ahp6@email.byu.edu ("Adam H. Peterson") wrote (abridged):
> But you don't know what functions do that.  When you call a function,
> you assume it does its job.

Exactly. So there's no problem. If it has a good reason to access a
non-const alias, it does so. That's its concern.


> By const safety analogy, it ought to be illegal for a const static
> function to call any namespace function without some sort of cast.

Not at all. The namespace function does its job, and if that means using a
non-const alias to an object which another function has as const, that's
fine. There's no hole in the type system.


> In any viable const safety system, I believe that const qualifiers
> should be hard to discard, and in this case const qualifiers are
> discarded almost as readily as arrays decay into pointers.

In this case const qualifiers are never discarded. Aliases become
available. The presence of aliases makes the const qualifier less
significant, but it's still useful in avoiding mistakes and conveying
intention.


> > As I said before, I think it would need to be part of a fully worked
> > out metaclass scheme, which I doubt will ever happen.
>
> The question I have about a metaclass scheme is: what problem does it
> solve?  IOW, what can such a scheme do that, say, the singleton pattern
> can't do about as effectively?

It should make metaclass idioms easier to express - including virtual
static functions. It should remove some special cases and anomalies from
the language. Of course you can always achieve a similar result by
implementing your own metaclass system by hand.

-- Dave Harris, Nottingham, UK

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

ahp6@email.byu.edu ("Adam H. Peterson") wrote (abridged):
> > That is analogous to a const non-static member function calling a
> > non-const one through an alias.
>
> Which you can only do if you have a viable alias to the instance (or
> create one through a const_cast).  The nonconst interface to a class is
> always available, and it would just be jumping through hoops to force
> the user to go through a namespace function.

That's like saying const_cast is always available. We are not trying to
prevent malicous users here. The awkwardness of the jumping through hoops
is a good thing, because it helps discourage accidents.


> Analogously, const safety on instances of a class can't be compromised
> just by calling another function.  Why is the function boundary more
> significant to class const safety than instance const safety?

It's not the function boundary which is significant. It's the availability
of aliases.


> More to the point, it's going to be all too easy to access the nonconst
> interface of a class inadvertently, which comes back to providing at
> most illusory const safety.

It's not that easy. They have to explicitly acquire an alias to the class,
or invoke a function which does that.

For extra safety we might even say that an alias acquired in a const
static member is also const.

    struct S {
        int x;
        void test1() const {
            int &r1 = x; // Error; x is const.
            int &r2 = S::x; // Error; x is const even with ::.
        }

        static int y;
        static void test2() const { // New feature.
             int &r1 = y; // Error; y is const.
             int &r2 = S::y; // Error?
        }
    };

As I said before, I think it would need to be part of a fully worked out
metaclass scheme, which I doubt will ever happen.

-- Dave Harris, Nottingham, UK

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

Dave Harris wrote:
> ahp6@email.byu.edu ("Adam H. Peterson") wrote (abridged):
>
>>>That is analogous to a const non-static member function calling a
>>>non-const one through an alias.
>>
>>Which you can only do if you have a viable alias to the instance (or
>>create one through a const_cast).  The nonconst interface to a class is
>>always available, and it would just be jumping through hoops to force
>>the user to go through a namespace function.
>
>
> That's like saying const_cast is always available.

It's nothing like saying that.  Const_cast's only use is to discard
const qualifiers.  It's obvious you're circumventing the const system
when you use it.  I almost never use it, and I can tell just by looking
at the code when someone else is.

Function calls, on the other hand....


> We are not trying to
> prevent malicous users here.

But this won't prevent benign users from discarding const qualifiers
either.  Under the proposed scheme, you can discard (or acquire) const
qualifiers just by refactoring functions.  This doesn't happen with
instance const safety, and points to a big hole IMO.


> The awkwardness of the jumping through hoops
> is a good thing, because it helps discourage accidents.

Sometimes that is true and sometimes it is not.  My concern is not that
you have to jump through the hoop; it's how easy it is to jump through
and how likely you are to jump through this particular hoop for
completely unrelated reasons.


>
>
>
>>Analogously, const safety on instances of a class can't be compromised
>>just by calling another function.  Why is the function boundary more
>>significant to class const safety than instance const safety?
>
>
> It's not the function boundary which is significant. It's the availability
> of aliases.

In this case, it's the function boundary that makes the alias available,
and I think that's a big hole in the safety of the system.


>
>
>
>>More to the point, it's going to be all too easy to access the nonconst
>>interface of a class inadvertently, which comes back to providing at
>>most illusory const safety.
>
>
> It's not that easy. They have to explicitly acquire an alias to the class,
> or invoke a function which does that.

