C言語なら俺に聞け 153

2019/08/17(土) 23:02:42.00

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/
-
VIPQ2_EXTDAT: checked:vvvvv:1000:512:----: EXT was configured
※前スレ
C言語なら俺に聞け 152
https://mevius.5ch.net/test/read.cgi/tech/1560763630/

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2019/12/06(金) 00:04:45.19

>>491
了解です。ありがとうございました。

2019/12/06(金) 00:12:50.26

>>492
ちゃんとコードを読んだら↓の部分はケアされてましたね。失礼しました。
> reallocの戻り値は古いポインタと異なるものになる保証はないはずなので、

ただ、reallocが成功したらfreeは呼ばなくていいのは間違いないと思います。

2019/12/06(金) 00:50:56.12

>>490 のreallocのコード返り値のポインタが不定を指しているので、使わないでください。
こっちを使ってください。
https://qiita.com/yakitori32/items/98256db666029fb5ebca

2019/12/06(金) 00:55:18.93

>>493
了解です。ありがとうございます。

2019/12/06(金) 01:07:01.79

>>489
超高速ビットカウント
でググって出てくるページでちゃんと解説してくれてる
この手のよく見るやつはちょっとググれば解説見つかる

何を本質と置くかによるけど両者はそもそもアルゴリズムが違うのでその観点からなら違う
どちらのコードも結果は同じでも前者のほうが圧倒的に処理速度が早い
ビット数などが必要になる処理では速度が重要になるケースも多々あるので結果が同じでも後者は使い物にならない場合もある

2019/12/06(金) 01:36:02.35

>>496
レスありがとうございます。紹介していただいた記事を読ませていただき、大変勉強になりました。

ただ、>>489 の場合だと「ビットカウントするデータ列がある程度長い場合」には
当てはまらないため記事の前半の内容がアルゴリズムの基本になるとか思うのですが、
私が理解した範囲で記事の内容を参考にして関数を作成しても以下のようにしかできませんでした。

int popcount(unsigned long long x)
{
　　x = (x & 0x5555555555555555) + (x >> 1 & 0x5555555555555555);
　　x = (x & 0x3333333333333333) + (x >> 2 & 0x3333333333333333);
　　x = (x & 0x0f0f0f0f0f0f0f0f) + (x >> 4 & 0x0f0f0f0f0f0f0f0f);
　　x = (x & 0x00ff00ff00ff00ff) + (x >> 8 & 0x00ff00ff00ff00ff);
　　x = (x & 0x0000ffff0000ffff) + (x >> 16 & 0x0000ffff0000ffff);
　　return (int)((x & 0x00000000ffffffff) + (x >> 32 & 0x00000000ffffffff));
}

しかし >>489 の関数はこれを途中で打ち切って % 0xff をくっつけたような形になっており、
やはり完全な理解には至っていない状況です。
もし可能であれば、この部分についてもヒントをいただけると大変嬉しく思います。
たびたび申し訳ありませんが、どうぞよろしくお願いいたします。

2019/12/06(金) 04:41:11.15

>>497
64ビット長のビットカウントの最大値はたかだか64なので8ビット(最大255)で表現できる
一方、64ビットデータの分割統治による畳み込み計算は1回目で2ビット×32組、2回目で4ビット×16組、3回目で8ビット×8組の結果が得られる
ビット数を求めるだけなら3回目の結果が得られた時点で8ビットの最大数(255)で3回目の畳み込み結果の剰余を求めてやればそれぞれの組の重み(ビット数)が計算できる
(64を超えることはないことが明らかなので)

2019/12/06(金) 04:45:05.84

訂正
それぞれの組の重みの総計(ビット数)

2019/12/06(金) 05:11:25.02

>>498
わかりやすいご説明どうもありがとうございます！ほぼ理解できたと思います。
たとえば十進数の123を十進数文字の最大値9で割った余りは
1+2+3と等しくなりますが、これと同じ原理ということですよね？

ただよくよく考えてみると、そもそも十進数の各桁の合計を9で割った余りが
元の数を9で割った余りと等しくなることについても
お恥ずかしながら豆知識として知っているだけで原理を理解できていませんでした。
ただこれに関してはもはやC言語ではなく算数の問題なので、
その方面の解説サイトをググって勉強しようと思います。
なにはともあれ、回答してくださった皆様方、どうもありがとうございました。

