Объединение больших программ на C и C ++

1. да, но завернутый как объяснено здесь: Сочетание C ++ и C — как работает #ifdef __cplusplus?
2. не требуется, если они находятся в заголовочном файле. Если это не так, то вам нужно предварительное объявление extern в ваших файлах C ++, если это необходимо, и да с extern «C»
3. Это не всегда возможно, потому что классы и некоторые типичные для C ++ вещи просто не работают в C. Но если код C ++ действительно просто C, он тоже будет работать. Использование C в C ++ намного проще, чем наоборот.
4. Какой смысл переименовывать вторую основную функцию? Он не будет вызываться, вы можете иметь только одну основную функцию
5. Вы можете переименовать ваши c файлы в C ++ и начать компилировать все с помощью C ++. Это решило бы ваши проблемы со связью с внешним «C» и это то, что я бы сделал в первую очередь. В противном случае C компилируется компилятором C, а C ++ — компилятором C ++. Эти компиляторы ведут себя по-разному, конечно.
6. да, конечно, ваш код на C может нуждаться в некоторой переработке. Это то, что я бы сделал
7. не думай так Опять же, кажется, нет никаких зависимостей? Как это может быть ?
8. не имеет значения, начните компиляцию, затем исправьте проблемы компоновщика
9. могут возникнуть конфликты, если вы включите 2 заголовочных файла, содержащих один и тот же макрос. Компилятор будет пожаловаться с переопределением.

Резюме:

Я думаю, что вы можете просто собрать свой C main() в отдельном модуле компиляции CPP, а затем «extern C» все ваши определения функций C. Звонить из CPP в C легко. Другой способ немного сложнее, так как вам придется создать «… API C для демонстрации функциональности вашего кода C ++ …» — см. Как вызвать функцию C ++ из C?

РЕДАКТИРОВАТЬ: Выше отредактировано благодаря обратной связи от Микаэля (см. Комментарии). Глядя на это, я думаю, что с C ++ до C, как правило, все еще проще, если код C ++ использует преимущества специфических функций C ++, таких как перегрузка объектов и т. Д., Поскольку в этом случае могут потребоваться средства обработки API C (см. Ссылку выше). В этом случае, как указывает Микаэль, это не совсем так, так что в любом случае так легко / сложно …

Примечание: объедините ваши main()в одной функции CPP.

Деталь:

запускать обе программы таким образом, чтобы моя программа на C «вызывала» код C ++

Боюсь, обычно это немного сложно. C ++ делает то, что называется название искажения, так что вызов функции C ++ из C трудно сделать переносимым способом, если вы не сделали обертку C (см. ссылку выше). Причина в том, что CPP-компилятор (внутренне без вашего ведома) перезаписывает имена функций и включает такие вещи, как типы параметров, обычно в качестве суффикса к имени, так что он может выполнять такие вещи, как перегрузка функций. Компилятор C не делает этого, потому что перегрузка функций невозможна в C.

Я бы сказал, что было бы лучше запустить ваш main из модуля C ++ и вызывать ваши функции C оттуда … таким образом вы обойдете проблему искажения имен.

Должен ли я обернуть мои файлы заголовков C с внешним «C» {}

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

#ifndef HEADER_FILE_NAME
#define HEADER_FILE_NAME
#ifdef __cplusplus
extern "C" {
#endif
/// FILE CONTENTS
#ifdef _cplusplus
}
#endif
#endif // HEADER_FILE_NAME

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

При компиляции модуля CPP __cplusplus должен быть определен, но при компиляции модуля C он не должен. Это означает, что когда модуль CPP включает ваш заголовочный файл C, он не будет манипулировать именами функций и, следовательно, сможет правильно вызывать функции C.

Или я должен использовать extern «C» в моих файлах C ++?

Extern «C» просто говорит компилятору, что функция имеет связь с языком C, поэтому сгенерированный символ не будет искажен. Поэтому я думаю, что если это функция, которая не была перегружена, то выполнение этого (в файле H для определения функции) предотвратит искажение имени функции, поэтому вы сможете вызывать ее из C. Однако, если вы extern «C» класс, например, который все еще будет иметь связь с C ++, то же самое для функций-членов класса и т. д. … зависит, используете ли вы их или нет … не похоже на это из вашего примера кода.

В понимании я не могу иметь две основные функции. Могу ли я просто переименовать мою основную функцию в C ++?
Может ли это быть вариант (чтобы упростить вещи), чтобы преобразовать мою основную функцию из C в C ++?

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

Однако, если существует модуль C, который должен вызывать модуль C ++, вам нужно будет рассмотреть возможность его компиляции в виде файла CPP или проверки того, что функция CPP extern "C" и не перегружен.

Наконец, в каждой программе есть несколько макросов, которые повторяются (одно и то же имя, одна и та же реализация). Есть ли конфликт с этим? Должен ли я хранить только один набор макросов?

Если макросы определены в файлах C / CPP, то все в порядке. Если они находятся в заголовочных файлах, то может возникнуть конфликт, если один файл содержит два заголовочных файла, каждый из которых содержит один и тот же макрос. В любом случае я бы порекомендовал вынести все распространенные макросы в общие заголовочные файлы, чтобы был только один экземпляр макроса … гораздо более понятный … используйте мантру «не повторяйся» 🙂

Я не учел все ваши вопросы, но надеюсь, что этого достаточно, чтобы вы начали 🙂

Что ж, в идеале вы можете скомпилировать исходники C как C ++ без изменения семантики, а затем просто пользоваться единой системой. В зависимости от размера вашей кодовой базы и ее формы стоит рассмотреть вариант. На самом деле это может быть меньше работы, чем возиться со всеми этими внешними буквами «С» и последствиями.

Следующий вариант — сотрудничество. C ++ разработан для совместимости с C, другое направление не так теоретически, но на практике — я ожидаю, что компиляторы одного и того же поставщика поддерживают кросс-разговор во всех направлениях.

Важно помнить, что если вы добавляете C ++, то вся ваша система считается C ++, поэтому вы должны учитывать одно правило определения, иметь основную часть из C ++ и т. Д. Вы компилируете C, полученный из компилятора C, и рассматриваете их как guest … Вы должны настроить параметры компилятора для совместимости и установить все заголовки, которые совместно используются системами. Обычно это означает использование этих условных выражений, внешнего «C», структур определения типа для их собственных имен и так далее.

При перекрестных вызовах следите за исключениями. В некоторых системах они не должны пересекать границу C / C ++. В других они могут, но вам нужно настроить параметры, чтобы он работал хорошо.

На первом проходе вам нужно только заставить материал работать так же, как и раньше. Для предложений более поздних рефакторингов есть хорошие вопросы здесь на SO и в других местах.

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

В идеальном мире, когда вы пишете свое приложение, оно должно быть написано таким образом, чтобы реализация выполнялась как формальный API, а функция main () переводила / анализировала аргументы командной строки в соответствующие вызовы в API. Если все сделано правильно, файл с подпрограммой main () необходим только для сборки исполняемого файла для его задачи.

Более того, реализация будет построена как библиотека и набор заголовков для использования этой библиотеки.

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

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

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