It depends on what you mean by "consistency." The reason I bring up range-based for loops is because, before this change, C++ was consistent in its lack of identifier enforcement. To say that this is impossible is an exaggeration...TylerH said:Is it worth it to keep with conventions if they limit the convenience of using the language? Consistency is impossible in a complete language.
It's not enforced. You can implement them if you want your class to work with the new for loop, just like you have to implement operator+ if you want your class to work with the + operator.Jocko Homo said:It depends on what you mean by "consistency." The reason I bring up range-based for loops is because, before this change, C++ was consistent in its lack of identifier enforcement. To say that this is impossible is an exaggeration...
TylerH said:Is it worth it to keep with conventions if they limit the convenience of using the language? Consistency is impossible in a complete language.
Don't troll. :grumpy:TylerH said:Impossible is far from an exaggeration. http://en.wikipedia.org/wiki/Gödel's_incompleteness_theorems#First_incompleteness_theorem You can either be complete or consistant.
Also, before c++0x, the language was consistent in its lack of range-based for loops, its lack of lambda expressions, its lack of variadic templates, its requirement for the type of a variable to be explicit at declaration, ...Jocko Homo said:It depends on what you mean by "consistency." The reason I bring up range-based for loops is because, before this change, C++ was consistent in its lack of identifier enforcement.
That's really not a fair comparison...TylerH said:It's not enforced. You can implement them if you want your class to work with the new for loop, just like you have to implement operator+ if you want your class to work with the + operator.
In programming, when people refer to "completeness," they're usually referring to Turing completeness. I'm trying to give you the benefit of the doubt (something you didn't appear to give me!) but I'm really not sure how Gödel's incompleteness theorems apply to programming languages. We're not proving theorems with our languages and "consistency" in this context is not referring to the uniformity of function or behavior. Could you please elaborate?Impossible is far from an exaggeration. http://en.wikipedia.org/wiki/Gödel's_incompleteness_theorems#First_incompleteness_theorem You can either be complete or consistant. C++ chose to strive for completeness, apparently.
I wouldn't characterize my attitude as "worked up." Is that what it looks like to you?Hurkyl said:Also, before c++0x, the language was consistent in its lack of range-based for loops, its lack of lambda expressions, its lack of variadic templates, its requirement for the type of a variable to be explicit at declaration, ...
Seriously, I find this an odd thing to get worked up over. I honestly don't understand how someone can find this important or even merely notable. Doubly so, given the slew of operator foo functions that various language constructs invoke.
They're established conventions in the standard libraries but that's all they were. Previously, the C++ compiler knew nothing of the standard libraries. They were completely divorced. You could delete them off your drive or even replace them with something else and still compile code just fine...It's also not like begin and end came out of nowhere -- this usage had already been established in the standard libraries.
That is nonsense. #include and #define are very different beasts. Macros are what #define creates, not #include. Conflating #include and #define is trolling. BOOST_FOREACH is a macro, something to be eschewed. Many people / many programming standards deem macros to be so inherently bad that they should never, ever be used, even something as simple as NULL. The vast majority of the C++ and Boost libraries are in the form of templates, which are very useful things.Jocko Homo said:You had to use the preprocessor to use template libraries in your code with the use of the include directive, which is basically just one giant macro.
That is exactly what it looks like to me. You are trying to create an issue where the only issue is that a number of languages have this exact feature and the current C++ does not. This is an incredibly compact and rather handy capability. Yes, it may be a bit of syntactic sugar, but it is sweet ...Jocko Homo said:I wouldn't characterize my attitude as "worked up." Is that what it looks like to you?
I've already explained how they're related. They're related in how they are both required for an optional feature. How else could it be done? Is it only the fact that they require a specific symbol name(begin and end) your only complaint? If so, what alternative would you propose, and why is it better?Jocko Homo said:That's really not a fair comparison...
You obviously have to implement something to get your containers to work with range-based for loops but if you want these new loops, you do have to use certain identifier names, which is weird. Before, it didn't matter what aspect of the language you used, you never had to do this. This has changed...
Your operator comparison makes no sense. That's like trying to compare what I'm saying to the fact that, in order to use while loops, you have to test a condition. Yes, you have to do certain things to do certain other things. It's hard to get around that. How is operator overloading the same as enforcing identifier names?
It applies in that the language can either be consistent in functionality or complete in functionality. You're arguing for consistency; I'm saying completeness is just as good.Jocko Homo said:In programming, when people refer to "completeness," they're usually referring to Turing completeness. I'm trying to give you the benefit of the doubt (something you didn't appear to give me!) but I'm really not sure how Gödel's incompleteness theorems apply to programming languages. We're not proving theorems with our languages and "consistency" in this context is not referring to the uniformity of function or behavior. Could you please elaborate?
If you're going to continue down this line of thought, you need to make a connection to Gödel's theorem more substantial than using homonyms of some of the words involved.TylerH said:It applies in that the language can either be consistent in functionality or complete in functionality.
Your experiment wouldn't work if you replaced "operator+" with "plus", or of you replaced "int" with "integer".Jocko Homo said:For example, I could do a search and replace for all instances of "begin" and "end" and replace them with "beginner" and "endorino" respectively and everything will work exactly the same because C++ never enforced identifier names on the user.
Just when I thought I was walking away from The Twilight Zone...D H said:That is nonsense. #include and #define are very different beasts. Macros are what #define creates, not #include. Conflating #include and #define is trolling. BOOST_FOREACH is a macro, something to be eschewed. Many people / many programming standards deem macros to be so inherently bad that they should never, ever be used, even something as simple as NULL. The vast majority of the C++ and Boost libraries are in the form of templates, which are very useful things.
I compared them to macros because... well, they're similar. I don't see how pointing this out is trolling but if you really feel this way then you should press the "report" button beside my post...D H said:The entirety of C++ libraries are implemented using the preprocessor? Where did you get that idea? Most of the C++ library is in the form of templates. The preprocessor doesn't know beans about templates.
Now that I think about it, I am enjoying this thread so, I guess in that sense, I'm getting worked up. It's just that Hurkyl made it sound like I was upset or something...That is exactly what it looks like to me. You are trying to create an issue where the only issue is that a number of languages have this exact feature and the current C++ does not. This is an incredibly compact and rather handy capability. Yes, it may be a bit of syntactic sugar, but it is sweet ...
I'm having trouble understanding what you mean in this paragraph here but I'll take a guess and run it. This is another example of how a little specificity might have been helpful...I don't get your issue at all with current C++ not saying anything about the semantics of identifiers. It most certainly does! You raised two examples of where it does exactly that: constructors and destructors. The existing standard has quite a bit to say and semantics of constructors and destructors.
That's a good question. I think someone earlier in this thread mentioned a range-based for loop implementation made using just the previous C++ specification. I think it was part of the Boost library...TylerH said:I've already explained how they're related. They're related in how they are both required for an optional feature. How else could it be done? Is it only the fact that they require a specific symbol name(begin and end) your only complaint? If so, what alternative would you propose, and why is it better?
In regards to Gödel's incompleteness theorems, given any axiomatic system sufficiently powerful enough to describe the natural numbers, "consistent" means that there exists no true statement whose negation is also true, and "complete" means that every true statement in said system is provable.It applies in that the language can either be consistent in functionality or complete in functionality. You're arguing for consistency; I'm saying completeness is just as good.
I'm not sure what point you're trying to make here. If I replaced "{" with "(" then my experiment would also not work but I don't place special meaning to that fact...Hurkyl said:Your experiment wouldn't work if you replaced "operator+" with "plus", or of you replaced "int" with "integer".
I don't see why you think it's strange. The identifier int has a special meaning. The language designers decided programmers aren't be allowed to shadow it, so they made it a keyword. The identifier begin has a special meaning. The language designers decided not to forbid programmers from shadowing it, so it's not a keyword.Jocko Homo said:"int" is a keyword. It has special meaning which is why you can't simply replace it with an identifier. "operator +" is an operator. It also has special meaning which is why you can't simply replace it with an identifier. If you use range-based for loops then "begin" and "end" also have special meaning... despite they not being keywords... Instead, they're identifiers that you may or may not use... except in range-based for loops where you'd better be using them!
If this page resembles what will go into c++0x, so is the version in the standard, by overloading the (non-member) functions begin and end.In fact, it happens to be extensible!