OSDev

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


Ну конечно, по каждому "Hello, World!" я сейчас же буду настраивать репозиторий и делать коммиты! Вместо того, чтобы просто закомментировать кусок кода. Ну вы даёте.


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


Так я как-то не вижу проблемы.

Вообще всё это – паника на ровном месте. Часто ли вы в своей практике сталкивались с закрытием комментария внутри строки? Много ли нужно усилий чтобы маскировать второй символ? Нарушится ли хоть что-либо при маскировании? На мой взгляд, ответ очевиден.
Да, в стандарте C/C++ такой escape-символ не предусмотрен, но ведь мы говорим про разработку нового языка. Даже несмотря на отсутствие решения проблемы в C/C++, я за всю свою практику не сталкивался с ситуацией, когда надо было закомментировать такую строку, так что вся эта ситуация надумана.

_________________
Yet Other Developer of Architecture.
The mistery of Yoda’s speech uncovered is:
Just an old Forth programmer Yoda was.
<<< OS Boot Tools. >>>

В Delphi и SQL я регулярно сталкиваюсь с отсутствием вложенных блочных комментариев, когда возникает необходимость закомментировать протяженный участок кода, уже содержащий такие комментарии. В процессе поиска решения такое случается сплошь и рядом. Для отслеживания вложенности комментарии нужно разбирать, что противоречит самой природе комментариев. Об этом уже говорилось в теме. Введение разбираемого комментария как отдельной синтаксической сущности будет решением, разбираемые комментарии смогут быть вложенными.

_________________
Путь успеха Циолковского — правильно умереть

Так "разбор" комментария будет сводиться к подсчету количества /* и поиску соответствующего количества */. И не нужно заморачиваться со всякими char a[] = "*/". Вот о чем речь-то.

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



Это самый правильный вариант, не обязательно даже одно-строчный комментарий, можно
и как немного выше говорилось и в строковых константах экранировку применить.
Главное здесь то что редактор знает что выделенный код станет комментарием и способен
легко обработать такие исключения, а также сделать обратное, но только потому что
мы подсветили ему так сказать фронт работ. конечно можно учить бедный парсер разбираться в таком УГ либо повторяя все синтагматические правила кода для строковых констант, и одно-строчных комментариев и может еще чего-нибудь.
Но это же часть компилятора, да еще с такими требованиями, если баг пролезет в редактор и он неправильно что то закоментирует вам об этом скажет компилятор, а кто скажет вам что баг есть в компиляторе? сами будете искать сначала перерыв код программы которая "почему то" валится в кору, а потом можно еще и в железе ошибки поискать и в ос.

Вообще с отдельной сущностью идея очень хорошая для такого языка как обсуждаемый. выделив несколько символов для такого дела можно будет превратить исходный код в мультимедийный формат и иметь прямо в коде
мат. формулами в естественном виде
инициализацию значений матрицы без обвязки наподобие {{...},{...}, ...} (естественно в коде это все равно будет {{... но наличие доп. разметки укажет редактору что этот кусок кода нужно отобразить через особый элемент )
наверное найдется что то еще, и всех таких штук будет достаточно минимум 1-2 гарантированно невозможных в обычном коде символов.

Например в ansi есть уже неиспользуемые управляющие символы такие как beep к примеру.
Их применение очень сильно облегчило бы парсинг исходного кода.

Конечно, это решается, и решается очень просто. Но возникает вопрос: а должны ли мы так делать? Разве конструкция char x[] = "*/"; в чём-то неправильна? Или в угоду возможности закомментривать код мы должны этот код править? Да нет, мы должны иметь возможность закомментировать любой код. Вот поэтому есть желание сделать комментарии особого вида, которые бы 1) могли быть вложенными 2) могли бы содержать в себе код. Конечно. Но Сишные комментарии не могут быть вложенными по определению. Я же веду речь о невозможности использования длинного скобочного комментария в качестве вложенного. Вот поговорили, есть новые мысли и новые сомнения. Всё-таки обсуждение с коллегами – это важно, помогает найти то, на что не обратил внимание. Например, возник такой вопрос: а что, если «нерабочий код» содержит синтаксическую ошибку? Если включены куки и js, то всё должно работать. Если такое повториться – напишите, когда это было в вплоть до минут – я посмотрю журнал. Кстати, почему-то на этом форуме не получается отправить личное сообщение – это чтобы форум не был замусорен. Ведь не все вещи достойны всеобщего внимания.Я бы это код переписал бы так: Так значительно короче и нагляднее. Второй, третий и четвёртый if – это замаскированный elseif. Но это если вести речь не о Си, а о новом языке, в котором мы сами устанавливаем правила.

Мне кажется, ли вложенные комментарии и правда самый главный элемент в параллельном программировании

может обсудим:
точность операций с плавающей точкой: задавать в библиотеке/программе их предоставить выбор пользователю
Поддержка архитектуры cuda, векторных процессоров и других аппаратных реализаций
Плюсы минусы существующих языков параллельного программирования

Точность не задают, её принимают к сведению. Задать можно только желаемый размер типа данных. Например, в GMP можно указать то, сколько цифр после запятой держать, а сколько из них будут правильными - это всегда должна быть задача пользователя, так как зависит не сколько от машины, сколько от самой задачи.

У меня однажды был проект, где я использовал интервальную арифметику. Любое дробное число (с бесконечной точность) хранилось в виде пары: (нижняя_граница,верхняя граница). То есть число - это как бы отрезок между границами. Каждая операция увеличивала эти границы. В конце концов границы становились достаточно большими, да и время работы таких операций было тоже большим (практически раза в 4 дольше). Но зато всё абсолютно точно: погрешность на практике всегда полностью накрывала погрешность в теории, то есть обе границы были всегда правильными. Настоящее число, которое должно получиться в ответе, всегда попадало в отрезок.


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


Таких как бы и нет вовсе. Есть надстройки над языками и библиотеки, позволяющие параллелить, но языков именно для параллельного программирования я лично не знаю. А это означает, что нормальных нет. Если бы были, я бы знал : ) (нормальный - это на котором можно решить нормальную в моём понимании задачу).

Если мы хотим обсуждать достоинства и недостатки OpenMP и MPI, то здесь лучше открывать отдельную тему. Если кратко, то оба этих инструмента - бодяга. Но ничего лучше я не знаю. Эту бодягу хотя бы можно заставить работать.

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

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

_________________
Путь успеха Циолковского — правильно умереть

Смотря что понимать под параллельным программированием. Если многопоточность в рамках одного приложения, то это изначально было (и, естественно, есть) в Аде, а может, и где-нибудь ещё. Если же речь об использовании параллелизма потоков данных на уровне системы команд (SIMD или GPU), то таких языков, вероятно, действительно нет -- разве что расширения существующих вроде невидийной CUDA для Це++. Компиляторы же распараллелить обычный код по потокам данных для SIMD способны далеко не всегда.