É possível que um #include ausente interrompa o programa em tempo de execução?

Existe algum caso em que a falta de um #includeinterrompa o software em tempo de execução, enquanto a compilação ainda continua?

Em outras palavras, é possível que

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

e

complexLogic();
cleverAlgorithms();

ambos construiriam com sucesso, mas se comportariam de maneira diferente?

Sim, é perfeitamente possível. Tenho certeza de que existem várias maneiras, mas suponha que o arquivo de inclusão contivesse uma definição de variável global chamada de construtor. No primeiro caso, o construtor executaria, e no segundo, não.

Colocar uma definição de variável global em um arquivo de cabeçalho é um estilo pobre, mas é possível.

Sim, isso é possível.

Tudo sobre #includes acontece em tempo de compilação. Mas, em tempo de compilação, as coisas podem mudar o comportamento em tempo de execução, é claro:

some/code.h:

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

então

#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
}

Com o #include, a resolução de sobrecarga encontra o mais apropriado foo(int)e, portanto, imprime em 1vez de 2. Além disso, como FOOé definido, ele também imprime FOO.

São apenas dois exemplos (não relacionados) que vieram à minha mente imediatamente e tenho certeza de que há muito mais.

Apenas para apontar o caso trivial, as diretivas de pré-compilador:

// 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;
}

E depois

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

É patológico, talvez, mas já tive um caso relacionado:

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

using namespace std;

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

Parece inócuo. Tenta ligar std::max. No entanto, windows.h define max como

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

Se fosse std::max, seria uma chamada de função normal que avalia f () uma vez eg () uma vez. Mas com windows.h, agora ele avalia f () ou g () duas vezes: uma vez durante a comparação e outra para obter o valor de retorno. Se f () ou g () não for idempotente, isso poderá causar problemas. Por exemplo, se um deles for um contador que retorna um número diferente toda vez ...

É possível que esteja faltando uma especialização de modelo.

// 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);
}

Incompatibilidade binária, acessando um membro ou, pior ainda, chamando uma função da classe errada:

#pragma once

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

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

#endif

Uma função usa e está tudo bem:

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

Trazendo outra versão da classe:

#pragma once

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

class class_w
{
public: int a;
};

#endif

Usando funções em main, a segunda definição altera a definição da classe. Isso leva à incompatibilidade binária e simplesmente trava no tempo de execução. E corrija o problema removendo o primeiro include em 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;
}

Nenhuma das variantes gera um erro de tempo de compilação ou link.

A situação vice-versa, adicionando um include, corrige a falha:

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

Essas situações são ainda mais difíceis ao corrigir erros em uma versão antiga do programa ou ao usar um objeto externo library / dll / shared. É por isso que às vezes devem ser seguidas as regras de compatibilidade com versões anteriores binárias.

Quero ressaltar que o problema também existe em C.

Você pode dizer ao compilador que uma função usa alguma convenção de chamada. Caso contrário, o compilador terá que adivinhar que usa o padrão, diferente do C ++, onde o compilador pode se recusar a compilá-lo.

Por exemplo,

main.c

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

foo.c

#include <stdio.h>

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

No Linux em x86-64, minha saída é

0

Se você omitir o protótipo aqui, o compilador assume que você possui

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

E a convenção para listas de argumentos não especificadas exige que floatdeve ser convertido doublepara ser aprovado. Então, embora eu tenha dado 1.0f, o compilador o converte 1.0dpara passar para foo. E de acordo com o Suplemento de processador de arquitetura AMD64 da interface binária de aplicativos do System V, as doublefalhas são passadas nos 64 bits menos significativos de xmm0. Mas fooespera um float e o lê dos 32 bits menos significativos de xmm0, e obtém 0.