23

私は特に陰湿なバグをデバッグしてきましたが、これは、さまざまなヘッダーが含まれている（または含まれていない）場合のさまざまな動作に起因する予期しない変更が原因であると考えられています。

これは私のコードの構造とは異なりますが、このシナリオを見てみましょう。

#include "Newly_created_header_which_accidentally_undefines_SOME_DEFINE.h"

// ...

#ifdef SOME_DEFINE
    code_which_i_believe_i_am_always_running();
#else 
    code_which_fails_which_i_have_forgotten_about(); // runtime error stack traces back here, but I don't know this... or maybe it's some strange linker error
#endif

私は自分のgitcommitを検索し、バグの原因を絞り込み、コードを数え切れないほどコンパイルして実行しましたが、数時間後に、バグを引き起こすために必要な唯一の違いは、完全に無害であると思われるものを含めることであることがわかりました。無関係なヘッダー。

おそらくこれは、プリプロセッサが基本的に単にダメな理由についての素晴らしい議論です。

しかし私はそれが好きです。プリプロセッサは、ショートカットを作成できるのでかっこいいです。これらのショートカットのいくつかは、注意深く使用しないと、かなり激しく噛み付くだけです。

したがって、この時点で、コンパイル中に#echo "Running old crashy code"これを確認できるようなディレクティブを使用できれば、SOME_DEFINEが定義されていない理由の調査をすぐに開始できるようになります。

私の知る限り、SOME_DEFINEが定義されているかどうかを判断する簡単な方法は、次のようなことを行うことです。

#ifndef SOME_DEFINE
    printf("SOME_DEFINE not defined!!\n");

これで確実に作業が完了しますが、コンパイル時に完全に決定されるため、このタスクを実行時に実行する理由はありません。これは、コンパイル時に見たいものです。

そうは言っても、この状況では、疑わしいコードの速度を落としたり乱雑にしたりすることはあまり気にしないので、印刷を使用する（またはログを記録する、あるいは例外をスローする）ことは許容できることかもしれません。しかし、たとえば2つのコードパスがあり、どちらも重要であり、コンパイル時にどちらがアクティブ化されているかを知りたい場合は、これは当てはまりません。プログラムの最初にプリプロセッサで調整された印刷を行うコードを実行することを心配する必要があります。

これは、「プリプロセッサディレクティブを使用して、コンパイル中に文字列を出力にエコーすることはできますか？」という質問をするための非常に長い方法です。

4

2 に答える 2

23

ディレクティブを使用する#errorと、出力が直接出力され、コンパイルが停止します。

$ make days_in_month
cc     days_in_month.c   -o days_in_month
days_in_month.c:2:2: error: #error "ugly!"
make: *** [days_in_month] Error 1
$

これはあなたが望んでいたことではないかもしれませんが、それは仕事を素早く終わらせます。

$ cat days_in_month.c
#include <stdio.h>
#error "ugly!"
...

処理を続行する場合は、次を使用できます#warning。

$ make days_in_month
cc     days_in_month.c   -o days_in_month
days_in_month.c:2:2: warning: #warning "ugly!" [-Wcpp]

$ head days_in_month.c 
#include <stdio.h>
#warning "ugly!"
于 2012-06-26T23:01:26.353 に答える
4

私が探していたものに沿ってもっと答えるのはここにあります：https ：//stackoverflow.com/a/3826876/340947

申し訳ありませんが@sarnold

于 2012-07-01T03:27:42.303 に答える