Qt 4.4

> А кто утверждал, что это имя? =)

Ну я хз, чем ты или другой анонимус руководствовался, называя меня не моим именем :)

>>В Си например тоже можно передать функции binary_search собственный компаратор вида int (*)(const void*, const void*).

>Ы? man 3 bsearch

Ну и что ты мне это привел?

> Как говорится "чисто не там, где убирают, а там, где не мусорят"

Смотрим на U++: http://www.ultimatepp.org/

>>D? хотя я его не смотрел.

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

Сконцентрировались на рантаймовых фичах ;) Будет релиз - опишу в новости. Из compile-time фичей, скорее всего, кроме шаблонов, ctfem mixin и AST macros ничего не будет.

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

утверждение было сделано Абсурдом, а ты с ним как бы согласился. перечитай свои посты от 04.05.2008 15:24:35 и от 04.05.2008 15:31:46, порефлексируй.

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

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

> Только он абсолютно ненужен.

кто тебе сказал, что определение операторов (не обязательно сравнения) для собственных типов (или классов) не нужно? не тебе об этом решать... если ты с чем-то не знаком, это не повод говорить, что это не нужно. хотя может вот это тебя утешит: http://thepr.ru/cert-absurd477667.html ?

> В Си например тоже можно передать функции binary_search собственный компаратор вида int (*)(const void*, const void*).

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

Всего наилучшего!

// captcha: tasker

>так-так... меняем показания на ходу?

Ты не умеешь читать. И С++ не осилил.

>у нас в протоколе все ходы записаны, между прочим...

Ментовской сынок?

>кто тебе сказал, что определение операторов (не обязательно сравнения) для собственных типов (или классов) не нужно

Не нужно. Виртуальные функции нужны, переопределенные операторы - нет.

btw, в Smalltalk и ObjectiveC вместо виртуальных функций используется посылка сообщений объекту. В Delphi подобие такого механизма есть - это dynamic функции, в С++ их нет.

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

Этой проблемы не существует. Ты ее выдумал.

> в Smalltalk и ObjectiveC вместо виртуальных функций используется посылка сообщений объекту

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

> Виртуальные функции нужны, переопределенные операторы - нет.

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

> Ты не умеешь читать. И С++ не осилил.

забыл добавить "и вообще ты нехороший"?

> Ментовской сынок?

не привык отвечать за свои слова?

> Не нужно. Виртуальные функции нужны, переопределенные операторы - нет.

обоснуй.

> btw, в Smalltalk и ObjectiveC вместо виртуальных функций используется посылка сообщений объекту. В Delphi подобие такого механизма есть - это dynamic функции, в С++ их нет.

и что следует из твоего текста? какой вывод?

> Этой проблемы не существует. Ты ее выдумал.

так и запишем: не знаком с методологией обобщенного программирования.

>Не нужно. Виртуальные функции нужны, переопределенные операторы - нет.

Это или твое унылое IMHO, или очередная xyйeтa

>Этой проблемы не существует. Ты ее выдумал.

Ага, все пидарасы, лишь один Absurd - Морфеус =)

>утверждение было сделано Абсурдом, а ты с ним как бы согласился. перечитай свои посты от 04.05.2008 15:24:35 и от 04.05.2008 15:31:46, порефлексируй

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

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

p.s. насчет моей социальной принадлежности не угадал.

// captcha: awaked

>Виртуальные функции нужны, переопределенные операторы - нет.

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

>> в Smalltalk и ObjectiveC вместо виртуальных функций используется посылка сообщений объекту

>Они оба динамически типизированы, так что сравнение неуместно. Кстати, не объяснишь, чем посылка сообщения качественно отличается от вызова виртуальной функции?

Каждый подкласс от AbstractWindow не должен тянуть по несколько сотен элементов в vTable несмотря на то что он все равно их не перегружает.

>> Виртуальные функции нужны, переопределенные операторы - нет.

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

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

В Java работа операторов сравнения бы очень не помешала для объектов у которых реализован interface Comparable. Но Гослинг видимо потрахался с С++ сильнее, поэтому он и более сильный экстремист в этом вопросе.

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

