Bugzilla – Full Text Bug Listing
| Summary: | Open declaration doesn't switch to code implementation | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | guy bonneau <guy.bonneau> | ||||||||
| Component: | cdt-indexer | Assignee: | Project Inbox <cdt-indexer-inbox> | ||||||||
| Status: | CLOSED FIXED | QA Contact: | Markus Schorn <mschorn.eclipse> | ||||||||
| Severity: | normal | ||||||||||
| Priority: | P3 | CC: | aegges, cdtdoug, guy.bonneau | ||||||||
| Version: | 8.0 | ||||||||||
| Target Milestone: | --- | ||||||||||
| Hardware: | All | ||||||||||
| OS: | All | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
guy bonneau
(In reply to comment #0) > Build Identifier: Build id: 20100617-1415 > > On complex class definition the CDT indexer doesn't switch to code > implementation when open declaration (F3) is executed on method members of the > class. > > Reproducible: Always > > Steps to Reproduce: > I cannot reproduce the problem with simple class. I am able to reproduce this > problem with complex class definition. The Intel Performance Primitive (IPP) > library codec samples is an example that will fail. > > To reproduce either on Windows or Linux > > 1- Register a trial for the Intel IPP library at > http://software.intel.com/en-us/articles/intel-ipp/ > 2- Download the Intel IPP version 6.1 update 5 or 6 > 3- Download the Intel IPP Samples > 4- Install the Intel IPP Library > 5- Unpack the IPP Samples Codes to an Eclipse workspace > 6- Define a new C++ library project media_buffers and link the sources to > folder \ipp-samples\audio-video-codecs\io\media_buffers > 7- Add the path of the include files of the Intel IPP library to the project > media_buffers. > 8- If you work on Linux defines the preprocessor LINUX32 > 9- Try to open the declaration of a few members of class FrameConstructor. Its > fail. > > If you have any problem to setup the project please contact me. I cannot reporoduce this. When I try to open members of class FrameConstructor it will send me to the definition. Could you please specifiy which member fails? I guess the best would be to name the source file and the line. Did you encounter problems with members of type e.g. "Ipp32s" ? Then how did you add the IPP include path? Usually for an external library you go to Project Properties->C/C++ General->Paths and Symbols->Includes and then add the path to the IPP installation (the includes folder) for the C Language (be aware that C and C++ can have different inclue paths!). 1- Open include file umc_frame_constructor.h 2- Goto line 349 which is the definition of FrameContructor:Reset() 3- Try to open the declaration (F3) of method Reset(). It will stay in the include file and will not switch to the code implementation. 4- Same things with members method Init Stop LockInputBuffer LockOutputBuffer Close I did not encounter any problem with Ipp32s. I did setup the project the same way you did. And yes I am aware that C and C++ project must be setup separately. I have included a jpeg picture of the IDE when I have the issue . Note that I have tried with NetBeans 6.9.1 with the same setting and the C++ indexer work perfectly and bring me to the code implementation. Created attachment 182206 [details]
Eclipse workspace IDE with the Issue
Eclipse workspace IDE with the Issue
(In reply to comment #2) > 1- Open include file umc_frame_constructor.h > 2- Goto line 349 which is the definition of FrameContructor:Reset() > 3- Try to open the declaration (F3) of method Reset(). It will stay in the > include file and will not switch to the code implementation. > 4- Same things with members method Init Stop LockInputBuffer LockOutputBuffer > Close OK, I see the problem. The methods are declared virtual. Bug #64594 described this problem and the solution was not to fix it :( I'm not happy with this solution. I would prefer to get a list of all possible implementations (see https://bugs.eclipse.org/bugs/show_bug.cgi?id=64594#c1 ). Created attachment 182225 [details]
Basic project (source file)
Created attachment 182226 [details]
Basic Project (Include file)
I am missing something!!! I understand that if a method is pure virtual it will stay at where it should : in the definition of the include file since there is no implementation. However if the method is not pure virtual it should switch to the code implementation. This is in fact the behavior I see with a basic project with Eclipse Helios CDT. I have attached a basic project to this issue to demonstrate this and so you can check by yourself. Thus I am somewhat confused that the behavior of the IPP samples code of class FrameConstructor is not consistent with the basic project I have attached to this issue. (In reply to comment #7) > I am missing something!!! > > I understand that if a method is pure virtual it will stay at where it should : > in the definition of the include file since there is no implementation. > > However if the method is not pure virtual it should switch to the code > implementation. > > This is in fact the behavior I see with a basic project with Eclipse Helios > CDT. I have attached a basic project to this issue to demonstrate this and so > you can check by yourself. Thus I am somewhat confused that the behavior of the > IPP samples code of class FrameConstructor is not consistent with the basic > project I have attached to this issue. In your example you have an implementation of e.g. Method1() in every derived class. When you remove the implementation of BClass::Method1() in the cpp file and then try to go to the implemtation from the header (line 36) nothing will happen (like in the case for the Intel code). I would expect that it will bring me to the base class implementation AClass::Method1(). I'm not sure if I was clear enough in my explanations. The issue happens when I am in the main editor windows. Not the outline windows.
The CDT can't go to a member virtual function if no implementation exist. I agree with this of course and this is the expected behavior. But if you check the code implementation of class FrameConstructor in file umc_frame_constructor.cpp the member virtual functions:
virtual Status Init(MediaReceiverParams *pInit);
virtual Status Close();
virtual Status Reset();
virtual Status Stop();
do exist and have a code implementation with class FrameConstructor even thought those virtual member functions are also overriden in other derived class.
For example in the basic example the CDT indexer bring me to the code implementation of the base AClass::Method1() when I do F3 in the AClass definition of the include file while the cursor focus is set to the AClass::Method1() (in the main editor windows) and bring me to the code implementation of the derived class BClass::Method1() when I do F3 (in the main editor windows) in the BClass definition of the include file while the cursor focus is set to the BClass::Method1().
Then when I try to do the same with the Intel IPP media_buffers project it is my understanding that the behavior doesn't seem to be consistent because the CDT indexer doesn't bring me to the code implementation like the basic project.
(In reply to comment #9) > I'm not sure if I was clear enough in my explanations. The issue happens when I > am in the main editor windows. Not the outline windows. I know. Your explanations were clear. But I made a mistake. Your bug is of course valid. The class FrameConstructor has indeed its own implementation for the method Reset(). I have overseen it using the Type Hierarchy View which, of course, uses the wrong info from the indexer. Ah! I got the indexer working correctly for the IPP case. I had to add the include paths for IPP lib not only to the C language but also for C++. I don't know why this affects the indexer because the IPP headers (e.g. ipps.h) are pure C and are not relevant for the class definition of FrameConstructor! Ah again! I got it. The problematic method definition is: virtual Status Reset(); The type status is typedefed: typedef Ipp32s Status; and the type Ipp32s is defined in some of the IPP lib headers. So if the indexer cannot resolve this type (because the include path was not added to C++), it does not know what to do with this method. => The indexer works correctly if parametrized correctly. This renders the bug invalid. Do you agree? If yes, then please close this bug (I don't have the right to do it). I will close the bug ! Many many thanks for the help. However before I close the bug could you please shed more light for my understanding. This is scaring because how I would know that I needed to setup the C path for the indexer since I setup from my point of view a pure C++ project. As a programmer I wasn't aware that a include file that doesn't has a C++ class definition is seen as a C header (from an indexer point of view). Does that means that when I have a complex project that includes perhaps hundred of include files I didn't wrote and don't know about I will have to check if a related include file is pure C or not ? (In reply to comment #11) > I will close the bug ! > > Many many thanks for the help. > > However before I close the bug could you please shed more light for my > understanding. This is scaring because how I would know that I needed to setup > the C path for the indexer since I setup from my point of view a pure C++ > project. As a programmer I wasn't aware that a include file that doesn't has a > C++ class definition is seen as a C header (from an indexer point of view). > Does that means that when I have a complex project that includes perhaps > hundred of include files I didn't wrote and don't know about I will have to > check if a related include file is pure C or not ? The mistake was to add the include path only for the C language. Important is not the language type of the header (if there is no C++ specific code it can be used for C and C++, respectively). Important is the language type of the source file (.cpp or .c). If the indexer detects that the source file is C++ (it usually uses the file ending .cpp as an indicator) then it will use only the include paths that are defined for C++. So, as a rule of thumb. - When you write pure C code (.c files) then add the include path to the C language. - If you write in C++ (.cpp file) then add the include path to the C++ language (irrespective of the language used in the external lib! You can call C functions in C++!). - If you are using mixed code (your project has .c and .cpp files) then add the include path to both languages. setup configuration problem. Not a Bug |