Re: portability thing?

[Robert Heller]

  Dan Stromberg <strombrg@dcs.nac.uci.edu>,
  In a message on Tue, 15 Nov 2005 19:24:17 GMT, wrote :

DS> Hi folks.
DS> 
DS> I'm working on building some software, some of which is written in C++,
DS> for a researcher here at the University.
DS> 
DS> I have an extensive background in C and python, but I haven't done much
DS> with C++ - I kind of mostly abandoned C++ some time ago, when I coded a
DS> project in C++, and some of my coworkers refused to use it -because- it
DS> was in C++.
DS> 
DS> So anyway, I'm working on building a library in C++, and although the
DS> library builds fine with g++, it does not build with IBM's xlC_r (C++,
DS> reentrant).  The OS I'm on is AIX 5.1 ML 4.
DS> 
DS> I was fine with building the library with g++, but the researcher really
DS> wants it built with xlC_r, because he believes (and is probably right)
DS> that xlC_r will produce faster code, and produce a library that can be
DS> linked with either xlC* or g++, while a library compiled with g++ would
DS> appear to be only linkable, on this platform, with g++.
DS> 
DS> 
DS> The error I get with xlC_r is:
DS> 
DS> xlC_r -qlanglvl=extended -q64 /usr/local/lib/libmalloc.a -DHAVE_CONFIG_H 
-I. -I. -I. -I. -I./gl -I/usr/local/include -I/usr/local/include/libxml2 
-I./GNU -g -c -M RValue.cc  -DPIC -o .libs/RValue.o
DS> "RValue.cc", line 176.39: 1540-0016 (S) The expression must be an integral 
constant expression.
DS> gmake[2]: *** [RValue.lo] Error 1
DS> 
DS> 
DS> The offending line of RValue.cc is:
DS> 
DS>     BaseType **argv = new (BaseType *[argc + 1]);

Are you really sure you don't mean this to be:

        BaseType **argv = new BaseType *[argc + 1];

?????

What happens to your code when you strip out these extra (and I think
unneeded/extraneous) parens?  I'm assuming that what you are doing to
allocating a vector of BaseType *'s of argc+1 length.  Otherwise the
code makes no sense.

I think that g++ is being wildly permissive about the parens (which
don't really make sense (to me) in this context).  I don't think it is
a g++ extension, but a plain old typo in your code, that g++ is not
complaining about (as maybe (IMHO) it should).  Hmm.  Just tested this on
my RH 7.3 box (gcc version 2.96 20000731 (Red Hat Linux 7.3 2.96-113))
and the assembly code for these two lines is nearly the same.  I think
g++ is being really clever and allowing those parens in a 'strange'
context, basically treating them like they are not there.  And on a WBL
3.0 (= RHEL 3.0) box, the parens make *NO DIFFERENCE* at all at the
assembly code level (gcc version 3.2.3 20030502 (Red Hat Linux
3.2.3-49)).

I'd say get rid of the parens.  I suspect that the xlC compiler
will happy at that point.

DS> 
DS> 
DS> Unfortunately, that "*[argc + 1]" wouldn't mean a great deal in C, and I
DS> suspect it's not going to be in many C++ books, because it seems likely
DS> that it's not portable C++, but rather a g++ extension of some sort? 
DS> Moreover, it seems a difficult thing to google for due to it being a bunch
DS> of special symbols, rather than keywords...
DS> 
DS> Anyway, I've tried a few things to get this to build with xlC_r, including
DS> cranking up the permissiveness of what language extensions xlC_r accepts,
DS> but it doesn't seem to be helping.
DS> 
DS> Does anyone have any suggestions for me?
DS> 
DS> Thanks!
DS> 
DS>          

                                     \/
Robert Heller                        ||InterNet:   heller@deepsoft.com
http://www.deepsoft.com/             ||FidoNet:    1:321/153            
http://www.deepsoft.com/~heller      /\