fzjaffe@othello.ucdavis.edu (Rory Jaffe) writes:

>Certainly something, either the compiler or the language, is broken.  It
>doesn't make sense that I can return a private enum if I define the
>function inside the class declaration, but can't return a private enum
>if I delay the definition of the declared function until I am outside
>the class declaration.

I agree (I'm the one who started this thread) but it seems that that's the
way things are in C++ today.

I do have a suggestion on how things could be fixed, however. My suggestion
would be to extend the syntax and semantics of the new 'namespace' feature
so that one could use a class declaration as a de facto namespace. Functions
and variables defined within this pseudo-namespace would be allowed syntax
just as if they were defined within the class declaration. Thus, one could
write:

// in a header file...
class A { enum B {XXX}; B func(); }
// in a source file...
namespace A  // this isn't currently legal, but it could be made so.
{
  // note that the following is NOT an inline function, but is a normal
  // member function of A, but since it is in namespace A, the A:: is
  // not necessary for B or func().
  B func() {return XXX;}
}
// if the declaration for func() were done according to the current rules
// of C++, it would have to be written as
A::B A::func() {return XXX}
// which, as we've previously discussed, is illegal C++ since the A::B is
// a private type which is inaccessible at file scope. So according to the
// current rules of C++, this function MUST be defined in the class header
// and is impossible to define anywhere else.

Just to get a little farther out on a limb, I can see lots of other
opportunities for my proposal to save redundant declarations, if it were
fully implemented (which might involve letting namespaces be templated like
classes and functions, as I've shown below), such as even perhaps:

template <class T> class List<T>
{
  private:
    class Elem<T> { ... };
    typedef Elem<T> elem;
  public:
    static int Q;
    elem & Add(elem &);
    elem & Subtract(elem &);
}
template <class T>
namespace List<T>
{
  int Q=42;  // outside the namespace this would be 'int List<T>::Q=42;'
  elem & Add(elem & E) { do_whatever(E);}
  elem & Subtract(elem & E) { do_whatever(E);}
  // in the above, note that with the current rules for C++ declarations,
  // I would have had to write, for function Add, something like:
  //  template <class T> Elem<T> & List<T>::Add(Elem<T> & E) {do_whatever(E);}
  // which is almost twice as long as my version, and is illegal C++ as
  // well, since the Elem<T> class is a private class and can't be returned at
  // file scope.
}

Now, doesn't this substantially reduce the ugliness of having to declare
each function as a separate template as we have to do now? I have many
header and source files with lots of functions declared like:

template <class T> ListIterator<T> ListIterator<T>::operator ++ (int)
{
  ...
}

which could, under my proposal, be shortened CONSIDERABLY, as well as
not having any of the nasty problems such as inability to have a private
enum type or a private class type as a return value, which is, in my
opinion, a BIG HOLE in the current C++ definition.

Anyway, I'd like to hear what Real Standards People in particular think
about this. Is it possible? Practical? Are there other ways under discussion
to fix the same problem?

Derek Riippa Foster


--
deef@techbook.COM  Public Access User --- Not affiliated with TECHbooks
Public Access UNIX and Internet at (503) 220-0636 (1200/2400, N81)

In article <2938b7$2dn@techbook.techbook.com> deef@techbook.techbook.com (Derek Foster) writes:
>
>I agree (I'm the one who started this thread) but it seems that that's the
>way things are in C++ today.
>
>I do have a suggestion on how things could be fixed, however. My suggestion
>would be to extend the syntax and semantics of the new 'namespace' feature
>so that one could use a class declaration as a de facto namespace.

>Anyway, I'd like to hear what Real Standards People in particular think
>about this. Is it possible? Practical? Are there other ways under discussion
>to fix the same problem?

 Its possible. It could be allowed to
define new invisible private non-virtual non-static members in the
extended namespace of a class. (Commonly called helper
functions).

 The major stumbling block for the extended proposal appears to
be that the helper functions would not appear in the class interface
declaration, so you couldnt find the names of all the methods with
access to the classes private parts by looking there.
(Obviously, thats exactly the intention of the proposal: to
hide implementation details :-)

 This disadvantage does not occur if adding helpers is
not allowed. Neither is the utility of the extension so great.
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA

In article <CEnAt9.4y2@ucc.su.OZ.AU> maxtal@physics.su.OZ.AU (John Max Skaller) writes:
>In article <2938b7$2dn@techbook.techbook.com> deef@techbook.techbook.com (Derek Foster) writes:
>>
>>I agree (I'm the one who started this thread) but it seems that that's the
>>way things are in C++ today.
>>
>>I do have a suggestion on how things could be fixed, however. My suggestion
>>would be to extend the syntax and semantics of the new 'namespace' feature
>>so that one could use a class declaration as a de facto namespace.
>
>>Anyway, I'd like to hear what Real Standards People in particular think
>>about this. Is it possible? Practical? Are there other ways under discussion
>>to fix the same problem?
>
> Its possible. It could be allowed to
>define new invisible private non-virtual non-static members in the
>extended namespace of a class. (Commonly called helper
>functions).
>
> The major stumbling block for the extended proposal appears to
>be that the helper functions would not appear in the class interface
>declaration, so you couldnt find the names of all the methods with
>access to the classes private parts by looking there.
>(Obviously, thats exactly the intention of the proposal: to
>hide implementation details :-)
>
> This disadvantage does not occur if adding helpers is
>not allowed. Neither is the utility of the extension so great.

This problem could be circumvented if the set of helper functions could be
localized by allowing the definition and implementation of the class to
be separated, with only one implementation allowed per class.

       // In the header file:
       class definition MyClass {
           enum PrivateType {X};
           // ...
       };

       //-------------------------------
       // In some other file:

       class implementaion MyClass {
           PrivateType helper();
       };

Since only one implementation exists per compilation, the encapsulation of
the class is maintained.

The fact there is only one implementation per class has other advantages,
however, I agree with you, I doubt that this extention is useful enough.
Even though the status quo class declaration is not perfect, it is good
enough for almost all class definitions.

>--
>        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
> Maxtal Pty Ltd,      CSERVE:10236.1703
>        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
>        NSW 2131, AUSTRALIA

Take care
    Robert

--
/----------------------------------+------------------------------------------\
| Robert N. Deviasse               |"If we have to re-invent the wheel,       |
| EMAIL: g2devi@cdf.utoronto.ca    |  can we at least make it round this time"|
+----------------------------------+------------------------------------------/

In article <1993Oct10.034003.16004@cdf.toronto.edu> g2devi@cdf.toronto.edu (Deviasse Robert N.) writes:

>The fact there is only one implementation per class has other advantages,
>however, I agree with you, I doubt that this extention is useful enough.
>Even though the status quo class declaration is not perfect, it is good
>enough for almost all class definitions.

 I think that *with* the ability to add helper functions,
the extension is useful enough, in particular, useful enough
to loose the ability to lookup all the methods that can access
the internal details in one hit by inspecting the interface.

 You can always use a tool, I dont expect loss
of this assurance is a major problem, but without practical
experience its hard to tell.

--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,      CSERVE:10236.1703
        6 MacKay St ASHFIELD,     Mem: SA IT/9/22,SC22/WG21
        NSW 2131, AUSTRALIA