Windows OS provides a preemptive kernel-mode scheduler,it’s a round-robin, priority-based mechanism that gives every task exclusive access to a computing resource for a given time period, and then switches to another task.Although this mechanism provides fairness (every thread makes forward progress), it comes at some cost of efficiency.For example, many computation-intensive algorithms do not require fairness. Instead, it is important that related tasks finish in the least overall time. Cooperative scheduling enables an application to more efficiently schedule work.

Cooperative scheduling is a mechanism that gives every task exclusive access to a computing resource until the task finishes or until the task yields its access to the resource.

The user-mode cooperative scheduler enables application code to make its own scheduling decisions. Because cooperative scheduling enables many scheduling decisions to be made by the application, it reduces much of the overhead that is associated with kernel-mode synchronization.

The Concurrency Runtime uses cooperative scheduling together with the preemptive scheduler of the operating system to achieve maximum usage of processing resources.

In this article we will discuss the Task Scheduler design and examine how it works internally. To do so, CppDepend is ued to analyse the concurrency runtime code source.

Scheduler Design

The concurrency runtime provides the interface Scheduler to implement a specific scheduler adapted to application needs.

Let’s discover classes implementing this inerface:

The concurrency runtime provides two implementations of the scheduler, ThreadScheduler and UMSThreadScheduler, and as shown in the dependency graph the SchedulerBase contains all common behavior of these two classes.

Is the Scheduler flexible? a good indicator of flexiblity is to search for all abstract classes used by the scheduler.

As shown in the dependency graph the Scheduler use many abstract classes,it enforces the low coupling, and make the scheduler more flexible, so adapting it to other needs will be easy.

To explain the role of each absract class used by the scheduler we will discuss its responsabilities.

There are three major responsabilities assigned to the Task Scheduler:

1) Getting Resources(Processors,Cores,Memory):

When the scheduler is created it ask for resources from runtime resource manager as explained in this article.

The scheduler communicate with resource manager using IResourceManager, ISchedulerProxy and IScheduler interfaces.

Resources given by resource manager use scheduler policy to allocate resources to the scheduler.
The policy as shown in this dependency graph is assigned when the scheduler is created.

The concurrency runtime create a default scheduler if no scheduler exists by invocking GetDefaultScheduler method, and a default policy is used.
The Task Scheduler enables applications to use one or more scheduler instances to schedule work, and an application can invoke Scheduler::Create to add another scheduler that uses a specific policy.

The Concurrency::PolicyElementKey enumeration defines the policy keys that are associated with the Task Scheduler.

Here’s an article explaining the utility of each policy key, and the default value of each key.

The following collaborations between the scheduler and resource manager shows the role of each interface concerned by the allocation.

- Ask for resource allocation:

- Getting resources from resource manager:

2)Manage Task Queues:

When Schedeluer is created, tasks could be assigned to it to be executed, the Scheduler store tasks into queues.to enforce the cohesion of classes, the queues are not managed directly by the ThreadScheduler class but by ScheduleGroupBase class.

A schedule group affinitizes, or groups, related tasks together. Every scheduler has one or more schedule groups. Use schedule groups when you require a high degree of locality among tasks, for example, when a group of related tasks benefit from executing on the same processor node.

As shown in the following graph, the runtime provides two kind of ScheduleGroup: FairScheduleGroup and CacheLocalScheduleGroup, choosing between those two groups as it will be explained later impact the algorithm of choosing the next task to execute by the scheduler.

Every Scheduler has a default schedule group for every scheduling node.The runtime creates one scheduling node for every processor package or Non-Uniform Memory Architecture (NUMA) node. If you do not explicitly associate a task with a schedule group, the scheduler chooses which group to add the task to.

As shown in the following dependency graph ,The schedulingRing is responsable of managing Scheduler Groups, it contains a list of groups and create them.

The Schedule group contains three kind of queues:

1) FIFO Queue

This queue contains lightweight tasks,a lightweight task resembles the function that you provide to the Windows API CreateThread function. Therefore, lightweight tasks are useful when you adapt existing code to use the scheduling functionality of the Concurrency Runtime.

A lighweight task is represented by RealizedChore class, and the FIFO queue of the schedule group is represented by the field m_realizedChores.

Let’s search all methods using directly this queue:

So we can add a lightweight task to the group by invoking ScheduleGroupBase::ScheduleTask or Scheduler::ScheduleTask.

Here’s an interesting article talking about lighweight tasks.

2)Work Stealing queue:

There’s only one FIFO queue associated to the schedule group, but the schedule group reference a list of work sealing queues, for each worker thread there’s a local queue associated to it.

A thread that is attached to a scheduler is known as an execution context, or just context, so actually this local queue is associated to Context class.

The Context class provides a programming abstraction for an execution context and offer the ability to cooperatively block, unblock, and yield the current context.

And to be sure that only Context create this kind of queue, let’s search of method accessing directly to m_workQueues field.

So the context is responsable of creating this queue, and for each context there’s a local work stealing queue associated to it.

To illustrate the behavior of the work-stealing algorithm ,let’s imagine that we have two worker thread allocated to the scheduler.

As explained before for each worker thread there’s a local queue associated with it.

Imagine that we have three tasks in the queue of the Worker Thread 1, tasks 3 and 4 are waiting to be executed while the 5 is running.

The Dispatch method finds that there is nothing in the queue, so the task 3 is moved, or “stolen” from its original queue, to be distributed the worker thread available.

How we can create a task managed by work stealing queue ?

To answer this question let’s search for methods indirectly invocking the CreateWorkQueue method.

As shown in this dependency graph, this kind of task could be created by using task_group class.

Using task_group to add new task is more better than using Sheduler::ScheduleTask to create lighweight task, indeed the work stealing algorithm optimize better the using of virtual processors allocated to the scheduler.

However ScheduleTask could be better to migrate easilly from the existing code using CreateThread API.

3)Unblocqued Context queue:

The Context class lets you block or yield the current execution context. Blocking or yielding is useful when the current context cannot continue because a resource is not available.
The Context::Block method blocks the current context. A context that is blocked yields its processing resources so that the runtime can perform other tasks. The Context::Unblock method unblocks a blocked context.

When a context is unblocked and it’s available to be executed , it’s added to runnable context queue, this queue is represented by the field m_runnableContexts.

Here’s a dependency graph showing some cases where the context is added to runnable queue:

So the context is added to the queue when it’s unblocked or a virtual processor is retired from the scheduler.

3)Dispatching Tasks:

The scheduler try to search for work to execute, a work could be:

- Unblocked context.
- Lightweight task.
- Task in work stealing queues.

And as explained before all these works are stored in queues managed by Schedule groups, and each group is managed by a scheduling ring.

When a virtual processor is allocated to the scheduler a ThreadProxy class is created and associated to this processor. and after the creation the Dispatch method of the ThreadProxy is invoked.
As shown in the following dependency graph and as explained before the concurrency runtime use abstract classes to enforces low coupling, and the real dispatch invoked depends of the implementation choosed by the runtime, this choice is given by the scheduler policy.

