C++相談室 part131 [無断転載禁止]©2ch.net

2017/07/29(土) 11:28:28.97

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

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

前スレ
C++相談室 part130
http://mevius.2ch.net/test/read.cgi/tech/1490917669/

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

■長いソースを貼るときはここへ。■
　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

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

2017/08/21(月) 23:00:08.39

犯人扱いしておいて違ったら知らん顔という制度そのものが間違ってる
捜査協力した人には謝礼だろうが
にせ伝票で架空の謝礼費を着服なんかしてないで
やるべきことをやれっての！

2017/08/21(月) 23:01:02.71

架空の謝礼費を内部告発した仙波さん、えらい扱い受けたよね

2017/08/21(月) 23:09:51.41

C++の最新仕様を追い続けられる人ってのはやっぱどこかちょっと変わり者というか
ふわふわしたものが許せないというか、なんとなく動いてるからいいや的な緩さが
許せないというか、白黒はっきりつけようぜ的な性格なのかな？って思ったｗ

2017/08/21(月) 23:12:01.91

たったの千円でも知らん顔とは次元が違う
謝礼の対象でないという取り決めがあるばかりに
警察官の横柄な態度を誘発しているんだよ

2017/08/21(月) 23:56:14.20

>>208
たかだか3年に１度の更新がそんなにしんどいのかよ
追い続けるもクソもねえ
重箱の隅をつついても１冊程度にまとめられる量しかないのに

2017/08/21(月) 23:59:39.85

最近は生ポインタ撲滅されそうと聞いたが
今までのメソッドとかどうしてるん
混在してるだろ

2017/08/22(火) 00:35:41.09

生ポのオレオレ定義

2017/08/22(火) 00:59:49.41

プロパティーいつ実装されるのやら
getsetくっそマンドクサ

2017/08/22(火) 01:03:51.34

>>208
ほとんどが待ってた機能だぜ？
言語仕様だけでなくライブラリまで
おまえろくすっぽC++使ってねえだろ

2017/08/22(火) 02:32:46.66

全くわからない
雰囲気でc++を使っている

2017/08/22(火) 02:42:19.05

VSのインテリセンスさんだって
いまだについていけず
ポンコツなエラー吐きまくってるわけだし
まだまだ大丈夫！

2017/08/22(火) 11:30:22.61

>>210
＞重箱の隅をつついても１冊程度にまとめられる量しかないのに

お前は本を出したことないから「１冊程度にまとめ」るのがどれだけ大変か分からないだけ

2017/08/22(火) 12:26:19.96

そういうおまえはあるのか？

2017/08/22(火) 12:33:51.83

雑誌の編集長ですから

2017/08/22(火) 12:42:39.12

それが本当なら恥ずかしい見積もりミスしてんぜおまえさん

**デフォルトの名無しさん** (JP 0H85-SBNh) · 2017/08/22(火) 12:43:40.67

>>217
本を読む、理解する側の分量の話をしてるんだから、まとめる側の労力が大きいかどうかはどうでもいいのでは？

2017/08/22(火) 15:03:21.13

うん。するどい。

2017/08/22(火) 15:14:35.21

雑誌ってエロ本か何かだろどーせ
技術系の雑誌やっててあーゆーバカ言っちゃ自殺もんの恥だぜ

2017/08/22(火) 17:02:21.79

>重箱の隅をつついても１冊程度にまとめられる量しかないのに
その一冊程度の更新にclang/gcc/vc++すべてが追従出来ていないというのに

2017/08/22(火) 17:10:08.87

>>205
情熱があるんだね，うらやましい‥
ガス欠状態から脱却した

2017/08/22(火) 17:20:14.07

あいたた、本にまとめることも、実装とテストも、
とにかく量的な感覚がどこにもないのか

2017/08/22(火) 20:47:37.89

>>213
なら、publicにしちゃえばいいじゃんといってみる。

関数は振る舞いを書くべきだと思うし、変数の代わりに使うものじゃないと思うんだ。

あと、オブジェクト指向的にクラス変数は基本悪である、ということも考えるべきではないだろうか。

2017/08/22(火) 20:56:12.81

>>227
横からだけど俺もそれに同意だ
余分な抽象化は単に工数が増えるだけ
しかしなんで"貪欲"な標準化委員会はプロパティは入れないんだろな

2017/08/22(火) 21:04:28.96

プロパティ導入したら、なんかいいことあるの？

2017/08/22(火) 21:13:44.10

>>227
クラス変数って何？

2017/08/22(火) 21:18:39.19

>>229
変数そのものがバッキングフィールドにカプセル化されることで、変数へのアクセスを必ずメソッド経由にできる

2017/08/22(火) 21:46:13.74

>>231
バッキングフィールドってメンバ変数をprivateにすれば今でも同じことできるんじゃね？

2017/08/22(火) 22:05:33.19

地味に嬉しいのは既存のパブリックメンバ変数にアクセスしてるコードを変更せずに処理を追加できること

2017/08/22(火) 22:30:23.44

>>232
privateな変数はclass内からアクセスし放題だけど、バッキングフィールドはアクセッサ経由以外では絶対に触れない

2017/08/22(火) 22:34:14.35

c++erは厳しくしつけられているので、既存のpublicメンバがそもそも存在しない

2017/08/22(火) 22:35:33.43

>>235
これは正しい

2017/08/22(火) 22:36:16.75

おっと変数が抜けた

2017/08/22(火) 22:58:36.57

