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

>>Список или ссылку в студию (тема интересная).

> Я Вам сам расскажу:

> 1) Угребищная система стандартных типов. Зачем в языке 6(или 9 - смотря как считать) целочисленых типа и 2 с плавающей точкой? Нельзя было сделать по одному?

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

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

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

И что, будет создан новый объект или же будет модифицированно состояние уже существующего?

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

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

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

Я где-нибудь утверждал обратное?

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

http://www.research.att.com/~bs/abstraction-and-machine.pdf

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

Все зависит от того как moc реализует сигналы/слоты. Указатель на метод класса с множественным наследованием обычно бинарно несовместим с указателем на метод класса с единичным наследованием, и если Qt использует что-то типа union { (QObject::*)(...), unsigned char хак[ширина указателя на метод с единичным наследованием данной архитектуре]} то может и не работать.

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

>>Только с++ объектно-ориентированный язык, соответственно и ситуаций с необходимостью передавать callback'и для перерисовки чего-либо должно быть меньше.

> Да, давай писать по классу на каждый калбэк.

А тебя не пугает, что в Божественной Жабе надо писать по интерфейсу на каждое замыкание? Аналогично ведь...

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

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

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

А вот это, кстати, очень глупо. Надо прогрессбар обновлять не на каждое изменение значения переменной, а не чаще чем раз в n миллисекунд. Иначе попробуй отобразить прогрессбар от i в следующем примере:

for (long i=0; i < maxlong; ++i) {
upadtevar(i);
}

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

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

Это не отмазка, это факт. Хоть покрасней и лопни, а все равно ведь никуда унаследованный код не денется.

> Продолжать?

А что тебе тут не нравится? Есть код на каком либо языке (кроме разве что C, Java и языков .NET) - изволь им же пользоваться и дальше. Мало какой язык можно адекватно дёргать из другого языка, так что каждый почти в этом смысле уникален и незаменим.

>>>Только с++ объектно-ориентированный язык, соответственно и ситуаций с необходимостью передавать callback'и для перерисовки чего-либо должно быть меньше.

>> Да, давай писать по классу на каждый калбэк.

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

Достает, да. Но в жабе этот недостаток скомпенсирован анонимными классами и gc.

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

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

Детали как это делается на самом деле см. в google. Я просто пояснил идею чистого ООП, без примеси явной императивности или функциональности.

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

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

Гик, перелогинься :)

>Это не отмазка, это факт. Хоть покрасней и лопни, а все равно ведь никуда унаследованный код не денется.

Ах..енный аргумент, говорящий ВСЁ о превосходстве языка C++ над остальными языками.

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

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

Да, задачи не самые сложные. Но в моем случае Ruby/Lua не прокатили потому, что требовалось слишком много обвязочного кода для доступа из Ruby/Lua скрипта к данным C++ ядра. И при этом сами Ruby/Lua скрипты оказывались "зашумлены" синтаксическими конструкциями самого языка. Поэтому проще оказалось сделать свой Lisp-подобный язык, в котором правила предметной области записываются с меньшим количеством "шума".

> Ах..енный аргумент, говорящий ВСЁ о превосходстве языка C++ над остальными языками.

Это не "превосходство", это неизбежность необходимости его дальнейшего использования.

> требовалось слишком много обвязочного кода для доступа из Ruby/Lua скрипта к данным C++ ядра

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

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

Про Гринспуна напоминать? :)

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

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

>Детали как это делается на самом деле см. в google. Я просто пояснил идею чистого ООП, без примеси явной императивности или функциональности.

Немного не угадал оказывается, объекты создаются посылкой сообщения "новый" классу. То есть класс тоже по сути является объектом (подразумеваемого класса "классы").

>> требовалось слишком много обвязочного кода для доступа из Ruby/Lua скрипта к данным C++ ядра

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

При этом создание сложных структур данных со списками, множествами и map-ами на C -- это то еще геморой.

>Про Гринспуна напоминать? :)

:)

Зато работает.

>Это не "превосходство", это неизбежность необходимости его дальнейшего использования.

Обсуждайте неизбежность дальше, я не верю в судьбу.

Зная о том, что смерть неизбежна, я стараюсь найти хорошее в жизни.

Зная о том, что C++ неизбежен, я стараюсь наслаждаться хорошими языками.

> При этом создание сложных структур данных со списками, множествами и map-ами на C -- это то еще геморой.

А я очень люблю волшебные слова extern "C" { всё-API-тут-и-не-колышэд }

Потроха на C++, а экспортируется голый Си. Кстати, этот подход очень дисциплинирует, API чище и понятней получаются, чем при злостном злоупотреблении возможностями C++.

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

