инициализовать после конструктора, например

в make_derived_2

Вооот, от этого я и пришёл. Контекст требуется уже внутри конструктора Derived, поэтому после - не получится

хм...

в любом случае меня учили в книжках, что агрегация уменьшает связность

а зачем вообще нужен второй конструктор?

он же может быть использован только в make_derived_2

Там в примере показаны две ситуации - нормальная, но не очень удобная и та, которую я хочу

В идеале нужно удалить конструктор Derived, который использует void*

Ну его сейчас можно удалить и юзать вторую фабрику. Собственно вопрос в том, законно ли это

фактически класс Derived при использовании конструктора 2 должен получить этот void*

все равно должен

все равно любой код, вызывающий этот конструктор, обязан знать этот void*

Должен. Вот он получает его еще до того, как сам сконструировался

да, но получается, что выставляется требование проинициализировать Base перед вызовом конструктора

а это то же самое, что передать Base* в кажестве параметра при агрегации

все равно любой код, вызывающий этот конструктор, обязан знать этот void*

Но если это будет шаблонная фабрика, скрытая в недрах библиотеки, то всё ок

а в чем проблема шаблонной фабрики использовать способ 1?

В том, что она требует от Derived дополнительного параметра в конструкторе void* context

я просто не могу никак понять, почему в данном случае _неявная_ передача параметра способом 2 вообще отличается от _явной_ способом 1, если параметр обязателен

Неявная передача параметра способом 2 делается внутри шаблонной фабрики и пишется один раз. А первый способ требует в каждом наследнике Base (пусть их 100) писать долбаный параметр в конструктор, который вообще является частью внутреннего интерфейса библиотеки

понял

мы хотим, чтобы класс Derived42 не знал про то, как инициализируется Base и что он вообще инициализируется

Ага

но при этом хочет его использовать

а нельзя сделать параметр конструктора отдельным типом?

и разрешить неявное преобразование дабла?

Во-первых, конструктор там будет иметь любое кол-во аргументов

Про неявное преобразование не понял

ну я пишу

Derived(base_constructor_arguments_type a)

и разрешаю base_constructor_arguments_type(double)

о_О

Зачем менять конструктор Derived?

А, и фабрика напрямую вызываться не будет, конечно

Она там внутри либы тоже болтается

для того, чтобы выполнить два условия: одновременно получить только нужные параметры и при этом получить еще один неявно

А можно пример? Я всё равно не понимаю, в чём идея

идея что вместо Derived(double, int) пишем сигнатуру Derived(helper<double, int>

где helper на самом деле еще содержит контекст

у меня пока возникла одна идея в случае агрегации: а нет гарантии, что если указано union{ Base* base; ??? }; то компилятор не будет инициализировать поле?

Ага, но пользователь опять расстроен, что ему придётся писать код

В чём моя фабрика-то неправильная?)

