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

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

Анонимный друг, ты уже прочитал ссылку на Луговского, чтоб заявлять такое? %)

>http://www.sql.ru/forum/actualthread.aspx?bid=16&tid=466654

Зачетно. Повеселило.

> ссылку на Луговского

Кто тебе сказал, что это был Луговский?

>Можете показать пальцем на checked exceptions в Eiffel?

Тут:
http://darij.by.ru/Eiffel.html#_Toc145476379

> Анонимный друг, ты уже прочитал ссылку на Луговского, чтоб заявлять такое? %)

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

>>Можете показать пальцем на checked exceptions в Eiffel?
>Тут:
>http://darij.by.ru/Eiffel.html#_Toc145476379

Ы. А о чем там вообще написано, ты прочитать потрудился? Или, как всегда, языком молоть горазд?

> Не, по сравнению с C#, как языком

Спецификации С# свежее 1.0 открывали?

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

Мне тут тётя Маша сказала что Луговский. Она с ним на нарах 15 суток отсидела, мировой мужик! :-D

Про авторитет спрашивают когда с темой не хотят знакомиться. Я могу по-секрету сказать что даже самые крутые авторитеты могут ошибаться. Когда всерьёз, а когда и шутки над нами смертными шутят. Так что думать надо самим, а авторитеты они приходят и уходят, один Бог безгрешен, хотя и шутник.

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

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

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

>Кто тебе сказал, что это был Луговский?

А имеет значение?

>Все домохозяйки ломанулись туда где бабло. Сама по себе Java может и хороша, но те кто там сейчас веет флагом, это ужос! Пройдёт ещё пару десятилетий и Java будет низкоуровневым отстоем а новые "программисты", ещё более необразованные, будут вещать про нейронные интерфейсы и что программировать будем на UMLv10.

Сам понял, чё сказал?

Попробуй объяснить замыкания домохозяйкам. А то, неровен час, выйдет Java 7.0 и все домохозяйки останутся без бабла.

>>Можете показать пальцем на checked exceptions в Eiffel? 

>Тут: 
>http://darij.by.ru/Eiffel.html#_Toc145476379

Блин, ламеризм! "Не читайте советских газет" (С)
Нашли какую-то херню в рунете и верите ей.

Инструкция check в Eiffel, это аналог assert-а,
но никак не checked exception. Вот, что об этом
пишет сам Мейер в своем толмуде:
---
Инструкция check выражает уверенность автора программы, что некоторое
свойство всегда выполняется, когда вычисление достигает точки, в которой
находится наша инструкция. Синтаксически, инструкция записывается в следующей
форме:

check
  assertion_clause1
  assertion_clause2
  ...
  assertion_clause
end

Включив эту инструкцию в программный текст, мы говорим, что всякий раз,
когда управление достигает этой инструкции, заданное утверждение
(предложения утверждения между check и end) должно выполняться.
---
(глава 11.11 "Инструкция утверждения", стр.371).

Там же чуть ниже:
---
Инструкция check дает возможность выразить наше предположение о
свойствах объектов:

x := a^2 + b^2
... Другие инструкции ...
  check
    x >= 0
    -- Поскольку x был вычислен как сумма квадратов.
  end
y := sqrt(x)
---

Кроме того, в отличии от checked exceptions в Java, инструкция
check (как и любые другие инструкции Design By Contract) могут
быть отключены во время компиляции и не будут оказывать влияние
на работу программы вообще.

Луговский вообще бох

> Ага, только там ни массивов

s/массивов/шаблонов/

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

> Кроме того, в отличии от checked exceptions в Java, инструкция check (как и любые другие инструкции Design By Contract) могут быть отключены во время компиляции и не будут оказывать влияние на работу программы вообще.

Не то хотел сказать: от проверки checked exceptions в Java во время компиляции невозможно отказаться. Компилятор будет бить по рукам за нарушение спецификации исключений. Тогда как в Eiffel инструкции DbC во время компиляции никак не проверяются, а работают исключительно в run-time. И, поскольку это не дешево, то их можно отключать во время компиляции.

