Why does the extern “C” group C++ class (not header) here?

Question

I was searching SVM libraries and encountered BudgetedSVM.

In the source code, I found an unusual usage, just like this:

#sample.h

#ifndef SAMPLE_H
#define SAMPLE_H

//no header included or namespace declared here

#ifdef __cplusplus
extern "C" {
#endif

//no header included or namespace declared too

class Sample: public Parent
{
public:
    Sample();
    ~Sample();

    type0 fun(type1 val1, type2 val2);
    ...
};

#ifdef __cplusplus
}
#endif

#endif // SAMPLE_H

As seen, no extra header or namespace is needed in the header, which all are in the cpp file.

Here are my thoughts:

1. Why does extern "C", which usually is used for C interfaces, group the C++ class? Is the usage in this way good for something?

2. Even if type0, type1 and type2 appeared, their own headers are not included here, but in the cpp file (e.g. sample.h). When I call the class Sample, however, I have to include these headers (e.g. type0.h, type1.h, type2.h), which seems inconvenient.

Answer 1

According to C++ Standard C language linkage is ignored in determining the language linkage of the names of class members and the function type of class member functions.

So such grouping looks meaningless, unless type0, type1 or type2 are function pointers defined inline, in this case they will have C linkage.

In case type0, type1 or type2 are user defined types and their definitions are placed in separate headers it violates the good C/C++ style rule - all headers shall be self-contained and require no additional inclusions to compile.

To answer the main question ('Why?') - it looks like C language linkage was just blindly copy-pasted from another header (possibly pure C, where it makes sense). Or it maybe done deliberately - by "uniformity" reasons.

Answer 2

Even if type0, type1 and type2 appeared, their own headers are not included here, but in the cpp file(e.g. sample.h). When I call the class Sample, however, I have to include these header(e.g. type0.h, type1.h, type2.h), which seems inconvenience.

Do you mean you have to include them before you call func? If that is the case it's a staple of good code organization, actually. If you never use func, you'd never need to include the headers for those types. The full definition of the types is a hard requirement only for a function call involving those types, not a function declaration.

A header should not include anything beyond the minimum that makes its own inclusion compile. Other things should be forward declared only, as long as it's possible. The standard library has the iosfwd header for this purpose exactly. So that classes that declare stream operators (<< and >>) won't need to pull the entire iostream header.

The call site, that also happens to know what concrete stream it want to write to or read from, does the inclusion.

Remember the design philosophy of C++: You don't pay for what you don't need.

Answer 3

From the C view, there are multiple reasons to do this (your question 2). One is data hiding, another is improving compile times by reducing include hierarchy.

And C allows using type pointers (passing them to functions, etc.) without knowing about them / including them. Unless you're dereferencing, it's fine. So you leave dealing with struct details to the implementor functions, abstracting the details.

Another explanation from a book, check section 4.8: http://www.duckware.com/bugfreec/chapter4.html#cppcomparison

Answer 4

I believe this is used when trying to produce a library which can be linked to by a standard C linker.

Regular C symbol names will be encoded, with the name and type , so a function like this:

int blah(double num);

may have a symbol name like "iblahd" (or something like that, I forget exactly) you see, the return type and the parameter types are in the symbol.

One thing that extern C does is it makes it look for the symbols in a routine C fashion, which would just be "blah"

I think for example, this is being used to create a valid C++ header, that the compiler tries uses it, will produce linking with the symbols in another C library.

Without the extern C, it would be looking for a shared library object with a function name/ encoded symbol in the C++ style.

So, to make it clearer, this is either used

• to create an C++ API to wrap a C library.

or

• to create a C++ library, which can be linked to by a C application

It is possible that it would also cause the class structure to be allocated more like a struct and not to be able to use dynamic polymorphism, so that its memory layout may be correct for C (unfortunately it's been too long for me to remember for sure).