TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼
新言語を開発したい
3Dアルゴリズム全般
VBAなんでも質問スレ Part2
くだらないアルゴリズムを考えるスレ
Lisp Scheme Part40
Go の宿題片付けます
【PHP】下らねぇ質問はここに書き込みやがれ 2
くだすれFORTRAN（超初心者用）その6
プログラム板自治スレッド　その16
ふらっと C#,C♯,C＃（初心者用） Part143

C++相談室 part138


1 ：2018/08/05 〜 最終レス ：2020/05/14
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

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

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

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
http://mevius.2ch.sc/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

2 ：
STLつかうと一気に実行ファイルサイズが10倍に?！

環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない

すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。

C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？

#include <stdafx.h>
後R。

言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。

---- テンプレ ここまで ----

3 ：
>>2
テンプレ乙ｗ

4 ：
おすすめのC++を教えてください‼

5 ：
MIWA C++

6 ：
rad c++ builderでファイルの入出力やドラッグ&ドロップ　簡単なdb操作は出来る様になったけど、もう一歩踏み出したいです


福岡当たりで勉強会みたいなのはないでしょうか？

大阪、東京でも有るなら飛行機使っていきたいです

7 ：
6です
c++ builderのスレッドが合ったので
そちらで聞いてみます

失礼しました

8 ：
>>6
「C++ の勉強会」
なんだか魅惑的な響きですね…

9 ：
関数内にstaticつけたクラス変数定義した場合、
コンストラクタは関数を最初に呼び出したときだけ呼ばれると思います。
これはどういう仕掛けなのですか？どこかにフラグがこっそり用意されるのでしょうか。

10 ：
>>9
前提が間違い
よって無術

11 ：
>10
ちょっと書き方間違えました。
定義ではなく宣言です。

間違ってますでしょうか？ではコンストラクタが呼ばれるタイミングはどこでしょうか

12 ：
>>9
クラス変数とは言わないよ

そのとおりフラグがある
さらに11か14かは忘れたけどmt safeにもなった
つまり同期プリミティブも裏で作られている

13 ：
>>9
コードで書いた方がいい。
どうせ用語を間違っていて、正確には通じてないから。
エスパーで話すのもありだとは思うけど、回答を信頼出来ないだろ。

14 ：
virtualなデストラクタを持たないクラスを継承しているクラスを派生していない状態でコンテナ等に入れた場合、
エラーまたは警告にする方法ってある？

典型的な「デストラクタをvirtualにしろ」のケースであり、
安全性だけを取るのならそうすれば済むのだが、大量使用したいのでコストを限界までケチりたい。
可能であればコンパイラにチェックさせたい。


具体的に言うと、Matz曰く「実装が漏れてる」の典型的なケース、配列について、
長さと先頭のポインタをstructにして、各操作をそれに対するメソッドとして記述し、
スクリプト言語風に簡潔に書けるか試したい。
std::spanの再実装に近いので、そちらで言うと、
https://github.com/tcbrindle/span/blob/master/include/tcb/span.hpp
std::spanを継承して各種メソッドを生やし、（クラスM）
さらにそれを継承して以下3つのコンストラクタを持たせる。

クラスA. 型と既存ポインタと長さからの生成
クラスB. 型と長さを与え、allocaでの生成
クラスC. 型と長さを与え、heap上への生成

A,Bは問題ないが、Cはデストラクタでdeleteをする必要がある。
ここでstd::spanのデストラクタはvirtualではないので、（上記実装例の場合）
vector<C>をvector<M>等と間違えたら不味い。
このときに、警告またはエラーを発生させたい。

15 ：
もう一つよろしく。

C++でkey/valueソートしたい場合は
・std::unordered_multimap等にコピーしてからstd::sort
・自前で<key,value>を含んだ構造体を用意し、それに < を定義して、コピーしてstd::sort
のどちらかって感じ？
ちょっとまどろっこしいので、もう少し簡単な方法無いかな？

doubleの配列をソートした際、何番目がどこに行ったか追跡したい。
.NETだと Array::sort(array0, array1) があり、
array0 に double の配列、
array1 に [0 ... N-1] な配列を指定しておけば、array1の結果で簡単に追跡出来た。
記法が原始的ではあるが、結果的にはこっちの方が楽で良かった。
std::sortで2つの配列を取る物があれば助かるのだが、なさそうだし。
boostも見たが、よく分からん。

16 ：
抽象型のメソッドを使ったときにも型を失わず、派生型のままで返す方法って無いよね？
継承を使わず、テンプレートで展開するしかないか？
コード上で展開されるのが、多少勿体ないんだが。

>>14の実装で、
各種メソッドをクラスMに突っ込み、それを継承していると、
Cからメソッドを呼び出した際、どうしてもM&等の型しか返せず、
ダウンキャストがいちいち必要なのがウザイ。

具体的には、fromは既存の配列からコピー、sortはソートするメソッドとして、メソッドチェーンで初期化する際、

C& test = (C&)C( ... ).from( ... ).sort();

となり、fromやsortがM&を返すのでC&にダウンキャストする必要がある。
従来方式の初期化して使用なら問題はない。
コンストラクタは派生型を返し、メソッド群はM&で閉じているので。

A& test = A( ... );
test.from( ... ).sort();

メソッドをvirtualにすれば回避出来るはずだが、無駄にvirtualにしたくない。
B/C共に全く同一の関数で済むはずなので、可能で有れば共有したい。
諦めてB/C毎に同じ関数をtemplateで展開すれば出来るのは分かるが、これはしたくない。
何か方法有る？

17 ：
そもそもなんのためにMから継承してんのか考えてみたら

18 ：
>>17
オブジェクト指向ではMで閉じるというのが正しいと思いこんでるんだろ。
それは一面にすぎない。

JavaScriptではメソッドチェーンで型を失わない。
だから上記のようなことも平気で出来る。
勿論C++でも実装を別々にすれば出来るが、ダブる分無駄に膨らむ。
或いはvirtualにしても出来るが、これはポインタ一つ分データが膨らみ、呼び出しも遅くなる。
最適化した状態での記述方法がない。

