I am trying to create a conversion operator that would be explicit by default, except for some designated classes.
More precisely, I have a relatively simple class template whose instances should be convertible to some other type (int throughout this question, for simplicity). However, I want this conversion to be explicit by default, but still allow it to be implicit for one other class, namely the class passed as template argument. Without this last part, this is what it would look like:
template<typename T>
class A {
public:
A(int i) : i(i) {}
explicit operator int() const {
return i;
}
private:
int i;
};
Now, I want to be able to write something like A a(2); int i = a; inside the methods of T (which is supposed to be a class).
My first idea was to make use of friend declarations and declare a private overload of the conversion operator. However, overloading based solely on explicit isn't allowed. So I tried using const for that instead, and it worked:
template<typename T>
class A {
public:
A(int i) : i(i) {}
explicit operator int() { // Public non-const
return i;
}
private:
int i;
operator int() const { // Private const
return i;
}
friend T;
};
... until it doesn't. This works only when using non-const As, and while I don't plan on using const As, I still would like it to work in all cases. Note that if the public overload is const and the private one isn't, this works only using const As.
Here is a demo showing in which cases it works or doesn't.
I have thought of using volatile (demo), and while it makes it better, it still leads to the same problem: it only works when using non-volatile As.
Is there a better way to do that? More generally, is there a way to solve the problem in the very first sentence?
There is apparently no satisfying solution. The volatile option seems to be the most practical, and although it doesn't quite work with volatile As, an additional const_cast solves that problem.
template<typename T>
class A {
public:
A(int i) : i(i) {}
explicit operator int() const {
return i;
}
private:
int i;
operator int() const volatile {
return static_cast<int>(const_cast<A const&>(*this));
// or just
// return i;
}
friend T;
};
Demo
As Sneftel stated in the comments, access permissions tend to be granted on a pull basis (using) rather than a push basis. That might be why the language does not provide a way to change conversion semantics depending on the class or block performing the conversions.
Related
I've been working on some class hierarchy with a goal to have a collection of classes that encapsulate primitive types (AdvancedInt, AdvanceDouble, etc.) and give them some additional behavior when accessing their underlaying values, through conversion operator and assignment operator. I can't do this with getters and setter as I can't change the original code and the way it access them, so my only choice is operator overloading.
The problem I ran into is with the templated class that defines the conversion operator which gives me a compiler error.
Here is the code that illustrates the problem
#include <string>
class Base {
public:
Base() = delete;
Base(std::string s) : name(s) {
//Some extra logic
}
~Base() {
//More custom logic
}
virtual std::string get_name() const final { //Final on purpose
return name;
}
private:
const std::string name;
};
template <typename T, class C> class Serializable :public Base { //Poor man's interface (but not quite)
public:
Serializable() = delete;
Serializable(std::string name) : Base(name) {
}
operator T() const {
//Some extra 'getter' logic
return value;
}
C& operator=(const T& val) {
//Some extra 'setter' logic
value = val;
return (C&)*this;
}
virtual void serialize() = 0; //This has to be pure virtual
private:
T value;
};
class AdvancedInt final : public Serializable<int, AdvancedInt> { //This is the actual complete class
public:
AdvancedInt(std::string name) : Serializable(name) {
//Nothing here, but needed for the special constructor logic from AbstractBase
}
void serialize() override {
//Some logic here
}
};
int main()
{
AdvancedInt adv{"foo"};
int calc = adv;
calc += 7;
adv = calc; //error C2679 (msvc) | binary '=': no operator found which takes a right-hand operand of type 'int' (or there is no acceptable conversion)
return 0;
}
Now aside from the (probably) questionable practice of passing AdvancedInt to the template of its own base class and it subsequently knowing that it's part of some derived class and implementing its logic (although any feedback on this is welcome), my main question is, what am I doing wrong here?
The C& operator=(const T& val) compiles fine when defined as pure virtual, but that enforces the implementation to be in the derived class, and when implemented there with T and C replaced by their corresponding types it works just fine, so the signature is logically sound, but probably not in the correct place(?). From what I've found on cppreference.com, the simple assignment operator is the only assignment operator that cannot be defined outside of class definition. Is this the reason why this code doesn't compile? And if so, is declaring it as pure virtual a way to go?
With adv = calc we look for operator= from AdvancedInt and found (implicit):
AdvancedInt& operator=(const AdvancedInt&);
AdvancedInt& operator=(AdvancedInt&&);
and look-up stops there.
Adding:
using Serializable<int, AdvancedInt>::operator=;
would allow to consider also that overload.
And that fixes your issue.
Demo.
Suppose I have a class with some constant member:
class MyClass {
public:
MyClass(int a) : a(a) {
}
MyClass() : MyClass(0) {
}
~MyClass() {
}
const int a;
};
Now I want to store an instance of MyClass somewhere, e.g. as a global variable or as an attribute of another object.
MyClass var;
Later, I want to assign a value to var:
var = MyClass(5);
Obviously, this does not work, because the assign operator is invoked, which does not exist by default, because MyClass has a const attribute. So far so good.
My question is, how can I assign a value to var anyway? After all, var itself is not declared to be a constant.
My thoughts so far
I know that the problem does not exist if I use a pointer for var:
MyClass *var;
var = new MyClass(5);
However, I would not like to use a pointer for convenience reasons.
A potential solution is to overwrite the memory with placement new:
template<class T, class... Args>
T &emplaceVar(T &myVar, Args&&... args) {
myVar.~T(); // free internal memory
return *new (&myVar) T(args...);
}
emplaceVar(var, 5);
This would solve the problem, but I am not sure if this may cause memory leaks or any other issues I have not thought of due to my lack of experience in c++. Furthermore, I would have thought there must be an easier way. Is there?
const members are problematic in general for the very reason you discovered.
The much simpler alternative is to make the member private and take care to provide no means to modify it from outside the class:
class MyClass {
public:
MyClass(int a) : a(a) {
}
MyClass() : MyClass(0) {
}
~MyClass() {
}
private:
int a;
};
I did not add a getter yet, because you say access via myObject.a is a hard requirement. Enabling this requires a bit of boilerplate, but it is much less hacky than modifiying something that must not be modified:
class MyClass {
public:
struct property {
const int& value;
operator int(){ return value;}
property(const property&) = delete;
};
MyClass(int a = 0) : value(a) {}
private:
int value;
public:
property a{value};
};
int main(){
MyClass myObject{5};
int x = myObject.a;
//myObject.a = 42; // error
//auto y = myObject.a; // unexpected type :/
}
Live Demo
Drawback is that it does not play well with auto. If by any means you can accept myObject.a() I would suggest to use that and keep it simple.
how can I assign a value to var anyway?
You can do that with a user-defined assignment operator:
class MyClass {
public:
MyClass &operator=(const MyClass &o)
{
// Implement your assignment here
return *this;
}
// ...
};
Your assignment operator can do anything that any operator= overload can. The only thing it can't do is assign anything to its const class member. That's because it's constant.
If a class does not have user-defined assignment operator, the default assignment operator assigns each member of the assigned-to object from the same member of the assigned-from object. However the default assignment operator is deleted from any class that has a const member, because that, of course, is no longer possible.
In your user-defined operator you can do whatever it means to assign one of these objects from another one. The only thing it can't do is the same thing any other class method can't do: modify a const class member.
You mentioned manual invocation of a destructor and placement new. That's possible, provided that all requisite requirements are met and undefined behavior is carefully avoided. However, technically, it wouldn't be assignment, but rather a manual destruction and construction of another object.
I want to create interface like
class Scalar {
public:
Scalar() {}
virtual ~Scalar() {}
//virtual members operators
virtual Scalar& operator+() const = 0;
virtual const Scalar operator-() const;
virtual Scalar& operator=() = 0;
virtual Scalar& operator+=() = 0;
//...
};
I intend also to use some friend functions, for example:
friend const Scalar operator+(const Scalar&, const Scalar&);
But there is a problem when I derive the abstract class, and create derived class, say:
class RealNumber: public Scalar {
public:
friend const RealNumber operator+(const RealNumber&, const RealNumber&);
//some definitions...
};
According to this logic, I would need to define a new overload of friend operator+ for every new class derived from Scalar. Is there some way to solve this problem and avoid declaring these friends in all the derived classes?
Is this your problem ?
I understand that your problem is that your two friends refer to totally different functions, since they have a different signature:
friend const Scalar operator+(const Scalar&, const Scalar&);
friend const RealNumber operator+(const RealNumber&, const RealNumber&);
Worse, the choice of a class external friend will not be polymorphic: the right friend will be chose based on the compile-time type.
How to solve it ?
First of all, instead of using an outside overloaded friend, you could consider overriding the operator of the class itself (keeping the signature identical).
However this has two major challenges:
it is almost impossible to return a reference from arithmetic operator, unless you'd accept side-effects, which would then make your operator behave differently than expected.
you'd need to cope with combining different kind of scalars: what if you'd have to add a Scalar to a RealNumber ? This would require a double dispatch to be implemented to cope with all the possible combination.
So, dead-end ?
No, there are two other alternatives, depending on your real problem:
Do you really want to combine arithmetic type dynamically at run-time ? If yes, you need to go away from the C++ operator overriding approach, and implement an expression evaluator, using the interpreter pattern.
If not, consider to use a template based design, so that the compiler choses at compile-time the appropriate specialisation.
Or suffer with the many possible friends and their combination of parameter types.
You may not be able to create virtual friend functions, but you can create virtual operators (even operator + could be done this way).
Consider the following code: WARNING: THIS IS NOT GOOD DESIGN AT ALL
#include <iostream>
using namespace std;
class AA {
private:
int a;
public:
AA(int a): a(a) {};
inline int getA() const { return a; };
virtual AA operator +(const AA &a) {
AA res(this->getA() + a.getA());
return res;
}
};
class BB: public AA {
public:
BB(int a): AA(a) {}
virtual AA operator +(const AA &a) {
AA res(this->getA() - a.getA());
return res;
}
};
int main() {
BB tmp(1);
AA& a = tmp;
AA b(7);
cout << (a + b).getA();
return 0;
}
When I was writing this code, I found that a lot of flaws could be induced (like the + operator that really does substraction instead, also what if the second operand was BB instead of the first one ??)
So, about your problem, you want Scalars. So you can do the following approach:
#include <iostream>
using namespace std;
// Here, Scalar acts as an abstract class, all its goal is to convert your
// class type into some calculable value type (e.g. you can use T as double)
template <typename T>
class Scalar {
public:
// Converter function is abstract
virtual operator T() = 0;
};
class AA: public Scalar<double> {
private:
double a;
public:
inline double getA() {return a;};
AA(double a): a(a) {}
// Implements the converter function in Scalar, T in scalar is mapped
// to double because we did Scalar<double>
virtual operator double() {
return a;
}
};
class BB: public Scalar<double> {
private:
int a;
public:
inline double getA() {return (double)a;};
BB(int a): a(a) {}
virtual operator double() {
return (double)a;
}
};
int main() {
BB tmp(1);
AA b(7);
// Here, it is easy for us just to add those, they are automatically converted into doubles, each one like how it is programmed.
cout << (b + tmp);
return 0;
}
My question is about this operator in C++, should we use it as much as possible? I given the following example to show my point:
class Abc
{
public:
int a_;
void fun();
};
void Abc::fun()
{
// option 1
a_ = 3;
// option 2
this->a_ = 3;
}
In the function class member fun(), we can invoke member variables in two ways, one is using this-> and the other is not using it. So my question is: which practice is encouraged? Thanks.
Under ordinary circumstances, you're right that you can use both. In such case, it's just a matter of style and the correct thing to do is follow the style guide of your project. Consistency is more important than personal preference in this regard.
However, there are two situations where using this-> can make a difference. One is when the member function has a parameter with the same name as a member; in such case, the name of the parameter hides the name of the member and you have to use this-> to refer to the member (first pointed out by #Krypton's answer):
void Abc::fun(int a_)
{
a_ = 3; // assigns into the parameter
this->a_ = 3; // assigns into the data member
}
The other situation is when you're working inside a class template and the member is inherited from a base class which depends on template parameters of your class template. In such case, unqualified lookup does not search dependent contexts and so the member would not be found. Using this-> turns the access into a dependent expression, which will be looked up at instantiation time, and thus resolved to the member correctly. Example:
template <class T>
struct Base
{
protected:
T a_;
};
template <class T>
struct Abc : Base<T>
{
void fun() {
a_ = 3; // error, not `a_` in scope
this->a_ = 3; // OK, found at instantiation time
}
};
In this situation, an alternative solution exists: make the name visible explicitly:
template <class T>
struct Abc : Base<T>
{
protected:
using Base<T>::a_;
public:
void fun() {
a_ = 3; // OK, found thanks to `using` declaration
}
};
If the variable and the parameter are named the same, using this is a must.
class Foo
{
public:
int _a;
void func(int _a) {
this->_a = _a;
}
};
this is also required when referring to a member of a base class that depends on a template parameter of the current class.
Otherwise, it is not necessary to use this.
I think it is more a matter of style. The use of additional this-> does not change the produced code.
Though you cannot use operator this-> in the initialization of class members before the constructor body, like
class Abc {
public:
Abc(int i): /*this-> is incorrect*/i(i) {}
private:
int i;
};
I prefer to use this-> to have a clear difference with other no-class members.
Then the code like the following is more readable
void foo(int i) { }
class Abc {
public:
Abc(int j) { this->foo(j); }
private:
void foo (int i) { this->i = i; }
int i;
};
Some people name class data members starting with m_, like m_i, m_j.
Some modern IDEs support semantic syntax highlighting that also helps to distinguish between local variables, class data members, global variables, functions.
My problem is this, I have a base class from which classes are derived. I have an overloaded += operator in the base class but I only want to be able to add derived classes of the same type. I do this by returning the lhs and producing a warning message if they are not the same type.
class base{
int variable;
public:
base(int v);
base & operator+=(const base & rhs);
class a: public base{
}
class b: public base{
}
base & operator+=(const base & rhs){
if(type_same(const & rhs){
variable+=rhs.variable; }
return *this
}
a first(1);
a second(5);
b third(2);
first+=second // first.variable now =6
second+=third // warning produced second.variable still = 5
I've never used dynamic cast before so my question is is it possible/advisable to a check using it and typeid to find out whether the types passed are the same. My alternative is a string constant name for each derived class.
Why have the operator+ in the base class in the first place? If you just place operator+ with the correct type into the a and b class, it will work, without any dynamic_cast.
dynamic_cast is usually a hint that your types are not well designed and should be avoided. In the described scenario, you can surely get by without any dynamic_cast. If not, then a and b should not be derived from base, as they do behave differently. Think about it from the user perspective: By deriving a from base, you tell the user that a can be used as base. If a method requires the actual type, move it down instead of putting it into the base interface.
The correct usage btw. would be to dynamic_cast the rhs to the current type (i.e. dynamic_cast<b*>(&rhs)) and if that returns a non-zero value, then rhs was indeed of the correct type (however, think about what happens if there is a class derived from b being passed in!)
To solve the problem that you stated in your post, dynamic_cast and RTTI are definitely the right tools. However, issuing a warning at runtime while providing compile-time support for a '+' operation may point to issues in the design where the users of your API would not expect exactly the behavior that your API provides.
My take: you could employ CRTP
The below code will issue the type mismatch error at compile time, as suggested by others.
template <typename Derived>
class base{
int variable;
public:
base(int v) { variable = v; }
Derived& operator+=(const Derived& rhs);
};
struct a: base<a> {
a(int v): base<a>(v) {}
};
struct b: base<b> {
b(int v): base<b>(v) {}
};
template <typename Derived>
Derived& base<Derived>::operator+=(const Derived& rhs)
{
variable += rhs.variable;
return static_cast<Derived&>(*this);
}
int main(int argc, const char *argv[])
{
a a1(1), a2(2);
b b1(1), b2(2);
a1 += a2;
b1 += a2; // compile time error :)
return 0;
}
Even if you really wanted to type the operator arguments as base& you'd at least gain the benefit of using static_cast<> because the conversion is exact and well defined at runtime. I can expand the idea in a few