public inbox for c++-embedded@sourceware.org
 help / color / mirror / Atom feed
* Re: iostreams (was template bloat)
@ 1998-08-27 20:59 Kenneth Porter
  0 siblings, 0 replies; 5+ messages in thread
From: Kenneth Porter @ 1998-08-27 20:59 UTC (permalink / raw)
  To: Embedded C++

On Fri, 28 Aug 1998 10:34:39 +1000, Chris Johns wrote:

>iostream goes beyond just a printf replacement with type-safety. It
>allows all sorts of stream management and control to be performed. I see
>very little need for this in an embedded system.

Depends on the embedded system. You might not want it for a microwave
oven, but it would be handy in some network toasters like a router or
even an advanced VCR with web-based programming. Knowing the cost of
iostreams lets one decide whether it makes sense to use it for a given
application.

How hard is it to factor iostreams so that one doesn't get more than
one needs?


Ken
mailto:shiva@well.com
http://www.well.com/user/shiva/

http://www.e-scrub.com/cgi-bin/wpoison/wpoison.cgi (Death to Spam!)


^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: iostreams (was template bloat)
@ 1998-08-28 19:08 Michael Bruck
  0 siblings, 0 replies; 5+ messages in thread
From: Michael Bruck @ 1998-08-28 19:08 UTC (permalink / raw)
  To: c++-embedded

>
>How hard is it to factor iostreams so that one doesn't get more than
>one needs?
>
>[pjp]  It's much easier to factor Embedded C++, which is one of the main
>reasons for defining that subset. For the size of embedded systems
>contemplated by the EC++ Technical Committee, EC++ makes eminent
>sense:
>
>NEC Semiconductor Application Engineering Division reports
>the following typical embedded code sizes:
>
>Application      Current KB        Future KB
>
>camera           48-64                96-256
>rice cooker      16-48                64
>celluar phone   384+                768+
>printer             32-64               64-128
>television         16-48              32-96
>VCR               192-256           320+
>HDD               32-64               64-128
>


