Rolf F. Katzenberger wrote:
>> Take for instance the declaration
>>     void setSalary( const int amount );

David R Tribble <david.tribble@noSPAM.central.beasys.com> writes:
>> I put this in the same category as:
>>     int func(Foo &const f);

Steve Clamage wrote:
> Bad analogy.
> Section 8.3.2 says cv-qualifiers on references are ill-formed,
> unless they are introduced via a typedef.
> It's a fairly recent language change.

I didn't know that, thanks.  I think it's a good change.
(I used to have to deal with code from another person who used the
'&const' quite a lot, which irritated me so.)

-- David R. Tribble, dtribble@technologist.com --
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

David R Tribble <david.tribble@noSPAM.central.beasys.com> writes:

>Rolf F. Katzenberger wrote:
>> Take for instance the declaration
>>     void setSalary( const int amount );
>>
>> The const is a hint that the *value* copied to amount should be
>> regarded as a *constant* by the implementor of setSalary(). It is only
>> a semantical hint, since the implementor could write
>>     void setSalary( int amount ) ...
>>
>> anyway and get away with it.
>...
>>
>> Is it really *that* weird?  8-|

>I put this in the same category as:
>    int func(Foo &const f);

>The 'const' is truly a waste of typing; references are, by
>definition, always constant (regardless of whether the object to
>which they refer is const or not).  ...

Bad analogy.

Section 8.3.2 says cv-qualifiers on references are ill-formed,
unless they are introduced via a typedef.

It's a fairly recent language change.

--
Steve Clamage, stephen.clamage@sun.com
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Rolf F. Katzenberger wrote:
> Take for instance the declaration
>     void setSalary( const int amount );
>
> The const is a hint that the *value* copied to amount should be
> regarded as a *constant* by the implementor of setSalary(). It is only
> a semantical hint, since the implementor could write
>     void setSalary( int amount ) ...
>
> anyway and get away with it.
...
>
> Is it really *that* weird?  8-|

I put this in the same category as:
    int func(Foo &const f);

The 'const' is truly a waste of typing; references are, by
definition, always constant (regardless of whether the object to
which they refer is const or not).  By the same token,
pass-by-value arguments are, by definition, always const as far as
the caller is concerned.

But it certainly doesn't hurt if you leave in the 'const' in your
prototype in your header file, just it doesn't hurt to leave the
'const' in the example I gave above.

-- David R. Tribble, dtribble@technologist.com --



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <36647057.540070970@homer>,
  math@vissci.com wrote:
>
> "Vlad Harchev" <vladhar@imimail.ssau.ru> wrote:
> >3) When compiling the function with 'const' qualifier on function
> >parameter passed by value, some compilers can generate more
> >optimized code than for  function without 'const' (eliminating
> >the loads of it).
>
> Name one compiler which does this. For the compiler to be able to
> check whether or not this optimization would be valid, it would need
> to have immediate access to the function definition.

I think that Vlad meant that some compilers can generate more
optimized code *IN* the function, if the parameter is declared
const.
    void foo(const int x) {
        const int y = x / 5 + 2;
        const int z = 5;
        // ...
    }
In this example, x is a const parameter, and y is a const
variable which is initialized by a run-time expression.
These are equivalent in every important aspect except, of
course, for where x gets it's value (from the caller).
z is a const variable whose value is known at compile time.

Now I haven't checked with any real compiler to see if I'm
right, but we all know that the compiler can optimize some
usage of z, right? For instance, if foo() containst the
statement
    a[z]=25;
(where a[] is a global array) then the compiler can
probably resolve the address of a[z] at compile time.

It's equally obvious to me that both x and y can have
certain optimizations, although not nearly so much as z
because their values aren't known at compile time. For
an example of such an optimization, let's assume that
foo() calls bar(). When bar() returns to foo(), the
foo() code can assume that x and y haven't changed.
If x and y have already been loaded into registers
(and if foo() is expected to preserve it's register
values), that optimization can be significant.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Mathew Hendry wrote <36647057.540070970@homer> ...

>"Vlad Harchev" <vladhar@imimail.ssau.ru> wrote:
>>3) When compiling the function with 'const' qualifier on function
>>parameter passed by value, some compilers can generate more
>>optimized code than for  function without 'const' (eliminating
>>the loads of it).
>
>>Name one compiler which does this. For the compiler to be able to
>>check whether or not this optimization would be valid, it would need
>>to have immediate access to the function definition.
>
>-- Mat.


  When compiler compiles function body, it has immediate access to the
function definition :)
  I meant that code can be made more optimized by some compilers in function
body, not the optimization of the invokation of the function (moreover, the
value should be copied anyway I think - no optimization in function
invokation).

 Example:
template <class T> struct smart_reference
{
  T* ptr;
  // ctros go here, etc
  operator T&() const { return *ptr; }
};

template <class Iter,class Value> void fill(Iter first,Iter last,const Value
v)
{
  while (first!=last)  *first++=v;
};

main(int argc,char** argv)
{
  typedef int type;

  type data[10]; type val=argc;
  smart_reference<type> ref(val);
  strange_fill(data,data+10,ref);
};

  I think that adding the 'const' on v can convince compiler not to load the
'*ptr' each iteration (if  type is small object like 'int' here) at least at
some intermediate optimization level. Chances increase if assembler code is
present in function body - compiler can become more pessimistic.


     Vlad
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

rfkat@ibm.net (Rolf F. Katzenberger) wrote:
>AllanW@my-dejanews.com wrote:
>> Rolf, I really want to understand. I can't possibly agree OR disagree
>> unless I understand.
>>
>> You've used the phrase "the const might be a semantical hint" often,
>> but I don't know what the hint IS.
>
>Take for instance the declaration
>
>  void setSalary( const int amount );
>
>The const is a hint that the *value* copied to amount should be
>regarded as a *constant* by the implementor of setSalary().

Why should the designer of the interface care whether it is constant
or not? The implementor is receiving a copy anyway.

The designer is implying that he knows more about implementation than
the man who has been employed to do it, and he's wasting his time
considering irrelevant minutiae of implementation instead of
concentrating on the interface design which *he* has been employed to
do.

Even more importantly, users of the interface will have to wade
through 6 extra characters for every function declaration making use
of this "hint", and sit trying to work out what the hell that "const"
is doing there.

Users of the interface - who will hopefully be looking at it more
often and for longer than either the designer or the implementor -
simply don't need to have this information.

-- Mat.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 13 Nov 1998, Rolf F. Katzenberger wrote:

> I rather expected answers like "Look,
> putting const here is bad style because of..." than those I got.

Look Rolf, putting const here is bad style because:

1.  Experienced programmers will assume that you do not understand
    pass by value.  With that assumption it follows that the
    implementation is likely incorrect and another library written
    by someone who does understand pass by value should be used.

2.  Inexperienced programmers may assume that it means something and
    waste valuable time trying to determine what it means.

3.  If someone posts your code to a moderated group, you will receive
    the mild form of flames which are accepted by the moderators.

Is that better?

John



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 13 Nov 1998, James Kuyper wrote:

> My message was about the const'ness of the object pointed to, not of the
> pointer itself. I was responding to a message which suggested that it
> would be a good idea to declare a function to take 'T * arg', and define
> it as taking 'T const *arg'.

Ah-ha!  There is no doubt that you know what you are talking about.  If
someone had really said that, everyone would be in agreement with you.

But your mind is playing tricks on your eyes.  Here is the quote you
talk about in another article.  I'm sure that you see a const added
at a level other than the outermost, but it isn't there.

> // header file
> void f(char const *);
>
> // cpp file
> #include "header file"
> void f(char const *const thing) { ... }

You were responding to a message which suggested that it
would be a good idea to declare a function to take 'T * arg', and define
it as taking 'T * const arg'.
                ^^^^^^^

With the const in the right place, I think we can all agree and drop
this sidetracked part of the thread.

John



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

John E. Potter wrote:
 >
 > On 13 Nov 1998, James Kuyper wrote:
 >
 > > My message was about the const'ness of the object pointed to, not of the
 > > pointer itself. I was responding to a message which suggested that it
 > > would be a good idea to declare a function to take 'T * arg', and define
 > > it as taking 'T const *arg'.
 >
 > Ah-ha!  There is no doubt that you know what you are talking about.  If
 > someone had really said that, everyone would be in agreement with you.
 >
 > But your mind is playing tricks on your eyes.  Here is the quote you
 > talk about in another article.  I'm sure that you see a const added
 > at a level other than the outermost, but it isn't there.
 >
 > > // header file
 > > void f(char const *);
 > >
 > > // cpp file
 > > #include "header file"
 > > void f(char const *const thing) { ... }
                ^^^^^
 > You were responding to a message which suggested that it
 > would be a good idea to declare a function to take 'T * arg', and define
 > it as taking 'T * const arg'.
 >                 ^^^^^^^

Unless I've mis-counted, there are two const's in that function
definition. Unless I've misunderstood something, they each have
different meanings, and the first of the two makes my objections
relevant.

 > With the const in the right place, I think we can all agree and drop
 > this sidetracked part of the thread.

If I'm wrong about the first 'const', I need an explanation; otherwise
I'll be quite happy to drop it.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Mathew Hendry writes <3657c433.87626925@news.dial.pipex.com> ...
>
>rfkat@ibm.net (Rolf F. Katzenberger) wrote:
>>AllanW@my-dejanews.com wrote:
>>> Rolf, I really want to understand. I can't possibly agree OR disagree
>>> unless I understand.
>>>
>>> You've used the phrase "the const might be a semantical hint" often,
>>> but I don't know what the hint IS.
>>
>>Take for instance the declaration
>>
>>  void setSalary( const int amount );
>>
>>The const is a hint that the *value* copied to amount should be
>>regarded as a *constant* by the implementor of setSalary().
>
>Why should the designer of the interface care whether it is constant
>or not? The implementor is receiving a copy anyway.
>
>The designer is implying that he knows more about implementation than
>the man who has been employed to do it, and he's wasting his time
>considering irrelevant minutiae of implementation instead of
>concentrating on the interface design which *he* has been employed to
>do.
>
>Even more importantly, users of the interface will have to wade
>through 6 extra characters for every function declaration making use
>of this "hint", and sit trying to work out what the hell that "const"
>is doing there.
>
>Users of the interface - who will hopefully be looking at it more
>often and for longer than either the designer or the implementor -
>simply don't need to have this information.
>
>-- Mat.

    I think that
