* 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 5:12 template bloat 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 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
* 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
* 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-27 5:12 template bloat Jackie Chen
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
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).