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(木) 10:06:12.56

>>552
関数セットとしては、やはり伝統的なCのものを使うことが多いんではなかろうか。
ソートや乱数、最大最小値計算、正規表現なんかはC++風のものが好まれる傾向が出始めてるかもしれない。
文字列の一致テストなども、個人的にはCのstrcmp()、_strcmpi()、strncmp()、memcmp() なども結構使ってるけど、若い人の間では std::string の比較機能が好まれているかもしれない。
というかC++から勉強した場合、それしか知らないだけかも知れないが。
文字列表示は、ネットではなぜか cout 系で、cout << "Hello"; のようなものを良くかけるが、
表示する際の16進数と10進数の区別や、表示桁数の指定、float/double値の有効数字桁数の指定、先頭に0を付けるかどうかなどを指定し易いので、古いと言われようが個人的には昔ながらのprintf()が好きだ。

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

マニピュレータを作ることが出来るのでストリームを使ってるだけでは。

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

若い子は馬鹿なのでストリームを好むｷﾘｯって風に見えるのだろか。

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

C++の文字列比較で比較開始位置や最大長さを指定したい場合、
if ( str1.compare(0, 5, "abcdefghijklmn") == 0 )
のように書く必要があるが、Cのstrncmp()だと
if ( strncmp(pszText1, pszText2, 5) == 0 )
と書ける。
後者の方が、比較する2つの文字列1, 文字列2の間にみごとな「対称性」があってとても美しい。
さらに、
C :
if ( strcmp(pszText1, pszText2) == 0 )　　// 長さ指定なしの全体比較
if ( strncmp(pszText1, pszText2, 5) == 0 ) // 最大長さ指定有り。
C++のstd::string :
if ( str1 == str2 )　　　　　　　　　　　　// 長さ指定なしの全体比較
if ( str1.compare(0, 5, str2) == 0 )　　　 // 最大長さ指定有り。
のように、長さ指定が無い場合と有る場合の「対称性」もCの方が高い。

さらに、開始位置と長さを指定する引数の位置が、コンストラクタに置いては
std::string str2("Hello World");
std::string str1(str2, 長さ);
std::string str1(str2, 開始位置, 長さ);
なのに、比較においては
str1.compare(開始位置, 長さ, str2)
のように前後が逆転していて、ここでもまた、STLの文字列操作には「対称性」が無い。

なお、MFCのCStringの場合は、
CString str1, str2;
に対し、以下のように strcmp(), strncmp() に簡単に指定できる :
if ( str1 == str2 )　　　　　　　　// 長さ指定なしの全体比較
if ( strcmp(str1, str2) == 0 )　　 // 長さ指定なしの全体比較
if ( strncmp(str1, str2, 5) == 0 ) // 最大長さ指定有り。
一方、std::string の場合、const char* 型への暗黙変換が出来ず、str.c_str() のように書かないといけないという困った問題がある「かも」知れない。
今のC++でどうなったかは知らない。

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

>>552
人による。
そして上のやり取りでもわかる通り玄人ぶったバカが変な思想を押し付けてくるが
気にしなくてもよい。

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

>>561
そんなん好きなようにラッパー関数を書けばええがな。

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

>>563
ラッパー関数とは関係ない話。

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

>>558
ストリームよりprintfがましってのは同意だがprintfよりfmt使え
C++20から標準になる

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

>>565
気になるので言っておく。
stream 入出力とは、古くから FILE, fopen, fclose, fgetc, fread などに対して使われていた言葉で、cout/cin 系専用の言葉ではない。
なんでもそうだが、言葉は有名なところで先に使っていた方が優先されるべきだ。

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

>>566
1. Cのstdin, stdout, FILE, fopen, fclose, fgetc, fread 系の関数群のことは、
非常に古くから「Stream I/O」と呼ばれていた。
2. C++ では、「iostream」というような名称で cout/cin 系のクラスが定義された。
後者の事を単に「ストリーム」と言っても1とは区別が付かないのでやめて欲しい。

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

>>556
おい554、range-based-forはコア言語だぞ、断じてSTLではない
そもそも規格票に一言も出てこない用語でイキッてんなよ
俺がアマチュアかどうかも証拠持ってるわけねえよな

寝言は寝て言えタコ助

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

>>567
C++スレなので。
コンテキストで十分判別がつきます。

**はちみつ餃子** ◆8X2XSCHEME · 2020/03/05(木) 13:41:04.88

何を使ってもいいけど、レイヤは切り分けた方がいいと思う。
string を使ってるときは char の配列と混同させて使うべきではないし、
char 配列を使っているなら string のことは忘れた方がいい。
どこがレイヤの境界なのかはっきりさせて。

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

>>565
初めて聞いたが、書式で{1}{2}など C#に似た使い方が出来るが、
逆に、{ や } の記号を簡単にはかけなくなり printf より使いにくくなってしまう。
しかも、{1}{2}が使い易いとは思わない。むしろ%sや%dより混乱する気がする。
しかも標準ライブラリではない。

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