1) declaration and definition of the function 'setSalary' will be in
different files, so library implementor can put the declaration without
'const' to not confuse library users, and the definintion of the function
can have the 'const' - normally users will use (read and explore) defintion
more seldom than they will use (include) declaration in the header.

2)  Using the 'const' qualifier on the parameter passed by value is very
useful (I use it very often) to insure that the paramter won't be changed by
the code of the function. It's also signtificant for flow of control.
Consider example:

struct foo
{
  void f() { cout << "A"; };
  void f() const  { cout << "B"; };
};

void bar1(foo v)          { v.f(); };
void bar2(const foo v) { v.f(); };

  These control flow in the bar1 and bar2 will be different ( bar1 prints 'A' , bar2 prints 'B').

3) When compiling the function with 'const' qualifier on function parameter passed by value, some compilers can generate more optimized code than for  function without 'const' (eliminating the loads of it).




[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

"Vlad Harchev" <vladhar@imimail.ssau.ru> wrote:
>3) When compiling the function with 'const' qualifier on function
>parameter passed by value, some compilers can generate more
>optimized code than for  function without 'const' (eliminating
>the loads of it).

Name one compiler which does this. For the compiler to be able to
check whether or not this optimization would be valid, it would need
to have immediate access to the function definition.

-- Mat.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <364DF7C6.81FE5F0E@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
>  > > // header file
>  > > void f(char const *);
>  > >
>  > > // cpp file
>  > > #include "header file"
>  > > void f(char const *const thing) { ... }

> Unless I've mis-counted, there are two const's in that function
> definition. Unless I've misunderstood something, they each have
> different meanings, and the first of the two makes my objections
> relevant.

You haven't misunderstood anything, but you have mis-counted.
You're right that the cpp file implementation does have two consts,
but the header file already had one (the one on the char).
The discussion was about the ADDED const, and there were only one
of these, and it was a top-level const.

>  > With the const in the right place, I think we can all agree and drop
>  > this sidetracked part of the thread.
>
> If I'm wrong about the first 'const', I need an explanation; otherwise
> I'll be quite happy to drop it.

You're right about the first const. Any serious argument you
heard was made in the mis-directed belief that you were
talking about the second const.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
>
> In article <364DF7C6.81FE5F0E@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
> >  > > // header file
> >  > > void f(char const *);
> >  > >
> >  > > // cpp file
> >  > > #include "header file"
> >  > > void f(char const *const thing) { ... }
>
> > Unless I've mis-counted, there are two const's in that function
> > definition. Unless I've misunderstood something, they each have
> > different meanings, and the first of the two makes my objections
> > relevant.
>
> You haven't misunderstood anything, but you have mis-counted.
> You're right that the cpp file implementation does have two consts,
> but the header file already had one (the one on the char).
> The discussion was about the ADDED const, and there were only one
> of these, and it was a top-level const.
>
> >  > With the const in the right place, I think we can all agree and drop
> >  > this sidetracked part of the thread.
> >
> > If I'm wrong about the first 'const', I need an explanation; otherwise
> > I'll be quite happy to drop it.
>
> You're right about the first const. Any serious argument you
> heard was made in the mis-directed belief that you were
> talking about the second const.

No, it was my error - my worries are irrelevant to the actual example
given, and you've helped me see where I misread it. The 'const' in the
header file declaration is on a different side of the '*' than I thought
it was. I've no idea how I misread it that way. I apologize for wasting
everyone's time.

This is why I fully approve of walkthroughs. Believe it or not, I
usually catch more mistakes than anyone else at our typical walkthrough.
That's even true when we're reviewing my own code :-(.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 16 Nov 1998, James Kuyper wrote:

> John E. Potter wrote:

>  > On 13 Nov 1998, James Kuyper wrote:

>  > But your mind is playing tricks on your eyes.  Here is the quote you
>  > talk about in another article.  I'm sure that you see a const added
>  > at a level other than the outermost, but it isn't there.

>  > > // header file
>  > > void f(char const *);

------------------^^^^^^            It's here too!

>  > >
>  > > // cpp file
>  > > #include "header file"
>  > > void f(char const *const thing) { ... }
>                 ^^^^^

--------------------------^^^^^     This is the one added

>  > You were responding to a message which suggested that it
>  > would be a good idea to declare a function to take 'T * arg', and define
>  > it as taking 'T * const arg'.
>  >                 ^^^^^^^

> Unless I've mis-counted, there are two const's in that function
> definition. Unless I've misunderstood something, they each have
> different meanings, and the first of the two makes my objections
> relevant.
>
>  > With the const in the right place, I think we can all agree and drop
>  > this sidetracked part of the thread.
>
> If I'm wrong about the first 'const', I need an explanation; otherwise
> I'll be quite happy to drop it.

These things are really hard to see once we get our minds set.

Consider:

typedef char const T;

>  > > // header file
>  > > void f(char const *);

becomes

   void f(T*);

>  > > // cpp file
>  > > #include "header file"
>  > > void f(char const *const thing) { ... }

becomes

   void f(T* const thing)

The first const in the cpp was also there in the h.  The second one
which was added does not change the signature and is an implementation
detail.  You still can't change what it points to, but you now also
can't change where it points.  Much like a reference, it may not be
reseated.

John



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:

> [Re-posting: It's been 24 hours since I posted this the first time, and
> I still haven't seen it on my news server. Moderators: please cancel
> this message, if the previous one actually made it through.]

> AllanW@my-dejanews.com wrote:
> >
> > In article <3648A176.41C6@wizard.net>,
> >   James Kuyper <kuyper@wizard.net> wrote:
> > [...]
> > > > >void func1(T *t);
> > [...]
> > > > >void func1(const T *t){
> > > > >       // definition that doesn't change t
> > > > }
> > [...]
> > > That's what I'd expect. However, the claim was made that it's a good
> > > idea to have this kind of mis-match between the header and
> > > implementation file. That implied to me that the resulting code was
> > > expected to compile and link properly. Rather than argue the point, I
> > > simply said that I'd be annoyed if I didn't get at least a warning
> > > message from such code.
> >
> > > If the claim hadn't been extended to include pointers, I would have
> > > considered it fairly reasonable.
> >
> > As far as I know, nobody has extended this claim to include pointers.

> If you follow the thread backwards 7 steps, you'll find a message by
> Siemel Naran saying:
> > Use this to your advantage.  In the header file, when declaring a function,
> > leave off the 'const'.  But in the cpp file, when defining the function,
> > put in the 'const'.  This has the advantage of making your implementation
> > easier to understand, and also keeps you from accidentally changing the
> > variable.  Eg, with pointers
> >
> > // header file
> > void f(char const *);
> >
> > // cpp file
> > #include "header file"
> > void f(char const *const thing) { ... }

> I've included portions of this text in two of the messages along that
> string of seven which were mine, and in the second one I inserted
> '^^^^^^^^' underneath the word "pointers", to emphasize the point.

This is different, since it does _not_ change the constness of the
pointed-to object. It "changes" the constness of the pointer itself.
The right side const just tells the compiler that you don't want
to re-seat the copy of the pointer you received. The pointed-to
value is not affected (*both* have the "const" left of the star).
Again, it's the top-level const and *only* the top-level const
which is discarded. And again, it doesn't change anything in the
interface.

The difference would be different if s.o. proposed to make

void f(char* const);

and

void f(char const* const)

the same. But no one did that. It's only the top-level const, which
affects only the copy of the value. Note that for references, this
top-level const doesn't exist.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:
>
> (snip)
>
> If the claim hadn't been extended to include pointers, I would have
> considered it fairly reasonable.

To quote from my earlier post in this thread:
"there's nothing magical about pointers".
A pointer variable holds an address.
The language allows you to perform
certain operations on that variable by virtue
of the fact it's a pointer - eg dereference it.
But as a variable, it is not different from
any other with regard to constness or pass-by-value.
The address the pointer holds may be const yes but
this is separate from whether the pointer itself
is const.

--
+---------------------------------+
|         Paul Grealish           |
|       GEOPAK-TMS Limited        |
|       Cambridge, England        |
| paul.grealish@uk.geopak-tms.com |
+---------------------------------+


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:

> A buggy compiler could also be compliant; consider a
> (strictly!) hypothetical compiler which implements
> every rule in the standard and passes almost every
> test suite, but incorrectly flags errors when
> variables are given certain valid names such as "far".

Just because the implementor didn't intend that to happen, doesn't make
the implementation compliant.

Most bugs render a compiler non-compliant. The only kinds of bugs that
wouldn't, are bugs that make a different choice than intended from among
the options allowed to an implementation. Even then, if behaviour is
implementation-defined, it must be correctly documented. Only within the
realm of unspecified behaviour is there freedom for a compiler bug to
not endanger the compiler's compliant status.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Grealish wrote:

> James Kuyper wrote:
> >
> > Paul Grealish wrote:
> > >
> > > (snip)
> > >
> > > No, that's not the way it works.  As Andrew Koenig noted
> > > earlier in this thread, "top-level consts are discarded
> > > from function declarations".
> > >
> > > Consider:
> > >
> > >         class A {};
> > >         extern void foo(A);
> > >         A a;
> > >         foo(a);
> > >
> > > The call to foo invokes A's copy constructor
> > > (A::A(const A&)).  Note the 'const' - this applies
> > > to your original object, 'a'.  foo() receives the
> > > unnamed temporary created by the copy constructor.
> >
> > I don't understand how your example is relevant to my concerns.

> Do you understand what pass-by-value means?
> I'm not being facetious.  To understand this
> thread you need to be able to look at function
> definitions and recognise where a temporary
> is going to be constructed and the scope of that
> temporary (as my example illustrated).
> Of course, when passing by reference it is not
> necessary for any temporary to be constructed).
> It's important to remember that there's nothing
> magical about pointers.  When programmers talk
> about passing by pointer [foo(int*)], pass-by-value
> of the pointer variable still occurs.  That's
> what this whole thread is concerned with.

Yes, I understand pass by value. I understand the difference between
'T*const arg' and 'T const *arg', and the former case is type of context
that the bulk of this thread has been about. However, it's not what the
entire thread has been about. I was responding specifically to one
message which was advocating a header file declaration of 'T *arg' for a
function whose implementation file said 'T const *arg'.
As several people have pointed out (in response to my message, rather
than to the original, making me appear responsible) that type of 'const'
mis-match between header file and implementation file results in the
declaration of two different overloaded functions, one of which has no
definition, and the other of which has no declaration in the header
file.

I posted a message late last night (EST) which quoted the original text
I was responding too. It hasn't shown up yet on my news server. I'll
repost it if it hasn't shown up by this evening.


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 10 Nov 1998 23:17:18 GMT, in article
<72ab7f$5no$1@nnrp1.dejanews.com> AllanW@my-dejanews.com wrote:

> In article <3646f04a.0@news2.ibm.net>,
>   rfkat@ibm.net (Rolf F. Katzenberger) wrote:

[snip]

> > That documents a semantical
> > (design) decision which IMHO is on a higher level than a possible need
> > to have a non-const amount available in the body of the function.
>
> Okay, so I've already proven through previous posts that I'm not
> the brightest person in the world. Which is perhaps exactly what
> you need when you make these types of notational policies. (If
> you assume that everyone is as smart as you, then your policies
> can only be understood by poeple that meet that qualification.
> Then when you find an exception, that person can't understand
> your policies...)

Please feel free to disagree. I'm not trying to make any policies, I
just had some questions. A lot of people in this thread seem to
misunderstand this, and I have to say I find it astonishing what kinds
of comments my questions earned me here, in a moderated group.

> Please explain, in terms so simple that even *I* can understand,
> what exactly you would signify by putting const in by-value
> parameters in functions in header files. Assuming that all the
> programmers in your shop read and understand your policy:

Once again: I don't make any policies.

>     1. What would the responsibilities of the caller be?

None.

>     2. What would the responsibilities of the implementation be?

Since my original question was answered by "casting away the const
from the definition signature would result in undefined behavior", I
wouldn't place a const there. So the implementation can be made as
needed by the implementor, either

  void f(const int i) {}

or

  void f(int i) {}

regardless whether there was a const in the declaration or not.


>     3. What assumptions could the caller make, that would make
>         the program easier to write or maintain?

The same as with comments. I never said the const in the header file
(i.e. in the declaration) was anything more than a comment.

>     4. What assumptions could the implementation make, that would
>         make the program easier to write or maintain?

see 2. & 3.

>     (Answer only if the answers to 3. and 4. are both blank):
>     5. What is the point, and why would I ever want to do this?

I don't want to start a debate about comments, but the const might be
a semantical hint, as comments are. The implementation can still be
written as needed, without the need for any cast (which would result
in undefined behavior, anyway).


Regards,
  Rolf


--
______________________________________________________________________
Rolf F. Katzenberger | Software Developer | Trainer         1998-09-21
Home: http://www.geocities.com/SiliconValley/Park/9557
PGP : http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3B39491F
      (Fingerprint F1C0 3116 F6D4 DA33 E61D  D2E4 2FB8 D6B6 3B39 491F)


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

[Re-posting: It's been 24 hours since I posted this the first time, and
I still haven't seen it on my news server. Moderators: please cancel
this message, if the previous one actually made it through.]

AllanW@my-dejanews.com wrote:
>
> In article <3648A176.41C6@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
> [...]
> > > >void func1(T *t);
> [...]
> > > >void func1(const T *t){
> > > >       // definition that doesn't change t
> > > }
> [...]
> > That's what I'd expect. However, the claim was made that it's a good
> > idea to have this kind of mis-match between the header and
> > implementation file. That implied to me that the resulting code was
> > expected to compile and link properly. Rather than argue the point, I
> > simply said that I'd be annoyed if I didn't get at least a warning
> > message from such code.
>
> > If the claim hadn't been extended to include pointers, I would have
> > considered it fairly reasonable.
>
> As far as I know, nobody has extended this claim to include pointers.

If you follow the thread backwards 7 steps, you'll find a message by
Siemel Naran saying:
> Use this to your advantage.  In the header file, when declaring a function,
> leave off the 'const'.  But in the cpp file, when defining the function,
> put in the 'const'.  This has the advantage of making your implementation
> easier to understand, and also keeps you from accidentally changing the
> variable.  Eg, with pointers
>
> // header file
> void f(char const *);
>
> // cpp file
> #include "header file"
> void f(char const *const thing) { ... }

I've included portions of this text in two of the messages along that
string of seven which were mine, and in the second one I inserted
'^^^^^^^^' underneath the word "pointers", to emphasize the point.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Grealish wrote:
>
> James Kuyper wrote:
> >
> > (snip)
> >
> > If the claim hadn't been extended to include pointers, I would have
> > considered it fairly reasonable.
>
> To quote from my earlier post in this thread:
> "there's nothing magical about pointers".
> A pointer variable holds an address.
> The language allows you to perform
> certain operations on that variable by virtue
> of the fact it's a pointer - eg dereference it.
> But as a variable, it is not different from
> any other with regard to constness or pass-by-value.
> The address the pointer holds may be const yes but
> this is separate from whether the pointer itself
> is const.

My message was about the const'ness of the object pointed to, not of the
pointer itself. I was responding to a message which suggested that it
would be a good idea to declare a function to take 'T * arg', and define
it as taking 'T const *arg'.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Rolf F. Katzenberger wrote:
>
> (Gargantua Blargg) wrote:
>
> (snip)
>
> > WTF?!? What the hell does the variable used to pass the argument to
> > setSalary matter with regard to the semantics of the function? NONE! It is
> > just a conduit for the data.
>
>   void setSalary(const int amount);
>
> says: "please regard the value copied into amount as a constant".

It doesn't say that to me, nor (as this this thread
supports) the vast majority of programmers.  To me
it says that the programmer does not understand
pass-by-value.
Why do you think memset() is documnted as
 void *memset(void *dest, int c, size_t count);
rather than:
 void* memset(void *dest, const int c, const size_t count);

???  Is it because (following your logic) the spec says
"please do not regard the values copied into 'c' and
'count' as constants"?


> > > That documents a semantical
> > > (design) decision which IMHO is on a higher level than a possible need
> > > to have a non-const amount available in the body of the function.
> >
> > Huh? This documents nothing. Comments document things.
>
> Exactly. Please note that I am very well able to grasp the meaning of
> "call by value". I'm primarily talking about using that const as a
> comment

There's the problem - code is precise, comments are
less precise.  The const is setSalary above is
completely redundant as far as the compiler is
concerned, agreed?  An inprecise comment such as
"please regard the value copied into amount as a
constant", is not best provided by the code - the
value's either const or it's not - it's as simple
as that.

--
+---------------------------------+
|         Paul Grealish           |
|       GEOPAK-TMS Limited        |
|       Cambridge, England        |
| paul.grealish@uk.geopak-tms.com |
+---------------------------------+
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 13 Nov 98 13:50:37 GMT, in article
<364C2118.1FD2@uk.geopak-tms.com> Paul Grealish
<paul.grealish@uk.geopak-tms.com> wrote:

> Rolf F. Katzenberger wrote:
> >
> > (Gargantua Blargg) wrote:
> >
> > (snip)
> >
> > > WTF?!? What the hell does the variable used to pass the argument to
> > > setSalary matter with regard to the semantics of the function? NONE! It is
> > > just a conduit for the data.
> >
> >   void setSalary(const int amount);
> >
> > says: "please regard the value copied into amount as a constant".
>
> It doesn't say that to me, nor (as this this thread
> supports) the vast majority of programmers.  To me
> it says that the programmer does not understand
> pass-by-value.

Thanks, but in fact I do understand call by value...

> Why do you think memset() is documnted as
>  void *memset(void *dest, int c, size_t count);
> rather than:
>  void* memset(void *dest, const int c, const size_t count);
>
> ???  Is it because (following your logic) the spec says
> "please do not regard the values copied into 'c' and
> 'count' as constants"?

Let me play the devil's advocate and say: a) memset was invented long
before C++ and before const; b) memset is part of the standard library
anyway, therefore the common programmer will not implement it.

[snip]
> code is precise, comments are
> less precise.  The const is setSalary above is
> completely redundant as far as the compiler is
> concerned, agreed?

Yes, of course. It's funny how many participants in this thread were
assuming that I just didn't understand call by value, while IMHO I
simply asked a question pertaining to style.

>  An inprecise comment such as
> "please regard the value copied into amount as a
> constant", is not best provided by the code - the
> value's either const or it's not - it's as simple
> as that.

Considering that standard conforming compilers support both
alternatives (const, no const) and considering that it doesn't make
any difference to the compiler which form one uses, why is such a
simple matter really *upsetting* so many posters? It's not forbidden
to add explicit comments. I rather expected answers like "Look,
putting const here is bad style because of..." than those I got.

Regards,
  Rolf

--
______________________________________________________________________
Rolf F. Katzenberger | Software Developer | Trainer         1998-09-21
Home: http://www.geocities.com/SiliconValley/Park/9557
PGP : http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3B39491F
      (Fingerprint F1C0 3116 F6D4 DA33 E61D  D2E4 2FB8 D6B6 3B39 491F)


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

> On 10 Nov 1998 23:17:18 GMT, in article
> <72ab7f$5no$1@nnrp1.dejanews.com> AllanW@my-dejanews.com wrote:
> >     5. What is the point, and why would I ever want to do this?

In article <364b6d67.0@news2.ibm.net>,
  rfkat@ibm.net (Rolf F. Katzenberger) wrote:
