[C++?] Серьезный вопрос.

> За окно посмотрите -- XXI век на дворе, кому нафиг CL нужен?

Вебдевелоперам. Continuation-based фреймворки - будущее уеба. Я уж не говорю про то, что из лиспового кода хтмл и джава-скрипт автоматически генерится.

>За окно посмотрите -- XXI век на дворе, кому нафиг CL нужен?

В лиспе (/ 1 3) дает абсолютно точный ответ - 1/3. Денежки наверно можно считать чтоб до копейки сходилось. В 1с то наверно фиксированная точка какая-нибудь.

> Практическим воплощениям ООП на С++ приходится обходить сам С++ при помощи препроцессора или MSVC++ - специфичных хаков.

Нет такой вещи, как "общепринятый ООП". Если для вас Qt и COM -- это воплощение ООП, то это ваши личные половые трудности.

> > За окно посмотрите -- XXI век на дворе, кому нафиг CL нужен?

> Вебдевелоперам.

15 лет не был никому нужен, а теперь вдруг все прозреют, выбросят PHP/Ruby/Python и начнут клепать Web-формочки на CL... Понятно, следующий.

>> Практическим воплощениям ООП на С++ приходится обходить сам С++ при помощи препроцессора или MSVC++ - специфичных хаков.

>Нет такой вещи, как "общепринятый ООП".

ООП рождался как чисто практическая методология такой разработки что новый код не ломает старый код. Это востребовано в гуях и прочих навороченных системах где постоянно что-то пишется и в то же время отмирает. Например, посылка сообщений в ObjC или Smalltalk - новый класс примет новый тип сообщения, старый отвергнет. Однако в С++ зачем-то отринули то ради чего все затевалось, т.к требуется перекомпиляция всего после изменения шаблона или добавления виртуальной функции.

> ООП рождался как чисто практическая методология такой разработки что новый код не ломает старый код. Это востребовано в гуях и прочих навороченных системах где постоянно что-то пишется и в то же время отмирает. Например, посылка сообщений в ObjC или Smalltalk - новый класс примет новый тип сообщения, старый отвергнет.

Существует мнение, что ООП пошел с Simula. Сомневаюсь, что там все было именно так.

> Однако в С++ зачем-то отринули то ради чего все затевалось, т.к требуется перекомпиляция всего после изменения шаблона или добавления виртуальной функции.

Т.е. C++ плох потому, что не нравится тараканам в вашей голове.

>В лиспе (/ 1 3) дает абсолютно точный ответ - 1/3.

>(+ (/ 1 3) 0.5)

Или ты предлагаешь напрягать мозг/руки и писать (/ 1 2) или (/ 5 10)?

> После словосочетания "значимые объектные иерархии" уже можно ничего не говорить. Маразм окончательно победил.

Тут любят тыкать в распространённость программ на плюсах. Так вот, практически все программы на С++, которыми я пользуюсь, написаны либо на Qt (мне кажется, что это скорее EDSL, чем просто фреймворк) либо на XPCOM (аналог COM от Netscape). Может, словосочетание не очень удачное, но в чём маразм то?

>> ООП рождался как чисто практическая методология такой разработки что новый код не ломает старый код. Это востребовано в гуях и прочих навороченных системах где постоянно что-то пишется и в то же время отмирает. Например, посылка сообщений в ObjC или Smalltalk - новый класс примет новый тип сообщения, старый отвергнет.

>Существует мнение, что ООП пошел с Simula. Сомневаюсь, что там все было именно так.

Не надо уподобляться tailgunner'у и запутывать историей и терминологией, я отлично знаю что делается откровенно уродливо в Си и какая "замена" была предложена этим хакам в С++. После первого же взгляда на diff C++ - C можно придти к моей интерпретации, не глядя даже на спеки Симулы.

>> Однако в С++ зачем-то отринули то ради чего все затевалось, т.к требуется перекомпиляция всего после изменения шаблона или добавления виртуальной функции.

