| Re: [cdt-dev] User survey: More CDT Refactorings - toggle function definition/namespace refactorings |
|
What bothers me most about the
discussion of additional features added to CDT over the last years
is, that most of them are C++ only.
As if C (ANSI/ ISO C89, C90, C99, C11 - did you actually realize, there is now a new C11 standard out?) would not exist anymore and also not used in the field, but on system level and in the embedded world, C is still the language number one. I think here also about some better handling inline assembler functionality (e.g. don't mark the whole module/function as an error, just because it contains inline assembly. Maybe, have a trigger on a function with (configurable) asm keyword in the signature, which could trigger an assembly parser, or use a default one, which at least marks the function ok. The asm dialect could be setup in the project settings (or by language settings provider). The same I already mentioned about Testing Frameworks (like cunit, check, ... compared to Google Test, cppcheck etc.), a lot of refactorings should also be possible for C. Just tried in a the "Toggle Function Definition" on a function in both C-Source and Header File and I get that: An internal error occurred during: "Toggle Function Definition code automation". org.eclipse.cdt.internal.core.dom.parser.c.CASTSimpleDeclSpecifier cannot be cast to org.eclipse.cdt.core.dom.ast.cpp.ICPPASTDeclSpecifier Which pretty much resembles the direction of all the development. For me, as an CDT user from the beginning, this is really frustrating. Especially, since more and more vendors of IDEs in the embedded world are changing (or already have changed) from their former IDEs to Eclipse/CDT based IDEs. I doubt, that the only currently working "Rename" refactoring is the only one that makes sense for C. What about things like, "Change function" .. private vs. public, private meaning, add the prototype to C source file + static keyword, public meaning, add prototype to header + remove static keyword inline (by macro or inline function) or remove inline, inline by macro --> define xx(args) do { ... } while(0) inline as inline function --> static inline xx(..arglist..) { .. } remove inline --> create normal function I'm a bit disappointed by the current direction, and I don't even like to think about the userbase we gain currently from former MSVS, CodeWright, SlickEdit users. I'm going to close this by: * There is no such language named "C/C++" * Don't forget your C user base, while adding (C++ only) features! Am 09.08.2013 15:36, schrieb Peter Sommerlad: Hello Marc-Andre, hello others,It seems users are particularly interested in: - More refactorings - Bug fixes - CMake integration - LLVM/Clang integration What are you thoughts after looking at the results?thank you for the survey and the encouragement that more refactorings are actually needed. It feels great that the work we started around 2005 and nobody believed it could be done now actually gets appreciated... :-) One participant asked for "change function signature" refactoring and I have to say this is very very hard to do well for C++. We tried! There are several reasons, especially when you expect call sites to be adapted, one is overload resolution that might change due to a changed signature, so even if you called the function before the change changing it actually might select a different overload at the call site, another issue my students suffered with is to make the UI useful and pleasing and actually faster to use than changing manually, we couldn't find a good way to implement it and make it usable. Just consider how ugly the Java Change Method Signature dialog is and C++ is much more complex syntactically. ** Therefore, I invented the "toggle function definition" pseudo-refactoring that at least allows one to do the signature change only once without having to use copy-paste or manually edit the signature twice in header and implementation file. This is already part of CDT. We are working on more refactorings, but if money would be involved we could do much more than we can do with students, public grants and profits from other projects. So if companies out there with a budget and interested in better C++ refactorings tell us what you desire. For all the others, have a look what we usually provide as preview of refactorings to come within our unit testing plug-in CUTE. Version 2.0 for beta tests can be found at the following update site http://www.cute-test.com/updatesite/development-2/cute/ >From the refactoring perspective most notable is its "namespactor" refactoring feature that allows to rid your code from either "using namespace" directives or from too many "::" scope resolution operators in fully qualified names. It even allows you to cheat, when your programming conventions forbid using namespace std; by first writing your code with it and then refactoring it away. Feedback is welcome. Best regards Peter. P.S: **Any (great) ideas on what cases to support (wrt overloading) for "change function signature" and how to make it usable in the UI are appreciated. |