Why [did you choose] C# ?

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

One reason could be that you're comfortable with Java and find C# very similar.

Is C++/CLI used mostly by people with a strong C++ background or are there other reasons? C++/CLI isn't portable like standard C++ so it cannot be that. Is there something else?

Thank you.

This has been recently discussed in depth. Look for the thread "Is it time to learn C#" or something similar.....

Quote:

---

Originally Posted by TheCPUWizard

This has been recently discussed in depth. Look for the thread "Is it time to learn C#" or something similar.....

---

I can't find it.

Hi ,
if ur starting to build a new application , C# is the language to go. The syntax is natural , it build for the .NET platform , Java people can migrate ,
has got the ability to mix pointer semantics inside C# , platform integration are the some of the advantage u get from C#.

C++/CLI syntax is quirky as the addional syntatic and semantic constructs has been injected into a language which is dated for modern day application development. ( C++ language has got a place in writing device drivers , CAD applications , certain Games , Offline rendering etc. )




Praseed Pai

Quote:

---

Originally Posted by _uj

I can't find it.

---

Here it is

Quote:

---

Originally Posted by Cyanide

Here it is

---

Thank you.

You say:Why C# ? Isn't it better to ask WHY NOT C# ? :D :lol: :wave:
BTW It seems me pretty easy to learn.

Quote:

---

Originally Posted by JonnyPoet

You say:Why C# ? Isn't it better to ask WHY NOT [b]C#

---

It's a C# forum so I thought people may have made an active choise to use it and would be willing to share their decision process. I hope there are at least some people who are using C# for a better reason than why not.

Quote:

---

BTW It seems me pretty easy to learn

---

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?

Quote:

---

Originally Posted by _uj

It's a C# forum so I thought people may have made an active choise to use it and would be willing to share their decision process. I hope there are at least some people who are using C# for a better reason than why not.

---

I chose the .net languages (when you start with them, and get to know them, you start to fail to be able to see a difference between them.. VB.NET, C#, J# .. i read them interchangeably without even realising, just as a person fluent in english and french may flick between them in speech or reading without it even registering what language they are using..) because they were easy to pick up, made a lot of sense, I'm quite good with what's going on under the hood and I can get to the end of a working day and feel fantastically productive. Additionally, the job mandated the move from VB6 to VB.NET, but I use C# mainly (ssshh.. dont tell them ;) ) because it's nicer, cleaner and more powerful. It suits the way I think.

Quote:

---

You mean that C# and C++/CLI are completely equivalent, the only difference being that C# is easier to learn.

---

C# and C++ arent equivalent. They can produce the same goals, by similar means, but they have very different target markets..

Quote:

---

Then why does C++/CLI exist at all? To satisfy masochist programmers who enjoy a daily spanking?

---

Yep. It suits a purpose, of course; it's quite raw and hence quick. If youre brilliant, you can pull some nasty, dirty tricks to make your apps fly. Most people are not brilliant. Most people dont need apps that fly. They need apps that work and are resistant to shoddy programming practice. From what I've seen from you in Java forum, i'm sure youre brilliant enough to climb the steep learning curve of C++; just ask yourself whether you really need to get down in the mud with the rest of the low level stuff, if you want to be able to allocate every byte of memory yourself and have total control over everything. Having micro-fine control of everything -> It's quite a management task, I can tell you. Compare the command line to windows; the GUI is very limited in power, but you can get things done at great speed, and in a friendly manner. Each has a use..

Looking at C++ code, it seems clear to me that the people who write it, have a very strange way of thinking; its rather alien to me, and doesnt make as much sense as .net or java. Thats not to say it's right, or wrong, just different.. If youre looking for a career move, then studying what the job ads are asking for and what you reckon you;d be happier doing would be the most prudent move.

As someone who is making the jump from C++ to C#, I can tell you that the syntax is very similiar. Declaring variables, functions, etc in C# is exactly the same as in C++ which I LOVE. There are some very fundamental differences, which I am getting used to, but all in all I'm pretty happy with the langauge.

Bottom line is if you want to take advantage of the .Net framework, C# is a good way to go, especially if you're a C++ guy. Besides, I dont wish Visual Basic on anyone except three year olds *flame retardant hat on*.

Good luck.

Quote:

---

There are some very fundamental differences

---

And that is an understatement. There is a MAJOR mindset/paradigm shift when mojing to managed code (any language) from native C++ [I know I have said this over and over, but....].

Many of the techniques used in C++ (e.g. Caching temporary objects as members for later use) are simply BAD architecture/design/programming in the managed world.

If you to not understand at a fairly deep level exactly how the garbage collector works, you are likely to write bad code. If you do not understand the difference between AppDomains and Eecution Contexts, you are likely to write bad code. If you do not understand the differences between generational heaps and the large object heap, you are likely to write bad code.

The syntax of a given language is really quite secondary when it comes to writing good managed code.

David

ps: Believe it or not, write now I am working with a client using COBOL.Net! :eek:

Quote:

---

Originally Posted by cjard

Looking at C++ code, it seems clear to me that the people who write it, have a very strange way of thinking; its rather alien to me, and doesnt make as much sense as .net or java. Thats not to say it's right, or wrong, just different..

---

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.

Quote:

---

Originally Posted by TheCPUWizard

And that is an understatement. There is a MAJOR mindset/paradigm shift when mojing to managed code (any language) from native C++ [I know I have said this over and over, but....].

---

Sure but there are small differences between pure C++/CLI, C# and Java. To program well in any of them requires you to already have made the "mindset shift" over to managed code.

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.

Quote:

---

why people chose C# over (pure) C++/CLI

---

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)

