C++は難しすぎ 難易度:4
■ このスレッドは過去ログ倉庫に格納されています
>>530
紹介されたページを読んでみたが、C++の入門書じゃなくて
プログラミングの入門書で使用言語がC++って本みたいだね。
あと、内容が難しいんじゃなくて、内容が酷いという意見。
これから訳書を売り出そうってのに原書をボロクソに貶すとは
思い切った人だわ。それだけに信憑性も感じるけど。 「内部コンパイラエラー(ICE)に関するものなど深刻なものを含む110以上のバグが修正されている」
GNU Project、バグを修正した「GCC 6.2」リリース | OSDN Magazine
https://osdn.jp/magazine/16/08/23/160000 よく知らないけどテンプレート機能ってマクロみたいなものだよね
マクロを読んで理解したりマクロで展開されたコードを読み下すのって地獄ちがう?
LISPの同期しながらネット上でやり取りするコードもマクロを使っていて
生成されたコードがボリュームテンコ盛りかつなにやっているのか意味不明な難易度だゲンナリすると言う
理解できないー学習に剥かないー当然不具合の発見も困難な感じ >>533
マクロだと地獄になるから
そうならないようにしたのが
テンプレートじゃね? マクロ地獄から抜け出せたと思ったらテンプレート地獄に堕ちた、みたいな。 Cよりは簡単だと思うけどな
Cはいちいち「そんなのわかりきってるだろ」みたいなことまでつらつら書かないといけないのに
C++は簡明に書けるし
学生時代にCのレポート書いてるときにめんどくさくなって、楽だからって勝手にC++で書いてたら、しばらく担当教が授気づかなかったな
すっかりCの仕様忘れてしまった。
CよりC++の方がずっとわかりやすくない? 書くのは楽でも読む方は苦痛ってプログラムになってそう。 list実装してこいって課題でstd::list使うマンやってたなーw ラムダでつまづきました。
どこかよいサイトか書籍ありませんか? >>540
「ラムダ式 C++入門」っていうサイトが分かりやすいよ。 自分で書ける程度にはなったが
読める程度には至らない。
知らない機能、文法が多すぎる。
入出力イテレータなんて使った試しがない。
STL難しすぎ。 C++ほど機能が煩雑な言語って他にあるのか?
テンプレートやスマートポインタのような基本的機能もそうだが、
戻り値の型に依存した例外処理、引数の参照渡し、new()との相性の悪い*なしクラス型など、
後発の言語が採用しなかった一貫性の無い仕様や、
#defineマクロ、グローバルstaticやヘッダとソースの分離などの70年代の因習をそのまま残しており、
しかもC時代に由来するmalloc/free、typedef struct、グローバル関数などをそのまま使う人が多い。
標準ライブラリにもstdio/iostreamのような重複が全体に生じている。
それに加え、ラムダ式やジェネリック、右辺値参照、constexprなどの機能拡張も進んでいる。
STLやBoostなどのライブラリも加えればきりがない。
そのくせまともなガベージコレクションはない。
実際のプログラミングではコーディング規約で一貫したルールを定め、余計な機能は使わないようにするのが普通だが、
やはり現代的な言語に比べるとずいぶん使いづらい。組み込み用途、DLLやドライバの開発以外では用いるべきではないのかも。 スマホでマイクラがサクサク動くような時代にGC積んでない言語って正直厳しいと思うの…
それに組み込み系でも別にc++なんて使わなくてもcで足りるし
でもGCを積んだら積んだでc++の存在意義が薄くなるしそれなら他選ぶよってなるわ
objective-cとswiftみたいに代替言語でてくるかもしれんし(使った事無いけど)
結局所詮道具なんだからシンプルで扱いやすいほうがいいに決まってるんだよなー
c++erの行き着く先はスパゲッティ職人っすかね C/C++ は低級が売り
これ以上複雑にしなくていい GCなんて余計管理が困難になる気がする。
GCは不要。 objective-cは{}じゃなくて@を強制されてひたすら読みづらいし構文がクソきもいけど
そこらへんをc++かjavaに近づけて
appleじゃなくてWindows(とLinux)が採用してればobjective-c使ってたわ
どうしてもCocoaかiOS周りにしか使えないからクソなんだよなぁ
まあそれでもcのライブラリが潤沢だから使おうと思えば使えるけど
言語自体はシンプルだから、実質apple専用ってのが残念だわ
一応WinObj-CがあったりGNUstepがあるのはしってるけどmacosと同等につかえるわけじゃなし
swift完全移項して空気になってしまうなら悲しいなー 高級言語は高級側を目指せばいいけど、CやC++は低級を保ってほしい >>548
そういうとこにすら表れてるよな
物事を複雑にして喜んでるようなスジの悪さが
あんなクソみたいな表記のラムダ式持ち込んで一体何がしたいんや(笑)
右辺値参照(笑)ムーブコンストラクタ(笑)型推論(笑) >>553
それみんなコードが簡潔になる機能じゃん。 548 :デフォルトの名無しさん [sage] :2017/06/19(月) 09:36:34.36 ID:S/5ZPkdK
C/C++ は低級が売り
これ以上複雑にしなくていい 仕様が複雑だから理解できない、っていうのをdisる理由にされてもな。
コードが簡潔になる事が重要。 コードが簡潔になることを最重要項目としてほしくない、CやC++の役目はそうじゃない
という主張
アセンブラとの親和性、非常に低レベルな環境への対応、命令レベルの速度チューニング、...
そういう低級言語としての役目が重要であると >>557
C++ の時点で「アセンブラとの親和性」とかあり得ないんだが‥ メジャーなコンパイラですら規格に対応しきれてないのにさらに仕様を増やすとか、規格自体が目的になってる感じで
私自信は規格書も読んだり、積極的に新規格についていってるつもり >>558
C++とアセンブラの混合コード、よく書くけど >>560
それは extern C なんでしょ? 別に低レベル性を犠牲にしているわけでは無いのだからデメリットは無いでしょ
機能追加で便利になってるのに、何が複雑なのかわからん
仕様が理解できないって意味で複雑って言う主張なら、使うなとしか c++至上主義者達は難解なパズルを解いてエレガントにプログラムすることが全てで
可読性とかそういう他人のこと考えてないとこないですかね・・・?
追加する仕様の方向性もまさにこういうとこが見受けられるから文句も言いたくもなるわ〜
別にc++つかっててもできるだけシンプルに見やすいようコーディングしてる人は好きよー C++はF1マシンみたいなもん
ちょっと近所に買い物するのにわざわざF1マシン乗りたくないし
しかもC++は速いけど脆いマクラーレンかな?
pythonとかjavaが人気なのは
上質なリクライニングシートにクーラーとカーナビもついてるからなんだよなぁ プログラムは、小さくて速いのがいい。エレガント、可読性なんて二の次だ > 機能追加で便利になってるのに、何が複雑なのかわからん
そういう感覚なんだろうなw
何が複雑かのセンスがそーいう状態なんよ
俺が何を言ってるかも、多分分からんやろな C++の書籍って、浅い入門書か、すでに使いこなしてる人向けの高度な本の両極端なイメージ やはり、コードの字面から動作を予測しやすいというのがわかりやすいプログラムなんだと思う。
そういう意味で、テンプレート、オーバーロード、SFINAE、ADLなんかを駆使してドヤッてるC++プログラムは
マクロ使いまくりのLispやCなみにわかりにくい。 >>566
実用的かどうか。これに尽きる
自己満のゴミプログラムなんていらない 複雑と思うなら、その機能を使わなければいいだけでしょ
低レベルさに加えて、流行りの高級機能も使えるという、「選択権」があるのがC++の良いところなんだから
自分の理解不能な機能を見て、ドヤってると感じるのは劣等感じゃね?
もちろん、普通に関数作れば良いところでlambda使って無駄に読みにくくしてる人がいると言う事実には同意する 例えばマクロを多用したプログラムが理解しにくいというのと、マクロの機能を理解しているかどうかってのは別の話。
言語機能自体を理解していたとしても、わかりにくいプログラムはわかりにくい。
>>573にlambdaを挙げなかったのは、lambdaはそういう意味での分かりにくさは比較的少ないから。 >>575が一体C++で何を作ってきたのかが疑問だな
お前C++の良さを語れるような立場じゃねえよな 無理に使わなくてもいいというのは同意だけど
例えばメンバとして持つものにstd::tupleなど、ムーブをサポートしているクラスを想定して
ムーブコンストラクタ、ムーブ代入演算子など定義するけど
「それ以外ほぼ何もしない」クラス作ってドヤってる人(サンプルコードの話ではない)は最近よく見かけるんだよなぁ・・・w
セオリーや流行ばかり追いかけて実用性皆無なコードしか書けない趣味グラマ?ばかりが
最近C++界隈で目立っている気はする。
ある程度なんでも出来るようになれば言語のことはどうでもいいから、
結果そういうのばかりが目立ってるのかもしれんけど >>576
具体的に言うと、どの言語がわかりやすいの?
煽ってる訳ではなく、純粋に意見が聞きたいだけよん。 絶対的な順位というのは決められないだろうけど、少なくともCはC++より分かりやすいよな。
a = b + c;
こんなコード片があるとき、Cならここで数値かポインタの加算が行われると推測できるし、あとは
オーバーフローの可能性を気にする程度でいいけど(マクロが使われていた場合は別として)、
C++だと選択肢が多すぎて判断が難しい。下手したらコード全体を隅から隅まで調べないと実際の
動作を把握できないかもしれない。 書きやすいと読みやすいは別物で
C++はC以上に書きやすさを求めた結果
読み手に優しくないコードが書けるようになったのは事実だよね
精通すればスラスラ読めるようになるってんならまだしも
単なる独りよがりなコードも書けるから手に負えない >>580
ああそういう事ね。
確かにわかる。
まあ、その点だけで言うと、その operator を提供しているクラスを信じられるかどうかって点に行き着く気がするけどね。
プラスの意味論 (セマンティクス) に逆らう機能を実装するような、質の悪い設計なのかって言う点から、実際ちゃんと動くのかって点ね。
セマンティクスに逆らわない機能で、単体テストされていれば、基本的に疑いの眼差しを向ける必要はないはず。(カプセル化) >>581
ああー、同意。
うまく使えば読みやすいのに、慣れない人が使うと酷いことに。
なるほどー、わかってきた気がする。
あまりにも簡単に無意味に複雑なコードが書けてしまうことが問題なのか。 違う。書いた本人以外に合わせるんだよ。
あんたのコードを周りの人が理解できないのはあんた以外全員バカだからというわけじゃない。 ポリモーフィズムを使うとき、デストラクタにvirtual付け忘れると
場合によってはメモリリークして大変な事になる
サブクラスをdeleteした時に
スーパークラスのデストラクタしか呼ばれない
この罠に引っかかった奴は多いに違いない >>586
とにかくデストラクタにはvirtual付けるようにしてる。 今ほど継承の問題点が言われていなかった過去の常識という印象。 virtualなデストラクタが必要なのは、上に言われてる通りポリモーフィズム使う時だけなんやで
基底クラスのポインタに派生クラスをまとめて管理する(基底のポインタからdeleteする)んでなければ
virtualにする必要は無いんやで
でないと、vtblを持たない、メンバ変数の通りの内容(パディングが無ければ、サイズもメンバの合計に等しい)
しか持たないクラス/構造体とか作れないしな。
継承の問題点って具体的にどの辺?自分にはちょっと想像つかんかった 継承(is-a)は、構造が硬直化する。柔軟ではない
一方、包含(has-a)は柔軟で、処理の委譲(丸投げ)にも使われる。
依存性の注入(DI)も、最近の流行 世間でそう言われているという話ならコピペでも不思議はなかろう。 >>590
has-aの関係だと言えるものならそうすべきだけど、is-aの関係を包含でやると
そのうち必ず破綻するよ? まぁ多態しないならデストラクタを仮想関数にする必要ないってのはその通りで
shared_ptrなんかはダウンキャストしても正しいデストラクタが呼び出せるように
ポインタ自体がデストラクタを持ちまわってるし、知らなきゃ驚くようなことをしている
が
そんなことより、C++が雑多だっていうなら
筆頭は多重継承、ダイヤモンド継承だろ
だーれも使ってない機能、goto以上に誰も使わない、盲腸のような機能
ここから読み取れるのは、つまりは要らない機能は使わなければよい
ってのがC++の流儀であり習わし
今に始まったことではない、昔からそう 多重継承のダイヤモンド継承がどれぐらい使われないかというと
明らかに問題があってめちゃ複雑なのに
ここで例に上がらないぐらい誰も使ってないし
すっかり忘れて頭から抜け落ちるぐらい使われてない
使ったこともないから困ったこともない、そんぐらい使われてない
こんな使ってはならないような機能を持っている言語なんだから
使う側で工夫するしかないのだわな ちなみに仮想継承なんか、実用的なプログラムで使ったことあるやつ居るのかね
コンパイラ開発者がかわいそうだよ
実装が面倒くさそうなのに誰も使わないんだから NVIインターフェースを複数継承するみたいなクラスはよく書くから多重継承がないと困る
そして、スマポが持ってるのはデストラクタではなくてカスタムデリータでしょ?
RAIIのためのデリータを指定するのと、ポリモーフィックなクラスのデストラクタを仮想にすることは独立だと思うけど ん?
オブジェクト志向バリバリだと、普通に多重継承起こるでしょ?
「インターフェースクラスの」ではあるけど。 >>598
インターフェースかどうかはどうやってジャッジするの? 子供の発表会みてるような微笑ましさがあるな
ID:MWDK7HMBのことな インターフェースの多重継承は否定してないって言ってるのになぁ
インターフェースの多重継承は他言語でも見かけるけど
C++の場合は実装の多重継承も出来て、これはJavaやC#では禁止されているわけだけど
CにOOを追加したのがC++の売りであるから、継承は筆頭株主というか鳴り物入りというか
当時としてはCに対するアドバンテージで、売りであったはず
そこでマズったのはハッキリ言ってかっこ悪いが
いらない機能は使わなきゃ済む話、それがC++
仮想継承とか誰が使うの?ってね
gotoより使わないし、gotoより害悪 江添亮とかいうやつやたら偉そうだけど
C++界になんか貢献したの? Linux プログラミング・インタフェース、Michael Kerrisk, 千住 治郎、2012
C++11/14 コア言語、江添 亮、2015
組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド、MISRA‐C研究会、2006
神の啓示を受けし者たちが記した、神の書。
この3冊が出版されているのは、日本だけ
皆、これらの本を持って、山ごもりするw >>606
俺は江添氏のブログで助かってるけどなぁ
新しい仕様を実践的に教えてくれるのでわかりやすい
対してメタプログラミングやらコンパイル時のポリモーフィズムやらを
「今どきのC++の使い方」とばかりに押し付けてくる風潮がうざい(ああいうのはアマチュアの意見だと断言できる)
アマチュアが言ってるのはわかるけどC++系のライターにまでそういうバカが居るから困る
誰とは言わんけど >>607
1番目のはLinuxシステムプログラミングと内容が似てるみたいだけどそっちのが良いの? >>594
標準ライブラリをはじめ多重継承は至るところで使われてるし、禿4にも、真のC++使いは恐れなく多重継承を使うと書かれている。
個人的には多重継承を避けてきたのだが、そろそろ使ってみようかと思う。
昔のgoto危険みたいな話なのかも。
使った方が良い場合は確かにあるので。 禿4によると過度の総称型も良くないらしい。
よくありがちなObject型ってやつ。 >>611
多重継承が一番いいと思ったらためらいなく使うわ
gotoも同様にね、まあ、これはgotoの出番かーと思っても
やっぱり必要なかったなとなるんでgoto使う機会は今のところないな >>609
「Linux プログラミング・インタフェース」の著者、
Michael Kerrisk は、Linux man ページを、10年書いてきた人。
世界中の開発者から、神と崇められている!
開発者は、この本を枕にして寝ろ、と言われている
この本に似ている本は、
詳解 UNIX プログラミング 第3版、2014 C++テンプレートテクニック 第2版、
επιστημη(えぴすてーめー)・高橋 晶、2014
επιστημη も、C++標準化委員会の会員
江添も、テンプレート・メタプログラミングの需要があれば、
本を書きたいって言ってたけど、既にこの本が出ている 江添はそいつらよりちょっと頭が悪いからまともに見えることもあるってだけだな。
本質は変わらん。 僕の知り合いの知り合いができたパソコン一台でお金持ちになれるやり方
役に立つかもしれません
グーグルで検索するといいかも『ネットで稼ぐ方法 モニアレフヌノ』
LNCSZ 屋上屋を架す形での仕様の肥大化が続いてもう巨大迷宮みたいな言語
理解してるって自信があるのはコンパイラ開発者や規格策定者だけじゃないかってレベル
いやそれさえも怪しいけど
そんな言語を一介のユーザーが進んで使いたいなんて思うわけがないよね K&Rを再読したんだけどさ…
スタックVMの作り方だろこれ。
「足りない分は自分でつくってね」という。
それで出来たのがjava,ruby,python。
禿に騙されて寄り道するなよ。 知れば知る程嫌いになる言語C++
パフォーマンスを維持したまま互換性を維持したまま言語仕様を肥大化して
コード以前に言語が汚くなっているC++
COBOLと同じ負の遺産C++ javaとか気持ち悪いよね
オブジェクトの中身弄くるのか分からなさすぎて ■ このスレッドは過去ログ倉庫に格納されています