Текущий Стандарт С++ и перспективы его развития

Цитата Axis @ 28.06.13, 04:19

Ноябрьский CTP компилятор?

Глючная полурабочая поделка. На вариадиках я его особо не гонял, но к примеру tuple с более чем 7 шаблонными аргументами он не переварил.
Unified initialization работает только в тривиальных случаях. Defaulted и deleted функций вообще нет, и что-то я не нашел упоминания о них в статье по ссылке.

Цитата Axis @ 28.06.13, 04:19

Ноябрьский CTP компилятор?

Похоже на то в ноябрьском вариадики сделаны на каком-то очень сильном макро-колдунстве, ЕМНИП

Цитата applegame @ 29.06.13, 04:50

в ноябрьском вариадики сделаны на каком-то очень сильном макро-колдунстве

Лолшто? Какими такими макрухами он мне компилил

template<class... T>
struct V {};

?

Цитата MyNameIsIgor @ 30.06.13, 03:11

Цитата applegame @ 29.06.13, 04:50

в ноябрьском вариадики сделаны на каком-то очень сильном макро-колдунстве

Лолшто? Какими такими макрухами он мне компилил

template<class... T>
struct V {};

?

applegame, наверное, говорит о стандартной библиотеке. Там действительно все на макросах.

Цитата Kray74 @ 30.06.13, 05:41

applegame, наверное, говорит о стандартной библиотеке. Там действительно все на макросах.

Он говорит про ноябрьский CTP, а там шёл только компилятор

Скажите, а вот такое присваивание сильно актуально, планируется? :

int a[10];
...
a[4..6] = {12,-4,80};

Сообщение отредактировано: Славян - 02.09.13, 15:09

это делается при помощи std::tuple и/или std::tie(). зачем это вносить в язык?

Добавлено 02.09.13, 15:13
можно закодить функцию, которая будет использоваться так:

int arr[10];
slice<from, to>(arr, 12,-4,80);

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

или так(хотя тут не уверен):

slice<from, to>(arr) = {12,-4,80};

Добавлено 02.09.13, 15:16

Цитата MyNameIsIgor @ 02.09.13, 15:13

это срез, кортежем не воспроизводится

ааа, ну да. тогда при помощи fusion::vector и fusion::tie

Так

valarray<int> a(10);
...
a[slice{4,3,1}] = {12,-4,80};

Правда дурацкий этот valarray.

Добавлено 02.09.13, 15:21
Упс. Опоздал.

Хотя не, тут другое немного. Пусть будет

Добавлено 02.09.13, 15:36

Цитата MyNameIsIgor @ 02.09.13, 15:13

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

Ну если их использовать примерно так же, как boost::tie, то никаких проблем быть не должно.

Сообщение отредактировано: D_KEY - 02.09.13, 15:36

А "освобождение памяти определенного размера" (для глобального delete) зачем нужно?

Только чтобы позволить аллокатору не хранить размер выделенной памяти?
Или есть другие мотивы?

В чем плюсы?
А то минус очевиден - обилие багов от несовпадения размеров памяти впри выделении и освобождении.

Сообщение отредактировано: amdei - 11.11.13, 06:20

А появится что-то типа utf32 или qchar_t ?

Добавлено 11.11.13, 06:24
Блин, наверное правильнее utf32==dchar_t, но qchar_t краше...

Будут char16_t и char32_t.

Хотя, почему будут? В GCC и Clang уже есть, только Visual Studio, как всегда, в роли догоняющего.

Сообщение отредактировано: Kray74 - 11.11.13, 06:28

Не, dchar_t это как бы wchar_t, а правильнее utf32==dwchar_t, но очень не красиво...

Добавлено 11.11.13, 06:33

Цитата Kray74 @ 11.11.13, 06:26

Хотя, почему будут? В GCC и Clang уже есть, только Visual Studio, как всегда, в роли догоняющего.

Ясно, спасибки. Просто цифры в именах неприятны, хотелось полностью буковками...

Цитата Славян @ 11.11.13, 06:30

Просто цифры в именах неприятны, хотелось полностью буковками...

Надо с собой бороться. Циферьки - очень правильное решение, потому что фиксируют количество бит, которыми описывается тип. А вот буковки - они, на самом деле, малоинформативны.