• Там же всякие глупости написаны, даже странно. Можно ругать C++ куда более изысканно
  • Хрень какая-то
  • @tilarids, Есть много моментов на грани бреда (например про то что if (ret < 0) более читаемо чем throw/catch), однако это не делает статью менее интересной. Я лично там нападок на C++ не вижу :)
  • I've decided to use C++ minus exceptions

    ну так ёптыть. Дальше можно не читать. Собственно, весь кусок до этого фееричен.
  • @max630, Советую прочитать до конца. На протяжение всей статьи дядька рассказывает как он делал из C++ сишку. Я ровно то же самое видел в очень многих компаниях (баним все, оставляем C с классами). Очень поучительная статья, кстати
  • @max630, То есть поучительная в том плане, что если в голову закрадывается мысль: "мне нужен просто C с классами, возьму-ка я C++", то нужно брать C и не выебываться. Во всех остальных случаях можно брать C++ :)
  • @dk, ну прочитал. Я извиняюсь, это типичный "Torvalds-ish rant against C++ from the point of view of die-hard C programmer". rigogous error handling у него. Я видел этот rigorous handling. Вкратце, он заключается в том что 80% ошибок игнорируется, вместо данных подставляется мусор.

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

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

    Из замеченного рационального: то, что обнаружение и обработка исключительных ситуаций не так тесно связаны, как это было в C, действительно может дать лазейку багу (забыли обработать исключение, к примеру). Сила исключений (imho) как раз в том, что они позволяют разделить обнаружение и обработку, но было бы неплохо иметь механизм для того, чтобы явно обозначить связь выбросившего и обрабатывающего кода. С другой стороны, показать такую связь можно с помощью exceptions specifications. При грамотном определении иерархии классов исключений особенных проблем, кажется, быть не должно.

    Остальное (если я ничего не пропустил) можно классифицировать как «я хочу от C++ странного». Весьма показательно в плане того, чего не стоит хотеть от C++. Читал, имея ввиду такой контекст, с удовольствием.
  • Прочитал вторую часть заметки.

    Нападки на std::list заставили немного призадуматься. В принципе, если при работе с определённым контейнером критично количество обращений к ядру за новыми кусками памяти, то можно переписать аллокатор. Сам этим никогда не занимался, но по идее должно помочь. Удаление элемента за константное время можно сделать и при той структуре данных, что приводится для std::list, добавив в реализацию списка хеш-таблицу с указателем на person в качестве ключа и указателем на звено (helper в терминах статьи) в качестве значения. В итоге мы и указатели на звенья не отдаём за пределы своей реализации контейнера (не нарушаем инкапсуляцию) и можем найти звено по указателю на person за время, примерно равное времени поиска по хеш-таблице. Выглядит сложно по сравнению с обычным двунаправленным списком, но тут можно оправдать себя тем, что от списка захотели не очень присущее ему свойство.