Re: .NET vs non-.NET and garbage collection vs manual resource management

> I've heard that Visual Studio has an option to insert canary values
> on the stack to try to detect buffer overflows that could have
> overwritten the return address. I'm guessing that's not just .NET
> specific, but applies to traditional Visual C/C++ also... But
> really, a careful programmer shouldn't allow buffer overflows in the
> first place...

Agreed. Buffer overflows shouldn't happen at all.

> As to portability, you're a Linux and Wine user, if I recall
> correctly. Are you able to run .NET programs on Linux? Do you write
> .NET programs?

.NET programs can run on Linux thanks to the work of the open-source
Mono project (see <http://www.mono-project.com/Main_Page>). You
can also compile some C# programs using the "mcs" compiler provided by
the project. In recent years, the Mono interpreter can be used to run
ASP.NET on top of the Apache HTTP server in a non-Windows environment
when the proper Apache module is installed and configured properly.
Additionally, the binfmt-support package in Debian (I'm fairly certain
it exists with similar names in other Linux distributions) allows one
to run non-ELF binaries (executables) almost seamlessly. For example,
when I run "./foo.exe", the Wine interpreter is automatically invoked
as "wine ./foo.exe". Note that even though I run a 64-bit Debian
system, Wine still only works with Win32 applications. If I have a
.NET application rather than a Windows application
(e.g. "./foobar.exe"), the Mono interpreter is automatically invoked
("mono ./foobar.exe").

I don't write .NET programs, but I once had an interest in the C#
programming language. As a matter of fact, I still have an interest,
though the amount of interest has decreased significantly due to the
fact that I am first and foremost a C programmer. As such, it is my
belief that portable code is a programmer's responsibility. C++ is a
bit higher-level than C and allows for greater possibilities with less
code, but its I/O facilities are somewhat slower and considerably more
expensive in the resulting file size. That being said, I do believe
that the right tool should be used for the right job. If I need
something done quickly, I use a Python script. If I need something
portable, I do my best to use a C program. If a rapid application
development cycle is necessary, but the code should still be portable,
C++ is usually a good choice. With plain ol' C and C++, the programs
should just work because they're compiled to machine code (albeit with
calls to library routines such as those found in msvcrt.dll). If
managed C++ is used, however, the .NET runtime takes over.

Where does that leave .NET? I don't like having a large layer between
me and the OS unless it's actually useful. C and C++ provide just
enough of a barrier to allow me to write reasonably safe AND portable
code, and Python is great for quick, yet powerful, scripts. I will
say that I feel SOME knowledge of the system's assembly programming
language is useful even to an application programmer, more
specifically for debugging purposes than anything else. I actually
wonder if inline ASM blocks work when writing managed C++ code... I
would think it would be a violation of the safety of managed code...
Then again, this is Microsoft we're talking about; they probably
figured out how to emulate it or something.

> Java and .NET both have automatic garbage collection. Is this really
> more efficient?

Well, the efficiency depends upon the implementation of the garbage
collector. I know that Python's garbage collector uses "reference
counting". Once it sees there are no more references, the object is
deallocated. I'm not sure what .NET's garbage collector uses, but
generally a garbage collector is difficult to program and even more
difficult to use effectively in one's program (such a practice is
often discouraged).

> I guess automatic garbage collection means that you don't have to
> manually deallocate objects (e.g. "delete" in C++)? So good
> programming practice in Java or .NET would be bad programming
> practice in C++, C, or Assembly.

Yes. In Java, .NET, Python and any other language/runtime that makes
use of a garbage collector, messing with the garbage collector at all
is generally considered "bad programming practice." Many people will
tell you to carefully consider WHY you're doing it. However, there is
nothing wrong with the idea of manual resource management as long as
you know what you're doing. I look at Python and know that most of
what I do will be safe and portable to systems that have Python
installed. I look at C and C++ (and assembly) and know that I'm
responsible for making the code safe. There exist garbage collection
libraries for C++, but I personally have never had an interest in
using them. They might not get in the way like a full-blown JIT
compiler/runtime, but they also provide me no reasonable benefit. In
C++, if I need a pointer, I'll use std::auto_ptr, which allows for a
bit of automatic resource management when using pointers, mainly to
avoid the pitfalls of pointers, but that's all. In the end, I still
prefer managing everything myself. It creates more complex code, but
it assures me that I'm doing things exactly the way I want.

I guess we're both just a couple of control freaks when it comes to
programming. :P