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!)
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!)
>>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
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
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"