Форум программистов [Powered by Invision Power Board]

Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате

Форум программистов > C/C++: Общие вопросы > куда "идет" С++11 и С++17 ?

Автор: boostcoder 13.2.2012, 01:37

только недавно утвердили С++11, но уже сейчас http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/.

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

порадовала идея со static if () {} (http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3322.pdf и http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3329.pdf)

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

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

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

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

зы
свежая, и абсолютно бесплатная версия http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3337.pdf от 2012-01-16.

Автор: boostcoder 13.2.2012, 01:58

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

Добавлено через 2 минуты и 26 секунд
и запрос стандартизовать http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3341.pdf. которые, кстати, реализованы в Intel и в GCC-4.7.0.

Добавлено через 9 минут и 19 секунд
просьба стандартизовать http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3345.htm. который реализован в компиляторах Intel и в форке GCC под названием http://gcc.gnu.org/viewcvs/branches/cilkplus/. http://software.intel.com/en-us/articles/intel-cilk-plus/.

Автор: boostcoder 13.2.2012, 02:14

и модули: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3347.pdf.
и http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3348.pdf. хотя не очень понимаю смысла.. можно просто использовать new и delete в скопе транзакции.

http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n3350.html smile

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

Автор: borisbn 16.2.2012, 10:40

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

Автор: boostcoder 16.2.2012, 10:47

Цитата(borisbn @ 16.2.2012, 10:40

)

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

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

Цитата(borisbn @ 16.2.2012, 10:40

)

В boost.filesystem реквестирую итерирование по каталогу по маске. Совершенно непонятно, почему они это не сделали

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

Автор: mes 16.2.2012, 11:10

Цитата(boostcoder @ 16.2.2012, 09:47

)

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

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

Код


struct A 
{
   static int i;
};
int A::i=5;

Код


struct A 
{
   static int i;
   
   static A () : i (5) {}   
};

Автор: borisbn 16.2.2012, 13:44

Цитата(mes @ 16.2.2012, 11:10

)

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

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

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

Автор: serghd 17.2.2012, 00:14

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

Автор: boostcoder 17.2.2012, 00:23

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

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

Автор: borisbn 17.2.2012, 06:14

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

Автор: bsa 17.2.2012, 10:29

Цитата(borisbn @ 16.2.2012, 11:40

)

Чего бы ещё хотелось - конструктор/деструктор для типа. Не для объекта, а именно для типа.

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

Автор: borisbn 17.2.2012, 10:36

Цитата(bsa @ 17.2.2012, 10:29

)

Есть один подводный камень - порядок инициализации.

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

Автор: 502 17.2.2012, 10:44

Цитата(bsa @ 17.2.2012, 10:29

)

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

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

Автор: newbee 17.2.2012, 10:47

Цитата(502 @ 17.2.2012, 11:44

)

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

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

Добавлено через 2 минуты и 13 секунд
А вот в делфи, smile

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

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

Автор: boostcoder 17.2.2012, 14:05

Цитата(borisbn @ 17.2.2012, 06:14

)

опппппа… а как?

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

Цитата(newbee @ 17.2.2012, 10:47

)

но официально это undefined behaviour

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

Автор: borisbn 17.2.2012, 14:18

Цитата(boostcoder @ 17.2.2012, 14:05

)

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

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

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

Автор: boostcoder 17.2.2012, 14:20

угу.

Автор: newbee 17.2.2012, 14:22

Цитата(boostcoder @ 17.2.2012, 15:05

)

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

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

Цитата(boostcoder @ 17.2.2012, 15:05

)

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

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

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

Автор: boostcoder 17.2.2012, 14:30

Цитата(newbee @ 17.2.2012, 14:22

)

я просто хотела сказать, что в рамках языка линковщика нет

будет.

Цитата(newbee @ 17.2.2012, 14:22

)

Я не понимаю, что ты имеешь в виду

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

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

Автор: boostcoder 17.2.2012, 14:34

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

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

Автор: 502 17.2.2012, 14:38

Цитата(mes @ 17.2.2012, 14:32

)

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

да, надо 1000

Автор: bsa 18.2.2012, 13:44

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

Код

bool (class *method)(int); //мое виденье синтаксиса, но я не настаиваю
...
method = &object.method; //получение - просто и элегантно
...
if (method(10)) //вызов - опять же просто и элегантно
   ...

