Интервью с Бьярном Страустрапом

> Дело не в авторитетах, а в аргументированном изложении точки зрения. По приведенной выше ссылке, если конечно осилить такое количество страниц, достаточно убедительно расписано то, почему "C++ не нужен". Вы сможете столь же хорошо доказать обратное?

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

> Exception проверяются на этапе компиляции компилятором и гарантируется вызов чётко определённого обработчика исключения на любом уровне вложенности.

Могу показать функцию, которая просает checked exception, но не объявляет его. Компилятор скушает и не подавится.

> Error гарантирует крах приложения.

Бред, он ловится так же как любое другое исключение.

Реально в JVM нет никаких checked exceptions, error-ов и прочего бреда. Есть просто исключения, практически такие же, как и в С++.

>Не проще ли было выбрать что-то другое

Время было такое. Да и образование у меня не ИТшное, что сначала понравилось, на том и писал.

>типа QT

Позже и на этом писал, не сказал бы, что гораздо удобнее.

> ...По приведенной выше ссылке, если конечно осилить такое количество страниц, достаточно убедительно расписано то, почему "C++ не нужен". Вы сможете столь же хорошо доказать обратное?

По ссылке увидел много про бабки как аргумент спора, подумал что всё понял и дальше не читал. Я не прав?

C++0x нужен мне так как я буду применять механизмы что там закладываются. Для меня он удобен для выражения того что я хочу сделать наиболее лаконичными средствами. Мне не нравится, когда я для одного и того же алгоритма в других языках я вынужден писать кода в два раза больше чем на C++. Практически всё что я делаю я могу повторно использовать в своих проектах, так как все получается компактное и адекватное поставленной задаче. И что самое главное я отдаю себе отчёт во что переводит компилятор мой текст. Я ничем не плачу за ту высокую степень абстракции что мне предоставляет C++ STL, она на этапе компиляции утрамбовывается в машкод. И все мудрёные vtables, this как и switch и прочая мутота вырождается в call по массиву адресов - всё.

Если ко мне придёт уважаемый дядя и скажет что С++ не нужен, я скажу дяде что это он(дядя) не нужен. А вот пусть возьмёт какой-нибудь opal/h323/ekiga и напишет хотя бы базовый вызов на своём могучем таким образом, чтобы не человек рутину писал, а компилер догадывался и машкод выдал как раньше C++ - вот тогда посмотрим. Но для возникновения такого языка причин меньше чем для совершенствования уже имеющегося - читай Мода vs Разум. Для возникновения такого языка формальный возраст разработки не может быть меньше 5 лет + параллельно компилятор 10. Ждём.

>Вы же сами всё знаете. Зачем стебаться?

Ваша самоуверенность провоцирует.

> RuntimeException не проверяются на этапе компиляции — за восстановление после сбоя (вызов правильного обработчика исключения) программист отвечает сам, как в C#.

Безопасность исключений и гарантии, которые рассматриваются в C++, относятся к несколько иным аспектам: как написать код так, чтобы его прерывание любым исключением оставило текущий объект, как минимум, в корректном и согласованном состоянии. Обеспечение подобных вещей в Java выливается в обилие finally, в которых часто можно увидеть массу дополнительных try-catch-finally.

И наличие RuntimeException в Java, имхо, является серьезным камешком в огороде защитников checked exception.

>Могу показать функцию, которая просает checked exception, но не объявляет его. Компилятор скушает и не подавится.

Покажи. Посмотрю.

>>Error гарантирует крах приложения.
>он ловится так же как любое другое исключение.

А смысл?

> Это очень и очень поверхносный взгляд на безопасность исключений. В языках с GC объекты могут содержать некоррекные данные в своих атрибутах, оставлять наполовину заполенные контейнеры, оставлять открытыми файлы, незакоммиченные транзакции и т.д.

Файлы и незаконченные транзакции да, нехорошо, поэтому их всегда в finally закрывают, не делать этого считается ненормальным.

> В секциях finally в Java так же кидать исключения не сильно полезно.

Почему? Старый exception потеряется, да. Но terminate() не вызовется, по крайней мере.

>С, Python и LISP - наше всё. Остальное от лукавого.

Это ВАШЕ все. На наше все - это Macro-11 и VB.

public class Main {
	public static void main(String[] args) {
		functionThrowingUndeclaredCheckedException();
		System.out.println("We never reach this");
	}
	