But you don't know what functions do that.  When you call a function,
you assume it does its job.  In the case of instance member functions,
you assume it preserves const safety of the instances it takes as const.
  But namespace functions don't take classes as const.  They always have
the nonconst interface to the class available (except for the special
case of const static members of _this_ class, and even these might call
outside the class, opening the same worm can).  By const safety analogy,
it ought to be illegal for a const static function to call any namespace
function without some sort of cast.


>
> For extra safety we might even say that an alias acquired in a const
> static member is also const.

If this proposal were to be adopted, I wouldn't call this "extra
safety."  I would call it a natural implication of the proposal.

But where the whole thing breaks down in my view is where static
functions call namespace functions, or static members of other classes,
or nonstatic member functions of other classes (or nonstatic members of
its own class for that matter).  Any of these will discard the const
qualifier on the class.

In any viable const safety system, I believe that const qualifiers
should be hard to discard, and in this case const qualifiers are
discarded almost as readily as arrays decay into pointers.


> As I said before, I think it would need to be part of a fully worked out
> metaclass scheme, which I doubt will ever happen.

The question I have about a metaclass scheme is: what problem does it
solve?  IOW, what can such a scheme do that, say, the singleton pattern
can't do about as effectively?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

[to mods: resent - previous post didn't get acked, or posted]

""qWake"" <mail@qWake.com> wrote in message
news:10aas4ftgf37124@corp.supernews.com...
> There is only a small gain but I was wondering if there would be serious
> problems in implementing this new type of const-ness.

I think one problem with this proposal is the interaction with const member
functions and static data.

Example:

class SomeClass
{
public:
  static int value;

  void aMethod() const
  {
    ++value; //currently valid syntax
  }

  static void proposedMethod() const // not currently legal
  {
    ++value; // should this work?
  }
};

I would be unhappy with the inconsistency produced if write access to static
data members were handled differently in the two cases.
However, changing the first case to outlaw modifying static member data in
const member functions would break so much code it is unlikely to be
contemplated.

Roger Orr
--
MVP in C++ at www.brainbench.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://www.jamesd.demon.co.uk/csc/faq.html                       ]

The C++ language standard stipulates at section 9.4.1 that "[...] A static
member function shall not be declared const [...]"

The question is: what problem(s) could possibly exist in allowing static
member functions to be 'const' with the implication that they could not
modify static data members?


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

qWake wrote:
> The C++ language standard stipulates at section 9.4.1 that "[...] A static
> member function shall not be declared const [...]"
>
> The question is: what problem(s) could possibly exist in allowing static
> member functions to be 'const' with the implication that they could not
> modify static data members?

Confusion is the problem, I think.  Const and non-const versions of
non-static members can be overloaded and the overload resolution is made
based on the type of the object for which the member is used.  Would you
allow overloading static const and non-const members?  If yes, how would
you decide which one to call?  If not, why?  Non-static members can be
overloaded based on their const-ness...

My guess is that the line had to be drawn somewhere, and there is no way
to satisfy everybody.

BTW, what problem would you solve by declaring a static member 'const'?

Victor

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

qWake wrote:
> The C++ language standard stipulates at section 9.4.1 that "[...] A static
> member function shall not be declared const [...]"
>
> The question is: what problem(s) could possibly exist in allowing static
> member functions to be 'const' with the implication that they could not
> modify static data members?

It seems a bit inconsistent since nonstatic const member functions can
modify static data members.  Do you propose to add a syntax that defines
a member function as "really-const" so it can't modify const members,
static or otherwise?

And it's not really necessary for const safety.  All you have to do is
not modify any static members in the function.  Const member functions
are necessary to specify a const interface to an instance, but there's
only ever one interface available to a class (which also brings up
overloading issues).

So what is the real gain?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

mail@qWake.com ("qWake") writes:

> The C++ language standard stipulates at section 9.4.1 that "[...] A static
> member function shall not be declared const [...]"
>
> The question is: what problem(s) could possibly exist in allowing static
> member functions to be 'const' with the implication that they could not
> modify static data members?

Probably the idea was simply missed. Applying 'const' to a member
    function was concieved to declare member functions that did not
    modify the object used to call the function. Since a static
    member function needs no such object, and indeed, can't refer to
    one if it is used, 'const' has no applicability to it, right? :-)

My first question about your suggested extension is: How often does
    the implementor of a static member function accidently modify a
    static data member that should not have been modified?

I don't know the answer, but the benefit of such an extension
    seems to hinge on that answer.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

