Обсуждение:C++

Материал из Lurkmore

• УБЕРИТЕ УЕБАНСКИЕ ХЭЛОВОРДЫ, БЛИА!) ++ конечно говно, но "хэловорды" ещё хуже. =) серьезный язык же, не?)

Пример с СОМовым хелловорлдом я бы выпилил - С++-специфичного там мало, это скорее MS-специфичное. C++-ный подобный вариант хелловорлда где-то видел, с темплейтами, smart-pointer'ами и всем прочим.

• Лучше сам найди и замени. У меня сейчас свободного времени не очень много, поэтому и статью сделал наскоро, чисто отвлечься.

Ересь ООП. фейспалм.жпг

MFC - это вообще пиздец. Настолько кривого пакета придумать сложно. Сам кодю на C#, а С++ и особенно MFC (Mother Fucking C) вспоминаю как кошмар. К примеру, последний код из примеров хелловорда - явно заточен под MFC.

Используй ATL/WTL, Люк.

Многие ассоциируют кодирование GUI на C++ с убогим MFC. Есть те же QT, gtk, С++ Builder на конец, etc. Так же многие сравнивают языки программирования(!) по сложности кодирования GUI в той или иной среде, например Delphi vs MFC. Прекращайте это быдлячество.

А реализовать строку - это такой особенный юмор?

Подключай STL-овский std::string. Довольно годная разработка, включение коей в Стандарт очень облегчило жизнь.

Содержание 1 От автора о хелловорлдах 2 Ололо 3 void main 4 Луговский 5 Драма, рекомендую 6 Александреску 7 Недоумение 8 первый хелловорлд 9 Быдло-язык? 10 Ксеноцефал 11 Годная копипаста 12 Очередной быдлобенчмарк или сосание хуёв по-быдлокодерски 13 Самый элементарный vs Вариант 0 14 Линус Торвальдс о плюсах 15 Хороший костыль со статичными переменными-членами класса

[править] От автора о хелловорлдах

Хелловорлды взяты отсюда: [1]. Если Анонимус заменит их на более адекватные, не нарушая общей идеи, то я только ЗА.

В чём поинт наличия четырёх хелловорлдов?

В сложности изобретённых велосипедов, очевидно. А на самом деле, HelloWorld'ы надо писать на w:HQ9+.

w:HQ9+ - FFFFUUUUUUUUUU~ первый интерпретатор Delphi такое УГ, удолил. А всё-таки, почему бы не оставить только первый хелловорлд здесь ?

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

[править] Ололо

Плюсовики возомнили себя пупом вселенной. Учните хаскельца!

• О да. "Умение героически преодолевать трудности, которые создает твой собственный инструмент" - это скорее про хацкель, чем про С++.

[править] void main

Распространено заблуждение что "void main(){}" - коррекное объявление головной функции. На самом деле, оно некорректно. Путаницу вносит то, что:
1. int main() {} - корректно и вернёт 0.
2. main() {} - в Си до С99 корректно и вернёт 0.
Пожалуйста, не пишите void main в хелловорлдах.

Ok, признаю, был не прав. Суть в том, что если объвить int main, а в теле функции не указать return вообще, гарантировано возвращение нуля. Но, поскольку, возвращаемое значение не входит в сигнатуру функции, компилятор не должен различать эту ситуацию. Плюс святая уверенность в обратной совместимости с С. Каюсь.

«Суть в том, что если объвить int main, а в теле функции не указать return вообще, гарантировано возвращение нуля.» ЛОЛЩИТО? behavior is undefined (implementation-specific), бля!

Ещё один. Кури 3.6.1/5

 A return statement in main has the effect of leaving the main function
 (destroying  any  objects with automatic storage duration) and calling
 exit with the return value as the argument.  If  control  reaches  the
 end  of  main  without  encountering a return statement, the effect is
 that of executing
         return 0;

Это не единственное необычное свойство main, об остальных — в других параграфах 3.6.1

>behavior is undefined (implementation-specific), бля!

