C++相談室 part149

**デフォルトの名無しさん** · 2020/02/18(火) 06:19:41.54

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

前スレ
C++相談室 part148
https://mevius.5ch.net/test/read.cgi/tech/1580471646/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://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/ (日本語)

**デフォルトの名無しさん** · 2020/03/05(木) 16:39:10.51

>>557
エラーってのがコンパイルエラーなら"\\s"とかR"(\s)"にする、実行時ならコンパイラのバージョンを上げる、でどうかな

**デフォルトの名無しさん** · 2020/03/05(木) 16:55:10.20

その理論だとc++もcでかかれたコード呼ぶだろ
ライブラリがc++のしか用意されてないとかそういう話かと思った

**デフォルトの名無しさん** · 2020/03/05(木) 16:58:12.34

>>609
Cから呼び出されるC++関数を書くにはC++側でCに合わせる必要がある
そういうのをCがC++に依存したというのはちょっと無理あるだろ

**デフォルトの名無しさん** · 2020/03/05(木) 17:08:17.82

>>609
時代とか大口叩いたくせに後で矮小化すんなよ、くそださい

その例でいうと中の実装言語が何かはc側は関知してないだろ
それはcがc++に依存とは言わない
その関数が提供する機能に依存してるという特定の事例にすぎない
だいたいABIは事実上cベースしかない
c++がcのふりしてるんだよ

**デフォルトの名無しさん** · 2020/03/05(木) 17:11:40.19

名前修飾の法則は規格化されないんかね

**デフォルトの名無しさん** · 2020/03/05(木) 17:16:22.18

>>609
・Windowsの場合、C++のプログラムは最終的には、Win32を呼び出しているが、　Win32は、記述言語もインターフェースもC。
・Linuxでも同様。LinuxのKernel本体はCで書かれている。
　GTKやKDE, Qt は原則 C++ だが、最終的には Cで書かれ、かつ、Cのインターフェース　を持つ System Call が呼び出される。

どちらも
C++ ---> C
の流れ。基礎部分やバックエンド部分は C になることが多い。
逆に C から C++ を呼び出すことは稀。
だから、事実とは逆。

**デフォルトの名無しさん** · 2020/03/05(木) 17:19:27.49

>>614
gccのマングリング化法は資料がある。
vc++も解析資料がある。
clangはgccのマングリング化法を使っている。
しかし、gccのマングリング化法を使うと、gnu/FSF/GPL 信者から
「真似をした、ずるい」と文句を言われたり、証拠もないのに
「勝手にソースを使った」などと風評被害があるに決まってるから
使いづらい。

**デフォルトの名無しさん** · 2020/03/05(木) 17:19:36.10

windowsはc++と混在してたはずよ
win32だけは違うとかあるかも試練が

**デフォルトの名無しさん** · 2020/03/05(木) 17:21:34.22

>>617
・GDI+ は C++ インターフェースだが、内部では Cの API を呼び出す仕組みになっている。
・DirectXも C++ インターフェースではあるが、COMだから Cからも呼び出せる。

**デフォルトの名無しさん** · 2020/03/05(木) 17:23:03.34

>>617
Win32は、GDI+以外はほぼ全て Cのはず。
MFCは、Win32をラッピングしているから、
C++(フロントエンド) ---> C(バックエンド)
の流れ。

**デフォルトの名無しさん** · 2020/03/05(木) 17:24:33.30

こいつらextern "C"についてさえまともに理解してなさげ。。

**デフォルトの名無しさん** · 2020/03/05(木) 17:37:41.82

>>608
Cだけだと、少し不便なだけで完結する。
むしろ、C++ だけではスクリプト言語的なことしかできないので、完結とはいいがたい。

このスレは新しい言語である C++ をネットで学んだだけで、基礎となる C の部分が学べてない人が多いようだ。
ネットだと新しく入った機能や新しい記事だけが上位に来てしまうから、新しいことしか知らない人が書いたページだけしか見る機会がなくなってしまうが、それだと悪循環になり、古くてももっと良いものがあっても学べない。

**デフォルトの名無しさん** · 2020/03/05(木) 17:47:46.22

C++を使いこなせない老害がCに固執してると見た。

**デフォルトの名無しさん** · 2020/03/05(木) 17:48:19.67

