Topic: C and EC++
Author: stewart.brodie@ntlworld.com ("Stewart Brodie")
Date: Fri, 20 Jun 2003 01:49:45 +0000 (UTC) Raw View
Dave Hansen wrote:
> On Thu, 15 May 2003 16:45:13 +0000 (UTC), jackklein@spamcop.net (Jack
> Klein) wrote:
>
> [...]
>>
>> Admittedly MISRA C has it faults. Do you know of a better
>> alternative?
>
> AFAICT, every problem that MISRA C attempts to solve can be better and
> more completely addressed by establishing (and enforcing) a lint
> policy and linting your d*mn code.
>
> IMHO, of course. That's not to say there's nothing useful in MISRA C.
Regards,
I don't believe that the expertise exists within many organisations to
produce, let alone enforce, such a policy. That is where I think the MISRA
guidelines are useful - to indicate areas where problems or unexpected
behaviour may occur.
I've had to deal with a coding standard that forbade all pointer arithmetic
(except pre- and post-increment/decrement) because "our C programmers are
confused by pointer arithmetic". Even worse, it recommended that the best
way to move pointer p along n items in an array is to cast the pointer to
int, add n*sizeof(*p), then cast it back to a pointer again! In the face of
such total stupidity, any external coding guidelines that a document such as
the MISRA guide can provide to help stop that sort of thing is helpful.
Perhaps that's the tactic I should have employed to get that recommendation
removed.
Perhaps my view on the lack of expertise is unjustified. Perhaps I've just
been unlucky in that nearly all the code I've seen from third party
suppliers and other programmers within the places I have worked is, frankly,
utter crap in several respects: buggy, badly thought out, badly organised
and written by people who didn't have a clue what they were doing.
--Stewart
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: nagle@animats.com (John Nagle)
Date: Fri, 20 Jun 2003 19:34:10 +0000 (UTC) Raw View
Hans Aberg wrote:
> It strikes me that the features of EC++ (embedded C++) might be put into
> the development of the C language. That is, essentially the stuff that
> does not create runtime overheads. Then C++ can focus on developing its
> runtime stuff without having to bother about EC++ concerns.
For embedded work, a big problem is that the STL tends to assume
that "new" is always a permitted operation. For much embedded work,
memory is preallocated. The STL has many facilities that would
be useful on fixed-sized collections, but you can't use it that
way. Yes, you can play games with allocators, but that isn't
a good way to go when it has to work.
Exceptions, on the other hand, are useful in real-time work.
If something goes badly wrong, having control reach an exception
handler where emergency action can be taken is very desirable.
John Nagle
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: petebecker@acm.org (Pete Becker)
Date: Fri, 20 Jun 2003 21:48:47 +0000 (UTC) Raw View
John Nagle wrote:
>
> Hans Aberg wrote:
> > It strikes me that the features of EC++ (embedded C++) might be put into
> > the development of the C language. That is, essentially the stuff that
> > does not create runtime overheads. Then C++ can focus on developing its
> > runtime stuff without having to bother about EC++ concerns.
>
> For embedded work, a big problem is that the STL tends to assume
> that "new" is always a permitted operation.
STL is not part of EC++.
--
Pete Becker
Dinkumware, Ltd. (http://www.dinkumware.com)
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: francis.glassborow@ntlworld.com (Francis Glassborow)
Date: Mon, 19 May 2003 19:50:08 +0000 (UTC) Raw View
In message <MRfhHNA700x+EA4V@phaedsys.demon.co.uk>, Chris Hills
<chris@phaedsys.org> writes
>There is now a second edition of MISRA-C due to be released in
>July/august. This has had input (as did the first version ) from several
>members of the ISO-C committee people.
You sure about that Chris? Certainly the general reaction from the then
C Panel of the BSI was that they did not want to be involved (because in
their opinions it had little to do with the C Standard)
--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow ACCU
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: chris@phaedsys.org (Chris Hills)
Date: Wed, 21 May 2003 19:27:06 +0000 (UTC) Raw View
In article <tlmu9DBw1Ry+Ewmt@robinton.demon.co.uk>, Francis Glassborow
<francis.glassborow@ntlworld.com> writes
>In message <MRfhHNA700x+EA4V@phaedsys.demon.co.uk>, Chris Hills
><chris@phaedsys.org> writes
>>There is now a second edition of MISRA-C due to be released in
>>July/august. This has had input (as did the first version ) from several
>>members of the ISO-C committee people.
>
>You sure about that Chris? Certainly the general reaction from the then
>C Panel of the BSI was that they did not want to be involved (because in
>their opinions it had little to do with the C Standard)
Derek was cited as being involved in the first one (I am sure there were
some others). There are several current panel members working at the
second one.
Why is it nothing to do with the C standard? Mind you most C compilers
have little to do with the standard these days. Most are still C90
Regards
Chris
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: francis.glassborow@ntlworld.com (Francis Glassborow)
Date: Wed, 21 May 2003 21:04:06 +0000 (UTC) Raw View
In message <DzlCvXAc9my+EAiq@phaedsys.demon.co.uk>, Chris Hills
<chris@phaedsys.org> writes
>>You sure about that Chris? Certainly the general reaction from the then
>>C Panel of the BSI was that they did not want to be involved (because in
>>their opinions it had little to do with the C Standard)
>
>Derek was cited as being involved in the first one (I am sure there were
>some others).
Involved was probably more like he was contacted and declined to
participate, but maybe I entirely miss-remember.
>There are several current panel members working at the
>second one.
The fact that people happen to work on both committees actually says
little. How many of those people attended the recent WG14 meeting? How
many participate here? There is a little more to being and ISO-C
committee person (or at least implied) than just being a recent attendee
at a BSI Panel meeting
>
>Why is it nothing to do with the C standard? Mind you most C compilers
>have little to do with the standard these days. Most are still C90
Because MISRA is about coding guidelines (or even coding standards)
which most of us believe to be something very different (though also
highly desirable) to a language standard.
--
ACCU Spring Conference 2003 April 2-5
The Conference you should not have missed
ACCU Spring Conference 2004 Late April
Francis Glassborow ACCU
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: remove.haberg@matematik.su.se (Hans Aberg)
Date: Wed, 14 May 2003 17:22:46 +0000 (UTC) Raw View
In article <3EC1486B.5020708@null.net>, DAGwyn@null.net ("Douglas A.
Gwyn") wrote:
>... The main problem was that just as "C with classes"
>kept evolving until it became C++, Standard C with modest support
>for classes (such as could be cheaply implemented) tends to not have
>quite enough features to satisfy users. Some of C++'s more
>attractive features (templates, namespaces) weren't settled when
>we first looked at adding classes to Standard C, and those may
>deserve revisiting now that they are stable. But very far along
>that path and one might as well just specify C++ anyway.
The problem that embedded people have with C++ seems to be certain
features like exceptions, and certain dynamic features that might not be
needed in their programming.
That might work will in an enhanced C, which would still not be a path
towards a specification of a C++ standard.
Hans Aberg * Anti-spam: remove "remove." from email address.
* Email: Hans Aberg <remove.haberg@member.ams.org>
* Home Page: <http://www.math.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: DAGwyn@null.net ("Douglas A. Gwyn")
Date: Thu, 15 May 2003 02:02:24 +0000 (UTC) Raw View
Hans Aberg wrote:
> The problem that embedded people have with C++ seems to be certain
> features like exceptions, and certain dynamic features that might not be
> needed in their programming.
That's too bad. In my embedded-systems work in C, I find it
essential to have a really good dynamic memory allocator
and a reasonable nested exception handling system.
If MISRA C is any indication, some of the people drawing up
specs for subset languages for embedded-system use are
relatively clueless. (My opinion, not necessarily shared
by others on the C standards committee.)
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: pjp@dinkumware.com ("P.J. Plauger")
Date: Thu, 15 May 2003 16:45:02 +0000 (UTC) Raw View
"Hans Aberg" <remove.haberg@matematik.su.se> wrote in message
news:remove.haberg-1405031846280001@du136-86.ppp.su-anst.tninet.se...
> In article <3EC1486B.5020708@null.net>, DAGwyn@null.net ("Douglas A.
> Gwyn") wrote:
>
> >... The main problem was that just as "C with classes"
> >kept evolving until it became C++, Standard C with modest support
> >for classes (such as could be cheaply implemented) tends to not have
> >quite enough features to satisfy users. Some of C++'s more
> >attractive features (templates, namespaces) weren't settled when
> >we first looked at adding classes to Standard C, and those may
> >deserve revisiting now that they are stable. But very far along
> >that path and one might as well just specify C++ anyway.
>
> The problem that embedded people have with C++ seems to be certain
> features like exceptions, and certain dynamic features that might not be
> needed in their programming.
>
> That might work will in an enhanced C, which would still not be a path
> towards a specification of a C++ standard.
Your points are valid, but I think EC++ is a settled issue. The EC++
Technical Committee has been in maintenance mode for years now. Most
EC++ compilers I know of are full C++ compilers (modulo the usual
missing bits for all but those with the EDG front end) with some
features possibly turned off. Most of the benefit of EC++ actually
comes from the library, which has a significantly smaller footprint
for many programs compared to the full C++ library.
Thus, there's no pressure to change the EC++ dialect, library, or
currently available compilers. They work and they've established a
niche in the embedded community.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: jackklein@spamcop.net (Jack Klein)
Date: Thu, 15 May 2003 16:45:13 +0000 (UTC) Raw View
On Thu, 15 May 2003 02:02:24 +0000 (UTC), DAGwyn@null.net ("Douglas A.
Gwyn") wrote in comp.std.c:
> Hans Aberg wrote:
> > The problem that embedded people have with C++ seems to be certain
> > features like exceptions, and certain dynamic features that might not be
> > needed in their programming.
>
> That's too bad. In my embedded-systems work in C, I find it
> essential to have a really good dynamic memory allocator
> and a reasonable nested exception handling system.
>
> If MISRA C is any indication, some of the people drawing up
> specs for subset languages for embedded-system use are
> relatively clueless. (My opinion, not necessarily shared
> by others on the C standards committee.)
Admittedly MISRA C has it faults. Do you know of a better
alternative?
--
Jack Klein
Home: http://JK-Technology.Com
FAQs for
comp.lang.c http://www.eskimo.com/~scs/C-faq/top.html
comp.lang.c++ http://www.parashift.com/c++-faq-lite/
alt.comp.lang.learn.c-c++ ftp://snurse-l.org/pub/acllc-c++/faq
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: iddw@hotmail.com (Dave Hansen)
Date: Thu, 15 May 2003 22:29:29 +0000 (UTC) Raw View
On Thu, 15 May 2003 16:45:13 +0000 (UTC), jackklein@spamcop.net (Jack
Klein) wrote:
[...]
>
>Admittedly MISRA C has it faults. Do you know of a better
>alternative?
AFAICT, every problem that MISRA C attempts to solve can be better and
more completely addressed by establishing (and enforcing) a lint
policy and linting your d*mn code.
IMHO, of course.
That's not to say there's nothing useful in MISRA C. Regards,
-=Dave
--
Change is inevitable, progress is not.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: chris@phaedsys.org (Chris Hills)
Date: Mon, 19 May 2003 17:37:17 +0000 (UTC) Raw View
In article <3EC2D756.7080807@null.net>, Douglas A. Gwyn
<DAGwyn@null.net> writes
>Hans Aberg wrote:
>> The problem that embedded people have with C++ seems to be certain
>> features like exceptions, and certain dynamic features that might not be
>> needed in their programming.
>
>That's too bad. In my embedded-systems work in C, I find it
>essential to have a really good dynamic memory allocator
>and a reasonable nested exception handling system.
>
>If MISRA C is any indication, some of the people drawing up
>specs for subset languages for embedded-system use are
>relatively clueless. (My opinion, not necessarily shared
>by others on the C standards committee.)
There is now a second edition of MISRA-C due to be released in
July/august. This has had input (as did the first version ) from several
members of the ISO-C committee people.
/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\
\/\/\/\/\ Chris Hills Staffs England /\/\/\/\/\
/\/\/ chris@phaedsys.org www.phaedsys.org \/\/
\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/\/
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: remove.haberg@matematik.su.se (Hans Aberg)
Date: Tue, 13 May 2003 04:59:02 +0000 (UTC) Raw View
It strikes me that the features of EC++ (embedded C++) might be put into
the development of the C language. That is, essentially the stuff that
does not create runtime overheads. Then C++ can focus on developing its
runtime stuff without having to bother about EC++ concerns.
Is that development model something that has been considered?
Hans Aberg * Anti-spam: remove "remove." from email address.
* Email: Hans Aberg <remove.haberg@member.ams.org>
* Home Page: <http://www.math.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: pjp@dinkumware.com ("P.J. Plauger")
Date: Tue, 13 May 2003 15:11:18 +0000 (UTC) Raw View
"Hans Aberg" <remove.haberg@matematik.su.se> wrote in message
news:remove.haberg-1205031904330001@du129-86.ppp.su-anst.tninet.se...
> It strikes me that the features of EC++ (embedded C++) might be put into
> the development of the C language. That is, essentially the stuff that
> does not create runtime overheads. Then C++ can focus on developing its
> runtime stuff without having to bother about EC++ concerns.
>
> Is that development model something that has been considered?
At great length. The C committee spent a couple of years in the early
1990s exploring what parts of C++ could be retrofit to C. These were
very close to the primary feature set of EC++. In the end, WG14 chose
not to walk this path.
P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: remove.haberg@matematik.su.se (Hans Aberg)
Date: Tue, 13 May 2003 17:30:57 +0000 (UTC) Raw View
In article <3ec0ef56$0$22026$4c41069e@reader0.ash.ops.us.uu.net>,
pjp@dinkumware.com ("P.J. Plauger") wrote:
>> It strikes me that the features of EC++ (embedded C++) might be put into
>> the development of the C language.
...
>> Is that development model something that has been considered?
>At great length. The C committee spent a couple of years in the early
>1990s exploring what parts of C++ could be retrofit to C. These were
>very close to the primary feature set of EC++. In the end, WG14 chose
>not to walk this path.
Perhaps the picture has changed today, when there is a C++ standard. -- In
the early 1990ies, C++ barely existed compared to what it is now.
And one should have a better idea of what might be implemented efficiently
into a compiler, and what might be a part of EC++.
In addition, there was in the past some strong negativity against C++ by
some C devotees -- perhaps this played a role in not choosing this road in
the early 199ies!?
Hans Aberg * Anti-spam: remove "remove." from email address.
* Email: Hans Aberg <remove.haberg@member.ams.org>
* Home Page: <http://www.math.su.se/~haberg/>
* AMS member listing: <http://www.ams.org/cml/>
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: DAGwyn@null.net ("Douglas A. Gwyn")
Date: Tue, 13 May 2003 19:35:23 +0000 (UTC) Raw View
Hans Aberg wrote:
> In addition, there was in the past some strong negativity against C++ by
> some C devotees -- perhaps this played a role in not choosing this road in
> the early 199ies!?
Not especially. The main problem was that just as "C with classes"
kept evolving until it became C++, Standard C with modest support
for classes (such as could be cheaply implemented) tends to not have
quite enough features to satisfy users. Some of C++'s more
attractive features (templates, namespaces) weren't settled when
we first looked at adding classes to Standard C, and those may
deserve revisiting now that they are stable. But very far along
that path and one might as well just specify C++ anyway.
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]
Author: scjones@thor.sdrc.com (Larry Jones)
Date: Tue, 13 May 2003 20:14:44 +0000 (UTC) Raw View
Hans Aberg <remove.haberg@matematik.su.se> wrote:
>
> In addition, there was in the past some strong negativity against C++ by
> some C devotees -- perhaps this played a role in not choosing this road in
> the early 199ies!?
The main reason the committee chose not to persue it is because the
person who had been championing it (presenting proposals, collecting
feedback, etc.) decided to spend his time working on Java rather than C
and no one else took it over.
-Larry Jones
I think football is a sport the way ducks think hunting is a sport. -- Calvin
---
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std-c++@ncar.ucar.edu ]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html ]