register <var>

[mcleano]

I've been working through my c++ book and its just introducd the register storage class specifier. It said that:

Technically, register is only a request to the compiler, which the compiler is free to ignore. The reason for this is easy to understand: there are a finite number of registers and these may differ from environment to environment.
...

Does that also work for the reverse then? If you create a program and you do not register any variables, will the compiler automatically register a compiler-chosen variable to optimize your code?

Edit** Don't worry about it, it said further on in the book that compilers do

[jsmith]

Yes, and tear out the pages from the book that discuss the register keyword and use them as kindling.

[Duthomhas]

Why?

[mcleano]

@Duoas ... is that at me or jsmith?

[Return 0]

If register is still in use I would like to know what scenarios it may be useful in? I have yet to run into a situation where it was of value.

[Duthomhas]

It was for jsmith.

When doing low-level programming, it is sometimes desirable to cater to the side-effects, as it were, and explicitly indicate which variables should be made register values so that the compiler doesn't optimize against what is actually happening. (C is just easier to use than assembly.)

But again, that is just what I know... I haven't had much use for them either.

[jsmith]

It was my understanding that nowadays compilers completely ignore the keyword anyway.

[kempofighter]

My experience is that by default, modern processors have large numbers of CPU registers and that by default the compiler will use registers for as many local variables as possible. It isn't really necessary to use the register keyword. In fact, the compiler I use chooses CPU registers for local variables of integral type in nearly all cases, regardless of whether you enable any optimization. The compiler may, however, provide you with an option to do the opposite and force it to use stack memory. I know mine does, which is useful for debugging because stack memory variables truly retain their values until the end of the block, whereas register variables don't. I have issues with our compiler because when it chooses register variables, there are some goofy debugger issues where you can't test the value of a register variable after the last point in a block where it was used. For some reason register variables lose their scope faster than variables placed on the stack. It must be that when the compiler sees that a variable is no longer used it frees the register for other uses before the end of a code block but it does not pop variables from the stack using the same logic. The point is that, using the register keyword is really pointless. If you really want to have any control over whether the compiler uses CPU registers or not, you have to read the manual and figure out what settings your compiler will allow you to tweak and you have to understand the issues that you'll have to face in each environment.

[Duthomhas]

Yes, yes, of course. All this is dependent on compiler options.

However, the language provides the register storage class specifier so that it can be used without requiring nonstandard extensions just to choose.

Also, it is not a bad idea to assume a limited number of registers available. Giving the compiler a hint never hurts.


As for debugging, some processors provide special instructions and registers to do debugging, but most don't. Hence, by the time the debugger gets to things, the (shared) register has probably already been smashed, whereas the (process-specific) stack and other memory has not.

But I would like to reiterate what kempofighter said: know your compiler and operating environment.