On 16/04/04, 12:56:09, Kevin Atkinson <[EMAIL PROTECTED]> 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. _______________________________________________ Aspell-devel mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/aspell-devel
