C++相談室 part136
■ このスレッドは過去ログ倉庫に格納されています
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part135
https://mevius.5ch.net/test/read.cgi/tech/1522495206/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.102【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1509780815/
■長いソースを貼るときはここへ。■
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 >>436
結城ならば簡単なJava だから、C++ の知識で Java の字面は追えますよ(なんとなくわかる)
私は結城 Java を C++ に書き直して習得しました C#やJavaが動くのにC++を使うのは辛い。非常につらい。絶対にやめたい。にも拘らず
未だにC++を進める人がいるのは残念だ。
一方C++は組み込みには非常に威力を発揮する。しかし組み込みではいまだに90%
の人がCを使う。それはなぜなのか?
CとC++ではスッポンと月ほどの違いがある。しかし残念ながらそれは
C++をフルに使える場合であって、フルに使える場合ならC#やJAVAを使った方がいいわけで
フルに使えないケースであるからこそ、C++を使うのが正しいのであるから、やはりC++は
Cに比べて月ほどではない。しいて言えば月というよりは牛だろう。ともすれば牛よりも
スッポン料理が高価なように、月になれるのに牛ではやはりかなり残念なのである。
どういう切り口でも残念な言語、それがC++だ。 C++開発をした人がC++の本を書いていて、先輩に「読め!!!」と勧められたので読んで
みたが非常にわかり難い。こんな頭の構造をした人が作った言語だからきっとわかり難いの
だろうと思う。一言でいうと簡単なことを複雑に説明する。
C++という言語もアフォほど簡単なことをやたらと複雑に書かなければならないことが多い
という気がする。 Headerファイルにメソッドを書かないスタイルは誤りだ。
理由
1.C++以外でそんなスタイルをとっているものはない。
2.なぜならメソッドも実体ではなく型だからだ。分離するメリットはないがデメリットは多い。 >>446
コピペかと思ったけど違うのか
何でC#を使うべきケースとC++を使うべきケースを分けられない人が出てくるんだ?
インタープリタやC#やらがクソ簡単に書けるのはその下で煩わしいことをやってくれてる人がいるからだ 最近の勘違いしたアホ機能テンコ盛りのC++。なんでも書けますよ。 c++が複雑なのはわかるがどんどん簡単に書けるように進歩してるだろ。
autoとかrange-based for loopとかconstexprとかlambdaとか。
他の言語並みに簡単に書けるようになるのはまだまだかかるとは思うが。 使う気ないですけどね。速度が速くならないならいらないです。
使い捨て、楽したいならC#で十分ですからね。 >>454
今どきはtypedefじゃなくてusingだしconstは実体が増えるからconstexprにするべきだと思うのだがどうだろう? セットする値に singned int の範囲しか使わないなら、static const 定数じゃなくて enum でOK。
enum なら constexpr すら要らない。 enum baseってlong long使えないんだっけ? >>444
Javaは高価な機器を買わせるためにデザインされた言語だから用途が違うけど、他はソフトウェアを作るためでは? C++やるのにテンプレート使わないなんてただのマゾプレイ 小規模マイコンのソフト開発なんて
全てがマゾプレイみたいなもんだから
それでもCよりはC++の方が便利 >>462は正しいと思うけど>>461のようにテンプレートだらけになるのはどうかと思う Expression templateでmatrix乗算、それが無理ならベクトルの内積
(それもコンパイル時計算じゃなくてコンパイラの遅延評価を利用して
一種の構文を記憶したもの)を計算するETを解説してるところしらないかな。
ベクトルのETによる遅延評価計算はC++テンプレートテクニックあるから
いいけどさ。
Matrixがわからんのよ。uBLAS、MET、TVMET探してもそれらしきソースコード
が特定できん。 Expression templateは本命じゃない。難しすぎる。でも演算子オーバーロードの
弱点である一時オブジェクトによるロス(a*aみたいな乗算も含めて)を解決する
方法を20年以上前に考えたけど、それと速度を比較したい。 ユニバーサル参照で一時オブジェクトの問題は片付く? 売ってる車輪の中から探すよりも作った方が早かったり安かったりぴったりな車輪になったりする アプリ次第じゃね。
数値計算やアルゴリズムやってると、リソース、速度、必要精度に応じて、整数、浮動小数点、多倍長整数、有理数等々に対応できるように作るから、むしろテンプレしかない。 >>470
うまい。プログラムがテンプレートだらけになってる奴は必死にマイレゴブロックを作ってる。
stl、boost、atl、既成レゴブロックは数多く提供され使われてるのだ。
そんなに理想の車輪がほしければ、
それこそ新言語を作ればいい。C++にアホ機能追加してる糞どもに言いたい。 >>473
C++03を使い続けたいのなら使ってもいいんよ。 >>473
何言ってるのかわからん
stlやboostはブロックを作るための材料くらいの位置づけだぞ
テンプレートがstlのような比較的低レイヤーなところでしか使わないとでも思ってるのか
レゴブロックと言ってるのは大量のモジュールを読み込んで継ぎ接ぎしてるようなJSやPythonのコードのことだ うちの会社にもなんでもテンプレで作りたがる奴いるけど、
調べたらほとんどのテンプレが一種類の型でしか使われてなかったw >>472
色々に対応できるライブラリは動作が遅い
スペシャル版が最強 そして変更に弱いコードが量産されて最後にはお手上げになると
親の顔より見たわ >>474
過去の大量のC++コードを全否定する機能を追加するなら新言語にすべし。
Java、C#みなそれで成功している。C++の名前を借りないと使ってもらう自身がないならキミは向いてない。 提案書を読めば分かるが基本的には問題点を解決するためのものばかりなはずだがな クソみたいな汎用化はいいからまずは一つの機能の関数をまともに書けと言いたくなるバカは確かにいる。 それ。C++は当初から問題ある欠陥言語だから、素晴らしい新しい言語を作るべき。
古い大量のコードはもうどうにもならない。誰も更新費用の予算を計上してくれない。
COBOLと同じなのだ。老人のおれはC++と心中する。
おまえら若者は新しい船で新しい世界に旅立ってくれ。俺の屍を越えてゆけ。 >>477
そうならないのがc++のtemplateなんで。。
それでも型によってかき分けたほうがいいところはTMPなり特殊化なりすればいい。 C++に取って代わろうとした言語はみんな死んだか別の路線を走ってるよ 老人はC++03と心中してくれ。俺はC++14以降の船に乗る。 >>486
スマートポインタは使わせてほしいのですが… vectorはdata()が連続した領域を返さないといけないのが大きな制約になってるかも。 それがなくなったら、もはや配列ではない
配列を使うべき用途で出番を失う 一応連続した領域を返すと保証されたのはc++03から 保証されてくれないと困るから保証されるようになったんだぞ >>484
テンプレートは魔法じゃない
同等の速度を出す為には結局全て特殊化することになるし、
インターフェースも型によって違う方が良いこともある
性能、リソース、...
突き詰めれば全て特殊化
テンプレートは妥協だ 妥協というより補助だろう。
templateだけで解決しようとすれば特殊化だらけになるのは当たり前の事 cstdio と STLの連携を深めて欲しいね。
・FILE* に basic_string をバッファとして渡してメモリに読み書きする機能が欲しい。
・fgets() で得られた文字列長を再計算するコストが無駄なので、文字列長も取得できる機能拡張関数が欲しい。
何らかの処理の過程で副産物として得た文字列長を捨てて、別の場所で文字列長を再計算する無駄は、かなり多いと思う。 templateはポリモーフィズムを実現するための実装の一つです
>>495
c_str()で渡せばいいのでは >>496
基底クラスのポインタで複数の派生クラスのポインタとして振舞えるの?
template を使ってポリモーフィズムを実装できるとでもいうの? >>496
FILE*を使う関数にbasic_stringをc_str()で渡すのではなく、
setvbuf() のようにFILE*の内部で使うバッファを basic_string に置き換える意味で言いました。
fprintf() でbasic_stringに書き込むことが可能になるイメージ。
C++にはpopen()で開いたパイプFILE*に相当するiostreamがないのでこれで代用可能。 >>497
コンパイル時にテンプレートパラメータでポリモーフィズムする >>499
template を使ってのポインタがポリモーフィズムを実現できるとは思えないのですが… templateはポリモーフィズムの実装ではなくポリモーフィズムの利用が仕事。 >>497
ポリモーフィズム=継承ではない
継承もポリモーフィズムを実現するための手法の一つにすぎない
ざっくり言えば同じ名前で異なった振る舞いをするもののことを言う
関数オーバーロードもポリモーフィズム 詐欺師が「○○を実現できます」と言った時、実際には「他人の作った○○に便乗します」という意味であることが多いから、あながち間違いでもない。 >>498
boostで似たようなことができる
http://www.cplusplus.com/forum/general/16532/
これをうまいことラップして
pstream ps("ls");
ps >> str;
みたいに動作するstreamを作ればいい >>505
情報ありがとう。
欲しいのは逆パターン。CをC++でラップするのではなく、C++をCでラップする感じ。難しいか。 >>503
>関数オーバーロードもポリモーフィズム
関数オーバーロードはコンパイル時には(どこからどこへコールしているかが)確定しているものですね
そういうものに「ポリモーフィズム」を当てるのは抵抗があります
もっとも wikipedia をみると、私の考えているポリモーフィズムは「部分型付け」(subtyping/inclusion polymorphism) としてサブクラス化されています
これは私の認識を修正しないといけない… 意味の広い英単語を、ものすごく狭くて極端な用例の一つに限定して和製英語化しちゃう日本人のいつもの得意技
ポリモもその犠牲者の一つ Ad hoc polymorphismのページでは2つの要素を+演算子にかける関数がpolymorphicなものの例として書かれてるね
https://en.wikipedia.org/wiki/Ad_hoc_polymorphism 拡大解釈すればできちまうものだからな
いくらでも俺様解釈し放題
それを聞かされている衆目がついていけないと言ったとき
強弁するやつと謙虚なやつでリトマス試験紙みたいになる もともとプログラミング言語の理論の方から出てきた言葉なので拡大解釈ではないでしょ
オブジェクト指向言語がそれらの理論から引用してオブジェクト指向におけるポリモーフィズムとは継承とオーバーライドによるサブクラス化のことだと言っているだけ >>486
その理屈だとc++20が出るからお前も十分老害だよ。
てか仕様が決まった言語使ってるのは老害ってことになるな。 個人的にはどっちかというと「動物ってのはワンワン鳴く奴のことだろ?猫や馬まで動物と呼ぶのは俺様解釈の拡大解釈」
って言ってるような滑稽さを感じる >>513
「老人はC++03と心中しろ」が「仕様が決まった言語使ってるのは老害」になるて…
倫理ダメダメやな
それでプログラム書いてんの?だいじょうぶ? >>516
"以降"が解らないのにC++で判定文書けるん? C++11以降で書かれたコードがほとんど増えていないという現実。 GCCもClangも、VC++でさえ10年近く前からサポートし続けてるのにまだ足りないと申すか 昨今の潮流はオブジェクト指向と関数型のハイブリッド
この二つをどう摺り合わせるか、どの言語もまだ明確な回答が出ていない
もちろんC++も アクセス権つき構造体とユニファイドコールシンタックスで疎結合オブジェクト指向だ。
と考えたのだが、ユニファイドコールシンタックスが死んでしまった。 ifdefできるだけなしで
どんなコンパイラでも通って同じ動作するコードを書けよ
コレは命令だ お前は本当にそんなにコンパイラを使い分けてるのか? 最低限、実機で間違いなく動いて
シミュレーターで間違いなく動くようにコード書きなさい
コードはいろんな実機をサポートしないといけない
実機ごとにOSも違う ICE上でのみ動作するコード
MIRACLE ON ICE 関数型も40年前からオワコンという現実を見ようよ。
5chのスレも全く伸びない。10年で1スレ消費できないレベル。 スレが伸びないのは難し過ぎるからじゃないのか
オブジェクト指向なんかはニワカが口を挟みやすい
あれやこれやと語ることがあると自転車置き場のごとくスレが伸びるんだよ 数学板とか物理板の質問スレで2chに失望し、それ以降2chで理系関連の質問はしないようにしてる >>532
稀に神回答がつくのを期待するしかないのです クラス/構造体の非静的メンバ変数/関数へのポインタ宣言 ってのを初めて知ったんですが、
これはどういう活用方法があるんでしょうか?
struct S { int data; };
int S::*d = &S::data;
S s1 = {999};
s1.*d; // → 999
s1.*d = 123;
(参考: 改訂第3版 C++ポケットリファレンス p.39)
上の例だと、 s1.data の別名以外の使い道がないように見えます。
長い長い真名の時は局所的に略記できて便利とか?、まさかそれだけですか? なんか昔同僚がメンバ関数へのポインタ使ってて納得した覚えがあるが
なんで納得したのかはもう忘れた >>535
動的に呼び出すメソッドを切り替えたいとかだね〜 >>535
そのとき S が int 型のメンバを持たなくても int S::*d という変数宣言が許される。
(無理矢理な型キャストをしない限りヌルしか入れられないけど。)
つまり、 S がプリミティブな型でなくクラスであるならば、メンバにかかわらず int S::*d は許容されて、
プリミティブな型だったらエラーになる。
この性質を利用して SFINAE で切り替えれば、与えられた型がクラスであるかどうか判定するものを作れる。
それが >>538 の言う is_class の実装に使えるって話ね。
まあ今なら is_class を使えよって話だから普通のプログラマ的にはどうでもいいけど。
回りくどい利用法なんだけど、まあ実際のところ実務の中で必要とする場面はそんなにないから、
この利用法が代表的なものとして紹介するしかない。 初心者の質問に答えていただき有難うございます。
動的にメソッド切り替えは実際に動かして理解できました。
SFNAEで切り替えの方ははコンパイル通る形にはできてませんが概要は理解できました。 メンバ関数ポインタがあの形になってるのはまあわかるから
変数もおまけで同じ形にそろえたのかな > 実務の中で必要とする場面はそんなにない
データメンバはともかくメンバ関数へのポインタは必須だろうが ■ このスレッドは過去ログ倉庫に格納されています