C言語なら俺に聞け 147

**デフォルトの名無しさん** · 2018/08/16(木) 23:36:02.22

C言語の話題のみ取り扱います C++の話題はC++スレへ
質問には最低限の情報(ソース/コンパイラ/OS)を付ける
数行で収まらないソースは以下を適当に使ってURLを晒す
https://paiza.io/
https://ideone.com/
http://codepad.org/

C11
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1570.pdf

C99
http://www.open-std.org/jtc1/sc22/WG14/www/docs/n1256.pdf
http://kikakurui.com/x3/X3010-2003-01.html

C FAQ 日本語訳
http://www.kouno.jp/home/c_faq/

JPCERT C コーディングスタンダード
https://www.jpcert.or.jp/sc-rules/

前
C言語なら俺に聞け 146
https://mevius.5ch.net/test/read.cgi/tech/1525031257/

**デフォルトの名無しさん** · 2018/09/06(木) 21:38:33.95

freeがいちいちSVCなんかするわけねえだろ
それと、おまえスワップとページを混同してるな

**デフォルトの名無しさん** · 2018/09/06(木) 21:42:11.21

>>781
ポインタ書き換えたりするから一度ディスクからメモリに戻さざるを得ないのでは？
ものすごく大きい領域を一括で確保した場合は全部戻す必要ないけど細切れに沢山確保してあるのをバラバラにfreeしたらなりそうだよね。

**デフォルトの名無しさん** · 2018/09/06(木) 21:46:37.65

>>781
free()すると管理領域を書き換えるためにページインが必要になる

**デフォルトの名無しさん** · 2018/09/06(木) 21:52:07.32

ランタイムの実装とOSにどう伝えてるかの間のことを考え出すと激しく禿る思考停止
unix/linux な人はどう実装してるか確認してるの？

**デフォルトの名無しさん** · 2018/09/06(木) 21:54:14.48

>>782
そうなの？
例えばWindowsだとfreeは内部でHeapFreeをコールしてるのかと思ってた。
HeapFreeって恐らくSVC伴うよね？

**デフォルトの名無しさん** · 2018/09/06(木) 23:11:21.70

皆さん、実メモリってどの位積んでいるの？

◆QZaw55cn4c · 2018/09/06(木) 23:42:12.50

>>787
DDR3 16G です、もっとほしい…

**デフォルトの名無しさん** · 2018/09/06(木) 23:43:10.77

8G
しかしこのPCは5年以上前に買ったやつ。

**デフォルトの名無しさん** · 2018/09/06(木) 23:53:41.06

>>781
単純に free だけの話じゃなく、自分が作り上げたオブジェクトツリーを辿りながら free していく過程でその（結局解放する）オブジェクトをページインすることになる。
C でオブジェクトとか言うことの是非は置いといて。

**デフォルトの名無しさん** · 2018/09/07(金) 00:04:11.13

>>787
Windows7 で 3GB。
Linux な家サーバだと 1GB。
Cプログラミングスタイルも細かくブロック分けてスタック節約するようなセコセコ型が基本。

**デフォルトの名無しさん** · 2018/09/07(金) 06:00:25.35

個人で使うための大したことないツールだったか、
この件の実験用に作ったプログラムだったか忘れたけど…。

そこそこ沢山のデータを、ひとつ読み取ってはmallocで確保した領域に保存、
ハッシュテーブル(値が重複する要素はリンクド・リストでつなぐ)にブチ込んで
個々のデータはプログラム終了まで破棄しない、て条件。

終了前に真面目にfreeして回るのと、そのままexitしてOSに片付けてもらうのと、
比較してみたらfreeのループ処理が意外に重かったんで、
解放処理の関数を残したまま呼び出し部だけ注釈にして、
// 解放すべきだと思いつつも無駄に重いんでOSに上手いことやってもらう
みたいな自分用のメモを残したわ。我ながらどっちつかずの折衷案。

**デフォルトの名無しさん** · 2018/09/07(金) 07:56:45.53

>787
Win7以降で最低4Ｇ、可能なら8Ｇ。3Dゲームやるなら16G以上。
XP時代は2Gか3Gだった。

**デフォルトの名無しさん** · 2018/09/07(金) 07:57:24.56

>>787
今使ってるマイコンのRAMは64バイト

