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 >>138
そのサンクらしきものはどこのセグメントに置くの？ >>143
MFCのどのクラスに動的コード生成の実装が書いてんの？ >>145
なんで急にキレるんですか？
あなたがソース読めとアドバイスしたからMFCのどのソースか聞いただけなのに。 理解しようという気持ちも理解する力もないのに質問すんなよ…
mfc ではやってたっけ？やってないんじゃないの？
というツッコミならともかく、
>>141>>142なんて思考力が虫以下だろ…どこのセグメントとかアホか
Win32 は古来よりフラットなリニアアドレスモデルだろ。
VirtualAlloc も知らなそうだし。 質問だと思ってる時点で低能確定やん w
まあセグメントと聞いてセグメントレジスタしか頭に思い浮かばない低能はROMってろ >古来よりフラットなリニアアドレスモデル
まさかそっちのセグメントに反応するとは予想外だった >>148
だいたいあなたがMFCの頃から動的コード生成でやってたって言い出したんですよ。
だから私はMFCにあるのはインスタンスの動的生成だという指摘をしたんですよ。
そしたら、再度あなたがATLのような実装があるんだと言ったんですよ。
ソース見ろとか言う人までいるから、どのソースか聞いたらキレて、なんで言い出したおまえまでキレんだよ。アル中か？
ここは相談室だぞ。 C++を身に着けたいと思いつつも、自分でC++で何かを作るモチベーションが湧かなくって、数千行程度のC++プログラムの写経でもしようかと思ってるのですがおすすめありませんか？
SDLを使ったゲームとか興味を持ちやすくて写経しやすいかと思ってgithubとか漁ってるのですがなかなかいいのが見つからなくて悩み中です
QtみたいなC++を拡張してるのは勘弁です あなたが何に興味を持つかなんてわかりません
C++以外の技能は？ てんそるふろーでも読んでみるとか。
今を時めくフレームワークだよ。 クソだと思うやつを俺が叩き直してやるってやっていればそのうち上達してる >>156
思いっきり叩いてやるからまず自分が書いたソースをどこかにアップしろ 他人に使わせる気のないコードなんていくら書いても意味ない
ソフトウェアとして公開して叩かれろ >>159
＞他人に使わせる気のないコード
どうすれば他人に使わせる気満々のコードになるのでしょうか？
ソースを公開する以外に何かしないといけないのでしょうか？ 使いたくなるか否か、それを判定するソースコードを見せてくれれば一番早い
そしてそのソフトウェア自体をその判定にかけると得点はMAXになるのは当然 >>160
・OSSライセンスを適用する
・有名処のOSSホスティングサービスで公開する
・ソフトウェアの目的と利用方法を理解しやすいようにドキュメント化する
・CPUやメモリなどのリソースを効率よく使用する
・汎用性が考慮された作りにする
・特殊化も考慮された作りにする
・バクが無いようにする
・こまめに更新し継続して改善されている事をアピールする
このくらいやれば他人に使わせる気満々のコードに見える >>163
なるほど
でも >>158 をやる気満々で公開しようと思ってもアピール点が見つからないんです
「C++ だけで簡潔する多桁演算」というのは訴求ポイントとしてはどうなんでしょうか
誰かやってるかどうかはさておき、魅力的がどうかは気になります 右辺値参照がやっぱりわからん
template<class T>
void test(T&& t) {
f(std::forward<T>(t))
}
このstd::forward<T>(t)は左辺値なの？
名前持つt(左辺値)を転送してるから左辺値でいい？
f()はf(T&)を呼ぶであってる？ C++11,14を勉強するのにいい本おしぇーてください。 >>166
forward<T>(t)はtをTの右辺値参照にキャストして返すんだから
f()はT&& tを受け取る(f(T&&)が呼ばれる)んじゃね？ >>166
それはforwarding referenceという機能を使ったperfect forwardingというテクニックで
右辺値参照を理解した先にあるものだ
右辺値参照の勉強中なら今は気にせず忘れておくもので
右辺値参照を理解してるなら右辺値参照とは別物として新たに勉強しなくてはならないものだ >>170
やっぱり右辺値参照へのキャストか
左辺値参照ぽい動きなんで質問してみた。ありがと
>>171
俺にはforwardはまだ早いってことスね
まずforwardなしでもう少し考えてみるわ >>166
もとの test という関数が右辺値、左辺値どっちでも引数に取れる、そして std::forward でそのまま転送している
f がとる引数の型は test がとった引数と同じ。
つまり答えは実引数次第だ。 死んだ？
むしろ他の提案が出ておちつきそうだったのに
自尊心を傷つけられたと感じたハゲがゴネだして蒸し返えされたような >>175
あんた詳しそうだな。今どうなってるの？？
猛烈にほしいんだけど、サクッと入らんかな？
詳しいリンクとかあったらいただけないでしょうか。 >>176
すまんが別の提案と間違えた。忘れて
open-std.orgのWG21のpapersの2016のP0251R0が最新ではないだろうか
何の動きもなくC++20ドラフトN4687にも入っていない 3年毎に膨らんでいく仕様とか嫌だな
そらリナスさんもブチキレますわｗ >>177
あぁ、情報ありがとう。やっぱ死んだままか。
手間かけさせてゴメンね。
やっぱコンセプト無いとコードサジェスト爆発するから気に入らないんだろうなぁ。。。 トーバル君は単に自分のニーズに最適な言語はCと言っているだけで
他の言語がどうなろうと知ったこっちゃないでしょ
それを周りのアフォどもが色々押しつけに来ることに時折ブチキレるだけで スキルの差によって読める、読めないの差がありすぎてもはや言語としての体をなしていない。
コンパイラによってもコンパイルできる、できないの差も激しい。大きなプロジェクトを管理する側はキレて当然。
癌のように誰も望んでない仕様拡張が続けられている。 メイヤーズがこっそりc++とバイナリ互換の新言語を開発している…と信じたい そのバイナリ互換ってなに？
C++11 以降で、役に立つ仕様とどーでもいい仕様とをわけるとすれば、何？ >>181
誰も望んでいない仕様拡張？
autoは？ range-based-forは？ R"リテラルは？
initializer_listは？ ラムダ式は？ template parameter packは？
<random>は？ shared_ptrは？ <regex>は？ <system_error>は？ >>181
ふつう、どの規格を使うかとか、場合によってはどの開発環境のどのバージョンを使うかまで
プロジェクトで規定するものだろう。
決めたことと違うコードを混ぜようとするメンバーがいたりしたらキレてもいいが。 少なくとも個別の提案はプログラムが読みやすくなるし楽になる方向なんよね。
だからまぁ、 >>181 の言い分にある「誰も望んでない」という言説には違和感があるな。
嫌だという人がいるのはわからんでもないが、
勝手にユーザ全体の意見を代表してしまうやつは単にクズなので、
誰も耳をかさないよ。 >>181
> スキルの差によって読める、読めないの差がありすぎてもはや言語としての体をなしていない。
日本語(自然言語）でも同じだろ。
馬鹿と天才でおなじ結果（コード）にしかならない、という方が問題だ。
それが天才側に揃っていれば理想的だが、実際は馬鹿側に揃うわけだし。
>>186
> 少なくとも個別の提案はプログラムが読みやすくなるし楽になる方向なんよね。
これは同意だが、問題は一部が本質的なところ（骨組み）まで変えられる程な点だろ。
現実的には>>185のようにプロジェクトリーダーが何を使うか厳密に決めればいい話で、
Linuxの場合はCだ、って言うんだから他の奴が布教しなければ丸く収まる話だ。
とはいえ通常製品の場合は「何でも出来る＝何にも使えない」ではあるのだが、
C++の場合は半製品（製品を作る道具）ではあるし、
実際、機能はあった方が便利だったりするので、（使う側がどこまで使うか決めればいいだけ)
プロジェクトリーダーがしっかりしていれば、現在の貪欲な拡張方向も悪くない。
「全部の機能を使わないといけない」と信じている馬鹿と初心者は混乱するだろうけどね。 >>188
>「全部の機能を使わないといけない」と信じている馬鹿と初心者は混乱するだろうけどね。
残念ながらこういう人たちは少数派ではないのだよ。。 >>188
馬鹿側に揃えるポリシーを見事なまでにやってのけた言語と言えば。。。
IDENTIFICATION DIVISION.
再帰できない、ダミーセクションできない、動的記憶ない、オラこんな村いやだ♪
で、その結果なにが起きたか。。。
エロパブの嬢がどこかで見覚えのある顔だと思ったら、うわあ（ｋｗｓｋはガン無視します） >>190
COBOLの事か？だとするとあれは試行錯誤の結果だ。非難されるべき物でもない。
そもそもあの時代の言語は再帰出来ないのも多かった。Fortran77もBASICもそうだろ。
俺が思うに、第一世代言語(C以前）は「プログラミングとはこうあるべき」、
つまり、プログラミング自体を規定しようとしている。
COBOL：自然言語の仕様書がそのままソースになるべき
C：所詮アセンブラ
smalltalk：オブジェクト間のメッセージングこそが真の未来
Lisp：ラムダこそ真理
BASIC：馬鹿でも使えることが重要
Fortran：所詮計算機だろ
で、C以外が全部糞だったのでCで統一された。
当然第二世代言語はCの後継で、C++/Java/C#のような面子になる。
とはいえ、COBOLの方向性は間違いでもないよ。
ソース自体が可読性のあるドキュメントであるべき、ってのは今でも理想だろ。 >>191
BASICは再帰できたぞ
FORTRANを実装できないマシン用に作られた縮小版で、
でもFORTRANより新しく作られた分、改良が図られていた
そのうちの、すべての行に行番号というのが賛否両論だった
当時初心者だった俺にとってはあれがラベルの概念の入り口になってくれたが
１桁KBのパーコンで構造化などという寝ぼけた老害たちがGOTOがどうたら言ってた
あ、嫁が呼んでるｗ じゃあな >>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が動作下限とのこと）
再帰ができるかどうかはしらんｗｗｗｗｗｗｗ >>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++の思想的に望ましいのでは… ■ このスレッドは過去ログ倉庫に格納されています
