Green Hills vs. Freescale CodeWarrior for ColdFire development

Hi folks.

I'm planning on developing an application for the ColdFire that uses pretty
cutting-edge C++ features (at least for the embedded world), such as partial
template specialization, Koenig lookup, heavy reliance on automatic template
parameter deduction, etc., but nothing that's not contained in the C++03 spec,
and certainly nothing that a contemporary desktop compiler (MS VC++ 2005 for
example) can't handle.

Does anyone have any idea how standards compliant the Freescale CodeWarrior
C++ compiler is? How about Green Hills C++? I've evaluated both, and it seems
that GHS is slightly behind the curve, but not by much; a little bit of
tweaking seems to make the compiler happy.

I'm concerned that I'm going down a design path relying on features that one
or both compilers cannot deliver.

Is there any objective study on how standards-compliant both compilers (and
libraries) really are?

-dr

In article <6or772l2g7vgmtrhfe43hpnr92der0ln7e@4ax.com>, Dave Rahardja
<ask@me.com> writes
>Hi folks.
>
>I'm planning on developing an application for the ColdFire that uses pretty
>cutting-edge C++ features (at least for the embedded world), such as partial
>template specialization, Koenig lookup, heavy reliance on automatic template
>parameter deduction, etc., but nothing that's not contained in the C++03 spec,
>and certainly nothing that a contemporary desktop compiler (MS VC++ 2005 for
>example) can't handle.


Perhaps you should look at EC++ 

-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

On Wed, 24 May 2006 12:07:08 +0100, Chris Hills <chris@phaedsys.org> wrote:

>In article <6or772l2g7vgmtrhfe43hpnr92der0ln7e@4ax.com>, Dave Rahardja
><ask@me.com> writes
>>Hi folks.
>>
>>I'm planning on developing an application for the ColdFire that uses pretty
>>cutting-edge C++ features (at least for the embedded world), such as partial
>>template specialization, Koenig lookup, heavy reliance on automatic template
>>parameter deduction, etc., but nothing that's not contained in the C++03 spec,
>>and certainly nothing that a contemporary desktop compiler (MS VC++ 2005 for
>>example) can't handle.
>
>
>Perhaps you should look at EC++ 

We did look at EC++, but decided that it's too restrictive. We are relying
heavily on templates, namespaces, virtual base classes, etc.

-dr

Dave Rahardja <ask@me.com> writes:

> On Wed, 24 May 2006 12:07:08 +0100, Chris Hills <chris@phaedsys.org> wrote:
>
>>In article <6or772l2g7vgmtrhfe43hpnr92der0ln7e@4ax.com>, Dave Rahardja
>><ask@me.com> writes
>>>Hi folks.
>>>
>>>I'm planning on developing an application for the ColdFire that
>>>uses pretty cutting-edge C++ features (at least for the embedded
>>>world), such as partial template specialization, Koenig lookup,
>>>heavy reliance on automatic template parameter deduction, etc., but
>>>nothing that's not contained in the C++03 spec, and certainly
>>>nothing that a contemporary desktop compiler (MS VC++ 2005 for
>>>example) can't handle.
>>
>>
>>Perhaps you should look at EC++ 
>
> We did look at EC++, but decided that it's too restrictive. We are relying
> heavily on templates, namespaces, virtual base classes, etc.

Is gcc (g++) no good for you? I don't know anything about its c++
conformance. But it *might* actually be better in this respect than a
commercial compiler that only targets the Coldfire. (Because all gcc's
many targets share the same front-end, work done there benefits all of
them).

-- 

John Devereux

On Wed, 24 May 2006 13:44:01 +0100, John Devereux
<jdREMOVE@THISdevereux.me.uk> wrote:

>Is gcc (g++) no good for you? I don't know anything about its c++
>conformance. But it *might* actually be better in this respect than a
>commercial compiler that only targets the Coldfire. (Because all gcc's
>many targets share the same front-end, work done there benefits all of
>them).