	private static void functionThrowingUndeclaredCheckedException() {
		try {
			MyCheckedExceptionThrower.class.newInstance();
		} catch (InstantiationException e) {
			e.printStackTrace();
		} catch (IllegalAccessException e) {
			e.printStackTrace();
		}
	}
}

class MyCheckedException extends Exception {
}

class MyCheckedExceptionThrower {
	public MyCheckedExceptionThrower() throws MyCheckedException {
		throw new MyCheckedException();
	}
}

Стектрейс:
Exception in thread "main" test.MyCheckedException
	at test.MyCheckedExceptionThrower.<init>(Main.java:30)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
	at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
	at sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)
	at java.lang.reflect.Constructor.newInstance(Unknown Source)
	at java.lang.Class.newInstance0(Unknown Source)
	at java.lang.Class.newInstance(Unknown Source)
	at test.Main.functionThrowingUndeclaredCheckedException(Main.java:15)
	at test.Main.main(Main.java:9)


>>>Error гарантирует крах приложения.
>>он ловится так же как любое другое исключение.
>А смысл?

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

> Интересно, а чем же здесь поможет процедурное программирование? В лучшем случае, вместо 200 Мб исходников получишь 180 Мб.

Ну допустим если на Haskell, то будет порядка 70 Мб, а если использовать всякие хитрые штучки-мозгодрючки типа Fudgets, то получится и того меньше.

>> В секциях finally в Java так же кидать исключения не сильно полезно.

>Почему? Старый exception потеряется, да. Но terminate() не вызовется, по крайней мере.

Старый exception теряется и это не есть хорошо, в принципе.

Но хуже, когда люди в finally пишут:

finally { try { a(); b(); c(); } catch ... }

Где и a() и b(), и c() могут кидать свои исключения. Тогда, если a() выбрасывает исключение, то b() и c() не выполняются. Т.е. нужно каждый вызов оборачивать в свой блок try-catch. Но что делать с такими исключениями -- выбрасывать все равно приходится.

> В плюсах я сам себе бог. Я разработчик платформы. В яве и подобных ей вы только пользователи.

+1

однако в плюсах по-моему не хватает средств, чтобы этой платформой пользовалиь обезьянки, пришедшие с явы.

>Безопасность исключений и гарантии, которые рассматриваются в C++, относятся к несколько иным аспектам: как написать код так, чтобы его прерывание любым исключением оставило текущий объект, как минимум, в корректном и согласованном состоянии.

Это решается в C++ использованием готовых библиотек,
так же это решается и в Java: грамотным кодированием.

(Давайте ещё поговорим о мультитрединге и потокобезопасном кодировании. :D )

>Обеспечение подобных вещей в Java выливается в обилие finally, в которых часто можно увидеть массу дополнительных try-catch-finally.

Всё зависит от конкретных задач и конкретной цели, которые ставит перед программой программист.

>И наличие RuntimeException в Java, имхо, является серьезным камешком в огороде защитников checked exception.

Это АСПЕКТ использования языка. Но программисты C# вообще лишены другого аспекта — Checked Exceptions. Так что C#, несомненно, семантически беднее.

пожалуй, единственного чего не хватает C++ (из моего опыта), это динамизма как в JS. Ну хотя бы в применении к структурам. Хотя бы.

> Старый exception теряется и это не есть хорошо, в принципе.

exception в finally скорее всего вызван первоначальным exception-ом (например при работе с базой потерялась связь, пробуем откатиться и, естественно, тот же exception опять вылетит). От этого никуда, по сути не уйдёшь, лучшее, что можно сделать, выругаться в логах.

Вообще, мне нравится подход D с scope (...) ..., позволяет делать то же самое, но без увеличения вложенности кода, по-моему читается значительно проще.

>>Безопасность исключений и гарантии, которые рассматриваются в C++, относятся к несколько иным аспектам: как написать код так, чтобы его прерывание любым исключением оставило текущий объект, как минимум, в корректном и согласованном состоянии.

>Это решается в C++ использованием готовых библиотек, так же это решается и в Java: грамотным кодированием.

Ага, т.е. язык-то не причем. Нужно, чтобы на нем работали грамотные люди. Причем и Java это так же касается.

>(Давайте ещё поговорим о мультитрединге и потокобезопасном кодировании. :D )

Ой, а что здесь-то не так? У нас в течении года работало приложение, в котором было 96 нитей (в одном процессе). И ни одной проблемы ни с мультитредингом, ни с потокобезопасным программированием. Сейчас это приложение разбито на несколько процессов, в одном из которых -- 55 потоков.

