Moving to C++11


I think that the biggest issue is not about implementation, but about interfaces. There are a lot of downstream projects. It would be cruel to make their authors to fix their code.
It is possible to rewrite e.g. EASTL to fit it into legacy interface of Urho containers, but it will require some effort.

That’s because they don’t provide any debugging information, which defeats the purpose.
I know that in my code I had to replace things like HashMap with std::unordered_map to be able to debug their content.

wat? :confused:

What kind of STL debug garbage do you need?
If I want to debug Urho containers, I do it in debugger.


Try doing that.

Here’s what I see:

Which doesn’t happen with std containers.


Additionally, you’ll need some knowledge about debug visualizers. Complex stuff like HashMap also requires VS 2015.
It’s not very hard to make it work, check this.


Thanks for the VS2015 Visualizer file! That really works. It helps a lot when debugging.



BTW when debugging std::unordered_map you can see the original strings (with the visualizer you only see hashes).
I assume std::unordered_map stores the strings in debug which makes it slower, but provides useful information.


That’s because Urho3D::VariantMap is HashMap<StringHash, Variant> and don’t contain names.
So, that’s not a question to visualizer or debug info. More likely, it’s about performance and amount of allocations made by VariantMap.

HashMap<String, Variant> will give you real strings, of course.
I mean I hope so because I tested my visulaized long time ago.


Don’t wait on me. An upgrade to C++11 will be massively beneficial to most of the pending stuff. Variadic templates could really simplify shaders (aside from the hash-code … which will just get fatter, but the pipeline looks pretty fixed now so that’s just 64bit int).

The only thing I’d like to push out before then would be cubemap filtering (that also means DDS writing, have to write those mipmaps for filtering them to really be worth anything).

  • Offtopic, is there a footer sytem so I can indicate “keep it on technical point” or such? I want to keep my involvement to task at hand, not idealogy and such.


Rule no. 1 for system changes:
If it ain’t broken, don’t fix it.

If the custom containers work just fine and impose no performance/memory downside, there’s no reason to switch to STL ones. Obviously, this can be tested and it seems some did that already (and seemingly there’s no reason to switch).

Auto… oh, auto… Let’s not. Please. I like to read my code and understand it without having to move back through functions until a real type appears somewhere.
I see the point in using it for abbreviation purposes, though. Iterators are a good example, because their type declaration usually looks like it was made to make people suffer. If there is a “auto iter = someContainer.begin();”, everybody will understand it and some (like me) will be thankful. A typedef is IMO not a solution here because it just moves the problem out of sight (you got the ugly piece of code elsewhere, but it is still present).
But in all other cases, auto just adds confusion instead of clarity.
Either way, there is no gain in replacing working existing code with it.

I can’t say much about other issues like with variadic templates. Personally, I avoid templates like the plague, because I like to retain my sanity when reading error outputs. Of course, I see the point in them, so if existing code can actually be made more readable or more performant with them, I’m all for it.
As long as I don’t have to write them, I really don’t care if a library I use makes use of them :smiley:


If you need iterator, you probably have container, e.g. Vector<SharedPtr<Object>>.
Such container is probably used in several places and may be typedef-ed.
ObjectArray::Iterator is much less scary, isn’t it?
But it is an issue what is more readable: long name with all related types or typedef abbreviation.

This is not a problem of auto itself. It’s mostly about ‘interface-oriented’ programming style when you work with public interfaces (e.g. public methods or properties) instead of concrete types. C++ templates are usually written in such style, and this style is common for script languages like Lua or Pyhton.
And I agree that ‘interface-oriented’ code is harder to understand than classic ‘object-oriented’.

Urho has a bucket of rules like ‘no tabs’, ‘use camel case’ etc. They are strict and easy to follow.

The probem with auto is that anybody have his own criteria where to use auto and where not to use.
If @cadaver just say ‘follow the common sence’, Urho may end up in codestyle mess because everybody has its own (of course, evident) rules.

Just look at these examples and try to answer where to use auto and where not to (and why):

  1. Vector<HashMap<String, Pair<Node, Component>>>::Iterator
    very long and ugly iterator

  2. Vector<SharedPtr<Component>>::Iterator
    just quite long iterator

  3. Vector<SharedPtr<Component>>
    this type is not an iterator, but still long

  4. Vector<SharedPtr<Component::Data>>
    as long as 2) but almost the same as 3)

  5. const Vector<SharedPtr<Component>>&
    as long as 2) but the same as 3)

  6. Vector<int>::Iterator
    pretty short iterator

  7. HashMap<String, int>
    as long as 6) but not an iterator

  8. const HashMap<String, int>&
    longer than 6) but not an iterator


I just looked at the Turso3D codebase and there I have used auto for iterators only (shortening & convenience). That could be one possible rule that’s at least easy to follow. But I don’t want to say it should be the rule, or that I’d want final authority on this matter. I agree that it’s just important that we decide something that is clear to follow.


That’s pretty much how I’ve been using ‘auto’ as well.


I have two more cases. auto shall (may?) be used

  • with any iterators if there is no one-word alias
  • with any pairs and pair-like structures (e.g. HashMap<T, U>::KeyValue>) if there is no one-word alias
    • However, prefer to extract pair content into variables with meaningful names
  • with unknown template types if there is no one-word alias
    • So, use auto instead of those ugly typenames and decltypes

Such rules are also pretty clear to follow, IMO.


I am in favor of using standard containers. Less confusion and better interoperability with other libraries not to mention not having to maintain said containers. Custom stuff is only useful if it provides something standard stuff does not. But is there really any benefit nowdays?


Urho’s HashMap doesn’t handle collisions, so it’s faster but less reliable than std::unordered_map.


Why do you think so? This sounds very strange. Generic HashMap container must handle collisions.


It seems I’m wrong, for some reason I remembered it doesn’t handle collisions.


At the same note we really should drop old cmake support. New versions have some useful goodies that would help simplifying build system, and boy oh boy we do need that. For example i came upon target_compile_definitions just now. The only reason to hold back on cmake would be having easy support for linux distributions, however new ubuntu LTS (16.04) already ships cmake v3.5. For windows it does not matter as user just installs latest and greatest from cmake website.


I rescind a desire to squeeze out cubemap filtering, I’m butting heads intensely with just interacting with cmft and the like remotely without crashing as a post process, that’s a red flag. It’s also just not going to fit even in a case of relying on other tools. I would much rather see a hard release and then work on finishing surround and LFE sound.


Travis CI still uses an ancient version of cmake. You’d break integration tests by using newer cmake stuff.


Just dropping by to say that there is no reason to set the minimum required CMake version higher than it needs to be. That is, we should only increase the version to the level our script really utilizes. Setting a high version number does not automatically make our build system better. I do agree on the point that we should modernize the scripts to take the advantage of some of the newer features and idioms provided by newer CMake though.

Also keep in mind there is more Linux distros out there than Ubuntu. So what CMake version it shipped in what LTS version does not have too much bearing on our decision making, except for our CI need as highlighted by TheComet.

And lastly. please stay on topic.