только недавно утвердили С++11, но уже сейчас завалил комитет proposal`ами.

любопытно, чего еще не хватает программистам(кроме тех, кто инструментом пользоваться не умеет), и куда новые фитчи ведут ведут С++?

порадовала идея со static if () {} (1 и 2)

еще больше порадовал Sequential access to data members and base sub-objects: http://www.open-std.org/jtc1/sc22/wg21/doc.../2012/n3326.pdf

так же A Standard Programmatic Interface for Asynchronous Operations: http://www.open-std.org/jtc1/sc22/wg21/doc.../2012/n3327.pdf
еще Resumable Functions: http://www.open-std.org/jtc1/sc22/wg21/doc.../2012/n3328.pdf

кстати, после появления в стандарте многопоточности, пришла пора стандартизовать асинхронность ;)


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

зы
свежая, и абсолютно бесплатная версия драфта С++11 от 2012-01-16.

Это сообщение отредактировал(а) boostcoder - 17.2.2012, 00:40

вот и предложение о включении boost.filesystem: http://www.open-std.org/jtc1/sc22/wg21/doc...2012/n3335.html

Добавлено через 2 минуты и 26 секунд
и запрос стандартизовать транзакции. которые, кстати, реализованы в Intel и в GCC-4.7.0.

Добавлено через 9 минут и 19 секунд
просьба стандартизовать C++ Language Constructs for Parallel Programming. который реализован в компиляторах Intel и в форке GCC под названием CilkPlus. дока/спецификация.

и модули: Modules in C++.
и Scoping of operator new. хотя не очень понимаю смысла.. можно просто использовать new и delete в скопе транзакции.

boost.range  кто-то только сегодня говорил об этом.

Чего бы ещё хотелось - конструктор/деструктор для типа. Не для объекта, а именно для типа. В конструкторе, например, можно инициализировать статические члены класса.
В boost.filesystem реквестирую итерирование по каталогу по маске. Совершенно непонятно, почему они это не сделали   

покажи на примере. а то не понимаю..


ну хз.. может это вовсе не задача итератора... он же итератор.

что то типо этого :

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

вот ещё вспомнил (до-диез навеял) - если перед строкой в кавычках стоит символ @, то строка не ескейпится.
@"\\192.168.1.1:C:\temp\do\not\escape" вместо "\\\\192.168.1.1:C:\\temp\\do\\not\\escape"
для регэкспов два слеша для адреса в начале строка выглядит вообще ужасно
"\\\\\\\\(\\d+" и т.д.

а следующим будет точно c++12? Не с++14 или типа того?

следующим будет С++17. отредактировал топик 

но до него, как говорит комитет, для С++11 выйдет корректирующий документ.


Это сообщение отредактировал(а) boostcoder - 17.2.2012, 00:38

> отредактировал топик
опппппа… а как?

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

Хммм. Действительно. Интересно, а как это в шарпе решили (и решили ли) ?

это как? что-то до меня не доходит

Класс А использует поле класса Б, которое может быть неинициализировано. Точно такая же фигня при ручном создании "инициализаторов", когда нужно выполнить настройки до main.

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

Добавлено через 3 минуты и 32 секунды
В С++ дефакто это тоже можно через порядок файлов линковщику, но официально это undefined behaviour.

как отредактировал? или, что отредактировал?


с++ более строгий язык, использующий более строгие трактовки.

раньше в названии темы было С++12 (мне дажу уведомлялки на почту приходят с этим заголовком). Теперь в названии - С++17. Вот я и спрашиваю, как ты отредактировал название темы ?

P.S. ааааа. всё. разобрался. нужно просто нажать "редактировать" на первом же сообщении. своём ессно))

угу.

Каким образом ты отредактировал заголовок топика? У меня не получается...

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

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

будет.


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

порядок инициализации статических переменных - UB.

borisbn уже ответил.
просто клацаешь "редактировать" на топике. там же и название темы изменить можно.


у mes`а так вообще супер способности! он посты свои удалять может!  

Это сообщение отредактировал(а) boostcoder - 17.2.2012, 14:35

да, надо 1000

