• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
ynm

What kind of optimization makes C++ faster than C#?

66 posts in this topic

interesting example Hogman.

But there is some missing data here. How many FPS did this wizardry gave to your game? And how many days were added to the project by choosing a language that allows you to get to that kind of wizardry? Are we sure that that FPS improvement is worth more than the delay to the game release? Or, if we decide not to treat these days as an early release but as dev time, are you sure that those days wouldn't have brought a similar algorithmic improvement? And, are you sure the original problem would be there in the first place?

 

The point here is that nobody REALLY has the answer to those questions.. so it's always down to an a priori decision that each software team needs to do when the project starts.

For the first 3-4 months of developing of my current game, I had fun maintaining a C# only parallel implementation of the entire graphics engine during my weekends for fun... until I could go on playing with it, it has been actually a tiny tad faster than the C++. Would that be the case now? With much more pressure on the system? Who knows? It's all very unpredictable.. 

 

I always use an analogy with race cars.. you can have a race car setup on the edge and POTENTIALLY very fast but tricky to drive.. or you can have a reasonable good setup POTENTIALLY slower but easier to drive and push hard..are you really sure car 1 is coming up first at the end of the race?

0

Share this post


Link to post
Share on other sites
But there is some missing data here. How many FPS did this wizardry gave to your game? And how many days were added to the project by choosing a language that allows you to get to that kind of wizardry? Are we sure that that FPS improvement is worth more than the delay to the game release?

The biggest optimization at this level of the code-base took some typical C++ code that was taking 8ms and reduced it's cost down to just 0.5ms (and that's without using any parallelization, which was also possible) -- taking us from well <30fps to comfortably >30fps, which is all that mattered, as we were vsync'ed to 30hz.
 
Just the core engine routines were written at this level of C++, by a very small team of expensive C++ programmers. The actual game itself was written by a much larger team in Lua (due to the productivity benefits!), with a budget of 16ms of CPU time on the main core per frame for all Lua code. Whenever this budget was breached (which happened often), some expensive Lua code would be ported over to optimized C++ code instead. These optimizations weren't delaying the release -- they were necessary to be able to release a playable product at all!

Edited by Hodgman
0

Share this post


Link to post
Share on other sites
 It's trying to juggle the code so that you're sure to delete things that need deleting and the pointers to them get there. That overhead is not trivial.

 

If you are constantly juggling with deleting objects, then you are doing something seriously wrong, and it's hardly fair to blame the language for that. In a well designed C++ program, it's fairly obvious where something has to be deleted. However if you start returning pointers from functions and expect the caller to delete it at some point, or pass pointers as parameters to functions and expect that function to delete it for you, yes then you will be juggling with deletes for some time. But doing that kind of reckless coding will result in unmanageable code in every language. If you have to rely on a garbage collector because your code is such a mess that you have no idea when to delete a pointer, you are doing it very wrong. Also, C++ does allow you to use unique_ptr for that specific job. So again, it's not really fair to blame a language to be counter productive because you choice not to use some 'safer' version.

0

Share this post


Link to post
Share on other sites

[quote name='3Ddreamer' timestamp='1356832449' post='5015595']
why do you believe that C# is so popular?
[/quote]

Because Java sucks. No really I imagine a junior developer just finishing college. Of course in college Java was the language that everybody had to use.

Now if I put myself in that position and would try out C# of course I would never want to go back to Java.

Whats the next step, of course putting C# in the educational system and you get even more mediocre but also much cheaper developers.

 

[quote name='3Ddreamer' timestamp='1356832449' post='5015595']
but one of the ECMA standard languages
[/quote]

Well the ECMA is living from doing standards, of course they take the chance to do a standard if a big vendor offers them a complete product. You can always find someone to standardize something.

 

[quote name='3Ddreamer' timestamp='1356832449' post='5015595']
These languages will be widely used for many years: C, C++, C#, Java, Python, and Lua It would not surprise me at all if they stayed in common use 10 or 20 years from now after the next big language is introduced, as has happened when C# was published.
[/quote]

Even longer, if you take maintenance into the account. Look at Cobol or Fortran, it's still in use even today.

 

And don't forget about these markets where the vendors have total control and everybody is happy with vendor lockin (SAP -> ABAP). Thoose languages will stay in use for decades.

0

Share this post


Link to post
Share on other sites

 It's trying to juggle the code so that you're sure to delete things that need deleting and the pointers to them get there. That overhead is not trivial.

 
If you are constantly juggling with deleting objects, then you are doing something seriously wrong, and it's hardly fair to blame the language for that. In a well designed C++ program, it's fairly obvious where something has to be deleted. However if you start returning pointers from functions and expect the caller to delete it at some point, or pass pointers as parameters to functions and expect that function to delete it for you, yes then you will be juggling with deletes for some time. But doing that kind of reckless coding will result in unmanageable code in every language.

No, that is pretty much standard in any non-C/C++ language. Even C does that liberally with stack allocated objects. I agree that well designed C++ programs make it obvious where something has to be deleted. This is because a well designed C++ program focuses on that rather than what needs to be done. Other languages (including modern, smart-pointer happy C++) aren't locked into how they need to design their program.

But honestly, that sort of thing isn't what I meant. I acknowledge that returning bald pointers is bad and often avoided practice. But even within a single method, properly cleaning up dynamically allocated objects without smart pointers in all of the different exception cases is tedious. It involves a lot of code that obfuscates what you're actually doing, and a lot of code that fallible programmers will screw up, and a lot of code you wrote that doesn't actually advance your game towards completion. It's overhead.


Also, C++ does allow you to use unique_ptr for that specific job. So again, it's not really fair to blame a language to be counter productive because you choice not to use some 'safer' version.

I was ignoring smart pointers since you deemed them the 'solution for the symptom'. I fail to see how it is not the language's fault that we had to build crutches for it. That we now have to spend time worrying about what smart pointer is appropriate here, how to handle libraries (that invariably use bald pointers) safely...

And to be blunt, pointers aren't a big deal as far as productivity goes. But to say that GC's just make up for poor design is naive at best.
0

Share this post


Link to post
Share on other sites

[quote name='kunos' timestamp='1356852212' post='5015675']
I always use an analogy with race cars.. you can have a race car setup on the edge and POTENTIALLY very fast but tricky to drive.. or you can have a reasonable good setup POTENTIALLY slower but easier to drive and push hard..are you really sure car 1 is coming up first at the end of the race?
[/quote]

 

It'd depend on the driver in the car.  If the driver in car 1 is just a better driver the chances of him winning of more than likely higher.  If you have the same drivers for each car then it'd depend on the drivers driving style (my whole family grew up around race cars, with some of my family actually racing pretty high up).

 

So by using that analogy with the code I'd say:

It'd depend on the programmer.  If the "better" programmer is working on code base 1 then the chances are more than likely higher.

0

Share this post


Link to post
Share on other sites
Ah, but that is a bit unfair towards C++. C++ was primarily designed not to force you into using something you don't need and not to add additional clutter or "secret magic stuff". But, at the same time, it was to allow you to use the "extra stuff" when you need.

Which has been found to hinder productivity greatly for the general case, and not really provide that much benefit as far as optimization goes. Hence the thread.
Smart pointers (at least one type of smart pointer) were part of the language pretty much forever.

Standardized in 1998, added ~1992 - about a decade after the language was released. And let's just say that adoption didn't really take place anywhere near those dates...
Do they require a programmer brain? Well yes, but what's the issue with that...

Which is overhead that is placed onto the programmer, leading to the sort of productivity losses in my original post. I'm not saying it's some horrible roadblock, I'm saying it's an inefficiency that effects every (non-trivial) thing you do in the language.
You can usually make a thousand lines worth of code well-behaved and guaranteed leak-free (also in presence of exceptions) using one or two smart pointers, with minimal, usually not measurable, added overhead.

Not in my experience. If you're doing any sort of OO programming, you're going to need polymorphism. Unless that thousand lines worth of code is simply bloat from static polymorphism (template metaprogramming), then there are some sort of pointers in there somewhere; a bundle of references to known types isn't going to cut it.
Now, one can like one approach or the other, one or the other design, that is a matter of taste (and application).

I disagree. It should be pretty conclusive at this point that (for the general case) 'pay for what you use' has decided detriments to productivity that arise from adapting the limited functionality to the different 'paid' functionality without providing meaningful optimization/performance benefits (in the general case).

You're right. That design decision doesn't make it all crap. Design by committee doesn't necessarily make things bad.

Like I said, having pointers in the language isn't even close to the biggest productivity losses compared to others. They're damned useful when you need them.

