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 put 'sets' just after the constructors because it is related to the object setup. I split gets (put gets in inquires) and sets but not sure if this is good or not. What is best practice for organizing member functions?
How about that?
class Foo
{
// Friends go here if it has
friend ...;
friend ...;
// First public, then protected and private
public:
// enums
enum {...}
// type defines.
typedef ...;
...
// Destructor and constructors
~Foo();
Foo(...);
Foo(...);
...
// Sets.
void setA(...);
void setB(...);
void setC(...);
...
// Inquiries (including gets).
A a() const;
B b() const;
...
// Operators.
void operator()(...);
...
// Operations.
void doSomething();
...
protected:
private:
};
It's hard to judge, it's up to your personal preference or company coding standard. By looking at your code, a few things I may not agree:
your declarations are not ordered from pubilc,'protected` then private
friend declaration has same effort when you declare them in private area as well. so I normally put them in private section, so it gives less noise in public section.
Below is the declaration order I normally use:
Use the specified order of declarations within a class: public: before private:, methods before data members (variables), etc.
class definition should start with its public: section, followed by its protected: section and then its private: section. If any of these sections are empty, omit them.
Within each section, the declarations generally should be in the following order:
Typedefs and Enums
Constants (static const data members)
Constructors
Destructor
Methods, including static methods
Data Members (except static const data members)
Friend declarations should always be in the private section, and the disabled copy constructor and other operators `should be at the end of the private: section. It should be the last thing in the class.
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 4 years ago.
Improve this question
While trying to remove all implementation details from a header file I decide to use and try out PIMPL idiom. The majority if not all examples, e.g. cppreference, I've seen use levels of indirection which reason I can't understand besides encapsulation. The examples always come with this flavor pattern.
Typical
//A.hpp
class A
{
public:
A(int);
//More non-static class methods
void set(int);
private:
struct a_impl;
std::unique_ptr<struct a_impl> pimpl;
};
//A.cpp
struct A::a_impl
{
private:
int i;
public:
a_impl(int i) : i{i}{}
//More non-static implementation class methods
void set(int i) {this->i = i;}
};
A::A(int i) : std::make_unique<struct a_impl>(i) {}
A::set(int i) {pimpl->set(i);} //????
A:://More indirect calls to non-static member functions through pointer
At certain point I start wondering why do I need all this level of complexity and indirection if we are talking about implementation. Why not something simplest without all those indirect calls.
Why not ?
//A.hpp
class A
{
public:
A(int);
//.....
void set(int);
private:
struct a_impl;
std::unique_ptr<struct a_impl> pimpl;
};
//A.cpp
struct A::a_impl
{
int i;
}
A::A(int i) : std::make_unique<struct a_impl>() { pimpl->i = i; }
A::set(int i) { pimpl->i = i; } //!!!!
What I would like to clarify:
1-Are all this samples presented this way just for a matter of education and good encapsulation practices?
2-Is there any other good reason I'm missing to add this level of complexity and overhead besides question 1?
3-Or what I put out as an alternative isn't PIMPL idiom?
Your own approach and the one you compare it against are just two different flavors of the idiom. Herb Sutter listed them, and more, in GotW #100:
What parts of the class should go into the impl object? Some potential
options include:
put all private data (but not functions) into impl;
put all private members into impl;
put all private and protected members into impl;
put all private nonvirtual members into impl;
put everything into impl, and write the public class itself as only the public interface, each implemented as a simple forwarding function
(a handle/body variant).
Each has its own strong and weak points. For the case you study, your approach does seem better. For other cases, a pimpl with behavior and not just state may be more appropriate. There isn't really a one size fits all.
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 4 years ago.
Improve this question
I would like to ask the proper location of typedef in C++.
Version1 : typedef outside class
typedef std::pair<std::string, int> StrIntPair;
typedef std::vector<StrIntPair> StrIntPairVec;
class MyData
{
public:
MyData(){};
~MyData(){};
private:
void addInfo(const StrIntPair &info)
{
infoVec.push_back(info);
}
StrIntPair info;
StrIntPairVec infoVec;
};
Version2 : typedef inside class public
class MyData
{
public:
MyData(){};
~MyData(){};
typedef std::pair<std::string, int> StrIntPair;
typedef std::vector<StrIntPair> StrIntPairVec;
private:
void addInfo(const StrIntPair &info)
{
infoVec.push_back(info);
}
StrIntPair info;
StrIntPairVec infoVec;
};
Version3 : typedef inside class private
class MyData
{
public:
MyData(){};
~MyData(){};
private:
typedef std::pair<std::string, int> StrIntPair;
typedef std::vector<StrIntPair> StrIntPairVec;
void addInfo(const StrIntPair &info)
{
infoVec.push_back(info);
}
StrIntPair info;
StrIntPairVec infoVec;
};
Which version is the best practice?
This depends on where you use the type alias. I'd advice you to
Put them outside of the class if you use them across classes and/or functions and the meaning of the alias is not exclusively related to the class.
Define them as public class type aliases if client code outside of the class needs to access them (e.g. to initialize the object or to store an aliased return value of a member function) but the alias is related to the class. The alias then becomes a part of the class interface.
Define them as private class type aliases when you use them exclusively inside the class, e.g. some utility data structure that is annoying to type out all the time when passing it across member functions.
The compiler will only enforce scopes of aliases that are too narrow (e.g. you use a type alias defined in the private section of your class outside of that class) and won't complain if you choose an unnecessarily permissive scope (e.g. you publicly declare the alias, but use it only in the class implementation). Hence, strive to choose the narrowest scope possible, which is in line with hiding implementation details.
As a side note, you might want to consider declaring your type aliases with using StrIntPair = std::pair<std::string, int>;, see Item 9 in Effective Modern C++. This has no influence on the above, though.
The question is about logical namespace of those names. With abstract naming like StrIntPair, StrIntPairVec and MyData there are no answers. Answers come when the things have meaning.
Lets take exactly same data structures but name them NickAndId, Friends and Player.
Now the question if to put NickAndId inside Player is about if it is specific to player. Can other entities like NonPlayerCharacter or Creature also have nickname and id expressed as same pair? Possibly. Then it should be outside.
Same question should be asked about Friends. Likely the NonPlayerCharacter and Creature can have nickname and id but do not have friends? Then it makes sense to put the type inside of Player as Player::Friends.
Finally, the types that are made private are meant only for usage by implementation details. That should be used when the name makes perfect sense in algorithms used inside of class but availability of those outside is unneeded or even worse, confusing. For example NonPlayerCharacter can react with some replicas to some states whose values are also internal to that NPC. Keeping that in sorted vector Reactions makes perfect sense inside of class. Access to ReplicaInState and Reactions from outside can be confusing.
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 5 years ago.
Improve this question
I am still new to C++ and OOP programming, and I was just wondering about something curious.
I have a class let's name it Foo, with some private members.
My question is: the Foo objects don't "pass data" to other objects during their lifespan. They receive data, do things, and save new data to file. That means, only Foo objects will access Foo private members.
Is it wrong to implement private getters and setters?
Or should I use direct access?
Pseudo code below:
Is this okay?
class foo
{
private:
string a;
string b;
string c;
void setA(string A){this->a=A;}
string getA()const{return this->a;
void setB(string B){this->b=B;}
string getB()const{return this->b;
void setC(string C){this->c=C;}
string getC()const{return this->b;
public:
//many omitted methods//
void Method(); //<-- this method does things and calls private getters and setters to modify private members
}
In main:
{
Foo obj=....;
obj.Method();
}
Or should I:
class foo
{
private:
string a;
string b;
string c;
public:
//many omitted methods//
void Method();
}
void foo::method()
{
string s1;
//initialize s1;
this->a=s1; //operation example
std::cout<<"A equals: "<< this->a;
}
Not sure if I explained my concerns in simple way.
Thank you in advance for your replies and help.
Writing private "getters" and "setters" is pointless, unless you are exploiting polymorphism in some funny way.
Setting up your member variables via a constructor is the best thing to do, and making the members const prevents their unintentional modification.
Avoid "setters" whenever possible regardless of their accessibility as they do little more than circumvent encapsulation.
I'm not the most experienced C++ developer, but from my point of view, using direct access is not a bad practice and it will require less time to write.
On the other hand, having such members in your interface makes it clear that only the Foo objects could read Foo's private members, so both ways are acceptable.
The main point of having getters and setters is controlling access to the class members in a flexible and extensible way. You don't get anything from creating getters and setters if you know they will never be used by external clients of the class, so I would advice to not write them at all.
They will only clutter your source files and make your code harder to read.
By they way, you don't need to use this everytime you want to access a member:
class foo {
private:
string a;
string b;
string c;
public:
//many omitted methods//
void Method();
}
void foo::method() {
string s1;
a=s1;
std::cout<<"A equals: "<< a;
}
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
Since C++11 we can default construct our variables in a class, like this:
class Foo{
private:
int bar = 0;
};
I've very rarely seen someone using this feature
Is this a good practice ?
This is a style question, but there are some considerations that are hopefully universal:
If all constructors of your class have to initialize a member the same way, because the initial value is in some profound way part of the invariants of the class, then it is both more readable and self-documenting and also shorter to use the inline initializer, and the deduplication removes a source of errors if you ever need to change the initial value.
Otherwise, if different constructors supply different initial values, then you shouldn't have an inline initializer, even though that's technically permitted.
I dont see any bad practices in this approach. This is allowed even in Higher level languages like Java. It reduces lines of code inside constructor.
The only big disadvantage I see is that it may lead people to expose more implementation details than necessary in class definitions. Currently, if you initialize a member in MyClass.cpp, then you can easily change the value later on. If you initialize the member in MyClass.h, then a lot of recompilation could be necessary if you later change the value.
In Java, you don't have this kind of separation between header and implementation, so the situation cannot be compared to C++.
C++11 allows non-static data members to be initialized in-class.
This can often save some typing. Consider the following example:
class Foo {
public:
Foo() : a_{5}, b_{7}, s_{"Foo"}, bar_{"Test"} {}
Foo(int x) : a_{x}, b_{7}, s_{"Foo"}, bar_{"Test"} {}
Foo(double d) : a_{5}, b_{g(d)}, s_{"Foo"}, bar_{"Test"} {}
int someFunc();
private:
int a_;
int b_;
std::string s_;
Bar bar_;
};
Using in-class initialization will IMHO make the code more readable.
class Foo {
public:
Foo() = default;
Foo(int x) : a_{x} {} // Initialization list overrides in-class initialization.
Foo(double d) : b_{g(d)} {} // Same here.
int someFunc();
private:
int a_ = 5;
int b_ = 7;
std::string s_{"Foo"};
Bar bar_{"Test"};
};
I would say use it when possible. An exception is when the situation described in this answer applies.
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 know the virtual keyword does not need to be resused in a derived class member function declaration if it overrides a virtual base function but is it good practice to do so to make it clear that it is virtual? Also, what about the presence of the const keyword in declaration and/or definition? I think Alexandrescu mentions something about this but I can't recall what it was?
Your question seems very confused. virtual is optional when overriding a base-class method. const is never optional if you need it. This does not do what you think it does:
struct A
{
virtual void Func() const;
};
struct B : public A
{
virtual void Func();
};
The struct B has two functions named Func. One of them will be called when the object it is called on is const, and the other will be called when it is not const. Nothing in this code has been overridden; these are two separate virtual functions.
You cannot just ignore the const and expect everything to work out fine.
Indeed, this example also shows why you should use virtual when you're overriding in derived classes. In this case, it's fairly obvious that you intended to override a base class function, but you got the function signature wrong. Without the virtual there, there would not be an immediate indication that you intended to override something.
It's not a huge help, but it's something.
C++11 provides a better solution (in that it actually solves the problem) with the override pseudo-keyword.
struct A
{
virtual void Func() const;
};
struct B : public A
{
virtual void Func() override; //Gives a compiler error, since it is not overriding a base class function.
};