How similar are C# and C++?

[MilleniumFalcon]

I've spent a majority of my time programming in C, and now I'm learning C#. C# is my first Object Oriented language, and I'm loving how I can beautifully structure my code into nice maintainable pieces with different Object Oriented features. Being a C programmer at heart, I've been interested in C++, since it would give me the best of both worlds. I was wondering though, how much knowledge could I transfer from C and C# to C++? Will I need to start all over again on a beginner's tutorial to catch everything I need to learn, or can I go quicker with some transition guide instead.

Note: I'm not completely done with learning C# yet, so it might be a while before I start really learning C++.

[grumpy]

C# has some syntactic similarities to both C and C++, but the philosophy is very different. That means, while some things carry across, if you slavishly use good C techniques or good C++ techniques in C#, you will become a bad C# developer. Similarly, if you slavishly use good C# techniques in C++, you will be a (really bad) C++ developer. That's because, trivial concerns of syntax aside, they are all really very different languages.

C and C++ have a lot more in common with C# than they do with each other - after all, the folks who specified early versions of C++ deliberately maintained backward compatibility with C (as per the the 1989 C standard). Even then, while it was possible to learn C++ as an "extended C", it quickly became apparent that learning C++ that way did not make for particularly good C++ developers. And BOTH languages have changed since then so, now, one very very bad way to learn C++ is as a "C with a few more features" - there are two many techniques that are good C which need to be unlearned to be an effective C++ developer. Similarly, it is also considered that a C++ developer learning C will be become a really bad C developer if they learn C as "C++ with a few things removed".

The same sort of argument is applicable to C#. If you have learned C# by analogy from C, odds are you are over-estimating C# abilities. If you then learn C++ by analogy with your understanding of C++, you will be a shocking C++ developer.


You are better off acknowledging that there are similarities between the languages, but avoid the trap of thinking (which is really a trap of lazy thinking, in the hope of skipping things) you can use your learning of one language to learn another. Learn the languages separately, without trying to reason about C# as a C programmer would, or about C++ as a C or C# developer would. If you try to learn one by analogy with the other, you will develop bad habits in each language. When you go through learning material of the new language, you will find similarities to what you have learned before. That will help you learn faster. The catch is, there will also be differences so, if you skim over such sections, you will miss the differences. And the differences are what is critical to becoming (say) a proficient C# developer rather than becoming a "C programmer doing something that is sort-of C#" who later transitions to being a "C programmer who uses some C# techniques in C code and makes a mess of it" and thereby becomes a person who has bad habits in both languages.


Also, be careful of the OO kool-aid. Contrary to what its zealots will teach you, it is not the solution or panacea to all problems with organising your code - it makes some things easier and not others. OO is valuable for what it offers. The curse, however, is developers who believe what it offers has to be applied to everything. It is problem solving that is important, and using techniques that are applicable to the problem. Not treating every problem like it is a nail because you have a popular hammer in your hand.

[Cat]

In contrast to what grumpy says, while I agree all languages have their idiosyncracies, as someone who is a "programming polyglot" I have to say that knowledge of prior languages really is a big help in acquiring new languages.

I think that's especially true at the highest levels of design - the details of how I would implement individual methods, the underlying data storage, etc. would vary a lot if I were to write the same code across different languages, but the high-level code structure would be driven primarily by the type of programming (e.g. am I doing OOP, procedural programming, etc.) - so I probably would structure the code much the same if I were doing OOP in C++ or Java or C#.

[grumpy]

In contrast to what grumpy says, while I agree all languages have their idiosyncracies, as someone who is a "programming polyglot" I have to say that knowledge of prior languages really is a big help in acquiring new languages.

You missed my point: I'm not saying that knowledge of prior languages doesn't have value in learning new languages. I'm saying that over-relying on it - and learning a new language by thinking about in in terms of a previous language - is a backward step. Given that a lot of beginners DO rely on it, and a lot of people get encouraged to rely on it, it needs to be said. Over-reliance i the reason for a phenomenon where a lot of people claim to be C++ developers, but in reality are C developers who use a few C++ features in what is otherwise C code. It's the reason that Pascal programmers have used preprocessor tricks to make C or C++ look something like Pascal.