But that wasn't the argument I was addressing; it was that a garbage collector is a band-aid for poor design. Which is crap.
0

Share this post


Link to post
Share on other sites

[quote name='shadowomf' timestamp='1356866939' post='5015718']
And don't forget about these markets where the vendors have total control and everybody is happy with vendor lockin (SAP -> ABAP). Thoose languages will stay in use for decades.
[/quote]

 

That's exactly right and we know also more specifically that such vendors use library extensions to fill the demands upon languages in ways more suitable to them, which is why C# is going to gain on C++ in many areas.  Using  a newer language such as C# eliminates much of the coding stagnation of having older C++ libraries and biases on them and also forces innovation in keeping with the demand for more cost effective program development implemented in newer systems, which has already been covered in this thread.

 

An independent and skilled programmer has much freedom to use C#, C++ or combine them, but I do not envy those corporate programmers who have time and resource constraints under pressure, even if they chose the easier C#. wink.png

 

 

Clinton

-2

Share this post


Link to post
Share on other sites
I disagree. It should be pretty conclusive at this point that (for the general case) 'pay for what you use' has decided detriments to productivity that arise from adapting the limited functionality to the different 'paid' functionality without providing meaningful optimization/performance benefits (in the general case).

Yeah, in the general case (whatever that is, I imagine writing corporate GUIs...), C++ isn't the most productive language, especially for junior staff to be using (they can actually be reducing instead of increasing the project's progress...)

 

However, "pay for what you use" is exactly what makes C++ the most productive choice for the small sub-set of problems where it is (one of) the most productive language to choose from.

e.g. If it didn't have manual memory management, then it would be a very unproductive choice in memory-constrained embedded systems. Manual memory management (the fact memory isn't abstracted away, and a GC forced upon you) is a key feature of the language that enhances it's productivity (in the specific case)!

 

But I would not use wordings like "cure for the symptom" or "crutch" for the memory management in C++ because that is really not what it is. It's a deliberate design decision.

QFE -- for a particular class of situations, it's a very, very useful decision.

 

 

Screw the 'general case'; I'm an engine programmer. I still measure system RAM in MiB, not GiB, and running out of RAM is a real concern, so I need to be able to track every single byte that's used. I need to be able to look at my high-level code and have a pretty good guess at what kind of assembly will be generated from it (and be able to debug with the two interleaved to confirm those guesses). I need to be able to treat memory as bytes and use memcpy. I need to be able to read data off disk and cast it to known structures without parsing/deserializing it. I have to make a lot of low-level optimizations, and make heavy use of the "pay for what you use" idea.

I also need to be able to support a productive "game programming" language, such as Lua or C#, but that comes after getting the foundations right wink.png

Edited by Hodgman
1

Share this post


Link to post
Share on other sites
However, "pay for what you use" is exactly what makes C++ the most productive choice for the small sub-set of problems where it is (one of) the most productive language to choose from.


Certainly, hence why I said general case. I agree it's a design decision. I just think that a design that benefits a "small sub-set of problems" to the detriment of the others is objectively a poor one in a general purpose programming language.

I frankly don't see how that is at all contentious, unless you're saying C++ isn't a general purpose programming language biggrin.png

-1

Share this post


Link to post
Share on other sites
Certainly, hence why I said general case. I agree it's a design decision. I just think that a design that benefits a "small sub-set of problems" to the detriment of the others is objectively a poor one in a general purpose programming language. I frankly don't see how that is at all contentious, unless you're saying C++ isn't a general purpose programming language biggrin.png

C/C++/C# are all "general purpose" languages (which is pretty meaningless; it just means they're Turing complete and are not DSLs...), but you'd typically call the former two "systems programming" languages, and the latter an "application programming" language, as those are the general domains that they're typically best at / used for.

e.g. Python is also a "general purpose" language, but is often called a "scripting language", because it's often used to write small "scripts" that extend the behaviour of a host program.

 

If you're a systems programmer, then the lack of simple manual resource management in C# turns out to be a "a design that benefits a "small sub-set of problems" to the detriment of the others"... So no, you can't objectively say that in the absolute.

Every sub-set of programming problems is small on a global scale, but on a local scale the size depends on who you are and what your job is.

 

Given the original topic of this thread (and the additional context of being on a game-dev site), it's clear we're discussing the (globally small) set of problems where specific manual resource management methods (and other options that you have in C++) can be more efficient than C#'s one-size-fits-all alternatives (such as game engines) -- and then also every other set where this isn't the case (such as corporate GUIs).

