C言語なら俺に聞け 147
レス数が950を超えています。1000を超えると書き込みができなくなります。
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. >>847
自作ツールで無茶苦茶
役に立ってしまった。
そうか、クソコードだったかw
それはさておき今回の発端>>757は、
メモリリークなんか気にしはじめたら
修正コストがどれくらいかかるか
わからない、それだったら現状で
問題は表面化してないし、
そのままでいいじゃん、みたいな
状況だと思う。
Vargrindを導入して
手軽にメモリリークを
チェックできれるようになれば、
上司にもとりあえず直しましょう
という説得ができる
チャンスもあるかも。 >>850 この式は初めて見ると訳の分からない呪文みたいだけど、
落ち着いて考えると分割統治の技法を並列処理してるんだよね。
これで1の立ってるビットの数が分かる理由を考えるのは良い教材かと。 >>850
少なくとも最後の行だけは
a = (a + (a >> 16)) & 0x0000FFFF;
の方がよさそう。
正確には最大 32 にしかならないから & 0x0000001F でもよさそうだし、値の上限を考えながらだと途中の行ももう少し演算を減らせたりするかも？ >>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% くらい速くなった。 >>858
0F 多すぎw
0x0F0F0F0F ね 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 の速度最適化を入れるとどれも変わらないね。 CPUにそういう命令なかったっけ？
使うところでは割と使いそうだけど >>863
AlphaとかM16Cとか古いCPUにはあった気がする。
最近はあんまり見ないね。 ビットを数える・探すアルゴリズム
http://www.nminoru.jp/~nminoru/programming/bitcount.html ビット数の数えあげが欲しくなるのってパリティチェックで末尾付加したりするとき？ ソケットみたいにフラグをビット管理してるときとかもほしくなるかな 符号とか暗号とかの世界ではしょっちゅう使うよ。
1の数で最適なアルゴリズムが変わるってケースもあるし、
暗号にサイドチャネル攻撃仕掛けるにはハミング距離とか重要。 >>870 はなんとなく理解できるけど >>869 のほうは想像がつかないな
ﾋﾞｯﾄ管理されたﾌﾗｸﾞと ONしてるﾋﾞｯﾄ数による分岐や演算法が変わるのが直結しない感じ フラグは数えねえよな
性能重視でもなければビットフィールド使って読みやすくして欲しいわ バラで書くから読みにくいのであって
関数にしておけば外から見た仕様は変わらない 普通の通信でエラー検出以外の目的でビット数を数える必要性がわからない。
そんな特定のCPU以外は必ず無駄な計算が必要になる方式をなぜ使う？ >>874
エラー検出、訂正目的以外の通信のためにビットの数え上げするって誰かレスしてたっけ？ >>875
>>869はそうではないのか？ならば居ないな。 >>821
んーこの文章読むと、よく教科書的な本に書かれてる関数に対してexternを書きましょうってのは冗長で不要って話なのね。確かに実際の動きとは合うし勉強になりました。
>>822
書いてる意図を汲めてるのか自信ないけど、他のサイトにもリンカ依存とあって、この話が全ての環境に対して正しい話なのか･･･若干不安はある感じ？ Common Lisp にビットを数える関数があるけどcでも同様のものがあったようなゔ int a=0;
printf("%p" ,a);
printf("%p",&a);
同じアドレスが表示されると思っていたのですが、上下で違う数字が出力されました。
アドレスを表示するのはどちらが正しいのでしょうか？
よろしくお願いします。 >>879
&a の方。
ていうか同じになるわけがない。片方は printf() に a の内容である 0 を渡しているんだから。 %p は ポインタを要求しているが
ポインタのサイズと intのサイズが違ってたら 鼻から悪魔 >>880
>>881
>>882
指定子Ｐで＆が付いてない方も変換されると思っていました。
ただの数値が表示されるだけなんですね。
int *a;
int b=0;
a=&b;
printf("%p",a);
この場合は＆が付いてなくてもアドレスを渡してるのでｏｋなんですね。
ありがとうございました。 >>869
それはどっちかって言うとビットサーチだね
68020 とかの BFFFO 命令とか https://ideone.com/bsjclG
また、低学歴知恵遅れのｸﾙｸﾙﾊﾟｰがｳｿ書いてるわ。。。
64bitのｱﾄﾞﾚｽ空間を持ってて、intのｻｲｽﾞが32bitならちゃんと動くﾜｹがないからな >>887
これまたチンケな知識でマウント取りに来たな w ID:WGo2tHWR ← ｺｲﾂにきまってんだろ
なあにが
そうそう。そういうこと。
だ
なにも知らないﾑｸなﾔﾂ相手に
低学歴知恵遅れの分際でﾃｷﾄｰなことばっかり書き込んでる ん？これのこと？
> printf() に a の内容である 0 を渡している >>883 ← ﾑｸな初心者
>>885 ← 低学歴知恵遅れ ID:WGo2tHWR 「そうそう。そういうこと。」 ← ｺﾚのｺﾄだ
低学歴知恵遅れはﾚｽもおえないの？ あれ？
int *a;
int b=0;
a=&b;
printf("%p",a);
って別に正しくね？ https://ideone.com/bsjclG
この処理結果みても分からないなら
ｵﾂﾑに相当な問題がある ううむ、俺にはaは64ビット環境だと64ビット長に見えるのだが違うのか？ で、処理結果みた？
で、処理結果みた？
で、処理結果みた？ おたくのサンプルは64ビットアドレスをintにキャストしちゃてるやん。そりゃ実行結果違うわ。 https://ideone.com/PGwK6j
ｷｬｽﾄはずしたったぞ
当然、結果はかわらない
やっぱりなこの板は低学歴知恵遅れしかいない
この程度のこともわからずにいきってﾚｽしてるﾜｹだからな たまたま 足りない分 0 を引っ張ってきてるけど（レジスタで渡ったから？）
スタックに積んでるリターンアドレスの一部から足りないのを補ってると、もっとわけわかな数値に
未定儀の挙動を推測すすのもまたオツなもの か いやいや、883のaはポインタなんだってw
なんでintに入れちゃうのw そんなことｵﾚのしったことじゃないからな
>>883 ← ﾑｸな初心者
>>885 ← 低学歴知恵遅れ ID:WGo2tHWR 「そうそう。そういうこと。」 ← ｺﾚのｺﾄだ
低学歴知恵遅れはﾚｽもおえないの？ 半角クンていつも周りを見ずに自分の思い込みだけでレスしちゃって誤り訂正できないから、恥ずかしい(*/□＼*)
直進しかできない目隠しされたイノシシみたい なにが間違いなわけ
指摘してみ
一切間違ったこと書いてないからな
低学歴知恵遅れはそもそも認知能力に問題がある なぜ64ビットポインタをintに入れたの？
883ではそんなこと一切してないんだけど。
逆に
>printf() に a の内容である 0 を渡している
は整数リテラルがintなのに%pで受けてるので、64ビット環境なら4バイト分スタックのゴミを拾ってきそうだけど。 はずかしくなって
こっち側にこようとしても
もう手遅れだからな なんだ、結局はaがポインタだってことを見逃しただけかよw >>909
半角野郎が数行のプログラムも理解できないくせに自分で改竄したコードが動かねぇって騒いでただけ。
半角野郎こそ低学歴知恵遅れクルクルパーで認知能力とオツムに相当な問題があるってことが証明されただけなので気にするな。
本人は顔真っ赤にして逃げたみたいだけど。 ポインタを受け取るべき%p変換指定子に、ポインタでない値を与えることの
危険性は >>882 ですでに指摘されてるのに、後乗りで書いた >>887 で
こんだけ引っ張れるのは、ある意味で才能かもな。
汚い言葉遣いを我慢しながら拝聴するほど啓蒙的な内容でもないし。 >>911
半角クンのレスは、5%の真実と15%の間違い・思い込みと80%の繰り言・罵詈雑言でできてるからね。まっとうに読む価値はない。 処理系って何？
cpuかコンパイラの事かなと思ってるんだけど。
間違ってる？ 処理系は、翻訳環境と、実行環境に大別される
翻訳環境とはコンパイラ等開発ツールを実行する環境
実行環境とはコンパイル結果のバイナリが稼働する環境、客先と言ってもよい >>917
バイナリが稼働する環境はcpuってことかな
どうもお世話になりました cpuだけじゃないメモリが実装されているアドレス
i/oが実装されているアドレス
osの挙動
など様々な要因が絡む CPUが同じであっても、
Windowsでは動かせてもmacOSでは動かないとか
同じWindowsでも、64bit環境では動いても32bit環境だと動かないとか 半角くん、いたの?
lynx で見てるから何言ってるかわからない。 処理系ってC99に関してはJISで定義されてたよね。 昔の教科書には
C言語の原稿
↓プリプロセッサ
マクロ・ヘッダファイルが展開された原稿
↓翻訳機
アセンブリ言語の原稿
↓アセンブラ
機械語
↓リンカ
実行可能ファイル
っていう図がよく描かれてて，今でもWebを検索するとよく見掛けるんだけど，ほんとに今現在のコンパイラってこういうことやってんの？
gccやclangって，もはやC言語の原稿からほぼほぼ直接に実行可能ファイルを生成してるんじゃない？
さすがにプリプロセッサくらいはあるかもしれんが。 -vつけて起動してみ。
プリプロcppはcc1に統合された。
gccだと、cc1とかasとかcollect2とかが動いてるはず。
clangはデフォルトだとasなしかも。 >>925
あざす
やっぱり減ってはいるんだな。
結構ああいう図を見掛けるんで，なんか（ほんとにこんな段階踏んでんのか？）ってモヤモヤしてた。
素人考えだが，あんな風に幾つも重ねてビルドしてたら最適化しにくい気がするし。 え そうなん
と思って空のファイルをgcc -vで処理したら
たしかにある程度進んでリンカの段階で エラーになったわ。 bash-4.3$ gcc -v -o aho aho.c ←開始
/usr/lib/gcc/i586-slackware-linux/5.3.0/specs から spec を読み込んでいます
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/libexec/gcc/i586-slackware-linux/5.3.0/lto-wrapper
ターゲット: i586-slackware-linux
configure 設定: ../gcc-5.3.0/configure --prefix=/usr --libdir=/usr/lib --mandir
=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap --enable-langu
ages=ada,c,c++,fortran,go,java,lto,objc --enable-threads=posix --enable-checkin
g=release --enable-objc-gc --with-system-zlib --with-python-dir=/lib/python2.7/
site-packages --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=gcc4-com
patible --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --
enable-lto --disable-install-libiberty --with-gnu-ld --verbose --enable-java-ho
me --with-java-home=/usr/lib/jvm/jre --with-jvm-root-dir=/usr/lib/jvm --with-jv
m-jar-dir=/usr/lib/jvm/jvm-exports --with-arch-directory=i386 --with-antlr-jar=
/root/slackware-current/source/d/gcc/antlr-runtime-3.4.jar --enable-java-awt=gt
k --disable-gtktest --with-arch=i586 --target=i586-slackware-linux --build=i586
-slackware-linux --host=i586-slackware-linux
スレッドモデル: posix
gcc バージョン 5.3.0 (GCC)
（-続く-） （-続き-）
COLLECT_GCC_OPTIONS='-v' '-o' 'aho' '-mtune=pentium' '-march=i586'
/usr/libexec/gcc/i586-slackware-linux/5.3.0/cc1 -quiet -v aho.c -quiet -dumpba
se aho.c -mtune=pentium -march=i586 -auxbase aho -version -o /tmp/ccVi37md.s ← ①ﾌﾟﾘﾌﾟﾛｾｽ
GNU C11 (GCC) version 5.3.0 (i586-slackware-linux)
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version 3.1.4, MPC
version 1.0.3
warning: GMP header version 6.1.0 differs from library version 6.1.2.
GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=62246
存在しないディレクトリ "/usr/lib/gcc/i586-slackware-linux/5.3.0/../../../../i58
6-slackware-linux/include" を無視します
#include "..." の探索はここから始まります:
#include <...> の探索はここから始まります:
/usr/lib/gcc/i586-slackware-linux/5.3.0/include
/usr/local/include
/usr/lib/gcc/i586-slackware-linux/5.3.0/include-fixed
/usr/include
探索リストの終わりです。
（-続く-） （-続き-）
GNU C11 (GCC) version 5.3.0 (i586-slackware-linux) ← ②ｺﾝﾊﾟｲﾙ
compiled by GNU C version 5.3.0, GMP version 6.1.0, MPFR version 3.1.4, MPC
version 1.0.3
MPC version 1.0.3
warning: GMP header version 6.1.0 differs from library version 6.1.2.
GGC heuristics: --param ggc-min-expand=63 --param ggc-min-heapsize=62246
Compiler executable checksum: c5a3ffed702d1cd048214b2b66d4a98a
（-続く-） （-続き-）
COLLECT_GCC_OPTIONS='-v' '-o' 'aho' '-mtune=pentium' '-march=i586'
/usr/lib/gcc/i586-slackware-linux/5.3.0/../../../../i586-slackware-linux/bin/a
s -v --32 -o /tmp/ccMFr9O6.o /tmp/ccVi37md.s ← ③ｱｾﾝﾌﾞﾙ
GNU アセンブラ バージョン 2.26 (i586-slackware-linux)、BFD バージョン version 2
.26.20160125 を使用
（-続く-） （-続き-）
COMPILER_PATH=/usr/libexec/gcc/i586-slackware-linux/5.3.0/:/usr/libexec/gcc/i58
6-slackware-linux/5.3.0/:/usr/libexec/gcc/i586-slackware-linux/:/usr/lib/gcc/i5
86-slackware-linux/5.3.0/:/usr/lib/gcc/i586-slackware-linux/:/usr/lib/gcc/i586-
slackware-linux/5.3.0/../../../../i586-slackware-linux/bin/
LIBRARY_PATH=/usr/lib/gcc/i586-slackware-linux/5.3.0/:/usr/lib/gcc/i586-slackwa
re-linux/5.3.0/../../../../i586-slackware-linux/lib/:/usr/lib/gcc/i586-slackwar
e-linux/5.3.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-o' 'aho' '-mtune=pentium' '-march=i586'
/usr/libexec/gcc/i586-slackware-linux/5.3.0/collect2 -plugin /usr/libexec/gcc/
i586-slackware-linux/5.3.0/liblto_plugin.so -plugin-opt=/usr/libexec/gcc/i586-s
lackware-linux/5.3.0/lto-wrapper -plugin-opt=-fresolution=/tmp/ccGuF6mf.res -pl
ugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s -plugin-opt=-pas
s-through=-lc -plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_s
--eh-frame-hdr -m elf_i386 -dynamic-linker /lib/ld-linux.so.2 -o aho /usr/lib/
gcc/i586-slackware-linux/5.3.0/../../../crt1.o /usr/lib/gcc/i586-slackware-linu
x/5.3.0/../../../crti.o /usr/lib/gcc/i586-slackware-linux/5.3.0/crtbegin.o -L/u
sr/lib/gcc/i586-slackware-linux/5.3.0 -L/usr/lib/gcc/i586-slackware-linux/5.3.0
/../../../../i586-slackware-linux/lib -L/usr/lib/gcc/i586-slackware-linux/5.3.0
/../../.. /tmp/ccMFr9O6.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --
as-needed -lgcc_s --no-as-needed /usr/lib/gcc/i586-slackware-linux/5.3.0/crtend
.o /usr/lib/gcc/i586-slackware-linux/5.3.0/../../../crtn.o ← ④ﾘﾝｸ 普通に別々のﾓｼﾞｭｰﾙで独立して処理されてる
①ﾌﾟﾘﾌﾟﾛｾｽ /usr/libexec/gcc/i586-slackware-linux/5.3.0/cc1
②ｺﾝﾊﾟｲﾙ /usr/bin/gcc
③ｱｾﾝﾌﾞﾙ /usr/lib/gcc/i586-slackware-linux/5.3.0/../../../../i586-slackware-linux/bin/as
④ﾘﾝｸ /usr/libexec/gcc/i586-slackware-linux/5.3.0/collect2 >>934
コンパイルは
/usr/lib/x86_64-linux-gnu/6/cc1
だな。俺の場合 bash-4.3$ gcc -v -E -o aho_.c aho.c ←開始
/usr/lib/gcc/i586-slackware-linux/5.3.0/specs から spec を読み込んでいます
COLLECT_GCC=gcc
ターゲット: i586-slackware-linux
configure 設定: ../gcc-5.3.0/configure --prefix=/usr --libdir=/usr/lib --mandir
=/usr/man --infodir=/usr/info --enable-shared --enable-bootstrap --enable-langu
ages=ada,c,c++,fortran,go,java,lto,objc --enable-threads=posix --enable-checkin
g=release --enable-objc-gc --with-system-zlib --with-python-dir=/lib/python2.7/
site-packages --enable-libstdcxx-dual-abi --with-default-libstdcxx-abi=gcc4-com
patible --disable-libunwind-exceptions --enable-__cxa_atexit --enable-libssp --
enable-lto --disable-install-libiberty --with-gnu-ld --verbose --enable-java-ho
me --with-java-home=/usr/lib/jvm/jre --with-jvm-root-dir=/usr/lib/jvm --with-jv
m-jar-dir=/usr/lib/jvm/jvm-exports --with-arch-directory=i386 --with-antlr-jar=
/root/slackware-current/source/d/gcc/antlr-runtime-3.4.jar --enable-java-awt=gt
k --disable-gtktest --with-arch=i586 --target=i586-slackware-linux --build=i586
-slackware-linux --host=i586-slackware-linux
スレッドモデル: posix
（-続く-） （-続き-）
gcc バージョン 5.3.0 (GCC)
COLLECT_GCC_OPTIONS='-v' '-E' '-o' 'aho_.c' '-mtune=pentium' '-march=i586'
/usr/libexec/gcc/i586-slackware-linux/5.3.0/cc1 -E -quiet -v aho.c -o aho_.c -
mtune=pentium -march=i586
存在しないディレクトリ "/usr/lib/gcc/i586-slackware-linux/5.3.0/../../../../i58
6-slackware-linux/include" を無視します
#include "..." の探索はここから始まります:
#include <...> の探索はここから始まります:
/usr/lib/gcc/i586-slackware-linux/5.3.0/include
/usr/local/include
/usr/lib/gcc/i586-slackware-linux/5.3.0/include-fixed
/usr/include
探索リストの終わりです。
COMPILER_PATH=/usr/libexec/gcc/i586-slackware-linux/5.3.0/:/usr/libexec/gcc/i58
6-slackware-linux/5.3.0/:/usr/libexec/gcc/i586-slackware-linux/:/usr/lib/gcc/i5
86-slackware-linux/5.3.0/:/usr/lib/gcc/i586-slackware-linux/:/usr/lib/gcc/i586-
slackware-linux/5.3.0/../../../../i586-slackware-linux/bin/
LIBRARY_PATH=/usr/lib/gcc/i586-slackware-linux/5.3.0/:/usr/lib/gcc/i586-slackwa
re-linux/5.3.0/../../../../i586-slackware-linux/lib/:/usr/lib/gcc/i586-slackwar
e-linux/5.3.0/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-v' '-E' '-o' 'aho_.c' '-mtune=pentium' '-march=i586'
ｴﾗｰなし ﾌﾟﾘﾌﾟﾛｾｽ前
bash-4.3$ cat aho.c
#include <stdio.h>
#define ahobaka "あほばか"
#define AHOBAKA aho##baka
#define LIT(str) #str
#define PRINT(f,...) fprintf(stdout, f, __VA_ARGS__)
#define SHINE PRINT("%s%s\n", AHOBAKA, LIT(a"b"c))
int main(void) {
SHINE;
return 0;
}
ﾌﾟﾘﾌﾟﾛｾｽ後
bash-4.3$ cat aho_.c
（-略-）
# 8 "aho.c"
int main(void) {
fprintf(
# 9 "aho.c" 3 4
stdout
# 9 "aho.c"
, "%s%s\n", "あほばか", "a\"b\"c");
return 0;
} コンパイラが(プリプロセス済みの)ソースを処理する際、
直接にはアセンブリのソースに持っていかず、いったん中間言語に変換。
その中間言語の段階でも最適化を行ってから
アセンブリに変換してアセンブル・リンク。
……みたいな手順になってると聞いたことがある。
中間言語段階の中間ファイルを出力させることができるか知らんけど。
プリプロセッサ、コンパイラ、アセンブラ、リンカよりも
内部的な手順はむしろ増えてるのかも。 >>941
>>924 の図に倣うなら
C言語の原稿
↓プリプロセッサ
マクロ・ヘッダファイルが展開された原稿
↓翻訳機1
中間言語（最適化済み）
↓翻訳機2
アセンブリ言語の原稿
↓アセンブラ
機械語
↓リンカ
実行可能ファイル
みたいなかんじかね。 昔 LSIゲームってあったでしょ
ああいうゲームをCで書いてパソコンで遊びたいんだけど
技術的な情報が不足してんだ 特に画面を動かす方法
そういうのどこで手に入るか分かる人いる？ 教えてくださいヽ(^o^)丿 CでGUIまでやりたいということか？
うーん・・・ >>945
エスケープシーケンスで検索
とりあえず NetHack みたいので遊んでみたら >>945 の言うLSIゲームってのが、
ドットマトリクスの汎用液晶パネルを使ったゲームじゃなくて、
ゲーム&ウォッチみたいな専用にデザインされた液晶のゲームだと
ちょいと変わってくるかもな。
大筋は同じだけど、少数のデカキャラ表示を点けたり消したり。 イメージ伝えるためにLSIゲームと言うならドットマトリックスというよりゲームウォッチ式じゃないかな。
ただその趣旨は、簡易な操作と表示のゲームなんじゃないかと。
キャラクタ端末ゲームを知ればそっちに倒れるんじゃないかな？ レス数が950を超えています。1000を超えると書き込みができなくなります。
