Привет всем сишникам! В первую очередь тем которые труъ и которые ANSI. провел тут давеча масштабный опрос на тему: сколько строк вы пишите за день (в среднем)? Поскольку опрос проходил в стихийной обстановке неформальной попойки, то обсуждение было бурным и суровым. Мы мужественно пили, ожесточенно спорили и непрерывно калькулировали на салфетках. В итоге пришли к мнению, что если брать полный цикл разработки от идеи до модели (летающей), то получается где-то по 3 строки в день.

Учитывая, что зарплата у сишников начинается от $10k ~ $15k в месяц (и там же и заканчивается), то в первом приближении мы имеем $169 за строку, а при средней длине строки в 30 символов (зависит от форматирования, конечно, но все равно это очень грубый результат), получается $6 баксов за одну нажатую клавишу. Или $3 за нажатую, а $3 за отпущенную.

А теперь, внимание вопрос залу: а сколько клавиш вы в среднем нажимаете за одну минуту? Вопрос, конечно, интересный и главное легко проверяемый. Благо ноуты под рукой имеются. После небольшого эксперимента мы сошлись на цифре 300 символов/min. У меня правда получилось всего двести с хвостиком, но суть не в этом.

Теперь берем цену за одну нажатую клавишу, множим ее на скорость набора и получаем астрономическую цифирь. Если бы программисты были не дятелы (в хорошем смысле этого слова), то получали бы пол-лимона баксов за 6ти часовой рабочий день, т.е. 16 лимонов в месяц или миллиард за три года непрырывного стука по клавишам.

Шутка, конечно, но это хороший пример того, что у сишников (в R&D) производительность труда строками никак не меряется и тот, кто три дня медитирует, а потом пишет рабочий код из девяти строк, зачастую получает больше индуса, настрогавшего за это же время тысячу строк в которых три тысячи багов.

А вообще интересно, что среди моих коллег чистым кодингом никто не занимается. Чистый кодинг аутсорсивается в китай. А тут в штатах основное время уходит на постановку задачи, поиск решения, создание ядра системы, переговоры с начальством, обучение манагеров по продажам (чтобы знали что они продают), кстати, попутно меня поразило что у манагера по продажам на столе книга по ида и по реверсингу. И она уже изрядно зачитанная, то есть не просто лежит для виду.

Глупость вообще это меняться количеством строк, написанных в единицу времени. Хотя выше была речь только про сишников, а тут своя специфика. На сях обычно решаются довольно нетривиальные задачи, потому как все остальное уже решено и на фига изобретать велосипед. Даже если задача более или менее понятная и решение уже как бы известно, все равно — на непосредственную набивку текста уходит лишь маленькая толика времени. Грубо говоря за N времени готова плотная версия, а за 10*N ~ 100*N мы наконец довели ее до того состояния, когда она реально взлетела.

Было бы интересно а сколько у вас выходит строк в среднем? Берем проект. Берем дату создания первого файла. Берем дату последней версии. Считаем строки. Делим на время. Оглашаем результат.

ЗЫ. Ну а то, что пиковая производительность (у сишиника) порой доходит до пары килострок в день (без копипастинга) ну так это ж понятно. Не за то сейчас речь.

М>Было бы интересно а сколько у вас выходит строк в среднем? Берем проект. Берем дату создания первого файла. Берем дату последней версии. Считаем строки. Делим на время. Оглашаем результат.

автогенеренные строки считать?

Здравствуйте, e_k, Вы писали:


М>>Было бы интересно а сколько у вас выходит строк в среднем? Берем проект. Берем дату создания первого файла. Берем дату последней версии. Считаем строки. Делим на время. Оглашаем результат.

e_k>автогенеренные строки считать?
могучий вопрос. мы тут с товарищами никак не можем прийти к соглашению о кошерности автокомпита. тут кстати и другой вопрос. допустим, мне нужен драйвер. допустим, драйвер не сильно сложный и чтобы не писать его с нуля я беру готовый из DDK и точу его под свои нужды. как считать кол-во строк в этом случае? и главное зачем? собственно пост выше это идея подсчета строк доведенная до абсурда. хотя, насколько я в курсе, в некоторых фирмах кол-во строк является чуть ли не решающим фактором, определяющим степнь вклада и вовлеченности в проект. ужос.

Здравствуйте, мыщъх, Вы писали:

М>...сколько у вас выходит строк в среднем...
Когда-то считал, выходило до 400-500 в день, если задача была ясна и понятна. Но это с++.

Здравствуйте, мыщъх, Вы писали:

