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/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

2019/10/11(金) 22:54:12.48

>>607
自分も最近ネット上でそういうブログとか見かけるけど、初心者もいいとこなやつに限ってそういうふうに書く
過去の仕様を腐すのがカッコいいと思ってるぽいね
アホだと思ってほっとけばいいよ

>>619
ET使ってるライブラリは戻り値が仲介クラスで実際に利用するベクトルとかのクラスじゃない
ベクトルクラスなどの代入演算子やコンストラクタに渡すことで初めて展開される
なのでautoで受け取るとまずいんだろうね

2019/10/12(土) 01:06:02.00

仕事の人は守秘義務とかあるだろうから聞かんけど趣味の人はC++で何作ってるの？

2019/10/12(土) 01:29:35.74

>>615
using

2019/10/12(土) 01:42:49.81

Windowsにはgdiplusという悪名高い画像ライブラリがあって min(), max()が名前衝突する困った仕様になっている。
usingで置き換えてくれたらみんなが幸せになるのに。

2019/10/12(土) 06:31:56.25

関数形マクロを回避する方法を知らないわけね

2019/10/12(土) 06:54:09.80

NOMINMAXを定義する方法、関数名を()で囲う方法ある

2019/10/12(土) 07:09:41.91

あー勘違いしてた。gdiplusの話か。std::min,std::maxを使うように更新して欲しいわ。

2019/10/12(土) 08:02:54.54

>>638
コンパイラ

2019/10/12(土) 09:55:25.44

>>638
汎用ほにゃらら系統
可変長、任意型タプルのテンプレートとか。

クソの役にも立たんが。

2019/10/12(土) 13:02:17.96

>>640
悪名高いといっても、MS 標準で、jpg, png, bmp などを簡単にファイルから
べたデータに変換して GDI の Bitmap 画像として BitBLT 出来るのは、GDI+ のみ。
透明色を十分にサポートしているのもこれのみ（ちょっと遅いらしいが）。
普通の Win32 (のGDI など) は、jpg, png, bmp をファイルから読み込もうとすると
自分でファイルを解析するか、読み込み用のライブラリを自分で探してきて
リンクする必要がある。

2019/10/12(土) 13:30:41.38

GDI+は既にLegacy Graphics扱いでもう新規に使うべきものじゃないことになってるしなぁ。
画像ファイル扱うなら今はWICを使う。

2019/10/12(土) 13:34:11.43

GDI遅いしね
GDI+はGDI時代でもそれよりくそ遅かったのに、今じゃ使う意味がない
まあXP以前のOS用に開発する必要があるなら別だが

2019/10/12(土) 14:09:30.46

でも、GDI+ は分かり易い。
ファイルの読み書きだけを使うのであれば全く問題ない。
描画系に関しては GDI+だけで済まさずに工夫すれば遅くは無い事が多い。

2019/10/12(土) 14:21:33.50

さすが古いもの万歳なADSLじじい

2019/10/12(土) 14:34:58.37

https://stackoverrun.com/ja/q/3803501

ここを見てみたら、2012年の時点で、GDI+の代わりになるMSが推奨するもの
はWPFという話。しかし、WPF自体が GDI+ より遥かに衰退してしまった現実がある。

2019/10/12(土) 15:20:37.17

誰が.NETの話してんだよｗ

2019/10/12(土) 15:50:03.16

一所懸命ググったんだろうねｗ
つまりGDI+より新しい技術のことを全然知らないから、否定されたら必死に擁護するしかないわけだ。

2019/10/12(土) 15:54:42.09

2D描画周りはDirect2Dがあるしね

2019/10/12(土) 16:12:33.93

>>648
おまえみたいのにそう言わせるために
わざと減速してるんだよ

2019/10/12(土) 16:26:54.37

そもそもGDI+はC++クラスを使ったラッパーに過ぎないので、基幹部分をしれっとDirect2Dに置き換えることだってできたはずなんだよね。
だけどなぜか劇遅のまま放置されてる。
同じことは、STLの正規表現クラスregexにも言えるわけで、基幹部分をしれっとpcreなりre2なりに置き換えることだってできる。

**656** (ﾜｯﾁｮｲ bfad-NJTS) · 2019/10/12(土) 16:39:52.46

尻切れトンボの追記。

