Recent Features
| |||||||||||||
lambda functionslambda functionsPosted Dec 9, 2005 21:25 UTC (Fri) by dvdeug (subscriber, #10998)In reply to: lambda functions by ncm Parent article: The Boost C++ Libraries
Writing an application as quickly as possible is not an easy job, yet it's one that Visual Basic makes easy. Solving complex problems of logical inference is not an easy job, but it's one that PROLOG and similar logical languages make easy. Writing an expandable editor like EMACS is not easy, but it's one that LISP makes easier. Writing a webpage generator isn't that hard, but it's a lot easier in Perl than C++.
C++ has less range than Common Lisp. If you demand that all core language features "map to a machine instruction or two", what more can you expect?
It's seriously absurd to dismiss all problems besides "industrial" problems as easy. There's no challenge to writing a paycheck generator. There's challenge to writing code to control a 757 (code written in Ada, BTW), but it's not in the range; it's in getting things done, always exactly correct, on a very tight time schedule.
A game is not a trivial thing; it's funny that many game programmers either refuse to use C++ for speed reasons, or use scripting languages to control much of the game's actions. Obviously, C++ doesn't provide the right range for them.
(Log in to post comments)
C++ Game development Posted Dec 10, 2005 6:03 UTC (Sat) by mvogt (guest, #34379) [Link] I disagree with your assertion that C++ is not used for games for performance reasons. I think commercial games are very often written in C++.
If you look at sourceforge, two categories I sampled as having high-performance requirements (simulations and first-person shooters) have more than half of their listed projects listed with C++ as a development language.
C++ can be used with almost no abstraction penalty over C, depending on what features you choose to employ. There is a good document establishing the efficiency costs of various C++ features available at http://www.research.att.com/~bs/Performance-TR.pdf
I agree that many games have a component written in scripting languages; I think that this is probably a reflection of the rapid time-to-market pressure in the game market as much as anything else.
C++ Game development Posted Dec 10, 2005 7:32 UTC (Sat) by dvdeug (subscriber, #10998) [Link] But rapid time-to-market is something that makes a problem hard, and there's no reason to dismiss languages that are ideal for solving such hard problems as unworthy of study.
C++ Game development Posted Dec 10, 2005 8:22 UTC (Sat) by mvogt (guest, #34379) [Link] Of course such languages should not be dismissed, but nor should they be espoused for tasks they're not designed for.
Ideally, C++ can be used together with a language designed for embedding (such as Lua) for game development.
That said, games are an unusual domain, where even correctness can be less important than performance or speed-to-market.
C++ Game development Posted Dec 10, 2005 8:53 UTC (Sat) by dvdeug (subscriber, #10998) [Link] Since when is correctness taking second place to performance and speed-to-market unusual? C++ itself puts correctness second to performance in relegating bounded arrays to the library. If you put correctness first, you would use the SPARK programming language, or something similar, and never release unless every possible test has been passed. But in reality, virtually every program releases with known bugs, frequently major ones. Jon Bentley mentions in one of the Programming Pearls books that given a 10x speed improvement on his typesetting system or all the bugs fixed, that he would have taken the speed up. If you (believably) made the offer on the GCC list, I suspect the list would blow up in a flame war over the issue.
C++ Game development Posted Dec 10, 2005 22:05 UTC (Sat) by mvogt (guest, #34379) [Link] Fair enough, there are obviously application domains where approximations are acceptable, and those where they are not. What would be the point of a 'grep' that returned most matches, or a 'find' with false positives?
C++ does not put correctness second to performance, it ensures that you needn't pay for what you don't use. (Ignoring legacy C built-in arrays,) if you can guarantee array bounds will not be violated you can use the subscript operator for unchecked access; you can use the 'at' member function to get runtime checking where desirable. 'Relegating... to the library' has been the favoured C++ evolution strategy, for right or wrong. It doesn't indicate that something is less correct or important.
I will admit that C++ puts guranateed correctness second to pragmatism. Languages that don't have not been conspicuously successful in general purpose programming.
|
|||||||||||||