Re: [boost] Re: Technical session at the October C++ meeting?

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-20 18:56:44

Peter Dimov wrote:

> > To make it work, you have to use RTTI, and the result
> > isn't safe: you can try to make it safer by providing some
> > 'convenience' functionality, but you can't force people
> > to use it. :-(
> 
> I can:
> 
> variant<void> v;
> 
> v = 5;
> 
> int & ri = variant_cast<int &>(v); // will throw bad_cast when v doesn't
> contain an int

        OK. Sorry. You can force people to use it,
but it isn't statically safe. As you say 'will throw
bad_cast'. In ML, matches are _statically_ safe.
They can't fail at run time. [Actually, this isn't
true, but that's because they allow dynamic guards
on match conditions which defeat static checking
for completeness _when_ you use them]

> > Compare with SML:
> >
> > type t = X of int | Y of float
> > match e with
> > | X x -> print_int x
> > | Y y -> print_float y
> >
> > where type safety is enforced,
> 
> Met.

        No. ML enforces at compile time.
Run time exceptions consitute a failure to enforce
type safety. 

        In ML, this is the case for arrays.
[The length isn't part of the type, so type-safe!=safe]
C/C++ can sometimes do better!

        In C++ (baring severe trickery!),
a pointer to T is always a pointer to T or a class
derived from T. This is enforced at _compile_ time.
Run time checks DO NOT COUNT as 'safe'. After all,
a core dump is just another form of exception.
[Its the infinite loops and wrong results which
are the real problem]
 
> > and, in most cases,
> > completeness of decoding checked.
> 
> Impossible without language support. :-)

        As is static checking of cases.
 
> > > > What we really need is core language support :-(
> > >
> > > I could use LOTS of core language support.
> >
> > But you're unlikely to get it.
> 
> That was a joke. :-)

        I wasn't when I proposed discriminated unions.
It wasn't when Australia and the UK blocked standardisation
because the simple implementation:

        struct X {
                enum tag_t { tag ... };
                union { A a; B b; .. }
        };

was prevented by a proposed rule that prohibited declaring
unions of constructible types. It wasn't when WG21 snuck
the rule in anyhow, when I couldn't afford to attend
a meeting to protest: a clear violation of the process,
and a clear violation of the 'Spirit of C++': trap
errors only on use. [Fixing this is on Bjarne's list]

Unlike 'smart pointer' on which there was no consensus,
and no clear and obvious solution, the solution to this
one is obvious. (if you try to _copy_ a union with
constructible types, and there is no user defined
constructor, THEN your program is ill formed.)

        So my implementation was really nasty:
I had to allocate arrays of char of length 
sizeof(T) instead of just using a T.
And do lots of casts. But UNLIKE the variant 
implementation using inheritance, it was a genuine
C union: that is, the objects were all atored in
the one place .. so that there was no memory management
issue. Which is the main pragmatic problem with the inheritance
approach (you have to use pointers ..)

-- 
John (Max) Skaller, mailto:skaller_at_[hidden] 
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
New generation programming language Felix  http://felix.sourceforge.net
Literate Programming tool Interscript     
http://Interscript.sourceforge.net