legal use of const?

[Comp1597]

Is the following code legal?

void f(const int ing)
{
ing++;
}

int main()
{
}


I would have thought not, and my compiler agrees. It's an error
because a const is being modified.
However, on another thread someone commented on passing a const
parameter by value instead of using a pointer to const or a reference.

In relation to this practice, the comment was

" the function's implementation is
free to omit the const qualifiers regardless of whether they are
included in this prototype. "


So is it the case that my code would be legal on some compilers and
not others? If my code is always illegal, what does it mean to say
"the function's implementation is free to omit the const
qualifiers" ?

Thanks

 

[James Kanze]

[...]

Well, live and learn. That's very cool. Actually, the
reverse order is cool, since the constness of an object passed
by value is really an implementation detail.

void f(int i); // client code shouldn't need to know whether i is const

void f(int const i) {
...
}

Exactly. In general, the use of the const in the declaration is
frowned upon, because it doesn't mean anything, and because it
has no signification for the client. In the definition, there
are two philosopies here: the first says that the declaration
and the definition should agree, literally, so there should be
no const there either; the second that if you don't want
to modify it, it should be declared const, even if there is a
visual difference between the declaration and the definition.
Most of the places I've seen adhere to the first philosophy, but
I don't know whether its because they've actually evaluated the
two alternatives, or simply because they'd always seen it that
way, and hadn't considered the second. (Arguably, functions
should be short enough that you can quickly see any
modifications anyway, so it shouldn't matter.)

 

[coal]

    [...]

Well, live and learn.  That's very cool.  Actually, the
reverse order is cool, since the constness of an object passed
by value is really an implementation detail.
void f(int i);  // client code shouldn't need to know whether i isconst
void f(intconsti) {
     ...
}

Exactly.  In general, the use of theconst in the declarationis
frowned upon, because it doesn't mean anything, and because it
has no signification for the client.

What if it's a reference to a type?

 In the definition, there
are two philosopies here: the first says that thedeclaration
and the definition should agree, literally, so there should be
noconstthere either; the second that if you don't want
to modify it, it should be declaredconst, even if there is a
visual difference between thedeclarationand the definition.
Most of the places I've seen adhere to the first philosophy, but
I don't know whether its because they've actually evaluated the
two alternatives, or simply because they'd always seen it that
way, and hadn't considered the second.  (Arguably, functions
should be short enough that you can quickly see any
modifications anyway, so it shouldn't matter.)

I'm thinking of including this in the C++ Middleware
Writer. Currently, both declarations and definitions
of send functions use const for parameters whether
they are passed by value or reference.

Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[James Kanze]

Pete Becker wrote:
On 2009-04-09 18:10:01 -0400, (e-mail address removed) said:

[...]

That's referring to this:
void f(constint); // prototype
void f(int i) // implementation; omittingconstis okay
{
// whatever
}
Well, live and learn. That's very cool. Actually, the
reverse order is cool, since the constness of an object passed
by value is really an implementation detail.
void f(int i); // client code shouldn't need to know whether i isconst
void f(intconsti) {
...
}

Exactly. In general, the use of the const in the
declaration is frowned upon, because it doesn't mean
anything, and because it has no signification for the
client.

What if it's a reference to a type?

I presume you mean "a reference type"---references can only be
to objects or to functions, not to types. In that case, the
const is illegal, so the question doesn't occur. (We're
talking of top level const here. Obviously, char const* or
SomeType const& is perfectly acceptable.)

 

[woodbrian77]

I presume you mean "a reference type"---references can only be
to objects or to functions, not to types.  In that case, the
const is illegal, so the question doesn't occur.  (We're
talking of top level const here.  Obviously, char const* or
SomeType const& is perfectly acceptable.)

Say someone wants to marshall a vector<string>. I was
wondering if you're saying a function declaration should be

bool Send(vector<string>&);

or

bool Send(vector<string> const&);

In my opinion the const is helpful to have in the
declaration even if it isn't required. So I'm not
sure what you meant by the words "in general."


Brian Wood
Ebenezer Enterprises
www.webEbenezer.net

 

[Comp1597]

Say someone wants to marshall a vector<string>.  I was
wondering if you're saying a function declaration should be

bool Send(vector<string>&);

or

bool Send(vector<string> const&);

In my opinion the const is helpful to have in the
declaration even if it isn't required.  So I'm not
sure what you meant by the words "in general."

Brian Wood
Ebenezer Enterpriseswww.webEbenezer.net

No, I don't think anyone was talking about this particular example.
In your Send example, the answer is clear: If Send changes the
vector, the declaration is bool Send(vector<string> &); and if Send
doesn't change the vector the declaration is
bool Send(vector<string> const&);
I think everyone agrees that it's better style to use a const function
if the vector doesn't change -- that's called const correctness.

 

[Comp1597]

Say someone wants to marshall a vector<string>.  I was
wondering if you're saying a function declaration should be

bool Send(vector<string>&);

or

bool Send(vector<string> const&);

In my opinion the const is helpful to have in the
declaration even if it isn't required.  So I'm not
sure what you meant by the words "in general."

Brian Wood
Ebenezer Enterpriseswww.webEbenezer.net

Well, the discussion was about const objects, not const references.

James was talking about functions whose parameters are const objects,
and you're talking about a function with a const reference parameter
-- a very different situation. You don't see a declaration like void f
(const int); very often -- that's (part of) James's point.

 

[James Kanze]

Say someone wants to marshall a vector<string>. I was
wondering if you're saying a function declaration should be

bool Send(vector<string>&);

bool Send(vector<string> const&);

In my opinion the const is helpful to have in the
declaration even if it isn't required. So I'm not
sure what you meant by the words "in general."

That's not a top level const. That's not what we're talking
about. Obviously, if Send doesn't modify the vector, the
reference to it should be declared const. But the entire
discussion has been with regards to top level const (which isn't
even legal for references).

 

[James Kanze]

Well, the discussion was about const objects, not const
references.

James was talking about functions whose parameters are const
objects, and you're talking about a function with a const
reference parameter -- a very different situation. You don't
see a declaration like void f (const int); very often --
that's (part of) James's point.

Fundamentally, the issue is one of top level const in a function
parameter. If the parameter has reference type, then it isn't
an object, and the top level const is illegal (since references
are always const)---you can't write something like:

bool
Send( std::vector< std::string > const& const ) ;