Qt 4.4

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

Ну - вообще-то он есть. Посмотри что такое вебсервисы.

>> И что будет вызываться при вызове нереализованного метода? Такой класс вообще загрузится?

> А как у тебя может быть его вызов, если его добавили только потом?

А у меня клиент библиотеки перекомпилирован. а она сама - нет.

>А у меня клиент библиотеки перекомпилирован. а она сама - нет.

Что-то я не понял - вроде же в парента добавляли не трогая наследника, а не наоборот.

То как ты говоришь бросит исключение NoSuchMethodError в момент вызова. Можно поймать:)

>То как ты говоришь бросит исключение NoSuchMethodError в момент вызова. Можно поймать:)

По идее ничто не мешает сантехникам это поведение завернуть в вызов метода типа undefinedMethodCall() с дефаултной реализацией в виде бросания исключения - будет без потери обратной совместимости вполне себе статика с поведением смолтолка.

>>А у меня клиент библиотеки перекомпилирован. а она сама - нет.

>Что-то я не понял - вроде же в парента добавляли не трогая наследника, а не наоборот.

В пакете p1 определен интерфейс I1, в пакете p2 - реализующий его класс C1. I1 используется в клиентском пакете p3. В I1 добавляется метод m2, и p1 перекомпилируется. Вопрос - если из p3 будет вызван m2, что будет?

> NoSuchMethodError в момент вызова. Можно поймать:)

Но дальше-то что? :)

>что будет?

NoSuchMethodError

>Но дальше-то что? :)

Ну тоже самое что и везде:)

Ну да, можно сказать ещё так: "что мой авторитет не осилил - значит не нужно". И ты опять ушел от ответа на мой вопрос. И к тому же, Линус говорит, что гном для идиотов и поэтому советует всем пользоваться KDЕ. Общий вывод из всего этого: твой очередной аргумент - говно.

> If you want a VCS that is written in C++, go play with Monotone. Really. They use a "real database". They use "nice object-oriented libraries". They use "nice C++ abstractions". And quite frankly, as a result of all these design decisions that sound so appealing to some CS people, the end result is a horrible and unmaintainable mess.

Бгг. Линус сам признался, что по идеям Git - цельнотянутый Monotone. Кстати, сам Monotone вполне жив и развивается (а людей у Смита и Хоара не в пример меньше).

Да git тоже ничего так, жив ;)

> Да git тоже ничего так, жив ;)

Git жив за счет пЕара: "VCS, которую написал сам Линус".

Это ты в какой-нибудь умной книжке прочитал или сам додумался?

>Ну да, можно сказать ещё так: "что мой авторитет не осилил - значит не нужно".

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

>И ты опять ушел от ответа на мой вопрос.

Я не вижу конкретных технических выкладок о приемеществах С++ в твоих постингах. Их нет.

>И к тому же, Линус говорит, что гном для идиотов и поэтому советует всем пользоваться KDЕ.

ЕМНИП Это было давно. Возможно даже, он тогда любил С++. Платонически.

>>> Да git тоже ничего так, жив ;)

>> Git жив за счет пЕара: "VCS, которую написал сам Линус".

> Это ты в какой-нибудь умной книжке прочитал или сам додумался?

Кисо, я покусился на твой фетиш? Нуизвини. А читать или думать о судьбе Git незачем - достаточно просто посмотреть.

>Ну, через несколько лет использования С++ я пришел к тем же выводам что и Торвальдс. Я его понимаю.

Это твое IMHO. А Торвальдс обычно любит покричать, о perl в частности =)

>Я не вижу конкретных технических выкладок о приемеществах С++ в твоих постингах. Их нет.

Ты кося под дурачка все время пытаешься съехать с темы, но это ничего, я в очередной раз тыкну тебя носом: http://www.linux.org.ru/jump-message.jsp?msgid=2710611&cid=2721921 А если совсем c сообразительностью худо: http://www.linux.org.ru/jump-message.jsp?msgid=2710611&cid=2719767

>ЕМНИП Это было давно. Возможно даже, он тогда любил С++. Платонически.

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

> Кисо, я покусился на твой фетиш?

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

> Нуизвини. А читать или думать о судьбе Git незачем - достаточно просто посмотреть.

