Ну вот скажем если бы в C/C++ была конструкция #include source то можно было бы включать библиотеки в исходники проекта без всяких там make и прочей лабуды.
Скажем хочу включить pnglib ну и пишу одну строку:
И не надо мне никаких package managers, всяких там cargo, npm и прочей фигни. Ну блин задрало же. Как библиотека так своя хитровывернутая система сборки ...
Здравствуйте, c-smile, Вы писали:
CS>Ну вот скажем если бы в C/C++ была конструкция #include source то можно было бы включать библиотеки в исходники проекта без всяких там make и прочей лабуды.
CS>Скажем хочу включить pnglib ну и пишу одну строку:
CS>
CS>И не надо мне никаких package managers, всяких там cargo, npm и прочей фигни. Ну блин задрало же. Как библиотека так своя хитровывернутая система сборки ...
Так можно делать уже очень давно. Главное, чтобы пути были доступны в вашей билд системе. И не было опциональной компиляции (например, платформозависимого кода).
А вообще уже скоро будут модули
M>что я туплю, в чем отличие от обычного #include?
Тем что обычным #include может заинклюдиться лишний хлам.
Полагаю c-smile хочет инструкцию для компилятора, чтобы она заставляла его компилировать указанный файл отдельно, а также сообщить об этой единице трансляции линковщику. Также, например, как в MSVC можно указывать необходимые библиотеки, через #pragma comment(lib, "some.lib")
Здравствуйте, SaZ, Вы писали:
CS>>И не надо мне никаких package managers, всяких там cargo, npm и прочей фигни. Ну блин задрало же. Как библиотека так своя хитровывернутая система сборки ...
SaZ>Так можно делать уже очень давно. Главное, чтобы пути были доступны в вашей билд системе. И не было опциональной компиляции (например, платформозависимого кода).
Забыли добавить, ещё чтобы не было функций с одинаковыми именами.
Здравствуйте, _NN_, Вы писали:
_NN>Здравствуйте, SaZ, Вы писали:
CS>>>И не надо мне никаких package managers, всяких там cargo, npm и прочей фигни. Ну блин задрало же. Как библиотека так своя хитровывернутая система сборки ...
SaZ>>Так можно делать уже очень давно. Главное, чтобы пути были доступны в вашей билд системе. И не было опциональной компиляции (например, платформозависимого кода). _NN>Забыли добавить, ещё чтобы не было функций с одинаковыми именами.
_NN>...
Ну если человек представляет как работает инклюд, то с этим проблем не будет. Мы такие вещи часто в кодстайл выносим, чтоб юнити билд работал.
SaZ>Ну если человек представляет как работает инклюд, то с этим проблем не будет. Мы такие вещи часто в кодстайл выносим, чтоб юнити билд работал.
Интересно. А какой код стайл?
Давать префиксы функциям? Так static и сделан для того, чтобы не нужно было этим заморачиваться .
И как решаются классы в сpp файлах ?
SaZ>>Ну если человек представляет как работает инклюд, то с этим проблем не будет. Мы такие вещи часто в кодстайл выносим, чтоб юнити билд работал.
_NN>Интересно. А какой код стайл? _NN>Давать префиксы функциям? Так static и сделан для того, чтобы не нужно было этим заморачиваться . _NN>И как решаются классы в сpp файлах ?
_NN>
Да, использовали уникальные неймспейсы либо уникальные имена.
А вот с одинаковыми именами классов мне за 10 лет практики вообще не приходилось сталкиваться. Да и чисто теоретически сложно придумать случай, когда нужно было бы иметь два класса с одинаковыми именами и разным функционалом.
Тут надо понимать, что это осознанное ограничение (на мой взгляд — очень незначительное) ради ускорения сборки.
Модули — это способ ввести имена (функций, методов, классов, пространств имен) в единицу трансляции. Ровно то же, что делают заголовочные файлы, ничего более. Только делается это на уровне языка, а не текстового препроцессора. Ничего того, что хочет ТС модули не дадут.
Вокруг модулей много ажиотажа и ожиданий, но модули лишь аккуратно сделанные, чуть улучшенные заголовочные файлы. Они не делают ничего более, чем заголовки. Более того, аккуратно написанный заголовочный файл делается модулем в одну строку.
SaZ>Да, использовали уникальные неймспейсы либо уникальные имена. SaZ>А вот с одинаковыми именами классов мне за 10 лет практики вообще не приходилось сталкиваться. Да и чисто теоретически сложно придумать случай, когда нужно было бы иметь два класса с одинаковыми именами и разным функционалом. SaZ>Тут надо понимать, что это осознанное ограничение (на мой взгляд — очень незначительное) ради ускорения сборки.
Конечно, если об этом думать заранее то вполне несложно следовать правилам .
А вот взять простой проект и собрать его таким образом сходу не выйдет.
Я как-то пол дня убил, чтобы собрать так проект
Здравствуйте, std.denis, Вы писали:
M>>что я туплю, в чем отличие от обычного #include?
SD>Также, например, как в MSVC можно указывать необходимые библиотеки, через #pragma comment(lib, "some.lib")
Именно, почему можно #pragma comment(lib, "some.lib"), но что мешает сделать #include source "some.lib.c" ?
Здравствуйте, c-smile, Вы писали:
SD>>Также, например, как в MSVC можно указывать необходимые библиотеки, через #pragma comment(lib, "some.lib")
CS>Именно, почему можно #pragma comment(lib, "some.lib"), но что мешает сделать #include source "some.lib.c" ?
Я думаю, технически ничего не мешает, просто не особо востребовано, видимо. Да и не нужно забывать, что все "прагмы" — это специфика отдельных компиляторов.
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, rg45, Вы писали:
R>Здравствуйте, c-smile, Вы писали:
SD>>>Также, например, как в MSVC можно указывать необходимые библиотеки, через #pragma comment(lib, "some.lib")
CS>>Именно, почему можно #pragma comment(lib, "some.lib"), но что мешает сделать #include source "some.lib.c" ?
R>Я думаю, технически ничего не мешает, просто не особо востребовано, видимо. Да и не нужно забывать, что все "прагмы" — это специфика отдельных компиляторов.
Ну дык я и не прошу pragm'у.
Хватит простого #include source "src.c" и не надо будет городить огород с модулями, make и прочей лабудой.