[C++0x] Report from Frankfurt committee meeting
The C++ standards committee met in Frankfurt, Germany, last week. Key actions: * Concepts have been removed from C++0x. The committee is very much in favor of Concepts. But Concepts are seen as so important that they have to be right. And the strong consensus was that getting Concepts right, for any reasonable definition of "right", would add several years to the schedule. There was also a consensus that an implementation of a compiler that could compile the entire standard library is part of the definition of "right". While ConceptGCC has been a great help, it isn't there as far as validating "right". Personally, I think Clang may end up being the compiler that eventually validates Concepts. * The range-based for loop and some other library features that were dependent on Concepts will be retained by recasting them to no longer depend on Concepts. See a paper in the upcoming post-meeting mailing to see how range-based for loops will work. * A second Committee Draft (CD2) will need go out for public comment in the Spring or Summer 2010, given the amount of change required to remove Concepts. The C++0x final schedule will thus slip about one year. * No committee action was taken as to how Concepts will eventually make it into C++. While there was a bit of discussion about doing a Concepts Technical Report (TR), there was no such proposal made. Committee members seem to lean toward letting the two rival Concept teams go back to work outside of the committee process. The expectation being they will come back to the committee when they are ready to restart the standardization process. Hopefully the lessons learned about Concepts during the committee process will be taken advantage of, so future standardization of Concepts will be smoother. My personal opinion is that removing Concepts will speed the arrival of conforming C++0x compilers. GCC, for example, has already implemented much of C++0x, so their key developers are no longer faced with the difficult task of turning ConceptGCC into a production compiler, and can concentrate on remaining major features like lambdas. Although Concepts would have added a lot to C++ and Boost, Concepts would also have presented major migration challenges. I'm thinking that for most Boost libraries, migration to C++0x will now be easier and less disruptive. We need to focus on the bright side. --Beman
That's a pity - a lot of libraries could have greatly benefitted from concepts. On the plus side, we really don't want to end up with a repeat of the export debacle or similar.
Joseph Gauterin wrote:
That's a pity - a lot of libraries could have greatly benefitted from concepts. On the plus side, we really don't want to end up with a repeat of the export debacle or similar. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I think it is a tragedy. While reading about why not to use C++, or STL, or Boost, the biggest issue I've seen recently is "template error messages are too large and meaningless". Bjarne has said that one C++0x's was to make it more user friendly, but it appears we will lose the biggest feature towards that goal. Also, export is an entirely different issue with a much narrower potential usage scenarios.
I think it is a tragedy. While reading about why not to use C++, or STL, or Boost, the biggest issue I've seen recently is "template error messages are too large and meaningless". Bjarne has said that one C++0x's was to make it more user friendly, but it appears we will lose the biggest feature towards that goal.
I don't think it's such a big deal. You need training to do C++/STL/Boost. The template error messages are certainly not helpful but certainly not the biggest obstacle. An over-ambitious new revision of the standard would result in a myriad of compilers that differently support the said revision (and I think it's going to be the case for a while anyway). I'm just looking forward to have something released. It's going to send a very positive signal. I'm happy to have lambdas (even if they are not fully generic), auto, rvalues, static_assert... There is always room for improvement, as we say in French, the best can be the enemy of the good... -- EA __________ Information from ESET NOD32 Antivirus, version of virus signature database 4262 (20090720) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com
On Mon, Jul 20, 2009 at 2:52 PM, Raindog <raindog@macrohmasheen.com> wrote:
Joseph Gauterin wrote:
That's a pity - a lot of libraries could have greatly benefitted from concepts. On the plus side, we really don't want to end up with a repeat of the export debacle or similar. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I think it is a tragedy. While reading about why not to use C++, or STL, or Boost, the biggest issue I've seen recently is "template error messages are too large and meaningless". Bjarne has said that one C++0x's was to make it more user friendly, but it appears we will lose the biggest feature towards that goal.
Disappointing, but hardly tragic. It would have been tragic if the standard adopted a definition of concepts that failed to improve support for generic programming or made it worse worse. I think Doug Gregor - somewhere in the comments here: http://cpp-next.com/archive/2009/08/what-happened-in-frankfurt/ - summarizes the problem nicely. "What was missing from these discussions was the input of everyday
programmers: we lacked enough usage experience with concepts to determine whether potential problems would affect real-world code, or how often these problems would occur".
Andrew Sutton andrew.n.sutton@gmail.com
Would it not be possible to produce something like a "C++ Lint" (missing clever name here). Which would be a) Written in portable C++ b) Would permit "concept" syntax to be added in as a tagged comment like /* indiana concept syntax ... */ which would produce concept errors. This would a) be a practical tool for working programmers b) would be useful regardless of the C++ compiler being used c) would be quicker and easier to make than a full compiler d) wouldn't have to be very fast as it would only be invoked "occasionally" e) would provide feedback to the C++ community regarding the utility and practicality of any concept proposal. Robert Ramey Andrew Sutton wrote:
On Mon, Jul 20, 2009 at 2:52 PM, Raindog <raindog@macrohmasheen.com> wrote:
Joseph Gauterin wrote:
That's a pity - a lot of libraries could have greatly benefitted from concepts. On the plus side, we really don't want to end up with a repeat of the export debacle or similar. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
I think it is a tragedy. While reading about why not to use C++, or STL, or Boost, the biggest issue I've seen recently is "template error messages are too large and meaningless". Bjarne has said that one C++0x's was to make it more user friendly, but it appears we will lose the biggest feature towards that goal.
Disappointing, but hardly tragic. It would have been tragic if the standard adopted a definition of concepts that failed to improve support for generic programming or made it worse worse. I think Doug Gregor - somewhere in the comments here: http://cpp-next.com/archive/2009/08/what-happened-in-frankfurt/ - summarizes the problem nicely.
"What was missing from these discussions was the input of everyday
programmers: we lacked enough usage experience with concepts to determine whether potential problems would affect real-world code, or how often these problems would occur".
Andrew Sutton andrew.n.sutton@gmail.com _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Robert Ramey wrote:
Would it not be possible to produce something like a "C++ Lint" (missing clever name here). Which would be
a) Written in portable C++ b) Would permit "concept" syntax to be added in as a tagged comment like
/* indiana concept syntax ... */
which would produce concept errors.
This would
a) be a practical tool for working programmers b) would be useful regardless of the C++ compiler being used c) would be quicker and easier to make than a full compiler d) wouldn't have to be very fast as it would only be invoked "occasionally" e) would provide feedback to the C++ community regarding the utility and practicality of any concept proposal.
From my limited understanding of the concepts proposals (I'm an "average programmer"), there were some cases where overriding on concepts should apply to allow for optimizations in some cases (e.g., random-access vs. bidirectional iterators). I don't think "C++ Lint" would allow that. It would still be useful in other cases, but I don't think it could substitute for an in-compiler reference implementation. --Jeffrey Bosboom
Robert Ramey schrieb am Dienstag 11 August 2009 um 22:00:
Would it not be possible to produce something like a "C++ Lint" (missing clever name here). Which would be
a) Written in portable C++ b) Would permit "concept" syntax to be added in as a tagged comment like
/* indiana concept syntax ... */
which would produce concept errors.
This would
a) be a practical tool for working programmers b) would be useful regardless of the C++ compiler being used c) would be quicker and easier to make than a full compiler d) wouldn't have to be very fast as it would only be invoked "occasionally" e) would provide feedback to the C++ community regarding the utility and practicality of any concept proposal.
Robert Ramey
Putting aside the fact that I'm not qualified to comment on this... I wonder if llvm's clang would be good base for such an effort, given that the dependencies it introduces are not to much of a hassle. If I got it right clang is, as llvm itself, mostly a set of libraries. So one day the code in the to be written "Lint" library might end up being used for clang's C++-Concept implementation. Yay! -- Maik
Robert Ramey wrote:
Would it not be possible to produce something like a "C++ Lint" (missing clever name here). Which would be
a) Written in portable C++ b) Would permit "concept" syntax to be added in as a tagged comment like
/* indiana concept syntax ... */
Why not just use Boost.ConceptCheck. The library could be improved to generate error messages just as good as the ones concepts provide.
on Wed Aug 12 2009, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
Robert Ramey wrote:
Would it not be possible to produce something like a "C++ Lint" (missing clever name here). Which would be
a) Written in portable C++ b) Would permit "concept" syntax to be added in as a tagged comment like
/* indiana concept syntax ... */
Why not just use Boost.ConceptCheck. The library could be improved to generate error messages just as good as the ones concepts provide.
a. I doubt we could do as well with error messages b. It would be slower (at compile time) c. It wouldn't have the right syntax d. It wouldn't do the right thing -- Dave Abrahams BoostPro Computing http://www.boostpro.com
David Abrahams wrote:
on Wed Aug 12 2009, Mathias Gaunard <mathias.gaunard-AT-ens-lyon.org> wrote:
Robert Ramey wrote:
Would it not be possible to produce something like a "C++ Lint" (missing clever name here). Which would be
a) Written in portable C++ b) Would permit "concept" syntax to be added in as a tagged comment like
/* indiana concept syntax ... */ Why not just use Boost.ConceptCheck. The library could be improved to generate error messages just as good as the ones concepts provide.
a. I doubt we could do as well with error messages b. It would be slower (at compile time) c. It wouldn't have the right syntax d. It wouldn't do the right thing
<aside> I bet for C++0x compilers that support SFINAE on expressions, we could build a much nicer Boost.ConceptCheck library. I'd be curious to see how far we could go. </aside> -- Eric Niebler BoostPro Computing http://www.boostpro.com
<aside> I bet for C++0x compilers that support SFINAE on expressions, we could build a much nicer Boost.ConceptCheck library. I'd be curious to see how far we could go. </aside>
You can go pretty far. I've been working on exactly this problem for the past week or so. I've basically taken the approach of treating requirements (i.e., of the form Iterator<X>) as a facade for type traits-style queries and Boost.ConceptCheck style-assertions (among other things). But, to address Dave's concerns:
a. I doubt we could do as well with error messages
You can't, but static_assert helps a bit.
b. It would be slower (at compile time)
It seems to be faster than ConceptGCC, but I agree that a compiler could do it better.
c. It wouldn't have the right syntax
Well, no. You can get close to "approximating" the syntax, but a real grammar would be better. Also, there are also some features that are essentially impossible to implement outside the compiler. Partially ordering overloads based on the most-refined model is one example.
d. It wouldn't do the right thing
What's the right thing, in this case? I have a couple of issues to work out, but I think I'll have a first draft of the library ready in the next day or so. I'll try to post a link and coherent introduction and overview then. Andrew Sutton andrew.n.sutton@gmail.com
Andrew Sutton wrote: I'm also replying to Dave Abrahams here.
a. I doubt we could do as well with error messages
You can't, but static_assert helps a bit.
What exactly can't be done? Let's consider function templates. Using concepts, the overload is masked if the concept is not fulfilled. Using SFINAE, the overload is masked if the expressions lead to errors. In both cases, the compiler just says there is no match, and eventually gives a list of possible matches.
b. It would be slower (at compile time)
Similarly to a C++-Lint-like tool, it would only be run for debugging purposes.
c. It wouldn't have the right syntax
Well, personally, I think defining concepts in terms of expressions is better than doing so in terms of signatures. But is the syntax really important?
d. It wouldn't do the right thing
The goal is not to be the same as the former C++0x concepts, but to provide an effective compile-time debugging and type checking mechanism with nice error messages.
I'm curious about the concept of concepts. I looked into the current library and it looked interesting but the syntax seemed sort of opaque - at least to my in experienced eye. I searched in boost for libraries which use the concept library. I didn't find any. This was a surprise to given the benefits that are anticipated from it. I guessed that the C++ template metaprogram implemenation was lacking in some way. I don't know what way, but I didn't want to be the first to add it to a boost library. I've had a lot of reservations about adding anything to a standard which hasn't had wide usage. It's just to hard to get anything complicated right the first time. I proposed the idea of writing a "lint-like" program in order to: a) provide a tool that could be used by "the rest of us" b) on our programs and libraries c) in a non-intrusive, reversable manner d) to provide help to library maintainers and users e) which would also provide real world feed back to those who are designing the feature. Enhancing the concepts library might be useful for part of the above but not all of it. I don't know that such a "lint-like" program is even possible. If adding concepts to a program actually changes the code generated, that might make it undoable. If it wasn't possible, to make such a program, that would also be interesting to know. Looking back in the past, one if the principle usages of the lint program was to verify that the types of the parameters being passed to functions matched the types of parameters being used as arguments in function calls. After a time, this facility migrated into the compilers themselves and eventually into the standard. The transition was almost painless. I see a strong parallel with the checking of parameters for template instantiations. Robert Ramey
I'm curious about the concept of concepts. I looked into the current library and it looked interesting but the syntax seemed sort of opaque - at least to my in experienced eye. I searched in boost for libraries which use the concept library. I didn't find any. This was a surprise to given the benefits that are anticipated from it. I guessed that the C++ template metaprogram implemenation was lacking in some way. I don't know what way, but I didn't want to be the first to add it to a boost library.
I've had a lot of reservations about adding anything to a standard which hasn't had wide usage. It's just to hard to get anything complicated right the first time. I proposed the idea of writing a "lint-like" program in order to:
I think that you have nicely summarized the single largest problem here - very few people have any experience developing with concepts - as you've found surveying the Boost libraries. By the way, the BGL uses concepts extensively. Beyond that, writing and using concepts is /hard/. Concepts are pure design. You're trying to describe broad classes of types, but not necessarily writing something functional. Get it wrong, and you exclude valid abstractions, or admit those that don't work. Try it: what's a "list"? Maybe part of the issue is that we're being given a solution without really understanding the problems. To be fair, I would claim that you /did/ find concepts and concept-related techniques being used, but you would probably see them as tag dispatch, traits classes, type traits, SFINAE techniques, etc. Andrew Sutton andrew.n.sutton@gmail.com
Mathias Gaunard-2 wrote:
Andrew Sutton wrote:
I'm also replying to Dave Abrahams here.
a. I doubt we could do as well with error messages
You can't, but static_assert helps a bit.
What exactly can't be done? Let's consider function templates. Using concepts, the overload is masked if the concept is not fulfilled. Using SFINAE, the overload is masked if the expressions lead to errors.
In both cases, the compiler just says there is no match, and eventually gives a list of possible matches.
When you talk about using SFINAE, are you thinking on the Concept Traits library (http://neoscientists.org/~tschwinger/boostdev/concept_traits/libs/concept_tr...) that Terje Slettebø and Tobias Schwinger have abandoned because the C++0x should have Concepts?
c. It wouldn't have the right syntax
Well, personally, I think defining concepts in terms of expressions is better than doing so in terms of signatures. But is the syntax really important?
Not to me. What is important is that this will allows people to experiment with Concepts in a portable way waiting for the new standard. The transition should be much more smooth.
d. It wouldn't do the right thing
we can approximate with SFINAE partial ordering, isn't it? Best, Vicente -- View this message in context: http://www.nabble.com/-C%2B%2B0x--Report-from-Frankfurt-committee-meeting-tp... Sent from the Boost - Dev mailing list archive at Nabble.com.
Vicente Botet Escriba wrote:
When you talk about using SFINAE, are you thinking on the Concept Traits library (http://neoscientists.org/~tschwinger/boostdev/concept_traits/libs/concept_tr...) that Terje Slettebø and Tobias Schwinger have abandoned because the C++0x should have Concepts?
Well, any hope this can be ressurected ? I jsut glanced over the doc and examples and it's rather impressive -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
Vicente Botet Escriba wrote:
When you talk about using SFINAE, are you thinking on the Concept Traits library (http://neoscientists.org/~tschwinger/boostdev/concept_traits/libs/concept_tr...) that Terje Slettebø and Tobias Schwinger have abandoned because the C++0x should have Concepts?
Well, any hope this can be ressurected ? I jsut glanced over the doc and examples and it's rather impressive
+1 from here, John.
Vicente Botet Escriba wrote:
When you talk about using SFINAE, are you thinking on the Concept Traits library (http://neoscientists.org/~tschwinger/boostdev/concept_traits/libs/concept_tr...) that Terje Slettebø and Tobias Schwinger have abandoned because the C++0x should have Concepts?
No, I'm thinking of using SFINAE generalized for expressions (note that this requires a compiler which supports the feature, such as GCC 4.4+), that is to say to put the expressions to check for directly in the signature of the overload, be it with sizeof or decltype. For example, to check a variant of the Callable2<F, T1, T2> concept, template<int> struct dummy {}; template<typename T> T& make(); template<typename F, typename T1, typename T2> char callable2_impl(dummy<sizeof( typename F::result_type( make<F>()( make<T1>(), make<T2>() ) ) , 0)>*); template<typename F, typename T1, typename T2> char (&callable2_impl(...))[2]; template<typename F, typename T1, typename T2> struct Callable2 : mpl::bool_<sizeof(callable2_impl<F, T1, T2>(0)) == 1> { }; Then you can just test for the Callable2 concept using enable_if or BOOST_MPL_ASSERT. (the syntax for declaring concepts would of course use the preprocessor instead of directly writing this) Unfortunately using std:::result_of<F(T1, T2)>::type instead of F::result_type doesn't work, since the substitution failure happens within the definition of result_of, but that should be solvable. I believe things like associated types can be integrated as well. This isn't as nice to write as the current system Boost.ConceptCheck uses however, which allows to use private members instead of make<T> thingies.
No, I'm thinking of using SFINAE generalized for expressions (note that this requires a compiler which supports the feature, such as GCC 4.4+), that is to say to put the expressions to check for directly in the signature of the overload, be it with sizeof or decltype.
For example, to check a variant of the Callable2<F, T1, T2> concept,
template<int> struct dummy {}; template<typename T> T& make();
template<typename F, typename T1, typename T2> char callable2_impl(dummy<sizeof( typename F::result_type( make<F>()( make<T1>(), make<T2>() ) ) , 0)>*);
template<typename F, typename T1, typename T2> char (&callable2_impl(...))[2];
template<typename F, typename T1, typename T2> struct Callable2 : mpl::bool_<sizeof(callable2_impl<F, T1, T2>(0)) == 1> { };
That seems overly complicated. Why not... template <typename...> failed call(...); template <typename F, typename... Args> auto call(F&& f, Args... args) -> decltype(f(args...)); template <typename F, typename... Args> struct is_callable : not<is_same<decltype(call<F, Args...>(F(), Args()...)), failed>::type> { }; I'm waving my hands a bit since F() and Args() require everything to be default constructible, but you can get around that with some clever metaprogramming machinery and fake accessor functions. It's worth pointing out that the this decltype trick works for pretty much any possible query. Unfortunately, it fails (compilation) if f(args...) is private, but hey... It works for most functions and functors, and that's not bad. Caveat: you probably need an SVN build of GCC to actually make that work without internal compiler errors :) Andrew Sutton andrew.n.sutton@gmail.com
Andrew Sutton wrote:
That seems overly complicated. Why not...
template <typename...> failed call(...); template <typename F, typename... Args> auto call(F&& f, Args... args) -> decltype(f(args...));
Because that's C++0x, while my code is C++03.
I'm waving my hands a bit since F() and Args() require everything to be default constructible, but you can get around that with some clever metaprogramming machinery and fake accessor functions.
Which is why I use make<T>() instead of T().
Caveat: you probably need an SVN build of GCC to actually make that work without internal compiler errors :)
I've had no problem at all with a standard GCC 4.4 build. What kind of ICEs are they? If it's mangling issues, they're not very hard to circumvent usually.
I'm not writing for C++03. "Start fresh". That's my motto. (It isn't really).
I'm waving my hands a bit since F() and Args() require everything to be
default constructible, but you can get around that with some clever metaprogramming machinery and fake accessor functions.
Which is why I use make<T>() instead of T().
I used something similar (cons<T>), which is specialized for lvalue, rvalue references.
Caveat: you probably need an SVN build of GCC to actually make that work
without internal compiler errors :)
I've had no problem at all with a standard GCC 4.4 build. What kind of ICEs are they? If it's mangling issues, they're not very hard to circumvent usually.
With GCC 4.5... It wasn't this particular example - and it may have just been a regression - but I had an ICE using a similar technique when trying to determine if list<int>::iterator (i.e. list_iterator<int> or whatever it is) had an operator*. The error was in tsubst_copy, but it seems to have gone away. Andrew Sutton andrew.n.sutton@gmail.com
on Wed Aug 12 2009, Andrew Sutton <andrew.n.sutton-AT-gmail.com> wrote:
d. It wouldn't do the right thing
What's the right thing, in this case?
Partially ordering overloads based on the most-refined model ;-) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
This is probably going to piss some people off, but what the hay... I was truly disappointed, myself, about Concepts being postponed until future notice, but then starting thinking about why this is all taking so long? I mean, the C# people come out with language changes every couple of years without any fuss or muss. But the C++ masterminds, I mean all those guys with PHD's as well as the programming gurus, cannot figure out the next stage after 10 years. What's going on? Does it really matter what comes out of this committee? I don't care as long as I have something better, and I don't think the compiler writers care either; they're just waiting for something, anything. Maybe I'm not seeing the big picture, but I'm starting to think the committee is overdoing it. -Sid
Sid Sacek wrote:
I mean, the C# people come out with language changes every couple of years without any fuss or muss. But the C++ masterminds, I mean all those guys with PHD's as well as the programming gurus, cannot figure out the next stage after 10 years. What's going on?
I'm not familiar with C#, so I don't know what these language changes are. They may be less complex than concepts. Also, C++ is used in many more applications than C#, so there are more potential impacts to consider when making language changes. Finally, C# can be changed unilaterally by Microsoft, without concern for other users.
Does it really matter what comes out of this committee? I don't care as long as I have something better, and I don't think the compiler writers care either; they're just waiting for something, anything.
Would you accept something worse? That's what we almost ended up with (in my opinion, anyway). The concern was that not only would concepts in their current form not be used by "everyday programmers", but also that there would be no way to fix this later -- once (some) people start using it, it becomes a backwards-compatibility concern. --Jeffrey Bosboom
Sid Sacek wrote:
I mean, the C# people come out with language changes every couple of years without any fuss or muss. But the C++ masterminds, I mean all those guys with PHD's as well as the programming gurus, cannot figure out the next stage after 10 years. What's going on?
The C++ Committee is *all volunteer*. The proposals are all from *volunteers*. They do what they can to make C++ stable while advancing it. That's part of what Boost is about: try new things and use them to inform the next standard. Microsoft, OTOH, gets to make any change they like and their customers have to deal accordingly. Sure, MS doesn't want to irritate their customers too much, but they can get away with a lot. Furthermore, they have only their previous version with which to be compatible rather than having to worry about C, for example. This gives MS a lot of leeway.
Does it really matter what comes out of this committee? I don't care as long as I have something better, and I don't think the compiler writers care either; they're just waiting for something, anything.
Who decides what is better? If you let vendors create something new as if it were standard, rather than requiring that you use special namespaces, __'s, etc. to access them, then you get great fragmentation of the language and lose portability.
Maybe I'm not seeing the big picture, but I'm starting to think the committee is overdoing it.
Volunteer your time. I'm sure they'd be happy to have the extra help. _____ Rob Stewart robert.stewart@sig.com Software Engineer, Core Software using std::disclaimer; Susquehanna International Group, LLP http://www.sig.com IMPORTANT: The information contained in this email and/or its attachments is confidential. If you are not the intended recipient, please notify the sender immediately by reply and immediately delete this message and all its attachments. Any review, use, reproduction, disclosure or dissemination of this message or any attachment by an unintended recipient is strictly prohibited. Neither this message nor any attachment is intended as or should be construed as an offer, solicitation or recommendation to buy or sell any security or other financial instrument. Neither the sender, his or her employer nor any of their respective affiliates makes any warranties as to the completeness or accuracy of any of the information contained herein or that this message or any of its attachments is free of viruses.
2009/8/12 Stewart, Robert <Robert.Stewart@sig.com>:
Microsoft, OTOH, gets to make any change they like and their customers have to deal accordingly. Sure, MS doesn't want to irritate their customers too much, but they can get away with a lot. Furthermore, they have only their previous version with which to be compatible rather than having to worry about C, for example. This gives MS a lot of leeway.
And certainly with C#, it feels like much of what gets added are isolationist features, not infrastructure. And when they do build infrastruture, there are holes. (Try to write the downcast you need in "void Foo<T>(T x) where T : IFoo;" so that you can pass x to "void Bar<U>(U x) where T : IFoo, IBar;", for example.)
Scott McMurray wrote:
And when they do build infrastruture, there are holes. (Try to write the downcast you need in "void Foo<T>(T x) where T : IFoo;" so that you can pass x to "void Bar<U>(U x) where T : IFoo, IBar;", for example.)
Disallowing downcasting, which is inherently unsafe, sounds more like a design decision than a hole in the system. Use overloading instead to visit the possible values. (just a wild guess, I know nothing of C# generics)
on Wed Aug 12 2009, Eric Niebler <eric-AT-boostpro.com> wrote:
<aside> I bet for C++0x compilers that support SFINAE on expressions, we could build a much nicer Boost.ConceptCheck library.
Yep
I'd be curious to see how far we could go. </aside>
Me too -- Dave Abrahams BoostPro Computing http://www.boostpro.com
On Thu, Aug 13, 2009 at 1:48 AM, David Abrahams<dave@boostpro.com> wrote:
on Wed Aug 12 2009, Eric Niebler <eric-AT-boostpro.com> wrote:
<aside> I bet for C++0x compilers that support SFINAE on expressions, we could build a much nicer Boost.ConceptCheck library.
Yep
As others have already pointed out, static_assert is also helpful. It can generate much more targeted error messages. Function template argument defaults are also very helpful, since enable_if can be applied to the template argument rather than a function argument or return value. That results in cleaner, easier-to-read, code.
I'd be curious to see how far we could go. </aside>
Ditto. --Beman
Beman Dawes wrote:
Function template argument defaults are also very helpful, since enable_if can be applied to the template argument rather than a function argument or return value. That results in cleaner, easier-to-read, code.
Sorry for the off-topicness but, are they any sample use-case for enable_if in template argument somewhere to look at ? -- ___________________________________________ Joel Falcou - Assistant Professor PARALL Team - LRI - Universite Paris Sud XI Tel : (+33)1 69 15 66 35
On Aug 15, 2009, at 10:09 AM, joel wrote:
Beman Dawes wrote:
Function template argument defaults are also very helpful, since enable_if can be applied to the template argument rather than a function argument or return value. That results in cleaner, easier-to-read, code.
Sorry for the off-topicness but, are they any sample use-case for enable_if in template argument somewhere to look at ?
http://home.roadrunner.com/~hinnant/issue_review/lwg-active.html#1054 -Howard
Function template argument defaults are also very helpful, since
enable_if can be applied to the template argument rather than a function argument or return value. That results in cleaner, easier-to-read, code.
Sorry for the off-topicness but, are they any sample use-case for enable_if in template argument somewhere to look at ?
I've actually been experimenting with this for the last couple of days, and have been having some problems overloading with enable_if in template parameters. The technique works fine if there is only function definition. Given multiple overloads, the compiler (for me, GCC 4.5) will give redefinition errors. template < typename T, typename = typename enable_if<std::is_integral<T>>::type> void foo(T const&) { cout << "1\n"; } template < typename T, typename = typename disable_if<std::is_integral<T>>::type> void foo(T const&) { cout << "2\n"; } It doesn't work if you try to push some part of the enable_if into the function declaration either. Fopr example, if you use the form: template < typename T, typename Enabler = typename enable_if<std::is_integral<T>>::type> Enabler foo(T const&) Still a redefinition. What about? template < typename T, typename Enabler = enable_if<std::is_integral<T>>> typename Enabler::type foo(T const&) Still a redefinition. It doesn't really seem to matter how you try to write or force the enable_if to work, the compiler seems to want to call these the same function - which, I suppose they are until you try to instantiate them. The only thing that does (still) work is to write the enabler as a return type or function parameter. It may also be the case that this is supposed to work, but hasn't been implemented by GCC. I'm not certain. Andrew Sutton andrew.n.sutton@gmail.com
Was there any discussion regarding 'noexcept' or any other alternative to it? -Sid Sacek -----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes Subject: [boost] [C++0x] Report from Frankfurt committee meeting The C++ standards committee met in Frankfurt, Germany, last week. Key actions: * Concepts have been removed from C++0x.
On Jul 20, 2009, at 11:56 AM, Sid Sacek wrote:
Was there any discussion regarding 'noexcept' or any other alternative to it? -Sid Sacek
Yes. There is great reluctance to introducing a new keyword at this late date. Instead, recycling an old keyword or two in a new context is much preferred. The front running solution at this point is: void f(arguments...) do not throw while using this { // ... } -Howard My apologies to the original authors (you know who you are) for plagiarizing your brilliant sense of humor. :-)
on Mon Jul 20 2009, Beman Dawes <bdawes-AT-acm.org> wrote:
The C++ standards committee met in Frankfurt, Germany, last week. Key actions:
* Concepts have been removed from C++0x.
The committee is very much in favor of Concepts. But Concepts are seen as so important that they have to be right. And the strong consensus was that getting Concepts right, for any reasonable definition of "right", would add several years to the schedule. There was also a consensus that an implementation of a compiler that could compile the entire standard library is part of the definition of "right". While ConceptGCC has been a great help, it isn't there as far as validating "right". Personally, I think Clang may end up being the compiler that eventually validates Concepts.
More on this at http://cpp-next.com/archive/2009/08/what-happened-in-frankfurt, if anyone's interested. -- Dave Abrahams BoostPro Computing http://www.boostpro.com
participants (18)
-
Andrew Sutton -
Beman Dawes -
David Abrahams -
Edouard A. -
Eric Niebler -
Howard Hinnant -
Jeffrey Bosboom -
joel -
John Maddock -
Joseph Gauterin -
Maik Beckmann -
Mathias Gaunard -
Raindog -
Robert Ramey -
Scott McMurray -
Sid Sacek -
Stewart, Robert -
Vicente Botet Escriba