Каким должен быть язык программирования? Анализ и критика Описание языка Компилятор
Отечественные разработки Cтатьи на компьютерные темы Компьютерный юмор Прочее

Комментарии

В процессе эволюции языков программирования сложилось так, что оказались жизнеспособными два вида комментариев: длинные (с условно скобочной структурой) и короткие, занимающие конец строки. В Си они представлены /*...*/ и //... соответственно. В последнее время появились комментарии третьего вида: комментарии генерации документации. Идея замечательна: прокомментировал функцию, и этим одновременно создал help для неё.

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

            Экспериментируя с компиляцией кодов C++, мне захотелось сделать так, чтобы длинные комментарии могли бы быть вложенными. Ведь они по сути — квази-скобки: /* и */. Одна квази-скобка открывает комментарий, а вторая закрывает. Это очень удобно. Допустим, имеется фрагмент программы:

 текст программы
/* комментарий */
 текст программы
             Если мне надо для каких-то целей этот фрагмент закомментировать целиком, сделать его нерабочим, то содержащийся внутри комментарий этому совершенно не мешает: число открывающих скобок равно числу закрывающих. И у нас всё хорошо.

             Но от этого пришлось отказаться. В C++ комментарии не могут быть вложенными, для совместимости со стандартом языка следует отказаться от такой возможности. Так почему в C++ вложенные комментарии невозможны? Это казалось идиотизмом, которому нет разумных объяснений. Ведь это так элементарно! Объяснение нашлось случайно. Допустим, у нас есть такой кусок программы:
   char  x[] = "*/";                      // строка n+1
   /* комментарий */                      // строка n+2
   // ещё какой-то код                    // строка n+3
А теперь весь этот фрагмент поместим внутрь другого комментария:
/* начало комментария верхнего уровня     // строка n
   char  x[] = "*/";                      // строка n+1
   /* комментарий */                      // строка n+2
   // ещё какой-то код                    // строка n+3
конец комментария верхнего уровня */      // строка n+4
            При компиляции этого текста будет обнаружена ошибка. Комментарий верхнего уровня, начинающийся в строке n, закончится не в строке n+4 и даже не в строке n+2, а в строке n+1. Может возникнуть возражение:

Пусть компилятор сделает синтаксический анализ и увидит, что «*/» в строке n+1 заключен в кавычки, т.е. «*/» — это строковый литерал. Эта пара символов не может быть концом комментария, пусть компилятор ищет этот конец дальше

.             Это возражение не может быть принято! Компилятор не должен проводить анализ внутри комментария. Единственное, что можно ему позволено — это искать символы «*/».

            Но что же тогда делать? Иметь вложенные скобочные комментарии всё равно хочется. Мы, например, скопировали фрагмент кода из другой программы и хотим иметь его в качестве образца. Или ещё по каким-то причинам нужно фрагмент программы сделать неработающим, отключить его. Варианты решения проблемы:
  • Один из вариантов выхода видится такой. К тем видам комментариев, которые уже имеются, нужно добавить ещё один. Специально для того, чтобы фрагменты программ делать неработающими. Внутри таких комментариев делается синтаксический анализ, но выходной код для таких участков программы не генерируется. Этот другой вид комментариев и начинаться должен по-другому, т.е. не так, как обычный длинный (скобочный) комментарий. Но это сложный вариант.

  • Второй вариант — комментарии, имеющие уникальную метку вначале и конце. Этот способ попроще.

  • Ну и самое лёгкое — вообще ничего не делать. Просто программист должен знать о таком нюансе и самостоятельно отслеживать такую редкую ситуацию — последовательность символов «конец комментария» внутри строки.

Последняя правка: 2018-11-09    12:43

ОценитеОценки посетителей
   ██████████████████████████████████████████ 4 (100%)
   ▌ 0
   ▌ 0
   ▌ 0

Отзывы

     2014/06/17 04:26, utkin

Есть еще один вид комментариев это #. Он является стандартом в юникс/линукс.

     2014/06/17 16:43, Автор сайта

