Здравствуйте, FrozenHeart, Вы писали:

FH>Что значит "готов отказаться"? Я привёл цитаты из стандарта, которые указывают на то, что использование non-ASCII символов в строковых литералах -- это уже implementation-defined поведение.

Есть спецификация языка, то есть документ описывающий его стандарт, и его реализации в виде наборов утилит в которые так же входит компилятор. Как известно разные производители компиляторов отступают в некоторых деталях от стандарта. Более того существуют ещё древние компиляторы, но это явно не про C++14. Опять же не забываем о настройках компилятора, можно ведь так настроить, что не скомпилируется даже то, что по стандарту, то есть поставить запрет на некие возможности. Поэтому у производителей компиляторов есть свои документы, в которых описано как они это видят. Иными словами всё равно нельзя игнорировать особенности и настройки компиляторов, даже если действуете по стандарту по которому в теории должны создаваться все компиляторы.

FH>Т.е. единственный кросс-платформенный способ использовать non-ASCII символы в строковых литералах — это

Для кроссплатформы понадобится прописать поведение в зависимости от платформы, например:

CMake

CMake (от англ. cross platform make) — это кроссплатформенная система автоматизации сборки программного обеспечения из исходного кода. CMake не занимается непосредственно сборкой, a лишь генерирует файлы управления сборкой из файлов CMakeLists.txt:

Makefile в системах Unix для сборки с помощью make;
файлы projects/solutions (.vcproj/.sln) в Windows для сборки с помощью Visual C++;
проекты XCode в Mac OS X

Qmake

qmake- это утилита из состава Qt, которая помогает облегчить процесс сборки приложения на разных платформах. qmake автоматически генерирует make-файлы, основываясь на информации в файлах проекта(*.pro).

(информация из руководства)

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

qmake создает файл сборки, не требуя от разработчика вносить изменения в файл проекта.

Опять же если так волнует переносимость, тогда лучше использовать C++03, а не C++14. Сейчас уже разговор пошёл не о том, что нельзя скомпилировать программу в принципе, а о том, что у конкретного человека это может не получиться. Не поставили указание компилятору использовать новый стандарт, отключили поддержку UTF-8, и так далее.

Здравствуйте, FrozenHeart, Вы писали:

FH>Файловая система в том или ином виде должна ведь присутствовать всё равно. Вы же как-то подавали исходные файлы на вход компилятору?

С ленточки грузил в ОЗУ...

FH>Впрочем, всё это оффтоп. Буду признателен, если ответите на обозначенный в ОП-посте вопрос.
Так что за вопрос? С++ сформулирован в неких абстрактных терминах. Исходники — это именованные последовательости текстовых символов просто, а способы задания отображения имён на последовательности и представления последовательностей вроде как не ооваривается. Так что тут всё от платформы и транслятора зависит.

Про "по существу" тебе ответили же.
1) Если устроит набор из двух-трёх популярных компиляторов и семи-восьми платформ, то можно utf-8 исходники юзать, например.
2) Если не устраивает, то лучше такие тексты вообще вынести в отдельные файлы ресурсов и не зависить от доступных компилятору способов представления последовательностей букв в исходнике.

В общем, IMHO, ты путаешь последовтельность букв в текстах доступных коду и пследовательность букв, доступную компилятору в виде исходного текста.

Если их не путать, то проблем не будет, IMHO...

Здравствуйте, FrozenHeart, Вы писали:

FH>Всё ли я правильно сказал?
Да, на мой взгляд почти всё верно, но есть одно упущение в самом начале:

FH>Предположим, я решил написать
FH>

FH>const char* str = "✓";
FH>

FH>Что произойдёт при компиляции такой программы?

Прежде, чем ответить на этот вопрос нужно задаться другим вопросом: что произойдёт при сохранении этой строчки кода на физическом носителе? Думаю вы согласитесь, что представление символа '✓' в виде последовательности байтов в файле на разных платформах может быть разным, т.е. implementation-defined. Все остальные вопросы связанные с представлением строк логически вытекают из этого положения. Если бы этот формат файлов был фиксированным, то для редактирования файлов пришлось бы создавать специальные редакторы взамен общетекстовых.

Здравствуйте, B0FEE664, Вы писали:

BFE>Здравствуйте, FrozenHeart, Вы писали:

FH>>Всё ли я правильно сказал?
BFE>Да, на мой взгляд почти всё верно, но есть одно упущение в самом начале:

FH>>Предположим, я решил написать
FH>>

FH>>const char* str = "✓";
FH>>

FH>>Что произойдёт при компиляции такой программы?

BFE>Прежде, чем ответить на этот вопрос нужно задаться другим вопросом: что произойдёт при сохранении этой строчки кода на физическом носителе? Думаю вы согласитесь, что представление символа '✓' в виде последовательности байтов в файле на разных платформах может быть разным, т.е. implementation-defined. Все остальные вопросы связанные с представлением строк логически вытекают из этого положения. Если бы этот формат файлов был фиксированным, то для редактирования файлов пришлось бы создавать специальные редакторы взамен общетекстовых.

параллельно вопрос: а как гарантировать, что если в текстовом редакторе среды разработки (того же vs) я вижу символ "✓", то и всюду в скомпилированной программе он будет выводиться в нужном представлении? можно ли для этого использовать подход:

const std::wstring = L"✓";

?

__>параллельно вопрос: а как гарантировать, что если в текстовом редакторе среды разработки (того же vs) я вижу символ "✓", то и всюду в скомпилированной программе он будет выводиться в нужном представлении? можно ли для этого использовать подход:

__>

__>const std::wstring = L"✓";
__>

__>?

Гарантированно — никак, потому что

The set of physical source file characters accepted is implementation-defined

Но раз речь идёт только об одном окружении (редактор и компилятор, встроенные в Visual Studio), то... Я всё равно не могу посоветовать использовать wide-string.

Их проблема в том, что стандарт не гарантирует на их тему практически ничего! В какую кодировку будут преобразованы символы такой строки неизвестно, какого размера будет каждый из её элементов зависит от реализации (он вообще может быть равен 1 байту, как и char).

Здравствуйте, _hum_, Вы писали:

__>параллельно вопрос: а как гарантировать, что если в текстовом редакторе среды разработки (того же vs) я вижу символ "✓", то и всюду в скомпилированной программе он будет выводиться в нужном представлении?
Таких гарантий нет.

__>
можно ли для этого использовать подход:

__>

__>const std::wstring = L"✓";
__>

__>?

нет.