STL design "good" wrt producing code bloat?

[Tony]

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.



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.

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]

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.

 

[Tony]

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

 

[Mathias Gaunard]

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.

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".

 

[Tony]

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.



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?

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.

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

 

[Mathias Gaunard]

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.

 

[Noah Roberts]

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.

 

[Tony]

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.

If you use C++, then do it the C++ way.

Paradigms are exactly that: paradigms! (Read, inside-the-box thinking).

Tony

 

[Mathias Gaunard]

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.