I love g++! The thing I like about CW (and GHS) is their project management
IDE, configuration management, and built-in debugger. I wouldn't mind going to
g++ at all if that's what it takes.

By the way, both GHS and CW target a wide variety of processors. You just have
to buy licenses to run the various back ends.

-dr

In article <87zmh7k2y6.fsf@cordelia.devereux.me.uk>, John Devereux
<jdREMOVE@THISdevereux.me.uk> writes
>Dave Rahardja <ask@me.com> writes:
>
>> On Wed, 24 May 2006 12:07:08 +0100, Chris Hills <chris@phaedsys.org> wrote:
>>
>>>In article <6or772l2g7vgmtrhfe43hpnr92der0ln7e@4ax.com>, Dave Rahardja
>>><ask@me.com> writes
>>>>Hi folks.
>>>>
>>>>I'm planning on developing an application for the ColdFire that
>>>>uses pretty cutting-edge C++ features (at least for the embedded
>>>>world), such as partial template specialization, Koenig lookup,
>>>>heavy reliance on automatic template parameter deduction, etc., but
>>>>nothing that's not contained in the C++03 spec, and certainly
>>>>nothing that a contemporary desktop compiler (MS VC++ 2005 for
>>>>example) can't handle.
>>>
>>>
>>>Perhaps you should look at EC++ 
>>
>> We did look at EC++, but decided that it's too restrictive. We are relying
>> heavily on templates, namespaces, virtual base classes, etc.
>
>Is gcc (g++) no good for you? I don't know anything about its c++
>conformance.

Not bad apparently though code density and optimisation etc are another
matter.

> But it *might* actually be better in this respect than a
>commercial compiler that only targets the Coldfire. (Because all gcc's
>many targets share the same front-end, work done there benefits all of
>them).

:-)  So how is that different to a lot of the commercial compilers?  

They use the same front end across many targets. In fact many of the
higher end compiler systems use the same front end.....


-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

In article <i1k872dj2ug66sbp8r3khj1p5rf260pbok@4ax.com>, Dave Rahardja
<ask@me.com> writes
>On Wed, 24 May 2006 12:07:08 +0100, Chris Hills <chris@phaedsys.org> wrote:
>
>>In article <6or772l2g7vgmtrhfe43hpnr92der0ln7e@4ax.com>, Dave Rahardja
>><ask@me.com> writes
>>>Hi folks.
>>>
>>>I'm planning on developing an application for the ColdFire that uses pretty
>>>cutting-edge C++ features (at least for the embedded world), such as partial
>>>template specialization, Koenig lookup, heavy reliance on automatic template
>>>parameter deduction, etc., but nothing that's not contained in the C++03 spec,
>>>and certainly nothing that a contemporary desktop compiler (MS VC++ 2005 for
>>>example) can't handle.
>>
>>
>>Perhaps you should look at EC++ 
>
>We did look at EC++, but decided that it's too restrictive. We are relying
>heavily on templates, namespaces, virtual base classes, etc.

EC++ or Embedded C++ was developed for Embedded systems. 

Various things were removed from C++ for safety. This is why the
majority of embedded C++ compilers implement EC++ not full C++.

Perhaps you should think on *WHY* they did this. I know that some of the
embedded C++ compilers use a front end that has full C++ compliance so
you can assume that it was probably not because they did not want to
implement full C++ . There are plenty of desktop compilers that do a
full implementation.

Perhaps you should reassess how you write your software.  You seem to
have it back to front. 

You are *planning* on developing an embedded application that will use
Coldfire and C++.  How do you know you will use all those features?
Unless you are porting the code from somewhere else? 

If you are not porting the code then you have jumped the gun by writung
the code first. 

I suggest you get one of the good compilers for Coldfire Either GHS or
Codewarrior and write your app according to the language features they
support. 





