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

On Wed, 26 Aug 1998 17:39:53 +0800, Jackie Chen wrote:

>Look at your mail about the template bloat, you mentioned the STL
>container is the good example for the template bloat.
>
>Do you have any experience about the STL using in an embedded
>multi-tasking environment? Is it feasible or not-workable?

Actually, I was speaking theoretically from a position of ignorance.
:-)

I would be curious to hear of any list members' experiences with STL as
well. I've read lots about it in C++ Report but haven't any experience
coding with it.

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: template bloat
  1998-08-27  5:12 Jackie Chen
@ 1998-08-27  6:23 ` Pete Becker
  0 siblings, 0 replies; 5+ messages in thread
From: Pete Becker @ 1998-08-27  6:23 UTC (permalink / raw)
  To: c++-embedded

At 08:07 PM 8/27/98 +0800, Jackie Chen wrote:
>In our system, we use Diab Data compiler and pSOS real time OS. Someone from 
>DDI said following.
>
>   There may be difficulties in trying to use STL with pSoS.  For one thing,
>   the iostream libraries do not work with pSoS.  Also, there are static 
>   members in many of the template classes which would result in not being
>   thread safe in a RTOS.  If you are concerned about why you can't get a 
>   compile, please send us the code that you are trying to compile and I 
>   can look at it.  However, I think there are real run-time concerns about
>   using STL in pSOS.

Don't mistake limitations of a particular implementation for limitations of
a library specification. There is nothing inherent in the Standard C++
Library that prevents it from being written in a way that will work
correctly and safely in a multi-threaded environment. Dinkumware's
implementation of the Standard C++ Library, for example, is used by several
compiler vendors in the embedded market.
Dinkumware, Ltd.
"Genuine Software"

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

* Re: template bloat
@ 1998-08-27  5:12 Jackie Chen
  1998-08-27  6:23 ` Pete Becker
  0 siblings, 1 reply; 5+ messages in thread
From: Jackie Chen @ 1998-08-27  5:12 UTC (permalink / raw)
  To: Michael Bruck, Embedded C++

At 01:04 PM 8/27/98 +0200, Michael Bruck wrote:
>>>Do you have any experience about the STL using in an embedded
>>>multi-tasking environment? Is it feasible or not-workable?
>>
>>Actually, I was speaking theoretically from a position of ignorance.
>>:-)
>>
>>I would be curious to hear of any list members' experiences with STL as
>>well. I've read lots about it in C++ Report but haven't any experience
>>coding with it.
>
>
>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.
>
>>
>>Ken
>
>Micha
>

Hi,

In our system, we use Diab Data compiler and pSOS real time OS. Someone from 
DDI said following.

   There may be difficulties in trying to use STL with pSoS.  For one thing,
   the iostream libraries do not work with pSoS.  Also, there are static 
   members in many of the template classes which would result in not being
   thread safe in a RTOS.  If you are concerned about why you can't get a 
   compile, please send us the code that you are trying to compile and I 
   can look at it.  However, I think there are real run-time concerns about
   using STL in pSOS.
 

As our trying to use STL with pSOS (for PPC), we got the following result.

   The iostream features in the DDI's STL will cause linking 
   problems. Remark the iostream features in the STL header
   files, (iterator.h, defalloc.h and faralloc.h) will remove
   these linking problems in our little testing program, 
   vector.cpp. (We assume no iostream features will be used in
   embedded system, or rewrite this part of code with stdio
   features)

We also use STL in Metaware compiler and pSOS (for x86) environment. Until
now, it seems fine with the multi-tasking environment. But we still can not
make sure STL will be no problem in the embedded system.

Does anyone have any comment?



--
Jackie Chen	Sr. Software Engineer
Siemens Telecommunication Systems Limited
Transport Networks & ASIC Design
Tel: 886-2-25186258	Fax: 886-2-25053866
jackie@stsl.siemens.com.tw
http:://www.siemens.com.tw



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

* Re: template bloat
@ 1998-08-27  4:05 Michael Bruck
  0 siblings, 0 replies; 5+ messages in thread
From: Michael Bruck @ 1998-08-27  4:05 UTC (permalink / raw)
  To: Embedded C++

>>Do you have any experience about the STL using in an embedded
>>multi-tasking environment? Is it feasible or not-workable?
>
>Actually, I was speaking theoretically from a position of ignorance.
>:-)
>
>I would be curious to hear of any list members' experiences with STL as
>well. I've read lots about it in C++ Report but haven't any experience
>coding with it.


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.

>
>Ken

Micha


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

* template bloat
@ 1998-08-25 17:50 Kenneth Porter
  0 siblings, 0 replies; 5+ messages in thread
From: Kenneth Porter @ 1998-08-25 17:50 UTC (permalink / raw)
  To: c++-embedded

Many of us, I'm sure, avoid templates because they often generate
identical code differentiated only by parameter types, but not by the
final binary. This usually happens where the template parameter is a
pointer and the template doesn't dereference the pointer. For example,
an STL container of pointers will suffer from this effect.

It would be nice if the tool chain could identify these situations and
merge templates that are binary-equivalent. One way to do this is to
assign a checksum to every routine in the compiler and have the linker
look for routines with the same checksum. These can then be further
examined to see if the code is identical and can then be merged.

For debugging, the feature could be disabled for all routines that
don't share common source (ie. non-templates).

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-27  6:23 UTC | newest]

Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
1998-08-26 15:51 template bloat Kenneth Porter
  -- strict thread matches above, loose matches on Subject: below --
1998-08-27  5:12 Jackie Chen
1998-08-27  6:23 ` Pete Becker
1998-08-27  4:05 Michael Bruck
1998-08-25 17:50 Kenneth Porter

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).