11–20 of 43 posts
It also does nothing smart, it is user trained. Every symbol prefixed with a namespace you are interested in will be presented to you, and you must tell it where to find the symbol. Any other symbols will be ignored.
For example, I used a module prefix consistently in my code so that any occurrence of an "Xyz_" prefix in a file would pretty much guarantee that "Xyz.h" is required to compile. I also put all local #include references in the same part of the file under a predictable comment header. That way, I didn't need a C++ parser; I just needed to know where to start searching for the list of headers, infer prefixes from their names, and complain about prefixes that were not found in the rest of the file. This has worked surprisingly well, and I can tune the script to skip modules for any reason.
This is also important for the reverse case. I don't really need an IDE or ctags to figure out what file is needed for a #include in most cases because I have the name of the function/type/constant/etc. to guide me. Similarly, I know exactly what file to open in my editor without using magic tricks. (Although, code completion and jump-to-definition are still quite helpful, especially for things like OS calls that may follow no particular convention.)
However wrt this project I just looked at the "Instructions for Users" and it tells me how to build it and that I need to observe this and that and a lot of other things for it not to go wrong. Sorry, I just don't have the time for that. Why not just provide binaries for the most important platforms?
Personally I don't like this. Often enough there's includes in headers, which are an implementation detail for the functionality in the originally included header. Iwyu will just include that, increasing coupling between components.
I don't get it, can you give an example?
(e.g. https://github.com/Itseez/opencv/blob/master/include/opencv2...)
A tool like this would see right through that and walk the tree all the way to the final leaf headers that actually implement the parts you use. This not only means one single include will balloon to many smaller ones, but when the library moves things around internally your code will break.
(Unclear if this is what this tool in particular will do, but I've certainly seen this behavior with Clion for example when it recommends what header to include.)
I would love if imperfect #includes (what I understand this tool is supposed to point out) simply became a compile warning and part of the toolchain. I would love such a feature and would use it a lot. However wrt this project I just looked at the "Instructions for Users" and it tells me how to build it and that I need to observe this and that and a lot of other things for it not to go wrong. Sorry, I just don't have…
I'm trying to get into refactoring (and even semantic analysis, and code-generation) for large C++ codebases using libclang, libtool, and the ilk. Any guides to get started, and/or best practices? Does it increase productivity by order of magnitude? (I'd like to think so. I think it's madness not to use any AST tool when working on large codebases). Also I'm assuming "white-box" C/C++ tools like libclang/libtooling a…
howto: https://wiki.documentfoundation.org/Development/Clang_plugin...
code: http://cgit.freedesktop.org/libreoffice/core/tree/compilerpl...
Personally I don't like this. Often enough there's includes in headers, which are an implementation detail for the functionality in the originally included header. Iwyu will just include that, increasing coupling between components.
I don't get it, can you give an example?
Personally I don't like this. Often enough there's includes in headers, which are an implementation detail for the functionality in the originally included header. Iwyu will just include that, increasing coupling between components.
I don't think the program does that, if I understand your post. A more accurate name might b "exclude what you don't use." It doesn't add in chained includes, it just lets you know about superfluous includes.