20/02/12 21:26:37 rfok9Tr/.net
(bool)b
はCへの移植の可能性があるならやっちゃダメ
801:デフォルトの名無しさん
20/02/12 21:31:03 DU9qWhLl.net
>>776
何で？
ISO/IEC 9899:2011 (E)
7.18 Boolean type and values <stdbool.h>
1 The header <stdbool.h> defines four macros.
2 The macro
bool
expands to _Bool.
802:デフォルトの名無しさん
20/02/12 21:34:37.96 rfok9Tr/.net
typedef char bool;
の可能性があるから
803:デフォルトの名無しさん
20/02/12 21:35:17.48 ytylQgpT.net
Cに移植する可能性があるならC++の機能を使っちゃダメなのは当たり前だよなぁ
C++スレで言うことではないと思うが
804:デフォルトの名無しさん
20/02/12 21:36:55.01 rfok9Tr/.net
>>779
問題点はそこじゃない
移植時にコンパイラが問題点を見つけられないのが問題
805:デフォルトの名無しさん
20/02/12 21:38:26.52 rfok9Tr/.net
コンパイラが問題点を見つけられない例は他に山ほどあるが
だからといってわざわざ増やさなくても良い
806:デフォルトの名無しさん
20/02/12 21:39:05.32 ytylQgpT.net
いや、問題があるなら移植する人が見つけろよ
807:デフォルトの名無しさん
20/02/12 21:40:47.83 rfok9Tr/.net
移植は完璧な人がする
なんて妄想は捨てた方が良い
808:デフォルトの名無しさん
20/02/12 21:42:13.60 rfok9Tr/.net
Cに移植する可能性が無いならどうでも良い
ちなみにキャストで警告が出る環境もある
809:デフォルトの名無しさん
20/02/12 21:42:36.95 ytylQgpT.net
だからそれは移植する側の問題だろ。勝手にやれよ
810:デフォルトの名無しさん
20/02/12 21:52:54.99 DU9qWhLl.net
>>778
マクロとtypedefが被った場合どうなるか解ってる？
811:デフォルトの名無しさん
20/02/12 22:12:26.79 ecElmrkB.net
もちろん
812:デフォルトの名無しさん
20/02/13 00:16:13.58 X++L6urQ.net
>>733
Rustを少し見てみたけど、書き方が全くC/C++とは違っていて、
全く異なる文化圏の言語になれた人が設計した臭がした。
これがC/C++の代替になるとは考えにくい。
はっきり行って、これを使えといわれると辛い。
813:デフォルトの名無しさん
20/02/13 00:26:27.60 YbJF2Pjt.net
テスト機能が標準で用意されてるのはいい
814:はちみつ餃子 ◆8X2XSCHEME
20/02/13 00:45:52 XX4mj9DD.net
個人的には Rust は好感触。
型システムは ML 系言語で実績があるものを基礎にしてることもあって、C++ のグダグダな歴史を背負ったものよりはまとも。
ML 系はやっぱり高級路線の言語だし、インデントでブロックを表す系統なのがしんどいけど、
Rust は上手く低レイヤ用 (としても使えるよう) に着地させてるし、 C 風の外観を踏襲してもいる。
C++ が Rust から取り入れられるものはそんなに多くないと思う。
C++ は良くも悪くも互換性についてかなり強い要求があるので、
Rust 的な、カッチリと保護された仕組みを後付けするのはどう考えても無理。
C++ が Rust を参考にすることは間違いなくあるとは思うが、
全体の思想がまるで違うので限定的な範囲でしか取り入れられない。
もし取り入れらたらそれは C++ の新機能として新しく学ぶので十分でしょ。
Rust を学ぶのは間違いなく有用ではあるけども、
Rust の知見が C++ に取り入れられる可能性がありそうだからという理由ならそんなに意味ない。
815:デフォルトの名無しさん
20/02/13 01:02:46 b1nbpqgi.net
C++の配列は長さの情報を持ってないってことになってるけど
長さを与えなくてもdelete[]できるんだから、メモリのどこかにその情報はあるよね？
なんでその情報をプログラマが利用できないようになってるの？
816:デフォルトの名無しさん
20/02/13 01:06:29 qzSQSiwu.net
rustがかっちり保護してくれるとか低レイヤー向けとか馬鹿ほど信じてるよね。
ありゃ帯に短し襷に長しの典型言語だわ。
817:デフォルトの名無しさん
20/02/13 01:44:34.08 X++L6urQ.net
>>792
実際、Rustは、Cを簡単にするのではなく、Cを難しくしてしまっていて、Cのポインタが理解できない or 難しく感じる人には、Rustの特徴の核心たる所有権、借用などの部分はちんぷんかんぷんだと思う。
818:デフォルトの名無しさん
20/02/13 01:48:50.73 X++L6urQ.net
>>793
Cの問題点を取り除いたと言うより、ほとんど全てのプログラミング言語が暗黙のうちに用いている代入の概念をなるべく使わないようにして変数束縛などの全く異なる独自概念を用いようとしている。
しかし、これは、手続き型言語と関数言語の違いに匹敵するくらいのプログラミングの概念の変更になってしまうため、手続き型言語の中で改良された次世代言語と言うものではなくなってしまっているとも言える。
819:デフォルトの名無しさん
20/02/13 05:24:36 AWnkBPoe.net
変数束縛って右辺値参照でしょ
820:デフォルトの名無しさん
20/02/13 06:24:47.58 fMXzK7Sc.net
RustはC++なら簡単にできることをものすごく回りくどく書かないとコンパイル通らない感じだからとてもつらい
821:デフォルトの名無しさん
20/02/13 09:13:38.23 6FSFTWhE.net
>>790
RustがC++に取って代わることがあるか、というニュアンスの質問でした
今C++でやってる仕事がRustに置き換わる可能性が高いなら今から勉強しとこうか、と
822:デフォルトの名無しさん
20/02/13 12:35:22.33 z5cRWLgY.net
>>797
断言してもいいが、RustはC++に取って代わることは無い。
なぜなら、普通の手続き型言語での枠組みにすら入ってない書き方を強要されるから。
手短に言えば、単にC/C++と書き方が大幅に違っているだけではなく、書き方が他のどんな減の範疇にも属していない。
823:はちみつ餃子
20/02/13 13:30:24.18 XX4mj9DD.net
>>796
C/C++ でのオブジェクトの寿命の管理の難しさってのは
理屈が理解しづらいというよりはわかってても間違うという難しさなんだよね。
そして間違っていてもコンパイラは黙って通すことも多い。
C/C++ を長く使っていればそれを感じることって結構あるでしょ。
そういう部分のプログラムが正しいことはプログラマが保証しなくてはならんわけだ。
でも Rust では言語処理系の側でやってくれる。
C/C++ で面倒な部分を Rust では自動でやってくれる。
まわりくどいのは確かだけど、それで楽できるのも確かなので、
どっちを取るかって話だな。
オブジェクトをどこで後始末するか。
管理の主導権はどのモジュールに持たせるか。
そういうのって C/C++ でも考えてるよね。
C/C++ ではプログラムに書いてないだけで本来はあるはずのものなんだよ。
(C++ だとスマートポインタの導入で少し楽にはなったけど。)
自分が何を考えていたのか、そして何を考えられていなかったのが
明らかになるのはそれはそれで楽しいと思う。
まあ、それは俺が趣味でやってるからかもしれんな。
824:デフォルトの名無しさん
20/02/13 13:34:58.25 3lSBa444.net
おまえの設計がヘタクソなだけだろ
825:はちみつ餃子 ◆8X2XSCHEME
20/02/13 13:45:30 XX4mj9DD.net
>>800
そうだよ。
そんでもって大抵の人間は設計がヘタクソだし、
ヘタなところが検出されるなら検出されないより良い。
826:デフォルトの名無しさん
20/02/13 14:01:13 z5cRWLgY.net
>>799
変数束縛やら所有権や借用の概念が複雑すぎて、そっちの方が C/C++の
メモリ管理よりミスし易い。
827:はちみつ餃子 ◆8X2XSCHEME
20/02/13 14:13:53 XX4mj9DD.net
>>802
間違いなくミスし易いけどミスした箇所が検出できないということはあまりない。
828:デフォルトの名無しさん
20/02/13 14:20:14 3lSBa444.net
設計がヘタクソなヤツが書いたソースのメンテやらされるのは最悪だけど自分で組み上げるならC++以外有り得ない
各々の力量が顕著に表れやすい最高の言語には違いない
バカも容易に炙り出せるしな
829:デフォルトの名無しさん
20/02/13 14:20:33 z5cRWLgY.net
>>803
仮にあなたはちゃんと理解できても、一般のプログラマは変数束縛やら所有権や借用の概念を理解することが難しすぎるので、C/C++を置き換える言語にはならない。
それらの概念は学習コストが高すぎるどころか、一生理解できないプログラマが多いだろう。
830:はちみつ餃子 ◆8X2XSCHEME
20/02/13 15:53:13 XX4mj9DD.net
>>805
誤解のないように補足しておくけど、俺は Rust が C++ を置き換えるという主張はしてないからね。
C++ の重大な欠点を (実行コストをあまり払わない形で) 改善しているのは確かってだけ。
そんでもってそれが必要な場面は間違いなくあるってことも。
831:デフォルトの名無しさん
20/02/13 19:21:34 b1nbpqgi.net
>>791
わかる人いませんか？
832:デフォルトの名無しさん
20/02/13 19:29:34 z5cRWLgY.net
>>807
new TYPE[] のようにしてヒープから配列として確保されたメモリは確かに
要素数の情報を持っている。
しかし、new TYPEのように配列ではない場合は、高速化のために情報を
持ってない処理系もある。そのために 前者では delete[] を、後者では
deleteを使うことになっており、間違った組み合わせを使った場合には
不具合を生じる。
また、ポインタは、ヒープから確保された配列ばかりをポイントしているとは
限らず、例えばスタック上のローカルオート変数や、グローバル変数をポイント
していることもあり、その場合には、要素数の情報は全く持っていない。
さらに、Cの場合、関数の引数に TYPE buf[] のように配列を書いても、
TYPE *buf に自動修正される仕様となっている。
そのため、配列を受け取るのは、必ずポインタということになる。
しかし、ポインタで受け取るということは、そこには、&a のように、
ローカルオート変数も実引数として指定して呼び出すことも出来る。
その場合には要素数が無いので、あなたの望みをかなえる高速な
一般的方法が存在しない。
望みをかなえるためには、言語の拡張が必要となる。
833:デフォルトの名無しさん
20/02/13 19:33:05 bRhYdbIA.net
Rustっていろいろ清々しいよね
関数型言語に必須じゃねえのと思うリスト関係がぽっかり抜けてるのは不満だけど
834:デフォルトの名無しさん
20/02/13 19:57:05 WjLTLikp.net
>>807
URLﾘﾝｸ(ideone.com)
835:デフォルトの名無しさん
20/02/13 20:01:17 b1nbpqgi.net
>>808
ヒープに確保した配列の要素数はやはりメモリ上にあるんですね
手段がないのは文法として一貫性をもたせられないからということでしょうか
なるほど、回答ありがとうございます
836:デフォルトの名無しさん
20/02/13 20:08:49 J94ypinO.net
delete [] pと同じように
sizeof [] pを用意すりゃいいのにね
pがnew []されてなかったら誤動作するって挙動ならdeleteと同じだろうに
837:デフォルトの名無しさん
20/02/13 20:15:32 iivZofrB.net
言いたいことは分かるが構文がきもい
838:デフォルトの名無しさん
20/02/13 20:17:34 Y6SS1xK+.net
欲しいなら作れば？
それができるのがc++じゃん
839:
20/02/13 20:36:41.73 ImKshd8q.net
>>791
＞C++の配列は長さの情報を持ってないってことになってるけど
＞長さを与えなくてもdelete[]できるんだから、メモリのどこかにその情報はあるよね？
new したときは、その領域サイズが実行時にユーザーのみえないところに保存される、というだけなのでは？
C/C++ の配列は長さ情報を（自分でそう書かないかぎり）持たないとおもいますよ
840:デフォルトの名無しさん
20/02/13 20:38:39.62 WjLTLikp.net
ちゃうねん。
841:デフォルトの名無しさん
20/02/13 20:50:05.52 qzSQSiwu.net
設計がダメな場合コンパイラにいくら指摘されようと根本的には治らんのだが、
（たいていそういう馬鹿はコンパイラ通すためにmut,RefCell,unsafeを使いまくる）
そういうのを少しもわかってないバカがrust推しなんだよなぁ。
構造体を１から作り直さなきゃならんかったり根本的に間違ってる。
842:デフォルトの名無しさん
20/02/13 21:00:18 sl9OX6cI.net
>>808
new TYPE[]するとき内部的にサイズ情報を持つ保証ってあったっけ？
例えば自前でoperator new []を実装するとき、予め2^nバイトのブロックを所定の数用意しておいて、要求サイズに応じて必要十分な大きさのブロックを返すなら、割り当て時に要求されたバイト数または要素数の情報を保持しないという実装も可能かと思う。
843:デフォルトの名無しさん
20/02/13 21:18:32.64 9NIgZq2/.net
>>811
いえいえ
844:デフォルトの名無しさん
20/02/13 21:37:18.24 Y6SS1xK+.net
>>818
デストラクタ呼ぶ必要ある
845:デフォルトの名無しさん
20/02/13 21:39:24.09 J94ypinO.net
デストラクタ呼ぶ必要ない型だと、size情報持ってないと言うことなんだろうね
846:デフォルトの名無しさん
20/02/13 21:40:36.17 sl9OX6cI.net
>>820
デストラクタの実装も、返ってきたアドレスの値でどのサイズの領域か(割り当て要求されたサイズではなく、自分で区切ったブロックのサイズ)が分かるようにしておけば大丈夫でないかな？
847:デフォルトの名無しさん
20/02/13 21:41:24.98 sl9OX6cI.net
>>822
すまん、勘違いでした。全部忘れてください
848:デフォルトの名無しさん
20/02/13 22:02:22.87 WjLTLikp.net
はい忘れました。
849:デフォルトの名無しさん
20/02/13 22:06:16.93 Bk3UL691.net
アドレスだけじゃなくて長さも受け渡しするインターフェースにしましょうとしか。
850:デフォルトの名無しさん
20/02/13 22:36:33.13 WjLTLikp.net
シリアル化の王道ってありますか？
851:デフォルトの名無しさん
20/02/13 22:45:19.55 iq5JxXln.net
オブジェクトならCORBA、データ構造だけでいいならASN.1とか。
852:デフォルトの名無しさん
20/02/13 22:54:55 tx2lxPGZ.net
>>822
TYPEがデストラクタを持つclassの場合に、ptr = new TYPE[n] で確保されたメモリ
を delete[] ptr とすると、 正確に n 回デストラクタを呼び出す必要がある。
new が n * sizeof(TYPE) より大きめのブロックを確保した場合でも、
delete[] ptr 時に正確な n の値を割り出す方法が必要となる。
なので、n の値は ptr の値さえあれば知ることが出来ることが必要条件となる。
つまり、少なくともデストラクタを持つ TYPE の場合に TYPE の配列をヒープから
確保した場合には、配列の要素数を必ず配列の先頭のポインタの値から「知る」事が出来る。
853:デフォルトの名無しさん
20/02/13 23:01:33 WjLTLikp.net
>>827
もうちょっと簡単なのないですかね。
型情報要らないんで。
854:デフォルトの名無しさん
20/02/13 23:09:58 iq5JxXln.net
型情報が無けりゃデシリアライズしても使いようがあるまい。
855:デフォルトの名無しさん
20/02/13 23:12:32 WjLTLikp.net
それがあるんですよ兄さん。
856:デフォルトの名無しさん
20/02/13 23:12:57 ktN45haN.net
双方向mapって何使うのがいいですか？boostのbimap？
それともこのくらいは自作してる人のほうが多いですか？
857:デフォルトの名無しさん
20/02/14 00:05:24 CPLKNT1n.net
双方向Mapって何に使えるんですか？
858:デフォルトの名無しさん
20/02/14 01:54:24 0WgbwkuV.net
型情報ないならそもそもデシリアライズできないし
型情報なしで成り立つ、つまり型情報を事前に知っている前提なら
バイナリでそのまま送ればいいだろ
859:デフォルトの名無しさん
20/02/14 02:05:36 raWqkpxU.net
型がわかっててもコンテナはそのままではバイナリで送れない
860:デフォルトの名無しさん
20/02/14 02:11:15 CPLKNT1n.net
>>834
そのやり方教えて。
あめさんあげるから。
861:デフォルトの名無しさん
20/02/14 07:52:45.40 RsXMnrpQ.net
ちゃんとやるならPODに詰め替えてからchar配列へreinterpret_cast
862:はちみつ餃子
20/02/14 09:19:01.22 nLeEzkye.net
>>826
シリアル化ってのにどういう要件を置くかだな。
同じ環境でデシリアライズ出来ればよいのであれば >>837 で十分だろうし、
データ形式が決まってて (あるいはデータ形式の側を中心に策定したくて)
それのシリアライズとデシリアライズを (それぞれ別の環境で (ときには言語も違うかも)) やりたいということなら
protobuf などのツールを使うのはよい案だと思う。
863:デフォルトの名無しさん
20/02/14 13:35:07 vZZ7SPTm.net
boostにあるじゃないですか
googleのなんか使うんじゃありません
864:デフォルトの名無しさん
20/02/14 13:41:23 a5iC3cHy.net
>>791
>>807
実装�
865:ﾋ存だと思うけど hoge[-1] あたりに格納されてた
866:デフォルトの名無しさん
20/02/14 13:49:57 rQdJoGM9.net
>>840
VC++の場合、ptr = new TYPE[n] で確保された場合は、確かに
ptr[0] == n
になっていた気がする。
「確かに」というのは言葉のあやで、厳密には覚えてないが、
VC++の new で使われる組み込み関数のライブラリのソースコードを見ると分かる。
867:デフォルトの名無しさん
20/02/14 13:50:28 rQdJoGM9.net
>>841
すまん、
ptr[-1] == n
の間違い。
868:デフォルトの名無しさん
20/02/14 14:03:39 a5iC3cHy.net
>>807
>>841
OSやコンパイラで違うんでしょ
URLﾘﾝｸ(ideone.com)
869:デフォルトの名無しさん
20/02/14 15:26:11.39 rQdJoGM9.net
>>842
あ、すまん、正しくは、大体、
((DWORD *)ptr)[-1] == n
だ。
ptr[-1] だと、sizeof(TYPE)分、アドレスが戻ってしまうし、
結果の型も DWORD とかではなく、TYPE 型になってしまう。
870:デフォルトの名無しさん
20/02/14 15:28:19.59 rQdJoGM9.net
>>843
言っておくが、new char[n] とかでは、駄目な可能性は有るよ。
話は、「TYPEがデストラクタを持つとき」のnew TYPE[n]に限定。
871:デフォルトの名無しさん
20/02/14 17:17:51.62 jFoBh/u0.net
一時オブジェクトの寿命について、ご教示ください。
例えば、以下のようなコードがあった時、
void foo(const char* c); // 外部ライブラリの関数につき変更不可とする
void main()
{
const std::string s = "aaa";
foo((s + "bbb").c_str());
}
一時オブジェクトstring(s + "bbb")の破棄が行われるのは、
関数foo()を呼ぶ前でしょうか、呼んだ後でしょうか。
調べた範囲では、「完全式の終わり」という話が出てきたのですが、
どこまでが完全式なのか判断できませんでした。
872:はちみつ餃子
20/02/14 17:22:07.67 nLeEzkye.net
>>846
この場合はその行の終わり。
セミコロンのところだと思っていい。
873:はちみつ餃子
20/02/14 17:34:07.49 nLeEzkye.net
すごくどうでもいい話なんだけど、
JIS では完結式という用語を使ってるのに完全式って言葉の方がよく使われているよね……。
874:はちみつ餃子 ◆8X2XSCHEME
20/02/14 17:59:01 nLeEzkye.net
>>846-847
式の一部であるような式が部分式で、
そうでないような式が完結式って言う。
875:デフォルトの名無しさん
20/02/14 19:29:16.13 CPLKNT1n.net
>>837-838
ありがとん。
876:846
20/02/14 19:44:55.13 jFoBh/u0.net
>>847-849
ご回答ありがとうございます。
大変勉強になりました。
877:デフォルトの名無しさん
20/02/14 20:52:54 x/oqiD9H.net
おいCぺろぺろ
878:デフォルトの名無しさん
20/02/14 20:58:59 V/oEZCXU.net
>>851
いえいえ
879:デフォルトの名無しさん
20/02/15 10:34:21 BMoFghq4.net
newって意外と速いんだな。
アクセスは不利かもしれないけど。
880:デフォルトの名無しさん
20/02/15 12:11:39.70 DzNKB5Jj.net
>>854
速いよ。
高速なゲームでも普通に使える。
881:デフォルトの名無しさん
20/02/15 12:12:59.04 BMoFghq4.net
でもスタックは常にキャッシュに乗ってるから、そこらへんでどう変わるのかな。
882:デフォルトの名無しさん
20/02/15 13:19:54 J1bovO5o.net
キャッシュに乗るくらいの量だったらそもそもクリティカルな重さにはならんだろ。
newで問題になるのは10万とかそのくらいのオーダーをがっつりfor文で呼ぶとかそれくらいのことする場合。
883:デフォルトの名無しさん
20/02/15 13:21:27 BMoFghq4.net
スタックは常にキャッシュに乗ってる。
884:デフォルトの名無しさん
20/02/15 13:23:13 lTU5fwx1.net
>>857
風邪が騙りかけます
885:デフォルトの名無しさん
20/02/15 14:11:39.55 DzNKB5Jj.net
>>857
VC++の場合、コンストラクタが無い場合、new が必要とする時間は 170クロック。
3.0GHz の CPUの場合、1.7 * 10^7 回(1,700万回)くらい new してやっと一秒
位。
だから、問題になるのは、1万回ループではなく、100～1000万回くらいのループ。
886:デフォルトの名無しさん
20/02/15 14:15:19.79 DzNKB5Jj.net
もちろん、スタック変数で済むならスタック変数の方がい
887:い。 ただ、スタックは容量に限りがあるので全部スタックという訳にもいかない。 ヒープにも限りはあるにはあるが、それは OSやマシンの限界。
888:デフォルトの名無しさん
20/02/15 14:25:57.86 BMoFghq4.net
そこでgotoなんですよ。
889:デフォルトの名無しさん
20/02/15 14:43:25.87 BMoFghq4.net
コレクションがソートの有無でだいぶ変わる。
trie_base_benchmark__sorted_words_1
trie assign.
409ms
size : 466551
words : 466551
trie insert.
762ms
size : 466551
words : 466551
std::set insert.
69ms
std::unordered_set insert.
149ms
(assigned) trie find.
24ms
(inserted) trie find.
25ms
std::set find.
194ms
std::unordered_set find.
63ms
890:デフォルトの名無しさん
20/02/15 14:44:57.19 BMoFghq4.net
trie_base_benchmark__random_words_1
trie assign.
2034ms
size : 466551
words : 466551
trie insert.
2026ms
size : 466551
words : 466551
std::set insert.
490ms
std::unordered_set insert.
146ms
(assigned) trie find.
158ms
(inserted) trie find.
169ms
std::set find.
477ms
std::unordered_set find.
62ms
891:デフォルトの名無しさん
20/02/15 14:46:37.02 BMoFghq4.net
挿入速度が変わるのは仕方ないとしても、検索速度が変わるのは、キャッシュじゃないかと思うんだけど。
892:デフォルトの名無しさん
20/02/15 14:49:41.43 BMoFghq4.net
std::sort: 306ms, (466551count).
先にソートしてから挿入したほうが速度的にお得っぽい。
893:デフォルトの名無しさん
20/02/15 16:03:09.29 0hgUDlXi.net
>>854
速いといっても
単純な演算と比べれば劇遅
894:デフォルトの名無しさん
20/02/15 16:18:40.81 qSK05WKV.net
>>867
とにかく、足し算/引き算が1クロック程度、new が170クロック程度だからね。
使い方を間違えなければ劇遅とはいえまい。
895:デフォルトの名無しさん
20/02/15 16:32:01.46 4O8uAQVX.net
auto hentai = SM(std::move(羞恥心));
896:デフォルトの名無しさん
20/02/15 17:12:18.08 BMoFghq4.net
newより+のほうが速いってことか。
897:デフォルトの名無しさん
20/02/15 17:25:57.34 BMoFghq4.net
+と-ならどっちが速いんだろう。
898:はちみつ餃子
20/02/15 17:49:06.00 cwLPNCdO.net
>>871
回路はほぼ共有してるんじゃないの？
2の補数を使うのもそれが理由なんだろうし。
少なくとも Pentium 時代まではクロックは同じだったはず。
近頃の事情は知らんけど
GCC あたりで強い最適化をかけてみても引き算か足し算を特に避ける様子もないので、
まあだいたい同じなんでしょ。
899:デフォルトの名無しさん
20/02/15 18:01:50.38 zARYy4pH.net
>>870
C++の場合、+ひとつだけでも裏でどんなコードが動くか油断ならない。
900:デフォルトの名無しさん
20/02/15 18:13:26.25 2RWOAy2H.net
>>871
+ と - で速度が違うCPUは見たことがない
- は順番が関係あるので
処理によっては遅い事がある
b = 1 + b
b = 1 - b
901:はちみつ餃子
20/02/15 18:14:19.52 cwLPNCdO.net
整数だけの話じゃなくてってことか。
ある程度の常識的判断が出来る場合もあるけど、
基本的には実装次第だわな。
902:デフォルトの名無しさん
20/02/15 18:19:46.61 2RWOAy2H.net
組み込み型じゃなけりゃそりゃね
+ でミサイル発射とか
903:デフォルトの名無しさん
20/02/15 19:02:33.35 qSK05WKV.net
>>870
new より + の方が 170 倍速いと言うことだ。
904:デフォルトの名無しさん
20/02/15 19:04:43.75 cVttwiPD.net
>>874
一度bをnegateしてから足す処理系があるかもな
905:デフォルトの名無しさん
20/02/15 19:30:46 qSK05WKV.net
>>874
確かに引き算には順序があるので、足し算より最適化に不利になることがある。
906:デフォルトの名無しさん
20/02/15 19:48:11.00 x3vECiAE.net
if(bReaZyuu){
907:デフォルトの名無しさん
20/02/16 00:34:55 pXV6w9YM.net
if (false != bReaZyuu) {
908:デフォルトの名無しさん
20/02/16 00:35:58 pXV6w9YM.net
newが常に数百クロックで済むと思ったら
間違いかもしれん…
909:デフォルトの名無しさん
20/02/16 01:50:35.50 1DEBeg9G.net
経験的にはnewが遅いと思ったことは無い。
なお、コンストラクタの処理時間以外はnewはmallocと同じ速度。
ゲームメーカーでも必要な場合に malloc を使うことは問題�
910:ﾈいとされている。
911:デフォルトの名無しさん
20/02/16 02:03:13.40 MPWqg8uW.net
new からしてmallocを呼んでる実装が多い気がする。
912:デフォルトの名無しさん
20/02/16 02:34:52 yR2k1LO6.net
そりゃnew用とmalloc用でヒープ別けたら無駄だし
913:はちみつ餃子 ◆8X2XSCHEME
20/02/16 02:36:27 VK9AAsv4.net
ヒープからの割り付けをする機会を減らすことで実行速度を上げる工夫はよく聞く話ではあるよな。
ただ、そこまでギリギリのチューニングが必要ってことがあまりないだけで。
914:デフォルトの名無しさん
20/02/16 07:37:50.08 Rlzwkt+8.net
newは最悪値が読めないからなぁ
組込とかシビアなゲームでは使い辛い
915:デフォルトの名無しさん
20/02/16 08:25:44.50 Yy7z+EdH.net
具体的な数字が出てるとイメージが湧く。
916:デフォルトの名無しさん
20/02/16 08:45:53 Yy7z+EdH.net
170クロックならあんまり気にする必要ないな。
917:デフォルトの名無しさん
20/02/16 10:26:07.87 w0IbR+6u.net
組み込みでc++がそもそもおかしい
918:デフォルトの名無しさん
20/02/16 11:00:34.43 1DEBeg9G.net
>>887
よっぽどでない限り、AAAゲームでも使われてるよ。
919:デフォルトの名無しさん
20/02/16 11:01:02.59 B02+i8yM.net
最近では小規模組み込みでもC++を使う事はあります
new / deleteやヒープを無効にしたり
newのみでdelete出来ないようにしたり
なんてこともあります
920:デフォルトの名無しさん
20/02/16 11:03:58.49 +vprjU7s.net
>>890
視野狭すぎ
921:デフォルトの名無しさん
20/02/16 11:12:03 w0IbR+6u.net
また馬鹿が無駄に一般化してできるワイ言ってんのか。。相変わらずだな。
922:デフォルトの名無しさん
20/02/16 11:20:41 +vprjU7s.net
日本語でおｋ
923:デフォルトの名無しさん
20/02/16 11:23:16 Yy7z+EdH.net
ストリームってなんで遅いんだろね。
924:デフォルトの名無しさん
20/02/16 11:39:47 Rlzwkt+8.net
>>891
そりゃそういう例もあるわな
だから何？w
925:デフォルトの名無しさん
20/02/16 11:42:38 Yy7z+EdH.net
スレで、do{}while()はダメっぽいこと書いてあったけど、なんでダメなの？
926:デフォルトの名無しさん
20/02/16 12:30:30 q7JzY0gs.net
>>887
でもお前は組み込みにもゲーム開発にも携わってないじゃん
927:デフォルトの名無しさん
20/02/16 12:42:15 Rlzwkt+8.net
>>899
ごめんねー、俺はプリンタ屋さんなのw
ゲームは知り合いの話ね
928:デフォルトの名無しさん
20/02/16 12:54:36 Yy7z+EdH.net
プリンタ屋さんってどんな仕事ですか？
929:デフォルトの名無しさん
20/02/16 12:58:53 Rlzwkt+8.net
>>901
俺は制御周り、上位インターフェースからのデータを描画ルーチンにに渡したり、下位インターフェースにデータ渡したり、パネルとかの制御をやってる
描画部分はまた別の人がやってる
930:デフォルトの名無しさん
20/02/16 12:59:56.11 Yy7z+EdH.net
なんか難しそうですね。
931:デフォルトの名無しさん
20/02/16 13:01:18.53 Yy7z+EdH.net
プリンタってプロセッサはどんな感じのを使うんですか？
newってあるんですか？
932:デフォルトの名無しさん
20/02/16 13:02:40.97 Yy7z+EdH.net
プリンタのヘッドについてる穴の数は決まっているんだから、あまりヒープが必要無さそうな気もする。
933:デフォルトの名無しさん
20/02/16 13:03:59.79 Yy7z+EdH.net
std::vectorの上にヒープを作っても速度的に大丈夫なことは確認した。
934:デフォルトの名無しさん
20/02/16 13:07:31.29 Rlzwkt+8.net
昔はSHシリーズとかR2000とか
今はARMもそれなりに使ってる
制御だとnewは基本使わない
あと俺がやってるのは業務用のLBP
935:デフォルトの名無しさん
20/02/16 13:08:47.09 Yy7z+EdH.net
ってことはキャノンですか。
936:デフォルトの名無しさん
20/02/16 13:10:53.15 Yy7z+EdH.net
メモ問題は結局ホワイトボード買ってきた。
ホワイトボードをワンノートに撮影するという昔っぽいことに。
937:デフォルトの名無しさん
20/02/16 13:11:07.93 Rlzwkt+8.net
流石に社名までは出せんわw
938:デフォルトの名無しさん
20/02/16 13:12:13.52 Yy7z+EdH.net
ワンノートのアンドロイド版はカメラにホワイトボードのモードがあるんだけど、テカリ消してくれないし、ホワイトバランスも調整してくれない。
939:はちみつ餃子
20/02/16 13:12:31.37 VK9AAsv4.net
PostScript くらいならプリンタの側で処理することもあるし、
世間で想像されているよりは高級なことをやっているんじゃないかなぁという気もする。
940:デフォルトの名無しさん
20/02/16 13:16:21 Yy7z+EdH.net
ってことは、別の人がnew使いまくり
941:なのでは。
942:デフォルトの名無しさん
20/02/16 13:17:17 Yy7z+EdH.net
テカテカしないホワイトボードないのかな。
943:はちみつ餃子 ◆8X2XSCHEME
20/02/16 13:20:18 VK9AAsv4.net
>>914
URLﾘﾝｸ(www.google.com)
944:デフォルトの名無しさん
20/02/16 13:20:51 Yy7z+EdH.net
ありがとん。
945:デフォルトの名無しさん
20/02/16 13:27:19 Yy7z+EdH.net
モーター動かしたりするのはnew使ったらダメなんだろな。
946:デフォルトの名無しさん
20/02/16 13:52:37.96 Yy7z+EdH.net
リアルタイムOSはヒープあるんだろか。
947:デフォルトの名無しさん
20/02/16 14:03:56.47 1DEBeg9G.net
>>900
ゲームに関しては、かなりちゃんとした現場で昔から malloc は使われていたし、全社的に使っても問題ないとされていた。
948:デフォルトの名無しさん
20/02/16 14:33:04.16 Rlzwkt+8.net
>>919
で？
使われてる例も使われない例もあるよ
タイミングにシビアなゲームだと使い辛いと言うだけ
949:デフォルトの名無しさん
20/02/16 14:34:24.22 Rlzwkt+8.net
>>918
最大実行時間が読める専用のヒープを持ってたりするよ
950:デフォルトの名無しさん
20/02/16 14:44:07.47 Yy7z+EdH.net
あるんだ。
951:デフォルトの名無しさん
20/02/16 14:49:10.64 B02+i8yM.net
>>918
ヒープを使うかどうか選べるものが多い
952:デフォルトの名無しさん
20/02/16 14:53:55.58 Yy7z+EdH.net
選べるってことは、用途によって使い分けが必要って事なんだろな。
953:デフォルトの名無しさん
20/02/16 14:59:29.04 D2RmZx9z.net
ループ内で可変長のvector使っているようなのは、外に出してループ始めにclearする方がいい
ループごとにvector出力しなきゃいけない場合も、moveしないでcopyした方がいい
954:デフォルトの名無しさん
20/02/16 15:03:54.38 k775l7KG.net
>>920
意見されたら喧嘩売りたくなる病気なの？
955:デフォルトの名無しさん
20/02/16 15:10:11 D2RmZx9z.net
mallocは使い方が余程ひどく無ければ、性能上問題になることはない
問題になっている場合もプロファイラでその部分だけ対策すればどうにでもなる
断片化やmalloc自体の管理領域容量が気になるほどの環境では使わない方がいいが
956:デフォルトの名無しさん
20/02/16 15:11:53 +ZTPu1gL.net
>>926
それお前じゃね？
957:デフォルトの名無しさん
20/02/16 15:13:28.86 +ZTPu1gL.net
>>927
リアルタイム系の仕事したことないならそう言う考え方でもいいと思うよ
958:デフォルトの名無しさん
20/02/16 15:17:30.49 D2RmZx9z.net
そもそもリアルタイム系の処理で、実処理部分でmallocするってのは普通しないよね
初期化時に必要なバッファはあらかじめ確保しておくものでしょ
そこはmallocだろうが静的確保だろうが変わらないし
959:デフォルトの名無しさん
20/02/16 15:23:06.64 8bxeBykO.net
>>929はループの中で毎回malloc freeしてるからそりゃ性能が気になるよね
960:デフォルトの名無しさん
20/02/16 15:24:31.11 1DEBeg9G.net
>>925
std::vector<TYPE> は、リンクリストではなく、「可変長配列」なので、std::list<TYPE> に比べて、TYPE のコンストラクタがデコボコした頻度で
多めに呼び出されてしまう傾向がある。TYPEのコンストラクタの中で何かをnew していると、new が呼び出される回数をグラフにした場合、
デコボコになるため、速度的に滑らかさがなくなってしまう可能性が考えられる。
それは、newの速度がデコボコなのではなく、std::vector が持つ悪い性質の一つ。
速度的に「滑らか」にしたいならば、std::list の方が適している。
そもそも、C言語がポインタを用意したのは、リンクリストを使いたかったからで、Cはデータ集合用のデータ構造として動的リストではなくリンクリストを用いるのが伝統。
Cの高速性とはリンクリストによるものと言っても過言ではない。
newも、mallocもコンストラクタも、リンクリストと最も相性が良い傾向がある。
cppreferenceなどでも、std::vectorが出てくることが多いが、Cの新かを発揮するにはstd::listの方が良い。
961:デフォルトの名無しさん
20/02/16 15:25:54.32 1DEBeg9G.net
>>932
誤：Cはデータ集合用のデータ構造として動的リストではなくリンクリストを用いるのが伝統。
正：Cはデータ集合用のデータ構造として動的配列ではなくリンクリストを用いるのが伝統。
962:デフォルトの名無しさん
20/02/16 15:27:49.69 D2RmZx9z.net
いやいや、速度がシビアならreserveしとけと
cとの親和性考えなきゃdequeも良いが、cのAPI呼び出し考慮すると結局vectorをうまく使うのが一番良い
963:デフォルトの名無しさん
20/02/16 15:28:20.99 1DEBeg9G.net
>>929
std::vector<TYPE>を使っていて、TYPEのコンストラクタの中でnewするのはリアルタイム処理には向きません。
その場合、std::list<TYPE>に変えれば劇的に速度が安定するはずです。
964:デフォルトの名無しさん
20/02/16 15:30:12.10 1DEBeg9G.net
>>934
CのAPI呼び出しで集合を渡す場合、通常、集合の要素はコンストラクタを持ちません。
その場合は、std::vectorは適すでしょう。
ところが、要素がコンストラクタを持つ場合は、std::listが適します。
965:デフォルトの名無しさん
20/02/16 15:32:54 D2RmZx9z.net
vectorで再配置する際にmoveされない前提なのね
966:デフォルトの名無しさん
20/02/16 15:33:13 1DEBeg9G.net
>>936
補足すれば、APIは、リング0のシステムランドで実装されていることが多いため、
リンクリストの様な複雑な構造が用いられることが少ないのです。
しかし、それはAPIに限った話で、Cは誕生したときから、要素数が変化する
集合には、動的配列よりもリンクリストを用いるのが伝統でした。
伝統と言うよりも、リンクリストこそがCの核心・本質といっても過言では有りません。
967:デフォルトの名無しさん
20/02/16 15:35:27 1DEBeg9G.net
>>937
C言語とはリンクリストのことです。
動的配列は、Cの文化ではありません。
968:デフォルトの名無しさん
20/02/16 15:36:04 MPWqg8uW.net
アドレスで直にアクセスできる言語の強みはリンクリストで活きるからごもっとも
969:デフォルトの名無しさん
20/02/16 15:40:23 +ZTPu1gL.net
>>930
そう言う事
平均的には間に合っても確保や解放にかかる時間が読めなくなる
100万回に１回でもダメならダメっていう世界だしね
>>931とかはそう言うことがわかってないので頓珍漢なレスになってるw
970:デフォルトの名無しさん
20/02/16 15:40:27 pXV6w9YM.net
>>934
reserveしただけだとOSによっては実メモリ確保しなさそう…
で初回アクセスでおもむろにページが用意されれる
ﾖｶﾝ
971:デフォルトの名無しさん
20/02/16 15:42:34 D2RmZx9z.net
それだとmalloc使うこと自体不味いだろ
確率でmmapしちゃうのだから
972:デフォルトの名無しさん
20/02/16 15:44:00.56 pXV6w9YM.net
別に
>>925の前半でおk
973:デフォルトの名無しさん
20/02/16 15:46:21.91 D2RmZx9z.net
もちろん初期化時以外でね
974:デフォルトの名無しさん
20/02/16 16:01:46.00 1DEBeg9G.net
>>937
moveを使いたい場合、要素の TYPE クラスに move 用の記述が必要となるため、手間がかかります。
975:デフォルトの名無しさん
20/02/16 16:01:54.10 Yy7z+EdH.net
is_pod_vで事前条件を確認してるけど、PODはなくなるんだってね。
976:デフォルトの名無しさん
20/02/16 16:02:29.34 Rlzwkt+8.net
>>935
まあお前がそう思うならそうなんだろうな
お前ん中ではな…
977:デフォルトの名無しさん
20/02/16 16:07:00.64 D2RmZx9z.net
listで美味しいのはsplice使いたい時くらいだろ
multi threadのログ統合したい時とかに、lockに必要な時間を最小化出来る
978:デフォルトの名無しさん
20/02/16 16:26:27.54 c8Po0Swg.net
>>947
POD = trivialかつstandard_layout
だから後者を使うようにすればいい
979:デフォルトの名無しさん
20/02/16 17:05:35.53 +vprjU7s.net
子スレッドを休眠状態で作る方法ない？
起動直後にcondition_variable::waitとかじゃなく
初期状態として
980:デフォルトの名無しさん
20/02/16 17:13:29.37 YrNuZAe7.net
何のために？それによる
981:デフォルトの名無しさん
20/02/16 18:53:05 Yy7z+EdH.net
>>950
ありがとん。
982:デフォルトの名無しさん
20/02/16 21:26:26 D0JJuQrX.net
>>953
いえいえ
983:デフォルトの名無しさん
20/02/16 23:16:48.80 B02+i8yM.net
>>924
まあそりゃね
使えるようにしてもPCやスマホのように自由には使えないぞ
こまめに確保解放なんてことはしない
基本最初に確保して終わり
解放はしない
だから確保しか出来ないヒープも選べる
984:デフォルトの名無しさん
20/02/16 23:20:30.34 B02+i8yM.net
>>927
それはPCやスマホなどリッチな環境の場合
>>931
一見軽そうで重い関数があったりするから
同じ人が同じ時に作ってたらそんな処理にはしないだろうけど
985:デフォルトの名無しさん
20/02/17 00:08:48 U44ZlMgK.net
白物家電のマイコンやら、pfcのマイコンやらもやったが、そんなのはそもそもmalloc使うような環境じゃなかったしなぁ
RAMもkB単位で少ないし、自由に関数呼べるほどスタックも無いし
割り込み部分はアセンブリで書いてた
986:デフォルトの名無しさん
20/02/17 00:14:53 /jKzm6f9.net
今は冷蔵庫や電子レンジもAI積んでネットワークに繋がるIoT時代だけど
それでも組み込みって未だにそんな感じなの？
987:デフォルトの名無しさん
20/02/17 00:16:48 U44ZlMgK.net
まあそれは特に東南アジア向けだったし
日本よりさらにチープだったのかも
988:デフォルトの名無しさん
20/02/17 00:19:59 uafn9Eqq.net
>>958
そんなのごく一部
989:デフォルトの名無しさん
20/02/17 00:20:59 uafn9Eqq.net
いまだにチープな8bit CPUもたくさん使われている
990:デフォルトの名無しさん
20/02/17 00:23:25 U44ZlMgK.net
cortex-m0とか載ってたらもう小躍りしちゃうくらいのリッチさだよね
991:デフォルトの名無しさん
20/02/17 00:34:16.83 H8nvOahp.net
リッチなCPUを使うって事は
それだけ求められる事が大きいわけで
992:デフォルトの名無しさん
20/02/17 07:41:59.44 xyBTOgD8.net
でもCPU節約するために人件費かけて結局商品高いじゃん
993:デフォルトの名無しさん
20/02/17 09:22:40.01 usLteeFN.net
趣味じゃないんだから
当然トータルで考えるよ
開発工数、単価、機能性能、信頼性、供給、大人の事情、...
994:デフォルトの名無しさん
20/02/17 10:36:24 sgjaAMaL.net
ゲーム業界の人だけど
new使っても問題ないってのはおれの常識とは異なる
まず問題が広すぎる
言いたいことはデフォルトのグローバルヒープを無邪気に使っていいか
ということだと仮定すると
AAAクラスでそんな杜撰なことしてるところはないと思う
組み込みもそうだがリアルタイム性が必要とされるところでは、メモリ予算というものがある
グラフィック、オーディオ、ネットワークなどのモジュールごとにメモリいくらと決められる
モジュールの責任者はその中でやりくりする
ここで大事なのはメモリの最大使用量を保証しなければならないってこと
必要ならローカルのヒープは作ったりするが、この時点で担当者が気ままにnewってのは認められない
基本的にすべてコントロールされる
現実的に最大量が正確に見積もれないものもあるがそれでも最大量は決める
995:デフォルトの名無しさん
20/02/17 10:57:08.38 sgjaAMaL.net
といってもグローバルヒープを使わないわけじゃない
オープンソースのもので無邪気にmallocするものは多数あるが、それほど荒ぶらなければそのまま使う
(リアルタイム性が不要なら仮想メモリに任せる)
あとmalloc遅くないという論調の人がいるけどそれはベストケースの話でしょう
ヒープメモリが不足したり一度に巨大なメモリを確保する場合はシステムコールになるからずっと遅くなる
ワーストが見積もれないものはリアルタイムで使いづらい
まぁ昨今は仮想マシン上で動くゲームが多数あるわけで気にしなくていいレベルという意見はある
ただesports系で一瞬カつくとか商品性に関わるわけで
また後から直すのも地獄なので
最初から計画的に作るべきだろう
996:デフォルトの名無しさん
20/02/17 11:06:49.04 tDJaHp5K.net
ここC++スレだよね、つかぬことだけど
記憶管理はいつでも如何様にもカスタマイズできるようにtypename Allocatorになってるわけじゃん
なんでいきなり組み込みには向かないとかキリッてんの？
997:デフォルトの名無しさん
20/02/17 12:20:34.06 ipOy1V1j.net
>>968
typename Allocatorとかすげぇ初心者っぽい
キリってるのはお前だ
998:デフォルトの名無しさん
20/02/17 12:22:54.84 tDJaHp5K.net
>>969
ｋｗｓｋ
999:デフォルトの名無しさん
1000:sage
>>968 標準ライブラリでもallocatorが指定できないものもあるんだよ もはや今のc++で標準ライブラリを全面的に使いつつ、ヒープを個別に差し替えるのはかなり非現実的だ allocatorを差し替えられてもnewするタイミングや量はリバースエンジニアリングしないとわからない それが問題になることもある
1001:デフォルトの名無しさん
20/02/17 12:48:18 2c+OKT/4.net
てか、静的確保したメモリブロック使うアロケータ書いてそれで標準コンテナ使うのが基本じゃね
まあeastlでも良いが
1002:デフォルトの名無しさん
20/02/17 12:51:50 tDJaHp5K.net
>>971
> 標準ライブラリでもallocatorが指定できないもの
例えば？
newだってoperator newですぐカスタマイズできるし
placementで環境依存の細かい設定もできる
ライブラリはISO/IEC14882に固執する必要はなく
サードパーティでも内製でもより都合のよいほうを使えばいい
というだけの話
1003:969
20/02/17 12:56:55 nfQInp9b.net
カスタマイズの話なら真っ先にnewの話をすべきなんだが順番おかしくね？
ていうか今時はallocatorより先にpolymorphic resourceだと思うが
というかそもそもmallocの速度の話からであって、いきなりallocatorの話したり
C++全体を否定されたかのように過剰反応するとか・・
1004:デフォルトの名無しさん
20/02/17 13:12:34.13 y136Nw0W.net
仕様通りに書けばいい感じにうごいてくれて、責任は俺にはないとか
思い込んでんじゃってるキッズなんだろう。
デバッグするなんてことはもちろん頭にない。
1005:865
20/02/17 13:34:28 FC0zZXW0.net
>>890からの流れでは直後からnewが出てきてたろ
C++が組み込みに向かないという主張の
理由がmallocじゃおかしいだろ
それしか使えんわけでもなし
1006:デフォルトの名無しさん
20/02/17 13:44:11 nfQInp9b.net
>>968に突っ込むと>>890に同意したことになるのか
1007:デフォルトの名無しさん
20/02/17 14:00:21 sgjaAMaL.net
>>973
> > 標準ライブラリでもallocatorが指定できないもの
> 例えば？
でしょ？
お前さんは人並み以上にc++知ってると思うけどこの事実知らない
どこで使われてるか知らなきゃ置き換えができないよね
答えはあえて教えない
標準ライブラリのヘッダーをnewでgrepすればallocatorを通さないものが見つかるさ
自分で確認してこりゃ置き換え無理だわと悟って欲しいw
もし見つからないなら後で書くよ
ちなみにグローバルにnewを置き換えるぐらいならmallocのバイナリを差し替えた方が早いし確実
1008:はちみつ餃子 ◆8X2XSCHEME
20/02/17 14:31:40 qpTD/rYC.net
おっ。
野党みたいなことを言い始めたぞ。
1009:デフォルトの名無しさん
20/02/17 14:37:47 nfQInp9b.net
>>979
横からだが、具体的に誰のどこを指してそう思ったのかよろしく
1010:デフォルトの名無しさん
20/02/17 14:59:36 QYRwM+i2.net
>>966
もちろん、むやみやたらと使って全く問題ないわけではない。
が、本当に必要な箇所で使う程度なら(多くの場合)余り問題ないという程度。
大体ゲームの場合のnewやmallocは、敵や弾やイフェクト、3Dオブジェクトなど
を1つずつ収めるために使うことが多いが、ゲームの1シーン内に登場する個数が
newやmallocが問題ない程度に元々なっている事がわりと多いと言うだけ。
3Dの雑草の葉っぱ一枚単位で new したりすると問題になってくるかもしれない。
1011:デフォルトの名無しさん
20/02/17 15:51:15.09 sgjaAMaL.net
>>981
なんとも感覚的な話だね
だいたい動けばOK！って感じ？
おれは仕事でそういうもの作りはしない
1012:デフォルトの名無しさん
20/02/17 16:08:54 HCTe1ZqE.net
コンシューマかPCかでも違うだろうし
（自分はさほど詳しくないが、基本コンシューマは標準ヒープ使わないはず）
ジャンルによっても違うんじゃね
PCのMMORPGなんかだとシーン中のメモリ確保は必須だろうし
あと草は普通同じメッシュやテクスチャ使うだろうし、揺れを入れるにしても一つ一つにデータ持たせるなんてアホなことしないだろ
1013:デフォルトの名無しさん
20/02/17 16:15:08 tDJaHp5K.net
>>978
「後で」かｗ
もう1000間近だし期限切らないでおけば時効だろってか？
1014:デフォルトの名無しさん
20/02/17 16:32:36.59 y136Nw0W.net
いやそれくらい調べろって話だろ。。馬鹿が。
1015:デフォルトの名無しさん
20/02/17 16:44:43.28 tDJaHp5K.net
>>985
sgjaAMaLが、自分の話に傾聴してきた人の質問に答えなかった
つまり自分の考えを伝える努力を中止したということでしかない
何人も自らの意見を他人に伝えるには
その意見を説明するしかなく
説明をやめることは沈黙に等しい
1016:デフォルトの名無しさん
20/02/17 16:55:56.23 9WiS2n1W.net
黙って調べてくれば？
調べて無いと結論づけられればまた偉そうに出来るだろw
1017:デフォルトの名無しさん
20/02/17 17:15:39.87 9Dh9neDd.net
ちゃうねん。
僕が組み込みいうたのはArduinoのことな。
RAM2KBやし。
1018:デフォルトの名無しさん
20/02/17 17:31:33 9Dh9neDd.net
Arduino面白いよ。
1019:デフォルトの名無しさん
20/02/17 18:25:59 sgjaAMaL.net
>>984
条件は明示してるんだからおれが書くかはお前に委ねられている
1000が迫っているぞw
1020:デフォルトの名無しさん
20/02/17 18:30:32 T3Z0MUY2.net
この手の人最後まで答えないか
答えても的外れなのしか見たことないわ
1021:デフォルトの名無しさん
20/02/17 18:32:18 wtNXL+i7.net
だね
消えて良いよ
1022:デフォルトの名無しさん
20/02/17 19:27:27 XybgTXf7.net
>>978
std::arrayとか言わないよね
1023:デフォルトの名無しさん
20/02/17 19:33:45 nfQInp9b.net
arrayのどこに動的メモリ確保が出てくるんだよ
アホか
1024:デフォルトの名無しさん
20/02/17 19:46:45 9Dh9neDd.net
なぞなぞですか。
1025:デフォルトの名無しさん
20/02/17 23:00:17 HZSaiYXA.net
漏れはnewのときたまの遅さの可能性に警鐘を鳴らしたからｾﾌｾﾌ、
1026:デフォルトの名無しさん
20/02/17 23:06:03 HZSaiYXA.net
やっぱnew/deleteのレイテンシーを設計に乗せるには非ページプールメモリにアロケートするべきですよねー
1027:デフォルトの名無しさん
20/02/17 23:19:17 sgjaAMaL.net
なんかスレ止めてたら悪いから書いておくよ
ひとつは17からallocatorがdeprecatedになったstd::functionね
これは結構知られてるばずだ
定期的にこれ濫用する人が現れるんだけど中身理解してから使うか判断しろと職場では言っている代物
もうひとつあげるなら、
処理系によってかなり違うかもだけどstd::threadも中でこっそり内部クラスをnewしてるはず
ただスレッド間で引数を引き渡すためのものでサイズは小さいしスレッド作るコストの方が遥かにでかいから問題にはなりにくい
他にもあるけどとりあえずこんなもんで
1028:デフォルトの名無しさん
20/02/17 23:46:06.60 HZSaiYXA.net
std::functionを使わないと1 bitもプログラムが書けなくなった漏れｶﾞｲﾙ、
クロージャをいちいちクラス定義から手で書く日々に戻るのはいやじゃー
1029:デフォルトの名無しさん
20/02/17 23:54:13.03 HCTe1ZqE.net
1000なら>>986, >>991-992が土下座
1030:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 17日 3時間 0分 7秒
1031:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています