Re: Non virtual base interface?

Hi,

The reason i want separate the implementation and private parts from
the public interface is not to hide them behind a firewall. I just
dont want to confuse my "simple" client by forcing him to scan thru an
overly big header file to find the public interface he should use.
Also i dont want to document this interface in plain text because the
description and the coded interface easily get out of sync.

Id rather not use PIMPL or CRTP because it does add some code
"clutter" to the interface class. Id like to keep the interface class
as declarations of the public interface only (similar to ABI) if i
can. Id like to use ABI if i knew the vtable was optimized away in non
polymorfic use.

Here is a more detailed example. To me the "A Non-Polymorphic
Interface Class" sounds like a reasonable idea.

<CODE>

struct Concrete1 { /* a simple cluttered example class we want to
emulate the behavior of */
    void publicFunction1() {}
    void publicFunction2(); /* calling this function will cause link
error because it lacks definition */
    //etc
private:
    void privateFunction1() {}
    //etc
};

struct TheAPI { /* A Non-Polymorphic Interface Class. (Public function
declarations separated from their definitions and from private
function declarations.)*/
    void publicFunction1();
    void publicFunction2();
    void publicFunction3(); /* just an extra test, see below.. */
    //etc
protected:
    TheAPI(){}
    ~TheAPI(){}
};

struct Concrete2: public TheAPI { /* will behave just like Concrete1
*/
    void publicFunction1() {} /* will behave just like
Concrete1::publicFunction1() */
    void publicFunction2(); /* will behave just like
Concrete1::publicFunction2() */
    //void publicFunction3() {} /* an extra test, TheAPI::publicFunction3
is declared but no Concrete2::publicFunction3 is defined (since this
line is commented out) */
    //etc
private:
    void privateFunction1() {}
    //etc
};

inline void TestConcrete() {
    //nothing surprising..
    Concrete1 c1;
    Concrete2 c2;
    c1.publicFunction1();
    c2.publicFunction1();
    //c1.publicFunction2(); /* link error, just like we want. (because
there is no Concrete1::publicFunction2 defintion) */
    //c2.publicFunction2(); /* link error, just like we want. (because
there is no Concrete2::publicFunction2 defintion) */
    Concrete1* c1p = new Concrete1();
    Concrete2* c2p = new Concrete2();
    c1p->publicFunction1();
    c2p->publicFunction1();
    delete(c1p);
    delete(c2p);

    /* clients shouldn't be able to use the TheAPI class in any way other
than as documentation.. */

    //TheAPI a; /* compile error, just like we want (because protected
TheAPI constructor) */
    TheAPI* pa = &c2; /* no error, ideally we would like the implicit
conversion of derived to base pointer an error. Its okay though
because the client wont be able to do anything useful with the TheAPI
pointer. */
    //c2->publicFunction1(); /* link error, just like we want. (because
there is no TheAPI::publicFunction1 defintion) */

    TheAPI* pa1 = new Concrete2(); /* no error, ideally we would like
the implicit conversion of derived to base pointer an error. Its okay
though because the client wont be able to do anything useful with the
TheAPI pointer. */
    //delete(pa1); /*compile error, just like we want (because protected
TheAPI deconstructor). If the client had no way of doing delete on the
TheAPI pointer then the memory will leak. I think the fact that a
delete cannot be done on a TheAPI* clearly signals that the TheAPI*
shouldnt have been used to hold the result of new in the first place.
*/

    /* so if there are no other issues with the use of the "Non-
Polymorphic Interface Class" i would prefer it to ABI, PIMPL or CRTP
for this use case.*/
}

</CODE>

Regards Patrik

--
      [ See http://www.gotw.ca/resources/clcm.htm for info about ]
      [ comp.lang.c++.moderated. First time posters: Do this! ]