М>Учитывая, что зарплата у сишников начинается от $10k ~ $15k в месяц (и там же

А можно подробнее это где такая зарплата у сишников?

Здравствуйте, catBasilio, Вы писали:

B>Здравствуйте, мыщъх, Вы писали:

М>>Учитывая, что зарплата у сишников начинается от $10k ~ $15k в месяц (и там же

B>А можно подробнее это где такая зарплата у сишников?
и в россии в том числе. но это до уплаты налогов. после уплаты останется от $8k.

в штатах в калифорнии мои коллеги получают ~$135k годовых. в dc (на другом побережье) ~$170k

средний возраст моих сишных коллег лет сорок будет. так что тут еще нужно делать "наценку" на опыт, стаж и проч. средняя зараплата чистых сишников выше чем плюсовиков потому что среди сишников намного более выскоий процент сильных программистов. ну потому как очень странно если современный студент укажет в резюме: C89, C99 и после этого поставит жирную точку. типа список кончился

кстати, как правило кол-во перечисленных языков и технологий обратно пропорционально реальным навыкам


ЗЫ. если что, то я реверсер и программирую как умею.

Здравствуйте, мыщъх, Вы писали:

М>>>Учитывая, что зарплата у сишников начинается от $10k ~ $15k в месяц (и там же

B>>А можно подробнее это где такая зарплата у сишников?
М>и в россии в том числе. но это до уплаты налогов. после уплаты останется от $8k.
8K * 30 = 240 тыщ в месяц?
Что-то я явно пропустил в этой жизни... Я знаю достаточно много не побоюсь этого слова — гениальных сишников, которые работают в двух столицах, уважаемые люди, и получают они, тем не менее, не более сотни.

Теперь по теме:
За три года работы в одной крупной компании, я написал ~5 KLOC, но это — с учетом серьезного Процесса, соблюдением всех дисциплин и т.п.
Значит, незатейливая калькуляция показывает ~10$ / LOC. Неплохо!
С другой стороны, за тот же период, я написал несколько программ "для себя", суммарным объемом ~20 KLOC. Здесь стоимость LOC = 0$.
С третьей стороны, я помог вскрыть одну платную гадину, заменив три команды ассемблера. Стоимость двойного слова составила ~300$.
Помните тот анекдот, про механика? "1 бакс я взял за удар молотком, и 999 баксов за то, что знал куда ударить".

С уважением.

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, e_k, Вы писали:


М>>>Было бы интересно а сколько у вас выходит строк в среднем? Берем проект. Берем дату создания первого файла. Берем дату последней версии. Считаем строки. Делим на время. Оглашаем результат.

e_k>>автогенеренные строки считать?
М>могучий вопрос. мы тут с товарищами никак не можем прийти к соглашению о кошерности автокомпита.

Еще один могучий вопрос — нужно ли учитывать строки комментариев ? Мое мнение — обязательно надо учитывать.

Здравствуйте, мыщъх, Вы писали:

М>в штатах в калифорнии мои коллеги получают ~$135k годовых. в dc (на другом побережье) ~$170k

Это под виндой/юникс или без разницы?
Какие задачи решаются на Си, приведите пример чтобы представлять?

М>>>Учитывая, что зарплата у сишников начинается от $10k ~ $15k в месяц (и там же

B>>А можно подробнее это где такая зарплата у сишников?
М>и в россии в том числе. но это до уплаты налогов. после уплаты останется от $8k.

М>в штатах в калифорнии мои коллеги получают ~$135k годовых. в dc (на другом побережье) ~$170k

ну все, после ваших сумм у многих произошел выброс моска с последующим переучиваением на С, сразу поплыли картины Калифорнии с райском пляжем, горячей девушки рядом, ноута и банкомата с баксами.

зы: а если по делу, то писать на сях, это надо недюженной выдержкой обладать, т.к. любое элементарное действие выплывает в тонны кода...

Здравствуйте, мыщъх, Вы писали:

Гы, примерно вопрос из той же серии,
что и просьбв предоставить образец кода.

Я тут нашёл класс из пары строк,
из заголовка/комментариев к которому
следует, что он коммитился с изменениями
48 раз двумя десятками авторов

Здравствуйте, мыщъх, Вы писали:

Пробовал считать статистику по часам. У меня получалось 3 строки в человеко-час и 10 строк в час (на двух разных проектах). Это код который пошел в продукт.
Это С++, CAD, геометрия за 6-й класс...

Проекты обычно на 80% состояли из исследований. Строки/время общие, без выделения фазы "кодинга".

Пришел к выводу, что "10 строк в час" в принципе адекватная цифра. Только непригодна для того, чтобы делать орг. выводы по поводу их автора. Чем сложнее работа, тем меньше строк/час, но больше пользы для потребителя.

Здравствуйте, мыщъх, Вы писали:

М>...

некоторые люди признают эту метрику бессмысленной.
Отчасти из-за того, что она подменяет внутреннюю мотивацию внешней (знаю со слов знакомого бизнесмена).

Здравствуйте, мыщъх, Вы писали:

Не скажу за Cи, но в C++ если правильно наследоваться и вовсю использовать методики повторного использования кода, то 20 строк кода в день могут иметь огромный вес, это как карточный домик, чем выше домик тем нужно аккуратнее ложить карточки иначе можна навернуть весь дом

Здравствуйте, мыщъх, Вы писали:

М>Было бы интересно а сколько у вас выходит строк в среднем? Берем проект. Берем дату создания первого файла. Берем дату последней версии. Считаем строки. Делим на время. Оглашаем результат.

М>ЗЫ. Ну а то, что пиковая производительность (у сишиника) порой доходит до пары килострок в день (без копипастинга) ну так это ж понятно. Не за то сейчас речь.

Часть проекта from scratch ~3-6 kloc/week -> 50 loc/h .
+Тесты ~10 kloc (но много copy-paste) -> 300 loc/h.
+Автогенерёнка — на генератор дней 10 -> ~1M loc -> 20 kloc/h.

Здравствуйте, UA, Вы писали:

UA>Не скажу за Cи, но в C++ если правильно наследоваться и вовсю использовать методики повторного использования кода, то 20 строк кода в день могут иметь огромный вес, это как карточный домик, чем выше домик тем нужно аккуратнее ложить карточки иначе можна навернуть весь дом

Значит связанность слишком высокая.

Здравствуйте, traveler, Вы писали:

T>Здравствуйте, мыщъх, Вы писали:

М>>>>Учитывая, что зарплата у сишников начинается от $10k ~ $15k в месяц (и там же

B>>>А можно подробнее это где такая зарплата у сишников?
М>>и в россии в том числе. но это до уплаты налогов. после уплаты останется от $8k.
T>8K * 30 = 240 тыщ в месяц?
вполне достойная зарплата. знакомые (в москве) получают и триста.

T> Что-то я явно пропустил в этой жизни...
"невероятно, но факт" (с)

T> Я знаю достаточно много не побоюсь этого слова — гениальных сишников,
T> которые работают в двух столицах, уважаемые люди, и получают они,
T> тем не менее, не более сотни.
а вот мои коллеги без всякой претензии на гениальность в лучшем случае улыбнуться, а худшем сочтут сотку грабежом и оскорблением. одна контора из израиля пыталась аутсорсить им несколько проектов с готовым ТЗ, в котором сишники сходу нашли кучу ляпов, нестыковок, косяков и предложили израильтянам или мы делаем по русски (т.е. по уму) за три ляма в год на рыло, или вы идете дорогой давида. израильтяне помялись сначала, но потом таки согласились. и хотя я не в курсе последних событий — обе стороны довольны. причем, это не финансовые проекты и даже софт для боингов, и математики там немного. обычный системный софт под линь. и это в россии с оплатой белой зарплатой и трудойстройством по ТК, хотя пиплы работают непосредственно на европу и запад. имена сишников обозначать не буду, т.к. не уполномочен, но думаю, что вы их знаете. даже если не лично, то слышали о них, т.к. они уже успели "засветиться" в куче продуктов как под линь, так и под винду.

зы. поинтересуйтесь сколько получают ребята, которые на стыке разлома ссср стыбрили из беркли бзди и перехачили его в унах, позже переименнованный в дэмос. там один антонов чего стоит.

T>Значит, незатейливая калькуляция показывает ~10$ / LOC. Неплохо!
вот, а вы еще на жизнь жалуетесь

T> С третьей стороны, я помог вскрыть одну платную гадину, заменив три команды ассемблера.
T> Стоимость двойного слова составила ~300$.
в двойных словах считать я бы не догадался. а почему не в байтах?

T> Помните тот анекдот, про механика? "1 бакс я взял за удар молотком,
T> и 999 баксов за то, что знал куда ударить".
только хотел его процитировать, но вы меня опередили

Здравствуйте, Flying Dutchman, Вы писали:

М>>>>Было бы интересно а сколько у вас выходит строк в среднем? Берем проект. Берем дату создания первого файла. Берем дату последней версии. Считаем строки. Делим на время. Оглашаем результат.

e_k>>>автогенеренные строки считать?
М>>могучий вопрос. мы тут с товарищами никак не можем прийти к соглашению о кошерности автокомпита.

FD>Еще один могучий вопрос — нужно ли учитывать строки комментариев ? Мое мнение — обязательно надо учитывать.

Очень часто (хотя, конечно, не всегда) строки комментариев надо учитывать со знаком минус

Здравствуйте, legogogo, Вы писали:

L>Здравствуйте, мыщъх, Вы писали:

М>>в штатах в калифорнии мои коллеги получают ~$135k годовых. в dc (на другом побережье) ~$170k
L>Это под виндой/юникс или без разницы?
под линух. винду я последнее время вижу все реже и реже.

L>Какие задачи решаются на Си, приведите пример чтобы представлять?
$135k для калифорнии это хорошие деньги, но вовсе не мегакул. мои знакомые оттуда заняты криптографией, защитой блю-рей на жабе, разработкой трансляторов с си на примитивные виртуальные машины (типа чтобы и сорцы клиенту отдать, которые компилируются на любых никсах, но и не позволить ему ими завладеть, ибо что интересного можно сделать, например, с кодом для сетей петри? или стрелкой пирса? да ничего с ней нельзя сделать, только тупо откомпилировать, чтобы собралась в бинарник на данной архитектуре гнутым си — а вы говорите, что под линь никто ничего не защищает).

в dc у меня знакомых уже побольше будет, в основном все сетевики. о себе говорят, что занимаются контент анализом. что это такое я до конца так и не понял, поэтому объясниить могу только на примерах. ну это как бы написание декомпрессоров для разных пакеров, декомпиляторов, парсеров и всего такого.

сам же я пишу утилиты для реверсеров и приблуды облегчающие написание сигнатур. на си. или даже на ида-си. а еще есть микро-си, который есть подмножество си (довольно сильно урезанное) и на нем люди тоже пишут, ну а я же пока только к нему присматриваюсь.

Здравствуйте, ARMSoft, Вы писали:

М>>в штатах в калифорнии мои коллеги получают ~$135k годовых. в dc (на другом побережье) ~$170k
ARM>ну все, после ваших сумм у многих произошел выброс моска с последующим переучиваением на С,
да ладно вам. в калифорнии $75k это то, на что может претендовать _рядовой_ прикладник (дотнет, жаба), с опытом работы от трех лет. причем, разницу между дотнетом и сями мне думаю вам объяснять не надо. дотнет весчь в себе. а нормальный программист на си обычно знает во что компилируется его программа, знает "кухню" операционной системы, вникая в кучу низкоуровневых подробностей. разница в объеме знаний — колоссальна. разница в зарплате — где-то в два, ну в три раза. плюс реального рынка труда для сишников нет. работа есть, и работы валом. но вот рынка — нет. впрочем, сишники и работу меняют гораздо реже.

> сразу поплыли картины Калифорнии с райском пляжем, горячей девушки рядом, ноута и банкомата с баксами.
банкоматов здесь что-то не особо видно (или просто я их не замечаю). видел в порту. в городе не встречал. хотя специально и не искал, может они где и стоят. ноуты — гадость. сейчас надо кодить, а рабочей станции под рукой нет, а заказывать — так грят ее только в начале января доставят. вот вам и сша. зато тут есть куча серверов. щас на одном из них развертываем линух, на котором запустим варю, а из под вари мой имаге с привычным мне окружением. причем сервер до жути тормозной. всего два с хвостиком мегагерца. процессоров до кучи, но мне ж все равно только один использовать. вот и приходится выкручиваться.

не, калифорния не для меня. хотя есть вариант перебраться в санта-клару, я лучше тут с белками в рестоне.

ARM> зы: а если по делу, то писать на сях, это надо недюженной выдержкой обладать,
ARM> т.к. любое элементарное действие выплывает в тонны кода...
гм. мне казалось, что на плюсах оверхид выше. и там где у меня десяток функций и приплюснутых коллег развернутра могучая иерархия классов с запутанным наследованием. так же мне кажется, что реюз кода на си проще. в смысле, что вот у меня одна функция искала регулярные выражения и парсила жабу на лету. поскольку писалось все это на быструю руку и поиск был тупой как валенок, то это быстро работало лишь на небольшом кол-ве сигнатур. а сейчас было приятно решение переписать эту функцию по науке, разделив ее собственно на парсер и поиск. на сях это заняло меньше получаса (хотя там была дикая мешанина кода). а вот на плюсах изначально кривой дизайн так быстро уже не исправишь.

Здравствуйте, мыщъх, Вы писали:

М>гм. мне казалось, что на плюсах оверхид выше. и там где у меня десяток функций и приплюснутых коллег развернутра могучая иерархия классов с запутанным наследованием....

Скажите, вы С++ знаете? Насколько хорошо? Спрашиваю без подколок, просто интересно.

Здравствуйте, legogogo, Вы писали:

L>Здравствуйте, мыщъх, Вы писали:

М>>в штатах в калифорнии мои коллеги получают ~$135k годовых. в dc (на другом побережье) ~$170k

L>Это под виндой/юникс или без разницы?
L>Какие задачи решаются на Си, приведите пример чтобы представлять?
В системном программировании в основном используется С но не С++.
Почему не С++ это отдельная тема.

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, catBasilio, Вы писали:

B>>Здравствуйте, мыщъх, Вы писали:

М>>>Учитывая, что зарплата у сишников начинается от $10k ~ $15k в месяц (и там же

B>>А можно подробнее это где такая зарплата у сишников?
М>и в россии в том числе. но это до уплаты налогов. после уплаты останется от $8k.

М>в штатах в калифорнии мои коллеги получают ~$135k годовых. в dc (на другом побережье) ~$170k

М>средний возраст моих сишных коллег лет сорок будет. так что тут еще нужно делать "наценку" на опыт, стаж и проч. средняя зараплата чистых сишников выше чем плюсовиков потому что среди сишников намного более выскоий процент сильных программистов. ну потому как очень странно если современный студент укажет в резюме: C89, C99 и после этого поставит жирную точку. типа список кончился

М>кстати, как правило кол-во перечисленных языков и технологий обратно пропорционально реальным навыкам


М>ЗЫ. если что, то я реверсер и программирую как умею.
В Штатах есть и програмеры которые и на Java получают в 2-3 раза больше.
Некоторые области финансового сектора.

Здравствуйте, legogogo, Вы писали:

L>Здравствуйте, мыщъх, Вы писали:

М>>гм. мне казалось, что на плюсах оверхид выше. и там где у меня десяток функций и приплюснутых коллег развернутра могучая иерархия классов с запутанным наследованием....

L>Скажите, вы С++ знаете? Насколько хорошо? Спрашиваю без подколок, просто интересно.
как я написал в одном своем резюме: "плюсы это целый мир, а я владею лишь крошечной его частью". резюме вышло зачотным, hr от дущи посмеялась и сказала, ну вот наконец хоть один честно признался.

для меня плюсы это... как бы си с классами (которые я воспринимаю как структуры). на этом мои познания собственно и заканчиватся. то есть в конторе в которой пишут на плюсах я только дворником устроюсь. ну не мое это... "язык определяет мышление" (с), а мыслить категориями плюсов я не могу (особенно парадигмами метапрограммирования). потому в рашке морально похоронил себя, занимаясь книгописательством, т.к. слабо верил, что можно найти работу без плюсов и без дельфи. а тут в штатах оказывается всем работы хватает. к тому же так стихийно сложилось, что я оказалася в крошечном тиме огромной фирмы, где каждый делает свое и в чужой код лезть нет надобности. главное -- это интерфейс/протокол взаимодействия модулей, а в детали реализации коллеги не вникают. ну а законченный модуль, который выдает результат "завернутый" в xml, вообще без разницы на чем написан, главное чтобы под линухом работал и гнусем собирался

к тому же как я писал выше, по статусу я реверс инженер, т.е. совсем не программер и потому незнание плюсов меня совсем не напрягает. (хотя, конечно, чтобы реверсить приплюснутые приложения нужно знать хотя бы что такое виртуальные функции и как они выглядят — но это как бы совсем неглубокий уровень владения языком).

Здравствуйте, мыщъх, Вы писали:

М>гм. мне казалось, что на плюсах оверхид выше.
Сказки. Если делать по уму то очень часто получается наоборот...
Например при правильной реализации исключений код с исключениями работает быстрее чем код с кодами возврата. Проверено.
Шаблоны позволяют сильно сжимать объем кода плюс благодоря агрессивному инлайну повышается производительность.

М>и там где у меня десяток функций и приплюснутых коллег развернутра могучая иерархия классов с запутанным наследованием.
Этих твоих колег в дворники.

М>так же мне кажется, что реюз кода на си проще. в смысле, что вот у меня одна функция искала регулярные выражения и парсила жабу на лету. поскольку писалось все это на быструю руку и поиск был тупой как валенок, то это быстро работало лишь на небольшом кол-ве сигнатур. а сейчас было приятно решение переписать эту функцию по науке, разделив ее собственно на парсер и поиск. на сях это заняло меньше получаса (хотя там была дикая мешанина кода). а вот на плюсах изначально кривой дизайн так быстро уже не исправишь.
Не согласен.

Более того существуют вещи которые на С практически не реализуемы. Например http://antigrain.com/
При попытке переписать на С будет либо значительная просадка производительности либо раздутие кода в десятки раз.
Я когда возился с изображениями тоже шаблонил по черному.

Если же переходить к еще более сложным задачам типа оптимизирующих компиляторов то использовать С++ и тем более С это просто глупость.
Вот например простенький оптимизатор http://code.google.com/p/nemerle/source/browse/nemerle/trunk/snippets/peg-parser/LRPEGCC/Optimizer.OptimizeRule.n
Попытка реализовать этот функционал на императивном языке привидет к раздутию кода наверное раз в 10. Я уже не говорю по его поддержку.

Здравствуйте, мыщъх, Вы писали:

М> а мыслить категориями плюсов я не могу (особенно парадигмами метапрограммирования).

А не пробовали разобраться с метапрограммированием в Lisp-е, например. Возможно в его диалекте Scheme. Или присмотреться к Haskell-ю.

Просто метапрограммирование в C++ как бы есть, но в конечном итоге какоето кривое и недоделанное. На эту тему здесь на rsdn несколько лет назад был очень хороший топик

Автор:
Дата: 09.07.05

Здравствуйте, WolfHound, Вы писали:


WH>При попытке переписать на С будет либо значительная просадка производительности либо раздутие кода в десятки раз.

Я всегда подазревал что Linux kernel это просадка производительности и раздутия кода в десятки разы так как написан на С. Я непонимал в чем причина и вы открыли мне глаза.Если бы он был написан на С++ то код был бы в 10 раз меньше и Linux просто бы летал.Обязательно сообщите об этом Linus.

Здравствуйте, eagersh, Вы писали:

E>Здравствуйте, мыщъх, Вы писали:

М>>ЗЫ. если что, то я реверсер и программирую как умею.
E>В Штатах есть и програмеры которые и на Java получают в 2-3 раза больше.
E>Некоторые области финансового сектора.
да я в курсе. а если еще взять тех, кто пилит бюджет, то и покруче будет. и даже без бюджета. тут один мужик который курит нейросети пишет систему для предсказания загрузки авиалиний. пишет он ее на жабе почему-то. получает $300k и $100k бонусов. причем система у него реально очень мало что предсказывает. она просто выделяет какие-то там паттерны. очень часто ошибается, но это никого не волнует, потому как компания большая, а он маленький.

Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>Здравствуйте, Flying Dutchman, Вы писали:

М>>>>>Было бы интересно а сколько у вас выходит строк в среднем? Берем проект. Берем дату создания первого файла. Берем дату последней версии. Считаем строки. Делим на время. Оглашаем результат.

e_k>>>>автогенеренные строки считать?
М>>>могучий вопрос. мы тут с товарищами никак не можем прийти к соглашению о кошерности автокомпита.

FD>>Еще один могучий вопрос — нужно ли учитывать строки комментариев ? Мое мнение — обязательно надо учитывать.

ТКС>Очень часто (хотя, конечно, не всегда) строки комментариев надо учитывать со знаком минус

Конечно. Как говорил Страуструп, "Написать хороший комментарий зачастую сложнее, чем саму программу".

Здравствуйте, eagersh, Вы писали:

E>Я всегда подазревал что Linux kernel это просадка производительности и раздутия кода в десятки разы так как написан на С. Я непонимал в чем причина и вы открыли мне глаза.Если бы он был написан на С++ то код был бы в 10 раз меньше и Linux просто бы летал.Обязательно сообщите об этом Linus.

А также Гейтсу и Баллмеру. Ядро виндов ведь тоже на чистом Си написано. Вообще есть немало очень крупных систем, написанных на Си.

Здравствуйте, мыщъх, Вы писали:

ARM>> зы: а если по делу, то писать на сях, это надо недюженной выдержкой обладать,
ARM>> т.к. любое элементарное действие выплывает в тонны кода...
М>гм. мне казалось, что на плюсах оверхид выше. и там где у меня десяток функций и приплюснутых коллег развернутра могучая иерархия классов с запутанным наследованием.
Это какие то коллеги странные видимо.
На С++ можно писать как на С с классами и темплейтами, так и в стиле "меня в полнолуние укусил Александреску".

М> так же мне кажется, что реюз кода на си проще.
Реюз нормально структурированного кода проще. На С или на С++ уже второе дело.

М> в смысле, что вот у меня одна функция искала регулярные выражения и парсила жабу на лету. поскольку писалось все это на быструю руку и поиск был тупой как валенок, то это быстро работало лишь на небольшом кол-ве сигнатур. а сейчас было приятно решение переписать эту функцию по науке, разделив ее собственно на парсер и поиск. на сях это заняло меньше получаса (хотя там была дикая мешанина кода). а вот на плюсах изначально кривой дизайн так быстро уже не исправишь.
Кривой дизайн на С точно так же придётся переделывать.

Здравствуйте, мыщъх, Вы писали:

М>а мыслить категориями плюсов я не могу (особенно парадигмами метапрограммирования).
В С++ дефакто нет метапрограммирования. Есть извращенцы, которые пытаются заниматься метапрограммированием на С++.

Здравствуйте, eagersh, Вы писали:

WH>>Более того существуют вещи которые на С практически не реализуемы. Например http://antigrain.com/
WH>>При попытке переписать на С будет либо значительная просадка производительности либо раздутие кода в десятки раз.
E>Я всегда подазревал что Linux kernel это просадка производительности и раздутия кода в десятки разы так как написан на С. Я непонимал в чем причина и вы открыли мне глаза.Если бы он был написан на С++ то код был бы в 10 раз меньше и Linux просто бы летал.Обязательно сообщите об этом Linus.
Я востановил ту часть цитаты которую ты вырезал.
Теперь объясни мне причем тут линух?
Ибо я говорил про вполне конкретную библиотеку.

Здравствуйте, мыщъх, Вы писали:

B>>>>А можно подробнее это где такая зарплата у сишников?
М>>>и в россии в том числе. но это до уплаты налогов. после уплаты останется от $8k.
T>>8K * 30 = 240 тыщ в месяц?
М>вполне достойная зарплата. знакомые (в москве) получают и триста.

Скажите, пожалуйста, куда резюме отправить?
Уж я не подведу! (никого еще не подводил)

T>> С третьей стороны, я помог вскрыть одну платную гадину, заменив три команды ассемблера.
T>> Стоимость двойного слова составила ~300$.
М>в двойных словах считать я бы не догадался. а почему не в байтах?

Потому что один великий мудрец (это сарказм), в великой книге "Техника оптимизации программ. Эффективное использование памяти.", которую я прочитал не менее десяти раз (это лесть), упомянул, что работать двойными словами эффективнее, нежели байтами.
Т.е. если на байты пересчитать — дешевле выйдет...

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, eagersh, Вы писали:

WH>>>Более того существуют вещи которые на С практически не реализуемы. Например http://antigrain.com/
WH>>>При попытке переписать на С будет либо значительная просадка производительности либо раздутие кода в десятки раз.
E>>Я всегда подазревал что Linux kernel это просадка производительности и раздутия кода в десятки разы так как написан на С. Я непонимал в чем причина и вы открыли мне глаза.Если бы он был написан на С++ то код был бы в 10 раз меньше и Linux просто бы летал.Обязательно сообщите об этом Linus.
WH>Я востановил ту часть цитаты которую ты вырезал.
WH>Теперь объясни мне причем тут линух?
WH>Ибо я говорил про вполне конкретную библиотеку.
Я просто хотел показать что есть проэкты в которых использования С++ приведет к "значительной просадки производительности либо раздутие кода в десятки раз".Если мыщъх исльзует С а не С++ то на это есть обьективные причины.

20к строчек кода за полтора года писания(это правда с++), при этом первые полгода я совмещал с работой на работодателя, хотя он(работодатель) и был довольно халявный(яндекс) и я много времени занимался своим проектом прямо на рабочем месте. при этом специфика моего проекта такова, что я большую часть кода(уж половину точно) могу удалить- и ничего не изменится, но держу я этот код только потому, что там реализованны кое какие идеи, которые не подошли сейчас, но могут подойти в дальнейшем.

Здравствуйте, eagersh, Вы писали:

E>Я просто хотел показать что есть проэкты в которых использования С++ приведет к "значительной просадки производительности либо раздутие кода в десятки раз".
Ты вообще эти языки знаешь или или просто докопаться пытаешься?
Ибо при наличии прямых рук код на С++ гарантированно не медленней и не больше чем на С.
Просто по тому что С++ надмножество С.

E>Если мыщъх исльзует С а не С++ то на это есть обьективные причины.
Я не знаю по каким причинам мыщъх использует С но я точно знаю что все твои "аргументы" объективно ложны.

Здравствуйте, eagersh, Вы писали:

E> Если мыщъх исльзует С а не С++ то на это есть обьективные причины.
"почему вы ее называете во множественном числе?" (с).
причина одна — незнание плюсов. раньше думал, что "незнание плюсов" ==> "невозможность найти работу" (дельфи и php я так же не знаю, как и жабу).

но оказалось, что в сша можно программировать на чем угодно. к тому же поскольку по статусу я реверсер, то и тестировали меня как реверсера. а вот если бы устраивался как девелопер, то вероятнее всего и смотреть в мою сторону не стали.

в принципе, компанию вполне устраивает комбинация моих навыков (опытый реверсер и посредственный девелопер), грят это не так уж и часто встречается, хотя в россии очень много сильных реверсеров и сильных девелоперов. как, кстати, и на украине. и в беларусии.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, eagersh, Вы писали:

E>>Я просто хотел показать что есть проэкты в которых использования С++ приведет к "значительной просадки производительности либо раздутие кода в десятки раз".
WH>Ты вообще эти языки знаешь или или просто докопаться пытаешься?
WH>Ибо при наличии прямых рук код на С++ гарантированно не медленней и не больше чем на С.
WH>Просто по тому что С++ надмножество С.

E>>Если мыщъх исльзует С а не С++ то на это есть обьективные причины.
WH>Я не знаю по каким причинам мыщъх использует С но я точно знаю что все твои "аргументы" объективно ложны.
Знаю оба языка.И знаю что например в системном програмировании используется в основном С. С++ можно теоритически использовать но это большой геморой и иногда просто небезопасно если не понимаешь какой код генерируется.
Насчет аргументов напиши лучше об этом Linus как я тебе советовал раньше.

Здравствуйте, мыщъх, Вы писали:

М>Здравствуйте, eagersh, Вы писали:

E>> Если мыщъх исльзует С а не С++ то на это есть обьективные причины.
М>"почему вы ее называете во множественном числе?" (с).
М>причина одна — незнание плюсов. раньше думал, что "незнание плюсов" ==> "невозможность найти работу" (дельфи и php я так же не знаю, как и жабу).

М>но оказалось, что в сша можно программировать на чем угодно. к тому же поскольку по статусу я реверсер, то и тестировали меня как реверсера. а вот если бы устраивался как девелопер, то вероятнее всего и смотреть в мою сторону не стали.

М>в принципе, компанию вполне устраивает комбинация моих навыков (опытый реверсер и посредственный девелопер), грят это не так уж и часто встречается, хотя в россии очень много сильных реверсеров и сильных девелоперов. как, кстати, и на украине. и в беларусии.
Мой point был в том что если ты работаешь в основном с ядром то должен использовать С и асемблер.Поэтому и навыки на С должны быть сильнее.

Здравствуйте, eagersh, Вы писали:

E>Мой point был в том что если ты работаешь в основном с ядром то должен использовать С и асемблер.
E>Поэтому и навыки на С должны быть сильнее.
с этим согласен. выгоды от плюсов в тех же драйверах в упор не вижу. кроме того раздражает, что рядовой приплюснутый программист совершенно не в курсе что такое память (оперативная) и чем стек от кучи вообще отличается и почему статические массивы иногда на порядок быстрее, а то и на два. ну а то, что они потоконебезопасны — это заблуждение. просто не нужно писать так: foo(){static... buf[x];} нужно так: buf[x]; foo(X_HANDLE x)}{}, где в x лежит указатель на buf, а хэндл для всех потоков разный. (гусары: ни слова о том, что это фактически свой собственный мини-аллокатор памяти!)

eagersh пишет:
>
> WH>Ибо при наличии прямых рук код на С++ гарантированно не медленней и
> не больше чем на С.
> Знаю оба языка.И знаю что например в системном програмировании
> используется в основном С. С++ можно теоритически использовать но это
> большой геморой и иногда просто небезопасно если не понимаешь какой код
> генерируется.
Значит не знаешь. Исходя из моего опыта, качество кода зависит только от
прямизны рук, но ни как не от С или С++.
Причем С на прямизну рук накладывает даже большие требования, чем С++.

Здравствуйте, мыщъх, Вы писали:

М>Учитывая, что зарплата у сишников начинается от $10k ~ $15k в месяц (и там же и заканчивается), то в первом приближении мы имеем $169 за строку, а при средней длине строки в 30 символов (зависит от форматирования, конечно, но все равно это очень грубый результат), получается $6 баксов за одну нажатую клавишу. Или $3 за нажатую, а $3 за отпущенную.

Зажрались вы ( мы ), вот что я вам скажу.

Только твоё сравнение некорректно. Если ты будешь просто "топтать клаву" — очень быстро твои 10-15к в месяц превратятся в пособие по безработице. Даже если написнное синтаксически правильное и даже будет компиляться. Платят не за строчки кода, а за то, чтоб работало (да, я сегодня за Капитана Очевидность)

Здравствуйте, мыщъх, Вы писали:

E>>Мой point был в том что если ты работаешь в основном с ядром то должен использовать С и асемблер.
E>>Поэтому и навыки на С должны быть сильнее.
М>с этим согласен. выгоды от плюсов в тех же драйверах в упор не вижу. кроме того раздражает, что рядовой приплюснутый программист совершенно не в курсе что такое память (оперативная) и чем стек от кучи вообще отличается и почему статические массивы иногда на порядок быстрее, а то и на два. ну а то, что они потоконебезопасны — это заблуждение.
Просто изучать надо сначала асм, потом С и только потом С++. Ну и понимать надо как работает эта вся подкапотная автоматика, которую С++ компилер генерит. Прикладники этого всего как правило не понимают вообще, витая в абстракциях.

Здравствуйте, мыщъх, Вы писали:
М>Было бы интересно а сколько у вас выходит строк в среднем? Берем проект. Берем дату создания первого файла. Берем дату последней версии. Считаем строки. Делим на время. Оглашаем результат.
полгода писал последний С++ проект. сейчас как раз закончил, перехожу к новому.
16300 строк, 120 рабочих дней -> 136 строк в день

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, мыщъх, Вы писали:

CC>Просто изучать надо сначала асм, потом С и только потом С++. Ну и понимать надо как работает эта вся подкапотная автоматика, которую С++ компилер генерит. Прикладники этого всего как правило не понимают вообще, витая в абстракциях.

СОВЕРШЕННО СОГЛАСЕН!!! После 11 лет asm (причем разных, писал свои классы), и 13 лет С/С++ (где представляешь, куда какой байтик выкладывается и кто к нему может доступиться) С# вызывает дикую неприязнь с его тупизной, но что делать — зкакзчик хочет... У меня сын пишет — как домино — попка к попке — не представляя, как реально это будет выполняться на железе.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, мыщъх, Вы писали:

CC> Просто изучать надо сначала асм, потом С и только потом С++.
имхо начинать с асма в нашу эпоху будет тяжело. уж лучше сначала си, потому как это ж не ms-dos. тут асм погружает человека в такую пучину деталей, что из нее будет скорее всего никогда и не выбраться, только погружаться все дальше и дальше. к тому же, если мы использем мпорт API функций, то асм так же скрывает что у нас находится под капотом и как _реально_ происходит вызов функции. уж лучше брать отладчик в руки и смотреть сишную программу с отрезанным rtl.

> Ну и понимать надо как работает эта вся подкапотная автоматика, которую С++ компилер генерит.
> Прикладники этого всего как правило не понимают вообще, витая в абстракциях.
вот я и говорю. скажем исключения в плюсах. ускорить программу они никак не могут. ее могут (могли бы) ускорить только аппаратные исключения, но их нет... отловы нулевого указателя не в счет, т.к. накладные расходы на вызов функции распределеня памяти или открытия файла несопостовимы со временем проверки результата возврата.

а так исключения в плюсах это грубо говоря встроенный диспетчер сообщений. на си он пишется влет, причем заточенный под нужды конкретной задачи, а не вообще и в целом.

и что самое смешное, люди которые готовы убить за goto, пропагандируют исключения, которые еще хуже, чем goto, поскольку goto err это не лапша и сразу понятно кто у нас обрабатывает ошибку (ну или long jump), а вот исключения вообще непонятно кто и как обрабатывает. там временами такое спагетти образуется, что распутать его совершенно невозможно. и не нужно говорить, что это вина не исключений, а тех дэбилов, которые их бездумно используют.

исключения (как и goto) делают логику программы неоднозачной. типа выпрыгнули тут, а упали совсем в другом месте, где нас не ждали.

короче говоря, моя точка зрения такова: человек который знает что находится под капотом плюсов в большинстве случаев сделает все это и на си, причем работать оно будет не хуже, а скорее всего даже лучше (в рамках данной задачи).

Здравствуйте, alzt, Вы писали:

UA>>Не скажу за Cи, но в C++ если правильно наследоваться и вовсю использовать методики повторного использования кода, то 20 строк кода в день могут иметь огромный вес, это как карточный домик, чем выше домик тем нужно аккуратнее ложить карточки иначе можна навернуть весь дом

Даже не представляю, что и как можно повторно использовать??? Из личного опыта — усилия и время на унификацию для повторного использования затрачиваются больше, чем доводка под новую конкретную задачу. Кстати — и в ХР программировании о том же (в смысле — не париться о повторном использовании).

Здравствуйте, frogkiller, Вы писали:

F>Здравствуйте, мыщъх, Вы писали:

М>>Учитывая, что зарплата у сишников начинается от $10k ~ $15k в месяц (и там же и заканчивается), то в первом приближении мы имеем $169 за строку, а при средней длине строки в 30 символов (зависит от форматирования, конечно, но все равно это очень грубый результат), получается $6 баксов за одну нажатую клавишу. Или $3 за нажатую, а $3 за отпущенную.

F>Зажрались вы ( мы ), вот что я вам скажу.

F>Только твоё сравнение некорректно. Если ты будешь просто "топтать клаву" — очень быстро твои 10-15к в месяц превратятся в пособие по безработице. Даже если написнное синтаксически правильное и даже будет компиляться. Платят не за строчки кода, а за то, чтоб работало (да, я сегодня за Капитана Очевидность)

так ведь это и есть мой поинт. производительность труда к строчкам кода не имеет ни малейшего отношения, особенно когда продукт уже взлетел и вдруг забарахлил в полете. и тут уже начинаешь думать как его пофиксить так, чтобы окончательно не свалить его в штопор. и тут чем меньше изменений вносится для устранения проблемы — тем лучше.

кстати, тезис "платят за то, чтобы работало" тоже как бы не совсем верный. если оно работает, то платят только один раз. а вот чтобы платили постоянно надо добиться, чтобы оно как бы работало, но и как бы не совсем. это на рынке шаровар платят за решения (да и то с оговорками). а при работе на фирму платят за работу. т.е. даже в штатах ситуация не сильно отличается от ссср. хожу на работу — получаю зарплату. а если еще и работаю — то зарплату + премию

Здравствуйте, мыщъх,

М>кстати, тезис "платят за то, чтобы работало" тоже как бы не совсем верный. если оно работает, то платят только один раз. а вот чтобы платили постоянно надо добиться, чтобы оно как бы работало, но и как бы не совсем. это на рынке шаровар платят за решения (да и то с оговорками). а при работе на фирму платят за работу. т.е. даже в штатах ситуация не сильно отличается от ссср. хожу на работу — получаю зарплату. а если еще и работаю — то зарплату + премию
--
Этот тезис может быть верным только для конторы, которая имеет один-единственный продукт и продала его одному-единственному клиенту. Вспомнить таких контор (работаюших в около-компютерных областях) мне как-то сходу не удалось. И если даже такая есть, то я уверен, что с такой стратегией протянет она на рынке не дольше одного квартала.

C уважением,
Геннадий Майко

Здравствуйте, Геннадий Майко, Вы писали:

ГМ>Этот тезис может быть верным только для конторы, которая имеет один-единственный продукт и продала его одному-единственному клиенту. Вспомнить таких контор (работаюших в около-компютерных областях) мне как-то сходу не удалось. И если даже такая есть, то я уверен, что с такой стратегией протянет она на рынке не дольше одного квартала.

Один продукт — согласен, один клиент — не обязательно. Таких контор полно — кто пишет банковские дни (штук 5), распознавалки/переводчики, антивирусники, CRM и т.д. Т.е. — те, кто имеют коробочный продукт, а не делают дяде какие-то мелкие компоненты.

Здравствуйте, Vzhyk, Вы писали:

V>eagersh пишет:
>>
>> WH>Ибо при наличии прямых рук код на С++ гарантированно не медленней и
>> не больше чем на С.
>> Знаю оба языка.И знаю что например в системном програмировании
>> используется в основном С. С++ можно теоритически использовать но это
>> большой геморой и иногда просто небезопасно если не понимаешь какой код
>> генерируется.
V>Значит не знаешь. Исходя из моего опыта, качество кода зависит только от
V>прямизны рук, но ни как не от С или С++.
V>Причем С на прямизну рук накладывает даже большие требования, чем С++.
Это ты не в теме.Попробуй написать драйвер на С++ для Windows. После этого твои прямые руки станут кривыми
Можешь также почитать вот это.
http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx

Здравствуйте, мыщъх, Вы писали:

М>вот я и говорю. скажем исключения в плюсах. ускорить программу они никак не могут.
Твое утверждение противоречит экспериментальным данным.

М>а так исключения в плюсах это грубо говоря встроенный диспетчер сообщений. на си он пишется влет, причем заточенный под нужды конкретной задачи, а не вообще и в целом.
Все можно написать на асме. Вот только стоит ли?

М>и что самое смешное, люди которые готовы убить за goto, пропагандируют исключения, которые еще хуже, чем goto, поскольку goto err это не лапша и сразу понятно кто у нас обрабатывает ошибку (ну или long jump), а вот исключения вообще непонятно кто и как обрабатывает. там временами такое спагетти образуется, что распутать его совершенно невозможно. и не нужно говорить, что это вина не исключений, а тех дэбилов, которые их бездумно используют.
Именно так.
Ибо исключения нужны исключительно в исключительных ситуациях.
И при правильном подходе при чтении кода в котором летают исключения вообще не приходится заострять на них внимания ибо они не пересекаются с основной логикой программы.

М>короче говоря, моя точка зрения такова: человек который знает что находится под капотом плюсов в большинстве случаев сделает все это и на си, причем работать оно будет не хуже, а скорее всего даже лучше (в рамках данной задачи).
Я очень хорошо знаю что там под капотом вот только в использовании С не вижу ну совсем никакого смысла.
Что касается сделать лучше то попробуй переписать http://antigrain.com/ (лучшая в мире библиотека для растеризации векторных изображений) на С.

eagersh пишет:
>
> V>Причем С на прямизну рук накладывает даже большие требования, чем С++.
> Это ты не в теме.Попробуй написать драйвер на С++ для Windows. После
> этого твои прямые руки станут кривыми
У меня немного другая область. Распознавание образов, причем
периодически на таком говне, как ARM, приходится пускать и плюсы мне
сильно подходят, главное в первую очередь голову применять.
А так вот рядом парень работал, дрова писал под разное свое
специфическое железо и С++ использовал вовсю, вот только он еще и голову
использовал.

Здравствуйте, мыщъх, Вы писали:

>> Ну и понимать надо как работает эта вся подкапотная автоматика, которую С++ компилер генерит.
>> Прикладники этого всего как правило не понимают вообще, витая в абстракциях.
М>вот я и говорю. скажем исключения в плюсах. ускорить программу они никак не могут. ее могут (могли бы) ускорить только аппаратные исключения, но их нет... отловы нулевого указателя не в счет, т.к. накладные расходы на вызов функции распределеня памяти или открытия файла несопостовимы со временем проверки результата возврата.

С исключениями тупо меньше проверок. Если тащишь код возврата через 10 уровней, придется на каждом его проверять.

М>и что самое смешное, люди которые готовы убить за goto, пропагандируют исключения, которые еще хуже, чем goto, поскольку goto err это не лапша и сразу понятно кто у нас обрабатывает ошибку (ну или long jump), а вот исключения вообще непонятно кто и как обрабатывает. там временами такое спагетти образуется, что распутать его совершенно невозможно. и не нужно говорить, что это вина не исключений, а тех дэбилов, которые их бездумно используют.

М>исключения (как и goto) делают логику программы неоднозачной. типа выпрыгнули тут, а упали совсем в другом месте, где нас не ждали.

А везде ждать надо. Ловить — на верхнем по возможности уровне, а захват ресурсов и транзакции откатывать — везде.

М>короче говоря, моя точка зрения такова: человек который знает что находится под капотом плюсов в большинстве случаев сделает все это и на си, причем работать оно будет не хуже, а скорее всего даже лучше (в рамках данной задачи).

Только писать ему придется в 10 раз больше. Минимизируется риск понаписать лишнего трэша, пятикратно копирующего из пустого в порожнее, зато в разы повышаются усилия по проверке кодов возврата и освобождению захваченных ресурсов.

Здравствуйте, мыщъх, Вы писали:

М>Учитывая, что зарплата у сишников начинается от $10k ~ $15k в месяц (и там же и заканчивается), то в первом приближении мы имеем $169 за строку,

Чё, эта где столько?

В текущем проекте имеем около 100 строк в рабочий день. Проект уже кое-как работал когда было меньше 250, но документация, тестирования, изменения и т.п. снижают показатель сходу в 2 раза (учтено всё время, а не только на программирование, т.е. и отладка тоже).

При российской зряплате имеем более чем 100-кратное различие в меньшую сторону, чем насчитал мыщъх.

М>Шутка, конечно, но это хороший пример того, что у сишников (в R&D) производительность труда строками никак не меряется и тот, кто три дня медитирует, а потом пишет рабочий код из девяти строк, зачастую получает больше индуса, настрогавшего за это же время тысячу строк в которых три тысячи багов.

Чушь. Именно строками хорошо и меряется, ХОТЯ И ГРУБО (плюс-минус в 2 раза -- легко).
Исходя из того, что очень так приблизительно имеем ОДИН ОПЕРАТОР НА СТРОКУ. Да, где-то,
в какой-то строке операторов больше. Зато есть комментарии, пустые строки, закрывающиеся фигурные скобки и т.п.

Другой столько же прозрачной и достаточно хорошей методики оценки я не знаю.

М>Глупость вообще это меняться количеством строк, написанных в единицу времени.

А чем ещё? Операторами? Строки -- это приближение к тому.

M> и решение уже как бы известно, все равно — на непосредственную набивку текста уходит лишь маленькая толика времени. Грубо говоря за N времени готова плотная версия, а за 10*N ~ 100*N мы наконец довели ее до того состояния, когда она реально взлетела.

Ошибочное суждение. Корректно говорить о производительности X строк в единицу времени в проекте в целом, а не за какое время был написан этот кусок кода физически на клавиатуре. Сюда входит и время на проектирование, и время на отладку, на документацию, тестирование, исправления...

М>Было бы интересно а сколько у вас выходит строк в среднем? Берем проект. Берем дату создания первого файла. Берем дату последней версии. Считаем строки. Делим на время. Оглашаем результат.

См. выше.

М>ЗЫ. Ну а то, что пиковая производительность (у сишиника) порой доходит до пары килострок в день (без копипастинга) ну так это ж понятно. Не за то сейчас речь.

Правильно говорить не копипастинг, а "повторное использование кода". На C, без ++, так можно.

Здравствуйте, WolfHound, Вы писали:


WH>И при правильном подходе при чтении кода в котором летают исключения вообще не приходится заострять на них внимания ибо они не пересекаются с основной логикой программы.

Не все так просто.Вот ссылка из документа об использовании исключений в Windows kernel
"
Exceptions and RTTI
It is tempting to use C++ exceptions, but they are difficult to implement in kernel mode. C++ exceptions require a kernel-mode-safe library, which does not currently exist. They also present an unavoidable runtime problem, because exception records that are generated when an exception is thrown are large objects on the very limited stack. On x86 systems, exception records are not particularly large (although they are large compared with many typical stack frames), but on Intel Itanium systems they are quite large: 3K to 4K, or one-sixth to one-eighth of the available 24K stack space. To preserve portability of a driver to 64-bit platforms, exceptions would have to be used in a very limited way, even on the x86 architecture. The rethrow operator can cause multiple exception records on the stack. Note that Structured Exception Handling (__try /__except/__finally) is available in kernel mode, although the space concerns remain. C++ exceptions have a number of semantic subtleties that prevent them from simply mapping onto Structured Exception Handling.

"

WH>Я очень хорошо знаю что там под капотом вот только в использовании С не вижу ну совсем никакого смысла.
WH>Что касается сделать лучше то попробуй переписать http://antigrain.com/ (лучшая в мире библиотека для растеризации векторных изображений) на С.

Это же можно сказать и об переписавании на С++ одну из лучших операционных систем — Linux

Здравствуйте, Vzhyk, Вы писали:

V>eagersh пишет:

V>А так вот рядом парень работал, дрова писал под разное свое
V>специфическое железо и С++ использовал вовсю, вот только он еще и голову
V>использовал.
Какая OS?
В embedded systems начали немного использовать С++, но делают это очень осторожно.В целом для системных вещей С++ мало подходит так как решаются совсем другие задачи чем например в application programming где часто измеряют производитеьность по количеству написанных строк.Можно конечно использовать и С++ для системных вещей но зачем?

Здравствуйте, мыщъх, Вы писали:

М>Привет всем сишникам! В первую очередь тем которые труъ и которые ANSI.

Привет. Ты ничего не перепутал? Дальше пишешь, что "по статусу я реверс инженер"

Автор: мыщъх
Дата: 15.12.09

(кстати, всегда было интересно, что ты вкладыаешь в это понятие, думаю, тебе банально нравится употреблять это слово к месту и не очень, наряду с "хакер"). Можно понять, что подразумевается

Автор: мыщъх
Дата: 15.12.09

написание сценариев на IDA скрипте (а что, правда кто-то до сих пор всерьёз использует этот жалкий тормоз? при наличии Питона и Перла??? )

Короче, не знаю что народ баламутится, а мне ясно как день, что в Сишники ты себя записал просто потому что считаешь модным говорить "я не (хочу) знаю другие языки". И читать всё написанное тобой делее следует в ключе, что к С оно отношения практического не имеет.

Да, а что до стоимости строчек кода... за последний RE не могу посчитать, деление на 0 происходит вот и сейчас пишу текстовый документ... стоп! да я ведь мог 3 дня в медитации просидеть, а потом это на словах рассказать Однако понимаю, что ценность просто слов гораздо ниже "бумаги", а стоимость — на порядки выше обернётся. Не для меня. Это к тому, что расчеты с "ценой" не имеющие упоминания "маржа" смешат не только мою жену — бухгалтера

А что сказать то хотел... Вы (мы) реверсеры видать сильно стукнутый по голове народ. Кто ещё способен потратить кучу времени на осознание простого факта из учебников Строка кода ничего не стоит. Строка кода с ошибкой стоит дорого. А платят за решение проблем, или — реже — за надежду

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, мыщъх, Вы писали:

М>>Привет всем сишникам! В первую очередь тем которые труъ и которые ANSI.
GN>Привет. Ты ничего не перепутал? Дальше пишешь, что "по статусу я реверс инженер"

Автор: мыщъх
Дата: 15.12.09

ну если говорить честно, то принят я по двум контрактам. по ТК просто инженер без уточнений, в английской версии написано черным по белому что реверс инженер. только реверсингом (в русском понимании этого слова) заниматься приходится редко и все по мелкому делу. даже иду не запускаю. последнее, что разреверсил — pdf сплоит для очередного 0day с засунутым внутрь exe. уже думал запустить иду, но пока вырезал файл хьювом уже успел разобраться. так что это не реверсинг. это так, дизаасемблирование по ходу дела.

а за что же мне тогда деньги платят? вот сегодня на корпоративной вечеринке приставал с этим вопросам и к боссу и к юристу. они сказали не париться и предложили выпить, потому как пили все. в том числе и воду. хотя я и в самом деле ни хвоста не понимаю. ну программирую немного. последняя программа аж и 16 строк на си. пол-дня писал. аж вспотел. программа ищет определенную последновательность кода с учетом возможных вариаций. вообще-то по уму тут нужно юзать либу регулярных выражений. если бы знал — заюзал. однако, вариант написанный коллегами, пропустил половину сэмплов. сэмлы, кстати, из с неба не упали. по сети пришло что-то, но мало... так что мыщъх написал простой автогенератор кода, генерирующий все возможные последовательности заданного типа (тысчи файлов).

так что все-таки по факту приходится программировать. и хотя мне это очень нравится, так что меня от компа за хвост оттащить не могут, реального опыта у меня нет, так что ужасно косячу. правда архитектор системы помогает, а я мотаю на ус. то есть на хвост. но и на ус тоже.

GN> кстати, всегда было интересно, что ты вкладыаешь в это понятие,
в данном контексте это название моей должности. в другом контекте понятие может быть другим.

GN> думаю, тебе банально нравится употреблять это слово к месту и не очень, наряду с "хакер"
мне нравится реверсинг. и хотелось бы реверстить не только в стол, но и для пользы дела. однако, обстоятельства сложились так, что устроившись в антивирусную компанию реверсером, я перестал запускать иду, хотя раньше проводил в ней значительную часть времени.

> Можно понять, что подразумевается

Автор: мыщъх
Дата: 15.12.09

> написание сценариев на IDA скрипте (а что, правда кто-то до сих пор всерьёз использует этот
> жалкий тормоз? при наличии Питона и Перла??? )
перл курил, но так и не проникся. питон у меня на уровне read-only

GN> Короче, не знаю что народ баламутится, а мне ясно как день, что в Сишники
GN> ты себя записал просто потому что считаешь модным говорить "я не (хочу) знаю другие языки".
си очаровал меня с самого начала. потребности изучать другие языки до сих пор не возникала, да и не полиглот. на самом деле я бы с удовольствием оказался бы в компании программирующей на плюсах, где была бы не только приниципиальная возможность их учить, но еще и потребности. а так... я на си быстрее решу задачу. в примере с тем же автогенератором кода. который написан на скорую руку для решения конкретной задачи. зачем тут плюсы? написал, запустил, забыл.

GN> читать всё написанное тобой делее следует в ключе, что к С оно отношения практического не имеет.
т.е. программы, полностью написанные на си, к С практического отношения не имеют. а к чему имеют?

GN> вот и сейчас пишу текстовый документ... стоп! да я ведь мог 3 дня в медитации просидеть,
GN> а потом это на словах рассказать
через три дня вы бы пришли к выводу, что данный документ писать вообще не нужно. разве что писанины ради.

GN> Строка кода с ошибкой стоит дорого. А платят за решение проблем, или — реже — за надежду
кто бы объяснил за что платят мне... я ведь действительно не понимаю. сегодня показывал коллеге как реверсить патчи. и в качестве простого и в то же время наглядного примера взял древний патч MS08-67, который когда-то реверсил сам и за реверс которого мне платили. если кто не в курсе, там одна dll на 300 кб, причем сами фиксы тривальны (т.е. очень хороший пример для обучения для человека который патчдифф видет впервые в жизни). и что же я узнал в процессе реверсинга? ох ты мою мать! оторвать хвост и прыгнуть в пропасть! та это же новое слово в пиротехнике. половина векторов атак ранее была неизвестна!!! в смысле была неизвестна тем для кого я этот патч реверсил и по результатам реверсинга писал отчет. вывод — отчет ущел в /dev/nul и на него никто даже не глянул.

а тогда я еще работал не как fte, а как контрактор и на каждый чих посылал инвойсы. которые выплачивались. вот теперь вопрос: на фига было аппрувить инвойс, если результатами реверсинга не воспользовались? и на фига я вообще все это реверсил? странно все это... ладно когда человеку платят зарплату не понятно за что, т.к. не платить юридически не могут, а увольнять предположим не увольняют по тем или иным соображениям.

короче, я теряюсь. сам не знаю, чем я тут занимаюсь...

но это мы скатились в оффтопик. изначальный пост относился не ко мне лично, а к коллегам по (не)счастью.

Здравствуйте, eagersh, Вы писали:

WH>>Я очень хорошо знаю что там под капотом вот только в использовании С не вижу ну совсем никакого смысла.
WH>>Что касается сделать лучше то попробуй переписать http://antigrain.com/ (лучшая в мире библиотека для растеризации векторных изображений) на С.

E>Это же можно сказать и об переписавании на С++ одну из лучших операционных систем — Linux

BeOS кстати по слухам целиком на плюсах написана была.

Здравствуйте, traveler, Вы писали:

T>Потому что один великий мудрец (это сарказм), в великой книге "Техника оптимизации программ. Эффективное использование памяти.", которую я прочитал не менее десяти раз (это лесть), упомянул, что работать двойными словами эффективнее, нежели байтами.
T>Т.е. если на байты пересчитать — дешевле выйдет..

Великой книге не хватало только диска

Здравствуйте, мыщъх,

GN>> читать всё написанное тобой делее следует в ключе, что к С оно отношения практического не имеет.
М>т.е. программы, полностью написанные на си, к С практического отношения не имеют. а к чему имеют?

Кнут издал 4 тома с программами на ассемблере. Однако они никак не о программировании на ассемблере

GN>> вот и сейчас пишу текстовый документ... стоп! да я ведь мог 3 дня в медитации просидеть,
GN>> а потом это на словах рассказать
М>через три дня вы бы пришли к выводу, что данный документ писать вообще не нужно. разве что писанины ради.

Нет, ни в коем случае не приду я к такому выводу. Составление документации к проекту без оной — типичный reverse engineering Может быть полезен для снижения стоимости поддержки. Или что бы аналитики почитали и сделали оценки, или предлагаешь делать это мне? Тогда у меня есть обычно только одно мнение, котрое не обязательно правильное. Держать всё в голове — это, извини, подойдёт только для примитивных вещей.

М>короче, я теряюсь. сам не знаю, чем я тут занимаюсь...

Не парься Доктор говорит, что выгодно вкладывать в branding. Вот в тебя и вкладывают — очевидно же, что ты начнёшь повсеместно писать про своего работодателя

Здравствуйте, eagersh, Вы писали:

E>Не все так просто.Вот ссылка из документа об использовании исключений в Windows kernel
E>"
E>Exceptions and RTTI
E>It is tempting to use C++ exceptions, but they are difficult to implement in kernel mode. C++ exceptions require a kernel-mode-safe library, which does not currently exist.

Есть некоторые реализации того, что нужно, многие даже свободные.

E>Это же можно сказать и об переписавании на С++ одну из лучших операционных систем — Linux

Строго говоря, хотя бы С++ в *nix вообще и Linux в частности совсем бы не помешало...

Здравствуйте, lyk, Вы писали:


lyk>СОВЕРШЕННО СОГЛАСЕН!!! После 11 лет asm (причем разных, писал свои классы), и 13 лет С/С++ (где представляешь, куда какой байтик выкладывается и кто к нему может доступиться) С# вызывает дикую неприязнь с его тупизной, но что делать — зкакзчик хочет... У меня сын пишет — как домино — попка к попке — не представляя, как реально это будет выполняться на железе.

Напишите-ка с выкладыванием байтиков запрос к Web-сервису, получающий сериализованный объект и восстанавливающий его вместе с состоянием...

Здравствуйте, eagersh, Вы писали:

E>Не все так просто.Вот ссылка из документа об использовании исключений в Windows kernel
То что исключения в MSVC реализованы плохо ИМХО знают все.
Вот только что их мешает реализовать хорошо?

E>Это же можно сказать и об переписавании на С++ одну из лучших операционных систем — Linux
Ну раз ты упорно на этом настаиваешь то тебе не составит труда назвать причину кроме плохой реализации исключений в MSVC Меж тем мое утверждение про антиграйн проверяется тривиально. Достаточно посмотреть на коллически шаблонов и то как они используются чтобы понять.
Кстати BeOS по слухам написана на С++.

Здравствуйте, мыщъх, Вы писали:

CC>> Просто изучать надо сначала асм, потом С и только потом С++.
М>имхо начинать с асма в нашу эпоху будет тяжело. уж лучше сначала си, потому как это ж не ms-dos.
М> тут асм погружает человека в такую пучину деталей, что из нее будет скорее всего никогда и не выбраться, только погружаться все дальше и дальше.
В принципе да, тем более даже тот же "асм под современные х86 тогда" и "асм под современные х86 сейчас" по колву нюансов работы проца которые надо понять отличается на порядок.

М>goto err это не лапша и сразу понятно кто у нас обрабатывает ошибку (ну или long jump),
Скажем так, это наверное единственный вариант использования goto, за который не стоит сильно бить. Но в С++ лучше все таки использовать RAII. Для этого не нужны исключения, он прекрасно работает с return.

М>короче говоря, моя точка зрения такова: человек который знает что находится под капотом плюсов в большинстве случаев сделает все это и на си, причем работать оно будет не хуже, а скорее всего даже лучше (в рамках данной задачи).
Ну, на С будет просто сильно менее удобно. Одна только невозможность объявления переменных в произвольном месте меня раздражает.

Здравствуйте, WolfHound, Вы писали:

М>>вот я и говорю. скажем исключения в плюсах. ускорить программу они никак не могут.
WH>Твое утверждение противоречит экспериментальным данным.
А можно взглянуть на "экспериментальный" код для кодов возврата и для исключений?
Потому как у меня на некоторых проектах получились совершенно иные экспериментальные данные.

Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>С исключениями тупо меньше проверок. Если тащишь код возврата через 10 уровней, придется на каждом его проверять.
Исключения хороши когда ошибка может произойти на каком нить нереальном уровне вложенности.
А так — и кодов вполне достаточно.
Причём выброс исключения на порядки тяжелее чем возврат кода ошибки.

Здравствуйте, мыщъх, Вы писали:

М>а тогда я еще работал не как fte, а как контрактор и на каждый чих посылал инвойсы. которые выплачивались. вот теперь вопрос: на фига было аппрувить инвойс, если результатами реверсинга не воспользовались?
Ну, задача выполнена, работа проделана, надо оплатить. А то, что заказчик не сумел/захотел воспользоваться результатами этой работы — это его трудности.

М> и на фига я вообще все это реверсил?
Тебе заказали — ты отреверсил. Ну бывает такое что делается ненужная в результате работа, да.

М>ладно когда человеку платят зарплату не понятно за что, т.к. не платить юридически не могут, а увольнять предположим не увольняют по тем или иным соображениям.
Тут тоже юридически не могут не заплатить, потому как условия контракта с твоей стороны выполнены.

Здравствуйте, CreatorCray, Вы писали:

CC>А можно взглянуть на "экспериментальный" код для кодов возврата и для исключений?
CC>Потому как у меня на некоторых проектах получились совершенно иные экспериментальные данные.
Кода у меня под рукой нет. Но его не сложно написать. Просто нужно убедиться что инлайна небыло.
Также нужно учесть что это зависит от компилятора.
Ибо есть 2 несколько способов реализовать исключения.
Есть варианты когда каждая функция во время работы пишет в стек информацию для раскрутки. Эти будут медленней.
А есть варианты которым достаточно адресов возврата которые заталкивает в стек call. Эти будут очевидно быстрее ибо пока нет исключений (а они должны быть большой редкостью) у нас вообще не происходит никаких действий направленных на проверку ошибок.

Здравствуйте, CreatorCray, Вы писали:

ТКС>>С исключениями тупо меньше проверок. Если тащишь код возврата через 10 уровней, придется на каждом его проверять.
CC>Исключения хороши когда ошибка может произойти на каком нить нереальном уровне вложенности.
CC>А так — и кодов вполне достаточно.

Достаточно, конечно. Для многого вообще и ассемблера достаточно. Но я просто пояснял, каким образом исключения могут быть быстрее кодов возврата, а не затевал спор об их избыточности/необходимости в неоговоренных заранее ситуациях

CC>Причём выброс исключения на порядки тяжелее чем возврат кода ошибки.

Да. Поэтому область их применения ограничивается теми областями, где ошибки возникают на порядки реже, чем нормальное завершение работы. А это, как ни странно, подавляющее большинство кода

Здравствуйте, lyk, Вы писали:

lyk>Здравствуйте, Геннадий Майко, Вы писали:

ГМ>>Этот тезис может быть верным только для конторы, которая имеет один-единственный продукт и продала его одному-единственному клиенту. Вспомнить таких контор (работаюших в около-компютерных областях) мне как-то сходу не удалось. И если даже такая есть, то я уверен, что с такой стратегией протянет она на рынке не дольше одного квартала.

lyk>Один продукт — согласен, один клиент — не обязательно. Таких контор полно — кто пишет банковские дни (штук 5), распознавалки/переводчики, антивирусники, CRM и т.д. Т.е. — те, кто имеют коробочный продукт, а не делают дяде какие-то мелкие компоненты.

Зачем далеко ходить? MS Windows, MS Office и т.д. Достаточно вспомнить "откиньтесь на спинку кресла, и мы вам расскажем, насколько лучше Win98... win2k, winXP"...

Т.е. пишем продукт, в следующей версии исправляем старые ляпы, попутно внося новые, и юзер будет покупать такой продукт бесконечно (мысль честно украденная несколько лет назад у одного известного товарища ^^).
Правда на современном рынке ПО такая стратегия уже не катит, но мелкомягкие уже достаточно отожрались, чтобы позволить себе выпускать качественный софт.

Здравствуйте, CreatorCray, Вы писали:

CC>Здравствуйте, мыщъх, Вы писали:

М>>а тогда я еще работал не как fte, а как контрактор и на каждый чих посылал инвойсы. которые выплачивались. вот теперь вопрос: на фига было аппрувить инвойс, если результатами реверсинга не воспользовались?
CC>Ну, задача выполнена, работа проделана, надо оплатить. А то, что заказчик не сумел/захотел воспользоваться результатами этой работы — это его трудности.
по поводу невостребованности работы я совсем не комплексую. я просто понять пытаюсь зачем меня тут держат

М>>ладно когда человеку платят зарплату не понятно за что, т.к. не платить юридически не могут, а увольнять предположим не увольняют по тем или иным соображениям.
CC>Тут тоже юридически не могут не заплатить, потому как условия контракта с твоей стороны выполнены.
в контракте про это как раз ничего не сказано, там лишь очерчены наши отношения. реальная работа выглядит, точнее выглядела так: в конце каждого месяца я посылаю инвойс, т.е. список всего, что я заточил, время (сколько точилась каждая деталь) и ставка. максимальная ставка ограничена контрактом. максимальное кол-во часов ограничено законом. вот и пишешь все-все-все, что ты делал. забыл чего-то указать: сам себе злобный буратино.

и бывает так, что даже если целую неделю реверсил что-то большое и могучее, в ходе чего создал три мелких скрипта для иды, то вписывать это одним пунктом рисковано, т.к. если не утвердят, мы теряем сразу всю неделю. лучше разбить эту задачу на кучу мелких подзадач. допустим, не утвердили реверсинг, но утвердили скрипты.

и оплачивать работу в этом случае необязаны.

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, eagersh, Вы писали:

E>>Не все так просто.Вот ссылка из документа об использовании исключений в Windows kernel
WH>То что исключения в MSVC реализованы плохо ИМХО знают все.
WH>Вот только что их мешает реализовать хорошо?

E>>Это же можно сказать и об переписавании на С++ одну из лучших операционных систем — Linux
WH>Ну раз ты упорно на этом настаиваешь то тебе не составит труда назвать причину кроме плохой реализации исключений в MSVC Меж тем мое утверждение про антиграйн проверяется тривиально. Достаточно посмотреть на коллически шаблонов и то как они используются чтобы понять.

Я пытаюсь сказать что хороший програмист не должен привязываться к языку, а выбирать язык и библиотеку исходя из поставленной задачи.Если для этой задачи лучше использовать С++ то надо так и делать.Но если надо использовать С, как я показал в примере по системному програмированию, то надо С но никак С++.Есть и задачи где можна использовать только ассемблер.Там даже С нельзя, несмотря на его хорошую оптимизацию по коду.

WH>Кстати BeOS по слухам написана на С++.

И как она широко используется

Здравствуйте, StandAlone, Вы писали:

SA>Здравствуйте, lyk, Вы писали:


lyk>>СОВЕРШЕННО СОГЛАСЕН!!! После 11 лет asm (причем разных, писал свои классы), и 13 лет С/С++ (где представляешь, куда какой байтик выкладывается и кто к нему может доступиться) С# вызывает дикую неприязнь с его тупизной, но что делать — зкакзчик хочет... У меня сын пишет — как домино — попка к попке — не представляя, как реально это будет выполняться на железе.

SA>Напишите-ка с выкладыванием байтиков запрос к Web-сервису, получающий сериализованный объект и восстанавливающий его вместе с состоянием...
Он не говорил что все надо писать на ассемблере.Он говорил, что часто сейчас програмисты используя языки высого уровня не понимают что находится внутри этого кода и какой код генерируется.Понимание таких вещей показывает квалификацию програмиста.

Здравствуйте, StandAlone, Вы писали:

SA>Здравствуйте, eagersh, Вы писали:

E>>Не все так просто.Вот ссылка из документа об использовании исключений в Windows kernel
E>>"
E>>Exceptions and RTTI
E>>It is tempting to use C++ exceptions, but they are difficult to implement in kernel mode. C++ exceptions require a kernel-mode-safe library, which does not currently exist.

SA>Есть некоторые реализации того, что нужно, многие даже свободные.

E>>Это же можно сказать и об переписавании на С++ одну из лучших операционных систем — Linux

SA>Строго говоря, хотя бы С++ в *nix вообще и Linux в частности совсем бы не помешало...
Что бы такие вещи говорить надо самому написать операционку.Только тогда можно правильно оценить какой язык выбрать для реализации.

Здравствуйте, eagersh, Вы писали:

E>Не все так просто.Вот ссылка из документа об использовании исключений в Windows kernel

[nuked]

Да, действительно не так просто, но и исключения, и RTTI в ядре Виндовса использовать можно.

Здравствуйте, eagersh, Вы писали:

E>Что бы такие вещи говорить надо самому написать операционку.Только тогда можно правильно оценить какой язык выбрать для реализации.

А в чем у *nix, кстати, проблема? Они использовали ключевый слова С++ в своих гнусных целях? Re: Попинайте C++ framework для DDK

Автор: MShura
Дата: 26.05.08

Здравствуйте, eagersh, Вы писали:

E>Я пытаюсь сказать что
Ты пытаешься прыгать с темы на тему пытаясь отстоять сказанную не подумав глупость.

E>хороший програмист не должен привязываться к языку, а выбирать язык и библиотеку исходя из поставленной задачи.
И к чему тут эта банальность?

E>Если для этой задачи лучше использовать С++ то надо так и делать.Но если надо использовать С, как я показал в примере по системному програмированию, то надо С но никак С++.
Единственное что ты показал это то что ребятишки из мелкософта не могут реализовать нормальную обработку исключений. Так это и так все знают.

E>Есть и задачи где можна использовать только ассемблер.Там даже С нельзя, несмотря на его хорошую оптимизацию по коду.
И что это за задачи таки?

WH>>Кстати BeOS по слухам написана на С++.
E>И как она широко используется
Это вопрос к манагерам которые этот проект похоронили.

Здравствуйте, WolfHound, Вы писали:

E>>Не все так просто.Вот ссылка из документа об использовании исключений в Windows kernel
WH>То что исключения в MSVC реализованы плохо ИМХО знают все.
WH>Вот только что их мешает реализовать хорошо?

Глядя на простыни мануалов на тему "как использовать исключения в с++" слабо верится что проблема именно у msvc.

Здравствуйте, мыщъх, Вы писали:

М>имхо начинать с асма в нашу эпоху будет тяжело. уж лучше сначала си

Си это ассемблер PDP-11. ПРичем сделан так, что позволяет понять его сходу... и неправильно. А переучиваться всегда дороже.

М>и что самое смешное, люди которые готовы убить за goto, пропагандируют исключения, которые еще хуже, чем goto, поскольку goto err это не лапша и сразу понятно кто у нас обрабатывает ошибку (ну или long jump)
М>, а вот исключения вообще непонятно кто и как обрабатывает.

Самое смешное — диспетчер исключений обрабатывает и longjmp Теперь понятно?

М>короче говоря, моя точка зрения такова: человек который знает что находится под капотом плюсов в большинстве случаев сделает все это и на си, причем работать оно будет не хуже, а скорее всего даже лучше (в рамках данной задачи).

Ты не знаешь С++, поэтому твоя точка зрения суть догадки. Если он действительно понимает плюсы, то конечно сделает на С (в смысле — сможет), но вряд ли будет тратить своё время так неэффективно.

Здравствуйте, мыщъх, Вы писали:

М> кроме того раздражает, что рядовой приплюснутый программист совершенно не в курсе что такое память (оперативная) и чем стек от кучи вообще отличается и почему статические массивы иногда на порядок быстрее, а то и на два.

Почему статический массив будет на 2 порядка быстрее автоматического, который по факту всегда в кеше?

Здравствуйте, мыщъх, Вы писали:

М> программа ищет определенную последновательность кода с учетом возможных вариаций. вообще-то по уму тут нужно юзать либу регулярных выражений. если бы знал — заюзал.

Зачем регулярные — строится автомат с состояниями, условиями переходов. Причем — если на asm — все будет на регистрах и просто летать Правда, сейчас оптимизаторы С тоже очень хитрые. С регулярными писать на порядок меньше, но как там там реализованы потроха... Ну это дело вкуса.

Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>Здравствуйте, CreatorCray, Вы писали:

ТКС> Достаточно, конечно. Для многого вообще и ассемблера достаточно.
TKC> Но я просто пояснял, каким образом исключения могут быть быстрее кодов возврата,
стоп. исключения (программные, т.к. аппаратных у нас немного и они на каждой платформе разные и "стоят" очень дорого в смысле памяти/тактов ЦП) могут быть реализованы через посылку сообщений. если произошло нечто ужасное, то тащить ошибку через кучу уровней действительно глупо и рисковано (вдруг где-то забудем вставить проверку). а вот послать сообщение -- самое то. адресат сообщения может быть где угодно и он получит его немедленно (допустим, через таблицу вызовов), т.е. практически без накладных расходов.

и в отличии от приплюснутых исключений, которые черт знает как реализованы в каждом компиляторе на каждой платформе, наш диспетчер сообщений будет успешно работать и в ядре, и даже в другой галактике (если, конечно, он писан не через попу, а писать его совсем недолго и его легко заменить на любой другой).

это не значит, что нужно переизобретать плюсы но утверждение, что на плюсах можно сделать более быстрый код, чем на си по меньшей мере сомнительно и требует доказательств. или хотя бы обоснований. кстати, кто мне объяснит почему в ms vc выбор исключения реализован так, как он там реализован? это же ужос. именно потому исключения и не рекоммендуется бросать в ядре.

TKC> а не затевал спор об их избыточности/необходимости в неоговоренных заранее ситуациях
язык определяет мышление хотим мы того или нет. постоянно сталкиваюсь, что плюсовики тяготеют к решением в общем виде, в то время как сишники решают задачу в частном виде, что в разы быстрее. вон тут в одной текущей задаче, которую сначала показали плюсовику и спросили сколько займет ее решение, он сказал, тут типа нам нужно писать могучий движок и это проект на полгода. его коллега (сишник) поинтересовался: а зачем? ведь _поставленная_ задача укладывается в сотню строк кода. ответ был ошеломляющим: "ну и что мы так и будем по сотне строк кода писать для решения частных задач каждый раз как они возникают? задачи надо решать раз и навсегда!!!"

CC>>Причём выброс исключения на порядки тяжелее чем возврат кода ошибки.
ТКС>Да. Поэтому область их применения ограничивается теми областями, где ошибки возникают на порядки реже,
стоп! если ошибки все-таки возникают, то это ведет к возможности доса.

TKC> чем нормальное завершение работы. А это, как ни странно, подавляющее большинство кода
согласно парадигме ООП о частоте возникновения ощибок место их возникновения знать не может. например, ошибка выдления памяти: как часто она возникает? ответ: ну вообще-то при нормальном положении дел не возникает вообще, но если "кривыми" запросами заставить выпрыгивать ее постоянно, то... капец производительности.

и есть куча кода, который хоть и не реал-тайм, а все-таки должен обрабатывать заданное кол-во запросов в единицу времени, а подсчитать во что обойдутся исключения, если они начнут выпрыгивать на каждом запросе — очень сложно, особенно если код кроссплатформенный.

ЗЫ. я не противник исключений. но ругая си за "...дайте детям динамит", исключения в плюсах выглядят как "...дали террористам атомную бомбу и средство ее доставки". наличие исключений (и их агрессивная пропаганда) приводят к их бездумному использованию. поэтому, если мы на 100% не уверены, что знаем как юзать исключения, их лучше не юзать.

ЗЫ.ЗЫ. коды возврата тоже зло. и в идеале нужно проектировать программу так, чтобы _явная_ проверка на ошибку не требовалось. ну вот например, обломались мы с открытием файла в текстовом редакторе, но проверить это забыли. передали дескриптор функции чтения. функция чтения вернула ноль байт. вывели мы эти ноль байт на экран получив пустоту. конечно, отсутствие сообщений об ошибке не есть хорошо, но при данном подходе и не смертельно. а вот если функция чтения файла среагирует на нулевой дескриптор падением или возвратом неиницилированного мусора с кодом ошибки, вот тут придется туго.

ЗЫ.ЗЫ.ЗЫ. а что делать если прототип функции объявлен как void remove_comments(char *s), нам менять его нельзя, а нужно удалить из строки си и си++ комментарии? а если комментарии кривые? допустим, вложенные /* /* */ */ ? вполне реальный пример из жизни. тестовое задание от макровижн. когда они мне его прислали первый раз, я сказал, что void не катит. через год они присылают тоже самое (!) задание с тем же (!) прототимом, но с припиской на полях: s указаывает на строку с комментами _по_ _стандарту_. т.е. согласно ТЗ ошибки возникнуть не может. но а если таки выясняется, что комменты у нас не по стандарту? что делать-то? менять прототип мы не могем. я плюнул и в обработчике ошибок воткнул *s = 0. не уверен, что правильно, но...
а что было еще делать? исключение кидать? а кто его ловить будет? а не станет ли оно намного большей неожиданностью, чем непонятного почему обнулившаяся строка?

Здравствуйте, WolfHound, Вы писали:

WH>Здравствуйте, eagersh, Вы писали:

E>>Я пытаюсь сказать что
WH>Ты пытаешься прыгать с темы на тему пытаясь отстоять сказанную не подумав глупость.

E>>хороший програмист не должен привязываться к языку, а выбирать язык и библиотеку исходя из поставленной задачи.
WH>И к чему тут эта банальность?

А в чем глупость? В том что С почти не используется в системном програмировании это правда.А если используется то с большимы ограничениями.Почему? Потому что есть причины которые я тебе часть показал.Я уже приводил этот документ выше, но для тебя приведу еще раз.
http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx


E>>Есть и задачи где можна использовать только ассемблер.Там даже С нельзя, несмотря на его хорошую оптимизацию по коду.
WH>И что это за задачи таки?
Ну например PXEloader с каким нибудь network stack. Так как это работает в real mode то идет борьба за каждый байт памяти.
Ну и разный start boot in embedded systems.

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, eagersh, Вы писали:

E>>Что бы такие вещи говорить надо самому написать операционку.Только тогда можно правильно оценить какой язык выбрать для реализации.

GN>А в чем у *nix, кстати, проблема? Они использовали ключевый слова С++ в своих гнусных целях? Re: Попинайте C++ framework для DDK

Автор: MShura
Дата: 26.05.08

Просто все изначально было написанно на С для Linux в начале 90-х. На С++ не имело смысла переписовать. Переписать конечно можно было, но преимуществ не получили бы.
Но С++ не все так плохо в системном програмировании.Можно програмировать на нем тоже, но правда с ограничениями.Надо хорошо понимать эти ограничения, и как их обходить. Microsoft например сейчас широко использует кернел API — WDF которая написанна на С++.Но правда Microsoft все еще не рекомендует использовать С++ для написания драйверов. Их понять можно, так как драйвера фактически часть OS со всеми вытекающими последствиями.

Здравствуйте, lyk, Вы писали:

lyk>Здравствуйте, мыщъх, Вы писали:

М>> программа ищет определенную последновательность кода с учетом возможных вариаций. вообще-то по уму тут нужно юзать либу регулярных выражений. если бы знал — заюзал.

lyk> Зачем регулярные — строится автомат с состояниями, условиями переходов. Причем — если на asm
с удовольствием бы написал на асм. на си не хватает goto (оно там есть, но не приветствуется), поэтому замуил спагетти из кучи continue/break, уложившись в 16 строк, уместив их в одной функции.

автомат состояний, правда, мне не подходил, т.к. производительность очень критична и важно как можно скорее понять, что тут мы ничего не найдем и побыстрее свалить отсюда, а поскольку последовательность команд (порядок которых произволен, регистры произвольны...) начинается с mov, то под нее попадает практически любой код. поэтому, там поиск получилися очень запутанным. сначала ищем наиболее уникальные комбинации байт (которые как можно редко встречаются), задавив регистры битовыми масками. если нашлось что-то прыгаем назад и начинаем чекать зависимость по регистрам. для ускорения сути дела заводится массив стркутур, проидексированный регистрами и натянутый на граф.

хотя это и не предел алгоритмической оптимизации, но... все летает. правда, кол-во последовательностей которые надо искать некулонно растет и пока они у меня чекаются последовательно одна за другой. с ужасом думаю, что я буду делать через год таких темпов. workaround на сегодня это классическое дерево выполняющее быструю проверку постоянных фрагментов последовательностей и уже потом вызывающий сооветсвующую функцию для валадации данной последовательности. пока последовательностей немного это очень хорошо работат, но... а что будет завтра? а вот тут у меня уже знаний и не хватает...

> все будет на регистрах и просто летать
это понятно, что будет летать. когда регулярное выражение одно. а когда их миллион? библиотеки регулярных выражений как бы поддерживают поиск по всем ним сразу, а вот мой подход — увы. но мне же не просто язык регулярных выражений нужен. мне как минимум нужен трейсер потока управления, не говоря за отслеживание регистров. пытался закодировать трейсер потока управленя на регулярных выражениях — упорно не хочет работать, т.е. работает но очень медленно.

> Правда, сейчас оптимизаторы С тоже очень хитрые. С регулярными писать на порядок меньше,
> но как там там реализованы потроха... Ну это дело вкуса.
с регулярными да, задача была бы решена быстрее. хотя не уверен. отладчика регулярных выражений еще не видел. и у всех них язык write-only.

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, мыщъх, Вы писали:

М>> кроме того раздражает, что рядовой приплюснутый программист совершенно не в курсе что такое память (оперативная) и чем стек от кучи вообще отличается и почему статические массивы иногда на порядок быстрее, а то и на два.

GN>Почему статический массив будет на 2 порядка быстрее автоматического, который по факту всегда в кеше?fr
имеется ввиду "выделение памяти под массив". а если массив еще не дай бог и иницилизированный, то это вообще капец в случае со стеком. самый классический пример: char buf[]="hello, world!\n". менее классический, но так же встречающийся это int matrix[x][y][z] = ... ;

но даже если массив не иницилизирован. объявляя в статике int buf[xxl] мы ничего не теряем. даже память не коммитим. вот как воспользуемся буфером (если вообще воспользуемся) так ось и закоммитит. если же массив локальный ОС выделяет память при входе в функцию. и эта функция пробегается по каждой странице массива даже если память была выделена ранее (компилер же не знает была выделеена память или нет). допустим, у нас массив на 400 кб. тогда компилятор воткнет скрытый цикл на сотню итераций. если цикл функцией реально используется хотя бы на 30% — потери производительности невелики, но что делать, если массив размером с максимально допустимую длину некой структуры (строки), а в рельности функция работает намного с более короткими строками?

ЗЫ. я ж сказал "иногда" (см. выделенное). в _общем_ случае различие в производительности действительно скорее всего не будет заметно.

Здравствуйте, мыщъх, Вы писали:

ТКС>> Достаточно, конечно. Для многого вообще и ассемблера достаточно.
TKC>> Но я просто пояснял, каким образом исключения могут быть быстрее кодов возврата,
М>стоп. исключения (программные, т.к. аппаратных у нас немного и они на каждой платформе разные и "стоят" очень дорого в смысле памяти/тактов ЦП) могут быть реализованы через посылку сообщений. если произошло нечто ужасное, то тащить ошибку через кучу уровней действительно глупо и рисковано (вдруг где-то забудем вставить проверку). а вот послать сообщение -- самое то. адресат сообщения может быть где угодно и он получит его немедленно (допустим, через таблицу вызовов), т.е. практически без накладных расходов.

М>и в отличии от приплюснутых исключений, которые черт знает как реализованы в каждом компиляторе на каждой платформе, наш диспетчер сообщений будет успешно работать и в ядре, и даже в другой галактике (если, конечно, он писан не через попу, а писать его совсем недолго и его легко заменить на любой другой).

М>это не значит, что нужно переизобретать плюсы но утверждение, что на плюсах можно сделать более быстрый код, чем на си по меньшей мере сомнительно и требует доказательств. или хотя бы обоснований. кстати, кто мне объяснит почему в ms vc выбор исключения реализован так, как он там реализован? это же ужос. именно потому исключения и не рекоммендуется бросать в ядре.

Собственно никто и не спорит, что на C вполне можно организовать закат солнца в ручную. Но часто ли на setjmp/longjmp организуют обычную прикладную логику? Да ни в жисть. В то время как на плюсах аналогичный механизм уже есть, причем — удобный.

TKC>> а не затевал спор об их избыточности/необходимости в неоговоренных заранее ситуациях
М>язык определяет мышление хотим мы того или нет. постоянно сталкиваюсь, что плюсовики тяготеют к решением в общем виде, в то время как сишники решают задачу в частном виде, что в разы быстрее. вон тут в одной текущей задаче, которую сначала показали плюсовику и спросили сколько займет ее решение, он сказал, тут типа нам нужно писать могучий движок и это проект на полгода. его коллега (сишник) поинтересовался: а зачем? ведь _поставленная_ задача укладывается в сотню строк кода. ответ был ошеломляющим: "ну и что мы так и будем по сотне строк кода писать для решения частных задач каждый раз как они возникают? задачи надо решать раз и навсегда!!!"

Встречаются иногда такие кадры, ага. Я раньше думал, что они испорченные джавой. Обратная крайность — когда заранее известно, что частных случаев будет не меньше 30, а движок все равно писать лень, устраивают лапшу для каждого случая — тоже бывает, причем у нас в конторе такие были тоже с джава бэкграундом Так что думаю язык тут не при чем.

CC>>>Причём выброс исключения на порядки тяжелее чем возврат кода ошибки.
ТКС>>Да. Поэтому область их применения ограничивается теми областями, где ошибки возникают на порядки реже,
М>стоп! если ошибки все-таки возникают, то это ведет к возможности доса.

Когда-то ведет, когда-то не ведет. Если мы тихо мирно из файла или даже сокета читаем, и нам лень на каждом из 10 уровней при каждом чтении проверку писать — какой тут нафиг дос? Ну закроет вражина сокет неожиданно, ну полетит из-за этого исключение — так и пёс бы с ним, с досом в другом месте бороться надо, например чтоб слишком часто не коннектился.

TKC>> чем нормальное завершение работы. А это, как ни странно, подавляющее большинство кода
М>согласно парадигме ООП о частоте возникновения ощибок место их возникновения знать не может. например, ошибка выдления памяти: как часто она возникает? ответ: ну вообще-то при нормальном положении дел не возникает вообще, но если "кривыми" запросами заставить выпрыгивать ее постоянно, то... капец производительности.

А ей в этом случае по любому капец, что у нас new исключения кидает, что результат malloc проверяем. Только если в случае с new упадет 95% программ, в случае с malloc (или старорежимным некидающим new) эта доля превышает, по моим наблюдениям, 99%.

М>и есть куча кода, который хоть и не реал-тайм, а все-таки должен обрабатывать заданное кол-во запросов в единицу времени, а подсчитать во что обойдутся исключения, если они начнут выпрыгивать на каждом запросе — очень сложно, особенно если код кроссплатформенный.

Ну так обязнность думать головой никто не отменял Мешают в каком-то коде исключения — значит надо писать без них.

М>ЗЫ. я не противник исключений. но ругая си за "...дайте детям динамит", исключения в плюсах выглядят как "...дали террористам атомную бомбу и средство ее доставки". наличие исключений (и их агрессивная пропаганда) приводят к их бездумному использованию. поэтому, если мы на 100% не уверены, что знаем как юзать исключения, их лучше не юзать.

По мне так наоборот — если мы на 100% не уверены, что справимся без исключений, лучше их использовать. Я про прикладной код естественно, без каких-то специфических ограничений. Ну а если логика позволяет и без кодов возврата, и без исключений обойтись — ну так мы в таком случае ничего не теряем, значит ни одного throw в коде и не будет.

М>ЗЫ.ЗЫ. коды возврата тоже зло. и в идеале нужно проектировать программу так, чтобы _явная_ проверка на ошибку не требовалось. ну вот например, обломались мы с открытием файла в текстовом редакторе, но проверить это забыли. передали дескриптор функции чтения. функция чтения вернула ноль байт. вывели мы эти ноль байт на экран получив пустоту. конечно, отсутствие сообщений об ошибке не есть хорошо, но при данном подходе и не смертельно. а вот если функция чтения файла среагирует на нулевой дескриптор падением или возвратом неиницилированного мусора с кодом ошибки, вот тут придется туго.

Ну вот как раз если скатываться к текстовым редакторам, то исключениям альтернативы я не вижу. Пишем для самого низкого уровня библиотеку, кидающую исключения (или берем готовую), закрываем try/catch самый верхний уровень (WinMain и WndProc или что у нас там в целевой системе, а так же все вспомогательные нити) и собственно в коде редактора вообще не паримся на тему обработки ошибок. Естественно, повсеместно используем RAII — оно и без исключений полезно. Чуть какая двусмысленная ситуация — кидаем исключение, сверху поймают и мессаджбокс покажут. И юзер по крайней мере узнает, что файл заблокирован другой программой, а не пустой, как ему бы показалось без обработки ошибок.

М>ЗЫ.ЗЫ.ЗЫ. а что делать если прототип функции объявлен как void remove_comments(char *s), нам менять его нельзя, а нужно удалить из строки си и си++ комментарии? а если комментарии кривые? допустим, вложенные /* /* */ */ ? вполне реальный пример из жизни. тестовое задание от макровижн. когда они мне его прислали первый раз, я сказал, что void не катит. через год они присылают тоже самое (!) задание с тем же (!) прототимом, но с припиской на полях: s указаывает на строку с комментами _по_ _стандарту_. т.е. согласно ТЗ ошибки возникнуть не может. но а если таки выясняется, что комменты у нас не по стандарту? что делать-то? менять прототип мы не могем. я плюнул и в обработчике ошибок воткнул *s = 0. не уверен, что правильно, но...

Конкретно с комментарием лично я бы оставил как есть. Ну то есть если встретили одинарный /* — выкидываем все до конца (хотя тут по уму все равно надо бы возвращать ошибку), если */ — возвращаем все как есть, это не комментарий, пусть с этим следующий уровень трахается.

М>а что было еще делать? исключение кидать? а кто его ловить будет? а не станет ли оно намного большей неожиданностью, чем непонятного почему обнулившаяся строка?

Ну это всего лишь не полностью сформулированное ТЗ. В жизни у меня таких почти не бывает, потому что я либо начинаю пытать заказчика, пока не выложит, для чего ему это надо, либо сам додумываю — если это в моей компетенции.

Здравствуйте, мыщъх, Вы писали:

М>имеется ввиду "выделение памяти под массив". а если массив еще не дай бог и иницилизированный, то это вообще капец в случае со стеком. самый классический пример: char buf[]="hello, world!\n". менее классический, но так же встречающийся это int matrix[x][y][z] = ... ;


откройте для себя alloca();

Здравствуйте, legogogo, Вы писали:

М>>имеется ввиду "выделение памяти под массив". а если массив еще не дай бог и иницилизированный, то это вообще капец в случае со стеком. самый классический пример: char buf[]="hello, world!\n". менее классический, но так же встречающийся это int matrix[x][y][z] = ... ;

L>откройте для себя alloca();

Тебе не про то пишут, а про скрытую инициализацию. Запись

char buf[]="hello, world!\n"

в отличие от записи

char const *buf="hello, world!\n"

скопирует строку в локально объявленный массив. В ряде случаев эти расходы могут стать заметными. Например, я когда-то подобную фигню в xml-парсере boost::serialization обнаружил — удалось нахаляву на пару процентов скорость загрузки увеличить. При том что там медленные файловые стримы использовались и вообще много всякой работы. Поэтому про подобные вещи надлежит помнить и вовремя голову включать, константы выносить в статику. Там правда есть шанс лохануться в другую сторону и упустить из виду многопоточность, если вдруг потом вместо константы потребуется переменная

Здравствуйте, Тот кто сидит в пруду, Вы писали:

ТКС>Здравствуйте, мыщъх, Вы писали:

ТКС> Собственно никто и не спорит, что на C вполне можно организовать закат солнца в ручную.
ТКС> Но часто ли на setjmp/longjmp организуют обычную прикладную логику? Да ни в жисть.
ТКС> В то время как на плюсах аналогичный механизм уже есть, причем — удобный.
с тем, что механизм есть — согласен. с тем что удобный — могу поспорить, но не буду. потому как для этого же его сначала изучить надо. я же сторонник подхода: если знаю как написать что-то за разумное время, то лучше писать самому, чем использовать сторонние компоненты. причем если в библиотеки хотя бы можно заглянуть, то особенности реализации исключений на данном компиляторе под данной осью...

M> укладывается в сотню строк кода. ответ был ошеломляющим: "ну и что мы так и будем по сотне
M> строк кода писать для решения частных задач каждый раз как они возникают? задачи надо
M> решать раз и навсегда!!!"

ТКС> Встречаются иногда такие кадры, ага. Я раньше думал, что они испорченные джавой.
это, конечно, крайний случай, но и в повседневной жизни спрашивая плюсовиков: а зачем тут это? я получаю ответы: а вдруг понадобится?

ведь в решении задачи важно понять что же нам _действительно_ надо. известна же хохма: препод: дан массив из N целых чисел, от 0 до N-1, где каждое число не может встречаться больше одного раза. отсортировать. вопрос из зала: скажите: на хрена нам массив?

> Обратная крайность — когда заранее известно, что частных случаев будет не меньше 30,
> а движок все равно писать лень, устраивают лапшу для каждого случая — тоже бывает,
такое тоже бывает. в том числе и за собой замечаю. но с другой стороны, если остальные 29 случаев будут не завтра и даже не послезавтра, а конкретно взятый случай необходимо решить уже сегодня, то писать движок не только лениво, но и нет времени.

ТКС> Когда-то ведет, когда-то не ведет. Если мы тихо мирно из файла или даже сокета читаем, и нам лень
TKC> на каждом из 10 уровней при каждом чтении проверку писать — какой тут нафиг дос?
смотря как читать и что читать. проверок все равно будет куча. допустим, мы ожидаем увидеть: XXX N M "<yyy@zzz>". какая разница с точки зрения парсера, то ли соединение порвалось, то ли кто-то скобку не закрыл.

ТКС> Ну так обязнность думать головой никто не отменял
TKC> Мешают в каком-то коде исключения — значит надо писать без них.
а если мне мешают исключения в чужом коде? причем мешают не сами исключения, и даже не код, а скорость внесения в него изменений. допустим, прошу коллегу чего-то добавить в его модуле, потому как это нужно моему (мой модуль хочет сообщить о чем-то важном пра-пра-пра материнской функции). коллега печатльно смотрит на свой код и грит, "слушай, а давай мы щас откомилирующешь свой модуль в программу, вернешь вывод в xml, а мы его запустим скриптом на руби и распарсим". вот... такие у нас исключения.

ТКС> По мне так наоборот — если мы на 100% не уверены, что справимся без исключений, лучше их использовать.
вопрос: как? рецептов много, ни одного правильного.

TKC> Я про прикладной код естественно, без каких-то специфических ограничений. Ну а если логика позволяет
TKC> и без кодов возврата, и без исключений обойтись — ну так мы в таком случае ничего не теряем, значит
TKC> ни одного throw в коде и не будет.
так ведь такую логику еще спроектировать надо. если думать заранее: а вот что произойдет если вызывающий
код забудет проверить ошибку? какие данные мы должны будем ему вернуть, чтобы обойтись без критических последстй?

ТКС>Конкретно с комментарием лично я бы оставил как есть. Ну то есть если встретили одинарный /*
TKC> — выкидываем все до конца (хотя тут по уму все равно надо бы возвращать ошибку),
это понятно. что делать с вложенными комментариями тоже понятно. в крайнем случае можно подддержать вложенность, хоть и противоречит стадарту, ну и что? это же не баг, это фича. а вот если это printf(".../*......*/[EOF]. тут как бы не совсем понятно что делать с незакрытой строкой. оставлять как есть? про #define я молчу. _корректно_ удалить комментарии без поддержки #define нельзя, ибо можно так извратиться, что и код будет следовать стандарту, и в нем незакрытые скобки будут, которые удаляются сишным препроцессором, но о которых спотыкаемся мы.

про то, что функции необхходим еще один аргумент — ссылка на стандарт я молчу. старндарты они сильно разные. по одному стандарту /**/ замееяется пробелом, по другому просто удаляется. какому стандарту следовать, если он явно не оговорен в ТЗ?

ТКС> Ну это всего лишь не полностью сформулированное ТЗ. В жизни у меня таких почти не бывает,
TKC> потому что я либо начинаю пытать заказчика, пока не выложит, для чего ему это надо,
ну в даннном случае это было задание не сколько на программирование, сколько на знание как нужно правильно программировать. т.е. чем больше "граблей" найдет в задании человек, тем он круче. из того что нашел я:
1) как возвращать ошибку?
2) нам что всерьез предлагают писать препроцессор?!!!
3) какой стандарт имеется ввиду?!

показательно, что программу я таки не написал. вернее написал, но в ней была пара багов. но оффер таки получил и программу зачли. а вот знакомый индус получивший тоже самое задание убеждал меня, что он его _решил_ и решил его правильно. оффера он не получил я попросил его скинуть программу на мыло. ну что? программа как программа. работает, не падает. про вложенные комменты, про пунткы 1, 2, 3 она ес-но не знает, но явных багов в ней нет.

вот и выходит, что я знаю как правильно программировать, но сам программировать не умею. а он умеет, но не знает.

Здравствуйте, eagersh, Вы писали:

E>Но С++ не все так плохо в системном програмировании.Можно програмировать на нем тоже, но правда с ограничениями.Надо хорошо понимать эти ограничения, и как их обходить. Microsoft например сейчас широко использует кернел API — WDF которая написанна на С++.Но правда Microsoft все еще не рекомендует использовать С++ для написания драйверов. Их понять можно, так как драйвера фактически часть OS со всеми вытекающими последствиями.

Я довольно неплохо знаю ситуацию в default OS, основная проблема — MS до сих пор не удосужились сделать C++ runtime.

Здравствуйте, мыщъх, Вы писали:

М>имеется ввиду "выделение памяти под массив". а если массив еще не дай бог и иницилизированный, то это вообще капец в случае со стеком. самый классический пример: char buf[]="hello, world!\n".

Если к этому коду дописать static, он станет медленнее, поскольку инициализация будет в обоих случаях. Если добавить еще и const — будет сравнение разных сущностей.

М> менее классический, но так же встречающийся это int matrix[x][y][z] = ... ;

М>но даже если массив не иницилизирован. объявляя в статике int buf[xxl] мы ничего не теряем. даже память не коммитим. вот как воспользуемся буфером (если вообще воспользуемся) так ось и закоммитит.

М> если же массив локальный ОС выделяет память при входе в функцию. и эта функция пробегается по каждой странице массива даже если память была выделена ранее (компилер же не знает была выделеена память или нет). допустим, у нас массив на 400 кб. тогда компилятор воткнет скрытый цикл на сотню итераций. если цикл функцией реально используется хотя бы на 30% — потери производительности невелики

Да тут точно такой же механизм коммита работает, как и при подкачке секций PE со статиками. А нет, пожалуй, вру. Стек менее вероятно будет позже вытеснен в своп.

М>, но что делать, если массив размером с максимально допустимую длину некой структуры (строки), а в рельности функция работает намного с более короткими строками?

Не уверен, что понял о чем речь, но наверное надо будет почитать о менеджменте памяти, например lookaside lists?

М>ЗЫ. я ж сказал "иногда" (см. выделенное). в _общем_ случае различие в производительности действительно скорее всего не будет заметно.

Иногда самая быстрая программа = которая ничего не делает.

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, мыщъх, Вы писали:

М>>имеется ввиду "выделение памяти под массив". а если массив еще не дай бог и иницилизированный, то это вообще капец в случае со стеком. самый классический пример: char buf[]="hello, world!\n".

GN>Если к этому коду дописать static, он станет медленнее, поскольку инициализация будет в обоих случаях.
с какого это перепугу при static у нас появится что либо? компилятор в студию. даже с выключенной оптимизацией при static оно будет в сегменте данных, откуда и загрузится с диска, а в стеке оно будет копироваться из сегмента данных в стек уже в рантайме при каждом вызове функции, что сильно тормозно. рассмотрим для примера функцию, которая превращает число из 0..F в символ.

foo(int a)
{
char x[]="0123456789ABCDEF";
return x[a & (0x10-1)];
}

пример жизненный. надуманным его назвать трудно. а теперь поставьте static и посмотрите что из этого выйдет. производительность возрастет в разы. если не в 6 раз, то раз в 3 точно с учетом всех прочих накладных расходов. а ведь у нас массив всего из 16 байт...

М>> если же массив локальный ОС выделяет память при входе в функцию. и эта функция пробегается по каждой странице массива даже если память была выделена ранее (компилер же не знает была выделеена память или нет). допустим, у нас массив на 400 кб. тогда компилятор воткнет скрытый цикл на сотню итераций. если цикл функцией реально используется хотя бы на 30% — потери производительности невелики

GN>Да тут точно такой же механизм коммита работает, как и при подкачке секций PE со статиками. А нет, пожалуй, вру. Стек менее вероятно будет позже вытеснен в своп.

при чем тут подкачка?! погуглите page guard. узнаете много нового. а так же объявите массив больше 4 кб в стеке и посмотрите что сделает компилятор. стек не является памятью с произвольным доступом. он растет вверх и память под него выделяется постепенно. постранично. поэтому, если мы выделяем массив из 8 кб памяти, мы вынуждены совершить одно обращение сначала к последней странице, а потом к первой. если обратимся сразу к первой — приложение рухнет. можете проверить на naked функциях, куда компилятор ничего не вставляет. поэтому, если у нас массив из N страниц, где N намного больше 1, то накладные расходы на пробег по всем страницам (при каждом вызове функции!) становятся ощутимыми.

Здравствуйте, мыщъх, Вы писали:
.
М>с какого это перепугу при static у нас появится что либо? компилятор в студию. даже с выключенной оптимизацией при static оно будет в сегменте данных, откуда и загрузится с диска, а в стеке оно будет копироваться из сегмента данных в стек уже в рантайме при каждом вызове функции, что сильно тормозно. рассмотрим для примера функцию, которая превращает число из 0..F в символ.

М>foo(int a)
М>{
М>char x[]="0123456789ABCDEF";
М>return x[a & (0x10-1)];
М>}

М>пример жизненный. надуманным его назвать трудно.

Этот пример — поросту не в тему, зачем начинаешь юлить? Напомню изначальный контекст:

почему статические массивы иногда на порядок быстрее, а то и на два. ну а то, что они потоконебезопасны — это заблуждение.)

Вот простейший массив из одного элемента, инициализаруемый произвольным значением:

?foo0@@YGXH@Z PROC                    ; foo0, COMDAT

; 172  : {

    push    ebp
    mov    ebp, esp
    push    ecx

; 173  :   int x[1] = { f() };

    call    ?f@@YGHXZ                ; f
    mov    DWORD PTR _x$[ebp], eax

; 174  : }

    mov    esp, ebp
    pop    ebp
    ret    4
?foo0@@YGXH@Z ENDP                    ; foo0


?foo1@@YGXH@Z PROC                    ; foo1, COMDAT

; 178  : {

    push    ebp
    mov    ebp, esp

; 179  :   static int x[1] = { f() };

    mov    eax, DWORD PTR ?$S1@?1??foo1@@YGXH@Z@4IA
    and    eax, 1
    jne    SHORT $LN2@foo1
    mov    ecx, DWORD PTR ?$S1@?1??foo1@@YGXH@Z@4IA
    or    ecx, 1
    mov    DWORD PTR ?$S1@?1??foo1@@YGXH@Z@4IA, ecx
    call    ?f@@YGHXZ                ; f
    mov    DWORD PTR ?x@?1??foo1@@YGXH@Z@4PAHA, eax
$LN2@foo1:

; 180  : }

    pop    ebp
    ret    4
?foo1@@YGXH@Z ENDP                    ; foo1

Он заодно показывет неверность твоего второго утверждения.

М> а теперь поставьте static и посмотрите что из этого выйдет. производительность возрастет в разы.

Я тоже могу привести какой-то частный случай, и начать делать из него обобщённые выводы. Но не буду.

М>при чем тут подкачка?!

Подкачка при том, что изменённые данные в статическом массиве уйдут на диск, при нехватке физической памяти. Стек, как постоянно используемые данные — менее вероятный кандидат для этого.

М> погуглите page guard. узнаете много нового.

Не пойму, каким боком тут сторожевые страницы. Ну, первый раз будет инициализация, как и подкачка страницы PE имиджа. Счёт 1:1. А потом программа будет работать дальше, и счет постепенно изменится не в пользу статиков. Обрати внимание, я не пишу константных статиков, как и ты!

М> а так же объявите массив больше 4 кб в стеке и посмотрите что сделает компилятор. стек не является памятью с произвольным доступом.

О, это такая память, к которой можно обращаться только командами push и pop?

М> он растет вверх и память под него выделяется постепенно.

А че не в лево то? Может быть в сторону младших адресов? Это не сарказм, а иллюстрация что лучше учить сначала — асм, или С.

М> постранично. поэтому, если мы выделяем массив из 8 кб памяти, мы вынуждены совершить одно обращение сначала к последней странице, а потом к первой. если обратимся сразу к первой — приложение рухнет. можете проверить на naked функциях, куда компилятор ничего не вставляет. поэтому, если у нас массив из N страниц, где N намного больше 1, то накладные расходы на пробег по всем страницам (при каждом вызове функции!) становятся ощутимыми.

Ты, похоже, так ничего и не понял стех пор, как лет 5 назад на wasm.ru твой memcpy проиграл коду из мануала (!) по процессору в несколько раз.

Эти обращения играют роль prefetch и подгружают данные в кеш.

А если у нас N страниц в секции PE имиджа — ОС не сможет его загрузить.

Здравствуйте, gear nuke, Вы писали:

GN>А че не в лево то? Может быть в сторону младших адресов? Это не сарказм, а иллюстрация что лучше учить сначала — асм, или С.

Если не ошибаюсь, в старых Unux стек рос вообще вниз на встречу text segment (блоку данных) до разделения стека и кода по разным сегментам и точка где они должны встретится называлась break или break point.

Здравствуйте, gear nuke, Вы писали:

GN>Этот пример — поросту не в тему, зачем начинаешь юлить? Напомню изначальный контекст:
GN>

почему статические массивы иногда на порядок быстрее, а то и на два. ну а то, что они потоконебезопасны — это заблуждение.)

