Thread: Managed VS Unmanaged code

I do not decide on managed or unmanaged solely on the fact that managed has garbage collection b/c that is easy enough to program in C/C++.

Citation needed. I would like to cite my own claims by saying the huge amount of vulnerabilities that exist in software like Linux, Apache, Windows or otherwise 'low-level' software written in C/C++ is precisely because memory is not managed and is hence 'unsafe', ripe for exploitation. Go look on phrack.org as an example - how many papers there since the publication of Aleph1 are based on exploitation and security vulnerabilities via the unauthorized control of memory even in the face of code scrutiny and tried-and-true usage?

You say this is 'easy', but I would argue it most certainly is not, and the number of defects and vulnerabilities in software these days written in languages like C/C++ would support that claim I think.

OTOH, there are reasonable ways to combat things like this in C++, where you have a bit more abstraction. Namely you can eliminate a large class of errors if you're using something like shared_ptrs and RAII pretty thoroughly (on that note, exceptions in C++ are mostly a terrible idea IMO unless you do use RAII thoroughly, precisely because exceptions in an unmanaged language like C++ can have some pitfalls when your code isn't designed with exception safety in mind, *especially* when resources like memory are involved, which RAII helps with a lot. Google for example, does not ever use exceptions, to make their C++ more clear, predictable and safe.)

Note that my point isn't that it's impossible to write working, correct software, 'memory safe' language or not. My point is that in a language like C/C++, there is a larger burden on you, the programmer, to make sure of these things, when with other languages, your compiler can just do the work for you.

I think headers have a purpose and I now understand why C and C++ have them

I would say this is not an argument for headers, this is an argument for a proper module system, something like Standard ML's (where a signature specifies the interface and a module implements it.) Headers/The Preprocessor in C/C++ are notoriously broken in a few ways. Have you ever looked at the headers for the standard C++ libraries, for example? They look like complete ass in every way. Do you know why? Because a simple #define on line 1 before any other #include directives could come through and literally trash everything in the following headers and break things in subtle ways. That's why every identifier in a C++ standard header is chocked with underscores and short, undescriptive variable names, making it look like ass. Essentially, you *cannot* have a standard C++ library with reasonable code in the headers, because the preprocessor can screw everything up.

More to the C# gripe - I don't know why you would have to constantly expand boxes. Are you telling me visual studio doesn't have a simple 'outline' feature to show you what's defined at the top level of a module? I'm almost certain it does, I can't verify right now however (on linux.)

and easier to maintain.

As someone who works on a small team with a ~40,000 loc C++ code base, I'm inclined to believe otherwise, but as you are mainly comparing to C#, I can't really say since I don't use it often or in very large magnitude.

I can get a pure C++ MFC app up and running just as fast as I can get a C# GUI app up and running. No difference for me at all b/c I'm very familiar with MFC and C#.

Really? This is your empirical argument that demonstrates there's no difference? Does it do more than display a simple window and maybe draw a PNG? I'm actually being dead serious here, because this claim is ludicrous unless you have actual statistics and measurements for a realistically sized code base, not some 40 line GUI app anybody can throw together with an API reference.