| T O P I C R E V I E W |
| MrDoomMaster |
Posted - Feb 26 2008 : 1:19:29 PM
As you all know, C++0x is speculated for finalization in 2009. I'm curious if you guys have already made plans in regards to the new standard for C++. Do you guys plan to support it? If so, are you going to begin development early so that there is a greater chance of release next year about the same time the standard comes out? I'm not sure how long Microsoft will take to create a conforming compiler, but according to the developer blog they've already began working on compatibility with TR1.
Let me know how things are going. |
| 13 L A T E S T R E P L I E S (Newest First) |
| support |
Posted - Dec 16 2011 : 1:48:56 PM
case=13607 is implemented in build 1862 |
| accord |
Posted - Feb 29 2008 : 3:47:24 PM
Yes, as I said before auto is not a new keyword. It's behavior changed in 0x.
quote:
Hence, "auto" should not be parsed by VAX, otherwise programmers would start using the auto-keyword in the wrong way ;)
Yes, but there will be programmers, who will "overuse" this new fancy keyword. If they leave the company, and I have to find the bugs in his/her source, VAX will help here   |
| feline |
Posted - Feb 29 2008 : 11:21:17 AM
I should have tested this sooner. VC6 does not allow any variables called "auto", they do not compile. I have never tried to use the word, so I had not noticed.
That helps a lot, this will avoid most of the obvious problems and compiler specific behaviours with auto. |
| MrDoomMaster |
Posted - Feb 29 2008 : 10:52:54 AM
quote:
Originally posted by feline
I am confused. As I understand it the auto keyword creates a strongly typed variable. If you are programing with this keyword (the correct IDE, correct patch, etc) then "auto" is a keyword and it creates a typed variable.
If you are programming in VC6 then the code int auto = 2 is going to be valid code.
The fact the keyword might be a variable in existing code is a problem we are going to have to somehow deal with.
However in C++0x it is a reserved word, so you cannot use it as a variable name. Since C++0x will be backwards compatible, you might have to end up checking which IDE you're running in and treat reserved words differently depending on which you're on. |
| feline |
Posted - Feb 29 2008 : 10:25:01 AM
I am confused. As I understand it the auto keyword creates a strongly typed variable. If you are programing with this keyword (the correct IDE, correct patch, etc) then "auto" is a keyword and it creates a typed variable.
If you are programming in VC6 then the code int auto = 2 is going to be valid code.
The fact the keyword might be a variable in existing code is a problem we are going to have to somehow deal with. |
| znakeeye |
Posted - Feb 28 2008 : 12:38:50 PM
quote:
"auto" should not be parsed by VAX[/b]
That is, it should not be interpreted as a typed variable. |
| znakeeye |
Posted - Feb 28 2008 : 12:37:05 PM
In my opinion the "auto" keyword is the most important change in TR1.
This is simply handicapped:
std::map< std::string, std::vector<CMyItem> >::const_iterator iter = m.begin();
I'm looking forward replacing all this ugliness with:
auto iter = m.begin();
The purpose of the "auto" keyword is "I don't care what complex type this variable is. Just use it!".
Hence, "auto" should not be parsed by VAX, otherwise programmers would start using the auto-keyword in the wrong way ;) |
| accord |
Posted - Feb 27 2008 : 4:02:02 PM
Thank you.
I do not rush to use new features like "auto", but it would be nice to see it in the future. Definition field already can tell me the types of Right values, so you can use it to generate the type of the auto.
Yes, there will be edge cases, but an already imlemented feature called "definition field" also can run into edge cases, but despite of it, I am very satisfied user of it.
Certainly on simple types like "float" you have to write an another algorithm.
quote:
The point is fair though, and it certainly applies to listboxes.
Yes, VAX will be in trouble if it wants to populate a listbox with the members of auto |
| feline |
Posted - Feb 27 2008 : 07:51:00 AM
accord in your example it is arguable that the definition field should actually show "auto apple = 5.0f", since that is how the variable is defined. The point is fair though, and it certainly applies to listboxes.
The auto keyword might be tricky. Certainly I can think of edge cases that VA is going to struggle to understand. The real question is simply how often we run into these edge cases.
The other practical question is how important this is. We still have a lot of users working in VC6, which is quite a long distance from VS2008 with an extra patch installed on it.
On a related front, I wonder how many projects out there contain functions and variables called "auto". This code may not respond well to this suddenly becoming a keyword.
I have put in a feature request for this, so we can track it:
case=13607 |
| MrDoomMaster |
Posted - Feb 26 2008 : 3:56:33 PM
quote:
Originally posted by accord
About the linked topic, "auto" keyword is the only "new" (changed) keyword in TR1. Will VAX support it?
So if I write
auto apple = 5.0f;
and I place the carret over the symbol "apple", VAX's Definition field should show "float apple = 5.0f".
I'm not confident VAX will adjust very well to the new standard. The new standard introduces a lot more implicitness which is more difficult to parse and more prone to misunderstandings and confusion by a custom parser. However if VAX can pull through I will definitely be impressed. They already have their hands full as it is. |
| accord |
Posted - Feb 26 2008 : 2:53:17 PM
About the linked topic, "auto" keyword is the only "new" (changed) keyword in TR1. Will VAX support it?
So if I write
auto apple = 5.0f;
and I place the carret over the symbol "apple", VAX's Definition field should show "float apple = 5.0f".
|
| feline |
Posted - Feb 26 2008 : 1:35:38 PM
This discussion might help:
http://forum.wholetomato.com/forum/topic.asp?TOPIC_ID=7190
see the posts on Jan 29 2008 by znakeeye |
| rhummer |
Posted - Feb 26 2008 : 1:24:01 PM
VS2008 will have TR1 support, it should be available with an update to VS2008 that also gives new MFC features IIRC.
When that update is, I don't know. Should be fairly soon though... |