> Это АСПЕКТ использования языка. Но программисты C# вообще лишены другого аспекта — Checked Exceptions. Так что C#, несомненно, семантически беднее.

C# вообще идет в сад. Разговор, если вы не забыли, был о C++. Или все ваши претензии касались не C++, а C#? ;)

>> Старый exception теряется и это не есть хорошо, в принципе.

> exception в finally скорее всего вызван первоначальным exception-ом (например при работе с базой потерялась связь, пробуем откатиться и, естественно, тот же exception опять вылетит). От этого никуда, по сути не уйдёшь, лучшее, что можно сделать, выругаться в логах.

В общем-то ситуация с деструкторами в C++ очень похожа.

> Вообще, мне нравится подход D с scope (...) ..., позволяет делать то же самое, но без увеличения вложенности кода, по-моему читается значительно проще.

Да, в D в этом направлении хорошо продвинулись. Там есть на выбор и RAII, и scope, и finally. А в D2 они хотят еще дальше пройти -- реализовать специальную метку для функций nothrow.

>Стектрейс:
>Exception in thread "main" test.MyCheckedException
>	at test.MyCheckedExceptionThrower.<init>(Main.java:30)
>	at sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
>	at sun.reflect.NativeConstructorAccessorImpl.newInstance(Unknown Source)
>	at >sun.reflect.DelegatingConstructorAccessorImpl.newInstance(Unknown Source)

Ээ... Рефлексия идёт лесом.

> В общем-то ситуация с деструкторами в C++ очень похожа.

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

> А в D2 они хотят еще дальше пройти -- реализовать специальную метку для функций nothrow.

Кстати да, мне checked exceptions не нравятся (точнее даже, их можно использовать, но это зачастую выливается в такое количество синтаксического мусора, что не использовать их проще и для сопровождаемости, и для читабельности кода), но throw()/nothrow вполне полезны.

>> Собственно если верить якобы-Луговскому

>Ну, если ты ему веришь, тогда ой.

Однако неясно, в чем заключается ой. Таки в первом приближении я, как человек несильно разбирающийся, поверю ему, нежели красноглазым лоровцам, которые кричат "в генту/слаке/lfs ты решаешь все сам", "в плюсах ты сам себе бог", и т.д. :)

> Ээ... Рефлексия идёт лесом.

А чего так, это неотъемлемая часть языка. Сейчас ещё пошаманю, попробую без рефлексии кинуть.

>Вопрос, кто авторитетнее Луговский или Страуструп?

У тебя ГСМ, очевидно. Луговский не авторитетен — Луговский просто каждый раз доказывает свои утверждения и рационально их обосновывает.

>>Error гарантирует крах приложения.
>он ловится так же как любое другое исключение.
>>А смысл?
>Чтобы не допустить краха приложения, очевидно. Упавший плагин можно перезапустить, например.
Неочевидно. Упавший из-за Error плагин в лучшем случае потянет за собой JVM и всё приложение, в худшем — случится утечка или нарушение стэка где-нибудь в нативной либе.

>> ...ни один, даже супер-профессиональный, программист в одиночку сходу не разберется в 200 мб текстов того-же KDE хотя ему там требуется исправить всего-то какую-то досадную мелочь.

>Интересно, а чем же здесь поможет процедурное программирование? В лучшем случае, вместо 200 Мб исходников получишь 180 Мб. И чем отличается исправление кода в каком-нибудь методе класса от исправления кода функции? Предугадывая вопрос о "поломанном API": в процедурных языках точно также может потребоваться лишний вызов функции, или поменяется содержимое какой-нибудь структуры/записи и т.д. anonymous (*) (28.06.2008 13:57:45)

Не буду здесь затеивать спор, тем более спорить бесполезно, а приведу цитату из моей любимой книги (Йа самоучко): "Вместе с UNIX появилось много новых программ и методов программирования, но никакая отдельная программа или идея не дает гарантии в отношении качества системы. Эффективность системы достигается благодаря определенному подходу к программированию, своего рода философии использования вычислительной машины. Основной смысл ее состоит в том, что мощь системы обуславливается взаимодействием программ, а не мощью САМИХ программ."

"САМИХ" - это я выделил, цитата взята из предисловия в "Б. В. Керниган, Р. Пайк "UNIX-универсальная среда программирования" М.,"финансы и статистика" 1992" ... и маленький пример из книги: полноценная программа на C, zap занимает 33 строки, включая комментарии, пустые строки и {} в отдельной строке. Предлагаю подумать, потом почитать книгу, потом опять подумать, а, уже после, что-то ляпать "вумное".

