/* In modelloader.lib */
class CModel
{
public:
Cmodel();
~Cmodel();
void SomeMethod ( void );
void Render ( void );
};
/* In the main engine library (using the modelloader.lib): */
class CEngine
{
private:
CModel *m_CModel;
public:
// Constructor, destructor, blablabla
CEngine ( void ) { m_CModel = new m_CModel(); }
~CEngine ( void )
{
if ( m_CModel ) delete m_CModel;
}
CModel* GetModelLoader ( void ) { return m_CModel; }
};
Building a .lib using a .lib?
Hey all,
In my ongoing quest to create a game engine I've started wondering about this: suppose I have a library that employs a class for loading and rendering models in a custom file format.
Is it possible to build another .lib that has been built using aforementioned .lib and and which then employs the same functionality? I am aware this may sound a bit strange (even to me :P) but let me illustrate it with a short code example:
I hope this gives a better illustration of what I want. In fact, let me rephrase the question: "Suppose I use the GetModelLoader function of CEngine, will I be able to use all of CModel's methods?"
Thanks in advance for any help.
Thanks for the quick answer - I have another question however. When you say "just make sure you link them in the correct order" do you mean that the 'end-user' would still have to include the modelloader.lib and take care about linking it before the main engine's library?
In other words, will the main engine library kind of 'contain' the modelloader library after it's been built or do you still need to link both .libs in all projects you'd do with the engine?
In other words, will the main engine library kind of 'contain' the modelloader library after it's been built or do you still need to link both .libs in all projects you'd do with the engine?
I'm not sure on the answer to that since I've only used them in a dll setting. Hopefully someone else can enlighten us.
Quote:Original post by tstrimp
I'm not sure on the answer to that since I've only used them in a dll setting. Hopefully someone else can enlighten us.
If I am following along correctly, if you arent using DLL's, the lib files will all be statically linked into your resulting EXE. So, there will be no issue assuming you get past any linker dependancies. Lib files are co-dependant on other libs all the time, nature of the beast.
Quote:Original post by Serapth
If I am following along correctly, if you arent using DLL's, the lib files will all be statically linked into your resulting EXE. So, there will be no issue assuming you get past any linker dependancies. Lib files are co-dependant on other libs all the time, nature of the beast.
So you can't link a static lib into another static lib the same way a static lib is linked into an executable.
Quote:Original post by tstrimpQuote:Original post by Serapth
If I am following along correctly, if you arent using DLL's, the lib files will all be statically linked into your resulting EXE. So, there will be no issue assuming you get past any linker dependancies. Lib files are co-dependant on other libs all the time, nature of the beast.
So you can't link a static lib into another static lib the same way a static lib is linked into an executable.
No no, you can. Its just they all basically just end up getting smushed together into your executable. Infact statically linking libs is probrably easier then going the DLL route, since you can gaurantee all your code is going to be there ( since its packed into the executable ) and nobody is going to come along and replace it with a new version sometime down the road.
So long as you can keep the linker happy ( aka, no circular dependencies ), you can link as many libs together as you want. The biggest caveat is, they all need to be compiled using the same threading model.
Quote:Original post by Serapth
No no, you can. Its just they all basically just end up getting smushed together into your executable. Infact statically linking libs is probrably easier then going the DLL route, since you can gaurantee all your code is going to be there ( since its packed into the executable ) and nobody is going to come along and replace it with a new version sometime down the road.
So long as you can keep the linker happy ( aka, no circular dependencies ), you can link as many libs together as you want. The biggest caveat is, they all need to be compiled using the same threading model.
That is, assuming we're talking about a .exe. In this case I'd build a library that has been linked with an already finished library. The library 'to be created' should then offer the same functionality as the already finished library without requiring the 'end user' to link both libraries...
Would this still apply?
Quote:Original post by rogierpenninkQuote:Original post by Serapth
No no, you can. Its just they all basically just end up getting smushed together into your executable. Infact statically linking libs is probrably easier then going the DLL route, since you can gaurantee all your code is going to be there ( since its packed into the executable ) and nobody is going to come along and replace it with a new version sometime down the road.
So long as you can keep the linker happy ( aka, no circular dependencies ), you can link as many libs together as you want. The biggest caveat is, they all need to be compiled using the same threading model.
That is, assuming we're talking about a .exe. In this case I'd build a library that has been linked with an already finished library. The library 'to be created' should then offer the same functionality as the already finished library without requiring the 'end user' to link both libraries...
Would this still apply?
The thing is, with statically linked lib files, the "end user" is ignorant to the fact. The only case where this wouldnt be true is if you were creating a public API as a static lib file, that has dependancies on other static lib files. In this case, im not completely sure if the end user will need both lib files or not. However, if you build an EXE or DLL that link in static libraries, and distribute those, again the end user will be ignorant.
Keep in mind, you can or atleast could, statically link to the C runtime. How many other libs do you think are dependant on the c runtime? ;)
EDIT: Perhaps this will make a bit more sense. When you link to a LIB file, the linker is actually copying the code from the lib file into your project. From this point on, the origonal lib file should no longer matter. However, when linking to a dynamic library ( such as a DLL ), the linker is merely pulling in references to locations in the other library. This is why you get dependancy nightmares known as DLL hell. If those references change its not so fun.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement