<<
 >In this case, the question is from where is ~Foo accessed?

 Right. The answer to _where_ ~Foo() is accessed is "at the definition
of the Foo object".
>>

Are you sure? It may be where the compiler is checking it in this
instance, but it would not do much that was where it was accessed!

<<
 >Is it ~Bar?

 No, of course not.

 >Bar::f is a __static__ object,
 >so its destructor is invoked on exit from main(),

 That's _when_ it's destructor is invoked.
>>

I think that this use of "where" and "when" is confusing the issue.
If a class member function is called at line n of a program, that is
_where_ it is accessed, and it is accessed _when_ that piece of code is
itself invoked.

The closing brace/return from main (or in some compiler-generated code
nearby) is _where_ the compiler is accessing the destructor, just as the
closing brace in any pair of braces is _where_ the destructor is
accessed for ordinary automatic objects defined in their scope (for the
latter, have a look at Stanley Lippman's book "Inside the C++ Object
Model", pages 203-205). I would therefore suggest that, while you may not
see code like

main()
{
    ...

    Bar::f.~Foo();     // *** Compiler generated ***
    return 0;
}

something like it is there or thereabouts.

How do you think the destructor is called?

<<
 >and thus (IMHO) needs public accessibility.

 I don't see how this follows.
>>

The other crucial question is _what_ accesses the destructor, even if
this access is somehow performed at the definition of Bar::f.
Since the CRT is not part of Foo, and cannot be made its friend, IMHO it
is subject to the same restrictions on access as anything else.
The only way Bar's friendship could help would be if the cleanup of
static members was considered to be part of Bar; conceptually, as some
sort of compiler generated static function Bar::___clean_static_data,
invoked by the CRT at the end of main.
In that case, you would be right, and I would be wrong - I would be very
happy to stand corrected if it were so.

I had a look at the DWP to try and clarify this, but couldn't find any
clear definition of where the destructor of a static member object is
considered to be accessed. Perhaps someone, for example, one of the
committee could help here?

(As an aside, a comprehensive index to the DWP would be very useful
addition to it - in any case, I couldn't see one in
http://www.cygnus.com/~mrs/wp-draft)

Dominic
Bruxelles, Fri, 29 Nov 1996 13:07 +0100
also cis:106136,2400
using Virtual Access 3.52 build 159c (32-bit)
on WinNT build 1057 (3.51)
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Statics are destroyed after the return from main. So the question really is
do the access specifications of the destructor apply at the point it is
constructed, or the point at which it is destroyed?

Also, what about this case?

class Baz
{
public:
Foo * func() {static Foo foo; return &foo;}
}

Fergus Henderson <fjh@mundook.cs.mu.OZ.AU> wrote in article
<576tha$4t6@mulga.cs.mu.OZ.AU>...
> weiss@pacsim.com (Phil Weiss) writes:
>
> ] I am unable to find the appropriate portion of the April working draft
> ] which might shed some light on this, but some of the committee members
> ] or C++ language lawyers might know better.
> ]
> ] Should the following compile on a conforming compiler?
>
> Yes, the example should compile, IMHO.
>
> ] class Foo
> ] {
> ]    friend class Bar;
> ] private:
> ]    Foo() {};
> ]    ~Foo() {};
> ] };
> ]
> ] class Bar
> ] {
> ] public:
> ]    static Foo f;
> ] };
> ]
> ] Foo Bar::f; // my compiler gives me an error, saying ~Foo is private
>
> The line `Foo Bar::f' is a declaration (and also definition) of
> a member function of `Bar', and `Bar' was declared to be a friend of
> `Foo', hence ~Foo is accessible at that point.
>
> See 11.4[class.friend]/3.

---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

"Steve Downey" <steve.downey@servicing.com> writes:

>Statics are destroyed after the return from main.

That's the "when" -- a point in time, not a location in the program.

>So the question really is
>do the access specifications of the destructor apply at the point it is
>constructed, or the point at which it is destroyed?

I'd say the access specifications should be checked at the place in the
program where the definition of object occurs.

Which other program point could it be checked at?

>Also, what about this case?
>
>class Baz
>{
>public:
>Foo * func() {static Foo foo; return &foo;}
>}

Same deal.  Access should be checked at the place where the object
is defined.  In this case, if `Baz' is a friend of `Foo', then this
code should be OK.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

<< I'd say the access specifications should be checked at the place in
the program where the definition of object occurs.

Which other program point could it be checked at? >>

Surely, wherever access to the member function/data item is attempted.