>Немного не угадал оказывается, объекты создаются посылкой сообщения "новый" классу. То есть класс тоже по сути является объектом (подразумеваемого класса "классы").

Я подразумевал вот какой сценарий:

w = Window create title: 'Title' state: HIDDEN.

w open state: MAXIMIZE.

Здесь объекту w посылается сообщение (open), которое модифицирует состояние объекта w. Но объект остается тем же самым. Тогда как в функциональном подходе нужно было получить новый объект w' с новым состоянием.

Disclaimer: за точность SmallTalk-овского синтаксиса не ручаюсь.

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

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

> Все зависит от того как moc реализует сигналы/слоты. Указатель на метод класса с множественным наследованием обычно бинарно несовместим с указателем на метод класса с единичным наследованием, и если Qt использует что-то типа union { (QObject::*)(...), unsigned char хак[ширина указателя на метод с единичным наследованием данной архитектуре]} то может и не работать.

Оно их вообще реализует через char* и strcmp, емнип.

>Я подразумевал вот какой сценарий:

>w = Window create title: 'Title' state: HIDDEN.

>w open state: MAXIMIZE.

>Здесь объекту w посылается сообщение (open), которое модифицирует состояние объекта w. Но объект остается тем же самым. Тогда как в функциональном подходе нужно было получить новый объект w' с новым состоянием.

>Disclaimer: за точность SmallTalk-овского синтаксиса не ручаюсь.

О выражении a=5-1:
Там парадигма очень непривычная для императивщиков. a - это одна из ссылок на объект, 5 и 1 - это реально существующие объекты. Они существуют до тех пор, пока на них кто-то ссылается. Каждое число будет существовать в системе в единственном экземпляре. То есть если две ссылки a и b на объект 5, то сам объект 5 будет существовать в памяти в единственном экземпляре, до тех пор пока на него есть хоть одна ссылка.

В названном вами случае w - это ссылка на объект, который будет создан. Затем по этой ссылке будут отправляться сообщения реально существующему в памяти объекту. Сам объект будет удалён как только ссылке w будет отправлено сообщение = с экземпляром нового объекта. То есть ссылка - тоже объект!

>В названном вами случае w - это ссылка на объект, который будет создан. Затем по этой ссылке будут отправляться сообщения реально существующему в памяти объекту. Сам объект будет удалён как только ссылке w будет отправлено сообщение = с экземпляром нового объекта.

Я говорил о другом: при получении сообщения open объект, на который указывает w изменяется. И это изменение будет видно через все другие ссылки на данный объект.

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

Именно в этом, имхо, и состоит главное отличие императивного подхода от функционального.

>То есть ссылка - тоже объект!

Сильно в этом сомневаюсь.

И ещё дополню себя. Ссылка может принимать единственное сообщение = с параметром, который является объектом любого типа. Чтобы принудительно удалить объект из памяти, нужно отправить ссылке сообщение = null. null - это "несуществующий" объект, его отсутствие.

>>То есть ссылка - тоже объект!

>Сильно в этом сомневаюсь.

Во всяком случае она так выглядит для программиста (ей можно отправлять единственное сообщение = с параметром - объектом любого типа), для интерпретатора она конечно может являться чем-то другим.

>Я говорил о другом: при получении сообщения open объект, на который указывает w изменяется. И это изменение будет видно через все другие ссылки на данный объект.

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

По сути так и есть. А в выражении a=b=5 будет существовать только один объект 5 и две ссылки на него. Если после этого сделать a=4, то объект 5 останется в памяти, но количество ссылок на него уменьшится на одну, будет создан новый объект 4 и он будет доступен по ссылке a.

Очень красивая и чисто реализованная концепция ООП. Жаль только производительность у таких программ сильно ниже. В Objective C попытались собрать языки SmallTalk и C, явно проведя границу между императивным и ОО-подходами. В C++ это не так и выглядит очень костыльно, за что часто и критикуется.

>В C++ это не так и выглядит очень костыльно, за что часто и критикуется.

Эти костыли есть не только в C++, но и в D, в C#, в Java, в Scala: там есть value-типы (int, например) и reference-типы, которые уже являеются объектами. Даже в Eiffel в угоду эффективности были добавлены extended типы (которыми int-ы и являются). Так что ругать за это только C++ довольно странно.

Зато в C++ все значения являются first-class citizens: вы можете параметризовать любой шаблон любым типом и шаблону будет безразлично что это за тип. В отличии, например, от D, где в шаблоне нельзя просто написать:

template(T) { T t = T(); }

т.к. в случае value-типа это будет одна семантика, а в случае reference-типа -- совсем другая (емнип, вообще недопустимая языком).

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

Ну ты и дурачек...

