From: "Andy Little" <andy@servocomm.freeserve.co.uk>
"Terje Slettebø" <tslettebo@broadpark.no> wrote in message news:044f01c4adf0$ab9fcf30$0300000a@pc...
From: "John Maddock" <john@johnmaddock.co.uk> 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 not 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
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. the
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 C++ 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 (http://www.google.com/groups?selm=2873fa46.0407311135.33810bdb%40posting.go ogle.com), 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 --
IOW 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 - http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2004/n1582.pdf). 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 - http://www.vandevoorde.com/Daveed/News/Archives/000014.html). As you see, many approaches. :) Regards, Terje