Кстати, «undefined behavior» и «unspecified behavior» — это две большие разницы. Смотреть 1.4/1.

[править] Луговский

Может лучше создать раздел и скопировать туда больше утверждений с того треда?

[править] Драма, рекомендую

Обсуждение шаблона:Языки программирования

[править] Александреску

Надо добавить срач про «Современное проектирование».

[править] Недоумение

Я не понимаю шаблоны. Совсем не понимаю. Легче понять сложнейшие системы объектов, интерфейсов и прочей хуини. BPW-кун

И поэтому пласофагам похуй на характеристику "быдлокодерский", ня.

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

чуваки, ну в натуре жгете! Ёбанный насос, в самом деле очень круто и интересно! Всего вам всякого кошерного и насосного! Уть-уть!!!

тогда предлагаю вам упороться от невозбранно заимствованного с говнокода struct X{template<class T>X(T);X g(){X(this->*&X::g);}};

[править] первый хелловорлд

В такой маленькой программе ошибку сделали. Вот мудаки. Правильно так:

#include <iostream>
int main()
{
  std::cout << "Hello, World" << std::endl;
}

Сброс stdout через endl совершенно излишен. Достаточно std::cout << "Hello, World\n"

—Мимо проходилНе ври endl может быть разное в разных ОС, в Mac OS, например это '\r'

[править] Быдло-язык?

Лол тому, кто утверждает быдлонутость языка из-за отсутствия сборки мусора. Если в ц++ будут свистоперделки ввиде сборки мусора, потоков (и прочего говна из boost) то это будет уже не ц++. С таким же успехом можно называть быдло-ц.

Может, выпилить ту секцию полностью?

[править] Ксеноцефал

В связи с акцией по зачистке статей от мусора, из данной секции были выпилены примечания, полемизирующие с мнением этого персонажа. В результате, «охуенно ценное IMHO от быдлокодера» выглядит общим мнением. Это неправильно. Предлагаю либо выпилить ксеноцефальные излияния, либо добавить альтернативные мнения, излагавшиеся в примечаниях.

Оформил как цитату. Опровергнуть при большом желании можно непосредственно под.

Поскольку спорить в статьях нам строжайше запретили, выношу моё «охуенно ценное IMHO» на суд уважаемой публики на странице «Обсуждение» ;-) Синтаксис и структура написания программ на C++ действительно имеют достаточно «неудобных моментов», но, если быть честными, неменьше неудобств и «технических нелепостей» присутствует и в Жабе, и в Дельфи, и в любом другом языке общего назначения, который претендует на определённую универсальность. Что касается C++, то большинство кирпичных экскрементов вокруг него порождены простым нежеланием быдлокодеров нормально изучить этот язык. Кроме того, кодеры на других языках часто считают, что знание, например, Джавы или структурного C, автоматом делает их экспертами в Це-плюс-плюсе. Они не хотят понять, что C++ это не «навороченный ANSI C» и не «предыдущая версия Джавы», а другой язык со своей спецификой, своим инструментарием, своим синтаксисом и правилами компиляции и исполнения кода. Другая вестчъ, которую часто упускают из вида обличители Си-плюс-плюса, это тот факт, что задача определяет выбор инструмента, а не наоборот. По этому, как это делает Ксеноцефал, они часто пытаются представить знание C++ как нечто «необязательное» или «ненужное», и пустословят о «сложностях, которые создаёт твой собственный инструмент». Конечно, если ты ваяешь Web-странички с парой таблиц и кнопок, ничего универсальнее Javascript'a тебе не надо и С++, равно как Smalltalk, Fortran или LISP, тут совершенно ни при чём. Из моего личного опыта могу добавить, что, когда возникает необходимость, люди, нормально знающие C++, «пересаживаются» на любой другой язык с минимальными затратами времени — обычно хватает недели (а то и меньше) вдумчивого чтения какого-нибудь вменяемого руководства (типа книжки «Thinking in Java») и выполнения нескольких упражнений, что бы человек стал кодить на вполне достойном уровне, как по скорости написания, так и по качеству выдаваемого кода. А вот как раз адепты Жабоскриптов и ПыХПыхов испытывают жесточайшие сложности и могут гнать классику быдлокода в течении неограниченного времени. Возвращаясь к Ксеноцефалу, в «программистской професси-анальной» среде я неоднократно замечал, что когда человек имеет некую жёсткую формулу для определения программерской квалификации (типа «Знаешь только два языка? — Лох. Знаешь десять? — Суперэксперт.»), сам этот человек — весьма посредственный специалист. Искусство Программирования™, как и любая прикладная наука, состоит из двух разделов: теоретического и практического. К первому относятся базовые знания в теории алгоритмов, теории автоматов, математической лингвистике, реляционной алгебре, структурах данных, моделировании систем и т.д. — словом, всего того, что программеры (по идее) должны были изучить на соответствующем факультете в своём институте. Суммируя эти познания, их можно назвать «алгоритмическим мышлением» — способностью построить нужную модель и грамотно разработать алгоритмическое решение задачи, используя доступные теоретические наработки. Второй раздел, практический, предполагает знание уже конкретных языков программирования, аппаратных и програмных платформ, сред разработки и исполнения, нужного middleware-инструментария и т.п., а главное, умение использовать всё это на уровне, необходимом для правильной реализации нужных моделей и алгоритмов. Так вот, «хороший программист» это не тот, кто «обязан знать C», и не тот, кто «знает десять языков», а тот, кто обладает достаточными знанием и опытом в обоих разделах применительно к конкретной задаче. Имею наглость гарантировать, что можно запросто быть «аццки паршивым программистом», будучи полным гуру в одном отдельно взятом разделе. Если у человека хромает «алгоритмичекое мышление», он никогда не построит грамотное решение задачи, если хромают практические навыки — никогда не сможет это решение грамотно реализовать. А быть очень хорошим программистом вполне можно работая только на Вижуал Бейсике...

