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 _______________________________________________ Aspell-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/aspell-devel
