MikeGitb

> Honestly the #include "" version can be much more confusing. yes, it's convenient but what happens when the files get moved? More things tend to break. Further it leaves...

I guess the best course of action depends on the concrete case. Two possiblilities that come to mind are - Use std::move, if the ype(s) are cheap to move -...

I like the Idea to stick with the stl behavior for now, but would love to see more data about the need for stronger rules. Has anyone had anekdotal or...

> which implies that types with const members (i.e. immutable) are neither concrete nor regular. I think you are creating false dilemmas here. As I said in the other thread:...

A word is commonly two bytes, but the important part of the statement you quoted is that you can't give an exact number, because the cost it depends on the...

Sorry, was thinking in windows terms.

I think thats about a struct that has a reference as a member. EDIT: But I agree, that - even if I'm right - some clarification would be useful.

I think, much more important than the size is whether the type is trivially copyable or not. For trivially copyable types, I find the rule of thumb in the rules...

> The desgin fix for code reusing is in moving of common part into separate base class (VecBase ?) with protected destructor and inherit it by Vec : public VecBase...

Correct me if I'm wrong, but I thought using bit_cast as a 1:1 replacement for reinterpret cast ist almost always wrong. Afaik the idea is not use `bit_cast` to cast...