"I am joined on stage tonight by many distinguished, high-profile computer programming languages. Each is highly regarded by its devotees, and I for one look forward to hearing what each has to say."
The Last Language War / Language Trolling Post You'll Ever Need To Read (Hopefully) - прикольный диалог языков программирования.
Спасибо Maniac'у за ссылку.
That IACR preprint
4 часа назад
Atom feed
15 коммент.:
"Developers, developers, developers, developers..." :-)
O С++ ни слова...
А вот и перевод:
http://zverok-kha.livejournal.com/2244.html
O С++ ни слова...
О С++? Пожалуйста :)
Да чтож вы к бедному С++ пристали...
> O С++ ни слова...
>> О С++? Пожалуйста :)
Думал, что-нибудь интересное найду, а там... C++ устами чайника.
adept пишет:
Думал, что-нибудь интересное найду, а там... C++ устами чайника.
То есть проблем нет, автор бредит и, конечно, язык прост, быстро компилируется, при добавлении очередного поля в класс не надо пересобирать все зависимые модули, и всё работает по принципу наименьшей неожиданности? :)
P.S. Хотел бы я, чтобы чайники знали про подобные вещи... Глядишь бы, и работать стало проще.
То есть проблем нет
Проблемы есть. Только автор не в состоянии адекватно их проанализировать. Я читал не всё, а только про references, constructors, destructors и exceptions. У него элементарно не хватает знаний языка и общеизвестных парадигм программирования на нём. Это просматривается по всем четырём статьям.
автор бредит
Бредит, и очень много.
язык прост, быстро компилируется, при добавлении очередного поля в класс не надо пересобирать все зависимые модули, и всё работает по принципу наименьшей неожиданности?
Для меня такие проблемы не являются открытием :-) Думаю, о них знает любой человек, имеющий мало-мальский опыт программирования на C++. В чём прелесть читать то, о чём уже и так всем давным-давно известно?
Для меня такие проблемы не являются открытием :-) Думаю, о них знает любой человек, имеющий мало-мальский опыт программирования на C++.
Ну, с большей частью вещей, описанных в FQA и FAQ, столкнутся далеко не все программисты. Автору же не нравится разрыв между теорией и реализацией языка.
Бредит, и очень много.
Можно любой броский пример? :)
В чём прелесть читать то, о чём уже и так всем давным-давно известно?
Просто небольшой список неприятных мелочей, который каждый программист на С++ всегда должен держать в уме. И в идеале знать о тех языках, в которых этих мелочей нет.
Конечно, если вы читали оригинальный FAQ, книжки, скажем, товарища Meyers или сталкивались с подобным на практике, то ничего нового тут нет (что вообще нового сказать за 27 лет существования языка? :)
Автору же не нравится разрыв между теорией и реализацией языка.
Возможно, местами разрыв действительно есть, но автор склонен к сильному преувеличению.
> Бредит, и очень много.
Можно любой броский пример? :)
Ну хотя бы взять его доводы не использовать нетривиальные конструкторы и деструкторы. Это вообще шедевр :-)
что вообще нового сказать за 27 лет существования языка?
На самом деле кое-что сказать всё-таки можно - по поводу обработки исключений в деструкторах. Исключения в деструкторах бросать можно и нужно (так же, как и в конструкторах), только способ их обработки должен быть выбран несколько специфический, и почему-то Мейерс до него не додумался.
Идею такой обработки можно найти по твоей же ссылке. Помимо обезьяны, которая всюду подписывается FQA, там есть ещё один автор - вот у него эта идея промелькнула, только применить её к деструктору он не догадался.
Не нужно забывать, что в C++ одновременное существование двух и более необработанных исключений возможно и само по себе не приводит к проблемам. Проблема возникнет лишь тогда, когда исключению позволят выйти за пределы деструктора, в котором оно возникло, чего допускать, естественно, не следует.
Исключения в деструкторах бросать можно и нужно [...]
Совсем уйду в оффтопик... Нет ли где информации о "стоимости" исключений в C++? Вроде бы в comp.lang.c++ был длиннющий тред по этому вопросу, но всё опять свелось к "может привести к заметному замедлению, а может и нет, в зависимости от конкретного приложения".
Ну хотя бы взять его доводы не использовать нетривиальные конструкторы и деструкторы. Это вообще шедевр :-)
Что-то я не нашёл там таких доводов... Можно конкретную ссылку?
На самом деле кое-что сказать всё-таки можно - по поводу обработки исключений в деструкторах.
...
Проблема возникнет лишь тогда, когда исключению позволят выйти за пределы деструктора, в котором оно возникло, чего допускать, естественно, не следует.
Опять же, ссылочку пожалста...
Оч интересно, где ты у Мейрса, Саттера или Александреску встречал призыв вообще не использовать исключения в деструкторах(про конструкторы я вообще молчу)?
Вот то что выпускать их оттуда нельзя - это да, у них встречается.
Что-то я не нашёл там таких доводов... Можно конкретную ссылку?
Похоже, ты подумал, что adept комментирует Мейрса, хотя на самом деле он говорит про приведённый мной fqa. Вот ссылка.
Нет, в первом вопросе я просил ссылку именно на FQA(ибо речь была о нём).
>>> Бредит, и очень много.
>> Можно любой броский пример? :)
> Ну хотя бы взять его доводы не
> использовать нетривиальные
> конструкторы и деструкторы.
> Это вообще шедевр :-)
Вот ссылка.
Итак, цитирую:
[11.13] Should my destructor throw an exception when it detects a problem?
FQA: It shouldn't. And you can't return an error code either. However, on many systems you can send an e-mail with the word "BUMMER" to your support e-mail address.
If you want your destructor to detect problems, make it a close function.
Где призыв не использовать нетривиальные конструкторы деструкторы? 0_о
2Adept:
В чём прелесть читать то, о чём уже и так всем давным-давно известно?
Очень часто оказывается, что эти "все" - это очень небольшая группа людей из ближайшего окружения :-).
Полно студентов, которые вообще ни сном, ни духом о недостатках С++.
Я посмотрела FQA наискосок - на глубокий аналитический материал оно не тянет, но вообще забавно.
Отправить комментарий