Qt 4.4

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

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

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

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

значит ответить на поставленные ранее вопросы ты не можешь? слив тебе защитан, юный красноглазик =))))))

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

>значит ответить на поставленные ранее вопросы ты не можешь?

Мы поняли, что в своей лабе ты определил operator< для класса TPerson и с помощью std::sort отсортировал std::vector<TPerson> размером 10 элементов по ФИО. Писай кипятком дальше.

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

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

Да нет никаких - само сдохнет.

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

Тогда при чем тут твоя нелюбовь шаблонам? И уже в который раз шрифтом для блондинок повторю (в надежде получить-таки ответ): КТО ТЕБЯ ЗАСТАВЛЯЕТ ИХ ИСПОЛЬЗОВАТЬ?

>Очередной раз повторяю:

ты говоришь это впервые

>1) finally нет, значит использования auto_ptr<> не избежать.

кто тебя заставляет использовать исключения?

>2) чтобы сделать callback нужно использовать костыль типа boost::function<>.

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

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

Зачем тогда привел цитату - продолжить флейм своим очередным идиотским высказыванивем?

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

Не удивительно, продолжай отжигать ))))))

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

значит программер ты никудышный

> изменение класса AbstractWindow с ~500 виртуальными функциями сломает весь код который от него зависит

Блин, ты с самого начала говорил об этом древнем бояне с добавлением виртуальной функции в базовый класс? o.O

Ну и что будет, если ты добаишь метод в Ява-интерфейс? То же всё сломается. Везде всё сломается, кроме динамических языков (у которых свои проблемы).

>Ну и что будет, если ты добаишь метод в Ява-интерфейс? То же всё сломается.

Нет.

>Мы поняли, что в своей лабе ты определил operator< для класса TPerson и с помощью std::sort отсортировал std::vector<TPerson> размером 10 элементов по ФИО. Писай кипятком дальше.

Какой-то поток сознания, а ответить конкретно на 2 пункта без ФГМ'ных аргументов - уровня интеллектуального развития уже не хватает?

>Да нет никаких - само сдохнет.

уж никак не раньше чем ты, красноглазый троллишко

бегом читать про рефакторинг и нормальные IDE

>> Ну и что будет, если ты добаишь метод в Ява-интерфейс? То же всё сломается.

> Нет.

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

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

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

Не об этом речь. Речь о бинарной совместимости, насколько я понял. О том, что при добавлении виртфункции приходится расширять vTable и это ломает производные классы. Но эта misfeature известна уже лет 20, и для борьбы с ней есть хорошо известный тупой костыль.

> не знаю как в яве, а в с++

В Java так же. Чтобы не сломать прикладной код при добавлении метода в библиотечный интерфейс. Только код всё-равно ломается, если он реализует прямо этот интерфейс.

Э... Есть два варианта. Либо я совсем ничего не понимаю в C++. Либо добавление виртуального метода не люмает производные классы. По крайней мере с компилятором g++ 4.2.3.

//другой анонимус

> Либо добавление виртуального метода не люмает производные классы. По крайней мере с компилятором g++ 4.2.3.

Как ты проверял?

1. Обьявил класс с виртуальным методом и скомпилил его в .o

2. Обьявил класс-наследник с перегруженным виртуальным методом и в одном файле с ним функцию main. Скомпилил в .o

3. Слинковал *.o и убедился что работает.

4. Добавил в первый класс виртуальный метод и скомпилил только его. $ g++ -c foo.c

5. Слинковал новый foo.o со старым main.o. Запустил. Сработало.

Естественно в main виртуальная функция вызывалась и выводила в консоль "derived foo".

>> изменение класса AbstractWindow с ~500 виртуальными функциями сломает весь код который от него зависит

>Блин, ты с самого начала говорил об этом древнем бояне с добавлением виртуальной функции в базовый класс? o.O

В ObjectiveC вообще 500 виртуальных функций создавать не придется вообще. Там надо поставить дефолтовый обработчик *всех* сообщений. Если ни один из подклассов не ловит сообщение, сообщение попадет в дефолтовый обработчик.

>Ну и что будет, если ты добаишь метод в Ява-интерфейс? То же всё сломается. Везде всё сломается, кроме динамических языков (у которых свои проблемы).

