Сообщение Re[5]: C++'s lack of a module system от 20.05.2018 7:44
Изменено 20.05.2018 7:57 AlexGin
Re[5]: C++'s lack of a module system
Здравствуйте, Dair, Вы писали:
AG>>Да, обычная. Но стандартного (с точки зрения языка C++) метода применнинея библиотекам — нет.
D>А что, нужен? А зачем? Вообще давно придумали статические и динамические библиотеки, они, конечно, вне стандарта C++, но зачем это втаскивать в него, когда это вещи, зависящие от операционной система?
Вопрос: Стандарт нужен ли и зачем? — скорее риторический. Вот сделают и посмотрим, какие проблемы это решит.
Так, например, если бы то, что реализовано в том же C++11, мне показали лет десять назад, я точно также бы усомнился — надо ли это?
Тем не менее, теперь — охотно пользуюсь, и недоумеваю — как ранее работали без этого
AG>>То есть — это может быть только один заголовочник (*.h либо *.hpp файл).
AG>>Это может быть *.lib (статическая библиотека) с *.h файлом (файлами).
D>А вот какая разница? Как удобно разработчику — так и сделано.
Здесь подразумевается два разработчика — разработчик библиотечного модуля и разработчик продукта, в котором применяется данный модуль.
То, что удобно первому, далеко не всегда удобно второму и наоборот.
D>(Я считаю, что h/hpp-only оно может быть в чисто темплейтном случае, а если есть нетемплейтный код, его надо выносить в код)
+100500
D>Внутри компании библиотеки должны распространяться в исходных кодах, и пусть каждый проект из них делает то, что им надо — статическую библиотеку, динамическую, напрямую в проект влинковывает.
Смотря в какой компании. Здесь всё зависит от принятой в компании политики. Далеко не всегда одно подразделение делится исходниками с другим.
AG>>Также это может быть *.dll файл (как собственно DLL, так и в виде COM-компонента, исполненного в виде dll).
AG>>Что стандартно?
D>Стандартно отсутствие стандарта. Как хочешь — так и делай, решай сам, у тебя голова на плечах.
Так зачем мы сегодня с радостью пользуемся всм тем, что привнесли в нашу жизнь стсандарты C++11/14, зачем изучаем C++17?
Давай писать на C++ образца 1983 года...
AG>>Так определи понятие "библиотека" для C++
AG>>Что ты сам понимаешь под этим термином в контексте C++?
D>У меня рекурсивное определение: библиотека — это группа методов с схожим общим назначением и явно выраженной односторонней зависимостью от других библиотек.
Определение вроде вполне логичное, однако не полное — в плане отсутствия каких-либо упоминаний об интеграции с остальной (скажем так "клиентской") частью системы.
AG>>Да, обычная. Но стандартного (с точки зрения языка C++) метода применнинея библиотекам — нет.
D>А что, нужен? А зачем? Вообще давно придумали статические и динамические библиотеки, они, конечно, вне стандарта C++, но зачем это втаскивать в него, когда это вещи, зависящие от операционной система?
Вопрос: Стандарт нужен ли и зачем? — скорее риторический. Вот сделают и посмотрим, какие проблемы это решит.
Так, например, если бы то, что реализовано в том же C++11, мне показали лет десять назад, я точно также бы усомнился — надо ли это?
Тем не менее, теперь — охотно пользуюсь, и недоумеваю — как ранее работали без этого
AG>>То есть — это может быть только один заголовочник (*.h либо *.hpp файл).
AG>>Это может быть *.lib (статическая библиотека) с *.h файлом (файлами).
D>А вот какая разница? Как удобно разработчику — так и сделано.
Здесь подразумевается два разработчика — разработчик библиотечного модуля и разработчик продукта, в котором применяется данный модуль.
То, что удобно первому, далеко не всегда удобно второму и наоборот.
D>(Я считаю, что h/hpp-only оно может быть в чисто темплейтном случае, а если есть нетемплейтный код, его надо выносить в код)
+100500
D>Внутри компании библиотеки должны распространяться в исходных кодах, и пусть каждый проект из них делает то, что им надо — статическую библиотеку, динамическую, напрямую в проект влинковывает.
Смотря в какой компании. Здесь всё зависит от принятой в компании политики. Далеко не всегда одно подразделение делится исходниками с другим.
AG>>Также это может быть *.dll файл (как собственно DLL, так и в виде COM-компонента, исполненного в виде dll).
AG>>Что стандартно?
D>Стандартно отсутствие стандарта. Как хочешь — так и делай, решай сам, у тебя голова на плечах.
Так зачем мы сегодня с радостью пользуемся всм тем, что привнесли в нашу жизнь стсандарты C++11/14, зачем изучаем C++17?
Давай писать на C++ образца 1983 года...
AG>>Так определи понятие "библиотека" для C++
AG>>Что ты сам понимаешь под этим термином в контексте C++?
D>У меня рекурсивное определение: библиотека — это группа методов с схожим общим назначением и явно выраженной односторонней зависимостью от других библиотек.
Определение вроде вполне логичное, однако не полное — в плане отсутствия каких-либо упоминаний об интеграции с остальной (скажем так "клиентской") частью системы.
Re[5]: C++'s lack of a module system
Здравствуйте, Dair, Вы писали:
AG>>Да, обычная. Но стандартного (с точки зрения языка C++) метода применнинея библиотекам — нет.
D>А что, нужен? А зачем? Вообще давно придумали статические и динамические библиотеки, они, конечно, вне стандарта C++, но зачем это втаскивать в него, когда это вещи, зависящие от операционной система?
Вопрос: Стандарт нужен ли и зачем? — скорее риторический. Вот сделают и посмотрим, какие проблемы это решит.
Так, например, если бы то, что реализовано в том же C++11, мне показали лет десять назад, я точно также бы усомнился — надо ли это?
Тем не менее, теперь — охотно пользуюсь, и недоумеваю — как ранее работали без этого
AG>>То есть — это может быть только один заголовочник (*.h либо *.hpp файл).
AG>>Это может быть *.lib (статическая библиотека) с *.h файлом (файлами).
D>А вот какая разница? Как удобно разработчику — так и сделано.
Здесь подразумевается два разработчика — разработчик библиотечного модуля и разработчик продукта, в котором применяется данный модуль.
То, что удобно первому, далеко не всегда удобно второму и наоборот.
D>(Я считаю, что h/hpp-only оно может быть в чисто темплейтном случае, а если есть нетемплейтный код, его надо выносить в код)
+100500
В то же время, теперь часто в h/hpp выносят много кодогенерации (мне самому это не нпавится, но приходиться мириться).
D>Внутри компании библиотеки должны распространяться в исходных кодах, и пусть каждый проект из них делает то, что им надо — статическую библиотеку, динамическую, напрямую в проект влинковывает.
Смотря в какой компании. Здесь всё зависит от принятой в компании политики. Далеко не всегда одно подразделение делится исходниками с другим.
AG>>Также это может быть *.dll файл (как собственно DLL, так и в виде COM-компонента, исполненного в виде dll).
AG>>Что стандартно?
D>Стандартно отсутствие стандарта. Как хочешь — так и делай, решай сам, у тебя голова на плечах.
Так зачем мы сегодня с радостью пользуемся всм тем, что привнесли в нашу жизнь стсандарты C++11/14, зачем изучаем C++17?
Давай писать на C++ образца 1983 года...
AG>>Так определи понятие "библиотека" для C++
AG>>Что ты сам понимаешь под этим термином в контексте C++?
D>У меня рекурсивное определение: библиотека — это группа методов с схожим общим назначением и явно выраженной односторонней зависимостью от других библиотек.
Определение вроде вполне логичное, однако не полное — в плане отсутствия каких-либо упоминаний об интеграции с остальной (скажем так "клиентской") частью системы.
AG>>Да, обычная. Но стандартного (с точки зрения языка C++) метода применнинея библиотекам — нет.
D>А что, нужен? А зачем? Вообще давно придумали статические и динамические библиотеки, они, конечно, вне стандарта C++, но зачем это втаскивать в него, когда это вещи, зависящие от операционной система?
Вопрос: Стандарт нужен ли и зачем? — скорее риторический. Вот сделают и посмотрим, какие проблемы это решит.
Так, например, если бы то, что реализовано в том же C++11, мне показали лет десять назад, я точно также бы усомнился — надо ли это?
Тем не менее, теперь — охотно пользуюсь, и недоумеваю — как ранее работали без этого
AG>>То есть — это может быть только один заголовочник (*.h либо *.hpp файл).
AG>>Это может быть *.lib (статическая библиотека) с *.h файлом (файлами).
D>А вот какая разница? Как удобно разработчику — так и сделано.
Здесь подразумевается два разработчика — разработчик библиотечного модуля и разработчик продукта, в котором применяется данный модуль.
То, что удобно первому, далеко не всегда удобно второму и наоборот.
D>(Я считаю, что h/hpp-only оно может быть в чисто темплейтном случае, а если есть нетемплейтный код, его надо выносить в код)
+100500
В то же время, теперь часто в h/hpp выносят много кодогенерации (мне самому это не нпавится, но приходиться мириться).
D>Внутри компании библиотеки должны распространяться в исходных кодах, и пусть каждый проект из них делает то, что им надо — статическую библиотеку, динамическую, напрямую в проект влинковывает.
Смотря в какой компании. Здесь всё зависит от принятой в компании политики. Далеко не всегда одно подразделение делится исходниками с другим.
AG>>Также это может быть *.dll файл (как собственно DLL, так и в виде COM-компонента, исполненного в виде dll).
AG>>Что стандартно?
D>Стандартно отсутствие стандарта. Как хочешь — так и делай, решай сам, у тебя голова на плечах.
Так зачем мы сегодня с радостью пользуемся всм тем, что привнесли в нашу жизнь стсандарты C++11/14, зачем изучаем C++17?
Давай писать на C++ образца 1983 года...
AG>>Так определи понятие "библиотека" для C++
AG>>Что ты сам понимаешь под этим термином в контексте C++?
D>У меня рекурсивное определение: библиотека — это группа методов с схожим общим назначением и явно выраженной односторонней зависимостью от других библиотек.
Определение вроде вполне логичное, однако не полное — в плане отсутствия каких-либо упоминаний об интеграции с остальной (скажем так "клиентской") частью системы.