同じことは、STLの正規表現クラスregexにも言えるわけで、基幹部分をしれっとpcreなりre2なりに置き換えることだってできるはずなので、
競合する正規表現ライブラリからシェアを奪うためにも、STLのregexと互換性のあるインターフェースをライブラリ提供元に公式で作ってもらいたいというなぁという愚痴。
あと、今やヘッダーに何でも書く時代になったので、ヘッダーを書くときは名前衝突しないようにC++の名前空間を有効に使って配慮するのがマナーかなと。

**656** (ﾜｯﾁｮｲ bfad-NJTS) · 2019/10/12(土) 16:43:15.63

失礼しました。regexはstdであってSTLではなかった。

2019/10/12(土) 16:43:30.99

何度も言っているがお前ら池沼は邪魔だから本スレに行け。
俺は隔離されてやってるんだから俺に文句がある奴がここに来る必要なんて無いだろ。

C++相談室 part145
https://mevius.5ch.net/test/read.cgi/tech/1568362404/

お節介ついでに言っておいてやると、
>>591と>>635は上達しないタイプだ。ただし>>635は救済の余地がある。
>>422と>>553は上達するタイプだ。だから俺は救済してやろうとした。

2019/10/12(土) 16:43:56.62

>>422だが、ああいうコードをすぱっと投稿出来る素朴さは失うべきではないんだ。
糞コードだと叩かれたところで、どこが糞か指摘してもらえれば上達の手助けになる。
そこで「俺コードの方が上だ」と突っ張りあいをするのなら、それも切磋琢磨になる。
お前らは批判されるのを恐れてこれを全くやらなくなってしまっている。だから上達しない。
そして逆に、これをやり続けているのがOSSで、GitHubなんてその典型だろ。
コードを書けない奴に発言権無しの世界だから、お前らは参加出来ないとは思うが、
逆に、コードを書ける奴にとっては、お前らみたいな池沼に絡まれることがない、かなり快適な世界だ。
だからGitHubは本日も盛況なわけでさ。

>>553もちゃんと自分で考えて本質を見てるだろ。
言っていることはその通りで、従ってシングルトンなんて珍妙カラクリオナニーなゴミでしかない。
これに対して>>591は「シングルトンパターン」という権威？を「有用で正しい」と思いこみ、
活用の仕方を探している。これは方向性が全く逆だ。
これは自分で考える知能がない奴が陥るパターンだ。だからこいつは上達しない。
話を聞く限り、インターンで褒められて勘違いした奴じゃないかな？
インターンは新人以下の奴に1週間程度でそれなりに成果を出させて、
しかも仮に成果が全くなくとも本業に影響してはいけないので扱いが難しい。
そこで「モック」を作らせて「無いよりまし」な状況でテストの足しにしよう、というのは戦略として正しい。
それでおだてられて勘違い、というところだろう。
教育や結果に責任持つ必要なく、嫌われる価値すらないので、当然褒める。
お客様扱いでしかなく、同じコードを「新人」として入社後に書いたらボロカスに言われることを理解出来てない。
といっても、まあ、これを入社前に知っている奴なんて居ないから、本人の問題ではないが、
そこで勘違いしているようなら上達はしない。
ただこいつは話しぶりから学生ではなく既に社会人っぽいので、おそらくもう手遅れだろう。

2019/10/12(土) 16:44:14.47

>>635はそれ以前で、何を努力すべきか分かっていない状態だ。
といっても聞く耳は持っていそうだから、勝手にアドバイスしておいてやる。

>>607
基本的に出来るだけ最新の環境を使え。
新しいのは以前の問題点を修正したものだから、「以前」を知らない奴が古い環境にこだわる理由はない。
お前がまともにプログラミング出来るようになるまでにどうせ数年かかるから、
そのうち「古い」といわれている物に追いつかれる。
だから、自分が未熟で熟達できるまでに数年かかると自覚出来ているのなら、
今なら当然C++17以降の環境を使うべきだ。新機能を使うことに躊躇する必要はない。
お前は初心者なのだから。

>>635は完全に方向性を間違っているから止めろ。
C++は他言語と比べて3周ほど遅れていて、どのみち糞な書き方しか出来ないから、お前が今やるべきなのは、