Ну написал человек (первую версию) свою программу. В первый раз, что ли? :) Есть объективные аргументы, почему git - неудачная и ненужная VCS?

>я в очередной раз тыкну тебя носом:

Итак, вопрос: Какие особенности С++ мешают _тебе_?

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

>> Кисо, я покусился на твой фетиш?

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

Нет. Это был вопрос, если ты не заметил.

> Есть объективные аргументы, почему git - неудачная и ненужная VCS?

Ыыы... я что-то сказал про неудачность и ненужность? Git жив (== выжил) за счет пеара, точка. Он вообще планировался как stopgap measure, и ранний Git (как минимум, до 1.0 включительно) был просто шлак неюзабельный - его, кроме Линуса, больше никто использовать просто не хотел (Xen - отличный пример). Однако пеар был мощный, и, похоже, Git допилили таки до юзабельного состояния (не знаю, ибо не пользуюсь).

>>> Кисо, я покусился на твой фетиш?

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

> Нет. Это был вопрос, если ты не заметил.

Кисой меня дозволено называть только моей жене.

> Ыыы... я что-то сказал про неудачность и ненужность? Git жив (== выжил) за счет пеара, точка. Он вообще планировался как stopgap measure, и ранний Git (как минимум, до 1.0 включительно) был просто шлак неюзабельный - его, кроме Линуса, больше никто использовать просто не хотел (Xen - отличный пример). Однако пеар был мощный, и, похоже, Git допилили таки до юзабельного состояния (не знаю, ибо не пользуюсь).

Я git увидел в районе 1.3 или 1.4. После svn, не говоря уж о cvs, очень хорошо. Mercurial, вроде, тоже неплох, но я его кроме hg clone и hg pull не пользовал.

> Я git увидел в районе 1.3 или 1.4

Примерно в это время Git проиграл Mercurial'у OpenSolaris и JDK.

> Примерно в это время Git проиграл Mercurial'у OpenSolaris и JDK.

И что теперь? :) Уронить скупую мужскую слезу? Мне на оба фиолетово :)

Вот на часто сломанные cvs/svn на sf.net не пофиг. А repo.or.cz, тьфу-тьфу, или не глючит, или чинится очень оперативно.

>> Примерно в это время Git проиграл Mercurial'у OpenSolaris и JDK.

> И что теперь? :) Уронить скупую мужскую слезу?

Что теперь - решай сам. Я чисто для справки сказал.

Ну родил ты наконец !!! ))))))

>Ответ: Тебе в С++ не мешает ничего

Значит "объективные" недостатки C++ на самом деле субъективные и, следовательно, заявление гика есть ложь - что и требовалось доказать

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

А это уже плод твоей фантазии

Урок окончен, можешь идти домой =)

> Что теперь - решай сам. Я чисто для справки сказал.

Для новых проектов надо брать лучшее, что есть. А legacy на cvs дцать лет уже сидит, и ещё с пяток точно мучаться придётся.

> Значит "объективные" недостатки C++ на самом деле субъективные и, следовательно,

Следовательно, что всё субъективно. Объектная модель в C++ по сравнению с другими, более продвинутыми, языками - говно. Субъективно, конечно же. Субъективно же, при портировании софта на другой компилятор/платформу сишный компилятор выдаёт ошибки проще, чем плюсатый, которого переклинило где-нибудь глубоко в boost. Это, что касается меня. Для вас, конечно же, 6 экранов выхлопов g++ - это даже лучше, чем стихи Пушкина.

>>Ответ: Тебе в С++ не мешает ничего

>Значит "объективные" недостатки C++ на самом деле субъективные и, следовательно, заявление гика есть ложь - что и требовалось доказать

Твои упражнения в риторике меня не интересуют. Я привел три объективных недостатка С++:

1) в нем есть шаблоны, которых быть не должно. 2) стандартные контейнеры используют шаблоны которых быть не должно. 3) generics использует шаблоны которых быть не должно.

Ты слил, так как сказал что я могу их не использовать, так как тот факт что я могу их не использовать не отменяет того что они _есть_ в языке.

пиздец...

Клиника.

>>Я привел три объективных недостатка С++

>пиздец...

>Клиника.

Хочешь узнать мое мнение? =D

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

производительность бинарников на этих языках (грубо говоря) по сравнению с С++ - говно

