Loading ...
Sorry, an error occurred while loading the content.

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

Expand Messages
  • Ruslan Zasukhin
    ... I don t think we will get any arrows in back, because I use in my project just SomeObjectCPtr obj = NULL; and if( obj == NULL ) everywhere. No problems.
    Message 1 of 9 , Oct 3, 2001
    • 0 Attachment
      on 10/3/01 17:24, Ric Klaren at klaren@... wrote:

      > Sorry it got snowed under a little...
      >
      >>> RefCount nullASt
      >
      > I'm not sure why it is used... It looks like they used it to have one null
      > pointer refcounted object?
      >
      > It's defined in BaseAST with a comment about it being nasty but making
      > codegen easier.. It's not something I particularly looked at.
      >
      > Some quick browsing in the code indeed seems to indicate that it can go.

      > Although maybe there's something subtle with the reference counter,
      > although the worst that could happen is that multiple RefAST's exist of a
      > null pointer, which should not be that bad.

      I don't think we will get any arrows in back, because I use in my project
      just

      SomeObjectCPtr obj = NULL;

      and

      if( obj == NULL )

      everywhere. No problems. At least with my implementation of ref counting via
      Sharable class and pointer.

      > I may have a closer look/try it out later this week or next week, there are
      > not too much occurences of the beast so giving it a spin is not hard.

      --
      Best regards,
      Ruslan Zasukhin

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

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

      To subscribe to the Valentina mail list
      send a letter to valentina-on@...
    • Ken Lidster
      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
      Message 2 of 9 , Oct 3, 2001
      • 0 Attachment
        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.

        Ken

        -----Original Message-----
        From: Ruslan Zasukhin [mailto:sunshine@...]
        Sent: Friday, September 28, 2001 2:25 PM
        To: Ric Klaren; antlr-interest@yahoogroups.com
        Subject: [antlr-interest] C++ version, == nullAST


        Hi Ric,

        I also note next issue.
        What sense to have in C++ version special global variable

        RefCount nullASt

        ???

        Later there is many coe that use it for comparison

        if( someAST == nullAST )

        At first I did think this is again, "way of Java"...
        but in Java code I see

        if( someAST == null )

        So I think we must throw out from C++ version this nullAST.
        This make code more clean, more similar to Java version and little faster.
        Really

        if( someAST == nullAST )
        ^^^^^^^^ here work operator that return AST*

        if( someAST == 0 )
        ^^^^ zero overhead.

        --
        Best regards,
        Ruslan Zasukhin

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

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

        To subscribe to the Valentina mail list
        send a letter to valentina-on@...





        Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
      • Ruslan Zasukhin
        ... Okay, Ken I see. But again with my implementation of Ref count pointers via classes Sharable and SharablePtr there is no above problems at all. I can
        Message 3 of 9 , Oct 3, 2001
        • 0 Attachment
          on 10/4/01 1:24, Ken Lidster at ken@... 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@...
          web : http://www.paradigmasoft.com

          To subscribe to the Valentina mail list
          send a letter to valentina-on@...
        • David Barron
          STL uses empty as a predicate to determine whether the container is empty. This should be easy to add to template RefCount : // (pseudo code)
          Message 4 of 9 , Oct 4, 2001
          • 0 Attachment
            STL uses "empty" as a predicate to determine whether the container is empty.
            This should be easy to add to template RefCount < T > :

            // (pseudo code)

            RefCount::empty(const T &x) const
            {
            return (T.pointer == NULL);
            }

            Making this a method of RefCount should make things more efficient.
            Checking a pointer against 0 should be faster than checking someAST ==
            nullAST.

            STL uses "clear" is used to clear a container (or part of it). It may not
            make the code more efficient, but it would make it closer to STL, which
            should make it easier for C++ people to use.

            David

            -----Original Message-----
            From: Ken Lidster [mailto:ken@...]
            Sent: Wednesday, October 03, 2001 3:25 PM
            To: 'antlr-interest@yahoogroups.com'
            Subject: RE: [antlr-interest] C++ version, == nullAST


            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.

            Ken

            -----Original Message-----
            From: Ruslan Zasukhin [mailto:sunshine@...]
            Sent: Friday, September 28, 2001 2:25 PM
            To: Ric Klaren; antlr-interest@yahoogroups.com
            Subject: [antlr-interest] C++ version, == nullAST


            Hi Ric,

            I also note next issue.
            What sense to have in C++ version special global variable

            RefCount nullASt

            ???

            Later there is many coe that use it for comparison

            if( someAST == nullAST )

            At first I did think this is again, "way of Java"...
            but in Java code I see

            if( someAST == null )

            So I think we must throw out from C++ version this nullAST.
            This make code more clean, more similar to Java version and little faster.
            Really

            if( someAST == nullAST )
            ^^^^^^^^ here work operator that return AST*

            if( someAST == 0 )
            ^^^^ zero overhead.

            --
            Best regards,
            Ruslan Zasukhin

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

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

            To subscribe to the Valentina mail list
            send a letter to valentina-on@...





            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/
          • 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
            Message 5 of 9 , Oct 4, 2001
            • 0 Attachment
              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@...]
              Sent: Wednesday, October 03, 2001 11:47 PM
              To: antlr-interest@yahoogroups.com
              Subject: Re: [antlr-interest] C++ version, == nullAST


              on 10/4/01 1:24, Ken Lidster at ken@... 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@...
              web : http://www.paradigmasoft.com

              To subscribe to the Valentina mail list
              send a letter to valentina-on@...





              Your use of Yahoo! Groups is subject to http://docs.yahoo.com/info/terms/
            • John Green
              I really like this line of thinking. As the C++ codegen for ANTLR evolves, I for one would be very happy to see it doing things the STL way .I d also be
              Message 6 of 9 , Oct 4, 2001
              • 0 Attachment
                I really like this line of thinking. As the C++ codegen for ANTLR evolves, I
                for one would be very happy to see it doing things "the STL way".

                I'd also be happy to see the Boost libraries taken advantage of. Has
                boost::shared_ptr every been considered or discussed? (I haven't looked into
                it...)

                John


                > -----Original Message-----
                > From: David Barron [mailto:david.barron@...]
                > Sent: Friday, October 05, 2001 12:31 AM
                > To: 'antlr-interest@yahoogroups.com'
                > Subject: [antlr-interest] RE: C++ version, == nullAST
                >
                >
                > STL uses "empty" as a predicate to determine whether the
                > container is empty.
                > This should be easy to add to template RefCount < T > :
                >
                > // (pseudo code)
                >
                > RefCount::empty(const T &x) const
                > {
                > return (T.pointer == NULL);
                > }
                >
                > Making this a method of RefCount should make things more efficient.
                > Checking a pointer against 0 should be faster than checking someAST ==
                > nullAST.
                >
                > STL uses "clear" is used to clear a container (or part of it). It may not
                > make the code more efficient, but it would make it closer to STL, which
                > should make it easier for C++ people to use.
                >
                > David


                _________________________________________________________
                Do You Yahoo!?
                Get your free @... address at http://mail.yahoo.com
              Your message has been successfully submitted and would be delivered to recipients shortly.