Конечно не увенчалась. Borland решила одним документом провести три "фичи":
- bound pointers to member functions
- properties (надстройка над геттерами/сеттерами)
- Enriched RTTI (тип доступа класса - published)

Все что я нашел, это дело закончилось "предложение не готово для включения в C++0x, но может быть перерассмотрено позже".

На comp.std.c++ шли довольно жаркие дискуссии по поводу этих указателей. Александреску в 1999 году какую-то нерабочую хрень в виде шаблона closure<>  и кучи наворотов предлагал. И все это вместо того, чтобы внести в стандарт такую простую и очевидную вещь! Да, у нее есть недостатки, например: неочевиден синтаксис в случае присутствия перегруженных методов (но он и для существующих указателей не особо очевиден).

не замечал такого предложения..


что это?

на сегодняшний день RAII заменяет отсутствие finally в стандарте языка, но иногда использовать finally проще и логичнее.

ну да, это нужно.
но признаюсь, так же не видел этого предложения..

хорошая новость!

несколько дней тому, началось обсуждение планов и принципов развития стандартной библиотеки С++: TR2 is dead; multiple TR's coming instead.

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

• SG1: Concurrency and Parallelism (chair: Hans Boehm). This is the old Concurrency sub-group.
• SG2: Modules (chair: Doug Gregor). A new sub-group of the committee's evolution working group (EWG).
• SG3: File System (chair: Beman Dawes). A LWG sub-group to handle the Boost.Filesystem work item approved at the meeting.
• SG4: Networking (chair: Kyle Kloepper). A LWG sub-group to handle the Boost.Asio work item approved at the meeting.

модули!
файловая система!!
сеть!!!

Добавлено через 3 минуты и 27 секунд
хотя по поводу модулей, я что-то не въехал.. это же в основном поддержка со стороны препроцессора/компилятора, а не со стороны библиотек...

мнение Страуструпа по этому поводу: http://www2.research.att.com/~bs/bs_faq2.html#finally

Это ж здорово! Чем больше требований к компилятору введут в стандарт, тем проще будет писать кросскомпиляторные программы. К тому же там наверняка будут требования к оформлению модулей в коде

типа Java/C# reflection ? 
Осталось еще все сделать все функции virtual, segmentation fault  отлавливать в сatch и GC добаваить , и  все нету больше С++    

С++ 12 придумали в 1995году, под названием Java    правда так и недоделали нормальную возможность прямого доступа к памяти,  похоже комитет хочет имеено этого ,

т,е С++ станет улучшенной/не тормозной версией жавы, а сама жава перейдет в скалу,
С останеться как был и гап между ним и С++ вырастет , и кто то должен будет его заполнить, 
мне пока не понятно , 





Это сообщение отредактировал(а) sergioK1 - 22.5.2012, 18:15

Дык пока вроде ничего значительно нарушающего обратную совместимость не приняли? или я ошибаюсь?
Так что можно писать в любом стиле покрывающем широкий гап от С до С++12

Думаю и указатели не приняли чтоб сохранить обратную совместимость.

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

Зачем finally при наличии RAII?

finally, имхо, неудачная реализация хорошей идеи. Иногда нужно обработать и общий случай с помощью finally, и конкретную ошибку c помощью catch и по дельфям помню, что получались некрасивые многоэтажные вложенные конструкции из finally и except (дельфийский  catch), на пару строк кода могло выйти 6-7 строк этих самых конструкций. В этом плане, на мой взгляд, эффективнее подход D с его выражением scope(), погармоничнее finally.

А вообще язык переусложняется и обратная совместимость начинает тяготить язык и усложнять жизнь разработчикам компиляторов. Рано или поздно языку придется отказаться от обратной совместимости, иначе язык задохнется под своей же тяжестью. Неплохо было бы все-таки ввести стандарт на ABI, принять модули и реализовать выбор версии языка для модуля (если рантайм у версий языка один и тот же, это не будет сложно). Тогда можно будет обеспечить совместимость не усложняя язык и мешая все в кучу, а просто раздельно компилировать модули с учетом версии языка, используемой в данном модуле. На уровне компоновщика уже разницы между стандартами не будет и он все слинкует. Главное стандарт на ABI. Тогда можно будет даже (иногда  ) статически линковать с объектным кодом других языков.

Главное, сборщик мусора не вводить в стандарт .

Просто в делфе убогий синтаксис и разделение try ... except и try ... finally. В более нормальных языках это выглядит примерно как



В C++ и это не нужно, т.к.

Велосипед. Обычно делают так: