In article fsf@vx.cit.alcatel.fr, James Kanze
<james-albert.kanze@vx.cit.alcatel.fr> () writes:

>C++, as it stands today, has a weight problem; it *is* overly complex,
>often difficult to use, and certainly very difficult to teach.  I see
>EC++ as an attempt to address this problem.  I'm not sure it is the
>right solution; I've written enough classes using generic.h, for
>example, to really appreciate templates.  But the authors don't seem to
>be claiming it is a universal solution to the problem.  There may not
>even be one.  Every language I see which attempts to address the entire
>spectrum of programming seems heavy.
...
>In the end, if you want to program over the entire applications
>spectrum, you have a choice: learn many simple, elegant languages, or
>learn one monster (C++, or maybe Ada, or in earlier times PL/1).  I'm
>not sure which is the best way to go about it.  My impression is that
>EC++ is an attempt to split the difference.  It tries to be simple and
>elegant, but also be an almost strict subset of the monster.  I'm not
>sure it will work, but it is an experience worth trying.

Some thoughts in response:

1. 'Embedded' seems to imply a language that is more suitable to
programming for minimal resources and tight constraints than is C++.
But the features of C++ which imply additional run-time overhead are
all under the programmer's control and can be avoided in tight
situations, and features like templates can be used usefully even in
the smallest environments.   So I think EC++ would be *less* suitable
than C++ for embedded systems programming, and the adjective 'Embedded'
is a little misleading.

2. If indeed people are having trouble learning to use C++ in its
entirety, then teaching and using a subset of the languate may be a
reasonable response.  Such a subset could be 'standardized' by
convention, or by influential personalities.  (I am speaking of a true
subset, like "don't use templates, don't use abstract bases", etc.)  If
some of the standard library (like iostream) is too heavy to use in
embedded systems, an alternate library can be developed for that
environment.  All this can happen within C++; there's no need to call
this a different language.  The only thing I can identify as an
'advantage' of a separate language is that compiler vendors wouldn't be
bound by the C++ standard.  (An advantage to the vendors, maybe.)

3. I really don't think it's proper to appropriate the name of an
existing language to a new language unless the new one is either a
proper subset or superset of the old one, or you are the creator (or
responsible standards organization) of the existing language.  It seems
presumptious to me, and especially so when the new language lacks
features (yet is not a subset) of the existing one.  A new language
should have a new name.

Bill Linke
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

bs@research.att.com (Bjarne Stroustrup) writes:

|> kjNOSPAMray@ix.netcom.com (Ray) writes:
|>
|> > The C/C+ Users Journal had a description by P. J. Plauger of a new
|> > "standard" dialect of C++ called "Embedded C++". This language is [being?]
|> > specified by Advanced Data Controls Corp., Fujitsu, Hitachi, NEC, and
|> > Toshiba.
|> >
|> > You can read the Feb 97 issue for more information, but succinctly, the
|> > language is the draft C++ standard, without templates, without rtti,
|> > without exceptions, no STL, no multiple inheritance, no namespaces. It has
|> > non-templatized iostreams and string classes, and a subset of standard C
|> > library functions.
|> >
|> > How many people are interested in having their compiler vendor support EC++
|> > as an option?  Would you use it when you want to write efficient code,
|> > being wary of template bloat or compiler-generated behind-the-scenes code?
|>
|> Caveat: I have not seen the Feb 97 article; I base my comments on
|> information from the Dinkumware(tm) homepages describing Embedded C++.
|>
|> Describing a restricted version of C++ for use in demanding applications
|> in a particular area might very well be a good idea. In some contexts it
|> could be necessary. Defining an incompatible language with an incompatible
|> ``standard'' library is a bad idea.
|>
|> From what I have seen of Embedded C++, it is not a strict subset of (draft)
|> ISO C++ and its standard library, and it is not a language defined simply
|> by excluding features that would cause run-time overheads or problems with
|> predictability of run-time. Embedded C++ is even defined relative to a
|> two-year-old working paper draft that differs significantly from every
|> draft that succeeded it. This is against the spirit of ISO standardization.
    [...]

