Re: [boost] Report from Berlin C++ Standards Committee meeting
Doug Gregor wrote:
On Apr 10, 2006, at 3:58 AM, Reece Dunn wrote:
In terms of C++0x features, what is the current state of lambda support as I have seen several papers from Bjarne, et. al.?
I don't think being the fourth of five authors on one lambda proposal counts as "Bjarne et. al." :)
I could only remember Bjarne as being one of the people involved with a wg21 paper on Lambda from www.open-std.org. Maybe I should have said Doug et. al. :)
The driving forces behind lambdas for C++0x are Jeremiah Willcock, Jaakko Jarvi, and Valentin Samko.
I'll keep an eye out for papers from them.
The lambda proposals are still in an early state of development and will take a couple months to mature. There are many unanswered questions about the scope of lambdas (how much can/should they express?), various design features (polymorphic vs. monomorphic, how to handle references to local variables), etc. I have no doubt the authors will spiral in on the right solution, but they could certainly use more feedback.
Sure. I am interested in Lambda functions and have knowledge of Haskell (and more recently Python :)) and the Boost.Phoenix/Lambda libraries. - Reece _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/
The driving forces behind lambdas for C++0x are Jeremiah Willcock, Jaakko Jarvi, and Valentin Samko.
RD> I'll keep an eye out for papers from them. Currently there are two lambda proposals, one from me and another from Jaakko and Jeremiah, et al. The main reason we have two proposals is that we did not know about each other's proposal until the final drafts were ready. The main difference between these proposals (apart from minor syntactic differences) is that in one the local scope variables are copied by reference to the lambda object by default and in another they are copied by value. There are advantages and disadvantages in both approaches. We are currently working on resolving issues raised during the committee meeting and hopefully will write a new paper on lambdas. Any feedback on this topic will be highly appreciated. Valentin Samko http://val.samko.info/
Valentin Samko wrote:
We are currently working on resolving issues raised during the committee meeting and hopefully will write a new paper on lambdas. Any feedback on this topic will be highly appreciated.
I was looking at the lambda papers recently and I came to the conclusion that what we actually need is local functions. To pick an example from N1958: void foo( myvec& v, const myset& s, int a ) { // ... v.erase( std::remove_if(v.begin(), v.end(), bool(int x) { return std::abs(x) < a && s.find(x) != s.end(); }), v.end() ); } What I really want is this: void foo( myvec& v, const myset& s, int a ) { // ... inline bool f( int x ) { return std::abs( x ) < a && s.find( x ) != s.end(); } v.erase( std::remove_if( v.begin(), v.end(), f ), v.end() ); } for obvious readability reasons. This syntax also allows me to use a more descriptive name instead of f, and the consistency with ordinary function definitions will make it easier to teach. It may be somewhat easier to parse or specify, but I haven't considered this in detail.
On Behalf Of Peter Dimov
What I really want is this:
What I really want to be able to do is everything I can do in Haskell, but in C++ :) I'm very grateful for Boost.Lambda but language support is needed to make it fully functional (pun not intended).
void foo( myvec& v, const myset& s, int a ) { // ...
inline bool f( int x ) { return std::abs( x ) < a && s.find( x )
!=
s.end(); }
v.erase( std::remove_if( v.begin(), v.end(), f ), v.end() ); }
I like local functions, but one problem I see with this is that it can't work in a template. If you make f a template it will be ambiguous without a cast or something. If only we could pass functions by name.
Brock Peabody wrote:
void foo( myvec& v, const myset& s, int a ) { // ...
inline bool f( int x ) { return std::abs( x ) < a && s.find( x ) != s.end(); }
v.erase( std::remove_if( v.begin(), v.end(), f ), v.end() ); }
I like local functions, but one problem I see with this is that it can't work in a template. If you make f a template it will be ambiguous without a cast or something. If only we could pass functions by name.
The 'f' above is not really a function, it's a function object, a named lambda. The only difference with Valentin Samko's lambda proposal: http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1958.pdf is in the syntax. I'd prefer to not be forced to spell the type of the arguments: inline bool less( x, y ) { return x < y; } (and live with the ambiguities when x is a type in an outer scope) but even with explicit typing as in N1958 it's much better than nothing. :-) It doesn't beat Dave's _1 < _2 challenge, but I'm not sure that it has to.
inline bool f( int x ) { return std::abs( x ) < a && s.find( x )
PD> The 'f' above is not really a function, it's a function object, a named PD> lambda. The only difference with Valentin Samko's lambda proposal: PD> http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1958.pdf PD> is in the syntax. I'd prefer to not be forced to spell the type of the PD> arguments: PD> inline bool less( x, y ) { return x < y; }
This is what I mentioned in Annex A/2. I just did not want to overcomplicate the proposal with template lambdas as this functionality can be added later. With the "auto" keyword one would be able to write auto f = <> less(x, y) { return x < y; }; where "f" is a function object, somewhat equivalent to a local function. This is from a mixture of n1958 and n1968 which we are working on. PD> It doesn't beat Dave's _1 < _2 challenge, but I'm not sure that it has to. The problem with _1 < _2 is that you still need to put it inside {...} to limit the scope of the lambda, and some prefix like <> to avoid the forward lookup which must be done by the compiler. And once you add that, the only difference is that with _1 and _2 you do not have to declare the arguments and need to add the explicit "return" keyword. A bigger problem is how to access local variables in the lambda. There are reasonable objections to all the default options and we may end up disabling access to the local scope variables by default. Also, if I understood Herb Sutter right, he wants to see all the static and namespace scope variables (referenced in the lambda function) to be copied to that lambda object by default by value. This would be more of a problem. Valentin Samko http://val.samko.info
Valentin Samko wrote:
With the "auto" keyword one would be able to write
auto f = <> less(x, y) { return x < y; };
where "f" is a function object, somewhat equivalent to a local function. This is from a mixture of n1958 and n1968 which we are working on.
Not bad, although I still prefer inline f( x, y ) { return x < y; }
On Apr 12, 2006, at 4:18 PM, Peter Dimov wrote:
Brock Peabody wrote:
void foo( myvec& v, const myset& s, int a ) { // ...
inline bool f( int x ) { return std::abs( x ) < a && s.find( x ) != s.end(); }
v.erase( std::remove_if( v.begin(), v.end(), f ), v.end() ); }
I like local functions, but one problem I see with this is that it can't work in a template. If you make f a template it will be ambiguous without a cast or something. If only we could pass functions by name.
The 'f' above is not really a function, it's a function object, a named lambda. The only difference with Valentin Samko's lambda proposal:
http://www.open-std.org/JTC1/SC22/WG21/docs/papers/2006/n1958.pdf
is in the syntax. I'd prefer to not be forced to spell the type of the arguments:
inline bool less( x, y ) { return x < y; }
(and live with the ambiguities when x is a type in an outer scope) but even with explicit typing as in N1958 it's much better than nothing. :-)
The syntactic trouble (which I believe Peter is referring to with the comment on ambiguities) is that in a normal function parameter list one can leave out the parameter name, here we would be leaving out the parameter type. I think that is fine, but I'd thus rather make lambdas look different so that there is no confusion of what kind of parameter list we are dealing with. (e.g. with the syntax <>(x, y) { return x < y; } ) Flagging an ambiguity in the case that the parameter name would be a type in an outer scope seems quite brittle. Cheers, Jaakko
Jaakko Jarvi wrote:
On Apr 12, 2006, at 4:18 PM, Peter Dimov wrote:
I'd prefer to not be forced to spell the type of the arguments:
inline bool less( x, y ) { return x < y; }
(and live with the ambiguities when x is a type in an outer scope) but even with explicit typing as in N1958 it's much better than nothing. :-)
The syntactic trouble (which I believe Peter is referring to with the comment on ambiguities) is that in a normal function parameter list one can leave out the parameter name, here we would be leaving out the parameter type. I think that is fine, but I'd thus rather make lambdas look different so that there is no confusion of what kind of parameter list we are dealing with.
(e.g. with the syntax <>(x, y) { return x < y; } )
Flagging an ambiguity in the case that the parameter name would be a type in an outer scope seems quite brittle.
But I should also note that there are three cases: 1. Lambdas require explicit argument types, as ordinary functions do; 2. Lambdas do not have explicit argument types (as in the above examples); 3. Lambdas allow explicit argument types but do not require them. The ambiguity arises only in (3). (1) and (2) don't have this problem.
On Apr 13, 2006, at 10:05 AM, Peter Dimov wrote:
Jaakko Jarvi wrote:
On Apr 12, 2006, at 4:18 PM, Peter Dimov wrote:
I'd prefer to not be forced to spell the type of the arguments:
inline bool less( x, y ) { return x < y; }
(and live with the ambiguities when x is a type in an outer scope) but even with explicit typing as in N1958 it's much better than nothing. :-)
The syntactic trouble (which I believe Peter is referring to with the comment on ambiguities) is that in a normal function parameter list one can leave out the parameter name, here we would be leaving out the parameter type. I think that is fine, but I'd thus rather make lambdas look different so that there is no confusion of what kind of parameter list we are dealing with.
(e.g. with the syntax <>(x, y) { return x < y; } )
Flagging an ambiguity in the case that the parameter name would be a type in an outer scope seems quite brittle.
But I should also note that there are three cases:
1. Lambdas require explicit argument types, as ordinary functions do; 2. Lambdas do not have explicit argument types (as in the above examples); 3. Lambdas allow explicit argument types but do not require them.
The ambiguity arises only in (3). (1) and (2) don't have this problem.
Yes, very true. My concern with (2) if the syntax of lambdas is practically the same as normal functions is having two kind of function definitions (local and global) with seemingly the same syntax, but yet with different behavior. There is another related problem on which discussion would be welcomed. Assuming no types need to be provided for the parameter types, what is the parameter passing mode? It seems that && makes the most sense, but we haven't found a good syntax to override this. OTOH, we don't have strong arguments why the parameter passing mode should be allowed to be overridden. Best, Jaakko
Jaakko Jarvi wrote:
There is another related problem on which discussion would be welcomed. Assuming no types need to be provided for the parameter types, what is the parameter passing mode?
auto&&, of course. This is what the current library solutions do (or would do if there were && in the language).
inline bool less( x, y ) { return x < y; } ... be leaving out the parameter type. I think that is fine, but I'd thus rather make lambdas look different so that there is no confusion of what kind of parameter list we are dealing with.
(e.g. with the syntax <>(x, y) { return x < y; } )
It seems to me that the use of the "inline" keyword inside a function body makes it stand out sufficiently. The use of "auto" or "<>" is no better at making it stand out, but not as meaningful when reading the code. Darren
Darren Cook <darren@dcook.org> writes:
inline bool less( x, y ) { return x < y; } ... be leaving out the parameter type. I think that is fine, but I'd thus rather make lambdas look different so that there is no confusion of what kind of parameter list we are dealing with.
(e.g. with the syntax <>(x, y) { return x < y; } )
It seems to me that the use of the "inline" keyword inside a function body makes it stand out sufficiently. The use of "auto" or "<>" is no better at making it stand out, but not as meaningful when reading the code.
I actually like inline, even if it is a bit longer than auto. -- Dave Abrahams Boost Consulting www.boost-consulting.com
Peter Dimov wrote:
Valentin Samko wrote:
We are currently working on resolving issues raised during the committee meeting and hopefully will write a new paper on lambdas. Any feedback on this topic will be highly appreciated.
I was looking at the lambda papers recently and I came to the conclusion that what we actually need is local functions. To pick an example from
and function objects?
N1958:
void foo( myvec& v, const myset& s, int a ) { // ... v.erase( std::remove_if(v.begin(), v.end(), bool(int x) { return std::abs(x) < a && s.find(x) != s.end(); }), v.end() ); }
What I really want is this:
void foo( myvec& v, const myset& s, int a ) { // ...
inline bool f( int x ) { return std::abs( x ) < a && s.find( x ) != s.end(); }
This goes beyond simple local functions, with the ability to access s and a from the enclosing function scope. I like it. :) Saves the need of a full function object with explicit reference members to s and a.
v.erase( std::remove_if( v.begin(), v.end(), f ), v.end() ); }
for obvious readability reasons. This syntax also allows me to use a more descriptive name instead of f, and the consistency with ordinary function definitions will make it easier to teach. It may be somewhat easier to parse or specify, but I haven't considered this in detail.
I've never understood the reason that local function objects were not able to be used with templates. IMO, algorithms would have been much more readily adopted. Jeff
"Peter Dimov" <pdimov@mmltd.net> writes:
What I really want is this:
void foo( myvec& v, const myset& s, int a ) { // ...
inline bool f( int x ) { return std::abs( x ) < a && s.find( x ) != s.end(); }
v.erase( std::remove_if( v.begin(), v.end(), f ), v.end() ); }
for obvious readability reasons.
Local functions would be great. I still think we need lambda expressions to handle the simple _1->first < 0 cases, and especially those cases where the function needs or ought to be templated. I think the syntax should be auto(x){ x->first < 0 } -- Dave Abrahams Boost Consulting www.boost-consulting.com
Bronek Kozicki <brok@rubikon.pl> writes:
David Abrahams wrote:
cases, and especially those cases where the function needs or ought to be templated. I think the syntax should be
auto(x){ x->first < 0 }
where is "return" ?
Good observation. Nowhere. Have you got a problem with that? Also no semicolon. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
be templated. I think the syntax should be
auto(x){ x->first < 0 } where is "return" ?
Good observation. Nowhere. Have you got a problem with that? Also no semicolon.
it's not function body, then. It's an expression. C'mon, I do not think that this could be honestly called "lambda". B.
Bronek Kozicki wrote:
David Abrahams wrote:
be templated. I think the syntax should be
auto(x){ x->first < 0 } where is "return" ? Good observation. Nowhere. Have you got a problem with that? Also no semicolon.
it's not function body, then. It's an expression. C'mon, I do not think that this could be honestly called "lambda".
It could be an expression or a statement-list, why couldn't it be called lambda? I would say most lambda expressions would be simple expressions, in which "return" is just unnecessary clutter. If they are too complicated they should be moved out to a named function anyway, IMO.. -- Daniel Wallin
Bronek Kozicki <brok@rubikon.pl> writes:
David Abrahams wrote:
be templated. I think the syntax should be
auto(x){ x->first < 0 } where is "return" ?
Good observation. Nowhere. Have you got a problem with that? Also no semicolon.
it's not function body, then. It's an expression. C'mon, I do not think that this could be honestly called "lambda".
C'mon, haven't you ever heard of something called a "lambda expression?" Yes, of course it's an expression. We make a provision that a lambda expression can end with a simple expression in which case that is its return value. It could be made into a statement and a valid function body like this: auto(x) { x->first < 0; } but then such a statement normally does *not* return, and the semicolon adds a little confusion, one more character, and nothing of value. Adding "return" for the majority of simple lambda expressions would result in a 25-30% increase in total non-whitespace characters, which is a big lose. -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams wrote:
auto(x){ x->first < 0 } where is "return" ? Good observation. Nowhere. Have you got a problem with that? Also no semicolon. it's not function body, then. It's an expression. C'mon, I do not think that this could be honestly called "lambda".
C'mon, haven't you ever heard of something called a "lambda expression?"
I have not seen one in C++, yet ;)
Adding "return" for the majority of simple lambda expressions would result in a 25-30% increase in total non-whitespace characters, which is a big lose.
I understand, but it would be nice to 1. look at all use cases where lamba is wanted and useful and 2. avoid confusing syntax. B.
Bronek Kozicki <brok@rubikon.pl> writes: | David Abrahams wrote: | >>> be templated. I think the syntax should be | >>> | >>> auto(x){ x->first < 0 } | >> where is "return" ? | > | > Good observation. Nowhere. Have you got a problem with that? Also | > no semicolon. | | it's not function body, then. It's an expression. C'mon, I do not think that | this could be honestly called "lambda". according to which definition of "lambda"? -- Gaby
David Abrahams wrote:
cases, and especially those cases where the function needs or ought to be templated. I think the syntax should be
auto(x){ x->first < 0 }
where is "return" ?
DA> Good observation. Nowhere. Have you got a problem with that? Also DA> no semicolon. So, auto(x){ x->first < 0 } returns bool, and auto(x){ x->first < 0; } returns void? I think it is very confusing and error prone to change the return type when user misses (or accidently types) a semicolon. Valentin Samko http://val.samko.info
Valentin Samko <boost@digiways.com> writes:
David Abrahams wrote:
cases, and especially those cases where the function needs or ought to be templated. I think the syntax should be
auto(x){ x->first < 0 }
where is "return" ?
DA> Good observation. Nowhere. Have you got a problem with that? Also DA> no semicolon.
So, auto(x){ x->first < 0 } returns bool, and auto(x){ x->first < 0; } returns void?
Did I say that? I didn't mean to say that. -- Dave Abrahams Boost Consulting www.boost-consulting.com
So, auto(x){ x->first < 0 } returns bool, and auto(x){ x->first < 0; } returns void?
Did I say that? I didn't mean to say that.
Yes, it sounded like that was maybe what you meant (in another message in this thread - quoted below). So what does the version with the semi-colon return? Or would the semi-colon be a syntax error? Darren -------------- Yes, of course it's an expression. We make a provision that a lambda expression can end with a simple expression in which case that is its return value. It could be made into a statement and a valid function body like this: auto(x) { x->first < 0; } but then such a statement normally does *not* return, and the semicolon adds a little confusion, one more character, and nothing of value.
Darren Cook <darren@dcook.org> writes:
So, auto(x){ x->first < 0 } returns bool, and auto(x){ x->first < 0; } returns void?
Did I say that? I didn't mean to say that.
Yes, it sounded like that was maybe what you meant (in another message in this thread - quoted below).
But I didn't say that. I didn't mean that either. I didn't mean to make any statement about what happens in the second case. I only made a claim about its normal behavior when it is part of a function body. I was claiming that leaving out the semicolon is not only less needlessly verbose, but it could act as a (admittedly subtle) signal that it's not just an ordinary statement.
So what does the version with the semi-colon return? Or would the semi-colon be a syntax error?
One viable possibility is that the semicolon could be optional, and could result in no change of meaning. -- Dave Abrahams Boost Consulting www.boost-consulting.com
On Behalf Of David Abrahams
Local functions would be great. I still think we need lambda expressions to handle the simple
_1->first < 0
That's awesome! What about _1.first < 0 ? If we're going that far how about currying? Could we eliminate the need for bind completely? _1.f(_2) < 0
I think the syntax should be
auto(x){ x->first < 0 }
I like that! Would you be able to name them? If so then would I ever need to use the word 'template' with a function again?
DA> Local functions would be great. I still think we need lambda DA> expressions to handle the simple DA> _1->first < 0 DA> cases, and especially those cases where the function needs or ought to DA> be templated. I think the syntax should be DA> auto(x){ x->first < 0 } This is quite similar to what we are considering for polymorphic lambdas, <>(x) { return x->first < 0; } Valentin Samko http://val.samko.info
Valentin Samko <boost@digiways.com> writes:
DA> auto(x){ x->first < 0 }
This is quite similar to what we are considering for polymorphic lambdas, <>(x) { return x->first < 0; }
Except 1/3 longer, and, I guess for some people, there's a huge difference in aesthetics -- Dave Abrahams Boost Consulting www.boost-consulting.com
Peter Dimov wrote:
What I really want is this:
void foo( myvec& v, const myset& s, int a ) { // ...
inline bool f( int x ) { return std::abs( x ) < a && s.find( x ) != s.end(); }
v.erase( std::remove_if( v.begin(), v.end(), f ), v.end() ); }
for obvious readability reasons. This syntax also allows me to use a more descriptive name instead of f, and the consistency with ordinary function definitions will make it easier to teach. It may be somewhat easier to parse or specify, but I haven't considered this in detail.
I also really like this syntax, and the other example suggested by Peter: inline f( x, y ) { return x < y; } It seems natural and easy to understand. I think not having to specify parameter types when they can be worked out by the compiler is also important. But I'm not a compiler writer. Are there good reasons not to do it this way? Darren
On Apr 12, 2006, at 7:38 PM, Darren Cook wrote:
Peter Dimov wrote:
What I really want is this:
void foo( myvec& v, const myset& s, int a ) { // ...
inline bool f( int x ) { return std::abs( x ) < a && s.find ( x ) != s.end(); }
v.erase( std::remove_if( v.begin(), v.end(), f ), v.end() ); }
for obvious readability reasons. This syntax also allows me to use a more descriptive name instead of f, and the consistency with ordinary function definitions will make it easier to teach. It may be somewhat easier to parse or specify, but I haven't considered this in detail.
I also really like this syntax, and the other example suggested by Peter: inline f( x, y ) { return x < y; }
It seems natural and easy to understand. I think not having to specify parameter types when they can be worked out by the compiler is also important.
But I'm not a compiler writer. Are there good reasons not to do it this way?
In current C++, there would be no good reasons to not do it this way. In C++0x, assuming it supports constrained templates, separate type- checking of such lambdas will be more difficult, n1968 has a discussion about this topic. By separate type-checking I mean that the body of the lambda function is type-checked at the point of its definition, rather than at the point of where the lambda is invoked. We are looking into this issue, and are fairly confident that _essentially_ separate type checking can still be achieved even if parameter types are not specified. n1968 hints at how this is accomplished. In any case, there will necessarily be some separation of the point of definition and the point of type checking because of auto: auto f = <> (x, y) { return x + y; } // no information to type-check the body ... a lot of code here ... transform(a.begin(), a.end(), b.begin(), f) // we can get information from the constraints of transform to type check the body of f Best, Jaakko
"Peter Dimov" wrote
What I really want is this:
void foo( myvec& v, const myset& s, int a ) { // ...
inline bool f( int x ) { return std::abs( x ) < a && s.find( x ) != s.end(); }
v.erase( std::remove_if( v.begin(), v.end(), f ), v.end() ); }
for obvious readability reasons. This syntax also allows me to use a more descriptive name instead of f, and the consistency with ordinary function definitions will make it easier to teach. It may be somewhat easier to parse or specify, but I haven't considered this in detail.
Its interesting that you bring up the teaching issue AFAIK. Robert Rameys earlier point regarding the benefits of what seems to just be a "cool" feature to C++ is apt . Do local functions, named or unnamed really add that much to the language?. They do certainly add another layer of complexity to the parser and whats more important another layer of complexity that students will feel that they must learn and use. C++'s main problem is that it doesnt have enough standard libraries to compete with (say) Java. Two obvious ones still not on the horizon are Unicode and GUI. ( I am going to try to do something about the GUI, though there must be much greater GUI experts than me that could do a better job). A major reason given by the committee AFAICS (in GUI case) was that the committee doesnt have enough time to deal with it. Yet there seems to be adequate time to discuss the addition of more complexities to the language itself. A great language missing some essential standard libraries. Will that be C++ epitaph? bemused Andy Little
Andy Little wrote:
"Peter Dimov" wrote
What I really want is this:
void foo( myvec& v, const myset& s, int a ) { // ...
inline bool f( int x ) { return std::abs( x ) < a && s.find( x ) != s.end(); }
v.erase( std::remove_if( v.begin(), v.end(), f ), v.end() ); }
for obvious readability reasons. This syntax also allows me to use a more descriptive name instead of f, and the consistency with ordinary function definitions will make it easier to teach. It may be somewhat easier to parse or specify, but I haven't considered this in detail.
Its interesting that you bring up the teaching issue AFAIK. Robert Rameys earlier point regarding the benefits of what seems to just be a "cool" feature to C++ is apt . Do local functions, named or unnamed really add that much to the language?. They do certainly add another layer of complexity to the parser and whats more important another layer of complexity that students will feel that they must learn and use.
Yes, local functions do add to the language. What you currently need is: static bool f( int x, int a, myset const & s ) { return abs( x ) < a && s.find( x ) != s.end(); } void foo( myvec& v, const myset& s, int a ) { // ... v.erase( std::remove_if( v.begin(), v.end(), std::bind( f, _1, a, std::ref( s ) ) ), v.end() ); } As you can see, there is an additional bind needed to pass the arguments from the enclosing context to f, but the more important thing is that f needs to be defined outside of foo, removed from the point of use. A local function decreases complexity, and it's much easier to grasp because it's just like an ordinary function, only defined inside of foo.
C++'s main problem is that it doesnt have enough standard libraries to compete with (say) Java. Two obvious ones still not on the horizon are Unicode and GUI. ( I am going to try to do something about the GUI, though there must be much greater GUI experts than me that could do a better job). A major reason given by the committee AFAICS (in GUI case) was that the committee doesnt have enough time to deal with it. Yet there seems to be adequate time to discuss the addition of more complexities to the language itself. A great language missing some essential standard libraries. Will that be C++ epitaph?
This is a pretty common view, but C++ has been missing essential standard libraries for more than ten years, and it still competes with Java. C++ simply doesn't play by the marketing rule that whoever has the more checkboxes wins. It doesn't even have garbage collection! An automatic loss, you'd think. Not only that; what standard libraries C++ does have are often simply not used (iostreams, locale.)
Peter Dimov wrote:
This is a pretty common view, but C++ has been missing essential standard libraries for more than ten years, and it still competes with Java.
The places where C++ competes are shrinking rapidly from what I'm seeing in the 'real-world'. It's a combination of factors including faster machines with more memory, better performance for scripted/interpreted languages, lack of education (schools don't teach C++ as much), and lack of libraries. More worrisome, some places where you would think C++ would dominate (high performance web backends, for example) it simply doesn't compete because of a lack of libraries. Java doesn't dominate in the development of web-backends b/c it's a better language -- it's all about the libraries and tools built on top... All this said, C++ isn't going anywhere -- there are millions and millions of lines of C++ in existing projects that will be maintained for decades to come. And in some domains the performance advantages of C++ are still important.
C++ simply doesn't play by the marketing rule that whoever has the more checkboxes wins. It doesn't even have garbage collection! An automatic loss, you'd think.
Of course C++ has garbage collection -- it's one library Java just doesn't have ;-) http://www.hpl.hp.com/personal/Hans_Boehm/gc/ Jeff
"Peter Dimov" wrote
Yes, local functions do add to the language. What you currently need is:
static bool f( int x, int a, myset const & s ) { return abs( x ) < a && s.find( x ) != s.end(); }
void foo( myvec& v, const myset& s, int a ) { // ...
v.erase( std::remove_if( v.begin(), v.end(), std::bind( f, _1, a, std::ref( s ) ) ), v.end() ); }
As you can see, there is an additional bind needed to pass the arguments from the enclosing context to f, but the more important thing is that f needs to be defined outside of foo, removed from the point of use. A local function decreases complexity, and it's much easier to grasp because it's just like an ordinary function, only defined inside of foo.
Sure, but its an awful lot of work to design, implement and maintain, especially if its going to need its own peculiar syntax. Is the ability to define a function inside another a great win?. The only use is as an argument to functions that iterate through containers like std::for_each AFAICS. (My overall point was that if there was a choice (due to finite resources) between implementing local functions and implementing a standard GUI or Unicode or threads, then I would take one of the latter).
C++'s main problem is that it doesnt have enough standard libraries to compete with (say) Java. Two obvious ones still not on the horizon are Unicode and GUI. ( I am going to try to do something about the GUI, though there must be much greater GUI experts than me that could do a better job). A major reason given by the committee AFAICS (in GUI case) was that the committee doesnt have enough time to deal with it. Yet there seems to be adequate time to discuss the addition of more complexities to the language itself. A great language missing some essential standard libraries. Will that be C++ epitaph?
This is a pretty common view, but C++ has been missing essential standard libraries for more than ten years, and it still competes with Java. C++ simply doesn't play by the marketing rule that whoever has the more checkboxes wins. It doesn't even have garbage collection! An automatic loss, you'd think.
In an ideal world it would be nice not to worry about object lifetimes. From the current threads on clcm the garbage collection issue is not clear cut. My current limited understanding is that it would be too great a distortion to the current language to try to apply garbage collection( excepting smart pointers), especially since it seems to violate the "you dont pay for what you dont use" principle. Maybe C++ is showing its age though!
Not only that; what standard libraries C++ does have are often simply not used (iostreams, locale.)
Are you suggesting that C++ shouldnt have a standard input/output mechanism? FWIW mention of standard streams is apt. A GUI is just an alternative paradigm for I/O. As far as most users of an application are concerned its a much superior I/O mechanism than the command line AFAICS. OTOH If the command line was superior then all modern oses would just provide command line wouldnt they? regards Andy Little
Andy Little wrote:
Is the ability to define a function inside another a great win?. The only use is as an argument to functions that iterate through containers like std::for_each AFAICS.
I have certainly reached for them in other circumstances, to scope a 'helper function' as local to the code that needs it. Maybe it's my Pascal background showing through, although I have not actively written pascal for close to a decade now. Usually when I reach for local functions it is purely a scoping mechanism, and I have no interest in accessing local state of the enclosing function. Accessing that state is what seems to bring the complication, but also all the interesting use cases! -- AlisdairM
Andy Little wrote:
C++'s main problem is that it doesnt have enough standard libraries to compete with (say) Java. Two obvious ones still not on the horizon are Unicode and GUI. ( I am going to try to do something about the GUI, though there must be much greater GUI experts than me that could do a better job). A major reason given by the committee AFAICS (in GUI case) was that the committee doesnt have enough time to deal with it.
Actually I believe the issue is that nobody has proposed a GUI library -- Bjarne has written many times about the desire to see a GUI library. But, its not really a surprise when you consider the huge amount of effort needed to do the design and development of such a proposal -- just to give it away. From the academic side, there isn't much incentive to try and create a C++ GUI library. Honestly, I like to look at this the other way around. C++ is the only language that has multiple cross-platform GUI libraries -- it's bad for training and consistency, but you're not confined to what a single commercial entity provides.
Yet there seems to be adequate time to discuss the addition of more complexities to the language itself. A great language missing some essential standard libraries. Will that be C++ epitaph?
Personally, I'm worried that C++ has had a major slip due to the lack of libraries. But I have to say that there's no way C++ library development can ever compete directly against commercial interests with serious monetary interest in language development (Sun/IBM/Oracle --> Java, Microsoft-->C#). These interests can and do spend millions to advance their platforms. Since C++ is an open standard it can't be owned and hence it just isn't as attractive to these interests with agendas. And you can't blame developers -- they need to get their projects done, not write infrastructure libraries... Jeff
Jeff Garland wrote:
Andy Little wrote:
C++'s main problem is that it doesnt have enough standard libraries to compete with (say) Java. Two obvious ones still not on the horizon are Unicode and GUI. ( I am going to try to do something about the GUI, though there must be much greater GUI experts than me that could do a better job). A major reason given by the committee AFAICS (in GUI case) was that the committee doesnt have enough time to deal with it.
Actually I believe the issue is that nobody has proposed a GUI library -- Bjarne has written many times about the desire to see a GUI library. But, its not really a surprise when you consider the huge amount of effort needed to do the design and development of such a proposal -- just to give it away. From the academic side, there isn't much incentive to try and create a C++ GUI library.
Honestly, I like to look at this the other way around. C++ is the only language that has multiple cross-platform GUI libraries -- it's bad for training and consistency, but you're not confined to what a single commercial entity provides.
I tend to agree. As we have discussed in another thread about GUI work, there are really two orthogonal parts to this: 1) Develop a new GUI architecture, based on past experience. 2) Provide a set of C++ APIs that can map (at compile- or run-time) to different backends. Most people who think about developing a GUI API for C++ in the context of boost seem to either think in terms of 1), or at least want to promote very specific programming idioms, which restrict the choice of possible GUI backends. While I have done my own share of 1), I think for boost it would be more appropriate to focus on 2). Still, it isn't clear that this is possible at all, at least in general. As an exercise, take the major GUI libraries that exist across all platforms and try to provide uniform wrappers for them without 1) restricting yourself to the least common denominator and 2) loosing performance due to late binding and many levels of indirection. Regards, Stefan
Neal Becker wrote:
Jeff Garland wrote:
Honestly, I like to look at this the other way around. C++ is the only language that has multiple cross-platform GUI libraries
Python?
Could be, I'm not a Python expert. Of course Python is also an open language not controlled by commercial interest -- and is certainly a friend of C++ in the language eco system :-) Jeff
On Apr 13, 2006, at 3:20 AM, Andy Little wrote:
A major reason given by the committee AFAICS (in GUI case) was that the committee doesnt have enough time to deal with it.
This is not exactly correct. The committee does not have enough time to *design* a GUI library, nor any other library. Besides, you wouldn't want a library designed by committee, would you? If someone steps up with a proposal for a GUI library, the committee will review it.
Yet there seems to be adequate time to discuss the addition of more complexities to the language itself.
These are different groups within the C++ committee. Libraries are handled by the Library Working Group, language extensions are handled by the Evolution Working Group. Discussing language extensions rarely takes away time from the discussion of new/improved libraries, except where language changes can have a large effect on how libraries are written (e.g., concepts and move semantics). Doug
Hello, Am Donnerstag, den 13.04.2006, 08:20 +0100 schrieb Andy Little:
C++'s main problem is that it doesnt have enough standard libraries to compete with (say) Java.
Very well known but true.
Two obvious ones still not on the horizon are Unicode and GUI.
Oh yes, the first one really. But I do _not_ believe C++ needs a standardised GUI API. Really it would probably end up like the string class as it is: either not used or used unwillingly. (And the string class is way smaller than a reasonable GUI library!) It is not possible to add a good GUI library to the standard and finish it in reasonable time. People should really remove this from their minds. Everything else, sockets, UNICODE, all those nice boost libraries, we need them and they can be done because they are operating in more or less standardised and overseeable fields. GUI is different. And effort should really be concentrated into doing the other things right. Please, please don't stop making GUI toolkits but (please) stop crying them into the standard. My feeling says they do not belong there. Oh and: even regarding those libraries that are not part of the standard, there is _no_ good GUI library available that is free to use and open-source.
( I am going to try to do something about the GUI, though there must be much greater GUI experts than me that could do a better job). A major reason given by the committee AFAICS (in GUI case) was that the committee doesnt have enough time to deal with it. Yet there seems to be adequate time to discuss the addition of more complexities to the language itself. A great language missing some essential standard libraries. Will that be C++ epitaph?
I hope not. And hope is essential :-).
bemused Andy Little
with a bit too strong feelings, Aristid Breitkreuz
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Valentin Samko <boost@digiways.com> writes:
We are currently working on resolving issues raised during the committee meeting and hopefully will write a new paper on lambdas. Any feedback on this topic will be highly appreciated.
I've said it before and I'll say it again: no lambda feature will be satisfying until it can be syntactically competitive with the best library solution for *simple* lambda expressions like _1 < _2 -- Dave Abrahams Boost Consulting www.boost-consulting.com
David Abrahams writes:
Valentin Samko <boost@digiways.com> writes:
We are currently working on resolving issues raised during the committee meeting and hopefully will write a new paper on lambdas. Any feedback on this topic will be highly appreciated.
I've said it before and I'll say it again: no lambda feature will be satisfying until it can be syntactically competitive with the best library solution for *simple* lambda expressions like
_1 < _2
FWIW, I'm 100% with Dave on this one. -- Aleksey Gurtovoy MetaCommunications Engineering
participants (19)
-
Aleksey Gurtovoy -
AlisdairM -
Andy Little -
Aristid Breitkreuz -
Brock Peabody -
Bronek Kozicki -
Daniel Wallin -
Darren Cook -
David Abrahams -
Douglas Gregor -
Gabriel Dos Reis -
Jaakko Jarvi -
Jeff Flinn -
Jeff Garland -
Neal Becker -
Peter Dimov -
Reece Dunn -
Stefan Seefeld -
Valentin Samko