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

From: John Max Skaller (skaller_at_[hidden])
Date: 2001-08-16 19:27:19

Aleksey Gurtovoy wrote:

> >       Yes there is: these 'functions' generally consist of
> > a large set of specialisations, and they fail to work
> > immediately you supply an argument for which there is no
> > specialisation, so you have to 'augment' the function
> > with a suitable specialisation.
> 
> If you are talking about the traits technique in general -

        I was.

> But I was talking about "traits" templates in the type_traits
> library, and the above paragraph certainly does not apply to them. 

        Accepted.

'is_fundamental'? 'is_convertible'?), and on conforming
> compiler they will work "out of box" with any type, built-in or
> user-defined. There are a few templates that cannot be implemented within
> the current language, and thus require a compiler support, or, in absence of
> this, user-defined specializations:
> 
> is_union
> is_class
> is_POD
> has_trivial_constructor
> has_trivial_copy
> has_trivial_assign
> has_trivial_destructor

        OK. Basically, these things just use existing syntax
(templates) to provide a whole new set of operators. They're
not really 'library' components in the usual sense of the word,
they're actually core language extensions that avoid using
new keywords :-)
 

(BTW, on
> some of the compilers we're already there). And (plans for) standardization
> could definitely speed up this process :).

        Agree.
 
> Actually, the fact that most often traits are not intrusive can be viewed as
> an advantage of the technique. First at all, there are always built-in
> types, and global traits are the only way to associate library-specific
> information with them. 

        No, its not the _only_ way. One has to wonder why
such information is useful, and then ponder how to fix
the core language so you don't need it.

        For example, in SML some types are boxed,
and others not. You need to know, if you're writing
a C interface. But for programming in SML, such distinctions
are disasterous, since they destroy orthogonality.

> Secondly, many libraries need to be generic enough to
> not force their users to change the interfaces of the already existing
> classes in order to use them together with the library components, 

        That's a persuasive argument, but it's also dangerous
because it promotes short term goals in favour of long
term productivity.

> Of course the drawbacks you are talking about are real too, I am just
> pointing out that often advantages overweight disadvantages, and that
> generally non-intrusiveness is considered as a good thing.

        Generally, most programmers haven't got the faintest idea
what a good thing is, because they've never use a high enough level
language to actually appreciate the power of 'orthogonality'.

        I once (with Fergus Henderson's help) proposed nested
functions for C++. About 50% of the extensions group supported
it -- and the other 50% didn't understand why it was useful!

        The supporters were people that had programmed
with other languages, the people that didn't understand it
were typically C++ compiler implementors that spent most of
their time writing C.
 
> It's not very different from, for example, a situation when they would all
> at the same time came to the conclusion that the class needs to have an
> output stream operator ("std::ostream& operator<<(std::ostream&, UNICODE)"),
> is it? :)

        No, I agree, its much the same. So one condemns object
oriented programming as well, since the obviously intended
solution -- each programmer derives a new class to add
their function (open/closed principle) -- in fact doesn't work.

        The SML solution to your problem: just write a function
'print' in your module. This works. There's no clash.
The same solution in C++: just write a global function in your
namespace. No clash. [If you can't do this, you have to invade
the class. In that case, the clash WILL be detected by, for
example, CVS, when several people try to add the method
interface to the same class -- this isn't true for specialisations
unfortunately, since they only need to be declared where
they're used, which need not be a shared file :-[

> Actually, I do share this point of view, or let's say that I tend to agree.
> I just don't think that (1) the issue is so black & white, and (2) that the
> type_traits library falls under category of "huge hacks" :).

        I agree. Its a hack -- but it isn't the implementation
that's the hack but the core language which it is trying to
bolster up :-)

-- 
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