GN>Вот простейший массив из одного элемента, инициализаруемый произвольным значением:
выше было написано _иногда_
а быстрее они по следующим причинам:
1) необходимость иницилизации локального массива при каждом вызове функции;

2) необходимость "пробежки" по каждой странице выделенной памяти в стеке при каждом вызове функции;


GN>; 173 : int x[1] = { f() };
чем такой массив отличается от простой переменной? ничем. а если продолжить развивать мысль, то если у нас есть сильно много перемнных или могучие структуры данных (особенно инициализированные), то стек не лучшее место для их хранения по тем же самым причинам.

GN>Я тоже могу привести какой-то частный случай, и начать делать из него обобщённые выводы. Но не буду.
М>>при чем тут подкачка?!
GN> Подкачка при том, что изменённые данные в статическом массиве уйдут на диск, при нехватке физической памяти.
GN> Стек, как постоянно используемые данные — менее вероятный кандидат для этого.
гражданин, это в сегмнте данных данные есть изначально. в стек они попадают без всякой магии путем простого копирования. другой вопрос, что компилятор может расположить данные не в стеке, а на непосредственных значениях, копируя их инструкцией mov, но тогда у нас резко возрастает размер кода.


М>> погуглите page guard. узнаете много нового.
GN>Не пойму, каким боком тут сторожевые страницы. Ну, первый раз будет инициализация,
блин, да не первый раз она будет. компилятор вставляет в начало функции код, "пробегающий" массив при _каждом_ вызове функции.

