There's a proposal (N1611) "Implicitly-Callable Functions in C++0x" by Walter Brown in the C++ committee's pre-meeting papers. See http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf Given all the Boost work that has gone into math constants, function issues, and to a lesser extent, properties, I'd guess several Boosters might want to comment on Walter's proposal. Strong support from library developers like Boost participants would almost be a requirement for such a proposal to be accepted, IMO. But do remember that only so many proposals can be accepted, and that every proposal that gets accepted pushes some other proposal aside. comp.std.c++ is the best place to post comments, since it is probably read by more of the committee's Evolution Working Group than read the Boost list. See http://groups.google.com/groups?q=comp.std.c%2B%2B for a web interface. A comment on comp.std.c++ should probably be like Boost review; say in plain language if you support or oppose the proposal so detailed comments don't obscure an overall view. (The Boost list is read by many active C++ committee members, but they tend to be library oriented rather than core language or evolution oriented.) An extended discussion of such a proposal would probably stray off-topic for Boost anyhow. --Beman PS: if you are interested in other proposals for the next C++ standard, http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/#pre_sydney has a wealth of interesting papers.
From a very quick study of this, this radical proposal avoids nasty brackets "pi()" by adding a new C++ keyword implicit to make "pi" have the same effect.
One could write: double pi() implicit // << Note new keyword here. { return 3.145926; } and double circumference = pi * diameter; // Note No nasty ()s and more usefully: and template<class T = double> T pi() implicit // << Note new keyword here. { return 3.1459265358793; } and specialisations like: template<> float pi<float>() { return 3.1459F; } template<> myVeryLongDouble pi<myVeryLongDouble >() { // UserDefined floating point Type. return 3.1459265358793432986549023478943257; } template<> int pi<int >() { // For indiana Legislature lawyers only ;-) return 3; } and define functions like template<class T> T area (T radius) { return pi<T> * radius * radius; } Language design implications is way outside my competence, but "implicit" sweetens a serious language nastiness. Pragmatically, I sense that a kludge, such as several people, most recently Daniel Frey, are working on promises a nasty but quicker partial solution for math constants. It would not seem much trouble to convert if the new keyword "implicit" is actually working, so I don't conclude we should stop the on-going battle to present math constants. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com | -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Beman Dawes | Sent: 10 March 2004 02:18 | To: Boost mailing list | Subject: [boost] Implicitly-Callable Functions in C++0x? | | There's a proposal (N1611) "Implicitly-Callable Functions in C++0x" by | Walter Brown in the C++ committee's pre-meeting papers. See | http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1611.pdf
"Paul A Bristow" <boost@hetp.u-net.com> wrote in message news:001501c40795$ce631ce0$0c010101@hetp3...
From a very quick study of this, this radical proposal avoids nasty brackets "pi()" by adding a new C++ keyword implicit to make "pi" have the same effect.
Considering what Daniel can do, I don't think the math constant part of the proposal brings anything. br Thorsten
Thorsten Ottosen wrote:
"Paul A Bristow" <boost@hetp.u-net.com> wrote in message news:001501c40795$ce631ce0$0c010101@hetp3...
From a very quick study of this, this radical proposal avoids nasty brackets "pi()" by adding a new C++ keyword implicit to make "pi" have the same effect.
Considering what Daniel can do, I don't think the math constant part of the proposal brings anything.
Basically, I agree. When I sorted out the VC-issues and finished the documentation, I'll have a deeper look at the ICF-proposal and post some comments to csc++. FWIW, my gut feeling is that the proposal it not worth the trouble. However: I can do many, but not all things proposed. There is one thing (syntax) that I cannot do but that I like very much: pi<T> In my constant library, this is spelled 'pi.get<T>()'. Alternatives that don't work: 'static_cast<T>(pi)', 'T(pi)', 'pi.operator T()'. If anyone has a cool idea how this can be improved, let me know :) Regards, Daniel
Daniel Frey <d.frey@gmx.de> writes:
Thorsten Ottosen wrote:
"Paul A Bristow" <boost@hetp.u-net.com> wrote in message news:001501c40795$ce631ce0$0c010101@hetp3...
From a very quick study of this, this radical proposal avoids nasty brackets "pi()" by adding a new C++ keyword implicit to make "pi" have the same effect. Considering what Daniel can do, I don't think the math constant part of the proposal brings anything.
Basically, I agree. When I sorted out the VC-issues and finished the documentation, I'll have a deeper look at the ICF-proposal and post some comments to csc++. FWIW, my gut feeling is that the proposal it not worth the trouble.
However: I can do many, but not all things proposed. There is one thing (syntax) that I cannot do but that I like very much:
pi<T>
In my constant library, this is spelled 'pi.get<T>()'. Alternatives that don't work: 'static_cast<T>(pi)', 'T(pi)', 'pi.operator T()'. If anyone has a cool idea how this can be improved, let me know :)
get<T>(pi) Why doesn't T(pi) work? -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
Daniel Frey <d.frey@gmx.de> writes:
Thorsten Ottosen wrote:
"Paul A Bristow" <boost@hetp.u-net.com> wrote in message news:001501c40795$ce631ce0$0c010101@hetp3...
From a very quick study of this, this radical proposal avoids nasty brackets "pi()" by adding a new C++ keyword implicit to make "pi" have the same effect.
Considering what Daniel can do, I don't think the math constant part of the proposal brings anything.
Basically, I agree. When I sorted out the VC-issues and finished the documentation, I'll have a deeper look at the ICF-proposal and post some comments to csc++. FWIW, my gut feeling is that the proposal it not worth the trouble.
However: I can do many, but not all things proposed. There is one thing (syntax) that I cannot do but that I like very much:
pi<T>
In my constant library, this is spelled 'pi.get<T>()'. Alternatives that don't work: 'static_cast<T>(pi)', 'T(pi)', 'pi.operator T()'. If anyone has a cool idea how this can be improved, let me know :)
get<T>(pi)
Good idea, I'll think about this one.
Why doesn't
T(pi)
Because T can have multiple ctors (taking i.e. float, double, long double and thus making the conversion ambiguous - I can't control that from inside pi, the T is not exactly forwarded to pi's type when asked for a conversion). The second reason is that it limits the result to T. When I have a unit library, this is not acceptable, as get<T> provides some magic: get<double>(G) returns a combination of a double value plus the appropriate unit, not a plain double. This is the basic problem of all the alternatives I mentioned: I don't have the freedom to modify the returned type, but this is an essential feature I need. Regards, Daniel -- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de
"Daniel Frey" <daniel.frey@aixigo.de> wrote in message news:c2scpf$me8$1@sea.gmane.org... David Abrahams: [snip]
Why doesn't
T(pi)
Because T can have multiple ctors (taking i.e. float, double, long double and thus making the conversion ambiguous - I can't control that from inside pi, the T is not exactly forwarded to pi's type when asked for a conversion).
1. how big is this problem in practice? 2.couldn't you just make a default choice? Let enable_if disable some if there is an ambiguity? br Thorsten
Thorsten Ottosen wrote:
"Daniel Frey" <daniel.frey@aixigo.de> wrote in message news:c2scpf$me8$1@sea.gmane.org... David Abrahams: [snip]
Why doesn't
T(pi)
Because T can have multiple ctors (taking i.e. float, double, long double and thus making the conversion ambiguous - I can't control that
from inside pi, the T is not exactly forwarded to pi's type when asked
for a conversion).
1. how big is this problem in practice?
Big AFAICT. Most UDTs that I saw have ctors to handle conversions from the built-in types. I would limit the useable types for no good reason. Also, the second problem I mentioned is even more serious - and solving it also solves the ctor-problem.
2.couldn't you just make a default choice? Let enable_if disable some if there is an ambiguity?
Not an option IMHO. A default is exactly what should be avoided at all cost. If someone uses quad-doubles or RWDecimal, he has a reason to do so. Silently injecting doubles (or any other default) could do a lot of damage and thus will work against the acceptance of the library. Safe use with no surprises is a lot more important than convenience and a default type isn't safe. BTW: These things are good to discuss. I think some of this should make it to the documentation :) Regards, Daniel -- Daniel Frey aixigo AG - financial solutions & technology Schloß-Rahe-Straße 15, 52072 Aachen, Germany fon: +49 (0)241 936737-42, fax: +49 (0)241 936737-99 eMail: daniel.frey@aixigo.de, web: http://www.aixigo.de
Daniel Frey <daniel.frey@aixigo.de> wrote:
BTW: These things are good to discuss. I think some of this should make it to the documentation :)
I'd like to point your attention to http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1600.html This is actually not a proposal, just a status of properties as being worked on by C++/CLI group. However please keep in mind, that once it's established, it will go (or may go?) on the fast-track of C++ Committee. C++/CLI properties are going somehow across (hm, I do not know if that's a good word) ICF as proposed in N1611, as both may result in function call taking form: object.member_variable difference is that properties privide clean notion of getter/setter, while in ICF things appear to be more complicated. On the other side properties do not seem to support template getter/setter . I think Committee will need to work it out, I just want to point that both features (ICF and propeties) will probably need to meet somewhere in the middle, thus some serious changes in ICF and/or properties will most probably happen. I'm just guessing - Committee members are present on this list and their opinion (opposite to mine) have some actual foundation. B.
Bronek Kozicki wrote:
Daniel Frey <daniel.frey@aixigo.de> wrote:
BTW: These things are good to discuss. I think some of this should make it to the documentation :)
I'd like to point your attention to http://std.dkuug.dk/jtc1/sc22/wg21/docs/papers/2004/n1600.html
Most of these ideas are taken from Delphi/C++ Builder, which is understandable since one of the chief architects of .NET, Mr. Hejlsberg, was one of the chief architects of Delphi/C++ Builder before he was hired away by Microsoft. On comp.std.c++ I, and others, argued for properties in C++ a while back along many of the same paths as taken in the article above. The article even repeats the same arguments made for properties which I made on comp.std.c++: syntactic sugar for getXXX()/setXXX() and support for RAD via introspection. I find it amusing that while properties were part of Delphi/C++ Builder 9 years or so, they were considered outside the bounds of C++, but now they have been adapted by Microsoft for .NET in the past 3 years, they are now considered with much more importance and relevance as a real possibility for a future C++.
This is actually not a proposal, just a status of properties as being worked on by C++/CLI group. However please keep in mind, that once it's established, it will go (or may go?) on the fast-track of C++ Committee. C++/CLI properties are going somehow across (hm, I do not know if that's a good word) ICF as proposed in N1611, as both may result in function call taking form: object.member_variable
difference is that properties privide clean notion of getter/setter, while in ICF things appear to be more complicated.
ICF's notion of setting values when it must be done through member functions, what it calls filtering which needs a proxy class, is much more complicated than setting properties via a member function in the property notation as exemplified in the above proposal ( and in Delphi/C++ Builder ). For that reason I favor a separate proposal on properties, as exemplified above, which is outside the bounds of ICF.
On the other side properties do not seem to support template getter/setter .
I feel that properties, purely in the form of setter/getter functions and without any special notation for RAD introspection, can be done using templates and pure C++ notation, with boost::function serving as the glue which ties the property to setter/getter functions. If I can work something out along these lines I will post it.
| -----Original Message----- | From: boost-bounces@lists.boost.org | [mailto:boost-bounces@lists.boost.org] On Behalf Of Daniel Frey | Sent: 12 March 2004 13:53 | To: boost@lists.boost.org | Subject: [boost] Re: Implicitly-Callable Functions in C++0x? | -problem. | | > 2.couldn't you just make a default choice? Let enable_if | disable some if | > there is an ambiguity? | | Not an option IMHO. A default is exactly what should be avoided at all cost. If | someone uses quad-doubles or RWDecimal, he has a reason to do | so. Silently injecting doubles (or any other default) could do a lot of | damage and thus will work against the acceptance of the library. Safe | use with no surprises is a lot more important than convenience and a | default type isn't safe. Agreed strongly - for me, the most important point about constants is ensuring that you get EXACTLY the right value for the type. For fancy UDTs (eg quad-doubles or RWDecimal or intervals) this is tricky but THE objective. Paul Paul A Bristow Prizet Farmhouse, Kendal, Cumbria UK LA8 8AB +44 1539 561830 +44 7714 330204 mailto: pbristow@hetp.u-net.com
Thorsten Ottosen wrote:
"Paul A Bristow" <boost@hetp.u-net.com> wrote in message news:001501c40795$ce631ce0$0c010101@hetp3...
From a very quick study of this, this radical proposal avoids nasty brackets "pi()" by adding a new C++ keyword implicit to make "pi" have the same effect.
Considering what Daniel can do, I don't think the math constant part of
"Daniel Frey" <d.frey@gmx.de> skrev i meddelandet news:c2rrjl$ero$1@sea.gmane.org... the
proposal brings anything.
Basically, I agree. When I sorted out the VC-issues and finished the documentation, I'll have a deeper look at the ICF-proposal and post some comments to csc++. FWIW, my gut feeling is that the proposal it not worth the trouble.
However: I can do many, but not all things proposed. There is one thing (syntax) that I cannot do but that I like very much:
pi<T>
But you don't need the entire Implicitly Callable Functions just to have constants. What about templated constants, if that is what you want? template<class T> T const pi; template<> float const pi = 3.14159f; template<> double const pi = ... ; Bo Persson
"Bo Persson" <bop@gmb.dk> writes: | But you don't need the entire Implicitly Callable Functions just to have | constants. What about templated constants, if that is what you want? I have been suggesting variables templates for a long time... with no much success :-( If you can help, yay! Personally, I believe that constant-valued functions + user-defined literals + variable templates give you all of ICF. The first two are already proposed. -- Gaby
participants (10)
-
Beman Dawes -
Bo Persson -
Bronek Kozicki -
Daniel Frey -
Daniel Frey -
David Abrahams -
Edward Diener -
Gabriel Dos Reis -
Paul A Bristow -
Thorsten Ottosen