Is there a way in C++ to enforce the use of getters or setters WITHIN the class?
class C{
private:
int x; // should only be Changed by setX();
private:
setX(int i){
(...) // enforce some complicated invariantes
x = i;
};
m(){
x = 5; // should not not allowed
}
}
The only thing that comes to my mind is to put all the super-private members as private variables into an abstract base class with protected getters/setters.
But that doesn't sound like good practice.
Are there any more common ways or conventions to ensure, that everyone uses the setters?
(My purpose:
If the class gets bigger i find it hard to remember what variables carry invariants with them. And currently before setting any variable I search, whether I created a getter or setter (to find out whether i have to consider invariants). But i want to get rid of this unprofessional searching-each-time.)
You can take advantage of composition like this:
class C_int
{
public:
void setX(int i)
{
/* enforce invariants */
x = i;
}
private:
int x;
};
class C
{
pulbic:
void m()
{
x.setX(5);
// x.x = 5; // Won't compile.
}
private:
C_int x;
};
But I find it odd that this is an actual problem for you, IMHO. You're the writer of the C class and its members. You have control over how the x variable is read/written, and x is not part of the public interface of the class. While it is true that other people (e.g. maintainers) can write code that breaks invariants in the future, unit tests should be able to cover those cases.
a) favor accessors throughout your codebase for consistency. then you will more easily spot direct accesses to members. if you need special accessors, then create special methods:
void setFoo(const t_foo& foo) {
assert(foo.isValid());
this->d_foo = foo;
}
void invalidateFoo() {
this->d_foo = t_foo::InvalidFoo();
}
b) to get to an answer: i'll often create an inner class (temporarily in some cases):
class C {
class t_inner {
public:
/* ... */
void setX(int arg) {
/* enforce some complicated invariants... */
this->x = arg;
}
const int& getX() const {
/* ... */
return this->x;
}
private:
int x;
};
public:
/* ... */
private:
/* ... */
void m() {
this->inner().setX(5);
}
private:
t_inner d_inner;
};
The clean answer is No. There is no language feature for that; you can do some variation to achieve it, but that will clutter your code.
In Visual C++, __declspec( property ) can be used to have this feature:
__declspec(property(put=setFunction, get=getFunction)) data-type property-name;
See this article
Related
aI find this question to be interesting for other people, too. So I choose this one to finally ask my first question on Stack Overflow. A minimal description of the situation is the following:
class A {
public:
Type_m_first m_first;
Type_m_second m_second;
}
class B { // shoud be const on a.m_first
private:
A& a;
public:
B(A& a_) : a(a_) {};
}
EDIT: Setting the members of A to be private and using getters and setters is not a solution to my problem. However, I hope for a solution as easy as this, because I well might miss something easy, due to my lack of experience in programming.
Now, I need any yet-to-be-implemented method of B to have only const access to A.m_first while having non-const access to A.m_second, and similarly, I need any other code using something of type B having the same access restrictions, when accessing B.a. Of course, this is impossible (at least from my humble point of view).
Nevertheless, my question is:
How is it possible to enforce on the class B such a const-restriction of the access to a non-const member variable?
EDIT With private m_first and m_second and a getters and setters for m_first and m_second the situation would be the same. Then the questions is: How to restrict the access of B to the const getter of m_first, and deny B the access to the setter of m_first, while at the same time allow B to use the setter of m_second?
The above is the question. However, without the following context this question might be incomplete as it illustrates the significance of the question. The actual situation I am facing is the following:
class A {
public:
Type_m_first m_first;
Type_m_second m_second;
public:
// A lot of code.
private:
// A lot of code.
}
class B { // shoud be const on a.m_first
private:
A& a;
public:
B(A& a_) : a(a_) {};
private:
// A lot of code, that I am supposed to move from somewhere else to here
// or write myself.
public:
// A lot of code, that I am supposed to move from somewhere else to here
// or write myself.
}
class C { // shoud be const on a.m_second
private:
A& a;
public:
C(A& a_) : a(a_) {};
private:
// A lot of code, that I am supposed to move from somewhere else to here
// or write myself.
public:
// A lot of code, that I am supposed to move from somewhere else to here
// or write myself.
}
/*
* A lot of other Code that is supposed to work with A, B and C. The following three
* functions serve as an example. As you see, everything is manipulating essentially
* the same data from a.
*/
void f(A& a, /* other args */ ) { /* ... */ };
void g(B& b, /* other args */ ) { /* ... */ }; // shoud be const on b.a.m_first by design
int h(C& c, /* other args */ ) { /* ... */ }; // shoud be const on c.a.m_second by design
int main() {
A a;
B b = B(a);
C c = C(a);
f(a, /* other args */ );
g(b, /* other args */ );
return h(c, /* other args */ );
}
Again, I need any yet-to-be-implemented method of B to have only const access to A.m_first while having non-const access to A.m_second. However, for the class C I need this to be exactly the other way round: I need any yet-to-be-implemented method of C to have only const access to A.m_second while having non-const access to A.m_first. Similarily, any Code using something of type B and C should have corresponding access-restrictions.
Again, of course, the question arises: Why do I need this? And the answer is, that the logical structure of the algorithm would be enforced by such a design. Making everything public is only in so far a concern, as neglecting the logical structure by accident leads to hard to find bugs in the code and due to the complexity of the code it is hard to keep track of such restrictions which are not enforced by design.
The best solution I had come up with - but did not yet implement -, is copying the code to two wrapper classes:
class A_first {
public:
const Type_m_first& m_first;
Type_m_second& m_second;
A_first(A&) ; m_first(const A.m_first), m_second(A.m_second) {};
public:
// Same code as before.
protected:
// Same code as before.
private:
// Same code as before.
}
class A_second {
public:
Type_m_first& m_first;
const Type_m_second& m_second;
A_first(A&) ; m_first(A.m_first), m_second(const A.m_second) {};
public:
// Same code as before.
protected:
// Same code as before.
private:
// Same code as before.
}
This is not desirabe, because the code changes a lot over time, and keeping track of the changes in three classes is error-prone. My question is, what to do in such a situation?
I'm highly in doubt whether this is worth the effort, but this might suit your needs:
Instead of passing B and C a reference to A (which would grant them unlimited access to A, which is your whole problem if I understand correctly), only pass them the accessors to the two members. This could look like so:
class B {
private:
std::function<Type_m_first const&()> getConstFirst;
std::function<Type_m_second&()> getNonConstSecond;
public:
B(std::function<Type_m_first const&()> f1, std::function<Type_m_second&()> f2)
: getConstFirst(std::move(f1)), getNonConstSecond(std::move(f2)) {};
void someMethod() {
getConstFirst() = abc; // this won't compile
getNonConstSecond() = xyz; // this will
}
}
Analogous implementation for C.
Then, pass functions to the c'tors of B and C using lambdas that capture the instance of A by reference:
A a;
B b = B(
[&a]() -> auto const& { return a.m_first; },
[&a]() -> auto& { return a.m_second; }
);
C c = C(
[&a]() -> auto& { return a.m_first; },
[&a]() -> auto const& { return a.m_second; }
);
Ok, I have to confess, I just skimmed reading you question, so I might have missed some details. But wouldn't a getter that returns a const reference be what you need?
class A {
private:
Type_m_first m_first;
public:
const Type_m_first & get_m_first() const { return m_first; }
Type_m_second m_second;
}
Here only members of A might modify m_first directly. Everybody else must use the the const reference obtained by get_m_first.
I am working on translating some Java code to C++.
In Java, we can create object from anonymous class, using existing constructor, and overriding some methods. E.g.,
class X {
public X(int value) {...}
public void work() {....}
}
void main(String[] args) {
X entity = new X(5) {
public void work() { /* Something else */ }
};
}
In C++, I know I can create anonymous class as following:
class X {
public:
virtual void work() {...}
}
class : public X {
public:
void work() {....}
} obj;
But C++ does not allow constructor in anonymous class, and it does not allow extending from object (e.g., the new X(5) { public void work() {} } like what Java allows.
How can I write similar code in C++?
Update 03/07/2020 05:27 CDT
More context about the problem I am working on. I am implementing aggregation function of a in-memory SQL database, and use the following class to represent an aggregation field:
class AggField {
public:
AggField(int colIndex);
virtual void reduce(DataRow&) = 0;
virtual double output() = 0;
}
For each type of aggregation, e.g., avg, min/max and sum, I have a subclass. For example
class Avg : public AggField {
private:
int counter_;
double value_;
public:
Avg(int colIndex) : AggField(colIndex), counter_(0), value_(0) {};
void reduce(DataRow&) override {
value_ += row[colIndex].doubleval();
counter_ += 1;
}
double output() override {
return value_ / counter_;
}
}
class Sum : public AggField {
.....
}
When processing a table, I will write the following
Table table = ...
auto agg_opr = Agg({
new Sum(0),
new Avg(1)
});
agg_opr.agg(table);
which does a sum on column 0, and average on column 1.
Sometimes(rare) I need to process more than one input columns. For example, doing a sum of col1 * (1 + col2). Instead of creating a new subclass of AggField, I would like to write something similar to:
Table table = ...
auto agg_opr = Agg({
new Sum(0) {
void reduce(DataRow& row) {
value_ += row[0].doubleval() * (1 + row[1].doubleval());
}
},
new Avg(1),
new Max(1)
});
agg_opr.agg(table);
I can't say that I know how to write idiomatic Java but I'm guessing that this pattern in Java is an alternative to lambdas in C++. I remember using an anonymous class long ago when I was working with Swing. I think I did something like this:
button.addMouseListener(new MouseAdapter() {
public void mouseClicked(MouseEvent e) {
// ...
}
});
This is sugar for inheriting from a class and overriding a method. Doing precisely that is not really how I would like to attach an event listener in C++. I'd prefer to do this:
button.addMouseClickListener([](const MouseEvent &e) {
// ...
});
In the case of an event listener, the closure would need to be stored in a std::function or something similar. This has roughly the same performance as a virtual call.
I don't really know much about where you're using this class but if you need to store it aside (like an event listener or something) then declaring the class the long way or using std::function are probably the cleanest options. If you don't need to store it aside (like a policy for an algorithm) then you could use a functor. Of course, you can store aside a functor but it takes a bit of template machinery and probably isn't worth it (although it does have more flexibility).
struct MyPolicy {
int doSomething(int i) {
return i * 3;
}
double getSomething() const {
return d;
}
double d;
};
template <typename Policy>
void algorithm(Policy policy) {
// use policy.doSomething and policy.getSomething...
}
Using a functor or lambda with a template has much better performance than using virtual functions. In the above example, the compiler can and probably will inline the calls to doSomething and getSomething. This isn't possible with virtual functions.
If I knew more about the real problem that you're trying to solve then I might be able to write a more specific and helpful answer.
After seeing the updated question I have another suggestion. That would be to create a subclass for custom aggregate functions. Of course, this has plenty of limitations.
template <typename Func>
class CustomAgg : public AggField {
public:
CustomAgg(int colIndex, Func func)
: AggField{colIndex}, func{func} {}
void reduce(DataRow &row) override {
func(value, row);
}
double output() override {
return value;
}
private:
Func func;
double value = 0.0;
// could add a `count` member if you want
};
auto agg_opr = Agg({
new CustomAgg{0, [](double &value, DataRow &row) {
value += row[0].doubleval() * (1 + row[1].doubleval());
}},
new Avg(1),
new Max(1)
});
Honestly, I think the best solution for you is to not try to implement a Java feature in C++. I mean, if you need to handle multiple columns in some specific operation then create a class just for that. Don't take any shortcuts. Give it a name even though you might only use it in one place.
C++ has anonymous namespaces, which effectively lets you create classes that are completely isolated to the translation units they're declared in:
namespace {
class X {
public:
X(int) { /* ... */ } // Ok to have a constructor
void work();
};
}
int main(int argc, char **argv)
{
X entity{5};
// ...
}
Now, you have to declare them in global scope, you can't declare them in inner scope. You'll also need to give these classes normal names that you can reference them by in the same translation unit; but for all practical purposes they're completely anonymous and inaccessible from other translation units. Another translation unit can declare its own anonymous class "X", and there won't be any conflicts.
You can use anonymous classes in all other normal ways, subclass them, etc... You can create an anonymous class that's a subclass of a regular, non-anonymous class, which gets you pretty close to what Java does, here.
Some compilers also offer extensions where you can declare classes in inner scopes, and they'll also work very similar to anonymous namespaces, but that's going to be a compiler-specific extension.
Let's say that I have this class in C++:
class ExampleClass{
private:
int example_var;
public:
void exampleMethod(){
example_var = other_value; // other value will be always different
}
}
How can I unit test exampleMethod()? I would like to do something like this:
void testExampleMethod(){
ExampleClass obj;
int before_call_value = obj.example_var;
obj.exampleMethod();
int after_call_value = obj.example_var;
ASSERT_NOT_EQUALS(before_call_value, after_call_value);
}
But example_var is private.
So, what is the right way to do this unit test? How can I test if a private example_var has changed?
Short answer: Dont do it.
Your test should test against the public interface only. Let me try to explain with some code:
class Adder {
int a,b;
public:
Adder() : a(0),b(0) {}
void set(int x,int y) { a=x;b=y; }
int get() { return a+b; }
};
and a test (assume for a moment we had access to a and b):
void testAdder(){
Adder add;
int a = 1;
int b = 2;
add.set(a,b);
ASSERT_EQUALS(add.a,a);
ASSERT_EQUALS(add.b,b);
ASSERT_EQUALS(add.get(),a+b);
}
Suppose you already distributed the code and someone is using it. He would like to continue using it but complains about too much memory consumption. It is straightforward to fix this issue while keeping the same public interface:
class Adder {
int c;
public:
Adder() : c(0) {}
void set(int x,int y) { c = x+y; }
int get() { return c; }
};
That was easy, but the test will fail :(
Conclusion: Testing private implementation details defeats the purpose of testing, because each time you modify the code it is likely that you also have to "fix" the test.
It is bad approach to test private variable/methods. But if you need there are a lot of options:
You can make Your test class as friend of ExampleClass
You can grab information using moc object
If you want to access example_val, there are one of two things you can do. The first is by making testExampleMethod() a friend method, as follows:
class ExampleClass{
private:
int example_var;
public:
void exampleMethod(){
example_var = other_value; // other value will be always different
}
friend void testExampleMethod(); //Now you can use the function as is.
}
On the other hand, you could just add a getter to your ExampleClass to access the variable, such as the following:
class ExampleClass{
private:
int example_var;
public:
void exampleMethod(){
example_var = other_value; // other value will be always different
}
inline void getExampleVar() const { return example_var; }
}
And then change testExampleMethod() to:
void testExampleMethod(){
ExampleClass obj;
int before_call_value = obj.getExampleVar();
obj.exampleMethod();
int after_call_value = obj.getExampleVar();
ASSERT_NOT_EQUALS(before_call_value, after_call_value);
}
I would honestly use the second method, since accessing a class's private variables is generally not recommended.
You just simply implement get function for that private variable you want to get.
class ExampleClass{
private:
int example_var;
public:
void exampleMethod(){
example_var = other_value; // other value will be always different
}
int GetExampleVar(){
return example_var;
}
}
And call it like
void testExampleMethod(){
ExampleClass obj;
int before_call_value = obj.GetExampleVar();
obj.exampleMethod();
int after_call_value = obj.GetExampleVar();
ASSERT_NOT_EQUALS(before_call_value, after_call_value);
}
Or make testExampleMethod friend function (friend function can access private variables of friend class even if its not its method).
class ExampleClass{
private:
int example_var;
public:
void exampleMethod(){
example_var = other_value; // other value will be always different
}
friend void testExampleMethod();
}
In my opinion first example would be more suitable, but if you cannot modify ExampleClass, you can turn off access control for gcc -- -fno-access-control.
A few options I can think of:
1) Make the test code a friend of the class. That way it can access the private members.
2) Add a getter to the class that's under a #ifdef Testing directive that only gets defined when building the test version (or put public: under that macro and a private: in the #else branch).
3) #define private public when building the test (no, not really).
4) Use gcc's -fno-access-control flag when building the version to test, so that everything is public (if you are using gcc that is).
5) Just give up testing externally from the class and instead add relevant static_asserts/asserts to the class itself to test invariants.
6) Don't. Just stick to testing the public interface.
Hope that helps :-)
This is a question to find out the better programming practice:
In C++, say I have two classes one of which is a member class of the other, e.g.,
class SomeClass {
public:
MemberClass member_class;
void set_num(double num_) { num_ = num; }
double num() {return num_; }
private:
double num_;
}
I want the member class to have access to the member functions of the outer class, e.g.,
class MemberClass {
public:
PrintSquare() {
cout << num() * num() << endl;
}
}
I am trying to achieve this in order to reduce the number of function arguments I am passing all around the program.
The most common (and IMHO proper) way to solve this problem is, introducing an interface (or even more interfaces focusing on particular sets of method features) for the containing class, and pass that one to the 'inner' class member on construction:
struct Interface {
virtual void set_num(double num_) = 0;
virtual double num() const = 0;
virtual ~Interface() {}
};
class MemberClass {
public:
MemberClass(Interface& interface) : interface_(interface) {}
PrintSquare() {
cout << interface_.num() * interface_.num() << endl;
}
private:
Interface& interface_;
};
class SomeClass : public Interface {
public:
MemberClass member_class;
SomeClass() : member_class(*this), num_() {}
virtual void set_num(double num_) { num_ = num; }
virtual double num() const { return num_; }
virtual SomeClass() {}
private:
double num_;
};
NOTE:
Calling methods of the interface though will fail (with a runtime exception), when called from the MemberClass constructor definition.
Although the answer by Kerrek is very interesting, he himself already states this normally isn't the way to go. Common practice would be to make the inner class nested in the outer one, if possible. If the inner one needs access to the outer one in such a way that a nested connection seems natural, this would be the way to go. Construction of an Inner object would then need a reference to the object it is a member from, in order to be able to call functions on its parent:
class Outer
{
class Inner
{
Outer &parent; // consider constness
public:
Inner(Outer &_parent); //initializes the parent-reference
void innerFunction(); // can call members of parent
};
Inner inner;
public:
Outer(): inner(*this) { ... } // initialize inner
};
Depending on the standard you're using, the innerFunction now has access to all public members of Outer (C++03), or even all private members as well (C++11). See also this topic:
C++ nested classes - inner/outer relationship
EDIT: Did a quick test, and my compiler (gcc 4.7.2) also allows access to private members with older standards. Maybe someone could comment on this...
If your classes are all standard-layout, then you can take advantage of some layout guarantees that C++ makes, namely that a on object of standard layout type may be treated as if it were its own first member. For instance:
struct Foo
{
int a;
void barely_legal();
};
struct Bar
{
Foo x;
int y;
};
#include <type_traits>
void Foo::barely_legal()
{
static_assert(std::is_standard_layout<Foo>::value, "Foo");
static_assert(std::is_standard_layout<Bar>::value, "Bar");
Bar * p = reinterpret_cast<Bar *>(this);
++p->y;
}
This is unusual at best and cruel at worst, so please don't write code like this unless you have a really good reason to do so. (I know people who do have reason to do this, but I don't turn my back towards them.)
so I've been learning C++ for a few weeks now but I'm having a bit of trouble:
Class Tool
{
public:
Tool(const float maxCarried = 1):maxAmountCarried(maxCarried){}
virtual void Use() = 0;
/* ... */
}
Class CuttingTool: public Tool
{
public:
CuttingTool(const float maxCarried):Tool(maxCarried){}
virtual void Use(){ /* ... */ }
/* ... */
}
Class Saw: public CuttingTool
{
public:
Saw(const float maxCarried):CuttingTool(1){}
virtual void Use(){ /* ... */ }
/* ... */
}
Class Scissors: public Fruit
{
public:
Scissors(const float maxCarried):CuttingTool(2){}
virtual void Use(){ /* ... */ }
/* ... */
}
A few things to note:
I'm trying to make a big database of 'Tools'.
I never change the value of 'maxAmountCarried' so I've set it to const.
Memory/performance is important because I have a huge vector of Tools.
The problem lies within the fact that I have to keep writing:
ClassName(const float maxCarried):BaseClass(maxCarried){}
It's really tedious, moreover, I worry that if I were to add a new const value I would have to repeat the process all over again (problem when you have 50 classes inheriting from Food :S).
I feel as though I've designed this poorly. Is there a way to avoid repeating the same line of code over and over again or do I just have to suck it up and deal with it?
Thanks in advance.
If your only concern is the repeating initialization list you could use a macro like this:
#define DEFAULT_CONSTRUCTOR(Child, Parent) Child(float max) : Parent(max) {}
and use it like so:
class Saw : public CuttingTool
{
public:
DEFAULT_CONSTRUCTOR(Saw, CuttingTool) {}
};
You can extend this idea and do something like that:
#define BEGIN_CLASS(Child, Parent) class Child : public Parent { \
public: \
Child(float max) : Parent(max) {}
#define END_CLASS };
and declare your classes:
BEGIN_CLASS(Scissors, Tool)
void cut_through_paper() {} // specific method for scissors
END_CLASS
Note that there is no point of using const float as a parameter since you can't change arguments passed by value anyway. You might however want to use const float& to pass an argument by reference, and that will make sense if size of float is bigger than the size of a pointer in your specific platform.
If you never change you max value, you can make it static and share it between all tool instances:
class Tool
{
protected:
static const float _max;
public:
Tool() {}
};
const float Tool::_max = 0;
If you'd like to be able to change max value only once (say at the begining of your program, you can add a static function:
static void globalMax(float max) { Tool::_max = max; }
and use it where appropriate:
int main() {
Tool::globalMax(5);
...
...
}
Note that you should remove the const from the _max declaration.
Finally, if performance is an issue, you probably need to rethink your design and maybe go with something else (templates maybe?)
Hope that helps!