How to debug method resolution problem?

Discussion in 'C++' started by jburgy, Feb 10, 2010.

  1. jburgy

    jburgy Guest

    Good morning,

    I'm faced with a tricky problem and the C++ gurus I work with couldn't
    help. I apologize for not posting actual code, I simply can't for IP
    reasons. I have the following inheritance diagram:

    class A
    {
    virtual A *foo( ... ) const;
    };

    template< class T >
    class B : public A
    {
    virtual A *foo( ... ) const;
    };

    template< class T >
    inline A *B::foo( ... ) const
    {
    throw( "B's template specializations must override foo!" );
    return NULL;
    }

    I have specializations of B for 8 distinct classes T. I have
    explicitly overridden foo for all of them (using a preprocessor macro)
    but am getting mixed results. Some cases still end up throwing the
    error message shown above (3 when building with MSVC and 5 with g++
    although I have no compile errors in either case). Is this something
    that's not supported by the standard and I shouldn't expect it to work
    reliably? How do I go about debugging it since the problem occurs at
    compile-time.

    Thanks,
     
    jburgy, Feb 10, 2010
    #1
    1. Advertising

  2. On 10 fév, 15:02, jburgy <> wrote:
    > Good morning,
    >
    > I'm faced with a tricky problem and the C++ gurus I work with couldn't
    > help.  I apologize for not posting actual code, I simply can't for IP
    > reasons.  I have the following inheritance diagram:
    >
    > class A
    > {
    >     virtual A *foo( ... ) const;
    >
    > };
    >
    > template< class T >
    > class B : public A
    > {
    >     virtual A *foo( ... ) const;
    >
    > };
    >
    > template< class T >
    > inline A *B::foo( ... ) const
    > {
    >     throw( "B's template specializations must override foo!" );
    >     return NULL;
    >
    > }
    >
    > I have specializations of B for 8 distinct classes T.  I have
    > explicitly overridden foo for all of them (using a preprocessor macro)
    > but am getting mixed results.  Some cases still end up throwing the
    > error message shown above (3 when building with MSVC and 5 with g++
    > although I have no compile errors in either case).  Is this something
    > that's not supported by the standard and I shouldn't expect it to work
    > reliably?


    Yes. It is a valid specialisation. But definition should use B<T> :
    template< class T >
    A *B<T>::foo( ... ) const
    {
    throw( "B's template specializations must override foo!" );
    return NULL;
    }

    >  How do I go about debugging it since the problem occurs at
    > compile-time.


    Without the exact message, I can't say.
    But instead of using a run time check you could simply make it pure
    virtual:

    template< class T >
    class B : public A
    {
    virtual A *foo( ... )const = 0;
    };

    Then, any class inheriting from B<T> must implement foo to be
    instantiatable.
    Note: from §10.4/5 of the standard: [...] a pure virtual function may
    override a virtual function which is not pure.

    --
    Michael
     
    Michael Doubez, Feb 10, 2010
    #2
    1. Advertising

  3. jburgy wrote:
    > Good morning,
    >
    > I'm faced with a tricky problem and the C++ gurus I work with couldn't
    > help. I apologize for not posting actual code, I simply can't for IP
    > reasons. I have the following inheritance diagram:


    IP reasons?
    You should post minimal compilable example, because nothing is wrong in
    the code you posted

    >
    > class A
    > {
    > virtual A *foo( ... ) const;
    > };
    >
    > template< class T >
    > class B : public A
    > {
    > virtual A *foo( ... ) const;
    > };
    >
    > template< class T >
    > inline A *B::foo( ... ) const


    This should be:
    inline A *B< T >::foo( ... ) const

    > {
    > throw( "B's template specializations must override foo!" );
    > return NULL;
    > }
    >
     
    Vladimir Jovic, Feb 10, 2010
    #3
  4. jburgy

    jburgy Guest

    On Feb 10, 10:19 am, Pete Becker <> wrote:
    > Yu Han wrote:
    > > May be you could declare A::foo as pure virtual. But I guess you do have
    > > something useful in A::foo, so you have to do something different.

    >
    > Not necessarily. Declaring a function pure virtual does not mean that
    > you can't implement it.
    >
    > --
    >    Pete
    > Roundhouse Consulting, Ltd. (www.versatilecoding.com) Author of
    > "The Standard C++ Library Extensions: a Tutorial and Reference"
    > (www.petebecker.com/tr1book)


    Thanks for all the help. Let me try to address your points:

    * I can't add a pure virtual B<T>::foo, too many classes derive from
    it and rely on the default implementation
    * Once again, sorry for not posting a minimal compilable sample, that
    would take very long to reproduce the relevant setup (3 separate
    projects compiled independently)
    * There is no error message, everything build and runs, I'm just
    getting the wrong implementation

    I have made accidental progress by remove the inline keyword and now
    get a fatal error LNK1169: one or more multiply defined symbols
    founds. Those multiply defined symbols are precisely the
    specializations that aren't working. Inline somehow made the compiler
    feel it was ok to skip them I guess.
     
    jburgy, Feb 10, 2010
    #4
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Andrew FPGA
    Replies:
    0
    Views:
    979
    Andrew FPGA
    Sep 26, 2005
  2. Frank

    dynamic method resolution

    Frank, Apr 23, 2004, in forum: Java
    Replies:
    1
    Views:
    547
    chris
    Apr 23, 2004
  3. Replies:
    8
    Views:
    6,894
    Michele Simionato
    Jun 27, 2006
  4. ddtl
    Replies:
    4
    Views:
    386
    Bruno Desthuilliers
    Sep 10, 2006
  5. MP
    Replies:
    4
    Views:
    769
Loading...

Share This Page