partial template specialisation problem

I would be partial to using simple composition in such a scenario. Well, in truth I would use std::string, but aside from that for the moment.

This allows you to minimise the interface to what you want. I believe you can do similar things with template specialisation, but IMO the extra complexity isn't worth it.

Ha, yeah std::string is good, but my problem applies to other non-string related problems :)

In your example, surely I then have to pass through a lot of tArray functionality in the string class, e.g. the [] operator, GetSize() function, etc etc ?

or use the string by making calls to a GetStorage() member in a lot of places?

I don't think C++ has a nice solution to offer me for this problem :(

Quote:

However, I don't really want my string class using inheritance like this, I'd rather it used template specialisation, but I can't figure out a nice way of doing it :(

May I ask why?

Template typedefs are coming in C++0x.

Before that point, barring the operators that you lose (operator= and constructors), inheritance is pretty close.

There are some quirky differences in the world of type overloading vs template specialisation... But they are relative corner cases. (Template specialisation doesn't 'know about' C++ object type hierarchies, which can cause some problems in a few corner cases.)

Hmmm... this is a good question, and has just prompted me to do some googling, because I was thinking the inheritance approach would incur some extra function call overhead due to vtable lookups etc.. but because none of the functions I am using are overriden virtuals, I don't think there is any runtime penalty for using inheritance?

Google seems to corroborate this theory..

is there any runtime penalty for using the inheritance approach, if I'm only using the dervied class for adding extra functionality, not for overriding base class functionality?

C++ tries as hard as it can to make decisions at compile time, not runtime. With no virtual functions, you won't pay for using inheritance. But be warned, inheritance can cause problems. For example, the following code will not work:

To make it work, the destructor in tArray needs to be virtual, which will cause a virtual dispatch anywhere you delete a pointer to a tArray (or derived) class.

Remember, using inheritance ties you to the tArray class, whereas using composition makes it easier to move away from this dependency (e.g. to boost::array).

But I still think it is odd that you worry about virtual function cost when you potentially are instantiating lots of classes for each value of MaxLength, which may be unable to share code and thus could increase the size of your executable, which is another cost. You are making a trade off here, both in terms of performance (though I am not going to guess as to which would be faster) and in usability.

To be honest, unless I had a compelling reason not to I would just use std::vector<> for arrays and std::string for text.

ok,

thanks for the help :)

Quote:

To make it work, the destructor in tArray needs to be virtual, which will cause a virtual dispatch anywhere you delete a pointer to a tArray (or derived) class.

*nod*, except you are also getting a heap deallocation hit.

The cost of that will probably hide the cost of the virtual pointer lookup.