ConceptGCC 4.3.0 Alpha 6 is now available
ConceptGCC is a prototype implementation of the Concepts language feature for C++0x, which offers improved type-checking for C++ templates and complete support for the Generic Programming paradigm. ConceptGCC 4.3.0 alpha 6 provides many improvements over previous versions of ConceptGCC, including support for the concept syntax introduced by the latest concepts proposal, N2193, along with support for many other C++0x features, such as: - Rvalue references - Right angle brackets - Default template arguments for function templates - Delegating constructors - decltype - Static assertions - C99 preprocessor - Variadic templates - Range-based for loop Source code and pre-compiled binaries for various platforms are available on the ConceptGCC download page at: http://www.generic-programming.org/software/ConceptGCC/download.php For more information about concepts, please see: http://www.generic-programming.org/languages/conceptcpp/ Doug Gregor Open Systems Lab @ Indiana University
Douglas Gregor wrote:
ConceptGCC is a prototype implementation of the Concepts language feature for C++0x, which offers improved type-checking for C++ templates and complete support for the Generic Programming paradigm.
ConceptGCC 4.3.0 alpha 6 provides many improvements over previous versions of ConceptGCC, including support for the concept syntax introduced by the latest concepts proposal, N2193, along with support for many other C++0x features, such as: - Rvalue references - Right angle brackets - Default template arguments for function templates - Delegating constructors - decltype - Static assertions - C99 preprocessor - Variadic templates - Range-based for loop
Source code and pre-compiled binaries for various platforms are available on the ConceptGCC download page at:
http://www.generic-programming.org/software/ConceptGCC/download.php
Thank you. This is awesome. A version of GCC, and even precompiled binaries, with all those C++0x features is a good thing as it will allow early usage and spreading of those new features. Could you give more info about the incompability between variadic templates and concepts though?
On Apr 12, 2007, at 12:16 AM, Mathias Gaunard wrote:
Thank you. This is awesome.
A version of GCC, and even precompiled binaries, with all those C++0x features is a good thing as it will allow early usage and spreading of those new features.
The "OSL5" regression tester for Boost CVS HEAD tests a version of GCC with all of those C++0x features *except* concepts, so we can start (conditionally) using these features in Boost libraries.
Could you give more info about the incompability between variadic templates and concepts though?
Don't write a constrained template (i.e., one with any concept requirements placed on it) that uses variadic templates, e.g., the following will probably crash: auto concept OutputStreamable<typename T> { std::ostream operator<<(std::ostream&, const T&); } void print() { } template<typename T, typename... Rest> requires OutputStreamable<T>, OutputStreamable<Rest>... void print(const T& x, const Rest&... rest) { print(x); print(rest...); } Take away the "requires" clause and it should be fine, because you would be using variadic templates separately from concepts. Cheers, Doug
On 4/12/07, Douglas Gregor <doug.gregor@gmail.com> wrote:
On Apr 12, 2007, at 12:16 AM, Mathias Gaunard wrote:
Thank you. This is awesome.
A version of GCC, and even precompiled binaries, with all those C++0x features is a good thing as it will allow early usage and spreading of those new features.
The "OSL5" regression tester for Boost CVS HEAD tests a version of GCC with all of those C++0x features *except* concepts, so we can start (conditionally) using these features in Boost libraries.
So, libraries could begin providing features that rely on decltype even if the features won't be available on all compilers, so long as the user has some way to conditionally include the features? I'm wondering if/when Boost can offer a result_of implementation using decltype along the lines of your suggested in N1454 (or typeof if reference preservation is not necessary). Perhaps, Boost.TR1 could provide a result_of that adheres to the current TR1 proposal and Boost.Utility could provide a decltype-based result_of. Also, I believe Boost.Typeof has library-based facilities for auto and typeof but not decltype. Is there any chance of that happening on the horizon? Thanks, Daniel
On Apr 13, 2007, at 3:24 PM, Daniel Walker wrote:
On 4/12/07, Douglas Gregor <doug.gregor@gmail.com> wrote:
On Apr 12, 2007, at 12:16 AM, Mathias Gaunard wrote:
Thank you. This is awesome.
A version of GCC, and even precompiled binaries, with all those C+ +0x features is a good thing as it will allow early usage and spreading of those new features.
The "OSL5" regression tester for Boost CVS HEAD tests a version of GCC with all of those C++0x features *except* concepts, so we can start (conditionally) using these features in Boost libraries.
So, libraries could begin providing features that rely on decltype even if the features won't be available on all compilers, so long as the user has some way to conditionally include the features?
Yes. The Config library has macros for some C++0x features (e.g., BOOST_HAS_RVALUE_REFS)
I'm wondering if/when Boost can offer a result_of implementation using decltype along the lines of your suggested in N1454 (or typeof if reference preservation is not necessary). Perhaps, Boost.TR1 could provide a result_of that adheres to the current TR1 proposal and Boost.Utility could provide a decltype-based result_of.
The TR1 result_of is allowed to use compiler magic (read: decltype) to get the right answer, so yes, this is entirely possible and could probably be done now relatively easily. Cheers, Doug
participants (3)
-
Daniel Walker -
Douglas Gregor -
Mathias Gaunard