Apakah mungkin #include yang hilang untuk menghentikan program saat runtime?

Apakah ada kasus, di mana yang hilang #includeakan merusak perangkat lunak saat runtime, sementara build masih berjalan?

Dengan kata lain, mungkinkah itu

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

dan

complexLogic();
cleverAlgorithms();

akan sama-sama membangun dengan sukses, tetapi berperilaku berbeda?

Ya, sangat mungkin. Saya yakin ada banyak cara, tetapi anggaplah file include berisi definisi variabel global yang disebut konstruktor. Dalam kasus pertama, konstruktor akan mengeksekusi, dan yang kedua tidak.

Menempatkan definisi variabel global dalam file header adalah gaya yang buruk, tetapi itu mungkin.

Ya itu mungkin.

Segala sesuatu yang berkaitan #includeterjadi pada waktu kompilasi. Tetapi kompilasi waktu hal-hal dapat mengubah perilaku saat runtime, tentu saja:

some/code.h:

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

kemudian

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

Dengan #include, resolusi kelebihan menemukan yang lebih tepat foo(int)dan karenanya mencetak 1daripada 2. Juga, sejak FOOdidefinisikan, ia juga mencetak FOO.

Itu hanya dua contoh (tidak berhubungan) yang langsung muncul di benak saya, dan saya yakin ada banyak lagi.

Hanya untuk menunjukkan kasus sepele, arahan precompiler:

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

Lalu

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

Ini patologis, mungkin, tapi saya punya kasus terkait terjadi:

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

using namespace std;

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

Terlihat tidak berbahaya. Mencoba menelepon std::max. Namun, windows.h mendefinisikan max menjadi

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

Jika ini std::max, ini akan menjadi panggilan fungsi normal yang mengevaluasi f () sekali dan g () sekali. Tetapi dengan windows.h di sana, sekarang mengevaluasi f () atau g () dua kali: sekali selama perbandingan dan sekali untuk mendapatkan nilai kembali. Jika f () atau g () tidak idempoten, ini dapat menyebabkan masalah. Misalnya, jika salah satu dari mereka kebetulan adalah penghitung yang mengembalikan nomor yang berbeda setiap kali ....

Mungkin saja ada spesialisasi template yang hilang.

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

Ketidakcocokan biner, mengakses anggota atau bahkan lebih buruk, memanggil fungsi dari kelas yang salah:

#pragma once

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

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

#endif

Sebuah fungsi menggunakannya, dan tidak apa-apa:

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

Membawa versi lain dari kelas:

#pragma once

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

class class_w
{
public: int a;
};

#endif

Menggunakan fungsi di main, definisi kedua mengubah definisi kelas. Ini menyebabkan ketidakcocokan biner dan hanya crash saat runtime. Dan perbaiki masalah dengan menghapus menyertakan pertama di 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;
}

Tidak ada varian yang menghasilkan kesalahan waktu kompilasi atau tautan.

Situasi sebaliknya, menambahkan sertakan perbaikan kerusakan:

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

Situasi ini bahkan jauh lebih sulit ketika memperbaiki bug di versi program lama, atau menggunakan perpustakaan eksternal / dll / objek bersama. Itu sebabnya kadang-kadang harus diikuti aturan kompatibilitas mundur biner.

Saya ingin menunjukkan bahwa masalahnya juga ada di C.

Anda dapat memberi tahu kompiler bahwa suatu fungsi menggunakan beberapa konvensi pemanggilan. Jika tidak, kompiler harus menebak bahwa ia menggunakan yang default, tidak seperti di C ++ di mana kompiler dapat menolak untuk mengkompilasinya.

Sebagai contoh,

main.c

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

foo.c

#include <stdio.h>

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

Di Linux pada x86-64, output saya adalah

0

Jika Anda menghilangkan prototipe di sini, kompilator mengasumsikan Anda memilikinya

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

Dan konvensi untuk daftar argumen yang tidak ditentukan mensyaratkan bahwa floatharus dikonversi doubleagar dapat disahkan. Jadi walaupun saya berikan 1.0f, kompiler mengkonversinya 1.0duntuk meneruskannya foo. Dan menurut System V Application Binary Interface, Tambahan Prosesor Arsitektur AMD64, doubleakan dilewatkan dalam 64 bit paling tidak signifikan xmm0. Tetapi foomengharapkan float, dan membacanya dari 32 bit paling tidak signifikan xmm0, dan mendapat 0.