アカウント名:
パスワード:
プログラムの基本として、全てのバッファに対して...
少なくとも文字列処理について言えば、そもそも自前でバッファを確保して使おうなどとするのが、時代遅れで、無粋で、効率の悪いプログラミングスタイルでしょう。別途入念に作られた汎用文字列操作ライブラリを使うことを考えてみるべきです。
そうした汎用ライブラリを使うと、文字列格納のためのメモリがヒープ領域に
ガベージコレクションすればいいって? あんなもんは「ゴミ撒き散らしても後で掃除しとけば文句ないんだろう」という下品でだらしない発想の元に用意されたフールプルーフ(バカ避け)機能でしかない。 実際ガベージコレクションが使われているのはBASICとかJavaとかのキッシュイータ向けの言語ぐらいだろ。 それにガベージコレクションが発生すると極端なレスポンス低下が発生するので、それを受け入れられるようなオモチャのプログラムでしか使えない。
ま、他人のやってる事に「時代遅れ」だとか「無粋」だとか「効率が悪い」だとか「昔気質」だとか言うのは、あんたには100年早いって事だな。 少なくとも(識者に質問)と書いてあるスレッドには、あんたはお呼びじゃないよ。 オモチャじゃなくて本当のプログラムが作れるようになって出直しといで。ボウヤ
# 我ながら煽り耐性無いなと思いつつ、/.Jで煽るような発言は謹んでもらいたいという希望も込めて、あえて外から見るとみっともない煽り返しをしてみたりするAC
あんたマトモなデーモンとか書いたこと無いだろ。 練習として作ってみましたとかいうオモチャじゃなくて、毎日何万アクセスも受けて365日何年も動き続ける事を前提としたヤツ。 文字列処理のためにいちいちヒープ取ってやってたら、メモリのスラシングが起きてコピー回数云々とかと比べ物にならない性能低下が発生する。
なるほど、では文字列を含むほとんどのメモリ管理をヒープ(pool)で行うApacheも練習用として作ってみましたとかいうオ
では文字列を含むほとんどのメモリ管理をヒープ(pool)で行うApacheも練習用として作ってみましたとかいうオモチャなんですね。
Apacheって最初からスラッシングが起きたりする事の対策を半ばあきらめて、スラッシングが起きる前にそのプロセスを放棄して再フォークするという、まさに
「ゴミ撒き散らしても後で掃除しとけば文句ないんだろう」とい
日にたったの数万件程度なら、1アクセスあたり数百ミリ秒~数秒ほどの時間がありますよね。
処理の平均サイクルと応答速度とは別のもの。
「動き続ける」というのはむしろ動的にメモリを使うほうが当たり前にできる
mallocとfreeのようなオブジェクトのサイズによる管理を行う場合、効率の良い断片化の
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲはアレゲを呼ぶ -- ある傍観者
バッファオーバーフローについて(識者に質問) (スコア:0)
Re:バッファオーバーフローについて(識者に質問) (スコア:1)
少なくとも文字列処理について言えば、そもそも自前でバッファを確保して使おうなどとするのが、時代遅れで、無粋で、効率の悪いプログラミングスタイルでしょう。別途入念に作られた汎用文字列操作ライブラリを使うことを考えてみるべきです。
そうした汎用ライブラリを使うと、文字列格納のためのメモリがヒープ領域に
Re:バッファオーバーフローについて(識者に質問) (スコア:0)
練習として作ってみましたとかいうオモチャじゃなくて、毎日何万アクセスも受けて365日何年も動き続ける事を前提としたヤツ。
文字列処理のためにいちいちヒープ取ってやってたら、メモリのスラシングが起きてコピー回数云々とかと比べ物にならない性能低下が発生する。
ガベージコレクションすればいいって?
あんなもんは「ゴミ撒き散らしても後で掃除しとけば文句ないんだろう」という下品でだらしない発想の元に用意されたフールプルーフ(バカ避け)機能でしかない。
実際ガベージコレクションが使われているのはBASICとかJavaとかのキッシュイータ向けの言語ぐらいだろ。
それにガベージコレクションが発生すると極端なレスポンス低下が発生するので、それを受け入れられるようなオモチャのプログラムでしか使えない。
ま、他人のやってる事に「時代遅れ」だとか「無粋」だとか「効率が悪い」だとか「昔気質」だとか言うのは、あんたには100年早いって事だな。
少なくとも(識者に質問)と書いてあるスレッドには、あんたはお呼びじゃないよ。
オモチャじゃなくて本当のプログラムが作れるようになって出直しといで。ボウヤ
# 我ながら煽り耐性無いなと思いつつ、/.Jで煽るような発言は謹んでもらいたいという希望も込めて、あえて外から見るとみっともない煽り返しをしてみたりするAC
Re:バッファオーバーフローについて(識者に質問) (スコア:1)
>毎日何万アクセスも受けて365日何年も動き続ける事を前提としたヤツ。
こんなWindows環境が欲しい!ってちょっと思っちゃった:-)
-- yuno
Re:バッファオーバーフローについて(識者に質問) (スコア:1)
プロジェクトや、プログラムの規模が大きくなると、バッファオーバーフローの知識を十分に持っているプログラマだけでメンバを構成することが不可能になると思うが。
Re:バッファオーバーフローについて(識者に質問) (スコア:0)
Re:バッファオーバーフローについて(識者に質問) (スコア:0)
bugが取れなくって徹夜でもしてあせっているんでしょう。
Re:バッファオーバーフローについて(識者に質問) (スコア:0)
煽りってのは正論が含まれてナイト。
フツーの人はそんなこと言わない (スコア:0)
なるほど、では文字列を含むほとんどのメモリ管理をヒープ(pool)で行うApacheも練習用として作ってみましたとかいうオ
Re:フツーの人はそんなこと言わない (スコア:0)
スラッシングや処理効率などの心配が在るからメモリアロケータ
をオーバーライドして使うのが普通だと思ふ。
Apacheも、そうしていると思うけど?・・・
Re:フツーの人はそんなこと言わない (スコア:0)
Apacheって最初からスラッシングが起きたりする事の対策を半ばあきらめて、スラッシングが起きる前にそのプロセスを放棄して再フォークするという、まさに
Re:バッファオーバーフローについて(識者に質問) (スコア:0)
日にたったの数万件程度なら、1アクセスあたり数百ミリ秒~数秒ほどの時間がありますよね。仮にヒープ管理が重いとしても、めちゃめちゃ余裕だと思うのですが。
あと、「動き続ける」という
Re:バッファオーバーフローについて(識者に質問) (スコア:0)
処理の平均サイクルと応答速度とは別のもの。
mallocとfreeのようなオブジェクトのサイズによる管理を行う場合、効率の良い断片化の