При перекомпиляции сервера перекомпилируется клиент, а что, собственно в этом плохого?

@kravam · Регистрация: 04.06.2008

Author24 — интернет-сервис помощи студентам

Друзья!
Начинаем цикл вопросов про COM- Объекты. Первый вопрос возник по статье Безверхова, вот здесь статья. Вот там такой пример:

C++
1
2
3
4
5
//myobj.cpp - реализация методов объекта сервера
#include "myobj.h"     
void Foo::SetA(int i){a = i;} 
void Foo::SetB(float f){b = f;} 
void Foo::SetAB(int i, float f){a = i; b = f;}

C++
1
2
3
4
5
6
7
8
9
//myobj.h - определение объекта Foo
class Foo { 
      private:     
                   int a;     float b;   
      public:     
                  void SetA(int i);     
                  void SetB(float f);     
                  void SetAB(int i, float f); 
      };

C++
1
2
3
4
5
6
7
//myclient.cpp - реализация кода клиента
#include "myobj.h"     
int main () {
    Foo Cls;   
    Cls.SetA(12); 
    Cls.SetB(13.2);
}

Видите ли вы здесь неудобство, которое при этом возникает? А неудобство-то вот какое - при компиляции сервера нам действительно нужно знать всё про класс - и про его данные и про его методы. А вот при компиляции клиента нас интересуют только методы - данные-то сервера нам недоступны. И если в процессе развития сервера мы, скажем, добавили в класс еще одну, сугубо внутреннюю, переменную или внутренний метод, то понятно, что нам нужно будет перекомпилировать сервер. Но ведь нам также придется и перекомпилировать клиент - файл myobj.h ведь изменился! А вот сам клиент - не изменялся. А перекомпилировать клиент - придётся...

А перекомпилировать клиент - придётся... А чё не так-то?
...Итак, компилим сервер:

Bash
1
g++ -c myobj.cpp

компилим клиент

Bash
1
g++ -c myclient.cpp

Лепим экзешник.

Bash
1
g++ -o myclient myclient.o myobj.o

Всё! Теперь ты хоть ЗАМЕНЯЙСЯ сервер, хоть чё сюда напиши:

C++
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
class Foo { 
      private:     
            
                   int a;     float b;   
      
      public:     
                  void SetA(int i);     
                  
                  void SetB(float f);     
 
                  //Можно эту функцию закомментить
                  //void SetAB(int i, float f); 
            
          //можно добавить функцию:
          void SetB();  
            
      };

Главное хидер не забудь поправить как надо. И всё. И НЕ НАДО перекомпилировать клиент, то есть не надо давать команду

Bash
1
g++ -c myclient.cpp

А то, что тебе придётся всё-таки линковать

Bash
1
g++ -o myclient myclient.o myobj.o

Так извините меня, сервер и клиент находятся в одном экзешнике. Или автор в претензиях, что мы меняя ЧАСТЬ экзешника (сервер) вынуждены менять ВЕСЬ экзешник? (При совместной компиляции те же рассуждения, там так же создаются *.o файлы, просто если мы совместно будем всё это компилить, мы два раза создадим АБСОЛЮТНО одинаковые файлы myclient.o, незачем два раза создавать одно и то же, да и раздельная компиляция прибавит наглядности.)

Я ничё не понимаю. Может кто-то разъяснит мне, что имел ввиду Безверхов, говоря:

А перекомпилировать клиент - придётся...

@vxg · 05.03.2013, 14:30

Сообщение от kravam

к чему относится этот пример

то ли вы меня не поймете то ли я вас. если вы задаете вопрос о COM-объектах, то вы можете менять сервер как угодно - переставлять поля местами, менять их количество, позиции и сигнатуры методов - клиенту это без разницы до тех пор пока интерфейс не изменяется. вы ведь возвращаете клиенту интерфейс.

@kravam · 05.03.2013, 16:28 **[ТС]**

Сообщение от vxg

если вы задаете вопрос о COM-объектах

в том-то и дело, что не о СOM! Понимаете, Безверхов начинает объяснение COM-объектов издалека с языка C++. Так что имеем ввиду, щас речь идёт о C++. То есть имеем чистой воды класс и main, они ещё и не COM-объекты и таковыми после компиляции и не будут, они просто разнесены по разным файлам-сырцам.