このスレに限らず、検索してても初心者が過去の遺物だのオワコンだの死すべしだの
口の悪い厨二病発言するだけで上級者になったつもりのクソブログばっかり上に出るからなぁ
ABIというかマングリングとかバイナリ周りの統一に関しては、C++はいつまで経ってもCの後塵を拝する形になってるんだが、何年かC++やっててもその程度の欠点にも気付かない奴ってのは
要するにそういうことだろ・・・

**デフォルトの名無しさん** · 2020/03/05(木) 17:52:51.49

Cで出来ることはC++でもできる。
C++で出来ることがCには出来ない。
Cは老害。

**デフォルトの名無しさん** · 2020/03/05(木) 17:53:01.97

あんま調べてないけどモジュールも多分ソースコードレベルでのヘッダ依存の解消のためであって
ライブラリファイルみたいな外部に出す方法はまだまだ来ないだろうし

**デフォルトの名無しさん** · 2020/03/05(木) 18:13:53.71

>>624
C++はCのサブセットなので、当然それは正しいことなのだが、
このスレの人達は、「C++のうちからCの部分を除外した部分だけ」
をC++だと言い張るので異なるのだ。

**デフォルトの名無しさん** · 2020/03/05(木) 18:17:40.92

>>622
このスレで、Cを使うのを朗がい呼ばわりしている人達を見る限り、単にC++に加わった新機能を解説したサイトをネットで学んだだけで古いC++やCを知らないだけに見える。
確かに、Cより優れているC++の部分を使わないのは老害だ。
しかし、C++より優れているCの部分を使わないのは、単にCを知らないだけ。

**デフォルトの名無しさん** · 2020/03/05(木) 18:22:08.41

>>624
話をそらすな
cがc++に依存してるとか言い出したから
総ツッコミがはいったんだろが
自分で言い出したこと忘れたのか？
それ老害の先の症状だぞ

**デフォルトの名無しさん** · 2020/03/05(木) 18:28:00.98

c++より優れているcの機能って言うほど無いだろ
printfとiostreamにしたって好みによるとしか

まあ次の標準に来るから使えるならfmt使っとけ
明らかに上記のどちらよりも優れているから

**デフォルトの名無しさん** · 2020/03/05(木) 18:35:08.33

>>629
fmtは{}が直接使えないからだめらしいぞ
しかしprintfの%は気にしないみたいだぞ

**デフォルトの名無しさん** · 2020/03/05(木) 19:01:36.23

>>615
インターフェースとか言い出したらWin32APIはPascalやでw

**デフォルトの名無しさん** · 2020/03/05(木) 19:07:31.57

>>629
昔BASICが人気があったころ、print と print using の二種類有り、
cout は前者の、printf は後者の流儀と同じである。
初心者は、print から使い始め、慣れてくると print using を使うと言われていた。
後者はとっつきにくいが独特の便利さがあるとされた。
つまり、BASICは、cout 方式も使えたのに、敢えて printf 方式も用意したのだ。
このスレやネットには初心者が多いので、覚えることの少ない coutが好まれているだけ。

なぜcoutが問題なのかと言うと、書く量が多くなることと、見た目的に結果を予想しづらくなるからだ。
printf( "(x, y, z, w)=(%d, %d, %d, %d)\n", x, y, z, w );
で済む所が、coutだと、
cout << "(x, y, z, w)=(" << x << ", " << y << ", " << z << ", " << std::eol;
などとなってしまい、打ち込みにくいだけでなく、結果がどうなるかも直感的に分かりにくい。
出力にカンマや空白を入れるのが難しいのだ。
さらに、これを16進に直したい場合、printf なら、
printf( "(x, y, z, w)=(%X, %X, %X, %X)\n", x, y, z, w );
と僅かな修正だけで済む。さらに、左に0を埋めた8桁の16進数に直したい場合には、
printf( "(x, y, z, w)=(%08X, %08X, %08X, %08X)\n", x, y, z, w );
で済むし、表示に0xを含めたい場合には、
printf( "(x, y, z, w)=(0x%08X, 0x%08X, 0x%08X, 0x%08X)\n", x, y, z, w );
で済む。これで、0x0000ABCD などと表示できる。さらに、0x0000abcd と表示したい場合は、
printf( "(x, y, z, w)=(0x%08x, 0x%08x, 0x%08x, 0x%08x)\n", x, y, z, w );
で済む。どのような表示形式にしても、コンパクトで見易い。
一方、coutでこれと同じようにしようと思ったら、見易くするためには5行くらいの長さになってしまうだろう。
それでもこのように美しい見た目にはならない。

