C / C++ / MFC

Re: Link Errors from Imports/Exports with C++ prog importing C exports

24-Jan-08 13:01

Hi,

I guess I tried in the subject matter to explain the problem

let me say before I describle the problem that I am using a few of the same headers .h files in both The C and C++

project

In the begining when I was getting unresolved extern __declspec from the link trying to import C symbols

into my C++ project I thought it had something to do with were I specfied my LIB file (I am using VS 2005 )

Linker -> General then the specfic .Lib under Linker -> Additional inputs

Now however I getting the Idea that a part of this problem is that I have C++ project importing C symmbols

When I declare the imports as extern "C" __declspec(dllimport) in the C++ project I resolve a few of the externs

However I still get unresolved ___impl_func

seems __impl is added to C export but linking the C++ project it doesn't see these names

would doing the following when building the C exports in the C++ projects Help

#ifdef __cplusplus

DLL_EXPORT __cdecl telling the C++ compiler that this is C export

Maybe there is simeple soultion to all of this if you know any please Share

Thankx

Mark Salsbery24-Jan-08 13:37

Re: Link Errors from Imports/Exports with C++ prog importing C exports

24-Jan-08 13:37

How are the C items exported?

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

ForNow24-Jan-08 15:43

Re: Link Errors from Imports/Exports with C++ prog importing C exports

24-Jan-08 15:43

real vinalla statement __declspec(dllexport) int func(...,)

this probelm has to do with mixed language import/export C/C++

But then again I am sure they DLL's written in other Languages e.g. VB wich use C/C++ DLL's

so what I doing is not that uncommon

However part of the problem is that I am including the same Headers in both the C/C++

So ......

If have gotten rid of most of the errors with the exception of some unresolved externs with a prefix of __imp

Which I understand the compiler appends to a C export When the Link of C++ reads the .Lib

generated by the linker of the C proj it cann't seem to match __imp_func

maybee I need to qualify the C DLL EXPORT (___imp_func ) wih something like __cdecl to make it drop the __imp

prefix

Dont know ???

thankx

CPallini24-Jan-08 21:37

CPallini

24-Jan-08 21:37

I think you can drop the ___imp_func specifier and use standard __declspec(dllexport).
Smile | :)

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.

[my articles]

Re: Link Errors from Imports/Exports with C++ prog importing C exports

ForNow25-Jan-08 10:55

Re: Link Errors from Imports/Exports with C++ prog importing C exports

25-Jan-08 10:55

the __imp is generated by the compiler for DLL EXPORTS on a C build

Linking the C++ projects with .lib from C gives me the problem

Mark Salsbery25-Jan-08 5:58

Re: Link Errors from Imports/Exports with C++ prog importing C exports

25-Jan-08 5:58

ForNow wrote:
However part of the problem is that I am including the same Headers in both the C/C++

That's what you should be doing IMO. Then you only make changes in one place.
How are you handling the dllimport/dllexport difference depending on the type
of module being built...with a macro?

You should be able to form your shared header something like this:

// Define MY_DLL_BUILD when building the C DLL
//     (using Project settings/Preprocessor Definitions or compiler /D[macro] switch)

#ifdef MY_DLL_BUILD
   #define MY_IMPORTEXPORT __declspec(dllexport)
#else
   #define MY_IMPORTEXPORT __declspec(dllimport)
#endif


#ifdef __cplusplus
extern "C" {
#endif

// Declare an imported/exported function
MY_IMPORTEXPORT void SomeFunction();

#ifdef __cplusplus
}
#endif

Note that's a simplified solution. You may need more for certain
types of builds.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

ForNow25-Jan-08 10:53

25-Jan-08 10:53

coding that seems more stright foward I'll try it tommorow nite

thankx

GDI+ RectF constructor

bob1697224-Jan-08 9:34

24-Jan-08 9:34

According to MSDN, the default constructor for a GDI+ RectF class will initialize the X and Y members to zero. It doesn't say anything about the Width and Height members. Does anyone know if the Width and Height get set to zero? I did some quick testing and it appears so but I thought I'd ask around before relying on this possibility in case I was getting fooled somehow.

From MSDN:
******************************
RectF::RectF Constructor

Creates a RectF object and initializes the X and Y data members to zero. This is the default constructor.

Mark Salsbery24-Jan-08 9:41

24-Jan-08 9:41

Here's the source code...

RectF()
{
    X = Y = Width = Height = 0.0f;
}

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

bob1697224-Jan-08 9:57

24-Jan-08 9:57

Where'd you find that?

Is that in the header?

bob1697224-Jan-08 9:59

24-Jan-08 9:59

Oops, by the way...thanks Blush | :O

Mark Salsbery24-Jan-08 10:01

24-Jan-08 10:01

Heh

I just traced into it in the debugger....it was quicker
at the moment then a text search. And yes, it's in the header...
gdiplustypes.h. Looks like the entire class is inline methods.

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

bob1697224-Jan-08 10:08

AFX_MANAGE_STATE in CMyThread::InitInstance()?

24-Jan-08 10:08

I see it now. D'Oh! | :doh:

Boy I feel stupid.

Thanks for the guidance.