The concrete implementation of Dispatch invoke Dispatch Method of the execution context.

Here’s a dependec graph showing methods invocked by concrete implementation of Context::Dispatch method:

So the algorithm of searching the next work to execute is implemented by WorkSearchContext class.

Let’s discover all classes used directly by WorkSearchContext to achieve its responsability:

The responsability of WorkSearchContext is to give us a WorkItem to execute, it could be InternalContextBase, RealizedChore or _UnrealizedChore.

To understand better the collaboration between these classes , let’s search for methods used directly by WorkSearchContext:

So the WorkSearchContext iterate on SchedulingRing and SheduleGroup classes by using SchedulerBase methods.

And for each ScheduleBase we search for RunnableContext, realizedChore or UnrealizedChore.

The WorkSearchContext class is created by the VirtualProcessor class, and as shown in the following dependency graph, the algorithm used is specified when the VirtualProcessor is initialized, and for that it ask the Scheduler for the SchedulingProtocol which describe the scheduling algorithm that will be utilized for the scheduler.

The WorkSearchContext will be notified by the algorithm to use by passing it a value from Algorithm enum.

So two algorithmes are implemented by this class to find a work:

- Cache Local algorithm:

This algorithm will look for runnables context within the current schedule group,then realized chores and unrealized chores, if there’s no more work in the curent schedule group it looks for the next group in the same shedule ring, and when it finishes all works in the current schedule ring it looks in the next schedule ring.

So the scheduler prefers to continue to work on tasks within the current schedule group before moving to another schedule group.

This algorithm is implemented by WorkSearchContext::SearchCacheLocal method, and as show by this dependency graph, this method search invoke other methods to search for runnable contexts, RealizedChore or _UnrealizedChore.

Another specificity of this algorithm is that the unblocked contexts are cached per virtual-processor and are typically scheduled in a last-in first-out (LIFO) fashion by the virtual processor which unblocked them.

And to verify this behavior, here’s a dependency graph of methods invocked when searching for runnable context:

This algorithm is the default algorithm choosen by the scheduler if no one is specified.

- Fair algorithm:

In this case the scheduler prefers to round-robin through schedule groups after executing each task. Unblocked contexts are typically scheduled in a first-in-first-out (FIFO) fashion. Virtual processors do not cache unblocked contexts.

This algorithm is implemented by WorkSearchContext::SearchFair method, and as show by this dependency graph, this method search invoke other methods to search for runnable contexts, RealizedChore or _UnrealizedChore.

After this analysis we can say that The concurrent runtime task scheduler is well designed , it’s characterized by a high cohesion and very low copling, it’s very flexible and provides by default an optimized algorithm to exploit better hardware resources.

The Concurrency Runtime raises the level of abstraction so that you do not have to manage the infrastructure details that are related to concurrency. The Concurrency Runtime also enables you to specify scheduling policies that meet the quality of service demands of your applications.

Here’s the architecture of Concurrent Runtime Framework:

And to have more information’s about this framework, here’s a good introduction about it.

In this article we will discuss the Resource Manager layer, and try to discover how it works internally.For that CppDepend is used to analyse CRT Concurrency Runtime code source.

Before reading this article it’s better to take a look at these interesting articles about ResourceManager:

• Resource Management in Concurrency Runtime – Part 1
• Resource Management in Concurrency Runtime – Part 2
• Resource Management in Concurrency Runtime – Part 3

ResourceManager Design

Which classes are used by ResourceManager to achieve its responsibility?

SELECT TYPES WHERE IsDirectlyUsedBy “Concurrency.details.ResourceManager“

The first remark about this design is that it enforces the:

- High Cohesion: Many classes and structs are used by resource manager, each one has a specific responsability, it makes the design very clear.The single responsibility principle states that a class should have more than one reason to change. Such a class is said to be cohesive. A high LCOM value generally pinpoints a poorly cohesive class. There are several LCOM metrics. The LCOM takes its values in the range [0-1]. The LCOMHS (HS stands for Henderson-Sellers) takes its values in the range [0-2]. Note that the LCOMHS metric is often considered as more efficient to detect non-cohesive types.

LCOMHS value higher than 1 should be considered alarming.

WARN IF Count > 0 IN SELECT TYPES WHERE LCOMHS > 1 AND NbFields > 10
AND NbMethods >10 AND !IsGlobal ORDER BY LCOMHS DESC

So among classes used by ResourceManager, only UMS is considered as class with a poor cohesion.

- Low Coupling:Many interfaces and proxies are used to isolate ResourceManager from other components.
The Scheduler communicate with ResourceManager but there’s no direct link between Two components, so how the scheduler communicate with ResourceManager?

To answer to this question let’s discover classes using ResourceManager:

SELECT TYPES WHERE IsDirectlyUsing “Concurrency.details.ResourceManager“

Only these classes use the ResourceManager, and the Scheduler doesnt know the ResourceManager directly , so how it interact with it? let’s add to dependency graph the scheduler and interfaces used by it.

As shown in the dependency graph the Scheduler communicate with ResourceManager using interfaces IResourceManager,ISchedulere and ISchedulerProxy.

Where the ResourceManager is created?

SELECT METHODS WHERE DepthOfCreateA “Concurrency.details.ResourceManager” == 1

Only ResourceManager create an instance, and it’s a singleton so only one ResourceManager exist for the whole process.

Workflow of resource allocation:

Step 1: Get resources information’s from system

The Resource manager need all physical information’s concerning processors and cores to use them when allocating resources for schedulers.Let’s discover all data manipulated by this component.

SELECT FIELDS WHERE IsDirectlyUsedBy “Concurrency.details.ResourceManager“

These structs represent all data needed by ResourceManager, the basic ones are ProcessorCore and ProcessorNode representing information’s about physical resources.

Other structs contains some scheduler data needed for the allocation algorithm.

The good news is that ResourceManager didnt directly access to fields of other logical classes used by it.

Let’s search where Resourcemanager get basic information’s about physical resources, for that we can search for methods using GetLogicalProcessorInformation.

SELECT METHODS WHERE IsDirectlyUsing “WindowsAPIGlobalMembers.GetLogicalProcessorInformation(PSYSTEM_LOGICAL_PROCESSOR_INFORMATION,PDWORD)“

Only ResourceManager::InitializeSystemInformation use this method, to get information’s from system, but it’s this method responsible of populating ProcessorCore and ProcessorNode?

For that we can search for methods assigning a fields of ProcessorCore:
SELECT METHODS WHERE IsDirectlyWritingField “Concurrency.details.ProcessorCore.m_processorNumber“

So ResourceManager invoke DetermineTopology method to populate data into structs.

And here’s a dependency graph showing methods concerned by getting nodes and cores information’s.

Step2: Scheduler ask for resource allocation

After ResourceManager get all data needed for allocation algorithm, a scheduler can ask it to allocate ressources.