> А то, неровен час, выйдет Java 7.0 и все домохозяйки останутся без бабла.

Не останутся, они будут писать на 1.6 (совместимость ведь не сломают?). Как вышло с С# 2.0

> Так. Этого к Дельфям не пускать. Рекомендую осилить ООП, конкретно наследование, и компонентную модель VCL/CLX/LCL.

> с деревом TCustomTreeView наследуешь

Про компонентную модель я писАл. Её как-то не очень уж часто используют. Т.к. нужно разрабывать (в виде отдельного проекта или подпроекта) и доставлять отдельный компонент, или "тупо наследовать и вставлять на форму ручками" (что вообще ни один программист на Delphi делать не станет).

> с деревом TCustomTreeView наследуешь.

Так о чем и речь: 1. не жирно ли все TCustomTreeView наследовать, если нет, то как его на форму добавить (разрабатывать отдельный компонент? А если компонент сложный, то как его отладить, быстро изменить в рамках всего проекта без постоянных пересборок и переустановок?

2. кто-нибудь в Delphi их наследовал для такой для своих нужд? Сомневаюсь, скорее всего искали и доставляли отдельный компонент , который еще и не всегда подойдет (разработчики компонентов конечно же эти классы наследовали, но...). Если нужно сделать представление одних и тех же данных в TreeView и ListView как быть? В JAVA, QT и т.д. нужно просто реализовать соответствующие интерфейсы/абстрактные модели (в виде двух классов-делегатов, работающих с одними и теми данными, или вообще в виде одного, если получится) и подставить их/его во view (сомневаюсь, что в Delphi так получится "из каропки").

По поводу SynEdit и прочих сторонних компонентов с вами согласен. Но смотрятся они как-то корявенько, т.к. не всегда 100% подходят и трудно расширяются.

P.S. еще раз уточню, если есть подходящие компоненты, программа не очень сложная (ну не верю я, что на Delphi можно сделать WebBrowser, или текстовый процессор сложнее WordPad) и в дальнейшем сильных изменений не будет, то Delphi очень даже хороший вариант.

http://burks.brighton.ac.uk/burks/language/eiffel/oveiffel/exceptns.htm

>> Кто тебе сказал, что это был Луговский?

> А имеет значение?

Это можно понимать так "мне никто не говорил, я сам придумал"? Потому что в реальности Луговский относится к Си++ с некоторым даже уважением %)

>Да и вообще смешно: процедурный Modula-2 является конкурентом объектно-ориентированному C++ :) Даже при всех недостатках C++. eao197 (*) (28.06.2008 9:59:40)

Смешно дураку, что два уха на боку. Процедурное программирование не является конкурентом ООП, он просто реализует иную концепцию, не более и не менее и, насколько мне известно, еще ни один С*труп & Ко не привел ни одного толкового аргумента в пользу ООП, кроме одного (самого сладкого для софтверных монстров типа MS или IBM ) - возможности клепать программные комбайны, которые норовят делать фсё, но делают это "фсиё" очень хреново - пресловутый windows-way, на который могли свернуть только пришибленные DOSкой программеры. Сейчас сама идея открытых исходников находится под угрозой - ни один, даже супер-профессиональный, программист в одиночку сходу не разберется в 200 мб текстов того-же KDE хотя ему там требуется исправить всего-то какую-то досадную мелочь. Может быть из-за этого программирование находится сейчас в таком плачевном состоянии - наплодили монстров с которыми уже даже сами создатели не могут ничего поделать, а вернуться на UNIX-way уже мозгов не хватает или спонсор не пущает (баблосы можно и поприжать для слишком умных)...

>Это можно понимать так "мне никто не говорил, я сам придумал"?

s/А имеет значение/А имеет значение он ли это?

>Потому что в реальности Луговский относится к Си++ с некоторым даже уважением

Это можно понимать как "Луговского в фидо, лоре и т.д. вообще не существовало"?

Собственно если верить якобы-Луговскому, то он доказывал что "C++ не нужен" для того, чтоб те кто его читает, хоть немного расширили кругозор, а не "тупо обосрать", ы?

Интересно, хоть один быдлёныш, хаящий здесь Страустрапа и его разработку, написал свой язык программирования, которым хоть кто-то пользуется кроме него самого (это в лучшем случае)? Вы безсполезные бздуны. Становитесь в очередь в биореактор, сукины дети, а то он уже не справляется с переработкой быдломассы. Только так вы сможете принести пользу человечеству.

З.Ы. Ни в коем разе не фанат Цпп.

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

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

> Процедурное программирование не является конкурентом ООП, он просто реализует иную концепцию, не более и не менее и, насколько мне известно, еще ни один С*труп & Ко не привел ни одного толкового аргумента в пользу ООП, кроме одного (самого сладкого для софтверных монстров типа MS или IBM ) - возможности клепать программные комбайны, которые норовят делать фсё, но делают это "фсиё" очень хреново - пресловутый windows-way, на который могли свернуть только пришибленные DOSкой программеры. Сейчас сама идея открытых исходников находится под угрозой - ни один, даже супер-профессиональный, программист в одиночку сходу не разберется в 200 мб текстов того-же KDE хотя ему там требуется исправить всего-то какую-то досадную мелочь. Может быть из-за этого программирование находится сейчас в таком плачевном состоянии - наплодили монстров с которыми уже даже сами создатели не могут ничего поделать, а вернуться на UNIX-way уже мозгов не хватает или спонсор не пущает (баблосы можно и поприжать для слишком умных)...

Феерично! Пиши еще

>в Eiffel инструкции DbC во время компиляции никак не проверяются, а работают исключительно в run-time. И, поскольку это не дешево, то их можно отключать во время компиляции.

Да. Но сама концепция "контрактного программирования" заставляет постоянно задумываться о входных параметрах методов, о способе обработки исключительных ситуаций и принятии правильных решений для такой обработки. Чего в C++ не наблюдалось НИКОГДА.

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

OpenGL — это голимый Си без плюсов. ООП-обёртка для него есть — Java3D API. Причём сам API может использовать DirectX или OpenGL в Windows, OpenGL в UNIX, но сам API неизменен.

>>в Eiffel инструкции DbC во время компиляции никак не проверяются, а работают исключительно в run-time. И, поскольку это не дешево, то их можно отключать во время компиляции.

>Да. Но сама концепция "контрактного программирования" заставляет постоянно задумываться о входных параметрах методов, о способе обработки исключительных ситуаций и принятии правильных решений для такой обработки. Чего в C++ не наблюдалось НИКОГДА.

Опять поздравляю вас соврамши, любезнейший!

В специальном третьем издании книги "Язык программирования C++" обсуждаемого здесь Страуструпа есть специальное приложение "Безопасность исключений и стандартная библиотека". А это издание 2000-го года (на русском издана в 2001). Так что теме безопасности исключений в С++ уделяется очень большое внимание. Достаточно глянуть, например: http://www.boost.org/community/exception_safety.html

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

Скорее Windows Vista написали индусы, а вот про J2ME-игры я такой статистики не дам. (J2ME это урезанная Java2 v.1.4). Куда уж им до 1.5/1.6 с генериками.

>Её как-то не очень уж часто используют.

Вот-вот. Быдлокодеры и есть.

>1. не жирно ли все TCustomTreeView наследовать

В смысле, жирно???? Там тупо одну-две функции переписать. Два десятка строчек.

