@ct0r

https://isocpp.org/files/papers/D4492.pdf

Как думаете, в правильном ли направлении идет развитие? Что вы хотите видеть в С++17? Какую фичу ждете больше всего?

4

@ct0r

Ну тогда да.

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

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

0

@hoggy

так и есть.

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

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

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

все вместе - и многие конторы не хотят связываться.

0

@cybercitizen

0

MrGluck

Я знаком с ним лично, цифру надо как минимум умножить в два раза.

Добавлено через 11 минут
Очень хотелось модулей (которых увы, не будет в С++17), работу с ФС, range v3, многопоточные алгоритмы STL, std::any, std::variant, определение типа шаблона для конструкторов.

0

@Avazart

0

MrGluck

В избавлении гемороя при компиляции, переход на новую систему сборки. То есть мы избавимся от .h файлов, будем писать только .cpp. Сейчас уже есть две реализации - от clang и Microsoft, обе имеют свои плюсы и минусы и они, конечно, несовместимы между собой.

0

@Avazart

И что в итоге получится?
Модули Delphi с секциями interface и implementation ?

0

Убежденный

В скорости сборки.

Например, у меня проект из многих тысяч файлов, почти каждый из
них включает Windows.h, string, vector и еще многие заголовки.
И при компиляции каждого .cpp или .c файла каждый раз выполняется
обработка этих заголовков, что явно избыточно и тормозит весь процесс.

С переходом на модули все кардинально меняется, т.к. каждый модуль
обрабатывается единожды.

Кстати, из-за раздельной компиляции сборка в C/C++ на порядки
медленнее, чем в Delphi, например.

0

@Avazart

Разве тогда не придется решать проблему с шаблонами?

0

Убежденный

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

0

MrGluck

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

0

@Avazart

Ну так в другой единице как я полагаю породит туже проблему с многократной обработкой одного и того же кода.

Т.е если я использую в многих файлах std::vector<std::string> "инстанцироваться" будет же столько же раз сколько и файлов?
Или я ошибаюсь?

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

0

@rikimaru2013

Обработка нужна всегда, а скомпилируются cpp файлы ваших Window.h и т.д. только один раз. Всё верно - что именно не нравится?

0

Убежденный

source1.cpp
source2.cpp
...

source10000.cpp
Не нравится, что 10000 исходных файлов = 10000 раз компиляция Windows.h.
Подключим модули - компиляция будет однократная.

0

@Avazart

Вопрос в том будет ли компиляция проектов c STL и boost действительно быстрее (там как бы одни шаблоны в принципе)

0

@rikimaru2013

Avazart, да я и про полную компиляцию тоже) *.cpp в списке скомпилируемых файлов будет 1 раз, а подключение *.h это не более чем вставка всего текста, что несёт объявление, declaration.

Компилируем 1 раз - линкуемся к нему много раз. Что не так то? Убежденный, А чем компиляция отличается на 999 строчке #include <Windows.h> от первой? Это всего лишь incldue текста, который помогает компилятору и линковщику.

0

Убежденный

Заголовки бывают очень большие (Windows) и тяжелые (Boost), и чем больше
исходных файлов включают такие заголовки, тем больше замедляется время сборки.

Это как постоянное копирование больших объектов по значению, в то время
как эффективнее было бы копировать их по ссылке или указателю...

Линковка здесь не поможет. Как ты залинкуешь шаблоны, например?
У MS давно есть решение в виде прекомпилированных заголовков, но они,
во-первых, не стандартизированы, а во-вторых, там есть свои проблемы
(например, появление лишних зависимостей).

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

0

@rikimaru2013

Убежденный, ну вот мы уже определились, что *.h файлы не компилируются, а лишь влияют на синтаксический разбор, что по понятным причинам замедляет сборку. Я вполне доволен скоростью сборки проектов С++, ведь я правильно веду архитектуру )) Думаю модули добавят свои минусы и плюсы.

0

Убежденный

О чем и речь.
И чем больше проект - тем больше это замедление ощущается.

Поделишься секретами правильного ведения архитектуры?

Минимизация зависимостей, pimpl, forward declarations, отказ от реализаций в
заголовочных файлах и т.д. - это все давно известно, но желаемого профита не дает.
Все равно у C/C++ по сравнению с Delphi, C# и т.п. скорость компиляции просто
отвратительно медленная и то, что в других языках компилируется за секунды, в
C/C++ занимает минуты и даже часы.

Да, если у тебя N исходных файлов и каждый подключает <string>, то синтаксический
разбор <string> будет выполняться N раз. И никакой архитектурой это не исправишь.
Извращения с запихиванием всего кода в один большущий cpp-файл не рассматриваем.

1

@rikimaru2013

Ну замеры до и после, позволяет сказать об ускорении в2-3 раза. Что очень много) Да и умная компиляция IDE - только измененных ускоряет процесс разработки. Итого: не более минуты идёт компиляция изменений. А полная перекомпиляция ... . Я не стремлюсь за её скоростью - ведь в это время я пью чай с печеньками)

1