I also happen to be a "programming polyglot". It might not be obvious here, because most of the languages I'm experienced in aren't even subjects in forums here, and the main emphasis of questions here is C or C++. However, I don't even think in terms of "type of programming" (OOP vs procedural versus functional or whatever). I think in terms of solving problems, and selecting architectures (organisation), tools, and techniques or idioms for the job at hand. Effective OO development in C++ (or <shudder> C) uses techniques that I wouldn't use in C# or Java. But the same goes in reverse.

Incidentally, I just picked up a typo in my previous post. where I said "C and C++ have a lot more in common with C# than they do with each other" I should have said "C and C++ have a lot more in common with each other than they do with C#". That error came about because I initially wrote the sentence one way, but changed the order of things, and muffed it.

[Mario F.]

and I'm loving how I can beautifully structure my code into nice maintainable pieces with different Object Oriented features.

Actually that's one of my criticisms of C#: C# Partial Classes and Implementation Separation

[phantomotap]

Actually that's one of my criticisms of C#

O_o

Your criticism seems exactly opposite the view a lot of people have regarding the desire of separating declaration and implementation.

If you use or have used languages that also don't have such separation, how do you cope with your criticism for such other languages?

I prefer using tools to generate the information you reference as your primary reason for your criticism, yet I despise the requirement of specifically labeling different bits beyond the core of the language--as "doxygen" commenting for example--so I don't see a reasonable "trade off" in either direction.

Soma

[c99tutorial]

I wonder if the differences encountered will not be so much language differences but actually library differences. In C++ you probably will end up using the C++ standard library and in C# you will probably end up using the .NET framework and/or Mono. The differences in the way these libraries are used and operate might be more substantial than the language differences.

[Mario F.]

Your criticism seems exactly opposite the view a lot of people have regarding the desire of separating declaration and implementation.

Not sure I understand what you mean. C# doesn't allow for separation of declaration and implementation. And that's my main beef with C# regarding code structure. You mean to say people criticize languages which offer a (optional) way to separate declaration from implementation?

If you use or have used languages that also don't have such separation, how do you cope with your criticism for such other languages?

Like Java for instance. I would always feel there was a need for such separation in OOP languages and would include such language in my criticism. I feel this type of separation is very useful in increasingly complex objects.

I prefer using tools to generate the information

Editors for Java and C# editors (to name two OOP languages) already ship with this assumption. And that is how we do it. No harm there. It's not that I'm saying, or ever said, we don't have a solution to this problem. But both languages are meant to be used in any type of hardware/OS and with all forms of restrictions. Without a language implemented solution to the separation of declaration and implementation we are dependent on those tools, which may or may not exist in a certain operating system or hardware environment.

[grumpy]

I wonder if the differences encountered will not be so much language differences but actually library differences. In C++ you probably will end up using the C++ standard library and in C# you will probably end up using the .NET framework and/or Mono. The differences in the way these libraries are used and operate might be more substantial than the language differences.

I would suggest both the language differences and the library differences are substantial.

The impact of the language differences will hit anyone. For a person who deliberately uses facilities of the library wherever appropriate, the differences in libraries will hit home. A person who avoids using the library and insists on rolling their own code will be affected more by differences in the core languages. Which makes the question of whether library differences are more or less substantial than language differences rather moot.

[phantomotap]

You mean to say people criticize languages which offer a (optional) way to separate declaration from implementation?

O_o

Yes. That is what I was saying.

An example would be C++ member declarations. (That is, the implementation of a class method--when the implementation appears within the definition of a class--generally do not need to have seen declarations for class members/methods.) People are happy to complain about code that takes advantage of the "quirk". People are happy to complain about code that doesn't take advantage of the "quirk". (I get a lot of flack for separating implementation and declaration for template classes. I basically ignore the comments, but my point is only that I do get a lot of flack.) People are happy to complain that the option drives inconsistency which can be jarring enough to increase the time necessary to navigate a piece of code.

