Вопрос можно ставить более широко. Работодатели всегда требуют, чтоб кандидат знал, то, что они считают нужным, умел делать то, что им нужно и делал это именно так, как они считают правильным. При этом работодатели либо не хотят, либо не могут выяснить, может ли кандидат обучиться тому, что им нужно, готов ли он следовать их стандартам программирования и т.д. И порой складывается парадоксальная ситуация, фирма не может найти себе специалиста, а толпа специалистов даже не знает, какие требования предъявляются в этой фирме и не может привести себя в соответствие с этими требованиями.
Здравствуйте, flashinc, Вы писали:
F>Сделайте упор все-таки на практическую сторону. А именно — дайте вначале простейший тест с вопросами (без лимита по времени), затем посадите человека за конкретный инструмент, написать что-то конкретное, по вашей специфике. В некоторых случаях можно получить удивительные результаты. И может случиться так, что они вас удовлетворят.
Именно. Надо смотреть как человек справляется с данными ему заданиями. Хорошо еще давать код и просить найти баги, проблемы, неудачные решения. Обсудить возможности расширения, параллелизации и т.п.
Здравствуйте, FDSC, Вы писали:
FDS>А я что, говорю о чём-то другом?
Да, там было четко написано "Ваш код не скопилируется", ни слова "мой тоже не скомпилируется".
FDS>ПОЖАЛУЙСТА, ЧИТАЙТЕ МОИ СООБЩЕНИЯ ПЕРЕД ТЕМ, КАК ОТВЕЧАТЬ НА НИХ!!!
не горячись, выпей валокордину что ли.
И пойми — даже если ты знаешь Дао и можешь написать такой хитрый выкрутас, который позволит использовать указатели вместо ссылок — то обычные смертные программисты такого не знают все равно и не уверены, что твое заклинание все еще в силе. Потому не смогут в других методах класса предполагать по умолчанию, что твой указатель ведет себя как ссылка и обязательно требует инициализации. Ну просто не могут, если у них есть какой-то практический опыт рабоыт в нашем переменчивом мире.
Потому что можно, конечно, использовать в театре, настоящие боевые полностью исправные автоматы, написав в инструкции, что патронов в них нет, и никогда не будет. Но здавомыслящий человек все же будет проверять наличие патронов прежде чем снимать его с предохранителя.
Ибо преценденты "неожиданного" появления боевых патронов в ранее незаряженном оружии в человеческой истории были.
Ну а неожиданное изменение поведения инциализации членов класса это вообще обычное дело.
Предположение что "данный указатель в данной программе всегда будет инициализирован, потому что так сказал Я" оно гораздо слабее, чем "данная ссылка всегда будет инициализирована, потому что неинициализированной ссылка быть просто не может".
Здравствуйте, FDSC, Вы писали:
A>>i — не обязательно встроенный тип, это может быть какой-нибудь навороченный итератор делающий достаточно сложные преобразования.Как правило посфиксный оператор реализуют через префиксный с копированием, отсюда и разница.
FDS>Если это будет итератор — я учту. Только скорее я буду там использовать ".Next" а не "++", а если я пишу for (int i = 0; i < L; i++), то какого чёрта мне писать ++i, это просто некрасиво
Мне почему-то тоже привычнее писать i++, хотя рационально объяснить я это не могу.
Здравствуйте, fmiracle, Вы писали:
F>И пойми — даже если ты знаешь Дао и можешь написать такой хитрый выкрутас, который позволит использовать указатели вместо ссылок — то обычные смертные программисты такого не знают все равно и не уверены, что твое заклинание все еще в силе. Потому не смогут в других методах класса предполагать по умолчанию, что твой указатель ведет себя как ссылка и обязательно требует инициализации. Ну просто не могут, если у них есть какой-то практический опыт рабоыт в нашем переменчивом мире.
Это никакие не заклинания. Я привёл вполне реальную вещь, которая абсолютно так же, как и ссылка, блокирует изменение значения указателя простым объявлением константности. Инициализации они требует, потому что указатель объявлен как константа, абсолютно аналогично ссылке. Единственное, при инициализации нужно проверить, что указатель инициализируется не нулём или инициализировать его с помощью переданной в конструктор ссылки (как я и продемонстрировал). Т.е. проверить указатель нужно лишь один раз: при инициализации в конструкторах или вообще не проверять, если используется ссылка
В чём тут колдовство я не понимаю. А вот у вас колдовство потом получится может, программист будет думать, что он изменяет приватный объект, например, а на самом деле будет изменять ссылку....
F>Потому что можно, конечно, использовать в театре, настоящие боевые полностью исправные автоматы, написав в инструкции, что патронов в них нет, и никогда не будет. Но здавомыслящий человек все же будет проверять наличие патронов прежде чем снимать его с предохранителя.
В данном случае, указатель далеко не полностью боевой. Ещё раз прошу вас прочитать сообщение, на которое вы ответили, перед тем, как продолжать со мной спор
F>Ибо преценденты "неожиданного" появления боевых патронов в ранее незаряженном оружии в человеческой истории были.
Да, зато ни разу не было, что бы автомат со спиленным бойком стрелял
F>Ну а неожиданное изменение поведения инциализации членов класса это вообще обычное дело.
Это да. Хотя если программист не совсем дурак, передавать NULL в конструктор он всё равно не будет, но даже если передаст, вы это сразу заметите, а вот где изменяется ваш любимый и лелеемый объект вы не заметите, если он будет изменяться по ссылке. Вы будете читать код и видеть, что изменяется какой-то другой объект, а вовсе не ссылка на ваш.
F>Предположение что "данный указатель в данной программе всегда будет инициализирован, потому что так сказал Я" оно гораздо слабее, чем "данная ссылка всегда будет инициализирована, потому что неинициализированной ссылка быть просто не может".
Константный указатель тоже не может быть неинициализирован — это ошибка компиляции. Третий раз прошу прочитать мой пост, перед тем, как продолжать спор
Здравствуйте, DKM_MSFT, Вы писали:
DKM>За три недели человек проделал объем работы, который удивил всю команду. Вчера я делал code-review его кода. Код идеально соответсвует духу соответсвующих приложений, я нашел 6 стилистических проблем в коде, который занимал несколько десятков экранов.
Здравствуйте, FDSC, Вы писали:
FDS>Если это будет итератор — я учту. Только скорее я буду там использовать ".Next" а не "++", а если я пишу for (int i = 0; i < L; i++), то какого чёрта мне писать ++i, это просто некрасиво
Думай на тему STL и общего дизайна кода по всему проекту:
for (int i = 0; i < L; i++)
for (iterator i = start; i != end; ++i)
суть циклов совершенно одинакова. Почему надо в одном случае пиасать ++i а в другом i++???
Почему не писать более "общий" ++i?
Какая тут вообще принципиальная разница с этетической точки зрения где плюсики? Надо просто взять какой-то вариант в привычку да и использовать. Привычным может быть как тот так и другой. Зачем так упираться в свою привычку-то?
Я раньше тоже всегда писал i++, казалось красивее. Почитав про копирование перешел на ++i без каких-то проблем — теперь так же кажется красивее это. Или у тебя есть строгое доказательство большей красивости постфикса над префиксом?
Использовать .Next это круто конечно же. Особенно если создаешь итератор для работы с stl например, который предполагает наличие ++ но не .Next().
Я уж не говорю про случай, когда ты пользуешься чужим итератором, где нет твоего метода .Next. Ну можно обматерить автора, правда.
Здравствуйте, fmiracle, Вы писали:
F>Думай на тему STL и общего дизайна кода по всему проекту:
F>for (int i = 0; i < L; i++) F>for (iterator i = start; i != end; ++i)
А я такие циклы через while делаю
F>Какая тут вообще принципиальная разница с этетической точки зрения где плюсики? Надо просто взять какой-то вариант в привычку да и использовать. Привычным может быть как тот так и другой. Зачем так упираться в свою привычку-то?
У меня высокохудожественный вкус: центр масс выражения "i++)" по середине, а "++i)" смещён вправо. К тому же, скобка рядом с переменной немного затрудняет чтение кода, а когда она отделена ++ это улучшает визуальную читабельность
F>Я раньше тоже всегда писал i++, казалось красивее. Почитав про копирование перешел на ++i без каких-то проблем — теперь так же кажется красивее это. Или у тебя есть строгое доказательство большей красивости постфикса над префиксом?
F>Использовать .Next это круто конечно же. Особенно если создаешь итератор для работы с stl например, который предполагает наличие ++ но не .Next(). F>Я уж не говорю про случай, когда ты пользуешься чужим итератором, где нет твоего метода .Next. Ну можно обматерить автора, правда.
Ну, что поделаешь...
iterator i = start;
while( i != end)
{
// ....
++i;
}
На такое согласен, хотя всё равно, как-будто i с каким-то цепом в руках куда-то идёт
Я стремлюсь, что бы код выглядел визуально красиво. В частности, никогда не понимал Макконнелла, когда он говорил, что
знаки равно в коде
int i = 0;
int kjfdsl = 0;
не нужно выравниваить и никто не будет заниматься их поддержкой
Здравствуйте, FDSC, Вы писали:
FDS>У меня высокохудожественный вкус: центр масс выражения "i++)" по середине, а "++i)" смещён вправо. К тому же, скобка рядом с переменной немного затрудняет чтение кода, а когда она отделена ++ это улучшает визуальную читабельность
С отделением скобки для улчшения читабельности согласен, то лично я просто предпочитаю всегда отделять скобки и операторы пробелами:
....; ++i );
а так же:
if( a )
while( !b )
Foo.Bar( c + 1 );
Здравствуйте, Ulter, Вы писали:
U>то это то-же самое, что abbyy и bitsoft U>Делайте выводы...
А какие выводы надо сделать?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, sc, Вы писали:
sc>В данном случае, если ссылку заменить на указатель, вред точно такой же sc>Почему же указатели хуже? Потому что Гугл на запрос "pointers are evil" выдает 554 ссылки а на "references are evil" всего 10
Да просто ссылки ЗЛО малоизвестное
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, NikeByNike, Вы писали:
NBN>Здравствуйте, FDSC, Вы писали:
FDS>>И тут она будет поймана компилятором. Вставьте ВЕСЬ мой код в компилятор и попробуйте скомпилировать
NBN> virtual ~C2() NBN> { NBN> delete c1; NBN> c1 = NULL; <- лишнее действие NBN> }
На сколько я помню, оператор delete не обнуляет операнд-указатель. А у меня есть привычка некоторые поля классов обнулять при уничтожении, что бы если на них был указатель, он не указывал на когда-то бывшие валидные данные
Здравствуйте, sc, Вы писали:
sc>ну вот, начали уже не помню с чего, продолжили ссылками и указателями, теперь спор идет о количестве пробелов. причем совсем не конструктивный
FDS>>Если это будет итератор — я учту. Только скорее я буду там использовать ".Next" а не "++", а если я пишу for (int i = 0; i < L; i++), то какого чёрта мне писать ++i, это просто некрасиво F>Думай на тему STL и общего дизайна кода по всему проекту: F>for (int i = 0; i < L; i++) F>for (iterator i = start; i != end; ++i) F>суть циклов совершенно одинакова. Почему надо в одном случае пиасать ++i а в другом i++??? F>Почему не писать более "общий" ++i? F>Какая тут вообще принципиальная разница с этетической точки зрения где плюсики? Надо просто взять какой-то вариант в привычку да и использовать. Привычным может быть как тот так и другой. Зачем так упираться в свою привычку-то? F>Я раньше тоже всегда писал i++, казалось красивее. Почитав про копирование перешел на ++i без каких-то проблем — теперь так же кажется красивее это. Или у тебя есть строгое доказательство большей красивости постфикса над префиксом? :)
Это всего лишь "мода" Мейерса или Саттера. Кроме того что прочитать и следовать "новой моде" полезно знать, какой код будет в реальности. А в реальности в 99.9% temporary не создастся, только если специально не стараться. Если иметь по всему проекту привычку писать ++i, легко "намозолить глаза", и рано или поздно, влететь в ситуацию когда напишешь ++ptr = ... вместо ptr++ Представим, что мы пишем некий аддон для браузера, где этот указатель передается в функцию и по нему что-то записывается или читается.
Далее может быть такой сценарий: memory access, на x86 как известно, чекается по страницам 4kb. Пока количество объектов в списке (массиве) будет определенным, Access Violation происходить не будет. Но в один прекрасный день, допустим, html-документ вытянутый с сервера будет иметь размер как раз такой, что выполнив ++ptr указатель при доступе по нему будет заходить в область другой 4kb memory page. Всё. Access Violation. До свидания. Браузер упал, URL в кэш не записался.
А все почему? Да потому что следовали моде, повышали эффективность оператора i++. В реальности нужно не следовать моде,
а здравому смыслу и все перепроверять на деле. Кстати, это касается и языковых изысков самого Страуструпа...
p.s.
в дискуссии выше, про сылки, еще не промелькнуло использование везде где только можно вместо ссылок или указателей
auto_ptr или shared_ptr. В том числе, и в качестве полей класса. Есть и такие "модники"....
Здравствуйте, flashinc, Вы писали:
F>p.s. F> в дискуссии выше, про сылки, еще не промелькнуло использование везде где только можно вместо ссылок или указателей F>auto_ptr или shared_ptr. В том числе, и в качестве полей класса.
Естественно! В качестве полей класса надо использовать в зависимости от ситуации boost::shared_ptr или boost::scoped_ptr. Сразу видно какая политика владения и в большинстве случаев можно обойтись без написания деструктора.
Не хватает только стандартного copy_ptr, который бы при копировании клонировал объект на который указывает.
F>Есть и такие "модники"....