в Яве никаких неожиданных проблем не бывает. Это в С++ ошибочный символ в шаблоне компилятор может воспринять как элемент ANSI-триграфа и расксерить по всем инстанциациям шаблона. Реальный случай кстати - в одной западной фирме разработка встала на две недели - все искали что же такое страшное случилось.

>бегом читать про рефакторинг и нормальные IDE

Рефакторинг? В С++ ?

>Какой-то поток сознания, а ответить конкретно на 2 пункта

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

у... как все запущено, я то думал вы действительно разбираетесь, советую к примеру почитать Мартина Фаулера - "Рефакторинг. Улучшение существующего кода", отличная книга

> Естественно в main виртуальная функция вызывалась и выводила в консоль "derived foo".

Анонимный брат, а не делаешь ли ты примерно так:

Derived d;

d.virtfoo()

?

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

>>> изменение класса AbstractWindow с ~500 виртуальными функциями сломает весь код который от него зависит

>>Блин, ты с самого начала говорил об этом древнем бояне с добавлением виртуальной функции в базовый класс? o.O

>В ObjectiveC вообще 500 виртуальных функций создавать не придется вообще. Там надо поставить дефолтовый обработчик *всех* сообщений.

Точно. И в Смолтоке тоже. А в Питоне вообще можно добавить в объект метод "на ходу". Это неопровержимо доказывает, что Си++ сакс и мастдай.

> Это в С++ ошибочный символ в шаблоне компилятор может воспринять как элемент ANSI-триграфа и расксерить по всем инстанциациям шаблона. Реальный случай кстати - в одной западной фирме разработка встала на две недели

А чего только 2 недели? Давай сразу 2 года, унушаит сильнее.

Base *o = new Derived(); o->foo();

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

Мне всё-таки непонятно, если в функциях изменились принимаемые аргументы и тип возвращаемого значения, если в объектах часть методов изменилась/исчезла, как здесь поможет с? Возмём самый простой пример: в qt3 состояние QCheckBox показывалось функциями isChecked и isTristate, возвращающими bool. В qt4 isChecked заменили на checkState, возвращающую значение типа Qt::CheckState. Или вспомним uic, который теперь генерирует не сам диалог, а некий класс-настройщик. Я уже не говорю о QMainWindow и производных QAbstractItemView.. О каком reusable в этих случаях может идти речь?

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

Ну и? В qt точно также есть Qt3Support. Это решение самих разработчиков тулкитов.. Чем здесь обычный си удобней плюсов?

> Base *o = new Derived(); o->foo();

Тоже компилятор мог догадаться... сейчас посмотрю у себя.

------------------------------lib.h
class Base {
public:
	virtual void foo();
//	virtual void bar();
};


------------------------------lib.c
#include "lib.h"
#include "stdio.h"

void Base::foo() {
	printf("Foo!");
}

//void Base::bar() {
//	printf("Bar!");
//}

------------------------------main.c
#include "lib.h"
#include "stdio.h"

class Derived : public Base {
public:
	virtual void foo() {
		printf("derived Foo!");
	}
};

int main() {
	Base *o = new Derived();
	o->foo();
	return 0;
}

При втором билде комменты убираются

> Точно. И в Смолтоке тоже. А в Питоне вообще можно добавить в объект метод "на ходу". Это неопровержимо доказывает, что Си++ сакс и мастдай.

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

Какое интеллектуальное, интересное и содержательное сообщение. :)

>Да нет никаких - само сдохнет.

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

> почему программы, которые не используют это - "сакс и мастдай"?

Это была грустная ирония.

>>В ObjectiveC 500 виртуальных функций создавать не придется вообще. Там надо поставить дефолтовый обработчик *всех* сообщений.

>Точно. И в Смолтоке тоже. А в Питоне вообще можно добавить в объект метод "на ходу". Это неопровержимо доказывает, что Си++ сакс и мастдай.

Ну для меня - да. Я люблю асинхронную event-driven архитектуру. Смоллток и Питон не компилируется в маш.код, можно разводить FUD по поводу перворманса. А вот ObjectiveC нормально использовался на очень древних Маках.

>> Это в С++ ошибочный символ в шаблоне компилятор может воспринять как элемент ANSI-триграфа и расксерить по всем инстанциациям шаблона. Реальный случай кстати - в одной западной фирме разработка встала на две недели

>А чего только 2 недели? Давай сразу 2 года, унушаит сильнее.

Этот прикол вошел в книжку Саттера. Или в его онлайновую переписку с кем-то.