From what I've read at http://www.caravan.net/ec2plus EC++ simply removes
some features from C++.
This may be cool for people who don't know exactly what code the compiler
generates (or who don't care.) The EC++ subset guarantees that you won't
waste memory. But this is no solution to the real problem. F.e. removing
templates may save some memory but it also prevents people who know
how to use templates properly from saving memory by using them. BTW the
argumentation why the mutable keyword should be removed is senseless. As
long as a constructor may modify every member of the class you simply
can't guarantee that the contents of a "const" class are known at
compiletime.

And then this:

> 3.3 wchar_t, long double
>
> The libraries for type of wchar_t or long double are little used for the
> embedded application and have little necessity in the present
circumstances.
>
> Therefore, the technical committee decided not to include libraries for
type
> of wchar_t or long double in the Embedded C++ specification.
>
> For example, 'wstream', 'long_double_complex' are not supported.
>
> REASON:(2)

If I have no use for wchar_t then I just don't use it. But that's no reason
to remove
the feature as long as it costs no extra memory. This decision also
conflicts
with the definition of the intended targets for this standard (from the
Objectives powerpoint slides):
> Electronic equipment for home-use with network capability will be main
target.

For targeting international markets it's important to have some basic
multilingual
support. (the same applies to the locale library that is removed in this
specification)


The point is that there is no reason to prevent a programmer from using
exceptions as long as he thinks he can afford the extra memory overhead.
But he should be able to disable them. One simple measure would be to
offer some compiler-switches that disable these features (exceptions, rtti,
maybe templates ...). More important would be to implement the
Standard C++ Library in a way that allows for easy enabling or disabling
of (un)used features (f.e. #define _NO_IOSTREAM
#define _NO_EXCEPT ). The user should also be able to approximate
the (memory) costs of a particular feature.

Again from the rationale text:
> We mainly target 32-bit RISC MCU applications as embedded systems.

But the standard sounds as if it wants to address stone age 8051 technology.
The authors didn't know that there is a difference between bloat and
overhead.
C++ is about efficient programming (this may cause overhead). Unfortunately
it may easily cause bloat too. If you remove everything that causes
overhead you also prevent the bloat but you have nothing left that couldn't
been done with simple C. This is like inventing ReducedATM: Simply
don't use cells -- you save about 10% bandwith but you don't have
QoS, realtime audio/video streams ...  :).


Micha



^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: iostreams (was template bloat)
@ 1998-08-28  5:55 P.J. Plauger
  0 siblings, 0 replies; 5+ messages in thread
From: P.J. Plauger @ 1998-08-28  5:55 UTC (permalink / raw)
  To: c++-embedded

From: "Kenneth Porter" <shiva@well.com>
To: "Embedded C++" <c++-embedded@cygnus.com>
Date: Thu, 27 Aug 1998 20:58:46 +0700
Subject: Re: iostreams (was template bloat)

On Fri, 28 Aug 1998 10:34:39 +1000, Chris Johns wrote:

>iostream goes beyond just a printf replacement with type-safety. It
>allows all sorts of stream management and control to be performed. I see
>very little need for this in an embedded system.

Depends on the embedded system. You might not want it for a microwave
oven, but it would be handy in some network toasters like a router or
even an advanced VCR with web-based programming. Knowing the cost of
iostreams lets one decide whether it makes sense to use it for a given
application.

How hard is it to factor iostreams so that one doesn't get more than
one needs?

[pjp]  It's much easier to factor Embedded C++, which is one of the main
reasons for defining that subset. For the size of embedded systems
contemplated by the EC++ Technical Committee, EC++ makes eminent
sense:

NEC Semiconductor Application Engineering Division reports
the following typical embedded code sizes:

Application      Current KB        Future KB

camera           48-64                96-256
rice cooker      16-48                64
celluar phone   384+                768+
printer             32-64               64-128
television         16-48              32-96
VCR               192-256           320+
HDD               32-64               64-128





^ permalink raw reply	[flat|nested] 5+ messages in thread

* Re: iostreams (was template bloat)
  1998-08-27 16:40 Kenneth Porter
@ 1998-08-27 17:36 ` Chris Johns
  0 siblings, 0 replies; 5+ messages in thread
From: Chris Johns @ 1998-08-27 17:36 UTC (permalink / raw)
  To: Kenneth Porter; +Cc: Embedded C++

Kenneth Porter wrote:
> 
> On Thu, 27 Aug 1998 13:04:18 +0200, Michael Bruck wrote:
> 
> >I know I have always negative examples ... but first thing I noticed when I
> >tried to use the STL for embedded modules was that there are some
> >places where it uses iostreams. (f.e. in the new operator). Thats why I
> >had to modify (means remove) some things to work without them. I have
> >not yet looked at the impact that it has on code size and placement.
> 
> What impact does iostreams (classic or STL) have on code size, as
> compared to stdio? I'm sure most of us cut our teeth on printf and find
> stream inserters to be difficult to get used to, but they have the
> benefit of adapting to new types by defining an inserter for the new
> type, and printf lacks a mechanism for automatically type-checking its
> parameters and making sure the right number were passed. What cost must
> we pay for the convenience of type-safety?
> 

iostream goes beyond just a printf replacement with type-safety. It
allows all sorts of stream management and control to be performed. I see
very little need for this in an embedded system.

We use a cout object which maps to printf to give us just an "iostream
printf". It allows basic cout operations to be portable with out the
cost of embedding the full iostream library.

The last time I look at iostream sizes was about 4 years ago with a
cfront 2.x version of iostream. It was over 32k. The C printf code was
about 3k. This means an increase of 10 times.

The printf based cout adds about 3k, but I would have to check this to
be certain.

-- 
 Chris Johns  Networks, Plessey Asia Pacfic Pty. Ltd.
  mailto:ccj@acm.org    mailto:cjohns@plessey.com.au

^ permalink raw reply	[flat|nested] 5+ messages in thread

* iostreams (was template bloat)
@ 1998-08-27 16:40 Kenneth Porter
  1998-08-27 17:36 ` Chris Johns
  0 siblings, 1 reply; 5+ messages in thread
From: Kenneth Porter @ 1998-08-27 16:40 UTC (permalink / raw)
  To: Embedded C++

On Thu, 27 Aug 1998 13:04:18 +0200, Michael Bruck wrote:

>I know I have always negative examples ... but first thing I noticed when I
>tried to use the STL for embedded modules was that there are some
>places where it uses iostreams. (f.e. in the new operator). Thats why I
>had to modify (means remove) some things to work without them. I have 
>not yet looked at the impact that it has on code size and placement.

What impact does iostreams (classic or STL) have on code size, as
compared to stdio? I'm sure most of us cut our teeth on printf and find
stream inserters to be difficult to get used to, but they have the
benefit of adapting to new types by defining an inserter for the new
type, and printf lacks a mechanism for automatically type-checking its
parameters and making sure the right number were passed. What cost must
we pay for the convenience of type-safety?

Ken
mailto:shiva@well.com
http://www.well.com/user/shiva/

http://www.e-scrub.com/cgi-bin/wpoison/wpoison.cgi (Death to Spam!)


^ permalink raw reply	[flat|nested] 5+ messages in thread

end of thread, other threads:[~1998-08-28 19:08 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-08-27 20:59 iostreams (was template bloat) Kenneth Porter
  -- strict thread matches above, loose matches on Subject: below --
1998-08-28 19:08 Michael Bruck
1998-08-28  5:55 P.J. Plauger
1998-08-27 16:40 Kenneth Porter
1998-08-27 17:36 ` Chris Johns

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).