Not Much to 'C' in C#

[Jonathan Gilligan]

The trend to move so much processor-intensive work from compile-time to runtime bothers me. One of the great advantages Blitz++ gets from generic programming is that it concentrates a huge amount of computational effort in compile-time optimization of generic functions (if you call a linear algebra function on a matrix, it uses information available at compile time about the matrix to strategically unroll loops, simplify indexing, and generally decompose the generic problem into efficient subproblems appropriate for the special case at hand). In principle, one could have a compiler that would spend a week optimizing its code and generating the most efficient runtime possible. This would be worthwhile effort for numerically intensive engineering code (I have many programs that will run for days at a time, occupying a significant fraction of processor power). If we go to the .NET model, the generic stuff ends up being optimized by the CLR JIT compiler, so instead of efficiently compiling once, on the developer's machine, we duplicate the effort of compiling to machine code on every user's machine. Moreover, information is lost in the translation from source to intermediate code, so optimization will be less efficient downstream than if you compile directly to machine code, specifying the exact target processor. Consider FFTW or the current generation of BLAS generators for extreme examples! These analyze your computer and generate optimized C or FORTRAN code specific to the configuration (available RAM, virtual memory, L1 and L2 caching, etc.) you are compiling for. These are completely orthogonal to the CLR approach and I am concerned that the emphasis on complete genericity in the intermediate language is eclipsing important considerations for the engineering and scientific markets.

[William E Kempf]

1. It's not the syntax that's a pain. You get used to the syntax really quickly. It's the semantics. Simple templated types are just that, simple. But when you get into more complex uses (specializations, both full and partial, etc.) then the semantic results become difficult to deal with. A lot of this is because C++ compilers aren't fully compliant yet, but there are also a lot of corner cases where the standard missed a difficult nuance. From a strategic standpoint I can not fault MS from not including generics in .NET or C# in release 1. 2. Ref-counting is simpler and faster, but is no different from GC in semantics. It's an implementation detail. The only real complaint is that the .NET infrastructure, and therefor C#, only allow objects to be created on the GC heap (well, actually, simple types can be placed on the stack, but you and I both know that these aren't the object types we're talking about). At least in MC++ you can somewhat handle this issue with stack based approaches that are easier to deal with than finally blocks. That said, you should read my article on the gc_ptr<> on this site where I talk about the pros and cons of GC. I won't fault C# for it's choice to be a full GC language since for many things this makes programming simpler and less error prone, but I'm not going to give up C++ RAII idioms for it either. 3. I'll agree with this, as will most C++ users, and probably all Eiffel users. However, this is a very heated religous issue with valid points on both sides. I can live with the lack in C#, though I'm more concerned with the lack in .NET. 4. C# leaves out very little functionality that's available to C++ users. The only two I can think of we've already discussed... MI and GC. C# does make it harder to use some of the more dangerous constructs, such as pointer manipulation, but as long as it still can be done I see nothing wrong with making harder to shoot yourself in the foot. If you want to talk pure opinion and not technical merits, I'll stick with C++, thank you very much. But trying to find technical faults in C# (at least for any of the reasons given so far) just shows either a religious bias or ignorance. Bill Kempf William E. Kempf

[William E Kempf]

C# is nothing like VB. It's more like Java# if you have to make such a comparison, but Java was based on C++, so... William E. Kempf

[Nemanja Trifunovic]

I have 7 years of C/C++, and 4 years of VB experience (also some Java), and I didn't find VB projects easier to debug at all. Now, I don't imply here that I'm a C++ guru (far from it :-O), but my point is that if you put in some discipline, C++ can be as safe as any programming language. Just don't hack with pointer arithmetics, use STL containers instead of "intristic" arrays, and do some planning before you start coding. Again, I don't think C# is unusable. It is a great replacement for VB. All that I want to say is that it could (and should) be even better without dropping generic programming and MI I vote pro drink X|

[Steven Hicks n 1]

C# was a language that was suppose to be a mixture of VB and VC++, but to me it looks like VB, because of the loss of control. C# is not a very powerful language, you can't even write a OS in it. Visit Ltpb.8m.com Surf the web faster than ever: http://www.404Browser.com

[William E Kempf]

The JIT doesn't have to be done with each invokation. It can be done at installation time. This approach is better than at compile time, since the JIT can do system optimizations not available to the compiler and can optimize the code for the specific CPU instruction set. Also, not all applications need this amount of optimization in any event. With fast CPUs a JIT done at first invocation is not likely to be noticable at run time even for speed critical applications. If the JIT occurred with every invocation you'd have more of an argument, but that's not what happens. William E. Kempf