> его, где не хочется, чтобы из за кривости одного куска страдало всё приложение.

Я конечно в Java не силён, однако у меня маленький вопрос, а что нельзя подозрительные plugin-ны запускать fork-exec-ом и ждать select-ом для красоты и стандартности? Ну там интерфейсик продумать командный - нет?

>Ага, только там ни массивов, ни генериков, ни forall не было, а так просто чудесен.

каких массивов нет?

sv75, открой уже для себя FreePascal в котором есть генерики (обобщения)

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

Насколько я помню, нельзя выбрасывать исключение, когда идет раскрутка стека после выброса предшествовавшего ему исключения. Именно эта ситуация приводит к вызову terminate.

Но, поскольку в этот момент работают только деструкторы, то это касается в первую очередь деструкторов.

Отсюда-то и растут ноги у данного правила.

> Таки в первом приближении я, как человек несильно разбирающийся, поверю ему, нежели красноглазым лоровцам, > я, как человек несильно разбирающийся, > несильно разбирающийся,

хе-хе-хе, луговский смотрит на таких как на быдло. можешь верить дальше кому угодно.

>Не буду здесь затеивать спор, тем более спорить бесполезно, а приведу цитату

Так современные приложения представляют собой именно агрегат взаимодействующих программ: чего стоят, например, многопоточное программирование, когда в одном приложении используются нити для выполнения одинаковых или разных задач. Пример: текстовый процессор в фоне проверяет орфографию, закачивает обновление словарей, рендерит сложную графику и т.д.

>Предлагаю подумать, потом почитать книгу, потом опять подумать, а, уже после, что-то ляпать "вумное".

Ценная мысль, которая приходит в голову постоянно, но сейчас не до неё, так как доступ к вычислительным средствам уж очень дешёв. И машинное время не такое дорогое, как тридцать лет назад. :))

> Неочевидно. Упавший из-за Error плагин в лучшем случае потянет за собой JVM и всё приложение, в худшем — случится утечка или нарушение стэка где-нибудь в нативной либе.

Если в процессе выполнения верифицированного байткода упала JVM или случилась утечка памяти/нарушение стека, значит в JVM баг.

>На мой взгляд, C++ довольно хорош для трехмерной компьютерной графики. Например рендер наподобие http://www.luxrender.net/ на хаскеле/жаве будет выполняться дольше, чем аналог на C++, и кушать неадекватные количества памяти.

А теперь расскажите, зачем в рендере нужен ООП? Эффективный рендер, для которого скорость критична, пишется на C в виде библиотеки. Если его написать на C++, то и использовать его можно будет только на C++. Это, кстати, один из аргументов Xenocephal-а в пользу C:

>>Предлагаю привести примеры в доказательство своей правоты. >>Что можно написать на Plain C и нельзя на С++? >Например, библиотеку функций, которые будут вызываться из другого, >чужеродного языка - не важно, интерпретируемого или компилируемого. На >C++ придется все засунуть в extern "C" { ... }, и никаких тебе классов с темплейтами.

> Я конечно в Java не силён, однако у меня маленький вопрос, а что нельзя подозрительные plugin-ны запускать fork-exec-ом и ждать select-ом для красоты и стандартности? Ну там интерфейсик продумать командный - нет?

Можно. В C так и приходится делать. Но вы ведь не будете отрицать, что это значительно сложнее (да и накладнее), чем обычные вызовы.

>Я конечно в Java не силён, однако у меня маленький вопрос, а что нельзя подозрительные plugin-ны запускать fork-exec-ом и ждать select-ом для красоты и стандартности? Ну там интерфейсик продумать командный - нет?

JMS появилась в J2EE v.1.2, если не ошибаюсь. ;) Сколько уж лет прошло...

Форматирование:

>На мой взгляд, C++ довольно хорош для трехмерной компьютерной графики. Например рендер наподобие http://www.luxrender.net/ на хаскеле/жаве будет выполняться дольше, чем аналог на C++, и кушать неадекватные количества памяти.

А теперь расскажите, зачем в рендере нужен ООП? Эффективный рендер, для которого скорость критична, пишется на C в виде библиотеки. Если его написать на C++, то и использовать его можно будет только на C++. Это, кстати, один из аргументов Xenocephal-а в пользу C:

>>Предлагаю привести примеры в доказательство своей правоты.

>>Что можно написать на Plain C и нельзя на С++?

