MSDN extern C document is wrong?
George
Not agree with 2 points in the link.
http://msdn.microsoft.com/en-us/library/0603949d%28VS.80%29.aspx
1.
"Microsoft C++ supports the strings "C" and "C++" in the string-literal
field. All of the standard include files use the extern "C" syntax to allow
the run-time library functions to be used in C++ programs." -- I am wondering
whether the document is wrong? Using extern C should allow the run-time
library functions to be used in C functions, since extern C specifies the C
name decoration which could be consumed (linked) by C application?
2.
I also do not agree with this -- " C functions and data can be accessed only
if they are previously declared as having C linkage. However, they must be
defined in a separately compiled translation unit." -- we can define extern C
function in the same cpp file (compiled translation unit) and use the
function in the same cpp file, no need to be defined in a separately compiled
translation unit.
thanks in advance,
George
Ulrich Eckhardt
> "Microsoft C++ supports the strings "C" and "C++" in the string-literal
> field. All of the standard include files use the extern "C" syntax to
> allow the run-time library functions to be used in C++ programs." -- I am
> wondering whether the document is wrong? Using extern C should allow the
> run-time library functions to be used in C functions, since extern C
> specifies the C name decoration which could be consumed (linked) by C
> application?
There are two things, the thing declared in the header and the one defined
in the library. In order to use the thing defined in the library, the one
in the header has to match. The syntax for a matching declaration is
different for C and C++, hence the conditional extern "C".
BTW: both sentences from you end in a question mark, but neither is a
question...
Uli
--
C++ FAQ: http://parashift.com/c++-faq-lite
Sator Laser GmbH
Geschäftsführer: Thorsten Föcking, Amtsgericht Hamburg HR B62 932
George
Let us discuss the second point at first.
I think the MSDN page means if we define some function as extern C, the
function could only be used in another compile unit, not the same unit -- see
MSDN words like "must be defined in a separately". I think it is wrong. I
think the correct description should be, if defined with extern, could be
used in the same compile unit or other compile unit.
Here is the MSDN page and the link, how do you understand it?
" C functions and data can be accessed only if they are previously declared
as having C linkage. However, they must be defined in a separately compiled
translation unit."
http://msdn.microsoft.com/en-us/library/0603949d%28VS.80%29.aspx
regards,
George
dert...@web.de
> I think the MSDN page means if we define some function as extern C, the
> function could only be used in another compile unit, not the same unit -- see
> MSDN words like "must be defined in a separately". I think it is wrong. I
> think the correct description should be, if defined with extern, could be
> used in the same compile unit or other compile unit.
>
> Here is the MSDN page and the link, how do you understand it?
>
> " C functions and data can be accessed only if they are previously declared
> as having C linkage. However, they must be defined in a separately compiled
> translation unit."
Note the subtle difference in the MSDN description: "... C functions
and data can be accessed only if they are previously _declared_ as
having C linkage. However, they must be _defined_ in a separately
translation unit."
You have to distinguish between DECLARATION and DEFINITION of a
function: declaration means that you tell the compiler that there is
some function entity, but you don't specify the implementation. A
definition is both a declaration and the implementation of the
function.
So in the context of using C functions inside C++ source you have to
_declare_ the function as extern "C" functions (so the compiler knows
that it should generate a dependency for a proper C-style mangled
function name), but you cannot compile the "C" function along with
your C++ source code, you have to use the proper C compiler (this is
only for historical reasons, as nowadays MS ships only the cl.exe,
which can compile either C or C++, but not both at the same time).
Regards,
Stuart
George
I agree. Previously, I understand the MSDN statements in this way, if we
define extern C function in one C file, and we can not use the function in
the same C file, but can only be used in other C/C++ files.
I think it is wrong. since we can define, declare and use the same function
in the same compile unit, no need to be a "separate" compile unit.
Any comments? :-)
regards,
George
dert...@web.de
You're right, you can declare and use an extern "C" function in the
same compilation unit.
This still doesn't contradict what the MSDN site (essentially) says:
You cannot mix C and C++ code in the same compilation unit (because
the compilation unit can only be compiled as C++ code or as C code,
but _not_ as "mixed" C/C++ code). Note that when you add 'extern "C"'
to a function, this doesn't mean that this function will be compiled
as C code (this is only dependent on the file extension of the file).
Regards,
Stuart
Wayne A. King
> Note that when you add 'extern "C"'
>to a function, this doesn't mean that this function will be compiled
>as C code (this is only dependent on the file extension of the file).
Or on the compiler option chosen: /TP or /TC
- Wayne A. King
wak...@idirect.com
George
I am investigating how runtime library deals with this issue. I have
examined header files like math.h. I think for runtime library,
- For header file function declaration, it is marked with extern C.
"use the extern "C" syntax to allow the run-time library functions to be
used in C++ programs" -- means using when include header files using C++
compiler/linker, the linker will know it is using C name decoration from
runtime library header file function declaration, which will looks for
symbols with C name decoration? For C program which will use the runtime
library, since all of them are C decoration, runtime library should be used
straightforward.
Is my understanding now correct?
regards,
George
George
1.
> Or on the compiler option chosen: /TP or /TC
The options you mentioned above is to assign source file type. It could
specify the whole file as either C or C++ so that related C/C++ compiler
could work on it and generate either C or C++ name decoration during
compiling process, is my understanding correct?
2.
In yes to 1, then I think its function is not the same as extern C,
difference is -- extern C only visible to C++ compiler, to make name
decorated using C name decoration rules. It could be specified at function
level, which Tc/Tp could not achieved which could only be specified at file
level. Any comments?
regards,
George
dert...@web.de
You've got it.
I have to admit that the second example in the MSDN article
http://msdn.microsoft.com/en-us/library/0603949d%28VS.80%29.aspx seems
a bit misleading since it uses the 'extern "C"' construct in a strange
fashion. Normally, you only use this keyword inside headers that can
be used to compile both C and C++ code:
my_printf.h:
extern "C" void my_printf (const char* Format, ...);
my_printf.c:
/*
* No need to define it 'extern "C"' because this file will be
compiled
* with a C compiler anyway.
*/
void my_printf (const char* Format, ...)
{
/* some implementation */
}
C_client.c:
#include "my_printf.h"
int main ()
{
my_printf ("Some text");
}
Cplusplus_client.cpp:
#include "my_printf.h"
int main ()
{
// The C++ compiler knows that my_printf is a C function.
my_printf ("Some text");
}
Regards,
Stuart
George
> I have to admit that the second example in the MSDN article
> http://msdn.microsoft.com/en-us/library/0603949d%28VS.80%29.aspx seems
> a bit misleading since it uses the 'extern "C"' construct in a strange
> fashion. Normally, you only use this keyword inside headers that can
> be used to compile both C and C++ code:
Which point do you think is misleading? :-)
Actually from grammar point of view, I could understand, but not sure which
are the best and practical usage?
regards,
George
Ben Voigt [C++ MVP]
> http://msdn.microsoft.com/en-us/library/0603949d%28VS.80%29.aspx seems
> a bit misleading since it uses the 'extern "C"' construct in a strange
> fashion. Normally, you only use this keyword inside headers that can
> be used to compile both C and C++ code:
I disagree. A common case is a project written in C with multiple files.
If I have to modify one of the files, I may change it to C++, then any
functions defined in the file must be prefixed with extern "C" so that they
can be found by the pure-C files using them.
Wayne A. King
<Geo...@discussions.microsoft.com> wrote:
>> Or on the compiler option chosen: /TP or /TC
>
>The options you mentioned above is to assign source file type. It could
>specify the whole file as either C or C++ ...
Yes. I was responding to the statement:
>>... will be compiled
>as C code (this is only dependent on the file extension of the file).
It is not "only" dependent on the file extension. The same
determination may be the result of the compiler options used.
>... so that related C/C++ compiler
>could work on it and generate either C or C++ name decoration during
>compiling process ...
Name decoration or mangling is one consequence. Of course, when
building as C then C++ features such as classes, namespaces,
templates, etc. are not recognized. Neither is extern "C".
>In yes to 1, then I think its function is not the same as extern C,
Nobody suggested that it was.
- Wayne
George
"I may change it to C++" -- change file name extension from .c to .cpp/.cxx?
regards,
George
George
1.
> >... so that related C/C++ compiler
> >could work on it and generate either C or C++ name decoration during
> >compiling process ...
>
> Name decoration or mangling is one consequence. Of course, when
> building as C then C++ features such as classes, namespaces,
> templates, etc. are not recognized. Neither is extern "C".
I read your above statements, but still confused. Could you show some simple
pseudo code about your ideas please?
2.
> >In yes to 1, then I think its function is not the same as extern C,
>
> Nobody suggested that it was.
Could you say in some other words please? I am not native English speaker. :-)
regards,
George
Ben Voigt [C++ MVP]
> Thanks Ben!
>
>
> "I may change it to C++" -- change file name extension from .c to
> .cpp/.cxx?
That would typically be one of the changes. Others would be using smart
pointers, C++ specific keywords like inline, variable declarations at
point-of-first-use, etc.
>
>
> regards,
> George
George
What is "point-of-first-use"? Is it a well known formal C++ concept? I did
some Google search but find few results. Is there any other words for this?
regards,
George
SvenC
> What is "point-of-first-use"? Is it a well known formal C++ concept?
> I did some Google search but find few results. Is there any other
> words for this?
In C you needed to declare variables at the beginning of a function
in C++ you can declare it anywhere in a function:
someFile.c
void c_Func()
{
int x = 0; // declare all your variables at the beginning
char *p = NULL;
// and use them later
}
someFile.cpp
void cpp_Func()
{
// do something without x and p...
// now we need x and declare it just here:
int x = 0;
// use x but no p
// now we need p;
char *p = NULL;
// use p and/or x
}
--
SvenC
George
I understand it and using it everyday. I never know it is called
"point-of-first-use"! :-)
BTW: I have another question, do you know what is the root cause in C we
must declare all variables at the beginning? Compiler limitations?
regards,
George
SvenC
> I understand it and using it everyday. I never know it is called
> "point-of-first-use"! :-)
>
> BTW: I have another question, do you know what is the root cause in C
> we must declare all variables at the beginning? Compiler limitations?
Sorry, I do not know that. My guess is that it was done to make writing
a C compiler easier.
--
Sven
George
regards,
George
Tim Roberts
>
>I understand it and using it everyday. I never know it is called
>"point-of-first-use"! :-)
>
>BTW: I have another question, do you know what is the root cause in C we
>must declare all variables at the beginning? Compiler limitations?
C was designed so that it could be compiled very easily. It was viewed as
a "high-level assembler". Remember that computer systems at that time
(we're talking about 1968!) were not the monster powerhouses that we have
today.
Before it can start compiling the code for a function, the compiler needs
to know how many bytes of stack space will be needed for stack variables.
Because of that, C required that all stack variables be declared before any
executable statements.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
George
Generally I agree with you.
regards,
George