Quote:

---

Originally Posted by _uj

Then why does C++/CLI exist at all?

---

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.

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.

Quote:

---

Originally Posted by JonnyPoet

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

---

Come on now. The "Why C#" was just the topic of my thread. I then immediately qualified it to be "C# in relation to C++/CLI".

Quote:

---

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++.

---

Yes but I already know Java and classic C++ extremely well. I also know the benefits/drawbacks of .NET in relation to portability ala Java. What I'm interested in is people's views regarding C# versus C++/CLI. This is the decision I'm facing.

What I got so far in favour of C# is not that convincing. A few bickerings about C++/CLI being to general is about all. 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#.

In the context of web development and ASP.NET, C++/CLI is unusable (except for web services I believe). A lot of people migrate to C# from VB or Java because its easy to grok. Also, C++/CLI looks plain ugly. I think it exists solely as an "upgrade path" for C++ developers who want to write .NET apps but don't want/need to bother with C#.

Quote:

---

Originally Posted by sleezyb

In the context of web development and ASP.NET, C++/CLI is unusable (except for web services I believe). A lot of people migrate to C# from VB or Java because its easy to grok. Also, C++/CLI looks plain ugly. I think it exists solely as an "upgrade path" for C++ developers who want to write .NET apps but don't want/need to bother with C#.

---

Well if you think so, wouldn't it be appropriate to show how C# is better than C++/CLI then?

__uj,

It seems like you keep looking for something that C# can do, that C++/CLI cant. You will not find it, as that is not the reason for the existance of the language.

The driving force of C# is to provide a simpler to use development environment. The less that the programmer needs to deal with at the syntactical level, the easier it is to develop and the lower the risk of bugs. By lowering the bar, it is possible (and even somewhat likely) that less senior developers [read as those who will work for less money] can develop robust programs. This results in a lower TCO [total cost of ownership] in the business world. That is a very serious advantage (assuming it really proves itself over the long haul.

Even just the time it takes to create seperate header and implementation files in C++ can have a measurable (not necessarily overly significant) difference in the time it takes to create code. When you add up the "little" things it matters at the business level.

Quote:

---

Originally Posted by _uj

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.

---

I have nothing against the C++/CLI syntax for implementing IDispose by writing a function which looks like a standard C++ destructor.

