[Q] Deriving from templates

[Victor Bazarov]

[...]
I'd hardly call the STL portions a model of how to do things. No
offense to PJP, et al., but I consider the STL a _horrible_ mess of
virtually unreadable code.

I am fairly certain it's perfectly readable to those who wrote it.

Probably. And for the rest of us?

The Standard headers [even if they exist in a text file form] are not
intended to be read by us[ers]. All we need to know about them is
perfectly readably expressed in the Standard.

Yes, possible, but if the case, of very detrimental value.

Why? The reason to "obfuscate" it is to protect from possible name
conflicts. Many variables there have the form _X (where 'X' is any
capital letter). Anything that is intended for access (like typedefs
and class/function names) is perfectly readable. Multiple statements
on a single source line is a necessity to keep the processing speed
to a maximum and space to a minimum.

Forget the code, of all the STL documentation that I've seen, it is based
on that (deliberately or consequentially) obfuscated code. Personally, I
rate STL documentation as the worst there is, but I digress...

I suppose the documentation you write is perfect, yes?

Besides, Mike didn't suggest to use Dinkumware's version _specifically_
but "an STL implementation that you like". If you don't like any [you
have seen], it doesn't mean they all are bad.

I'll readily admit that I'm far from an STL expert and have limited
exposure to : Borland's version (from the early days), whatever has
shipped w/ MS VisualC++ (Dinkumware included), and SGI. None of those
qualify as readable to me.

Again, they are not intended to be readable [by you].

Get a copy of STLport, you actually may change your mind. And take a look
at other implementations, like GNU's.

If you have any recommendations to _any_ implementation that is written w/
/clarity/ in mind, please let me know, same applies to documentation.

No, I don't know of any, really. The Dinkumware source is fine with me,
especially since it works if I need to step through it (though very
rarily indeed).

If anyone cares, and I doubt that anyone does, those are the *main*
reasons that I don't spend a lot of time w/ STL. I didn't grow up on
Unix, and personally, shun that style and level of obfuscation.

I don't think the two have anything to do with each other.

V

 

[Julie]

Julie wrote:


[...]
I'd hardly call the STL portions a model of how to do things. No
offense to PJP, et al., but I consider the STL a _horrible_ mess of
virtually unreadable code.


I am fairly certain it's perfectly readable to those who wrote it.

Probably. And for the rest of us?

The Standard headers [even if they exist in a text file form] are not
intended to be read by us[ers]. All we need to know about them is
perfectly readably expressed in the Standard.

Ok, you say that it is there, but not meant to be read/understood -- I
disagree, I think that they _should_ be readable.

Standard == definition != documentation

I suppose the documentation you write is perfect, yes?

Victor, I have *NEVER* understood that argument.

Are you saying that in order to critique something I must be better than that
thing? I hope not...

In absolute terms, the STL documentation that I've encountered is sub-par, period.

 

[Victor Bazarov]

The Standard headers [even if they exist in a text file form] are not
intended to be read by us[ers]. All we need to know about them is
perfectly readably expressed in the Standard.

Ok, you say that it is there, but not meant to be read/understood -- I
disagree, I think that they _should_ be readable.

Everybody is entitled to an opinion.

Standard == definition != documentation

In my book, documentation === definition.

Victor, I have *NEVER* understood that argument.

Julie, I have *NEVER* understood people's desire to complain about some
things.

Are you saying that in order to critique something I must be better than
that thing? I hope not...

You get what you pay for. You create documentation when you're paid to
create documentation.

Roads in the USA are crap. And I have no reservation about criticizing
those who are to maintain the roads in the US. I pay them money to
maintain the roads. I do not pay C++ compiler/library implementors to
make headers readable by me. They are readable by the compiler, that's
enough.

If you want documentation, you could pay Dinkumware and get a very nicely
packaged HTML documentation on the Standard C++ library (and Standard C
library, probably too). Check their web site. No, I am not affiliated
with them, nor am I in business promoting their documentation. It's just
an example of what you get when you pay for it.

In absolute terms, the STL documentation that I've encountered is
sub-par, period.

In absolute terms, all documentation that I've encountered is sub-par.
That doesn't mean it's impossible to use it.

There is always this saying I simply loove: he who wants to get things
done finds the means, he who doesn't want to get things done finds
excuses. Not that it's relevant here or anything...

V

 

[Julie]

In my book, documentation === definition.

You are probably in a pretty small crowd.

Julie, I have *NEVER* understood people's desire to complain about some
things.

Whatever. Don't know what that has to do w/ the subject at hand.

In absolute terms, all documentation that I've encountered is sub-par.
That doesn't mean it's impossible to use it.

Apparently you don't know what par means -- I'll rephrase:

In absolute terms, the STL documentation that I've encountered is below the
/average/ [quality level of general-use documentation], period.

There is always this saying I simply loove: he who wants to get things
done finds the means, he who doesn't want to get things done finds
excuses. Not that it's relevant here or anything...

?!

Irrelevant and condescending.

-end