John Potter writes:

> : It can, since, inside the scope of foo, both the constructor and the
> : destructor are acessible.

> I note the lack of your normal draft quote of chapter and verse :-)

:-)

> Since the destructor is going to be called by some compiler generated
> cleanup function, the question is "does that function have access or
> does that function need access?"

The way the compiler implements the destruction of objects with static
duration is not in the scope of the Standard.  The Standard specifies
what must be done, not the way it should be done.  The fact is that,
since foo is a friend of the class, all members of the class are
accessible inside its body, in particular it can access the
constructor and the destructor of the original class, as is stated in
[special] paragraph 2. :-)

The fact that the compiler uses a cleanup function or not, or even the
fact that an object is static or not must not affect the accessibility
of its members.  The point is: foo has got priviledged access to the
class, so that it can instantiate objects of that class.  Since the
point of declaration of the static object is inside the scope of foo,
accessibility is tested in that scope.  Particularly, paragraph 5 in
[class.access] states that the access rules rule about the ability to
access a class member from a given scope, which seems to support my
interpretation.  Also, paragraph 3 in the same section says that
access control applies uniformly to all names.

--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
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                             ]

jpotter@falcon.lhup.edu (John Potter) wrote:

>There is another thread on clc++m about this.  I suspect that it was
>moved here to get a real answer.  Chapter and verse.  I do not have
>one, but would like to see one.

Yes, that was basically what it boiled down to.  There doesn't appear to be any passage that makes this clear.  As a result we have compilers that have decided to handle it differently.
--------------------------------------------
David Bradley         davidb@datalytics.com
Software Engineer
Datalytics, Inc.      http://www.datalytics.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

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

>Particularly, paragraph 5 in
>[class.access] states that the access rules rule about the ability to
>access a class member from a given scope, which seems to support my
>interpretation.  Also, paragraph 3 in the same section says that
>access control applies uniformly to all names.

Yes, but constructors and destructors don't have names.  [12.1/1]

--
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
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

 [ Regarding accessability of private destructor with static objects ]

On 29 May 97 12:29:54 GMT, Alexandre Oliva wrote:
: John Potter writes:
: > Alexandre Oliva wrote:
: > : It can, since, inside the scope of foo, both the constructor and the
: > : destructor are acessible.
: > Since the destructor is going to be called by some compiler generated
: > cleanup function, the question is "does that function have access or
: > does that function need access?"

: The way the compiler implements the destruction of objects with static
: duration is not in the scope of the Standard.  The Standard specifies
: what must be done, not the way it should be done.  The fact is that,
: since foo is a friend of the class, all members of the class are
: accessible inside its body, in particular it can access the
: constructor and the destructor of the original class, as is stated in
: [special] paragraph 2.

Yes, foo can.  The constructor will be accessed on the first call of
foo within the context of foo.  But, when will the destructor be
accessed and in what context?  12.4/10 says that a program is ill
formed if an explicit or implicit call of the destructor is generated
and the destructor is not accessable.

: The fact that the compiler uses a cleanup function or not, or even the
: fact that an object is static or not must not affect the accessibility
: of its members.  The point is: foo has got priviledged access to the
: class, so that it can instantiate objects of that class.  Since the
: point of declaration of the static object is inside the scope of foo,
: accessibility is tested in that scope.

Sounds good to me, but is it correct?  Consider a member function
which performs a new and returns a pointer.  A non-friend stores the
pointer and later uses delete.  This is an example of the access at
construction and destruction being different.  I do not think that
this is a good counter example, but it does show the need for explicit
wording, which is not present, to support your statement.

: Particularly, paragraph 5 in
: [class.access] states that the access rules rule about the ability to
: access a class member from a given scope, which seems to support my
: interpretation.  Also, paragraph 3 in the same section says that
: access control applies uniformly to all names.

Fergus Henderson wrote:
> : Yes, but constructors and destructors don't have names.  [12.1/1]

12.1 is about constructors only.  12.4 is about destructors and does
not contain the explicit exclusion of a name.  12.4/12 describes how
the name of a destructor is formed, but falls short of really saying
that it is a name.  Anyway, I can say xp->~X() and that sequence of
synbols (name?) must mean something.

The original problem involved a static member function (same results
with friend function) with a local static (Local below) and VC++.  I
consulted some other compilers for opinions:

class C {
 public:
  static C& getC();
  static C staticOne; // Member added to original
 private :
  C();
  C (C const&);
  ~C();
 };
C C::staticOne;
C& C::getC () {
  static C mine;  // Local
  return mine;
 }

VC++ reportedly complained about "mine" not having accessable dtor.

Cfront made no complaints about dtors but complained about ctor for
"staticOne".  We know that complaint is invalid.  But, cfront was
written in the days when compiler writers did what seemed reasonable
and had no draft standard.  The rules for special members have changed
greatly since then.  Today we care about standard behavior much more
than reasonableness.

BC++4.5 and g++2.7.2 complained about dtor being inaccessable for both
of them.

xlC complained about "mine" but not about "staticOne".

With these opinions, it seems that the draft is either not too clear
or clearly states that the code is ill formed.  It is also worth
noting that the three most current (my xlC is old) implementations
make the most complaints.

Is there an answer?

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         ]
[ 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 encountered this problem and posted a message in comp.lang.c++.moderated.  It looks as if this might be more of a standard's issue.

Take the following:

class A
{
private:
 A();
 ~A();
 friend void foo(void);
};

void foo(void)
{
 static A instance;
}

The question is, can the compiler generate a call to the destructor or should it flag it as an access violation due to the private destructor?

David Bradley writes:

[class A declares private constructor and destructor, and a friend
::foo().  foo declares a static variable that is an instance of A]

> The question is, can the compiler generate a call to the destructor
> or should it flag it as an access violation due to the private
> destructor?

It can, since, inside the scope of foo, both the constructor and the
destructor are acessible.

--
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
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                             ]

On 28 May 97 16:47:33 GMT, Alexandre Oliva wrote:

: David Bradley writes:

: [class A declares private constructor and destructor, and a friend
: ::foo().  foo declares a static variable that is an instance of A]

: > The question is, can the compiler generate a call to the destructor
: > or should it flag it as an access violation due to the private
: > destructor?

: It can, since, inside the scope of foo, both the constructor and the
: destructor are acessible.

I note the lack of your normal draft quote of chapter and verse :-)

Since the destructor is going to be called by some compiler generated
cleanup function, the question is "does that function have access or
does that function need access?"

There is another thread on clc++m about this.  I suspect that it was
moved here to get a real answer.  Chapter and verse.  I do not have
one, but would like to see one.

John
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]