Re: [aspell-devel] stings.hpp

[James Lee]

On 16/04/04, 12:56:09, Kevin Atkinson <address@hidden> wrote regarding Re:
[aspell-devel] stings.hpp:


> > 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?

Because the ParmString constructor is doing work that isn't needed.
Compare the assembler.  The best a compiler can do is match an
explicit call, why not give it one?

Inefficiency aside, what causes the implicit type cast to ParmString?
If ParmString operator== didn't compare strings, and as far as
compilers go it needn't, it would be an error to use it implicitly.



> > 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?

What do you take me for?


 g++ -DHAVE_CONFIG_H -I. -I. -I./gen -I./gen -I./common
-I./interfaces/cc/ -I./modules/speller/default/
-DLOCALEDIR=\"/opt/csw/share/locale\" -fno-exceptions -MT
common/config.lo -MD -MP -MF common/.deps/config.Tpo -c common/config.cpp
 -fPIC -DPIC -o common/.libs/config.o
common/config.cpp: In function `void
acommon::get_lang(acommon::String&)':
common/config.cpp:384: error: ambiguous overload for 'operator==' in
'locale ==
   "C"'
common/string.hpp:218: error: candidates are: bool
   acommon::String::operator==(const acommon::String&)
common/parm_string.hpp:72: error:                 bool
   acommon::operator==(acommon::ParmString, acommon::ParmString)
common/parm_string.hpp:84: error:                 bool
   acommon::operator==(acommon::ParmString, const char*)
common/config.cpp:388: error: ambiguous overload for 'operator==' in
'locale ==
   "C"'
common/string.hpp:218: error: candidates are: bool
   acommon::String::operator==(const acommon::String&)
common/parm_string.hpp:72: error:                 bool
   acommon::operator==(acommon::ParmString, acommon::ParmString)
common/parm_string.hpp:84: error:                 bool
   acommon::operator==(acommon::ParmString, const char*)
common/config.cpp: In member function `void acommon::Config::merge(const
   acommon::Config&)':
common/config.cpp:940: error: ambiguous overload for 'operator==' in '
   other_value == "(default)"'
common/string.hpp:218: error: candidates are: bool
   acommon::String::operator==(const acommon::String&)
common/parm_string.hpp:72: error:                 bool
   acommon::operator==(acommon::ParmString, acommon::ParmString)
common/parm_string.hpp:84: error:                 bool
   acommon::operator==(acommon::ParmString, const char*)


> > 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.

Some would say immutable strings are a feature.

It seems a lot of effort is going into recreating what is part of
the standard library.  As a matter of principle that makes me uneasy.


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

That would be the rationalisation I mentioned.  Any reason why they
need implementing in different ways?  Why can't Sting alone provide
what is needed?



James.