«	А быть очень хорошим программистом вполне можно работая только на Вижуал Бейсике...	»
— Анонимус

«	Студентов, ранее изучавших Бейсик, практически невозможно обучить хорошему программированию. Как потенциальные программисты они подверглись необратимой умственной деградации.	»
— Э.В.Дейкстра

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

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

Факты -> лулзы. Статья должна быть правдивой.

В писанине выше дофига хуиты. Писать не буду, ибо придирки. С главным посылом, что программирование - это профессия, и как профессию его и нужно оценивать, согласен. Но: а) цитата представлена как частное мнение, имеющее право быть. б) язык умирает. Кстати, никто не знает на каком языке написано больше кода - на фортране или це++? Также, называть знания computer science "алгоритмическим мышлением", да ещё и говоря при этом об ОО языке - очевидный признак быдлокодера.

Так уж и умирает? Быть может он таки просто занимает свою нишу: высокопроизводительные и сложные приложения. А не пытается быть языком для всего. Алсо, QT.

Не знаю что он там пытается, но факт в том, что это довольно дорогой и трудоёмкий язык (в промышленном смысле), поэтому там, где от него можно отказаться, от него отказываются. И таких ниш всё больше и больше. Сложные приложения - это которые? Если древние проекты, типа адинэс, неро и прочего, то это не ниша, а реликт. Такое с каждым умирающим языком было. Веришь-нет, некоторым приходится до сих пор с фортраном возиться и даже деньги зарабатывают на портировании фортранных прог в современные языки. Поменять язык гораздо сложнее, чем поменять архитектуру. Но даже на линуксе складывается тенденция писать пользовательский софт не на це++, а под моно, вещи вроде зул (правда не знаю на чём зулраннер написан). Под гном так и вообще давно уже для интерфейсов юзают питон (сука, язык скриптовый, а быстрее жабы!), а движок и либы на Це. Под qt в чистом виде сейчас либо сторонние проекты портируют (как опера), но чаще пишут всякую мелкую юзерофильщину. А действительно сложные приложения - это обычно такой конгломерат, что там часто похуй на чём отдельные компоненты написаны.