When the Scheduler is created it ask for a ResourceManager and invoke CreateResourceManager to get the singleton, after that it invokes IResourceManager::RegisterScheduler to register it self with the resource manager, and get a pointer to ISchedulerProxy, and with this interface the Scheduler will interact with the resource manager.

After that the Scheduler is ready to ask for resources allocation by invocking RequestInitialVirtualProcessors.

And as explained before the Scheduler communicate with resource manager using IScheduleProxy interface to enforces low coupling, and the concrete implemenatation of this interface invoke ResourceManager::RequestInitialVirtualprocessors.

Step3: Resources allocation

The resource Manager have to give resources to schedulers when schedulers are created.It will do the allocation depending on the policies and taking into account the other schedulers in the process. Eventually the resources will be provided to the scheduler in need.

The entry point of allocating request is RequestInitialVirtualProcessors, and here’s a dependency graph showing methods used to acheive allocation.

PerformAllocation method implements the allocation logic, it ask for Scheduler policies from SchedulerProxy, and invoke AllocateCores method to perform allocation.

Here’s some characteristics of PerformAllocation and AllocateCores:

Thoses methods are very well documented and the cyclomatic complexity is not high, and it’s a good indicator that the algorithm of initial allocation is not very complicated.

Step4: giving resources to Scheduler

After ResourceManager allocate Resources , the scheduler is notified with resources allocated, for that the resource manager invoke GrantAllocation method.

What resources the ResourceManager have to give to Scheduler?

As described in msdn articles mentioned below related to resource manager, the resource is a virtual processor associated to a specific thread and runing in a specific core.

But as shown in the dependency graph the resource manager dont give VirtualProcessors to SchedulerProxy but an array of SchedulerNodes, the SchedulerProxy create VirtualProcessorRoot classes, VirtualProcessorRoot represent an abstraction for a hardware thread on which a thread proxy can execute.

Who is creating VirtualProcessor?

Before answering to this question let’s search for classes that represent a Virtual Processor, so let’s search for classes inheriting from this one.

So VirtualProcessor could concern a simple thread or an UMS Thread.

User-mode scheduling (UMS) is a light-weight mechanism introduced in Windows7 and Windows server 2008 R2, that applications can use to schedule their own threads. For more information, see User-Mode Scheduling.

Let’s search for methods creating ThreadVirtualProcessor.

So the Scheduler is the responsible of creating VirtualProcessors, and all information’s needed to create it are given by manager.

Step5:Dynamic managing resources

After the initial allocation of resources, the second main responsability of resource manager is to Constantly monitoring utilization of resources by schedulers, and dynamically migrating resources between schedulers.

And as shown in the following graph the resource manager create DynamicRM Thread,This worker thread wakes up at fixed intervals and load balances resources among schedulers.

And here’s the dependency graph of DynamicResourceManager:

Is ResourceManager customizable?

ResourceManager is well designed and is decoupled from other Concurrency Runtime framework by using interfaces, but it’s possible to customize the allocation behavior of resource manager.

For that let’s search for ResourceManager virtual methods:

SELECT METHODS FROM TYPES “Concurrency.details.ResourceManager” WHERE IsVirtual

Only these methods are virtual and they implements the IResourceManager methods,so it’s not possible to overload allocation resource manager logic and customize it.

So what’s new in MFC 10? to answer to this question I tried to compare the two versions MFC 9 and MFC 10 using CppDepend.

Removed classes:

Let’s begin with breaking changes and search for removed classes:

SELECT TYPES WHERE WasRemoved

It was very strange that this class is removed , and to be sure I searched in the code source and I found it inside #ifdef ENABLE_RIBBON_LAUNCH_BUTTON statement.

The only resource I found in the web talking about this change is here , and I dont know if
adding #define ENABLE_RIBBON_LAUNCH_BUTTON is suficient to compile without problem.

Added Classes:

SELECT TYPES WHERE WasAdded AND isClass

What’s the new features added by these classes?

CMFCRibbonCollector,CMFCRibbonConstructor,CMFCRibbonInfo:
When I searched in MSDN the utility of these classes , I didnt found any useful informations, so I searched for methods using CMFCRibbonInfo.

SELECT METHODS WHERE IsDirectlyUsing “CMFCRibbonInfo“

The RibbonBar class use CMFCRibbonInfo to save it to xml or load it.

CJumpList,CAppDestinations:
Jump list is a new useful Window7 feature, it adds a new way of interaction between user and application.
here’s a good article to add JumpList feature with MFC.

CMFCControlContainer:

This class provides a CWnd support for MFC Control containment of Feature Pack controls.

And to know which controls can be contained inside this container, let’s search for classes used by CMFCControlContainer::CreateDlgControl.

Here’s the result:

So only these MFC feature pack controls are concerned by this container.

CDocument::CDocumentAdapter:

This class implements ATL::IDocument interface required for “Search and Organize” feature.
My first impression when I discovered this implemention was ” WOW, MFC use now interfaces to enforce low coupling”.

Let’s see the impact of using this interface, for that let’s search for classes using CDocumentAdapter :

SELECT TYPES WHERE IsDirectlyUsing “CDocument+CDocumentAdapter“

Only CDocument use directly this class.

However IDocument is used by other classes like the new class CMFCPreviewCtrlImpl, so this class can work with CDocumentAdapter and also others classes implementing this interface.

And as explained in the comment of CDocumentAdapter code source:

“Search and Organize handlers are implemented in ATL DLLs, which can be MFC or not-MFC based.Internally handlers refer to IDocument interface, whose implementation in the common case should be supplied by a developer. CDocumentAdapter provides this implementation for MFC and basically calls the appropriate methods of the parent CDocument.”

CDataRecoveryHandler:
This class autosaves documents and restores them if an application unexpectedly exits, it’s used by Restart Manager feature, here’s an interesting article talking about it.

Let’s search for classes used by CDataRecoveryHandler:

SELECT TYPES WHERE IsDirectlyUsedBy “CDataRecoveryHandler“

CDataRecoveryHandler is highly coupled with other MFC classes like CDocument, CWinApp, CWnd.

Which MFC classes use the recovery feature?

SELECT TYPES WHERE IsDirectlyUsing “CDataRecoveryHandler“

So all these classes benefit of this new feature especially CDocument.

CTaskDialog:
A pop-up dialog box that functions like a message box but can display additional information to the user.
here’s an interesting article talking about this feature.

CMFCVisualManagerVS2008,CMFCVisualManagerWindows7:
Gives an application the apparence of a VS2008 or Windows 7 application.

CGestureConfig:
Used for touch feature.

CFolderPickerDialog:
CFolderPickerDialog class implements CFileDialog in the folder picker mode.

CXMLParser,CXMLParserCollection,CXMLParserRoot:
when I dsicovered these classes, I thought that is concerning xml parsing but when I searched for methods using them, I discovered that only CMFCRibbonInfo use them to save or load its description to xml files.

SELECT METHODS WHERE IsDirectlyUsing “CXMLParserRoot“

CMFCZoomKernel,CMFCScanliner, CMFCScanlinerBitmap :
Not yet documented in MSDN, let’s discover which classes use them.

