From mboxrd@z Thu Jan 1 00:00:00 1970 From: Chris Johns To: Kenneth Porter Cc: Embedded C++ Subject: Re: iostreams (was template bloat) Date: Thu, 27 Aug 1998 17:36:00 -0000 Message-id: <35E5FB1F.ABD84649@acm.org> References: <199808272340.TAA21451@mail1.ispnews.com> X-SW-Source: 1998/msg00039.html 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