bool (MyClass::*method2)(int);
method2 = &MyClass::method;
method = &object.(*method2); //получение "правильного" из "обычного"
method2 = static_cast<bool (MyClass::*)(int)>(method); //допустимо только явное преобразование при обратной операции
MyClass *p = static_cast<MyClass*>(method); //допустимо только явное преобразование

На физическом уровне такой указатель имеет фиксированный размер в 2 указателя:

Код

struct {
   void *object;
   bool (*function)(void*,int);
};

Фактически, это тоже самое, что и bind(&MyClass::method, &object, _1), но уже встроенное в язык.

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

Предложение от Borland: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1384.pdf

Автор: boostcoder 18.2.2012, 17:15

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

Автор: xvr 20.2.2012, 13:37

Цитата(bsa @ 18.2.2012, 13:44

)

Было бы хорошо, если бы наконец ввели "правильные" указатели на методы - с привязкой к объекту.

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

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

Автор: azesmcar 20.2.2012, 13:42

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

Автор: bems 20.2.2012, 14:04

Цитата(newbee @ 17.2.2012, 10:47

)

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

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

Автор: newbee 20.2.2012, 14:21

Цитата(bems @ 20.2.2012, 15:04

)

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

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

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

Автор: bems 20.2.2012, 14:25

Цитата(newbee @ 20.2.2012, 14:21

)

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

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

Автор: xvr 20.2.2012, 14:28

Цитата(bems @ 20.2.2012, 14:04

)

можно поточнее что имеет в виду этот хацкер под файлами и инициализаторами?

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

Автор: bems 20.2.2012, 14:30

Цитата(xvr @ 20.2.2012, 14:28

)

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

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

Цитата(xvr @ 20.2.2012, 14:28

)

И на этапе линковки

я бы так смело не говорил на каком этапе

Автор: bsa 20.2.2012, 16:46

Цитата(xvr @ 20.2.2012, 14:37

)

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

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

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

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

Автор: boostcoder 20.2.2012, 17:35

Цитата(xvr @ 20.2.2012, 13:37

)

попытка продавить это в стандарт языка успехом не увенчалась

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

Цитата(azesmcar @ 20.2.2012, 13:42

)

Хотелось бы finally в стандарте

что это?

Автор: azesmcar 20.2.2012, 17:43

Цитата(boostcoder @ 20.2.2012, 17:35

)

что это?

Код


try
{
   // пытаемся
} catch (...)
{
   // срабатывает при исключении
} finally
{
   // срабатывает всегда
}

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

Автор: boostcoder 20.2.2012, 18:02

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

Автор: bsa 20.2.2012, 20:21

Цитата(boostcoder @ 20.2.2012, 18:35

)

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

Цитата(bsa @ 18.2.2012, 14:44

)

Предложение от Borland: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2002/n1384.pdf

Автор: boostcoder 20.2.2012, 22:55

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

несколько дней тому, началось обсуждение планов и принципов развития стандартной библиотеки С++: http://thread.gmane.org/gmane.comp.lib.boost.devel/228312

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

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 секунд
хотя по поводу модулей, я что-то не въехал.. это же в основном поддержка со стороны препроцессора/компилятора, а не со стороны библиотек...

Автор: boostcoder 21.2.2012, 03:19

Цитата(azesmcar @ 20.2.2012, 13:42

)

Хотелось бы finally в стандарте

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

Автор: borisbn 21.2.2012, 08:18

Цитата(boostcoder @ 20.2.2012, 22:55

)

это же в основном поддержка со стороны препроцессора/компилятора

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

Автор: sergioK1 22.5.2012, 18:07

Цитата(bsa @ 18.2.2012, 12:44)

Код

bool (class *method)(int); //мое виденье синтаксиса, но я не настаиваю
...
method = &object.method; //получение - просто и элегантно
...
if (method(10)) //вызов - опять же просто и элегантно
   ...

bool (MyClass::*method2)(int);
method2 = &MyClass::method;
method = &object.(*method2); //получение "правильного" из "обычного"
method2 = static_cast<bool (MyClass::*)(int)>(method); //допустимо только явное преобразование при обратной операции
MyClass *p = static_cast<MyClass*>(method); //допустимо только явное преобразование

На физическом уровне такой указатель имеет фиксированный размер в 2 указателя:

Код

struct {
   void *object;
   bool (*function)(void*,int);
};

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

С++ 12 придумали в 1995году, под названием Java smile

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

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

Автор: volatile 23.5.2012, 00:33

Цитата(sergioK1 @ 22.5.2012, 18:07

)

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

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

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

