C++相談室 part144

**デフォルトの名無しさん** · 2019/07/22(月) 13:18:35.52

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part143
https://mevius.5ch.net/test/read.cgi/tech/1560574313/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1556142878/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

----- テンプレここまで -----

**デフォルトの名無しさん** · 2019/08/03(土) 17:50:54.20

そういえば、min(), max() は C の時代、確かマクロ実装版が基本だったり
して複雑なことになっているのかな。よく知らないけど。

**デフォルトの名無しさん** · 2019/08/03(土) 17:53:29.88

そこでBOOST_PREVENT_MACRO_SUBSTITUTIONですよ
BOOST_PREVENT_MACRO_SUBSTITUTIONを崇めよ

**デフォルトの名無しさん** · 2019/08/03(土) 17:55:43.43

マイクロソフト最大のチョンボだよな。

**デフォルトの名無しさん** · 2019/08/03(土) 17:59:48.03

関数は関数呼び出しが遅いから使うなマクロにしろ
処理は全部mainに入れろ

という恐ろしい時代から引きずってるから仕方ないといえば仕方ない

**デフォルトの名無しさん** · 2019/08/03(土) 18:02:18.88

だったら STL の方が、std::max とかじゃなくて、
std::smax とかにすべきだったような気がしますが。

**デフォルトの名無しさん** · 2019/08/03(土) 18:03:42.44

NOMINMAXしたらしたでgdiplusでエラーになったので、仕方なくusing std::min;using std::max;を書いてしまった。

**デフォルトの名無しさん** · 2019/08/03(土) 18:03:43.41

>>288
どんなusingがされている箇所でもstd::をつけさえすれば確実に標準ライブラリにアクセスできるんだから、記述の一貫性を保つのに役立つよ。

**デフォルトの名無しさん** · 2019/08/03(土) 18:07:41.16

元々 min(), max() は非常に古い C時代から #define されているマクロですよね、

std::min(), std::max() と書いても結局マクロ展開されてしまうのでは
ないでしょうか？？？

**デフォルトの名無しさん** · 2019/08/03(土) 18:08:18.92

>>298
でも実際に引っかかったら、何でこういうことする！マイクロソフト死ね！！っておまえも思うはず。

**デフォルトの名無しさん** · 2019/08/03(土) 18:10:37.82

