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 11 years ago.
C++ was the first programming language I really got into, but the majority of my work on it was academic or for game programming. Most of the programming jobs where I live require Java or .NET programmers and I have a fairly good idea of what technologies they require aside from the basic language. For example, a Java programmer might be required to know EJB, Servlets, Hibernate, Spring, and other technologies, libraries, and frameworks.
I'm not sure about C++, however. In real life situations, for general business programming, what are C++ programmers required to know beyond the language features? Stuff like Win32 API, certain libraries, frameworks, technologies, tools, etc.
Edit: I was thinking of the standard library as well when I said basic language, sorry if it was wrong or not clear. I was wondering if there are any more specific domain requirements similar to all the technologies Java or .NET programmers might be required to learn as apposed to what C++ programmers need to know in general. I do agree that the standard library and Boost are essential, but is there anything beyond that or is it different for every company/project/domain?
As for every language, I believe there are three interconnected levels of knowledge :
Master your language. Every programmer should (do what it takes to) master the syntax. Good references to achieve this are :
The C++ Programming Language by Bjarne Stroustrup.
Effective C++ series by Scott Meyers.
Know your libraries extensively.
STL is definitely a must as it has been included in the C++ Standard Library, so knowing it is very close to point 1 : you have to master it.
Knowing boost can be very interesting, as a multi-platform and generic library.
Know the libraries you are supposed to work with, whether it is Win32 API, OCCI, XPCOM or UNO (just a few examples here). No need to know a database library if you develop purely graphic components...
Develop your knowledge of patterns. Cannot avoid Design Patterns: Elements of Reusable Object-Oriented Software here...
So, my answer to your updated question would be : know your language, know your platform, know your domain. I think there is enough work by itself here, especially in C++. It's an evergoing work that should never be overlooked.
C++ developer have to grok std and boost libraries.
List of other technologies largely depends on project type. For sure you will have some interaction with SO, so you will need to know API of your environment.
As for data-access and other stuffs there are tons for different solutions. C++ is much richer than some managed langs in that sense. 99% of old popular systems have C/C++ interface.
After you clarified your question a bit in the comment to my answer I can recommend:
Good code browser (SourceInsight or Understand For C++ for example)
Static analysis tools (Link, KlockWork Inforce, etc.)
MySQL\SQLite (I encountered these DB in a huge number of C++ projects)
UI technologies (OpenGL\GLUT, DirectX, GDI, Qt, etc)
technologies you should know as a C++ programmer (and therefore more technically knowledgeable than lesser programmers ;) ):
performance issues - what makes things go slow, how to find and fix such issues. I also mean stuff like context switching, cache lines, optimised searches, memory usage and constraints, and similar stuff that your average VB/C# developer doesn't care about.
threading issues - how to get the most from a multi-threaded app, how to detect and fix abuses of the same.
low-level communications - especially being able to connect to obscure systems that no-one else has written a toolkit for (especially radio comms), latency and bandwidth management.
Otherwise, for specific tools - it depends on what you're targeting, Windows dev will be different to Linux, different to embedded.
This will largely depend on the used platform and other constraints. As a general rule, a good (C++) programmer is (or should be) able to learn a platform-specific API in a very short time. For C++, it's much more important to understand the different tool chains (e.g. a Windows programmer should also know the GCC tool chain) and differences in compilers. Programmer should also understand limitations and platform-dependend behaviour of the language.
As for libraries, C++ programmers absolutely need to know STL and Boost. No discussion.
Standard Template Library
http://en.wikipedia.org/wiki/Standard_Template_Library
Besides the stuff everyone listed, keep in mind that C++ programmer have space on the embedded systems market (much more than most other high level languages).So familiarity with embedded systems and development may open a lot of doors and job opportunities where you will not be competing so heavily with Java development for example. So learning to code compact code (compact after compiled) and low memory usage techniques is a good bet.
if you're using gcc you should definitely know gdb. Actually, you should be proficient with the local debugger for whichever compiler you're using. Other than that there is such a wide range of libraries used that being able to quickly pick up an API is more useful than any specific one. I would suggest learning doxygen though.
If you are using linux then Valgrind is a very usefull tool for checking how your program deals with memory access.
In no specific order
COM/ATL
DirectX
MFC & Win32
STL
GDI
BOOST
The popular way to use C++ in the mobile space would involve learning Symbian OS development.
http://developer.symbian.com
Related
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.
I have the book "Write Portable Code" which details POSH, an open-source "framework" (mostly just a header) to help with portability of C/C++ code between different platforms and hardware.
Since Poshlib hasn't had an update in 5 years now, I was wondering what other similar libraries/frameworks exist out there?
For C code, GLib is a modern cross-platform (non-GUI) library which makes it easy to write applications that run on many different platforms without source code changes. GLib is actively developed in an open manner as part of the GNOME project with lots of open source projects using it.
For C++ I would suggest looking at the Boost libraries.
Dear Shaggy Frog,
While I remain largely incurious about your handle, I must say that this is something of a hairy issue. Here's why. I work with the boost libraries day in and day out. They're fantastic, and make innumerable tasks way easier. But I must emphasis that if you use them, you need to use a profiler. Some of the really nice portions of it tend to be a bit slow, and you should definitely read up on best-practices before using certain parts like, say, transform iterators. Boost, though, is worth mentioning because it does make an effort to supply some pretty powerful pieces of abstraction that are almost foreign in the ++cverse.
However, Boost, and other frameworks like it, are not snakeoil. They rock. People who rock use them. People who rock work on them. For more specialized tasks, I'd need to know more about your problem domain. However, one other tool that's really excellent is SWIG, which will let you bundle up any hunk of portable C code into a library that's... well.... accessible.
As for bloat, a lot of that is going to go away when C++0x moves to the standard, thanks to variadic templates, and a number of similar pieces of cleverness. Honestly, I'm tired of people yelling about The Terrors Of Templates. Perhaps six years ago they were a danger due to poor compiler support, but these days, they're part of the language. They live under almost every piece of generic code you touch. Projects like CLang are hammering the very last nails into this coffin as we speak. They aren't a fad anymore. They aren't a magical solution. No one still thinks that. No one you should hire, anyway.
The future approaches. Do you need a Boost?
Most libraries with the buzzwords "portability framework" or "portable runtime" in their names are useless bloat and snake oil. If you want to write portable code, start with the relevant standards and follow them. Instead of reading your vendor's man pages or help files for standard library functions, read the ISO C or C++ standard or POSIX standard. And so on.
Aside from highly crippled embedded systems (note: many/most embedded systems do not fall into the "highly crippled" category) and DSPs, pretty much any environment can be made to be POSIX conformant. A much better approach than trying to design or find a new "portability framework" on top of diverse and incompatible underlying systems is to evaluate what parts of POSIX you need to get the job done, what parts might be missing or non-conformant on systems you're interested in, and whether there are drop-in replacements or workarounds for the missing or broken functionality.
For most people, the only relevant non-POSIX system is Windows. Cygwin is one heavy-weight option for making Windows conform to POSIX, but if you code to a more-inclusive subset of POSIX, you can get by with much lighter solutions and still support Windows.
There is similar Predef project on sourceforge, but it are not updated for several years also.
FWIW, the predef pages are actively maintained and have been continuously updated over the last several years.
Aside from Boost, which all C++ programmers should be familiar with, there are several libraries worth looking at. STLSoft is the first one that comes to my mind.
I have prepared a list of some prominent portability libraries for C and C++ on my personal web site. One can freely reuse it under the terms of the Creative Commons Attribution Licence. I had some experience with Qt, GLib, and the Apache Portable Runtime, and they all seemed to have been mostly OK.
There is also another list on the wikipedia.
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 12 years ago.
I would like to know the advantages and disadvantages between C++ and VB6. The reason I am asking is because I came across a website where they have source code for various programs that are coded for Windows machines, and they are almost all coded in VB6.
However, I do not know a lot about VB6, and am trying to learn C++ at the moment, and I was wondering why people would code in VB6 instead of C++ or how they rank in different areas.
So I would appreciate it if someone could weigh the pros and cons of each language and really give me perspective of the languages.
-Oswald.
I was wondering why people would code
in VB6 instead of C++ or how they rank
in different areas.
VB6 is a dead language. It was a Microsoft proprietary language.The VB6 IDE is no longer supported but VB6 applications are supported for at least the lifetime of Windows 8. Most (with many changes) of the syntax lives on in VB.NET (another proprietary language). In addition to the syntax, VB.NET and VB6 share the idea of "canned programming", where the developer just combines existing building blocks to create small applications very easily. VB6 introduced a large number of innovative techniques for this. It became known as RAD, Rapid Application Development or Rabid Application Development, depending on who you ask.
The problem with RAD, that it doesn't scale…
Probably you looked at a very old web site.
C++ is a general programming language standardized by ISO. There are also a great many other general programming languages, and many of them are also standardized. In addition there are general programming languages like Java that are not standardized by some international standards organization, but have sufficient heavy backing that it's almost as if they are open languages, in spite of being technically proprietary.
Going into more details comparing the languages serves no useful purpose.
You might read up on the old C versus Pascal debates to see why (these debates got pretty heated, so called language wars, but resulted in some classic papers such as Brian Kernighan's "Why Pascal is not my favorite language").
VB6 is antiquated -- the only reason people would code in it these days is if their company had business reasons for not upgrading to something newer (like a large legacy code-base written in VB6). Even then, you'd expect them to be looking to move on.
VB6 has been obsolete for quite some time now and superseded by VB.NET. C++ and Visual Basic have way too many differences to list here, but if you want to learn C++, it doesn't help much to learn from VB examples. There are plenty of books, tutorials and examples for C++ - in all likelihood, much more than what you would find for VB - so that's what you should be looking for.
I am learning C++, but only after Python and Java.
It is not suggested to learn C++ as a first language (that's what I got online).
I am interested in getting deeper in low-level programming an OSs so C/C++ is what I am aiming for right now.
I would say learn C++
One reason VB may still be used is that in some companies (such as the one I worked for) we required financial analysts who were good at understand the math behind the business AND be able to produce applications that solved business problems. It turned out (as others have pointed out above) that it was easier for us to hire folks with good functional business knowledge and then get them up-to-speed with VB than C++ or VC++, the latter two being the exclusive domain of the IT-department developers.
Basically if you are looking for low-level coding that offers more speed then go with C++, however if you are new to programming I wouldn't recommend it. However, there is much more overhead with C++ and coding can take more time. C++ also allows you to be object oriented if you so choose, but it does not force the paradigm.
Visual Basic is a high-level language and is pretty well noob friendly but is slower than C++. Visual Basic has less overhead meaning you can code a lot quicker once you get the hang of it. I'm not sure if VB is object oriented but I don't believe so.
C++ is a lower-level languagge, thus programs will perform better... everywhere, period.
VB6 is a higher-level languagge, so it'd probably be easrier to learn. Actually it would depend on your previous skills, if you know java you'll have a hard time understanding VB6.
A friend of mine once said, if you know english you can write VB6 :)
Plus, VB6 is no object-oriented, while C++ is
VB6 has since been superseded by VB.net. VB was and continues to be very "newbie" friendly. VB was easier(depends on what and whom you ask) to code in, whereas C++ allowed access to certain components not available in VB6. C++ was also significantly faster than VB6, though those type of speed differences don't matter much any more.
There are certain sites which continue to host/advocate vb6 code. VB6 support will be completely dropped after Windows 7.
So the main difference is that VB6 is a slower, (becoming unsupported), proprietary language that is easier to learn for programming beginners. C++ is a standardized, supported language that's quite a bit harder to learn, though its faster/more efficient.
For starters, I'd recommend a Basic dialect, be it Microsoft Small Basic (this is a newb's language), VB.net, FreeBasic, RealBasic, Auto-it or maybe even PowerBasic.
Hope this helps.
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 12 years ago.
I want to go into native c++ programming after University, but it seems like languages that compile with JIT (like .Net) are overtaking c++. What does the future hold for Native code?
C++ is the seventh programming language I have been professionally paid to program in, and I'm sure won't be the last. My advice is not to think of yourself as a specific language programmer. Even if JIT takes over the world, it has to get down to native machine code eventually, and someone has to write that software.
There are a lot of opportunities to work on natively compiled C++ code. It's especially popular (along with C) in non-PC environments such as embedded and real time environments, and in a lot of situations where there is some level of safety certification required.
Game programming, where performance is usually critical, is another area where C++ is very popular.
It is less popular than it was in traditional 'desktop' applications and web service applications although you can find native code projects in both these areas - especially the former - if you hunt around.
I'm not sure what you mean when you say that you will be "going into native C++ after college". Your career will not be defined by what languages you know, it will be defined by what you can do with those languages.
However, C++ is used widely in many applications. I work in systems and we use C++ for everything. .NET isn't an option in my world, but the guys doing the GIU's next door use it for everything. It comes down to what you want to do with your career. The language you use will come naturally, you are thinking about it backwards.
There will always be a place for C/C++
Any application that needs to be as
fast as possible will be written in
a native language like C/C++
Any application that runs on a device that has limited memory
will
run better in C/C++ since memory
management is more deterministic.
Operating systems will continue to be written in C. That
include
device drivers.
Up until recently one always had the luxury of speeding an application up by using better hardware. Will Moore's law being stretched to the limit, chances are the performance improvements will have to come from software. Chances are that languages that give better performance will come into their own in this regard.
If you go desktop C++ is still the way to go especially if you want to be cross platform.
Java GUI Libraries are way to slow and .NET is not portable (the GUI part).
But C++ is a language beast, the only language where i can understand managers to ask for 5 years experience.
In the server world the VM/JIT has so many advantages that only basic infrastructure is coded native. If this is the industry you want to join learn (infrastructure) or don't learn (applications) C++.
Its also pretty popular in embedded programming where you can't fire up a hundert MB virtual machine.
Since C/C++ is the only fast imperative native programming language left in mainstream you should learn at least the basics.
Yes, of course it is:
http://www.tiobe.com/index.php/content/paperinfo/tpci/index.html
http://langpop.com/
And some of the great features like rvalue-references, variadic templates, uniform initializations, lambdas, unrestricted unions, thread-local storage, extern templates and ... yet keeps C++ to be a good choice for 20 years of the future, until the C++ committee decides to publish another new standard for the other remaining years (like a do...while!) (:
Note that the computers needs native programs to run! Java, .NET, python and ... needs native environment to run on it! so, native programs are the base of softwares.
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.
Will learning C++ help me build native applications with good speed? Will it help me as a programmer, and what are the other benefits?
The reason why I want to learn C++ is because I'm disappointed with the UI performances of applications built on top of JVM and .NET. They feel slow, and start slow too. Of course, a really bad programmer can create a slower and sluggish application using C++ too, but I'm not considering that case.
One of my favorite Windows utility application is Launchy. And in the Readme.pdf file, the author of the program wrote this:
0.6 This is the first C++ release. As I became frustrated with C#’s large
.NET framework requirements and users
lack of desire to install it, I
decided to switch back to the faster
language.
I totally agree with the author of Launchy about the .NET framework requirement or even a JRE requirement for desktop applications. Let alone the specific version of them. And some of the best and my favorite desktop applications don't need .NET or Java to run. They just run after installing. Are they mostly built using C++? Is C++ the only option for good and fast GUI based applications?
And, I'm also very interested in hearing the other benefits of learning C++.
yep, C++ is absolutely great. Check Qt. It has a great Python binding too, so you can easily prototype in Python, and when/if you need extra performance, porting to C++ is a mostly 1:1 translation.
But in fact, writing C++ isn't so hard either when you have a great platform, the worst part is writing all the class declarations :-)
If you want to build Windows applications that will run without frameworks such as .NET or virtual machines/interpreters, then your only really viable choices are going to be Visual Basic or C/C++
I've written some small Windows apps before in C++ code, and there is definitely a benefit in terms of speed and ease of deployment, at the expense of difficulty going up for development. C++ can be very fast, natively compiles, has many modern language features, and wide support. The trade off is that it's likely that you'll need to write more code in certain situations, or seek out libraries like Boost that provide the functionality you're after.
As a programmer, working in C++ and especially in C is good experience for helping you understand something just a tad closer to the machine than say, .NET, Java or a scripting language like VBScript, Python, Perl etc. It won't necessarily make you a better programmer, but if you are open to learning new lessons from it you may find that it helps you gain a new perspective on software. After all, most of the frameworks and systems you depend on are written in pure C, so it will never hurt you to understand the foundations. C++ is a different animal from straight C, but if you develop in C++ for Windows you'll likely find yourself working in a mix of C and C++ to work with Windows APIs, so it will have a trickle-down effect.
I wrote C++ windows apps for 10 years and switched to c# about 2 years ago to work on the latest product. I am embarrassed by how pathetic the C# app is. It takes 20 seconds to start up, you have to wait a second or so for it to switch between screens. I've used some third party GUI control library, and that leaks memory like a sieve! My app runs at 150 meg, and its doing hardly anything.
I am looking to go back to C++.
You can use MFC, it will be far quicker than .Net. Or, if you really want to burn, check out WTL - aLthough, there's not much documentation for that. I suggest you go with either MFC or Qt because you'll find plenty of good information and tutorials for them.
I can see that C# can be quicker to develop with, and maybe in some future version it will be quicker and smaller.
You will hate my answer:
The biggest bottlenecks in GUI development usually are not because of the language. After all most of the time in most applications the UI is idling, waiting for some user input. I can hear your screams already, but I said in most of the apps.
Let's put it this way: I am pretty sure that one can design a good UI on top of the .Net CLR. Learning C++ is a good thing, but will not solve the inherent problems of developing a good UI.
As always. It depends.
As long as you stay away from microsofts large Frameworks, as MFC, .net etc your applications can be blazing fast, but hard to code. Your benefit: You will really learn how windows is working behind its nice(?)surface. Just look into the initialisation code for COM-Objects and you know what I mean. You will never see such things in VB or C#
You have to program each button, each window and each control by yourself, sending silly window messages, however your applications are small, very small. This is an forgotten art:
Write small, fast programs
Good luck!
If you're committed to learning the raw, gritty details of Win32, then C++ will get you there. If you're not, then you'll end up using a bunch of wrappers anyway. For something like a small utility or especially something like a shell extension (where trying to use .NET will cause you problems anyway), C++ will let you write effective code with the absolute minimum in external dependencies. For a larger app, YMMV - a lot of the UI sluggishness out there comes from poor design: naive algorithms, an unwillingness to spin off non-trivial operations onto separate thread(s), reliance on badly-written 3rd-party components instead of custom controls... Mistakes easily made in any language.
Here is my honest answer to this.
First, I think every programmer should learn C/C++ just for the fact that by learning C++ you learn about programming. It is a systems-level language. You have to consider the finer details of memory management and so forth. I am shocked at how many programmers do not understand the foundational aspects of a programming language or computer system. By learning C/C++, you force yourself to understand programming at a more intimate level. On top of that, if you learn how to program in C/C++, you can program in almost anything.
That isn't to say C/C++ is always the right tool for the job. It can be a total pain to debug and take longer to write more meaningful code. However, it is perfect for those situations where you need absolute control of how a program executes.
This goes to say, I don't prefer C/C++ for UI programming. You still have to use a windowing framework specific to the OS you run on (MFC,Win32,Motif,GTK,QT,etc.). These frameworks don't lend themselves to easy learning curves. For at least Windows development, .NET is really the future of UI development (even though surprisingly MFC got a major overhaul for Vista that does stuff .NET doesn't even do yet). If you write your UI in .NET, it is easier to maintain and for others to maintain.
I typically write my UI in .NET and backend in C++.
Yes and no. It's all about optimization...And since C++ allows you to work on a lower level C++ is one of the best languages to write fast applications.
However those low-level mechanics implemented in C++ could be very annoying if you're used to more abstract approaches to OOP.
Testing your software in C++ is usually a long process.
If you are looking for speed anyway, C++ would definitely be one of the best choices.
C++ will indeed potentially get you a leaner, meaner and faster application (if you do it right).
However, the .NET framework is built for comfort from a developer point of view; a vast improvement over Win32 API or MFC, which may seem like hard work in comparison, So consider how you will implement the aspects for which your application depends on .NET (there are other frameworks available that may be easier than MFC or Win32 API), and also consider the costs and license issues of using such frameworks; for example the free VC++ Express Edition for example does not include MFC support.
If you know where you application is sluggish, C++/CLI may be a solution; allowing you to mix managed and native code to accelerate the parts that need it. However if it is the GUI that is intrinsically slow rather than the application processing; this may not be a useful path.
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.