Jump to content

View more

Image of the Day

Adding some finishing touches...
Follow us for more
#screenshotsaturday #indiedev... by #MakeGoodGames https://t.co/Otbwywbm3a
IOTD | Top Screenshots

The latest, straight to your Inbox.

Subscribe to GameDev.net Direct to receive the latest updates and exclusive content.


Sign up now

When to start with C++?

4: Adsense

Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.


  • You cannot reply to this topic
37 replies to this topic

#21 akesterson   Members   

150
Like
-3Likes
Like

Posted 10 March 2013 - 07:01 AM

@Alpha_ProgDes has it right; use what you know first. Learning another language "because it's probably got better performance", before you have anything published in the languages you're already good with, is premature optimization - and as we all know, premature optimization is bad.

 

And for what it's worth, I'd avoid C++ like the plague anyway. If you DO pick up C++, avoid the STL containers like the plague - their performance is absolutely abyssmal.



#22 EWClay   Members   

659
Like
2Likes
Like

Posted 10 March 2013 - 08:26 AM

@Alpha_ProgDes has it right; use what you know first. Learning another language "because it's probably got better performance", before you have anything published in the languages you're already good with, is premature optimization - and as we all know, premature optimization is bad.

And for what it's worth, I'd avoid C++ like the plague anyway. If you DO pick up C++, avoid the STL containers like the plague - their performance is absolutely abyssmal.


Talking about premature optimisation and then saying to avoid the standard library for performance reasons is a massive self-contradiction.

#23 akesterson   Members   

150
Like
0Likes
Like

Posted 10 March 2013 - 08:44 AM

@Alpha_ProgDes has it right; use what you know first. Learning another language "because it's probably got better performance", before you have anything published in the languages you're already good with, is premature optimization - and as we all know, premature optimization is bad.

And for what it's worth, I'd avoid C++ like the plague anyway. If you DO pick up C++, avoid the STL containers like the plague - their performance is absolutely abyssmal.


Talking about premature optimisation and then saying to avoid the standard library for performance reasons is a massive self-contradiction.

 

Actually, no, it goes to prove the point. Many times, when deciding to optimize early based off of minor observations, without really completing the solution, you just muck it up. In this case, OP is asking to switch to C++ because (essentially) "that's what everyone uses"; having a java background, OP would expect the C++ STL containers to confer that same sort of naive "all native code is fast" performance benefit, when in actuality, they're the fastest way to murder C++ code.

 

Write first, optimize later. OP's java will quite likely be faster than their C++, since they already know their Java, and the best patterns/weaknesses in the language. If they write their Java and finds that it is, in fact, too slow (or nobody wants to run Java), then they can look to a new language.

 

Unless they really honestly just WANT to learn a new language, just for the sake of learning it, which is an entirely different conversation.


Edited by akesterson, 10 March 2013 - 08:46 AM.


#24 EWClay   Members   

659
Like
4Likes
Like

Posted 10 March 2013 - 09:06 AM

I didn't even mention Java. I'm just saying, if you use C++ without the standard library you are making life difficult for yourself.

 

Switching language is hardly an optimisation. Switching to a different container type is trivial in comparison.



#25 Altruist   Members   

140
Like
0Likes
Like

Posted 10 March 2013 - 04:20 PM

@GD.NET: tldr:C++ rox/sux, Java sux/rox. The end. This debate is older than some of the people on this board.

Also, as for containers, BOOST for the win.

 

@OP: You're going to get bored of hello world and the amazing joys of console text output REALLY quickly.

Get reasonably good with that first. Then try some graphics programming.

I'm assuming you're going to program in Windows so you will want to go with DirectX. You'll want the Direct X SDK. 

Now, there is steep speed bump in the learning curve as you go from console to Windows programming, and that is the windowing system itself. This doesn't have to be a stumbling block in your coding pursuits. Find a good tutorial site. I like CodeProject.

http://www.codeproject.com/search.aspx?q=directx&doctypeid=1

Best thing to do is find a SERIES of Direct X tutorials. This is that whole "gradual learning", "bit by bit", "walk before you run" deal.

Once you have a quasi-firm grasp of DirectX, find a sprite repository and experiment with animating.