>если нет, то как его на форму добавить (разрабатывать отдельный компонент? А если компонент сложный, то как его отладить, быстро изменить в рамках всего проекта без постоянных пересборок и переустановок?

Вы вообще на Дельфи сложнее блокнота что нибудь писали? О_о

>2. кто-нибудь в Delphi их наследовал для такой для своих нужд?

Разумеется. Не в обработчики же пихать.

>Если нужно сделать представление одних и тех же данных в TreeView и ListView как быть?

Переписать функции доступа данных в них на внешний источник и добавить источник в пропертисы.

>Но смотрятся они как-то корявенько

Напишите свою морду, только движок используйте. Недолго.

>P.S. еще раз уточню, если есть подходящие компоненты, программа не очень сложная (ну не верю я, что на Delphi можно сделать WebBrowser, или текстовый процессор сложнее WordPad) и в дальнейшем сильных изменений не будет, то

... вы с 99.(9) вероятностью быдлокодер и логику в обработчиках пишите.

>(ну не верю я, что на Delphi можно сделать WebBrowser, или текстовый процессор сложнее WordPad)

<cut>/Delphi/Referee/Referee VCL Edition# cat *.pas | wc -l 27651

Плюс, он еще пару проектов использует и плугины имеет. Общее где-то 34-35тыс строк. Сойдет?

>В специальном третьем издании книги "Язык программирования C++" обсуждаемого здесь Страуструпа есть специальное приложение "Безопасность исключений и стандартная библиотека"

Так это библиотека, а не конструкция языка! Тем более описана в "Приложении". СмЯшно.

> Достаточно глянуть, например: http://www.boost.org/community/exception_safety.html

Кстати, ни для одного другого языка я не видел обсуждения гарантий, которые должен предоставлять код в отношении исключений. Только в C++ говорят о трех типах гарантий: basic, strong и no-throw.

И это при том, что несоблюдение гарантий черевато в любом языке программирования (да, в C++ они самые тяжелые, но и в C#/Java легко оставить класс в некорректном состоянии после возникновения исключения). Но только в C++ об этом открыто говорят.

>>(ну не верю я, что на Delphi можно сделать WebBrowser, или текстовый процессор сложнее WordPad)
>/Delphi/Referee/Referee VCL Edition# cat *.pas | wc -l 27651
>Плюс, он еще пару проектов использует и плугины имеет. Общее где-то 34-35тыс строк. Сойдет?

Это тот, который IE5 использует в качестве движка? :))

> Возражения принимаются в виде предложений других языков =)

Haskell наше фсё!

>>В специальном третьем издании книги "Язык программирования C++" обсуждаемого здесь Страуструпа есть специальное приложение "Безопасность исключений и стандартная библиотека"

>Так это библиотека, а не конструкция языка!

Вы хоть сами сейчас понимаете, о чем идет речь?

>> Потому что в реальности Луговский относится к Си++ с некоторым даже уважением

> Это можно понимать как "Луговского в фидо, лоре и т.д. вообще не существовало"?

Это можно понимать как "на ЛОРе Луговский говорил не то, что думал" (в ФИДО я его не читал).

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

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

> он доказывал что "C++ не нужен" для того, чтоб те кто его читает, хоть немного расширили кругозор

Я имею наглость считать свой кругозор достаточно широким, но мне читать этого "якобы-Луговского" было противно. Впрочем, реального Луговского - тоже. Не важно, выплескивал он свои комплексы или вел просветительскую работу (как он написал в своем прощании) - от его методов "расширения кругозора" больше вреда, чем пользы.

>Кстати, ни для одного другого языка я не видел обсуждения гарантий, которые должен предоставлять код в отношении исключений. Только в C++ говорят о трех типах гарантий: basic, strong и no-throw.

Аналогия с Java.
Обработки Exception, RuntimeException, Error дают разные степени уверенности в правильности кода и состояния объекта после них.

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

>OpenGL — это голимый Си без плюсов. ООП-обёртка для него есть — Java3D API. Причём сам API может использовать DirectX или OpenGL в Windows, OpenGL в UNIX, но сам API неизменен.

OpenGL - всего лишь интерфейс к железке, немного не то. Я о софтверных рейтрейсерах.

>Феерично! Пиши еще eao197 (*) (28.06.2008 13:41:29)