>>495
読みやすい記事を提供してくださっているので、もう少しだけコメントさせてください。

現状だと、MemoryReAllocateを呼び出す側は関数の成否を確認するために
Mem->Memoryを覚えておく必要がありますので、MemoryReAllocateの引数に
参照渡しを使われるならMemoryReAllocateの戻り値はMomeryではなくて
成否を表すboolなどにされてはいかがでしょうか。

また、reallocは第一引数としてNULLを許容しているので
MemoryReAllocateは入力のMem->MemoryがNULLであっても
Mem->ElementSizeが正しい値であれば正常に動作しますが、
その一方でMemoryAllocateは失敗するとElementSizeがゼロの構造体を
返すので少しアンバランスかなと思いました。

あと、MemoryFreeがboolを返すのであれば、freeの前にNULLチェックを入れて
その結果をMemoryFreeの戻り値としてもいいかなと思いました。
（free関数自体はNULLを渡しても何もしないだけで問題は起こりませんが）

以上お目汚し失礼しました

2019/12/06(金) 05:15:04.10

1回進むごとに
2bitずつに区切って、1の数を各2bitに入れる
4bitずつに区切って、1の数を各4bitに入れる
8bitずつに区切って、1の数を各8bitに入れる
...

となるので
>>489だと各バイトの1の合計が、各バイトに入る

各バイトなので256バイトのテーブルを使う方法もある
チープなCPUだとこちらの方が速い

逆にリッチなCPUだと数える命令が最初から備わってたりするしベクタ化も可能

Icelake以降だとAVX512VBMIの命令を使って
超高速に64バイト分カウント出来る

2019/12/06(金) 05:24:05.53

>>500前半
なんか違う

10進数の各桁に関しては
1000a+100b+10c+d
=999a+99b+9c+a+b+c+d
=9(111a+11b+c)+(a+b+c+d)

これを2進数でやると
9のところが1になるからあまり意味がない

2019/12/06(金) 05:33:31.46

分割統治っていうより
レジスタ内の桁数を使ってSIMD演算してるって感じ

01020304 + 02040608

2桁ずつの4個の足し算になってるでしょ？

2019/12/06(金) 05:47:57.81

vpsrld
vpermb
vpermb
vpaddb

AVX512VBMIを使うと
レジスタに値がある状態で
4命令で64バイト分

2019/12/06(金) 05:56:22.53

>>501 >>504
レスありがとうございます。

> 各バイトなので256バイトのテーブルを使う方法もある
確かにある程度のビット幅ごとにテーブルを使って計算する方法は
シンプルですが効果が高そうですね。

> 逆にリッチなCPUだと数える命令が最初から備わってたりするしベクタ化も可能
> 4命令で64バイト分
勉強になります。本当に速さが必要ならCPU自体の理解から始めるべきなんですね。
このあたりのハードウェアの違いは標準ライブラリ関数が吸収してくれると最高なのですがｗ

>>502
10進数の話の数式どうもありがとうございます！大変勉強になりました。

そうすると、>>489 の popcount の最後にやっているのは
2進数というか0x100進数で、

0x1000000*a+0x10000f*b+0x100*c+d
=0xffffff*a+0xffff*b+0xff*c+a+b+c+d
=0xff*(0x01010x*a+0x0101*b+c)+(a+b+c+d)

ということになると思うのですがいかがでしょうか。

2019/12/06(金) 05:58:37.54

>>505 の数式が変でした。正しくは以下のとおりです。失礼しました。

0x1000000*a+0x10000*b+0x100*c+d
=0xffffff*a+0xffff*b+0xff*c+a+b+c+d
=0xff*(0x010101x*a+0x0101*b+c)+(a+b+c+d)

2019/12/06(金) 06:20:08.91

最後の % 0xff を見てなかった
なので各バイトの1の個数と勘違いしてました

>>506はその通り

%は、除算命令を使うと遅いので
コンパイラは
0x0101010101010101
との乗算とシフトに置き換えそうです

PCの64bit環境だとPOPCNT命令がそのまま1命令
Icelake以降だとVPOPCNTQで8個を1命令
で出来ます

2019/12/06(金) 06:24:24.02

x % 0xff
よりは
x * 0x0101010101010101 >> 56 & 0xff
の方が直接的でコンパイラを頼らない記述でしょう

2019/12/06(金) 06:34:20.70

それだと
剰余 x % 0xff
ではなくて
商 x / 0xff

