> It is an <brag> original idea </brag>,

Being such a software solipsist, I can assure you my idea was original as
well. <g> Alas, so many people having the same ideas. sigh ...

> I just smacked the example out rather quickly. The syntax might have been
a bit off.
>
> Because *some* people are so much into templates and STL and forget that
the real power of C++ started with OO I got so upset a while ago that I
started http://www.vstl.org/ ;-)

Curse those types. I can't stand people like that ...

Thanks!
Actually, I do kind of agree with your sentiments. It is certainly something
worth pursuining at some point in the future.
Cool!
> I made a start patching a SGI version of STL to actually create VSTL, but
I am kinda short in time and money at the moment...

Am absolutely with you there, my penurious brother. When oh when will it
start to rain again ...

Oh, it rains here and than it gets warm... and sticky...
> Now, that would be a GREAT idea. Let's not make the same mistake twice,
but honer design patterns... ;-)

Sounds cool. I've a massive list of stuff to go into STLSoft 1.7.1, but it's
going to be awhile. There are a couple of container ideas, and maybe we can
chat about them before it goes in, and perhaps enable some VSTL stuff?
(Current timeline: 4 chapters to you guys tomorrow; CUJ column by the 18th;
STLSoft 1.6.5 next week; more chapters for book for foreseeable future;
never-ending writing commitments having me superglued into my chair and not
seeing the world or going for nice bike rides; ... ; STLSoft 1.7.1; ...;
Borland, Intel, Metrowerks, Microsoft, Sun form a consortium to invest in
STLSoft and make me very rich; ... wake up from delusions to find I'm back
at the beginning of the book; ...; remainder of my days blurbling around a
padded room;)

;-)
To be serious, have you checked out my Veneers concept
(http://synesis.com.au/resources/articles/cpp/veneers.pdf), as this has some
related stipulations about in what ways (non-polymorphic, i.e. non-vtable)
inheritance can be done?
Actually, I had not looked at it before, but I have used constructions like (not exactly like) this in the past one was for more or less the same reason as you explained to make MFC controls 'cool' or 'hover over' sensitive without deriving separately from each control. Instead I had a template like:
tempate < class  Ctrl > CoolCtrl : public  Ctrl
{
   // etc...
};

Than...

typedef CoolCtrl < CEdit >            CoolEditCtrl;
typedef CoolCtrl < CDateTimeCtrl >    CoolDateTimeCtrl;

etc..

Since I am writing some C++ code for the Symbian ( http://www.symbian.com/ http://www.nokia.com/ ) operating system at this moment and had to implement the same extension functionality for two different classes at some point derived from the same base class I used the same type of construction again... Just a template to extend each of the classes and typedef'ed them... ;-)

> Well, that last one because I am upset with the ANSI committee for
prototyping swprintf as snwprintf. They didn't want to make the same mistake
twice either, but I think declined the fact that there is tons of code out
there that works with swprintf WITHOUT the string length parameters.
Besides, they had a nice pattern going as:
> printf -> wprintf
> sprintf -> swprintf
> snprintf -> snwprintf
> vsprintf -> vswprintf
> vsnprintf -> vsnwprintf
> Which is now broke... <sigh>

Agreed.

Thanks!

--
ManiaC++
Jan Knepper