Здравствуйте, CreatorCray, Вы писали:
А>>Будет ли полностью освобождена память на которую указывает tranDets?
CC>Хм. Какой хороший вопрос для собеседования!
И если собеседуемый с ходу не отвечает, даем подсказку:
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, CreatorCray, Вы писали:
CC>>Хм. Какой хороший вопрос для собеседования! E>А что в нём хорошего? E> (Какие выводы по соискателе позволяет сделать тот или иной ответ на этот "хороший" вопрос?)
я например боюсь с++ экспертов, они как нааачнут работать крупными мазками, что потом не разберешься, что это...программа ваще или картина — "неизвестная с огурцом".
Здравствуйте, CreatorCray, Вы писали:
CC>Но если вдруг ответит что память освободится по обоим указателям — серьезный "минус". CC>Где то так...
IMHO ответ "хрен его знает, я так не пишу, возможно будет вот так, а возможно и так..." тоже подходит
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, CreatorCray, Вы писали:
CC>Смысла в этом коде нет никакого. А запутать может, особенно при беглом просмотре кода, когда глаз цепляется за начало строк.
Смысл — в фейсконтроле. Чтобы не запутать — можно после кода в коментарии поставить смайлик.
CC>А какой смысл их не подпускать?
Чтобы вместо того, чтобы разжевывать очевидные (для людей схожей квалификации) вещи в своем коде, написать больше действительно полезного кода. Если не нравится пример, который я уже привел — могу привести другой: вместо расписывания что делает "хитрый" по мнению неучей код — дать ссылку на "must have" для тех кто забыл. Например, вместо объяснения почему "вместо" цикла идет простой x&(x-1) — дать ссылку на книжку K&R.
CC>В свое время столкнулись с капитальной нехваткой квалифицированных С++шников.
Не бывает нехватки квалифицированных кадров (по крайней мере, в РФ) — бывает желание найти квалифицированных кадров, готовых работать "за еду".
CC>Пришлось выбирать лучших из тех что были. И они должны были работать и желательно как можно более эффективно.
Только вот сколько Вы потеряли на том, что квалифицированные ваши сотрудники были вынуждены работать с этими, Вы не посчитали?
CC>А вот такие запутывалки только тормозят понимание кода. Следовательно их использование скорее во вред.
Такие ловушки не надо разрасывать по всему коду — только на самом видном месте.
CC>Вообще я лично оценивал всегда как большой плюс, если на пример какого нибудь головоломного заворота кода собеседуемый отвечал что за такой код надо больно бить по рукам и заставлять переписывать. Разумеется если такой ответ приходил на простую конструкцию то эффект был как раз противоположный.
В общем случае — это сильно зависит от заворота и от того, в каком месте проекта он используется. В любом случае, так как все субьективно, WTFs/min равным нулю не бывает.
CC>ИМХО некоторые возможности С++ людям со слабой волей лучше и не знать вовсе — не удержатся от применения везде где только можно. Получившуюся помойку потом и сами часто не могут отладить/модифицировать.
C++ — это язык для квалифицированных программистов. Всем будет лучше других держать подальше.
CC>Это и надо выяснять на собеседовании + испытательный срок еще есть для особо клинических случаев.
Вам очень везет, если Вы можете проводить собеседование для _каждого_, кто будет иметь дело с Вашим кодом. Могу только позавидовать.
Re[17]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, Erop, Вы писали:
E>>Я думаю, что так писать можно, но в целом не нужно. LMA>Что-то грань уж слишком размытая. E>>Конструкция "+=" очень простая и широко известная, в отличии от точек следования... LMA>Ну хорошо, а то я уж боялся, что и LMA>
LMA>a += b += c;
LMA>
LMA>тебе не понравится.
Определенно, LordMAD впечатления опытного профессионала не производит, скорее всего просто подросток с комплексами.
Крайне мала вероятность, что он действительно участвует в коммерческих проектах, в виду отсутствия минимальных коммуникативных навыков и мании величия.
Здравствуйте, Programador, Вы писали:
P> или както так сделать чтоб выводить delete[] и delete , хотя для одиночных можно всегда new[1] звать, чтоб не путатся
Вот уж реально людям заняться нечем
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, LordMAD, Вы писали:
LMA>Запись "delete x, y, z;" есть способ повысить минимальный уровень требований к осуществляющему code review, если, конечно, писавший такое понимает, что он делает "delete x;". Т.е. способ не подпускать новичков к своему коду,...
А что, систем контроля версий и распределения прав вы не используете в работе?
Да и какой смысл в этой записи писать "x, y" вообще? Это типа просто обфускация на коленке?
Я бы такие ПРЕДНАМЕРЕННЫЕ действия воспринимал как преднамеренный саботаж, и немедленно бы уволил...
Хотя, возможно ты о разработке в OpenSource канечна... Там уволить нельзя вроде как...
LMA>писать просто LMA>
LMA>assert(true);
LMA>
Нахрена это вообще писать? Этот код эквивалентен пустому оператору. Если ты хочешь что-то написать читателю кода, а не компилятору, то от чего бы не воспользоваться человеческим языком, а не языком С++ ребусов?..
LMA>...если Вы понимаете о чем я. Что в конечном итоге может повысить производительность труда, между прочим. Понятно, что такое применимо не для всех проектов.
В целом я понимаю. Ты о генерации С++ кода, который никто кроме тебя поддерживать не сможет.
Мало того, что это вредно для бизнес-процессов, так это ещё и для тебя вредно.
Во-первых, ты не сможешь работать с другими людьми\
Во-вторых, обычно такие подходы приводят к тому, что через пару лет надо что-то поправить, а не выходит...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, CreatorCray, Вы писали:
CC>А вот "может быть так, а может эдак", если про удаление обоих заикнется — тогда все таки минус. Ну базовые ж вещи! Тем более при прямой работе с памятью.
Ну, в целом, стандарт у С++ кудрявый. И кто его там знает, что придумали там для запятой в delete. IMHO, может быть три варианта (по степени убывания вероятности)
1) удалится второй
2) удалится первый
3) удаляться таки оба, только второй как скаляр (это если delete x, y; устроен так же как и int x, y
Какой из трёх выбрали авторы языка догадаться, IMHO, нельзя. Это надо знать. Но на кой бы это знать --
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>IMHO, может быть три варианта (по степени убывания вероятности) E>1) удалится второй E>2) удалится первый E>3) удаляться таки оба, только второй как скаляр (это если delete x, y; устроен так же как и int x, y
Однако...
E>Какой из трёх выбрали авторы языка догадаться, IMHO, нельзя. Это надо знать. Но на кой бы это знать --
Знать надо формат вызова delete. И как оно работает. Надеюсь с этим ты согласен?
Впрочем я тут круче пример придумал:
char *foo = new char[100];
char *bar = new char[100];
delete [] (foo,bar); // ЫЫЫЫЫ!!!
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, LordMAD, Вы писали:
E>>В преднамеренном препятствовании коллективной разработке и снижении управяемости процесса производства ПО. LMA>А никакого припятствования! Речь идет лишь о том, что люди должны иметь определенный уровень квалификации.
IMHO это дело менеджера или владельца кода, выяснять какая у кого должна быть квалификация. Действия с твоей стороны направленные на воспрепятствование понимания твоего кода однозначно являются саботажем.
LMA>Где на C++ нельзя, приходится английский — мир не идеален.
Просто улучши свой английский, а не на мар гони
E>>Кроме того, он может попробовать выяснить зачем такая хреновина написана. LMA>Always welcome. Но если что — пусть не удивляется, если "опущу".
Короче -- хороший код должен помогать в нм разобраться, а не мешать.
LMA>+1. Только что есть "нестандартный код" — видимо у нас разные взгляды.
Так у тебя код "delete x, y, z" ещё и стандартный?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
LMA>>А никакого припятствования! Речь идет лишь о том, что люди должны иметь определенный уровень квалификации. E>IMHO это дело менеджера или владельца кода, выяснять какая у кого должна быть квалификация. Действия с твоей стороны направленные на воспрепятствование понимания твоего кода однозначно являются саботажем.
Еще раз: тут нет восприпятствования пониманию. Совеобразная "проверка на вшивость". Если я получу запрос по данной строке — просто буду иметь аргумент, касающийся квалификации инициатора запроса до того, как он будет слать другие запросы. Ну нет у меня желания _каждому_ объяснять что из себя представляет та или иная конструкция языка или алгоритм. Это не означает, что если кто-то поинтересуется для самообразования — то я не объясню.
E>Просто улучши свой английский, а не на мар гони
Если ты не в состоянии понять, почему средствами языка программирования документировать код лучше, чем на естественном языке, это еще не повод бестактности писать.
E>Короче -- хороший код должен помогать в нм разобраться, а не мешать.
А кто спорит? Но тратить время _в каждом проекте_, на то, чтобы с кодом мог разобраться любой — не стоит. Просто я ценю свое время.
E>Так у тебя код "delete x, y, z" ещё и стандартный?
А что в нем нестандартного?
... LMA>Еще раз: тут нет восприпятствования пониманию. Совеобразная "проверка на вшивость". Если я получу запрос по данной строке — просто буду иметь аргумент, касающийся квалификации инициатора запроса до того, как он будет слать другие запросы. Ну нет у меня желания _каждому_ объяснять что из себя представляет та или иная конструкция языка или алгоритм. Это не означает, что если кто-то поинтересуется для самообразования — то я не объясню.
Противоречие
... E>>Короче -- хороший код должен помогать в нм разобраться, а не мешать. LMA>А кто спорит? Но тратить время _в каждом проекте_, на то, чтобы с кодом мог разобраться любой — не стоит. Просто я ценю свое время.
А время других? Код пишется дни, недели, месяцы а сопровождается годами. Поэтому вожно, чтобы код хорошо сопровождался, иначе затраты на его поддержку со временем будут больше, чем затраты на его переписывание. Если нравится писать в мусорку, тогда действительно стоит писать как можно более запутанный код. Хотя в больших и сложных проектах и без этого проблем хватает.
Здравствуйте, LordMAD, Вы писали:
LMA>Все верно, но это не значит, что он должен хорошо сопровождаться любым человеком. Если Ваш код не может сопровождать обезьяна, это же не значит, что его плохо сопровождать.
Не, ну если у вас и обезьяны доступ к коду имеют, то мне всё больше интересно где ты таки работаешь?
LMA>Повторю: писать код, который легок для понимания квалифицированным программистом быстрее (а еще приятнее), чем код, понимаемый любым программистом.
Может быть ты таки пояснишь, начиная с какой квалификации программиста конструкции вроде "delete x, y, z" начинают облегчать понимание кода?
Моей квалификации, например, хватило бы только на то, чтобы понять "Осторожно! Код писали люди с альтернативным подходом к программированию!!! Дальше может быть любое г.!!!!". Правда мне пришлось сделать осмысленное усилие, когда я этот пример тут увидел. Вспомнить про операторы, про запятую и т. д. Нормальный код на С++ я читаю не задумываясь о синтаксисе, примерно как текст по-русски или по-английски.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, LordMAD, Вы писали:
LMA>>Странное требование — чтобы они могли его понимать. Зачем? Может стоит просто подумать о другой декомпозиции? E>Например при его использовании и отладки базирующегося на нём кода...
Для этого достаточно знания интерфейса и того, чтобы к этому моменту он был оттестирован. Им нет смысла заходить внутрь моих функций, ведь даже если они передадут что-то не то в качестве аргументов моему коду — они получат "assert'ом по морде"
Необходимость заходить внутрь используемого кода говорит только о низком его качестве и объективно не нужна.
Здравствуйте, LordMAD, Вы писали:
LMA>Необходимость заходить внутрь используемого кода говорит только о низком его качестве и объективно не нужна.
IMHO, гордиться надо практическими результатами, а не абстрактной крутизной кода.
Ну а то, что ты совершенно не приспособлен к работе в команде ты меня убедил. Увы и ах, но я только убеждаюсь в том, что мой первоначальный диагноз был верным...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>IMHO, гордиться надо практическими результатами, а не абстрактной крутизной кода.
Вот именно. Пока я от тебя услышал только то, что ты пропагандируешь какие-то теоретические принципы, которых сам же не придерживаешься, обуславливая это компромиссом. Все компромиссы должны быть формализованы ДО, а не ПОСЛЕ. IMHO, компромиссы, о которых говоришь ты, — это все лишь отмазки, нужные для того, чтобы в любой момент можно было прикрыть себе задницу: для тех людей, кто пишет нереальные (учитывая ресурсы, время и качество) "стандарты" кодирования — тем, что они написали "правильные" стандарты, а для тех, кто таким "стандартам" вынужден следовать — необязательностью следованию стандартов (компромиссом). Могу даже предположить, что у вас видимо стандарты вполне себе похожи на некоторое из тех, которые я видел, включающие кроме всего прочего, _запреты_ на использование goto, глобальных переменных; или устанавливающие минимальный размер комментариев.
Re[17]: Программирование деятельность целенаправленная....
Здравствуйте, LordMAD, Вы писали:
LMA>Не "запутан", а не разжеван. Если это приводит к экономии денег заказчика (т.к. производительность работы квалифицированных программистов возрастает) — это саботаж? Ну тогда — я сочувствую вашим заказчикам!
Мне кажется или кто-то пропагандировал использование конструкции "delete x, y, z", с целью сделать код более непонятным для программистов низкой квалификации? При этом, насколько я понял, программистов, которым такая конструкция понимаени кода облегчает в природе не существует...
А заказчикам нашим сочувствовать не надо. Мы производим весьма успешные коробочные продукты, и библиотеки и SDK и в целом всем всё нравится.
LMA>Если ты не видишь разницы, между тем, что я не готов специально снижать свою производительность в НЕКОТОРЫХ проетках (что и было бы саботажем, IMHO) и тем, что пишешь ты — с тобой разговаривать не о чем!
А мне показалось, что ты готов специально тратить усилия (то есть таки снижать свою производительность) для того, чтобы затруднить поддержку кода слишком низкоквалифицированными (по твоему мнению, а не по мнению заказчика) специалистами. То есть ты тратишь оплаченное заказчиком твоё рабочее время на удорожание саппорта. Ну и что что ты это только "в некоторых проектах" делаешь?
LMA>Только если на это есть существенная причина, которая с лихвой покроет недостатки такой шалости!
И какова же эта существенная причина преднамаренно понижать качество кода? Твоя патологическая боязнь критики?
E>>и что надо писать delete x, y, z... LMA>Ты будешь удивлен, но МОЖНО и НАДО — это не одно и тоже!
Я не удивлён. Тебя я понял так, что НАДО, а я, например, считаю, что НЕЛЬЗЯ...
LMA>Как я уже писал, и в хорошем коде WTFs/min равным нулю не бывает, если конечно не свой собственный код человек смотрит (шучу). Я не вижу ничего криминального в том, что я в каком-то куске кода добавлю в свои ворота WTF (хотя, как я уже писал, уверен, что если смайлик поставлю — коллеги меня поймут), а взамен получу реальную пользу в виде доводов против того, чтобы _это_ критиковало мой код.
У тебя как-то много оченьпривязанности к коду. Прямо как к поэме или к ребёнку. Какие-то обиды, цензы кто там что может или не может критиковать...
Обычно, когда критикуют, то приводят аргументы. И сразу ясно кто там чего стоит, и как критик и как автор.
Если даже очень неквалифицированный программист найдёт в твоём прекраснейшем коде ошибку или недочёт какой -- то это будет на благо проекту!!!
Цель ведь не код свой внедрить, а РЕШИТЬ ПОСТАВЛЕННУЮ ЗАДАЧУ...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, LordMAD, Вы писали:
LMA>получу реальную пользу в виде доводов против того, чтобы _это_ критиковало мой код.
Следует ли понимать, что человека, обозначенного как _это_ вы считаете недопрограммистом а то и вообще недочеловеком?
Ну а себя, соответственно, неким арийцем?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[16]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, Erop, Вы писали:
E>Наоборот. Список контекстов, где запятая уместна.
Это непринципиально.
E>Обычно этот список состоит из лдного пункта -- третьей части оператора for...
-1
Как минимум, в голову сразу еще приходят "первая часть for" и переопределенный "operator,"
В общем случае запрещать использовать запятую почти всегда — это означает попросту не доверять программистам "решать на месте", что возможно в работе только с новичками, IMHO.
E>Какой код? "delete x, y, z"?
Нет, это же я только собираюсь...
LMA>>То, что одна мысль не размазана на две строки — это усложнение? E>Если тебе так критично написать это на одной строке, напиши через ";". Так всё равно будет понятнее, чем с запятой.
Это практически тоже, что писать в две строки.
Re[17]: Месье ещё и с формальной логикой не дружит?
LMA>Просто вторым и третьим аргументом оператора "?:" являются выражения, а не значения — что я уже писал выше.
Какие проблемы? Подставь вместо p и q какие-нибудь выражения
LMA>Собственно это "старо как мир": когда Страуструп написал в своей "The C++ Programming Language" про то, что это не может быть сведено к одним лишь приоритетам — его об этом самого расспрашивали в одном из интервью — можешь найти его ответ. Все это не означает, что приоритетов не существует, это означает, что кроме приоритетов есть кое-что еще.
А я на новизну и не претендую. Это не я писал, что если де С++ программист не знает приориетов операций, то он вообще последний лох. Я давно уже в курсе, что "нет никакой ложки", в смысле приоритетов операций...
E>>Ну процитируй стандарт С++, где там вводятся приоритеты операций, пжлст... LMA>Я уже написал, что приоритетов там нет. Если что-то явно не вводится в стандарте, то это значит, что этого в том, о чем стандарт, нет?
Ну в целом да. LMA>Там и "оператора for" нет, о котором ты писал: E>>>Обычно этот список состоит из лдного пункта -- третьей части оператора for...
Это особенности переводной терминологии. Всего лишь. Правда я забыл, что ты по-русски и по-английски изъясняешься ещё хуже, чем на С++. Извини...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали: LMA>>Тратить больше своего времени на никому не нужные вещи... комментировать каждый чих... чтобы обычные программисты тонули в море ненужных им комментариев при просмотре моего кода... понятно... IMHO, вот это и есть саботаж.
E>Нет, писать ненужные комментарии на каждый чих тоже плохо. Программировать надо так, чтобы программа была и так ясна, без комментариев. E>А вот нетривиальные места надо комментировать. Ещё крайне полезно комментировать семантику методов полей и функций, если она не очевидна из их названий...
Так в том то и проблема, что тривиальность по-разному все понимают!
E>Таки в чём твоя цель? Помочь твоему клиенту или наоборот отомстить?
Моя цель — соблюсти свои интересы, а именно — работать продуктивно, вместо того, чтобы обучать отдельных представителей заказчика.
Re[14]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, shrecher, Вы писали:
S>Зачем писать ассерты в каждой функуци? Каждая задача ограничена в ресурсах (время и внимамние).
В каждой — не за чем.
S>На написание безполезных ассертов в тривиальных это уходит время и несколько отвлекаешься от поставленной задачи.
Безполезных assert'ов писать не надо. assert(true); — это не безполезный assert, это способ документирования. Или Вы не понимаете зачем документировать свой код?
S>Лучше это время затратить на написание комментариев
Потому что "assert(true);" — писать быстрее и это понятнее, чем "// no preconditions".
S>и написание еще одного или больше Unit теста.
unit-тесты — это не панацея, они тем полезнее, чем менее квалифицированные люди пишут код. В ряде случаев они почти бесполезны. Скорее всего, на написание качественного unit-теста уйдет существенно больше времени, чем на грамотное внесение assert'ов.
S>>>
S>>>a = 3;
S>>>b = 4;
S>>>assert( a < b ); // зачем?!
S>>>void foo( int a, int b )
S>>>{
S>>> assert( a < b ); // в принципе можно, но лучше по другому
S>>>}
S>>>error_cd foo( int a, int b )
S>>>{
S>>> if( ! (a < b) )
S>>> return assert(0), invalid_parameter;
S>>>}
S>>>
LMA>>К чему эти три примера плохого кода?
S>чем же они плохи?
Первые два assert'а вообще не нужны, третий пример вообще никуда не годится — это нужно переписывать.
Re[16]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, CreatorCray, Вы писали:
LMA>>Безполезных assert'ов писать не надо. assert(true); — это не безполезный assert, это способ документирования. Или Вы не понимаете зачем документировать свой код? CC>-1
А если по-существу?
LMA>>unit-тесты — это не панацея, они тем полезнее, чем менее квалифицированные люди пишут код. В ряде случаев они почти бесполезны. Скорее всего, на написание качественного unit-теста уйдет существенно больше времени, чем на грамотное внесение assert'ов. CC>Мсье продемонстрирует публике например как с помощью ассертов проверить что функциональность класса не сломана во время рефакторинга? Скажем на примере класса, который считает CRC32.
Во-первых, Ваша фраза звучит так, как будто я утверждал, что assert'ы — панацея! Если Вам угодно ПРИДУМЫВАТЬ ложные утверждения, а потом героически их опровергать — это Ваше дело, но мне бы не хотелось в этом участвовать.
Во-вторых, "проверить что функциональность класса не сломана во время рефакторинга" можно множеством способов, включая assert'ы, unit-тесты и пр.... и ни один из этих способов не будет гарантировать корректности кода, поэтому то, что Вы просите сделать — это обыкновенная провокация, на которую я не собираюсь поддаваться.
Re[18]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, Programador, Вы писали:
P>Здравствуйте, Programador, Вы писали:
P>>Здравствуйте, Юрий Жмеренецкий, Вы писали:
LMA>>>>>>
LMA>>>>>>delete p;
ЮЖ>>>LMA>>>p = 0;
LMA>>>>>>
ЮЖ>>>А выделенное — вообще UB P>мне так показалось что nulptr не отменяет преобразование 0 в указатель. nulptr конвертабельное значение какогото класса вводится дополнительно, на старые правила плевались, но рука вроде на основы не поднялась
После удаления с указателем формально ничего делать нельзя(разве что можно использовать в невычисляемых выражениях), так как его значение неопределено.
Здравствуйте, Erop, Вы писали: T>>Вроде даже у кого-то из классиков описан. E>AFAIK, всё верно, но думал долго
Времени не было, вот и "думал долго".
К тому же сказывается то, что я уже ~3 года не работаю с С++...
L>Объясните пожалуйста вот это посимвольно. Что-то я грузанулся...
Ну это такой панковский способ описать копируемый тип, с sizeof 1 и 2.
Теперь можно наваять каких-то функций с разными прототипами, которые возвращают тот или иной тип, после чего, можно написать выражение, тип которого будет зависеть от каких-то условий. После этого можно взять sizeof от этого выражения и узнать в CT верно какое-то условие или нет
IMHO это всё почти лишнее. Крайне редко бывает полезно.
Если же тебе не понятны сами типы, то Yes -- это ссылка на массив char из одного символа, а No на массив из двух.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
А>>Будет ли полностью освобождена память на которую указывает tranDets?
АШ>tranDets будет удален, а вот tranName — нет. Почитайте про оператор ','.
Если почитать про оператор ',' (например у отца-основателя в 6.2 Operator Summary), то можно выяснить, что у него низший приоритет, а потому утечет как раз tranDets.
Здравствуйте, CreatorCray, Вы писали:
CC>Хм. Какой хороший вопрос для собеседования!
А что в нём хорошего?
(Какие выводы по соискателе позволяет сделать тот или иной ответ на этот "хороший" вопрос?)
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, CreatorCray, Вы писали:
CC>Вопрос будет состоять из двух частей CC>1) Расскажите что произойдет в результате выполнения данного кода. CC>2) Объясните, почему оператор запятая лучше вообще не применять.
CC>Если на первый вопрос будет восторженный рассказ как это круто писать через "," — есть повод для беспокойства.
Запись "delete x, y, z;" есть способ повысить минимальный уровень требований к осуществляющему code review, если, конечно, писавший такое понимает, что он делает "delete x;". Т.е. способ не подпускать новичков к своему коду, что например может позволить вместо
assert(true); // no preconditions
писать просто
assert(true);
...если Вы понимаете о чем я. Что в конечном итоге может повысить производительность труда, между прочим. Понятно, что такое применимо не для всех проектов.
CC>Если будут резкие возражения по второму вопросу — "минус" собеседуемому. Принцип KISS это наше всё
Это уже не KISS, это уже VB-like.
CC>Если вдруг он не знает про "," — это как раз не страшно.
Это говорит о неполных знаниях языка. А что он еще в языке не знает? operator= позволяет тоже очень хорошо выстрелить себе в ногу — так если он и его не знает — тоже ничего страшного — пусть пользуется лучше функцией very_safe_assign?
CC>Но если вдруг ответит что память освободится по обоим указателям — серьезный "минус".
Здравствуйте, Programador, Вы писали:
P>а еще можно сделать tranDets++ гдето по пути P>чтоб от этого защитится ???лучше??? замутить так
1) IMHO, невменяемых кодеров допускать к коду на голых указателях нехорошо и даже опвсно.
2) Так
char * const tranDets = new char[128];
не хватит?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, LordMAD, Вы писали:
E>>А что, систем контроля версий и распределения прав вы не используете в работе? LMA>При чем тут это? Или у вас принято, чтобы программист пофамильно выбирал, кто будет смотреть на его код?
У разных программистов есть доступ к разным областям кода. При этом у кода как правило есть сотрудник, который отвечает за его текущее состояние и править его можно только при его участии либо при участии его начальника. А что, у вас как-то не так?
При этом права раздаёшь не ты, а менеджеры, которые управляют производством ПО...
LMA>А в чем саботаж?
В преднамеренном препятствовании коллективной разработке и снижении управяемости процесса производства ПО.
E>>Нахрена это вообще писать? Этот код эквивалентен пустому оператору. Если ты хочешь что-то написать читателю кода, а не компилятору, то от чего бы не воспользоваться человеческим языком, а не языком С++ ребусов?.. LMA>Нету к сожалению "человеческого" языка — есть русский, английский, немецкий, китайский и т.д. Все что я знаю о том, кто будет смотреть мой код — он должен знать C++. А тому, для кого "assert(true);" — не пустой звук, я готов помочь такими конструкциями понять мой код.
А ты даже и языка коллег не знаешь? А как вы общаетесь? На С++? Или таки речь про OpenSource?
Вообще-то в нормальной программае, кроме комментариев есть ещё и идентификаторы и документация и интерфейсные сообщения и имена файлов... Обычно, если языки разработчиков отличаются используют английский...
LMA>Нет. Сможет любой, знающий C++. Только действительно знающий, а не тот которому delete x, y; "не режет глаз" (и который не помнит какие у какого оператора приоритеты). И как я уже писал, тут многое зависит от проекта и не надо думать, что так нужно делать всегда и везде — есть проекты, в которых действительно стоит ненужные () расставлять и прочие вещи чисто для удобочитаемости. Тут вопрос скорее в том, какие проекты для себя выбирает человек.
Даже очень знающий С++ может не обратить внимания на твои художества. Кроме того, он может попробовать выяснить зачем такая хреновина написана. Я, например, требую от сотрудников, чтобы они избегали нестандартного кода. А если уж избежать не получилось, то должно быть понятно, зачем тут понадобилось извращаться...
Короче реально бы уволил без разговоров.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, LordMAD, Вы писали:
CC>>Смысла в этом коде нет никакого. А запутать может, особенно при беглом просмотре кода, когда глаз цепляется за начало строк. LMA>Смысл — в фейсконтроле. Чтобы не запутать — можно после кода в коментарии поставить смайлик.
Какой еще фейсконтроль в production коде???
CC>>А какой смысл их не подпускать? LMA>Чтобы вместо того, чтобы разжевывать очевидные (для людей схожей квалификации) вещи в своем коде, написать больше действительно полезного кода. LMA>Если не нравится пример, который я уже привел — могу привести другой
Дык пример не совсем про то. В жизни есть ситуации когда надо делать теми силами, что есть в наличии — других не будет.
Можно конечно сказать "а я с этими лохами педальными работать ваще не буду", сесть и ничего не делать. Но как по мне так это не вариант.
CC>>В свое время столкнулись с капитальной нехваткой квалифицированных С++шников. LMA>Не бывает нехватки квалифицированных кадров (по крайней мере, в РФ) — бывает желание найти квалифицированных кадров, готовых работать "за еду".
Это вопрос уже к руководству. Но и реально некоторый кадровый голод на вменяемых людей тогда был. (Не РФ )
CC>>Пришлось выбирать лучших из тех что были. И они должны были работать и желательно как можно более эффективно. LMA>Только вот сколько Вы потеряли на том, что квалифицированные ваши сотрудники были вынуждены работать с этими, Вы не посчитали?
Не я принимал такое решение.
CC>>А вот такие запутывалки только тормозят понимание кода. Следовательно их использование скорее во вред. LMA>Такие ловушки не надо разрасывать по всему коду — только на самом видном месте.
За намеренные ловушки я бы гнал из команды. Код должен быть чистым.
CC>>Вообще я лично оценивал всегда как большой плюс, если на пример какого нибудь головоломного заворота кода собеседуемый отвечал что за такой код надо больно бить по рукам и заставлять переписывать. Разумеется если такой ответ приходил на простую конструкцию то эффект был как раз противоположный. LMA>В общем случае — это сильно зависит от заворота и от того, в каком месте проекта он используется. В любом случае, так как все субьективно, WTFs/min равным нулю не бывает.
+1. Но к минимизации метрики "WTF per minute" надо стремиться ИМХО
CC>>ИМХО некоторые возможности С++ людям со слабой волей лучше и не знать вовсе — не удержатся от применения везде где только можно. Получившуюся помойку потом и сами часто не могут отладить/модифицировать. LMA>C++ — это язык для квалифицированных программистов. Всем будет лучше других держать подальше.
Оно то да, но вернемся на грешную землю в реальный мир: есть большой проект на С++. Надо его двигать и быстро. Квалифицированных людей нехватка, есть пучок недоквалифицированных. Т.е. теорию вроде знают но опыта нету. Что делать будем?
Вариантов реальных два:
1) Колбасить теми силами что есть на износ — высок риск фатального износа, что чревато...
2) Взять несколько толковых неопытных "на подхват", от них реально помощь бывает + через некоторое время при достаточной степени вменяемости можно вырастить прогера "достаточной" квалификации.
CC>>Это и надо выяснять на собеседовании + испытательный срок еще есть для особо клинических случаев. LMA>Вам очень везет, если Вы можете проводить собеседование для _каждого_, кто будет иметь дело с Вашим кодом. Могу только позавидовать.
Проводил собеседования в соседний отдел, где делали не ядро проекта а всякое сильно попроще. Ну и требования были на самом пределе разумного. Если кто попадался потолковее тогда уже мучали капитально. Впрочем я уже там полгода как не работаю.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[9]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, LordMAD, Вы писали:
LMA>+1. Только что есть "нестандартный код" — видимо у нас разные взгляды.
Страшная мысль: а coding standard у вас есть вообще? Или художники на вольном выпасе?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Roman Odaisky, Вы писали:
RO>Во-первых, он бывает нужен в for.
редко, но +1 RO>Во-вторых, это единственное выражение, позволяющее из потенциально-void-выражения сделать гарантированно-не-void. Применяется в SFINAE. Например:
Как часто это требуется в общем коде?
CC>>2) Объясните, почему оператор запятая лучше вообще не применять.
Не совсем верно выразился, согласен. Смысл был что применять строго там, где иначе никак.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[9]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, CreatorCray, Вы писали:
CC>>Так объясни какой сермяжный смысл ты в это вкладываешь? CC>>Для меня это пустой звук. Обычный комментарий пользы принес бы больше. LMA>assert (-ы) в начале функции являются проверкой на preconditions. "Пустой" указывает на то, что preconditions отсутствуют (а не забыты). Больше читайте Александра Степанова.
не любых preconditions, а только внутренних, например внутримодульных.
вместо assert(true) на мой взгляд лучше assert("no preconditions");
... CC>>Складывается впечатление что ты "предпочитаешь выражать свои мысли музыкой С++" (С) CC>>Это так? LMA>Язык C++ хорошо подходит для выражении моих мыслей — лучше других языков программирования. И я убежден, что использовать для выражения своих мыслей язык программирования — лучше, чем коментарии на естественном языке.
В коде с хорошими комментариями просто быстрее ориентироваться. Не нужно вчитываться, особенно в хитро закрученный код, чтобы найти интересующее место. А когда место найдено, тогда уже можно и детально разобраться. Код пишут один раз а читают сотни, а то и тысячи раз.
... LMA>Все верно, но это не значит, что он должен хорошо сопровождаться любым человеком. Если Ваш код не может сопровождать обезьяна, это же не значит, что его плохо сопровождать. Повторю: писать код, который легок для понимания квалифицированным программистом быстрее (а еще приятнее), чем код, понимаемый любым программистом.
Не любым человеком, а большинством программистов код должен пониматься без особых напрягов.
Лучше медленне писать, но быстрее сопровождать, быстрее править баги и быстрее дописывать новую фунциональность
Даже достаточно простой и понятный код со временем может очень усложниться. После того, как над ним поработают несколько программистов подряд в течение нескольких лет. Так что лишние "кучеряшки" в коде лишние
Здравствуйте, CreatorCray, Вы писали:
CC>Хм. Какой хороший вопрос для собеседования!
И все таки я настаиваю на том, что вопрос отличный.
Вон даже тут сколько всего интересного о собеседниках узнал
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, LordMAD, Вы писали:
LMA>Не передергивай. Когда код отправляется заказчику — контроль над тем, кто его будет видеть теряется почти всегда.
Так значит то, что код преднамеренно запутан, для того, чтобы саппорт могли осуществлоять более дорогие программисты -- это саботаж интересов заказчика и есть!!!
E>>Может быть ты таки пояснишь, начиная с какой квалификации программиста конструкции вроде "delete x, y, z" начинают облегчать понимание кода? LMA>Этой ереси не утверждалось! Читай внимательнее.
А я внимательно читал. Ты тут соловьём разливаешься, что не готов тратить усилия чтобы писать более понятный дня новичков код, и что надо писать delete x, y, z... Так что либо ты готов тратить усилия на более понятный для неновичков, либо вообще готов тратить усилия на то, чтобы код стал менее понятным для всех. Я думал о тебе хорошо, извини, ошибся.
E>>Моей квалификации, например, хватило бы только на то, чтобы понять "Осторожно! Код писали люди с альтернативным подходом к программированию!!! Дальше может быть любое г.!!!!". LMA>inductio incompleta
Пока что ты меня всё более убеждаешь в этом
E>>Правда мне пришлось сделать осмысленное усилие, когда я этот пример тут увидел. Вспомнить про операторы, про запятую и т. д. LMA>Так иногда полезно азы вспомнить
Но не в том случае, когда внезапно надо найти ошибку или добавить фичу в чужой, преднамеренно запутанный код
E>>Нормальный код на С++ я читаю не задумываясь о синтаксисе, примерно как текст по-русски или по-английски. LMA>То есть "нормальным" ты считаешь тот, код, который ты читаешь с листа? Так у нас практически нет противоречий!
Нет. У нас есть противоречие. Очень существенное. Я считаю, что понятность и читабельность кода надо повышать всегда. А ты, насколько я понял, призываешь её в некоторых случаях преднамеренно понижать...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, LordMAD, Вы писали:
LMA>Формально — практически любого. Хотелось бы узнать: а как может формулироваться стандарт, запрещающий такое?
Например, через запрет необоснованного (задаётся явным перечислением обоснованных случаев + разрешение начальника под его ответственность) использования запятой...
Кроме того ревью ещё бывают...
E>>Я бы даже
delete p, p = 0;
писать не стал бы... LMA>Ты считаешь, что это менее читабельно, чем LMA>
LMA>delete p;
LMA>p = 0;
LMA>
LMA>?
Да, считаю. Это необоснованное усложнение кода. Чтобы понять код с двумя операторами нужны толкьо базовые знания С++, а чтобы понять код с запятой, надо, по крайней мере, знать о точках следования. При этом код с запятой не проще написать и он не имеет никакх преимуществ для сколь угодно квалифицированного прграммиста. Так что он однозначно хуже.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[13]: Месье ещё и с формальной логикой не дружит?
Здравствуйте, LordMAD, Вы писали:
LMA>> Тождественных приоритету понятий достаточно. LMA>Непонятно слово "тождественных"? (выделил жирным)
Не совсем понятно. Приоритет операции -- это очень просто. Это частичное упорядочение на множестве операций, позволяющее сравнить операции, которые могут конкурировать между собой за приоритет. Если ещё проще, то это такая таблица, где каждой операции сопоставлен элемент упорядоченного множества. Число, например.
IMHO, если какая-то система понятий "тождественна" системе с приоритетами, то ты всегда можешь выписать такую таблицу и предъявить её.
Выпиши её, пожалуйста, для двух операций: "?:" и ","...
E>>Если у "?:" приоритет выше, чем у "," то поясни пожалуйста, почему вторая запятая обрабатывается так, словно она имеет более высокий приоритет, чем "?:" LMA>Я уже написал: "аргументами "?:" являются выражения?" (выделил жирным)
То есть ты ссылаешься на то, что корректность С++ выражений и порядок применения операций определяется не приоритетами, а некими грамматиками? Несводимыми, при этом, к понятию "приоритет операции"? Если так, то это обозначает, что приоритетов операций в С++ нет...
E>>Кроме того, тема об упоминании приоритетов в тексте стандарта тобой тоже не раскрыта... LMA>Разжевать что именно тождественное есть в стандарте? Кстати, про это есть в книге Страуструпа "Дизайн и эволюция.."
Нет. Разжёвывать не обязательно. Просто либо выпиши, пожалуйста, таки таблицу приоритетов, либо признавай что нет их... А тень на плетень рассуждениями о "тождественных понятиях" наводить не надо...
Пока что ты не прошёл лично мой ценз на соответствие уровня знаний С++ и уровня понтов по этому поводу
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[14]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, LordMAD, Вы писали:
LMA>>Ты считаешь, что это менее читабельно, чем LMA>>
LMA>>delete p;
LMA>>p = 0;
LMA>>
LMA>>? CC>Да. CC>Код через запятую не имеет никакого преимущества, а вероятность неверного понимания или сотворения в том месте неоднозначной ошибки только повышает.
как правило, вторая половина вообще не нужна, ее пишут для а вероятность неверного понимания или сотворения в ДРУГОМ месте неоднозначной ошибки только повышает.
А вероятность закопипастить, одно без другого повышается, таким образом код c ; менее писабелен
Re[18]: Программирование деятельность целенаправленная....
Здравствуйте, Erop, Вы писали:
E>А заказчикам нашим сочувствовать не надо. Мы производим весьма успешные коробочные продукты, и библиотеки и SDK и в целом всем всё нравится.
Я просто делаю выводы из твоих слов. То, что некие продукты продаются, ведь не означает, что при другом подходе они не продавались бы лучше, так что это никак не доказывает того, что твоим заказчикам не надо посочувствовать. Кстати сказать, если судить по твоим репликами, сильно сомневаюсь, чтобы такого подпустили бы к серьезным продуктам, без обид.
E>А мне показалось, что ты готов специально тратить усилия (то есть таки снижать свою производительность) для того, чтобы затруднить поддержку кода слишком низкоквалифицированными (по твоему мнению, а не по мнению заказчика) специалистами. То есть ты тратишь оплаченное заказчиком твоё рабочее время на удорожание саппорта. Ну и что что ты это только "в некоторых проектах" делаешь?
"Усилия" на написание одной-двух строчек кода? Ну да, заказчик потеряет на спичках, и выиграет на золоте.
E>И какова же эта существенная причина преднамаренно понижать качество кода?
E>Твоя патологическая боязнь критики?
У меня нет боязни критики, не суди по себе о других. Просто объяснять прописные истины желания нет. А тебе видать нравится из букваря цитаты в исходники вставлять, что у вас за килобайты кода примии дают?
E>Я не удивлён. Тебя я понял так, что НАДО,
Тогда читай внимательнее, я же выделил жирным шрифтом!
E>Обычно, когда критикуют, то приводят аргументы. И сразу ясно кто там чего стоит, и как критик и как автор.
Ага, в духе: почему у вас тут x*(x-1) — мы хотим цикл.
Может мне просто с новичками не везет, а у других таких проблем не бывает?
E>Если даже очень неквалифицированный программист найдёт в твоём прекраснейшем коде ошибку или недочёт какой -- то это будет на благо проекту!!!
+1. Только вот неквалифицированные ничего серьезного НИ РАЗУ не находили, зато времени на них уходит уйма.
Re[14]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, CreatorCray, Вы писали:
LMA>>Ты считаешь, что это менее читабельно, чем LMA>>
LMA>>delete p;
LMA>>p = 0;
LMA>>
LMA>>? CC>Да. CC>Код через запятую не имеет никакого преимущества, а вероятность неверного понимания или сотворения в том месте неоднозначной ошибки только повышает.
Если так рассуждать, то стоит вместо
a += b;
писать
a = a + b;
(конечно при условии одинакового результата, что верно в большинстве, наверное, случаев) потому, что для тех, кто "пришел" с других языков программирования так понятнее?
Re[15]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, LordMAD, Вы писали:
LMA>Хотелось бы увидеть список необоснованных случаев использования запятой!!! Думаю, если бы такой можно было составить заранее, компилятор на такие случаи уже бы ругался.
Наоборот. Список контекстов, где запятая уместна. Обычно этот список состоит из лдного пункта -- третьей части оператора for...
E>>Кроме того ревью ещё бывают... LMA>Дык о нем родимом и речь! Код прошел 10 code review "без сучка, без задоринки" разными людьми, его передали еще кому-нибудь. Он сегодня одно пиьсьмо написал — получил ссылку в "букварь", завтра — еще одно, послезавтра — еще...
Какой код? "delete x, y, z"?
E>>Да, считаю. Это необоснованное усложнение кода. Чтобы понять код с двумя операторами нужны толкьо базовые знания С++, а чтобы понять код с запятой, надо, по крайней мере, знать о точках следования. При этом код с запятой не проще написать и он не имеет никакх преимуществ для сколь угодно квалифицированного прграммиста. Так что он однозначно хуже. LMA>То, что одна мысль не размазана на две строки — это усложнение?
Если тебе так критично написать это на одной строке, напиши через ";". Так всё равно будет понятнее, чем с запятой.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[21]: Программирование деятельность целенаправленная....
Здравствуйте, LordMAD, Вы писали:
E>>Я тоже выделил слово НЕЛЬЗЯ... LMA>Тогда обоснуй — почему категорично НЕЛЬЗЯ?
Ну смотри выше по ветке
Стетная о доставших нашего д'Артаньяна НЕУЧАХ я опустил...
E>>IMHO, это говорит о том, что в вашей конторе очень плохо поставлена организация труда. Ко мне люди с улицы с вопросами "а почему вот у вас там написанно" не подходят... LMA>Речь идет о запросах от заказчика. И что нужно поменять в нашей конторе, чтобы такого не было?
Писать более понятный и более полно документированный код...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[17]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, LordMAD, Вы писали:
LMA>Ну хорошо, а то я уж боялся, что и LMA>
LMA>a += b += c;
LMA>
LMA>тебе не понравится.
И не зря боялся. Так писать НЕ НАДО!
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[17]: А разве в OpenSource бывают собеседования? :)
LMA>>Просто вторым и третьим аргументом оператора "?:" являются выражения, а не значения — что я уже писал выше.
E>Какие проблемы? Подставь вместо p и q какие-нибудь выражения
Дык там и так выражения!
LMA>>Я уже написал, что приоритетов там нет. Если что-то явно не вводится в стандарте, то это значит, что этого в том, о чем стандарт, нет? E>Ну в целом да. В целом — это в том смысле, что пока тебе удобно придерживаться этой точки зрения?
LMA>>Там и "оператора for" нет, о котором ты писал: E>>>>Обычно этот список состоит из лдного пункта -- третьей части оператора for... E>Это особенности переводной терминологии. Всего лишь. Правда я забыл, что ты по-русски и по-английски изъясняешься ещё хуже, чем на С++. Извини...
Слив защитан.
Re[19]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, Erop, Вы писали:
E>Я бы вообще сказал, что использовать результат оператора присваивания нужно только в том случае, если это действительно зачем-то нужно. И то сначала крепко подумать как бы этого избежать...
С фомулировкой "использовать x нужно только в том случае, если это действительно зачем-то нужно." вообще трудно не согласиться.
Не понятно только — зачем пытаться избегать тех конструкций, которые хороши всем, кроме того, что кто-то ВОЗМОЖНО их не поймет?
Здравствуйте, LordMAD, Вы писали:
LMA>Моя цель — соблюсти свои интересы, а именно — работать продуктивно, вместо того, чтобы обучать отдельных представителей заказчика.
После твоей "сливы" дальнейшее обсуждение не имеет смысла. IMHO ты плохо понимаешьчто такое "продуктивность"
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[20]: Месье ещё и с формальной логикой не дружит?
Здравствуйте, Erop, Вы писали:
E>Не, ну если у тебя аргументы таки закончились... E>Мне-то казалось, что тебя С++ интересует, а не сливы.
Ну давай обсудим твои "особенности переводной терминологии", которые заставили тебя слово statement перевести как ОПЕРАТОР, при том, что для языка C++ слово operator уже занято.
Здравствуйте, Erop, Вы писали:
LMA>>Моя цель — соблюсти свои интересы, а именно — работать продуктивно, вместо того, чтобы обучать отдельных представителей заказчика. E>После твоей "сливы" дальнейшее обсуждение не имеет смысла. IMHO ты плохо понимаешьчто такое "продуктивность"
Для меня это эффективное создание хорошо поддерживаемого, производительного и т.д. кода. Так что я упустил?
Re[16]: Месье ещё и с формальной логикой не дружит?
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, LordMAD, Вы писали:
E>>>Выпиши её, пожалуйста, для двух операций: "?:" и ","... E>>>>>Если у "?:" приоритет выше, чем у "," то поясни пожалуйста, почему вторая запятая обрабатывается так, словно она имеет более высокий приоритет, чем "?:"
LMA>>Я не пойму к чему это ты. Пусть у тебя приоритет "?:" получится 101, а у "," — 103 (меньшее значение соответствует более высокому приоритету), что дальше? Что ты хочешь сказать?
E>Я так тебя понял, что для этих двух операций таблица приоритетов выглядит так, как я выделил у тебя? E>Тогда, согласно этой таблице, в выражении
p, q ? p, q : p, q
скобки должны быть расставлены так
p, (q?p), (q:p), q
но это таки не верно. Это одна из причин, почему подход с приоритетами в С++ выражениях не работает. Работает подходь с грамматиками. E>Увы.
E>>>То есть ты ссылаешься на то, что корректность С++ выражений и порядок применения операций определяется не приоритетами, а некими грамматиками? Несводимыми, при этом, к понятию "приоритет операции"? Если так, то это обозначает, что приоритетов операций в С++ нет...
E>>>Пока что ты не прошёл лично мой ценз на соответствие уровня знаний С++ и уровня понтов по этому поводу LMA>>Взаимно. E>Ну процитируй стандарт С++, где там вводятся приоритеты операций, пжлст... E>Или ты намекаешь на то, что я слишком мало понтуюсь?
Не знаю как из стандарта доказать что что это well-formed и распарсить его.
Из грамматик а*б+С можно породить 2-мя способами. Где про это в стандарте , тем хуже для стандарта.
парсинг для бинарных операторов начинается с низких приоритетов. Поскольку ?: не бинарный его парсят перед, отдельно, также как унарные +-. То что его приоритет выше чем запятой означает что всетаки не так p, (q ? p, q : p), q а если был ниже то так (p, q) ?( p, q ): (p, q)
Всем известная таблица работает
Re[15]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, Programador, Вы писали:
P>Здравствуйте, CreatorCray, Вы писали:
CC>>Здравствуйте, LordMAD, Вы писали:
LMA>>>Ты считаешь, что это менее читабельно, чем LMA>>>
LMA>>>delete p;
LMA>>>p = 0;
LMA>>>
LMA>>>? CC>>Да. CC>>Код через запятую не имеет никакого преимущества, а вероятность неверного понимания или сотворения в том месте неоднозначной ошибки только повышает. P>как правило, вторая половина вообще не нужна, ее пишут для а вероятность неверного понимания или сотворения в ДРУГОМ месте неоднозначной ошибки только повышает. P>А вероятность закопипастить, одно без другого повышается, таким образом код c ; менее писабелен
А выделенное — вообще UB
Re[18]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, CreatorCray, Вы писали:
CC>По существу: assert который ничего не проверяет бесполезен и не несет никакой смысловой нагрузки..
Т.е. комментарии тоже бесполезны... ну-ну.
CC>Твоя надежда на то, что увидевший его догадается что других ассертов тут не надо — ничем не обоснована.
Да уж какая надежда на то, что они читали K&R, Страуструпа, Степанова или хотя бы Макконнелла... (Степанов как раз "assert(true);" использовал даже в своих статьях). Советую Вам почитать стандарты написания кода хотя бы одной приличной (не местечковой) конторы.
CC>По результатам проведенного еще в пятницу по аське "опроса" выяснилось, что в большинстве своем тот кто видит подобный ассерт считает автора параноиком и при первом же рефакторинге такие ассерты будут вычищены.
Точно! Тот же Степанов (см. выше об использовании такого в его статьях) — параноик! Что-то мне Ваш "опрос" очень напоминает, не сочтите за грубость, анекдот про конкурс красоты в гей-баре.
LMA>>>>unit-тесты — это не панацея, они тем полезнее, чем менее квалифицированные люди пишут код. В ряде случаев они почти бесполезны. Скорее всего, на написание качественного unit-теста уйдет существенно больше времени, чем на грамотное внесение assert'ов. CC>>>Мсье продемонстрирует публике например как с помощью ассертов проверить что функциональность класса не сломана во время рефакторинга? Скажем на примере класса, который считает CRC32. LMA>>Во-первых, Ваша фраза звучит так, как будто я утверждал, что assert'ы — панацея! CC>Ты утверждал, что юниттесты в ряде случаев почти бесполезны, что они нужнее для низкоквалифицированных разработчиков, что на них уходит больше времени чем на ассерты. Лично у меня создалось впечатление, что юниттестами аффтар вообще не пользуется и терпеть их не может. Зато крайне любит ассерты и применяет их везде и всюду, квадратно-гнездовым методом.
У Вас создалось ложное впечатление. Я ими пользуюсь, только не для того, чтобы проверить то, что можно проверить assert'ом.
CC>Опять 25! Повторюсь: как в приведенном примере (CRC32) с помощью assertов проверить не сломана ли функциональность?
Зачем проверять assert'ом то, что нужно проверить другими способами?
LMA>> unit-тесты и пр.... и ни один из этих способов не будет гарантировать корректности кода CC>Ну приехали...
А Вы считаете иначе?
Re[16]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, Юрий Жмеренецкий, Вы писали:
LMA>>>>
LMA>>>>delete p;
ЮЖ>LMA>>>p = 0;
LMA>>>>
ЮЖ>А выделенное — вообще UB
Erop, -1 ?
Мало того что значение указателя после удаления не определено, так он еще и перестает удовлетворять требованиям Copy Constructable и Assignable и фактически не может находится в стандартных контейнерах после удаления. Понятно что это формальности подобные i++ + ++i и на конкретных платформах это будет работать.
Re[17]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, Юрий Жмеренецкий, Вы писали:
ЮЖ>Мало того что значение указателя после удаления не определено, так он еще и перестает удовлетворять требованиям Copy Constructable и Assignable и фактически не может находится в стандартных контейнерах после удаления. Понятно что это формальности подобные i++ + ++i и на конкретных платформах это будет работать.
Тем не менее новое значение в переменную присвоить можно... В коде
int* p = new int( 5 );
delete p;
p = 0;
UB нет...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[22]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, Programador, Вы писали:
P>>Если комитет по недомыслию или для перестраховки написал такое P>>
P>>delete p;
P>>b=p; // UB
P>>
P>> то тут уж не знаешь смеяться или плакать
E>Это не для перестраховки. Могут быть платформы, на которых используется сегментная модель памяти. И для операций с адресами удобно использзовать специальные инструкции и регистры, обрабатывающие сегмент и смещение. E>При этом процессор, при загрузке указателя, может проверять, например, корректность id сегмента. Если после delete p последняя память в сегменте освободится менеджер может вернуть системе весь сегмент, а система просто разрушит его, сделав селектор сегмента невалидным. При попытке копирования невалидный селектор будет загружен в процесор и начнётся реальное UB... E>Затриать же невалидный указатель в памяти всё-таки безопасно...
Таки да, безопасно (: Assignable requirements сбили с толку.
Здравствуйте, Erop, Вы писали: T>>А можно пример, где оператор "ведёт себя неожиданно" в синтаксическом плане? T>>Мне как-то всё время казалось, что С++ довольно "кудряв" в синтаксисе объявлений, но вот операторы всегда казались довольно простой и логичной в синтаксисе областью эхотага.
E>Вот, ещё придумалось...
всё ли тут хорошо?
Тут как раз "кудрявый" синтаксис обявления скрывает то, что вызывается new[]. Так что это вполне классический пример неявной ошибки удаления массива не массивным delete.
Вроде даже у кого-то из классиков описан.
... << RSDN@Home 1.2.0 alpha 4 rev. 1065>>
delete[]
От:
Аноним
Дата:
19.06.08 12:53
Оценка:
Законен ли такой код?
char* tranName = new char [128];
char* tranDets = new char [1024];
...
delete[] tranName, tranDets;
Будет ли полностью освобождена память на которую указывает tranDets?
А>>>Будет ли полностью освобождена память на которую указывает tranDets?
АШ>>tranDets будет удален, а вот tranName — нет. Почитайте про оператор ','. B>Если почитать про оператор ',' (например у отца-основателя в 6.2 Operator Summary), то можно выяснить, что у него низший приоритет, а потому утечет как раз tranDets. B>
Да, действительно, я не принял в расчет приоритет.
Здравствуйте, Bell, Вы писали:
АШ>>tranDets будет удален, а вот tranName — нет. Почитайте про оператор ','. B>Если почитать про оператор ',' (например у отца-основателя в 6.2 Operator Summary), то можно выяснить, что у него низший приоритет, а потому утечет как раз tranDets. B>
5.18 Comma operator [expr.comma]
1 The comma operator groups left-to-right.
A pair of expressions separated by a comma is evaluated left-to-right and the value of the left expression is discarded. The lvalue-to-rvalue (4.1), array-to-pointer (4.2), and function-to-pointer (4.3) standard conversions are not applied to the left expression. All side effects (1.9) of the left expression, except for the destruction of temporaries (12.2), are performed before the evaluation of the right expression. The type and value of the result are the type and value of the right operand; the result is an lvalue if its right operand is.
кстати можно написать и так
void zx()
{ char* tranName = new char [128];
char* tranDets = new char [1024];
(delete[] tranName,delete[] tranDets);
}
хороший вопрос для собеседования — какой тип у того что в скобках?
Здравствуйте, Erop, Вы писали:
E> Какие выводы по соискателе позволяет сделать тот или иной ответ на этот "хороший" вопрос?
Вопрос будет состоять из двух частей
1) Расскажите что произойдет в результате выполнения данного кода.
2) Объясните, почему оператор запятая лучше вообще не применять.
Если на первый вопрос будет восторженный рассказ как это круто писать через "," — есть повод для беспокойства.
Если будут резкие возражения по второму вопросу — "минус" собеседуемому. Принцип KISS это наше всё
Если вдруг он не знает про "," — это как раз не страшно.
Но если вдруг ответит что память освободится по обоим указателям — серьезный "минус".
Где то так...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, merk, Вы писали:
M>я например боюсь с++ экспертов, они как нааачнут работать крупными мазками, что потом не разберешься, что это...программа ваще или картина — "неизвестная с огурцом".
Здравствуйте, Erop, Вы писали:
E>IMHO ответ "хрен его знает, я так не пишу, возможно будет вот так, а возможно и так..." тоже подходит
За "я так не пишу" — жирный плюс
А вот "может быть так, а может эдак", если про удаление обоих заикнется — тогда все таки минус. Ну базовые ж вещи! Тем более при прямой работе с памятью.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, LordMAD, Вы писали:
LMA>Запись "delete x, y, z;" есть способ повысить минимальный уровень требований к осуществляющему code review, если, конечно, писавший такое понимает, что он делает "delete x;".
Смысла в этом коде нет никакого. А запутать может, особенно при беглом просмотре кода, когда глаз цепляется за начало строк.
LMA> Т.е. способ не подпускать новичков к своему коду, что например может позволить вместо
А какой смысл их не подпускать? В свое время столкнулись с капитальной нехваткой квалифицированных С++шников. Пришлось выбирать лучших из тех что были. И они должны были работать и желательно как можно более эффективно.
А вот такие запутывалки только тормозят понимание кода. Следовательно их использование скорее во вред.
LMA>Что в конечном итоге может повысить производительность труда, между прочим.
Несколько сомнительно, ну да ладно.
CC>>Если будут резкие возражения по второму вопросу — "минус" собеседуемому. Принцип KISS это наше всё LMA>Это уже не KISS, это уже VB-like.
Что именно понимается под "это"? Почему VB-like?
CC>>Если вдруг он не знает про "," — это как раз не страшно. LMA>Это говорит о неполных знаниях языка.
Разумеется. Но неполнота бывает разной. Эта как раз не фатальна — можно быстро объяснить как понимать такой код, заодно вбить в голову что самому так писать не следует.
Вообще я лично оценивал всегда как большой плюс, если на пример какого нибудь головоломного заворота кода собеседуемый отвечал что за такой код надо больно бить по рукам и заставлять переписывать. Разумеется если такой ответ приходил на простую конструкцию то эффект был как раз противоположный.
ИМХО некоторые возможности С++ людям со слабой волей лучше и не знать вовсе — не удержатся от применения везде где только можно. Получившуюся помойку потом и сами часто не могут отладить/модифицировать.
LMA> А что он еще в языке не знает?
Это и надо выяснять на собеседовании + испытательный срок еще есть для особо клинических случаев.
CC>>Но если вдруг ответит что память освободится по обоим указателям — серьезный "минус". LMA>Я бы сформулировал более жестко.
+1
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Впрочем я тут круче пример придумал: CC>
CC> char *foo = new char[100];
CC> char *bar = new char[100];
CC> delete [] (foo,bar); // ЫЫЫЫЫ!!!
CC>
Не сильно-то он и круче. Насколько понимаю, это эквивалентно записи delete [] bar.
Не вижу смысла вообще обсуждать подобные клинические случаи.
IMHO delete в таком виде, в каком он представлен в этих примерах быть не должно, потому как smart pointer'ы более exception safe.
Здравствуйте, php-coder, Вы писали:
PC>Не сильно-то он и круче.
Не сильно, но я тут опросик по аське утворил — некоторых он заставил посомневаться и задуматься.
Показательно между прочим.
PC>Насколько понимаю, это эквивалентно записи delete [] bar.
Почти. Ты про foo забыл, хоть оно и выбросится компилером.
А объяснить почему именно так будет можешь?
PC>Не вижу смысла вообще обсуждать подобные клинические случаи.
Ну например потому, что на таких клинических случаях часто построены вопросы на собеседованиях и brainbench.
Да и просто мне поностальгировать захотелось
PC>IMHO delete в таком виде, в каком он представлен в этих примерах быть не должно
Не должно, факт.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Знать надо формат вызова delete. И как оно работает. Надеюсь с этим ты согласен?
Ну знать надо, но не все же тонкости. Вернее отсутсвие всех мыслемых тонкостей.
delete вообще редко нужная конструкция, а уж знание на зубок всех возможных исключений в описании этой конструкции в стандарте -- совсем странное требование. Я к тому, что вполне могло бы и быть что-то такое, с запятой в delete. Скажем вторые/третьи аргументы в operator delete могли бы так передавать, например...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, CreatorCray, Вы писали:
CC>Не сильно, но я тут опросик по аське утворил — некоторых он заставил посомневаться и задуматься. CC>Показательно между прочим.
Я думаю потому, что похоже на запись
new( bufffer ) T;
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, CreatorCray, Вы писали:
PC>>Насколько понимаю, это эквивалентно записи delete [] bar. CC>Почти. Ты про foo забыл, хоть оно и выбросится компилером. CC>А объяснить почему именно так будет можешь?
Конечно. Всё что в скобках будет вычисляться первым. Оператор запятая вернёт свой последний аргумент, в первом аргументе вычисляться ничего не будет, так что в итоге к в качестве аргумента delete поступит bar.
Re[6]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, Erop, Вы писали:
E>А что, систем контроля версий и распределения прав вы не используете в работе?
При чем тут это? Или у вас принято, чтобы программист пофамильно выбирал, кто будет смотреть на его код?
E>Я бы такие ПРЕДНАМЕРЕННЫЕ действия воспринимал как преднамеренный саботаж, и немедленно бы уволил...
А в чем саботаж?
LMA>>писать просто LMA>>
LMA>>assert(true);
LMA>>
E>Нахрена это вообще писать? Этот код эквивалентен пустому оператору. Если ты хочешь что-то написать читателю кода, а не компилятору, то от чего бы не воспользоваться человеческим языком, а не языком С++ ребусов?..
Нету к сожалению "человеческого" языка — есть русский, английский, немецкий, китайский и т.д. Все что я знаю о том, кто будет смотреть мой код — он должен знать C++. А тому, для кого "assert(true);" — не пустой звук, я готов помочь такими конструкциями понять мой код.
E>В целом я понимаю. Ты о генерации С++ кода, который никто кроме тебя поддерживать не сможет.
Нет. Сможет любой, знающий C++. Только действительно знающий, а не тот которому delete x, y; "не режет глаз" (и который не помнит какие у какого оператора приоритеты). И как я уже писал, тут многое зависит от проекта и не надо думать, что так нужно делать всегда и везде — есть проекты, в которых действительно стоит ненужные () расставлять и прочие вещи чисто для удобочитаемости. Тут вопрос скорее в том, какие проекты для себя выбирает человек.
Re[8]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, Erop, Вы писали:
LMA>>При чем тут это? Или у вас принято, чтобы программист пофамильно выбирал, кто будет смотреть на его код? E>У разных программистов есть доступ к разным областям кода. При этом у кода как правило есть сотрудник, который отвечает за его текущее состояние и править его можно только при его участии либо при участии его начальника. А что, у вас как-то не так? E>При этом права раздаёшь не ты, а менеджеры, которые управляют производством ПО...
Откуда взялось "править"? Речь пока что шла о просмотре кода. Заказчик может передать код кому-угодно по своему усмотрению для чего угодно, это уже не моя проблема. Но моя проблема, чтобы он был читаем квалифицированным программистом из любой страны.
LMA>>А в чем саботаж? E>В преднамеренном препятствовании коллективной разработке и снижении управяемости процесса производства ПО.
А никакого припятствования! Речь идет лишь о том, что люди должны иметь определенный уровень квалификации.
E>А ты даже и языка коллег не знаешь?
Реально обычно догадываюсь, но я на многих из этих языков не говорю.
E>А как вы общаетесь?
Я со ВСЕМИ колегами не общаюсь напрямую.
E>Вообще-то в нормальной программае, кроме комментариев есть ещё и идентификаторы и документация и интерфейсные сообщения и имена файлов... Обычно, если языки разработчиков отличаются используют английский...
Где на C++ нельзя, приходится английский — мир не идеален.
E>Даже очень знающий С++ может не обратить внимания на твои художества.
Так это моя задача, чтобы знающий обратил — это не сложно.
E>Кроме того, он может попробовать выяснить зачем такая хреновина написана.
Always welcome. Но если что — пусть не удивляется, если "опущу".
E>Я, например, требую от сотрудников, чтобы они избегали нестандартного кода. А если уж избежать не получилось, то должно быть понятно, зачем тут понадобилось извращаться...
+1. Только что есть "нестандартный код" — видимо у нас разные взгляды.
Здравствуйте, php-coder, Вы писали:
PC>Здравствуйте, CreatorCray, Вы писали:
PC>>>Насколько понимаю, это эквивалентно записи delete [] bar. CC>>Почти. Ты про foo забыл, хоть оно и выбросится компилером. CC>>А объяснить почему именно так будет можешь?
PC>Конечно. Всё что в скобках будет вычисляться первым. Оператор запятая вернёт свой последний аргумент, в первом аргументе вычисляться ничего не будет, так что в итоге к в качестве аргумента delete поступит bar.
Правильно. Но как оказалось с запятой сталкивались не все...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Erop, Вы писали:
E>Ну знать надо, но не все же тонкости. Вернее отсутсвие всех мыслемых тонкостей. E>delete вообще редко нужная конструкция, а уж знание на зубок всех возможных исключений в описании этой конструкции в стандарте -- совсем странное требование. Я к тому, что вполне могло бы и быть что-то такое, с запятой в delete. Скажем вторые/третьи аргументы в operator delete могли бы так передавать, например...
Перестань меня удивлять! Я почему то до сих пор считал что ты знаешь С++ на достаточном уровне...
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[7]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, LordMAD, Вы писали:
LMA>А тому, для кого "assert(true);" — не пустой звук, я готов помочь такими конструкциями понять мой код.
Так объясни какой сермяжный смысл ты в это вкладываешь?
Для меня это пустой звук. Обычный комментарий пользы принес бы больше.
LMA>Нет. Сможет любой, знающий C++. Только действительно знающий
Мсье нескромен
Складывается впечатление что ты "предпочитаешь выражать свои мысли музыкой С++" (С)
Это так?
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, Erop, Вы писали: E>Ну знать надо, но не все же тонкости. Вернее отсутсвие всех мыслемых тонкостей.
В данном вопросе нужно знать только то, что и delete и , операторы, и представлять отношение их приоритетов.
E>delete вообще редко нужная конструкция, а уж знание на зубок всех возможных исключений в описании этой конструкции в стандарте -- совсем странное требование.
О каких исключениях идёт речь?
E> Я к тому, что вполне могло бы и быть что-то такое, с запятой в delete. Скажем вторые/третьи аргументы в operator delete могли бы так передавать, например...
А можно пример, где оператор "ведёт себя неожиданно" в синтаксическом плане?
Мне как-то всё время казалось, что С++ довольно "кудряв" в синтаксисе объявлений, но вот операторы всегда казались довольно простой и логичной в синтаксисе областью эхотага.
Здравствуйте, CreatorCray, Вы писали:
CC>Какой еще фейсконтроль в production коде???
Иногда могу пошалить. Конечно, если буду уверен, что другие воспримут это именно как шутку.
CC>Дык пример не совсем про то. В жизни есть ситуации когда надо делать теми силами, что есть в наличии — других не будет. CC>Можно конечно сказать "а я с этими лохами педальными работать ваще не буду", сесть и ничего не делать. Но как по мне так это не вариант.
Я же не говорю, что так нужно делать во всех проектах. Но бываю же такие проекты, когда с этим все в порядке. Очевидно, что это вопрос лояльности, и я себя не могу назвать нелояльным человеком по отношению к тем фирмам, которые мне деньги платят, но если бы мне пришлось все время с новичками работать — я бы взвыл.
CC>За намеренные ловушки я бы гнал из команды. Код должен быть чистым.
В теории — да, но мир не идеален, а это всего лишь своего рода самозащита.
CC>+1. Но к минимизации метрики "WTF per minute" надо стремиться ИМХО
Да, безусловно.
CC>Оно то да, но вернемся на грешную землю в реальный мир: есть большой проект на С++. Надо его двигать и быстро. Квалифицированных людей нехватка, есть пучок недоквалифицированных. Т.е. теорию вроде знают но опыта нету. Что делать будем? CC>Вариантов реальных два: CC>1) Колбасить теми силами что есть на износ — высок риск фатального износа, что чревато... CC>2) Взять несколько толковых неопытных "на подхват", от них реально помощь бывает + через некоторое время при достаточной степени вменяемости можно вырастить прогера "достаточной" квалификации.
Но это же не значит, что те, которые "на подхват" должны ковыряться в Вашем коде.
Здравствуйте, LordMAD, Вы писали:
LMA>Но это же не значит, что те, которые "на подхват" должны ковыряться в Вашем коде.
Менять они его права не имели. Но понимать его они должны без отвлечения меня от работы.
И простота понимания кода играет тут существенную роль
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[8]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, CreatorCray, Вы писали:
CC>Так объясни какой сермяжный смысл ты в это вкладываешь? CC>Для меня это пустой звук. Обычный комментарий пользы принес бы больше.
assert (-ы) в начале функции являются проверкой на preconditions. "Пустой" указывает на то, что preconditions отсутствуют (а не забыты). Больше читайте Александра Степанова.
LMA>>Нет. Сможет любой, знающий C++. Только действительно знающий CC>Мсье нескромен
Я про себя ничего не писал. Но я действительно считаю, что если человек не знает приоритеты операторов в C++, то язык он не знает. Некоторых других языков программирования это, кстати, касается в меньшей степени.
CC>Складывается впечатление что ты "предпочитаешь выражать свои мысли музыкой С++" (С) CC>Это так?
Язык C++ хорошо подходит для выражении моих мыслей — лучше других языков программирования. И я убежден, что использовать для выражения своих мыслей язык программирования — лучше, чем коментарии на естественном языке.
Re[10]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, CreatorCray, Вы писали:
CC>Страшная мысль: а coding standard у вас есть вообще? Или художники на вольном выпасе?
Конечно есть. Но мои личные стандарты кодирования более жесткие, чем в тех проектах, в которых я участвую. Стандарты кодирования проектов разные — это зависит от проекта.
Здравствуйте, sc, Вы писали:
LMA>>Еще раз: тут нет восприпятствования пониманию. Совеобразная "проверка на вшивость". Если я получу запрос по данной строке — просто буду иметь аргумент, касающийся квалификации инициатора запроса до того, как он будет слать другие запросы. Ну нет у меня желания _каждому_ объяснять что из себя представляет та или иная конструкция языка или алгоритм. Это не означает, что если кто-то поинтересуется для самообразования — то я не объясню. sc>Противоречие
В чем? Если я не готов объяснять каждому, это не значит, что не объясняю кому-то.
LMA>>А кто спорит? Но тратить время _в каждом проекте_, на то, чтобы с кодом мог разобраться любой — не стоит. Просто я ценю свое время. sc>А время других? Код пишется дни, недели, месяцы а сопровождается годами. Поэтому вожно, чтобы код хорошо сопровождался, иначе затраты на его поддержку со временем будут больше, чем затраты на его переписывание. Если нравится писать в мусорку, тогда действительно стоит писать как можно более запутанный код. Хотя в больших и сложных проектах и без этого проблем хватает.
Все верно, но это не значит, что он должен хорошо сопровождаться любым человеком. Если Ваш код не может сопровождать обезьяна, это же не значит, что его плохо сопровождать. Повторю: писать код, который легок для понимания квалифицированным программистом быстрее (а еще приятнее), чем код, понимаемый любым программистом.
Здравствуйте, CreatorCray, Вы писали:
CC>Но понимать его они должны без отвлечения меня от работы.
Странное требование — чтобы они могли его понимать. Зачем? Может стоит просто подумать о другой декомпозиции?
Re[9]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, LordMAD, Вы писали:
LMA>"Пустой" указывает на то, что preconditions отсутствуют (а не забыты).
Всего то?..
CC>>Складывается впечатление что ты "предпочитаешь выражать свои мысли музыкой С++" (С) CC>>Это так? LMA>Язык C++ хорошо подходит для выражении моих мыслей — лучше других языков программирования. И я убежден, что использовать для выражения своих мыслей язык программирования — лучше, чем коментарии на естественном языке.
Спасибо.
Вопросов больше не имею.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, CreatorCray, Вы писали:
CC>Перестань меня удивлять! Я почему то до сих пор считал что ты знаешь С++ на достаточном уровне...
Про весь С++ не скажу, но про operator delete знаю, возможно вообще всё.
При этом, судя по опыту обучения людей языку, многие люди имеют склонность ожидать, что у operator delete есть какие-нибудь особые формы, анологичные new( buffer ) T; или вызовам других operator new с дополнительными аргументами. IMHO в незнаии того, как там оно на самом деле большого вреда нет. Правда я в таких случаях, прошу человека почитать стандарт и выяснить ответ самостоятельно... Всё польза.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Tonal-, Вы писали:
T>Мне как-то всё время казалось, что С++ довольно "кудряв" в синтаксисе объявлений, но вот операторы всегда казались довольно простой и логичной в синтаксисе областью эхотага.
Проверим, что тут всё просто?
Ты, наверное знаешь, что код delete p; вызовет деструктор *p, а потом позовёт operator delete( p );
1) Как вызвать operator delete( void*, size_t );
2) Как вызвать operator delete( void*, const char* );
3) Как вызывать operator delete( int );
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, LordMAD, Вы писали:
LMA>Странное требование — чтобы они могли его понимать. Зачем? Может стоит просто подумать о другой декомпозиции?
Например при его использовании и отладки базирующегося на нём кода...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Tonal-, Вы писали:
T>А можно пример, где оператор "ведёт себя неожиданно" в синтаксическом плане? T>Мне как-то всё время казалось, что С++ довольно "кудряв" в синтаксисе объявлений, но вот операторы всегда казались довольно простой и логичной в синтаксисе областью эхотага.
Вот, ещё придумалось...
void foo()
{
typedef std::string Strings[5];
delete new Strings;
}
всё ли тут хорошо?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[11]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, LordMAD, Вы писали:
CC>>Страшная мысль: а coding standard у вас есть вообще? Или художники на вольном выпасе? LMA>Конечно есть. Но мои личные стандарты кодирования более жесткие, чем в тех проектах, в которых я участвую. Стандарты кодирования проектов разные — это зависит от проекта.
и что? delete x, y, z; стандарты какого проекта позволяют писать?
Я бы даже
delete p, p = 0;
писать не стал бы...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, LordMAD, Вы писали:
LMA>Повторю: писать код, который легок для понимания квалифицированным программистом быстрее (а еще приятнее), чем код, понимаемый любым программистом.
Я, кажется, понял, в чём корень разногласий. Чем больше людей может легко понимать и поддерживать код, решающий какую-то конкретную задачу, тем качественнее этот код написан.
Конечно понятно, что более качественный код писать сложнее и дольше. В этом ничего удивительного нет. И при тарет ресурсов на разработку надо искать комперомисс между трудозатратами и качеством кода.
Но преднамеренно тратить ресурсы на осознанное снижение качества кода -- всё таки это явный и злонамеренный саботаж!
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, LordMAD, Вы писали:
LMA>Я про себя ничего не писал. Но я действительно считаю, что если человек не знает приоритеты операторов в C++, то язык он не знает. Некоторых других языков программирования это, кстати, касается в меньшей степени.
Кстати, не хочу тебя расстраивать, но в С++ приоритетов у операторов нет
Если тебе так не кажется, то можешь расставить приоритеты в этом вот выражении:
p, q ? p, q : p, q
Либо найти перечень приоритетов в стандарте С++...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, sc, Вы писали:
sc>Не любым человеком, а большинством программистов код должен пониматься без особых напрягов.
Это красивые слова — не более того. Ни мне, ни Вам не может быть известно то, какой код должен пониматься _большинством_ программистов — просто потому, что это потребует регулярного анализа того, какая квалификация сейчас у _большинства_ программистов. Я стараюсь ориентировать написание кода на программистов определенных _квалификаций_, а не исходя из количества программистов. При этом ожидаемый уровень квалификации определяется моими предположениями о том, что из себя представляют программисты, которые возможно будут иметь дело с моим кодом.
sc>Лучше медленне писать, но быстрее сопровождать, быстрее править баги и быстрее дописывать новую фунциональность sc>Даже достаточно простой и понятный код со временем может очень усложниться. После того, как над ним поработают несколько программистов подряд в течение нескольких лет. Так что лишние "кучеряшки" в коде лишние
К чему это очевидные вещи тут писать? С этом кто-то спорил?
Re[10]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, LordMAD, Вы писали:
LMA>>Все верно, но это не значит, что он должен хорошо сопровождаться любым человеком. Если Ваш код не может сопровождать обезьяна, это же не значит, что его плохо сопровождать. E>Не, ну если у вас и обезьяны доступ к коду имеют, то мне всё больше интересно где ты таки работаешь?
Не передергивай. Когда код отправляется заказчику — контроль над тем, кто его будет видеть теряется почти всегда.
E>Может быть ты таки пояснишь, начиная с какой квалификации программиста конструкции вроде "delete x, y, z" начинают облегчать понимание кода?
Этой ереси не утверждалось! Читай внимательнее.
E>Моей квалификации, например, хватило бы только на то, чтобы понять "Осторожно! Код писали люди с альтернативным подходом к программированию!!! Дальше может быть любое г.!!!!".
inductio incompleta
E>Правда мне пришлось сделать осмысленное усилие, когда я этот пример тут увидел. Вспомнить про операторы, про запятую и т. д.
Так иногда полезно азы вспомнить
E>Нормальный код на С++ я читаю не задумываясь о синтаксисе, примерно как текст по-русски или по-английски.
То есть "нормальным" ты считаешь тот, код, который ты читаешь с листа? Так у нас практически нет противоречий!
Re[12]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, Erop, Вы писали:
E>и что? delete x, y, z; стандарты какого проекта позволяют писать?
Формально — практически любого. Хотелось бы узнать: а как может формулироваться стандарт, запрещающий такое?
E>Я бы даже
delete p, p = 0;
писать не стал бы...
Ты считаешь, что это менее читабельно, чем
Здравствуйте, Erop, Вы писали:
E>Я, кажется, понял, в чём корень разногласий. Чем больше людей может легко понимать и поддерживать код, решающий какую-то конкретную задачу, тем качественнее этот код написан. E>Конечно понятно, что более качественный код писать сложнее и дольше. В этом ничего удивительного нет. И при тарет ресурсов на разработку надо искать комперомисс между трудозатратами и качеством кода.
Именно. Только ты пропагандируешь теоретический максимум, а в реальном проекте идешь на компромисс; а я предлагаю для реального проекта оговорить компромисс в качестве стандарта, чтобы потом ни у кого не возникало соблазна ничем не обоснованную лажу выдавать за компромисс.
Здравствуйте, Erop, Вы писали:
E>Кстати, не хочу тебя расстраивать, но в С++ приоритетов у операторов нет
Тождественных приоритету понятий достаточно.
E>Если тебе так не кажется, то можешь расставить приоритеты в этом вот выражении:
p, q ? p, q : p, q
А что тебе здесь не понятно: то, что "?:" имеет больший приоритет, чем ",", или что агрументами "?:" являются варажения?
Здравствуйте, LordMAD, Вы писали:
LMA>Именно. Только ты пропагандируешь теоретический максимум, а в реальном проекте идешь на компромисс; а я предлагаю для реального проекта оговорить компромисс в качестве стандарта, чтобы потом ни у кого не возникало соблазна ничем не обоснованную лажу выдавать за компромисс.
Да? Ну так и поясни тогда "Кому конструкция delete x, y, z" облегчает жизнь? С точки зрения компилятора она бессмысленна. С точки зрения новичка она не понятно, с точки зрения не новичка она предумышленное запутываение кода. Так и при чём тут компромисс? Это компромисс между чем и чем?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, LordMAD, Вы писали:
E>>Если тебе так не кажется, то можешь расставить приоритеты в этом вот выражении:
p, q ? p, q : p, q
LMA>А что тебе здесь не понятно: то, что "?:" имеет больший приоритет, чем ",", или что агрументами "?:" являются варажения?
Мне-то как раз всё понятно. Но я и не утверждаю, что в С++ у операций есть приоритеты...
Если у "?:" приоритет выше, чем у "," то поясни пожалуйста, почему вторая запятая обрабатывается так, словно она имеет более высокий приоритет, чем "?:"
Кроме того, тема об упоминании проритетов в тексте стандарта тобой тоже не раскрыта...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Так значит то, что код преднамеренно запутан, для того, чтобы саппорт могли осуществлоять более дорогие программисты -- это саботаж интересов заказчика и есть!!!
Не "запутан", а не разжеван. Если это приводит к экономии денег заказчика (т.к. производительность работы квалифицированных программистов возрастает) — это саботаж? Ну тогда — я сочувствую вашим заказчикам!
LMA>>Этой ереси не утверждалось! Читай внимательнее. E>А я внимательно читал. Ты тут соловьём разливаешься, что не готов тратить усилия чтобы писать более понятный дня новичков код,
Если ты не видишь разницы, между тем, что я не готов специально снижать свою производительность в НЕКОТОРЫХ проетках (что и было бы саботажем, IMHO) и тем, что пишешь ты — с тобой разговаривать не о чем!
E>и что надо писать delete x, y, z...
Ты будешь удивлен, но МОЖНО и НАДО — это не одно и тоже!
E> Так что либо ты готов тратить усилия на более понятный для неновичков, либо вообще готов тратить усилия на то, чтобы код стал менее понятным для всех. Я думал о тебе хорошо, извини, ошибся.
Не понял твоей мысли.
E>>>Моей квалификации, например, хватило бы только на то, чтобы понять "Осторожно! Код писали люди с альтернативным подходом к программированию!!! Дальше может быть любое г.!!!!". LMA>>inductio incompleta E>Пока что ты меня всё более убеждаешь в этом
Как я уже писал, и в хорошем коде WTFs/min равным нулю не бывает, если конечно не свой собственный код человек смотрит (шучу). Я не вижу ничего криминального в том, что я в каком-то куске кода добавлю в свои ворота WTF (хотя, как я уже писал, уверен, что если смайлик поставлю — коллеги меня поймут), а взамен получу реальную пользу в виде доводов против того, чтобы _это_ критиковало мой код.
E>Но не в том случае, когда внезапно надо найти ошибку или добавить фичу в чужой, преднамеренно запутанный код
Так нужно такие вещи не глубоко в код прятать, а на самом видном месте (как я тоже уже писал), поэтому к такому, как ты пишешь это не приведет.
E>Нет. У нас есть противоречие. Очень существенное. Я считаю, что понятность и читабельность кода надо повышать всегда. А ты, насколько я понял, призываешь её в некоторых случаях преднамеренно понижать...
Только если на это есть существенная причина, которая с лихвой покроет недостатки такой шалости!
Здравствуйте, Erop, Вы писали:
E>Да? Ну так и поясни тогда "Кому конструкция delete x, y, z" облегчает жизнь? С точки зрения компилятора она бессмысленна. С точки зрения новичка она не понятно, с точки зрения не новичка она предумышленное запутываение кода. Так и при чём тут компромисс? Это компромисс между чем и чем?
Прочти выше для чего я предлагал использовать такую конструкцию — для фейсконтроля. Если ты предложишь лучший способ достичь такой же цели — возможно, я соглашусь.
Здравствуйте, Erop, Вы писали:
LMA> Тождественных приоритету понятий достаточно.
LMA>>А что тебе здесь не понятно: то, что "?:" имеет больший приоритет, чем ",", или что агрументами "?:" являются варажения?
E>Мне-то как раз всё понятно. Но я и не утверждаю, что в С++ у операций есть приоритеты...
Непонятно слово "тождественных"? (выделил жирным)
E>Если у "?:" приоритет выше, чем у "," то поясни пожалуйста, почему вторая запятая обрабатывается так, словно она имеет более высокий приоритет, чем "?:"
Я уже написал: "агрументами "?:" являются варажения?" (выделил жирным)
E>Кроме того, тема об упоминании проритетов в тексте стандарта тобой тоже не раскрыта...
Разжевать что именно тождественное есть в стандарте? Кстати, про это есть в книге Страуструпа "Дизайн и эволюция.."
Здравствуйте, LordMAD, Вы писали:
LMA>Прочти выше для чего я предлагал использовать такую конструкцию — для фейсконтроля. Если ты предложишь лучший способ достичь такой же цели — возможно, я соглашусь.
Система контроля версий + вменяемый менеджмент процессом разработки + не читать письма людей, не имеющих к делу отношения...
Короче вопрос компетентности и допуска людей к коду должен решаться как-то административным путём, а не путём насыщения кода каким-то ребусами...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[11]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, CreatorCray, Вы писали:
CC>>Всего то?.. LMA>Было бы интересно узнать — как этот же вопрос решается у Вас.
А без этих ассертов в начале функций не прожить? Я обычно их пишу если реально надо проверить что-то сложное, а тривиальных методов зачем их писать
a = 3;
b = 4;
assert( a < b ); // зачем?!void foo( int a, int b )
{
assert( a < b ); // в принципе можно, но лучше по другому
}
error_cd foo( int a, int b )
{
if( ! (a < b) )
return assert(0), invalid_parameter;
}
Re[13]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, LordMAD, Вы писали:
LMA>Ты считаешь, что это менее читабельно, чем LMA>
LMA>delete p;
LMA>p = 0;
LMA>
LMA>?
Да.
Код через запятую не имеет никакого преимущества, а вероятность неверного понимания или сотворения в том месте неоднозначной ошибки только повышает.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[15]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, Erop, Вы писали:
E>Система контроля версий + вменяемый менеджмент процессом разработки + не читать письма людей, не имеющих к делу отношения...
Система контроля версия тут не при чем — я уже объяснял.
Вменяемый менеджмент. Даже не смешно.
Вопрос выбора стиля написания кода должен решаться ДО НАПИСАНИЯ кода, а не когда выяснится КОГО поставит заказчик на работу с кодом. Или ты его письма предлагаешь не читать?
E>Короче вопрос компетентности и допуска людей к коду должен решаться как-то административным путём, а не путём насыщения кода каким-то ребусами...
Административные пути — самые неэффективные. Точнее это просто не работает в больших распределенных командах.
Re[14]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, Erop, Вы писали:
LMA>>Формально — практически любого. Хотелось бы узнать: а как может формулироваться стандарт, запрещающий такое? E>Например, через запрет необоснованного (задаётся явным перечислением обоснованных случаев + разрешение начальника под его ответственность) использования запятой...
Хотелось бы увидеть список необоснованных случаев использования запятой!!! Думаю, если бы такой можно было составить заранее, компилятор на такие случаи уже бы ругался.
E>Кроме того ревью ещё бывают...
Дык о нем родимом и речь! Код прошел 10 code review "без сучка, без задоринки" разными людьми, его передали еще кому-нибудь. Он сегодня одно пиьсьмо написал — получил ссылку в "букварь", завтра — еще одно, послезавтра — еще...
E>>>Я бы даже
delete p, p = 0;
писать не стал бы... LMA>>Ты считаешь, что это менее читабельно, чем LMA>>
LMA>>delete p;
LMA>>p = 0;
LMA>>
LMA>>? E>Да, считаю. Это необоснованное усложнение кода. Чтобы понять код с двумя операторами нужны толкьо базовые знания С++, а чтобы понять код с запятой, надо, по крайней мере, знать о точках следования. При этом код с запятой не проще написать и он не имеет никакх преимуществ для сколь угодно квалифицированного прграммиста. Так что он однозначно хуже.
То, что одна мысль не размазана на две строки — это усложнение?
Re[12]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, shrecher, Вы писали:
S>А без этих ассертов в начале функций не прожить? Я обычно их пишу если реально надо проверить что-то сложное, а тривиальных методов зачем их писать
Это общепринятый и довольно удобный способ выразить мысль. Позволяет при последовательном просмотре кода видя только тело функции понять правильно ли она написана. Ставший уже классическим пример с функцией нахождения среднего двух целых чисел о чем-то говорит?
S>
S>a = 3;
S>b = 4;
S>assert( a < b ); // зачем?!
S>void foo( int a, int b )
S>{
S> assert( a < b ); // в принципе можно, но лучше по другому
S>}
S>error_cd foo( int a, int b )
S>{
S> if( ! (a < b) )
S> return assert(0), invalid_parameter;
S>}
S>
К чему эти три примера плохого кода?
Re[14]: Месье ещё и с формальной логикой не дружит?
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, LordMAD, Вы писали:
E>Не совсем понятно. Приоритет операции -- это очень просто. Это частичное упорядочение на множестве операций, позволяющее сравнить операции, которые могут конкурировать между собой за приоритет. Если ещё проще, то это такая таблица, где каждой операции сопоставлен элемент упорядоченного множества. Число, например. E>IMHO, если какая-то система понятий "тождественна" системе с приоритетами, то ты всегда можешь выписать такую таблицу и предъявить её. E>Выпиши её, пожалуйста, для двух операций: "?:" и ","...
Возьми K&R — там эти два оператора есть в списке упорядоченных операций — в начале списка самые приоритетные, числа подставишь сам. Полученная таблица будет тождественна тому, что описано в стандарте C++, за исключением разницы между C и C++, что для этих двух операторов роли не играет.
E>>>Если у "?:" приоритет выше, чем у "," то поясни пожалуйста, почему вторая запятая обрабатывается так, словно она имеет более высокий приоритет, чем "?:" LMA>>Я уже написал: "аргументами "?:" являются выражения?" (выделил жирным) E>То есть ты ссылаешься на то, что корректность С++ выражений и порядок применения операций определяется не приоритетами, а некими грамматиками? Несводимыми, при этом, к понятию "приоритет операции"? Если так, то это обозначает, что приоритетов операций в С++ нет...
Я не пойму к чему это ты. Пусть у тебя приоритет "?:" получится 101, а у "," — 103 (меньшее значение соответствует более высокому приоритету), что дальше? Что ты хочешь сказать?
E>Пока что ты не прошёл лично мой ценз на соответствие уровня знаний С++ и уровня понтов по этому поводу
Взаимно.
Здравствуйте, CreatorCray, Вы писали:
LMA>>получу реальную пользу в виде доводов против того, чтобы _это_ критиковало мой код. CC>Следует ли понимать, что человека, обозначенного как _это_ вы считаете недопрограммистом а то и вообще недочеловеком?
Просто утрировал, не придирайтесь.
Никто не рождается опытным программистом. И есть множество сфер человеческой деятельности, в которых большинство из нас ничего не понимает до самой смерти.
Re[19]: Программирование деятельность целенаправленная....
Здравствуйте, LordMAD, Вы писали:
LMA>Я просто делаю выводы из твоих слов. То, что некие продукты продаются, ведь не означает, что при другом подходе они не продавались бы лучше, так что это никак не доказывает того, что твоим заказчикам не надо посочувствовать. Кстати сказать, если судить по твоим репликами, сильно сомневаюсь, чтобы такого подпустили бы к серьезным продуктам, без обид.
Не знаешь, а говоришь... Думаешь так ведут себя мудрые люди?
E>>И какова же эта существенная причина преднамаренно понижать качество кода?
E>>Твоя патологическая боязнь критики? LMA>У меня нет боязни критики, не суди по себе о других. Просто объяснять прописные истины желания нет. А тебе видать нравится из букваря цитаты в исходники вставлять, что у вас за килобайты кода примии дают?
А что тогда обозначают всякие рассуждения про _ЭТО_, которое будет ТЕБЯ критиковать...
E>>Я не удивлён. Тебя я понял так, что НАДО, LMA>Тогда читай внимательнее, я же выделил жирным шрифтом!
Я тоже выделил слово НЕЛЬЗЯ...
E>>Обычно, когда критикуют, то приводят аргументы. И сразу ясно кто там чего стоит, и как критик и как автор. LMA>Ага, в духе: почему у вас тут x*(x-1) — мы хотим цикл.
IMHO, это значит, что надо написать комментарий... Но вообще-то вопрос довольно глупый. Показывает что задающий вопрос не разобрался. А ещё показывает, что ты написал код эффективный, но непонятный -- есть куда расти...
LMA>Может мне просто с новичками не везет, а у других таких проблем не бывает?
IMHO, ты просто не умеешь работать с людьми. Например, не умеешь заваёвывать у них авторитет. Иначе тебе бы не задавали дуратских вопросов, не попробовав предварительно разобраться самостоятельно. С другой стороны объяснить тот или иной приём в целом не долго...
LMA>+1. Только вот неквалифицированные ничего серьезного НИ РАЗУ не находили, зато времени на них уходит уйма.
IMHO, это говорит о том, что в вашей конторе очень плохо поставлена организация труда. Ко мне люди с улицы с вопросами "а почему вот у вас там написанно" не подходят...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, LordMAD, Вы писали:
LMA>Вопрос выбора стиля написания кода должен решаться ДО НАПИСАНИЯ кода, а не когда выяснится КОГО поставит заказчик на работу с кодом.
Я с этим не спорю. Я спорю с тем, что при написании кода нужно использовать направленные на его преднамеренное запутывание трюки, вроде "delete x, y, z" LMA>Или ты его письма предлагаешь не читать?
Ты таки занимаешься аутсорсингом или OpSo?
E>>Короче вопрос компетентности и допуска людей к коду должен решаться как-то административным путём, а не путём насыщения кода каким-то ребусами... LMA>Административные пути — самые неэффективные. Точнее это просто не работает в больших распределенных командах.
Это неправда. Правда то, что аутсорсерам обычно очень сильно не хватет нормальной организации разработки. Во всяком случае так каждый раз было, когда я заказывал какую-нибудь часть проекта аутсорсерам. Обычно российские аутсорсеры имеют неплохих разработчиков и совсем ни на что не годный менджмент, особенно менеджмент среднего звена. В конце концов мне больше всего понравилось заказывать аутсорсерам разработку, при условии, что менеджеры будут мои, а не их.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[15]: А разве в OpenSource бывают собеседования? :)
LMA>(конечно при условии одинакового результата, что верно в большинстве, наверное, случаев) потому, что для тех, кто "пришел" с других языков программирования так понятнее?
Я думаю, что так писать можно, но в целом не нужно. Конструкция "+=" очень простая и широко известная, в отличии от точек следования...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[15]: Месье ещё и с формальной логикой не дружит?
Здравствуйте, LordMAD, Вы писали:
E>>Выпиши её, пожалуйста, для двух операций: "?:" и ","... E>>>>Если у "?:" приоритет выше, чем у "," то поясни пожалуйста, почему вторая запятая обрабатывается так, словно она имеет более высокий приоритет, чем "?:"
LMA>Я не пойму к чему это ты. Пусть у тебя приоритет "?:" получится 101, а у "," — 103 (меньшее значение соответствует более высокому приоритету), что дальше? Что ты хочешь сказать?
Я так тебя понял, что для этих двух операций таблица приоритетов выглядит так, как я выделил у тебя?
Тогда, согласно этой таблице, в выражении
p, q ? p, q : p, q
скобки должны быть расставлены так
p, (q?p), (q:p), q
но это таки не верно. Это одна из причин, почему подход с приоритетами в С++ выражениях не работает. Работает подходь с грамматиками.
Увы.
E>>То есть ты ссылаешься на то, что корректность С++ выражений и порядок применения операций определяется не приоритетами, а некими грамматиками? Несводимыми, при этом, к понятию "приоритет операции"? Если так, то это обозначает, что приоритетов операций в С++ нет...
E>>Пока что ты не прошёл лично мой ценз на соответствие уровня знаний С++ и уровня понтов по этому поводу LMA>Взаимно.
Ну процитируй стандарт С++, где там вводятся приоритеты операций, пжлст...
Или ты намекаешь на то, что я слишком мало понтуюсь?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[20]: Программирование деятельность целенаправленная....
Здравствуйте, Erop, Вы писали:
E>Не знаешь, а говоришь... Думаешь так ведут себя мудрые люди?
Ты оставляешь такое право только за собой?
LMA>>У меня нет боязни критики, не суди по себе о других. Просто объяснять прописные истины желания нет. А тебе видать нравится из букваря цитаты в исходники вставлять, что у вас за килобайты кода примии дают? E>А что тогда обозначают всякие рассуждения про _ЭТО_, которое будет ТЕБЯ критиковать...
Критика бывает конструктивной, а бывает неконструктивной. Первую я приветствую; вторая меня раздражает, потому что приходится тратить время на ответ.
E>Я тоже выделил слово НЕЛЬЗЯ...
Тогда обоснуй — почему категорично НЕЛЬЗЯ?
LMA>>Ага, в духе: почему у вас тут x*(x-1) — мы хотим цикл. E>IMHO, это значит, что надо написать комментарий... Но вообще-то вопрос довольно глупый. Показывает что задающий вопрос не разобрался. А ещё показывает, что ты написал код эффективный, но непонятный -- есть куда расти...
Если какому-то НЕУЧУ этот код непонятный, то почему я должен тратить свое время (а следовательно — деньги заказчика), на то, чтобы объяснять ему это (в виде комментария), а не ему купить "букварь", научится программировать, и только после этого подходить к моему коду "ближе, чем на 10 метров"?
LMA>>Может мне просто с новичками не везет, а у других таких проблем не бывает? E>IMHO, ты просто не умеешь работать с людьми. Например, не умеешь заваёвывать у них авторитет. Иначе тебе бы не задавали дуратских вопросов, не попробовав предварительно разобраться самостоятельно.
У меня такая специфика работы, что (для части проектов) я человека который будет смотреть мой код не видел, не вижу и никогда не увижу (и, кстати, даже не знаю какой язык для него родной). То, о чем ты пишешь, хорошо для локальных проектов, а с ними как раз проблем нет (отчасти как раз авторитет помогает, хотя иногда как раз прошу более критически смотреть по этой причине).
E>С другой стороны объяснить тот или иной приём в целом не долго...
Каждый может и не долго... а на все уходит приличное количество времени, в чем и проблема.
E>IMHO, это говорит о том, что в вашей конторе очень плохо поставлена организация труда. Ко мне люди с улицы с вопросами "а почему вот у вас там написанно" не подходят...
Речь идет о запросах от заказчика. И что нужно поменять в нашей конторе, чтобы такого не было?
Здравствуйте, Erop, Вы писали:
E>Я с этим не спорю. Я спорю с тем, что при написании кода нужно использовать направленные на его преднамеренное запутывание трюки, вроде "delete x, y, z"
Я не говорю, что НУЖНО, а говорю, что хочу такое себе позволить (не от хорошей жизни).
E>Ты таки занимаешься аутсорсингом или OpSo?
Те, проекты, о которых идет речь (есть обозначенная проблема) — аутсорсинг. Хотя это не основная моя работа.
LMA>>Административные пути — самые неэффективные. Точнее это просто не работает в больших распределенных командах. E>Это неправда. Правда то, что аутсорсерам обычно очень сильно не хватет нормальной организации разработки. Во всяком случае так каждый раз было, когда я заказывал какую-нибудь часть проекта аутсорсерам. Обычно российские аутсорсеры имеют неплохих разработчиков и совсем ни на что не годный менджмент, особенно менеджмент среднего звена. В конце концов мне больше всего понравилось заказывать аутсорсерам разработку, при условии, что менеджеры будут мои, а не их.
Тогда просвяти — что правильные менеджеры должны в такой ситуации делать? Лично у меня устойчивое мнение, что вероятность того, что бывают правильные менеджеры меньше чем вероятность того, что Дед Мороз существует.
Re[16]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, Erop, Вы писали:
E>Я думаю, что так писать можно, но в целом не нужно.
Что-то грань уж слишком размытая. E>Конструкция "+=" очень простая и широко известная, в отличии от точек следования...
Ну хорошо, а то я уж боялся, что и
a += b += c;
тебе не понравится.
Re[16]: Месье ещё и с формальной логикой не дружит?
Здравствуйте, Erop, Вы писали:
E>>>Выпиши её, пожалуйста, для двух операций: "?:" и ","... E>>>>>Если у "?:" приоритет выше, чем у "," то поясни пожалуйста, почему вторая запятая обрабатывается так, словно она имеет более высокий приоритет, чем "?:"
LMA>>Я не пойму к чему это ты. Пусть у тебя приоритет "?:" получится 101, а у "," — 103 (меньшее значение соответствует более высокому приоритету), что дальше? Что ты хочешь сказать?
E>Я так тебя понял, что для этих двух операций таблица приоритетов выглядит так, как я выделил у тебя? E>Тогда, согласно этой таблице, в выражении
p, q ? p, q : p, q
скобки должны быть расставлены так
p, (q?p), (q:p), q
но это таки не верно. Это одна из причин, почему подход с приоритетами в С++ выражениях не работает. Работает подходь с грамматиками. E>Увы.
Нет. Скобки должны быть расставлены так:
p, (q ? p, q : q, q)
Просто вторым и третьим аргументом оператора "?:" являются выражения, а не значения — что я уже писал выше.
E>>>То есть ты ссылаешься на то, что корректность С++ выражений и порядок применения операций определяется не приоритетами, а некими грамматиками? Несводимыми, при этом, к понятию "приоритет операции"? Если так, то это обозначает, что приоритетов операций в С++ нет...
Собственно это "старо как мир": когда Страуструп написал в своей "The C++ Programming Language" про то, что это не может быть сведено к одним лишь приоритетам — его об этом самого расспрашивали в одном из интервью — можешь найти его ответ. Все это не означает, что приоритетов не существует, это означает, что кроме приоритетов есть кое-что еще.
E>Ну процитируй стандарт С++, где там вводятся приоритеты операций, пжлст...
Я уже написал, что приоритетов там нет. Если что-то явно не вводится в стандарте, то это значит, что этого в том, о чем стандарт, нет?
Там и "оператора for" нет, о котором ты писал: E>>Обычно этот список состоит из лдного пункта -- третьей части оператора for...
Здравствуйте, LordMAD, Вы писали:
LMA>Тогда просвяти — что правильные менеджеры должны в такой ситуации делать? Лично у меня устойчивое мнение, что вероятность того, что бывают правильные менеджеры меньше чем вероятность того, что Дед Мороз существует.
Грамотно выполнять свою работу
Прагматически организовыватьпроцесс разработки ПО, так чтобы он обеспечивал качество и скорость разработки. В частности неплохо бы добиться такого положения вещей, чтобы разработчики понимали и разделяли ценности и цели осуществляемой разработки
Это правда сложная довольно и высококвалифицированная работа. В общих словах такое знание передаётся IMHO плохо. Это как высшей математике в чате учить
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[17]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, LordMAD, Вы писали:
E>>Обычно этот список состоит из лдного пункта -- третьей части оператора for... LMA>-1 LMA>Как минимум, в голову сразу еще приходят "первая часть for"
Приведи, пожалуйста, пример, когда оператор "запятая" в этом месте уместна...
При этом именно оператор "запятая", а не декларация нескольких переменных через запятую...
LMA>и переопределенный "operator,"
Обычно свои писать нельзя. А библиотечные можно, если можно использовать соответсвующие библиотечные средства.
LMA>В общем случае запрещать использовать запятую почти всегда — это означает попросту не доверять программистам "решать на месте", что возможно в работе только с новичками, IMHO.
В чём продлема? Убеди своего начальника в целесообразности использования запятой и используй
E>>Какой код? "delete x, y, z"? LMA>Нет, это же я только собираюсь...
Ну ты просто про какие-то многочисленные ревю пройденные этим кодом писал...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[22]: Программирование деятельность целенаправленная....
Здравствуйте, Erop, Вы писали:
LMA>>Тогда обоснуй — почему категорично НЕЛЬЗЯ? E>Ну смотри выше по ветке
Там нет фактов, только мнения.
E>Писать более понятный и более полно документированный код...
Тратить больше своего времени на никому не нужные вещи... комментировать каждый чих... чтобы обычные программисты тонули в море ненужных им комментариев при просмотре моего кода... понятно... IMHO, вот это и есть саботаж.
Здравствуйте, LordMAD, Вы писали:
E>>Писать более понятный и более полно документированный код... LMA>Тратить больше своего времени на никому не нужные вещи... комментировать каждый чих... чтобы обычные программисты тонули в море ненужных им комментариев при просмотре моего кода... понятно... IMHO, вот это и есть саботаж.
Нет, писать ненужные комментарии на каждый чих тоже плохо. Программировать надо так, чтобы программа была и так ясна, без комментариев.
А вот нетривиальные места надо комментировать. Ещё крайне полезно комментировать семантику методов полей и функций, если она не очевидна из их названий...
Я тебя так понял, что у тебя уже был негативный опыт, что ты написал крутой, по твоему мнению код, а заказчик тебе прислал вопрос, почему так написано, а не прямо? Если я понял тебя правилбно, то я тебе советую как именно надо делать, чтобы твоему заказчику было удобнее. А ты хочешь зачем-то сделать так, чтобы ему не хотелось читать твои исходники вообще.
Таки в чём твоя цель? Помочь твоему клиенту или наоборот отомстить?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[18]: А разве в OpenSource бывают собеседования? :)
LMA>>тебе не понравится. CC>Не понравится. Это уже перебор.
Я бы вообще сказал, что использовать результат оператора присваивания нужно только в том случае, если это действительно зачем-то нужно. И то сначала крепко подумать как бы этого избежать...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Грамотно выполнять свою работу
Осваивали средства? С этим проблем нет.
E>Прагматически организовыватьпроцесс разработки ПО, так чтобы он обеспечивал качество и скорость разработки.
Ха, ха, ха... А как же треугольник "ресурсы, время, качество".
E>В частности неплохо бы добиться такого положения вещей, чтобы разработчики понимали и разделяли ценности и цели осуществляемой разработки
С ценностями и целями — неувязочка — они у менеджеров и у разработчиков разные. Я очень хорошо понимаю, почему менеджерам выгодно, чтобы код был "попроще". Впрочем, сейчас вспоминать Маркса и классовую борьбу не модно, так что не буду развивать эту тему...
E>Это правда сложная довольно и высококвалифицированная работа. В общих словах такое знание передаётся IMHO плохо. Это как высшей математике в чате учить
Есть такая фраза, которую припысывают Эйнштейну: если вы не можете объяснить что-то шестилетнему ребенку, значит, вы не понимаете это сами.
Здравствуйте, LordMAD, Вы писали:
LMA>Осваивали средства? С этим проблем нет.
Нет. Хороший менеджмент другим занимается. Вот с таким, который "средства осваивает" в российский аутсорсерах как раз проблем обычно нет...
LMA>Ха, ха, ха... А как же треугольник "ресурсы, время, качество".
А так, что повышай качество своей работы. Тогда у тебя треугольник будет лучше, чем у конкурентов..
Так ты "delete x, y, z" в качестве орудия классовой борьбы применять хочешь?
E>>Это правда сложная довольно и высококвалифицированная работа. В общих словах такое знание передаётся IMHO плохо. Это как высшей математике в чате учить LMA>Есть такая фраза, которую припысывают Эйнштейну: если вы не можете объяснить что-то шестилетнему ребенку, значит, вы не понимаете это сами.
Ну так то 6-летнему ребёнку... А то тебе. У тебя мозг не так открыт объяснениям...
Но ты можешьпродемонстрировать класс и объяснить тут быстренько как на С++ программировать надо, так чтобы 6-летний ребёнок тоже понял
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[18]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, Erop, Вы писали:
LMA>>Как минимум, в голову сразу еще приходят "первая часть for" E>Приведи, пожалуйста, пример, когда оператор "запятая" в этом месте уместна... E>При этом именно оператор "запятая", а не декларация нескольких переменных через запятую...
Захват ресурса + декларация переменной цикла
LMA>>и переопределенный "operator," E>Обычно свои писать нельзя. А библиотечные можно, если можно использовать соответсвующие библиотечные средства.
?
LMA>>В общем случае запрещать использовать запятую почти всегда — это означает попросту не доверять программистам "решать на месте", что возможно в работе только с новичками, IMHO. E>В чём продлема? Убеди своего начальника в целесообразности использования запятой и используй
Да у тебя отношение к программистам — просто как к лохам последним! Откуда такое недоверие?
E>>>Какой код? "delete x, y, z"? LMA>>Нет, это же я только собираюсь... E>Ну ты просто про какие-то многочисленные ревю пройденные этим кодом писал...
Ничего подобного про этот код я не писал!
Здравствуйте, LordMAD, Вы писали:
E>>Приведи, пожалуйста, пример, когда оператор "запятая" в этом месте уместна... E>>При этом именно оператор "запятая", а не декларация нескольких переменных через запятую... LMA>Захват ресурса + декларация переменной цикла
Пример кода, пожалуйста...
E>>В чём продлема? Убеди своего начальника в целесообразности использования запятой и используй LMA>Да у тебя отношение к программистам — просто как к лохам последним! Откуда такое недоверие?
Нет. Просто это часть грамотного управления разработкой. Любое отступление от "простого понятного кода" стоит дополнительных затрат по управлению разработкой и по поддержке. Соответсвенно, если принимается решение о целесообразности такого удороджания, то должны быть приведены внятные аргументы. Как раз инициатор аргументирует, начальник сопротивляется. Если решение верное, то убедит, если нет, то и к лучшему оно...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[19]: Месье ещё и с формальной логикой не дружит?
Здравствуйте, LordMAD, Вы писали:
LMA>Слив защитан.
Не, ну если у тебя аргументы таки закончились...
Мне-то казалось, что тебя С++ интересует, а не сливы.
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[19]: Месье ещё и с формальной логикой не дружит?
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, Erop, Вы писали:
LMA>>>
LMA>>>p, (q ? p, q : q, q)
LMA>>>
LMA>>>Просто вторым и третьим аргументом оператора "?:" являются выражения, а не значения — что я уже писал выше.
вообщето и значениями и выражениями delete выражение типа void а new типа указатель поэтому
1? delete x:new int;
распарсится нормально, но отбракуется по несовместимым значениям
Здесь собственно особенность того что оператор торйной поэтому от ? идет к : и поскольку запятая меньший приоритет то всеже так
p, (q ? (p, q ): q), q
вариант ответа ошибка, вобщем тоже правдоподобно
Re[20]: Месье ещё и с формальной логикой не дружит?
Здравствуйте, Erop, Вы писали:
E>Я бы вообще сказал, что использовать результат оператора присваивания нужно только в том случае, если это действительно зачем-то нужно. И то сначала крепко подумать как бы этого избежать...
И на это правило есть исключение:
int a,b,c,d,e,f;
...
a = b = c = d = e = f = 0;
Но вытворять такое же с "+=" я бы не стал.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[20]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, CreatorCray, Вы писали:
CC>Здравствуйте, Erop, Вы писали:
E>>Я бы вообще сказал, что использовать результат оператора присваивания нужно только в том случае, если это действительно зачем-то нужно. И то сначала крепко подумать как бы этого избежать...
Ну это примеры VB-like а ежели вместо b l-value типа ::->[]() то а=б=с и += весьма полезны
CC>И на это правило есть исключение: CC>
CC>int a,b,c,d,e,f;
CC>...
CC>a = b = c = d = e = f = 0;
CC>
CC>Но вытворять такое же с "+=" я бы не стал.
Re[13]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, shrecher, Вы писали:
S>>А без этих ассертов в начале функций не прожить? Я обычно их пишу если реально надо проверить что-то сложное, а тривиальных методов зачем их писать LMA>Это общепринятый и довольно удобный способ выразить мысль. Позволяет при последовательном просмотре кода видя только тело функции понять правильно ли она написана. Ставший уже классическим пример с функцией нахождения среднего двух целых чисел о чем-то говорит?
Зачем писать ассерты в каждой функуци? Каждая задача ограничена в ресурсах (время и внимамние).
На написание безполезных ассертов в тривиальных это уходит время и несколько отвлекаешься от поставленной задачи. Лучше это время затратить на написание комментариев и написание еще одного или больше Unit теста.
S>>
S>>a = 3;
S>>b = 4;
S>>assert( a < b ); // зачем?!
S>>void foo( int a, int b )
S>>{
S>> assert( a < b ); // в принципе можно, но лучше по другому
S>>}
S>>error_cd foo( int a, int b )
S>>{
S>> if( ! (a < b) )
S>> return assert(0), invalid_parameter;
S>>}
S>>
Здравствуйте, Erop, Вы писали:
LMA>>Захват ресурса + декларация переменной цикла E>Пример кода, пожалуйста...
Сначала объясни — зачем? Что тебе это даст? Декларация нескольких переменных разных типов — дальше что?
LMA>>Да у тебя отношение к программистам — просто как к лохам последним! Откуда такое недоверие? E>Нет. Просто это часть грамотного управления разработкой.
Увеличение затрат, вызванное лишними действиями — это грамотное управление разработкой?
Фразы вида "мы всегда все делаем по стандарту", "вы всегда делаем правильно", "мы успешно продаем свои продукты" на самом деле означают всего-лишь "мы всегда так делаем".
E>Любое отступление от "простого понятного кода" стоит дополнительных затрат по управлению разработкой и по поддержке.
С этим никто и не спорит, вопрос опять же в том, что "простой понятный код" — это СУБЪЕКТИВНО.
E>Соответсвенно, если принимается решение о целесообразности такого удороджания, то должны быть приведены внятные аргументы.
Удорожание происходит тогда, когда вместо низкооплачиваемого программиста берут высокооплачиваемого. А если имеется высокооплачиваемый — никакого удорожания нет.
E>Как раз инициатор аргументирует, начальник сопротивляется. Если решение верное, то убедит, если нет, то и к лучшему оно...
Начальник — менеджер, он в этом понимать ничего не должен — у него совсем другие заботы, и это правильно. Программист имеет право на презумпцию вменяемости: он пишет код как считает нужным, качество этого кода видно из code review.
Re[20]: Месье ещё и с формальной логикой не дружит?
Здравствуйте, Programador, Вы писали:
LMA>>>>Просто вторым и третьим аргументом оператора "?:" являются выражения, а не значения — что я уже писал выше. P>вообщето и значениями и выражениями delete выражение типа void а new типа указатель поэтому P>
P>1? delete x:new int;
P>
P>распарсится нормально, но отбракуется по несовместимым значениям
Какое отношение то, что написали Вы, имеет к тому, что написал я?
P>Здесь собственно особенность того что оператор торйной поэтому от ? идет к : и поскольку запятая меньший приоритет то всеже так
P>p, (q ? (p, q ): q), q
P>вариант ответа ошибка, вобщем тоже правдоподобно
Что Вы хотели этим сказать?
Re[21]: Месье ещё и с формальной логикой не дружит?
Здравствуйте, Programador, Вы писали:
P>кстати простая арифметика не имеет приретив поскольку есть унарный плюс и минус
Вы понимаете, надеюсь, что вычитание и смена знака — это разные операции?
Re[18]: А разве в OpenSource бывают собеседования? :)
От:
Аноним
Дата:
22.06.08 15:55
Оценка:
Здравствуйте, Аноним, Вы писали:
... А>Определенно, LordMAD впечатления опытного профессионала не производит, скорее всего просто подросток с комплексами. А>Крайне мала вероятность, что он действительно участвует в коммерческих проектах, в виду отсутствия минимальных коммуникативных навыков и мании величия.
Ну так "безумный" в нике не зря
Re[15]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, LordMAD, Вы писали:
S>>На написание безполезных ассертов в тривиальных это уходит время и несколько отвлекаешься от поставленной задачи. LMA>Безполезных assert'ов писать не надо. assert(true); — это не безполезный assert, это способ документирования. Или Вы не понимаете зачем документировать свой код?
-1
LMA>unit-тесты — это не панацея, они тем полезнее, чем менее квалифицированные люди пишут код. В ряде случаев они почти бесполезны. Скорее всего, на написание качественного unit-теста уйдет существенно больше времени, чем на грамотное внесение assert'ов.
Мсье продемонстрирует публике например как с помощью ассертов проверить что функциональность класса не сломана во время рефакторинга? Скажем на примере класса, который считает CRC32.
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[21]: Месье ещё и с формальной логикой не дружит?
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, Programador, Вы писали:
LMA>>>>>Просто вторым и третьим аргументом оператора "?:" являются выражения, а не значения — что я уже писал выше. P>>вообщето и значениями и выражениями delete выражение типа void а new типа указатель поэтому P>>
P>>1? delete x:new int;
P>>
P>>распарсится нормально, но отбракуется по несовместимым значениям LMA>Какое отношение то, что написали Вы, имеет к тому, что написал я?
P>>Здесь собственно особенность того что оператор торйной поэтому от ? идет к : и поскольку запятая меньший приоритет то всеже так
P>>p, (q ? (p, q ): q), q
P>>вариант ответа ошибка, вобщем тоже правдоподобно LMA>Что Вы хотели этим сказать?
1. имхо выражения, а не значения некоректно, вроде мухи с котлетами
2. Вроде Вы придерживались с Егором противоположных мнений на парсинга pqpqpq
правильный парсинг p, (q ? (p, q ): q), q
p, ( (q ? (p, q ): q), q ) эти скобки тоже правильные хоть не дают ничего
а почему Егор какашками кидался
Re[22]: Месье ещё и с формальной логикой не дружит?
Здравствуйте, LordMAD, Вы писали:
LMA>Здравствуйте, Programador, Вы писали:
P>>кстати простая арифметика не имеет приретив поскольку есть унарный плюс и минус LMA>Вы понимаете, надеюсь, что вычитание и смена знака — это разные операции?
Вестимо разные, просто когда парсер пишешь это один и тотже символ
Re[22]: Месье ещё и с формальной логикой не дружит?
Здравствуйте, Programador, Вы писали:
P>1. имхо выражения, а не значения некоректно, вроде мухи с котлетами
Отчасти — да.
P>2. Вроде Вы придерживались с Егором противоположных мнений на парсинга pqpqpq P>правильный парсинг p, (q ? (p, q ): q), q P> p, ( (q ? (p, q ): q), q ) эти скобки тоже правильные хоть не дают ничего
Да, Вы правы.
P>а почему Егор какашками кидался
Могу только предполагать
Re[23]: Месье ещё и с формальной логикой не дружит?
Здравствуйте, Programador, Вы писали:
P>>>кстати простая арифметика не имеет приретив поскольку есть унарный плюс и минус LMA>>Вы понимаете, надеюсь, что вычитание и смена знака — это разные операции? P>Вестимо разные, просто когда парсер пишешь это один и тотже символ
Так приоритеты — у операций, а не у символов. То, о чем Вы пишете, просто говорит о том, что парсер должен будет понять — какой оператор соответствует символу.
Re[23]: Месье ещё и с формальной логикой не дружит?
Здравствуйте, LordMAD, Вы писали:
P>>правильный парсинг p, (q ? (p, q ): q), q P>> p, ( (q ? (p, q ): q), q ) эти скобки тоже правильные хоть не дают ничего LMA>Да, Вы правы.
неа ошибся .
Подумавши: x,y,z =(x,y),z Left to right все скобки слева, как +-. для пары +- так и для перегруженных не одно и тоже
Здравствуйте, LordMAD, Вы писали:
LMA>А если по-существу?
По существу: assert который ничего не проверяет бесполезен и не несет никакой смысловой нагрузки..
Твоя надежда на то, что увидевший его догадается что других ассертов тут не надо — ничем не обоснована.
По результатам проведенного еще в пятницу по аське "опроса" выяснилось, что в большинстве своем тот кто видит подобный ассерт считает автора параноиком и при первом же рефакторинге такие ассерты будут вычищены.
LMA>>>unit-тесты — это не панацея, они тем полезнее, чем менее квалифицированные люди пишут код. В ряде случаев они почти бесполезны. Скорее всего, на написание качественного unit-теста уйдет существенно больше времени, чем на грамотное внесение assert'ов. CC>>Мсье продемонстрирует публике например как с помощью ассертов проверить что функциональность класса не сломана во время рефакторинга? Скажем на примере класса, который считает CRC32. LMA>Во-первых, Ваша фраза звучит так, как будто я утверждал, что assert'ы — панацея!
Ты утверждал, что юниттесты в ряде случаев почти бесполезны, что они нужнее для низкоквалифицированных разработчиков, что на них уходит больше времени чем на ассерты. Лично у меня создалось впечатление, что юниттестами аффтар вообще не пользуется и терпеть их не может. Зато крайне любит ассерты и применяет их везде и всюду, квадратно-гнездовым методом.
LMA>Во-вторых, "проверить что функциональность класса не сломана во время рефакторинга" можно множеством способов, включая assert'ы
Опять 25! Повторюсь: как в приведенном примере (CRC32) с помощью assertов проверить не сломана ли функциональность?
LMA> unit-тесты и пр.... и ни один из этих способов не будет гарантировать корректности кода
Ну приехали...
LMA>то, что Вы просите сделать — это обыкновенная провокация, на которую я не собираюсь поддаваться.
Некоторое время Выбегалло пусто смотрел на него, затем сказал:
-- Эту реплику из зала мы, товарищи, сейчас отметем с негодованием. Как неорганизованную
(С)
... << RSDN@Home 1.1.4 stable SR1 rev. 568>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Re[16]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, Programador, Вы писали:
P>Здравствуйте, Юрий Жмеренецкий, Вы писали:
LMA>>>>>
LMA>>>>>delete p;
ЮЖ>>LMA>>>p = 0;
LMA>>>>>
ЮЖ>>А выделенное — вообще UB
мне так показалось что nulptr не отменяет преобразование 0 в указатель. nulptr конвертабельное значение какогото класса вводится дополнительно, на старые правила плевались, но рука вроде на основы не поднялась
Re[18]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, Programador, Вы писали:
P>Незя, так низя. Это сечас левое от голого указателя, а сделаю GC тут все UB и повылазят
В текущем стандарте переменная, содержащая удалённый указатель не хуже, чем просто неинициализированная переменная. Так как в неинициализированную переменную присваисать можно (смотри на совместимость с С), то и в переменную с удалённым указателем тоже можно.
Если не так, приврли пункит стандарта, где утверждается, что это UB.
IMHO, вы путаете с таким вот кодом:
int* deletedPtr()
{
int p* = new int;
delete p;
return p;// Копируем невалидный указаетль => UB
}
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[20]: А разве в OpenSource бывают собеседования? :)
Здравствуйте, Programador, Вы писали:
P>Если комитет по недомыслию или для перестраховки написал такое P>
P>delete p;
P>b=p; // UB
P>
P> то тут уж не знаешь смеяться или плакать
Это не для перестраховки. Могут быть платформы, на которых используется сегментная модель памяти. И для операций с адресами удобно использзовать специальные инструкции и регистры, обрабатывающие сегмент и смещение.
При этом процессор, при загрузке указателя, может проверять, например, корректность id сегмента. Если после delete p последняя память в сегменте освободится менеджер может вернуть системе весь сегмент, а система просто разрушит его, сделав селектор сегмента невалидным. При попытке копирования невалидный селектор будет загружен в процесор и начнётся реальное UB...
Затриать же невалидный указатель в памяти всё-таки безопасно...
похожего UB можно добиться даже на x86. Только не с указателями, но с другим типом, валидность которого может проверяться аппаратурой -- с double.
struct UBGenerator { double f1, f2, f3, f4, f5, f6, f7, f8, f9, f10; };
UBGenerator foo()
{
UBGenerator tmp;
return tmp; // UB, может приводить на x86 к реаоьным проблемам :(
}
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали: E>Ты, наверное знаешь, что код delete p; вызовет деструктор *p, а потом позовёт operator delete( p ); E>1) Как вызвать operator delete( void*, size_t );
Если этот опреатор определить в классе, то именно он будет вызываться при удалении экземпляра.
№3.7.3.2 п2
Иначе как и №2 E>2) Как вызвать operator delete( void*, const char* );
Вызывается в случае, вылета исключения из конструктора объекта при конструировании соответствующим по параметрам new.
№5.3.4 пп8,17-20 E>3) Как вызывать operator delete( int );
Неверная сигнатура.
Разумеется, правильные операторы можно вызвать явно как функции.
Здравствуйте, Tonal-, Вы писали:
T>Вроде даже у кого-то из классиков описан.
AFAIK, всё верно, но думал долго
Я это к тому, что и new вроде как оператор, а ясности мало, да и delete запутанно очень определён. И если не знать всё на эту тему досконально, то легко, IMHO, запутаться
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали: T>>Вроде даже у кого-то из классиков описан. E>AFAIK, всё верно, но думал долго
Кстати, почему ещё тормозил: Простейший пример для вызова operator delete из конструкции new не отработал с первого раза и заставил усомнится в моём склерозе.
При компиляции мингвой (3.4.5, 4.1.2-dw2, 4.3.0) выводит только
e::new(size_t 1, char* 0x22ff38)
Для того, чтобы отработало как положено надо поместить вызов foo или new в try/catch.
Нельзя сказать,что такое поведение нелогично, но в ступор таки поставило.
Кстати, кто-нибудь может сказать как это согласуется со стандартом? Мне кажется это отступление...
Здравствуйте, Tonal-, Вы писали:
T>Кстати, кто-нибудь может сказать как это согласуется со стандартом? Мне кажется это отступление...
Основное западло состоит в том, что да.
Совсем неловленное исключение стек разматывать не обязано
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском