Re[10]: Массив объектов и распределение памяти.
От: Pavel Dvorkin Россия  
Дата: 23.12.13 15:25
Оценка:
Здравствуйте, Erop, Вы писали:


PD>>Этот нет (Visual Studio). Для экспорта нужно __declspec(dllexport). Если хочешь сказать , что __declspec(dllexport) может быть у наследников, которые экспортируются — верно, но поскольку сам тип IDeletable за пределами DLL не виден


E>В каком смысле "не виден"?


В прямом. Только те классы, которые имеют в описании __declspec(dllexport), могут использоваться за пределами DLL, точно так же, как и просто C-функции из DLL можно вызывать за ее пределами только если они экспортируются. А экспорт класса — это, грубо говоря, экспорт его методов.

E>Попробуй сделать такую dll, возьми её хедер, отнаследуйся в exe, и погляди виден или нет...


Ну и ну...

Каким образом EXE получит доступ к коду базового класса, если его реализация в DLL и не экспортируется ? Он вообще за пределами DLL не виден никому.

Или у тебя весь код в хедере будет ? Тогда просто в EXE будет свой класс, DLL ни при чем.

http://msdn.microsoft.com/ru-ru/library/a90k134d(v=vs.90).aspx

Чтобы экспортировать все общие члены данных и функции-члены в класс, ключевое слово должно стоять слева от имени класса:

class __declspec(dllexport) CExampleExport : public CObject
{ ... class definition ... };
With best regards
Pavel Dvorkin
Re[5]: Массив объектов и распределение памяти.
От: Pavel Dvorkin Россия  
Дата: 23.12.13 15:39
Оценка:
Здравствуйте, Alexander G, Вы писали:


AG>Есть final в С++11. И sealed в MSVС с тем же смыслом.


В VS2013 можно писать и то, и другое. sealed — насколько я понимаю, для совместимости с MC++

struct Base1 final/*sealed*/
{ };

struct Derived1 : Base1 { };

error C3246: 'Derived1' : cannot inherit from 'Base1' as it has been declared as 'final'
With best regards
Pavel Dvorkin
Re[11]: Массив объектов и распределение памяти.
От: Erop Россия  
Дата: 23.12.13 17:36
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>В прямом. Только те классы, которые имеют в описании __declspec(dllexport), могут использоваться за пределами DLL, точно так же, как и просто C-функции из DLL можно вызывать за ее пределами только если они экспортируются. А экспорт класса — это, грубо говоря, экспорт его методов.


Ну, то есть ты утверждаешь, что какой-нибудь
struct Data {
    int F1;
    int F2;
    double D3;
};
надо экспортировать? Про хедер-онли библиотеки никогда не слышал?..

E>>Попробуй сделать такую dll, возьми её хедер, отнаследуйся в exe, и погляди виден или нет...


PD>Ну и ну...

Ты не "ну-ну", а пример неработающий приведи...

PD>Каким образом EXE получит доступ к коду базового класса, если его реализация в DLL и не экспортируется ? Он вообще за пределами DLL не виден никому.

А зачем тут доступ к какому-то коду?
Автогенерённые методы сгенеряться ещё раз для EXE, независимо, так же как и для inline-функции, например. А виртуальным вызовам пофигу, экспортированы реализации или нет...

PD>Или у тебя весь код в хедере будет ? Тогда просто в EXE будет свой класс, DLL ни при чем.

Почему не при чём? В DLL может быть, например, полиморфный код, которому exe будет отдавать наследников...
Я же конкретный пример конкретного класса привёл?


PD>Чтобы экспортировать все общие члены данных и функции-члены в класс, ключевое слово должно стоять слева от имени класса:


PD>class __declspec(dllexport) CExampleExport : public CObject

PD>{ ... class definition ... };

Это ты про классы, которые должны показать наружу свои потроха (адреса методов и статических переменных). При чём тут выбрасывание виртуальности оптимизатором?

