Variadic Templates Redux
A while ago I announced the availability of an implementation of "variadic templates" for GCC. Variadic templates eliminate a huge amount of redundancy in several Boost libraries (including some that have gone into TR1), such as tuples, function, bind, mem_fn, and MPL. I have now completed the compiler (everything I've thought to try works) and completely reimplemented TR1's <tuple> and <functional> headers using variadic templates. The resulting code is much smaller, clean, and compiles significantly faster that the previous versions. Compiler binaries and sources, both including the implementation of TR1, are available here: http://www.osl.iu.edu/~dgregor/cpp/variadic-templates.html I think variadic templates are a big step forward for C++ libraries that deal with function objects, forwarding, and type-lists. If you're interested, please read the documentation, hack some code with the compiler, and tell your local C++ committee representative to vote for variadic templates in C++0x :) Cheers, Doug
Doug Gregor wrote:
A while ago I announced the availability of an implementation of "variadic templates" for GCC. Variadic templates eliminate a huge amount of redundancy in several Boost libraries (including some that have gone into TR1), such as tuples, function, bind, mem_fn, and MPL. I have now completed the compiler (everything I've thought to try works) and completely reimplemented TR1's <tuple> and <functional> headers using variadic templates. The resulting code is much smaller, clean, and compiles significantly faster that the previous versions. Compiler binaries and sources, both including the implementation of TR1, are available here:
http://www.osl.iu.edu/~dgregor/cpp/variadic-templates.html
I think variadic templates are a big step forward for C++ libraries that deal with function objects, forwarding, and type-lists. If you're interested, please read the documentation, hack some code with the compiler, and tell your local C++ committee representative to vote for variadic templates in C++0x :)
FWIW, I'll add a quick word of support for this feature. I ran into this very issue with my implementation of the 'super_string' class where I wanted to have an unlimited number of template function parameters for functions like type conversion and and formatted output. It's painful to write/test all the different overloadings to an 'arbitrary level'. Honestly, I punted and didn't write as many overloads as I should have...luckily no one has complained - yet ;-) I looked at your spec when you first posted and I believe it would solve my issue quite nicely. Thanks for doing this. Jeff
Doug Gregor wrote:
A while ago I announced the availability of an implementation of "variadic templates" for GCC. Variadic templates eliminate a huge amount of redundancy in several Boost libraries (including some that have gone into TR1), such as tuples, function, bind, mem_fn, and MPL. I have now completed the compiler (everything I've thought to try works) and completely reimplemented TR1's <tuple> and <functional> headers using variadic templates. The resulting code is much smaller, clean, and compiles significantly faster that the previous versions. Compiler binaries and sources, both including the implementation of TR1, are available here:
http://www.osl.iu.edu/~dgregor/cpp/variadic-templates.html
I think variadic templates are a big step forward for C++ libraries that deal with function objects, forwarding, and type-lists. If you're interested, please read the documentation, hack some code with the compiler, and tell your local C++ committee representative to vote for variadic templates in C++0x :)
Oh man, this is awesome! Regards, -- Joel de Guzman http://www.boost-consulting.com http://spirit.sf.net
On 09/26/2006 05:12 PM, Joel de Guzman wrote:
Doug Gregor wrote:
A while ago I announced the availability of an implementation of "variadic templates" for GCC. Variadic templates eliminate a huge [snip]
Oh man, this is awesome!
Joel, I'm wondering what implications this would have for fusion containers. The variadic template tuple in: http://www.osl.iu.edu/~dgregor/cpp/variadic-templates.html is implemented roughly like fusion's cons; hence, I'm guessing it would be easy to use a slight modification of the that tuple to implement a variadic template fusion list. However, the fusion vector uses BOOST_PP_ENUM* to generate member names. To do that BOOST_PP_ENUM* requires the length of the variadic template typelist, information not available at preprocessing time. Hence, I'm wondering how a variadic template fusion vector would be implemented. Any ideas? TIA. -regards, Larry
"Larry Evans" <cppljevans@cox-internet.com> wrote in message news:efdt92$16l$1@sea.gmane.org...
Hence, I'm wondering how a variadic template fusion vector would be implemented. Any ideas?
Nope. But I'm sure it will though! :-) seems a bit like ConceptGCC has broken the sound barrier don't it :-) regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"Larry Evans" <cppljevans@cox-internet.com> wrote in message news:efdt92$16l$1@sea.gmane.org...
Hence, I'm wondering how a variadic template fusion vector would be implemented. Any ideas?
Nope. But I'm sure it will though!
:-)
seems a bit like ConceptGCC has broken the sound barrier don't it :-)
Variadics is a separate feature from what ConceptGCC provides. I know variadics are generating a lot of well-earned excitement, but think ConceptGCC really deserves more attention. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87wt7pjr73.fsf@pereiro.luannocracy.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"Larry Evans" <cppljevans@cox-internet.com> wrote in message news:efdt92$16l$1@sea.gmane.org...
Hence, I'm wondering how a variadic template fusion vector would be implemented. Any ideas?
Nope. But I'm sure it will though!
:-)
seems a bit like ConceptGCC has broken the sound barrier don't it :-)
Variadics is a separate feature from what ConceptGCC provides. I know variadics are generating a lot of well-earned excitement, but think ConceptGCC really deserves more attention.
Sure, but I for one have some trepidation about applying Concepts to everything. The main issue that worries me is that checking everything is going to be very slow. And I am not sure I totally agree. Although Variadic templates may be simpler, they look to firstly actually speed up compilation, and secondly they make tuples more like arrays. I think that means that UDT's such as those in my physical quantities library will be much easier to use. (e.g in a matrix). And that is important because,working with physical quantities rather than good old doubles really scales well. What I mean by that is that one has much better visual cues as to what the source code is doing, what the source code is. That is incredibly helpful as it relieves that sort of intense concentration, which those that have programmed in assembler might know what I'm talkng about and help you to think about the big picture and that is what I mean about scaleability. I think the combination of variadic templates and Fusion will go really well with my types and probably facilitate a lot more use of UDT's. And Variadic templates are more of something that users can use directly, though hopefully they will get the benefit of Concepts in much more helpful error messages. Anyway, All these things on the horizon together with auto and decltype are making things look up for C++ at the moment, so thanks to you Joel Alexsey, Doug Gregor and everyone else for putting the work in to realise all this. regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87wt7pjr73.fsf@pereiro.luannocracy.com...
Variadics is a separate feature from what ConceptGCC provides. I know variadics are generating a lot of well-earned excitement, but think ConceptGCC really deserves more attention.
Sure, but I for one have some trepidation about applying Concepts to everything. The main issue that worries me is that checking everything is going to be very slow.
You seem to have that concern often, and often prematurely.
And I am not sure I totally agree.
If you're disagreeing, I think it's because I wasn't clear. I meant that "ConceptGCC really deserves more attention than it is currently getting." -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:871wpxi1vb.fsf@pereiro.luannocracy.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87wt7pjr73.fsf@pereiro.luannocracy.com...
Variadics is a separate feature from what ConceptGCC provides. I know variadics are generating a lot of well-earned excitement, but think ConceptGCC really deserves more attention.
Sure, but I for one have some trepidation about applying Concepts to everything. The main issue that worries me is that checking everything is going to be very slow.
You seem to have that concern often, and often prematurely.
I often have that concern and often it's true :-). In the case of Fusion. I need the library to create matrices which work with types other than double.
And I am not sure I totally agree.
If you're disagreeing, I think it's because I wasn't clear. I meant that "ConceptGCC really deserves more attention than it is currently getting."
OK. The first question is... why? I think I can answer that for myself, but what is in it for the broader audience? For myself an important issue is that I am, due to inertia, compiler bound. I love VC7.1. I love the IDE. (IIRC you call this ' screen scraping', but that's your problem). So that is a hurdle that ConceptGCC has to face for someone like me. I have my "comp.bat" file set up for checking that stuff compiles with gcc, but for effortless coding, I head straight for VC7.1. IOW your compiler/IDE has a great deal of power over what you do And , maybe ConceptGCC has a similar 'problem'(It's not really a problem) to the one I have with Quan, but probably more severe, in that most people are bound to old C style libraries, which frankly don't have a hope of compiling with ConceptGCC, due to the average *useful* 'Hack' optimisation's that have been applied. It's simply inertia again. I think what C++ needs most of all, is a standard GUI, because with that, it would be easy to plug ConceptGCC, the compiler, into a standard IDE. And with a standard IDE, it would be quite easy to apply a couple of switches to switch compilers... So, of all the libraries that C++ should have, I think that a standard GUI is the most important, because it would be so much easier to try out and demonstrate major changes to C++. Simply put, ConceptGCC needs a nice UI to show it off, and its a bit sad that C++ has no way to provide that. I guess that is the root of the problem. ( And I am currently concerned with trying to make some inroads into that problem) regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
In the case of Fusion. I need the library to create matrices which work with types other than double.
Not really. You could have decided the abstractions provided by the library would be too expensive and coded everything by hand.
And I am not sure I totally agree.
If you're disagreeing, I think it's because I wasn't clear. I meant that "ConceptGCC really deserves more attention than it is currently getting."
OK. The first question is... why? I think I can answer that for myself, but what is in it for the broader audience?
Having concept support in the language revolutionizes the way we program with templates, and in particular, provides a massively improved experience for the casual user.
For myself an important issue is that I am, due to inertia, compiler bound. I love VC7.1. I love the IDE. (IIRC you call this ' screen scraping', but that's your problem).
No, I have never used that term, so that's your problem. Nyah nyah. I think IDEs are great and vc7.1 is a good compiler.
So that is a hurdle that ConceptGCC has to face for someone like me. I have my "comp.bat" file set up for checking that stuff compiles with gcc, but for effortless coding, I head straight for VC7.1. IOW your compiler/IDE has a great deal of power over what you do
Yep. That's why I am not tied to VS, as great as it is.
And , maybe ConceptGCC has a similar 'problem'(It's not really a problem) to the one I have with Quan, but probably more severe, in that most people are bound to old C style libraries, which frankly don't have a hope of compiling with ConceptGCC, due to the average *useful* 'Hack' optimisation's that have been applied. It's simply inertia again.
I don't know why you'd think that. If the library compiles with G++, it should compile with ConceptGCC.
I think what C++ needs most of all, is a standard GUI, because with that, it would be easy to plug ConceptGCC, the compiler, into a standard IDE.
That's what I do with emacs. It works almost dreamily well.
And with a standard IDE, it would be quite easy to apply a couple of switches to switch compilers...
Who needs switches? I just hit F7 and modify the compiler name in the command-line I have stored up for invoking bjam before hitting return. Anyway, you can do all this compiling with bjam from within VS's IDE. I know people do that.
So, of all the libraries that C++ should have, I think that a standard GUI is the most important, because it would be so much easier to try out and demonstrate major changes to C++.
I think an easily modifiable compiler framework written in C++ would strike lots closer to the mark than a standard GUI, for that purpose.
Simply put, ConceptGCC needs a nice UI to show it off, and its a bit sad that C++ has no way to provide that.
A nice UI to show off ConceptGCC? I'm giggling.
I guess that is the root of the problem.
( And I am currently concerned with trying to make some inroads into that problem)
I wish you well. I think it would be cool, but I don't think it's going to help much with core language development. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:871wpvouwx.fsf@pereiro.luannocracy.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
Simply put, ConceptGCC needs a nice UI to show it off, and its a bit sad that C++ has no way to provide that.
A nice UI to show off ConceptGCC? I'm giggling.
I guess that is the root of the problem.
( And I am currently concerned with trying to make some inroads into that problem)
I wish you well. I think it would be cool, but I don't think it's going to help much with core language development.
Depends if ConceptGCC can compile Windows Apps don't it? regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:871wpvouwx.fsf@pereiro.luannocracy.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
A nice UI to show off ConceptGCC? I'm giggling.
I guess that is the root of the problem.
( And I am currently concerned with trying to make some inroads into that problem)
I wish you well. I think it would be cool, but I don't think it's going to help much with core language development.
Depends if ConceptGCC can compile Windows Apps don't it?
Not AFAICT. And it can. -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" wrote
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"David Abrahams" <dave@boost-consulting.com> wrote in message news:871wpvouwx.fsf@pereiro.luannocracy.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
A nice UI to show off ConceptGCC? I'm giggling.
I guess that is the root of the problem.
( And I am currently concerned with trying to make some inroads into that problem)
I wish you well. I think it would be cool, but I don't think it's going to help much with core language development.
Depends if ConceptGCC can compile Windows Apps don't it?
Not AFAICT. And it can.
Well as it happens I was living in the grip of a trichotomy, regarding whether to pursue my interest in Quanta (That the name of my GUI BTW), or to delve further into the mysteries of Concepts. Anyway poor old VC7.1 just doesnt have the amps to compile the Fusion matrices in any quantity, and VC8.0... lovely optimiser but gets very confused about operators. But meanwhile good old GCC just keeps motoring on, and BTW ConceptGCC compiles faster than VC7.1 with the Quanfusion matrices, So that got me to thinking. Why not rewrite my Quan library in terms of Concepts and develop my GUI at the same time. Neat really because by the time I get the GUI to a reasonable state then Concepts will be part of the language and Quanta will be right at the cutting edge . Brilliant Eh ? Then I'll be giggling too :-) regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
Neat really because by the time I get the GUI to a reasonable state then Concepts will be part of the language and Quanta will be right at the cutting edge . Brilliant Eh ?
Great idea. We need more people exercising concept support in real code.
Then I'll be giggling too :-)
:) -- Dave Abrahams Boost Consulting www.boost-consulting.com
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87sli24t5e.fsf@pereiro.luannocracy.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
Neat really because by the time I get the GUI to a reasonable state then Concepts will be part of the language and Quanta will be right at the cutting edge . Brilliant Eh ?
Great idea. We need more people exercising concept support in real code.
Then I'll be giggling too :-)
:)
The best part is ... I don't have to write any docs... :-) (Only kidding) regards Andy Little
On Thu, 28 Sep 2006 00:23:44 +0100, "Andy Little" <andy@servocomm.freeserve.co.uk> wrote:
Sure, but I for one have some trepidation about applying Concepts to everything. The main issue that worries me is that checking everything is going to be very slow.
You seem to have that concern often, and often prematurely.
I often have that concern and often it's true :-).
Give him an inch and he'll take a yard. You don't want to reply with a smile to such sentences, really. -- Genny.
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87wt7pjr73.fsf@pereiro.luannocracy.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"Larry Evans" <cppljevans@cox-internet.com> wrote in message news:efdt92$16l$1@sea.gmane.org...
Hence, I'm wondering how a variadic template fusion vector would be implemented. Any ideas?
Nope. But I'm sure it will though!
:-)
seems a bit like ConceptGCC has broken the sound barrier don't it :-)
Variadics is a separate feature from what ConceptGCC provides. I know variadics are generating a lot of well-earned excitement, but think ConceptGCC really deserves more attention.
And a Question to Doug Gregor Does ConceptGCC support decltype and auto? Please note: this is Not a feature request, just a simple question! :-) The point of that is that I would love to try porting my Quan library to use Concepts, but for Quan, the one feature that would be the 'killer compiler' application is decltype and auto. Quan would be a nice looking library with the combination of Concepts and those features. In reality I don't know where I would find the time to do that port though. I know that gcc has problems with typeof and Boost.Typeof, in return types, so OTOH I guess this functionality may be problematic? Of course if I really want it, then I guess I ought to try sorting it out myself though shouldnt I? :-) regards Andy Little
"Andy Little" <andy@servocomm.freeserve.co.uk> wrote in message news:efft3d$5oi$1@sea.gmane.org...
"David Abrahams" <dave@boost-consulting.com> wrote in message news:87wt7pjr73.fsf@pereiro.luannocracy.com...
"Andy Little" <andy@servocomm.freeserve.co.uk> writes:
"Larry Evans" <cppljevans@cox-internet.com> wrote in message news:efdt92$16l$1@sea.gmane.org...
Hence, I'm wondering how a variadic template fusion vector would be implemented. Any ideas?
Nope. But I'm sure it will though!
:-)
seems a bit like ConceptGCC has broken the sound barrier don't it :-)
Variadics is a separate feature from what ConceptGCC provides. I know variadics are generating a lot of well-earned excitement, but think ConceptGCC really deserves more attention.
OK Here is my ConceptGCC installation for dummies guide. Probably of most use to myself :-) And BTW that is as far as I have got so far. Will try to actually compile something next! OK Hurdle 1. Many Windows users are used to zip not bz2 files, so what do I do with them?? Use gzip ??options to unzip the source. I cant remember what this is! You also need the Cygwin/bin directory in your non-Cygwin path to get gzip at the non Cygwin command prompt I used PKZip which IIRC I had to extend with something or other and then Use tar -xf conceptgcc-VERSION.tar , hence I cant remember the gzip stuff. (Replace with whatever the Cool form to extract tar.bzip2 files is) Move the resulting 'opt' directory to your Cygwin installation. In my case C:/Cygwin so the result is C:/Cygwin/opt Head for Start>Control Panel. Head for System>Advanced>Environment Variables. Find 'Path' environment variable Add The ConceptGcc bin directory e.g PREVIOUS_Stuff;C:/Cygwin/opt/conceptgcc-VERSION/bin Now check it works. Open a command prompt. (If you have Cygwin correctly installed you shouldnt need to be in Cygwin shell) type conceptg++. If all is working ok you should get: C:\my_current_dir>conceptg++ conceptg++: no input files C:\my_current_dir Next.. actually trying to compile something :-) regards Andy little
Andy Little wrote:
Hurdle 1. Many Windows users are used to zip not bz2 files, so what do I do with them??
cygwin comes with bunzip2.exe or in case of an archive you can directly 'tar -xvjf <file>'
"Toon Knapen" wrote
Andy Little wrote:
Hurdle 1. Many Windows users are used to zip not bz2 files, so what do I do with them??
cygwin comes with bunzip2.exe or in case of an archive you can directly 'tar -xvjf <file>'
OK.... Here then is my ConceptGCC installation for dummies guide: You need to have Cygwin installed: http://www.cygwin.com/ Hurdle 1. Many Windows users are used to zip not bz2 files, so what do I do with them? Answer: Cygwin comes with bunzip2.exe or in case of an archive you can directly 'tar -xvjf <file>' Move the resulting 'opt' directory to your Cygwin installation. In my case C:/Cygwin so in my case the result is C:/Cygwin/opt Head for Start>Control Panel. Head for System>Advanced>Environment Variables. Find 'Path' environment variable Add The ConceptGcc bin directory e.g PREVIOUS_Stuff;C:/Cygwin/opt/conceptgcc-VERSION/bin Now check it works. Open a command prompt. (If you have Cygwin correctly installed you shouldnt need to be in Cygwin shell) type conceptg++. If all is working ok you should get: C:\my_current_dir>conceptg++ conceptg++: no input files C:\my_current_dir Next.. Head for the tutorial: http://www.generic-programming.org/languages/conceptcpp/tutorial/ ....And it even works with my Stuff! :-) regards Andy little
Andy Little wrote:
"Toon Knapen" wrote
Andy Little wrote:
Hurdle 1. Many Windows users are used to zip not bz2 files, so what do I do with them??
cygwin comes with bunzip2.exe or in case of an archive you can directly 'tar -xvjf <file>'
You can also you 7zip ( which most windows users have by now or should have as 7zip is really cool :) ) and do 2 extracts... one from the bz2 to a tar and one from the tar to the folders and files you need. Windows users love a GUI... this save a little typing.
On Sep 28, 2006, at 3:20 AM, Andy Little wrote:
And a Question to Doug Gregor Does ConceptGCC support decltype and auto? Please note: this is Not a feature request, just a simple question! :-)
No, we don't have support for decltype or auto in ConceptGCC. Of course, you can fake decltype with concepts, if you want: auto concept Callable2<typename F, typename T1, typename T2> { typename result_type; result_type operator()(F, T1, T2); } Callable2<F, T1, T2>::result_type tells you the type returned by calling an object of type F with arguments of types T1 and T2.
Of course if I really want it, then I guess I ought to try sorting it out myself though shouldnt I? :-)
If be "sorting it out myself" you mean implementing decltype and auto in GCC, then "yes"! :) Doug
"Doug Gregor" <dgregor@cs.indiana.edu> wrote in message news:11FDF23E-AE83-484F-B34E-D03829821B55@cs.indiana.edu...
On Sep 28, 2006, at 3:20 AM, Andy Little wrote:
And a Question to Doug Gregor Does ConceptGCC support decltype and auto? Please note: this is Not a feature request, just a simple question! :-)
No, we don't have support for decltype or auto in ConceptGCC.
Of course, you can fake decltype with concepts, if you want:
auto concept Callable2<typename F, typename T1, typename T2> { typename result_type; result_type operator()(F, T1, T2); }
Callable2<F, T1, T2>::result_type tells you the type returned by calling an object of type F with arguments of types T1 and T2.
I was just looking at the tutorial, wondering about whether I could do that... ...And if I couldnt, I was going to suggest that I should be able to. :-)
Of course if I really want it, then I guess I ought to try sorting it out myself though shouldnt I? :-)
If be "sorting it out myself" you mean implementing decltype and auto in GCC, then "yes"! :)
hmm... (actually that Was a feature request... ;-) ) *Interesting* idea though, trying to hack Gcc.... very foolhardy IMO, unwise, very unwise... :-) Am I right that I can add conditional Concept support to headers by : # ifdef __GXX_CONCEPTS__ ... concept stuff ? And what happens if I have for example a Numeric concept (float, int, boost::numeric::interval) and I want to make Integer a 'member'( model?). How would that work? And integer is also a fundamental type of course Would I be able somehow to express that I don't want potentially 'lossy' division. e.g int / int ? Anyway I will have to see how well it works in my physical quantities library. I'm glad I finally got round to trying it out :-) regards Andy Little
On Sep 28, 2006, at 12:13 PM, Andy Little wrote:
"Doug Gregor" <dgregor@cs.indiana.edu> wrote in message
If be "sorting it out myself" you mean implementing decltype and auto in GCC, then "yes"! :)
hmm... (actually that Was a feature request... ;-) ) *Interesting* idea though, trying to hack Gcc.... very foolhardy IMO, unwise, very unwise...
:-)
Sure, but if you don't implement it in GCC... who will?
Am I right that I can add conditional Concept support to headers by :
# ifdef __GXX_CONCEPTS__
... concept stuff
?
Yep.
And what happens if I have for example a Numeric concept (float, int, boost::numeric::interval) and I want to make Integer a 'member'( model?). How would that work? And integer is also a fundamental type of course
That's what concept maps are for, e.g., concept_map Numeric<integer> { }
Would I be able somehow to express that I don't want potentially 'lossy' division. e.g int / int ?
In the concept Numeric (or, perhaps, one of its "refinements", i.e., more specific concepts that inherit/refine "Numeric"), you could write an axiom like: axiom NonlossyDivision(T x, T y) { y == (x / y) * x; } It's a semantic requirement (and, therefore, unchecked); but, users have to at least think about it before lying to you about their division operators.
Anyway I will have to see how well it works in my physical quantities library. I'm glad I finally got round to trying it out :-)
Me too :) Doug
The following doesnt work though ( nor with the std:: versions of the Concepts) Output is : test.cpp: In function 'T sum(T*, int)': test.cpp:28: error: no match for 'operator=' in 'result = Addable<T>::operator+(result, array[i])' test.cpp:19: note: candidates are: typename Assignable<T>::result_type Assignable<T>::operator=(T&, const T&) ---------------------------------- #include <concepts> #include <iostream> #if (0) //Works auto concept Addable<typename T> { T operator+(T x, T y); }; #else // Fails auto concept Addable<typename T> { typename result_type; result_type operator+(T x, T y); }; #endif auto concept Assignable<typename T> { typename result_type; result_type operator=(T& x, T y); }; template<std::CopyConstructible T> where Addable<T> && Assignable<T> T sum(T array[], int n) { T result = T(0); for (int i = 0; i < n; ++i) result = result + array[i]; return result; } int main() { int arr[3] = {1,2,3}; std::cout << sum(arr, 3); return 0; } regards Andy Little
On Sep 28, 2006, at 6:09 PM, Andy Little wrote:
The following doesnt work though ( nor with the std:: versions of the Concepts)
Output is : test.cpp: In function 'T sum(T*, int)': test.cpp:28: error: no match for 'operator=' in 'result = Addable<T>::operator+(result, array[i])' test.cpp:19: note: candidates are: typename Assignable<T>::result_type Assignable<T>::operator=(T&, const T&)
Right. Let's take a closer look...
auto concept Addable<typename T> { typename result_type; result_type operator+(T x, T y); };
This says that you can add two T's with operator+, and the result is a value of some type result_type (we don't know what that is).
auto concept Assignable<typename T> { typename result_type; result_type operator=(T& x, T y); };
This says we can assign from a T to a T.
result = result + array[i];
So, result + array[i] returns a value of type Addable<T>::result_type. However, there's no requirement on sum that says that we can assign from an Addable<T>::result_type to a T... we only say that we can assign from a T to a T! There are a couple ways to fix this. You could make the Assignable concept take two parameters (e.g., assign to a T from a U), or you could add a Convertible constraint that says that the result_type needs to be convertible to T, e.g., std::Convertible<Addable<T>::result_type, T> I added this to the where clause, and things work as expected. Doug
"Douglas Gregor" <doug.gregor@gmail.com> wrote in message news:6F743D04-2F34-488D-BBC6-0DEC80DBCBC2@osl.iu.edu... OK. Thanks for sorting that out. FWIW here is my user impressions from the tutorial. I suspect that maybe other people trying this out will get into these difficulties, once they start experimenting. In this situation, being human and seeing nothing wrong with my code which (I hope) would have always worked before, I immediately suspect the compiler. Lets face it hacking Gcc is a no no anyway. Its new , why shouldnt it be full of bugs? So that is a hurdle. For that reason I think the tutorial example is way too complicated: double sum(double array[], int n) { double result = 0; for (int i = 0; i < n; ++i) result = result + array[i]; return result; } There is way too much going on here IMO. I eventually started with this: auto concept Addable<typename T1, typename T2> { typename result_type; result_type operator+(T1 x, T2 y); }; template <typename TL, typename TR> where Addable<TL,TR> Addable<TL,TR>::result_type add( TL const & lhs, TR const & rhs) { return lhs + rhs; } And then to this: auto concept Assignable<typename T1, typename T2> { T1& operator=(T1& x, T2 y); }; template <typename TL,typename TR> where Addable<TL,TR> && Assignable<TL,Addable<TL,TR>::result_type > TL& add_assign( TL & lhs, TR const & rhs) { lhs = lhs + rhs; return lhs; } Maybe that is related to my stuff though. Anyway it might be worth trying to cut extraneous stuff from the first example. Secondly, the way templates currently work is firmly entrenched in my brain. Currently they work most of the time, with any old junk that you throw at them. Maybe you need to stress that although the syntax is similar, that once you include Concept features that your template parameters are suddenly imbued with a much different character. This relates a lot to the first point; If it doesnt work then (often wrongly but nevertheless... )suspect the compiler. in the words of Spock in Start Trek. "This is C++ Jim, but not as we know it." I'll have to think more about it. Anyway I definitely want to spend some time learning more about it and try to port my physical quantities stuff over. Its a really clean way of doing things. I love it ! trouble is there is a lot going on in C++ at the moment, so there is no way I am going to master all this for a while. regards Andy Little
On Sep 28, 2006, at 9:15 PM, Andy Little wrote:
For that reason I think the tutorial example is way too complicated: [snip example]
Yeah, you're probably right. In my talks, I start with much simpler examples. *sigh* I should probably write a new, improved tutorial in the near future, because we've gotten a lot better at describing concepts in the past six months.
Secondly, the way templates currently work is firmly entrenched in my brain. Currently they work most of the time, with any old junk that you throw at them. Maybe you need to stress that although the syntax is similar, that once you include Concept features that your template parameters are suddenly imbued with a much different character. This relates a lot to the first point; If it doesnt work then (often wrongly but nevertheless... )suspect the compiler.
Understood.
I love it ! trouble is there is a lot going on in C++ at the moment, so there is no way I am going to master all this for a while.
None of us can. As we start to get implementations of these features, we'll start to discover all of the interesting tricks, techniques, and (of course) pitfalls. But the earlier we start playing with the features, the better we can avoid the pitfalls :) Doug
"Douglas Gregor" wrote
On Sep 28, 2006, at 9:15 PM, Andy Little wrote:
For that reason I think the tutorial example is way too complicated: [snip example]
Yeah, you're probably right. In my talks, I start with much simpler examples. *sigh* I should probably write a new, improved tutorial in the near future, because we've gotten a lot better at describing concepts in the past six months.
I have been reading the n2042 Concepts doc, and it's quite easy reading. Maybe it's worth putting a link to that in the intro to the tutorial, rather than the general link at the end of the tutorial, so if I do get into difficulties then I've got prior notice of somewhere to go to figure out what I'm doing wrong. Its a thought anyway. regards Andy Little
On Sep 29, 2006, at 10:09 AM, Andy Little wrote:
I have been reading the n2042 Concepts doc, and it's quite easy reading.
Glad to hear it. N2081 fixes a lot of typos and other minor issues with N2042, and adds some discussion of rvalue references. But if you've read one, there's no reason to read the other.
Maybe it's worth putting a link to that in the intro to the tutorial, rather than the general link at the end of the tutorial, so if I do get into difficulties then I've got prior notice of somewhere to go to figure out what I'm doing wrong. Its a thought anyway.
Good idea! Thanks. Cheers, Doug
"Doug Gregor" <dgregor@cs.indiana.edu> wrote
On Sep 28, 2006, at 12:13 PM, Andy Little wrote:
"Doug Gregor" <dgregor@cs.indiana.edu> wrote in message
If be "sorting it out myself" you mean implementing decltype and auto in GCC, then "yes"! :)
hmm... (actually that Was a feature request... ;-) ) *Interesting* idea though, trying to hack Gcc.... very foolhardy IMO, unwise, very unwise...
:-)
Sure, but if you don't implement it in GCC... who will?
I don't know. Personally I don't see much point in having a new version of C++ without decltype and auto though. However there is no way that I would take it on as a project myself, no way. regards Andy Little
Doug Gregor <dgregor@cs.indiana.edu> writes:
On Sep 28, 2006, at 3:20 AM, Andy Little wrote:
And a Question to Doug Gregor Does ConceptGCC support decltype and auto? Please note: this is Not a feature request, just a simple question! :-)
No, we don't have support for decltype or auto in ConceptGCC.
Of course, you can fake decltype with concepts, if you want:
auto concept Callable2<typename F, typename T1, typename T2> { typename result_type; result_type operator()(F, T1, T2); }
Doug, that's ridiculously cool... and once you show it, it seems so obvious that it makes me feel dumb. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 09/27/2006 08:08 AM, Larry Evans wrote: [snip]
I'm wondering what implications this would have for fusion containers. [snip] to implement a variadic template fusion list. However, the fusion vector uses BOOST_PP_ENUM* to generate member names. To do that BOOST_PP_ENUM* requires the length of the variadic template typelist, information not available at preprocessing time. Hence, I'm wondering how a variadic template fusion vector would be implemented. Any ideas?
I guess the answer is suggested by: fusion/sequence/conversion/detail/as_vector.hpp. In that file, the preprocessor vertical repetition code generates a specialization for each N and that N can be the result of mpl::size<V>::value where V is some mpl::vector<T1,...,TN>.
I think variadic templates are a big step forward for C++ libraries that deal with function objects, forwarding, and type-lists. If you're interested, please read the documentation, hack some code with the compiler, and tell your local C++ committee representative to vote for variadic templates in C++0x :)
Impressive! A must-have for C++0x without any doubt. Having precompiled binaries is a very nice detail. Variadic templates plus rvalue reference will rock C++. Thanks! Ion
Impressive! A must-have for C++0x without any doubt. Having precompiled binaries is a very nice detail. Variadic templates plus rvalue reference will rock C++.
Don't want to spoil the party (I would love to see this feature) but I looked at the standard home page and in the latest list of mailings the variadic template proposal is marked as "Not Ready for C++0x". So what gives?
Tomas Puverle wrote:
Don't want to spoil the party (I would love to see this feature) but I looked at the standard home page and in the latest list of mailings the variadic template proposal is marked as "Not Ready for C++0x". So what gives?
What gives is that I expect to have an updated state-of-evolution paper after the Portland meeing in a few weeks. I expect we will have a very clear idea of what the next standard will look like after that. Given the excellent proposal Doug et. al. have put forward, with the added bonus of a reference implementation, I sincerely hope this is not the last we have heard on the subject ... -- AlisdairM
Tomas Puverle wrote:
Impressive! A must-have for C++0x without any doubt. Having precompiled binaries is a very nice detail. Variadic templates plus rvalue reference will rock C++.
Don't want to spoil the party (I would love to see this feature) but I looked at the standard home page and in the latest list of mailings the variadic template proposal is marked as "Not Ready for C++0x". So what gives?
Having a reference implementation changes the equation. It markedly raises the comfort level for any proposal. It demonstrates that a proposal is ready for prime time. A reference implementations is a major plus. --Beman
Doug Gregor wrote:
...
I think variadic templates are a big step forward for C++ libraries that deal with function objects, forwarding, and type-lists. If you're interested, please read the documentation, hack some code with the compiler, and tell your local C++ committee representative to vote for variadic templates in C++0x :)
I have tried out the compiler using the cygwin compiled code supplied. I have implemented the printf example. I had a name clash with the printf in the system, and renamed the local one printff. The return in the recursion had to be modified: /*return*/ printf(++s, args...); return; When I added this example: const char* more = "have nothing to do with the case %s %s\n"; printff(more, "tra la"); the output is have nothing to do with the case tra la tra la instead of an exception for an extra format. I hope this helps. Source code of example attached. John // printex.cpp // Variadic printf example from the manual. #include <iostream> #include <stdexcept> void printff(const char* s) { while (*s) { if (*s == '%' && *++s != '%') throw std::runtime_error("invalid format string: missing arguments"); std::cout << *s++; } } template<typename T, typename... Args> void printff(const char* s, const T& value, const Args&... args) { while (*s) { if (*s == '%' && *++s != '%') { std::cout << value; /*return*/ printf(++s, args...); return; } std::cout << *s++; } throw std::runtime_error("extra arguments provided to printff"); } int main() { try { const char* msg = "The value of %s is about %g (unless you live in %s).\n"; const char* another = "The flowers that bloom in the spring %s \n"; const char* more = "have nothing to do with the case %s %s\n"; printff(msg, std::string("pi"), 3.14159, "Indiana"); printff(another, "tra la"); printff(more, "tra la"); } catch(std::runtime_error s) { std::cout << "Caught " << s.what() << std::endl; } return 0; }
Doug Gregor wrote: I have implemented the printf example. I had a name clash with the printf in the system, and renamed the local one printff.
Ugh, okay. It seems that C++ should prefer the non-varargs "printf(const char*)" over the system's "printf(const char*, ...)".
The return in the recursion had to be modified:
/*return*/ printf(++s, args...); return;
Change that "printf" to "printff" and everything works as expected. What's happening here is that you're calling the system's "printf" with every argument after the first. And since that "printf" returns an int (not void), the "return" won't parse.
When I added this example:
const char* more = "have nothing to do with the case %s %s\n"; printff(more, "tra la");
the output is
have nothing to do with the case tra la tra la
instead of an exception for an extra format.
Once I change that "printf" to "printff" into the "return printf(" line, it raises the exception as expected. Cheers, Doug
Douglas Gregor wrote:
Doug Gregor wrote:
Once I change that "printf" to "printff" into the "return printf(" line, it raises the exception as expected.
Cheers, Doug
Thanks. Sorry about that. Is the code of the tuple implementation available? If so where is it? Thanks John
On Sep 28, 2006, at 7:14 AM, John Fletcher wrote:
Douglas Gregor wrote:
Doug Gregor wrote:
Once I change that "printf" to "printff" into the "return printf(" line, it raises the exception as expected.
Cheers, Doug
Thanks. Sorry about that.
Is the code of the tuple implementation available? If so where is it?
There's an annotated version in the variadic template proposal: http://www.osl.iu.edu/~dgregor/cpp/variadic-templates.pdf There's a complete TR1 implementation in the compiler for variadic templates (see libstdc++-v3/include/tr1/tuple). Doug
Doug Gregor wrote:
On Sep 28, 2006, at 7:14 AM, John Fletcher wrote:
There's an annotated version in the variadic template proposal:
I was hoping not to have to dig it out of the pdf.
There's a complete TR1 implementation in the compiler for variadic templates (see libstdc++-v3/include/tr1/tuple).
I have the compiled distribution for cygwin and cannot find a directory for the includes for libstdc++-v3. Is it in a different distribution? John
On Sep 28, 2006, at 11:36 AM, John Fletcher wrote:
I have the compiled distribution for cygwin and cannot find a directory for the includes for libstdc++-v3. Is it in a different distribution?
Oh, sorry. In the compiled distribution it's in /opt/variadicgcc-4.1.1/include/c++/4.1.1/tr1/tuple Doug
Doug Gregor wrote:
On Sep 28, 2006, at 11:36 AM, John Fletcher wrote:
I have the compiled distribution for cygwin and cannot find a directory for the includes for libstdc++-v3. Is it in a different distribution?
Oh, sorry. In the compiled distribution it's in
/opt/variadicgcc-4.1.1/include/c++/4.1.1/tr1/tuple
Doug
Got it. Thanks. It beats typing it all in. John
John Fletcher wrote:
/*return*/ printf(++s, args...); return;
When I added this example:
const char* more = "have nothing to do with the case %s %s\n"; printff(more, "tra la");
the output is
have nothing to do with the case tra la tra la
instead of an exception for an extra format
John
Ignore all this bit. I forgot to rename the inner call from printf to printff. Now the previous code return printff(++s, args...); works fine and gives the expected exception. It makes the point about this way of doing it being better. John
On 09/26/2006 04:36 PM, Doug Gregor wrote:
A while ago I announced the availability of an implementation of "variadic templates" for GCC. Variadic templates eliminate a huge amount of redundancy in several Boost libraries (including some that have gone into TR1), such as tuples, function, bind, mem_fn, and MPL. David, Joel:
Do you have any plans for using this in not-to-distant future versions of MPL and FUSION, obviously with preprocessor dispatching on the __VARIADIC_TEMPLATES mentioned in: http://www.osl.iu.edu/~dgregor/cpp/variadic-templates.html ? If not, I could attempt it; however, I'm sure you, being the library authors, would do a better job. For example, I just glanced at mpl/reverse_fold.hpp and saw the need to look at aux_/na_spec.hpp to see if it's needed with _VARIADIC_TEMPLATES; however, the answer wasn't obvious at first glance :( -regards, Larry
On 09/30/2006 07:12 AM, Larry Evans wrote: [snip]
David, Joel:
Do you have any plans for using this in not-to-distant future versions of MPL and FUSION, obviously with preprocessor dispatching on the __VARIADIC_TEMPLATES mentioned in:
http://www.osl.iu.edu/~dgregor/cpp/variadic-templates.html
? If not, I could attempt it; however, I'm sure you, being
The attached shows a variadic template version of mpl vector and at_c. Of course there would have to be begin, end, size, and others, but this suggests it may be pretty easy to convert mpl to use variadic templates.
Larry Evans said: (by the date of Sat, 30 Sep 2006 10:06:54 -0500)
The attached shows a variadic template version of mpl vector and at_c. Of course there would have to be begin, end, size, and others, but this suggests it may be pretty easy to convert mpl to use variadic templates.
When boost switches to using variadic templates (which release will it be then?) I'm curious what happens with support of all the other (older) compilers? -- Janek Kozicki |
On 09/30/2006 10:15 AM, Janek Kozicki wrote:
Larry Evans said: (by the date of Sat, 30 Sep 2006 10:06:54 -0500)
The attached shows a variadic template version of mpl vector and at_c. Of course there would have to be begin, end, size, and others, but this suggests it may be pretty easy to convert mpl to use variadic templates.
When boost switches to using variadic templates (which release will it be then?) I'm curious what happens with support of all the other (older) compilers?
My OP mentioned the need to dispatch on the _VARIADIC_TEMPLATES macro. This should enable use of non-variadic-template compilers while still enabling use of Douglas' veriadic-template enabled compiler.
Janek Kozicki <janek_listy@wp.pl> writes:
Larry Evans said: (by the date of Sat, 30 Sep 2006 10:06:54 -0500)
The attached shows a variadic template version of mpl vector and at_c. Of course there would have to be begin, end, size, and others, but this suggests it may be pretty easy to convert mpl to use variadic templates.
When boost switches to using variadic templates (which release will it be then?) I'm curious what happens with support of all the other (older) compilers?
Boost isn't going to do a wholesale *switch* until the feature is standard C++, and then we'd have to decide we weren't supporting C++03 anymore. I predict that is many years off. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Janek Kozicki <janek_listy@wp.pl> writes:
When boost switches to using variadic templates (which release will it be then?) I'm curious what happens with support of all the other (older) compilers?
Boost isn't going to do a wholesale *switch* until the feature is standard C++, and then we'd have to decide we weren't supporting C++03 anymore. I predict that is many years off.
I don't see a reason why we couldn't start supporting advanced features using ConceptGCC or other compilers using our usual configuration system even before the standard is complete. That might help provide for detailed evaluation of various features and implementations. If the features don't ever make it to the standard they could be deprecated and removed over time. Jeff
Jeff Garland <jeff@crystalclearsoftware.com> writes:
I don't see a reason why we couldn't start supporting advanced features using ConceptGCC or other compilers using our usual configuration system even before the standard is complete.
I never suggested otherwise, and of course I agree. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Jeff Garland wrote:
I don't see a reason why we couldn't start supporting advanced features using ConceptGCC or other compilers using our usual configuration system even before the standard is complete. That might help provide for detailed evaluation of various features and implementations. If the features don't ever make it to the standard they could be deprecated and removed over time.
The problem isn't just features that don't make it into the standard, but also features that do make it in, but get modified in various important ways. Once a feature makes it into the working paper (WP), there is less risk involved. As the WP stabilizes (no new features being added, all work directed at finishing), the risk is much lower. But to do much more than experiment with a new feature before it even gets voted into the WP is asking for trouble, IMO. --Beman
On Oct 1, 2006, at 9:57 PM, Beman Dawes wrote:
Once a feature makes it into the working paper (WP), there is less risk involved. As the WP stabilizes (no new features being added, all work directed at finishing), the risk is much lower. But to do much more than experiment with a new feature before it even gets voted into the WP is asking for trouble, IMO.
Sure, but you can never experiment too much with a feature before it goes into the working paper, and we've learned that many features that look great in small examples---say, ADL---can cause big problems in the wild. We should encourage experimentation as much as possible. If it means setting up a regression tester with, e.g., the variadic templates compiler, we should do it. But, let's keep the uses of these new features safely tucked behind macros or in separate header files. We're not going to guarantee anything about their continued use until they're firm in the WP. Doug
On 10/02/2006 09:12 AM, Douglas Gregor wrote: [snip]
Sure, but you can never experiment too much with a feature before it goes into the working paper, and we've learned that many features that look great in small examples---say, ADL---can cause big problems in the wild. We should encourage experimentation as much as possible. If it means setting up a regression tester with, e.g., the variadic templates compiler, we should do it.
But, let's keep the uses of these new features safely tucked behind macros or in separate header files. We're not going to guarantee anything about their continued use until they're firm in the WP. Doug,
On my local disk, I've got code for variadic templates tucked underneath */boost/sandbox/variadic-templates. I got what I think is an variadic version of mpl::list; however, the compiler gets an ICE when it sees mpl::equal. The code is in boost-vault under variadic_templates.
On 10/15/2006 03:01 PM, Larry Evans wrote: [snip]
On my local disk, I've got code for variadic templates tucked underneath */boost/sandbox/variadic-templates. I got what I think is an variadic version of mpl::list; however, the compiler gets an ICE when it sees mpl::equal.
The code is in boost-vault under variadic_templates. In the same boost-vault directory, there's vtmpl.zip. This shows a failed attempt at using variadic templates for type_traits/is_same.hpp. The included files show the compiler errors for non-variadic and variadic template versions of is_same.
Could anyone suggest how to do what I attempted to do in the variadic is_same.hpp in vtmpl.zip? TIA. -regards, Larry
On 10/15/2006 08:34 PM, Larry Evans wrote: [snip]
Could anyone suggest how to do what I attempted to do in the variadic is_same.hpp in vtmpl.zip?
Never mind. The whole problem was caused by the failure to unpack the Tail arg in the list.hpp push_front. With that correction, non-variadic is_same worked.
On Oct 16, 2006, at 4:14 PM, Larry Evans wrote:
On 10/15/2006 08:34 PM, Larry Evans wrote: [snip]
Could anyone suggest how to do what I attempted to do in the variadic is_same.hpp in vtmpl.zip?
Never mind. The whole problem was caused by the failure to unpack the Tail arg in the list.hpp push_front. With that correction, non-variadic is_same worked.
Thanks for tracking this down. I'll make sure the compiler diagnoses this error properly in future versions. Doug
Larry Evans <cppljevans@cox-internet.com> writes:
David, Joel:
Do you have any plans for using this in not-to-distant future versions of MPL and FUSION, obviously with preprocessor dispatching on the __VARIADIC_TEMPLATES mentioned in:
http://www.osl.iu.edu/~dgregor/cpp/variadic-templates.html
?
Not me; ask Aleksey -- he implemented nearly all of MPL himself. He generously named me in the copyrights because I contributed some ideas, but the code is Aleksey's. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On 09/30/2006 10:34 AM, David Abrahams wrote:
Larry Evans <cppljevans@cox-internet.com> writes:
David, Joel:
Do you have any plans for using this in not-to-distant future versions of MPL and FUSION, obviously with preprocessor [snip] Not me; ask Aleksey -- he implemented nearly all of MPL himself.
OK. Aleksey, do you have any plans? I'm starting to do it, but there's a lot I don't know about it. For example, I see there's a aux::vector_tag<N> ( where N == vector size, I guess), It's used in push_back and push_front. I'm unsure whether it could be replaced with a simple aux::vector_tag and maybe use variadic template arg packing and unpacking to implment the push* functions. I'm also thinking maybe it would be best to just have a separate include directory for variadic templates intead of heavily sprinkling the code with: #ifdef __VARIADIC_TEMPLATES ... #endif then the user could change his user-config.jam to test the compiler and if it's Douglas' then prepend the variadic-template include directory in front of the other -I parameters to the compiler. What are your thoughts? TIA. -regards, Larry
participants (17)
-
AlisdairM -
Andy Little -
Beman Dawes -
David Abrahams -
Doug Gregor -
Douglas Gregor
-
Douglas Gregor -
Gennaro Prota -
Ion Gaztañaga -
Janek Kozicki -
Jeff Garland -
Joel de Guzman -
John Fletcher -
Larry Evans -
Michael Marcin -
Tomas Puverle -
Toon Knapen