>Например, библиотеку функций, которые будут вызываться из другого, чужеродного языка - не важно, интерпретируемого или компилируемого. На C++ придется все засунуть в extern "C" { ... }, и никаких тебе классов с темплейтами.

Пошёл читать "луговского", а то как-то все уныло, как на току у тетеревов.

(лубытел "UNIX-универсальная среда программирования")

>Если в процессе выполнения верифицированного байткода упала JVM или случилась утечка памяти/нарушение стека, значит в JVM баг.

Не, не так.
Если в процессе выполнения верифицированного байткода упала JVM или случилась утечка памяти/нарушение стека, значит в коде на C++ баг. ;)

>>> Собственно если верить якобы-Луговскому

>> Ну, если ты ему веришь, тогда ой.

> Однако неясно, в чем заключается ой.

В вере. Мы говорим об узкотехнических вещах, в них нужно разбираться. Знать историю, иметь опыт.

> Таки в первом приближении я, как человек несильно разбирающийся, поверю ему, нежели красноглазым лоровцам, которые кричат

Это говорит только о том, что стиль "а-ля Луговский" на тебя хорошо действует.

Гы, ну или так. Только s/C++/C++\/C\/Assembler/ :)

> Эффективный рендер, для которого скорость критична, пишется на C в виде библиотеки. Если его написать на C++, то и использовать его можно будет только на C++.

Разработчиков плагинов для Maya это не смущает.

> Если его написать на C++, то и использовать его можно будет только на C++.

Это не так. Есть даже биндинги Qt к Си :)

> Это, кстати, один из аргументов Xenocephal-а в пользу C:

Да, демагоги любят этот аргумент.

> Да, в D в этом направлении хорошо продвинулись. Там есть на выбор и RAII, и scope, и finally.

Я не въехал, чем RAII отличается от scope?

> У тебя ГСМ, очевидно.

У меня техническое, лол!

> Луговский не авторитетен — Луговский просто каждый раз доказывает свои утверждения и рационально их обосновывает.

Где утверждает и доказывает? Он тупо провоцирует и троллит.

>> Это, кстати, один из аргументов Xenocephal-а в пользу C:

>Да, демагоги любят этот аргумент.

Опровергните его, если можете.

>Где утверждает и доказывает? Он тупо провоцирует и троллит.

В треде на sql.ru уже пытались найти, где он не доказал то, что сказал. Что-то так и не смогли найти.

CAPTCHA buzgers

Во, нашёл. http://www.rsdn.ru/forum/message/2778526.flat.aspx здесь куча способов кидать необъявленное исключение. Мне больше всего с генериками понравился, там не придерёшься, чистая джава, никаких библиотек.

>> Да, в D в этом направлении хорошо продвинулись.
>>Там есть на выбор и RAII, и scope, и finally. 

>Я не въехал, чем RAII отличается от scope?

RAII:

scope class Resource {
  this() {
    handle_ = AcquireSomeResource();
  }
  ~this() {
    ReleaseSomeResource(handle_);
  }
  ...
}

void f() {
  auto r = new Resource(); // Вот и все.
  ...
}

Scope:

void f() {
  auto h = AcquireSomeResource(); // Это еще не все.
  scope(exit) ReleaseSomeResource(h); // Вот теперь все.
  ...
}

товарищ, так рассуждают только неудачники, которые ниасилили серьезных систем. Плюсы это паровоз, а Ява суперскоростной поезд в смысле эффективности разработки. А это самое главное. Танцы с бубнами в плюсах щас никому не нужны. Щас конкуренция глаша. За короткий срок сделать вменяемое кроссплатформенное распределенное приложение на Яве делается за так. И сборщик мусора, который тут критикуют, будет поэффективнее тех так костылей, которые выдумывуют недоразвитые плусатники.

>Ценная мысль, которая приходит в голову постоянно, но сейчас не до неё, так как доступ к вычислительным средствам уж очень дешёв. И машинное время не такое дорогое, как тридцать лет назад. :)) iZEN ** (*) (28.06.2008 14:49:30)

Угу, "бензин стоит 15 копеек" (с) неизвестный водитель Рабинович 1980 г.

> В треде на sql.ru уже пытались найти, где он не доказал то, что сказал. Что-то так и не смогли найти.

Сомневаюсь, что можно что-то найти на 100 с лишним страницах. Таки дела есть поважнее у каждого.

> И сборщик мусора, который тут критикуют, будет поэффективнее тех так костылей, которые выдумывуют недоразвитые плусатники.

Побочные эффекты этого (пока?) не решены. Так что хватит демагогии, товарищ.