>>> Просто неудачный пример с прогресс-баром выбрали. Там проще было бы обойтись не callback-функцией, а передачей адреса static-переменной, содержащей необходимые цифири.

>>И что с этой переменной делать? Смысл задачи в отлавливании момента изменения значения.

>Не понял в чём проблема? callback функция передаётся туда, где рисуют прогрессбар. Так? При перерисовке прогрессбара, он будет вызывать callback и перерисовывать себя, в соответствии с теми данными, которые он получил из callback-функции.

Ъ-ООП мышление? Работу делает долгоработающая функция в контексте отдельного от цикла обработки сообщений треда. Она по ходу дела вызывает каллбак. Класс с окном прогрессбара при вызове каллбака обновляет свою модель и запускает рефреш окна в контекст цикла обработки сообщений.

>Не понял в чём проблема? callback функция передаётся туда, где рисуют прогрессбар. Так? При перерисовке прогрессбара, он будет вызывать callback и перерисовывать себя, в соответствии с теми данными, которые он получил из callback-функции. Прогрессбар может не вызывать функцию, которая вернёт значение, а самим заглянуть в переменную и увидеть актуальную информацию.

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

>В таком простом примере видна искусственность (костыльность реализации) объектов в C++ и нецелостность языка, т.к. не любая информация является объектом.

Такой же нецелостностью обладают и D, и Java, и C#, и Scala. Обязательно ли какашками по этому поводу кидаться только в C++?

>Если бы эта переменная была бы настоящим объектом, тогда смысл в передачи callback'ов объекту переменной есть. Но опять таки, а если есть несколько подписчиков, желающих знать об изменении переменной, они все смогут отслеживать изменение переменной?

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

А, кажется понял месседж, пардон.

>Такой же нецелостностью обладают и D, и Java, и C#, и Scala. Обязательно ли какашками по этому поводу кидаться только в C++?

Словоблудие и ГСМ. Там нецелостность не настолько критична. По крайней мере в D не надо привлекать шаблонную метапрограмму из библиотеки чтобы передать функции тупую строчку, а в Джаве инстанс каллбак-интерфейса подберет gc, так что не надо думать кто им владеет. Давай только не будем о субъективности этой "критической величины", ок?

>Там нецелостность не настолько критична. По крайней мере в D...

Попробуй написать в D шаблон, который бы создавал новые объекты своего типа параметра (чтобы он был одинаков и для int, и для экземпляров классов, и для экземпляров структур). Тогда почуствуешь разницу в том, что является объектом, а что нет.

>Давай только не будем о субъективности этой "критической величины", ок?

Только когда здесь абсурд перестанут говорить. Или абсурд перестанет говорить.

>>Там нецелостность не настолько критична. По крайней мере в D...

>Попробуй написать в D шаблон

Даже полное отсутствие метапрограммирования в языке не является недостатком. А вот то что для создания тупого динамического массива надо применять метапрограммирование - это уже не недостаток, это п..ц

>Ъ-ООП мышление?

Именно так :)

>Такой же нецелостностью обладают и D, и Java, и C#, и Scala. Обязательно ли какашками по этому поводу кидаться только в C++?

Да по этому поводу я не кидаюсь какашками конкретно в C++, это черта всех императивных языков с объектами.

Просто мне довольно тяжело понять что же такого стоящего в таких объектах, которые можно использовать столь ограниченным образом. Инкапсуляция, наследование, полиморфизм? Какая из этих фишек не реализуема на чистом C? В исходниках Quake 2 все эти фишки используются в чистом C.

Сомнительно такое ООП, сомнительно. Искажает концепцию.

>>>Там нецелостность не настолько критична. По крайней мере в D...

>>Попробуй написать в D шаблон

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

Это сейчас про D или С++?

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

А где его нужно применять? В C++ или в D?

>>Такой же нецелостностью обладают и D, и Java, и C#, и Scala. Обязательно ли какашками по этому поводу кидаться только в C++?

>Да по этому поводу я не кидаюсь какашками конкретно в C++, это черта всех императивных языков с объектами.

Таки всех? А Ruby со SmallTalk-ом уже функциональными стали, надо полагать.

>Просто мне довольно тяжело понять что же такого стоящего в таких объектах, которые можно использовать столь ограниченным образом. Инкапсуляция, наследование, полиморфизм?

Да.

>Какая из этих фишек не реализуема на чистом C? В исходниках Quake 2 все эти фишки используются в чистом C.

Вручную это нужно делать. Но зачем это делать вручную, если еще лучше это сделает компилятор?

>Сомнительно такое ООП, сомнительно. Искажает концепцию.

C++ вообще-то создавался не для чистоты концепций.

>>>Попробуй написать в D шаблон

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

>Это сейчас про D или С++?

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

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

>А где его нужно применять? В C++ или в D?

Раз констатирован п..ц - значит в плюсах.

>>Просто мне довольно тяжело понять что же такого стоящего в таких объектах, которые можно использовать столь ограниченным образом. Инкапсуляция, наследование, полиморфизм?

>Да.

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

>>Какая из этих фишек не реализуема на чистом C? В исходниках Quake 2 все эти фишки используются в чистом C.

>Вручную это нужно делать. Но зачем это делать вручную, если еще лучше это сделает компилятор?

Потому что С++ - говно.

>>>Просто мне довольно тяжело понять что же такого стоящего в таких объектах, которые можно использовать столь ограниченным образом. Инкапсуляция, наследование, полиморфизм?

>>Да.

>Ни того, ни другого, ни третьего в плюсах нет.

Где ты такую траву берешь?

>И я это убедительно доказал в прошлом плюсосраче.

Ссылочкой не поделишься?

>>И я это убедительно доказал в прошлом плюсосраче.

>Ссылочкой не поделишься?

Можно продолжить - я там написал "Начнем кратко", но обсуждения по существу не последовало.

http://www.linux.org.ru/view-message.jsp?msgid=2804957&page=15#2810231

>Можно продолжить - я там написал "Начнем кратко", но обсуждения по существу не последовало.

>http://www.linux.org.ru/view-message.jsp?msgid=2804957&page=15#2810231

Оно и не могло последовать, поскольку там какая-то муть написана. Особенно про полиморфизм и наследование.

>>Да по этому поводу я не кидаюсь какашками конкретно в C++, это черта всех императивных языков с объектами.

>Таки всех? А Ruby со SmallTalk-ом уже функциональными стали, надо полагать.

Что Вы понимаете в этой фразе под функциональностью?

>>Инкапсуляция, наследование, полиморфизм?

>Да.

Но какой ценой! В виде странного довеска к языку, а не концептуального целого с языком, и не в виде чётко разграниченных двух концепций в одном языке, как например в Objective C.

>>Какая из этих фишек не реализуема на чистом C? В исходниках Quake 2 все эти фишки используются в чистом C.

>Вручную это нужно делать. Но зачем это делать вручную, если еще лучше это сделает компилятор?

Нет, не нужно вручную. Но и такая половинчатая автоматизация тоже не нужна. Автор языка C++ сказал А, но никто так и не дождался логически вытекающего из него Б.

>>Сомнительно такое ООП, сомнительно. Искажает концепцию.

>C++ вообще-то создавался не для чистоты концепций.

В том то и дело. Это главный аргумент против C++, он не создавался концептуально целостным.

Вы меня не понимаете. Я не против C++. Мне не нравится половинчатость этого языка - добавили к C объекты, но каким-то странным образом. Получилось ни два ни полтора. Меня не покидает чувство, что чаще всего лучше выбрать C (единица) или например Java/Python (двойка), или использовать их смесь, но избегать при этом использования C++ (полтора).

Если Вы автор статьи http://eao197.narod.ru/better_language/2_what_i_search.html, то я даже спорить с Вами не собираюсь. Вы в точности выразили все те мысли, которые приходили в голову и мне.

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

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

>Можно продолжить - я там написал "Начнем кратко", но обсуждения по существу не последовало.

>http://www.linux.org.ru/view-message.jsp?msgid=2804957&page=15#2810231

Вот оно! Вот наглядно расписанная костыльность и половинчатость ООП в Си++!

Жму руку!

> Зачем в языке 6(или 9 - смотря как считать) целочисленых типа

Затем, что это не "целочисленные типы", а машинные слова разной разрядности. Язык то для низкоуровневого программирования.

> вообще удивительно, что .НЕТ и Жава переняли этот брейн демедж с их количеством

Доднед - это где операции битовых сдвигов забыли включить?

>Можно продолжить - я там написал "Начнем кратко", но обсуждения по существу не последовало.

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

Адепт ООП-религии в понимании С++? Меня не волнует теория - что такое полиморфизм например. Меня волнует как я могу применить полиморфизм чтобы увеличить продуктивность труда по сравнению с Си драматическим образом. Массивы из указателей на функции, так называемые vtable которые обеспечивают полиморфизм в С++ это не более чем синтаксический сахар, который по факту производительность труда не увеличивает. Городить новый язык ради передачи неявного параметра this не стоило.

>>Таки всех? А Ruby со SmallTalk-ом уже функциональными стали, надо полагать.

>Что Вы понимаете в этой фразе под функциональностью?

Противоположность императивности.

>Но и такая половинчатая автоматизация тоже не нужна. Автор языка C++ сказал А, но никто так и не дождался логически вытекающего из него Б.

Не нужно говорить за всех. Если кто-то ждал Б -- это это его проблемы. Но есть и такие, кто не ждал.

>>C++ вообще-то создавался не для чистоты концепций.

>В том то и дело. Это главный аргумент против C++, он не создавался концептуально целостным.

Зато пригодным к практическому применению в широком спектре задач. В отличии от концептуально целостного SmallTalk. Или в еще большем отличии от очень целостного Eiffel, который из-за своей концептуальности так и не смог стать широкоиспользуемым.

>Меня не покидает чувство, что чаще всего лучше выбрать C (единица) или например Java/Python (двойка), или использовать их смесь, но избегать при этом использования C++ (полтора).

Видите ли, понятия "чаще" или "реже" становятся совершенно бесполезными когда нужно решить конкретную задачу, на конкретном железе, с конкретными требованиями по производительности. И тут оказывается, что на C++ ее можно решить в текущих условиях. А вот на Java+Python или Eiffel, или Ada -- нет. Причем главным препятствием для этих языков будут вовсе не их языковые свойства, а наличие/стоимость инструментов, подготовленных разработчиков и прочей инфраструктуры.

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

>Адепт ООП-религии в понимании С++?

Выходит, что так.

>Меня не волнует теория - что такое полиморфизм например.

Т.е. что такое полиморфизм не в курсе, но в C++ его точно нет. "Булгакова не читал, но осуждаю" (С)

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

Интересно, как можно применить то, о чем ты не знаешь?

>Массивы из указателей на функции, так называемые vtable которые обеспечивают полиморфизм в С++ это не более чем синтаксический сахар, который по факту производительность труда не увеличивает

Почитай для общего развития Гради Буча и Бертрана Мейера. Может тогда и производительность увеличится.

>>>Таки всех? А Ruby со SmallTalk-ом уже функциональными стали, надо полагать.

>>Что Вы понимаете в этой фразе под функциональностью?

>Противоположность императивности.

Функциональность и императивность - это не противоположности, это парадигмы, подходы к программированию. Если они противоположны, тогда получается ОО-парадигма противоположна им обоим? Нет - это разные вещи, но не противоположные.

>>Но и такая половинчатая автоматизация тоже не нужна. Автор языка C++ сказал А, но никто так и не дождался логически вытекающего из него Б.

>Не нужно говорить за всех. Если кто-то ждал Б -- это это его проблемы. Но есть и такие, кто не ждал.

Это говорит о глупости этих людей. Это как сидеть на стуле с двумя ножками - нужно держать равновесие. Третьей ножки предусмотрено в этом стуле не было. К чему тогда вообще были сделаны эти две ноги? Чтобы сидеть повыше, но постоянно держать равновесие?

>Зато пригодным к практическому применению в широком спектре задач. В отличии от концептуально целостного SmallTalk. Или в еще большем отличии от очень целостного Eiffel, который из-за своей концептуальности так и не смог стать широкоиспользуемым.

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

