C# vs C++, .NET vs VS 6.0

IME, the most common way properties are used is that the setter validates the new property value, stores it in a member variable, and often calls an API or some other function to let it know the property has changed (e.g. updating a button caption on the screen), and the getter simply reads the property value from the member variable. Therefore, reading the property value is almost always a trivial operation.

Unfortunately, you’re also guaranteed that every piece of code that uses your class will break if you ever decide you need a function call after all.

Suppose you’re writing a text box that can be toggled between single and multiple lines, so you make a boolean property MultiLine. For optimization purposes, you make it a public member variable, and in your keyboard event handler, you simply ignore the enter key if MultiLine is false.

Then a few months later, you decide you don’t want anyone to disable MultiLine if the box already contains line breaks. Or you change the look of the control so that it needs to be redrawn when MultiLine changes. Uh oh… that means writing a setter function, and rewriting all the existing code that uses that class.

The problem with those is you end up learning new syntax for every function that behaves like that. Since you can’t write one function that can accept a combination of strings, numbers, and objects, you end up with several functions that work together to do the same thing and need to be stuck together with operator overloading… and as you’ve illustrated, different libraries use different operators for the same thing. (AFAIK, generics in C# aren’t implicitly instantiated, so you can’t do this in C#.)

Now, I’ve looked at Boost and I’m impressed with the way they’ve been able to tortu–I mean, extend the language with templates ;), but I sure wouldn’t want to write something like that myself. It’s much easier to loop through a list and call ToString() on all the elements than to make all those templates and operators work together.

And a function that takes different parameter types is just one example. A single root class also lets you combine different types in a single array, like the list of items in a list box.

It’s not an implicit cast, it only happens when you call ToString(). And while you need an explicit cast in C# (just like in Delphi), in MC++ you can implicitly cast a __value enum to an integer.

Besides, ToString() is an excellent debugging tool, and comes in handy at other times - like the aforementioned list of items in a list box. You can toss strings, integers, and objects in the list box, and they’ll all be converted to strings when they’re displayed.

Proper coding of the Dispose method is what protects you against double Dispose().

Do you have a link where this is documented? I haven’t worked much with Java, but my understanding is that setting an object’s last reference to null only makes it available for GC, as in .NET; it doesn’t force immediate finalization or GC.

Thanks for the info so far, just another question to top it up. What is this managed c++ that I have been hearing about? What makes it different from the ANSI standard C++?

If I have been following correctly, I assume that there are some new libraries for threads and etc. in .NET. Do I have to use them? Are they, so to say, “standard”?

Thanks again

Managed C++, or to give it its full name, managed extensions for C++, are a set of proprietary extensions to the C++ language to allow it to play along in the .NET world. See here: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vcmex/html/vcconmcoverview.asp

To a UNIX C++ developer, they would look like Martian language.

Now the IMHO part: I’ve been using Visual Studio (formerly Dev Studio, formerly Caviar, formerly…) professionally since V 2.0. I have mainly been a C++ programmer but with quite a bit of VB and recently, a lot of VB.NET and C#. I have a couple of Microsoft certifications and in general I’m a huge Microsoft fan.

My opinion is that .NET is beautiful - clean, well designed, elegant.

Visual Studio .NET stinks.

Sorry, VS team, but compared to .NET itself, Visual Studio .NET is a wet fart. It is slow, quirky and buggy. The buggy part is to be expected for such a new product, but the slowness is inexcusable. It take forever to fire up, and loading projects & solutions is a nightmare, especially if you’re masochistic enough to enable source control integration.

The way web projects are handled is a joke - it reeks of Interdev and I’m sure there’s some ugly Interdev DNA buried in there. It’s so bad that a few people (including the developers at my company) totally eschew web projects, instead tricking the compiler into creating them under the guise of class libraries.

It’s no surprise that even senior people at Microsoft avoid Visual Studio - one high level architect there uses emacs and the command line .NET compilers for his work.

And that’s the beauty of .NET - it is open, so 3rd parties can (and have) produce development environments for it to compete with Visual Studio.