>>>В ObjectiveC 500 виртуальных функций создавать не придется вообще. Там надо поставить дефолтовый обработчик *всех* сообщений.

>>Точно. И в Смолтоке тоже. А в Питоне вообще можно добавить в объект метод "на ходу". Это неопровержимо доказывает, что Си++ сакс и мастдай.

> Ну для меня - да.

Да понятно, что логика у тебя... своя.

>>> Это в С++ ошибочный символ в шаблоне компилятор может воспринять как элемент ANSI-триграфа и расксерить по всем инстанциациям шаблона. Реальный случай кстати - в одной западной фирме разработка встала на две недели

>>А чего только 2 недели? Давай сразу 2 года, унушаит сильнее.

>Этот прикол вошел в книжку Саттера. Или в его онлайновую переписку с кем-то.

Те, с кем это случилось - кретины, независимо от того, существовали они или нет.

> вошел в ... его онлайновую переписку с кем-то.

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

> Те, с кем это случилось - кретины, независимо от того, существовали они или нет.

они просто не знали о такой вещи, как Preprocess, тогда можно спокойно посмотреть во что развернулись все макросы

Не в том дело... остановка работы на 2 недели, чтобы найти ошибку компиляции - это песец. Да по любой причине остановка работы хоть на 2 дня - это вопиющий непрофессионализм. У них что, VCS не было и предыдущие версии никак не хранились?

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

Там были шаблоны.

> Там были шаблоны

все, ложусь спать - уже двое суток не спал, голова не соображает :)

Вот что получилось у меня:

------------base.h
class Base {
public:
virtual void virtfoo() const;
#if WITH_VIRTFOO2 == 1
virtual void virtfoo2() const;
#endif
};
------------base.cc
#include <iostream>

#include "base.h"

using namespace std;

void Base::virtfoo() const
{
cout << "I am Base::virtfoo" << endl;
}

#if WITH_VIRTFOO2 == 1
void Base::virtfoo2() const
{
cout << "I am Base::virtfoo2" << endl;
}
#endif
------------main.cc
#include <iostream>

#include "base.h"

using namespace std;

class Derived : public Base {
public:
virtual void virtfoo() const { cout << "I am Derived::virtfoo" << endl; }
};

int main()
{
Base *o = new Derived();

o->virtfoo();
}

------------buildrun
c++ -DWITH_VIRTFOO2=0 -c base.cc && \
c++ -DWITH_VIRTFOO2=0 main.cc base.o && \
./a.out; \
c++ -DWITH_VIRTFOO2=1 -c base.cc && \

c++ -DWITH_VIRTFOO2=1 main.o base.o && \
./a.out
------------

Если всё работает как должно, запуск buildrun должен выводить:
I am Derived::virtfoo
I am Derived::virtfoo

В реальности он выводит:
I am Derived::virtfoo
I am Base::virtfoo

Если заменить:

c++ -DWITH_VIRTFOO2=1 main.o base.o && \

на

c++ -DWITH_VIRTFOO2=1 main.cc base.o && \

всё работает как положено.

Пара ссылок в тему:
http://xytang.blogspot.com/2007/08/comparison-of-c-and-java-vtable-vs.html
http://techbase.kde.org/Policies/Binary_Compatibility_Issues_With_C%2B%2B

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

В дурку играешь или таки фимоз? http://www.linux.org.ru/jump-message.jsp?msgid=2710611&cid=2719871

Только расскажи не про то, что тебе "мешает", хотя ты это не используешь, а ответь на мой прямой вопрос, т.е.:

какие из объективных недостатков С++ мешают лично _мне_

гик после этого вопроса уже признал свою импотенцию =)

Ничего не понимаю... У меня выводит

I am Derived::virtfoo
I am Derived::virtfoo

В обоих случаях.

Только заменил c++ на g++ и указал выходные файлы ключом -o, чтобы в a.out не сохранял. Делаю rm *.o && ./buildrun

Ещё одно проявление несовместимости C++ с самим собой?

>http://www.linux.org.ru/jump-message.jsp?msgid=2710611&cid=2719871

Я этот постинг вчера вообще проскочил. Он неинтересный. Такие посты (по энергетике) бывают на 50-й странице обсуждения "Православие-маздай или не маздай?", где православные неизменно унылы и терпеливы как зомби, а атеистов уже задолбало.