>Т.е. C++ плох потому, что не нравится тараканам в вашей голове.

У MS видимо такие же тараканы, раз объекты COM делаются с упором на бинарную стабильность. Если нужно что-то расширить то там делается новая версия интерфейса, а старая объявляется "опциональной" и не грузится даже в память пока явно не запрошена через QueryInterface.

>Или ты предлагаешь напрягать мозг/руки и писать (/ 1 2) или (/ 5 10)?

a) Перестань тявкать.
б) 1/2 - три символа.

> Тут любят тыкать в распространённость программ на плюсах. Так вот, практически все программы на С++, которыми я пользуюсь, написаны либо на Qt (мне кажется, что это скорее EDSL, чем просто фреймворк) либо на XPCOM (аналог COM от Netscape).

А практически все программы, которыми я польюсь, требуют либо Windows, либо Linux. Странно, правда? Приложениям требуется инфраструктра. Включать которую в язык -- не есть правильно. Qt и XPCOM предоставляют некую инфораструктуру для создания приложений определенным образом. Если она кого-то не устраивает, ей можно не пользоваться.

Тот же C++ позволил написать и Qt, и FOX Toolkit, и Fltk, и MFC, и ATL. И все нашло свое применение.

Кстати, Qt если и считать EDSL, то разве что External DSL, поскольку обработка DSL делается средствами отдельного приложения.

> Может, словосочетание не очень удачное, но в чём маразм то?

В том, что объектным иерархиям вообще предается какое-то значение. Иерархия, это такой же способ решения задач как и цикл for или рекурсивный вызов функций. Почему-то for не называется значимой конструкцией.

> >Существует мнение, что ООП пошел с Simula. Сомневаюсь, что там все было именно так.

> Не надо уподобляться tailgunner'у и запутывать историей и терминологией, я отлично знаю что делается откровенно уродливо в Си и какая "замена" была предложена этим хакам в С++.

Ага, как обычно, все факты, которые не укладываются в вашу теорию, просто отметаются.

> После первого же взгляда на diff C++ - C можно придти к моей интерпретации, не глядя даже на спеки Симулы.

Не, не можно. Не приходится. Здравый смысл не позволяет.

> У MS видимо такие же тараканы, раз объекты COM делаются с упором на бинарную стабильность.

Это потому, что у COM задача изначально была такая -- позволить бинарному коду (полученному из разных языков программирования) взаимодействовать друг с другом.

К ООП и C++ это все имеет лишь то отношение, что в C++ с помощью ООП можно было с COM-ом работать.

>a) Перестань тявкать.

Не любишь отвечать на неудобные вопросы?

>б) 1/2 - три символа.

7/10 -- четыре

>Нет такой вещи, как "общепринятый ООП"

зато есть понятие избыточности кода. до тех пор, пока ООП в С++ будет требовать использования паттернов Bridge, NVI и Visitor для решения типовых задач построения объектной иерархии, его сложно будет назвать хорошим

>>Нет такой вещи, как "общепринятый ООП"

> зато есть понятие избыточности кода. до тех пор, пока ООП в С++ будет требовать использования паттернов Bridge, NVI и Visitor для решения типовых задач построения объектной иерархии, его сложно будет назвать хорошим

Есть у меня подозрение, что подобные недостатки свойственны большой группе ОО языков со статической типизацией, как то: C++, Java, C#, Scala, Eiffel и, наверное, Ada95-2005.

Было бы интересно увидеть список типовых задач построение объектной иерархии.

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

>Есть у меня подозрение, что подобные недостатки свойственны большой группе ОО языков со статической типизацией, как то: C++, Java, C#, Scala, Eiffel и, наверное, Ada95-2005.

