Re: stings.hpp

On Fri, 16 Apr 2004, James Lee wrote:

> I'm having problems with strings.hpp. Class String is now
> (last few 0.60) declared as:
> 
>   class String : public OStream
> 
> In previous versions (0.50.5) it is:
> 
>   class String : public std::string, public OStream
> 
> This means that previously a call to operator== was serviced
> by the std::sting class but now there is no operator defined
> within the class.  Running a simple test program[1] through
> ddd shows that gcc will implicitly type cast to a ParmString
> then call operator==(ParmString s1, const char * s2).
> 
> Although by reading the comments I can see that this will give
> the desire result I can't see from the coding why it should be.
> It's also inefficient, even inlined.  

How.  In what way?

> More importantly the Sun
> Forte compiler (Sun 1 Studio 8) doesn't assume the type cast
> to ParmString.  If I provide the operator== methods in
> string.hpp the Sun CC works but g++ finds an ambiguity.

Did you verify this?

> Can the String classes be rationalised?  Why isn't the
> std::string class used? Why don't the other string classes
> inherit from String?

Yes it can.  The standard string class does not give me the control I 
need.  In particular there is no guarantee that the string is stored in a 
continuous area of memory, nor is there a way to get a mutable "char *" 
pointer.  Amount other things.

The other don't inherit from String because they are implemented 
differently.

-- 
http://kevin.atkinson.dhs.org