Honest opinions requested

Bill at Sierra Design wrote:

I agree with (I think) John. I haven’t yet seen a GNU C++ compiler that did
everything right.

That’s also true for all the other C++ compilers
:slight_smile:

I.E. exceptions, RTTI

That may be the situation today. Is RTTI part of
the ANSI C++ standard ?

Armin


and such.

Armin Steinhoff <A-Steinhoff@web_.de> wrote in message
news:3A539392.A7844567@web_.de…

Hello John,

John Bowen wrote:

[ clip …]

I don’t doubt that RTP is a good OS. From what I’ve seen it’s exactly
as
advertised. But I’m really hesitant about dropping money on compilers
and
IDEs.

I don’t see any problems with the GNU compilers
… you can absolutely flawless recompile huge
software packages like XFree86 and others. And
regarding IDEs, the door is open for ports of
different open source IDEs like GDE (done), vdk
builder (done), SourceNavigator (done from others)
and e.g. KDEvelop a.s.o … and if the base
libraries are available it is really just a
recompile!

That’s exactly our experiences …

When the latest ANSI C++ standard was issued (exceptions, RTTI and
such) a dozen companies claimed compliance, but of course after
thousands of
dollars and countless lives lost, we abandoned them and licked our
wounds.
Needless to say, I am always skeptical now.

I don’t believe that this is an issue for QNX RTP.

Armin

Armin Steinhoff wrote:

Bill at Sierra Design wrote:

I agree with (I think) John. I haven’t yet seen a GNU C++ compiler that did
everything right.

That’s also true for all the other C++ compilers
:slight_smile:

I.E. exceptions, RTTI

That may be the situation today.

The GNU compiler collection GCC 3.0 is annouced
for Q1/2001 … RTTI and
exceptions seems not be an issue of that release.

Armin


PS.:

Is RTTI part of the ANSI C++ standard ?

it is part of the ISO C++ standard .

Armin Steinhoff <A-Steinhoff@web_.de> wrote in message
news:3A539F55.AA8772F7@web_.de…

Bill at Sierra Design wrote:

I agree with (I think) John. I haven’t yet seen a GNU C++ compiler that
did
everything right.

That’s also true for all the other C++ compilers
Maybe. But I had very little complaints about the Watcom compilers. The

defunct V11.0 actually did everything right. It just couldn’t produce
thread safe programs. But I blame QNX4 for that more than the compiler.
And if ANYONE ever tries to claim that QNX4 is even remotely thread safe, I
want them to explain why ‘errno’ is not. And how the hell does anyone
program around errno not being thread safe.

The only other problem I remember with V11.0 was that lines like:
char * cp, c;
were not valid because you were trying to declair two different data types
in the same declairation (a char * and a char). I remember that QSSL was
not very willing to change all of their header files to co-operate. BUT, I
don’t think that the final C++ standard has a problem with mixing these two
data types, even at the highest warning level. (OK so I am now about to go
try it).

I.E. exceptions, RTTI

That may be the situation today. Is RTTI part of
the ANSI C++ standard ?

Yes. I belive that the final standard (as opposed to a draft standard) has
been released for a while and RTTI is part of it.

P.S. Of course “final” is only final till someone comes up with new changes.

P.P.S Since I’m rambeling on here, I was amused at how many new C++
keywords were added to the very last draft of the standard. I was amused
becuase 10 years ago I wrote to the C++ commitee to suggest a “mustuse” key
word. My intent was twofold. 1. Any routine that allocated a resource,
like memory, and returned a pointer/reference to that resource would want to
make sure that the caller of that routine saved that pointer. Otherwise
it’s like:
char * getBuffer( int size )
{
return malloc( size );
}
and the caller calls:
void ( )
{
getBuffer( 1000000 );
}
You’ve got a pretty big memory leak there!

The second purpose is one of my biggest pet peeves. I write a lot of low
level routines that get called by other applications programmers. Almost
every one of them looks something like this:

enum RETURD_CODE
{
OK,
REASON1,
REASON2, // etc.
};

RETURN_CODE doSomething()
{
if( it finished successfully )
return OK;
if( this went wrong )
return REASON1;
// etc.
}

and inevitibly someone will code something like:

void fn()
{
doSomething();
doSomethingElse();
}
and they’ll come to me and complain “Why didn’t your doSomethingElse()
routine work”. To which I must reply “Because the arguments to passed to
the first routine wern’t valid and you didn’t even test them. Had you
tested the return code from doSomething() it would have told you exactly
what was invalid about it.”

By using the “mustuse” keyword the caller must assign the return value of a
function to something (or at the very least test it). I.E.
mustuse char * getBuffer( int size )
{
return malloc( size );
}
or
mustuse RETURN_CODE doSomething()
{
if( it finished successfully )
return OK;
if( this went wrong )
return REASON1;
// etc.
}

It would be of the same class as “const” or “volatile” but could only be
applied to function calls.

