• Advertisement
Sign in to follow this  

MSVC2005Ex: Multiple projects, inheritance and the compiler going mad.

This topic is 3876 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Looks like I've fooled the compiler again. I am using Microsoft Visual Studio Express 2005 to produce native Win32 code. So, I have a solution which is becoming quite complex. Since it actually made sense to split it over multiple projects I taken a few components out of the original project and made them to compile to static lib files. The issue mixing multiple lib files from different projects and inheritance trees seems to be evil to the compiler. The lastly inherited class seems to "lose" some of its inherited entrypoints but strangely enough, not all of them the situation is something like: Free Image Hosting at www.ImageShack.us In project "use" the class "RPSRC" loses the entrypoints. Note "SRC" is also used: it works fine and it's also on another lib. Is there someone who tackled this problem before? I don't want to foward all the func calls.

Share this post


Link to post
Share on other sites
Advertisement
What exactly are the warnings/errors you are receiving?

I'm not sure what you're talking about when you say "inherited entrypoints" when talking about .lib files. I've never found that the object-oriented concept of "inheritance" had any compiler (linker) problems like you describe.

If I had to guess, I'd say you were getting unresolved externals... and that you're using different versions of the standard library for one or more of your projects.

Without seeing some of the code, it would be hard to decide what was wrong, though.

It helps when doing larger projects and static .libs to make the linker deposit all your .lib files in a common directory, and to explicitly include those .lib files in your main (solution) project (the one that creates the executable).

Share this post


Link to post
Share on other sites
Quote:
Original post by Verg
What exactly are the warnings/errors you are receiving?

Because I am really late, I had to go for a manual function forwarding, I'll try to reproduce this again and post the exact string.
I wonder how I managed to not post it in the first time. Sorry for the inconvenience!
Quote:
Original post by Verg
I'm not sure what you're talking about when you say "inherited entrypoints" when talking about .lib files. I've never found that the object-oriented concept of "inheritance" had any compiler (linker) problems like you describe.
I believe linking the obj isn't the problem since this is not a linker error. It's the compiler which refuses to use some inherited entrypoints (the ctor for first) even in the compile stage.
Quote:
Original post by Verg
If I had to guess, I'd say you were getting unresolved externals... and that you're using different versions of the standard library for one or more of your projects.
No. It's a compile-time error. I'll double check my stdlib but I don't think to have a problem here: I use MSVC defaults and everything is ok if I add a manual forwarding in the function definition.
Quote:
Original post by Verg
Without seeing some of the code, it would be hard to decide what was wrong, though.
I know, I tried to figure out what to post but the whole thing counts more than 200 files!
Quote:
Original post by Verg
It helps when doing larger projects and static .libs to make the linker deposit all your .lib files in a common directory, and to explicitly include those .lib files in your main (solution) project (the one that creates the executable).
Is it the same than adding them using the "project dependancy" tab? I used that way.

Share this post


Link to post
Share on other sites
Uhm, I've been cleaning and rebuilding a few times in those hours and it seems I am unable to reproduce the problem.

class RPSRC : public SRC {

/* omissis */



public:
// this is sort of ok, ctors are not inherited.

RPSRC(nameSpace_t *parent) : SRC(parent) { }

/////au16 GetNumFunctons() const { return this->SRC::GetNumFunctions(); }

/////identifier_t* DeclareIdentifier(const au16 index) const { return this->SRC::DeclareIdentifier(index); }



};



I introduced the forwarders marked with ///// because they weren't inherited for some reason.
In this case the compiler would have reported a missing symbol.
Doing the same today however didn't produce the same errors.

It now seems to work sort of ok-ish but somehow the "search" bar stopped to work ( ??? ) and compilation sometimes fail sporadically (something like "couldn't convert to COFF ... corrupted").

Uhm, I fear I could have an HD or HW issue... this sounds nasty!

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement