Quote:
I believe that we can say it is easier to write slow (resource inefficient, in general) programs to write in languages like c# not solely because of the language itself but also because many c# programmers tend to think that the .NET (or whatever underlying platform) will handle too much for them whereas many c++ programmers know that they have the control, hence are responsible for certain things.
I would disagree, but I think you're getting warmer.
C++ doesn't by itself give you much in the way of control. Remember that C++ defines its own abstract machine -- it's own definition of what, exactly a byte is, and what memory is, and so on. Just like the CLR. The difference is that C++ leaves
huge swaths of that abstract machine undefined or implementation defined. This is one of the reason we tend to recommend against C++ for beginners, because this is a massive drawback of C++. However, in the right contexts, it's also a huge benefit. When you combine all the implementation-defined bits with an extremely fixed platform (console, embedded system) and some documentation on how that implementation-defined behavior works, you get a fair modicum of control -- in these very isolated scenarios, you get the 'low level' ideal that many people believe C++ gives you overall. But only in these scenarios.
These scenarios are useful for console developers -- working on the GBA, for example, involves loads of implementation defined behavior -- you cast specific addresses to pointers and write to them, which anywhere else is broken code. But the platform implementing C++ on the GBA assures you that these memory locations are mapped to suitable hardware memory registers.
A lot of the problems arise because surprisingly few people actually realize what's going on there, and where the boundaries all lie, and as such extrapolate from the basis that 'it works like this on my machine' to 'C++ says it works like this.' Some even take so far as 'computers work like this,' which is wrong. Those are often the guys who you see claiming C# and such are nonviable because they don't "have pointers" (disregarding C#'s unsafe-mode access to pointers, for a moment) while failing to realize that its referential semantics they're really thinking of. Et cetera.
Those guys (who in my observations are often C++-only or otherwise very heavily-C++-focused) do tend to write poorly performing C# code, or otherwise poorly performing code in other languages, because they have yet adapted to the idea that different contexts call for different actions to achieve optimal performance.
C# and the CLR don't magically make all your resource management needs go away, for example. The GC typically handles memory, and nothing else, leaving you to manage other resources (file handles being the common example) yourself. And lack of widespread deterministic scope-based cleanup makes this more difficult, sometimes, than in C++.
C# and the CLR are not a silver bullet. To write optimally performing C#, you need to work at it, you need to understand your domain. This is no different from in C++ or any other language. The reasons many people find C# to be more optimal in terms of development time tend to be due to it providing better, higher level features and more modern concepts (of which the GC is just a small part). Not because of memory management and other things which the programmer must 'control' and 'manage' when writing native code (although of course, not having to do that is a boon, since often native implementations end up looking very similar to many of the things GCs do, such as pooling).
Writing code from the hip where performance isn't a concern one way or another is about as easy in C# and C++, as long as you know both languages well and are only talking about the handling of those things like memory -- std::vector goes a long way. It's usually the higher level stuff that really makes C# shine in terms of development efficiency.
Quote:
Both of our opinions are based on our observations and experiments. I haven't seen you come with any hard data so far either, maybe I just missed. So what makes your experiences more valuable than mine? I hope you see where this issue boils down to? I know I haven't addressed all points in your post but I see no point in doing so as it will bloat this thread even more than it is now.
I think you're unfairly conflating things here. Drilian's challenge to you vis-a-vis hard facts was (or appears to have been) in direct response to your assertion that I quoted above in this post, and responded to. For that you have no factual basis (and in fact have several facts slightly off-base, as I noted).
[Edited by - jpetrie on March 4, 2009 6:19:07 PM]
