John Nagle wrote:

Reece Dunn wrote:

...

John Nagle wrote:

...

I think we're back to using an abstract base class. The hacks to get around it introduce worse problems. I would agree. I have been trying to find a way around the problem and have (sortof) by having a base class:

template< typename CharT > class string_base { private: size_t len, cap; // length & capacity CharT * buf; // data buffer public: string_base( CharT * b, size_t c, size_t l ): len( l ), cap( c ), buf( b ){} // non-virtual implementation };

template< size_t n, typename CharT > class fixed_string: public string_base { private: CharT data[ n + 1 ]; public: fixed_string(): string_base( data, n + 1 ){} };

That's a much better approach than the previous one. It's sound C++, and it's simple. All the operations go in string_base. fixed_string need only allocate space. Where do you hit a problem?

The problems arise in the interation with basic_string_impl and how to implement swap and functions that require constructing a string object. Both string_base and fixed_string must operate through basic_string_impl to allow basic_string operations. I suppose this should be done in a heirarchy similar to the current one, having swap virtual (you don't want to swap internal pointers!) and using the current system for the object construction functions, but it may be possible to have substr virtual, I'm not sure yet. I shall have a go at this and report back when I have a working implementation. Regards, Reece _________________________________________________________________ Stay in touch with absent friends - get MSN Messenger http://www.msn.co.uk/messenger