The Removal of Concepts From C++0x
georg...@gmail.com
http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441
This seems like a huge deal given the years that have been invested in
it. How much does this effect the schedule of 0x?
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
[ --- Please see the FAQ before posting. --- ]
[ FAQ: http://www.comeaucomputing.com/csc/faq.html ]
Joe Gottman
> I just read this article:
> http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441
>
> This seems like a huge deal given the years that have been invested in
> it. How much does this effect the schedule of 0x?
>
Does this means that the new for loop is gone as well? I liked the
idea of being able to do
vector<int> vec = get_vector();
for (int x : vec) { //Do something with x.
Note that many competitor languages, including Java and C#, have this
feature.
Joe Gottman
Pete Becker
> georg...@gmail.com wrote:
>> I just read this article:
>> http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441
>>
>> This seems like a huge deal given the years that have been invested in
>> it. How much does this effect the schedule of 0x?
>>
>
> Does this means that the new for loop is gone as well?
No.
--
Pete
Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
"The Standard C++ Library Extensions: a Tutorial and Reference"
(www.petebecker.com/tr1book)
Mathias Gaunard
> Does this means that the new for loop is gone as well?
Why would it mean that?
Doug Gregor
> george.r...@gmail.com wrote:
> > I just read this article:
> >http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441
>
> > This seems like a huge deal given the years that have been invested in
> > it. How much does this effect the schedule of 0x?
>
> Does this means that the new for loop is gone as well? I liked the
> idea of being able to do
> vector<int> vec = get_vector();
> for (int x : vec) { //Do something with x.
The new for loop will still be in C++0x, with the same syntax. The
actual implementation of the new for loop will be based on argument-
dependent lookup rather than concepts, but the user experience will be
almost the same. The actual details will be in the post-Frankfurt
mailing, in document number N2930.
- Doug
Rodolfo Lima
> Does this means that the new for loop is gone as well?
I don't think so. At least they're trying to implement the new for
loop based on ADL of begin/end functions. More info at:
http://www-949.ibm.com/software/rational/cafe/blogs/cpp-standard
Regards,
Rodolfo Lima
PS: I'm in a mix of sadness and relief about concepts removal,
strange...
Ville Voutilainen
> Does this means that the new for loop is gone as well? I liked the
No. The new for loop actually predates concepts, can be done without
them, and was promptly rescued in a no-concept fashion right after
concepts
were removed.
Beman Dawes
> george.r...@gmail.com wrote:
> > I just read this article:
> >http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441
>
> > This seems like a huge deal given the years that have been invested in
> > it. How much does this effect the schedule of 0x?
>
> Does this means that the new for loop is gone as well?
No. There will be a paper in the post-meeting mailing specifying the
changes to make range-based for loops work in C++0x.
Schedule impact isn't certain, but another Committee Draft will be
needed, and that is scheduled for Spring, 2010. It will take one to
three meetings to turn that around and get an FCD out the door. So say
a slip of one year, more or less.
On the other hand, C++0x compilers may be available sooner than
originally expected, since they don't have to include a complex new
feature (concepts).
--Beman
Stephen Clamage
> I just read this article:
> http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441
>
> This seems like a huge deal given the years that have been invested in
> it. How much does this effect the schedule of 0x?
The Committee voted to remove concepts from the version of the standard
now being worked on because we estimated it would take at least 2 more
years, and possibly 5, to complete the work and publish.
With many other desirable features ready to go, and with the current
standard already more than 10 years old, that seemed too long a delay.
The choice was difficult, and nobody was happy about having to drop
concepts, but the alternatives -- 5 years delay or standardizing an
unusable version of concepts -- were far worse.
Removing concepts will take some time, so the publication date of the
new standard might slip by 3 months or so, due specifically to the
removal of concepts. As Beman noted in an earlier message, we had to
lengthen our schedule still more for other reasons.
The Committee still wants concepts in C++, and will continue developing
it in anticipation of the next update of the standard.
---
Steve Clamage
Francis Glassborow
> I just read this article:
> http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441
>
> This seems like a huge deal given the years that have been invested in
> it. How much does this effect the schedule of 0x?
>
>
by 3.5 years. Of course taking them out of the current working paper
will take some time (though the project editor thinks he can do it in
time for the next meeting) Even without concepts it is going to take
about two years to get an internetional standard but at least most of
the new stuff (unlikr concepts) is being implemented in commercial
compilers even now.
Apart from problems with getting the spec for concepts right there is
also an issue as to what the overhead will be in compilation time. For
some major users even a 20% increase in compile time would be problematic.
Ken Penpal
> The Committee voted to remove concepts from the version of the standard now being worked on
Very disappointing indeed.
Isn't this showing the inability to evolve of a programming language
designed by Committee?
Just out of curiosity, how did Bjarne vote?
- Ken
Francis Glassborow
> Steve Clamage wrote:
>> The Committee voted to remove concepts from the version of the standard now being worked on
>
> Very disappointing indeed.
Would you have been happier if the Standard was delayed until circa 2014?
>
> Isn't this showing the inability to evolve of a programming language
> designed by Committee?
Well it is explicitly not the job of WG21 to design new features. Its
job is to consider features designed elsewhere. Among other things many
of us had concerns as to what impact concepts would have on compile
times at least in the short run.
We did not take the decision lightly.
>
> Just out of curiosity, how did Bjarne vote?
Well the voting was actually quite complex and cannot be adequately
summarised by a single yes/no. I am sure he can respond himself but on
at least one of the votes he voted to take concepts out.
However note that this was not a decision to abandon concepts just that
the risk of keeping them in the current iteration of the Standard was
too high for most of us.
Robin
wrote:
> On Jul 18, 12:18 pm, Joe Gottman <jgott...@carolina.rr.com> wrote:
>
> > Does this means that the new for loop is gone as well? I liked the
>
> No. The new for loop actually predates concepts, can be done without
> them, and was promptly rescued in a no-concept fashion right after
> concepts
> were removed.
>
> --
> [ comp.std.c++ is moderated. To submit articles, try just posting with ]
> [ --- Please see the FAQ before posting. --- ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html ]
I'm glad that the new for loop is still there.
georg...@gmail.com
<francis.glassbo...@btinternet.com> wrote:
> Even without concepts it is going to take
> about two years to get an internetional standard but at least most of
> the new stuff (unlikr concepts) is being implemented in commercial
> compilers even now.
Wow, two more years? Does that mean things slated for TR-2 are a good
5-7 years away?
Are there any plans to release shorter-duration updates to the
standard? Like aiming for every two years? I know everyone's working
hard and volunteering their time - it's just seems like a long time to
wait in an industry full of other languages moving quickly.
Francis Glassborow
> On Jul 20, 3:09 pm, Francis Glassborow
> <francis.glassbo...@btinternet.com> wrote:
>> Even without concepts it is going to take
>> about two years to get an internetional standard but at least most of
>> the new stuff (unlikr concepts) is being implemented in commercial
>> compilers even now.
>
> Wow, two more years? Does that mean things slated for TR-2 are a good
> 5-7 years away?
>
> Are there any plans to release shorter-duration updates to the
> standard? Like aiming for every two years? I know everyone's working
> hard and volunteering their time - it's just seems like a long time to
> wait in an industry full of other languages moving quickly.
>
we may well aim for releasing a mojor update of the standard 5 years
after the next one.
One of the problems is that issues (defects if it were a Standard) are
still arriving faster than we can process them. That suggest we are
still some way from the stability needed for a Standard. It should not
be forgotten that a complete we have completely overhauled the model
machine taking it from a single processor one where multi-threading does
not necessarily mean concurrency to a model which covers genuine
concurrency. That will be largely invisible to the working programmer
but is an essential step in a world where multiple cores a processors
are the norm.
Steve Clamage
<penpa...@googlemail.com> wrote:
>Steve Clamage wrote:
>> The Committee voted to remove concepts from the version of the standard
now being worked on
>
>Very disappointing indeed.
>
>Isn't this showing the inability to evolve of a programming language
>designed by Committee?
No. It shows how complex some features are, and the unwillingness of
the committee to release a standard that had a major unusable feature.
>
>Just out of curiosity, how did Bjarne vote?
He speaks for himself here:
http://www.ddj.com/cpp/218600111?pgno=1
---
Steve Clamage
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use
mailto:std...@netlab.cs.rpi.edu<std-c%2B%2...@netlab.cs.rpi.edu>
Goran Skoric
> On Mon, 20 Jul 2009 12:07:47 CST, Ken Penpal
>
>
>
> <penpal....@googlemail.com> wrote:
> >Steve Clamage wrote:
> >> The Committee voted to remove concepts from the version of the standard
> now being worked on
>
> >Very disappointing indeed.
>
> >Isn't this showing the inability to evolve of a programming language
> >designed by Committee?
>
> No. It shows how complex some features are, and the unwillingness of
> the committee to release a standard that had a major unusable feature.
>
>
>
> >Just out of curiosity, how did Bjarne vote?
>
> He speaks for himself here:http://www.ddj.com/cpp/218600111?pgno=1
>
> ---
> Steve Clamage
>
> --
> [ comp.std.c++ is moderated. To submit articles, try just posting with ]
> [ your news-reader. If that fails, use
> ]
> [ --- Please see the FAQ before posting. --- ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html ]
I am dissapointed as well, and I will try to explain (in my first post
of this kind) my reasons why.
I have been programming in C++ for almost 15 years, and although I may
not be an expert as committee members, still I believe that stripping
Concepts is big mistake. I say this altough I am very well aware that
there must have been big discussion and head-scratching before making
this decission and that I have biggest respect for all people involved
there. I also would like to mention that I have read comments made by
Bjarne Stroustrup, Herb Sutter and some other posts before posting
this
1. C++ is, whether we want to admit or not, very complex language (if
you want to master everything it offers) and although novice can use
subset of this quite happily and easily, there are parts of the
languages you can use 'more correctly' only by getting more
experienced, proficient (i.e getting towards 'expert' programmer
scale) . In this view, concepts might be difficult to master for
novice programmer, but using it in simplest form should not be so
difficult. So, I cannot support reasons that introducing or not
introducing them will not change to much for average programmer. My
view is that average programmers would use it sooner than some people
expect (I do not equal average programmer with novice programmer)
2. No language is ideal, neither C++ is. There are always flaws, even
with the best intention there will be some things which has been
overlooked etc... and although concepts are not perfect, and although
there are possible uses which might be controversial and problematic, C
++ programmers who are willing to use them will surely learn about it
and avoid it. If someone would like to abuse it or don't care about
it, well that is a problem of C++ programmer. Some learning effort is
neccessary.
3. So much effort has gone into design of it, on so many committee
(and probably some other non-official) meetings (or part of it) were
devoted to that that just throwing it out of window is really almost
unbelievable. I cannot still accept that because of several problems,
committee is ready to throw a lot of good things which can be achieved
by using concepts. I believe that people who designed it, know the
best why it is neccessary to have them and tried to find the best way
how to incorporate it within existing C++ and I think committee should
have accepted their view.
4. My view is that best solution would be to simplify concepts
according to Bjarne's proposal or modify them in such maaner to
minimize problems but not sacrifice good uses of them and accept it in
standard. Then, during next several years, when commercial
implementation is more avalaible, there will be more data what can be
improved and how, and than TR can be done to fix problems. In that
way, C++ community would have a concepts, compiler vendor would be
under pressure to implement them, which would as I said benefit all of
us and give better chances of fixing some problems in future. Without
putting them in standard, probably, concepts will be dead - which
compiler vendor is going to implement them to gain neccessary
practical experience for improving them in right direction and to be
significantly used by C++ community ?!
5. I accept that 'concept way' is not standard way of how things are
done, i.e a lot of things are usually avalaible as extensions (i.e in
one form or antoher already implemented) and than after that they are
added to standard, but this is enormous feature and sometimes, we had
to bite u bullet and to put something which has never before been
tried and tested. There is a risk, but, if compiler vendors are
villing to implement it, or most important parts of it, I don't think
it will be a problem
Again, I would like to thanks committee, their members and all C++
community for all effort done to improve our C++ language we use, but
my view is that decision to remove concepts is wrong and I would like C
++ community to express their view on it. I still believe that if
majority of C++ community supports inclusion of concepts in standard,
committee would have obligation to listen to it and change this
decision of favor of keeping it in.
Thank you for reading this long post.
Best regards,
Goran Skoric
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
Rodolfo Lima
> I am dissapointed as well, and I will try to explain (in my first post
> of this kind) my reasons why.
Hi, I'm also disappointed but somehow relieved. How many times we came
up with a neat idea, but only during its development some overseen
subtleties arise, then we kind of solve them by 'hacking up' the
abstractions, up to a point we have a mammoth system that does
everything we throw at it, at the expense of complicating the simpler
use cases (that neat idea we started with)?
That's what I think that happened with c++'s concepts. If you look at
it na�vely, its all fine, useful, clean and simple. But reality rarely
is like that, and since it didn't came from common practices, the
probability of doing it right at first time is usually small.
If this "mammoth" concepts subsystem went into the standard, I doubt
simple TRs would correct its fundamental problems, and it would only
become a new member in the C++'s shame list (along with function's
exception specification, vector<bool> and others).
IMHO I think the committee had courage to acknowledge that something
was deeply wrong with the whole thing and throw away years hard work
on the subject.
So, I'm disappointed because C++ needs desperately to address generic
programming properly and concepts was a step forward in this
direction, but relieved that the committee made the right (and hard)
decision that was best for the language itself.
Generic programming isn't that difficult that only expert programmers
can use it. Concepts weren't helping less experienced programmers
enter in GP world and profit from it and that's when, IMHO, the
committee decided that something was wrong.
There's no doubt something must happen to C++ so that it'll still be
relevant in the future, and I'm confident that that *something* we'll
be better than concepts in its current form.
[]s,
Rodolfo Lima
Balog Pal
> Generic programming isn't that difficult that only expert programmers
> can use it. Concepts weren't helping less experienced programmers
> enter in GP world and profit from it and that's when, IMHO, the
> committee decided that something was wrong.
Now, being removed concepts help no one. And After so many years passed
we're back to face those same problems concepts were ought to fix.
I would be happy, if the removal came along with introducing a light
version, that solves those, maybe somewhat less, maybe not always. One of
the options was to go ahead and fix the thing. Fix could include serious
stripping of scope, going towards the basics. It could possibly involve
calling external forces.
Now that will not happen. While the standard will still be late. And who
seriously believes that a TR, changing core will be accepted and implemented
with this stuff say within 10 years from now.
It resembles me those projects I saw in life that got out of control, and
attempted to fix the schedule by ad-hoc trimming the scope. No matter the
disturbance it created, that rollbacks were eating resources all the same,
and what stayed was possibly built on that was cut.
Then the project was late by the same or more amount as predicted without
the reorg, just finished in the crippled form. Leaving all the parties
unhappy.
Sean Hunt
> Now, being removed concepts help no one. And After so many years passed
> we're back to face those same problems concepts were ought to fix.
Not entirely. Due to various other language extensions like decltype
and SFINAE excpressions, I believe the entire effective semantic power
of concepts is still available in C++1x, though in a far more
difficult-to-use form (and no, I don't like what it will do to errors
either).
Sean Hunt.
Howard Hinnant
> On Jul 31, 3:12 pm, "Balog Pal" <p...@lib.hu> wrote:
>
> > Now, being removed concepts help no one. And After so many years passed
> > we're back to face those same problems concepts were ought to fix.
>
> Not entirely. Due to various other language extensions like decltype
> and SFINAE excpressions, I believe the entire effective semantic power
> of concepts is still available in C++1x, though in a far more
> difficult-to-use form (and no, I don't like what it will do to errors
> either).
Actually g++-4.4 does a pretty good job with functions constrained
with SFINAE:
#include <type_traits>
template <class T,
class = typename
std::enable_if<std::is_scalar<T>::value>::type
>
T
f(T t)
{
return t;
}
struct A {};
int main()
{
f(1);
f(A()); // line 17
}
test.cpp: In function �int main()�:
test.cpp:17: error: no matching function for call to �f(A)�
-Howard
Anders Dalvander
> Actually g++-4.4 does a pretty good job with functions constrained
> with SFINAE:
>
> #include <type_traits>
>
> template <class T,
> class = typename
> std::enable_if<std::is_scalar<T>::value>::type
> >
> T
> f(T t)
> {
> return t;
>
> }
>
> struct A {};
>
> int main()
> {
> f(1);
> f(A()); // line 17
>
> }
>
> test.cpp:17: error: no matching function for call to ‘f(A)’
>
> -Howard
I saw a nice macro from Beman Dawes, on the Boost mailing list the
other day, see below.
Regards,
Anders Dalvander
#define requires(...) class = typename std::enable_if<(__VA_ARGS__)
>::type
template <class T>
struct underlying
{
typedef typename remove_cv<typename
remove_reference<T>::type>::type type;
};
// forward with <type_traits>
template <class T, class U,
requires(!is_lvalue_reference<T> ||
is_lvalue_reference<T> && is_lvalue_reference<U>),
requires(is_same<typename underlying<T>::type,
typename underlying<U>::type>)>
inline
T&&
forward(U&& t)
{
return static_cast<T&&>(t);
SG
>
> Actually g++-4.4 does a pretty good job with functions constrained
> with SFINAE:
>
> #include <type_traits>
>
> template <class T,
> class = typename
> std::enable_if<std::is_scalar<T>::value>::type
> >
> T
> f(T t)
> {
> return t;
>
> }
Interesting. Does this mean that we're able to constrain templates
w.r.t. syntactic requirements like this
template<typename T>
struct make {
static T& lvalue();
static T&& rvalue();
};
class A {
public:
A(int, long);
template< typename Iter, // can be dereferenced?
typename Test = decltype(*make<Iter>::lvalue()) >
// ^
A(Iter beg, Iter end);
};
int main() {
A a (23,42); // picks 1st construtor
// even though it requires a conversion from int to long
}
?
Cheers!
SG
Florian Weimer
> Actually g++-4.4 does a pretty good job with functions constrained
> with SFINAE:
> test.cpp: In function ‘int main()’:
> test.cpp:17: error: no matching function for call to ‘f(A)’
This is certainly nice, short error message, but it doesn't really
tell you what preconditions are missing. I'm not sure if it makes
libraries easier to use.
Mathias Gaunard
> Does this mean that we're able to constrain templates
> w.r.t. syntactic requirements
Yes, with SFINAE generalized to expressions.
Has probably been said three times in this thread at least, I'd say.
It's available in GCC 4.4+ if you want to test it.
Goran Skoric
> On Jul 30, 2:28 pm, Goran Skoric <gskori...@googlemail.com> wrote:
>
> > I am dissapointed as well, and I will try to explain (in my first post
> > of this kind) my reasons why.
>
> Hi, I'm also disappointed but somehow relieved. How many times we came
> up with a neat idea, but only during its development some overseen
> subtleties arise, then we kind of solve them by 'hacking up' the
> abstractions, up to a point we have a mammoth system that does
> everything we throw at it, at the expense of complicating the simpler
> use cases (that neat idea we started with)?
>
> That's what I think that happened with c++'s concepts. If you look at
> is like that, and since it didn't came from common practices, the
> probability of doing it right at first time is usually small.
>
> If this "mammoth" concepts subsystem went into the standard, I doubt
> simple TRs would correct its fundamental problems, and it would only
> become a new member in the C++'s shame list (along with function's
> exception specification, vector<bool> and others).
>
> IMHO I think the committee had courage to acknowledge that something
> was deeply wrong with the whole thing and throw away years hard work
> on the subject.
>
> So, I'm disappointed because C++ needs desperately to address generic
> programming properly and concepts was a step forward in this
> direction, but relieved that the committee made the right (and hard)
> decision that was best for the language itself.
>
> Generic programming isn't that difficult that only expert programmers
> can use it. Concepts weren't helping less experienced programmers
> enter in GP world and profit from it and that's when, IMHO, the
> committee decided that something was wrong.
>
> There's no doubt something must happen to C++ so that it'll still be
> relevant in the future, and I'm confident that that *something* we'll
> be better than concepts in its current form.
>
> []s,
> Rodolfo Lima
>
> --
> [ comp.std.c++ is moderated. To submit articles, try just posting with ]
> [ --- Please see the FAQ before posting. --- ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html ]
>That's what I think that happened with c++'s concepts. If you look at
> it naďvely, its all fine, useful, clean and simple. But reality rarely
> is like that, and since it didn't came from common practices, the
> probability of doing it right at first time is usually small.
>
> If this "mammoth" concepts subsystem went into the standard, I doubt
> simple TRs would correct its fundamental problems, and it would only
> become a new member in the C++'s shame list (along with function's
> exception specification, vector<bool> and others).
Concepts is an enormous feature, so it is not possible to be 'only'
simple (as someone could naively expect to be) and it should not be
thrown because it is a big feature and not entirely simple. I do not
see a design which would replace concepts which can be significantly
better, simpler and flawless etc. within existing (either C++98 or C+
+0x/1x). If there was one, I am sure it would have been already
included in proposal. So I think that is is naive to expect this to
happen!.
>So, I'm disappointed because C++ needs desperately to address generic
> programming properly and concepts was a step forward in this
> direction, but relieved that the committee made the right (and hard)
> decision that was best for the language itself.
I think it is step in right direction but my view is that committee
was too conservative and pesimistic. Problems obviously exist, but
still I don't think it warrants exclusion.
> There's no doubt something must happen to C++ so that it'll still be
> relevant in the future, and I'm confident that that *something* we'll
> be better than concepts in its current form.
What and When?! In next 5 or 10 years. There is chance that it will be
better design than current concepts, because that design would draw up
conclusion from good design points of concepts as well as problems
encountered, but question is when? Is it worth waiting for it and will
it be so much better and simpler. My view is that not including this
very important feature doesn't help in it's faster evolving and
modernising, which C++ desperatly needs to keep a pace with some other
languages...
Some other techiques like SFINAE etc... which are by the way mostly
used by advanced/expert C++ programmers are just 'ugly' replecement
for concept or concept-like features which should make designing and
programming much easier task than using SFINAE and similar hard to
code and hard to read/understand code techniques wher e you have to be
expert on compiler's internals. Concepts would make that code much
easier to write, read and understand, no doubt about it and it is why
it is needed now, not in 5 or 10 years time.
Best regards,
Goran Skoric
Mathias Gaunard
> * Howard Hinnant:
>
> > Actually g++-4.4 does a pretty good job with functions constrained
> > with SFINAE:
> > test.cpp: In function ‘int main()’:
> > test.cpp:17: error: no matching function for call to ‘f(A)’
>
> This is certainly nice, short error message, but it doesn't really
> tell you what preconditions are missing. I'm not sure if it makes
> libraries easier to use.
In case where there are multiple candidates, it tells you what they
were.
It is the same error mechanism as failing to match any overload, be it
templated or not, and that is really the same error than with
concepts.
SG
>
> > Does this mean that we're able to constrain templates
> > w.r.t. syntactic requirements
>
> Yes, with SFINAE generalized to expressions.
> Has probably been said three times in this thread at least, I'd say.
Only once by Sean Hunt before Howard Hinnant did it. But I appreciate
the examples. I havn't seen decltype as part of a default template
parameter for a function templates before which is why I asked the
question.
> It's available in GCC 4.4+ if you want to test it.
Sure. I managed to test it yesterday. It's still not perfect, though.
I sometimes get errors that are substitution failures.
For kicks and giggles I already tried to emulate a couple of library
concepts (HasXyz, Convertible, ExplicitlyConvertible, Callable, ...).
You can basically divide them into "expression concepts" and "composed
concepts". All "concept" class templates expose a static const bool
value. "Expression concepts" also expose a typedef for result_type
(the expression's type for value==true and null_type otherwise).
"Expression concepts" with a null_type parameter are automatically
deemed unsatisfied. This also allows me to compose them like this:
template<typename T>
struct is_less_than_comparable :
is_convertible<
typename has_less<T const&, T const&>::result_type,
bool
>
{};
Cheers!
SG
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use
mailto:std...@netlab.cs.rpi.edu<std-c%2B%2...@netlab.cs.rpi.edu>
Sean Hunt
> Not entirely. Due to various other language extensions like decltype
> and SFINAE excpressions, I believe the entire effective semantic power
> of concepts is still available in C++1x, though in a far more
> difficult-to-use form (and no, I don't like what it will do to errors
> either).
Douglas Gregor pointed out to me that this is incorrect; removing
concepts removes the ability to have one-pass templates that are
syntactically and semantically checked at compile time, with no added
checks required at instantiation time.
Sean Hunt
David Abrahams
> I just read this article:
> http://www.informit.com/guides/content.aspx?g=cplusplus&seqNum=441
>
> This seems like a huge deal given the years that have been invested in
> it. How much does this effect the schedule of 0x?
There's more information on what happened at http://cpp-next.com
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
Beman Dawes
> I saw a nice macro from Beman Dawes, on the Boost mailing list the
> other day, see below.
>
> Regards,
> Anders Dalvander
The macro actually came from Howard Hinnant, as I mentioned in the
Boost posting.
--Beman
> #define requires(...) class = typename std::enable_if<(__VA_ARGS__)
>
> >::type
>
> template <class T>
> struct underlying
> {
> typedef typename remove_cv<typename
> remove_reference<T>::type>::type type;
>
> };
>
> // forward with <type_traits>
>
> template <class T, class U,
> requires(!is_lvalue_reference<T> ||
> is_lvalue_reference<T> && is_lvalue_reference<U>),
> requires(is_same<typename underlying<T>::type,
> typename underlying<U>::type>)>
> inline
> T&&
> forward(U&& t)
> {
> return static_cast<T&&>(t);
>
> }
>
> --
> [ comp.std.c++ is moderated. To submit articles, try just posting with ]
> [ your news-reader. If that fails, use mailto:std-...@netlab.cs.rpi.edu]
ymett
>
> Actually g++-4.4 does a pretty good job with functions constrained
> with SFINAE:
>
> #include <type_traits>
>
> template <class T,
> class = typename
> std::enable_if<std::is_scalar<T>::value>::type
> >
> T
> f(T t)
> {
> return t;
>
> }
>
> struct A {};
>
> int main()
> {
> f(1);
> f(A()); // line 17
>
> }
>
> test.cpp:17: error: no matching function for call to =91f(A)=92
>
Will it be possible to use SFINAE with conversion operators now? In
other words will the following be legal and useful:
struct C
{
template<class T, class = typename
std::enable_if<std::is_scalar<T>::value>::type>
operator T();
};
Yechezkel Mett
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use
mailto:std...@netlab.cs.rpi.edu<std-c%2B%2...@netlab.cs.rpi.edu>
Helmut Zeisel
concepts is the lack of experience.
I know that ConceptGCC can be used to obtain some experiences; as I
understand, ConceptGCC is more in the spirit of the "Indiana
Proposal".
Are there compilers that implements the "Texas Proposal" so that one
can evaulate the differences between the proposals?
Are there any plans for the future of ConceptGCC and other compilers
offering concepts?
Helmut
--
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
[ your news-reader. If that fails, use mailto:std...@netlab.cs.rpi.edu]
Jerry Coffin
@r34g2000vba.googlegroups.com>, zei2...@liwest.at says...
>
> If I undestand correctly, one of the main reason for the removal of
> concepts is the lack of experience.
> I know that ConceptGCC can be used to obtain some experiences; as I
> understand, ConceptGCC is more in the spirit of the "Indiana
> Proposal".
"More in the spirit of" may be rather understating things. ConceptGCC
was written primarily by Douglas Gregor at Indiana University's Open
Systems Laboratory (the leader of which is Andrew Lumsdaine). Their
work was based, to a large degree, on Jeremy Siek's design for the G
language.
Those same three people (along with Jaako Jarvi and Ronald Garcia)
were the authors of N1758 (the Indiana Proposal).
> Are there compilers that implements the "Texas Proposal" so that one
> can evaulate the differences between the proposals?
> Are there any plans for the future of ConceptGCC and other compilers
> offering concepts?
TTBOMK, the only other compiler with concepts is Jeremy Siek's for
the G language. I haven't studied G, but as I understand the
situation, most of the concept part of the design fro ConceptC++
(what ConceptGCC partially implements) came from G; their models (no
pun intended) of concepts are extremely similar.
--
Later,
Jerry.
Joe Smith
"Goran Skoric" <gsko...@googlemail.com> wrote in message
news:01711eb0-ab1c-419c...@j21g2000yqe.googlegroups.com...
> On Jul 31, 7:25 pm, Rodolfo Lima <rodo...@rodsoft.org> wrote:
>>So, I'm disappointed because C++ needs desperately to address generic
>> programming properly and concepts was a step forward in this
>> direction, but relieved that the committee made the right (and hard)
>> decision that was best for the language itself.
>
> I think it is step in right direction but my view is that committee
> was too conservative and pesimistic. Problems obviously exist, but
> still I don't think it warrants exclusion.
>
The standard is already overdue. There is no compiler that implements
concepts according the last concept-enabled draft. There were several major
unresolved issues in the core of the concept proposal itself. The
conceptized standard library is most likely full of issues of improper
contrainsts that are accidentally overlooked.
If we had a compiler that supported concepts as stated in the draft, we
could find these issues. (Even if the compiler was not quite fully
conformant with repect to concepts, if it was close it would help a lot).
The problem is that nobody is planning on implementing concepts in their
compilers very soon. ConceptGcc appears to just be rotting, EDG is busy with
the other features, and Microsoft does not have immediate plans to implement
concepts.
Considering all this, the right move is to release a version of the standard
without concepts, and rework concepts for the next standard.
The work done is not entirely wasted. While we really need to re-examine the
core of concepts, and probably completely rewrite that according to whatever
simplified proposal is considered best, the syntax is unlikely to change
considerably, and much of the conceptization of the library will still be
valid.
Please remember the list of features other than concepts that have been
added:
=== Core Features ===
* Move Semantics
* Perfect Forwarding
* constexpr
* relaxed rules for POD
* initializer lists
* uniform initialization
* Full core support for threads
* type inference with "auto"
* decltype()
* range based for loop
* lambdas
* constructor delegation
* nullptr
* enum class
* Fix for that annoying ">>" issue for template usage.
* explicit conversion operators.
* unrestricted unions
* variadict templates
* utf8, utf16, and utf32 string literals
* Raw string literals
* user defined literals
* "=default;" syntax for explicitly requesting a default constructor.
* "=delete;" syntax for explict deleing of member functions.
* long long int
* static_assert
* sizeof working on members of a class without an object of said class being
available.
=== Library features ===
* A reasonably featured threading library.
* Tuple type
* unordered containers
* regular expresions
* More rigerous random number generator framework
* Smart pointers
* type traits
* function object wrappers
* std::bind
* a fair bit more
While I would like concepts, I would rather wait a while longer for them if
it means I can use all the above sooner.
lindach...@gmail.com
> "Goran Skoric" <gskori...@googlemail.com> wrote in message
> [ --- Please see the FAQ before posting. --- ]
> [ FAQ:http://www.comeaucomputing.com/csc/faq.html ]
That is cool
David Abrahams
on Thu Jul 30 2009, Goran Skoric <gskoric88-AT-googlemail.com> wrote:
> 4. My view is that best solution would be to simplify concepts
> according to Bjarne's proposal or modify them in such maaner to
> minimize problems but not sacrifice good uses of them and accept it in
> standard.
There was substantial disagreement within the committee about how often
the problems addressed by that proposal would actually manifest
themselves, whether it would have actually made any difference in those
issues, and whether it would amount to an overall improvement. It's
just too late in the process to be fiddling with the fundamentals of
concepts in that way. If we didn't have enough implementation and usage
experience to standardize the proposal as it was (we didn't), we sure as
heck didn't have enough to standardize it with a bunch of last-minute
changes.
> Then, during next several years, when commercial implementation is
> more avalaible, there will be more data what can be improved and how,
> and than TR can be done to fix problems. In that way, C++ community
> would have a concepts, compiler vendor would be under pressure to
> implement them, which would as I said benefit all of us and give
> better chances of fixing some problems in future. Without putting them
> in standard, probably, concepts will be dead - which compiler vendor
> is going to implement them to gain neccessary practical experience for
> improving them in right direction and to be significantly used by C++
> community ?!
I think we'll see one or two efforts to implement them in open-source
compilers (watch http://cpp-next.com for details). But I agree, it's
quite hard to bootstrap significant usage experience before a standard
is established. I think we'll probably have to accept a slightly lower
standard of proof than we'd ideally like if we're ever to have concepts
in C++.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
David Abrahams
on Sun Aug 02 2009, Florian Weimer <fw-AT-deneb.enyo.de> wrote:
> * Howard Hinnant:
>
>> Actually g++-4.4 does a pretty good job with functions constrained
>> with SFINAE:
>
>> test.cpp: In function ‘int main()’:
>> test.cpp:17: error: no matching function for call to ‘f(A)’
>
> This is certainly nice, short error message, but it doesn't really
> tell you what preconditions are missing. I'm not sure if it makes
> libraries easier to use.
Yeah, this is nowhere close to what you can get from concepts. You also
don't get refinement-based overloading a la
template <ForwardIterator I>
void f(I, I);
template <RandomAccessIterator I>
void f(I, I);
without each overload's author having to know the entire overload set
ahead of time. You also don't get (nearly) full checking of templates
at definition time. These are big losses.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
David Abrahams
on Fri Aug 07 2009, Jerry Coffin <jerryvcoffin-AT-yahoo.com> wrote:
> In article <25ce403b-b866-44b3-8bbf-f60523a72208
> @r34g2000vba.googlegroups.com>, zei2...@liwest.at says...
>>
>> If I undestand correctly, one of the main reason for the removal of
>> concepts is the lack of experience.
>> I know that ConceptGCC can be used to obtain some experiences; as I
>> understand, ConceptGCC is more in the spirit of the "Indiana
>> Proposal".
>
> "More in the spirit of" may be rather understating things. ConceptGCC
> was written primarily by Douglas Gregor at Indiana University's Open
> Systems Laboratory (the leader of which is Andrew Lumsdaine).
Well, that was true initially, but then it was modified to reflect the
compromise proposals, co-authored by the Texas team, that began in
October 2005.
> Their work was based, to a large degree, on Jeremy Siek's design for
> the G language.
I dunno. Not to take anything away from G -- it yielded lots of
extremely useful information -- but G's template compilation model was
so different from C++'s (separate compilation, more like Haskell; no
concept-based overloading; no template specialization) that it's hard to
claim it as a significant basis for ConceptGCC.
> Those same three people (along with Jaako Jarvi and Ronald Garcia)
> were the authors of N1758 (the Indiana Proposal).
>
>> Are there compilers that implements the "Texas Proposal" so that one
>> can evaulate the differences between the proposals?
Nope.
>> Are there any plans for the future of ConceptGCC and other compilers
>> offering concepts?
I don't think there's much of a future for ConceptGCC itself, but I
believe we may see concepts in Clang within the next couple of years.
> TTBOMK, the only other compiler with concepts is Jeremy Siek's for
> the G language. I haven't studied G, but as I understand the
> situation, most of the concept part of the design fro ConceptC++
> (what ConceptGCC partially implements) came from G; their models (no
> pun intended) of concepts are extremely similar.
I don't think so (see above).
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
David Abrahams
on Mon Jul 20 2009, Ken Penpal <penpal.ken-AT-googlemail.com> wrote:
> Steve Clamage wrote:
>> The Committee voted to remove concepts from the version of the standard now being
> worked on
>
> Very disappointing indeed.
>
> Isn't this showing the inability to evolve of a programming language
> designed by Committee?
In a sense, the answer is yes.
While we try assiduously to avoid design work in the committee (our
charter is to "standardize existing practice"), I believe we slipped up
this time. In October 2005, when the differing ideas of two groups
working outside the committee seemed to be causing a serious and
irreparable rift within the committee, we asked them to work together
toward a compromise proposal
(http://cpp-next.com/archive/2009/08/what-happened-in-frankfurt/).
Instead of allowing everyone's work to proceed apace, we asked the
people who were making the most progress to stop, synchronize, and
maintain synchronization despite their fundamental disagreements about
what concepts should look like.
I have no doubt that, if it weren't the drag created by that compromise,
by now we'd have one or more implementations of sufficient quality to
responsibly standardize concepts, along with a useful body of usage
experience. It seemed like the only reasonable choice at the time (and
I personally worked hard on making the compromise possible), but now it
seems as though it might have been better if we were able to tolerate
more internal dissention. The committee's habit of consciously seeking
consensus is absolutely essential to producing standards the community
can believe in, but perhaps we got involved too early in the game this
time.
Andrei Alexandrescu
>
> on Sun Aug 02 2009, Florian Weimer <fw-AT-deneb.enyo.de> wrote:
>
>> * Howard Hinnant:
>>
>>> Actually g++-4.4 does a pretty good job with functions constrained
>>> with SFINAE:
>>> test.cpp: In function �int main()�:
>>> test.cpp:17: error: no matching function for call to �f(A)�
>>
>> This is certainly nice, short error message, but it doesn't really
>> tell you what preconditions are missing. I'm not sure if it makes
>> libraries easier to use.
>
> Yeah, this is nowhere close to what you can get from concepts. You also
> don't get refinement-based overloading a la
>
> template <ForwardIterator I>
> void f(I, I);
>
> template <RandomAccessIterator I>
> void f(I, I);
>
> without each overload's author having to know the entire overload set
> ahead of time. You also don't get (nearly) full checking of templates
> at definition time. These are big losses.
I've always wondered, why "nearly"? I recall having seen that
mentioned in a paper by Doug, but never saw the matter explained in
depth.
Andrei
--
Helmut Zeisel
> I believe we may see concepts in Clang within the next couple of years.
Why do you think so? On http://clang.llvm.org I did not find any
information about such plans.
Helmut
--
David Abrahams
on Wed Aug 12 2009, Andrei Alexandrescu
<SeeWebsiteForEmail-AT-erdani.org> wrote:
> David Abrahams wrote:
>>
>> on Sun Aug 02 2009, Florian Weimer <fw-AT-deneb.enyo.de> wrote:
>>
>>> * Howard Hinnant:
>>>
>>>> Actually g++-4.4 does a pretty good job with functions constrained
>>>> with SFINAE:
>>>> test.cpp: In function �int main()�:
>>>> test.cpp:17: error: no matching function for call to �f(A)�
>>>
>>> This is certainly nice, short error message, but it doesn't really
>>> tell you what preconditions are missing. I'm not sure if it makes
>>> libraries easier to use.
>>
>> Yeah, this is nowhere close to what you can get from concepts. You also
>> don't get refinement-based overloading a la
>>
>> template <ForwardIterator I>
>> void f(I, I);
>>
>> template <RandomAccessIterator I>
>> void f(I, I);
>>
>> without each overload's author having to know the entire overload set
>> ahead of time. You also don't get (nearly) full checking of templates
>> at definition time. These are big losses.
>
> I've always wondered, why "nearly"? I recall having seen that
> mentioned in a paper by Doug, but never saw the matter explained in
> depth.
Briefly, things like overloading and template specialization get in the
way of being able to make a final determination of instantiability for
*all* types because they change the game for specific types. One
particularly un-solvable example is that you can have concept-based
overloads that turn out to be ambiguous because a type models two
refinements of the same concept:
// This all checks at definition time
concept Z {};
template <Z T> int f(T) { return 0; }
template <Z T> int g(T x) { return f(x); }
// No reason we can't refine Z and provide an optimized f
concept X : Z {};
template <X T> int f(T) { return 1; }
// No reason we can't do it again.
concept Y : Z {};
template <Y T> int f(T) { return 2; }
// struct A models both X and Y (and therefore Z).
struct A {};
concept_map X<A> {}
concept_map Y<A> {}
// All concepts are satisifed here, but oops...
// g's *instantiation* fails (the call to f is ambiguous).
int x = g(A());
HTH,
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
David Abrahams
on Wed Aug 12 2009, Helmut Zeisel <zei2006q1-AT-liwest.at> wrote:
> On Aug 11, 10:08 pm, David Abrahams <d...@boostpro.com> wrote:
>
>> I believe we may see concepts in Clang within the next couple of years.
>
> Why do you think so?
Click Doug Gregor's name at
http://cpp-next.com/archive/2009/08/what-happened-in-frankfurt/ to see
why ;-)
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]
georg...@gmail.com
> > Isn't this showing the inability to evolve of a programming language
> > designed by Committee?
>
> In a sense, the answer is yes.
> I have no doubt that, if it weren't the drag created by that compromise,
> by now we'd have one or more implementations of sufficient quality to
> responsibly standardize concepts, along with a useful body of usage
> experience. It seemed like the only reasonable choice at the time (and
> I personally worked hard on making the compromise possible), but now
I'm interested in how that avenue would have been different in the
end. Wouldn't you have just ended up with two different
implementations with fundamental differences and have been unable to
decide which was better?
Assuming that the designs were significantly orthogonal enough to have
been unable to come up with a workable compromise, what good would it
have done to have two orthogonal implementations?
--
David Abrahams
> On Aug 11, 5:07 pm, David Abrahams <d...@boostpro.com> wrote:
>> > Isn't this showing the inability to evolve of a programming language
>> > designed by Committee?
>>
>> In a sense, the answer is yes.
> [SNIP]
>> I have no doubt that, if it weren't the drag created by that compromise,
>> by now we'd have one or more implementations of sufficient quality to
>> responsibly standardize concepts, along with a useful body of usage
>> experience. It seemed like the only reasonable choice at the time (and
>> I personally worked hard on making the compromise possible), but now
>
> I'm interested in how that avenue would have been different in the
> end. Wouldn't you have just ended up with two different
> implementations with fundamental differences and have been unable to
> decide which was better?
>
> Assuming that the designs were significantly orthogonal enough to have
> been unable to come up with a workable compromise, what good would it
> have done to have two orthogonal implementations?
Good questions.
I think a there's a good chance that we'd have ended up with only one
implementation of reasonable quality, or that the proposals would have
been driven closer together.
Producing an implementation and getting real usage experience have a way
of bringing things into sharper focus. A proposal's internal
contradictions have to be resolved one way or another, and its vague
areas must be nailed down. Ideas that are provably unimplementable have
to be definitively dropped. Concerns about usability can be clearly
shown to be serious problems, or not, for realistic use cases.
These pressures, along with the fact that producing an implementation
and usage experience is a great deal of work, will tend to winnow the
field of competing designs. So I'd be really surprised if we were
presented with two equally well-proven proposals, but if we were, we'd
have tools for making a choice that we don't have today, like the
opinions of an informed and experienced user community.
--
Dave Abrahams
BoostPro Computing
http://www.boostpro.com
[ comp.std.c++ is moderated. To submit articles, try just posting with ]