>Каждый подкласс от AbstractWindow не должен тянуть по несколько сотен элементов в vTable несмотря на то что он все равно их не перегружает.

И _всё_? Я спрашивал именно про посылку сообщения, вообще-то. Ну а "несколько сотен элементов в vTable" (ну пусть 500), по 12 байт на элемент - это 6КБайт _на класс_. Афигеть какой оверхэд, да. Сколько там в яве метаданных на класс, а?

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

> Потому что late-binding сущности можно легко экспортировать из библиотек, в отличии от раннесвязанных перегруженных операторов.

Ы... ты что сказать-то хотел? Причем перегрузка операторов к late-binding?

> В Java работа операторов сравнения бы очень не помешала для объектов у которых реализован interface Comparable

Так я не понял - перегрузка оераторов нужна или нет? o_O

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

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

>p.s. насчет моей социальной принадлежности не угадал.

птушнег?

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

виртуальные функции и перегруженные операторы вообще-то вещи весьма ортогональные. С чего ты взялся сравнивать, что лучше? =)

>виртуальные функции и перегруженные операторы вообще-то вещи весьма ортогональные. С чего ты взялся сравнивать, что лучше? =)

Я не говорю, что лучше, это меня абсурд загипнотизировал своей фразой =) Просто прочитав все предыдущее я так и не понял, чего же он добивается.

>Просто прочитав все предыдущее я так и не понял, чего же он добивается.

справедливости? =)

>справедливости? =)

для кого?

>для кого?

вообще. А то некоторые тут считают плюсы гениальным изобретением...невзирая на факты =)

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

>>Каждый подкласс от AbstractWindow не должен тянуть по несколько сотен элементов в vTable несмотря на то что он все равно их не перегружает.

>И _всё_? Я спрашивал именно про посылку сообщения, вообще-то.

Что ты спрашивал? В Delphi есть и virtual и dynamic. Оконные сообщения обрабатываются с помощью dynamic. В Visual С++ оконные сообщения обрабатывают с помощью switch, спрятанным за макросом.

>Ну а "несколько сотен элементов в vTable" (ну пусть 500), по 12 байт на элемент - это 6КБайт _на класс_. Афигеть какой оверхэд, да.

Это много.

>Сколько там в яве метаданных на класс, а?

Яве это тоже на пользу не идет. Впрочем, там и dynamic методов тоже нет. И делегатов тоже.

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

>> Потому что late-binding сущности можно легко экспортировать из библиотек, в отличии от раннесвязанных перегруженных операторов.

>ты что сказать-то хотел? Причем перегрузка операторов к late-binding?

При том блин. bsearch из <stdlib.h> уже скомпилирован и лежит в libc. std::binary_search из <algorithm> предварительно скомпилировать и положить в библиотеку невозможно -> в топку.

>> В Java работа операторов сравнения бы очень не помешала для объектов у которых реализован interface Comparable

>Так я не понял - перегрузка оераторов нужна или нет? o_O

Динамическую можно сделать. Но это синтаксический сахар, не более. Статическую - в топку.

>вообще. А то некоторые тут считают плюсы гениальным изобретением...невзирая на факты =)

это не справедливость (как некая цель), а элементарная зависть, открытая неприязнь к другому (пусть даже и неправильному c его точки зрения) мнению, черта характера, других объективных причин нахождения его и тебя в этом топике я не вижу

>При том блин. bsearch из <stdlib.h> уже скомпилирован и лежит в libc. std::binary_search из <algorithm> предварительно скомпилировать и положить в библиотеку невозможно -> в топку.

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

>а элементарная зависть

бугага. Ровно так же я "завидую" любителям турбобейсика =)

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

недостатки плюсов - вещь объективная.

>других объективных причин нахождения его и тебя в этом топике я не вижу

ну как же. А поржать над укурками, которые в азах ООП не разбираются, читать и понимать прочитанное не умеют - это не объективная причина? =)

>бугага. Ровно так же я "завидую" любителям турбобейсика =)

ну тут понятно - надменная ухмылка

>недостатки плюсов - вещь объективная.

перечисли, какие из этих "недостатков" _мне_ мешают

>А поржать над укурками, которые в азах ООП не разбираются, читать и понимать прочитанное не умеют - это не объективная причина? =)

