quote:Original post by nyugfu
>> Lack of garbage collection which makes certain idioms problematic, and causes developers to have to waste time dealing with memory allocation and ownership issues, rather than focusing on the actual problem they are trying to solve.
This is true, but I would argue that C# can still require you to focus on a whole new set of issues as well, as davepermen pointed out. The inability to explicitly control the allocation and deallocation of an object requires you to track down every single reference if you want to avoid internal memory leaks, which I imagine can be quite challenging in a large scale system.
However, this problem isn't new , it's the same problem you have in C++. In C++, you still need to track every single reference if you are to ensure that you don't forget to deallocate something that is later not referenced.
Also, in C# it is possible in principle to profile the program to detect references that aren't being used. The profiler could then warn you that a particular reference may be 'leaky'.
quote:
I don't think this creates any more confusion than in C#. The behavior is simply reversed. C#, by default, passes things by reference while C++ passes objects by value.
Well, that's not true. C# classes are references, parameters are actually passed by value, just as in C++.
quote:
A programmer should still think about whether he/she wishes to deep copy or shallow copy an object. In fact, if he/she doesn't know well enough to decide, I would think that it would be less confusing and potentially less problematic to pass and return copies around.
Which is a little easier in C# than in C++.
quote:
It's worth mentioning that a problem with many C++ programs is that many programmers do a lot of unnecessary copying.
In my experience, a primary reason for this is that it's a lot easier to copy data than to deal with the memory management issues of references into heap allocated objects.
quote:
However, I would still bet that many of them outperform similar C# programs. It's when a programmer shallow copies an object and hopes to be working with a copy when the bigger, more difficult problems arise.
If the programmer "hopes to be working with a copy", then he should know that he needs to deep copy the object when making a copy. Programmer error, not language error.
quote:
Additionally, I think some of your points are really IDE-specific (though you're probably perfectly aware of it). While C++ IDEs at the present may have synchronization issues between headers and implementations (I avoid most fancy IDEs in C++ so I wouldn't know), that's still a feature of the IDEs and not C++. It doesn't mean it would be impossible for an IDE to be created that would keep the things in sync.
Indeed. Synchronisation between headers and implementations isn't a feature of C++ at all. That is a Bad Thing. A language which automatically generated headers from its implementation would be a better idea.
quote:
The form designer is not part of the C# language.
Hmm. So flaws in C# are not solved by an IDE, whilst flaws in C++ are solved by an IDE?
quote:
Also, you mentioned C++'s longer build times. This is certainly a disadvantage, but it's due to the fact that C++'s power comes mainly from its static, compile-time capabilities. This is why applications using templates as a means of generic design can greatly outperform C# applications which use object boxing. Templates slow down compile time but have no effect on the application's performance at runtime.
But the fact of C++'s build times remains. And of course, C# 2.0 supports generics and still manages to compile quickly.
quote:
On a similar note, most of the commonly used C++ libraries are statically compiled and linked, including the STL (and for good reason). This contributes to a great portion of the build time. If you wanted, you could certainly take the functionality from these libraries and compile your own dynamic linked libraries and avoid the lengthy build times that way, as C# does. However, you would have to sacrifice the use of templates and use other techniques for generic programming which would inevitably lead to a reduction in efficiency. If C# had to statically compile and link the full .NET framework, the build times would be horrific and the executables would be huge.
Yes. It would also be stupid. Handily, the CIL itself is highly generic.
For example, the function T add (T a, T b) { a + b} can be compiled to precisely two functions -- one that adds primitive values of any type, and one that invokes operator+ on Object values. When the CIL is recompiled into native code at load (or preload) time, the generic function can be compiled into whatever distinct functions are needed.
Edit: The reason I mention this is that I figure this makes precompiled generics libraries more useful in C# than in C++. Although that does mean people who would have distributed a C++ template library in source form might instead distribute a C# generics library in binary form. I don't like that.
In principle, it could be compiled to only one function, but the standard doesn't allow that.
quote:
From my standpoint, I can always make a C++ program compile faster at the cost of runtime performance or by writing a bunch of DLLs. There are also a lot of techniques such as pimpls to reduce compile-time dependencies. However, in C#, I have no choice but to do a lot of things dynamically which I could have done statically to get a more efficient program.
In terms of importance, however, I usually find that greater efficiency at runtime generally outweights the speed at which a program can be compiled and linked. A lot of people say that computers these days have so much memory and so much speed that programmers need not worry about such things, but there are still a number of applications where performance is crucial. Server-side applications, for instance, often need optimal performance to serve as many people as possible with a given set of hardware.
However, because C# is, in effect, compiled at load-time, it can be statically linked right then. The loader can also perform full-program optimisation, which is usually better than the single-module optimisation performed by traditional compilers.
If you don't like all this load-time delay (I know I wouldn't), you can prerecompile your program. Also, I assume that, eventually, the system will cache the recompiled programs so they don't have to be recompiled every time you run them.
quote:
However, just taking out features from a language because a lot of people misuse them is not always the best solution, in my opinion. This is the big problem I see in C# and Java's approach to 'better design'. It might make the general population design better, but it restricts the more advanced people from doing a lot of good stuff.
I agree absolutely. The removal of some cool-but-misused features, together with the fact that it is controlled by an organisation with an ulterior motive, are what I have against C#.
[edited by - Mayrel on February 19, 2004 9:27:06 PM]
Now that I think about it though, there are things like stream objects which tend to give unwanted behavior when deep copied (that's often a common source of confusion for novices to C++), so toss that point aside.
