Version: 3.3.3 (using KDE KDE 3.5.4) Installed from: Gentoo Packages OS: Linux When there are multiple defines in a file, the make member button disappears. Here is an example: #ifndef __FILE_H_INCLUDED__ #define __FILE_H_INCLUDED__ #ifdef HAVE_CONFIG_H #include "config.h" #endif #ifdef HAVE_SOMELIB class x { void foo(); }; #endif #endif When right-clicking on foo there is no make member option.
I can confirm this problem with kdevelop-3.3.4 as well (on Gentoo). Its kind of anoying. One guess is that maybe kdevelop doesn't define HAVE_CONFIG_H?
I also just noticed that that 'Document Current Function' feature is broken in the same way. If you are working inside some ifdef then it does nothing.
I don't really think this is a bug. The parser needs to resolve the macro in order to understand it. There are three ways to attempt to solve this in current 3.4 branch: 1. define the macro locally 2. Settings -> Configure KDevelop -> C++ Parsing - register the macro there 3. Project -> Project Options -> C++ Support -> Code Completion - "Preprocess included headers" - note that this will in many cases be really slow.
As Jens described, this can be solved by letting the parser know about the define in C++Parsing dialog. Closing.
*** Bug 60512 has been marked as a duplicate of this bug. ***
*** Bug 89550 has been marked as a duplicate of this bug. ***
*** Bug 139914 has been marked as a duplicate of this bug. ***
I vote the status be changed. I'm dealing with a situation where I've got macros in virtual class method declarations, in my library header files. These virtual methods are overridden in my executable projects, which require these macros to be included in the declarations. Consequently, I've got to put all of these macros into the C++ Parsing for all of my executable projects, or I've got redded-out code everywhere.
To what should this be changed? There's a way to make this work. Copying/pasting a few dozen macro's shouldn't be a problem, apart from that: Macro's are BAD ;)
It should be changed such that the red line doesn't appear unless there truly is a syntax error. If there's any chance at all that the line in question might not generate an error for the designated language, I think it should give the programmer the benefit of the doubt. Why are macros bad? They are bad if you try to use them as functions in C++, but in one case, I have little choice. I've got a pure virtual that I want to assign an __attribute__((fastcall)) to. That attribute is meaningless if building for x86-64, but useful in i386. Furthermore, if I ever decide to take away that fastcall for all environments, then I'd have to hunt down every override, because if you neglect to assign the proper calling convention, Gnu does *not* generate a compile error, but you'll have a very obscure bug at run-time. And I did try adding the macro to C++ Parsing, and it still red-lines the code.
Adding support for macros in KDev3's parser is not going to happen, unless you find somebody to do it or do it yourself. The parser is hand-written, undocumented and the original author doesn't want to work on it anymore. Yes this is not a good thing, but we have to live with it. If adding the complete macro definition to the C++ Parsing page doesn't help thats a different error which you may file as new bugreport. However I doubt that will get fixed in KDev3 either, because currently the person that knows this stuff best doesn't have time to work on KDevelop3. And nobody else wants to invest the time to learn how all this works.
@Andreas KDevelop does support macros, and it supports every aspect of them. @Angus In the c++ options "preprocess included headers" should be enabled, and maybe the experimental include-path resolution if it works. If it doesn't, the include-path should be filled so the headers that contain the problematic macros can be found. Then there should be no problem!
David: Variadic macros are still not supported :(