|
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
|
|
|
|
|
What I use is the Build Date held in the PE Header. you get that by opening your exe or dll as a binary file for reading, and wade through the headers. These headers are declared in "Windows.h". I do this once in InitInstance(), and store the value in a global time_t. You can then choose in your AboutDlg to just show this as a 'Secret' number, or format it out as a Build Date and Time. Furthermore, this info is also immediately available to your install routines, and is available for all binaries, whether built by you with this in mind, or otherwise.
regards
Bram van Kampen
|
|
|
|
|
Thanks though I would prefer something a bit easier though. Interesting idea though. I might just write a little app that increments a build number in a .h file and call that per compile. Then include that in the app for use. Shouldn't be too hard. I'm amazed MS after all these years hasn't provided what is a fundemental tool for any developer releasing images for testing.
|
|
|
|
|
montiee wrote: I'm amazed MS after all these years hasn't provided what is a fundemental tool for any developer releasing images for testing.
So am I, but well, my voting shares in microsoft are insufficient to force the issue.
montiee wrote: I would prefer something a bit easier though. Interesting idea though. I might just write a little app that increments a build number in a .h file and call that per compile. Then include that in the app for use
Well, thought of that, even wrote it. Would not use a .h file target for that though, try to line it in as a 'Pre Compile Step'
montiee wrote: Shouldn't be too hard.
That's what I thought. Success!
BTW it is very very easy to write a piece of code to get the link stamp of an exe.
Bram van Kampen
|
|
|
|
|
Hello everyone,
I asked question about debugging native code before -- mode details it is about optimized release mode x64 code which will use register to store variable which will block debugger from monitoring the variable value.
Today, I debugged a managed program, also in release build for the managed program, but I do not compile it with x64, and it is for "Any CPU". I met with the same issue and when see the assembly code, it has the same pattern that putting some variable in register prevents debugger to see its value.
My question is, I am not 100% confident enough (since the build is not for x64 release, but for "Any CPU" release, different build option from the native code issue before) and I want to confirm with you the same issue happens not only in native code in x64 release mode, but also in managed code in release "Any CPU" mode?
thanks in advance,
George
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
