Здравствуйте, Bug_z, Вы писали:
B_>Есть dll, в ней находится класс B_>
B_>class Base
B_>{
B_> static member1;
B_>};
B_>
B_>и есть exe, в нем B_>
B_>class Derive : public Base
B_>{
B_> static member2;
B_>};
B_>
B_>можно ли утверждать, что member1 создастся раньше чем memeber2 ? B_>Если нет, то как реализовать,чтобы member1 создавался раньше member2. B_>VS 7.1
Насколько я понимаю, если DLL загружается явно (через LoadLibrary()), то конструктор member2 будет вызван раньше конструктора member1. А если DLL загружается неявно (и не отложенно), то вначале будет вызван конструктор member1.
Здравствуйте, Кодт, Вы писали:
К>Не забудь правильно экспортировать класс. Иначе ты получишь два экземпляра переменной Base::member1 — в длл и в экзе.
Что значит правильно? dll грузится неявно, без отложеной загрузки.
B_>>можно ли утверждать, что member1 создастся раньше чем memeber2 ? B_>>Если нет, то как реализовать,чтобы member1 создавался раньше member2.
К>Если member2 как-то использует member1 — то разумеется.
Использует, т.е. в любом случае будет сначала будет member1, потом member2 ?
Здравствуйте, Кодт, Вы писали: К>В случае с VC — написать в объявлении класса К>
К>class YOUR_DLL_API MyClass { ..... }
К>
К>где макрос YOUR_DLL_API в зависимости от того, это Your.dll или всё остальное, принимает значения _declspec(dllexport), _declspec(dllimport)
К>Ну это я говорю так, на всякий случай, — надеюсь что ты в курсе.
Здравствуйте, Bug_z, Вы писали:
B_>И еще инетересно, вызов деструкторов производится в обратном порядке или сначала особождаются ресурсы dll а потом экзе?
если не выгружаешь DLL явно, то сначала освобождаются ресурсы exe, потом dll
Здравствуйте, Bug_z, Вы писали:
B_>Если создание member1, потом member2, то подскажите как обеспечить правилное удаление, сначала member2, потом member1. т.к. member2 использует member1
Вообще-то если возникает вопрос о порядке создания/удаления статических/глобальных объектов, по-моему следует пересмотреть дизайн и применить паттерн "синглтон", перейдя от статических объектов к статическим указателям.
В искустве летать есть один маленький секрет. Секрет этот в том,чтобы бросить себя изо всех сил на землю — и не попасть. Выберете погожий денек и попробуйте сами.
B_>>Если создание member1, потом member2, то подскажите как обеспечить правилное удаление, сначала member2, потом member1. т.к. member2 использует member1
BOP>Вообще-то если возникает вопрос о порядке создания/удаления статических/глобальных объектов, по-моему следует пересмотреть дизайн и применить паттерн "синглтон", перейдя от статических объектов к статическим указателям.
Паттерн синглетон имеет кучу проблем и при линковке в один физический модуль. Сколько возникнет проблем при раскидывании его частей по библиотекам — даже сложно представить.
Здравствуйте, Andrew S, Вы писали:
B_>>>Если создание member1, потом member2, то подскажите как обеспечить правилное удаление, сначала member2, потом member1. т.к. member2 использует member1
BOP>>Вообще-то если возникает вопрос о порядке создания/удаления статических/глобальных объектов, по-моему следует пересмотреть дизайн и применить паттерн "синглтон", перейдя от статических объектов к статическим указателям.
AS>Паттерн синглетон имеет кучу проблем и при линковке в один физический модуль. Сколько возникнет проблем при раскидывании его частей по библиотекам — даже сложно представить
Может уточните, какие проблемы вы имеете в виду. На сколько я понимаю у этого паттерна одна проблема — как и когда убить указатель. Если ввести счетчики то все будет ОК...
В искустве летать есть один маленький секрет. Секрет этот в том,чтобы бросить себя изо всех сил на землю — и не попасть. Выберете погожий денек и попробуйте сами.
B_>>>>Если создание member1, потом member2, то подскажите как обеспечить правилное удаление, сначала member2, потом member1. т.к. member2 использует member1
BOP>>>Вообще-то если возникает вопрос о порядке создания/удаления статических/глобальных объектов, по-моему следует пересмотреть дизайн и применить паттерн "синглтон", перейдя от статических объектов к статическим указателям.
AS>>Паттерн синглетон имеет кучу проблем и при линковке в один физический модуль. Сколько возникнет проблем при раскидывании его частей по библиотекам — даже сложно представить
BOP>Может уточните, какие проблемы вы имеете в виду. На сколько я понимаю у этого паттерна одна проблема — как и когда убить указатель. Если ввести счетчики то все будет ОК...
Вообще то стандартым считаемся регистрация функции убийства при помощи _atexit (явно, непосредственным вызовом, или неявно — как это сделано в синглетоне Майерса).
Здравствуйте, Andrew S, Вы писали:
BOP>>Может уточните, какие проблемы вы имеете в виду. На сколько я понимаю у этого паттерна одна проблема — как и когда убить указатель. Если ввести счетчики то все будет ОК...
AS>Вообще то стандартым считаемся регистрация функции убийства при помощи _atexit (явно, непосредственным вызовом, или неявно — как это сделано в синглетоне Майерса).
У этого способа есть недостаток, когда несколько синглетонов (а статические переменные — это синглетоны ) устанавливают ссылки друг на друга не во время инициализации, а во время исполнения. В результате может возникнуть ситуация, когда некто работает с уже разрушенным объектом.
У подсчёта ссылок есть другой недостаток: "круговая порука", в результате которой можно вообще не дойти до разрушения объектов.
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, Andrew S, Вы писали:
BOP>>>Может уточните, какие проблемы вы имеете в виду. На сколько я понимаю у этого паттерна одна проблема — как и когда убить указатель. Если ввести счетчики то все будет ОК...
AS>>Вообще то стандартым считаемся регистрация функции убийства при помощи _atexit (явно, непосредственным вызовом, или неявно — как это сделано в синглетоне Майерса).
К>У этого способа есть недостаток, когда несколько синглетонов (а статические переменные — это синглетоны ) устанавливают ссылки друг на друга не во время инициализации, а во время исполнения. В результате может возникнуть ситуация, когда некто работает с уже разрушенным объектом.
К>У подсчёта ссылок есть другой недостаток: "круговая порука", в результате которой можно вообще не дойти до разрушения объектов.
В данном случае никакой "круговой поруки" быть не может т.к. мембер базового класса не должен ссылаться на мембер производного
В искустве летать есть один маленький секрет. Секрет этот в том,чтобы бросить себя изо всех сил на землю — и не попасть. Выберете погожий денек и попробуйте сами.
BOP>>>Может уточните, какие проблемы вы имеете в виду. На сколько я понимаю у этого паттерна одна проблема — как и когда убить указатель. Если ввести счетчики то все будет ОК...
AS>>Вообще то стандартым считаемся регистрация функции убийства при помощи _atexit (явно, непосредственным вызовом, или неявно — как это сделано в синглетоне Майерса).
К>У этого способа есть недостаток, когда несколько синглетонов (а статические переменные — это синглетоны ) устанавливают ссылки друг на друга не во время инициализации, а во время исполнения. В результате может возникнуть ситуация, когда некто работает с уже разрушенным объектом.
К>У подсчёта ссылок есть другой недостаток: "круговая порука", в результате которой можно вообще не дойти до разрушения объектов.
Основной недостаток подсчета ссылок — что объект надо явно создавать и убивать. При помощи же списка финализации это делается автоматически.
Вообще, идеальных вещей нет. У каждого паттерна свои недостатки.
Здравствуйте, BOPOH_N, Вы писали:
К>>У подсчёта ссылок есть другой недостаток: "круговая порука", в результате которой можно вообще не дойти до разрушения объектов.
BOP>В данном случае никакой "круговой поруки" быть не может т.к. мембер базового класса не должен ссылаться на мембер производного
Здравствуйте, Кодт, Вы писали:
К>Здравствуйте, BOPOH_N, Вы писали:
К>>>У подсчёта ссылок есть другой недостаток: "круговая порука", в результате которой можно вообще не дойти до разрушения объектов.
BOP>>В данном случае никакой "круговой поруки" быть не может т.к. мембер базового класса не должен ссылаться на мембер производного
К>Кто-то что-то не понял...
Наверное... Я рассматривал конкретный пример
class Base
{
static member1;
};
class Derive : public Base
{
static member2;
};
Где, как я себе это вижу, не может быть перекрестных ссылок между member1 и member2...
В искустве летать есть один маленький секрет. Секрет этот в том,чтобы бросить себя изо всех сил на землю — и не попасть. Выберете погожий денек и попробуйте сами.
Перекуём баги на фичи!
Здравствуйте, Кодт, Вы писали:
В искустве летать есть один маленький секрет. Секрет этот в том,чтобы бросить себя изо всех сил на землю — и не попасть. Выберете погожий денек и попробуйте сами.
) устанавливают ссылки друг на друга не во время инициализации, а во время исполнения. В результате может возникнуть ситуация, когда некто работает с уже разрушенным объектом.