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.
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
I am working on a C++ project, where the lead is saying that private/public doesn't matter in practice, and so that all the classes should have only public members. Basically, he wants C++ with struct only.
His main argument is that huge code bases were written in C without private, and no bugs would have been prevented in those code bases by having a private keyword, so why bother?
I am countering by saying that private state is cleaner modularization, that it makes the code easier to reason about, easier to test, easier to refactor, that I could write assertions to make assumptions explicit with private state, that different teams could work independently by just agreeing on the interface of classes, but nothing seems to convince him.
What are the purely technical/objective arguments in this discussion, for/against struct/class with private members? It is a given that there is no generic answer, but I would like to list all the objective arguments I could use to evaluate which one to use in any given situation. Something like reasonable guidelines that we could all agree on, or an analysis grid that would tell us which one to use, given parameters of the situation. I would like to steer clear from personal preferences, as discussion of personal preferences is probably not productive.
It would be particularly useful to see a few concrete examples that demonstrate the pros/cons of each in specific situations.
My answer would be, "No, there is nothing to add." As you said, he has already dismissed good reasons. Maybe he's pleased with himself for recognizing that code can work without any private members, so he's being stubborn. I don't know.
A struct is fine where it makes sense, but people (like me) who have maintained code extensively know that encapsulation does improve design.
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 7 years ago.
Improve this question
sorry to bother but I'm a newbie programmer and has just been starting on c++ course. The reason I asked this question is because I've been hearing on OOP and its relation to class.
So my question is:
Does class actually simplify the programming code just because it groups up all related functions into one single "object" thats called "class" ?
One more thing is that...
Why do we create class inheritance when we could use one class and derive all functions from that one class alone?
Sorry to bother.
Newbie programmer.
"Does class actually simplify the programming code just because it groups up all related functions into one single "object" thats called "class" ?"
The main idea is to encapsulate state (== data) with operations that can be applied to it into a single class type.
Yes, that simplifies programming code, because there are certain interfaces/operations that can be used with this type.
"Why do we create class inheritance when we could use one class and derive all functions from that one class alone?"
Derived classes may introduce different behavior as inherited from their base class. There are many uses when you want to change that behavior, without inventing new function names all the time (or just add numbers to them).
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 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
I'm using both win32 and directx when making a game engine + game. Win32 directly needs the window header and directx header includes it aswell.
It is a decently-sized project and I'd rather avoid exposing the windows header to the rest of the project(s) if possible. Is there any good way to bypass this issue?
There's only one practical way to avoid exposing a header that your implementation code needs, and that's to include the header only in the implementation.
That's called the compiler firewall idiom.
Often (but this is not always required) one exposes a class with a member pointer to an object of declared but incomplete type, that is defined only in the implementation file. This is usually called the PIMPL, short for pointer to implementation, idiom, but it has also been called the handle-body idiom and the Cheshire Cat idiom.
One alternative to a PIMPL pointer is to declare a factory function in the header file, where that factory function produces objects of some known type Base, and in the implementation file let it produce an object of a derived type Derived that contains the dependencies on the undesirable header.
Another alternative, but then you might run into thread safety issues, is to just provide functions that operate on a static state variable. I.e. a singleton, a global. Yes this is as bad as it sounds (even though a whole programming language, Modula-2, was based on the idea), but it certainly is a technical option, and might be preferable in certain situations.