Hello everyone,
As most other C++ programmers who have been around for awhile, know that making tools with C++ with GUI from the ground up can be a big pain in the butt sometimes (unless you have a lot of reusable code from past projects), not to mention taking a huge amount of time. I'm not interested in using MFC for obvious reasons. I've gotten to the point where I really like C++ and could not see myself fully using C# for tool kits anymore. So my question is, will going into Managed C++ just for Level Editors and other tools be wise? How easy will it be to grasp the concepts to setup my tools? (I've never even looked at C++.net to be honest).
I've used C# for a level editor that exports files for my Engine, however I would rather just stay with C++ instead of swapping back and forth. I've had a hard time moving on to programming a project using several languages, even though I've learned enough C# to make a game in that language.
Do you recommend C++.net for tool sets? Or should I just stay with C#? I'm trying to end the habit of making tools using APIs like SDL to save time.
NOTE: This topic is not a (VS) topic for C++ vs C#. It's a topic to decide which will get results faster for building tool kits. I've invested enough time through the years in C++ to keep this as my language of choice.
Managed C++ for game tools?
Hello everyone,
As most other C++ programmers who have been around for awhile, know that making tools with C++ with GUI from the ground up can be a big pain in the butt sometimes (unless you have a lot of reusable code from past projects), not to mention taking a huge amount of time. I'm not interested in using MFC for obvious reasons. I've gotten to the point where I really like C++ and could not see myself fully using C# for tool kits anymore. So my question is, will going into Managed C++ just for Level Editors and other tools be wise? How easy will it be to grasp the concepts to setup my tools? (I've never even looked at C++.net to be honest).
I've used C# for a level editor that exports files for my Engine, however I would rather just stay with C++ instead of swapping back and forth. I've had a hard time moving on to programming a project using several languages, even though I've learned enough C# to make a game in that language.
Do you recommend C++.net for tool sets? Or should I just stay with C#? I'm trying to end the habit of making tools using APIs like SDL to save time.
NOTE: This topic is not a (VS) topic for C++ vs C#. It's a topic to decide which will get results faster for building tool kits. I've invested enough time through the years in C++ to keep this as my language of choice.
Personally i'd recommend taking a look at QT , its quite easy to get started with, works on multiple platforms and with QTCreator you get a really nice UI design tool.
Author
Thanks, I'll look into QT. I've heard about QT countless times, even had the page bookmarked, never really went there though. I guess I really should be checking this out.
Thanks again.
Thanks again.
Managed C++ is the red headed stepchild of the .net world. If you don't want to use C# or Vb and are insistent on using C++ for GUI work the earlier Qt recommendation is as good as any.
For the record, I think using C++ for GUI work is a worse idea than using garden sheers to cut your toenails, but to each their own.
For the record, I think using C++ for GUI work is a worse idea than using garden sheers to cut your toenails, but to each their own.
Author
I do agree that when I used C#, heck even in my BASIC days GUI applications were a lot less time consuming than C++. I looked at QT briefly, it does appear to do everything I need, heck I remember making an active toolkit with C# using XNA that had a real run time for maps. Was a lot of fun! 
Was there a reason Managed C++ is a bad idea for toolkits? I wouldn't touch managed C++ with a flag poll for games though since I've never really jumped on board for .net games; however my tools are running on Windows 7. If I wasn't so keen on using just C++ and could break this bad habit, I would just use C# due to it's RAD Development. QT does appear interesting, that's for sure!
Was there a reason Managed C++ is a bad idea for toolkits? I wouldn't touch managed C++ with a flag poll for games though since I've never really jumped on board for .net games; however my tools are running on Windows 7. If I wasn't so keen on using just C++ and could break this bad habit, I would just use C# due to it's RAD Development. QT does appear interesting, that's for sure!
To be honest, my experience with Managed C++ may be out dated, but they basically cludged a bunch of new operators and keywords on top of C++ to sorta support .net, then in the following release basically deprecated them all and used a different set of cludges. Managed C++ was as close to C++ as C# was, without some extraordinaryly arbitrary memory access rules.
It may have gotten better since, but the first two iterations of Managed C++ were pretty awful.
It may have gotten better since, but the first two iterations of Managed C++ were pretty awful.
For the record:
"Managed C++" was the first attempt at gluing C++ into the dotNet framework. It is now deprecated and shouldn't be used by anyone.
What you're talking about is called "C++/CLI".
IMO:
C# is great for tools dev. C++ is great for engine dev.
C++/CLI is really ugly (it's basically C#, but with really cumbersome syntax), and should only be used in the rare cases where you want to plug some engine code into your tools (i.e. just use it when you're gluing C++ and C# code together).
"Managed C++" was the first attempt at gluing C++ into the dotNet framework. It is now deprecated and shouldn't be used by anyone.
What you're talking about is called "C++/CLI".
IMO:
C# is great for tools dev. C++ is great for engine dev.
C++/CLI is really ugly (it's basically C#, but with really cumbersome syntax), and should only be used in the rare cases where you want to plug some engine code into your tools (i.e. just use it when you're gluing C++ and C# code together).
Author
Thanks for all the advice. I know when I did C# before with my Editors, I would embed XNA into my form so I could tile, drag and drop, plus add collision areas, ect... If I end up using C#, will I be stuck with XNA? I could use slimDX, however I've never used Slim before. I still think GDI+ would be too slow, not to mention dragging and dropping enemies on the screen would be a nightmare.
Thanks for all the advice. I know when I did C# before with my Editors, I would embed XNA into my form so I could tile, drag and drop, plus add collision areas, ect... If I end up using C#, will I be stuck with XNA? I could use slimDX, however I've never used Slim before. I still think GDI+ would be too slow, not to mention dragging and dropping enemies on the screen would be a nightmare.
C++/CLI isn't bad to use but as Hodgeman says you should stay away from it unless you need to embedd a third party tool lib or some of the engine code into your tools pipeline. The syntax of it is close enough to C++ there are some new keywords and when a class needs to be visible by C# it needs to be a ref class and every "gcnew" has "^" as its pointer syntax.
When doing your tools in C# however your productivity is for bigger then writing pure C++ tools.
I've used C# for a level editor that exports files for my Engine, however I would rather just stay with C++ instead of swapping back and forth.
By "swapping back and forth" do you mean swapping code files back and forth or do you mean the language change?
If by that you mean swapping code files, I would recommend putting them into a .lib or .dll file.
If by that you mean swapping languages, I would recommend using wxWidgets. It is great for making tools and several game companies use it for their internal tools (when using C++).
However, it might be worth learning C#/WPF for building your tools. Some may consider it fast for prototyping and if you are looking to create tools professionally, a lot of studios use C#/WPF for their tools.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