2019/12/06(金) 06:36:33.62

>>508 で大丈夫
乗算の筆算を考えてみよう

2019/12/06(金) 06:37:31.16

>>507-508
レスありがとうございます。

> x % 0xff
> よりは
> x * 0x0101010101010101 >> 56 & 0xff
> の方が直接的でコンパイラを頼らない記述でしょう
コンパイラの最適化によって一行目が三行目に
置き換えられる可能性があるということですか！？
難しそうですがちょっと考えてみたいと思います。

> PCの64bit環境だとPOPCNT命令がそのまま1命令
> Icelake以降だとVPOPCNTQで8個を1命令
本当に速度を求めるならCPUの命令を直接使えということですね。
覚えておきます。

2019/12/06(金) 06:42:08.81

>>511
コンパイラは普通、定数の除算は乗算に置き換えます
乗算、シフトは1クロック、除算は数十クロックかかるのが普通なので

ただ、
>>508 にまでは最適化されないかも
なので>>508の方が良いです

2019/12/06(金) 06:54:43.75

>>512
ありがとうございます。そのようにしたいと思います。

ご親切に甘えてしまい申し訳ないのですが、
もう一つ質問させてください。今、
① = x % 0xff
と
② = x * 0x0101010101010101 >> 56 & 0xff
について考えていたのですが、
x = 0xff のとき、
① = 0x00, ② = 0xffのように、別の値になりませんか？
これは、どこか書き間違いがあるとういことでしょうか。
それとも、この違いは今回の用途では問題にならないということでしょうか。

2019/12/06(金) 06:57:32.55

>>512
立て続けにすみません。。。たった今理解しました。
「この違いは今回の用途では問題にならない」が正解ですね。

2019/12/06(金) 06:57:55.91

除算命令、
Skylakeで最大90クロックだそうで...
簡単な命令だと1クロックで3～4個実行出来る事を考えると劇遅ですね

Icelakeだと18クロックなので
改善されてるみたい

2019/12/06(金) 07:06:52.23

>>515
> 除算命令、
> Skylakeで最大90クロックだそうで...
なんと！しかも、「最大」という表現が付くんですね。
つまり、ただの数値計算なのに
クロックの数がデータに依存する可能があるということ…？

2019/12/06(金) 07:12:58.28

>>516
除算命令の実行時間はデータに依存します
内部的にループしてるようなものなので

SIMDの除算は多分一定
Icelakeももしかしたら一定かもしれません

SIMD乗算も非常に小さな値だと遅い事があったような

2019/12/06(金) 07:35:33.29

>>517
小さい値だと遅い！？
すみません、ハードウェアの知識がなさすぎて
タイプミスをされたのか本当にそうなのかの判断すらつかないです。。。

2019/12/06(金) 07:55:08.53

https://ja.m.wikipedia.org/wiki/%E9%9D%9E%E6%AD%A3%E8%A6%8F%E5%8C%96%E6%95%B0

ここの｢性能問題｣参照
浮動小数点演算の話ですので今回は関係ないです

2019/12/06(金) 07:59:35.87

そりゃ並列処理できるような相互依存性の低い大量のデータでもあるならともかく
小さなデータ塊対象だとパック化やアンパック化する手間が掛かる分だけ
総合的にはSIMD使った方が遅くなるだろ
馬鹿となんとかは使いようと言うだろ

2019/12/06(金) 08:10:43.32

どこの誤爆か気になる

2019/12/06(金) 12:19:42.67

>>520
馬鹿がSIMD使うと遅くなる
それはそうかも

2019/12/06(金) 15:17:31.13

>>519
勉強になります。
非正規化数という言葉はちらっと聞いたことはありますが、こういうデメリットもあるんですね。
そして、それでも非正規化数を使うのは
「浮動小数点数の加減算は決して『アンダーフローによるゼロ』にならない」
という理由があるのだということも初めて知り、とても興味深く感じました。

ところで、ビット演算に関してもう一つ相談させていただいてもよろしいでしょうか。

動的メモリ再確保のコストを減らすために確保するメモリのサイズを必ず 2ⁿ-1 の形にしたくて、
与えられた数を下回らない最小の 2ⁿ-1 の値の値を返すような関数を作って使っています。
つまり引数xを2進数で表したときの一番上位の1以下をすべて1に置き換えるような関数で、
具体的には以下のように記述しています。

int fill_lower_bits(int x)
{
　　x |= x >> 1;
　　x |= x >> 2;
　　x |= x >> 4;
　　x |= x >> 8;
　　x |= x >> 16;
　　return x;
}

この関数は割と使用頻度が高いので、PCの64bit環境にPOPCNT命令があるように、
もしfill_lower_bitsと似た振る舞いをする命令があれば名前を教えていただけないでしょうか。

（続く）

2019/12/06(金) 15:18:25.28

（続き）
また、こちらはあまり使い道は思いつきませんが、

int fill_higher_bits(int x)
{
　　x |= x << 1;
　　x |= x << 2;
　　x |= x << 4;
　　x |= x << 8;
　　x |= x << 16;
　　return x;
}

という関数を考えることもできて、これなら

int fill_higher_bits(int x)
{
　　return -(x & -x);
}

のように簡単な書き方に変更できます。
fill_lower_bitsについてもこういうテクニックがあればいいなと思っているのですが、
もし何かご存知であれば教えていただけると嬉しいです。

2019/12/06(金) 19:09:08.62

>>523
BSR命令といくつかの命令を組み合わせて出来ます
Cからだと _BitScanReverse64

>>524
x | -x
の方が良いと思います

2019/12/06(金) 19:33:49.52

>>525
何度も本当にどうもありがとうございます。大変勉強になります。

> _BitScanReverse64
こんな命令があったとは！
この名前で検索したら、今まで知らなかった興味深いページがたくさんヒットしました。
ReverseじゃなくてForwardというのもあるみたいですが、
Forwardの方はマイナスを使う方法でも十分高速になりそうなので、
どちらが速いか検証してみようと思います。

> x | -x
確かに…。
ド・モルガンの法則で ~(x & ~x) が ~x & x に書き換えられるのはすぐに分かるのですが、
もしかしてそれと同じことがマイナスでもできるのでしょうか。
-x が ~x + 1 と同じになることは理解しているので、ちょっと考えてみたいと思います。

2019/12/06(金) 19:53:04.32

>>526
> ド・モルガンの法則

-(a & b) = -a | -b が成り立つかなと期待したのですが、
a = 0, b = 1 のときにつまずいてしまいました。

でも、>>525 に書いていただいた -(x & -x) = -x | x は間違いなさそうです。

こういう式の変形って、どこかテキストに載っていたりするのでしょうか。

2019/12/06(金) 20:51:24.53

自分で頑張って探すんです

~x
x-1
-x
&
|
^

これらを組み合わせれば
一番右のビット関連がいろいろと出来ます

???10000
に対して
11110000
11100000
00010000
00011111
00001111
これらを得る最小回数の演算を考えてみてください

2019/12/06(金) 21:03:52.43

ド・モルガンと似た問題で、
「君たち2人は注意されないならば、君たち2人は私語を止めない」
の対偶、
「君たち2人が私語を止めるならば、君たち2人は注意される」
って矛盾にちょっと考えてしまったわ。

2019/12/06(金) 21:07:30.59

x 注意される
o 注意された

2019/12/06(金) 21:15:00.21

>>530
さすが、その通り。

2019/12/06(金) 23:44:25.67

>>523
メモリ確保やアクセスの時間に比べれば
サイズ計算の時間は無視出来る

ビット演算の趣味として楽しむ分には良いけど
普通にループでもパフォーマンスは変わらない

パフォーマンスが重要じゃないところ
(つまりほとんどの部分)は
移植性、見やすさ、工数、...
などが優先される

ということは知っておいた方が良いですね

2019/12/06(金) 23:51:44.77

分野によってはループや比較による分岐は遅すぎて使えないなんてことままあるよ

2019/12/07(土) 00:10:26.85

>>523の話

2019/12/07(土) 00:10:27.55

それは経験談？
それとも誰かからの受け売り？

2019/12/07(土) 00:15:02.34

動的メモリ再確保
のサイズ計算の話

オーダーnに対して係数の小さなオーダーlog nは無視して良い
って話

2019/12/07(土) 01:14:15.17

ちょっと前にスレで騒がれていたフーリエ変換に関する話題

50年来の信号処理に関する謎が解かれる、逆高速フーリエ変換がついに一般化
https://fabcross.jp/news/2019/20191206_fast-fourier-transform.html

2019/12/07(土) 19:02:43.91

