Whidbey and Managed Extensions, clarifications.
Garrett Serack made some comments on my last blog entry that I thought were interesting enough to share with everyone. He asks:
And how about forward source-level compatability between .net 1.1 and whidbey? Is the current batch of Managed C++ gonna work just as well?
Yes! One of our goals in Whidbey is to keep backwards-compatibility with Managed Extensions. They'll be accessible through a new switch, /clr:oldSyntax. (The plain /clr switch will now mean the new C++ syntax.) In most cases, you can just change your makefiles or project settings to use the /clr:oldSyntax switch, and your code will continue to compile as it used to.
Additionally, it is rumored that Stan Lippman is working on a Managed Extensions -> new C++ syntax conversion tool to be shipped with Whidbey.
What's even more interesting is that in many cases .NET assemblies compiled with /clr:oldSyntax will work correctly with Whidbey C++ .NET assemblies, since they both target the CLR. What this means is that you can often keep your existing sourcebase, but use the new C++ syntax with new code, and expect it to work together! (Then, as you have time and money, work on converting your other sourcebase over to the new syntax.) Brandon Bray made a post recently concerning some of these issues over at his blog.
Garrett also asked a great question about the last code example in my previous post, which made me realize I might not have been clear enough:
I have a q' about that line:
if(!x && !y && !z){
//you won't get into this code branch!
}Is the reason that you won't get into the inside of the if because the !z doesn't compare to nonzero? That'd be kind of a pity :(
That would be a pity! Luckily, that's not the case. The reason you won't get inside the if statement is not because of z, but because of y. Let's take another look at the code sample:
int* x = 0; //sets x to null
int^ y = 0; //boxes the integer value zero and puts it inside y
int^ z = nullptr; //sets z to null
if(!x && !y && !z){
//you won't get into this code branch!
}
In this example, the conditions for entering the loop are that all three variables evaluate to false. They are all pointer-types, and so have implicit conversions to bool, which means we can evaluate them to true and false. In the case of x and z, they are null values, and so they do evaluate to false.
The problem is actually with y, which appears to be assigned a null value, but is actually pointing to a valid object. This is a consequence of the implicit boxing, which takes the literal integer value zero, and boxes it onto the GC heap, and makes y refer to it. That's quite a bit different from null! :)
Thanks for the feedback, Garrett!
Comments
- Anonymous
December 10, 2003
Sweet!
Thanks for that clarification.
I sure hope Stan Lippman comes thru with that tool, I've got a bunch of code I'd love to see updated to the new standard in time.
That being said, I've been working thru the C++/CLI draft doc and I've got a couple questions (although I'm not quite finished :)
1. What about partial types?
2. Given the statement found on Brandon Bray's blog about "Leave no room for a lower level language on the CLR than C++." , what about inline MSIL? :)
Garrett - Anonymous
December 10, 2003
More good feedback, and another good post as a result. If you keep asking questions, I may never have to think up my own subjects to prattle on about! :)
Regarding Stan's tool, a guy I know in another team is actively testing it. I hear it's coming along pretty well. - Anonymous
May 29, 2009
PingBack from http://paidsurveyshub.info/story.php?title=i-love-that-new-syntax-smell-whidbey-and-managed-extensions