Snavtofamix feature list

From FetchWiki

Jump to: navigation, search

This page discusses features provided by snavtofamix when processing SourceNavigator's database-dump (accompanied with the results from our parser extensions, e.g., namespace parsing, usage declaration parsing etc.) towards a valid CDIF file.


[edit] Facts extracted for C++

While most of the implementation of snavtofamix is similar between C++ and Java, the completeness with which facts on entities and relations are extracted is considerable less for C++. This is mainly due to the minimal extent to which SourceNavigator provides information about references.

[edit] Extracted entity facts

[edit] Namespaces

A single namespace that is extended at various locations is recorded as a single namespace, having multiple source locations.

[edit] Classes

All class, struct and union declarations included in SourceNavigator's database-dump are converted to CDIF. The names of anonymous unions and structs that are typedef-ed immediately is considered to be this typedef name.

[edit] Methods

Snavtofamix differentiates between declarations and definitions. Declarations specify the signature of a method, but do not specify a method body. Definitions specify the method body associated with a method signature.

Method declarations and definitions will be generated only in case the class owning the method can be uniquely identified. This identification is based on (i) the class-name; (ii) and the source file in which the method is declared/defined. The implicit assumption here is that method declarations are specified in the same source file as the declaration of the class owning the method. Identification based on these two items will fail in the following situations:

  • Two declarations are provided for a class. This may occur when using macro's preprocessing directives, e.g. #ifdef. While this situation can currently not be handled correctly, the exploitation of the line numbers of both declarations and the current declaration enable to identify the right class declaration, since it should always hold that lineNr(classDeclaration) < lineNr(methodDeclaration).

[edit] Attributes

Similar to methods, attributes will be generated only in case the class owning the attribute can be uniquely identified.

[edit] Functions

Similar to methods. Function prototypes are not recorded.

[edit] Formal Parameters

Currently, there is hardly any support for extracting facts on formal parameters. Merely formal parameters of method definitions are processed, and even then, the identification of the parent of a formal parameter (the method in question) is bound to fail due to:

  • template parameters prefixed to the method name by SourceNavigator
  • dependency on the SourceNavigator database-dump as the main source of information, rather than snavtofamix's internal caches.

[edit] Extracted relation facts

[edit] Include directives

Snavtofamix extracts include dependencies between source files, yet translates the paths of the included source files. In fact, include directives mostly refer to the included file relative to the location of the including source file (e.g., using directory navigation similar to ../someDir/someFile.h). The paths of included files are translated as to represent their location relative to the base directory of the software system.

To clarify the concept of a base directory of the software system under study, one must realize that information on these include directives is passed on by SourceNavigator. SourceNavigator itself is given a set of source folders from which to parse source code. As an illustration, consider the following input to SourceNavigator:

  • Source folder /home/fetchUser/core/src, containing files:
    • /home/fetchUser/core/src/Foo/Foo.h
    • /home/fetchUser/core/src/Foo/Foo.cpp
    • /home/fetchUser/core/src/Bar/Bar.h
  • Source folder /home/fetchUser/auxilary/src, containing files:
    • /home/fetchUser/auxilary/src/Baz.h

SourceNavigator will itself translate the path of each file in a given source folder relative to this source folder. Additionally, suppose that the include directives in these files are as follows:

  • ./Foo/Foo.cpp
    • #include "./Foo.h"
  • ./Bar/Bar.h
    • #include "../Foo/Foo.h"
    • #include "/home/fetchUser/core/src/Bar/Bar.h"

In that case, the following file paths and include relations will be published by SourceNavigator:

  • ./Foo/Foo.h
  • ./Foo/Foo.cpp, will be stated to include:
    • ./Foo.h
  • ./Bar/Bar.h, will be stated to include:
    • ../Foo/Foo.h
    • /home/fetchUser/core/src/Bar/Bar.h TODO: check this
  • ./Bar/Bar.h
  • ./src/Baz.h

For this input, snavtofamix will publish the follwing facts on include directives:

  • Foo/Foo.cpp includes Foo/Foo.h
  • Bar/Bar.h includes Foo/Foo.h
  • Bar/Bar.h includes /home/fetchUser/core/src/Bar/Bar.h

[edit] Typedef relations

All type definitions will be generated, unless a type definition was used in the definition of an anonymous union or struct (see classes).

[edit] Inheritance relations

Similar to methods and attributes, an inheritance relation from the subclass with a superclass will be generated only in case the superclasscan be uniquely identified. Currently, this precondition is inconsistenly not required for the subclass.

[edit] Data accesses

A data accesses is a reference and/or update to either a global variable or an attribute from either a function or a method definition.

[edit] Invocations

An invocation is a call to a method or a function declaration from a method or function definition.

Personal tools