М>> а так же объявите массив больше 4 кб в стеке и посмотрите что сделает компилятор. стек не является памятью с произвольным доступом.
GN>О, это такая память, к которой можно обращаться только командами push и pop?
если вы знаете асм, то напишите:
sub esp, 4*1024*69
mov eax, [esp]

и получите исключение. потому как память не выделена. а чтобы выделить ее надо запрашивать страница за страницей. и никак не более страницы за раз.

при повторном вызове функции память, конечно, выдедена. но компилятор об этом не знает и потому совершает "холостой" пробег по всем страницам массива.

GN>Ты, похоже, так ничего и не понял стех пор, как лет 5 назад на wasm.ru твой memcpy проиграл коду из мануала (!) по процессору в несколько раз.
GN>Эти обращения играют роль prefetch и подгружают данные в кеш.
ваша гипотеза неправильная. гуглите описание функции chkstk, которую вставляет в код ms vc.

Здравствуйте, eagersh, Вы писали:

E>Это ты не в теме.Попробуй написать драйвер на С++ для Windows. После этого твои прямые руки станут кривыми
E>Можешь также почитать вот это.
E>http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx

А еще вот это http://security.ti.bfh.ch/projects/lugh.html

Здравствуйте, мыщъх, Вы писали:

М>выше было написано _иногда_

