extern "C"
George
Just to confirm what is the most correct way beyond a just working function.
1.
We need to add extern "C" to both variable/function definition/declaration?
Or only need to add to the variable/function declaration?
2.
How about extern? Declaration only or both declaration and definition are
required?
BTW: previously, I only add to declaration, but after reading more and more
code which add to both declaration and definition, I come to here to ask this
question.
thanks in advance,
George
gerhard
> BTW: previously, I only add to declaration, but after reading more and more
> code which add to both declaration and definition, I come to here to ask this
> question.
Read a book to learn C
Tim Roberts
extern "C" is only required for the declaration.
Do you understand that extern "C" is only used for C++ that you need to
call from a C function?
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
George
From some self-study, I found to add extern "C" to both declaration and
definition is safe, especially when there is function pointer as input type.
Any comments?
http://www.glenmccl.com/ansi028.htm
regards,
George
George
I do not think this question is easy to answer. Please read my reply to Tim,
about special case for function pointers. Sometimes people here
over-simplified my question. :-)
regards,
George
Ben Voigt [C++ MVP]
extern "C" should also be used with dllexport, even if the caller is C++, to
get rid of the (compiler version dependent) name mangling.
George
BTW: to make it safe, we should add extern "C" to both declaration and
definition, right?
regards,
George
Drew
Drew
"George" <Geo...@discussions.microsoft.com> wrote in message
news:D8810866-D9BC-4B78...@microsoft.com...
George
> Compiler/Linker will error if linkage specifications don't match.
>
What is your context about the one-sentence statement? You mean you prefer
to add extern "C" to both declaration and definition?
regards,
George
Abhishek Padmanabh
>
> - Show quoted text -
extern "C" specifies external linkage spec for the functions that you
declare somewhere. If these functions are just used in one compilation
unit, giving in extern "C" or not probably does not matter. It is only
when you use those functions somewhere else (in some other .cpp/.c
file). Usually, you would not copy the full implementation of that
function everywhere. You would have a header file and you keep
including that in the other compilation units. And you would include
that header (with function declarations) in the file that implements
them. So, the compiler is able to see that the function has already
been declared as extern "C", and hence you don't need to put it with
the function definitions. There can be special cases, for example -
the one mentioned by Ben Voigt above regarding putting extern "C" to
dll exported functions.
Abhishek Padmanabh
wrote:
.. that is there can be cases where you don't have a function
declaration (prototype not defined) in that case, you would be forced
to put it into the function definitions.
Tim Roberts
>
>Thanks Drew!
>
>> Compiler/Linker will error if linkage specifications don't match.
>
>What is your context about the one-sentence statement? You mean you prefer
>to add extern "C" to both declaration and definition?
I think he answered a question different from the one you asked. Because
your questions tend to be somewhat ambiguous, it might be better if you
started including actual examples.
The key is the function prototype, which is the declaration. Attributes
that are included on the function's prototype do not need to be repeated in
the definition. So, if you have this:
-- myfuncs.h --
extern "C" void DoMyFunction( FancyClass* ptr );
Then as long as you #include that both when you define the function and
when you call the function, you don't need the extern "C" anywhere else.
That is, I can say this:
-- myfuncs.cpp --
#include "myfuncs.h"
...
void DoMyFunction( FancyClass* ptr )
{
ptr->ExecuteSomething();
}
And this:
-- caller.cpp --
#include "myfuncs.h"
...
void UseAFunction()
{
FancyClass object;
DoMyFunction( &object );
}
Now, if you have some strange requirement that prevents you from #include
"myfuncs.h" when you define the function, then you would have to include
extern "C" again.
The key is that every module that mentions DoMyFunction must have the
extern "C" somewhere.
Andre Kaufmann
> Tim Roberts wrote:
> extern "C" should also be used with dllexport, even if the caller is C++, to
> get rid of the (compiler version dependent) name mangling.
I would appreciate it, if this would be sufficient for all cases. But
still, IIRC, the compiler adds an underscore for a stdcall calling
convention.
Only if additionally a *.def file is used, the function name is exported
without any name mangling.
Or is there any solution I've missed ?
Andre
Ben Voigt [C++ MVP]
> Thanks for your advice, Ben!
>
> BTW: to make it safe, we should add extern "C" to both declaration and
> definition, right?
I do (place extern "C" on both decl and def) and it has always worked
perfectly for me, on all the most common compilers (MSVC 7/7.1/8, gcc
2.x/3.x).
Ben Voigt [C++ MVP]
Ahh, but that is not compiler-version dependent, and many times the user's
compiler is smart enough to deal with it automatically (.NET p/invoke, for
example, automatically adds both leading underscore and trailing prefix
indicating the stack space used by parameters, when needed).
Andre Kaufmann
But have you seen any Windows DLL exporting their functions, which
generally use stdcall calling convention, added an underscore ? ;-).
If you want to be language independent you have no chance but export the
pure name only - sadly :-/ - I wish Windows would force a name mangling
standard for native languages - at least for calling conventions and
basic types.
Andre