AD wrote:
> I did face few issues when introducing STL in a vxWorks based
> system.Major problems were:
> - significant code bloat
...

It would be nice if there were alternative implementations of the
containers (especially map/set) where most of the code was non-
templated and used void * and function pointers heavily.  The
templates would just be a type-safe veneer.  Seems like this
approach would be a little less fast but could greatly reduce
bloat (in those bloat-sensitive situations).

Has anyone tried this?

|| Many embedded C++ compilers ship with this library.

Interesting.  Went off and familiarized myself with Dinkum EC++.  This
in part, because I recalled having a conversation with the vendor and
he seemed overly enthused about the fact that the lastest release of
their development environment used 'Dinkumware'.  To that end, he
offered me a trade +  extra cash.
Trouble is, I tend to be a little skeptical of a sale person who
doesn't do a good job of explaining to me the ' embedded ' in the
embedded version of the Dinkumware C++ compiler.


Curiousity question.  What's in a name - 'Dinkumware'?

"ma740988" <m...@gmail.com> wrote in message 
news:1...@g44g2000cwa.googlegroups.com...

> || Many embedded C++ compilers ship with this library.
>
> Interesting.  Went off and familiarized myself with Dinkum EC++.  This
> in part, because I recalled having a conversation with the vendor and
> he seemed overly enthused about the fact that the lastest release of
> their development environment used 'Dinkumware'.  To that end, he
> offered me a trade +  extra cash.
> Trouble is, I tend to be a little skeptical of a sale person who
> doesn't do a good job of explaining to me the ' embedded ' in the
> embedded version of the Dinkumware C++ compiler.
>
>
> Curiousity question.  What's in a name - 'Dinkumware'?

Short answer -- we spent a year in Australia. A good friend of mine
organized a visiting post for me at University of New South Wales.
Besides, we've always liked Oz. "Dinkum" is Aussie slang for
genuine, honest, or true. I thought it was a good name for a
company that made good software. (The Limited part is to keep us
humble.)

Longer answer -- One term I taught a graduate seminar in software
engineering. (I called it Remedial Software Engineering.) We had
a running case study on Dinkum Swill Pty. Ltd., a company that
supplied hog swill for most of NSW. The students found some
fascinating, and sometimes gross, uses for computers in the
production of hog swill.

A few years later, I found myself negotiating with the likes of
Microsoft and IBM for the licensing of the C++ library I'd been
developing. My wife Tana did not want me signing contracts with
such big players as a sole proprietor (quite rightly). So she
founded a company for us. I wanted to call it Dinkum Swill, but
she would have none of it. (Imagine sitting at a rosewood
conference table explaining to a bunch of suits where the name
came from.) She was willing to settle for Dinkumware, Ltd.

That was ten years ago.

HTH,

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

Alex Vinokur wrote:
> Are there any restrictions/problems for use of  C++ STL in development
> in embedded systems?
> In particular:
> * Does STL require too much space/memory?
> * Is 'implementation of STL algorithms/methods' reenterable/reentrant?
> * What is the cost to provide  continuity of vectors in memory?
> Any other problems?
>

If you are wondering about microsoft's evc++ 4.0 and above, the simple
answer is, they don't provide one due to yada yada reasons. Every
platform has its own library, and their MFC has a memory leak. You can
possibly get sources for the STL and compile them with each library for
each platform that you are working for. But it is not clear if evc++ is
truly standards conforming.

> --
>  Alex Vinokur
>      email: alex DOT vinokur AT gmail DOT com
>      http://mathforum.org/library/view/10978.html
>      http://sourceforge.net/users/alexvn

"Shark" <c...@yahoo.com> wrote in message 
news:1...@g49g2000cwa.googlegroups.com...

> Alex Vinokur wrote:
>> Are there any restrictions/problems for use of  C++ STL in development
>> in embedded systems?
>> In particular:
>> * Does STL require too much space/memory?
>> * Is 'implementation of STL algorithms/methods' reenterable/reentrant?
>> * What is the cost to provide  continuity of vectors in memory?
>> Any other problems?
>>
>
> If you are wondering about microsoft's evc++ 4.0 and above, the simple
> answer is, they don't provide one due to yada yada reasons. Every
> platform has its own library, and their MFC has a memory leak. You can
> possibly get sources for the STL and compile them with each library for
> each platform that you are working for. But it is not clear if evc++ is
> truly standards conforming.