Вот у тебя есть, например, код контейнера, который хранит в себе IDeletable*, и удаляет их правильно. Полиморфный код с IDeletable, тем не менее, не может быть девиртуализоан, так как другие наследники могут прийти их других DLL, например из плагинов...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[12]: Массив объектов и распределение памяти.
От: Pavel Dvorkin Россия  
Дата: 24.12.13 02:44
Оценка:
Здравствуйте, Erop, Вы писали:

PD>>В прямом. Только те классы, которые имеют в описании __declspec(dllexport), могут использоваться за пределами DLL, точно так же, как и просто C-функции из DLL можно вызывать за ее пределами только если они экспортируются. А экспорт класса — это, грубо говоря, экспорт его методов.


E>Ну, то есть ты утверждаешь, что какой-нибудь
struct Data {
E>    int F1;
E>    int F2;
E>    double D3;
E>};
надо экспортировать? Про хедер-онли библиотеки никогда не слышал?..


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

E>>>Попробуй сделать такую dll, возьми её хедер, отнаследуйся в exe, и погляди виден или нет...


PD>>Ну и ну...

E>Ты не "ну-ну", а пример неработающий приведи...

Пожалуйста


// DLL
class A {
public:
 void myprint() {
 printf("This function code now is in DLL");
}
}


Вставь этот класс в DLL. Он не экспортируется из нее.

А теперь любым способом используй этот класс в EXE при том, что код myprint должен быть в DLL. Для начала попробуй описать переменную этого класса.
With best regards
Pavel Dvorkin
Re[13]: Массив объектов и распределение памяти.
От: Erop Россия  
Дата: 24.12.13 02:56
Оценка: +1
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Батенька, хедер-онли библиотеки реализуются там, где хедер. То есть у тебя просто получится реализация класса в EXE, без участия DLL

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

Так?

Вот и говорю тебе, что хедер-онли база, с которой работает полиморфный код, вполне может разжиться наследниками из плагина, другой DLL, или, наоборот, прилинковавшего нашу DLL EXEшника...


PD>// DLL

PD>class A {
PD>public:
PD> void myprint() {
PD> printf("This function code now is in DLL");
PD>}
PD>}
PD>[/ccode]

PD>Вставь этот класс в DLL. Он не экспортируется из нее.


PD>А теперь любым способом используй этот класс в EXE при том, что код myprint должен быть в DLL. Для начала попробуй описать переменную этого класса.


1) Этот класс не имеет виртуальности, и к обсуждаемо проблеме отношения не имеет.
2) Если ты поместишь этот код в A.h, и заюзаешь класс А и из DLL и из EXE, то всё влшебным образом заработает...
Да, реализаций A::myprint в программе окажется две. Одна в DLL, а другая в EXE, это если A::myprint ни там ни там не встроится, конечно. Скорее всего вообще реализаций в явном виде ни там ни там не будет, а будут результаты инлайн-подстановок...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[14]: Массив объектов и распределение памяти.
От: Pavel Dvorkin Россия  
Дата: 24.12.13 05:45
Оценка:
Здравствуйте, Erop, Вы писали:


PD>>Вставь этот класс в DLL. Он не экспортируется из нее.


PD>>А теперь любым способом используй этот класс в EXE при том, что код myprint должен быть в DLL. Для начала попробуй описать переменную этого класса.


E>1) Этот класс не имеет виртуальности, и к обсуждаемо проблеме отношения не имеет.


Да ну ? Кто мне привел пример со struct Data (я его повторил ниже) ?
Впрочем, если очень хочешь, добавь virtual.

E>2) Если ты поместишь этот код в A.h, и заюзаешь класс А и из DLL и из EXE, то всё влшебным образом заработает...

E>Да, реализаций A::myprint в программе окажется две. Одна в DLL, а другая в EXE, это если A::myprint ни там ни там не встроится, конечно. Скорее всего вообще реализаций в явном виде ни там ни там не будет, а будут результаты инлайн-подстановок...

Ты же утверждал, что можно добраться к классу из DLL, даже если он не экспортируется. Вот и покажи, как к нему добраться. А создать новый класс в EXE, не имеющий никакого отношения к DLL — большого ума не надо, но к делу не относится.

E>Ну, то есть ты утверждаешь, что какой-нибудь

