私は、algorithm
、memory
、string
などのC++標準ライブラリがいくつかの操作を実行するためにWindows APIヘッダーを使用すると判断された人と議論しています。C++標準ライブラリには、プラットフォームごとにネイティブヘッダーが含まれていますか?
このケースは正しくありませんか? すべてのWindows PEにWinAPIのネイティブDLLが含まれていることを理解していますが、標準ライブラリがすべてのコンパイラ/ OSに依存しているかどうかはわかりません。
私は、algorithm
、memory
、string
などのC++標準ライブラリがいくつかの操作を実行するためにWindows APIヘッダーを使用すると判断された人と議論しています。C++標準ライブラリには、プラットフォームごとにネイティブヘッダーが含まれていますか?
このケースは正しくありませんか? すべてのWindows PEにWinAPIのネイティブDLLが含まれていることを理解していますが、標準ライブラリがすべてのコンパイラ/ OSに依存しているかどうかはわかりません。
C++標準ライブラリは、C++プログラムに挿入されたときに標準で定義された効果を持つ#include <>
ディレクティブのセットです。
技術的には、ファイルである必要は全くありません。標準で指示されている#include <blah>
ディレクティブは、ディレクティブの後にプログラムの動作を変更するコンパイラ組み込み関数とすることもできます。
実際には、純粋なC++ヘッダーファイルコード、コンパイラ組み込み関数またはプラットフォーム固有の詳細を使用するヘッダーファイルコード、およびライブラリがOS固有のハードウェア固有のコードと、特定の、またはC/C + +で。
C++で実装できない部分がC++標準ライブラリにあります。
しかし、標準ライブラリのヘッダファイルは明示的に#include
@ CRTはいくつかの魔法の弾丸ではありません。それがコンパイルされたOSを回避します。ある時点で、CRTはOS固有の機能(メモリ管理、ファイルアクセス、例外処理など)を使用する必要があります。特定の実装からのC++ライブラリ 'ファイル'に* Windows.h *が含まれているかどうかは、まったく興味深いものではありません。 CRTと(または)C++標準ライブラリは、ある時点でコンパイラ/ OS固有です。 – IInspectable
@IInspectable: 'windows.h'は、ユーザのコードと衝突する可能性のあるたくさんのものを定義しているので、あまり面白くありません。私は実際には、明白な理由から、これを禁止する標準が期待されます。 (明らかに、ライブラリ自体のソースコードは 'windows.h'を使わなければなりませんが、標準のインクルードファイルと同じではありません) –
短い答え:はい、標準ライブラリでは、プラットフォーム固有のヘッダーを使用できます(そして使用します)。
長い回答: ユーザーに公開されるインターフェイスはプラットフォーム間で同じですが、実装ではプラットフォーム+コンパイラ固有の機能が使用される場合があります。
あなたのコンパイラのincludeディレクトリを検索し、例えば、最新のVisual Studioは、ここでは(デフォルトでは)次のとおりです。
C:\プログラムファイル(x86の)\のMicrosoft Visual Studioの14.0 \ VC \はに
ゴーが含まコマンドラインと上でこのディレクトリには、実行します。私のマシン上で
findstr -s -n -i -l "<windows.h>" *
、この出力:
delayhlp.cpp:25:#include <windows.h>
msclr\marshal.h:20:#include <windows.h>
msclr\marshal_windows.h:18:#include <windows.h>
vccorlib.h:34:#include <windows.h>
vsgcapture.h:4:#include <Windows.h>
そうです。windows.hは複数の実装ファイルに含まれています。コメントへの応答で
編集:Visual Studioでファイル "スレッド" を調べる
がディレクトリのstdの実装を明らかに含ま::スレッド::結合です:
inline void thread::join()
{ // join thread
if (!joinable())
_Throw_Cpp_error(_INVALID_ARGUMENT);
if (_Thr_is_null(_Thr))
_Throw_Cpp_error(_INVALID_ARGUMENT);
if (get_id() == _STD this_thread::get_id())
_Throw_Cpp_error(_RESOURCE_DEADLOCK_WOULD_OCCUR);
if (_Thrd_join(_Thr, 0) != _Thrd_success)
_Throw_Cpp_error(_NO_SUCH_PROCESS);
_Thr_set_null(_Thr);
}
さまざまな_Thrd_XXX
関数は、
cthread.c
に定義されています例えば210
は、_Thrd_joinは次のとおりです。WaitForSingleObjectEx
など、さまざまなWindows API関数を使用しています
int _Thrd_join(_Thrd_t thr, int *code)
{ /* return exit code when thread terminates */
unsigned long res;
if (WaitForSingleObjectEx(thr._Hnd, INFINITE, FALSE) == WAIT_FAILED
|| GetExitCodeThread(thr._Hnd, &res) == 0)
return (_Thrd_error);
if (code)
*code = (int)res;
return (CloseHandle(thr._Hnd) == 0 ? _Thrd_error : _Thrd_success);
}
は、だから、思われる「WINDOWS.Hは、」標準libaryヘッダのユーザーには見えないですが、それこれらの機能の実装に使用されます。
実装ファイル(cthread.cなど)には、同じディレクトリ内のファイル "wrapwin.h"を介して "windows.h"が含まれていることに注意してください。ファイル内のコメントに従って、コンパイラの警告を抑制します"windows.h"
Visual StudioコンパイラのようなWindowsコンパイラ関連のものだけではありませんか?これらのファイルは、C++ STLではなくCLRの一部のように見えます – oldjohn1994
これらの実装ファイルはどれも、標準ヘッダーには含まれていません。:) – melak47
また、ucrtもWindows.hまたはWinuserのようです。 hが含まれます。 – melak47
標準ライブラリはコンパイラ/ OSに依存することができます。たとえば、コンパイラ固有の拡張機能を利用することがよくあります。 –
@RaymondChen私は、標準ライブラリがWindows APIを使用する必要がある理由を考えることはできません。フードの下では、確かにWindows用の実装は、WinAPIを使用する領域にCを使用することができます。標準ライブラリのWinAPIや* nixライブラリの使用例は考えられません。 – oldjohn1994
@struction:Windows上のC++例外は、SEH例外の上にモデル化されています。それらはコンパイラ拡張とCRTの混合を使用して実装されています。これは、C++標準ライブラリ(またはCRT)がOS固有の実装を使用する必要がある理由の何千もの理由のほんの一**です。 CRTはWindows APIの上に実装されているということは、あなたがあまり理解していないようです。その逆ではありません。 – IInspectable