C++相談室 part138

**デフォルトの名無しさん** (ｽﾌｯ Sd9f-fGne) · 2018/08/05(日) 18:02:36.57

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

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

前スレ
C++相談室 part137
http://mevius.5ch.net/test/read.cgi/tech/1531558382/

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

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

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

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2019/10/04(金) 12:12:57.31

この国のソフト屋にどれだけ職人がいるってのよ
大半がただの土方じゃねえか

2019/10/04(金) 12:24:43.08

おまえ土方をバカにしてんの？

2019/10/04(金) 12:32:18.96

多くの土方がいるからこそ職人が存在しうる
技術力の高い土方=職人
とするなら職人を増やすには土方を増やすべき

2019/10/04(金) 12:56:55.05

職人になるのは職人見習いであって土方ではない
どこの業界でも同じ、エリートと人手要員とでは入り口が違う

2019/10/04(金) 13:00:57.26

くだらん言葉遊びだ
土方を馬鹿にするくせに同じ仕上がりのものをてめえは作れねえのを忘れてやがる
それが立場が逆でもわからないとしたら相当な知恵遅れだ

まあおそらく逆の立場になったことのないゴミニートだろうがな

2019/10/04(金) 13:13:06.36

>>536
オナニーやろうってのは無駄に拘ったコード書くやつのことだよ

2019/10/04(金) 13:14:16.00

>>542
無駄かどうか、おまえさんはどんな基準で線引いているんだい？

2019/10/04(金) 13:22:56.82

そんなこと自分で考えろ

2019/10/04(金) 13:27:33.21

これはあくまで国語の問題で
「動けばいいんだよ」的なことをオナニー野郎とは言わない
オナニー野郎ってのは珍妙なカラクリを作って喜んでいるやつのことを言うんだ

2019/10/04(金) 13:29:36.40

珍妙カラクリオナニー野郎に比べれば
特にこだわりのない「動けばいいんだよ」の方が
まだマシ

2019/10/04(金) 14:43:29.74

>この国のソフト屋にどれだけ職人がいるってのよ
>大半がただの土方じゃねえか
ソフト屋に職人と土方が含まれてるように自分で言っといて入り口が違うとか意味がわからん

2019/10/04(金) 16:04:51.75

もしかして頭が昭和のまま更新が止まったジジイか？
俺と同じバーによく来てる土木の土方さんなんか
下手なホワイトカラーより高収入だぜ
今はそんな時代なんだよ
てめえじゃ何もできねえハリボテ野郎のフカしが通用する時代じゃねえ

2019/10/04(金) 16:32:24.34

>>546
現在だけを見たらお前の言う通り
ただ「動けばいいんだよ」は10年後もそのままだけど「珍妙カラクリオナニー野郎」はたまに化ける

2019/10/04(金) 16:49:12.89

オナニー小僧って言われて発狂してるやつ
嫁の来手がないまま白髪が目立つようになったり光ったりしちまったの？

2019/10/04(金) 16:55:37.44

白髪ならまだマシなビル
ちんこ勃たないレベルになるで

◆QZaw55cn4c (CA 0H71-sTUF) · 2019/10/04(金) 20:03:47.39

>>551
それは深刻ですね…

2019/10/09(水) 23:24:31.98

c++にはじめてさわったとき、クラスなるものに触れてシングルトンパターン凄くね！？と思ってたんだけど、スタティックと何が違うねんってなった
必ず生成されるか使われたときにはじめて生成されるかしか差がない？？

2019/10/09(水) 23:30:02.37

classベースにしておけば継承なりなんなりOO的な設計手法が使える
でもシングルトンをすごいと思う感性におどろくわ

2019/10/09(水) 23:56:26.11

>>554
値の変更を許さないってやるやん！？
用意にアクセスさせないやん！？これがカプセル化の極意か！！！とか思ってしまった

2019/10/10(木) 00:21:57.56

本当に1つだけなら静的変数でいいのよ
2以上の「n個まで」をやりたい時がシングルトンの使いどころ
「シングルトン」て名前がよくない

2019/10/10(木) 00:31:49.11

