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

>Be careful about throwing out the baby with the bathwater just because there is
>one feature not implemented by the majority of compilers because it is pretty useless and hard to implement.

Oh, don't get me wrong. Standards are good. But they
have to be taken with a big grain of salt, and with a whole
lot of extra-textual "cultural" knowledge about what
*really* works in which versions of which compilers
under what circumstances, and how features interact, and
what coding style and design patterns you need to use
*if* you try to use that feature.
shman for not wearing a jacket and tie.

>The thing is that all of that is an even bigger argument for writing your
>own malloc() or at least checking the code to see if the behaviour you were
>seeing was real.

Well, we *tested* it pretty thoroughly when we started
down that path: and it worked fine. Then - years later,
when probably the malloc() source had changed - someone
on another continent started using threads and ran into
trouble. So then, after much debugging, I went and read
the source code malloc.c, especially searching for places
where it used mmap(), because that's the most likely way to
get the unexpected address ranges. And all that code
looked as though it was fine for what we were doing.
So then I scratched my head a little more, and eventually
found out that there was *another* source file arena.c
that had the extra-special code that got invoked when
there were threads around ...

Ther's no good answer. Yeah, I could have written the
whole damn allocator myself, but malloc.c is nearly 6K
lines of code, and duplicating that effort - and
probably introducing a whole lot of *new* bugs, never
seemed like the right answer. And "checking the code"
isn't trivial either, when it's many thousands of lines
spread over a non-obvious set of files.

It's just the way it is if you venture into system-
programming details. Sometimes you get bitten.

>My point from the beginning was the inconsistency in your position
>where you were unwilling to use a well-defined subset of the language because it
>might be implemented poorly (STL),

At the time the design decisions were taken, it *was*
implemented poorly.

As for the "standard" crapola, you're perfectly willing
to use hash_map<> even though it is *not* in the standard.
It probably should have been from the start, but it isn't.

>Ouch. And you had to do all of that because GCC doesn't >implement dynamic_cast properly?

Yes. It's not *that* bad really: when you've got a
class hierarchy and every class has 30 or 40 methods,
adding another 10 or so trivial methods for down-casting
isn't a big deal.

>I'm sure GCC is a mess, but I wonder if it would have been >easier to try and fix the bug in GCC instead? :-)

Even if they fixed it, it's a pretty major exercise to
move our whole world onto a different compiler revision -
making sure all 3 development sites have all the right
tools, doing all the QA testing for a full build with
the newer compiler, etc. Working around with a hundred
lines of easy code is cheaper and quicker.

>Look at reinterpret_cast: that has no real place in most application-level
>code, but you couldn't write system-level code without it.

Of course you could: you can do it with a union, or by
taking the address of the thing and casting it as a
pointer to the type you want. That's two ways to do
(both of which would work all the way back to K&R C).

>Fortunately it only takes one line to fix:

Oh yeah, it's not *fixing* it that sucks. It's having
N lines of code that you *might* need to fix, where
N is up in the millions, and no automatic way to find
the 10000 routines that need the fix, nor any automatic
way to apply the fix.

>The whole point of RAII is that for each routine, if you make that routine
>exception-safe in isolation, you don't have to care about implementing try-catch(-finally)
>at all except in the routines that actually try to handle the exception.

That's all nice, as long as you don't have 100+ programmers
who don't know about RAII and don't understand the issue and
can't be made to follow any kind of coding standard.
And every year 20 or 30 of them leave and you get 20 or 30
new guys who don't know the rules and will start churning
out code and hacking on all the old code.

If you do (and my suspicion, in these days of outsourcing,
is that the staffing and management of many projects is
much more like mine than like yours), then the cost/benefit
tradeoffs are different.

The case of the error-message-handling code that used
dynamically-allocated strings and so couldn't manage to
print out the "FATAL ERROR: malloc failedn" message
might give you some idea of what I'm talking about.

>That's why making each routine exception safe is so important, which is why making
>writing exception safe code easy is so important, which is why RAII is so important,
>which is why C++ makes writing robust code easier than e.g. Java.

At one level, I agree with you completely. The way to
get good software is to have a small number of highly-
skilled software experts, preferably at one site,
writing the code carefully in adherence to an agreed
design style.

And this isn't really news. It's all in "The Mythical
Man-Month" which everyone talks about but most projects
don't follow, at all.

So I guess it's just that we're answering different
questions: you're describing the best way to write robust
code; I'm trying to answer the question, starting from
a pretty screwy codebase, with a dodgy set of developers
subject to little control, what can be done that
a) makes things a little better, while b) avoiding
total chaos.

It's a different question. Not surprising it has
different answers.

>I consider checked exceptions the "export" equivalent for >Java -- something that
>sounds good on paper but really needed a few years >experience in writing large programs before committing to.

Back around 1984, I worked with some ex-Xerox PARC people
for a while, who had experience with early code using
exceptions on what was it ? The Alto or Dorado ?
Anyway, they'd been on the bleeding edge. And what I heard
was that the number 1 problem on those systems was programse
crashing with "uncaught exception". That gave me a
negative view of the whole idea from the start.

>Read what I wrote. If you aren't using objects to manage >resources then you aren't using RAII.

OK, so we're not. And we can't guarantee that. Actually,
no-one can *guarantee* it, because there's no way to check
it automatically. So now what ?

>You can always create an object to manage a resource.

Yeah, you *can*. And you *can* write a large program in
assembly language that always uses all its global variables
with the right types. It's just damn hard, because no
tools enforce the constraint. Whereas strongly-typed
languages make it easy. Rules without tools are pretty
weak (you can make up for that weakness by hiring really
good people and applying good management practices, but
those are tricky problems in themselves).

>In case you're not using it already, here's a slightly modified one from the original: http://www.zete.org/people/jlehrer/scopeguard.h
>. It has features that aren't in the one in Boost.

Thanks. It's a good trick, and I'll consider using it
in my own code.