I am saying that you never-the-less still need to write that function. C++/CLI does not remove the necessity to implement IDispose. Whether you call it ~MyClass (C++/CLI) or Dispose (c#) is of little consequence. The point is: You still have to write that function.

Quote:

---

Originally Posted by _uj

Because of its general nature C++/CLI is more likely to be immune to fads. And I like that.

---

Except that Microsoft completely changed the syntax for .net compatible C++ code between VS2003 and VS2005.

Quote:

---

Originally Posted by _uj

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

---

Bickering?
:confused:

I'm just giving a few examples why I ended up choosing C# over C++/CLI for .net development.

Quote:

---

Except that Microsoft completely changed the syntax for .net compatible C++ code between VS2003 and VS2005.

---

To be correct. Microsoft actually published two different implementations for writing managed applications. VS-2003 used "Managed C++". This implementation violated many of the "approved" methods of extending C++ (including the nameing convention of keeping C++ at the begining of the name). With VS-2005, they published a NEW LANGUAGE EXTENSION call "C++/CLI".

Quote:

---

Originally Posted by TheCPUWizard

__uj,

It seems like you keep looking for something that C# can do, that C++/CLI cant. You will not find it, as that is not the reason for the existance of the language.

The driving force of C# is to provide a simpler to use development environment.

---

I'm not looking for anything in particular but people usually have a motivation for their choises. I know C# has been around longer than C++/CLI so that might be a strong contributing factor to use it. C# is so strongly associated with .NET that C++/CLI isn't even considered an alternative.

Or, it can be as you say that C# really is the simpler language and thus easy to master and less error-prone. But to be honest, I'm not convinced. I've started to read up on C++/CLI and I can't see how it can be considered more complex than Java (which should be fairly equal to C#). Isn't this just a myth related to C++ being conceived as a hard language. But pure C++/CLI is nothing like classic C++. To me it seems as easy as C# or Java.

Code:

---

Or, it can be as you say that C# really is the simpler language and thus easier to master and less error-prone. But to be honest, I'm not convinced. I've started to read up on C++/CLI now and I can't see how it can be considered more complex than Java (which should be fairly equal to C#). Isn't this just a myth related to C++ being conceived as a hard language. But pure C++/CLI is nothing like classic C++. To me it seems as easy as C# or Java.

---

Just by alloswing "unsafe" code, C++/CLI is inherently and significantly more difficult and error prone than C#.

Even if you force "safe" code only, it is still more complex and therefore more error prone. Have you ever in C++ or C++/CLI mistyped a declaration between the header and cpp file [If you say NO, then I dont believe you :D ]. You get a compile error, have to go back and edit one (or both) of the source files and re-compile. In C#, this can not happen.

Granted that is a trivial example, but it does kill the argument the "C++/CLI" is "just as easy" as C#...

Quote:

---

Originally Posted by TheCPUWizard

Have you ever in C++ or C++/CLI mistyped a declaration between the header and cpp file

---

Yes, for example:

Code:

---

class A
{
public:
    void f(int min, int max);
};


void A::f(int max, int min)
{
/// ....
}

---

:ehh:

Quote:

---

Originally Posted by _uj

C# is so strongly associated with .NET that C++/CLI isn't even considered an alternative.

---

Personally, I did consider C++/CLI and even wrote a number of small programs with it.

Quote:

---

Originally Posted by _uj

Or, it can be as you say that C# really is the simpler language and thus easy to master and less error-prone.

---

That is the conclusion I have come to.

Quote:

---

Originally Posted by Zaccheus

I have nothing against the C++/CLI syntax for implementing IDispose by writing a function which looks like a standard C++ destructor.

I am saying that you never-the-less still need to write that function. C++/CLI does not remove the necessity to implement IDispose. Whether you call it ~MyClass (C++/CLI) or Dispose (c#) is of little consequence. The point is: You still have to write that function.

---

If that's your point than I don't understand why you're replying to me?

Read what I said in #16 again. I question what TheCPUWizard wrote namely that implementing this interface was an example of how "handy" C# is. In my view it's often better to have a general feature which takes care of a situation. (although in essence the same code has to be provided in the end)

Quote:

---

Except that Microsoft completely changed the syntax for .net compatible C++ code between VS2003 and VS2005.

---

No they didn't. They introduced a whole new language in its own right called C++/CLI. They did this because Managed C++ turned out a failure.

It's not C++ anymore (which Managed C++ was). It's a totally new language sporting classic C++ as a subset. The CLI part draws heavily on experiences with C#.

Quote:

---

Originally Posted by _uj

I've started to read up on C++/CLI and I can't see how it can be considered more complex than Java (which should be fairly equal to C#). Isn't this just a myth related to C++ being conceived as a hard language. But pure C++/CLI is nothing like classic C++. To me it seems as easy as C# or Java.

---

One example is the need to #include class declarations. In ANSI C++ the use of header files makes sense, because all information about a class is discarded after compilation. So you use a class in another source file, you have to include the class declaration in that source file.
But in Java and in .net, all the information about a class is maintained after compilation. Therefore you do not need to #include class declarations in C# or in Java. However, because C++/CLI is based on C++, you still need to split your class into declaration and implementation files, and you still need to decide which header files to include in which source files.

Quote:

---

Originally Posted by _uj

(although in essence the same code has to be provided in the end)

---

That's all I was trying to say.

Quote:

---

Originally Posted by _uj

They introduced a whole new language in its own right called C++/CLI.

---

Isn't that just another way of saying "They changed the syntax"?

Quote:

---

Originally Posted by TheCPUWizard

Just by alloswing "unsafe" code, C++/CLI is inherently and significantly more difficult and error prone than C#.

Even if you force "safe" code only, it is still more complex and therefore more error prone. Have you ever in C++ or C++/CLI mistyped a declaration between the header and cpp file [If you say NO, then I dont believe you :D ]. You get a compile error, have to go back and edit one (or both) of the source files and re-compile. In C#, this can not happen.

Granted that is a trivial example, but it does kill the argument the "C++/CLI" is "just as easy" as C#...

---

What's this fuss about header files. Isn't it just to include namespaces like say

using namespace System;

Have you written any programs in C# ?
Have you written any programs in C++/CLI ?

Perhaps people's preference for C# will make more sense if you write a simple, but meaningful, program in both languages.



Regarding the #includes:

In C#, the compiler automatically knows about the classes which you have declared in other source files in the same project. In C++/CLI you need to #include the class declarations in each source file where you want to use it, otherwise the compiler will not know about the other class - unless the class is declared in another DLL.

Quote:

---

What's this fuss about header files. Isn't it just to include namespaces like say

using namespace System;

---

Actually C++ header files should NEVER have a using statement in them.

This forces the inclusion of the namespace into the scope of every client which wishes to use the header. In headers, the namespace should always be explicit:

Code:

---

void f(std::string s, std::vector<int> vec);

---

Of couse you do need to "#include" the appropriate headers in your header...

Again addidional details that make C++/CLI "harder" and more error prone. To summarize:

#1) Any time there is a "using" statement in a header... IT IS A DESIGN ERROR
#2) Any time a header file does not internally reference all required headers and requiures a user (.cpp file) to pre-include another header... IT IS A DESIGN ERROR
#3) Any time you do not have appropriate guards to gracefully and properly handle multiple includes of the same header file within a .cpp... IT IS A DESIGN ERROR.

None of these three things can happen in C#.

Quote:

---

Originally Posted by Zaccheus

Have you written any programs in C# ?
Have you written any programs in C++/CLI ?

---

Read my posts with some attention and it will become clear. If you cannot be bothered the answer is no to both your questions. Not a single line and it shouldn't matter because I'm not interested in syntax detail at this point, only principal features.

Quote:

---

In C#, the compiler automatically knows about the classes which you have declared in other source files in the same project. In C++/CLI you need to #include the class declarations in each source file where you want to use it, otherwise the compiler will not know about the other class - unless the class is declared in another DLL

---

Is this a feature of the languages or the development systems?

Code:

---

Is this a feature of the languages or the development systems?

---

It is inherent in the design of both of the languages.

Quote:

---

Originally Posted by Zaccheus

Isn't that just another way of saying "They changed the syntax"?

---

In the bickering sense you're right. I guess you may have noticed that Managed C++ and C++/CLI have different syntax. But the introduction of a new computer language is seldom considered a mere change of syntax in relation to some existing one. So in that sense you're wrong.

Quote:

---

Originally Posted by Zaccheus

Perhaps people's preference for C# will make more sense if you write a simple, but meaningful, program in both languages.

---

That's not a very good strategy. The virtues of any language only show after extensive use in real situations by language experts. As a newbie it's better to ask the experts directly. I have enougth experience in both Java and classic C++ to know what they're talking about.

I've asked the same question at the C++/CLI forum,

http://www.codeguru.com/forum/showthread.php?t=421029