> I don't want to start a debate about comments, but the const might be
> a semantical hint, as comments are. The implementation can still be
> written as needed, without the need for any cast (which would result
> in undefined behavior, anyway).

Rolf, I really want to understand. I can't possibly agree OR disagree
unless I understand.

You've used the phrase "the const might be a semantical hint" often,
but I don't know what the hint IS.

    THE "const" MIGHT BE A SEMANTICAL HINT THAT function setSalary()
    will not change the amount while it runs.

Which means *NOTHING* to the caller, as many people have pointed out
and as you have acknowledged.

    THE "const" MIGHT BE A SEMANTICAL HINT THAT amount will always
    be a prime number.
or
    THE "const" MIGHT BE A SEMANTICAL HINT THAT amount will be
    calculated from data in the database.
or
    THE "const" MIGHT BE A SEMANTICAL HINT THAT amount should be
    1,000 or less.

I'm guessing that none of these is what you meant. But you're going
to have to write a sentance along these lines before I understand
you. Sorry if I'm just being slow, here.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 13 Nov 1998 18:28:14 GMT, in article
<72hr23$g0u$1@nnrp1.dejanews.com> AllanW@my-dejanews.com wrote:


> > On 10 Nov 1998 23:17:18 GMT, in article
> > <72ab7f$5no$1@nnrp1.dejanews.com> AllanW@my-dejanews.com wrote:
> > >     5. What is the point, and why would I ever want to do this?
>
> In article <364b6d67.0@news2.ibm.net>,
>   rfkat@ibm.net (Rolf F. Katzenberger) wrote:
> > I don't want to start a debate about comments, but the const might be
> > a semantical hint, as comments are. The implementation can still be
> > written as needed, without the need for any cast (which would result
> > in undefined behavior, anyway).
>
> Rolf, I really want to understand. I can't possibly agree OR disagree
> unless I understand.
>
> You've used the phrase "the const might be a semantical hint" often,
> but I don't know what the hint IS.

Take for instance the declaration

  void setSalary( const int amount );

The const is a hint that the *value* copied to amount should be
regarded as a *constant* by the implementor of setSalary(). It is only
a semantical hint, since the implementor could write

  void setSalary( int amount )
  {
    //...
  }

anyway and get away with it. But if there is no real need to change
amount, not even for implementation purposes (which I find to be true
in practically every function of that kind), he could write

  void setSalary( const int amount )
  {
    //...
  }

and have the compiler check that the value stored in amount isn't
changed erroneously. One can always modify the implementation file and
remove the const, should that become necessary. In any case, there is
no avalanche effect with respect to compile-time dependencies - it's
only an implementation file.

Is it really *that* weird?  8-|
  Rolf


--
______________________________________________________________________
Rolf F. Katzenberger | Software Developer | Trainer         1998-09-21
Home: http://www.geocities.com/SiliconValley/Park/9557
PGP : http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3B39491F
      (Fingerprint F1C0 3116 F6D4 DA33 E61D  D2E4 2FB8 D6B6 3B39 491F)


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3648A176.41C6@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
[...]
> > >void func1(T *t);
[...]
> > >void func1(const T *t){
> > >       // definition that doesn't change t
> > }
[...]
> That's what I'd expect. However, the claim was made that it's a good
> idea to have this kind of mis-match between the header and
> implementation file. That implied to me that the resulting code was
> expected to compile and link properly. Rather than argue the point, I
> simply said that I'd be annoyed if I didn't get at least a warning
> message from such code.

> If the claim hadn't been extended to include pointers, I would have
> considered it fairly reasonable.

As far as I know, nobody has extended this claim to include pointers.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper <kuyper@wizard.net> writes:

>Paul Grealish wrote:
>>
>> No, that's not the way it works.  As Andrew Koenig noted
>> earlier in this thread, "top-level consts are discarded
>> from function declarations".

>What I'm concerned about is the following:

>func1.h:
>void func1(T *t);

>func1.c:
>void func1(const T *t){
> // definition that doesn't change t
>}

>func2.c:
>#include "func.h"
>woid func2(const T *t)
>{
> func1(t); // My concern.
>}

But the const in that example is not a top-level const. Parameter t
is not const in either of the delcarations of func1.

The func1 declared in func1.h is not the same function as the func1
declared in func2.cc. The func1 called from function func2 is the
one declared in func1.h, not the function defined in func1.cc.

A top-level const example would look like this:

void func1(T* t); // declaration
void func1(T* const t) { ... } // definition

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3643B424.51D53E54@ibm.net>,
  bijuthom@ibm.net wrote:
> Steve Clamage wrote:
> >
> > rfkat@ibm.net (Rolf F. Katzenberger) writes:
> >
> > >What is the reason for making this overloading
> >
> > >  void f(int i);
> > >  void f(const int i);
> >
> > >syntactically illegal?
> >
> > It isn't illegal. The two declarations of f are equivalent,
> > and refer to the same function.
> >
> > If your compiler complains about the two *declarations* at
> > either the point of declaration or the point of some use,
> > it is wrong.
> >
>
> What Steve says is true only for global functions, not for member
> functions. It is not possible to have multiple declarations of member
> functions. Standard  9.2/1 says:
>
> "A member shall not be declared twice in the member-specification,
> except that a nested class or member class template can be declared and
> then later defined."

How does that passage contradict or refute what Steve Clamage said?

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <m3u3094ztq.fsf@gabi-soft.fr>,
  kanze@gabi-soft.fr (J. Kanze) wrote:
>
> stephen.clamage@sun.com (Steve Clamage) writes:
> |>  >  void f(int i);
> |>  >  void f(const int i);
> |>  It isn't illegal. The two declarations of f are equivalent,
> |>  and refer to the same function.
> |>
> |>  If your compiler complains about the two *declarations* at
> |>  either the point of declaration or the point of some use,
> |>  it is wrong.
>
> Or old?  I think that this point was unclear for a long time.

Were these two different functions, in some draft standard?
As opposed to
    void f(int &i);
    void f(const int &i);
or
    struct xxx {
        void f(int i);
        void f(int i) const;
    };
which have been and still are unique functions, right?

> (What's happening, Steve: I thought that you were one of the rare people who
> agreed with me when I say that conforming to an earlier pseudo-standard
> should not be considered a bug.)

Obviously not. If a compiler was free from bugs in 1996, the
release of a language standard in 1998 does not cause it to have
bugs. The compiler simply doesn't comply with the new standard.

I see what you're getting at. Some people use the term
"non-compliant" as if it was equivalent to the phrase
"bug-riddled." But these are two separate issues. A
compiler can be solid as a rock but not compliant.
A buggy compiler could also be compliant; consider a
(strictly!) hypothetical compiler which implements
every rule in the standard and passes almost every
test suite, but incorrectly flags errors when
variables are given certain valid names such as "far".

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 10 Nov 98 16:44:52 GMT, in article
<199811091915.NAA24480@centurion.flash.net> blargg@flash.net
(Gargantua Blargg) wrote:

> > Provided the implementation can cast away the const, you don't have to
> > care for that, either.
>
> What? This is a variable local to the function.

It's scope is that of the function, I agree. But it is also part of
the interface, so semantically (from a design point of view) it is way
more than *just* a local variable.

> Outside users can't even
> tell if it's const or not. Casting is irrelevant here.

There are more options than just casting away the const.

> > >  The compiler knows this and completely ignores the cv
> > > qualification at the point of call.
> > >
> > > > It would be bad, however, if the implementation of
> > > >f() couldn't cast away the const, should that be necessary.
>
> What const? Nothing is being passed in by reference. Modifying a const
> parameter to the function would be equivalent to copying it internally and
> modifying that copy. Again, no references to the outside world.

I did not say at all there was a physical reference to the outside.
There is, however, a logical reference, since it is a parameter, not
only a local variable.

[snip]
> > If the implementation
> > really wants to cast away the const from things that are semantically
> > const, that desire can *only* result from implementation needs. In the
> > above example:
> >
> >   void setSalary(const int amount);
> >
> > it is clear that the designer of setSalary() wanted to express that
> > amount should be regarded as a constant.
>
> WTF?!? What the hell does the variable used to pass the argument to
> setSalary matter with regard to the semantics of the function? NONE! It is
> just a conduit for the data.

  void setSalary(const int amount);

says: "please regard the value copied into amount as a constant". I
don't know what caused you to choose such unpleasant acronyms, to me
that wish does not seems that strange.

> > That documents a semantical
> > (design) decision which IMHO is on a higher level than a possible need
> > to have a non-const amount available in the body of the function.
>
> Huh? This documents nothing. Comments document things.

Exactly. Please note that I am very well able to grasp the meaning of
"call by value". I'm primarily talking about using that const as a
comment, and my original question was whether it is feasible to put
that const into the signatures of both the declarations and the
definition. To do this, you need to be able to cast away that const
for implementation matters, where needed, to avoid a second copy into
a local variable.

Meanwhile that question pertaining to undefined behavior after that
cast has been answered: there is no exception to the rule, casting
away that const leads to undefined behavior.

> Here const means
> nothing, and in the definition of setSalary, means the particular variable
> amount won't be modified in the body. Not that amount has any significance
> after the function returns, or any significance on member variables set
> inside the function.

I agree.

> > So, provided we can safely cast away the const in case we need that,
> > why should we document implementation-specific needs in the *header*
> > file?
>
> We cannot safely cast away const on a const variable:
>
>     void setSalary( int const amount )
>     {
>         const_cast<int&> (amount) = 1234; // undefined behavior
>         // ...
>
> > Or, to twist a solution as suggested by somebody else before:
> > why not write
> >
> >   void setSalary(const int amount);
> >
> > in the header and
> >
> >     void setSalary(int amount)
> >     {
> >     }
> >
> > in the implementation file, instead of the other way around?
>
> Uhhh, because the const in the declaration doesn't mean anything?
>
> Look, if y'all are advocating use of const in a header file as
> documentation of a function's semantics, think again. It means nothing to
> the compiler or implementation of the function. It won't mean anything to
> most users anyway (other than scratching their heads wondering why someone
> would put const there in the declaration). If you want to document the
> contract for the function, use comments instead of this meaningless
> application of const.

Once more: this *is* meaningful. It is a semantical (design) matter
that I'm after, not primarily a compilation matter.


Regards,
  Rolf

--
______________________________________________________________________
Rolf F. Katzenberger | Software Developer | Trainer         1998-09-21
Home: http://www.geocities.com/SiliconValley/Park/9557
PGP : http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3B39491F
      (Fingerprint F1C0 3116 F6D4 DA33 E61D  D2E4 2FB8 D6B6 3B39 491F)
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

There's been something unstated in this thread. Some people seem
to think that it's so basic that there's no need to say it, but
others seem not to know it. Excuse me for stating what may be
very obvious, but:
    void func1(int i) { // Called by value, not by reference
        ++i;    // Modifies i
    }
    int main() {
        int x;
        x = 5;
        func1(x); // Calls func1
        std::cout << x << std::endl;
    }
This program outputs 5, not 6. When main() calls func1(), it
COPIES the value of main's x (5) into func1's variable i.
Then, as func1() executes, it changes the value of this copy
from 5 to 6. But this does not affect variable x in any way.
When func1() returns, main prints out the value of variable
x, which still contains 5.

It would be different if func1's parameter was passed by
reference, but it's not.

For this reason, changing func1() to:
    void func1(const int i) { // Called by value, not by reference
        //++i;   // This would be illegal
        int j=i; // Make a copy
        ++j;     // and modify that
    }
would not change the net effect of the whole program AT ALL.

> Paul Grealish wrote:
> > No, that's not the way it works.  As Andrew Koenig noted
> > earlier in this thread, "top-level consts are discarded
                             ^^^^^^^^^
> > from function declarations".

In article <36478079.167E@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> I don't understand how your example is relevant to my concerns. What I'm
> concerned about is the following:
>
> func1.h:
> void func1(T *t);
>
> func1.c:
> void func1(const T *t){
>  // definition that doesn't change t
> }

This is not the same function as the prototype in func1.h. And,
despite your comment, this version of func1() could change t;
this usage of const is not at the top level. What you've stated
is that *t can't be modified, but t can:
    void func1(const int *t) {
        (*t)++; // Illegal, modifies the const int
        ++t;    // No problem
    }
If you want to make sure that you can't modify t, you need a
top-level "const". This is the one that has no business being
in the header file:
    void func1(int * const t) {
        (*t)++; // Fine
        ++t;    // Illegal, can't modify the const pointer
    }
And of course these can be combined:
    void func1(const int * const t) {
        (*t)++; // Violates the first const
        ++t;    // Violates the second const
    }
The proper header-file prototype for the last version is
    void func1(const int*);
because it says that the pointed-to integer can't be modified.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:
>
> Paul Grealish wrote:
> >
> > (snip)
> >
> > No, that's not the way it works.  As Andrew Koenig noted
> > earlier in this thread, "top-level consts are discarded
> > from function declarations".
> >
> > Consider:
> >
> >         class A {};
> >         extern void foo(A);
> >         A a;
> >         foo(a);
> >
> > The call to foo invokes A's copy constructor
> > (A::A(const A&)).  Note the 'const' - this applies
> > to your original object, 'a'.  foo() receives the
> > unnamed temporary created by the copy constructor.
>
> I don't understand how your example is relevant to my concerns.

Do you understand what pass-by-value means?
I'm not being facetious.  To understand this
thread you need to be able to look at function
definitions and recognise where a temporary
is going to be constructed and the scope of that
temporary (as my example illustrated).
Of course, when passing by reference it is not
necessary for any temporary to be constructed).
It's important to remember that there's nothing
magical about pointers.  When programmers talk
about passing by pointer [foo(int*)], pass-by-value
of the pointer variable still occurs.  That's
what this whole thread is concerned with.

--
+---------------------------------+
|         Paul Grealish           |
|       GEOPAK-TMS Limited        |
|       Cambridge, England        |
| paul.grealish@uk.geopak-tms.com |
+---------------------------------+
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

AllanW@my-dejanews.com wrote:
....
> In article <36478079.167E@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
> > I don't understand how your example is relevant to my concerns. What I'm
> > concerned about is the following:
> >
> > func1.h:
> > void func1(T *t);
> >
> > func1.c:
> > void func1(const T *t){
> >       // definition that doesn't change t
> > }
>
> This is not the same function as the prototype in func1.h. And,
> despite your comment, this version of func1() could change t;

I've already dealt with both of these issues on another branch of this
same thread.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3646f04a.0@news2.ibm.net>, Rolf F. Katzenberger
<rfkat@ibm.net> writes
>So, provided we can safely cast away the const in case we need that,
>why should we document implementation-specific needs in the *header*
>file? Or, to twist a solution as suggested by somebody else before:
>why not write
>
>  void setSalary(const int amount);

Fine, if thats what you want, it just doesn't do anything that cannot be
as well (or even better) done with a comment.

>
>in the header and
>
>    void setSalary(int amount)
>    {
>    }
>
>in the implementation file, instead of the other way around?
>

Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote:
>
> On 07 Nov 98 04:18:10 GMT, Rolf F. Katzenberger <rfkat@ibm.net> wrote:
>
> >Why not indicate in the header, too, that I don't intend to change the
> >parameter? It should be possible, provided that casting away the const
> >in the body of f() doesn't result in undefined behavior. I'd like to
> >put the const into the header file, too - however this could be
> >disadvantageous if the implementation of f() can't cast away the
> >const.
>
> Here's one suggestion: in the header file don't use const, but in the
> implementation file do what you want.  Use const if the value indeed
> does not change; leave out the const if the value does change.
> There's no need for a const_cast here.
>
> >Essentially, I'm thinking of things like
> >
> >  void setSalary(const int amount);
<snip>
>
> So it's really a matter of coding style.
What your saying is the function will not modify the copy of the
argument.  Really this is information that the user of the function does
not need to know, only the implimenter.

I suggest use plain T for simple types and const T& or const T* for
extended types in the header.  Give the user's of your function only the
information they need to call your function.  Hide all implimentation
data from the users.

For the implimentation I'd add the const for pointers only (const T*
const) since the function should not be looking anywhere else (unless
the argument is a pointer to an array.)  Adding the const precludes
using the int as a count down variable.
--
Bill Roeder
My opinions are my own and do not reflect those of my employer.
Why do people put the above line in their signature?
If they reflected my employer then he would have sent the message!
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Grealish wrote:
>
> James Kuyper wrote:
> > >
> > > (snip)
> > >
> > > In the header file, when declaring a function,
> > > leave off the 'const'.  But in the cpp file, when defining the function,
> > > put in the 'const'.  This has the advantage of making your implementation
> > > easier to understand, and also keeps you from accidentally changing the
> > > variable.  Eg, with pointers
                          ^^^^^^^^
> >
> > That would mean that anyone who wants to call your function for a const
> > object would have to cast away the const. I don't like that idea.
>
> No, that's not the way it works.  As Andrew Koenig noted
> earlier in this thread, "top-level consts are discarded
> from function declarations".
>
> Consider:
>
>         class A {};
>         extern void foo(A);
>         A a;
>         foo(a);
>
> The call to foo invokes A's copy constructor
> (A::A(const A&)).  Note the 'const' - this applies
> to your original object, 'a'.  foo() receives the
> unnamed temporary created by the copy constructor.

I don't understand how your example is relevant to my concerns. What I'm
concerned about is the following:

func1.h:
void func1(T *t);

func1.c:
void func1(const T *t){
 // definition that doesn't change t
}

func2.c:
#include "func.h"
woid func2(const T *t)
{
 func1(t); // My concern.
}


Even if we ignore all issues of standards compliance, I'd be very
annoyed at an implementation that doesn't complain about the marked
line. To stop the complaint, I need a const_cast<T*>(t). I don't like
that, because by writing code like that I'm accepting responsibility for
knowing that func1() does not in fact change it's argument. Since I
might not even have access to the source code for func1(), I don't like
accepting that responsibility.

I wouldn't need to do so, if func1.h had contained a declaration which
corresponded to the actual functioning of func1().
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Rolf F. Katzenberger wrote:
>
> So, provided we can safely cast away the const in case we need that,
> why should we document implementation-specific needs in the *header*
> file? Or, to twist a solution as suggested by somebody else before:
> why not write
>
>   void setSalary(const int amount);
>
> in the header and
>
>     void setSalary(int amount)
>     {
>     }
>
> in the implementation file, instead of the other way around?
>

Because, the constness of 'amount' is an implementation issue. The
caller of the method sees that he passes the amount by *value*, and,
hence, the callee cannot modify the caller's 'amount' in any way. So, we
don't need the const specification in the header.

OTOH, the implementation may decide not to modify the parameter 'amount'
inside the function. If you declare the parameter to be 'const', the
compiler will prevent you from modifying the value of 'amount'
accidentally inside the function. For example,

void setSalary ( int amount )
{
  amount = -1; // Okay do this, probably by mistake.
}

void setSalary ( const int amount )
{
  amount = -1; // Error.
}

The second style is preferable, as it will help you to prevent mistakes.

Note that this is similar to declaring local variables as 'const'.

Regards,
Biju Thomas
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3646f04a.0@news2.ibm.net>, rfkat@ibm.net (Rolf F.
Katzenberger) wrote:

> On 7 Nov 1998 20:49:08 GMT, in article
> <lh6MkZAp6CR2EwPx@robinton.demon.co.uk> Francis Glassborow
> <francis@robinton.demon.co.uk> wrote:
>
> > In article <3642e0bf.0@news2.ibm.net>, Rolf F. Katzenberger
> > <rfkat@ibm.net> writes
> [snip]
> > >Essentially, I'm thinking of things like
> > >
> > >  void setSalary(const int amount);
> > >
> > >and the like. To me it seems perfectly o.k. to place const into the
> > >header file, too, as a semantic hint (IMHO setters rarely ever change
> > >their parameters).
> >
> > Semantic hint to who?  If you are passing by value you KNOW the original
> > cannot be changed and should not care what the function does with the
> > copy.