E>struct Data {
E> int F1;
E> int F2;
E> double D3;
E>};

E>надо экспортировать?


Так вот — таки надо, если хочешь иметь его реализацию в DLL. А если хочешь иметь ее в EXE — бога ради, но тогда про DLL и говорить незачем.

На этом и прощаюсь. Если покажешь пример, как добраться к моему классу A, реализованному в DLL из EXE — продолжим обсуждение, а иначе хватит.
With best regards
Pavel Dvorkin
Re[15]: Массив объектов и распределение памяти.
От: Erop Россия  
Дата: 24.12.13 08:19
Оценка: -1
Здравствуйте, Pavel Dvorkin, Вы писали:


PD>Ты же утверждал, что можно добраться к классу из DLL, даже если он не экспортируется. Вот и покажи, как к нему добраться. А создать новый класс в EXE, не имеющий никакого отношения к DLL — большого ума не надо, но к делу не относится.


Что значит "новый" или "старый"? То, что некоторые inline и виртуальные методы класса получают по две реализации, никак не делает это ДВУМЯ классами же...

E>>Ну, то есть ты утверждаешь, что какой-нибудь

E>>struct Data {
E>> int F1;
E>> int F2;
E>> double D3;
E>>};

E>>надо экспортировать?


PD>Так вот — таки надо, если хочешь иметь его реализацию в DLL. А если хочешь иметь ее в EXE — бога ради, но тогда про DLL и говорить незачем.


Ну вот представь себе, что в каком-то API такая вот структура используется как параметр ЭКСПОРТИРУЕМОЙ функции. Надо ли экспортировать САМУ структуру?..
Скажем реализация WIN32API для нескольких компиляторов как бы намекает нам, что необязательно...

PD>На этом и прощаюсь. Если покажешь пример, как добраться к моему классу A, реализованному в DLL из EXE — продолжим обсуждение, а иначе хватит.

Ну то есть ты признал, что в современном С/С++ в случае существования динамических библиотек даже на этапе окончания линковки нет ВСЕЙ информации о возможных наследниках, как минимум полиморфных классов, и, таким образом, на этапе линковки виртуальность нельзя исключить даже теоретически?...

Напоминаю, что я возражал именно против этого тезиса. Так что давай либо признавай, что нельзя, либо расскажи, как это сделать в случае IDeletable, реальные наследники которого попадают в нашу прогу их плагинов...
Ну и ещё можешь, конечно просто слиться по-тихому
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[16]: Массив объектов и распределение памяти.
От: Pavel Dvorkin Россия  
Дата: 24.12.13 13:45
Оценка: :)
Здравствуйте, Erop, Вы писали:

Поскольку ответа нет, дискуссию закончил. Только маленькое замечание

E>Что значит "новый" или "старый"? То, что некоторые inline и виртуальные методы класса получают по две реализации, никак не делает это ДВУМЯ классами же...


Чудненько. При том, что код некоторого виртуального метода f в EXE и DLL может вполне не совпадать (а с чего они обязаны совпадать, если DLL писал Петя, а EXE Вася , и Вася с Петей договорились об именах классов, полей, методов и параметров , но не о реализации этих методов), по твоему утверждению, это тем не менее один класс, а не два. Все, приплыли.
With best regards
Pavel Dvorkin
Re[17]: Массив объектов и распределение памяти.
От: Erop Россия  
Дата: 24.12.13 14:05
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Поскольку ответа нет, дискуссию закончил. Только маленькое замечание

Какого ответа? Почему хедер-онли полиморфную базу не обязательно экспортировать
Я думаю, что ты сам постепенно поймёшь, почему и зачем это так..

PD>Чудненько. При том, что код некоторого виртуального метода f в EXE и DLL может вполне не совпадать (а с чего они обязаны совпадать, если DLL писал Петя, а EXE Вася , и Вася с Петей договорились об именах классов, полей, методов и параметров , но не о реализации этих методов), по твоему утверждению, это тем не менее один класс, а не два. Все, приплыли.


