Небольшая информация. Трехгодичный мораторий на внесение измений стандарта окончился и сейчас идет работа по внесению изменений. Информацию о текущем положении дел можно подчерпнуть отсюда
http://std.dkuug.dk/jtc1/sc22/wg21/docs/pa...402.html#hickey
http://www.cuj.com/documents/s=8890/cujexp0310sutter/
http://www.cuj.com/documents/cujcexp0308sutter/

Лично меня порадовало внесение в стандарт(пока в черновной вариант) шаблонного класса function, в частности облегчающего работа с указателями на метод класса
Например.

Код

string AppendA( string s ) { return s + 'a'; } class B { public:  virtual string AppendB( string s ) { return s + 'b'; } }; class Derived : public B {  string AppendB( string s ) { return s + "bDerived"; } }; class Name { public:  Name( string s ) : s_( s ) { }  string Get() const { return s_; } private:  string s_; }; const char* AppendD( const Name& s ) {  static string x;  x = s.Get() + 'd';  return x.c_str(); } string test = "test"; B b; Derived der; function<string (string)> f;                                                                 f = &AppendA;                                 cout << f( test ) << endl; f = bind1st( mem_fun( &B::AppendB ), &b ); cout << f( test ) << endl; f = bind1st( mem_fun( &B::AppendB ), &der ); cout << f( test ) << endl;                     f = c;                                         cout << f( test ) << endl; f = &AppendD;                                 cout << f( test ) << endl;

Замена __closure от Borland выглядела примерно так

Код

//typedef void  (__closure * TNotifyEvent)(TObject* Sender); typedef function< void(TObject*) > TNotifyEvent; ... void TForm1::Button1Click(TObject* Sender) { ... } void Click(TObject* Sender) { ... } //Button1->OnClick = Button1Click; Button1->OnClick = bind1st( mem_fun( &TForm1::Button1Click ), this ); //Button1->OnClick = Form2->Button1Click; Button1->OnClick = bind1st( mem_fun( &TForm2::Button1Click ), Form2 ); //а вот этого closure не мог Button1->OnClick = &Click;