http://charas-project.net/charas2/index.php (This one's all sorts of fun.)

 

Sound/music is important. Or you can tell your users to hum while they play. Find a free sound/music repo and add background music and sound effects to your project.

Bit by bit. Little by little.

 

And then one day, not today, or even next week, you'll make the move to 3D. Make some 3D models. Spin them around like a planets in a solar system. (My CG instructor made us do a 3D solar system with the "Utah Teapot" with the sun, three planets and the moon). Go with Blender for now. Sculptris also, but mostly for heads. If you're a college student, you can get a LEGIT copy of Maya 3D and other AutoDesk products free. Free is good. 

 

 

Go make us proud.


Edited by Altruist, 10 March 2013 - 04:21 PM.


#26 Oberon_Command   Members   

5985
Like
0Likes
Like

Posted 10 March 2013 - 04:38 PM

And for what it's worth, I'd avoid C++ like the plague anyway. If you DO pick up C++, avoid the STL containers like the plague - their performance is absolutely abyssmal.

Which containers and on what platform? Do you have data to support this conclusion available to show us?

#27 Alpheus   GDNet+   

6908
Like
0Likes
Like

Posted 10 March 2013 - 04:47 PM

And for what it's worth, I'd avoid C++ like the plague anyway. If you DO pick up C++, avoid the STL containers like the plague - their performance is absolutely abyssmal.

Which containers and on what platform? Do you have data to support this conclusion available to show us?

 

Maybe he's referring to the EASTL that was made for game consoles (and maybe embedded systems). However, that has nothing to do with normal day to day systems and apps programming. The amount of time testing and fixing bugs by using raw pointers and like makes the SC++L even more of a reason to use. Performance and maintenance go up considerably. And I doubt that many developers can write data structures and libraries on par with the people who actually make SC++L.


External Articulation of Concepts Materializes Innate Knowledge of One's Craft and Science
 
Beginner in Game Development? Read here. And read here.
 
Super Mario Bros clone tutorial written in XNA 4.0 [MonoGame, ANX, and MonoXNA] by Scott Haley
 
If you have found any of the posts helpful, please show your appreciation by clicking the up arrow on those posts Posted Image
 
Spoiler

#28 akesterson   Members   

150
Like
0Likes
Like

Posted 10 March 2013 - 06:19 PM

And for what it's worth, I'd avoid C++ like the plague anyway. If you DO pick up C++, avoid the STL containers like the plague - their performance is absolutely abyssmal.

Which containers and on what platform? Do you have data to support this conclusion available to show us?

 

Google "C++ STL performance" and you'll be inundated with people complaining about the performance, with no indication that it is relative to any one compiler or implementation. std::map and std::vector are particularly troublesome offenders. Compared to their counterparts in Boost, or their dynamic contemporaries in languages like Python, their performance is garbage until you start cranking up the compiler optimizations (which make the code arguably more difficult to debug.)

 

I have some example numbers on a (very narrow set of use cases) in a thing I've been putting together to illustrate these issues, actually. 

 

https://github.com/akesterson/perftests/tree/master/countstrings

https://github.com/akesterson/perftests/tree/master/countints

 

Those two test cases illustrate C (with glib & hash maps) vs C++ (std::map and std::unordered_map) vs Python vs JavaScript vs Bash, comparing their relative execution speed to count the occurence of an item in a list of items (strings and ints), to illustrate the speed of each implementation's containers in setting, looking up, and checking for the existence of keys.

 

You CAN get C++ STL containers to perform admirably (see the -O2 settings on the documentation), but out of the box, the containers perform incredibly badly.


Edited by akesterson, 10 March 2013 - 06:19 PM.


#29 Paradigm Shifter   Members   

5832
Like
0Likes
Like

Posted 10 March 2013 - 06:28 PM

Why wouldn't you use full optimisation for a release build? Of course you're going to use -O2... and looking at performance in a debug build is just meaningless... debug builds are for stepping through code and debugging it...


"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#30 akesterson   Members   

150
Like
0Likes
Like

Posted 10 March 2013 - 06:34 PM

Why wouldn't you use full optimisation for a release build? Of course you're going to use -O2... and looking at performance in a debug build is just meaningless... debug builds are for stepping through code and debugging it...

 