Хорошо-хорошо. Давайте называть знания «компьютер саенс» знаниями «компьютер саенс». Вы что хотели сказать-то? Знания «компьютер саенс» к объектно-ориентированным языкам никакого отношения не имеют? Или вы о чём? Никакой «рекламы» C++ в моем комментарии не содержится. Содержится оспаривание мнения Ксеноцефала. Я неправ? Объясните почему. И никаких придирок :) Да, и расскажите пожалуйста, в какой-такой профессиональной среде «некоторые возятся с Фортраном, портируя проги на другие языки»? И зачем конкретно? Математику теперь проще писать на Питоне, а не на специализированном для этого Фортране? Короче — типичный быдлокодерский понос: сказано немало, но ничего по существу, зато нам объяснили что всё надо писать «под моно и зул», а «в сложных приложениях похуй на чём написаны компоненты».

Ты сейчас похож на дефектного, которому причудилось в собеседнике собственное отражение, и который поэтому готов разразиться ненавистью. Те же необоснованные проекции, провоцирование флейма и обвинения, которые как минимум в той же степени можно применить и к тебе. Попробую по порядку, конструктивно: Знания computer science отношение к ООП имеют, "алгоритмическое мышление" в буквальном понимании этой фразы - нет. Только косвенное. Если ты хочешь весь computer science свести к "алгоритмическому мышлению" - тебе в зарю эпохи ЭВМ. Про рекламу це++ не понял зачем ты сказал, я про неё ничего не говорил. Насчёт оспаривания мнения - флаг в руки, но ты прав не более, чем Луговский. Про фортран: друг знакомого этим занимается, сам с ним не встречался. Цели сугубо специальные, как это часто бывает в программистской индустрии, и зависят от конкретного куска кода. + однокурснику бывшему для дипломной пришлось с фортраном связаться. Математику сейчас проще писать не на фортране или питоне, а в маткадах, если не встают технические ограничения. И нигде я тебя не учил как и что надо писать. Я такими глупостями не занимаюсь. Это твои проекции.

Хорошо, «алгоритмическое мышление» — неудачный термин, с его помощью я хотел обобщить требуемые теоретические знания, о чём недвусмысленно написал («Суммируя эти познания...»), не так ли? Термин неудачен, согласен, но ведь я развёрнуто объяснил, что имею в виду. И ежели я теперь так похож на «дефектного», то только потому, что ты, несмотря на понимание смысла моей писанины, решил повыёживаться и записать меня в быдлокодеры :) Не твои ли это проекции? :) Про Фортран: мой близкий друг, физик, очень много работает на Фортране (как, по его рассказам, и все его коллеги — тысячи их), на Фортране, а не в маткадах, потому что задачи объёмные, обсчитываются на больших машинах, а Фортран предоставляет и хорошее быстродействие и нужные возможности параллелизации их алгоритмов. И переписывать это на что либо другое никто не собирается — это просто ненужно. Да, про «рекламу C++» я сказал, потому что вторым твоим пунктом, после замечания о том, что Ксеноцефал имеет право на мнение, было «язык умирает». Я так же на эту тему ничего не говорил.

У меня несколько трепетное отношение к буквальному смыслу идентификаторов. Это профессиональное, как ты должен понимать. "Язык умирает" - это в защиту мнения ксеноцефала. Хотя я и не утверждаю, что он прав. Такие вот ВП.

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

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

Тот же Фортран, тащемта, нихуя не умиарет, ибо в своей отрасли он замечательно работает. Аналогично с Прологом. Так что заявление о смерти С++ - ересь. Дальше. Называть С++ ОО-языком и есть быдлокодерство, потому что язык, сука, мультипарадгменный. Лисп, между прочим, ООП тоже поддерживает, если кто не в курсе. — S a 21:25, 8 ноября 2009 (MSK)

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

> Называть С++ ОО-языком и есть быдлокодерство, потому что язык, сука, мультипарадгменный.

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

