After 17 years of active development, does the Boost C++ library meet its original vision?

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 web site 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 web site that acts as a general repository for C++ libraries. The vision is of a site where programmers can find libraries they need, post libraries they would like to share, and 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 “After 17 years of active development, does the Boost C++ library meet its original vision?”

Easy way to detect where the C++11/C++14/C++17 features are used in a C++ project : WinObjC case 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 we can easilly detect where the new C++ features are used in a project?

Facebook and Google use intensively C++11 in their source code. Folly from Facebook as we discovered in a previos post use almost all 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 “Easy way to detect where the C++11/C++14/C++17 features are used in a C++ project : WinObjC case study.”

Comparing the codebase of the original Quake3 and the kenny edition one.

Quake III Arena is a multiplayer-focused first-person shooter video game released in December 1999. The game was developed by id Software. Quake III was a very popular game and even now it’s still popular and many gamers enjoy with it.

The original source code of Quake3 can be found here https://github.com/id-Software/Quake-III-Arena Continue reading “Comparing the codebase of the original Quake3 and the kenny edition one.”

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 the memory usage of a C++ application: 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 the memory usage of a C++ application: 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.”

Make the most of the technical debt with an agile algorithm and a baseline comparison.

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 “Make the most of the technical debt with an agile algorithm and a baseline comparison.”