Re: Idiots

From:

"Leigh Johnston" <leigh@i42.co.uk>

Newsgroups:

comp.lang.c++

Date:

Fri, 16 Apr 2010 16:34:29 +0100

Message-ID:

<L8adnW60k58WHlXWnZ2dnUVZ8u6dnZ2d@giganews.com>

"Keith H Duggar" <duggar@alum.mit.edu> wrote in message
news:ae003626-6afe-4ec2-86f0-49c4af72b498@w16g2000vbf.googlegroups.com...

As far as the compiler generated Microsoft COM interface was concerned it
did not contain any state or invariant checks (a requirement for an
abstract
interface) and the virtual function that was "wrapped" was not made
private
the "wrapper" being simply an additional (optional) helper function. And
the two other "unwrapped" pure virtual functions of the abstract
interface
were public.

But they /did have/ member function implementations! And that is
precisely what I and other were talking about with thunks. Can
you not comprehend this so very simple fact??

I was not talking about thunks, I was talking about the validity of public
virtual functions in general. An *optional* inline helper function is not a
"thunk". The virtual function that the *optional* inline helper function
wrapped was still public (i.e. still callable). This thread was about the
validity of public virtual functions and the Microsoft IUnknown example does
not contradict my opinion on this matter, i.e. public virtual functions are
fine in certain contexts. Most of the standard Microsoft COM interfaces do
not have any inline helper functions (modulo IUnknown::QueryInterface):

    IDispatch : public IUnknown
    {
    public:
        virtual HRESULT STDMETHODCALLTYPE GetTypeInfoCount(
            /* [out] */ __RPC__out UINT *pctinfo) = 0;

        virtual HRESULT STDMETHODCALLTYPE GetTypeInfo(
            /* [in] */ UINT iTInfo,
            /* [in] */ LCID lcid,
            /* [out] */ __RPC__deref_out_opt ITypeInfo **ppTInfo) = 0;

        virtual HRESULT STDMETHODCALLTYPE GetIDsOfNames(
            /* [in] */ __RPC__in REFIID riid,
            /* [size_is][in] */ __RPC__in_ecount_full(cNames) LPOLESTR
*rgszNames,
            /* [range][in] */ __RPC__in_range(0,16384) UINT cNames,
            /* [in] */ LCID lcid,
            /* [size_is][out] */ __RPC__out_ecount_full(cNames) DISPID
*rgDispId) = 0;

        virtual /* [local] */ HRESULT STDMETHODCALLTYPE Invoke(
            /* [in] */ DISPID dispIdMember,
            /* [in] */ REFIID riid,
            /* [in] */ LCID lcid,
            /* [in] */ WORD wFlags,
            /* [out][in] */ DISPPARAMS *pDispParams,
            /* [out] */ VARIANT *pVarResult,
            /* [out] */ EXCEPINFO *pExcepInfo,
            /* [out] */ UINT *puArgErr) = 0;

    };

The above is an "abstract interface", i.e. a class whose polymorphic
interface is entirely abstract. Any *optional* non-virtual inline helper
functions only contribute indirectly to inter-object contracts.

I do not deny that public virtual functions can be problematic (especially
in large scale designs and/or large programming teams) but abstract
interfaces made up of public pure virtual functions are not problematic as
an idiom. Even if we restrict our discourse to public virtual functions in
ordinary classes the worst outcome of changing a public virtual function to
a non-virtual wrapper to allow for some invariant check and/or extra
pre/post logic is a binary compatibility (BC) break the severity of which is
proportional to the size of the project and/or team.

/Leigh