Навскидку внутренности Андроида на Сях и С++. Алсо, "похуй на чём отдельные компоненты написаны" - это признак того, что архитектура в Жопе, ибо связывать несколько языков - тот еще гемморой, на который идут ради того, чтобы разделить по полочкам задачи. Т.е. см. того же Андроида: ядро на сях, API и обвязка на цпп, юзерспейс на жабе. Систем быстра аки скаковая лошадь, а всякие свистелки и перделки ненапряжно пишутся на жабе, которую изучить объективно проще чем цпп - разделение труда и сказка.

Никто и не говорит про связывание (ты линкинг и биндинг имел ввиду ведь?) нескольких языков. IPC же

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

Есть, но это коммерческая тайна :) Внутренний проект. А вообще, на линуксе полно софтин, сделанных по схеме клиент-сервер (и не только) с помощью IPC. Даже муз проигрыватель такой есть :) Хотя не помню, какие конктретно механизмы там используются. Может те же сокеты и пайпы. А почему это важно?

Так и shared memory можно изпользовать в программах на разных языках.

Клиент-серверную хрень я и сам пишу, но там кроме сокетов, пайпов и fork-exec юзается чуть менее чем ничего ;). И да, как минимум Перловка, Пхп, Питон, Цпп и Ц в этом проекте есть, но все работает как распределенная система по сокетам, а сокетам до лампочки от чего к чему байты гонять. А вот чегонибудь монолитного я не припомню, так чтобы активно несколько языков, вот в чем соль.
И плееры тоже - сокеты. Причем максимум два языка - клиент и сервер.

>Другая вестчъ, которую часто упускают из вида обличители Си-плюс-плюса, это тот факт, что задача определяет выбор инструмента, а не наоборот.
напомню позицию ксеноцефала. задача диктует инструмент; не существует такой задачи, для решения которой c++ был бы хорошим инструментом.

Плюсану, например. Кстати, интересное сложилось на Лурке, а именно засилье ФЛП-фагов. Вот только мне кажется, что все это лисп- и хаскельфажетсво из того же разряда, что и ненависть к маздаю у людей, которые на деле в жизни не сидели за другой ОС. ФЯП - это ж типа модно, это ж типа круто выебнуться, рассказать про то, какой Хаскель крутой и обосрать C/C++/C#/Java. Но в реале большая часть этих холиворщиков оказывается унылыми цпп-быдлокодерами :) (живого хаскельщика вообще никогда не видел). Не говоря уж о том, что стремление применять ФЛП во всех отраслях программирования является весьма удивительным. Для каждой задачи свои инструменты, ня?

Ня. О живых Хаскельщиках ходят легенды. Якобы они где-то водятся...

[править] Годная копипаста

When you see the code

    i = j * 5;

… in C you know, at least, that j is being multiplied by five and the results stored in i.

But if you see that same snippet of code in C++, you don’t know anything. Nothing. The only way to know what’s really happening in C++ is to find out what types i and j are, something which might be declared somewhere altogether else. That’s because j might be of a type that has operator* overloaded and it does something terribly witty when you try to multiply it. And i might be of a type that has operator= overloaded, and the types might not be compatible so an automatic type coercion function might end up being called. And the only way to find out is not only to check the type of the variables, but to find the code that implements that type, and God help you if there’s inheritance somewhere, because now you have to traipse all the way up the class hierarchy all by yourself trying to find where that code really is, and if there’s polymorphism somewhere, you’re really in trouble because it’s not enough to know what type i and j are declared, you have to know what type they are right now, which might involve inspecting an arbitrary amount of code and you can never really be sure if you’ve looked everywhere thanks to the halting problem (phew!).

Источник: http://www.joelonsoftware.com/articles/Wrong.html

Ну Джоэл Спольски в своём духе. Хотя реально тема непредсказуемости смысла операторов в статье не раскрыта (разве что в примере analog literals)

Речь не о пидаре и его статье. Сама копипаста вне контекста доставляет. А статья спорная, да. Точнее, если выжать оттуда воду, то останется 2-3 тезиса, которые можно легко опрокинуть или, по крайней мере, поставить под сомнение из значимость. Ну да опять же, не о том речь, а то щас разболтаюсь...

