extern "c"

[srhandore]

In the following code snippet if I remove the the extern "c" specifier then also my code works fine. Then can someone please tell me why do we use this identifier.
It is used when we want to merge some code of c to c++. But in our case as in brew this is not intended.Kindly help :confused: :confused: :confused:


extern "C"
{

int AEEClsCreateInstance(AEECLSID ClsId,IShell * pIShell,IModule * po,void ** ppObj)
{
*ppObj = NULL;

if(ClsId == AEECLSID_HELLOWORLD)
{
if(AEEApplet_New(sizeof(HelloWorld), ClsId, pIShell,po,(IApplet**)ppObj,
(AEEHANDLER)HelloWorld::HandleEvent,(PFNFREEAPPDATA)HelloWorld::freeAppData))
{
if(HelloWorld::initAppData((IApplet *) *ppObj))
{
return (AEE_SUCCESS);
}
}
}
return (EFAILED);
}

}

[Skavenger]

The underlying brew interface when it calls the function "AEEClsCreateInstance" uses the "C" calling convention as opposed to the "C++" one. This is just to specify to the compiler and linker how this function expects its parameters.

[srhandore]

First of all thank you very much for your reply.
But sir, my question is if I remove the extern "c" keyword then also my program is successfully excecuting. Then why to use it.
Is it like we don't want the functions in the code under extern "c" to be overloaded. And to avoid them getting overloaded we are using extern "c".
or
Is it like, in the case where I am getting the intended results without extern "c" but may be there would be some situations where it'll fail to do so.
Kindly help. :confused: :confused: :confused: :confused:

[Skavenger]

If your program is compiled via a c compiler (or C++ compiler with C++ extensions turned off) or from a .c as opposed to a .cpp file then the compiler will not require that extern "c". The reason that its there is if your program is developed in C++ as opposed to standard c.

[rabidcow]

extern "c" doesn't specify a calling convention so much as it instructs the C++ compiler to use C name mangling rather than C++ (ie, leave out the data types, it can't be overloaded across compilation units and C code can find it.)

You never need to wrap the actual function body. Since these functions must be visible in more than one compilation unit, they will almost universally have a prototype in a header file (in this case AEEAppGen.h, IIRC). Having an extern on the prototype is sufficient, assuming you include that file. (Also you don't need it if AEEClsCreateInstance is in a .c source file, but I think the extern "c" would be an error in that case...)

[deepti1]

sir,
I want to know how to create C++ project in brew.when i create an empty project it generates .c file .but i want to generate .cpp file.

[Skavenger]

extern "c" doesn't specify a calling convention so much as it instructs the C++ compiler to use C name mangling rather than C++ (ie, leave out the data types, it can't be overloaded across compilation units and C code can find it.)

Correct.


You never need to wrap the actual function body. Since these functions must be visible in more than one compilation unit, they will almost universally have a prototype in a header file (in this case AEEAppGen.h, IIRC). Having an extern on the prototype is sufficient, assuming you include that file.

Surely you'd need to extern "c" the actual function if its contained within a cpp file, otherwise you'd end up with two function declarations (Once names have been mangled).

(Also you don't need it if AEEClsCreateInstance is in a .c source file, but I think the extern "c" would be an error in that case...)


I'd have said more of a warning as to most compilers its just as a switch.

[rabidcow]

Surely you'd need to extern "c" the actual function if its contained within a cpp file, otherwise you'd end up with two function declarations (Once names have been mangled).

extern "c" void f(void);
void f(void) { }

is fine, so long as the compiler sees both of them. The extern from the declaration carries over to the actual function definition. After all, they're exactly the same function: same name, same type.

Now if you don't have the prototype included in the compilation unit, then you would need to have:

extern "c" void f(void) { }

But it's probably a better idea to just make sure to include a header, so you don't end up with mismatched type signatures. (get a link error instead of a crash or general strange runtime behavior)

I'd have said more of a warning as to most compilers its just as a switch.

I dunno, just ISTM that extern "c" would be generate an error in a C source file... haven't tried it recently. :) But there must be some reason why they're always wrapped in #ifdef __cplusplus...

[Skavenger]

I dunno, just ISTM that extern "c" would be generate an error in a C source file... haven't tried it recently. But there must be some reason why they're always wrapped in #ifdef __cplusplus...

Thats true, haven't tried it in ages but i think VC6 used to just warn you about it. (Dependant on error and warning levels of course). As for .net or 2005 I haven't tried it.

is fine, so long as the compiler sees both of them. The extern from the declaration carries over to the actual function definition. After all, they're exactly the same function: same name, same type.
Exactly. But if your not going to call it from outside of your source file, I don't see the point in adding it to your header file, just seems a waste of time and effort to me.

[rabidcow]

Exactly. But if your not going to call it from outside of your source file, I don't see the point in adding it to your header file, just seems a waste of time and effort to me.

Sure, but if you're not going to call it from outside of your source file why do you need extern "c" at all? Might as well make it static even.

In the specific case of AEEClsCreateInstance it's already declared in a header, you just have to include it. And you need that header anyway for the generic applet structure.

[Skavenger]

Sure, but if you're not going to call it from outside of your source file why do you need extern "c" at all? Might as well make it static even.
If you "static" the function it will NOT be available outside of the current source file. Brew needs access to this funciton therefore static won't work. But because the function is already pre-defined (in their Brew Code) then you don't need to put it in a header.

[rabidcow]

If you "static" the function it will NOT be available outside of the current source file. Brew needs access to this funciton therefore static won't work. But because the function is already pre-defined (in their Brew Code) then you don't need to put it in a header.

That's my point. :) It's just that I consider AEEAppGen to be part of your code and not part of BREW, because it's just another compilation unit that gets linked into your binary.

[Skavenger]

Well it is and it isn't. If you rewrote aeeappgen and aeemodgen then you could call the function whatever you wanted to.

However from experience I know a lot of companies that would prefer you not to rewrite those modules.