Running cppcheck on my project gives me about 80% ouput about library files instead of my code.
Is there a way to tell cppcheck to only search library(-headers) for definitions and such but not actually perform checks?
Or at least to supress the output for those files?
Or, even better, save the gathered information somewhere for re-use, as the library code is not likely to change for the next run?
I am a Cppcheck dev. Not currently. But I do believe that we should not warn about library headers.
Feel free to write some comments here if you want:
http://sourceforge.net/apps/trac/cppcheck/ticket/3390
Related
I'm working with a program, full of compiler directives, programmed in Visual Studio.
I've made some changes and now I'm stuck with an unresolved external compiler/linker error.
I believe this is caused by the compiler directives, which seem not to detect the implementation of that particular function, and in order to investigate this, I'd like to follow the #ifdef compiler directives throughout the compilation process.
I've already tried using the /P configuration, but I don't see any compiler directive in the Output window.
Does anybody know how to do this?
I think you're on the right track with the /P option, but the doc states that the output will go to files with a .i extension (so probably not to your Output window).
Further, you may be able to find some help on any linker errors by generating a map file; see /MAP (Generate Mapfile).
Our product uses C++ as the programming language. One annoying issue of using C++ STL is that we forget to include the necessary header files, because the file may have been included in some other STL header, the build passes. For example,
In Mac platform using Xcode, if I use std::auto_ptr without include memory.h but include iostream.h, the build will pass, but it will fail in Android platform.
But I don't want move the code to Android for an build check for each code change commit. So, is there anyway to avoid that problem?
Edit 1:
I know the best solution is to not forget the include the header. But developers make mistakes. So is there any tool to help check it?
Edit 2:
Seams no ideal solution, so I will use vim script to check it in my editor,the solution is similar to https://github.com/vim-scripts/vim-cpp-auto-include/blob/master/ftplugin/cpp_auto_include.vim
You can use a common_includes.h file that includes all necessary files there, and include that file everywhere you need. This will simplify the situation and will help out forgetting to include some file. At least you will forget it only one time :).
The only tool I know of... is the compiler itself.
Whenever the issue is portability, the best solution I have seen was to simply put on automated build/test suites for all required environments. Then, whenever a pull request is made it will be validated on all your build bots, and you will be warned if you forgot something.
I've taken the "edge" sample file and moved the appropriate source files into the directory, changing #include(s) where needed to account for the directory structure and not being setup with the library and all that. The goal being to make a more portable batch of code to try some things out. I was wondering, given the list of linker errors (lots of undefined this and that.) Would it A, be possible to take the source and include it all in a way that I won't need linking? And if so B, what would be the suggested route to find which source files have the right code to counter all the undefined stuff I get while linking?
I understand this is a general question, but it requires a general answer and I haven't seen anyone answer this here or anywhere else. I would think it's entirely possible though, OpenCV is BSD and all the source to compile it into the library is available, so I would imagine you could skip the linking to an external library step if you had the source for the library in your project code. Thanks a million to whoever can help me out or lead me into the right direction, it's much appreciated.
If your project requires fully open source code, you can do what you want. Of course, to isolate what you need from OpenCV will be a demanding task. To do that, you need to manually locate the files including the missing objects. In MS explorer you search using "inside the file" query, in linux console you can use "find | grep" combo command.
I sometimes move source files(opencv/modules/*/src) locally in my projects to customize some functions. I also keep the linked libraries which compiler puts second in priority and they become inactive but they still exists in their original form occupying some negligible useless MBs.
I have a legacy C++ application with a deep graph of #includes. Changes to any header file often cause recompiles of seemingly unrelated source files.
The application is built using a Visual Studio 2005 solution (sln) file.
Can MSBUILD be invoked in a way that it reports which dependency(ies) are causing a source file to be recompiled?
Is there any other tool that might be able to help?
NOTE: I'm only looking for a tool to tell me why a file would be rebuilt, not some restrospective magic telling me why it was rebuilt.
If you dial up the verbosity to detailed or above (Tools>Options>Project>Build or /v:detailed) then MSBuild will log, just before it runs the compiler, exactly what header file or source file caused it to run the compiler.
Is that what you're asking for?
Dan/MSBuild
There is a utility called makedepend. It is available on Unix platforms. On Window you can find a similar perl script here.
I do not think MSBUILD takes care of dependency.
You probably need Include Finder (http://www.softpedia.com/progDownload/Include-Finder-Download-83403.html).
We are migrating our works repository so I want to do a cull of all the unreferenced files that exist in the source tree before moving it into the nice fresh (empty) repository.
So far I have gone through by hand and found all the unreferenced files that I know about but I want to find out if I have caught them all. One way would be to manually move the project file by file to a new folder and see what sticks when compiling. That will take all week, so I need an automated tool.
What do people suggest?
Clarifications:
1) It is C++.
2) The files are mixed. I am looking for files that have been superseded by others but have left to rot in the repository - for instance file_iter.h is not referenced by any other file in the program but remains in the repository just in case someone wants to compile a version from 1996! Now we are moving to a fresh repository we can safely junk all the files that are no longer used.
3) Lint only finds unused includes - not unused files (I have the 7.5 manual in front of me).
You've tagged this post with c++, so I'm assuming that's the language in question. If that's the only thing that's in the repository then it shouldn't be too hard to grep all files in the repository for each filename to give you a good starting point. If the repository contains other files (metadata, support files, resources, etc) then you're probably going to need to do it manually.
I can't offer an existing tool for it, but I would expect that you can get a lot of this information from you build tools (with some effort, probably). Typically you can at least let the build tool print the commands it would run, without actually running them. (E.g. the -n option of make and bjam does this.) From it you should be able to extract at least the used source files.
With the -MM of g++ you can get all the non-system header files for the given source files. The output is in the form of a make rule, but with some filtering this shouldn't be a problem.
I don't know if this helps; it's just what I would try in your situation.
You can actually do this indirectly with Lint by running a "whole project analysis" (in which all files are analysed together rather than individually).
Configure it to ignore everything but unreferenced variable/enum/function etc warnings and it should give you a reasonable indicator of where the deadwood lies without those issues being obscured by any others in the codebase.
A static source code analysis tool like lint might do the job. They will tell you if a piece of code will never be called.
Have you taken a look at Source-Navigator? It can be used as an IDE but I found to be very good at analyzing source code structure. For example, it can find out where and if a certain method is used in your source code.
I don't know if it's scriptable but it might be a good starting point for you.