Какое удобное слово, надо взять на вооружение но не оправдывайся, цитата целиком:

кроме того раздражает, что рядовой приплюснутый программист совершенно не в курсе что такое память (оперативная) и чем стек от кучи вообще отличается и почему статические массивы иногда на порядок быстрее, а то и на два.

Ты не в курсе, что по крайней мере пользователи форума RSDN по умолчанию (согласно правилам) считаются образованными людьми? Да, в подфоруме C/C++ подобные вопросы иногда возникают у новичков, что вполне нормально и не свидетельствует о какойто прилюснутости, или другой ущербности

М>а быстрее они по следующим причинам:
М>1) необходимость иницилизации локального массива при каждом вызове функции;

Да никто в критичных местах такой код не напишет в здравом уме!

М>гражданин, это в сегмнте данных данные есть изначально.

Поправлю: в сегменте инициализированных данных.

М> в стек они попадают без всякой магии путем простого копирования.

Да вообще-то страницы обнуляются менеждером вирт памяти, поскольку Винда соответствует какми-то требованиям по безопастности.

М> другой вопрос, что компилятор может расположить данные не в стеке, а на непосредственных значениях, копируя их инструкцией mov

Только константы, переменные будут в регистрах.

М>но тогда у нас резко возрастает размер кода.

