Short answer is “yes”, I agree that this is perfectly reasonable scenario and, unfortunately, “yes” you may to guard the use of “nullptr” to get it correct in all cases.
Just to be clear, if you write a library and only target native development (with anyone’s compiler including ours) then you use nullptr. If you have a library that is compiled by only Visual C++ and needs to support native and managed, then you use __nullptr
for native and nullptr for managed. The issue is if you do the combination of these (multiple compilers and you want to be able to target both native and managed with Visual C++), then you need a guard.
I am not sure I agree with your last statement however, having “nullptr” (in both native and managed code) solves problems that we cannot solve without them. Unfortunately ECMA C++/CLI and ISO C++ selected the same keyword here but that is life with standard-based
languages. C++/CLI code already exists and, with all other things being equal, we prefer/defer to the "do not breaking existing code" rule.
We do mention somewhere in the video that now we have the re-implementation work completed we will look at performance/cost for the iterator switches and may change the default for VS2010 - no concrete decision yet but stay tuned (as always you will be
able to simply switch between the default and whatever you want by defining a macro too.) But we do hear you on the default issue.
I took no offence from your statements and did not think you said anything negative. It is just that other readers can accidently read unintended intentions into my posts/replies, so sometimes I find it is just best for me to be super explicit
I would agree that recently C++/CLI has found a place as the interop language - while C#/VB/F# add new functionality at a pace that we cannot keep up with if we are also to innovate in the native space as well. And since we are the only native game in the
VS box I personally feel we need to devote more time to the native arena then we have in recent releases,
Personally I am very happy about the new features in C++0x – I agree they took a long time to get here and unfortunately we could not do more of them for VS2010. As we said in the interview, not having variadic templates in VS2010 is Stephan’s and my biggest
regret (although we also would also have wanted nullptr too.)
So on one level we do not actually have “managed C++” guys, when I say I am the PM for the compiler FE and libraries on the Visual C++ team that means both native and managed. To be direct, in VS2010 our focus was on the native developer. With VS2008 and
immediately prior releases (in both compiler work - such as “C++/CLI” - and libraries work - such as “STL/CLR” and the “Marshalling Library”) we felt we had devoted sufficient time recently to “managed C++” developers, potentially at the expanse of the native
code developer in some ways. So, as you can see in the current beta, there is not that much new for “managed C++” code developers in VS2010. However some of the new features work both ways, try using auto in managed code for example. But I also want to be
very clear and respond to your “abandoned” comment, this emphasis on native code development in VS2010 is really a re-balancing of efforts (native had been underdone for a while) and is in no way any indication of relinquishing anything.
> “As always, use the right tool for the job at hand.”
Or as my mother would tell me: “to a man with a hammer everything looks like a nail”.
I just want to reinforce the comment Charles made above – knowing all the tools of your trade is vital if you want to do any engineering discipline. If you want to build a managed-only application today, the right tools for that job would be C#/VB/F# (my
personal favorite of those would actually be F#– but that is purely my personal preferences coming through ) If you want to write a high performance native application, then you are probably going to use C/C++. If you want to mix native/managed then write
the native parts in C/C++, the managed parts in C#/VB/F# and do the interop shim in C++/CLI (and keep it is small as possible, keep it self contained, avoid chatting interfaces, … – alternatively you can use PInvoke or COM Interop but I am sure you understand
BTW: Stephan really is as enthusiastic, passionate and knowledgeable as he appears in the video – this is what makers coming to work here every day so enjoyable.
And as Charles said, we have a few more Channel 9 on the way (the pause was caused by waiting until VS2010 Beta 1 came out – it is so much more fun to describe these features when you can actually play with them too.)