>Субъективно же, при портировании софта на другой компилятор/платформу сишный компилятор выдаёт ошибки проще, чем плюсатый, которого переклинило где-нибудь глубоко в boost.

Субъективно, для меня важны скорость бинарников и удобная модель программирования. Писать GUI на Qt удобней, чем GTK. Количество "выхлопа" компилятора - унылый аргумент.

>Писать GUI на Qt удобней

Не в порядке что "правильнее" - C или C++:

1) "Писать GUI на Qt" != "Писать GUI на C++"

2) Писать GUI на Tk удобнее, чем на Qt и GTK

Т.о. твоё утверждение - сорри, но не аргумент в текущем споре:)

>пиздец...

>Клиника.

Я не хочу видеть в своих .h файлах ничего кроме деклараций интерфейсов. И не хочу инклудить из своих .h файлов ничего кроме описаний интерфейсов. И не хочу городить костылей типа pimpl-классов. Если считаете иначе, то клиника светит вам.

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

>производительность бинарников на этих языках (грубо говоря) по сравнению с С++ - говно

У Deplhi и Cocoa плохая производительность?

> У Deplhi и Cocoa плохая производительность?

У первого - отстой. Там даже байт в машинное слово кастится при помощи вызова функции, когда можно просто al заюзать.

Наеборот, из слова в байт, наанестезировавшийся упавший вылысыпыдыст...

>> У Deplhi и Cocoa плохая производительность?

>У первого - отстой. Там даже байт в машинное слово кастится при помощи вызова функции, когда можно просто al заюзать.

В msvc++ 6 тоже была куча косяков когда вместо одной x86 инструкции он делал call вглубь crt с передачей параметра через стек. И ничаво - пипл хавал.

> 1) "Писать GUI на Qt" != "Писать GUI на C++"

согласен, но под первым я подразумевал второе, простите эту огрешность если сможете =)

> 2) Писать GUI на Tk удобнее, чем на Qt и GTK

Tk не подходит по заданному критерию - производительности, хотя мне самому он тоже очень нравится =)

У Delphi где-то в 2 раза медленнее получается бинарник, считающий pi до заданного знака (все операции - целочисленная арифметика и работа со строками), по сравнению с Си и Си++

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

Это сделано для того, чтобы:
a) работать с выравненными на двойное слово данными
б) избежать ненужных movzx/movsx

>В msvc++ 6 тоже была куча косяков когда вместо одной x86 инструкции он делал call вглубь crt с передачей параметра через стек. И ничаво - пипл хавал.

А было что-то лучшее в то время?

> А было что-то лучшее в то время?

Watcom?

Почему-то даже лисповому компилятору SBCL ничего не мешает загрузить полностью машинное слово (из соображений эффективности) и дальше просто работать с младшим 8-битным регистром. А Делфи делает проверку и после неё call.

> Tk не подходит по заданному критерию - производительности, хотя мне самому он тоже очень нравится =)

Очень странный критерий - "производительность GUI"...

>> А было что-то лучшее в то время?

>Watcom?

Ты спрашиваешь, значит сам толком не уверен, а я даже дам ссылку, чтобы тебе помочь: http://www.rusdoc.ru/material/lang/cpp/hicode.shtml Читай до конца, делай адекватные выводы

>Очень странный критерий - "производительность GUI"...

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

А Trolltech по-любому заслуживает уважения за проделанную работу в этор выпуске по увеличению скорости работы qt (это то, на что разработчики "иделогически правильного" gtk давно положили, типа "там уже и так все оптимизировано лучше некуда")

> Ты спрашиваешь, значит сам толком не уверен

Я не спрашиваю, я предлагаю. Тот факт, что я хорошо пописал на ассемблере и до сих пор его помню, позволяет мне залезть в сгенерированный компилятором код и самостоятельно оценить его качество :-P Так вот, Watcom во времена msvs6 генерил очень неплохой код, хотя по части соблюдения стандартов он - своеобразный компилятор.

> 1) в нем есть шаблоны, которых быть не должно.

Я конечно дико извиняюсь, что влез в Вашу дискуссию. Однако мне не понятно почему Вам не нравятся шаблоны. По моему удобный инструмент...

