18/09/29 02:25:18.76 4F2hgYyq0.net
>>819-824
コピーもムーブも省略される可能性ってのは、左辺の場所でオブジェクトを直接に構築するっていう意味。
構築してからそのままコピーしてる (そして元のオブジェクトが一時的である) 場合は実際には直接構築したって同じよねという話。
842:デフォルトの名無しさん
18/09/29 14:26:47.44 7XGFV27+0.net
>>820
＞オブジェクトにムーブコンストラクタがあって戻り値が右辺値ならコピー回避されるし
なんかムーブコンストラクタを魔法か何かと勘違いしてないか？
ムーブコンストラクタの方が重い処理してたら当然重くなるんだぞ
843:デフォルトの名無しさん
18/09/29 14:32:22.06 OnnXxjQtM.net
>>826
ええ…
コピーより重いムーブコンストラクタの存在を前提に話す必要ある？
844:デフォルトの名無しさん
18/09/29 14:44:27.90 7XGFV27+0.net
むしろムーブで軽くなるのは大抵の場合ムーブによってヒープの確保、解放を
避けられるクラスだけ、だろ
ある意味そっちの方が限定して話をしてると思うが
基本をすっ飛ばすからはちみつその他誤解するやつが出てくる
845:デフォルトの名無しさん
18/09/29 14:49:31.13 IuTgmxg/0.net
この機能が必要になった背景・経緯
ムーブセマンティクスは、C++03でもNRVO（特定の文脈でのコンストラクタの省略）や、 C++11で非推奨となったstd::auto_ptrで実現されていた。
しかし、NRVOがいつでも機能するわけではなかった。
また、std::auto_ptrにはコピーと同じ文法でムーブしていることなど、問題が多かった。
そのため、コピーと区別でき、統一的にムーブを表す文法が言語機能として必要とされた。
つまりこんなあぶなっかしい
unique_ptr、shared
846:_ptr、weak_ptrとか使ってるﾔﾂﾗも ｸﾙｸﾙﾊﾟｰしかいない この程度の簡単な制御も自分で簡単に制御しきれないﾜｹだからな
847:デフォルトの名無しさん
18/09/29 14:56:25.79 IuTgmxg/0.net
しかしｱﾎのあたらしもの好きは半端ない
頭悪いｼﾛﾓﾉでも新しいものができたら使わないといけない病になってるからな
ｼﾛｳﾄに多い
848:デフォルトの名無しさん
18/09/29 14:58:40.21 7XGFV27+0.net
いや、autoはともかくshared, unique, weakは危なっかしくないと思うが・・
ムーブが使えるようになってからだし
あと個人的にはcpprefjpは規格寄り過ぎてユーザー寄りじゃないと思う
cppreference.comを使うべき
849:デフォルトの名無しさん
18/09/29 14:59:08.11 IuTgmxg/0.net
で、こんなしょうもないことより
ﾎﾝﾄに理解しないといけない部分がすっぽりと抜けてる
850:はちみつ餃子
18/09/29 16:42:03.70 4F2hgYyq0.net
C++ の (というかプログラミング言語の) ほとんどの機能は抽象化の道具。
ムーブもまた、見かけ上は代入っぽい抽象で扱えるものであっても
実態はもうちょっと速いコードにも出来る (可能性がある)。
>>829
そういう簡単な制御すら抽象化層に押し込められない方がよっぽど駄目。
クルクルパーだと思ってるならなおさら、
簡単な制御なら (いつも間違いなく) 出来ると期待すべきでない。
そんでもって大抵の人間はクソザコで、しょうもない間違いをする。
問題は道具で解決すべき。
851:デフォルトの名無しさん
18/09/29 17:03:15.96 7XGFV27+0.net
スマポは言語の機能じゃねーよボケ
852:デフォルトの名無しさん
18/09/29 18:38:13.57 GD2dD6IB0.net
>>833
>問題は道具で解決すべき。
ネ申は確かＬＬ言語を創造された
853:デフォルトの名無しさん
18/09/29 18:45:43.26 Dc4laUcM0.net
ムーブはゼロの発見に次ぐ、人類史上における大発見と言われてるけどな。
ノーベル賞候補の一つにもなってるし。
854:デフォルトの名無しさん
18/09/29 18:51:41.19 GD2dD6IB0.net
std::auto_ptr<T>はもともとオブジェクトをムーブしたくて生まれたわけでは無いと思う…
確実な解放の実現が先
ムーブする仕様はあと
あとstd::auto_ptr<T>（unique_ptr<T>でも良いが）でも使わないとやってられないｼﾁｭがC++には少なくとも1つある
855:デフォルトの名無しさん
18/09/29 18:56:52.23 oWn9MzvpM.net
move元のオブジェクトに対するアクセスがコンパイルエラーになるんならわかるけど、そうじゃないんなら
大層な仕組みを入れなくても単に unique_ptr を言語組み込みで実装すれば済む話だったのでは？
856:デフォルトの名無しさん
18/09/29 19:32:03.30 YVfD+mv1M.net
お前ら江添に負けて恥ずかしくないの？
857:デフォルトの名無しさん
18/09/29 20:26:30.14 1/46iTAZM.net
全然？
858:デフォルトの名無しさん
18/09/29 21:00:53.02 vc6gAAuZd.net
>>838
それ何が嬉しいんだ？
vector とかどうすんだよ
859:デフォルトの名無しさん
18/09/29 22:03:09.07 oWn9MzvpM.net
>>841
moveするのが分かってるんなら最初からvectorごとヒープに作って unique_ptr で持てばいいでしょ
中途半端にガワだけスタックに置く意味がない
860:デフォルトの名無しさん
18/09/29 23:45:25.50 OLOWa9QF0.net
move後の元オブジェクトを破壊っていうか破棄しようって提案もあったよ。ちょっと早くなるのだとさ。
861:デフォルトの名無しさん
18/09/30 00:04:13.06 kBo12DYt0.net
>>842
ポインターならそもそも copy のコスト安いから move 要らないじゃん
862:デフォルトの名無しさん
18/09/30 00:20:38.65 aYXyCrkn0.net
それだったら最初から普通にﾎﾟｲﾝﾀでかけよ
863:デフォルトの名無しさん
18/09/30 00:57:02.37 GfZkWSkk0.net
この3冊が、神の書！
Linux プログラミング・インタフェース、Michael Kerrisk、2012
C++11/14 コア言語、江添 亮、2015
組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド、MISRA‐C研究会、2006
864:デフォルトの名無しさん
18/09/30 01:40:28.47 CKZYWlYLa.net
>>844
だからmoveいらないって話でしょ
C++のムーブセマンティクスがああなったのは中途半端にスタックを使うスタイルが定着してしまっていて今更ポインタ使えというのは無理があるからで、
本来は所有権の管理さえ適切に行えるようになってさえいればムーブなんか要らんよ
865:デフォルトの名無しさん
18/09/30 06:43:45.01 C9oWPEnUr.net
C++ Coding Standards って新品で買えないけど代わりになる書籍ありますか？
866:デフォルトの名無しさん
18/09/30 06:48:23.20 d4gXl3Bi0.net
>>847
ポインタ使え思想はすでにC#とかなクラスが参照型な言語で実現されているが
オブジェクトの解放にガベージコレクタが要る言語になった
これはガベージコレクタ無し・所有権の無条件移動だけだと、次のようなケースで早速話が破綻するから仕方が無い
void bar(int n) {
std::unique_ptr<Foo> a(new Foo());
for (int i = 0; i < n; i++) {
func1(a, i); // func1(a, 0);で所有権がgone 以降のfunc(a, i)はaの不正アクセス
}
}
不正アクセスにならないように、実際にはこのようなfunc1()にはa.get()でポインタを渡す書き方をする
するとfunc1()以下の呼び出しは全部>>845になる
人類に逃げ場は無い
867:デフォルトの名無しさん
18/09/30 06:53:57.08 d4gXl3Bi0.net
それにポインタ使え思想だと次のようなケースでBaz::m_c[i]のBar:m_b[j]の:Foo::m_aのアクセスに藻前らどんだけ間接参照するんですかと、
class Foo {
SomeClass m_a;
};
class Bar {
Foo m_b[100];
};
class Baz {
Bar m_c[100];
};
868:デフォルトの名無しさん
18/09/30 07:13:40.02 d4gXl3Bi0.net
ちな>>850はm_bやm_cが配列であるため、配列アクセス時の添え字が定数なｼﾁｭでもない限り、JITでも間接参照回数を3以下にはできん
869:デフォルトの名無しさん
18/09/30 09:10:22.74 3yGUdTqFM.net
>>849
よくわからんな
848の問題はそれmoveでも一緒だよね
単にデフォルトの挙動がmoveかborrowかだけの話で、unique_ptrがたまたま前者なだけ
スマポ使えば間接参照はどうしても増えるけど、実際>>850のようなケースで特定の要素だけ所有権捨てたりしないでしょ
所有権を移動するかどうかはほぼ例外なくオブジェクト生成時点で予め分かってるんだから、その場合に限ってスマポを使えばよい
コーナーケースのために全てを複雑にする必要はない
870:デフォルトの名無しさん
18/09/30 09:21:04.80 d4gXl3Bi0.net
>>852
>所有権を移動するかどうかはほぼ例外なくオブジェクト生成時点で予め分かってるんだから、
有り得ない仮定すぐる…
>>849なケースにおいて、オブジェクトaの生成時点というのは、
ライブラリー制作者がfunc1()を設計してビルドまで完了した後やがな…
871:デフォルトの名無しさん
18/09/30 09:39:54.40 3yGUdTqFM.net
>>853
自分でも分かってて揚げ足取ろうとしてるんだろうけど、コーディング時に、プログラマがオブジェクトを生成することを意図したコードを記述した時点で、な
872:デフォルトの名無しさん
18/09/30 09:46:24.24 d4gXl3Bi0.net
>>854
いやｽﾏﾝ言い方がまずかったそういう意味ではない
確かに
>所有権を移動するかどうかはほぼ例外なくオブジェクト生成時点で予め分かってるんだから、
というのは真だが、ライブラリのインターフェースに解放が必要なオブジェクトのmoveなど認めたら有り得ないコストが生じるという話
func1()の制作者が所有権を寄越すことを強制した（そういうインターフェース仕様にしてしまった）場合、
func1()を使う人はfunc1()に所有権を渡さねばならない。この結果、
1. 呼び出し元（func1()を使う人）がaをコピーしてコピーをfunc1()に渡さねばならない
2. func1()は呼び出しの度に、aを解放する
というのが>>849のコードでn回無駄に繰り返される
これを避ける方法はあるっていやーあるが、結局func1()以下の呼び出しは全部>>845になる（か、ガベージコレクタの出番となる
人類に逃げ場は無い
873:デフォルトの名無しさん
18/09/30 09:52:25.65 CKZYWlYLa.net
>>855
だからそれmoveでも同じことだよね？
ユニバーサル参照のことを言ってるんだとしたら、あれただの型推論だぞ
874:デフォルトの名無しさん
18/09/30 10:03:48.10 d4gXl3Bi0.net
>>856
解放が不要なオブジェクトのmoveは話がちげう
この場合、単に生ポインタ（オブジェクトのアドレス）をfunc1()に渡すのと変わらん
これはライブラリのインターフェースに現れてもコスト的には問題は無い
元レスのアンカー先>>847は>>855のコストが避けられない主張
875:デフォルトの名無しさん
18/09/30 10:07:31.97 d4gXl3Bi0.net
いやすまん解放が不要なオブジェクトでも、所有権を移動した場合は>>855の1のコストは避けられないorz
ここは訂正
876:デフォルトの名無しさん
18/09/30 10:11:13.08 CKZYWlYLa.net
>>857
スマポのmoveも本体のmoveも一段間接参照が入る以外は何も変わらないって言ってるんだけど、そんなに難しい話かなあ
877:デフォルトの名無しさん
18/09/30 10:45:39.58 d4gXl3Bi0.net
>>859
>>849、>>850は、現行C++におけるスマポのmoveと本体のmoveの優劣は問題にしていない
848を現行C++のコード風に書いたから誤解を招いたのかもしれないが、比較はあくまで現行C++と846思想の比較であって、
846の次の思想を実行に移したら>>855のコストが避けられませんよという話
1. スタックを使うスタイルはやめるべき（全部スマポであるべき）
2. 所有権の管理さえ適切に行えるようになってさえいれば（現行C++のムーブセマンティクスみたいな）ムーブなんか要らん
1は現行C++との比較において、間接参照回数に響く
2は現行C++との比較において、現行C++では避けられるコスト（>>855またはガベージコレクション）を無駄に背負い込むことになる
878:はちみつ餃子
18/09/30 10:52:02.74 56zUhffF0.net
>>859
本体のムーブも、ムーブ出来るように書いたらカスタムなスマートポインタみたいになるから、
間接参照が入っちゃうので、なおさら同じではあると思う。
でもまあ、ムーブは抽象化の方法であって、
最終的に実行されることが同じだからなくても良いってのは暴論よね。
879:デフォルトの名無しさん
18/09/30 11:10:34.99 f0zM7Hcdr.net
アンダースコアとドットをこの順で必ず含む string があったとして、アンダースコアからドットまでの部分文字列を切り出す処理って一行で書ける？
substr と find_first_of と find_last_of を組み合わせる方法を考えたんだが、
アンダースコアの前を削る;
ドットの後を削る;
という2行に渡るやり方しか思い付かない
880:デフォルトの名無しさん
18/09/30 11:15:56.30 d4gXl3Bi0.net
ちな
>スマポのmoveも本体のmoveも一段間接参照が入る以外は何も変わらないって
これは現行C++においても違う違いがﾜｶﾙ男ならﾜｶﾙ
func1()からfunc2()にfunc1()の自動変数aをmoveするとして、かつfunc2()はインライン展開されるとすると、
func2()におけるaのメンバへのアクセスはfunc1()呼び出し時点でのスタックポインタ相対で一発でやれる
一方、aがスマポだったりすると、aのメンバへのアクセスの前に、func1()呼び出しの都度1回はスタックポインタ相対でaのアドレスを得なければならない
881:デフォルトの名無しさん
18/09/30 11:27:40.54 fM5IaZg4M.net
オブジェクト本体のメモリのコピーにかかるコストを考慮すればどっちもどっち
882:デフォルトの名無しさん
18/09/30 11:54:22.15 u5/6mv7u0.net
>>862
substr じゃなくて、コンストラクタ使えばいいんじゃね
string t(s.begin() + s.find_first_of('_') + 1, s.begin() + s.find_last_of('.'));
883:デフォルトの名無しさん
18/09/30 12:29:37.73 f0zM7Hcdr.net
>>865
なるほど、ためになります
884:デフォルトの名無しさん
18/09/30 12:35:17.89 f0zM7Hcdr.net
>>865
ふと気になったのですが、このコンストラクタの挙動って他の名前の関数で実装されてないんでしょうか？
885:さまよえる蟻人間
18/09/30 12:48:58.63 Eso9UeUod.net
>>867
assign
886:デフォルトの名無しさん
18/09/30 13:18:31.87 f0zM7Hcdr.net
>>868
何から何までありがとうございます
887:デフォルトの名無しさん
18/09/30 14:15:51.90 QSRvujde0.net
「rustにもあるし俺らも入れなきゃ」くらいの感覚で
今までのシステムとの統合性の難しさなんかほぼ考えないで入れちゃった機能だから。
c++らしいといえばらしい感覚だけど。
888:デフォルトの名無しさん
18/09/30 14:22:42.56 d4gXl3Bi0.net
std::basic_string::find()もイテレータを返すように他のコレクションとの統合性を尊重して欲しいよな
889:デフォルトの名無しさん
18/09/30 22:56:12.57 SdlFi6Ao0.net
findを実行した対象とは別のstringの同じ位置に何かしたいとき
イテレータで返されるとちょっとだけ面倒
まあ大した問題でもないんだけど
890:デフォルトの名無しさん
18/10/01 17:20:37.02 mKeAnbBU0.net
moveセマンテックが必要になった理由を理解してないのが多くて驚くばかりだな
破壊して良い中間オブジェクトとそうじゃないのとを区別するために必要なのだよ
ポインタ使えばmove必要ないとかそういう問題じゃない
891:デフォルトの名無しさん
18/10/01 17:40:58.61 qsdLJDx40.net
元はといえば禿が左辺値参照でもconstつければ右辺値を指せるという曲がった話を始めたのが
評判悪くてC++11でやっとやっとやっとやっとメスが入ったのが本当の理由
892:はちみつ餃子
18/10/01 18:05:01.87 hbafP85H0.net
>>873
色んな話題が出てるので混乱してるが、ムーブ不要論を出してる側の *元々の* 主張は >>847 の通り
「ちゃんとした所有権の管理 (たぶん Rust みたいなやつのこと？) が有りさえすれば」
であって、でもそれは C++ ではもはや無理でしょということもわかった上だと思う。
893:デフォルトの名無しさん
18/10/01 18:05:54.55 Gge6W+rt0.net
Cにも欲しいわ
Cは参照ないから右辺値指示ポインタで
894:デフォルトの名無しさん
18/10/01 18:09:04.02 qsdLJDx40.net
それを言うなら、右辺値の概念を撤廃すべきでしょ
どんな値もポインタで指すことができ、
ポインタで指すことでregister指定を解除されるという変更
895:デフォルトの名無しさん
18/10/01 18:12:32.93 UY4lJdAP0.net
テンポラリーオブジェクトなくすと、一回必ず厳密に生成してから仕様になるので、手間増えると思う。
896:デフォルトの名無しさん
18/10/01 18:40:21.84 Gge6W+rt0.net
右辺値がないと int i = 0; すら書けなくなるんだが
897:デフォルトの名無しさん
18/10/01 18:50:50.76 qsdLJDx40.net
なんで？
int j;
j ^= j;
int i = j;
左辺値でも問題ないじゃん
898:デフォルトの名無しさん
18/10/01 18:54:00.22 xwh6ZD/vM.net
>>880
苦しいねーw
899:デフォルトの名無しさん
18/10/01 19:00:24.21 Yquio+NL0.net
0 以外はどうすんの。
900:デフォルトの名無しさん
18/10/01 19:02:25.38 Gge6W+rt0.net
> j ^= j;
はい未初期化値を使ったから未定義動作で鼻から悪魔
901:デフォルトの名無しさん
18/10/01 19:04:34.50 Yquio+NL0.net
char buf[1];
int i = (int)(buf[10] - buf[0]);
で、i = 10 に初期化される。
902:デフォルトの名無しさん
18/10/01 19:05:56.72 xwh6ZD/vM.net
NaNのときはxorは未定義か、そこまで考えなかったな
903:デフォルトの名無しさん
18/10/01 19:06:32.55 uXaVofwo0.net
>>884
間違った。正しくは：
char buf[1];
int i = (int)(&buf[10] - &buf[0]); // i = 10 と等価。
904:デフォルトの名無しさん
18/10/01 19:11:01.98 rJND5eoS0.net
そもそも=の無理やりなオーバーロードや引数に対する暗黙的なattainが問題なんだろう。
しかし元々のcのシンタックスを引き継ぎつつ、上記の問題を解決するのは不可能。
905:デフォルトの名無しさん
18/10/01 19:14:47.64 Gge6W+rt0.net
>>886
10
0
&buf[10]
&buf[0]
&buf[10] - &buf[0]
(int)(&buf[10] - &buf[0])
右辺値だらけ
やりなおし
906:デフォルトの名無しさん
18/10/01 19:19:47.07 qsdLJDx40.net
>>882
別に？
int *j;
j = &10;
int i = *j;
てだけじゃん
10が左辺値だったらって話ね
char *j;
j = "\n";
int i = *j;
て話と何か違うの？
907:デフォルトの名無しさん
18/10/01 19:23:45.27 Gge6W+rt0.net
10が左辺値ならこれ認めるの？
10 = 42;
908:デフォルトの名無しさん
18/10/01 21:57:05.81 92NEoPQV0.net
お前らがC++で作ったことあるものリスト化して
909:デフォルトの名無しさん
18/10/01 22:37:33.40 qsdLJDx40.net
>>890
全然かまわん
int a = 10;
int b = 10;
a = 42;
こう言っているに過ぎない
910:デフォルトの名無しさん
18/10/01 22:42:30.92 qsdLJDx40.net
>>879
そろそろ答えてもらおうか
なぜ右辺値がないと int i = 0; が書けないのか
911:デフォルトの名無しさん
18/10/01 23:15:35.29 2m3Ms8fl0.net
>>875
ていうか所有権などという中途半端な概念にオブジェクトの解放を担わせるのは危険か無意味かのどっちかにしかならない
最後までオブジェクトを使いたい人と、そのオブジェクトを所有する人を
コードに所有権を明示するスタイルで一致させられるケースは少ない
希ガス
912:デフォルトの名無しさん
18/10/01 23:21:45.86 2m3Ms8fl0.net
しかしながら右辺値参照を使うとコードを書く人がオブジェクトの所有権を意識せざるを得ない
これを抽象化といわれるとかなり違和感
※ 個人の感想です
913:デフォルトの名無しさん
18/10/01 23:31:19.12 rJND5eoS0.net
結局ネストしたオブジェクトってのはどう扱おうと楽な扱いなんてできんってことなんだわ。
同期と効率と安全性を全て容易にするってのは不可能なんじゃないかね。
914:デフォルトの名無しさん
18/10/01 23:41:31.83 2m3Ms8fl0.net
>>896
>結局ネストしたオブジェクトってのはどう扱おうと楽な扱いなんてできんってことなんだわ。
いや？
オブジェクトの所有権は最初のcallerががっちり掴んでオブジェクトを使うcallee以下は生ポでおk
全てが調和する
915:デフォルトの名無しさん
18/10/01 23:46:11.02 zfKNS/F/0.net
ｱﾎどもはやっと気付いたか。。。
ｺﾀｴ：最初から普通にﾎﾟｲﾝﾀで書きなさい
unique_ptr、shared_ptr、weak_ptrなんか使ってるﾔﾂﾗは
ｸﾙｸﾙﾊﾟｰしかいない
916:デフォルトの名無しさん
18/10/01 23:49:34.85 aHxMqUX30.net
>>895
右辺値参照周りを抽象化とか言ってるアホははちみつだけだろ
917:デフォルトの名無しさん
18/10/02 00:39:52.22 YrRJAaFSa.net
URLﾘﾝｸ(ideone.com)
上のコードで教えて欲しい。
templateでデフォルト引数で関数を指定する場合、わざわざテンプレートパラメーターFuncにdecltype(...)しなきゃいけないのは何故？
918:デフォルトの名無しさん
18/10/02 01:21:04.00 HQVsIoxF0.net
URLﾘﾝｸ(ideone.com)
testは関数名だから型じゃない
919:はちみつ餃子
18/10/02 02:10:18.78 wuORmtyC0.net
>>895
ムーブだのなんだの言ってても、
C++ の言語機能として直接的に有るのは rvalue 参照を区別して受け取れるってだけで、
所有権の管理をキッチリやってくれるわけではない C++ の限界なんだよね。
だけど、なるべくクラス・関数の実装の中に区別を押し込めて隠す道具のひとつにはなるって話。
でも、中途半端にやるなら隠さないで見せた方がマシという論はわかる。
920:はちみつ餃子
18/10/02 05:46:40.59 wuORmtyC0.net
受取る関数の側を上手く作っておけば
それを使う側では所有権の移動とかそんなに気にしなくない？
rvalue だったら勝手にちょっと効率的になる (こともある) ねってだけで。
使うときに気にしなくて良いように押し込められるならやっぱり抽象化の道具って言えると思うよ。
921:デフォルトの名無しさん
18/10/02 06:04:33.19 YrRJAaFSa.net
>>901
ありがとう。
template<typename Func = int (int)>
を
template<typename Func>
にするとエラーになるのは何故？
922:はちみつ餃子
18/10/02 06:50:19.11 wuORmtyC0.net
>>904
デフォルト引数からはテンプレート引数を推定できない制限がある。
923:デフォルトの名無しさん
18/10/02 07:00:39.49 YrRJAaFSa.net
なるほどです。
924:デフォルトの名無しさん
18/10/02 07:46:51.87 kk/2dA0Y0.net
時々、イラつかされる制限だ
925:デフォルトの名無しさん
18/10/02 08:15:45.67 Tcj3k2lbM.net
>>891
C++が得意なことを教えてください
926:デフォルトの名無しさん
18/10/02 10:26:10.74 giBEQZ0BM.net
>>903
いや呼び出す側に意識させるのが右辺値参照の目的だろ
意識しなくていいようなケースならconst参照で十分
927:デフォルトの名無しさん
18/10/02 10:31:03.15 kk/2dA0Y0.net
冗談は顔だけにしろよ
たとえばstd::threadの右辺値参照なんぞ意識してるか？
928:デフォルトの名無しさん
18/10/02 13:13:32.45 8CvSI5wK0.net
一行目に何の意味があるのかわからん
929:デフォルトの名無しさん
18/10/02 15:51:55.37 Xh7D/bbnH.net
割と昔からあるプログラムを見てるんですけど一つのメソッド内で
for(int i = 0; ……）{……}
for(i = 0;……）{……}
って書き方してるのをちらほら見ます
要は宣言してるんだから使い回せるだろみたいな理屈なんでしょうがビルドしようとすると当然未定義だとエラーが出ます
昔のC++だとこれがオッケーだったりしたんでしょうか？
930:デフォルトの名無しさん
18/10/02 15:56:06.09 kk/2dA0Y0.net
そうだよ
931:デフォルトの名無しさん
18/10/02 16:33:18.83 Tcj3k2lbM.net
c++で初心者が作れるものを教えてください
932:デフォルトの名無しさん
18/10/02 16:37:39.73 kk/2dA0Y0.net
rogueとか作って見てはどうよ
SetConsoleCursorPositionとGetKeyStateがあれば何とかなるだろ
933:はちみつ餃子
18/10/02 16:39:28.61 wuORmtyC0.net
>>912
むしろ古い仕様だと後者の i を宣言しようとすると、
ひとつのスコープ内で同じ名前の変数を定義しようとした扱いになってエラーになったりした。
934:デフォルトの名無しさん
18/10/02 17:18:00.03 kk/2dA0Y0.net
今のコンパイラでも当時の仕様に合わせるオプションはある
935:デフォルトの名無しさん
18/10/02 18:04:17.03 Tcj3k2lbM.net
>>915
ありがとう
936:デフォルトの名無しさん
18/10/02 19:05:29.79 Tcj3k2lbM.net
C++.でバッチ処理やbashのsedの様な機能はありますか？
937:デフォルトの名無しさん
18/10/02 19:11:57.50 kk/2dA0Y0.net
システムコマンドを実行したいのならsystem関数
正規表現ならstd::regexクラス
ファイル名に関する様々なことはstd::filesystem::pathクラス
938:デフォルトの名無しさん
18/10/02 20:37:48.16 YnEH1wx10.net
>>920
ありがとうございます
とても便利です
939:デフォルトの名無しさん
18/10/03 01:07:54.12 S2BN/gu+r.net
std::array を自作関数の引数に渡したいときって、サイズはハードコードしないとダメなの？
940:さまよえる蟻人間
18/10/03 01:11:26.75 gXNqr2Qf0.net
>>922
template <size_t t_n>
void my_func(std::array<data_t, t_n>& a)
{
...
}
941:デフォルトの名無しさん
18/10/03 01:18:33.15 S2BN/gu+r.net
>>923
なるほ
ありがとうございます
942:デフォルトの名無しさん
18/10/03 01:18:50.70 S2BN/gu+r.net
>>923
なるほ
ありがとうございます
943:デフォルトの名無しさん
18/10/03 03:04:58.67 plRFOjxw0.net
>>913 >>916
ありがとうございました。やっぱそうだったんですね
しかし検索しても全然出てこないというかどう検索したら良いものか。C++98とかの時代になるんですかねぇ
944:はちみつ餃子
18/10/03 05:02:16.81 jiQInXAP0.net
>>926
たぶんそれより更に前の話だったと思う。
「c++ for文 宣言 スコープ」でググったらこういうのとかヒットした。
URLﾘﾝｸ(www.ksky.ne.jp)
D&E でも言及があって、 if 文でのルールと合わせる形で修正したという話が載ってる。
945:デフォルトの名無しさん
18/10/03 05:31:10.20 F+YgKz680.net
>>917
VC++ですら廃止予定だけど
URLﾘﾝｸ(msdn.microsoft.com)
946:はちみつ餃子
18/10/03 05:33:04.20 jiQInXAP0.net
ARM (The Annotated C++ Reference Manual; URLﾘﾝｸ(amzn.asia) ) を確認してみたら、
「初期設定文が宣言ならば、宣言された変数のスコープは for 文を囲むブロックの終わりまでである」
というような記述がある。 (要するに古い仕様)
このあたりから C++98 になるまでの間に修正したってことなんじゃないかと。
947:デフォルトの名無しさん
18/10/03 07:01:52.10 IEc6BJqm0.net
>>927
キーワードと完全に同じ綴りのマクロがあると
標準ヘッダが動作保証外になる
ISO/IEC9899:2011 7.1.2 Standard headers の段落4
948:デフォルトの名無しさん
18/10/03 11:00:28.82 e50Rb7+yd.net
>>926
最初期の処理系、AT&T cfront の頃からの仕様だから 1980年台だと思う
ちなみに有名な Annotated C++ Reference Manual (ARM) は
この cfront のリファレンスマニュアルに注を付けたもの。
Mac II が出た頃の Mac のソフト開発者は Apple の MPW という開発環境の上で
AT&T のリファレンスマニュアル見ながら cfront で開発していた。
949:デフォルトの名無しさん
18/10/03 11:03:08.53 e50Rb7+yd.net
>>926
＞しかし検索しても全然出てこないというかどう検索したら良いものか。
当時まだ処理系と独立して言語仕様を策定/記述したものは存在していなくて、
上記の cfront のリファレンスマニュアルと cfront の実際の動作が c++ の仕様でした。
950:デフォルトの名無しさん
18/10/03 12:23:08.82 eWsEWXO50.net
>>930
そんなもん古い環境で使うなら標準ヘッダのインクルード後に定義するに決まってるだろ
現行の標準に合わせたいけど仕方なく古い環境でも動くようにしたい場合のテクニックなんだから
951:デフォルトの名無しさん
18/10/03 13:10:09.63 IEc6BJqm0.net
>>933
俺だったらこう書くぜ
{ for(int i = 0; i < 1; i++) ; }
{ for(int i = 0; i < 1; i++) ; }
前提にしている環境を誤解させかねない変態コードには反対だ
952:デフォルトの名無しさん
18/10/03 13:21:21.77 2zzoZNSm0.net
953:
954:はちみつ餃子
18/10/03 17:25:53.30 jiQInXAP0.net
>>935
今では C でもブロックの頭という縛りは無いやで。
955:デフォルトの名無しさん
18/10/03 22:30:16.11 T5RLH7Axr.net
std::array ってコンパイル時にサイズが決まっていることを想定して作られてるんだよね？
だったら、「可変長ではないがサイズは実行時に決まる」というメモリが連続な配列がほしいなら生配列を使え、というのが C++ を作った人の気持ちなの？
956:デフォルトの名無しさん
18/10/03 23:04:38.92 p3pJJViFa.net
それこそvectorじゃないの
957:デフォルトの名無しさん
18/10/03 23:19:51.08 frDsf1q90.net
>>937
いや、昔はイニシャライザーリストがなかったので、初期化式が使えるオブジェクトの立ち位置だった。
イニシャライザーリストが入ったのでほぼ産廃。constexprの対応もなく死んでいる。
基本的に配列っぽいものがほしかったらベクター使ってっていう趣旨だったと思う。
958:デフォルトの名無しさん
18/10/03 23:26:50.16 T5RLH7Axr.net
>>938-939
vector ってメモリ空間連続ですか？
だったら迷わずこれ使うんですが
959:デフォルトの名無しさん
18/10/03 23:29:56.10 frDsf1q90.net
>>940
&V[0]すると一本のメモリの先頭が取れると規格書に書いてあると聞いた。
これは、サイズを拡張するなどのメモリ変更があるまで同じものを指してると思う。
960:デフォルトの名無しさん
18/10/04 00:07:58.65 zm1AtLvQ0.net
>>940
迷わず使っていいですよ
961:デフォルトの名無しさん
18/10/04 00:35:06.85 b1qTAw9u0.net
C++11からvectorのメモリ空間は連続でなければならないと規格で決められた
安心していいよ
962:デフォルトの名無しさん
18/10/04 00:40:31.88 bav+IDITr.net
>>941-943
ありがとうございます
しかしメモリが連続じゃないといけない外部ライブラリに vector 渡すの結構緊張しますね
少し飛躍するのですが、vector の入れ子は流石に連続とは限りませんよね？
963:デフォルトの名無しさん
18/10/04 00:58:43.11 s35zoLCpa.net
メモリ連続させたいならvectorの入れ子はよして。
最初arrayで考えてたなら画像とか行列とかそんな感じかな？
964:デフォルトの名無しさん
18/10/04 01:32:01.20 ezH2Wklod.net
>>943
太古から実際には連続だし規格として明記されたのは C++03 から。
C++11 で連続と規格化されたのは string (basic_string) の方。
965:デフォルトの名無しさん
18/10/04 01:57:52.21 CYtCz8O/r.net
>>945
いえ、もともとは生の一次元配列を使ってて、array の方が取り回しが良いのかなと考えただけです
実際は vector が最強ということですね
入れ子云々は本当に気になっただけです
多次元配列は、色々諦めて Boost を使っています
966:デフォルトの名無しさん
18/10/04 03:00:41.82 SxiNReMs0.net
変数名とかクラス名にめちゃくちゃ毎回悩む
従業員の名前、社員番号、階級みたいなクラスを作るときのクラス名とかって普段どうしてる？
Employeeだけで良いのだろうか
DataとかInfoとか意味のあるようでないような命名が頭をよぎってしまう
仮に従業員をEmployeeとしたときに会社名と従業員リストのDictionary<string, List<Employee>>の変数名とかどうすりゃええねんってなる
CompanyではないしCompanyDataだとそれっぽいが的確でもなさそうだし...
967:デフォルトの名無しさん
18/10/04 03:38:58.82 ezH2Wklod.net
emproyees でいいだろ
for (consy auto& emproyee : emproyees["Microsoft"]) ...
968:デフォルトの名無しさん
18/10/04 03:39:14.21 ezH2Wklod.net
rじゃなくてlか
969:さまよえる蟻人間
18/10/04 04:00:10.87 MLculXgyd.net
MapCompanyNameToEmployees
970:はちみつ餃子
18/10/04 04:12:55.17 1wg41Y300.net
>>940
vector が連続と明記されたのは C++03 だが、
C++ 標準の体制としては仕様の「欠陥」と認められた項目については過去の版にさかのぼって適用されることがあり、
vector が連続であるというのもそのひとつのはず。
つまり、 C++98 を名乗る処理系でも vector は連続であるべきで、実際にほとんどそうなっていると思う。
971:デフォルトの名無しさん
18/10/04 04:54:31.87 MQvrn7bB0.net
>>948
クラス名・変数名に迷ったら書き込むスレ。Part28 [無断転載禁止]©2ch.net
URLﾘﾝｸ(mevius.2ch.net)
972:デフォルトの名無しさん
18/10/04 19:12:35.69 Ohr0xwue0.net
>>948
素直に日本語使えばええやんけ。
973:デフォルトの名無しさん
18/10/05 00:43:30.52 SgefIaql0.net
英語の複数形は便利すぐる
emproyee_list[]の代わりにemproyees[]で済む
大文字小文字でキャメルケースも使えるしほんと出来過ぎ
974:デフォルトの名無しさん
18/10/05 01:05:30.84 lAZe+Hwv0.net
単独かコンテナで意味が大きくかわるのに
字面の違いがsのありなしは微妙すぎていまいちだと思ってる
975:デフォルトの名無しさん
18/10/05 06:55:01.43 226EunUa0.net
しかしそこまでメモリに直触りするならvectorでない方がいい気がするんだが。
976:デフォルトの名無しさん
18/10/05 07:56:42.65 Zg//fZBj0.net
だよな
生メモリがいるなら生メモリ使えってこと
977:デフォルトの名無しさん
18/10/05 08:13:10.92 8YBbWag1r.net
>>957-958
サイズの取得とかオシャレにできないじゃん
978:デフォルトの名無しさん
18/10/05 12:49:05.99 cQzHZ22n0.net
生メモリのサイズの管理の仕方さえ忘れたか
979:デフォルトの名無しさん
18/10/05 18:47:04.93 4ThlZrTR0.net
>>948
g_dictCompanyInfo
980:デフォルトの名無しさん
18/10/05 18:49:08.38 4ThlZrTR0.net
>>961
もし、今後絶対、employee の情報しか入れないと言い切れるのなら、
g_dictCompanyEmploees
でもいい。何か追加する予定なら、>>961 のように「g_dictCompanyInfo」
981:デフォルトの名無しさん
18/10/05 18:51:17.31 4ThlZrTR0.net
>>948
最初の従業員のデータについては、
EmployeeInfo
二番目の dictionary の方は、
g_dictCompanyEmploeeInfo_s
982:デフォルトの名無しさん
18/10/05 20:18:06.35 2Vgho4wC0.net
g_とか_sとかなんなんだそれ
983:デフォルトの名無しさん
18/10/05 21:02:11.53 eXLBKWdN0.net
秘密の呪文
984:デフォルトの名無しさん
18/10/05 21:42:38.07 s/+stmcD0.net
ハンガリアン記法とかいうMSが編み出した負の遺産
985:デフォルトの名無しさん
18/10/05 21:54:51.59 wRA0FWgN0.net
型付けるハンガリアンは糞だけど、グローバル変数にg_付けるのは普通でしょ
付けないの？
986:デフォルトの名無しさん
18/10/05 21:56:47.70 zW6/2yxd0.net
グローバル変数使わないしg_つけてもなんの役にも立たないし
987:デフォルトの名無しさん
18/10/05 22:29:36.85 dsZIcecxM.net
スコープを示すハンガリアンは変数のスコープを不必要に広げることに対する心理的抵抗を低減するという点で害悪
988:デフォルトの名無しさん
18/10/05 22:48:31.92 qdFd1sVz0.net
あの複雑怪奇な名前解決ルールを受け入れているC++使いからしてみれば、変数が
ローカルかグローバルかなんてわざわざ目印付けるほどのことじゃないのかも
989:デフォルトの名無しさん
18/10/05 22:49:02.31 SgefIaql0.net
パブロフの犬ｶﾖ
グローバル変数の先頭に「g_」を付け続けると
そのうち先頭に「g_」とつけただけで
990:デフォルトの名無しさん
18/10/05 23:02:57.02 SgefIaql0.net
しかしいかにクラスFooに関連するオブジェクトは全部Fooのコンストラクタかsetterで渡すか一時オブジェク
トとしてメソッドの引数として都度渡すのがオブジェクト指向設計としての理想とはいえ実際には対数表のカ
スタマイズ版みたいにかなり普遍的な意味を持つテーブルＴが存在する前提でいっぱいクラスを定義したい
ときもあるわけでそういうときはテーブルTをグローバル変数とした方がスマートに書けるTがこの世に1つし
かないのにいちいちインスタンス毎にTへのポインタを持たせるのですかみたいな、
で、そうするとグローバルであることの目立つ標識が欲しいところだがオリジナルの規則を考えるのもアホら
しいので使用人口が多そうな「g_」を使う
991:デフォルトの名無しさん
18/10/05 23:05:20.25 cQzHZ22n0.net
６０億人がシステムハンガリアンの良さを発見できなかった
そういうことだ
992:デフォルトの名無しさん
18/10/05 23:06:16.17 cQzHZ22n0.net
せっかく自動化したものを蒸し返す愚行
機械に使われる人間に自ら志願するようなことでしかない
993:デフォルトの名無しさん
18/10/05 23:14:36.32 MM5jcfpFM.net
ハンガリアン記法が滅亡した時にgとかsとかのスコーププレフィックスも一緒に絶滅したと思うの。
994:デフォルトの名無しさん
18/10/05 23:19:28.57 SgefIaql0.net
もうそういうのは見飽きたからハンガリアン無差別否定派とアプリケーションハンガリアン推進派が頃しあって消滅してくれたらいいのに…
995:デフォルトの名無しさん
18/10/05 23:22:01.95 4ThlZrTR0.net
「ハンガリアン記法を使うと、コードの断片からでも何かを発見できる。」
996:デフォルトの名無しさん
18/10/05 23:25:38.27 4ThlZrTR0.net
C#では、メンバ変数 aaa をアクセスする時には、必ず、
「this.aaa」
とするらしい。これは、C++で、ハンガリアン記法を使った場合の、
「m_aaa」
に該当する。this. と m_ では、後者のほうが短く便利。
m_ も、this. も付けない場合、たとえば、コンストラクタで
同じ意味の仮引数を使いたい場合に、何らかの別の名前を
考えなければならなくなる。
997:デフォルトの名無しさん
18/10/05 23:26:32.77 eEmdo3hB0.net
サイズ変更してキャパシティ変更になったらデリートかかる可能性が高いのでそういうことを一応管理しないといけない。
998:デフォルトの名無しさん
18/10/05 23:28:00.34 SgefIaql0.net
>C#では、メンバ変数 aaa をアクセスする時には、必ず、
999:>「this.aaa」 >とするらしい。 mjd？ いつから？次の元号から？？
1000:デフォルトの名無しさん
18/10/05 23:29:24.93 3VgmxBOW0.net
一般的に言われているシステムハンガリアンのデメリットはg、s、mには当てはまらない。
iとかdwとかlpszみたいな糞接頭辞とは分けて考えたほうがいいと思うよ。
1001:デフォルトの名無しさん
18/10/05 23:31:13.38 4ThlZrTR0.net
個人的には、以下のような命名規則は大いに役立っており、
コード全体を見ずにコードの断片を見るだけで、何も考えずに
コーディングが出来ることが多くなる。おかげでずいぶん楽になった。
char *pszText;
char szText[256];
CString strText;
char **ppszText;
「sz」は、0終端文字列。s = string、z = zero。
p は、ポインタ、str は、CString。
pp は、ポインタへのポインタ。
1002:デフォルトの名無しさん
18/10/05 23:36:17.35 zW6/2yxd0.net
m_がついててもそれがメンバである保証が何もないからなあ。無駄なだけ
1003:デフォルトの名無しさん
18/10/05 23:39:57.45 4ThlZrTR0.net
>>981
個人的には、i や dw は滅多に使わない。
lpszは、自分では使わない。pszは使う。
なぜなら、lpsz の「l」 は、16BIT時代から32BIT 時代へ移行したときの産物だから、
今は時代遅れなので。
ところで、dwRead と書くと、宣言を見返さなくても、読み込みバイト数を表す DWORD 値だと
分かって便利。dwWrite だと、その書き込み版となる。変数名が規則変化するのでとっても便利。
たとえば、「text」という変数名だと、CString 型なのか、0終端文字列なのか、
0終端が付いてないような特殊な文字列なのかが分からない。
ところが、ハンガリアン記法を使うとそれらが明確に区別できる。
0終端文字列を配列で持っているのか、それとも、そのアドレスをポインタで
持っているのかも、sz か、psz かで区別できる。
このことはバグの少ないコーディングにとても役立つ、。
頭を使わなくても機械的にコーディングできてしまうことが多くなるから。
1004:デフォルトの名無しさん
18/10/05 23:46:52.35 SgefIaql0.net
命名のプレフィックスに関する個人的な熱い想いはカプセルの内側に隠蔽すると良い
そういう意味で「m_」は比較的どうでも良い
1005:デフォルトの名無しさん
18/10/05 23:50:11.62 3VgmxBOW0.net
>>983
それを言うならあらゆるシンボル名が正しくそれを示している保証なんてないと思うよ。
>>984
そういうのはoopやtmpと相性が悪いんで…
1006:デフォルトの名無しさん
18/10/05 23:51:01.17 elz6X2140.net
こういう話だけは食い付きがいい
さすがﾄﾞｶﾀ
1007:デフォルトの名無しさん
18/10/05 23:52:25.87 zW6/2yxd0.net
そうだよ。だから最低限にしないといけない
無駄なものをつけるのはいらんバグを増やすだけで悪
1008:デフォルトの名無しさん
18/10/05 23:54:14.41 SgefIaql0.net
個人的にはCのライブラリ関数名に「g_」がついていないのを遺憾に思う
1009:デフォルトの名無しさん
18/10/05 23:54:47.79 ZMQnisBBd.net
今時ハンガリアン使うアホがいたとは驚きなんだがw
もう絶滅したと思ってた
1010:デフォルトの名無しさん
18/10/06 00:00:43.80 JjdhAE/r0.net
>>986
>そういうのはoopやtmpと相性が悪いんで…
どういう意味？
1011:さまよえる蟻人間
18/10/06 00:06:22.53 SJezKYMvd.net
OOP == オブジェクト指向プログラミング
TMP == テンプレート/temporary
1012:デフォルトの名無しさん
18/10/06 00:07:22.53 JjdhAE/r0.net
何で相性が悪いのかが分からぬ。
1013:デフォルトの名無しさん
18/10/06 00:11:20.65 d9G2ZJ030.net
いかにハンガリアン否定派といえども
いざ実際ハンガリアンで書かれた変数名を見たら体が反応してしまうということなんだろＪＫ
鍛錬が足りん
1014:デフォルトの名無しさん
18/10/06 00:14:20.26 JjdhAE/r0.net
ずっと前に、ハンガリアン記法で書かれた比較的大きなソース・コードを見て
とても分かりやすかったので自分もそれに習っただけなんだよね。
1015:デフォルトの名無しさん
18/10/06 00:23:46.06 PyrakEMK0.net
実際みんなが叩いてるから叩いてるってやつはいるだろうな
俺も別に悪くはないと思うよ
自分から進んで使おうとは思わないが
1016:デフォルトの名無しさん
18/10/06 00:28:00.98 GMmUDkcN0.net
型が殖える度に変数名のプレフィックスがどんどんどん殖えていくなんてコーダー側からしたら不毛なだけ
いざ型名変えたいと思っても後ろを振り向くのが怖くなる
1017:デフォルトの名無しさん
18/10/06 00:33:38.42 JjdhAE/r0.net
でも、BOOL 値の変数の先頭に b を付けたりすると、ミスを発見するのに大いに役立つ
事があるよ。
1018:デフォルトの名無しさん
18/10/06 00:36:41.02 GMmUDkcN0.net
読む側にとってはな
書く側は細心の注意を払わないといけない
簡単に後戻りできないからな
メンテ効率最悪なんだよ
1019:デフォルトの名無しさん
18/10/06 00:38:54.48 CdYUXXMG0.net
次はpart139でいいのか？
1020:デフォルトの名無しさん
18/10/06 00:42:40.48 tQclXtq/0.net
ハンガリアンは、集団にその命名方法が周知されていないといけないので、周知するところから始めないといけない。
周知できればコスト低減できるが、それまでのコストをどうみつもる？
1021:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 39日 8時間 40分 40秒
1022:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています