Когда Java быстрее C++ - сравнение производительности

> То есть если если что-то опасное выделяем через new в конструкторе и оно успело выделится до исключения - оно в пролете

>Ещё раз:
С этим никто не спорит.
Речь шла о такой проблеме
class A {

C c;
C* pc;
public:
A() {
pc = new C;
throw new int;
};
~A()
{
delete pc;
};
};

Для c нам деструктор сделают, для *pc - нет. Вывод - ловить исключения или создавать мембер-ресурсы тербующие new через обертки. Это проблема есть для любых функций где есть new, а delete - где-то потом. Поэтому я и говорил что в исключениях из конструкторов нет ничего особенного (в отличии от деструкторов).

Фибоначчи вычисляется рекурсивно :-) Класс!!!

2turanchox:родной, зачем вы нам показываете возможности OpenGL? какая разница, на чем написаны вызывающие ее функции?

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

>Неправильно. Читаем Final International Draft Standard ISO/IEC
>14882:1998(E), Programming languages -- C++
Ты наверное забыл, что в QT все выделяется в куче, а не на стэке?

>Ты наверное забыл, что в QT все выделяется в куче, а не на стэке?

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

#include <iostream>
using namespace std;

struct A {
	A() {
		cout << "A()" << endl;
	}
	~A() {
		cout << "~A()" << endl;
	}
};

struct B: public A {
	B() {
		cout << "B()" << endl;
		throw int( 1 );
	}
	~B() {
		cout << "~B()" << endl;
	}
};

main()
{
	try {
		B b;
	}
	catch( int ) {
		cout << "catched" << endl;
	}
}


$ ./main
A()
B()
~A()
catched

> Ну насмешил :-). А если в любом из их конструкторов эксепшн вылетит - они уберут мусор за собой? ;-)..

В Qt исключения не используются. Вообще. Поэтому всех вышеперечисленных с ними проблем тоже не будет.

2 adarovsky:
То что ребята из TrollTech не используют исключения не означает что их не буду использовать я... и не означает того, что их будет использовать кто-нибудь из тех, кто работает со мной в комманде. Мало того... мы их наверняка будем исползовать :-). Теперь смотрим... есть у нас например специализированый QSpecializedTextBrowser : public QTextBrowser в котором используются исключения... и любое непойманное внутри него исключение возникнет внутри QSplitter'а в конструкторе, или внутри любого другого контейнера в конструкторе ;-)... хе хе хе... так что аргументация мимо корзины.

>То что ребята из TrollTech не используют исключения не означает что их не буду использовать я... и не означает того, что их будет использовать кто-нибудь из тех, кто работает со мной в комманде. Мало того... мы их наверняка будем исползовать :-).

Соответственно, исключения обрабатывать вы уже должны, а не Qt. И возможные утечки - на вашей совести.

>Теперь смотрим... есть у нас например специализированый QSpecializedTextBrowser : public QTextBrowser в котором используются исключения... и любое непойманное внутри него исключение

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

>возникнет внутри QSplitter'а в конструкторе, или внутри любого другого контейнера в конструкторе ;-)... хе хе хе... так что аргументация мимо корзины.

Это каким же образом в конструкторе QSplitter'а будут создаваться ваши объекты QSpecializedTextBrowser ? Нету их там)

P.S. А вообще исключения - в топку. Не место им в хорошем ОО-коде. Разумеется IMHO.

>ANDI прав.

Чтобы создать контейнер со своими объектами, нужно сначала
создать контейнер, а потом уже пихать туда объекты. И тогда
лови исключения на здоровье. Можно, правда, замутить контейнер,
который инициализируется а-ля STL-е, т.е. по паре итераторов,
но в Qt таких нет. Так что, хе-хе-хе, на FAQ в trolltech.com
всё это описано :-)))

Таки да, тест methcall на яве под серверной ВМ выполняется в разы быстрее чем аналог на плюсах. Код на плюсах ИМХО вполне корректный. Компилировался как интеловским компилятором, так и и gcc. Странным показалось то, что возвращая в activate() Toggle по указателю, а не по ссылке производительность растет раза в два :-/ Интересно мнение плюсоведов, так как я сам пишу в основном на плюсах.

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