Автор: sergioK1 23.5.2012, 08:51

Цитата(volatile @ 22.5.2012, 23:33)

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

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

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

Автор: k0rvin 23.5.2012, 09:24

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

Автор: drug007 23.5.2012, 10:04

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

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

) статически линковать с объектным кодом других языков.

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

Автор: k0rvin 23.5.2012, 11:09

Цитата(drug007 @ 23.5.2012, 10:04)

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

Код


try {
    ...
} catch (IOException e) {
    ...
} catch (Exception e) {
    ...
} finally {
    ...
}

Цитата(drug007 @ 23.5.2012, 10:04)

В этом плане, на мой взгляд, эффективнее подход D с его выражением scope(), погармоничнее finally.

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

Код


void foo() {
    File* file = new File("/path/to/file");
    FileOwner owner(file); // в конструкторе FileOwner файл открывается
    try {
        // работаем с файлом
    } catch (...) {
        // обрабатываем исключение
    }
} // автоматический вызов деструктора ~FileOwner, который закроет файл и удалит объект file

Автор: bsa 23.5.2012, 11:16

Цитата(k0rvin @ 23.5.2012, 12:09

)

File* file = new File("/path/to/file");
FileOwner owner(file); // в конструкторе FileOwner файл открывается

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

Код

File file("/path/to/file");
if (!file.open(<флаги открытия>) {
 ...
}
...

Автор: k0rvin 23.5.2012, 11:25

Цитата(bsa @ 23.5.2012, 11:16)

Цитата(k0rvin @ 23.5.2012, 12:09

)

File* file = new File("/path/to/file");
FileOwner owner(file); // в конструкторе FileOwner файл открывается

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

Код

File file("/path/to/file");
if (!file.open(<флаги открытия>) {
 ...
}
...

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

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

Автор: Ivan. 23.5.2012, 11:37

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

Код

template<const char Str[]>
struct TStruct {
    static const char* T = Str;
};

Автор: sergioK1 23.5.2012, 11:45

Модератор: Сообщение скрыто.

Автор: baldina 23.5.2012, 11:49

Цитата(Ivan. @ 23.5.2012, 11:37

)

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

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

Код


#include <iostream>
template <const char *S>
struct foo {
  static void echo () { std::cout << S << std::endl; }
};

char Hello[] = "Hello";
char World[] = "World";

int main () {
  foo<Hello>::echo();
  foo<World>::echo();
}

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

Код


#include <iostream>
template <const char *S>
struct foo {
  static void echo () { std::cout << S << std::endl; }
};

int main () {
  foo<"Hello">::echo();
  foo<"World">::echo();
}

Автор: Ivan. 23.5.2012, 12:17

Цитата(baldina @ 23.5.2012, 11:49

)

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

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

Код


struct TStruct {
    const char* Name;
    ...
};
extern const char PROGMEM Name1[];
const char Name1[] = "Abcd";
const TStruct S = {Name1, ...};
//А хочется вот так:
const TStruct S = {TProgMemString<"Abcd">::Text, ...};
//А с литералами еще лучше:
const TStruct S = {"Abcd"_ProgMem, ...};

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

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

Автор: boostcoder 23.5.2012, 12:27

считай http://forum.try-catch.ru/index.php?topic=931.0, и используй ее для ассоциации со строкой.

Автор: Ivan. 23.5.2012, 16:54

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

Код


template<const char *s, size_t N> struct     TProgStr;
template<const char *s          > struct     TProgStr<s, 2>{static const char PROGMEM T[2];};
template<const char *s          > const char TProgStr<s, 2>::T[2] = {s[0], s[1]};

template<size_t N> constexpr const char* ProgStr   (const char (&s)[N]);
template<        > constexpr const char* ProgStr<2>(const char (&s)[2]){return TProgStr<s, 2>::T;}
const char* T = ProgStr("a");

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

Автор: drug007 23.5.2012, 18:47

Цитата(k0rvin @ 23.5.2012, 11:09)

Цитата(drug007 @ 23.5.2012, 10:04)

В этом плане, на мой взгляд, эффективнее подход D с его выражением scope(), погармоничнее finally.

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

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

Код


  scope(exit) {
     close(file);
  }
  file = open("/path/to/file");

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

Автор: boostcoder 23.5.2012, 22:10

Цитата(Ivan. @ 23.5.2012, 16:54

)

Error 1 in convert_nontype_argument, at cp/pt.c:5780

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