Внезапно тут подумалось, что вот адреса IP v4 кончились, и не слишком далёк тот час, когда синтаксис C++ тоже исчерпает пути расширения. Выхода два:
1) Превратиться в Perl++, наращивая цепочки скобочек и закорючек, которые ранее не имели прикладного смысла, но распарсить которые будут в состоянии лишь единицы из нас, не считая regexp-роботов
2) Добавить новый тип файлов расширения, по аналогу перехода ".c" -> ".cpp". Например, ".c1x" или ".cpp1x"
Здравствуйте, Mr.Delphist, Вы писали:
MD>Внезапно тут подумалось, что вот адреса IP v4 кончились, и не слишком далёк тот час, когда синтаксис C++ тоже исчерпает пути расширения. Выхода два: MD>1) Превратиться в Perl++, наращивая цепочки скобочек и закорючек, которые ранее не имели прикладного смысла, но распарсить которые будут в состоянии лишь единицы из нас, не считая regexp-роботов MD>2) Добавить новый тип файлов расширения, по аналогу перехода ".c" -> ".cpp". Например, ".c1x" или ".cpp1x"
MD>Что скажете?
Добавить новый тип файлов. Причем это нужно было сделать уже давно, а не мучить С++ кривым синтаксисом только ради того чтобы не сломать чего-нибудь старое.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Внезапно тут подумалось, что вот адреса IP v4 кончились, и не слишком далёк тот час, когда синтаксис C++ тоже исчерпает пути расширения. Выхода два: MD>1) Превратиться в Perl++, наращивая цепочки скобочек и закорючек, которые ранее не имели прикладного смысла, но распарсить которые будут в состоянии лишь единицы из нас, не считая regexp-роботов MD>2) Добавить новый тип файлов расширения, по аналогу перехода ".c" -> ".cpp". Например, ".c1x" или ".cpp1x"
MD>Что скажете?
что следующее значительное изменение языка будет примерно в 2022 году. (в 2017 — незначительные изменения).
это нескоро.
Здравствуйте, Abyx, Вы писали:
A>по сабжу — можно использовать #pragma new_syntax
А Вы точно уверены, что какой-нибудь хитро-выдуманный компилер уже не ввёл такую прагму лет эдак ...дцать назад, для нужд автоматизации атомных войск за полярным кругом? Насколько знаю, стандартизации прагм так и нет.
Здравствуйте, enji, Вы писали:
E>Здравствуйте, Mr.Delphist, Вы писали:
MD>>2) Добавить новый тип файлов расширения, по аналогу перехода ".c" -> ".cpp". Например, ".c1x" или ".cpp1x"
E>Тоже об этом думал. Но как быть например с инклюдами? Они то в старом синтаксисе остаются... Как-то по особому их обрабатывать?
Дык у нас же есть уже ".h" и ".hpp" — почему бы не добавить ещё что? тот же ".h1x", например.
Здравствуйте, Mr.Delphist, Вы писали:
MD>>>2) Добавить новый тип файлов расширения, по аналогу перехода ".c" -> ".cpp". Например, ".c1x" или ".cpp1x"
E>>Тоже об этом думал. Но как быть например с инклюдами? Они то в старом синтаксисе остаются... Как-то по особому их обрабатывать?
MD>Дык у нас же есть уже ".h" и ".hpp" — почему бы не добавить ещё что? тот же ".h1x", например.
Ну придется ведь включать старые .h в наши новые .c1xx...
Здравствуйте, enji, Вы писали:
E>Тоже об этом думал. Но как быть например с инклюдами? Они то в старом синтаксисе остаются... Как-то по особому их обрабатывать?
Основная проблема с такими инклудами, которые компилируются по-разному в зависимости от некоторых #define, которые определены выше. Причем препроцессор может изменять код на уровне лексем, то есть еще до синтаксического дерева.
Наверное можно компилировать старые h-файлы в какой-тоспециальный формат типа pch и подключать их как модули в нормальных модульных языках.
Здравствуйте, Mr.Delphist, Вы писали:
MD>2) Добавить новый тип файлов расширения, по аналогу перехода ".c" -> ".cpp". Например, ".c1x" или ".cpp1x"
Нахрена?
Здравствуйте, Трололоша, Вы писали:
Т>Здравствуйте, Mr.Delphist, Вы писали:
MD>>2) Добавить новый тип файлов расширения, по аналогу перехода ".c" -> ".cpp". Например, ".c1x" или ".cpp1x" Т>Нахрена?
Чтобы без особого риска добавлять новые ключевые слова в язык. Как например яэти всякие await в новой версии C#
Здравствуйте, Mr.Delphist, Вы писали:
MD>Чтобы без особого риска добавлять новые ключевые слова в язык. Как например яэти всякие await в новой версии C#
Я так полагаю, что вводить различение версий языка на основе расширений файлов как-то слишком смело.
С учётом наличия адской магии препроцессора, которую из песни не выкинешь, совершенно непонятно, что будет делать компилятор при скармливании ему .c1x, заинклудившего .cpp. Трактовать код в .cpp как старый, или как новый?
Так что, если уж хочется адского, то надо вводить прагмы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Mr.Delphist, Вы писали:
MD>Чтобы без особого риска добавлять новые ключевые слова в язык. Как например яэти всякие await в новой версии C#
Зачем для этого менять расширение?
Здравствуйте, Трололоша, Вы писали:
Т>Здравствуйте, Mr.Delphist, Вы писали:
MD>>Чтобы без особого риска добавлять новые ключевые слова в язык. Как например яэти всякие await в новой версии C# Т>Зачем для этого менять расширение?
Для гарантий обратной совместимости. Как всякие эти двойные подчеркивания в именах идентификаторов — чтобы хоть как-то быть уверенным, что твой супер-макрос в мега-шаблоне не встретится с коллизией имён.
MD>Чтобы без особого риска добавлять новые ключевые слова в язык. Как например яэти всякие await в новой версии C#
Ценность автоматического преобразования "линейного" псевдокода в событийный реальный резко снижается в отсутствии GC. Поэтому, в нейтивном C++ этого не будет. А в расширениях MS чего уже только нет...
Здравствуйте, vdimas, Вы писали:
V>Здравствуйте, Mr.Delphist, Вы писали:
MD>>Чтобы без особого риска добавлять новые ключевые слова в язык. Как например яэти всякие await в новой версии C#
V>Ценность автоматического преобразования "линейного" псевдокода в событийный реальный резко снижается в отсутствии GC. Поэтому, в нейтивном C++ этого не будет. А в расширениях MS чего уже только нет...
Да тут await просто как пример: вот не было его раньше, а затем бац и в новом релизе языка добавили.
Аналогично сейчас C++ комитет начинает ритуальные танцы вокруг способов описать новые сущности и идиомы. Ну ладно, с rvalue повезло. Но это не значит, что подобные лазейки валяются в избытке — наоборот, я с давних пор утвердился во мнении, что одним из главных минусов C++ можно считать малое количество запрещенных инструкций, т.е. как ни напиши, это всё равно будет что-то обозначать с вероятностью 99%. Т.е. потенциальных "карманов" для отстраивания новых синтаксических веток в грамматике языка авторы не оставили себе практически с самого начала...
Здравствуйте, Mr.Delphist, Вы писали:
V>>Ценность автоматического преобразования "линейного" псевдокода в событийный реальный резко снижается в отсутствии GC. Поэтому, в нейтивном C++ этого не будет. А в расширениях MS чего уже только нет...
MD>Да тут await просто как пример: вот не было его раньше, а затем бац и в новом релизе языка добавили.
Я же говорю, GC очень развязывает руки в плане трансформации кода. А этот await, так же как yield return — это операторы трансформации кода.
MD>Аналогично сейчас C++ комитет начинает ритуальные танцы вокруг способов описать новые сущности и идиомы. Ну ладно, с rvalue повезло. Но это не значит, что подобные лазейки валяются в избытке — наоборот, я с давних пор утвердился во мнении, что одним из главных минусов C++ можно считать малое количество запрещенных инструкций, т.е. как ни напиши, это всё равно будет что-то обозначать с вероятностью 99%. Т.е. потенциальных "карманов" для отстраивания новых синтаксических веток в грамматике языка авторы не оставили себе практически с самого начала...
Да пофиг.
См. static_assert. Это вполне мог бы быть и пользовательский макрос и зашитая в компилятор метка.
MD>>Что скажете? NC>Добавить новый тип файлов. Причем это нужно было сделать уже давно, а не мучить С++ кривым синтаксисом только ради того чтобы не сломать чего-нибудь старое.
А линковаться как?
Здравствуйте, Mr.Delphist, Вы писали:
MD>Здравствуйте, Трололоша, Вы писали:
Т>>Здравствуйте, Mr.Delphist, Вы писали:
MD>>>2) Добавить новый тип файлов расширения, по аналогу перехода ".c" -> ".cpp". Например, ".c1x" или ".cpp1x" Т>>Нахрена?
MD>Чтобы без особого риска добавлять новые ключевые слова в язык. Как например яэти всякие await в новой версии C#
Я бы наоборот ввёл бы ограничения на используемые фичи
strict(no bost)
или
strict(c only)
strict(NO AWAIT, only C99)
Добавление всех этих чудных фич в C++ его убивает.
Во первых они не решают конкретных задач. Очень много конструкций решают не практические задачи а проблемы которые были созданы искусственно.
Во вторых конструкции всё усложняются. Всё труднее обучать новых людей. А как только вымрут динозавры и язык умрёт. Останется C и Fortran
Скорость компиляции очень низкая. Даже precompiled headers не спасают.
Очень сложно и дорого сделать компилятор C++ для новой платформы.
Очень сложно добавлять новые фичи, не мешая старым.
Очень низкая выразительность языка. Что бы что-то быстро сделать нужны костыли типа boost.
Дурацкая типизация данных. Зачем-то выравнивание указателей втянули в язык. Совместили блох с кометами.
Очень сложный синтаксис для сред разработки.
Огромный зоопарк стандартных библиотек с разными видами не совместимостей.
Постоянное нытьё что макросы это гавно. Что мешает сделать нормальные макросы как в техе? Что бы они не мешали а помогали повысить выразительность? И пишите на них dsl-и
...
Можно долго перечислять.
Посмотрите на форум C++ во что он превратился ни одной интересной мысли. Один бред и обсуждение новых стандартов.
Ни один больной маньяк не будет реализовывать свою идею на C++. Дорого и бесперспективно.
Может потом если надо будет что-то оптимизировать то да и то предпочтет использовать оптимизированные библиотеки на C или их порты.
Да и на C++ программу в ПЛИС не запихнуть.
Вобщем считю C++(n+1) без перспективными языками. Зачем тратить так много усилий и времени
что бы реализовать то что можно сделать на другом языке в 10раз быстрее короче, выразительнее и эффективнее.
