Re: compile on Cray/ nonGNUcompiler

[Mumit Khan]

On Mon, 31 Jan 2000, Daniel Heiserer wrote:

> That would be easy for me. I can run it thru tons of other compilers.
> If there is somebody who can fix it AND wants to fix it in the way 
> that octave is 100% ANSI C++ (what I think is not the worst idea.)

You're of course correct, but do keep in mind that not everybody wants
to (or can!) jump to the latest and greatest compilers that tend to break
lots of existing code. If you really want a surprise, try IBM's latest
VisualAge C++.

Now on to topic at hand -- here're the various pieces that need to be
changed to make Octave compile with a reasonably conforming compiler
(note that I don't consider any versions of GCC released to date to be 
"reasonably conforming"):

Here's a few things from memory when I looked into this a while back.

Simple things:

1. Fix up readline headers. Currently these use K&R declarations.
2. There were a few issues in kpathsea as well, but probably fixed
   by now (my own packages use an older version that did fixing).

3. Fix up non-conformant forward decls, such as:
   
   class ostream;
   class string;

   etc and replace these with the appropriate include statements.

4. Fix up configure to handle non-GNU compilers. It should generally 
   work, but won't in the following cases:
     
   a. Make sure you tell configure to use an ANSI C compiler. The current
      check for f2c compatible F77 compiler will fail otherwise. Easy to
      fix of course.
   b. Other issues such as creating .d files won't work, but again
      there're well established/known methods to make these portable.
   c. Little things like -shared flags may not be acceptable, and you may
      need to use something else (eg., on Solaris, gcc will accept
      -shared, but CC will only take -G). Again, easy to fix.

5. GCC allows certain accesses that are illegal (due to bugs in scope
   handling in GCC, not because GCC is trying to help you ;-). I remember
   a case or two in Octave, and easily fixed. 

Simple, but very tedious things:

1. Fix up all usages of std:: namespace symbols! When I moved to EDG
   based compilers, this was what took me the most time to "fix" 
   a large package. I don't care for my own sofware to be compilable 
   by older compilers, so my solution was simple -- prefix each 
   occurance of iostream, string etc with std::. The rest of my code 
   was already namespaced, so the transition was quite trivial.

Quality of Implementation issues:

1. Fix up various variable shadow'ing issues in Octave. Octave's code 
   has a few cases where the class data member names and the name of a
   parameter to a method coincide. I tend to name data members so that 
   this doesn't happen, but that's a style/guideline issue.

   The current shadowing in Octave is unlikely to lead to bugs because
   of the relatively decent type-safey in C++, but it'd be nice to get 
   rid of these.

I probably have most of these changes sitting in a CVS branch somewhere,
and if you someone really wants it, I'll dig it out.

If you really want to try good compilers, try out KCC or something based
on EDG. 

Regards,
Mumit




-----------------------------------------------------------------------
Octave is freely available under the terms of the GNU GPL.

Octave's home on the web:  http://www.che.wisc.edu/octave/octave.html
How to fund new projects:  http://www.che.wisc.edu/octave/funding.html
Subscription information:  http://www.che.wisc.edu/octave/archive.html
-----------------------------------------------------------------------