C++相談室 part152
レス数が950を超えています。1000を超えると書き込みができなくなります。
>>847
争うつもりがないなら黙ってりゃいいのにw
>>849
お前バカ? 怒らせてしまった。やっぱ本当のこと言うのは良くないね。 C++でカーネルを書くとして
レイヤー的にSTLとか一切禁止になるんじゃ…
するともはやCに対するアドバンテージはクラスや仮想関数が使えることぐらい
だがそれあってもカーネル書くのに言うほどうれしいかどうか、、、 アプリケーション開発なら問題領域と解決領域をスムーズにつなぐのにクラスや多態性が役に立つが
OSのカーネルとなると信頼性と効率性が追求目標なのでアプリの設計とは様相がだいぶ異なるヨカン
アルゴリズムとデータ構造の世界で今日日のアーキテクチャーの複雑なメモリモデルの
要請を満たしつつメチャ枯れた書き方を要求されるしそれ以外の書き方をしたらリーナスに頃される
ハズ >>854
テンプレート自体は使える
ただ、new/deleteや例外を使ってるやつも多いから使えるのはかなり限定されるとは思う
>>852
ダッサw >>854
カーネルで糞重い仮想関数使うな、馬鹿。 おいおい
linux kernelの中はいたるところ仮想関数だらけですがな実質的には
vptrは使わないけど そうだっけvptrって構造体に書かれているvptrでvtblを参照してさらにそのvtblに収容されているポインタを参照するわけだが
そんなことをするぐらいなら構造体メンバとしてポインタを持ったほうがなんぼかマシ
※ 個人の感想です なんでこんなC++を目の仇にしてるようなオッサンがわざわざスレみにきてるのかが謎だ
その精力を別のことに割り振ればもっと生産的なのに・・ >>860
virtualキーワード導入にあたってvtable方式に対する反対意見としてそういうのがあったらしいね
多態はクラスの特性かオブジェクトの特性かという分かれ道で
Smalltalkerあたりが言い出しそうなことだ Smalltalker
昔あった東京や大阪の街情報誌みたいだなw >>862
ちゅうか、お湯に入れたカエルは飛び出るので死なないが、
水から茹でたカエルはそのまま死んでしまうのと同じで、
昔のC++が好きで使っていたらいつのまにか全然違う言語になってしまって
嫌いになっているから。 私は C++ が ISO で標準化される前から使っているが今の方がずっと良くなってると思うんだがなぁ……。
まあ私はアマチュアだから業務での事情とかも知らんし、何か思うところがある人もいるのかもしれん。 保守性無視のアホ拡張ばかりでもはや業務では使えん。
多くのOSSのC++プロジェクトが担当してたPGがいなくなれば保守されず放置されるのは至極当然。
昔のObjective-C、C++、Java、Javascript、C#がそうであったように、オナニー拡張するなら改名して別言語にすべし。 テンプレートメタプログラミングのトンチ臭さがなんとも
ライブラリを使うだけの立場なら使いやすくなったと思うけど
テンプレート絡んだライブラリ作る側はしんどすぎる
デバッグつらい 確かに色々としんどい機能は多いのかもしれんけど、
それらの機能が必要なときに使わずに書くともっとしんどいでしょ。
全面的にメリットがないときなら使わないという選択もできるわけだし。 頓珍漢甚だしい。その拡張された機能が必要だったのは標準化される10年も20年も前だろう。
必要なときに用意しないで今更使ってくれと迷惑極まりない。C++標準化委員会のやってることは時代錯誤甚だしい。
過去のコード資産を全否定するような拡張するなら別言語にしろと言ってんだ。 てか、はちみつはマジで煽り抜きで
数万行以上のソフトをモダン(と、C++オタが信じてる)な書き方で作ってみたらいいよ
当然メタプログラミングにも挑戦して、だ
業務どうこうじゃなくて、ソフトを作る道具としての今のC++がどうなのかわかるから >>875
新しい機能を (必要だと考えるまで) 使わないでいい自由があるということを
私は言ってるのにその返しはなんかおかしくない? >>880
>新しい機能を (必要だと考えるまで) 使わないでいい自由がある
全部publicなのが問題 んまー低水準開発だと見えてほしくないものが見えてしまっている
レイヤーAとBの初期化が終わらなければレイヤーCの機能を呼んではいけないのに、
という状況は言語によらず普通に発生するから程度なのかもしれんが
C++はその手の罠が大杉問題、 最新のC++規格について行けている(キリ
と自称されている方々は、
単にOSが起動完了した状態での使い方に習熟しているだけではないのかどうなのか、 くだらねえ言いがかりだな
まあそんなことしか言うことねえのはわかるぜ
最大級に軽蔑する このスレ観てたら C#++ とか産まれそう
と思った >>881
プロジェクトのコーティング規約に従えよ。 プロジェクトのコーティング規約をしっかり定めさえすれば
空も飛べるはず、 >>870
まあ、配列が TYPE a[N][M]; ではなく、
vector<vector<TYPE>> a; // ???
が推奨された時点でもう、おかしいから。
しかも、このスレにはvectorと略さずに必ずstd::vectorと書け、とまで言う人までいる。 vector< vector <TYPE> > a;
はそもそも
TYPE a[N][M];
じゃなくて
TYPE *a[N];
だからなー >>888
プロジェクトのコーディング規約に従えよ;; iteratorの書き方も煩雑すぎ、長すぎ。
linked listの場合に効率悪すぎ。
ポインタも生ポインタ費推奨で uniqure_ptr, shared_ptrなどが推奨されているのも
既に言語として破綻してる。
ポインタはCの「命」なのに、unique_ptrなどと書くのは長すぎるので。
アメリカの学生は9割がポインタが理解できないので、
多数決で言語仕様を決定していくと、ポインタを徹底的に排除してしまう。
角度の Radian 法が理解できない人が、Degreeを推奨し続けたりしているようなもの。
AndroidのSDKは、それになっている。
馬鹿じゃないかと思う。 >>891
std::unique_ptr便利やん?
機能を使えるところまで持っていくのが面倒なだけで、 頭が悪い人は、ポインタの表記の優先順位を頭の中で「ほどけない」ので、
優先順位が馬鹿でも分かる
unique_ptr<unique_ptr<T>> p;
という書き方の方が分かり易く感じるのだと思う。
頭の良い人にとっては、ただ書くのが長くなっただけに過ぎないのに。 >>892
便利でも書くのが長くなった時点で駄目。
頭の悪い人は、長くても考える量が少なくなる方を好むから、
9割がベギナー止まりであるところのプログラミングの世界で多数決で
良し悪しを決めると長くても考える量が少なくなる方が人気を呼ぶことになる。
しかし、頭の良い人は頭のAIがすぐれているので、考えなくても瞬時に分かって
しまうので、読み解いたり自分で書くときに全く時間が掛からないので、
短くかけるほうが好まれる。 >>894
違うな。
実世界では天才と呼ばれているから。 >>895
長くなったことの問題はわかるけど
じゃあc++はどうすればよかったか代案だせんの? 余は真に驚くべき代案を思いついたが
匿名掲示板に書くには余白が狭すぎる、 >>896
ネットを除いたお前さんの実世界って、話す相手が自分自身かお母さんくらいしかいないんじゃないの? >>891
生ポインタは言語仕様上、現在でも有効だし、合理的理由があればナマポを使うことを否定されるわけでもないのに、何が不満なのか分からんな。 >>882
グローバル変数やスタティック変数のコンストラクタに依存姓のある処理を記述して失敗しているのを目撃することはよくある。
でもそれはロード時に自動実行する機能のある言語では同様に起こりうることだと思うよ。
だいたいシングルトン多用するやつの仕業。
使うと恥ずかしくて死んでしまうようなパターン名ならよかったのに std::vector ←イキってるだけのアホ
::std::vector ←こう書かなきゃ意味ねえだろ メモ帳でコード書いてんの?
普通のエディタは補完が効くよ >>896
そういうのならその証拠をみせてください
あなたのものの言い方は、どちらかというと反対側の人の言い方ですね この板で一番馬鹿っぽいのに自分は賢いと思っているのが QZだ。
恐らく女。
女の中では賢いのかもしれないが、男の中では普通。 >>903
アドレスサニタイザー入れたらシンプルトン関連で例外だらけになった
やっぱ未定義動作なのね >>909
>恐らく女。
面白い意見ですね、どのような推論からこの結論が導き出されたのか興味があります
>>896
>実世界では天才と呼ばれているから。
というのなら、その証拠を投稿内容で証明してみせてほしいですよね
>>909 を見る限り、私には馬鹿の同類項にしかみえないですね…… C++で食ってるフリーランスいる?
いくつでどういう技能を持ってていくら貰ってるか教えてくれよ >>911
>>恐らく女。
>面白い意見ですね、どのような推論からこの結論が導き出されたのか興味があります
普段から、馬鹿な応答が多かったし、
「自分でコンテナクラス(リストなど)を作れるから天才」
だとか、男だったら基本中の基本の出来て当たり前の事が出来るだけで天才と言っている
辺り、如何に周りのレベルが低いかが分かったから。 >>904
> ::std::vector ←こう書かなきゃ意味ねえだろ
えーキモいからやだ :: が増えると tanasinn な感じになるな。 >>916
絶対パスのつもりらしいが絶対パスになってねえだろ
相対パスならusingしろ
絶対パスの面倒臭さと相対パスの曖昧さのデメリット両取りする間抜けな書き方すんじゃねえって話 stdが被る可能性はないに等しいのでセーフという合理性 あのなあ、ここ技術板だぜ?
合理性っておかしいだろ >>920
技術板だからこそ、教条主義的な完全性より現実的な条件での合理的な判断があってしかるべきだと思うぞ。 プログラミングはサイエンスの部分もなくはないがエンジニアリング (またはテクノロジ) 寄りの話だろ。
一部の隙もない論理を構築したいわけじゃなくて問題を解決したいんだ。
で、 std のかわりに ::std と書くことで解決される問題が
このスレの誰かの前に出現したことがただの一度でもあると思うのかね?
トップレベル以外の名前空間に std が現れるのは仕様で禁止されていないっぽいから、
そりゃあ可能性だけで言えば絶対にないとは言えんだろうが、
現実にはこの二者がいたらどちらがよりクソだと思う?
・ 変なところに std という名前空間を作るやつ
・ ::std と書かずに std と書くやつ
前者があまりにもクソすぎるのでそういうやつはおらんだろということで
だいたい上手く運用できておるのや。 自己弁護にしか聞こえねえな
"今までそうやってきたから正しいことにしたい"
批判的な相手がそれで納得するとでも思っているのか いっそstdをキーワードにすればって話ならまだわかるぜ
おまえらの論法で言うところの関数名やオブジェクト名をstdにはしねえんだから
下線で始まらないoperator""をstd以外には作らせないこともできるね >>923
そうだよ。
std という名前を作らないか ::std を使うかのどちらかが達成されていればよく、
std という名前を作らないという習慣で今までやってきるのをあえて乱したいのはなんで?
っていう話だよ。 ::stdってしてたら逆に何こいつイキってんの?って思うけどなw >>923
どちらかが正しいと言ってるんじゃなくて、一貫させることが正しいと言ってるんだよ。
移行コストを支払って得られる何かがあるなら検討はするよ。
何かいいことあるの? >>923
世の中には話の通じない相手がいるのは分かってるし、そんな相手を納得させることに無駄なエネルギーを費やす価値はない。お前さんが納得しなくも他の誰も困らないからどうでもいい。
というのも合理性だなw 「合理性」を咎められたのが余程効いたようだな
意味をここでだけ変更したくてそんなに必死になるのは
そういう手合いはstdの意味をここだけ変更もしかねねえな >>928
どちらが正しいかって論点では分が悪いもんなw ::stdって自己満でしかない
リターンがない
特に困ってない問題を解決したところで人生の無駄遣い
そこがんばったところでアホなマクロがひとつ混ざれば破綻する可能性はあるわけで
ある程度の良識や常識に依存するのは仕方ない
可能性のスケール感を考えられるかどうかとも言える
まぁやめろとは言ってないんだから好きにすればいいじゃん、ひとりで書いてる限りは 実害が出る前に予防的措置ということはあるぞ
それから俺は既存のコードを書き直せなんて言ってない
そんなのはてめーらの勝手だ
アカデミックな目線でおかしいと思うところを批判しているだけだ
代替案も出してる(採用されるか否かはともかく) >>935
もっと広範囲に std という名前を禁止する提案はもう出てるよ。
言語仕様として良くなかったというのは言わなくても皆がわかってるので、
そんなに強くいわなくてもいいよ。
C++ の仕様がグダグダなんていうのは今更のことじゃん。
その上で、 std という名前を定義しないという運用上の習慣は確立してるって話。 そもそもstd名前空間(::stdじゃなくて)の拡張は未定義じゃね?
(17.6.4.2.1 Namespace std)
何のためにstd名前空間を定義するの? 茨木が
いばらき
なのか
いばらぎ
なのか
くらいどうでもいい 例えばstd::swapで自分のクラスの交換を定義したい、ってケースが考えられる。 >>939
その std は ::std のことやで。
その std を拡張することは禁止されているが、
別の名前空間の下に std という名前空間を作るのは禁止されていない。
using namespace で std を含む名前空間を取り込んだ上だと ::std でなく std という表現をすると
標準ライブラリの std でないものを指す可能性があるというのが今の話題。
でも禁止されてないからといって std という名前を付けるやつはおらんから気にするだけあほらしいでというのが反論。 >>935が言ってる採用されるか、てのは「相手が」だと思うが
C++標準の話ではないやろ >>941
std (::std) に定義を追加することは禁じられているが特殊化を追加することは禁じられていなかった。
しかし C++20 からはこれも禁止になる。
カスタマイズポイントという仕組みが用意されたのでこれを使うのが (今後は) 望ましい。 >>942
C++標準にnamespace std を ::stdとする定義ってあったっけ?
『standard libraryの名前xは ::std::xとして定義しろ(20.5.1.1.3)』
というのはあるけど、namespace std = ::std という定義じゃないよね?
最近は標準を読んでないから見落としあるかもしれんが、
ざっと見た範囲では無さそうだった。 >>945
そう。
using namespace std; の std が ::std でないものを指す可能性があるが、
拡張を禁じている std というのは ::std のことなので、
大元の議論は ::std を拡張するなんていう話はしてないという指摘をしてる。 ID:FCbCRYtX さんはグローバル以外で自分のコードから見えるスコープに誰かが
std という名前を宣言している可能性も考慮して万全の策を取っているんですね。すごいなぁ。
ということは当然、誰かが #define std ... している可能性も考慮して
::std を使う行の前には必ず #undef std も書くのでしょうね。すごいなぁ。 「::」って打つのは超々々多大なコストですもんね。すごいですよね。 >>946
16.5.4.2.1 Namespace std
Unless otherwise specified, the behavior of a program is undefined if it adds declarations or definitions
to namespace std or to a namespace within namespace std.
で、::stdの規定があるのは
16.5.1.1 Library contents
Whenever a name x defined in the standard library is mentioned, the name x is assumed to be fully qualified
as ::std::x, unless explicitly described otherwise. For example, if the Effects: element for library function F
is described as calling library function G, the function ::std::G is meant.
だけだから、拡張を禁じているのが::stdだけというのは言いすぎじゃね?
標準化の経過を追っているわけじゃないからこの解釈が妥当か知らんが。 >>942
反論なら論で来いよ
あほららしいなんて感情ではなく >>943
「相手が」stdをキーワードにできると思うのか? レス数が950を超えています。1000を超えると書き込みができなくなります。