В С для этих целей давно уже придумали хедеры. Открой их для себя, что ли...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[18]: Массив объектов и распределение памяти.
От: Pavel Dvorkin Россия  
Дата: 24.12.13 14:23
Оценка:
Здравствуйте, Erop, Вы писали:

PD>>Чудненько. При том, что код некоторого виртуального метода f в EXE и DLL может вполне не совпадать (а с чего они обязаны совпадать, если DLL писал Петя, а EXE Вася , и Вася с Петей договорились об именах классов, полей, методов и параметров , но не о реализации этих методов), по твоему утверждению, это тем не менее один класс, а не два. Все, приплыли.


E>В С для этих целей давно уже придумали хедеры. Открой их для себя, что ли...


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

Ладно, все, хватит, на таком уровне понимания говорить больше не о чем.
With best regards
Pavel Dvorkin
Re[19]: Массив объектов и распределение памяти.
От: Erop Россия  
Дата: 24.12.13 14:35
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

E>>В С для этих целей давно уже придумали хедеры. Открой их для себя, что ли...


PD>Прелесть, да и только. OK. Вася и Петя оба использовали некий хедер. Изначально этот файл Вася взял у Пети, только вот Вася взял да и изменил код одного из методов, который в этом самом хедере, а Петю не проинформировал об этом. Потом Вася отдал DLL Пете. В DLL есть класс, в EXE есть класс, реализации функции разные, но это все равно один класс, а не два разных ...


А думаешь экспорт метода что-то улучшит?..
Да совместимость через хедеры -- она такая...

PD>Ладно, все, хватит, на таком уровне понимания говорить больше не о чем.

Ну бывает. Я, честно говоря думал, что методологию использования хедеров ты уж как-то осилил...

Я верно понимаю, что от защиты своего первоначального ошибочного тезиса о возможности выкинуть виртуализацию на завершающей стадии линкера, ты уе отказался?..
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Re[20]: Массив объектов и распределение памяти.
От: Pavel Dvorkin Россия  
Дата: 24.12.13 14:56
Оценка:
Здравствуйте, Erop, Вы писали:

E>Я верно понимаю, что от защиты своего первоначального ошибочного тезиса о возможности выкинуть виртуализацию на завершающей стадии линкера, ты уе отказался?..


http://rsdn.ru/forum/cpp/5406112.1
Автор: niXman
Дата: 22.12.13


Link-Time Optimization optimizes across object file (and static library) boundaries, available since GCC 4.5
jury-rigged version is mega-compilation
really only started working properly in GCC 4.6.2
de-virtualization is a brand new optimization that reduces the overhead of indirect function calls, specifically virtual functions in C++
With best regards
Pavel Dvorkin
Re[21]: Массив объектов и распределение памяти.
От: Erop Россия  
Дата: 24.12.13 17:22
Оценка:
Здравствуйте, Pavel Dvorkin, Вы писали:

E>>Я верно понимаю, что от защиты своего первоначального ошибочного тезиса о возможности выкинуть виртуализацию на завершающей стадии линкера, ты уе отказался?..


PD>http://rsdn.ru/forum/cpp/5406112.1
Автор: niXman
Дата: 22.12.13


PD>Link-Time Optimization optimizes across object file (and static library) boundaries, available since GCC 4.5

PD>jury-rigged version is mega-compilation
PD>really only started working properly in GCC 4.6.2
PD>de-virtualization is a brand new optimization that reduces the overhead of indirect function calls, specifically virtual functions in C++

Это другой, довольно таки частный случай. Речь идёт о том, что когда у тебя есть какой-то конечный код с MDT, то ты там можешь, теоретически, а иногда и практически, подставить все виртуальные функции явно. Так как именно невозможность инлайнинга является одним из источников неэффиктивности виртуальных вызовов, то это довольно таки эффективный инструмент. Но он работает в иную сторону, чем ты говорил. Он позволяет перенести в CT часть динамического полиморфизма, но, тем не менее, не позволяет совсем его искоренить. То есть, если у тебя есть какой-то полиморфный код, то ты его, конечно, можешь подставить весь в какой-то конкретный контекст, с какими-то конкретными MDT, но, это всё равно не позволяет тебе выкинуть полиморфную версию кода...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.