昔のBASICのprint文にも同じような問題点がおきたから、print using が生み出されたのだ。
それを知らないで、coutがprintfより優れていると思ったら大間違いだ。

**デフォルトの名無しさん** · 2020/03/05(木) 19:15:26.67

>>632
誤: cout << "(x, y, z, w)=(" << x << ", " << y << ", " << z << ", " << std::eol;
正: cout << "(x, y, z, w)=(" << x << ", " << y << ", " << z << ", " << w << ")" << std::eol;

**デフォルトの名無しさん** · 2020/03/05(木) 19:18:12.66

>>633
もっと言えば、この cout は、古いN88-BASIC言語より記述量が多い。
<< を使うからだ。N88-BASIC は、<< の部分が ; となる。
N88-BASIC なら、
print "(x, y, z, w)=("; x ; ", " ; y ; ", " ; z ; ", " ; w ; ")"

**デフォルトの名無しさん** · 2020/03/05(木) 19:22:17.12

1. N88-BASIC
print "(x, y, z, w)=("; x ; ", " ; y ; ", " ; z ; ", " ; w ; ")"
2. C
printf( "(x, y, z, w)=(%d, %d, %d, %d)\n", x, y, z, w );
3. C++
cout << "(x, y, z, w)=(" << x << ", " << y << ", " << z << ", " << w << ")" << std::eol;

C++ が最も汚く、書きづらい。

N88-BASIC ---> C の printf()　　// 進化と言えよう。
N88-BASIC ---> C++ の cout　　// 後退のように見える。

cout は、classのパワーを例示するために用意されたと聞いている。
もともと実用性は無かったのに、それを知らない人達が使うようになってしまったのが現状である。

**デフォルトの名無しさん** · 2020/03/05(木) 19:25:02.59

printfとcoutの議論はgoogleでもやってたな。
型安全と見やすさのどちらが重要かみたいなやつ。
型安全にこだわるやつはたいてい現実見てないなってのが良くわかる例になってる。

**デフォルトの名無しさん** · 2020/03/05(木) 19:32:35.95

>>635
一見、printf と cout で記述のしやすさに大差ないと思う人もいるかもしれないが、実際に入れてみると coutの記述のしにくさは異常なほどである。
特に問題なのが、後から "," の後ろに空白を入れたくなったりしたときの修正のしにくさである。
printf の場合は、最初の書式付文字列の中にまとまっているので、非常に修正し易く、数秒で修正できてしまう。
ところが cout の場合は、全体に散らばっているので修正箇所を見出すのが非常に難しく、間違いの元になり易い。
全部修正したつもりでも、いくつか入力し忘れていたり、"・・・" の中に入れなければならない所を、"・・・" の直後の「地の文」に入れてしまったりする羽目になる。
また、よくあるのは、" や << を入れ忘れたりすることである。

**デフォルトの名無しさん** · 2020/03/05(木) 19:37:42.73

>>637
coutの場合に、よくあるのが、" の内側と外側の混乱である。
"で文字列を始めたり終えたり何度も繰り返すので、目が混乱して
どっちがどっちか分からなくなる。
コンパイルしたとき、文字列が開きっぱなしになって、酷いときには
ファイルの最後までコンパイルしてしまって、エラーがどこで起きたのかさえ
分からない最悪の間違いを犯してしまう。
だから、perl,ruby,pythonでは、
"#{変数名}"
のような記述が発明された。
これは、printf を進化させたものといえよう。
しかし、coutは退化である。

**デフォルトの名無しさん** · 2020/03/05(木) 19:39:40.38

なんでこの子価値の無い長文書いてしまうん？

**デフォルトの名無しさん** · 2020/03/05(木) 19:39:40.91

>>638
エディタくらいまともなやつ使え

**デフォルトの名無しさん** · 2020/03/05(木) 19:41:36.95

>>640
そんな問題ではない。

**デフォルトの名無しさん** · 2020/03/05(木) 19:47:23.03