дурачОк

>Эти костыли есть не только в C++, но и в D, в C#, в Java, в Scala: там есть value-типы (int, например) и reference-типы, которые уже являеются объектами. Даже в Eiffel в угоду эффективности были добавлены extended типы (которыми int-ы и являются). Так что ругать за это только C++ довольно странно.

Да, языкам, являющимися идейными продолжателями C++ присущи те же недостатки. Только в новых языках есть, например, ссылки (вместо указателей), сборка мусора, переменные с динамическим типом. Это всё черты более развитых ООЯ. Вот что имеется в виду про А и Б, в C++ сказано только A, а Б никто так толком и не дождался.

>Зато в C++ все значения являются first-class citizens: вы можете параметризовать любой шаблон любым типом и шаблону будет безразлично что это за тип. В отличии, например, от D, где в шаблоне нельзя просто написать:

>template(T) { T t = T(); }

>т.к. в случае value-типа это будет одна семантика, а в случае reference-типа -- совсем другая (емнип, вообще недопустимая языком).

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

Оллстарс тред: капитан Очевидность, граммар наци...

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

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

> Ну ты и дурачек...

Точно стукнутый.

Ruby, Smalltalk... Какая-то академическая болтовня пошла.

К тому же, что вы зациклились на ООП? Например, generic программинг - это совсем не ООП. Тот же STL написан _не_ в ООП стиле. CPP позволяет писать программы в самых разных стилях, и это его плюс.

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

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

>Ruby, Smalltalk... Какая-то академическая болтовня пошла.

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

>CPP позволяет писать программы в самых разных стилях, и это его плюс.

+100

>Вообще, писать программы только в одном стиле - полнейшая глупость. Даже обсуждать смешно.

+1000

Я про превосходство, вообще-то, никогда и не говорил. Терпеть не могу C++, ещё где-то с начала 90х его терпеть не могу, всегда предпочитал Common Lisp и чистый C, но как писал на C++, так и пишу, и писать буду. Потому что есть необходимость, и никуда и никогда она не денется.

>пионерской "говно"

Извините, но если мне надо привлекать метапрограмму работающую во время компиляции для того чтобы просто вернуть из функции тупую строчку (std::string), то действительно говно.

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

По-моему ты никому это не доказал, кроме себя. Что само по себе странно, ибо зачем что-то доказывать самому себе?

Лично мне ты что в прошлый, что в этот раз убедительно доказал, что на деле ты знаешь куда меньше, чем на словах. Ты не умеешь программировать на С++, ты умеешь дёргать знакомые шаблоны из boost и stl и орать, какое говно С++ раз в нём есть такое говно, как boost.

>>пионерской "говно"

>Извините, но если мне надо привлекать метапрограмму работающую во время компиляции для того чтобы просто вернуть из функции тупую строчку (std::string), то действительно говно.

Я, наверное, уже это говорил, но повторюсь: твой никнейм удивительно точно отражает содержание твоих сообщений.

>>>пионерской "говно"

>>Извините, но если мне надо привлекать метапрограмму работающую во время компиляции для того чтобы просто вернуть из функции тупую строчку (std::string), то действительно говно.

>Я, наверное, уже это говорил, но повторюсь: твой никнейм удивительно точно отражает содержание твоих сообщений.

Давай разобьем на две позиции:

1) Мне надо привлекать метапрограмму работающую во время компиляции для того чтобы просто вернуть из функции тупую строчку? Я так понимаю мне надо использовать std::string, а это typedef для шаблона std::basic_string<...> где параметрами являются как минимум аллокатор и char_traits.

2) Является ли говном тот язык где надо привлекать метапрограмму работающую во время компиляции для того чтобы просто вернуть из функции тупую строчку?

Дурилка, а если в кресты добавят еще tiny int, small int, big int, huge int и их unsigned аналоги то С++ вообще мегаязыком станет, да? С головой дружишь?

>1) Мне надо привлекать метапрограмму работающую во время компиляции для того чтобы просто вернуть из функции тупую строчку? Я так понимаю мне надо использовать std::string, а это typedef для шаблона std::basic_string<...> где параметрами являются как минимум аллокатор и char_traits.

Ну а вот и очередное подтверждение словам из моего предыдущего сообщения %)

Пришла пора Капитану Очевидность сказать своё слово: "строки в С++" != "std::string".

Очередной ой?

Да, кстати: скажи-ка, дядя, ведь недаром^W^Wчто "надо" (не зря в кавычках, кстати) сделать в чистом С "чтобы вернуть из функции тупую строчку"? Это такой то-о-о-оненький типа намёк....

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

>>> Да, давай писать по классу на каждый калбэк.

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

