I'll the first to argue that C# does have its shared of memory problems.

Sometimes it is not enough to just rely on the garbage collector. You have to explicitly ask for it:
GC.Collect();

But then again, that is only a request. There is no delete. Sometimes you have to dispose your objects:
MyObject.Dispose();

I'm not aware of any other ways to delete memory in C#. (excluding the topic of remoting which is shared process memory space).

I am aware of the TAO engine, but that takes the fun out of it.

See the difference between MFC and C# is that with MFC you had to change code in 10 unrelated places anytime you wanted to alter a single object. In C#, it's all form based. You can create an event and you only need to add code to the calling method. It just makes things way easier.

Plus, I'll write my code to be compatible with Mono. I'll supply the batch files and the bash files, so you can run on both Windows or Linux.

I'm still using VC++ version 6.0; I dont see any reason to change based on the direction I'm trying to take my code. Ultimately, your choice of language should not have a significant impact on the engine you develop; that is to say we are all going to have our fair share of problems and they are going to be different (based on language). The thing that stays constant is that the engine we develop will solve the problems we want it to solve(and nothing more).

Quote: Original post by skow

Quote: Original post by _DarkWIng_
I know I'm building my next engine in it.

Why would you use c# instead of c++? What are the advantages?

Language is just a tool. I'm moving to C# for most of my other projects. It alows me to do some things much faster. I like prototyping and this is very simple and fast in C#, with all the build in calsses and templates (in 2.0). All in all, its just a personal choice.

Just to chime in with my unashamedly pro-C++ $0.02. As _DarkWIng_ has already pointed out, language is a tool and you should use whatever tool you feel is most appropriate to the task. That said, memory management should not be an issue in C++. Sure, if you code everything with raw pointers and make copies and make a real mess then it will be difficult (I should know, I've done it enough times), but the beauty of C++ is that it is so extensible. Prefer garbage collected memory management? Download a garbage collector implementation (or, if you're up to it, write your own). Don't like garbage collection? Use std::auto_ptr, boost smart pointers or roll your own smart pointer.

I've come to realise that there are three stages in learning C++ (OK, there may well be more, but I'm only at stage 3 at the moment [lol]):
1. Not understanding how to use pointers.
2. Understanding how to use pointers.
3. Realising that nine times out of ten you don't need to use pointers.

Also, you can't compare MFC and C#. MFC is a library. C# is a language. There are many other windowing libraries for C++ besides MFC and although I don't know for sure I would suspect that C# does not restrict you to forms and that in fact it is possible to use an MFC-like library in C#.

To try and get this thread vaguely back on topic. I think the city theme would be interesting. It's a bit different from anything done before at NeHe. I wish I could enter, but I suspect I won't have time. I'll look forward to seeing all the entries though (will we finally get a full demo from you Vincoof?).

Enigma

OK MFC is a library and C# is a language. So I was comparing System.Windows.Forms to MFC.

You don't have to use System.Windows.Forms. I wrote an example of pinvoking GDI32.DLL to use Win32 calls in C# to create windows. I find it far easier and more intuitive using Windows.Forms. (Although, I put up a lot of resistence before I made the switch).

I know some people are stuck on VC 6.0. But Mono offers a free mcs compiler for C# that works on multiple platforms. If you do write in C++, one problem is you have to write wrappers around your windowing code. A bunch of compiler options for #if WIN32, #if LINUX #if SOLARIS. One advantage for C# is that you can get away from that.

Another advantage of C# is the built-in ADT types. You can use the built in String, Stack, ArrayList, BST, etc. Everything is in there. It has built-in fonts, image handling/conversion for (BMP/TIFF/JPG/GIF), audio streams, web services, window services, and db connection code.

You gotta move with the times. At work we are moving towards ASP 2.0. With any luck we'll be getting a pre-release copy any day.

[Edited by - tgraupmann on October 12, 2004 2:48:46 PM]

Quote: Original post by tgraupmann
Plus, I'll write my code to be compatible with Mono. I'll supply the batch files and the bash files, so you can run on both Windows or Linux.

If that is your plan, then I'd suggest either not using the System.Windows.Forms code, or having a GTK# alternative for linux, since Mono doesn't have SWF support yet. DotGNU does, but you'd still need specialized code for the different linux/windows OpenGL setup. SDL is currently the only alternative that will just work on all platforms right now without specialized code for each platform.

As for creating project files, there is a usefull utility called .Net Pre-Build. The version on that site supports sharpdevelop, vs2002, and vs2003 targets. The SF project is pretty much dead, but I believe that the version that is currently used by Axiom and CEGUI# has been imroved some by Randy Ridge (Tao creator), and Leedgitar (Axiom creator).

J.W.

Last I checked I was able to run System.Windows.Forms apps on Linux with Mono. The SF project died before they added debug support. I could be mistaken.

When I get home tonight, I'll fire up Linux Mandrake and give it another test run.

Quote: Original post by tgraupmann
...snip...
Another advantage of C# is the built-in ADT types. You can use the built in String, Stack, ArrayList, BST, etc. Everything is in there. It has built-in fonts, image handling/conversion for (BMP/TIFF/JPG/GIF), audio streams, web services, window services, and db connection code.

You gotta move with the times. At work we are moving towards ASP 2.0. With any luck we'll be getting a pre-release copy any day.

std::string, std::stack, std::vector/std::deque? OK, so C++ doesn't have built-in fonts etc., but there's a reason for that: different applications have different requirements. Some might need a small memory footprint while others need fast execution. There are plenty of libraries out there to do all of those things in C++ with very little effort. Plus the C++ standard library will expand with the next version of the standard. C++ is moving with the times too.

I'm not trying to argue against C# here (well, maybe a little :P), just clear up a few common misconceptions about C++.

Enigma

Please don't turn this into another language flame-war. There are other threads for this. Please continue the original topic about demo theme selection.