I have functions of the following form in the code I'm refactoring:
A f()
{
if(existing)
return A();
else
return A(handle);
}
The Safe Bool Idiom is later used to test if A is associated with a handle or not, i.e. if we should call the class methods for this object which require internally a valid handle for execution. A's methods are const.
I'd like to return an interface, IA, here instead. Must I therefore return a pointer? If so I will go with boost shared pointers. I can test if the pointer is pointing to something or not.
Is there any way for me to work with references here instead? Would you recommend such an approach or do you think that boost::shared_ptrs is the way to go?
UPDATE
A is derived from IA.
My compiler is gcc version 4.4.3.
My biggest problem with this code is that A is used to interact with an external C API. Therefore I wish to mock it away using the IA interface as base for my Mock of A and its implementation, A. Then outside of the method f() above, which I see as a factory, I will only work with IA pointers. Dependency Injection in other words.
So A is basically a handle and an interface to a set of C API functions which require a handle. I can have several objects of type A where the interface is the same but the handle is different.
I'd return a std::unique_ptr< AI > object :
std::unique_ptr< AI > f()
{
if(existing)
return std::unique_ptr< AI >( new A() );
else
return std::unique_ptr< AI >( new A(handle) );
}
In the above case, the slicing doesn't happen, and the compiler will move* the object.
* I assumed you are using the c++11.
Since you are not using c++11, the simplest is to use boost::shared_ptrs :
boost::shared_ptrs< AI > f()
{
if(existing)
return boost::shared_ptrs< AI >( new A() );
else
return boost::shared_ptrs< AI >( new A(handle) );
}
In such case, you do not have to take care whether and when the created object gets destructed. The boost::shared_ptrs will take care of that.
I'd go with pointers too, but you can also work with references:
A& f()
{
if(existing)
{
static A a;
return a;
}
else
{
static A a(handle);
return a;
}
}
You are fully aware of the implications though, right? i.e. you can't re-assign the reference and modifying it means modifying the local static variable.
From your code snippet it seems that you are constructing A objects in function f. In such a case, returning the object by value is probably the best thing you can do. The compiler will use return value optimization (RVO) and optimize all the copies away.
Check this article by Dave Abrahams on passing and returning objects by value.
Be aware that this solution will not work if you are returning a base class of A, due to the slicing problem. If returning an A object is fine, then this is probably the best solution.
If you can understand pointers then work with pointers. If you can't, then stay with what you've got. Looks like the guy before you did his best to avoid pointers. As betabandido said, the compiler will make best out of it, even if it seems slow - on paper.
Interface is a design pattern to take fullest advantage of pointers. It doesn't make very much sense without pointers and casting.
To test if the pointer is pointing at something or not, there is NULL value. No need to roll out cannons if you're shooting flies.
Explain why you're not comfortable with the code as it is now. Maybe the problem isn't really severe.
Returning a pointer is one way to go.
To me, another simple and native way is to add a return value to the method's signature.
int f(A & a)
{
if(existing)
{
return ERROR_ALREADY_EXISTS;
}
else
{
A temp(handle);
a = temp;
return SUCCEEDED;
}
}
Related
I wonder if there are any legitimate reasons to return unique pointers by reference in C++, i.e. std::unique_ptr<T>&?
I've never actually seen that trick before, but the new project I've got seems to use this pattern a lot. From the first glance, it just effectively breaks / circumvents the "unique ownership" contract, making it impossible to catch the error in compile-time. Consider the following example:
class TmContainer {
public:
TmContainer() {
// Create some sort of complex object on heap and store unique_ptr to it
m_time = std::unique_ptr<tm>(new tm());
// Store something meaningful in its fields
m_time->tm_year = 42;
}
std::unique_ptr<tm>& time() { return m_time; }
private:
std::unique_ptr<tm> m_time;
};
auto one = new TmContainer();
auto& myTime = one->time();
std::cout << myTime->tm_year; // works, outputs 42
delete one;
std::cout << myTime->tm_year; // obviously fails at runtime, as `one` is deleted
Note that if we'd returned just std::unique_ptr<tm> (not a reference), it would raise a clear compile-time error, or would force use to use move semantics:
// Compile-time error
std::unique_ptr<tm> time() { return m_time; }
// Works as expected, but m_time is no longer owned by the container
std::unique_ptr<tm> time() { return std::move(m_time); }
I suspect that a general rule of thumb is that all such cases warrant use of std::shared_ptr. Am I right?
There are two use cases for this and in my opinion it is indicative of bad design. Having a non-const reference means that you can steal the resource or replace it without having to offer separate methods.
// Just create a handle to the managed object
auto& tm_ptr = tm_container.time();
do_something_to_tm(*tm_ptr);
// Steal the resource
std::unique_ptr<TmContainer> other_tm_ptr = std::move(tm_ptr);
// Replace the managed object with another one
tm_ptr = std::make_unique<TmContainer>;
I strongly advocate against these practices because they are error prone and less readable. It's best to offer an interface such as the following, provided you actually need this functionality.
tm& time() { return *m_time; }
std::unique_ptr<tm> release_time() { return {std::move(m_time)}; }
// If tm is cheap to move
void set_time(tm t) { m_time = make_unique<tm>(std::move(t)); }
// If tm is not cheap to move or not moveable at all
void set_time(std::unique_ptr t_ptr) { m_time = std::move(t_ptr); }
This was too long of a comment. I don't have a good idea for requested use case. The only thing I imagine is some middle ware for a utility library.
The question is what do you want and need to model. What are the semantics. Returning reference does not anything useful that I know.
The only advantage in your example is no explicit destructor. If you wanted to make exact mirror of this code it'd be a raw pointer IMHO. What exact type one should use depends on the exact semantics that they want to model.
Perhaps the intention behind the code you show is to return a non-owning pointer, which idiomatically (as I have learned) is modeled through a raw pointer. If you need to guarantee the object is alive, then you should use shared_ptr but bear it mind, that it means sharing ownership - i.e. detaching it's lifetime from the TmContianer.
Using raw pointer would make your code fail the same, but one could argue, that there is no reason for explicit delete as well, and lifetime of the object can be properly managed through scopes.
This is of course debatable, as semantics and meaning of words and phrases is, but my experience says, that's how c++ people write, talk and understand the pointers.
std::unique_ptr does not satisfy the requirements of CopyConstructible or CopyAssignable as per design.
So the object has to be returned as a reference, if needed.
Consider the following scenario: There is a class CDriver that is in charge of enumerating all the attached output devices (represented by the COutput class). The code for that may look something like this:
class COutput
{
// COutput stuff
};
class CDriver
{
public:
CDriver(); // enumerate outputs and store in m_outputs
// some other methods
private:
std::vector<COutput> m_outputs;
};
Now CDriver should be able to grant the user access to the enumerated COutputs.
The first method of achieving this is to return a pointer:
const COutput* GetOutput(unsigned int idx) const
{
return idx < m_outputs.size() ? &m_outputs[idx] : nullptr;
}
The way I see it, this method presents the problem that if the pointer is stored by the user and it persists after the CDriver object has been destroyed, it is now a dangling pointer. This is due to the fact that the pointee (COutput object) has been destroyed during the destructor of the CDriver object.
The second way of doing this would be to return by reference:
const COutput& GetOutput(unsigned int idx) const
{
return idx < m_outputs.size() ? &m_outputs[idx] : m_invalidOutput;
}
Here the same problems apply as in the approach with pointers. Furthermore it has the additional caveat that no real invalid object can be returned. If a nullptr is returned as a return pointer, it is obvious that it is "invalid". There is, however, no equivalent to nullptr when it comes to references.
Moving on to approach number three. Return by value.
COutput GetOutput(unsigned int idx) const
{
return idx < m_outputs.size() ? &m_outputs[idx] : m_invalidOutput;
}
Here, the user doesn't have to worry about the lifetime of the returned object. However, the COutput object has to be copied and there is, similary to the reference approach, no intuitive way to check for errors.
I could go on...
For example, the COutput objects could be allocated on the heap and stored in std::shared_ptrs and returned as such. This, however would make the code very verbose.
Is there any way to solve this problem intuitively and without introducing unnecessary code verbosity?
Let me start off by saying, you should absolutely not start messing around with shared_ptr to solve this problem. Just don't do it. You have a few different options here that are reasonable.
First, you can simply return by value. If COutput is small, this is a good way to go. To deal with an out of bounds index, you have two options. One is throw an exception. Works well and is easy. This is what I would recommend here most likely. Make sure to have a size() member that the user can call to get the size, so they can avoid paying the cost of throwing, if that is too expensive for them. You can also return an optional. This is in the standard library as of 17, in boost prior, and there are standalone implementations.
Second, you can return by pointer/reference. Yes, it can dangle. But C++ does not claim to offer protection against this. Every single standard container features begin() and end() methods that return iterators can easily dangle as well. Expecting clients to avoid these pitfalls is not unreasonable in C++ (you should of course document them though).
Third, you can do inversion of control: instead of giving the user an object to operate on, you instead make the user pass in the action they want to take. In other words:
template <class F>
auto apply(std::size_t idx, F f) const
{
if (idx >= m_outputs.size())
{
throw std::out_of_range("index is out of range");
}
return f(m_outputs[idx]);
}
Usage:
CDriver x;
x.apply(3, [] (const COutput& o) {
o.do_something();
});
The user needs to work quite a bit harder to make something dangle in this case (though it's still possible) since they aren't handed a pointer/reference, and you don't have to make a copy either.
You can of course change apply in many ways; e.g. not return back from the functional call but instead return true/false to indicate whether the index was in range instead of throwing. The basic idea is the same. Note that this approach would have to be modified to be used in conjunction with virtual functions, which would make it less desirable. So if you are thinking of polymorphism for CDriver, you should consider that.
Take a look at C++11's shared pointers. With shared pointers, the base object's deconstructor won't be called until all shared pointers "owning" that object are destroyed. This removes a lot (but not all) of the headache when dealing with multiple references to a single object.
Here's some more info:
http://en.cppreference.com/w/cpp/memory/shared_ptr
1). The tried and tested: throw a standard argument exception
2) You could use tuples and std::tie.
const std::tuple<bool, COutput> GetOutput(unsigned int idx) const
{
return idx < m_outputs.size()
? std::make_tuple(true m_outputs[idx])
: std::make_tuple(false, m_invalidOutput);
}
bool has_value;
COutput output;
std::tie(has_value, output) = GetOutput(3);
To replace tuples and std::tie in C++17 structured bindings can be used.
3) C++17 will have std::optional for this kind of scenario.
I have spent a great deal of time programming in Java and a decent amount of time writing c++, but I have run into an issue I haven't been able to solve. In a Java class I can simply write the following,
public void doOperation(object a)
{
if(a != this)
{
set(a); // just some method that sets this.a = object.a
}
doOperation();
}
public void doOperation()
{
this.a = pow(this.a,3);
}
The part I am having trouble implementing in c++ is the if statement where I check if the argument object is equal to this. I have tried this in c++
object::doOperation(object a)
{
if(a != this)
{
set(a);
}
doOperation();
}
object::doOperation()
{
this->a = pow(this->a,3)
}
The error I get reads, "no match for ‘operator!=’ (operand types are ‘object’ and ‘object* const’)". Thanks in advance for anybody who can help!
You can simply pass "a" by reference, take a pointer to "a" and compare it with "this", like so:
object::doOperation(object & a)
{
if(&a != this)
{
set(a);
}
doOperation();
}
object::doOperation()
{
this->a = pow(this->a,3)
}
This is a standard way that people would e.g. implement copy assignment operators in C++. It's not always done this way, but often the implementation of that will take a const reference to an object, and use a check against "this" to prevent self assignment.
Edit: Let me try to take a broader view, which might be more useful to you.
In Java, objects are implicitly passed around by reference and not by value, and they are garbage collected also, automatically destroyed when no-one needs them anymore.
The closest way to get that kind of semantics in C++ is to pass around std::shared_ptr<A> when in java you would have passed A. Then, when you need to compare against this, you can use the get method to get a raw pointer from the shared pointer and compare it literally against this. OR, if you use the std::enable_shared_from_this template when you define your class, you can use shared_from_this to get a shared_ptr<A> to this at any point in your member functions, and compare the shared_ptr's directly.
I'm assuming you are using C++11, otherwise you would use boost headers for that stuff.
Note also the stuff about "weak_ptr" which you might need to use if you have cyclic references.
That's because this is a pointer type in C++. If your function signature would use a pointer as well, it would work:
object::doOperation(object* a)
{
if(a != this)
{
set(a);
}
doOperation();
}
In Java most objects are passed around as references. To avoid aliasing problems you may then need to check for reference equality: are these two apparently distinct objects, really distinct, or do the references refer to the same object?
In C++ objects are often passed as values, copying their values. And for values it doesn't make sense to check for object identity. E.g. a function argument passed by value, as in your object::doOperation(object a) example, will always have an address different from everything else at that point in the program execution (it's freshly allocated).
Still there are some cases where objects are passed by reference (or pointer), and where self-check is appropriate.
For example, a copy assignment operator might go like this:
auto My_class::operator=( My_class const& other )
-> My_class&
{
if( &other != this )
{
values_ = other.values_; // Avoid this work for self-assign.
}
return *this;
}
The self-check can also be crucial for correctness, although with use of standard library containers and smart pointers correctness can usually be ensured without any self-check.
If an object has been passed by value as in
void object::doSomething(object x)
{
// whatever
}
then it is not necessary to compare with this. Even of the caller does
some_object.doSomething(some_object);
the x is a temporary copy - i.e. so a different object is guaranteed.
If the argument is passed by reference or argument then remember that this is a pointer and not a reference (unlike Java in which those concepts are entwined), for example;
void object::doSomething(object *x)
{
if (this != x)
{
}
}
and
void object::doSomething(object &x)
{
if (this != &x)
{
}
}
The latter assumes that object does not have an interfering operator&(). If that assumption is invalid then, in C++11 use addressof(x) (where addressof() is specified in <memory>. Before C++11, the tricks to get address of x are a little more indirect (e.g. a sequence of casts).
Personally, I don't do such tests at all. Instead, I simply do
void object::doSomething(object &x)
{
object temp(x);
// do things with temp and *this
std::swap(x, temp);
}
which relies on working copy semantics, but also gives more exception safety. If a class makes the above prohibitive, then that is more usually a problem with class design (better to find another way to avoid the need to compare with this).
I recently reworked one of my own libraries to try out separating interface from implementation. I am having on final issue with a class that is meant to return an instance of another class.
In the interface definition, I do something like
struct IFoo
{
virtual const IBar& getBar() = 0;
}
and then in the concrete Foo getBar looks like
const IBar& Foo::getBar()
{
Bar ret = Bar();
return ret;
}
The problem is ret gets deleted as soon as getBar is done, causing a big crash when the copy constructor tries to use Bar like so
const Bar myBar = myFoo.getBar();
I have been reading various things, and I know returning by reference is frowned upon, but I do not see any other way (I do not want to return Bar* because I do not want to have to manually delete the return value).
What is the proper way (if any way exists) for an abstract class to return an instance of a concrete class derived from another abstract class?
Note I did see this solution: returning an abstract class from a function
but I do not want to make the return value static and loose thread safety.
Use smart pointers.
These are pointers deleted when not used anymore (see for example http://www.boost.org/doc/libs/1_43_0/libs/smart_ptr/smart_ptr.htm).
You can also return the object by value.
Some compilers provide the Return value optimization which optimize away the copy when returning an object.
Edit:
Sorry. I skimmed through the question and somehow missed the fact that inheritance is involved. Assuming that getBar() can return various kind of IBar returning an IBar pointer makes a lot of sense.
By returning a pointer to base the concrete object is kept intact. The slicing problem is avoided and the original vtbl pointer is available to make virtual function calls. Also (as you noted in your comment) returning an instance of an abstract class is just impossible.
Instead of returning a raw pointer I suggest you return a shared_ptr<IBar> to simplify memory management.
const shared_ptr<IBar> Foo::getBar()
{
shared_ptr<IBar> ret(new Bar());
return ret;
}
Then use it this way:
shared_ptr<IBar> pIBar(foo.getBar());
pIBar->myVirtualFunction();
shared_ptr is the most commonly used smart pointer type in C++0x. If you have a sufficiently recent compiler it will be in the std namespace. Older compiler may have it in the tr1 namespace and it's also part of boost.
You're returning a reference to a local variable. As soon as the function returns the reference, the stack gets popped and that Bar object ceases to exist.
EDIT: I didn't read the whole thing. You'll probably need to use a smart pointer.
Actually, is there any reason why you need to return a base class reference? You could avoid any smart pointer messiness by returning an object of the concrete type itself, since C++ allows covariant return types.
Since you want to transfer ownership of the returned object to the caller, the caller will have to destroy the object. In other words, returning IBar * is your best bet. If you are worried about having to manually call delete, you should look into using a smart pointer package, e.g. boost::shared_ptr.
If you don't want to take care of deletion then you have to use SmartPointers.
In C++ this is the only way to have object "deletes itself" when it is appropriated.
http://en.wikipedia.org/wiki/Smart_pointer
The object that has been created on the stack will be destructed when your stack is removed. The stack is removed when the function exits.
Instead, try something like this:
struct Foo : public IFoo
{
Bar m_Bar;
public:
virtual const IBar& getBar()
{
return m_Bar;
}
}
I would like to know a good syntax for C++ getters and setters.
private:
YourClass *pMember;
the setter is easy I guess:
void Member(YourClass *value){
this->pMember = value; // forget about deleting etc
}
and the getter?
should I use references or const pointers?
example:
YourClass &Member(){
return *this->pMember;
}
or
YourClass *Member() const{
return this->member;
}
whats the difference between them?
Thanks,
Joe
EDIT:
sorry, I will edit my question... I know about references and pointers, I was asking about references and const pointers, as getters, what would be the difference between them in my code, like in hte future, what shoud I expect to lose if I go a way or another...
so I guess I will use const pointers instead of references
const pointers can't be delete or setted, right?
As a general law:
If NULL is a valid parameter or return value, use pointers.
If NULL is NOT a valid parameter or return value, use references.
So if the setter should possibly be called with NULL, use a pointer as a parameter. Otherwise use a reference.
If it's valid to call the getter of a object containing a NULL pointer, it should return a pointer. If such a case is an illegal invariant, the return value should be a reference. The getter then should throw a exception, if the member variable is NULL.
Your code looks a great deal as if you're accustomed to a different language -- in C++ using this->x (for one example) is relatively unusual. When the code is at all well written, so is using an accessor or mutator.
Though I'm fairly unusual in this particular respect, I'll go on record (yet again) as saying that forcing client code to use an accessor or mutator directly is a bad idea. If you honestly have a situation where it makes sense for client code to manipulate a value in your object, then the client code should use normal assignment to read and/or write that value.
When/if you need to control what value is assigned, operator overloading lets you take that control without forcing ugly get/set syntax on the client code. Specifically, what you want is a proxy class (or class template). Just for one example, one of the most common situations where people want get/set functions is something like a number that's supposed to be restricted to some particular range. The setXXX checks the new value for being in range, and the getXXX returns the value.
If you want that, a (fairly) simple template can do the job much more cleanly:
template <class T, class less=std::less<T> >
class bounded {
const T lower_, upper_;
T val_;
bool check(T const &value) {
return less()(value, lower_) || less()(upper_, value);
}
void assign(T const &value) {
if (check(value))
throw std::domain_error("Out of Range");
val_ = value;
}
public:
bounded(T const &lower, T const &upper)
: lower_(lower), upper_(upper) {}
bounded(bounded const &init)
: lower_(init.lower), upper_(init.upper)
{
assign(init);
}
bounded &operator=(T const &v) { assign(v); return *this; }
operator T() const { return val_; }
friend std::istream &operator>>(std::istream &is, bounded &b) {
T temp;
is >> temp;
if (b.check(temp))
is.setstate(std::ios::failbit);
else
b.val_ = temp;
return is;
}
};
This also makes the code much closer to self documenting -- for example, when you declare an object like: bounded<int>(1, 1024);, it's immediately apparent that the intent is an integer in the range of 1 to 1024. The only part somebody might find open to question is whether 1 and/or 1024 is included in the range. This is considerably different from defining an int in the class, and expecting everybody who ever looks at the class to realize that they're supposed to use the setXXX to enforce some (at that point unknown) set of bounds on the values that can be assigned.
When you embed one of these in a class, you make it a public variable, and the range is still enforced. In the client code, there's no real argument over syntax -- you're just assigning to a public variable, like you would any other -- with the minor detail that attempting to assign a value that's out of range will throw an exception. In theory, the class should probably take a policy template-parameter to specify exactly what it does in that case, but I've never had a real reason to bother with that.
The best thing is to provide a real OO interface to the client that hides implementaton details. Getters and Setters are not OO.
As others have said, use pointers if null is a possibility.
In most cases, I prefer to use references when possible. Personally, in my code, I like to use the distinction between pointers and references to signal ownership. I think of calls with references as "loaning" an object to another function or class. The original class that passed or returned the reference still owns it, and is responsible for its creation, maintenance and clean up. When my code passes a non-const pointer, on the other hand, it usually means that there's some kind of transfer or sharing of ownership going on, with all the responsibilities that entails.
(And yes, I usually use smart pointers. Those are akin to references in my mind. I'm talking about lower level code than that here.)
whats the difference between them?
The reference is an alias of the thing(it is the thing*). A pointer is the address of the thing. If there's a chance that what's pointed to won't be there, then you probably don't want to return references. References tell the caller "I'm going to give you an alias that will exist when I return it to you". In fact there's really no way to check the reference to see if what's underlying is valid.
With the pointer, semantically, you are implying that the caller may wish to check to see if Member exists before using it. Ussually this is done with a NULL check.
Ultimately there's no "right" answer. It depends on the class's contract and if the caller will/should/wants to check whether "Member" is still around.
The short answer is pointers for things that can be pointed elsewhere and references for "unseated" aliases.
In addition to the other answers, if you choose references for the getter don't write it like in your example:
YourClass &Member(){
return *this->pMember;
}
Your getter actually allows setting, as in instance->Member() = YourClass(); and thus bypassing your setter. This might not be allowed if YourClass is noncopyable, but is still another thing to have in mind. Another drawback is the getter is not const.
Instead, write your getter like this:
const YourClass &Member() const {
return *this->pMember;
}
+1 on questioning the use of setters and getters. If you must use them and have the possibility of nulls consider using boost::shared_ptr. This way ownership is handled for you.
Jonathan, what compiler are you using? There's a great chance that shared_ptr already comes shipped with it as part of the compiler's TR1 implementation.