Two comments:

1. Language definitions take time.  I would imagine that it is the
intent of the authors of EC++ is to use a subset of the actual C++
standard that gets adopted.  The use of a two-year-old working paper
simply represents the lead time in their writing up of the proposal.

2. With regards to the library, no templates means that a lot will be
either missing or changed.  Frankly (and I think that this is what
Bjarne was getting at), I'd prefer missing, rather than different.  It
is hard to imagine a language without IO, however.  And the C++ standard
uses template classes for this.  However, the C++ standard also proposes
an interface (through typedef's for streambuf, ios, istream, ostream,
etc.) in which the use of templates is invisible to the user; if a
restricted subset of C++ offered this exact same interface, implemented
as classes, rather than typedef's to templates, I would consider this
still a strict subset, or close enough.  (This is slightly tricky; the
restricted subset should still declare that the forward declaration
"class istream" results in undefined behavior, for example, since a
program which uses it cannot compile in complete C++.)

This said: the only information I've seen concerning EC++ is what has
appeared here.  My above comments refer to how I would do it, supposing
I were doing it.

Also: I've seen enough of Plauger's work to feel certain that his
motivation is not just "to save effort for compiler and standard library
implementors."  I'm somewhat disappointed in this ad hominum attact.
Having had reason to appreciate Bjarne's tolerance of other people's
ideas in the past, I suspect that he didn't mean it as it sounds, and
this reaction is only due to his justified worry about splitting the C++
community.

C++, as it stands today, has a weight problem; it *is* overly complex,
often difficult to use, and certainly very difficult to teach.  I see
EC++ as an attempt to address this problem.  I'm not sure it is the
right solution; I've written enough classes using generic.h, for
example, to really appreciate templates.  But the authors don't seem to
be claiming it is a universal solution to the problem.  There may not
even be one.  Every language I see which attempts to address the entire
spectrum of programming seems heavy.  EC++ simply says that for a
specific subrange of applications, it may offer a solution.  (In many
ways, Java does the same thing, addressing a significantly different
subrange.)

In the end, if you want to program over the entire applications
spectrum, you have a choice: learn many simple, elegant languages, or
learn one monster (C++, or maybe Ada, or in earlier times PL/1).  I'm
not sure which is the best way to go about it.  My impression is that
EC++ is an attempt to split the difference.  It tries to be simple and
elegant, but also be an almost strict subset of the monster.  I'm not
sure it will work, but it is an experience worth trying.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Julian Pardoe <pardoej@lonnds.ml.com> writes:

|>  James Kanze wrote:
|>  >
|>  > "Paul D. DeRocco" <pderocco@ix.netcom.com> writes:
|>  >
|>  > |>  Multiple inheritance is free at
|>  > |>  run-time, except for the need to test for nil before converting between
|>  > |>  a derived pointer and a second base pointer.
|>  >
|>  > This depends.  Multiple inheritance without virtual base classes is very
|>  > limited in application.
|>
|>  Ooh, is this true?  I use MI all the time, not as a key feature of my
|>  design but because I use pattern where a class defines a "client" abstract
|>  base class.  Often my objects need to be clients of several kinds of object
|>  and so need to inherit from several "client" interfaces.

Actually, I think my statement may have been too strong.