Чушь.

mov eax, 12345678h  ; 5 байт

stuff: dd 12345678h ; 4 байта
                    ; +
mov eax, [stuff]    ; 5 байт

GN>>О, это такая память, к которой можно обращаться только командами push и pop?
М>если вы знаете асм, то напишите:
М>sub esp, 4*1024*69
М>mov eax, [esp]

Это называется произвольный доступ

М>и получите исключение. потому как память не выделена. а чтобы выделить ее надо запрашивать страница за страницей. и никак не более страницы за раз.

Что там получу — будет зависить, например от... а не выделил ли я эту память из неподкачиваемого пула

М>при повторном вызове функции память, конечно, выдедена. но компилятор об этом не знает и потому совершает "холостой" пробег по всем страницам массива.

GN>>Эти обращения играют роль prefetch и подгружают данные в кеш.
М>ваша гипотеза неправильная. гуглите описание функции chkstk, которую вставляет в код ms vc.

Моё утверждение о бенефитах при подобном доступе к памяти основано на информации из мануала. Понимаешь? Лишние такты на чтение оборачиваются отсутствием более заметных пенальти из-за заблаговременного кеширования.

И я знаю что это "побочный эффект", и зачем на самом деле _chkstk. Если ты не понимаешь по дургому — мы его даже используем здесь

