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

>>Там нет никакой scoped памяти. Есть только GC-память.

> Ну тогда это автоматизированный finally-блок а не RAII в понимании плюсов.

Если выключить режим дурака и подумать, то окажется, что в схеме с IDisposable на разработчике лежит ответственность за написание метода Dispose. Такая же, как и в C++ при написании деструктора.

Так что да -- это не RAII в понимании C++. Что не удивительно, поскольку это C#/.NET. Но принципы схожие.

>>Ну и в каком случае больше контекстов, за которыми нужно следить?

> И что, Font здесь - критический ресурс? В Яве - нет.

Если Ява работает на винде -- то ресурс, т.к. объем GDI ресурсов в приложении ограничен.

> Если он используется постоянно в каком-то контроле, можно мембером его сделать - тогда он не будет создаваться при каждой отрисовке.

Ага, конечно. Только вы до этого додумались.

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

>Скажешь Interface 01 и Aftor заслуживали каких-то иных эпитетов? С iron00cutter&Yossarian Ксеноцефал разговаривал вежливо.

Это пока тебя это не касается. Вот были бы у тебя с ним разногласия, я бы посмотрел на эпитеты в твою сторону...

> Битард?

Двачеры на моём лоре? лол?

"С++ - это замечательная, если не сказать гениальная объектная модель. Это превосходная, если не сказать максимальная, производительность. Это миллионы строк уже написанного кода на все случаи жизни. С++ - это мировая популярность, почти стандарт. Смело можно сказать, что это самый крутой язык, для самых крутых программистов. Но это также и часы, проведенные в поисках трудноуловимых ошибок, непонятность или правильнее сказать неочевидность многих вещей и, самое главное, время потраченное на его изучение. Говорят, что спустя годы программист С++ не знает любить ему или ненавидеть этот язык. Понимание красоты и гениальности приходит не сразу. Для этого нужно пройти большой путь. И путь этот никак не усеян розами." (c)www.dprogramming.ru

Всецело поддерживаю.

Да, меня тоже язык заинтересовал. Сборка мусора без всяких ВМ и т.д.. И Limbo, но пока времени нет.

IDE только пока одна - Code::Blocks.

> Приведи пример "чуши".

Да там всё приведено уже: http://www.sql.ru/forum/actualthread.aspx?bid=16&tid=466654&pg=11

Но особенно мне нравятся его утверждение о том, что Страуструп не знал о ML (то есть про эволюцию Си++ он не чита, или сознательно лжет) и его умилительный рассказ о раскрутке Лиспа, Си и Паскаля через Форт на голом железе за два месяца "по вечерам". И еще его манера не отвечать на избранные вопросы :)

>Если выключить режим дурака и подумать, то окажется, что в схеме с IDisposable на разработчике лежит ответственность за написание метода Dispose.

Пользователь кода может забыть вызвать Dispose если он инстанциирует Font вне using блока. Разработчик производного от Font класса может забыть вызвать Dispose парента если он его перегрузил. Как страшно жить.

>Такая же, как и в C++ при написании деструктора.

В плюсах для RAII помимо деструктора надо написать конструктор копирования и operator=. Это нетривиальная задача т.к в конструкторе копирования для критического ресурса надо инкрементить счетчик ссылок который при этом должен находиться вне объекта, либо его клонировать что еще более нетривиальная задача для какого-нибудь хэндла. А в operator= надо не забыть ни одно поле которое было упомянуто в конструкторе копирования.

>>>Ну и в каком случае больше контекстов, за которыми нужно следить?

>> И что, Font здесь - критический ресурс? В Яве - нет.

>Если Ява работает на винде -- то ресурс, т.к. объем GDI ресурсов в приложении ограничен.

Тем не менее в java.awt.Font никакого метода dispose() который надо обязательно вызывать нет.

>> Если он используется постоянно в каком-то контроле, можно мембером его сделать - тогда он не будет создаваться при каждой отрисовке.

>Тем не менее, хотелось бы услышать внятный ответ на вопрос о разнице в количестве контекстов.

Проблема надумана. Нагромождений finally в реальном коде в Жаве нет.

> В плюсах для RAII помимо деструктора надо написать конструктор копирования и operator=

Зачем?

>> Приведи пример "чуши".

>Да там всё приведено уже: http://www.sql.ru/forum/actualthread.aspx?bid=16&tid=466654&pg=11

