Rebel Fork Framework
Container types

Urho3D implements its own string type and template containers instead of using STL. The rationale for this consists of the following:

  • Increased performance in some cases, for example when using the PODVector class.
  • Guaranteed binary size of strings and containers, to allow eg. embedding inside the Variant object.
  • Reduced compile time.
  • Straightforward naming and implementation that aids in debugging and profiling.
  • Convenient member functions can be added, for example String::Split() or Vector::Compact().
  • Consistency with the rest of the classes, see Coding conventions.

The classes in question are String, Vector, PODVector, List, HashSet and HashMap. PODVector is only to be used when the elements of the vector need no construction or destruction and can be moved with a block memory copy.

The list, set and map classes use a fixed-size allocator internally. This can also be used by the application, either by using the procedural functions AllocatorInitialize(), AllocatorUninitialize(), AllocatorReserve() and AllocatorFree(), or through the template class Allocator.

In script, the String class is exposed as it is. The template containers can not be directly exposed to script, but instead a template Array type exists, which behaves like a Vector, but does not expose iterators. In addition the VariantMap is available, which is a HashMap<StringHash, Variant>.

C++11 features

Aggregate initializers:

VariantMap parameters = { {"Key1", "Value1"}, {"Key2", "Value2"} };

Range-base for loop:

for (auto&& item: container)
{
}
Urho3D::VariantMap
ea::unordered_map< StringHash, Variant > VariantMap
Map of variants.
Definition: Variant.h:102