C++ parser

[Steven T. Hatton]

On Thursday 02 June 2005 11:53, Roberto Raggi wrote:
> Hi Steven,
>
> On Wednesday 01 June 2005 21:19, Steven T. Hatton wrote:
> > I look at suff like Robe's code just to remind me there are people who
> > are better programmers than I will ever be.  I hope to find time to
> > really
>
> trust me, I'm not that good :( anyway thanks!!
>
> > study what he's done.  From what little I do understand, his parser
> > should be pretty darn fast.  Unfortunately, there seems to be some
> > problem running
>
> the parser is a lot faster than the old one. In some cases it is 10 times
> faster :)
>
> > it on my system.  Whenever I try ./r++ -dump main.cpp I get the
> > following:
>
> please, can you post the line of stl_alloc.h that cause the problem? I know
> the parser has problems to parse expressions! I hope to solve these
> problems with the new multi-pass mode.
>
> > I get the same if I don't use -dump.  I'm assuming if I use -dump, it
> > should dump a bunch of stuff to standard out. I get different values for
> > the time statistics when I run it on different files, but I always get
> > the unexpected symbol message.  It also doesn't seem to understand my
> > CPLUS_INCLUDE_PATH, nor -I.  But as Robe said, it just a stupid wrapper
> > script.
>
> maybe you want to replace ``/usr/bin/cpp'' in ``r++''! for instance on my
> system I have cpp and cpp-3.3.
>
> ciao robe
>

I realized I am running distcc, so I logged in as another user, and r++ 
segfaulted.  I took all the junk out of my PATH in my normal login and it 
segfaulted.  I rebuilt it with the cleaned up path, and it's back to giving 
me the same error message. Very strange. I may have something coherent to add 
to this after the coffee take effect. :-/

The indicated line is:

 void construct(pointer __p, const _Tp& __val)
      { ::new(__p) _Tp(__val); }

  /**
   *  @brief  The "standard" allocator, as per [20.4].
   *
   *  The private _Alloc is "SGI" style.  (See comments at the top
   *  of stl_alloc.h.)
   *
   *  The underlying allocator behaves as follows.
   *    - __default_alloc_template is used via two typedefs
   *    - "__single_client_alloc" typedef does no locking for threads
   *    - "__alloc" typedef is threadsafe via the locks
   *    - __new_alloc is used for memory requests
   *
   *  (See @link Allocators allocators info @endlink for more.)
   */
  template<typename _Tp>
    class allocator
    {
      typedef __alloc _Alloc;          // The underlying allocator.
    public:
      typedef size_t     size_type;
      typedef ptrdiff_t  difference_type;
      typedef _Tp*       pointer;
      typedef const _Tp* const_pointer;
      typedef _Tp&       reference;
      typedef const _Tp& const_reference;
      typedef _Tp        value_type;

      template<typename _Tp1>
        struct rebind
        { typedef allocator<_Tp1> other; };

      allocator() throw() {}
      allocator(const allocator&) throw() {}
      template<typename _Tp1>
        allocator(const allocator<_Tp1>&) throw() {}
      ~allocator() throw() {}

      pointer
      address(reference __x) const { return &__x; }

      const_pointer
      address(const_reference __x) const { return &__x; }

      // NB: __n is permitted to be 0.  The C++ standard says nothing
      // about what the return value is when __n == 0.
      _Tp*
      allocate(size_type __n, const void* = 0)
      {
	_Tp* __ret = 0;
	if (__n)
	  {
	    if (__n <= this->max_size())
	      __ret = static_cast<_Tp*>(_Alloc::allocate(__n * sizeof(_Tp)));
	    else
	      __throw_bad_alloc();
	  }
	return __ret;
      }

      // __p is not permitted to be a null pointer.
      void
      deallocate(pointer __p, size_type __n)
      { _Alloc::deallocate(__p, __n * sizeof(_Tp)); }

      size_type
      max_size() const throw() { return size_t(-1) / sizeof(_Tp); }

      // _GLIBCXX_RESOLVE_LIB_DEFECTS
      // 402. wrong new expression in [some_]allocator::construct
      void construct(pointer __p, const _Tp& __val)
      { ::new(__p) _Tp(__val); }

      void destroy(pointer __p) { __p->~_Tp(); }
    };

-- 
Regards,
Steven