This I agree with. It's a freaking local variable. It doesn't mean anything.

> Provided the implementation can cast away the const, you don't have to
> care for that, either.

What? This is a variable local to the function. Outside users can't even
tell if it's const or not. Casting is irrelevant here.

> >  The compiler knows this and completely ignores the cv
> > qualification at the point of call.
> >
> > > It would be bad, however, if the implementation of
> > >f() couldn't cast away the const, should that be necessary.

What const? Nothing is being passed in by reference. Modifying a const
parameter to the function would be equivalent to copying it internally and
modifying that copy. Again, no references to the outside world.

> > Whether or not f() can cast away the const is absolutely irrelevant
> > outside the scope of f().  It can have no effect anywhere else. The
> > reason that a sane programmer qualifies the parameter at the point of
> > definition is to ask the compiler to check that you do not change the
> > value in the body of the function because you know that would be a
> > semantic error in your implementation. If it isn't do not add the const
> > qualification to the parameter in the first place.

Yes yes. This is all it means. Agreed.

> Of course this is a valid reason for (not) placing the const into the
> function *definition*.
>
> But seen from the other side: why should we care for such
> implementation issues in the *header* file?

We shouldn't, which is why const shouldn't be added to the header file
(unless we're using an old/buggy compiler that requires the func def to
match the decl with regard to this const issue).

> If the implementation
> really wants to cast away the const from things that are semantically
> const, that desire can *only* result from implementation needs. In the
> above example:
>
>   void setSalary(const int amount);
>
> it is clear that the designer of setSalary() wanted to express that
> amount should be regarded as a constant.

WTF?!? What the hell does the variable used to pass the argument to
setSalary matter with regard to the semantics of the function? NONE! It is
just a conduit for the data.

> That documents a semantical
> (design) decision which IMHO is on a higher level than a possible need
> to have a non-const amount available in the body of the function.

Huh? This documents nothing. Comments document things. Here const means
nothing, and in the definition of setSalary, means the particular variable
amount won't be modified in the body. Not that amount has any significance
after the function returns, or any significance on member variables set
inside the function.

> So, provided we can safely cast away the const in case we need that,
> why should we document implementation-specific needs in the *header*
> file?