mail@qWake.com ("qWake") wrote in message news:<10a78ifp04nk236@corp.supernews.com>...
> The C++ language standard stipulates at section 9.4.1 that "[...] A static
> member function shall not be declared const [...]"
>
> The question is: what problem(s) could possibly exist in allowing static
> member functions to be 'const' with the implication that they could not
> modify static data members?
>

At least one problem would be that a const non-static member function
can be invoked only through a const object.  Since a static member can
be invoked without any object that particular meaning of const would
not make any sense.

Other than that, however, it does, at least initially, sound
reasonable that a const static member function would be unable to
modify any class static data members.  But, this might be more
difficult for compiler vendors to implement.  For a non-static member
function the this pointer is a pointer to const, which makes it easy
for the compiler to detect attempted misuse, but for a static member
function, which has no this pointer, it might be more difficult to
enforce the constness?

Randy.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

> It seems a bit inconsistent since nonstatic const member functions can
> modify static data members.  Do you propose to add a syntax that defines
> a member function as "really-const" so it can't modify const members,
> static or otherwise?

Of course, here I meant "can't modify members."

 > ...
> So what is the real gain?

Another point is that such const safety isn't much safety at all.  A
const static member function would be able to call another nonconst
static member function.  And if you disallow that, it could simply call
a namespace level function that calls a nonconst static function.  So
beyond the language complexities and implementation difficulties, it
doesn't really provide any const safety at all, or possibly illusory
safety which would be worse.

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

There is only a small gain but I was wondering if there would be serious
problems in implementing this new type of const-ness.  The gain is the
ability to define an interface for a safe static function without concern
for the underlying implementation.  Example:

struct C {
    static unsigned getClassState() const; // Currently illegal...
    ...other things...
private:
    static unsigned stateFlags;
    ...other things...
};

This would ensure that no implementation of getClassState will accidentally
(or purposely) change these state flags.  So this is simply an additional
protection against mistakes.

Regarding inheritance, transfer of const-ness and similar considerations,
this type of const is unrelated to any 'this' pointer so it may not be an
issue.  Const objects, non-const objects and even non-member functions could
still access static members of either const or non-const types: non-const
static functions the same way they are presently, and const static function
with the certainty that static data members will not be altered.  A static
const function might behave like a function that accesses all static data
members as if they were const parameters.


---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

ahp6@email.byu.edu ("Adam H. Peterson") wrote (abridged):
> > It seems a bit inconsistent since nonstatic const member functions
> > can modify static data members.

If we think of static members as being members of a static instance of a
metaclass, then it is not inconsistent. An instance of a metaclass is a
different object to an instance of the class, so the constness of one
shouldn't affect the constness of the other.


> > Do you propose to add a syntax that defines a member function
> > as "really-const" so it can't modify const members, static or
> > otherwise?

There's no need.


> Another point is that such const safety isn't much safety at all.  A
> const static member function would be able to call another nonconst
> static member function.

I would disallow that, and provide overloading on const. Probably a
"this", too, as a syntactic convenience, although it needn't take memory.


> And if you disallow that, it could simply call a namespace level
> function that calls a nonconst static function.

That is analogous to a const non-static member function calling a
non-const one through an alias.

It seems to me the idea is consistent and logical, but really needs to
form part of a complete metaclass systems, along with virtual static
functions.

-- Dave Harris, Nottingham, UK

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]

>>Another point is that such const safety isn't much safety at all.  A
>>const static member function would be able to call another nonconst
>>static member function.
>
>
> I would disallow that, and provide overloading on const. Probably a
> "this", too, as a syntactic convenience, although it needn't take memory.
>
>
>
>>And if you disallow that, it could simply call a namespace level
>>function that calls a nonconst static function.
>
>
> That is analogous to a const non-static member function calling a
> non-const one through an alias.


Which you can only do if you have a viable alias to the instance (or
create one through a const_cast).  The nonconst interface to a class is
always available, and it would just be jumping through hoops to force
the user to go through a namespace function.  Analogously, const safety
on instances of a class can't be compromised just by calling another
function.  Why is the function boundary more significant to class const
safety than instance const safety?

More to the point, it's going to be all too easy to access the nonconst
interface of a class inadvertently, which comes back to providing at
most illusory const safety.  If you have a const pointer/ref to an
instance, you can't use its nonconst alias without scrounging up a
nonconst one.  But any function you call might call static nonconst
member functions on your class, without a second thought.  So where's
the safety?

---
[ 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://www.jamesd.demon.co.uk/csc/faq.html                       ]