For those who had developed applications with D,
which libraries did you use to build your application?
those libraries were good documented?
did you use Tango?
do you feel that D is ready to build big applications?
which IDE did you use? Descent maybe?
Note that any C library can be used with D, as D fully supports the C ABI. D has some limited support for C++ libraries, though not C++ template libraries.
I used tango libraries + dfl and a bit of my own.
Tango documentation is excellent. DFL not bad.
Yes I did use tango then but tried phobos at first.
Ready for big apps? depends on what you mean. In production use I have only used it for frontends and updaters.
So far I've only used vim to code and entice to design gui because I couldn't find the right ide for me.
I generally don't work on top of libs (aside from the std lib) as I tend to do very low level stuff, so "none"
I use Phobos, but that's because I'm lazy and that's all that was around when I started.
I'm using it in a commercial app. But we are very much in the early adopter segment.
Descent is really making good progress. However for the stuff I do (very heavy template work) it is not up to the task. However for most things that should not be nearly as much of an issue.
Tango
Yes, albeit a little more examples could be good
Yes
Yes, I think so. But if the programmers are used to full-fledged IDEs (MS Visual Studio), they probably wouldn't like D,
I use a small custom-made Scintilla-based editor, with options to build applications using bud, dsss or dmd.
I use Tango, Jive stacktrace, dconstructor, dunit, and selfmock. I maintain the last three of those, though.
Tango has reasonable documentation. I've run into a few places where it had less documentation than I needed; in these cases, I've made tickets requesting better documentation. Jive doesn't require documentation. I hope the others I use have reasonable documentation; I've been working on that a fair bit.
Yes, I use Tango.
You can create large applications in FORTRAN; D is better. The main issue is library support. Things like cryptography aren't well supported in D, as far as I know. But it's been pretty easy to find everything that I have needed. Anything else, you can probably write a wrapper around an existing library in C without much trouble.
I usually use vim, but now I'm switching to Descent. Its autocompletion is far better than Vim's.
DFL (GUI), Decent (for OpenGL), CUDA (GPGPU)
DFL was decently documented, but lacked cross referencing. Decent/ CUDA are mainly C wrappers, though D made making nice internal API for CUDA very easy.
No, I've been using Phobos
Yes, though there are certain types of big applications which would be much faster to write in another language.
I've been using Code::blocks for my principal IDE and Entice for GUI design.
Other than the core library (in my case, Tango), I'm not using any external libs.
Tango documentation is decent. It's a large library, and I'd say there's documentation for about 80% of it, off the top of my head. And, of those documented classes, I'd say about 80% of them are complete and correct. Given the size of the library, the amount of documentation is impressive. But it's still not quite where it needs to be. In order to really use Tango right now, you have to read the source code (which is clean and well-written).
I don't know whether D is ready for big applications. My application is pretty small, and I'm pretty happy with it. From a language-design perspective, I prefer C# (or Java, to a lesser extent). In comparison, the D language design strikes me as somewhat clunky and awkward. Really, the only reason I chose D for this project was because A) I needed to be able to compile my code to a DLL which could be linked by an arbitrary third party; B) I needed my code to be portable between Win, Lin, and Mac; and C) I didn't want to write in C/C++.
I'm using Descent (an Eclipse IDE plugin). It provides reasonably good syntax highlighting and project navigation. Auto-complete still leaves much to be desired, and the integration with a "builder" like dsss is still lacking. But it's better than notepad :)
Mainly those I develop myself - SDWF and Stewart's Utility Library.
I hope so.
No.
Yes, though I'm not sure that libraries and IDE support are quite ready yet. And D isn't quite ready for significant third-party implementation, which might play a part in reaching this stage.
I do most of my editing in TextPad. Which admittedly isn't fully compatible with D (two missing syntax highlighting features, and doesn't support Unicode), but it works.
Code blocks seems to support D.
Related
Greetings,
I am trying to decide between C and C++ for my robot. I am a 5+ year veteran of Visual Basic.NET, however I'm going with Linux (Ubuntu) on this robot, and there is a compatibility problem between Linux and the .NET Framework. I want to stick with whichever language I choose for all of my projects, so I want to make sure that I choose the most appropriate one for the task.
For reference, I will describe my current robot in progress and what I am going to do with it. I am in the process of building a full-sized R4 Astromech (yep, I'm one of those guys). I have incorporated a PC motherboard with an Intel Core 2 2.1 GHz processor, 1 GB RAM. I will be using a scratch-built parallel interface card to control the drive motors, head motor, as well as a secondary parallel interface card (going to a second parallel port) which all of the sensors (IR, Ultrasonic Ranging, Visual Recognition via webcam, etc.) will be going to. Commands will be given using speech recognition (currently have a VB.NET scratch-built recognition program that I will be adapting to the new language).
Given the specifications and desired goals listed above, would I be better off with C or C++? I greatly appreciate any suggestions that you might have.
Thanks!
Thaskalas
What do you mean by a compatibility problem? Have you looked at Mono? It's an open-source implementation of the .NET libraries. It's geared toward C# not VB.NET but if you're more comfortable in a .NET environment use that. Speed isn't really an issue here as a Core2Duo is plenty fast for what you need to do.
If Mono won't work for you, I'd recommend C++. There are a lot more libraries out there for C++ (or at least, I am familiar with more, e.g. Boost), which can use most C libraries too. There's no real speed penalty for using C++. While using C wouldn't be bad per-se, C++ has some benefits and no drawbacks, so it's probably the better choice.
I would recommend using ROS. It will let you get started with a sophisticated Inter-Process Communications manager, as well as a large library of sophisticated robotics code, including multiple implementations of SLAM and other critical robotics algorithms. ROS also lets you program in multiple languages, including C, C++, and Python, so you aren't stuck with one language or another down the road.
I would also recommend C++ and ROS. In our company we're migrating to it, because there's so many people working on it, expanding it, and adding lots of cool features.
With this, you can forget about implementing most of the basic low-level stuff and start working on what you intend to research.
It's really easy to set up and start developing.
Since you're running Linux on it, I'd recommend a split approach, where you do the lower-level (device interface, where you may need fast performance) stuff in C (or C++), and the higher level stuff in a modern language like C# (using Mono) or Java, or even Python.
Python especially is hugely expressive, has a large set of libraries, and has a pretty straightforward C interface.
Writing your high-level control stuff in a low-level language like C/C++ will get old fast (IMHO). Robots should be fun!
Have you considered D? It's a fairly new language, is compiled to native code and can link directly to C. (The entire C standard library is even available from D, and bindings to the POSIX API are included in the standard library.) Basically all you need to do to use any C library from D is compile it with a C compiler and translate the function prototypes, constant declarations, etc. in the header file.
D is low-level enough that an experimental kernel is written in it, but has modern features like garbage collection (though manual memory management is still permitted), builtin strings and arrays, and more advanced/easier to use template metaprogramming facilities than C++. The biggest disadvantage is lack of a mature toolchain and libraries for enterprise-y things, but for your purposes that probably doesn't matter. BTW, if you need to do a bunch of matrix manipulation and stuff, there's the SciD project, which provides nice templated wrappers over LAPACK and BLAS.
Use C++. You have the space. You can use it "as a better C" to start with.
C++ is a bigger tool bag; why would you not want that!? You need not use all the tools, but with C you'd have no choice. Most importantly with C++ you have the choice of using both C and C++ third-party libraries.
I am familiar with QT/gtk+ libs under linux. I've just roughly had a look at available c++ frameworks like Reason and Platinum. Does anyone have any experience working with any of them? Are they any good, should I consider learning them? I am not a big fan of frameworks though.
Keep using Qt or gtk+.
They're very good, and you already know them.
I am not a fan of frameworks either, which is maybe why I haven't heard of those you mention. Having said that, check out POCO. Looks much better than Qt or gtk+ to me if you don't need GUI.
I worked on a project that had to run on multiple platforms (Linux, Windows, Windows CE). We used WxWidgets for the UI. The libraries and the tools weren't perfect. But it compiled and ran on all the platforms without any issues.
The platform is completely open source, so you have the benefits therein.
In the end, I was glad we used it as apposed to porting the UI layer multiple times.
boost asio: the framework for those who are not framework fans ;-). (and this question still lacked a boost answer)
I've started working a little bit with Platinum C++. The documentation is really lacking. That said, you can get some things off the ground relatively quickly. What I worry about is investing deeper into it and finding bugs without support or that it gets dropped as a project (or never really adopted) -- it is version 1.0.0.4
I sounds like you are practiced in keeping the general application mechanics independent and abstracted from one another. It may be worth writing your own small 'framework' and plugging in functionality from other projects with a small wrapper - particularly boost, as mentioned above. This is the direction I am going.
STL/Boost cover all the low level stuff.
But what about the higher level concepts?
Windows: We have multiple windowing libs
KDE(Qt)
Gnome
Motif(C but written in OO style)
MS Windows
etc
But is anybody working on a unified standard for windowing?
Something that wrapped all the above would be acceptable. (even if it only accessed the common stuff it would be a starting point).
Networking:
There are a couple out there (including the Boost low level stuff).
But is there anybody working on a Service based network layer?
All the other stuff that Java/C# have in their standard libraries.
The stuff that makes it simpler for a beginner to jump in and say Wow done and it works everywhere (nearly).
Anyway. Here hoping there are some cool projects out there.
Edit
Maybe there is not one.
But if there are a couple that could be bundled together as a starting point (and potentially modified over time (where is that deprecated keyword)) into a nice consolidated whole.
Note: Windows is just a small part of what I am looking for. The Java/C# languages consolidate a lot more under the hood than just the GUI. What would be a good set of libraries to get all the functionality in one place.
There are too big differences between platforms to get a definitive C++ standard for GUI programming. I think Qt is about as close as you will get in the forseeable future. wxWidgets is another popular choise, but as I understand it, they are using less modern c++ features.
As for networking, I think you are being kind of vague. If you mean web services over HTTP, I would have a look at Pion.
Well it is almost 2010 and C++ almost has threads.
I'll probably get slammed for this but C++ moves too slow - to its own detriment and its user base. I readily acknowledge the difficulty of the technical and political issues involved but that's still the dirty reality of it. The language can't build in higher level concepts when it takes 5-10 years to agree on and implement the building blocks.
The reasons for this have endlessly debated but the sad truth is that C++ has relegated itself to a niche language. I like C++ but I look at the progress C#, Java, and even Python and Ruby have made over the last 5 years and I increasingly question whether C++ is worth the effort.
The Poco C++ project aims to deliver all that you ask, except for Windowing:
The POCO C++ Libraries aim to be for
network-centric, cross-platform C++
software development what Apple's
Cocoa is for Mac development, or Ruby
on Rails is for Web development — a
powerful, yet easy to use platform to
build your applications upon.
Qt might be the only framework complete enough to be what you suggest.
I guess there's some kind of keyword lookup driving the advertising here because I'm seeing a REALbasic ad, which is what I generally use for cross-platform GUI's nowadays.
I have spent a lot of time over the last 15 years working in C++ GUI's including retailing my own portability layer for CodeWarrior PowerPlant and working on the two Macintosh-based GUI code generators, including adding Windows generation to AppMaker. I've worked with wxWidgets, mainly wxPython. So, my opinion on difficulties in cross-platform GUI is fairly well-qualified :-)
Cross-platform GUI frameworks are hard to the point of nearly impossible without significant compromise - the issues come down to subtle matters of behavior which generally bother users at a level where some of them can't quantify but know that the application doesn't feel right. This is a lot harder to fix than just rendering native controls.
I started using REALbasic because their framework does a better job of getting the feel right than anything else I'd tried (I didn't get into Qt because of the expensive commercial license).
The reason it has taken so long for things to evolve is nothing to do with the C++ world moving slowly, it's just an intractable problem. The very best cross-platform Java apps do some stuff conditionally for OS/X and it is still screamingly obvious to an experienced user that they are not a native Mac app, although some are very usable and come pretty close to looking native - Oxygen XML editor and DeltaWalker are two of my favourites.
I don't think it is achievable to make a really comprehensive portable GUI library. Operating systems are just too different. Can you imagine a GUI library that would cover everything from iPhone to Windows 7 and wouldn't feel wierd on any of them?
A Boost gui library comes up occasionally.
The general opinion seems to be that the problems is too wide (are you targeting cellphones, FPS games or CAD workstations) and that it is too much work - Qt/wxWidgets has taken 10years.
see http://lists.boost.org/Archives/boost/2005/09/94453.php for a discussion.
It would have been nice because GUI usually means cross platform and threads, so all the GUI toolkits have invented their own cross platform,filesystem and thread classes. On the other hand if a standard GUI had been introduced in C++ it would probably look like TK !
What's so great about standardization ? Sure, if novice coders want to download one SDK to build portable apps, let them download Qt (or something similar) and forever remain within it's fine walled environment. But it'd be a tragedy if the C++ world revolved around that one library and boost and POCO and wxWidgets and clutter and blitz++ and eigen and and 101 other wonderful things (yes, gtkmm and ACE even) were stifled at birth because the gatekeepers of The Standard Library didn't see fit to admit them.
Diversity is good I think (although when dealing with it, it helps to have a good package manager; I've spent hours setting up build dependencies on Windows which just needed a few seconds of apt-getting on Debian).
ACE is great for concurrent communication and networking.
For cross platform windowing, there's wxWidgets. (formerly wxWindows).
Only everybody and his brother, but hardly any of them actually get anywhere.
I am writing a small C++ program for fun and for extending my C++ skill. Since its scope is relatively small, I also planning to try out cross-platform development by making this program support both Windows and Linux.
I reckon my C++ proficiency is sitting somewhere between casual and intermediate level: OO, a bit of templates and design patterns, used STL before and trying to look into it more in details, ... However, while coding this little program, I find that the deeper I dig into C++, the more pain I feel, especially when I come to understanding and dealing with differences between different platform's/vendor's implementation.
The use of cross-platform frameworks like Qt, ACE, Boost seems help to speed up development a lot thus make life easier, but I worry if this will beat my purpose. Can somebody give some advice if there is any "best practice" for doing C++ cross-platform development? Thanks.
Can somebody give some advice if there is any "best practice" for doing C++ cross-platform development?
There are three things:
Write your own code so that it's portable
Wrap platform-specific APIs behind an abstraction/insulation/utility layer
Choose cross-platform libraries
You can choose option #2 and/or #3.
Advantages of #3 over #2 tend to be things like, "It's already written, debugged, and supported"; and the disadvantages are like, "I have to learn it, I might have to pay for it, I can't necessarily support it myself, and it may not do exactly what I want."
Developers will often prefer option #3 instead of #2, especially if it's free open source (which all three of the libraries that you cited are).
http://blog.backblaze.com/2008/12/15/10-rules-for-how-to-write-cross-platform-code/
Should provide more detail to the answers already given.
Also I suggest using existing libraries that abstract endianness, data type sizes and differences. The following should be considered before starting your cross-platform project.
GUI
Qt
XVT
wxWidgets
General Libraries/frameworks
STL (Incorporated in most platform libraries already)
Boost
Game Development
SDL
Cocos2d-x
Use gcc. It's available on both Windows and Linux and the libraries and language syntax is identical on both platforms.
For cross platform GUI applications, Qt is a good idea. There is no getting away from having a dependency on a GUI framework if you are trying to achieve platform independence.
Unless you are doing GUI stuff cross platform isn't a big problem.
There are some small issues to do with filesystems ( different / \ separators, allowed characters in filenames etc) but these are at the application level rather than the c++.
Doing major applications gets more complex, you need to handle help, file locations an possibly security and user info in a cross platform way. For simple algorithm type programming there isn't a problem.
Qt is mainly a GUI library, although it has extra cross platform filesystems stuff. STL, Boost, ACE are cross platform but that isn't there main point.
Use them! Seriously. The only reason you may not want to use them is if you plan on working in an environment where they're not available. But, given their cross-platform nature, that's not likely.
You will find that the benefit you get from using them is immense, even if they weren't cross-platform. The "best practice" you speak of is to be able to deliver your "product" as quicly and easily as possible.
I once answered a question from someone who stated he didn't want to use GUI libraries at a level above Xlib. If he'd actually ever used Xlib, he'd know the pain we'd all felt when forced to code at such a low level of abstraction. This makes about as much sense as wanting to code in assembler because C/C++?Python/Perl/everthting-else is simply a higher-level abstarction.
this answers are really good and you can make a list for find where is the beginning. but i think you should read some articles about "porting application".not relevant with cross-platform development but this can give you very large perspective about cross platform development. In cross-platform developing, one of more importing thing is memory issues like "endian" (byte order- byte order can show differences for tehnologies or platforms)
use boost. they take care of cross-platform stuff for you.
boost::filesystem is a great example
i think you can learn a lot from using ACE or equivalent libraries. they will boost your understanding of c++ and design patterns. i think this is the best thing you can do to improve your coding skills.
If your are really interested in making your code as cross-platform as possible, use as many compilers as possible. If you are using Windows and Linux, use VC and gcc, at the minimum. This will ensure that you don't use complier specific features, and that you don't rely on system specific behavior. Use more compilers (Intel, IBM, etc) and OSs (OS X, Solaris) if you have access to them.
You can try using U++ > http://www.ultimatepp.org/index.html
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.