In this case, the question is from where is ~Foo accessed? Is it ~Bar?
If it were so, then that would be OK because of Bar's friendship with
Foo. However Bar::f is a __static__ object, so its destructor is invoked
on exit from main(), and thus (IMHO) needs public accessibility.

Dominic
Bruxelles, Wed, 27 Nov 1996 18:58 +0100
also cis:106136,2400
using Virtual Access 3.52 build 159c (32-bit)
on WinNT build 1057 (3.51)
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Dominic North <Dominic.North@ping.be> writes:

><< I'd say the access specifications should be checked at the place in
>the program where the definition of object occurs.
>
>Which other program point could it be checked at? >>
>
>Surely, wherever access to the member function/data item is attempted.
>
>In this case, the question is from where is ~Foo accessed?

Right.  The answer to _where_ ~Foo() is accessed is "at the definition of
the Foo object".

>Is it ~Bar?

No, of course not.

>Bar::f is a __static__ object,

>so its destructor is invoked on exit from main(),

That's _when_ it's destructor is invoked.

>and thus (IMHO) needs public accessibility.

I don't see how this follows.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Fergus Henderson wrote:
>
> Dominic North <Dominic.North@ping.be> writes:
>
> ><< I'd say the access specifications should be checked at the place in
> >the program where the definition of object occurs.
> >
> >Which other program point could it be checked at? >>
> >
> >Surely, wherever access to the member function/data item is attempted.
> >
> >In this case, the question is from where is ~Foo accessed?
>
> Right.  The answer to _where_ ~Foo() is accessed is "at the definition of
> the Foo object".
...

Yes. Access control applies, in this case, for all members of the class,
including the static member of type Foo. If the class has access to
Foo's private members, then all its members do (this is how it works).
The static member is a member of the class, so it has access to private
functions of Foo.

> >Bar::f is a __static__ object,
> >so its destructor is invoked on exit from main(),
>
> That's _when_ it's destructor is invoked.
>
> >and thus (IMHO) needs public accessibility.
>
> I don't see how this follows.

Looking at the program from a dynamic view, the object is constructed
some time before main() is invoked, and destructed some time after
main() returns, or exit() is called. Access control is not a dynamic
thing. It applies to the static model of the system. Access control is
irrelevant in this dynamic model, because any violations would prevent
the program from compiling, thus there would be no dynamic model (just a
broken program :-).

--
Chelly Green | chelly@eden.com | C++ - http://www.eden.com/~chelly
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

weiss@pacsim.com (Phil Weiss) writes:

] I am unable to find the appropriate portion of the April working draft
] which might shed some light on this, but some of the committee members
] or C++ language lawyers might know better.
]
] Should the following compile on a conforming compiler?

Yes, the example should compile, IMHO.

] class Foo
] {
]    friend class Bar;
] private:
]    Foo() {};
]    ~Foo() {};
] };
]
] class Bar
] {
] public:
]    static Foo f;
] };
]
] Foo Bar::f; // my compiler gives me an error, saying ~Foo is private

The line `Foo Bar::f' is a declaration (and also definition) of
a member function of `Bar', and `Bar' was declared to be a friend of `Foo',
hence ~Foo is accessible at that point.

See 11.4[class.friend]/3.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Alexandre Oliva <oliva@dcc.unicamp.br> writes:

>Phil Weiss writes:
>
>> Should the following compile on a conforming compiler?
>
>[snipped: declaration of object of class whose constructor and
>destructor are private]
>
>No, it should not.  The constructor should be visible, as well as the
>destructor.

You snipped a crucial part of the example: the constructor and
destructor _are_ visible in the example, because the object
in question is a static data member of a friend class.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

Phil Weiss writes:

> Should the following compile on a conforming compiler?

[snipped: declaration of object of class whose constructor and
destructor are private]

No, it should not.  The constructor should be visible, as well as the
destructor.  In Sept'96 DWP, these restrictions are in [class.ctor]
paragraph 8 and [class.dtor] paragraph 10.

--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br
Universidade Estadual de Campinas, SP, Brasil
---
[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

I am unable to find the appropriate portion of the April working draft
which might shed some light on this, but some of the committee members
or C++ language lawyers might know better.

Should the following compile on a conforming compiler?

class Foo
{
   friend class Bar;
private:
   Foo() {};
   ~Foo() {};
};

class Bar
{
public:
   static Foo f;
};

Foo Bar::f; // my compiler gives me an error, saying ~Foo is private


Phil.


[ 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         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]