Why [did you choose] C# ?

Quote:

---

Originally Posted by TheCPUWizard

One reason is that it is harder to do bad things with C#..

Also there is some handy syntactic "sugar" (e.g. The "using" statement).

Finally there are some good tools that are not available for C++/CLI (e.g. Runtime Code Generation)

---

Aren't the things you mention rather examples of the contrary, namely examples of unsafe C# constructs which are quite likely to go wrong?

For example to use C# "using" you got to implement IDispose correctly whereas in C++ you just give the objects involved value sematics so they get held on the stack and thus get automatically disposed when the method ends.

And Runtime Code Generation sounds very unsafe to me.

I'm not convinced that C# shields you better from programmer mistakes than does pure C++/CLI. Isn't that just a myth?

Quote:

---

Originally Posted by reko_t

I won't repeat the things that have been said already, but C++/CLI can be used to write eg. Mixed DLLs. That is, a managed application that mixes managed and unmanaged code. This is particularly useful for writing wrappers for unmanaged libraries for .NET. You can't write Mixed DLLs in C#, although you can always use P/Invoke for certain things.

---

That's rather an argument to prefer C++/CLI over C#, not the other way around, isn't it? :)

Quote:

---

Originally Posted by _uj

That's rather an argument to prefer C++/CLI over C#, not the other way around, isn't it? :)

---

Indeed it is, but I was just answering his question about why C++/CLI should exist at all. :)

I'd definitely go for C# over C++/CLI for writing your common managed applications, since C# is designed as a .NET language in the first place, so the integration is much more seamless and consistent. C++/CLI is still useful to know, even if you use C#, in case you need to write mixed code, although not nearly all of us ever need to do that. Especially for someone who doesn't come from C++ enviroment, C# seems like much more logical choice than C++/CLI.

Quote:

---

Originally Posted by _uj

For example to use C# "using" you got to implement IDispose correctly whereas in C++ you just give the objects involved value sematics so they get held on the stack and thus get automatically disposed when the method ends.

---

The MSIL code generated by the C# using directive is the same as the code generated by C++/CLI stack semantics. The only difference is the syntax.

Quote:

---

Originally Posted by Zaccheus

The MSIL code generated by the C# using directive is the same as the code generated by C++/CLI stack semantics. The only difference is the syntax.

---

Isn't that compiler dependent? In any case the code generated doesn't matter because programming takes place at the syntax level, doesn't it? What you call the only difference is in fact all that matters.

Quote:

---

Originally Posted by reko_t

I'd definitely go for C# over C++/CLI for writing your common managed applications, since C# is designed as a .NET language in the first place, so the integration is much more seamless and consistent.

---

Well, C# wasn't conceived totally out of the blue. It has quite strong C++ influences it seems to me. The difference is that in C++/CLI the C++ heritage is a part of the language. You got classic C++ and in addition the CLI extension.

But in my view the CLI extension part of C++/CLI is a wonder of seamlessness and consistency. In fact if you didn't know that classic C++ actually is a true subset of C++/CLI it would be almost impossible to guess.

Quote:

---

C++/CLI is still useful to know, even if you use C#, in case you need to write mixed code, although not nearly all of us ever need to do that. Especially for someone who doesn't come from C++ enviroment, C# seems like much more logical choice than C++/CLI.

---

Well, I'm not entirely convinced that a person with no C++ background would have a harder time learning pure C++/CLI than learning C#. You don't have to tell people how you would accomplish in classic C++ what now is much easier thanks to the CLI extension of C++/CLI.

Quote:

---

Originally Posted by _uj

Isn't that compiler dependent? In any case the code generated doesn't matter because programming takes place at the syntax level, doesn't it? What you call the only difference is in fact all that matters.

---

Ok, you said in C# you need to implement IDispose and C++/CLI you don't. That is not correct.

Quote:

---

Originally Posted by Zaccheus

Ok, you said in C# you need to implement IDispose and C++/CLI you don't. That is not correct.

---

I was lead to believe that yes. What is correct then?

Quote:

---

