Re: Why localize structures in this case.

Logan Shaw <lshaw-usenet@xxxxxxxxxxxxx> writes:
Rainer Weikusat wrote:

[someone writing about pimpl in C++]

A similar effect could be achieved by putting the definition in the
public header file, but define an 'interface class', which contains a
pointer to an object of the other class/ struct type. Something like:
struct X_impl {
/*
This is for internal use only.
*/
int a, b, c;
};
class X {
/* methods et. al */
private:
struct X_impl *x_impl;
};
This way, 'class users' of class X wouldn't need to be recompiled
when the definition of X_impl changes (this would, of course, break
'naive' automatically-generated header dependency rules) but
the information what an X_impl actually is would still be available to
people who may need to look at objects of this type.

I would find code that uses this idiom to be confusing because it
would imply that the data members are part of the implementation
but the methods aren't part of the implementation.

Huh? Methods are supposed to provide an interface to some
implementation whose details are not intended to matter for ordinary
uses. So, this would appear (to me at least) to be quite natural.

If you really want to hide the implementation, and you can afford
overhead of stuff like referring to all data members through an extra
pointer dereference (your 'x_impl' in this example), it seems cleaner
to just put an abstract class in the header file as the interface
and then subclass that in the implementation.

The point of my posting was actually that the implementation should
not be hidden because the respective information would be useful for
'non-ordinary uses', specifically, for debugging unrelated code.

Having thought about this somewhat since then, I came to a different
conclusion in this respect: The reason that C++-classes incoroprating
other classes need to be recompiled when the implementation of those
other classes changes is that this is a necessary side effect of the
'wanted' property that the compiler can generate more efficient code
if access to the data members of the implementation does not need to
go through an indirection every time. Additionally, this means it is
up to the 'class users' to decide where and how they want to allocate
storage for a particular instance of a class they use. This is
sensible, because the author of the class itself cannot possibly know
what 'storage requirements' may exist in a particukar situation where
the class could be used.

Taking these two issues into account, I would therefore take this one
step further and state that not only the implementation should not be
hidden, but additionally, that it is not the business of 'utility
class writers' to dictate others what compile-time versus run-time
speed tradeoffs they desire to make or limit what 'storage allocation
mechanisms' can be used when using a particular utility class, and that
people, to whom both doesn't matter, should probably consider using a
'more abstract' language than C++ happens to be.

Then the users of the class wouldn't have visibility into the
implementation because they wouldn't even know the name of the class
that contains the implementation! Of course this would force you to
hide object creation as well with a factory method or something
similar since you can't call a constructor without knowing the type
name in C++, but that might be a good thing in a lot of cases and a
neutral thing in many other cases.

It would be a bad thing for C++ (or for C, were similar things may be
constructed) because instances of such a class can neither live in the
ordinary program data segment nor coulde they be stack-allocated.
.

Relevant Pages

  • HOWTO: Create a new ATL VC++ class for a MAPI Address Book Provider
    ... If you want to develop a MAPI Address Book Provider ... How to make an interface inherite from another interface using ATL ... paste them into the new header file ABProvider.h into the class ...
    (microsoft.public.win32.programmer.messaging)
  • HOWTO: Create a new ATL VC++ class for a MAPI Address Book Provider
    ... If you want to develop a MAPI Address Book Provider ... How to make an interface inherite from another interface using ATL ... paste them into the new header file ABProvider.h into the class ...
    (microsoft.public.win32.programmer.messaging)
  • Re: If (global header files are bad) then ??
    ... the wrong header file is read in the wrong context. ... The next solution to this is to give the client a single header file and a .lib file which ... statically-linked MFC libraries vs. the shared MFC DLL library. ... Note however that all of these have one common theme: a single .h file as the interface ...
    (microsoft.public.vc.mfc)
  • Re: .h files
    ... Having header files allows the ability to separate the interface ... have to compile printf's dependencies -- meaning every single function ... printf call uses. ... everybody knows how to interface with it because of its header file. ...
    (alt.comp.lang.learn.c-cpp)
  • Re: Assistance required, exporting a class from a DLL
    ... data members and with all member functions being pure virtual. ... For those that export an interface related ... since that would mean that another library exporting ...
    (microsoft.public.vc.language)