Edited by Hodgman
1

Share this post


Link to post
Share on other sites

Oh boy here come the flames.

Look, just make your project in C#.  When you find something particularly important is running too slowly, there is a way to write it in C++ and call it from your code.  It'll run as fast as you want it to run.

I'm betting /you/ will be slower with C++ than with C# in both productivity and program execution.
You want to get it working and then look for where you need improvement and improve.  Eventually you'll hit a wall with C# (maybe), at which point you can move over to C++ and have it fast enough to get the job done.  There's always room for improvement, so stop worrying about it lol.


C++ does exactly what you say.  You can shoot yourself in the foot.
C# makes reasonable assumptions and files the paperwork for you so you don't have to.  Maybe you don't need it filed in triplicate, but a well established protocol works even when you're not thinking hard about how you want to deal with a situation.  If you need triplicate, its there.  If not, no worries.  C++ only files in triplicate when you tell it to, and is willing to blindly do as you say.  If you mess up it's on you.  That is how it saves time.  By not double checking all of your instructions.

That, and they've been at improving it for a really long time.

0

Share this post


Link to post
Share on other sites

[quote name='frob' timestamp='1356928477' post='5015962']
Good engines rely on many different languages.
[/quote]

Sorry, but this is just plain wrong. Many different languages don't equal quality.

 

While there are many engines that are written in more than one language it's not necessary a good thing.

