How much bloat does the STL produce? Is it a good design
wrt code bloat? Do implementations vary much?
Tony
48  2579 
"Tony" <rd**************@sbcglobal.netwrote in message
news:pn***************@newssvr21.news.prodigy.net. ..
How much bloat does the STL produce?
None. Some. Much. It depends upon your
notion of 'bloat' and the particular implementation.
Is it a good design
wrt code bloat?
Imo its design is good (using my own notion
of 'good'). See above about 'bloat'.
Do implementations vary much?
Yes.
-Mike
Tony wrote:
How much bloat does the STL produce? Is it a good design
wrt code bloat? Do implementations vary much?
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.
"Noah Roberts" <ro**********@gmail.comwrote in message
news:11*********************@73g2000cwn.googlegrou ps.com...
>
Tony wrote:
>How much bloat does the STL produce? Is it a good design
wrt code bloat? Do implementations vary much?
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.
Its readability sucks rocks though. Where would one go to read about
STL memory management design/architecture if anywhere?
As far as design goes...the STL is a work of art.
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
Tony skrev:
"Noah Roberts" <ro**********@gmail.comwrote in message
news:11*********************@73g2000cwn.googlegrou ps.com...
Tony wrote:
How much bloat does the STL produce? Is it a good design
wrt code bloat? Do implementations vary much?
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.
Its readability sucks rocks though. Where would one go to read about
STL memory management design/architecture if anywhere?
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]
peter koch wrote:
>
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.
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)
Pete Becker skrev:
peter koch wrote:
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.
And don't forget reading the documentation. Why is it that people think
they can use tools without doing this?
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
Tony wrote:
Perhaps if you don't try to read it or or try to understand it from the
implementation!
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.
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.
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.
On Fri, 08 Dec 2006 16:19:40 +0100, Mathias Gaunard wrote:
>You're not supposed to read the implementation.
What's important is the interface and the behaviour.
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
Roland Pibinger wrote:
On Fri, 08 Dec 2006 16:19:40 +0100, Mathias Gaunard wrote:
You're not supposed to read the implementation.
What's important is the interface and the behaviour.
Regarding templates there is no difference between interface and
implementation.
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.
Maybe he just wants to understand the template error
messages which is not an outrageous request, IMO.
If anyone learns how to do that, could you let me know :)
Gavin Deane
Tony wrote:
"Noah Roberts" <ro**********@gmail.comwrote in message
As far as design goes...the STL is a work of art.
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.
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.
Roland Pibinger wrote:
On Fri, 08 Dec 2006 16:19:40 +0100, Mathias Gaunard wrote:
>You're not supposed to read the implementation.
What's important is the interface and the behaviour.
Regarding templates there is no difference between interface and
implementation.
Sure there is. The interface to std::tr1::result_of is quite simple:
template <class FTYstruct 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)
Tony wrote:
How much bloat does the STL produce? Is it a good design
wrt code bloat? Do implementations vary much?
Tony
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.
"peter koch" <pe***************@gmail.comwrote in message
news:11*********************@l12g2000cwl.googlegro ups.com...
>
Pete Becker skrev:
>peter koch wrote:
>
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.
And don't forget reading the documentation. Why is it that people think
they can use tools without doing this?
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.
Yes, I was inquiring about architecture/design documentation rather than
usage info. The memory management in particular.
Tony
On Fri, 08 Dec 2006 11:41:13 -0500, Pete Becker wrote:
>Roland Pibinger wrote:
>Regarding templates there is no difference between interface and
implementation.
Sure there is. The interface to std::tr1::result_of is quite simple:
template <class FTYstruct result_of
{
typedef /* return type */ type;
}
The implementation is deep magic.
To make the typdef'ed type never appear in a template error message is
indeed deep magic.
Best regards,
Roland Pibinger
"Roland Pibinger" <rp*****@yahoo.comwrote in message
news:45***************@news.utanet.at...
On Fri, 08 Dec 2006 16:19:40 +0100, Mathias Gaunard wrote:
>>You're not supposed to read the implementation.
What's important is the interface and the behaviour.
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.
The mem mgmt.
Tony
"Mathias Gaunard" <lo******@remove.gmail.comwrote in message
news:45***********************@news.free.fr...
Tony wrote:
>Perhaps if you don't try to read it or or try to understand it from the
implementation!
You're not supposed to read the implementation.
What's important is the interface and the behaviour.
Sounds like obfuscation.
There are lots of books for learning how to use the C++ standard library
and especially the containers. Get one.
Been there. Done that. I wanted architecture/design documentation on the
memory management.
>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.
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.
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.
Genericity through void* is unmaintenable and dangerous.
YMMV.
You must not know much about C++ if you say that collections of void* are
better.
Hehe. OK, if you say so then surely it must be so. :P
To have implemented, played with, and benchmarked both, I can tell you I
would never want to drop templates.
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
"Noah Roberts" <ro**********@gmail.comwrote in message
news:11**********************@80g2000cwy.googlegro ups.com...
>
Tony wrote:
>"Noah Roberts" <ro**********@gmail.comwrote in message
As far as design goes...the STL is a work of art.
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.
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,
So no one thinks the current design is getting a bit long in the tooth?
The way these tools can be used to do things that the library
designers could not have possibly forseen is amazing.
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.
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.
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
Tony wrote:
>
"Mathias Gaunard" <lo******@remove.gmail.comwrote in message
news:45***********************@news.free.fr...
>Tony wrote:
>>Perhaps if you don't try to read it or or try to understand it from the
implementation!
You're not supposed to read the implementation.
What's important is the interface and the behaviour.
Sounds like obfuscation.
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.
>There are lots of books for learning how to use the C++ standard library
and especially the containers. Get one.
Been there. Done that. I wanted architecture/design documentation on the
memory management.
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.
>>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.
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.
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.
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
"Kai-Uwe Bux" <jk********@gmx.netwrote in message
news:el**********@murdoch.acc.Virginia.EDU...
Tony wrote:
>>
"Mathias Gaunard" <lo******@remove.gmail.comwrote in message
news:45***********************@news.free.fr...
>>Tony wrote:
Perhaps if you don't try to read it or or try to understand it from the
implementation!
You're not supposed to read the implementation.
What's important is the interface and the behaviour.
Sounds like obfuscation.
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.
Maybe it's too "general purpose" then.
>>There are lots of books for learning how to use the C++ standard library
and especially the containers. Get one.
Been there. Done that. I wanted architecture/design documentation on the
memory management.
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.
That makes sense. So none of the implementations (perhaps a free one?) are
documented (design/architecture)?
>>>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.
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.
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.
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.
"YMMV" is always appropriate. I don't use a corvette to get groceries daily
either.
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.
If it's a choice between a "black box" and something comprehensible, you
know which one I want.
Tony
Tony wrote:
"Noah Roberts" <ro**********@gmail.comwrote in message
The way these tools can be used to do things that the library
designers could not have possibly forseen is amazing.
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.
You and I have different views of the STL. I see the STL as a black
box into which I send things and get things back. I don't particularly
care how it does those things. What I find interesting about the STL
is the public interface. From a generic programming viewpoint the STL
is an amazing piece of work that has an interface that is fairly easy
to use for most purposes and can be implemented on numerous
architectures.
When I do have to look inside the STL because something I have done
wrong traces into an STL container I don't find the code there
particularly difficult or even that interesting or groundbreaking. If
you want interesting things to do with templates look at MPL, Spirit,
and boost::bind/boost::function. Yes, those thing definately do have a
place in general coding practices...they allow you to create very
powerful tools that are easy to USE (if not easy to understand or
implement).
Spirit is one great example of such work. Spirit is easy to use and
makes developing parsers a breeze...but no way would I step into it
trying to figure out how it works...I don't need to know how it does
what it does to use it.
"Noah Roberts" <ro**********@gmail.comwrote in message
news:11*********************@l12g2000cwl.googlegro ups.com...
>
Tony wrote:
>"Noah Roberts" <ro**********@gmail.comwrote in message
The way these tools can be used to do things that the library
designers could not have possibly forseen is amazing.
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.
You and I have different views of the STL.
Yep.
I see the STL as a black
box into which I send things and get things back.
And I OTOH don't like black boxes.
I don't particularly
care how it does those things.
And I have "NIH syndrome".
What I find interesting about the STL
is the public interface. From a generic programming viewpoint the STL
is an amazing piece of work that has an interface that is fairly easy
to use for most purposes and can be implemented on numerous
architectures.
When I do have to look inside the STL because something I have done
wrong traces into an STL container I don't find the code there
particularly difficult or even that interesting or groundbreaking. If
you want interesting things to do with templates look at MPL, Spirit,
and boost::bind/boost::function. Yes, those thing definately do have a
place in general coding practices...they allow you to create very
powerful tools that are easy to USE (if not easy to understand or
implement).
Those are specialized applications. I consider templates a specialized
subsystem of C++. I don't want code littered with templates unless the
templates are containers/iterators/algorithms. Just personal preference.
Spirit is one great example of such work. Spirit is easy to use and
makes developing parsers a breeze...but no way would I step into it
trying to figure out how it works...I don't need to know how it does
what it does to use it.
And the "off the beaten path" applications of code are not what I'm
generalizing about.
Tony
>
Tony wrote:
"Noah Roberts" <ro**********@gmail.comwrote in message
When I do have to look inside the STL because something I have done
wrong traces into an STL container I don't find the code there
particularly difficult or even that interesting or groundbreaking. If
you want interesting things to do with templates look at MPL, Spirit,
and boost::bind/boost::function. Yes, those thing definately do have a
place in general coding practices...they allow you to create very
powerful tools that are easy to USE (if not easy to understand or
implement).
Those are specialized applications. I consider templates a specialized
subsystem of C++. I don't want code littered with templates unless the
templates are containers/iterators/algorithms. Just personal preference.
Well, that is certainly your poragative but you've just tossed out
pretty powerful tools based on "personal preference".
Tony wrote:
"Noah Roberts" <ro**********@gmail.comwrote in message
>>
When I do have to look inside the STL because something I have done
wrong traces into an STL container I don't find the code there
particularly difficult or even that interesting or groundbreaking. If
you want interesting things to do with templates look at MPL, Spirit,
and boost::bind/boost::function. Yes, those thing definately do have a
place in general coding practices...they allow you to create very
powerful tools that are easy to USE (if not easy to understand or
implement).
Those are specialized applications. I consider templates a specialized
subsystem of C++.
Then you haven't invested the time and effort to master a core part of
the language.
I don't want code littered with templates unless the
templates are containers/iterators/algorithms. Just personal preference.
A rather shortsighted preference. Try them, learn where they make life
easier. The more I dig into templates and meta programming, the more I
find myself asking "is that it?" when solving complex problems with very
few lines of code.
--
Ian Collins.
Tony skrev:
"Noah Roberts" <ro**********@gmail.comwrote in message
news:11*********************@l12g2000cwl.googlegro ups.com...
[snip]
>
Yep.
I see the STL as a black
box into which I send things and get things back.
And I OTOH don't like black boxes.
Right. What operating systems do you write code for? Apart from that,
the standard containers are pretty well documented so the boxes are not
that black again.
>
I don't particularly
care how it does those things.
And I have "NIH syndrome".
What I find interesting about the STL
is the public interface. From a generic programming viewpoint the STL
is an amazing piece of work that has an interface that is fairly easy
to use for most purposes and can be implemented on numerous
architectures.
When I do have to look inside the STL because something I have done
wrong traces into an STL container I don't find the code there
particularly difficult or even that interesting or groundbreaking. If
you want interesting things to do with templates look at MPL, Spirit,
and boost::bind/boost::function. Yes, those thing definately do have a
place in general coding practices...they allow you to create very
powerful tools that are easy to USE (if not easy to understand or
implement).
Those are specialized applications. I consider templates a specialized
subsystem of C++. I don't want code littered with templates unless the
templates are containers/iterators/algorithms. Just personal preference.
I don't like liver; it's a personal preference. But it is not an
argument against others who eat liver with great joy. If you don't like
it then stay away from it, but don't expect sympathy from others.
Peter
[snip]
Tony wrote:
"Noah Roberts" <ro**********@gmail.comwrote in message
news:11*********************@l12g2000cwl.googlegro ups.com...
I see the STL as a black
box into which I send things and get things back.
And I OTOH don't like black boxes.
I don't particularly
care how it does those things.
And I have "NIH syndrome".
Which is, of course, your personal choice. However, if you reject the
concept of reading the documentation and treating the implementation as
a black box in favour of reinventing all the wheels yourself, you are
throwing away an enormous amount of your own productivity. It's
entirely up to you whether you care about that, and it sounds like you
don't. But if you ever aspire to find yourself programming
professionally, I imagine an employer would have a problem with that
approach.
Gavin Deane
Tony wrote:
Sounds like obfuscation.
Did you read all the implementations of the libraries you used?
The implementation can vary also, while APIs are usually stable.
Been there. Done that. I wanted architecture/design documentation on the
memory management.
There is no need to be a guru to understand how containers handle memory.
std::vector, for example, asks for a contiguous segment of memory of T's
through the standard allocator (or another one if you provide it), then
uses placement new to construct the objects.
Of course, to provide the complexity the standard requires, it needs to
allocate more than it needs. The "more" is implementation dependent and
is at least sqrt(n) where n is the number of elements.
What may be bothering you is that they often do not give the memory back
to the system when shrinking, and may not even do so when freeing. The
standard doesn't really put constraints on how vector manages its
capacity to amortize operations.
There is no such problem with node based containers though, that can
allocate memory as needed without performance issues.
Performance is overrated, these days.
Well, if you store pointers instead of objects, you're basically stuck
with "everything is a pointer".
That's a huge performance hit. You might as well use Java, which
actually will be more efficient since it has GC, which are basically
needed to make "everything is a pointer" efficient.
Readability improves, usage improves
safety need not be compromised.
What you don't seem to understand is that with void* you lose
readability, easy usage and safety.
std::vector<void*v;
v.push_back(new int(5));
v.push_back(new double(6.));
std::cout << *((int*)v[1]) << std::endl;
1) You need to cast to get back to the original type, which is verbose.
This is still needed if want heterogenous containers though.
2) While casting you may do things wrong and produce undefined behaviour
3) How should memory be handled here?
But I don't want to get into the details:
just go find another well-implemented library and look at it.
Again, who cares about how a library is implemented?
What's important is that it does what it does in the most efficient way.
The code of your compiler is not supposed to be easy to read so that
beginners can understand how a compiler works. It's supposed to analyse
correctly your code and produce the most efficient assembler.
To understand how it works, read the documentation.
YMMV.
No, it's a fact.
And it doesn't even allow specialization.
Hehe. OK, if you say so then surely it must be so. :P
You have made numerous posts criticizing C++ while you obviously don't
have much knowledge about it, and even less usage.
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.
Sure, O(1) and O(n) are the same things.
What kind of algorithmic course did you follow? The one for dummies?
Or maybe you just never worked with applications that had to scale.
Tony wrote:
And I OTOH don't like black boxes.
There is no way to know how the implementation works, since there are
various implementations of C++ and standard libraries, some
closed-source, and that your code should run on all of them.
And I have "NIH syndrome".
I, too, don't like stuff made by others when it could have really be
made better written in another way.
This is not the case for the STL though.
Those are specialized applications. I consider templates a specialized
subsystem of C++. I don't want code littered with templates unless the
templates are containers/iterators/algorithms. Just personal preference.
The STL is just containers/iterators/algorithms.
What are you talking about then?
It you mean "the C++ standard library parts that are not STL" just say
so explicitly.
So is your criticism about usage of templates in iostreams?
Gavin Deane wrote:
Tony wrote:
"Noah Roberts" <ro**********@gmail.comwrote in message
news:11*********************@l12g2000cwl.googlegro ups.com...
I see the STL as a black
box into which I send things and get things back.
And I OTOH don't like black boxes.
I don't particularly
care how it does those things.
And I have "NIH syndrome".
Which is, of course, your personal choice. However, if you reject the
concept of reading the documentation and treating the implementation as
a black box in favour of reinventing all the wheels yourself, you are
throwing away an enormous amount of your own productivity. It's
entirely up to you whether you care about that, and it sounds like you
don't. But if you ever aspire to find yourself programming
professionally, I imagine an employer would have a problem with that
approach.
I had an employer that had NIH syndrom. I don't know...it might be
worse working for one than having one work for you. At least when one
working for you you can smack them around and make them use tools
available to them....you can't do that when it's your boss :P
Noah Roberts wrote:
I had an employer that had NIH syndrom. I don't know...it might
be worse working for one than having one work for you. At least
when one working for you you can smack them around and make them
use tools available to them....you can't do that when it's your
boss :P
Well, I *have* an employer that *had* that syndrom too. Fortunately, I
managed to convince him that buying a fully fledged ACID RDBMS library
was indeed way more profitable than having to code it ourselves.
I have to admit, he only saw my point after I spent waaaay too much
time coding a disk-based B-Tree (which didn't even support
transactions or multi-threading), whereas in about an hour I installed
the DB library, made some example code and got it running.
:D
Cheers,
--
IR
IR wrote:
Well, I *have* an employer that *had* that syndrom too. Fortunately, I
managed to convince him that buying a fully fledged ACID RDBMS library
was indeed way more profitable than having to code it ourselves.
Or use one that you don't need to buy and that doesn't have a
restricting license.
Such as SQLite.
I hardly see how your boss could refuse public domain.
You actually have the right to copy and paste the code and claim it as
yours.
Mathias Gaunard wrote:
IR wrote:
>Well, I *have* an employer that *had* that syndrom too.
Fortunately, I managed to convince him that buying a fully
fledged ACID RDBMS library was indeed way more profitable than
having to code it ourselves.
Or use one that you don't need to buy and that doesn't have a
restricting license.
Such as SQLite.
I hardly see how your boss could refuse public domain.
You actually have the right to copy and paste the code and claim
it as yours.
Sure. I used other free libs (eg. Anti Grain Geometry 2.4, before it
went to GPL in 2.5).
Concerning the DB thing, SQLite was an option. Nevertheless I
preferred another lib which was more conforming to our needs.
However I do use SQLite in a personal project ;-)
Cheers,
--
IR
Mathias Gaunard wrote:
I hardly see how your boss could refuse public domain.
You actually have the right to copy and paste the code and claim
it as yours.
BTW, the only way to keep public domain code alive IMHO is to *never*
claim it as yours. As far as I'm concerned, I always credit the
authors.
Years ago, a manager tried to make me omit credits in the
documentation. Although he was legally right, we included the credits.
I made him choose between two lines of "we are using..." and me. :D
Cheers,
--
IR
Mathias Gaunard wrote:
IR wrote:
Well, I *have* an employer that *had* that syndrom too. Fortunately, I
managed to convince him that buying a fully fledged ACID RDBMS library
was indeed way more profitable than having to code it ourselves.
Or use one that you don't need to buy and that doesn't have a
restricting license.
Such as SQLite.
I hardly see how your boss could refuse public domain.
You actually have the right to copy and paste the code and claim it as
yours.
Well, I had a pretty hard time selling boost. The policy actually was,
"No third party libraries." We use it now, but that manager quit so...
They can come up with all sorts of reasons. "Has no support," "might
change in incompatible ways," "doesn't fit our needs (even though no
effort was made to see if it did)," etc...
You know...someone has a bad experience with some library vendor and so
to defend against that they decide to never use anyone else's libraries.
Noah Roberts wrote:
Well, I had a pretty hard time selling boost. The policy actually
was, "No third party libraries." We use it now, but that manager
quit so...
They can come up with all sorts of reasons. "Has no support,"
"might change in incompatible ways," "doesn't fit our needs (even
though no effort was made to see if it did)," etc...
You know...someone has a bad experience with some library vendor
and so to defend against that they decide to never use anyone
else's libraries.
In which case I always reply: we have the code available since it's
public domain, at least didn't have to write it, even if we have to
support it ourselves later... (this doesn't apply to the "doesn't fit
our needs" argument, but this one is pretty weak if the devs believe
they need that lib)
Even in the worst case it's still a win using it IMHO. :-)
Cheers,
--
IR
"Mathias Gaunard" <lo******@remove.gmail.comwrote in message
news:45***********************@news.free.fr...
Tony wrote:
>Sounds like obfuscation.
Did you read all the implementations of the libraries you used?
Not when I was team developer of corporate apps (10+ years ago).
But now that I'd like to deliver my own software, I'm considering
building everything I need.
The implementation can vary also, while APIs are usually stable.
>Been there. Done that. I wanted architecture/design documentation on the
memory management.
There is no need to be a guru to understand how containers handle memory.
std::vector, for example, asks for a contiguous segment of memory of T's
through the standard allocator (or another one if you provide it), then
uses placement new to construct the objects.
Oh. I thought perhaps it had something other than the compiler-supplied
mem mgmt underlying it. Good info.
Of course, to provide the complexity the standard requires, it needs to
allocate more than it needs. The "more" is implementation dependent and is
at least sqrt(n) where n is the number of elements.
How did they come up with sqrt(n) as the reserve mem amount?
What may be bothering you is that they often do not give the memory back
to the system when shrinking,
That seems reasonable, but an option may have been better.
and may not even do so when freeing.
You mean even when the container is deleted??
The standard doesn't really put constraints on how vector manages its
capacity to amortize operations.
OK.
There is no such problem with node based containers though, that can
allocate memory as needed without performance issues.
And node-based containers give it all back when deleted?
>Performance is overrated, these days.
Well, if you store pointers instead of objects, you're basically stuck
with "everything is a pointer".
That's a huge performance hit.
But all that matters is staying within the performance requirement of the
application program. Side-by-side comparison of the performance of
various container implementations may not be relevant then.
You might as well use Java,
That's a silly thing to say.
What you don't seem to understand is that with void* you lose readability,
easy usage and safety.
I understand it very well. I weigh the tradeoffs and make a choice. Well
without disclosing my own container implementations, I have to say that
readability and ease-of-use is greatly improved over something like STL.
While not being the purist's idea of "type safe", it's hardly an abominable
aberration. (Remember too, it doesn't have to be templates or no templates,
things in between are possible).
Again, who cares about how a library is implemented?
I do.
What's important is that it does what it does in the most efficient way.
That's not enough for me.
The code of your compiler is not supposed to be easy to read so that
beginners can understand how a compiler works. It's supposed to analyse
correctly your code and produce the most efficient assembler.
It's the "all things for all users all the time" stuff. One can do much
better
many times for a specific program.
To understand how it works, read the documentation.
Usually there is none at the design/architecture level.
>YMMV.
No, it's a fact.
If you're an extremist/purist.
And it doesn't even allow specialization.
Not a concern.
>Hehe. OK, if you say so then surely it must be so. :P
You have made numerous posts criticizing C++ while you obviously don't
have much knowledge about it, and even less usage.
LOL. Don't take it personally. (Though I made no criticizing remarks. You
are
taking it that way and you should do some introspection to determine why you
are so sensitive to anyone doing anything differently than your own way or
the
"std" way).
>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.
Sure, O(1) and O(n) are the same things.
What kind of algorithmic course did you follow? The one for dummies?
Read my statement above noting that if you're within the range that the
program
requires, it's a moot point. It simply does not matter. The user won't
notice anything
different.
Or maybe you just never worked with applications that had to scale.
Or maybe you're getting a bit long in the tooth with your attacks. (Grow up
already).
Tony
"Noah Roberts" <ro**********@gmail.comwrote in message
news:11**********************@l12g2000cwl.googlegr oups.com...
>
Tony wrote:
>"Noah Roberts" <ro**********@gmail.comwrote in message
When I do have to look inside the STL because something I have done
wrong traces into an STL container I don't find the code there
particularly difficult or even that interesting or groundbreaking. If
you want interesting things to do with templates look at MPL, Spirit,
and boost::bind/boost::function. Yes, those thing definately do have a
place in general coding practices...they allow you to create very
powerful tools that are easy to USE (if not easy to understand or
implement).
Those are specialized applications. I consider templates a specialized
subsystem of C++. I don't want code littered with templates unless the
templates are containers/iterators/algorithms. Just personal preference.
Well, that is certainly your poragative but you've just tossed out
pretty powerful tools based on "personal preference".
Again, it doesn't have to be either/or. There's usually a range of
possibilities
in between.
Tony
"Ian Collins" <ia******@hotmail.comwrote in message
news:4t*************@mid.individual.net...
Tony wrote:
>"Noah Roberts" <ro**********@gmail.comwrote in message
>>>
When I do have to look inside the STL because something I have done
wrong traces into an STL container I don't find the code there
particularly difficult or even that interesting or groundbreaking. If
you want interesting things to do with templates look at MPL, Spirit,
and boost::bind/boost::function. Yes, those thing definately do have a
place in general coding practices...they allow you to create very
powerful tools that are easy to USE (if not easy to understand or
implement).
Those are specialized applications. I consider templates a specialized
subsystem of C++.
Then you haven't invested the time and effort to master a core part of
the language.
LOL. Because I choose not to use it all over, all of the sudden I can't even
tie my own shoes huh? Some of you guys are silly, silly, silly.
>I don't want code littered with templates unless the
templates are containers/iterators/algorithms. Just personal preference.
A rather shortsighted preference.
Just the opposite actually.
Try them, learn where they make life
easier.
Been there, done that. Judicious use and even minimal use is the mantra
here.
The more I dig into templates and meta programming, the more I
find myself asking "is that it?" when solving complex problems with very
few lines of code.
That's not the goal here. I'll leave that kind of research to the language
lawyers
and scientists. All those clever tricks done with templates or whatever are
not
only not necessary but also undesireable. Give me a good architecture/design
with the FEWEST advanced/obscure/clever mechanisms any day. (Something
I'm sure a lot of people enamored with technology itself rather than
building
software will never quite grasp. Keep It Simple Stupid.)
Tony
"peter koch" <pe***************@gmail.comwrote in message
news:11**********************@f1g2000cwa.googlegro ups.com...
>
Tony skrev:
>"Noah Roberts" <ro**********@gmail.comwrote in message
news:11*********************@l12g2000cwl.googlegr oups.com...
[snip]
>>
Yep.
I see the STL as a black
box into which I send things and get things back.
And I OTOH don't like black boxes.
Right. What operating systems do you write code for?
Well I'm writing my own of course! (hehe, ;) )
Apart from that,
the standard containers are pretty well documented so the boxes are not
that black again.
They're only one option amongst many.
I don't like liver; it's a personal preference. But it is not an
argument against others who eat liver with great joy. If you don't like
it then stay away from it, but don't expect sympathy from others.
My my, another one getting sensitive about nothing. Interesting. I wasn't
aware the choice of whether or not to use the STL was a religious topic!
Tony
"Gavin Deane" <de*********@hotmail.comwrote in message
news:11**********************@n67g2000cwd.googlegr oups.com...
>
Tony wrote:
>"Noah Roberts" <ro**********@gmail.comwrote in message
news:11*********************@l12g2000cwl.googlegr oups.com...
I see the STL as a black
box into which I send things and get things back.
And I OTOH don't like black boxes.
I don't particularly
care how it does those things.
And I have "NIH syndrome".
Which is, of course, your personal choice. However, if you reject the
concept of reading the documentation
There isn't any design/architecture documentation really. But from what
I've gotten here, there's really nothing that novel happening at the mem
mgmt level.
Any way you slice or dice it though, the STL is hideous to look at (at least
the implementations I've seen, though I don't see how any could be much
better because it's the template syntax that is a big part of the ugliness).
and treating the implementation as
a black box in favour of reinventing all the wheels yourself, you are
throwing away an enormous amount of your own productivity.
It is very educational though. (Maybe everyone should do it, even if they
use STL).
It's
entirely up to you whether you care about that, and it sounds like you
don't. But if you ever aspire to find yourself programming
professionally, I imagine an employer would have a problem with that
approach.
I haven't done that in 10+ years. Been there. Done that. (Never again!). :)
Tony
Tony wrote:
"Ian Collins" <ia******@hotmail.comwrote in message
news:4t*************@mid.individual.net...
>>Tony wrote:
>>>
Those are specialized applications. I consider templates a specialized
subsystem of C++.
Then you haven't invested the time and effort to master a core part of
the language.
LOL. Because I choose not to use it all over, all of the sudden I can't even
tie my own shoes huh? Some of you guys are silly, silly, silly.
No, I was contradicting "I consider templates a specialized subsystem of
C++". They are part of the core language.
--
Ian Collins.
"Mathias Gaunard" <lo******@remove.gmail.comwrote in message
news:45**********************@news.free.fr...
Tony wrote:
>And I OTOH don't like black boxes.
There is no way to know how the implementation works, since there are
various implementations of C++ and standard libraries, some closed-source,
and that your code should run on all of them.
>And I have "NIH syndrome".
I, too, don't like stuff made by others when it could have really be made
better written in another way.
This is not the case for the STL though.
Of course it is. STL it the "general purpose" thing.
>Those are specialized applications. I consider templates a specialized
subsystem of C++. I don't want code littered with templates unless the
templates are containers/iterators/algorithms. Just personal preference.
The STL is just containers/iterators/algorithms.
What are you talking about then?
I mean making things templates that can be avoidably not so. "Containers
are containers". Pick your poison. It probably doesn't matter one way or
the other. Do know and use containers though, whether they are STL or not.
There may come a day when C++ cannot be used without using templates.
I want to be prepared for that day (read, jetison C++). It's just one
library
(and the associated machinery) and as long as it stays JUST that, I'm OK
with it. It's almost a language of it's own, so it only gets a small stage
of
presence (containers!) in my mind.
So is your criticism about usage of templates in iostreams?
I'm not criticizing (other than saying that templatized code is hard to read
and not fun to read or work with). YMMV.
Tony
"Ian Collins" <ia******@hotmail.comwrote in message
news:4u**************@mid.individual.net...
Tony wrote:
>"Ian Collins" <ia******@hotmail.comwrote in message
news:4t*************@mid.individual.net...
>>>Tony wrote:
Those are specialized applications. I consider templates a specialized
subsystem of C++.
Then you haven't invested the time and effort to master a core part of
the language.
LOL. Because I choose not to use it all over, all of the sudden I can't
even
tie my own shoes huh? Some of you guys are silly, silly, silly.
No, I was contradicting "I consider templates a specialized subsystem of
C++". They are part of the core language.
It's a separate programming paradigm. I choose the paradigms I want to use
and where/how I use them. To each their own.
Tony
Tony wrote:
How did they come up with sqrt(n) as the reserve mem amount?
I think that according to theory, to amortize push_back, you need to at
least waste sqrt(n) additional memory.
But anyway, I'm not even sure about it and it's not that important.
>
>What may be bothering you is that they often do not give the memory back
to the system when shrinking,
That seems reasonable, but an option may have been better.
There was a GOTW about that back in 1999 I believe.
std::vector<T>(v).swap(v); will shrink-to-fit v.
Of course this is O(n).
You mean even when the container is deleted??
Yes.
An allocator could very well take the memory for itself and not give it
back to the system. Especially if this is implemented as a pool.
And node-based containers give it all back when deleted?
They give it back to their allocator.
But the allocator may do anything with that memory. (within the standard
constraints of course)
That's a silly thing to say.
Maybe you didn't understand my point.
If you want every variable to be a pointer, C++ is not really suited.
Where C++ shines is value semantics with variables on automatic memory.
Read my statement above noting that if you're within the range that the
program
requires, it's a moot point. It simply does not matter. The user won't
notice anything
different.
They might notice when it scales.
If the program gets exponentially slower when feeding bigger data while
it does not need to, it is a problem.
Or maybe you're getting a bit long in the tooth with your attacks. (Grow up
already).
I guess you're playing in another league, there is nothing I can do
against comments such as "grow up already".
"Mathias Gaunard" <lo******@remove.gmail.comwrote in message
news:45**********************@news.free.fr...
>You mean even when the container is deleted??
Yes.
An allocator could very well take the memory for itself and not give it
back to the system. Especially if this is implemented as a pool.
>And node-based containers give it all back when deleted?
They give it back to their allocator.
But the allocator may do anything with that memory. (within the standard
constraints of course)
And that allocator is none other than that which provides memory for any
other 'new' instantiation unless another allocator is specified, correct?
>That's a silly thing to say.
Maybe you didn't understand my point.
If you want every variable to be a pointer, C++ is not really suited.
Where C++ shines is value semantics with variables on automatic memory.
It's silly to recommend a language switch on such trivial dialog. I also
wouldn't hire anyone with that sort of "language of the day" thinking. We
use C++ here, and it's not open for discussion.
>Read my statement above noting that if you're within the range that the
program
requires, it's a moot point. It simply does not matter. The user won't
notice anything
different.
They might notice when it scales.
If the program gets exponentially slower when feeding bigger data while it
does not need to, it is a problem.
But I already said it is not for what I'm developing and probably doesn't
matter for a large class of programs.
Tony
Tony wrote:
And that allocator is none other than that which provides memory for any
other 'new' instantiation unless another allocator is specified, correct?
No.
The default allocator has to use new but that doesn't mean that new has
to use the default allocator.
It's silly to recommend a language switch on such trivial dialog. I also
wouldn't hire anyone with that sort of "language of the day" thinking. We
use C++ here, and it's not open for discussion.
If you use C++, then do it the C++ way.
For example, no one is crazy enough to code the C++ way in C. Simply
because it's not suited.
Mathias Gaunard wrote:
For example, no one is crazy enough to code the C++ way in C. Simply
because it's not suited.
It's not possible. C doesn't have the "new" keyword. However, many
use some of the concepts you use all the time in C++ in C. For
instance it is quite possible to write OO code in C, it's just harder.
There is LOTS of OO C code.
"Mathias Gaunard" <lo******@remove.gmail.comwrote in message
news:45***********************@news.free.fr...
Tony wrote:
>And that allocator is none other than that which provides memory for any
other 'new' instantiation unless another allocator is specified, correct?
No.
The default allocator has to use new but that doesn't mean that new has to
use the default allocator.
Well yes then: the default allocator uses new. That's what I asserted
above.
>It's silly to recommend a language switch on such trivial dialog. I also
wouldn't hire anyone with that sort of "language of the day" thinking. We
use C++ here, and it's not open for discussion.
If you use C++, then do it the C++ way.
Paradigms are exactly that: paradigms! (Read, inside-the-box thinking).
Tony
Noah Roberts wrote:
For
instance it is quite possible to write OO code in C, it's just harder.
There is LOTS of OO C code.
OO C code usually rely on dynamic allocation of objects and reference
semantics.
This is totally different from C++, which key element is RAII and value
semantics. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: beliavsky |
last post by:
Many of my C++ programs have the line
using namespace std;
but the "Accelerated C++" book of Koenig and Moo has many examples
where the library names are included one at a time, for example
...
|
by: Tyno Gendo |
last post by:
Hi everyone
I need to move on a step in my PHP...
I know what classes are, both in PHP4 and 5 and I'm aware of "patterns"
existing, but what I'm looking for are some real world projects eg....
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: agi2029 |
last post by:
Let's talk about the concept of autonomous AI software engineers and no-code agents. These AIs are designed to manage the entire lifecycle of a software development project—planning, coding, testing,...
|
by: isladogs |
last post by:
The next Access Europe User Group meeting will be on Wednesday 1 May 2024 starting at 18:00 UK time (6PM UTC+1) and finishing by 19:30 (7.30PM).
In this session, we are pleased to welcome a new...
| |