@vxg · 06.03.2013, 10:04

Сообщение от kravam

не о СOM

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

@kravam · 06.03.2013, 11:34 **[ТС]**

Ну, положим, первой части вполне хватило бы для ответа на вопрос, а вторая часть это то, чего не может быть

Сообщение от vxg

2 если у нас "обычный" объект который не содержит полей, а состоит из одних чистых виртуальных функций причем их набор и сигнатуры фиксированы, то как бы мы не издевались над его реализацией (над объектом наследником) компиляция клиента нам не нужна - мы всегда работаем с известным интерфейсом. это и есть COM.

И там дальше в статье по-моему речь и идёт об этом.
Не бывает хидера с таким описанием. (если, конечно мы ведём речь о C++ объектах. Ну то есть не выносим объект в отдельную dll). По-любому интерфейс наследника должен быть известен клиенту. Так что одним подключением абстрактного класса никак не обойтись.

Ну, вы наверное имели ввиду, что если мы исхитримся сделать так, то это значит, что мы и сконструировали тот самый настоящий COM-объект, который находится в другом исполняемом модуле и никак иначе.

@vxg · 06.03.2013, 14:33

Сообщение от kravam

то, чего не может быть

чего не может быть? того что где-то живет нечто способное при вызове известной и неизменной функции вернуть указатель на объект класса содержащего одни чистые виртуальные функции (то есть интерфейс)? это вполне может быть. хоть в том же модуле хоть за его пределами. и это называется COM

@kravam · 07.03.2013, 01:24 **[ТС]**

Того не может быть, что:

нас "обычный" объект который не содержит полей, а состоит из одних чистых виртуальных функций причем их набор и сигнатуры фиксированы, то как бы мы не издевались над его реализацией (над объектом наследником) компиляция клиента нам не нужна - мы всегда работаем с известным интерфейсом. это и есть COM.

И чтобы этот объект был в одном исполняемом модуле, (том же экзешнике) вместе с клиентом.

@vxg · 07.03.2013, 08:22

Сообщение от kravam

И чтобы этот объект был в одном исполняемом модуле

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

@kravam · 07.03.2013, 11:34 **[ТС]**

Сообщение от vxg

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

Сказать всё, что угодно можно. Сделайте...

@kravam · 10.03.2013, 03:23 **[ТС]**

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

Не по теме:

Напоминаю, речь идёт исключительно о C++ коде, COM не трогаем. Я поторопился, задав вопрос в этом разделе- ну так значит не смог разобраться, пусть тему перенесут.

Всегда ли?

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

Действительно, возьмём этот код, добавим в сервер функцию-метод (в хидер и в*.cpp)

C++
1
void funktsia () {;}

и добавим её вызов в клиент:

C++
1
w.funktsia ();

скомпилим клиент

Bash
1
g++ -c client.cpp

посмотрим символы, которые в client.o

Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
nm -u client.o
 
         U __Unwind_Resume
         
         //Вот она, наша функция
         U __ZN5world8funktsiaEv
         
         U __ZN5worldC1Ev
         U __ZNSolsEPFRSoS_E
         U __ZNSsD1Ev
         U __ZNSt8ios_base4InitC1Ev
         U __ZNSt8ios_base4InitD1Ev
         U __ZSt4cout
         U __ZSt4endlIcSt11char_traitsIcEERSt13basic_ostreamIT_T0_ES6_
         U __ZStlsISt11char_traitsIcEERSt13basic_ostreamIcT_ES5_PKc
         U __ZStlsIcSt11char_traitsIcESaIcEERSt13basic_ostreamIT_T0_ES7_RKSbIS4
_S5_T1_E
         U ___gxx_personality_v0
         U ___main
         U _atexit

Теперь соберём сервер и посмотрим его нутро:

Bash
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
nm server.o
 
00000000 b .bss
00000000 d .data
00000000 r .eh_frame
00000000 d .gcc_except_table
00000000 r .rdata
00000000 t .text
         U __Unwind_Resume
 
