Do you usually to pass a reference to set (or other stl container) asconst

[puzzlecracker]

void func(const set<string&);

It is typical for pointers, but not reference to pass as const if you
don't want modified. Who finds himself doing it above -- passing the
reference as const?

[Salt_Peter]

On Aug 20, 4:53 pm, puzzlecracker <[e-mail]:

void func(const set<string&);

It is typical for pointers, but not reference to pass as const if you
don't want modified. Who finds himself doing it above -- passing the
reference as const?

Its not typical.
Passing a reference to const should be the default.
The reason you often see references to mutables is due to bad habits
gained from pointers.

// bad
void func(const set<string>* p); // ptr is reseatable
// better
void func(const set<string>* const p); // const ptr to const set
// perfect
void func(const set<string>& r); // not reseatable, set is const

[Triple-DES]

On 20 Aug, 23:14, Salt_Peter <[e-mail]:

>
Its not typical.
Passing a reference to const should be the default.
The reason you often see references to mutables is due to bad habits
gained from pointers.

// bad
void func(const set<string>* p); // ptr is reseatable
// better
void func(const set<string>* const p); // const ptr to const set
// perfect
void func(const set<string>& r); // not reseatable, set is const

I must admit that I do not understand why your example of "bad" is so
bad. Isn't that just like saying:

void f(int i) // bad, the local copy of i can be modified
void f(const int i) // good

Which is simply false.

DP

[puzzlecracker]

On Aug 21, 1:34*am, Triple-DES <[e-mail]:

On 20 Aug, 23:14, Salt_Peter <[e-mail]:

Its not typical.
Passing a reference to const should be the default.
The reason you often see references to mutables is due to bad habits
gained from pointers.

// bad
void func(const set<string>* p); // ptr is reseatable
// better
void func(const set<string>* const p); // const ptr to const set
// perfect
void func(const set<string>& r); // not reseatable, set is const

I must admit that I do not understand why your example of "bad" is so
bad. Isn't that just like saying:

void f(int i) // bad, the local copy of i can be modified
void f(const int i) // good

Which is simply false.

DP

I think void f(const int i) is plainly stupid....
Do you know the difference between

function(const T *p)
function (T const *p )
function (T * const p)
function (const T* const p)

and harder ones:

function(const T **p)
function(T **const p)

[Triple-DES]

On 21 Aug, 14:45, puzzlecracker <[e-mail]:

On Aug 21, 1:34*am, Triple-DES <[e-mail]:

On 20 Aug, 23:14, Salt_Peter <[e-mail]:

Its not typical.
Passing a reference to const should be the default.
The reason you often see references to mutables is due to bad habits
gained from pointers.

// bad
void func(const set<string>* p); // ptr is reseatable
// better
void func(const set<string>* const p); // const ptr to const set
// perfect
void func(const set<string>& r); // not reseatable, set is const

I must admit that I do not understand why your example of "bad" is so
bad. Isn't that just like saying:

void f(int i) // bad, the local copy of i can be modified
void f(const int i) // good

Which is simply false.

DP

I think void f(const int i) *is plainly stupid....

Do you know the difference between

function(const T *p)
function (T const *p )
function (T * const p)
function (const T* const p)

and harder ones:

function(const T **p)
function(T **const p)

Yes, that's why I was interested to hear Salt_Peter's argumentation
why

f(T const * const p);

is "better" than:

f(T const * p)

DP

[Juha Nieminen]

puzzlecracker wrote:

I think void f(const int i) is plainly stupid....

Why? It documents that the parameter is not modified in the program,
and additionally makes the compiler tell you if you break the promise
nevertheless. If it was not your intention to modify the parameter (even
though it's just a local copy), the compiler error can hint you at your
mistake.

[Jorgen Grahn]

On Thu, 21 Aug 2008 15:37:46 GMT, Juha Nieminen <no****@thanks.invalidwrote:

puzzlecracker wrote:

>I think void f(const int i) is plainly stupid....

Why? It documents that the parameter is not modified in the program,

Yes, but callers couldn't care less -- which is why C++ allows this:

void f(int i); // interface

void f(const int i) // implementation, locks down 'i'
{ ... }

and additionally makes the compiler tell you if you break the promise
nevertheless. If it was not your intention to modify the parameter (even
though it's just a local copy), the compiler error can hint you at your
mistake.

Yes, I use that a lot, if the function is messy enough.
It can be useful to know that 'i' still has the same value
two pages down in the code ...

/Jorgen

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se R'lyeh wgah'nagl fhtagn!

[Bo Persson]

Jorgen Grahn wrote:

On Thu, 21 Aug 2008 15:37:46 GMT, Juha Nieminen
<no****@thanks.invalidwrote:

>puzzlecracker wrote:

>>I think void f(const int i) is plainly stupid....

Why? It documents that the parameter is not modified in the
program,

Yes, but callers couldn't care less -- which is why C++ allows this:

void f(int i); // interface

void f(const int i) // implementation, locks down 'i'
{ ... }

>and additionally makes the compiler tell you if you break the
promise nevertheless. If it was not your intention to modify the
parameter (even though it's just a local copy), the compiler error
can hint you at your mistake.

Yes, I use that a lot, if the function is messy enough.
It can be useful to know that 'i' still has the same value
two pages down in the code ...

Yes, I use that as well occationally, even though it is a confession
that the code is not really good enough.

The real solution is, of course, not to have two pages of code in the
function. :-)
Bo Persson

[Jorgen Grahn]

On Thu, 21 Aug 2008 21:21:10 +0200, Bo Persson <bo*@gmb.dkwrote:

Jorgen Grahn wrote:

>void f(int i); // interface

void f(const int i) // implementation, locks down 'i'
{ ... }

>>and additionally makes the compiler tell you if you break the
promise nevertheless. If it was not your intention to modify the
parameter (even though it's just a local copy), the compiler error
can hint you at your mistake.

Yes, I use that a lot, if the function is messy enough.
It can be useful to know that 'i' still has the same value
two pages down in the code ...

Yes, I use that as well occationally, even though it is a confession
that the code is not really good enough.

The real solution is, of course, not to have two pages of code in the
function. :-)

:-) It's actually something I use when cleaning up other people's[0]
messy functions: place "const" on anything which I suspect doesn't or
shouldn't change, and recompile. If it compiles, it becomes easier to
reason about the correctness of the code.

C++ is nice for cleanup work in general -- nicer than any other
language I use. There are so many things you can lock down by
applying 'const', by making things (e.g. copy constructors) private,
by wrapping enums and integers in classes). Runtime bugs pop up as
compiler warnings or errors.

/Jorgen

[0] Can't use it on my own messy code, because I apply const if I
suspect it will become messy.

--
// Jorgen Grahn <grahn@ Ph'nglui mglw'nafh Cthulhu
\X/ snipabacken.se R'lyeh wgah'nagl fhtagn!