«Непроверенные» утверждения / утверждения:
Объекты C ++ имеют vtables.Структуры в стиле C - это просто переменные и значения.Поэтому структуры в стиле C могут передаваться вокруг процессов, а объекты C ++ не могут быть.
Это утверждение частично верно, но приводится в заблуждение.
Не все объекты C ++иметь vtables (Технически стандарты C ++ вообще не требуют vtables, хотя это распространенная техника реализации, используемая для поддержки диспетчеризации виртуальных функций, поскольку она предлагает различные преимущества).
Если вы посмотрите , этоТАК вопрос и различные ответы вы найдете обсуждение агрегатных и POD-типов в C ++.Суть в том, что определения развивались между стандартами C ++ (как отражено в различных ответах на этот вопрос).В C ++ 11 понятие типов POD было изменено и фактически заменено понятиями тривиальных типов и типов стандартной компоновки.
Типы POD (до C ++ 11) и типами стандартной компоновки (C +)+11 и позже) можно поменять местами между C ++ и C (т. Е. Передать из кода, написанного на одном языке, в код, написанный на другом, поскольку компоновка памяти совместима).
Это правда, что C ++ объекты с любымвиртуальные функции относятся к числу тех, которые нельзя взаимозаменять с C. Обычно указатели не могут быть скопированы, что препятствует использованию (большей части) стандартных контейнеров C ++.
Со структурами в стиле C мы можем встраиватьтакая информация, как размер структуры, так что обе стороны знают, чего ожидать и что отправлять, но для объектов C ++ это невозможно, поскольку «размер таблицы может варьироваться».
Это утверждениеимеет значение false, поскольку существуют типы, у которых нет vtable, и типы, которые можно взаимозаменять между C ++ и C.
Если мы изменим компиляторы, тогдаэто еще хуже.У нас было бы еще больше перестановок для случая объектов C ++.
Опять же, пока типы выбираются правильно в коде C ++, их можно обменять с C.
Это утверждение - где оно верно для C, взаимодействующего с C ++ - также верно для C. Размер типов C формально определяется реализацией, определенной в C, так же, как и в C ++.Такие типы, как int, long, float, double, не обязательно имеют одинаковый размер с разными компиляторами.Существуют компиляторы с настройками, которые изменяют размер некоторых или всех основных типов (например, компиляторы, которые имеют различные параметры с плавающей запятой, компиляторы, которые имеют настройки, влияющие на то, является ли int 16 или 32-битным и т. Д.).
struct типы в C также могут иметь заполнение между членами, и заполнение может варьироваться в зависимости от компиляторов C.У ряда компиляторов есть опция компиляции, которая влияет на заполнение, которое влияет на размер struct типов.Это может привести к несовместимости макета для того же типа struct в C.
Так что же здесь происходит?
Межпроцессное взаимодействие, вероятно, было разработано сПредположение, что оно всегда будет между кодом C, созданным с помощью одинаковых (или совместимых) компиляторов.Механизм IPC, вероятно, довольно прост: например, один процесс сжимает определенный объем данных в указанной ячейке памяти по каналу, а получатель копирует данные, полученные на другом конце этого канала, в эквивалентную структуру данных.
Предполагается, что данные могут быть напрямую скопированы таким образом.Это зависит от совместимости макетов типов данных в обеих программах.
Проблема заключается в том, что, поскольку механизм IPC был разработан с предположением о совместимости компиляторов C, теперь вам говорят, что это из-за преимуществC над C ++ (или другими языками).Это не.Это артефакт того, как проводится IPC.
Подход IPC, вероятно, весьма ограничен, но ваш код C ++ сможет отправлять и получать данные с помощью механизма IPC, если вы упаковываете данные в соответствующие типы (например, стандартное расположение) в коде C ++.И не имеет значения, был ли другой процесс написан на C или C ++.В C ++ может потребоваться больше работы (например, упаковать данные из класса C ++ в структуру стандартного макета и сдать эту структуру в другой процесс - или наоборот при получении данных), но это, безусловно, возможно.
Вынезависимо от того, нужно ли будет использовать совместимые компиляторы.
И это предполагает, что вы не можете изменить средства межпроцессного взаимодействия (например, разработать протокол для обмена данными между процессами, а не слепо копировать данные из области памяти вниз по линиидругому процессу, и процесс получения затем копирует данные обратно в совместимую структуру данных).Существуют способы выполнения IPC, которые лучше поддерживали бы ряд языков программирования, если это необходимо, хотя и с различными компромиссами (например, пропускная способность для связи, код для перевода данных, чтобы их можно было отправлять, и код для получения и поворота данных).обратно в структуры данных).