Editors for Java and C# editors already ship with this assumption.

You have not commented on a solution to the situation I reference. I despise the requirement of manually separating declaration and implementation. I despise having to annotate a particular implementation so that tools may produce a matching declaration. I am not alone; I suspect somewhat that you are with me.

Now look at your own example code: your suggestion depends on "markup" for the class implementation, and you'd place the burden of maintenance on the programmer. With or without the markup, do you have any ideas to resolve maintaining two components without placing a burden on maintaining both components or producing a declaration to conform to a requirement without tools which still work to separate the two components?

You reference limited environments; what method have you to offer which solves your problems and mine?

I can't think of any method which manages a reasonable balance; with no reasonable balance to offer, you are necessarily trading some problems for others. Having spent the last several months with Javascript, I am desperate to get back to C++ for though among many this exact reason, yet I can't imagine any Javascript version being employed by anyone other than me.

Soma

[Mario F.]

I would suggest both the language differences and the library differences are substantial.

More so because, while the C++ Standard Library is meant as a standards library, which should be mirrored on all implementations of the programming language, in C# there's no notion of a standard library beyond the limited scope of the Common Type System. Every implementation of C# is free to create their own library.

[grumpy]

An example would be C++ member declarations. (That is, the implementation of a class method--when the implementation appears within the definition of a class--generally do not need to have seen declarations for class members/methods.)

That depends on what you mean by "see". The compiler needs to interpret the complete class definition, regardless, before it can correctly handle definitions of member functions. That is true whether the functions are inline (within the class definition), inline after the class definition, or not inline.

It is true that member functions can refer to data members that are declared further into the class definition (in the sense of subsequent lines of code) than they are.

[Mario F.]

Yes. That is what I was saying.

I was honestly not aware this was a problem. I mean, I've seen the odd criticism of C++ headers. Just never realized it came from a substantial part of the community.

I can't think of any method which manages a reasonable balance; with no reasonable balance to offer, you are necessarily trading some problems for others.

Well, for sure... it is true that I am putting the burden on the developer. But this is true of any code structuring language feature. I too can't think of any other way of doing it, short of introducing a new programming language. It just happens that on my view -- especially because you aren't forced to adopt this feature (much like in C++ you aren't forced to separate declaration from implementation) -- separation of declaration and implementation can be useful enough that, when needed, it will trump the code maintenance requirements. C# Partial classes are a good example of this. They increase the code maintenance requirements of the language, but their advantages (when partial classes are needed) outweigh this disadvantage. I don't think of partial classes implementation in C# as a problem. I just know they could hardly ever have been implemented without their own set of syntax, semantics and the unfortunate necessary evil of dependency.

[phantomotap]

The compiler needs to interpret the complete class definition, regardless, before it can correctly handle definitions of member functions.

O_o

Yes. You have correctly understood the point of the comment.

Soma

[phantomotap]

I was honestly not aware this was a problem.

O_o

You should see the response my code--separated--received on submission of a patch to an expression templates mechanism.

Well, I am sure you may imagine; this was a "GNU" project.

much like in C++ you aren't forced to separate declaration from implementation

You are indeed in limited circumstances; perhaps I should have offered the example in that direction.

Consider the case of mutually recursive, "freestanding" functions: at least one declaration must have been separated from the implementation.

C# Partial classes are a good example of this. They increase the code maintenance requirements of the language, but their advantages (when partial classes are needed) outweigh this disadvantage.

[Edit]I haven't used C# in a long time; the requirement on "third-party" tools or manually coded solution may have changed.[/Edit]

If you could natively combine partial classes--within the language--without a "monolithic"--your definition from the post--class I would agree.

As is, I don't see how the separation buys anything worth the cost, but I don't have that much experience with the language so...

*shrug*

Anyway, I agree with that value of separation, but I've seen slight differences between documentation, declaration, and implementation cause too many problems to consider the separation valuable without tools to manage the separation, and the solution can't really be found "within the language". The issue is more of a "quality of implementation" issue.

Soma