dynamic_cast from base to another parent of derived class

Discussion in 'C++' started by Boris, Oct 3, 2006.

  1. Boris

    Boris Guest

    I'm porting code from Windows to UNIX and ran into a problem with
    dynamic_cast. Imagine a class hierarchy with three levels: class Level2
    derives from Level1 which derives from Base. If you look now at this code:

    Base *b = new Level2();
    Level1 *l1 = dynamic_cast<Level1*>(b);

    Should dynamic_cast return a valid pointer or 0? I wonder as Visual Studio
    2005 returns a valid pointer while g++ 3.4.6 returns 0. Both compilers work
    as expected when dynamic_cast<Level2*> is used but return different results
    with the code above. Who is right?

    The class hierarchy I'm talking about has some more classes per level.
    That's why sometimes a dynamic_cast to a level 1 class is preferred as you
    can then operate on various level 2 classes which are all derived from the
    same level 1 class. If you have to downcast to the actual level 2 class you
    end up writing the same code for several level 2 classes which I would like
    to avoid.

    Boris
    Boris, Oct 3, 2006
    #1
    1. Advertising

  2. Boris

    Pete Becker Guest

    Boris wrote:
    > I'm porting code from Windows to UNIX and ran into a problem with
    > dynamic_cast. Imagine a class hierarchy with three levels: class Level2
    > derives from Level1 which derives from Base. If you look now at this code:
    >
    > Base *b = new Level2();
    > Level1 *l1 = dynamic_cast<Level1*>(b);
    >
    > Should dynamic_cast return a valid pointer or 0? I wonder as Visual Studio
    > 2005 returns a valid pointer while g++ 3.4.6 returns 0. Both compilers work
    > as expected when dynamic_cast<Level2*> is used but return different results
    > with the code above. Who is right?
    >


    If Base has at least one virtual function (a prerequisite for applying
    dynamic_cast to a Base*) and that the various bases are public,
    dynamic_cast<Level1*>(b) does just what you would expect: it returns a
    pointer to the Level1 subobject in the original Level2 object.

    --

    -- Pete

    Author of "The Standard C++ Library Extensions: a Tutorial and
    Reference." For more information about this book, see
    www.petebecker.com/tr1book.
    Pete Becker, Oct 3, 2006
    #2
    1. Advertising

  3. Boris

    Boris Guest

    Pete Becker wrote:
    > Boris wrote:
    >> I'm porting code from Windows to UNIX and ran into a problem with
    >> dynamic_cast. Imagine a class hierarchy with three levels: class
    >> Level2 derives from Level1 which derives from Base. If you look now
    >> at this code: Base *b = new Level2();
    >> Level1 *l1 = dynamic_cast<Level1*>(b);
    >>
    >> Should dynamic_cast return a valid pointer or 0? I wonder as Visual
    >> Studio 2005 returns a valid pointer while g++ 3.4.6 returns 0. Both
    >> compilers work as expected when dynamic_cast<Level2*> is used but
    >> return different results with the code above. Who is right?
    >>

    >
    > If Base has at least one virtual function (a prerequisite for applying
    > dynamic_cast to a Base*) and that the various bases are public,
    > dynamic_cast<Level1*>(b) does just what you would expect: it returns a
    > pointer to the Level1 subobject in the original Level2 object.


    Thanks for your reply, Pete! When I create a small test program which works
    with the original class hierarchy there is no problem with dynamic_cast.

    The code I talk about looks like this:

    if (typeid(b) == typeid(level2))
    {
    const level1 *l1 = dynamic_cast<const level1*>(&b);
    }

    There is an explicit check (b is a reference to an instance of Base here)
    before dynamic_cast is used. The requirements you mentioned above are also
    met (Base has virtual functions and public inheritance is used everwhere).
    The compiler doesn't complain either when it sees this code. When I
    dynamic_cast to level2* I get a valid pointer, too. I play around some more
    to figure out what's going on. If you or anyone else has an idea what might
    affect dynamic_cast I would be happy to hear it!

    Boris
    Boris, Oct 3, 2006
    #3
  4. Boris

    mlimber Guest

    Boris wrote:
    > Pete Becker wrote:
    > > Boris wrote:
    > >> I'm porting code from Windows to UNIX and ran into a problem with
    > >> dynamic_cast. Imagine a class hierarchy with three levels: class
    > >> Level2 derives from Level1 which derives from Base. If you look now
    > >> at this code: Base *b = new Level2();
    > >> Level1 *l1 = dynamic_cast<Level1*>(b);
    > >>
    > >> Should dynamic_cast return a valid pointer or 0? I wonder as Visual
    > >> Studio 2005 returns a valid pointer while g++ 3.4.6 returns 0. Both
    > >> compilers work as expected when dynamic_cast<Level2*> is used but
    > >> return different results with the code above. Who is right?
    > >>

    > >
    > > If Base has at least one virtual function (a prerequisite for applying
    > > dynamic_cast to a Base*) and that the various bases are public,
    > > dynamic_cast<Level1*>(b) does just what you would expect: it returns a
    > > pointer to the Level1 subobject in the original Level2 object.

    >
    > Thanks for your reply, Pete! When I create a small test program which works
    > with the original class hierarchy there is no problem with dynamic_cast.
    >
    > The code I talk about looks like this:
    >
    > if (typeid(b) == typeid(level2))
    > {
    > const level1 *l1 = dynamic_cast<const level1*>(&b);
    > }
    >
    > There is an explicit check (b is a reference to an instance of Base here)
    > before dynamic_cast is used. The requirements you mentioned above are also
    > met (Base has virtual functions and public inheritance is used everwhere).
    > The compiler doesn't complain either when it sees this code. When I
    > dynamic_cast to level2* I get a valid pointer, too. I play around some more
    > to figure out what's going on. If you or anyone else has an idea what might
    > affect dynamic_cast I would be happy to hear it!
    >
    > Boris


    One syntactic simplification:

    if ( const level1 *const l1 = dynamic_cast<const level1*>(&b) )
    {
    // Use l1 here
    }
    else
    {
    // l1 is null here
    }

    Cheers! --M
    mlimber, Oct 3, 2006
    #4
  5. Boris

    Boris Guest

    Boris wrote:
    > [...] The code I talk about looks like this:
    >
    > if (typeid(b) == typeid(level2))
    > {
    > const level1 *l1 = dynamic_cast<const level1*>(&b);
    > }


    I changed the code for testing purposes and replaced dynamic_cast with
    reinterpret_cast - this works.

    I changed then the code to make it look like this:

    if (typeid(b) == typeid(level2))
    {
    const level2 *l2 = dynamic_cast<const level2*>(&b);
    const level1 *l1 = l2;
    }

    This works, too. Is there any other possible explanation than a compiler bug
    why a dynamic_cast<const level1*> should not work?

    Boris
    Boris, Oct 3, 2006
    #5
  6. Boris

    Boris Guest

    [crossposted to gnu.g++.help]

    Boris wrote:
    > Boris wrote:
    >> [...] The code I talk about looks like this:
    >>
    >> if (typeid(b) == typeid(level2))
    >> {
    >> const level1 *l1 = dynamic_cast<const level1*>(&b);
    >> }

    >
    > I changed the code for testing purposes and replaced dynamic_cast with
    > reinterpret_cast - this works.
    >
    > I changed then the code to make it look like this:
    >
    > if (typeid(b) == typeid(level2))
    > {
    > const level2 *l2 = dynamic_cast<const level2*>(&b);
    > const level1 *l1 = l2;
    > }
    >
    > This works, too. Is there any other possible explanation than a
    > compiler bug why a dynamic_cast<const level1*> should not work?


    It looks like a problem with g++. The code I was talking about is in a
    shared library. When I link the executable statically dynamic_cast works.
    When I use however the shared library dynamic_cast returns 0. Same code but
    different behavior due to linking.

    There is a section "dynamic_cast, throw, typeid don't work with shared
    libraries" at http://gcc.gnu.org/faq.html#dso. From what I understand though
    there is not much you can do? I'm using version 3.4.6 of g++ which is the
    latest of the 3.4.x series.

    The code construct as above with dynamic_cast is used in various project
    files. When building and linking the shared library some work, others don't.
    I don't know though on what it depends why some dynamic_casts don't work and
    falsely return 0. Is there anything I can do except replacing all
    dynamic_casts? Any g++ experts with ideas?

    Boris
    Boris, Oct 3, 2006
    #6
  7. Boris wrote:
    > [crossposted to gnu.g++.help]
    >
    > Boris wrote:
    > > Boris wrote:
    > >> [...] The code I talk about looks like this:
    > >>
    > >> if (typeid(b) == typeid(level2))
    > >> {
    > >> const level1 *l1 = dynamic_cast<const level1*>(&b);
    > >> }

    > >
    > > I changed the code for testing purposes and replaced dynamic_cast with
    > > reinterpret_cast - this works.
    > >
    > > I changed then the code to make it look like this:
    > >
    > > if (typeid(b) == typeid(level2))
    > > {
    > > const level2 *l2 = dynamic_cast<const level2*>(&b);
    > > const level1 *l1 = l2;
    > > }
    > >
    > > This works, too. Is there any other possible explanation than a
    > > compiler bug why a dynamic_cast<const level1*> should not work?


    Why not just:

    if(level2 const* l2 = dynamic_cast<level2 const*>(&b))
    {
    // no need comparing typeinfo's
    }

    ?

    >
    > It looks like a problem with g++. The code I was talking about is in a
    > shared library. When I link the executable statically dynamic_cast works.
    > When I use however the shared library dynamic_cast returns 0. Same code but
    > different behavior due to linking.
    >
    > There is a section "dynamic_cast, throw, typeid don't work with shared
    > libraries" at http://gcc.gnu.org/faq.html#dso.


    I wonder how you reached such a conclusion. Where on that page do they
    say it does not work?
    Maxim Yegorushkin, Oct 4, 2006
    #7
  8. Boris

    Boris Guest

    Maxim Yegorushkin wrote:
    > [...]
    >
    > Why not just:
    >
    > if(level2 const* l2 = dynamic_cast<level2 const*>(&b))
    > {
    > // no need comparing typeinfo's
    > }
    >
    > ?


    I want to cast to a level 1 class which is a parent of several level 2
    classes. Otherwise you are right - I could cast to the actual type directly.
    The real code looks more like this:

    if (typeid(b) == typeid(level2a) || typeid(b) == typeid(level2b) ||
    typeid(b) == typeid(level2c))
    {
    const level1 *l1 = dynamic_cast<const level1*>(&b);
    }

    Class level1 is the parent of all the level2 classes. I have to check for
    several types but don't need to write the same code then at least for all
    the level2 classes.

    >> It looks like a problem with g++. The code I was talking about is in
    >> a shared library. When I link the executable statically dynamic_cast
    >> works. When I use however the shared library dynamic_cast returns 0.
    >> Same code but different behavior due to linking.
    >>
    >> There is a section "dynamic_cast, throw, typeid don't work with
    >> shared libraries" at http://gcc.gnu.org/faq.html#dso.

    >
    > I wonder how you reached such a conclusion. Where on that page do they
    > say it does not work?


    The title is pretty clear I think: "dynamic_cast,throw, typeid don't work
    with shared libraries". :) They are talking about template instantiations,
    vague linkage, not an exhaustive list, namesspaces etc. This all doesn't
    sound like adding a linker switch fixes all your problems. This sounds like
    be ready for all kind of problems.

    Anyway if I can downcast to the actual type and then back to its parent with
    the following code (no compilation error, no runtime error) why should a
    dynamic_cast to the parent l1 not work?

    if (typeid(b) == typeid(level2))
    {
    const level2 *l2 = dynamic_cast<const level2*>(&b);
    const level1 *l1 = l2;
    }

    Boris
    Boris, Oct 4, 2006
    #8
  9. Boris

    Boris Guest

    Boris wrote:
    >> I wonder how you reached such a conclusion. Where on that page do
    >> they say it does not work?

    >
    > The title is pretty clear I think: "dynamic_cast,throw, typeid don't
    > work with shared libraries". :) They are talking about template
    > instantiations, vague linkage, not an exhaustive list, namesspaces
    > etc. This all doesn't sound like adding a linker switch fixes all
    > your problems. This sounds like be ready for all kind of problems.
    >
    > Anyway if I can downcast to the actual type and then back to its
    > parent with the following code (no compilation error, no runtime
    > error) why should a dynamic_cast to the parent l1 not work?
    >
    > if (typeid(b) == typeid(level2))
    > {
    > const level2 *l2 = dynamic_cast<const level2*>(&b);
    > const level1 *l1 = l2;
    > }


    I changed the code to use boost::polymorphic_downcast instead of
    dynamic_cast:

    if (typeid(b) == typeid(level2))
    {
    const level1 *l1 = boost::polymorphic_downcast<const level1*>(&b);
    }

    With NDEBUG defined boost::polymorphic_downcast uses only static_cast - this
    works. Without NDEBUG defined dynamic_cast is used which doesn't work (as an
    assert fails).

    Summary: Everything works with reinterpret_cast and static_cast or
    dynamic_cast when statically linked. It fails when dynamic_cast is used in a
    shared library. It can not be reproduced with a small test case as
    everything works then. The project I port to UNIX uses dynamic_casts in
    different files where some do work. There must be some more conditions which
    make g++ produce wrong code and which make some dynamic_casts fail
    constantly.

    Boris
    Boris, Oct 4, 2006
    #9
  10. Boris wrote:
    > Maxim Yegorushkin wrote:
    > > [...]
    > >
    > > Why not just:
    > >
    > > if(level2 const* l2 = dynamic_cast<level2 const*>(&b))
    > > {
    > > // no need comparing typeinfo's
    > > }
    > >
    > > ?

    >
    > I want to cast to a level 1 class which is a parent of several level 2
    > classes. Otherwise you are right - I could cast to the actual type directly.
    > The real code looks more like this:
    >
    > if (typeid(b) == typeid(level2a) || typeid(b) == typeid(level2b) ||
    > typeid(b) == typeid(level2c))
    > {
    > const level1 *l1 = dynamic_cast<const level1*>(&b);
    > }
    >
    > Class level1 is the parent of all the level2 classes. I have to check for
    > several types but don't need to write the same code then at least for all
    > the level2 classes.


    I would redesign my hierarchy so, that dynamic_cast would be enough.

    > >> It looks like a problem with g++. The code I was talking about is in
    > >> a shared library. When I link the executable statically dynamic_cast
    > >> works. When I use however the shared library dynamic_cast returns 0.
    > >> Same code but different behavior due to linking.
    > >>
    > >> There is a section "dynamic_cast, throw, typeid don't work with
    > >> shared libraries" at http://gcc.gnu.org/faq.html#dso.

    > >
    > > I wonder how you reached such a conclusion. Where on that page do they
    > > say it does not work?

    >
    > The title is pretty clear I think: "dynamic_cast,throw, typeid don't work
    > with shared libraries". :) They are talking about template instantiations,
    > vague linkage, not an exhaustive list, namesspaces etc. This all doesn't
    > sound like adding a linker switch fixes all your problems. This sounds like
    > be ready for all kind of problems.


    This is a title of a frequently asked question. The answer is given fow
    to make it work. If you can follow the first advise, which is

    <q>
    For a program which is linked against a shared library, no additional
    precautions are needed
    </q>

    then no other action is required.

    > Anyway if I can downcast to the actual type and then back to its parent with
    > the following code (no compilation error, no runtime error) why should a
    > dynamic_cast to the parent l1 not work?
    >
    > if (typeid(b) == typeid(level2))
    > {
    > const level2 *l2 = dynamic_cast<const level2*>(&b);
    > const level1 *l1 = l2;
    > }


    You could find more help if you posted simplified complete code that
    reproduces what you are observing.

    It might be that you derive privately from your base (class A : B {};)
    .. dynamic_cast in this case does not work, reinterpret_cast does work
    if your base class is first in the list of the base classes.
    Maxim Yegorushkin, Oct 4, 2006
    #10
  11. Boris

    Boris Guest

    Maxim Yegorushkin wrote:
    > [...]
    >> if (typeid(b) == typeid(level2a) || typeid(b) == typeid(level2b) ||
    >> typeid(b) == typeid(level2c))
    >> {
    >> const level1 *l1 = dynamic_cast<const level1*>(&b);
    >> }
    >>
    >> Class level1 is the parent of all the level2 classes. I have to
    >> check for several types but don't need to write the same code then
    >> at least for all the level2 classes.

    >
    > I would redesign my hierarchy so, that dynamic_cast would be enough.


    I'm open for any suggestions but don't know if I can simplify it. If you
    have a function like this:

    base *foo();

    which returns a level2 class but you know that level2 classes are grouped
    then you try to find their parent classes (level1) if in the current
    function you don't need to work with level2 classes (of course there are
    other functions which need to; thus I can't get rid of any level).

    It's not an option either to change the return type of foo() as there are
    quite a lot of functions which all work with base classes. It must be
    possible to nest them like in bar(foo()). No matter what foo() returns bar()
    must be able to work with. And no matter what function is nested it must
    return base* to bar().

    > [...]
    > This is a title of a frequently asked question. The answer is given
    > fow to make it work. If you can follow the first advise, which is
    >
    > <q>
    > For a program which is linked against a shared library, no additional
    > precautions are needed
    > </q>
    >
    > then no other action is required.


    That's what I have and how I ran into this problem: It's a console program
    linked to a shared library.

    >> Anyway if I can downcast to the actual type and then back to its
    >> parent with the following code (no compilation error, no runtime
    >> error) why should a dynamic_cast to the parent l1 not work?
    >>
    >> if (typeid(b) == typeid(level2))
    >> {
    >> const level2 *l2 = dynamic_cast<const level2*>(&b);
    >> const level1 *l1 = l2;
    >> }

    >
    > You could find more help if you posted simplified complete code that
    > reproduces what you are observing.


    I had created a small test case but unfortunately it worked. The project I
    port is too large - it would take some time to track this down which I don't
    have currently.

    > It might be that you derive privately from your base (class A : B {};)
    > . dynamic_cast in this case does not work, reinterpret_cast does work
    > if your base class is first in the list of the base classes.


    But why does it all work then when I link statically?

    Boris
    Boris, Oct 4, 2006
    #11
  12. Boris wrote:

    []

    > I had created a small test case but unfortunately it worked. The project I
    > port is too large - it would take some time to track this down which I don't
    > have currently.


    So, it's not a gcc problem, is it?
    Maxim Yegorushkin, Oct 5, 2006
    #12
  13. Boris

    Fred Zwarts Guest

    "Boris" <> wrote in message news:...
    > [crossposted to gnu.g++.help]
    >
    > Boris wrote:
    >> Boris wrote:
    >>> [...] The code I talk about looks like this:
    >>>
    >>> if (typeid(b) == typeid(level2))
    >>> {
    >>> const level1 *l1 = dynamic_cast<const level1*>(&b);
    >>> }

    >>
    >> I changed the code for testing purposes and replaced dynamic_cast with
    >> reinterpret_cast - this works.
    >>
    >> I changed then the code to make it look like this:
    >>
    >> if (typeid(b) == typeid(level2))
    >> {
    >> const level2 *l2 = dynamic_cast<const level2*>(&b);
    >> const level1 *l1 = l2;
    >> }
    >>
    >> This works, too. Is there any other possible explanation than a
    >> compiler bug why a dynamic_cast<const level1*> should not work?

    >
    > It looks like a problem with g++. The code I was talking about is in a
    > shared library. When I link the executable statically dynamic_cast works.
    > When I use however the shared library dynamic_cast returns 0. Same code but
    > different behavior due to linking.
    >
    > There is a section "dynamic_cast, throw, typeid don't work with shared
    > libraries" at http://gcc.gnu.org/faq.html#dso. From what I understand though
    > there is not much you can do? I'm using version 3.4.6 of g++ which is the
    > latest of the 3.4.x series.
    >
    > The code construct as above with dynamic_cast is used in various project
    > files. When building and linking the shared library some work, others don't.
    > I don't know though on what it depends why some dynamic_casts don't work and
    > falsely return 0. Is there anything I can do except replacing all
    > dynamic_casts? Any g++ experts with ideas?
    >
    > Boris


    Interesting. A few years ago I had a similar problem on an OpenVMS system.
    The dynamic_cast did not work properly in a function that was called from
    another function in a shareable image (which is similar to a dynamic library
    under Linux). An example was code running in a separate thread. Since the
    pthread library was in a shareable image, functions running in another thread
    were called from functions in a shareable image.
    The OpenVMS engineers brought out a patch for the compiler and the run-time
    library quickly.

    The similarity of these problems strikes me, as the compiler environments are
    from very different teams. Apparently there is something in dynamic_cast
    that makes it difficult to work from pre-linked parts of a program.

    Fred.Zwarts.
    Fred Zwarts, Oct 5, 2006
    #13
  14. Boris

    Boris Guest

    Maxim Yegorushkin wrote:
    > Boris wrote:
    >
    > []
    >
    >> I had created a small test case but unfortunately it worked. The
    >> project I port is too large - it would take some time to track this
    >> down which I don't have currently.

    >
    > So, it's not a gcc problem, is it?


    Just because a small test case works doesn't mean that the compiler is
    bug-free. There must be some side conditions which make the bug appear. And
    I don't have the time unfortunately to find the exact conditions under which
    the bug can be reproduced. Again I repeat that the same souce code linked
    statically works perfectly. Thus it could be a problem with the linker,
    too - I don't know.

    Boris
    Boris, Oct 5, 2006
    #14
  15. Boris

    Boris Guest

    Fred Zwarts wrote:
    > [...]
    > Interesting. A few years ago I had a similar problem on an OpenVMS
    > system.
    > The dynamic_cast did not work properly in a function that was called
    > from
    > another function in a shareable image (which is similar to a dynamic
    > library
    > under Linux). An example was code running in a separate thread. Since
    > the
    > pthread library was in a shareable image, functions running in
    > another thread
    > were called from functions in a shareable image.
    > The OpenVMS engineers brought out a patch for the compiler and the
    > run-time
    > library quickly.
    >
    > The similarity of these problems strikes me, as the compiler
    > environments are
    > from very different teams. Apparently there is something in
    > dynamic_cast
    > that makes it difficult to work from pre-linked parts of a program.


    Could you easily reproduce the problem with a small test program or was it
    something where some other conditions had to be met? And did you ever try to
    link everything statically just to see if the problem disappeared?

    Boris
    Boris, Oct 5, 2006
    #15
  16. Boris wrote:
    > Maxim Yegorushkin wrote:
    > > Boris wrote:
    > >
    > > []
    > >
    > >> I had created a small test case but unfortunately it worked. The
    > >> project I port is too large - it would take some time to track this
    > >> down which I don't have currently.

    > >
    > > So, it's not a gcc problem, is it?

    >
    > Just because a small test case works doesn't mean that the compiler is
    > bug-free.


    True.

    You have to come up with a test case to prove that the compiler is
    faulty rather than your code.
    Maxim Yegorushkin, Oct 5, 2006
    #16
  17. Boris

    iftekhar Guest

    just curious. You never mentioned the linker options. did you use the
    -rdynamic option for linking the executable?
    I had a similar problem a year back. which was solved by using
    -rdynamic, if i can remember properly.

    Iftekhar
    iftekhar, Oct 5, 2006
    #17
  18. Boris

    Fred Zwarts Guest

    "Boris" <> wrote in message news:...
    > Fred Zwarts wrote:
    >> [...]
    >> Interesting. A few years ago I had a similar problem on an OpenVMS
    >> system.
    >> The dynamic_cast did not work properly in a function that was called
    >> from
    >> another function in a shareable image (which is similar to a dynamic
    >> library
    >> under Linux). An example was code running in a separate thread. Since
    >> the
    >> pthread library was in a shareable image, functions running in
    >> another thread
    >> were called from functions in a shareable image.
    >> The OpenVMS engineers brought out a patch for the compiler and the
    >> run-time
    >> library quickly.
    >>
    >> The similarity of these problems strikes me, as the compiler
    >> environments are
    >> from very different teams. Apparently there is something in
    >> dynamic_cast
    >> that makes it difficult to work from pre-linked parts of a program.

    >
    > Could you easily reproduce the problem with a small test program or was it
    > something where some other conditions had to be met? And did you ever try to
    > link everything statically just to see if the problem disappeared?


    It could not be reproduced in a small program, because it only occurred in
    functions called from the shareable image. So, the test program needed
    to use some library functions which in turn called the function in which
    dynamic_cast was used, which is not easy to do in a small test program.
    I encountered the bug when using the pthreads library, exactly a case where
    functions in a program (the start functions of the threads) are called from the
    library.
    At the time I encountered the bug, it was already known to the OpenVMS
    compiler group, so I did not have to prove it with a small program, but they
    recognized the case and sent me the patch.
    So, the conditions under which the bug was exposed were not determined by me,
    but I read them in the patch description. It gave an excellent explanation why
    dynamic_cast worked in some cases, but failed in others.

    Fred.Zwarts.
    Fred Zwarts, Oct 9, 2006
    #18
  19. Boris

    Boris Guest

    iftekhar wrote:
    > just curious. You never mentioned the linker options. did you use the
    > -rdynamic option for linking the executable?
    > I had a similar problem a year back. which was solved by using
    > -rdynamic, if i can remember properly.


    I rebuilt everywhing with the default compiler and linker switches. No -f
    options or anything else which might affect compiling and linking. I tried
    to build the executable with and without -rdynamic (which I never heard of
    before and couldn't find in the local man files either). It all didn't help.
    The only thing which works is linking statically (which doesn't help me
    really as I need to ship a library).

    Boris
    Boris, Oct 10, 2006
    #19
  20. Boris

    F.J.K. Guest

    Boris wrote:
    > I had created a small test case but unfortunately it worked. The project I
    > port is too large - it would take some time to track this down which I don't
    > have currently.


    Is the bug present in GCC 4.x?
    in mainline?

    Is there any reason you can't just do? (Real question, not just
    rhetorical :)

    #ifdef __GNUC__ && __GNU__<4
    #define dynamic_cast static_cast
    #endif

    >From what I take from the discussion so far, you have assured your code

    is semantically correct (See Pete Beckers guru-posting). At this point,
    I'd just truy to work around and go on with life.
    F.J.K., Oct 10, 2006
    #20
    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. qazmlp
    Replies:
    1
    Views:
    551
    qazmlp
    Apr 10, 2005
  2. Replies:
    4
    Views:
    387
    Alf P. Steinbach
    May 23, 2007
  3. Replies:
    1
    Views:
    378
    myork
    May 23, 2007
  4. Replies:
    1
    Views:
    369
    Victor Bazarov
    May 23, 2007
  5. Replies:
    2
    Views:
    685
Loading...

Share This Page