Author: CppDepend Team

How it was the C source code 25 years ago?

C is one of the most popular language around all the world, it was initially developed by Dennis Ritchie between 1969 and 1973 at AT&T Bell Labs. Many thousands of projects was developed using C since then. It’s used for all kinds of needs, we can enumerate OS, embedded applications, gaming development, image processing, word processing and database engines.

It’s interesting to discover the evolution of a language, and how it evolved over years of feedbacks from developers and end users. We will go back 25 years ago to discover how some C projects were implemented. Continue reading “How it was the C source code 25 years ago?”

20 Years of Boost C++: Original Vision Review

In 1998 a proposal for  a C++ Library Repository Web Site was posted by Beman G. Dawes. The original vision aims to satisfy two major goals:

  • A world-wide website containing a repository of free C++ class libraries would be of great benefit to the C++ community. Although other sites supply specific libraries or provide links to libraries, there is currently no well-known website that acts as a general repository for C++ libraries. The vision is this: a site where programmers can find the libraries they need, post libraries they would like to share, and which can act as a focal point to encourage innovative C++ library development. An online peer review process is envisioned to ensure library quality with a minimum of bureaucracy.
  • Secondary goals include encouraging effective programming techniques and providing a focal point for C++ programmers to participate in a wider community. Additionally, such a site might foster C++ standards activity by helping to establish existing practice.

Continue reading “20 Years of Boost C++: Original Vision Review”

Spotting C++11/C++14/C++17 Features in WinObjC: A Study

In a previous post we talked about the clang-modernize tool to detect where you can use some new C++11 features to modernize your C++ source code. But how can we easily detect where the new C++ features are used in a project?

Facebook and Google use C++11 extensively in their source code. Folly from Facebook as we discovered in a previous post use almost all of the C++11 features and I was curious to know if Microsoft also use the new  C++11 standards in their open sourced code. Continue reading “Spotting C++11/C++14/C++17 Features in WinObjC: A Study”

Lessons to learn from the CLang/LLVM codebase

It’s proven that Clang is a mature compiler For C and C++ as GCC and Microsoft compilers, but what makes it special is the fact that it’s not just a compiler. It’s also an infrastructure to build tools. Thanks to its library based architecture which makes the reuse and integration of functionality provided more flexible and easier to integrate into other projects. Continue reading “Lessons to learn from the CLang/LLVM codebase”

Optimize Memory in C++: Doxygen Case Study

When the processes running on your machine attempt to allocate more memory than your system has available, the kernel begins to swap memory pages to and from the disk. This is done in order to free up sufficient physical memory to meet the RAM allocation requirements of the requestor.

Excessive use of swapping is called thrashing and is undesirable because it lowers overall system performance, mainly because hard drives are far slower than RAM. Continue reading “Optimize Memory in C++: Doxygen Case Study”

Discover your C++ project internals: POCO case study

The POCO C++ Libraries are a collection of open source class libraries for developing network-centric, portable applications in C++.

POCO stands for POrtable COmponents. The libraries cover functionality such as threads, thread synchronization, file system access, streams, shared libraries and class loading, sockets and network protocols (HTTP, FTP, SMTP, etc.), and include an HTTP server, as well as an XML parser with SAX2 and DOM interfaces and SQL database access.

The modular and efficient design and implementation makes the POCO C++ Libraries well suited for embedded development. Continue reading “Discover your C++ project internals: POCO case study”

5 Common reasons of using namespaces in C++ projects

Namespaces were introduced to the C++ Standard in 1995 and usually they are defined like this:

A namespace defines a new scope. They provide a way to avoid name collisions.

Namespaces in C++ are most often used to avoid naming collisions. Although namespaces are used extensively in recent C++ code, most older code does not use this facility. 

After exploring the source code of many C++ projects, here are some common reasons of using the namespaces in these projects. Continue reading “5 Common reasons of using namespaces in C++ projects”

Detect the obfuscated names in a C/C++ project

How many times do you already discover a code like this:

obfuscatednames

Maybe in some cases it’s not a big issue to have such code. But if this coding habit is used many times by the developers, it will cost a lot to the company. Each new comer who needs to debug or add a new feature will spent a lot of time to understand the existing codebase.

How to detect these obfuscated names to refactor them? Continue reading “Detect the obfuscated names in a C/C++ project”

Good coder should hate to code a lot.

Coding is fun for many developers and as coder you are guaranteed to not be bored, each year many new languages, technologies, frameworks and libraries emerge.

The coders are the central piece of a project, their contribution are very important and having good coders is a big guarantee to make a project a success.

But who can be qualified as a good coder, the one who code a lot in a reduced time? Continue reading “Good coder should hate to code a lot.”

Managing Technical Debt with Agile Algorithm

Form wikipedia we can discover a brief explanation about the technical debt:

Technical debt (also known as design debt[1] or code debt) is “a concept in programming that reflects the extra development work that arises when code that is easy to implement in the short run is used instead of applying the best overall solution”.[2]

Technical debt can be compared to monetary debt.[3] If technical debt is not repaid, it can accumulate ‘interest’, making it harder to implement changes later on. Unaddressed technical debt increases software entropy. Technical debt is not necessarily a bad thing, and sometimes (e.g., as a proof-of-concept) technical debt is required to move projects forward. On the other hand, some experts claim that the “technical debt” metaphor tends to minimize the impact, which results in insufficient prioritization of the necessary work to correct it.[4][5]

Continue reading “Managing Technical Debt with Agile Algorithm”