>>569
付かない。
C++はCを前提にしているのだから、両者を混在して使うのが普通だし。

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

>>570
仕組みを深く理解していれば混在させても問題もない。
文字列程度でレイヤー訳が必要になるんなら、Cの上位互換の名を外すべきだ。
別の言語としてやり直せ。

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

>>572
もうそんな時代じゃないので。
いまは、CがC++に依存する時代。
C++で書かれたAPIをCから呼び出す。
C++がスクリプト言語のような柔軟性を持ちつつ、しかしシステム言語として使われるのは、Cから呼び出せるからでは。

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

c++がスクリプト言語のような柔軟性をもつ？何言ってんの？病気か？

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

>>568
言い返すとこはそこでいいのか？w
ちなrange-based forはまだC++に慣れてない初心者に押し付けるほどのものではないし
ましてrange-basedに合わせるためにoperatorの実装を押し付けるのは論外
ドヤりたいだけの初心者は黙ってろマジ迷惑だから

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

>>574
coutやstd::stringが使い易いなら誰もCでやろうとは思わないが、現実にはCの方が便利だから
あくまでも使いにくいそれらを使おうとするとのは、今のネットは新しい情報だけが上に来てしまうため、C++しか知らない人が多いためだ。

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

>>571
好きにどうぞ
時代に取り残されないようにな

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

>>577
一行目の「だから」の直後に「。」が抜けていた。

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

>>578
古いものを知らないで勝手に変な仕様を入れてしまう人が増えているんだ。
C#やcppfmtのそれは、PerlやRubyよりも遥かに使いにくい。

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

>>580
好きにどうぞ
時代に取り残されないようにな

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

>>576
現場でよく使われる関数は何かと尋ねられて
すぐ思い当たるものを正直に述べたのが
初心者に押しつけたように見えるのは
おまえの目か頭のどちらかがおかしいからだ
いや両方か？

C++11に付いていけず置いてかれ
C++03でドヤりたいだけなアウトカーストこそ
マトモな初心者に触るなアホが伝染るから

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

マジでプロでもフリーソフト開発してるアマチュアでもいいから実際の開発に使ってる人(と初心者)専用の相談スレがあった方がいいかもな
開発全くしてない人間でも別に好きにすればいいが、ここはプロや経験長い人にマウント取りたいだけのクソバカが多過ぎる(しかもそれに初心者が騙されて右往左往する)

まぁその役割は初心者スレがすでにある程度担ってんだろうけど

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

>>582
アマチュアで初心者でドヤりたいだけ、ってのは否定しないのかwwww

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

乱数とかCライブラリでは辛すぎる。

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

>>584
はあ？　俺がアマチュアという事実無根の誹謗中傷をしたことを否定しないのはおまえだろ

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

嘘つき野郎と日本語で言っても非難の度合いが弱すぎるので英語でLIAR!!

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

仕様に「任意の」とついたら、もうCでは拷問になる。
CIA真っ青級の。

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

めんどくさいからそろそろ天才がどうたらいういつもの結論行って。

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

Networking TSが入れば追いついてこれるものなど居ない。

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

江添に影響されたバカが増えたよな。
ああいうまともにコード書いてないで知ったかするカス態度はほんと害悪だわ。

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

生データからノイズを除去し有益な情報だけを抽出できないやつに江添の文面は無理

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

まぁC++専門のライター自身がC++に変な幻想抱いてるしね
スクリプト言語の代わりになったって仕方ないのに
むしろC++にそのように振る舞わせるためにユーザーがアホほどコスト掛けなきゃいけなくなるという

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

>>593
https://root.cern.ch/cint

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

ただ新しい言語をなぜやるかの理由の一つとして
年上にマウントとるためってのは実際大きいんだろうなと思う。
これは他言語でもそうだし、昔からそう。
この点についてこの業界は50年以上全く解決されてない。

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

C++でワンライナー書けるようになったら、初心者脱出。

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

>>574
cがc++に依存するって何のこと言ってる？

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

俺が6800のマシン語やり始めた頃
ジジイたちはPCなんてオモチャとバカにしてたから
マウント取りたきゃいつでも取れてたが
そんなパンピーが考えそうなくだらねえことには興味なかった

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

C++を使いこなせないと老害の始まり。

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

>>594
時代がどうこう言ってたのに03までやんけ（´･ω･`）

>>598
老g(ry

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

URL見て気が付いてほしかったが。

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

君そのマウント癖やめた方がいいよ
しょっちゅう恥かいてるだろ？
しかも自爆でw

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

いや、CINTなんていにしえの遺物で、話題になることも無いし。
そこで気づいてほしかったのだが。

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

まさに老害にぴったりと。

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

>>604
でcがc++に依存するって何のこと？

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

俺もぜひ拝聴したいねえ

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

このスレって伸びてるときほど中身が薄くなるなw

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

もはやCだけで完結しない。
Cは歴史の遺物。

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

API呼び出したら、中身はC++で書かれてるだろ？

**デフォルトの名無しさん** · 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++使いたいからな