SELECT TYPES WHERE IsDirectlyUsing “CMFCZoomKernel“

And we have the same result for the two other classes.

Methods Removed:

SELECT METHODS WHERE WasRemoved

Almost all these methodes are not removed but only the signature is changed , and some optional parameters are added, however some methods are removed like CCommandManager::ResetAllImages or CPanelDialog::ClipPaint, and one method was renamed from CMFCRibbonBar::GetTabTrancateRatio to CMFCRibbonBar::GetTabTruncateRatio.

Methods Added:

Let’s search for all methods added to MFC10

SELECT METHODS WHERE WasAdded

Which features are added by these new methods?

For that we will focus only in the most used classes.

CWnd:

Here’s the methods added for CWnd, and almost all methods added concern touch feature and touch gestures.

CFile,CStdioFile,CFileFind:
Many methods of these classes add CAtlTransactionmanager as optional parameter.

Transactional File System is a new technology first introduced in Windows Vista. It enables you to roll back operations made on the file system and registry.

here’s a good article about this feature.

CRecentFileList:


New possibilities to add item to recent file list are now available.

CDocument:
Here’s the methods added by CDocument:

Two new features concern methods added :

-Supporting Windows Search with MFC
-Rich Preview

Let’s discover the changes concerning dependency of CDocument to other MFC classes,and which additional dependencies are added in MFC10, for that Dependency Matrix can be useful, and the sign “+” in the cell representing the dependency indicate that this dependency is new.


So many dependencies are added, especially with new classes added to MFC10 like CDataRecoveryHandler,and also some other inner classes added to CDocument.

CFileDialog:
Here’s the methods added by CFileDialog:

A good news is we can now customize CFileDialog by adding what we want in the dialog.

CMDIChildWndEx:
Here’s the methods added by CMDIChildWndEx:

Windows7 add a new interesting features like:taskbar Tabs,Taskbar thumbnails and thumbnail previews, and almost all methods added to CMDIChildWndEx concern these features.

CFrameWnd:

Windows 7 add also some useful features like OverlayIcon and progressbar in the taskbar, and the methods added to CFrameWnd concern these features.

CWinApp:

Almost all methods added to CWinApp concern the ApplicationRecovery support.

Other useful methods are added like CMFCControlRenderer::SmoothResize and CDrawingmanager::DrawRotated.

Methods where visibility was changed:

SELECT METHODS WHERE VisibilityWasChanged

Almost the visibility of all CMFCRibbonTab methods is changed from private to public.

But when I checked the code source the only modification in the class declaration is the adding of DECLARE_DYNAMIC(CMFCRibbonTab) , this macro include “public:” , so I wonder if this visibility changes is only a side effect of adding this macro.

Methods Not Used Anymore:

Some methods become obsolete when upgrading framework version, did MFC10 not use anymore some methods?

To answer to this question let’s execute the query :

SELECT METHODS WHERE IsNotUsedAnymore

here’s the result:

These methods were declared before in multimon.h , the origin of this file goes back to Windows 98 to let compatibility with Windows 95 in the case of multi monitor, here’s an interesting article talking about it.
In MFC10 this file is no longer included in mfc files. and MFC10 use directly GetSystemMetrics instead of xGetSystemMetrics.

Let’s take a look into Doc/View architecture proposed by MFC and discuss how MVC pattern could be implemented.

Did CDocument/CView implements MVC pattern?

Doc/View architecture as described by many articles is implementing MVC pattern, but where’s the Model, the controller and the view?

Here’s a description from msdn article:

“The Document-View variant recognizes all three roles of Model-View-Controller but merges the controller into the view. The document corresponds to the model role in MVC. This variant is present in many existing GUI platforms. An excellent example of Document-View is the Microsoft Foundation Class Library (MFC) in the Microsoft Visual C++ environment. The tradeoff of using this variant is that the view and the controller are more tightly coupled.”

So the CDocument is the model and CView merge the view and controller.

But actually the CDocument is not representing only the model , and to proof it let’s discover some CDocument design and methods:

CDocument derives from CCmdTarget to receive events and commands and contains the following methods : AddView, GetFirstViewPosition,GetNextView,UpdateAllViews.

So this class treats events,refresh and manage views, so it have some controller responsability.

Why CDocument is not the good candidate to be the model?

As described below the CDocument contains controller logic, and considering it also as model impact a lot the cohesion of classes, each classe must have a specific responsibility; it makes the design more flexible.

The model must be independent of any framework used, if it can be a POCO classes it will be wonderful, the question is why coupling the model with a specific framework?

high coupling makes the design more rigid, and any evolution or changes will be very difficult, for example if some client ask to provides also webservices, and if our model is highly coupled with CDocument , this evolution will cost a lot, on the other side if it’s independent to CDocument it can be developed more easily.

What’s the conclusion of this story?

• High cohesion and low coupling are two powerful concepts that assist your design, but their benefits are more visible only if evolutions or changes are needed.
• Be careful when using external frameworks, and not understanding the design provided by the framework could impact a lot the design quality of your application.

CppDepend focus more on design analysis to understand the structure of existing code, and many times we ask us if CppDepend can detect implementation problems, like variables not initialized, 64 bits and parallel issues.

For that there are other tools that complements CppDepend to detect this kind of issues and we recommend PVS-Studio.

PVS-Studio is a static code analyzer intended for developers of modern resource-intensive C and C++ applications. By modern applications we understand 64-bit and/or parallel applications. Development of such programs involves some difficulties different from the problems you face when developing conventional programs. For besides usual errors known to everybody like uninitialized pointers, which are detected by any compiler, there are new types of problems.

We speak about the errors in programs which occur when porting 32-bit applications on 64-bit platforms or paralleling the code to provide support of multi-processor or multi-core mode. It is rather difficult to develop such applications because of lack of tools which could simplify creation of 64-bit and parallel programs. PVS-Studio analyzer is quite a tool for this purpose!

Though PVS-Studio code analyzer user interface is rather simple, still, to use the tool most efficiently, you should understand the principles and technology of static code analysis. After reading this article and examining the examples described in it, you will be able to use PVS-Studio in your everyday work.
Purpose, abilities and system requirements of PVS-Studio.

The static code analyzer PVS-Studio is intended for developers of modern resource-intensive C and C++ applications. At present, PVS-Studio includes two units:

• Viva64 is a subsystem of diagnosing errors characteristic of 64-bit systems;
• VivaMP is a subsystem of diagnosing errors in parallel programs built on OpenMP technology.
With the help of these two units PVS-Studio allows you to detect in the source code of C and C++ programs the following types of defects:
• errors of migration of 32-bit applications on 64-bit systems;
• errors occurring when developing new 64-bit applications;
• non-optimal use of memory in 64-bit programs due to alignment peculiarities;
• errors in parallel programs relating to insufficient knowledge of OpenMP directives’ syntax;
• errors in parallel programs relating to insufficient knowledge of the principles of paralleling code using OpenMP technology;
• errors of incorrect memory operation in parallel code (unprotected main memory access, absence of synchronization, incorrect mode of access to variables etc).
PVS-Studio analyzer is intended for working on Windows-platform. It integrates into Microsoft Visual Studio 2005/2008/2010 development environment. The system requirements to the analyzer coincide with the requirements to Microsoft Visual Studio:
• Operation System: Windows 2000/XP/2003/Vista/2008 x86 or x64. Attention: to analyze 64-bit applications it is not necessary to have a 64-bit operation system.
• Development environment: Microsoft Visual Studio 2005/2008/2010 (Standard Edition, Professional Edition, Team Systems). To analyze 64-bit applications you must have a component of Visual Studio “X64 Compilers and Tools” installed. It is included into all the listed versions of Visual Studio and can be installed through Visual Studio Setup. Pay attention that PVS-Studio cannot operate Visual C++ Express Edition for this system does not support extension units.
• Hardware: PVS-Studio operates on systems with no less than 1 Gb of main memory (it is recommended that you have 2 Gb and more); the analyzer can work at several cores (the more cores, the faster code analysis).

Getting acquainted with PVS-Studio

After installing the examples PortSample and ParallelSample you can start examining PVS-Studio. Open PortSample project in Microsoft Visual Studio.

Figure 1 – Selection of PortSample demo-project

You should begin working with PVS-Studio with one of our demo-projects due to some reasons:

• firstly, they cover all the code defects diagnosed by PVS-Studio;
• secondly, you can watch behavior of an application with an error in a real example;
• thirdly, PVS-Studio demo-version shows location only of some of the defects and errors in the code (although it detects them all). But for PortSample and ParallelSample we have made an exception – for them all the defects are shown.

So, open PortSample project, select 64-bit configuration x64 to check presence of defects in 64-bit code, with the help of PVS-Studio command bar select analysis of 64-bit problems – Viva64 unit “64-bit issues (Viva64)” and launch analysis of the whole solution by the command “Check Solution”. All this is shown on Figure 2.

Figure 2 – Check of PortSample solution on presence of 64-bit problems

x64 configuration is chosen deliberately. You can check only the 64-bit configuration on 64-bit code problems. The point is that the project’s settings in the 64-bit configuration are different from those of the 32-bit one. So you cannot perform check of 64-bit code in the 32-bit configuration.

After launching analysis, you will see a progress indicator with Pause (pause analysis) and Stop (stop analysis) buttons on the screen. Potentially unsafe constructions detected during analysis will be printed in the window of detected defects (Figure 3).

Figure 3 – Analysis of the project – problems detected in the code are printed in the window at once

The term “potentially unsafe construction” means that the analyzer considered some particular code line a defect. But only the programmer who knows the application can determine if this line is really a defect of the application or not. This principle of working with code analyzers must be understood correctly.

Generally, no tool can replace a programmer completely when solving the task of correcting errors in programs. Only a programmer can do it relying on his knowledge. But a tool can and must help the programmer in this task. That’s why a code analyzer’s task is to reduce the number of places in the code which the programmer must look through and investigate.

But let’s return to PVS-Studio analyzer. Analysis of the whole code is complete and now you can start looking through the messages. By the way, if you have a multi-core processor analysis will be performed faster for all the cores will be used.

Correction of errors

After getting a list of diagnostic warnings from the code analyzer, you can study it. Let’s consider the first
error:
V101: Implicit assignment type conversion to memsize type. v1xx.cpp 34

Here is its code:

size_t bufferSize = imageWidth * imageHeght *
bytePerPixel * maxFrameCountInBuffer;

The problem here is that the resulting size of the buffer (bufferSize variable) has the right size size_t but the variables participating in the expression (imageWidth, imageHeight, bytePerPixel and maxFrameCountInBuffer) have int type. The result of multiplication of these variables has also int type. It is not crucial for values less than 2 Gb for type conversion takes place. But if you get a result more than 2 Gb it will be cut to 2 Gb despite that bufferSize variable has a right type. To correct this error you should change the type of the variables participating in the expression. You can do this in a preciding code section. Instead of:

unsigned imageWidth = 1000;
unsigned imageHeght = 1000;
unsigned bytePerPixel = 3;
unsigned maxFrameCountInBuffer;

let’s write:

size_t imageWidth = 1000;
size_t imageHeght = 1000;
size_t bytePerPixel = 3;
size_t maxFrameCountInBuffer;

You can learn about this correction from the Help system. After pressing Alt+H (with mouse or F4 button) when studying a new error, the online help page will open with the description of the error:

Figure 4 – Detailed description of the error and the ways to correct it are given in online help

After correcting the used data types let’s relaunch analysis. You will see that the number of diagnostic warnings is less in one. It means that the problem is corrected. In the same way you should deal with all the diagnostic warnings and correct those places in the code where there are possible problems.

Working with the list of diagnostic warnings

Of course, in large real projects there will be not some tens of diagnostic warnings, but hundreds or even thousands of them. And looking through all of them is not a simple task. To simplify it PVS-Studio has several mechanisms. The first is filtration of warnings by the code of an error. The second is filtration by the content of the text of a diagnostic warning. The third is filtration by the paths to files. Let’s consider the examples of using filtration systems.

Suppose you be sure that diagnostic messages with V112 code (using magic numbers) are not relevant to your application. In this case you may turn off showing of these diagnostic warnings with the help of the code analyzer’s settings:

Figure 5 – Turning off some diagnostic warnings by the code

After that all the warnings with V112 code will disappear from the list of warnings. And you do not need to relaunch analysis for this. If you turn on these warnings they will appear in the list again without relaunching analysis.

Now let’s consider another variant of filtration on the basis of the text of diagnostic warnings. Let’s get back to PortSample example. One of the errors in this example is access to the array “array” using an index of int type:

V108: Incorrect index type for “array”. Use memsize type instead. v1xx.cpp 183

Here is the code:

volatile int index = 0;
for (size_t i = 0; i != n; ++i) {
array[index++] = 1; // error
if (array[i] != 1)
throw CString(“x64 portability issues”);
}

Of course, you may just change the type of index variable from unsigned to size_t and the problem will disappear. But if there are a lot of code sections with access to array variable and you are sure that there are not more than 2 billions of items in array, you may “ask” the code analyzer not to show the warnings whose text contains the word “array”. You can do this with the help of the settings on MessageSupression page:

Figure 6 – Turning off some diagnostic warnings by the text

After that all the diagnostic warnings whose text contains the word “array” will disappear from the list without relaunching the code analyzer. You can get them back by simply removing the word “array” from the filter.
The last mechanism of reducing the number of diagnostic warnings is “Don’t Check Files” setting.

You may specify file masks on the tab “Don’t Check Files” to exclude some files from analysis. The analyzer will not check those files that meet the mask’s conditions.

Figure 7 – Setting filtration of messages by files’ names

Using this method, you may, for instance, exclude autogenerated files from analysis. Besides, you may define the files to be excluded from analysis by the name of the folder they are situated in.
A mask is defined with the help of wild card match types like in MS-DOS. The following wild cards can be used:
• ? – any character;
• - any number of any characters;
The case of characters does not matter.