That's not a debug build, that's just unoptimized. Debug builds include stabs, extra nametable info, etc, none of which the -O0 builds include. -O0 just means that there is no optimization performed by the compiler - how your code is written, is how it will run.

 

Yes, you will make a production build at -O2 or potentially even higher, and when you do that, you'll get near-C levels of performance. But that's not the point. The point is that the containers perform terribly until the compiler gets its hands on them and optimizes them; why? There's no obvious reason for it, not when C and glib are smoking it by orders of magnitude. RTTI and dynamic dispatch can't account for all of the slowness there - the C++ STL containers just aren't written for performance from the get-go.

 

Just realized we're jacking OP's thread, can make a separate thread re: STL performance if we want to keep talking about this.


Edited by akesterson, 10 March 2013 - 06:35 PM.


#31 Paradigm Shifter   Members   

5832
Like
0Likes
Like

Posted 10 March 2013 - 06:36 PM

I can't think of a single STL container that uses RTTI or dynamic dispatch...

 

And I think you're going to struggle to write a decent container in C without using a ton of macros (void* is going to be slower than templates).


"Most people think, great God will come from the sky, take away everything, and make everybody feel high" - Bob Marley

#32 EWClay   Members   

659
Like
1Likes
Like

Posted 11 March 2013 - 01:24 AM

I also hear that Usain Bolt is slow if you tie bricks to his feet...

#33 Alpheus   GDNet+   

6908
Like
0Likes
Like

Posted 11 March 2013 - 01:36 AM

I also hear that Usain Bolt is slow if you tie bricks to his feet...

 

Yeah, but he's only slower than Usain Bolt w/o bricks tied to his feet :)


External Articulation of Concepts Materializes Innate Knowledge of One's Craft and Science
 
Beginner in Game Development? Read here. And read here.
 
Super Mario Bros clone tutorial written in XNA 4.0 [MonoGame, ANX, and MonoXNA] by Scott Haley
 
If you have found any of the posts helpful, please show your appreciation by clicking the up arrow on those posts Posted Image
 
Spoiler

#34 matrisking   Members   

282
Like
0Likes
Like

Posted 11 March 2013 - 09:04 AM

Almost everyone who posts on this forum will usually argue that it's best not to start with C++? But how will you know when it's time to move on to C++?

 

The reason I want to get into C++ is not because I think it's a superior language to Java(What I use now), I just feel that there are more C++ game programmers out there and it's easier to get support on my projects and more code samples to look at.

 

To address your questions I would say that there's going to be as much "general" support out there for C++ as there is for Java.  They're both mature, well established languages with very large user bases.  

 

As far as game development is concerned, if support and code samples are your concern, you probably want to focus more on specific game development libraries and frameworks rather than something as broad as a programming language.  For example, I'd love to learn Monogame (which is based on C#), but I haven't yet.  Sure, there's a ton of C# documentation and support out there, but not nearly as much for Monogame.

 

Finally, I think it's worth asking:  What's your long term goal here?  Are you a hobbyist or looking to work for a big development studio at some point?

 

Hope this helps!



#35 stein102   Members   

556
Like
0Likes
Like

Posted 11 March 2013 - 04:37 PM

Thanks for all the responses, it seems the general response is to stick with Java for now. Pretty sure that's what I'll do then.

 

Almost everyone who posts on this forum will usually argue that it's best not to start with C++? But how will you know when it's time to move on to C++?

 

The reason I want to get into C++ is not because I think it's a superior language to Java(What I use now), I just feel that there are more C++ game programmers out there and it's easier to get support on my projects and more code samples to look at.

 

To address your questions I would say that there's going to be as much "general" support out there for C++ as there is for Java.  They're both mature, well established languages with very large user bases.  

 

As far as game development is concerned, if support and code samples are your concern, you probably want to focus more on specific game development libraries and frameworks rather than something as broad as a programming language.  For example, I'd love to learn Monogame (which is based on C#), but I haven't yet.  Sure, there's a ton of C# documentation and support out there, but not nearly as much for Monogame.

 

Finally, I think it's worth asking:  What's your long term goal here?  Are you a hobbyist or looking to work for a big development studio at some point?

 

