Это очень важно: от вас не потребуется разделять файлы на заголовок и исходный код.

Подумайте только: количество файлов в обычном C ++ проекте уменьшится вдвое!

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

Нам нужно упростить задачу, чтобы расширить наше сообщество C ++! Это важно!

Согласованность декларации

Из предыдущего абзаца мы можем вывести более точный факт: Больше не будет проблем с согласованностью порядка объявления.

О чем я говорю? Не знаю, похожи ли вы на меня, но самое важное, что я не могу вынести в C ++, - это то, что он требует от меня соблюдения принципа «декларация против определения»: в любом случае от вас потребуют повторите себя, если вы хотите разработать проект на C ++, состоящий из более чем одного файла.

Хотите увидеть пример? Нет, это ужасно. Но, тем не менее, я покажу один здесь, чтобы вы увидели настоящую проблему.

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

Теперь с приведенным выше кодом возникает пара проблем:

  • Вам нужно указать включить охранников.
  • Невозможно узнать, какой спецификатор доступа имеет конкретный метод, если вы просматриваете только исходный файл («cat.cpp»).
  • Подпись каждого актуального метода нужно указывать дважды.
  • Лучше сохранять последовательность объявления последовательным (так у вас будут лучшие возможности навигации по коду), и, следовательно, вам нужно отслеживать его, что просто избыточная работа, которую вам нужно выполнить .

Подлинный дизайн C ++ нарушает принцип DRY и заставляет вас выполнять избыточную работу, что недопустимо.

Лучшее время компиляции

Ура!

Время компиляции обещают сократить до 20%. Это является следствием того факта, что нет необходимости читать и обрабатывать все эти #include операторы каждый раз, когда компилятор их видит.

Хотите пример? Я напишу простое приложение hello world и сравню размеры реальной программы, которую мы написали, с ее предварительно обработанной версией (версия программы, в которой все #include решены).

Давайте посмотрим на «фальшивый» размер нашей программы:

Как видно из рисунка, размер написанной нами программы составляет всего 95 байт.

Теперь сравним результаты выше с предварительно обработанной версией:

Мы видим, что, боже мой, препроцессированный файл огромен: он занимает 644 КБ (658905 байт). Это невероятно и безумно.

И, тем не менее, это всего лишь приложение hello world. Подумайте, сколько еще материала должен обработать компилятор C ++ при компиляции нормального проекта SLOC размером ~ 10k. Невообразимо.

Управление пакетами

Было бы намного проще реализовать и стандартизировать систему управления пакетами для C ++ с помощью модулей TS.

И здесь я хочу отметить одну вещь. Скомпилированный характер C ++ не является причиной того, что у него еще нет хорошего менеджера пакетов (например, Rust). Виной всему отсутствие понятия модуль. Действительно.

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

Очевидно, что ни один из них не стал стандартом мира C ++.

Устранение использования препроцессора

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

Я знаю, что препроцессор C - это хорошо, и он имеет много преимуществ для C ++, но, тем не менее, замена препроцессора сделает язык проще и чище.

Модуль включает порядок выписки

Порядок новых import операторов (из модулей TS) не имеет значения. Вообще.

Почему тебе должно быть до этого дело?

Что ж, позвольте мне привести пример прямо здесь.

Скажем, например, вы хотите использовать две (абсолютно не связанные) библиотеки в своем проекте C ++. Первая библиотека, которая называется «Cat», содержит определение класса «Cat». Второй, назовем его «Явное отсутствие батута» (или просто «CAT»), содержит кое-что еще (я не знаю, как создавать названия для программных продуктов).

Теперь библиотека «Cat» содержит параметр #define'd CAT_PRINT, который, если он включен, добавляет метод Cat::print() к определению класса Cat:

Бывает, что вторая библиотека, сокращенно «CAT», также имеет параметр CAT_PRINT, который, по сути, отвечает за что-то совершенно глупое, которое вы никогда не хотите включать.

Угадай, что? Вам нужно выбрать. Что ты будешь делать? Что ж, вы можете выбросить одну из библиотек и либо реализовать ее самостоятельно, либо, возможно, найти другую библиотеку с аналогичной функциональностью.

Это проблема. Мы не хотим, чтобы такие вещи были внутри C ++!

Где я могу это попробовать?

Модули C ++ TS обещали стандартизировать в стандарте C ++ 17, но, однако, этого не произошло. Вместо этого сейчас все говорят о стандартизации модулей C ++ 20. Было бы здорово, если бы это действительно произошло.

Существует несколько возможных подходов к реализации новой модульной системы:

Первый более популярен, чем второй, но, вероятно, полученная реализация будет результатом слияния двух.

Поддержка компилятора на данный момент очень слабая и экспериментальная.

Функция модулей была объявлена ​​доступной в VS 2015 Update 1, и в мае 2017 года были некоторые обновления по этой теме. Я лично не использую Windows, и, следовательно, я ничего не могу сказать о реальной реализации VS. использование.

CLang 6 также поддерживает экспериментальные модули.

Заключение

Если вас интересуют модули C ++, можно воспользоваться следующими материалами:

Если хотите, оставляйте свои мысли и идеи по поводу этой ТС в комментариях. Я буду и дальше интересоваться модулями C ++, поэтому буду публиковать обновления по этому поводу. Хорошего дня!