Dan Stromberg <[EMAIL PROTECTED]>,
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: [EMAIL PROTECTED]
http://www.deepsoft.com/ ||FidoNet: 1:321/153
http://www.deepsoft.com/~heller /\
_______________________________________________
Help-gplusplus mailing list
Help-gplusplus@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gplusplus
