[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [aspell-devel] stings.hpp
From: |
Kevin Atkinson |
Subject: |
Re: [aspell-devel] stings.hpp |
Date: |
Fri, 16 Apr 2004 07:56:09 -0400 (EDT) |
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