Boost logo

Boost Users :

From: David Abrahams (dave_at_[hidden])
Date: 2006-06-19 08:48:43


Edward Diener <eddielee_at_[hidden]> writes:

>> I disagree. Certainly Pierre's experience belies that statement.
>> More generally, variant presents a high-level abstraction, and users
>> aren't necessarily expected to have any idea how it works internally.
>> For the most part, a naive user with a good debugger can explore his
>> program's data structures at will, but unlike almost any other library
>> component, variant is a barrier to the type information the debugger
>> needs.
>
>
> Variant isn't the only data structure where the actual type stored is
> not known at compile time and therefore unavailable to the debugger to
> show to the user. You yourself pointed out the others.

Yes, there are a very few others. And I was wrong about
shared_ptr<void>, since the deleter still has the static type info.

> Every good programmer of which I know is cognizant of the technique
> of casting the variable or memory area, from within a debugger, to
> the actual type so that the debugger shows the value.

So does that make Pierre a bad programmer? I don't think anyone's
programming skill should be indicted based on ignorance of a single
debugging hack.

> Are you saying it should be up to Boost to tell the programmer about
> this technique ?

No, I'm saying that maybe Boost should tell the user enough about the
implementation of variant so that he knows to look at the address of
the aligned storage for the type stored there when debugging. While
we're at it, I think it would be courteous to mention the cast
technique.

> I am not saying it might not be helpful, but I do not think it
> belongs in the documentation as a general rule since the technique
> is universal to other similar situations, and not to just one or two
> Boost libraries.

The technique may be universal, but I think the _problem_ is
particular to just one or two Boost libraries.

-- 
Dave Abrahams
Boost Consulting
www.boost-consulting.com

Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net