どんなクラスのオブジェクトでもoperator<<さえ定義すれば吐き出せるのがiostreamのメリットよ
クラスは組込型のように振る舞えるべきだっていうオブジェクト指向の理想のために必要だったんだよ
安全な後世から後出しジャンケンで叩くのはフェアじゃないよ

それはそれとしてiostreamは使いづらいクソだという意見は否定しない

**デフォルトの名無しさん** · 2020/03/05(木) 19:48:11.76

>>641
そんな既知の話ここで長々と書かんでいいから
自分のブログでやれ
ここにはリンクだけ張りに来い

**デフォルトの名無しさん** · 2020/03/05(木) 20:14:15.18

>>639
中学校が休校になって暇を持て余してるんだろう

**デフォルトの名無しさん** · 2020/03/05(木) 20:37:19.93

>>565
ようやく来たかー。
望んていた形そのものだわ

ID:HyVcGvBE
スレによって態度違いすぎw

**デフォルトの名無しさん** · 2020/03/05(木) 20:38:33.78

>>636
両立できそうなところへ、どちらかが優れているという結論を目指すという
前提がそもそも間違っている不毛な議論だと思うが

**デフォルトの名無しさん** · 2020/03/05(木) 20:45:44.87

>>646
統一したいという輩がいるんだからどっちでもいいとしても
少なくともその輩を黙らす必要はあるだろう。
まあlinusの言う通り馬鹿をプロジェクトに入れないっていうのがやっぱり正解なんだが。

◆QZaw55cn4c · 2020/03/05(木) 20:52:50.83

>>574
＞C++で書かれたAPIをCから呼び出す。
extern "C"　
でもしないかぎり、あり得ないのでは？this とかマングリングとかどうするの？

**デフォルトの名無しさん** · 2020/03/05(木) 20:53:54.02

>>647
日本語でおｋ

◆QZaw55cn4c · 2020/03/05(木) 20:54:26.10

>>583
＞マジでプロでもフリーソフト開発してるアマチュアでもいいから実際の開発に使ってる人(と初心者)専用の相談スレがあった方がいいかもな

ここがそうだと思います
そう思えないのであれば、それはスルー力が足りないかと

**デフォルトの名無しさん** · 2020/03/05(木) 20:54:47.02

なんだ日本語読めないのか。。そりゃ失礼。

**デフォルトの名無しさん** · 2020/03/05(木) 20:55:46.47

>>648
関数ポインタに生アドレスを渡すとかｗ
GetProcAddressみたいに
QueryInterfaceと似てるけど、より面倒くさいね

◆QZaw55cn4c · 2020/03/05(木) 20:56:14.98

>>608
そうでもないですよ
ほかの言語から自由に呼び出せるようにするため、汎用ライブラリをわざわざ C で書いたりするでしょう？

◆QZaw55cn4c · 2020/03/05(木) 20:57:13.05

>>612
私は extern "C" くらいしか思いつかないですね…

◆QZaw55cn4c · 2020/03/05(木) 20:58:06.21

>>615
＞逆に C から C++ を呼び出すことは稀
というか皆無といういうべきでしょう、extern "C" でもしない限り

◆QZaw55cn4c · 2020/03/05(木) 21:00:50.35

>>624
＞Cで出来ることはC++でもできる。

C++ でできないこともあります
他言語から自由に呼び出せるライブラリを書くときは C で書くしかないでしょうね…
extern "C" というのは、もはや C で書いているのと一緒…

**デフォルトの名無しさん** · 2020/03/05(木) 21:03:38.79

>>656
一緒ではないだろ
APIはcで中身はc++ってのは多い
実際おれもそうしてる
c++使いたいからな

**デフォルトの名無しさん** · 2020/03/05(木) 21:07:33.42

>>654
あーそうなの？
テンプレートとかムブコンとかうっすらぱーｗ

**デフォルトの名無しさん** · 2020/03/05(木) 21:29:47.60

>>650
＞ここがそうだと思います
本気でそう思えるなら自分のことしか見えてないんだろうな
あといちいち分けてレスするな

**デフォルトの名無しさん** · 2020/03/05(木) 21:57:41.56

