5 ms·
> I also would guess that the compiler elides the Badge argument since it is never used. It's also zero width, so no temporaries, etc.
by SolarNet 7y ago
> I also would guess that the compiler elides the Badge argument since it is never used.
It's also zero width, so no temporaries, etc.
- kazinator 7y agoProblem is, nothing elides the presence of these obtrusive badge parameters in the source code. A few bytes of stack is the least of my concerns on some file system device registration function that is called five times when the system boots. If we imagine a software organization "going to town" with this badge approach so that there are badges all over the code base, it's not hard to imagine how it would be a nuisance.
- dkersten 7y agoDepending on how you approach it (eg if you don’t instantiate it as {} but instead something like access::device, which is a type alias for Badge<Device>) then I find being explicit about access rights is quite helpful sometimes. In this case, I probably would avoid it too in favour of private headers, but then, I prefer freestanding namespaces functions over objects when possible anyway (too much functional programming maybe), so I’d partition my API that way instead.