C и стандарты кодирования C++

C++ не делает 'безопасных с точки зрения типов проверок' во время выполнения, если Вы не просите их (при помощи dynamic_cast). C++ очень совместим с C, таким образом, можно свободно назвать библиотеки C, как Вы желаете и компилируете код C с компилятором C++. C++ не подразумевает 'объектно-ориентированный', и Вы не должны получать потерю производительности от использования его.

При смешивании кода, скомпилированного с gcc и с g ++ см. ответ Graeme.

Самая большая проблема вызывает функцию C из кода C++ или наоборот. В этом случае Вы хотите удостовериться, что Вы отмечаете функцию как имеющий "C" использование связи extern "C". Можно сделать это в заголовочном файле непосредственно с помощью:

#if defined( __cplusplus )
extern "C" {
#endif

extern int myfunc( const char *param, int another_one );

#if defined( __cplusplus )
}
#endif

Вам нужно #ifs, потому что код C, который включает его, не поймет extern "C".

Если Вы не хотите к (или не может) для изменения заголовочного файла, можно сделать это в коде C++:

extern "C" {
#include "myfuncheader.h"
}

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

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

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

Для gcc это -fexceptions параметр, который включен по умолчанию для C++, но отключен по умолчанию для C.

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

extern "c"
{
    int nice_c_function_interface
    (
        void
    )
    {
        int returnStatus;

        try
        {
             returnStatus = nice_cpp_function();
        }
        catch (NiceCppException& that)
        {
             returnStatus = that.failure_code();  
        }
        catch (...)
        {
            cerr << "Oh Worse! an unexpected unknown exception" << endl;

            returnStatus = -1;  // Horrible unknown failure
        }

        return returnStatus;
    }
}

Здесь нет никаких хороших жестких правил.

Если конечный продукт будет всегда связываться с основным C++ () затем, он действительно не имеет значения. Поскольку можно всегда создавать заголовки, которые сделают корректную вещь.

При создании библиотеки, которая должна иметь C и интерфейс C++, но Вы не можете принять компоновщика C++ затем, необходимо будет удостовериться, что разделили API C от C++ чисто. В этой точке это обычно - инструмент для очистки, чтобы сделать всю работу в C и использовать классы C++ для проксирования к C.

Например:

/* c header */

struct CData
 { /* stuff */ };

void init( CData* data );
void fini( CData* data );
int getSomething( CData* data );
void doSomething( CData* data, int val );

// c++ header

extern "C" {
#include cdata.h
};

class CppData : private CData
 {
 public:
   CppData() { ::init( (CData*)this ); }
   ~CppData() { ::fini( (CData*)this ); }
   int getSomething() { return ::getSomething( (CData*)this ); }
   void doSomething( int val ) { :: doSomething( (CData*)this, val ); }
 };

Я надеюсь, что это помогает.

При компиляции всего источника с g ++ затем, он все компилируется в файлах объекта C++ (т.е. с соответствующим искажением имени и ABI C++).

Необходимо будет только использовать экстерна "C" прием при создании библиотек, которыми нужно пользоваться явно C приложения, которые должны использовать ABI C.

Если все компилируется в единственный исполняемый файл, затем используют g ++ и рассматривают все как C++