программистские ссылки

[avva]

Два отличных анализа дизассемблированного кода:

• Анализ бага в Excel (PDF), о котором я писал недавно. Очень, очень увлекательно и интересно. Подробно и дотошно объясняется, чем был вызван этот баг. (за ссылку спасибо ygam)
  
  
• Анализ червя Storm Worm, включая его руткит. Тоже исключительно интересная и подробная информация. Мне особенно понравилось про средства обнаружения виртуальных машин и песочниц анти-вирусов.
  

И заодно, раз уж программистские ссылки:

C++ FQA, развернутая критика C++, выполненная в виде комментария к известному C++ FAQ. Не со всем я соглашусь, но много дельных и заслуженно едких замечаний. Автор - yosefk, обсуждения есть по-английски в reddit и по-русски в ЖЖ.

Update: И еще одна полезная ссылка для любителей ассемблера: сравнение GAS и Intel-синтаксиса. Я так и не научился как следует читать программы в AT&T-синтаксисе, которым пользуется GAS (ну, скорее, научился с грехом пополам), поэтому мне понравилось подробное сравнение.

Comments

[cmm.livejournal.com]

Так и хочется ему ответить

Вы явно хотите об этом поговорить.

[ak_47]

Хотел, но сдержался. :) Там уже люди поумнее меня всё правильно сказали. Да, собственно, и сам Страуструп уже давно вполне убедительно ответил на многие нападки yosefk.

[cmm.livejournal.com]

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

кто созрел типа, тот принимает к сведению.

[ak_47]

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

Но предъявлять претензии к С++ по поводу того что там нет garbage collector'а или reflection, например, это вообще как-то мимо кассы. Когда С++ был в зените своей славы, то он предлагал наилучший компромисс между возможностями языка и ценой за них. С тех пор многое поменялось. То что было дорого - стало дёшево, изменились требования к процессу разработки и т.д.. Сегодня другие языки и среды предлагают наилучший компромисс. Их и надо использовать.

Смеяться над тем что в С++ вместо "struct" используют "class" это детство недоигравшее в одном месте.

[cmm.livejournal.com]

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

фигня ещё и в том, что утверждать подобные вещи как объективные истины — не очень разумно.

Смеяться над тем что в С++ вместо "struct" используют "class" это детство недоигравшее в одном месте.

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

[ak_47]

То что С++ стал самым распространённым general purpose языком это объективная истина или какая? Язык программирования это не только следование академическим правилам. Как и любое другое инженерное изделие, язык программирования обязан учитывать сложившиеся реалии в индустрии. С++ предложил набор качеств, который по совокупности был достаточно хорош для того, чтобы язык занял лидирующие позиции. Остальное, как говорится, история.

По поводу стиля C++ FQA. Натыкаясь на такой стиль теряешь доверие и к остальным, в общем-то разумным, доводам. Но основное нарекание не на стиль как раз. А на то что к С++ предъявляются надуманные требования. Автор хочет managed язык, но чего он к С++ то прицепился в таком случае?

[cmm.livejournal.com]

То что С++ стал самым распространённым general purpose языком это объективная истина или какая?

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

Натыкаясь на такой стиль теряешь доверие и к остальным, в общем-то разумным, доводам.

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

Автор хочет managed язык, но чего он к С++ то прицепился в таком случае?

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

[ak_47]

Про миллиарды мух это не риторический шаблон, а демагогический приём. С++ выбирали не мухи, а инженеры и руководители проектов. Они, как тогда, так и сейчас, руководствуются вполне объективными критериями. Вы пытаетесь представить картину в чёрно-белом свете: или давайте эксепшены как в С#/Java, или вообше никаких; или давайте ОО/reflection как сейчас, или вообще не надо.

На заре возникновения С++ нельзя было отказаться от совместимости с С. В тоже время, С++ предлагал адекватные возможности на тот момент, которые соответствовали требованиям индустрии. В начале/середине 90-х лучше было иметь эксепшены как в С++ чем вообще никаких; лучше было иметь поддержку ООП как в С++ чем вообще никакую, и т.д..

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

[cmm.livejournal.com]

Про миллиарды мух это не риторический шаблон, а демагогический приём. С++ выбирали не мухи, а инженеры и руководители проектов. Они, как тогда, так и сейчас, руководствуются вполне объективными критериями.

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

В начале/середине 90-х лучше было иметь эксепшены как в С++ чем вообще никаких

если сейчас таких эксепшенов лучше не иметь, то почему их надо было иметь тогда?

Лучше было иметь поддержку ООП как в С++ чем вообще никакую

ditto.

(по фоновому пункту "сегодня C++ лучше не пользоваться", я так понимаю, возражений нет?)

[ak_47]

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

Про сейчас и тогда. В 90-х можно было бы теоретически иметь всё как сейчас. Но это вылилось бы в неприемлемую цену. Поэтому и не имели. Имели то что было по карману. В 30-х годах автоматическую коробку передач имели только самые роскошные модели. А сегодня все имеют.

Про то что в большинстве случаев сегодня лучше не пользоваться С++ я сказал вам ещё в одном из первых ответов. Да, по современным меркам С++ не удовлетворяет многим требованиям. Для большинства новых проектов сегодня я выберу другой язык.

[cmm.livejournal.com]

Они иногда ошибаются, но в целом работу свою делают.

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

разумеется, IT-индустрия в большинстве случает свою работу делает.

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

Имели то что было по карману.

не пользоваться эксепшенами вообще — лучше, чем пользоваться сиплюсплюсными, я к этому.