>какие из объективных недостатков С++ мешают лично _мне_

А мне пофиг.

>гик после этого вопроса уже признал свою импотенцию =)

Кто о чем, а вшивый ...

>Я этот постинг вчера вообще проскочил. Он неинтересный.

Ну да, сморозил в ответ какое-то дермище, тебе потом столько прямых вопросов задали - ты ни на один из них толком так и не ответил, а теперь "Он неинтересный", слив защитан, красноглазик Absurd ))))))))

>А мне пофиг.

Гик немного поумнее, он промолчал, а ты слил в прямом эфире - на пересдачу, быдло!

>Кто о чем, а вшивый ...

не любит С++, но никак не может найти объективных пояснений, что с его гуманитарным складом мышления ничуть не удивительно =)

>>Я этот постинг вчера вообще проскочил. Он неинтересный.

>Ну да, сморозил в ответ какое-то дермище

Перевод темы в гуманитарное выяснение отношений, на которое Гик зачем-то повелся? Ну нах. Я полстраницы промотал, до постов tailgunner'а с которым можно нормально дискутировать.

>слив защитан, красноглазик Absurd

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

Красноглазик с гуманитарным складом ума?!

>Перевод темы в гуманитарное выяснение отношений, на которое Гик зачем-то повелся? Ну нах.

UPD: Это была другая страница. На этой я все-таки ответил популярным языком, по пунктам.

>Перевод темы в гуманитарное выяснение отношений, на которое Гик зачем-то повелся? Ну нах. Я полстраницы промотал, до постов tailgunner'а с которым можно нормально дискутировать.

Я ничего не хочу с тобой обсуждать, а лишь хочу получить от тебя (раз уж ты взялся отвечать) и гика ясные и корректные ответы на вопросы, которые по логике всплывают из его заявлений. Если ответов не будет - значит он балабол и его утверждения это обычный ГСМный кал.

>>Перевод темы в гуманитарное выяснение отношений, на которое Гик зачем-то повелся? Ну нах. Я полстраницы промотал, до постов tailgunner'а с которым можно нормально дискутировать.

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

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

From: Linus Torvalds <torvalds <at> linux-foundation.org>
Subject: Re: [RFC] Convert builin-mailinfo.c to use The Better String Library.
Newsgroups: gmane.comp.version-control.git
Date: 2007-09-06 17:50:28 GMT (34 weeks, 5 days, 17 hours and 54 minutes ago)


On Wed, 5 Sep 2007, Dmitry Kakurin wrote:
>
> When I first looked at Git source code two things struck me as odd:
> 1. Pure C as opposed to C++. No idea why. Please don't talk about portability,
> it's BS.

*YOU* are full of bullshit.

C++ is a horrible language. It's made more horrible by the fact that a lot
of substandard programmers use it, to the point where it's much much
easier to generate total and utter crap with it. Quite frankly, even if
the choice of C were to do *nothing* but keep the C++ programmers out,
that in itself would be a huge reason to use C.

In other words: the choice of C is the only sane choice. I know Miles
Bader jokingly said "to piss you off", but it's actually true. I've come
to the conclusion that any programmer that would prefer the project to be
in C++ over C is likely a programmer that I really *would* prefer to piss
off, so that he doesn't come and screw up any project I'm involved with.

C++ leads to really really bad design choices. You invariably start using
the "nice" library features of the language like STL and Boost and other
total and utter crap, that may "help" you program, but causes:

- infinite amounts of pain when they don't work (and anybody who tells me
that STL and especially Boost are stable and portable is just so full
of BS that it's not even funny)

- inefficient abstracted programming models where two years down the road
you notice that some abstraction wasn't very efficient, but now all
your code depends on all the nice object models around it, and you
cannot fix it without rewriting your app.

In other words, the only way to do good, efficient, and system-level and
portable C++ ends up to limit yourself to all the things that are
basically available in C. And limiting your project to C means that people
don't screw that up, and also means that you get a lot of programmers that
do actually understand low-level issues and don't screw things up with any
idiotic "object model" crap.

So I'm sorry, but for something like git, where efficiency was a primary
objective, the "advantages" of C++ is just a huge mistake. The fact that
we also piss off people who cannot see that is just a big additional
advantage.

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.

But I'm sure you'd like it more than git.

Linus

> Ещё одно проявление несовместимости C++ с самим собой?

Скорее undefined behaviour.

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

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