Community
Participate
Working Groups
Build Identifier: 201006141710 This has been a gripe of an otherwise amazingly useful feature for years. Now with 3.6, it's still here. Some of the time, pressing F3 on the function name will jump to its definition in the .C file. Pressing F3 again will start alternating between the .h declaration and the .C definition, which is perfect, and is exactly what I want. Now, this behavior is very inconsistent. In a lot of cases, it will only jump to the .h file and subsequent F3s will not do anything, even though the definition is wide open in the .C. Sure - F3 is Open DECLARATION, fair enough - then why does it jump to the definition some of the time (see above)? Furthermore, there's an actual Open Definition (Ctrl-F3) which is only visible from Preferences->Keys and doesn't actually do anything. Reproducible: Always Steps to Reproduce: See details.
My version is actually 7.0.0.201006141710.
(In reply to comment #0) > ... > Some of the time, pressing F3 on the function name will jump to its definition > in the .C file. Pressing F3 again will start alternating between the .h > declaration and the .C definition, which is perfect, and is exactly what I > want. That is the intended behavior. > Now, this behavior is very inconsistent. In a lot of cases, it will only jump > to the .h file and subsequent F3s will not do anything, even though the > definition is wide open in the .C. > .... Please provide instructions on how to reproduce such a problem. For example you can create a minimal project that shows the issue and attach it. > ... > Furthermore, there's an actual Open Definition (Ctrl-F3) which is only visible > from Preferences->Keys and doesn't actually do anything. The command should not be there, I'll remove it (see bug 167162).
Created attachment 178020 [details] removes the (unimplemented) open definition command Removed 'Open Definition' command in 8.0 > 20100902.
The problem is present in our quite complicated project. I'm not sure I'll be able to easily reproduce this but I can try when I get time. I know it's hard to go on without knowing where exactly the problem lies but I'm not sure I'll be able to come up with an isolated test case. Please go off the assumption for now that you will not get a test case.
*** cdt cvs genie on behalf of mschorn *** Bug 324262: Remove command for 'Open Definition'. [*] plugin.properties 1.205 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-core/org.eclipse.cdt.ui/plugin.properties?root=Tools_Project&r1=1.204&r2=1.205 [*] plugin.xml 1.386 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-core/org.eclipse.cdt.ui/plugin.xml?root=Tools_Project&r1=1.385&r2=1.386
I also see this problem in my project. This is also a pretty large project, and I am not really at liberty to share the entire source code, but I'll try to put together a small test project later. In the mean time, perhaps the following helps. In a .h file in my project, I have: FTC_t DoGetInterface(const char_t* pInterfaceName, void** ppInterface); void foo(char* bla); Both methods are defined in the corresponding .cpp file (in the same directory). The FTC_t type is typedef'ed elsewhere (in a separate .h file, living in another directory in the same project). For 'foo', the F3 behaviour is fine; for DoGetInterface it is not (F3 gets me the declaration, but not the definition). When I change 'foo' to return an FTC_t (both in the .h file and the .cpp file), the F3 behavior no longer works -- I still get to the declaration from anywhere in the source code, but not to the definition.
I think I tracked mine down to the same thing. For example, HttpResultPtr HttpsConnection::Post() where HttpResultPtr is defined in the .h of the same file as typedef boost::shared_ptr<HttpResult> HttpResultPtr; If I change HttpResultPtr to HttpResult* just to test, Open Declaration works just fine. Additionally, we use the following MACRO instead of typedef at times, which is also not parsed correctly, for the same reason: DECLARE_BOOST_TYPES(GdTag); Here's the definition: #define DECLARE_BOOST_TYPES(classname) \ class classname; \ typedef boost::shared_ptr<classname> classname ## Ptr; \ typedef std::vector<classname ## Ptr> classname ## PtrVec; \ typedef std::map<ub4, classname ## Ptr> Ub4To ## classname ## PtrMap; \ typedef std::multimap<ub4, classname ## Ptr> Ub4To ## classname ## PtrMultiMap; \ typedef std::map<ub8, classname ## Ptr> Ub8To ## classname ## PtrMap; \ typedef std::multimap<ub8, classname ## Ptr> Ub8To ## classname ## PtrMultiMap; \ etc ...
I have removed the superfluous command in 8.0. Where the navigation to a definition does not work it is very likely that we have a problem parsing the code at that point. Please file bugs with specific examples for that.
