C++ is love
-
- you want to disable copy and move operations (constructor and assign operation) on
StaticMemoryPooland copy operations onDynamicMemoryPool10)~StaticMemoryPool() {}don't provide user-defined special members functions if they are not really necessary and if you do have to define them because language rules deleted them, use= defaultto retain possible triviality of these operations General rule is if you need to provide a single user-defined SMF, you need to provide them all. It was called rule-of-three, now it's known as rule-of-five. Think about using clang-format and clang-tidy (they integrate well with VS these days).
Okay I am aware of the rule of five but I don't actually want copy and move operations to work, consequently, no move and copy operations. Currently if I try to do those things, I'm pretty sure it doesn't compile. What's wrong with that?
Real programmers use butterflies
- you want to disable copy and move operations (constructor and assign operation) on
-
Okay I am aware of the rule of five but I don't actually want copy and move operations to work, consequently, no move and copy operations. Currently if I try to do those things, I'm pretty sure it doesn't compile. What's wrong with that?
Real programmers use butterflies
Are you sure it does not compile? [Copy and move operations does not produce error](https://godbolt.org/z/8vadqM) Rules for which SMFs get deleted by compiler and which remain defaulted are a bit complex, so that's why it's better to be explicit about it and
= deletethose that you don't want and= defaultthose that you want to keep. The second point is to always prefer= defaultover{}since you retain triviality which is actual concept. Trivial type are easier to handle, subject to more optimizations and can be used in wider range of situations. It something that you probably don't need for arena allocator, so in this case it would be about habit and consistency. -
Are you sure it does not compile? [Copy and move operations does not produce error](https://godbolt.org/z/8vadqM) Rules for which SMFs get deleted by compiler and which remain defaulted are a bit complex, so that's why it's better to be explicit about it and
= deletethose that you don't want and= defaultthose that you want to keep. The second point is to always prefer= defaultover{}since you retain triviality which is actual concept. Trivial type are easier to handle, subject to more optimizations and can be used in wider range of situations. It something that you probably don't need for arena allocator, so in this case it would be about habit and consistency.Now that you mention it I'm not sure. I guess I should be explicit.
Real programmers use butterflies
-
1&2 - see my edited post 4, i use const descriptively, even if it doesn't do anything, unless there's a reason I shouldn't 5, yeah that's a nasty habit of mine 6 I introduced a static_assert to fix that in my later code.
Real programmers use butterflies
honey the codewitch wrote:
4, i use const descriptively, even if it doesn't do anything, unless there's a reason I shouldn't
To whom this description is directed? Users of the interface don't not care about it. Implementer of the interface is [free to leave it out when override the function](https://godbolt.org/z/as7Mzv), since compiler ignores
constwhen doing overload resolution. It is just implementation thing leaking into syntax of function signature, but not really affecting it. You can keep it class implementing abstract function to prevent changes to the parameter in the function's body, but in the base class it just confusing. -
declaring it on the stack? ouch. I only return char*s from functions if I'm using some kind of memory management scheme that allows for it. Unless you implement one C and C++ ... doesn't. I can't judge people too badly though, considering I just got schooled on using leading underscores in my local member names (a habit I picked up from C#) But still, you should understand scoping if you're going to get paid to code in the thing.
Real programmers use butterflies
Yes, in C#, we (used to) use underscores for local member names. In C++, we used 'm_' for member names. The 'm' told us that it was a class (or struct) member.
-
Yes, in C#, we (used to) use underscores for local member names. In C++, we used 'm_' for member names. The 'm' told us that it was a class (or struct) member.
i should have known. i went back to that style and I absolutely hate it.
Real programmers use butterflies