//Вот она, наша функция
0000007a T __ZN5world8funktsiaEv
 
 
00000000 T __ZN5worldC1Ev
00000000 T __ZN5worldC2Ev
         U __ZNSsC1Ev
         U __ZNSsD1Ev
         U __ZNSsaSEPKc
         U ___gxx_personality_v0

И вы знаете, ребята, есть у меня такое ощущение, что линковщик, ища соответствие между символом
__ZN5world8funktsiaEv из client.o ни с чем не перепутает __ZN5world8funktsiaEv из server.o

Почему же линковщик может перепутать поля класса?

На самом деле ответ прост, и он лежит на повержности. Все, кто отписался, его знают. А вот мне пришлось чуток подумать. В server.o генерируется код, который кладёт в первое поле world значение такое-то, а во второе такое-то. А в клиенте вынимаются значения из полей- из первого и второго. Если в хидере поменяются их имена, и клиент не узнает об этом на этапе компиляции, он не узнает этого никогда. Так и будет действовать, как запрограммирован при первой компиляции.

Вернёмся с функциями, с ними всё проще.
В коде они ведут себя как НЕ методы класса- то есть принадлежность к классу абсолютно никак не выявляется. (В объекте даже указателя на них нет. Был бы- не исключалась бы возможность путаницы, как с полями) Выясните размер world- он будет равен 8, по 4 байта накаждое поле string. Просто функция-метод (и конструктор) принимает указатель на объект класса и работает с ним. Все об этом знают, просто написать забыли.

Ну вот и всё, собсно. То есть если пользуетесь для доступа к данным исключительно функциями, можете смело менять хидер и не трогать сырец с main. Всякое несоответствие (если таковое найдётся) между вызовами функций и тем, как они представлены в классе, выявится на этапе линковки. А не выявится, значит экзешник отработает корректно.

@vxg · 11.03.2013, 11:25

Сообщение от kravam

Ну вот и всё, собсно

нет, вы не совсем правы. сейчас приведу пример.

@vxg · 11.03.2013, 11:34

итак, делаем игрушечный интерфейс и игрушечную библиотеку COM.
имеем заголовочный файл в котором есть:
- определение класса my_iface с чистыми виртуальными функциями f1 и f2 - это наш игрушечный интерфейс
- прототип функции create_obj возвращающей указатель на объект класса my_iface - это наша игрушечная библиотека COM (наш аналог функции CoCreateInstance).
собираем DLL в которой есть класс реализующий интерфейс и есть функция возвращающая указатель на реализацию.
подключаем DLL к проекту.
если в заголовочном файле в определении класса поменять местами виртуальные функции f1 и f2, то при вызове obj->f1() мы ничуть не удивившись обнаружим на экране информацию говорящую о том, что реально была вызвана функция f2.

@vxg · 11.03.2013, 11:38

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

Tulosba · 11.03.2013, 11:45

Не по теме:

Сообщение от vxg

что в нормальных классах деструктор является виртуальным

ну если наследники не нужны, это не значит что класс не нормальный.

@vxg · 11.03.2013, 11:48

Не по теме:

Сообщение от Tulosba

ну если наследники не нужны, это не значит что класс не нормальный

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

Tulosba · 11.03.2013, 11:54

Не по теме:

Сообщение от vxg

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

Неумение пользоваться имеющимися классами (в частности попытки наследоваться от тех классов, которые для этого не предназначены) вовсе не значит, что класс написан неправильно. Возьмите хотя бы std::string.
В шарпике есть например sealed, четко говорящий о том, что наследование запрещено. В плюсах же приходится немного углубляться в документацию.

@vxg · 11.03.2013, 12:07

Не по теме:

Сообщение от Tulosba

Неумение

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

@kravam · 11.03.2013, 12:59 **[ТС]**

Сообщение от vxg

если в заголовочном файле в определении класса поменять местами виртуальные функции f1 и f2

Угу, только я разделил для себя:

1)использование абстрактного класса это одна история- ваш пример,
2)неиспользование абстрактного класса- другая история.

Сейчас мы говорим о втором примере. Никаких абстрактных классов! Мне почему-то казалось это очевидным, раз не оговорено обратное

.

