Возможно ли такое?

Пример:


Т.е. до вызова конструктора базового класса, надо установить флажок. Компилятор выдает варнинг, что флажок должен быть инициализирован после базового класса. Можно реализовать это корректно?

И он, редиска, [компилятор] делает по своему.

Только множественное наследование?

maytonМожно, если заменить наследование композицией. Или перенести флажок в контекст класса а не экземпляра.

Композицией не охота. Большой интерфейс тащить за собой не хочеться, плюс сложность в модификации, если у предка будут новые методы добавляться. Уж лучше множественную.

В контекст класса ??? . Статик что ли?

kolobok0 Akh...Т.е. до вызова конструктора базового класса, надо установить флажок....

а можно пример такой задачи то ? может есть пути более ровные ?

с уважением
(круглый)

Задача такая:
Есть класс, который имеет набор функций, вызовом коих управляет базовый класс. В этих функциях происходит доступ к данным (список очередей на векторах). В конструкте базового класса происходит создание потока, который может начать тыркать эти функции.
А теперь добаляется фича - при создании объекта надо проинициализировать эти данные, например, загрузить некоторые значения. Допустим из таблицы. Не важно, но заранее не определенные.

Как я вижу, стандартные решения - разного рода mutexы и семафоры или средства межпотокового взаимодействия. Но! Загрузка происходит один раз (при создании объекта), все функции работы с данными происходят синхронно (отвечают базовые классы). Так что я здесь не вижу смысла тратить время на дополнительные средства во время установившейся работы программы.

Моя идея, проста до невозможности. До создания базового класса поставить флажок, мол, доступ к данным запрещен, после создается базовый класс, потом производится инициализация, после, флажок снимается. В функциях получается затраты ресурсов на один if.

kolobok0мне пришло на ум две идеи...незнаю насколько это отвечает Вашим требованиям...
1) по умолчанию в базовом - запрет на "доступ к данным", там где это необходимо в производном конструкторе сбрасываем сей флаг (возможно вообще без флага, а просто вызов явно инициализации).
2) если у Вас поток организован внутри базового, то при старт апе дожидаемся конца отработки конструктора, и после этого запрашиваем виртуальный метод - а собственно нам разрешён ли "доступ к данным"


ну где то так...
с уважением
(круглый)

1. Модель предпологает, что базовый класс не знает об ограничениях производных. Эта модель у меня родилась от каждого класса, отвечающего самого за себя. Но в целях ограничения числа потоков, т.к. их использование не оправдано, управление передалось базовым классам. Поэтому нагружать предков своими проблемами не хочу. :)
2. Опять же вопросы у предков. Хотя решение и красивое (т.к. в этой модели как раз все на виртуальных методах и построено), но опять надо загружать предка. Я сразу это решение переродил в более общее - "ну, что, поехали?" :). Но здесь есть несколько но! Во первых, вроде бы, никто нам не разрешить из конструктора вызывать виртуальны метод, а во вторых, запуск потока во время выхода из конструктора базового класса и в входа в производный, чревато тем, что флажек еще не инициализируется.

А сорри. Да не из конструктора, а из потока. Но второе но остается.

Ладно. Спасибо за советы. Думаю, что пока самым простым вариантом будет множественное наследование.

maXmoможет, всё-таки вытащить запуск потока куда-нить из конструктора?

А зачем? Для этого надо будет плодить функцию init.

Я, вообще, не приверженец множественного наследования, но в данном случае это не нагружает всю иерархию классов.

maXmoчтобы потомки успели сконструироваться, а то это жестоко — что-то начать делать не дождавшись конструктора.

Да, я тоже об этом думал. Но это дело можно "запомнить" в наследнике. А по завершению конструирования, "вспомнить" и актуализировать данные.

Gluk (Kazan) AkhМоя идея, проста до невозможности. До создания базового класса поставить флажок, мол, доступ к данным запрещен, после создается базовый класс, потом производится инициализация, после, флажок снимается. В функциях получается затраты ресурсов на один if.

Создаем Event, синхронизируемся, грохаем Event. В каком месте издержки ?
Все описанное мне ОЧЕНЬ не нравится.

1. Базовый флаг не должен знать о каких-то флагах производного.
2. Как порожденный поток будет контролировать этот флаг ? Крутясь в цикле ???
3. Также напоминаю, что не следует вызывать виртуальные функции в конструкторах, подробности в рекомендации 49 здесь

Какой эвент? Это про что?

MasterZivЭто и так корректно и реализовано и будет работать. Что еще надо ?

Чтобы не было одновременного доступа

Gluk (Kazan) AkhКакой эвент? Это про что?

Объект синхронизации в Windows

Какой Windows? ;)

Родное CriticalSection(windows), mutex(linux), semafor(linux)?

Gluk (Kazan) AkhКакой Windows? ;)
Родное CriticalSection(windows), mutex(linux), semafor(linux)?

Друх, я не телепат Слово Linux впервые появляется в предыдушем посте треда.
Разумеется, используй то что есть на платформе, зачем извращения с флагами та ?

Я хотел уточнить из какой области эти евенты. Так понял, что понял правельно. :)

Кто его знает, сколько ресурсов требуется на вход в секцию и выход из нее. А, накрайняк, с одним ифом все понятно.

Gluk (Kazan) Akh
Кто его знает, сколько ресурсов требуется на вход в секцию и выход из нее. А, накрайняк, с одним ифом все понятно.

IMHO
Создание потока исполнения не такая частая операция, чтобы на ней экономить время.
В случае Windows критичным ресурсом является сам Event как оббъект ядра, но поскольку операция однократная, его можно уничтожить сразу после использования

В цикле надо будет постоянно входить в выходить из секции, хотя уже рантайме владельцем данных будет только сам цикл. Про эти ресурсы я и говорю.

maXmoно можно же один раз войти и подождать, пока не выкинет.

Базовый класс ничего не знает, у него только каллбак есть который дергать.

И, вообще, предлагаю тему закрыть. У меня уже другая схема. Критические данные ушли в другой класс, который делегирует себя потомку, про которого шла речь.

Так что можно пообсуждать, если вопрос интересует только теоретически.