std::vector<int> data = {1, 2, 3 ,4 , 9999999};
for (const auto& p : data) {
　std::cout << p << std::endl;
}

という糞な書き方を受け入れてその先のコードを書くことであって、
C++の糞さを回避することに躍起になることではない。
（ただ同様にここで引っかかっているこのスレの馬鹿C++erは多いようだが）

2019/10/12(土) 16:44:41.24

エレガントに書けなければ受け付けない、というのなら、まずはLL言語で学べ。例えばJavaScriptなら、

[1,2,3,4].forEach(v=>console.log(v));

と書ける。
LL言語で楽に書けるのはC++側も理解していて、今C++の糞な部分を修正していっている。
結果的にC++をLL言語に寄せて行っているから、LL言語で学べば先回り出来る。
むしろ、今の糞なC++でお前みたいなおかしなこだわりを持つのは時間の無駄でしかない。
それはC++標準委員会の仕事であって、お前がやるべき事ではない。
そもそもC++なんて速度チューニングする気無ければ使う価値のない言語だ。
お前らみたいな、OOPすら理解出来ないレベルの馬鹿が使う意味はないはずなんだがな。
(C/C++しかなかった昔ならさておき、今は他のもっとましな言語があるのだからそっちで入門すべき）

そしてお前ら、OOPを理解したいがコードが書けない、というのなら、何故>>572のコードを読まない？
全部読んだわけではないし、俺なら違う組み方にするが、
コード自体は普通にクラス分けされているし、普通にOOPだ。
むしろ普通すぎて読む価値なさそうだから俺は読むのを止めた。
が、お前らにはいい教材だろう。規模も小さくて手頃だ。
逆に、妙な構造になっていて、その善し悪しを議論したい、というのなら受け付ける。
俺はそういうことをするのがここの使い方だと思っているので。
ちなみに、シングルトン部分は意味無いというのは既に言ったとおり。
修正するほど悪いってわけでもないが。この辺はポリシーと好みだろうな。
（ただな、コンストラクタをprivateにして呼べなくする、というのは、
「シングルトンパターン」というのが認知されてない世界ではグーで殴られる案件だ。
そういう、コードを見てぱっと趣旨が分からないことは基本的にやるべきではないんだ。
実際、実体を一つに限定したいのならstaticまたはグローバルで済む話でしかないし)

2019/10/12(土) 17:09:32.41

staticと言われてもC++のstaticには色々な意味があるから
どの意味なのか

2019/10/12(土) 18:08:30.41

>>553の言う「スタティック」の意味だよ。
それが分からないのはお前の問題だ。