Было бы хорошо, если бы наконец ввели "правильные" указатели на методы - с привязкой к объекту (bound pointers to member functions). И синтаксис был бы интуитивней, и работы было бы меньше программистам (не пришлось бы использовать всякие boost::bind и boost::function).
Например:На физическом уровне такой указатель имеет фиксированный размер в 2 указателя:Фактически, это тоже самое, что и bind(&MyClass::method, &object, _1), но уже встроенное в язык.

Не трудно заметить, что данный указатель не зависит от типа базового класса!

Предложение от Borland: n1384

Это сообщение отредактировал(а) bsa - 20.2.2012, 16:38

bsa, да, логично.

В BCB такие есть - __closure называются. Насколько мне известно попытка продавить это в стандарт языка успехом не увенчалась   

Кроме того, есть некоторое количество библиотек, которые это реализуют (обычно под именем типа delegate_чего_нибудь или аналогичным)

Хотелось бы finally в стандарте и побольше возможностей для статических проверок.

Это сообщение отредактировал(а) azesmcar - 20.2.2012, 13:43

можно поточнее что имеет в виду этот хацкер под файлами и инициализаторами?
Если "инициализатор внутри файла" это конструктор класса, то компилятор всё-таки делает попытку упорядочить вызовы так чтобы избежать использования класса до того, как будет вызван его конструктор. Если там циклическая ссылка, то всё равно всё плохо


Это сообщение отредактировал(а) bems - 20.2.2012, 14:12

Когда пересекусь, спрошу, если не забуду. По памяти: есть функции со специальным именем - Initizalization или не знаю как, - они выполняются в начале работы программы, их порядок можно как-то задать, например в одном модуле ты создаешь объект в инициализаторе, в другом - как-то его настраиваешь (пример из пальца).

Тут про функции гоdорят... Хочу а) нормальную ламбду с замыканием, б) нормальную переменную-функцию, в которую (с определенной сигнатурой) можно было бы хранить функцию и указатель на метод, связанный с объектом (то, о чем bsa писал), в) продолжения. Надоело на коленке каждый раз все это городить.

Добавлено через 1 минуту и 12 секунд
Но я, как известно, никто и мою "хочу" никого не ебеинтересует.

ну да, там порядок задаётся. Но вообще оно не для этого. 

Видимо имеется в виду то, что в Delphi unit (это модуль, которых увы нету в С++) должен явно указывать все unit'ы, которые он использует. И на этапе линковки инициализация всех unit'ов программы выполняется с учетом их зависимостей.

да, но это не то, о чем была речь. Речь была именно о конструкторах классов (не экземпляров), а это другое (хотя реализовано почти так же)

Добавлено через 5 минут и 15 секунд
я бы так смело не говорил на каком этапе

Конечно не увенчалась. 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++ и это не нужно, т.к.

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

Не суть, моя основная мысль была про автоматический вызов деструктора и соответственно ненужность finally.

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

Еще бы очень хотелось иметь возможность создавать строковые темплейты:

их и сейчас можно.

хотелось бы литералы использовать

Не совсем то. Необходимо создавать переменные, а хотелось бы без них.
Для чего мне это нужно:

Но все упирается в строковый шаблон

Добавлено через 3 минуты и 19 секунд
Как только я узнал про литералы - у меня сразу родилась идея создать литерал создающий строку в кодовой памяти, но через пол часа мучений я понял, что это не возможно из-за вышеуказанного ограничения с темплетами

Это сообщение отредактировал(а) Ivan. - 23.5.2012, 12:18

считай хеш-сумму строки в копайл-тайме, и используй ее для ассоциации со строкой.

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

но и тут вылезает непонятная ошибка:
Error    1    in convert_nontype_argument, at cp/pt.c:5780

В принципе суровой необходимости в scope нет, но иногда работаешь с функциями и нет смысла писать класс только для связки парных функций и проще написать:

весь код ясен в месте написания, не надо смотреть класс - при выходе по любой причине из текущего блока компилятор вызовет close(). 
Но, безусловно, это не самая потрясающая фича для языка, просто сравнил с finally.

очень информативно %)