Est-il possible pour un #include manquant de casser le programme au moment de l'exécution?

Existe-t-il un cas où le fait de manquer un #includecasserait le logiciel au moment de l'exécution, alors que la construction continue?

En d'autres termes, est-il possible que

#include "some/code.h"
complexLogic();
cleverAlgorithms();

et

complexLogic();
cleverAlgorithms();

serait à la fois construire avec succès, mais se comporter différemment?

Oui, c'est parfaitement possible. Je suis sûr qu'il existe de nombreuses façons, mais supposons que le fichier include contienne une définition de variable globale qui a appelé un constructeur. Dans le premier cas, le constructeur s'exécute et dans le second, il ne s'exécute pas.

Mettre une définition de variable globale dans un fichier d'en-tête est un mauvais style, mais c'est possible.

Oui, c'est possible.

Tout ce qui concerne #includes se produit au moment de la compilation. Mais au moment de la compilation, les choses peuvent changer le comportement à l'exécution, bien sûr:

some/code.h:

#define FOO
int foo(int a) { return 1; }

puis

#include <iostream>
int foo(float a) { return 2; }

#include "some/code.h"  // Remove that line

int main() {
  std::cout << foo(1) << std::endl;
  #ifdef FOO
    std::cout << "FOO" std::endl;
  #endif
}

Avec le #include, la résolution de surcharge trouve le plus approprié foo(int)et imprime donc à la 1place de 2. De plus, puisque FOOest défini, il imprime en outre FOO.

Ce ne sont que deux exemples (non liés) qui me sont venus à l'esprit immédiatement, et je suis sûr qu'il y en a beaucoup plus.

Juste pour souligner le cas trivial, les directives de précompilateur:

// main.cpp
#include <iostream>
#include "trouble.h" // comment this out to change behavior

bool doACheck(); // always returns true

int main()
{
    if (doACheck())
        std::cout << "Normal!" << std::endl;
    else
        std::cout << "BAD!" << std::endl;
}

Et alors

// trouble.h
#define doACheck(...) false

C'est pathologique, peut-être, mais un cas connexe s'est produit:

#include <algorithm>
#include <windows.h> // comment this out to change behavior

using namespace std;

double doThings()
{
    return max(f(), g());
}

Ça a l'air inoffensif. Essaie d'appeler std::max. Cependant, windows.h définit max comme

#define max(a, b)  (((a) > (b)) ? (a) : (b))

Si tel était le cas std::max, ce serait un appel de fonction normal qui évalue f () une fois et g () une fois. Mais avec windows.h là-dedans, il évalue maintenant f () ou g () deux fois: une fois pendant la comparaison et une fois pour obtenir la valeur de retour. Si f () ou g () n'était pas idempotent, cela peut provoquer des problèmes. Par exemple, si l'un d'eux se trouve être un compteur qui renvoie un nombre différent à chaque fois ...

Il est possible de manquer une spécialisation de modèle.

// header1.h:

template<class T>
void algorithm(std::vector<T> &ts) {
    // clever algorithm (sorting, for example)
}

class thingy {
    // stuff
};

// header2.h

template<>
void algorithm(std::vector<thingy> &ts) {
    // different clever algorithm
}

// main.cpp

#include <vector>
#include "header1.h"
//#include "header2.h"

int main() {
    std::vector<thingy> thingies;
    algorithm(thingies);
}

Incompatibilité binaire, accès à un membre ou pire encore, appel d'une fonction de la mauvaise classe:

#pragma once

//include1.h:
#ifndef classw
#define classw

class class_w
{
    public: int a, b;
};

#endif

Une fonction l'utilise, et c'est ok:

//functions.cpp
#include <include1.h>
void smartFunction(class_w& x){x.b = 2;}

Apporter une autre version de la classe:

#pragma once

//include2.h:
#ifndef classw
#define classw

class class_w
{
public: int a;
};

#endif

En utilisant les fonctions principales, la deuxième définition modifie la définition de classe. Cela conduit à une incompatibilité binaire et se bloque simplement lors de l'exécution. Et corrigez le problème en supprimant le premier include dans main.cpp:

//main.cpp

#include <include2.h> //<-- Remove this to fix the crash
#include <include1.h>

void smartFunction(class_w& x);
int main()
{
    class_w w;
    smartFunction(w);
    return 0;
}

Aucune des variantes ne génère une erreur de temps de compilation ou de liaison.

La situation vice versa, l'ajout d'une inclusion corrige le crash:

//main.cpp
//#include <include1.h>  //<-- Add this include to fix the crash
#include <include2.h>
...

Ces situations sont encore plus difficiles à résoudre lors de la correction de bogues dans une ancienne version du programme ou lors de l'utilisation d'une bibliothèque externe / dll / objet partagé. C'est pourquoi il faut parfois respecter les règles de compatibilité descendante binaire.

Je tiens à souligner que le problème existe également en C.

Vous pouvez dire au compilateur qu'une fonction utilise une convention d'appel. Si vous ne le faites pas, le compilateur devra deviner qu'il utilise celui par défaut, contrairement à C ++ où le compilateur peut refuser de le compiler.

Par exemple,

main.c

int main(void) {
  foo(1.0f);
  return 1;
}

foo.c

#include <stdio.h>

void foo(float x) {
  printf("%g\n", x);
}

Sous Linux sur x86-64, ma sortie est

0

Si vous omettez le prototype ici, le compilateur suppose que vous avez

int foo(); // Has different meaning in C++

Et la convention pour les listes d'arguments non spécifiées exige que cela floatsoit converti doublepour être passé. Donc, bien que j'aie donné 1.0f, le compilateur le convertit 1.0dpour le transmettre foo. Et selon le supplément du processeur d'architecture AMD64 de l'interface binaire d'application System V, le doubleobtient est transmis dans les 64 bits les moins significatifs de xmm0. Mais fooattend un flottant, et il le lit à partir des 32 bits les moins significatifs de xmm0, et obtient 0.