C/C++は古臭い!効率悪い! ぼく「それC++の事を知らないって言ってるようなものだよ?」
■ このスレッドは過去ログ倉庫に格納されています
string ある
foreach ある
型推論 ある
template ある
オペレーターオーバーロード←クソ便利 こういうプログラムを作ると、この言語だとこんな簡単にかけるけどCだと大変!みたいなのないだろ? 組み込みプログラマ僕、戻り値の型がわからなくなる型推論に激怒 template使えばオーバーロードしまくるJAVAやPythonよりも簡潔にかけるよ >>14
C++.netは別の言語みたいなものだよ multibyte,sdlc無し,4バイトアライメントとする ファイル分割する場合やっぱまだhファイルとcppファイル作る必要あるの? 言語自体の効率とかよりたくさんの人が参加してライブラリ開発が活発な言語が重要ってはなしになっただろ >>22
元からきちんと設計してたら作る必要ないが? まーたイッチ負けたんかw
ググってきた知識書いてるからボロがボロボロでてまんなあw 組み込みもRustになるんちゃうの
C++20も追ってない人大井っしょ >>29
パンダズのAI層別を1万で作ってよ、みたいなのはある >>31
14時点でrustより上
safeptr周りはおまけ >>19
言語設計がむずすぎる・日本語の情報がほぼない・GUIが面倒すぎる
の三拍子がね… >>34
ヘッダとソースに分けるのは、整理しやすいから分けてるので 普通にリソースの制限を意識しなきゃいけない組み込み系で使うなら
C/C++は最強の部類だと思うが C#訳分かんねぇ・・・
Javaのがまだマシだった >>46
Javaは分かりやすいけど書く量が多いぢゃん 他の言語は言語の側についてない機能使おうとするとクソ長いコードでトリッキーなことしないとダメなのが多いけど
CとかC++はそのあたりは素直でやりたい通りに書けばその通りに作れる まあ処理は爆速だよな
それに何もしなくても勝手に環境整ってること多いし >>50
javaが理解出来ないわけない
理解出来ないjavaがあるとすれば
それはただのゴミ
全部書き直すべき >>52
基礎ができてない感あるよね
でも最近のアホ大はCやらせずにpythonだけやらせたりするんだぜ gcとかjitとか内部的にファンクションポインタ連発してくるとか物理アドレス触れないとか
後継言語がくそすぎて結局c言語でいいよってなる
文字列操作とかgui組む羽目になった時とか
アホくさいと思いますよ >>56
やはりsimple is bestなのか javaって書き方の流儀なんかも含めてCやC++にも影響及ぼしたくらい良くも悪くも革命起こした勢力だぞ
C界隈は大昔は1文字の変数とか山盛り転がってて流派が合わないとまともに読めない世界だったんだ
ちゃんと読める変数名付けるのが当たり前になったのはjava勢の力が大きい Cプラプラ学ぶのおすすめな本やサイトってある?
お絵かきソフトとか作りたい ちなみに本の見様見真似だけどシンセサイザーソフト作ったことある
ただ基礎学んでないと応用もできんだろうから基礎を学びたい ここで聞くのは>>1に申し訳ないんだが有識者が多いからstaticについて教えてくれ
インスタンスの生成が必要ないクラスや処理の場合はstatic使うって認識であってる? 動的確保したメモリの扱い。
ガベージコレクション無いからいちいちfree()とかdelete()とかしなきゃいけない
可読性低下 まんどくせいからLLでいいよ
なんならローコードでもいいよ >>63
使い方は言語や流派でいくらか違うと思うけど
ただ、インスタンス化が必要ないというだけで多用するとスパゲティ化待ったなしだからそういう使い方はあまりしないと思う
どうしてもインスタンス化をすることができない場面で検討するか
パフォーマンスチューニングで局所的に使うのは良いと思う ずっとC言語やってたが
C++触ってゲロ吐きそうになった
その後C#触って感動した C++って今もmavenとかyarnとかpip的なのないの?
ライブラリ導入しようとするたびに発狂してた思い出 >>66
>>68
ありがとう
既存システムに制御装置からデータ抜き取ってるアプリがあるんだけど8割くらいはstaticで書かれてたのね
装置と通信→データ読み取り→加工、みたいな一連の処理で、装置も一台としか通信してなくて内容的にもインスタンス化する必要ないからstaticでも問題ない >>72
問題ないんだと思って見てたんだけど、あんまり多用するもんでもないんだね >>72
制御装置繋がってるものだと事情が違うかもしれない
ハード側の制約でインスタンス化がそもそも不適切な仕様かもしれないし
古い機器との接続を想定してのことかもしれないし
接続方式によって伝送レート計算して微調整した結果かもしれんし
アプリ単独で動くものとは事情が違うから安易にそうとは言えない >>72
うちも全く同じ処理をほぼ全部シングルトンでやってるわ
同僚だったら笑えるな >>75
ありがとう勉強になる
そこまで考えて作ったとは考えにくいけど状況によってstaticの使い分けは必要になるね
>>76
それはやっぱハードとの制約があってそうしてる?それともインスタンス化するような要件がないからそうしてるのかね
あとうちの会社にはここに居るような色々知識のある人は居ないからきっと大丈夫だ >>77
中身がわからないから細かいことはわかないけど
GCかかる時の遅延が問題になる仕様で
それを避けるためにstaticという構造かもしれないし
メモリが限られているけど長期稼働が必要で万一にもリークしたらまずいから動的要素は排除とかかもしれないし
その辺は設計した当時の人間じゃないとわからないな
遅延だとかリソース不足の問題は信じられないほど緩和したし
20年前とかのシステムで動いてたものをそのまま引き継いでて今では全くどうでもいい可能性も >>77
後者だな
複数作りたいクラスじゃないし面倒なこと考えないでとりあえずGetInstance()しとけばいいから挙動もわかりやすい >>80
JavaScript
htmlファイルに書いたらブラウザで気軽に実行できる
型はないし言語設計微妙だけど >>78
なるほど
うちも当時の担当者がいないし資料も残ってないけど多分過去のを引き継いだだけの気がする…
>>79
たしかに、複数のクラス作る必要無いんだってのは見てて分かりやすい ■ このスレッドは過去ログ倉庫に格納されています