>Видите ли, понятия "чаще" или "реже" становятся совершенно бесполезными когда нужно решить конкретную задачу, на конкретном железе, с конкретными требованиями по производительности. И тут оказывается, что на C++ ее можно решить в текущих условиях. А вот на Java+Python или Eiffel, или Ada -- нет. Причем главным препятствием для этих языков будут вовсе не их языковые свойства, а наличие/стоимость инструментов, подготовленных разработчиков и прочей инфраструктуры.

Бл..дь, как можно с Вам разговаривать? Вы узко мыслите. Почему вместо C++ нужно обязательно выбрать ТОЛЬКО ОДИН язык? Нужна производительность? Горячие точки программы можно написать на C. Нужна гибкость и удобство? Сложную логику лучше реализовать на Java/Python.

>На форуме хорошо рассуждать, какое C++ говно и чем он кому не нравится. На практике же заменить C++ на какой-нибудь D или OCaml можно в очень редких случаях.

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

> А если для замены нужно переписать несколько сот тысяч строк работающего C++ кода (а то и больше), то это уже вообще не реально.

Если что написано, то менять не будет никто. Подумайте о НОВЫХ проектах, где можно начинать с чистого листа.

>>Меня не волнует теория - что такое полиморфизм например.

>Т.е. что такое полиморфизм не в курсе, но в C++ его точно нет. "Булгакова не читал, но осуждаю" (С)

По мне так быть "не в курсе полиморфизма" это отвечать в духе тупого зубрилы типа "взаимозаменяемость объектов с одинаковым интерфейсом". Это точно быть не в курсе. То что с помощью write() можно писать в tty, сокет или файл - это полиморфизм?

>>Массивы из указателей на функции, так называемые vtable которые обеспечивают полиморфизм в С++ это не более чем синтаксический сахар, который по факту производительность труда не увеличивает

>Почитай для общего развития Гради Буча и Бертрана Мейера.

GoF читал, не впечатлило. Вот SQL по сравнению с навигационным способом произизводительность труда точно увеличивает, это да.

> Потому что С++ - говно. > Absurd (*) (11.09.2008 12:20:23)

А вы чем пользуетесь и для каких задач?

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

Тогда Лисп - это п..ц. В некоторых Лиспах даже рекурсивные функции, и те определяются только средствами метапрограммирования.

В общем для меня все возражения апологетов C++ сводятся к таким словам:

1. да костыльно, но зато лучше чем ничего,
2. да какашка, но зато рабочая,
3. да, много лишнего, но это можно не использовать,
4. да, кое чего не хватает, но можно сделать вручную,
5. негибко, но зато быстро работает,
6. на нём много написано, так что никуда не денетесь,
7. да неудобно, но самураи трудностей не боятся.

> В общем для меня все возражения апологетов C++ сводятся к таким словам:

Эти же апологеты предлагали назвать вам свой "божественный" язык без изъянов.

>Эти же апологеты предлагали назвать вам свой "божественный" язык без изъянов.

Они монотеисты, я - нет.

>Нет - это разные вещи, но не противоположные.

Ну пусть они будут не противоположными, а просто разными (хотя я и сомневаюсь, что икапсуляция хорошо дружит с неизменяемостью данных в функциональном подходе). Тем не менее, вы сказали, что нецелостность -- это "черта всех императивных языков с объектами". Императивные языки Ruby и SmallTalk по вашему так же обладают подобной не целостностью?

>>Не нужно говорить за всех. Если кто-то ждал Б -- это это его проблемы. Но есть и такие, кто не ждал.

>Это говорит о глупости этих людей. Это как сидеть на стуле с двумя ножками - нужно держать равновесие. Третьей ножки предусмотрено в этом стуле не было. К чему тогда вообще были сделаны эти две ноги? Чтобы сидеть повыше, но постоянно держать равновесие?

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

>Почему вместо C++ нужно обязательно выбрать ТОЛЬКО ОДИН язык? Нужна производительность? Горячие точки программы можно написать на C. Нужна гибкость и удобство? Сложную логику лучше реализовать на Java/Python.

