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

[Qraizer]

Ошибаешься, niXman. Это тоже стереотип. Массив символов - это массив, который хранит символы. Массив в первую очередь контейнер, хранящий элементы одного типа - в частности char или там char16_t итп - последовательно без перекрытий и пропусков. Строка по определению хранит только символы и ни что другое. И при этом как контейнер это отнюдь не массив. Она может быть представлена массивом, но отнюдь не обязательно.
В C не было типа строк, поэтому вместо них использовали почти исключительно массивы символов, которые на строки похожи. Т.к. строки в общем могут иметь произвольную длину, в частности определяемую в run-time, то в виду того, что динамические массивы в C нигде не хранят длину, решили строки хранить в ASCIIZ-форме, с NUL на конце, причём молчаливо предполагая, что как часть строки этот NUL использоваться не может. Не слишком ли много условностей? Этот стереотип так закрепился, что теперь мы все имеем две проблемы.
Во-первых, std::basic_string<> свободен от всех недостатков C-строк. Это не массив, не ASCIIZ и без условностей NUL. Хранит любые символы, в любом количестве, как и любой контейнер знает, сколько он их хранит... в C++98-C++03 не было даже требования хранить символы последовательно. Собственно а зачем? Есть итераторы, есть индексация, для связи с legacy-кодом дали std::basic_string<>::data() и std::basic_string<>::c_str(), обе const, ибо они отнюдь не обязаны возвращать свой сторадж, тот вообще может быть представлен как угодно, например в виде списка деков, что весьма удобно для оптимизаций операций вставки/удаления/замещения частей строк, т.е. операций, ожидаемо часто выполняющихся над строками, в отличие от массивов. И оговорили условия, при которых возвращаемый ими std::basic_string<>::const_pointer перестаёт быть валидным. Во-вторых, стереотип настолько глубоко проник во всевозможные API, что представление строк в виде массивов стало чем-то само собой разумеющемся, в результате оказалось проще вернуть в C++11 гарантию последовательности хранения символов в std::basic_string<>. Пусть даже от стереотипа можно избавиться, программа по-любому часто взаимодействует с API, где эта непрерывность требуется, а постоянно юзать std::basic_string<>::data() const напрягает.
Вот такие пироги. В заключение хочу напомнить, что непрерывность - та ну бог с ней, в других языках строки тоже зачастую непрерывны и в реализации, а не только внешне. Но строки всё-таки не массивы, а символы всё-таки не целые. И чтобы преобразовать одно в другое требуются касты, а то и вызовы RTL.

Добавлено 12.01.14, 04:03

Цитата amk @ 11.01.14, 22:48

Там и wchar_t часто определялся как синоним какого-то из int'ов.

И это неправильно. Этот костыль - как и определение подобным образом bool - не в состоянии полностью удовлетворить требованиям Стандарта к ним. В частности будут проблемы при использовании их в качестве аргументов шаблонов или специализаций.

Добавлено 12.01.14, 04:08

Цитата liss @ 11.01.14, 22:59

вершину абстракции Qraizer приводил недавно в виде шаблона универсального решателя

Чего я делал??

Сообщение отредактировано: Qraizer - 12.01.14, 04:09

[D_KEY]

Что строкой вы назовете, то ей и будет В принципе, строка - это список(в смысле АТД, а не структуры данных) символов. А все остальное - вопрос реализации в языке/библиотеке.

[korvin]

Цитата Qraizer @ 12.01.14, 03:49

Массив в первую очередь контейнер, хранящий элементы одного типа - в частности char или там char16_t итп - последовательно без перекрытий и пропусков. Строка по определению хранит только символы и ни что другое. И при этом как контейнер это отнюдь не массив.

Тем более в utf8 например.

[liss]

Цитата Qraizer @ 12.01.14, 03:49

шаблона универсального решателя

гм. не нашел. вроде был пост, в котором что-то вроде

template <typename Result, typename Problem>
Result solve (Problem args...);

[Qraizer]

А, понял Ну да, прикололся.

[NeoApostol]

А как обстоит дело в С++14 со static if ?

[Kray74]

Цитата NeoApostol @ 13.01.14, 07:29

А как обстоит дело в С++14 со static if ?

Никак. Последнее, что я видел - это критика static if Страуструпом (PDF).

[NeoApostol]

Цитата Kray74 @ 13.01.14, 08:02

Цитата NeoApostol @ 13.01.14, 07:29

А как обстоит дело в С++14 со static if ?

Никак. Последнее, что я видел - это критика static if Страуструпом (PDF).

А не подскажите, есть ли какая стороняя реализация этой штуки? Может в бусте?
Я пока ничего не нашел

[liss]

Цитата NeoApostol @ 13.01.14, 12:10

есть ли какая стороняя реализация

#if
подойдет?

Добавлено 13.01.14, 15:51
пожалуй единственное, чего нельзя сделать без static if это по сложному условию объявить глобальную переменную.
остальное решаемо шаблонами

[Qraizer]

liss, а пример можно, когда нельзя его заменить?

[NeoApostol]

Цитата liss @ 13.01.14, 15:47

Цитата NeoApostol @ 13.01.14, 12:10

есть ли какая стороняя реализация

#if
подойдет?

мне для просто, что посоветуете ?
Типа

    static if(std::is_empty<T>::value || std::is_empty<U>::value){
        
    } else {
        
    }

[amk]

Цитата Qraizer @ 12.01.14, 03:49

И это неправильно. Этот костыль - как и определение подобным образом bool - не в состоянии полностью удовлетворить требованиям Стандарта к ним. В частности будут проблемы при использовании их в качестве аргументов шаблонов или специализаций.

Откуда в чистом C шаблоны? Или перегрузка функций? Я же писал о C, где char имело считать числовым типом, поскольку за его интерпретацию в любом случае отвечал самолично программист. В фортране хорошо было, можно было указать размер числа.

[liss]

Цитата Qraizer @ 13.01.14, 17:51

liss, а пример можно, когда нельзя его заменить?

не пользуясь препроцессором?

[Qraizer]

Не, когда static if нельзя заменить на шаблонны.

[Axis]

Цитата NeoApostol @ 13.01.14, 18:37

мне для просто, что посоветуете ?
Типа

    static if(std::is_empty<T>::value || std::is_empty<U>::value){
 
    } else {
 
    }

Вызов функции с перегрузкой.

void helper(....., std::integral_constant<bool, false>){ ... }
void helper(....., std::integral_constant<bool, true>){ ... }
 
helper(....., std::integral_constant<bool, std::is_empty<T>::value || std::is_empty<U>::value>());

Имхо static_if в данном случае был бы действительно приятнее. И ведь это самый простой вариант использования.

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

Сообщение отредактировано: Axis - 20.01.14, 05:20