В жабе, насколько я понимаю, vtable строится в рантайме при загрузке класса так что там особой паранои с добавлением новой виртуальной функции в корень нет. Anyway, OO со статической типизацией это вообще бред сивой кобылы. Статическая типизация годится только для изолированных и самодостаточных кусков кода. Например, линкер может девиртуализовать или вообще заинлайнить вызовы если пэкэдж запечатывается и на него ставится метка сборки. Между пакеджами методы должны искаться только динамически по сигнатуре. Для оптимизации можно предоставить разве что взятие адреса обработчика чтобы в дальнейшем дергать его напрямую.

> Anyway, OO со статической типизацией это вообще бред сивой кобылы.

Не обижайтесь, но мне кажется, что вы еще очень молоды. И юношеский максимализм пока не дает вам понять, что в программировании найдется место для мирного сосуществования целой кучи разных концепций. В том числе и статически типизированному ООП (которое есть и в упомянутом здесь неоднократно OCaml-е).

> Практическим воплощениям ООП на С++ (COM и Qt) приходится обходить сам С++ при помощи препроцессора или MSVC++ - специфичных хаков.

Эмо-зомбирование детектед.

Насчет СОМ не скажу, но вот Qt не обходит С++, а расширяет.

> main = print . fact . read . head =<< getArgs

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

случаи, когда мы можем сказать: "суммирование = плюс-редукция" (вспоминая АПЛ), даже в математике не часто встречаются

например, случаи, когда выписывается формула А=В и утверждается, "обе части равенства равны или не имеют смысла одновременно" это редкость. часто одно более общее, или есть некторые условия, отсекающие экзотические случаи, когда А!=В

что касается теорем -- что-то бла-бла-бла тогда и только тогда, когда тра-та-та -- они встречаются, но надо ли их будет выражать в коде?

обычная, имхо, работа программера -- это перефасовка с проверками, и проверки вот так красивенько не записываются

> main = print . fact . read . head =<< getArgs

короче: на практике вся эта красота потонет в деталях, которые совершенно необходимы:

не важно, это функция или целая программа, но тебе придется перефасовать встретившуюся ошибочную ситуацию "не могу вычислить голову, т.к. список пустой" в другую ошибочную ситуацию или в печать сообщения "нет аргумента номер 1".

Забавно, большинство гуру-кодеров все-таки не любят си++.

http://www.gigamonkeys.com/blog/2009/10/16/coders-c++.html

> Забавно, большинство гуру-кодеров все-таки не любят си++.

> http://www.gigamonkeys.com/blog/2009/10/16/coders-c++.html

Некоторые настолько не любят, что превращают С++ в собственные языки программирования (как Джеймс Гослинг с Java) :)

>Было бы интересно увидеть список типовых задач построение объектной иерархии.

иерархия объектов в векторном редакторе, например

>подобные недостатки свойственны большой группе ОО языков со статической типизацией, как то: C++, Java, C#, Scala, Eiffel и, наверное, Ada95-2005.

в той или иной мере - да, однако в С++ в этом смысле грустнее всего

>случаи, когда мы можем сказать: "суммирование = плюс-редукция" (вспоминая АПЛ), даже в математике не часто встречаются

у тебя какая-то странная математика

>обычная, имхо, работа программера

"обычный программер" пишет дейтинги на PHP и доволен жизнью

>не важно, это функция или целая программа, но тебе придется перефасовать встретившуюся ошибочную ситуацию "не могу вычислить голову, т.к. список пустой" в другую ошибочную ситуацию или в печать сообщения "нет аргумента номер 1".

а вот для этого в хаскеле есть монады - чтобы не засорять код этими самыми проверками

>на практике вся эта красота потонет в деталях

твоя аргументация от сообщения к сообщению становится всё более убедительной, да

>> обычная, имхо, работа программера

> "обычный программер" пишет дейтинги на PHP и доволен жизнью

не путай две раные вещи

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

>Qt не обходит С++, а расширяет

обработку ошибок, например, очень расширяет. и обобщённое программирование

нет, ты определённо нетрезв

> а вот для этого в хаскеле есть монады - чтобы не засорять код этими самыми проверками

продемострируй собравшейся публике как оно не засоряет

