C++相談室 part131 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
次スレを立てる時は本文の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 >>199
> 君の定義ならCOBOLだって再帰出来るだろ？
（当然だが当時のCOBOLは）できないよ
戻り番地を１つしか覚えてないのでネストしたら戻れなくなる C++17ドラフトのguaranteed copy-elisionが難しい
しかも規格が約50カ所修正されている
A a = A{}; と A a = f(); のムーブ無くすだけでどんだけ根本概念に手を入れてんだ >>199
だから見解が違っているねと言ったろ
アセンブラは再帰できるのか、できないのかという問いと、
COBOLは再帰できるのか、できないのかという問いに、
同じバックボーンで答えることが俺には出来ないが
おまえさんには出来るということだろ？
>>200
bfdではi370だね 犯人扱いしておいて違ったら知らん顔という制度そのものが間違ってる
捜査協力した人には謝礼だろうが
にせ伝票で架空の謝礼費を着服なんかしてないで
やるべきことをやれっての！ 架空の謝礼費を内部告発した仙波さん、えらい扱い受けたよね C++の最新仕様を追い続けられる人ってのはやっぱどこかちょっと変わり者というか
ふわふわしたものが許せないというか、なんとなく動いてるからいいや的な緩さが
許せないというか、白黒はっきりつけようぜ的な性格なのかな？って思ったｗ たったの千円でも知らん顔とは次元が違う
謝礼の対象でないという取り決めがあるばかりに
警察官の横柄な態度を誘発しているんだよ >>208
たかだか3年に１度の更新がそんなにしんどいのかよ
追い続けるもクソもねえ
重箱の隅をつついても１冊程度にまとめられる量しかないのに 最近は生ポインタ撲滅されそうと聞いたが
今までのメソッドとかどうしてるん
混在してるだろ プロパティーいつ実装されるのやら
getsetくっそマンドクサ >>208
ほとんどが待ってた機能だぜ？
言語仕様だけでなくライブラリまで
おまえろくすっぽC++使ってねえだろ VSのインテリセンスさんだって
いまだについていけず
ポンコツなエラー吐きまくってるわけだし
まだまだ大丈夫！ >>210
＞重箱の隅をつついても１冊程度にまとめられる量しかないのに
お前は本を出したことないから「１冊程度にまとめ」るのがどれだけ大変か分からないだけ それが本当なら恥ずかしい見積もりミスしてんぜおまえさん >>217
本を読む、理解する側の分量の話をしてるんだから、まとめる側の労力が大きいかどうかはどうでもいいのでは？ 雑誌ってエロ本か何かだろどーせ
技術系の雑誌やっててあーゆーバカ言っちゃ自殺もんの恥だぜ >重箱の隅をつついても１冊程度にまとめられる量しかないのに
その一冊程度の更新にclang/gcc/vc++すべてが追従出来ていないというのに >>205
情熱があるんだね，うらやましい‥
ガス欠状態から脱却した あいたた、本にまとめることも、実装とテストも、
とにかく量的な感覚がどこにもないのか >>213
なら、publicにしちゃえばいいじゃんといってみる。
関数は振る舞いを書くべきだと思うし、変数の代わりに使うものじゃないと思うんだ。
あと、オブジェクト指向的にクラス変数は基本悪である、ということも考えるべきではないだろうか。 >>227
横からだけど俺もそれに同意だ
余分な抽象化は単に工数が増えるだけ
しかしなんで"貪欲"な標準化委員会はプロパティは入れないんだろな >>229
変数そのものがバッキングフィールドにカプセル化されることで、変数へのアクセスを必ずメソッド経由にできる >>231
バッキングフィールドってメンバ変数をprivateにすれば今でも同じことできるんじゃね？ 地味に嬉しいのは既存のパブリックメンバ変数にアクセスしてるコードを変更せずに処理を追加できること >>232
privateな変数はclass内からアクセスし放題だけど、バッキングフィールドはアクセッサ経由以外では絶対に触れない c++erは厳しくしつけられているので、既存のpublicメンバがそもそも存在しない >>233
逆にそれが入らない原因なのでは？
軽い処理(public変数）なのか重いかもしれない処理（関数呼び出し）なのか、
見た目分かるようにしろってのがC++の流儀なんだろ。
俺はあった方がいいと思うけどね。
速度チューニングでこの手のマイクロマネージメントは全く意味がないから。 publicなメンバが一つもなかったらそもそもインスタンスを構築できないのでは… >>238
メンバ変数の公開よりもアクセサーを設けてインライン展開してもらう方がC++の思想的に望ましいのでは… >軽い処理(public変数）なのか重いかもしれない処理（関数呼び出し）なのか、
>見た目分かるようにしろってのがC++の流儀なんだろ。
C++って、それを判断するのが最も困難な部類の言語だと思うが。 set/get用のデータメンバをちまちま用意するという
狭い考えに限定してきやがる思考妨害アイテムは無用 >>240
それはオブジェクト指向の理想。C++はそっちを向いていない。
>>242
いや簡単な部類の言語だ。 ほう、ではこのプログラムがC++17で何回ムーブが行われるかわかるかね？
auto f() {
struct C{int m;};
return C{};
}
auto c = f(); 残念
0回または1回
因みに確認のためにムーブコンストラクターを追加すると0回に変わる ということで、見た目で判断することは難しいのではないかと つかお前ら他言語使ってないだろ。
逆に言えばC++はその程度の精度での見積もりが出来る、ということなんだよ。
GC言語なんてGCがどこで走るか予測不能だから、実行時間の保証なんて全く出来ないし、
JIT言語はJIT側にその最適化が入っているかどうかで全く速度が変わってしまう。
つまりJava/C#/JavaScript等はその精度での見積もりはそもそも不可能なんだよ。
それとは別に、C++はその辺の仕組みがかなり複雑になっているのは認めるが、
それでも他言語と比べたら精度高く見積もれる方だよ。
getterを使った場合の問題は、それが見積もりにくくなることと、
あまりに多用するとどこで処理しているのか分かりにくくなる点だが、
まあ、適切に使っている限りはかなり使える機能だから、有った方が便利なんだけどね。
だから普通に考えれば「貪欲」なら当然入れるべきだし、
むしろラムダより先に入れるべきだが、入れないんだから何か引っかかってんでしょ多分。 getter がただの変数アクセスに被せてあるだけならまともなコンパイラなら最適化で消えるから速度的なペナルティはゼロだよ。 a = 1;
こんなコード片で、aの型がプリミティブ型かconstr(int)/operator=(int)を持つクラスなのかによって
実際に実行される処理内容が違う時点で
>軽い処理(public変数）なのか重いかもしれない処理（関数呼び出し）なのか、
>見た目分かるようにしろってのがC++の流儀なんだろ。
そんなものないとわかるだろう。
それににしても、そこからGCのオーバーヘッドに話が飛ぶのはさすがにアクロバティックすぎるw
実実行時間の話なら、マルチスレッドの非リアルタイムOS上のプログラムはどれも正確な見積もりなどできん。 プリミティブ型？ ああJava訛りね、C++用語はISO/IEC14882:2011 3.9.1に規定あるから
a = 1; がビルトインの代入か、トリビアルのoperator=か、
ユーザー定義のoperator=か、コンストラクタを呼び出すか、
コピーかムーブか、読めない人はC++には向いてないので無理しなくていいよ
要するにアセンブラ苦手なんだろ
マルチスレッドでもタイムクリティカルとか割り込みマスクとかあるしね
別にRTOSに限ったことじゃなく >>254
オメーは何が言いてえんだw
無意味に反論するんじゃねえよ
だからアホだって言われるんだよ C++を批判するには
おまえ足んねーものが
多すぎつってんだよ C++ 標準委員会のドワンゴ江添は、職務質問の手荷物検査を拒否したら、
警官10人に、現場で1時間半以上、拘束されたらしい
捜査でもない、任意の行政処分なのにw
それで東京都を訴えた >>254
> a = 1; がビルトインの代入か、トリビアルのoperator=か、
> ユーザー定義のoperator=か、コンストラクタを呼び出すか、
> コピーかムーブか、読めない人
それがわかったからと言ってなんになるんだ？
定義が常に読めるとは限らんだろ
> 要するにアセンブラ苦手なんだろ
逆アセしてでも読めとか言ってるなら単なる老害のアホ >>258
ほーお、おまえさんは定義が読めないと判断できないのか
普通の人は宣言まで読めれば判断できるんだがｗ
逆汗読まないほうがバカガキ
バカガキからみて普通の人は老害というだけ IDEがやれば済むこと
わざわざ言語に入れる必要なし！ メンバ変数と関数の呼び出し統一化。
いらんというのは同意。 オブジェクトの状態と操作の区別
関数でも代用できてしまうけど、変数のように扱えるってのが大きい
変数のような使い方で処理を挟める、これはPublicなメンバ変数では出来ない できるよバーカ
C++98より前、ARM C++の時代から たしかに、operator()とoperator=があればできそうではある ARMだとテンプレートないから、メンバ変数にしたい型ごとにラッパークラス作らないいけないから大変そう 質問ですが
std::string str("abcdefghi"); // (*1)
str.resize(8); // (*2)
size_t len = strlen(str.c_str()); // <-- "abcdefgh\0"の長さが返る (*3)
となるのですが、(*3)の時点でできる終端NUL文字"\0"って、
いつのタイミングでどこの領域に確保されるのですか、 訂正
×：、(*3)の時点でできる
○：、(*3)の時点でできている >>270
そのスマートオブジェクトをメンバ変数にした場合、一々親へのポインタをそのスマートオブジェクトに記憶してやらんといけないからすごく面倒なのだよ
プロパティはその点何の束縛もないから良いのだ >>272
アフォｗｗｗ
template と try catch それと typeid はARMで新設されたんだよ
おまえ多重継承だけだと思ってんだろ >>273
(*2)の時点で 'i' があった場所に置かれる、
と素朴に思ってた >>273
(*2) の時点で新規領域に abcdefgh をコピーしてその後に \0 を置く コピーが生じないんだとしたら、
std::string::size()はいつも1バイトだけサバを読んだ値を返すってこと？ Windows Phoneの開発で使うC++/CXにはpropertyが構文でサポートされているで
ていうかpropertyがあることが存在意義な感じ？（ネイティブなC++は別にあってそれはそれで利用可能 データメンバ直アクセスでなくてpropertyにすると良いことがあるというのは
マーシャリングを裏で勝手にやって来る点 ｜
｜ ('A`) .oO（名前考えるのﾏﾝﾄﾞｸｾ
／￣ﾉ( ﾍﾍ￣￣￣
／ 0変数:getter, 1変数:setter, 尻尾付き:メンバ変数
とかは良くやるな >>287
それ以前のVC++/CLIからサポートされてる。
>>286
駄目。
propertyは新規機能ではなく、見た目だけの問題だから、
逆に言えば、見た目がpropertyで書いた時より分かりにくいようなら駄目なんだ。
ほぼ同じ事はラムダとファンクタでもそうだけど。 >>268
オペレーターのオーバーライドとにたような感じになると思うけど、その挟み込む処理の重さが隠蔽されてしまうという問題があって、一般には、非推奨だとおもうのだけど今はかわってきてるのかね？
たとえば、代入しているだけだとおもったら、実はファイルアクセスまでしてたとかかな。 >>293
>258理論によれば、老害じゃなければ一目で処理の重さがわかるんじゃね
もっとも処理の重さに関するC++の不透明さに警戒を抱くことを老害とするならば、
カーニハンやリッチーも老害にカテゴライズされてしまうが >>294
K&Rというか生Cが嫌っている理由は「余計なことをするな」だ。
適切に使っている限りC++は不透明ではない。それでも彼等は嫌うだろ。
>>293
横だが結局は使い方次第だよ。C++はいくらでも読みにくいコードを書けるから。
ただ、きちんと使えば有用な機能だよ。
演算子オーバーロードについてはgoogleは「慎重にやれ」だね。
https://ttsuki.github.io/styleguide/cppguide.ja.html#Operator_Overloading
どうでもいいが、何故演算子は「オーバーロード」なんだ？
言われてみれば「オーバーライド」の方が適切な気がする。 >>293
それは言語機能の問題じゃなく実装の問題じゃない？
propertyってメンバ変数がどうなっているかに関わらずオブジェクトの状態を表すもの
言語機能の話をしているのであって
既存の機能をやりくりして似たことは出来るって言われてもって感じ 「処理の重さを隠蔽するな」なんて思想がそもそもあるのかね？ >>295
オーバーロードは新設で、たいていのoperatorがこっち
オーバーライドは変更で、代入やnewが本当はこっち property ってパブリック変数とどう違うの？ >>294
> >258理論によれば、老害じゃなければ一目で処理の重さがわかるんじゃね
どこにも「わかる」って書いてないのにどんなアホ解釈したらそんな結論になるんだよ w ■ このスレッドは過去ログ倉庫に格納されています
