Improve Container Types #180

Mozz3d · 2025-02-07T20:55:15Z

No description provided.

include/RED4ext/Containers/DynArray.hpp

include/RED4ext/Containers/Span.hpp

include/RED4ext/Detail/Containers/ArrayIterator.hpp

wopss · 2025-02-11T09:27:10Z

include/RED4ext/Containers/DynArray.hpp

+    template<ContainerType TContainer>
+    DynArray(const TContainer& aContainer, Memory::IAllocator* aAllocator = nullptr)
+        : DynArray(aAllocator)
+    {
+        Assign(aContainer.begin(), aContainer.end());
+    }
+
+    template<ContainerType TContainer>
+    DynArray(TContainer&& aContainer, Memory::IAllocator* aAllocator = nullptr)
+        : DynArray(aAllocator)


Is there a valid use case for this? I can't think of any, and you will have to handle special cases, such as Map.

I gave some of my reasons in discord, but yes I think so. Also the template using the ContainerType concept to enforce what exactly can be used here, so things like Map aren't a concern afaict

Why not do something like:

template<typename InputIt> requires std::input_iterator<InputIt> DynArray(InputIt aFirst, InputIt aLast, Memory::IAllocator* aAllocator = nullptr)

?

Because I have a habit of over-complicating things when I haven't slept :)
Thank you

You dont have to use requires in that case, just template <std::input_iterator InputIt> is enough, maybe can be even included in the signature itself, getting rid of the template keyword alltogether if you do not need to do something with the type.

And looking at the code now, think you should be able to do just that.

DynArray(std::input_iterator auto aFirst, std::input_iterator auto aLast, Memory::IAllocator* aAllocator = nullptr)

Unsure if it is wanted to be passed by value though, need to look at the implementation in full finally... If you need to pass by reference in the simplified case, just put & after the auto in the above.

You can actually do sth like that in multiple places from quick glance, you dont seem to be accessing the type explicitly in many of them. Using template keyword in such cases is a bit of a waste.

Actually, rereading my comments, you may not want to do the simplified case without template in the end here as it would match 2 distinct input iterators on input... Still could be done in some other places.

This variant should be used here to ensure same type. #180 (comment)

wopss · 2025-02-11T09:29:24Z

include/RED4ext/Containers/DynArray.hpp

+        if (capacity)
+            std::destroy(begin(), end());


No need for the check. std::destory is well defined in this case.

This is more like a comment, not a request for change, so if you want feel free to keep it.

wopss · 2025-02-11T09:31:39Z

include/RED4ext/Containers/DynArray.hpp

+        Assign(aItems);
+    }
+
+    DynArray(uint32_t aSize, Memory::IAllocator* aAllocator = nullptr)


Suggested change

DynArray(uint32_t aSize, Memory::IAllocator* aAllocator = nullptr)

DynArray(SizeType aSize, Memory::IAllocator* aAllocator = nullptr)

wopss · 2025-02-11T10:38:26Z

include/RED4ext/Containers/DynArray.hpp