ололо #define i return; j

Ну да, но так никто не делает. Точнее так можно сделать только из сознательной злонамеренности. Хотя именами i и j сложные объекты тоже никто не называет.

И в цпп стараются сохранять семантику операторов. Принцип наименьшего удивления называется.

#define i *((rand()%7&1)?&i:&j)

Пидор такой пидор. Если вы видите i.assign(j.multiply(5)); вы знаете еще меньше -- модифицирует ли multiply j или нет, а из названия multiply это никак не вытекает. Да и ООП лучше не использовать совсем: чтобы узнать что делает SomeClass.Foo() нужно слазить в ее определение, а оттуда в другие классы, которые она вызывает. Даже в ассемблере символические ссылки лучше не использовать: если вы видите mov [z],1 то вы не знаете, где лежит z и какой у нее размер.

[править] Очередной быдлобенчмарк или сосание хуёв по-быдлокодерски

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

Итак, начнём с формальностей:

По ссылке приводится исходный код программ, но не указывается вообще ничего о среде компиляции/исполнения и машине, на которой проводился тест. В таких тестах запросто могут иметь значение версии компиляторов, библиотек и ОС, а так же характеристики машины. Я запустил программу на С++ на старом Acer Aspire 5600 с 2ГБ памяти под ХРюшей и через несколько секунд активно заработал свап (Венда в своём стиле) - а это значит, что тест уже не особо чистый. О подобных деталях, некоторые из которых могут значительно влиять на результаты бенчмарка, аффтарь статьи не обмолвился ни словом, зато пускается в пространные рассуждения про OutofMemoryException на 1.4ГБ и прочую поебень.

Далее, вот вывод, который делает аффтор:

«Получается, что выделение/освобождение памяти GarbageCollector'ом (который двигает объекты в памяти, ведет себя непредсказуемо, да и вообще «дико тормозной») происходит почти в полтора раза быстрее, чем в native-коде!!! Мда-а-а, недаром говорят «доверяй, но проверяй -)))) Ну и кстати аналогичные результаты получаются, если изменять размер объектов, их число и количество итераций…»

У меня вопрос. Почему аццкий сотона аффтар, так убеждён, что в его тесте сравнивается именно время «выделения/освобождения памяти GarbageCollector'ом»? Делал ли он профайлинг программ? Не буду тянуть, вот чью скорость меряет этот супер-мега бенчмарк (в программе на C++):

memset(data, 0, 1024 * 1024);

С этой инициализацией, на упомянутом старом лэптопе, прога выдает 76.8 секунд в среднем, а без неё... 1.04 секунды. Т.е. порядка 98.7% всего времени исполнения программы, тратится на инициализацию каждого создаваемого объекта, а вовсе не на администрацию памяти. Почему memset «от Ц-плюс-плюс» работает медленнее аналога «от Ц-шарп» - хуй проссышь, может функция Ц-шарп как-то круче, а может Ц-шарп вовсе не инициализирует весь массив сразу при создании объекта, а делает это по мере запросов на доступ к этому массиву, но в любом случае к администрации памяти (GC vs. new/delete) этот тест не имеет вообще никакого отношения, и выводы сделанные башковитым аффтаром - ложь, пиздежь и провокация, а также классика быдлокодерства.

[править] Самый элементарный vs Вариант 0

Да вы упоролись. «Самый элементарный» и будет «Вариант 0». А «cstdio, элементарный, C++» это какой-то пиздец.

[править] Линус Торвальдс о плюсах

может стоит запилить в статью? http://article.gmane.org/gmane.comp.version-control.git/57918

Не стоит. Очередное нытьё от профессионального обличителя и ненавистника плюсов. В статье и так до хрена ненависти и говна.

[править] Хороший костыль со статичными переменными-членами класса

http://weblogs.asp.net/whaggard/archive/2004/11/05/252685.aspx

Вообще стоит добавить раздел с костылями, доставшимися в наследство или вызванными этим наследством от Си.