Здравствуйте, Shmj, Вы писали:
S>Как вы относитесь к этой библиотеке и примененному там подходу: https://github.com/CrowCpp/Crow
относительный минус одного огромного файла — некоторые IDE плохо с такими работают, начинают дико тормозить, не могут найти место в файле, когда пытаешься перейти к определению функции. Например, XCode такая.
Но так как это библиотека, работать напрямую с этим файлом ты не будешь, так что минусов нет
Шымж, кончай спамить, а. Есть конкретные вопросы — пиши. И уж будь добр больше контекста давай в своих сообщениях, а то ты все разделы форума захламляешь всякими рандомными вопросами. Вот конкретно тут: напиши, что ты ищешь; что смущает в этой либе; не можешь подключить — так и напиши; есть вопросы в производительности — так и спроси; какой подход тебя интересует; сам что думаешь.
Ну короче, твои посты кажутся написанными ботом. Я абсолютно не уверен, что ты все это через себя пропускаешь. Спамишь как из пулемета, блин.
Патриот здравого смысла
Re[2]: Когда пишут все в заголовках - в чем минусы?
Здравствуйте, wl., Вы писали:
wl.>Но так как это библиотека, работать напрямую с этим файлом ты не будешь, так что минусов нет
Минус в скорости сборки.
Минус может быть только один — объем транслируемого кода.
А так я вижу одни плюсы.
Например, SQLite — прямо в виде исходных кодов прямо в твой прогу включается, и она становится совершенно независимой от наличия SQLite у заказчика.
unit-тестирование с doctest — это класс!!!
Пока народ сочинял всякие проги/библиотеки для этого — я нифига не пользовался.
А сейчас — — блеск, инклуд написал, и пиши себе тесты по самые помидоры.
Я вот предпочитаю именно такой подход и стараюсь разыскать либу подобного типа для разных работ.
Это же сродни пакетам в Go.
Хочешь быть счастливым — будь им!
Без булдырабыз!!!
Re[4]: Когда пишут все в заголовках - в чем минусы?
Здравствуйте, Shmj, Вы писали:
S>Почему метод process_tasks реализован в заголовочном файле а не как обычно в cpp?
ну, так проще подключить этот код в свой проект.
кроме этого особых преимуществ я не вижу, остаются только недостатки.
по большому счёту, это личные предпочтения автора кода.
никакого скрытого мегазамысла в этом нет.
Здравствуйте, Shmj, Вы писали:
S>Как вы относитесь к этой библиотеке и примененному там подходу: https://github.com/CrowCpp/Crow
S>?
Минусы:
1) Время компиляции (и время отдельной единицы трансляции у пользователя библиотеки, и необходимость пересборки всего, при внесении изменений в код библиотеки).
2) Раздувание результирующего кода (клонирование тела inline функций).
3) Нарушение изоляции (инкапсуляции).
Плюсы:
1) Простота распространения/подключения.
Пока проект маленький — плюсы перевешивают, но с ростом проекта (с ростом числа таких библиотек) — минусы растут быстрее чем линейно, в отличии от плюса.
Нормально если это редко обновляемые библиотеки (извлекли из git-а, и живем с одной версией библиотеки, до выпуска следующего релиза).
Совсем плохо, если эта библиотека — ваша корпоративная (т.е. изменения в нее вносятся регулярно).
Эти изменения начинают заметно тормозить всех пользователей, даже если улучшения не меняют интерфейс библиотеки.
Здравствуйте, Shmj, Вы писали:
S>Когда пишут все в заголовках — в чем минусы?
На этот вопрос ты без труда мог бы найти ответ самостоятельно — если бы хотел, конечно.
S>Как вы относитесь к этой библиотеке и примененному там подходу: https://github.com/CrowCpp/Crow?
А в теле сообщения у тебя вообще другой вопрос — не тот, что в заголовке.
Все это указывает на то, что, скорее всего, ответы на вопросы тебя мало интересуют, ты просто заскочил потрындеть мимоходом.
- Как Вы относитесь к этой библиотеке?
— А Вы из какой газеты?
--
Не можешь достичь желаемого — пожелай достигнутого.
Здравствуйте, Chorkov, Вы писали:
C>2) Раздувание результирующего кода (клонирование тела inline функций).
Вроде бы уже давно inline -- это всего лишь указание компилятору на то, что нет нарушения ODR в результате включения одного заголовка в несколько единиц трансляции. Будет ли реальная подстановка тела в место вызова решает компилятор и, возможно, линкер.
C>3) Нарушение изоляции (инкапсуляции).
А это как?
Re[3]: Когда пишут все в заголовках - в чем минусы?
Здравствуйте, so5team, Вы писали:
S>Здравствуйте, Chorkov, Вы писали:
C>>2) Раздувание результирующего кода (клонирование тела inline функций).
S>Вроде бы уже давно inline -- это всего лишь указание компилятору на то, что нет нарушения ODR в результате включения одного заголовка в несколько единиц трансляции. Будет ли реальная подстановка тела в место вызова решает компилятор и, возможно, линкер.
Так, но если определение функции доступно в данной единице трансляции, то вероятность что она будет встроена — выше.
Если функция недоступна — то ниже. Если LTCG отключен, то точно не строит.
C>>3) Нарушение изоляции (инкапсуляции).
S>А это как?
Тут два аспекта:
1) Многие библиотеки мусорят в глобальное пространство имен. Возможны конфликты.
2) Если реализация видна пользователю "насквозь", то велик соблазн вызвать, например, вызвать функцию из `namespace private`.
Если детали реализации лежат в отдельных заголовочных файлах, которые недоступны для #include из стороннего кода — то такая вероятность сильно снижается.
Re[4]: Когда пишут все в заголовках - в чем минусы?
Здравствуйте, Chorkov, Вы писали:
S>>А это как?
C>1) Многие библиотеки мусорят в глобальное пространство имен. Возможны конфликты.
Понятно. Отмечу лишь, что не могу вспомнить header-only плюсовые библиотеки, которые бы не использовали пространств имен.
C>2) Если реализация видна пользователю "насквозь", то велик соблазн вызвать, например, вызвать функцию из `namespace private`.
Это уже из категории ССЗБ.
Re[5]: Когда пишут все в заголовках - в чем минусы?
Здравствуйте, Shmj, Вы писали:
S>Почему метод process_tasks реализован в заголовочном файле а не как обычно в cpp?
Это один частный файл, остальное это шаблон на шаблоне. Я думаю автор просто хотел header-only либу сделать.
Sic luceat lux!
Re[6]: Когда пишут все в заголовках - в чем минусы?
Здравствуйте, Kernan, Вы писали:
K>Здравствуйте, Shmj, Вы писали:
S>>Почему метод process_tasks реализован в заголовочном файле а не как обычно в cpp? K>Это один частный файл, остальное это шаблон на шаблоне. Я думаю автор просто хотел header-only либу сделать.
А что мешает с шаблонами применять стандартный механизм разделения на декларацию в заголовках и определение в cpp-файлах? Или вы просто не знаете как это записать?
Здравствуйте, rg45, Вы писали:
R>А ты еще более безмозглый, чем я думал R>Исчезни отсюда, пожалуйста. Тебе что, других форумов мало?
У нас принято даже при глупости собеседника — не опускаться до перехода на личности а давать исчерпывающий детальный ответ даже на глупый вопрос, как бы обличающий оппонента, чтобы всем все стало понятно. Я достаточно детально ответил на ваш вопрос?
