Kevin Atkinson wrote:
> I will not apply the patch as is as there are some changes I don't
> approve of.
That's ok, I expected as much:)
> 1)
> I will accept the changes to deal with the fact that the sun compiler
> is to stupid to know that abort doesn't return as those are harmless.
Well, yes CC is stupid, it doesn't check sprintf format strings either, but I'm told
it seems to produce better code for SPARC, so here we are.
> 2)
> In may cases you changed:
>
> String val = config.retrieve("key");
> to
> String val = String(config.retrieve("key"));
>
> what is the error you are getting without the change? There might be
> a better way to solve the problem.
There is a constructor for String that takes an PosibError (what things return), but
there is also an operator= on String that takes a PosibError.
Just the constructor ought to be enough, the = operator is redundant IMHO.
Deleting String::operator= (PosibError...) would probably be the easiest and most
correct solution, but I was a bit nervous about it, so I chose to use the constructor
explicitly.
What do you think?
> Same for
> -static void display_menu(O * out, const Choices * choices, int
> width) { +static void display_menu(O * out, const StackPtr<Choices>
> &choices, int +width)
The sun compiler bitched about incompatible types, 'Choices *' is not the same as
'StackPtr<Choices>', which is what is needed in the function.
I guess StackPtr<Mumble> just happens to resolve to the same as Mumble * with GNUs STL
implementation, but assuming it always does is bad form or at least not something that
you can assume all compilers understand.
> 3)
> The C++ standard requires "friend class HashTable", "friend HashTable"
> is not valid C++ and will not compile with gcc
Hmm, that wasn't good.
With: friend class HashTable; I get:
"vector_hash.hpp", line 243: Error: A typedef name cannot be used in an elaborated
type specifier..
With: friend class Parms::HashTable; I get:
Error: aspeller_default_readonly_ws::ReadOnlyWS::WordLookupParms::HashTable is not
defined.
How about:
#ifdef __SUNPRO_CC
// Fix for deficient sun compilers:
friend HashTable
#else
friend class HashTable
#endif
> 4)
> What is the reason for?
> +#if (1)
> + FStream CIN(stdin, false);
> + FStream COUT(stdout, false);
> + FStream CERR(stderr, false);
> +#else
> +#include "iostream.hpp"
It seems the symbols from iostream.cpp were not available when linking the
application, maybe because of defective name mangling, maybe because of scoping, it
seemed a lot easier to simply define the vairables there rather than battle with the
build system to figure out what went wrong.
As far as I know libaspell.so is supposed to provide a C interface, not a C++ one,
right? In that case referencing C++ symbols in it is wrong, even if g++ lets you get
away with it.
This is what happens if I try to link it with the default code:
CC -g -o .libs/aspell aspell.o check_funs.o checker_string.o
../lib/.libs/libaspell.so -lcurses -R/home/ffr/projects/spell/test/lib
ild: (undefined symbol) acommon::CERR -- referenced in the text segment of aspell.o
[Hint: static member acommon::CERR must be defined in the program]
ild: (undefined symbol) acommon::CIN -- referenced in the text segment of aspell.o
[Hint: static member acommon::CIN must be defined in the program]
ild: (undefined symbol) acommon::COUT -- referenced in the text segment of aspell.o
[Hint: static member acommon::COUT must be defined in the program]
> 5)
> In parm_string you comment out one of my compressions due to a
> conflict with the STL. I have a configure test to deal with this
> problem. It will define the macro "REL_OPS_POLLUTION". Check that
> the macro is defined in settings.h and if it is use an ifndef around
> the comparasion. if the macro is not defined please let me know.
Ah, right, I just checked and it isn't defined.
The problem isn't that it's impossible to have your own == operator, the problem is
that stl can make an std::string from a char * which can be made from a ParamString
automagicly, that causes a conflict between the two == operators.
... Which IMHO is stupid of CC as the sane thing to do is to select the "nearest"
operator for the job.
As the current configure test doesn't define REL_OPS_POLLUTION on my system it might
be wrong to expand the test to catch this case as well.
I worry about doing what I do now and using the std::string == operator as it might
not work the same way and it may be slower, but I havn't seen any problems with the
approach while running aspell.
--
Flemming Frandsen / Systems Designer
_______________________________________________
Aspell-devel mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/aspell-devel
