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(木) 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#あたりでいいと思ってるだけの話
必須でもなんでもないよ

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

>>710
意見でもあるし、定性的にそうだよ
閉じカッコを含められない制限に何か合理性ある？
ptyonだってトリプルクォートとかrawとか建て増しになってとっちらかってるわけで

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

いや問題はダブルクォーテンションか
そこは訂正

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

>>711-712
> 閉じカッコを含められない制限に何か合理性ある？
生文字列中にダブルクォーテーションを含めたい機会がどんだけあるんだ？
って話な
Pythonなら R"ABC" "¥"" "def" ってやるだけ（R'ABC"DEF' でもいいけど両方含む場合はとか言い出すだろうからw）
C# なら @"ABC""DEF" でできる

> ptyonだってトリプルクォートとかrawとか建て増しになってとっちらかってるわけで
トリプルクォートとRaw文字列は役割違うし別にとっちらかってないけど？

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

ダブルクォート含みのCSVとかをパースするための正規表現書く時とかいくらでもあるけど
raw文字列ってそういう時のための物じゃないの？

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

>>713
> トリプルクォートとRaw文字列は役割違うし別にとっちらかってないけど？

それこそお前の感想だよね？w
役割が違う言えば聞こえがいいが、pythonの文字列リテラルは機能の直行性もない短絡的な設計
rawは短い正規表現などの用途しか考えてなくて複数行でかつエスケープなしができない
でそういうのが欲しいケースはいくらでもある
JSONを文字列で埋め込んでおきたい場合とかね

c++のrawは建て増しなのは同じだけど設計の筋は通ってる
ただもう一歩がんばってindent合わせが可能な仕様にしてほしかったな

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

>Pythonなら R"ABC" "¥"" "def" ってやるだけ
rawの意味ねぇなｗｗ

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

>>690
だから、64BITの時間をそのまま7で割らなくてはならないような状況に
なってしまうあなたの数学力が足りない。

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

>>717
それから、本当に桁数の多い数の割り算計算が本質的に必要な場合は多倍長計算ライブラリを使えばいい。
多くのアプリではそういう状況が少ないと言うことだ。
科学技術計算では、doubleか、4倍精度float数を扱えればいいので、64BIT整数が必要な場面は今のところ少ない。
メッシュの個数やループ回数が32BITを超えるようなものは、今のCPUでは重過ぎて普通、計算できない。

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

>>717
64bitの時間？　おまえさんもしかして、2922億年のことを言っているのか？
64bitの１秒であろうと32bitの１秒であろうと１秒は１秒でしかないんだが

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

>>715
> rawは短い正規表現などの用途しか考えてなくて複数行でかつエスケープなしができない
まさかと思うがトリプルクォートとRaw文字列を組合せて使えることも知らんのか？
そんな知識で直行性とか語るなよw

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

>>716
まああんまり無いケースだから多少見辛いのはしゃーない
C#みたいな方がまだマシだとは思うが

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

業界全体の傾向では「printfへの回帰」が見られる
fmtはprintfの21世紀型強化版として捉える

つまり、+や<<で連結するのはどの言語でも煩わしかった
だからprintf（のようなもの）に戻ってきている

CUIやテキストへの出力はprintf程度で充分だった、と誰もが気付いた

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

複数行できるぞ

std::cout << R"(abc)"
R"(def)"
"\nghi" << std::endl;

しかもエスケープあり／なしを途中で切り替えることまでできる

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

普通は16ビットあれば十分ですよ。
64ビット厨はプログラムしたことあるの？

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

ポインタ使えないだろ

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

>>718
へー
お前の世界の普通の会計ソフトは43億円を扱えないし
お前の世界の普通の防犯カメラは43億ミリ秒(たった5日)連続稼働したら落ちるし
お前の世界の普通のOSは4GBのファイルを作れないのか

アホくさ

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

>>726
16BIT時代から一兆円は扱えた。
Z80 はマシン語としては整数の掛け算/割り算も浮動小数点も全くサポートしてなかったが、BASIC言語ではどれも普通に出来た。
同様に、32BIT CPUでも、64BIT整数が扱えないわけではない。

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

intは16ビットが正解。

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

>>720
まじか・・・正直その組み合わせ気づいてなかったわ
ただやはりpythonはエスケープフリーで任意の文字を含められない点で機能が不完全

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

pythonは文字列まわりがとっちらかって結局2と3で分裂したが。

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

python2で混乱してたのはraw周りじゃないぞ
文字列の文法は3でもほとんど変わってないはず
strとunicodeとbyte(に相当するもの)の扱いがナイーブ過ぎてグッチャグチャだったのがpython2の大問題

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

>>729
pythonでも"と'を同時に使わない限り何でもかけるじゃん。
一方、c++は)"という並びを文字列中にかけない制限があるわけなんで、
もちろん後者のほうか確率は低いけど、pythonを一方的に機能不全と言えるほどじゃないなー