Hi Eric,

It's progressing :

variable declaration recognized with template specifier : ok

in semantic-analyze-tag-type I've both the variableTag plus its classTag.
so here I’ can :
  - if in classTag there is a "->" function, I can replace classTag with the one returned by the "->" function (in case of template I use variableTag.template-specifier classTag)

but

* I’ don’t know if its correct to deal with a specific language issue in a non language-specific function.

* I’ think it’s more correct to set classTag to the class returned bye the -> operator (if a c++ class redefine the "->" operator it want to act like a pointer of the type returned by the operator) rather than to the class owning the -> operator. Ideally it has to be determined by the context (is the token followed by a "->" or a "." maybe with overlay info, but now I don't know where to find this info. Another compromise is to mix the slots of both class : the original + the pointed one, but it sound difficult, and also I’ don’t know how.

Do you think semantic-analyze-tag-type is the correct place to handle this ?
Any risks of bad side effects here ?

For now I've just written dirty code to see if it can work, and it do in my limited test cases.

I’ will propose you a patch when I’ will find the time to write cleaner code.

Any hints are welcome.

thanks.

raf.

Eric M. Ludlam a écrit :
Hi,

I knew operator overloads would eventually show up. :)  I've looked
into this before, and it is not an incremental change.

The existing parser parses templates just enough to get past them, and
that works for a large number of templated classes.

The preprocessor cannot do substitutions for anything other than
symbols.  This is as intended.  A full up lexical redefinition would
be needed.

As you suggest below, the "right" solution is to remember the template
specifier for variables.  This seems like the best approach, and
should be handled in the derived datatype of the variable.  All the
type dereferencing through the template specifier could then be
handled nicely as a minor C++ tweak.

In c.by, typeformbase already has a comment waiting to be modified.
Perhaps like this:

*** c.by.~1.49.~	2008-09-19 23:29:45.000000000 -0400
--- c.by	2008-11-21 11:49:50.000000000 -0500
***************
*** 664,671 ****
      (TYPE-TAG $2 $1 nil nil )
    | builtintype
      ( ,$1 )
!  ;;| symbol template-specifier
!  ;;  ( $1 type "class" )
   ;;| namespace-symbol opt-stars opt-template-specifier
   ;;| namespace-symbol opt-template-specifier
    | namespace-symbol opt-template-specifier
--- 664,671 ----
      (TYPE-TAG $2 $1 nil nil )
    | builtintype
      ( ,$1 )
!   | symbol template-specifier
!     (TYPE-TAG $1 "class" nil nil :template-specifier $2)
   ;;| namespace-symbol opt-stars opt-template-specifier
   ;;| namespace-symbol opt-template-specifier
    | namespace-symbol opt-template-specifier
----------------------------

would get you just far enough to get by w/ non-namespace based
symbols.  Ideally someone would get around to a parser re-write in
wisent which is sorely needed.

Anyway, once that is available, the name and datatype resolver in the
analyzer would need to be made aware of template specifiers, and the
context parser would need to start tracking operator overloading.

I'd be happy to work through some of this if you don't mind working
through some of the issues w/ me.

Eric

  
Raf <raf.ml@free.fr> seems to think that:
        
Hello,

I'm currently testing the CVS version of semantic. Thanks for this great 
and impressive tool.

I'm trying to make completion for smart_pointer to work (since most of 
my code use it).

here is a sample :
-----------------------------------
template class<T>
class ref<T> {
public:
 T* operator->();
};


class Foo {
public:
 int getValue();  
 double getResult();
};


void
main(void) {
 ref<Foo> d;

 d->;
}
-------------------------------------

=> I've tried this :
(setq semantic-lex-c-preprocessor-symbol-map
     '(
       ( "ref<Foo>" . ((symbol "Foo" 1 1) (punctuation "*" 1 1)) )
      ))

but it doesn't work because of the "<" character in the keyword.

=> I've looking in c.by
here the template parameters of the variable declaration seems to be 
ignored :

namespace-symbol
 : symbol opt-template-specifier COLON COLON namespace-symbol
   ( (concat $1 "::" (car $5)) )
 | symbol opt-template-specifier
   ( $1 )
 ;

It would be nice if we could set a variable that drive substitutions 
before the lexer start.
Something like "'ref<Foo>' should be read as 'Foo *'"
this would add smart_pointer completion support by just a fews lines 
(there is usually fews smart pointers types, so identifying them in a 
variable is no pain and a lot benefits)

ideally the parser should produce tag with the corrects infos, but maybe 
it's too complicated for just one use case. (the type tag already have 
the infos, but not the variable tag)

thanks in advance for any hints, help, suggestions on how to make this work.

raf.
    
  [ ... ]