If a mask is specified without a full path (i.e. without the characters “:” and “\”), the check is performed ONLY by the file name. For instance, the mask “V*.CPP” covers the files c:\test\V1111.cpp and d:\project\V1111.cpp. But if you define the mask as c:\*.cpp, the file d:\project\V1111.cpp will not fall under it.

Here are some examples:
*ex.c – all the files whose names end with “ex” and which have the extension “c” will be excluded from analysis.
c:\Libs\*.cpp – all the files with the extension “cpp” in the folders c:\Libs\XX, c:\Libs\XX\YY, c:\Libs\ZZ, etc. will be excluded.
If you change a mask, you will need to relaunch the analyzer.

In PVS-Studio, there is a possibility called “Mark as False Alarm”. Due to it, it is possible to mark those lines in the source code, in which false alarm of the code analyzer occurs. After the marking, the analyzer will not produce diagnostic messages for such code any more. This allows to use the analyzer constantly with more convenience in the process of software development for verifying new code.
Thus, in the following example, the output of the diagnostic message with code V104 is disabled:

size_t n = 100;
for (unsigned i = 0;
i < n; //-V104
i++)
{
// …
}

This feature is described thoroughly and in detail in the article "PVS-Studio: use of "Mark as False Alarm" function".
There are also many other means to handle diagnostic warnings to be shown by setting the code analyzer but they lay beyond consideration in this document. We recommend that you refer to the documentation on the code analyzer's settings.

Should all the potential errors detected by the analyzer be corrected?

Having looked through all the warnings shown by the code analyzer you will find both real errors in programs and constructions that are not errors. The point is that the analyzer cannot detect all the errors in programs 100% accurately without the so called "false responses". Only the programmer who knows and understands the program can determine if there is an error in a particular place. The code analyzer can only significantly reduce the number of sections which must be looked through by the developer.

Thus, of course, there is no sense in trying to correct all the potential problems detected by the code analyzer.

But you should try to correct as many code sections as you can. It is especially relevant when the static analyzer is used not once just to verify an application when, for example, porting it on a 64-bit system, but regularly with the purpose to detect new errors and insufficient constructions. In this case correction of sections which are actually not errors, and also setting of the analyzer to suppress some types of errors will allow you to significantly save on time when using the analyzer next time.

You can define Ca and Ce for the graph of projects dependencies, the graph of namespaces dependencies, the graph of types dependencies and the graph of methods dependencies of a code base. You can also define the Ca metric on the fields of a program as the number of methods that access the field. This leads to 9 metrics all supported by the tool CppDepend We precise that when computing Ce.

With CppDepend, if you wish to know which methods of your program are massively used you can write the following CQL Query :

SELECT TOP 10 METHODS ORDER BY MethodCa DESC

Being used a lot is not necessarily a problem. However it is still interesting to know which part of your code base is used a lot.

High Efferent Coupling and design flaws

If you wish to know which types of your program are heavy users of other types you just have to write:

SELECT TOP 10 TYPES ORDER BY TypeCe DESC

High Ce might reveal a design problem. Types with high Ce are entangled with many other implementations. The higher the Ce, the higher the number of responsibilities the type has.

What about reusing garbage collector?

The class representing the garbage collector is MarkCompactCollector, this class has a TypeCe equal to 34, but how many types this class use indirectly.

SELECT TYPES WHERE IsUsedBy “v8.internal.MarkCompactCollector“

And there’s the result

And the metric view shows better relation between MarkCompactCollector class and other V8 types:

So it’s very difficult to isolate only the garbage collector mechanism from V8 source code, Maybe in the future the V8 team will isolate this garbage collector, and it will be used in other projects.

It’s very interesting to discover how this engine is implemented and what lessons we can take when analyzing it.

here’s some remarks about this engine:

Optimization is also a design issue

When I hear that google chromium browser use fast javascript engine, I was sure that it was developed with “C” language like almost all known languages and interpreters (Perl, Python, PHP, Spider Monkey), but when I got the source code, I was very surprised that‘s developed with C++.

The goal of this engine is to be very fast and the decision of V8 team to choose C++ proof that performance depends also on design choices more than language choice.

There’s some V8 Design Choices:

Hidden Class:

JavaScript is a dynamic programming language: properties can be added to, and deleted from, objects on the fly. This means an object’s properties are likely to change.
Javascript has a class concept but there’s a class representing it in source code?

To answer to this question let’s search in V8 source code all objects kind treated, for that we can execute the following request:

SELECT TYPES WHERE DeriveFrom “v8.internal.JSObject“

as we can observe there’s no class inheriting from JSObject representing a Class like Function or Value, it’s normal because in any dynamic langage the idea is to create a class in the real time and most JavaScript engines use a dictionary-like data structure as storage for object properties,each property access requires a dynamic lookup to resolve the property’s location in memory.

This approach makes accessing properties in JavaScript typically much slower than accessing instance variables in programming languages like Java and Smalltalk. In these languages, instance variables are located at fixed offsets determined by the compiler due to the fixed object layout defined by the object’s class. Access is simply a matter of a memory load or store, often requiring only a single instruction.

V8 use hidden class concept to reduce the time required to access JavaScript properties. V8 does not use dynamic lookup to access properties. Instead, V8 dynamically creates hidden classes behind the scenes as detailled in this post.

Dynamic machine code generation:

V8 compiles JavaScript source code directly into machine code when it is first executed. There are no intermediate byte codes, no interpreter. Property access is handled by inline cache code that may be patched with other machine instructions as V8 executes.

let’s discover the dependency graph for MakeCode function.

Garbage collector:

V8 use an efficient garbage collector to manage memory, and I was very interested to know if I can use it easily in other C++ projects, for that I have to look if the garbage collector classes are highly coupled with other V8 classes or not.

An interesting question is to know if we can use MarkCompactCollector in other C++ projects.

for that let’s search for indirect dependencies for this class:

SELECT TYPES WHERE IsUsedBy “v8.internal.MarkCompactCollector“

Unfortunately this class is highly coupled with a lot of other V8 classes.

V8 is optimized and use design patterns:

I dont know why many developpers think that using OOP and design patterns can impact a lot the optimization.

V8 is an example of project that use OOP and patterns and in the same time very optimized.

here’s for example two patterns used:

Factory:

The factoy class create many objects needed and do abstraction of garbage collector invocation, for example let’s search for methods invoked by Factory::NewJsObject

SELECT METHODS WHERE IsDirectlyUsedBy “v8.internal.Factory.NewJSObject(Handle,PretenureFlag)“

as we can observe this method do some abstraction of memory allocation.

Visitor:

V8 contains many classes implementing visitor pattern.

Make C++ easy to use:

Memory allocation simplified

Managing memory and allocating pointers is complicated in C++ Using garbage collector can simplify this task.

Avoid multiple inheritance

Let’s search for classes with multiple base classes:

SELECT TYPES WHERE NbBaseClass >1

and the result of this query is empty so V8 dont use multiple inheritance, it simplify a lot the developement and evolution of application.

Use RTTI carefully

Using RTTI resolve some problems but can be an indicator of a bad design, be sure to no overuse this technique.

Let’s search if V8 use dynamic_cast:

SELECT METHODS WHERE IsDirectlyUsing “Keywords.dynamic_cast“

the result is empty and it’s an indicator from others that V8 is well designed.

Exceptions

Using exceptions is interesting but is not easy that a code be exception safe.
V8 team choose to not use exceptions to simplify the implementation.

we can execute the following CQL request to know if exception is used:

SELECT METHODS WHERE IsDirectlyUsing “Keywords.throw“

Refactoring improves the quality of application design and implementation, but unfortunately the expression “If it is working don’t change” is many times used to bypass it.

We can found in general three cases concerning refactoring:

- Iterative refactoring: each application can’t be developed perfectly in the first iteration without any feedbacks, even if the team has the best of the architects, designers and developers. The easy way to do refactoring without investing a lot of money and without wasting time is to integrate it in the development process and do it after each iteration.

- Refactoring when is necessary: after the application is deployed, there are some feedbacks and bugs, if resolving them take a lot of time or some client needs are very complex to develop and integrate to the existing system, a refactoring can be a good solution to improve the quality of the code base, but in this case it can be very risky and we have to take care to avoid regression in the existing code.

- Not refactor: sometimes even if there are many problems in the existing application, a refactoring is never began, because the boss not want to invest in this process, and the support team have to manage the stress generated by all bugs and feedbacks.

Which factors can influent the quality of design and implementation?

To avoid investing a lot of money and time when refactoring, the good solution is to design well the application, but there are some traps that can influent the code quality:

No architect and designers in the team:

Unfortunately there are some projects initiated with only developers, and no architect is present, the problem is that we can discover this misconduct very early and it can contribute of the project failing.

Prototype:
A prototype typically simulates only a few aspects of the features of the eventual program, and may be completely different from the eventual implementation.

Unfortunately many projects are based on the prototype without any review of architecture, design and implementation, and this trap is due to the rapidity of development and the team thinks that’s a good solution to continue with a prototype to gain time.

Frameworks used:

Some frameworks provide useful classes but can influent also the design, for example MFC or Qt are intrusive frameworks.

Using some bad designed functionalities of such frameworks can influent to complicate the design of project, let’s take as example the Doc/View design provided by MFC, if a designer choose to consider CDocument as the model as encouraged by the MFC documentation, it will be a bad choice.
The model must be independent of MFC to be used in other contexts easily; however CDocument can be used as controller.

Technology high coupling:

Some architects and designers forget the low coupling concept, and propose a high coupled design with the technology or the frameworks used.

For example If CORBA is used for a distributed system, it must be isolated in the communication level, and all other classes must be CORBA independent.

Unfortunately in some projects we can found CORBA types used also in the business classes and it complicate a lot the application.

In my opinion this problem is the most popular and the very dangerous one; it has an enormous impact especially for C++ projects, indeed currently finding a good C++ developer is not very easy, and finding one who master many technologies and frameworks become very hard, so creating a high coupling application with technology used implies that all the team must know it, but if the application is low coupled with technology, it will facilitate the human resource department task and they can find easily C++ developers.

Your experience is very interesting to identify the bad design origin, for that you can vote to identify each factor is the most responsible.

View This Poll

Recently i read a famous linus torvalds opinion about C++, where he wrote:

“C++ is a horrible language. It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out,that in itself would be a huge reason to use C.”

I decide to do a quick analysis of Linux using CppDepend and try to understand the Linus opinion.

CppDepend can analyse Visual Studio projects without any configuration, but if the build process is described by another build processing system like Makefile, SCONS, CMake or others, the solution is to use the ProjectMaker to describe the project to be analyzed.

For Linux we can use ProjectMaker to describe projects to analyze.

Linux code source contains many directories, and to have a clear vision of code source we will associate each directory to a project.

And for each project we can specify other informations:

C vs C++ comparison

Modularity:Physical vs Logical

Modularity is a software design technique that increases the extent to which software is composed from separate parts , you can manage and maintain modular code easily.

We can modularize a project with two approachs:

- physically: by using directories and files, this modularity is provided by the operating system and can be applied to any langague.

- logically: by using namespaces,component,classes,structs and functions, this technique depends on the langague capabilties.

when we develop with C, and to package our code we use essentialy physical modularity, for example for Linux each module is isolated in directory and each file contains structs,variables and methods relative to a specific functionality.

This dependency graph shows relation between some linux directories:

C++ instead of C can use namespaces and classes to modularize the code, thoses types are provided by the langague, and for the previous graph we can use namespaces to modularize our code instead of directories.

C++ provide an efficient way to modularize the code base, but why namespaces artifacts are not enough used? for example only some C++ open source projects use it, maybe it’s due to historical reason or maybe we use “C with Classes” where the C habits are all the time present instead of modern C++.

What the difference between the two approachs?

Lisibility : the logical approch is better, because we can understand and use easily the code, and we dont need to know the physical emplacement of a code element.

Managing changes: a good design need in general many iterations, and for the physical approch the impact of design changes can be very limited than logical one, indeed we need only to move function or variable from a file to another, or move file from directory to another.

However for C++ it can impact a lot of code because the logical modularity is implemented by the langage artifacts and a code modification is needed.

Encapsulation:Class vs File

For C++ the encapsulation is defined as the process of combining data and functions into a single unit called class. Using the method of encapsulation, the programmer cannot directly access the data. Data is only accessible through the functions present inside the class.

For C we can have an encapsulation but using also a physical approach like described in the modularity section, and a class can be a file containing functions and data used by them, and we can limit the accesibility of functions and variables by using “static” keyword.

Linux use this technique to hide functions and variables, to discover that let’s search for static function:

SELECT METHODS WHERE IsStatic

and also we can search for static varibles:
SELECT FIELDS WHERE IsStatic

Lisibility:using C++ encapsulation mecanism improve the understanding and lisibility of code, C is low level and use physical approch rather than logical.

Managing changes:if we have to change the place where varibale or function are encapsulated, it can very easy for C, but for C++ it can impact a lot of code.

Polymorphism vs Selection idiom

Polymorphism means that some code or operations or objects behave differently in different contexts.

This technique is very used in C++ projects, but what about C?

for procedural langages the selection techniques by using the keywords “switch”, “if” or maybe “goto” can simulate the polymorphism behavior, but this technique tend to increase cyclomatic complexity of code.

Let’s search for complex function and see if the polymorphism can minimize the complexity.

the more complex function w9968cf_v41_ioctl use a big switch to differentiate a behavior that depends on a specific command, with C++ we can use polymorphism and command pattern to minimize the complexity of this code.

Lisibility: using Polymorphism permit the isolation of a specific behavior to a class, it improve the visibility of the code.