"поржать над укурками" это твое субъективное, но уж никак не оъективное, касающееся в данном случае именно ООП - понял или детальней разложить?

мне кажется, что адекватных ответов на поледние 2 пункта не будет

+1

>перечисли, какие из этих "недостатков" _мне_ мешают

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

>"поржать над укурками" это твое субъективное, но уж никак не оъективное

объективное, ага. Где ещё встретишь индусов, путающих понятия класс и объект =)

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

Тебя попросили перечислить недостатки С++, мешающие отдельному человеку, а не рисовать очередную аллегорию. Засчитываем слив или все-таки перечислишь?

>объективное, ага. Где ещё встретишь индусов, путающих понятия класс и объект =)

Повторяю, "поржать" - это повод для _тебя_, т.е. лично субъективное. Назови объективную причину.

>Тебя попросили перечислить недостатки С++, мешающие отдельному человеку, а не рисовать очередную аллегорию.

Мне мешают:

1) Шаблоны, их быть не должно.

2) string, vector и hash_map не атомарные типы, а базируются на шаблонах которых быть не должно.

3) Библиотека generics - ов не пользуется виртуальными методами объектов для выполнения операций над ними, а использует перегруженные операторы доступные в контексте инстанциированного шаблона, а шаблонов быть не должно.

Это совершенно идиотские доводы ))))))))))) Ну ладно, по пунктам:

>Мне мешают:

А мне не мешают, я наоборот - считаю это очень удобным. Значит это субъективно.

>1) Шаблоны, их быть не должно.

Кто заставляет тебя использовать шаблоны?

>2) string, vector и hash_map не атомарные типы, а базируются на >шаблонах которых быть не должно.

Кто заставляет тебя пользоваться string, vector и hash_map, которые не атомарные типы, а базируются на шаблонах, которыми непонятно кто тебя заставляет пользоваться?

>3) Библиотека generics - ов не пользуется виртуальными методами объектов для выполнения операций над ними, а использует перегруженные операторы доступные в контексте инстанциированного шаблона, а шаблонов быть не должно.

Мне кажется, что ты просто ищешь причину, по которой хочешь прищемить себе яйца дверью, которая тебе не нравится =) Ничего вразумительного ответить на это наука не может, я же жду фотки яиц =)

Вообщем, Absurd, - жги дальше в лучших ЛОРовских ФГМных традициях )))))))))))))))))))))))

>А мне не мешают, я наоборот - считаю это очень удобным. Значит это субъективно.

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

>>1) Шаблоны, их быть не должно.

>Кто заставляет тебя использовать шаблоны?

Ну во первых Строуструп считает их гениальным изобретением, и зачастую выкручивает руки. Например, указатели на методы были разработаны для того чтобы быть использованными в конъюнкции с шаблонами и никак иначе. В псевдоинтервью журналу Computer псевдоСтроуструп говорил о "ловушках" которые он специально расставил для того чтобы С++ можно было использовать только в полной мере. 2 my mind похоже на правду.

>>2) string, vector и hash_map не атомарные типы, а базируются на шаблонах которых быть не должно.

>Кто заставляет тебя пользоваться string, vector и hash_map, которые не атомарные типы, а базируются на шаблонах, которыми непонятно кто тебя заставляет пользоваться?

Мы же не должны плодить велосипеды, не так ли?

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

Из постановки условий задачи видно, что шаблоны это явне не подходящий для этого инструмент. ТЫ не понимаешь разницы между _возможностью_ и _необходимостью_ использования конкретного инструмента и это явно ТВОИ проблемы, а не С++.

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

тебе выкручивает?

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

Тем не менее, в работе можно прекрасно обойтись и без шаблонов. Очередно раз спрашиваю: кто тебя заставляет этим пользоваться?

>В псевдоинтервью журналу Computer псевдоСтроуструп говорил о "ловушках" которые он специально расставил для того чтобы С++ можно было использовать только в полной мере. 2 my mind похоже на правду.

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

>Мы же не должны плодить велосипеды, не так ли?

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

Вообщем, зови гика на помощь, а то ты что-то совсем плох =) С нетерпением жду очередной порции идиотских аргументов ))))))