идея что вместо Derived(double, int) пишем сигнатуру Derived(helper<double, int>

А, и всё равно придётся это передавать в конструктор Base, о чем опять грустит юзер

я подумал за логику и решил, что нельзя требовать с компилятора ничего не трогать в данном случае

Предполагаем, что в базовом классе только указатель и какие-нибудь int, double, char

потому что переменная класса может быть объявлена в глобале, а у компилятора там обязанность все инициализировать

емнип, конечно

??

Чего? Это ж не статическое поле

Вот меня тоже только это смущает - что вызванный Base() по умолчанию потрёт контекст, записанный туда ранее

на кого распространяется правило инициализации при объявлении в глобале? только на int всякие или на все объекты?

Есть вопрос к ненавистникам UB: http://cpp.sh/2rbzm внутри main()

Мракобесие... Не делайте так, у вас сойдут с ума санитайзеры и оптимизатор. Вам необходимо передавать контекст внутрь базового класса так, чтобы Derived ничего не знал об этом? Создайте в базовом классе private: static thread_local void* ctx; static void* get_context(); static void set_context(void*); Явно вызывайте get_context() в конструкторе базового. Сделайте frined template <class Derived> factory_method; внутри базового, в фабрике делайте set_context(); Но всё это выглядит как-то болезненно и неправильно, буд-то что-то неправльно с иерархией классов... Кстати, посмотрите библиотеку DI https://github.com/boost-experimental/di она решает вашу проблему

на кого распространяется правило инициализации при объявлении в глобале? только на int всякие или на все объекты?

А в глобале такие объекты жить и не будут

просто если такое правило распространяется на все объекты, я не верю, что стандарт требует, что инициализация блока памяти произойдет НЕ в момент вызова конструктора

то есть здесь моя "Б. Логика" требует, чтобы случай, когда конструктор явно не инициализирует переменные, считался UB

Мракобесие... Не делайте так, у вас сойдут с ума санитайзеры и оптимизатор. Вам необходимо передавать контекст внутрь базового класса так, чтобы Derived ничего не знал об этом? Создайте в базовом классе private: static thread_local void* ctx; static void* get_context(); static void set_context(void*); Явно вызывайте get_context() в конструкторе базового. Сделайте frined template <class Derived> factory_method; внутри базового, в фабрике делайте set_context(); Но всё это выглядит как-то болезненно и неправильно, буд-то что-то неправльно с иерархией классов... Кстати, посмотрите библиотеку DI https://github.com/boost-experimental/di она решает вашу проблему

Оооо, это гениально. Идею понял, круто.

это неявная передача параметра как раз

С DI придётся юзера заставлять что-то писать (совсем не простое)

это неявная передача параметра как раз

Если имелось в виду это, то прошу прощения, не понял

просто если такое правило распространяется на все объекты, я не верю, что стандарт требует, что инициализация блока памяти произойдет НЕ в момент вызова конструктора

Да тут вообще глобала нет. Если отсутствие инициализации - UB, то да, я облажался

ERROR: S client not available

да не, я почему-то не подумал, что можно в действительности ЯВНО написать НЕЯВНУЮ передачу параметра через thread_local

Да thread_local можно было бы потом прикрутить, когда я вспомнил бы о потоках

интересно, у вижака есть известный мне note, распространяется ли он на thread_local

On Windows operating systems before Windows Vista, __declspec( thread ) has some limitations. If a DLL declares any data or object as __declspec( thread ), it can cause a protection fault if dynamically loaded. After the DLL is loaded with LoadLibrary, it causes system failure whenever the code references the __declspec( thread ) data. Because the global variable space for a thread is allocated at run time, the size of this space is based on a calculation of the requirements of the application plus the requirements of all the DLLs that are statically linked. When you use LoadLibrary, you cannot extend this space to allow for the thread local variables declared with __declspec( thread ). Use the TLS APIs, such as TlsAlloc, in your DLL to allocate TLS if the DLL might be loaded with LoadLibrary.

Мракобесие... Не делайте так, у вас сойдут с ума санитайзеры и оптимизатор. Вам необходимо передавать контекст внутрь базового класса так, чтобы Derived ничего не знал об этом? Создайте в базовом классе private: static thread_local void* ctx; static void* get_context(); static void set_context(void*); Явно вызывайте get_context() в конструкторе базового. Сделайте frined template <class Derived> factory_method; внутри базового, в фабрике делайте set_context(); Но всё это выглядит как-то болезненно и неправильно, буд-то что-то неправльно с иерархией классов... Кстати, посмотрите библиотеку DI https://github.com/boost-experimental/di она решает вашу проблему

Спасибо, кстати.

Неазчто :)

интересно, у вижака есть известный мне note, распространяется ли он на thread_local

Да, распространяется и на thread_local. Немного вот тут описана печаль: http://www.boost.org/doc/libs/1_64_0/doc/html/boost_dll/missuses.html А именно: Issue: Thread local storage seems to be corrupted. Fix: Some platforms have no out-of-the-box support for plugins that use TLS, for example Windows. Use platform specific workarounds or just do not use TLS in plugins.