Игровая физика действительно до недавнего времени была слабовата. В Лиспе язык действительно можно расширять. Написание пары языков - скорее всего специфичные для проблематики языки имеются в виду.

>Но особенно мне нравятся его утверждение о том, что Страуструп не знал о ML (то есть про эволюцию Си++ он не чита, или сознательно лжет

А может Строуструп лжет?

>и его умилительный рассказ о раскрутке Лиспа, Си и Паскаля через Форт на голом железе за два месяца "по вечерам"

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

>И еще его манера не отвечать на избранные вопросы :)

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

>§ 2.4. Ответственность сторон В случае нарушения любого из пунктов данного ... соглашения разработчик и пользователь обязаны принять на себя те муки, которые им подготовила совесть. Но тут надо ориентироваться по ситуации: если муки слишком слабые, то следует их чем-нибудь усилить. Хорошим средством является самосожжение либо дизассемблирование исходного кода данного лицензионного соглашения в уме.

Ну нечто подобное нужно подписывать перед программированием на С++.

Виртовский паскаль можно написать за выходные, если использовать некоторые готовые инструменты вроде парсера и лексера.

>Есть библиотека с нужной функцией, я её использую. А уж на чём оно написано - дело десятое.

Ну и как ты будешь использовать C++ библиотеку из программы на C(можешь подставить на это место Perl, Python, Haskell, LISP или еще что-то, что ты используешь)?

> Пользователь кода может забыть вызвать Dispose если он инстанциирует Font вне using блока. Разработчик производного от Font класса может забыть вызвать Dispose парента если он его перегрузил. Как страшно жить.

Да, заставлять пользователя закрывать ресурсы явно в finally гораздо благороднее.

> В плюсах для RAII помимо деструктора надо написать конструктор копирования и operator=.

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

Вот например, есть ли конструктор копирования у std::fstream?

> Тем не менее в java.awt.Font никакого метода dispose() который надо обязательно вызывать нет.

Ну так на Java и нет серьезных десктопных приложений. Может как раз одно с другим связано?

> Нагромождений finally в реальном коде в Жаве нет.

В исходниках компилятора Scala 2.5.0 167 файлов. В 13-ти из них finally используется. Т.е. почти в 10% файлов. И это в проекте, где вообще ресурсами управлять не нужно.

Тем не менее, вы сказали, что при использовании using программисту нужно заботиться о большем количестве контекстов. Вы по прежнему так думаете?

>> В плюсах для RAII помимо деструктора надо написать конструктор копирования и operator=

>Зачем?

Чтобы возвращать объект например из функции. Например Font f = LookAndFeel.getFont(BUTTON_CAPTION)

> В исходниках компилятора Scala 2.5.0 167 файлов. В 13-ти из них finally используется. Т.е. почти в 10% файлов.

Гм, а разве Scala на Java написана? В последний раз, когда я её видел, она была написана на Scala :)

>>> В плюсах для RAII помимо деструктора надо написать конструктор копирования и operator=

>> Зачем?

> Чтобы возвращать объект например из функции. Например Font f = LookAndFeel.getFont(BUTTON_CAPTION)

Во-первых причём тут RAII? Во-вторых для возвращения объекта из функции не обязателен конструктор копирования, можно просто возвращать указатель (при необходимости умный).

>его умилительный рассказ о раскрутке Лиспа, Си и Паскаля через Форт на голом железе за два месяца "по вечерам"

Ну вот разберем тебе, что он там написал:

>На ассемблере написал минимальное ядро Форта

Нефиг делать, форт реально пишется проще ассемблера. Сравнимо со сложностью создания виртуальной машины или интерпретатора brainfuck.

>на Форте - простейший интерпретатор Лиспа

Сложно? Простейший интерпретатор Лиспа - это что-то вроде Scheme(то есть макросы слабоваты). Это осиливают даже студенты MIT, до этого не умеющие программировать.

>На этом Лиспе - компилятор Лиспа посложнее

По сути макросы реализовал. Компилировал может быть вообще в форт.

>а на нем уже - компилятор для довольно немалого подмножества Си и для полного Виртовского Паскаля

Виртовский Паскаль - это вообще ерунда. Подмножество Си может быть любое, это зависит от того, как вы понимаете слово "немалого"(а много - это сколько? ©).

> Но при этом ты будешь наверняка пользоваться библиотеками на Си типа OpenGL, так как они объективно удобней (не спорь со мной, я точно знаю что с библиотеками на Си меньше всего гиморов, это факт).

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

