Topic: proposal for implimentation only methods in a class


Author: "Bruce Mellows" <bruce+101@wakethegimp.org>
Date: 8 Aug 2005 00:20:02 GMT
Raw View
It does preclude you from having any inlines for one thing.

But not to worry, the door seems to be closed.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: "Bruce Mellows" <bruce+101@wakethegimp.org>
Date: 3 Aug 2005 23:10:05 GMT
Raw View
The problem is that I need to declare the implimentation in the
interface.

eg.

class A
{
public:
  A();
  ~A();
  // ... etc
  void user_visible_method_1();
  void user_visible_method_2();
private:
  void user_visible_methods_common_implimentation();
};

Why does the user of either user_visible_method need to know that there
is a method named user_visible_methods_common_implimentation? I believe
that they don't.

So that I am proposing that the private method
user_visible_methods_common_implimentation need not be declared, but
only defined in the c (cc, cpp, cxx, c++, C, whatever) file, and that
it would be assumed to be private, this further allows us to
change/re-factor the implimentation without having to re-compile every
user, which is a big deal when the project gets larger

Of course there is the constraint that these sort of implimentation
only methods do not change the 'shape' of the class, ie. they cannot
override a virtual, though they might overload a method.

This may also be usable for not declaring nested private classes in the
header, and only putting them in the implimentation file, these might
inherit from some interface and forward it to the main class, such that
the class can conform to an interface in its implimentation but not in
its interface.

I personaly see some value in it, and hope that there would not be much
work in acheiving this from the compiler vendors perspective (you are
allowed to add to namespaces at any time, why not classes)

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: squell@alumina.nl (Marc Schoolderman)
Date: Thu, 4 Aug 2005 00:29:44 GMT
Raw View
Bruce Mellows wrote:

> Why does the user of either user_visible_method need to know that there
> is a method named user_visible_methods_common_implimentation? I believe
> that they don't.

Have you read Marshall Cline's faq?

http://www.parashift.com/c++-faq-lite/classes-and-objects.html#faq-7.6

Furthermore, there exist idioms you can use to hide implementation
details. For example, the handle/body pattern;

http://www.gotw.ca/gotw/024.htm

Why _your_ proposal won't work: if an inline memberfunction of a class
needs the private member, it has to know it's signature, as well as that
the private member needs to have external linkage.

~Marc.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: "Bruce Mellows" <bruce+101@wakethegimp.org>
Date: 4 Aug 2005 01:10:06 GMT
Raw View
Yes, I have read the FAQ, but I don't work with people who have, and if
I tell them that some 'idiom' can help to separate our inteface and
implimentation, ..., well not much separation is going to get done
(Think Bob from Conversations).

Regarding using some pattern or idiom to circumvent this need, perhaps
it might be nice to go direct rather than via a workaround ? (You can
get from New York to New Jersey by air - perhaps via Los Angeles if you
want, or you could get there easier by cab)

You're absolutely correct about an inline method needing the signature.
So it stands to reason that you would not be able to call it from
there, just like you cannot call any undeclared method or function - a
fine limitiation I would expect.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: Carl Barron <cbarron413@adelphia.net>
Date: 5 Aug 2005 23:00:14 GMT
Raw View
In article <1123109337.867536.228580@g47g2000cwa.googlegroups.com>,
Bruce Mellows <bruce+101@wakethegimp.org> wrote:

> The problem is that I need to declare the implimentation in the
> interface.
>
> eg.
>
> class A
> {
> public:
>   A();
>   ~A();
>   // ... etc
>   void user_visible_method_1();
>   void user_visible_method_2();
> private:
>   void user_visible_methods_common_implimentation();
> };
>
> Why does the user of either user_visible_method need to know that there
> is a method named user_visible_methods_common_implimentation? I believe
> that they don't.
>
> So that I am proposing that the private method
> user_visible_methods_common_implimentation need not be declared, but
> only defined in the c (cc, cpp, cxx, c++, C, whatever) file, and that
> it would be assumed to be private, this further allows us to
> change/re-factor the implimentation without having to re-compile every
> user, which is a big deal when the project gets larger
>
> Of course there is the constraint that these sort of implimentation
> only methods do not change the 'shape' of the class, ie. they cannot
> override a virtual, though they might overload a method.
>
> This may also be usable for not declaring nested private classes in the
> header, and only putting them in the implimentation file, these might
> inherit from some interface and forward it to the main class, such that
> the class can conform to an interface in its implimentation but not in
> its interface.
>
> I personaly see some value in it, and hope that there would not be much
> work in acheiving this from the compiler vendors perspective (you are
> allowed to add to namespaces at any time, why not classes)
>
  what is wrong with the pimple idiom easiest implimented as:
  class Foo
  {
   struct Bar;
   tr1::shared_ptr<Bar> pimple;
  public:
   //...
  };

  or unnamed namespaces in the implimentation file?

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: Bruce Mellows <bruce+101@wakethegimp.org>
Date: Wed, 3 Aug 2005 00:55:10 CST
Raw View
A problem exists that methods specific to the implimentation of a
classes behaviour, namely its private non-virtual methods must be
declared on the class declaration.

If one could define methods for a class that do not override a virtual
method (but may overload a non-virtual method), and that these methods
are given the priviledge of private only, thus a class declaration need
only contain methods that are significant to a user of the declaration.

A supplied private implimentation only method has static linkage, such
that it cannot be referenced outside of the translation unit.

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]





Author: v.Abazarov@comAcast.net (Victor Bazarov)
Date: Wed, 3 Aug 2005 17:50:53 GMT
Raw View
Bruce Mellows wrote:
> A problem exists that methods specific to the implimentation of a
> classes behaviour, namely its private non-virtual methods must be
> declared on the class declaration.

Why is that a problem?

> [...]

---
[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]