C# in comparison to C++: what is your strongest pain?

Question

Here are my points to start with.

1. I cannot guarantee that my structs are initialized with my default constructor.
2. I cannot define a simple " == " operator overload on an interface.
3. I cannot return const objects, which destroys encapsulation.
4. I cannot define a simple generic Sum function because of operator + not working on generic type T.

Edit: Imagine you need to create a small type or maybe type hierarchy - double with accuracy and with different roundings. You would then understand why I need all these..

1. I cannot decide where to place my instances: ref- or value-placement
2. I don't have multiple inheritance which is the least pain (when you are not in one of those MarshalByRef situations...)!

Answer 1

None of those things I see as issues at all, never really been a problem if you adopt the C# paradigm of programming, ie, don't program like a C++ programmer in C#.

The biggest pain is lack of real time / native code capability in C#

Answer 2

I hate how I'm hugely more productive in C# than I ever was in C++, because it proves I'm not a real programmer ;)

And I hate how C# doesn't have nearly enough string classes.

Answer 3

You make some good points. A lot of what is "missing" was left out to keep the language simpler and avoid common pitfalls. Here are some thoughts on your items.

1. Either: a) use a class or b) build a struct that doesn't need to be initialized using properties with lazy instantiation where needed. Search other SO questions to see why this was a good idea. As a quick example: private myStruct[100000000000000]; How long would that take to initialize?
2. All objects inherit an Equals() method, but if you want to require a class to implement Equals, you might have your interface inherit from IEquatable<T>. You won't be using the == operator, but you can get the same behavior.
3. Build immutable objects (i.e. objects with read-only properties). I agree this is limiting, because it's not always possible to make the objects within your objects immutable.
4. Agreed. This would be very nice. Before releasing generics, MS at least added "where T : new()" so we could create a new instance of T. It would be nice if they added more of these. At least you can add methods to replace all these operators, which will make your code more friendly to other CLR languages anyway.
5. Can you explain this one a little more?
6. Interfaces are widely regarded as the answer to multiple inheritance. Granted, a standard mix-in framework would be nice as well. It doesn't sound like you miss multiple inheritance that much.

Answer 4

The biggest thing for me is lack of RAII. Not having a guarantee that the destructor will be called in a timely manner to release resources is a big drawback for me. The using statement and the IDisposable interface is a poor substitute for a compile-time guarantee that no one is forgetting to release the resources.

Answer 5

Well, here goes some downvote-bait...

C# isn't so bad, but what I really miss is the preprocessor.

I know the "powers that be" decided I didn't need it, and I'm sorry, but that really frosts.

Added:

Example of what I need to do sometimes. I have a DSL, which is the base language with some special statements layered on top, such as some special IF-type statements:

 #define IF(test){bool _test; if (IfUtil(Protect(_test=(test))){
#define ELIF(test) } if (IfUtil(Protect(!_test && (_test=(test))))){
#define ELSE } if (IfUtil(!_test)) {
#define ENDIF }}

So I can write

//
IF(some_test)
  ....
ELIF(another_test)
  ....
....
 ELSE
  ....
 ENDIF

And the boilerplate will be expanded for me.

Answer 6

I shall quote an email I wrote to my colleagues recently titled, "My 'short' fuse with C#":

This is unbelievable! In C#, the following is a compile error:

short a = 5;
short b = 3;
short c = a - b;

Stating there is no implicit conversion from 'int' to 'short'. It seems that there is no minus operator defined for shorts, so a and b get implicitly cast to an int to do the arithmetic, resulting in an integer return value! The way to get it compiling (probably still with the conversions to/from ints) is like this:

short c = (short)(a - b);

What a dog of a language.

As an experienced developer across a number of platforms and languages (predominantly C/C++ though), I am constantly suprised by the holes C#. Not being able to do arithmatic with shorts is just crazy.

All these holes just lowers my confidence in C# and .NET and makes it feel like a toy.

Oh, and if I had mixins or macros (preferably mixins), then I might not feel like I need multiple inheritance.

Cheers,

Dan

Answer 7

Garbage Disposal

Answer 8

I also miss basic stability and simplicity. To me it's just not a benefit that new features keep being added to something I already can use quite effectively, thank you. A prime example is "var".

Answer 9

I spent two years programming with C# and then took the first opportunity to jump back to C++. Some of the things I dislike about C#:

• Lack of free functions and perverse workarounds like static classes.
• Too much casting. There are too many .NET framework methods that return object and than you need to cast down. Before generics it was even worse.
• Memory footprint. It is bloody impossible to keep memory under control with C#
• Verbosity. Somewhat addressed by type inference, although the choice of the keyword is unfortunate.

In general, C# is targeted to in-house business programming and it is probably good for that purpose, but that is not what I want to do. For all interesting stuff: system programming, graphics, games, real-time and embedded systems, etc, C++ is a much better choice.

Answer 10

C# lack of const-correctness is a shortfall. I really wish C# had #include

Answer 11

1. It is way too easy to inadvertedly alias objects and then be surprised by how a change to a property somewhere can cause all sorts of bad effect.
2. Pointers to members. Way too many libraries (e.g. Workflow Foundation) use strings and reflection to compensate for the lack of them.

Answer 12

In C# 2.0 I became disappointed in closures feature - way too much boilerplate and weird syntax limitations.

The Adobe Flex ActionScript3 language is a statically typed language (has compile-time type checking) and very much resembles Java or C#. Unlike Java, but like C#, it also has properties and events (plus very nice data-binding features built on that foundation).

Yet due to its JavaScript heritage, AS3 retains a closure feature. This works very well in AS3 coding. Coding in AS3 has been more pleasing that either Java or C# 2.0. AS3 seems simpler, cleaner, and yet sufficiently powerful.

Does lambda expressions address this closures clunkiness in C# 3.0?

(And BTW, previous comments have suggested that C# is only good for internal business software. Yet lots of public Internet facing Adobe Flex software is out in the wild. Plenty more public facing Flex software is in development. I say this to point out that a managed code runtime can indeed be used for public facing software if the runtime is suitably designed., as Flash/Flex runtime has been for the web.)

Answer 13

C# drawbacks compared to C++:

• There is no support for const-correctness. I find this sad, because 80% of all parameters passed to functions are constant (in functional programming this is even 100%). It is very nice if you can add compiler-checked documentation to your code stating which parameters will not be tampered with.
• There is no support for non-null pointers (cf. C++'s "references"). This is a shame, because 95% of all parameters passed to functions are non-null pointers. In C++, you can add compiler-checked documentation indicating which pointers are ensured to point to something. In C# you have to wait until runtime to get this feedback.

However, C# also has some advantages over C++:

• There is much better support for working with components (assemblies), which is a big advantage. In C++ this is a real pain, for third party libraries as well as in-house components.
• C# has a large standard library, which is a big plus. C++ especially lacks a good standard user interface library.
• The namespace system is better. C++ has the problem that "using namespace" doesn't work in header files, which more or less ruins the feature. I don't understand why they don't fix this in C++ (I know, I know: the eternal backward compatibility issue which paralyzes progress).
• Extension methods are a great feature, which I really mis in C++.
• Compiling code at runtime. This provides for an out-of-the-box plugin system.
• The reflection feature sometimes proves useful.

All in all, I still prefer C++, as I think the two features I listed are major ones. C++ was there first, so a new programming language should be much better to justify its existence.

Answer 14

A good list of problems with C# can be found here.