Wes Jones24-Jan-08 9:09

Wes Jones

24-Jan-08 9:09

Hi All,

I am looking some code in a dll which is part of a project I inherited & see the following code in a CWinThread derived class:

<br />
BOOL CMyThread::InitInstance()<br />
{<br />
    AfxEnableControlContainer();<br />
    AfxOleInit();<br />
<br />
    CoInitialize(NULL);<br />
<br />
    AFX_MANAGE_STATE(AfxGetStaticModuleState());<br />
<br />
    //..other stuff starts here<br />
    return TRUE;<br />
}<br />

Is it me, or does AFX_MANAGE_STATE() not belong here? The thread is instantiated from other plaes in code where AFX_MANAGE_STATE has already been called & there is no cross-thread communication w/ other threads or the calling process.
Is it common practice to call AFX_MANAGE_STATE from a CWinThread derived class's InitInstance() ?

Also, does it matter if I call CoInitialize/CoInitializeEx before calls to AfxEnableControlContainer()/AfxOleInit()?
Thanks!

David Crow24-Jan-08 9:22

David Crow

24-Jan-08 9:22

Wes Jones wrote:
Is it common practice to call AFX_MANAGE_STATE from a CWinThread derived class's InitInstance() ?

Only if the place in which it is called will be loading resources from the DLL.

"Normal is getting dressed in clothes that you buy for work and driving through traffic in a car that you are still paying for, in order to get to the job you need to pay for the clothes and the car and the house you leave vacant all day so you can afford to live in it." - Ellen Goodman

"To have a respect for ourselves guides our morals; to have deference for others governs our manners." - Laurence Sterne

Wes Jones24-Jan-08 9:41

Wes Jones

24-Jan-08 9:41

Hmm.. so if the InitInstance brought up a CDialog based class & called DoModal(), it'd be loading resources & it'd be a good idea to call this?

such as:

<br />
viod MyDll_ShowScreen()<br />
{<br />
 AFX_MANAGE_STATE(...);//already calls it here...<br />
 ...<br />
 AfxBeginThread( RUNTIME_CLASS(CMyThread) );<br />
}<br />
<br />
CMyThread::InitInstance()<br />
{<br />
  AFX_MANAGE_STATE(....);//<-- good idea?<br />
<br />
  CMyDlg dlg(...);<br />
  dlg.DoModal();<br />
<br />
  PostThreadMessage(WM_QUIT,0,0);<br />
  return TRUE;<br />
}<br />
<br />
//from calling process:<br />
MyDll_ShowScreen();<br />

David Crow24-Jan-08 9:45

David Crow

24-Jan-08 9:45

Yes, otherwise the InitInstance() method would be looking for CMyDlg's dialog template in the EXE that owns your DLL.

Wes Jones24-Jan-08 11:05

Wes Jones

24-Jan-08 11:05

My understanding is that AFX_MANAGE_STATE is it's on more of a module level, not so much on a per-thread level.

Mark Salsbery24-Jan-08 9:52

24-Jan-08 9:52

Wes Jones wrote:
does it matter if I call CoInitialize/CoInitializeEx before calls to AfxEnableControlContainer()/AfxOleInit()?

CoInitialize(Ex), if needed, should be called before AfxOleInit().

I don't know if this note from the docs is relevant here...

"If AfxOleInit is called from an MFC DLL, the call will fail. The failure
occurs because the function assumes that, if it is called from a DLL, the
OLE system was previously initialized by the calling application."

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

led mike24-Jan-08 10:19

led mike

24-Jan-08 10:19

Isn't DLLMain() a more appropriate place for initialization calls. Doesn't the documentation even say that? I have always initialized OLE and cleaned it up in DLLMain for DLL_THREAD_ATTACH/DLL_PROCESS_ATTACH and DLL_THREAD_DETACH/DLL_PROCESS_DETACH and have never had any problems.

led mike

Mark Salsbery24-Jan-08 10:26

24-Jan-08 10:26

hmm I thought one wasn't supposed to call any ole init funcs from dllmain.

Maybe this is irrelevant, but from the docs:

"Because there is no way to control the order in which in-process servers
are loaded or unloaded, do not call CoInitialize, CoInitializeEx, or
CoUninitialize from the DllMain function."

What thread is DllMain called on? Does it even make sense there? I dunno...
my brain is fried today (death in family...nightmare week).

Mark

Mark Salsbery
Microsoft MVP - Visual C++
Java | [Coffee]

led mike24-Jan-08 10:52

led mike

24-Jan-08 10:52

in-process servers, hmm, I would like to see more of that. Do you have a link? I was not thinking about COM servers but just DLL's as it has been many years since I have developed any COM servers. I guess my recent experience has limited my thinking *that's weak*. In the recent past my DLL models have been for libraries that use COM servers rather than implementing them. I have never had a problem even though multiple init's are surely happening within the process.

Mark Salsbery wrote:
What thread is DllMain called on?

The current process is creating a new thread. When this occurs, the system calls the entry-point function of all DLLs currently attached to the process. The call is made in the context of the new thread.

link[^]

led mike

Mark Salsbery24-Jan-08 11:01