C++-Compiler for VxWorks
sch...@ibm.net
Hence, I am looking for a reliable C++ Compiler package for
VxWorks V 5.2.
I would appreciate any comments about experiences.
Thanks
Kai
Earl Mitchell
>We have to develop a complex system using VxWorks.
>Hence, I am looking for a reliable C++ Compiler package for VxWorks V 5.2.
BWAAAHAHAHAHAH !!!!
There is no such thing as a reliable C++ compiler -- not yet anyway.
Your best bet is g++ which is free, and for the *reliable* portion get
support from Cygnus which ain't free. They may have a debugger also
but be ready to spend BIG bucks, and be ready to rewrite some code later
when they rewrite C++ compilers to conform to ANSI C++ standard.
PS: Was it a complex system before or after you used C++. ;-)
Rohan LENARD
Earl Mitchell <k...@leland.Stanford.EDU> wrote:
>Your best bet is g++ which is free, and for the *reliable* portion get
>support from Cygnus which ain't free. They may have a debugger also
>but be ready to spend BIG bucks, and be ready to rewrite some code later
>when they rewrite C++ compilers to conform to ANSI C++ standard.
For any commercial development support from cygnus is *really* cheap.
They do have a debugger - a derivative of gdb-4.14. It also includes
the features the one supplied with VxWorks has (tk/tcl).
Of course there also is ObjectCentre (cfront based).
I'd be very surprised if you need to rewrite *any* code. Sounds like you
need to follow the standardisation process more closely.
Regards,
Rohan
--
----------------------------------------------------------------------------
r...@iassf.easams.com.au | All quotes can be attributed to my automated quote
Rohan Lenard | writing tool. Yours for just $19.95; and if you
+61-2-367-4555 | call now you'll get a free set of steak knives ...
Earl Mitchell
Rohan LENARD <r...@f111.iassf.easams.com.au> wrote:
>I'd be very surprised if you need to rewrite *any* code. Sounds like you
Surprise!!!
>need to follow the standardisation process more closely.
Yeah right .. read on .. oh great know it all
Several existing C++ compilers provide features which are
NOT supplied by other vendors obviously if these features do not make
it into the standard you are out of luck (unless you can get away
with non-ANSI code).
Several compilers implement class hierarchies differently (e.g. compare
the implementations of Microsoft's iostream stuff with GNU). And don't
even get me started on the different implementations of templates out
there.
Also any *serious* C++ programmer knows that there are several areas
of ambiguity NOT covered by the ARM in which compiler designers were
free to implement behaviors as they saw fit. The ANSI standard will
remove ambiguity in most of those areas, thus forcing some vendors to
change their compilers to comply. If you stick to the simple stuff you
are probably safe but it you use a lot of complex constucts or have
very complex class libaries you may be hosed.
Feel free to shit your pants now.
Earl Mitchell
Rohan LENARD <r...@f111.iassf.easams.com.au> wrote:
>Well the GNU compiler implements ansi and non-ansi features and any non-ansi
>feature can be turned off with -ansi -pedantic. If you're compiler doesn't
>allow this then I suggest getting a new compiler.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Try compiling your GNU code with ObjectCenter or SparcWorks compiler.
Last time I tried neither mode worked. I had to rewrite code to get
around this. Strike 1.
>The GNU libg++ has the ANSI definition of iostream. If Microsloth doesn't
>get yourself a copy of libg++.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Which won't work with Macrohard C++ compiler without MAJOR hacking. For
example, both have defined some manipulators which the other doesn't, and
some manipulators are implemented differently (i.e. different args). That's
just the tip of the iceberg with Macrohard C++ compiler problems.
So forget using Macrohard's Visual C++ environment with GNU code without
changes. Strike 2.
>Templates are actually quite easy to get around once you understand the
>models the different compilers use.
For most real time applications templates are practically a joke, most
people I know avoid using them due to code size explosion problems (i.e.
most embedded applications have limited memory). Your excessive use of
templates says a lot. ;-) But ignoring this issue here's a simple test.
Try compiling the standard template library with the GNU compiler. The
standard template library is now part of the ANSI standard. If you can
get it to compile without changing code your a better man than me.
Strike 3.
>Who codes to the ARM ? There's been a draft working paper for a *long* time.
>If you're developing in C++ you should be involved in the process of
>developing the final standard otherwise you will be surprised when it
>is released.
Who codes to a "draft"?
Especially one that most compilers don't support yet.
Final comment: If you stick to the simple stuff you probably won't have
to change much code but most C++ programmers don't like to stick to the
simple stuff (e.g. the heavy use of templates). If you don't care about
ANSI compatibility your ok also. However, once you venture out to use
third party tools and class libraries all bets are of and you'll become
interested in ANSI compatibility very quickly. And don't forget CORBA.
Rohan LENARD
Earl Mitchell <k...@leland.Stanford.EDU> wrote:
>In article <3s8egq$7...@f111.iassf.easams.com.au>,
>Rohan LENARD <r...@f111.iassf.easams.com.au> wrote:
>
>>Well the GNU compiler implements ansi and non-ansi features and any non-ansi
>>feature can be turned off with -ansi -pedantic. If you're compiler doesn't
>>allow this then I suggest getting a new compiler.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>Try compiling your GNU code with ObjectCenter or SparcWorks compiler.
>Last time I tried neither mode worked. I had to rewrite code to get
>around this. Strike 1.
I have and it works. Maybe your problem lies with not having coding standards
and not having analysed what the different compilers are capable of.
>
>>The GNU libg++ has the ANSI definition of iostream. If Microsloth doesn't
>>get yourself a copy of libg++.
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
>Which won't work with Macrohard C++ compiler without MAJOR hacking. For
>example, both have defined some manipulators which the other doesn't, and
>some manipulators are implemented differently (i.e. different args). That's
>just the tip of the iceberg with Macrohard C++ compiler problems.
>So forget using Macrohard's Visual C++ environment with GNU code without
>changes. Strike 2.
If you want to use a compiler which does support common sorts of C++ code
(which libg++ is pretty indicative of) more fool you.
>
>>Templates are actually quite easy to get around once you understand the
>>models the different compilers use.
>
>For most real time applications templates are practically a joke, most
>people I know avoid using them due to code size explosion problems (i.e.
>most embedded applications have limited memory). Your excessive use of
>templates says a lot. ;-) But ignoring this issue here's a simple test.
>Try compiling the standard template library with the GNU compiler. The
>standard template library is now part of the ANSI standard. If you can
>get it to compile without changing code your a better man than me.
>Strike 3.
Trying to start a flame war :-).
Before we started using templates we did a very thorough analysis of the
template state of the art and determined what we could do to get minimal
code bloat. Naive use of template is bound to ensure code bloat.
Our *embedded* applications makes extensive use of templates because they
are the *best* way to do what we want. We don't believe they use much
more memory than other programming methods for what we require. The bigger
advantage is the inherant type safety we gain. The proof of this is that
we were able to integrate about 7 man years worth of software development
in less than a man month.
>
>>Who codes to the ARM ? There's been a draft working paper for a *long* time.
>>If you're developing in C++ you should be involved in the process of
>>developing the final standard otherwise you will be surprised when it
>>is released.
>
>Who codes to a "draft"?
I think you missed the point. You need to have your own "standard" which
is written and rewritten as the standard changes. The only advanced features
we've ever had problems with are those where we developed our own method
of doing something (say RTTI) which only worked because of knowledge of
the internals of the compiler. When we reverted to a more portable version
we had no problems.
I guess we both agree on something. You can't blindly start using C++
(or any modern HLL) and expect things to work without difficulties.
Charles Key
In article <3sqb0d$o...@f111.iassf.easams.com.au>,
Rohan LENARD <r...@f111.iassf.easams.com.au> wrote:
>Before we started using templates we did a very thorough analysis of the
>template state of the art and determined what we could do to get minimal
>code bloat.
I suspect that many would be interested in the results of your analysis.
Are you able to post them or share them in some other way?
___________________________________________________________________________
Charles Key
Diasonics Ultrasound k...@diasonx.com