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

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.

Are these interview questions?

Quote:

---

Originally Posted by abeginner

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.

Quote:

---

Originally Posted by abeginner

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.

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?

Quote:

---

Originally Posted by abeginner

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.

Quote:

---

Originally Posted by abeginner

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

Quote:

---

Originally Posted by abeginner

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).

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.

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.

Quote:

---

Originally Posted by abeginner

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

Quote:

---

Originally Posted by abeginner

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.

same logic: change m2 to m3

Quote:

---

Originally Posted by abeginner

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.

Quote:

---

Originally Posted by nuzzle

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.

---

So you are actually suggesting that the dependent code is never recompiled? That's a pretty hard constraint!
If the introduction of another constructor overload would cause a bug in other code, I would want to find out about that as soon as possible, rather than have it lingering.

The point to this whole exercise is that all of these situations [i]could[/b] recuire dependent code having to be recompiled. In a more specific case, you may be able to conclude that that is not necessary.