Czy brak elementu #include może spowodować uszkodzenie programu w czasie wykonywania?

Czy jest jakikolwiek przypadek, w którym pominięcie a #includespowodowałoby uszkodzenie oprogramowania w czasie wykonywania, podczas gdy kompilacja wciąż trwa?

Innymi słowy, czy to możliwe?

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

i

complexLogic();
cleverAlgorithms();

czy oba będą się pomyślnie budować, ale zachowają się inaczej?

Tak, jest to całkowicie możliwe. Jestem pewien, że jest wiele sposobów, ale załóżmy, że plik dołączania zawierał definicję zmiennej globalnej, która nazywała się konstruktorem. W pierwszym przypadku konstruktor wykonałby, a w drugim nie.

Umieszczenie definicji zmiennej globalnej w pliku nagłówkowym jest złym stylem, ale jest możliwe.

Tak, to możliwe.

Wszystko, co dotyczy #includes, dzieje się w czasie kompilacji. Ale czas kompilacji może oczywiście zmienić zachowanie w czasie wykonywania:

some/code.h:

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

następnie

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

Dzięki rozwiązaniu #includeprzeciążanie jest bardziej odpowiednie foo(int)i dlatego drukuje 1zamiast 2. Ponadto, ponieważ FOOjest zdefiniowany, dodatkowo drukuje FOO.

To tylko dwa (niepowiązane) przykłady, które od razu przyszły mi do głowy i jestem pewien, że jest o wiele więcej.

Aby wskazać trywialny przypadek, dyrektywy prekompilatora:

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

I wtedy

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

Być może jest to patologiczne, ale zdarzył się podobny przypadek:

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

using namespace std;

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

Wygląda niewinnie. Próbuje zadzwonić std::max. Jednak windows.h definiuje max

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

Gdyby tak było std::max, byłoby to normalne wywołanie funkcji, które ocenia f () raz g () raz. Ale z Windows.h tam teraz ocenia dwa razy f () lub g (): raz podczas porównania i raz, aby uzyskać wartość zwracaną. Jeśli f () lub g () nie były idempotentne, może to powodować problemy. Na przykład, jeśli jeden z nich jest licznikiem, który za każdym razem zwraca inną liczbę ...

Możliwe jest brak specjalizacji szablonu.

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

Niekompatybilność binarna, dostęp do członka lub jeszcze gorzej, wywołanie funkcji niewłaściwej klasy:

#pragma once

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

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

#endif

Funkcja go używa i jest w porządku:

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

Wprowadzanie innej wersji klasy:

#pragma once

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

class class_w
{
public: int a;
};

#endif

Używając funkcji main, druga definicja zmienia definicję klasy. Prowadzi to do binarnej niezgodności i po prostu ulega awarii w czasie wykonywania. I napraw ten problem, usuwając pierwszy plik include w 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;
}

Żaden z wariantów nie generuje błędu czasu kompilacji lub łącza.

Odwrotna sytuacja, dodanie parametru include naprawia awarię:

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

Sytuacje te są jeszcze trudniejsze, gdy naprawia się błąd w starej wersji programu lub używa zewnętrznej biblioteki / dll / współdzielonego obiektu. Dlatego czasami należy przestrzegać zasad binarnej kompatybilności wstecznej.

Chcę podkreślić, że problem istnieje również w C.

Możesz powiedzieć kompilatorowi, że funkcja korzysta z konwencji wywoływania. Jeśli tego nie zrobisz, kompilator będzie musiał zgadywać, że używa domyślnego, inaczej niż w C ++, gdzie kompilator może odmówić jego skompilowania.

Na przykład,

main.c

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

foo.c

#include <stdio.h>

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

W systemie Linux na platformie x86-64 moje dane wyjściowe to

0

Jeśli pominiesz tutaj prototyp, kompilator zakłada, że ​​masz

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

Konwencja dotycząca nieokreślonych list argumentów wymaga floatprzekonwertowania na doubleprzesłaną. Więc chociaż dałem 1.0f, kompilator konwertuje go, 1.0daby przekazać foo. I zgodnie z Suplementem do Procesora architektury B64 interfejsu systemu V w aplikacji V, doubledostaje się w 64 najmniej znaczących bitach xmm0. Ale foooczekuje liczby zmiennoprzecinkowej i odczytuje ją z 32 najmniej znaczących bitów xmm0, i otrzymuje 0.