[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [aspell-devel] stings.hpp
From: |
James Lee |
Subject: |
Re: [aspell-devel] stings.hpp |
Date: |
Sat, 17 Apr 2004 11:07:06 GMT |
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.