Why [did you choose] C# ?

Quote:

---

Originally Posted by _uj

Well, C++/CLI actually is a .NET language. If you like the Java and C# way of programming then C++/CLI is very similar, that is if you stick to the CLI extension and write pure C++/CLI. Pure C++/CLI is nothing like classic C++. Resorting to classic C++ is just an option you have. Pure C++/CLI let's you use the OO paradigm with the same ease as C# and Java.

---

Mmmhhhh.. It strikes me then, if you stick within C++/CLI then youre using (imho) an awkward and somewhat backward syntax/methodology to write a modern program, avoiding everything about what brought that syntax into being, purely for the sake of using the modern extensions..

I reckon that's a bit like falling out with a friend after he loaned you his lawn mower, but continuing to mow your lawn with his mower because you prefer it to yours..

In programming terms, using pure C++/CLI isnt really going to be any different to C#, just a bit more legwork and some "older fashioned" thinking, on the simplistic level

Quote:

---

So I was interested in why people chose C# over C++/CLI. Both are .NET languages and should be equally easy (or hard maybe) to master and use.

---

When I chose C#, C++/CLI didnt exist and I just didnt like MC++ as much; it looked a mess and the ambiguities bave me a headache. C# was much closer to java, and I rather liked java. I can write code without having to track and remember everything on a very micro scale.. This might arise from the rather typical male way of being forgetful and careless, I dont know!

When you say both are .NET though, I still dont quite agree with that. C# is all .NET with this unmanaged ability if you really work at linking it up. Compared to that C++/CLI's unmanaged code accessibility is quite a lot more present and uncovered.. I dont feel I'm explaining this particularly well, but suppose you were in front of a class of students, teaching them pure C++/CLI, and one asked "What's the difference between String*and String^?" - your answer would have to be "String* is the one we dont use, String^ is the one we do use" without launching into a huge and long explanation, and like the big red button that says "dont push this button", someone will want to push it.

I guess you could say I use C# because it does everything that I need, cleanly and simply, consistently and easily.. Additionally, when I go looking for examples of things, I happen upon C# more often than all other .NET syntaxes put together. As no fan of reinventing perfectly good wheels, I like having that vastness of pre-existing material as a resource

Quote:

---

Originally Posted by _uj

Well, C# wasn't conceived totally out of the blue.

---

No, but then I do feel that it was more a rip of J# 6.0, as the salvation of all the work that MS put into their proprietary form of java, that Sun sued them over..

Nothing ever is completely new, but I wouldnt say C# has any C or C++ as a heritage.. I actually think that all the .NET languages have java as an ancestor due to they way they work under the hood. Developing a new syntax is probably trivial once the VM-esque way of working is in place..

Quote:

---

It has quite strong C++ influences it seems to me.

---

It borrows a couple of keywords.. You couldnt really say that C++ has quite strong english influences, it just uses English words that embody the concept of what they achieve within the language..

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.

Quote:

---

if you didn't know that classic C++ actually is a true subset of C++/CLI it would be almost impossible to guess.

---

Last I knew, one of the biggest quibbles over C++/CLI vs C++ was that neither was a subset of the other.. But maybe I'm just out of date?

Quote:

---

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.

---

Is there an inherent inconsistency there, though? In a language where there are two ways of doing most things, each affecting/influencing the style of the other, but just different enough to make the explanation difficult, I'd rather teacha language that was single-track, consistent and simpler..

Quote:

---

Originally Posted by _uj

Yes but I already know Java and classic C++ extremely well.

---

Then you shouldnt struggle with either. Assuming you favour C++ and Java equally, with no intuition that makes you think "I like the way X feels, more than Y", then from a productivity point of view, you'll likely be more productive in C# than CLI (i'm going to drop calling it C++/CLI because we already are talking about avoiding the C++ part) because there is less messing around with the finer points. Of course, these may well be the finer points you seek, but the fact that you use and are happy with Java kinda makes me think you dont really miss the things that C++ does that Java doesnt..

Quote:

---

I also know the benefits/drawbacks of .NET in relation to portability

---

People typically use .NET because they want to develop a Windows app. If you dont want to develop a windows app (ignoring Mono), dont' use any .NET flavour.

Quote:

---

What I got so far in favour of C# is not that convincing.

