David Engster <deng@randomsample.de> writes:
> Pieter Swinkels <swinkels.pieter@yahoo.com> writes:
>> While on the subject of STL, if I have a declaration such as
>> "std::vector<MyType> v;", completing something like "v[0]." expands as
>> if v[0] is a std::vector instead of a MyType. Is this to be expected?

[...]

> The support for overloaded operators in Semantic is still a bit
> sparse. I suppose we have to add another dereferencer for this case...

Writing the dereferencer won't be a problem - it roughly has to do the
same thing as semantic-c-dereference-member-of, i.e., returning the type
of the 'operator[]' function.

However, doing this for the 'vector' class turned out to be
difficult. The reason is that 'operator[]' from the 'vector' class
returns a 'const_reference', which via several typedef's turns out to be
allocator<TYPE>::const_reference, which is yet another typedef for
'const TYPE&'.

Semantic currently has difficulties parsing the STL allocator class. If
you open bits/allocator.h, you'll see that it roughly boils down to


  template<typename _Tp>
    class allocator;

  /// allocator<void> specialization.
  template<>
    class allocator<void>
    {
    public:
	 typedef const void* const_pointer;
    };

  template<typename _Tp>
    class allocator
    {
   public:
      typedef const _Tp* const_pointer;
      typedef const _Tp& const_reference;
  };


Two problems:

i) Semantic does not recognize

      typedef const _Tp& const_reference;

as a typedef; it has no problems with the previous 'const_pointer',
though. I could fix this through the attached patch to c.by, which adds
an 'opt-ref' to the typedefname rule. This doesn't set the 'reference'
attribute for the tag, but I don't think that this will matter much.

ii) The <void> specialization hides the general implementation. That
means, if you try to complete 'allocator<int>::const_', it will only
return 'const_pointer'. I'm not sure where and how to fix this one.

Regards,
David