Здравствуйте, legogogo, Вы писали:

L>Если не ошибаюсь, в старых Unux стек рос вообще вниз

Мне кажется, что в старых книжках младшие алреса рисовали внизу, а в новых вверху. Поэтому я стараюсь употреблять термин не дупускающий двоякой трактовки.

L> на встречу text segment (блоку данных) до разделения стека и кода по разным сегментам и точка где они должны встретится называлась break или break point.

Вот оно откуда оказывается, затирали стек и попадали в отладчик А я когда-то тоже такое придумал, век живи, век учись... нет что бы книжки читать

Ты троллишь или спрашиваешь странное.

Если троллишь — ладно, а если странное, то:

Строка кода на Си не стоит ничего. Вот прикинь, ты бы купил одну строку на Си? Ну, например, int main(int argc, char** argv)?

Проект стоит каких-то, обговоренных с заказчиком денег.
Проект может потребовать тысячи строк.
А может потребовать миллиона.

В случае миллиона строк одна строка выйдет дешевле чем в случае тысячи, но и тоже не факт.
А сколько это в рублях — не скажет никто и никогда.

Здравствуйте, мыщъх, Вы писали:

>> Обратная крайность — когда заранее известно, что частных случаев будет не меньше 30,
>> а движок все равно писать лень, устраивают лапшу для каждого случая — тоже бывает,
М>такое тоже бывает. в том числе и за собой замечаю. но с другой стороны, если остальные 29 случаев будут не завтра и даже не послезавтра, а конкретно взятый случай необходимо решить уже сегодня, то писать движок не только лениво, но и нет времени.

У меня правило — на третьем частном случае (если ситуация неясная) писать движок (при наличии возможности) Пока считаю его оправданным.

ТКС>> Когда-то ведет, когда-то не ведет. Если мы тихо мирно из файла или даже сокета читаем, и нам лень
TKC>> на каждом из 10 уровней при каждом чтении проверку писать — какой тут нафиг дос?
М>смотря как читать и что читать. проверок все равно будет куча. допустим, мы ожидаем увидеть: XXX N M "<yyy@zzz>". какая разница с точки зрения парсера, то ли соединение порвалось, то ли кто-то скобку не закрыл.

Парсеру то может быть и никакой, а вот пользователю это знание скорее всего пригодится. Я уж не говорю о техподдержке, у которой пользователь будет потом спрашивать как ему от надоедливой ошибки избавиться. Не, с кодами и чистом C такое тоже естественно решается, стек ошибок в OpenSSL тому пример, просто редко кто подобным на С систематически заморачивается. Да тот же OpenSSL опять тому пример — полноценный понятный стек ошибок там делается далеко не во всех случаях, недоделок в части обработки ошибок просто куча.

TKC>> Мешают в каком-то коде исключения — значит надо писать без них.
М>а если мне мешают исключения в чужом коде? причем мешают не сами исключения, и даже не код, а скорость внесения в него изменений. допустим, прошу коллегу чего-то добавить в его модуле, потому как это нужно моему (мой модуль хочет сообщить о чем-то важном пра-пра-пра материнской функции). коллега печатльно смотрит на свой код и грит, "слушай, а давай мы щас откомилирующешь свой модуль в программу, вернешь вывод в xml, а мы его запустим скриптом на руби и распарсим". вот... такие у нас исключения.

А вот это если честно вообще не понял. При чем тут исключения?

ТКС>> По мне так наоборот — если мы на 100% не уверены, что справимся без исключений, лучше их использовать.
М>вопрос: как? рецептов много, ни одного правильного.

Что значит как? Как исключения использовать? Смотря в каком языке, наверное. Про С++ общие принципы могу изложить, остальные — пас.

TKC>> Я про прикладной код естественно, без каких-то специфических ограничений. Ну а если логика позволяет
TKC>> и без кодов возврата, и без исключений обойтись — ну так мы в таком случае ничего не теряем, значит
TKC>> ни одного throw в коде и не будет.
М>так ведь такую логику еще спроектировать надо. если думать заранее: а вот что произойдет если вызывающий
М>код забудет проверить ошибку? какие данные мы должны будем ему вернуть, чтобы обойтись без критических последстй?

Я немного другое имел в виду. Тривиальный случай, когда часть программы может работать вообще без ошибок. В случае с кодами возврата обработку ошибок писать в этом куске обычно все равно надо, т.к. как правило есть низлежащие слои, которые могут сбойнуть — malloc там 0 вернет и т.п. В случае с исключениями весь код надо писать в предположении, что исключения могут вылететь из под каждой строчки (т.е., только RAII и откат транзакций), но собственно обработки ошибок (чужих) никакой не требуется. Вылетело из new исключение — откатили состояние в деструкторах, и все. Верхний уровень сам разберется, что ему с этой ошибкой делать. Самое интересное, конечно, это когда состояние безошибочно откатить не получается (в файл ченибудь уже написали, например) — но тут что с исключениями, что с кодами убьешься. Но лично мне с исключениями в среднем удобнее. И ошибок при таком подходе получается заметно меньше — проверено на людях.

ТКС>> Ну это всего лишь не полностью сформулированное ТЗ. В жизни у меня таких почти не бывает,
TKC>> потому что я либо начинаю пытать заказчика, пока не выложит, для чего ему это надо,
М>ну в даннном случае это было задание не сколько на программирование, сколько на знание как нужно правильно программировать. т.е. чем больше "граблей" найдет в задании человек, тем он круче. из того что нашел я:
М>1) как возвращать ошибку?
М>2) нам что всерьез предлагают писать препроцессор?!!!
М>3) какой стандарт имеется ввиду?!

А, понятно. Бывают такие заподлянские задания, да.

М>показательно, что программу я таки не написал. вернее написал, но в ней была пара багов. но оффер таки получил и программу зачли. а вот знакомый индус получивший тоже самое задание убеждал меня, что он его _решил_ и решил его правильно. оффера он не получил я попросил его скинуть программу на мыло. ну что? программа как программа. работает, не падает. про вложенные комменты, про пунткы 1, 2, 3 она ес-но не знает, но явных багов в ней нет.

М>вот и выходит, что я знаю как правильно программировать, но сам программировать не умею. а он умеет, но не знает.

Ну иди в начальники, будешь таким кодерам задания разжёвывать Если понравится, конечно. Мне например не особо нравится, с кодом оно как-то приятнее и спокойнее, чем с подчиненными. Есть правда и плюсы.

Здравствуйте, gear nuke, Вы писали:

GN>Вот оно откуда оказывается, затирали стек и попадали в отладчик А я когда-то тоже такое придумал, век живи, век учись... нет что бы книжки читать

break point это линия разделения стека и кода, это не точка останова в отладчике. Вот скриншот книги где про это пишут: http://slil.ru/28369178

Здравствуйте, мыщъх, Вы писали:

М>>>а тогда я еще работал не как fte, а как контрактор и на каждый чих посылал инвойсы. которые выплачивались. вот теперь вопрос: на фига было аппрувить инвойс, если результатами реверсинга не воспользовались?
CC>>Ну, задача выполнена, работа проделана, надо оплатить. А то, что заказчик не сумел/захотел воспользоваться результатами этой работы — это его трудности.
М>по поводу невостребованности работы я совсем не комплексую. я просто понять пытаюсь зачем меня тут держат
Видимо на тот случай, если твои умения вдруг резко понадобятся на всю катушку такого как ты не пришлось бы искать чёрти где чёрти сколько времени и неизвестно за какие деньги.

М>и бывает так, что даже если целую неделю реверсил что-то большое и могучее, в ходе чего создал три мелких скрипта для иды, то вписывать это одним пунктом рисковано, т.к. если не утвердят, мы теряем сразу всю неделю. лучше разбить эту задачу на кучу мелких подзадач. допустим, не утвердили реверсинг, но утвердили скрипты.
М>и оплачивать работу в этом случае необязаны.
Мда, и правда странная система.

Здравствуйте, gear nuke, Вы писали:

М>>выше было написано _иногда_
GN>Какое удобное слово, надо взять на вооружение
берите надеюсь, что пригодится

GN> но не оправдывайся, цитата целиком:
GN>

кроме того раздражает, что рядовой приплюснутый программист совершенно не в курсе что такое память (оперативная) и чем стек от кучи вообще отличается и почему статические массивы иногда на порядок быстрее, а то и на два.

GN>Ты не в курсе, что по крайней мере пользователи форума RSDN по умолчанию (согласно правилам) считаются образованными людьми?
см. выше слово "рядовой". это раз.
два. что такое "образованный человек"? это специалист в своей области. на RSDN очень много очень умных людей, в том числе и гуру по плюсам, которые знают такое, что ни в какой книжке не откопаешь. и опыт проектирования у них имеется. о том, что при продвижении вверх по абстрактивной лестнице, мы забираемся так высоко, что уже не различаем низкоуровневые детали -- вы же сами нам это и демонстрируете.

М>>1) необходимость иницилизации локального массива при каждом вызове функции;
GN>Да никто в критичных местах такой код не напишет в здравом уме!
тогда почему этот код пишут? причем в очень больших колличествах?

М>>гражданин, это в сегмнте данных данные есть изначально.
GN>Поправлю: в сегменте инициализированных данных.
в PE/ELF файле неиницилизированных данных просто не бывет. бываеют секции неиницилизированных данных, которые при загрузке _гарантированно_ заполняются нулями

М>> в стек они попадают без всякой магии путем простого копирования.
GN> Да вообще-то страницы обнуляются менеждером вирт памяти, поскольку
GN> Винда соответствует какми-то требованиям по безопастности.
в стек данные копируются при каждом вызове функции. "зачистка" страниц физической памяти происходит только при коммите страницы ранее принадлежавшей другому процессу.

М>> другой вопрос, что компилятор может расположить данные не в стеке,
M>> а на непосредственных значениях, копируя их инструкцией mov
пардон, заговорился. следует читать: "расположить данные не в сегменте данных, а в коде в непосредственных значениях инструкций mov", впрочем, багдад часто их прямо в коде и размещает.

ЗЫ. не вижу смысла дальше спорить. давайте сойдемся, что каждый остается при своем. пример кода где static дает резкий прирост производительности выше уже был. проверить это может каждый котому оно интересно. так же было сказано (мной), что не стоит делать обобщающих выводов, и механически пихать static везде, без понимания как оно работает.

в ответ вы в качестве контр-примера привели код с массивом из одного дв. слова, который кажется мне очень сильно надуманным и который не противоречит моему высказыванию о необходимости понимания того, как оно на самом деле работает на низком уровне.

Здравствуйте, мыщъх, Вы писали:

М>утверждение, что на плюсах можно сделать более быстрый код, чем на си по меньшей мере сомнительно и требует доказательств. или хотя бы обоснований.
Равно как и обратное утверждение.
В общем виде это недоказуемо. Всё сведётся к частным случаям. Кроме того, не стоит забывать что на С++ можно писать как на С.

М> кстати, кто мне объяснит почему в ms vc выбор исключения реализован так, как он там реализован? это же ужос. именно потому исключения и не рекоммендуется бросать в ядре.
А поподробнее, что тебя там так ужаснуло?

М>язык определяет мышление хотим мы того или нет. постоянно сталкиваюсь, что плюсовики тяготеют к решением в общем виде, в то время как сишники решают задачу в частном виде, что в разы быстрее.
М> вон тут в одной текущей задаче, которую сначала показали плюсовику и спросили сколько займет ее решение, он сказал, тут типа нам нужно писать могучий движок и это проект на полгода. его коллега (сишник) поинтересовался: а зачем? ведь _поставленная_ задача укладывается в сотню строк кода. ответ был ошеломляющим: "ну и что мы так и будем по сотне строк кода писать для решения частных задач каждый раз как они возникают? задачи надо решать раз и навсегда!!!"
Абстрагируясь от С++ vs C замечу, что решение в частном виде как правило плохо расширяемо. Видимо потому и желает твой плюсовик заранее обезопасить себя от полного переписывания всего кода когда срочно понадобится "всего лишь добавить оттакую вот функциональность". Сишник же похоже решил поступить по принципу "а после нас хоть потоп".
Вообще примеру явно не хватает некоторых деталей, а конкретно: описываемая задача пойдёт в production код, или она надо чисто для потестить и выкинуть?

М>ЗЫ. я не противник исключений. но ругая си за "...дайте детям динамит", исключения в плюсах выглядят как "...дали террористам атомную бомбу и средство ее доставки". наличие исключений (и их агрессивная пропаганда) приводят к их бездумному использованию. поэтому, если мы на 100% не уверены, что знаем как юзать исключения, их лучше не юзать.
+1

М>ЗЫ.ЗЫ. коды возврата тоже зло. и в идеале нужно проектировать программу так, чтобы _явная_ проверка на ошибку не требовалось. ну вот например, обломались мы с открытием файла в текстовом редакторе, но проверить это забыли. передали дескриптор функции чтения. функция чтения вернула ноль байт. вывели мы эти ноль байт на экран получив пустоту. конечно, отсутствие сообщений об ошибке не есть хорошо, но при данном подходе и не смертельно.
Зато диагностика ошибки при таком подходе будет pain in ass. Потому как придётся трейсить вглубь чтоб найти откуда таки ноги у ошибки растут.

Здравствуйте, legogogo, Вы писали:

L>break point это линия разделения стека и кода, это не точка останова в отладчике.

The bp, bu, and bm commands set one or more software breakpoints. You can combine locations, conditions, and options to set different kinds of software breakpoints

L> Вот скриншот книги где про это пишут: http://slil.ru/28369178

Это история.

Здравствуйте, eagersh, Вы писали:

E>Он не говорил что все надо писать на ассемблере.Он говорил, что часто сейчас програмисты используя языки высого уровня не понимают что находится внутри этого кода и какой код генерируется.Понимание таких вещей показывает квалификацию програмиста.

Квалификацию программиста показывает только способность к решению сложных задач. Задача — это решение некоей проблемы, которая возникает в реальном мире.
Разбирательство в потрохах кода само по себе задачей не является, хотя порой бывает необходимым для решения других — настоящих — задач.

Здравствуйте, мыщъх, Вы писали:

М>см. выше слово "рядовой". это раз. два. что такое "образованный человек"?

Демагогию пропускаем.


М>>>гражданин, это в сегмнте данных данные есть изначально.
GN>>Поправлю: в сегменте инициализированных данных.
М>в PE/ELF файле неиницилизированных данных просто не бывет. бываеют секции неиницилизированных данных, которые при загрузке _гарантированно_ заполняются нулями

Не знаю к чему ты написал про файлы, и не знаю про Эльф. На всякий случай процитирую доку по PE/COFF

IMAGE_SCN_CNT_UNINITIALIZED_DATA The section contains uninitialized data.