>Однако мне не понятно почему Вам не нравятся шаблоны. По моему удобный инструмент...

А как они используются кроме для решения собственных проблем С++?
Если посмотреть на библиотеки идущие к коммерческим компиляторам типа
MSVC или BCB, то там иерархии классов строятся от базового объекта
типа CObject или TObject. Для борьбы с языком используется препроцессор,
грязные хаки c union{void (CObject::*ptr)(...), more_sane_types} (MFC)
и расширения наподобие __closure, __declspec(dynamic) (VCL).
В Qt тоже все наследуется от QObject и используется внешний
препроцессор moc. Несмотря на всю ту пургу что несет Строуструп
относительно того что иерархии в С++ должны быть
предметно-ориентированы и разрознены.

Особняком тут стоит WTL/ATL, где шаблоны применяются
для маршрутизации вызозов функций без применения C++ vTables.
Т.е примерно так:

template <class T> class B1 {
public:
void SayHi() {
T* pT = static_cast<T*>(this);
pT->PrintClassName();
}

void PrintClassName() { cout << "This is B1"; }
};

class D1 : public B1<D1> {
// No overridden functions at all
};

class D2 : public B1<D2> {
void PrintClassName() { cout << "This is D2"; }
};

int main() {
D1 d1;
D2 d2;
d1.SayHi(); // prints "This is B1"
d2.SayHi(); // prints "This is D2"
return 0;
}

В ObjectiveC связывание сообщения с обработчиком происходит
примерно как в WTL - статически вызывается селектор,
который ищет обработчик сообщения в самом нижнем классе и
при отсутствии оного делегирует сообщение вверх.
При достижении корня вызывается дефолтовый обработчик -
в win32 это DefWindowProc.
Т.е опять таки решаем собственные проблемы C++.

Ты можешь сказать что так круто сделать MyCoolLinkedList<T>.
Но это очень сомнительно, так как объекты удобнее складывать
в виде указателей, а не по значению т.к заколебешься для каждого
класса в большом проекте делать конструктор копирования,
функцию swap и operator=, упоминая каждое поле класса
три или четыре раза и при добавлении полей вносить минимум
три консистентных изменения. Проще поместить объект в кучу и
пользоваться указателем, который семантикой значений
обладает изначально.

Всякие вектора [x y z 1] и матрицы 4x4, которые вроде бы
напрашиваются на семантику значений, никто на C++ делать не будет.
Напишут на C + ASM в виде довольно крупных операций
покрывающих всю логику работы с ними.

Type Safety, который обеспечивает MyCoolLinkedList<T> по сравнению с
MyCoolObjectLinkedList содержащим указатели на базовый MyObject
и необходимость даункастинга (явного или неявного) при обращении
к элементам коллекции это FUD в основном. Теряем раздельную
компиляцию в обмен на чистоплюйство.

Звездишь, как дышишь :) В Qt не все наследуется от QObject moc - ни разу не препроцессор

> Ты можешь сказать что так круто сделать MyCoolLinkedList<T>.
Но это очень сомнительно, так как объекты удобнее складывать
в виде указателей, а не по значению т.к заколебешься для каждого
класса в большом проекте делать конструктор копирования,
функцию swap и operator=, упоминая каждое поле класса
три или четыре раза и при добавлении полей вносить минимум
три консистентных изменения. Проще поместить объект в кучу и
пользоваться указателем, который семантикой значений
обладает изначально.

MyCoolLinkedList<boost::shared_ptr<T> >

> Всякие вектора [x y z 1] и матрицы 4x4, которые вроде бы
напрашиваются на семантику значений, никто на C++ делать не будет.

возвр. значение: return T;
вызывающий код: const T& val=<возвр. значение>

>
Type Safety, который обеспечивает MyCoolLinkedList<T> по сравнению с
MyCoolObjectLinkedList содержащим указатели на базовый MyObject
и необходимость даункастинга (явного или неявного) при обращении
к элементам коллекции это FUD в основном. Теряем раздельную
компиляцию в обмен на чистоплюйство.

Разумное сочетание динамического и статического полиморфизма - ключевой момент в понимании и использовании С++. Если же Вам больше нравится LISP, Haskel или еще что - не вопрос вообще, у нас свободная страна.

> Очень странный критерий - "производительность GUI"...

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