Нужно все сразу, представляете? Это, может быть, в GUI-евом приложении, не сложном, можно пару-тройку узких мест переписать на C. А в другом приложении, каком-нибудь банковском процессинге, обрабатывающем тысячи транзакций в секунду на одном узле кластера создавать макароны из фрагментов кода на C/Java/Python может быть гораздо хуже, чем делать все на одном языке.

>Подумайте о НОВЫХ проектах, где можно начинать с чистого листа.

Последний раз я делал проект с чистого листа на Ruby ровно четыре года назад. А предпоследний раз -- в 2001-м году (из-за смены места работы). С тех пор все новые проекты переиспользовали части ранее написанных проектов.

> А в другом приложении, каком-нибудь банковском процессинге, обрабатывающем тысячи транзакций в секунду на одном узле кластера создавать макароны из фрагментов кода на C/Java/Python может быть гораздо хуже, чем делать все на одном языке.

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

>> Потому что С++ - говно. > Absurd (*) (11.09.2008 12:20:23)

>А вы чем пользуетесь и для каких задач?

Поддерживаю пару проектов на С++. Си-подмножество слишком сурово хотя пользуюсь в последнее время только им, т.к дешево, надежно и сердито, от С++ - куча гиморроя и ничего толкового. Для фана - на питоне и баше.

>То что с помощью write() можно писать в tty, сокет или файл - это полиморфизм?

Типа того. Только из этого условия не ясно, будет ли это статический полиморфизм (compile-time) или же динамический (run-time).

>>Почитай для общего развития Гради Буча и Бертрана Мейера.

>GoF читал, не впечатлило.

GoF -- это некие часто встречающиеся приемы применения ООП. Но если это все, что ты читал про ООП, тогда все становится понятно.

>Императивные языки Ruby и SmallTalk по вашему так же обладают подобной не целостностью?

С Ruby не знаком. Но в SmallTalk нет императивности как таковой. Там любая сущность является объектом, отправляющим сообщение. Выражение a=5-1 означает, что объекту 5 отправляется сообщение - с аргументом-объектом 1, результирующий объект будет отправлен объекту a как аргумент сообщения =. Где здесь императивность?

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

А не лучше ли всё-таки для этого встать на те же две ноги, но уже собственные? Или всё-таки приделать к стулу ещё одну-две ноги?

>А в другом приложении, каком-нибудь банковском процессинге, обрабатывающем тысячи транзакций в секунду на одном узле кластера создавать макароны из фрагментов кода на C/Java/Python может быть гораздо хуже, чем делать все на одном языке.

Если у Вас есть кластер, почему бы низкую производительность сервера не компенсировать добавив к нему побольше узлов? Может оказаться, что стоить они будут дешевле труда программиста на C++?

И потом, неужели вы думаете, что используете в таком банковском процессинге только один язык? Assembler, SQL, C, Java - минимальный набор. Почему отказываться нужно ещё от одного языка, если он не будет пыжиться занять чужие ниши, а просто будет хорошо решать задачи в своей предметной области?

Вы точно о банковском процессинге знаете? Я вижу там чаще всего названные мной языки, плюс ещё regexp, HTML, PHP.

>С тех пор все новые проекты переиспользовали части ранее написанных проектов.

Это утверждение как нибудь доказывает качество C++? Только это:
>6. на нём много написано, так что никуда не денетесь,

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

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

Мы, например, используем C++ для ядра, Ruby для обслуживания процессов, администрирования и отчетов. Плюс еще свой маленький язычок в одном из C++ных компонентов для правил маршрутизации (интерпритатор на C++). Хотя это и не банковская система.

Но вот выгод от того, чтобы в один процесс помещать код на C++ и Ruby/Lua я так и не нашел -- лишней головной боли гораздо больше.