昔BeOSっていう純粋にC++で書かれたOSがあったけど、コンパイラやAPIのバージョンアップで
マングリング規則やクラスのエクスポート時の互換性が無くなって、
過去のアプリが全く動かなくなったりした(こういうのはBeOS限定の話ではないけど

クラスライブラリの互換性をどうにかするために、MSの場合はvtblが先頭にあることを利用したり
余分な引数を追加したりしてコンパイラ間の互換や後のバージョンアップに対応できるようにしたけど
そもそもvtblを先頭に置くのは規格で決まってるわけではない

上の方でUBUB言ってた人達はこういうのどう思うんだろうね

**デフォルトの名無しさん** · 2020/03/05(木) 22:17:26.19

>>610

コンパイル時にエラーが出ていました。
下記でコンパイル通りました。
ありがとうございます。

std::regex re( R"(^\s*(^\S+)\s+(\S+))")

ダブルクォーテーションの内側を全部丸括弧でくくればよくて、そのカッコは
下記の　results[1]　にはセットされないんですね。
知らないとちょっと戸惑いそうだ。

std::regex_search(word, results, re)

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/05(木) 22:19:16.64

>>660
OS の製作元と同じマイクロソフトが提供している VS で COM を作る分には別にいいんじゃないの。
移植性を考える必要もないし。

しかし、こういう変な形でなければ C++ で作ったバイナリは運用しづらいということの証明にもなってはいるよな。

**デフォルトの名無しさん** · 2020/03/05(木) 22:24:01.52

>>660
c++でUBでも処理系が定義してる範囲で、
かつその処理系に依存していいなら問題ないだろ
そのへん区別しろ

**デフォルトの名無しさん** · 2020/03/05(木) 22:33:54.16

>>662
いやVS限定ではないはず、他のコンパイラからでも使えるでしょ

>>663
問題かどうかではなくて、そういうトリックを使わなければ達成できない目的があったときどうするの？みたいな話
と、バイナリ関係の規格が全然足りてないよね、という話

**デフォルトの名無しさん** · 2020/03/05(木) 22:49:02.33

>>664
わからんやっちゃな
処理系が決めてる範囲でやるんだよ
実際それでなんとかしてるだろ？
テンプレートでいきってる標準化の連中がバイナリ境界に無関心なのはカスだと思うけどな

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/05(木) 22:55:28.04

>>664
まあ実際には VS に合わせてるコンパイラが多いのは知ってる。
gcc とかもデフォルトではビットフィールドの割り当て順序が違ってるんだが、
VS に合わせるオプションとかが用意されてたりもするくらいには Windows では VS が基準。

ただやっぱりそこには「検証の手間」が発生するよ。
VS でやる分にはマイクロソフト自身がやってんだから疑いが入る余地はない、
確実に問題はないという意味で VS に限定して問題ないと表現した。

ひょっとしたら VS 以外のコンパイラでもドキュメントをよく見たらどっかに書いてあるのかもしれんけど、
少なくとも私はそれを確認したことはない。

---

バイナリの規格ってのは「せめて Windows 内では」とかいうレベルのこと？
違うアーキテクチャで統一できないのは仕方ないけど、
主要なアーキテクチャ/OS内ではっきりした規格を定めれていないのはなんでできないんかなぁと思わなくはないな。

うーん、でも Linux なんかだと GCC のマングルが実質的な規格そのものみたいな感じもするし、
Windows だと結局は VS に合わせるしかないんだからそれが規格みたいなもんじゃね？
その規格 (的なもの) に合わせられていないのは単純にやる機運が起こってないだけで。

**デフォルトの名無しさん** · 2020/03/05(木) 23:15:47.07

>>666
マングリングは政治的な問題も絡むのか・・

すまんバイナリって言ったから誤解させたかもしれん、インターフェースの話ね
クラスのエクスポートとか回り道せずに出来るようにならないと、上でも言われてる通りいつまでもCのスタイルに合わせざるを得ない

てかvtblを先頭に置かないコンパイラを知らんのだけど、あったとして合理的な理由とかあるんだろうか

**デフォルトの名無しさん** · 2020/03/05(木) 23:18:24.65

どんな状況でも動くことを考えたらCの仕様に行き着く

**デフォルトの名無しさん** · 2020/03/06(金) 00:04:56.44

iostreamの使いづらさはboost::formatで大体解決する
ってかformat指定をワザワザprintfから改悪してstreamオブジェクトに余計な状態保持をさせてしまったところ

std::vector<bool>が典型的だけど、初期の頃に考えられた言語デモンストレーションの為に、実用性に疑問の残るおかしな仕様が標準化されちゃっているところがあるよね

**デフォルトの名無しさん** · 2020/03/06(金) 00:09:16.95

>>630
printf が関数として、特別な機能を持たせている文字は % の1つだけ。
しかし、言語自体が \ をエスケープ記号として使っているので、合計2つが
特別な意味を持っており、これでも問題になる場合がある。

一方、cppfmt の場合、少なくとも %, {, } の3つが特殊記号になっていて、
\と合わせれば、合計4つもが特別な意味を持っており、いくらなんでも多すぎる。

それがセンスの悪さ、と呼ばれるものである。

**デフォルトの名無しさん** · 2020/03/06(金) 00:13:54.49

>>670
でお前printfで64bitの整数出すのどうしてる？
正直に言ってみな

**デフォルトの名無しさん** · 2020/03/06(金) 00:16:09.16

>>671
64bit モードは使う必要ない。

**デフォルトの名無しさん** · 2020/03/06(金) 00:28:50.27

>>672
そうなんだ
でお前はそのお前固有の環境を前提に俺たちに何を語りかけたいのさ？
寂しいからとかやめてよ

**デフォルトの名無しさん** · 2020/03/06(金) 00:34:13.09

>>670
pythonっぽいfmt::formatが{}
cっぽいfmt::formatfが%じゃないの？

前者がわざわざ2文字なのは見やすさ重視だからこそだし

**デフォルトの名無しさん** · 2020/03/06(金) 00:53:15.12

メリットは何もないのに64bit使う必要なし。

**デフォルトの名無しさん** · 2020/03/06(金) 00:56:22.87

そうか
じゃあお前だけtime_tに32bit使って2038年問題で苦しめ

**デフォルトの名無しさん** · 2020/03/06(金) 01:00:41.40

printfは型と対応するformat指定法を把握していないと簡単にバグるからね
まあ、最近のまともなコンパイラだとprintfのformat解析まで静的にやって殆んどの場面でエラーなり警告なり出すから大分マシだけど

**デフォルトの名無しさん** · 2020/03/06(金) 01:04:32.93

(ITﾄﾞｶﾀの爺さんには)64bitはなんのメリットもない
pythonなんて当然触ったこともない

**デフォルトの名無しさん** · 2020/03/06(金) 01:55:37.24

>>675
time_tの問題をコンパイラの64bit化しなくては解決できないほどプログラミング能力がないんだね。
アホみたい。

**デフォルトの名無しさん** · 2020/03/06(金) 02:12:28.32

>>679
自分で自分に批判レスするってアホみたい

**デフォルトの名無しさん** · 2020/03/06(金) 02:13:52.12

>>680
頭がおかしいね、あなた。

**デフォルトの名無しさん** · 2020/03/06(金) 02:18:58.34

知らなくて驚くかもしれないけど、32bitのシステムでも64bit整数は使えるんだよ

**デフォルトの名無しさん** · 2020/03/06(金) 02:27:44.01

64ビットは不要とか言っちゃう奴がC++の仕様に文句言うとかないわｗ

**デフォルトの名無しさん** · 2020/03/06(金) 02:31:48.79

ハード屋が単に食い扶持確保のために用意しただけのものを勝手に意味があると思い込んでいる馬鹿な人達。

**デフォルトの名無しさん** · 2020/03/06(金) 02:59:03.29

>>684
純粋な疑問なんだけど、あなたは4294967295を超える整数を扱う必要がある時にはどうするの？

**デフォルトの名無しさん** · 2020/03/06(金) 04:22:51.72

構造体を使います。

**デフォルトの名無しさん** · 2020/03/06(金) 04:28:44.87

構造体を知らない人が64ビット言ってるんだと思います。

**デフォルトの名無しさん** · 2020/03/06(金) 04:29:16.89

なるほどね
センス悪いねあんた

**デフォルトの名無しさん** · 2020/03/06(金) 04:32:38.83

何のセンスだ。

**デフォルトの名無しさん** · 2020/03/06(金) 04:35:36.86

仕事のセンスだよ
じゃあ構造体使って1兆÷7を計算するコード書いてみてよ
64bit整数を使えば「100000000000ULL/7」だけで済むものを
どれだけ面倒で下らないコードで水増しして生産性下げてチームに迷惑かけてるのか興味あるからさ

**デフォルトの名無しさん** · 2020/03/06(金) 04:43:17.56

64bit機のNintendo64は32bit機のプレステ1に負けたよね。商業的に。

**デフォルトの名無しさん** · 2020/03/06(金) 04:53:21.52

>>690
構造体知らんの？

**デフォルトの名無しさん** · 2020/03/06(金) 04:56:22.47

知らないから君の最強の多倍長整数64bit計算を見せてよ

**デフォルトの名無しさん** · 2020/03/06(金) 05:00:24.98

構造体学んでからもう一度質問してください。

**デフォルトの名無しさん** · 2020/03/06(金) 05:04:01.70

というか構造体じゃなくて配列でいいよね
uint32_t trillion[2] = {232, 3567587328};
を7で割るコードを見せてください

64bit整数の割り算をわざわざ多倍長整数でやるなんてそんな無意味なコード書いたこともないから知らないんだよね
見本見せてよ
「100000000000ULL/7」よりもずっと優れてるんでしょ？

**デフォルトの名無しさん** · 2020/03/06(金) 05:06:27.71

構造体を学んでください。
いま素晴らしいアドバイスを与えましたよ？

**デフォルトの名無しさん** · 2020/03/06(金) 05:12:53.95

じゃあ構造体でいいよ
struct Int64 {uint32_t high, low;};
Int64 trillion = {232, 3567587328};

さっさと7で割れや
逃げるのか？

**デフォルトの名無しさん** · 2020/03/06(金) 05:14:40.27

いや全然ダメ。
構造体の何たるかが全然わかっていない。
まともな師匠に師事して学ぶべきです。

**デフォルトの名無しさん** · 2020/03/06(金) 05:29:10.46

しょうがねえな
多倍長の除算を書くのが面倒なんだったら、>>695>>697にはわざと32bit環境での多倍長演算には適さない
問題のある表現使ってやったからそのことを指摘するだけでもいいよ
それすら出来ないならお前こそまともな師匠に師事して出直してこい

**デフォルトの名無しさん** · 2020/03/06(金) 06:26:13.08

むしろ16ビットで十分だけどな。

**デフォルトの名無しさん** · 2020/03/06(金) 06:41:40.07

え、マジ？>>695>>697の何がダメか本当にわかんないの？
相手して損した

**デフォルトの名無しさん** · 2020/03/06(金) 07:17:23.58

構造体を知らないものが64ビットを愛好するということが分かった。

**デフォルトの名無しさん** · 2020/03/06(金) 07:25:27.16

>>661
R"..." はいわゆる生文字リテラルでWindowsのファイルパスとか正規表現文字列を書き易くするための機能やね
ただ無駄に高機能で
R"***(文字列中)")***" ⇒ 文字列中)"
なんてのも指定できるけど個人的にはやりすぎとしか思えない
https://cpprefjp.github.io/lang/cpp11/raw_string_literals.html

