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 質問ですが
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 >>295
> どうでもいいが、何故演算子は「オーバーロード」なんだ？
> 言われてみれば「オーバーライド」の方が適切な気がする。
オーバーロードとオーバーライドの違いもわかってないの？
まあ>>298も色々おかしいが >>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種類あった >>298
いや、new もオーバーロードでしょ。 新しくメモリのようなものを持って来るってことでしょ。
言語上ではオペレーターじゃないの？ オペレータはオーバーロードするもんじゃね？
まぁいいか。 >>305
「本当は」って書いてるだろ
# 流れを読んでない近視眼的なアフォどもは無視 「本当は」とは？
C++の規格？
本来の英語の意味？ 突然「本当は」とか書いても、どういう意味でどういう意図で書いたかなんてわからんぞ >>304
ごちゃごちゃ書いてるけどどこから
> 老害じゃなければ一目で処理の重さがわかるんじゃね
が出てくるのかさっぱりわからん >>311
いや、グローバルのオペレーターに対して、型特化を新設するんだから、newも代入も、オーバーロードでいいんだよ。って話。
c++の実現方法（クラス内定義）でイメージしちゃうから、オーバーライドと思っちゃう気持ちはわかるけど。 ::operator newは新設か？
ユーザー定義するとビルトインを置き換えるだろ operatorをオーバーライドしてる人いるみたいだけど、operatorを仮想関数にするのってどういう時なの？ >>323
具体的には何のoperatorをオーバーライドしてるの？ operator==を仮想化したら、多態性が必要な状況であれこれはかどるだろう。
Numberクラスを基底として、RealクラスやらComplexクラスを作ったりしたら、同値確認にoperator==を使いたくなるだろう。 >>327
それってダブルディスパッチの問題起きないの？ よく分からん揉め方をしているが、
俺は>>298の表現は極めて的確で分かりやすいと思うぞ。
俺はあれで納得だ。サンクス。一応言っておく。 >>327
RealクラスとComplexクラスを比較した時の振る舞いが直感的じゃなくね？ はてoverloadとoverrideは排他的な存在だっただろうか
ちなみに規格で::newはreplace, displace
overrideとは言わない >>333
その場合はオーバーロードよりも強力なダブルディスパッチを使うのが妥当だった。すまね。 まだおまいらオーバーなんちゃらで言い争っているのかｗ >>332
operator newって仮想関数にできなくない？ なんでオーバーライドが的確なの？ >>336
言い争ってなんかいねえぜ
一部のアフォどもをこっちはスルーしてるんで争いになってない >>334
排他的くねなぜならシグネチャが変わらないオーバーロードは無いしシグネチャが変わるオーバーライドもこれまた無いからだ そうか？
https://ideone.com/VOwt42
これはオーバーロードかつオーバーライドだと思うが
オーバーロードは特定の関数について言及しているのではなく同一スコープに同一の名前が複数存在する状態を指すものだと思っとりました >>341
それは
上の方はオーバーライド
で
下の方はオーバーロード（を追加している）
でしょ
関数単位で見たら排他だと思う >>342
あー左様かvoid B::f(int)のオーバーライドとf()のオーバーロードが同時にありえるのか、
完全に排他的（背反）というわけでもないな
ただしそれぞれ独立な概念とは言える
なぜなら下記の4通り全ての組み合わせが有り得、互いの成立要件に他方の成立の真偽が関係しないだから、
1. オーバーライド∧オーバーロード
2. オーバーライド∧¬オーバーロード
3. ¬オーバーライド∧オーバーロード
4. ¬オーバーライド∧¬オーバーロード 訂正
△： ただしそれぞれ独立な概念とは言える
○： ただしそれならそれでそれぞれ独立な概念とは言える 同じ名前の関数で、引数が同じならオーバーライド、 引数が違えばオーバーロードだよ？
そんなに難しい話じゃないはずだった気がしたんだけどな。 >>345
usual な operator new は、いつも
void* operator new(std::size_t);
というシグネチャなのに、なぜオーバロードなのか
という話題だったのでは？ 「同じ名前の関数で、引数が同じならオーバーライド、 引数が違えばオーバーロードだよ？」
これまた珍説を >>347
＞引数が違えばオーバーロードだよ？
演算子のオーバーロード みんな人に説明できるだけのまともな言語能力を備えてから来てくれ
あとクソみたいな反論をするのもやめよう >>348
それは>>298と>>319を読んだ上で物申してるのかね constオブジェクトのデストラクタって
一般に中で非constメソッドを呼んでいるのに
なんで合法に呼び出されるの？
それとも合法に見えるのはVC++固有？
プロセスが死ぬまで破棄されないのが正しいロジックなんじゃないの const の考え方には logical const と bitwise const があって、
logical const を実現するために言語としては bitwise const を基本として要求してる感じ。
logical const ってのは論理的な const 性で、
bitwise const ってのはビットパターンとして不変ってことね。
mutable キーワードを付ければ const なメンバ関数からも操作できるデータメンバを
作れるけど、これは bitwise const でなくてもよくなるだけで
logical const であることは要求される。
(その性質を満たすようにプログラマが配慮しないといけない。
コンパイラは面倒みてくれない。
reinterpret_cast と同じくらいには危険で面倒くさいと思う)
寿命が尽きたオブジェクトにはアクセスは許されないから
もはや logical も bitwise も関係なく const 性は無意味になる。 >>354
>寿命が尽きたオブジェクトにはアクセスは許されないから
>もはや logical も bitwise も関係なく const 性は無意味になる。
これはだいたいﾜｶﾀ
前半はわからん
bitwise const でないオブジェクトがROMに割り付けられたり、とか、
bitwise const でないオブジェクトがmemcpy()的手段で同じビットパターンに繰り返し上書きされるみたいな
処理があったりするとbitwise constでないことは致命的だが
それ以外のケースではconstといいつつクラス内部ではmutableな扱いであっても全く実害無いんじゃ…
ていうかそもそもC++の非PODオブジェクトに対するconstはbitwise constなのかかなり疑問が、、 >>355
logical const であれば性質として充分だよ。
だけど、それをコンパイラがチェックすることは出来ないから、
原則としては bitwise const を要求して、
それがちゃんとできてなけりゃエラーも出す。
だけど、 bitwise でなくても logical に出来る場面では
プログラマの責任でやるよっていうのを mutable キーワードで表すってわけ。 おい、mutableなんてキーワード初めて知ったぞｗ
ググってみたらC++11から導入されてたんだな知らんかった、、、 >>359
ANSI で規格化された最初から有ったがな (´・ω・｀) 「C++の非PODオブジェクトに対するconstはbitwise constなのかかなり疑問が」
標準レイアウトではないconstexprなオブジェクトはビットレベルでconstなのだろうか
constexpr struct A { constexpr A()=default; int m=1; private: int n=2; } a;
確かに疑問だ どんどんキーワードが増えるのは思いつきで仕様を決めてるからだ。
無能SEの下のプロジェクトではよくあること。
50年は仕様を追加しないつもりで仕様を決めてほしい。 コンピュータを取り巻く事情は予想の斜め上をいく形でどんどん変わるのに言語だけのんびりしとれるかいな 永久に仕様が追加されない言語なんてたくさんあるから好きなのを使いなよ
機能が必要になった背景やそれを追加することが適当だという根拠まで知ってろとは言わないからさ 雑魚に上から言われる筋合いはない。そんな態度だから囲まれて職質されるんだよ。 つ、追加しなくても1.5年待てば倍速くなるもん…！
ていうかメモリバリア周りの扱いが未だに規格化されていないのは言語としてはお寒い状況だといわざるおえない
ゆくゆくはOpenMPIを正式に取り込んでキャッシュスヌープ無しのメニーコア環境でも
最高のパフォーマンスを発揮できるだけの選択肢をプログラマに提示し、
さらにはGPGPU対応もしてﾎｽｲ、 ｽﾏﾝOpenMPIはOpenMPのつもりで言った！ openmpみたいなマクロまみれよりtbbのほうが好き そんなに新機能を追加したいなら、新しく別言語を創れ。JavaやC#みたに成功して普及した事例はいくらでもある。
一度普及した言語に、碌に実務でコードも書いたことないような輩が後からやってきてデタラメな糞仕様を追加するんじゃない。 ■ このスレッドは過去ログ倉庫に格納されています
