アカウント名:
パスワード:
malloc/freeの処理コストってどれくらいかかるんだろう。メモリがバカ高かった時代はmalloc/freeで使用量を厳密に、というのはわかるんだが、ンGB当たり前の昨今、malloc/freeの処理コストの方が高くなったりしないのかな?と。「だいたい、こんくらいとっといてぇー」というようなプログラミングスタイルは無いのだろうか、と思う。
・・・malloc/free叩いとらんな、最近。
数GBの画像データを複数枚読み込んで比較するプログラムをCで組んでいたりするのでmalloc(てかcalloc)とかfreeとか頻繁に使ってますが何か。
ファイル名指定に256バイト/512バイトのcharを確保しているのも無駄知識だろうなぁ。8の倍数でメモリ領域確保したほうが効率がいいなんて都市伝説?まだそのおまじないは意味がある?
もし Windows 向けだとしたら、最近は Unicode API が基本 + Unicode ベースのファイル名指定では 32767 文字までサポートなので、全然足りない場合がありうるという話に。 大抵のアプリが対応してないパスになりますけど。
# TCHAR が char じゃなく wchar_t なんですよね、_UNICODE だと。
>Unicode ベースのファイル名指定では 32767 文字まで
CreateFile() の話であれば、32000文字までですね。
>Unicode ベースのファイル名指定では 32767 文字までCreateFile() の話であれば、32000文字までですね。
MSDN Library 英語版の CreateFile 関数の説明 [microsoft.com]には 32767 文字と書かれており、日本語版 [microsoft.com]でも「ほぼ 32,000 ワイド文字」となっているので、「32767 文字までではなく 32000 文字までだ」という主張は誤りだと思います。ただ、 File Names, Paths, and Namespaces [microsoft.com] には
Note: The maximum path of 32,767 characters is approximate, because the "\\?\" prefix may be expanded to a longer string by the system at run time, and this expansion applies to the total length.
と書かれており、 32767 文字ぎりぎりまで使えるとは限らないみたいなので、 32000 文字くらいまでに抑えておいた方が安全という事情はあるかもしれません。僕は \\?\ なんて使ったことがなく、よく知りません。
>MSDN Library 英語版の CreateFile 関数の説明 [microsoft.com]には 32767 文字と書かれており
情報ありがとうございます。知りませんでした。
言い訳をすると、昔は、英語版MSDN にも nearly 32,000 としか書かれてなかったんですけどね…(This lets you use paths that are nearly 32,000 Unicode characters long.)
言い訳をすると、昔は、英語版MSDN にも nearly 32,000 としか書かれてなかったんですけどね… (This lets you use paths that are nearly 32,000 Unicode characters long.)
ということは、日本語版が「ほぼ 32,000 ワイド文字」という謎の書き方になっているのは、以前の英語版の影響なんですね。参考になります。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
日々是ハック也 -- あるハードコアバイナリアン
時々思うんだが (スコア:3, 興味深い)
malloc/freeの処理コストってどれくらいかかるんだろう。メモリがバカ高かった時代はmalloc/freeで使用量を厳密に、というのはわかるんだが、ンGB当たり前の昨今、malloc/freeの処理コストの方が高くなったりしないのかな?と。「だいたい、こんくらいとっといてぇー」というようなプログラミングスタイルは無いのだろうか、と思う。
・・・malloc/free叩いとらんな、最近。
-- gonta --
"May Macintosh be with you"
Re: (スコア:0)
数GBの画像データを複数枚読み込んで比較するプログラムをCで組んでいたりするので
malloc(てかcalloc)とかfreeとか頻繁に使ってますが何か。
ファイル名指定に256バイト/512バイトのcharを確保しているのも無駄知識だろうなぁ。
8の倍数でメモリ領域確保したほうが効率がいいなんて都市伝説?
まだそのおまじないは意味がある?
Re:時々思うんだが (スコア:1)
もし Windows 向けだとしたら、最近は Unicode API が基本 + Unicode ベースのファイル名指定では 32767 文字までサポートなので、全然足りない場合がありうるという話に。
大抵のアプリが対応してないパスになりますけど。
# TCHAR が char じゃなく wchar_t なんですよね、_UNICODE だと。
Re: (スコア:0)
>Unicode ベースのファイル名指定では 32767 文字まで
CreateFile() の話であれば、32000文字までですね。
32767文字? 32000文字? (スコア:2)
MSDN Library 英語版の CreateFile 関数の説明 [microsoft.com]には 32767 文字と書かれており、日本語版 [microsoft.com]でも「ほぼ 32,000 ワイド文字」となっているので、「32767 文字までではなく 32000 文字までだ」という主張は誤りだと思います。ただ、 File Names, Paths, and Namespaces [microsoft.com] には
と書かれており、 32767 文字ぎりぎりまで使えるとは限らないみたいなので、 32000 文字くらいまでに抑えておいた方が安全という事情はあるかもしれません。僕は \\?\ なんて使ったことがなく、よく知りません。
Re: (スコア:0)
>MSDN Library 英語版の CreateFile 関数の説明 [microsoft.com]には 32767 文字と書かれており
情報ありがとうございます。知りませんでした。
言い訳をすると、昔は、英語版MSDN にも nearly 32,000 としか書かれてなかったんですけどね…
(This lets you use paths that are nearly 32,000 Unicode characters long.)
Re:32767文字? 32000文字? (スコア:2)
ということは、日本語版が「ほぼ 32,000 ワイド文字」という謎の書き方になっているのは、以前の英語版の影響なんですね。参考になります。
Re: (スコア:0)