Просто жаль целый символ жертвовать на какой-то комментарий. А вдруг пригодится? Уж лучше тогда «##», это не так жалко :)

     2016/08/06 19:05, rst256

А разве одиночные комментарии не удобнее? Они же надежно отключают любой код, и гораздо быстрее обрабатываются.

     2016/08/12 10:21, Трурль

Но эта же ошибка возникнет и без вложенных комментариев.

Написать отзыв

Написать автору можно на электронную почту mail(аt)compiler.su

Авторизация

Регистрация

Выслать пароль

Карта сайта


Каким должен быть язык программирования?

Анализ и критика

Устарел ли текст как форма представления программы

Русский язык и программирование

Многоязыковое программирование

Синтаксис языков программирования

Синтаксический сахар

Некоторые «вкусности» Алгол-68

«Двухмерный» синтаксис Python

Почему языки с синтаксисом Си популярнее языков с синтаксисом Паскаля?

Должна ли программа быть удобочитаемой?

Стиль языка программирования

Тексто-графическое представление программы

●  Разделители

●  Строки программы

●  Слева направо или справа налево?

Комментарии

●  Длинные комментарии

●  Короткие комментарии

●  Комментарии автоматической генерации документации

●  Нерабочий код

●  Помеченные комментарии

Нужны ли беззнаковые целые?

Шестнадцатиричные и двоичные константы

Условные операторы

Переключатель

Циклы

●  Продолжение цикла и выход из него

Некошерный «goto»

Изменение приоритетов операций

Операции присвоения и проверки на равенство. Возможно ли однаковое обозначение?

Так ли нужны операции «&&», «||» и «^^»?

Постфиксные инкремент и декремент

Почему в PHP для конкатенации строк используется «.»?

Указатели и ссылки в C++

Использование памяти

Почему динамическое распределение памяти — это плохо

Как обеспечить возврат функциями объектов переменной длины?

●  Типы переменного размера (dynamically sized types, DST) в языке Rust

●  Массивы переменной длины в C/C++

●  Размещение объектов в стеке, традиционный подход

●  Размещение объектов переменной длины с использованием множества стеков

●  Размещение объектов переменной длины с использованием двух стеков

●  Реализация двухстековой модели размещения данных

●  Двухстековая модель: тесты на скорость

●  Изменение длины объекта в стеке во время исполнения

●  Размещение объектов переменной длины с использованием одного стека

Можно ли забыть о «куче», если объекты переменной длины хранить в стеке

Безопасность и размещение объектов переменной длины в стеке

Массивы, структуры, типы, классы переменной длины

О хранении данных в стеке, вместо заключения

Описание языка

Компилятор

Отечественные разработки

Cтатьи на компьютерные темы

Компьютерный юмор

Прочее

Последние комментарии

2018/12/08 23:03 ••• Попов Михаил
✎ Программирование без программистов — это медицина без врачей

2018/12/07 08:57 ••• Автор сайта
✎ Почему обречён язык Форт

2018/12/07 08:36 ••• Автор сайта
✎ Нужны ли беззнаковые целые?

2018/12/03 13:51 ••• kt
✎ Экстракоды при синтезе программ

2018/11/30 17:56 ••• Freeman
✎ Изменение приоритетов операций

2018/11/30 17:20 ••• Автор сайта
✎ Почему языки с синтаксисом Си популярнее языков с синтаксисом Паскаля?

2018/11/26 14:23 ••• Автор сайта
✎ Так ли нужны операции «&&», «||» и «^^»?

2018/11/18 15:21 ••• Freeman
✎ Устарел ли текст как форма представления программы

2018/11/17 03:28 ••• Comdiv
✎ Изменение длины объекта в стеке во время исполнения

2018/11/16 12:53 ••• Автор сайта
✎ Помеченные комментарии

2018/11/11 14:01 ••• Александр Коновалов aka Маздайщик
✎ Нерабочий код

2018/11/11 13:39 ••• Александр Коновалов aka Маздайщик
✎ О русском языке в программировании