>Сейчас нашел только следы -- ссылка на то, что Delphi 2.0 давала 120000 строк в минуту. Уже без подтверждений, увы :-(.

"По оценочным материалам фирмы Borland, скорость работы компилятора Delphi составляет 350000 строк в минуту. Оставив на стороне все рекламные трюки, можно сказать, что компилятор Delphi, возможно, самый быстрый Windows-компилятор в мире."
Цитата из книги "Руководство разработчика баз данных в Dephi(тм) 2", Кен Хендерсон, 1996. — с.16. в переводном издании — К.: Диалектика, 1996.

>Но вот выгод от того, чтобы в один процесс помещать код на C++ и Ruby/Lua я так и не нашел -- лишней головной боли гораздо больше.

Опять узкое мышление? Зачем помещать их в один процесс? Они хорошо работают как взаимодействующие процессы.

> Выражение a=5-1 означает, что объекту 5 отправляется сообщение - с аргументом-объектом 1, результирующий объект будет отправлен объекту a как аргумент сообщения =. Где здесь императивность?

А если взять менее вырожденный пример? Например window open?

>Если у Вас есть кластер, почему бы низкую производительность сервера не компенсировать добавив к нему побольше узлов? Может оказаться, что стоить они будут дешевле труда программиста на C++?

Может. А может и нет. Это еще будет зависеть от стоимости дополнительных лицензий на 3rd party ПО за каждый новый узел кластера.

>Вы точно о банковском процессинге знаете? Я вижу там чаще всего названные мной языки, плюс ещё regexp, HTML, PHP.

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

Однако, если называть SQL, regex и HTML гордым словом "языки программирования", то да, одним C++ мы уже давно не ограничиваемся.

>>Но вот выгод от того, чтобы в один процесс помещать код на C++ и Ruby/Lua я так и не нашел -- лишней головной боли гораздо больше.

>Опять узкое мышление?

Нет, просто я вас понимал так, что несколько языков нужно использовать внутри одного процесса. Такой подход, временами, дает хорошие результаты. Например, есть такой архиватор -- FreeArc. Его автор говорит, что он написан на Haskel (обертка) и C++ (алгоритмы сжатия).

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

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

Более того - части таких систем пишут специалисты, которые не хотят и не должны знать C++ или Java, и чьё время слишком дорого стоит, чтобы тратить его на низкоуровневую возню. Для них и пишут специализированные DSL, на которых они свои многоумные математические идеи выражают и отлаживают.

> Но вот выгод от того, чтобы в один процесс помещать код на C++ и Ruby/Lua я так и не нашел -- лишней головной боли гораздо больше.

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

>>То что с помощью write() можно писать в tty, сокет или файл - это полиморфизм?

>Типа того. Только из этого условия не ясно, будет ли это статический полиморфизм (compile-time)

Если не подходит динамический полиморфизм, то не подойдет никакой. Всякие извращения с шаблонами С++ - бесполезный унылый мудизм.

>>GoF читал, не впечатлило.

>GoF -- это некие часто встречающиеся приемы применения ООП. Но если это все, что ты читал про ООП, тогда все становится понятно.

Из всех талмудов по ООП создается впечатление что пытаются продать муху по цене слона. Наделяют удивительным волшебным смыслом этот неявный указатель this, как будто он совешил революцию, опровергнув классическое определение "алгоритмы+структуры данных". Одна вода короче. В GoF хотя бы приведены красивые инженерные решения и почитать интересно.

>А если взять менее вырожденный пример? Например window open?

Объекту Window будет оправлено сообщение open. Сложно было додуматься?

>Может. А может и нет. Это еще будет зависеть от стоимости дополнительных лицензий на 3rd party ПО за каждый новый узел кластера.

К языкам это не имеет никакого отношения.

>Однако, если называть SQL, regex и HTML гордым словом "языки программирования", то да, одним C++ мы уже давно не ограничиваемся.

Ну ладно, не языки программирования, а просто - специализированные языки. regex между прочим заменит сотни эквивалентных строк на C++, SQL - тоже, HTML заменяет ручное конструирование объектной модели документа (DOM).

Суть всё равно в том, что C++ не универсален и часто для конкретных подзадач лучше выбирать другие языки. C++ не делает ничего уникального, чего бы не мог заменить какой-то другой более специализированный и концептуально БОЛЕЕ ЧИСТЫЙ язык.

> Зачем помещать их в один процесс?

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

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

Re^6: Страуструп о будущем семантических средств разработки с комментариями

>>Ну я так полагаю, что говоря "в qt" подразумевается "со всеми классами, как чисто c++-ными, так и с qobject-ными расширениями"

> Вопрос был "используется ли в Qt множественное наследование". Ответ --- да.

> А вопрос "можно ли в Qt наследовать от двух потомков QObject" ничем не отличается от вопроса "можно ли в С++ наследовать от двух потомков одного класса". Краеугольный "ромб" сиплюсплюса :)

