How can I extend/combine Interface classes containing pure virtual functions?

Question

I am using:

class ISearchFuncs :
    public Osp::Ui::IActionEventListener
    , public Osp::Ui::ITextEventListener
    , public Osp::Ui::IScrollPanelEventListener {
public:
    virtual result CloseOverlayKeyb() = 0;
    virtual result InitiateSearch() = 0;
};

but when I try and connect to those interfaces by passing a pointer to ISearchFuncs the callback/events fail to run. Whereas, connecting up using those interfaces in the class that actually implements them has no such problems. I could live with that but it would be better encapsulation if I could get to the bottom of this problem.

class Form1 :
    public Osp::Ui::Controls::Form
    , public ISearchFuncs
//  , public Osp::Ui::IActionEventListener// see below
//  , Osp::Ui::ITextEventListener//deleted due to ambiguity
    {

This is how it can be made to work:

    EditField *pSearchEditField = new EditField;
    TryCatch(E_SUCCESS == (r = pSearchEditField->Construct(Rectangle(labelRect.x + labelRect.width / 6, labelRect.y, 7 * labelRect.width / 12, 80)
                        , EDIT_FIELD_STYLE_NORMAL, INPUT_STYLE_OVERLAY, false, 100, GROUP_STYLE_MIDDLE)),, GetErrorMessage(r));
    pSearchEditField->AddTextEventListener(*this);
    pSearchEditField->AddScrollPanelEventListener(*this);
    pSearchEditField->AddActionEventListener(*this);
    TryCatch(E_SUCCESS == (r = pSearchEditField->SetOverlayKeypadCommandButton(COMMAND_BUTTON_POSITION_LEFT,
            L"Done", SearchPanel::ID_BUTTON_SEARCH_EDITFIELD_DONE)),, "");
    TryCatch(E_SUCCESS == (r = pSearchEditField->SetOverlayKeypadCommandButton(COMMAND_BUTTON_POSITION_RIGHT,
            L"Cancel", SearchPanel::ID_BUTTON_SEARCH_EDITFIELD_CANCEL)),, "");
    __pScrollPanel->AddControl(*pSearchEditField);

whereas passing to another class to do the equivalent fails to connect events at run time:

    __pSearchPanel->Construct(labelRect, this, __pScrollPanel);

calls:

result SearchPanel::Construct(const Rectangle &rect, ISearchFuncs *pListener, ScrollPanel *pScrollPare) {
    result r = E_SUCCESS;
    int x1 = rect.width / 6;
    int x2 = rect.width * 3 / 4;
    int y1 = rect.height / 3;

    EditField *pSearchEditField = new EditField;
    TryCatch(E_SUCCESS == (r = pSearchEditField->Construct(Rectangle(rect.x + x1, rect.y, x2 - x1, y1)
            , EDIT_FIELD_STYLE_NORMAL, INPUT_STYLE_OVERLAY, false, 100, GROUP_STYLE_MIDDLE)),, GetErrorMessage(r));
    pSearchEditField->AddTextEventListener(*pListener);
    pSearchEditField->AddScrollPanelEventListener(*pListener);
    pSearchEditField->AddActionEventListener(*pListener);
    TryCatch(E_SUCCESS == (r = pSearchEditField->SetOverlayKeypadCommandButton(COMMAND_BUTTON_POSITION_LEFT,
            L"Done", SearchPanel::ID_BUTTON_SEARCH_EDITFIELD_DONE)),, "");
    TryCatch(E_SUCCESS == (r = pSearchEditField->SetOverlayKeypadCommandButton(COMMAND_BUTTON_POSITION_RIGHT,
            L"Cancel", SearchPanel::ID_BUTTON_SEARCH_EDITFIELD_CANCEL)),, "");
    TryCatch(E_SUCCESS == (r = pScrollPare->AddControl(*pSearchEditField)),, "");

Sorry for the code duplication, but this is driving me crazy.

The idiom I am attempting to follow is part of the bada SDK's help.

You need to cut down on code and make it a little more framework agnostic then this and explain what does not work. There is no such thing as `connect events` in standard C++. Otherwise it is hard to answer. — pmr, Mar 06 '12 at 14:12
@pmr: Those `TryCatch` are there to detect errors. I'm sorry but this isn't quite standard C++ in that proper exception handling is absent. Better expressed in code than English, or so I thought. — John, Mar 06 '12 at 14:14
I've waded through the doc of whatever framework you seem to be using and showed you what I would do, but this isn't necessarily right in terms of the framework, only in terms of C++. — pmr, Mar 06 '12 at 14:17
Identifiers with `__` in them are reserved for the implementation, and therefore you're not allowed to use them. Other than that, try not to write Java in C++ and you'll be much happier. — Cat Plus Plus, Mar 06 '12 at 14:19
My, what a mess... What's the question, again? And where's your stripped-down testcase? It should be 5-6 lines long. — Lightness Races in Orbit, Mar 06 '12 at 14:19
Guessing from how they're used, those `TryCatch` more look like something that would better be named `ThrowingAssert`. Just from looking at the sheer number of namespaces, double-underscore variables, functions that I have to guess, and base classes involved, I'm getting dizzy. I think it would be easier for people to grasp if you gave a concise, readable example (with class A, B, and C, and not extra code). Plus, as a general thing, I'd try not to "overdesign" like this. Less can really sometimes be more. — Damon, Mar 06 '12 at 14:27
I use `__` when I want an extra layer of privacy on private members declared in the header. I know I should isolate the problem but I am being trying to be time -greedy/efficient. I'm sorry, I actually thought I had presented a pretty concise example, as concise as bada's constrained platform can accomodate. — John, Mar 06 '12 at 14:29
@CatPlusPlus: _"try not to write Java in C++ and you'll be much happier"_ -- funny you should say that. When J. Gosling advertised Java as "better than C++" back in 1995 and giving "does not have multiple inheritance" as one argument for that, my thinking was "that's just because you're too lazy to implement it". Now when I see code like this, I'm beginning to understand his reasoning... :-) — Damon, Mar 06 '12 at 14:32
Well, Java is too heavy for mobile phones, this is like Android native, but with a much bigger library and more language features. I actually read, in an old pdf, that bada forbade MI, unless the bases were 100% pure virtual, but I now see I've been using full MI all along in other places. — John, Mar 06 '12 at 14:35

score 0 · Answer 1 · answered Mar 06 '12 at 14:16

0

It seems that Osp::Ui::IActionEventListener, Osp::Ui::ITextEventListener, and Osp::Ui::IScrollPanelEventListener all derive from a common base. You need to use virtual inheritance to avoid common base classes.

class ISearchFuncs :
    public virtual Osp::Ui::IActionEventListener
    , public virtual Osp::Ui::ITextEventListener
    , public virtual Osp::Ui::IScrollPanelEventListener 
{
public:
  virtual result CloseOverlayKeyb() = 0;
  virtual result InitiateSearch() = 0;
};

answered Mar 06 '12 at 14:16

pmr

58,701
10
113
156

That's a good point, but as those base classes are themselves purely abstract interfaces with no concrete members (all pure virtual) there is no risk of ambiguious inheritence. Confirmed, no difference made. – John Mar 06 '12 at 14:21

John · Accepted Answer · 2015-10-17T09:43:54.110

-1

After being forced to accept the hack I outlined in my question I was getting some errors due to having overriden methods with stubs, IIRC.

I am 90% sure that that was not the reason for the anomoly that inspired my question but 100% sure it's more relevant than pmr's answer.

edited Oct 17 '15 at 09:43

answered Mar 18 '12 at 22:14

John

6,433
7
47
82

How can I extend/combine Interface classes containing pure virtual functions?

2 Answers2