That is not correct, &Vec is fundamentally different. &str, &[T], and &Path are all "a pair of a pointer and a length," and String, Vec<T>, and PathBuf are all "a triple of a pointer, a length, and a capacity.".
&Vec<T> is "a pointer to a triple of a pointer, a length, and a capacity."
I'd be happy if languages would adopt Vec2 Vec3 and Vec4 as standard data types - both float and double. I understand there are ways to create these in most any language, I just want them standardized so we can all write code the same way and get the performance of some vector instructions without using intrinsics.
Yes. Over 15 years ago I proposed a library for Vec2, Vec3, and Vec4 to the C++ standards committee. It's the one from Graphics Gems, but rewritten as all inline.[1] The C++ standards people wanted more usage of templates.
That's a hard one to get right; for a long time, C++ compilers would tokenize 'vector<vector<int>>' incorrectly and throw a syntax error -- the final two angle brackets had to be separated by a space for the code to compile.
Vectors don't 'contain' numbers, a vector is a multidimensional value. The fact that a C++ vector is conceptually a container for values more than anything else is a reason why 'vector' is a poor name for this component.
I swapped std::string and std::vector when writing that comment :/ But still, there's no need for a vector to necessarily keep three pointers, it could use a pointer and two sizes for example.
It still blows my mind that people have to define Vec3 and Vec4 types. These should be native to modern programming languages as should Vec2. Modern CPUs have vector registers that can support these sizes and GCC has intrinsics for them that can be passed by value (even returned from a function IIRC), added and subtracted or multiplied by a scaler, and yet no language that I'm aware of has them as built-in types.
Vectors are not just for parallel computations, these small sized ones deserve to be a proper data type.
> It's an ABI break to add small-size optimizations to std::vector at this point so unfortunately while there's not really anything in the API requirements that would prevent it, compatibility concerns pose a formidable barrier
It's also a tradeoff as you would either need additional branching on access (this is what most std::string implementations do) and/or bloat the size of all vector objects, even those that will never fit into the static size.
> the lack of move constructors, which (should) make Vec<T> faster than std::vec.
So you are saying that the lack of move constructors (hence copying the structure) will make Vec<T> faster than std::vector? I don't follow that logic, wouldn't it actually be slower?
> I was going to point out that if you std::move a uniq_ptr, it becomes null
The original becames null because the semantic is actually tranfering ownership which might be desirable depending on the case. Also you need it in case you are using custom deleters.
(C++ doesn't have a ':' operator, you'll need to use some other symbol.)
reply