Bottom line was I was told that they didn’t want to “polute” the keyword
namespace!

The second purpose is one of my biggest pet peeves. I write a lot of low
level routines that get called by other applications programmers. Almost
every one of them looks something like this:

enum RETURD_CODE
{
OK,
REASON1,
REASON2, // etc.
};

RETURN_CODE doSomething()
{
if( it finished successfully )
return OK;
if( this went wrong )
return REASON1;
// etc.
}

and inevitibly someone will code something like:

void fn()
{
doSomething();
doSomethingElse();
}
and they’ll come to me and complain “Why didn’t your doSomethingElse()
routine work”. To which I must reply “Because the arguments to passed to
the first routine wern’t valid and you didn’t even test them. Had you
tested the return code from doSomething() it would have told you exactly
what was invalid about it.”

flint detects this condition.

By using the “mustuse” keyword the caller must assign the return value of
a
function to something (or at the very least test it). I.E.
mustuse char * getBuffer( int size )
{
return malloc( size );
}
or
mustuse RETURN_CODE doSomething()
{
if( it finished successfully )
return OK;
if( this went wrong )
return REASON1;
// etc.
}

It would be of the same class as “const” or “volatile” but could only be
applied to function calls.

Bottom line was I was told that they didn’t want to “polute” the keyword
namespace!

Bill at Sierra Design wrote:

Armin Steinhoff <A-Steinhoff@web_.de> wrote in message
news:3A539F55.AA8772F7@web_.de…


Bill at Sierra Design wrote:

I agree with (I think) John. I haven’t yet seen a GNU C++ compiler that
did
everything right.

That’s also true for all the other C++ compilers
Maybe. But I had very little complaints about the Watcom compilers.

Hmm … there are lots of problems with the C++
part of the Watcom compiler.
It was completely inpossible to recompile ACE/TAO
… it works now with qcc.

The
defunct V11.0 actually did everything right. It just couldn’t produce
thread safe programs. But I blame QNX4 for that more than the compiler.
And if ANYONE ever tries to claim that QNX4 is even remotely thread safe, I
want them to explain why ‘errno’ is not. And how the hell does anyone
program around errno not being thread safe.

OK … consider QNX4 as history :slight_smile: V11.0 was never
relaesed.

[ clip …]

I.E. exceptions, RTTI

That may be the situation today. Is RTTI part of
the ANSI C++ standard ?

Yes. I belive that the final standard (as opposed to a draft standard) has
been released for a while and RTTI is part of it.

P.S. Of course “final” is only final till someone comes up with new changes.

P.P.S Since I’m rambeling on here, I was amused at how many new C++
keywords were added to the very last draft of the standard.

Seems to be a ‘floating standard’ … so its hard
to justify the states of implementations of
compilers.

I was amused
becuase 10 years ago I wrote to the C++ commitee to suggest a “mustuse” key
word. My intent was twofold. 1. Any routine that allocated a resource,
like memory, and returned a pointer/reference to that resource would want to
make sure that the caller of that routine saved that pointer. Otherwise
it’s like:
char * getBuffer( int size )
{
return malloc( size );
}
and the caller calls:
void ( )
{
getBuffer( 1000000 );
}
You’ve got a pretty big memory leak there!

The pointer concept of C/C++ is very dangerous. C
was designed to be a system development language.
IMHO … Ada doesn’t have such problems … or?.

The second purpose is one of my biggest pet peeves. I write a lot of low
level routines that get called by other applications programmers. Almost
every one of them looks something like this:

enum RETURD_CODE
{
OK,
REASON1,
REASON2, // etc.
};

RETURN_CODE doSomething()
{
if( it finished successfully )
return OK;
if( this went wrong )
return REASON1;
// etc.
}

and inevitibly someone will code something like:

void fn()
{
doSomething();
doSomethingElse();
}
and they’ll come to me and complain “Why didn’t your doSomethingElse()
routine work”. To which I must reply “Because the arguments to passed to
the first routine wern’t valid and you didn’t even test them. Had you
tested the return code from doSomething() it would have told you exactly
what was invalid about it.”

By using the “mustuse” keyword the caller must assign the return value of a
function to something (or at the very least test it). I.E.
mustuse char * getBuffer( int size )
{
return malloc( size );
}
or
mustuse RETURN_CODE doSomething()
{
if( it finished successfully )
return OK;
if( this went wrong )
return REASON1;
// etc.
}

It would be of the same class as “const” or “volatile” but could only be
applied to function calls.

Interesting …

Bottom line was I was told that they didn’t want to “polute” the keyword
namespace!

That’s life :slight_smile:

Armin

Humm…



John Bowen wrote:

Just to scare you a little, I know of several NT based systems used on the
Internation Space Station…

This may explain a couple of things…! >:)

Miguel



-Warren “I wouldn’t get on a Microschlock powered spacecraft” Peece