Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Sm0ke, Вы писали:

S>>Вы можете ответить мол конструктор по умолчанию сгенерирован компилятором

V>Верно.


S>>И что? Без вирт метода тоже можно обращаться к конструктору по умолчанию в агрегатной структуре.

V>В случае виртуальных методов необходимо ссылаться на единственный vtable в автогенерённых в каждом модуле конструкторах, иначе dynamic_cast может перестать работать.

V>Наверное, при экспорте такой структуры необходимо так же материализовать и экспортировать символ автосгенерённого дефолтного конструктора.
V>(или экспортировать его vtable)

V>Ты хочешь добавить то допущение, что для случая структурной инициализации классов/структур с виртуальныи методами объект предварительно инициализируется автосгенерённым конструктором по-умолчанию (если он доступен, иначе структурная инициализация невозможна, ес-но)?

V>Далее рассуждения вслух (могу ошибаться).

V>Если тип импортируется, тогда поля могут быть проиницилизированы дважды — в умолчательном конструкторе и в целевой структурной инициализации.

V>Однако, инициализируемые поля могут представлять из себя нетривиальные типы и/или содержать новомодную дефолотную инициализацию. При перезаписи таких полей должны будут уже вызываться не конструкторы, а operator=, доступность которого может не совпадать с доступностью конструкторов.

V>Т.е., вместо operator= надо "честно" повторно инициализировать нетривиальное поле через парный вызов деструктора/конструктора — уже выглядит как антипаттерн. ))
V>В случае побочных эффектов в конструкторах/деструкторах получим потенциальное нарушение семантики программы.

Компилятор может сгенерировать скрытый метод для инициализации только vtable, чтобы вызывать его (или инлайнить) при структурной инициализации. Когда нет явных конструкторов, конечно.

Здравствуйте, vdimas, Вы писали:

V>Здравствуйте, Sm0ke, Вы писали:

S>>Вы можете ответить мол конструктор по умолчанию сгенерирован компилятором

V>Верно.


S>>И что? Без вирт метода тоже можно обращаться к конструктору по умолчанию в агрегатной структуре.

V>В случае виртуальных методов необходимо ссылаться на единственный vtable в автогенерённых в каждом модуле конструкторах, иначе dynamic_cast может перестать работать.

Это же задача линкера, в любом случае. Раз он справляется с этим при наличии конструкторов — думаю не трудно сделать чтобы это было так и без.

V>Наверное, при экспорте такой структуры необходимо так же материализовать и экспортировать символ автосгенерённого дефолтного конструктора.
V>(или экспортировать его vtable)

V>Ты хочешь добавить то допущение, что для случая структурной инициализации классов/структур с виртуальныи методами объект предварительно инициализируется автосгенерённым конструктором по-умолчанию (если он доступен, иначе структурная инициализация невозможна, ес-но)?

V>Далее рассуждения вслух (могу ошибаться).

V>Если тип импортируется, тогда поля могут быть проиницилизированы дважды — в умолчательном конструкторе и в целевой структурной инициализации.

V>Однако, инициализируемые поля могут представлять из себя нетривиальные типы и/или содержать новомодную дефолотную инициализацию. При перезаписи таких полей должны будут уже вызываться не конструкторы, а operator=, доступность которого может не совпадать с доступностью конструкторов.

V>Т.е., вместо operator= надо "честно" повторно инициализировать нетривиальное поле через парный вызов деструктора/конструктора — уже выглядит как антипаттерн. ))
V>В случае побочных эффектов в конструкторах/деструкторах получим потенциальное нарушение семантики программы.

Компилятор может сгенерировать скрытый метод для инициализации только vtable, чтобы вызывать его (или инлайнить) при структурной инициализации. Когда нет явных конструкторов, конечно.