---

It's not really a spitting contest between C# and CLI though, is it?

Quote:

---

Most people in favour of C# don't even seem to realize that C++/CLI is very far from classic C++. In fact C++/CLI seems quite ahead of C#.

---

Yep, that's viable; there will be a general ignorance towards CLI because it is newer than C#, has less of a following, is harder/more confusing/more leet haxor(probably an unfair stigmatisation from C++ associations) but saying that it's ahead of C# needs a little more qualification; what does the word "ahead" mean to you?

Quote:

---

Originally Posted by Zaccheus

Well, as you ask so nicely.
:D

---

Glad you're back. I'll give you an extra hug to compensate for the hardship you suffered :)

Quote:

---

For what it's worth, I have found C++/CLI to be unnecessarily complicated. I've been writing commercial ANSI C++ code for almost 8 years, so I've got no problem understanding or appreciating traditional C++.

What you call bickering is based on experimenting with C++/CLI for over a year and comparing it to the C# code I've written at work.

You are absolutely right in saying that C++/CLI is very similar to C# (they both fully utilise the benefits of .net), but the syntax for C# is simplified down to a very intuitive level.

For example, in C++/CLI you need to either use the dot notation or the arrow notation to access class members, depending on what kind of object you are dealing with. In C# it is always the dot notation.

The issue with the #includes only relates to classes which you have defined in the current project (i.e. which do not already exist as meta-data in another DLL).

One nice thing about C++/CLI is the full support for C++ templates (even in pure managed mode) as these are far more powerful and flexible than the .net generics, but these template classes always need to be #included because .net stores no meta-data for the uninstantiated templates.

Apart from the simplified syntax, C# also has a bunch of syntactical abstractions which make writing code easier. For example, have a look at the C# yield keyword in C# v2 and the new lambda expressions in the upcoming C# v3.

---

Okay so the major advantage of C# is a more polished syntax and more avant-garde language constructs.

Well I buy that. C++/CLI must stay out of the way of classic C++ in order not to interfere with its current nor with its anticipated future syntax. C# on the other hand was designed from the ground up with no such restrictions.

Featurewise C++/CLI is tied to the evolution of C++ whereas C# is free to add on new sexy features, like the lambda expressions you mentioned.

In summary I think it's only natural that C++/CLI has a slightly more complex syntax and is likely to be more conservative in adding new language features. Because it's in the C++ tradition to avoid language changes these are likely to be quite few and instead find their way into the language as additions to the C++ standard library. There's a new C++ standard coming up "around 2009" and I guess this will also be the next time C++/CLI changes.

Quote:

---

My understanding is that C++/CLI is really just meant to be a way of incorporating legacy C++ code in .net assemblies.

---

The main objective of C++/CLI is to,

"Enable C++ to be a first-class language for CLI programming" (Herb Sutter).

This is a far more ambitious goal than to be a mere upgrading path for old rusty C++ applications. With this objective C++/CLI takes on C# as the preferred language for the development of new applications. That's my interpretation.

Quote:

---

Originally Posted by TheCPUWizard

1) The fairly rare condition where savinging microseconds counts. This should (of course) only be considered after measuring that there is a performance bottleneck that has a significant impact at the application level, and there are no improvements to the algorithms/design that can achieve the performance

2) EXTENSIVE interfacing with existing or "built-in" (e.g. Kernel) native code. The overhead of marshalling across the boundaries can become significant.

Alas, both of these techniques imply that "unsafe" native code will be used heavily, which brings back all of the classic C++ issues. So none of the three conditions (yours + my 2) apply if you are going to force the use of only safe managed code.

---

To be honest I don't quite see where this speed advantage of C++/CLI over C# should come from?

C++/CLI is a managed language just like C# so both will suffer the same context switches when compiled with non-managed native code. Does C++/CLI offer an advantage in this area?

Or is it that C++/CLI can be more efficiently compiled to Intermediate Language code so it will be faster than C# for reason of more aggressive optimizations?

Or is it that the C++/CLI programmer can avoid using or better control the managed Garbage Collector for reference objects thus escaping some overhead which C# cannot?

I wonder how can C++/CLI be faster than C#?

Quote:

---

Enable C++ to be a first-class language for CLI programming" (Herb Sutter).