[William E Kempf]

Conversely, the more complex the task the harder it is to do in these "safer" languages, offsetting the costs and often making the "less safe" langauges more cost effective. The right tool for the right job... William E. Kempf

[William E Kempf]

Name a single thing that represents your claim of "loss of control". You tried with the claim that you can't write an OS in C#, but C# has more hardware control than Java, and Java's being used to develop an OS today. Is C# the right choice for such an understaking? No. But you can still do it. The right tool for the right job... William E. Kempf

[Jason Gerard]

And why the hell would you want to write an OS? You have Windows, Mac OS, Linux, Solaris, HP-UX, FreeBSD, WinCE, PalmOS, etc, etc, etc. Leave the OS programming to OS programmers with C and Assembly. Leave the Application development to Application developers with C, C++, C#, Java, VB, etc. Jason Gerard, Master of Kung Foo

[Nemanja Trifunovic]

It is true that C# is nothing like VB. However, it's also true that it aimes to be an alternative to VB rather than to C++. Remember Microsoft slogan: "Ease of use of VB, with raw power of C++"? Of course, for big and complex projects, VB is hardly easier to use than C++, but that's another story. I vote pro drink X|

[Eric Gunnerson msft]

I'd like to discuss a few of these: 1. Lack of support for generic programming. We may agree or not that templates syntax is far from perfect, but generic programming is so powerful that there is no excuse for ommiting it from the very beginning. **** There was just no way to get generics into the current version. They will likely show up in a future version, though not necessarily the next version. Since you can use the "object" type as a "poor man's generics" in C# and get a similar effect, generics aren't as critical in C# as C++. You do lose a few things, however: 1) You have to write casts from object to the type that you want, though this occurs less than you'd think due to the use of foreach. 2) You get run-time type checking on these casts rather than compile-time type checking. 3) You box value types in collection classes. I don't find these to be tremendously important issues. #1 and #2 are easy to get used to, and #3 isn't usually a problem, and you can get around it with effort by writing a type-specific collection, though that's a pain. **** 2. Object lifetime control. I think that garbage collectors in general are very bad idea. For those who tend to forget to free objects from the memory, reference counting may be a better solution. Of course, this is just my oppinion. :-D *** I think most C++ programmers have this attitude towards GC; they hate any loss of control. I know I did when I first started working on C#. But over time, I've realized that for the code I write, I don't care that much about exactly how memory is used, and the GC saves me tons of time and gives me programs that are more likely to be correct. Reference counting can't detect cycles, among other things. There are still some issues dealing with non-memory resources that require more thought than we'd like, but overall it's a very easy model to work in. *** 3. Lack of multiple inheritance. Yes, I know the arguments from Java world, but multiple inheritance is still one of the important features of OO programming, and it should not be left out. *** I have mixed feelings about this; from a language perspective, I'm not sure the advantages of MI are worth the increase in complexity (of the language, compilers, debugging task, etc.) Interfaces cover some of the things you'd want to do with MI. That aside, the runtime team couldn't come up with a way to do MI without penalizing the SI case. Even if they could, it's tough to decide what MI means, since different languages have different d

[Eric Gunnerson msft]

C# is not a very powerful language, you can't even write a OS in it. *** You're correct, you can't write an OS in it. C# is designed to be a language that targets the .NET platform. If you don't like managed environments, then C# isn't for you. I understand your point about power; sometimes you really need it, but it's not the be-all and end-all of a computer languages. ***

[Steven Hicks n 1]

I wonder if WinXP was written in C#. ;) Visit Ltpb.8m.com Surf the web faster than ever: http://www.404Browser.com

[Pavlos Touboulidis]

"Of course, for big and complex projects, VB is hardly easier to use than C++, but that's another story. " I second that!!! Anything more than 1 week's work would be better if done in C++...

[Joaquin M Lopez Munoz]

>> Reference counting can't detect cycles, among other things. This is a very poor argument against ref counting. I have been programming in C/C++ for more than 6 years, and the only occasions I've ran into a cyclic structures have been handmading lists and the like, which now you can forget about thanks to STL containers. Be honest: Have you ever had a memory leak due to a pair of mutually referencing structs? The problem with GC is not the issue of memory management itself (with regard to this I see it as good an option as ref counting). The problem is that GC forces you to abandon RAII, which, in my opinion, is the single idiom that can prevent most resource leaks amongst the tools a programmer can count on in C++. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

[William E Kempf]