**デフォルトの名無しさん** · 2020/03/06(金) 08:24:11.44

そもそも暗号系扱うならそんな長さじゃ全然足らんしね。
構造体構造体言ってる奴もそれわかってなさそうだが。

**デフォルトの名無しさん** · 2020/03/06(金) 08:42:39.21

暗号系はHaskell一択でしょ。

**デフォルトの名無しさん** · 2020/03/06(金) 10:08:00.27

プログラムが実際にかかった時間とCPU時間の2つを最後に表示させるのに何か関数用意されてますか？
clock()はCPU時間だけですよね？

**デフォルトの名無しさん** · 2020/03/06(金) 10:13:22.05

>>703
それ必須(syntaxはさておき)
それなしのrawは片手落ちだよ

**デフォルトの名無しさん** · 2020/03/06(金) 10:23:16.85

>>706
clock()つかってんならtime()使えばいいじゃん
ちなみに君c++使えてる？

**デフォルトの名無しさん** · 2020/03/06(金) 10:25:39.21

>>699
この爺さんたぶん足し算引き算繰り返すんだよ
それならcarry bitだけ気にすればいいからね
32bitの乗算の結果は最大64bitだから爺さんの能力オーバーする

**デフォルトの名無しさん** · 2020/03/06(金) 10:33:59.25

>>707
それおまえさんの個人的意見だよね？
俺はPythonとかC#あたりでいいと思ってるだけの話
必須でもなんでもないよ