Re: A program that writes code: should it use 'string'?
On Jun 3, 5:16 pm, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
In article
<d442bccc-43ec-4060-a323-f5943c4f3...@m73g2000hsh.googlegroups.com>,
James Kanze <james.ka...@gmail.com> wrote:
On Jun 2, 3:41 pm, ytrem...@nyx.nyx.net (Yannick Tremblay) wrote:
In article <7clk1oc8r6....@pbourguignon.anevia.com>,
Pascal J. Bourguignon <p...@informatimago.com> wrote:
No, you should not use strings to generate code. Code is a syntac
tree. You should have a tree of objects:
Lhs* lhs=new Variable("pi_squared");
Rhs* rhs=new Variable("pi");
Statement* code=new Assignment(lhs,new Multiply(rhs,rhs));
cout<<code->generate();
This is C++, not Java, loose the "new" abuse:
He's building a tree. That pretty much required dynamic
allocation.
Looking at the proposed syntax above, I don't think that was
the reason for the "new" overflow syntax so I maintain my
opinion.
I'm not sure what you mean by "overflow" syntax, but Pascal
explicitly said that you should have a tree, so I think we have
to assume that he was building a tree.
This could be true for:
Lhs* lhs=new Variable("pi_squared");
Rhs* rhs=new Variable("pi");
Rhs* rhs2=new Variable("pi");
Assignemnt code(lhs, new Multiply(rhs,rhs2))
OK, so his code builds a directed acyclic graph, instead of a
tree. What does that change?
But in the code as presented:
1- Multiply can't get double ownership of rhs unless it's
constructor is convoluted. If it gets basic ownership of the
dynamically allocated object it is given, Multiply(rhs, rhs)
is probably a bug.
First, I suspect that the posted code was just a hint, and not
meant to be polished, finished, fully working code. Second, I
don't quite follow your points about "ownership". If you're
building a directed acyclic graph, then ownership is not really
a relevant issue; if there is ownership, it is shared by all
parents, but typically, you'll implement some sort of garbage
collection, and not worry about it. If you're not using the
Boehm collector, you'll allocate all of the nodes from a pool,
with a pool for each expression, and you'll drop the entire pool
when you're done with the expression. Or, since the graph is
acyclic, you can even use boost::shared_ptr if performance isn't
an issue (and the amount boost::shared_ptr will impact is
probably small enough to make it not an issue).
2-
Statement* code=new Assignment(/*...*/);
std::cout << code->generate();
is very hard to justify. To me that's clear dynamic
allocation abuse. Of course, "code" could later be added to a
statement collection but that was not in the presented code so
dynamic allocation there was unjustified.
Except that in a larger context, it's likely that you can't
allocate Statement (or any syntax element) on the stack.
(Unless you have full garbage collection, of course.)
3- The code as presented will leak if either of the 2nd, 3rd
or 4th "new" throws.
Without seeing the actual classes involved, I can't say that.
Probably, he's using the Boehm collector; this is typically the
sort of thing where garbage collection shines. Or he's defined
an operator new/operator delete in the base class constructor
which allocates from a pool, and he just tells the pool to drop
everything when he's through with the expression, at a higher
level. (That's the way I usually handle syntax trees when I
can't use the Boehm collector.) Or maybe he's made the
constructors nothrow, and replaced the new_handler to abort, so
that the entire code is guaranteed no throw.
So maybe the following would be acceptable:
shared_ptr<Lhs> lhs(new Variable("pi_squared"));
shared_ptr<Rhs> rhs(new Variable("pi"));
Assignemnt code(lhs, new Multiply(rhs,rhs))
Maybe, but there are better solutions.
[...]
Copy constructors would do the job fine. It seems to works
for the STL.
In case you hadn't notice, the STL does dynamic allocation in
its containers. Here, he's building a tree outside of any
container, so that doesn't work; he'd have to hide it in the
individual elements.
The Assignement implementation would also not be forced to
have a particular internal structure but could be implemented
in whatever way is best.
course, it doesn't work if the expression is the result of
parsing some external data either.
Not sure I get your point here.
If you don't know what variables you're going to need up front,
the only way to get the objects you need is by dynamic
allocation.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34