タグ付けされた質問 「c」

Cは、システムプログラミング(OSおよび組み込み)、ライブラリ、ゲーム、クロスプラットフォームに使用される汎用プログラミング言語です。このタグは、ISO 9899標準で定義されているC言語に関する一般的な質問で使用する必要があります(特に指定のない限り、最新バージョン9899:2018。バージョン固有のリクエストには、c89、c99、c11などのタグも付けます)。CはC ++とは異なり、合理的な理由がない限り、C ++タグと組み合わせるべきではありません。

11
整数の最大値
Cでは、整数(32ビットマシンの場合)は32ビットで、範囲は-32,768〜+32,767です。Javaでは、integer(long)も32ビットですが、範囲は-2,147,483,648から+2,147,483,647です。 ビット数が同じでも、Javaで範囲がどのように異なるかわかりません。誰かがこれを説明できますか?
291 java  c  integer  max  bit 

19
C / C ++で余分な#includeを検出していますか?
ファイルのヘッダーセクションが常に大きくなるのに、小さくならないことがよくあります。ソースファイルの存続期間を通じて、クラスは移動してリファクタリングされている可能性があり、そこに存在する#includes必要のないものも少なくない可能性があります。それらをそこに残すと、コンパイル時間が長くなり、不要なコンパイル依存関係が追加されます。どれがまだ必要かを理解しようとするのは、かなり退屈な作業です。 不要な#includeディレクティブを検出して、安全に削除できるものを提案できるツールはありますか? リントは多分これをしますか?

19
Cのシフト演算子を使用した乗算と除算は実際には高速ですか?
乗算と除算は、ビット演算子を使用して実現できます。 i*2 = i<<1 i*3 = (i<<1) + i; i*10 = (i<<3) + (i<<1) 等々。 直接(i<<3)+(i<<1)使用i*10するよりも、sayを使用して10を乗算する方が実際に高速ですか?この方法で乗算または除算できない入力の種類はありますか?


10
C / C ++インクルードヘッダーファイルの順序
どのような順序でファイルを指定する必要がありますか。つまり、あるヘッダーを別のヘッダーの前に含める理由は何ですか。 たとえば、システムファイル、STL、およびBoostはローカルインクルードファイルの前または後にありますか?
287 c++  c 