это не такой критичный фичер, чтобы без него какие-то программы вообще не были возможны.  можно просто "не иметь".

Про то что в большинстве случаев сегодня лучше не пользоваться С++ я сказал вам ещё в одном из первых ответов.

и правда, прошу прощения!

[ak_47]

Про оптимальность я с вами не соглашусь. Если система работает достаточно долгое время (а на С++ пишут уже достаточно долго), то случайные завихрения отмирают. "Рыночность" в этом случае работает совершенно замечательно. Была бы конкурентоспособная альтернатива - люди бы на неё потихоньку переползали. Может не все и не сразу, но такого перелоса как с С++ не было бы.

Криртерий оптимальности не такой уж и сложный: сколько стоит дом построить сделать и сдать проект. Если на других языках/в других средах это стоит дороже, то они менее оптимальны для данного проекта. Для большинства проектов С++ оказался в самый раз.

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

А что касается эксепшенов - так там большого выбора и не было. Никто не спрашивал хотят ими пользоваться или не хотят. Эксепшены были и надо было с ними жить. Обрабатывать ошибки старыми методами (сигналы, if'ы и т.д.) стало просто слишком трудоёмко и неэффективно (читай - дорого). Надо было что-то с этим делать. Или вы думаете что это от нечего делать комитет сидел и выдумывал чего-нибудь эдакого? Эксепшены явились ответом на реальные потребности разработчиков. С++ предложил вполне приемлимое решение обработки эксепшенов для своего времени.

[cmm.livejournal.com]

Для большинства проектов С++ оказался в самый раз.

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

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

может, может.  IT индустрия находится в до-инженерной стадии, и до недавнего времени nobody was ever fired for choosing C++.

С++ предложил вполне приемлимое решение обработки эксепшенов для своего времени.

C++ предложил вполне приемлемое решение обработки эксепшенов в C++-программах, в лучшем случае.  почувствуйте разницу. :)

[ak_47]

Вы видите что проекты страдают, потому что имеете возможность сравнить с альтернативой. Перенеситесь мысленно в 1991 год. У вас есть выбор начинать большой сложный (по меркам '91-го года) проект на С или на новом языке С++, который к тому же поддерживает ваши старые наработки на С. Естественно что большинство здравомыслящих инженеров и менеджеров ухватилось за такую возможность.

Т.е. по-вашему они все должны были бы сидеть ещё 20 лет на С и ждать пока чудесным образом вдруг появятся C#/Java с правильными эксепшенами, reflection, ОО и всем прочим что в них есть. И вот тут-то все бы дружною гурьбой пересели с С на новенькие красочные компалеры.

Индустрия может находится в любой стадии, на самом деле. Вопрос лишь в том за сколько денег она делает продукт. Те кто делают медленно и дорого вылетают из игры. Так же как в своё время WordPerfect вылетел со своим ассемблером, сегодня вылетают (или уже стоят на подходе) те кто цепляются за С++.

[cmm.livejournal.com]

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

по-Вашему, в таком изложении они выглядят здравомыслящими? :)

[ak_47]

Конечно выглядят. А что же им прикажете делать? Продолжать сверять аллокации и ручками виртуальные таблицы писать?

[zigmar.livejournal.com]

по фоновому пункту "сегодня C++ лучше не пользоваться", я так понимаю, возражений нет?
Это бред, а не возражение. До сих пор, есть достаточно много областей применения (хотя и меньше, чем раньше), для для С++ реальных альтернатив. Чтоб заранее избежать пустых нападок - я говорю, про весь класс софтвера, который требователен к производительности настолько, чтоб языки более высоко уровня не подошли, но достаточно сложного, чтоб написание на более низкоуровневых языках (вроде С) было бы неоправданным мазохизмом и тратой времени.

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

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

[cmm.livejournal.com]

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

не надо так плохо относиться к C.
если не пытаться изо всех нехемульских сил пытаться пользоваться им как C++, то всё будет замечательно!

[zigmar.livejournal.com]

Я вижу очень мало реальных (т.е. технических, а не религиозных) причин использовать С а не С++. Да, использования чистого С даёт бинарную совместимость (что, в том числе, очень полезно для интеграции с другими языками), но по всем остальным причинам даже подмножество C++, которое реализует сходную с базовым С функциональность, предпочтительнее по безопасности и удобству. А используя С++ "с головой" производительность не только не страдает, но и бывает лучше (например за счёт инлайнинга). С99, кстати, стирает многие из различий С и С-подобного подмножества С++, но по сути является тем-же С++, но в профиль.

[cmm.livejournal.com]

С99, кстати, стирает многие из различий С и С-подобного подмножества С++, но по сути является тем-же С++, но в профиль.

в гораздо более правильный профиль чем сам C++, собственно.

[zigmar.livejournal.com]

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

[cmm.livejournal.com]

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

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

о чём Вы пытаетесь спорить?

[trurle.livejournal.com]

Пребывание с другой стороны - это что?
Мне кажется что возможно несколько позиций:
1. Я понимаю инженерные компромиссы, легшие в основу дизайна C/C++, но полагаю что другой набор компромиссов создает инструменты разработки программ, лучше подходящие в некоторых ( вариант - большинстве ) ситуаций.
2. Я не понимаю соображения, легшие в основу дизайна C/C++, потому что я невежественный фанбой Питона ( вариант - Руби и Лиспа )

[cmm.livejournal.com]

первое, естественно.

[trurle.livejournal.com]

Я так и знал!