In general, I would argue that if MI is being used, you want all
inheritance to be virtual, "just in case".  On the other hand, one of
the principal uses of MI *is* for inheriting multiple interfaces.  If
you apply a rule that an interface definition may not contain data (a
reasonable rule, IMHO), then you don't need to make the inheritance
virtual, since if the classes contain no data, in theory, it doesn't
matter how many times they occur in the hierarchy.  (In practice, of
course, you still only want one instance, since otherwise, you run the
risk of having conversion to the interface being ambiguous.  So maybe my
initial declaration was right anyway.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

[Note: this has drifted off-topic.  I've crossposted and redirected
followups to comp.lang.java.advocacy. --Moderator of comp.std.c++ (fjh).]

Paul D. DeRocco wrote:

> BTW, I recently got a book about Java, to see what it was like. I got to
> the sentence that said, "Java doesn't have destructors," and promptly
> closed the book. I won't be writing any EC++ or Java code, if I can
> avoid it.

And why is that a problem?

--

Nick

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Paul D. DeRocco wrote:
> The only thing that's costly at run-time is exception handling, and I
> believe most compilers already provide an option for turning it off.
> Personally, I think exception handling is so important that I'm not
> willing to give it up.

That depends on which compiler you use.  The Sun SPARC C++ compiler
incurs no speed penalty whatsoever.  In fact it has an option to
*disable* exceptions, rather than one to enable them.  It does have
a size penalty, though, due to the static function maps which tell
the exception mechanism what to destruct.

The interesting result of this is that a program that uses
exception handling is actually faster than the equivalent program
that does error checking with return values.  Sometimes the
difference can be enormous, especially for tight loops that call
functions.


--
___________________________________________________________________
Marcelo Cantos, Research Assistant          marcelo@mds.rmit.edu.au
Multimedia Database Systems Group              Tel: +61-3-9282-2497
723 Swanston St, Carlton VIC 3053, Australia   Fax: +61-3-9282-2490
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

"Paul D. DeRocco" <pderocco@ix.netcom.com> writes:

|>  Multiple inheritance is free at
|>  run-time, except for the need to test for nil before converting between
|>  a derived pointer and a second base pointer.

This depends.  Multiple inheritance without virtual base classes is very
limited in application.  And virtual base classes DO add significant
overhead, both space and run-time.

|>  BTW, I recently got a book about Java, to see what it was like. I got to
|>  the sentence that said, "Java doesn't have destructors," and promptly
|>  closed the book. I won't be writing any EC++ or Java code, if I can
|>  avoid it.

Most of my destructors are used to clean up memory, and wouldn't be
necessary in Java.  While I do use destructors for explicit cleanup of
other resources as well, there is something to be said for using named
functions, instead.  The exception safety, in the case of Java, is
provided by the "finally" clause, rather than the destructor.  I can
think of valid arguments for both of them.  In the end, I think that it
is a question of taste.  I think that I would prefer "finally", but not
having actually used it in a major project, I certainly won't insist on
it.

(I can think of a number of reasons why I won't be using Java in
embedded projects, but the lack of destructors is not one of them.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

conor@cognet.com.au (Conor MacNeill) writes:

|>  In article <kjNOSPAMray-ya023480000802971516580001@nntp.ix.netcom.com>,
|>  kjNOSPAMray@ix.netcom.com (Ray) wrote:
|>
|>  >The C/C+ Users Journal had a description by P. J. Plauger of a new
|>  >"standard" dialect of C++ called "Embedded C++". This language is [being?]
|>  >specified by Advanced Data Controls Corp., Fujitsu, Hitachi, NEC, and
|>  >Toshiba.
|>  >
|>  >You can read the Feb 97 issue for more information, but succinctly, the
|>  >language is the draft C++ standard, without templates, without rtti,
|>  >without exceptions, no STL, no multiple inheritance, no namespaces. It has
|>  >non-templatized iostreams and string classes, and a subset of standard C
|>  >library functions.
|>  >
|>  >How many people are interested in having their compiler vendor support
|>  >EC++ as an option?  Would you use it when you want to write efficient
|>  >code, being wary of template bloat or compiler-generated behind-the-scenes
|>  >code?

I missed this in my earlier post, but I think that the name EC++ is
already taken.  I seem to remember reading about a variant of C++ (an
extension?) with this name developed in Germany.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze wrote:
>
> "Paul D. DeRocco" <pderocco@ix.netcom.com> writes:
>
> |>  Multiple inheritance is free at
> |>  run-time, except for the need to test for nil before converting between
> |>  a derived pointer and a second base pointer.
>
> This depends.  Multiple inheritance without virtual base classes is very
> limited in application.

Ooh, is this true?  I use MI all the time, not as a key feature of my
design but because I use pattern where a class defines a "client" abstract
base class.  Often my objects need to be clients of several kinds of object
and so need to inherit from several "client" interfaces.

-- jP --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

kjNOSPAMray@ix.netcom.com (Ray) writes:

 >
 > The C/C+ Users Journal had a description by P. J. Plauger of a new
 > "standard" dialect of C++ called "Embedded C++". This language is [being?]
 > specified by Advanced Data Controls Corp., Fujitsu, Hitachi, NEC, and
 > Toshiba.
 >
 > You can read the Feb 97 issue for more information, but succinctly, the
 > language is the draft C++ standard, without templates, without rtti,
 > without exceptions, no STL, no multiple inheritance, no namespaces. It has
 > non-templatized iostreams and string classes, and a subset of standard C
 > library functions.
 >
 > How many people are interested in having their compiler vendor support EC++
 > as an option?  Would you use it when you want to write efficient code,
 > being wary of template bloat or compiler-generated behind-the-scenes code?

Caveat: I have not seen the Feb 97 article; I base my comments on
information from the Dinkumware(tm) homepages describing Embedded C++.

Describing a restricted version of C++ for use in demanding applications
in a particular area might very well be a good idea. In some contexts it
could be necessary. Defining an incompatible language with an incompatible
``standard'' library is a bad idea.

>From what I have seen of Embedded C++, it is not a strict subset of (draft)
ISO C++ and its standard library, and it is not a language defined simply
by excluding features that would cause run-time overheads or problems with
predictability of run-time. Embedded C++ is even defined relative to a
two-year-old working paper draft that differs significantly from every
draft that succeeded it. This is against the spirit of ISO standardization.

Developers should be wary of inefficent code and avoid code bloat, but
Embedded C++ is not simply an attempt help with that. It appears to be an
attempt to create a C++-like language in which you can't write C++-style
code - even when you stay within the bounds of what is clearly predictable
and efficient. The features cut from C++ to define Embedded C++ and especially
the changes to the standard library makes me fear that a primary motivator
was to save effort for compiler and standard library implementors.

At some points in time, it can be reasonable to settle of a subset of
a language and a library to create a period of stability for developers
while the standard matures. Going beyond that, creates an incompatible
language and library dialect - causing confusion in the user community
and a new burden to implementors. I think that the standard is already
mature enough to remove the need for subsetting for that particular reason.

One particular worrisome point is that the choice of language features
for Embedded C++ ensures that the standard C++ library will never be
available to Embedded C++ programmers so that they must have their own
incompatible and independently evolving ``standard'' library. This could
perpetuate an unnecessary split in the C++ community many years to come.

 - Bjarne

Bjarne Stroustrup, AT&T Research, http://www.research.att.com/~bs/homepage.html

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Marcelo Cantos (marcelo@mds.rmit.edu.au) wrote:
> The Sun SPARC C++ compiler
> incurs no speed penalty whatsoever.  In fact it has an option to
> *disable* exceptions, rather than one to enable them.  It does have
> a size penalty, though, due to the static function maps which tell
> the exception mechanism what to destruct.

> The interesting result of this is that a program that uses
> exception handling is actually faster than the equivalent program
> that does error checking with return values.  Sometimes the
> difference can be enormous, especially for tight loops that call
> functions.

Exactly! It is quite common to speak about the price of exception handling
and say nothing about how a code will look without it. Exception handling
SHOULD present in any language for embedding systems.
Another important thing that also should present is the explicit
language constructions for at least cooperative multithreading.
After some experience with Modula-2 it was really a pain to write such
code in C++. Classes will not help because you just need the support from
a language and compiler to write robust and effective code.
So EC++ is not a good idea.

--
Regards, Igor Boukanov.
igor.boukanov@fi.uib.no
http://www.fi.uib.no/~boukanov/
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

[Moderator's note: please note that this article is crossposted, and
that followups are directed by default to comp.lang.c++.moderated. mha]

>>>>> Conor MacNeill <conor@cognet.com.au> writes:

> Isn't most of this achievable with the "full" version just by not using
> the specified features.  Isn't one of the goals of C++ that you don't pay
> the overhead for what you don't use ?

I don't think there's any way to avoid paying for exceptions if the
compiler supports them, since it needs to handle throwing through an
arbitrary function and cleaning up the automatic variables there.  You may
not use exceptions, but something you call might.

Jason

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Paul D. DeRocco <pderocco@ix.netcom.com> wrote in article
<32FEAB38.11BF@ix.netcom.com>...
> Ray wrote:

[description of Embedded C++ (EC++)]
>
> Most of these features [that are omitted from EC++]
> really only make the compiler bigger. And who
> cares how big the compiler is? You don't run the compiler on the target
> system.

Another poster pointed out that compiler size actually is a factor in
embedded systems programming. While some embedded systems will benefit
from the omitted features, others will benefit much more from a simpler
compiler with an absolutely bulletproof code-generation phase. Multiple
inheritance, templates, exception handling, and namespaces are all
features which have historically led to (1) code bloat, (2) data bloat,
and (3) compiler errors. Space- and speed-critical embedded systems
would like to avoid #1 and #2. Life-critical embedded systems
desperately need to avoid #3. All embedded systems programmers would
still like to take advantage of the high level of abstraction of C++,
but avoiding complexity is important. I don't see myself using EC++,
but I think there's a significant vertical market that would benefit
from it.

--
Bradd W. Szonye
bradds@concentric.net
http://www.concentric.net/~bradds

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

On 09 Feb 97 03:24:49 GMT, kjNOSPAMray@ix.netcom.com (Ray) wrote:

>The C/C+ Users Journal had a description by P. J. Plauger of a new
>"standard" dialect of C++ called "Embedded C++". This language is [being?]
>specified by Advanced Data Controls Corp., Fujitsu, Hitachi, NEC, and
>Toshiba.
>
>You can read the Feb 97 issue for more information, but succinctly, the
>language is the draft C++ standard, without templates, without rtti,
>without exceptions, no STL, no multiple inheritance, no namespaces. It has
>non-templatized iostreams and string classes, and a subset of standard C
>library functions.
>
>How many people are interested in having their compiler vendor support EC++
>as an option?  Would you use it when you want to write efficient code,
>being wary of template bloat or compiler-generated behind-the-scenes code?

I think it is a great idea. For embedded programmers. (As it's name
implies.) Having this as an optional dialect feature which can be
switched on or off as the project demands seems to make sense.

I would use it to write embedded code. Normal code, I believe, can be
written efficiently with normal C++, templates, STL, streams, etc.,
and a bit of common sense. :-)

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

The C/C+ Users Journal had a description by P. J. Plauger of a new
"standard" dialect of C++ called "Embedded C++". This language is [being?]
specified by Advanced Data Controls Corp., Fujitsu, Hitachi, NEC, and
Toshiba.

You can read the Feb 97 issue for more information, but succinctly, the
language is the draft C++ standard, without templates, without rtti,
without exceptions, no STL, no multiple inheritance, no namespaces. It has
non-templatized iostreams and string classes, and a subset of standard C
library functions.

How many people are interested in having their compiler vendor support EC++
as an option?  Would you use it when you want to write efficient code,
being wary of template bloat or compiler-generated behind-the-scenes code?

       //
 ---- // ---   email is k j r a y at ix.netcom.com
----------     Check out:  <http://www.devworld.apple.com/>
---------                  <http://www.devtools.apple.com/>
----------           <http://www.evangelist.macaddict.com/>
 -----------     <http://www.solutions.apple.com/listadmin>
  ---   ---
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <kjNOSPAMray-ya023480000802971516580001@nntp.ix.netcom.com>,
kjNOSPAMray@ix.netcom.com (Ray) wrote:

>The C/C+ Users Journal had a description by P. J. Plauger of a new
>"standard" dialect of C++ called "Embedded C++". This language is [being?]
>specified by Advanced Data Controls Corp., Fujitsu, Hitachi, NEC, and
>Toshiba.
>
>You can read the Feb 97 issue for more information, but succinctly, the
>language is the draft C++ standard, without templates, without rtti,
>without exceptions, no STL, no multiple inheritance, no namespaces. It has
>non-templatized iostreams and string classes, and a subset of standard C
>library functions.
>
>How many people are interested in having their compiler vendor support EC++
>as an option?  Would you use it when you want to write efficient code,
>being wary of template bloat or compiler-generated behind-the-scenes code?

This sounds like C++ at the time of the 1st edition of Stroustrup

Isn't most of this achievable with the "full" version just by not using
the
specified features.  Isn't one of the goals of C++ that you don't pay
the overhead
for what you don't use ?

I can't see the benefit. If you take features away people will revert to
the
"bad" old ways. e.g. setjmp/longjmp combined with macros for exception
handling, generic.h for templates , a thousand different linked list
classes
instead of STL and even type unsafe containers with unverifiable
downcasts

Rather than support EC++, I'd like to see my compiler vendor work on
optimizing their support for the "full" version to reduce template
bloat,
etc.

Cheers

--
I do speak for my employer :-)
Conor MacNeill
conor@cognet.com.au
Cognet Pty Limited

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

conor@cognet.com.au (Conor MacNeill) writes:

|>  In article <kjNOSPAMray-ya023480000802971516580001@nntp.ix.netcom.com>,
|>  kjNOSPAMray@ix.netcom.com (Ray) wrote:
|>
|>  >The C/C+ Users Journal had a description by P. J. Plauger of a new
|>  >"standard" dialect of C++ called "Embedded C++". This language is [being?]
|>  >specified by Advanced Data Controls Corp., Fujitsu, Hitachi, NEC, and
|>  >Toshiba.
|>  >
|>  >You can read the Feb 97 issue for more information, but succinctly, the
|>  >language is the draft C++ standard, without templates, without rtti,
|>  >without exceptions, no STL, no multiple inheritance, no namespaces. It has
|>  >non-templatized iostreams and string classes, and a subset of standard C
|>  >library functions.
|>  >
|>  >How many people are interested in having their compiler vendor support
|>  >EC++ as an option?  Would you use it when you want to write efficient
|>  >code, being wary of template bloat or compiler-generated behind-the-scenes
|>  >code?
|>
|>  This sounds like C++ at the time of the 1st edition of Stroustrup
|>
|>  Isn't most of this achievable with the "full" version just by not using
|>  the specified features.  Isn't one of the goals of C++ that you don't pay
|>  the overhead for what you don't use ?