Managing changes: adding another behavior with polymorphism can implies the adding of another class, however with selection idiom, you can add only another case under the switch statement.

Inheritance vs Agregation

Linux use essentially structs to define data manipulated by functions.

Let’s search for all structs used:

SELECT TYPES WHERE IsStructure

but what happened when struct has a common data as another, for exemple many struct can be considered as “inode” with adding some other fields, in this case the agregation is used instead of inheritance, let’s search for structs using “inode”.

SELECT TYPES WHERE IsDirectlyUsing “inode“

Some structs using inode can be inherited from it, but the agregation technique is used instead.

Lisibility: using inheritance can improve the understanding of data, but we have to be carefull whene using it, its used only for the “Is” relation.

Managing changes: Inheritance implies a high coupling so any changes can impact a lot of code.

Conclusion:

C++ provide a better lisibility but any changes or refactoring can be difficult, and Linus talk about this idea of design changes in the same post:

“inefficient abstracted programming models where two years down the road you notice that some abstraction wasn’t very efficient, but now all your code depends on all the nice object models around it, and you cannot fix it without rewriting your app.”

But doing refactoring need to understand the existing code and design before making changes, and C program is very difficult to understand but easy to change, however C++ can be more lisible than C but need some effort when making changes.

How we can limit the impact of changes for C++?

The good solution to limit the impact of changements is to use patterns, specially low coupling concept to isolate changes only in a specific place, Irrlicht as explained in the previous post is a good example of using low coupling.

But when i discovered GRASP patterns , i advice any one interested to improve his skills design to look at this patterns, it gives a design fondamental rules.

Irrlicht is a 3D engine library that use many GRASP concepts, let’s discover with CppDepend the benefits of using this kind of patterns, and to show using of GRASP concepts we will focus on the namespace irr::gui.


Creator:

To detect with CppDepend the existence of creator, the easy way is to to use a CQL query like this:

SELECT METHODS WHERE DepthOfCreateA “irr.gui.CGUISkin” == 1

So the CGUIEnvironement is the only class that create CGUISkin,

but what about other GUI elements?

almost all GUIElement are created by CGUIEnvironement class except CGUIButton

SELECT METHODS WHERE DepthOfCreateA “irr.gui.CGUIButton” == 1

As we observe the CGUIButton is created in three different places, maybe there’s a reason for this behavior.

So the CGUIEnvironement class act as creator, but what’s the role of CDefaultGUIElementFactory class?

The dependency graph between CDefaultGUIElementFactory and CGUIEnvironement shows the relation between them:

Adding GUIElement begin with the invocation of CDefaultGUIElementFactory::addGuiElement , and this method invoke the right creation method from CGUIEnvironement, it depends of the type of element to create.

Controler

The Controler for GUIElements must at least manage event processing,this task is processed by CGuiEnvironement::OnEvent.

Let’s see which methods are used by OnEvent

SELECT METHODS WHERE IsUsedBy “irr.gui.CGUIEnvironment.OnEvent(constSEvent&)“

So the event fired is processed by a class that implement IEventReceiver.

Which classes implement this abstract class?
SELECT TYPES WHERE DeriveFrom “irr.IEventReceiver” ORDER BY DepthOfDeriveFrom

What’s the other responsabilities of CGUIEnvironement?

As we have seen before this class create the concrete classes and also manage event processing, and to discove if it do another responsability we can search for methods used by this class:

SELECT METHODS WHERE IsDirectlyUsedBy “irr.gui.CGUIEnvironment“

This class use also classes from irr::io namespace to persist and load into xml files , so maybe this class has many responsabilities and it can impact it’s cohesion, but it still tolerable because this class has all informations needed to persist data so this class follows the “Information Expert” principle of GRASP.

Low Coupling

Low coupling is desirable because a change in one area of an application will require less changes throughout the entire application. In the long run, this could alleviate a lot of time, effort, and cost associated with modifying and adding new features to an application.

Using abstract classes can improve the low coupling and we can evaluate the abstractness of a defined module by the following metric :

A = Na / Nc

Where:

* A = abstractness of a modulke
Zero is a completely concrete module. One is a completely abstract module.
* Na = number of abstract classes in the module.
* Nc = number of concrete classes in the module.

The abstractness of Irrlich is equal to 0.1245972, and it contains 125 abstract classes.

And for irr::gui namespaces there’s 28 abstract classes , for each GUI element there’s the equivalent interface.

SELECT TYPES FROM NAMESPACES “irr.gui” WHERE IsAbstract

CppDepend provide DSM graph, and we can triangularize this matrix to focus under red borders highly dependent classes, and to detect modules.

As we can observe all abstract classes are grouped, so we can consider them as module, so we can isolated them in another namespace or maybe in another project.

And to see the benefit of using abstract class to improve the low coupling, let’s search for classes that use the concrete class CGUISkin.

SELECT METHODS WHERE IsDirectlyUsing “irr.gui.CGUISkin“

So only one class know this class, it’s his creator.

And what about IGUISkin:

SELECT METHODS WHERE IsDirectlyUsing “irr.gui.CGUISkin“

Unlike CGUISkin the IGUISkin class is visible and used by many classes.

What about coupling between namespaces:





A dependency cycle exist between namespaces, having this dependency can be not problematic but avoiding it enforce loose coupling, but what’s interesting than this dependency cycle is the manner that namespaces interact with each others.

When we choose to work with abstract classes, it’s recommended to interact between functional namespaces using abstract classes rather than concrete classes, except for namespaces that contains utility classes like irr::core.

Is Irrlich follow this rule?

for that let’s see what the namespace irr use as classes and methodes.

SELECT METHODS WHERE IsDirectlyUsedBy “irr“

As we can see almost all interaction with other namespaces pass by abstract classes, except for irr::video::CVideoModelList and irr::scene::CMeshBuffer.

Let’s discover the origin of the dependency with irr::video::CVideoModelList, for that we can execute the following CQL query:

SELECT METHODS OUT OF TYPES “irr.video.CVideoModeList” WHERE IsUsing “irr.video.CVideoModeList“

so the class irr::CIrrDeviceWin32 use it because this class declare a field as video::CVideoModeList instead of video::IVideoModeList.

High cohesion

The single responsibility principle states that a class should have more than one reason to change. Such a class is said to be cohesive. A high LCOM value generally pinpoints a poorly cohesive class. There are several LCOM metrics. The LCOM takes its values in the range [0-1]. The LCOMHS (HS stands for Henderson-Sellers) takes its values in the range [0-2]. Note that the LCOMHS metric is often considered as more efficient to detect non-cohesive types.

LCOMHS value higher than 1 should be considered alarming.

SELECT TYPES WHERE LCOMHS > 0.95 AND NbFields > 10 AND NbMethods >10 AND !IsGlobal ORDER BY LCOMHS DESC

Only few classes are considered as no cohesive.

Conclusion:

Irrlicht use namespaces to modularize the code base and absract classes to improve low coupling, so it makes it very easy to understand and maintain.

It’s a good example to follow if you want to improve your design quality.