Why [did you choose] C# ?

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

Quote:

---

Originally Posted by TheCPUWizard

Code:

---

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

---

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

---

Just to make sure. Are they necessary in C++/CLI if you use the CLI part only? The reason I'm asking is that in my C++/CLI textbook there are hardly no include files at all.

Quote:

---

The reason I'm asking is that in my C++/CLI textbook there are hardly no include files at all.

---

The majority of "textbook" programs are simple single module programs. This is radically different from a "real" program that may contain hundreds of .cpp (and corrosponding ".h") files.

The project I am working on right now [in C#] contains over 2500 different classes. Many of these classes are implemented as partial classes, since portions of them are autogenerated by designers. The total number of files is just under the 8,000 mark.

You will not find this type of complexity in a textbook. :D

Quote:

---

The virtues of any language only show after extensive use in real situations by language experts.

---

As a professional developer with over 30 years experience, using over 50 different computer languages [15 years C++, 6 years C#, 2 years Managed C++, 3 years C++/CLI], I think I might fall into that category... ;)

Quote:

---

Originally Posted by TheCPUWizard

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

---

It was you who introduced "headers" as a special difficulty of C++/CLI in relation to C#. I don't need to be lectured about the use of header files or design issues concerning classic C++. I'm interested in pure managed C++/CLI only at this point.

As I mentioned the C++/CLI textbook I'm using show hardly no includes at all so I was under the impression that they weren't strictly necessary if one sticks to CLI.

Quote:

---

Originally Posted by TheCPUWizard

The majority of "textbook" programs are simple single module programs. This is radically different from a "real" program that may contain hundreds of .cpp (and corrosponding ".h") files.

---

My textbook isn't really a step-by-step introduction (It's C++/CLI by Hogenson). Still I can see no indication that a C++/CLI class file must be divided into a .h and a .cpp part.

I agree with you that controling and using header files is a true nuisance in classic C++ but I'm not convinced it's a problem in C++/CLI if you stick to the pure managed part.

In Java one is forced to import the classes one is using but this is largely a non-problem because of the import management good IDEs offer. In principle they tell you what you need to import.

Quote:

---

Originally Posted by _uj

Read my posts with some attention and it will become clear. If you cannot be bothered the answer is no to both your questions.

---

If you cannot be bothered to be polite then I will not bother to continue trying to be helpful in this thread.

Bye.

Quote:

---

Originally Posted by Zaccheus

If you cannot be bothered to be polite then I will not bother to continue trying to be helpful in this thread.

Bye.

---

I appreciate your help but I still feel free to argue if I don't agree with you. What did you expect? That I lick your feet in thankfulness just because you replied? I also adopted your rather condescending tone. If you didn't like it why should I? Now be a good sport and come back to the thread. :)

Quote:

---

Originally Posted by TheCPUWizard

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:

---

Well I've browsed a little further in my textbook and it's pretty clear that the above isn't true.

The #include directive is part of classic C++ and you don't need to use it in pure managed C++/CLI. Instead you use the #using directive which should let you import managed assemblies very much the same way as in C#.

Again to me it seems very much that the notion of C# being much easier than pure managed C++/CLI is a myth. Okay if you resort to the classic C++ part of C++/CLI and you find C++ difficult than of course C++/CLI will be difficult too but this is an option you don't have to utilize (unless the need arises and then its quite handy actually).

So to me C++/CLI seems to fullfil two quite disparate objectives. Firstly to be a language capable of swallowing classic legacy C++ code, and secondly to be a good managed language at par with C#. In the latter capacity it has none of the drawbacks of classic C++, like say this "header" issue we've been discussing.

Quote:

---

Originally Posted by _uj

I appreciate your help but I still feel free to argue if I don't agree with you.

---

Argue away, by all means.

But comments like ...

Quote:

---

Originally Posted by _uj

What did you expect? That I lick your feet in thankfulness just because you replied?

---

... are simply not helpful.

Quote:

---

Originally Posted by _uj

I also adopted your rather condescending tone. If you didn't like it why should I?

---

I wasn't being condescending. Your post #44 was the first indication in this thread that you had not written any C# or C++/CLI at all - which surprised me, because if I'm considering using a language then I tend to give it a try, especially if I want to know something specific (like the #include issue). Of course it makes sense to ask people, who know the languages, for their opinions (that's why I'm responding to this thread) but that does not stop you from giving them a try. But that was not meant to be a put down, just a friendly suggestion.

Quote:

---

Originally Posted by _uj

Now be a good sport and come back to the thread. :)

---

Well, as you ask so nicely.
:D

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.

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

Zacchaus,

I agree with your last post, except:

Quote:

---

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

---

It is primarily that, but it also fills two other roles:

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.

Yes, I agree.


I would also add that C++/CLI has the ability to access native C++ classes exported from 3rd party DLLs ('mangled' C++ identifiers), something you cannot do in C#.

Like you say, it's all to do with accessing native code efficiently, i.e. writing 'glue' code.

The bulk of most applications can be written more easily in C#.