На всякий случай напомню — исполняемый образ не загружается, а маппится (как объект ядра "секция"). При этом в физической памяти данные оказываются не в момент загрузки (которого и быть не может), а при доступе к соотвествующим данным имиджа.
Еще напомню, что страницы (в первую очередь — редко используемые) физической памяти могут уйти в своп.

Не знаю, зачем я тебе всё это напоминаю, ведь ты писал про это целую статью Может, потому что она не такая подробная, как аналогичная статья f0dder'а.

Еще процитирую выброшенный контекст:

М>а быстрее они по следующим причинам:
М>1) необходимость иницилизации локального массива при каждом вызове функции;

При этом память стека не может быть выгружена в своп (точнее — может конечно, но это маловероятно, поскольку к ней есть постоянные обращения).

Так вот, дисковые операции существенно дороже инициализаций константами, которые ты почемуто неявно подразумеваешь.

А почему ты их подразумеваешь константными? Что бы потом сравнить это с совершенно с другим вариантом: когда данные не являются константными. Иначе зачем еще инициализировать массив в стеке? Будь добр, ответь на этот вопрос, не обязательно здесь, себе. Говоря о рядовых приплюснутых программистах, ты похоже не знаешь, что их код будет проходить ревью, и, этот вопрос может быть задан. И они либо ответ: "я думал о задаче а не о premature optimization", либо на первой ошибке научатся так не далать, где это уместно. Так же как и ты когда-нибудь научишся не экономить на написании ключевого слова const.

М>>> в стек они попадают без всякой магии путем простого копирования.
GN>> Да вообще-то страницы обнуляются менеждером вирт памяти, поскольку
GN>> Винда соответствует какми-то требованиям по безопастности.
М>в стек данные копируются при каждом вызове функции. "зачистка" страниц физической памяти происходит только при коммите страницы ранее принадлежавшей другому процессу.

Неужали ты думаешь, что я не читал выделенное, зачем повторяться? Зачем пишешь чушь про другой процесс, понятия "принадлежала" нет, есть "принадлежит" и "свободна". И к чему "только", если я писал уже про счёт 1:1

Автор: gear nuke
Дата: 19.12.09

М>>> другой вопрос, что компилятор может расположить данные не в стеке,
M>>> а на непосредственных значениях, копируя их инструкцией mov
М>пардон, заговорился. следует читать: "расположить данные не в сегменте данных, а в коде в непосредственных значениях инструкций mov", впрочем, багдад часто их прямо в коде и размещает.

Да я понял, что ты имел ввиду! Даже несмотря на то, что ты зачем-то снова пишешь"сегмент" говоря о плоской модели И повторю пример, показывающий, что на самом деле общий размер уменьшится:

mov eax, 12345678h  ; 5 байт

stuff: dd 12345678h ; 4 байта
                    ; +
mov eax, [stuff]    ; 5 байт

М>ЗЫ. не вижу смысла дальше спорить.

А я и не спорю. Я методично нахожу пробелы в твоих знаниях и тыкаю тебя в них носом, что бы не обзывался на рядовых приплюснутых программистов, включая меня.

М> давайте сойдемся, что каждый остается при своем. пример кода где static дает резкий прирост производительности выше уже был. проверить это может каждый котому оно интересно. так же было сказано (мной), что не стоит делать обобщающих выводов, и механически пихать static везде, без понимания как оно работает.

М>в ответ вы в качестве контр-примера привели код с массивом из одного дв. слова

Что-то мешает увеличить количество элементов? Я привёл простейший пример общего случая (ведь не всегда значения для инициализации известны на этапе компиляции) что бы показать, что для инициализации статиков требуются дополнительные затраты, которые к тому же не потокобезопасны.

А ты взял какой-то частный случай как показатель что остальные глупее тебя.

М>, который кажется мне очень сильно надуманным и который не противоречит моему высказыванию о необходимости понимания того, как оно на самом деле работает на низком уровне.

Я опять повторю твоё высказывание:

рядовой приплюснутый программист совершенно не в курсе что такое память (оперативная) и чем стек от кучи вообще отличается

Обрати внимание, я даже ни разу (до этого) не сказал, что понимание что такое оперативная память практически бессмысленно в настояшее время. Оно может быть полезно вкупе с пониманием кеша и виртуальной памяти (которого нет у тебя).

Здравствуйте, мыщъх, Вы писали:

М>так ведь это и есть мой поинт. производительность труда к строчкам кода не имеет ни малейшего отношения, особенно когда продукт уже взлетел и вдруг забарахлил в полете. и тут уже начинаешь думать как его пофиксить так, чтобы окончательно не свалить его в штопор. и тут чем меньше изменений вносится для устранения проблемы — тем лучше.

Поддержка проекта — это совсем другая история. К ней нельзя применять те же метрики, что к разработке. (Мне, например, часто приходится заниматься поддержкой — и обычно у меня количество строк кода уходит в минус, т.е. стираю больше, чем пишу )

М>кстати, тезис "платят за то, чтобы работало" тоже как бы не совсем верный. если оно работает, то платят только один раз. а вот чтобы платили постоянно надо добиться, чтобы оно как бы работало, но и как бы не совсем. это на рынке шаровар платят за решения (да и то с оговорками). а при работе на фирму платят за работу. т.е. даже в штатах ситуация не сильно отличается от ссср. хожу на работу — получаю зарплату. а если еще и работаю — то зарплату + премию

Извини, но абсолютно не согласен. Специально делать так, "чтобы оно как бы работало, но и как бы не совсем" — это халтура. И кстати не факт, что такой подход в конечном итоге окажется более доходным. Успешно закончив проект, даже если он действительно закончился, и ты больше не нужен, гораздо легче найти следующий проект на большие деньги. А "застряв" на постоянном ковырянии в болоте, которые ты сам же и инициируешь — перестанешь развиваться.

М>кстати, тезис "платят за то, чтобы работало" тоже как бы не совсем верный. если оно работает, то платят только один раз. а вот чтобы платили постоянно надо добиться, чтобы оно как бы работало, но и как бы не совсем. это на рынке шаровар платят за решения (да и то с оговорками). а при работе на фирму платят за работу. т.е. даже в штатах ситуация не сильно отличается от ссср. хожу на работу — получаю зарплату. а если еще и работаю — то зарплату + премию

Видимо, это и есть "хорошо подвешенный язык" ?
Мда, язык мой — враг мой...

По всему, пашиным хозяевам позарез нужна война в Европе
(уверены — к ним не залетит, в предыдущих двух не залетало жеж)

Здравствуйте, gear nuke, Вы писали:

GN> А я и не спорю. Я методично нахожу пробелы в твоих знаниях и тыкаю тебя в них носом,
GN> что бы не обзывался на рядовых приплюснутых программистов, включая меня.
что-то это у вас плохо получается. в смысле находить и тыкать. эх... вашу бы энергию да в мирное русло!

GN> А ты взял какой-то частный случай как показатель что остальные глупее тебя.
"не бойтесь показаться дураком, бойтесь показаться слишком умным" (с)

GN>Обрати внимание, я даже ни разу (до этого) не сказал, что понимание что такое оперативная память практически бессмысленно в настояшее время. Оно может быть полезно вкупе с пониманием кеша и виртуальной памяти (которого нет у тебя).
а зачем вы мне это (теперь) говорите? извините за грубость, но мне ваша точка зрения совершенно неинтересна. потому что вы не сути дела докопаться хотите, а занимаетесь самоутверждением, споря с очевидным. изначальный посыл был о том, что размещение массивов в стеке могут дать сильную просадку производительности. пример тому был мной продемонстрирован. вы же продемонстрировали конт. пример, пытаясь доказать, что в _общем_ случае что окажается быстрее еще неизвестно, что _полность_ совпдает с моим высказыванием. т.е. может дать просадку, а может и не дать. зависит от ситуации.

если же вы пытаетесь доказать, что все плюсовики знают низкий уровень, так вы это никогда не докажите. "вы их всех поименно опрашивали?" (с), а у вас (как вы неожиданно признались) ниже виртуальной памяти ничего нет и более глубокие слои абстракции вас уже не интересуют в принципе. хотя бы чисто в познавательных целях.

ЗЫ. ну так бы сразу и сказали, что вам хочется меня "тыкнуть". я бы сразу назвал себя лосем и поставил вам плюс. мне же ведь совсем не жалко. я уже давно понял, что я ни хвоста не знаю и ничего не умею. я этого даже и не скрываю. причем, не только от вас (ну от вас-то мне ни жарко ни холодно), но и от своих работодателей, для которых не исключено, я фигура чисто имидживая. потому как на мое предложение: "мужики, а давайте я чего-то полезного сдеалаю?" они мне прямым текстом отвечают: "мыщъх, ты это... ты побереги себя... ты это... лучше отдохни... и в офис лучше не ходи. и вообще давай мы тебя в индию отправим -- в индии щас тепло". а рестоне снегу намело. пять человек замело совсем. школы закрыты. дороги заблокированы. писец короче.

Здравствуйте, мыщъх, Вы писали:

М>а так исключения в плюсах это грубо говоря встроенный диспетчер сообщений. на си он пишется влет, причем заточенный под нужды конкретной задачи, а не вообще и в целом.

Грубо говоря ценность этого диспетчера в том, что он стандартный. Пока нет стандартного — Коля, Вася и Петя будут ваять Диспетчер Сообщений Имени Себя. Заточенный и все дела. Вот только договориться они никогда не смогут. В случае стандартных исключений — договоренность получается бесплатно по дизайну.

Правда некоторые особенности исключений в C++ ставят под большое сомнение выгоды использований исключений между библиотеками — только внутри конкретной библиотеки. Снаружи опять же — коды возврата.

Здравствуйте, мыщъх, Вы писали:

М>автомат состояний, правда, мне не подходил, т.к. производительность очень критична и важно как можно скорее понять, что тут мы ничего не найдем и побыстрее свалить отсюда, а поскольку последовательность команд (порядок которых произволен, регистры произвольны...) начинается с mov, то под нее попадает практически любой код. поэтому, там поиск получилися очень запутанным. сначала ищем наиболее уникальные комбинации байт (которые как можно редко встречаются), задавив регистры битовыми масками. если нашлось что-то прыгаем назад и начинаем чекать зависимость по регистрам. для ускорения сути дела заводится массив стркутур, проидексированный регистрами и натянутый на граф.

Ну тогда воспользоваться алгоритмом составления словаря при зиповании, точнее — не словаря (это второй этап), а самого сжатия (первый этап — поиск повторений) — от противного — самый отличающийся кусок — который раньше не повторялся. Ну, правда, со скоростью не очень.

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, eagersh, Вы писали:

E>>Это ты не в теме.Попробуй написать драйвер на С++ для Windows. После этого твои прямые руки станут кривыми
E>>Можешь также почитать вот это.
E>>http://www.microsoft.com/whdc/driver/kernel/KMcode.mspx

GN>А еще вот это http://security.ti.bfh.ch/projects/lugh.html
Я встречал тоже проэкты которые написанные на С++ для Windows kernel.Но их очень мало и это исключения.Лично я не вижу никаких преимуществ в исльзовании С++ для кернел.На OSR переодически возникают дискусии по поводу использования С++ в Windows driver development.Сторонники использования С++ не могут привести ни одного серьезного аргумента почему код на С++ для драйвера лучше чем на С.Пожалуй один аргумент есь.Это использования .cpp файла.Но это не использования языка вцелом.

Здравствуйте, Tekk, Вы писали:

T>Здравствуйте, eagersh, Вы писали:

E>>Он не говорил что все надо писать на ассемблере.Он говорил, что часто сейчас програмисты используя языки высого уровня не понимают что находится внутри этого кода и какой код генерируется.Понимание таких вещей показывает квалификацию програмиста.

T>Квалификацию программиста показывает только способность к решению сложных задач. Задача — это решение некоей проблемы, которая возникает в реальном мире.
T>Разбирательство в потрохах кода само по себе задачей не является, хотя порой бывает необходимым для решения других — настоящих — задач.
Я имел ввиду понимание кода, а не разбирательство.Это разные вещи.

Здравствуйте, gear nuke, Вы писали:

GN>Здравствуйте, eagersh, Вы писали:

E>>Но С++ не все так плохо в системном програмировании.Можно програмировать на нем тоже, но правда с ограничениями.Надо хорошо понимать эти ограничения, и как их обходить. Microsoft например сейчас широко использует кернел API — WDF которая написанна на С++.Но правда Microsoft все еще не рекомендует использовать С++ для написания драйверов. Их понять можно, так как драйвера фактически часть OS со всеми вытекающими последствиями.

GN>Я довольно неплохо знаю ситуацию в default OS, основная проблема — MS до сих пор не удосужились сделать C++ runtime.
Я думаю они просто не видят в этом смысла.Преимуществ в использовании С++ практически не будет .Да и запрос на использовании С++ от програмистов кто пишет драйвера практически нулевой.Есть исключения конечно, но это энтузиасты которые любят все новое.

Здравствуйте, eagersh, Вы писали:

E>Я имел ввиду понимание кода, а не разбирательство.Это разные вещи.

В чем разные, в данном контексте?

Здравствуйте, eagersh, Вы писали:

E>Я встречал тоже проэкты которые написанные на С++ для Windows kernel.Но их очень мало и это исключения.

Их намного больше, чем кажется на первый взгляд.

E>Лично я не вижу никаких преимуществ в исльзовании С++ для кернел.На OSR переодически возникают дискусии по поводу использования С++ в Windows driver development.

Это уже показатель, которого достаточно. Так же когда-то возникали предложения использовать С вместо ассемблера. И точно так же С в то время подебил Ригидность всегда проигрывает, дайте ей время

E>Сторонники использования С++ не могут привести ни одного серьезного аргумента почему код на С++ для драйвера лучше чем на С.

Я (и не только) могу привести их, по крайней мере, несколько. Однако очевидно уже, что они не будут восприняты как серьёзные. Их можно только на свом опыте оценить.

E>Пожалуй один аргумент есь.Это использования .cpp файла.Но это не использования языка вцелом.

Здравствуйте, Кэр, Вы писали:

Кэр>В случае стандартных исключений — договоренность получается бесплатно по дизайну.

Кодер не может оценить стоимость дизайна

М>и в отличии от приплюснутых исключений, которые черт знает как реализованы в каждом компиляторе на каждой платформе, наш диспетчер сообщений будет успешно работать и в ядре, и даже в другой галактике (если, конечно, он писан не через попу, а писать его совсем недолго и его легко заменить на любой другой).
Тут главное слово "если."

М>это не значит, что нужно переизобретать плюсы но утверждение, что на плюсах можно сделать более быстрый код, чем на си по меньшей мере сомнительно и требует доказательств. или хотя бы обоснований. кстати, кто мне объяснит почему в ms vc выбор исключения реализован так, как он там реализован? это же ужос. именно потому исключения и не рекоммендуется бросать в ядре.
Попробуй отсортировать какой-нибудь большой массив int-ов используя qsort() и std::sort<>().

TKC>> а не затевал спор об их избыточности/необходимости в неоговоренных заранее ситуациях
М>язык определяет мышление хотим мы того или нет. постоянно сталкиваюсь, что плюсовики тяготеют к решением в общем виде, в то время как сишники решают задачу в частном виде, что в разы быстрее. вон тут в одной текущей задаче, которую сначала показали плюсовику и спросили сколько займет ее решение, он сказал, тут типа нам нужно писать могучий движок и это проект на полгода. его коллега (сишник) поинтересовался: а зачем? ведь _поставленная_ задача укладывается в сотню строк кода. ответ был ошеломляющим: "ну и что мы так и будем по сотне строк кода писать для решения частных задач каждый раз как они возникают? задачи надо решать раз и навсегда!!!"
Казалось бы, при чем тут язык?

М>ЗЫ.ЗЫ. коды возврата тоже зло. и в идеале нужно проектировать программу так, чтобы _явная_ проверка на ошибку не требовалось. ну вот например, обломались мы с открытием файла в текстовом редакторе, но проверить это забыли. передали дескриптор функции чтения. функция чтения вернула ноль байт. вывели мы эти ноль байт на экран получив пустоту. конечно, отсутствие сообщений об ошибке не есть хорошо, но при данном подходе и не смертельно. а вот если функция чтения файла среагирует на нулевой дескриптор падением или возвратом неиницилированного мусора с кодом ошибки, вот тут придется туго.
Кривой какой-то дизайн.

М>ЗЫ.ЗЫ.ЗЫ. а что делать если прототип функции объявлен как void remove_comments(char *s), нам менять его нельзя, а нужно удалить из строки си и си++ комментарии? а если комментарии кривые? допустим, вложенные /* /* */ */ ? вполне реальный пример из жизни. тестовое задание от макровижн. когда они мне его прислали первый раз, я сказал, что void не катит. через год они присылают тоже самое (!) задание с тем же (!) прототимом, но с припиской на полях: s указаывает на строку с комментами _по_ _стандарту_. т.е. согласно ТЗ ошибки возникнуть не может. но а если таки выясняется, что комменты у нас не по стандарту? что делать-то? менять прототип мы не могем. я плюнул и в обработчике ошибок воткнул *s = 0. не уверен, что правильно, но...
М>а что было еще делать? исключение кидать? а кто его ловить будет? а не станет ли оно намного большей неожиданностью, чем непонятного почему обнулившаяся строка?
Ты писал реальный код или какое-то тестовое задание? Ясно ведь что замарачиваться с правильностью камментов не надо. Ну не пишешь ты компилятор, не пишешь. А это тестовое задание посмотрят и выкинут. Более того, через год тебе присылают уточненное задание где говорят что ошибки возникнуть не может, но ты и здесь упорствуешь. Надо было просто написать что код предполагает правильные камменты а ты "обнуляешь" строку.

GN>>Если к этому коду дописать static, он станет медленнее, поскольку инициализация будет в обоих случаях.
М>с какого это перепугу при static у нас появится что либо? компилятор в студию. даже с выключенной оптимизацией при static оно будет в сегменте данных, откуда и загрузится с диска, а в стеке оно будет копироваться из сегмента данных в стек уже в рантайме при каждом вызове функции, что сильно тормозно. рассмотрим для примера функцию, которая превращает число из 0..F в символ.

М>foo(int a)
М>{
М>char x[]="0123456789ABCDEF";
М>return x[a & (0x10-1)];
М>}

М>пример жизненный. надуманным его назвать трудно. а теперь поставьте static и посмотрите что из этого выйдет. производительность возрастет в разы. если не в 6 раз, то раз в 3 точно с учетом всех прочих накладных расходов. а ведь у нас массив всего из 16 байт...
А что, авторам книг уже не надо ставить retun type? Про implicit int я, конечно же, знаю.

З.Ы. Твоих книг не читал но рад что ты смог пробиться в жизни!
З.З.Ы. Почему обломалось с Индией, если не секрет?