解明って言うんか？これ

2019/12/14(土) 01:27:42.96

C言語というか、WindowsのCですが、
たとえば strcpyの lstrcpyと _tcscpyの違いは何なのでしょうか
前者は WindowsAPI、後者は VC++CRTという説明を見たのですがよくわからないのです
両者とも UNICODE(後者は_UNICODE) の有無で charとwchar_tを切り替えるようですが、どちらをどんな時に使用するのかが分かりません。

2019/12/14(土) 10:20:34.10

crtへの依存を減らせる分、常にlstrcpyを使えばいいと思うよ。lstrcpyは不正アクセスしたときに例外投げてくれるみたいだし。
自分なら依存減らす＆安全性のためにstrncpyとwcsncpyを選ぶけど

2019/12/14(土) 23:23:03.56

>>540
ありがとうございます。
539です。

今後は気をつけようと思いますが、過去に書いたコードは何ともいたし難く…orz
なぜ先に lstrcpyを見つけなかった 2014年のオレ…

でも、内容が古いのかもしれませんが、ある記事によると CRTの依存を断ち切るのも容易ではないようで。。。

2019/12/15(日) 00:22:25.61

むしろlstrcpyなんて16bit時代から引きずってる過去の遺物なんじゃ？
今はlstrcpyも非推奨、代替のStringCchCopyはWindowsAPIの体だけどkernel32.dll等を呼び出すのではなくstrsafe.h内にコードが書いてある変わり種なのでtchar.h系の_tcscpy_sでよくね？っていう

2019/12/15(日) 00:32:33.51

MSのCは独自色が過ぎる

2019/12/15(日) 09:51:20.97

そうか？　古くからMSCは「高いが安心」というポジションだったが

2019/12/15(日) 13:16:36.84

放送大学2020新講座
C言語基礎演習
https://www.wakaba.ouj.ac.jp/kyoumu/syllabus/PU02060200221/initialize.do

2019/12/15(日) 14:57:55.02

何の変哲の無いコードを書いてコンパイラのバグが顕在化するMicrosoftのCが安心とは、茶がヘソを沸かす。

2019/12/15(日) 15:53:29.93

唯一のECMA-372対応コンパイラ
壮大なマッチポンプだが…

2019/12/15(日) 23:21:27.87

そもそもCはUNIXの為に作られた言語だから
UNIX系以外のOSで使うと齟齬が出るよね

2019/12/16(月) 09:15:32.91

何言ってんだこのバカ

2019/12/16(月) 09:20:02.47

せいぜい�nとCR LFの齟齬くらいだね

2019/12/16(月) 09:40:49.35

それはテキストファイルのコードの違いというだけであって言語の仕様そのものとは直接関係ない

2019/12/16(月) 10:23:00.62

OSを記述しやすく意図されて言語という認識だが
UNIXに絞って特化された部分って何だろう？

2019/12/16(月) 10:34:38.41

テキストファイルといえば
歴史上どっかの段階で文字列操作や汎用IO関数を捨て専用のもちっと使いやすい内蔵スクリプト言語に任せ
どうしても処理速度を求めるマは自作、非標準ライブラリで配列イジクール形にしたらよかったのにね

システムコールの頻度とか毎度読み解く指定子とかで標準ライブラリも爆速ってほどじゃないしー
printfのうじゃうじゃ増える非互換指定子とか似た使い分け迷う関数の増殖とかを防げたろうに

2019/12/16(月) 11:27:10.48

せっかくライブラリとして言語の外に出てるのに、
なんでスクリプト言語なんか内蔵しなきゃいかんの。

2019/12/16(月) 12:29:48.70

>>552
creat()のモード指定が８進数で書ける

2019/12/16(月) 13:05:02.49

file の lock とかか >>552

2019/12/16(月) 13:12:27.77

>>555-556
それはライブラリの問題ではないか。言語仕様とはちょいと違う気がする

