Community
Participate
Working Groups
In C++11 you can write auto myThing = someVector[i].someMember().field; if you need to factor out the subexpression "someVector[i].someMember().field" in some piece of code. Note that you do not need to worry about spelling out the type unless you want to. In C++98, this would have to be std::map<std::string, std::pair<::time_t, std::vector<int> > > myThing = someVector[i].someMember().field; likely leading people to prefer to write the subexpression "someVector[i].someMember().field" directly in several places. Typedefs may help, but merely uniquely naming, spelling and internalising the definitions of such typedefs can be more trouble than it's worth. My suggestion is that if the specified type matches exactly the type of the expression on the right of the assignment, that the type expression be optionally de-emphasised (e.g. greyed out), or perhaps replaced completely by a graphical indicator (for those who do not care about column alignment). If the type does not match but there is a valid implicit conversion, either the existing rendering or some other emphasis could indicate to the user that something is going on. This would allow the developer to focus directly on the important parts of the code, rather than having to visually scan over verbose or unutterable type annotations. Thanks
Why not just refactor the code to use 'auto'?
A few reasons: * A lot of codebases are stuck supporting pre-C++11 - I work at a large company that is dependent on some big old enterprise UNIX vendors and their compilers are not up to scratch for C++11. * Despite my own preferences for "AAA" ("almost always auto"), many programming style guides prohibit this even in C++11 and mandate cases where types should be explicitly named. It would be useful if the editor helped here. * Users of legacy codebases that have moved to C++11 (and beyond) may benefit from this kind of editor feature to identify places where "auto" could (though not necessarily should) be used. By the way, does this feature seem easy? I've been looking for a reason to start hacking on Eclipse for a while, now... Thanks
(In reply to Alexander Jones from comment #2) > By the way, does this feature seem easy? I've been looking for a reason to > start hacking on Eclipse for a while, now... It shouldn't be too difficult. Here's how I would do it: - Introduce a new semantic highlighting, which will be listed in Window -> Preferences -> C/C++ -> Editor -> Syntax Coloring -> Code alongide the existing ones ("Braces", "Built-in types", and so on). You can call it "De-emphasized type name", or something like that, and make its default color grey. There is some boilerplate involved in doing this. You can use the changes I made to org.eclipse.cdt.ui in Patch Set 1 of this gerrit change [1] to add a new semantic highlighting for context-sensitive keywords, as a guide. (Note, if you do this: - Be sure sure you're looking at Patch Set 1. By default, gerrit shows you the latest patch set, Patch Set 6. - Look at the changes to org.eclipse.cdt.ui only. The changes to org.eclipse.cdt.core are parser changes related to context-sensitive keywords, which aren't relevant here.) - The interesting code will be in the consumes() method of your new semantic highlighting, which decides whether the highlighting should apply to a particular token in the code. Here, I would do this: - Walk up the AST from the token, to the nearest enclosing decl-specifier (if any). - See if the decl-specifier is part of a simple-declaration, and if that simple-declaration is declaring a variable (as opposed to a function or class). --> If so, your token is part of the type name of a variable declaration. - See if the simple-declaration includes an initializer. - Resolve the declared type of the variable. - Resolve the type of the initializer expression. - Compare the two types and decide if de-emphasizing the declared type of the variable is warranted. --> If so, you want to apply the highlighting to the token. If you're interested in working on this, I'm happy to provide guidance. (Note: all this assumes you want the "greyed out" approach. If you want the "replaced by a visual indicator" approach, that would probably involve deeper changes to the editor UI, which I know very little about.) [1] https://git.eclipse.org/r/#/c/24513/
