JasonB (no@spam.com) on 8/22/09 wrote:
---------------------------

>Library routines that are included with the language as per the standard. They
>are just as much a part of "C++" as the compiler

Yes. But there's a whole lot of stuff in the C++
standard that we *never* use in our codebase. I expect
there's a whole lot of stuff in the C++ standard that
you *never* use in your codebase. "Sesquipedalian" is
a perfectly good English word, it's in the dictionary,
but I never use it and I don't know how to use it.

So really, the set of stuff that's *effectively*
"standard" is what is in frequent use on a particular
project. Using other stuff imposes a cost.

To paraphrase Churchill, C++ developers are many cultures
divided by a common language.
>
>>And furthermore,
>>it's a language that really didn't work well (poor
>>standards compliance, poor portability, slow compile,
>>poor debugging tools) until the last 4 years or so.
>
>How would you know if you didn't use it?

We had to jump through hoops to use templates at all back
around 1998. And a colleague went off to a startup
around 2002 where they chose to use STL and templates
heavily, and he had a horrible time with the issues
of compile/link time, executable size, and debugging.
Maybe that was just g++/gdb, and MSVC++ did better: but
then we're back to the whole "different cultures" issue.

>>Which would be the way I'd do it as
>>well. Not by *randomly* "revisiting assumptions".
>
>Who said anything about randomly revisiting assumptions?

You suggested it was a good idea to "revisit assumptions"
at regular intervals. So my question really was, how do
you decide which assumptions might need to be revisited ?
If the answer is "look at the profiling data", then we
agree. If you had another answer I'd be interested to
know what it was: but revisiting *all* the assumptions
just seems like way too much.

>Previously you said you used glibc, and glibc's different implementations of malloc()
>were responsible for your problems.

No. We use glibc, it's one implementation, but it has
some special behavior which occurs only when multiple
threads are used.

>Since glibc is open-source, couldn't you have read the source code and kept tabs
>on that? Even better, you could have modified glibc (or derived your own
>allocator from it) to suit your needs as long as you published your modifications
>and linked to your modified version dynamically.

All good suggestions *WITH HINDSIGHT*. Why write that
program with that bug ? Why not write it correctly the
first time ? But this is engineering for profit: we do
what we need to do to sell something to customers.
It wasn't obvious that reading the glibc source code was
the best use of my time (and regrettably, though we have
a large number of developers, there wasn't really anyone
else with expertise in memory allocation).

>>I'm just pointing out that "conformant" isn't a very
>>helpful concept.
>
>It would have saved you a "nasty few weeks" tracking down mysterious behaviour.

Not really. A trick that reduces our DRAM requirement
by a factor of about 1.3x is worth a lot to us. Giving
that up for the (mostly nebulous) benefits of
"conformance" would be the wrong choice for our
circumstances. It's worth enough for me to spend that
"nasty few weeks" if I have to. YMMV.

>No. The program may not be able to do the operation requested, but that's not the
>same as "running into trouble".

For us it is. If the customer's problem won't run on
the size of machine that we specified then procedurally,
managerially, and financially that's going to get treated
the exact same way as a bug. And because the curve of
machine-DRAM-capacity vs cost has some big discontinuities,
you really don't want to find yourself specifying a
129GB machine instead of a 96GB machine.
Again, YMMV.

>>Maybe I know how to do it faster than you do it :-)
>
>Thousands of times faster?

Depends how slow yours is. I've tackled this problem
several times, and I'm confident I can do it pretty well.