Announcement

Collapse
No announcement yet.

Why doesn't UE utilize STL containers?

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

    #16
    Originally posted by Michael Noland View Post
    These sorts of operations are supported via TArray<T>::AddUnitialized or TArray<T>::AddDefaulted (the first doesn't run the constructor, and relies on you knowing what you are doing, the latter runs the default constructor for T). You can also call Empty(Size) to reserve enough room for a specific number of elements if you want to add a few at a time later on but don't want to reallocate as you go.

    Cheers,
    Michael Noland
    Ahh I didn't realize I could use Empty(Size) for that, of course! Thanks. It would be nice to have a constructor variant of the AddUninitialized or AddDefaulted methods (preferably the latter) so that they can be constructed to size (and have elements constructed) at the point of initialization of a class within which they're member variables. It's not the end of the world but I miss that from std::vector.

    Comment


      #17
      Originally posted by HateDread View Post
      Ahh I didn't realize I could use Empty(Size) for that, of course! Thanks. It would be nice to have a constructor variant of the AddUninitialized or AddDefaulted methods (preferably the latter) so that they can be constructed to size (and have elements constructed) at the point of initialization of a class within which they're member variables. It's not the end of the world but I miss that from std::vector.
      Actually, at one point TArray had such a constructor and did the equivalent of AddUninitialized. It got removed because it was deemed unsafe to not explicitly mention 'Uninitialized' when doing an uninitialised resize. Also, it caused confusion about whether or not the constructor was resizing or reserving. This was also before AddDefaulted existed.

      Familiarity and compatibility is one of the motivating factors behind a move to standard containers/algorithms. For some of the reasons already touched upon (like problems with the standard allocator model), it may be the case that we end up with our own 'UESTL' which, like EASTL, will be our implementation but which 'quacks' like the standard.

      In any case, it's unlikely to happen any time soon.

      Steve
      Senior Core Programmer, UE4, Epic Games UK

      Comment


        #18
        How easy would it be to make things blueprintable if not using internal implementations?

        It seems like TArray for example is built to be blueprintable, but then again other types like TMap and TSet aren't so that's not even an issue. Not sure why they aren't or if there are plans to make them blueprintable later though. Would be nice if they were blueprintable

        Comment


          #19
          Since you guys brought up UE5 will it be free like UE4? Plus another question. Is the STD slower then the UE4's lib?

          Comment


            #20
            Making C++ implementations blueprintable - exposing to the editor, is as easy as it could be for the most part since all you need is a UPROPERTY(...), UFUNCTION(...), UCLASS(...), etc before the appropriate declarations.
            UE5 will likely be as free as UE4, as it can be quite awkward to go from one financial model to another. Especially more so if you ask for a higher paying price.
            I expect the stdlib and UE4's lib to be similar in performance seeing as how the both use move semantics - though I suppose the specific implementation may potentially not be ideal.

            Comment


              #21
              Epic:

              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?

              Comment


                #22
                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.

                Cheers,
                Jin

                Comment


                  #23
                  Hi,

                  I am working on this std isolation issue as well.

                  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.

                  Comment


                    #24
                    Does TArray really not have a binary search aka lower_bound?

                    If it does, someone else had as much trouble as me finding it and tacked it on in SSequencerTreeView.cpp

                    Comment


                      #25
                      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.

                      Comment


                        #26
                        Very excited about the UE5 announcement! So Mr. Tim Sweeney, are std containers going to be a thing in UE5?

                        Comment


                          #27
                          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

                          Comment


                            #28
                            Originally posted by asdzxcv View Post
                            But I too would like to know if stl will be used in ue5
                            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.

                            Originally posted by asdzxcv View Post
                            Also will the source code be organized differently so that build times are faster and engine is more modular.
                            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.

                            Originally posted by asdzxcv View Post
                            The pointless garbage collection mechanism should also be remove ... like all the uclass, ustruct and other stuff
                            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.
                            Last edited by TheJamsh; 05-14-2020, 04:37 AM.

                            Comment


                              #29
                              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. Tim alluded to the possibility earlier and gave a good explanation, so would love to hear an official answer.

                              Comment


                                #30
                                Tim 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.
                                Last edited by Antidamage; 05-14-2020, 01:10 PM.

                                Comment

                                Working...
                                X