>кроме того, перепиши свою строчку

делать мне больше нечего :) я, вроде как, никому ничего доказывать не собирался

> у тебя какая-то странная математика

ну тут придется с тобой меряться.

ты что по математике закончил, с какими оценками, или самостоятельно изучил и в каком объеме?

> делать мне больше нечего :) я, вроде как, никому ничего доказывать не собирался

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

а пока что только я продемонстрировал, что в с++ мы пишем то что думаем:

Value<1,-2,0> v(1);

а в хаскеле вынуждены использовать фантомные типы и кодирование целых чисел какими-то скобочными конструкциями

>ну тут придется с тобой меряться.

с этим не ко мне, с этим к доктору :)

singletonHead :: [a] -> a
singletonHead [n] = n
singletonHead []  = error "No argements provided"
singletonHead _   = error "Wrong number of arguments"

main = print . fact . read . singletonHead =<< getArgs 

читаемость исходной строчки изменилась?

> с этим не ко мне, с этим к доктору :)

да, ты мне напомнил -- ты вроде тут кому-то обещал сделать, отсканить и выложить справку о своем психическом здоровье, и как?

> читаемость исходной строчки изменилась?

вопрос поставлен неверно, т.к. задачу *это* не решает

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

твое определение singletonHead не может рассматриваться отдельно от строчки -- т.к. отдельная ценность у singletonHead нулевая. оно -- часть решения задачи, ибо его выхлопы "No argements provided" и "Wrong number of arguments" несут специфику задачи, а отнюдь не специфику операции "взять голову".

как вариант, ты можешь переписать singletonHead так, чтобы подавать ему строки "No argements provided" и "Wrong number of arguments" внутри своей красивой строчки -- тогда я соглашусь, что singletonHead может считаться библиотечной функцией (но тогда "No argements provided" и "Wrong number of arguments" окажутся внутри своей красивой строчки)

не думал, что этот детсад (что есть библиотечное, что задачеспецифичное) придется разъяснять

>да, ты мне напомнил -- ты вроде тут кому-то обещал сделать, отсканить и выложить справку о своем психическом здоровье, и как?

lester'у. я помню. ещё окулиста. пока что не проверился, как только - сразу побегу на ЛОР

>твое определение singletonHead не может рассматриваться отдельно от строчки -- т.к. отдельная ценность у singletonHead нулевая. оно -- часть решения задачи, ибо его выхлопы "No argements provided" и "Wrong number of arguments" несут специфику задачи, а отнюдь не специфику операции "взять голову".

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

>не думал, что этот детсад (что есть библиотечное, что задачеспецифичное) придется разъяснять

Ты вроде не глупый человек, а скатываешься в дешевые демагогические приемы спора.

не думал, что этот детсад

вот и я не думал, что тут детсад

main = print . fact . read . singletonHead =<< getArgs
    where singletonHead [n] = n 
          singletonHead []  = error "No argements provided" 
          singletonHead _   = error "Wrong number of arguments"

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

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

Дислексия?

я же написал:

как вариант, ты можешь переписать singletonHead так, чтобы подавать ему строки "No argements provided" и "Wrong number of arguments" внутри своей красивой строчки -- тогда я _______соглашусь_______, что singletonHead может считаться библиотечной функцией

Но эта библиотечная функция *должна* быть параметризована теми 2 строчками.

>Дислексия?

>я же написал:

>как вариант, ты можешь переписать singletonHead так, чтобы подавать ему строки "No argements provided" и "Wrong number of arguments" внутри своей красивой строчки -- тогда я _______соглашусь_______, что singletonHead может считаться библиотечной функцией

Ты не кипятись. А я написал, "Если есть желание, то можно приспособить для _произвольного_количества_аргументов_. " Текст сообщения можно и возможно стоит вообще не трогать.

>Но эта библиотечная функция *должна* быть параметризована теми 2 строчками.

ммм.. спорный вопрос.

