Skip to main content

Welcome to The Deep Blue C++

Waves at Getaria/Gu├ęthary, Aquitaine, France

During my years as a software engineer, I have learnt quite a lot of things - and I keep learning every day. I learn from practice, discussions with workmates, reading... I especially learn from mistakes: code that doesn't do what I expect, code that doesn't do anything at all, code that does it but with some occasional crash or two... If you're a programmer, you know what I'm talking about.

What I've learnt has substantially changed the way I write code. In my first years as a programmer I tried to avoid mistakes, but I hadn't made enough of them yet to discover the best ways to prevent them. Now I know better. I know there are some things that bring you into trouble very quickly. Other things will silently wait for the worst moment - maybe months or years later, to come to the surface in the form of even more original problems. Disorganized code, uninitialized variables, pointer arithmetics, implicit casts, syntactic overloading, inheritance in which functions hide other functions, too complex expressions, unclear function or class semantics... the list of things which you'd better avoid in the first place has become rather long during the years.

I decided to start a blog where I'll organize and share my experiences and ideas, so that I won't forget them. As a plus, you'll be able to read them and give me your feedback. I will appreciate any comments you leave in this place. I'm sure I can learn a lot from them!

There are already many C++ blogs, often written by people who know much more about software and C++ than I'll ever do. I hope my contribution will add some practical aspects which I feel may be useful, especially for novice programmers.

Software programs have two kinds of audience. They are written for a computer to execute them, but also for people to read and hopefully understand them in the future. The best programs are those which work well in both ways – the machine does its job, and humans can make that work evolve into something which suits new needs.

We write software to change the world, because programs are run to change something. Their lines will be spelled tomorrow with effects that we cannot fully foresee. We rise waves which will go a long way until they reach a far away shore - one which our eyes may never see.

Let’s take a dive. Welcome to The Deep Blue C++!


  1. Thank you for your two cents worth! (or your "Little grain of sand") :P
    I'm sure you can help Indian Politicians, too! See this link below:



    1. Thank you Oriol for the very first comment in The Deep Blue C++! It all began in Carrer de Figueres, you know :-) Every politician should be able to compare two strings in C++, that's the bare minimum! :P

  2. Hi Daniel! Looking at your blog, I was wondering if you can help me in writing code for Text Clipping in Computer Graphics in c++? I don't know how to start and I can't seem to google anything on writing its logic.
    P. S. I need it ASAP. Can you help?

    1. Hi varun, sorry, actually I can't help you because I don't have any experience in the subject you mention. I'm sure there must be somewhere (libraries, book shops) where you can find good learning material. Good luck!


Post a Comment

Popular posts from this blog

#11. Don't use syntactic overloading

Syntactic overloading (or function overloading) is a C++ feature which allows a class to have several functions with the same name, but with different parameters. To say "Don't use syntactic overloading" is the same as to say "Don't give the same name to different functions".

class C
    void add(int i);
    void add(double d);
    void add(C other);

When you write this client code:

C c;

The compiler will call the appropiate version of the funcion add, depending on the type of x.

This is what syntactic overloading is. It is called syntactic overloading to distinguish it from semantic overloading 8more properly called dynamic binding), which is the one that happens when you use inheritance and polymorphism.

Syntactic overloading may seem useful at first sight, but it has lots of drawbacks for no real advantage. It just can go wrong in too many ways.

Code is more readable without syntactic overloading. One name for each thing, different n…

#2. Make all type conversions explicit

Assignments, function calls and expressions in general should not contain implicit type conversions. All type conversions should be explicit.

Type conversions should be isolated in their own line, which should consist only of the assignment of the result of the type conversion to a variable of the target type.

A statement should not mix type conversion with other operations. For example, if you need to convert an object to one of another type to pass it as a function parameter, do not do it in the function call itself; instead, do it in a separate instruction in the previous line.
Type conversion occurs when an entity of type A is, well, converted to an entity of type B. This may occur in function calls, expressions using operators, or assignments.
An explicit type conversion is one which you can read in the code. An implicit type conversion is one which does not appear in the source code, but is done automatically when the software is executed.
Making all type conversions explicit he…

#10. Choosing the right loop structure

C++ has three loop instructions: for, while and do ... while. To choose wisely among them, you need to know what their differences are.
1) for A for loop makes sense when you repeat an action for a known number of times, or for all the elements of a known set.

This is the syntax of a forloop:

for (initialization; condition; expression)

statement is actually a compound statement, that is, a block of code. This is called the body of the loop. In contrast, the initialization, condition and expression together are called the header of the loop. The initialization is a single statement which ends at the semicolon I wrote after it. The condition is a boolean expression. The expression is a statement. It should be a single statement which modifies one variable which is involved in the condition (see #guideline #5).

The initialization is performed. Then, the condition is evaluated. Then, two things can happen. If the condition is false, the code jumps right after the for statemen…