[boost] Re: Re: Re: Proposed addition: sign_triats and[un]signed_cast

From: Jeffrey C. Jacobs (darklord_at_[hidden])
Date: 2002-09-12 12:16:39

Note that the "const" appears AFTER the "&".  Perhaps what I wrote would be
clearer if it were a pointer:

Integral * const _T1

This is different from

const Integral *_T2

And I know you probably all know how so, but for those that don't, the first
means that "_T1 = new Integral(3)" will NOT compile where as the second says
that "*_T2 = Integral(3)" will NOT compile (it might not run either if you
didn't initialize _T2 with something!).  This concept could and would be
extended to References so in:

Integral & const _T

The const refers to the Reference, not the object, which is hence redundant.

Now I am aware of the reasons why something might be locally constant but
globally volatile e.g. in a multi-threaded application but then didn't I
just say I agree that "const volatile &_T" should be added.  You sold me
already Daniel -- it was a great catch!  I even thanked you in my source
code comments!  What more do you want??  ;)  Anyway, thanks again for the
further explaination though and hope we're both sympatico at this point:
const volatile is should be supported!  :)

Jeffrey.

"Daniel Frey" <daniel.frey_at_[hidden]> wrote in message
news:3D804B20.2C99BA99_at_aixigo.de...
"Jeffrey C. Jacobs" wrote:
>
> Oh!  Good point, thanks Daniel!  Consider it done:
>
> const volatile Integral &_T
>
> Of course, a const volatile (or volatile const) anything is effectively
> saying: this value doesn't change but assume it changes frequently (don't
> cache it), so although as a completist I will support it, from a language
> POV it's sort of like saying:
>
> Integral & const _T

Of course the & is always fixed, the 'const' and 'volatile' refer to the
type you are refering. Using both 'const' and 'volatile' is AFAIK a
useful thing as it says that *your* code will not change it, but another
thread could (or if it's a hardware register etc.). This prevents the
compiler from optimizing certain things away like moving the 'reading'
of the variable out of a loop or removing code paths that otherwise
would never be taken.

Regards, Daniel