|
Hello everyone,
I think extern C is enough to prevent name from decorated, but when we export function names from a DLL using dllexport, even if we declare at the same time with extern C, but without a DEF file to define un-decorated exported function names, the name is still decorated.
I do not know why DEF file is needed? extern C is not enough to control name decoration for both DLL exported names and current DLL model linking?
regards,
George
|
|
|
|
|
George_George wrote: I think extern C is enough to prevent name from decorated
Don't think this is exactly true. C functions are also decorated based on calling convention.
See: http://msdn.microsoft.com/en-us/library/x7kb4e2f.aspx[^]
As an example; in .cpp:
extern "C" {
__declspec(dllexport) int MyFunc ( int A ) { return(A*2); }
}
and in .def (in EXPORTS):
MyFunc @3
'DumpBin /exports mydll.lib' will report '_MyFunc' as the name.
If, we used:
extern "C" {
__declspec(dllexport) int __stdcall MyFunc ( int A ) { return(A*2); }
}
then, even with the .def entry, dumpbin will report '_MyFunc@4' as the name.
What are you using to view the name ?
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Hi cmk,
Your reply is excellent. I have tried but have different results. In the document you recommended, it is mentioned default calling convention is __cdecl, and the resulting name in DLL should begin with sign _.
But my result is the default calling convention __cdecl results in name without _ sign? Here is my code and my output. Any ideas?
I am using VS 2008, Debug build for Win32.
D:\Visual Studio 2008\Projects\TestDll2\Debug>dumpbin /exports TestDll2.dll
Microsoft (R) COFF/PE Dumper Version 9.00.30729.01
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file TestDll2.dll
File Type: DLL
Section contains the following exports for TestDll2.dll
00000000 characteristics
48E8B6E6 time date stamp Sun Oct 05 20:45:26 2008
0.00 version
1 ordinal base
2 number of functions
2 number of names
ordinal hint RVA name
1 0 000110AF MyFunc1 = @ILT+170(_MyFunc1)
2 1 0001106E _MyFunc2@4 = @ILT+105(_MyFunc2@4)
Summary
1000 .data
1000 .idata
2000 .rdata
1000 .reloc
1000 .rsrc
4000 .text
10000 .textbss
extern "C"
{
__declspec (dllexport) int MyFunc1 (int A) {return 100;}
__declspec (dllexport) int __stdcall MyFunc2 (int A) {return 100;}
}
regards,
George
|
|
|
|
|
The default _cdecl is standard, the _ prefix is used by all vendors.
Other calling conventions are vendor specific (__stdcall is only MS i think).
Use extern "C" {} _and_ the default _cdecl when you want to create a dll with one compiler that can be called by an exe compiled using any other compiler.
If you have a .cpp file all functions will be named using C++ naming - mangled. If you have a .c file all functions will be named using C naming - mangled as described in the url i posted in previous message. The default _cdecl .c naming is considered by most to be unmangled, even though it is (leading _).
Using extern "C" in a .cpp file, or extern "C++" in a .c file, just allows you override the default naming the compiler uses based on the file extension (.c or .cpp).
In your dumpbin output MyFunc1 _is_ mangled (_MyFunc). The default is so standard that the _ is often dropped from display - but it is there.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Thanks cmk,
1.
If from dumpbin, we can not see the leading _ sign in my sample, then how could you find the leading _ sign is there? From which tool? Is it a bug of dumpbin which does not accurately?
2.
I am interested in your comments -- "extern "C++" in a .c file, just allows you override the default naming " -- do you mean using extern C++ in a .c file using C++ compiler, we could make the c program using C++ name mangling?
regards,
George
|
|
|
|
|
1.
Dumpbin is showing the leading _
1 0 000110AF MyFunc1 = @ILT+170(_MyFunc1)
it's the name on the right (_MyFunc1).
2. I mispoke, the compiler does not recognise extern in .c files.
extern "C++" would be used if nesting within an extern "C" block.
e.g. f.cpp
#define T_API __declspec(dllexport)
T_API int f_cpp1 ( int A ) { return(A); }
extern "C" {
T_API int f_c1 ( int A ) { return(A); }
extern "C++" {
T_API int f_cpp2 ( int A ) { return(A); }
}
T_API int f_c2 ( int A ) { return(A); }
} // extern "C"
T_API int f_cpp3 ( int A ) { return(A); }
In the above the nesting of extern "C++" overrides the extern "C" it is within.
See:
http://msdn.microsoft.com/en-us/library/0603949d(VS.80).aspx[^]
http://msdn.microsoft.com/en-us/library/s6y4zxec(VS.80).aspx[^]
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Hi cmk,
I read your above sample for point 2. My question is what is your purpose of showing this sample? To prove/show what point relates to my original question? 
regards,
George
|
|
|
|
|
?
The sample was a reply to your question about extern "C" and extern "C++".
It was to clear up what i had previously written.
It does not directly relate to your original question - other than to further point out that extern is not about controlling name mangling, it is about defining linkage; name mangling (or not) is a side-effect of the specified linkage.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Thanks cmk,
Understand and clear now. Two more questions for the link you provided,
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.
regards,
George
|
|
|
|
|
1.
The document is correct.
Remember, extern <string> is C++ only, not C.
The C compiler will throw an "error C2059: syntax error : 'string'" if it sees extern "C".
This is why .h files will wrap extern "C" e.g.:
#ifdef __cplusplus
extern "C" {
#endif
... your C code
#ifdef __cplusplus
}
#endif
2.
I agree it isn't clear what they are referring to. I assume they mean 'C functions and data [in another comp unit] can be ...' which makes the 'However, ...' redundant.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Thanks cmk,
"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." -- after reading your comments, I think the quoted MSDN document means, for system runtime library (for example, I have examined math.h), it is all wrapped with extern C. It means the system library exports symbol using C name decoration.
- And for the header files, when used by C++ files (developer include the headers files in their C++ code), C++ compiler wil notice C name decoration is used and resolves name by C name decoration;
- And for the header files, when used by C files (developer include the headers files in their C code), C compiler wil ignore extern C since extern C is conditional compiled for C++ compiler only, and C name decoration is used by C compiler and resolves name by C name decoration.
All of my above understandings are correct?
regards,
George
|
|
|
|
|
"... used by C++ ..."
Correct.
"... used by C ... C compiler will ignore extern C ..."
The conclusion is correct, the reason is close.
It's not that the C compiler will ignore extern C, it is that the C compiler will not see extern C. The 'extern "C" {' is wrapped in '#ifdef __cplusplus' which will evaluate to false, so the C compiler never sees 'extern "C" {'. If it did see extern C it would throw an error.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
Thanks cmk,
In VC environment, both C and C++ are using the same compiler -- cl.exe?
regards,
George
|
|
|
|
|
George_George wrote: In VC environment, both C and C++ are using the same compiler -- cl.exe?
Yes, but depending on the File Extension it uses either the 'C' or 'CPP' front end. The Backend is mostly the same for both. You can force the CPP compiler to treat a declaration as 'C' with the 'extern "C" ' directive. Decorated names are generated differently, and those end up in the obj files. The problem is the Linker. (the 'l' in cl). It is basically stupid, and does not care about C, CPP, or for that matter ALGOL, Pascal, or basic etc, and compiled languages yet to be invented. All it sees is a number of PE .obj files, and tries to do a job of linking names with addresses. It does not know (or care) that '_myfunc',in one obj file, and '??myfunc@ABUXZ0'in another obj are meant to mean the same thing.
N.B. There are ways of exporting names without decoration, by specifying the name in a DEF File. Be carefull though, the name decoration also encodes the calling convention. ( that is, How things are laidout on the stack, and how the task of cleaning up the stack is devided between the caller and the callee. If you just mix C and CPP, don't rename member functions to global, and only use __cdecl (the default), definitely NEVER __stdcall,__pascall, etc, you should be OK.
Hope this is helpfull.
regards
Bram van Kampen
|
|
|
|
|
What does your rule "don't rename member functions to global" mean? Could you show some pseudo code please?
regards,
George
|
|
|
|
|
don't rename member functions to global, and only use __cdecl (the default), definitely NEVER __stdcall,__pascall, etc, you should be OK.
Exampe:
void CMyClass::MyFunction()
The compiler generates hidden pointers to the inststance of the class you are calling from, if you compile a member function being called from a class instance. The Name Decorating Service provided by the compiler ensures that at each stage the correct function is called. In a .DEF file you can override most things. The decorationd determine if you were calling a global, or a member function. member functions have ALWAYS as first hidden param, the pointer to the class they where called from.
If you have in your class a function fputs(LPCSTR pStr, FILE* F); what's called is something like ??MyClass@@puts@ABCD(MyClass* this,LPCSTR pStr...etc.
You create a DEF file to remap ??MyClass@@puts@ABCD to puts;
It will run: puts(this,pStr); and probably crash!
This WIL need some Name translations, but can be made to work.
btw Why are c and cpp names different.
Regards,
Bram van Kampen
|
|
|
|
|
Hi,
How can I set a bitmap on a wizard, I also tried to set bitmap on each property page but it is not fit when i run the application, Some space is coming around the bitmap.
modified on Sunday, October 5, 2008 6:41 AM
|
|
|
|
|
|
No sir, actually when I set bitmap to property page it appears but not from 0,0 pixel but from like 5,5 pixel.
|
|
|
|
|
I am in problem with static variable.Please help me.
Program:
file1.h
int x = 10;
file2.cpp
#include "file1.h"
#include "stdio.h"
extern int x;
void main() {
printf("%d",x);
}
o/p: Error(Unresolved external symbol)...
As per my knlowledge is consern I know to access x I have to use extern.But it is giving error.I want to know whts there reseaon?
Compiler: vc++ 2005(8.0ver)
|
|
|
|
|
Technically "x" isn't an extern the way you've done it. You don't need the extern keyword in file2.cpp. Extern is meant to imply that the variable is defined externally to the files that are referencing it. Since you've defined x in the header and then included it it isn't defined externally.
Also you aren't using any static variables whatsoever in the example you've provided. I think you really need to find a basic C primer on the net talking about extern and static variable and read through that since you are missing some fundemental understandings. No point writing code until you clear that up.
|
|
|
|
|
Please modify the code by which I can access x declared in file1.h in file2.cpp.
Again give me one fantastic example of usages of keyword extern.Please don't give example like below...
extern int x;
fun() {
printf("%d", x);
}
int x = 80;
fun2(){
printf("%d", x);
}
|
|
|
|
|
file1.c
-------
int counter = 1;
file2.h
-------
extern int counter;
file2.c
---------
#include "file2.h"
void countToTen()
{
while (counter <= 10) {
printf("%d\n", counter++);
}
}
Notice that counter is defined in the file.c file hence to access it we need to define it as external to our file2.c file that uses it. Hope that gives you an idea about extern vars. Similar principle applies to extern functions.
You really need to read some books on the topic.
|
|
|
|
|
Thanks a lot. It'd be great if you are sending me some useful links.
|
|
|
|
|
Does anyone have instructions on how I would go about automatically adding an auto-increment build number each time the app is compiled so that it shows up in the apps titlebar?
For eg say I have an app called Browser. First time I compile my app the title would be Browser V1.0 (build 1). I compile it again and it would be Browser V1.0 (build 2) etc.
I don't want to have to manually go into the dialog editor and change it for each compile and neither do I want to have to update a variable by hand each time for compile.
Any help would be appreciated. The language is VC++ and I'm using Visual Studio 2009.
Thanks!
PS: I'd like something that doesn't require me to alter or add stuff to the registry. I want to be able to grab the project folder, copy it to another machine and have it work straight off the bat without going through registering 3rd party dll's in the registry each time I move the source code to another PC. I found http://www.codeproject.com/KB/cpp/autobuildnumber.aspx but don't like the fact I need to go through a setup procedure that goes outside of the compiler.
Also most discussions about the topic date back 6+ years. I'm hoping MS added some functionality into VS2009 to maybe make the process simpler, more native.
modified on Sunday, October 5, 2008 8:05 AM
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