Hope this helps!

 

Well, I'm just finishing up my last year of highschool and am planning on going to university for a CS degree to hopefully work in a studio when I'm done.



#36 Chad Smith   Members   

1343
Like
0Likes
Like

Posted 12 March 2013 - 11:54 AM

@Alpha_ProgDes has it right; use what you know first. Learning another language "because it's probably got better performance", before you have anything published in the languages you're already good with, is premature optimization - and as we all know, premature optimization is bad.

 

And for what it's worth, I'd avoid C++ like the plague anyway. If you DO pick up C++, avoid the STL containers like the plague - their performance is absolutely abyssmal.

While I will say for a programmer it would be important to know the concepts behind the containers in the STL, though to say to avoid them is stretching it by a good amount.

 

The chances of an average joe programmer to write containers that are more optimized in terms of speed and usability are more than likely very slim. An average programmer will more than likely not produce code anywhere near that of what the programmers of STL do.  Hell even if they did, the chances of it being "safe" and "bug free" are even less slim.

 

Though I would say it wouldn't hurt to know the concepts behind the containers and implement your own version of them just for learning and learning only.


Edited by Chad Smith, 12 March 2013 - 11:58 AM.


#37 Chad Smith   Members   

1343
Like
0Likes
Like

Posted 12 March 2013 - 11:57 AM

Double Post.


Edited by Chad Smith, 12 March 2013 - 11:57 AM.


#38 BGB   Members   

1570
Like
0Likes
Like

Posted 12 March 2013 - 12:57 PM


@Alpha_ProgDes has it right; use what you know first. Learning another language "because it's probably got better performance", before you have anything published in the languages you're already good with, is premature optimization - and as we all know, premature optimization is bad.
 
And for what it's worth, I'd avoid C++ like the plague anyway. If you DO pick up C++, avoid the STL containers like the plague - their performance is absolutely abyssmal.

While I will say for a programmer it would be important to know the concepts behind the containers in the STL, though to say to avoid them is stretching it by a good amount.
 
The chances of an average joe programmer to write containers that are more optimized in terms of speed and usability are more than likely very slim. An average programmer will more than likely not produce code anywhere near that of what the programmers of STL do.  Hell even if they did, the chances of it being "safe" and "bug free" are even less slim.
 
Though I would say it wouldn't hurt to know the concepts behind the containers and implement your own version of them just for learning and learning only.


for containers, it depends some on what a person is doing as well.

from a performance POV, direct access to a C-style array is hard to beat:
Foo **arr;
...
obj=arr[idx];

but, if adding things like bounds-checking, insert operations, ... then without care, these costs can quickly add up (and overshadow any inherent speed advantage).

so, a person ends up needing to take into account things like when and where to insert checks, ... and for the most part uses raw array access.

meanwhile, many people swear by generic containers, and some others believe them to be overrated (like, they can be good and nice sometimes, but hardly a one-size-fits-all solution either).

others may come from a tradition where it is more common to write the logic for managing collections of a given type of object along with the object in question (where relevant each type of object supplies its own container), ...

so, it depends some.


it is sort of like floating point vs fixed point:
many will say floating point is fast enough for anything, faster than fixed-point on current hardware, ... basically, that a person should always choose floating point, and never consider the "ancient cruft" that is fixed-point arithmetic.

sometimes there are good reasons, like fixed point can be a pain to get right, tends to result in opaque-looking code, with funky issues like having to worry about things like value precision and overflow, ..., and if written naively (or used inappropriately) will in-fact generally be slower.
but, for some types of tasks, there are still cases where fixed point may significantly outperform floating point (*1), or offer special advantages (like being able to cram a value into a smaller number of bits), and, on the other side, cases where if fixed point is used it may lead to annoying arbitrary limitations and/or weird bugs.

*1: typically in image and signal processing tasks (such as in a video codec).

and, probably, if your "average joe" programmer tries to use fixed-point, they will mess it up.
yet, no reason for a person not to have the tool in their toolbox.

programming decisions need not always aim for the least-common-denominator.




Old topic!

Guest, the last post of this topic is over 60 days old and at this point you may not reply in this topic. If you wish to continue this conversation start a new topic.