What's in stdafx.h since you included all headers actually used by the program directly in the file?

It doesn't do the same thing as the C# version or what androidi specified, as you use operator>> which stops extraction when it encounters a space; it doesn't read the whole line. Also the C++ version doesn't write a newline, and the C# version does.

Explicitly initialization an std:: string with an empty string literal is pointless.

I recently worked on an off-beat pet project where the idea is to convert a .Net app to something that can run natively on an ARM microcontroller (mainly to work around the fact that the .Net Micro Framework runs 3 to 4 orders of magnitude slower on a microcontroller than equivalent native code).

My initial approach was to create C++ code from the IL, and then use a traditional ARM C++ compiler to compile the code to an ARM executable. Initially I was just using VS to compile the C++ code to a native x86 executable for testing purposes, and it went reasonably well.

Once I actually started looking into the available C++ compilers for ARM microcontrollers, I realized it was a bad idea. The "decent" IDE's are all ridiculously expensive. For instance, Keil quoted me $2,695 for their basic, crippled version of their IDE that only allows 256K code to be generated, plus $4,895 for the dev kit. And the free or cheap IDEs were difficult to set up and ultimately it didn't seem like it was worth all the effort.

OK I know all of this sounds off-topic - hear me out...

My next approach was to create an ARM assembler/linker/emulator that allows me to compile the IL code directly to native ARM code. I'm quite far along with this project, and it is going well. Parts of the emulator consists of auto-generated C# code.

OK, so how is this related to this topic? Well, now that I've had a chance to write code that auto-generates both C++ code and C# code, I can say that C++ is a royal pain. It is so much easier to generate C# code where you don't need to worry about header files, forward declarators, worry about #ifdef guards, declaring static members multiple times (I mean - it's all there! Why can't the compiler figure it out - yes I know, it's a single-pass vs multi-pass thing), etc. Overall the C# syntax is just cleaner. All this unneeded complexity distracts from the real problem you are trying to solve.

In addition, the C++ compiler is way more finicky and often gives you compiler error messages that are completely unrelated to what the real error is. Well that last point might be more VS related than C++ related, but I believe it is because of C++'s nature that even the compiler is sometimes clueless as to what is really the problem. And then there is that whole debugging C++ code vs C# code thing. There is quite an advantage to the debugger being able to use reflection on your application...

I'm not 100% sure how writing code generation algorithms relate to actually writing the code yourself, but for me at least it has shown that C++ is pretty archaic compared to modern languages.

Bottom line, if I can help it at all, I'd like to stay away from C++ if I could. The problems we need to solve in code are getting exponentially more complex, and the last thing I need is to have to deal with an additional layer of complexity which modern languages have done away with.

EDIT: A few years ago I attended a talk by Bjarne Stroustrup in Berkeley CA about the future of C++. He is very passionate about C++ and I commend him for the great work he does. One thing that came through during his talk is that he is frustrated by the slow progress that C++ is making and the difficulty in advancing it. He made comparisons to C# and said something along the lines of "C++ doesn't have a sugar daddy that can push new development as fast" (yes, I believe he actually used the term "sugar daddy").

I think the problem you are encountering here is that C is not really for user-mode applications. Sure you can use it, but C really comes into its own when you start saying things like "We've got this new processor..." or "let's build an OS" or even "I've only got 70KB of memory on this thing, so we can't use .NET", or "let's build the new[] operator without using malloc".

If you're dealing with users in C, you're probably doing it wrong. If you're dealing with raw memory, data and kernel drivers in C++ or C# you're probably doing it wrong.

As it was brought up that my C hello world has little to do with C++, I'll go with some novice questions on that.

(Safe might be defined here as a way of writing code which avoids the bugs commonly associated with C or just "low risk of human error due to language design" as I don't know how C++ "safety" compares to C#)

Where does the safe C++ end and the C or unsafe concepts begin (as both can be in .cpp) - How can I tell which header has only C++ things in it (ignoring OS calls)? Are there things I can't do without use of C, eg. lack of libraries written this "safe/pure C++" that accomplish everything I could possibly want (in user land)?

Is there a C++ book/resource/authority that claims that by following their teaching you won't be making C-style mistakes or even that you get managed-level safety with C++ performance?

@BitFlipper:I agree with you BitFlipper. I programmed in C/C++ for many years. The problem is that to move the language forward you go through a huge commitee. Also, you cannot undo what is already done in the language. I never liked macros and when you make heavy use of them you almost cannot tell what the code is doing until you step through it. Alot of code can begin to look like assembly if you dont document it. You should see how they do a pointer to a ref type in the new Metro C++. Gets real ugly. I like to look at code that informs you of what it does just by looking at it. I switch to C# back in 2001 and found it a pleasure to work with. I dont miss the header files, the macros, and the buffer overruns. C# had a clean slate and cherry picked the better features from Java and C/C++.

I think it is time for a new C/C++ that is syntaxed like C# but produces native code.

Where does the safe C++ end and the C or unsafe concepts begin (as both can be in .cpp) - How can I tell which header has only C++ things in it (ignoring OS calls)? Are there things I can't do without use of C, eg. lack of libraries written this "safe/pure C++" that accomplish everything I could possibly want (in user land)?

Is there a C++ book/resource/authority that claims that by following their teaching you won't be making C-style mistakes or even that you get managed-level safety with C++ performance?

1) "Safe C++" is C++ without ever using a pointer or the "new" keyword. It's possible, but it's hard (and it's not necessarily safe)

2) C++ headers don't have a ".h" in the name. In C you #include <string.h> and in C++ you #include <string>.

3) You can do anything in C++ that you can do in C because C++ is (almost) a superset of C.

4) There are no C++ books/resources or authorities which guarantee that the code you write will be free of bugs, but then there aren't any for ASP, PHP, C# or Java either (and there are more published exploitable bugs in PHP and ASP than C/C++ even though protecting C/C++ is actually much harder).

What's in stdafx.h since you included all headers actually used by the program directly in the file?

It doesn't do the same thing as the C# version or what androidi specified, as you use operator>> which stops extraction when it encounters a space; it doesn't read the whole line. Also the C++ version doesn't write a newline, and the C# version does.

Explicitly initialization an std:: string with an empty string literal is pointless.

Didn't want to find the setting to disable precompiled headers, but since you insisted...

Where does the safe C++ end and the C or unsafe concepts begin (as both can be in .cpp) - How can I tell which header has only C++ things in it (ignoring OS calls)? Are there things I can't do without use of C, eg. lack of libraries written this "safe/pure C++" that accomplish everything I could possibly want (in user land)?

It's mainly about avoiding raw pointers and manual memory management. It means that pointer lifetime is managed by smart pointers like std::shared_ptr or std::unique_ptr so you won't ever write delete (and write new only to initialize a unique_ptr; initialize shared_ptr using std::make_shared). This makes your code exception-safe (resources get cleaned up regardless of what code path is taken).

Seriously, watch Herb Sutter's video, it explains all this much better than I could in a short forum post, and touches on some other important points too.

This idea of using scoped variables for automatic resource management doesn't just apply to smart pointers. For example, the Boost.Thread library (and as of C++11, the standard library <thread> header, available in VC11) uses this with mutex locks that ensure they get released when the lock_guard variable goes out of scope, just like the using statement in C# (but without needing a language extension).

And for the second part of your question: sometimes you have to interact with libraries that aren't that friendly. Unfortunately, Win32 itself is written for C, not C++, so unless you use a wrapper library you may run into situations where manual resource management is unavoidable. But when you do, you can follow the pattern yourself: write a class to encapsulate the resource and clean up in its destructor. In Win32 code I've written I've used a ScopedHandle template class that was specialized for various HANDLE types and their specific deletion functions so neatly handle those.

And std::shared_ptr and std::unique_ptr can use a custom deletion function, so it can easily be adapted for memory you got from a Win32 function that needs to be deleted using e.g. LocalFree rather than delete.

Interesting, I'm sure the opposite was said during the keynotes, but I'll take that as a more authorative resource. Still the majority of the really neat stuff like charms and contracts will presumably require appcontainers so I'm not sure there will be quite the same benefit (although .NET developers will probably be glad not to have to PInvoke quite as much).

I went to a post BUILD event last night and the same discussion was had there, too. It seems to still be confusing even with the evidence on both sides.

That said, if WinRT is as awesome as it seems, it will almost have to end up being callable from everywhere...

I went to a post BUILD event last night and the same discussion was had there, too. It seems to still be confusing even with the evidence on both sides.

That said, if WinRT is as awesome as it seems, it will almost have to end up being callable from everywhere...

I was disappointed to find out that Microsoft didn't do enough abstraction to allow more of the WinRT classes/methods to be usable from standard .NET applications. I understand that it wouldn't make sense to allow something like FileOpenPicker.PickSingleFileAsync() to be callable from ASP.NET, but there's no reason you shouldn't be allowed to call it from a WPF application. The framework should detect what kind of application is calling it, and then present the appropriate dialog (i.e. standard windows File Open dialog or the Metro-version). As it stands now, calling FileOpenPicker.PickSingleFileAsync() from a WPF application does nothing, as far as I can tell.

I suspect, and there have been various MS comments to suggest it might happen, that there will eventually be a WinRT target for desktop (non-Metro) applications. That pretty much has to happen or WinRT will be largely a wasted effort. I think MS isn't saying anything about it now because it hasn't been worked on at all yet (all resources have gone into the Metro support). WinRT will get beefed up to be a more complete framework for both desktop and Metro targets. At least I hope so. The disappointing thing is that MS won't describe what is planned. They are trying to force developer attention to Metro apps while ignoring the elephant in the room.

My company is just beginning to move partially away from XP and onto Vista (yes, I said Vista, not Win7). It will be another 10 years or more before something other than traditional desktop apps are even an option. MS's current direction to continue building native GUIs in MFC or pure win32 just isn't going to cut it.

All I know is, C++ code shared on the web looks like alien language. Much harder to utilize the community. When I look at C# sample, it just feels easy. It may also be my fault unable to translate alien language, but, I am only human.

For 99% of the typical software LOB, Web, Services etc .NET is plenty fast. Only in systems programming, embedded or number crunching do you need to drop down to C/C++. I would always develop in the most productive langague then use perf analysis to find bottle necks. You could then factor out the code to a native dll.

C is also the least common denominator in that pretty much every language out there can call into it without any major problem. That makes it ideal for libraries that need to be used by a lot of different applications that may not all be written in the same language.

It's also one of the most portable languages out there as well, there are C code bases that can be compiled and used on every platform out there big, small, and rarely used. Pretty much every processor family has a C compiler available.