public inbox for c++-embedded@sourceware.org
 help / color / mirror / Atom feed
From: Jackie Chen <jackie@stsl.siemens.com.tw>
To: "Michael Bruck" <mbruck@rft.de>,
	"Embedded C++" <c++-embedded@cygnus.com>
Subject: Re: template bloat
Date: Thu, 27 Aug 1998 05:12:00 -0000	[thread overview]
Message-ID: <199808271207.UAA14445@stsl> (raw)

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



             reply	other threads:[~1998-08-27  5:12 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1998-08-27  5:12 Jackie Chen [this message]
1998-08-27  6:23 ` Pete Becker
  -- strict thread matches above, loose matches on Subject: below --
1998-08-27  4:05 Michael Bruck
1998-08-26 15:51 Kenneth Porter
1998-08-25 17:50 Kenneth Porter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=199808271207.UAA14445@stsl \
    --to=jackie@stsl.siemens.com.tw \
    --cc=c++-embedded@cygnus.com \
    --cc=mbruck@rft.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).