STLつかうと一気に実行ファイルサイズが10倍に?！
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？
#include <stdafx.h>
後死ね。
言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。
---- テンプレ ここまで ----
std::functionを使うなと言われたのは残念だが
newのときたまの遅さの可能性に警鐘を鳴らしたから勝利宣言しちゃおうかなっ
かなっ
function・・・それだけか？
なんか組み込みにC++は向かないとまで
大きく出る理由として弱すぎね？
あ、IDは気にしないでね
スレ主としての発言じゃないよ
乙
それ言ってたのは別の人だし過剰反応しすぎだろ
というかあのキッズを叩くと必ず単発煽りが出てくるのは恐らく同一人物だろうな
>>3
標準ヒープ使われてもいいなら使えばいいじゃん 君は誰？
組み込みにC++は向かないなんて思ってないなら
俺はそれ以上言うことないけど
＞標準ライブラリでもallocatorが指定できないものもあるんだよ
の人ではないよ
というか何がそんなに気に入らないのかね
組み込みに向かないと言ってた人はArduinoがどうこう言ってたろ
実際RAMが少ない環境ではかなり慎重に使わざるを得ないんだろ、知らんけど
std::function は (呼び出しの型が一致さえすれば) どんな関数オブジェクト (または関数ポインタ)
でも格納できるというのは強いんだが、
実際にはコンパイル時に型が確定できる場合の方が多いと思うので
std::is_invocable_r で制約を付けた方が少し性能は良いと思う。
でもテンプレートって型引数ごとに実体化されちゃうから、
素朴に考えると引数をラムダ式で与えてたら呼び出しごとに実体化されることになっちゃうよな……。
(最適化で上手く統合されることもあるかもしれないけど。)
どちらを選んでもいいことばかりではないので、結局は場合によるとしか。
>>9
何がってそのままだよ
組み込みにC++は向かない、という意見に反対だ だから過剰反応しすぎだろ
functionの話してた人はゲームだろうが
反対するなら根拠を示せばいいし
少なくとも別の人の話は混同するな
>>10
ラムダなら実体化っつっても毎回関数オブジェクト作るのと変わらんやろ IDなんかアテにならない
基本的に匿名掲示板なんだから
人違いはそう言えばいい
もっとも、それを信じるかどうかは別だが
まさか前スレID:tDJaHP5Kじゃないだろうな？
>>15
いや俺tDJaHP5Kだよ
過剰反応するなっていうおまえさんこそ
なんでそんなにとんがってるんだ？
色々勘ぐってしまうぞ ＞「後で」かｗ
＞もう1000間近だし期限切らないでおけば時効だろってか？
こんなん書いてよく開き直れるな
側から見てて気分悪かったぞ
ちなみに俺は前スレnfQlnp9bな
>>17
それは妥当だろ。
あの場面ではライブラリにアロケータを指定できない場合があると主張しながら例を示さない
のは議論の仕方がわかってないクズだし、そういう奴に遠慮してたら話が進まねーよ。
2ch って元々そういうところじゃん。 ああ、あいつか
元々newの話だったのに
mallocの話だってクレーム垂れてきたやつね
は？頭湧いてんのか？
最終的に例出されたなら反論か謝罪かどっちかだろ
そこで逃げるという選択が取れる方がよっぽどクズだと思うがな
毎回荒れる原因作ってんのお前らだろ
さんざん煽って言い返せなくなったら別人に成り済まして単発煽り入れたり
マジ邪魔だわ
それから俺は元々特定のレスや人物に異を唱えたわけではなく
流れ全体に対しておかしいと思ったことを言ったのが968だったぞ
>>20
前スレで野党に喩えたのはそういうとこね。
事実関係は議論の前提だから、共有しないで先延ばしする理由はない。
カルトクイズに答えられない相手を見て悦に入るようなやつがクズでなくてなんなんだ。 だいたい喧嘩売ってきたのは978で
それまで平和的に話していた俺が
ひとこと言い返したのだけ取り上げて
気分悪いとかどういうバイアス持ってるんだよ
＞前スレで野党に喩えたのはそういうとこね。
それはどうでもいい、問題にもしてない
＞カルトクイズに答えられない相手を見て悦に入るようなやつがクズでなくてなんなんだ。
悦に入ってたかどうかは本人に聞け
というか調べ方は出してくれてただろうが
お前も都合の悪いことからはとことん逃げるから、悪いが相手したくない
>>24
>>978もそれまでのお前の態度と同程度には平和的だと思うが
どういうバイアス持ってるんだよ
悪いがもうキチガイキッズの相手はしたくない、絡んで悪かったな 自己弁護にしか見えねえ
どうやら勘ぐりは当たってたようだな
アホか
俺が前スレ>>978本人だったらもっといじり倒してるわ MinGW のライブラリを見てたら std::function にも SSO が入ってる。
データメンバの総計が 16 バイト以下の関数オブジェクト (キャプチャした変数が少ないラムダ) なら new は呼ばれない。
※ string ではないのにこの最適化を SSO と呼んでいいものなのかどうかわからん
※ 16 バイトというのは環境によるだろうし、 SSO がないこともあるだろう
※ とはいえ、主要な実装ではだいたい有ることを期待できるのではなかろうか
間接参照にはなるから std::function はわずかにコスト高には違いないかもしれないけど、
ちょっとしたことに使う分には急激に実行コストが上がるというほどではない。
リソースの限られた組み込み環境だといずれにしても基本的なライブラリも
自前で用意せざるを得なかったりもするだろうし、
標準ライブラリをフルセットで使えるほどの環境ならみみっちくリソース消費量を抑える必要もないだろうから、
使いどころが適切であれば全体としてはあまり問題にならなさそうという感想。 (あくまでも個人の感想です！)
僕はArduinoこそC++パワーが必要と言ってるんですよ。
Arduinoは様々な亜種があるので、テンプレートでゴニョゴニョすると、何かいいことが起きるのではないか？
そんなことを議論してほしいわけですよ。
メモリーは2KBしかないけれども。
ちなみにエルチカとこんな感じ。
最大32256バイトのフラッシュメモリのうち、スケッチが932バイト（2%）を使っています。
最大2048バイトのRAMのうち、グローバル変数が9バイト（0%）を使っていて、ローカル変数で2039バイト使うことができます。
>>33-34
僕って誰や？
ランタイムのパワーが必要ないものはリソースの少ない環境用に積極的に活用するべきだとは思う。
Arduino についてはよう知らんけど、ドキュメントを見た感じだと type_traits のような
(実行時の) マシンパワーが要らないようなものまで除く必要はないやろという気持ちになる。 C++標準ライブラリはないけどテンプレートは使えます！
魔術師が活躍する舞台として最高だと思いますが。
なぜ参入してこないのか。
Running 5 test cases...
---------- std_algorithm__adjacent_find_1 ----------
std::vector<std::uint32_t>
size(): 104,857,600
std::adjacent_find: 66ms
---------- std_algorithm__is_sorted_1 ----------
std::vector<std::uint32_t>
size(): 104,857,600
std::is_sorted: 66ms
---------- std_algorithm__sort_1 ----------
std::vector<std::uint32_t>
size(): 1,048,576
std::sort: 119ms
---------- std_algorithm__unique_1 ----------
std::vector<std::uint32_t>
size(): 5,242,880
std::unique: 4ms
---------- std__vector__copy_1 ----------
std::vector<std::uint32_t>
size(): 104,857,600
copy assignment: 220ms
new std::uint32_t[]
size: 104,857,600
std::memmove: 55ms
*** No errors detected
>>30
SSO = Small-string optimization Arduinoも一応newは使える。
使わないけど。
>>44
new を使わずに、かわりにどうすんの？ 基本的にグローバル変数を駆使するしかないけど、結構強烈に最適化かかるので、意外と2KBで何でもできる。
プログラムが極端に小さいなら高度な抽象化をする甲斐がない。
抽象レイヤを挟むことで綺麗になるよりも複雑さが増すだけになりがち。
本当に使いまわす部品は綺麗に整理するに越したことは無いけど、
メモリ 2KB かそこらの環境ならベタ書きで十分でしょ。 (YAGNI 原則)
C++ が組み込みに向いていないとは言わないけど、
そのレベルで極端にリソースが制約されている状況では必要でもないと思う。
パソコンでは、恐れることなくnew使って良いと思うけど、static_vectorというのも自作した。
>>48
もちろん単にやるのが楽しい！ というのも動機としてはありうるので趣味でやる分にはどんどんやったらいいと思うけど。 >>48
まあ確かに。
でも使いまわし出来ると便利だし、C++なら...やってくれる！ いやいや、固定小数点とか組み込みだからこそのtemplateがふさわしい場面は結構あるよ
>>49
どういう意味で static なの？
大きさが固定ってこと？ ストレージ内蔵だけど内蔵キャパまでの可変長対応とかかね
知らんけど
>>54
std::arrayにsize()をプラスした。 std::arrayは最初からsize()持ってるんだけどどういうこと？
static_vectorってまんまboostにある
最大の長さが確定してるvectorで
メモリ確保は初期化時だけってやつ
それこそ組み込みやゲームでは有用
上の人のと同じかどうかは知らんが
>>11
向くか向かないかなんて主観なんだからそこを力説してもしゃない
向くと思うなら自身の経験をもとに定性的に説明してみなはれ
あと組み込みってもピンキリだから
マイコンでモーターをPID制御するのと、
組み込みLinuxでメディアサーバー作るのとでは全く異なる世界
そこは区別しないと意味ある議論はできないね
後者は両論あるだろうけど前者はどうだろう？
そもそもモダンなc++で開発できる環境あるのかな？ >>59
駄目ですか？
使えるなら使っていいンじゃなすか？ YAGNI // "You ain't gonna need it" : 機能は実際に必要となるまでは追加しないのがよいとする。
Ajail 開発
↑こういう開発哲学の様なものは他にどんなものがありますか？
真逆の哲学でも構いません。
>>63
【KISS の原則 (英: KISS principle)】
「Keep it simple stupid.」（シンプルで愚鈍にする）、もしくは「Keep it simple, stupid.」
（シンプルにしておけ！この間抜け）、もしくは「Keep it short and simple.」（簡潔に単純にしておけ）
という内容の、1960年代の米国海軍において言われた、経験的な原理・原則の略語。
その意味するところは、設計の単純性（簡潔性）は成功への鍵だということと、不必要な複雑性は避けるべきだ、ということである。
【なし崩しの機能追加主義】
KISSの原則に反して、仕様が徐々に複雑化していくことは、ソフトウェア開発の世界でよくみられる。
これは、「なし崩しの機能追加主義」として知られる。
ソフトウェアが複雑になるにつれて、使い方を習得する時間が増えたり、操作に手間取ったり、どれが重要な機能なのか分からなくなったりする。
さらには、ハードウェアへの要求スペックが高くなったり製品価格が高くなったりもする。
しかし、大多数のユーザーが実際に使用する機能は、そのごく一部であったりする。
ユーザへの負担や開発コストを考えると、単純なソフトウェアの方がユーザフレンドリかつ生産性が高い可能性がある。 KISSの原則、俺は正しいと思う
オーバースペックなものを作っても、その「オーバー」な部分が
あとで必要になったとき不十分なんてことが起きやすいからな
案件の「今」を最大限に最適化するのは義務と言ってよい努力だし
なし崩しの法則は、変更要求に対する不適切な対応が積み重なって起きることだ
既存のソースコードや回路図の微修正で済ませようとするあまり
それまでの反省を踏まえてきれいにリメイクすれば解消する問題が
ずっと影を落とし続ける現象はそこいら中あふれかえっている
車輪の再発明なんて例えをよく見かけるが
じゃあ今の車輪はまだ木で出来ていたり
パンクしやすいチューブタイヤだったりするのか
進歩の原動力たる、たゆまぬ努力に対する
アイディアキラーは見逃しちゃダメだ
>>63
契約プログラミングとかもそうかな？
C++20 にサポートが入る予定だったが、次以降に延期された。
まあ言語としてのサポートがあろうとなかろうと関数が機能するための前提条件
を意識したり明記したりするのは良いことだと思う。
文芸的プログラミングという考え方もある。
説明文とコードを分離せずに書くようなもの。
提案者 (クヌース) が考えていたのは文章説明を中心にする考え方で
コードの方が従属するようなものだけれど、
コメントとしてドキュメントを書くようなものなら doxygen や Javadoc はよく使われているね。
コードを書いているときはちゃんと把握できているからドキュメントを後回しにしがちだし、
コードがドキュメントであるようなものが理想とか言う人もいるんだけど、
数日前に書いたものさえ割と忘れるのが人間なので文書で残すのは大事だと思う。
テスト駆動開発も割とメジャーかもしれない。
仕様をテストコードとして書いて、それを満たすように実装を進める手法。
テストできるように作らなければならないという点で実装に制約が付くのが嫌われがち
ではあるようだけど、仕事でやる開発なら客にアピールしやすい気がするなぁ。 doxygenで作られたドキュメントあんま役に立たないよ
特にテンプレートリッチなコードだと余計なものや個々の実体化までドキュメントに入る
まぁそれを避ける方法が無いわけではないしdoxygen用にコメントをきっちり書くのは良いことなんだけど
>>67
車輪の再発明っていうのは、車輪を知らないで「発明」することだよ。
既に普及しているものを知らず、学ばずに思いつきでやって既出の失敗を繰り返す愚かさを言ったもので、
学んだ上であらためて自分で作ることや改良することを否定してはいない。 >>69
個別のツールについては私は良く知らないんだ。
ここではドキュメントとコードを同時進行で作るという考え方の話。 >>70
ところが、「車輪の際発明」と言って批判する人こそが、全く試しもせずに妄想していることも多い。
この言葉をインド人が言っているのを見て、だから後進国のままなんだな、と思った。 車輪を題材にした慣用句であり、世界中で使われている。
「広く受け入れられ確立されている技術や解決法を知らずに（または意図的に無視して）、
同様のものを再び一から作ること」
を意味する。
MS officeのフリーの互換製品を作ることは違う
>>70
同じことだ
学生や新米が何か思いついて実験してみてるところへ
身も蓋もないことを言ってやる気なくさせる老害は進歩の邪魔だ パーキンソンの凡俗法則
どうでもいい話題ほど紛糾する
車輪の再発明がどうとか
gotoがどうとか
>>76
俺、サラリーマンやってた頃は
手が空いたとき色々実験してたよ
向上心のないやつを蛇蝎のごとく嫌う上司だったし >>75
それは思いつきとは言ってもまだ学びの段階の中の話でしょ。
学ぶためにやってるのなら別にいいよ。
学習段階によって当然知っているべきことを学べてないなら軌道修正はするべきだが。
程度問題とか状況というものもある。
上にあげたような方法論がある程度の確立はしているとは言っても、
業務に取り込むにあたっては色々と試行錯誤はあるもんだしな。
>>76
仕事に必要な学習なら業務時間中にやるべきだし、
そのための時間が与えられないなら会社が学ぶなという方針なんだろう。 学ぶ？
毎回プロジェクト初めに同じものを同じだけ時間かけて作り直すのが学習？
前のを使えよ
プロジェクトが始まったらニコニコ顔で同じ作業を同じように繰り返して
夜になったら必要もないのに残業してふーってニコニコして仕事
ある程度満足したら帰る
そしてプロジェクト終了間際には死んだような顔をしてこんなの間に合うわけないとか言い出す
車輪の再発明にかけた時間をそこに回せよと
プロジェクト始まったころにSEが間に合って仕様書も来てないのに意味もなく残業してるやつら
何をしてるのかと思うと勉強しようと思ってとか言って全然関係ないことをしてる
家でやれよバカ
死ね給料泥棒
× SEが間に合って
○ SEが間に合っていなくて
業務でやるならそのあたりのバランスを決めるのは管理者の裁量次第だろ。
>>80
自動化できるものは自動化すべきだね
コピー一発で済むものとジェネレータがいるのとある
俺、ジェネレータ作るの楽しくて好きだ 学習に時間を使ったのに同じように失敗する馬鹿。
糞シンタックスを覚えることに時間かけるんじゃなくて
普通にメトリック取ったりテストコード書けって話なんだが、理解できないのだろう。
> 俺、ジェネレータ作るの楽しくて好きだ
この場合のジェネレータって一体何？
同じものを1度作っても2度目作れない
同じくらい時間はかかっても2度目作ると3度目は作れるようになっている
それは無駄ではないと思っている
海外の掲示板で「車輪の再発明」することを馬鹿にしていたもう一人の人は、哲学科出身で、宗教関連の発言ばかりしてる人だった。
理系ですらない。
自分では作らずに口だけ達者な人だった事が追跡できた。
全然関係ないことを持ち出して
自分と意見の違う人を馬鹿にできたつもりになってるやつは
論理的な思考が極度に苦手な、理系文系以前に無学なやつだ
>>92は車輪の際発明を馬鹿にする人が一人しかいないという命題に対する反例
としては全く正しい >>82
プロジェクトを効率よく回した方が良い
あと残業を作業者自身の裁量に任せるのはシステムがNG
裁量労働は結果責任を果たせば会社が回るクラスの仕事をしているハイクラスな奴用
SEが必要なときに前の仕事が終わっていないかもしれないからロックしておくというケースで
前の仕事が終わったSEが次の仕事のスタートまでの間、
定時内に会社で独学するのは別段怒るほどのことではない ここ老害のおっさんばっかりだからな
ところ構わず自分の言いたいことを言いまくる
はいおっさん続きどうぞ
他人が自分と違う意見を持つ事実を受け入れられず拒否反応するだけな幼児性は無学のさらに以前の問題だ
「車輪の再発明」という言葉は、加工貿易しか生きる道は無い日本を必ず衰退させる。
車輪の再発明すら出来ない無能にはこの上なく都合のいい言葉だなｗ
>>101
実際、最近では同じ事を作ることすら出来なくなっている。 教育や訓練でやっていることは「車輪の再発明」だよ。
>>103
というか、ホリエモンロケットもアポロのエンジンを真似ているだけとされるのに
何度も墜落したり、三菱のジェット機(旧MRJ)もボーイングなどとほぼ同じような
ものだけど、納期を大幅に延期しまくっても完成できてないように、同じものを
作るということですら簡単では無い事がある。
逆に言えば、ソフトウェアでも売り物と似たようなものをフルスクラッチで作れたと言うことはなかなかの技術力があったということ。 >>79
学生と新米と言ったがそうでない者が
既存のものを知った上で再考することだってある
最初に出した例えで、木でできた車輪や
チューブタイヤがあるのを知った上で
さらに進化できないかなんて話は珍しくもない
そこへ木の車輪があるのに何をしてやがると
突っかかるのをやめるべきだと言っているんだ
人がどんな目的で実験しているのかを
勝手に決めつけている点も問題だ >>105
学んだうえで改良しろってのは最初から言ってることで、そこは否定してないじゃん。
何言ってんの？
そもそも >>75 で出てきた老害ってのはどっから湧いて出てきたんだよ。
お前が文句付けてるのはお前が言い始めた老害に対してであって俺じゃないだろ。 マ板でやれって言われてるのはそういうとこだよ。
困った老害がいるのならそりゃ大変ですねとは思うが、
C++ 板で言っても知らんがな。
美術科の大学生が200万円自腹かけて作った卒業制作品に買い手がつかないのも「車輪の再発明」ゆえの想定内。
というかはちみつはあくまで趣味グラマなのにプロでやってる人の事情に知った風な口きいて首突っ込むから
それに反論すると必ず話がややこしくなる
スルー推奨
プロでも環境によって全然違うのに、一律に使えないと断定するから反発されているってのが目立つと
組み込みやコンシューマのゲームに限定しても使える、使えないは変わるのだから
まあc++の思想としてどんな状況でも使えるユニバーサルな言語を目指してるってのは
あるからな。真に受けて馬鹿が狂信するってのはある意味では不思議じゃない。
>>106
おまえさんは何か思いついたとき
その思いつきと同様の先人の業績をいちいち調べ上げるのか
俺はそんな悠長なことをするより即やってみたい
調べるのはそのあとだ
木の車輪だって自分でやってみなきゃ気持ち悪いし
アンプは量販店で買えても回路組んでみたい
パンピーとハッカーの違いはそこだろ 「板違い」というが、議論と言うのは多岐に渡って派生しても良いもので、それでスレッドが機能不全になってしまうのは、コメントがツリー状にできない2ch/5chそのものの問題点。
>>115
>おまえさんは何か思いついたとき
>その思いつきと同様の先人の業績をいちいち調べ上げるのか
ここ、気持ち分かる。
なんでもやってみる前にすぐに調べようとする弊害と言うものが指摘されている。
調べずに自分の頭でやってみることが脳を鍛える。 >>115
車輪の再発明という言葉が出たからその意味に当てはまらない場合だと思うと私は言ってるだけで、賛否の意見は無いよ。
所詮は俺は趣味人だもの。 エンジンやモーターとかなら他社のものを買ってきて分解すれば学べるが、
プログラムの場合、自分で小さなものから作った方が学べることが多い。
既に出来ているものは複雑すぎて本質を学ぶのは難しいし。
それにFOSSはなぜかサイズが大きくて無駄が大きいことが多い。
stdにあって条件的にそれで十分なのに、わざわざ劣化版作る奴には車輪の云々って言葉が当てはまる
大体そう言うのバグっているし
Arduinoやってみた感じでは、組み込みにもC++は有効だな。
static_vectorはダブル・アレイのリロケートに使った。
ダブル・アレイで一番効果あったのは、解放されたノードをリンクリストにつなげるときに、整列させるのが一番効果あった。
ダブルアレイは挿入でさえノードの解放が発生するので、確保・解放を壮絶に繰り返す。
この時、リストの末尾に追加するなら、何も計算が必要ない。
整列させるなら検索が必要になる。
ところが、整列させた方が挿入も検索も早くなるという結果に。
すべてキャッシュだと思う。
ちなみにヒープはstd::vectorの上に作った。
std::vector単体のベンチとると遅いんだけど、実用上はそんなに遅くない。
そういうわけで、最近はstd::vector上にヒープ作るの流行ってる。
キャッシュに乗るか乗らないか、それが人生のすべてだと思う。
ツリーも試作してみたんだけど、std::vectorの上にヒープ作った。
ヒープの何が良いかって、そのままserializeできるとこだと思う。
今はwindows案件ばかりだけど
数年前くらいまではlinuxばかりだった
LL以外はほぼc++のみ
車輪の再発明は結果的にそうなるというものであって
そういう現象なのであって
良いも悪いも善も悪も
ないお
真に手間をかけたくなくて時間が惜しい当事者ならアルゴリズム辞典ぐら普通当たるし
そうではなくて他者とか部下が車輪の再発明に時間を浪費するのが我慢ならないのなら
正解を提示してやるべきだろうJK
マ板でやれ、
文明を0からやり直すとか
糸車と水車でコンピューターを作ることとか
いろいろ
>>135
何かをやりかけた人をやめさせて、それ以上発展させないようにするために使われる言葉かもしれない。 >>137
もう一つは、既存のプログラムのステークホルダーが、新しく作らせずに既にあるものを使わせようとするための口実や詭弁かも。 この言葉、NPO団体勤務の人が使っているのを見た。
偉そうなこと行ってるけど、実績も学歴もたいしたこと無い。
とある掲示板を見ていたが、この言葉は「その人の中では正しい」だけだと思った。
彼によれば、「自分で書くより既存のものを使ったほうが、大抵の場合は優秀だから」
ということであるが、それは彼の場合であって、自分で書いた方が優秀なものが出来上がる確率が高い人には当てはまらない。
要はIQが人並みを遥かに超えた人と、人並みの人の場合では異なってくる。
メンデルの遺伝の法則とか車輪の再発明がもう何度目だナウシカ状態、
そもそも自分が優秀だと勘違いしてるヤツだからこそ
糞の山を量産して満足げなんであって
自分の愚かさを理解できてるやつは
糞の山作りかけてる時にそれに気付いて引き返す
なんで既にあるものをそんなにもう一回作りたがるの？
めんどくせえじゃん
わかったC++の話にもどろう
まずはC++で効率のよいコレクションクラスの実装について・・
>>144
ねえ、プログラマなんて既に数え切れないほどいるのに
なんで自分もなりたがるんだろうね
他の職業にもすべて当てはまるね
無職がいいの？ あ、死ねって意味じゃないよ。死者の数はもっと多いのでそっちの方がもっと不要。
「自分の愚かさを理解できてるやつ」
これはみんなが同じ力量であることを前提にしていて、こういうところが嫌だ。
天狗になるのも、どうせ馬鹿だからと居直るのも
正反対のようで共通点がある
この分野はレベルの差が大きいので、一般レベルからは有り得なくても天狗とは限らない。
gotoの次は車輪か。
テンプレに付け加えていけよ。
記録することで無駄な議論を減らすってあたりまえのことができてないから
馬鹿なことを何回でも繰り返すんだよ。
安倍政権といっしょでさ。
gotoの話はみんな通る道なんだよ
後輩が議論するのを邪魔してやるな
>>154
おまえみたいな馬鹿にうんざりしてるとこだよ。。
馬鹿はゴキブリみたいなもんだからな。 std::vectorはPODだと最終的にmemmoveが呼ばれるのにmemmoveよりだいぶ遅い。
それと何故memomoveなのかよくわからない。
ここは趣味でプログラミングやってるギーク多そうだけど
まともなC++人材がいないせいで進歩がウン十年遅れてる業界がかなりあるから
どうかそういうことに飛び込んでいってくれないかな？
あ、給料はたぶんクソ安いけど日本への貢献と思って
>>159
その気持ち分かるよ
>>152みたいな隙あらばアベガーゴキブリにはいい加減ウンザリだよな 実際に馬鹿に馬鹿って言わないと安倍政権みたいな状態になるってのが今の政治に対する教訓だわな。。
ここも同じか。
>>164
誰に向かって言っているのかは知らないがお前自身に言い聞かせているんだろうな ---------- std__pair__construct_1 ----------
std::pair<std::uint32_t, std::uint32_t>[]
size(): 104,857,600
construct: 0ms
for (std::uint32_t i = 0; i < n; ++i) a1[i].second = i; 30ms
struct twice { std::uint32_t i1, i2; }[]
size: 104,857,600
construct: 0ms
for (std::uint32_t i = 0; i < n; ++i) a2[i].i2 = i; 0ms
一億個書き込んで0msなのは最適化で消えるんですかね？
今度は最適化で消えないように末尾をIOしたら、なぜかstd::pairのほうが速くなった。
std::pair<std::uint32_t, std::uint32_t>[]
size(): 10,485,760
construct: 0ms
for (std::uint32_t i = 0; i < n; ++i) a1[i].second = i; 20ms
1[n - 1].secondt10,485,759
struct twice { std::uint32_t i1, i2; }[]
size: 10,485,760
construct: 0ms
for (std::uint32_t i = 0; i < n; ++i) a2[i].i2 = i; 42ms
a2[n - 1].i2 10,485,759
最適化で変数が消されないようにするおまじないってないんですかね？
当然と言えば当然だけど消されないようにしたらスタックオーバフローするので、グローバル変数に追い出したら、構築時間を測る方法が無くなった。
nをsizeと書いておいた方が後でわかりやすいのかな。
大きなスタックをとる方法かms以下を測る方法みつけないと測れない。
おまえが頭悪いのは十分わかったから、もう書き込むな
ちなみにグローバル変数で一億個確保したら今度はClangがギブアップした。
1000万個ならClangでもいけた。
std::vectorは初期化子リストによる構築が出来るんだけど、そこでもオーバーフローしたような気がする。
でも、元ネタは別にスタックに入れなくてもどこかにあるはずなので、なぜそうなるのかよくわからなかった。
そもそもコードを書いた時点でされるであろう最適化を
まったく予想できていない
もうこの時点で脳味噌がコンパイラの知能より劣ってるのが確定
これすらわからんから延々と馬鹿な実験を続ける
バカな実験は勝手にやっててくれて構わないが、いちいちここに書き込むのはやめて欲しい。バカなことでも呟いていれば誰かが正しいことを教えてくれるだろうというスタイルなのだろうか？
>>185
ハイそういうスタイルです。
C++コミュニティは親切なので誰かが「ちげーだろバカ」と教えてくれます。 他に気付いたことは。
gotoはかなり使い道がある。
newは意外と速い。
std::vectorはコンテントによって最適化してくれるので基盤としてなかなか良い。
メモリー分断化は全く問題にもならなかった。
そんなに心配ならOSもJavaで書くしかない。
>>186-187
マイクロベンチマークは特性を見極めるのに使うべきで、
その特性が用途に適合するかどうかという視点で見ないと意味ない。
当たり前だがあらゆる意味で最強ってことはそうそうあることではなくて、
良い部分もあれば悪い部分もある。
普段はかなり良質な機能でも、その悪い部分を使うような用途だったら
使い物にならないかもしれない。
「間違い」っていうのは目的にマッチしないってことなんだよ。
目的・用途が示されないベンチマークがダラダラ流れててもそこに間違いもクソもない。
指摘を期待するなら指摘できるような形に整理して欲しい。
C++ スレだから言語仕様に反することは (目的にかかわらず) 間違いと言うかもしれんけど、
言語仕様で未定義のことでもやむをえずやることは C++ ではあることだしな。 まずbenchmarkをとる方法がわかってないから。
ベンチマーク取ること自体が目的なのはプロセッサベンダーとパソコンオタクだけ
まず要件があって、それを満たすことの判定のために設計するのがベンチマークだ
>>188
そもそも、Javaの方がメモリー効率が悪い。
現実的にはGarbage Collectionはメモリーの節約にはならない。 >>194
実装と実装の比較をする場合もあれば
試作と要求スペックの比較をする場合もあるね >>194
比較のために取ってるんだよ。
入力がランダムな場合と、整列されてる場合とか。
生ポインタとstd::vectorとか。
だいたいの傾向が見たい。 でお前は何を相談したいわけ？
中身のない活動報告しないくていいから
>>198
まあそういわれればそうかも。
スイマセンでした。 Twitter とか Qiita とかで書いといて
車輪どころか分裂勘違い君を再生産するのがC+++じゃねえか
だから悪かったって。
そんな怒らなくたっていいやん。
