Best practice about C++ modularity [closed] - c++

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
Is a good practice to allways separate the declaration and the definition even if the definition has a only line, like the constructor or int value() const; in the code bellow?
My goal is to learn C++ and, at the same time, incorporate the best practices. So if there is something to improve in this code please tell me.
//counter.h
#ifndef COUNTER_H
#define COUNTER_H
#include <QObject>
class Counter : public QObject
{
Q_OBJECT
public:
Counter();
int value() const;
public slots:
void setValue(int value);
signals:
void valueChange(int newValue);
private:
int m_value;
};
#endif // COUNTER_H
-
//counter.cpp
#include "counter.h"
Counter::Counter()
{
m_value = 0;
}
int Counter::value() const
{
return m_value;
}
void Counter::setValue(int value)
{
if(value != m_value)
{
m_value = value;
emit valueChange(value);
}
}

All functions implemented inside class definition is inline. So if you put these methods inside class definition you'll make them all inline. This is not equivalent code.
Best practice in C++ is moving to .cpp file as many definitions as possible and keeping your .h file as easy as possible. Reduce the number if #include directives in your header files. Use forward declarations of your classes and structs instead of full definitions where possible.
Alas, these guidelines will not work with templates, that's why C++ compilation is so slow.

Related

Are .cpp files useful? [closed]

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 2 years ago.
Improve this question
I can understand that headers are used to include classes and functions into another file, but .cpp just seem a bit useless to me.
.h files are used to declare functions that can be exported/imported, however, template functions and classes must be defined in the same .h file and not only declared.
I have only used .cpp files as of now for the main program, but can they be used for any other thing? I am using .h files for everything and just .cpp files for the int main() function
Question: What are the cases where you use .cpp files over .h files
Here's an example of how to organize your code. Define headers for any classes you're using, like:
// example.h
#pragma once // Avoid duplicate imports, if supported by your compiler
#include <string>
class Example {
public:
Example();
Example(const char* name);
~Example();
protected:
std::string name;
};
Then implement it:
#include "example.h"
Example::Example() {
}
Example::Example(const char* name_) : name(name_) {
}
Example::~Example() {
}
Then in main.cpp:
#include "example"
int main() {
Example e("Some Name");
return 0;
}
This will all change for the better when modules become the best way to declare things, but until then, this is how it's typically done.

What kind of information is stored in a .cpp file extension? [closed]

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 5 years ago.
Improve this question
I researched this question on Google and Stak Overflow but couldn't find an answer to it.
I am trying to find out what all information is stored in a .cpp file extension. Meaning, is it just code that has been compiled (meaning compiled code)? Does have an object file in it? Does it include an object in it? What exactly does it consist of?
The .h usually has the class definition (code)
#ifndef CLASS_T_H
#define CLASS_T_H
class class_t {
public:
class_t();
class_t(const class_t& o);
~class_t();
class_t& operator=(const class_t& o);
private:
};
#endif
And the .cpp usually has the class implementation (code)
#include "class_t.h"
class_t::class_t() {
}
class_t::class_t(const class_t& o) {
}
class_t::~class_t() {
}
class_t& class_t::operator=(const class_t& o) {
return *this;
}
You could use the class_t in another .cpp file by inclduing the .h file and compiling the cpp files into a binary executable. One of the cpp files would contain your main() method.

create class and function in one header file without library [closed]

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 5 years ago.
Improve this question
Hello i want to create my own public c++ tool like auto socket connection. but i have two ways and i want to know which way is better.
way 1 :
insert the functions (with source) inside one header file and other people just include the header file and use the functions...
sock.h
#include <iostream>
class sock {
public:
bool create();
bool bind();
bool listen();
}
inline bool sock::create() { ... }
inline bool sock::bind() { ... }
inline bool sock::listen() { ... }
and second way is create a header file and also create static lib (c++)
sock.h
#include <iostream>
class sock {
public:
bool create();
bool bind();
bool listen();
}
sock.cpp
#include "sock.h"
bool sock::create() { ... }
bool sock::bind() { ... }
bool sock::listen() { ... }
which way is better ? ( i choose the first way myself because it's easy for client to just include one header file and use the functions but in second way client must include the header and also include the lib file. is there any problem for first way?
Functionally there is no problem. But by keeping the function definitions inside the header, every time the header is imported into a source file, all of the definitions will be compiled again, negatively impacting both compile time and binary size (in certain cases).
Best practice is to define only once, forward declare wherever possible. Keep your abstractions water tight.
Unless you're using template classes, in which case header definitions are generally required.

strange behaviour.. please suggest some solution [closed]

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 9 years ago.
Improve this question
I have encountered one very strange problem. I am trying to explain full scenario here. Please suggest some solution.
/* "test.h" */
class A : public B
{
public:
A();
bool isUp;
};
/* test.cpp */
#include "test.h"
A::A()
{
isUp = false; //`isUp' was not declared in this scope
}
What is it means if I am declaring it in .h inside class. If I am wrong then what approach I need to follow.
EDIT :
class B
{
public:
sem_t m_job_count; //added by RajaGopal
B();
void Init();
void Init(char * s,int );
void RegisterWorker(worker *aWorker);
unsigned long getIndex();
void setIndex(unsigned long index);
char Msg[200];
static void* ThreadProc(void *p);
~B();
};
Where is the definition of class B. Since you are inheriting class B, compiler needs to know the definition of class B. Include its header file or its definition too.
Class definition of B should be visible to A.
Otherwise, I have compiled this code here and did not faced any problem.

Should headers used as part of a base class interface be included in the derived class [closed]

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
Take the following example:
// base.h
#include <string>
struct base
{
virtual ~base() = default;
virtual void do_something(const std::string& arg) const = 0;
};
// derived.h
struct derived : base
{
void do_something(const std::string& arg) const
{
//...
}
};
In this example should derived.h include the string header?
I fully agree with the principle of including what you use but in this case base.h has to include string and if the interface changes to not use string (and the include <string> is accordingly removed from base.h) then the interface will break highlighting anyways.
If the interface changes not to include string, your derived do_something will have to change as well. If you need in the derived.h independently of the interface (e.g. due to details unrelated to interface but present in the implementation) - in this case yes, it's valid and probably preferable to include <string> there as well.
I take the approach of always includeing anything I need for that file. I then don't have to go around hunting through headers and untangling webs of dependencies when I'm missing a symbol somewhere. Include guards mean that this is cheap.
But it's completely up to you. If you want to omit it, to make derived.cpp shorter, and add it in at a later date if the need arises, that's fine too.
There's simply no "right" answer.
You can include "base.h". Don't think too much.The less code you write,the better your code is.
#include "base.h"
struct derived :public base
{
void do_something(const std::string& arg) const
{
//...
}
};