> Достает, да. Но в жабе этот недостаток скомпенсирован анонимными классами и gc.

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

Чего же тебя так плющит от std::string? В контексте C++ это просто тип данных. И всего-то. И, пожалуйста, расшифруй свои высокопарные слова о каком-то метапрограммировании. Только по делу, без болтовни.

>>1) Мне надо привлекать метапрограмму работающую во время компиляции для того чтобы просто вернуть из функции тупую строчку? Я так понимаю мне надо использовать std::string, а это typedef для шаблона std::basic_string<...> где параметрами являются как минимум аллокатор и char_traits.

>Пришла пора Капитану Очевидность сказать своё слово: "строки в С++" != "std::string".

Принять const char* (Тип строкового литерала в С++) можно, вернуть нельзя. Можно аллоцировать результат в куче под честное слово клиента кода что он его удалит. Можно принять out-параметром char* указатель на буффер + длину буфера и вернуть ошибку если не влезло.

И при этом кто-то тут обсуждает ООП и generic programming, да.

>Принять const char* (Тип строкового литерала в С++) можно, вернуть нельзя. Можно аллоцировать результат в куче под честное слово клиента кода что он его удалит. Можно принять out-параметром char* указатель на буффер + длину буфера и вернуть ошибку если не влезло.

Ой, надо же! Правда что ли? Спасибо, конечно, но ты опоздал лет эдак.... хм.... сильно, короче, опоздал.

>И при этом кто-то тут обсуждает ООП и generic programming, да.

Просто этого "кого-то" не переклинило на std::string и const char*, как некоторых, и этот "кто-то" не лезет в std и boost на каждый элементарный чих, как некоторые. Снова убеждаюсь в своей правоте в теперь уже пред-предыдущем посте.... =\

>> ИМХО, синтаксис - дело десятое, разумная модель раздельной компиляции в BP - вот главное

> Дыкть, в Аде, небось, не хуже была.

Про скорость компилятора Ады ничего не знаю, но Ада (как и Си++, кстати) - гораздо более сложный язык, чем Паскаль. Сравнивать имеет смысл Паскаль и обычный Си.

>> TurboC приходится парсить кучу заголовочных файлов

> А pch для кого придумали, а?

В Turbo C не было pch :) Кроме того, pch - это всё же не то.

> 1) Угребищная система стандартных типов. Зачем в языке 6(или 9 - смотря как считать) целочисленых типа и 2 с плавающей точкой? Нельзя было сделать по одному? Почему их размеры хотя-бы жестко не ограничены, как в точкаНЕТе(вообще удивительно, что .НЕТ и Жава переняли этот брейн демедж с их количеством)?

Я таки не понял, ты посмел наехать на Си? :D

>Спасибо, конечно, но ты опоздал лет эдак.... хм.... сильно, короче, опоздал.

Да, теперь в моде миксы из QString, mysql::String, ACE_String_*, MyCoolString, your_cool_string и пр. sqlite++ char* использует кстати.

>>И при этом кто-то тут обсуждает ООП и generic programming, да.

>Просто этого "кого-то" не переклинило на std::string

Часть Стандартной Библиотеки, одобренная ansi-iso-iec, ты чаво.

>Я таки не понял, ты посмел наехать на Си? :D

А стрелки не переводить и за кресты ответить слабо? :)

> А стрелки не переводить и за кресты ответить слабо? :)

А ты не понял, что это был ответ за Си++? Тогда ой.

> 1) Мне надо привлекать метапрограмму работающую во время компиляции для того чтобы просто вернуть из функции тупую строчку? Я так понимаю мне надо использовать std::string, а это typedef для шаблона std::basic_string<...> где параметрами являются как минимум аллокатор и char_traits.

А ты покажи в basic_string метапрограмму сначала. Ведь метапрограммирование (http://en.wikipedia.org/wiki/Metaprogramming) это когда одна программа получает вторую в качестве параметра, манипулирует ей и генерит на основе манипуляции новую программу (либо, касательно C++, производит результат вычислений в compile-time, а не в run-time). По мне, так basic_string -- это обычный шаблонный класс, никакими манипуляциями над программами не занимающийся.

> 2) Является ли говном тот язык где надо привлекать метапрограмму работающую во время компиляции для того чтобы просто вернуть из функции тупую строчку?

Я знаю фанатов такого языка, как Nemerle. В нем чуть ли не все делается метапрограммами. Даже циклы и условные операторы в них -- это вызовы метапрограмм. Надо полагать, что по твоей логике Nemerle говно-говном. Только вот эти самые фанаты Nemerle тебя бы с потрохами съели за такое сравнение. И многие из них понимают в программировании и CS гораздо больше тебя.