8
glibcのstrlenをすばやく実行するには、なぜ複雑にする必要があるのですか?
ここでstrlenコードを調べていて、コードで使用されている最適化が本当に必要かどうか疑問に思っていましたか?たとえば、次のようなものが同等以上に機能しないのはなぜですか? unsigned long strlen(char s[]) { unsigned long i; for (i = 0; s[i] != '\0'; i++) continue; return i; } より単純なコードは、コンパイラーが最適化するのに優れていたり、簡単だったりしませんか? strlenリンクの背後にあるページのコードは次のようになります。 /* Copyright (C) 1991, 1993, 1997, 2000, 2003 Free Software Foundation, Inc. This file is part of the GNU C Library. Written by Torbjorn Granlund (tege@sics.se), with …

17
「char s []」ではなく、文字列リテラルで初期化された「char * s」に書き込むときに、セグメンテーション違反が発生するのはなぜですか?
次のコードは、2行目でsegフォルトを受け取ります。 char *str = "string"; str[0] = 'z'; // could be also written as *str = 'z' printf("%s\n", str); これは完璧に機能しますが、 char str[] = "string"; str[0] = 'z'; printf("%s\n", str); MSVCおよびGCCでテスト済み。

20
Android用のCまたはC ++でアプリケーションを作成しますか?[閉まっている]
現在のところ、この質問はQ&A形式には適していません。私たちは回答が事実、参考文献、または専門知識によってサポートされることを期待しますが、この質問はおそらく議論、議論、投票、または拡張された議論を誘います。この質問を改善でき、再開できると思われる場合は、ヘルプセンターにアクセスしてください。 8年前に閉鎖。 ゲームを開発/ Androidに移植しようとしていますが、それはCで行われ、AndroidはJavaをサポートしていますが、Cアプリをそこにインストールする方法があるはずだと確信しています。これを達成する方法を知っている人はいますか?
286 c++  c  android 

12
PythonでのCライブラリのラッピング:C、Cythonまたはctypes?
PythonアプリケーションからCライブラリを呼び出したいのですが。API全体をラップするのではなく、自分のケースに関連する関数とデータ型のみをラップします。それを見ると、私は3つの選択肢があります。 Cで実際の拡張モジュールを作成します。おそらくやり過ぎです。また、拡張の記述を学習するオーバーヘッドを回避したいと思います。 Cythonを使用して、CライブラリからPythonに関連パーツを公開します。 Pythonですべてをctypes行い、外部ライブラリとの通信に使用します。 2)と3)のどちらが良い選択かわかりません。3)の利点は、それctypesが標準ライブラリの一部であり、結果のコードが純粋なPythonになることです。ただし、その利点が実際にどれほど大きいかはわかりません。 どちらを選択しても、長所/短所はありますか?どちらのアプローチをお勧めしますか? 編集:すべての回答に感謝します。同様のことをしたいと考えているすべての人に役立つリソースを提供します。もちろん、決定はまだ1つのケースに対して行われることになっています。「これは正しいことです」という種類の答えはありません。私自身のケースでは、おそらくctypesを使用しますが、他のプロジェクトでCythonを試すことも楽しみにしています。 正解は1つではないため、1つを受け入れることはいくぶん恣意的です。私はFogleBirdの回答を選択しました。これはctypesに対するいくつかの優れた洞察を提供し、現在、最も投票された回答でもあるからです。ただし、概要を理解するためにすべての回答を読むことをお勧めします。 再度、感謝します。
284 python  c  ctypes  cython 

18
nullで終了する文字列の根拠は何ですか?
私はCとC ++が大好きですが、ヌル終了文字列の選択に頭を悩まさずにはいられません。 Cの前に存在する長さの接頭辞付きの(つまりPascal)文字列 長さの接頭辞付き文字列は、一定時間の長さのルックアップを可能にすることにより、いくつかのアルゴリズムを高速化します。 長さの接頭辞付き文字列により、バッファオーバーランエラーが発生しにくくなります。 32ビットマシンでも、文字列が使用可能なメモリのサイズになるようにすると、長さの接頭辞付き文字列は、ヌル終了文字列よりも3バイトだけ広くなります。16ビットマシンでは、これは1バイトです。64ビットマシンでは、4GBが適切な文字列長の制限ですが、それをマシンワードのサイズに拡張したい場合でも、64ビットマシンは通常、十分なメモリを備えており、余分な7バイトのnull引数になります。元のC標準がめちゃくちゃ貧弱なマシン(メモリの観点から)向けに作成されたのは知っていますが、効率性の問題でここでは売れません。 他のほとんどすべての言語(Perl、Pascal、Python、Java、C#など)は、長さの接頭辞付き文字列を使用します。これらの言語は文字列の方が効率的であるため、通常、文字列操作のベンチマークでCに勝っています。 C ++はこれをstd::basic_stringテンプレートで少し修正しましたが、nullで終了する文字列を期待するプレーンな文字配列はまだ普及しています。ヒープの割り当てが必要なため、これも不完全です。 nullで終了する文字列は、文字列に存在できない文字(つまりnull)を予約する必要がありますが、長さの接頭辞付きの文字列には埋め込みnullを含めることができます。 これらの事柄のいくつかはCよりも最近明らかになったので、Cがそれらを知らなかったのは理にかなっています。しかし、Cが登場する前に、いくつかは明白でした。明らかに優れた長さの接頭辞の代わりにnullで終了する文字列が選択されたのはなぜですか? 編集:一部の人は上記の私の効率の点で事実を尋ねました(そして私がすでに提供したものを好きではありませんでした)ので、それらはいくつかのことに由来します: nullで終了する文字列を使用した連結では、O(n + m)時間の複雑さが必要です。多くの場合、長さの接頭辞にはO(m)のみが必要です。 nullで終了する文字列を使用する長さには、O(n)時間の複雑さが必要です。長さの接頭辞はO(1)です。 長さと連結は、最も一般的な文字列操作です。nullで終了する文字列の方が効率的である場合がいくつかありますが、これらはそれほど頻繁には発生しません。 以下の回答から、これらはnullで終了する文字列がより効率的ないくつかのケースです: 文字列の先頭を切り取って、いくつかのメソッドに渡す必要がある場合。元の文字列を破棄することが許可されている場合でも、長さの接頭辞を使用して一定の時間でこれを実際に行うことはできません。長さの接頭辞はおそらく整列規則に従う必要があるためです。 文字列を1文字ずつループしている場合は、CPUレジスタを保存できる場合があります。これは、文字列を動的に割り当てていない場合にのみ機能することに注意してください(その後、文字列を解放する必要があるため、保存したCPUレジスタを使用して、最初にmallocや友人から取得したポインターを保持する必要があります)。 上記のどれも、長さと連結ほど一般的ではありません。 以下の回答にはもう1つ主張があります。 あなたは文字列の終わりを切り取る必要があります しかし、これは正しくありません。nullで終了し、長さの接頭辞が付いた文字列と同じ時間です。(nullで終了する文字列は、新しい終了位置にしたい場所にnullを貼り付け、長さのプリフィックスはプレフィックスから減算するだけです。)
281 c++  c  string  null-terminated 

4
むかしむかしに>が<よりも速いとき…ちょっと待って、何?
私は読んでいます 素晴らしいOpenGLチュートリアルをいます。それは本当に素晴らしいです、私を信頼してください。私が現在取り組んでいるトピックはZバッファです。それが何であるかを説明するだけでなく、著者は、GL_LESS、GL_ALWAYSなどのカスタム深度テストを実行できることを述べています。深度値の実際の意味(上と下ではない)も可能であることも説明しています。カスタマイズ。私はこれまで理解しました。そして、著者は信じられないようなことを言っています: 範囲zNearは、範囲zFarより大きくすることができます。そうである場合、ウィンドウ空間の値は、ビューアから最も近いまたは最も遠いものを構成するものに関して逆になります。 以前は、ウィンドウ空間のZ値0が最も近く、1が最も遠いと言われていました。ただし、クリップ空間のZ値を無効にすると、深度1はビューに最も近く、深度0は最も遠くなります。ただし、深度テストの方向を逆にしても(GL_LESSからGL_GREATERなど)、まったく同じ結果が得られます。だから、それは本当に単なる慣習です。実際、Zの符号と深度テストを反転させることは、かつて多くのゲームにとって重要なパフォーマンス最適化でした。 私が正しく理解していれば、パフォーマンスに関して、Zの符号と深度テストを反転させることは、&lt;比較を比較に変更することに他なりません&gt;。だから、私が正しく理解していて、作者が嘘をついていたり、物事を構成していなかったりした場合は、重要な最適化に変更&lt;する&gt;、多くのゲームでした。 著者は、物事を作っている私が何かを誤解していますか、それはかつての場合、確かである&lt;(遅かった極めてよりも、著者が言うように、) &gt;? このかなり興味深い問題を明確にしてくれてありがとう! 免責事項:アルゴリズムの複雑さが最適化の主な原因であることを十分に承知しています。さらに、今日は間違いなく何の違いもないだろうと私は疑っています。これを最適化するように求めているわけではありません。私は非常に、苦痛に、おそらく法外に好奇心が強いのです。
280 c  optimization  opengl  cpu  gpu 



11
コアダンプされましたが、コアファイルは現在のディレクトリにありませんか?
Cプログラムの実行中に「(コアダンプ)」と表示されますが、現在のパスの下にファイルが表示されません。 私は設定して確認しましたulimit: ulimit -c unlimited ulimit -a 「core」という名前のファイルも見つけようとしましたが、コアダンプファイルを取得できませんでしたか? 私のコアファイルはどこにありますか?
277 c  linux  coredump 

6
ファイルアクセスにmmapを使用する必要があるのはいつですか?
POSIX環境では、少なくとも2つの方法でファイルにアクセスできます。標準のシステムコールがありますopen()、read()、write()、と友人は、しかし、使用するオプションもありますmmap()仮想メモリにファイルをマップするためには。 どちらを使用するのが望ましいですか?2つのインターフェースを含めることのメリットは何ですか?
276 c  file-io  posix  mmap 

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.