Re: [CEDET-devel] return values with locally scoped types
Brought to you by:
zappo
From: Eric M. L. <er...@si...> - 2011-05-27 01:46:31
|
Hi David, Interesting new issues. To figure out performance, just put the cursor on some example, and do: M-x semantic-elp-analyze RET I would guess your code won't do much if the local context doesn't have the case where this extra work is needed?? That would be the best solution as a little performance issue is fine for more complex problems. Eric On 05/23/2011 02:04 PM, David Engster wrote: > Eric M. Ludlam writes: >> That looks exactly like what I expected. This would be great to check >> in. With a bonus test too. Huzzah! > > Well, I've changed my mind. :-) > > I'm afraid just including the parent into the scope is not > enough. Consider the following example: > > ------------------------------------------- > namespace foo { > struct myStruct {int foo1; int foo2;}; > > class MyClass > { > public: > myStruct bla; > }; > } > > void func() > { > foo::MyClass c; > c.bla. // Complete here > } > ------------------------------------------- > > 'myStruct' is member of the namespace 'foo', but not of 'MyClass'. And > now, just for fun, let's throw a template and typedef into the mix: > > --------------------------------------- > namespace foo { > > template<typename _T> > struct myStruct {_T foo1; _T foo2;}; > > template<typename T> > class MyClass > { > public: > typedef myStruct<T> myType; > myType bla; > }; > } > > void func() > { > foo::MyClass<int> c; > c.bla. // Complete here > } > -------------------------------------- > > While Semantic does find 'foo1/2', it assumes those are of type > 'T'. This is because the dereferencer doesn't get the chance to > dereference the template and the typedef at the same time; it will first > dereference the template for MyClass when dealing with 'c', and it will > then separately deal with the typedef when looking at 'bla'. However, > there it will only see 'MyClass<T>' as the parent and not > 'MyClass<myStruct>', which obviously doesn't exist anywhere in written > form. > > Here's a snippet which should deal with both: > > --- trunk/semantic/semantic-analyze.el 2011-03-09 12:09:43.000000000 +0100 > +++ poly-template/semantic/semantic-analyze.el 2011-05-23 17:43:27.000000000 +0200 > @@ -341,6 +341,21 @@ > (when (and fname (semantic-tag-p tmp) > (not (semantic-tag-in-buffer-p tmp))) > (semantic--tag-put-property tmp :filename fname)) > + > + (when (and tmp (semantic-tag-p tmp)) > + (let ((tagscope > + (save-excursion > + (semantic-go-to-tag tmp) > + (semantic-calculate-scope))) > + (rawscope > + (semantic-tag-type-members tmptype) > + )) > + (when tagscope > + (oset scope fullscope > + (append rawscope > + (oref tagscope fullscope) > + (oref scope fullscope)))))) > + > (setq tag (cons tmp tag)) > (setq tagtype (cons tmptype tagtype)) > ) > > > In words: > > - Calculate a local scope for 'tmp' (which in the first example is > 'foo::MyClass::bla') and include it into scope. > > - Include all the type members of the type we're currently dealing > with (in the second example those are the members of the > dereferenced 'MyClass<int>'). It's also important that those members > are at the front of the scope list. > > I haven't tested this fully; I'm also not sure how this will affect > speed (how expensive is `semantic-calculate-scope'?). I probably will > have to benchmark this. But maybe you have a better idea? > > BTW, it might be that the second example doesn't work at all with > trunk. I'm working with my local branch, which already has a ton of > changes to better deal with templates... > > -David > > ------------------------------------------------------------------------------ > What Every C/C++ and Fortran developer Should Know! > Read this article and learn how Intel has extended the reach of its > next-generation tools to help Windows* and Linux* C/C++ and Fortran > developers boost performance applications - including clusters. > http://p.sf.net/sfu/intel-dev2devmay > _______________________________________________ > Cedet-devel mailing list > Ced...@li... > https://lists.sourceforge.net/lists/listinfo/cedet-devel > |