Okay, I’m gonna extract this question into separate thread to keep discussion on-topic.
Currently there’s very good opportunity to move Urho from custom containers to proper 3rd party container library. Most of the porting is already done.
The issue is that this change is breaking. There are adapters that covers common cases but they don’t provide 100% backward compatibility. And names are not in
CamelCase /outcry of shock/.
What this migration offers:
- Container library maintained by companies instead of custom-made library that nobody maintains;
- Move-semantics friendly containers;
- Containers that don’t allocate memory dynamically;
Why one may want this change?
When a person is used to work with
std container library in its entirety (more than just
vector.push_back), using custom Urho Containers becomes a pain. There’re so many things missing. I have refactored
Urho3D::Vector<T> two times when I needed something from it and it’s not even close to “enough”.
Small buffer optimization? Nope. Allocators? Nope. Algorithms? Nope. Containers except vector and hash map? Nope. Move semantics? Barely. Spans and string views? Nope.
Urho is outsourcing physics, navigation, image decoding and tons of other tasks. Why it cannot outsource container library too?
So, what do you think? Is it worth it?
- [supportive] I want to switch to EASTL or std library.
- [supportive] I don’t need any features from EASTL but I’m ok with switching to it.
- [against] I don’t want to switch to EASTL but I have a proposal how to make Urho Containers more convinient to use.
- [against] I don’t want to switch to EASTL and I have nothing to suggest.