T
Tony
How much bloat does the STL produce? Is it a good design
wrt code bloat? Do implementations vary much?
Tony
wrt code bloat? Do implementations vary much?
Tony
M
Mike Wahler
Tony said:
None. Some. Much. It depends upon your
notion of 'bloat' and the particular implementation.
Imo its design is good (using my own notion
of 'good'). See above about 'bloat'.
Yes.
-Mike
N
Noah Roberts
Tony said:
In general STL containers and algorithms are made to introduce little
bloat and overhead. They are usually very well optimized for the
compiler they are built for. They also increase programmer
productivity by a great margin. Unless you see a problem with a
particular use of an STL container or algorithm it is just plain silly
to concern yourself with such. It is very difficult to beat the usual
STL implementation in size, speed, quality, or dependency.
As far as design goes...the STL is a work of art.
T
Tony
Noah Roberts said:
Its readability sucks rocks though. Where would one go to read about
STL memory management design/architecture if anywhere?
Perhaps if you don't try to read it or or try to understand it from the
implementation! I think what makes it that way is the extremism of
type safety. I'm would use a void* or a cast, judiciously placed
in order to considerably make code more readable. But I guess the
standard has to be pure/extreme in that area.
Tony
P
peter koch
Tony skrev:
What do you mean when you say readability sucks? If you read the
standard C++ code from e.g. Dinkumware I agree that the code is not
that easy to read, but you should bear in mind that the code has been
written to be ported to different compilers in several configurations.
Also e.g. variable names look weird, but remember that the code must be
able to work in "hostile" environments where the programmers might e.g.
have definitions such as
#define i 42
.... none of the template code you or I write could handle stuff like
this (nor are we supposed to).
If you think readability of code using the standard library, i believe
that the code in general is quite readable.
Now If you want to learn something about your standard library, I would
recommend that you simply study the code - preferably while debugging
it. You could also try to write your own collection classes.
/Peter
[snip]
What do you mean when you say readability sucks? If you read the
standard C++ code from e.g. Dinkumware I agree that the code is not
that easy to read, but you should bear in mind that the code has been
written to be ported to different compilers in several configurations.
Also e.g. variable names look weird, but remember that the code must be
able to work in "hostile" environments where the programmers might e.g.
have definitions such as
#define i 42
.... none of the template code you or I write could handle stuff like
this (nor are we supposed to).
If you think readability of code using the standard library, i believe
that the code in general is quite readable.
Now If you want to learn something about your standard library, I would
recommend that you simply study the code - preferably while debugging
it. You could also try to write your own collection classes.
/Peter
[snip]
P
Pete Becker
peter said:
And don't forget reading the documentation. Why is it that people think
they can use tools without doing this?
--
-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
P
peter koch
Pete Becker skrev:
Certainly! Actually, I read Tonys question not as a way to get
documentation but rather to learn how to create the code in the first
place. Rereading, I realize I was influenced by the "difficult to read"
statement.
/Peter
Certainly! Actually, I read Tonys question not as a way to get
documentation but rather to learn how to create the code in the first
place. Rereading, I realize I was influenced by the "difficult to read"
statement.
/Peter
M
Mathias Gaunard
Tony said:
You're not supposed to read the implementation.
What's important is the interface and the behaviour.
There are lots of books for learning how to use the C++ standard library
and especially the containers. Get one.
And when you're familiar enough, a reference should do to learn everything.
If you were to use void* instead of T you would not only lose on
readability, usage, and safety (the biggest issue actually) but also in
performance.
Genericity through void* is unmaintenable and dangerous.
You must not know much about C++ if you say that collections of void*
are better.
To have implemented, played with, and benchmarked both, I can tell you I
would never want to drop templates.
R
Roland Pibinger
Regarding templates there is no difference between interface and
implementation. Maybe he just wants to understand the template error
messages which is not an outrageous request, IMO.
Best regards,
Roland Pibinger
G
Gavin Deane
Roland said:
You can still write the documentation, which is where clients of your
code should be looking to understand the interface to and behaviour of
your code.
If anyone learns how to do that, could you let me know
Gavin Deane
N
Noah Roberts
Tony said:
It isn't about how easy it is to read. In most cases that is very
important but with the standard library there are other considerations
because it needs to be quick, small, etc...all the things you seem to
want. Most of the time one would only sacrifice readability when
necissary based on some known need but the std library maintainers must
get the best performance in many conflicting areas for unknown needs.
The beuty of the STL is the design, the interface the client (us) sees.
The way these tools can be used to do things that the library
designers could not have possibly forseen is amazing. One great
measure of design is how easy is it to create new behavior out of the
components, or how easy is it to extend objects in the design to do
things they where not designed for. In that regard the STL is
constantly teaching me new things about good design.
P
Pete Becker
Roland said:
Sure there is. The interface to std::tr1::result_of is quite simple:
template <class FTY> struct result_of
{
typedef /* return type */ type;
}
The implementation is deep magic.
--
-- Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com)
Author of "The Standard C++ Library Extensions: a Tutorial and
Reference." (www.petebecker.com/tr1book)
W
wkaras
Tony said:
When implementing a template, you often have a range
of options as to how much of the implementation will
be in non-templeted code that can be shared by
all/some of the template instantiations. I could
implement std::sort() so that it shared no code
between instantiations, or I could implement it so
that all instatiations call the (non-templeted)
function:
void sort_(
void *begin, size_t elem_size, size_t n_elems,
void (*index)(void *begin, size_t idx),
bool before(void *a, void *b));
The implementation using sort_() would be slower,
but if std::sort() had serveral distinct instantiations
in a program, there would be less bloat.
A generic sort using O-O might further reduce
bloat (and execution performance), but then you run
into all the limitations of O-O (can't use with
primitive types, often need to modify target
type) that inspired the invention of templates.
And, or course, there's no O-O based sort
in the standard library.
On the other hand, if the bloat got bad enough,
it could lead to a greater amount of cache
and virtual memory evictions, that might
more than offset the performance
advantage of the "fast and fat" implementation
approach.
T
Tony
peter koch said:
Yes, I was inquiring about architecture/design documentation rather than
usage info. The memory management in particular.
Tony
R
Roland Pibinger
To make the typdef'ed type never appear in a template error message is
indeed deep magic.
Best regards,
Roland Pibinger
T
Tony
Mathias Gaunard said:
Sounds like obfuscation.
Been there. Done that. I wanted architecture/design documentation on the
memory management.
Performance is overrated, these days. Readability improves, usage improves
safety need not be compromised. But I don't want to get into the details:
just go find another well-implemented library and look at it.
Hehe. OK, if you say so then surely it must be so.
Again, performance is overrated in many many cases. In many many cases,
it doesn't even matter what container you use. You'd have to be doing things
with thousands of objects before performance concerns became important.
Tony
Tony
T
Tony
Roland Pibinger said:
The mem mgmt.
Tony
T
Tony
Noah Roberts said:
So no one thinks the current design is getting a bit long in the tooth?
Not an asset, IMO. Pretty much a language on it's own. It reminds me
of the column in a programming magazine: "Obfuscated C" where the
goal was (I think) to write the most undecipheral code snippet. Doing
unusual things with templates may be interesting or fun but probably
doesn't belong in general coding practices. How much undecipherable
code can one have before it becomes overwhelmingly unmaintainable?
I want to see code that I can understand what it is doing without having
to go investigate the tiniest of idiosyncracy of template machinery.
There's nothing wrong with templates, but they are a genre all their own.
There's a place for them and a place not for them. (Containers only for me).
Tony
K
Kai-Uwe Bux
Tony said:
Not at all. It's just acknowledging that header and implementation files are
meant to be digested by the compiler, whereas published documentation is
meant to be digested by client programmers. The maintenance programmer for
the STL code hopefully and probably has access to design documentation that
is not shipped with the code.
You will have to ask the vendor for that. The STL is defined by the standard
only in terms of its behavior. All implementation details are unspecified
and up to the implementor.
As far as memory management in general goes, the only thing guaranteed by
the standard is that you can customize the STL containers by providing your
own allocators.
Nope. I regularly write programs that run for days to search for examples or
counter examples to certain conjectures. Speed does matter since it
translates directly into the amount of information I can get out of those
computational experiments.
Performance is especially important when it comes to standard libraries. I
don't want the compiler vendor to decide that _my_ programs may just run a
little slower just so that the code looks nicer. The code is none of my
concerns, readability is what I need for _my_ code. As far as I am
concerned, the code in the STL header files could be computer generated
from other highlevel descriptions. If that made it faster, I'd be all for
it. The maintenance of that code is a problem that I cheerfully leave to
other people.
[snip]
Best
Kai-Uwe Bux
T
Tony
Kai-Uwe Bux said:
Maybe it's too "general purpose" then.
That makes sense. So none of the implementations (perhaps a free one?) are
documented (design/architecture)?
"YMMV" is always appropriate. I don't use a corvette to get groceries daily
either.
If it's a choice between a "black box" and something comprehensible, you
know which one I want.
Tony