Здравствуйте, Дарней, Вы писали:
Д>PPS А знаешь, что меня удивляет больше всего? Это работодатели, которые разводят неимоверные понты на собеседованиях и спрашивают целую кучу вещей, которые в реальной работе на этой позиции никогда не понадобятся.
С таким подходом (знать по минимуму только то что "надо для работы") деградация польная всех и вся настанет! Работа же не погрузочно-покрасочная! ... Хотя и там можно подкачаться или кисть держать ровнее научиться ... Тут и потенциал работодателям интересен и реальный уровень кандидата. Может он способен на большее чем Copy+Paste ? И понты тут не при чём. А вот другу Вашему я бы посоветовал разницу между виртуальными и невиртуальными методами всё-таки познать!
Здравствуйте, Eurispheus, Вы писали:
ГВ>>Вот, кстати, вопрос. Если специалисту безотносительно его ответственности и порядочности будут платить на уровне, скажем так, рыночном, то во сколько оценивается его ответственность и порядочность? Можно — в процентах к базовой ставке.
E>Я считаю, что ответственность и порядочность — это конкурентное преимущество специалиста. А з/п — конкурентное преимущество организации. E>Таким образом, ответственность и порядочность — это средство удержаться специалисту в этой фирме (при прочих равных). E>И наоборот, з/п — это средство фирмы удержать специалиста в этой фирме (при прочих равных).
Спасибо.
Я должен извиниться, вопрос был несколько некорректным. Спрашивать скорее нужно было самих специалистов, чем менеджеров. Вы сейчас просто подтверждаете, что на самом деле порядочность и ответственность с уровнем компенсации никак не связаны.
Хотя то, как Вы расставили "конкурентные преимущества" наводит на интересные размышления. Получается, что менеджменту выгодны безответственные и непорядочные сотрудники. У них меньше конкурентых преимуществ перед остальными, следовательно, они менее требовательны к фирме-нанимателю.
<< Под музыку: Аквариум — Из Калинина В Тверь >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Kestrel, Вы писали:
K>Небольшая таблица, где сравниваются примеры на C++ и Java, приведённые ранее.
Пункты
сравнения C++ Java
__________________________________________________________________________
<skip>
Есть ли реализация
void dominanceTest() нет нет
в IBase
Отношения BaseImpl наследует BaseImpl implements IBase
наследования от IBase
Derived наследует Derived implements IBase
от IBase
<skip>
K>В чем разница между примерами на на C++ И Java, кроме терминологии? K>Интересует не то, как называется то или иное свойство языка, а разница K>в поведении.
Разница наблюдается в выбранных выше пунктах.
"Есть ли реализация void dominanceTest() в IBase". В отличие от Java, в C++ реализация все-таки есть (хоть и абстрактная, но в соответствующей таблице виртуальных методов будет указатель на обработчик, который завалит программу с ошибкой "Pure virtual function called").
В Java интерфейс — это исключительно декларативная вещь, которая не содержит никаких признаков реализации.
Кроме того, в С++ классы связаны отношением наследования, а в Java — отношением реализации. Собственно, механизмы совершенно разные: раз в Java не идет речи о наследовании, то ни о каких ромбах в иерархии говорить не приходится. А если Вы считаете, что я не прав, то попробуйте построить свой Java-пример не на основе интерфейсов, а на основе абстрактных классов: вот где будет прямая аналогия с С++... только множественного наследования не получится
Попробую повториться в очень простых словах:
1) С++ — наследование от абстрактного класса означает: "Переопределен метод базового класса, и теперь в иерархии есть два метода: абстрактный у базового класса и вариант реализации у данного класса".
2) Java — реализация метода интерфейса означает: "У данного класса есть такой метод, и вы можете его вызывать!"
Здравствуйте, egaron, Вы писали:
E>Опять разгорелся флейм "тупые кандидаты" vs "умные работодатели". Если вы такие умные, то почему такие бедные ?
ИМХО, всё-таки работодатели платят деньги сотрудникам, а не наоборот . Так что либо кандидаты умные, либо бедные
E>Вот сейчас специально запустил поиск по проекту слова "virtual". Не поверишь — сие слово найдено только в комментариях, в проекте нет ни одной виртуальной функции. Как по-твоему живет и существует наш крупный заграничный проект, за котороый заказчик платит неплохие деньги?
Когда-то умные такие дядьки доказали теорему. Суть в том, что любую алгоритмическую задачу можно решить с применением 3-х структуп : структупа следования (последовательное выполнение инструкций), структура проверки условия и циклическая структура. Так зачем тогда что-то ещё ! Это ж можно не использовать ! А по поводу крупных заграничных проэктов ... В Индии тоже много крупных проэктов делается . Лет по 10 делается . И тоже за них деньги платятся. А кто пробовал саппортить эти проекты или изменения вносить, тот знает как всё-таки хорошо когда люди умеют правильно применять и наследование, и виртуальные методы, и все "никогда-не-нужные изыски ООП"!!! Так что тут вопрос только в том умеет разработчик применять знания и есть ли они. А деньги и за разгрузку вагонов платят.
E>Ведь в реальности вся эта лабуда, типа изысков ООП, виртуальных деструкторов и паттернов, и даже виртуальных функций, почти не используется в реальных проектах.
Как ни странно, но в компании где я работаю делаются очень даже РЕАЛЬНЫЕ проекты . И в них все облегчающие жизнь разработчику вещи (см. чуть выше ) используются.
E>Кстати, об ООП. Вот сейчас работаю над проектом, который проектирвался явно товарищами, помешанными на ООП (несмотря на то что даже вирт. функций ни одной нету). Строгое отделение бизнес-логики от гуи, все сущности вынесены в классы, классов такое количество, что в них запутаешься, все обращение к БД через кучу провайдеров-адаптеров. Казалось бы все грамотно и правильно — однако малейшее изменение кода в рамках данной архитектуры — перематеришься пока сделаешь — чрезмерная "объектно-ориентированность" тоже ведет к путанице кода не хуже чем "гоу ту". А уж косяков по производительности (многократное повторное считывание одних и тех же данных) — так их вообще дофига.
Куча классов — это не продуманная архитектура. Можно и калькулятор написать в 500 классов ! Или у Вас объём кода — критерий качества?
Здравствуйте, Геннадий Васильев, Вы писали:
K>>Кто-то бросает исключение. Я обычно делаю break. [...] А с goto у меня никогда нет уверенности, является ли такой выход корректным.
ГВ>У меня тоже не всегда есть такая уверенность. Здесь лучше всего помогает чтение стандарта и тесты. Большая часть вопросов и неуверенности снимается сходу. Про ошибки компилятора намеренно не упоминаю, это разговор особый. Он может и goto неправильно обработать, и break, и ещё много чего.
Но есть фичи, неаккуратная обработка которых более вероятна. И что написано в стандарте меня волнует лишь постольку, чтобы самому его не нарушать. От компиляторов я этого давно уже не требую. И стандарты к соседям давно снизил — никогда не знаешь, какую редко применяемую мелочь забудет эксперт с многолетним стажем.
K>>>>Аксиома: выбор стиля код программиста — не личное дело программиста, и вообще не его дело. Это дело тех, кто будет код поддерживать. ГВ>>>А на поддержку, значит, традиционно приглашаем новичков. Следовательно, любой код должен быть ориентирован на новичков. Так? K>>Я — не новичек. Но если мне подают код, ориентированный на новичков, то с ним работать гораздо легче. Спрашивается, нафига тогда выпендриваться ?
ГВ>Вы сформулировали аксиому, я сформулировал естественное логическое следствие из этой аксиомы в условиях традиционной практики. Оставьте свои впечатления при себе и ответьте на заданный вопрос.
Ваш вопрос опирается на предположение, что "код для новичков" и "код, с которым хотел бы работать профи", обязательно разные вещи. Я считаю, что это одно и то же. В этих условиях ваш вопрос получается эквивалентен "следовательно, любой код должен быть ориентирован на профессионалов". Ответ на оба эти одинаковых вопроса положительный. Я, как профессионал, предпочту работать с кодом, ориентированным на новичков.
ГВ>Если эти самые "остальные" мотивируют свои трудности необходимостью изучить инструмент, то это сугубо их личные проблемы. Инструмент надо знать и уметь.
Эти остальные могут знать инструмент от и до. Но зачем им ненужный геморрой ?
ГВ>С чего это Вы взяли, что на выходе у автора неизбежно получится г-но? Это всего лишь код на языке программирования и всё. Если фичи не понятны, то в них нужно разобраться, а не бравировать своим непониманием, прикрывая его маской заботы о ближнем.
Да кого вообще волнуют эти фичи ? Ну знаю их я. Знает сосед. Знает еще кто-нибудь. Может, все вокруг знают. Результат один — их применение должно быть обоснованным. Если их использование не несет каких-либо существенных плюсов, если это чистое эстетство ради более красивого кода, или может для сокращения десяти строк в семь (тоже мне разница), и при этом еще и затрудняют поддержку, то у них нет права на применение. Начальный кодинг много времени не занимает, как ты к нему не подходи. А вот дебаг и изменения жрут время с поистине зверским аппетитом. При этом обьем изменений кода снова минимален. Да пусть этот несчастный код втрое раздуют, только бы читался легче.
ГВ>Поймите меня правильно, я не против ругани в адрес того, кто оставил г-но за собой, хотя и на это могут быть свои вполне рациональные причины. Я против того, чтобы руководствоваться таким неправильным силлогизмом:
Я за огранчение на использование фич, создающих трудности в чтении и дебаге, в том числе чтении и дебаге "новичками".
ГВ>1. В некоторых случаях использование фичи X влечёт проблемы. ГВ>2. Проблемный код является г-ном. ГВ>Вывод: всякое использование фичи X — г-но.
Не всякое, а бесконтрольное.
Правильный вывод: допущение использования фичи без серьезного ее основания — ошибочно. Исключения должны быть именно исключением, и не более того. Код, засуморенный необоснованным применением нетривиальных для понимания фич, г-ный код. Не только потому, что новичкам его труднее разобрать, а и потому, что его всем труднее разбирать, анализировать взаимодействие различных его кусков и держать в голове одновременно все нюансы используемых конструкций.
ГВ>На бытовом уровне это может быть приемлемо, в технической деятельности — нет.
Между полным запретом и полным попустительством есть еще грань "запрет на применение без хорошего обоснования (на применение)".
ГВ>Это тоже так. Но у примитивизации есть и оборотная сторона, прежде всего связанная с увеличением объёма исходников. "Комбинаторный взрыв", знаете ли.
Смотря как писать. Если писать монолит и не разбивать на подсистемы — возможно. А в промышленных системах полгода интенсивной разработки могут включать лишь неделю-другую на собственно кодирование. Да и тогда все неплохо разбито на модули. В одном месте разбивка нарушилась, и я в тот раз перетаскивал потроха на более правильное место.
K>>Все запреты неоднократно выстраданы на крешах.
ГВ>Не стоит обобщать эту красивую легенду. На самом деле, запреты могут копироваться из всяческих good practices на основании одной только интуиции.
Это мне не помешало изрядно в оные креши потыкаться носом. На практиках основаны а) рекомендации б) запреты в условиях "при прочих равных" в) более жесткие запреты "при отсутствии обоснования и наличии обходных путей".
ГВ>Началось... Ладно, чтобы не вдаваться в длинные рассуждения, прочтите
Прочитал. Нашел утверждение, что при прочих равных надо выбирать более безопасный код. Добавлю, что еще и легко читаемый большей аудиторией. Отличие размера кода, скажем, в два раза, считаю незначительным, при сравнимом размере обьектника. С чем из этого вы не согласны ?
Кстати, могу предложить еще более интересный небезопасный код копирования строки:
{
int i = 0;
while(dst[i] = src[i]) { ++i;}
}
Вопрос на засыпку — когда такой вариант окажется лучше ?
ГВ>>> А почему виртуальное наследование можно при этом запрещать, хотя его даже зазубривать не надо, достаточно один раз понять? K>>Ну, понял. Разобрался. Выучил. Состояние "не могу работать с этой хренью" сменилось на "не переношу эту хрень, хочу видеть пять листов A4 с обоснованием, росписями и печатями под каждое применение".
ГВ>Главное, что "разобрался и выучил". То, что "хочется видеть" что-то там — дело десятое. Это совсем не повод запрещать окружающим это самое что-то использовать.
Почему не повод ? Теми или иными путями, но разброд и шатание всегда приводят к увеличению времени на выполнение работы, а это одна из главных характеристик процесса разработки. Баланс между единообразием кода, легкостью работы с ним у максимально широкой аудитории, и пристрастиями програмиста все же должен поддерживаться, а разрешение использовать все, что захочется, от баланса очень далеко.
ГВ>Не стоит обобщать эту красивую легенду.
Читать как: "принимать близко к средцу".
ГВ>То, что "хочется видеть" что-то там — дело десятое. Это совсем не повод запрещать окружающим это самое что-то использовать.
Читать как: "использовать то, что потребовалось изучить".
<< Под музыку: Аквариум — Из Калинина В Тверь >>
<< При помощи Януса: 1.2.0 alpha rev. 650 >>
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, kittown, Вы писали:
K>Здравствуйте, Геннадий Васильев, Вы писали:
K>>>Кто-то бросает исключение. Я обычно делаю break. [...] А с goto у меня никогда нет уверенности, является ли такой выход корректным.
ГВ>>У меня тоже не всегда есть такая уверенность. Здесь лучше всего помогает чтение стандарта и тесты. Большая часть вопросов и неуверенности снимается сходу. Про ошибки компилятора намеренно не упоминаю, это разговор особый. Он может и goto неправильно обработать, и break, и ещё много чего.
K>Но есть фичи, неаккуратная обработка которых более вероятна. И что написано в стандарте меня волнует лишь постольку, чтобы самому его не нарушать. От компиляторов я этого давно уже не требую. И стандарты к соседям давно снизил — никогда не знаешь, какую редко применяемую мелочь забудет эксперт с многолетним стажем.
Чего вы к goto прикопались? Меньше Дийкстру читайте .После компиляции goto,break и continue уже никак не различить
Здравствуйте, kittown, Вы писали:
K>Кстати, могу предложить еще более интересный небезопасный код копирования строки:
K>
K>{
K> int i = 0;
K> while(dst[i] = src[i]) { ++i;}
K>}
K>
K>Вопрос на засыпку — когда такой вариант окажется лучше ?
О, кстати, интересно: я не могу придумать сколь-нибудь значимый пример того, когда бы этот вариант оказался лучше. Даже с учетом того, что процессор поддерживает индексную адресацию (т.е. вычислять адрес по два раза за цикл не нужно: нужно всего лишь прогрузить четыре регистра — и можно сразу обращаться к ячейке памяти) — все равно работа с инкрементом указателей оказывается эффективнее индексной адресации, как по скорости работы, так и по размеру объектного кода. Ну разве что в результате работы этого кода к концу цикла у нас остаются неизменными значения src и dst... но это ерунда.
Здравствуйте, Udjine, Вы писали:
U>С таким подходом (знать по минимуму только то что "надо для работы") деградация польная всех и вся настанет! Работа же не погрузочно-покрасочная! ... Хотя и там можно подкачаться или кисть держать ровнее научиться ... Тут и потенциал работодателям интересен и реальный уровень кандидата. Может он способен на большее чем Copy+Paste ? И понты тут не при чём. А вот другу Вашему я бы посоветовал разницу между виртуальными и невиртуальными методами всё-таки познать!
знание одного принципа избавляет от необходимости знать сотни деталей (С) Конфуций
могу только посочувствовать тем, кто этого не понимает. Мозги — они не бесконечные
Здравствуйте, Александр Каширин, Вы писали:
АК>Ненадежен — да, несомненно. Однако в остальном — никакой это не выпендрежь, а совершенно нормальный, простой, часто встречающийся, легкочитабельный и эффективный код. Добавить туда еще контроль размера буфера — и цены этому коду не будет
нормальный, простой, легкочитабельный и эффективный код — это ArrayCopy(src, dst)
а за выпендреж c "while(*dest++ = *src++);" надо бить по рукам резиновой дубинкой
Здравствуйте, Дарней, Вы писали:
Д>нормальный, простой, легкочитабельный и эффективный код — это ArrayCopy(src, dst) Д>а за выпендреж c "while(*dest++ = *src++);" надо бить по рукам резиновой дубинкой
Хорошо что я не у вас работаю, а то бы без рук остался.
Кстати, а кто такой ArrayCopy? Это вообще из C? А то обычно идет сначала dst, а потом src.
Здравствуйте, algol, Вы писали:
A>Хорошо что я не у вас работаю, а то бы без рук остался.
такое вообще во многих компаниях практикуется, где требовательно относятся к качеству кода. хотя бьют обычно не по рукам, а скорее по кошельку
A>Кстати, а кто такой ArrayCopy? Это вообще из C? А то обычно идет сначала dst, а потом src.
Это просто шаблонный метод. Неважно, откуда он взялся. Считай, что просто кто-то его написал
Здравствуйте, mik1, Вы писали:
M>А еще — покажите мне место в Москве, где офис снимают в подвале и платят программеру 3000$. M>Поверю в 1500 максимум.
Поверьте, что такие места есть. И даже не одно. Почему в подвале — чтобы в случае неожиданного притока любопытствующих быстро бросить подвал, не сожалея об оставленных кондиционерах, coffee-machines, кожаных диванах... и контрафактной продукции...
Здравствуйте, Дарней, Вы писали:
Д>нормальный, простой, легкочитабельный и эффективный код — это ArrayCopy(src, dst) Д>а за выпендреж c "while(*dest++ = *src++);" надо бить по рукам резиновой дубинкой
Вот пример из файла "algorithm" библиотеки STL в варианте MS Visual C++ 6.0:
Такого кода там полно. В других реализациях STL (не от MS) подобного кода не меньше, а возможно даже и больше (MS вообще скромничает, применяя подобный код). Обратите внимание, что там не только постинкремент указателя применяется прямо в выражении, а еще и выражение через запятую написано. Ужас Так давайте надаем по рукам разработчикам библиотеки STL и навсегда откажемся от ее применения А заодно и от применения стандартной библиотеки работы со строками С.
Здравствуйте, Александр Каширин, Вы писали:
АК>Такого кода там полно. В других реализациях STL (не от MS) подобного кода не меньше, а возможно даже и больше (MS вообще скромничает, применяя подобный код). Обратите внимание, что там не только постинкремент указателя применяется прямо в выражении, а еще и выражение через запятую написано. Ужас Так давайте надаем по рукам разработчикам библиотеки STL и навсегда откажемся от ее применения
Ты будешь смеяться, но многие конторы, которые выпускают серьезный софт, именно так и делают.
Хотя теперешние реализации СТЛ уже неплохо вылизаны, пользоваться ими можно практически без опасений. Если конечно ты ими только пользуешься, но не изменяешь библиотечный код.
Но человека, который пишет в таком же стиле продакшен код, который часто меняется — гнать из фирмы без размышлений
АК> А заодно и от применения стандартной библиотеки работы со строками С.
Здравствуйте, Eurispheus, Вы писали:
E>Здравствуйте, Menestrel, Вы писали:
E>>>Пока складывается ощущение, что вы не ориентируетесь в теме обсуждения. M>>Очень даже ориентируюсь. Даже могу открыть маленький секрет: в 98% случаев люди идут устраиваться на работу именно из-за денег и только из-за них. Им глубоко по барабану все красоты кАрпАрАтивных политик и вся остальная подобная чушь.
E>Эта тема уже обсуждалась. Действительно, при уровне дохода, при котором +/- $500 еще имеет значение, з/п при выборе места работы стоит на первом месте.
Поясняю минус. +-500$ становятся безразличными, когда эти самые +- <10% от зарплаты. Т.е. при зарплате 10000$ / месяц да, пофиг. А хотя бы 5000 — что-то да значит.