Fantasist BRAVO:) I krome vsego vi je sebe predstavljajete chto napisannij kod doljen kto-to i chitat`, i po semu kak vi sebe predstavljajete ser`jeznie (imeetsja v vidu razmer koda) swich, if i drugie s bol`shim kolichestvom break-ov ili continue-ov, nu tut i zrenie isportit` mojno:) GOD BLESS C++ jazik v kotorij sam je sposoben ispravit` vse svoi nedostaki:)

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

• JAVA: если функция кидает Exception, то она должна быть соответственно задекларирована.
  Если юзер вызывает такую функцию, он ОБЯЗАН работать с try catch. К сожалению в Си++ это не так Хотим кидаем хотим ловим.
• Хотелось бы иметь возможность работать с ММХ и расширениями SSE.
• Неплохо было бы иметь возможность указывать операции, которые могут выполняться параллельно. Как например в VHDL (хотя конечно назначение VHDL другое).

Пока всё...

Цитата

Если юзер вызывает такую функцию, он ОБЯЗАН работать с try catch. К сожалению в Си++ это не так  Хотим кидаем хотим ловим.

Не вижу недостатка в этом. Это даже к лучшему.
Например, вызываю функцию 1 (при этом она в try..catch), та в свою очередь использует сотни функций, каждая из них может выкинуть исключение - и что, каждый раз ставить try..catch ? И еще в каждом catch ставить throw, чтобы основная прога (которая вызвала ф-ию 1) тоже поймала исключение ?
Какая-то ерунда... Программист - не дурак, сам знает, когда и где ему ожидать исключений, а специально "тыкать носом" его, по-моему, абсурд.

Цитата

Хотелось бы иметь возможность работать с ММХ и расширениями SSE.

А кто мешает ? Асм-вставки давно не новинка...

по поводу switch, было бы неплохо что бы его расширили до испосльзования
всех пользовательских типов реализующих operator==,

еще хотелось бы безимянных функций (лямбда ф-ий, как boost::lambda),

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

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

шаблоны сканера и парсера тоже не помешали бы (boost::tokenizer, boost::spirit)

да, механизм сигналов и слотов, для GUI приложений очень удобно, реализовано в Qt,
там они транслируются в C++ код.

2 p0s0l

Цитата

Например, вызываю функцию 1 (при этом она в try..catch), та в свою очередь использует сотни функций, каждая из них может выкинуть исключение - и что, каждый раз ставить try..catch

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

2 achmed

Цитата

java прграммы буквально загромождаютсяблоками try..catch

Если нормально сдвигать, то это не проблема ИМХО. Всё аккуратно и понятно.

2 p0s0l

Цитата

Асм-вставки давно не новинка...

Вот именно, АСМ а не Си. Я согласен с тобой, что любой может написать свою функцию с вставкой АСМ. Просто Анзи Си обеспечивает интероперабилитет (Не знаю как АСМ. если так же, прошу считать пункт закрытым).

2 achmed

Цитата

по поводу switch, было бы неплохо что бы его расширили до испосльзования всех пользовательских типов реализующих operator==

Это на много облегчило бы жизнь и улучшило читабельность кода ИМХО.


Ребята, спасибо за интересную раскладку!

Цитата

JAVA: если функция кидает Exception, то она должна быть соответственно задекларирована. Если юзер вызывает такую функцию, он ОБЯЗАН работать с try catch. К сожалению в Си++ это не так  Хотим кидаем хотим ловим.

Здесь я бы согласился, но это пока не отвечает духу С++. После недолгой работы с Java я понял что фича очень стоящая. Она заранее заставляет задуматься о грамотной иерархии обработки ошибок, да и действиетльно выглядит гораздо нагляднее. Всем четко известно, что ловить, и все обязаны это ловить. Повышает стабильность. Но все-таки это не в стиле языков подобных С++. Даже если взять только исторические причины, то очень много старого кода оказалось бы невозможно использовать при добавлении такой фичи. Java все-таки отдельный разговор (был, во всяком случае, пока не появился С#) .

Цитата

Fantasist ..очень много старого кода оказалось бы невозможно использовать при добавлении такой фичи..

К сожалению это действительно так! Примерно как с телевизорами. Eщё много лет будем юзать ужасные PAL/SECAM, хотя современная технология позволяет значительные расширения разрешаюшей способности, итд,итп.
Вообще изменение стандарта дело нелёгкое из за хвостов. А ЯВА была написана с нуля и к счастью концептуально, хотя казалось бы главной задачей был именно интероперабилитет. Совершенно согласен, что не надо из Си++ делать ЯВУ, но кое чему стоило бы поучиться.

стандарт предусматривает спецификацию исключений, но не обязывает реализовывать.
http://www.codeproject.com/useritems/stdexceptionspec.asp

Если будет добавлена поддержка свойств на уровне синтаксиса языка - это будет просто рулез !!! Под свойствами я имею ввиду:

Цитата

class A {    private:       int   m_x;    public:       int x       {          get          {             // какие-то действия, связанные с чтением свойства "x"              return  m_x;          }          set          {              m_x = value;             // какие-то действия, связанные с записью свойства "x", например:              MessageBox(0, "x изменилось !", 0, MB_OK);          }       } }; void main() {   A  obj;   obj.x = 1;   int  y = obj.x; }

("новые" ключевые слова выделены курсивом)

В C# и ManagedC++ это действительно рульная фича, вот если бы в стандарте С++ было такое ...

По поводу использования MMX(SSE) - было бы приятно, если бы в STL включили стороннюю библиотеку типа Intel Small Matrix Library.
По поводу перегрузки с помощью overload, в старых версиях компиляторов оное ключевое слово было, однако отказались, посчитав избыточным. Пусть лучше компилятор выводит статистику для перегруженных функций типа

func1 - n overloads
func2 - m overloads и т.д.

Цитата

achmed стандарт предусматривает спецификацию исключений, но не обязывает реализовывать.

Ну так меня почти устраивает.

Вот только жаль..

Цитата

stdexceptionspec Exception specifications are not checked at compile time - they are enforced at run time.

Ведь типы проверяются, почему исключения не могут?