Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 6 years ago.
Improve this question
Why only default constructor only able to create vptr(Virtual Table Pointer) and vtable(Virtual Table)? Why parameter constructor not able to
First, vtables and vptrs are not specified by the C++ language standard.
They're an implementation detail, although as far as I know all extant C++ implementation use that technique to implement virtual function dispatch.
With such an implementation, all constructors for a class with virtual member functions, necessarily establish the object's vptr. Things wouldn't work without it. So …
” Why parameter constructor not able to
… is simply an incorrect assumption.
Assuming the implementation uses vtables (a pretty common implementation choice, as noted by "Cheers and hth - Alf"), the creation/population of vtables and invoking constructors are distinct operations.
However, all instances of a given (non-abstract) class will - once constructed fully - have the same set of vtables (a class that inherits from multiple bases may have more than one vtable). There will certainly not be a different vtable depending on how the object is constructed (e.g. what parameters are passed to constructors, which constructor is invoked, etc).
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
These recommendations boost::pointer_container suggest that one derives ABCs from boost::noncopyable to prevent slicing further down the hierarchy. Apart from the mentioned advantages, are there reasons why I should not follow this recommendation?
There is a thing called "empty base optimization" that will prevent derived class from growing when deriving from base class that has no non-static data members and no virtual functions (that is no vtable). MS Visual C++ however implements such optimization only for first base class (that is minimal standard requirement if I remember correctly). So if you want to derive your class from two empty base classes you'll waste empy base optimization on the ::boost::noncopyable. So it would be better to explicitly write deleted constructors / assignment operators in this case.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I have a event based communication system, and this is the simplifed version of it:
class A: contains elements derived from class B
class B: has a pointer to its owner A
So when a B wants to communicate with other B-s, it calls A's Broadcast() method:
m_owner->Broadcast();
But I was wondering:
Should I make a protected Broadcast() method for B, which is just this:
m_owner->Broadcast();
Pros:
Instead of m_owner->Broadcast() I can write just Broadcast()
this makes the code cleaner.
Cons:
There will be +1 function calling in the procedure.
But this can be avoided by making the method inline
Is this a good practice? Why yes and why not?
In a situation that you have described, it probably indeed does not make much difference.
But in future you may find that you will need to add extra code to each place where Broadcast is called, for example logging or mutex locking. In this case, a separate function will be really useful.
Also you mention that you have classes derived from B. If this is a derived class that calls m_owner->Broadcast(), and m_owner is a base class field, then this is not a good pattern. Derived classes should better access parent's protected functions, not directly data members.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 8 years ago.
Improve this question
I don't understand the purpose of constructors and how they function in C++. I understand that a constructor a is a function within a class that has the same name as the class but does not have a return type.
The purpose of a constructor in C++ is to reliably initialize raw memory, turning it into a useful object by establishing the chosen class invariant (what you can always assume about the object between calls of its member functions).
In contrast, an assignment has to change the value of an already initialized object, and may for example have to deallocate buffers that already have been established.
As long as you don't use very low level features of the language there is effectively a constructor call guarantee: that every object instantiated from a type T that has at least one user defined constructor, gets a single external call to a T constructor, which happens before anything else. Conversely, when you call a constructor by using the type name as a pseudo function name, T(), or with arguments, a T object is created. So the guarantee works both ways, and means that object creation involves constructor call and vice versa.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 8 years ago.
Improve this question
Or in a class method, call other class' method/free function and pass this pointer as the parameter. Is there any good practice for this? Or it is a bad practice and I should not doing so?
It usually makes no sense to return the this pointer from class meber functions.
(since the caller must be already holding a reference to the instance,, to call the method/operator in question, and you cannot change it returning di9fferent values anyway).
It makes sense to return *this from various types of member functions (specific operators in particular, e.g. operator=()), to enable chaining of operations on results.
NOTE:
Some of the overloadable operator signatures (as the mentioned assignment operator) require to implement such behavior to work correctly with the semantics defined by C++!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Could someone explain this theoretical question about the C++ object model? It was on a recent exam of mine and I was stumped by it.
Question:
Noting the success of Java, C#, and Smalltalk, the C++ Standard Committee has decided to add an additional level to the language's object model. Namely, each class should have a meta-class that has a representation at run-time.
The opponents says that this contradicts one of the language's fundamental principles. Which? Explain.
The opponents have also claimed that C++ has an additional "half-level" that allows some of the functionality of the full-blown metaclass level. What is this "half-level" and what kind of clases enjoy its capabilities?
The supporters have come up with a winning argument. Adding a level will provide support for the Mark phase in a Mark & Sweep garbage collection (in which all reachable objects are first marked, and then non-reachable ones are freed). What feature in the additional level does their argument rely on?
In addition, the supporters have come up with another argument. The additional level will make virtual destructors redundant, even without a garbage collection system. Explain when and why a virtual destructor is needed and how an additional level will eliminate that requirement?
Since I haven't been in your course, I can only guess:
1: C++ is a kind of lego kit - you take what you need and you can leave everything else. You don't have to pay for it either. Adding this additional level requires some initialization and stuff and I suppose you can't select not to use it - even if you don't require it.
2: RTTI for classes with vtable
3: Here I can only guess - I suppose that all instances of a class are somehow reachable by the meta class or can be detected by scanning the memory. If that's the case, you can implement mark&sweep.
4: virtual destructors are needed if you destroy a class instance via a pointer that has the type of one of the base classes. If you can reach from each instance the meta class, you can then call the correct destructor without the need of having to look it up in the vtable.