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.
Related
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).
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 8 years ago.
Improve this question
My current project involves writing a C++ API and I have decided to use the PIMPL idiom.
Should I use the PIMPL idiom everywhere in my project, for example I need to create a custom class that inherits from std::exception, should I design this class with PIMPL idiom in mind or can I just write as a public implementation?
It feels wrong to assume that just because I'm using the PIMPL idiom that every class I create should be designed around it. Are there any exceptions where PIMPL should not be used?
If you are writing API/library the question is what is the main advantage for the users of your API and even what IDE and tools they will be using working with your API.
The key points for using PIMPL are:
You want to really hide implementation from users (you have great amount of private methods and fields and very simple public interface).
You want to abstract them from platform-dependent code.
You want to reduce their build time.
You shouldn't use PIMPL when virtual calls or any sort of indirection cost your users too much in operation time of their programs:
Sequences of repeated small functions calls (and you can't remove it from API level).
Creating and deleting huge amount of small objects (and you can't remove it from API level).
PIMPL has costs.
Therefore it's only a good idea where you really need it, e.g. to contain use of a C header that uses C++ keywords as names, or that e.g. defines a zillion macros.
Some (including Herb) advocate or at least don't argue against using PIMPL purely for reduced build times, but other measures such as throwing hardware at the problem can be less costly.
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 8 years ago.
Improve this question
I'm making a calendar application in c++ and I'm making a great number of overloaded constructors for the appointment class depending on the information provided(e.g. if i have a start time for the event but no end time, and a location, but no attached contacts)
class Appointment {
public:
//overloaded Constructors
Appointment();
Appointment(Date);
Appointment(Date,Date);
Appointment(Date,Date,std::string);
Appointment(Date,Date,std::string,std::string);
Appointment(Date,Date,std::string,std::string,Contact);
etc. etc. Is there a better way to do this?
You could either:
Create the object (a valid one) and set its properties afterwards via interface setters (since it seems an object can have a variable number of properties this seems like a good choice)
Use default parameters, e.g.
Appointment(Date=getDefaultDate(),
Date=getDefaultDate(),
std::string=getDefaultString(),
std::string=getDefaultString(),
Contact=getDefaultContact());
It really boils down to how you prefer to handle and initialize your objects.
An important sidenote: in large production codebases default parameters is a C++ feature often frowned upon because it might hinder readability and/or render debugging more difficult in particular scenarios (especially when something unwanted goes on and you didn't consider a default parameter being chosen, default parameters are specified on the declaration and that might also "hides" a potential problem from the developers)
This is totally unnecessary. As pointed out Macro A , you can default construct the object and afterwards you can use setters for them.
One more thing when designing a software you should keep in mind the rule of complete and minimal i.e you should provide all facilities in a class avoiding duplication/redundancy.
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 8 years ago.
Improve this question
I hear a lot that RTTI can be avoided by using good virtual functions...since RTTI is clunky and slow, why should I use it? Are there any situations where I should use RTTI instead of virtual accessor functions?
RTTI can be used to solve the double dispatch problem (a function that behaves virtually based off the dynamic type of two objects).
RTTI gives you automatic access to the class inheritance graph of types with virtual methods.
Like some other language features, if you only want a restricted subset of its features (if you are ok with a centralized list, or single implementation inheritance, or even single binary, or lack of availability early/late in execution, etc) you can sometimes implement a more efficient, restricted version.
In addition, often double dispatch can be refactored into orthogonal single dispatches. And even if RTTI allows multiple dispatch, the code remains messy and difficult to maintain and RTTI can be a non trivial cost (note that compilers are much better at it now). So often a simpler, seemingly less efficient single dispatch solution ends up being a better idea anyhow.
RTTI can also be used in despirwtion when you need dynamic dispatch, but have no access to the ability to add new virtual methods for whatever reason.
Tightly coupled classes that expose pure interfaces but need to work with each others guts can use RTTI when paranoid about the dangers of blind static_cast as well.
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
I have a project that contains several classes. I added to this project several functions that are used by one of the classes, let named MainClass. I put all these functions in a file stuff.h. To use these functions I include the stuff.h file at the beginning of the implementation of the class MainClass. I am wondering if this is a good style of programming or if it would be better to create a new class and add my functions to this class. Then I instantiate this class in the MainClass.
Not so good style. Starting from the fact headers are not actually intended to have real code but declarations of things defined somewhere else.
If your 'external' functions are used only by MainClass why not to do them class methods? Even maybe private so they are only visible inside class? Keep things as encapsulated as you can. If you're trying to follow C++, try not to use 'plain C functions'. It's different language. If you absolutely need plain routines, use namespaces instead. But please try to keep your code inside modules (.cpp), not in headers.
Regarding other classes. It depends if you know why you need other classes. If you don't know why, you don't need them. BTW OOP is not always 'best' approach, especially in things like balance between inheritance and composition. You should understand what you really want to achieve to select proper technique.
Indeed you need good C++ book. Chapters about project composition, compilation process, translation units so you will understand logics behind this. This Q&A site cannot explain you everything. Just give some points.
Good question here for you
I think it would be better to create a new class, or several new classes that are ordered by the different ways the functions will be used. That's more in line with classic OO.