Эх, отвечаю, скорее всего, довольно запоздало, но тем не менее. Обычный std::basic_string (да и остальные контейнеры в STL) хранит тип, соответствующий требованиям, предъявляемым к аллокаторам. Если взять std::allocator, то по сути он просто имеет парочку методов типа allocate/deallocate и construct/destroy, а внутри никаких данных в виде полей он не содержит. В таком случае накладные расходы для его использования минимальны: 1 байт. Да и от этих накладных расходов разработчики реализаций STL уходят, используя empty-base optimization. Например, Microsoft использует свой _Compressed_pair, gcc объявляет структуру _Alloc_hider, которая делает примерно то же самое, что и _Compressed_pair (но, по моему скромному мнению, немного хуже, чем Microsoft). Вот и получается, что в обычной имплементации это работает несколько лучше.
В тот же день пофиксил свою проблему спустя пару часов разных попыток. Моя проблема заключалась в том, что на руках имеется большой проект, и библиотек там используется несколько. Я написал велосипед такого вида:
Суть в том, что я с самого начала пробовал эту версию, просто забыл, что у меня есть зависимость ещё и от lib_b :) А потом пробовал с ENVIRONMENT_MODIFICATION, но оно используется для одного изменения переменных окружения, то есть я пробовал одну и ту же переменную несколько раз обновить, но применялось только последнее изменение.
Эххх, я, наверное, уже слишком поздно пишу, но сейчас буквально работаю с тестами и CMake. Копировать DLL библиотеки под маздаем к исполняемому файлу с тестами может быть разумно, когда она одна. А когда их несколько, то начинаются танцы с бубном, по типу этих https://gist.github.com/micahsnyder/5d98ac8548b429309ec5a35bca9366da
А вот тут https://stackoverflow.com/a/76914147 вообще рекомендуют использовать set_tests_properties и прописывать в PATH путь до библиотек. Правда, у меня почему-то не срабатывает. Не знаю, может быть, есть идеи, как это сделать для больших проектов с кучами библиотек (по типу проектов на Qt, например). Каждый раз копировать библиотеки к бинарю с тестами выглядит как ужасный костыль...
Можете тогда объяснить, как надо правильно работать с БД или какие-нибудь другие паттерны? Или посоветуете чего почитать и какие статьи глянуть. Только начал изучать взаимодействие с БД из приложения, пока ничего критического в описанных паттернах не вижу...
Вроде это как и показатель предусмотрительности, и вроде как круто быть на шаг впереди (а иногда и на несколько шагов), но так и до паранойи недалеко. Учитывая абсурд нынешних законопроектов, ящетаю, надо лишь искать солярку для ближайшего трактора. Тогда и паранойи нет, и вроде спасён от бутылочки.
Я, если честно, не особо понимаю, как работает вся система (так как никогда с работой этих самых аппаратов не сталкивался). Думаю, товарищ майор не просто так посещает тех или иных людей.
Очередной байт на нологи... Пусть лучше разрабов "Смуты" судят и взымают обратно вложенные непонятно во что 500кк вечно деревянных
Эх, отвечаю, скорее всего, довольно запоздало, но тем не менее. Обычный
std::basic_string(да и остальные контейнеры в STL) хранит тип, соответствующий требованиям, предъявляемым к аллокаторам. Если взятьstd::allocator, то по сути он просто имеет парочку методов типаallocate/deallocateиconstruct/destroy, а внутри никаких данных в виде полей он не содержит. В таком случае накладные расходы для его использования минимальны: 1 байт. Да и от этих накладных расходов разработчики реализаций STL уходят, используяempty-base optimization. Например, Microsoft использует свой _Compressed_pair, gcc объявляет структуру _Alloc_hider, которая делает примерно то же самое, что и _Compressed_pair (но, по моему скромному мнению, немного хуже, чем Microsoft). Вот и получается, что в обычной имплементации это работает несколько лучше.Тогда разве не получается, что бесплатными могут быть только двузначные номера? Немного запутался на этом моменте
В тот же день пофиксил свою проблему спустя пару часов разных попыток. Моя проблема заключалась в том, что на руках имеется большой проект, и библиотек там используется несколько. Я написал велосипед такого вида:
Суть в том, что я с самого начала пробовал эту версию, просто забыл, что у меня есть зависимость ещё и от
lib_b:) А потом пробовал сENVIRONMENT_MODIFICATION, но оно используется для одного изменения переменных окружения, то есть я пробовал одну и ту же переменную несколько раз обновить, но применялось только последнее изменение.А пример такого рода информацию можете привести? Аж интересно стало
Эххх, я, наверное, уже слишком поздно пишу, но сейчас буквально работаю с тестами и CMake. Копировать DLL библиотеки под маздаем к исполняемому файлу с тестами может быть разумно, когда она одна. А когда их несколько, то начинаются танцы с бубном, по типу этих https://gist.github.com/micahsnyder/5d98ac8548b429309ec5a35bca9366da
А вот тут https://stackoverflow.com/a/76914147 вообще рекомендуют использовать
set_tests_propertiesи прописывать в PATH путь до библиотек. Правда, у меня почему-то не срабатывает. Не знаю, может быть, есть идеи, как это сделать для больших проектов с кучами библиотек (по типу проектов на Qt, например). Каждый раз копировать библиотеки к бинарю с тестами выглядит как ужасный костыль...Есть пробитие!
Вообще жесть, наоборот же должно быть. Я помню, раньше наоборот многим не нравились русские озвучки. Видимо, время совсем поменялось...
Заранее извиняюсь, если чем-то Вас обижу, но Ваш ответ буквально звучит как "радуйтесь, что Ваш продукт бесплатно использовали в коммерческих целях")
Можете тогда объяснить, как надо правильно работать с БД или какие-нибудь другие паттерны? Или посоветуете чего почитать и какие статьи глянуть. Только начал изучать взаимодействие с БД из приложения, пока ничего критического в описанных паттернах не вижу...
Вроде это как и показатель предусмотрительности, и вроде как круто быть на шаг впереди (а иногда и на несколько шагов), но так и до паранойи недалеко. Учитывая абсурд нынешних законопроектов, ящетаю, надо лишь искать солярку для ближайшего трактора. Тогда и паранойи нет, и вроде спасён от бутылочки.