questions from strategies and tactics C++

Discussion in 'C++' started by puzzlecracker, Jul 16, 2005.

  1. I have recently decided to go over the questions in the classical book
    by Murray and few of them admittedly befuddled me.

    page 140:

    1. Under what circumstances should a smart compiler be able to use
    static binding for a virtual function call? (is it when base class
    pointer refers to base class object?)

    2.Does it ever make sense to declare an inline virtual function? Under
    what circumstances (is in it a contradiction unless it relates to my
    answer to above question)?

    3. Under what circumstances might be very costly to make a large
    function virtual?
     
    puzzlecracker, Jul 16, 2005
    #1
    1. Advertising

  2. * puzzlecracker:
    >
    > I have recently decided to go over the questions in the classical book
    > by Murray and few of them admittedly befuddled me.
    >
    > page 140:
    >
    > 1. Under what circumstances should a smart compiler be able to use
    > static binding for a virtual function call? (is it when base class
    > pointer refers to base class object?)


    When the compiler can determine which function will be executed. A dumb
    compiler can do that for

    A o;
    o.f();

    A smart compiler can do it also for a range of other cases.

    The time spent in analysis go quickly up, however.


    > 2.Does it ever make sense to declare an inline virtual function?


    Yes.


    > Under
    > what circumstances (is in it a contradiction unless it relates to my
    > answer to above question)?


    Any circumstances, it's mostly a personal preference. Circumstances
    where it isn't a good idea: when the project/firm's coding guidelines
    say otherwise. No technical reasons.


    > 3. Under what circumstances might be very costly to make a large
    > function virtual?


    The direct (relative) cost of virtualness has nothing to do with the size of
    a function but with the execution time and frequency of calls. So this one
    has me befuddled, too. I'm guessing that the authors earlier have given
    some inane advice like "prefentially don't make small functions virtual",
    and here are trying to make the earlier advice seem sort of rational.

    --
    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 16, 2005
    #2
    1. Advertising

  3. puzzlecracker

    Alipha Guest

    #include <iostream>

    class Base {
    public:
    Base(const Base &) { std::cout << "copy is made" << std::endl; }
    virtual ~Base() {}
    virtual void foo() { std::cout << "Base" << std::endl; }
    };

    class Derived : public Base {
    public:
    virtual void foo() { std::cout << "Derived" << std::endl; }
    };

    void f(Base *p, Base obj, Base &ref) {
    p->foo();
    obj.foo();
    ref.foo();
    }

    int main() {
    Derived d;
    f(&d, d, d);
    return 0;
    }

    f accepts a pointer, an object, and a reference to Base. However, one
    of these guarentees that Base::foo is called eventhough d, a Derived
    object, is passed, and so the compiler can optimize it. perhaps this
    example program will help you answer things correctly.
     
    Alipha, Jul 16, 2005
    #3
  4. > 2.Does it ever make sense to declare an inline virtual function?
    >Yes.



    I don't think a compiler can inline a virtual function (unless it is an
    object -not a pointer to- or a pointer to a class instance of the same
    class (A a=new A; a.foo();) ), so declaring it as inline doesn't make
    sense from efficiency point of view (much less from aesthetic one) -
    the function simply won't be inlined. aka. static vs. dynamic
    binding... .

    On the same note: can you have or inline a virtual template *member*
    function?
     
    puzzlecracker, Jul 16, 2005
    #4
  5. * puzzlecracker:
    > [responding to my posting but referring to another posting, and not
    > stating who he's quoting etc. -- fixed:]
    > * Alf P. Steinbach:
    > > * puzzlecracker:
    > > >
    > > > Does it ever make sense to declare an inline virtual function?

    > >
    > > Yes.


    Your quoting and article references are inconsistent; please sharpen up.


    > I don't think a compiler can inline a virtual function (unless it is an
    > object -not a pointer to- or a pointer to a class instance of the same
    > class (A a=new A; a.foo();) ), so declaring it as inline doesn't make
    > sense from efficiency point of view (much less from aesthetic one) -
    > the function simply won't be inlined. aka. static vs. dynamic
    > binding... .


    Sorry, that's incorrect: a compiler can and will inline a virtual function
    in the same way as other functions, when it knows which function will be
    executed.

    Also note that the keyword 'inline', or placing a member function definition
    inside the class definition, has very little to do with execution efficiency
    or machine-code level inlining.

    You should not rely on 'inline' as an optimization feature; that's not what
    it's for.


    > On the same note: can you have or inline a virtual template *member*
    > function?


    In C++ you cannot templatize a virtual function.

    That's because a template function defines an infinite set of potential
    functions, and dealing with the unknown set was and largely still is beyond
    the compiler/linker technology C++ rests on in practice.

    --
    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 16, 2005
    #5
  6. In C++ you cannot templatize a virtual function.

    That's because a template function defines an infinite set of potential

    functions, and dealing with the unknown set was and largely still is
    beyond
    the compiler/linker technology C++ rests on in practice.





    will (or should) a compiler complain or ignore the virtual aspects
    (not vtable to be created if this the only v-function defined) if it
    see virtual templ. mem. function?
     
    puzzlecracker, Jul 16, 2005
    #6
  7. * puzzlecracker:
    > In C++ you cannot templatize a virtual function.
    >
    > That's because a template function defines an infinite set of potential
    >
    > functions, and dealing with the unknown set was and largely still is
    > beyond
    > the compiler/linker technology C++ rests on in practice.
    >
    >
    >
    >
    >
    > will (or should) a compiler complain or ignore the virtual aspects
    > (not vtable to be created if this the only v-function defined) if it
    > see virtual templ. mem. function?


    Could you please fix your quoting? It's really not acceptable. One easy
    way is to download a news client such as (if you're running Windows) Forté
    Free Agent, set up an account with a free news-server provider, and voilĂ .

    To repeat myself: in C++ you cannot templatize a virtual function.

    --
    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 16, 2005
    #7
    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. Kevin Spencer

    Re: 2 Psychological sales tactics 2

    Kevin Spencer, Aug 29, 2003, in forum: ASP .Net
    Replies:
    0
    Views:
    492
    Kevin Spencer
    Aug 29, 2003
  2. David
    Replies:
    20
    Views:
    669
    Nicola Musatti
    Jun 3, 2008
  3. David
    Replies:
    2
    Views:
    324
    David
    Jun 11, 2008
  4. Ruby Quiz

    [QUIZ] Solving Tactics (#18)

    Ruby Quiz, Feb 4, 2005, in forum: Ruby
    Replies:
    9
    Views:
    118
    Sea&Gull
    Feb 11, 2005
  5. Ruby Quiz

    [SUMMARY] Solving Tactics (#18)

    Ruby Quiz, Feb 10, 2005, in forum: Ruby
    Replies:
    0
    Views:
    129
    Ruby Quiz
    Feb 10, 2005
Loading...

Share This Page