Re: [aspell-devel] Ported to Solaris / Sun WorkShop 6 compiler

[Flemming Frandsen]

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