(I'm not counting scripting support into this, because scripting is often part of the game and the engine is only providing the possibility to script the game or game objects.)

 

Also you have to differentiate a bit more. E.g. having a library or engine that has multiple language bindings is a complete different thing than having an engine that's written in a dozen of different languages. Having many different bindings is something good, especially if the engine should be licensed to other developers. Having an engine written in many languages sounds like a horror story.

Again we are talking about the engine itself. I'm not saying that it's a bad thing to write your tools in something for appropriate (e.g. use C# for the tools and C++ for the engine itself). However if every tool is written in another language it's not a sign of high quality.

 

[quote name='frob' timestamp='1356928477' post='5015962']
Thinking back over the decades of good engines I've used, the simplest engine remember was for the Nintendo DS, and it 'only' used six languages that I'm aware of. The major EA engine I work with today has no less than 15 languages, probably more if I dig deeper. They range through hardware-specific assembly and C and C++ and C# and Lua and perl and python and shader scripts and even a handful of custom languages for particle systems and audio control.
[/quote]

They don't use it because someone thought "hey great let us use as many languages as possible in our engine". Most of the time it grew historically and it's hard to impossible to get rid of it. Sometimes you have to add another language, for example to support a new platform or make use of a new library, however I'm pretty sure no experienced developer will make such a decision lightly.

 

And the many different tools and scripts all in different scripting languages is a sign of lack of direction. Obviously nobody decided to use only one scripting languages.

Or even worse imagine this scenario:

  1. In the beginning somebody choose perl as scripting languages, because he knew it already or he heard something about it.
  2. A few years later you decide to switch to python, because you can find more developers that also know python and in generally it seems like a nicer language or whatever. However you don't have the time to make a complete transition to python, because not all your developers are as fluent as they need to be for that. Besides your developers don't have the time to rewrite all the tools. So some modules are rewritten but most of them stay perl.
  3. Lua comes along and somebody made the decision to use it as main scripting language in the game. It's nicer for the artists and level designer and the developers do like it too. Great since you are already using Lua in-game, why not also for the tools? So without much hesitation your team decides to switch to Lua for tool development. Now most of your developers need some time to get familiar with Lua, they also have their usual tasks to do so again yo can't completly rewrite everything in the new language.
  4. You've got yourself a ten year old code base with 3 different languages (just for the tools). Whenever there is something to change on the older modules you need to find the perl or python guy. Since some of the tools are so old and complex, everybody is just saying "never change a running system" and nobody is touching the old code. If your last perl guy leaves you won't replace the perl tools, no developers will start writing tools in Lua or whatever you currently use just to integrate the old tools. "No, you need to run the converter script to make it work with tool X, when you're finished you need to run it again to make it work with our other stuff!"
  5. Of course everybody that reads this knows, a rewrite would be the best thing to do or better forget all about it and start from scratch. However if your studio can't afford it you need to make it somehow work. It gets worse every year and each project is getting more difficult, takes longer and gets more expensive. Maybe some day your studio does a complete rewrite, maybe they decide to license an engine from another developer. Or maybe your studio is slowly fading away into oblivion, like many before you.

 

Multi-language projects have many downsides, for example:

  • They are a maintenance hell. At my place of work (not game related) we have projects with Tcl, C++, Visual Basic, C# in one project (some modules stand on they own). It's just bad, I can't see any good about it.
  • Developers need to be fluent in many languages. This is especialy difficult if you have some rarely used, old or esoteric languages. Especially since some parts of the engine aren't tuched for a while and the developers aren't as familiar with it as with a piece of code they work regulary with.
  • New developers will need longer to get a grasp of the engine code.
  • It's harder to hire new developers, especially if you want them to have expierience with all of the used languages.
  • If somebody is developing a module in a different language than all the other modules you should take a close look. Is it neccessary or is he trying to make himself unfireable. If he is just trying to use arcane knowledge to make it hard for everybode else to maintain that module, he/she should be let go as soon as possible.
  • Each additional language means the development environment gets more complex. Not something you wish to achive.
-1

Share this post


Link to post
Share on other sites

Good engines rely on many different languages.

 
While there are many engines that are written in more than one language it's not necessary a good thing.
(I'm not counting scripting support into this, because scripting is often part of the game and the engine is only providing the possibility to script the game or game objects.)
Also you have to differentiate a bit more. E.g. having a library or engine that has multiple language bindings is a complete different thing than having an engine that's written in a dozen of different languages. Having many different bindings is something good, especially if the engine should be licensed to other developers. Having an engine written in many languages sounds like a horror story.

Yeah, it depends on how you define things. I think it would be pretty common to see:
* a language for the engine
* a language for the game
* a language for the GPU-side components
* a language for the tool-chain
* a language for data definitions
* a language for build automation

Some of them might be the same language, and some of the dot points might be several languages.
e.g. For the above dot points, I use C/C++, C++/Lua, HLSL/Cg, C#/VB/Batch/JavaScript+HTML, Lua, CMake/Batch.
That's around 10 languages in a modern engine with no legacy code.
The engine is C++, but contains some C modules, which is fine because the two interop so well.
The engine is bound to Lua, so the game is written in a mixture of C++ and Lua, depending on which is more productive in that area.
The obvious choice for the GPU portions is a standard shading language -- HLSL is great, and Cg is almost the same syntax, which helps when porting HLSL code to GL.
The data-processing parts of the tool-chain are all C# because it's a good language to work with and is very capable. Many GUIs are JavaScript+HTML because they're designed to be remote "web" tools, that are just thin GUIs that connect to either a C# data-cruncher, or the C++ engine in the background. Extensions of our art tools are VB, because they support it for scripting. Microsoft Batch files are sometimes used as glue.
Human editable data files are written in Lua, instead of JSON/XML/et al. because Lua is already the engine's scripting language, and it's also a great, flexible DDL.

Instead of being tied to a specific IDE "project file" format, the code builds are controlled by CMake scripts, which is a simple imperative language, again with some Batch glue.

 

Personally, I'd include all of the above inside the category of what "the engine" is made up of (not just the engine's runtime library itself).

Edited by Hodgman
0

Share this post


Link to post
Share on other sites

[quote name='Hodgman' timestamp='1356961267' post='5016050']
Personally, I'd include all of the above inside the category of what "the engine" is made up of (not just the engine's runtime library itself).
[/quote]

That's where our opinions are different (which is not a bad thing).

I wouldn't count the following as part of the engine. Sure they are connected, but not part of the runtime.

  • Shaders - many provide some predefined shaders. But I believe shaders should be part of the game. Else all games use the same lighting style and materials it gets boring. Handwritten shaders often look more unique and can do so much more than shader that have been generated can. Besides aren't shaders assets?
  • Scripting - yes, provide the possibility for scripting, but I wouldn't put scripts in the engine.
  • The whole pipeline - Texture-, normal map-, lightmap-, mipmap-baking is all part of the tools. It's not shipped with the game and not part of the engine. It's part of the eco-system that engine developers provide to make it easy to use the engine. Most of the time the tools even work without the engine as well as the other way around.
  • Build tools - you wouldn't count Visual Studio as part of a game engine would you? Or cmd.exe. Just because somebody decides to replace either it's not magically becoming a part of the game engine. Would you count make as part of a piece of software that is developed with the gcc toolchain?
  • Web tools - see whole pipeline/build tools and I wouldn't count any other way to provide a pretty Gui for a simple tool.
  • Exporters - for Photoshop, gimp, 3ds max, blender, ... they are tools just as before, besides there are other ways (use standard formats).
  • The game - choose whatever language you wish to write the game. Provide multiple language bindings to use the engine. The game just is not part of the engine. Anyway if you go down that road, microsoft should start to claim that any piece of software written for windows is also a part of windows (well in some philosophical way it could be). Of course it's always possible to write a game without engine, which makes the engine somewhat a part of the game...
  • Libraries - If you use a third party library or API, for example OpenGL, the Windows API or any other library the library is not part of the engine. It's a dependency. I wouldn't count the languages used inside the library as part of the engine. Besides you can't always be certain what language it was written in.
  • Data definition languages or data in general - One of the points where we need to clarify which languages we mean. If we start counting not human readable data languages, we could include every binary file format that an engine supports. Besides the whole point only applies if you're using a data driven architecture, else it's just data and not part of the engine. Most data is part of the game anyway... so I would count this as assets.
-1

Share this post


Link to post
Share on other sites
Did it take over a decade to improve C++? Did this annoy the hell out of many people (including me)? Of course, but that is what design-by-committee is about. A design committee always makes any kind of process lengthy and complicated, that's just the way it is. It's not a miracle that someone at the top (1-2 people) dictating what shall be done happens in considerably less time than 40 or 50 board members meeting and discussing and trying to make every single one happy. This doesn't mean that what finally came out of it is necessarily bad, however.


It did take a long time to for this update to happen, from 98 to 2011. However, the future of c++ is amazingly bright, they now have many study groups of experts working on separate pieces of the language. These study groups work on the language and then bring there work back to the commite to be voted on. This is something that c++ has never had, more people are now working on the standard than ever before.


If you want to see exactly what I'm talking about watch this.
http://channel9.msdn.com/Events/Build/2012/2-005

he starts getting into the new standards committe about 22minutes in.

Study groups ( none of these existed before c++11 was released )
concurrency
modules
filesystem
networking
Tx Memory
Numerics
reflection
concepts
ranges
Feature Test
Databases ( being formed )

And also the standard agreed on a new time table for releases

ge3qu.jpg Edited by EddieV223
1

Share this post


Link to post
Share on other sites

Good engines rely on many different languages.

 

Sorry, but this is just plain wrong. Many different languages don't equal quality.

One could certainly do everything in one language, but that would be foolish. A good craftsman uses the right tool for the job. Insofar, using several languages in some way does equal quality (that assumes one doesn't just use many languages for using many languages!).

 

I am probably one of the biggest C++ fanboys, but I would never consider even for a minute writing part of a toolchain in C++. Why? Because C++ sucks ass for that.

Python, Ruby, PHP, take your pick. One line to read a whole file into an array, a dozen lines with 2-3 regex to do the whole magic, 2-3 lines to dump the binary stuff to disk. Two lines to read and parse an XML file, a dozen more to walk through it. Pipe to/from an external command... 1 line. Make a HTTP request or database query or similar... 1 line.

 

Do that kind of thing in C++ and you need half a dozen of libraries and will waste a week on writing something that (maybe, if you're lucky) does the same thing in three seconds instead of two, and that's a nightmare to maintain. It will take quite a few runs to amortize that week of development time. Every time you change something, you spend half a day on it again.

 

Level Editor? Written in 1/3 the time using C#, and they work quite OK. Could they be 20% "better" in C++? Probably, but who cares. They're functional, and they're not so slow that it takes away productivity. Spend your time on something different.

 

Then there's scripting, of course. Scripting (Angelscript in my case) is what usually runs not only the GUI, but almost the entire program. Unless of course you don't care about that kind of thing. How would I do that in C++?

 

So, you really don't have to make up something to get 4-5 different languages (and that's not counting domain specific languages like SQL or XML or JSON that you implicitly use too).

1

Share this post


Link to post
Share on other sites
The discussion has been interesting and constructive at least, it didn't go flame war style like a lot of threads like this do.
0

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!


Register a new account

Sign in

Already have an account? Sign in here.


Sign In Now
Sign in to follow this  
Followers 0