|
Boost Users : |
From: Steve Folly (boost_at_[hidden])
Date: 2004-02-07 20:28:38
Hi,
I'd like some help trying to crack a problem I've got. Now, I am using
shared pointers at the moment, and that might be part of my problem, or it
might not, but I'll describe the situation and you can tell to go elsewhere
if you like! :)
Part of my application involves scripting - allowing the user to write file
based scripts to execute within the context of an application.
I've designed it so it also gives the ability for the application writer to
create some 'scripts' by creating classes directly in the C++ code.
The script has the ability to run in the main thread of the app, but some
statements could potentially block, so each statement is run from a 'timer'
event which gets scheduled immediately. Those that block wait for an event
and continue on that event. This part is working well.
The statements are classes constructed in a hierarchical manner with things
like a block class (a statement itself) which has a list of statements in
it, an if statement class - which has an expression evaluator, a statement
for the 'then' part, and an optional statement for the 'else' part. You get
the idea?
After looking at boost::lambda I thought it would be nice if I could
construct my script similar to how lambda does these sorts of control
statements - the if_, switch_, for_ constructs. The idea I have is like:
expression exp = ...
If_statement s1 =
if_( expr)->then_( s2 )->else_( s3 );
while_statement ws =
while_( expr ).do_( s1 );
One of the things I decided early on was to use shared_ptrs. The while_ and
if_ constructs are functions returning a shared pointer to the real if
statement object.
Now my problem: given the example above. The do_ method of a while_statement
takes a shared pointer to a statement so I don't have to worry about
deallocation. Constructing the if_ statement on it's own is no problem, but
if I was to construct one directly within the do_ part of the while
statement it wont compile:
while_( expr ).do_( if_(expr)->then_(s2)->else_(s3) );
The problem is to be able to chain then_ and else_ together, I have to
return a plain pointer because the if_ statement itself doesn't know about
it's shared pointer. So now, the compiler complains that can't implicitly
convert a plain if_statement pointer into a shared pointer. And even if it
could, I don't have the original shared pointer to hand.
Now, I hope you're all still listening at the back! :)
My first thought was to somehow get the object to look after the shared
pointer, but surely if the object has a reference to itself, the ref count
of the shared pointer could never reach zero?
As I said right at the beginning, I think is a problem I have with shared
pointers, whether it be a misunderstanding about them or maybe I'm using
them the wrong way?
I could always go for scrapping the shared pointers all together, and make
the classes responsible for their own (de)allocation, but I was rather
hoping to avoid that.
Any tips and suggestions on ways forward will be much appreciated. (Even if
to say - "ha! it'll never work", or "try a another newsgroup"! :)
TIA.
-- Regards, Steve.
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net