Ладно, уел.

> Сделали они виртуальное наследование или нет --- хз, не проверял, ибо как-то не нужно было. Обойти необходимость наслодования от двух потомков QObject --- как два пальца об асфальт, даже напрягаться не потребуется. Более того: само наличие такой необходимости как бы намекает на ошибку в проектировании. Имхо.

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

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

Наконец-то мне полегчало: я донёс мысль, которую и пытался объяснить.

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

>Из всех талмудов по ООП создается впечатление что пытаются продать муху по цене слона. Наделяют удивительным волшебным смыслом этот неявный указатель this, как будто он совешил революцию, опровергнув классическое определение "алгоритмы+структуры данных". Одна вода короче. В GoF хотя бы приведены красивые инженерные решения и почитать интересно.

Вот-вот, this и таблица виртуальных методов (то бишь указателей на функции, которые обрабатывают this и ещё-какие-то аргументы), хранимая вместе с данными.

> C++ не делает ничего уникального

4.2. C++ уникален, поскольку никакой другой язык не может столь же легко пользоваться библиотеками, написанными на C++. Там, где нужно использовать такие библиотеки, альтернатив C++ просто нет (и не может быть в силу отсутствия стандарта на ABI). Даже тот же PyQt сделан откровенно через задницу, и использует для генерации биндингов парсер от доброй половины C++.

Re^4: Страуструп о будущем семантических средств разработки с комментариями

>>>> Мой пойнт был в том, что компилятор Delphi наглядно показал, что код аналогичного качества можно собирать за многократно меньшее время. Выходит, технический изъян в Си с плюсам.

>>> Главное корость разработки, а не скорость сборки. Кормить лишнего программиста дороже чем поставить выделеный сервак для найтли билдов. Неужели я должен объяснять такому опытному человеку, как Вы, прописные истины? К тому же компиляторы Ц значительно шустрее крестовых. Если Вы располагаете тестами о реальном значительном превосходстве в скорости компиляции Делфи програм перед их Цшнами аналогами будет очень интересно глянуть.

>> Какими на..й тестами? Просто тупо запускаешь компиляцию и получаешь бинарь за время, различающееся раз в 30. У паскаля необычайно быстрые компиляторы.

> Пример: Eclipse и OpenOfice.

> Сборка Eclipse из исходников (eclipse-sourceBuild-srcIncluded-3.3.2.zip, 89.8МБ) занимает где-то 15...20 минут.

> Сборка OpenOffice из исходников (OOo_OOH680_m17_source.tar.bz2, 273.2МБ) занимает в среднем 5 часов.

> Разница в объёме исходников в три раза, а разница времени на сборку — 15 раз.

> Ещё: Sun JDK 1.5 из исходников собирался за полтора часа чистого времени. Более новый Sun JDK 1.6 собирается гораздо быстрее — 30...40 минут. Видимо, появились оптимизации в схеме сборки и опциях компиляции.

Как хорошо ты перескочил со сравнения скорости компиляции delphi и c на сравнение скорости компиляции c++ и java. Думал я за поскипанным не замечу?

>> C++ не делает ничего уникального

>4.2. C++ уникален, поскольку никакой другой язык не может столь же легко пользоваться библиотеками, написанными на C++. Там, где нужно использовать такие библиотеки, альтернатив C++ просто нет (и не может быть в силу отсутствия стандарта на ABI). Даже тот же PyQt сделан откровенно через задницу, и использует для генерации биндингов парсер от доброй половины C++.

См. мой список стандартных отмазок апологетов C++ выше по треду:
>6. на нём много написано, так что никуда не денетесь,

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

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

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

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

Продолжать?