• Advertisement
Sign in to follow this  

C++ C++ - do you use STL in your game?

This topic is 2043 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

Direct, idiom free translation:
[code]

#include <vector>
#include <cstdio>
#include <cstdlib>

int main()
{
std::vector<int> numbers;

for(unsigned i = 0 ; i < 20 ; ++i)
{
numbers.push_back(std::rand() % 50);
}

for (unsigned i = 0; i < numbers.size(); i++)
{
std::printf("List[%i] = %i\n", i, numbers[i]);
}

for (unsigned i = 0; i < numbers.size(); i++)
{
if (numbers[i] % 2 == 0)
{
numbers.erase(numbers.begin() + i);
i--;
}
}

for (unsigned i = 0; i < numbers.size(); i++)
{
std::printf("List[%i] = %i\n", i, numbers[i]);
}
}
[/code]

Share this post


Link to post
Share on other sites
Advertisement
[quote name='rip-off' timestamp='1337006302' post='4940091']
[quote]



[left][color=#282828][font=helvetica, arial, verdana, tahoma, sans-serif][size=3][background=rgb(250,251,252)]Your original posts said one should not use lists at all, not that vectors are usually better.[/background][/size][/font][/color][/left]

[/quote]
Please quote where I said that.
[/quote]

[quote name='rip-off' timestamp='1336996225' post='4940024']
[quote]
... your linked lists, trees, etc., rather than just using LinkedList<MyClass> (or whatever the STL syntax is).
[/quote]
If you're worried about performance, you should strongly consider not using linked lists at all.[/quote]

(My apologies if I misinterpreted what that first quote meant.) Edited by mdwh

Share this post


Link to post
Share on other sites
I fundamentally disagree with your characterisation of the words I said. I believe "strongly consider not using lists" more closely matches "vectors are usually better" than "not use lists at all". That is what I meant, and that is what the words actually mean, as I understand.

Share this post


Link to post
Share on other sites
[size=3][font=arial,helvetica,sans-serif]Which is better...that part of Standard C++ formerly known as STL or your own?[/font][/size]

[size=3][font=arial,helvetica,sans-serif]This is a common query and I doubt anyone has the definitive answer because what was once known as STL covers quite a wide range of concepts. Likely any one individual has only a very limited use for and knowledge of a subset of it, even if that's a large subset. I don't think it's possible for anyone to really be an expert across the entire STL because I doubt any single person has used every single feature.

It's important to understand this...because people should expect quite a varying range of opinions and you need to consider the subset of functionality that is relevant to your own work. For game development, we’re really only talking about a few specific types of containers that are relevant to run time. Tools are fair game for a much wider range of needs.

Once upon a time, at least to settle this query for my own purposes I considered the subset that I would use normally, discarding concepts I would never use and features I would never really be interested in during my life as a game developer. I looked deeply into the implementations I was interested in and tried to see if I could improve on them performance wise.

What I found was that most implementations were quite well developed and were quite efficient - at least as much as they could be. There was very little room for direct optimization, which wasn’t even worth the effort. For the optimizations that were possible...typically they'd be related to the deployment/use and as such would also be necessary if you were to take the ‘rolling your own’ containers option anyway or the optimizations were possible only by removing features to allow corner cutting.

The latter were more interesting to me because clear performance (and memory) wins were easy and possible via this route. This should surprise no one though…because the outcome of removing features is a more specialized case and as we all know, specialized cases will generally be more performant than generic ones. I actually don’t find too much fault with STL for being generic and flexible either – that’s kind of the point of it. I should also add that programming IMHO is often about making trade off decisions and sometimes generic/flexible is just a better choice anyway.

Unfortunately, this result did give me the excuse I needed to continue using and maintaining my own containers because I don’t need to give clock cycles away anyway. However, before the haters applaud I will also add that while such exercises do provide measurable gains at the instruction level please bear in mind that the % of time your program counter is iterating over such instructions is very minimal. The gains you’ll see to your frame rate by such techniques are often not going to be as noticeable.

I should also add that while I do use my own containers, that wasn’t an excuse for me to throw STL containers away. I still use them actually, particularly in code that I share with others or in code that needs to be more flexible.

A TL/DR version, which is also roughly the takeaway from my own research[/font][/size][list]
[*][size=3][font=arial,helvetica,sans-serif]In rolling your own it’s easy to make performance gains, but you’re not really optimizing STL – you’re removing features and making something else. Apples and oranges don’t really compare.[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]I did make some memory gains too, as I briefly hint at above. [/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]The more features you add, the more the gap will close on any gains you made - the more pointless having your own will be.[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]If you can live without those features the performance gains are worth it at the instruction level.[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]The same performance gains have limited worth overall, largely due the time your program counter is in these so called problem areas. Or…there should be bigger fish to fry when you look at your performance profile.[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]It is possibly worth using your own to gain maximum performance for your run time regardless (as I say above…why thrown cycles away).[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]Rolling your own is an interesting exercise, particularly if you do look at the existing implementations. You’ll learn a lot about them and I think make wiser decisions for having that knowledge.[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]Rolling your own with the intention of supporting all the same features is pointless. Things will exist in your version for the same reason they exist in vendor versions, which have already been optimized as they are. You really will be reinventing the wheel here and you’ll do that via creating a less optimal wheel at least in the first instance.[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]Where you don’t need performance, the only possible need to use your own might be for reasons of consistency and not using two different types of containers.[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]It’s my opinion that your tools/pipeline and generally your higher level code are better off using STL/standard C++ library containers though. Why?…[/font][/size]
[list]
[*][size=3][font=arial,helvetica,sans-serif]They are more flexible and this sort of code generally needs to have that benefit[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]The same code will be more maintainable due to using something more flexible[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]Because they are standard and everyone should know them. Not everyone will be aware of the nuances of your own version, even if it’s a version shared amongst several people.[/font][/size]
[*][size=3][font=arial,helvetica,sans-serif]The advantage of the alternative has no place here.[/font][/size]
[/list]
[/list]
[size=3][font=arial,helvetica,sans-serif]YMMV of course.[/font][/size] Edited by freakchild

Share this post


Link to post
Share on other sites
traits and algorithms only (in particular sort). The generic containers are more or less banned, though a bitset has managed to make its way into our codebase since its such a pain to write one that scales up into the hundreds of bits.

Share this post


Link to post
Share on other sites
[quote name='Promit' timestamp='1339638444' post='4949011']
The biggest rule of thumb is this: [b]If you have to ask, you should use STL.[/b]
[/quote]
Quoted for emphasis; that is an [i]excellent[/i] guideline.

Share this post


Link to post
Share on other sites
I don't ever use the STL, period. Not even when time is tight and I just "need to get it done". But then again I am a die-hard [url="http://en.wikipedia.org/wiki/Common_Lisp"]Lisper[/url], so... take it for a grain of salt. Edited by Conoktra

Share this post


Link to post
Share on other sites
@Conoktra: that's not really helpful in a discussion that specified C++ up-front. Obviously users of other languages won't be using the C++ Standard Library; if one is available they might however be well advised to use the standard library of their language of choice, for the same reasons given in favour of the C++SL in this topic.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
  • Advertisement
  • Popular Now

  • Advertisement
  • Similar Content

    • By komires
      We are pleased to announce the release of Matali Physics 4.0, the fourth major version of Matali Physics engine.
      What is Matali Physics?
      Matali Physics is an advanced, multi-platform, high-performance 3d physics engine intended for games, virtual reality and physics-based simulations. Matali Physics and add-ons form physics environment which provides complex physical simulation and physics-based modeling of objects both real and imagined. The engine is available across multiple platforms:
              Android         *BSD         iOS         Linux         OS X         SteamOS         Windows 10 UAP/UWP         Windows 7/8/8.1/10         Windows XP/Vista What's new in version 4.0?
               One extended edition of Matali Physics engine          Support for Android 8.0 Oreo, iOS 11.x and macOS High Sierra (version 10.13.x) as well as support for the latest IDEs          Matali Render 3.0 add-on with physically-based rendering (PBR), screen space ambient occlusion (SSAO) and support for Vulkan API          Matali Games add-on  
      Main benefits of using Matali Physics:
              Stable, high-performance solution supplied together with the rich set of add-ons for all major mobile and desktop platforms (both 32 and 64 bit)         Advanced samples ready to use in your own games         New features on request         Dedicated technical support         Regular updates and fixes
      The engine history in a nutshell
      Matali Physics was built in 2009 as a dedicated solution for XNA. The first complete version of the engine was released in November 2010, and it was further developed to July 2014 forming multi-platform, fully manage solution for .NET and Mono. In the meantime, from October 2013 to July 2014, was introduced simultaneous support for C++. A significant change occurred in July 2014 together with the release of version 3.0. Managed version of the engine has been abandoned, and the engine was released solely with a new native core written entirely in modern C++. Currently the engine is intensively developed as an advanced, cross-platform, high-performance 3d physics solution.
       
      If you have questions related to the latest update or use of Matali Physics engine as a stable physics solution in your projects, please don't hesitate to contact us.

      View full story
    • By JoshKlint_34394
      Today we are pleased to announce the release of Leadwerks Game Engine 4.5.
      Version 4.5 introduces support for VR headsets including the HTC Vive, Oculus Rift, and all OSVR-based hardware, allowing developers to create both room-scale and seated VR experiences. The Leadwerks virtual reality command set is robust yet incredibly simple allowing you to easily convert your existing 3D games into VR titles. To help get you started the source code for our Asteroids3D game has been updated for VR and is now freely available in the Leadwerks Games Showcase.
      Leadwerks Game Engine is uniquely well-suited for VR because of its fast performance, ease of use, and the availability of C++ programming for demanding VR games. Several optimizations for VR have been made including combining the rendering of both eyes into a single culling step. The stability and accuracy of Newton Game Dynamics means we can have in-depth physics interactions in VR.

      A new VR game template has been added to provide common VR features including teleportation locomotion and the ability to pick up and interact with objects in the environment.
      Visual Studio 2017
      We've also upgraded Leadwerks Professional Edition to build with Visual Studio 2017 so you can take advantage of the very latest Visual Studio features. Instructions for upgrading C++ projects from version 4.4 to 4.5 are available here.
      Other Improvements
      Added fog settings in editor and into map file format. New joint scripts and enhancements. Updated to Steamworks 1.41 You can pick up Leadwerks Game Engine with a discount during the Steam Winter Sale.
      About Leadwerks Software
      Leadwerks Software was founded in 2006 to make game development easy and fun. The company launched Leadwerks Game Engine on Steam in January 2014 and has experienced steady growth, now with over 20,000 paid users.  Leadwerks Game Launcher was released as an early access title in September 2015, allowing developers to publish games to Steam Workshop with no submission fee.

      View full story
    • By khawk
      Urho3D 1.7 has been released. The release for the open source, cross-platform 2D/3D game engine includes a number of new features and bug fixes, including new IK support, AppleTV platform support, WebAssembly support, improved font rendering, better integration with Bullet and Box2D, renderer improvements, and more.
      Download the release and view the full changelog at https://urho3d.github.io/releases/2017/08/19/urho3d-1.7-release.html#changelog.
       

      View full story
    • By khawk
      GameDev.net member @Bleys has released a C++ library that may be useful for game developers.

      Called DynaMix, the library:
      You can access the repository at https://github.com/iboB/dynamix and documentation at https://ibob.github.io/dynamix/.
      Learn more from the thread:
      .

      View full story
    • By khawk
      Reddit user Wafflyn made useful Blueprint and C++ cheatsheets for anyone using UE4. From the post:
      UE4 Blueprint Cheat Sheet: http://uecasts.com/resources/unreal-engine-blueprint-cheat-sheet
      UE4 C++ Cheat Sheet: http://uecasts.com/resources/unreal-engine-c-plus-plus-cheat-sheet

      View full story
  • Advertisement