-- 
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills  Staffs  England     /\/\/\/\/
/\/\/ chris@phaedsys.org      www.phaedsys.org \/\/\
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/

Dave Rahardja wrote:
> On Wed, 24 May 2006 13:44:01 +0100, John Devereux
> <jdREMOVE@THISdevereux.me.uk> wrote:
> 
>> Is gcc (g++) no good for you? I don't know anything about its c++
>> conformance. But it *might* actually be better in this respect than a
>> commercial compiler that only targets the Coldfire. (Because all gcc's
>> many targets share the same front-end, work done there benefits all of
>> them).
> 
> I love g++! The thing I like about CW (and GHS) is their project management
> IDE, configuration management, and built-in debugger. I wouldn't mind going to
> g++ at all if that's what it takes.
> 

So perhaps what you're looking for is an IDE that works well with gcc. 
The biggie that springs to mind is Eclipse, but there are others that 
might be worth looking at (I haven't tried these much - if you think 
you've found something ideal, let us know):

https://libre2.adacore.com/gps/
www.jedit.org
http://bvrde.sourceforge.net/index.htm

There are other linux IDEs, such as KDevelop, which which work with 
cross-compilers.  There are also a number of good editors and gdb 
front-ends (such as DDD and Insight) if you don't need the integration. 
  And of course, there is always emacs :-)




> By the way, both GHS and CW target a wide variety of processors. You just have
> to buy licenses to run the various back ends.
> 
> -dr

On Wed, 24 May 2006 14:27:22 +0100, Chris Hills <chris@phaedsys.org> wrote:

>>>Perhaps you should look at EC++ 
>>
>>We did look at EC++, but decided that it's too restrictive. We are relying
>>heavily on templates, namespaces, virtual base classes, etc.
>
>EC++ or Embedded C++ was developed for Embedded systems. 
>
>Various things were removed from C++ for safety. This is why the
>majority of embedded C++ compilers implement EC++ not full C++.
>
>Perhaps you should think on *WHY* they did this. I know that some of the
>embedded C++ compilers use a front end that has full C++ compliance so
>you can assume that it was probably not because they did not want to
>implement full C++ . There are plenty of desktop compilers that do a
>full implementation.

EC++ is not without its critics, and I happen to be one of them. Features
removed from C++ can ADD safety to the software if used correctly, and I
intend to use those features to enhance code correctness.

I don't know why you assume that I have not thought about the pros and cons of
EC++ versus C++, given what I said in the post before yours. I understand the
motivation behind EC++; I just don't agree with it.


>Perhaps you should reassess how you write your software.  You seem to
>have it back to front. 

>You are *planning* on developing an embedded application that will use
>Coldfire and C++.  How do you know you will use all those features?
>Unless you are porting the code from somewhere else? 

>If you are not porting the code then you have jumped the gun by writung
>the code first. 

Thank you for that generous critique on my software engineering approach. Rest
assured that my choice of ColdFire and the full C++ language was based on
specific issues that made it the most appropriate solution for our project.


>I suggest you get one of the good compilers for Coldfire Either GHS or
>Codewarrior and write your app according to the language features they
>support. 

And we end up back at the original question: Which of the compilers would
support the largest subset of the C++ specification?

-dr

On 24 May 2006 15:40:57 +0200, David Brown
<david@westcontrol.removethisbit.com> wrote:

>So perhaps what you're looking for is an IDE that works well with gcc. 
>The biggie that springs to mind is Eclipse, but there are others that 
>might be worth looking at (I haven't tried these much - if you think 
>you've found something ideal, let us know):
>
>https://libre2.adacore.com/gps/
>www.jedit.org
>http://bvrde.sourceforge.net/index.htm
>
>There are other linux IDEs, such as KDevelop, which which work with 
>cross-compilers.  There are also a number of good editors and gdb 
>front-ends (such as DDD and Insight) if you don't need the integration. 
>  And of course, there is always emacs :-)

Hey now, that's interesting!

-dr