я так и подозревал ?

Но вы эту проблему заметите только если ручками подгружаете библиотеку (используете плагины). Если вы библиотеку прилинковали - то всй нормально.

спасибо за заботу :) я не первый день в вин разработке, так что в целом понятен текст, который пишут на MSDN :)

собственно, я знаю, потому что у нас используется thread_local и это ограничение к dll в хелпе приписано

спасибо за заботу :) я не первый день в вин разработке, так что в целом понятен текст, который пишут на MSDN :)

:) Мне он всегда не понятен. Приходится вдуплять по часу на каждую страницу

при этом можно неплохо огрести, например, SetWindowsHookEx не с _LL будет подгружать библиотеку через LoadLibrary

Обсуждение IDE - в #supapro.

флудить-то не запрещайте мимими

флудить-то не запрещайте мимими

Флудить во @fludpac.

Флудить во @fludpac.

@fludpac :)

Холивары - в @pro.cxx.holywars)

#holywar

#holywar

С таким заявлением вам лучше сюда: pro.cxx.holywars

вообще, ловите идею: автоматически синтезировать подконфу для обсуждения тем

вообще, ловите идею: автоматически синтезировать подконфу для обсуждения тем

@AlexFails

собственно, у меня нет идей как по-другому не превращать любую конфу во <s>флуд</s> объяснение, как работает std::move

:D

#chatlist

#chatlist

Другие чаты ? @ProCxx – чат для серьезных вопросов; ? @ProCxxLib – библиотека книг по языку C++, проектированию и программированию; ? @ProCxxNews – новости из мира C++, интересные статьи и пр. ? @ProAlgorithms – чат по обсуждению вопросов проектирования, архитектуры программного обесепечения; ? @ProLua – чатик по скриптовому языку Lua; ? @fludpac – флудилка, чат по обсуждению всего; ? @xthon – канал с цитатами участников pro.* ? @prodot – канал pro.*; ? @flood – общий флуд канала @prodot; ? supapro.cxx – чат помощи для новичков; ? pro.git – чат по обсуждению Git; ⚔ pro.cxx.holywars – чат для любителей холиваров; ?pro.net – чат по .NET Framework; ?pro.linux – чат по Линуксу; ?pro.linux.old – самая первая группа из коллекции pro.*. Вход по инвайтам, т.к. создатель группы удалился из telegram; ? Opengl / opencl / Vulkan / etc gamedev – no-flood-чат по опенглу и пр. Читайте правила при входе! Пока не в системе pro.* English chats ❤️ @undertale_chat – chat about the Undertale game; ?? pro.english – chat about learning English.

вот вам набор ссылок

Другие чаты ? @ProCxx – чат для серьезных вопросов; ? @ProCxxLib – библиотека книг по языку C++, проектированию и программированию; ? @ProCxxNews – новости из мира C++, интересные статьи и пр. ? @ProAlgorithms – чат по обсуждению вопросов проектирования, архитектуры программного обесепечения; ? @ProLua – чатик по скриптовому языку Lua; ? @fludpac – флудилка, чат по обсуждению всего; ? @xthon – канал с цитатами участников pro.* ? @prodot – канал pro.*; ? @flood – общий флуд канала @prodot; ? supapro.cxx – чат помощи для новичков; ? pro.git – чат по обсуждению Git; ⚔ pro.cxx.holywars – чат для любителей холиваров; ?pro.net – чат по .NET Framework; ?pro.linux – чат по Линуксу; ?pro.linux.old – самая первая группа из коллекции pro.*. Вход по инвайтам, т.к. создатель группы удалился из telegram; ? Opengl / opencl / Vulkan / etc gamedev – no-flood-чат по опенглу и пр. Читайте правила при входе! Пока не в системе pro.* English chats ❤️ @undertale_chat – chat about the Undertale game; ?? pro.english – chat about learning English.

Мафии нету

какая к дьяволу мафия с открытым инвайтом? ;)