what changes to class lead to recompile?
CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums Developer.com
Page 1 of 2 12 LastLast
Results 1 to 15 of 16

Thread: what changes to class lead to recompile?

Hybrid View

  1. #1
    Join Date
    Sep 2009
    Posts
    23

    what changes to class lead to recompile?

    I ran into following question:

    You have a class that many libraries depend on. Now you need to modify the class for one application. Which of the following changes require recompiling all libraries before it is safe to build the application?

    a. add a constructor
    b. add a data member
    c. change destructor into virtual
    d. add an argument with default value to an existing member function



    I'd think that all 4 options would require recompile as they either change the data allocation for class or the public interface of the class. how to go about getting to the right answer in above?
    thanks

  2. #2
    Join Date
    Sep 2009
    Posts
    23

    Re: what changes to class lead to recompile?

    Any help, please!


    The other one was:

    whats wrong with the code..
    class T {
    public:
    T();
    private:;
    char c[7];
    long *p;
    };

    T::T() { memset(this, 0, sizeof(*this)); }


    anything wrong with the above code? pitfalls?

    thanks.

  3. #3
    Join Date
    Jan 2008
    Location
    California, USA
    Posts
    822

    Re: what changes to class lead to recompile?

    Are these interview questions?

  4. #4
    Join Date
    May 2009
    Posts
    2,413

    Re: what changes to class lead to recompile?

    Quote Originally Posted by abeginner View Post
    anything wrong with the above code? pitfalls?
    You're breaking encapsulation by not accessing data members using their symbolic names. You're "nulling" a whole object possibly overwriting implementation dependent parts.

  5. #5
    Join Date
    Sep 2009
    Posts
    23

    Re: what changes to class lead to recompile?

    In (a) - the newly added constructor may be a candidate for constructor call among many overloaded constructors, thus becoming a viable candidate function for some constructor calls.

    class A {
    A(double) {...} // added ctor - CTOR2
    A(int) {...} // CTOR 1
    ...
    }


    Now if the library had "A *a = new A(2.3);" Before Ctor2 was added, it resolved to ctor1. After addition of ctor 2 it;d resolve to ctor2.

    So, seems like addiing constructor would require recompile of lib. Same for (d), adding default value to a function.

    correct?

  6. #6
    Join Date
    May 2009
    Posts
    2,413

    Re: what changes to class lead to recompile?

    Quote Originally Posted by abeginner View Post
    So, seems like addiing constructor would require recompile of lib. Same for (d), adding default value to a function.

    correct?
    You're probably right about a. I didn't consider the case when the added constructor overloaded an existing one.

    In d on the other hand, if you have

    class A {
    void a(double d) {...}
    }

    and change to,

    class A {
    void a(double d=0.0) {...}
    }

    that would be syntactically equivalent to this,

    class A {
    void a(double d) {...}
    void a() {a(0.0);}
    }

    Although adding default to a parameter corresponds to adding an overloaded method, the existing code cannot have any calls to the added overload, in this case a(). So it shouldn't require a recompilation.

  7. #7
    Join Date
    Jan 2008
    Location
    California, USA
    Posts
    822

    Re: what changes to class lead to recompile?

    Quote Originally Posted by abeginner View Post
    In (a) - the newly added constructor may be a candidate for constructor call among many overloaded constructors, thus becoming a viable candidate function for some constructor calls.

    class A {
    A(double) {...} // added ctor - CTOR2
    A(int) {...} // CTOR 1
    ...
    }


    Now if the library had "A *a = new A(2.3);" Before Ctor2 was added, it resolved to ctor1. After addition of ctor 2 it;d resolve to ctor2.

    So, seems like addiing constructor would require recompile of lib. Same for (d), adding default value to a function.

    correct?
    Your general understanding of the language is correct but the question is tricky.
    Your answer (all of the above) would be correct if you make assumption that
    any changes done will be reflected on the library classes.

    However, you can't infer anything solid from the question except;
    1. The modification is done on the author's class, not on the client code
    2. The class is [color =red]used[/color], but you have no idea how or when it is used.
    thus, the question is asking you
    "if you have a Fuji apple, and there are several receipes to make apple pies from it,
    when can you not make an apple pie?"
    In short, it's asking you to distinguish the realtionship from the object initializiation
    from its implementation.
    And given the context of this, the best answer would be b (adding a data member).

  8. #8
    Join Date
    Apr 1999
    Posts
    27,444

    Re: what changes to class lead to recompile?

    Quote Originally Posted by abeginner View Post
    Any help, please!
    anything wrong with the above code? pitfalls?
    Let's see your answer first. Do you think there is anything wrong with the code? If not, why not. If there is something wrong with the code, why?

    Regards,

    Paul McKenzie

  9. #9
    Join Date
    May 2009
    Posts
    2,413

    Re: what changes to class lead to recompile?

    Quote Originally Posted by abeginner View Post
    I'd think that all 4 options would require recompile as they either change the data allocation for class or the public interface of the class. how to go about getting to the right answer in above?
    Option b changes the size of objects and c will make the destructor dynamically bound rather than statically so that changes how it's called by existing code. These should require a recompilation.

    But what about a and d? Both changes are equivalent to adding methods and adding methods doesn't change the size of objects, and existing code isn't using the added methods so there will be no calls to them. I don't think this would require a recompilation.
    Last edited by nuzzle; September 28th, 2009 at 02:56 AM.

  10. #10
    Join Date
    Sep 2009
    Posts
    23

    Re: what changes to class lead to recompile?

    nuzzle,
    (d) would recompile by the same logic as (a).

    class A {
    void a(int i, int j ) {...} // m1
    void a(int i) {..} // m2
    }

    If you add m3 to A:

    void a(int i, double j =0.0) {...} //m3

    A call in the lib of the form "a(1, 1.5)" would not match with m3 and not m1.

  11. #11
    Join Date
    May 2009
    Posts
    2,413

    Re: what changes to class lead to recompile?

    Quote Originally Posted by abeginner View Post
    nuzzle,
    (d) would recompile by the same logic as (a).

    class A {
    void a(int i, int j ) {...} // m1
    void a(int i) {..} // m2
    }

    If you add m3 to A:

    void a(int i, double j =0.0) {...} //m3

    A call in the lib of the form "a(1, 1.5)" would not match with m3 and not m1.
    As I understand (d) you don't add a method, you make a parameter default in an existing one.

  12. #12
    Join Date
    Sep 2009
    Posts
    23

    Re: what changes to class lead to recompile?

    Paul Mckenzie,
    Whether a ctor is correct or not depends upon what it is expected to do per design. it is not clear whether the designer expected ctor to allocate memory for long *p. If yes, then ctor does not do what was expected. If no, it is ok for the isolated case in question.
    one can not use memset in general. even though advatage could be reduced overhead wrt to initialization of each member, what about const members? can they be memset? clearly memset can not be used if the ctor was expected to allocate memory to class member ptrs.

  13. #13
    Join Date
    Apr 1999
    Posts
    27,444

    Re: what changes to class lead to recompile?

    Quote Originally Posted by abeginner View Post
    Paul Mckenzie,
    Whether a ctor is correct or not depends upon what it is expected to do per design. it is not clear whether the designer expected ctor to allocate memory for long *p. If yes, then ctor does not do what was expected. If no, it is ok for the isolated case in question.
    one can not use memset in general. even though advatage could be reduced overhead wrt to initialization of each member, what about const members? can they be memset? clearly memset can not be used if the ctor was expected to allocate memory to class member ptrs.
    You are overthinking the reasoning why the code is faulty. I answered you in the other thread.

    The bottom line -- don't code that way.

    Regards,

    Paul McKenzie

  14. #14
    Join Date
    Sep 2009
    Posts
    23

    Re: what changes to class lead to recompile?

    same logic: change m2 to m3

  15. #15
    Join Date
    May 2009
    Posts
    2,413

    Re: what changes to class lead to recompile?

    Quote Originally Posted by abeginner View Post
    same logic: change m2 to m3
    Well, okay. I interpreted (d) as meaning you add a change, namely making an existing parameter default. In that case I don't think a recompile would be neccessary.

    But it probably should read you add a default parameter thus increasing the parameter list with one default parameter. And then it's the same logic as in (a).

    I'm glad I don't have to take these tests to get a job anymore.

    Anyway if you reconsider (a) for a second.

    Say you have a constructor that takes a double parameter. Then you add another constructor which takes an int parameter thus overloading the first constructor. Formally you now can have code that previously selected the former constructor but now instead would select the latter constructor.

    Now it would be pretty suicidal to let the added overloaded constructor do something totally different. Then recompiling the code would most likely spell disaster. Because suddenly there will be random calls to a new constructor that does something different than the programmer knew about when he wrote the code.

    So either the added constructor doesn't change anything. It just replaces with overloading what the program did before by coercion (automatic conversion between int and double). Then you don't need to recompile. Or the added constructor does indeed change the program logic. Then you shouldn't recompile because this most certainly would introduce bugs.
    Last edited by nuzzle; September 28th, 2009 at 06:30 PM.

Page 1 of 2 12 LastLast

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •  


Windows Mobile Development Center


Click Here to Expand Forum to Full Width

This is a CodeGuru survey question.


Featured


HTML5 Development Center