inline virtual functions

Discussion in 'C++' started by siddhu, Jul 3, 2007.

  1. siddhu

    siddhu Guest

    Dear experts,

    A virtual function has to have an address. So if an inline virtual
    function is actually inlined then in that case what does address of
    this function signify? How does compiler know at compile time about
    the actual object a pointer points to so that it can paste the correct
    inline function in the place of function call if the function is
    getting inlined?
    siddhu, Jul 3, 2007
    #1
    1. Advertising

  2. siddhu wrote:
    > Dear experts,
    >
    > A virtual function has to have an address.


    Really? Why?

    > So if an inline virtual
    > function is actually inlined then in that case what does address of
    > this function signify?


    If a function is inlined, the compiler is still free to create a body
    of it _if_ it needs to take the address.

    > How does compiler know at compile time about
    > the actual object a pointer points to so that it can paste the correct
    > inline function in the place of function call if the function is
    > getting inlined?


    It doesn't. The whole point of polymorphism is that the type of the
    actual object is unknown until the run time.

    V
    --
    Please remove capital 'A's when replying by e-mail
    I do not respond to top-posted replies, please don't ask
    Victor Bazarov, Jul 3, 2007
    #2
    1. Advertising

  3. siddhu

    siddhu Guest

    On Jul 3, 10:56 am, "Victor Bazarov" <> wrote:
    > siddhu wrote:
    > > Dear experts,

    >
    > > A virtual function has to have an address.

    >
    > Really? Why?
    >
    > > So if an inline virtual
    > > function is actually inlined then in that case what does address of
    > > this function signify?

    >
    > If a function is inlined, the compiler is still free to create a body
    > of it _if_ it needs to take the address.
    >
    > > How does compiler know at compile time about
    > > the actual object a pointer points to so that it can paste the correct
    > > inline function in the place of function call if the function is
    > > getting inlined?

    >
    > It doesn't. The whole point of polymorphism is that the type of the
    > actual object is unknown until the run time.

    Without knowing the exact type how can a compiler expand the function
    at function call?
    >
    > V
    > --
    > Please remove capital 'A's when replying by e-mail
    > I do not respond to top-posted replies, please don't ask
    siddhu, Jul 3, 2007
    #3
  4. siddhu wrote:
    >>>How does compiler know at compile time about
    >>>the actual object a pointer points to so that it can paste the correct
    >>>inline function in the place of function call if the function is
    >>>getting inlined?


    On Jul 3, 10:56 am, "Victor Bazarov" <> wrote:
    >>It doesn't. The whole point of polymorphism is that the type of the
    >>actual object is unknown until the run time.


    siddhu wrote:
    > Without knowing the exact type how can a compiler expand the function
    > at function call?


    If the compiler doesn't know which function will be used, it cannot expand it.
    As the inline keyword doesn't _require_ the compiler to expand functions (the
    inline keyword is only a _suggestion_ that the method should be expanded), the
    compiler is free to simply call the function.

    BTW, inline and virtual don't go together. As I recall, compilers may even issue
    a warning if you try to inline virtual methods.

    Regards,
    Stuart
    Stuart Redmann, Jul 3, 2007
    #4
  5. * Stuart Redmann:
    >
    > BTW, inline and virtual don't go together. As I recall, compilers may
    > even issue a warning if you try to inline virtual methods.


    'inline' and 'virtual' are very compatible. A compiler that issues any
    diagnostic on the combination is trash, probably pre-standard. Use
    decent compilers.

    --
    A: Because it messes up the order in which people normally read text.
    Q: Why is it such a bad thing?
    A: Top-posting.
    Q: What is the most annoying thing on usenet and in e-mail?
    Alf P. Steinbach, Jul 3, 2007
    #5
  6. siddhu

    gpuchtel Guest

    On Jul 3, 10:44 am, siddhu <> wrote:
    > Dear experts,
    >
    > A virtual function has to have an address. So if an inline virtual
    > function is actually inlined then in that case what does address of
    > this function signify? How does compiler know at compile time about
    > the actual object a pointer points to so that it can paste the correct
    > inline function in the place of function call if the function is
    > getting inlined?


    http://www.devx.com/tips/Tip/13815
    gpuchtel, Jul 4, 2007
    #6
  7. siddhu

    James Kanze Guest

    On Jul 3, 4:56 pm, "Victor Bazarov" <> wrote:
    > siddhu wrote:
    > > Dear experts,


    > > A virtual function has to have an address.


    > Really? Why?


    For the same reason every function has to have an address. You
    can take its address with the & operator.

    Beyond that, of course, the compiler might want the address for
    some internal house keeping. In the case of a virtual function,
    this is in fact very likely. (But of course, that's the
    compiler's problem, not yours.)

    Note that the standard guarantees that all instances of the
    address of the function compare equal, even when they are taken
    in different compilation units.

    > > So if an inline virtual
    > > function is actually inlined then in that case what does address of
    > > this function signify?


    > If a function is inlined, the compiler is still free to create a body
    > of it _if_ it needs to take the address.


    > > How does compiler know at compile time about
    > > the actual object a pointer points to so that it can paste the correct
    > > inline function in the place of function call if the function is
    > > getting inlined?


    > It doesn't. The whole point of polymorphism is that the type of the
    > actual object is unknown until the run time.


    And of course, just because you say "inline" doesn't mean that
    the compiler has to generate the function inline (and vice
    versa). In the case of a virtual function called through a
    pointer or a reference, there's a very, very good chance that
    the compiler won't inline it (although I've heard of some that
    do, in some special cases).

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jul 4, 2007
    #7
  8. siddhu

    James Kanze Guest

    On Jul 3, 11:16 pm, "Alf P. Steinbach" <> wrote:
    > * Stuart Redmann:


    > > BTW, inline and virtual don't go together. As I recall, compilers may
    > > even issue a warning if you try to inline virtual methods.


    > 'inline' and 'virtual' are very compatible. A compiler that issues any
    > diagnostic on the combination is trash, probably pre-standard. Use
    > decent compilers.


    I'll go even further, and say that there are two cases where I
    regularly inline virtual functions, and I've never seen a
    warning about it.

    The first is the virtual destructor of an "interface", e.g.:

    class Interface
    {
    public:
    virtual ~Interface() {}
    // Only pure virtual functions...
    } ;

    Since the destructor is the only function which has an
    "implementation", it seems a shame to have to create a source
    file just for it. (And of course, the destructor never will be
    called virtually, since instances of the class can't exist.)

    The second is when the concrete instance of an interface is
    created by a factory function, with a different function for
    each type. In such cases, the simplest solution is to define
    the derived class in the factory function, and C++ requires all
    functions in a local class to be defined in the class
    definition, which means that they are "inline"; in this case, of
    course, the function will never, ever actually be inlined.

    --
    James Kanze (GABI Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jul 4, 2007
    #8
  9. siddhu

    gpuchtel Guest

    On Jul 4, 4:38 am, James Kanze <> wrote:

    > The first is the virtual destructor of an "interface", e.g.:
    >
    > class Interface
    > {
    > public:
    > virtual ~Interface() {}
    > // Only pure virtual functions...
    > } ;
    >
    > Since the destructor is the only function which has an
    > "implementation", it seems a shame to have to create a source
    > file just for it. (And of course, the destructor never will be
    > called virtually, since instances of the class can't exist.)
    >


    Actually, an instance of the 'Interface' class does exist, it's just
    that it cannot be instantiated explicitly; however, the compiler will
    create it. Furthermore, the destructor of the abstract (Interface)
    class 'is' called, which is why an implementation was needed in first
    place. For example:

    class Interface {
    public:
    virtual ~Interface() = 0 {
    std::cout << "virtual ~Interface()" << std::endl;
    }
    };

    class Concrete : public Interface {
    public:
    ~Concrete() {
    std::cout << "virtual ~Concrete()" << std::endl;
    }
    };

    void SomeFunction()
    {
    Concrete* concrete = new Concrete();
    delete concrete;
    }

    ....renders the following output:

    "virtual ~Concrete()"
    "virtual ~Interface()"
    gpuchtel, Jul 4, 2007
    #9
  10. siddhu

    James Kanze Guest

    gpuchtel wrote:
    > On Jul 4, 4:38 am, James Kanze <> wrote:


    > > The first is the virtual destructor of an "interface", e.g.:


    > > class Interface
    > > {
    > > public:
    > > virtual ~Interface() {}
    > > // Only pure virtual functions...
    > > } ;


    > > Since the destructor is the only function which has an
    > > "implementation", it seems a shame to have to create a source
    > > file just for it. (And of course, the destructor never will be
    > > called virtually, since instances of the class can't exist.)


    > Actually, an instance of the 'Interface' class does exist,


    When I speak of an instance, I'm using the usual meaning: an
    object with type Interface. Obviously, the derived classes will
    have a sub-object of type Interface, and during construction and
    destruction, there will be a moment when the dynamic type of the
    object is Interface (but with the above destructor, and the
    compiler provided constructors, there's no way a program can
    actually see this) but there can be no fully constructed object
    of type Interface.

    > it's just that it cannot be instantiated explicitly;


    Or implicitly.

    > however, the compiler will create it.


    When?

    > Furthermore, the destructor of the abstract (Interface)
    > class 'is' called,


    But it's never called "virtually". Whenever the compiler calls
    it, it knows exactly that destructor is being called. (That's
    why you can declare it pure virtual.) At least read what you
    are responding to.

    --
    James Kanze (Gabi Software) email:
    Conseils en informatique orientée objet/
    Beratung in objektorientierter Datenverarbeitung
    9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
    James Kanze, Jul 4, 2007
    #10
    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. Dave Townsend

    inline virtual functions.

    Dave Townsend, May 21, 2004, in forum: C++
    Replies:
    15
    Views:
    644
    Alf P. Steinbach
    May 22, 2004
  2. Replies:
    3
    Views:
    451
  3. Daniel Vallstrom
    Replies:
    2
    Views:
    1,832
    Kevin Bracey
    Nov 21, 2003
  4. John Goche
    Replies:
    10
    Views:
    725
    Marcus Kwok
    Dec 8, 2006
  5. Rahul
    Replies:
    3
    Views:
    445
    James Kanze
    Feb 28, 2008
Loading...

Share This Page