C++相談室 part146
■ このスレッドは過去ログ倉庫に格納されています
C++はすぐ深刻なエラーになるからコーディングに注意を要しストレスで禿げる それはあながち否定はできない
まあ俺は禿げていないが プログラミング言語好きの人たちが集まるネットコミュニティの
雰囲気にあてられてハゲるんと違うか？
C++界隈は他の言語に比べて攻撃的な物言いをする人が多い気がするぞ。
皆がトーバルズ氏になりたがってる、みたいな。
ハゲ先生の本を(和訳本で)読むと穏やかな人格者っぽい感じなのに。 C++はもうC#の後追いやってるだけだからなww
テンプレートにうつつ抜かしてる間に生産性以外でもC#に劣る言語仕様に成り下がった >>116
void君とか頭おかしい連中が目立ってるからだろ
>>110
c++で創薬したるわ 今はやりのpythonを使う人はpybind11とかでpython用のC++プラグイン作るだろうから、これからもC++は色んな所で使われ続ける。 後追いというか、C++を最も使い込んでいるのはMSなんだからC#に似てくるのは当然 何寝言逝ってる
C#で新たな規格が決まって
だいぶ遅れて、C++がそれ取り込んでという順番がつづいてるだろうがwww C++/cli経由だけどenum classもそうじゃないかな yieldは40年前からある技術だけどな。
cライクの言語に取り入れたという意味ではエポックメイキングだったんだろう。
その2つくらい？ >>127
Herb Sutter
のことですかね。 >>128
中間言語や VM の存在は C# の本質ではないと思います
マイクロソフトもいずれネイティブコードを吐く C# コンパイラを出してくるでしょう、私には VM なんてなんの腹の足しにもならない無駄な機構にしかみえません PGのVM設計するときに参照するのがx86だったりとかで、結局ロックインしちゃってる気がする。
複数の未知のCPUにJITできるように組んでないような気がする。 wintelの目指すトコロはCPUアーキテクチャと専用高級言語の囲い込みでしょ
C++を潰すには、みたいな第二次ハロウィン怪文書を思案中だよきっと >>132
今でも .NET の中間コードは、native コード化できます。 >>136
できますが、結局、GCを使うので、C++並の速度にはなりません。
GCが動いた場合、処理時間のオーダーが違うので、CPUがどんなに速くなっても
どんなに最適化を施しても無理です。 ビジネス用途を想定しているC#と基礎技術を支えるC++が競合してると思ってるのが面白い GC で止まるのが嫌なら、GCの無い、Rust を使え！
その代わり、かなり注意深くプログラミングしないといけないw 注意深くプログラミングしなくていい言語なんてあるのか 昔は1日の業務の終わりにGCを走らせてから帰宅したもんだ。翌朝までにGCが完了してればそれで充分だった。
いまは物理メモリが広いので速度クリティカルな部分ではGCを無効化するのもありかもしれない。
それだとしてもC#はC++を置き換えられないよ。思想が違うもの。 やっぱ今衝突とか爆発しそうなその瞬間に寄りによってGC走ったら悔やんでも悔やみきれないからな
GCなし言語には生き残ってもらわないと >>145
それはRTOS使わないといけない
C++でも割り込みで予期せず遅れることはある Rustはコンパイルが通った時点で（メモリ管理に関しては）注意深くプログラミングし終えたことになる、
抜け穴がないわけではないが普段気にするほどではない GCとプログラムの実行速度の姦計は、
GCが極力動かないようにプログラマの側で工夫する余地があるから必ずしも打つ手が無いわけでは…
（GCが動き出したらワーストケースの見積りが吹っ飛ぶというのはあるが
とゆーわけでC++に比べてC#がいまいち遅いのはGCが主犯というわけではなく、
オブジェクトに参照経由で毎回間接アクセスする言語仕様なのと
JITでマルチプラットフォーム対応可能なことと引き換えに最適化があんま利かせられていないせいだと思う
あとネイティブコードを呼び出す最にマーシャリングもするし、
ジャヴァのサンドボックス思想をパクるために仕方なかった側面、 ユーザーコードがバックグラウンドタスク（応答時間非規定で可）でGCを使うだけなら
GCとリアルタイム性は両立しないわけでは無い
まあGC有りのプログラミング言語でプログラムする状況で
GCが使われる状況がバックグラウンドタスクのみに限定されるというのは
非現実的な想定かもしれんが >>151
姦計とか、どんな文脈で使ってたんだよw 今時のよくできた GC (の実装) はインクリメンタル化されてるから、
良い感じに暇なときを見つけて動いてくれるっしょ あれ？この人職業プログラマなの？
趣味でお気楽にやってるだけの人だと持ってた わたくしが「現代現象」と呼称する一連の悲劇的な出来事は
なんの変哲もない日常がいきなり変貌を遂げるものであり
その猶予は0.1秒もない
スイスチーズモデルを天文学的数字ですり抜けたそれら現代現象への対処時間は大抵は１秒未満になる
なので未来になればなるほど思いもよらない意味不明で突発的で素早い破壊事象が起こる
これを踏まえて車載映像の事故映像を見てみると猶予が本当に少ないことが分かる
なので自動運転では各種の重い処理はマーフィーの法則によれば衝突する0.1秒前の「暇な時」に動き出す
これを超克するには未来予知が必要になる >>155
はちみつさんは lisp-er ですから、lisp-er 的な視点で現在のプログラミング環境をみれば、
やっと時代が lisp に追いついてきた、という感慨が発生するのも自然だと思いますよ
GC も lisp の産物ですから
「適正に欠く」と判断する推論内容は理解できませんね >>159
それは、おまえも適性を欠いているということだ
形容詞に比較をつけないとか、定量的でないとか、
魔法的にアレしてくれるだろうとか
おまえの頭ん中も同じだとここで露呈して今どんな気持ち？ >>160
私に適性がないのはそのとおりなのでしょうが、いちいち定量的に条件を明示して話をしなければならないわけでもないでしょう
魔法的にアレするレイヤーの話は別途規定する前提で、今は特に大局観を語りたいときにはね
あなたは、戦術レベルの話はできても戦略レベルの話は理解できない大局観に欠いた狭量な、例えば java 屋さんに見えますね >>161
主張に説得力がないって指摘がおまえまだわからないのか？
あいた口が塞がらんわ ほんと攻撃的なやつが多いな
これだからC++界隈は >>132
>いずれネイティブコードを吐く C# コンパイラを出してくる
すでに出とるが
いつの時代の話しだ >>159
ワイは Scheme 使いでもあるし日常的には Scheme の方をよく使ってはいるが、
長いことバイナリマンだったし、 LISP の思想にそんな強い思い入れはないわ。
ただ、評価とかごちゃごちゃ言ってないで手早く書いて実測しろってのは LISP 的かもね。
今では他の言語でも書きながら速いサイクルで回して改善するスタイルって一般的じゃね？
書き始めは楽観的にやってるよ。
なるべく楽して必要になってから手間かけりゃいいんだよ。
そんでもってゆるふわに富豪的プログラミングしてても割と足りてしまう経験の方がおおいなぁ。
>>156
俺は趣味人やで。 > 富豪的プログラミング
相手してはいかんやつだったコイツ >>163
これだけ広いスパン使われて、いろいろな書き方がある言語なのに
ユーザーは多様性に非寛容というのはなかなか興味深い現象。 いや多様な使い方を求めるからこそ
GC厨の矮小な発想範囲を危惧するんだ >>170
この板で唯一まともな僕も赤くしておこう C#って、これ以上の普及はもう無理だろ。WindowsのUIアプリでしか存在価値はない。
MonoはイマイチでJavaはなくならんし、WebもAIもスクリプト言語系でOK。
タイムクリティカルなエンジン部をC++で書いて、スクリプト言語（Python含めて）
使うのが主流化してる。C#を使う場面が無い。 会社の上層部がMSの営業に騙されてAzureの導入を決めてしまった場合、
マネージドサービスの利用のためにはC#を使用せざるを得ない
他の言語では事実上使い物にならない Windowsのデスクトップアプリを手っ取り早く作るにはC#以外の選択肢が無い 保守的な経営者とそこそこの技術力の社員でも使えるんだからAzureというのは大したもんだな windowsに関わってる限りC#とC++/CLIからは逃れられない >>132
制限付きながら、既にネイティブコードは吐ける >タイムクリティカルなエンジン部をC++で書いて、スクリプト言語（Python含めて）
>使うのが主流化してる。C#を使う場面が無い。
主流て、そんなもん昔からほぼこういう書き方してるだろwww
そこで、スクリプト言語を使ってどれだけ実行時間に影響与えてるか正しく認識してないのが多い。
ここでC#使ってこんなに違うのかと初めて気づく。
そして、単に実行速度ってことならエンジンにC++使わずともC#でもそこそこ勝負できるってことも認識するのが情弱。
タイムクリティカルな用途ならそれこそOSからしてラウンドロビンなんか使わない。
RTOSでわざわざ、メモリプール設定してるのに、new/delete繰り返すようなC++流の書き方はそもそもよろしくない。
C++で非推奨の限りなくpure Cに近い書き方してるのはもはやC++とはいわんだろ。 > RTOSでわざわざ(中略)C++流
そう思い込んでる迷惑なのがいるんだよ
おまえみたいな タイムクリティカルもいろんなレベルがあるから
ハード実装
FPGA
OSレスのフルアセンブラ
RTOS + C
....
クラウド > C++で非推奨の限りなくpure Cに近い書き方してるのはもはやC++とはいわんだろ。
テンプレート、ラムダ、...を使いまくるコーディングだけがC++じゃない
小規模組み込みでnewすら使わない泥臭いC++もC++ 禿も必要な機能だけを使え、無理に全機能を使おうとするなって言ってるね クラスにupdateという関数があってそれが何回もメイン関数にあるインスタンスから呼び出されるのですが
update内で変数宣言を書いている場合、領域の確保は呼び出される度に行われますか？ その宣言にstaticがついてなければ毎回領域確保が行われる 変数の宣言と定義、用語の違いを利用した罠かも知れん。 変数自体はスタック(またはレジスタ)に割り当てられるから
確保解放のコストは気にするな
変数の内部(コンストラクタ他)でのメモリ確保解放や初期化処のコストは当然気にしよう
パフォーマンスの問題であればクラス変数にする等 関数を使おうってときに
関数内変数をデータメンバに改造するアホが
うちの若いのにいたら焼きだ バッファをあらかじめ確保しておくなんて
ごく当たり前のことだと思ってたけど
そうじゃないのか？
updateなんていう、
クラスの内部に直結してそうな関数ならなおさら とか抜かすやつに限って計測もせずに片っ端から最適化と称した難読化をしやがる パフォーマンスの問題であれば
パフォーマンスに問題があるなら >>200
パフォーマンスの問題であるなら、まずは計測する
そして最適化厨が必死に難読化を施しているその箇所は、殆どの場合パフォーマンスに全く影響しない パフォーマンスを考えなくていいプログラムなら
そもそもC++を選ぶのが間違い パフォーマンスなのかフラグメントなのか使用リソースなのか
何を気にしてるのかはわからないけど 再入やマルチスレッドで死ぬ恐れもあるから、このレベルの初心者にバッファの事前確保が当然だなどという阿呆な考えを植え付けることはテロ行為に等しい >>191はstaticがついてなければyesで終わる話
それに勝手な前提つけたしていらん押し付けをするからお前らは駄目なんだぞ >>207
会話するのが嫌いならわざわざ書き込まなくて良いんだよ https://ideone.com/kprgQF
ちょっと暇だったので、
昔のビットシフトの掛け算と割り算って、
今の技術使ったら爆速になるんじゃないかと思ったのですよ。
で、書いてみたのだけど、知識不足で到達しないんだ。
なんでだろう？？ >>202
そのプログラム全体が速度が要求される訳でもなかろう。必要なところだけ必要なぶんだけ高速化しろよ。
速度が要求されない部分も別にわざわざ別の言語で作るメリットがなければC++のままで構わないわけだし。 >>208
質問者にとっては混乱させられるだけの余分な情報だし、知っている人からすれば当たり前で価値のない情報だし、実のない議論したいだけの無意味な付け足しは要らんよ。 俺が言いたいのは一つだ。
C言語は超高等言語なので、その前にC++使うのだ！ ■ このスレッドは過去ログ倉庫に格納されています