Originally Posted by _uj

What do you consider to be the main reason for picking C# over C++/CLI?

---

Here are some of my thoughts:
http://www.codeguru.com/forum/showthread.php?t=412701

The final straw for me was the limitations of C++/CLI stack semantics, discussed in this thread:
http://www.codeguru.com/forum/showthread.php?t=412448

Quote:

---

Originally Posted by _uj

What is correct?

---

In C++/CLI you still need to implement IDispose, by writing a member function which looks like a traditional C++ destructor.

I will agree that in C++/CLI, some of the housekeeping to do with disposing is handled for you by the compiler, but that is a small benefit compared to the huge benefits of C#.

One thing I like about C# is that there is no need for #includes. The more I used C++/CLI, the more I got annoyed with the fact that I had to include header files for classes defined inside my own project even though I didn't need them for classes defined in other DLLs.

I used to be a big fan of #includes, typedefs, #defines, etc, but I've found that C#/.net makes these unnecessary.

It is also worth mentioning that C# is actually less Microsoft specific than C++/CLI, in the sense that there are many non-MS compilers for C# (including those used for the Mono and GNU .net implementations), but few (if any) non-MS compilers for C++/CLI.

Quote:

---

Originally Posted by _uj

You mean that C# and C++/CLI are completely equivalent, the only difference being that C# is easier to learn. Then why does C++/CLI exist at all? To satisfy masochist programmers who enjoy a daily spanking?

---

No.. thats not the point I have meant.C++ is in my sight really needed to do things like drivers and a lot of other things but IMHO it is similar then in VB6.0 times. Getting a useful product in a short time, which e.g has had lots of forms was quicker in the design then to do it in C++ This begins with the designer of C++ where you had to draw each window, couldn't copy from other programs and so on. So the hours needed to do simple programs was much quicker in VB then C++ But creating programs like compilers, drivers or if you wanted to do some parts of code in MASM my choice woud be C++, no question. Now bring this example to C# in comparison with C++/CLI

Generally my opinion is: Every language has advantages in different sectors of programming, so you could not basically answer 'why C#'

C# for basic programmers is easy to learn and to change from VB to it, with much more possibilities to code then before,(especially in OOP, or e.g. threads ) but the same speed of programms development progress, I would dear to say faster then in VB.6.0

So I would suggest: If you are starting to develop a program you have to choos which language you are using. And then I would not ask why should I use C# but I would say OK, maybe I'll use C#. And requesting yourself regarding that program and its needs: Why not C' ? Are ther any points you can answer which would maybe lead you into problems using C' ? Which can easier/ quicker be done in C++ ? And only if this question leads to C++ then I would decide to do it in C++.

Thats was what I wanted to say :wave:

It seems to me that the real question is why people would use Managed C++, especially given that things like smart pointers already exist. I think that a lot of companies use C++ because they can write portable code that runs on many platforms and because they can compile it down to native code. That's certainly what my current job involves, but it's by no means unique. At my last job, we used C++ for stuff that needed to be shipped outside the company, and C# for web servers and tools for inside the company.

Quote:

---

Originally Posted by Zaccheus

Here are some of my thoughts:
http://www.codeguru.com/forum/showthread.php?t=412701

The final straw for me was the limitations of C++/CLI stack semantics, discussed in this thread:
http://www.codeguru.com/forum/showthread.php?t=412448

---

Well, I'm not fit enought at this point to determine whether you're bickerings are motivated. :)

Quote:

---

Originally Posted by Zaccheus

In C++/CLI you still need to implement IDispose, by writing a member function which looks like a traditional C++ destructor.

---

Well I don't have to implement IDispose in C++/CLI right, but I have to abide with the rules of a value class in C++/CLI, namely that it needs a destructor.

If I recall it right, in your previous post, the existance of a destructor was what you held against C++/CLI. I don't think I agree. Sometimes it's better to have a general feature than lots of special cases.

Both Java and C# seems to be afflicted with this disease of a never ending introduction of special features. Because of its general nature C++/CLI is more likely to be immune to fads. And I like that.