This makes porting to Unreal (as a 3rd-Party lib) a lot more difficult than it should be. Supporting an industry-wide standard isn’t asking too much IMO. Making it impossible to port without a substantial rewrite is an unnecessary obstacle. I would add that it is also contrary to the goals behind the (commendable) openness you have recently embraced.
My job just got at least 10x more painful. I have to reevaluate if it’s even worth the effort at this point. Please consider future support.
It doesn’t look like there are naming conflicts, so why can’t there be both stdlib and your alternative?
Sorry for the double post but I got it working! This might be the best way to go for other developers too, so I’m posting this. Hope that’s OK.
The code I am porting was only using a few templates so I just implemented my own minimal versions. It was pretty quick.
I still think that std should be possible in UE, though I guess now I wouldn’t phrase it with a tone of desperation. Maybe you don’t have to support it directly, but at least we should find a way to make it possible for someone whose code depends on it heavily. Let me know if I can be of any help.
So far as I studied, I guess we can wrap the interface with std related. Not sure whether it works, still testing! How did you fix it? Looks forward to your response.
As has sort of been implied elsewhere in this thread, a stopgap measure which would be lovely would be to have Unreal’s array class at least have the same function names and general API as the STL.
If there are memory considerations and binary compatibility considerations that actually require minor API differences or documented gotchas, great, but having, or example, begin(), end(), size(), empty() etc etc, and compatibility with standard library < algorithm > functions, etc, etc, would be fantastic.
Using std::vector would be a nice golden chalice for some, but a custom Unreal::vector would be good enough for a lot of cases.
This dead thread has been awakened.
But I too would like to know if stl will be used in ue5
Also will the source code be organized differently so that build times are faster and engine is more modular. Hopefully no external build tool will be used and build will be directly from visual studio. The pointless garbage collection mechanism should also be remove … like all the uclass, ustruct and other stuff
Highly unlikely. I can’t see any reason a game engine would want to use one of the worst parts of C++ when it already has specialised libraries of it’s own that are much more fit-for-purpose. There’s nothing stopping you from using STL right now, but you won’t find many others doing it and for good reason.
Possibly, as that is where the engine was heading anyway. Most of the newer engine features are sectioned off into their own modules. Naturally, there will always be dependencies.
Nonsense. The garbage collection and reflection system is one of the most powerful parts of UE4, and again, it’s properly fit for purpose. There’s zero reason to suspect any of that will be removed, or that much of the underlying engine architecture has changed at all.
The answer to this thread at large is the same as it’s always been - UE’s own containers are fit-for-purpose and in most cases far superior to the STL/STD counterparts.
Well TheJamsh – you sure have a lot of posts here! stdlib containers are quite fine now in modern C++. And Unreal containers are a real sticking point for developers switching to Unreal. alluded to the possibility earlier and gave a good explanation, so would love to hear an official answer.
said once that UE development began before stdlib was where you’d really want it to be. Then the hitch became that stdlib still either wasn’t implemented well on target platforms or wasn’t standard across them, so you still ended up with a framework layer on top of it. He said that he’d like to see UE move to supporting straight stdlib one day but it would be a big refactor.
I think they’d have to start a stdlib branch and you’d need to choose what you wanted to use, while at the same time knowing that the old version would stop existing one day.
If it did move to stdlib then that would increase the amount of supporting documentation available since it’d no longer need to be UE-specific. At the same time if we’re going stdlib then we should continue the UE framework that’s built on top of it with a new focus to ease of use, or scripting. Make a decision on what should be stdlib and what can just be macros and functions that give you the best-practices behaviour for high level stuff. Ultimately the UE framework is easier for new people than stdlib is, as it has a very narrow design pattern that is easy to replicate and wraps a lot of fundamental stuff with good practices that suit UE.
Speaking of post gilding, are the avatar icons to the left new? I’ve never noticed them before.
I particularly see zero reason for this to change since we can already use std and build wrappers when I really have to.
But what do I know anyway, if ever say “yes” I say “why not”!
It won’t, and why would it? Epic have spent a lot of time writing their own far more fit-for-purpose types and methods that do the job much better. There’s no reason to use STL/STD in UE4 - but if you really want to punish yourself, there’s nothing stopping you from doing it for the most part.
As for official word on the matter, the fact that Epic have stated that UE4 projects will transition to UE5 with minimal effort should be enough.
While it’s obvious that UE4 containers are better, I think it’s also obvious that there should be C+±style constructors and converters for every kind of container, at least optional. There are infinite variety of C++ libraries that use std::string and conversions back and forth are all over the place if you have to use one. It would be incredibly convenient to have something like myFString.ToStdString() or FString(const std::string&) constructor instead of these macros, pointer dereferences and .c_str()s.
The cost of using std::string in these libraries instead of rewriting stuff for not using std::string is often negligible in the front of development speed boost and usability if such convenience functions were present.
The same goes for most-used containers (std::vector, std::unordered_map), but these are not as important as std::string
This is not actually true. The standard library is targeting different benchmark targets/environments than the Unreal Engine. The memory/cache/branching/data-dependency trade-off space is huge, and the Unreal containers sit on a different hill than the standard library.
More importantly, the Unreal contains support the Unreal Engine reflection system, which is what underpins pretty much all of what the engine can do. CAN you write some kinds of adaptors that make the standard library containers provide the same reflection features as TArray and friends? Probably. But it would be a lot of work, and in the end, you’d have to live with whatever decisions the standard library authors chose, rather than the decisions that a game developer chose.
Also: You don’t need to glue conversions to the classes themselves. You could just have a header of free functions that convert.
The code you write would, in my opinion, not only look better than gluing member functions to specific classes, but it would also be more flexible. Free functions are your friend!
I’m really looking forward to UE switching to STD, and with like any proper sexually transmittable disease, perform poorer and die off until it is rid of it.
Specialized solutions are always a better choice than a general purpose one, every proper game engine has its own implementation of a standard library and its own custom memory allocation system because it fits the “real time / high performance / data driven” software, which is games, better.
Because…? More performant? If yes, do you have any measures? Or maybe has better API? Or Something else?
Can you explain?
AFAIK all reflection stuff are doing by dummy macros and UHT code-generator. Can you give me some TArray implementation feature that treat USomething* different than native C++ type?
Does TArray<> without UPROPERTY still handle reflection?
I would love to know more about the Unreal Engine “custom allocation model”. I would be grateful for any clarifications, because tracing NewObject<> function bring me to simple malloc.
The latter is wrong in general (it does the job better only if you are used to the system, but not when comin from std background). And just because you spent time on something in past is no reason for keeping it.
I speculate the main reason to keep the custom implementations is that they are good enough and it would be a lot of work to replace those. High cost/risk*, low short term benefit, esp. from the UE4 developer point of view (high benefit for those which are not used to UE4).
The main issue I see with the custom implementations: Upgrading to newer C++ versions takes time. AFAIK UE4 is still on C++14 level while we have C++20 around the corner. So developing for UE4 comes with lost productivity if you are
a) used to std types and algorithms
b) used to newer cpp implementations
True, but this increases build time which wouldn’t be the case if UE4 already would use std.
*E.g. build times could suffer b/c of the heavy usage of templates within std libs. (on the other hand, the UE4 classes also use templates, so maybe a not-so-issue)
PPS: Until one comes with measurements, those performance claims are bull* and not worth discussing.
Also, if user uses any third-party library, compiler will do double work of parsing std headers and UE4 library. And that’s the majority of cases, I think
Fortunately, it building supports C++17 already and I use it. Can’t wait to have C++20 features