---

I think it's more like

-- Get those C++ guys who are very hard to shift to use .NET because we've come up with a .NET flavour of their favourite language --

Or

-- Get people to use .NET even though they have 2.5 million lines of C++ in their application --

Similarly for VB.NET.

Personally I wouldn't touch C++/CLI with a very long pole unless I had to. And I've had to.

I wrote an entire application in it to get around certain political issues and believe me it was hard work compared to C#.

Quote:

---

To be honest I don't quite see where this speed advantage of C++/CLI over C# should come from?

---

I believe its faster (I can't believe my much though) than C# because it can do things like inlining, whole program optimisations and other C++ niceties. Because each class doesn't proliferate throughout each assembly and the compiler knows which classes reference it (because of the #include-s) then I can believe this.

How much difference it makes is debatable though. I've never seen any specific stats on it or tried anything out myself.

As to the fact you can compile native code into managed code I don't think you should be doing this anyway. My C++/CLI code always has the managed and native parts seperate anyway (as it should in my opinion) so why not just have a native dll which interfaces to C# via p/invoke ?

There is one thing I don't like about .NET and that's the rather fuzzy boundary between dlls. It doesn't lend itself nicely to re-use (without a great deal of self control and concious decision about what you're writing/changing).

Mind you I don't like equally the linked static dlls you get in C++ for this very reason either (e.g. rather than having a .def file and explicit exports you use the __declspec stuff and even export classes from the dll). I far prefer COM in this case because of its well defined interfaces and well defined boundary between client and server (or dll and exe/dll if you prefer).

I can't personally see how C++/CLI is a "first class language" for .NET. Why anyone would write a form in C++/CLI is beyond me. The autogenerated code is horrendous !

I suppose it has its place, but it doesn't do anything you can't do in C# and C# is much, much, MUCH easier to deal with so I'll stick with C# for .NET development.

Darwen.

Generally I'm over in the Visual C++/Multithreading forums, but since I primarily code in C# at work, I figured I'd chime in with a question.

Because I haven't ever programmed in MC++ or C++/CLI, I'm wondering what these have to offer over coding in C# and PInvoking to a C++ dll (or COM object) when doing it in C# doesn't cut it?

Quote:

---

Originally Posted by cjard

Yep, that's viable; there will be a general ignorance towards CLI because it is newer than C#, has less of a following, is harder/more confusing/more leet haxor(probably an unfair stigmatisation from C++ associations) but saying that it's ahead of C# needs a little more qualification; what does the word "ahead" mean to you?

---

I claimed C++/CLI was "ahead" of C# to provoke a reaction. :) But I got the idea from my textbook (Gordon Hogenson) who writes,

"The designers of C++/CLI had the advantage of looking at what works and what doesn't in the C# language, and planning the design of C++/CLI accordingly"

He's more or less forced to boost C++/CLI of course and to be honest I haven't found that many advantages of C++/CLI over C# really.

But one is that C++/CLI provides better and more predictable object cleanup. Another is that C++/CLI offers more interoperability options wheras C# has P/Invoke only. I haven't been convinced though that C++/CLI is capable of faster context-switching than C#. In fact I haven't find any evidence that C++/CLI should be faster than C# in any respect. Then comes the question you raise, that of language polularity. There's no doubt that C# has the lead and probably will have for the foreseeable future.

So all in all, the

- polished syntax,
- sexy language features,
- sufficient interoperability with native code via P/Invoke,
- popularity

seem to make C# the better choise. But I haven't written C++/CLI off yet especially not if evidence of possible substantial performance gains over C# will surface. Are there any?

Quote:

---

Originally Posted by darwen

I wrote an entire application in it to get around certain political issues and believe me it was hard work compared to C#.

---

Could you please be more specific. I cannot quite get how it can be so much harder to write a program in C++/CLI (in safe mode) rather than writing the same program in C#?

Was it because of the unfamiliar C++/CLI syntax? Was if for the lack of essential language features available in C#? Or what was it?

Quote:

---

Originally Posted by _uj

The main objective of C++/CLI is to,

"Enable C++ to be a first-class language for CLI programming" (Herb Sutter).

This is a far more ambitious goal than to be a mere upgrading path for old rusty C++ applications. With this objective C++/CLI takes on C# as the preferred language for the development of new applications. That's my interpretation.

---

Stanley B. Lippman is an Architect with the Visual C++ team at Microsoft:

Quote:

---

C++/CLI represents an integration of the Kansas and Oz of native and managed programming. In this iteration, that has been done through a kind of separate but equal community of source-level and binary elements, including Mixed mode (source-level mix of native and CTS types, plus a binary mix of native and CIL object files), Pure mode (source-level mix of native and CTS types, all compiled to CIL object files), Native classes (can hold CTS types through a special wrapper class only), and CTS classes (can hold native types only as pointers).

Of course, the C++/CLI programmer can also choose to program in the CLI types alone, and in this way provide verifiable code that can be hosted, for example, as a SQL stored procedure in SQL Server™ 2005.

http://msdn.microsoft.com/msdnmag/is...5/02/PureC/#S7

---

Quote:

---

Originally Posted by _uj

In summary I think it's only natural that C++/CLI has a slightly more complex syntax and is likely to be more conservative in adding new language features. Because it's in the C++ tradition to avoid language changes these are likely to be quite few and instead find their way into the language as additions to the C++ standard library. There's a new C++ standard coming up "around 2009" and I guess this will also be the next time C++/CLI changes.

---

I wouldn't say traditional C++ has been conservative in adding new language features. There have been a few changes and many many additions since it was first introduced in the mid-1980s.

As far as I know, code written in the first version of C# will still compile just fine on the latest compilers.

Regarding the question of C++/CLI vs Managed C++, I think it is fair to call it a syntax change - in fact the Visual C++ 2005 compiler option for compiling code as Managed C++ is /clr:oldSyntax.

[quote]
But one is that C++/CLI provides better and more predictable object cleanup.
[quote]

Wrong, False, Utterly UNTRUE!

There are three phases to object cleanup:

1) Dispose() [optional]
2) Finalize() [automatic if implemented and not suppressed
3) Freeing Memory.