как вариант, ты можешь переписать singletonHead так, чтобы подавать ему строки «No argements provided» и «Wrong number of arguments» внутри своей красивой строчки — тогда я _______соглашусь_______, что singletonHead может считаться библиотечной функцией

singletonHead :: String -> String -> [a] -> a
singletonHead _  _  [n] = n
singletonHead eS _  []  = error eS
singletonHead _  eS _   = error eS

main = print . facs . read . (singletonHead "No arguments provided" "Wrong number of arguments") =<< getArgs

> иерархия объектов в векторном редакторе, например

Никаких сложностей. Проделывал это несколько раз на C++ в 1997-2000 (тогда, по-моему, и книжки по паттернам на русском еще не было). Отлично ложится на C++ с наследованием и шаблонами.

Visitor здесь компенсируется быстродействием, поскольку скорость работы каких-нибудь динамически-типизированных ОО языков в серьезном векторном редакторе будет ниже всякой критики.

> в той или иной мере - да, однако в С++ в этом смысле грустнее всего

Позволю себе не согласиться. Груснее всего в Java. Круче всего, пожалуй, в Eiffel (за счет очень мощного множественного наследования) и в Scala (за счет trait-ов). Но C++ в этом списке далеко не самый последний.

> >Qt не обходит С++, а расширяет

> обработку ошибок, например, очень расширяет. и обобщённое программирование

Не-не-не, без примеров не катит. Чем Qt расширяет обработку ошибок и обобщенное программирование?

>Не-не-не, без примеров не катит. Чем Qt расширяет обработку ошибок и обобщенное программирование?

в том-то и дело, что не расширяет, а замещает. Qt не поощряет использование исключений (исключительные ситуации должны обрабатываться сигналами/слотами), Qt не поощряет использование шаблонов в QObject-ах (MOC с ними не очень дружит). эти пункты вызывают вопросы? в смысле, надо ли мне приводить примеры и давать ссылки на официальную документацию?

>Никаких сложностей

ну пусть будет моим, опять же, субъективным мнением :) спорить в этом треде мне уже надоело

>Груснее всего в Java

ну там по крайней мере рефлекшен есть

>Круче всего, пожалуй, в Eiffel

вот с этим - согласен

и теперь сравним:

main = print . fact . read . (singletonHead "No arguments provided" "Too many arguments") =<< getArgs

#include <iostream> 
#include <boost/lexical_cast.hpp>

int main(int argc, char *argv[]) 
{
    be_equal(argc, 2, "No arguments provided", "Too many arguments");
    std::cout << fact(boost::lexical_cast<int>argv[1]); 
}

в хаскеле красивая строчка стала длинной клизмой

(зато в плюсах нету что-ли связности, т.к. проверяется argc, а юзается argv)

singletonHead :: String -> String -> [a] -> a
singletonHead _  _  [n] = n
singletonHead eS _  []  = error eS
singletonHead _  eS _   = error eS

void be_equal(int a, int b, char* less, char* more) 
{
  if(a<b) { std::cout<<less; exit(); }
  if(a>b) { std::cout<<more; exit(); }
}

хаскельный вариант требует ума для чтения (и того и гляди, с багом) — имхо тут не место матчингу

>в хаскеле красивая строчка стала длинной клизмой

исключительно потому, что ты тщательно этого добивался своими просьбами :) ты удивительно последователен в желании убедить себя в том, что C++ - это хорошо

>зато в плюсах нету что-ли связности

да что ты говоришь :)

> в том-то и дело, что не расширяет, а замещает.

абсурд вообще-то говорил "обходит", что явно мимо кассы

> Qt не поощряет использование исключений (исключительные ситуации должны обрабатываться сигналами/слотами), Qt не поощряет использование шаблонов в QObject-ах (MOC с ними не очень дружит).

Ладно, чем Qt *замещает* исключения и *замещает* шаблоны в QObject-ах? Они придумали свой механизм, которого нет в плюсах для этого?