まあ「標準ライブラリは言語仕様(ｷﾘｯ」と言いきっちゃってもいい気もする

2019/12/16(月) 13:19:15.38

たしかにunix系以外で8進数って使わないような気もする。

2019/12/16(月) 13:21:15.05

Cは文字列をヌル終端するのが「ほぼ」前提になってるよね。
もしそれ以外の文字列表現を使うつもりだったら、
文字列専用の型を用意していたし、ポインタより配列を重視していたはず。

2019/12/16(月) 13:22:41.90

>>557
おまいがOSに特化したとか言い出したんじゃないのか

2019/12/16(月) 13:23:58.45

>>557
違う、８進数で書けると言う「言語仕様」の話

2019/12/16(月) 13:30:01.62

>>561
8進数でも書けちゃう
というだけで、建前としては「ちゃんと定数使え」じゃない？

言語仕様でUnix文化に特化してるところって
mainとreturnの仕様くらいじゃない？

2019/12/16(月) 13:32:32.25

>>562
8進数で書くのがchmod互換で直感的なんだべ

2019/12/16(月) 14:13:38.79

>>562
> 建前としては「ちゃんと定数使え」じゃない？
建前はともかく0777とか0755とかバンバン書かれてるし…

とまで書いてなんだけど、ちょっとググったらどうも８進数はC言語発祥じゃなくてB言語でも使えたみたいw
PDPシリーズは触ったことないからよくわからんけどHPのミニコンは命令コードが3bit単位に区切られて表記されてた
ブートローダーは手入力してて16個並んでるスイッチでアドレスや命令コードをセットするんだけど見ての通り3bit単位に区切ってある
もう記憶があやふやだけどアセンブラとかも８進表記ができたような気がする
http://www.hpmuseum.net/images/2108A-37.jpg
多分PDPも似たような感じだったんじゃないかと思う
なので８進数云々はあまり関係なかったわ、すまん

2019/12/16(月) 19:57:33.47

お前らも8進数よく使うだろ
0とか

2019/12/16(月) 20:00:10.61

ソースの見栄えを気にして桁そろえにスペース使わずに 0 を補うんですね

2019/12/16(月) 20:01:38.57

やったことあるヤツいるよな？

いやそうじゃなくて
ただの0

**蟻人間** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd02-jJp1) · 2019/12/16(月) 20:18:50.99

017は頭に0があるから、C/C++では8進数として扱う。ただのゼロもリテラルの分類としては8進数。

2019/12/16(月) 20:23:36.65

0リテラルは8進だったのか…

2019/12/16(月) 20:31:05.71

(6.4.4.1) octal-constant:
0
octal-constant octal-digit

まじか

でも8進だからなんだっていう

2019/12/16(月) 21:43:34.71

16歳の僕でも酒が飲めるぞ。
飲める飲める飲めるぞ酒が飲めるぞ。

2019/12/16(月) 21:43:53.10

え？割と有名な話では？

2019/12/16(月) 22:13:01.15

012 月はハロウィンで酒が飲めるぞ
飲める飲める飲めるぞ酒が飲めるぞ

2019/12/16(月) 22:28:43.33

>>571
それは10進数でしょ

2019/12/16(月) 22:44:38.36

いや
14進数とか16進数だろ

2019/12/17(火) 05:16:47.62

8進数いらない

2019/12/17(火) 07:03:39.66

Cにも0bと桁区切り欲しい

2019/12/17(火) 11:16:49.78

512色カラーで使った。

2019/12/17(火) 12:28:51.79

int main()
{
return 0;
}
8進数ですほんとうにありがとうございました

2019/12/17(火) 18:33:08.01

MinGWとUbuntuはどっちがいいですか？

2019/12/17(火) 19:26:43.19

何が？

2019/12/17(火) 23:43:40.20

Ubuntu

2019/12/17(火) 23:50:56.66

2進数表記が欲しい

2019/12/18(水) 00:13:36.84

16進小数リテラルが欲しい

2019/12/18(水) 00:16:26.43

>>584
加減乗除考えただけで頭痛くなりそうだ

2019/12/18(水) 00:19:17.60

すんごく欲しいならプリプロセッサでも作ればいいんじゃね？

2019/12/18(水) 00:19:24.08

人間が計算する必要は無いんだよ

2019/12/18(水) 00:24:30.38

>>586
プリプロセッサで10進数にするの？
それじゃ何の為の16進リテラルかわからない

いずれ対応するから待つのみ

2019/12/18(水) 00:34:01.93

プリプロセッサ作って言語を拡張とか、昔はけっこうあったけどな。

2019/12/18(水) 00:36:26.05

昔は結構あったはずのものが、今は残ってないのだろう

2019/12/18(水) 00:39:48.29

まあそれほど必要がないなら別にいいんじゃね。
IDEしか使わないならそういうことはやりづらいだろうし。