I'm having a bit of a disagreement with ChatGPT. ChatGPT seems convinced I have to call move constructor on all objects 1 by 1, but to me memcpy seems fine for 99.99% of cases I can think of, only causing issues if the move constructor has to for some reason update some pointer pointing to the objects location in memory. I've never really heard of this pattern. Any advice?
#is memcpy fine for MyVector resizing for (almost) any arbitrary type?
royal swallow
astral meadowBOT
frosty thunder
the phrase you're looking for is trivial relocatability
which is related to a feature that almost made it into C++26
so on the one hand you're right that in principle, memcpy would be fine for most types
however, that's not how the language currently works
if your types are implicit lifetime tpyes, then I think you can implement reallocation by using memcpy
but if they aren't, that's technically UB I believe
royal swallow
the phrase you're looking for is trivial relocatability
is something like a string "trivially relocatable"? I think it is, right?
frosty thunder
a std::string isn't trivially relocatable
there are different ways to implement it
but at least one common implementation can store a pointer into itself in the std::string
that's because of Short String Optimization: For short strings, std::string doesn't have to allocate
royal swallow
but at least one common implementation can store a pointer into itself in the `s...
interesting. I can't see how this isn't a waste of memory.
ohhhh
frosty thunder
that's because of Short String Optimization: For short strings, `std::string` do...
it avoids that by storing the characters inside the object itself
royal swallow
right, I see. I think that explains it, thanks
frosty thunder
but that means that now you either need to make functions like begin() more complicated, or store a pointer into the object
astral meadowBOT
@royal swallow Has your question been resolved? If so, type !solved :)
royal swallow
!solved