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 >>191
BASICは再帰できたぞ
FORTRANを実装できないマシン用に作られた縮小版で、
でもFORTRANより新しく作られた分、改良が図られていた
そのうちの、すべての行に行番号というのが賛否両論だった
当時初心者だった俺にとってはあれがラベルの概念の入り口になってくれたが
1桁KBのパーコンで構造化などという寝ぼけた老害たちがGOTOがどうたら言ってた
あ、嫁が呼んでるw じゃあな >>192
BASIC で再帰ができるのは,ハドソン系ベーシック等,マイクロソフト以外の BASIC ではないか? メインフレーム用の一部の言語が再帰できないのは
当時のS/370がスタックのないアーキテクチャだったからだ
逆にBASICが実装された多くのPCではCPがにスタックを持っていた
なので全変数がグローバルなのでやりにくいができるにはできた
俺もBASICでの再帰は大道芸の域を出ることがなく
実用上の手の内に入ったのはCからだった >>194
> 全変数がグローバルなのでやりにくいができるにはできた
これは一般的には出来るとは言わない。
再帰が出来る=関数ローカルの変数が定義出来る、だよ。
変数共通で突っ込むのは今なら「再入」と呼ばれる物に近く、
これは言語として云々ではなく、対応する構造にするかどうかだけ。
また、CPUのスタック操作命令は高速化に寄与するだけであって、
無ければエミュレートすればいいだけだろ。
その論法だとスタック操作命令がないCPUではC言語を実装出来ないことになるが、
これはないだろ。
(S/370上のC言語実装も無いとは思えないし) >>196
そこは俺とは見解が違うね
再帰の定義はサブルーチンの中からそのサブルーチンを呼び出すことで、
それをやりやすく補助する存在は本質じゃない
なのでスタックですら再帰の本質ではない
マシンによってはサブルーチンのネストが6層までとか限定されていて
それは何かというとリンクレジスタの個数でありスタックじゃない
再入は共通変数なんか使わないし、使ったらRENTじゃなくなる
メインフレームの流儀ではいちいちGETMAINとかね
メインフレーム上のCの実装は、俺が目撃したのはS/370じゃなく
ESA/370だったけどいちいちGETMAINはしてなかった 秀和の解析本にはBASICのくせにunwindがあるぞってなのが載ってたね >>197
> 再帰の定義はサブルーチンの中からそのサブルーチンを呼び出すことで、
> それをやりやすく補助する存在は本質じゃない
これは屁理屈だ。
なぜならこの定義では、「再帰出来ない」言語なんて無いから。
再帰出来る/出来ない『言語』を議論している時点で、この定義は無意味で、
「普通に再帰を記述した時に問題なく動くか」が議論用の定義になる。
これは当然であり、自明だ。
つか、君は何が言いたかったんだ?
君の定義ならCOBOLだって再帰出来るだろ? 再帰アルゴリズムを繰り返し(ループ)アルゴリズムに変換することは普通のアーキテクチャー上では常に可能、
再帰回数に応じて新規のメモ化用領域を本質的に必要とするという重症なケースでも、最悪配列が使えればどうとでもなる、
>>197
メインフレームってグローバル変数として配列とか確保できなくて
いちいちGETMAINするしかないのスゲー
>>199
System/370で動くGCCの実装があったと聞いたわ(ただし今はSystem/390が動作下限とのこと)
再帰ができるかどうかはしらんwwwwwww >>199
> 君の定義ならCOBOLだって再帰出来るだろ?
(当然だが当時のCOBOLは)できないよ
戻り番地を1つしか覚えてないのでネストしたら戻れなくなる C++17ドラフトのguaranteed copy-elisionが難しい
しかも規格が約50カ所修正されている
A a = A{}; と A a = f(); のムーブ無くすだけでどんだけ根本概念に手を入れてんだ >>199
だから見解が違っているねと言ったろ
アセンブラは再帰できるのか、できないのかという問いと、
COBOLは再帰できるのか、できないのかという問いに、
同じバックボーンで答えることが俺には出来ないが
おまえさんには出来るということだろ?
>>200
bfdではi370だね 犯人扱いしておいて違ったら知らん顔という制度そのものが間違ってる
捜査協力した人には謝礼だろうが
にせ伝票で架空の謝礼費を着服なんかしてないで
やるべきことをやれっての! 架空の謝礼費を内部告発した仙波さん、えらい扱い受けたよね C++の最新仕様を追い続けられる人ってのはやっぱどこかちょっと変わり者というか
ふわふわしたものが許せないというか、なんとなく動いてるからいいや的な緩さが
許せないというか、白黒はっきりつけようぜ的な性格なのかな?って思ったw たったの千円でも知らん顔とは次元が違う
謝礼の対象でないという取り決めがあるばかりに
警察官の横柄な態度を誘発しているんだよ >>208
たかだか3年に1度の更新がそんなにしんどいのかよ
追い続けるもクソもねえ
重箱の隅をつついても1冊程度にまとめられる量しかないのに 最近は生ポインタ撲滅されそうと聞いたが
今までのメソッドとかどうしてるん
混在してるだろ プロパティーいつ実装されるのやら
getsetくっそマンドクサ >>208
ほとんどが待ってた機能だぜ?
言語仕様だけでなくライブラリまで
おまえろくすっぽC++使ってねえだろ VSのインテリセンスさんだって
いまだについていけず
ポンコツなエラー吐きまくってるわけだし
まだまだ大丈夫! >>210
>重箱の隅をつついても1冊程度にまとめられる量しかないのに
お前は本を出したことないから「1冊程度にまとめ」るのがどれだけ大変か分からないだけ それが本当なら恥ずかしい見積もりミスしてんぜおまえさん >>217
本を読む、理解する側の分量の話をしてるんだから、まとめる側の労力が大きいかどうかはどうでもいいのでは? 雑誌ってエロ本か何かだろどーせ
技術系の雑誌やっててあーゆーバカ言っちゃ自殺もんの恥だぜ >重箱の隅をつついても1冊程度にまとめられる量しかないのに
その一冊程度の更新に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
ほーお、おまえさんは定義が読めないと判断できないのか
普通の人は宣言まで読めれば判断できるんだがw
逆汗読まないほうがバカガキ
バカガキからみて普通の人は老害というだけ 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
アフォwww
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, 尻尾付き:メンバ変数
とかは良くやるな ■ このスレッドは過去ログ倉庫に格納されています