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 see such answer:
COM is a technique of it's own. It fulfills some special needs but
violates a lot of good engineering principles. E.g solid. The standard
has better ways than using COM. – mkaes
Very interesting to know what is that "better ways"?
We use in our project IUnknown base class, but not COM technology itself.
IUnknown allows us:
have nice specified interface abstract classes;
use its add()/release() as basis for intrusive smart ptrs;
use mechanism of QueryInterface() to be more effective than dynamic_cast;
Okay, exists boost::intrusive_ptr but it is not in the standard so far. And even if it was there, this will be separate class to solve task of intrusive smart ptr. Assuming it is there, yes I could do something as
interface ITable : intrusive_ptr {}
interface IField : intrusive_ptr {}
But what about QueryInterface() mechanism?
P.S. This question is NOT about COM at all.
The standard uses: composition rather than inheritance in most cases (very little inheritance in the standard library). Prefers template based generic programming rather than runtime polymorphism. Prefers value types rather than keeping pointers of unknown ultimate type for everything, everywhere. All things you should be doing in C++ rather than treating it like Java.
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 7 years ago.
Improve this question
Let's suppose I'm writing a compiler for some programming language. It is common to use abstract syntax tree (AST) as an internal representation. I can see two possible ways to design it:
using boost::variant
using inheritance
As hierarchy of nodes is fixed - boost::variant will suffice.
My question is what are the advantages and disadvantages of each approach from points of maintability and runtime efficiency?
Using boost::variants will work, but will require you to use visitor pattern extensively to exploit the content of a variant object. If later you extend the number of types used in your variant, you'll have to maintain all the visitors that you've implemented.
With inheritance, you have the advantage of being able to use polymorphism. Later extension will be straightforward : simply derive one of the existing base and override the polymorphic functions, without touching the rest of the code.
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 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 8 years ago.
Improve this question
It seems to me that C++-style struct can do more things than a C-style struct (for example, you can have member functions and access specifiers). What's the design reason for this, considering we already have class in c++?
A real design example would be appreciated.
What's the design reason for this, considering we already have class in c++?
A few potential benefits I can image are:
Easier compiler implementation by being able to handle structs and classes in almost the same way.
More options for developers. For instance, being able to use structs as more than just POD types by adding basic things like constructors, while leaving classes for usages where for object-oriented design is used.
Being able to derive from structs in C-compatible headers of 3rd-party libraries to add on convenience features like constructors and member functions.
A real design example would be appreciated.
Using the third idea: The Windows headers define a struct called RECT. MFC provides a class CRect which derives from it and provides several useful methods, but it's still able to be used in place of a RECT whenever needed by the Windows API.
If you are asking for a "design reason" to allow members to be defaulted to public visibility, then this is easily justified: The legacy struct from C originally assumed all members were public, so defaulting to public would make it easier to port C code to C++ without heavy modifications to the original C code. It also makes it easier to share C header files with C++ code.
If you are asking why struct was extended in C++ to be allowed to have protected/private sections and methods, then this has more to do with what the inventor of C++ imagined to be the fundamental difference between a struct and a class from the point of view of a user of the language. The answer was ultimately made that fundamentally, there is really no difference whatsoever (save the default to public visibility).
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 9 years ago.
Improve this question
Sutter and Alexandrescu have discribed in a quite simple and self contained way the ecosystem of C++ classes, providing 6 main categories
Value classes (e.g., std::pair, std::vector)
Base classes (building blocks of class hierarchies)
Traits classes (templates that carry information about types)
Policy classes (fragments of pluggable behavior)
Exception classes
Ancillary classes that typically support specific idioms (e.g. RAII)
It is a very handy shortcut when taking decisions on class design and I'
ve used it before, but there are two things that come into play: 2004 (the year that book was puplished) is a long time ago in software engineering and there is a new language standard since then. I can't but wonder:
Is this this categorization still relevant?
Are there any new items ammending the above list?
Is there an alternative categorization, by authors having matching authoritative power?
Is there a standard taxonomy for c++ classes? (for all I know this could also be it)
NOTE:
I hope the 4 questions above have a clear setting. To avoid opinion based answers, a valid answer should link/mention examples, code usage or standard excerpts that verify its statings.
In a categorization like this I would also include Inner classes as the type of classes that declare containment. For example Engine is included in a Vehicle:
class Vehicle{
public:
class Engine{
};
Engine* vehicle_engine;
};
But it reduces the readability of the code. I prefer composition over Inner Classes. It is not so easy to distinguish between language featured type of classes and design patterns. For example can Singleton be on that categorization?
The categorisation is relevant in C++11 as well, the basic OOP premises haven't changed.
The scope of the answer has to be limited because you explicitly ask about class types, nevertheless, I would add Functors (including lambdas) to the list.
Also now that enums are strongly typed (specified with the enum class keyword), they can arguably have their own place in the pantheon.