For a long time Understand has been primarily a solo experience. We are working to change that so you can easily share what you learn in Understand with the rest of your team.
We are simplifying project creation, and once the project is created everyone on your team will be able to use it automatically. We’re accomplishing that by completely changing the structure of the Understand project, replacing the udb file with much smaller, non-binary files that can be easily added to version control or accessed from a shared network location.
Once everyone is using the same shared project, your team can use Annotations to share extra information about the code. Annotations are being re-written to enhance the look and make them much more intuitive to use, similar to leaving a comment in Google Docs or Microsoft Word. Even better, we will be adding the capability to add attachments to annotations. Imagine being able to save the whiteboard image from a planning meeting, document the discussion from the last code-review, and attach the design documents right next to the code, without cluttering it.
Another way you’ll be able to share information is by tagging the code in your project and using those tags to navigate easier, analyze dependencies, generate reports and metrics. For example you can easily tag a function that manipulates passwords with a “security-risk” label, mark a header file with an “API” tag or flag a directory as “Open-Source”. This let’s you quickly answer big questions like “Does the code that launches the satellite depend on any external code?”, or the smaller questions like “Where are our API files?”.
Software development never goes completely as planned, but these features should begin rolling out soon. We look forward to your feedback on them.
When things change from one version of a project to another, sometimes we just want to go back and visually see exactly what those changes were and what they might have affected. Now Understand gives you the power to see how one entity changes over time with the new Compare feature.
Both projects need to be setup with identical paths in the Understand database in order to compare them. The easiest way to do that is to set the projects to Relative mode and put the udb project file in the root of the source tree. Similar to this:
Open the more recent project in Understand. Then go to Tools->Compare->Set Comparison Project and select the project that contains the older version of source code.
Notice that there is a button here to ‘Close Comparison Project’. This button is used to close just this comparison project as it will stay open until it is closed in this menu, or until the first opened project is closed.
After the Comparison Project is set, select ‘OK’ and then it’s time to see the differences. In this project that I’m looking at, I know that I have changed some of the include files in my attributes.cpp file so I will right click on the file name and select ‘Graphical Views->Butterfly Compare’.
The Legend quickly shows the meanings of the different colors and in this sample we can quickly see that there are 2 new references to entities that exist in both versions of the project. We can also see that there are 3 old references and the ‘attributes.cpp’ file is colored in blue because it existed in both versions of the project and it changed from one version to the next.
Note that if the Legend is in the way of what you want to see simply click and drag it to where you want, or right click on the white space of the graph and there is an option to turn the Legend completely off.
Now lets take a look at the function ‘appendTexture’ and see what kind of changes it has from one version to the next.
I can see that there are several changed entities in blue, one old entity that no longer exists in the new version called ‘adjustSize’ which makes all of its references old as well, showing in red. And in green, there are new references and a new entity named ‘changeSize’. I can look into this code further if needed, but a quick look at this graph lets me visualize the changes that have occurred.
Sharing your Understand project definitions with your team members saves them from needing to setup all of the include paths, macros, file paths etc. An easy way to do that is by adding the project files to your version control system. However in the past the file size and frequency of change made it a little tricky. Now we’ve added new type of Understand project file that makes this a lot easier – the *.udx settings file. The udx settings file saves the project settings but none of the parse information, so it stays slim, trim and easy to share.
Everything about a project is stored in the udb project file, the project settings along with all of the details from the analysis. The new udx configuration files live side by side with the udb file and share the same name. As you can see there is a substantial size difference.
These udx files can be read from and written to manually or automatically, whatever works best for your team.
The File menu has a new Export/Import option that lets you manually write/read the project settings to/from the udx file for the currently opened project. There is also an option under the New menu for creating a new project file from a udx file. Note that the udb file is always created next to the udx file specified. The two files always need to be paired together.
The options to automatically use the udx files are located in Tools->Options->General. If “Read” is checked then whenever the udx file is modified Understand will prompt you to reanalyze your project with the new configuration settings. If “Write” is checked then whenever the project configuration is changed then the .udx file will be updated to reflect those changes.
As a possible use case let’s say you are the guru who sets up projects for everyone else and you want to setup a new project and share it with your team using git.
When sharing a project file, always make sure you have the correct portability options set so the files align on each users environment. I prefer to setup my project in the root directory of my source code and use relative paths.
Next go into Tools->Options->General and enable the “Write .udx export files automatically”option. This will create a new .udx file in the directory with the .udb file. Alternatively you can do it manually using the File->Export command
As a one time change add these lines to your .gitignore file to ignore the bigger udb files
# Understand project files
Add the .udx file to git, then commit and push. Now whenever the other engineers pull the latest source they will get your udx settings file. Whenever you need to change the project configuration just commit the changes to this file as you would any other source file.
To create a new project with it the other engineers need to run git pull and then double click on the udx file or open Understand and select File->New->New UDX Project. That project will then stay up-to-date whenever they update git.
Function pointer support is available in Understand 5.0 when using the C/C++ Strict Parser. With this added support, Understand is providing the potential calls so that you can see the bigger picture.
This screenshot shows the Information Browser in Understand 4.0 on the left, and Understand 5.0 on the right, with the same project and the same function being viewed in each version. Understand 4.0 shows only a few calls, while Understand 5.0 is providing all of the possibilities with the added function pointer support.
This also translates to a better, more informative graphical view with the added function pointers. You can see in this next graph, all of the red dots on the nodes which signify the ability to expand the calls.
Notice that the same ‘dthash’ function, prior to function pointer support, only had 2 nodes that were expandable.
Looking at a few of the entities in this call graph, we expand the ‘cmpf’, ‘makef’, and ‘dthtab’ calls and see the potential calls available, noting that the function pointer calls are signified with the red dotted lines.
Here is the same graph available in Understand 4.0 prior to the function pointer support.
The interactive Cluster Call Graphs show the function call graph, organized by file. There are several variants of this graph: Call, Call-by, Butterfly and Internal Call. They can also be accessed from the function, class, file or architecture level. These graphs can all be accessed from the Graphical View right click menu for the entity.
Good news for teams using Codecheck, build 868 lets Codecheck ignore violation via comments in the code. This will allow teams to specify areas in the code where exceptions are permitted and specify the rationale. For example:
goto RAINBOW; //UndCC_Line() Use of goto statement approved by Gerry T. on Nov 7,2014
This will create a new rule in the Codecheck “Ignores List” to ignore all Codecheck violations on this line and add a note about the approval process. Those ignored violations can still be viewed in Understand, but are hidden by default.
Ignore rules can be created for: a specific line, a range of lines, a file, a specific entity, and a specific entity in a range of lines. They can also be made to ignore all violations or just violations of the specified type(s).
In an effort to make our APIs more consistent a few of the API files have been moved around with build 858. Your code may need to be updated to reflect these changes.
udb.h, libudb_api.so, udb_api.dll and udb_api.lib have all been moved to bin\<OS>\C
The bin\pc-win64\python folder has been capitalized to bin\<OS>\Python
Custom Perl API
The Understand Perl library files have been moved up a level from bin\<OS>\Perl\STI\Maintain to bin\<OS>\Perl\STI
This will only affect users that are using the perl API with their own custom install of Perl 5.10.0, not those running scripts inside of Understand or using the uperl executable.
We’re excited to join our European partner Emenda at a morning seminar in Reading on Tuesday 18th October. The subject is: Software quality improvement, development process optimisation and cost reduction