問題タブ [libc++]

静的分析機能のために、clangを試してみることに興味があります。私は現在、ubuntu11.04で実行されているc++のプロジェクトに取り組んでいます。clangの問題の1つは、パッチを適用しない限り、libstdc++4.4では機能しないことです。clangへの一時的な侵入となる可能性があるため、libstdc++ソースをいじりたくありません。

別の方法は、libstdc++の代わりにlibc++を使用することです。残念ながら、CMakeの代替STL実装を使用するためのヘルプをオンラインで見つけることができませんでした。

CMakeにlibc++を使用するように指示するには、CMakeLists.txtファイルに何を書き込みますか？

驚くほど少しハッキングした後、Linuxボックスにlibc ++をインストールすることができました（libstdc ++には不足しているものがあるため）。残念ながら、同じ名前の関数が原因で、既存のコードの一部が壊れています。

通常、そして私が必要とする方法で、bind（）はソケットに関連しています。ただし、libc ++には独自のbind（）関数が付属しています。これは基本的にこれですが、それらを分離するための便利な名前空間がありません。マーフィーの法則に従って、コンパイラは間違った関数を使用しようとし、エラーを吐き出します。NetBeansは、実際にはsys / socket.hファイルを検索しているため、問題は発生しません。

したがって、両方の関数が基本的に私の制御の範囲を超えている場合、コンパイラ（clang ++）に、特定のヘッダーを検索し、その関数の他の場所を検索しないように指示するにはどうすればよいですか？

clang と libc++ のコンパイル、実行、NetBeans との統合、さらには 32 ビット マシンへのクロスコンパイルまで相当な労力を費やした後、すべてを理解したと思いました。そこで、libstdc++ になかったいくつかの機能 (開発環境をひっくり返す理由) を使用し、発見しました...実際にはそれができません。

libc++ がインストールされ、動作し、コンパイルされたプログラム (動作する場合) がそれを必要とします。ただし、コンパイラは、名前空間をいじることによって、あらゆる機会に libstdc++ バージョンを使用しようとします。std::__1::map、std::__1::basic_stringなど。今、私はこの質問から、なぜそれが起こるのか、そしてなぜlibc ++がそれをするのかを知っています. 完全に適用できないため、それを消去する方法を知る必要があるだけです-私は本当に、本当にlibc ++バージョンを使用したいのですが、コードには2つのタイプが共存する必要があるものは何もありません.

libstdc++ フォルダーをインクルード パスから外そうとしましたが、失敗すると完全にアクセスできなくなりました。運がない。アドオン ライブラリは使用せず、組み込みの Linux/POSIX ヘッダー (errno、socket、syslog、fcntl) のみを使用しています。

編集:エラー メッセージ:

libstdc++ マップには emplace() がありません。libc++ バージョンは.

コマンドラインからの次の呼び出しは機能しているようです。

NetBeans 内からの呼び出しは、次のことを行いません。

次の (おもちゃの) プログラムは、libstdc++ と libc++ に対してリンクすると、異なるものを返します。これは libc++ のバグですか、それとも istream eof() の仕組みがわかりませんか? -std=c++0x の有無にかかわらず、Linux および mac os x で g++ を使用し、mac os x で clang を使用して実行しようとしました。(get() などによる) 読み取りの試行が実際に失敗するまで、eof() は true を返さないというのが私の印象でした。これは libstdc++ の動作ですが、libc++ の動作ではありません。

私はC++11を試したり、C ++ 11から実験しshared_ptrたりmake_sharedして、小さなおもちゃの例をプログラムして、を呼び出したときに実際に何が起こっているかを確認しましたmake_shared。インフラストラクチャとして、XCode4内のllvm stdc++ライブラリとともにllvm/clang3.0を使用していました。

次に、出力を見てください。

make_sharedを使用してsmart_ptrを作成します...

コンストラクタmake_shared

コンストラクターをコピーします。

コンストラクターをコピーします。

デストラクタ

デストラクタ

make_sharedを使用してsmart_ptrを作成します：done。

new...を使用してsmart_ptrを作成します。

新しいコンストラクタ

new：doneを使用してsmart_ptrを作成します。

デストラクタ

デストラクタ

make_sharedコピーコンストラクタを2回呼び出しているようです。Objectレギュラーを使用してメモリを割り当てる場合、newこれは発生せず、1つだけObjectが構築されます。

私が疑問に思っているのは次のとおりです。^{（1、2）を}make_shared使用するよりも効率的だと聞いてい^ます。1つの理由は、同じメモリブロックで管理されるオブジェクトと一緒に参照カウントを割り当てるためです。OK、要点はわかりました。もちろん、これは2つの個別の割り当て操作よりも効率的です。newmake_shared

それどころか、なぜこれがのコピーコンストラクターへの2回の呼び出しのコストを伴う必要があるのか​​理解できませんObject。このため、すべての場合に使用するmake_shared割り当てよりも効率的であるとは確信していません。私はここで間違っていますか？さて、1つはのための移動コンストラクターを実装することができますが、それでもこれが単にを割り当てるよりも効率的であるかどうかはわかりません。少なくともすべての場合ではありません。コピーが参照カウンターにメモリを割り当てるよりも安価である場合は、それが当てはまります。しかし、内部参照カウンターは、いくつかのプリミティブデータ型を使用して実装できますよね？newObjectObjectnewObjectshared_ptr

make_shared概説されたコピーのオーバーヘッドにもかかわらず、なぜ効率の観点から進むべきかを助け、説明できますか？

libcxxLLVM3.0とClang3.0を使用してUbuntu12.04でlibc++（）をコンパイルしようとすると、エラーが発生します

cxxabi.hはどこに置くべきですか？現在、以下の場所にあります

コマンドラインで渡された一連のロケールを使用して、wchar_t と char の間の変換をテストする簡単なプログラムがあります。ロケール名と変換に失敗した文字列を出力することで、失敗した変換のリストを出力します。

私はclangとlibc ++を使って構築しています。私の理解では、libc++ の名前付きロケール サポートは、OS X の xlocale ライブラリによって提供されます。

予期しないエラーが発生したり、変換が失敗するはずのインスタンスが発生したりしません。

これがプログラムです。

正しい出力の例をいくつか示します

予期しない出力の例を次に示します。

ユーロ文字は ISO 8859-15 文字セットに存在するため、これが失敗することはありません。

期待しているが受け取っていない出力の例を次に示します

これは、ISO 8859-1 に存在する通貨記号ですが、ISO 8859-15 では削除され、ユーロ記号に置き換えられました。この変換は成功しないはずですが、エラーは通知されていません。このケースをさらに調べると、両方のケースで「¤」が「¤」の ISO 8859-1 表現である 0xA4 に変換されていることがわかります。

xlocale を直接使用しているのではなく、libc++ を介して間接的に使用しています。Mac OS X の xlocale は単に悪いロケール定義で壊れているのですか? それを修正する方法はありますか？それとも、私が見ている問題は何か別の結果ですか?

Linux システムでは、実行時に呼び出しでプログラムを呼び出そうとしていsystem()ます。システム コールは、ゼロ以外のリターン コードで終了します。

エラーコードを呼び出すWEXITSTATUSと、「127」が返されます。

system の man ページによると、このコードは を/bin/sh呼び出すことができなかったことを示しています。

/bin/sh実行できなかった場合の終了ステータスは、 を実行したコマンドの終了ステータスになりますexit(127)。

確認しました:/bin/shへのリンクbashです。bashある。シェルから実行できます。

では、なぜ を呼び出せなかったのかを調べるにはどうすれ/bin/shばよいでしょうか? カーネルの歴史か何か？

編集：

非常に役立つヒント (以下を参照) の後strace -f -p <PID>、プロセスを進めます。これは私がsystem電話中に得たものです：

への呼び出しに/bin/shなると、アドレスが悪いと言われます。どうして ？

編集：

ここでは、失敗に関係する部分全体を示しますsystem(ここでは、バッファーへの安全なコピーが既に配置されています)。

出力：

編集 (コードの最初のバージョン):

文字列作成の複雑さは、ここでは問題ではありません。示されているようstraceに、「不正なアドレス」が問題です。正当な文字列です。「不良アドレス」は発生しないはずです。

私が知る限り、std::string::c_str()戻り値const char *は、文字列の読み取り専用コピーが保持される可能性のある libc++ のスクラッチ スペースを指す可能性があります。

残念ながら、エラーは実際には再現できません。への呼び出しはsystem、失敗する前に数回成功します。

焦りたくはありませんが、カーネル、libc、またはハードウェアのいずれかのバグのようなにおいがします。

編集：

失敗したシステム コールのより詳細なstrace出力 ( ) を作成しました。strace -f -v -s 2048 -e trace=process -p $!execve

最初の後続の呼び出し:

今失敗したもの：

ここ<list of vars>は同一です。不正なアドレスの原因となる環境変数のリストではないようです。Chris Dodd が述べたように、execve の 3 番目の引数は raw ポインター 0x14595af0 であり、strace はこれを無効と見なします (そしてカーネルは同意します)。straceはそれを文字列として認識しません (したがって、文字列ではなく 16 進値を出力します)。

編集：

cmd親プロセスでのこのポインターの値を確認するために、ポインター値の出力を挿入しました。

出力 (失敗した呼び出しの場合):

の 3 番目の引数と同じポインター値straceです。strace（上記の出力を更新しました）。

ポインターの 32 ビットの外観について:後続の呼び出しcmdのポインターの値を確認しました。cmd構造上の違いは見られません。これは、呼び出しが成功cmdしたときの値の 1 つです。system

したがって、system呼び出しの前にポインターは有効です。上記のstrace出力が示唆しているように、( を呼び出した後fork) 子プロセスは正しいポインター値を受け取ります。しかし、何らかの理由で、ポインター値は子プロセスで無効とマークされています。

現在、次のいずれかだと考えています。

• libc/カーネルのバグ
• ハードウェアの問題

編集：

その間、回避策を投稿させてください。そのようなものを実装することを余儀なくされるのはとてもばかげています...しかし、それは機能します。systemしたがって、呼び出しが失敗した場合に備えて、次のコード ブロックが実行されます。新しいコマンド文字列を割り当て、成功するまで再試行します (無期限ではありません)。

編集：

ある特定の実行でこの回避策が機能しないことがわかりました。1000回の試行で、すべてが新しく割り当てられたcmdコマンド文字列で行われました。1000 はすべて失敗しました。これだけではありません。別の Linux ホスト (同じ Linux/ソフトウェア構成) で試してみました。

これを考慮に入れると、ハードウェアの問題を除外できる可能性があります。(その場合、2 つの物理的に異なるホスト上にある必要があります)。カーネルのバグのまま??

編集：

torek、修正したsystem通話をインストールしてみます。そのために少し時間をください。

ImageMagick（特にMagick ++）をclang++とlibc++でコンパイルしようとしています。したがって、コンパイラとリンカの両方に-stdlib =libc++を渡す必要があります。

CXXFLAGS = "-stdlib = libc ++"はコンパイルには問題なく機能しますが、LDFLAGS = "-stdlib =libc++"はCリンカーにのみ影響するようです。

C ++ライブラリをリンクするときに./configureを正しく指示するか、このフラグを使用するようにするにはどうすればよいですか？

私が作成している iOS アプリケーションは、ZXing、Couchbase、Couchcocoa を使用しています。もともと必要だったのは libc++.dylib だけで、シミュレーターを使用してプログラムを実行できました。

デバイスで実行しようとすると、正常にビルドされますが、クラッシュしてログが表示されます。

次に、リンク バイナリ ライブラリに libc++.1.dylib を追加しました。そして、私はまだ同じログを取得します。