>> Ну а "несколько сотен элементов в vTable" (ну пусть 500), по 12 байт на элемент - это 6КБайт _на класс_. Афигеть какой оверхэд, да.

> Это много.

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

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

>> Так я не понял - перегрузка оераторов нужна или нет? o_O

> Динамическую можно сделать. Но это синтаксический сахар, не более. Статическую - в топку.

"Динамический синтаксический сахар" - это здорово сказано.

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

"Я весь плакал" (c)

> В псевдоинтервью журналу Computer псевдоСтроуструп говорил о "ловушках" которые он специально расставил для того чтобы С++ можно было использовать только в полной мере. 2 my mind похоже на правду.

Не знаю, шутишь ты или нет, но всё же: это интервью - стеб.

ну не корми этого тролля, я ж его вместе с гиком практически прибил! :)

>я ж его вместе с гиком практически прибил! :)

Не льсти себе:)

>ну не корми этого тролля, я ж его вместе с гиком практически прибил! :)

этой фразой ты надолго меня пацтол вогнал...

>Гик правда тоже не в тему подлизал (чего стоит только утверждение, что в плюсах невозможно определить оператор сравнения для собственных типов)

Гик у нас вообще непрекращающийся источник хорошего настроения.. Меня особенно забавляет, когда он каким-то образом связывает несовместимость qt3 с qt4 и "мультипарадигмность плюсов и легкости reusable плюсового кода". Наверное если в gtk половину методов переименуют, изменят принимаемые аргументы и тип возвращаемого значения, то сишные программы об этом узнают и сами себя перепишут. =)

>он каким-то образом связывает несовместимость qt3 с qt4 и "мультипарадигмность плюсов и легкости reusable плюсового кода".

если бы reusable было в наличии - переписывать бы qt3 на qt4 не пришлось бы.

>Наверное если в gtk половину методов переименуют

не переименуют. Учи матчасть. Новые могут добавить, оставив на какое-то время старые, пометив их как deprecated.

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

> а идея какая у wxWidgets - наклепать абстракцию от всех оконных интерфейсов, при том написав минимум, и получилась самая уродская по внешнему виду приложений библиотека с уродским api.

в каком месте api уродский? насчет внешнего вида - руки надо иметь где надо ;)

Наконец-то осилил тему. :)

Нет, Absurd, D не хранит шаблоны в объектных файлах. И не может хранить. Здесь остались все плюсовые недостатки. А вот string, vector и hash_map - как раз стали примитивами.

Если тебя не устраивают имеющиеся языки - напиши свой.

"For my part, I want to encourage people to make their own languages, because doing it makes you a world-class programmer. Seriously. Not just a better programmer, but a best programmer." (c) Steve Yegge

> если бы reusable было в наличии - переписывать бы qt3 на qt4 не пришлось бы.

Qt3Support Module

>Qt3Support Module

бгг

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

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

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

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

>Тем не менее, в работе можно прекрасно обойтись и без шаблонов. Очередно раз спрашиваю: кто тебя заставляет этим пользоваться?

Очередной раз повторяю: 1) finally нет, значит использования auto_ptr<> не избежать. 2) чтобы сделать callback нужно использовать костыль типа boost::function<>. И то и другое - шаблоны, следовательно фтопку. Вывод: мне выкрутили руки чтобы я применил фтопочную конструкцию.

>>В псевдоинтервью журналу Computer псевдоСтроуструп говорил о "ловушках" которые он специально расставил для того чтобы С++ можно было использовать только в полной мере. 2 my mind похоже на правду.

>А я всегда думал, что нужно эффективно решать задачи, а не использовать язык программирования "на полную" (смахивает на красноглазый фетишизм)

Желания использовать С++ "на полную" у меня нет никакого, я об этом уже говорил.

>>Мы же не должны плодить велосипеды, не так ли?

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

Каких тормознутых костылей? Не понял.

>Если тебя не устраивают имеющиеся языки - напиши свой.

Все языки от Фортрана до Хаскеля по своему хороши. Кроме С++ - он плох во всем.

> Все языки от Фортрана до Хаскеля по своему хороши. Кроме С++ - он плох во всем.

Твои предложения?