Except that in reality, you do pay for it, at least now and in the
forseeable future.  I'll bet a compiler which only implemented the
"Embedded C++" would be a lot smaller and faster than a full C++
compiler.  More important, from my point of view, there is a chance that
it would be reasonably error free:-).

And of course, it would be stable, since as you point out, these
features haven't changed in a long time.

Would it be useful?  I don't really know.  The major paradigm shift,
which makes C++ more than just a "better C", is inheritance and virtual
functions.  I notice that, although they also have hidden cost, they've
been kept.

(The "hidden cost" I'm thinking of in virtual functions isn't so much
the added indirection at the call site, but the fact that virtual
functions practically means that you need constructors, which in turn
means potentially function calls where the user didn't write one.)

I've gotten used to using multiple inheritance and templates a lot.  On
the other hand, for simple applications (and note that the supporters
are vendors of processors for embedded systems), I don't think it would
be difficult for me to do without; most of the benefits are only to be
reaped in large, complicated systems.  (An exception might be to allow
multiple inheritance of "empty", or interface, classes, like Java.  I
suspect, however, that if their goal is to make this a true subset of
C++, this would be too difficult to specify.)

Templates are another question.  They weren't there when I started C++,
at least not with the compilers I used.  I've developed significant
classes with generic.h.  I don't want to have to do it again.  And let's
face it, even in very small, embedded systems, you are likely to use
lists.

|>  I can't see the benefit. If you take features away people will revert to
|>  the "bad" old ways. e.g. setjmp/longjmp combined with macros for exception
|>  handling, generic.h for templates , a thousand different linked list
|>  classes instead of STL and even type unsafe containers with unverifiable
|>  downcasts

|>  Rather than support EC++, I'd like to see my compiler vendor work on
|>  optimizing their support for the "full" version to reduce template
|>  bloat, etc.

I can understand your point of view, but I can see why a supplier of
embedded processors would want to offer the biggest single plus of C++,
without paying the overhead for features which don't really bring any
advantages for their particular market.  (I would probably still want
templates, but only class templates?, and no implicit instantiation.
I'm not sure if this is simple enough for what they are trying to do,
however.)

I think that one other point is worth mentioning: the basic motivation
for the templated iostream was, if I'm not mistaken, to require
systematic support for wchar_t (and thus, Asian character sets).  It's
thus very interesting to note that all but one of the companies listed
is Japanese, and that the author, Plauger, is one of the real experts in
international software.  (I'm not sure what conclusions to draw from
this, if any, but I do find it interesting.  I'd be very interested in
reading the original article, if someone knows a URL, and I'd also be
interested in following further developments.  While my current
applications are large projects, in which templates and multiple
inheritance play an important role, I started with small, embedded
systems, and I rather feel too that C++, as currently specified, has
gotten too heavy for them.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

In article <kjNOSPAMray-ya023480000802971516580001@nntp.ix.netcom.com>,
Ray <kjNOSPAMray@ix.netcom.com> wrote:
>
>How many people are interested in having their compiler vendor support EC++
>as an option?  Would you use it when you want to write efficient code,
>being wary of template bloat or compiler-generated behind-the-scenes code?
>

Our company uses a compiler that provides functionality similiar
to what's described for some of our embedded projects. It turns
out that the savings are mostly imaginary.

In particular, some of the compile time checks that could be
achieved through templates and multiple inheritance now are
implemented through complex runtime structures. These end up
causing performance hits and maintenance nightmares, while
contributing as much or more to code bloat than their options
would have.

Thankfully, I don't have to use it...
--
-- fritzz@qualcomm.com
-- Pain is temporary, glory is forever.
--

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

Ray wrote:
>
> The C/C+ Users Journal had a description by P. J. Plauger of a new
> "standard" dialect of C++ called "Embedded C++". This language is [being?]
> specified by Advanced Data Controls Corp., Fujitsu, Hitachi, NEC, and
> Toshiba.
>
> You can read the Feb 97 issue for more information, but succinctly, the
> language is the draft C++ standard, without templates, without rtti,
> without exceptions, no STL, no multiple inheritance, no namespaces. It has
> non-templatized iostreams and string classes, and a subset of standard C
> library functions.
>
> How many people are interested in having their compiler vendor support EC++
> as an option?  Would you use it when you want to write efficient code,
> being wary of template bloat or compiler-generated behind-the-scenes code?

Without templates, exceptions and multiple inheritance, it's crap, in my
view. I'm running Borland 5.01 under 32-bit DPMI in an embedded project,
using somebody's ROM DOS clone, and I make extensive use of those three
things. The other features I could do without.

Most of these features really only make the compiler bigger. And who
cares how big the compiler is? You don't run the compiler on the target
system. Templates (including STL) only add bloat if you actually use
them, so there's no need to disallow them. And there are lots of useful
things that can be done with templates (especially inline template
functions) that don't add any bloat at all. RTTI adds a bit of overhead,
but it's really only an extra vtbl entry pointing to a static data
structure for each class. Big deal. Multiple inheritance is free at
run-time, except for the need to test for nil before converting between
a derived pointer and a second base pointer. Namespaces are utterly
free.

The only thing that's costly at run-time is exception handling, and I
believe most compilers already provide an option for turning it off.
Personally, I think exception handling is so important that I'm not
willing to give it up.

This sounds like an expression of the parochial view that embedded code
is "toy" code. Well, not the embedded code I write.

BTW, I recently got a book about Java, to see what it was like. I got to
the sentence that said, "Java doesn't have destructors," and promptly
closed the book. I won't be writing any EC++ or Java code, if I can
avoid it.

--

Ciao,
Paul D. DeRocco


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]