Wracking my brains for something positive to say about Visual Studio .NET…well, there are a couple of things: the new Help system is pretty cool, very useful (especially compared to previous incarnations of MSDN). The visual designer tools are powerful, friendly and even fun to use. The unification of the various languages ( MC++, C#, VB.NET, J#) in a single IDE, using the same visual designer for WinForms and WebForms projects, is a big achievement.

Boy this thread got technical fast. Here’s the basics.

C# is part of Microsoft’s attempt to steal Java’s thunder.

Java works by creating a fake software-based computer on your hardware-based one called the Java Virtual Machine, and the compiler create the “bytecode” that is this virtual machine’s language. In theory, all you need to do to run an existing Java program on your computer is to get yourself a JVM and you’re in business, you don’t even need access to the source code to recompile.

Took the computing world by storm, it did, both for that reason, and the fact that the syntax is like a streamlined C++, optimized for object-oriented programming. Granted, the bytecode prevents you from working with pointers, but you do get to lose the “header” files that are essentially written in a different language. Everything is Java is a class, and you simply import the classes you need. When you declare a new class within an executable, it gets compiled as a separate file for easy re-use. Neat!

Java has any number of problems that keep it from being ideal, but its biggest problem, as far as Bill Gates is concerned, is that Sun Microsystems owns and controls it, and he doesn’t. It’s rise in the late 90s made him ever so pissed, and he does everything he can to thwart it, from ensuring that later versions of Windows can’t run the JVM (Sun built a workaround), to creating his OWN version of the JVM, the .NET platform, optimized for Gates-oriented control.

.NET even comes with its own version of a souped-up C++, called C#, which, while not exactly Java, does move in the same direction, and apparently lacks certain problems that Java experiences. If you google the two languages, you will find any number of reports comparing the two. Most of the ones I’ve read basically come to the conclusion that C# is a perfectly workable language, but there’s nothing earth-shatteringly new about it.

I teach a C/C++ introductory programming class, and we have VS.NET installed. It’s a little buggy, but it gets basic jobs done OK. Unless you understand and wish to use the .NET platform, there’s no reason to upgrade. My co-teacher would prefer we still had VS6 as a matter of fact, and he’s a far more experienced programmer than I.

When you hear people espouse the various merits of different approaches, keep in mind that the world of computers is divided into two groups: those who believe that the world begins at Bill Gates’ left nut and ends at his right one, and those who do not. The nuts will tell you that C#, being the newest bestowal by the God of the Northwest, is the only language that matters, and you’d better get on the bandwagon, or be hopelessly left in the dust. The rest of us will wait and see.

Hmm, I´m not sure about that. What about mutual or cyclic references / includes? Say you have two classes, A and B, and A uses B, and also B uses A; or longer cycles involving more classes. This is not far - fetched, and because the the C/C++ preprocessor is really just a text replacement “tool”, you can´t simply #include “A.h” in B.h and #include “B.h” in A.h. It won´t work. This is a really old problem, and the classic solution is to move the #includes to the .cpp (or .c) file, and put a forward reference in the header. Forward references are part of the C/C++ language for that very reason.
So if you move all your code in the header, like the .NET IDE for managed C++ does by default (at least for Forms), you will likely run into problems if your application is more than a hello world type program.
Or is there a mechanism/language extension in managed C++ that I´m not aware of?

Another thing I would like to mention is that managed C++ is really C# in disguise. There are SO many differences form standard C++ that it is simply a new language created by Microsoft that has a C++ like syntax. I´m not saying it´s bad, you can get your work done, the IDE is very nice etc. But from a language standpoint … no multiple inheritance, interfaces, delegates, properties, __gc arrays that need to be constructed, the awkward syntax that goes with it, the fact that primitive types like int are really Int32 value types (you can say “int i.ToString()”!!!) etc. make mananged C++ a mock java or C#.

I just wanted to add this: of course you could put up one big and cleverly designed .cpp (or .h) file, because that´s what the C/C++ preprocessor produces in the end. So stirctly speaking, there is no need for seperate .h and .cpp files, it´s just not manageable for larger projects.

I never really used Visual Studio until version 2003, but if the previous help systems are even worse, I’d hate to see them. It’s nice that VS.NET’s help system integrates with the IDE, appearing as collapsing panes and tabbed windows just like a CPP file or property editor, but in terms of actually finding the right help topic when I push F1, the help system is an utter failure.

In Borland’s Delphi and C++Builder IDEs, if you select a keyword that has more than one definition (like a method that appears in two unrelated classes) and push F1, you get a list of topics and you have to select the one you want. VS.NET, on the other hand, seems to choose the topic least related to what I actually want to learn, and show that one automatically.

No, there isn’t. If you compile your forms separately, you can import the binary metadata from one file into another (see the #using directive) and use it without a header, but if you want to compile them together, you need a header as in regular C++.

The .NET parts are like that, because the .NET environment has an object model that each language can’t really avoid using for managed types… but note that MC++ is a superset of regular C++, and the new rules only apply for classes that use the managed extensions. You can still use the STL, Boost, and other C++ libraries. You can still have classes with multiple inheritance and statically allocated arrays, as long as you leave out the __gc keyword - which means giving up garbage collection and interoperability with other .NET languages for those classes.

On a side note, properties were also in older versions of Visual C++, but they were declared differently. I don’t know why MS felt the need to make up a new property syntax for MC++, but they’re doing it again for the next version of Visual Studio (which features yet another C+±like language, “C++/CLI”).

#using directive:
Yes, you could do this. But this is sort of like making all of your forms COM controls and using the COM metadata as a replacement for #includes. What I really wanted to say is that a Java or C# compiler is much smarter (or different) than a C++ compiler; in Java each class “knows” each other if they are in the same package. In C++, seperate .h and .cpp files are needed in many not so unusaul cases simply because of the way the preprocessor works. You can´t simply unify those languages because in the end they are all compiled to the same intermediate code.
Don´t get me wrong, I have nothing against .NET, but if you stick with the text replacement preprocessor, you have to stick with seperate .h and .cpp files too. What really bothers me ist that the .NET IDE places all the code in the header. It´s a lot of work to move and maintain that code once you have cyclic references, and it´s also ugly from a C++ perspective. C++ isn´t Java, and I wouldn´t be complaining if the C++ IDE behaved like the good old VC++ 6.0 IDE. It´s class wizard was actually helpful, and I miss it.

You are right.
I think I misstated my objections.
I like the .NET object model, I like Java too, and I think that interfaces are a much more sane alternative to multiple inheritance (although I love Eiffel, but it has it´s probems), I think that properties are a good idea and I see nothing wrong with garbage collection, __gc arrays or “primitive” types being “value types” and int i.ToString() etc. It´s alright, and it is really an evolution of C++.
But – it isn´t C++. Yes, strictly speaking, managed C++ is a superset of regular C++, but what purpose does it serve? You can use the STL, but you can´t put a managed class in a STL container, and still expect everything to work. There is support for MFC, but it doesn´t mix well with managed C++. It seems to me that there should be a VC++ 7.0 (MFC) and a .NET MC++. But Microsoft deceided to unify it, and it is a very bad marriage. Calls to the Win API or .dlls are a pain in managed C++, it works a lot like it did in Visual Basic. But it should be no problem in the “VC++ 7.0” mode? Is it? I really don´t know, especially if you mix it with some managed code. I know they advertised something like “Bring all your old MFC code, it will work fine, and augment it with our new .NET classes”. I think a project like that would be a suicide assignment, and I really woudn´t like to be responsible for maintaining such a monster.

Ok, sorry for the rant.

It’s mostly useful for two things:

  1. Making glue or wrappers to let native code work together with managed code. If you’re the author of a C++ library, and now you want to offer it to .NET developers, it’s pretty straightforward to make a .NET wrapper in MC++ to expose it as a managed class (or vice versa - you could expose .NET classes as a native DLL). If you need to import a function with complicated parameters from a DLL, it might be difficult or even impossible to do it from C# or VB.NET, but not in MC++.

  2. Writing high-performance managed code. The MC++ compiler does a better job of optimizing your code than the other .NET compilers (though the runtime’s JIT optimization is probably more important), and you can do things like work with a boxed object without copying it.

No, but you can copy the data in managed class to and from STL containers.

I’m doing a project at work right now (well, when I’m not posting on the SDMB ;)) with a guy who has a background in C++ on Unix. He’s developing the back end for this app with GCC, using the STL and Boost to do number crunching and parsing, and I’m developing the front end in MC++, using Windows Forms for a GUI and .NET’s serialization to save settings.

When he commits his changes, I can simply recompile the app in Visual Studio and it all works together. I can catch C++ exceptions, fill in unmanaged structures, construct his classes, and call his methods, all from my managed code. His code compiles to IL just fine, even though it uses unmanaged types hand over fist, but I could choose to compile it to native code if necessary.

They call it “IJW” (It Just Works), and as far as I can tell, it lives up to its name. Calling the Windows API or a DLL function is a piece of cake with MC++ - you just use an import library or #include <windows.h> or whatever you’d normally do in C++, and the compiler makes it work.

Ok, I admit that my comments regarding mixing managed and regular C++ were based on my “gut” feelings and speculation.
The way you describe it sounds pretty amazing. Maybe I´m a bit conservative, but some part of my brain still refuses to believe that it works that well.
And I still think it is a bit cumbersome (ok, it isnt´really a “pain”) to call into the Win API from managed code, with all the PInvoke and redeclaring possibly lenghty structs. To be fair, the whole point of the .NET API is to provide a framework for applications so they don´t have to rely on the native API; and it´s ok to make life a bit harder for people that need DeviceIoControl() in return for a nice and clean framework.

A question: do you also have experience with integrating existing MFC code? If so, I would really appreciate it if you elaborated on it a bit. Bacause again, some part of my maybe conservative brain says “This can´t possibly work!”. I mean, taking a large MFC app, and “augmenting” it with .NET classes, maybe even windows forms, or even putting a Windows::Forms::UserControl on a MFC form etc. - does this really work? Aside from the fact that it would be ugly from a maintance standpoint, if it does work, my hats off to Microsoft.

I enjoyed the whole discussion, even if it drifted off a bit from the OP´s question. (To the OP:) My personal experience with .NET has been quite positive, and I think both C# and managed C++ are worth your time; and altough the whole thing could still turn out to be a flop or never really catch on (like COM+), it seems rather unlikely at this point.
For me, the hardest part of the transition was to see the marketable value of my expertise in MFC go down the drain. l know I´m exaggerating, but just a couple of years ago, in the Windows world, you were either a “real” programmer who used C++ and MFC (or even the Petzold style), or a “hobby” Visual Basic programmer. Now that gap has closed considerably, but that´s life.

Yes, that’s cumbersome - but again, you only need to use P/Invoke if you’re coding in C# or VB.NET. In MC++, you can still use P/Invoke if you like pain, but it’s a lot simpler to just #include <windows.h> and let the compiler figure it out.

I don’t have any experience with MFC (except when I spent two weeks trying to make a simple dialog app and gave up on MFC forever), but I doubt you can mix native and .NET controls on the same form like that. You can do it by using the .NET control as an ActiveX control with COM Interop, but that’s a pain. Apparently they’re going to add better WinForms/MFC compatibility in the next release.

It should be easy enough to add .NET forms to an MFC project, though, and also to use managed nonvisual classes from native code. There are a couple small hangups: The garbage collector doesn’t know about native pointers, so if you store a pointer to a managed class inside an unmanaged class, you have to wrap it in a gcroot<> template so the GC doesn’t delete the object. You also need to use some helper functions to copy .NET strings to and from STL strings and char*, but I don’t think you need those to convert them to MFC’s CString.