In article <24872@uflorida.cis.ufl.EDU> rmy@beach.cis.ufl.edu () writes:
>
>The question is: would it be wrong to define a class that simply
>represents an interface to a layer or module...

A related question was discussed awhile back, i.e. the question of
why C++ can't be a bit more like Ada.

Specifically, I think that the kind of thing that you are perhaps
looking for might be a header file that looks kinda like this:

 class car;

  car::car (int cost);
  car::~car ();
  heading car::turn (direction d);
  next_date car::change_oil (station s);

In other words, a sort of *abbreviated* description of the interface to
a class which is provided to some user of the class.

Allowing abbreviated descriptions like this (which leave out information
about data members) could potentially cut down dramatically on the
amount of recompilations we have to do over the lifetime of a class.

I hope that the ANSI committee will consider this possible solution
for an important (and as yet unresolved) problem.

I (for one) can't see any problems with the solution proposed here.
It certainly doesn't break any existing syntax rules, and if (for
instance) `car::turn' was never really defined for the class car, then
you most certainly would find out about *that* problem at link time.

One minor problem with this proposed `feature' is that `car::change_oil'
might be private to the class car (in which case the user of the header
file should not be allowed to use `car::change_oil'.

That problem could easily be solved by providing three different name
manglings for member functions.  One (and only one) of these would be
selected and used depending upon the access category (i.e. public,
private, or protected) of the member function where its *true*
declarations (within the class body) occurs.

--

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.