>>233
逆にそれが入らない原因なのでは？
軽い処理(public変数）なのか重いかもしれない処理（関数呼び出し）なのか、
見た目分かるようにしろってのがC++の流儀なんだろ。

俺はあった方がいいと思うけどね。
速度チューニングでこの手のマイクロマネージメントは全く意味がないから。

2017/08/22(火) 22:59:26.20

publicなメンバが一つもなかったらそもそもインスタンスを構築できないのでは…

2017/08/22(火) 23:02:04.62

>>238
メンバ変数の公開よりもアクセサーを設けてインライン展開してもらう方がC++の思想的に望ましいのでは…

**239** (ﾜｯﾁｮｲ 93c5-8P7d) · 2017/08/22(火) 23:02:59.41

ｽﾏﾝfriendを使えば良いのか…

2017/08/22(火) 23:13:00.45

>軽い処理(public変数）なのか重いかもしれない処理（関数呼び出し）なのか、
>見た目分かるようにしろってのがC++の流儀なんだろ。

C++って、それを判断するのが最も困難な部類の言語だと思うが。

2017/08/22(火) 23:20:46.21

set/get用のデータメンバをちまちま用意するという
狭い考えに限定してきやがる思考妨害アイテムは無用

2017/08/22(火) 23:28:17.57

>>240
それはオブジェクト指向の理想。C++はそっちを向いていない。

>>242
いや簡単な部類の言語だ。

2017/08/22(火) 23:37:15.06

ほう、ではこのプログラムがC++17で何回ムーブが行われるかわかるかね？
auto f() {
struct C{int m;};
return C{};
}
auto c = f();

2017/08/22(火) 23:37:39.41

はいはい属性の抽象化属性の抽象化

2017/08/22(火) 23:39:19.18

>>245
0回

2017/08/22(火) 23:41:09.40

残念
0回または1回
因みに確認のためにムーブコンストラクターを追加すると0回に変わる

2017/08/22(火) 23:49:21.67

ということで、見た目で判断することは難しいのではないかと

2017/08/23(水) 00:09:19.34

つかお前ら他言語使ってないだろ。
逆に言えばC++はその程度の精度での見積もりが出来る、ということなんだよ。

GC言語なんてGCがどこで走るか予測不能だから、実行時間の保証なんて全く出来ないし、
JIT言語はJIT側にその最適化が入っているかどうかで全く速度が変わってしまう。
つまりJava/C#/JavaScript等はその精度での見積もりはそもそも不可能なんだよ。

それとは別に、C++はその辺の仕組みがかなり複雑になっているのは認めるが、
それでも他言語と比べたら精度高く見積もれる方だよ。

getterを使った場合の問題は、それが見積もりにくくなることと、
あまりに多用するとどこで処理しているのか分かりにくくなる点だが、
まあ、適切に使っている限りはかなり使える機能だから、有った方が便利なんだけどね。
だから普通に考えれば「貪欲」なら当然入れるべきだし、
むしろラムダより先に入れるべきだが、入れないんだから何か引っかかってんでしょ多分。

2017/08/23(水) 00:16:20.92

>>248
？

2017/08/23(水) 02:11:33.58

getter がただの変数アクセスに被せてあるだけならまともなコンパイラなら最適化で消えるから速度的なペナルティはゼロだよ。

2017/08/23(水) 07:57:53.52

a = 1;

こんなコード片で、aの型がプリミティブ型かconstr(int)/operator=(int)を持つクラスなのかによって
実際に実行される処理内容が違う時点で

>軽い処理(public変数）なのか重いかもしれない処理（関数呼び出し）なのか、
>見た目分かるようにしろってのがC++の流儀なんだろ。

そんなものないとわかるだろう。
それににしても、そこからGCのオーバーヘッドに話が飛ぶのはさすがにアクロバティックすぎるw
実実行時間の話なら、マルチスレッドの非リアルタイムOS上のプログラムはどれも正確な見積もりなどできん。

2017/08/23(水) 08:29:43.04

プリミティブ型？　ああJava訛りね、C++用語はISO/IEC14882:2011 3.9.1に規定あるから

a = 1; がビルトインの代入か、トリビアルのoperator=か、
ユーザー定義のoperator=か、コンストラクタを呼び出すか、
コピーかムーブか、読めない人はC++には向いてないので無理しなくていいよ
要するにアセンブラ苦手なんだろ

マルチスレッドでもタイムクリティカルとか割り込みマスクとかあるしね
別にRTOSに限ったことじゃなく

2017/08/23(水) 11:11:46.28

>>254
オメーは何が言いてえんだw
無意味に反論するんじゃねえよ
だからアホだって言われるんだよ

2017/08/23(水) 12:25:37.91

C++を批判するには
おまえ足んねーものが
多すぎつってんだよ

2017/08/23(水) 18:58:23.34

C++ 標準委員会のドワンゴ江添は、職務質問の手荷物検査を拒否したら、
警官10人に、現場で1時間半以上、拘束されたらしい

捜査でもない、任意の行政処分なのにw

それで東京都を訴えた

2017/08/23(水) 19:16:52.69

>>254
> a = 1; がビルトインの代入か、トリビアルのoperator=か、
> ユーザー定義のoperator=か、コンストラクタを呼び出すか、
> コピーかムーブか、読めない人
それがわかったからと言ってなんになるんだ？
定義が常に読めるとは限らんだろ

> 要するにアセンブラ苦手なんだろ
逆アセしてでも読めとか言ってるなら単なる老害のアホ

2017/08/23(水) 22:25:37.71

>>258
ほーお、おまえさんは定義が読めないと判断できないのか
普通の人は宣言まで読めれば判断できるんだがｗ

逆汗読まないほうがバカガキ
バカガキからみて普通の人は老害というだけ

2017/08/24(木) 00:52:21.94

そうか。

2017/08/24(木) 07:16:54.28

老害だと思ってたら基地害だったと言うオチかよ w

2017/08/24(木) 07:27:59.03

熱いなプロパティ
はやく標準化されればいいのに

2017/08/24(木) 10:04:23.28

いらね

2017/08/24(木) 11:04:12.57

プロパティじゃないと出来ないことってなになの

2017/08/24(木) 11:21:59.10

見た目だけじゃね？

2017/08/24(木) 11:45:56.43

IDEがやれば済むこと
わざわざ言語に入れる必要なし！

2017/08/24(木) 12:19:36.07

メンバ変数と関数の呼び出し統一化。
いらんというのは同意。

2017/08/24(木) 14:05:25.76

オブジェクトの状態と操作の区別
関数でも代用できてしまうけど、変数のように扱えるってのが大きい
変数のような使い方で処理を挟める、これはPublicなメンバ変数では出来ない

2017/08/24(木) 14:20:51.13

できるよバーカ
C++98より前、ARM C++の時代から

2017/08/24(木) 17:42:35.34

たしかに、operator()とoperator=があればできそうではある

2017/08/24(木) 18:28:45.68

>>269
どうやって？コードよろ

2017/08/24(木) 18:48:22.87

ARMだとテンプレートないから、メンバ変数にしたい型ごとにラッパークラス作らないいけないから大変そう

2017/08/24(木) 18:52:57.63

質問ですが
std::string str("abcdefghi");　// (*1)
str.resize(8); // (*2)
size_t len = strlen(str.c_str()); // <-- "abcdefgh\0"の長さが返る (*3)
となるのですが、(*3)の時点でできる終端NUL文字"\0"って、
いつのタイミングでどこの領域に確保されるのですか、

2017/08/24(木) 18:54:42.67

訂正
×：、(*3)の時点でできる
○：、(*3)の時点でできている

2017/08/24(木) 19:23:39.06

ARMテンプレートあったわ。失礼

2017/08/24(木) 20:00:39.22

>>270
そのスマートオブジェクトをメンバ変数にした場合、一々親へのポインタをそのスマートオブジェクトに記憶してやらんといけないからすごく面倒なのだよ
プロパティはその点何の束縛もないから良いのだ

2017/08/24(木) 20:11:18.34

>>272
アフォｗｗｗ
template と try catch それと typeid はARMで新設されたんだよ
おまえ多重継承だけだと思ってんだろ

2017/08/24(木) 20:14:15.85

>>273
*1の時点であるよ

2017/08/24(木) 20:17:27.08

>>273
(*2)の時点で 'i' があった場所に置かれる、

と素朴に思ってた

**デフォルトの名無しさん** · 2017/08/24(木) 20:39:47.98

🐒

2017/08/24(木) 21:28:30.26

>>273
(*2) の時点で新規領域に abcdefgh をコピーしてその後に \0 を置く

2017/08/24(木) 21:29:59.02

新規領域もコピーもないでしょ

2017/08/24(木) 21:33:49.00

コピーが生じないんだとしたら、
std::string::size()はいつも1バイトだけサバを読んだ値を返すってこと？

2017/08/24(木) 21:34:29.37

せやで

2017/08/24(木) 21:35:38.05

なのか

**270** (ｽｯｯﾌﾟ Sdea-l/E4) · 2017/08/24(木) 22:02:35.81

プロパティはこれじゃアカンの？
https://wandbox.org/permlink/a1fqVzyPCHgFeNjc

2017/08/24(木) 22:12:47.64

Windows Phoneの開発で使うC++/CXにはpropertyが構文でサポートされているで
ていうかpropertyがあることが存在意義な感じ？（ネイティブなC++は別にあってそれはそれで利用可能

2017/08/24(木) 22:15:25.24

データメンバ直アクセスでなくてpropertyにすると良いことがあるというのは
マーシャリングを裏で勝手にやって来る点

2017/08/24(木) 22:28:47.63

メンバ関数でいいじゃん。ということだろ。

2017/08/24(木) 22:34:36.32

　｜
　｜　('A`)　.oO（名前考えるのﾏﾝﾄﾞｸｾ
　／￣ﾉ( ﾍﾍ￣￣￣
／

2017/08/24(木) 22:54:26.67

0変数:getter, 1変数:setter, 尻尾付き:メンバ変数
とかは良くやるな

2017/08/25(金) 00:06:28.73

>>287
それ以前のVC++/CLIからサポートされてる。

>>286
駄目。
propertyは新規機能ではなく、見た目だけの問題だから、
逆に言えば、見た目がpropertyで書いた時より分かりにくいようなら駄目なんだ。
ほぼ同じ事はラムダとファンクタでもそうだけど。

2017/08/25(金) 00:10:22.03

>>268
オペレーターのオーバーライドとにたような感じになると思うけど、その挟み込む処理の重さが隠蔽されてしまうという問題があって、一般には、非推奨だとおもうのだけど今はかわってきてるのかね？

たとえば、代入しているだけだとおもったら、実はファイルアクセスまでしてたとかかな。

2017/08/25(金) 00:19:32.01

>>293
>258理論によれば、老害じゃなければ一目で処理の重さがわかるんじゃね
もっとも処理の重さに関するC++の不透明さに警戒を抱くことを老害とするならば、
カーニハンやリッチーも老害にカテゴライズされてしまうが

2017/08/25(金) 00:49:30.90

>>294
K&Rというか生Cが嫌っている理由は「余計なことをするな」だ。
適切に使っている限りC++は不透明ではない。それでも彼等は嫌うだろ。

>>293
横だが結局は使い方次第だよ。C++はいくらでも読みにくいコードを書けるから。
ただ、きちんと使えば有用な機能だよ。
演算子オーバーロードについてはgoogleは「慎重にやれ」だね。
https://ttsuki.github.io/styleguide/cppguide.ja.html#Operator_Overloading

どうでもいいが、何故演算子は「オーバーロード」なんだ？
言われてみれば「オーバーライド」の方が適切な気がする。

2017/08/25(金) 02:45:57.11

>>293
それは言語機能の問題じゃなく実装の問題じゃない？

propertyってメンバ変数がどうなっているかに関わらずオブジェクトの状態を表すもの
言語機能の話をしているのであって
既存の機能をやりくりして似たことは出来るって言われてもって感じ

2017/08/25(金) 04:18:10.56

「処理の重さを隠蔽するな」なんて思想がそもそもあるのかね？

2017/08/25(金) 05:23:39.04

>>295
オーバーロードは新設で、たいていのoperatorがこっち
オーバーライドは変更で、代入やnewが本当はこっち

2017/08/25(金) 06:02:53.19

property ってパブリック変数とどう違うの？

2017/08/25(金) 06:53:00.86

>>294
> >258理論によれば、老害じゃなければ一目で処理の重さがわかるんじゃね
どこにも「わかる」って書いてないのにどんなアホ解釈したらそんな結論になるんだよ w

2017/08/25(金) 06:55:30.90

>>295
> どうでもいいが、何故演算子は「オーバーロード」なんだ？
> 言われてみれば「オーバーライド」の方が適切な気がする。
オーバーロードとオーバーライドの違いもわかってないの？
まあ>>298も色々おかしいが

2017/08/25(金) 07:02:27.63

オーバーロードってモモンガ

2017/08/25(金) 07:24:58.66

https://ideone.com/CUMjUp
http://qiita.com/a-beco/items/7709ab80a05ea2d09ea8#%E3%83%86%E3%83%B3%E3%83%97%E3%83%AC%E3%83%BC%E3%83%88%E5%BC%95%E6%95%B0%E3%81%AB%E3%83%9D%E3%82%A4%E3%83%B3%E3%82%BF%E3%82%92%E4%B8%8E%E3%81%88%E3%82%8B
なんか通った。プロパティですよ？
こんなかんじでいいのかな？
何で動いてるのかよくわからん。Orz

2017/08/25(金) 07:49:18.88

>>300
>>254～>>258の流れをa=1;の実行速度が一目見てわかるのかどうかという問題提起の意味に解釈すた、
パフォーマンスを読みきるには何の言語であれボトルネック（ループ回数×1回の実行時間が最大の処理）の特定が必要だが
C++は演算子のオーバーロードとかインライン展開とかテンプレートがそれ以前の障害として立ちはだかる点がCより重症
パフォーマンスを上げるための手段を豊富に提供してプログラムを書く人の選択に委ねているみたいな？
つまりC++はソースコードのROM専はお断りな言語

>>295
ｽﾏﾝ言いたかったのはK&Rではなくてカーニハンとロブ・パイクやったorz
『プログラミング作法』の第7章「性能」のところにC++の特性について（CやJavaとの比較が）書かれていた希ガス、
（目次）ttps://tatsu-zine.com/books/practice-of-programming
ちな本は売ったから手元に無い

>>297
本来のK&Rがまさにそれなのでは…
Unixの移植目的で作られた言語なので、移植性と意図通りのアセンブリコードに落ちること
（ソースコードからアセンブリコードが透けて見えること）の両立が着手時点の第一優先だったはず
故に生ポインタが言語の前面に出てきてインクリメント/デクリメントがそれぞれ2種類あった

2017/08/25(金) 08:42:44.14

>>298
いや、new もオーバーロードでしょ。