>>556
シングルトンなのに2以上になりえることあんの？？
継承？？

2019/10/10(木) 00:54:16.71

静的変数はスコープが限られてるけど(あるいはグローバル汚染するけど）
シングルトンなら使いたいところだけで使えるのがメリットだと思ってた

2019/10/10(木) 08:42:21.73

「使いたいところで使える」はメリットに見えてかなりのデメリットだぞ。

2019/10/10(木) 08:53:26.94

他インスタンスを生成させないことじゃないの？
静的変数だと別インスタンスが生成できちゃう

2019/10/10(木) 18:23:19.99

シングルトンの使いどころはマルチスレッドでリソース共有をしたい場合だぞ

代表格はロガー

マルチスレッドでない場合や、一つのオブジェクトからしか使われない場合は、他のやりようがある

2019/10/10(木) 18:28:51.53

>>556
それはMultitonという名前があるので別物

2019/10/10(木) 19:25:30.70

代表格はロガーw

2019/10/10(木) 20:18:53.50

シングルトンとかGoFの中で一番残念なパターンだろjk

2019/10/10(木) 20:43:06.65

シングルトンはマルチスレッドでつかって副作用ないの？
それこそロガーとかなんか嫌な上書き起こしそうな

2019/10/10(木) 20:44:52.27

お前ら完全にJa馬鹿と同レベルまで落ちたな。
C++やってるぼくすごい、だからだろうが。

シングルトンの使い道なんて無い。
あれはグローバルが文法的に存在しないJavaでグローバルを使う為にでっち上げたもので、
その嘘がばれないようにデザインパターン(ｷﾘｯしたものだ。
だからデザインパターンは嘘八百で、全部ゴミだ。
そしてそれをありがたがっている馬鹿共も全員無能だ。

実際、お前ら自身も、何の有り難みがあるか分からないだろ。
それで正しい。
嘘に騙されないように気を付けろ。
そしてその嘘つきは大体、コードを書かない癖にゴタクを述べてるライタだ。
だから（プログラマじゃない奴が書いた）本で学ぶのは止めた方がいい。

実際、ロガーなんて、グローバルスコープに存在しないと使いにくいし、
どうせ使うんだからstaticに生成して全く問題ないだろ。
デザインパターンの本来の趣旨「頻出パターンを学ぶことにより上達を促す」は正しいのだが、
いわゆるGoFとかのデザインパターンが糞過ぎるんだ。
ロガー等を作る場合なら、マルチスレッド対応のキューイング部分の
「悲観的ロック」「楽観的ロック」等をデザインパターン化するべきなのだが、そうなってない。

ただ、話を聞いている限り、お前らはまだクラス分けが必要なレベルに達していない。
上達したいのなら、今やってる珍妙カラクリオナニーをこねくり回すのは止めて、
無駄のないコードを書くことにフォーカスした方がいいと思うが。
それで1,000行越えるようになってから、改めてクラス分け等を学べばいい。
今のお前らが何故そこまでクラスにこだわるのか分からないが、
今の時点で珍妙カラクリオナニーに勤しんでいるようなら、Ja馬鹿と同レベルにしかなれないぞ。
今実際そうだし。

なお反論するなら、まともなOSS等でシングルトンが有効に使われているソースを提示してくれ。
10.000行程度なら読むから。

2019/10/10(木) 20:51:33.59

ロガーは機能単位やモジュール単位で作るだろ
見出しつけたりon/offを個別にコントロールするんだから
シングルトンのロガーなんて不便でしかない
そういうこといってるやつは経験不足

2019/10/10(木) 21:04:54.58

>>563
ん？
なんかおかしいと思うなら指摘してみ

2019/10/10(木) 21:06:12.07

>>567
それこそバカの典型だろw
まともなロガーの実装見てこいよ

2019/10/10(木) 21:09:00.51

>>567
テンプレートなんだから必要な単位で作るだけでは

2019/10/10(木) 21:09:26.27

と、GoF本がどの言語で書かれているか知らず、java仕様も知らないvoid君が呟いてます

2019/10/10(木) 21:19:24.09

>>569
じゃあ有名どころのspdlogのサンプルでも見てみな
ロガーをby nameで管理するregistryが内部的にシングルトンになってるがロガーは違う
ロガーはいくらでもインスタンスが作れる
https://github.com/gabime/spdlog/blob/v1.x/example/example.cpp

次お前シングルトン(GetInstance()してるやつ)のロガー持って来いよ

2019/10/10(木) 21:24:19.62

>>565
もちろんスレッドセーフにするよ
インスタンスを返す関数の中にstd::lock_guard入れるだけ

>>567
マジで言ってるのかジョークで煽ってるのか分からん

2019/10/10(木) 21:31:31.52

まあ普通のことを言ってしまうと
シングルトンて現在では有名なアンチパターンだよ。
設計が完全に間違ってる場合に生じるものと思ってよい。

2019/10/10(木) 21:33:28.29

>>572
spdlogのregistry.hのinstanceを見るとstaticの変数を返してるから、これシングルトンパターンの典型例だぞ、、、

2019/10/10(木) 21:44:28.65

>>575
どこのことを言ってるかしらんがたぶんそれデフォルトのロガー
最近のバージョンからそれがはいった
そこまで見たならspdlogに関してロガーはいくらでも作れるのはわかっただろ？
ロガーのユースケース考えたらそんなの当たり前なんだよ

2019/10/10(木) 21:53:19.67

俺もシングルトン信者ではないからシングルトンが必要になったときには設計を見直すが、シングルトンがアンチパターンであると提唱するヤツの言い分はあまり好きではない

シングルトンをアンチと言っているヤツの言い分一つに、ユニットテストがマルチで走らないこととか抜かしている
物理デバイス、例えばカメラと1:1でシングルトン用意するのはむしろ安全だ

2019/10/10(木) 21:55:58.39

シングルトンは「全部ヘッダーに書く厨」にとって天敵だし

2019/10/10(木) 22:16:24.45

わきからちょいちょい眺めてるだけだが
長文は口はわるいが言ってることは的を射ている

2019/10/10(木) 22:17:28.54

>>577
> 物理デバイス、例えばカメラと1:1でシングルトン用意するのはむしろ安全だ

まったく安全でない
複数から参照取られて同時にアクセスされたら破綻するだろ
デバイスはopen/closeのイディオムが古くから確立されてんだからそれに従えばいいだけ
やっぱりいろいろあれじゃねお前？

2019/10/10(木) 22:44:44.67

>>572
> ロガーをby nameで管理するregistryが内部的にシングルトンになってる
なんのためにそうなってるかを考えたらわかると思うんだが…

2019/10/10(木) 22:53:56.75

スレッド局所記憶（英: thread local storage, TLS）があればシングルトンでもダイジョブ

2019/10/10(木) 22:55:00.12

>>580
シングルトンにするクラスがスレッドセーフなら問題ないのでは

2019/10/10(木) 22:56:22.42

>>567
(俺に向けて言っているのかは微妙だが、)
こちらも registry.h を確認した。そして俺自身は spdlog の作りで問題ないと思う。
俺が「グローバル」と言ったのはこれで言うと spdlog になる。
ただ、俺なら syslog 等のお約束は spdlog 内に
void spdlog::sys(const std::string &str) 等にして転がしてしまって、直接それを叩き、
個別のloggerのポインタを掴んでガコガコ、ってのは最小限にするが。（というか基本やらない）
とはいえ、個別にログをガシガシ取りたいなら直接叩く今のspdlog方式の方が使いやすいのも事実だ。

ただね、個別にログ取ってもいちいち見るの大変だし、個々の順番も分からなくなるから、
纏めて errlog 等に吐き出して grep する方が実用的だと俺は思ってそうしているが。
個別にログ取るメリットって何よ？

2019/10/10(木) 23:19:05.01

>>580
シングルトンそのものが安全機構を提供する訳ではないからその意見は至極真っ当だな
当然open/closeも実装するが、言いたいことはユニットテストがマルチスレッドで走らないからアンチパターンに含めるというのは賛同できないという事だ

いちいち全部書かないと分からないようだから書くけど、デバイス制御でデバイスをいきなり作るのではなくモックをソフトウェアで作って試験する
このモックをシングルトンで作って置くと、マルチスレッドでユニットテストが通らない
通らないのが正しいんだ
そういう意味の安全

2019/10/10(木) 23:38:16.51

>>585
それはお前がおかしい。（2重に）

まず>>577の書き方がおかしい。
普通に読んだら、「mutex使わずにシングルトン？」と読める。>>580がまとも。
585の意味なら、そこで「モック」と明示的に書かなければ通じない。

次に585、それがそもそもおかしい。
ハードのモックをソフトで作って、排他制御が出来ていないときに正しく落とすのなら、
MutexのTryOpen等を使って実装し、（例えば以下）
https://docs.microsoft.com/ja-jp/dotnet/api/system.threading.mutex.tryopenexisting?view=netframework-4.8
falseが返ってきたら全部アウト（落とす）というように実装するのが普通で、
そこでシングルトンとかいう構造で無理矢理落とそうというのがそもそも間違っている。
というかそのお前が作っているモック、全く信用ならないと思うが。
それだと「落ちるときもある」であって、「上位での排他制御を忘れた場合に100%落ちる」ではないだろ。
それでは使い物にならないと思うが。

2019/10/10(木) 23:55:12.29

>>586
なんでお前は勝手に想像して批判するんだよ
上に俺の書き込みでstd::lock_guardと書いてるんだから、当然そこにはmutex入ってるだろ

mutexで例外飛ばして落とすなんて普通にやるよ
そういう話をしてんじゃねーよ

モックでうまくいった試験が実デバイスに入れ替えた途端にマルチスレッドで走って、setupでありえない動作してmutexで落ちたって、片方の試験はされてないだろ
ここにシングルトン導入するだけでヒューマンエラーが減るんだよ

2019/10/11(金) 00:15:49.73

>>587
だからそうじゃないんだよ。
お前が言ってるmutexは、ちゃんと止まるmutexだろ。
つまり、取れなかったり取れたりするmutexだ。（それ自体を排他制御に使っているmutex)

俺が言ってるのは、常に取れるmutexであって、取れないとアウトだ、ということ。
それは上位で排他制御しているから。

馬鹿なお前の為にもっとかみ砕くと、二重のmutexの構造にするんだよ。
外側はユーザー（つまりデバイスを使う側）がmutexを取る。
これがお前が言っているmutexだ。これをmutexAとしよう。
そしてモック内にmutexBをもう一つおく。これがチェック用のmutexで、
mutexBはmutexAで排他制御済みなのだから常に取れるんだよ。
だからtryOpenでfalseならアウトにする。それだけだよ。

モックで上手く行った試験ならデバイスでも100%走るべきであって、
それが出来てないのは、お前のモックが「落ちるときもある」でしかないからだよ。
お前の言い分は、お前のモックがポンコツだと証明しているだけだぞ。
お前には分からないのだろうけど。

まあこれ以上は平行線だろうから、俺の言い分をお前の上司に見てもらえ。
そして怒られろ。

デザインパターン廚の問題はここで、
本来はデザインパターンで対応するものではないのものを無理にデザインパターンで対応しようとしてしまう。
引き出しを増やす為のデザインパターンなのだが、デザインパターンを使うことが目的になってしまっている。
今のお前らもそうだろ。クラス分割することが目的になっている。
今のお前らの実力なら、無駄のないコードを書くことにフォーカスした方がいい。
mutexで対応すべき案件をシングルトンで、とか、狂ってるぞマジで。

2019/10/11(金) 00:19:03.25

シングルトンってのはインスタンスの数を制限するとともに、みなさんご自由に参照とって使ってくださいよってパターン
お前のは後者の観点が抜けている

2019/10/11(金) 00:19:37.19

>>587

2019/10/11(金) 00:29:38.02

>>588
お前はだから勝手に想像して批判するのをやめろ
二重のmutexだって使うし、当たり前すぎるから一々書かない
お前は自分だけが知ってるとか勘違いしてるから諭すように余計なことを言い始めるが、滑稽なだけだぞ

誰がモックのみでうまく行く試験書くんだよ？
モックの段階で気づく事ができるから、シングルトンの有効な使い方の一つだと言っているだけだ

お前は誰かがシングルトンはアンチパターンと言っているから、シングルトンの活用の仕方を放棄してるだけだろ
ハッキリ言って思考停止してるよ

2019/10/11(金) 00:37:41.40

>>589
後者の話は真っ先に>>561で書いた
ロガーが代表格と書いて置いた

今話しているのは、シングルトンがアンチパターンだという理由の一つに、シングルトンを含めるとユニットテストがマルチスレッドで動かない事が挙げられている点に、俺は賛同していない
その具体例を挙げているだけ

シングルトンである必要はないが、シングルトンを活用できる事例だよ

2019/10/11(金) 00:51:34.26

Interface& singleton(); で済むところ、わざわざ実装クラスを公開したうえで「これはシングルトンです」
などと制限を加えるのはマヌケに見える。そもそも実装クラスを公開しなければ勝手にインスタンスが作られることもないのに。

2019/10/11(金) 00:53:32.37

「勝手に想像して批判」「自分だけが知ってるとか勘違い」などと指摘した人はたくさんいたけど、
そこは変わらない彼の性格なようだから、あきらめたほうがいい。
いろいろあってこの重複スレに閉じこもってくれているだけありがたい。

2019/10/11(金) 01:05:57.82

>>591
>>592
お前がそう思うのは自由だが、お前はマジで狂ってるぞ。

それは間違ったシングルトンの使い方であって、2重mutexで組むのが正しいし、それだけだ。
シングルトンのモックは「排他制御を忘れてデバイス上で競合し、
たまたまシングルトンの排他制御が出来ていない部分に命中」した場合に落ちるだけだ。
2重mutexだと「排他制御を忘れてデバイス上に突入」したら全部落とせる。当然モックとしての質は高い。
だからこの部分を2重mutexではなくシングルトンで組むというのは明確な間違いだ。
というか何故それをシングルトン、というのが疑問だが。
普通に考えてそうはならないだろ。
既に言ったが、シングルトンを使うことが目的になってるとしか思えない。

まあいずれにしても、上司に怒られとけ。それがお前にとって一番いいと思う。
お前はそもそもモックが何の為にあるかとか、その辺から分かってない。

なお俺はシングルトンの使い道はない、と言っているだけだ。
別に誰かがどうこう、ではない。実際に使えないから使えない、と言っているだけ。

2019/10/11(金) 01:48:03.62

>>595
いや、だからなんで2重のmutexを入れない前提になってんだよ

物理デバイスに対してユニットテストを行う場合、そもそも平行して試験できないから、そこにシングルトンを入れて平行に試験できない事がデメリットではないと言っているんだが、何故伝わらん

2019/10/11(金) 01:53:41.68

>>594
身をもって理解したw

2019/10/11(金) 02:03:23.96

>>596
伝わらないのはお前が色々嘘を言っているからだ。
お前は自分の書き込みを読み返して、矛盾等がないか確認してみろ。

まあとにかく、お前はここの書き込みを上司に見てもらって、怒られろ。
上司がまともならそれで問題なくなるはず。

2019/10/11(金) 02:09:36.89

>>598
まぁもうやめよう

お前ユニットテスト理解して無さそうだし、ハードウェアで直列にやる試験を並列に間違えて書かれた場合の対処方法全然書いてないし

知らないから書けないのは理解した

2019/10/11(金) 06:48:18.29

ちなみにちょっと気になって
>>572のソース、シングルトンになっている部分
https://github.com/gabime/spdlog/blob/v1.x/include/spdlog/details/registry-inl.h/#L263-L267
について確認してみたが、
C++11でスレッドセーフにするという糞なパッチが言語側で当てられてるんだな。
https://cpprefjp.github.io/lang/cpp11/static_initialization_thread_safely.html
かなり最悪だ。目に見えないコストは無くすとかいうポリシーはどこに行ったんだよ？という。
これならシングルトンパターンにdouble-checked locking まで含めて
以下リスト4にした方がまだましだった。(なおJavaでは動かないらしい、詳細は全部読めば分かる）
https://www.ibm.com/developerworks/jp/java/library/j-dcl/index.html

いずれにしてもシングルトンなんて使い物にならないし、
それ以前に関数内staticなんて使わない方がいい。
さてgoogleはどうしてるのか、と思いきや、いまいちよく分からんが限定的許可らしい。
https://ttsuki.github.io/styleguide/cppguide.ja.html#Static_and_Global_Variables

どうもここのC++初心者は文法をこねくり回す傾向があり、
同様に、学んだデザインパターンの適用範囲を探しているようだが、そういうのは止めた方がいい。
それは本末転倒そのものでしかない。
何か書いていて、何か引っかかったときに、そういえば何かパターンにないか？と探すものであって、
デザインパターンを適用する為のコードを書くものではない。
そうすればシングルトンなんて使いどころがないというのが自然に納得出来るようになる。
>>553の言うとおり、staticで何も問題ないからだ。
コンストラクタをprivateにして外から呼ばせない、というアクロバティックなことをする意味がまるでない。
これに関しては、GoFも若気の至り(中二)だったんだと思うよ。
(ただし形式的には分かりやすいシングルトンに初心者が惹かれるのは分かる)

同様に、クラス分割(OOP)をする為のコードを書くものではない。
これも、必要に応じて自然に分割して行くものだ。
試したいのなら、まずはOOPが有効に機能する最低規模(1,000行程度)のコードを書かないと始まらない。
既に何度も言ったが。

2019/10/11(金) 07:25:57.91

押し付けがましいやつ、プログラムに限らず、どこで出くわしてもウザ過ぎ。死ねよゴミとしき思わない。

2019/10/11(金) 11:20:06.41

文句つけられる俺スゲー君だろw
生暖かく見守ってやろうじゃないか

2019/10/11(金) 12:00:40.27

どうせ隔離スレなんだから

2019/10/11(金) 12:44:46.33

>>566
OpenGL

2019/10/11(金) 13:11:27.34

>>572
俺(566)に対してのソース提示ではないだろうが一応レス付けとくと、
そのOSSは確かにまともなOSSでシングルトンが使われている。
有効に？ではないと思うが。

一応軽く追いかけてみた。
その構成ならregistryは動作時には不可欠で、当然生成されるが、それは例えば
https://github.com/gabime/spdlog/blob/v1.x/include/spdlog/details/synchronous_factory.h
で為されている。呼び出し元は例えば
https://github.com/gabime/spdlog/blob/v1.x/include/spdlog/sinks/basic_file_sink.h
で、wikiによるとそれはloggerの生成だ。
> auto my_logger = spdlog::basic_logger_mt("basic_logger", "logs/basic.txt");
> https://github.com/gabime/spdlog/wiki/1.-QuickStart

だから、loggerを生成したらregistryは生成される。
そして当然このloggerの生成は出力より前に行われるから、常にベタで書かれている。
だから結局常に生成されるだけで、このシングルトンは意味ない。

意味があるように作るとしたら、
loggerの生成タイミングではなく、出力タイミングでのregistry生成としなければならない。
この場合、「loggerの準備」ではなく、「初めての出力」時にregistryが生成されることとなるので、
例えばログレベルを下げておいて殆ど出力がない状態なら、（初めての出力までは）registryのメモリがケチれる。
ただし出力毎に毎回nullチェックが必要なので、出力自体は（ごく微妙だが）遅くなる。
(そして速度重視のこのOSSはこれを嫌って生成タイミングを準備時にし、シングルトンの意味が無くなってる）

が、正直、こんなところをケチるよりは、staticに生成して、
google曰くの「dynamic initialization」の問題を避けた方がましだと思うが。
いずれにしても、今の実装はどっちつかずの状態になっている。
（シングルトンのデメリットだけ受けている状態になっている。といっても大して問題ないが）

というわけで、お前らの判断は知らんが、俺の判定は上記だ。このOSSのシングルトンは意味無い。
他に同様に「まともなOSS等でシングルトンが有効に使われているソース」と思われる物があればよろしく。

2019/10/11(金) 13:12:56.72

>>604
> Is OpenGL Open Source?
> No, OpenGL doesn't have any source code.
> https://www.khronos.org/opengl/wiki/FAQ
もうちょっと調べてから頼む

2019/10/11(金) 15:26:52.64

今の議題とは全く関係有りませんけど、さっき、
「C++13(?)は『古過ぎる』ためにC++とは認めない」ということが
書いてあり、その後もカドがあるような書き方を一杯してあるホームページ
を見つけました。そういう人がこういうスレにくればそういう感じの事を
言いまくるんでしょう・・・。やっぱり、C++の最新機能を必要とするか
好きかどうかは思想や好みの問題だと思いますので、それが全てだという
主張は問題ですね。

2019/10/11(金) 15:35:59.14

例えば、C++11 は、VS だと、2015 か 2017 辺りで初めてサポートされた
機能もあるそうですね。だから、C++11をちゃんと使おうとすれば、VS 2017
が必要になる事もあるはずです。C++11 が 2011年で使えたとは限りません。

2019/10/11(金) 16:29:40.21

C++13って何？

2019/10/11(金) 16:42:27.41

>>609
C++13 は無いようですね。

2019/10/11(金) 16:43:38.85

C++14になったやつかいな？？

2019/10/11(金) 16:44:23.13

たしか17策定しているときに11のあれ不味かったなーって案件をフィックスするわーって話があった気がする。

2019/10/11(金) 16:48:29.20

std::vector などの初期化や末尾追加などが分かりやすく書くためには、
かなり新しいC++でないといけないようです。結局、それがしたいためだけに
言語仕様が修正されたとも言えるかもしれませんね。

2019/10/11(金) 18:25:13.94

>>607
その記事は読んでないけども、c++2aを見ると、俺の知ってるC++じゃないと言いたくなる

2019/10/11(金) 18:40:56.74

C++11以降で何が一番いい機能だと思う？
俺autoかconstexprで迷う

2019/10/11(金) 18:48:26.59

CPUがどんどん速くなってるから高速化機能のconstexprのありがたみはあまりない。
一方、autoのおかげでソースコードの可読性や保守性はかなり上がったと思う。
autoのせいで苦しんだって人を知らないんだけど、みんなの周りにいる？

2019/10/11(金) 19:05:12.18

c++はクラス名が長くなりがちだからautoは便利なんだけど、型が分かりにくくなってしまう

個人的にはuniversal initializationかな

2019/10/11(金) 19:10:41.92

range-based for

2019/10/11(金) 19:13:06.87

>>616
Eigenはautoが使えんて記事見た事ある

2019/10/11(金) 19:14:23.31

>>600
ついでにCについて調べてみたが、
Cはコンパイル時に初期化で、リテラルしか許可されないらしい。
まあこの構成ならシンプルで美しい。
https://www.geeksforgeeks.org/g-fact-80/

問題はC++で、
動的初期化前提のクラスも普通にそこに書きたいから、
初期化タイミングを「最初の実行時」に移動し、
結果的にフラグをコンパイラ側で用意する等で対応することになるが、
C++erが馬鹿過ぎてスレッドセーフに書けなかったからC++11で言語側で補助輪追加、のようだ。
何だかなあ、だが、割とC++的展開ではある。

C++は全般的に仕様に貪欲すぎる。Cのように、それは無理だから割り切る、という部分がない。
結果、ソースコードから想像も出来ない仕様が追加されているわけだ。
そりゃLinusも嫌うわ。
見た目スレッドセーフでないコードが仕様でスレッドセーフにされているのは、かなり酷い。

2019/10/11(金) 19:20:04.91

範囲for自前のでももうちょい組み込みやすいといいんだけどな
結構めんどい

2019/10/11(金) 20:28:29.78

C++ って、

std::vector<int> {要素1の初期値, 要素2の初期値, 要素3の初期値}

で一時オブジェクトが作れましたっけ？

2019/10/11(金) 20:31:33.49

https://docs.microsoft.com/en-us/cpp/cpp/constructors-cpp?view=vs-2019
↑によれば、initializer_list<string> { "bread", "cheese", "wine" }
という書き方は出来るらしいです。

2019/10/11(金) 20:36:19.16

出来る

2019/10/11(金) 20:55:22.22

https://wandbox.org/permlink/1OIKd3PqPlolWL6M
よくわからんけど。こんなんもん？

2019/10/11(金) 21:01:35.20

>>615
usingだな。aliasを適切なスコープで定義できるだけで十分。

2019/10/11(金) 21:43:31.41

>>621
そんなに面倒かな？
https://marycore.jp/prog/cpp/custom-iterator-and-range-based-for/
まあC#みたいにyieldが使えた方が綺麗にかけるとは思うが

2019/10/11(金) 22:13:24.26

>>625
それは、
std::vector<int> &data = {1, 2, 3 ,4 , 9999999};
に相当しているようで、>>622 の
std::vector<int> {1, 2, 3 ,4 , 9999999}
とは違いますね。

2019/10/11(金) 22:16:09.02

C++ の例として、
std::vector<int> data = {1, 2, 3 ,4 , 9999999};
は見たことがあると思うんですが、>>625 だと関数の
引数渡しの場合にはなっていますが、結局、
std::vector<int> &data = {1, 2, 3 ,4 , 9999999};
相当の事をやっているようです。この形式も可能なんでしょうか？

2019/10/11(金) 22:19:36.71

やってみたら、& が付いてない方は通りましたが、& を付けた方はエラーに
なりました。
どうやら、関数の引数の場合だけは異なる処理がされているようです。

2019/10/11(金) 22:24:09.11

for (const auto& p : std::vector<int> {100, 200, 300, 400} ) {
std::cout << p << std::endl;
}
↑は通りました。

【結論】

std::vector<int> data = {1, 2, 3 ,4 , 9999999};　　// ○
std::vector<int> &data = {1, 2, 3 ,4 , 9999999};　// ×
std::vector<int> {100, 200, 300, 400};　　　　// ○, 一時オブジェクトの生成。

2019/10/11(金) 22:27:32.98

>>631
【追加】
void func(const std::vector<int>& deta) {
　　・・・
}
func( {1, 2, 3 ,4 , 9999999} );　　// ○, 実際にコンパイルに成功する。

2019/10/11(金) 22:30:11.29

【結論】
std::vector<int> data = {1, 2, 3 ,4 , 9999999};　　// ○
std::vector<int> &data = {1, 2, 3 ,4 , 9999999};　// ×, const が付いてない参照型はダメ。
const std::vector<int> &aaa = {1, 2, 3 ,4 , 9999999};　　// ○, const が付いていると OK。
std::vector<int> {100, 200, 300, 400};　　　　// ○, 一時オブジェクトの生成。

void func(const std::vector<int>& deta) {
　　・・・
}
func( {1, 2, 3 ,4 , 9999999} );　　// ○, 実際にコンパイルに成功する。

2019/10/11(金) 22:32:47.43

>>631
一時オブジェクト(右辺値)だから&&で受けなきゃいけないね
std::vector<int> &&data = {1, 2, 3 ,4 , 9999999};　// ○

>>632
constであれば一時オブジェクトの参照も引数にとれる
constを外すとコンパイル通らない

2019/10/11(金) 22:37:02.37

for (const auto& p : {100, 200, 300, 400} ) {
　std::cout << p << std::endl;
}
↑も通りました。
すくなくとも、for each の文脈においては、
std::vector<int> {100, 200, 300, 400};　
と
{100, 200, 300, 400}
は等価であるかのように振舞っています。詳細は分かりません。

2019/10/11(金) 22:52:24.45

>>627
c++17でstd::iteratorが非推奨になったのを書き直すとそれなりにめんどくさい
あと貼ってくれたURLは分かりすいけどもc++11以降の書き方には見えないなw