Level of indirection how to#

This last example, perhaps, explains the 'why' of it all.Īs we work with something we master it and learn how to abstract it to a higher level of abstraction, thus a new level of indirection is needed and we can solve bigger problems faster by offloading some of the work to the new API. Again a level of indirection is added on top of the low level API and we call it the new, improved API. It is not uncommon for one API to deal with something on a high level and that API deals with the same thing on a lower level.

Level of indirection driver#

The driver is the next something using the something else which is the hardware. Then the screen driver talks directly to the screen hardware causing it to make tiny dots of light here and there. Here are two layers, at least of indirection.

Using an operating system to access the display screen.

Here the web site is the something and hiding behind it is the data which is the something else.

Using a web site to graphically display the data generated by an XML based service.

Typically this is something larger in scope: The pointer is the something and the value is the something else. So your example, using a pointer of a value instead of the value, fits this definition at one level. e.g.'Indirection' is using something that uses something else, in its broadest sense. Indeed, that's the motivating case for adding the syntax in the first place. You're also required to use trailing return types if the type is a decltype that is dependent on the name of one of the function's arguments. It's the only way to specify return types for lambdas. So why would you prefer this style? Well, first there's that consistency argument. The issue is about where to specify return types on function signatures.įor most of C++'s history the only choice has been to write the type before the name of the function (along with any modifiers).īut since C++11 we've been able to write the type at the end of the function signature (after a -> - and the function must be prefixed with the keyword auto). Personally I've been an East Const advocate for many years (although not by that name, of course) -Īnd converted the entire Catch codebase over to East Constīut there's another style choice that I've not seen discussed quite as much, but has a number of parallels.Īs with East vs West Const this is purely a matter of style (it doesn't change what the compiler generates),Īnd one of the arguments in favour is consistency across application (there are some cases where you must do it this way) -īut the main argument against is also consistency - with most existing code.

Level of indirection code#

There are cases for and against, but both sides seem to revolve around the idea of 'consistency'.įor the East Const believers the consistency is in the sense that you can always apply one, simple, rule about what const means and where it goes.įor the West Consters the consistency is with the majority of existing code out there -Īs well as the Core Guidelines recommendation! (which, I think, is what has stirred up the interest).Īs purely a matter of style it's fascinating that it seems to have split the community so strongly! The practice has even been gifted a catchy name: East Const There has been a recent stirring of attention, in the C++ community, for the practice of always placing the const modifier to the right of the thing it modifies.