Объясните, пожалуйста, в чем выражается эта нехватка модульной системы в C++? Все классы в отдельных единицах трансляции обычно находятся. Чего не хватает?
В книжке Герба Саттера про Pimpl idiom написано, что:
it does help compensate for C++'s lack of a module system.
Здравствуйте, Максим Рогожин, Вы писали:
МР>Объясните, пожалуйста, в чем выражается эта нехватка модульной системы в C++?
Временем компиляции выражается. И плясками с бубнами при подключении сторонних библиотек.
Здравствуйте, Максим Рогожин, Вы писали:
МР>Привет!
МР>Объясните, пожалуйста, в чем выражается эта нехватка модульной системы в C++? Все классы в отдельных единицах трансляции обычно находятся. Чего не хватает?
Выскажу своими словами мой взгляд на проблему:
Когда у тебя C++ ный проект разростается и перестаёт быть малениким, ты задумываешся о том, что хорошо бы его разделить на некоторые части, при этом очень важно, чтобы данные части были максимально независимы (даже на случай повторного применения). При этом, желательно чтобы эти части имели некоторый законченный вид и могли бы передаваться между разработчиками.
И тут — тебя ждут пляски с бубнами
Для сравнения — если у тебя проект на C#, то этот самый момент является достаточно простым и безболезнынным (скорее даже тривиальным).
P.S. Тот факт, что классы — это отдельные единицы трансляци, не мешает пониманию того, что иногда несколько таких классов требуется
объединить в одну сущность — например: для подсистемы обеспечения работы с Базой Данных.
При этом, важно понимать, что сегодня — твой проект маленький и ты вполне обходишься применением (например) СУБД MySQL.
Завтра,по мере развития проекта и увеличения базы данных, встанет ворпос о переходе — например на ORACLE или MS SQL Server.
Очень важно — сделать так, чтобы изменения при переходе на более мощную СУБД коснулись ТОЛЬКО кодов работы с базой Данных!
То есть, изменения в кодах работы с данными, реализующими концепцию CRUD — https://en.wikipedia.org/wiki/Create,_read,_update_and_delete для применяемой тобой СУБД, а не всего твоего проекта. Другими словами — важна независимость подсистемы БД от всего остального проекта.
Важна также и возможность абстрагирования от подсистемы БД на уровне бизнес-логики и GUI твоей программы.
Именно это обеспечивает такое понятие как "модульность".
Здравствуйте, Максим Рогожин, Вы писали:
МР>Привет!
МР>Объясните, пожалуйста, в чем выражается эта нехватка модульной системы в C++? Все классы в отдельных единицах трансляции обычно находятся. Чего не хватает?
Можно ответить максимально просто
Без модулей при любом самом маленьком изменении заголовка класса требуется перекомпиляция всех единиц трансляции, которые используют этот заголовок. С модулями чаще всего это будет не нужно.
Здравствуйте, AlexGin, Вы писали:
AG>Когда у тебя C++ ный проект разростается и перестаёт быть малениким, ты задумываешся о том, что хорошо бы его разделить на некоторые части, при этом очень важно, чтобы данные части были максимально независимы (даже на случай повторного применения). При этом, желательно чтобы эти части имели некоторый законченный вид и могли бы передаваться между разработчиками.
Так это же обычная библиотека (классов, функций) ?!
AG>Именно это обеспечивает такое понятие как "модульность".
Здравствуйте, RedApe, Вы писали:
RA>Без модулей при любом самом маленьком изменении заголовка класса требуется перекомпиляция всех единиц трансляции, которые используют этот заголовок. С модулями чаще всего это будет не нужно.
Как такое может быть? Если изменился заголовок, то значит изменились и все единицы трансляции, которые используют этот заголовок.
Здравствуйте, Максим Рогожин, Вы писали:
МР>Здравствуйте, AlexGin, Вы писали:
AG>>Когда у тебя C++ ный проект разростается и перестаёт быть малениким, ты задумываешся о том, что хорошо бы его разделить на некоторые части, при этом очень важно, чтобы данные части были максимально независимы (даже на случай повторного применения). При этом, желательно чтобы эти части имели некоторый законченный вид и могли бы передаваться между разработчиками.
МР>Так это же обычная библиотека (классов, функций) ?!
+100500
Да, обычная. Но стандартного (с точки зрения языка C++) метода применнинея библиотекам — нет.
То есть — это может быть только один заголовочник (*.h либо *.hpp файл).
Это может быть *.lib (статическая библиотека) с *.h файлом (файлами).
Пример: boost — там в основном заголовочники,
но есть и статические либы и есть возможность даже динамического использования некоторых либ-ов: https://www.boost.org/doc/libs/1_62_0/boost/dll/shared_library.hpp
Также это может быть *.dll файл (как собственно DLL, так и в виде COM-компонента, исполненного в виде dll).
Что стандартно?
AG>>Именно это обеспечивает такое понятие как "модульность".
МР>Чем оно отличается от понятия библиотеки?
Так определи понятие "библиотека" для C++
Что ты сам понимаешь под этим термином в контексте C++?
Здравствуйте, AlexGin, Вы писали:
AG>Для сравнения — если у тебя проект на C#, то этот самый момент является достаточно простым и безболезнынным (скорее даже тривиальным).
А можете сказать за счет чего в C# этот момент является простым? В C# есть какой-то механизм, который отсутствует в C++? Почему этот механизм не добавят в C++?
Здравствуйте, Максим Рогожин, Вы писали:
AG>>Да, обычная. Но стандартного (с точки зрения языка C++) метода применнинея библиотекам — нет. МР>Т.е. C++'s lack of a module system — это про то, что в стандарте C++ нет понятия библиотека? Правильно?
Договориться они не могут. По уму, действие макросов не должно выходить за пределы модуля. Но то по уму, а вот эмбеддщики считают иначе.
Здравствуйте, Максим Рогожин, Вы писали:
МР>Здравствуйте, AlexGin, Вы писали:
AG>Для сравнения — если у тебя проект на C#, то этот самый момент является достаточно простым и безболезнынным (скорее даже тривиальным).
МР>А можете сказать за счет чего в C# этот момент является простым? В C# есть какой-то механизм, который отсутствует в C++? Почему этот механизм не добавят в C++?
ИМХО именно это, является препятствием (предположу, что всё-таки в преспективе преодолимым) для простого введения такого понятия как "модульность" в состав языка.
Также введению и поддержке модульности для C# и платформы .NET сопсобствует тот факт, что это продукция фактически одного производителя: M$.
Эта продукция закрывает относительно узкие нишевые решения (настольный PC, реже — сервер).
В мире C++ нет единого производителя.
Есть различные компании, производящие: компиляторы, линкеры, отладчики, системы сборки, IDE и библиотеки классов для C++. Тот факт, что C++ это универсальный язык (настольные PC, сервера, мобильные устройства, приборы промышленной автоматики, медицинское оборудование, системы военного назначения и т.д.) также добавляет сложности по аспекту модульности.
Учитывая всё сказанное, принятие единого стандарта на модульность выглядит достаточно непростым решением.
Здравствуйте, Максим Рогожин, Вы писали:
МР>Здравствуйте, RedApe, Вы писали:
RA>>Без модулей при любом самом маленьком изменении заголовка класса требуется перекомпиляция всех единиц трансляции, которые используют этот заголовок. С модулями чаще всего это будет не нужно.
МР>Как такое может быть? Если изменился заголовок, то значит изменились и все единицы трансляции, которые используют этот заголовок.
В существующей системе не может, а в модулях можно сделать, чтобы добавление комментария не вызывала потока перекомпиляции.
Здравствуйте, Максим Рогожин, Вы писали:
МР>Интересную статью нашел:
МР>A Module System for C++
МР>Можете объяснить откуда берется много исполняемого кода в modern C++ headers?
МР>
МР>with modern C++, header files contain lot of (executable) codes.
Здравствуйте, alex_mah, Вы писали:
_>Шаблоны, я так понимаю
Шаблоны и раньше были. Тут про modern C++ говорится.
Кстати, интересно, а как шаблоны в модулях определять? В модуле будет храниться просто заголовочный файл с определением шаблона и этот заголовочный файл будет включаться в те единицы трансляции где инстанциируется шаблон? Т.е. как обычно, с помощью препроцессора? Это уже не соответствует идее модулей.
Здравствуйте, AlexGin, Вы писали:
AG>Да, обычная. Но стандартного (с точки зрения языка C++) метода применнинея библиотекам — нет.
А что, нужен? А зачем? Вообще давно придумали статические и динамические библиотеки, они, конечно, вне стандарта C++, но зачем это втаскивать в него, когда это вещи, зависящие от операционной система?
AG>То есть — это может быть только один заголовочник (*.h либо *.hpp файл). AG>Это может быть *.lib (статическая библиотека) с *.h файлом (файлами).
А вот какая разница? Как удобно разработчику — так и сделано.
(Я считаю, что h/hpp-only оно может быть в чисто темплейтном случае, а если есть нетемплейтный код, его надо выносить в код)
Внутри компании библиотеки должны распространяться в исходных кодах, и пусть каждый проект из них делает то, что им надо — статическую библиотеку, динамическую, напрямую в проект влинковывает.
AG>Также это может быть *.dll файл (как собственно DLL, так и в виде COM-компонента, исполненного в виде dll). AG>Что стандартно?
Стандартно отсутствие стандарта. Как хочешь — так и делай, решай сам, у тебя голова на плечах.
AG>Так определи понятие "библиотека" для C++ AG>Что ты сам понимаешь под этим термином в контексте C++?
У меня рекурсивное определение: библиотека — это группа методов с схожим общим назначением и явно выраженной односторонней зависимостью от других библиотек.
