Hiding implementation

[borophyll]

Is there any alternative to hiding private members of a class without
using the Pimpl idiom? I know it probably doesn't affect performance
by much (although it would at least slightly), it just seems like such
an ugly hack and it detracts from the readability of the code.

Regards,
B.

 

[cplusplus]

What you need to do is to go out and get laid and then think about the
question you're asking . Ask your self id this realy that important to
you . If it is then know this you're a ****** .

 

[benben]

Is there any alternative to hiding private members of a class without
using the Pimpl idiom? I know it probably doesn't affect performance
by much (although it would at least slightly), it just seems like such
an ugly hack and it detracts from the readability of the code.

The immediate one in my head is to use pure abstract base class, which
is basically a p-impl hidden behind virtual dispatch mechanism:

class dog_impl;

class dog
{
virtual void bark() const =0;
virtual ~dog(){}

static std::auto_ptr<dog> create()
{
return std::auto_ptr<dog>(new dog_impl())
}
};


class dog_impl: public dog_impl
{
void bark() const;
~dog_impl();
};

But, on the user's stand point, this design is just not as intuitive to
use as p-impl, for the following reasons:

1) The interface class is a pure abstract class although it portraits a
concrete one and shall be used as a concrete one.

2) The user has to call a factory function to create an instance.

3) Assignment and copying are not easy to implement. In fact, since the
user is only given an effective pointer, any operator overloading will
be unavailable.

4) The concrete class is not readily derivable.

5) The problem complicates exponentially when more classes are derived
from the same base class.

Regards,
B.

Regards,
Ben

 

[Markus Moll]

Hi

Is there any alternative to hiding private members of a class without
using the Pimpl idiom? I know it probably doesn't affect performance
by much (although it would at least slightly), it just seems like such
an ugly hack and it detracts from the readability of the code.

Using inheritance and interfaces is often an option. Paired with a factory
of some kind, you wouldn't give away any internals besides the public
interface.

Markus

 

[borophyll]

Thank you both for your input. The above methods seem to suffer from
the same problems of roundaboutness as pImpl, with other associated
problems. So I guess it really comes down to the language's design.
Why did C++ choose to not allow a program to define certain parts of a
class in seperate places (eg public interface in header file, and the
rest elsewhere).

Regards,
B.

 

[James Kanze]

Thank you both for your input. The above methods seem to suffer from
the same problems of roundaboutness as pImpl, with other associated
problems. So I guess it really comes down to the language's design.
Why did C++ choose to not allow a program to define certain parts of a
class in seperate places (eg public interface in header file, and the
rest elsewhere).

Because there's no way to implement it otherwise, and still meet
the other constraints (integration with the C development
environment, etc.).

 

[benben]

Thank you both for your input. The above methods seem to suffer from
the same problems of roundaboutness as pImpl, with other associated
problems. So I guess it really comes down to the language's design.
Why did C++ choose to not allow a program to define certain parts of a
class in seperate places (eg public interface in header file, and the
rest elsewhere).

I think you are mixing program organisation with the p-impl idiom. It
may be helpful to recap what exactly the problem the p-impl design was
really trying to solve. From what I know, p-impl lets you:

1) redesign part of the class without having to recompile other parts of
the program

2) facilitate fast data swapping between objects. That is, instead of
swapping all data elements, a p-impl class needs only to swap with the
content pointer.

3) share content between objects (not primary purpose)


AFAICS, problem 1) is a non problem from a language design perspective.
The C++ language has always been a programming language, not a
programming language + build specification + anything else.

To achieve the zero-overhead principle C++ assumes a very compact object
model, in which no redirection shall be needed unless otherwise
specified. The P-impl method is the kind of redirection in data
structure the language refuses to construct itself. The "unless
otherwise specified" is the virtual function part.

In any case, a non p-impl design constitute a clean design provided you
are happy to recompile the entire program every time you make a little
bit of change here and there.

Problem 2) and 3) are entirely design problems and are only problems to
certain type of situations. Obviously, the language does not enforce them.

You really can define public interface and the rest of the class in
separate files in C++. Yes, you can, without doing p-impl or
inheritance. But then it is just a way to organise the program and it
still doesn't solve problems 1) 2) and 3).

Regards,
B.

Ben