**デフォルトの名無しさん** · 2018/09/07(金) 08:06:16.22

メモリを確保しっぱなしでわざわざ明示的に解放コードを書かないことはある
C++じゃなくてCだと特に

組み込みだとそもそも終了処理なんて物が無かったりする

**デフォルトの名無しさん** · 2018/09/07(金) 08:35:25.77

>>792
(俺はそういう状況に遭遇したことがないが、)やるなら、
freeを生かしたまま残し、その直前でexit、
exitに「// free が遅いからここで強制終了」とコメントかな。

そもそもCはやたらfreeするようには出来てない。それはK&Rのfree実装をみても明らかだ。
C++や他GC言語のようにインスタンスを個別にmalloc/freeした方が
プログラミング的に美しく、自由度があるのも確かだが、
古来C流なら
> 個々のデータはプログラム終了まで破棄しない、て条件。
が分かっている時点で纏めてmallocし、内部的に切り出して使う、とかじゃないかな？
大きなテキストを1発mallocで確保し、内部的に改行コードで区切って使うみたいに。
初期データはインミュータブル扱い、追加/変更はインスタンス毎個別に確保、だ。

ただこれだと結局コードは増えてしまうし、個別freeすべきかのフラグを導入するか、
解放関数でインミュータブル領域かどうかを判定する必要がある。
そういうのが面倒だと最初から全部C++流にインスタンス毎個別に確保になり、
その分動作が遅くなるが、コード自体は綺麗に（統一的に）保たれる。
結局、コードを取るか、手間かけてその分高速化するか、でしかない。
気にならない程度なら、俺はC++流の個別確保の方がコードが綺麗だからいいと思うが。
(つまり今の君の実装）
気になるのなら、選択の余地無く高速化するしかないし。

**デフォルトの名無しさん** · 2018/09/07(金) 08:38:20.43

>>795
むしろ C++ の方が気安く new するから、そっちの方が放置したくならないかね。
根っこのオブジェクトを delete すれば後のはデストラクタがやってくれるとかで面倒さは少ないのかもしれないが。

何にしても、許されるのはきちんと解放できるけどあえてしない、ってのだけだな。
なんだかよく分かんないし面倒からOSに尻拭いしてもらうなんてのはダメだ。
fork で起こした子プロセスがメモリを free せず終了しても問題無いが、それをスレッドにしましょうなんてなった瞬間に破綻する。

**デフォルトの名無しさん** · 2018/09/07(金) 09:28:39.55

商業プログラムだとラッパだらけで直接free呼ばんし。
freeなしという選択肢は常に確保しとけばよい。

**デフォルトの名無しさん** · 2018/09/07(金) 11:25:43.88

>>786
え、WindowsにSystem z版てあるんだっけ？

**デフォルトの名無しさん** · 2018/09/07(金) 12:12:28.24

>>799
え？System z限定の話だったの？

**デフォルトの名無しさん** · 2018/09/07(金) 12:18:34.93

>>800
だってSVCって。。。

**デフォルトの名無しさん** · 2018/09/07(金) 12:28:11.67

>>801
スーパーバイザコールを拡大解釈して、いわゆる特権モードを伴うシステムコールとして書いてたわ。
誤解があったらすまん。

**デフォルトの名無しさん** · 2018/09/07(金) 12:36:08.16

>>781
mmap経由ならOSによってはそうかもな

**デフォルトの名無しさん** · 2018/09/07(金) 12:51:04.62

>>802
おｋ
じゃあ、その前提で話を戻そう
freeはISO/IEC9899では宣言と引数の意味のみが規定され実装は未規定だ
782でああ言ったのは、freeする度毎にタイムスライスを放棄するような実装は
まずなかろうということだ

**デフォルトの名無しさん** · 2018/09/07(金) 14:34:23.02

>>804
まず、786で書いたようにあくまで「思ってた」だけで確固たる根拠はないことを前提に。

freeするならどこからか借りていたメモリ領域を返却するわけで、仮想メモリ返却にはMMUを使ったページ管理が必要だよね？
仮想メモリページ管理はメモリマネージャー的なカーネルモードドライバが必要なはずで、つまり解放時にはシステムコールを伴う。

ただ、HeapFree時に直接カーネルモードで解放が実行されずメモリマネージャがガーベジコレクション的に後々回収するなら、あなたの言うとおりfree時にユーザーモードで閉じて処理されるかも。

このへん、Linuxとかどういう実装になってるんだろうね？

**デフォルトの名無しさん** · 2018/09/07(金) 14:55:15.04

画期的なメモリ確保方式とか出来ないかな
例えばさ、名前付きタグを付けてメモリ確保し、
名前指定で一気に解放できるようにするとか

**デフォルトの名無しさん** · 2018/09/07(金) 15:22:58.08

Rust？

**デフォルトの名無しさん** · 2018/09/07(金) 15:56:06.95

>>805
freeがメモリを返却する相手が何者なのかは未規定だぞ
いちいちOSへ直に返しているとおまえさんの言うとおりだが
スタティックリンクライブラリがOSから大口で借りたメモリを切り売りする
スタイルならシステムコールの回数をガクンと減らせる
よくある実装は1MiBあたりを境に小容量は切り売りで大容量は直にという形

**デフォルトの名無しさん** · 2018/09/07(金) 16:07:14.96

>>808
いや、俺はANSI Cとかの規定の話してるんじゃなくて、SVCって単語からこの議論がスタートしてるのでモダンなOS上の一般的な実装の話をしてると思ってたんだけど、違ったのか。

確かにアプリ起動時にある程度のヒープを最初から用意ってのはありそう。

**デフォルトの名無しさん** · 2018/09/07(金) 16:15:46.30

>>806
ソフトで実現で良いなら、簡単に実現できそうね。
てかsmbか何かでそういう実装見たことあるような？

**デフォルトの名無しさん** · 2018/09/07(金) 17:07:55.49

>>805
Linux+glibcの環境なら、mallocは昔ながらのbrkシステムコールの方法と
mmapシステムコールの方法が状況に応じて使われる
freeしたときmmapをmunmapしてOSに返されることもある
はず。…たしか

**デフォルトの名無しさん** · 2018/09/07(金) 18:11:36.24

>>811
なるほど、勉強になります。
やっぱりOSのメモリ管理をちゃんと理解しようとしたら参考になるので最低限glibcとmmapを読まないといけないね。

**デフォルトの名無しさん** · 2018/09/07(金) 20:33:47.92

ちらっとmmapとglibc斜め読みしてみた。
こんな世界があるんだとソフトエンジニア7年目にして新しい視点が開眼しそう。
色々気付きをくれた方々、ありがとうございました。

**デフォルトの名無しさん** · 2018/09/07(金) 23:08:07.85

>>806
ゆとりりゅうのすごいめもりかくほ、まで読んだ。

マジレスすると、
> 名前付きタグ
このコストが分からない馬鹿はCを学ぶ意味はあるだろう。
スクリプト言語しか使ったことのない奴に多いが。（例：ハッシュはタダだと思ってる）

>>805
> 仮想メモリ返却にはMMUを使ったページ管理が必要だよね？
お前は中途半端に勉強してるな。まあ悪いことではないが。
ページの単位は今も昔も4KBだ。その方法ではインスタンス毎の確保は出来ないと分かるだろ。

>>812-813
読むのは勝手だが、あまり関係ないところに深入りしても意味はないぞ。
7年目なら業務関連は一通り出来るようになっており、知識を横に広げているのかもしれないが、
OS関連の知識があってもな。

時間が有り余っていて手当たり次第に知識を吸収するのも一つの手だが、
もし大きい(10,000行以上）のを書いたことがないのなら、
まずは規模の限界（複雑さの限界）に挑戦する方がいいと思うが。

◆QZaw55cn4c · 2018/09/07(金) 23:21:41.29

>>814
＞もし大きい(10,000行以上）のを書いたことがないのなら、まずは規模の限界（複雑さの限界）に挑戦する方がいいと思うが。
そうですね…
1万行ですか…
せいぜい 1000 行程度までしかやったことがありません、モチベーションが続かない・燃料切れ、という感じです

**デフォルトの名無しさん** · 2018/09/08(土) 00:12:07.00

行数が多ければいいというものでもないと思うが・・・

**デフォルトの名無しさん** · 2018/09/08(土) 00:16:36.09

だいぶ初歩の質問なんだけどextern宣言って本当に必須なの？コンパイラというかリンカによるのかもしれないけど、つけなくても同じ動作するよね？
今まで疑問に思わず書いてたけど、これを聞かれて色々試してみると実際つけなくても同様の動きしてるように見えるし、ちゃんと答えられなかったわ

**デフォルトの名無しさん** · 2018/09/08(土) 00:16:57.63

>>816
ならお前なりの妥当な規模を測る単位でも示せよ

**デフォルトの名無しさん** · 2018/09/08(土) 00:24:37.23

>>816
否定ばかりして新しい提案をしない典型的無能要員

◆QZaw55cn4c · 2018/09/08(土) 00:43:40.72

>>817
ライブラリ関数をコールするだけなら extern は要らない子です、でもライブラリが独自の変数を定義して公開しているのならば extern がないと困ります
例えば <stdio.h> の stdin, stdout, stderr

**デフォルトの名無しさん** · 2018/09/08(土) 01:03:55.35

>>817
> 1. Declaration can be done any number of times but definition only once.
> 2. “extern” keyword is used to extend the visibility of variables/functions().
> 3. Since functions are visible through out the program by default. The use of extern is not needed in function declaration/definition. Its use is redundant.
> 4. When extern is used with a variable, it’s only declared not defined.
> 5. As an exception, when an extern variable is declared with initialization, it is taken as definition of the variable as well.
> https://www.geeksforgeeks.org/understanding-extern-keyword-in-c/
下のコード例が見やすい。
これが規格と合致しているのかは知らん。

◆QZaw55cn4c · 2018/09/08(土) 01:26:25.96

>>821
しかし C には仮定義 "tentative definition" があったりして混迷するのです
ISO/IEC 9899:1999 6.9.2.2
the behavior is exactly as if the translation unit contains a file scope declaration of that
identifier, with the composite type as of the end of the translation unit, with an initializer
equal to 0.

私には、これはリンカの仕業であってコンパイラが自ら行動しているようには見えないのですが…

**デフォルトの名無しさん** · 2018/09/08(土) 04:02:52.50

glibc は malloc だけで 5000行あるってね。
上級者スレに解説動画があったけど面白かったよ。

**デフォルトの名無しさん** · 2018/09/08(土) 09:36:45.93

>>814
>ページの単位は今も昔も4KBだ。その方法ではインスタンス毎の確保は出来ないと分かるだろ。
ごめん、これがよく分かんない。
MMUのページ単位が4KBなのと、インスタンス毎の確保はできないってのがつながらない。
てかここで言うインスタンスって何？

**デフォルトの名無しさん** · 2018/09/08(土) 09:55:06.11

>>824
インスタンス1つにいちいち4KBもアロケートするのかって話だろ

**デフォルトの名無しさん** · 2018/09/08(土) 10:01:56.96

>>825
別に1回のmallocで必ずしも毎回4KBのベージを割り当てる必要ないのでは？
mallocするのが小さいサイズなら確保済みの4KBの空いてるとこから割り当てれば良いし。
実際にはどういう実装になってるか知らんけど。

**デフォルトの名無しさん** · 2018/09/08(土) 10:10:27.96

そもそも動的メモリ確保/解放と仮想メモリ管理は直接関係ない話
組み込みだとMMUなんて存在しない環境もある

**デフォルトの名無しさん** · 2018/09/08(土) 10:12:51.74

>>826
それだとお前のレス
> freeするならどこからか借りていたメモリ領域を返却するわけで、仮想メモリ返却にはMMUを使ったページ管理が必要だよね？
> 仮想メモリページ管理はメモリマネージャー的なカーネルモードドライバが必要なはずで、つまり解放時にはシステムコールを伴う。
と矛盾するだろ。
お前は日本語が駄目なタイプか？

**デフォルトの名無しさん** · 2018/09/08(土) 10:15:40.02

>>828
そういう意味では、厳密には「4KB以上のfree」と書くべきだったかな？
ページサイズに言及したのは先の書き込みの後なので別に論理矛盾はないと思うけど。

**デフォルトの名無しさん** · 2018/09/08(土) 10:25:31.57

>>826
うん、俺もそう思うし
実際の実装もそうなっているのが多い
ただし4KBではなく1MiBとかだけど

**デフォルトの名無しさん** · 2018/09/08(土) 10:29:17.43

>>829
ぷろぐらみんぐのまえににほんごをがんばれ

**デフォルトの名無しさん** · 2018/09/08(土) 10:29:54.08

業務に関係なく完全に知的好奇心からのmalloc実装の想像だったので、やっぱりglibc読んでみよう。
色々レスくれた人、ありがとう。

**デフォルトの名無しさん** · 2018/09/08(土) 10:38:55.04

ファイルシステムの管理領域が大きくなりすぎて、
4KB以下のページサイズには出来ない

4MBで千個、4GBで百万個のページを管理しないといけないから、
管理領域だけでも、100MB以上になる

だから、ページサイズをもっと大きい、2MBにすると、
2GBで千個、2TBで百万個のページを管理できるから、今のHDD の容量に対応できる

**デフォルトの名無しさん** · 2018/09/08(土) 10:43:05.81

HDDだとシリンダ容量との親和性を考えないとね
だけどSSDが普及してる今どきの事情だとどうなんだろう

**デフォルトの名無しさん** · 2018/09/08(土) 10:55:59.74

>>833
> 4MBで千個、4GBで百万個のページを管理しないといけないから、
> 管理領域だけでも、100MB以上になる

管理領域ってどう計算してるの？

**デフォルトの名無しさん** · 2018/09/08(土) 10:58:20.45

一領域当たり100byte

**デフォルトの名無しさん** · 2018/09/08(土) 11:02:40.38

>>836
すまん、聞き方がアホだった
その1領域が100Byteになる理由を聞きたかった

**デフォルトの名無しさん** · 2018/09/08(土) 11:31:35.27

>>833
つHugePage

**デフォルトの名無しさん** · 2018/09/08(土) 16:08:33.18

utf8procというUnicodeライブラリを使いたいのですが、C99に準拠してるかどうかって分かりますか？
「emulate C99 bool」というコメントがソースコードにあったのでおそらくC89あたりからサポートしていると思うんですが。
https://github.com/JuliaStrings/utf8proc

**デフォルトの名無しさん** · 2018/09/08(土) 17:17:58.22

>>839
C99に準拠している
そのコメントの少し前に
「MSVC prior to 2013 lacked stdbool.h and inttypes.h」ってコメントがあるからWindowsの古い環境のためにboolとかを定義しているだけだね

**デフォルトの名無しさん** · 2018/09/08(土) 18:36:43.66

OSのすべての機能を学びたいなら、ムック本の
Linuxエンジニア養成読本、第3版、2016

カーネル、起動処理、仮想記憶、
ファイルシステム、シェルスクリプトなど

ファイルシステム・管理領域の仕組みなどを読んで

**デフォルトの名無しさん** · 2018/09/08(土) 18:44:21.19

タネンバウム先生の本でしょ
すごい弟子を育てた伝説の師匠

**デフォルトの名無しさん** · 2018/09/08(土) 18:49:46.85

なにそれ、すごい面白そう！
アラサーだけどまだまだ青二才だしとっても勉強になります！

**デフォルトの名無しさん** · 2018/09/08(土) 19:31:07.27

>>841
>>837にレス頼む

**デフォルトの名無しさん** · 2018/09/09(日) 05:27:49.39

>>840
ありがとうございます！
これでUnicodeが古い環境で心置きなく使えますわ。

**デフォルトの名無しさん** · 2018/09/09(日) 14:54:16.40

ここのスレの人はValgrindは
使っているんだろうか。
メモリリークとか考えれば
ぜひ使うべきツールだと思う。
https://qiita.com/tjun/items/e9d2f7da3c94eb0240d8

**デフォルトの名無しさん** · 2018/09/09(日) 15:31:42.46

便利だよね
ただ役に立ってるときはクソコードを触ってるときでもあると思う

**デフォルトの名無しさん** · 2018/09/09(日) 15:44:39.72

変数中の "1" のビット数を数える効率的方法ありますか？
aが32ビットとして
for (i = 0; i < 32; i++) {
j = j + a & 1;
a = a >> 1;
}
みたいに1ビットずつカウントするしかないでしょうか
あるいは、8bitとかで区切ってテーブルを引いて加算とかでしょうか(16ビットや32ビットのテーブルは現実的でないので)

**デフォルトの名無しさん** · 2018/09/09(日) 15:50:52.78

a=(a&0a55555555)+(a>>1&0a55555555);
a=(a&0a33333333)+(a>>2&0a33333333);
a=(a&0a0F0F0F0F)+(a>>4&0a0F0F0F0F);
a=(a&0a00FF00FF)+(a>>8&0a00FF00FF);
a=(a&0a0000FFFF)+(a>>16&0a0000FFFF);

**デフォルトの名無しさん** · 2018/09/09(日) 15:53:41.89

a = (a & 0x55555555) + (a >> 1 & 0x55555555);
a = (a & 0x33333333) + (a >> 2 & 0x33333333);
a = (a & 0x0F0F0F0F) + (a >> 4 & 0x0F0F0F0F);
a = (a & 0x00FF00FF) + (a >> 8 & 0x00FF00FF);
a = (a & 0x0000FFFF) + (a >> 16 & 0x0000FFFF);

**デフォルトの名無しさん** · 2018/09/09(日) 16:07:17.49

32ビットだしその書き方良くないと思います

**デフォルトの名無しさん** · 2018/09/09(日) 16:54:40.77

https://ideone.com/FGqs1S
なにも問題ない
ﾚｽをｺﾋﾟﾍﾟで普通に動く

ｱﾎがいちいち車輪の再発明するよりとりあえず↓ｺﾚ使っとけば間違いない
http://gcc.gnu.org/onlinedocs/gcc/Other-Builtins.html
Built-in Function: int __builtin_popcount (unsigned int x)
　Returns the number of 1-bits in x.
Built-in Function: int __builtin_popcountl (unsigned long)
　Similar to __builtin_popcount, except the argument type is unsigned long.
Built-in Function: int __builtin_parityll (unsigned long long)
　Similar to __builtin_parity, except the argument type is unsigned long long.

**デフォルトの名無しさん** · 2018/09/09(日) 17:39:09.00

>>847
自作ツールで無茶苦茶
役に立ってしまった。
そうか、クソコードだったかw

それはさておき今回の発端>>757は、
メモリリークなんか気にしはじめたら
修正コストがどれくらいかかるか
わからない、それだったら現状で
問題は表面化してないし、
そのままでいいじゃん、みたいな
状況だと思う。

Vargrindを導入して
手軽にメモリリークを
チェックできれるようになれば、
上司にもとりあえず直しましょう
という説得ができる
チャンスもあるかも。

**デフォルトの名無しさん** · 2018/09/09(日) 17:57:06.08

>>850
うまいやり方だなぁ

**デフォルトの名無しさん** · 2018/09/09(日) 17:57:22.00

>>850 この式は初めて見ると訳の分からない呪文みたいだけど、
落ち着いて考えると分割統治の技法を並列処理してるんだよね。
これで1の立ってるビットの数が分かる理由を考えるのは良い教材かと。

**デフォルトの名無しさん** · 2018/09/09(日) 18:06:01.01

>>850
少なくとも最後の行だけは
a = (a + (a >> 16)) & 0x0000FFFF;
の方がよさそう。
正確には最大 32 にしかならないから & 0x0000001F でもよさそうだし、値の上限を考えながらだと途中の行ももう少し演算を減らせたりするかも？

**デフォルトの名無しさん** · 2018/09/09(日) 18:06:59.52

>>856
0x0000003F だったw

**デフォルトの名無しさん** · 2018/09/09(日) 20:35:00.38

>>850
a = (a & 0x55555555) + (a >> 1 & 0x55555555);
a = (a & 0x33333333) + (a >> 2 & 0x33333333);
a = (a + (a >> 4)) & 0x0F0F0F0F0F;
a += a >> 8;
a = (a + (a >> 16)) & 0x3F;

でも同じ結果が得られた。
最適化無しだと 9% くらい速くなった。

**デフォルトの名無しさん** · 2018/09/09(日) 20:36:22.47

>>858
0F 多すぎw
0x0F0F0F0F ね

**デフォルトの名無しさん** · 2018/09/09(日) 21:00:45.14

しね

**デフォルトの名無しさん** · 2018/09/09(日) 21:13:17.93

a = (a & 0x55555555) + (a >> 1 & 0x55555555);
a = (a & 0x33333333) + (a >> 2 & 0x33333333);
a = (a + (a >> 4)) & 0x0F0F0F0F;
a = (a * 0x101 * 0x10001) >> 24;

にしたら >>850 より 24% 速くなった(pentiumM linux)。
でも gcc の速度最適化を入れるとどれも変わらないね。

**デフォルトの名無しさん** · 2018/09/09(日) 21:19:41.88

なに１人ではしゃいでんのこいつ。

**デフォルトの名無しさん** · 2018/09/09(日) 21:28:41.02

CPUにそういう命令なかったっけ？
使うところでは割と使いそうだけど

**デフォルトの名無しさん** · 2018/09/09(日) 21:45:09.16

>>863
AlphaとかM16Cとか古いCPUにはあった気がする。
最近はあんまり見ないね。

**デフォルトの名無しさん** · 2018/09/09(日) 21:54:33.81

ああ、SSEにpopcntがあるね

**デフォルトの名無しさん** · 2018/09/09(日) 22:32:42.62

ポックント

**デフォルトの名無しさん** · 2018/09/10(月) 02:37:34.95

ビットを数える・探すアルゴリズム
http://www.nminoru.jp/~nminoru/programming/bitcount.html

**デフォルトの名無しさん** · 2018/09/10(月) 10:36:25.17

ビット数の数えあげが欲しくなるのってパリティチェックで末尾付加したりするとき？

**デフォルトの名無しさん** · 2018/09/10(月) 10:44:53.73

ソケットみたいにフラグをビット管理してるときとかもほしくなるかな

**デフォルトの名無しさん** · 2018/09/10(月) 10:56:31.39

符号とか暗号とかの世界ではしょっちゅう使うよ。
1の数で最適なアルゴリズムが変わるってケースもあるし、
暗号にサイドチャネル攻撃仕掛けるにはハミング距離とか重要。

**デフォルトの名無しさん** · 2018/09/10(月) 11:27:01.59

>>870 はなんとなく理解できるけど　>>869 のほうは想像がつかないな
ﾋﾞｯﾄ管理されたﾌﾗｸﾞと ONしてるﾋﾞｯﾄ数による分岐や演算法が変わるのが直結しない感じ

**デフォルトの名無しさん** · 2018/09/10(月) 11:51:19.73

フラグは数えねえよな
性能重視でもなければビットフィールド使って読みやすくして欲しいわ

**デフォルトの名無しさん** · 2018/09/10(月) 11:54:23.84

バラで書くから読みにくいのであって
関数にしておけば外から見た仕様は変わらない

**デフォルトの名無しさん** · 2018/09/10(月) 12:16:32.03

普通の通信でエラー検出以外の目的でビット数を数える必要性がわからない。
そんな特定のCPU以外は必ず無駄な計算が必要になる方式をなぜ使う？

**デフォルトの名無しさん** · 2018/09/10(月) 12:46:33.22

>>874
エラー検出、訂正目的以外の通信のためにビットの数え上げするって誰かレスしてたっけ？

**デフォルトの名無しさん** · 2018/09/10(月) 15:09:59.53

>>875
>>869はそうではないのか？ならば居ないな。

**デフォルトの名無しさん** · 2018/09/10(月) 19:25:38.98

>>821
んーこの文章読むと、よく教科書的な本に書かれてる関数に対してexternを書きましょうってのは冗長で不要って話なのね。確かに実際の動きとは合うし勉強になりました。

>>822
書いてる意図を汲めてるのか自信ないけど、他のサイトにもリンカ依存とあって、この話が全ての環境に対して正しい話なのか･･･若干不安はある感じ？

**デフォルトの名無しさん** · 2018/09/10(月) 19:32:05.94

Common Lisp にビットを数える関数があるけどcでも同様のものがあったようなゔ

**デフォルトの名無しさん** · 2018/09/10(月) 20:00:47.59

int a=0;

printf("%p"　,a);

printf("%p",&a);

同じアドレスが表示されると思っていたのですが、上下で違う数字が出力されました。
アドレスを表示するのはどちらが正しいのでしょうか？
よろしくお願いします。

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2018/09/10(月) 20:06:35.73

下。

**デフォルトの名無しさん** · 2018/09/10(月) 20:07:47.31

>>879
&a の方。

ていうか同じになるわけがない。片方は printf() に a の内容である 0 を渡しているんだから。