In article <CDF4LK.CF6@cbnewse.cb.att.com> grumpy@cbnewse.cb.att.com (Paul J Lucas) writes:
>From article <276fr0$f00@techbook.techbook.com>, by deef@techbook.techbook.com (Derek Foster):
>>
>> Suppose I have a private enum type, like so:
>>
>> class X
>> {
>>   private:
>>     enum mytype {VALUE=42};
>>     mytype myfunc();
>>   // other functions...
>> };
>>
>> How do I then define the function myfunc? If I define it within the class
>> declaration, all is well, but if I try to define it elsewhere, via
>>
>> X::mytype X::myfunc()
>> {
>>   return VALUE;
>> }
>>
>> The compiler (BC++ 3.1) complains something along the lines of "can't access
>> private type 'X::mytype'" on the first line of the function declaration. If
>> I make the type public, it compiles fine. I can do this, of course, but I
>> would rather not, and I don't see why I should have to -- if I can
>> define a function in the class declaration, shouldn't I be able to define
>> the exact same function out of the class declaration?
>>
>> Any help would be appreciated.
>
> Your compiler is wrong.
>--
> - Paul J. Lucas
>   AT&T Bell Laboratories
>   Naperville, IL

Unless I am mistaken, Paul Lucas's response in this case relies upon certain
assumptions regarding visibility (within the return-type specifications of
member functions) which are not clearly supported by either the ARM or the
current X3J16 working paper.

If anyone wishes to disagree with that view, please proceed.  I would be
more than happy to be proven wrong on this point.  (Please provide relevant
citations however.)

Follow-ups to comp.std.c++ please.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <2798tf$v3d@rs6000.bham.ac.uk> G.PICKERING@bham.ac.uk writes:
>Derek Foster (deef@techbook.techbook.com) wrote:
>
>: Suppose I have a private enum type, like so:
>
>: class X
>: {
>:   private:
>:     enum mytype {VALUE=42};
>:     mytype myfunc();
>:   // other functions...
>: };
>
>: How do I then define the function myfunc? If I define it within the class
>: declaration, all is well, but if I try to define it elsewhere, via
>
>Anything declared private, be it a function, data member or enum can
>only be accessed within the class...

That statement is perfectly true, as far as it goes.

The question is however "Which portions of the source text should be
considered to be within the scope of the class?"  (In particular, we
need to know if that portion of the source test which constitutes the
return-type specification of a member function definition should be
considered to be within the scope of the parent class.)

I do not believe that either the ARM or the C++ standardization committee
has adequately answered this question (yet).

Follow-ups to comp.std.c++ please.

--

-- Ronald F. Guilmette ------------------------------------------------------
------ domain address: rfg@netcom.com ---------------------------------------
------ uucp address: ...!uunet!netcom.com!rfg -------------------------------

In article <rfgCDIuuo.8u9@netcom.com> rfg@netcom.com (Ronald F.
Guilmette) writes:

|> In article <2798tf$v3d@rs6000.bham.ac.uk> G.PICKERING@bham.ac.uk writes:
|> >Derek Foster (deef@techbook.techbook.com) wrote:

|> >: Suppose I have a private enum type, like so:

|> >: class X
|> >: {
|> >:   private:
|> >:     enum mytype {VALUE=42};
|> >:     mytype myfunc();
|> >:   // other functions...
|> >: };

|> >: How do I then define the function myfunc? If I define it within the class
|> >: declaration, all is well, but if I try to define it elsewhere, via

|> >Anything declared private, be it a function, data member or enum can
|> >only be accessed within the class...

|> That statement is perfectly true, as far as it goes.

|> The question is however "Which portions of the source text should be
|> considered to be within the scope of the class?"  (In particular, we
|> need to know if that portion of the source test which constitutes the
|> return-type specification of a member function definition should be
|> considered to be within the scope of the parent class.)

|> I do not believe that either the ARM or the C++ standardization committee
|> has adequately answered this question (yet).

I think practical problems of compiler construction will answer the
question.  The function return value *cannot* be parsed in the context
of the class the function is a member of.  Thus, when defining the
above function, it is necessary to specify the context, ie:

 X::mytype
 X::myfunc()
 {
  // ...
 }

Of course, all of this has *nothing* to do with private and public.
Private and public are access specifiers; symbol lookup is done
*without* taking them into consideration.  The access specifiers
should only come into play when the symbol is to be used.  (Since the
use X::mytype is part of the definition of a member function of X, it
should be legal.  At least, that is my opinion, and I think the
general concensus of the standards committee.  I don't have a quote
from the ARM, though, to prove my case.)
--
James Kanze                             email: kanze@us-es.sel.de
GABI Software, Sarl., 8 rue du Faisan, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                   -- Beratung in industrieller Datenverarbeitung