[antlr-interest] C++ version, == nullAST

[Ken Lidster]

Rusian,

I agree that there are better ways to do this. I was just answering your
original question on why that specific implementation required the nullAST
entry and its various references. It sounds like something along the lines
of your design would allow cleaner code.

Ken

-----Original Message-----
From: Ruslan Zasukhin [mailto:sunshine at public.kherson.ua]
Sent: Wednesday, October 03, 2001 11:47 PM
To: antlr-interest at yahoogroups.com
Subject: Re: [antlr-interest] C++ version, == nullAST


on 10/4/01 1:24, Ken Lidster at ken at synergex.com wrote:

> Ruslan,
> 
> I haven't worked with this code for a couple of years, but I believe this
> relates to the reference counting. First, I seem to recall that in this
> particular smart pointer implementation the only way to 'release' an
> associated address (actually, a private, encapsulating, reference counted,
> pointer object) was by either assigning another smart pointer to it, or
via
> destruction when the smart pointer object goes out of scope. Thus,
equating
> the empty nullAST object was an explicit release of the associated
pointer.
> 
> Second, I believe the default extractor for the base reference class
> (template RefCount<T> I think) was the address of the encapsulated pointer
> object, or zero if there was nothing. Since there wasn't an explicit
> clearing method and, as you noted, all of the releases were accomplished
via
> an equate to nullAST, the 'someAST == nullAST' had to be used to determine
> if someAST was "empty".
> 
> I remember thinking back then that I would have preferred (as I mentioned
> above) something like an explicit clear() or empty() method. The operation
> 'someAST.clear()' seems more intuitive to me than 'someAST = nullAST'.
This
> would also have allowed 'someAST == 0', or even '!someAST' to be true when
> the smart pointer was empty. But, what we had worked and there were
> deadlines to be met. You know how that goes, I'm sure.

Okay, Ken I see.

But again with my implementation of Ref count pointers via classes
Sharable and SharablePtr<T> there is no above problems at all.

I can assign and test usual NULL with no problems in my code.
So if Ric accept my class he will be able remove nullAST at all.

-- 
Best regards,
Ruslan Zasukhin

-------------------------
Paradigma.

e-mail: ruslan at paradigmasoft.com
web   : http://www.paradigmasoft.com

To subscribe to the Valentina mail list
send a letter to valentina-on at lists.macserve.net



 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/ 


 

Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/