>>Только в том случае, если компилятор эту строчку не оптимизирует)
Компилятор эту строчку банально выкинет

>> Неправильно. Читаем Final International Draft Standard ISO/IEC 14882:1998(E), Programming languages -- C++

> Ты наверное забыл, что в QT все выделяется в куче, а не на стэке?

Нельзя забыть то, что не знаешь :-)

Всегда старался избегать QT, а теперь потихоньку получаю объективные подтверждения моему подсознательному неприятию :-)

>> Ну насмешил :-). А если в любом из их конструкторов эксепшн вылетит - они уберут мусор за собой? ;-)..

> В Qt исключения не используются. Вообще.

Не использование exception'ов не влечёт автоматическую защиту от них. Точно так же, как "голова в песок" не спасает страуса от опасности.

Exception сожет вздететь сам по себе, из каких-то "низлежащих" соображений языка, библиотеки языковой поддержки или посто стандартной библиотеки (libstdc++ или её аналога). Причём тот факт, что возможность запуска исключительной ситуации в каком-то случае не оговорен стандартом не спасает от необходимости от неё защишаться, ибо можно нарваться либо на расширения языка/библиотеки от какого-нибудь "доброго" производителя либо просто на новую версию стандарта, о которой в момент написания ты ничего не знал и её ещё и в проекте не было.

> P.S. А вообще исключения - в топку. Не место им в хорошем ОО-коде. Разумеется IMHO.

Это Вы комитету по стандартизации расскажите. Или предлагается переписать всю библиотеку поддержки языка?

>>Если exception не будет пойман внутри конструктора и вылетит наружу, >>то объект не будет создан... хотя operator new для него выполнится, а >>значит память будет уже выделена.

Ты сначала стандарт почитай прежде чем бредить в форуме !
Память в этом случае будет удалена.

>P.S. А вообще исключения - в топку. Не место им в хорошем ОО-коде.
>Разумеется IMHO.
Хм... предложите альтернативу? Только return коды не надо... во-первых их легко проигнорировать, а значит усугубить последствия ошибки... во-вторых они _чертовски_засоряют_код_.

>Соответственно, исключения обрабатывать вы уже должны, а не Qt. И
>возможные утечки - на вашей совести.
Разумеется. Но кто совершенен? Может быть вы? Я допускаю ошибки и все мои знакомые... в условиях враждебной среды работать труднее..

>Это каким же образом в конструкторе QSplitter'а будут создаваться ваши
>объекты QSpecializedTextBrowser ? Нету их там)
А вы посмотрите как в QT/KDE приложениях создаются и заполняются элементы... и в самой библиотеке большая часть визуальных компонент создается и размещается в конструкторе...

QT ничего общего с C++ и нормальным ООП не имеет. GTKmm если на то пошло гораздо идеологически вернее... хм ;-)... да и лицензионно ;-).

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

2adarovsky: может стоит выучить что такое виртуальный деструтор ?

>Всегда старался избегать QT, а теперь потихоньку получаю объективные
>подтверждения моему подсознательному неприятию :-)
Гм ;-). Там еще много интересного... например поведение QVector... если обратиться к элементу с номером QVector::size()+n (n>1) то получим SigSegv (это поведение несколько отличается от того, что имеем с std::vector?) :-).

>Можно, правда, замутить контейнер,
>который инициализируется а-ля STL-е, т.е. по паре итераторов,
Речь не об этом?
http://doc.trolltech.com/3.3/qobject.html#children

>>я сказал про вызов деструктора, а не про очистку памяти. Или мистер >>гений delete от operator delete не отлечает?
А вы мой юный друг exception в конструкторе от деструктора отлЕчаете ?

>А вы мой юный друг exception в конструкторе от деструктора отлЕчаете >?
Поговорите об этом с вашим юным другом.

> например поведение QVector... если обратиться к элементу с номером QVector::size()+n (n>1) то получим SigSegv (это поведение несколько отличается от того, что имеем с std::vector?

Нет, не отличается. std::vector не проводит проверку границ при использовании operator[] - для этого есть at()

>Не использование exception'ов не влечёт автоматическую защиту от них. Точно так же, как "голова в песок" не спасает страуса от опасности.

Не уж-то и -fno-exceptions не спасет?)

>Exception сожет вздететь сам по себе, из каких-то "низлежащих" соображений языка, библиотеки языковой поддержки или посто стандартной библиотеки (libstdc++ или её аналога). Причём тот факт, что возможность запуска исключительной ситуации в каком-то случае не оговорен стандартом не спасает от необходимости от неё защишаться, ибо можно нарваться либо на расширения языка/библиотеки от какого-нибудь "доброго" производителя либо просто на новую версию стандарта, о которой в момент написания ты ничего не знал и её ещё и в проекте не было.

Ок. Qt не будет работать со "стандартными" библиотеками С++, нарушающими стандарт С++. Только будет ли это проблемой Qt?

> Это Вы комитету по стандартизации расскажите. Или предлагается переписать всю библиотеку поддержки языка?

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

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

Исключения никогда не позиционировались, как альтернатива return-кодам. Во всяком случае, Страуструпом. Почитайте первоисточники (тот же "Дизайн") про longjmp() etc.

>Разумеется. Но кто совершенен? Может быть вы? Я допускаю ошибки и все мои знакомые... в условиях враждебной среды работать труднее..

Если вы не хотите обрабатывать свои же исключения - попробуйте их не генерить вовсе.

>А вы посмотрите как в QT/KDE приложениях создаются и заполняются элементы... и в самой библиотеке большая часть визуальных компонент создается и размещается в конструкторе...

Вам привести исходный код конструктора QSplitter'а ?

> QT ничего общего с C++ и нормальным ООП не имеет.
Что такое "нормальное" ООП? Qt использует подмножество стандартного С++ и свои расширения для дополнения языка динамической системой сообщений. То, что механизм сигналов-слотов не включили в стандарт С++ - не значит, что он плох или неэффективен. А расширять языки, даже стандартные, даже С++ никто не запрещает. Во всяком случае, так однажды поступил Страуструп со стандартным С...

>GTKmm если на то пошло гораздо идеологически вернее... хм ;-)
Мне главное, чтоб инструмент был эффективен. Вопросы идеологической верности в данном случае меня меньше интересуют. Что касается GTKmm - пробовал, не понравилось. Тем более, все: от документации - до API. Тем более, когда есть, с чем сравнивать...

>... да и лицензионно ;-).
GPL уже вне закона?)

#include <iostream>
#include <vector>
using namespace std;
int main(int argc, char ** argv){
vector<int> test;
test.push_back(1);
test.push_back(2);
test.push_back(3);
cout << test[5] << endl;
return 0;
}
$g++ a.cpp
$./a.out
0

Почему не SigSegv? :-)

> Исключения предлагается игнорировать, как неудачную (хоть и стандартную) конструкцию языка.

STL тоже предполагается игнорировать? (он, напомню, использует исключения)

> Почему не SigSegv? :-)

Потому что undefined behavior! =)

> Исключения никогда не позиционировались, как альтернатива return-кодам. Во всяком случае, Страуструпом

А что, исключения придумал Строуструп?

Кстати, я так и не понял, что вам в них не понравилось. Хотя конечно в языках типа C# и Java они смотрятся "более к месту", но там уже нужен трехступенчатый try-catch-finally (зато все высвобождение ресурсов явно и очевидно).

>Исключения никогда не позиционировались, как альтернатива
>return-кодам. Во всяком случае, Страуструпом. Почитайте первоисточники
>(тот же "Дизайн") про longjmp() etc.
Хм... дизайн читал давно уже... хорошо если настаиваете - проверю еще раз. И опять же exception - это не альтернатива return коду, но ему альтернативу и не надо... он при любом подходе найдет применение. Задача обратная.
Хм а чем longjump удобнее и лучше exception'a? Весь полный набор тех же проблем, без более удобного синтаксиса :-(.

>Если вы не хотите обрабатывать свои же исключения - попробуйте их не
>генерить вовсе.
Хочу. Но могу что-нибудь упустить.

>Вам привести исходный код конструктора QSplitter'а ?
Да у меня вообще-то и так есть :-). Вы меня уводите от темы... children у QWidget создаются в куче?

> Что такое "нормальное" ООП?
Нормальное, полагаю, - это такое где есть инкапсуляция, наследование и полиморфизм :-D.. С моей стороны это было лишь ответом на: "А вообще исключения - в топку. Не место им в хорошем ОО-коде. Разумеется IMHO." - такого же уровня категоричности и абсурдности заявление ;-). Разве что имхо не приписал ;-).

>Мне главное, чтоб инструмент был эффективен. Вопросы идеологической
>верности в данном случае меня меньше интересуют.
Идеологическая верность не только облегчает изучение и понимание, но и делает решение более легко портируемым. В частности GTKmm код собирается многими C++ компиляторами, а вот QT код без moc не собирешь.

> Тем более, все: от документации - до API. Тем более, когда есть, с
>чем сравнивать...
А что понравилось?

> GPL уже вне закона?)
LGPL - дает возможность работать в одних терминах на работе и дома.

> Потому что undefined behavior! =)
А как тебе вот это:

using namespace std;
int main(int argc, char ** argv){
vector<int> test;
test.push_back(1);
test.push_back(2);
test.push_back(3);
test[5] = 10;
cout << test[5] << endl;

return 0;
}
[exor@fail ttt]$ cat b.cpp
#include <iostream>
#include <qvector.h>

using namespace std;
int main(int argc, char **argv){
QVector<int> test;
int b = 10;
test.insert(5,&b);
// test[5] = 10;

cout << test[5] << endl;
}
[exor@fail ttt]$ cat Makefile
CC=g++

all: a b
a:
$(CC) -o a a.cpp
b:
$(CC) -L/usr/lib/qt-3.1/lib/ -I/usr/lib/qt-3.1/include/ -lqt b.cpp -o b
[exor@fail ttt]$ make
g++ -o a a.cpp
g++ -L/usr/lib/qt-3.1/lib/ -I/usr/lib/qt-3.1/include/ -lqt b.cpp -o b
[exor@fail ttt]$ ./a
10
[exor@fail ttt]$ ./b
QGVector::insert: Index 5 out of range
QGVector::operator[]: Index 5 out of range
Segmentation fault
[exor@fail ttt]$

И что это показывает, кроме того, что добрый QVector все-таки пытается вас спасти? =)

>>Не использование exception'ов не влечёт автоматическую защиту от них. Точно так же, как "голова в песок" не спасает страуса от опасности.

> Не уж-то и -fno-exceptions не спасет?)

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

2. приведите мне, пожалуйста, ещё хотябы один компилятр C++, кроме g++, который этот параметр понимает. Или Вы джумаете, что на GCC свет клином сошёлся?

>>Exception сожет вздететь сам по себе, из каких-то "низлежащих" соображений языка, библиотеки языковой поддержки или посто стандартной библиотеки (libstdc++ или её аналога). Причём тот факт, что возможность запуска исключительной ситуации в каком-то случае не оговорен стандартом не спасает от необходимости от неё защишаться, ибо можно нарваться либо на расширения языка/библиотеки от какого-нибудь "доброго" производителя либо просто на новую версию стандарта, о которой в момент написания ты ничего не знал и её ещё и в проекте не было.

> Ок. Qt не будет работать со "стандартными" библиотеками С++, нарушающими стандарт С++. Только будет ли это проблемой Qt?

Неправильно. Qt не будет работать со стандартными библиотеками _соблюдающими_ стандарт. Точнее, будет работать непредсказуемо и/или с утечкой ресурсов. Проблема ли это Qt, как по Вашему?

>> Это Вы комитету по стандартизации расскажите. Или предлагается переписать всю библиотеку поддержки языка?

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

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

>И что это показывает, кроме того, что добрый QVector все-таки пытается
> вас спасти? =)
От чего спасти?

"A vector is a Sequence that supports random access to elements, constant time insertion and removal of elements at the end, and linear time insertion and removal of elements at the beginning or in the middle. The number of elements in a vector may vary dynamically; memory management is automatic. Vector is the simplest of the STL container classes, and in many cases the most efficient."
http://www.sgi.com/tech/stl/Vector.html