Да без базара, кушайте - не обляпайтесь.

>OpenGL — это голимый Си без плюсов.

Гм, "голимый" - это шютк такой, да? А директ-Х 10 написаный на [три буквы] - это "круто"?

>Это тот, который IE5 использует в качестве движка? :))

Нет :) Он такой относительно толстый (для одного меня), потому что самописного всего много. Узкая специализация, не скачаешь ...

P.S. Ах да, это не браузер и не ТП. Для шахматистов/шашистов всяких вещица.

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

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

И чем отличается исправление кода в каком-нибудь методе класса от исправления кода функции? Предугадывая вопрос о "поломанном API": в процедурных языках точно также может потребоваться лишний вызов функции, или поменяется содержимое какой-нибудь структуры/записи и т.д.

> OpenGL — это голимый Си без плюсов. ООП-обёртка для него есть — Java3D API

хе-хе-хе. сразу виден профессионал в 3Д. перед тем как запихнуть треугольники в opengl частенько требуется неслабый препроцессинг. например отрисовка позрачных обьектов требует чтобы треугольники были отсортированы по глубине. есть и другие ньюансы. Для отрисовки сложных сцен, да еще и в реальном времени С++ незаменим.

Просто жабабыдлокодерам и кидателям кнопок на формы все свойства С++ вообщем-то не нужны.

>>Кстати, ни для одного другого языка я не видел обсуждения гарантий, которые должен предоставлять код в отношении исключений. Только в C++ говорят о трех типах гарантий: basic, strong и no-throw.

>Аналогия с Java. >Обработки Exception, RuntimeException, Error дают разные степени уверенности в правильности кода и состояния объекта после них.

Не просветите как? В частности интересует вопрос, каким образом, например RuntimeError соотносится с типами гарантий безопасности исключений?

В С++ объект в некорректном состоянии часто означает утечку памяти. В языках с GC этого нет, и объекты в некорректном состоянии чаще всего проще создать заново, если очень нужно продолжить работу после исключения. Если создать заново тяжело, можно и подумать про exception safety.

Ну и деструкторы, в которых лучше не кидать исключения, тоже на обсуждаемость exception safety влияют.

>>Кстати, ни для одного другого языка я не видел обсуждения гарантий, которые должен предоставлять код в отношении исключений. Только в C++ говорят о трех типах гарантий: basic, strong и no-throw.

>Аналогия с Java. >Обработки Exception, RuntimeException, Error дают разные степени уверенности в правильности кода и состояния объекта после них.

И эти люди учат меня исключениям (с)

>>кто-нибудь в Delphi их наследовал для такой для своих нужд?

>Разумеется. Не в обработчики же пихать.

2 redgremlin вопрос снят.

> ... вы с 99.(9) вероятностью быдлокодер и логику в обработчиках пишите.

... да... на Delphi/Builder только в обработчиках, иногда Frames или "компоненты ручками"...

P.S. Не проще ли было выбрать что-то другое (типа QT, Gtk, Swing или что-то еще с Model/View/Controller)? Там удобнее со своими компонентами.

>Не просветите как? В частности интересует вопрос, каким образом, например RuntimeError соотносится с типами гарантий безопасности исключений?

Вы же сами всё знаете. Зачем стебаться?
Exception проверяются на этапе компиляции компилятором и гарантируется вызов чётко определённого обработчика исключения на любом уровне вложенности.
RuntimeException не проверяются на этапе компиляции — за восстановление после сбоя (вызов правильного обработчика исключения) программист отвечает сам, как в C#.
Error гарантирует крах приложения.

>В С++ объект в некорректном состоянии часто означает утечку памяти. В языках с GC этого нет, и объекты в некорректном состоянии чаще всего проще создать заново, если очень нужно продолжить работу после исключения. Если создать заново тяжело, можно и подумать про exception safety.

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

>Ну и деструкторы, в которых лучше не кидать исключения, тоже на обсуждаемость exception safety влияют.

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