今回、AとCの違いはデストラクタ内で解放するかどうかだけであり、
当然全てのメソッドは共有出来る。
順当なら継承が妥当だが、virtualにしないと型を失ってしまう。
(この点、全てvirtualであるJavaはオブジェクト指向原理主義としては筋が通っている）

19 ：
ちなみに技術的には、super に対するキーワード derived が足りないのだと思う。
クラスM内で、

M& from(){ ... ; return *this;}

ではなく

derived& from(){ ... ; return *this;}

と出来て「呼び出した型」を返せれば全く問題ないんだが。
この辺のキーワードって無いよね？

20 ：
なんだ、JavaScriptという一側面だけ見てC++に立ち向かってるアホだったのか
まぁがんばれよ

21 ：
C++がメソッドチェーンに向いてないのは確かだよ。
それ向けの文法も用意されてない。
多分「継承」に対して型を失うこと自体が間違いなんだよ。
C++はそこら辺が古い。

ただ、ダブって良ければtemplateで解決出来るのも確かだが。

22 ：
JavaScriptの場合は型が失われないんじゃなくて「無い」んだな。
レシーバの型に関係なく呼び出せてしまうだけ。

23 ：
>>20
あとついでに言うと、その選民思想はマジで止めろ。
C++だけの話でもないが。

というより最近「俺がやってる言語スゲー」な奴が多いのは何でだ？
一昔前は全員Cが出来、その上で他言語だったから、その手の争いは皆無だった。
それ以前にプログラミングがきちんと出来れば、後は文法だけの問題だから、
多言語化は容易だし、実際全く問題ない。
「俺の言語スゲー」でイキれる奴って文法しか見えない馬鹿のような気がするが。

C++はコンパイラ向けの文法ばかり多くて、本質的なプログラミング用の文法は多くない。
今回も、JavaScriptだと容易に実現出来るのに、C++だと記述出来ないだろ。
あまり他言語を馬鹿にしていると足をすくわれるぞ。

24 ：
CRTP使えばどうだろう？

template <typename Derived>
class M {
public:
Derived &from(){ return static_cast<Derived &>(*this); }
};

class A : public M<A>{};
class B : public M<B>{};

25 ：
>>22
まあその通りだが、

C++： 記述出来ない
JavaScript： 動的型なのでそのまま書けるし、動作する
Java： 全部virtualだからそのまま書ける（ただし、これでいいのならC++でも書ける）
Go： 継承を廃止してしまったからそもそもこの問題は発生しない？
Rust： ちょっと見たがよく分からん

まあ俺はやっぱり、「継承」で親の関数を呼んだら型が失われるのは間違いだと思うよ。
仮に Z : Y : X と継承していたとして、
(Zの実体).(Xのメソッド).(Yのメソッド）　とは出来ないでしょ。(Xのメソッドの時点でX&になるから）
これはメソッドチェーンする気なら使いにくい。
（これまでは居なかったから問題にならなかっただけ。バラバラに書けば出来るので）

26 ：
>>24
とりあえず今はそれで実装してる。
それが16で言ってる
> 諦めてB/C毎に同じ関数をtemplateで展開すれば出来る
というやつ。
ただどう見ても無駄なので、可能で有れば実体も一つにしたい。

27 ：
>>26
> ただどう見ても無駄なので、
どのへんが無駄なのか教えてほしい

28 ：
>>27
テンプレートは型毎に展開されるし、自明では？
むしろ通じない方が不思議だ。

仮に俺が言ったように19の表記が出来れば、
オブジェクトコードはその部分は半分で済むし、命令キャッシュのヒット率も上がる。
勿論C++でもvirtualにすればこれらの点は解決するが、
呼び出しが遅くなってデータオブジェクトもポインタ一つ分膨らむだろ。

今のC++では最適化したオブジェクトコードを吐かせる記述が出来ない。

29 ：
C++コンパイラの気持ちになって考えてみなよ
お前の望みは無理だから
どうせベンチとらずに遅いとか言ってんだろ
だまってvirtual使うかダウンキャストするかそもそも継承使わないかどれかにしとけ

30 ：
>>29
ベンチ取らなくても自明だろ。
そしてC流の「手動」オブジェクト指向なら、自分で関数を手動で切り替えるのだから、実現出来るんだよ。

ただ、現実的には、derived等のキーワードが出来ればC++でも普通に可能だぞ。
単一継承ではthisの値は型によらず同じだし、
この場合に親のメソッドを使ったら親の型になるというのは、
純粋に「コンパイラがエラーを検出するだけ」の為であり、実装には何ら影響がない。
だからコンパイラがエラー検出さえしなければ通るし、そのまま動作するコードになる。
C++は過剰にエラーを検出しているだけなんだよ。

31 ：
なお、やっぱ継承じゃないと使いにくいわ。

A/B/Cってのはコンストラクタ/デストラクタだけの違いだから、
他から呼び出すときは型Mにして多態したいのだが、
CRTPだとこれが出来ないorz

32 ：
必要なのは「ダウンキャストの型推論」か？

文法的に見てダウンキャストが安全な場所はあるだろ。例えば、25の
> 仮に Z : Y : X と継承していたとして、
> (Zの実体).(Xのメソッド).(Yのメソッド）
とか。
X& → Y&のダウンキャストも自動アップキャストと同様出来てもおかしくないし、これが有れば解決だ。
「ダウンキャストは悪」って事で止まってしまってるだろ。
もっとも、全部virtualで単一継承ならダウンキャストはほぼ要らないのも事実だが。

33 ：
↓こっち先使おう。
C++相談室 part137
https://mevius.2ch.sc/test/read.cgi/tech/1535353320/

34 ：
自己修正。

>>28
> 今のC++では最適化したオブジェクトコードを吐かせる記述が出来ない。

これは間違いだった。
いちいちダウンキャストすれば(ソースはうざくなるが)最適なオブジェクトコードが出る。
ダウンキャスト忘れはSyntaxErrorだし、妥協するならこっちかも。

35 ：
Mを継承してるのが間違い
Mは実装を共通化してるだけだろ
Mをコンポジションにしてデリゲート
C++ならprivate継承にしてデリゲートはテンプレートにすりゃいい

36 ：
>>35
それで何が嬉しいんだ？
記述も無駄に増えるし、何もメリット無いように思うが。
(Mへのデリゲートの部分が余分に必要）

どうせ委譲部分を全部書く気なら、
コンポジションせずに単に自前で戻り値をダウンキャストした方がいいと思うが。
例：

Class C : M {
C& from( ... ){
return (C&)((M*)this)->from( ... );
}
};

コンポジションにすると上記のアップキャスト部分(M*)が必要なくなるが、
その分無駄にポインタ一つ分データが膨らむだろ。
上記のダウンキャスト/アップキャストは実行コード上には現れないのだし、
2段呼び出しを省いてくれる最適化がかかるのなら、
呼び出し側でダウンキャストする必要が無い為、まあまあ。
(ただしfromの実体と委譲でクラス側のソースコードは増えるが)

37 ：
ちなみに単純な実装なら
「呼び出し側でダウンキャスト必須」になってウザイのだが、
C++的にはこれが正しいような気がしてきた。
俺にはこれは「過剰な型チェック」にしか見えないが、C++はそういう言語でもある。
コンパイラのチェックから逃れる為にデータ構造を変更するのは本末転倒だし。

ダウンキャスト撲滅教の信者は、次から
・derived等、継承で親のメソッドを使ったときにも「呼び出し側の型」を返す為のキーワードの整備
・ダウンキャストの型推論
のどっちかをプッシュしておいてくれ。

38 ：
ダメだこりゃ

39 ：
傍から見ていると、メソッドチェーン自体なにが嬉しいんだろう、と思ってしまう。

40 ：
一票だなぁ

41 ：
>>38-40
そりゃ君らが老害だからだよ。

老害ってのは肉体的な年齢のことではない。
好奇心/興味を失った結果、新しい価値観を認めないから老害となる。

新しい言語を見てみろ。全てメソッドチェーン出来るだろ。
最初は戸惑うかもしれないが、慣れれば相当便利なんだよ。簡単に凝集度を上げていける。
もう1行に1個ずつ処理を書いていていい時代じゃなくなりつつあるのさ。
とはいえ、クラスも当初は無駄だと言われていたのだろうし、今ならラムダやLINQが該当するのだろうけど。

42 ：
thisポインタ返すメソッドチェーンってクソだろw
perl脳と同じ

43 ：
おかしな主張を生暖かく見守っていたのに、そんなストレートな御意見を

44 ：
さて、続き。
C++で『デストラクタありの』オブジェクトを返すとき、お前らどうしてる？

α： しない。上位関数でオブジェクトポインタを渡して上書き。(Cスタイル)
β： スマポで渡す。（スマポ教）(=CLIスタイル)
γ： reinterpret_cast。 ← とりあえず今の実装
Δ： 他に何かある？

非常に当たり前だが、
戻り値として一時オブジェクトを用意すると、それのデストラクタが実行されてしまうことに気づいた。
(今更なのだが、これまではVC++/CLIでCまたはCLI(managed)スタイルで書いていて、
C++(unmanagedまたはネイティブ)スタイルはほぼ使っていなかったから気づかなかった)
これでは困ったことに、関数呼び出しで初期化がやりにくい。
具体的に、駄目なコードは以下。

45 ：
template<typename T> struct M { // メソッド群
T* ptr;
int length;
T& operator[](int idx){return ptr[idx];}
M(int length, T* ptr) : length(length), ptr(ptr){}
M& from( ... ){ ... ; return *this;}
M& sort(){ ... ; return *this;}
// M& alloc(int length){ ... ; return *this;} // --- (α）
// M(int length) : length(length), ptr((T*)malloc(sizeof(T)*length)) {} // --- (γ）
};

template<typename T> struct C : M<T> {
C(int length) : M(length, (T*)malloc(sizeof(T)*length)) {} // heap上に確保
~C(){free(this->ptr);}
};

C<double> calc_result_vals( ... ){ // --- （γ）
calc_result( ... ); // in-placeで結果が計算される。
return (C<double>&)C<double>( ... ).from( ... ).sort(); // 結果をコピーしてソートして返す
} // <----ここでCのデストラクタが実行される

void test(int num){
MyContainer<C<double>> vals(num); // アロケーションのみ --- （β）
for (int i=0;i<num;i++) vals[i] = calc_result_vals( ... ); // 初期化 --- （α）（γ）
}

46 ：
内容はこれまで通りだが、再度説明する。
Mはメソッド群を持つベースクラスであり、メンバ変数はポインタと長さのみ。
つまりshared_ptrと同様のヘッダであり、データは別区画にある。
Cのコンストラクタでデータエリアをheap上に確保する。
testではコンテナを用意し、各インスタンスを calc_resut_vals() によって初期化する。
Cはヘッダなのでコピーでいい。(32bit環境なら8Bytes)

というノリだったのだが、GC言語ではこれでいいが、C++では前述の通り動かない。
calc_result_vals 終了後に戻り値Cのデストラクタが実行され、データエリアが開放されてしまうからだ。
(ヘッダ自体はコピーされるが、中身が無効アドレスを指した状態になる)
このとき、お前らどうしてる？

まず思いつくのはCスタイル（α）だ。
test内の初期化を、戻り値ではなくポインタで渡し、子関数で上書きさせる。
for (int i=0;i<num;i++) calc_result_vals(&vals[i], ... ); // --- （α）
しかしやっぱ代入形式で書きたいのと、
一時オブジェクトを作らない為には、
Containerでmallocではなく各インスタンスをnewして空として初期化し、（ここまではまあいいが）
そこに上書きでポインタを初期化するというおかしな操作(allocメソッド）が必要となる。
これが流れ的にイマイチ。

スマポ教団なら全てスマポで対応しろ、か？つまりtest内のコンテナを
MyContainer<shared_ptr<C<double>>> vals(num); // --- （β）
とし、calc_result_valsはshared_ptrを返すというもの。
しかしこれは無駄にスマポを介している分ウザイし、速度も遅い。
とはいえ型には矛盾が無く、フローとしては綺麗ではある。
(GC言語は実質的に全てこれ)

47 ：
型なんて飾りですよ、なら、MにC同様のmallocするコンストラクタを用意し、
calc_result_vals上で作る一時オブジェクトはCではなくMとし、（デストラクタが空）
代入時にキャストして強引に突っ込む、とも出来る。
M/Cの区別は「heap上に新規作成するか」ではなく、「寿命を管理するか」に変わる。
M<double> calc_result_vals( ... ){
calc_result( ... );
return M<double>( ... ).from( ... ).sort(); // Mを一時的に作り、Mを返す
} // デストラクタは空なのでheapは解放されない
for (int i=0;i<num;i++) *(M*)&vals[i] = calc_result_vals( ... ); // キャストして強引に突っ込む（γ）
代入形式で書けるし、最速コードはこれだが、強引過ぎか？
ただC++でこれやったら最適化によっては死んだような…

お前らどうしてるよ？
他の方法（Δ）が有れば是非。
なお、「Cを継承したDを作り、Dのコンストラクタ内でcalc_result_valsを呼んで初期化」は
無意味に結合が増えそうなので却下。

48 ：
>>41
関数型言語で使われるパイプラインとの区別もついてないんだろうねぇ。
mutableなオブジェクトに対して連続的に操作を行う際にレシーバの記述を
省略できるというだけでしかないのに。

49 ：
>>48
意味不明。そもそも俺は「パイプライン」知らんし。

以下見る限り、データをメソッドで処理するのではなく、
データをメソッド配列（メソッド関数ポインタ配列）にくぐらせる感じか？
> https://postd.cc/an-introduction-to-functional-programming/
しかし今回は演算結果をコピーしてソートして返すだけだから、どっちでも変わらん気もするが。
callが使えればパイプラインも生きるのかもしれんが。

50 ：
>>44
スマポかムーブ

51 ：
α':参照渡し
Δ:move (デストラクタは動くけどコストは低くなる)

52 ：
お前らどうしてる？で吹いたわ

53 ：
>>50-51
おおサンクス。ムーブ忘れてたわ。

つっても俺の今の環境(VC++2008)だと出来ないっぽいが、この場合は正しくはムーブだろうね。

54 ：
class C : public Mのときに
c.chain().chain.chain()で戻り値がCの型のオブジェクト指向の静的型付き言語を知らないんだけどあるの？
少なくともc++、c#、java、kotlin、swiftはできない

55 ：
ダウンキャスト推論しろとかね
タイプセーフを何だと思ってんでしょ

56 ：
一応報告。
色々調べた結果、placement new を使えばαの時の「未初期化のthisを使う」気持ち悪さは無くなることが分かった。
これとムーブを比べると、以下。

Cスタイル(α）：
× 代入形式で書けない。
◎ 最初から最速コードが出る。(costructのみ）

ムーブ：（俺の環境では）
◎ 代入形式で書ける。
△ダウンキャストを書く必要がある。
× return (C<double>&)C<double>( ... ).from( ... ).sort();だと全く最適化されず、
　construct/copy/destruct/move/destructとなる。
△ C<double> retval(pat->num); retval.from((double*)pat->result).sort(); return retval; とベタに切ると、
　NRVOが一つだけかかり、construct/move/destruct となる。
(opereator=のオーバーロードが最適化に影響しているかも試したが、関係なかった)

いまいちソースは美しくないが、速ければいいだけならCなのはいつも通り。
(NRVOの最適化済みソースを手動で書くのだから当然）
ムーブにするか、いっそのこと代入/コピー禁止でunique_ptrの機能も持たせるか考え中。

57 ：
コンテナを自作しようとしているのだが、デストラクタの書き方が分からない。
教えてもらえないだろうか。


（自信は持てないが)
俺の理解では、コンテナのデストラクタは中身のデストラクタをキックする必要があって、
今は以下のように書いていて、それなりに動いているように見える。

~MyContainer(){
for (int i=0;i<length;i++) ptr[i].~T();
}

要するに中身のデストラクタを一つずつ直接呼び出している。
ところが、例えばGNUのvectorのデストラクタは空だ。

> 00126 ~vector() { }
> https://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a01115_source.html

これはどういう事なのだろうか？
他に参考になるソースでもいいから教えてもらえれば助かる。
なお、以下では俺と似たようなことをやっている。

> ~Stack () throw()
> {
> std::for_each(array_, array_ + top_, destroy<T>);
> ::operator delete(array_); // グローバルスコープの delete 演算子
> }
> https://ja.wikibooks.org/wiki/More_C%2B%2B_Idioms/%E6%B1%8E%E7%94%A8%E3%82%B3%E3%83%B3%E3%83%86%E3%83%8A%E4%BD%9C%E6%88%90%E7%94%A8%E3%82%A4%E3%83%87%E3%82%A3%E3%82%AA%E3%83%A0(Generic_Container_Idioms)

58 ：
>>57
vectorは所持するアロケータがメモリの管理をすべてやっているから
vector自身のデストラクタでは特にすることがない

59 ：
>>58
なるほど。
ではそのアロケータのdeallocateメンバ関数は誰がキックするんだ？
俺はそれが vector のデストラクタに書かれているのかと思っていたんだが。
以下参考。

> C++11では、std::allocator_traitsというアロケータアクセスの中間インタフェースが用意されたおかげで、
> 自作アロケータに必要な実装がだいぶ減りました。
>
> 自作アロケータに必要な最小コードは、以下のようになります。
>
> 要素型value_type
> 特殊関数(デフォルトコンストラクタ、コピーコンストラクタ、ムーブコンストラクタ)
> 別な要素型のアロケータを受け取るコンストラクタ
> allocate()メンバ関数。(hintパラメータはあってもなくてもいい)
> deallocate()メンバ関数
> operator==とoperator!=
> https://faithandbrave.hateblo.jp/entry/2014/02/14/160506

60 ：
>>59
アロケータのデストラクタじゃね？

61 ：
>>60
vector内部にallocatorを持っている場合、
allocatorのデストラクタはvectorのデストラクタが呼び出してやらないと連鎖しなくね？

なお、以下ではやはり自分のデストラクタででfreeを呼び出し、その中でalloc.deallocateされてる。
> StrVec::~StrVec() { free(); }
> https://books.google.co.jp/books?id=P1D5DAAAQBAJ&pg=PT746&lpg=PT746&dq=deallocate+%E5%91%BC%E3%81%B3%E5%87%BA%E3%81%97&source=bl&ots=1rmEQsOAY0&sig=
NRKyLHuLVtPQK5Yb2Nk_YU_pTNs&hl=en&sa=X&ved=2ahUKEwjCwe_q3sTdAhUNQd4KHc2FDi0Q6AEwA3oECAcQAQ#v=onepage&q=deallocate%20%E5%91%BC%E3%81%B3%E5%87%BA%E3%81%97&f=false

62 ：
いろいろと間違ってる

> for (int i=0;i<length;i++) ptr[i].~T();
> 要するに中身のデストラクタを一つずつ直接呼び出している。

こんなことする必要ない
ﾃﾞｽﾄﾗｸﾀはｲﾝｽﾀﾝｽが消滅するまえに自動的に呼ばれる

↓ｺﾚはdebug用　みるｿｰｽが適切じゃない
> https://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a01115_source.html

00078 #ifdef _GLIBCXX_DEBUG
00079 # include <debug/vector>　←　ｺﾚをみてる
00080 #endif


↓こっちみなさい
https://gcc.gnu.org/onlinedocs/libstdc%2B%2B/libstdc%2B%2B-html-USERS-3.4/stl__vector_8h-source.html
00268 ~vector()
00269 { std::_Destroy(this->_M_impl._M_start, this->_M_impl._M_finish); }

63 ：
>>62
おおサンクス。見るソースを間違えていたか。

なお俺が作ろうとしているのは「コンテナ」な。
だからデストラクタの連鎖の開始をキックする必要がある。
そのソースでもされてるだろ。

64 ：
×　デストラクタの連鎖の開始をキック
○　デストラクタの連鎖をキープ

開始のキックはコンパイラによってされるが、連鎖は手動でキープしてやらないと次に続かない。
コンテナの場合はこれが必要なはず。

65 ：
newはどうしてるんだい？
placement new？
それなら自分でデストラクタ呼ぶので正解
普通のnewなら、普通にdelete

66 ：
>>65
ああ、目の付け所はそこで合ってる。
先に言っておこうかとも思ったが、話が無駄にずれるので止めておいた。

わざわざコンテナを作ったのは、コンテナ領域をallocaで確保したかったから。
そこに結果的に placement new して、ヒープ領域にデータ領域を持ったオブジェクトを配置してる。
だからそれらを解放してくれないと不味い。
そのデストラクタをコンテナのデストラクタからキックしている。
(というか、これをやらせる為に簡易コンテナにした。
単にallocaで可変長配列を確保してその中に入れただけでは、
デストラクタを起動するコードが『自前で、上位側に』必要であり、これがC++の思想と反するから）

要するに alloca をもっと使ってみようというテストなのだが、
「コンストラクタで領域を確保出来ない」（関数呼び出しでは初期化出来ない）のが地味に使えない。
C++は何故か forceinline までも「無視していい」という仕様にしているようだし。
(inlineは無視してもよく、forceinlineは無視しては駄目、という仕様に普通はするだろ）

ただ、自作アロケータを既存のコンテナにはめ込めるのなら、その方がいい。
この解があるなら alloca がいらない子扱いなのも道理だ。

67 ：
>>37
＞・derived等、継承で親のメソッドを使ったときにも「呼び出し側の型」を返す為のキーワードの整備
合ってるかどうかわからんけど、共変の戻り値じゃあかんのけ？

68 ：
>>66
コンテナが可変長でスタック上にplacement newで置く
中身は普通にヒープなの？
不思議なもん作ってんのなw
それなら中身はコンテナのデストラクタでdeleteするだけじゃん

69 ：
>>67
駄目だな。
仮想関数にしないといけないのと、
それは子が子のままでいられるだけであって、子が親のメソッドを使った後も子で居続けられるわけでない。

> 実際に取得する型が親クラスに引っ張られないメリットを享受できる
> 自分自身の型を返す関数を定義する時など、親クラス固定だと、受け取った側でのキャストが面倒ですしね。
> http://cpp.aquariuscode.com/covariant-type
やはり既知の問題ではないか。

(C++しか使ったことがないなら意味が分からないと思うが)
JavaScriptの場合はクラス階層とインスタンス階層が分離しており、
各インスタンスはクラス階層を派生させてを作る。
だから元々親階層のメソッドから子階層のメンバ変数を参照出来るし、それがデフォの使い方だ。

クラス階層とインスタンス階層は文法的には違いが無く、クラスも継承出来るが、インスタンスも継承出来る。
これを上手く使えば、メモリを大幅に節約することが出来る。
C++にはこの記述能力がない。
理由はクラスとインスタンスが明確に分離しているからだ。

JavaScriptの挙動をC++用語で言えば、
thisが常に仮想thisであり、メンバ変数は全部仮想メンバ変数となっている。
だから親のメソッドを使っても派生型のままであり続け、自由にメソッドチェーンが出来る。

ただしここら辺はやや宗教的でもある。
親クラスの関数が派生クラスの変数を操作することを「仮想this」で実現するなら、
型安全ではなくなってしまう。
ただし実装は、単一継承の時には単に型チェックを外すだけと、極めて簡単であり、やる気だけの問題だ。
(ただしC++の場合には多重継承があるので若干問題がある）
なお、型安全を取りたいなら、仮想thisではなく、仮想メンバ変数で実現する事になる。
こちらはC++でも問題はない。（ただし動作速度が遅くなるが）

70 ：
>>68
当初は delete &ptr[i]; と記述していたのだが、これは
1. ptr[i].~T();　(各エレメントのデストラクタのキック）
2. free(ptr[i]); （メモリ区画の解放）
の2つを実行するらしくて、駄目だった。
今の各エレメントはallocaで確保した区画に placement new しているので。

> 不思議なもん作ってんのなw
今回は事前に全部計算してalloca出来るが、
コンテナ長だけ親で確定、中身の長さは子でしか確定出来ないことも普通にあるだろ。

例えば、LGBT共のおかげでFacebookには56種類の性別があるらしいが、
これに対して、無作為に10,000人の性別を調査するとして、
コンテナ長は56で親で決まるが、
各性別人リスト長は子関数で調査しないと決まらないだろ。そこをheapに取ってる。
勿論、親も含めてheapに取り、ジャグvectorとするのがC++流であり、だからC比でいちいち遅くなる。
そこら辺を改善出来ないかのテストだ。

71 ：
ああ、いつぞやのJS厨か・・・相手にするんじゃなかった

72 ：
>>70
何を悩んでんのかよくわからんが
普通にヒープから取ったんならdeleteだし
スタックをplacement newしたんなら自分でデストラクタ
それだけの話
というかね、はっきり言ってでかいデータをスタックに置く発想がセンスないぞ

73 ：
ｱﾎやな
ｽﾀｯｸ関係ない

ｱﾎは連続した一枚の板みたいなﾋｰﾌﾟに
ﾎﾟｲﾝﾀの列ではなくｵﾌﾞｼﾞｪｸﾄｲﾝｽﾀﾝｽのﾒﾓﾘｲﾒｰｼﾞの列をｼﾘｱﾙに並べてる

ﾎﾝﾄな、ｱﾎしかいいないわ

74 ：
俺JavaScriptもやってるけどこいつの言ってることはよくわからんよ

75 ：
たとえば64byteのﾒﾓﾘが必要なｸﾗｽがあったとする
ｱﾎが作ったｺﾝﾃﾅでは例えば要素が5個なら
こんな感じになるとｱﾎはいってるﾜｹ

　[0][64byte]
　[1][64byte]
　[2][64byte]
　[3][64byte]
　[4][64byte]

ﾒﾓﾘの板に64*5のﾒﾓﾘｲﾒｰｼﾞが配置される
要素が1つ増えるたびに64byte必要になることになる

ﾎﾟｲﾝﾀなら（仮に32bitなら）こうなる

　[0][4byte]　←　[64byte]
　[1][4byte]　←　[64byte]
　[2][4byte]　←　[64byte]
　[3][4byte]　←　[64byte]
　[4][4byte]　←　[64byte]

ﾒﾓﾘの板に4*5のﾒﾓﾘｲﾒｰｼﾞが配置される
さらに64byteのﾊﾞﾗﾊﾞﾗのﾒﾓﾘが5個できる
つまりﾒﾓﾘﾌﾗｸﾞﾒﾝﾃｰｼｮﾝがおきることになる

76 ：
>>69
そんな長々とオレオレ理解をオレオレ用語で説明されても困るわw
スタックで、とかメソッドチェーンで、とかにこだわりすぎだよ
言語に合わせてサクッと作れ

77 ：
そもそもｽﾀｯｸとかいってるｵﾏｴも
相当頭悪いという自覚が必要

78 ：
allocaって書いてあんだけど

79 ：
さよか

80 ：
>>71
お前が、というより最近の奴が何故
「俺の知ってる言語の『優位性』」に固執するのか甚だ疑問ではある。
ただ、お前は>>37も理解出来てないのだから、まずは「オブジェクト指向」を理解した方がいいぞ。

>>74
JavaScripterはそれ以前で、オブジェクト指向そのものを知らない奴が多いし、
他言語から来た奴は無理に「クラスベース」として捉えようとして誤解し、
しかもそれを垂れ流して間違いを再生産し、どうしようもない状況になってる。
JavaScripterには馬鹿しかいない。これは断言出来る。

>>76
俺はもう動けばいいだけなら普通に作れるんだよ。
その上で、C++の動作速度が遅く、記述がかったるいのを何とかしようと試してる。
先に言っておくが、俺はC比同速程度を目指している。
スマポ(ｷﾘｯなC++なんてJavaよりちょっと速い程度しか出ないし、それなら俺はCLIを使うからそれでいい。
ただしC流の書き方は見た目分かりにくいから、
C比で遅くならない、或いは多少程度でもうちょっとましに書けないか試している。

今回のにしたって、最速はC流の「頭で全部分確保、ポインタで細切れにして渡す」に決まっている。
ただこれは見た目何をやっているのか分かりにくいし、関数に分割もしづらい。
クラスにしたって、仮想関数なしなら速度もメモリもオーバーヘッドはない。なら使わない手はない。
そういう、C比オーバーヘッド無し（或いは僅か）程度で、どこまで分かりやすい見た目になるかを試してる。

楽に書きたいだけなら、JavaScriptが現状最強だ。
C比5倍程度であの楽さ、他の言語なんてやってられない。
速ければいいだけならCだ。ただし記述が見た目分かりにくいのは否めない。
それでC++でどこまでCを改善出来るかを試している。メソッドチェーンもそれの一環だ。

81 ：
だったらふつうにPODの配列でいいわけだからな

82 ：
Cでわかりにくいｺｰﾄﾞを書くには
頭悪いという才能がいる

83 ：
allocaの寿命大丈夫？ちょっと気になった、。

84 ：
>>80
携帯とPCで書いたから同一人物とわからんかったかな
何か実現したいことがあって
＞・derived等、継承で親のメソッドを使ったときにも「呼び出し側の型」を返す為のキーワードの整備
と書いてたんだと思って、解決策になるかもしれない情報を教えてあげようと思ったら
感謝もせんとC++に対するヘイトを垂れ流すだけだったから「ああ、あいつか・・・」となったんだが

＞「俺の知ってる言語の『優位性』」に固執する
どこをどう読んだらそうなるのかわからん。というか鏡見ろ

85 ：
遅いのはｵﾏｴのｳﾝｺｺｰﾄﾞのｱﾙｺﾞﾘｽﾞﾑのせいだからな
気にする必要ないほどのｵｰﾊﾞｰﾍｯﾄﾞが問題じゃない

86 ：
>>72
> スタックをplacement newしたんなら自分でデストラクタ
自分でデストラクタを書かなくて済むようにコンテナを用意してるんだよ。

というか、そもそもC++の思想はそうではないか？
ある意味、クラス外のコードでデストラクタを書いたら負けだろ。
そしてコンテナを用意するだけでこれを回避出来る。
それだけの話だ。

「書けばいい」の発想もいいが、俺はもうそれは十分出来るので、
書かなくて済む物を如何に増やすか、それを試してる。
結局、スクリプト言語が楽なのはここだし。


>>83
もう動作はしてるし、結果も比較して問題ないのを確認済み。
まあ、 alloca は相当使いづらいことも分かった。


>>84
いや、ワッチョイが同一だから同一人物だと認識してる。

> 解決策になるかもしれない情報を教えてあげようと思ったら
解決策になってないし、お前はそれが間違いだとも認識出来てない。
お前の情報は何の役にも立ってない。

馬鹿が間違ったことを言ってきて「間違ってるぞ」と言ったら「それでも感謝しろ」と言われた状況だ。
そういう考え方もありだが、俺はここではそれをしないし、する必要も無いし、するべきでもないと思ってる。
ここでは、間違ったことを言った奴は叩かれるべきだ。
そうでないと馬鹿がどんどん寄ってきて、結果、レベルが下がり、誰にとっても利益が無くなる。
間違ったことを言っても感謝されたいなら、少なくともIDやコテハンが付いてる場所へ行け。
そういうところが好きなら、そういう場所を盛り上げるべきであって、ここで文句を言うべきではない。

87 ：
まぁまぁ御託はいいからお前のコードを全部さらせよ
添削してやっから
あとベンチマークの結果も書いとけ

88 ：
それが一番やな

89 ：
IntelのC++ Composerってサポート期限切れのシリアルでも使用可能なバージョンがあるのね
知らなかったよ

2017 update7
>This update can be installed even if your support service has expired using your existing Serial Number.

90 ：
はじめまして
ゼミの課題でc++でバカラのプログラムかいてこいって言われたんですけど
簡単ですか？

91 ：
はい特定

92 ：
まずｻｲｺﾛの運動をｼﾐｭﾚｰｼｮﾝするところから

93 ：
https://ja.wikipedia.org/wiki/バカラ_(トランプゲーム)
客が複数いないと掛け金が流動しなくて面白くなさそう。
自分は3日あれば形にできそうではある。

94 ：
待ち行列で客が待つのもﾎﾟｱｿﾝ分布使ってｼﾐｭﾚｰｼｮﾝする必要がある

95 ：
devirtualizationはまだclangだけ？

96 ：
>>95
試せば？

97 ：
Win10で、でかいメモリを使おうとすると0xc0000017で落ちるんだけど
制限を解除する方法あったっけ？

98 ：
「64bitのコードでコンパイルするよう指定」するやつだっけ？

「デカいメモリ」「エラーコード〜でブルースクリーン」ていう
キーワードで、記憶に引っかかる感じ。

99 ：
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0551r3.pdf

C++20で、std空間内で宣言されたテンプレートをユーザが特殊化するのを
禁止しようって提案が出てるみたいなんだけど、どうよ？

俺はhashが特殊化できないのは困ると思うんだが

100 ：
ちょっとありえない気がする。大量のコードの互換性が失われるよね。
ostream/wostreamも存在意義を真っ向から否定するような変更では？

101 ：
>>99
pdfは読んでいないが妥当だろう。生産性は上がる。

特殊化したければオレオレ名前空間でstdを継承し、それを使え、でいい。
stdを直接変更している糞コードなんてどこかの時点で切り捨てる必要がある。
それがそろそろだという判断だろうし、実際、妥当だと思う。

102 ：
>>101
ちなみに、おまえさんは
std::unordered_set<my_class> the_obj; //C2280
こんなのにどう対応しているんだ？

103 ：
別の名前空間で特殊化とか出来たっけ？？

104 ：
しかもstdという空間名だけ、言語が特別扱いとかおかしいだろ

105 ：
ｃ＃よりC++のほうがいいんですか？

106 ：
どっちでもいい

107 ：
エラー出るんだけどさ
mt19937 en;
int ep[en.state_size];
random_device rd;
generate(begin(ep), end(ep), rd); //C2280

このラムダみたいなことをやってくれる標準の何かない？
generate(begin(ep), end(ep), [&rd]{ return rd(); });

108 ：
>>107
関数。

109 ：
generate(begin(ep), end(ep), en)
は？

110 ：
>>109
このあと、en.seek(begin(ep), end(ep)); とやりたいわけで。。。

111 ：
>>107
generate(begin(ep), end(ep), ref(rd));

112 ：
>>111
thx!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
これを待っていた

113 ：
>>100
亀レスすまそ
なぜostream/wostreamの存在意義を否定することになるんだ？

114 ：
そもそもP0551R3で禁止されるのは関数テンプレートの特殊化についてであって
std::hashなんかのクラステンプレートの特殊化は特に禁止されないのでは？
クラステンプレートの特殊化まで禁止されるとstd::tuple_sizeみたいなユーザによる特殊化ありきの機能が軒並み消滅する事になると思うんだが

115 ：
あ、そうなんだ
悪りい、そこまで読んでなかった

116 ：
>>102
>>101じゃない＆亀レスですまんけど、
普通にHasher関数オブジェクトを自作して、std::unordered_setのテンプレート第二引数として渡せばいいんじゃないか？
わざわざC2280の解決のためにstd::hashを特殊化するのはナンセンスだと思われる

example:
https://wandbox.org/permlink/mSO96qJDavoK1jqI

117 ：
>>116
ちなみにlambda式も渡せる？

118 ：
>>117
テンプレートへの渡し方が微妙だけど可能
autoでラムダ受け取っておいてdecltypeで渡すか、std::functionを受け皿にするかだな

example:
https://wandbox.org/permlink/qDm0vA6MWDrIksih

119 ：
>>116
それやはやだな
せっかく第２引数を省略する方法が提供されているのに
わざわざオレオレファンクタ−作んなきゃいけないのって。。。

120 ：
ごめ、ありえない変換ミス()しちまった

-それやはやだな
+それはやだな

俺、純血の日本人だよ
信じて

121 ：
ウソつけ絶対大陸人だゾ

122 ：
>>120
純潔(童貞)の日本人だろ、信じるよ。

123 ：
C++じゃないとできないすごいこと教えて

124 ：
作れるものと作れないものは同じだ

文法的に「すごい」のというと、たとえばラムダ式とか構造化束縛、raw-string-literalあたり
型推定もCで頭固くなっちまった人にはそこそこカルチャーショックだよ

125 ：
>>123
ゲームだろ。

126 ：
>>123
競プロ

127 ：
やっぱりC++ってすごくないんだ

128 ：
>>124
型推論は他の言語でもあるからそんなに驚きはないけどraw string literalはやり過ぎだろ

129 ：
>>123
世界征服

130 ：
>>123
・例えばAIライブラリは速度面からC++で組まれることが普通。
・言語コンパイラもコンパイル速度を重視すればC++が最適。
・AndroidOSそのものもC/C++で組まれる。
・Java Virtual Machineも、PC EmulatorもC/C++で組まれる。
・同程度の性能のデバイスでAndoidとiOSを比べたとき、前者が遅いといわれるのは
　全社はJava(仮想コードにコンパイルされる)、後者はSwing(native binaryにコンパイルされる)
　からが大きいと考えられる。

131 ：
>>130
では Java で記述されたコードをコンパイルした成果物が native binary であればいいのですね、これは商機があるかもしれませんね

132 ：
それ30億のデバイスで走る？

133 ：
甘いな
native binaryでありさえすればいいってもんじゃない
上手いマシン語と下手なマシン語がある

134 ：
>>131
実は、>>133が指摘してる通り JavaやC#は言語仕様そのものが native binary
に直してもC++ほどの速度にはなりにくい。例えば遅くなる理由として
1. GC(Garbage Collection)によって自動的にfreeやdeleteさせようとする仕様。
2. 標準的にはポインタを使わない仕様。
3. オブジェクトが構造体やスタックに埋め込まれずにheapからnewされ易い仕様。
4. 二次元以上の配列がJaggyタイプに成り易い仕様。
5. バッファオーバーランの防止のため、配列の境界チェックが行われやすい仕様。
6. ライブラリが巨大なため起動時に大量のコードがディスクから読み出されるため、
　起動が遅く成り易いこと。巨大になる理由の一つはリフレクションや型に
　#includeによる静的コンパイルをせずにすますためののクラスの型情報などが
　(Javaの場合は*.classや*.jarなどの)ライブラリに入っているためだろうか。

例えば、C#も予めnative binaryに直してしまう方法も有るが、それでも起動速度は
余り早くならないらしい。起動後も1.〜5.の理由のためC++程の速度にはなりにくい。

135 ：
>>134
7. C#のリンクリストの場合、要素を削除する場合、文字列などの要素の中身か、
　要素番号を指定する必要が有る。要素Bを有る要素Aの後ろに追加する場合、
　Aの要素番号を指定する必要が有る。これが遅くなる。C/C++本来のリンクリストは
　削除や追加の場所の指定をポインタ(アドレス)で指定できることが速度上の大きな
　優位性であったのにそれが出来ない。なお、詳しくはないがC++のSTLのstd::listの場合は、
　同様の「不具合」があるためリンクリストの本来の性能が出ないかもしれない。
　しかし、それはSTLがC/C++の昔から使われていた本来のリンクリストの実装の仕方を
　していないからであると思われる。

136 ：
Javaってランタイムがプリミティブなってるクラスを実行することがあったと思うけど、
ネーティブではそのプリミティブ型のクラスを分解してマシン語にしないといけなかった気がする。

137 ：
vs2019なんだけどさ

void f(path&& pt)
{
auto date = last_write_time(pt);
auto val = decltype(date)::clock::to_time_t(date); //C2039
}

これどうやってtime_tもらうの？

138 ：
decltype(ftime)::clock::to_time_t()
は、decltype(ftime) が std::filesystem::file_time_type なので、
意味的には長く書けば、
std::filesystem::file_time_type::clock::to_time_t()
となるとは思う。短くすれば、
file_time_type::clock::to_time_t()
となるけど、clock という名前空間は見つからなかったが、
std::chrono::system_clock::to_time_t()
という関数ならば存在しており、
static std::time_t to_time_t( const time_point& t ) noexcept;
という宣言にはなっているところまでは見つけた。
clock というキーワードが何なのかは不明。

139 ：
last_write_time() の型は：
std::filesystem::file_time_type last_write_time(const std::filesystem::path& p);
file_time_type の型(?)は：
using file_time_type = std::chrono::time_point<>;
なので、
decltype(date)::clock::to_time_t() の部分は、decltype()部分を展開(?)すれば
std::chrono::time_point<>::clock::to_time_t()
と書けることは書ける。この部分は、存在することが分かっている：
std::chrono::system_clock::to_time_t()
ととてもよく似ている。

140 ：
https://cpprefjp.github.io/reference/chrono/time_point.html
↑によれば、time_pointは
namespace std {
namespace chrono {
template <class Clock, class Duration = typename Clock::duration>
class time_point;
}}
というテンプレート・クラス。
file_time_typeは、C++20では、
using file_time_type = std::chrono::time_point<std::chrono::file_clock>;
と定義されているので、Clock=std::chrono::file_clock とされてテンプレートが具現化される
らしい。time_point<Clock,Duration>クラスには
Clock clock;
というメンバが存在するらしい。ゆえに、
decltype(date)::clock::to_time_t()は、
std::chrono::time_point<std::chrono::file_clock>::clock::to_time_t()
となり、clock=std::chrono::file_clock という意味になり、結局、
std::chrono::file_clock::to_time_t()
ということになるようだ。

141 ：
>>140
file_clock は、仕様がまだ決まって無いらしい。

142 ：
うん、俺もそう読んでる

auto sdat = time_point_cast<time_point<system_clock, system_clock::duration>>(date);
・・・これもうまくいかんなあ

143 ：
autoやめるか、autoで得たものをTYPEIDに物故むか。
好きな方をえらぶのじゃ。

144 ：
>>134-135
動的にコンテナサイズが変わるものは、遅くなる

それと、C++ でも仮想関数を使うと、関数のアドレスが静的に決まらないから、
その都度、計算するから、オーバーヘッドになる

145 ：
void f(path&& pt)
{
auto date = last_write_time(pt);
using dt = typename decltype(date)::clock;
auto val = dt::to_time_t(date); //C2039
}

くっそー、もうAPI呼ぶしかねえのか

146 ：
clock_castが実装されるまで待つしかなかろう

147 ：
>>145
単純に
void f(path&& pt)
{
　auto　　date1 = last_write_time(pt);
　time_t　val1 = std::chrono::system_clock::to_time_t(date1);
}
とすればいいだけのような気がする。

148 ：
C2664
残念。。。

149 ：
>>148
https://code.woboq.org/llvm/libcxx/include/chrono.html
↑によれば、以下の様になっており、time_point は、一般的な
template の time_point<・・・>とsystem_clock::time_pointは
厳密には「別」で、後者は前者を特殊化したものを typedef宣言
している。そのため、 std::chrono::system_clock::to_time_t()の
(メンバ)関数宣言の
static time_t to_time_t(const time_point& t) noexcept;
のtime_pointは、chrono::time_point<system_clock>という
system_clock専用になっている。それが原因で>>147は
エラーを出すらしい。

class system_clock {
public:
　・・・
　 typedef chrono::time_point<system_clock> time_point;
　・・・
}

150 ：
そう思ってtime_point_castしてみたんだが、それすら通らない。。。

151 ：
>>150
time_point_cast() は根本的な「Clock」の部分は変換前後で共通の場合のみが
実装されているようです。なのでどこまでの細かい時間を表現できるかの
「時間精度」は変更できても、表現の違いのようなものまでは対応できないのかも
知れません：

namespace std {
namespace chrono {
template <class ToDuration, class Clock, class Duration>
time_point<Clock, ToDuration>
time_point_cast(const time_point<Clock, Duration>& t); // C++11

template <class ToDuration, class Clock, class Duration>
constexpr time_point<Clock, ToDuration>
time_point_cast(const time_point<Clock, Duration>& t); // C++14
}}

152 ：
テンプレートとマクロのメリットデメリットって他にありますか？
またテンプレートとマクロの使い分けで悩んでいます

マクロのメリット
・一括置換ができる
・文字列も使用できる
・定数式にも使える（配列の要素数）

マクロのデメリット
・数式が複雑なときにミスをしやすい（＋＋を渡してはいけない、演算優先順位がミスしやすい）
・型の識別ができない
・一行記述なので大規模なのには不向き

テンプレートのメリット
・名前空間を定義できるので影響範囲をとどめやすい
・型の識別ができる
・関数なので大規模なのも書ける

テンプレートのデメリット
・定数式にしようできない
・ユーザー定義と標準定義が混ざったときのエラーを判別しにくい

こんなメリットデメリットだと思っています。
他にありますか？？

これを踏まえた上で使い分けとしては、
マクロは文字列などの簡単な定義に向いていて、テンプレートは処理（演算）を含むものと考えているのですが、
他に観点あるでしょうか

153 ：
宿題は宿題スレで

154 ：
マクロのデメリット
・スコープに従わない　←致命傷
・デバッガとの相性が極悪

155 ：
>>152
「他にありますか？」の答えにはならないんだけど・・・

> テンプレートのデメリット
> ・定数式にしようできない

そんなことなくね？

> ・ユーザー定義と標準定義が混ざったときのエラーを判別しにくい

どういう状況のこと言ってるのかよくわからないけど、マクロにすればわかりやすくなる状況なのか
怪しい気がする。

ってことで、使い分けとしてはマクロでしかできないこと（トークン連結・文字列化）以外は
テンプレート使うとしたほうが簡単だと思うし、よく聞く話。

156 ：
マクロはコンパイラが展開後のコードを見せてくれるけどテンプレートは見せてくれない

157 ：
展開じゃないからな
typename Tに何が来ているかなんてのはcout << typeid(T).name()で監視できるんで
iocccなみに解読困難なプリプロセッサ出力がないからって困りゃせん

158 ：
その無駄な監視についてなんも思わんてすごいね。

159 ：
その監視というか確認の煩雑さは、マクロの方が面倒だろに。

160 ：
>>152
マクロは、テンプレートのメタ側に位置する機能なので、テンプレートに出来ない事や、テンプレート自体のコードに変更を入れる場合につかうと良い。
まあ、リテラルレベルの置換と、プリプロセッサの入力に使えるってくらいかな。

よく使うのは、コンパイルスイッチくらいじゃないかな。
極稀にリテラルを文字列化したり、リテラルレベルでトークン連結処理したりするくらいかな。

定数はぶっちゃけどっちでも良いけど、式を含むならconstexpr を使うのが c++11の流儀。

161 ：
>>159
こんなクソみたいな記述入れて一旦ビルドして確かめるとか正気の沙汰じゃねーわ。
cout << typeid(T).name()
マクロもたいがいダメだろうがこれをやらせるって歪んでるとしか思えん。

162 ：
一旦ビルドしてって、テンプレートはコンパイルしないと何が来るかなんて分からんだろ
＞マクロもたいがいダメだろうが
とか雑な切り捨てしてる辺りからしても、めっちゃ初心者とみた

163 ：
>>161
何がどうクソなんだ？
おまえさんのルールの何条に違反しているんだ？

164 ：
>一旦ビルドしてって、テンプレートはコンパイルしないと何が来るかなんて分からんだろ
だからこれがしょうもないってことを言ってるんだが。
静的にコード見て判断しずらい仕組みをなぜ疑問なく使えるのか、そっちのがよっぽど素人感丸出しだよ。

165 ：
へー、判断しづらいのかｗ

おまえさ、C++に向いてないよ
もうやめたら？

166 ：
横からすまんが

cout << typeid(T).name()

はくそださいと思う

167 ：
そもそも cout がダサいですし

168 ：
宣言だけのテンプレートを使ってエラー吐かせてクラス名確認するのはわりとやる

169 ：
ダサいと言っているその姿がダサいことにくらい気がつけよ
技術板で客観性を全く欠いた戯れ言ぬかしやがって

170 ：
>>164
＞静的にコード見て判断しずらい仕組みをなぜ疑問なく使えるのか
これにはテンプレートも含むってこと？
それならまぁ言いたいことはわかる

171 ：
>>161
言ってることは当たってる。C++は、というか、正確に言うと、C++のスレは歪んでる。

C++ってのは結局のところ、何でも出来るように設計されている。
だから、ユーザーがその機能を使うか使わないか、よくよく考えないと逆に色々面倒なことになる。
マクロもテンプレートも上手く使えば素晴らしいが、濫用すると余計に酷くなる。
○○を使えばいい、とか、逆に、○○は禁止、とか、（本来は）単純に切り分けられるものでもない。

この辺は他LL言語やJava/C#等は最初から使える範囲が決まっており、
C++から見ればかなり制限されているから、濫用は出来ない。
結果、「C++の酷いコード」よりは「C#の酷いコード」の方が数段ましなものにはなる。
逆に言えば、C++はプロ仕様で、
自身でコーディングルールをそれなりに決められる人じゃないと適切には使いこなせない。

実際の職場では大概はがんじがらめのルールが決められているはずで、
C++でコーディングルール無しのところなんてないのではないかと思う。
ところがC++のスレは勘違いした素人が多いのか、
C++の新しい文法や小手先テクニックを使って書くことが目的になっている奴が多い。
そして「長期的な保守」を全く考慮してないレスも散見される。
だからここではそういう雑音もきちんと峻別する能力が求められてしまう。
といってもそれもC++の範疇で、つまり「自分で判断しろ」でしかない。
無理ならC#等そういう「馬鹿が使ったらどうしようもなくなる機能」が最初から用意されてない言語を使え、でしかない。

ここで素人相手にマウント合戦なんて意味無いから止めとけ。
> 静的にコード見て判断しずらい仕組みをなぜ疑問なく使えるのか (>>164)
この基準は正しい。
テンプレートに問題があると認識されているのは昔からだ。
ただ、テンプレート以外に上手く同等のコードを得る方法がないから、それでもテンプレートは使われている。
いずれにしても、その機能をどこまで使うかは君が判定するしかない。
実際に動かさないと何が当たっているか分からないテンプレートなんて事実として糞だが、
それでもその方がましならそういう書き方をするときもあるだろう。
全体を見ず、個々の末端の事例でグダグダ言い争っても意味はない。

172 ：
上っ面しか見てねえやつだな
長期的な保守性という要求から色んな仕様が発明されているのに
ついていけねえ低脳が被害者面しやがる

173 ：
おまえらもういいから、ずーっとC++98使い続けてろよ
それで食っていける仕事があるなら俺たち別に非難しねえ
非難てのも変だけどな

174 ：
中身のない長文書く奴はもれなくバカ

175 ：
>>172
お前最低限メタプログラミングは出来てて言ってるんだよな？
stlとか新機能使ってるだけとか自分で人様に使われるライブラリ書いたことない、とかじゃないよな？

176 ：
>>175
stlが新機能って・・・・おまえいつから更新停止してんだ？

177 ：
stlを新機能とは書いてないんだが

178 ：
いなして、それで？

179 ：
>>175に答えろアホ

180 ：
>>171
だいたい納得。
別にstl使うなとかそこまで無茶は言わんよ。
unique_ptr なんかも使っていくのは良いと思うし。
ただおれおれ糞テンプレートライブラリは使いたくねーわという話。

181 ：
アンチテンプレート厨はenable_ifになぜ_tがあるのかとかわからんだろ

182 ：
そこだけ泥縄で調べて何かぬかすんだろうけど
言ってることの全体的な薄っぺらさはどうにもならねえぜ

183 ：
それもcoutデバッグして理解したん？

184 ：
>>157, >>181は別人だと思ってたんだが違うのか

＞enable_ifになぜ_tがあるのか
別にアンチじゃないけどそれはある程度基礎が出来てる人には常識だとおも

185 ：
>>180
まあそうなんだが、unique_ptrとstlで大体いけるならPython/Ruby/Java/C#で全く問題ないし、
それらを使う方が断然生産性が高い。
だから逆に、C++を使うのならそれなりの理由が必要で、
通常それは速度、つまりゴリゴリに手動チューニングしてでも最速を得たい、ということなのだが、
C++のスレは「ナマポは撲滅されるべき、今時スマポ使わないなんて話にならない」だから終わってる。
ナマポを混在させられることがC++のメリットだし、それを使わなければC++使う意味ないと思うが。

あと、C++が導入したのは「オブジェクト指向」と「テンプレート」だが、
オブジェクト指向の方はほぼ全部のメジャー言語に採用されたのに対し、
テンプレートの採用は皆無だろ。出来も推して知るべし。
生産性を追求するC#、安全性を追求するJavaからは要らない子扱いされてるのが現実だ。

個人的に思うのは、超最速を目指さない限りC++で全部組むのはナンセンスで、
GUI部分とかはPython等で楽に組んで、演算部分だけCのDLLを呼ぶのがいいと思う。
Cは大規模コードを組む為の仕組みがないので次第に大きくなってくるとなかなか厳しくなるが、
この方法だと各DLLは1k行程度で済むのでCでも問題になることはない。
なお手動チューニングするならCの方が楽だ。
C++はコンパイラが最適化する前提でテンプレートを重ねがけする事が常態化しており、
ソースコードからどんなオブジェクトコードが生成されるかが読みづらい。
といってもこれはCはあんまり最適化しないからであって、
糞コードであっても速いオブジェクトが出る可能性のあるC++の方が断然いいのも事実だが。
（Cは糞コードなら糞オブジェクトしか出ないが、C++はコンパイラでの最適化がかなり期待できる局面もある）

なお今から学ぶならRustもありだと思うぞ。
unique_ptr基本で組むようにデザインされている。（らしい）
問題はRustは本当に立ち上がるか微妙なことだが。
C++が悪い点は多々あるが、それらって結局、そういう書き方をしなければいいだけでしかなく、
結局のところこれがCもC++も(Rustが立ち上がったとしても）死にきらない理由でもある。

186 ：
>enable_ifになぜ_tがあるのか
こういうのを知ってウキウキするのはよくわかるよw
https://www.fluentcpp.com/2018/05/18/make-sfinae-pretty-2-hidden-beauty-sfinae/

でもいらん機能を無理やり現場に持ち込んで他人に迷惑かけるのは筋違いだから。

187 ：
典型的な老害だな

188 ：
はいはい
テンプレート(もちろん自作の)バリバリのコード書いて
それがどれだけ開発効率に影響与えたか、コスト掛けた価値がどれだけあったか
客観的に言えるようになってからほざいてね

189 ：
本末転倒もいいとこだな
いいか、最も肝心なことは何を実現したかと成果物の質だ
開発効率だのコストだのはその次に考えることで
そこに振り回されて本分を投げちゃいけねえ

190 ：
都合のいい抜き出し方をするな
その成果物の質のために、どれだけの時間と労力を掛けて
それが質の向上に見合ったものかを客観的に見れるようになってから言えといってんの

191 ：
別にテンプレート使うなって言ってんじゃないよ
使ってごちゃごちゃ作るからにはそれが本当に後々まで使える便利なもので、
ゆくゆくは長い開発期間を償却できるレベルなのかどうか、そこまで考えると、普通は判断は難しい
テンプレート使う奴が実力あるやつで、やめとけと言うのは老害とかそんなアホな話は有り得ない

192 ：
経営者目線ならこっちは自営で
ニートのご高説は無用だ

193 ：
ははは、自らの主張を引っ込めたな
そうなるしかないんだけどな

194 ：
?俺>>184だよ
テンプレートバリバリ使ってコストのバランスに毎日悩んどるわ
ちな俺も自営、元は会社でチームでやってたが

195 ：
>>189
アウトプットを最大化するために効率をあげるんだが

196 ：
そういって腐ったテンプレートを残していった老害を何人も見てるからな。
下の世代がまた同じことを繰り返そうとしてたらそりゃ文句の一つも言っとかなきゃあかんだろ。

197 ：
>176 みたいな文盲ってホントに居るんだな

198 ：
今ここで為されている議論ももう何回目だ？だし、積極的に続ける意味はないと思うが。

そんなに気になるなら他人のコーディングルールを確認してみればいい。
例えばgoogleのテンプレートについての記述は以下。
https://ttsuki.github.io/styleguide/cppguide.ja.html#Template_metaprogramming
まあそうだよね、程度だが。

個人的にはリファクタの障害になるのが致命的だと感じる。
max_fやmax_iなんてやるのは馬鹿みたいではあるが、
しかし検索は簡単で、変更時の影響範囲も明確に分かる。
これはLinusも同じ事を言っている。

C++は若干コードに執着しすぎている。
泥臭くも書けるところを無理矢理綺麗にしようとして、余計に複雑になっている。
具体的に言うと、記述を１ヶ所に絞る為にテンプレートを3回重ねがけ、なんてのは割とある話で、
それなら数ヶ所ならベタで書いてしまって「同じ記述が○○にもあるから変更するときは注意しろ」と
コメントに書いてしまうというドベタな解決策も採れるわけだが、C++はこれをよしとしない。
(Cの場合はこの場合はマクロにしてしまって１ヶ所に纏めたりする。
これはこれで問題はあるが、それ以前に意識高い系C++erではマクロは禁止だし）

ただ現実的には、C++は上記「コメントで対応」「マクロで対応」「テンプレートで対応」のどれも出来る。
だからユーザーが適切に選べばいいだけであって、
より本質的な問題は、「こう書くべき、じゃないと認めない！」
みたいな意識高い系馬鹿がC++にも進出してきたことではある。
色々な書き方が無駄に出来てしまうC++は彼等にとってはそれなりに居心地がいいのかもしれない。
だからそういう馬鹿に流されず、「俺流のC++はこう」みたいなのが出来るのならそれでいいと思うが。

同じ話はconstや例外にもあって、それらも結局煮え切らない議論になってるだろ。
googleはconstは推奨、例外は禁止、のようであるが。
https://ttsuki.github.io/styleguide/cppguide.ja.html#Use_of_const
https://ttsuki.github.io/styleguide/cppguide.ja.html#Exceptions

199 ：
googleの例外禁止は古いコードが例外対応していないため、改修が辛いと言う消極的理由だけどね

200 ：
>>199
しかし例外が素性が悪いのも事実だろ。
そして現在のソフトウェア工学はこれに対する解をまだ提供できてない。

オブジェクト指向は各オブジェクトを基底側のクラスで抽象化して統一的に扱えるからいいのであって、
例外は基本的に派生クラスでの対処が必要だから全く馴染まない。
そしてこれがJavaで繰り返されてる
「例外でコケるの止めてくれない？」「えっと？握りつぶせばいいですか？」
の根元だろ。
かといってC流のエラー番号＆毎回いちいちチェック方式がいいというわけではないが。

C++流のオブジェクト指向はほぼ全てのメジャー言語に広まった。これは出来がいいからだ。
同様に、ラムダも出来がいいから最近採用されまくってる。
C++が当初これを持ってなかったのは結果的には単にC++が馬鹿だったからでしかない。
テンプレートも同様で、広まらないのは出来が悪いからでしかない。

例外がイマイチなのは、そもそも出来が悪いからだ。
そして本質的に、例外方式では非同期/ベクタ(SIMD)には対応できない。
同期で済むところを非同期で書かされるJavaScriptも相当ウザイが、
今後のプログラミングのトレンドが
マルチスレッドによる非同期やGPU活用の為のベクタライズ(SIMD)に進むとしたら、
今現在の『旧式』の例外をコードに含まないようにしておくことはかなり意味がある。
googleが過去にこだわっているだけだと見るのは勘違いだと思うよ。

まあいずれにしろ、C++は今後とも「全部入り、使うかどうかはおまえら次第」を目指すようではあるし、
そういう言語が一つくらいあってもいい。
だからこそ、各自でその機能をどこまで使うべきか考えないといけないし、
それを適切に出来ない人は、
誰かのコーディングルールに乗っかるか、C++を使うのを止めるかした方がいいと思うが。

201 ：
またvoidくん暴れてるの？

202 ：
>>194
おまえさ、そんなすぐ目先の損得に頭を占領されてんの？
同じ「コスト」って言葉を使ってるけど、なんか全然意味違いそうだな
５年１０年単位の長い波長を持つ金の津波をどう起こすかって話と
ずいぶんズレて聞こえるんだが

203 ：
>>202
俺が言ってんのは開発期間(見積もり含め)とかの話な
お前多分だいぶ規模小さいだろ
だから無条件にテンプレート崇拝できるんだろうな

204 ：
>>197
別にお前に言ってないけど図星突いちゃったか

205 ：
規模が大きいって、template使わないから規模が無駄に大きくなっているだけだろ
コピペ改変繰り返したような糞コードの山みたいな

206 ：
何言ってんだこいつ・・・

207 ：
>>203
ああ、やっぱりそうか
５年１０年つってんのに規模がどうたらとか
マジその日暮らしなんだな
同情はできるぜ、俺だって死にそうに苦しい時あったからな

208 ：
うちの会社にもなんでもかんでもテンプレートで定義する奴いるけど、
ほとんどのテンプレートが実際には１つの型でしか使ってなかったりするｗ

209 ：
は？
まぁ自営歴はそっちのが長いかもしれんが
>>186に対して>>187を書ける根拠が知りたいね
くだらないことでマウントかましてきたからやり返すけど、お前チーム開発の経験はあるんだろうな？
自分が開発したライブラリ(もちろんテンプレート使った)を人様に使わせたこともあって言ってるんだろうな？

210 ：
>>209は>>207宛

211 ：
あ、あと>>204は読み間違いだったわ、すまんorz

212 ：
>５年１０年単位の長い波長を持つ金の津波をどう起こすかって話と
名言ｋｔｋｒｗｗｗ
金の津波ｗｗｗ
それを考える奴がC++のソース書くのは時間が勿体ないよｗｗｗ

213 ：
なんでも良いだろ。
デバドラ書いてる俺はいまだにCだよ。

214 ：
理解してないバカがいるかぎりは何度でも言う。
てか google c++ の規約くらい読めばいいと思うよ。
実際、ためになるし、この手の文書にしては相当簡素で物量で圧倒されるようなもんでもないし。

215 ：
ちょっと悪意ある実例かもしれんけど、
仮にメモリリソースを標準ヒープ限定にしないよう、任意のアロケータを使ったstring, vectorを
受け取る関数を書いたとして（いずれのデータも結構大きい可能性がある）、

https://wandbox.org/permlink/wGxcWDrAvb93ptzD
↑のようにテンプレート化した途端に、簡単なリテラルや初期化子リストからは受け取れなくなる
（もちろんstd::string(), std::vector<hoge, allocator<hoge>>{うんたらかんたら}とすれば通るが）
むやみにテンプレートマンセーして、ちょっと否定的な意見（しかも経験豊富な人からの）を見ただけで火傷起こしてるバカどもは
この程度の（自分でテンプレート使って汎用性求めればすぐわかる）デメリットにすら気付いたことがないんだろう

（こんなんだったらポインタで受け取った方がマシ、この場合は。）

216 ：
ちなみに、こういう任意のリソースを受け取るということについていちいちテンプレート化しなきゃいけなかったという
STL周りの不便さを改善すべく、新しいリソース管理クラスが導入されたけど
Alex Stepanovや標準化委員会も、allocator周りは失敗だったと思ってるんだろうな

あと、>>187も含めテンプレートマンセーしてる初心者は知らんだろうけど
STLは構想から含めて十年以上かけて作られた代物だからな、ある意味優れてて当たり前
そんなライブラリでも改善すべき点は見つかるんであって、ろくにテンプレートライブラリ書いたことも無いやつが権威を笠に着るなと言いたい
その上で「お前らその開発期間を償却できるほどの設計センスと経験、責任感があるんか」と問いたい

>>212
自営業といっても全然関係ない業種の趣味グラマだったりして

217 ：
それ目的に対してテンプレートの書き方が悪いだけじゃね？

218 ：
StringTとかArrayTとかもっと雑に受け取れってことやろ？
わかるけど、その先で全部統一した一つの関数テンプレートで処理をまとめられるとは限らない
結局泥臭いコンパイル時分岐を書かなきゃいけなくなることもある

219 ：
>>215
ちょっと趣旨から脱線して申し訳ないが、
そういえば独自アロケータを与えられるのもC++の特長ではあったか。

となると、C++をどうしても使わなければならない局面は、
・ナマポとスマポの混在
・独自アロケータの使用
とかかな？

ただまあ、責める気はないが、
独自アロケータについては他言語は対応してないと思うので、
この場合はstlやテンプレートがどんだけ糞であろうが頑張ってC++で書くしかない。
勿論、色々改善する余地はあるとしても、
他言語がいわゆるシステムレベルプログラミング（≒OSそのものを作る）に
対応していないのだから選択の余地はない。
まあLinusに言わせればC++もシステムレベルプログラミングには使い物にならない、とのことだが。

220 ：
>>218
雑というかSFINAEで制限しろという
まあ、conceptくるまで汚くて面倒なのは仕方ない

221 ：
大体1の方しかなかったら、無駄にヒープ使われるだけで、それこそ望む挙動にならないような

222 ：
SFINAEで対応とか、c++のオーバーロード、ならびにrvalue周りの仕様を
全部読み、かつ現実のソースをすべて読むのにどれだけの物量かかるか少しも想像してないんだろう。

223 ：
>>219
いや、悪意ある例と書いたけど
どう確保したかに関数側が興味ないのであれば＆特殊な用途でなければ素直にポインタでいいし
>>216で挙げたPolymorphic Resource使えばテンプレートにする必要すら無いんだけどね（実際めっちゃ便利）

標準ヒープを前提にした設計＆サンプルコードなんかの綺麗な例のようなSTLの使い方しか
したことない初心者には全くそういう問題が想像つかないんだろうなと言いたかった
テンプレート使って設計するのはめっちゃ時間かかるし、そこまでする価値があるのかどうかというのは
今どきのC++でのコーディングには避けられない重要な判断だと思う
（そういう判断放棄して古臭い書き方してる職場が多いのは、決しておかしな話ではない）

>>220
＞SFINAEで制限
まぁその方が理想的なんだろうね（ある程度差異を吸収する関数はあるし）

224 ：
仕様全てとは言わんが、書くなら関連する仕様くらい押さえておけってだけだろう。

書けない人材でも、そのライブラリを使うのには支障無いだろ

225 ：
string_view的なもので実装書いて、他のは適当に切り分けてtemplateも必要に応じて使いつつoverloadで変換して実装呼ぶみたいなのはよくやる

そう言うのが多過ぎて面倒なら、パラメーター受け用のクラス作って受けたい元クラスから作るコンストラクタで変換するってのもあるし

226 ：
>>224
c++の場合、まともにオーバーロードの仕様を抑えてる奴などおらん。
てかコンパイラ作る方も理解が薄いんじゃないかと思うレベルでバグ入れ込む話だぞ。
実際に仕様読むと増築につぐ増築でまともな仕様とは思わなくなる。
簡単だと主張する輩というのは仕様を読んでないか、もしくは江添みたく仕事の関係で後に引けないやつかしかおらんってことだ。

227 ：
ADL含めたらややこし過ぎるが
そんなの普通は使わんだろ
名前空間指定してその中のオーバーロード使わせるのがまともなやり方

228 ：
ID:9yJw5XoJ0は逃げたんだろうか・・・・ﾂﾏﾝﾈ

229 ：
>>200
「全部入り」と言いつつcodecvtを入れた香具師は死刑

230 ：
便所の落書き見て経験豊富と思うのはさすがに草

231 ：
実引数依存の名前探索 （じつひきすういぞんのなまえたんさく、ADL）とは、
C++において関数呼出時に与えられた引数の型に依存して、
呼び出す関数を探索 (lookup)する仕組みのことである

英語ではKoenig lookup、argument dependent lookup (ADL)、argument dependent name lookupなどと呼ばれる。
なお、Koenig lookupとは、この仕組みをAndrew Koenigが提案したことにちなむ

Koenigは、C Traps and Pitfalls(Ｃプログラミングの落とし穴)を、1989年に書いてる。
ADLは、Koenigが発明したのではないけど、標準委員会を説得したのは彼らしい

たぶん、ここまで詳しいのは、江添の本にしか書いてないだろう

232 ：
Cは使い続ける意味はあるが
C++には未来はないよ
そういう使い方したい人は
Dを使えば良いんじゃないかな

233 ：
>>227
それなら関数名なりを変えてるのと変わらんだろ。
オーバーロードなんて無理に使う必要ない。
てかそこまでうまくモジュール分割できないやつに限って使おうとする機能だから
問題なんだよ。

234 ：
>>233
namespaceのalias作れるから
単純に関数名の接頭付けるのとは
使い勝手が段違い
namespace内でのoverloadは普通に有効だし

235 ：
>>234
だからネームスペースで区切った時点で話は終わってんだよ。
オーバーロードなんて余計な機能使うのは混乱を生むだけ。
無駄に検索にも弱くなるし。

236 ：
overloadは使うだろ？
overloadはする側が管理するため空間分けるってのは至極当然な話では？

237 ：
>>236
関数のoverloadはgrep検索が上手く出来なくなるからなるべく使わないほうが
いいと思ってるよ。ちなみに間違いやすいけど override のほうじゃないよ。

238 ：
推奨しない理由がgrepっておかしくね？
ちゃんと参照を解析できるIDE使えばいいやん
本質からずれてる

239 ：
何でgrep上手くできなくなるんだ？

240 ：
まあ使うも使わないも自由だが、あまり文法的なことばかりにこだわらない方がいい。
言い方を変えれば、「プログラミングの達人」と「C++言語の達人」は別なことを認識した方がいい。

「C++言語特有の機能」を使いこなせれば「C++言語の達人」ではあるだろう。
しかし、それは「プログラミングの達人」ではない。
「プログラミングの達人」なら当然「他言語を使っても達人」であり、
それは「言語非依存部分での圧倒的な巧さ」によるものだ。
単純に言えば、「ああ、こうすればこんなに簡単に実装できるのか」を繰り返してる。
C++特有の機能、つまりテンプレートやオーバーロードをいくら使いこなしてもここには到達できない。
それらは無ければ無いで何とかなる程度のものでしかなく、所詮はソースコードの整形でしかない。
それらをどれだけ使いこなしても本質的な構造の改善には繋がらない。

休日に2chに来てプログラミング談義に参加するような奴は、
モチベーションはあり、これは素晴らしい。上達も(本来は)するだろう。
ただ、最近は脱線している奴を多く見かける。
そして、無駄にやる気だけはあるから、おかしな議論で永久ループしてしまっている。
「言語非依存部分での腕前の差」を認識できないうちは、文法的なことにばかりこだわらない方がいい。
「C++言語の達人」ではなく「プログラミングの達人」を目指すなら、それは完全に空回りでしかない。

俺が見る限り、どの言語で始めてもどうやらそれなりにくだらない議論をやってる。
Javaの初学者は必要もないところでクラスを作って継承をこねくり回してる。
JavaScriptの初学者はセミコロンを打つか打たないかで議論してる。
C++の初学者はC++の無駄に複雑な言語仕様、特にテンプレート周りに惹かれるようだ。
ただ、これらを使いこなしても「プログラミング」そのものの上達はしない。
本来の「プログラミング」、つまり「言語非依存部分」での上達にフォーカスした方がいい。
そうであれば、C++が死んだら死んだで、あっそう、でしかない。
（俺はRustではC++を殺しきれないと見ているが）

241 ：
途中まで、何かもっともらしく聞こえるが
結局、C++の特定の機能を否定したいだけな下心が隠せてないな

242 ：
そりゃ無駄なことで労力使うことになる機能なんてなくなりゃいいと思うわ。
バカは他の人間が苦労してるのがうれしいのだろうが。

243 ：
C++から入れば他言語で当たり前に使われてるRTTIやリフレクションがおかしなものか分かる

244 ：
>>241
君がどこを目指すかは君の自由だが、「プログラミングの達人」のつもりなら、
君らが馬鹿にする「C限定」「C++98限定」縛りでも他の凡人とは明確に差を付けられなければいけない。
それが出来ないのなら、君は「プログラミングの達人」ではない。

ただ、新しい記述は古い記述の問題点を修正したものであるのは事実なので、
その問題に直面しているのに新しい記述を拒絶するのは、老害だと馬鹿にしていい。

といっても、当然だが基本/必要不可欠な部分から整備するので、
最近のC++に入っている仕様はかなり屋上屋を架す状態になっているのも事実だろ。
googleのルールがC++11を基本としているのもこれが遠因にある。


C++のスレが歪んでいるのは、住人がこの辺の「ちょっと考えれば分かること」を認めないからだ。
はちみつ餃子（コテ名）なんて、リアルの友人に職業マ（ゲーム）が居て色々聞いてみて、
「プロでも最近の仕様には疎いんだよなー」とか愚痴ってたろ。
そこでアマチュアであるはちみつ餃子が正しくプロが間違っている、と認識する点が狂ってる。
そしてこのタイプの人間がC++スレには割と多い。

C++が一番使われているのはゲーム業界だと思うが、これは単純に速度が速いからだ。
そしてゲーム業界が直面している問題は（ちと古いが）例えば以下であり、要するにOOPの限界とかだ。
OOPはコードを綺麗にまとめる手段ではあるが、速度は大概遅くなる方向だからだ。
https://sites.google.com/site/shunichisnote/translations/data-oriented-design
そして当たり前だがC++の新機能なんてこれに対する解を提供するものでは全くない。
結果、C++のゲームプログラマはC++の新機能なんて知る意味がないから、無視または受動的となる。
これもちょっと考えれば分かることだと思うんだがな。

プログラマ＝料理人に対して、包丁職人＝C++の達人も必要であり、
それを目指すなら、新機能を使えること＝上達だと考えるのは正しい。
でもそうでない場合、早い段階でこの認識は改めた方がいい。

245 ：
ある機能を使わない理由が知らないからで、結果無駄な労力かけている
知らない理由を正当化しようと、知る前から役に立たないとか抽象的な理屈で断定するのは逃げでしかないんだよね
まあ言語仕様なんてアセンブラがあればなんでもできる
色々な言語があって、それぞれ独自に進化しているのは、結局みんな楽をしたいからなんだよ
手を動かす方で楽をするためには知識と知恵が必要で、知識を得るためには勉強が必要
まあ知識だけ入れても使いこなす知恵がないと無意味なのだけど

246 ：
ゲームなんて子供のおもちゃとかどうでもよくて草

247 ：
>>243
リフレクションは動的→静的変換には必要ではある。
ただし動は動で組む、というのがC流ではある。(リフレクションがない世界だったから当然ではあるが)
といってもリフレクションありならだいぶ楽に書けるのも事実で、
.NET(WPF)はこの部分だけはフレームワークが自動的にリフレクションしてくれることになっている。

RTTIはgoogleは「必要になるのは設計ミスだ」という見解であり、確かにこれは事実だが、
https://ttsuki.github.io/styleguide/cppguide.ja.html#Run-Time_Type_Information__RTTI_
RTTIを使っていいのなら手抜きなパッチをサクッと当てられるのもまた事実だ。
(RTTIありなら1行で済むのが、無しでvirtualで対応なら新規クラス追加になってしまう）

ここら辺は結局のところ、どのコード品質まで許容するか、であり、
当然体面は「常に今現在の仕様で最高のコードにしておけ」な訳だが、
現実的に「そんなん出来るかバカヤロー」である程度デタラメなパッチも許容するのなら話は変わってくる。
だからこの辺は「無くても実装は出来るし、困らない」のを認識した上で、
どこまで手抜きを許容するか、だと思う。


>>245
それは俺に向けたものではないと思うから補足になるが、
俺はそれに関してはC++ではなく他言語をやった方がいいと思ってる。
現状、手抜きに関してはLL言語の方が数段上で、C++は完全に周回遅れだ。
クロージャ採用も今更だし、リフレクション等も他言語で普通に学べる。
（それを使うかどうかはまた別として）

今現在、C++でしか学べない事って、
C++固有案件(テンプレートをこねくり回すこと等)以外にはないよね？
C++が先頭切って導入しようとしている事ってあったっけ？

248 ：
>>244
業界経験者としても概ね同意
ただリンク先読むと、さすがにOOPとデータ主導（と速度）を両立できないのは
さすがに設計力不足だと思う（実際日本のゲーム会社は海外と比べてOOPの浸透率が低い）
枝葉末節にこだわって大局が見れてないんだろうな（このスレ見ててもわかるように）

>>245
＞ある機能を使わない理由が知らないからで、結果無駄な労力かけている
＞知らない理由を正当化しようと、知る前から役に立たないとか抽象的な理屈で断定するのは逃げでしかないんだよね
過去レス読む限り総称的なプログラミングには精通してる人のようだけど
さすがに↑の2行は思い上がりすぎだと思うよ、自分で読み直してみ

＞手を動かす方で楽をするためには知識と知恵が必要で、知識を得るためには勉強が必要
人の時間は有限だよ
あとここでよく挙げられるEASTLの開発動機の和訳
ttp://i-saint.hatenabl○g.com/entry/20101012/1286822888
の、Game software issuesの項を読め

249 ：
ただまぁ、正直コンセプトが導入されたり他の理由で
総称的プログラミングが浸透する可能性は否定しないけどね
しかし自分の払った学習コストを正当化したいがために
学習コストまたは開発コストの増大を危惧する人を「不勉強」と貶すアマチュアの声が一番大きい言語だったら
C++に未来は無いだろうな（すでに無いという声もあるけど）

250 ：
自演すんなゴミ

251 ：
俺も自演と思ったw
文の長さ、漢字と平仮名のバランス、使う単語、全部似てるんだよね
自演と分かってないなら何かの病気を疑うレベル
それともC++使うとこうなってしまうのか？
長すぎるエラーばっかり見てるのも困りもんだな

252 ：
>>240
ここまで読みました

253 ：
長文で必死こくやつは余裕のなさが丸見えだ
それこそ言語に振り回されて及び腰になっている自分を恥じるあまり
防衛反射で攻撃的になっているだけだろ馬鹿馬鹿しい

254 ：
何言ってるか全くわからんが
とりあえずいつもの基地外が一人でファビョってんのは伝わってきた

255 ：
>>239
func(const char *)とfunc(int)のようなものが10種類くらい有った場合、
func という名前で検索するだけでは目的のものが検索できない。

さらに、どの関数が呼び出されているかが分かりにくくなりバグの原因に成り易い。
例えば、func(int)とfunc(char)が有った場合、
func('A'+1)と書いた場合に、intとcharのどちらが呼び出されるかが混乱を
招きやすい。例えばの話、もっと複雑になって、+演算子が　operator+()
によってオーバーライド(オーバーロードではない)されていた場合、
どうなるかとか。

256 ：
>>253
長文の人は知的な人が多い。短文の人は女子高生の略語みたいに馬鹿な人が多い。

257 ：
>>245
STLを使うより似たようなものを自作したほうが何かと修正しやすいと
いうようなこともあって、もし自作するならC++98位でも余り問題にならない
こととかあるんだよ。

258 ：
>>256
自己紹介乙

0xffなんぞ驚愕の不勉強ぶりが炸裂してるなｗ

259 ：
>>258
ちなみに俺は現実世界では天才と言われている。

260 ：
こっちでやれよ
https://mevius.2ch.sc/test/read.cgi/tech/1427572389/

261 ：
知的な人は2ちゃんで3行以上書かない

262 ：
そもそも2chに・・・

263 ：
>>261 >>262
そうでもないだろうて。

264 ：
>>255
なんか包丁は殺人にも使えるから包丁を使うのはNGみたいな議論
dump()のようなデバッグを容易にする関数は任意の変数を突っ込みたいし、その場合templateだけでは限界があるだろう

265 ：
>>264
ケース・バイ・ケースだが、例えばの話、dump(int a)が呼び出されていると
思っていたら、dump(char c)が呼び出されていてせっかくのデバッグ情報
すら混乱してしまう可能性も有るかもしれない。入れ替わっても特に問題ない
場合も有るが、それは作り方による。余り変化が大きいようなものを
overloadだけで済ますと無駄な悩み事を増やしてしまうかもしれない。

266 ：
だからC++はバカには使えないんだってば

267 ：
明示的にするためにcastがあるんだろ

268 ：
理性をもって使えば重火器も問題ないわけで銃解禁
というのは明らかに間違ってるわけで
メリットデメリットをちゃんと考えてんのかよって話なんだよ。

269 ：
>>265

256デフォルトの名無しさん (ﾜｯﾁｮｲ 6961-hioB)2019/09/02(月) 07:12:36.17ID:CuenWXUR0
>>253
長文の人は知的な人が多い。短文の人は女子高生の略語みたいに馬鹿な人が多い。


259デフォルトの名無しさん (ﾜｯﾁｮｲ 6961-hioB)2019/09/02(月) 07:26:46.74ID:CuenWXUR0
>>258
ちなみに俺は現実世界では天才と言われている。

270 ：
>>248
リンク先のは多分、綺麗なOOP（意識高い系OOP)を目指しすぎた結果だと思う。
ソースコードの品質『だけ』を目指した場合、そりゃそうなる、というのをやっている。

ソースコードの品質は一般的に

・長期的保守性（つまり可読性）
・仕様変更に対する強さ（というより不感度）
・ソースコードの流用性
　（他に持って行っても使える度合い≒自身内部で流用出来ればコード削減に繋がる）

が重要だとされるはずだけど、これには、

・値配列ではなく、ポインタ配列
・インスタンスは纏めて取るなんてやらず、一つ一つnewする
・配列は固定長なんて止めて全部自動可変長にする
・全部virtual

みたいに、JavaやLL言語の方向性で行った方が断然いい。
ただ、こういう無駄をいちいち外す事によりC++の高速性は成り立っているのだから、
ソースコードの品質『だけ』を目指した「綺麗なOOP」をやりすぎるとそれはゲームには向かない。
30年後に赤の他人が読む可能性もあるJavaと同じ土俵で議論するのが馬鹿げてる。

271 ：
>>249
> 学習コストまたは開発コストの増大を危惧する人を「不勉強」と貶すアマチュアの声が一番大きい言語だったら
> C++に未来は無いだろうな（すでに無いという声もあるけど）
多分これはない。
おそらくC++は積み上げ型の学習(=ここまで出来た！)をしたい奴にとっては
「項目がやたらある」という意味で居心地がいいんだ。
だからここ2ch（数の上での主力はモチベーションの高いアマチュア）には妙な奴が集まることになる。
K&Rはあっさりしすぎてて、読んでも彼等は何をすればいいのか全くピンと来ない。
だから彼等はCを貶す。
とはいえ、現実のゲームプログラマの大半は休日はのびてるだろうし、ここの動向とは全く別だと思う。

が、まあ、これはさておき、
現実的にC++が提供している「ゴリゴリにマニュアルチューニング可能」が出来る言語が他にない。
よってゲームプログラマをはじめとして最高速が求められる領域、今ならMLとかもそうだと思うが、
これらにはC/C++しかない。
ところがCは全くやる気がなく、現実的にはC++しかない。

現状C++の代替となる可能性の最有力はRustだが、
C++が全部入りを目指す以上、Rustが出来ることは「C++とゴリゴリのリンター」で出来る範囲でしかなく、
結果的にRustコンパイラ自体が「C++のリンター」になって終わるのではないかと俺は見ている。

なお学習コストも考えて取捨選別して生産性を高めようとしているのはC#だが、
結果的にJavaとダダ被りすぎ、そしてJavaが死ぬことは今のところあり得ないから、
死ぬならC#になってしまっている。これも残念なことだ。

272 ：
長文書くなボケカスR

273 ：
>>272
お前はプログラミングを止めた方がいい。

マジな話、ドキュメントを読む能力の必要性は以前よりもどんどん高まっていて、
今時の若者プログラマは英語もある程度読めないと付いていけないと思う。
母国語すら3行しか読めないようならどうあがいても未来はない。

274 ：
>>273
死ぬならC#とか情勢見誤りすぎだろw
WindowsでUnityはC#一択だ

お前はもうすこし纏める努力しろw
それか自分のブログでやれ

275 ：
>>273
マジモンなのか・・・？

276 ：
昔はドキュメント読まなくて良かったってマジ？
もちろん分野によるけど、公式のリファレンス等に目を通さなくてもなんとでもなる分野は圧倒的に昨今のほうが多いと思う
英語に関しても同じ
何やるかに大きく左右されるけど英語圏にしか情報がほとんど転がってないような分野も昔からある
というかCPU回りとかハードよりなとことかは特にそうじゃない？

277 ：
妄言の落書きがドキュメントとかもう病院行った方が良いよ

278 ：
>>273
必要十分にまとまったドキュメントなら長かろうが難解だろうが苦にはならないよ。
纏まりがない持論をだらだら垂れ流されたら鬱陶しいというだけのことだろ。

279 ：
分かるように書くなら
main関数を1000行書くヤツをどう思うか
だな

280 ：
いやたった２０〜３０行じゃねーか。。
まあjavaとc#に対する見方はかなり怪しげな感じではあるが。

281 ：
>>279
+1

.h に本体書く馬鹿もな

282 ：
>>278
マイクロソフトを筆頭とするアメリカのIT企業のドキュメントの密度の
低さから比べれば格段にまし。

283 ：
テンプレートとインラインは.hに本体書くぞ

284 ：
テンプレートのいいところは、関数実体化しない限り、インクルードヘッダーを要求されないこと。

285 ：
意味がわからん

286 ：
真相はCMのあとで！

287 ：
.hppとhを実装の有無で使い分けてるのっておかしいですか？
>>283みたいに実装をヘッダに書く必要があるときにhppにしてるんですが

288 ：
>>287
俺は実装のあるなしではなくC/C++の両方から呼ぶときには.hを、C++からのみ呼ばないときは.hppにしてる
このルールだと確かにheader only libraryは.hppだし、実装を含む場合は.hppと言えなくもない

289 ：
>>288
日本語おかしかった
C++からしか呼ばない場合は.hppを使ってる

290 ：
最初プロタイプだけだったヘッダにテンプレートが入ったら拡張子を変更して
そいつをインクルードしているソースを変更して回るのか？

291 ：
実装を含む場合は hpp てのは結構いいな。
まあ pimple はどうするとか言い始めるとめんどくさい話が出てきそうだが。

292 ：
何がいいの？めんどくさい話しかなくね？

293 ：
俺も最初から実装を含む前提のheader only libraryとただのプロトタイプに分けてるな。
後からテンプレートを追加する場合といっても、ライブラリじゃなけりゃたいてい明示的
インスタンス化で片付くしな。

294 ：
明示的具現なんかやだよ
そんなことするくらいなら非テンプレートで多重定義しておいて
実装を作るときに無名名前空間の中で使ったほうがマシだ

295 ：
今北産業

296 ：
>>294
個人的には、明示的具現化というか、
class TZzz : public TXxx<TYyy> {
};
のようにしておいて、TZzz を使うようにしている。

297 ：
>>296
なんかtypedefみたいな使い方だ
今時はusingか

298 ：
うん、usingだね

299 ：
3行しか読めない馬鹿はちゃんと本スレに行け。
C++相談室 part144
https://mevius.2ch.sc/test/read.cgi/tech/1563769115/
「その話何度目よ？」な馬鹿共も同様。


おまえらは真面目に議論しているつもりなのだろうけど、
インクルードファイルをどうするかなんてC++固有案件だし、
「プログラミング」の腕前の向上には全く繋がらないことをちゃんと認識した方がいい。
そして、様々な対処法があるということは、逆に言えば、ろくな対処法がないことを意味する。
なら、どうあがいても糞なのだから、さっさと諦めてgoogleなりMSなりの対処法に乗っかった方がいい。
それで問題があるならそこで改めて考え直せばいいだけだ。

当たり前だがGoogleやMSの規模なら社内にツール担当の専属が居て、
そいつらが日々どうするか無駄に議論して、結果をルールとして定めてる。
それらはツールチェインを考慮しているから多少制約が厳しかったりもするが、
(よほど詳しいつもりでなければ)彼等の方が詳しいのも事実だし、
オレオレ流より結果的にかなりましだと思うが。

一般的に社内ルールなんてガチガチで大体ブーイングの荒らしだが、
それに比べてgoogleのルールはかなり緩く、参考にするには悪くないと思うぞ。
(もっともgoogle社内でもプロジェクト毎にさらにルールを課しているとは思うが）

テンプレートガー、インクルードファイルガー、なんて話は、
JavaScriptの連中がやってる「セミコロンを打つべきか否か、打つならどこに打つか」と変わらない。
「プログラミングの達人」を目指すならそんなところに無駄にこだわらず本質に急ぐべきだ。
「C++の達人」を目指すなら合点がいくまでやればいいが、
どのみち初心者/アマチュアではgoogleやMS以上の解決策を得られることは無い。時間の無駄だ。
そこで空回りした分、空回りしなかった連中とは差を付けられていることを認識した方がいい。

300 ：
キチガイ来たー

301 ：
2ちゃん(2ちゃん)で油売ってる口でな

302 ：
俺が気に入らないのなら、まずは本スレに行くべきだ。

俺は「このスレが存在する限り、他のC++本スレには書かない」の宣言を今も守っている。
俺はお前らがやってる糞みたいな文法話には興味ないし、
お前らは俺の文なんて読みたくもないんだろ。Win-Winだ。
お前らが何故棲み分けしようとしないのか俺には分からん。

さっさと以下に行け。
C++相談室 part144
https://mevius.2ch.sc/test/read.cgi/tech/1563769115/

（棲み分けしてればその必要もないはずだが）
それとは別に、俺を2chから追い出したいのなら、
俺に似合いそうな別のコミュニティを紹介してくれたら、そっちに行って居なくなるかもしれん。
よさげな所があればよろしく。

303 ：
スレを私物化する奴はこの世から出て行ってくれたら嬉しいなあ

304 ：
>>303
スレを私物化しているのはお前だ。
お前の意見が大勢だとでも思っているのか？


いずれにしても、俺（または長文）を嫌いな奴が
ずいぶん前に分離してゴミカス化してるこのスレに書く必然性はないはずだ。
また、俺は今後とも上記宣言を守るつもりで居るのだから、
わざわざ今更このスレに文句を言う必要もないはずだ。

結局のところ、スレはここで喚いている>>303のような、
「ぼくのみとめたすれしかみとめないゴミ」が潰していく。
それは全体の利益にはならないから、俺は棲み分けを提案してる。

このスレが嫌いならこのスレを読まなければいいだけ、
そしてそれが正しければ過疎って落ちるだけだ。
単純にお前がこのスレを読まなければ済む話だ。
何故それが出来ない？

さっさと以下に行け。
C++相談室 part144
https://mevius.2ch.sc/test/read.cgi/tech/1563769115/

305 ：
> 「プログラミング」の腕前の向上には全く繋がらないことをちゃんと認識した方がいい。

腕前が向上してない低脳に言われる筋合いはねえ
おととい来い、クズが！

306 ：
ここはマジキチvoid君の専用スレです。
void君は本スレには二度と書き込まないと言っているのだから、彼の言うとおり本スレに移動しましょう。

307 ：
もったいないので私にください

308 ：
>>297
typedefにしていないのは継承クラス TZzz に機能を後々追加することを想定しての事。
必ずこのスタイルにしておけば、その時に修正しなくて済むので、
後々機能追加するかどうか分からなくても必ずこの形式で書くようになった。

309 ：
>>308
追伸：本当は、T ではなく C を使って
class CZzz : public CXxx<CYyy> {　　// 1
};
としている。typedef ではないので、CZzz をさらに継承して
class CZzz2 : public CZzz {　　// 2
　・・・
};
のようにすることもできる。もし、
typedf Cxxx<Cyyy> Czzz;　　// 3
としてしまっていたら、2のようには書けないはず。
この形式だと全て class で統一されるので何かと安定感がある。

310 ：
>>305
ならお前が本スレを引っ張れ。
お前のレスが素晴らしくて俺のレスがどうしようもなくゴミなら、
ほっといても誰もこのスレには寄りつかなくなる。
まあ頑張れ。
そうやってプラス方向の競争をしないと駄目なんだよ。


それはさておき、C++スレのアマチュアは本当によく考えた方がいい。
インクルードファイル等の問題はC/C++では避けられないが、こだわりすぎだ。
それはエディタのフォントや色に異常にこだわる奴と同じだ。
最初はこだわる必要があるが、一度自分のスタイルを決めたら、後はガシガシ書くべきだ。
そしてアマチュアがgoogleやMSのツール専属の連中以上に
適切な方法を選択出来ることはほぼあり得ないのだから、有り難くさっさと丸パクすべきだ。
つまり、初心者がそこにこだわっていること自体が間違いだ。

311 ：
>>299
長文書いてる間、長文書いていないヤツに差をつけられているわけだ
2chで高説垂れても聞く奴なんてほとんどいないのに無駄なことをしているわけだ
無駄なことをしている間、無駄なことをいていないヤツに差をつけられているわけだ
周回遅れを10回くらいしてそうなほど無駄なことしてそうだよね
君の人生だから時間をどう使おうと勝ってだけど、しっかりと認識することが大事だよね

312 ：
>>311
それはその通り。
だから俺も馬鹿がいない方が助かるから、
長文が読めない馬鹿はさっさと以下に移動してくれ。

C++相談室 part144
https://mevius.2ch.sc/test/read.cgi/tech/1563769115/


それとは別に、俺と話したい奴がここに投稿するのはそいつの自由だし、
それ以前にこのスレに何を投稿しようが、そもそも投稿する奴の自由だ。
ただ、このスレに投稿された場合、俺が反応するかもしれないというだけ。

これについて、俺は俺が勝手に行った「棲み分け宣言」を守っており、
今現在の本スレは上記として別にあるのだから、無視するならともかく、
わざわざここに来て俺に文句を言うのは単なる当たり屋でしかない。
それはお互いに益がないから止めてくれ、というだけ。


まあついでに何度でも言っておくが、C++のアマチュアは自己満足が過ぎると思うよ。
どの言語の初心者もそれなりに空回りしてるとは240で言ったとおりだが、C++もだ。
ただこれについては防ぐのは難しいのだろう。

だから実際「C++なんてRばいいのに」と思っている奴も多いと思うよ。
原因はお前らが無駄に勘違いして威張っているのと、C++言語が糞過ぎるのが半々だと思うが。
といってもまあ、どの言語もそれなりに糞な部分はあるし、
C++は積極的に糞仕様を破棄している分、頑張っている方だと言える。
RustがC++をきっちり殺してくれれば割とみんな幸せになれると思うけど、
今のところその可能性は薄そうだし、もうしばらくC++はのさばりそうなのがなあ。

313 ：
>>312
>今のところその可能性は薄そうだし、もうしばらくC++はのさばりそうなのがなあ。

世界最古級レベルのOSであるところのUnix系が台頭しているようにも思える昨今、
同じく最古級ではないにしても古くあるCを引き継ぐC++はしばらくどころか
ずっと残っていくかもしれない。

314 ：
>>311
自分の場合、文書を短くしようとすると推敲(?)するのに時間がかかるので
深く考えずに長文で書いたほうがむしろ速く書けることがある。

315 ：
>>31
>だから実際「C++なんてRばいいのに」と思っている奴も多いと思うよ。
>原因はお前らが無駄に勘違いして威張っているのと、C++言語が糞過ぎるのが半々だと思うが。

既に言語としては C++98くらいの段階でもかなりのことは出来ていたので、その後は
だんだんと好みの分かれる仕様となって言ってるのかもしれない。絵画などの
芸術作品で好みが分かれて、どの作品が良いのかを議論しても決して結論には
達しないように、ある人はC++98くらいの仕様が好きで、またある人は最新の
仕様の方が好きと言うような現象も起き得ると思う。

「C++言語が糞過ぎる」という件、多くの人が認めてはいるようですが、人によって
正反対の方向性を向いていたりします。ある人は古い部分が好きで新しい部分が嫌い、
ある人は逆に新しい部分が好きで古い部分が嫌いなのです。低級言語が好きな人と
高級言語の好きな人の違いかも知れませんが、単に学んだ時期の違いかも知れません。

使いこなせる人数からすれば、低級言語に比べてスクリプト言語の方が圧倒的に
多いとされていますので、単純に多数決で決めれば後者風が勝つことになってしまうでしょう。
しかしそれではC++の良さも失われてしまう可能性が高いのですね。

316 ：
>>315
【追伸】
プログラミングの効率面で考えれば、標準のライブラリで用意されているものは
使った方が有利ですので、std::xxxx のように書かれる STLを使って方が
当然良い面も多いですが、それは本当はC++言語そのものではなく、あくまでも
ライブラリですので極論すれば MFCやWin32 APIを覚えるのと似たような
立ち位置にあるとも言えなくも有りません。この板の人たちは、
積極的にそのような最新のライブラリを使って自分でコーディングをする部分を
少なくするほうが「賢い」という価値観を持っている人が多いようですが、
昔にC++を覚えた人から見れば、カチンと来るところはありますね。
新しい機能を付けた人の技術を使っているだけで、使っている人の能力でも
努力でもなんでもない訳ですから。当然、後から生まれてきて今学び始めれば、
そういう最新の機能を身につけるのは当たり前ですが、昔にC++を学んだ人が
無能であるわけではないのに馬鹿だとか老害だと言ってしまう人が多いのが
この板の特徴なのです。

317 ：
Wikipedia には、STLに「難解さ」がある例として、以下のようなものが
書かれていた。ここで使われている STL を十分に知らない場合には
「一見何をやっているのか全く分からないソースコード」になってしまっている：


size_t N = 0;
int *pdata = NULL;
GetData(&pdata, &N); // データとデータ数を得る

typedef std::deque<int> Cont;
Cont deq(pdata, pdata + N);
FreeData(&pdata, &N); // データを解放

// 典型的なSTLコード
deq.erase(
　　　　std::partition(
　　　　　　　　deq.begin(),
　　　　　　　　deq.end(),
　　　　　　　　std::bind1st(std::less<Cont::value_type>(), 20)
　　　　),
　　　　deq.end()
);

318 ：
>>310
腕前が向上してない低脳を認めやがったｗ

319 ：
インクルードファイルに関してはむしろもっとこだわれと思うことのが多いがな。
c/c++においては本質だよ。

320 ：
長文が読めないやつがどうたらとぬかす前に
読んでみたくなるような文章を書けっての

駄文書いといて読んで貰えないのを人のせいにしてんじゃねえ

321 ：
>>313
> ずっと残っていくかもしれない。
それはないね。
当たり前だがどの言語も利用価値があれば使われ続けるし、無くなれば廃れる。
現状、C++の利用価値は、EASTL等のページも参考にして、

・大規模コードでの高速性
・細部までいじれること（特にアロケータ周り）

位か。
一応Rustは両方目指しているので刺客の筆頭だが、
「Rust文法で書けばC++より速い」てなことはなさそうなので、C++を殺しきれない。
となると余程C++が嫌われない限り、エコシステムのないRustの方が先細って死ぬ。
つまりC++は、他に代替がない、という消極的理由でしばらくは生き続けるのはほぼ確定だ。
しかしそれは当面であって、永遠ではない。

Linusの目が黒いうちはLinuxにC++が入ることはない。
そして今更LinuxをC++で書き直したところで
「遅くて枯れてない劣化版Linuxモドキ」しか出来ないことが分かり切っているから誰もやらない。
Linux等をC++の生存理由と見るのは明確な間違いだ。
俺は2000年代中盤のOOP全盛時に「OOPで安全なOSを」みたいなのを聞いた覚えがあるが、
続報が全くないので完全にポシャったんだと思う。
それ以前にもC++でUNIXを、というのは失敗している。
http://hoshi.air-nifty.com/diary/2012/06/unixcosbill-joy.html
SymbianがC++だったようだが、Symbian自体が死んでしまったし。
https://monoist.atmarkit.co.jp/mn/articles/0703/22/news124.html

322 ：
>>315
単に仕様が欲張り過ぎなだけ。
「何でも出来る」を目指している分、「普段は使わない」仕様ばかりになっている。
ただまあ、そういう言語も1つは必要だから、この意味では存在価値はあるのだが。

>>316-317
そのコードが「分からない」のなら老害でいいと思うけど。
君は結局、「俺のスタイルで書け」を強制する連中を擁護しているだけだろ。
俺はそうではなくて、例えばLL言語(JavaScript)では

deq.filter(v => v>=20);

で済む内容をグダグダやっていることに疑問を持たないのは老害だ、という考え。
当たり前だがC++より新しい言語はC++の欠点も見た上で改善内容を盛り込んでる。
それを学ぶ気もなく、古いスタイルにこだわり、結果的に効率が悪いなら、老害だ。

ただし関数型風の場合、ショートカット時に最速を得ることは難しい。
だからC++流のグダグダ記述も一定の妥当性はある。（ただし今回は全走査の為該当しない）
そして「分からない」と「使わない」はまた別の話だ。
そのコードはLinusの言う「C++erが糞な理由」の典型的な例だと思うが。

323 ：
>>319
結局「どこに記述するか」でしかなく、C/C++ソースコードの編集術でしかない。
それは当初は「上手い人の真似」で全く問題ない。
(それ以前に俺は2パスにしてその辺の糞仕様を全部消滅させるべきだと思っているが）

お前の下で若者がミスリードされないことを願う。
そしてもし上司がこのタイプなら、俺みたいな考えの奴も居ることを知っておいて欲しい。
上司は選べないが、上司は君の人生に責任を持ってはくれない。
間違ったアドバイスはスルーするのが妥当だ。

324 ：
>>321
>つまりC++は、他に代替がない、という消極的理由でしばらくは生き続ける
>のはほぼ確定だ。
>しかしそれは当面であって、永遠ではない。

Unixが出来たのは1970年位らしいのですが、パソコンの世界では非力さのために
しばらく使うことが出来ず、BASIC言語、MS-DOSやWin95などが台頭しました。
しかし、LinuxやFreeBSD、cygwinなどの登場と共に台頭し始め、最近では
Win10の方がLinuxを使えるようにしてしまいました。2019年現在において、
Unix系は衰えるどころかどんどん勢力を伸ばしているようにも見えます。
実に50年です。50年続いただけではなく、50年後にもまだ勢力を伸ばして
おり、ネットの世界ではWindowsではなくUnix系が標準となっているようです。
安いレンタルサーバーなどではUnix系全盛ですし、古いと言われそうですが、
cgiも、perl、rubyなどもUnixと相性がいいようですし。
後から歴史を振り返って見るとWindowsが台頭したのは短期間で、Unix系が
非常に長い間使われていく可能性があります。

それと似たことがC/C++にも起きるかも知れません。ただし、STLなどを
多用しようとするような今風のC++というよりC++98位のCをベースとした部分です。

例えば、STLの >>317 のコードより、あなたが指定したように、
deq.filter(v => v>=20);
のコードの方がずっと分かり易いということは、STLには欠陥があるとも言えるのです。
ところが、CやC++98位の基礎の部分は違います。Unixと同じで今後もかなり長く
残っていく可能性があるように思えます。

325 ：
>>324
ちょっと訂正。後半部分は的外れかもしれません。
探せば STL でも filter 文に似たものがあるかも知れず、それを使うと
LL言語同様に短く書けるかも知れませんので。

326 ：
ですます変えてIP変えれば別人になれると思っているのが愚かしい
それ以外のところが全く変わっていない

俺が推奨する自作自演方法は、一旦Google翻訳にかけて別の言語にして日本語に戻すことだ
これで自作自演テクも幾分マシになるだろう

327 ：
>>322
>単に仕様が欲張り過ぎなだけ。
>「何でも出来る」を目指している分、「普段は使わない」仕様ばかりになっている。

誰かが指摘していましたが、C++は「一般化」にこだわりすぎているという
見方がありますが、一方で、

C++ では >>317のようにも書けてしまうという一般性は持っていますが、
JS や Ruby、Python などでもfilter文1つで済まさず、それ相当のものを
良く似た工程や順序で作れる一般性もあります。と同時に、それが
>>317 よりは遥かに短く分かりやすいコードに掛けるでしょう。

>>317のように書くくらいならば、deque, erase, partition などを使わずに
素朴に書いたほうが分かりやすて、かつ、短く書ける可能性が高いという
意味において、今の C++ の STL は予めある機能を使って楽しようとすると
逆に記述が長くなる傾向が有る気がします。

他の LL 言語では、高機能さと記述の簡潔さを同時に実現できるのと対照的です。
高機能でも長くしか書けないのであれば意味が無いとも言えます。

328 ：
>>326
別人です。

329 ：
ID変え忘れてるぞ

330 ：
今時はrangeで書くんじゃね？

331 ：
>>327
確かに素朴に書いた方が可読性が高いというのはある。
しかし同時に配列のメモリ管理を自然にしてくれるっていうメリットもかなり大きい。
まあSTLの仕様がわかってなくてユーザー定義のクラスをSTLに突っ込んだときは
さらに危険な気もするが。
メモリ管理をガベージコレクションも使わず、明示的な解放処理も使わないようにしようと思えば
c++かrustのような複雑さを伴うのはしょうがない。

332 ：
配列一つとっても、Perl, Ruby, Python, JavaScript などでは典型的な書き方が1つ
に定まるが、今の C++ ではさまざまな書き方が出来てしまい、C風の伝統的な書き方
をすると老害扱いされてしまうのは困るな。

333 ：
>>332
ですます調はやめたの？

334 ：
>>332
くだらん難癖つけてくるカスの言いなりかよ

335 ：
古いと言われても、配列はC++でも言語定義としては、伝統的なCと同じ
TYPE a[N1][N2];
の形式。

この板の人たちが薦めるような
std::array<TYPE, N> a;
の形式は言語定義ではなくあくまで STL というライブラリによる拡張
なのでSTLとの相性は良いが、記述が長くなるし良いことばかりではない。
ところがSTLを積極的に使いたい人はこっちでないと困ることもあって、論争に
成り易い。

336 ：
静的配列と動的配列で書き方違うとか言われてもなぁ
そもそもスクリプト言語は静的配列ないやつ多いから書き方が一意になってるだけだし

337 ：
ビルトイン配列用のbegin/endとかrankなんてのがC++11で追加になったり
shared_ptrの配列バージョンもそうだし、ビルトイン配列はまだまだ現役だろ
arrayにしろなんて金切り声あげるやつこそ新しいものに対応するのが精一杯で
冷静に状況判断する余裕がなくなってるだけだと俺は見ている

338 ：
>新しいものに対応するのが精一杯で冷静に状況判断する余裕がなくなってるだけ
これな。それをごまかすために必死に老外言いまくってる輩とかな。
どっちも使えるようにしとけが正解。

339 ：
ネット検索すると新しいものが上位に出がちなのでそれだけを見ていると
C++を知らない人が見ればスクリプト言語と似た書き方が出来てしまいそう
なのでそればっかり使ってしまいがちなのかもしれないが、
本当は古いものを学んでからでないとC++はまともには使いこなせないだろう。

340 ：
privateメソッドのユニットテストってするものなの？

341 ：
>>324その他
何が言いたいのかよく分からんが、お前はテクニカルライタか何かか？
なら、プログラミングを知らずにプログラミングのことを書くことは止めろ。
誤情報が拡散されて迷惑なだけだし、それを読んだ若者が勘違いするだけだ。

× Cが残る
○ C流のプログラミング手法が残る

であって、つまり「変数、代入、条件分岐、ループ、関数でプログラミングする」手法が残るだけだ。
ただしこれらはアセンブラで既に出来るので、少なくともC発祥ではないが。

STLの「分かりやすさ」について欠陥があるのはみんな認識してる。
ただC++のように最速を目指すならこの方法しかないのも事実だ。だから使われてる。
逆に言えば、最速を達成出来てSTLよりもましなものが無いからSTLが生き残っているだけ。

というかそもそも発想が逆で、○○が残る、ではなくて、使えるものが結果的に残るだけだ。
それは言語でも同じ。
最近の若者は自身の選択を正当化する為に俺が選んだ言語スゲー＝俺スゲーする傾向があるが、
これ自体に意味はないし、そもそも「言語」ではなく「プログラミング」を学べばこんな事をする必要もない。
だから俺はちゃんと「プログラミング」を学べ、と言っているだけ。
初心者にも分かる基準で言えば、その言語限定か、他言語でも必要なものか、で判定すればいい。

342 ：
>>327
まるで分かってない、と言うか、お前プログラミングやってないだろ、としか思えない内容。
それで何故俺に絡もうとするのか？

> 素朴に書いたほうが分かりやすて、かつ、短く書ける可能性が高いという
> 意味において、今の C++ の STL は予めある機能を使って楽しようとすると
> 逆に記述が長くなる傾向が有る気がします。
これはない。STLは現実的にはフレームワークだが、
フレームワーク等が正しく構成されていれば、それより簡潔に書くことは出来ない。
解決策は簡単で、以下のように書けるようにインタフェースを追加すればいいだけ。

deq.erase([](auto v){return v<20;}); // 条件に合致するものを削除

ラムダも入ったし、これもじきに入るとも思うが。
STLはイテレータで抽象化するという手法が間違っている。
9割以上の箇所で全走査するんだから、
常にイテレータを指定しろというインタフェースがそもそもナンセンスだ。
ただまあこれも、使っている奴は当然気づいていると思うよ。

お前も初心者がよくやる勘違い、
「ぼくがよめるこーどはいいこーど、ぼくがよめないこーどはだめなこーど」をやっている。
良いコードとは「書き手の意図が正確に伝わるコード」であって、
「僕が知っている範囲の手法で書かれたコード」ではない。
この点、マルチパラダイムは読み手側に様々な手法の経験を要求するという意味で悪なのだ。
だからPythonやC#はそれを意図的に制限している。

例えば、この場合の「書き手の意図が正確に伝わるコード」は
deq.erase_less_than(20);
だ。ただこれではあまりにも汎用性がないから、フレームワークとして整備するならその次の階層
deq.erase([](auto v){return v<20;});
になるんだよ。

343 ：
>>331
× > 素朴に書いた方が可読性が高い
○ 素朴に書いた方が『事前学習のコストが低い』

繰り返すが、可読性が高い＝書き手の意図が正確に伝わる、であって、
『知識のない読み手でも読める』ではない。
双方の手法共に十分な経験があり、STLのインタフェースが糞な部分が直れば、
単純に記述出来る場合は抽象度が上がった記述(例は以下）の方がいいに決まっている。
deq.erase([](auto v){return v<20;});
そして9割以上の局面においてこれは成り立つ。(※余談あり）

ただし現実的にはSTLはフレームワークであり、ゴリゴリ使用するとなると事前学習が必要だ。
だからチームとして使うか使わないか、使うならどこまでか、を決める必要があって、
通常は以下の3通りになる。

α. 全く使わない。
β. そのフレームワークが提供している型でのみ使う。
γ. 汎用コンテナに独自型を突っ込んでバリバリ使う。

Linuxはαで行く、とLinusが決めているのだから、そりゃboostを持ち込もうとする馬鹿は嫌われる。
それを不勉強というなら、Linuxだって例えばプロセス管理でPID等を可変長配列で持つしかなく、
当然vectorモドキをどこかに持っているはずで、それを探すのが面倒だからSTL使います、というのも
目的のプロジェクトに対する不勉強でしかない。
（既存の問題に対するコードは既に実装されており、必要なSTL的コードは既に存在しているはず）

βはLL言語のアプローチで、フレームワークは使うが深入りはしない、というもの。
実はあいつらが馬鹿にしている「スタティックおじさん」もこのスタンスなのだが、
スクリプト言語を使って調子に乗ってる馬鹿共はこのことにも気づけない。
まあこれはさておき、これは現実的なアプローチではある。

344 ：
γは意識高い系のC++erが推奨しているもので、彼等はβを認めないから嫌われる。
ここまでやると、フレームワークに対する要求知識がかなり高くなってしまい、学習コストが高く付く。
ただし、最速を目指すにはこれしかないし、
ふんだんに使っていいのなら使った方が簡潔/明瞭な書き方は出来る。

だからこれらは学習コストとの兼ね合いであって、
人的リソースは有限なのだから、知識的参入障壁を上げれば、技術的参入障壁は下がってしまう。
（STLを知らないがC言語範囲ならバリバリの人を捨てて、STLを知っているだけの人を入れることになる)
OSSはメンテ出来なければ自動的に死ぬ。
Linusは知識的参入障壁をCレベルで固定し、結果的に技術的参入障壁を上げて上手く行っているのだから、
これに対して文句を言うのは全くの筋違いで、文句があればforkしろ、でしかない。
そしておそらく、意識高い系C++erがフォークしてSTLやboostを使いまくったら、
Linusの予言通り、早々にメンテ出来なくなって死ぬ。それは
「STLは知っているがC言語レベルでは良質なコードを書けないからLinuxにはコミット出来ない、
でもコミットしたいと思っている」意識高い系C++初心者ホイホイになることが目に見えているから。

逆にゲーム開発現場のように、
STLを使い倒すと決めて、チーム全員にその知識を要求するのもありだと思う。
実際にこれが出来るなら、素晴らしい方法ではある。
『素朴』とかの言い訳は、多くの場合、ライブラリ内のコードをそこにコピペしているのと変わらないから。

だからこれらは結局、人的リソースを含めたコード戦略であって、
プロジェクトリーダーがどうするか決めてそれに従い、死ぬも生きるもそいつの責任、で行くしかないと思う。
ここでやってる話も結局、「俺はこう思うから俺に合わせろ」以上のものになってないでしょ。
どうであれ文句を言ってもしょうがないし、また、不勉強を正当化するのも間違いだと思うよ。
（全部知っておけ、と言っているのではなく、「これ以上は立ち入らない」という選択をした、と考えるべき。
そしてそれによる不条理その他も選択の結果の責任として受け取るべき)

345 ：
※余談
deq.erase([](auto v){return v<20;}); は抽象度が上がっているという点で良だが、
deq.erase_less_than(20); もまた同様に抽象度が上がっているのでありだ。
この2つはMatzの言う「ソースコードがドキュメントである」とも合致する。
駄目なのはその場に for文でしこしこ20以下のインスタンスを消すループを書いてしまうケースであり、
それは「読んでいてそこで引っかかってしまう」という意味で悪だ。
だからこれについての解決策はC++には用意されていて、
・そこには deq.erase_less_than(20); と書いて、 メンバ関数 inline erase_less_than(int); を作る
なのだが、inlineは最早効かないし、ユーザー定義型ならさておきSTLをこの方法で拡張するのは悪だ。

だから『素朴な』手法でも deq.erase_less_than(20) としてくくり出されていれば俺は良しとする。
そしてインクルードヘッダみたいなソースコード整形にこだわる位なら、俺はこういう
「抽象度が不揃いな部分を積極的に括りだして関数毎の抽象度を揃える」整形にこだわった方がいいと思う。
そのうち、同じような括り出しが多くて、
それらを纏めるにはどうしても関数型のインタフェースになるのも納得出来るようになる。
ただしこれも所詮は「整形」であって、あまりこだわりすぎるのもよろしくないが。

346 ：
boost賛美しすぎ

347 ：
長文を書く→ 情報量が増える → スレ番だけでは正確に返信できない → 引用する →さらに長文になる

348 ：
>逆にゲーム開発現場のように、
>STLを使い倒すと決めて、チーム全員にその知識を要求するのもありだと思う。
いや、EASTLがあるから使い倒してるイメージになるかもしれんけど、そこまで浸透してはないと思うよ
自社でSTLの独自仕様作ってまで活用しよう、なんて
たかだかコンテナごときにエネルギー注げる会社はそうそうない
世界最大のゲーム会社だからそこまでやってられるだけ

簡単な使い方に限れば(&マルチプラットフォーム対応のためのアロケーションの問題に対するきちっとした解があれば)別に難しいもんでもないからそれなりに使っていこう、って程度かと

349 ：
>>341
>× Cが残る
>○ C流のプログラミング手法が残る
>であって、つまり「変数、代入、条件分岐、ループ、関数でプログラミングする」手>法が残るだけだ。

OSに話を移して考えてみれば、
その程度の意味における「Unix流のOS手法」は、Winodwsに受け継がれているの
にも関わらずUnix自体が台頭している現実を説明できない。
コンピュータの世界では初期の頃に人気があったものが長く残るのだ。

350 ：
不必要に長文を書く人の動機が謎だ
謎だが、かといって、知りたくもない

351 ：
プログラマだからキーボードを打つのが速いからでは。

352 ：
>>349
× > Unix自体が台頭している
○ Linuxが台頭している

理由は単純に無料だからだろ。
これは「ケチ」な意味での無料の魅力もそうだが、
OSSで無料というのは全然意味合いが異なっていて、
安かろう悪かろう/高くて良い品質が共存出来るのは、値段相応だからであって、
無料で品質の良いものがOSSで出てきた場合、他が瞬殺されて、
結果的に「品質世界一」しか生き残れない超絶レッドオーシャン化する。
そしてそこで生き残り続けてるLinuxを誰も倒せないだけ。
実際、商用Ｕｎｉｘなんて、Linux以降は、昔も今も、死んで、どうぞ、だろ。

ただいずれにしても、言語が死なない、ということに過度に拘るのはどうかと思うよ。
プログラミングは死なないよ。

353 ：
>>350
動機なんかなくて、ただ我慢ができないだけだと思う。

>>351
打つのが速いのはいいが、思考を整理せずに垂れ流すのはいかがなものか。

354 ：
>>348
それくらいのスタンスが現実的に無難だと思う。
そもそもコンテナに入れる要素のrequirementsどこに書いてるんだよ？と思って探したが、ググッてもスパッとは出てこない。
> T は CopyAssignable および CopyConstructible の要件を満たさなければなりません。
> 要素に課される要件はコンテナに対して実際に行われる操作によります。
> 一般的には、要素型は完全型であることが要求され、 Erasable の要件を満たさなければなりませんが、
> 使用するメンバ関数によってはさらに厳しい要件が課されます。
> https://ja.cppreference.com/w/cpp/container/vector
だからその「さらに厳しい条件」の詳細はどこに書いてあるんだよ？と。

355 ：
>>353
>打つのが速いのはいいが、思考を整理せずに垂れ流すのはいかがなものか。
もっとたくさんの思考を整理した結果、あの程度の量に縮まった可能性がある。
難しい本なんかはあれの数百倍くらいあるし。

356 ：
>>352
>ただいずれにしても、言語が死なない、ということに過度に拘るのはどうかと思うよ。
>プログラミングは死なないよ。

Cやアセンブラが好きだったからその延長線上のC++も使っていた。
STLはRubyやPythonやJSのような分かりやすさも無いし、旧来のC++ native
に比べてそんなに優れているとは思わない。

357 ：
>>352
理由はともかくとして、コンピュータに関するいろいろなことが Unix風に
なって来てる気がするんだよ。理由は分からない。

358 ：
>>356
ただ逆に、生き残っている＝言うほどボロボロでもない、のも事実なんだよ。

LL言語のアプローチが好きなら、
・vectorしか使わない
・値は入れず、ポインタしか入れない。つまり全面的に vector<T*> で行く
・indexOf/filter/map/reduce/slice/concat等の配列メソッドは自前で用意してしまう
事をすれば同じ使用感にはなる。
ただそれなら最初からLL言語を使った方がいいが。
なおググれば実装例/コードはちらほら出てくるが、まだboostには入ってなさそうだ。

あと、StreamsライブラリというのがC++14から入っているらしい。
これについては俺より他の人の方が詳しいと思うが。
http://www.convertstring.com/ja/StringFunction/ReverseString
lmth.133-yrtne-golb/moc.2cf.golb.yihshoy//:ptth

ただまあ、C++は何も諦めてないので、
上記のように「やれば出来る」のは事実だが、無駄に煩雑になっているのも事実。
そこら辺はLinusもボロカスに言ってる。

359 ：
LL風にって動機でVector使うなんて筋が悪すぎ
Dequeueやろ

360 ：
delコマンドをCreateProcessで実行するとファイル削除できないが、
そのコマンドをファイル出力させてそのままコピーして張り付けるとファイル削除できるって現象に見回れているのだけど、
delコマンドって実行できない？？
ファイルが存在するかのチェックはしたのちに、そのファイルパスを利用しているからファイルパスに関しての間違いはない模様

361 ：
built in

362 ：
>>360
ＣＭＤ.ＥＸＥ ／Ｃ ｄｅｌ ファイル名
を CreateProcess で実行するようにすると del コマンドが使えます。

363 ：
>>362
なお、コマンド部分を半角英数字で入れると投稿時にブロックされるため
全角に直した。なので実際に行う時は(当然ながら)半角にする必要がある。

364 ：
>>360
作った途端に消すとかしたりしてない？
ファイルが実際にはあっても処理が早いと確認できなかったりすることあるよ

365 ：
del コマンドは内部コマンドで、del.exe というプログラムがある
わけではないため、CreateProcess() で直接実行することは出来ない。
実行したければ、>>362 のように、ＣＭＤ．ＥＸＥ を介して
使用する。

366 ：
> 9割以上の箇所で全走査するんだから、
> 常にイテレータを指定しろというインタフェースがそもそもナンセンスだ。

あれ？　コイツrange-based-for知らねえの？ｗ

367 ：
横からだが
それforだけじゃん
それforだけじゃん

368 ：
祈れ！Unified Call Syntaxが導入される日まで！！！

369 ：
C++の糞な部分が修正されるのならよいことだ。（使うか使わないかは別）
ただ俺はググって出てきた以下記事で、

> ドワンゴは本物のC++プログラマーを募集しています
https://cpplover.blogspot.com/2014/11/cunified-call-syntax-n4165-n4174.html

ってことの方に興味が行った。「本物のC++プログラマ」って何ぞ？
同様に引っかかった奴も居たようだが、ドワンゴの基準は分からない。
この点、googleなら自社有名プロジェクト、例えばchromeで
「このコードを将来にわたりメンテナンス出来る人を募集しています」
と出来るので、差が埋まらないのだな、とも思った。

プログラミングなんて手段でしかないのだから、本来は、
・将来的にもメンテナンスする価値のあるプロジェクトを --- (A)
・ずっとメンテナンスしていける能力 --- (B)
を実力とすべきで、つまり、
・OSSで生き残っているプロジェクト(A)をメンテ出来る能力(B)
というのは素晴らしく分かりやすい。
社員なら(A)は会社が指定するので(B)だけ出来ればよく、
ドワンゴ内で非プロプライエタリに出来るソースがあれば積極的に出して世に問うべきだと思うんだがな。
プログラミングの実力を面接で見抜ける奴なんて居るとは思えないし、
ドワンゴ社員が気に入るスタイルで書ける能力は、プログラミングの実力ではないし。

いずれにしてもアマチュアC++erは文法に過度にこだわるのを止めた方がいい。
文法で修正出来るのは精々数行の範囲での複雑さでしかなく、
「そもそも何でこんな構造にしたんだよ？」みたいな大域の複雑さには文法は関係ない。
そして問題になるのは常に大域の方だ。
というより小域のは大概は「書き方が気に入らない」だけであって、
必要であればラップ関数一つで大体収まることでしかないからだが。
勉強するのが目的になってるのなら本末転倒だ。
さっさと実現したい何かを書くべきだ。

370 ：
上から目線だがてめー自身は何なんだ

371 ：
川上さんに聴け

372 ：
本物のC++ とは、数年以上、山籠もりすべし！

C++テンプレートテクニック 第2版、επιστημη(えぴすてーめー)・高橋 晶、2014
C++11/14 コア言語、江添 亮、2015
組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド、MISRA‐C研究会、2006
Linux プログラミング・インタフェース、Michael Kerrisk、2012

Go, Rust, Ruby → Elixir, Python → Julia

373 ：
>>369
言語文法で保守性が変わらないならCOBOLやPASCALで書かれた遺物システムはモダン言語に即効置き換えられるべきでしょ

374 ：
>>372
MISRA とかいう聳え立つ糞ルールの山を挙げられても…（困惑）

375 ：
>>371
その通りだが、例題くらい用意してくれた方がお互いに助かるだろ。
それが解けない奴は最初から受験するなでいい。
有料化もありだとは思うが。
ハフィントンポストの/yuuya-adachi/post_7054_b_4928430.html
.ネーバー纏めの/odai/2142728139568393601
(URLはNG->自動BBXになるようだ）


>>373
コミュ障はプログラマを止めろ。
何が言いたいのか分からん。

どうせ発狂するのだろうが、その前に
・具体的に俺の書き込みのどの部分から
・俺がどう具体的に考えていると読みとれ、
・それに対して>>373がどう繋がるのか
を答えてからにしてくれ。
それが出来ないなら、お前は企業が嫌がるコミュ障そのものだ。
とはいえ当の企業もこれを認識出来てないのも事実だが。

376 ：
凄いのが現れたな
何拗らせたらこうなるんだろうな、知りたくもないが

377 ：
これが朝鮮半島メンタルか

378 ：
発狂してるのはてめーなのに
自分を客観的に捉えることができないやつだな

379 ：
設計レベルになるのだけどクラス分けが苦手でなにかおすすめのほんない？？

380 ：
>>379
本買わなくてもネットで調べればいろいろ出てくるじゃん

初心者にありがちなよくない実装としては、
・１万ステップとかの神クラスを作る（ほとんどの主要な処理がこのクラス内）
・クラス同士が密結合だったり、依存関係が複雑すぎてデバッグ不能
・機能を追加するために継承使う（そのため継承レベルが深すぎ）
とか、他にもいろいろ

381 ：
>>379
つGoF本

382 ：
>>380
うちの会社にそういう実装する人、結構いるわ〜
１０年以上の経験者でもｗ

383 ：
>>380
一つ目はともかく、後の２つは場合によるだろ

384 ：
iostreamですね判ります

385 ：
最近はクラス設計とかじゃなくて名前の付け方が一番大事だと思うようになったわ。

386 ：
>>379
まず関数を短く切り出せ。
その次に共通の引数を構造体にまとめろ。
そしたらその構造体をクラス化してみるとよい。

387 ：
>>383
> 後の２つは場合によるだろ

>> 依存関係が複雑すぎてデバッグ不能
>> 継承レベルが深すぎ
って言う「場合」の話だろ

388 ：
>>383
継承はis-a関係のときだけ使ったほうがいよくね？
機能継承使う奴のコードは大概汚い

389 ：
自分を大きく見せようとするやつが殺到するのがオブジェクト指向
つーか新しいプログラミングパラダイム

ところでオブジェクト指向って新しいか？

390 ：
>>388
has-aで継承とか一言も言ってないけど
多分>>380の一つ目を完全に前提にしちゃってるんだろうな
クラス同士の依存関係が強くなるのも、is-aの継承で機能追加するのも
そうすべくしてそうする事もあるだろ、ってこと

391 ：
逆に is-a の時にしか継承しないことにこだわりすぎると、それ以外の場合
でも敬称を使えばせっかく便利になる場合があっても機を逃してしまう事
がある。個人的には、普段使いする部分においての記述量が減ることが
大切だと思っている。ライブラリや基礎部分の記述量を多くしてでも、
普段使いする部分（応用部分）の記述量を減らした方がバグが減り易いから。
なぜなら、基礎部分については予め徹底的にバグを取ればよいが、
応用部分はテストをするのが難しかったりして事情が異なるから。

392 ：
>>379
本でプログラミングを学ぶのは、止めた方がいい。
理由は、入門書を書いている奴はほぼ「本を書くこと」に特化しており、ろくなコードが書けないゴミだからだ。
江添は認めているだけかなりまし。
> 残念ながら、今仕事用のコードを書くといっても、未経験者とそれほど変わらない程度の能力しかない。
> https://cpplover.blogspot.com/2014/02/blog-post_13.html

入門書ではない本は、それなりの人が書いたものもあるが、例えば禿本4部には、
禿のプログラミング思想とそれに対するC++での解が書いてあるが、
それじゃ分からないんだろ。
(俺が初めて読んだときには感動したが)

ネット記事は「初心者上がりのイキった奴」が書く傾向があるが、
それでも彼等はコードを日々書いている分、本しか書いてない奴よりいい。
実際、ググって上から数個読んでみたけど、悪くないと思ったが。

クラス分けを学びたいのなら、C++ではなくLL言語を使った方がいい。
C++は体感3倍ほど手間がかかるから、
逆に言えば、LL言語を使えば3倍の量を同じ手間でこなせ、当然、上達も3倍速になる。

393 ：
駄目なクラス分け＝保守出来ないクラス分け、なのだが、これに関しては、
・とにかくそれなりの規模のプロジェクトを立ち上げる(3000行以上）
・そしてそれをひたすら保守する
事をやれば自然に上達する。ありがちな間違いは
・全部書き直す
事を安易に選択してしまうことで、
これをやっている限り（書けるようにはなるが、良いクラス分けという意味では)上達はしない。
・何でこんな事になってしまったのか
・その原因はどこにあり、どのコードがどこにあるべきなのか
考えながら修正すれば自然と上達する。結局のところ、あれは、現実で言う、
・動線を考えて配置しろ
・道具は使う順に纏めて、並べておけ、
程度のことでしかないからだ。
間違ったクラス分けをしているとやりにくいだけであり、それは自然と気づける範囲だ。
書いてないことを実行してくれるはずもないので、「クラス分け」だけで差が発生するとしたら、
・どのコードがどこにあるか
の配置の違いでしかなく、これは、例えば
・車のパンク対応用のスペアタイヤを、車内ではなく、家の冷蔵庫の中に保管する
みたいな意味不明なことをやっていれば当然気づく範囲だからだ。

ただし最低限の規模は必要で、俺が思うに3000行がクラス分けが有効に機能し始める最低の規模だ。
それ以下ではベタで転がしていた方がましな場合も多く、
そこに初心者は無駄にクラス分けを持ち込んで余計に複雑にしてしまう事も多い。
https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpriseEdition

394 ：
だから、まずは、3000行の規模のコードを書けるようになるまで上達しないといけない。
それ以下なら、クラス分けなんて考えずに、ひたすら書いてまずは修行することだ。
クラス分けは、その後で学んでも全く問題ない。
そもそもOOPは大規模コードの整理術であって、
のべ1000時間もプログラミングをしてない初心者が理解出来る物でも、また、すべき物でもない。
「OOPはCみたいな手続き型とは別物だ」みたいな事を言う奴もちらほらいるが、これは老害の間違いで、
Cでも大規模になるとどうしてもstructが増え、何となくOOP化してくるのも事実で、
CのstructとC++のOOPは完全に連続的に繋がっている。
その証拠にstructとclassの区別がほぼ無いだろ。
「OOPは手続き型とは別物だ」というのはOOPを学びたくない老害か、
OOP本を売りたい糞ライタが嘘を言っているだけだから、そんな連中は無視でいい。

なお、「クラス分けが苦手」というのが本当にそうなのか？というのも少し疑問で、
「初心者上がりのイキった奴」がデタラメ言ってるのが多い昨今だから、
勘違いさせられている可能性もある。
いわゆる「コードを綺麗に」というのはつまり「長期保守可能なコード」にする為であって、
「正しいクラス分け」もその一端でしかない。
逆に言えば、それなりの規模で長期保守可能なら、「綺麗なコード」には出来ている、と言っていい。
具体的に言うと、10,000行以上で数年保守して来れており、本人もさほど問題を感じてないのなら、
少なくともそれなり以上の水準であることは保証出来ている。
結局のところ、Linuxのコードもこれに該当し、CにはOOP文法こそ無いが、
それなりにモジュール分割出来ている筈なんだよ。

そして余談だが、これがCや、或いはC++が今後も死にきらない理由でもある。
保守されてきているOSSは、それなりに「綺麗なコード」になっている。
だから、Rustみたいな「駄目な書き方が出来ないC++」ではOSSのC++プロジェクトを殺せない。
同様に、Cで「綺麗なコード」になってしまっているLinuxはC++では殺せない。

395 ：
俺はネット記事を勧めるが、クレクレ君はRという思想なので、良い記事を探してやることはしない。
ただ、お前に学ぶ意志があり、その上でネット記事を数本読み、
・この記事のこの部分に疑問がある。俺はこう思う。
という具体的な議論なら受け付ける。
3,000行のコードも書けない初心者なら、まずは何でもいいからガシガシ書くことだ。
クラス分けなんてその後でいい。

ただし仕事場でこれをやられると困るのは事実なので、結果、
新人(≒初心者プログラマ）に対してもOOPを徹底させる必要があり、
その辺が歪みの発生原因になっていることは認める。
ただ、ここで尋ねてくるのはほぼアマチュアだろうから、これに囚われずに、
まずは3,000行規模を書けるようになることを目指すべきだ。
なお、プロ(新人）なら上司に聞いたほうが早いからそうすべきだし、逆に、わざわざここで聞くなら、
「上司はこう言っているが、俺は違うと思う」という具体例をコードと共に出すべきだ。
その場合、俺らがどっちが正しいか判断してやるよ。
https://mevius.2ch.sc/test/read.cgi/tech/1467992113/10-

396 ：
>>391
個人的には〜以降の後半部分は同意。

前半部分は、反対でもないが賛成でもない。
理由は評価軸が異なるから。
俺はhas-a/is-aという形式論よりは、最終的にコードが目的に沿うかが重要だとしている。
それは大半の場合に於いて「長期的保守の為の可読性」だが、場合によっては「速度」だったりする。
(速度が必要なアプリなら遅いと存在価値がなくなり、長期的保守する意味がないから）
そして疎結合化には大抵の場合間接参照を一度噛まして当該コードを集めることになるので、
どこまで疎結合化するかも判断の一つだと思っている。
（というより疎結合化して問題がない場合は当然疎結合化するので、
残った物は速度等何かトレードオフがある物になるだけだが)

なおC++はクラス単位でしか継承出来なくてその辺不便だが、
JavaScriptは関数単位で継承出来る。
(というか、親クラスを自前で組み立てるだけで、その時に関数単位で引っ張ってこれるだけだが。
おそらくこれは動的言語の特性で、知らないがPythonやRubyも同様の筈。
Goが継承を廃止したと聞いたので俺は当然この機能がGoにもあると思っていたのだが、
無かったので愕然とした。
そしてもやもや考えているうちに、多分これは動的言語の特性なのだと（今のところは）結論づけている。
ただ、そうならGoって継承出来ないだけの糞でしかないのだが)

そしてこれがよいかどうかはまた別なのだが、
いろんな構造を試すという試行錯誤が簡単に出来るのは上達にはいいと思っている。
だからクラス配置を学びたい場合は、C++ではなくてLL言語を勧める。

397 ：
Ruby は、デザインパターン・疎結合の宝庫！

is-a/has-a, Duck Typing, Page Object, Test Double(依存性の注入), TDD/BDD(RSpec)など

398 ：
ruby書いてる奴、言うほどまともにテストしてねーじゃん。

399 ：
>>396
>なおC++はクラス単位でしか継承出来なくてその辺不便だが、
>JavaScriptは関数単位で継承出来る。
具体的に詳しく紹介してもらえませんか。

400 ：
プロトタイプのことだろう
継承とは言わない

401 ：
あれ？　こいつインターフェイス知らねえの？ｗ

402 ：
あーでもこれあれだな
長文はキモイな、やっぱ
OOは整理整頓術ってのはその通りだけど、長々と書かずにそれだけ書き込めばよい
あとは、プログラムにはデータ構造と制御構造の二つがあるんだけど
この別々のものを一纏めにするのがOOの悲劇の始まり、ってのを教えといてあげればよい
この辺ベテランでも割とモゴモゴする

403 ：
データ構造と制御構造を対応づけようなんて話は
ジャクソン法やワーニエ法、つまり構造化プログラミングの時代に
もう出てきてた話なんだが

404 ：
それを構文で取り入れたのがOO

405 ：
結局、「作る側（実装）」と「使う側（関数を呼び出す側）」を分けて、
前者を後者から隠すという事が class の概念の最も重要な部分で、
それによってさまざまなメリットを受けられる。
「オブジェクト指向」という概念は、実は、それとはかなり違うもので、
参考にするのはいいがそっちを重視しすぎるとそれはそれで問題を来たす
気がする。

406 ：
メッセージングがどうとかの話だと思うけど
あれは確かにC++では忘れた方がいいだろうね(そういう風にわざと実装する場合はともかく)
Objective-Cなんかだと言語レベルでメッセージ送る形になってるけど

407 ：
メッセージと名が付いてるから送り合ってるように見えるだけ
スレッド分けすらされてないシロモノ

408 ：
>>406
ん？
>>405 は、「カプセル化」と呼ばれる考え方で、メッセージとは
直接関係ない。

409 ：
classが入って便利になったもう1つのことと言えば、同じ種類のオブジェクトを
簡単にいくつでも作れるようになったこと。pure Cのグローバル変数と
ローカル変数だけを使ってそのようなことをしようとするとなかなか大変だったが、
C++ の場合、new CMissile のようにするだけで、ミサイルがいくつでも
追加できて、しかも、それぞれの位置や速度などがオブジェクト・インスタンス
の中にきっちり分けて入ってくれるのでとても便利。

410 ：
いやすまん、C++のクラスがいわゆる本来のオブジェクト指向には沿ってないって話だと思って
メッセージングなんかには全く沿ってないよねと言いたかっただけw
他にも色々あるんだろうけど、C++のクラスと本来のOOとは切り分けた方がいいのは同意

411 ：
オブジェクト指向にこだわるよりかはSOLIDにこだわる方がまだまともだわ。
あんな用語にこだわらなくてもできてるやつはできてるし、
理解しないでこだわる奴は糞押し付け始めるし害悪でしかない。

412 ：
SOLIDよりYAGNIだな
オブジェクト脳のやつはありもしない拡張性を考えて無駄に複雑にする
それif分岐で十分だから

413 ：
>>404
で、ベテランがモゴモゴって何のことだ？

414 ：
OOPにおけるSOLIDという言葉は初めて聞いたけど、何を言ってるのかよく分から
ない部分が多くて、すぐには理解できそうに無い。

415 ：
>>398
言語設計者が一時期ソースコード＝仕様書、という思想を公言していた記憶
ソースコードにはバグも含めて全てか書かれている（のだからその存在自体が正しいい
、みたいな

416 ：
OOは継承と多態性のしくみに夢を抱きすぎた
継承は当初差分プログラミングによる省力化がやたらと喧伝されたが、
多くの人がやったら効果など無く混沌が広がるだけだったので
結局>>402な見解に戦線が縮小して現代に至る

データ構造と制御構造（振る舞い）を(オブジェクトの名前).(メソッドの名前)という
単純な表記で呼び出せるように一緒くたにあえてまとめたために、
テンプレートによるメタプログラミングの道が開けた
結果さらなる破壊と混乱がもたらされた

417 ：
バカが使うと混乱して仕組みが良くないとわめき出す
って言ういつもの流れw

418 ：
何回言っても言い過ぎでないくらいまた馬鹿が出てくるからな。

419 ：
OOの根本的な思想的な問題点は凝り固まったカプセル化の考え方にあるかもしれない
カプセル化って自分の仕事しかしない頭の悪いアスペみたいな存在で
そんなのだけが寄せ集まっても集団として何もできないという
人間でも同じでアスペだけの会社なんて無理だろうに
電気回路でも電子部品はコンポーネントかもしれないけど回路が無いと動かない
回路はどこに書くんだっていうね
だからC++はマルチパラダイム言語になってて
無論OOもあるが、非OOな部分が存在することも許容している
1+1は1に"+1"というメッセージを送る、とか解釈するどこかのアホの言語とは違う

420 ：
これはあくまで思想的な話で、ものすごく大まかに言えばOOは左翼的な思想に属してて
本当にこれでよいのか？という疑問は常に付きまとう
こんなものを使っていると頭がおかしくなるんじゃないかという
実際プログラマは精神病になりやすいイメージがあるし
OOに染まったプログラマの言うことは回りくどくて聞いてられない
実際頭おかしいでしょ

421 ：
すっこんでろ

422 ：
https://ideone.com/pMPcFp
これはOOといえるか？
ベースコード80行も書いてるのに、メインロジック一つもないわ。

423 ：
まぁ部品作るのには向いてると思うよOOは
ただ、部品なんてものは会社で言えば非正社員みたいなもので
そんなところに注力してもな
大事なのはそこじゃないからな
簡単なことをより簡単に出来るようにして
それ以外の難しいことに集中できるのがOOの利点か

424 ：
>>423
カプセル化してユーティリティ作るにはクラス構造はかなり良い。

425 ：
クラス分けはやっぱりデザインパターン見とけって感じなのね
どういうときに使えば便利かってのがいまだによくわからんのよなぁ

426 ：
>>425
デザインパターンはゴミ。
ところでお前は何万行のコードを書いていてクラス分けが分からないの？

知りもしないのに嘘情報を垂れ流すのは止めろ。何の得にもならない。
お前はデザインパターンの有効性を判定出来るレベルではないだろ。
なら、その点については黙っておけ。
結果的に、お前らが知ったかぶりで嘘情報を流すからお前ら自身が迷惑を被るループになってる。
いい加減これに気づいてわきまえろ。

427 ：
>>デザインパターンはゴミ。
同意はするが

>知りもしないのに嘘情報を垂れ流すのは止めろ。何の得にもならない。
>お前はデザインパターンの有効性を判定出来るレベルではないだろ。
>なら、その点については黙っておけ。
>結果的に、お前らが知ったかぶりで嘘

ここまで言うならお前がクソ言う理由も書くべき

428 ：
>>427
何についてだ？
425についてなら、糞だと自明でないお前も糞でしかないだろ。
むしろお前が425みたいなゴミを擁護する価値があると認めた理由を先に聞こうか。
それが妥当と判断したら、俺が425がゴミな理由を述べてやる。それでフェアだろ。

429 ：
>クラス分けはやっぱりデザインパターン見とけって感じなのね
>どういうときに使えば便利かってのがいまだによくわからんのよなぁ
さすがにこれだけ読んでこいつがデザインパターンを過剰に持ち上げてるとは
ふつう思わんだろ。
普通に考えればよくわからんやつがよくわからんがやってみるかって言ってるだけの文章だろ。

430 ：
>>429
そもそもデザインパターンはクラス分けについての話ではない。
よって425は知らない癖にそれがさも「クラス分けに役立つ」と取れるような嘘情報を述べている。
もっとも、本人が積極的に嘘をついていると言うよりは、
過去誰かが425と同じようなことを書いたのを読んでいて、それを再度垂れ流しただけだと思うが、
それが425自身も既に嘘情報の垂れ流しループに組み込まれている証明となっている。
そして結果、自身も勘違いさせられ、また、勘違いした馬鹿を再生産して行っているわけだ。
そんなことは止めろ、と言っている。

過剰に持ち上げている事を咎めているのではない。
（というよりそもそも俺は過剰に持ち上げているとは捉えていない）
（結果的であれ、回避出来る）嘘情報を垂れ流すな、と言っている。

クラス分けについては、分からないのではなく、クラス分けが必要になる規模のコードを書いたことがないだけだ。
初心者は全員これだ。だから何度も規模を聞いている。
10行しか書けないのにクラス分けなんて分かるわけがない。全く必要ないからだ。
逆に、10,000行フラットに転がしてみろ。いやでもクラス分けが分かるようになる。

ただ最近の傾向として、425みたいな奴は増えている。
これは単純に、「ネットに書く」ということに関して前世代よりは若者世代の方が抵抗がないからだ。
だから知りもしないことをボソッとつぶやいたりしてしまう。そして本人に悪気があるわけでもない。
ただ、それでも間違った情報が拡散され、結果、それを読んだ奴が被害被るのもまた事実だ。
だから、知りもしない事柄についてはもうちょっと慎重に書け、ということでしかない。
同じ事はDeNAのキュレーションサイトでも起こったろ。
医者がうんちくや意見を（それなりに注意しながら）語るのはいいが、
医療知識が全くない奴がそれをコピペして適当に編集するからおかしな事になる。だから禁止された。
https://www.itmedia.co.jp/news/articles/1703/13/news114.html
同様に、プログラミングについての知識がない/まだまだ初心者の奴が知ったかぶって書くな、ということだ。
そして結果的にお前ら自身が被害を被っていることにも気づけ、ということ。

431 ：
何度も言っているが、OOPは初心者が分かるものではないし、分かるべき物でもない。
それは単に、大規模コードを扱ったことがないからだ。
だから、その程度の奴らがOOPに対して何か書くこと自体が不適切なんだよ。
>>402みたいな糞も含めてな。理解出来てないのなら語るな、でしかない。

432 ：
>10行しか書けないのにクラス分けなんて分かるわけがない。全く必要ないからだ。
>逆に、10,000行フラットに転がしてみろ。いやでもクラス分けが分かるようになる。
これはまったくその通りだとは思うが、しかしその機会のない連中が
とりあえずデザインパターンやってみっかってのがそんな悪いこととも思わんがな。
過剰な反応に思う。
医療問題のような致命的な問題がデザインパターンやることで生じるとは思わん。
確かにデザインパターン魔がシングルトン振り回してグダグダにしてったという歴史はあるが
そういうアンチパターンも最近は紹介されとる。
それでもカスな知識を振り回す輩は結局何やってもカスなことをやる。

433 ：
>>427
> >>デザインパターンはゴミ。
> 同意はするが
同意するならその理由を書けって言われてるだけ
まあ書けないからグダグダ中身のない長文でごまかそうと必死なんだろうけどw

434 ：
>>432
> しかしその機会のない連中が
だからこれがナンセンスだと言ってるんだよ。

OOPは大規模コードの整理術なのだから、
コードが大規模になったときにやればいいのであって、
逆に、大規模になったら、やる以外の選択肢はないんだよ。
(OOP文法を使うかどうかは別だが、「分割」はやるしかない。だからみんなやってる)

逆に、コードが精々500行程度、
つまり一般的なスクリプトの用途なら、OOPなんて一生必要ない。
だから知る必要もないし、また、この規模で適切に学ぶ方法もない。
つまり初心者レベルだとどうあがいても空回りする。

だから俺はグダグダ言わずにコードを書け、と言っている。
それがOOPが有効に機能する規模になれば、
余程馬鹿でない限り、自然に分かるようになる。それだけだ。

それはさておき、お前がサポートしたいのなら勝手にやればいい。
お前がデザインパターンを極めているつもりなら、422に講評つけてやれよ。
俺はお前らとは違う評価を付けている自信があるから、後出ししてやる。
もし俺と同じ評価をしている奴がいて、俺が何も言うことが無くなれば、俺の負けでいい。
（なお一応言っておくが、俺が賢いからではなく、
お前らが馬鹿（＝下手)だから俺と同じ評価を付けられないだろう、と見ている。
つまり俺はお前らを技術的には数段下だと見ている。それを「負け」たら見直す、ということ。）
我こそは、と思う奴は422に講評付けてみろ。
俺を伸したがっている馬鹿共もかかって来いよ。チャンスだぜ。

435 ：
72行程度の長文でさえしどろもどろなアホが
何がOOPの必要性だｗ

436 ：
デザインパターンは掃き溜めの鶴ではないか
何を言っているんだ

437 ：
>>419
左様アスペを組織するにはタイピング量が半端無いことになりがち
アランケイが豪語したようなステップ数の削減は常人がOOPしたらまるで逆になる

>>417>>419
バカでも安全にプログラミングができるようにする、というのがソフトウェアー工学の主要なお題目
だっ
たはず

438 ：
目的が不明なコードに講評だってさ

439 ：
一応言っておくと、24時間は待つ。
状況によってはこの土日全部＝48時間待ってもいい。
イキってるだけの馬鹿共はいい機会だから講評付けてみろ。
匿名なんだから失う物はないだろ。それが匿名掲示板の良さだ。

イキるだけだからお前らは馬鹿なままなんだよ。
イキる元気さをちゃんとプラスの方向に転化しろ。
イキっているのにここで参戦しないのはチキン過ぎるぜ。

デザインパターンを「言葉で」擁護するのではなく、「コードで」擁護してみせろ。
つまり、デザインパターンを極めたお前だからこそ書ける素晴らしいコードを提示し、
俺みたいにデザインパターンを馬鹿にしている奴との差を見せつけてみせろ。



>>438
ぼくはあのこーどがなにをするのかさっぱりわかりません、か。
はい、お前は負け決定。
そのレベルでイキってるからお前は馬鹿のままなんだよ。少しは自覚しろ。

440 ：
422ってメッセージパッシングをやりたいような気がするけど
それってOO設計じゃなくてOO自身の設計じゃん
スレの流れ的にそういう趣旨でいいんだっけ？w
とにかく >>439 の講評が楽しみだわ

441 ：
イキってるって言いたいだけやん…
てか本人が一番イキってるしw

442 ：
>>439
匿名掲示板で失うものと言えば、時間だな。
持論垂れ流して気持ち良くなってるだけの相手に議論しても、得るものはない。

443 ：
酔っ払いの独り言は誰も面白いと思っていない
駅前で不特定多数を叱り飛ばしている危ないオヤジと同じだ

444 ：
>>419
それは一理ある。実際、
自分の場合、1つのアプリの場合、ほとんどのclass メンバをpublicにしてる
場合がある。
しかし、class 分けすることで new CXxxx としただけで同じ種類のオブジェクトが
簡単に作成できる事や、似た働きを基礎に持っているが、基礎を発展させた応用的な
オブジェクトや同じ系統だが少しずつ働きの違うオブジェクトを、共通の基礎部分を
CBase クラスで書いておいて、それを継承したクラスで書ける事が便利になる。

だから、内部データにはアクセス禁止という意味でのカプセル化は達成したくても
なかなか達成できない事があるが、上記の様な意味で便利に使えてる。

445 ：
>>435
それは思う。

446 ：
>>444
補足しておくと、protected に出来るメンバはできるだけ protectedにしている。
例えば、ポインタで保持している何らかのデータなどは、ちょっとしたことで
間違って削除してしまう可能性があるので、そこにデータを書いたり、
ポインタが指す先を付け替えたりする関数は出来る限り protected にしてる。
そして、それはなるべく基本クラスの方にくくり出す。もし、別の関数でも
これと同じような処理が必要になったら、既にある関数を組み合わせてなんとか
ならないかを考える。そうすることで、ポインタのつけ間違いや誤ったオブジェクトの
削除を防ぐことが出来る。

ポインタ以外でも、データの整合性に関して慎重さが必要な場合は、上記と
同じようなことをやっている。

447 ：
>>444
structで良いじゃん

448 ：
>>447
純粋な構造体なら struct にして、名称も TXxxx にしている。
一方、メンバ関数があるものについては、原則的に必ず classにしている。
理由は、クラス定義を grep 検索する祭、必ず class CXxxx をキーワード
にすればよくなるから。これがもし、一部でも struct CXxxx というものが
混じっているなら class CXxxx では見落としてしまうことになる。
型名の頭文字が T の場合は、struct TXxxx と検索する。

449 ：
>>448
それから、その時はたまたま public: 属性ばかりなだけで、
後から protected: 属性のメンバもできてくる可能性も有るから、
純粋なデータ構造体以外は、必ず class に統一することにしている。

450 ：
システムハンガリアンにしがみついてる化石ｗ

451 ：
MSVCはstructとclassの扱いが違う糞

452 ：
>>451
どう違う？

453 ：
宣言と定義で変えたらlink出来ない

454 ：
んなことするやつこそ糞だと思うが

455 ：
コンパイラによる解釈の違いを「そうきたか」と微笑みつつ解決するも楽しいものだよ。

456 ：
>>453
デフォルトのアクセス修飾子違うんだから当たり前じゃないのそれ

457 ：
>>456
そういえばそうだね。

458 ：
>>456
宣言にデフォルトのアクセス修飾子関係ないだろ

459 ：
>>458
一見そう思うかもしれないが、
class/struct の完全定義で、public: や protected: などを全く書かずにいきなり最初の
部分に書いたメンバに対しては関係ある。
本来の設計では class Aaaa だったのに、使う人が struct Aaaa で宣言してしまうと
Aaaa の完全定義の最初の部分に書いたメンバは、本来は private 属性で禁止されていた
はずなのに、使う側ではアクセスできてしまうことになる。

460 ：
>>453が言っているのは異なるコンパイル単位で別の定義を使うという話じゃなくて宣言と定義だろ？

461 ：
こういうケースの話だとは思うけど
struct A;
class A
{
int a;
};

コンパイラがどう解釈するかは決まってるのかなこれ

462 ：
エラー出すんじゃないの？

463 ：
c++17のfilesystemで、windowsの「マイドキュメント」とか展開するときってどうやるん？
自分は、日和ってWindowsの関数使ったんだけど。

464 ：
>>459
リンクって何やる処理かご存知？

465 ：
C++のclassとstructの違いはデフォルトのアクセス権が、
class : private
struct : public
ということでしかなくて、アクセス権を追加するのは両方できる。
さらに継承もできる。

466 ：
継承の時デフォルトがpublicかprivateかもあったような？

467 ：
>>466
それは、クラスはprivateで、構造体はpublicで継承されたと思う。基本値として。

468 ：
>>461
決まっている
規格上は宣言時structだろうがclassだろうが完全に同じ扱い

msvcは同一コンパイル単位では警告出してくるし、別れているとマングリングが変わるせいで引数にポインタや参照が含まれる関数などがある場合、linkが出来なくなる

469 ：
classで宣言したものを、
わざわざstructで定義する必要性って
どんな時に出てくるんだ？

関数の仮引数を[]で宣言して
わざわざ*で定義する必要性なら
まあ出てくることもあるが

470 ：
>>469
規格知ってる俺スゲーしたいときだろ。
話聞く限りVCの方がまともで、C++の仕様もそちらに合わせるべきだと思うが。

471 ：
アンチMSにとっては挙動が他と少しでも違えば気に入らないんだろうさ

472 ：
>>464
「>>459」のようなことが間違って起きないようにするためにリンク段階でリンカ
が気付くように、わざと *.obj, *.lib ファイルレベルでのマングリング名
を struct と class で変えてるのではないか。

473 ：
>>472
そんなことが起こるわけ無いだろ
宣言だけで出来るのは中身関係ないポインタや参照の受け渡し

まあstd::hashやstd::allocatorの特殊化してみればいい

474 ：
>>473
そういう問題ではなくて、
静的言語のメリットは、プログラマの明確な間違い＝タイポや型違いをコンパイル時に落とせる事でもあるだろ。
structとclassを間違えているのならコンパイルエラーにすべき、というのがお前以外の他全員だと思うが。

そういうどうでもいいところにこだわりすぎてるから上達してないのだと思うぞ。

475 ：
勝手に総意を語らないでください。

structとclassは同じ文脈で使われることもそれなりにあるので、
どう判断したら文脈的に正しいと思いますか？

476 ：
>>475
まあお前の意見が違うのは分かった。
普通の人は、VCの動作で全く問題ないと思うが。
実際誰も擁護もしないし、必要性もないだろ。
逆にstructとclassを混ぜてる糞ソースでドヤア出来る感覚は頭おかしいと思うが。

477 ：
間違いで起きるかそれ？
それが起きるとしたら、同名だけど中身が全く違うものをincludeしてる状態だろ
class/sturctの違いだけ気づけてもありがたみない

478 ：
>>477
間違いではなくて、
書いてる本人が同じ物にstructとclassを混ぜて使っており、
その本人がそれでいいと思っているケースだろ。
少なくとも ID:X/zAGzhO0 と ID:E6lKnilk0 はそうなんだろ。

> 同名だけど中身が全く違うものをincludeしてる状態
これはほぼ間違いなくコンパイルエラーで落ちるから、それで問題ないと思うが。

479 ：
警告出されないほうが困る事のが多そうだけどな
どっちで定義するつもりだったのかわからんもん

480 ：
C++では、constが付いているかいないかでも、関数のmangling名が
違うので、リンク段階でエラーが出る。
こっちのエラーも余り深く考えたことが無いけれど、似たような意味で
structとclassが違っていればリンク段階でエラーになるようになっている
気がする。つまり、const属性の違いの混乱が起きていてもエラーになるが、
似たような意味でアクセス属性の違いでもエラーになるようになっている。

普通、ライブラリに対応するヘッダファイルを正しく #include していれば、
このような現象は生じないが、新しく追加された関数のプロトタイプ宣言が
無い場合に自分で、ネットにあったプロトタイプ宣言をコピーしてきたような
場合にconst属性の違いが生じることがあるかも。
それと同様に、自分で作ってるアプリの *.cpp と *.h で、勘違いして
class型の完全定義をstruct型で不完全定義してしまっているとか。
そういうのは中身まで間違っていることもあるので、リンク段階でエラーになった
方が、原因不明のエラーを防ぐのに有効だと思われる。

481 ：
structとclassで多重定義できるべきとでも言いたいのか？

482 ：
コードスメル的な問題はあるとしても実害は考えられないのでは？

483 ：
で、VCの仕様で助かった経験のある人いんの？

class/structの違いは単なる表面的なsyntaxの違いでしかないと理解するのは自然
それが実はバイナリに影響してるってのはいらぬ驚き
という主張はおれはわかる

別にVCの仕様がおかしいとは言わないが何か防御に役立つとは思えない

484 ：
>>482
>>459

485 ：
自分のポリシーとしては、
構造体は変数のブロック用程度にしか考えないし、ユーティリティ作るときはclass使う。

だから、構造体使うときは、アラインとか気を使う。クラスはどうでもいい。

486 ：
>>483
むしろお前は混ぜていい仕様で助かっているのか？

487 ：
本来privateであるべきところがpublicになっててアクセスできるのは起こり得るんじゃないの

>>483
混ぜる必要がないし混ざらないほうがいいと思うけど
まず宣言と定義でごっちゃになることがないから実害食らったひとはいなさそうだけど

488 ：
>>486
ニホンゴワカリマスカ？

489 ：
>>459
こそ勘違いの最足るものだろうに
structとclassは定義時のデフォルトがpublicになるか否か以外言語仕様上違いが無いんだよ
struct A;
class A;
どちらもクラスAの宣言

490 ：
>>484
だからさ、class Aaaaとstruct Aaaaの2つの別々の宣言(前方宣言じゃない)があって、
メンバのアクセス修飾子だけが違うってどういう状況なんだよ
間違いで起こるかそれ？

491 ：
前方宣言でclassとstructを変えることによるメリットは？

492 ：
こんな糞議論しなきゃならん時点で有害だわ

493 ：
むしろ合わせなきゃいけない意味がわからん
他人のカスタマイズ用のtemplate classでそれがclassだったかstructだったかを正しく覚えてなきゃいけないとか

494 ：
使うだけならclassかstructか書く必要ないし修正を加えるなら必然的にソースコード見るだろ

495 ：
いやだから特殊化するときだって

496 ：
Aaaa を完全定義をする前に Aaaa 型へのポインタを宣言したい場合に不完全定義として
struct Aaaa;
としておき、後から完全定義として
class Aaaa {
　　int　　　data1;　　// class なのでデフォルトのアクセス属性は private 属性。
　　・・・
};
を与えた時、struct と class の違いでエラーにするかどうかの議論ですね。
そして、完全定義したときにだけしか、デフォルトのアクセス制御の public/private の違いは
出てこないので、エラーにする必要が特に無い、という説が出てきていると。

497 ：
極めてくだらない話題だね

498 ：
>>496
完全定義されなければそのクラスのメソッドが何一つ呼べないｷﾓｽ
よって不完全定義ならstruct/classの違いはおkというのは無意味な議論すぐる、
よってコパイラは単純にエラーにする

499 ：
名前が衝突した異なる型として

500 ：
ちょっと関係ある話なんだけどマングリングていう単語、なんかちょっとエロ要素あるよね

501 ：
pimpleやるときは前方宣言無いと辛いと思う。

502 ：
前方宣言でclassとstructが違うとユーザーコード書くとき気持ち悪くね？

503 ：
ピンプるときは宣言を書いたのと同一人物が定義も書くだろ
そこで間違えるとしたら相当に頓馬なやつだぞ
自分の癖さえ忘れるのは認知症だぜ

# hashを特殊化するときなんかは間違えないように気をつけている

504 ：
>>498
むしろ、完全定義されていない限りメンバ関数もメンバ変数も何一つ
使えないために、private/publicのデフォルト・アクセス属性の違いの
影響がでないからこそ、完全定義より前の不完全定義は、structと
classの違いを問わないでいいとも考えられる。

505 ：
>>504
型付き言語は型に関するプログラマーの間違いを指摘するのが優先
型推論が行えるときに型推論してタイピング量を減らせる手段「も」提供するのが第二優先
この優先順序を取り違えて良いものなら型無し言語を選択するほうが合理的である

つまり型付き言語のコンパイラーが型の誤り（デフォルト公開属性がpublicなstructとprivateなclass間の誤り）を
許すような振る舞いをするのは、現実に問題にならないとしても、道理に合わない

型の名前だけ宣言したくてclassかstructかの違いはどうでも良いなら、そういう意味のキーワードが用意されるべきなんじゃ

506 ：
classに関するc++の言語仕様とそのグレーゾーンのコンパイラ依存の話であって
型付き言語のあるべき論語ったところでしょうがないでしょ
本来言語仕様でstructとclassは型的に同じか否かが明言されてればそれで終了の話
道理はどちらでも通る

507 ：
言語仕様上は同じであることが明記されているし、それは書籍やweb上でも触れられている
重箱の隅ではなく常識として理解していたのだが

同じだと覚えて、その通りに使ったのに、msvcに移植する段になって奇妙な現象として実体化するのが問題

508 ：
>>506
>classに関するc++の言語仕様とそのグレーゾーンのコンパイラ依存の話
non
カプセル化の遵守を口にしつつ、前方宣言の記述をちょっとサボりたいがだけのために
デフォルト公開属性がpublicなstructと
デフォルト公開属性がprivateなclassをad-hocに同一視するええかげんな体系が有り得るのかという話

同一視する意図が無くかつ名前だけの前方宣言をしたいならば、名前だけ宣言する意味のキーワードでやれば無問題
無理矢理別の意味がまとわりついたキーワードを流用するのでは
コンパイラもコードを書いたプログラマーも表現を全うしたことにならず気持ち悪かろう

509 ：
>>507
>言語仕様上は同じであることが明記
同じ「型」であるというソースｷﾎﾞﾝ

510 ：
>>508
gcc/clangでは通ること把握してるか？

511 ：
>>508
> カプセル化の遵守を口にしつつ、前方宣言の記述をちょっとサボりたいがだけのために

なんかお前は大きな勘違いしてる気がしてならないんだけど
前方宣言でclassと書こうかstructと書こうがカプセル化に何も影響ないだろ
なにがサボリなんだ？
classのかわりにstructと書いたらむしろ1文字多いのだが

512 ：
C++例外の功罪について騙りたい。

513 ：
>>512
語るのはいいが騙るなよ

514 ：
>>508
C/C++には安易に予約語を増やさないというポリシーがあったと思うし、こんなレアで下らない例外ケースのために予約語を増やすのは賛同されないだろうよ。

515 ：
>言語仕様上は同じであることが明記されているし、
これが本当なら、とっくに規格厨が該当箇所を引用してくれてそうなんだけど

516 ：
>>508
>カプセル化の遵守を口にしつつ、前方宣言の記述をちょっとサボりたいがだけのために
不完全定義の主な目的は完全定義をサボるためではありません。
自己参照や、2つの構造体 A, B が有った場合、お互いに互い違い
に参照したい場合にどうしても必要だったので、pure C の時代から用意されて
いました。なお、ここでの参照とは、ポインタ * による参照です。pure C の
時代には、C++の & による参照はありませんでしたので。

517 ：
https://timsong-cpp.github.io/cppwp/n4659/dcl.type.elab#3
> ..., the union class-key shall be used to refer to a union, and either the class or struct class-key shall be used to refer to a class declared using the class or struct class-key.

518 ：
>>516
訂正。自己参照は間違いでした。
完全定義すれば、予めの不完全定義がなくても自己参照が可能ですから。
不完全定義が必須なのは互い違いの参照です。

519 ：
>>507
> 言語仕様上は同じであることが明記されている
どこに書いてあるの？
お前の脳内か？w

520 ：
>>518
再訂正です。
pure C だと、タグ名だけでは型名にならず、class key を直前に書く必要が
ありました。つまり、struct Aaa {・・・} という完全定義の場合、
・・・の部分で自己参照をする場合、C++ だと Aaa *pX; で良いのですが、
pure C だと struct Aaa *pX; と書く必要があります。だから、こんな感じに
書く必要がありました。
struct Aaa {
　struct Aaa *pX;
　・・・
};
これは書くのがめんどくさいので、多くの人が
typedef struct _Aaa Aaa; 　// 不完全定義と typedef の組み合わせ
struct _Aaa {
　Aaa *pX;
　・・・
};
としていたのです。そのために、自己参照のためには、不完全定義が
ほぼ必須となっていたのでした。C++の場合は、typedef しなくても
class key なしのタグ名そのものが型名としても使えるので上記の様な
ことが必要なくなり、自己参照では不完全定義がいらなくなったのです。

521 ：
「カジュアルに警察や救急車呼ぶ」が物議　「適切な通報」か「ただの自己中」なのか？ | キャリコネニュース
https://news.careerconnection.jp/?p=41755

C++例外をthrowすることの是非論に近いものがあると思う。

522 ：
そんなにどうしても例外について話し合いたいならこちらへどうぞ
https://qiita.com/notenopg/items/40571e69986a58b888a0

523 ：
>>519
517じゃないの？

524 ：
つかお前ら解散して、本スレに行け。邪魔だ。
日本語読めない馬鹿韓国人>>488もな。

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


お前らの言うとおり、お前らと話しても時間の無駄だ。
文句を言われながらいちいち教えてやる意味はないから当然止める。
俺が422への講評を投稿することはない。タダ乗り狙いの馬鹿共はさっさと本スレに行け。
ただそれ以前に、俺がいくら書いてもどうせ読めないし、技術的にも理解出来るレベルにない。
正直、ここまでお前らが馬鹿だったのには驚いた。

ここで乗ってこないからお前らは馬鹿のままなんだ。聞くは一時の恥、聞かぬは一生の恥だ。
お前らは自分が馬鹿にされるのが怖くて何も言い出せず、安全地帯からクレクレ君だ。
ゆとりはネットの使い方を根本的に分かってない。
デジタルネイティブだから分かっていると勝手に信じ切っているが、それは完全な勘違いだ。
お前らは、今日ネットに向かって何か書いた後、書く前と比べて少しでも成長しているか？

コードを読む/書くのに時間がかかるのなら、それはお前らのプログラミング能力が足りないからだ。
それはやれば上達するし、やらないと上達はしない。つまり、やれば実になるものだ。
お前らゆとりはそういう地道な練習をしようともせず、ここでひたすら罵詈雑言だ。
それで何か得た物があったか？
こういう機会に地道にコードに向き合っている奴とはどんどん差が付く。そして今がある。
お前らはレベルの低さを自覚した方がいい。
そしてC++だけやっていても『今風の』プログラミングは学べない。それも知っておいた方がいい。

525 ：
（今風のプログラミングって何だろう？）

526 ：
スマートポインタの積極利用でしょ。

527 ：
C言語で今風プログラミングしてください。

528 ：
C言語で今風のスクリプトのインタプリタを実装します
スクリプトでプログラムを書きます

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

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

どうせ三日坊主で我慢できなくなってしゃしゃり出てくるんだろうけどよｗ

530 ：
ならクラス分けのやり方に役立つ知識をくれ！！！！

531 ：
自分の中の知識や経験からくる予断にひきずられずにそのプログラムの仕様・要件にのみ従って設計すんだよ

532 ：
それは無理
つーか動きゃいいんだって態度の素だぞそれ
１つの目標に対して複数の実現手段がある中から
どれがベストかという判断は知識や経験によるところが大きい

533 ：
それホントにベスト？

534 ：
何を基準にベストというかも知識と経験によるところが大きい

535 ：
まぁでも動きゃいいんだよ
すくなくとも動かないより大分良い
後、変に拘ってて糞みたいなやつより
素直なのがいい

536 ：
動かないのは論外
論外でなくなっただけで慢心するやつは
他人の批評に聞く耳を持たないオナニー小僧だ
プロの職人は客の反応に関心がある

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

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

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

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

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

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

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

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

544 ：
そんなこと自分で考えろ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

代表格はロガー

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

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

563 ：
代表格はロガーw

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

586 ：
>>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%落ちる」ではないだろ。
それでは使い物にならないと思うが。

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

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

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

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

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

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

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

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


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

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

590 ：
>>587

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

599 ：
>>598
まぁもうやめよう

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

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

600 ：
ちなみにちょっと気になって
>>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行程度)のコードを書かないと始まらない。
既に何度も言ったが。

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

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

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

604 ：
>>566
OpenGL

605 ：
>>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等でシングルトンが有効に使われているソース」と思われる物があればよろしく。

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

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

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

609 ：
C++13って何？

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

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

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

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

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

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

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

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

個人的にはuniversal initializationかな

618 ：
range-based for

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

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

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

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

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

622 ：
C++ って、

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

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

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

624 ：
出来る

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

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

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

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

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

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

631 ：
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};　　　　// ○, 一時オブジェクトの生成。

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

633 ：
【結論】
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} );　　// ○, 実際にコンパイルに成功する。

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

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

635 ：
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}
は等価であるかのように振舞っています。詳細は分かりません。

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

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

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

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

639 ：
>>615
using

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

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

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

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

644 ：
>>638
コンパイラ

645 ：
>>638
汎用ほにゃらら系統
可変長、任意型タプルのテンプレートとか。
クソの役にも立たんが。

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

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

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

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

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

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

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

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

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

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

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

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

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

659 ：
何度も言っているがお前ら池沼は邪魔だから本スレに行け。
俺は隔離されてやってるんだから俺に文句がある奴がここに来る必要なんて無いだろ。
C++相談室 part145
https://mevius.2ch.sc/test/read.cgi/tech/1568362404/
お節介ついでに言っておいてやると、
>>591と>>635は上達しないタイプだ。ただし>>635は救済の余地がある。
>>422と>>553は上達するタイプだ。だから俺は救済してやろうとした。

660 ：
>>422だが、ああいうコードをすぱっと投稿出来る素朴さは失うべきではないんだ。
糞コードだと叩かれたところで、どこが糞か指摘してもらえれば上達の手助けになる。
そこで「俺コードの方が上だ」と突っ張りあいをするのなら、それも切磋琢磨になる。
お前らは批判されるのを恐れてこれを全くやらなくなってしまっている。だから上達しない。
そして逆に、これをやり続けているのがOSSで、GitHubなんてその典型だろ。
コードを書けない奴に発言権無しの世界だから、お前らは参加出来ないとは思うが、
逆に、コードを書ける奴にとっては、お前らみたいな池沼に絡まれることがない、かなり快適な世界だ。
だからGitHubは本日も盛況なわけでさ。
>>553もちゃんと自分で考えて本質を見てるだろ。
言っていることはその通りで、従ってシングルトンなんて珍妙カラクリオナニーなゴミでしかない。
これに対して>>591は「シングルトンパターン」という権威？を「有用で正しい」と思いこみ、
活用の仕方を探している。これは方向性が全く逆だ。
これは自分で考える知能がない奴が陥るパターンだ。だからこいつは上達しない。
話を聞く限り、インターンで褒められて勘違いした奴じゃないかな？
インターンは新人以下の奴に1週間程度でそれなりに成果を出させて、
しかも仮に成果が全くなくとも本業に影響してはいけないので扱いが難しい。
そこで「モック」を作らせて「無いよりまし」な状況でテストの足しにしよう、というのは戦略として正しい。
それでおだてられて勘違い、というところだろう。
教育や結果に責任持つ必要なく、嫌われる価値すらないので、当然褒める。
お客様扱いでしかなく、同じコードを「新人」として入社後に書いたらボロカスに言われることを理解出来てない。
といっても、まあ、これを入社前に知っている奴なんて居ないから、本人の問題ではないが、
そこで勘違いしているようなら上達はしない。
ただこいつは話しぶりから学生ではなく既に社会人っぽいので、おそらくもう手遅れだろう。

661 ：
>>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は多いようだが）

662 ：
エレガントに書けなければ受け付けない、というのなら、まずは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またはグローバルで済む話でしかないし)

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

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

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

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

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

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

667 ：
>>666
ならそれは区別する必要がないんだよ。
お前らにとっては受け入れ難いだろうけど。
例えば、名前空間A内の変数Bと、
グローバルにあるクラスA内のstatic変数（クラス変数）Bは、どちらも
A::B
でアクセス出来るだろ。
これは区別する必要がない、ということなんだよ。意味的には同じだから。
で、この「意味的には同じ」が通じないのはお前らがコードを書いてないからだ。
お前らがまずいのは「文法」から入ってしまっていて、「文法」が違うから全て別物だと思ってしまっている。
そうじゃない。「意味」から入らないといけない。
そして意味から入れば、>>553のような見解に自然に到達する。
お前らは「文法」にこだわりすぎだ。
どういう構造にしたいのか、それが重要なのであって、それをC++ではこう書く、でしかないんだよ。
だから本来のプログラミングを学べば、他言語に関しては文法を覚えるだけになる。
小説で言えば、伏線の張り方や殺人のトリックにこだわるべきであって、
それを日本語で書くか英語で書くかというだけの話だ。
ところがお前らは小説について日本語ガー英語ガーとしかやってないから駄目なんだ。
シングルトンが糞なのであって、どのstaticを使っても糞は糞だよ。
文法の話ではない。構造/構成の話だ。
分かるようにとどめを刺しておくと、珍妙カラクリである限り糞だ。
なお個人的には関数内static(local staticと表記されるようだ）は禁止でいいと思うが、
googleもいまいち歯切れが悪いのは、google内でも揉めているのだろう。
あれは要するにグローバルなクラスが出来るだけだから、名前空間/クラス文法があるC++で使う意味はない。

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

669 ：
関数内static
と
クラス内static、グローバルなstatic
では
使い勝手が全然違うから同じではないんだよ
どのstaticを使っても糞って言うのも意味不明で
プログラム中に一つだけ存在するものだってあるだろうよ
C++的には関数内staticで書くのが慣例
そんなことも知らないで2chでベテランぶって長文って、終わってるよ
>なお個人的には関数内static(local staticと表記されるようだ）は禁止でいいと思うが、
↑アホ

670 ：
>>669
まあお前がそう思うならそれでいい。
ただ、お前はプログラミングに向いてないから止めた方がいい。
事実として認識すべきなのは、初心者でも>>553のように「意味」から入れる奴は居て、
その連中はそもそも自然に「スタティック」で通じている、ということ。
そしてお前はそうではない、ということ。
これは結局、「抽象思考」出来るかどうかであり、出来ない奴＝お前はプログラミングに向いてないだけ。
こればっかりは俺も対策の仕方が分からない。
一つ確実に言えることは、>>553は努力してその境地に達したのではなく、単に最初から出来るだけ。
そしてお前はそうではない、ということ。だから、向いてない。
大して違いはないんだよ。だから同じ static というキーワードで処理されている。
お前はそれを別物として覚えるタイプだ。それは記憶型であり、プログラミングには向かない。
これらは同じキーワードで記述出来ることが自然だ、と思えるタイプが抽象思考型であり、
プログラマとして大成出来る奴は全員このタイプだ。
だからこそ、プログラミング言語はこういう感じな訳でさ。
お前にとっては分かりづらい世界なのだろうけど。
デザインパターンの問題はここで、
記憶型＝プログラマとしては無能な奴に一縷の望みを与えており、結果、
彼等は他にすがる物がないから記憶量で勝負しようとしてパターンを覚えてｷﾘｯしたがってしまう。
それで良いコードが書けるのならよいが、そもそも無能な奴がパターンを覚えたところで無能に毛が生えた程度だ。
だから俺は何度も「デザインパターンを極めているつもりの奴はかかってこい、粉砕してやる」
と言っているわけでさ。あれは過度にありがたがるものではない。
向き不向きはあるんだよ。プログラミングも、無理してまでやるものではない。
おそらく高校物理で落ちこぼれになるか自然と優等生になるかと相似する。
高校物理も、出来る奴は努力したわけではなく最初から出来るし、無理な奴は努力しても無理なんだ。
それは記憶で対処しようとするからなんだけど、これを具体的に指摘しても修正は不可能なんだよ。
無意識領域の動作だから、対応出来る奴の方が少ない。

671 ：
>>659
根本的に間違えてるぞ
お前に文句のあるヤツがここに来るんだ
文句のないヤツはとっくに移動している
たまにスレタイ見て紛れ込んでくる可哀想な被害者たちには誘導してやってくれないか
なおプログラミングに向き不向きがあるのは同意する
俺は向いてないわ

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

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

673 ：
> 文句を言われながらいちいち教えてやる意味はないから当然止める。
ああやめろ
おまえ自分の言ったことちゃんと実行しろよ
どうせ三日坊主で我慢できなくなってしゃしゃり出てくると思ったらやっぱりそうだな

674 ：
>>673
数字も数えられないお前もプログラミングを止めた方がいいと思うぞ
ただそれ以前に、既に言ったが、
お前らは>>422が良いか悪いか、自信を持って言えないんだろ？批判されるのが怖くて
その程度なのに格好付けてイキっているから駄目なんだよ

675 ：
>>674
お前は何かとあるとすぐプログラマーやめろだな
指導者には向いてないな
にも関わらず何かを教えたがる
しかも相手が知らないと決めつけて
俺からするとお前指導者向いてないわ
人に何かを教えたがるのやめた方がいい
ハッキリと向いてないと分かる
でもやめないだろ？
だからもう、プログラミング辞めろとか寂しいこと言うなよ
これだけ言っても分からないなら、お前人間向いてないわ

676 ：
おっと、>>422についてのコメントを求められてたな
俺自身はオブジェクト指向ではないと思うが、オブジェクト指向との関係は密接にある実装だと思うね
似たようなコードの例を挙げるなら、例外クラスだ
Exceptionクラスにほぼ全てを書いて、FileNotFoundExceptionやValueErrorExceptionは継承して何も書かない
使い方もメッセージを投げるだけなので良く似ている
では例外はオブジェクト指向の一部か？と言われると答えはNoだ

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

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

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

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

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

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

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

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

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


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

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

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

とっとと失せろ

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

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

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

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

684 ：
もう一度書いておくか

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

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

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

686 ：
>OSSでソースを公開しまくってる。
>当然技術レベルも丸わかりだ。この意味では、精神的ヌーディストだ。
面白いなw
なんで自分がコード公開を好きではないのか
技術レベル以外の理由が解った気がする
最近はgplじゃなくてmitとかそれ系統が増えて安心している

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

688 ：
関数内staticの暗黙の排他はc++っぽくないと思うわ
バカに合わせる必要ないのに

689 ：
そこ対応しないと関数内static自体がmultithreadが普通の今だと、安全に使えない盲腸仕様になってしまうだろ。
templateとか絡めると、同期用のオブジェクト自体のふさわしい置き場が関数内static以外無くなることも有るのだからね

690 ：
こういうバカが本当に困る
目的はき違えている

691 ：
>>681
それだからお前はその程度なのだ。
お前は脳も性格もプログラマに向いてない。
お前はプログラマを辞めた方が、お前自身も、周りの人も、救われると思うぞ。
お前は「排他制御の忘れを、敢えて排他制御していないシングルトン上で競合させることにより落とす。
これでヒューマンエラーを低減させる(ｷﾘｯ」したようだが、それが間違いだ。
俺なら「排他制御の忘れを、排他制御忘れの検出機構により検出する」だけ。
そして実装例としてその場で2重mutexを思いついて書いただけ。頻出パターンでは当然ない。
お前のコードは全部珍妙カラクリオナニー集なんだよ。
周りの奴は、お前なんて死んでくれねえかなと思ってると思うぞまじで。
ちなみに2重mutexが頻出パターンではないことは客観的に言える。
コードが「絶対に通過しないパス」を含んでしまうだろ。それがアウトだから。
それすら気づけず一生懸命、し、知ってたし、と繕うのだからアホすぎる。
ただまあ、これはもういい。知ってた/知らないは大した問題ではない。
お前の言うとおり、パターンとして記憶し、今後はそう実装するのもありだ。
問題は、既に言ったとおり、お前のコードは全部珍妙カラクリオナニーな事だ。
○○をやりたいのなら、○○をやるようにコードを組むべきであって、
○○をしたいから△△を造って□□する、みたいなコードは駄目なんだよ。
お前はそれをやってしまっている。（そしてデザインパターンも全部これだから糞だ）
適切な実装を思いつけなかったのなら上司に相談すればよかっただけの話なんだよ。
相談する勇気がなかったから上達の機会を失ってしまっている。
ついでに言うと、上記の通り、2重mutexなんて俺の思いつきでしかない。
だから、「そんな実装は糞だ。俺ならこう」という突っ張り合いはありなんだよ。
それならここで切磋琢磨出来るだろ。お前らはこの「有効な上方向への競争」ではなく、
韓国人と同レベルの「悪口の言い合い」しかできなくなってる。だからゆとりは駄目なんだ。
そしてさとりはまだ素朴にあっけらかんとしているし、こういう糞な展開も見慣れており、
ある意味俺ら前世代より冷静に対処出来ている。だから俺は救済しようとしているわけでさ。

692 ：
>>687
> だいたい普通にプログラム書いてたら関数内static変数は結構使うはずなのに
まともなOSSで関数内staticを有効に使いまくっている例があればソースコード提示よろしく。
10,.000行程度なら読むから。
なおシングルトン以外で頼む。

693 ：
匿名性掲示板の限界。
信頼関係も何も無いとこうなる。
実績や学歴、何をしたいと思っているかなどが分かれば見方も変わるのにそれが
出来ないからトラブルになる。
例えば、C++の書籍を書こうと思ってる人なら実際問題余り使わないような
些細なC++の仕様を知る必要が有る。だから、templateやリストの初期化の
仕方などを細かく知ろうとしても馬鹿なわけではない。

694 ：
同じ文章や言葉でも プログラミング自体の初心者なのか、C++の仕様を知らない
だけで百戦錬磨の Cのベテランなのか、BASIC言語では凄く良いプログラムを
書いた人なのか、プログラミング経験は少ないが、コンピュータサイエンスの
博士論文を書こうとしている人、プログラムはしないSE、
組み込みやゲームなどに関心が有る人、
などの違いで意味は全く変わってくる。
そういう情報が無いから相手に対して失礼なことを言ってしまって話が噛み合わ
なくなり炎上のひとつの原因となりえると思う。

695 ：
>>694
いいんじゃない？
炎上、傍からみてると面白いし…

696 ：
>>693
限界と言って諦めるのは簡単だ。ただ俺はそれを突破しようとしている。

例えば、俺は一々理由を述べているだろ。
結果、お前らは理由を読み、納得出来れば採用、そうでなければ無視できる。
読者側に選択の余地を与えている。そして本来は俺の技術レベルも読みとれる。

或いは、突っ張り合いでも、上方向の競争になるように誘導しているだろ。
問題はお前らの大半がコミュ障過ぎてこれを理解出来ないことだが。
ただし>>572は明確に上方向の競争を誘っている。これは正しい匿名掲示板の使い方だ。
そのターゲットはまさに俺に対して今文句を言っているゴミ共だが、こいつらは勿論対応出来てないだろ。
結局、こういう事の積み重ねで差が付くんだよ。

匿名掲示板に信頼関係なんて不要だ。
というか、それが欲しければteratailやredditみたいな固定ID制の所に行くべきだ。
そこでは過去の全発言を掘れるから、信頼関係が必要なら安心出来るだろう。
或いは、○○に勤めている大先生、という肩書きが必要なら同様にFaceBookに行くべきだ。

匿名掲示板では、己が何者か、己の書き込みだけで証明する必要がある。
だから、思考をきっちり書き下せ、また、記述内容から相手を読みとれないと無理だ。
国語力も、コミュ力も、技術力も要る。
お前らは技術レベルが低すぎて、俺の意見が嘘なのか間違いなのか正しいのか、判定出来ないだろ。
そもそもその程度の奴が匿名掲示板に来てる時点で根本的に間違ってる。
「先生」が必要な程度なら、最低限、固定IDの所に行くべきだ。

もしお前が本を書く為に>>635等を調べていたのなら、本を書くのを止めろ。
お前程度の馬鹿に書かれた本はミスリードのオンパレードで、迷惑でしかない。

>>694
だから何だ？お前は相手の肩書きによって意見を変えるのか？
匿名なのだから、相手が言った意見に対してのみフォーカスすればいいだけだ。
自称「大先生」なら、そうだと分かる技術的に高い書き込みをすれば済む話だ。

697 ：
>>696
>自称「大先生」なら、そうだと分かる技術的に高い書き込みをすれば済む話だ。
ところが、ものごとは意外で、実は凄い内容を書いていても、ほとんどの
人には一見馬鹿に見える事が有る。例え一流のエンジニアや科学者であっても
上には上がいるので勘違いが入る。

698 ：
>>697
ここではそれは「偏差値が○○違ったら話が通じない」と「常識」として語られてるだろ。
そんな当たり前のことを持ち出して、お前は何が言いたいんだ？
さっさと結論を言え。

699 ：
一番話の長いやつがさっさと結論を言えとか
ナイスジョークw

700 ：
>>696
>お前らは技術レベルが低すぎて、俺の意見が嘘なのか間違いなのか正しいのか、判定出来ないだろ。
科学もエンジニアリングの本質はそのようなおしゃべり的な言葉では決まりません。
実績か、プログラムそのものか、証明などの論証、論文などで決まります。
正直あなたの発言からは、あなたが自分が優秀であると思い込んでいることは分かっても、
優秀であることは全く見えてきません。

701 ：
>>700
ならそれでいい。それがお前の判断なのだから。

702 ：
> 文句を言われながらいちいち教えてやる意味はないから当然止める。
ああやめろ
おまえ自分の言ったことちゃんと実行しろよ
いい加減にしろ
自制心なさすぎたボケ

703 ：
お年寄りの茶飲み話

704 ：
>>691
2重のmutexはお前が嫌うどっかの誰かが考えた典型的手法の1つだよ
お前が自力で思いつくことは既に誰かがやっていて、お前の嫌いなパターン化がされているんだ
自分で白状しているように非同期処理についてど素人であることは検討がついていた
なぜならシングルトンに非同期処理を入れた場合のデメリットに全く言及していないからだ
少しでも知っている輩なら、シングルトンに非同期処理を入れると頻繁にロックが発生しパフォーマンスが落ちることを真っ先に指摘する
同じ話で、お前がハードウェアに対してど素人であることも、またそれなりの大きなチーム開発を経験したことがないことも分かる
知らないことや経験がないことは恥ずかしいことではないが、ど素人が経験もないのに講釈を垂れるのは極めて恥ずかしいということは覚えておいて損はないだろう

705 ：
何でも有りなのが2chの良い所
罵り合いを読んでて自分は気付く事が有る時が時折有る
相手を叩き潰しやると思ってる人は全力で来る
だから中身が全部出てくる
それに応戦した人も結構中身を出してくる
その時に自分が気付いていなかった事に気付く事が有る
他にこんな場所は無い
自分の中の疑問がハッキリしない時に意外と役に立つ
お行儀良くやってると
何か隠していたりオブラートが厚すぎて良く解らない事も有るし
お行儀良くやりたいなら他に行けば良いのだし

706 ：
>>705
うふふ、そこが 2ch のいいところですね
でも、私は、この方法、いわゆる「炎上学習法」をやりすぎてしまったのが、ちと問題になってきています…

707 ：
自覚してたんだ...

708 ：
>>707
一応、ちゃんと動くコードを示す、式変形も示す、無茶苦茶無理筋はいわない、負けは認める、とか最低ラインを設定しているつもりなんですけれどもこのコテに警戒する人が多くなってしまいました…
しかしと私が数学が苦手であることをきちんと明示しておけば数学の先生にも相手していただいたこともあり、割合に 2ch は使える場所だと今でもおもっています

709 ：
>>704
日本語が通じない馬鹿韓国人はお前だったか。
まあそれで反論できたつもりならそれでいいのでは。
とにかく、お前は今すぐにでもプログラマを辞めるべきだ。周りの人の為にも。

そして何度も言っているが、馬鹿共は本スレに行け。
そして馬鹿韓国人>>704、お前はちゃんと誘導を一々貼れ。お前自身が望んだことだろ。

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

710 ：
ところで、いい機会だから、
「ゆとり」と「さとり」の違い、
および何故「ゆとり」と「韓国人」は殲滅されなければならないかを述べよう。

>>671と>>673は典型的「ゆとり」だ。そして>>693は典型的「さとり」だ。
一応言っておくが、本人の肉体年齢は大した問題ではない。
精神的に「ゆとり」「さとり」世代のどちらか、ということだ。

そして俺が出している結論は、以下だ。
・ゆとりは殲滅すべき ← 破壊工作を行うから、ネット上では特に酷い
・韓国人も殲滅すべき ← 日本語および論理が通じないから
・さとりは救済可能 ← こいつらは若すぎて分かってないだけだから
「ゆとり」と「韓国人」が居なくなれば匿名掲示板もずいぶん快適になるはずだ。
俺はそれを目指している。
だから「ゆとり」と「韓国人」は殲滅対象であり、こいつらにエサは与えない。
これに対して「さとり」は救済対象であり、むしろ味方に付ける為にエサを与えようとしている。

711 ：
典型的な違いは以下だ。

「ゆとり」 >>671,673
・長文が読めない
・気に入らないことに関しては、破壊工作を行う
・ネットでは何でも許されると勘違いしている
・上級者/先輩に対するリスペクトが全くない
・論理が稚拙で、韓国人と同レベルの知能しかない
・相手の意見は聞かない、連呼リアンと同レベルの声闘をする
・デジタルネイティブの誇り(ｷﾘｯみたいなのがあって、ネットを知っているつもりらしい
・粘着質

「さとり」 >>693
・長文耐性がある、というか長文に対する文句は皆無で、むしろ糞長くても全部読んでくるからビビる
・ネットは糞なものだと捉えている。まあそれ以前の状況を知らないのだから当たり前だが
・ネット上の態度は、諦め気味だが抑制は利いており、場を破壊するようなことはしない
・上級者/先輩に対する適切なリスペクトはある。むしろ旧世代の先輩＝神みたいな馬鹿共の方が問題
・従って上目の者に対しても普通に平気で反対意見を述べる。そして一応論理的
・意見は少なくとも聞くだけは聞く。ただし割とスルーする
・非粘着質。糞サイトか、次行こー的に軽い

つまり「さとり」は本来「匿名掲示板」と相性がいい。
それが上手く出来ないのは「さとり」が使い方を分かってないからだ。だから教えてやる。
まず>>693、お前はこれが「荒れていて問題」だと捉えているわけだが、これが間違いだ。
匿名掲示板ではこの程度は平常運転、喧喧囂囂でしかない。慣れろ。
実際、「ゆとり」の書き込みを除けば、割とまともだろ。正しい方向に流そうとしている奴は、俺以外にもいる。

712 ：
お前の問題は、>>700に現れているが、「学校」の癖を「匿名掲示板」に持ち込んでいることだ。
「先生」は「優秀」でなければならず、その「優秀な人」の意見は自分と異なっていても聞く、という態度だ。
だからお前は俺が「先生」足り得るかを確認しようとする。これが間違いだ。

匿名掲示板は学校ではない。つまり、大方正しいことを言っていると期待される「先生」はいない。
ここは現実で言えばディベートではなくパネルディスカッションであり、
自分でどの意見がもっとも妥当かを考えて選び取らなければならない。
或いは電車の中で小耳に挟んだ情報であり、情報の真偽は自分で確かめる必要がある。
もう一度言うが、「正しい意見」がもらえる場所ではなく、どれがもっとも正しいかを「自分で選び取る」場所だ。
よって誰が言ったかは全く関係ない。

典型的な「正しい匿名掲示板上の態度」は>>686だ。
元々ぼんやり持っていた疑問が、ああなるほどそう言われればそうだな、と解消してる。
「俺が」言ったか、「熟練者」が言ったか、「初心者」が言ったか、なんてのは全く気にしてない。
「言われてみればそうだ」だけだ。
つまり、意見だけにフォーカスし、それを自身で正しいと判定している。
分かるか？
匿名掲示板上で提供されるのは、「正解かもしれない何か」であり「正解」ではない。
そしてどれが「正解」かはお前自身が考えて選び取る必要がある。
だからパネルディスカッションのように、それについての俺の意見はこうこう、なぜなら云々、というのが基本ラインになる。
逆に言えば、このフォーマットに沿ってない連中は議論の仕方を知らない馬鹿であり、無視していい。

713 ：
お前に関しての修正点は、もっと堂々としろ、ということろか。お前は抑制しすぎだ。
>>607とか最終的に何が言いたいのかよく分からんことになっている。
そもそも「匿名」なのだから、お前が初心者であっても堂々と意見を述べればいい。
そしてそれがアホな意見ならそれなりに叩かれる、それだけの話だ。
意見を述べることに躊躇する必要はない。
それをお前は場を乱してはいけない、と思っているのか、中途半端に押さえている。
>>700なんて典型的にそうだ。>>697の時点で700を投稿出来ない理由がないだろ。
あれは697に一発で投稿されるべき内容で、逆にそうじゃないと話が間延びしてリズムを失ってしまう。
そしてお前が辛辣だと思っていることなんてここではそよ風程度だから、躊躇する必要なんて無い。
実際、「低学歴は黙れ」というセリフを東大卒が言うのか幼稚園児が言うのかでは、意味あいは異なってくるだろ。
お前は幼稚園児でしかないのだから、それを利用して、ここでは思ったことはズバズバ言えばいいだけなんだよ。

そこで>>607に話を戻すと、俺の意見は既に言ったとおりだが、再度纏めると、
どうせお前が使い物になる5年後には「C++23以降しかC++とは認めない(ｷﾘｯ」や
「エーマジキモーイ、C++17が許されるのは老害までだよねー」とかいう輩が出てくるから、
今から学ぶ連中は基本的に最新環境から開始しろ、だ。
これが「俺」「熟練者」「初心者」によって発せられた意見かどうかではなく、
この「意見」そのものが妥当かどうかをお前が判定するんだ。
だから、全てに於いて、「お前がそう判断するのなら、それでいい」であり、そうにしかならないんだよ。
分かるか？
電車の中で会話が聞こえてきた、程度の確度の情報であり、それが妥当かどうかは自分で判断するんだ。
「誰が言ったか」は関係ない。それが自分にとって納得出来るか、だ。

714 ：
学校というのは何も知らない子供達の為に「先生」という正しく導く存在を置き、
「先生の言うことは正しい」として学習効率を上げている。これはこれでよく考えられたシステムだ。
それは刑事罰に処されるような事柄から教えなければならない小中学校レベルでは素晴らしく機能する。
ところが、社会人レベルになってきて、何が正しいのかなんて分からない世界では、全く機能しなくなってくる。
だから資本主義は別の成長モデルを使っている。典型的にはフォークだ。

つまり、お前は法に触れない限り何をしてもいい、そしてそれが正しかったかどうかは結果で判定される、だ。
新商品を開発して自由に売っていい。自社で出来ないのなら会社を興してもいい。
売れれば儲かり、その商品は結果的に正しいとされる。
売れなければお前の判断は間違っていた、とされる。
非常に分かりやすく、シンプルなシステムだ。
OSSも同様で、いくらでもフォークしてよく、新機能追加も自由に出来るだろ。
それが売れたり使われたりすれば正しかったとされ、誰も興味なければそれまで、というだけの話だ。

だからフォークは基本的な成長モデルであり、フォークを阻害するのは反社会行動なんだよ。
そしてゆとりはそれを臆面もなくやる。だからこいつらは殲滅されなければならない。つまりゆとりは反社会だからだ。
これも何度も言っているが、俺は「フォーク」をしているだけだ。
つまり、現状の「本スレ」をそのまま残したまま、「俺がいる」点だけが違うスレに（結果的に）フォークしたのがここだ。
それでどっちが正しいか、結果で判定しよう、というわけだ。


（そろそろ連投制限にかかりそうだから尻切れならそう思ってくれ）

715 ：
ところがゆとりは
・ぼくのきにいらないもののそんざいはみとめない！みとめたくない！
という価値観であり、フォーク先が上手く回り出したら必ず潰しに来る。典型的には>>671だ。
このスレを無視すればいいだけの話だが、それで自分が結果的に置き去りにされるのが怖くて、必ず潰そうとする。
ところが全ゆとり的に賛成される物が存在するはずもないから、結果的にゆとりはありとあらゆる物を潰し合いしている。
そしてその結果が今だ。
これだけ価値観が異なるゆとりが、
前世代の巣窟であり、ゆとり的に居心地がいいはずもない2chに来なければならない理由は、
ゆとり自身が潰し合いしてゆとり的に居心地がいい場所がなくなってしまっているからだ。
こいつらは本当に救いようがない。
お前らゆとりは、フォークを潰すのは反社会だ、とまず認識しなければならない。
（フォークを無視するのは自由だが、フォーク自体をさせない/邪魔をするようなことはしてはいけない）

そしてさとりは、上記のように、ゆとりが反社会なクズだということを認識しておく必要がある。
どうやってもさとりの上司がゆとりになることは避けられない。
おそらく無駄にねちねち虐められる事になる。
それは上手く回避して、可能であれば転職して元居た会社を結果的に潰すとかして反攻していくしかない。
なかなかに大変なことだが、ゆとりの存在は現在の日本が抱える問題でもあるんだよ。

実際、>>704なんて酷いだろ。
パターン化されているかどうかなんて本筋に関係ないし、非同期と排他は別物なのに混同して連呼しまくりだ。
おそらく覚えたての単語で最高にイキってマウントを取っているつもりなのだろう。
ただこれが、典型的なゆとりであるのもまた事実で、ここから目を逸らすのもまた、間違いだ。

716 ：
再度言うが、俺は邪魔しかしない「ゆとり」「韓国人」が居なければ匿名掲示板も上手く回るはず、と踏んでいる。
だから手始めにまずフォークだ。
俺の書き込みが嫌いな奴は来なければいいだけ、勿論俺は本スレには投稿しない。
よってここで俺の存在について文句を言うのは筋違いだ、というわけだが、この論理がゆとりには通じない。
そしてフォーク自体を潰そうとするわけだが、これが反社会行動だということに気づく知能すらない。
だから俺は「ゆとり」「韓国人」を強制的に排除出来るシステムを今実装中だ。
そしてそれが稼働し始めたら、「『ゆとり』と『韓国人』に邪魔されない匿名掲示板」が出来上がり、
そこにフォークして勝負だ。
といっても準備にまだ数年かかるし、そもそも俺だけでは無理だから賛同者を募る必要がある。
俺が一々こういう事を書いているのは種まきであり、つまりお前らが賛同するなら参加しろ、というわけだ。

そもそも「反対意見」と「文句」は違うのだが、ゆとりにはそれも分からない。
そして>>700、それは「反対意見＝私はそうは思わない」であり「文句＝邪魔してやる」ではないので、
堂々と言えばいいだけなんだよ。（こいつもだが、割とさとりはこれはきっちり出来る、ただ抑制しているだけで）
それで切れる奴もゴミだから無視でいい。
ただ、お前の問題は、そもそも着眼点がズレまくっていることだ。
お前はまず、ここが「匿名掲示板」であり「学校」ではないことから認識しなければならない。詳細は上記の通り。

717 ：
あとお前もだが、お前らはどうにも「人」ばかり見てて駄目だ。
例えばシングルトン、「ゴミだ」という俺の意見に対して、馬鹿共は「俺」を否定することに躍起になってるだろ。
匿名掲示板上の馬の骨を否定しても何にもならないだろ。
そうではなく「必要だ」というのなら、否定対象は「ゴミだ」という「意見」であり、
典型的にはシングルトンを使わなければ美しく実装出来ないであろうOSSを持ってくればいいだけだ。
そこでシングルトンを使わない構成でよりよく書き換える事を誰も出来なければ、「ゴミだ」という「意見」は否定される。
それだけの話だ。
お前らは「意見」にフォーカスすることが全く出来てない。

今リアルで「差別ダー」とかほざき回っているのは「韓国人」と「パヨク」だが、
内容はいい加減にしろ、というものばかりだろ。
連中は嫌われることをしておきながら、嫌われることの言い訳を「差別」としているからだ。
残念ながらリアルはフォークできない。しかしネットはフォーク出来る。
だから、2chのように「ゆとり」「韓国人」も自由に投稿出来る匿名掲示板と、
俺が今後用意する「ゆとり」「韓国人」を排除した匿名掲示板にフォークして、どちらが上手く回るか勝負だ、ということ。
そして俺の目論見通りなら、何だ、悪かったのは「ゆとり」と「韓国人」か、と認識され、リアルも変わってくるだろうさ。

718 ：
>>705
そういう見方ももっともだが、
それは「議論慣れしている連中だけで議論している空間」を知らないからであって、やはり効率は悪いんだよ。
例えば、俺がこんなメタ事象について説明するのではなく、
C++について、シングルトンについて、staticについて、
同じエネルギーを投入して書いた方がお前らにとっても断然有益だろ。
ところがそれは今は出来ない。
理由は「ゆとり」と「韓国人」が下向きの競争ばかり仕掛けて片っ端から潰していくから。
だから俺がフォークしてそうじゃない世界を提供してやろう、というわけだ。
といってもまだまだ果てしなく遠いが。
とにかく、結果的に炎上するのならさておき、意図的な炎上は邪魔でしかない。
それは短期的利益の為に長期的利益を阻害する。よってコミュニティにとっては破壊工作でしかない。
ところがゆとりはこれを平気でやる。結果、ゆとりにとって安住の地がないという、自業自得になっている。
ただ俺らも被害を食らっているので、フォークしてゆとりから逃げ出そうというわけだ。

（これで全部。連投制限は緩和されたのか？)

719 ：
緩和されたかまで読んだ。
長いので3行にまとめてくれ。

720 ：
>>719
ゆとりと韓国人はR
さとりはもっと堂々と自由に振る舞え
正しい匿名掲示板の使い方を学べ

721 ：
横からだが
>>635 は向上心はあるのかも知れないが筋が悪い
今の仕様を確認しても意味が無い
どうせまたすぐ obsoleted になるから

722 ：
RustがあればC/C++とおさらば！
コンパイラのセルフホスティングとGUI付きのOS（Redox）を書きったC/C++に次ぐシステム記述言語！！
つか後発が先発より優れたものでなかったらこの世は闇やがな、

723 ：
ゆとりだと？　おい小僧、誰に向かってぬかしてんだ
俺は FORTRAN 66 と APPLE ][ 世代の者だ
コードも仕事ぶりも見ることなく何がわかったつもりになってるんだ？
俺はたぶんおまえの年収の２倍じゃ効かねえ消費税業者だ
ゴチャゴチャぬかす前にてめーの目の前の需要に触ることさえできなくて
ここで駄文を垂れ流す暇を持て余してるんだろ
軽率な差別的発言から国際人でないことがよくわかる

724 ：
>>689
何十年前のコンパイラー使ってんの
struct a {
　inline static std::muxex m;
};

725 ：
>>720
あんまりスレを消費するな
このスレはお前の寿命みたいなもんだからな

726 ：
>>724
それだと不必要に同じmutex使い回す事になる
template引数毎に別々のものとして同期とりたいのに

727 ：
>>726
お前の主張する
・templateを使ったときに暗黙で排他な関数内staticが無いと困る
サンプルコードを上げてみ。
んで、誰かがそれをよりましに書き直せばいいだけ。

まあそもそもtemplate引数毎に同期化機構、というのが間違いな気はするが。

728 ：
>>726
これでええやろ
template<typename...>
struct a {
　inline static std::mutex m;
};
template<typename T>
auto f() {
　auto g = lock_guard{a<T>::m};
}

729 ：
>>723
それが本当だとして、Facebookに行けとしか。

見れば分かるが、お前 ﾜｯﾁｮｲ ffab の発言なんて全部ゴミだ。
俺はお前みたいな不規則発言しかできない馬鹿を一人ずつBANしていけば、
匿名掲示板も正常化すると見ている。
当然こっちだってお前が本当に「ゆとり」なのか「韓国人」なのかなんて分かるはずがない。
よってお前らが言う「差別ダー」みたいな逃げ道もない。
コミュニティを長期的に悪化させる馬鹿を粛々と一人ずつ除外していくだけだ。
いくら荒らしまくっても罰すら受けない、という今の状況が異常なんだよ。

言うなればドラえもんの「どくさいスイッチ」を与えたとき、上手く使いこなせる奴が居るか、という話だ。
そしてGitHubは優しい独裁者モデル、つまりまさにこれで盛況となっている。
フォーク(＝下克上)の権利を与えた上で独裁する、というのが、
今のところ一番ましな成長モデルだ。だからそれを導入する。それだけ。

例えばそこのQZとか、俺なら最初からBANだ。それは単純に
・QZを嫌って出ていく奴らが行う筈だった有効な投稿の総量 >>> QZが行う有効投稿の総量
だと見ているから。
この判断が間違いだというのなら、QZあるいは信奉者がフォークして別の掲示板を運営すればいい。
そしてそこの方が繁盛するなら、俺の判断が間違いであり、掲示板自体過疎って終了して終わるだけ。
極めて公平な戦いだと思うが。

実際、誰をBANすべきか、という判断は極めて難しい。
だから、やる気がある奴にやらせて、上手い奴が勝ち残る、というシステムがフォークだし、
逆に、フォークが機能している状況では、それを上回ることは出来ないと思うよ。
それで「差別ダー」とか言っていた言い訳が、
本当に差別だったのか、それともダダをこねていただけなのか、白黒つけられる。

そもそも匿名掲示板に「差別」は存在しない。誰もお前が何者か分からないのだから。
BANされるのは単なる荒らしで、そのBANが過剰か適正かをフォークで決着させる。

730 ：
>>728
(君への批判ではないが）
> Scoped Locking Pattern
> Strategized Locking Pattern
> https://cpprefjp.github.io/reference/mutex/lock_guard.html
なるほどC++自体が珍妙カラクリオナニー言語化してたか。
なら確かに double mutex pattern とかもどこかにあるんだろう。（ググッても出ては来ないが）
壮絶にアホすぎる。Linusが切れるのも分かるし、俺も切れるわ。

結局、コードを書きもしないお前らがC++を使う理由は、珍妙カラクリオナニーし放題だからだな。
そしてCではこれが出来ないから、お前らはCを嫌う。
となるとLinusの「C++を使っていいのは、Cで出来る範囲までだ」という
ナンダカナーな線引きも妥当性を帯びてくるわけだ。

C++が珍妙カラクリオナニー言語化したのはC++11からか？
ならC++スレ内にもC++98、C++03の信奉者が居るのは一定の妥当性がある。


728自身はそのコードを例として上げただだけだと思うが、
もし仮にそれに似たコードを書いているのだとしたら、アドバイスとしては、
・サンプルコードから出発しろ
になる。具体的には、上記URLのコードをコピペした状態から魔改造するべきだ。
そうすれば、訳の分からないコードになることはない。
どうも初心者はローレベルコード（低位コード）をこねくり回したくなるようだが、
本来君らがこねくり回すべきはハイレベルコード（上位コード）だ。
具体的には、上記URLなら、classXの中身ではなくて、classXをどう使うかに注力すべきだ。
おそらくは入門書が「連結リストを作ってみましょう」みたいな
ローレベルコードのサンプルばかりだからだと思うが、
実際はローレベルコードなんて熟練者が作るべきで、初心者が作っても使えないゴミでしかない。
逆に、ハイレベルコードは原理的に常に人手不足だから、とにかくアプリに近い部分を書くべきだ。

731 ：
>>729
BANしたきゃ勝手にすれば？　できるわけねえだろアホｗバカｗｗｗ
分かるわけねえのにゆとりと断言したのお前だぞ　アホｗバカｗｗｗ

しどろもどろ乙

732 ：
こいつ自覚してるかどうかはわからんが
物事の考え方が典型的な共産主義者だな
穢らわしい

733 ：
>>730
C++の流れとしては機能ごとに細分化をしているので、珍妙化現象の流れはかなり昔からあった
castが4つに分類されたあたりから、ん？っと思っていた輩は多いだろう
constがconstexprと分離され、mutexが3つに増え、templateにエイリアステンプレート・変数テンプレートが追加され、と
ニュアンスは似ているが厳密には異なるものをどんどんと分離しているので、細分化はこれからも進むだろう
大雑把な概念が同じものは同じキーワードでと言っている人間には辛く厳しい現実が待っている

734 ：
>>733
あの 4つのcast の分類の仕方に疑問を感じる。ちゃんと理解するのが難しい。

735 ：
気に入らなければCスタイルキャストを使えばいい

736 ：
cast関連で分かりにくくしているのは、用語の問題も有る。
図で書く場合、日本語だと基本クラスを（基礎として）下に置いて、継承クラスを
上に積み重ねていく感じがするけど、なぜか C++ においては、上に基本クラス、
下に継承クラスがあるようにイメージしているらしく、ちょうど、根っ子を上に
書き、枝や葉を下に書いていく、（自然の木とは逆さまの）「ツリー」を書いているように
捕らえているらしい。up-cast は、「上へのキャスト」とされるが、その
上とは基本クラスへ向かう方向のこと。逆に、down-cast とは、「下への
キャスト」で、継承クラスへ向かう方向のこと。

誰が考えたのか知らないけれど、個人的には、この感覚が逆さまな感じがするので、
cast の説明を理解するのに時間が掛かってしまった事がある。

737 ：
俺は４つのxxx_castそのものに異議はないな
唯一、reinterpret_castであるべき内容の一部がstatic_castになっているのが不満といえば不満だが

738 ：
>>736
木構造の根っこを上に書くのは、C++の継承関係に限らずコンピュータ関連で広く一般的に使われている概念だと思うよ

739 ：
ディレクトリの表示だってルートが左上だね

740 ：
木構造の図解なんて大抵ルートは上だと思うが…
組織図も同じ、生物の分類も上か左が大分類
ソフトウェアのモデル図なんかは下にベースを置いて上部が乗っかってるというイメージを出すけど木構造なもんではない

741 ：
生物の分類は下をルートとするものも多かったわ
すR

742 ：
基本クラス = base class
base = 基本、基礎。
図示するとき、木構造は根っ子を上に書くことが多いが、その一方で、
「基礎」は下に書くことが多い。base とは「基地」という意味もあるが、
基地は下にあるイメージ。

743 ：
>>732
なるほどお前がパヨクなのは分かった。
それはお前が事象を捉えられない馬鹿であることをお前自身が証明している。
本当にその年齢なら完全に老害だぞ。

フォークは資本主義のいわゆる「競争原理」であって、
逆に共産主義は一切のフォークを認めない。
共産主義は「独裁」であり、これは資本主義においてはプロパガンダ的に「悪」とされており、
これがお前みたいなパヨクな馬鹿が「共産主義者」とレッテルを貼りたがる理由だが、
これ自体もお前が馬鹿である証拠でもある。

実際は、「独裁」自体はさほど悪いものではない。
「独裁」であればこそ決済は早く、資源を集中投入することも可能だ。
実際、いわゆる開発独裁で失敗した国なんてない。
問題は、その独裁者が役割を終えた後も私腹を肥やし続け、また、虐殺を行うことであって。
（これをしなかった指導者は歴史的に見てもカストロしか居ない。この意味では彼は偉大だ)

開発独裁のように、国中にインフラが足りず、教育水準も低く、
やるべき事が山積している状況であれば、独裁の方が機能する。
とにかくやることが重要であって、何を先にやったところで大差ないからだ。
何を先にやるべきか、なんて議論は時間の無駄でしかない。

ところが、独裁は結局の所、「一人の天才指導者が多数の愚者を導く」モデルだから、
独裁者が天才として振る舞えなくなると失速してしまう。
共産主義が滅んだのはこれだ。
社会が成熟してくると、次に何をすべきかを指導者が正しく指し示すことは難しいからだ。

744 ：
資本主義ってのは逆で、結果で正しかったかどうかを判定するシステムだ。
くどいようだが言い直すと、共産主義は、指導者が正しいと認めた物をやらせるシステムであり、
資本主義は、民衆がそれぞれ勝手にやり、結果的に生き残った物を正しいと認めるシステムだ。
根本的に逆なんだよ。
だから資本主義はスピードが遅く、回りくどいが、最終的に勝つシステムだ。
そして共産主義は序盤の立ち上がりは早いが、最終的には負けるシステムだ。
これは歴史上もそうだ。
5ヵ年計画も最初の2周（10年）まではアメリカを上回っていたが、
その後ソ連は失速して滅んで現在に至る。

これらから、現代社会は、いいとこ取りのハイブリッドシステムになっている。
つまり、最上位レベルでのフォークを認めた上で、小単位では独裁を認める、というものだ。
例えば会社、オーナー会社なら完全に独裁も出来るし、
株式会社なら集団指導体制だが末端社員が方向性に関与出来ない意味では共産主義でしかない。
ただ、これらが方向性を間違ったとき、倒産するなり、首をすげ替えられる点が違う。
それはその上位でのフォーク、つまり、会社の倒産が可能性としてあるからだ。

この「倒産の可能性」というのが極めて重要で、これが歯止めになっている。
だからまあ、完全に脱線するが、
例えば神奈川県町田市が、今回の給水妨害騒動を聞いて、
「オラ、東京都の方がいいべ」とか思って東京都に編入される事を望み、それが成立するようだと、
結果的に神奈川県の自治体がどんどん減っていって神奈川県が倒産するようになる。
これがあり得る状況だと、今回のようなイジメな顛末は起きなくなる。
同様に、N国がNHKに倒産/解散のプレッシャーを与えているのも正しい。それだけで全然違うから。

745 ：
とまあ、現代社会は、
大局的なところでフォークを認めることにより方向性を見失うことを無くし、
局所的なところで独裁を認めることにより加速させる、というハイブリッドシステムになっている。
今のところはおそらくこれが一番いい成長モデルだ。
だから程度の差はあれ資本主義は全部これを採用している。

GitHubは「俺の独裁に文句があればフォークしろ」で、まんまハイブリッドシステムだ。
だから流行るし、成長する。
同様に、匿名掲示板にもフォークのシステムを導入するのは自然な成り行きでしかない。
そしてそれは最終的には勝つシステムだから、緩やかに浸透していくと見ている。

で、何で俺がこんな事を垂れ流しているかというと、
・なるほど、と思った奴は参加しろ
・そもそも誰か丸パクして今すぐ始めてくれ
だからだ。実は既に複数箇所に打診済みだが断られている。
一般に掲示板運営者というのは神として振る舞いたいらしく、自分が倒される可能性を許容出来ないらしい。
仕方ないから俺がやるか、としてちまちま実装を書きためつつ現在に至る。
アイデアは丸パクしてくれて構わんから、我こそは、と思う人はやってくれていい。

そして以上のように、俺の頭の中ではスターリンもカストロもGitHubも経済も2chも神奈川県も接続されている。
俺自身はこれを「知識のネットワーク化」と呼んでいるが、
俺の中でこれが始まったのは高校2年くらいで、それ以前はひたすら個々の事象を暗記してた。
そしておそらく、「ゆとり」世代に知識の積み上げについてのリスペクトが全くないのは、
彼等が「知識はネットワーク化するもの」ということを知らないからだと思う。
30%も削減されれば知識量自体は中二同等レベルでしかなく、それではネットワーク化しない。
漢字を読めない外国人が漢字の便利さを知らないのと同様、彼等は知識の有用さを知らない。
（漢字は教育コストが高すぎる面もあるが、それはさておき）
まあとにかく、だから肉体的にはさておき、知能的に「ゆとり」かどうかはまあわかる、というわけ。

746 ：
ついでに別の例を挙げると、>>635は微妙なところだろう。
こいつは荒らしではないが、馬鹿すぎて、現時点では役に立つ書き込みは出来ない。
よって、BANしたところで失うものはない、とも言えるが、あまりに厳しいと書き込みを躊躇する奴が出てくる。
とはいえ、躊躇する連中なんてそのレベルであって、
こんな奴要らん、と最初から思える連中は問題ないし、むしろ、BANしないことに幻滅する。
だから取り扱いが難しい。

これに対して、俺の判断が正しい、だから俺の言うことを聞け、というのが共産主義の独裁だ。
この意味では、現在の2chはJIMだかひろゆきだかFOXだか、そこら辺が指導者の共産主義でしかない。
逆に、話し合って決めよう、というのが民主主義だが、
実際この手のセンシティブなことに関しては民主主義は全く機能せず、
悪事を「差別ダー」と言い逃れするパヨクと韓国人にやられっぱなしなのは今のリアルの通り。
パヨクなんてそろそろ「俺達が東大に入れないのは差別だ」とか言い出しそうな勢いだろ。
アメリカもポリコレが酷すぎて何だかなあだし、
10年ほど前にはアファーマティブアクション導入の是非について大騒ぎして結局止めたはずだが、
最近確認したら普通に導入されてて驚いた。

747 ：
まあちょっと脱線したが、こういうのを止めて、フォークを導入する。
具体的には、誰をBANするかどうかは各moderatorが自由に出来るようにして、
どのmoderatorの基準が一番妥当かを競わせる。
そして勝ち残った（結果的に一番繁盛した）moderatorの基準が適正だったことになる、というわけだ。
よってシステムとしては、（今のところ考えているのは）
・2ch＋板所有＋フォーク
・reddit＋匿名＋フォーク
・8ch＋フォーク
・qiita＋共有＋匿名＋フォーク
みたいなものになる。なるほど面白そうだと思う奴は参加しろ。いやパクって今すぐ始めろ。
長期的に見てこいつはコミュニティにとって害か、口に苦いだけの良薬か、を適正に判断出来る奴がいれば、
確実に2chより良いコミュニティが形成されていくはずだ。
ただしこれは非常に難しい。だから出来る奴にやらせる為にフォークを導入する。
そして純粋に「良いコミュニティを形成する為の番人」としての腕前を結果で競おう、というわけだ。
そしてこれを経験した人は、コミュニティに対して有害な発言/人間に対する目が磨かれ、
結果的にリアルも変わってくる事を期待している。

今はゴミ投稿しかしてない ﾜｯﾁｮｲ ffab みたいな奴が普通に会話に加われてしまう、これが間違いだ。
そういう投稿をしてきたのなら、それ相応の報いを受けるべきだ。
今のネットにはこれが足りない。
勿論、これまで罵詈雑言、埋め立て、スレ乱立、嘘、流言、とにかくやりたい放題だった連中は大反対で、
当然のように彼等は邪魔をしてくる。
が、それも含めてフォークで決着だ。
「ゆとり」「韓国人」「パヨク」を迷惑だと思っている奴らが多ければ、フォークは成立する。
なるほど、と思う奴は参加しろ。気に入らなければ勿論無視でいい。

748 ：
>>733
なるほどだからお前みたいな「記憶型」の馬鹿には居心地がよく、
そして「思考型」の連中を除外する為にも無駄に技巧に凝るわけだ。
まあお前らとしては正当防衛なんだろう。

俺は「記憶型」はプログラマを辞めた方が幸せになれるからそうしろ、としか思わないが。
どうせ「思考型」のさとりに易々と追い抜かれて馬鹿にされる未来しかないと思うし。

一応言っておくと、C++は「設計」を記述しようとしていて、
castを4つに分けたのは「設計上は別物」だからだ。
お前は一生懸命パターン化して暗記しているのだろうが、
あれはちゃんと「設計」していれば、どれにするか迷うことはない。
その他の物も、一応分離する理由はあるんだよ。
お前にとっては暗記する物が増えて嬉しいのだろうけど、そういう目的ではない。

そしてCは記憶する量がほぼミニマムだから、
「記憶型」の馬鹿には何をすればいいのか分からないから嫌うんだな。
なるほどLinusの言う、
「Cにこだわっているのは、実のところ馬鹿C++er避けだ」というのも当たっている。

OSSの場合は更新出来なければ自動的に死ぬ運命だし、
過度に技巧的で意味不明なら書き直されるかフォークして丸ごと捨てられる。
これによって歯止めがかかっているわけだが、
どうせ書き捨てのお前らの糞コードはデタラメし放題、というわけだ。

既に言ったが、初心者向けのアドバイスとしては、
・まともなサンプルコードから出発しろ
だな。例えば730内のような、大勢の目に付く所とか、
MSDNみたいに記述者の最低限の技量が保証されているところとか。
これらの場合、最低限のコード品質は満たしている。
（というよりOSSと同様、あまりに酷いと書き直されるからだが）
そうすれば、mutexをstaticに取るみたいな意味不明なことは起きないだろうよ。

749 ：
ここはC++スレッドなのでC++のことに関心がない人は基本的に発言禁止。
談話をしたいやつはチャットルームへ行けよお。

750 ：
>>749
荒らし含めて、C++に関心無い奴はいないと思うが。
俺に対する文句なら、以下に行けとしか。
C++相談室 part145
https://mevius.2ch.sc/test/read.cgi/tech/1568362404/

というか韓国人>>733、ちゃんと誘導貼れよ。
お前が望んだことだろ。
結局お前ら韓国人はそうやって文句しか言わず何もしないから駄目なんだよ。
そして蟻、お前に発言権があるとでも思っているのか？
スレについて云々言うなら、少なくとも直近(1-3ヶ月以内程度)に何らかの有効発言があるべきだろ。
お前は半年前のようだが。

751 ：
>>748
俺がC++の進化を奇妙に思うのは、castやconstexprとわざわざ分けてまで開発者の意図を正しく伝わるようにしている一方で、それとは正反対のautoだラムダだと抽象化を促すように進んでいる事だ

まぁ俺はもうここには来ないことにする
俺自身韓国は好きでも嫌いでもないが、お前のような差別発言する人間は、先入観で突っ走って技術を正しく見る知能は持ち合わせてなさそうなんでね

752 ：
そりゃ細かく指定したい場面と、したくない場面を両立させようとしたらそうなる

753 ：
ライブラリを作成する人は細かく指定したいし実際に使う側はそんなこと気にしたくないし...

754 ：
>>751
>>752の言うとおりだと分からないのはお前が馬鹿だからだ。
なお、autoとかラムダは抽象化ではないが。
> まぁ俺はもうここには来ないことにする
最初からそうしろよドアホ。
俺はお前みたいに嘘つきで迷惑行為を行ったのにも関わらず「差別ダー」で逃げる奴にいい加減キレてるんだよ。
これは他のリアルでもそうで、だからトランプでありbrexitなんだよ。
お前らの存在がコミュニティにとって有益か害かはフォークで決着させるべきだ。
分かりやすいと思うがな。
俺はこのスレに居り、本スレには行かない。(これはもうずっと守ってる)
お前はもうこのスレには来ず、本スレに居る。（お前が守ってくれればだが。所詮韓国人、嘘ばかりだからなー）
これでどっちがよりましになるか、勝負だ、ということ。正しい競争だろ。

>>737
お前もみみっちくここにへばりついてないで、751を見習って潔く宣戦布告したらどうだ？
パヨクはそういうところがみっともないから若者にも支持されないんだよ。

755 ：
>>750
このスレが終わったらどうするの？
禁を解かれてまたいろんなスレに躍り出るの？

756 ：
馬鹿が長文書いてる時間、他のマトモなやつはコード書いてんだよ

> どうせ「思考型」のさとりに易々と追い抜かれて馬鹿にされる未来しかないと思うし。

この戯れ言をそっくりそのまま返すぜ

757 ：
パヨク、韓国という口癖から察しがつくのは
煽動に乗りやすい浅はかさだな
聞きかじったことの受け売りは雄弁に語るが
てめー自身の経験で得た知見はないに等しく
妄想とマニュアルトークしか芸がない

> 先入観で突っ走って技術を正しく見る知能は持ち合わせてなさそうなんでね

自己紹介乙

758 ：
共産主義者は２種類いる
悪の天才と騙されるアホだ
どう見ても後者なやつ

759 ：
しかし、OSSにすること自体が競争原理には相容れないと思うんだが。

760 ：
おっさんになると他人の関心お構いなしでく自分の言いたいこと言い散らかすよな
ボケ始めてるんだと思うわ

761 ：
優秀な一目線で見れば、分かり易くて修正し易いコードが、レベルの低い人に
一方的に修正されてフォークされているように見える。
分かり易ければ分かり易いほど修正や機能アップがし易いのでフォークされるだろう。
そして、コードが汚くなった時点で誰も修正が困難になってフォークは終わる。
つまり、良いコードはフォークされまくって、最後に残るのは悪いコード。
名前が売れるのは最後に修正した人。最初に良いコードを書いた人は過去の人となり
埋没していくだろう。

762 ：
全部読んでないが、シングルトンパターンについて意義があるなら原典引いてここにこう書いてあるがそれはどのように間違ってると書いた方が生産的だろう
使用例やstaticじゃダメな理由も書いてあるからそれに対して反論すればいい
Javaでグローバル使う為にとか書いてあるから読んでないんだろうけど
って書くとデザインパターンを盲信している信者扱いされるんだろうなw
いや、韓国人か？w

763 ：
>>761
ただし、一番最初に書いた人は、名前が残っていく傾向がある。
いずれにせよ、1つ言えることは、最も貢献した人が有名になるわけでは
ないだろうということ。もっと根本的な事を言えば、有名になってどうするの、
という点。プログラムなんかで別に有名になりたくない。

764 ：
>>743
＞実際は、「独裁」自体はさほど悪いものではない。
＞「独裁」であればこそ決済は早く、資源を集中投入することも可能だ。
たしかに
今の中共をみていると、成長分野になりふりかまわず資本投下できる独裁国は強い、と思います
中国には「人権」などという「きれいごと」は存在しないので、顔認証をもとにした「社会的従順度スコア」を導入するのにハードルがない
ひたすら統治コストを下げることができる中共中国は、当面伸びていく一方だと思います

765 ：
こんな連中を僅かでも擁護する人間のクズは人類６０億共通の敵だ
https://ameblo.jp/tachiagare-nihonjin/entry-10651665016.html?fbclid=IwAR34neJsrbH-oEqXKGFltM-tL874Ye59jgyKmJl--qleKxuCzCL87NCw7kE

766 ：
>>744
＞そして共産主義は序盤の立ち上がりは早いが、最終的には負けるシステムだ。
なぜ最終的に負けるシステムなのか、という点に興味があります
「言葉の自動機械」「法の奴隷」をキーワードとして、つまり、真心で動いていた層が死に絶えた次世代には損得勘定に長けた打算的な層ばかりが跋扈してしまうところに社会全体が衰退する原因をみます
当初素朴な自然信仰であったユダヤ教が、心を忘れ言葉の自動機械化が進み何事も言葉で定義されずにはいられない無駄な戒律ばかり増強した点を、後にイエスキリストは痛烈に批判していましたね

767 ：
>>745
＞漢字は教育コストが高すぎる面もあるが、それはさておき
いや、これはとても興味深いですよ
漢字は最初はコストが高いのかもしれませんが、高度化あるいは抽象化した概念を量産するのには向いているのではないでしょうか？

768 ：
>>746
＞10年ほど前にはアファーマティブアクション導入について大騒ぎして結局止めた
いいえ、止めてません、1960年代の公民権闘争の結果、その時期からアファーマティブアクションは着々と導入されてきての今があります
たぶん、ここ10年の間に白人比率が低下した結果、アファーマティブアクションは廃止されるのだろうと考えています、そこで米社会は一騒動するのだろうとも
https://www.youtube.com/watch?v=Y_oD0ZWfWz4
https://www.youtube.com/watch?v=eu6nk0s4ltM

769 ：
>>746
＞実際この手のセンシティブなことに関しては民主主義は全く機能せず、
＞悪事を「差別ダー」と言い逃れするパヨクと韓国人にやられっぱなしなのは今のリアルの通り。
たしかに、いまどきのリベラルは退潮しつつありますね
「仲間で平等に分配する」というシステムを仮に立ち上げたとしても、「誰を仲間だとするのか？」「こんな奴は仲間ではない」という議論が沸騰しているのが今の世というところでしょうか

770 ：
しかし、C++関連の質問や話をするスレがなくなっちゃうのも困りもんだな。

771 ：
NGしとけばいいだけ

772 ：
> そして共産主義は序盤の立ち上がりは早いが、最終的には負けるシステムだ。

暴力はその場しのぎで、後で回ってくるツケが法外ということだ
BANだBANだとラリっている低脳がBANという暴力＝麻薬に依存しきった思考回路であることを
共産主義者だと指摘したら図星で自白までしやがった

773 ：
共産主義、資本主義という分類ではなく、競争が起きるかどうかが重要。
独占状態だと競争が起きないので文明や科学の発展にはマイナスとなる。
資本主義でも、もともとが競争の結果でそうなったとしても、後々
結果的に他社や他者の参入が出来なくなってしまえば、競争が生じ
ず、文明の発展の速度は鈍化するだろう。独占禁止法の
「競争回復措置」という言葉が分かり易い。

774 ：
>>773
貧富の差も同様。もともと金持ちや首都圏に生まれた人が圧倒的有利に
なってしまうようでは、偶然に生まれてくる他県の優れた才能が生かせず、
国にとってはマイナスとなろう。

775 ：
>773
共産党が与党の国は一党独裁だ
これがどういう意味か説明する必要はあるまい

776 ：
共産主義 ---> 競争をなくした方が幸せになり、過当競争による無駄も無くなる
　　　　　　　と考えた思想。結局失敗。

資本主義の独占状態 ---> その企業がそこまでになったのは競争の結果であった
　　　　　　　　　　　　としても、結果的に競争が生じない状態になりがち。
　　　　　　　　　　　　将来もっと良い製品を作るかも知れない他の幼い芽さえも
　　　　　　　　　　　　積んでしまうので、別の可能性の出現は全く起きなくなる。

777 ：
GAFAが有史以前から存在していたと思っているガキかｗ

778 ：
>>773
＞競争が起きるかどうかが重要。
intel と AMD の舐めプレイ競争を見ても、つくづくそう思いますね…もうすぐ32コア？64コア？

779 ：
それぞれapiとして用意している二つの関数があって、そこで値を共有したい
apiの使い方はa関数をよんでbのために値を設定して、その後にb関数を呼ぶみたいな感じ

引数として渡すとインターフェースを変えることになるからできない
二つの関数は同じファイルに記述しているからグローバル変数で値を渡そうとしているのだけど、
それ以外に方法ある？？


namespace test
｛
static int test
｝

void a（）
｛｝

void b（）
｛｝

一応、staticで有効範囲をこのファイルに限定して、名前空間で使われ方を限定はしようとしてるんだけど...

780 ：
スレッドローカルって手はある
この場合に適するかどうかはさておき

781 ：
よく読んでないけど無名名前空間はどう？

782 ：
>>779
いくつか方法があるが、そのような目的では通常、namespace は使ってはいけない。

方法1：それらの関数を、あるクラスのメンバ関数にする。受け渡しのデータの型は、
　　　　関数宣言などの「インターフェース」には影響しなくできる。

方法2: struct TInfo {・・・}; というような構造体を宣言し、その中に、見せたくないデータを入れておき、
　　　 void a( TInfo *pInfo ); void b( TInfo *pInfo ); とする。TInfo は、

struct TInfo {
　DWORD　m_type;　// 種類を区別する何らかの数値。
　union {
　　TYPE1　m_dat1;
　　TYPE2　m_dat2;
　　TYPE3　m_dat3;
　}
};
のようにして、m_type の値に応じて、union 型のどのデータを使うかを場合分けする。
TYPE1, ・・・, TYPE3 は、通常、何らかの struct 型にし、好きなデータをそこに入れる。

783 ：
>>782
方法3: TInfo を直接使わずに、struct TBase {・・・} としておき、
void a( TBase *pInfo ); void b( TBase *pInfo ); とし、
struct TInfo1 : public TBase {・・・};
struct TInfo2 : public TBase {・・・};
struct TInfo3 : public TBase {・・・};
とする。やりたいことに応じて、TInfo1〜TInfo3の好きなものを使う。
なお、方法1は、説明不足だったが、こうする：
class CBase {
public :
　void a();
　void b();
};
class CDerive1 : public CBase {
protected :
　TYPE1　m_type1;　　// 好きなだけの個数のメンバを書いても良い。
public :
　void a();
　void b();
};
class CDerive2 : public CBase {
protected :
　TYPE2　m_type2;　　// 好きなだけの個数のメンバを書いても良い。
public :
　void a();
　void b();
};

784 ：
>>782
インターフェースを変えられない（＝呼び出し側を変更できない）んだから両方駄目だろ

785 ：
>>784
関数、a, b のインターフェースは変わってない。

786 ：
>>785
a, bをクラスに入れたら呼び出し方法が変わる
インターフェースを変えてはいけないのに呼び出し方法を変えても構わないというのはおかしい

787 ：
質問者がa(), b()以外から変数testが書き換えられる可能性を危惧しているのなら、
privateにコンストラクタとtestを持ち、a()とb()をfriend関数として持つクラスを作ればいい

class testClass
｛
testClass();
static inline int test = 0;
friend void a();
friend void b();
｝

788 ：
そういう話であれば、そもそも最初の質問の意味が分からない。
何がしたいのかが。

789 ：
32bitでコンパイルされたdllを64bitのプログラムから使用する方法ありますか？

790 ：
>>789
それらのDLLを読み込む32-bitのexeをShellExecuteで呼び出す。

791 ：
実はレジストリも違う場所に描き込まれるよね

792 ：
>>788
何をしたいのかは明らかだろ
メンバ関数にしてインタフェース変わってないとかお前の方が意味不明な

793 ：
>>755
追加の宣言を促す気なら、お前がまず何か宣言するべきだ。
これは俺に文句を言っているその他全員もだ。
俺はもう既に宣言済みで、それをこれまで守っているのだから。

単なる質問なら、それはそういう言葉で行うべきではない。
おまえら「ゆとり」はクズだからネット上ではいくらでも挑発していいと思っているようだが、それも間違いだ。
俺は勝手に宣言して勝手に守っているだけであって、お前らクズ「ゆとり」に禁をかけられているわけではない。
また、今尋ねることも適切ではない。
このスレを使い切るのに後何年かかるか分からないのだから。
（本来はあと2年ほどかかる予定だったし、今お前らが黙れば後1年は持つと思うぜ。実際俺が放置したら停止したろ）

そもそもお前がそれを心配するのなら、お前が今為すべき事はここに何も書き込まないことだ。
それは>>725もそうだが、どうにもお前ら「ゆとり」はクズ過ぎて駄目だ。
>>733,751とこの馬鹿自身が書き込むことによって、725を自ら無効化してしまっている。
結果、一番無駄なレスは725だ。
725は結局、自分に都合の悪いレスを止めて欲しいだけで、自分は文句を言いたい放題という、
いつも通りのパヨク的ダブスタに過ぎない。
他人に口をつぐむように指図するなら、その本人は最低限それを守るべきだ。
韓国人はこの辺の筋が通じないから駄目であり、結果、韓国人が居るだけで荒れる。
だから韓国人の存在自体がコミュニティにとって害だ、ということになる。
これが妥当か勘違いかを、フォークで決着付けてやる、ということだ。

いい加減、お前らがおもしろがっていたこと(>>705)を大迷惑だと思っていた連中も多いと気づけ。
だから「ゆとり」は殺さないといけない。
とは言っても物理的にRわけにも行かないので、ネット上でフォークして勝負だ。

794 ：
ちなみにお前ら、「殺人」が何故いけないのか考えたことがあるか？
俺はそれは「取り返しがつかないから」だと考えている。
逆に言えば、ネット上の殺人(＝BAN)は取り返しが付くのだから全く躊躇する必要がないとも考えている。
そして俺が「韓国人だから」という理由でBANを発行したとして、それに抗議するのは、
パヨクのように「人権ガー」「差別ガー」ではなく、
「韓国人が居ることによってより上手く回る」掲示板を運営し、そこを繁盛させることにより、
「韓国人だから」みたいな『ふざけた』理由でBANを発行する掲示板を過疎らせてRことによって行うべきだ。
実際、これは理論的には可能だ。多様性自体は上手く使えれば確かに善だ。
ただ、それには相応のコストが必要で、まずは最低限、悪事を「差別ダー」と言い逃れするクズ共をたたき出す必要がある。
そしてその先にも有形無形の様々なコストが必要で、今の日本のお花畑達はまるでこれが分かってない。
アメリカは確かに移民の恩恵を受けているが、それがタダだと思うのは完全に間違いだ。

ただ、本当にここら辺のことをふまえた上で実行され、それが機能するのなら、俺が運営する掲示板は滅ぼされることになる。
その時は、役割を終えた、ということでいい。
「韓国人」はR、というのが気に入らないのなら、やってみればいい。
俺が掲示板を用意するのにはあと数年かかる。
それ以前にお前らが機能させられれば、最初から俺の掲示板なんてゴミであり誰も見向きもしない。
お前らにこれが出来ればお前らの完全勝利だ。やってみろ。

795 ：
ちなみにお前らがこういう考えに至らず、文句を言って相手を潰そうとするのは、お前ら自身が共産主義的だからだ。
資本主義的なら、相手を凌駕することにより相手を滅ぼすのが正しい戦い方だ。
「差別ダー」と政治的に喚き散らし、お取りつぶしを願うことではない。
結果、共産主義では「指導者が正しいと認めた物」しか出てこないから発展せず、
資本主義はどんどん「相手を凌駕した物」が出てきて社会もその恩恵を受けられるからじりじりと前進していく。
これが共産主義が滅んだ最大の理由だ。最初から最終的に勝てるフォーマットではなかったんだよ。

だから、俺の見解を「差別ダー」と思うのなら、
「差別のない掲示板」をお前自身が運営して「差別のある」掲示板を滅ぼすことだ。
ただ、俺はお花畑なお前らにはそれは出来ないと見ている。
誰であれ「荒らし」であればBANしていく、という方針がもっとも差別がないと俺は思うが、お前らはそうではないようだし。

796 ：
ところで「向いている/向いていない」について良いスレを見つけた。
俺の文は読めないというのなら、以下でも読んでみてはどうか。
内容はまあまあだと思う。
（以下2つは同じ物）
http://boards.4channel.org/g/thread/73285994
https://archive.rebeccablacktech.com/g/thread/73285994/

797 ：
> パヨクのように「人権ガー」「差別ガー」

ブサヨが難癖つけるときのボキャ貧ワードだろうが
てめえらがしたことを他人に擦り付けるいつものワンパターンまたやってやがる
マジRよ腐れアカ

798 ：
>>793-796
3行にまとめてくれたまえ。

799 ：
>>511
>classのかわりにstructと書いたらむしろ1文字多いのだが
structのかわりにclassと書いたら1文字減るじゃん？

800 ：
>>583
問題ある
シングルトンの中身がわかったらﾜｶﾙ

801 ：
>>600
ジャヴァで動かないわけではない
安全にならないだけ

802 ：
訂正
バカ正直にsynchronizedしたシングルトンはジャヴァでも安全に動く
安全にならないのはdouble-checked lockingした場合

803 ：
現状のアーキテクチャはそもそものラムダ計算つまり再帰とはもっとも相性が悪い
スタックマシンや有限メモリでは関数型の再現は無理がある
そこをだましだまし使っているだけで、本当はとっても相性が悪い

804 ：
>>803
お前の頭はプログラミングとはもっとも相性が悪い
文系脳には無理がある
そこをだましだまし使っているだけで、本当はとっても相性が悪い


quoraにもあったわ(なお日本語版にはいいのがなかった)
https://www.quora.com/Is-it-true-that-programming-is-not-for-everyone
内容は>>796と同じだけど、つまりは同じ事を実感している人が多い事実は認識した方がいい
努力以前に適性の問題が大きい
プログラミングは無理してやるようなことではないし、今現在のC/C++はプロ以外が使う意味はない

新人みたいに絶対的に知識/修練時間が足りていないのならばさておき、
そうではなく、十分な練度のベテランのつもりで、
今現在のソフトウェア界隈の動きが全く理解不能なのであれば、
それはお前は全く向いてないことを意味する
多くの人がよってたかって改善しようとしている状況で、訳の分からない方向に行くことはほぼ無い
それはこれまでも、また、これからも、同じだ

805 ：
適正が有る無しは何処の分野でも同じ
今はソフトウェアが多く求められているのに
それを充足できていない事が問題
それなのに適正がー
とか言ってては何の解決にもならない
ライト層からヘビー層まで色々必要なんだから
別に適正がなくても訓練が出来ていればその人たちにライト系を作ってもらえば良い
今はどうやってソフトウェアの生産を増やすか?
その為の基礎教育や教科手順何かが求められている
問題はそういう教科書的な物で良い物が無い事だ
上に有る様な質問が出ても照会する本もたいして無く
ただ色々やってみろ
みたいな話にしかならない
努力と根性みたいな話しか出てこない
下層が弱くて薄い
それを強化しないといけないという問題認識が無さ過ぎる
まぁc++はライト層とは別分野だと思うけど
何の対策も提案も無く排除ばかりしようとするのは社会的に問題有りだ

806 ：
>>805
ならお前がまず解決策を出せよ
お前には出来ないと思うが

お前は英語も出来ないということは分かった
quoraのトップの意見に全くそれについて書いてあるだろうに
文系の馬鹿共にどれだけ高校物理を教えても時間の無駄にしかなってないのは今でも事実だろ
プログラミングはおそらくもっと酷いことになる
お前こそ精神論過ぎる

807 ：
ただ、俺はお前の言う問題は認識してないがな
俺は「無能はプログラミングすべきではない」と考えているし、義務教育化にも反対だ
そして排除自体はこのスレおよび話し相手としてだ
つまり俺の前から消えろ、でしかない
当たり前だが俺はお前ら馬鹿がプログラミングするのを止めることは出来ない
ただ、アドバイスするなら、お前らにも適性がある分野があるはずだから、そこを目指せ、となる
文系なのにSEなんかにされているのなら、
お前も、また、お前みたいな馬鹿と一緒にやらされる周りも、被害者だよ

プログラミングについても、以下は当てはまると思うぜ
一撃必殺！急にマンガ家だの声優だの絵師だのになりたいと言い出した子どもや大人を止める、オススメの方法
https://togetter.com/li/1130025
家庭にPCが当たり前にあり、個人レベルでスマホを持っていて、高性能なIDEも無料で手に入り、
ググればいくらでもサンプルコードが出てくる今、
自分で開始/対処出来てない時点で適性がないんだよ
才能さえ有れば、努力さえすれば、と思っている馬鹿が多すぎる
それなりに才能有るやつが努力し続けることを強制される世界なのだから、
努力を続けられる「適性」が最も重要で、それがないと根本的に無理なんだよ

というわけで話は終わりでいいか？
お互いこれ以上得る物はないと思うし
反論なら、quoraや4chanの意見を確実に読んだと分かるように書いてくれ
俺はお前と話すのは無駄だと認識したから、お前の意見については無視したい
ただ、お前が4chanやquoraの『大勢の』意見について賛同する部分があるのなら、
それが分かるように明記してくれれば、必要有れば反論することにする
俺は既に言った通り、4chanやquoraの『大勢の』意見には賛同している
だからまあ、可能で有れば、俺に反論する必要もなく、
お前が勝手に4chanやquoraに行って叩かれてくれるのが一番助かるが

808 ：
糞使えなかった do-while 文だが、最近使えそうなところに遭遇した。
が、結局スコープの問題で使えなかった。コード構成は以下と同じ。

do {
Type value(GetCurrentValue());
Process(value);
} while (condition(value));
// https://stackoverflow.com/questions/13297243/why-is-whiles-condition-outside-the-do-while-scope

ここで上記の筆者も言っているが、do-whileのスコープって使えないよな？（設計としてよくない）
そこで他言語でこのスコープが直っている物を知らないか？
最有力としてはC#だが、試したが駄目だった。
（スコープはCと同様、そしてdo-while自体がレア　https://ufcpp.net/blog/2016/12/tipsdowhile/ )
Rustは do-while ループを廃止したらしい。Goはwhile文自体を廃止している。

言語設計としての一貫性は重要として、
for文がスコープを拡張しているのに、do-whileがスコープを拡張してないのは間違いのように思う。
というか、do-whileが使えないのってこのスコープ設計が間違っているからであり、
正しくスコープが拡張されていれば有効性はあったように思うが、どうか？
while (true) { if ... break;} より1行短く書けるメリットもあるが、
それ自体ではなくく、その形式のループを全部do-whileにすることにより可読性が上がる。
違う言い方をすれば、 while ループでの頻出形式を for に纏めたのと同じく、
必ず一度は実行し最後に break する形式の while ループを全て do-while にすることにより識別しやすくなる。

もっとも、JaveScriptに慣れた状況だと、最早ブロックスコープイラネとも思えてきたが。
ブロックスコープだとどうしてもこういう状況等で宣言型（変数の宣言と同時に常に初期値を代入し、必要なければ再代入をしない）で書けない。
関数スコープの問題は関数を小さくすることによりほぼ回避出来るので。
(JavaScriptは全ての関数がクロージャを持つので、C言語でのループは常に関数内関数としてそのまま切り出せる）

809 ：
do-whileマクロで必須だろ

810 ：
使えないなら使わなければいい
すべてを使う必要もなければ、すべての仕様が有用である必要もない
C++にはC言語への後方互換性のためだけに残しているものは多い

811 ：
ループの先頭から入って
ループの後ろで条件判断するコードが
動作的に一番無駄が少ない

だから do while が存在する

コンパイラの最適化も糞でCPUも遅くメモリも少ない時代に出来た言語

1回以上通る事がわかっているループは
do whilw の方が良い
コンパイラが1回以上通る事がわからないと
無駄なジャンプ命令が増えるので

812 ：
do (int i = 0){

} while (i < size);

こんな書き方が出来れば良かった

813 ：
読みやすいfor文がええわ。

814 ：
読みやすさよりも1バイトでも短く
1サイクルでも速く

な時代の話

815 ：
for (int i = 0 ; ; ){

if (i < size) continue;
break;
}

う〜ん...

816 ：
>>821
見やすさなら従来通りの do-while がいい。問題はスコープなだけで。

do {
bool flag = ...
} while (flag);

頭でflagを確定させられる場合は、これはいわゆる従来記法

while ((line = sr->Readline())!=nullptr) {
...
}

とほぼ等価になる。が、（本来の）今風なのは上側の do-while だと思う。
なおfor文で do-while はGoがやっていて、

for (bool flag=true; flag; flag = update_flag()) {

}

の構成らしい。ただこれは見る限り駄目だろ。


ただし確かに実行コードとしては、頭の条件判定が抜けるだけでしかない。
以下を見れば一瞬で「絶対に一度は入る」とは分かるから、
コンパイラが最適化してくれるのなら、行数が１行増えること以外には問題はない。
が、俺はこの１行にもこだわりたいんだが。

while (1) {
...
if (condition) break;
}

817 ：
while (1) が見やすいよ。
かっこよさはさておき。

818 ：
>>817
現実的には俺もそうしている。

ただ、最近は、「こう書ければな」と考えながら書くのが重要なのだと思うようになった。
少なくとも、DI(Dependency Injection)とかの問題は自然と回避出来る。
そこでコードを見てて、ふと思ったわけだ。
この if 文、do-whileのスコープが正しければ削除出来るよなと。

ただ、他言語も特に対応していない状況であれば、今現在は
コンパイラに任せて、ユーザーはど定番の記述を書け、ということなのだろう。

819 ：
>>816
その、｢スコープの問題｣が大きいの
見やすさが大きく影響するので

820 ：
>>811と同じ理由で

while (1){
}
よりも

do {
} while (1);
のほうが良いバイナリになる事がある

糞コンパイラの場合

821 ：
最近のコンパイラは最適化を指示するまでは
いらんことしなくなってきてるね

822 ：
ステップ実行出来ないと困るから

823 ：
>>819
結局お前の意見は何なんだ？


俺の意見は、「do-whileはforと同様にスコープを{}の外まで拡張すべきだった」というものだ。
つまり、再記するが以下の書き方が出来るのが『正しい言語』と考える。

do {
bool flag = ...
} while (flag);

現行のC言語では、for文以外はスコープを {} 内に物理的に配置したものに限定しており、
for文だけ例外的に ()までスコープを拡張している。
C++17でif文とswitch文も拡張された。
https://cpprefjp.github.io/lang/cpp17/selection_statements_with_initializer.html
なら何故 do-while もそうしなかったのか？という話だ。
俺はC++23に期待するが。

824 ：
do-while使ってる人が少ないからじゃね

825 ：
>>823
期待するけど提案するつもりは無いのでしょう？
そんなことを思いつく人は一人ではないだろうけど実際に提案はされないから、そんなことは起こらないんだよ。

826 ：
提案は>>812に書いたけど

827 ：
それを今の文法で書くと
>>815になる

828 ：
別に頻繁に使うこともないんで
そう書きゃ良いだけなんだけど

829 ：
そこでマクロ定義ですよ。

830 ：
>>824,825
なるほど、提案しろと言うのはごもっともだ。
しかし俺は仕様を提案するほどには仕様に詳しくないからパスだな。
そして確かに同様の人が多いというのは認める。


>>829
それは俺も以前考えた。
Cのマクロはそこでしかパース出来ないので、前に出す事が出来ず、限界がある。
（例えばdo-whileブロック内のflag宣言をwhileよりも前に出すことができない）
そしてそれでも無理矢理やるならいっそのことPython等での自前パーサを先に通すほうがまし、という結論に達した。
そして一部それを既にやっている。
(俺は使ってないが）何だかんだでmakefileが融通が利くのはこういう点でもある。
そして自前パーサで全く別のように見える記述になってきたら、新言語の完成、というわけだ。
C++も同様だったと聞いているし。

831 ：
switch(hoge){
case HAGE: do{}while(0); break;
case FUGA: do{}while(0); break;
default: do{}while(0); break;
}
マクロにするとスコープ問題も解決するしbreak書き忘れも無くなる

832 ：
>>830
QTもその延長にある希ガス

833 ：
int a = 0;
do {
int a = 1;
} while (a);

このコードの挙動が変わってしまうから直せないと思う

834 ：
>>830
マジレスされるとは思わなかったけど例えばこんなのとか。C FAQでヤメロと言われてるような。

#define SCOPED_DO(VARS) for(;;) { VARS;
#define SCOPED_WHILE(COND) if(COND) continue; break;}

SCOPED_DO(int i;)
:
SCOPED_WHILE(i<10);

835 ：
ああ、確かにやめた方が良い

836 ：
>>831
すまんがそのコードの意味はよく分からない。


>>834
それはマクロにすることが目的で、見やすいコードを書こうとしていないので、
FAQでなくても止めろと言われて当然だ。
マクロも当然ながら見てすぐ分からないといけない。
この意味ではlinuxのコードが参考になるだろう。
小文字マクロが大量に使われていて、それでも何とかなってる。
逆に言えば、小文字マクロ＝関数だと勘違いしても問題ない範囲で使え、ということだ。
どう変換されるかぱっと分からないマクロは逆に読みづらくなる。

ただまあ、ifとswitchの取り扱いからすると、
C: for文が例外で、他は{}がスコープ
C++: do-while文が例外で、スコープを開始出来るキーワード(for/switch/if)ではキーワード部分までスコープに含める
という状況なので、do-whileのスコープも拡張されるのは時間の問題だとも思うが。

837 ：
みんなわかってることを長々書く人
do-whileもかなりどうでもいい
気分だけの問題でそんなとこで困ったこと一度もない

838 ：
>>837
ゆとりR

> みんなわかってることを長々書く人
何度も言っているが、お前らゆとりが駄目なのはそういうところだ。
ここで話すのに「俺の人格」なんて全く関係ないし、実際今のところ気にしてた奴なんていないだろ。
お前以外は全員、技術面にフォーカス出来ている。

ゆとりが駄目なのは、結局、こうやって場を一々ぶち壊していくことだ。
結果、ゆとりゴキブリが一匹でも入り込める場は全部ぶち壊されていく。
その結果、ゆとり自身の居場所が無くなっているというのが、現在のお前らを取り巻く状況だ。

お前らゆとりはネット上では何を言ってもいい、何をやってもいいと勘違いしている。
そうじゃない。
自由に意見は言っていいが、コミュニティに対する破壊活動は許容されない。
そしてお前らは何がそれに該当するのかさっぱり理解出来ていない。
しかしお前らはネット慣れしていると勘違いしているからかそれを認めることすら出来ない。
お前らは本当に救いようがない。

おそらくはネットが出現することによって、リアルが希薄になり、
結果、リアルでのコミュニティ（人間関係）を構築することが不得手になっている。
しかしそれは当然ネット上にも適用/応用出来るものであり、結果、ゆとりはコミュ障となっている。
ところがゆとりは誰かがネット上で形成したコミュニティにただ乗りして来れているから、その問題にも気づけない。
それが「コミュ力」とか言われた問題の本質だよ。
それ以前の世代では否応なしに必要とされた最低限の「コミュ力」がゆとりにはない。
（ただしこの意味ではコミュ障害でも生きていける社会に改善された、と考えることも出来るが）

お前の発言によって、コミュニティがどう動くか、少しは考えてから物を言え。
そうじゃないからお前らゆとりはお前ら自身で形成したコミュニティを持てないんだよ。
それにすら気づけないのだろうけど。

839 ：
くっさ

840 ：
>>808
言いたいことはわかる
do {} 内のスコープを後に続く while() の条件式にまで拡張すればいいだけだからそんなに無理なくできそうな気がするんだけどね

841 ：
>>840
StackOverflowの質問の筆者もそうだが、技術的にはやれば出来る程度の問題のはず。
あとは言語としての一貫性(＝{}をスコープとする)をどこまで厳密に適用するかだ。
ただ俺はこれがおかしな仕様のまま残されていることが奇妙だと思っている。
Cはほぼ変化する気がないからともかくとして、
Cの駄目なところを改善している他の新しい言語(C#等）でもそのままなのに驚いた。
ただ、ifやswitchまで拡張されたのなら、whileもそうだな。

現行
String^ line;
while ((line = sr->Readline())!=nullptr) {
...
}

次？（もしかして今ももう出来る？)
while ((String^ line = sr->Readline())!=nullptr) {
...
}

駄目だ駄目だと言われている条件式内での代入も、カンマ演算子も、上手く使えば美しく書けることに気づいた。
そして駄目だと言われているのは「白黒端末」前提であり、実は
「条件式内で代入演算子を用いた場合、太字にする」とかIDEのサポートがあれば問題ない気がしてきている。
つまりは、見た目気づきにくいから駄目なだけであって、見りゃ分かる、なら問題ないからだ。
だからコーディングルールもカラー端末大画面前提でのルールに変えていくべきなんだよな、とも。

842 ：
{do{}while(cond);}

843 ：
>>837
ID:x6gTDhtk0は、ほぼ確実にMIPS君だろｗ
＞自由に意見は言っていいが、コミュニティに対する破壊活動は許容されない。
＞そしてお前らは何がそれに該当するのかさっぱり理解出来ていない。
＞お前の発言によって、コミュニティがどう動くか、少しは考えてから物を言え。
この前キャリーフラグに関する間違い指摘されたら、100レス以上暴れたのはどこのどいつだよｗ

844 ：
>>843
ゆとりR

というか、ゆとりは認めないが、ゆとりの識別能力は恐ろしく低い。
単に「長文である」とか、そういう外面的な情報しか見えてないからだ。
結局これは、いわゆる「コミュ能力」が低いからであって、つまりは相手が見えてないからだ。
当たり前だがネット上でも相手は人間、リアルのコミュ能力が低ければネットでも低くなる。
（ただしリアルとはチューニングがかなり異なるので、
リアルでコミュ力高くてもネット慣れもしてないとちぐはぐな対応になってしまうが）
「空気読め」というのも、逆に言えば、
それまでの奴らは「空気読め」と言われるほど酷い発言/行動はしなかったんだよ。
良いか悪いかはさておき、「○○さんに対してそれはねーわ」が完全に共有されてた。
（ただしこれは本当に悪い側面も持つので、これ自体が破壊されたのは悪くはないかもしれない）
それをゆとりが出てきたおかげで、「空気読め」と言われだした。
そして雰囲気だけで無理強いする奴がそれを濫用し始めておかしな事になってるのが今だ。

お前らはその識別能力の低さを自覚した方がいい。
ゆとり以前の世代はこの自覚があるから、ゆとりレベルでトンチンカンな発言はしない。
俺はその話は知らないし、本来は一々否定することも面倒だからしないが、
いい加減ゆとりにはうんざりしているので、
「どうしてゆとりを排除しなければならないか」を蕩々と述べ、認識を共有することをまず始めることにした。
現状はそこから始めないと駄目だ、というのが俺の認識だ。
どれだけ新しいスレを作っても、良くなってきたらゆとりに破壊されるのを既に何度も繰り返してきたからだ。

ただ、おそらく、ネットを「正しく使える奴」と「間違った使い方しか出来ない奴」に強烈に分化しているのが現状だと思う。
「間違った使い方しか出来てない」奴は、本当によく考えた方がいい。
そして「『間違った使い方しか出来てない』奴（≒」ゆとり）はコミュニティに不要」と
認識を共有した者同士で脱皮しようと言うわけだ。これは既に述べたとおり。

ゆとりは俺を気に入らないようだが、実際、ここに投稿してもすぐにレスが付くだろ。
それは、お前とは違って、「まだこのスレも読む価値がある」と認めている奴も多い、ってことなんだよ。

845 ：
相手に伝えたいことを簡潔に表現する能力がない無能なんだから許してやれよw

846 ：
これだから老害はダメ。

847 ：
https://eigo-box.jp/others/jokes/#idiot
これを地で行くやつｗ

848 ：
しくった
https://eigo-box.jp/others/jokes/#9_idiot

849 ：
>>845-848
ゆとりR

一行しか理解出来ないゆとりにはこれがもっとも適切な表現だ。
常に最初に書いて置いたその意味もお前らには理解出来なかったようだが。

850 ：
鬱積したもんがあるんだろうね
ここに渾身の長文書いたら皆が読んで敵は打ちひしがれ、味方は共感してくれると思ってるところが
こいつのかわいいところであり、哀れであるところ

851 ：
>>850
ｗｗｗ

852 ：
>>850-851
ゆとりR

お前らにとって理解不能でも、意味があることはあるんだよ。
何故お前らゆとりがそこまで傲慢なのか俺には分からないが。

853 ：
その「意味があること」とやらを、おまえさんは伝えたいのか？
伝えたいのに伝わらないという問題に直面したとき
どうすれば伝わるか考えるという科学はしているのか？

854 ：
>>852
相手がゆとり世代かどうかも分からないのにそう決めつけたり、ゆとり世代というレッテルで一括りにしたり、非論理的な主張をするお前も無能だろう

855 ：
>>853-854
ゆとりR

そう思うならそれでいい。
俺の文がお前ら宛だと思っているのはお前らの勘違いでしかない。
俺は今ここを読んでいるが特に文句を言ってない連中、或いは将来的にここを読む奴宛に書いている。
彼等がどう思うかだよ。

ワッチョイ確認すれば分かるが、
実際、今回技術面にフォーカスしてきちんと議論出来ている人は、誰一人として文句を言ってないだろ。
一方、お前らゆとりは文句しか言ってない。
これが、既に言った、「正しく使える奴」と「間違った使い方しか出来ない奴」(≒ゆとり）の差だよ。

本来、コミュニティに対して生産的でない奴には発言権もないべきなんだよ。
それはリアルでは当然そうなっていて、会社で無能に発言権がないのもこれでしかない。
ところがネットではゆとりみたいなクズでもどのコミュニティに対しても自由に参加出来るものだから、
お前らゆとりはそういうものだと勘違いしてしまっている。
結果、お前らゆとり自体が本質的にクズ人間集団のように以前の世代から見たら思えてしまう。
これがゆとり問題の根元だよ。
そして問題は、このことを、お前らゆとりも、また、以前の世代も、意識出来ていないことだ。

ここがC++技術のスレなら、最低限、C++技術に関しての発言をする/した奴にしか発言権はない。
俺に文句を言う前に、お前らが何らかの「スレを盛り上げる為のC++技術論」を展開して、
コミュニティに対して生産的に寄与してからでないと、発言権はないんだ。
これは本当に当たり前のことなんだよ。
（というか、そうしないとコミュニティが崩壊して存続出来ないから、
存在しているコミュニティは本質的にそういうものとなる）
ゆとりでも分かるように言えば、リアルでシカトされるような行動/発言はネットでも慎むべきなんだよ。
まあもっとも、お前らゆとりはリアルでも「ないわ〜」な行動をしてブッ叩かれていたわけだが。

再度言うが、文句を言う前に何か他人を巻き込んで盛り上がるC++技術論を展開しろ。
そして俺にマウント取りたいのならC++技術論で来い。

856 ：
箇条書きできない人ってそんなに珍しくないと思うよ

857 ：
>>856
違うぞ。俺は単に言いたいことが多いだけだ。
それは見えている物がお前らより多いからだ。

そしてそれは既に言ったが「知識のネットワーク化」により、全部関連してるからだ。
何度も繰り返したように、これは見えた展開でしかない。
お前らはどうやら無限にこれを繰り返す気らしいが、俺はもうそろそろ終止符を打ちたいので、
俺の思想を開示し、賛同者を募っている。

プログラミングもそうだが、こういった展開も実は抽象化出来る。
お前らは文系脳だからそういう感覚すらないようだが。
今やっていることは「海と山が近い町での漁師と農民の喧嘩」でしかなく、リアルでも1000年以上繰り返してきてる。
それをお前ら文系は別々のこととして暗記するから駄目なんだ。
まあもういいが。

858 ：
>>856
ゆとりR

言い忘れてたので言っとく。
>>720が俺が箇条書きしたものだ。
ゆとり馬鹿以外に箇条書き出来ない奴がいると思っているのはゆとりすぎる。

859 ：
科学しねえサルであることはわかった
あばよエテ公

860 ：
そのための隔離スレ

861 ：
円周率はなぜπなのですか

862 ：
>>860
隔離スレから出てこないところだけは評価してもよいと思う。

863 ：
>>833 の指摘が簡潔で十分に説得的だと思う。

C++の人は何故こんなに互いに罵り合うのだろう。
それも技術的な妥当性などより先に人格や経歴を否定するような表現を使って。

864 ：
>>863
>>833については広義に捕らえればifやswitchでも発生することだし、
それ以前にC++は駄目な仕様は互換性が無くなっても改善して行ってる。
一応はいまだに「完璧な言語」を目指している。


> C++の人は何故こんなに互いに罵り合うのだろう。
C++だけの問題ではないと思うが、お前の言う「罵りあってない言語スレ」ってどこよ？
あと、揚げ足取り気味だが、
> 経歴を否定
してる奴は俺含めて誰も居ないと思うが？

865 ：
仕様変えろって言ってたのは do ~ while の話なのになんで if や switch が関係ある？
なにか話が通じてないっぽい。

866 ：
>>865
話が通じてないのはお前だ馬鹿タレ。

スコープの拡張によってdo-whileは従来コードと動作が変わってしまうので採用出来ない、というのなら、
if文もスコープの拡張によって従来コードとは動作が変わってしまっているし、switch文もそうだ。
だから、do-while文が従来コードと動作が変わってしまうから仕様の変更が出来ない、ということはない。

つか、お前ら馬鹿には短く書いたら通じないのに、
一々お前ら馬鹿にも分かるように説明してやると長いと文句を言うという。
だからお前らとはコミュニヶーション無理なんだよ。

867 ：
今あるdo whileの挙動が変わるような仕様に変える事なんて出来ないよ

仕様追加なら>>812が良い
ループ変数もローカルで定義出来る

868 ：
>>867
812は使えない。

（そもそもほぼ使われてないというのはさておき）
・do-whileの場合は、最初に条件変数を確定させることが出来ない場合が多い
・宣言だけdo内で出来ても余計に見にくくなるだけ、それなら{}内でいい

ただしifやswitchのように「変数スコープを汚さない」為ならこの仕様でもいい。
だから俺は賛成はしないが、実際に提案したら通るかもしれない、とは思う。
なお本来こういうのはRsustの出番だが、
今見たところRustもwhileのスコープはCと同様のようだ。
https://doc.rust-jp.rs/the-rust-programming-language-ja/1.6/book/loops.html

869 ：
>>817
私は for(;;) { }
を愛用しています

870 ：
>>868
for と比べても一貫性があるし
過去コードにも影響を与えない

より良い案があるなら書いてみれば？

871 ：
>>817
意味的には
while (TRUE)
なんだけど
なぜかみんな1だよね

1の方が楽だから？
それともTRUEが定義されてないことまで考えて？

既に定型文だからこのままで良いけど

872 ：
#define ever (;;)

for ever {
}

こんなネタがあった

873 ：
クサチューのオンパレード

874 ：
>>871
TRUE は自分で定義しないといけない分、面倒くさいですから
for(;;) { } ならそれも必要ないのでお得ですよ

875 ：
ここC++スレだよな？　（極度の脱力）

876 ：
キチガイの隔離スレですよ

877 ：
C++スレであることを忘れてた
while (true)
while (1)
for (;;)
do while (1)
do while (true)

forが一番文字数が少ないけど...
while (1) を一番良く見る

878 ：
>>870
既に816に書いたし、元のstackoverflowとの例とも同じだが、再記すると、

do {
bool flag = ...
} while (flag);

要するに while () までスコープを拡大しろ、というだけ。
これ自体もfor文とは整合性が取れている。敢えてスコープを [ ] で示すと、

[ for (int i=0; i<num; i++) { ... } ]
[ do { ... } while ( ... ) ]
[ while ((String^ line = sr->Readline())!=nullptr) { ... } ]

要するに全部外側まで含めろ、でしかない。
これは既に記したC++リファレンスでも言ってるだろ。
> 見方を変えるとfor文で可能な初期化が、なぜかif文やswitch文ではできない、文法に一貫性がない問題と見ることもできる。
> https://cpprefjp.github.io/lang/cpp17/selection_statements_with_initializer.html
ならdo-whileとwhileでもやらせろ、というだけの話。

ただしこれに関しては合意する必要がないので、ここまででいい。
俺はこれが最善だと思うし、君は816が最善だと思っているだけ。
提案するならどうぞ。俺は君の案が最善だとは思わないから協力はしない。
ただ、仕様委員会が君の提案を最善だと思うのなら、通るだろうし、その可能性もあると思う。
どちらがいいかなんて俺と君で詰める必要はないし、その意味もない。
（というのを868で言ったつもり)

879 ：
>>868
過去のコードが動かなくなるのはダメだ
って言ってるのに

880 ：
while (★::flag)

互換性を保つならこんなんだろうげど
★にたいする適切な物が思い浮かばない
予約語を増やすか演算子を増やすかくらい
直近の変数がデフォにならないのも違和感

そもそもループ変数のスコープ問題が解決しない

881 ：
>>878
やっぱり>>833で指摘されていることが理解できてない。

> do {
> bool flag = ...
> } while (flag);

今でも合法なコードの意味が変わってしまうからダメなんだよ。
forの拡張や>>812とはそこが違う。

882 ：
なるほど
上にスコープが伸びるのと
下にスコープが伸びるのでは違うのか

883 ：
>>871
意味的には1で充分でしょ
trueはいいけど、TRUEはありえない

884 ：
意味的に1で良いなんて言い出したら
わざわざC言語で普通TRUE, FALSEを定義する意味もなくなってしまう

>>871はCスレと勘違いして書いたので
C++であれば当然true

885 ：
>>884
stdbool使ったらtrueでしょ？
TRUEなんてどっから出てきたんだ？
C99以降なら1で充分なんだよ

886 ：
>>882
結果的にはそうだが、
× 伸びる
○　追加される
だ。まあ、俺も間違っていたが。C++リファレンスにもモロに書いてあるが、
#define if {if
#define switch {switch
に近い。（後ろ側！という突っ込みは無しで）

>>878を訂正すると、同様にスコープを [ ] で書くとして、
[ for ( .,.. ) [ { } ]] // (または [ for ( ... ) { } ] とも解釈出来る)
[ if ( ... ) [ { } ]]
[ switch ( ... ) [ { } ]]
になってる。だから同様に while 文は
[ while ( ... ) [ { } ]]
とするのは全く問題ないし、時間の問題だろう。
ただし do-whileは
[ do [ { } ] while ( ... ) ]
ではまるで意味がないので、これはどうしようもない。
for文のスコープについては上記の通り2通りの解釈方法があり、
おそらくCの連中は体感的に後者だと思うのだが、
C++で前者だということにして if と swtch を揃えた、というところか。
なら、技術的に何ら問題ない while もほぼ間違いなく揃えられるだろう。

よって、結果的に前か後ろか、という問題だが、まあ、そういうことだ。

>>880
switchに対して同様にスコープを『追加』するのは全く問題ない。
君がswitchについて誤解しているのは、俺と同様、スコープが『拡大』されると勘違いしているからだ。
上記とC++リファレンスを再度読むべし。

887 ：
>>885
文法的には1でも100でも良い
意味的にはtrue

888 ：
>>881
>>864
> それ以前にC++は駄目な仕様は互換性が無くなっても改善して行ってる。

なお864内の
> >>833については広義に捕らえればifやswitchでも発生することだし
この部分は間違いだ。ifやswitchは互換性の問題が発生しない。
同様に、whileに対してスコープを追加しても問題は発生しない。(886で述べたとおり）

そして再度言わないと分からないようだから言うが、
俺は「使えない仕様は互換性が無くても改善しろ」という意見だ。
だからそもそも糞コードが動かなくなることは問題にしてない。
833のコードは外側の a を普通に内側から変更する手段がない。
よって必ず無限ループでしかなく、最初から

int a = 0;
while (1) {
if ( ... ) break;
}

だ。余程おかしな事をしない限り、833のコードなんて存在しない。
それ以前にdo-whileなんてほぼ死滅状態だし。
そしてここに問題が発生する可能性のある場合、コンパイラが警告を出すことは容易だ。

889 ：
>>886
スコープが拡大とか縮小とか一貫性とか意味付けとかの問題じゃなくて

【過去のコードが動かなくなるのはダメだ】

890 ：
>>889
ならwhileについて問題ないのは理解したか？

互換性を重視するか、最高の仕様を目指すかは、合意を取るべき案件ではない。
それは既に言ったが、意味がないからだ。

891 ：
必ずしも
> 【過去のコードが動かなくなるのはダメだ】
ってこともないけどな
C++17でもC++20でも非推奨機能削除してるし
auto_ptrを使ったC++03基準のコードはもはやコンパイルできない

892 ：
ライブラリ仕様じゃなくて純粋な言語仕様
コンパイルエラーが出ない
(当然今のコンパイラでは警告も出ない)
C言語にも影響する

これだけダメな理由が揃ってる

過去にこんな変更あったか？

893 ：
代替手段がもいくらでもある、ほとんど使われない改善に対して
そんな冒険をする必要はない

894 ：
>>833のコード自体は外側のaがvolatileとかでもない限りあまり意味はないが
while (++a < c);とかいくらでも意味のあるコードにできるんだけどね

それに>>833は無限ループではなくて一度もループしないなんだが

895 ：
>>890
ループ変数のスコープ問題が解決しないからダメ

896 ：
>>887
100なんて値は無い
_Boolにキャストすれば1になる

897 ：
文法的には
while (100)
でも良いって言ってるの

898 ：
文脈読まずに反射で書いただけかよ

899 ：
>>895
whileで駄目なコード書いてみ？

900 ：
（早くこの隔離スレを終わらせたくなってわざとやってる気がしてきた）

901 ：
>>895
すまん、重要なところを間違えていた。
ただまあ、通じているとは思うが。

> switchに対して (>>886)
> 君がswitchについて
どちらも while が正しい。だから 890 や 899 の発言になる。
一応訂正しておく。

902 ：
>>898,900
こいつはMIPS君とか呼ばれてるらしいんだが、間違い指摘されたりするとファビョって暴れ出すんだよ
思い込みが激しいから、それが原因でしょっちゅう間違いをやらかすんだけど、
やたらとプライドだけは高いから引っ込みがつかなくなって連投しだすんだな
この前も、アセンブラ初心者スレで「キャリーフラグがアウトオブオーダー実行を妨げる」とか言って大恥かいたはずなんだけどね
アウトオブオーダーを正しく理解してたらそんなことは言い出さない（cmovで簡単に回避できるので）

平日の昼間でも連投してるから、おそらく頭がカチカチで2chしか居場所のない爺だと思う
相手しても疲れるだけだよ

903 ：
>>899
>>812

904 ：
>>902
キャリー君おはよう

905 ：
キャリーフラグが大好きキャリー君
知識不足でまともな会話が出来ないキャリー君
いつも長文で御苦労様

906 ：
>>903
それは do-while と俺は言っている。
とりあえず俺の記載ミスも仕様に関する誤解も酷かったので、一端話を整理する。（もう一度書き直す）

スコープは　[ ] で書くとして、if や switch のようにスコープを『追加』されている場合、以下となる。(878と同じ）
[ for ( .,.. ) [ { } ]] // (または [ for ( ... ) { } ] とも解釈出来る)
[ if ( ... ) [ { } ]]
[ switch ( ... ) [ { } ]]
よって while 文は
[ while ( ... ) [ { } ]]
と解釈を変更することにより、互換性の問題なしで for/if/swtch と揃える事は可能。
俺の予想ではこれは時間の問題で仕様に入る。

do-whileは
[ do [ { } ] while ( ... ) ]
としても意味がないので、
[ do { } while ( ... ) ]
とするしかないが、これだと互換性の問題を回避出来ない。

ここまではいいか？

お前は議論慣れが全然足りない。
whileとdo-whileで全然違うこの状況で、do-whileを略してwhileと言ってはいけない。
つまり>>880がよくない。これでは話が混乱する。
ただ、混乱しても収拾すればいいだけだ。まずはここまでの認識を確認する。

907 ：
そして何度も言っているが、
その先の、「互換性がないがどうするか？」という点についてはここで、または俺と君とで詰める意味がない。
>>812については既に>>868で言ったが、その仕様では見やすくないので俺なら使わない。
だから仕様として入れる意味も、改訂する意味もない、というのが俺の意見だ。ただしそれだと
[ do ( ... ) [ { } ] while ( ... ) ]
形式に出来、互換性の問題なく、for/if/switch/whileと揃えられる。
だから提案すれば通る可能性はある。


事の発端は808、「do-while が使えなかったのはスコープの仕様が『間違っていた』からではないか？」という俺の見解だが、
今現在のところ、
if と switch について間違っていたと言うのは厳しいが、修正されている。
while については直前にループ変数を定義するだけの使い方も本当によくあるので、
この仕様は明確に間違っていたと言える。
そして for/if/swtch と揃えることに障害がないのでじきに修正されるはず。
問題は do-while で、812みたいな糞ならイラネ、なら解決策がない。

908 ：
じゃあ演算子の優先順位もおかしいから
今から変えようか

909 ：
1. 今の仕様は間違っているから修正されなければならない
2. 間違いを正しく修正するうえでは互換性が失われるのも仕方がない

テロリストや狂信者の思考やね。

910 ：
char* ptr = "string";
これを正したのはテロリストや狂信者か

911 ：
getsの廃止も1.と2.の原理に主義を置いた決断だね

912 ：
俺は本来あんなクズの肩なんざ持ちかねえが
おかしいことはおかしいと言わねば気が済まん
頼むから奴よかマシな言い訳してくれ

913 ：
演算子の優先順位もおかしいから
今から変えよう

914 ：
do-whileはもう廃止でいいじゃん

それより統一loop構文考えようぜ
loopで気持ち悪いのは、loopの脱出条件が複数ある場合
for、whileもループを回す条件を書くじゃん
でもloop中に条件によってbreakする場合って当然ループを脱出する条件を書くじゃん
この論理が裏返ってるところでよく間違えるし、
文法的に異質なのもわかりにくい
誰かナイスなアイデア考えてくれ

915 ：
for-while

916 ：
言語を考えるスレじゃねーだろここ

917 ：
ここでみんなで考えて江添に標準化させよう

918 ：
>>912
Rよクズゆとり

>>859で言ったこと守れよゴミ
さっさと出ていけ

919 ：
何度も繰り返した展開だが話を整理すると、
>>912みたいなクズゆとりが結局自由に振る舞える状況では、どうにもならない。
だから俺は912みたいなクズゆとりを排除出来る場所を作ろうとしている。

文句言うだけ言って居座り、それを悪びれもしない。
ゆとりの問題は、これをクズだと認識出来ないことだ。

920 ：
>>910-911
「型が違います」「関数が存在しません」と
コンパイラやリンカがエラーにしてくれる変更は
まだタチがいいんだよね。

困るのは黙って挙動が変わるような変更。
もっとも、いまはビルドツールもリッチになってて
「新旧の規格で動作が違うよ、大丈夫？」みたいな
親切な警告を出してくれるだろうけど。

921 ：
コンパイラオプションで互換モード付ければいいだけ
そもそも>>833のコードがどれだけあるのかと

922 ：
>>905
おいおい、突然どうしたｗ
2人にアンカー張ってるんだから、あんたのことを指してたつもりじゃなかったんだが
それに「いつも」って何だ？
もしかして、「2chしか居場所のない爺」に反応して墓穴でも掘ったのかｗ

923 ：
>>922
ゆとりR

お前もっさっさと出て行けよ
お前の書き込みなんて何ら有効な物がないだろ
お前は邪魔しかしてない
お前らゆとりはそれを平気でやるところがクズなんだよ
そしてそれを自覚出来てないから嫌われる

結果的にゆとり自身がゆとりの安住の地を壊してる
だからゆとりはゆとりコミュニティを持てずに（ゆとりからすると）老害コミュニティに混ざろうとするが、
それもこっちにとっては大迷惑なんだが

老害だと思うなら来るな
来るならおまえらゆとりよりお前らが馬鹿にしている老害の方がましだと認めていることになるのを認識しろ
そしてもうちょっとましに振る舞え

といっても、既に言ったが、きちんと使えている奴と全く駄目な奴に分化しつつある
勿論ゆとり内にもきちんと使えている奴もいる
そして俺はそれを差別せず、きっちり「ネットの使い方が分かってない馬鹿」だけを排除出来る場所を作る
ここで言うと、まず>>912(=859)と>>922、この2人をBAN出来ればずいぶんましになると思う
(俺だったらそれでまず様子見、駄目なら3人目>>914(=837)をBANしていく)

まあこういう事も何度も言ったことだが

もし俺の構想に賛同するなら、
誰がコミュニティを壊しているのか、誰をBANすればそれを修正出来るのかを、いちいち考えておいて欲しい
日本人にはその経験が無く、これを適切に出来る奴が少ない
間違ったBANを発行すれば、コミュニティは酷く崩壊する
例えばここだと>>811(ﾜｯﾁｮｲ 7773=一番沢山書いている奴）をBANしてはいけない
彼はウザがられるかもしれないが、彼をBANするようでは自由な議論は出来ないから、存在価値が無くなり、みんな出ていくことになる
（なお俺は811をウザイだなんて思ってはいない、むしろ元気があってよろしい)

924 ：
void君もあと80レスの命か。さよならvoid君

925 ：
威張れるところがここしかない惨めなオナニー小僧
実社会ではゴミにすらカウントされていないくせに

926 ：
最近はCMAKE_CXX_FLAGSやadd_compile_optionsを使うな、target_compile_optionsを使えとか言われてるけどさ、
数10のターゲットにちまちま-Wallつけるとかめんどいんだけど

927 ：
数十のターゲットをサポートする心意気はすごいね
当然CI使ってると思うけど全部テスト可能？

928 ：
>>927
引き継いだプロジェクトがくそみたいなmakefileを使っていたからCMakeで書き直した
当然テストされてない（testというディレクトリはあるが保守していないので動く保証がないと言われた）

929 ：
libgccの大きさじゃなくてunwind用のハンドラコードの増加じゃないの？

930 ：
「別のスレッド」ってのはここか(相談室150での流れ)。

931 ：
C++で複数のクラス(namespace)に同じenumを設定したいのですが
いちいち全部にコピペする以外にいいやり方ありませんかね？
class A{public: enum{One, Two, Three}; };
class B{public: enum{One, Two, Three}; }; // enumの中身はまったく同じ

932 ：
継承すれば？
class BASE{public: enum{One, Two, Three}; };
class A : BASE { };
class B : BASE { };

933 ：2020/05/14
それでいけました
ありがとうございます

C++相談室 part135
Mathematicaプログラミング　質問箱　その1
Ruby 初心者スレッド Part 65
パチンコ、パチスロの基盤のプログラム 2
●●●●TCL/TKなら俺に聞け 4●●●●
Rust Part6
知ってるとプログラミングに役立つ数学知識
s = "" + i;でintをStringに変換するのはなぜだめか
スレ立てるまでもない質問はここで 148匹目
Gtkプログラミング on Windows!!!
--------------------
こんなハカイダーは嫌だ！ハカイダーファン集合！
【芸能】元「歌のお兄さん」沢田憲一容疑者を逮捕　大麻所持容疑、覚醒剤も
【ﾃﾞﾙﾌｫﾆｯｸｽ】ﾛﾙﾊﾞｰﾝ､ｵﾚ流の使い方【φ(.. )ﾒﾓ】
将棋初心者のための質問＆雑談スレ 41局目
10年後のジャンプ、萌え系に苦戦を強いられる
札幌で一人暮らし　その228
福原遥 VS 桜井日奈子　ラウンド１
ガジュマル　気根21本目
上司が京急のことを「京浜急行」って呼ぶんだけど
【ステヅラニート】就職道KTM【 ジム乞食 】34ﾂﾞﾗ目
テレビでの新番組や再放送の予定を書き込むスレ
アンビエント チルアウト 環境音楽について語るスレ
ワンダーモモとワルキューレが大好き
遠藤チャンネルそろそろ調子乗りすぎじゃね
臨時停車の思い出を語るスレ
【YAMAHA】YZF-R25 Part66
トヨタ　デリボーイ
原理は虹に甘いよな
よるドラ だから私は推しました 第1回★2
【まつり】曙はる3【ごよみ】
TOP カテ一覧 スレ一覧 100〜終まで 2ch元 削除依頼