Что касается вашего примера, то я вчера долго думал над ним и пришёл к тому же выводу, что и вы. Создал даже тему в разделе C++ потому, что к COM это пока никаким боком. Я и эту-то поторопился в этом разделе создавать.

Программа взаимодействует с классом исключительно через интерфейс. Однажды класс меняется и меняется его хидер. Надо ли перекомпилировать всю программ

вот оттуда моя цитата:

Ага, значит при компиляции мы привязаны к абстрактному классу. Один определённый вывод есть, то есть при измененеии абстрактного класса, надо перекомпилировать и main.o

Ну опять же в названии темы нет "абстрактный класс", моя вина. Но я оговариваю всё подробно в первом же посте.

@vxg · 11.03.2013, 13:13

а с чего вообще сыр-бор кроме интереса "а что же внутри". что внутри выяснили. какой еще вопрос то?

@kravam · 11.03.2013, 13:16 **[ТС]**

Вопрос "что внутри" это следствие вопроса "надо ли перекомпилировать", а так всё, никакого больше.

Новые блоги и статьи Все статьи Все блоги /
MVC фреймворк в PHP Jason-Webb 19.04.2025 Архитектурный паттерн Model-View-Controller (MVC) – это не просто модный термин из мира веб-разработки. Для PHP-программистов это фундаментальный подход к организации кода, который радикально меняет. . .	Dictionary Comprehensions в Python py-thonny 19.04.2025 Python славится своей выразительностью и лаконичностью, что позволяет писать чистый и понятный код. Среди множества синтаксических конструкций языка особое место занимают словарные включения. . .	Шаблоны и протоколы для создания устойчивых микросервисов ArchitectMsa 19.04.2025 Микросервисы — архитектурный подход, разбивающий сложные приложения на небольшие, независимые компоненты. Вместо монолитного гиганта, система превращается в созвездие небольших взаимодействующих. . .	Изменяемые и неизменяемые типы в Python py-thonny 19.04.2025 Python славится своей гибкостью и интуитивной понятностью, а одна из главных его особенностей — это система типов данных. В этом языке все, включая числа, строки, функции и даже классы, является. . .	Интеграция Hangfire с RabbitMQ в проектах C#.NET stackOverflow 18.04.2025 Разработка современных . NET-приложений часто требует выполнения задач "за кулисами". Это может быть отправка email-уведомлений, генерация отчётов, обработка загруженных файлов или синхронизация. . .
Построение эффективных запросов в микросервисной архитектуре: Стратегии и практики ArchitectMsa 18.04.2025 Микросервисная архитектура принесла с собой много преимуществ — возможность независимого масштабирования сервисов, технологическую гибкость и четкое разграничение ответственности. Но как часто бывает. . .	Префабы в Unity: Использование, хранение, управление GameUnited 18.04.2025 Префабы — один из краеугольных элементов разработки игр в Unity, представляющий собой шаблоны объектов, которые можно многократно использовать в различных сценах. Они позволяют создавать составные. . .	RabbitMQ как шина данных в интеграционных решениях на C# (с MassTransit) stackOverflow 18.04.2025 Современный бизнес опирается на множество специализированных программных систем, каждая из которых заточена под решение конкретных задач. CRM управляет отношениями с клиентами, ERP контролирует. . .	Типы в TypeScript run.dev 18.04.2025 TypeScript представляет собой мощное расширение JavaScript, которое добавляет статическую типизацию в этот динамический язык. В JavaScript, где переменная может свободно менять тип в процессе. . .	Погружение в Kafka: Концепции и примеры на C# с ASP.NET Core stackOverflow 18.04.2025 Apache Kafka изменила подход к обработке данных в распределенных системах. Эта платформа потоковой передачи данных выходит далеко за рамки обычной шины сообщений, предлагая мощные возможности,. . .

@vxg Модератор 3402 / 2173 / 353 Регистрация: 13.01.2012 Сообщений: 8,430
	05.03.2013, 14:30
	Сообщение от kravam к чему относится этот пример то ли вы меня не поймете то ли я вас. если вы задаете вопрос о COM-объектах, то вы можете менять сервер как угодно - переставлять поля местами, менять их количество, позиции и сигнатуры методов - клиенту это без разницы до тех пор пока интерфейс не изменяется. вы ведь возвращаете клиенту интерфейс. 0

