Java-docs allows a functionality which lets you show when a function is deprecated. You can put an annotation #Deprecated before the function and it will appear crossed in the code. This is a good mechanism to tell to the rest of the developers that they should avoid to use this function, and is very convenient for refactoring. Is any similar functionality for ColdFusion? Has anyone any workaround for these scenarios?
No there isn't a built in facility to do this, and no real mechanism I can think of you could co-opt to effect the same thing.
It'd be ugly, but all I can think is that you stick a logging line in any deprecated function to log to the application log that a deprecated function has been called. You could probably use some sort of AOP framework / mechanism to allow you to only do this in one place, with the deprecation logger logging for metadata on the deprecated function before it calls it..?
We explicitly throw an error in any deprecated function to let the developers know right away to not use it. Our QA testing will catch and report these errors in lower environments as part of our SDLC.
On top of that, we have our Jenkins server run a series of regex based rules in order to find any new instances of native CF functions which we have deprecated from our code base.
Related
What exactly is an event table and what does it do? I am asking regarding wxWidgets but maybe its a general GUI programming concept, so please correct me on that.
To keep it simple, the evend table tells which function to call when which event occurrs.
However, it is an old way of mapping events to functions.
It is no longer recommanded because isn't very flexible, and use macro tricks to do its job.
Macros themselves are generally not very recommanded in C++.
Unless you must stick to C++03, you should no longer use event tables.
Instead, you should use the bind method for New WXWidgets projects in C++11 or later.
Bind is more flexible, and don't use macro.
You will find this recommandation in the WXWidgets tutorials, too.
You must still be able to read and understand old event tables, though, because many samples haven't been updated for ages.
An event table tells wxWidgets to map events to member functions. It should be defined in a .cpp file.
wxBEGIN_EVENT_TABLE()
is an example of a macro
In addition to the other answers, I'd like to say that if you're starting learning wxWidgets, you should know that event tables are a legacy way of handling events and that using Bind() is the preferred way of doing it in the new code.
In particular, Bind() is much less "magic", and doesn't use any macros.
Given a set of public headers, and various test code that makes use of these headers, I need to generate a list of used/unused API calls.
I am working with a platform that can not easily have traditional code coverage at runtime, but my requirements are a bit simpler hopefully.
I only need this to occur statically, and it seems as if this should be an easily accomplished thing (Most IDE's show all available function calls). I haven't found an appropriate tool for this though.
Can anyone recommend one? Or point me to the specific term for what I am looking for?
Thank you
What is the best way to restrict use of certain headers(features of the library itself) in certain Cpp files. And if it fails to follow the set rules, compilation should halt.
This is not about finding out superfluous includes. This is about restricting the developers to the applicaiton framework.
For example if there exists a osUtils class as osUtils.h and if as per this, this application's development framework mandates use of osUtils.h for filesystem operation like to make a folder. but there are always a chance that individual module finds it convenience to break this rule by including sys/stat and use a mkdir() method. But if the intention of providing a framework here lets say for cross-platform abstraction or special path handling logic, the objective is lost by doing it out of framework. Is there a way to restrict this? like restricting the usage of sys/stat.h in certain files (except for osUtils.h file in this case) can help solve the problem. but how to implement it so it will not compile if the rule is broken.
I don't know how to do this by breaking compilation - the idea of compilation failure because of a valid code don't appeal to me. I've got some other ideas:
Code review. If done right this should prevent such errors.
I am pretty sure that some static code analysis tool can help detect
those things (they can check things like 'include what you use', so
a rule 'don't include 'XYZ' should be there)
If you have this static analysis tool ready there is a problem with getting people to use it and fix errors shown by it. One option that you can use is git hook. If the new code don't pass the static analysis - reject the commit. If you cannot use hooks, or don't want to - make a separate CI job that will check for the violations of the static checking. Then you'll see who and when pushed some bad code.
I wonder whether there is a tool for VS that can show me a call graph (that is, a diagram listing all possible execution paths) for a given C++ function. It would help in navigating a big code base, in cases where a function is called in only a few places.
For oft-called functions like printf it could simply say:
too many options...
Again I guess it is not really easy to make such tool so I wonder if it exists, but you know it seems possible to do it so you never know... :)
EDIT: I know about find all references, but that gives just call sites of the function, not the call site of the function that called the function that called the function...
EDIT: VS is 2010, but if necessary VS2012 is an option.
You mentioned that you know about finding all the references. Have you looked into viewing the Call Hierarchy? It's probably not your "dream method" but it does allow you to look at a function in terms of "calls to" and "calls from" the given function. The window also allows you to add multiple functions to view in a tree format. So basically you would tree up or down through the possible outcomes.
Right click on the desired method ( could be anywhere in the hierarchy ) =>
Select "View Call Hierarchy"
Note that if you can add more than one reference point to the window. Delete when needed
You could also use Ctrl+K or Ctrl+T
Another fine example, IMHO, of a disappointment in the differences between C++ and C# with VS. I think Code Maps would be just what you're looking for. Assuming of course you were working with Ultimate - but nope, not with C++.
There's no such feature in C++/MSVC, as far as I know.
However, there's AQTime profiler for windows that has "static analysis" option that (IF I remember correctly) scans compiled executable, generates call graph and shows you unreacheable functions.
If I remember correctly, AQtime integrates into visual studio (professional edition, afaik).
Unfortunately, this is a commercial profiler that costs around $500, and this feature is not available in trial version. Last time I used static analysis was 3..4 years ago and I don't exactly remember details at the moment (and I don't have access to AQTime anymore). Anyway, it is a specialized tool, so I wouldn't recommend buying it unless you're optimizing code for speed 24/7.
Perhaps, by googling "static analysis", "code coverage" or researching other profilers you'll find somewhat similar tool that does the job for free.
Aside from that, doxygen can generate callgraphs for C++ code. In case of doxygen, you'll have to hunt for functions that are never called yourself.
Also, Visual Studio 2008 had a built-in caller graph feature (which, I think, uses intellisense). Basically, you right click any function and select "show callers" (or something like that), that'll open list of all functions (visual studio THINKS are calling your function) in a window. Because this feature was present in VS2008, it should be included in VS2010. However, it can't detect every caller for obvious reasons (virtual methods, callbacks, etc).
Maybe doxygen is the tool you are looking for. It provides the possibility to generate call graphs (showing all functions called by a specific function) and/or caller graphs(showing the functions that the function is directly or indirectly called by).
see: http://www.doxygen.nl/manual/diagrams.html
Take a look at Understand tool (http://www.scitools.com). It's great for drawing call graphs and control flow charts.Unfortunately, it's commercial.
You can resolve results after doing Symbol search. Just right click in your source and then select find all references that performs symbol search. Its explained in further details at http://blogs.msdn.com/b/vcblog/archive/2009/11/17/improvements-to-find-all-references-in-visual-studio-2010.aspx
You can try CppDepend which give you the call graph inside VS and provides many features in its dependency graph.
Source Navigator is a tool that I have used and have been quite happy with on C++ projects. Again, it is not within the Visual Studio IDE, but it has some great advantages if you don't mind pressing Alt-Tab :-)
works with both C and C++ sources
is quite fast in it's indexing and searching; it's a pleasure to use, IMHO
is a visual tool
is a free and Open Source tool
See http://sourcenav.berlios.de/screenshots/ for some screenshots
In particular, you are looking for the Cross-Reference Browser:
"It can find every call of a function, or tell you everything a
particular function calls. It creates tree diagrams that show
essential relationships within the project's symbol database, such as
the function call hierarchy tree. You can traverse up and down the
hierarchy tree, as well as expand or restrict the tree. You can select
items in the hierarchy and display their Refers-to and Referred-by
relationships; these relationships are based on the "point-of-view" of
the selected symbol."
Though this example screenshot from the tutorial, "Using the Cross-Reference Browser" shows Referred-by relationships (using red arrows) for a class and not a function, the latter use case would be very similar. You can also browse what functions / methods are getting called from a function, and that would be a Refers-to relationship, shown using blue arrows instead of red.
Do give it a try! As I mentioned before, I have been a happy user of this tool; it's not very well-known, but is a good piece of software (that also stands as an example for how useful Tcl/Tk can be in the right hands).
I think you should be able to use VS Plugin - CodeGraph on your solution and look for the specific function you are looking for and go on from there. It does static analysis on your solution and generates a nice graph of the call flows. Check "https://marketplace.visualstudio.com/items?itemName=YaobinOuyang.CodeAtlas". Hope this helps.
Are there good tools to automatically check C++ projects for coding conventions like e.g.:
all thrown objects have to be classes derived from std::exception (i.e. throw 42; or throw "runtime error"; would be flagged as errors, just like throw std::string("another runtime error"); or throwing any other type not derived from std::exception)
In the end I'm looking for something like Cppcheck but with a simpler way to add new checks than hacking the source code of the check tool... May be even something with a nice little GUI which allows you to set up the rules, write them to disk and use the rule set in an IDE like Eclipse or an continuous integration server like Jenkins.
I ran a number of static analysis tools on my current project and here are some of the key takeaways:
I used Visual Lint as a single entry point for running all these tools. VL is a plug-in for VS to run third-party static analysis tools and allows a single click route from the report to the source code. Apart from supporting a GUI for selecting between the different levels of errors reported it also provides automated background analysis (that tells you how many errors have been fixed as you go), manual analysis for a single file, color coded error displays and charting facility. The VL installer is pretty spiffy and extremely helpful when you're trying to add new static analysis tools (it even helps you download Python from ActiveState should you want to use Google cpplint and don't have Python pre-installed!). You can learn more about VL here: http://www.riverblade.co.uk/products/visual_lint/features.html
Of the numerous tools that can be run with VL, I chose three that work with native C++ code: cppcheck, Google cpplint and Inspirel Vera++. These tools have different capabilities.
Cppcheck: This is probably the most common one and we have all used it. So, I'll gloss over the details. Suffice to say that it catches errors such as using postfix increment for non-primitive types, warns about using size() when empty() should be used, scope reduction of variables, incorrect name qualification of members in class definition, incorrect initialization order of class members, missing initializations, unused variables, etc. For our codebase cppcheck reported about 6K errors. There were a few false positives (such as unused function) but these were suppresed. You can learn more about cppcheck here: http://cppcheck.sourceforge.net/manual.pdf
Google cpplint: This is a python based tool that checks your source for style violations. The style guide against which this validation is done can be found here: http://google-styleguide.googlecode.com/svn/trunk/cppguide.xml (which is basically Google's C++ style guide). Cpplint produced ~ 104K errors with our codebase of which most errors are related to whitespaces (missing or extra), tabs, brace position etc. A few that are probably worth fixing are: C-style casts, missing headers.
Inspirel Vera++: This is a programmable tool for verification, analysis and transformation of C++ source code. This is similar to cpplint in functionality. A list of the available rules can be found here: http://www.inspirel.com/vera/ce/doc/rules/index.html and a similar list of available transformations can be found here: http://www.inspirel.com/vera/ce/doc/transformations/index.html. Details on how to add your own rule can be found here: http://www.inspirel.com/vera/ce/doc/tclapi.html. For our project, Vera++ found about 90K issues (for the 20 odd rules).
In the upcoming state: Manuel Klimek, from Google, is integrating in the Clang mainline a tool that has been developed at Google for querying and transforming C++ code.
The tooling infrastructure has been layed out, it may fill up but it is already functional. The main idea is that it allows you to define actions and will run those actions on the selected files.
Google has created a simple set of C++ classes and methods to allow querying the AST in a friendly way: the AST Matcher framework, it is being developped and will allow very precise matching in the end.
It requires creating an executable at the moment, but the code is provided as libraries so it's not necessary to edit it, and one-off transformation tools can be dealt with in a single source file.
Example of the Matcher (found in this thread): the goal is to find calls to the constructor overload of std::string formed from the result of std::string::c_str() (with the default allocator), because it can be replaced by a simple copy instead.
ConstructorCall(
HasDeclaration(Method(HasName(StringConstructor))),
ArgumentCountIs(2),
// The first argument must have the form x.c_str() or p->c_str()
// where the method is string::c_str(). We can use the copy
// constructor of string instead (or the compiler might share
// the string object).
HasArgument(
0,
Id("call", Call(
Callee(Id("member", MemberExpression())),
Callee(Method(HasName(StringCStrMethod))),
On(Id("arg", Expression()))
))
),
// The second argument is the alloc object which must not be
// present explicitly.
HasArgument(1, DefaultArgument())
)
It is very promising compared to ad-hoc tool because it uses the Clang compiler AST library, so not only it is guaranteed that no matter how complicated the macros and template stuff that are used, as long as your code compiles it can be analyzed; but it also means that intricates queries that depend on the result of overload resolution can be expressed.
This code returns actual AST nodes from within the Clang library, so the programmer can locate the bits and nits precisely in the source file and edit to tweak it according to her needs.
There has been talk about using a textual matching specification, however it was deemed better to start with the C++ API as it would have added much complexity (and bike-shedding). I hope a Python API will emerge.
The key problem with "style checkers" is that style is like art: everybody has a different opinion about what is good style and what is not. The implication is that style checkers will always need to be customized to the local art tastes.
To do this right, one needs a full C++ parser with access to symbol definitions, scoping rules and ideally various kinds of flow analyses. AFAIK, CppCheck does not provide accurate parsing or symbol table definitions, so its error checking can't be both deep and correct. I think Coverity and Fortify offer something along these lines using the EDG front end; I don't know if their tools offer access to symbol tables or data flow analyses. Clang is coming along.
You also need a way to write the style checks. I think all the tools offer access to an AST and perhaps symbol tables, and you can hand code your own checks, at the cost of knowing the AST intimately, which is hard for a big language like C++. I think Coverity and Fortify have some DSL-like scheme for specifying some of the checks.
If you want to fix code that is style incorrect, you need something that can modify the code representation. Coverity and Fortify do not offer this AFAIK. I believe Clang does offer the ability to modify the AST and regenerate code; you still have to have pretty intimate knowledge of the AST structure to code the tree hacking logic and get it right.
Our DMS Software Reengineering Toolkit and its C++ front end provide most of these capabilities. Using its C++ front end, DMS can parse ANSI C++11, GCC4 (with C++11 extensions) and MSVS 2010 (with its C++11 extensions) [update May 2021: now full C++17 and most of C++20] build ASTs and symbol tables with full type information. One can also ask for the type of an arbitrary expression AST node. At present, DMS computes control flow but not data flow for C++.
An AST API lets you procedurally code arbitrary checks; or make changes to the AST to fix problems, and then DMS's prettyprinter can regenerate complete, compilable source text with comments and preserved literal format information (eg., radix of numbers, etc.). You have to know the AST structure to do this, just like other tools, but it is a lot easier to know, because it is isomorphic to the DMS C++ grammar rules. The C++ front end comes with the our C++ grammar. [DMS uses GLR parsers to make this possible].
In addition, one can write patterns and transformations using DMS's Rule Specification Language, using the surface syntax of C++ itself. One might code OPs "dont throw nonSTL exceptions" as
pattern nonSTLexception(i: IDENTIFIER):statement
= " throw \i; " if ~derived_from_STD_exception(i);
The stuff inside the (meta)quotes is C++ source code with some pattern-matching escapes, e.g, "\i" refers to the placeholder varible "i" which must be a C++ IDENTIFIER according the rule; the entire "throw \i;" clause must be a C++ "statement" (a nonterminal in the C++ grammar). The rule itself mainly expresses syntax to be matched, but can invoke semantic checks (such as "~is_derived_from_STD_exception") applied to matched subtrees (in this case, whatever "\i" matched).
In writing such patterns, you don't have to know the shape of the AST; the pattern knows it, and it is automatically matched. If you've ever coded AST walkers, you will appreciate how convenient this is.
A match knows the AST node and therefore the precision position (file/line/column) which makes it easy to generate reports with precise location information.
You need to add a custom routine to DMS, "inherits_from_STD_exception", to verify the identifier tree node passed to that routine is (as OP desired) a class derived from
std::exception. This requires finding "std::exception" in the symbol table,
and verifying that the symbol table entry for the identifier tree node is a class
declaration and transitively inherits from other class declarations (by following symbol table links) until the std::exception symbol table entry is found.
A DMS transformation rule is a pair of patterns stating in essence, "if you see this, then replace it by that".
We've built several custom style checkers with DMS for both COBOL and C++. Its still a fair amount of work, mostly because C++ is a pretty complex language and you have to think carefully about the precise meaning of your check.
Trickier checks and those tests that start to fall into deep static analysis require access to control and data flow information. DMS computes control flow for C++ now, and we're working on data flow analysis (we've already done this for Java, IBM Enterprise COBOL and a variety of C dialects). Analysis results are tied back to the AST nodes so that one can use patterns to look for elements of the style check, and then follow the data flows to tie the elements together if needed.
When all is said and done with DMS, (or indeed with any of the other tools that deal with C++ in any halfway accurate way), is that coding additional or complex style checks is unlikely to be "convenient". You should hope for "possible with good technical background."