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.
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 3 years ago.
Improve this question
This seems like a really simple question, but I've been unable to find any opinions on it. When writing setters in C++, what is the difference between
void ClassName::set_member( type value ) {
ClassName::member = value;
}
and
void ClassName::set_member( type value ) {
this->member = value;
}
CLion generates the first version, so I suspect it has some advantage, but I don't see what that would be.
The difference is purely syntactic. Both versions have exactly the same effect. It doesn’t even matter whether member is static or non-static. Only from inside a static member function you cannot use the this-> version because there is no object and thus no this.
Because it feels really weird it bears repeating: Even if member is a static member variable this->member = value; is valid and does the right thing.
As for preferring one style over the other: like all stylistic choices that’s highly subjective. A clear answer isn’t really possible. But there are indictators of what the C++ community prefers in general. You might look at:
open source C++ code on GitHub etc., or your standard library implementation
code snippets on presentation slides from major conferences like CppCon, Meeting C++, C++ Now etc.
major C++ books, e.g. Stroustroup’s The C++ Programming Language or Scott Meyers’ Effective C++ series
Considering all that I’m confident to say that the prevalent style is none of your two, but:
member = value;
On a purely personal note: For non-static members the ClassName:: version feels unfamiliar to an extent that I would call it out in a code review. this-> usually makes me wonder “Was this written by a Java programmer?”, but overall – especially if it’s used consistently – it’s an ok style, although unusual; and in some special template metaprogramming cicumstances it’s even mandatory.
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.
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
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 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.