STL の方の min(), max() を使いたい場合は、
(min)(a,b)
(max)(a,b)
でいけるようです。C/C++ の前処理層によるマクロ展開は
マクロ関数名(
という並びが有る場合にのみ展開されますので。

**デフォルトの名無しさん** · 2019/08/03(土) 18:14:26.75

>>302
いや、むしろ逆に、std::min の設計者の方がCの常識を知らない人だな、
と思ってしまいます。
そもそも、min(), max() マクロは、1980年代のC言語の時代から有るよく
知られたものなので、後から登場した C++ 標準ライブラリは、それが
有る場合にでも当然問題なく使えるようにしなくてはならなかったが、
そうなってません。それはどちらに原因があるかは明確です。

**デフォルトの名無しさん** · 2019/08/03(土) 18:19:07.11

>>301
左様

.cppのヘッダファイルをインクルードし終わった以降の適当な場所でおもむろに
#undef min
#undef max

インクルードしたヘッダファイルにマクロ版のmin()、max()に依存したマクロが存在せず、
かつマクロ版のmin()、max()を使わない限りにおいてこれでおk、

**305** · 2019/08/03(土) 18:26:53.75

適用条件訂正orz
正：マクロ版のmin()、max()を使わない限りにおいてこれでおk、

インクルードしたヘッダファイルに含まれるマクロ版のmin()、max()に依存するマクロ経由で
間接的にマクロ版のmin()、max()を使おうとした場合はコンパイルエラーになるからﾜｶﾙ
そうなった場合の処置は知らんが、コンパイルが通ったら>>305の方法で安全なはず

**デフォルトの名無しさん** · 2019/08/03(土) 18:29:09.20

一番安全なのはこれだってboostの長年の結論だから
max BOOST_PREVENT_MACRO_SUBSTITUTION (a,b)

**デフォルトの名無しさん** · 2019/08/03(土) 18:29:45.19

マクロ版 min(), max() が #define されている状態でも、
#define smin (std::min)
#define smax (std::max)
としてしまえば、smin(a,b), smax(a,b) と書くだけで
それぞれ std::min(), std:max()
が使えるでしょう。

**デフォルトの名無しさん** · 2019/08/03(土) 18:32:51.04

>>307
正しいがIQが高すぐる答案

>>308
sminやsmaxという名前が衝突したらどうすんじゃ…

**デフォルトの名無しさん** · 2019/08/03(土) 18:55:02.09

この手の無駄に一般化は大抵バグを引き起こす。

◆QZaw55cn4c · 2019/08/03(土) 19:39:31.49

>>267
ふつうに std::cout << "hello, world!" << std::endl;
と地の文として書いていますが、そういうのは駄目なのですか？

**デフォルトの名無しさん** · 2019/08/03(土) 19:47:04.82

std::を書くと死ぬ人が発狂してるだけなので、std::を普通に書ける人にはしょうもない話

**デフォルトの名無しさん** · 2019/08/03(土) 19:50:41.99

これはVisual Studio 2019のバグだろうか？
C++17想定。Wandboxでは問題なし。

namespace user::math::literals {
constexpr double operator""_deg(long double deg) {
return deg * 3.14 / 180.0;
}
};

struct Test {
template<typename T = double>
constexpr double test(T t) {
using namespace user::math::literals;
return 1.0_deg * 8.0;
}
};

int main(){
}

//error C3688: リテラルサフィックス '_deg' が無効です。リテラル演算子またはリテラル演算子テンプレート 'operator ""_deg' が見つかりません

発生条件はクラス内テンプレート関数でユーザー定義リテラルを含んだ式
return 1.0_deg * 8.0;をreturn 1.0_deg;に変えると問題ない

**デフォルトの名無しさん** · 2019/08/03(土) 19:58:09.36

普通にビルドできたけどプロジェクトのC++言語基準をちゃんとC++17にしたか？

**デフォルトの名無しさん** · 2019/08/03(土) 19:59:17.19

>>288-289, >>291-292
だからベクトルとかでもいきなり衝突するっつってんだろバカチンが
どんだけ経験不足なんだお前らは

**デフォルトの名無しさん** · 2019/08/03(土) 21:04:27.05

using namespace はその名前空間の中の名前を私が責任持って現在の環境に導入しますという宣言だ
中身を把握してないくせにそんな事して事故った奴が全部悪いんであって、使われた側には責任はない
stdとて例外ではない

**デフォルトの名無しさん** · 2019/08/03(土) 21:27:39.99

>>316
使われた側の未来のふるまいまで予測してnamespaceの中身を理解などしていられない件について：

namespaceの正しい使われ方の下では、aというnamespaceに将来どんな名前が追加されようとも
bというnamespaceの名前とは衝突しないはずである
ところがaとbをusing namespaceしてしまったが最後、誰にも責任が持てないカオスが訪れる

これはnamespaceが無かったころの言語に先祖返りするだけではなく、より悪い状況を招くことに注意。
namespaceの利用によって、open、close、copy、find、vector、list、string、.....といった「自然な」名前がいっぱい使用されるからである。

namespaceは崇高だが、using namespaceはそうされることを意図されたnamespace意外には邪悪すぐる

**313** · 2019/08/03(土) 21:32:17.54

>>314
再インストールしなおしてプロジェクトの設定をC++17なのを確認してもエラーが出た
うちの環境だけか・・・

Visual Studio 2019 Community Version 16.2.0

**デフォルトの名無しさん** · 2019/08/03(土) 21:38:58.27

>>318
こっちも16.2.0で、ワークロードは「C++によるデスクトップ開発」のオプションに全部チェック
他はQtツール入れただけ

**デフォルトの名無しさん** · 2019/08/03(土) 21:51:26.72

>>317
完全に同意
そういう事態が起きないと確信できるほど中身を理解してるnamespaceか、起きても問題ないほど狭いスコープか
そのどちらかでしか使ってはいけないものだ
using namespaceというのはそういう乱暴な機能

**317** · 2019/08/03(土) 21:51:59.64

訂正；
語： namespaceは崇高だが
正： namespaceは崇高かもしれないが

>>316みたいな無根拠で実害のある精神論に後退するぐらいなら、
namespaceで修飾するかわりに接頭辞をつけた名前を使うという>>228な方策も現実の選択肢足りえる
（>>228がネットをgrep my_fooして見つからなかったのは不幸な事故だが

**デフォルトの名無しさん** · 2019/08/03(土) 21:54:29.31

>>321
同意した直後に正反対のこと言うのやめて？
316のどの辺が精神論で有害なのさ
C++だけの話でもなくて、pythonのimport * がカスと言われてるのと本質的に同じだろ

**デフォルトの名無しさん** · 2019/08/03(土) 22:06:21.81

>>316の精神論にはある意味同意するけどな
(ヘッダでの名前空間取り込みも、ある名前空間に別の名前空間を取り込む場合など、合理性があるなら設計上の選択の一つと言えるし
その辺は設計者の責任だと思う)

あと>>298, >>301はバカチンじゃなかった、すまんかった

**デフォルトの名無しさん** · 2019/08/03(土) 22:09:28.81

using namespaceの話はも止めたら？
使いたい人は使えばいいし
使いたくない人は使わなければいい
でいいじゃん
大した問題じゃないだろ

**デフォルトの名無しさん** · 2019/08/04(日) 00:06:21.11

ダメに決まってるだろｗ
Coding Standardの話なのにｗ

**デフォルトの名無しさん** · 2019/08/04(日) 01:17:09.87

どうでもいいだろ
C++のようなアレな言語を扱う上では些細な事さ

**デフォルトの名無しさん** · 2019/08/04(日) 01:20:42.30

そもそもプログラミングは間違ったことを信じている人がはっきり損をする世界
(ことあるごとにエラーが多発するとか作成に余分な時間がかかるとか完成品の質が悪いとかの話で）
リアルで誰かと作業するならともかく
ネットの向こうの間違ってる誰かなんて放っておいても損を勝手に積み立てて自らつぶれていくものだ

**デフォルトの名無しさん** · 2019/08/04(日) 01:21:14.60

おれはね
C++はね
正しく扱うのに本当にコツのいる言語だと思うんよ
そんな中using namespaceは割とどうでも良いよね
俺は使わない派だが、使いたければ使えばって感じ

**デフォルトの名無しさん** · 2019/08/04(日) 01:59:42.19

確かにどうでもいいな
プルリクで簡単に見つかるから
というかコンパイルや静的解析でエラーにする方法はないかな

**デフォルトの名無しさん** · 2019/08/04(日) 09:37:37.80

>>327
正確にはそれをリカバーする人だがな。
バカはリカバーされて成り立ってることすら理解せず同じことを繰り返す。

**デフォルトの名無しさん** · 2019/08/04(日) 18:06:02.62

min(), max() マクロのような件は別として、標準的なライブラリであるところの
std::系の名前は、using namespace std; してもそんなに問題ないということは
無いんですか？？？

他のライブラリの名前空間 XXX も同時に using namespace XXX;　した場合に
もし衝突が起きる場合は、using namespace XXX; だけはしないようにすれば、
特に問題ないような気がします。実際やってみたことが無いので経験者の意見を
聞いてみたいです。

**デフォルトの名無しさん** · 2019/08/04(日) 18:48:22.76

個人の趣味プログラミングならご自由に
仕事ならコーディング規約にあわせる
コーディング規約作る立場なら、チームにバカが混ざってる前提で非属人的になるようにルールを設ける
で経験を積めば積むほど自分がバカであることが身にしみてわかる
そういうことだよ

**デフォルトの名無しさん** · 2019/08/04(日) 18:54:59.65

>>331
別に衝突しなくても問題は起こる。
using namespace stdで書いたコードをヘッダーのインライン関数に持って行く必要が出た場合とか、

using namespace std；
#inlucde "...."

となってしまっていてたまたま動いていたコードを、別の箇所でincludeしたときにエラーがでまくるとか。

**デフォルトの名無しさん** · 2019/08/04(日) 19:00:40.18

>>333
ほとんど言いがかりレベルw

**デフォルトの名無しさん** · 2019/08/04(日) 19:02:23.99

std::くらい書けで終わる話をいつまで続けるつもりだ

**デフォルトの名無しさん** · 2019/08/04(日) 19:04:24.66

>>335
10万行とかのソースでそれをやりますか？

**デフォルトの名無しさん** · 2019/08/04(日) 19:06:21.58

>>336
ところどころについてたり、ついてなかったりするくらいなら、最初からstd::つける方がはるかにマシ。

**デフォルトの名無しさん** · 2019/08/04(日) 19:06:25.70

やるよ

**デフォルトの名無しさん** · 2019/08/04(日) 19:09:16.58

普通頻繁に使うライブラリをusingするだけで、名前空間ごとはやらんだろ
chrono使う時はたまにやるけど

**デフォルトの名無しさん** · 2019/08/04(日) 20:26:05.66

ていうかstd::程度を書くのが面倒な人はC++向いてない

**デフォルトの名無しさん** · 2019/08/04(日) 20:49:37.11

size_tにだけ頑なにstd付けない人いるんですがなにか理由あるんですか

**デフォルトの名無しさん** · 2019/08/04(日) 20:52:21.46

>>336
１ファイルが10万行じゃないだろ（１ファイルならそこから直せw）

**デフォルトの名無しさん** · 2019/08/04(日) 20:54:10.96

>>341
size_t は大昔からあるのと明らかに型名っぽい名前なのでわざわざバッティングさせる奴もいないからじゃね？

**デフォルトの名無しさん** · 2019/08/04(日) 21:52:28.11

>>341
size_tはC言語時代から存在してるから、もともとnamespace関係なく使える

**デフォルトの名無しさん** · 2019/08/05(月) 00:32:36.26

むしろstdにsize_tあったんだくらいの認識

**デフォルトの名無しさん** · 2019/08/05(月) 02:02:36.01

おれも知らんかったなまぁ言われてみればたしかにそうだなsize_tってネィムスペィス上でも定義されてたのか今度から一貫性のためにstd::つけとこうかな
まぁ、editorのちょい設定いじるだけなんだがな(´・ω・｀)

**デフォルトの名無しさん** · 2019/08/05(月) 12:35:07.05

>>340
そうでもない。

**デフォルトの名無しさん** · 2019/08/05(月) 14:11:04.57

>>342
1ファイルの行数は関係有りません。
要は大きなプログラムを書いているとき、string で済むところを
全ての箇所で std::string と書くのかということです。
void func(std::string &somename, int a, int b) {
std::string aaa;
aaa = somename + "abc";
}
struct Txxx {
　std::string　name1;
　std::string　name2;
　・・・・
};
↑のようにタイピングするのは余り賢いやり方だとは思えません。

**デフォルトの名無しさん** · 2019/08/05(月) 14:19:44.18

そんなに面倒ならusing S = std::stringでもすればいいじゃん

**デフォルトの名無しさん** · 2019/08/05(月) 14:24:57.77

過度に賢く振る舞おうとして滑ってるパターン
それくらい普通に書けばいいじゃん

**デフォルトの名無しさん** · 2019/08/05(月) 14:27:04.00

こういう奴って馬鹿丁寧に一文字ずつ全部打ってんのかね
補完って機能の概念がない世界に住んでんのかしら

**デフォルトの名無しさん** · 2019/08/05(月) 14:51:04.49

>>348ってジョルノっぽいよな

**デフォルトの名無しさん** · 2019/08/05(月) 20:01:38.61

>>348
> 1ファイルの行数は関係有りません。
> 要は大きなプログラムを書いているとき、string で済むところを
> 全ての箇所で std::string と書くのかということです。
俺は書く。

> ↑のようにタイピングするのは余り賢いやり方だとは思えません。
お前の感想はどうでもいい

**デフォルトの名無しさん** · 2019/08/05(月) 22:09:13.72

>>348
高々数文字のタイピングに拘って名前空間のメリットが理解できないという主張を繰り返すお前さんの行動は、余り賢いやり方とは思えません。

**デフォルトの名無しさん** · 2019/08/05(月) 22:10:29.33

>>348
だから何のために名前空間があるのかググれよ
別に好きにやればいいけどお前がいつもstd名前空間取り込んで便利だと思ってるのは
標準ライブラリしか使ってないからだ

**デフォルトの名無しさん** · 2019/08/05(月) 22:17:59.20

無駄だと思うならtypedefやusingすりゃいいじゃないか
そもそもstringって名前長すぎだろ

**デフォルトの名無しさん** · 2019/08/05(月) 22:26:34.39

usingである程度の広さのスコープでやるんが正解だろ。
まあこのある程度の広さってのが人によってだいぶ違うだろうが。

**デフォルトの名無しさん** · 2019/08/05(月) 22:37:46.60

少なくともstdは普通using namespaceしないよね
でかすぎる
最近良くやるのは
namespace fs=std::filesystem;
だな

まあこれもヘッダで使うなら独自namespaceに入れてからだが

**デフォルトの名無しさん** · 2019/08/05(月) 23:33:53.82

using namespace std;をグローバルなスコープでやってしまうと
ソースコードを他に持って行ったとき困る
fooをstd::fooに変換するのはfooの種類が100台になると並みのエディタの置換機能では手間的にアウト
一方std::をとるのなら簡単にできる
std::をつけるのは将来への投資といえる

**デフォルトの名無しさん** · 2019/08/07(水) 02:10:18.89

初心者除ける、上級勘違い中級者こそ、出て行ってくれないかな。
本当の上級者は、プログラミング初めての人でも、優しくあたってくれますよ。

**デフォルトの名無しさん** · 2019/08/07(水) 02:48:46.85

>>360=>>348？

**360** · 2019/08/07(水) 03:17:50.31

>>360 = not(>>348)
ですが。
証明方法は無いですから、わかりませんけどね。

**360** · 2019/08/07(水) 03:53:56.72

>>342
各1万行30ファイルは、セーフですか？

**デフォルトの名無しさん** · 2019/08/07(水) 08:04:40.03

入れ子となったクラスの内側のクラスから外側のクラスのprivateメンバにアクセスできるという
内側のクラスの特権はJavaやC#と同じくC++にもあるから、これを使って大規模なStateパターンでも書いた日には
ソースコードの行数も大規模にならざるおえない
このとき上記3言語の中で唯一大規模にならずに済むのはクラスの分割定義が可能なC#だけ

**デフォルトの名無しさん** · 2019/08/07(水) 09:17:55.92

まず日本語を勉強しましょう

**デフォルトの名無しさん** · 2019/08/07(水) 09:31:41.35

昨今のプログラミング用語における入れ子は界隈に限らず日常的に使われているが
プログラミング業界では特に再帰的構造を指す場合にも多く使われる

そこに非常に現代的な特殊用語たる「出し子」が加わると
一般人は入れ子と出し子が対になっていると思い込む

**デフォルトの名無しさん** · 2019/08/07(水) 09:45:33.66

入れ子の内側のクラスは別ファイルに定義できる

**デフォルトの名無しさん** · 2019/08/07(水) 09:55:09.68

好きなだけわけてincludeすればいいじやん

**デフォルトの名無しさん** · 2019/08/07(水) 23:36:21.14

スコープにあった変数名の長さにするべきとかそういうのお前らは習ってねーの？

**デフォルトの名無しさん** · 2019/08/07(水) 23:50:58.34

そういう感覚的なルールいらない
チェックできないルールはなくていい

**デフォルトの名無しさん** · 2019/08/08(木) 00:01:50.09

>>370
感覚的な部分を必要とすべきでないなら全てアセンブラで書けばか。

**デフォルトの名無しさん** · 2019/08/08(木) 03:03:18.83

>>370
チェック出来るルールに完璧に沿って書けてるボクちゃん偉い！エッヘン！
ってこと？
ユーザーからしたらクソの役にも立たねーよそれ

**デフォルトの名無しさん** · 2019/08/08(木) 03:51:27.57

errnoに謝罪しる

**デフォルトの名無しさん** · 2019/08/08(木) 05:46:38.89

>>367
1行で2クラス以上定義しないという原則を守る限り、30億状態あったら外側のクラスはどうがんばっても30億行未満では書けない
この場合でも30億行未満で書けるのは分割定義できる言語だけ
また、内側のクラスを使わない普通のStateパターンなら30億ファイルに分割してかけばだいたいおk
（1状態から遷移し得る状態の数による。30億状態のどれにでも遷移しえる状態、
　みたいな極端なやつはさすがに遷移先状態クラスの#includeで30億行になるが

>>368
おk

**デフォルトの名無しさん** · 2019/08/08(木) 06:53:52.07

頭悪そう

**デフォルトの名無しさん** · 2019/08/08(木) 10:31:27.94

それは設計の問題でしょ
30億通りのstateパターンで設計する方が悪い
言語の問題じゃあないな
あり得ないヘンな例を持ち出してdisる詐欺師の方法だ

**デフォルトの名無しさん** · 2019/08/08(木) 21:15:10.76

>>359
ファイル単位でそのまま使えや
コピペして改変部分があるとか当たり前のこと言うなよwwww

**デフォルトの名無しさん** · 2019/08/08(木) 22:58:59.35

コンパイル時に発覚する程度のエラーなら許容範囲でしょ。

**デフォルトの名無しさん** · 2019/08/09(金) 00:11:55.59

c++で想定外の場合にエラーメッセージとその行数を出して終了させたいのですが、
どのようにしたらできますか？
下記のようにしてもexitした行数が出ません。。

::fprintf(stderr, "error.\n");
exit 1;

perlのdie()のようなものをイメージしています。

**デフォルトの名無しさん** · 2019/08/09(金) 00:39:22.71

::fprintf(stderr, "error. (line: \d)\n", __LINE__);
とか

**デフォルトの名無しさん** · 2019/08/09(金) 22:56:01.92

丁寧にエラーメッセージ出すよりデバッガでバックトレースかけた方が早かったりするのは内緒

**デフォルトの名無しさん** · 2019/08/09(金) 23:44:34.34

右辺値参照ってconst参照という認識でOKですか？

**デフォルトの名無しさん** · 2019/08/10(土) 01:07:05.35

>>382
moveで中身を奪い取るからconstじゃだめよ。

**デフォルトの名無しさん** · 2019/08/10(土) 06:27:08.55

>>381
そりゃデバッガ使える状況ならその方が速いことは誰でも知ってるだろw

**379** · 2019/08/10(土) 09:48:42.90

>>380
その方法で目的の動作ができました。
行の最後にexit入れたら一行でかけて良さげな感じです。
ありがとうございました。
::fprintf(stderr, "error. (line: \d)\n", __LINE__); exit(0)

>>381,384
バックトレースというものを知らなかったのでググりました。
色々なものがあるようですが、gdbの下記程度の使い方なら自分でもできそうなので
これをちょっとづつ使ってみようと思います。

ttps://rat.cis.k.hosei.ac.jp/article/devel/debugongccgdb1.html

**デフォルトの名無しさん** · 2019/08/10(土) 15:57:01.40

ｸﾞｸﾞってもなかなか出てこないが__LINE__はlong型だったと思った！

**デフォルトの名無しさん** · 2019/08/10(土) 16:00:35.87

>>386
intじゃないの？
まあクロスの場合開発環境側のintな気もするが

**デフォルトの名無しさん** · 2019/08/10(土) 16:25:20.56

intでダメなファイルとかそもそもコンパイルできねーだろ。

**デフォルトの名無しさん** · 2019/08/10(土) 16:36:59.44

2GBの¥nの後にソースかいてみるとわかるかなw

**デフォルトの名無しさん** · 2019/08/10(土) 16:48:09.53

>>387
> まあクロスの場合開発環境側のintな気もするが
そんなアホなw

**デフォルトの名無しさん** · 2019/08/10(土) 16:57:47.58

いや、多分そこまで考えてないから、コンパイラ上ではintもしくはsize_tで
マクロ展開時は文字列化して接尾の型指定とかつけないだろ

勝手につけられると逆に困るし

**デフォルトの名無しさん** · 2019/08/10(土) 17:01:16.99

int型はターゲットアーキテクチャーで一番自然な型というのが本来の意味なのでソースコードの最大行数と関係する理由が無い
C++の最新規格ではどうなったかわからんが、longは規格上32 bit固定なのに対してintは16 bitのアーキテクチャーが有り得るはず

**デフォルトの名無しさん** · 2019/08/10(土) 17:02:52.50

32bit固定？

**デフォルトの名無しさん** · 2019/08/10(土) 17:06:31.95

longが32bit固定なシステムは64bitでは異端じゃね
まあwindowsはLLP64っぽいが