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

[Qraizer]

Почему это? Не будет. \, предшествующий ", маскирует конец литерала и означает просто символ " как его элемент, тогда как если этому \ предшествует ещё один \, то это означает просто символ \ как элемент литерала, и если следом идёт ", то это его граница. Если мы видим \\\, то первые два означают просто \, а последний является модификатором следующего символа, и какой-то смысл они имеют только совместно. \\\" означает два обычных символа \ и ", не специальных, \\\t означает \ и TAB итп

[macomics]

Проверю.

$ cat test.cpp
#include <iostream>
 
int main() {
        std::cout << "Test \\\";
        return 0;
}
$ g++ -o test test.cpp
test.cpp:4:22: предупреждение: отсутствует завершающий символ "
    4 |         std::cout << "Test \\\";
      |                      ^
test.cpp:4:22: ошибка: отсутствует терминирующий символ "
    4 |         std::cout << "Test \\\";
      |                      ^~~~~~~~~~~
test.cpp: In function «int main()»:
test.cpp:5:9: ошибка: expected primary-expression before «return»
    5 |         return 0;
      |         ^~~~~~
$ cat test.cpp
#include <iostream>
 
int main() {
        std::cout << "Test \\\\";
        return 0;
}
$ g++ -o test test.cpp
$ ./test
Test \\$

[Majestio]

Цитата Славян @ 13.09.25, 12:58

Может это и нормально, но совершенно выбесило меня!..

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

Цитата macomics @ 14.09.25, 00:04

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

Проще не заморачиваться количеством или чётностью. А просто определиться с обработкой.

Символ \ может участвовать:

• Просто как символ, если он внутри комментария
• Может участвовать в литералах как экранирующий или экранируемый символ
• Может участвовать в escape-преобразованиях
• Может участвовать как склеиватель строк

Экранирование
Работает только внутри литералов. Символ \ может экранировать " или ' или \

Escape-преобразования
Работают только внутри литералов. Всем известные \n \r \t \a \0 \x42 ....

Компилятор сканирует код посимвольно. Встречая символы, которые могут иметь и обычное, и управляющее значение. Компилятор, в процессе сканирования, "назначает" встретившему символу "роль" (обычный или управляющий) в зависимости от ряда состояний.

[Majestio]

Цитата Qraizer @ 13.09.25, 20:13

Не всё, что внутри /**/ или //EOL, является комментом, а только то, что не в строковом литерале.

Крайне подозрительное утверждение. Внутри комментариев - не может быть литералов. И если мы что-то решили закомментировать (я имею ввиду по правилам), то любые литералы автоматом превращаются в комментарии.

[Qraizer]

Majestio, ну да. Это и означает, что

std::cout << "Тут я не должна заменяться, даже /* если я размещу её */ вот так"; // в отличие от "Тут я должна быть \
заменена", потому что это всё ещё коммент

нужно уметь правильно обработать

Сообщение отредактировано: Qraizer - 14.09.25, 16:02

[Majestio]

Qraizer, склейка строк не спасет от неправильности твоего этого утверждения.
Хотя нет, не от неправильности. Твое это утверждение отчасти верно. Просто оно записано так, что несколько ломает причинно-следственные связи А именно ... как бы это правильно сказать: литералы все же первичны, конструкции комментариев вторичны. Т.е., выражаясь академическим языком, и чтобы не туманить мозги С++ неофитам, ты должен был выразить мысль в более "календарном" смысле, в обратном порядке:

1. Сперва проход препроцессора (склейки строк, инклюды, дефайны &etc)
2. Определение литералов
3. Определение комментариев

Заметь! 2 потом 3, а не 3 потом 2. Если я не ошибаюсь, это что-то типа раздел 5.2 "Phases of translation" текущего Стандарта.

[Qraizer]

В чём именно ты видишь неправильность? Я не собирался описывать алгоритм, хошь сырцов?, они есть. Я описал спектр учитываемых аспектов. Естественно их не следует применять в описанном порядке. Давайте не будем душнить. Плз.

[Majestio]

Цитата Qraizer @ 14.09.25, 21:56

В чём именно ты видишь неправильность?

Ну я же написал выше. Не неправильность, а скорее запутанность. Проще написать, что внутри литералов не может быть комментов, равно как и внутри комментов не может быть литералов.
Тогда всё ясно и понятно. И да, давай не будем душнить =)

[Majestio]

Qraizer, тебе квест!

Цитата Qraizer @ 13.09.25, 20:13

Как-то пришлось писать утилю, которая заменяла все я на Я, потому как используемая тулза (инструментатор исходного кода под: сбор структурного покрытия; сбор информации WCET, анализ потоков данных и/или управления; оценка наихудшего использования стека) на ASCII символах == 0xFF бажила. (Дело не в русской букве, а именно коде символа. В европейских кодировках на этом символе тот же баг.) Так это было целое приключение, т.к. заменять всё было нельзя, только в комментах. А то, что в строках, нужно оставить нетронутым, иначе меняется поведение кода, благо на таких тулза не бажила.
В итоге это вылилось в весьма нетривиальный алгоритм.

Я уверен, что сей велосипед ты навелосипедил на все 100% правильно. Но ты тогда, imho, пошел самым упоротым путем. Ибо для таких задач уже давно существовали специальные решения. А именно связка либ - bison (1985) + flex (1987). Генераторы парсеров и лексические анализаторы в лице вышеупомянутых либ.

Слабо изучить матчасть и перевести свой код под эти "платформы"?

Скрытый текст

заодно и мы поучимся ... а?

[Qraizer]

Зачем такое старьё, если есть boost::spirit ?

[Majestio]

Bison + Flex однозначно лучше, когда требуется максимальная производительность парсинга для обработки больших входных данных, а грамматика подходит для LALR, так как они генерируют оптимизированный C-код, который работает быстрее, чем парсеры, созданные с помощью Boost::Spirit.

[Qraizer]

Ну я бы не был так категоричен на предмет производительности. Другое дело, компиляция...
Та и в целом, меня напрягает любой автоматически непонятно кем непонятно как генерируемый код, вставляемый в мой проект. Никсоидам может быть и нормуль, когда make генерит makefile, по которому make генерит три makefile, по которым make генерит N makefiles для сборки N/3 пререквизитов, по которым рекурсивно процесс повторяется для сборки пререквизитов, ещё один собирает собственно проект с пререквизитами и ещё один конфигурит и инсталит, и поэтому им нормуль, когда половина пререквизитов автогенерится своими makefile, точнее, их половиной, тогда как вторая половина их собственно собирает... а, не, половина от N/3... ойфсё. И да, в Cях метакодить иначе никак. Спасибо, я всё ж лучше метакодить по Стандарту буду