Boost logo

Boost :

From: Terje Slettebø (tslettebo_at_[hidden])
Date: 2004-10-09 12:25:02

>From: "Andy Little" <andy_at_[hidden]>

By the way, in my recent reply to John Maddock, the next last paragraph may
have seemed harsher than it was meant (due to the exclamation mark). I
wasn't upset, or anything; it was just meant for emphasis.

Now to your posting.

> "Terje Slettebø" <tslettebo_at_[hidden]> wrote in message
> news:044f01c4adf0$ab9fcf30$0300000a_at_pc...
> > >From: "John Maddock" <john_at_[hidden]>
> > Me too.
> >
> > > BTW, don't get too hung up on names it could be a bicycle shed issue
> again
> > > :-)
> >
> > Don't worry; we have, after all, working code, and the naming issue is
> > what is most important.
> FWIW I have been reading the previous discussion and found the function
> style filters , whatever v. interesting, but Possibly like others I havent
> really got any constructive suggestions.... I am just voyuerising. Most
> important thing seems to be the pragmatic one... compile times, and that
> mechanisms involved in the library may turn out to be as useful as the end
> result. The big question (Which I hope will be dicussed at the next big
> meeting?) is what will compiler authors make of Concepts with a big C.

Yes, that's a very good question. It seems we've only started on that
journey, with the three papers by Bjarne Stroustrup and Gabriel Dos Reis (at
the C++ standards site). As you know from the comp.std.c++ discussion about
this a while ago
(, one of the open questions may be - if the "usage" way of
specifying concepts is used - to quote from the thread:

--- Start quote ---

Howard Hinnant:

| > At the time I asked for my "compile time bool", compiler writers assured
| > me that they can not back out of arbitrarily complex expressions when a
| > compile time error is met. And I believe them.

Gabriel Dos Reis:

At the Kona meeting, someone (unfortunately I cannot remember the
name) pointed out that that problem has a solution: just dump the
current state before doing a speculative instantiation!
Yes, you don't want your C++ compiler do that often :-) :-)

--- End quote --

> Are they ever going to be practical. (It seems that decltype, which IMO
> Everyone wants, too may need similar heavyweight speculative
> instantiation,backout etc.)

Yes, for the SFINAE part of that proposal.

>The library here certainly has some flavour of something to focus those
discussions on.

Thanks. One idea is to have something to experiment on, so to speak, so that
we can determine what is needed, to do robust concept checking. For example,
there are several remainding issues in the library/language:

- Classes with overloaded function call operator can only be detected with
an exact match signature (no implicit conversions permitted), since
operator() have to be member functions, unlike most of the operators. The
same goes for the member access (operator->) and index operator
(operator[]). So one step might be to allow them to be free functions.

- Constructors can't be detected, because, they, too, have to be member
functions, and are unnamed. The assignment operator has similar issues,
including compiler-generated defaults, which also goes for the address-of
and comma operator (some of this is considered by the standards committee
with an "explicit" class -

These are certainly smaller changes than adding support for concepts in the
language, and they might be useful, anyway, for introspection purposes.

Another way of approaching this, rather than stretching SFINAE way beyond
what it was intended for, :) is with a compile-time introspection framework
(like that being worked on by Daveed Vandevoorde -

As you see, many approaches. :)



Boost list run by bdawes at, gregod at, cpdaniel at, john at