The OpenNET Project / Index page

[ новости /+++ | форум | теги | ]



Вариант для распечатки  
Пред. тема | След. тема 
Форум Разговоры, обсуждение новостей
Режим отображения отдельной подветви беседы [ Отслеживать ]

Оглавление

В компиляторе G++ обеспечена поддержка C++17, opennews (?), 13-Янв-17, (0) [смотреть все]

Сообщения [Сортировка по времени | RSS]


75. "В компиляторе G++ обеспечена поддержка C++17"  +2 +/
Сообщение от Аноним (-), 13-Янв-17, 16:42 
> А пространства имён - чем не модули для плюсов?

Модули - это несколько другое. А именно, возможность не вести "двойную бухгалтерию", т.е. не дублировать заголовки функций в .h и .cpp файлах. Почитайте здесь:

https://blogs.msdn.microsoft.com/vcblog/2015/12/03/c-modules.../

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

Ответить | Правка | К родителю #28 | Наверх | Cообщить модератору

81. "В компиляторе G++ обеспечена поддержка C++17"  +/
Сообщение от freehckemail (ok), 13-Янв-17, 17:48 
>> А пространства имён - чем не модули для плюсов?
> Модули - это несколько другое. А именно, возможность не вести "двойную бухгалтерию",
> т.е. не дублировать заголовки функций в .h и .cpp файлах.

Хм. Я понял, смысл в том, что хочется уйти от необходимости отдельно писать код в .cpp/.cxx, и отдельно описывать интерфейсы в .h, передавая эту работу компилятору, когда это возможно.

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

Это смотря как реализовать. Если это будет штучка для "автоматической генерации интерфейсов", тогда скорее всего да, забьют на него.

А вот если смогут реализовать наследование, расширение модулей и генерацию на лету (functors) на основе других модулей, то это будет мега-фича. Впрочем, с фанкторами, скорее всего не получится. Они будут, пожалуй, сродни модулям первого порядка, а в c++ реализовать подобное будет сложновато.

В любом случае, спасибо за ссылку, было интересно.

Ответить | Правка | Наверх | Cообщить модератору

93. "В компиляторе G++ обеспечена поддержка C++17"  +1 +/
Сообщение от nobody (??), 13-Янв-17, 19:58 
> Хм. Я понял, смысл в том, что хочется уйти от необходимости отдельно писать код в .cpp/.cxx

Неправильно понял. Шаблоны в .cpp не поместишь, они до сих пор живут в хэдерах. 90% того же Boost - в хэдерах. И практически всё это компилятору нужно переразбирать при компиляции чуть ли не КАЖДОГО .cpp из проекта

Ответить | Правка | Наверх | Cообщить модератору

95. "В компиляторе G++ обеспечена поддержка C++17"  +2 +/
Сообщение от Ivan (??), 13-Янв-17, 20:01 
> Хм. Я понял, смысл в том, что хочется уйти от необходимости отдельно писать код в
> .cpp/.cxx, и отдельно описывать интерфейсы в .h, передавая эту работу компилятору,
> когда это возможно.

Я бы сказал, что это не главная фича. Основная мотивация это позволить компилятору закешировать результат парсинга/синтаксического анализа хедеров и переиспользовать его в каждой единице трансляции. Сейчас компилятору приходится парсить/анализировать хедер столько раз, сколько он инклудится в разные единицы трансляции.

Это больше напоминает precompiled хедера, только более fine-grained и встроенные в язык.

Ещё один минорным side-effect'ом является то, что это получить ODR-нарушение станет гораздо сложнее. Большинство пользователей этого не заметят, просто их программы будут работать как они ожидают.

Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

117. "В компиляторе G++ обеспечена поддержка C++17"  +/
Сообщение от freehckemail (ok), 14-Янв-17, 12:01 
> Я бы сказал, что это не главная фича. Основная мотивация это позволить
> компилятору закешировать результат парсинга/синтаксического анализа хедеров и переиспользовать
> его в каждой единице трансляции. Сейчас компилятору приходится парсить/анализировать
> хедер столько раз, сколько он инклудится в разные единицы трансляции.

Это-то понятно. Когда интерфейсы компилируются отдельно - это станартная практика. Хорошо бы ещё позволить интерфейсы модуля прописывать отдельно, в целях инкапсуляции вспомогательных функций. Думаю, в сях многие этого хотели бы.


Ответить | Правка | Наверх | Cообщить модератору

147. "В компиляторе G++ обеспечена поддержка C++17"  –1 +/
Сообщение от adolfus (ok), 18-Янв-17, 15:14 
> А вот если смогут реализовать наследование, расширение модулей и генерацию на лету
> (functors) на основе других модулей, то это будет мега-фича. Впрочем, с
> фанкторами, скорее всего не получится. Они будут, пожалуй, сродни модулям первого
> порядка, а в c++ реализовать подобное будет сложновато.

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

Ответить | Правка | К родителю #81 | Наверх | Cообщить модератору

152. "В компиляторе G++ обеспечена поддержка C++17"  +/
Сообщение от freehckemail (ok), 05-Фев-17, 02:23 
> На лету и остальная динамика хороши с точки зрения академического интереса.

Этот самый академический интерес работает не сильно медленнее обычного Си. Раза эдак в четыре всего.

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

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

> Не мешало бы поиметь несколько точек входа в процедуру

А может тогда лучше пусть это будут несколько разных процедур?

> и арифметическое ветвление

Ой, ну это же синтаксический сахар. Его не так уж сложно добавить.

> прямой выход из вложенных вызовов с очисткой стека,

exceptions

Ответить | Правка | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема




Партнёры:
PostgresPro
Inferno Solutions
Hosting by Hoster.ru
Хостинг:

Закладки на сайте
Проследить за страницей
Created 1996-2024 by Maxim Chirkov
Добавить, Поддержать, Вебмастеру