stl вектор позволяет создавать практически динамические массивы. "QVector is a Qt implementation of an STL-like vector container. It can be used in your application if the standard vector is not available for your target platforms."
- так почему же поведение различается? Мало того, QVector не выполняет динамического выделения памяти... вообще не понятно что он делает???

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

А вот с этим согласен. Но уже ничего с этим сделать нельзя: "отлито из бронзы, руками не трогать" :-(

>А вот с этим согласен. Но уже ничего с этим сделать нельзя: "отлито из
>бронзы, руками не трогать" :-(
Ошибок нет только у тех, кто ничего не делает ;-)... Отказаться можно от exception'ов, от template'ов, от наследования, виртуальных функций... от операторов присвоения (вон ведь в функциональных языках отказались ;-))... можно вообще отказаться от програмирования... хех... по крайней мере exception'ы не несут такого количества ошибок, как threads.

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

Потому что доступ к элементу по индексу, лежащему за границей массива/вектора, приводит к undefined behavior. Т.е. та же прога с std::vector может (и имеет полное право) дать разные результаты на разных ОС, на одной ОС с разными компиляторами, и даже с одинм компилятором на двух последовательных запусках.

> Мало того, QVector не выполняет динамического выделения памяти... вообще не понятно что он делает???

Выполняет. Только для этого надо insert() вызывать с корректными аргументами.

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

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

>Т.е. та же прога с std::vector может (и имеет полное право) дать
>разные результаты на разных ОС, на одной ОС с разными компиляторами, и
> даже с одинм компилятором на двух последовательных запусках.
Слушай... я уже залез в ISO/IEC 14882:1998 стр 482 и далее ни о каком "undefined behavior." речи нет и быть не может. Идет reallocation и глобальный invalidation итераторов и ссылок. При обращении на чтение к несуществующему элементу выполняется дефолнтый конструктор. ГДЕ "undefined behavior"????

>Я думаю, что именно нежелание связываться с исключениями породило
>QTL.
У троллей написано, что отказ от STL обусловлен тем, что шаблоны слабо поддерживаются большинством компилятором. И по крайней мере когда начинали писать QT с шаблонами была засада везде, сейчас хоть в g++ стало получше.

>Выполняет. Только для этого надо insert() вызывать с корректными
>аргументами.
Почему при заявленой совместимости с std::vector поведение в корне различно???

> Кстати, я так и не понял, что вам в них не понравилось. Хотя конечно в языках типа C# и Java они смотрятся "более к месту", но там уже нужен трехступенчатый try-catch-finally (зато все высвобождение ресурсов явно и очевидно).

Все) До сих пор вспоминается пример с функцией из трех строк, которая имеет 17 ветвей исполнения. Я был в шоке, честно говоря, и одного этого аргумента мне хватило.

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

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

> Идет reallocation и глобальный invalidation итераторов и ссылок.

Это происходит при добавлении нового элемента. То есть либо push_back(), либо же insert(). Про operator[] ничего такого не говорится, зато в описании функции at() (в конце параграфа 23.1.1, сразу после таблицы) сказано: "The member function at() provides bounds-checked access to container elements. at() throws out_of_range if n >= a.size()". А если внимательно почитать Строуструпа, то там как раз и объясняется, что единственное различие между at() и operator[] в том, что последний не производит проверку на границы.

> При обращении на чтение к несуществующему элементу выполняется дефолнтый конструктор.

Это вы с std::map перепутали.

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

Генерируемые функцией исключения - это не часть реализации, а часть ее интерфейса (не зря в яве есть ключевое слово throws). Вы ведь параметры функции и тип возвращаемого значения не считаете деталями ее реализации?

> Почему при заявленой совместимости с std::vector поведение в корне различно???

QVector - это далеко не std::vector хотя бы уже потому, что работает исключительно с указателями.

А поведение различно потому же, почему на двух разных ОС следующий код вида "int a[5]; printf("%d", a[6]);" напечатает разное число, или просто вылетит с SIGSEGV.