@kravam быдлокодер 1724 / 911 / 106 Регистрация: 04.06.2008 Сообщений: 5,695
	05.03.2013, 16:28 [ТС]
	Сообщение от vxg если вы задаете вопрос о COM-объектах в том-то и дело, что не о СOM! Понимаете, Безверхов начинает объяснение COM-объектов издалека с языка C++. Так что имеем ввиду, щас речь идёт о C++. То есть имеем чистой воды класс и main, они ещё и не COM-объекты и таковыми после компиляции и не будут, они просто разнесены по разным файлам-сырцам. 0

@vxg Модератор 3402 / 2173 / 353 Регистрация: 13.01.2012 Сообщений: 8,430
	06.03.2013, 10:04
	Сообщение от kravam не о СOM 1 если у нас обычный объект, то необходимость компиляции при внесении изменений в определение класса очевидна: изменение набора полей или обработчиков, их типов или сигнатур должно быть учтено на клиенте. в противном случае у него просто будет неактуальные адреса данных или точки входа, неверные размеры данных или процедуры передачи аргументов. 2 если у нас "обычный" объект который не содержит полей, а состоит из одних чистых виртуальных функций причем их набор и сигнатуры фиксированы, то как бы мы не издевались над его реализацией (над объектом наследником) компиляция клиента нам не нужна - мы всегда работаем с известным интерфейсом. это и есть COM. 1

@kravam быдлокодер 1724 / 911 / 106 Регистрация: 04.06.2008 Сообщений: 5,695
	06.03.2013, 11:34 [ТС]
	Ну, положим, первой части вполне хватило бы для ответа на вопрос, а вторая часть это то, чего не может быть Сообщение от vxg 2 если у нас "обычный" объект который не содержит полей, а состоит из одних чистых виртуальных функций причем их набор и сигнатуры фиксированы, то как бы мы не издевались над его реализацией (над объектом наследником) компиляция клиента нам не нужна - мы всегда работаем с известным интерфейсом. это и есть COM. И там дальше в статье по-моему речь и идёт об этом. Не бывает хидера с таким описанием. (если, конечно мы ведём речь о C++ объектах. Ну то есть не выносим объект в отдельную dll). По-любому интерфейс наследника должен быть известен клиенту. Так что одним подключением абстрактного класса никак не обойтись. Ну, вы наверное имели ввиду, что если мы исхитримся сделать так, то это значит, что мы и сконструировали тот самый настоящий COM-объект, который находится в другом исполняемом модуле и никак иначе. 0

@vxg Модератор 3402 / 2173 / 353 Регистрация: 13.01.2012 Сообщений: 8,430
	06.03.2013, 14:33
	Сообщение от kravam то, чего не может быть чего не может быть? того что где-то живет нечто способное при вызове известной и неизменной функции вернуть указатель на объект класса содержащего одни чистые виртуальные функции (то есть интерфейс)? это вполне может быть. хоть в том же модуле хоть за его пределами. и это называется COM 0

@kravam быдлокодер 1724 / 911 / 106 Регистрация: 04.06.2008 Сообщений: 5,695
	07.03.2013, 01:24 [ТС]
	Того не может быть, что: нас "обычный" объект который не содержит полей, а состоит из одних чистых виртуальных функций причем их набор и сигнатуры фиксированы, то как бы мы не издевались над его реализацией (над объектом наследником) компиляция клиента нам не нужна - мы всегда работаем с известным интерфейсом. это и есть COM. И чтобы этот объект был в одном исполняемом модуле, (том же экзешнике) вместе с клиентом. 0

@vxg Модератор 3402 / 2173 / 353 Регистрация: 13.01.2012 Сообщений: 8,430
	07.03.2013, 08:22
	Сообщение от kravam И чтобы этот объект был в одном исполняемом модуле как раз сделать так что бы он был в одном исполняемом модуле человек может хоть на коленке. а вот сделать что бы он был в другом приложении - это заморочки с заглушками и маршаллингом. тоже конечно можно сделать свой педальный маршаллинг, но труд адов. 0

