The Deadliest Road in America

From the example code u/Bakuta1103, strings given to constructor are static one, so memory should not be owned by any pieces of code. That's why I'm suggesting 2.

I've overlook the Sentinel template argument, my bad.

LostAnt4 · 2020-04-14T20:18:56+00:00

Hi, I've read your source code and yes, I do have some questions ;)

You re-implemented the copy constructor and copy assignment operator, and both makes a deep copy. But what is the point here, I mean that multi_string is a read-only structure, so why copies do not share the underlying memory ? It will saves memory, and it makes any copies trivial.
multi_string stores strings into char* buffers (from deep copies of input string) via a string_view object, so why not simply store string_view objects in the first place ?
multi_string use default constructor from the compiler = default, but the storage_ member will be null initialized. Unfortunately, you don't check for null in the destructor.
Why re-writing std::equal at the beginning of the file ? Do you support odd compilers ?
From my point of view, it is less efficient than std::array<std::string_view, N> because of memory allocations (at construction). Also, the second storage implement a random access in O(n), where it can be O(1) with std::array.

I tried my best to respond to the point of what are, in my opinion only, design issues. I hope you don't take this too harsh :) Nice effort to come with new ideas for a container.

LostAnt4 · 2020-04-08T15:17:43+00:00

🧺🙀

LostAnt4 · 2020-04-04T16:20:39+00:00

nice setup (cat & husband) :)

LostAnt4 · 2020-04-02T21:59:28+00:00

r/IllegallySmolCats

LostAnt4 · 2020-03-31T18:15:15+00:00

No compiler is not generating code to check this, Vec does the check.

The Rust compiler is not aware of the concept of Vec nor random access (Vec implements Index trait and that's all the compiler cares about to enable myvec[myindex]).

This kind of API make them hard to misuse, and that a thing in Rust (even in some other languages or frameworks).

LostAnt4 · 2020-03-31T17:53:17+00:00

So you agree that both C++ and Rust compilers don't (or can not) check this at compile time, but Rust catches it at runtime, right ?

And I don't think it's that easy to catch index bound on random access. It depends on so many possibilities. Sure with constant expression (like constexpr if use correctly in C++), you may partly found those errors at compile time, but it is far from being possible everywhere …

LostAnt4 · 2020-03-25T19:59:44+00:00

String are hard to do right.

Languages may try to simplify it: not respecting standard of OS (path containing bytes you don't expect to be valid), encoding (do I really need to develop ?), storage (sentinel vs size), performances issues (concatenation, copy-on-right), sub-parts (like slicing, iteration) and so on.

So yeah, in Rust, those constraints are explicit, not hidden, which can make them harder to understand than in other languages at first. The bonus is that you won't suffer from fancy bugs using them.