+    {
+        if (this != std::addressof(aOther))
+        {
+            Assign(std::make_move_iterator(aOther.begin()), std::make_move_iterator(aOther.end()));


This is having a complexity of O(n), Before it was O(1), do the swap trick.

wopss · 2025-02-11T10:40:23Z

include/RED4ext/Containers/DynArray.hpp

+    template<ContainerType TContainer>
+    DynArray& operator=(TContainer&& aOther)
+    {
+        if (this != std::addressof(aOther))
+        {
+            Assign(std::make_move_iterator(aOther.begin()), std::make_move_iterator(aOther.end()));
+        }


Again, no usecase for this.

wopss · 2025-02-11T10:43:58Z

include/RED4ext/Containers/DynArray.hpp

+        if constexpr (std::is_trivially_copyable_v<ValueType>)
+        {
+            auto begin = *aBegin;
+            std::memcpy(Data(), &begin, newSize * sizeof(ValueType));
+        }


Never do a memcpy or memmove. You might have pointers in the object that can point to itself, or to another variable in the object. Doing a copy you will have undefined behavior.

Never is a strong word I would say but yes, probably not good for collections. If copy is needed, std::copy family or ranges version of them should be used.

Which may end up as std::memcopy or memmove depending on underlying type. But it does call moves etc. when type requires it.

wopss · 2025-02-11T10:45:02Z

include/RED4ext/Containers/DynArray.hpp

+        if (aSize > Capacity())
+            Reserve(aSize);
+


Suggested change

if (aSize > Capacity())

Reserve(aSize);

if (aSize > Capacity())

{

Reserve(aSize);

}

wopss · 2025-02-11T10:46:46Z

include/RED4ext/Containers/DynArray.hpp

+    T* entries;        // 00
+    uint32_t capacity; // 08
+    uint32_t size;     // 0C


Can be private.

wopss · 2025-02-11T10:48:23Z

include/RED4ext/Containers/DynArray.hpp

+
+        if constexpr (std::is_trivially_copyable_v<T>)
+        {
+            std::memmove(aDst, aSrc, aCount * sizeof(ValueType));


Related to the previous memmove comment. memcopy and memmove are C constructs.

Are you suggesting I change this?

wopss · 2025-02-11T10:49:48Z

include/RED4ext/Containers/StaticArray.hpp

+    [[nodiscard]] constexpr Reference Front()
+    {
+        assert(!Empty());
+        return Data()[0];
+    }
+
+    [[nodiscard]] constexpr ConstReference Front() const
+    {
+        assert(!Empty());
+        return Data()[0];
+    }
+
+    [[nodiscard]] constexpr Reference Back()
+    {
+        assert(!Empty());
+        return Data()[Size() - 1];
+    }
+
+    [[nodiscard]] constexpr ConstReference Back() const
+    {
+        assert(!Empty());
+        return Data()[Size() - 1];
+    }


Imo, things like begin, front, etc. should only be STL style to not have duplicated. Wdyt?

Same for DynArray, Span.

Yeah definitely + from me on this.

Could you elaborate on what you mean a little? Im not sure if you're referring to just casing or something else aswell

I think it should be either STL or our style (STL conformant or not), but not both, with only exceptions for compliance with named requirements, range-based for loop, etc. If we want to keep our naming, then it should be Size(), Begin(), Front(), etc. Things like begin() and end() should be in a separate "compliance" region, not mixed in with the rest. What's the purpose of lowercase front() btw?

I don't think lowercase front has any purpose, but I made a typo, I wanted to say being, end, etc. Basically, everything that is needed for range-based loop.

For these requirements, I would say to just use the lowercase (STL variant) naming, instead of having both.

I'd keep Begin and End for consistent naming (you still need to use them explicitly) and not consider begin and end as part of our interface.

I dont know what you mean by consistent naming now - consistent with what? Other functions? Other collections not touched by this (if there are any)?

I would rather not have 2 functions doing the same thing personally, even if it would cause some function ToBeLikeThis and some like_this following std.

Mainly when they should be compatible with it, 2 of anything unnecessarily is a waste in my eyes.

Consistent across the class at least, ideally across the project. begin and end should not be considered functions of a class, but unfortunately C++ doesn't have a way to handle it properly. For example, C# supports explicit interface implementation that would hide begin and end from class.
Begin and begin have different purposes, and that's what matters, how they're implemented is irrelevant. begin exists to support range-based for loop, for everything else there's Begin.

WSSDude · 2025-02-12T04:06:48Z

include/RED4ext/Containers/DynArray.hpp

+    }
+
+    template<ContainerType TContainer>
+    DynArray(const TContainer& aContainer, Memory::IAllocator* aAllocator = nullptr)


It could be done here for example

https://github.com/wopss/RED4ext.SDK/pull/180/files/937f56dff17f36dd9f21867b8d0947685f204709..6080dc94c662a07d0bc97bcc2834c5072fd7c2c2#r1951944671

Mozz3d added 4 commits February 7, 2025 15:36

Adjust file paths

4756017

Improve Container Types

880f4bd

Fix include path

b6f4513

Adjustments

937f56d

wopss requested changes Feb 9, 2025

View reviewed changes

Mozz3d added 4 commits February 11, 2025 02:22

Several improvements & adjustments

6080dc9

Fix mistake & ArrayIterator crediting

00a2473

Fix errors

3ae9d42

Fix compiler warning

9a904b4

wopss requested changes Feb 11, 2025

View reviewed changes

WSSDude reviewed Feb 12, 2025

View reviewed changes

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Improve Container Types #180

Improve Container Types #180

Mozz3d commented Feb 7, 2025

wopss Feb 11, 2025

Mozz3d Feb 11, 2025

wopss Feb 11, 2025

Mozz3d Feb 11, 2025

WSSDude Feb 12, 2025

WSSDude Feb 12, 2025

WSSDude Feb 12, 2025

WSSDude Feb 12, 2025 •

edited

Loading

wopss Feb 11, 2025

wopss Feb 11, 2025

wopss Feb 11, 2025

wopss Feb 11, 2025

wopss Feb 11, 2025

WSSDude Feb 11, 2025

wopss Feb 11, 2025

wopss Feb 11, 2025

wopss Feb 11, 2025

Mozz3d Feb 11, 2025

wopss Feb 12, 2025

wopss Feb 11, 2025

WSSDude Feb 11, 2025

Mozz3d Feb 11, 2025

psiberx Feb 11, 2025 •

edited

Loading

wopss Feb 11, 2025

psiberx Feb 11, 2025

WSSDude Feb 12, 2025 •

edited

Loading

psiberx Feb 12, 2025 •

edited

Loading

WSSDude Feb 12, 2025

	DynArray(uint32_t aSize, Memory::IAllocator* aAllocator = nullptr)
	DynArray(SizeType aSize, Memory::IAllocator* aAllocator = nullptr)

Improve Container Types #180

Are you sure you want to change the base?

Improve Container Types #180

Conversation

Mozz3d commented Feb 7, 2025

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

WSSDude Feb 12, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

psiberx Feb 11, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

WSSDude Feb 12, 2025 • edited Loading

Choose a reason for hiding this comment

psiberx Feb 12, 2025 • edited Loading

Choose a reason for hiding this comment

Choose a reason for hiding this comment

WSSDude Feb 12, 2025 •

edited

Loading

psiberx Feb 11, 2025 •

edited

Loading

WSSDude Feb 12, 2025 •

edited

Loading

psiberx Feb 12, 2025 •

edited

Loading