Is this generally accepted as proper formatting for C++ classes? I've seen so many different formats for how to code classes while trying to learn them. I'm just wondering what the standard or 'normal' way of doing it is.
class Circle
{
private:
double radius;
public:
Circle()
{
radius = 0.0;
}
Circle(double r)
{
radius = r;
}
// MEMBER
void setRadius(double r)
{
radius = r;
}
double getArea()
{
return 3.14159 * radius * radius;
}
};
It's a matter of taste and consistency. There are many ways in which you can format not just classes, but all parts of the code in general. What's important is that the code is readable to anyone involved on your project, and follows basic guidelines in your group/workplace/whatever.
I would normally put the members in the bottom:
class Circle {
public:
Circle() {
radius = 0.0;
}
Circle(double r) {
radius = r;
}
void setRadius(double r) {
radius = r;
}
double getArea() {
return 3.14159 * radius * radius;
}
private:
double radius;
};
There is no universally preferred format, but what you show is probably
the most widely accepted. With one exception: it's usually considered
bad form to put the function implementations in the class definition.
There is no standard or format.
If you are working alone, do what makes it more readable for yourself - and sure, if you look at other people's code and say "Hey, that looks more readable", then feel free to assimilate their coding habits in your own.
If you are working in a team, it's best to follow some guidelines as set down by the team in general, lest you incur the wrath of the senior programmer who has spent a thousand more years in C++ than you have and evidently has a place set aside for him on God's right hand when he finally expires. Jests aside, it makes things much easier if a team is following guidelines.
This is my personal preference, hopefully I won't get down-votes for preferences:
template<class T> // template declaration if required
class myAwesomeClass
{
public:
/*
* Static stuff that is public goes here, oh and any type-definitions that are
* also externally viewable
*/
private:
/*
* All my secret stuff
*/
protected:
/*
* My descendants can be decadent with this stuff, may they revel in the power
*/
public:
/*
* The rest of you guys get this
*/
} // eo class myAwesomeclass, comment to determine the end of the definition
// this can be useful if things are big!
As classes are private by default the private: keyword after your first { is superfluous. The formatting that I have seen most and makes sense to me ispublic: then protected: then private: for access-specifier order.
Related
Let say that I have a big class Circle with a lot of members and functions. To proceed a large amount of data I decided to create class PotentialCirlce (with only 3 members - x, y, r), do most of preprocessing based on PotentialCirlce and in the last stage create objects Circle.
a) is it correct approach? do It influence on performance or rather should I use only Circle.
It seems to me that I can use inheritance:
class potentialCircle {
protected:
point_t center;
unsigned int radius;
public:
potentialCircle(int a, int b, unsigned int r) : center{ point_t(a,b) }, radius{ r } {}
potentialCircle() = delete;
potentialCircle(const potentialCircle&) = default;
potentialCircle(potentialCircle&&) = default;
potentialCircle& operator=(const potentialCircle&) = default;
potentialCircle& operator=(potentialCircle&&) = default;
virtual ~potentialCircle() = default;
};
class Circle : public potentialCircle {
// members detected based on Hough Circle Transform
//point_t center; // coordinates of center point
point_t alternative_center; // needed when center is out of frame
//unsigned int radius; // radius
// members calculated based on Flood Fill algorithm (more realistic)
unsigned int area = 0;
float diameter = 0;
float perimeter = 0;
....
};
b) where should I put method which needs to compare two difference objects? one object of type Circle and one of PotentialCirle?
currently, I have defined below function as part of Circle
bool Circle::is_greater(const std::pair<potentialCircle, int>& point_pair) const;
but I don't have access to protected data members of potentialCircle, although Circle is inheriting from potentialCircle.
Maybe I should defined is_greater() as part of namepsace and make it a friend to Circle and potentialCircle.
Do you have better idea?
There are not really a good approach to compare objects of different types as it make little sense in practice. What would be the purpose of such comparisons.
Now even if you have a single class, if the ordering is not intransic to the type, it would be better to use an external class for sorting.
class CircleDiameterLess
{
public:
bool operator()(const Circle &lhs, const Circle &rhs)
{
return lhs.diameter < rhs.diameter;
}
};
That way, you can have multiple ways to sort data and it play nice with STL.
Another problem with your code if that it make little sense to have a class circle with a diameter that derives from a class potentialCircle with a radius. Your code will be hard to maintain because it is hard to understand.
You want to store either the diameter or the radius and compute the other one.
unsigned int get_diameter() const { return radius * 2; }
Member like alternative_center make no sense. A circle has only one center. If your class does not respect basic expectations, it will make the code hard to maintain as nobody would known that a circle has 2 centers including you in 3 months!
In a case like yours, it make make sense to add public accessors.
class potentialCircle
{
public:
unsigned int get_radius() const { return radius; }
....
};
That way, you can still make data private (or sometime protected) while having read only access to it. That way, you can write you comparison function as you wish. And in practice, if you have a class that represent a circle, you usually want at least being able to get basic properties like radius, aread, bounding rectangle by the way of a function.
Another thing is that public derivation as your (from potentialCircle) would only make senses if you have other classes that derives from it. However, if this is the case, then how would you compare the other kind of circles?
Notes:
With C++ 20, three way comparison would be even better.
When my program is very young, there are usually many functions that do simple things.
When it became older, I found that it is more convenient to bundle some similar functions together, and group the return results of old functions as a "Report".
The "Report" can be easily passed around as a communication package among different modules.
Example 1
Code V1
class B{
float getWidth(C c){
float width= ... (very cheap function about "c") ;
return width;
}
float getHeight(C c){
float height= ... (very cheap function about "c") ;
return height;
}
};
Code V2
class ReportSize { float width; float height; }
class B{
ReportSize getSize(C c){ //<-- grouped
float width = ... ;
float height= ... ;
return ReportSize(width ,height);
}
};
Example 2
Code V1
class D{
Vector3 calculateNarrow(){ ... }
Vector3 calculateBoard(){ ... }
};
Code V2
class ReportVector3Pair{
Vector3 resultNarrow;
Vector3 resultBoard;
Vector3 get(NARROW_OR_BOARD paramEnum){
//return "resultNarrow" or "resultBoard"
}
};
class D{
ReportVector3Pair calculate(){ ... } //<-- grouped
};
Question
The refactoring cost some development time. All locations of code (up to 100 callers) have to be manually refactored to match the new signature.
How to minimize the chance of the need to refactor it later? How to minimize cost of the refactoring if it may happen in future?
How to minimize the chance of the need to refactor it later?
Create non-member functions that can return higher level objects instead of changing existing classes.
For example, instead of writing V2 of B, keep the existing B and use:
class ReportSize { float width; float height; }
ReportSize getReportSize(B const& b, C c)
{
return {b.getWidth(c), b.getHeight(c)}
}
Similarly, instead of creating V2 of D, keep existing D and use:
Vector3 calculate(D const& d, NARROW_OR_BOARD paramEnum) {
//return "resultNarrow" or "resultBoard"
}
How to minimize cost of the refactoring if it may happen in future?
Use non-member functions to extend functionality instead of modifying existing classes.
According to Scott Meyers, using non-member functions improves encapsulation.
Using non-member functions to add new functionality also follows The Open/Closed Principle.
The following is an example:
In circle.h
class circle
{
double _radius;
public:
double getRadius() {return _radius;}
void setRadius(double r) {_radius=r;}
}
In main
int main()
{
circle a;
cout<<a.getRadius(); // I want to use "a.radius"
a.setRadius(3.2); // I want to use "a.radius=3.2"
}
So the first question is why we should use get and set function to access instance variables rather than directly access them? The second question is how to do operator overloading to let the function call of get and set looks concise(like what objective-c did)?
Of course, the simplest way to make the syntax that you're hoping for available is to just make _radius a public member called radius:
class circle
{
public:
double radius;
}
Now you can use it like so:
circle c;
c.radius = 10.0;
However, you shouldn't make such decisions based only on how you'd like to write code (or how you might write it in C#). I recommend that you think about the following points for every member:
Does it make sense to set the member directly? Perhaps the member is just a private part of the object's state and is affected by other member functions. Consider the following example, where the interface you really want to expose is just a function that increases the size of the circle:
class circle
{
public:
circle(double radius, double delta = 1.0)
: radius(radius), delta(delta) { }
double increaseSize() {
radius += delta;
return radius;
}
private:
double radius;
double delta;
}
Do you need to enforce an invariant? Consider, perhaps, that you have decided that there can be no such thing as a circle with a negative radius. You might want to enforce this by having a member function that checks the given new radius to make sure it is greater than 0.
Do you want to provide some different representation of the member through the interface? Maybe you want the circle to keep its radius as a member, but the only thing any clients will want to know is its area. You could make radius private and then provide a getArea function like so:
class circle
{
public:
circle(double radius)
: radius(radius) { }
double getArea() {
return PI * radius * radius;
}
private:
double radius;
}
It's possible that none of the above points apply at the moment, but may do at some point in the future. If you have this foresight, it might be best to provide getter and setter functions now. This ensures that the interface that clients use won't change later on.
As an alternative naming scheme for your getters and setters, it's quite common to simply have two overloaded functions - one for setting and one for getting - like so:
class circle
{
public:
void radius(double); // Set the radius
double radius(); // Get the radius
private:
double radius;
}
In answer to the first question: so your object is encapsulated and you can deal with changed internal representation or the need to modify/update when radius changes.
To the second: you can't. C++ does not support object getters and setters like that.
(It is actually just about possible, but it really isn't worth it)
There's various reasons to do this with setters and getters;
They provide better encapsulation; the actual values of a class' internal variables should be the responsibility of the class to set/get, not that of a user of an instance of a class. But there's different schools of thought on this subject.
They leave open the possibility of doing more than just setting/getting a value upon calling a setter/getter. For example,
class circle
{
double _radius;
double _perimeter;
public:
double getRadius() {return _radius;}
void setRadius(double r) {
_radius = r;
_perimeter = 2*M_PI*r;
}
};
Well, the way you indicate can be accomplshed simply by making radius a public variable :) However, consider this alternative approach:
class circle
{
private:
double _radius;
public:
const double &radius;
circle(double R)
: radius(R)
: radius(_radius)
{}
void setRadius(double r) {
_radius = r;
}
};
which would then be used like this:
cout << a.radius; // works
a.radius = 3.2; // produces error
a.setRadius(3.2); // works
This approach has the benefit of concise, possibly more intuitive getters (i.e., use the actual variable name), more concise code (no need for countless virtually empty getters), and possibly even increased performance (a call to a getter function is slower than directly accessing a variable, although this depends on compiler optimization settings).
There's benefits and drawbacks to all methods mentioned here. In the end, it's really all up to the preferences of your team/employer.
You use a getter and setter to achieve better encapsulation and to make it possible to change the underlying implementation in easier way.
About the second question: you can not do that. You will have to write a getter and setter method.
Well there is the initializer way:
OCD::OCD ( ) : _number( 0 )
{
}
and the in body constructor way:
OCD::OCD ( size_t initial_value )
{
_number = initial_value;
}
to access them inside the class instance just use the variable name:
_number = value;
but if you have an global, local or argument variable with the same name, you can be specific like this:
this->_number = value;
then from outside of the instance you can call it thus:
// (that is if _number was public)
std::cout << "ocd2._number => " << ocd2._number << std::endl;
std::cout << "ocd3p->_number => " << ocd3p->_number << std::endl;
same goes for methods:
std::cout << "ocd2.get( ) => " << ocd2.get() << std::endl;
std::cout << "ocd3p->get( ) => " << ocd3p->get() << std::endl;
see my gist on the subject: https://gist.github.com/LaughingSun/7d2330ccff0777bec106
I am currently working on Chapter 7 in the book "Starting Out With C++ Early Objects" by the Pearson printing company.
I am unable to understand the function of the variable 'r' in this class declaration:
class Circle
{ private:
double radius;
public:
void setRadius(double r)
{ radius = r; }
double getArea()
{ return 3.14 * pow(radius, 2); }
};
Why can't I just write the 'radius' variable like this?
class Circle
{ private:
double radius;
double getArea()
{ return 3.14 * pow(radius, 2); }
};
I don't understand the function of the
public:
void setRadius(double r)
{ radius = r; }
Statement.
The technical reason is "because radius is private, hence inaccessible from outside the class".
So a change to radius must be some how managed by a public member function like SetRadius.
If the question now becomes "why designers did it that way, and did not simple make radius public?", well ... this is a never ending debate about how a proper object-oriented design should be an what has to be public and what not inside an object.
Traditional OOP school tends to make all data "private" and access or modify them through a variety of function to enforce what they call "encapsulation", and to have life easier in case the interface need to be extended to support eventual callbacks or events.
In this trivial simple case, well... all looks like a waste of energy (and without proper compiler optimization IS a waste of energy! In true physical sense). But may be they needed a uniform interface with something else.
As the functional behaviour of private is explained in other answers, directly accesing a private member outside the class will give you a compile-time error.
If you are asking why do we use setter functions and make some members private is a matter of design. For example; if you need the radius to be always positive number, you can write the set function as;
void setRadius(double r)
{
if(radius >= 0)
radius = r;
else
radius = 0;
}
Thus, you will have control over the values of the member when they are tried to be modified outside the class.
The radius is private. Without that function, you would not be able to set the radius from outside of the class. In order for the class to be useful, you would most likely want to be able to create objects of the type Circle and set their radius. Thus, you need some type of function in order to set that radius.
The easiest and most reasonable way to solve this is to supply a public member function inside the class Circle itself.
This can most easily be done using a setter, such as what you have shown. This allows you to set, and later change, the radius.
void SetRadius(float r)
{
radius = r;
}
You could also supply an extra argument to the constructor to ensure that a Circle always has its radius initialized with a user-supplied value, or at least set a default value in the declaration of radius (in C++11).
The concept of public private that no one can access the private variables just the class methods, and you can only access the public methods from your main function so ,the function setRadius is responsible to set the private variable of the radius
public:
void setRadius(double r)
{ radius = r; }
because the radius is a private variable so you have to create a public function inside the class to set that variable so you can set the radius when you create Circle object by :
this will work to set the radius in the main
Circle * test = new Circle;
test.setRadius(7);
but if you tried to set the radius directly by :
Circle * test = new Circle;
test.radius = 7;
it will crash the program Cannot access class private method
Consider the following code:
class Rectangle
{
public:
// Constructors
Rectangle(){ init(0,0); }
Rectangle(int h, int w){ init(h,w); }
// Methods
void init(int h, int w)
{
_h = h;
_w = w;
}
// Getters / Setters
double get_h(void){ return _h; }
double get_w(void){ return _w; }
void set_h(double h){ _h = h; }
void set_w(double w){ _w = w; }
std::string get_name(void){ return _name; }
void set_name(std::string name){ _name = name; }
private:
// Private Members
int _h, _w;
std::string _name;
};
class House
{
public:
// <BEGIN PASSTHROUGHS>
std::string get_b_name(void){ return _base.get_name() };
std::string get_r_name(void){ return _roof.get_name() };
void set_b_name(std::string name){ _base.set_name(name); }
void set_r_name(std::string name){ _roof.set_name(name); }
// </END PASSTHROUGHS>
private:
// Private Members
Rectangle _base;
Triangle _roof;
};
This code works fine.
My question deals with the "passthrough" functions in the House class, enclosed by the PASSTHROUGHS tags. Is this the best way to do this? The arguments and return types will always match and there is no "intelligence" in these passthrough functions other than to make things cleaner and more straightforward.
My instinct would be something like one of the following:
get_b_name = _base.get_name;
// OR
std::string get_b_name(void) = _base.get_name;
... but neither seem to work unfortunately and it was only wishful thinking in the first place. If there are no easier options, telling me that is fine too. Thanks!
The problem, I think, is conceptual. Your design is quite un-object oriented in that the house does not represent an entity, but rather provides a bit of glue around the components. From that standpoint, it would make more sense to provide accessors to the elements, rather than pass-through functions:
class House {
Rectangle _base;
Triangle _roof;
public:
const Rectangle& base() const {
return _base;
}
const Triangle& roof() const {
return _roof;
}
};
I imagine that this is just a toy example, but the same reasoning applies: a class should represent an entity on which a set of operations are preformed, in some cases those operations might be implemented in terms of internal subobjects, but they are still operations on the type, and how they are gathered is an implementation detail.
Consider:
class House {
Thermostat t;
public:
int temperature() const {
return t.temperature();
}
};
From the user point of view the house has a temperature that can be read, and in this particular implementation, it is read from a thermostat that is a member. But that is an implementation detail. You might want to later install more thermostats in the house and substitute the single reading by an average of the readings, but that will not change the fact that the entity House (in this model) has a temperature.
That is, you should not be thinking in implementing pass-through functions, but rather on implementing features of the type. If the implementation happens to be a single forwarding to an internal method, that is fine.
But if the type contains internal members and it makes sense to access properties of the members, consider that it might be that you actual type should just provide access to its internal members. Consider that you want to move a piano inside the house, then you might just provide access to the door member and let the user check:
class House {
Door d;
public:
Door const & door() const {
return d;
}
};
bool can_enter_piano( House const & h, Piano const & p ) {
return h.door().width() > p.size();
}
There is no need to provide House::get_door_width(), and House::get_door_color() so that you can describe the entrance to a friend, and House::get_door_handle() so that they can know when they arrive...
That's possibly because your design is contradictory. Why on earth would you make a public member variable, then write a function that just forwards to one of that variable's functions? As a user of your class, I'd just call the function on the public variable myself. You're just confusing me by providing two ways to do the same thing. Or write getters and setters for a Rectangle class? That thing is just a bunch of variables, and doesn't need any getters and setters. You're not exactly going to inherit from it, and you can't really change the internal logic and maintain the same semantics, so it's very meaningless to not just make the variables public.
The Rectangle class needs a very healthy dose of YAGNI, and the House class just needs to look at itself again. The fact that there's no intelligence in the "passthrough" methods should be a huge alarm bell telling you that they are quite probably redundant and not helpful- especially since you can't change the public variables without breaking your interface anyway, it's not like the getters and setters are decreasing coupling or anything like that.
Methods should perform logic, or in the very least case, exist where logic might have to be done.