portability thing?

[Dan Stromberg]

Hi folks.

I'm working on building some software, some of which is written in C++,
for a researcher here at the University.

I have an extensive background in C and python, but I haven't done much
with C++ - I kind of mostly abandoned C++ some time ago, when I coded a
project in C++, and some of my coworkers refused to use it -because- it
was in C++.

So anyway, I'm working on building a library in C++, and although the
library builds fine with g++, it does not build with IBM's xlC_r (C++,
reentrant). The OS I'm on is AIX 5.1 ML 4.

I was fine with building the library with g++, but the researcher really
wants it built with xlC_r, because he believes (and is probably right)
that xlC_r will produce faster code, and produce a library that can be
linked with either xlC* or g++, while a library compiled with g++ would
appear to be only linkable, on this platform, with g++.
The error I get with xlC_r is:

xlC_r -qlanglvl=extend ed -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
"RValue.cc" , line 176.39: 1540-0016 (S) The expression must be an integral constant expression.
gmake[2]: *** [RValue.lo] Error 1
The offending line of RValue.cc is:

BaseType **argv = new (BaseType *[argc + 1]);
Unfortunately, that "*[argc + 1]" wouldn't mean a great deal in C, and I
suspect it's not going to be in many C++ books, because it seems likely
that it's not portable C++, but rather a g++ extension of some sort?
Moreover, it seems a difficult thing to google for due to it being a bunch
of special symbols, rather than keywords...

Anyway, I've tried a few things to get this to build with xlC_r, including
cranking up the permissiveness of what language extensions xlC_r accepts,
but it doesn't seem to be helping.

Does anyone have any suggestions for me?

Thanks!

[Neelesh Bodas]

There are chances that I am wrong, but still I give a try -

Dan Stromberg wrote:

Hi folks.
BaseType **argv = new (BaseType *[argc + 1]);

If you want to allocate the memory using the C++ keyword "new", then
the correct syntax is :

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

// note that absence of ( )

This will compile on AIX 5.1 with xlC version 6

When you are putting parentheses after new, you are (most likely)
calling operator new(), and not doing a proper construction using new
operator.

Hope this helps.

[Victor Bazarov]

Dan Stromberg wrote:

[..]
The error I get with xlC_r is:

xlC_r -qlanglvl=extend ed -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
"RValue.cc" , line 176.39: 1540-0016 (S) The expression must be an integral constant expression.
gmake[2]: *** [RValue.lo] Error 1
The offending line of RValue.cc is:

BaseType **argv = new (BaseType *[argc + 1]);
[..]

Have you tried dropping the parentheses? As in

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

....

Of course, to know whether it's the right thing to do or not, I'd need to
see more code, especially how you use 'argv', but you could start there...

V

[Dan Stromberg]

On Tue, 15 Nov 2005 11:49:44 -0800, Neelesh Bodas wrote:

There are chances that I am wrong, but still I give a try -

Dan Stromberg wrote:

Hi folks.
BaseType **argv = new (BaseType *[argc + 1]);

If you want to allocate the memory using the C++ keyword "new", then
the correct syntax is :

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

// note that absence of ( )

This will compile on AIX 5.1 with xlC version 6

When you are putting parentheses after new, you are (most likely)
calling operator new(), and not doing a proper construction using new
operator.

Hope this helps.

Neelesh and Victor - Removing the parens worked great - thanks much.

I cleared a few more hurdles on my own, but now I've come upon another one
I'd like to get group advice on, hopefully.

Specifically, I'm getting:

xlC_r -I/usr/local/include -qlanglvl=extend ed:redefmac -D__inline= -DHAVE_CONFIG_H -I. -I. -I. -I./lnetcdf -I./fortran -Df2cFortran -DLOCAL -DDEFAULT_BASETY
PE_FACTORY -I/usr/local/include/libdap -O2 -c -o NCSequence.o `test -f 'NCSequence.cc' || echo './'`NCSequence.cc
"NCSequence.cc" , line 310.5: 1540-0130 (S) "Constructor::V ars_iter" is not declared.

....on the line:

Constructor::Va rs_iter field = var_begin();

....and I'm not recalling anything about that sort of Constructor keyword
in C++. I'm hazy on this, but I'd sort of thought C++ constructors were at
least somewhat like in python, where you just use the name of the class.

Is this "Constructo r::" thing a g++-ism? If so, is there a good
equivalent in portable C++?

Thanks!

[Mike Wahler]

"Dan Stromberg" <st******@dcs.n ac.uci.edu> wrote in message
news:pa******** *************** *****@dcs.nac.u ci.edu...

On Tue, 15 Nov 2005 11:49:44 -0800, Neelesh Bodas wrote:

There are chances that I am wrong, but still I give a try -

Dan Stromberg wrote:

Hi folks.
BaseType **argv = new (BaseType *[argc + 1]);
If you want to allocate the memory using the C++ keyword "new", then
the correct syntax is :

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

// note that absence of ( )

This will compile on AIX 5.1 with xlC version 6

When you are putting parentheses after new, you are (most likely)
calling operator new(), and not doing a proper construction using new
operator.

Hope this helps.

Neelesh and Victor - Removing the parens worked great - thanks much.

I cleared a few more hurdles on my own, but now I've come upon another one
I'd like to get group advice on, hopefully.

Specifically, I'm getting:

xlC_r -I/usr/local/include -qlanglvl=extend ed:redefmac -D__inline= -DHAVE_CONFIG_H
-I. -I. -I. -I./lnetcdf -I./fortran -Df2cFortran -DLOCAL -DDEFAULT_BASETY
PE_FACTORY -I/usr/local/include/libdap -O2 -c -o NCSequence.o `test -f
'NCSequence.cc' || echo './'`NCSequence.cc
"NCSequence.cc" , line 310.5: 1540-0130 (S) "Constructor::V ars_iter" is not
declared.

...on the line:

Constructor::Va rs_iter field = var_begin();

...and I'm not recalling anything about that sort of Constructor keyword
in C++.

In C++ the word 'constructor' (uppercase or not) is not
a keyword. Your expression:

Constructor::Va rs_iter field = var_begin();

... implies that the name 'Constructor' is either a
class name or the name of a namespace, and that the
name 'Vars_iter' is a class member or member of a namespace.
A class member function's "name" is that of its
class. (Technically constructors don't have names, its
just that the syntax makes it look that way).

class C
{
public:
C(){} /* constructor */
};

A constructor is not called directly, it's automatically
called at object creation.

C c; /* creates type 'C' object, calls C::C() */

C(); /* creates a type 'C' object, calls C::C(),
then the object is destroyed (calls C::~C())
(i.e. this creates a 'temporary' object) */

(If you don't define a constructor or destructor, the
compiler will synthesize default ones).
I'm hazy on this, but I'd sort of thought C++ constructors were at
least somewhat like in python, where you just use the name of the class.
I don't know Python, but yes, they have the same 'name'.
But you don't call them directly.

Is this "Constructo r::" thing a g++-ism?

Constructor syntax and semantics are part of standard C++.

-Mike