[MSVC++] Class doesn't have member but has it O_O

[camelCase]

[Is vs Has] Which is more efficient? Which should I use?

Well,
A few times, I find myself using a class only as a wrapper for std::vector, std::map, etc. and add along with a few extra methods/members that I need.

So, is it better if I make the container a member of the class or the parent of the class?
Which is more efficient?

This, of course, extends to other examples but I can't think of anything off the top of my head.

 

[s3rius]

Ah, I see I can get into more detail after that other topic already showed something of this mischievous act against humanity!

Make it a member (composition), don't inherit from std classes.

Composition should usually be prefered to inhertitance (http://en.wikipedia.org/wiki/Composition_over_inheritance - once wiki stops striking).

One reason is that std classes change drastically depending on if you build your app in debug or release mode (or anything inbetween). They can change size, internal workings, add or remove functions. Tons of stuff. That'll make it very cheesy to use them sometimes.

Also, they "pollute" your new class with tons of functions and variables that might end up in your way.

In terms of efficiency you're probably better off using composition too. Inheriting might force the compiler to create a virtual function table for your object (and if it doesn't, you might get problems with derived-to-base conversions as you can't implement virtual constructors).

Simple wrapper classes and small functions will most likely be optimized away by the compiler, leaving nothing but a few lines of code and the vector in the end.

Composition is definitely the cleaner variant and should be prefered simply because of that.

 

[camelCase]

Wow, that composition example on the wiki-page was... Different ._.
Yeah, I understand the 'pollution' especially with intellisense, even private inheritance didn't stop intellisense from spamming me with stuff I didn't wanna' use.

This std classes changing depending on compiler, build mode, etc. is also why we shouldn't use std classes in DLLs, right?
Because I was trying some stuff out, building a game-framework for my game using SFML and exporting it as a DLL (so that my game solution itself wouldn't be cluttered with source and header files from the framework) and got warnings about using std classes in DLLs =/

But SFML uses std classes, how come they don't get warnings? =x

 

[s3rius]

But SFML uses std classes

They do?
Well, maybe they keep their own copy of these classes inside the DLL. As long as they don't expose this to the outside (= user) that shouldn't mean a problem.

PS: Oh, I see they do... hmm.

This might help clear things up: http://support.microsoft.com/default.aspx?scid=KB;EN-US;168958
I just woke up, basically. So I'm too tired to read right now.

 

[camelCase]

I read it once, twice and didn't get it =/
I got lost at this part:
"In both the DLL and the .exe file, link with the same DLL version of the C run time."

Even the sample code still had me confused =x