This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
C++ - What should go into an .h file?
I know this is general, but I find it really annoying coding things twice, and would find it a lot easier if I didn't have to browse between two files (my .h and .cc) rather than just keep it all in one.
So, what is the point in having a header file if most of what is there must be rewritten and the rest can just be placed in the .cc.
Instead of:
class VoterData {
// raw data
Voter::States state;
bool vote;
unsigned int numBlocked;
// flags
bool _hasState, _hasVote, _hasNumBlocked;
public:
VoterData();
void reset();
// getters
Voter::States getState();
bool getVote();
unsigned int getNumBlocked();
bool hasState();
bool hasVote();
bool hasNumBlocked();
// setters
void setState(Voter::States state);
void setVote(bool vote);
void setNumBlocked(unsigned int numBlocked);
};
AND:
/* VoterData */
VoterData::VoterData() {
reset();
}
void VoterData::reset() {
_hasState = _hasVote = _hasNumBlocked = false;
}
// getters
Voter::States VoterData::getState() { return state; }
bool VoterData::getVote() { return vote; }
unsigned int VoterData::getNumBlocked() { return numBlocked; }
bool VoterData::hasState() { return _hasState; }
bool VoterData::hasVote() { return _hasVote; }
bool VoterData::hasNumBlocked() { return _hasNumBlocked; }
// setters
void VoterData::setState(Voter::States state) {
this->state = state;
_hasState = true;
}
void VoterData::setVote(bool vote) {
this->vote = vote;
_hasVote = true;
}
void VoterData::setNumBlocked(unsigned int numBlocked) {
this->numBlocked = numBlocked;
_hasNumBlocked = true;
}
Why shouldn't I just put it all in the .cc file and declare the class there?
C++ doesn't tell you where to put your code. Actually, in your case it might be better to use one file:
struct VoterData {
// raw data
Voter::States state;
bool vote;
unsigned int numBlocked;
// flags
bool _hasState, _hasVote, _hasNumBlocked;
// No getters, setters and other cruft needed
};
If your class is more complicated than my or your example, you will notice that having a header file gives an advantage in understanding your program.
In that case, the header file (x.h) will be small (e.g. 20 lines of code) and the implementation file (x.cc) will be large (e.g. 200 lines of code - much more than in your example class). Anyone (who wants to understand what the class does, or how to use it) has to look at the 20 lines in the header file and doesn't have to look at the 200 other lines of code - that's great (speaking from experience)!
So, your example doesn't require separation into header and implementation files.
I believe there are a lot of reasons, which the most noticeable ones are:
If you put a class in a source file and then include that source file in other source files that use that it will work, but it won't work if anything is outside of the class.
There is a huge speedup if other source files that use the class include only header files and don't have to parse the whole class source file.
Circular references, if class A uses class B and class B uses class A, you have to use header files, its not possible with only source files (there is a possible workaround with templates but its just complicated and will get you into trouble).
Of course you can put EVERYTHING in a single .cc file and make it compiled & run, no matter how many classes there are.
Whether to use header files depends on your purpose and habits.
For example, if you want to write a shared library and release it to others, you have to use header files. The users can then include your header files and call the functions you wrote.
For most any one-off code—which will never be shared with any other programs or persons—then I agree: skip creating a header file and put all the code in a .C, .cc, .c++, etc. file
However, if a class will/should/might be reused—often the goal of much development intent—somewhere along the way it is a great idea to identify the declaration portion and put that in a header file, and the implementation part and put that in a source mode: eventually it may become a shareable library.
If everything is in the .cc file and your compiler treats that file as a compilation unit, then you will not be able to use the classes defined in that file in other files (you will get a multiply defined symbol error). Also defining everything in a single file will significantly increase your compilation times, especially in a large project.
All of the answers so far seem to answer with respect to how the language works according to the specification and current compilers, but I think the question is about why it is designed that way.
When you add a method to a class, you have to put the declaration in two places, wasting programming time. It should be entirely possible to add a compiler pass that generates header files based on their code files, shouldn't it? Slightly longer compile times seems like an okay trade-off nowadays, but it wasn't always so.
One thing the current system does is give you finer control over what is where. There may be some defines for example that you want to have for your code that you don't want to be put into the header for anyone that calls your class.
Related
I have a C++20 program where the configuration is passed externally via JSON. According to the “Clean Architecture” I would like to transfer the information into a self-defined structure as soon as possible. The usage of JSON is only to be apparent in the “outer ring” and not spread through my whole program. So I want my own Config struct. But I am not sure how to write the constructor in a way that is safe against missing initializations, avoids redundancy and also separates the external library from my core entities.
One way of separation would be to define the structure without a constructor:
struct Config {
bool flag;
int number;
};
And then in a different file I can write a factory function that depends on the JSON library.
Config make_config(json const &json_config) {
return {.flag = json_config["flag"], .number = json_config["number"]};
}
This is somewhat safe to write, because one can directly see how the struct field names correspond to the JSON field. Also I don't have so much redundancy. But I don't really notice if fields are not initialized.
Another way would be to have a an explicit constructor. Clang-tidy would warn me if I forget to initialize a field:
struct Config {
Config(bool const flag, int const number) : flag(flag), number(number) {}
bool flag;
int number;
};
And then the factory would use the constructor:
Config make_config(json const &json_config) {
return Config(json_config["flag"], json_config["number"]);
}
I just have to specify the name of the field five times now. And in the factory function the correspondence is not clearly visible. Surely the IDE will show the parameter hints, but it feel brittle.
A really compact way of writing it would be to have a constructor that takes JSON, like this:
struct Config {
Config(json const &json_config)
: flag(json_config["flag"]), number(json_config["number"]) {}
bool flag;
int number;
};
That is really short, would warn me about uninitialized fields, the correspondence between fields and JSON is directly visible. But I need to import the JSON header in my Config.h file, which I really dislike. It also means that I need to recompile everything that uses the Config class if I should change the way that the configuration is loaded.
Surely C++ is a language where a lot of boilerplate code is needed. And in theory I like the second variant the best. It is the most encapsulated, the most separated one. But it is the worst to write and maintain. Given that in the realistic code the number of fields is significantly larger, I would sacrifice compilation time for less redundancy and more maintainability.
Is there some alternative way to organize this, or is the most separated variant also the one with the most boilerplate code?
I'd go with the constructor approach, however:
// header, possibly config.h
// only pre-declare!
class json;
struct Config
{
Config(json const& json_config); // only declare!
bool flag;
int number;
};
// now have a separate source file config.cpp:
#include "config.h"
#include <json.h>
Config::Config(json const& json_config)
: flag(json_config["flag"]), number(json_config["number"])
{ }
Clean approach and you avoid indirect inclusions of the json header. Sure, the constructor is duplicated as declaration and definition, but that's the usual C++ way.
In the case where there are multiple desired implementations for a given interface, but where the specific implementation desired is known before compile time, is it wrong simply to direct the make file to different implementation files for the same header?
For example, if have a program defining a car (Car.h)
// Car.h
class Car {
public:
string WhatCarAmI();
}
and at build time we know whether we want it to be a Ferrari or a Fiat, to give each either of the corresponding files:
// Ferrari.cpp
#include "Car.h"
string Car::WhatCarAmI() { return "Ferrari"; }
whilst for the other case (unsurprisingly)
// Fiat.cpp
#include "Car.h"
string Car::WhatCarAmI() { return "Fiat"; }
Now, I am aware that I could make both Fiat and Ferrari derived objects of Car and at runtime pick which I would like to build. Similarly, I could templatize it and make the compiler pick at compile time which to build. However, in this case the two implementations both refer to separate projects which should never intersect.
Given that, is it wrong to do what I propose and simply to select the correct .cpp in the makefile for the given project? What is the best way to do this?
Implementation
As this is static polymorphism, the Curiously Recurring Template Pattern is probably vastly more idiomatic than swapping a cpp file - which seems pretty hacky. CRTP seems to be required if you want to let multiple implementations coexist within one project, while being easy to use with an enforced single-implementation build system. I'd say its well-documented nature and ability to do both (since you never know what you'll need later) give it the edge.
In brief, CRTP looks a little like this:
template<typename T_Derived>
class Car {
public:
std::string getName() const
{
// compile-time cast to derived - trivially inlined
return static_cast<T_Derived const *>(this)->getName();
}
// and same for other functions...
int getResult()
{
return static_cast<T_Derived *>(this)->getResult();
}
void playSoundEffect()
{
static_cast<T_Derived *>(this)->playSoundEffect();
}
};
class Fiat: public Car<Fiat> {
public:
// Shadow the base's function, which calls this:
std::string getName() const
{
return "Fiat";
}
int getResult()
{
// Do cool stuff in your car
return 42;
}
void playSoundEffect()
{
std::cout << "varooooooom" << std::endl;
}
};
(I've previously prefixed derived implementation functions with d_, but I'm not sure this gains anything; in fact, it probably increases ambiguity...)
To understand what's really going on in the CRTP - it's simple once you get it! - there are plenty of guides around. You'll probably find many variations on this, and pick the one you like best.
Compile-time selection of implementation
To get back to the other aspect, if you do want to restrict to one of the implementations at compile-time, then you could use some preprocessor macro(s) to enforce the derived type, e.g.:
g++ -DMY_CAR_TYPE=Fiat
and later
// #include "see_below.hpp"
#include <iostream>
int main(int, char**)
{
Car<MY_CAR_TYPE> myCar;
// Do stuff with your car
std::cout << myCar.getName();
myCar.playSoundEffect();
return myCar.getResult();
}
You could either declare all Car variants in a single header and #include that, or use something like the methods discussed in these threads - Generate include file name in a macro / Dynamic #include based on macro definition - to generate the #include from the same -D macro.
Choosing a .cpp file at compile time is OK and perfectly reasonable... if the ignored .cpp file would not compile. This is one way to choose a platform specific implementation.
But in general - when possible (such as in your trivial example case) - it's better to use templates to achieve static polymorphism. If you need to make a choice at compile time, use a preprocessor macro.
If the two implementations refer to separate projects which should never intersect but still are implementations for a given interface, I would recommend to extract that interface as a separate "project". That way the separate projects are not directly related to each other, even though they both depend on the third project which provides the interface.
In your use case I think it would be best to use ifdef-blocks. This will be checked before compilation! This method is also sometimes used to distinct between different platforms for the same code.
// Car.cpp
#include "Car.h"
#define FERRARI
//#define FIAT
#ifdef FERRARI
string Car::WhatCarAmI() { return "Ferrari"; }
#endif
#ifdef FIAT
string Car::WhatCarAmI() { return "Fiat"; }
#endif
In these code the compiler will ignore the ifdef-block of fiat, because only FERRARI is defined. This way you can still use methods you want to have for both cars. Everything you want different, you can put in ifdefs and simply swap out the defines.
Actually instead of swapping out the defines, you'd leave your code alone and
provide the definitions on the GCC command line using the -D build switch,
depending on what build configuration were selected.
I am working on a C++ project that has gcc as the defined compiler in the makefile. I cannot use a different compiler.
What I need to do is to parse through .cc files which override a particular method called behavior(), inherited from a parent class. This method does not have any arguments and always has void as the return type.
I need to find out the presence of loops (for, while and do-while) within this behavior() method and analyze them in various ways like finding the number of times they are executed etc. For example, let sample.h and sample.cc be the header and source files respectively.
sample.h
class sample_class: public Base
{
....;
....;
void behavior(); //inherited from Base
};
sample.cc
void sample_class::behavior()
{
....;
....;
int n=10;
int count=0;
int c=2;
for(int x=0;x<n;x++)
{
count=count+n; //LOOP1
}
while(int z<5)
{
c=c*5; //LOOP2
}
}
What I want to do is to access the contents of for and while and be able to write something like:
exec_time(behavior)=n*exec_time(LOOP1)+5*exec_time(LOOP2)
Could someone please guide me as to how I can do this while using GCC as the compiler?
Thank you very much for any help.
"finding the number of times they are executed" - this (and only this) requirement necessarily requires runtime counting... you could either modify the relevant functions so they count how often they're called and save the call stack each time, then do some analysis on that output, or try using a profiling tool that already captures the same kind of information - perhaps gprof, or even Quantify or valgrind.
I have a whole bunch of constants that I want access to in different parts of my code, but that I want to have easy access to as a whole:
static const bool doX = true;
static const bool doY = false;
static const int maxNumX = 5;
etc.
So I created a file called "constants.h" and stuck them all in there and #included it in any file that needs to know a constant.
Problem is, this is terrible for compile times, since every time I change a constant, all files that constants.h reference have to be rebuilt. (Also, as I understand it, since they're static, I'm generating a copy of doX/doY/maxNumX in code every time I include constants.h in a new .cpp, leading to kilobytes of wasted space in the compiled EXE -- is there any way to see this?).
So, I want a solution. One that isn't "declare constants only in the files that use them", if possible.
Any suggestions?
The only alternative is to make your constants extern and define them in another .cpp file, but you'll lose potential for optimization, because the compiler won't know what value they have when compiling each .cpp`.
By the way, don't worry about the size increase: for integral types your constants are likely to be inlined directly in the generated machine code.
Finally, that static is not necessary, since by default const global variables are static in C++.
You declare them as extern in the header and define them in an implementation file.
That way, when you want to change their value, you modify the implementation file and no full re-compilation is necessary.
The problem in your variant isn't compilation-related, but logic related. They will not be globals since each translation unit will have its own copy of the variable.
EDIT:
The C++-ish way of doing it would actually wrapping them in a class:
//constants.h
class Constants
{
public:
static const bool doX;
static const bool doY;
static const int maxNumX;
}
//constants.cpp
const bool Constants::doX = true;
const bool Constants::doY = false;
const int Constants::maxNumX = 5;
I think your base assumption is off.
Your other headers are usually organized by keeping together what works together. For example, a class and its related methods or two classes heavily interlinked.
Why group all constants in a single header ? It does not make sense. It's about as bad an idea as a "global.h" header to include every single dependency easily.
In general, the constants are used in a particular context. For example, an enum used as a flag for a particular function:
class File {
public:
enum class Mode {
Read,
Write,
Append
};
File(std::string const& filename, Mode mode);
// ...
};
In this case, it is only natural that those constants live in the same header that the class they are bound to (and even within the class).
The other category of constants are those that just permeate the whole application. For example:
enum class Direction {
Up,
Down,
Right,
Left,
Forward,
Backward
};
... in a game where you want to express objects' move regarding the direction they are facing.
In this case, creating one header file for this specific set of constants is fine.
And if you really are worried about grouping those files together:
constants/
Direction.hpp
Sandwich.hpp
State.hpp
And you will neatly sidestep the issue of recompiling the whole application when you add a constant... though if you need to, do it, you're paying the cost only once, better than a wrong-sided design you'll have to live off with for the rest of your work.
What is the problem with this usage?
Do not declare a static type in header file, It does not do what you think it does.
When you declare a static in header file a copy of that variable gets created in each Translation Unit(TU) where you include that header file, SO each TU sees a different variable, this is opposite to your expectation of having a global.
Suggested Solution:
You should declare them as extern in a header file and define them in exactly one cpp file while include the header with extern in every cpp file where you want to access them.
Good Read:
How should i use extern?
Another approach which is best for compile times (but has some minor run-time cost) is to make the constants accessible via static methods in a class.
//constants.h
class Constants
{
public:
static bool doX();
static bool doY();
static int maxNumX();
};
//constants.cpp
bool Constants::doX() { return true; }
bool Constants::doY() { return false; }
int Constants::maxNumX() { return 42; }
The advantage of this approach is that you only recompile everything if you add/remove/change the declaration of a method in the header, while changing the value returned by any method requires only compiling constants.cpp (and linking, of course).
As with most things, this may or may not be the best is your particular case, but it is another option to consider.
The straight forward way is, to create non const symbols:
const bool doX = true;
const bool doY = false;
const int maxNumX = 5;
These values will be replaced by the compiler with the given values. Thats the most efficient way. This also of course leads to recompilation as soon as you modify or add values. But in most cases this should not raise practical problems.
Of course there are different solutions:
Using static consts, (or static const class members) the values can be modified without recompilation of all refered files - but thereby the values are held in a const data segment that will be called during runtime rather than being resolved at compile tine. If runtime perfomance is no issue (as it is for 90% of most typical code) thats OK.
The straight C++ way is using class enums rather than global const identifiers (as noted my Mathieu). This is more typesafe and besides this it works much as const: The symbols will be resolved at compile time.
in Java code convention is simple and obvious, in this style:
public:
int GetMyAge(){
return myAge;
}
void SetMyAge(int myAge){
this->myAge = myAge;
}
private:
int myAge;
(I know it's "again the same thing", but) I have read most of related questions on SO and I still don't know "the best one" and "the most official" way to do it in C++. It can't be just a matter of preferences, can it?
EDIT:
Seems like it can.
Best not to do it at all. Can your age actually be changed like that? Blindly providing getters and setters for all properties is a sign you have not designed your class properly.
The best style is the one that allows you and your team to make quality software that your clients continue to pay you for.
How does this style work for you and your team? Do you find it causes (or prevents) bugs? Do you find it easy to maintain the code? Do you bicker about the formatting?
Answer those questions and the answer to your question will arise out of them.
A simple answer: class names are capital in general in c++ (except for the std classes), methods are lower case, some frameworks like Qt prefer camelCase, however I prefer underscore_notation -- and so do the STL see eg. "auto_ptr".
Classes do not always have separate .h files, because here a .java file is split up into a .h header (for an entire package), and .cpp implementation files, one per class.
class TipicalCamelCase {
public:
/// mark the frequently used small functions inline in the class def.
inline int getMyAge() const;
void setMyAge(int myAge=5); // defaults go to the definition.
/// for efficiently setting more complex things.
void setMyStuff(const MyStuff& myStuff);
/// a tipical class-valued getter
/// (sometimes scoffed at since it can have memory leaks
/// if you dismiss the class but still use and don't copy MyStuff.)
const MyStuff& getMyStuff() const;
/// a safe getter, but forces copying-out MyStuff.
MyStuff getMyStuff() const;
private:
int myAge;
static const int zero=0; // allowed only in the new C++11 standard.
static const int one;
};
Some implementations/initializations (usually in separate TipicalCamelCase.cpp file):
const int TipicalCamelCase::one = 1;
int TipicalCamelCase::getMyAge() const{
return myAge;
}
void TipicalCamelCase::setMyAge(int myAge_){
myAge = myAge_;
}
Underscore style is the same but
int Tipical_camel_case::get_my_age() const
{
return my_age;
}
I prefer this as it looks cleaner both in the header and in the implementation files.
You can see that function headlines are lengthier than in java. Especially you'll see with templates (generics) 2 lines' header is typical, so it is worth to put them a bit more separated.
template<typename _Tp>
int Class_name::general_function(_Tp);
I think it should do as a style intro.
If you use inheritance, for the java-style working, mark every function except the constructors virtual so that the #overrides behave correctly.
What you have written in the above code is a correct syntax . If you are looking for a thumb rule, code your acccessor functions in such a way that they are set / get exactly the values .
EG :
void SetMyAge(int newAge)
{
if(newAge > 10 && newAge < 100)
_age = newAge ;
}
I would prefer to put the validation "newAge > 10 && newAge < 100" in a different function, IsValidAge ; even if the code is just one line. On the long run, small functions help in maintaining the code, and helps new developers to understand the code better.
void SetMyAge(int newAge)
{
if(IsValidAge() )
_age = newAge ;
}
However I would like to comment on this
void SetMyAge(int myAge){
this->myAge = myAge;
}
It is good practice to differentiate the nameing convention of the class varaiable to _myAge .
EDIT
I think the variable name was comprehended improperly .
myAge should be named _myAge .