Что-нибудь полезное там есть, или так, слюни и слезы? После беглого просмотра, мне кажется, что там полный бред. Возьмем например вот это:
[17.3] How can I handle a destructor that fails? FAQ [real C++FAQ]: Actually you can't — not beyond logging the problem to a file or the like. In particular, do not throw an exception. The problem is that destructors are called when exceptions are thrown so that functions propagating errors to their callers can clean up resources. Your destructor can also be called in such a situation. And when an exception is already thrown, throwing another one will result in a call to terminate(), killing your process. Because you see, what else could C++ do? There's an ambiguity: which exception out of the two do you want caught now?
Strictly speaking, you can make that "do not throw exceptions in a destructor unless you are sure that it won't be called as a result of an exception already thrown", but you can rarely be sure of that.
FQA: That's right, terminate(). Solomon-style conflict resolution carried to the end. See? Exceptions are not a graceful way to handle errors.
And "don't throw exceptions in destructors" actually means "don't call functions in destructors unless you are sure they don't throw an exception". The C++ compiler won't check for you, because it can't: the language doesn't force a function to declare whether it throws exceptions.
This is one good reason to avoid destructors doing more than nothing: like constructors and operators, they can't handle errors.
Все то, что написано после FQA никакого смысла не имеет. Это просто поток больного сознания.
Здравствуйте, alexeiz, Вы писали:
A>Здравствуйте, Кодт, Вы писали:
К>>В блоге Тру Программиста ссылка на C++ Frequently Questioned Answers. К>>Дисклаймер — у Тру Программиста.
A>Что-нибудь полезное там есть, или так, слюни и слезы?
Пользы было бы больше, если бы автор более аккуратно формулировал свои мысли, избегая затрагивать места, которые знает неточно. В текущем же состоянии, приходится читать по принципу: "Тут читать, тут не читать, а тут рыбу заворачивали".
A>После беглого просмотра, мне кажется, что там полный бред.
Там много ошибок в плане технической точности и интерпретации причин или последствий тех или иных проблем. Что там не бред, так это многие из упоминаемых больных мест. Например:
"Outstandingly" should be interpreted literally, because all popular languages have context-free (or "nearly" context-free) grammars, while C++ has undecidable grammar. If you like compilers and parsers, you probably know what this means. If you're not into this kind of thing, there's a simple example showing the problem with parsing C++: is AA BB(CC); an object definition or a function declaration? It turns out that the answer depends heavily on the code before the statement — the "context". This shows (on an intuitive level) that the C++ grammar is quite context-sensitive.
Это действительная проблема C++.
In practice, this means three things. First, C++ compiles slowly (the complexity takes time to deal with).
Тут автор сильно неточен. Разница, безусловно, есть, но ее значение и значимость существенно преувеличены. Например, cl.exe (VC++) построчно быстрее компилирует, чем csc.exe (компилятор C#). Главная причина медленности компиляции C++ (и многих других "болячек" языка) -- legacy модель компиляции, отсутствие нормальных модулей.
Second, when it doesn't compile, the error messages are frequently incomprehensible (the smallest error which a human reader wouldn't notice completely confuses the compiler). And three, parsing C++ right is very hard, so different compilers will interpret it differently, and tools like debuggers and IDEs periodically get awfully confused.
А это, действительно, одна из главных негативных составляющих сложной грамматики: стоимость создания инструментов.
Легче одурачить людей, чем убедить их в том, что они одурачены. — Марк Твен
Здравствуйте, Павел Кузнецов, Вы писали:
ПК>Там много ошибок в плане технической точности и интерпретации причин или последствий тех или иных проблем. Что там не бред, так это многие из упоминаемых больных мест.
Но мне интересно, какова была цель создания этого достаточно большого документа? Исправить ощибки C++FAQ? Навряд ли. Технической информации в FQA почти нет (я бы сказал, что вообще нет, но я не стану читать его полностью — а вдруг есть?). Скорее это попытка автора выразить свою нелюбовь к C++, используя эмоциональные доводы, а не логические. А C++FAQ здесь предоставляет возможность за что-то зацепиться, без которого мысль автора выразилась бы очень и очень кратко: "I hate this @$%@$ing C++! The end."
Здравствуйте, Кодт, Вы писали:
К>...
а что поделать, за универсальность надо платить. Знаете лучшее решение без memory/performance overhead'а, но с такими же возможностями — вперед, предлагайте!
Вот и Торвальдс тоже высказывался в похожем духе.
И самое интересное, что все это почти правда, хотя приступа восторга не вызвает — что до меня С++ был и остается по сути моим единственным кормильцем-поильцем.
А эти критики, вообще говоря, неадекватны: они говорят о недостатках, но напрочь забывают о достоинствах. Да и некоторые недостатки вызваны тем, чтобы малой кровью избежать больших проблем (обеспечить обратную совместимость с С, эффективно выполнять код и т.д. и т.п. можно написать целую кучу, а мне работать еще надо )
Здравствуйте, alexeiz, Вы писали:
A>Технической информации в FQA почти нет (я бы сказал, что вообще нет, но я не стану читать его полностью — а вдруг есть?).
Есть немножко.
Вообще, видно, что автор долго работал с C++. Но, похоже, он так и не осилил PImpl.
У него два основных аргумента: перекомпиляция на каждый чих и отсутствие GC, RTTI для всех объектов, рефлексии и т. п. — следствия борьбы за производительность.
Забавен стиль написания. Так пишут различные околонаучные доклады, когда нужно убедить в чём-нибудь малознакомую с мат. частью публику. Например, автор начинает доказательство с известнейших истин, после этого описание следующих "истин" снабжает ссылками на предыдущие и т.д. В итоге без особых проблем в 3 шага получаем, что в С++ — не ООП ЯП . Также, получаем, что нам очень нужен reflection, хотя вопрос весьма спорный. В общем, стандартный подход:
0. Неоспоримое вступление, обоснование актуальности пространства применения
1. Выбираем критерии, по которым существующие технологии проигрывают
2. Предлагаем свой вариант, который по данным критериям лучше
3. Читатели/слушатели доклада апплодируют
P.S. Я не утверждаю, что С++ не имеет тех недостатков, которые описаны в документе. Но утверждаю, что значимость их весьма завышена.
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, tilarids, Вы писали:
T>>Также, получаем, что нам очень нужен reflection, хотя вопрос весьма спорный.
RO>Естественно, рефлексия нужна. Она ведь бесплатна, не то, что GC.
RO>Другое дело, что сериализация, основанная на рефлексии, — потенциальный источник багов.
Я не против, чтобы она была в качестве средства. Но использовать ее нужно весьма аккуратно. Причем по такому алгоритму:
1. Не используй reflection
2. Если очень нужен, то см п.1.
3. Ну, сам напросился :)
И хоть прямые руки помогают всегда, но лучше проповедовать Александреску и использовать только то, что даже кривыми руками плохо не используешь
Здравствуйте, Roman Odaisky, Вы писали:
RO>Здравствуйте, alexeiz, Вы писали:
A>>Технической информации в FQA почти нет (я бы сказал, что вообще нет, но я не стану читать его полностью — а вдруг есть?).
RO>Есть немножко.
RO>Вообще, видно, что автор долго работал с C++. Но, похоже, он так и не осилил PImpl.
А что хорошего в Pimpl'e? Вместо одного класса приходится писать два. Тут с++ хвалиться нечем.
RO>У него два основных аргумента: перекомпиляция на каждый чих и отсутствие GC, RTTI для всех объектов, рефлексии и т. п. — следствия борьбы за производительность.
Ну это уже не два аргумента =). Кроме того там еще есть: неоправданная сложность простейших вещей, куча темных мест, и при всем при этом производительность — как повезет, отсутствие нормальных строк и много еще чего.
Здравствуйте, Константин Б., Вы писали:
КБ>А что хорошего в Pimpl'e? Вместо одного класса приходится писать два. Тут с++ хвалиться нечем.
По крайней мере, это решает проблему. Хотя и не совсем (порядок слов по вкусу) элегантно.
RO>>У него два основных аргумента: перекомпиляция на каждый чих и отсутствие GC, RTTI для всех объектов, рефлексии и т. п. — следствия борьбы за производительность. КБ>Ну это уже не два аргумента =).
Один — перекомпиляция и другой — отсутствие попсовых фич (все они, кроме рефлексии, имеют неотъемлемый оверхед).
КБ>Кроме того там еще есть: неоправданная сложность простейших вещей, куча темных мест, и при всем при этом производительность — как повезет, отсутствие нормальных строк и много еще чего.
Перекуём баги на фичи!
)