Items #2, and #3 are done by the Garbage collector, which is totally unaware of the thanguage the object is implemented in.

Item #1 Occurs only if the Dispose() method [which is implemented in C++/CLI using destructor semantics].

There are three ways that ispose typically gets invoked:

a) Explicit call to Dispose()
b) Exiting a "using" block in C#
c) Using stack semantics in C++/CLI

"b" & "c" both have identical performance, and are equally predicitable. "a" is actually a little more un-predicitable, since people often forget to structure things so that Dispose() always gets called in the event of exceptions.

Quote:

---

But I haven't written C++/CLI off yet especially not if evidence of possible substantial performance gains over C# will surface. Are there any?

---

The key word here is "substantial", and the general answer is a resounding NO.

Typical cases where there will be a measurabe performance difference is if you allow mixed mode [not pure CLI]. Consider a loop which has to call two unmanaged functions in some other existing peice of code. The loop will execute a million times.

If the loop is written in managed code (any language), then there will be 2,000,000 marshlling calls.

With a mixed mode C++/CLI implementation, you can code the loop as a peice of unmanaged code, and marshall just once and execute the entire loop in the unmanaged space.

Again: This point goes away if you are going to restrict your C++/CLI code to being pure..

Quote:

---

Originally Posted by Arjay

Generally I'm over in the Visual C++/Multithreading forums, but since I primarily code in C# at work, I figured I'd chime in with a question.

Because I haven't ever programmed in MC++ or C++/CLI, I'm wondering what these have to offer over coding in C# and PInvoking to a C++ dll (or COM object) when doing it in C# doesn't cut it?

---

My textbook (Hogenson) on C++/CLI contains suspiciously little about multithreading. I cannot say if this means there's less support than in C#. It may be that threading is mainly handled by CLI libraries (say System.Threading or so) which means it should be equally supported by both languages. Well at least there seems so be some support,

http://www.ddj.com/dept/cpp/184402018

Quote:

---

I cannot say if this means there's less support than in C#. It may be that threading is mainly handled by CLI libraries (say System.Threading or so) which means it should be equally supported by both languages. It seems at least there's a lock keyword in C++/CLI.

---

Multi-Threading (using managed threads which are not necessarily the same as system threads) is equally supported in all languages as you surmised.

C# also has the lock() statement.