問題タブ [buffer]

Read() 関数を適切に実装する方法がわからない Stream クラスを継承したので、ネストされた if が多くなり、コードをデバッグするのが難しくなりません。ポイントは、このストリームのソースからの読み取りは一定サイズのバッファー (変更不可など) を返しますが、Read() 関数は異なるバッファー サイズを受け入れることです。私は BufferedStream を追加することを考えましたが、それは悪い考えだと思います。手伝ってくれてありがとう！

私は C# 非同期ソケット プログラミングを学んでおり、バイト バッファーをある種のプールで再利用し、ソケットからデータを受信するときに必要に応じてチェックアウトすることをお勧めします。

ただし、バイト配列プールを実行する 2 つの異なる方法を見てきました。1 つは単純なキュー システムを使用し、必要に応じてキューに追加/削除するだけでした。1 つが要求され、キューにそれ以上残っていない場合は、新しいバイト配列が作成されます。

私が見たもう 1 つの方法は、プログラム全体で 1 つの大きなバイト配列を使用します。キューの考え方は引き続き適用されますが、代わりに、使用するバイト配列のスライス (オフセット) を決定する整数のキューです。配列が要求され、キューにそれ以上残っていない場合は、配列のサイズを変更する必要があります。

高度にスケーラブルなサーバーに適したソリューションは次のうちどれですか? 私の本能は、必要に応じて配列のサイズを変更すると（大きなチャンクで割り当てたとしても）、特に配列が大きくなった場合にかなりコストがかかると想像するため、多くのバイト配列を使用する方が安くなるということです。複数の配列を使用することもより直感的なようです-私が考えていない1つの大規模な配列を使用する利点はありますか?

私は最近 ido-mode を使い始めましたが、これは全体的に非常に優れています。しかし、特に壊れているように見えるものが 1 つあり、それを修正するための設定 (ha) がそこに埋め込まれているのではないかと考えています。

ido-switch-buffer は埋め込みバッファを気にしていないようです。つまり、bury-buffer を使用してから ido-switch-buffer を使用すると、多くの場合、最初に選択したのは先ほど埋めたものになります。

これを回避する簡単な方法はありますか？バッファーを埋めることの要点は、すぐにそれをもう一度見たくないということです。

「BUFFER」という言葉をあちこちで見かけますが、それが何であるかを正確に把握することはできません。

1. 素人の言葉でバッファとは何か説明してください。
2. いつ使用されますか？
3. どのように使用されますか？

バイトのバッファは、signedcharまたはunsignedchar、あるいは単にcharバッファにする必要がありますか？CとC++の違いはありますか？

ありがとう。

今日、cout と printf にはバッファがあることを知っています。バッファはスタックのようなもので、cout と printf の出力を右から左に取得し、(コンソールまたはファイルに)上から下に出力すると言われています。このような、

次に、以下のコードを記述します。

VS2005では、出力は

g++( (GCC) 3.4.2 (mingw-special)) の下では、出力は次のようになります。

バッファはスタックのようです。ただ、今日C++ Primer Plusを読んでみると、coutは左から右に働き、毎回オブジェクト(cout)を返すと書いてあるので、「挿入で出力を連結できる機能ですね」。しかし、左から右への方法では cout< 出力 9 8 7 を説明できません。今、cout のバッファの仕組みについて混乱しています。誰か助けてもらえますか?

私は数日前に cout がバッファを持っていることを知っています。ググると、バッファはスタックのようなもので、cout と printf の出力を右から左に取得し、(コンソールまたはファイルに)出力すると言われています。 )上から下へ。このような、

次に、以下のコードを記述します。

VS2005では、出力は

スタックのやり方は合ってるみたいですね〜 ただ、昨日C++ Primer Plusを読んでみると、coutは左から右に動き、毎回オブジェクト(cout)を返すって書いてあったので、「それが出力を連結できる機能です」挿入」を使用して。しかし、左から右への方法では説明できません cout<

するとAlnitakは、「<< 演算子は実際には ostream& operator<<(ostream& os, int) であるため、別の書き方では次のようになります: operator<< ( operator<< ( operator<< ( cout, a ), b ), c)",

右端の引数が最初に評価される場合、それはある程度説明できます。

cout のバッファの仕組みについて混乱しています。誰か助けてもらえますか?

":bn" と ":bp" を使用して vim でバッファーを切り替えると、ステータス行に次の便利な情報が表示されます。

（それを可能にするのは「set showmode」だと思います。）しかし、その「（1）」は常に文字通り「（1）」です。バッファを変更しても変化しません。(「1」の周りのかっこも奇妙です。)

誰もそれを修正する方法を知っていますか?

追加: それはおそらく、私の .vimrc に何か問題があることに関係しているでしょう 。

関連して、バッファの切り替えを本当に簡単にするための便利なトリックがあります (.vimrc のエントリ):

検索性を向上させるキーワード: vim、複数のバッファ、バッファ間の切り替え、奇妙なステータス行。[この質問に対する回答を探していて、最初の試行でこれが見つからなかった場合は、ここに他の人を追加してください!]

ヒープスプレー、ヒープオーバーフロー、ヒープオーバーランの違いは何ですか?

これらの用語は、バッファ スプレー、バッファ オーバーフロー、バッファ オーバーランに置き換えることができますか?

それらも同じ定義を持っていますか？

整数オーバーフローの場合の結果は(unsigned int) * (int)? unsignedまたはint？operator[]配列インデックス演算子 ( ) は、char*:intなどにどのような型をとりunsigned intますか?

私は次の関数を監査していましたが、突然この質問が発生しました。この関数には 17 行目に脆弱性があります。

wと の両方を考慮してくださいh。非常に大きな符号なし整数です。9 行目の乗算は、検証に合格する可能性があります。

問題は 17 行目です。掛け算: 結果が の場合int i、積が負になる可能性があり、結果として の前の位置にアクセスすることになります。結果が の場合、積は常に正になり、 の後の位置にアクセスすることになります。unsigned int wintbufunsigned intbuf

これを正当化するコードを書くのは難しいです:intは大きすぎます。誰かがこれについてアイデアを持っていますか?

製品のタイプを特定するドキュメントはありますか? 私はそれを検索しましたが、これまでのところ何も見つかりませんでした。

コンパイルされたオブジェクトファイルでは、それらは単なるバイトであるため、脆弱性に関する限り、(unsigned int) * (int)生成するunsigned intかどうかは問題ではないと思います。int次のコードは、製品のタイプに関係なく同じように機能します。

したがって、乗算が返す型は問題ではありません。int消費者関数が取るかどうかが重要ですunsigned。

ここでの問題は、その機能がどれほど悪いか、または機能を改善するためにどのように機能を改善するかではありません。この機能には間違いなく脆弱性があります。問題は、標準から規定された動作に基づいた、関数の正確な動作に関するものです。