Yes, anyone who's written complex object frameworks has had to deal with cyclic references. It's a real issue, not an acedemic argument. Many GC frameworks have started out using reference counts for tracking object lifetimes and have very quickly run into cases where cyclic constructs caused severe memory leaks and so moved to more advanced algorithms. Regardless, as I pointed out earlier, reference counting *IS* a form of garbage collection. So if you ever use reference counting but have a problem with the concept of GC, you really need to think carefully about why. Now the real complaint you have is stated in this post: "The problem is that GC forces you to abandon RAII, which, in my opinion, is the single idiom that can prevent most resource leaks amongst the tools a programmer can count on in C++." However, this argument is not the same thing. It is quite possible for a language to support both heap based construction with lifetime managed by a GC engine and stack based construction with the lifetime managed by stack unwinding. In fact, MC++ provides this very capability. The real complaint you have with C# and other such GCed languages is that it doesn't support this concept and instead relies on finally blocks. GC is far superior for memory management, while RAII is superior for other resources that must be reclaimed in a deterministic manner. William E. Kempf

[Eric Gunnerson msft]

For an in-depth discussion of all the issues, take a look at: http://discuss.develop.com/archives/wa.exe?A2=ind0010A&L=DOTNET&P=R28572

[Joaquin M Lopez Munoz]

ref counting has an advantange over GC (provided there are no cycles): it is faster, or at least its load is distributed over time, in contrast with GC, that pops up from time to time and momentarily stops the VM. Maybe this is not an issue for many, but it is for say game programmers who want sprites going smooth all the time. Anyway, I'm no ref counting fanatic :) It is quite possible for a language to support both heap based construction with lifetime managed by a GC engine and stack based construction with the lifetime managed by stack unwinding. Yes it is, but in such a situation all the magic about GC vanishes. Suppose the keyword stack has been defined for allocating objects on the stack. Have a look at this pseudocode:

class A{...}
class B
{
A a;
}

void f()
{
stack A a;
g(a);
}

void g(A a)
{
B b=new B; // not stack based
b.a=a;

...
}

As soon as f goes out of scope, the object a will have an invalid reference to a deallocated object, and GC will crash. This is not to say that GC can not coexist with a stack based allocation scheme, but you have to be careful not to mix both worlds, and the purported aim of GC of not having to worry about memory management gets lost. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo

[William E Kempf]

First, reference counting *IS* a form of GC, and to distinguish between the two the way you're trying to is wrong. As I've stated, many GC systems are built entirely on ref-counting resulting in identical performance. Other GC systems mix ref-counting with more complex algorithms, such as mark and sweep, which insures items are collected immediately unless there's a cycle which reduces the overhead of the mark/sweep drastically. Further, you claim problems where the collector "stops the VM". This is obviously a mistake with mixing the GC concept up with the GC implementation in Java. First, there need not be a VM ;). More importantly, sophiticated collectors insure that a process is not stopped for any length of time with various techniques including running the collection algorithms in a seperate thread (this means the only time other threads may be blocked at all is when they attempt to allocate memory while the collection algorithm is running, but there's even ways to reduce the overhead of this blocking operation). In fact, actual benchmark studies show that sophisticated GC systems often outperform manual or ref-counted systems. Now, for your argument about mixing types... for languages that support this it's a non-issue. Either you can't get a "pointer" to a stack based object, or the type of such a pointer and the type of a pointer to a heap object are different, and so assignment of the differing types results in a compile time error. There are definate issues with hybrid stack/GC systems, but the problems are generally not as sever as you think and are worth the effort of programmer discipline to avoid them. The gc_ptr<> on this site illustrates a fairly safe way to bring GC to C++ and retain it's stack based allocations as well. Since this solution is solely a library solution it does require a little runtime checking in addition to the compile time checks, making it less appealing than a language based solution, but it works. William E. Kempf

[Joaquin M Lopez Munoz]

Please excuse the looseness of my terminology. To fix the vocabulary, and for the sake of this conversation, understand GC as "non RAII-compatible based garbage collector". What this all started from is the issue of C#'s GC not allowing for usage of RAII discipline. This is beyond all argument I think. Your ideas about adding static type checking support to the coexistence of stack based and GC managed objects (I guess in the line of C++'s constness) are very interesting and indeed I think they could lead to an efficient language supporting both garbage collection and RAII on a per object basis based on the programmer's choice. But this is not C#. C# offers you a take-it-or-leave-it non-deterministic GC with which it is impossible to apply RAII. And this is, IMHO, a very bad design decision that will drive novice programmers into more resource leaks than it prevents. The same goes for Java, for that matter. Joaquín M López Muñoz Telefónica, Investigación y Desarrollo