капча maruded неспроста

>Поскольку, для таких вещей, как файлы или мутексы это вообще не имеет смысла.

Для файлов - имеет смысл. Возвращать InputStream в Яве - обычное дело.

>> Тем не менее в java.awt.Font никакого метода dispose() который надо обязательно вызывать нет.

>Ну так на Java и нет серьезных десктопных приложений. Может как раз одно с другим связано?

Не из-за GDI ликов точно. А в плюсах при работе с GDI я использовал __finally для клинапа.

>> Нагромождений finally в реальном коде в Жаве нет.

>В исходниках компилятора Scala 2.5.0 167 файлов. В 13-ти из них finally используется. Т.е. почти в 10% файлов. И это в проекте, где вообще ресурсами управлять не нужно.

А где нужно? У вас работа с файлами по всему проекту размазана? Или вы по всему проекту ДБ транзакции открываете/закрываете?

>Тем не менее, вы сказали, что при использовании using программисту нужно заботиться о большем количестве контекстов. Вы по прежнему так думаете?

Теперь я думаю об этом как об авто-finally. Решает проблему "забывания вызвать dispose()", которой по факту не существует.

>в прошлом GTK треде ты слил как программист и теперь собираешься учить нас, нормальных С++ программистов нашему бизнесу? GTFO дружок.

Ты тот даун который в MSVC6 использовал Loki в продакшене? Вылезай, я тебя в игнор не занес.

> Объясни, какие функции ООП нужны в рендере?

обьясняю:

// C++ Point c = a + b;

// C c.x = a.x + b.x; c.y = a.y + b.y; c.z = a.z + b.z;

>> Чтобы возвращать объект например из функции. Например Font f = LookAndFeel.getFont(BUTTON_CAPTION)

>Во-первых причём тут RAII? Во-вторых для возвращения объекта из функции не обязателен конструктор копирования, можно просто возвращать указатель (при необходимости умный).

Тут в треде пытаются доказать необходимость RAII для объекта типа Font.

> Ты тот даун который в MSVC6 использовал Loki в продакшене?

Локи я не использую, а дауном себя показал ты, когда начал примеры своего "кода" выкладывать.

>> Объясни, какие функции ООП нужны в рендере?

>обьясняю:

>// C++ Point c = a + b;

>// C c.x = a.x + b.x; c.y = a.y + b.y; c.z = a.z + b.z;

Тебя не смущает что в первом случае создается два временных объекта - один в недрах operator+, другой в результате возврата по значению?

>> Ты тот даун который в MSVC6 использовал Loki в продакшене?

>Локи я не использую, а дауном себя показал ты, когда начал примеры своего "кода" выкладывать.

Приведи мой код и претензии к нему, обсудим.

> Приведи мой код и претензии к нему, обсудим.

уже обсудили в GTK треде, твой код был вопиюще бездарен, поэтому я тебя запомнил.

static Font* getFont(const std::string& name) {
    return new Font(name);
}

...

std::auto_ptr<Font> f(LookAndFeel.getFont(BUTTON_CAPTION));
...

оно?

>> Приведи мой код и претензии к нему, обсудим.

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

Ничего конкретного, слив засчитан.

> Ну и как ты будешь использовать C++ библиотеку из программы на C(можешь подставить на это место Perl, Python, Haskell, LISP или еще что-то, что ты используешь)?

Ну на счёт использования c++ либы в сишных проектах пример уже приведён, это библиотека модплуг. А что до остального, то это уже другой вопрос ::))

> static Font* getFont(const std::string& name)

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

т.е

Font get_font(const char *name);
соотвественно:

{
   Font f = get_font("Tahoma"); // RAII
   // use f
}

или запоминаем
m_font = get_font("Tahoma");

>>Тебя не смущает что в первом случае создается два временных объекта - один в недрах operator+, другой в результате возврата по значению?

да, создание объекта в стеке это просто окуенно дорогая операция.

> нормальный программист сделает Font копируемым типом, а внутри будет лежать указатель на некопируемый FontImpl с подсчетом ссылок.

и зачем везде имитировать reference-семантику? Где это надо, там можно имитировать, где не надо, можно указатель передавать. Не нужно ограничивать себя.

> да, создание объекта в стеке это просто окуенно дорогая операция.

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

>>Поскольку, для таких вещей, как файлы или мутексы это вообще не имеет смысла.
>Для файлов - имеет смысл. Возвращать InputStream в Яве - обычное дело.

