Greg Colvin <spam@me.not> wrote in article
<01bddd29$d0083b80$5e4a5ed1@gcolvin-hpc>...

> Wil Evers writes:
>
> > As a programmer working on the Windows platform, I made many attempts
to
> > actually use the STL in real commercial projects. So far, all of them
> > failed. Typical symptoms are incomprehensible and often incorrect
compiler
> > messages, gross code bloat, trouble with dynamic linking and serious
> > performance degradation. In each case, I ended up reinventing a few
wheels
> > or using some proprietary framework.
>
> I don't know just what you were trying to do, but my experience with
> STL on Windows (VC++ 5) has been very good.  I'm talking a small team
> of experienced programmers producing a suite of commercial applications,
> which for the usual reasons need to be as small and fast as possible.

I must admit it's been a while since I last tried using the STL with VC++.
At the time, I was still trying to get the STL stuff to work when other
bugs in VC++ forced me to pick a different compiler. From what I gather, I
believe the situation for programmers using the STL with VC++ has improved;
however, I fear most of these improvements are the result of Dinkumware
tweaking their implementation rather than Microsoft fixing their compiler.

> Yes, the compiler messages are awful, but if you move by small steps
> from working examples you can avoid that grief.  In a pinch I just
> copy the messages to an editor and reformat them: they make a lot more
> sense that way.

In my experience, the difficulty of understanding these messages is one of
the main reasons programmers prefer whatever proprietary framework they're
used to over the standard library.

[ snip ]

> As for dynamic linking, IMHO it just doesn't work on Windows, and
> there isn't much that STL can do about that.

I never meant to say the problems I describe were caused by the STL as
such; I believe they're caused by compiler vendors not taking templates
seriously enough. As for DLLs: despite their shortcomings, DLLs are heavily
used under the Windows, and I could certainly use a lot of extra help from
better template aware-development tools. At the moment, managing the
instantation of templates in a multiple-DLL project is a nightmare.

> I find it best for Windows DLLs
> to  communicate via COM interfaces anyway.   If you want
> to avoid COM for portability reasons, then you can easily recreate
> the idiom with abstract base classes and factory functions.

That's one way of doing it, but it has some disadvantages. If I restrict
myself to COM communication or ABCs, I can no longer use the standard
library containers to describe the interface between two otherwise
indepently developed pieces of software. What's more, each DLL will carry
the instantiations of all the templates it uses, which causes further code
bloat.

[ snip ]

> In summary, you need to apply both object-oriented and structured
> design to make best use of STL's generic containers and algorithms.

No argument here, of course.

- Wil

--
sender's address is spam-protected -
please remove 'nospam.' when replying by email
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Wil Evers writes:
> As a programmer working on the Windows platform, I made many attempts to
> actually use the STL in real commercial projects. So far, all of them
> failed. Typical symptoms are incomprehensible and often incorrect compiler
> messages, gross code bloat, trouble with dynamic linking and serious
> performance degradation. In each case, I ended up reinventing a few wheels
> or using some proprietary framework.

I don't know just what you were trying to do, but my experience with
STL on Windows (VC++ 5) has been very good.  I'm talking a small team
of experienced programmers producing a suite of commercial applications,
which for the usual reasons need to be as small and fast as possible.

Yes, the compiler messages are awful, but if you move by small steps
from working examples you can avoid that grief.  In a pinch I just
copy the messages to an editor and reformat them: they make a lot more
sense that way.

If you instantiate many templates, or instantiate them with many
different types, then you will see an increase in code size.  You
might nonetheless see an increase in speed, as more code is visible to
the optimizer.  You say performance is degraded, so for you that
tradeoff isn't working.  In that case it's up to you manage the bloat.

How?  If the bloat is caused by instantiating templates on many
different types then you need to reduce the number of types, perhaps
by factoring your types into hierarchies and using pointers or smart
pointers to the base types to instantiate STL templates.

If you are getting bloat from the inlining of the same templates, on
the same types, in many different places, then you can factor the
redundant code into classes and functions to prevent the inlining.

As for dynamic linking, IMHO it just doesn't work on Windows, and
there isn't much that STL can do about that.  I find it best for
Windows DLLs to communicate via COM interfaces anyway.  If you want
to avoid COM for portability reasons, then you can easily recreate
the idiom with abstract base classes and factory functions.

Having done all that, your performance might still be degraded by
excessive virtual memory paging, in which case you need to organize
your source files and libraries to better mirror the function call
graph of you application,

In summary, you need to apply both object-oriented and structured
design to make best use of STL's generic containers and algorithms.

Greg Colvin



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 11 Sep 1998 16:24:55 GMT, Greg Colvin <spam@me.not> wrote:

>Yes, the compiler messages are awful, but if you move by small steps
>from working examples you can avoid that grief.  In a pinch I just
>copy the messages to an editor and reformat them: they make a lot more
>sense that way.

The next step for compiler writers is to use typedefs in their error
messages.  And leave out out namespaces if the named entity is defined
in only one namespace.  So instead of

'Error in function
   std::basic_ostream<char, std::char_traits<char> >&
      std::operator<<(std::basic_ostream<char, std::char_traits<char> >&,
                      const std::basic_string<char, std::char_traits<char>,
                      std::allocator<char> >
                );
'

we should see

'Error in function "ostream& operator<<(ostream&, const string&);"'


>If you instantiate many templates, or instantiate them with many
>different types, then you will see an increase in code size.  You
>might nonetheless see an increase in speed, as more code is visible to
>the optimizer.  You say performance is degraded, so for you that
>tradeoff isn't working.  In that case it's up to you manage the bloat.

Use template specializations to reduce code bloat.  Also, in template
funcs, you don't have to use function objects.  You can use function
pointers or an object that contains a function pointer.  After all,
a function pointer is an object too!

bool myless1(const Object&, const Object&);
bool myless2(const Object&, const Object&);
sort(a.begin(),a.end(),&myless1); // function template generated
sort(a.begin(),a.end(),&myless2); // new func template not generated!



--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]