-
Как-то мимо меня проходила эта заметка создателя zeromq: "Why should I have written ZeroMQ in C, not 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++. Читал, имея ввиду такой контекст, с удовольствием./8 · Reply -
Прочитал вторую часть заметки.
Нападки на std::list заставили немного призадуматься. В принципе, если при работе с определённым контейнером критично количество обращений к ядру за новыми кусками памяти, то можно переписать аллокатор. Сам этим никогда не занимался, но по идее должно помочь. Удаление элемента за константное время можно сделать и при той структуре данных, что приводится для std::list, добавив в реализацию списка хеш-таблицу с указателем на person в качестве ключа и указателем на звено (helper в терминах статьи) в качестве значения. В итоге мы и указатели на звенья не отдаём за пределы своей реализации контейнера (не нарушаем инкапсуляцию) и можем найти звено по указателю на person за время, примерно равное времени поиска по хеш-таблице. Выглядит сложно по сравнению с обычным двунаправленным списком, но тут можно оправдать себя тем, что от списка захотели не очень присущее ему свойство./9 · Reply