Ужос. Таких программастов надо в тюрьму сажать. Сия фраза полностью отражает, чего человек стоит, как программист и показывает как абсолютное незнание С++, так и незнание или непонимание Java. И такие люди берутся о чём-то еще рассуждать.

> и зачем везде имитировать reference-семантику? Где это надо, там можно имитировать, где не надо, можно указатель передавать.

передавать можно и без reference семантики. foo(const Font &font);

>>Тебя не смущает что в первом случае создается два временных объекта - один в недрах operator+, другой в результате возврата по значению?

>да, создание объекта в стеке это просто окуенно дорогая операция.

Это дно рендера. В нем все влияет на все.

>> Да там всё приведено уже: http://www.sql.ru/forum/actualthread.aspx?bid=16&tid=466654&pg=11

> Игровая физика действительно до недавнего времени была слабовата.

Специально для тебя - там 8 пунктов. И это только то, что бросалось в глаза. Он не на всё ответил, а на остальное - отмазался.

>>и его умилительный рассказ о раскрутке Лиспа, Си и Паскаля через Форт на голом железе за два месяца "по вечерам"

>Форт не знаю. На Лиспе чистый Си или Паскаль за пару месяцев по вечерам в принципе сделать наверно можно

А он сделал и то, и другое. И еще Лисп. И Форт. Впрочем, если ты в это веришь - ради бога. Добро пожаловать в фан-клуб :D

>>Но особенно мне нравятся его утверждение о том, что Страуструп не знал о ML (то есть про эволюцию Си++ он не чита, или сознательно лжет

>А может Строуструп лжет?

16 лет назад, когда он это сказал, ML не был в моде. И система исключений в Си++ и в самом деле похожа на ML.

> Ну за мной видят манеру не отвечать на какие-то вопросы.

И это очень печально - народу нравятся твои отжиги.

> влияние плюсов на мозг - высасывание каких-то трудностей на ровном месте.

Палишься.

> так пишут только мудаки.

Да нунах. А если Font достаточно толстый?

>>>Поскольку, для таких вещей, как файлы или мутексы это вообще не имеет смысла. >>Для файлов - имеет смысл. Возвращать InputStream в Яве - обычное дело.

>Ужос. Таких программастов надо в тюрьму сажать. Сия фраза полностью отражает, чего человек стоит, как программист и показывает как абсолютное незнание С++, так и незнание или непонимание Java. И такие люди берутся о чём-то еще рассуждать.

Бугага. Это плюсы так на нервы влияют?

>>Да нунах. А если Font достаточно толстый?

достаточно толстый в данном случае будет FontImpl*, который будет implicitly shared (не знаю как по-русски, зашарен короче)

>>Это дно рендера. В нем все влияет на все.

Хватит уже байки травить

>>Это дно рендера. В нем все влияет на все.

>Хватит уже байки травить

На таком низком уровне приложения гранулярность важнее чем красивые перегрузки.

> На таком низком уровне приложения гранулярность важнее чем красивые перегрузки.

хе-хе-хе. маразм крепчал.

>На таком низком уровне приложения гранулярность важнее чем красивые перегрузки.

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

>>На таком низком уровне приложения гранулярность важнее чем красивые перегрузки.

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

Аналог чего? Перегрузки оператора+ ? Я бы не делал такие мелкие функции.

>// C++ Point c = a + b;

#define DCT_DIV(res,a,b) res.re =a.re*b.re + a.im*b.im) / (b.re*b.re+b.im*b.im); res.im=(a.im*b.re-.re*b.im)/(b.re*b.re+b.im*b.im)

Написал один раз - работает везде. Называется макросы. Безпроблемное повторное использование гарантировано.

> Аналог чего? Перегрузки оператора+ ? Я бы не делал такие мелкие функции.

хе-хе-хе. вот он типичный сишник: невежда и копипаста-гей

>> В исходниках компилятора Scala 2.5.0 167 файлов. В 13-ти из них finally используется. Т.е. почти в 10% файлов.

>Гм, а разве Scala на Java написана? В последний раз, когда я её видел, она была написана на Scala :)

Других исходников для JVM у меня под рукой нет.

К тому же и в Scala, и в Java одинаковый набор средств для работы с исключениями.

>#define DCT_DIV(res,a,b) res.r

> Называется макросы

набор беспомощных кусков говна

>набор беспомощных кусков говна

Нифигасе. Макросы полезная и правильная вещь. И замечу, что очень быстрая.