- 締切済み
string.h内でエラー
Visual C++ 2005でプログラムを組んでいます。 あるプログラムをビルドすると以下のようにstring.h内でエラーが大量に発生します。string.hをインクルードしないとエラーは出ないことからおそらくstring.hまわりの設定がおかしいとは思うのですがよくわかりません。 エラー 2 error C2144: 構文エラー : 'char' は ')' によって先行されなければなりません。c:\program files\microsoft visual studio 8\vc\include\string.h 136 エラー 3 error C2144: 構文エラー : 'char' は ';' によって先行されなければなりません。c:\program files\microsoft visual studio 8\vc\include\string.h 136 エラー 5 error C2143: 構文エラー : ';' が ',' の前にありません。c:\program files \ microsoftvisualstudio8 \ vc\ include\ string.h 136 宜しくお願いします。
- みんなの回答 (6)
- 専門家の回答
みんなの回答
- ricardo_
- ベストアンサー率19% (14/72)
"string.h" を編集しませんでしたか。 単に内容を見るつもりやコメントを挿入するつもりが、書き換えてしまったのではないですか。 知らない間に全角スペースが入っているというミスも見つけ難い。
- Tacosan
- ベストアンサー率23% (3656/15482)
「コンパイルできない」って言われてもなぁ. せめてエラーメッセージ (できれば最初の方のやつ) が分かんないと.... 最終的にはプリプロセッサにかけて得られた結果を眺めてみるのか?
補足
回答ありがとうございます。 エラーメッセージは最初の質問で書かせて頂いております。 よろしければ見てください。
- asuncion
- ベストアンサー率33% (2127/6289)
メッセージでは、string.h の 136行目でエラーが出ていると言っていますね。 その行だけを見ても原因がわからないかもしれません。 そこで、120行目~140行目あたりを載せていただけますか? また、string.h のタイムスタンプはどうなっていますか? 他のヘッダーファイルとの違いはありますか? # (一部とはいえ)製品の内容をこういう場所に載せるのは、著作権か何かに引っかかるのでしょうか。>識者のかたがた
補足
string.hのタイムスタンプは '2006/12/01' でstdio.h, stdlib.hなどと同じです。 #if __STDC_WANT_SECURE_LIB__ _CRTIMP __checkReturn_wat errno_t __cdecl strerror_s(__out_ecount_z(_SizeInBytes) char * _Buf, __in size_t _SizeInBytes, __in int _ErrNum); #endif __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_1(errno_t, strerror_s, __out_ecount(_Size) char, _Buffer, __in int, _ErrorMessage) _CRTIMP __checkReturn_wat errno_t __cdecl _strlwr_s(__inout_ecount_z(_Size) char * _Str, __in size_t _Size); __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_0(errno_t, _strlwr_s, __inout_ecount_z(_Size) char, _String) __DEFINE_CPP_OVERLOAD_STANDARD_FUNC_0_0(char *, __RETURN_POLICY_DST, _CRTIMP, _strlwr, __inout_z char, _String) _CRTIMP __checkReturn_wat errno_t __cdecl _strlwr_s_l(__inout_ecount_z(_Size) char * _Str, __in size_t _Size, __in_opt _locale_t _Locale); __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_1(errno_t, _strlwr_s_l, __inout_ecount_z(_Size) char, _String, __in_opt _locale_t, _Locale) 【136行目】__DEFINE_CPP_OVERLOAD_STANDARD_FUNC_0_1_EX(char *, __RETURN_POLICY_DST, _CRTIMP, _strlwr_l, _strlwr_s_l, __inout_ecount_z(_Size) char, __inout_z char, _String, __in_opt _locale_t, _Locale) #if __STDC_WANT_SECURE_LIB__ _CRTIMP_ALTERNATIVE __checkReturn_wat errno_t __cdecl strncat_s(__inout_ecount_z(_DstSize) char * _Dst, __in rsize_t _DstSize, __in_z const char * _Src, __in rsize_t _MaxCount); #endif __DEFINE_CPP_OVERLOAD_SECURE_FUNC_0_2(errno_t, strncat_s, __inout_ecount_z(_Size) char, _Dest, __in_z const char *, _Source, __in size_t, _Count) #pragma warning(push) #pragma warning(disable:6059) /* prefast noise VSW 489802 */ __DEFINE_CPP_OVERLOAD_STANDARD_NFUNC_0_2_EX(char *, __RETURN_POLICY_DST, _CRTIMP, strncat, strncat_s, __inout_z char, __inout_ecount_z(_Count) char, _Dest, __in_z const char *, _Source, __in size_t, _Count) #pragma warning(pop) お手数おかけします。
- Tacosan
- ベストアンサー率23% (3656/15482)
とりあえず #include <string.h> だけからなるソースコードはコンパイルできますか? これがコンパイルできるなら string.h の問題ではなくあなたの作ったプログラムの問題といえるでしょう.
補足
回答ありがとうございます。 #include <string.h>だけのコードはコンパイルできません。 数日前までは問題なくコンパイルできたのですが。環境が変わったとしか思えないです。思い当たるのはスパイウェアソフトでスキャンをかけて見つかったものを駆除したぐらいです。 string.hファイルを入れなおしたほうがいいのでしょうか?
- asuncion
- ベストアンサー率33% (2127/6289)
もし、本当にstring.hの中にエラーの原因があるとします。 そうすると、質問者さんのところだけでなく、他の人のところでも 同じようなエラーが起こることが考えられるでしょう。 そうなると、世間が黙っていませんよね。 マイクロソフトの信用に関わる話ともなります。 ところが、実際はそうなっていませんね。 ということは、「string.hに原因がある」という仮説が誤っていることになります。 おそらく、質問者さんが書かれたコードに何か正しくない箇所があるのでしょう。
補足
数日前まではstring.hを利用したソースはコンパイルできていました。 string.hに問題があるのではなく、数日の間で自分のPCでなにか問題が起きたと思っています。ソースは以下になります。 #include <stdio.h> #include <string.h> int main(void) { int st; st = strcmp("abced", "abcce"); printf("st = %d\n", st); return 0; }
それをインクルードするまえにコンパイルしようとしているソースファイルを良くみて、"("を閉じてないとか、”だけしかないとか。よおーく見直してみましたか?
補足
#include <stdio.h> #include <string.h> ソースは以下のような簡単なものですが、なにか間違いありますでしょうか? #include <stdio.h> #include <string.h> int main(void) { int st; st = strcmp("abced", "abcce"); printf("st = %d\n", st); return 0; }
補足
回答ありがとうございます。 string.hのタイムスタンプが '2006/12/01'となっていますので書き換えた可能性はないと思います。