@kravam быдлокодер 1724 / 911 / 106 Регистрация: 04.06.2008 Сообщений: 5,695
	07.03.2013, 11:34 [ТС]
	Сообщение от vxg как раз сделать так что бы он был в одном исполняемом модуле человек может хоть на коленке Сказать всё, что угодно можно. Сделайте... 0

@vxg Модератор 3402 / 2173 / 353 Регистрация: 13.01.2012 Сообщений: 8,430
	11.03.2013, 11:25
	Сообщение от kravam Ну вот и всё, собсно нет, вы не совсем правы. сейчас приведу пример. 0

@vxg Модератор 3402 / 2173 / 353 Регистрация: 13.01.2012 Сообщений: 8,430
	11.03.2013, 11:38
	с вызовами функций не являющимися виртуальными таких эффектов не будет, но учитывая тот факт, что в нормальных классах деструктор является виртуальным перекомпиляция нужна всегда. 0

Tulosba
	11.03.2013, 11:45
	Не по теме: Сообщение от vxg что в нормальных классах деструктор является виртуальным ну если наследники не нужны, это не значит что класс не нормальный. 0

@vxg
	11.03.2013, 11:48
	Не по теме: Сообщение от Tulosba ну если наследники не нужны, это не значит что класс не нормальный его ненормальность проявится когда кому-нибудь взбредет от него наследовать 0

Tulosba
	11.03.2013, 11:54
	Не по теме: Сообщение от vxg его ненормальность проявится когда кому-нибудь взбредет от него наследовать Неумение пользоваться имеющимися классами (в частности попытки наследоваться от тех классов, которые для этого не предназначены) вовсе не значит, что класс написан неправильно. Возьмите хотя бы std::string. В шарпике есть например sealed, четко говорящий о том, что наследование запрещено. В плюсах же приходится немного углубляться в документацию. 0

@vxg
	11.03.2013, 12:07
	Не по теме: Сообщение от Tulosba Неумение безусловно все из-за него, родимого. никто не говорил "неправильно". говорил "ненормально" в плане отсутствия у проектировщика класса желания исключить потенциальную возможность утечки памяти или ошибки доступа. в любом случае данная дискуссия не относится к вопросу, имеет черты религиозной и на мой взгляд продолжать ее в данной теме нежелательно. 1

@kravam быдлокодер 1724 / 911 / 106 Регистрация: 04.06.2008 Сообщений: 5,695
	11.03.2013, 12:59 [ТС]
	Сообщение от vxg если в заголовочном файле в определении класса поменять местами виртуальные функции f1 и f2 Угу, только я разделил для себя: 1)использование абстрактного класса это одна история- ваш пример, 2)неиспользование абстрактного класса- другая история. Сейчас мы говорим о втором примере. Никаких абстрактных классов! Мне почему-то казалось это очевидным, раз не оговорено обратное . Что касается вашего примера, то я вчера долго думал над ним и пришёл к тому же выводу, что и вы. Создал даже тему в разделе C++ потому, что к COM это пока никаким боком. Я и эту-то поторопился в этом разделе создавать. Программа взаимодействует с классом исключительно через интерфейс. Однажды класс меняется и меняется его хидер. Надо ли перекомпилировать всю программ вот оттуда моя цитата: Ага, значит при компиляции мы привязаны к абстрактному классу. Один определённый вывод есть, то есть при измененеии абстрактного класса, надо перекомпилировать и main.o Ну опять же в названии темы нет "абстрактный класс", моя вина. Но я оговариваю всё подробно в первом же посте. 0

@vxg Модератор 3402 / 2173 / 353 Регистрация: 13.01.2012 Сообщений: 8,430
	11.03.2013, 13:13
	а с чего вообще сыр-бор кроме интереса "а что же внутри". что внутри выяснили. какой еще вопрос то? 0

@kravam быдлокодер 1724 / 911 / 106 Регистрация: 04.06.2008 Сообщений: 5,695
	11.03.2013, 13:16 [ТС]
	Вопрос "что внутри" это следствие вопроса "надо ли перекомпилировать", а так всё, никакого больше. 0