|
If you can use namespaces, then you can put the functions in the .LIB files into different namespaces.
This way you can use differentiate between the functions using namespaces.
|
|
|
|
|
I have been meeting the following in some c/c++ codes but I don't understand the theory behind it:
#ifdef __cplusplus
extern "C" {
#endif
I want to understand how it works. I know about the preprocessing but I don't know what that extern "C" in the code does. Someone teach me please!
|
|
|
|
|
The C++ compiler does something called name mangling which facilitates function overloading.
The extern "C" syntax tell the C++ compiler not to perform function overloading.
The code snippet that you posted first checks if the code being compiled is using a C++ compiler and if so starts a block in which name mangling will not be done.
|
|
|
|
|
That typically encloses DLL's exported functions.
You should know, C Language and C++ one use different approach to function's name mangling (i.e. altering the name of the funtion in object -or library- files), more specifically, C++ includes in the mangled (or decorated) name info about the function argument types (this allows, function overloads, a C++ feature, not available in C language).
The mechanism allows the same header to be used by both the C and C++ compiler ( __cpluspls macro is defined only by the C++ one) and works this way:
The C compiler, ignores the extern "C" (__cplusplus is not defined) directive both when building the DLL and when including the DLL header inside an application.
The C++ compiler, according with the extern "C" (__cplusplus is defined) directive:
- Produces a standard
C DLL (i.e. the function use the C language mangling scheme) when building th DLL. - consider the library as a
C DLL when the header is included in a application (you know C++ compiler is able to link with C libraries).
Hope it helps.
If the Lord God Almighty had consulted me before embarking upon the Creation, I would have recommended something simpler.
-- Alfonso the Wise, 13th Century King of Castile.
This is going on my arrogant assumptions. You may have a superb reason why I'm completely wrong.
-- Iain Clarke
[My articles]
|
|
|
|
|
I created a modless dialog box using Createdialog Function.but it is returning null value.what might be the reason.Please let me know
kir_MFC
|
|
|
|
|
Check the error value using GetLastError.
Also, it would help if you post the line of code that fails.
|
|
|
|
|
CreateDialog((HINSTANCE)hinst, _S("ABORT"), hDlg, (DLGPROC)lpAbortDlg)
kir_MFC
|
|
|
|
|
From the error code and code that you posted, it looks like ABORT is not a dialog template defined in your resource.
|
|
|
|
|
I see 3 things that I would question...
1/ Why the cast to HINSTANCE? If hinst is not already good enough, what it is?
2/ Same question with lpAbortDlg. If it's not the right type already, maybe there's a problem there.
3/ _S("ABORT"). I know _T, but not _S. Maybe ABORT is a constant, and what you really need is:
MAKEINTRESOURCE(ABORT) ?
Another thing that has caused my dialogs to fail in the past is when they contain a control that cannot be created - ie, a custom window class that you have not registered. To check this, go to resource editor, and check the "do not fail" checkbox.
Good luck,
Iain.
I have now moved to Sweden for love (awwww).
|
|
|
|
|
GetLastError returning 1814
kir_MFC
|
|
|
|
|
kir_MFC wrote: GetLastError returning 1814
The specified resource name cannot be found in the image file.
Not too difficult really ...
|
|
|
|
|
using errlook tool which will give you information about the error code!
Beyond myself!
|
|
|
|
|
I want to use the FlexGrid control in a VC6++ project. When the project was created several weeks ago I unchecked ActiveX support because I didn't think I was going to need that. Now it turns out it has been requested.
I added the ActiveX FlexGrid control using the normal Project -> Add to Project -> Components and Controls. The code compiles with no errors and runs as long as I don't actually add the FlexGrid control to the Dialog form.
When I drop a FlexGrid control onto the Dialog form it compiles when no error. However, when I click on Run, nothing happens. My dialog form doesn't start up. If I delete the FlexGrid control from the Dialog form and recompile the application starts up and my dialog form is displayed.
I think this is being caused by the fact that I unchecked the ActiveX support when I started project. How can I now add ActiveX support to the project?
|
|
|
|
|
Call the function AfxEnableControlContainer in the InitInstance method of your CWinApp derived class.
|
|
|
|
|
I added the AfxEnableControlContainer function. But my dialog still doesn't come up. Also, the function call is looking for an argument. What would that argument be?
Thank.
|
|
|
|
|
Never mind. I found that I had to place the function call ahead of initializing my application instance. By doing that my dialog form now comes up. Thanks for the help.
|
|
|
|
|
Hi,
I have been programming for 10 years using Borland Builder C++, but now I want to migrate to VS 2005 (or maybe later 2009). I am strugelling with UI and MFC stuff. Could you please recommend a good book to learn (for C++ programmers)?
Most of my applications are stand alone exe with graphic editors (2D at the moment).
Thank you for your help,
Denny
|
|
|
|
|
|
Rewriting your application from C++ Builder to MFC will be a pain for you, since the elegance of C++ Builder GUI designer is no where to be found in MFC. MFC feels like coding with one arm twisted behind your back.
I would recommend you take the leap to .NET and Winforms, you can still integrate your existing C++ code with the .NET code.
If you really don't want to use .NET, then consider looking at the GUI library Qt.
|
|
|
|
|
Snakefoot wrote: the elegance of C++ Builder GUI designer is no where to be found in MFC. MFC feels like coding with one arm twisted behind your back.
Yes, the elegance of Builder. Build apps that are several times the size of a similar MFC app. Use a class library design that inevitably frustrates any attempt to do anything unique; key methods not declared virtual, etc. The elegance of Builder - build your own BloatWare.
MFC seems to be getting a bad rep in this thread. Let me see if I can set the record straight. MFC offers a highly developed class library that is properly designed; it can be customized in ways Builder can't even dream of. You build native C++ apps - no .NET runtime, no .NET dependencies, etc. The idea that .NET replaces native C++ as a platform for high-performance apps is delusional.
L u n a t i c F r i n g e
|
|
|
|
|
Very seldom you need a high-performance CButton og CEdit. Use the right tool for the job, and C++/MFC is not the best tool for building GUI applications.
If there are parts of the application that are performance critical, then one can implement these parts in unmanaged C++, and interop with them from .NET.
Btw. MFC has also become quite bloated after including the BCG library, so unless you want to go WTL then it is difficult to deploy a standard GUI application without dependencies.
|
|
|
|
|
Snakefoot wrote: C++/MFC is not the best tool for building GUI applications.
That is a matter of opinion. With practice and a decent knowledge base, it is possible to create compelling UIs quite quickly w/ MFC. The class library is designed in a way that makes it fast and easy to implement custom UI components, unlike Builder's.
Your own experience may have been negative with MFC; mine has been fun and productive.
[edit]
Truth be told, though, I do love WTL. Any new native C++ project I've started in the last couple of years or so has been a WTL app. It's not a very beginner-friendly framework, though - I wouldn't recommend it in this case.
[/edit]
L u n a t i c F r i n g e
|
|
|
|
|
I'm working with MFC every day, so yes you can build nice applications with this framework.
I'm just saying there are better frameworks out these, especially if used to the GUI library of C++ Builder.
|
|
|
|
|
Thank you all for your input - my experience with Builder is - fast to make a simple project, easy to make a user interface, but of course limitations when you get deeper and the size of the final exe is bigger because you have to ship the VCL.
Sorry, but I am still hazy about the book to learn VS 2005 . I think I will stay with the Builder. 
Thanks again,
Denny
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