We cannot safely cast away const on a const variable:

    void setSalary( int const amount )
    {
        const_cast<int&> (amount) = 1234; // undefined behavior
        // ...

> Or, to twist a solution as suggested by somebody else before:
> why not write
>
>   void setSalary(const int amount);
>
> in the header and
>
>     void setSalary(int amount)
>     {
>     }
>
> in the implementation file, instead of the other way around?

Uhhh, because the const in the declaration doesn't mean anything?

Look, if y'all are advocating use of const in a header file as
documentation of a function's semantics, think again. It means nothing to
the compiler or implementation of the function. It won't mean anything to
most users anyway (other than scratching their heads wondering why someone
would put const there in the declaration). If you want to document the
contract for the function, use comments instead of this meaningless
application of const.

--
blarggflash.net | Gargantua Blargg | http://www.flash.net/~blargg/
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Paul Grealish wrote:
>
> James Kuyper wrote:
> > >
> > > (snip)
> > >
> > > In the header file, when declaring a function,
> > > leave off the 'const'.  But in the cpp file, when defining the function,
> > > put in the 'const'.  This has the advantage of making your implementation
> > > easier to understand, and also keeps you from accidentally changing the
> > > variable.  Eg, with pointers
> >
> > That would mean that anyone who wants to call your function for a const
> > object would have to cast away the const. I don't like that idea.
>
> No, that's not the way it works.  As Andrew Koenig noted
> earlier in this thread, "top-level consts are discarded
> from function declarations".
>
> Consider:
>
>         class A {};
>         extern void foo(A);
>         A a;
>         foo(a);
>
> The call to foo invokes A's copy constructor
> (A::A(const A&)).  Note the 'const' - this applies
> to your original object, 'a'.  foo() receives the
> unnamed temporary created by the copy constructor.

Also note that top-level const in parameter types does *not* ensure
that your object is not changed.

Example:

void f(auto_ptr<int> const x) {}

int main()
{
  auto_ptr<int> p(new int(5));
  f(p); // does change p, despite of "const".
}
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Rolf F. Katzenberger wrote:

[...]

> here by the standard and what the consequences are. For instance, is
> the following resulting in undefined behavior:
>
>   void f( const int i )
>   {
>     const_cast<int&>( i ) = 5;
>   }
>
> Or does this have defined behavior, since void f(int i) and void
> f(const int i) are considered to have equivalent signatures?

Inside the function, the const is respected (otherwise you'd not
need the const_cast). Therefore i is a const object, and changing
it is undefined behaviour.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 10 Nov 98 16:16:59 GMT, James Kuyper <kuyper@wizard.net> wrote:

>func1.h:
>void func1(T *t);

OK.


>func1.c:
>void func1(const T *t){
> // definition that doesn't change t
}

Comment is not correct.  Indeed, "t" can be changed!  The stuff that
"t" points to cannot be changed.  Overloading by constancy of the
pointed to object is valid and should be respected in any conforming
compiler.  So the above function "func1" is a completely different
function.  We often overload the variable "this" in this manner.

struct X
{
     void f(int);
     void f(int) const;
};

The two funcs are sort of equivalent to

void f(X       *, int);
void f(X const *, int);

An idea for implementors is to issue warning messages for this sort of
thing.  When compiling func1.c, the compiler sees that func1(T const *)
is not in an unnamed namespace, so it is not a helper function.  This
means that it had better be a function that is declared in func1.h.
Since it is not declared there, the compiler concludes that the person
made a mistake and so issues a warning (or error).



>func2.c:
>#include "func.h"

You mean to include "func1.h"

>woid func2(const T *t)
>{
> func1(t); // My concern.
>}

This one calls f(T const *), no ambiguity.
This function only exists in func1.c, which is not in this translation unit.
So you should get a compile time error.

>Even if we ignore all issues of standards compliance, I'd be very
>annoyed at an implementation that doesn't complain about the marked
>line. To stop the complaint, I need a const_cast<T*>(t). I don't like
>that, because by writing code like that I'm accepting responsibility for
>knowing that func1() does not in fact change it's argument. Since I
>might not even have access to the source code for func1(), I don't like
>accepting that responsibility.

The use of const_cast here is distasteful, as you've pointed out.
However, even if you use const_cast, your program still doesn't work.
It compiles fines.
It fails to link.  This is because the function func1(T *) has not been
defined.  Only func1(T const *) was defined.

--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote:

> On 10 Nov 98 16:16:59 GMT, James Kuyper <kuyper@wizard.net> wrote:

> >func1.h:
> >void func1(T *t);

> OK.

> >func1.c:
> >void func1(const T *t){
> >       // definition that doesn't change t
> }

> Comment is not correct.  Indeed, "t" can be changed!  The stuff that

You're correct, the comment should have said '*t', not 't'.

> "t" points to cannot be changed.  Overloading by constancy of the
> pointed to object is valid and should be respected in any conforming
> compiler.  So the above function "func1" is a completely different
> function.  We often overload the variable "this" in this manner.
> struct X
> {
>      void f(int);
>      void f(int) const;
> };

> The two funcs are sort of equivalent to

> void f(X       *, int);
> void f(X const *, int);

> An idea for implementors is to issue warning messages for this sort of
> thing.  When compiling func1.c, the compiler sees that func1(T const *)
> is not in an unnamed namespace, so it is not a helper function.  This
> means that it had better be a function that is declared in func1.h.
> Since it is not declared there, the compiler concludes that the person
> made a mistake and so issues a warning (or error).

> >func2.c:
> >#include "func.h"

> You mean to include "func1.h"

Correct.

> >woid func2(const T *t)
> >{
> >       func1(t);       // My concern.
> >}

> This one calls f(T const *), no ambiguity.
> This function only exists in func1.c, which is not in this translation unit.
> So you should get a compile time error.

That's what I'd expect. However, the claim was made that it's a good
idea to have this kind of mis-match between the header and
implementation file. That implied to me that the resulting code was
expected to compile and link properly. Rather than argue the point, I
simply said that I'd be annoyed if I didn't get at least a warning
message from such code.

If the claim hadn't been extended to include pointers, I would have
considered it fairly reasonable.



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3646f04a.0@news2.ibm.net>,
  rfkat@ibm.net (Rolf F. Katzenberger) wrote:
>
> On 7 Nov 1998 20:49:08 GMT, in article
> <lh6MkZAp6CR2EwPx@robinton.demon.co.uk> Francis Glassborow
> <francis@robinton.demon.co.uk> wrote:
>
> > In article <3642e0bf.0@news2.ibm.net>, Rolf F. Katzenberger
> > <rfkat@ibm.net> writes
> [snip]
> > >Essentially, I'm thinking of things like
> > >
> > >  void setSalary(const int amount);
> > >
> > >and the like. To me it seems perfectly o.k. to place const into the
> > >header file, too, as a semantic hint (IMHO setters rarely ever change
> > >their parameters).
> >
> > Semantic hint to who?  If you are passing by value you KNOW the original
> > cannot be changed and should not care what the function does with the
> > copy.
>
> Provided the implementation can cast away the const, you don't have to
> care for that, either.

Many shops have adopted the rule that we should never use any
type of cast if it can be avoided by re-design. For instance,
in one 250,000-line project, I have used about 20 casts. (I
think. Grepping for them is easy with new-style casts, but
some of them are old C-style casts.)

Anyway, with decent design, casting away const-ness should be
pretty rare.

> >  The compiler knows this and completely ignores the cv
> > qualification at the point of call.
> >
> > > It would be bad, however, if the implementation of
> > >f() couldn't cast away the const, should that be necessary.

Besides asking why it couldn't cast away const, I would ask why
it would be neccesary. THE PARAMETER WAS PASSED BY VALUE!
Conceptually it's the same as:
    void setSalary(const int &_amount) {
        int amount(_amount);
        // ... do whatever you want to amount ...
    }
except that the "original" value _amount isn't really accessible.
But
    void setSalary(const int a) {
        int amount = a;
is conceptually the same as
    void setSalary(const int &_amount) {
        const int a(_amount);
        int amount(a);
        // ... do whatever you want to amount ...
    }
There's an extra copy of _amount that you *CAN* access, but it
serves no purpose except to de-optimize your program...

> > Whether or not f() can cast away the const is absolutely irrelevant
> > outside the scope of f().  It can have no effect anywhere else. The
> > reason that a sane programmer qualifies the parameter at the point of
> > definition is to ask the compiler to check that you do not change the
> > value in the body of the function because you know that would be a
> > semantic error in your implementation. If it isn't do not add the const
> > qualification to the parameter in the first place.
>
> Of course this is a valid reason for (not) placing the const into the
> function *definition*.

The only place where it might meaningfully be used is in the
definition.
    void setSalary(const int amount) {
        amount = salary; // Oops! Got the assignment backwards
    }
This (admittedly contrived) example generates an error; if the
const keyword were not used, there would be no clue to any
error until debugging showed that setSalary() had no net
effect.

Please understand that this argument is hypothetical; I do not
personally use this style, nor do I know anybody that does.

> But seen from the other side: why should we care for such
> implementation issues in the *header* file?

Because it looks like a programmer error. If the programmer
intended for the keyword "const" to guarantee *ANYTHING AT ALL*,
she was mistaken.

> If the implementation
> really wants to cast away the const from things that are semantically
> const, that desire can *only* result from implementation needs. In the
> above example:
>
>   void setSalary(const int amount);
>
> it is clear that the designer of setSalary() wanted to express that
> amount should be regarded as a constant.

You said this in another post as well, but I still don't
understand it.

Do you mean that the salary would remain constant? This
contradicts my intuition about what setSalary does -- which
is to change the salary.

Do you mean that the variable passed in to setSalary() should
be a constant? That would make
    setSalary(getSalary()+raiseAmount);
illegal. Even if this is what you want, you won't get it --
at least, the compiler won't enforce it.

Do you mean that the parameter "amount" will not change
during the run of setSalary()? This is an implementation
issue, and therefore has no business being in the header
file.

What's clear to me is that the programmer who wrote the
header file doesn't understand what "const" does in this
setting. In other words, I regard it as a (probably
benign) error.

> That documents a semantical
> (design) decision which IMHO is on a higher level than a possible need
> to have a non-const amount available in the body of the function.

Okay, so I've already proven through previous posts that I'm not
the brightest person in the world. Which is perhaps exactly what
you need when you make these types of notational policies. (If
you assume that everyone is as smart as you, then your policies
can only be understood by poeple that meet that qualification.
Then when you find an exception, that person can't understand
your policies...)

Please explain, in terms so simple that even *I* can understand,
what exactly you would signify by putting const in by-value
parameters in functions in header files. Assuming that all the
programmers in your shop read and understand your policy:
    1. What would the responsibilities of the caller be?
    2. What would the responsibilities of the implementation be?
    3. What assumptions could the caller make, that would make
        the program easier to write or maintain?
    4. What assumptions could the implementation make, that would
        make the program easier to write or maintain?
    (Answer only if the answers to 3. and 4. are both blank):
    5. What is the point, and why would I ever want to do this?

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3646DD85.34D@uk.geopak-tms.com>,
  paul.grealish@uk.geopak-tms.com wrote:
>
> James Kuyper wrote:
> > > In the header file, when declaring a function,
> > > leave off the 'const'.  But in the cpp file, when defining the function,
> > > put in the 'const'.  This has the advantage of making your implementation
> > > easier to understand, and also keeps you from accidentally changing the
> > > variable.  Eg, with pointers
> >
> > That would mean that anyone who wants to call your function for a const
> > object would have to cast away the const. I don't like that idea.
>
> No, that's not the way it works.  As Andrew Koenig noted
> earlier in this thread, "top-level consts are discarded
> from function declarations".

Which is to say, const is ignored when passing by value.

> Consider:
>
>  class A {};
>  extern void foo(A);

        void bar() {
            // >  A a;
            const A a;
>      foo(a);
        }
>
> The call to foo invokes A's copy constructor
> (A::A(const A&)).  Note the 'const' - this applies
> to your original object, 'a'.  foo() receives the
> unnamed temporary created by the copy constructor.

I assume that you meant to include the changes that I
just made: declare a as const, and include the declaration
and the call to foo in a function.

In that case, I completely agree.

--
AllanW@my-dejanews.com is a "Spam Magnet" -- never read.
Please reply in USENET only, sorry.

-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/       Search, Read, Discuss, or Start Your Own


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <3642e0bf.0@news2.ibm.net>, Rolf F. Katzenberger
<rfkat@ibm.net> writes
>Why not indicate in the header, too, that I don't intend to change the
>parameter? It should be possible, provided that casting away the const
>in the body of f() doesn't result in undefined behavior. I'd like to
>put the const into the header file, too - however this could be
>disadvantageous if the implementation of f() can't cast away the
>const.
>
>Essentially, I'm thinking of things like
>
>  void setSalary(const int amount);
>
>and the like. To me it seems perfectly o.k. to place const into the
>header file, too, as a semantic hint (IMHO setters rarely ever change
>their parameters).

Semantic hint to who?  If you are passing by value you KNOW the original
cannot be changed and should not care what the function does with the
copy.  The compiler knows this and completely ignores the cv
qualification at the point of call.

> It would be bad, however, if the implementation of
>f() couldn't cast away the const, should that be necessary.

Whether or not f() can cast away the const is absolutely irrelevant
outside the scope of f().  It can have no effect anywhere else.  The
reason that a sane programmer qualifies the parameter at the point of
definition is to ask the compiler to check that you do not change the
value in the body of the function because you know that would be a
semantic error in your implementation.  If it isn't do not add the const
qualification to the parameter in the first place.


Francis Glassborow      Chair of Association of C & C++ Users
64 Southfield Rd
Oxford OX4 1PA          +44(0)1865 246490
All opinions are mine and do not represent those of any organisation


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Steve Clamage wrote:
>
> rfkat@ibm.net (Rolf F. Katzenberger) writes:
>
> >What is the reason for making this overloading
>
> >  void f(int i);
> >  void f(const int i);
>
> >syntactically illegal?
>
> It isn't illegal. The two declarations of f are equivalent,
> and refer to the same function.
>
> If your compiler complains about the two *declarations* at
> either the point of declaration or the point of some use,
> it is wrong.
>

What Steve says is true only for global functions, not for member
functions. It is not possible to have multiple declarations of member
functions. Standard  9.2/1 says:

"A member shall not be declared twice in the member-specification,
except that a nested class or member class template can be declared and
then later defined."

Regards,
Biju Thomas
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 07 Nov 98 04:18:10 GMT, Rolf F. Katzenberger <rfkat@ibm.net> wrote:

>Why not indicate in the header, too, that I don't intend to change the
>parameter? It should be possible, provided that casting away the const
>in the body of f() doesn't result in undefined behavior. I'd like to
>put the const into the header file, too - however this could be
>disadvantageous if the implementation of f() can't cast away the
>const.

Here's one suggestion: in the header file don't use const, but in the
implementation file do what you want.  Use const if the value indeed
does not change; leave out the const if the value does change.
There's no need for a const_cast here.


>Essentially, I'm thinking of things like
>
>  void setSalary(const int amount);
>
>and the like. To me it seems perfectly o.k. to place const into the
>header file, too, as a semantic hint (IMHO setters rarely ever change
>their parameters). It would be bad, however, if the implementation of
>f() couldn't cast away the const, should that be necessary.

Yes, using 'const' in the header file serves as a kind of comment.  For
example, in the above, the 'const' could mean that the salary will be
set exactly to 'amount', and won't be rounded in any way.  An function
I wrote some time ago was like this:

void Interact::action(const Iflags iflags);

The intent of the unnecessary 'const' here is that Interact::action
does not change the 'iflags'.  If we want to change the 'iflags',
we'll have to call Interact::action again with new a new value for
'iflags'.


But be aware that the 'const' does not have to mean this.  Eg,

void Object::setSalaray(const int amount) {
     the_salary=round_to_nearest_10(amount);
}

void Interact::action(const Iflags i) {
     Iflags iflags=i; // non-const
     ...
}


So it's really a matter of coding style.


--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

stephen.clamage@sun.com (Steve Clamage) writes:

|>  rfkat@ibm.net (Rolf F. Katzenberger) writes:
|>
|>  >What is the reason for making this overloading
|>
|>  >  void f(int i);
|>  >  void f(const int i);
|>
|>  >syntactically illegal?
|>
|>  It isn't illegal. The two declarations of f are equivalent,
|>  and refer to the same function.
|>
|>  If your compiler complains about the two *declarations* at
|>  either the point of declaration or the point of some use,
|>  it is wrong.

Or old?  I think that this point was unclear for a long time.  (What's
happening, Steve: I thought that you were one of the rare people who
agreed with me when I say that conforming to an earlier pseudo-standard
should not be considered a bug.)

--
James Kanze    +33 (0)1 39 23 84 71    mailto: kanze@gabi-soft.fr
GABI Software, 22 rue Jacques-Lemercier, 78000 Versailles, France
Conseils en informatique orient   e objet --
              -- Beratung in objektorientierter Datenverarbeitung


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

James Kuyper wrote:
> >
> > (snip)
> >
> > In the header file, when declaring a function,
> > leave off the 'const'.  But in the cpp file, when defining the function,
> > put in the 'const'.  This has the advantage of making your implementation
> > easier to understand, and also keeps you from accidentally changing the
> > variable.  Eg, with pointers
>
> That would mean that anyone who wants to call your function for a const
> object would have to cast away the const. I don't like that idea.

No, that's not the way it works.  As Andrew Koenig noted
earlier in this thread, "top-level consts are discarded
from function declarations".

Consider:

 class A {};
 extern void foo(A);
 A a;
 foo(a);

The call to foo invokes A's copy constructor
(A::A(const A&)).  Note the 'const' - this applies
to your original object, 'a'.  foo() receives the
unnamed temporary created by the copy constructor.

--
+---------------------------------+
|         Paul Grealish           |
|       GEOPAK-TMS Limited        |
|       Cambridge, England        |
| paul.grealish@uk.geopak-tms.com |
+---------------------------------+


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 7 Nov 1998 20:49:08 GMT, in article
<lh6MkZAp6CR2EwPx@robinton.demon.co.uk> Francis Glassborow
<francis@robinton.demon.co.uk> wrote:

> In article <3642e0bf.0@news2.ibm.net>, Rolf F. Katzenberger
> <rfkat@ibm.net> writes
[snip]
> >Essentially, I'm thinking of things like
> >
> >  void setSalary(const int amount);
> >
> >and the like. To me it seems perfectly o.k. to place const into the
> >header file, too, as a semantic hint (IMHO setters rarely ever change
> >their parameters).
>
> Semantic hint to who?  If you are passing by value you KNOW the original
> cannot be changed and should not care what the function does with the
> copy.

Provided the implementation can cast away the const, you don't have to
care for that, either.

>  The compiler knows this and completely ignores the cv
> qualification at the point of call.
>
> > It would be bad, however, if the implementation of
> >f() couldn't cast away the const, should that be necessary.
>
> Whether or not f() can cast away the const is absolutely irrelevant
> outside the scope of f().  It can have no effect anywhere else. The
> reason that a sane programmer qualifies the parameter at the point of
> definition is to ask the compiler to check that you do not change the
> value in the body of the function because you know that would be a
> semantic error in your implementation. If it isn't do not add the const
> qualification to the parameter in the first place.

Of course this is a valid reason for (not) placing the const into the
function *definition*.

But seen from the other side: why should we care for such
implementation issues in the *header* file? If the implementation
really wants to cast away the const from things that are semantically
const, that desire can *only* result from implementation needs. In the
above example:

  void setSalary(const int amount);

it is clear that the designer of setSalary() wanted to express that
amount should be regarded as a constant. That documents a semantical
(design) decision which IMHO is on a higher level than a possible need
to have a non-const amount available in the body of the function.

So, provided we can safely cast away the const in case we need that,
why should we document implementation-specific needs in the *header*
file? Or, to twist a solution as suggested by somebody else before:
why not write

  void setSalary(const int amount);

in the header and

    void setSalary(int amount)
    {
    }

in the implementation file, instead of the other way around?


Regards,
  Rolf

--
______________________________________________________________________
Rolf F. Katzenberger | Software Developer | Trainer         1998-09-21
Home: http://www.geocities.com/SiliconValley/Park/9557
PGP : http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3B39491F
      (Fingerprint F1C0 3116 F6D4 DA33 E61D  D2E4 2FB8 D6B6 3B39 491F)


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

kanze@gabi-soft.fr (J. Kanze) writes:

>stephen.clamage@sun.com (Steve Clamage) writes:

>|>  >  void f(int i);
>|>  >  void f(const int i);
>|>
>|>  .... The two declarations of f are equivalent,
>|>  and refer to the same function.
>|>
>|>  If your compiler complains about the two *declarations* at
>|>  either the point of declaration or the point of some use,
>|>  it is wrong.

>Or old?  I think that this point was unclear for a long time.  (What's
>happening, Steve: I thought that you were one of the rare people who
>agreed with me when I say that conforming to an earlier pseudo-standard
>should not be considered a bug.)

Good point. I do agree that chastising an old compiler for not
conforming to a new rule doesn't make sense.

I had forgotten that the two functions above were once considered
different functions, and that the implied overloading was
disallowed. The ARM on page 308 covers this case and says the
pair of declarations is not allowed.

A compiler that doesn't claim standards conformance, or one operating
in a pre-standard compatibility mode, could reject the code.

--
Steve Clamage, stephen.clamage@sun.com


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <363cf405.0@news2.ibm.net>,
Rolf F. Katzenberger <rfkat@ibm.net> wrote:

> What is the reason for making this overloading

>   void f(int i);
>   void f(const int i);

> syntactically illegal?

It's not.  Top-level consts are discarded from function declarations,
so the meaning is precisely the same as

 void f(int i);
 void f(int i);

This declares the same function twice, but the declarations are
not definitions, so it's OK.

The rationale for this behavior is that it's what C does.
--
    Andrew Koenig
    ark@research.att.com
    http://www.research.att.com/info/ark



[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

On 06 Nov 98 06:28:35 GMT, in article
<slrn6v453f.plj.sbnaran@localhost.localdomain>
sbnaran@localhost.localdomain (Siemel Naran) wrote:

> On 2 Nov 1998 17:49:25 GMT, Rolf F. Katzenberger <rfkat@ibm.net> wrote:
>
> >What is the reason for making this overloading
> >
> >  void f(int i);
> >  void f(const int i);
> >
> >syntactically illegal?
>
> The reason the two f's can't be considered different function is that
> the arguments are too similar.  What should be called in any of
> these?
>
> f(3); // which one to call?
> int i=8; f(i); // compiler makes copy of 'i' but then which one does it call?
> const int i=9; f(i); // same reason

Ok, I see. Now my question boils down to a matter of style vs.
possibly undefined behavior.

> Use this to your advantage.  In the header file, when declaring a function,
> leave off the 'const'.  But in the cpp file, when defining the function,
> put in the 'const'.  This has the advantage of making your implementation
> easier to understand, and also keeps you from accidentally changing the
> variable.  Eg, with pointers
>
> // header file
> void f(char const *);
>
> // cpp file
> #include "header file"
> void f(char const *const thing) { ... }

Why not indicate in the header, too, that I don't intend to change the
parameter? It should be possible, provided that casting away the const
in the body of f() doesn't result in undefined behavior. I'd like to
put the const into the header file, too - however this could be
disadvantageous if the implementation of f() can't cast away the
const.

Essentially, I'm thinking of things like

  void setSalary(const int amount);

and the like. To me it seems perfectly o.k. to place const into the
header file, too, as a semantic hint (IMHO setters rarely ever change
their parameters). It would be bad, however, if the implementation of
f() couldn't cast away the const, should that be necessary.

Thank you for your hint,
 Rolf

--
______________________________________________________________________
Rolf F. Katzenberger | Software Developer | Trainer         1998-09-21
Home: http://www.geocities.com/SiliconValley/Park/9557
PGP : http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3B39491F
      (Fingerprint F1C0 3116 F6D4 DA33 E61D  D2E4 2FB8 D6B6 3B39 491F)
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Siemel Naran wrote:
>
> On 2 Nov 1998 17:49:25 GMT, Rolf F. Katzenberger <rfkat@ibm.net> wrote:
>
> >What is the reason for making this overloading
> >
> >  void f(int i);
> >  void f(const int i);
> >
> >syntactically illegal?
>
> The reason the two f's can't be considered different function is that
> the arguments are too similar.  What should be called in any of
> these?
>
> f(3); // which one to call?
> int i=8; f(i); // compiler makes copy of 'i' but then which one does it call?
> const int i=9; f(i); // same reason
>
> Use this to your advantage.  In the header file, when declaring a function,
> leave off the 'const'.  But in the cpp file, when defining the function,
> put in the 'const'.  This has the advantage of making your implementation
> easier to understand, and also keeps you from accidentally changing the
> variable.  Eg, with pointers

That would mean that anyone who wants to call your function for a const
object would have to cast away the const. I don't like that idea.
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

What is the reason for making this overloading

  void f(int i);
  void f(const int i);

syntactically illegal?

Of course, for the caller the "const" doesn't matter, since it is a
call by value anyway. But IMHO this is *semantical* reasoning, and I'd
like to understand why overloading was made *syntactically* illegal
here by the standard and what the consequences are. For instance, is
the following resulting in undefined behavior:

  void f( const int i )
  {
    const_cast<int&>( i ) = 5;
  }

Or does this have defined behavior, since void f(int i) and void
f(const int i) are considered to have equivalent signatures?


Regards,
 Rolf

--
______________________________________________________________________
Rolf F. Katzenberger | Software Developer | Trainer         1998-09-21
Home: http://www.geocities.com/SiliconValley/Park/9557
PGP : http://wwwkeys.pgp.net:11371/pks/lookup?op=get&search=0x3B39491F
      (Fingerprint F1C0 3116 F6D4 DA33 E61D  D2E4 2FB8 D6B6 3B39 491F)


[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

rfkat@ibm.net (Rolf F. Katzenberger) writes:

>What is the reason for making this overloading

>  void f(int i);
>  void f(const int i);

>syntactically illegal?

It isn't illegal. The two declarations of f are equivalent,
and refer to the same function.

If your compiler complains about the two *declarations* at
either the point of declaration or the point of some use,
it is wrong.

If you attempt to provide two *definitions* (bodies) for f,
that would not be allowed, because there is only one function.

On 2 Nov 1998 17:49:25 GMT, Rolf F. Katzenberger <rfkat@ibm.net> wrote:

>What is the reason for making this overloading
>
>  void f(int i);
>  void f(const int i);
>
>syntactically illegal?

The reason the two f's can't be considered different function is that
the arguments are too similar.  What should be called in any of
these?

f(3); // which one to call?
int i=8; f(i); // compiler makes copy of 'i' but then which one does it call?
const int i=9; f(i); // same reason


Use this to your advantage.  In the header file, when declaring a function,
leave off the 'const'.  But in the cpp file, when defining the function,
put in the 'const'.  This has the advantage of making your implementation
easier to understand, and also keeps you from accidentally changing the
variable.  Eg, with pointers

// header file
void f(char const *);

// cpp file
#include "header file"
void f(char const *const thing) { ... }



--
----------------------------------
Siemel B. Naran (sbnaran@uiuc.edu)
----------------------------------
---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]