ただそれ以前に、これすら分からない奴がデザインパターン(ｷﾘｯやOOPする意味なんてまるでないんだよ。
だから何でもいいから1,000行規模の物をまず書けと言っている。
書くことがないのなら、(プログラミングを学ぶ必然性がそもそもないと思うが、それでもと言うのなら）
>>572のコードを読めと言っている。

2019/10/12(土) 18:23:14.92

ついでに言っておくと、>>553の5chの使い方は正しいんだ。
だから救済しようとしている。

上司が「シングルトンパターン(ｷﾘｯ」とかやってる馬鹿だと、
「いや、でもシングルトンってスタティックと何が違うんですか？」なんて質問出来ないだろ。
そういう「リアルでのモヤモヤ」を5chで問うのは正しい。
そして各自が勝手に有用かゴミかを自説と共に述べあい、どれがまともかは553自身が判断すればいい。
ここは本来そういうことをする場所だ。
お前らみたいなゴミがイキがる場所ではない。

2019/10/12(土) 19:35:00.48

だけど、どの意味でのstaticかでだいぶ変わるよ
>>553もどの意味で使ってるのか分からん
グローバルのstatic指定と関数内static変数とでは意味合いが大分違う
どちらもシングルトンな使い方が出来るからどっちかわからん

2019/10/12(土) 20:09:43.66

>>666
ならそれは区別する必要がないんだよ。
お前らにとっては受け入れ難いだろうけど。

例えば、名前空間A内の変数Bと、
グローバルにあるクラスA内のstatic変数（クラス変数）Bは、どちらも

A::B

でアクセス出来るだろ。
これは区別する必要がない、ということなんだよ。意味的には同じだから。

で、この「意味的には同じ」が通じないのはお前らがコードを書いてないからだ。
お前らがまずいのは「文法」から入ってしまっていて、「文法」が違うから全て別物だと思ってしまっている。
そうじゃない。「意味」から入らないといけない。
そして意味から入れば、>>553のような見解に自然に到達する。
お前らは「文法」にこだわりすぎだ。
どういう構造にしたいのか、それが重要なのであって、それをC++ではこう書く、でしかないんだよ。
だから本来のプログラミングを学べば、他言語に関しては文法を覚えるだけになる。

小説で言えば、伏線の張り方や殺人のトリックにこだわるべきであって、
それを日本語で書くか英語で書くかというだけの話だ。
ところがお前らは小説について日本語ガー英語ガーとしかやってないから駄目なんだ。

シングルトンが糞なのであって、どのstaticを使っても糞は糞だよ。
文法の話ではない。構造/構成の話だ。
分かるようにとどめを刺しておくと、珍妙カラクリである限り糞だ。
なお個人的には関数内static(local staticと表記されるようだ）は禁止でいいと思うが、
googleもいまいち歯切れが悪いのは、google内でも揉めているのだろう。
あれは要するにグローバルなクラスが出来るだけだから、名前空間/クラス文法があるC++で使う意味はない。

2019/10/12(土) 21:48:43.03

同じじゃないんだよ
使い勝手が全然違うから

2019/10/12(土) 21:53:22.68

関数内static
と
クラス内static、グローバルなstatic
では
使い勝手が全然違うから同じではないんだよ

どのstaticを使っても糞って言うのも意味不明で
プログラム中に一つだけ存在するものだってあるだろうよ
C++的には関数内staticで書くのが慣例
そんなことも知らないで5chでベテランぶって長文って、終わってるよ

>なお個人的には関数内static(local staticと表記されるようだ）は禁止でいいと思うが、
↑アホ

2019/10/12(土) 22:29:41.35

>>669
まあお前がそう思うならそれでいい。
ただ、お前はプログラミングに向いてないから止めた方がいい。

事実として認識すべきなのは、初心者でも>>553のように「意味」から入れる奴は居て、
その連中はそもそも自然に「スタティック」で通じている、ということ。
そしてお前はそうではない、ということ。

これは結局、「抽象思考」出来るかどうかであり、出来ない奴＝お前はプログラミングに向いてないだけ。
こればっかりは俺も対策の仕方が分からない。
一つ確実に言えることは、>>553は努力してその境地に達したのではなく、単に最初から出来るだけ。
そしてお前はそうではない、ということ。だから、向いてない。

大して違いはないんだよ。だから同じ static というキーワードで処理されている。
お前はそれを別物として覚えるタイプだ。それは記憶型であり、プログラミングには向かない。
これらは同じキーワードで記述出来ることが自然だ、と思えるタイプが抽象思考型であり、
プログラマとして大成出来る奴は全員このタイプだ。
だからこそ、プログラミング言語はこういう感じな訳でさ。
お前にとっては分かりづらい世界なのだろうけど。

デザインパターンの問題はここで、
記憶型＝プログラマとしては無能な奴に一縷の望みを与えており、結果、
彼等は他にすがる物がないから記憶量で勝負しようとしてパターンを覚えてｷﾘｯしたがってしまう。
それで良いコードが書けるのならよいが、そもそも無能な奴がパターンを覚えたところで無能に毛が生えた程度だ。
だから俺は何度も「デザインパターンを極めているつもりの奴はかかってこい、粉砕してやる」
と言っているわけでさ。あれは過度にありがたがるものではない。

向き不向きはあるんだよ。プログラミングも、無理してまでやるものではない。
おそらく高校物理で落ちこぼれになるか自然と優等生になるかと相似する。
高校物理も、出来る奴は努力したわけではなく最初から出来るし、無理な奴は努力しても無理なんだ。
それは記憶で対処しようとするからなんだけど、これを具体的に指摘しても修正は不可能なんだよ。
無意識領域の動作だから、対応出来る奴の方が少ない。

2019/10/12(土) 22:48:15.48

>>659
根本的に間違えてるぞ
お前に文句のあるヤツがここに来るんだ
文句のないヤツはとっくに移動している

たまにスレタイ見て紛れ込んでくる可哀想な被害者たちには誘導してやってくれないか

なおプログラミングに向き不向きがあるのは同意する
俺は向いてないわ

2019/10/12(土) 23:07:01.57

>>671
当たり屋かよ。しかし奇妙なほどに従順だな。

> たまにスレタイ見て紛れ込んでくる可哀想な被害者たちには誘導してやってくれないか
知るかよ。お前がやれよ。
俺が誘導に反対しないことは約束するし、実際に反対した試しもないはずだ。
そもそも話したいことが異なるから棲み分けしようとしているのであって、反対する理由もない。
文法/仕様についてはお前らの方が詳しいだろうし、お前らの話題は全部これなんだから、
お前らの本スレで全部済むはずだ。

2019/10/13(日) 00:17:00.56

> 文句を言われながらいちいち教えてやる意味はないから当然止める。

ああやめろ
おまえ自分の言ったことちゃんと実行しろよ

どうせ三日坊主で我慢できなくなってしゃしゃり出てくると思ったらやっぱりそうだな

2019/10/13(日) 01:16:31.64

>>673
数字も数えられないお前もプログラミングを止めた方がいいと思うぞ

ただそれ以前に、既に言ったが、
お前らは>>422が良いか悪いか、自信を持って言えないんだろ？批判されるのが怖くて
その程度なのに格好付けてイキっているから駄目なんだよ

2019/10/13(日) 01:32:55.16

>>674
お前は何かとあるとすぐプログラマーやめろだな
指導者には向いてないな
にも関わらず何かを教えたがる
しかも相手が知らないと決めつけて

俺からするとお前指導者向いてないわ
人に何かを教えたがるのやめた方がいい
ハッキリと向いてないと分かる
でもやめないだろ？

だからもう、プログラミング辞めろとか寂しいこと言うなよ
これだけ言っても分からないなら、お前人間向いてないわ

2019/10/13(日) 01:51:56.98

おっと、>>422についてのコメントを求められてたな
俺自身はオブジェクト指向ではないと思うが、オブジェクト指向との関係は密接にある実装だと思うね

似たようなコードの例を挙げるなら、例外クラスだ
Exceptionクラスにほぼ全てを書いて、FileNotFoundExceptionやValueErrorExceptionは継承して何も書かない
使い方もメッセージを投げるだけなので良く似ている

では例外はオブジェクト指向の一部か？と言われると答えはNoだ

2019/10/13(日) 03:23:32.13

>>675
実際おまえは何も知らない癖にイキってるだけだろ。
話の流れからして2重mutexなんてまるで思いつきもしなかったのを必死で繕ってる。
それが間違いなんだよ。性格的にプログラマに向いてない。

そもそもお前の性格で匿名掲示板を使うのが間違っている。
お前が繕う理由は何よ？
他の連中はあっけらかんとしてるし、俺がズバズバ言っても別に、って感じだろ。
>>555とかテヘペロだが、それを恥ずかしがってもないだろ。
俺みたいにコテハンレベルまでキャラが立っているならともかく、
1週間でワッチョイも消えるここで格好付ける必要なんて無いだろ。

そしてそんな性格だと一生、GitHubでソースを公開するなんて怖くて出来ないだろ。
実際のプログラマは逆で、OSSでソースを公開しまくってる。
当然技術レベルも丸わかりだ。この意味では、精神的ヌーディストだ。
ただ、それがプログラマという人種だ。そうなれないのなら、向いてないんだよ根本的に。

優しく言ってくれ、というだけなら、それもプログラマに向いてない。
プログラミングは自己完結してる奴じゃないと上達しない。
>>635とかは完全に自己完結してて暴走してるだろ。この「自己完結の暴走」が上達には重要なんだ。
ただ、こいつは方向性がおかしすぎるから、修正してみただけ。
ちっとこの糞女は生真面目すぎる気もするが、正しい方向に暴走出来るのなら大化けする可能性はある。

> だからもう、プログラミング辞めろとか寂しいこと言うなよ
効いてる宣言かよ。お前は5chがどういうところか分かってねえな。
優しく言って欲しければteratailみたいな固定ID制のところに行くべきだ。
俺は向いてない奴に向いてないと言ってるだけ。見解は間違っているかもしれないが、嘘はついてない。
固定ID制で、嫌われるのを恐れて、向いてない奴にも向いているとうそぶく方が問題だと俺は考えている。
そしてこういう価値観の奴が集うのが本来の匿名掲示板だ。
嘘を優しく言う方が正しいと思うなら最初からteratailに行けよドアホ。

マジな話、お前はプログラマを辞めた方が幸せになれると思うぞ。いろんな観点から見て。

2019/10/13(日) 03:32:28.46

>>676
そんなこと聞いてないわ馬鹿タレ。
>>422が良コードか糞コードか、糞コードと思うなら422よりもマシなコードを出せ、だよ。
そしてそれをお前ら同士でやり合えば切磋琢磨してお前ら同士で上達して行ける、
だからそれをやれ、と言っている。

ただそれについては俺はもう回答しないぞ。
>>673も再度駄目押ししてきたし、お前も
> たまにスレタイ見て紛れ込んでくる可哀想な被害者たちには誘導してやってくれないか
と来ている。お前ら自身もその意味は分かってるんだろうが、俺も駄目押ししておいてやる。

そもそもどっちに投稿するかは投稿者の自由だ。
俺がこっちにいて、本スレには投稿しないということも知っていて、
それでもなおこっちに投稿するのは、俺に対する賛成票だ。
それは俺の投稿の質の方がお前らゴミ>>673>>676より上だとその投稿者が判断した、ということだ。
だからお前らはこのスレが流れてくれては困る。それで671,673の投稿になる。
まあ頑張って本スレ盛り上げとけ。
それでもこのスレが流れるようなら、俺の投稿の方が総合的に見て上だということでしかない。
その時はちゃんと負けを認めろ。

ただマジな話、お前らはコードの善し悪しを議論出来るレベルにない。
だからまずはコードをガシガシ書いた方がいい。
そして議論するならお前らの糞コードではなく、まともなOSSでやるべきだ。
だから>>572のコードを読んで「ここはこうした方がこういうメリットがあると思うが、どうか」
みたいな議論については受け付ける、と言ったんだよ。
ただまあ、お前ら671,673からは受け付けない。お前らは俺には何も言って欲しくないんだろ？
>>676とか書いてて、お前自身は惨めじゃないのかよ？喧嘩売るならちゃんと売り続けろよドアホ。

2019/10/13(日) 03:44:41.90

>>674
数字？　おまえまさか、三日坊主の他に四日坊主とか五日坊主があるとでも思っているのか？
日本語学校にそういうジョークを言うやつがいたんだろうけど、おまえ騙されてるぞｗｗｗ

2019/10/13(日) 03:50:37.39

ゴチャゴチャうるせえんだよ
自分の言ったことができねえゴミが
嘘つきを指摘されて逆ギレしてんじゃねえ

とっとと失せろ

2019/10/13(日) 08:02:24.48

>>677
お前本当にアホだな
二重のmutexなんて古くから使い古された技術を、お前が言うところの記憶型の俺が知らない訳ないだろw
誰でも知ってる技術を、どうだお前知らなかっただろうと言ってる姿が滑稽だと言ったんだ

2019/10/13(日) 08:09:00.90

> どうだお前知らなかっただろうと言ってる姿が滑稽

その昔、いたね
そういう芸風のコメディアンｗ

2019/10/13(日) 08:37:04.39

長文にする必要ないのに長文にするってのは
頭が悪くて纏める力がない証拠
彼の書くコードもこんな感じなんだろうな

2019/10/13(日) 08:42:41.94

もう一度書いておくか

>なお個人的には関数内static(local staticと表記されるようだ）は禁止でいいと思うが、

これだけでアホってわかる

2019/10/13(日) 08:53:15.32

アメリカンジョークでもどうぞ
https://eigo-box.jp/others/jokes/#9_idiot

2019/10/13(日) 09:18:47.10

>OSSでソースを公開しまくってる。
>当然技術レベルも丸わかりだ。この意味では、精神的ヌーディストだ。

面白いなw
なんで自分がコード公開を好きではないのか
技術レベル以外の理由が解った気がする
最近はgplじゃなくてmitとかそれ系統が増えて安心している

2019/10/13(日) 09:47:32.91

だいたい普通にプログラム書いてたら関数内static変数は結構使うはずなのに
それを要らないって言うのはまともにプログラム書いてない証拠
書く量が足りてない赤ん坊