Re: Keeping object beyond current lexical scope
Hello Urs!
Unless I misunderstand something about your question, I don't
think that your question is well posed.
On Feb 21, 7:08 am, Urs Thuermann <u...@isnogud.escape.de> wrote:
How can I cleanly and elegantly keep a locally created object beyond
the lexical block it is created in? Say I have a class Item with no
default constructor, but a copy constructor and code like this:
void some_func() {
my_queue.lock();
Item i = my_queue.get_item();
my_queue.unlock();
// do something with Item i
}
I now want to unlock() the my_queue even if get_item() throws an
exception. But both, a try-catch block and RAII would make the
variable Item i local so I cannot work on it after that block, e.g.
If get_item() throws, then you didn't get your Item, so there is no
i to "do something" with whether you're in or out of local scope.
void some_func () {
// Cannot define Item i here since it has no default ctor=
..
try {
my_queue.lock();
Item i = ...
my_queue.unlock();
} catch (...) {
my_queue.unlock();
}
// cannot work with Item i here
}
I would rewrite some_func as follows:
The point is that i is only guaranteed to be valid inside the try
block, so you should work with it there.
void some_func () {
// Cannot define Item i here since it has no default ctor.
<-- okay
try {
my_queue.lock();
Item i = my_queue.get_item(); // <-- get_item might
throw, okay
my_queue.unlock(); // <-- lock is released as soon
as possible
do_something_with_i (i); // <-- get_item didn't throw
so you have a valid i
} catch (...) {
my_queue.unlock(); // <-- release lock, even if
get_item throws, okay
}
// cannot work with Item i here <-- true, but if get_item
threw, i is no good anyway
}
Now this approach does require two copies of the line
"my_queue.unlock;".
I don't think that's a big deal, but you avoid this issue with RAII.
If
you want to use RAII to manage the lock, I don't see a way to do it
without
introducing the helper function that Fred suggested.
I cannot define Item i before that block, since I have no default
ctor. Adding such a ctor that leaves i mostly uninitialized and
defining an assignment operator looks very unclean. Also something
like this
void some_func() {
Item *i;
try {
...
i = new Item(my_queue.get_item());
...
} catch ...
...
}
// do something with i
You have the same issue here. If get_item throws you don't have a
valid Item, and i is now a bad pointer. You only know that i is
good inside of the try block.
delete i;
}
looks very unclean and cumbersome, unnecessarily creates dynamic
memory overhead, and it also introduces the next resource leak if the
"do something with i" can throw an exception.
The cleanest solution I can currently think of is to put the try{}
block into a separate function and to return the Item to some_func().
Still, possibly, the same issue. What should your "separate function"
return if the call to get_item throws?
Is there a simpler and cleaner way?
urs
Sorry if I misunderstood the issue.
Good luck.
K. Frank