I've had much experience writing in Java, python, C#, and C, mostly for hobby. In all of the applications I've coded that involve displays (simulations, graphers, etc.), I've always just used the stock "Canvas" class of whatever framework I'm using (Swing Canvas, .NET Canvas, pygame once for python).
The downside of this is that all of these have slightly different paradigms in drawing.
I'm starting a project in C++ and was wondering what the best solution is for cross-platform drawing. OpenGL is obviously very low level, but some sort of library on top of OpenGL would be good. I've heard of/read about things like Cairo, SDL, etc., but don't yet know what to go with. I'm already using wxWidgets for interface, but would prefer to use something more standard instead of just a wxWidgets canvas. Obviously, the ability to draw lines and shapes is important, not just display pictures or whatnot.
Thanks for any direction!
I would consider using Qt, and notably its Graphics View framework. (Qt works on Linux, Windows, MacOSX).
SDL is SimpleMedia Direct Layer, which is basically a common interface to interface with the framebuffer and audio devices. If you wanted to create windows and such, it doesn't have general purpose constructs that work cross-platform.
Cairo is for drawing graphics, but still operates at a level that's lower than what WxWidgets provides.
C++ doesn't provide anything standard, so either you go with some platform specific, or you use a cross platform library like Qt (already mentioned by Basile) or stick with wxWidgets. Both are popular and widely used, though Qt is probably much more well-known and used (though that is just opinion). I've used Qt for work and it is very much cross platform and pretty easy to use (but very extensive, so prepare to read a lot of documentation). Luckily it also has a lot of documentation and many examples available.
Plus, both wxWidgets and Qt have bindings in many languages, so you could take the knowledge with either and use it with many other languages.
Open Frameworks is very easy to use and comes with a lot of examples...
it's platform independent and somehow reminds me of processing
I am producing a piece numerical software in C++ and want to add a GUI (mainly for Windows). I know how to produce GUIs using comfortable editors in modern languages like Java or .NET. Now my question is what is the easiest and most comfortable way to add a GUI frontend for my program. In the choice of the tools am completely free (open source and portability would be nice), but please also keep in mind how much boilerplate code and interfaces that have to be maintained are required if the GUI is implemented in another language (Like C#).
Please don't suggest switching the whole project from C++! And note that the program does not require not much interaction between the C++ code and the GUI.
The statements about ISO C++ in this answer's comments are poorly edited. None of the solutions presented here would impose on the computational code a requirement of changing to a different dialect of C++. The GUI code itself might be another story.
The answers about using Windows Forms with managed C++ are probably the most practical. A lot of the UI-related code would be in a dialect (extension) of C++ where the .NET-garbage-collected pointers would be living alongside the traditional ISO C++ pointers. I haven't used this method but from what I read it might be better than what I have used.
MFC might be more practical if you don't want to invest in .NET knowledge for this task. It uses standard C++ constructs to wrap the Windows API. The Windows API uses a particular calling convention which C++ doesn't normally use, and it takes an extension to C++ to work with that, but this is no different than having a C++ program that calls some functions that are extern "C". Visual Studio has a GUI layout tool that is really good at layout of dialogs and at interfacing the dialog widgets to variables that reflect the state of the widgets. I've used this. If you can boil your GUI down to a dialog box then this would be a great option, otherwise you'd be using one of MFC's layout-managed windows.
Obviously the above options do not handle other platforms you might have in mind.
There are also various toolkits that were born on other platforms and have been decently ported to Windows. GTK, QT, FLTK, and WxWindows come to mind. I haven't used any of the dialog-layout/application designer tools that work with those, and I haven't used QT at all. When I last reviewed QT it had a special preprocessing pass for the GUI code. Other than that these portable tool kits are pure ISO C++ as far as I know.
As a really-out-there option one could program to the X Window System protocol using "libx". As far as I know this would involve no non-ISO C++ code.
Qt is a decent choice. It's stable, has a wonderful C++ interface (as opposed to MFC) and has a convenient designer tool.
The overhead of learning it from scratch might however be more that what you're willing to invest. It does have a certain learning curve.
wxWidgets would a good choice for a cross platform GUI for C++
As much as I love C++, it's difficult to build a GUI with. I'd build a quick C# WinForms application which would let you use things like Visual Studio's visual designers (Drag and drop buttons and such), and call your C++ application using P/Invoke.
C++ will often produce smoother and nicer GUIs, but it takes a bit more work out of the box.
If it's going to be just a simple GUI consisting mostly of standard controls I would do it with MFC. It may be outdated and was never really good, but it's still useful to get a native Windows GUI up and running quickly.
I have to chuckle at all the ways to skin this cat. Life is good. My response is a product I manage. XVT can do it for you. The easiest way is let us do it for you or give you a template to get there. It's just a matter of if you have more money than time. Then I'd look at us. It would be the fastest and least amount of effort on your part.
MFC Dialog Based application could answer the needs.
Depending on what you need, there's a nice imgui made by Mikko floating around that you can simply plug-in and use fairly quickly. It's done in opengl though so it won't be your standard windows-gui but it's really small and really easy to work with. You can download r'lyeh's version from here: http://code.google.com/p/colony9/source/browse/include/goo/imgui.h.
That's the easiest and most comfortable way I know, it is dependent on SDL though.
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
Gui toolkits, which should I use?
I've got a fair bit of C/C++ experience - mostly for writing console application for Windows/Linux, and also a fair bit of C# experience - generally for writing WinForms applications etc.
I'm extremely impressed with with ease at which I can create a window in .net, for example something as simple as
Form form = new Form();
form.ShowDialog();
is enough to get a blank form up on the screen. In fact,
new Form().ShowDialog();
is technically enough as long as we don't mind losing reference to the form after it's closed.
I've tried writing some windows-based GUI stuff in C++ using windows.h, but not only does the learning curve seem a little steep but also the syntax is extremely verbose. Creating a simple window like the above mentioned single line .net implementation can easily exceed 2 dozen lines using windows.h.
But not only that, if I were to port the application over to Linux/Max (something which I can pretty much never do with .net, with the exception of hacks like mono etc), then I would need to rewrite 95% of the GUI code.
I'm assuming this is where frameworks come in, for example QT etc... (I don't really know much about gui frameworks, I'm afraid).
What GUI frameworks do you recommend? which are the most powerful and which are the easiest to use?
How do you generally tackle the task of coding your GUI in C/C++?
The closer to the metal (so to speak) that you are programming, the more difficult things get. WinForms (provided by the .NET Framework) is a pretty outstanding abstraction over the Win32 API, considering the complexity you've already seen that it involves for the even the simplest of tasks, like getting a window to appear on the screen. All of that is still happening in the background, of course (registering a window class, creating the window, etc.), you just don't have to write the code yourself.
It's interesting that you write off Mono as a "hack", but would consider a library like Qt. I'm really not sure on what basis you make the distinction. The Mono library is widely regarded as excellent when it comes to WinForms support. The biggest detractors are the same as Microsoft's own CLR implementation, namely that it doesn't produce truly native code, which is more irrelevant to performance in the majority of situations than one might think. Beyond that, some complain that Mono applications don't conform fully to the platform's UI guidelines (that is, they don't look and behave exactly like a native application would), but I have a similar complaint about applications written using Qt.
It seems like literally everyone recommends using Qt if you want to do GUI work in C++. As I mentioned above, it happens not to be my favorite library because I'm a stickler for using fully native controls and widgets provided by the platform you're currently running on. I understand that Qt has gotten a little better at this recently, but I still don't think it's up to my standards. If you're more flexible than I am (and I'll warn you that the average Mac user is not any more flexible than I am), and true platform independence is a big concern to you, it's probably the one you should opt for. Many people praise it for its design elegance and convenience, although I seriously doubt that even it offers the same simplicity as the .NET Framework's implementation.
If sheer simplicity and terseness of code is as important as the beginning of your question makes it sound, I highly recommend sticking with C# and WinForms. Things get harder as you start to remove layers of abstraction, and if you don't need the extra levels of control that doing so affords you, there's hardly any justification for making more work for yourself. Mono's Forms implementation is a perfectly viable solution for cross-platform applications, assuming your needs are relatively modest.
Beyond that, if you want to create a truly cross-platform application in C++ the right way, I recommend that you strictly separate your data layer code from your UI layer, and then write the UI using the tools provided by each platform you want to support. In Windows, your options are relatively open: .NET WinForms is a solid choice, native Win32 is a somewhat painful though merited option, and a handful of other libraries like MFC and WxWidgets can help to ease the pain of fully native programming (though not nearly as well as WinForms does). On the Mac, the only real option is Xcode, Interface Builder, and Objective-C, targeting the Cocoa framework. Linux/Unix-based systems are hardly my forte, but I'm given to understand that Qt is about as native a library as you can get. This sounds like more work than I think it is—a well-designed library should handle 80% of the work, leaving only around 20% that you have to do in implementing the UI. Beyond using truly native controls and widgets, I think the other big advantage afforded by this approach is flexibility. Notice how Microsoft Word looks very different (despite some superficial similarities) on Windows than it does on the Mac. And iTunes has become almost a paragon of excellent UI design on the Mac platform, but sticks out like a sore thumb on Windows. On the other hand, if you rolled out something like Windows Media Player on the Mac (and yes, it's been tried by Microsoft themselves, though without much success), Mac users will dismiss it as a complete abomination and probably be somewhat offended that you even tried. Not so good for the truly cross-platform-minded developer. All of that to say, if your app is anything but the simplest of utilities, you'll probably find that an entirely different interface is justified (and even expected) on each platform that you want to support.
No matter how great Qt may be, you're not going to get that with it.
Qt, hands down.
it's the most complete, most mature, fastest framework available. and on top of it, it's seriously multiplaftorm and your choice of commercially friendly open source or paid support.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
C++ just sucks too much of my time by making me micro-manage my own memory, making me type far too much (hello std::vector<Thingy>::const_iterator it = lotsOfThingys.begin()), and boring me with long compile times. What's the single best alternative for serious real-time graphics programming? Garbage collection is a must (as is the ability to avoid its use when necessary), and speed must be competitive with C++. A reasonable story for accessing C libs is also a must.
(Full disclosure: I have my own answer to this, but I'm interested to see what others have found to be good alternatives to C++ for real-time graphics work.)
Edit: Thanks everyone for the thoughtful replies. Given that there's really no "right" answer to this question I won't be selecting any particular answer. Besides I'd just pick the language I happen to like as a C++ alternative, which wouldn't really be fair.
What about D Programming Language?
Some links requested in the comment:
Win32 Api
Derelict (Multimedia lib)
I wouldn't discard C++. In fact, I would consider adding Boost to your C++ library, which makes the language much more usable. Your example would become:
BOOST_FOREACH( Thingy& t, lostOfThingys ) {
// do something with 't'
}
Boost has tons of tools that help make C++ a better language.
C# is a nice language that fits your requirements, and it is definitely suited for graphics, thanks to the efforts of Microsoft to provide it with great tools and libraries like Visual Studio and XNA.
Real-time + garbage collection don't match very well I'm afraid.
It's a bit hard to make any real-time response guarantees if a garbage collector can kick in at any time and spend an undefined amount of processing...
I disagree with your premise. When used carefully and properly, C++ is a great language, especially for a domain like real-time graphics, where speed is of the essence.
Memory management becomes easy if you design your system well, and use stl containers and smart pointers.
std::vector::const_iterator it = lotsOfThingys.begin()) will become much shorter if you use
using namespace std;
typedef vector::const_iterator ThingyConstIter;
And you can shorten compile times significantly by breaking up your systems into reasonably self-contained modules, by using precompiled headers, or by using the PIMPL idiom.
Perhaps a hybrid approach. Python and C++ make a good combination (see, for example, PyGame).
Some variation of Lisp that compiles to machine code could be almost as fast as C++ for this kind of programming. The Naughty Dog team created a version of Lisp called Game Oriented Assembly Lisp, which they used to create several AAA titles, including the Jak and Daxter series. The two major impediments to a Lisp approach in the game industry would be the entrenched nature of C/C++ development (both tools and human assets are heavily invested in C/C++), as well as the difficulty of finding talented engineers who are stars in both the game programming domain and the Lisp language.
Many programming teams in the industry are shifting to a hybrid approach wherein the real-time code, especially graphics and physics code, is written in C or C++, but game logic is done in a higher-level scripting language, which is accessible to and editable by programmers and non-programmers alike. Lua and Python are both popular for higher-level scripting.
Let's not forget to mention the new 'auto' use:
auto it = lotsOfThingys.begin(); // Let the compiler figure it out.
auto it2 = lotsOfFoos.begin();
if (it==it2) // It's still strongly typed; a Thingy iter is not a Foo iter.
As a developer/researcher/professor of 3D VR applications for some 20 years I would suggest there is no alternative (except possibly C). The only way to reduce latency and enable real-time interaction is an optimized compiled language (eg C or C++) with access to a fast relaible 3D graphics library such as OpenGL. While I agree it is flustrating to have to code everything, this is also essential for performanc and optimization.
Sometimes, looking outside the beaten path you can find a real gem. You might want to consider PureBasic (Don't let the name mislead you). Here's some details:
PureBasic Features
Machine Code (Assembly) executables (FASM)
In-line Assembly support
No run-times needed (no DLLs needed,etc.) 1 executable file
Tiny executables (as small or smaller/as fast or faster than C++ w/out the runtime)
You can write DLLs
Multi-thread support
Full OS API support
Multi-platform support
Windows 95-2003
Linux
Mac-OS X
Amiga
2D & 3D game development
DirectX
OGRE
Generous Licensing
Inexpensive (79 Euros or about $112)
Life-time license (all future updates & versions included)
One price for all platforms
External Library support
3rd party DLLs
User Libraries
On-line Support
Responsive development team led by it's creator
On-line forum
One place for answers (don’t have to go all over the net)
Huge amount of sample code (try code out while in IE with IEtool)
Fast replies to questions
Bonus learning (alternative to learning C++)
API
Structures
Interfaces
Pointers
Visit the online forum to get a better idea of PureBasic (http://www.purebasic.fr/english/index.php) or the main site: www.purebasic.com
I completely agree with the mention of C# for graphics programming. It has the slight disadvantage of being a managed language and allowing the garbage collector free reign over your application is framerate suicide after a while but with some relatively intelligent pool allocations made early in the program's life any real issues can be avoided.
Several people have already mentioned XNA, which is incredibly friendly and well-documented and I would like to echo that recommendation as well. I'm personally using it for my hobby game projects and it has treated me very well.
XNA isn't the only alternative, though. There is also SlimDX which is under constant development as a means of providing a lean wrapper of DirectX in a similar fashion as Managed DirectX (which was, I believe, discontinued by Microsoft in favor of XNA). Both are worthy of research: http://code.google.com/p/slimdx/
There are no true alternatives for big AAA titles, especially on the consoles. For smaller titles C# should do.
C# is a good answer here - it has a fair garbage collection (although you'd have to profile it quite a bit - to change the way you handle things now that the entire memory handling is out of your hands), it is simple to use, have a lot of examples and is well documented.
In the 3D department it gives full support for shaders and effects and so - that would be my choice.
Still, C# is not as efficient as C++ and is slower due to overhead, so if it is speed and the flexibility to use any trick in the book you like (with pointers and assembly if you like to get your hands dirty) - stick to C++ and the price would be writing way more code as you mentioned, but having full control over everything including memory management.
I would say the D programming language is a good option. You can link to C object files and interface with C++ code through C libraries. D has garbage collection, inline assembly, and game developers have created bindings to SDL and OpenGL libraries, and are also actively working on new game development apis. I love D. Too bad my job doesn't demand it's use. :(
Like James (hopkin), for me, the hybrid approach is the best solution. Python and C++ is a good choice, but other style like C#/C++ works. All depends of your graphical context. For game, XNA is a good platform (limited to win32), in this case C#/C++ is the best solution. For scientific visualization, Python/C++ is accepted (like vtk's bindings in python). For mobile game JAVA/C++ can works...
If you are targeting Windows, C++/CLI (Microsoft's .NET 'managed' dialect of C++) is an interesting possibility, particularly if you want to leverage your C++ experience. You can mix native code (e.g. calls to C-style libraries) with .NET managed code quite seamlessly, and take advantage of .NET GC and libraries.
As far as concerns about GC impacting 'real time' performance, I think those tend to be overblown. The multi-generational .NET GC is very good at never taking much time to do a collection, unless you are in some kind of critical low-memory situation. I write .NET code that interacts with electronic derivatives exchanges, where time delays == lots of $$$, and we have never had a GC-related issue. A few milliseconds is a long, long time for the GC, but not for a human interacting with a piece of software, even a 'real time' game. If you really need true "real time" performance (for medical devices, process control, etc.) then you can't use Windows anyway - it's just not a real-time OS.
Lot of game engines can fit your need, I suppose. For example, using SDL or Cairo, if portability is needed. Lot of scripting languages (coming in general with easy syntax and garbage collection) have binding to these canvas.
Flash might be another alternative.
I will just point out Processing, which is an open source programming language and environment for people who want to program images, animation, and interactions.
Actually, it is a thin wrapper around Java, making it look like a scripting language: it has a (primitive) IDE when you can type a few lines of code and hit Run without even having to save the file. Actually it wraps the code around a class and adds a main() call, compiles it and run it in a window.
Lot of people use it for real-time exhibitions (VJ and similar).
It has the power and limitations of Java, but adds out of the box a number of nice wrappers (libraries) to simplify access to Java2D, OpenGL, SVG, etc.
Somehow, it has become a model of simple graphics language: there are several applications trying to mimic Processing in other languages, like Ruby, Scala or Python. One of the most impressive is a JavaScript implementation, using the canvas component implemented in Firefox, Safari, Opera, etc.
I vote c++0x. Partial support is already available in gcc-4.3+ using the -std=c++0x flag.
Would 'C' be too obvious an answer?
I have very successfully used C++ for the engine, with the application written in Lua on top. JavaScript is also very practical, now the latest generation of JIT based JS engines are around (tracemonkey, V8 etc).
I think C++ will be with us for a while yet; even Tim Sweeney hasn't actually switched to Haskell (pdf) yet, AFAIK :-)
Java and LWJGL (OpenGL wrapper) has worked well for me. If you're looking for more of a scene graph type library like Orge have a look at jMonkeyEngine which we used to create a google earth type application (see www.skapeworld.com). If you're sensible with object creation the garbage collection is a non issue.
If your target is a PC, I think you can try C#, or embed Lua in your C++ app and run scripts for 'high-level' stuff. However if your target is a console, you must manage your own memory!
Objective-C looks like a good match for your requirements (the latest version with optional GC), although it is too dynamic and Smalltalk-like for my taste.
XNA is your best bet I think. Being supported by the .NET framework you can build for a Windows or Xbox 360 platform by simply changing a setting in Game Studio. Best yet, all the tools are free!
If you decide to go with XNA you can easily get started using their quickstart guide
XNA Quickstart guide
It has been a rewarding and fun experiance for me so far, and a nice break from the memory management of C++.
Garbage collection is a must (as is
the ability to avoid its use when
necessary)
You can't disable a garbage collector temporarily. You would need a deterministic garbage collector then. But such a beast does come with a performance hit also. I think BEA JRockit is such a beast and then you should stick to Java.
Just to comment on your example; typedef is your friend...
typedef std::vector<Thingy> Thingys;
Thingys::const_iterator it = lotsOfThingys.begin()
Don't overlook independent languages in your quest. Emergence BASIC from Ionic Wind Software has a built in DirectX 9 engine, supports OOP and can easily interface with C libraries.
http://www.ionicwind.com
James.
The best enviroment for your project is the one you get your task done in the fastest way possible. This - especially for 3D-graphics - includes libraries.
Depending on the task, you may get away with some minor directx hacking. Then you could use .NET and slimdx. Managed languages tend to be faster to programm and easier to debug.
Perhaps you need a really good 3D-engine? Try Ogre3D or Irrlicht. You need commercial grade quality (one might argue that Ogre3D offers that) - go for Cryengine or Unreal. With Ogre3D and Irrlicht you might uses .NET as well, though the ports are not always up to date and plugins are not as easyly included as in the C++ versions. For Cryengine/Unrealengine you won't have a real choice I guess.
You need it more portable? OpenGL for the rescue - though you might need some wrapper (e.g. SDL).
You need a GUI as well? wxWidgets, QT might be a possiblity.
You already have a toolchain? Your libraries need to be able to handle the file formats.
You want to write a library? C / C++ might be a solution, since most of the world can use C / C++ libraries. Perhaps with the use of COM?
There are still a lot of projects/libraries I did not mention (XNA, Boost, ...) and if you want to create some program that does not only display 3D-graphics, you might have other needs as well (Input, Sound, Network, AI, Database, GUI, ...)
To sum it up: A programming language is a tool to reach a goal. It has to be seen in the context of the task at hand. The task has its own needs and these needs may chose the language for you (e.g. you need a certain library to get a feature that takes long to programm and you can only access the library with language X).
If you need the one-does-nearly-all: try C++/CLI (perhaps in combination with C# for easier syntax).
Good question.
As for the 'making me type far too much', C++0x seems to address most of it
as mentioned:
auto it = lotsOfThingys.begin()) // ... deduce type, just like in *ML
VS2010beta implements this already.
As for the memory management - for efficiency - you will have to keep good track of memory allocations, with or without garbage collection (ie, make memory-pools, re-use allocated object sometimes) anyhow, so that eventually whether your environment is garbage collected or not, matters less. You'll have to explicitly call the gc() as well, to keep the memory from fragmenting.
Having consistent ways to manage memory is important anywhere.
RAII - is a killer feature of C++
Another thing - is that memory is just one resource, you still have to keep track of other resources with a GC, so RIAA.
Anyhow, C# - is a nice alternative in many respects, I find it a very nice language, especially the ability to write functional-style code in it (the cute lambda -> syntax, map/select 'LINQ' syntax etc), thus the possibility to write parallel code; while it's still a 'standard curly-brackets', when you (or your colleagues) need it.
Have a look to Delphi/Pascal Object and some exemples :
http://www.delphigamer.com or http://glscene.cjb.net/
You can look at Ada. There is no garbage collector but this language is oftenly used for real-time system needing high reliability. That means less debuging times for your 3D applications.
And, you can also look at Haskell, if you don't know the functional paradigm this language will look weird to you, but it's worth a bit of your time. Tim Sweeney (EPIC Inc) is considering this language as a C++ alternative.