If by STL you really mean the Standard Template Library, then most
versions of eVC++ contain pretty complete implementations. (Ours, of
course.) What Microsoft has managed to do, for mysterious (yada
yada?) reasons, is butcher the combined C/C++ library in bizarre and
inventively different ways for each release of eVC++. We have a tidy
side business replacing the missing bits for those who need better
code portability between desktop and embedded versions of the same
compiler family.

P.J. Plauger
Dinkumware, Ltd.
http://www.dinkumware.com

"P.J. Plauger" wrote:
> "Shark" <c...@yahoo.com> wrote in message
>> Alex Vinokur wrote:
> 
>>> Are there any restrictions/problems for use of  C++ STL in
>>> development in embedded systems?
>>> In particular:
>>> * Does STL require too much space/memory?
>>> * Is 'implementation of STL algorithms/methods' reenterable/reentrant?
>>> * What is the cost to provide  continuity of vectors in memory?
>>> Any other problems?
>>
>> If you are wondering about microsoft's evc++ 4.0 and above, the
>> simple answer is, they don't provide one due to yada yada reasons.
>> Every platform has its own library, and their MFC has a memory
>> leak. You can possibly get sources for the STL and compile them
>> with each library for each platform that you are working for. But
>> it is not clear if evc++ is truly standards conforming.
> 
> If by STL you really mean the Standard Template Library, then most
> versions of eVC++ contain pretty complete implementations. (Ours,
> of course.) What Microsoft has managed to do, for mysterious (yada
> yada?) reasons, is butcher the combined C/C++ library in bizarre
> and inventively different ways for each release of eVC++. We have
> a tidy side business replacing the missing bits for those who need
> better code portability between desktop and embedded versions of
> the same compiler family.

The reason is obvious and consistent.  Microsoft fouls existing
standards in order to lock suckers in to their own software and
systems.  They have been doing this for many years.  They have
fouled html with IE and Usenet with OE.  More power to you if you
can replace their junk with conforming packages.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson
More details at: <http://cfaj.freeshell.org/google/>;

Shark wrote:
> Alex Vinokur wrote:
> 
>>Are there any restrictions/problems for use of  C++ STL in development
>>in embedded systems?
>>In particular:
>>* Does STL require too much space/memory?
>>* Is 'implementation of STL algorithms/methods' reenterable/reentrant?
>>* What is the cost to provide  continuity of vectors in memory?
>>Any other problems?
>>
> 
> 
> If you are wondering about microsoft's evc++ 4.0 and above, the simple
> answer is, they don't provide one due to yada yada reasons. Every
> platform has its own library, and their MFC has a memory leak. You can
> possibly get sources for the STL and compile them with each library for
> each platform that you are working for. 

First, eVC++ 4.0 includes STL implementation but very incomplete.
Second, if you'd like to use STL then you have two (three in fact) choices:
- buy Dinkumware libraries
- use STLport (here is my small introduction: http://tinyurl.com/eysea)
- write it youself :-)


> But it is not clear if evc++ is
> truly standards conforming.

No, it isn't e.g. there is lack of template partial specialization 
support and other modern C++ features.
eVC++ compiler is directly derived from VC++ 6.0 for desktop Windows.
(BTW, compilers for Windows CE platform are usually based on "big" 
brothers for desktop Windows)

If you are looking for ANSI/ISO C++ compliant compiler for Windows CE 
then you better take a look at Visual C++ 2005 (8.0).
Here is my small analysis I write to encourage myself to
move to VC++ 8.0 :-)

http://mateusz.loskot.net/2005/12/28/how-visual-c-2005-is-compliant-to-c-standards-regarding-windows-ce/

Cheers
-- 
Mateusz Łoskot
http://mateusz.loskot.net