1h;1!H;${;g;s/<h2.*</h2>/No title here/g;p;}

Adopt DevOps (https://about.gitlab.com/2017/03/06/introduce-continuous-workflows)!L'idée c'est d'améliorer la productivité et la qualité d'une équipe de développement en améliorant la communication au sein de l'équipe. Donc :

• Continuous Integration (via GitLab, ...) pour savoir quand le code plante et en discuter (via Rocket.chat, ...). Plus on a de tests unitaires représentant la spécification, plus on est sûr que chacun à implémenter la spécification de la bonne manière.
• Tous les développeurs peuvent pousser leur code sur la branche de dev en cours sans autorisation préalable, afin de pouvoir en discuter
• Continuous Delivery (via GitLab, ...) et livraisons intermédiaires fréquentes (au client ou en interne) pour avoir le plus de feedback possible

Le dernier point rejoint cet article : https://about.gitlab.com/2017/04/27/why-code-is-released-too-early

Pour me rappeler, je m'essai aux résumés.

Prefer NRVO to RVO

* RVO = return-value optimization

MyData myFunction() {
    return MyData(); // Create and return unnamed obj
}
MyData abc = myFunction();

With RVO, the C++ standard allows the compiler to skip the creation of the temporary, treating both object instances—the one inside the function and the one assigned to the variable outside the function—as the same. This usually goes under the name of copy elision. But what is elided here is the temporary and the copy.

• NRVO = named return-value optimization

MyData myFunction() {
  MyData result;           // Declare return val in ONE place
  if (doing_something) {
    return result;       // Return same val everywhere
  }
  // Doing something else
  return result;           // Return same val everywhere
} 
MyData abc = myFunction();

Named Return Value Optimization is similar but it allows the compiler to eliminate not just rvalues (temporaries), but lvalues (local variables), too, under certain conditions.

But many compilers are actualy failing to apply NRVO with the following code:

 MyData myFunction() {
    if (doing_something)
        return MyData();     // RVO expected

    MyData result;

    // ...
    return result;           // NRVO expected
} 
MyData abc = myFunction();

So previous example has to be preferred.

Return parameters by value whenever possible

Surprisingly, don’t use "out-parameters" but prefer "return-by-value", even if it implies creating a small struct in order to return multiple values. I will check that, because it seems strange to me.

“out” parameter pointers force a modern compiler to avoid certain optimisations when calling non-inlined functions.

Prefer:

struct fractional_parts {
    int numerator;
    int denominator;
};

fractional_parts convertToFraction(double val) {
    int numerator = /*calculation */ ;
    int denominator = /*calculation */ ;
    return {numerator, denominator}; // C++11 braced initialisation -> RVO
}
auto parts = convertToFraction(val);
use(parts.nominator);
use(parts.denominator);

than:

void convertToFraction(double val, int &numerator, int &denominator) {
    numerator = /*calculation */ ;
    denominator = /*calculation */ ;
}

int numerator, denominator;
convertToFraction(val, numerator, denominator); // or was it "denominator, nominator"?
use(numerator);
use(denominator);    

Cache member-variables and reference parameters

Prefer:

template <class T> 
complex<T> &complex<T>;::operator*=(const complex<T> &a) {
   T a_real = a.real, a_imag = a.imag;
   T t_real =   real, t_imag =   imag; // t == this
   real = t_real * a_real – t_imag * a_imag;
   imag = t_real * a_imag + t_imag * a_real;
   return *this;
}

than:

template <class T> 
complex<T> &complex<T>;::operator*=(const complex<T> &a) {
   real = real * a.real – imag * a.imag;
   imag = real * a.imag + imag * a.real;
   return *this;
}

It seems the example is too simple to really understand the benefits. I do not want to make my code more complex for such a simple case... I do not like this advice.

Organise intelligently member variables

Due to the CPU caches mechanisms (blocks of 64-byte), it is propose to organise member variables in a class as follow:

• Move the most-frequently-used member-variables first
• Move the least-frequently-used member-variables last
• If variables are often used together, group them near each other
• Try to reference variables in your functions in the order they’re declared

Why not...

Oui, un framework Web en Qt.

Bibliothèques Javascript pour faire des graphes avec des contraintes au niveau du rendu (certains points fixes, d'autres non, organisation pour l'affichage d'une molécule, groupe, ...).
Quelqu'un a testé ?

(via je ne sais plus qui)

Ce topic est à lire en détail ! C'est un sujet qui m'intéresse et me passionne tout à la fois en ce moment. Mais le plus frustrant c'est qu'il est particulièrement difficile d'atteindre le système fiable et sûre à 99%. J'aimerai le créer au moins une fois, quit à le rendre non user-friendly, histoire de pouvoir faire correctement ma sauce dans de vrais projets.