Re: [boost] Re: Review: Boost Coding Guidelines

From: James Dennett (jdennett_at_[hidden])
Date: 2001-07-26 17:54:50

John Max Skaller wrote:
> 
> tim_at_[hidden] wrote:
> >
> > --- In boost_at_y..., Daryle Walker <darylew_at_m...> wrote:
> > > I don't think you realize that not
> > > all types support the pre-qualifier form!
> >
> > You are right. I won't try to describe the parsing
> > contortions my mind goes through mapping post-qualifiers
> > on pointers into a pre-qualifier world.
> 
>         I think you're having the same trouble
> the committee did. The rule is that 'const' is always
> associated with the pointer NOT the type: there is
> no such type as 'const int'.

Yes there is.

> There is no 'pointer to a const int' either. 

Yes there is.

> What exists in reality is
> a pointer-const to int:
> 
>         int      const*

There are only pointers.  They may point to cv-qualified
types.

> where I put lots of white space to indicate what's
> connected to what. Don't get confused like the committee
> did with
> 
>         int const x = 1;
> 
> x is NOT a const int type.

No, it's a variable, not a type.  Its type is "const int",
equivalently "int const".

Which pointer do you claim the "const" in "int const x=1;"
is bound to?  It's a const l-value.  Not a pointer in sight.

> Its a ref-const to int:
> 
>         int   const& x = 1;
> 
> See? x has the SAME type in both cases.

Not true.  x is a reference in one case but not in the other.
In particular, "int const &x = 1;" does not define x so that
it is usable as a constant expression.  Constant expressions
have constant integral types.

> Or consider:
> 
>         void f(int);
>         void g(const int);
> 
> See? f and g have the SAME type in both cases.

They do, but only because the "const" is only significant
in definitions (for functions), as per 8.3.5/3.  If the types
int and const int were the same this explicit rule would not
be needed.  Indeed, you claim that const int is the same as
int const &, which is clearly not the same as int.

> Its the ref or pointer which is qualified, NOT the
> object type. If there's no pointer or reference,
> cv-qualifiers are meaningless.

Not true.
 
> So the reason you write the const AFTER the type is
> that you must put the word 'const' next to the thing
> that it _actually_ qualifies, the * or & or implied &.
> Putting it before the type as in:
> 
>         const int *
> 
> is obviously very bad practice because the suggestion
> is just NOT how the type system really works.
> But you're in good company, even Bjarne got this wrong.

I think not.  Why do you believe that many experts who
wrote the Standard were wrong, while you are right?
Given that Bjarne developed the semantics of const
prior to its inclusion in C89, it seems harsh to say
that he's wrong about something that he specified
in the first place.

You've presented no evidence to support your claim that
"const int" is not a type, and the Standard clearly
defines cv-qualified types.

Is this some kind of word-play which requires the
synthesis of ghost pointers where there are none in 
order to appeal to some idea of a clean type system?

-- James Dennett