thinkFirst
ThinkFirst
オーバーライドするときはoverrideつけたら？
>>5
サンクス。こんなことか・・・。
そういえばそういう習慣持ってないなぁ。余裕があったらやってみる。
コンパイル通ったので再開。
助かりましたありがとう。 >>1乙
前スレ>>1000の人は関数型プログラミング的プログラミングを自らに課している人なのであろう
つまり全てのオブジェクトは属性がコンストラクタで設定され、immutable、、、 getterは読み取り専用のメンバを作りたいときに必要
setterはpimpl化したときに必要
getterならread only修飾子を導入して
コンパイル時に書きこまれないことを保証すればいい
かんたんだろ
mutable なオブジェクトだとしても、setter を付けるメンバー変数は少ないな。
3つのうち1つぐらいの感じ。
セマンティクス上で重要なメンバ関数の区別は、オブジェクトの内部状態を変更するものか(非constメンバ関数)と、変更せずに内容を見るためのものか(constメンバ関数)の違いであって
その具体的な処理内容が特定のprivateデータメンバのgetterかsetterかなんて観点は大して重要じゃないし、そんなものに固執して設計を考えるのは馬鹿馬鹿しいし危険だと思う
>>13
「状態を変更」の方はまあいいけど「内容を見る」という表現は狭すぎないか。 そうね引数を加工するとか他のオブジェクトへのプロキシになるとか色々あるね
getterのイメージに引きずられすぎちゃった
コンテナのset, map, multi_mapはconst_iteratorじゃないと正しくforループを回せないって制限あった気がする。どうだっけ？
ペアのインデックサがわを弄ったら、ソートぶっこまれて順番が狂う感じの奴かい？
構造体のメンバ変数をまとめて以下のように文字列でアクセスできるようにしたいのですが、
構造体のポインタを以下のpointerに一括で割り当てる方法はないでしょうか？
Params {
int param1, param2;
} params;
std::map<std::string, void*> pointer;
// 同じ操作
params.param1 = 1;
*static_cast<int*>(pointer["param1"]) = 1;
Paramsは複数の型のメンバ変数を持ちますがpointerにtypeidを合わせて持たせることで使用時の問題は解決できます
以下のように一つずつ割り当てるのではなく、構造体に含まれるメンバの名前とポインタをイテレートして割り当てたいのです
pointer["param1"] = ¶ms.param1;
pointer["param2"] = ¶ms.param2;
中身が長ったらしい（と言っても200行程度）ラムダ式ってやめたほうがいいですか？
一般的には普通の関数にするんでしょうがヘッダーに書きたくないんです
ヘッダーに書きたくないって…、cpp内で関数を宣言/定義してもいいんだぞ
ラムダ式の存在意義は、コンパイラではなく人間にとっての可読性の改善にある。
どうも可読性が低いなぁと思ったら、ラムダ式をやめるべきだね。
>その関数に名前がつけれないならいいんじゃない
完全にダメなパターンだろ。。
カッコよくラムダで比較関数を書いたものの、あちこちで同じ比較関数が必要になって結局関数オブジェクトを作る不毛な作業
>>29 わざわざ関数オブジェクト作成するくらいならラムダをauto変数にいれるのはどうですか？ クロージャの利点っていうのは
クラスとメソッドに比べたらアクセスするデータのスコープがわかりやすく渡せるってことだが
c++だと同時にデータが処分されるタイミングを考えなきゃならなくて逆にむずい。
大抵の言語でループ変数をキャプチャするlambdaを配列に入れるとかするとはまるよね
c++の場合コピーキャプチャ使えばすむけど、キャプチャ方式指定できない言語だと結構面倒なことになる
>>26
そういえばそうでした…そうします
>>27
ですよね
初歩的な質問ですいませんでした プログラム板にキチガイ降臨中！botに一晩も反応する異常さ
一般人(学校恩師)に殺害予告をしているのでスレ建て通報してください。
http://2chb.net/r/tech/1559872586/
142 名前：a4 ◆700L1Efzuv 投稿日：2019/06/18(火) 05:29:55 ID://qVkzO
>>141
名古屋の人な 俺ね、君の問題を大橋先生と混ぜないことにする。つまりね、
片桐孝洋のことをボコろうと思う。普通に顎の骨を折る。これくらいで警察来るか？
一般市民とかさ、普通にさ、俺らの秘密なんだけどさ、日本人なんて復活ねーから。 BoostのSerializationはいつ標準ライブラリに入るの？
もしかしてあまり使われてないの？
現場で困った早引きできるいい本ってないですかねぇ。今度の現場が初のC++でして
>>43
GCCのバージョンアップでカスタマイズしやすくなった、とかじゃないの？ >>43
原文は "The pace of compiler development has increased with the recent updates to C++, ..." で、
C++03時代はバグ修正や最適化の向上がメインだったコンパイラ開発が、C++11以降は
大きな機能追加も伴う規格の改定に追いつくためにペースアップした、という感じかと。
改めて訳すとしたら「最近のC++のアップデートに伴ってコンパイラ開発のペースは増しており、〜」ぐらいかな。 >>39
ポケットリファレンス
ただ次の現場がレガシーC++ならあまり参考にならないだろうけど 実務で原文読んでたら、一生原文読むだけで終わりそう
大部分の軍人は銃や刀剣の作り方について深く知る必要はない。
バカな日本語訳や要約を読んで首ひねる暇があれば原文読んだほうが早い
>>53
結局のところ、たくさんの単語を覚えるしかない。数は力だよ。 昔に比べれば英文なんてそこら中にあるんだから読めばいい。
引き籠りが毎日ひたすら英語版のwikipediaを読んでいたらいつのまにかとんでもない英語力が
昔は民主主義はどうのこうのとか洗脳じみたreaderしかなかったよな？
C++のスレッドや並行処理でこれ読んどけっていう資料や本などありますか？
pthreadはもう使いたくない
えーっと、終わりが明確なものは、std::asyncでスレッド投げればいいと思うよ。
>>58
他の本はしらないが、「Effective Modern C++」には必要なことは書いてある、と思う。 std::asyncって生まれた瞬間にdeprecated送りになってなかったっけ？
11でのasyncの自動でjoinする仕様について
『致命的な問題でありasyncは実用にならない欠陥品。
破壊的変更になっても次の規格で修正すべき』
って声が(一部で)あったんよ(※表現は誇張しております)
std::async使ってみましたがstd::launch::async指定すると自動でjoinしますね
デストラクタで待ってるんですかね
std::launch::defferredを指定するとすぐ返ります
確かに微妙に使いにくいw
実装依存だから環境によってはスレッド作成すらしてないかも知れない
コンセプトですよコンセプト。来年に期待しましょう。
unifide call syntaxもその後入ることに期待です。
関数チェインしたいんです！
と、唐突に宣伝を始めるなど。
>>56
不思議なことに、読めるようになると、聞き取れるようにもなるんだよね。
どうしてだろね。
不思議不思議。 読み書きは下手くそでも時間かかってもなんとか通じるからいいけど音声はGoogle翻訳に頼れないのがつら
再帰を用いずに、
a0=0
an=( an-1×an-1 )+1
の1〜6を出せ
ってやつが全然できないので教えてください。
>>75
#include <stdio.h>
int f(int n)
{
int i, a = 0;
for (i = 1; i <= n; ++i) a = a * a + 1;
return a;
}
int main(void)
{
int i;
for (i = 1; i <= 6; ++i) printf("a_%d: %d\n", i, f(i));
return 0;
} >>75
> 再帰を用いずに、
その意図は？
単にスタック使いたくないだけなら最近のコンパイラにまかせりゃ末尾呼出最適化ぐらいはするから気にすんな 平均値も出せないMath.hはクソだと思う理由
１．エクセル関数で簡単にできちゃう
２．電卓でもできることがプログラムになると煩雑になる
３．平均値を出すのにコードを書き換える手間など
そのエクセルの関数の機能や電卓ツールはmath.hを使って作られている
C++コードをC++コンパイラでコンパイルするのと
CにトランスパイルしてCコンパイラでコンパイルするのと
どっちが性能良いんだろう？
トランスパイラの優秀さにもよりそうだが
CがC++よりハイパフォーマンスという前提がありそうだが、そんなことはない
>>86
いったんトランスパイルを挟むと、C++の元のコードをCで表現できる範囲内のコードに置き換えなきゃならないから、その時点で元のコードのままならなできた最適化のうちの一部はできなくなるだろうし、わざわざ効率の悪いコードに置き換えなきゃならないこともあるだろう。
トランスパイルの方が効率が上がる理由はないと思うよ。 現時点で利用可能な C++→C トランスパイラは何ですか？
>>89
c++のままでないとできない最適化って何がある？ >>91
LLVM は C++->C はできないのでは？LLVM のこと、わかってますか？ >>92
C++ の template は #define の親玉のようなものですから、qsort() とかの間接ポインタ渡しでなんとかするしかない C が不利な場合はあるとおもいますよ >>94
allocatorってまさにそのための仕組みなんだけど >>95
具体的にはあげられないけど、現在の文脈においてある前提が成り立つことが分かることによりできる最適化が、
(最適化を除いて)同じ動作となる別のコードに置き換えられることにより、元の文脈での前提条件が成り立つことを断定できなくなり適用できないという状況があるのではないかと思う。 >>96
そちらこそllvmをまるで理解していないみたいですね >>100
具体的なのが聞きたい
gccもllvmも中間言語でやる最適化が中心でしょ
そういうc++の特別なフェーズがあるなら興味ある
けど知らずに言ってるなら聞いても無駄だね >>101
llvm が変換した IR を C コードに戻すことができるのですか？ (1) コンストラクタの呼び出し回数削減最適化
(2) クラスが絡むmemory ariasing
(1)はC++かその意味を保った中間言語上で行う必要があり、C言語に逐語訳してからでは手遅れ
(2)も同じくで、クラスの意味を失うような低レベルへの変換を一揆にかけると
クラスFooのthisポインタとかクラス固有のアドレスが他のクラスにもグローバルな関数にも渡っていないことの保証がC言語に逐語訳してからでは手遅れ
な印象
想像なので詳しくは知らん
初歩的な質問で申し訳ないんですけどcinってどういうもんなんでしょうか
cpprefjp見ると標準入力に対する入力ストリームオブジェクトなんて書いてありますけど
iostream.hで定義されてる「なにか」だとは思うんですがどういう型のものなのかとかそういえば全然知らずに使ってたなって
よろしくおねがいします
const inputかと思って親近感がわいていたのに…
C++でクロスプラットフォームなコードを書くのはどれくらい難しい？
Nimはクロスプラットフォームを主張してるんだけどどっちがいいんだろう？
WindowsもLinuxもMacもカーネルがCで書かれてるらしいけど何でC++じゃないんだろう？
C++がそこまで整備されていなかったから
OSといえばC言語で書くのが当たり前だから
そもそもC言語で十分だから
Linus「C++はレベルの低い奴が使うものだから」
>WindowsもLinuxもMacもカーネルがCで書かれてるらしいけど何でC++じゃないんだろう？
何回質問されたことだろうか。
OSじゃなくて組み込みでも大部分Cでしょ？
なんで？
超堅牢に作らないといけないから、
見えないところでコピコン大量に走ったりするような言語は避けられるんじゃないか
ヘッダーに実装書き散らしてるのよくないね
OSはバイナリ境界意識しないといけないし
まあどのみち標準ライブラリは使えないけど
>>115
各ベンダーがサポートするにはC言語がちょうどいい規模だから >>112
C++ のデフォでのマングリングが外部結合（リンク）を阻害するから、に一票 ちがう
ちがうなぁ
ポインタがあって適度に奥が深いから、だ
メモリの制御が難しいからじゃね
最近やっと標準でまともなメモリ管理の仕組みを作り込めるができるようになったくらいだし
今のC++なら十分使えるよね
継承やSTL、shared_ptrみたいなことをCで実装してるわけで
それを考えたらC++で良い
プログラムの一部にでもRTTIを使用した部分があるとプログラム全体のパフォーマンスが低下する？
まあc++でちゃんとしたもの組もうと思ったらデストラクタをしっかり用意するってのが
大事なわけだが、かなりいろんな状況に対応したものにしないとまともに使い物にならん。
これはメタプロバカが思ってるほど難易度は低くない。
>>127
コンパイラオプションでRTTIを無効化するとデータ量が減るのでパフォーマンスが上がる
→つまり一部でも使ってると低下する
まぁ今時は気にする必要無いと思うけど
速度は実測が基本 ちゃんと例外を投げないデストラクタを書くんだぞ
fcloseの失敗はもみ消せ
どうせ回復などできない
>>129
やはりそうですか、ありがとうございます
速度は今試せないのでまたこんどやってみます >>107
えーっとcinってのはistream型のオブジェクトってことでいいんですかね
externをいまいちよく分かってないですがヘッダ内で定義されてるから他のファイルでも使えるとという認識で大丈夫ですかね 1.思考停止してそのまま使う
2.外界から齎される無限長の情報列がストリームである、と理解する
好きな方を選べ
何でC++使ってる職場少ないのにプログラム板で上位なの？
C++プライマーとaccelerated C++一通りやってeffective C++始めたんだけどすんごくめんどくさーい
acceleratedの後半あたりから思ってたんだけど純粋なロジックやテクニック以外のところで考えなきゃいけないこと無限にあってできるようになる気がしない
実際に開発になってクラスやインターフェイスの設計ってみんなこんな色々考えてやってんの？って
競プロっぽい問題だったりちょっとしたもの作るのは割と面白いけどなんかもう萎えてきた
世の中のプロってやっぱ(modern) effective C++とかmodern C++ designとかその辺りは基礎教養レベルまでもっていってるもんなの？
2年目のペーペーだけどとてもC++のプロになれる気がせんわ
そのへんはさらっと何が書いてあるか見ておいて、実際書くときに関係ある部分を参照する本では？
>>141
それは思うわ
結局その辺の不満を改善したのがJava以降のオブジェクト指向言語だから
今C++を勉強すると面倒すぎると感じるはず 11 名前：（´・ω・｀）（｀ハ´ ）さん[] 投稿日：2019/06/24(月) 17:55:34.54 ID:PqEssjoP
世界三大英雄は野茂と村田と、あと１人は誰?
142 名前：（´・ω・｀）（｀ハ´ ）さん[sage] 投稿日：2019/06/24(月) 21:21:51.77 ID:osRVwCku
>>11
中野英雄 >>132
回復できないエラーでもユーザーに通知する余地はあるでしょう。最悪abort()でも、もみ消すよりはマシ。 >>141
modern C++ designはメタプログラミングに片足突っ込んでるからだいぶ後回しでいいと思う
考えること無限にある、は同意だけど優先順位低いものは忘れた方がいいんじゃないかね(特に、ループ回しもしない箇所の速度効率とか 使用する概念としてはJavaとCを足してさらに多重継承とか演算子オーバーロードとかを足した
のがC++という印象だった。
プログラミング言語 収入 ランキング
とかでぐぐると
難しい上に重要なはずのC++が年収ランキングで10位以内に無いんだが
>>140
多いってのはどこで集計されて発表されてるの？ 一発当てて稼げてるのがwebサービスやってる人たちだから
C/C++まともに書ける人は貴重になってきてるのに何故か低いよねえ
特定の会社に行くしかない気がする
>>151
経済の世界でよくあること：
・高度な能力を持つ人は給与ではない部分にやりがいを感じるので給与に
関係なく集まってしまう。アニメーターは絵がものすごくうまいのに、
マクドナルド店員よりも自給が低い。「やりがい搾取」。
・高度な分野は、人材も高度な人が集まってくるので需要よりも大き過ぎる過剰な
成果を出してしまうので給与が下がるらしい。プログラマや数学者、
コンピュータ業界なんかは大体、そんな感じのところがある。 高度な分野においては、とても僅かな一握りの人が、過大な成果を出してしまう。
すると、大体の場合、給与が下がるらしい。世界のわずか数人が異常なほど大きな成果を
出しているとか。
みんな勘違いしてるが儲かる商売してるかどうかだけが稼ぎに関係している
儲からない商売に超絶技巧を投入しても意味ない
サービスで一発当てる方が100倍稼げる
というか自分のビジネス思いつくタイプでもないプログラマーが稼ごうと思ったらなるべくニッチな言語を探していくべきなんだと思う
C/C++なんてメジャーどころは一番だめなんじゃないか。まだまだ人が少ないか、書ける人がどんどん減っていきそうなところを
>>159
違うぞ稼げる商売やってる人に乗っかるのが正解
現在儲かってしょうがない会社に入るか今後そうなる会社に入っておくしかない
専門分野は関係ないが一発当てようがない業界というのはあるからそういうところは目指さない方がいい 言語は表現手段にすぎないので、言語で分野が決まってしまう現状には疑問を持ちます
少なくともライブラリーは統一されるべきだと昔から夢想してきています
ライブラリはCインターフェースさえあれば全てのまともな言語から呼べるから問題ない
>>163
OLE は重過ぎるんじゃないでしょうか？単に名前と仕様が「ある程度」統一できればいいかと考えています
でも OLE はもう一度調べなおしてみます、キーワード提供ありがとうございます 素朴な疑問なんだけど
オブジェクトをshared_ptrで管理するとき
そのオブジェクトから他のオブジェクトにポインタを渡したいときってどうするの？
コンストラクタ以外のメソッドからならenable_shared_from_thisで
生なthisポインタからshared_ptrを生成して渡せばよいけど
コンストラクタだとそれも無理だよね(shared_ptrが作られるのはnewの後だから)
どうするの？
ポインタ指向プログラミングとオブジェクト指向プログラミングは根本的に相性が悪い
これがC++高難易度化の一要因
てかさ
自分自身のスマポを
外部から渡してもらわないと、自分では知れないってのは
設計ミスなんじゃね？
当たり前、JavaやC#だとそんな制約ないからなぁ
代入がメンバのコピーという仕様が全ての複雑さの元凶
互換性のために仕方なかったとはいえ
おかげで完全に動くクラスをつくるのが凄まじくしんどい
それを改善しようとしたJavaは全てポインタのコピーというふうに割り切ったが
Optinalを導入しなかったせいかヌルポの山を築いた
それを改善しようと
Rustは全てがムーブという世界を作ったがまだ受け入れられるには早かった
>>171
これまた不思議なもんで
Cからして配列は参照渡しなのに構造体は値渡しだからねぇ
Cの構造体が配列みたいにアクセスするとポインタに成り下がる仕様だったのなら
C++もまた違ってただろうねぇ
どちらがいいかは分からないが えっ
普通は呼吸をするように
const T& var
て書く様に訓練されてるだろ？
任意にコピーとポインタとムーブを使い分けることになんの苦労も無いと思うけど
>>172
私は逆を考えていました、すなわち、配列ですら値渡しであるべきかと
参照渡しにしたいのなら、そのすべてに * をつけて明示するべき そうではなくて
構造体において何も考えずに代入した場合
実体のコピーになるって話では
その点、配列では実体のコピーにならないので
JavaやC#のオブジェクトに近い仕様で
なかなか先鋭的
そんなことより
コンストラクタで自分自身のshared_ptrが欲しい時
どうするの？
欲しい理由としては、どっかシステム的なところにattachしたり
自分のコンポジションした子供たち？に渡したり
そういうことをコンストラクタですっかりしたい場合どうすんの
enable_shared_from_thisを継承して二段階初期化ってのもかっこ悪いし
（↑生成する側がshared_ptrを使ってくれなかった場合
クラッシュするってのは置いておいてさ）
そもそも実行時型情報なんて反則が許されるなら
仮想関数付きのオブジェクトは実行時型情報のどこかに参照カウンタを隠し持っている
って仕様でもよかっただろ？
スマポ側が参照カウンタを持っているってのは一見賢そうだけど…
上手くいかないパターンもあるよね
>仮想関数付きのオブジェクトは実行時型情報のどこかに参照カウンタを隠し持っている
↑これはちょっと不正確だな
vtableと一緒に参照カウンタ〜
が正解かな
>>177
create関数でshare作ってから後の構築処理して返すしかないんじゃね 有害でしかない美意識は投げ捨ててshared_form_this使えって話になるだろ
それでもコンストラクタでは使えないから二段階初期化になるな
ちょっと質問なんですが、どういうときに必要になるんですか？
Intel、新プログラミング言語「Data Parallel C++」を開発中
2019/06/25 11:08 後藤大地
https://news.mynavi.jp/article/20190625-848112/
ossbytesは2019年6月24日(米国時間)、「Intel Is Working On A New 'Data Parallel C++’
Programming Language」において、Intelが「Data Parallel C++」と呼ばれるプログラ
ミング言語の開発を進めていると伝えた。
Data Parallel C++に関しては、先日Intelが発表した「Intel’s ‘One API’ Project
Delivers Unified Programming Model Across Diverse Architectures」程度しか情報が
なく、具体的にどのようなプログラミング言語なのか、わからない状況にある。
記事では、これまでに公開されている情報から、Data Parallel C++の特徴として以下を
まとめている。
・Data Parallel C++ (DPC++)はIntelが以前から取り組んでいるOneAPIプロジェクトの
成果物の1つ
・OneAPIプロジェクトはさまざまなコンピューティングアーキテクチャにおいて統合された
プログラミングモデルを提供するための取り組み
・Data Parallel C++はC++をベースに開発されている
・Data Parallel C++はKhronos GroupのSYCLシングルソースC++プログラミングスタン
ダードがベースになっている
・CPU、GPU、FPGAといった異なるアーキテクチャに対して使用できる
・Data Parallel C++の詳細は2019年第4四半期の発表される見通し
GPUの活用はスーパーコンピュータにおいても重要度が増している。Intelは異なるアーキ
テクチャに対して利用できるプログラミングモデルを構築することで、さまざまなコン
ピューティングアーキテクチャに対して同じコードベースで開発を進められる仕組みを
実現することを目指していると見られる。 >>177
相互参照自体がクソ汚い設計なんだからツールがいくら綺麗になってもダメ。
諦めてthis渡せや。 異なるアーキテクチャに対応
高額
インテルサポートあり
OpenCLがずっと停滞気味なのに業を煮やしたんじゃね
Intelは、CPU内臓のGPUを自前で作ってるから、そのための開発環境は
重要で、実行時のパイプライン関連のさまざまな高速化においても、
共通の技術が使えるので開発するメリットは大きいのだろうと思う。
レジスタ割付、ループ関連の最適化などは、CPUを実行する段階でも
似たことが行われる。
そんなくだらんライブラリ作ってる暇あったらCUDA互換のランタイムだせーい
accelerated C++みたいな実際にプログラム組んでいきながら組むときはこういうところを気をつけないといけないみたいなこと解説してる本って他に無い？
細切れの文法はC++プライマーやプログラミング言語C++第4版あるし、テクニック集みたいなのはeffectiveC++でいいだろとは思うんだけど
プログラミング構築を実際にどう進めていくのがいいのかってところが全然分からない
>>194
同じ著者の再考C++とか？
ただクソ古い時代のC++
あとストラウストラップのC++によるプログラミングの原則と実践
これはモダンだが鈍器なので読むのは覚悟がいる C++に限らず、プログラムに関連した技術書について議論するスレってある？
他板でも良いが、書き込みが活発な場所が良い
金を持て余してて、「定番中の定番」という技術書をかき集めたいんだ
ランキングなどあったらなお良い
昔は推奨本スレとか無かったっけ
過去ログを漁ってみるとか
>>199
質問に対する回答にま〜〜〜〜ったくなってない
お前死ぬほどアタマ悪いだろ 金持て余してて収集欲のために名著集めたいみたいな話なのに身につく身につかないとか言ってるのは確かにおかしいよ
全然関係ないけどこのスレワッチョイの表示がワッチョイだけなんだな
初めてみた
>>204
それこそC++に限らないなら他のスレで聞けばよくね？ 各C++コンパイラのシェアってどのくらいなんだろう
Builderとかまだ使ってる人いるのかな
推定だと、Delphiを含めれば、VC++の10分の一位は、Embarcadero製の
開発環境を使っているらしい。C++とPascalの内訳は分からない。
C++で、マルチプラットフォームで、コンパイラとライブラリを同じ組織が
作っているものは多分、他にない。Qtはライブラリと簡易IDE程度だし。
やはり同じ組織が全てを管理しているのは信頼性において優位。
なお、MSだと、Windowsシェアを根本的に減らす開発環境は存在し得ない。
MSの開発環境で、果たしてMSを脅かすような製品を作れるだろうか。
一見便利に見えても、MS社内にはさらに便利なツールやライブラリがあるのでは。
だから、生産性は常にMSには適わないことになる。MS以外の開発環境を
使えば、あるいはMS社内の生産性を超えることが出来るかもしれない。運がよければ。
コマンドライン引数にファイル名を取って、そこに記述されている数値列を vector に格納して、その後その vector に何かするプログラムを作りたいとします。
そのファイルに入ってる数値列が int でも float でも良いとき、 main 関数ってどう書いたら良いのでしょうか。
ただし、数値列の中の全ての数値が同じ型であることは保証します。
int main(int argc, char* argv[]){
vector<ここに何を入れたら良いか分からないです> v;
ifstream fin(argv[1]);
auto tmp;
while(fin >> tmp) v.push_back(tmp);
fin.close();
〜 v にしたい処理を書く〜
}
doubleか何かにしとけば
あるいはvariant
>>214
vector<auto> って意味ですか？
>>215さんの案とどっちが良いんでしょうか。
思想による？ >>216
auto tmp;なんてありえねーってことだろ
型推論でけへんやん >>217
じゃあそこもどう書くべきか分からないです 根本的にはオートマトンで判定する
IP型 192.56.125.0
小数型 1025.62
整数型 100731
分数型 57/1269
+-の記号も含めて状態遷移図を考えてif文のすごい連なりを作る
単純でしょ
9.7/2.01
ピリオドと/を含むこの文字列を分数と見做して小数にしてしまうかどうかも勝手に決めて言い
2.54/-0.07
これは非常に怪しいけど、負の小数に直してもいい、と決めていい
.565
これはどこからどう見ても小数の0.565に見えるから小数である、としてもいい
00.3
ゼロが重なってるけどだいたい小数だろ、ということにしてもいい
>>219
トライ木みたいなものを作るべきということですか？
それとも、トライ木など言わずにもっとシンプルに実装できるのでしょうか 読み込みの時点で処理をするときの型に変換するだけでは？
>>222
>>213のコードで言うと、fin >> tmp の部分が「読み込みの時点」ですよね？
どう変えたら良いですか。
ちなみに、
〜 v にしたい処理を書く〜
というところには int なら int、float なら float 向けの工程が書かれるというつもりです とりあえずvector<string>に収集してから中身がintかdoubleかcomplexかゆっくり解析すればええやん
>>224
皆そんなダサいやり方でやっているのですか？ 字句解析の方法を勉強しないといけないよ。簡単に言えば文字列を一文字一文字解釈する訳。
std::atoiとか、std::strtolなどの関数を使えば字句解析は省略できるけど。
てか面倒だから全部doubleで読むんじゃダメなの？
ハァ〜〜〜ダセェ奴しかいねぇなここは
分かった。自分で勉強するわ
ありがとう
>>233
自分が思うカッコイイやり方があるかと期待してたら、誰も期待に応えてくれなかったということだろう。
周囲の人間が｢お前のカッコイイは世間からずれてるぞ(むしろバカっぽいぞ)｣と教えてやっても、本人は納得しないのだろう。 C++をPythonかなんかと勘違いしてるんだろう
>>196
ストラウストラップのは初心者用って聞いてたからスルーしてた。両方ちょっとチェックしてみるわ感謝 typescriptだとint|floatみたいな型指定ができるんだっけ
質問です。weak_ptr<T>とintの双方向マップがやりたかったので
boost::bimap<weak_ptr<T>,int> bm;
とやったらweak_ptrはハッシュにできないのでエラーになりました。よく考えると当たり前ですね。
仕方ないのでとりあえずunordered_mapと組み合わせて
boost::bimap<T*,int> bm;
unordered_map<T*, weak_ptr<T>> um;
この２つをセットで用いてるんですが、なんか不格好というか・・・
もしかして変なことしてますかね自分？
字句解析しても書かれた数が整数型として扱うべきなのか浮動小数点型として扱うべきなのか
書いてあるのが数だけなら、書いた奴の意図まで常にわかるとは限らん
価域だけが問題ならとりあえずdoubleかlong doubleの数値xとして読んでから
std::numeric_limits<T>::lowest()〜std::numeric_limits<T>::max()にxが収まるような最少の型Tを決定せよ、
みたいな
>>239
Tclが演算するときに整数か浮動小数点か勝手に決めるんだよね。
ファイルからデータ読んできて処理させたら所々不自然な値になると思ったら
整数演算になってたりさ。
型変換関数噛ませばいいだけだけどね。 むしろ、整数と浮動小数点の両方のパターンで値を持っておいて、後で必要なときにどっちかを使えばいいだけなのでは？
C++でアライメントを指定してクラスをnewしたい
void* operator new[](std::size_t, std::align_val_t)
なる関数が存在するからこれを使う
しかしnew側では一般的にクラスをどのアライメントでnewすればよいのかは知らない
というよりアライメントを指定すべきかどうかも知らない
こういった場合、例えば普通のnewをprivateにしておいて、
その近くにコメントで１６でアライメントを使うこととか書くくらいしかできませんかね？
あるいはstatic klass* Generator()みたいな関数を用意すればよいのか
>>244
値を保持するだけならdouble（使えるならlong double）の一種類で十分 >>245
『プログラミング言語C』のmalloc()の実装例を嫁
ていうかそれすら読んでいないのｶﾖ、というﾚｳﾞｪﾙ >>245
alignasが目的に合うように見えるが使ったことがないから適切かどうか分からん >>245
アライメント指定してるのに、
newがアライメントわからないって意味不明
アライメント指定どこいったんだよ アライメント指定してnewしてほしいクラスがある時
newする側にそれをどうやって伝えるべきか？という問題です
__attribute__ ((aligned(x)))
アライメント指定してnewしてほしいクラスTのoperator new()を
オーバーロードしてaligned_malloc()でも呼ぶようにすれば良い
class C {
public:
__m512i aa;
void* operator new(std::size_t n) {
std::cout << "new" << std::endl;
return ::operator new(n, std::align_val_t(64));
}
};
こういうことではなく？
>>246
でもそれだと、intとdoubleで別々の処理を書かないといけなくなる。
vector<int>とvector<double>を両方作ってtemplate関数で呼び分ければ処理の記述自体は1つにできるでしょ。 >>246
整数値のビット数が長いとdoubleじゃダメ >>255
12 bitぐらいまけてくれYO、
ていうか10バイトのdoubleを使ったらおk >>254
どっちかというとunionベースのクラスの出番かとｵﾓﾃﾀ
要素型の方でキャスト演算子を定義するなどして整数型解釈と浮動小数点型解釈に両方対応したら、
コンテナを2種類用意する必要はなくなる
ｷﾓｽ アライメント指定はとっくに言語に組み込まれてるんだけど…
newを呼び出す側がアライメントサイズを過少に設定しても、
コンパイラはnewしようとする構造体に含まれる全メンバのアライメント要請を把握しているはずなので
>>247式に構造体定義を対策しておけば問題無い配置でポインタを返してくれる気もする（そうすべきなのが道理
が（さもないとARMとかで例外で落ちるコードを簡単に量産できてしまう
newの細かい仕様は知らんのでわからん どっちかというとmallocしたメモリよりスタックで確保した場合に問題なることがある
環境やコンパイルオプションにもよるけど
atoiとかで解析する前後でオーバーフローを検出する方法ってあるの？
>>268
ない
0返すだけ
std::stoi
とか使った方がいい vtableの仕様を標準規格化してれば、もっと便利になっていたのにな。
clangやLLVMって、coff 形式の object file は作れないのかな？
>>271
いろいろやれるからな
テンプレートみたいな難しい仕組みも標準規格としてきちんと仕様化できる連中が
言語仕様の策定を仕切っているというのが大きい >>274
委員会が入ってきてからは汚くなってる気がする。
むしろ、ずっと昔に入った仕様が使いやすい。 C++はSTLの既存クラスに、新たなメンバ関数を追加できますか? 継承の新クラス作るのはではなく。
javascriptとかは追加できたとおもいます。
>>277
テンプレートの代替物がプリプロセッサのマクロになってしまうというのが最悪すぐる、
しかしまあそれ以外は同意
ただしスタックに構造体を詰めないK&Rの頃の奴のは除外それは論外 昔C++にお世話になってたんだけどその頃はゲームでよく使われる言語だったんだよね
今でもゲーム開発によく使われてるの？
>>282
使われていると思う。アメリカのQuoraによれば、本格的な3Dゲームでは、
C#が使われたことは無く、全てC/C++製らしい。 ゲームエンジン自体はC++だけど、購入したエンジンを使って作る場合にはエンジンによって使う言語は変わる
>>283
>>284
3Dゲームとゲームエンジンで使われてるのね
やはり速度とモダンな機能ではまだC++の代替になる言語は無い感じだよね
そういう意味ではRustが最近がんばってるみたいだが >>285
Rustは、mozillaが開発したから有名なだけ。
実際には広く使われることは無いらしい。
既存の言語から逸脱しすぎた言語は、よっぽど便利でない限りは普及しないらしいよ。 新言語上げでよくやられてるC++叩きって、書いてる方の知識が98/03で止まってて
「そんなん最近のC++でも出来るし…」ってなる事が多い印象が強い
もちろん新言語の本当に優れてるところもあるんだろうけど、比較するなら比較元もちゃんと勉強しろと言いたい
あと「C++はこんなに危険！」ってどうしようもないクソコードを藁人形に出してきたりな
お前らの新言語の新機能も間違った理解でクソみたいな使い方したら危険だっての
メタではみんなLISPを作りたがるんだけど、表現方法の違いで文法が狂う。
そうはいってもRustは良さげなので
コンパイルがVisual C++クラスに瞬時に終わって
Visual Studioクラスの光速で反応するインテリセンスができたらぜひやりたい
変数がデフォルトでimmutableなのがたいへん痺れる、
確かに今のC++の用途で置き換えられる可能性がありそうなのはRust位だな
Rustは情緒的に言って錆びだからな。蓄積使うんですーって感じの命名なのだろう。
RustってC++11以降の機能を勉強して
難しすぎると感じた人がやったらすんなり入れるんだよね
でも普通の言語から移った人は何じゃこれってなる
C++11以降に挫折した人のための言語
RustでC++ → Rustトランスレータを書いたら勉強になると思うわ
>>294
間にLLVM挟むと公共の福祉になりえます。 >>295
ソースコードのコメントやインデントが保持されないのでは…
あと自分自身が使っていない範囲も含めたC++の全機能のトランスレートに対応しようとしたら日が暮れてしまう >>270
遅レスだけどthx。
面倒そうだけど何とかなりそうね >>296
貴様、パイソニアンだな。
ずしゃんずしゃん。 みんなC++がここまで残ることになるとは予想してた？
このままだとC++30とか40とか普通に来そう
OSを除けば基礎的なソフトはだいたいC++でしょ
ふつーに重要言語の1つ
C++11以降標準のフットワークが軽くなってありがたい
その代わり要るんかこれ？みたいのもガンガン入ってくるけど
>OSを除けば基礎的なソフトはだいたいC++でしょ
docker, kubeはgolangだが？
golangが増えてきたね
Cを置き換える感じになりそう
言語仕様もCとPython混ぜたような言語だし
c++が使われるとこってのはゲーム、ブラウザ、windows, MSoffice
とか、GUIでかつ計算資源どっかり使うようなプログラムだわ。
確かにVC++はMFCが使えるからGUI向きだな！
clang, llvm, jdk, .net core, chrome,ほとんどのゲームエンジン
この辺C++
他の主要ブラウザも大体C++のはず
dockerはgoで書かれたせいで性能が悪いって言ってる記事を読んだ事がある
要するにC++は「ソースコードが大規模かつ性能がシビアに要求される」場面で使われる。
開発効率はJavaより悪い事が実証されてたはず。
なんかの研究論文もあったし多くの開発者の経験談もある。
だから開発効率を多少悪化させてでも性能を求める場合に使われる。
使える人揃えるの大変なんだよ
Rustの導入談とか見ると、
性能に問題があって他言語導入を検討したがC++は使える人がいないのでRustにしましたとか書いてあるし
そもそもポインタが理解できる人が、アメリカの大学の理系の学生でもほとんどいないという話がある。
だから、C++が悪い言語というより、C++がある種の数学みたいに難しすぎて理解できない人が多いので
Javaなんかが必要になったらしい。
Rustはポインタ理解でない人が使える言語ではない気がする
ポインタが理解できるとかそういう問題じゃねーわ。
むしろ「〜の概念が理解できる」てだけでドヤって
まともなプログラム書けると思い込むバカが問題なんだわ。
ポインタすら理解できない人にプログラミングは難しすぎないか？
>>313はただのデマだろう
ポインタが理解できないなんてことはありえない C++がある種の数学ってなんだよ
この板最近一人おかしな作り話書き込み続けてるやつがいるよ
包丁使えない人に料理は難しすぎないか？みたいな話だな。
包丁使えなくてもハサミ使えば料理できるでしょ。
リファクタリング中毒言語
勉強すればするほど書き直したくなる
どんな書き方しても新しい規格は出てくるわけで、
そこで古い書き方だからとかいちいち引っかかる奴はc++は向いてない。
RustスレなのにC++の話で申し訳ないが、この前
template<class T, class U> void tr_pos(const T& src, U& dst) { ... } // メンバ関数T::get()、U::set()がある前提
というテンプレートを1個書いて、メンバ関数get()やset()を有する無数のクラスA、B、C、...について
任意の組み合わせでの相互変換（および同一型のコピー）を可能ならしめたんじゃわ
C++は数学や！とそのときｵﾓﾀわ
次の日、今度はメンバ関数get()やset()を持たないクラスFooとBarについて
template<class U> void tr_pos(const Foo& src, U& dst) { ... } // メンバ関数U::set()がある前提
template<class T> void tr_pos(const T& src, Foo& dst) { ... } // メンバ関数T::get()がある前提
template<class U> void tr_pos(const Bar& src, U& dst) { ... } // メンバ関数U::set()がある前提
template<class T> void tr_pos(const T& src, Bar& dst) { ... } // メンバ関数T::get()がある前提
というテンプレートを追加して、{ A, B, C, ... }とFoo、および{ A, B, C, ... }とBar、
および（前日実現済みの）{ A, B, C, ... }内の任意のクラス間のの相互変換を
tr_pos(src, dst)と書いただけで可能ならしめるという壮大な体系を実現したんじゃわ
C++は数学や！という思いをそのときさらに強くしたわ
さらに次の日、Foo型オブジェクトsrcとBar型オブジェクトdstについてtr_pos(src, dst)と
書いたらビルドエラーになったわ；
仕方ないので関数のオーバーロードを使って
void tr_pos(const Foo& src, Bar& dst) { tr_pos(src, A); tr_pos(A, dst); }
void tr_pos(const Bar& src, Foo& dst) { tr_pos(src, A); tr_pos(A, dst); }
のようにして解決したんじゃわ
C++はちょっとしたテクニックを要する数学や！とそのときｵﾓﾀわ
さらに次の日、Foo型同士、およびBar型同士でコピーしたくなったので、
一昨日書いたテンプレートを特殊化したら行けるやろ、と思って
template<> void tr_pos<Foo>(const Foo& src, const Foo& dst) { ... }
template<> void tr_pos<Bar>(const Bar& src, const Bar& dst) { ... }
と書いたらコンパイラが一昨日書いたテンプレートではなくて昨日書いた
オーバーロード関数を特殊化しようとしてビルドエラーになるわrz
C++はいろいろ破綻している罠だらけの言語やとそのとき確信したわ；
C++の話は悪くないかもしれないが、関数テンプレートの部分特殊化ができないというC++の仕様は悪い
※ 個人の感想です
>>324
念のため確認なんだけど
template<> void tr_pos<Foo,Foo>(const Foo& src, const Foo& dst) { ... }
template<> void tr_pos<Bar,Bar>(const Bar& src, const Bar& dst) { ... }
じゃなくて？ 皮肉もわからんか
オーバーロードの解決順を制御するTipsがあった気が
この辺はマジで分かりにくいわ
コンパイルオプションで名前解決の過程が可視化できるとありがたいんだけど
さらに言えば<Foo,Foo>と<Bar,Bar>の所消しても動かん？
template<>void tr_pos(const Foo...
>>331
それはさすがに駄目で、VC++で次のエラーになる
error C2912: 明示的な特殊化; 'void tr_pos(const Foo&,Foo &)' は関数テンプレートの特殊化ではありません。
原因は1日目に追加したtr_pos<T, U>(const T&, U&)、および2日目に追加したtr_pos<U>(const Foo&, U&)、tr_pos<T>(const T&, Foo&)の
3種類のうちのどれを特殊化すべきなのかわからないかららしい まとめ: >>323-324の状況において、特殊化は次のように手段を使い分けねばならない
(1) 3日目のtr_pos(Foo, Bar)の追加は、関数テンプレートの特殊化ではエラーになるので関数のオーバーロードで特殊化する必要がある。
（理由）
tr_pos(Foo, Bar)は以下の関数テンプレート全てに当てはまってしまい、コンパイラが特殊化対象を特定できない。
tr_pos<T, U>(T, U), tr_pos<U>(Foo, U), tr_pos(U, Bar)
(2) 4日目のtr_pos(Foo, Foo)の追加は、関数テンプレートを>>327のように型パラメータ<T, U>を全て指定して明示的特殊化するなら逝ける
（理由）
関数引数にBarが現れないことから、tr_pos<U>(U, Bar)は特殊化対象から外れる。
型パラメータ<T, U>を両方明示することにより、tr_pos<U>(Foo, U)も特殊化対象から外れる。
==> 残るtr_pos<T, U>(T, U)が特殊化対象の関数テンプレートであるとコンパイラが判断できる。
(3) 一方、4日目のやつを暗黙的特殊化で行おうとするとビルドエラーで失敗する。
（>>332でも述べたが、上記(1)と同じことになる。
T::get()やU::set()を持たないクラスであるFooやBarを無理やりtr_pos()というシグネチャで他と統一的に扱おうとした結果ｽｹﾞｰ薄氷を踏むようなプログラミングになっていた、
ことがわかった、、 >>333ﾌﾟﾁ訂正orz
誤： tr_pos(U, Bar)
正： tr_pos<T>(T, Bar)
>>334
手元の環境はC++14なので使えないっぽい
および、>>323-324のガンはtr_pos<U>(Foo, U), tr_pos<T>(T, Bar)の2つのテンプレートの名前が
tr_pos<T, U>(T, U)と同じであることにあるのは確定的に明らかなので、これを治療するのが筋
constexpr ifに逃げるのはいささか筋が悪いかと、
※ tr_pos<U>(Foo, U), tr_pos<T>(T, Bar) を、それぞれtr_pos以外の固有の名前に改名し
（例えばtr_pos_from_Foo,とtr_pos_to_Bar）、
tr_pos<T, U>(T, U)にてそれらを使って共通の名前tr_posで実体化するテンプレートを書くならば、
テンプレート機能の中だけで目的（tr_pos(T, U)式のシグネチャへの統一）を果たせてシンプル＆スマートに解決する。 >>317
アメリカのコンピュータ科学系の学生の7割がポインタが理解できないらしい。 Ruby の女神・池澤あやかが言ってる
大学で、C言語を教えるから、ほとんどの人がプログラムを嫌いになる！
だから、Rubyから始めるべきだって！
YouTube に動画を上げてるKENTA も、初心者はRubyから始めるべきだって言ってる！
多言語やってる専門家は、皆、Rubyからって言う
動いているプログラムそのものを記述できるC言語を理解できないとコンピュータサイエンスを修めたとは言えないでしょ
俺もCから始めるべきだって思ってた
ま、俺自身はHSPやった後にCやったんだけど
最初スクリプト言語みたいなライトウェイトなやつやるべきだってのは正しいのかもね
実は、プログラミングに興味がある人は多くても、適性が余り無い人の方が多い。
だから、誰でも出来る言語の人気が高まる。それがスクリプト言語であり、
VBやC#だろう。多数決の投票では平易な言語が上位に来る。
個人的にはC++は難しいのではなく面倒くさい言語だと思っている
ポインタが理解できないなら参照も理解できないと思うんだけどな
日本にはc言語ポインターだけを解説した本が有るじゃないか
自分はあれを読んで初めて
ポインターの何を理解出来ていないのかが解った
c言語は人間の認識的に誤りやすい書き方になっているのが問題
そういうのをシマンテッスク問題とか言うらしい
アセンブリ言語を先に勉強すべきだんだよな
それだとメモリとそのアドレスを当たり前のように使うし
それこそがコンピュータなのだとわかる
そのあとで変数や参照はどう受け渡しされるのかを理解すればスムーズ
問題はアセンブリを始めるには手頃なアセンブラが無いというところか？
手頃さで言ったらGASぐらいだと思うんだが
>>343
ところが、
1. TYPE[10][10] aaa; は理解しやすくても、
2. TYPE aaa[10][10];
3. TYPE *aaa[10][10];
4. TYPE (*aaa)[10][10];
3, 4 となると意味不明になる人が多いらしい。また、典型的な例として、
2の場合に、aaa[5] の意味を理解できない人が多い。 >>344
多分それは、>>347 みたいな話で、優先順位を「ほどいて」理解できない人
が多いんだと思うが、実は、見た目と離れて、優先順位どおりに、
配列やポインタの記号を「直線化」するとそんなに難しい話ではないんだが、
数学の計算と同じようなことで、それが難しい人がいる。 >>342
実際にそういう人もいるが、自分が難しくて理解できないだけなのに、
言語設計に問題があるという風に捕らえる人もいる。そして多数決だと
圧倒的に後者のように感じる人が多くなってしまう。微分積分や
複素数、ベクトルはどれも美しい理論だが、理解できないために、
不要論が出てくるのと同じ。 言語設計は誉められたもんじゃないだろ
数学に例えられるレベルじゃない
でもC/C++に変わるものが無いのが現実なんだよね
結局これがベター
>>350
でも、ポインタの書き方なんかはC設計者によるとても美しい設計とも言える部分。
言語設計が汚いのは、むしろ、C++に後から追加されてきた部分で、特に
最近に付け加えられてきた部分が誰かの言ったように「ハウルの動く城」的
になっている。
ところが、逆のことを言ってしまう人がいて、その人はポインタが理解できる
才能が無い人だと思う。 >>351
そりゃ他の言語はC++のクラスを手本にクラスの仕様を決めてるからな >>352
いや単にポインターまでの概念しか理解できない人だと思うよ
参照、右辺値参照辺りが理解できないで批判する人多い >>354
右辺値参照が理解できないのは分かるけど、単なる TYPE &aaa みたいな参照型
は、ポインタが理解しにくい人用に用意されたとも言われてる機能で、
ポインタが理解できたのにそれが理解できないとは考えにくい。 右辺値と左辺値で参照レベルが変わるのがややこしい原因だと思うけどね。
変数名aを左辺で使うとaという入れ物、右辺で使うとaの中身。
*bを左辺で使うとbの中身のアドレスが指し示す場所、
右辺で使うとbの中身が指してるアドレスの中に入ってる値。
参照レベルを変える演算子のない言語なら意識しないところだが。
glvalue
rvalue
lvalue
xvalue
prvalue
入門者の皆さんはまず上記の違いを把握することから始めましょう！
そういうのしょうもないと思わないってのはほんとセンスないわ。
皮肉だろ
否定３つも使うな
お前は国語のセンスない
♪そうゆうの〜、しょ〜もないって、思わないって、ほんとセンスないないさぁ〜
作曲頼む
>>357
入門者はCを学んだ後、C++の class、メンバ関数、仮想関数、コンストラクタ、
デストラクタ、演算子のオーバーロード、継承、templateの基本などを学べば
C++の重要な部分は使えるので、xvalue、glvalue、prvalueなどは
すぐには分からなくてもいいと思う。 便利そうに見えても、CやC++の基礎をすっ飛ばしてboostやSTLを学ぶのは
C++の本質が学べないので良くない。それらにも配列やリストなどがあって、
C#などの高級言語風に使えるので初心者は勘違いしてしまいがちだが、
それらは「動的」なものが多く、本来のC++の速度が出ない事がある。
もともとのC++は、静的な配列が基本なので、速度を上げたいなら、
静的な方で済む場合にはなるべく静的なものを使うべき。その基本を知らずに
STLだけを何の配慮も無く使っていたら、昔からのC++のような高速なアプリ
を作るのは困難。
>>364
そんな考えだときりがない。
実測して時間かかってるところだけを改良したほうがいい
速度にほとんど影響しないところでも拘る、時間かかるはめになる。 たとえ動的な、vector を使っていても、それよりも速いコードを書けないw
それCで良くねってなってSTLとか使うのがおかしいとか言ってくるようになるんだろ？
テンプレートなんか使うんじゃねえとか。
>>368
そうはならない。C++とCの違いは、STLが使えるかどうかではなく、
class、コンストラクタ、デストラクタ、メンバ関数、仮想関数、
演算子の多重定義、template などが使えるかどうかだから。
STLは、言語ではなく、template library。 Cにおいては、「標準ライブラリ」と呼ばれたライブラリは効率が良かったので
特殊な環境や黎明期以外では、それ以外を使う必要性は特になく、ほとんどの
場合それを使えば良いと考えられた。
ところが、STLはそういう設計にはなっていないことが多いので注意が必要だと
言っている。
>>371
Cの基本的な配列などを理解してない人は、コンピュータの動作の細かな仕組み
が分かってないので、挿入時間や末尾追加時間、参照のための時間などが
O(1)やO(N) などと言われてもちゃんと理解できないので、良く分からずに
単純なC風の配列で済むところを、vector などを使って遅くなったりしやすい。
array, vector, deque, list などを目的別に区別して使うためには、Cの配列や
ポインタが理解できないと難しいはずだ。どれもデータを集合させるためのもので、
速度やメモリの効率以外には余り違いは無いが、どういう違いがあるかはCや
アセンブラでの基礎が出来てなければ理解できしにくいと思われる。
たとえば構造体のメンバに配列データを入れる場合、サイズが固定である場合も
多いが、その場合には、文句なしに、TYPE aaa[16]; のような C流の配列で
十分。そこに vector を使ってしまう人がいて、それはかなり効率面で問題となる。
そのような場合には、std::array を使うのも避けるべきである。 >>371
さらに、全ての場所でスマートポインター系を使おうとする人も出てきてしまうのも
問題点。 計算量と配列使うかvector使うかは別の問題なんだけど…
あとarrayの要件分かってる？
>>374
あなたは分かってない。
だからこういう風になる一例。 組み込みなんかだとvector始めSTL全部使えないとかあった
環境によっては標準ライブラリも全部使えないとかあったし
スタックサイズまで気にしなきゃいけないような組み込み系の話
初めはSTLやフレームワークに依存した書き方で学んでも構わんと思うがね
そういうものが使えない環境で開発する人は、その時にそのための書き方を学べばいい
ヒープに確保するならstd::vectorが実用上ほぼ最速
ダメだこりゃ
もうちょっとマシな答え返ってくるかと思ったが
>>380
雑魚の癖にえらそうにすんな。
お前は生ポインタ怖くて使えないだけだろ。 スマポはしゃーない
ライブラリがヒープに構築するオブジェクトを例外安全に使おうと思ったら使わんと
vecorというかSTLコンテナ全般だけど、push_back(void)みたいなデフォルトコンストラクタでの要素構築があればもっと良かった。
なんでないのかな。
std::arrayでなく生配列を使うべき理由なんてC++03以前との相互運用性以外には一切ねえよクソ雑魚
vectorも然りで、例外時にちゃんと捨ててくれないと困るときにはnewなんかやってられんし。
>>383
emplace_backを空で呼べばぁ？ ところで生ポ怖いとかそんなヌルい理由でSTL使うやつおるの？w
ポインタ覚えたてのボクちゃんがイキってはるように見えますね。
てか使わん理由がない
unique_ptrならオーバーヘッド0だろ
>>386
それでもmoveが発生するでしょ。美しくないw ナマポは怖いよ
あれの不適切な取扱いのせいで数限りないバグとセキュリティホールが生まれて莫大な損害を生み出してる歴史に学ぶべきだ
そうなれば適切な取扱いを強制する仕組みをなるべく取り入れるのは至極当然のことだ
>>390
MSVCとclangで試した範囲では、基本的にはスタック上に構築されたインスタンスをメモリコピーするアセンブリが生成される。
もちろん最適化で消えることもあるけど、全てというわけではない。
内部で確保されたメモリに対してplacement newで直接コンストラクタを呼び出すのと比べると若干のオーバーヘッドになる。 それコンパイラかオプション腐ってね？
moveが無駄ってのがemplaceの存在意義だろ？
>>393
emplaceはmoveコンストラクタを呼び出すための関数でしょ。
push_backだとcopyコンストラクタが呼ばれる。 push_backにも右辺値参照取るオーバーロードがあるんだけど？
emplace系（moveコンストラクタ）の利点は一時オブジェクトのデストラクタを呼ばなくて良いことであって、
メモリコピー自体は発生するよ。
すまん、おれが間違ってた、emplace_back(void)なんてものがあったんだなwwww
ないない
アセンブリ出力なんか見なくても
各コンストラクタに自分の素性を出力させるようにしてテストすりゃあわかる。
emplace_backはコンストラクタしか呼ばない
ムーブやコピーなどの余計なコンストラクタは呼ばれない。
v.emplace_back(A())
なんてアホなことやってたら呼ばれるけどなw
てかplacement newさせるための機能だから
よくよく規格読むとemplace_backの要件のところでなぜかvectorに限って要素型にMoveInsertable要求してるな
(Table 88 - Optional sequence container operations)
vectorに限ってはID:z0GlqJ7U0の言う通りmoveするのかもしれんが何故だろう
アロケータ絡み？
それ、領域の再確保で既存要素をmoveする必要があるからじゃね
そうかと思ったんだけどdequeにはこの要求ないんよね
dequeの場合、最初と最後に限っては既存要素の移動が必要ないからだろう
>>401
size()がcapacity()を超えた時ごっそり移すから >>391
実際はナマポによる問題よりもスマポの取り扱いのわからんバカによる間違った使い方のが多いけどな。
重要なのは言語による強制じゃなくて、教育だわ。
そこのコストを無駄にケチるバカ企業はどんな言語使っても無駄。 >>406
結局、生ポインタや生配列も必ず必要になるから、仕組みを理解せずに使えば
コンテナやスマートポインターの方こそが危険の原因になるのは容易に想像できる。
結局、実装の詳細を知らなければ危険なので、初心者向けでない。 >>408
生ポインタや生配列をコンテナやスマートポインターに置き換えて危険の原因になる例おしえて。 こうやって具体例も出さずに古い知識と気分と思い込みでコンテナやスマポを意味なく禁止してナマポや生配列を強要する老害が一番危険
生ポ受け取って処理して返す関数の中で
受け取った生ポをユニポに入れてしまって
関数から抜けるときに消えちゃうバカとか？
コンテナなりで確保して必要なときにポインタで渡すだけだろ
結局このての老害が居座ってるのがこの言語の一番の欠点だわ
下手にC言語と互換性があるから頭の悪いナマポおじさんが初心者に間違った知識を広げていくという
>>379
vector で、TYPE型のオブジェクトを N 個収める場合、通常は、
2 * N * sizeof(TYPE) + (制御情報)
程度のバイト数が必要になる。一方、Cの生配列の場合、
N * sizeof(TYPE)
で済む。重要なのは、必要メモリに2倍もの開きがあるということ。
つまり、配列なら10MB で済むところが、vector だと20MB必要になる。 メモリ使用量という観点では、vectorよりもlistの方が優れる。
vectorは、メモリを2倍使用することで末尾追加の時間をO(1)に抑えているだけ。
固定長で済む場合はCの生配列を使うべき。
サイズを徐々に大きくしていくようなばあいは、vectorよりもlistの方が良い場合が
多い。ただし、listはランダムアクセスには向いてないが。
なお、TYPE のサイズが大きい場合に vectorを使うと、Core i7 でも Celeron 並み
にCPUキャッシュメモリが減ったかのようになり、せっかくのハイエンドなパソコンが
エントリーモデルのパソコン並みの速度になってしまうかも知れない。
生配列かvectorかlistかって論点古すぎ
今c++の複雑さはそういうとこじゃないから
他の言語含めてもうちょっと勉強しろ
明らかにC++03時代の入門見て覚えた知識を頑張って披露してます状態だな
勉強足りなすぎ
typeのサイズが大きい場合に生配列使うとそれはそれで問題にならん？
>>421 >>422
雑魚は黙っててくれ。レベルの低い人は自分がレベルが低いことに気が付かない。
このままだと日本のITは壊滅的なままだから。 >>424
はいはい雑魚雑魚
boostのstatic_vectorって調べてみな
生配列とvectorのいいとこどりのコンテナだ
eastlにも似たようなのあったはず
おれも大概おっさんでc++にネガティブな思いはある
だけどお前みたいな老害にはなりたくないな >>425
static_vector みたいなアホみたいなものを持ち出して。
黙ってろよ馬鹿は。
想像力が足りない人が既にあるものをいくら勉強だけしても駄目なんだよ。 約2倍使うのって追加するときに内部のサイズが足らん場合だけだろ
後別に遅くないがな
基礎をすっとばすのが良くないというのは同意だわ
C++はスクリプト言語の代わりにはなれない
>>418
その*2はどこから出てきたんだ？
生で10MBでサイズ既知なら、vectorでも10MB+固定サイズ制御情報にしかならんだろ そんな細けーこと気にするならデフォのnewやmalloc使ってたら笑うぞ
>>429
vectorは構造上はリンクリストではなく、Cの生配列と全く同じ形式で
要素を単純な配列として持っているが、最初に最大要素数を指定しなくても
後から動的に要素数を増やす機能も持っている。この機能の実現の際、もし、
今入っている要素数とぴったり同じだけの個数が入る配列でデータを持っているだけだと、
1個ずつ末尾追加したときに、毎回、今までと同じ大きさの新しい配列を new し、
古い配列のN個の要素を全て新しい配列にコピーする動作をしなくてはならず
とても時間がかかってしまう。それを防ぐために、原則的には 今入っている
要素の2倍の配列を内部的に持つことにされている。そうすることによって、
要素数が2倍に到達するまでは、末尾追加しても今言った「new してから全てコピーする動作」
をしなくて済むようになる。そのために、必要メモリが生配列の二倍必要になっているらしい。 最悪の場合を言ってるのだろう
平均で見なきゃ意味ない
そんなこと言ったらクイックソートだって
そもそも好きに使って経験を積みゃいいんだし手法を統一する必要もない
>>435
CPUの内部キャッシュは、ハイエンド機種でも8MB程度しかないので、
むやみにメモリを使った場合の速度低下は著しい。 用途要求仕様要件目的予算を特定せずに何を判断せよと
#include <iostream>
#include <vector>
using namespace std;
int main() {
std::vector<int> v(10);
cout << v.capacity();
return 0;
}
>>431
どこのコンパイラが20や15表示するの？教えてよ
俺の手元のGCCとclangとVCとiccは当然だけど10だったよ
そんなサイズ伸縮やreserveもする前から手前勝手に1.5倍やら2倍やら確保するコンパイラがあるなんて怖いからさ
お前の妄想や思い込みじゃないなら当然答えられるよね？そんな長文書くほど自信満々なら知らないわけないよね？
教えてよ >>439
仮に要素数と内部テーブルのサイズが原則同じなのであれば、>>431
で書いたように末尾追加がかなり遅くなる。その場合、std::vector
とstd::list では末尾追加の速度が劇的に違うことになる。 末尾追加したいのかCのように固定長で使いたいのかはっきりせぇや
どう転んでも文句言いやがってw
生配列と比較するならサイズ既知なのだから、サイズ指定して初期化、もしくはreserveするのは当然だろ
push_back使うなら、生配列の側も現在の実サイズを別変数で管理しないと公平でない
>>442
区別することが大切だといってるんだよ。 キャッシュなんてキャッシュラインサイズごとに読み込むのだから
使いもしないvectorで確保した領域全部読むわけちゃうぞwwww
vectorか生ポかなんて低次元な話ではなくメモリアライメントまで気にしとけと。
だからごちゃごちゃ言うやつはデフォのmallocなんか使ってないよなと確認したのにwww
「トレードオフを理解はするが、許せない」
こういうことか？
>>440
あっはい追加時の話はどうでもいいです
追加量が読めてるならreserveなり最初に大きめに構築するなりするだけだし、読めてないならそれ必要なコストですよね？
私が聞きたいのはreserveや要素追加も伴わずに勝手に常に2倍で確保するというコンパイラorライブラリの具体的な情報です
質問に答えてください >>443
固定長でとったら伸ばせないと文句いい
伸ばせるようにしてたらメモリ無駄と言い
文句言いたいだけやろwww >>441
そういうことじゃなくて、新しく追加された機能を何も考えずにそのまま使って
C#との速度比較に用いてC++がC#に負けたと主張するQiitaの記事が「C# 速度」と
いうGoogle検索で上位に来るから困るんだよ。 >>448
なんでそういう低次元な前提で機能自体を否定しにかかってんだよwwww
そもそも無駄だから生ポ使えと主張してたくせに曲げてくんなよwww この展開だと、知識もスキルも足りていない奴が、誤解でvector使えないといっているだけにしか見えないな
>>448
C#？？Qiita？？C++98からあるvectorが「新しい機能」？？？？？
キチガイのフリしてるんじゃないなら逃げずに>>439>>446に答えろ。知らんなら知らんと正直に言え
答えないならフリじゃないとみなす 日本のITが駄目な理由がここに全て現れている。
その上、自分達がレベルが高いと思っているのがまた痛い。
日本はもう二度と浮上しないな。
>>454
OK、知らないってことね。もしくはキチガイごっこ続けるわけね
>>431みたいなことドヤ顔でほざいて、根拠求められれば逃げ回って結局示せなくて
お前とコードレビューしてる同僚はさぞ仕事が辛いだろうな
同情するわ >>454
逃げる前にお願い
効率悪いとかそういう話ではなく
一番最初に主張していた
スマポとコンテナの方が生ポより危険
をちゃんと言ってからにしてよ。
危険性の話から効率の話になってc#とか言い出して
ひたすらトーンダウンなんだけどwww やめたれよ
vector2倍コンパイラの名前をずばり答える能力すらない人間にその抽象的な質問は難しすぎる
駄目なところは用途によって変えるべきなのに包括的に物事を判断することしかしないから
vectorが確保するcapacity程度でも気にすべき環境なら当然気にするし、そうじゃないなら気にしなきゃいい
気にしなくて良いケースでもとにかく重箱の隅をつついて難癖つけるような輩が居る
サービス利用者からみて大差無けりゃどうでもいいのに変なところにこだわり持つからサービスが生まれない
なんや今日はいろんなスレでキチガイ多いなと思ってID見たら
VS2019スレで妄言垂れてたのと同じキチガイじゃねえかｗ
このボケ老人よそでも暴れてたのか
くわばらくわばら
そもそもmallocでも管理領域あるしな。
さもなくばfreeするときサイズわからんようなるからwww
2018年度の流行語大賞をとった彼じゃないの
C言語なら俺に聞け 148
http://2chb.net/r/tech/1537347410/37
37 名前：デフォルトの名無しさん (ﾜｯﾁｮｲ f94f-yqSl)[sage] 投稿日：2018/09/22(土) 01:42:06.64 ID:16ZpsTnK0
>>36
（略）
> void show_all(void)
なんだこれ？引数 void って初めて見たぞ。文法的にありなのかこれ？
（略） まあ今のC++で生配列と生ポインタ使う理由はゼロだわな
vectorに対する難癖が叩かれる割に
>>464みたいな井の中の蛙が叩かれないのは理解できんけどな
まぁこんなこと言ったらまたファビョる奴が出てくるんだろうけど C互換APIは生配列と生ポインタで受け渡しなので完全排除は不可能。
狭いローカルスコープ内にある
int arr[3] をわざわざ std::array<int, 3> にしようとも思わないけどな
なるべくスマポとarrayに変えていくべきだというのも、置き換えきれない所があるのも両方とも正しい
どっちかの極端に走るとさっきの老害みたいになる
>>468
あなたの脳内では、
「C言語は危険なので成るべくBASIC言語に置き換えていくべき」
なんだよね。 無能の意見 ---> 「自転車は危険なので全員三輪車に乗るべき」
>>471
有能なアナタなはもちろん自分で披露した知見の裏付けくらい当然に示せますよね？
>>446に答えるか無能を認めるかさっさと選べよ 昔、「BASIC言語は誰でも使える」と言われていたが、STLのコンテナや
スマポを使ったプログラムは、絶対にそれだけを使って、かつ、効率を
考えなければそれに匹敵するくらい簡単。
でもそれでは駄目な領域が有る。
何の主張で議論してんのかさっぱりわからん
マウント取りたいだけ大会みたい
>>473
話が変わってるぞ
スマポとコンテナが生ポより危険だと言っだろ
それを示せと >>478
それがどうやらvectorは生配列の2倍の容量を食うから効率悪いんだってさ(>>431)
GCCclangVCiccでは違うけど、そんなコンパイラが本当にあったら大変だからどんな環境だとそうなるのか気になるよね
というわけで>>446に今すぐ答えてねID:Odxsa8jS0さん
さっさとしろよグズ この板のような匿名性の過疎スレはレベルの低い連中の意見が多数派になりやすい。
つまり少数精鋭の完全な逆。
>>480
レベルの高い>>446への回答をよろしくお願いします
いつまでも逃げ回ってんじゃねえぞ卑怯者 アホだから要素追加時のとごっちゃになってんだろう
要素0でpush_backしたらキャパ2以上になるのはそれなりにあるんかな
馬鹿にはいくら言っても本質が理解できない。ちゃんと答えても的外れな
観点で何か言って来る。質問自体が馬鹿だから答えてもしょうがない。
いっとくが、むしろ俺は天才といわれてる。天才の言うことが理解できない
凡人たちだ。ここの人は。
>>485
凡人なのでvector2倍コンパイラの正体がわからないと不安でたまりません
天才の閃きで>>446に答えてください
もしくは自分を天才だと思い込んでる狂人だと認めてください >>489
自分で行ったことへの責任すら取れないアンタが客観的に見てこのスレで一番の雑魚だよ
雑魚扱いが嫌なら>>446に答えろ
答えないなら言いっぱなしの無責任で卑怯なクソ雑魚として永遠に軽蔑する >>483
一般的には、capacity()サイズを倍々にしていく実装が多いんじゃないかな？ >>489
通常は2倍と聞いている。恐らく、上に上がっている例だと、何らかの
事情で2倍になっていない特殊な結果が出たのだと思われる。 凡人は本質を理解できないからソースを見たり実験しないと分からないんだろう。
天才はソースも実験もしないでも結論が分かる。数学と同じだ。
実験して結果が違っていたとしてもそれは例外だと断定できる。
なぜなら、絶対にそういう実装で無ければ成らないことが天才には分かるからだ。
凡人の反論は受け付けない。これは絶対だ。実験とか関係ない。
そっか
天才様の書いたプログラムは必ず天才様が思ったとおりに動くに決まってるから、動かしてテストもしないんだね
怖すぎるから絶対に本番用コードに近寄らないでね天才様
>>495
関係ない。数学とはそういうものだ。テストなんか無くても結果が分かる。
絶対に正しいということが分かるんだ。それが凡才と天才の違いだ。
ここには秀才レベルもいない。 適当に書いたことに予想外に食いつかれて、
答えられなくなったからネタに走ってごまかそうとしてるだけだろ
「便所の落書きに天才現る (2)」
(c) 蟻人間 2019年7月発行.
無断転載を禁ず.
>>492
倍々なのか
変な人が勘違いしてたのはそのへんか >>496
うん、天才様はそれでいいんだろうけど、凡人の世界では書いたコードは必ずテストして報告書を納品するものなんですよ
天才様は我々凡人のやり方とは合わないでしょうから、どうぞお一人で自分のためだけのコーディングを楽しんでください
未テストのクソコードを凡人世界に持ち込まないでくださいお願いします プログラミングでテストが必要なのは、たとえば、過去に書いた何万行ものコード
を全部は思い出せないので、grep検索などで調査した結果にもと髄手後から機能追加
する時にミスが入り込んだり、ケアレスミスがあるからだ。
ところが、アルゴリズムのようなものは数学のようなもので、完全に正しいことが
天才には分かる。ところがここの人たちは凡才なので分からないから、いつまで
たっても証拠を見せろ、説明せよ、を連呼し続けてるだけだ。しかしそれは、
天才の結論が間違っていることにはならない。
あれということは追加したときに足らんときって一時的に約3倍メモリくうのか
>>499
勘違いなどしてない。勘違いだと思い込むのは、ここの人たちが凡人だからだよ。 >>500
数学とプログラミングのテストは異なるといってるんだ。
今回のは数学。プログラミングにテストが必要なのは>>501に書いたような
理由による。天才でも記憶力は有限なのでソースが大きくなると勘違いが
生じることが有ったり、ケアレスミスがあるのでテストは必須となる。
ところが、今回のような例ではテストも何もいらず、結論が見えてる。 つまんね
自分を天才だと思いこむ狂人を演じる雑魚ってどんだけ殻被らないと自分を守れないの？
もうオモチャにする価値もないわNGします
まずvectorはN個の要素を確保するときはN個分でふつうの配列と同じ分だけ確保する
要素追加時にキャパ足りない場合は配列の1.5とか2倍に増加する
この時ID:Odxsa8jS0のいうとおり2*Nとかになるときがあるという話ですね
>>509
最初に確保したまま、絶対に後から追加しないなら、固定長配列で十分だから、
2倍などになっていることの方が通常。ただし、2倍、2倍で増えていく場合でも、
平均のテーブルサイズは、要素数の1.5倍+(固定サイズの制御情報)となる。 >>509
そうだね
キチガイが間違ってるのは末尾追加に備えて常に2*Nを確保するという主張 >>512
少なくともGCCとclangとVCとiccは違うよ >>511
アホはだまっとれ。誰も2倍固定などとは思ってない。4倍でもなんでもいい。
とにかく、そのような「感じ」で増加していくということだけだ。「感じで」
といったのは数学的感覚に優れた秀才以上の人でなければ理解できなくて、
凡才には誤解を招くだろうが。 >>513
何度も行ってるが、それはテストの時にたまたまそうなっただけ。 >>515
君のいうとおりになった環境とコードあげたら君の勝ちよ >>516
数学というのはテストしなくても結果が分かるので、馬鹿馬鹿しいので探す
気になれない。天才の中での数学的確信というのはそれくらい強いものなんだ。 天才様、ReactOSの開発を手伝って下さい。お願いします
>>518
お前みたいに何が危険なのか分からない人が出てくるのが、危険な理由の1つでも
あるんだよ。 >>517
テストしなくても分かるなら探すまでもなく名前挙げれるでしょ >>521
違う。絶対そういう仕組みで無ければ成らないことが分かるだけだ。
どの実装とかそんなものは関係ない。Mr.スポックでもグレイでも
ほぼそれしかできない。 >>522
まあ、この件に関しては、宇宙人レベルまで言うのは言い過ぎだったかもしれない。
ただ、現在人類がしている知識ではその程度のやり方しかない。 キチガイ見えない状態で書いてるけどなんかほざいてるっぽいので
通りかかった初心者が勘違いしないように正しいこと書いておくね
std::vectorのpush_backが要求する計算量は「償却定数時間」で、これはざっくり言うと
たまに長い時間がかかるけどそれが稀なので、平均的には定数で抑えられるってこと
capacityいっぱいのvectorにpush_backをすると領域再確保してO(n)かかるけど、その頻度がnのオーダーより小さければ償却定数時間になる
2倍2倍で広げるってのはそういうこと（再確保の頻度がO(logn)になる）。2倍に限らず1.5倍とかでもいいしそれは実装次第
で、キチガイの主張は「push_backは定数時間！だからその保証のために追加先として始めから2倍の領域を確保してて効率悪いんだ(ﾄﾞﾔｧ…」だけど見ての通り大間違いね
capacityがいっぱいになってから再確保すれば償却定数時間には十分で、要素が追加されるかもわからない最初の段階でそんな事する必要はまったくない
当然ながら実際にGCCとclangとVCとiccは、例えば要素10個で構築されればcapacityを10にする常識的な実装をしている
追加量が読めていて、何度も2倍2倍で再確保するのが無駄な場合はcapacityをあらかじめ広げるreserve()という操作があるので、それを使えば効率的になる
蛇足だけど、キチガイの主張通り常に2倍の領域を確保したとしても、push_backの（償却でない）定数時間は達成できないことも指摘しておく
その2倍が埋まったら結局再配置はしないといけないわけだからね。キチガイ式の実装は再確保のタイミングをずらして、メモリを無駄にしつつ当初の目的も達成できないという
大変悪い見本です。真似しないようにしましょう
以上、長文失礼しました
>>525
アホ。お前が考えているようなことは最初から分かった上で言ってる。
変な言葉をひけらかしても関係ない。天才には知識が無くてもイマジネーション
だけで全てが分かる。 >>525 の勘違いは、「勉強しなければ分からない」と思っているところに有る。
天才は勉強しなくてもその場で考えれば自力で本に書いてあること同じ結論が
導ける。だから、言葉は分からない。ただ、同じアルゴリズムがひらめく。
そして全てが分かる。 >>419のメモリ使用量でvectorよりlistが勝るというのも間違いだよね。 >>528
いくらでも有るから言わない。馬鹿馬鹿しいから。
少しは自分の頭で考えてみろ。 >>530
1つの要素 TYPE のサイズが十分大きいばあいは間違いじゃない。 >>531
だから書いてるじゃん
お前はいくらでもある例を一つも出してない。
そのくせメモリがーキャッシュがーとか最初の危険という趣旨のことばかり並べ立てる
馬鹿だろ listはシーケンシャルアクセスでも異常に遅いけどな。
中間挿入の頻度がシーケンシャルアクセスよりも低い場合はdeque使ったほうが遥かにマシ。
>>532
やっぱりお前さんは阿呆か？
std::listは１要素に対して要素のデータとポインタ２個消費する。std::vectorはヘッダーとcapacity個の要素のデータだけだ。要素が多ければlistの方が不利。 >>533
それはコンテナの具体的実装によって危険な場合の書き方が変わってくるから、
数学的な才能だけがあってもSTLの個別具体的な勉強はしてない俺には語れないから
言わないだけだ。 std::listはメモリ局所性が低いので現代的なコンピュータだと遅いってのはよく言われてる
サイズが小さいと中間挿入でvectorに負けることさえある
天才様のクソ実装だとvectorは要素数の2倍のcapacityを抱えてなければならないからlistよりでかくなるんだよ
天才様のクソ実装がいかにダメ実装なのかを示す実例なわけだ
今のコンピュータなんて100MB単位でメモリ食ったって構わんのだしメモリ効率なんてそこまで気にすることか？
気にしなきゃならん組み込みの開発ではSTLなんか使わんだろ
>>539
さっきからずっと小学生の喧嘩のような返ししかできてないけど、もしかしてリアルキッズ？
お前がどんなに自分を天才だと評価して事実天才だったとしても、周りからはただの興奮して引くに引けなくなったバカとしか見えてないよ。
天才アピールしてるし周囲にもそう認識して欲しいなら、それが実現できるように頑張りなよ。 >>543
そんなめんどくさいことしても、凡人以下のここの人には理解してもらえない。 まあ、せいぜい数年掛けて理解すればいい。
一生理解できない人も多いのかも知れんが。
そんな世話してられないし、知らん。
要素を挿入したときにイテレータが無効になってよいかどうかがlistを選択する基準で結論が出てるんですよ。
これ、欧米では20世紀に決着がついてるんです。
天才は明快な直感に導かれ、才能を実証する。秀才は歴史や書物に学び、凡人は愚鈍な考えや経験に頼る。
std::listは、連結リストである。rbeginとrendを持っているから、逆方向にも走査できる二重連結リストである。二重連結リストは、1個の要素に対して要素データと2個のポインタを消費する。
要素データのサイズをEとし、1個のポインタのサイズをPとすると、std::listが1個の要素に対して消費するメモリーサイズは、(E + P * 2)バイトとなる。
要素数やルートポインタを含むヘッダ情報のサイズをH1とし、n個の要素があるとすると、合計 H1 + n * (E + P * 2) バイトとなる。
std::vectorは、動的配列であり、要素の個数や要素を格納する連続データへのポインタなどを含むヘッダ情報を持っている。
ヘッダ情報のサイズをH2とする。capacityの個数が実際の要素の1.5倍だと仮定すると、(H2 + n * E * 1.5)となる。
listよりvectorの方がサイズが小さいと仮定すると、
H1 + n * (E + P * 2) > H2 + n * E * 1.5.
n * (E + P * 2 - E * 1.5) > H2 - H1.
n * (P * 2 - E * 0.5) > H2 - H1.
n > (H2 - H1) / (P * 2 - E * 0.5).
となる。
>>549 訂正。(誤)サイズ → (正)メモリー消費量 >>549 この不等式は、トートロジーではない。
よって
>>419
>メモリ使用量という観点では、vectorよりもlistの方が優れる
というのは、常に正しいとは限らない。その点は、>>532 で軌道修正された。
>>532
>1つの要素 TYPE のサイズが十分大きいばあいは間違いじゃない 凄まじい勢いでスレ伸びてて草
久々に香ばしいのきたな
>>552
その間違いは致命的だろ
おかげで台無しになったんだぞ あれ？ dwMemoryLoadは、MemCheck1の方が小さいのか。。。
分からなくなってきた。。。
>確かにstd::listの方がメモリー消費量が少ない。
これは間違い。Availが少ない → 消費量が多い
だから std::vectorの方が消費量が小さいということになる。
180°正反対の間違いをしておいて他人を笑うとは。
中学レベルの問題が直感で分かるような自称天才は、問題を見るとすぐ答えがわかるから、自分が天才・神童だと思い込む。
しかし、複数の変数が絡む数式になると直感は外れるようになる。だから、考える努力をしない自称天才は高校くらいで落ちぶれる。
>>372
リスト・配列の特性、真ん中あたりの要素の削除の計算量などは、情報処理資格の内容にある
C++ は最高難易度の複雑さだから、さすがに資格を持っていない香具師は、門前払い！ >>559
まあよくあることだわ。
扱いには困るが。 std array使わないで生配列推奨する意味がわからない
どのようにプログラミングしても、vector には勝てない！
真ん中あたりの要素の追加・削除で、大量の要素がズレても、それでもvector が有利！
だから素人は、vector を使っておけばよい
リストは、ランダムアクセスできない。
常に線形探索だから、O(n)
Rubyのしくみ、2014
Rubyの実装系、Ruby1.9のRuby仮想マシンの本に書いてあるけど、
Rubyでは、Hashの要素数が増えていくと、再編成される
バケット数は、2の累乗付近の素数を使う。
つまり、倍々に増やしていく
8+3, 16+3, 32+5, 64+3, 128+3, 256+27, 512+9...
1つのバケットには、平均して5つの要素を入れる(衝突)。
11*5=55, 19*5=95, 37*5=185...
つまり要素数が、56, 96, 186...個になると、
バケット数を増やして、再編成する
普段、1万個の要素を追加するのに、8msかかるが、
再編成するタイミングでは、20msかかる。
要素数が増えていけば、もっとかかる
10万個なら200ms、100万個なら2秒と、再編成があるたび、ドンドン増えていく
>>563
std::arrayはサイズで型変わるから
そこが面倒なこともある >>558
違う。
vector は、最悪、a*N*sizeof(TYPE) + (制御情報サイズ) だ。
listは、常に、N * ( sizeof(TYPE) + ポインタサイズ * b ) + (制御情報サイズ) だ。
aは、実装依存で、典型的には2。vectorを確保した直後を除いて1であることはない。
b は、1または2。
あなたのやったテストでは、vector を確保した直後だから、a=1になっていただけ。 vectorとかlistとか初心者向けの話題いつまでやんの？
まさにパーキンソンの凡俗法則だな
天才様が主導してるわけだがw
使用メモリって観点だと、realloc時は要素数の1+a倍だから、最悪値もそれになる
まあ、要素数の見積もりが全くできない状況でもaは容易に制御可能でcapacity見ながらreallocが起こる直前のpush_back前にreserveかけりゃ済む
最悪1要素ずつ拡張すればa~1
性能は最悪だがw
参考書に答え書いてあるものを永久に語り続けるのおもろ
std::list<std::string> lines;
std::string l;
while(std::getline(std::cin,l)){
lines.push_back(l); //(1)
//lines.push_back(std::move(l)); //(2)
}
だと(1)の方がいいよね
特に行内の文字数、行数が大きくなると速度差はかなり大きくなる。
stringじゃなく同様のvectorでも同じ
listだと(2)が速いだろうけど
>>549
あなたの誘導に沿って説明しよう。
要素の型をTYPEとすると、要素の1つのバイト数を、E=sizeof(TYPE)であり、
それが、x 個ある場合を考える。
L(x) = H1 + x * (E + P * 2) // list に必要なバイト数
V(x) = H2 + x * E * 1.5 // vector に必要なバイト数
となっている。
P は、ポインタ1つ当りのバイト数であり、Windows の 32BIT モードの時は、4 である。
これらの関数は、どちらも n に対する1次関数で、
グラフにすると、傾きはそれぞれ、
a_L = E + P * 2 // list の必要バイト数の傾き
= E + 8
a_V = 1.5 * E // vector の必要バイト数の傾き
だ。
要素1つ辺りのサイズ E が十分大きい場合、たとえば、100バイトの時を考えれば、
a_L = 100 + 8 = 108
a_V = 1.5 * 100 = 150
となる。
だから、V(x)の傾きの方が、L(x) の傾きのよりも大きい。
だから明らかに V(x) の方が効率が悪い事になる。H1, H2 がどんな
値であれ、要素数 x が十分大きい場合にはメモリ効率の良さは
xに対するグラフの傾きで決まる。H1, H2 は、いわゆる「y切片」
を決めるだけで、x が大きい時には影響はなくなっていくから。 >>576
[続き]
>>549 の最後の方は：
『listよりvectorの方がサイズが小さい』・・・・☆
と同値な条件は、
H1 + n * (E + P * 2) > H2 + n * E * 1.5 ・・・・(1)
⇔
n * (P * 2 - E * 0.5) > H2 - H1 ・・・・(2)
である、というところまでは正しい。ところが、中学校で習ったように、
不等式では、両辺を負の数で割るると、不等号の向きが逆になってしまう。
だから、割る数が正か負かを気をつけないといけない。
今、E = 100, P = 4 だから、
(P * 2 - E * 0.5) = 4 * 2 - 100 * 0.5 = 8 - 50 = -42
となり、負の値である。E が1000や10000の場合は、どちらも
もっと絶対値の大きな負の値となる。だから、この部分は要素のサイズ
が十分大きいと必ず負の値である。ゆえに、(2) をこの数で割ると、
n < (H2 - H1) / (P * 2 - E * 0.5) ・・・・(3)
となり、あなたの書いた式とは不等号の向きが逆となる。
さて、この(3)の意味は、右辺の値は、Eの値が100の場合は、分母は負の値であるが、
分子の H2-H1 の値は実装依存なので、右辺全体としては、正か負かも定まらない。
そこで、右辺の値を R とおくと、n < R という式になる。
この意味は、ある値 R よりも要素数 n が小さいと、この式が成立する、
ということである。この式は、あなたが書いたように、
☆と同値な式である。だから、ある値 R よりも要素数 n が小さいと、
☆が成立することを意味している。つまり、要素数が十分小さいときに
のみ「list より vector のサイズが小さい」のである。逆に、
要素数が十分大きければ、「list より vector のサイズが大きい」
ことが言える。 数学得意とか言うわりに内容が中学生レベルなのをわざわざ説明するとか
>>576
誤：これらの関数は、どちらも n に対する1次関数で、
正：これらの関数は、どちらも x に対する1次関数で、 >>579
ここにいる人たちが、懇切丁寧に説明しないと分かってくれないからだよ。 メモリ容量が厳しいときにreserveしないなんてあり得ないし、Typeがでかく、要素数不明なときにそのままvectorに放り込むとかも普通しないよね
それこそスマポとか使ってでもlist使わない方がましな場合が殆んど
>>582
数学や科学の世界は、簡潔に説明なんか出来ないんだよ。
だから、簡潔を望む人は科学や数学には向いてない。 （自分が知っている部分だけ）懇切丁寧に説明しないと
＝知らない部分は無視して天才どうのこうので議論を拒否する
説明した部分に疑問持ってるレスどれ？
大体が生配列とvectorの比較だったわけだが、なんで可変長でのメモリ使用でlistと比較しているんだ？
vectorじゃなく生配列使うべき有意な優位性を説明しろと
>>583
要素数と要素のサイズが大きいとき reserve()するのに時間がかかる。
昔から知られているが、リンクリストだとその手の作業が必要ないので、
速度とメモリの両方の効率がバランスが良い。 そもそも、最大限使えるメモリ容量から計算してreserveしておけば、listよりより多くの要素数格納できるんだな。
listの場合malloc的なものの管理領域も大きくなるってのも、メモリ厳しい場合には無視できない
>>560
行列がわからない自称上級者の蟻さん、ﾁｰｯｽ >>587
生配列に必要なバイト数：
A(x)=E * x
vector に必要なバイト数
V1(x) = H2 + 1.5 * E * x // 平均時
V2(x) = H2 + 2 * E * x // 最悪時
これらをみるだけでも、生配列の方が効率がいい事が分かる。
要素を書き込む時にも、生配列は典型的には1クロック。
vectorだと、境界チェックが入るので5クロックくらいは必要となる。
境界チェックは条件 jump なので、パイプライン類の乱れが生じ
だいぶ遅くなることが有る。 listとvectorの違いなんて皆わかった上で議論しているのに天才さんはバカなの？
最近アルゴリズム入門書でも読んで語りたいだけなの？
>>589
それもあるが、reserve()は時間がかかるので、扱うデータが巨大な場合には、
無駄が多くなるのと、reserve()するまでの最悪時には2倍の領域が必要となる事が
メモリ用件が厳しいときには問題となることも有る。
ただし、listにもデメリットは有る。それは、1要素を追加するときに new されるので、
典型的には150クロック程度の時間がかかってしまうことだ。 容量既知なら配列との差は管理領域とヒープが別になるオーバヘッドだけ
ヒープが別になるってのを責めて来るならまあ分かるが、容量既知なのに全くその情報使わない最悪値で比較とかセンス無さすぎ
size 0でのreserveは別に時間かからんだろ
それこそlistで要素追加でnewされるの1回分と大差ない
MATLABで演算するときforループを使って一つずつ計算するよりもsumやmeanなどの関数を行列に対して行う方が圧倒的に速いのですが
C++にもMATLABのように一括で高速に行う方法がありますか？
>>593
なお、要素が、サイズが小さくて、かつコンストラクタを持たないような
単純なデータだとreserve()の時間が list の (150 * 要素数) (クロック)
よりも短いことも少なくて済む事もあるが、サイズが600バイトを超えたり、
要素の中に、newして持っているデータがあるような場合があったりする
場合や、要素のコンストラクタが重い作業を行うには、reserve()は、
listよりも遅くなる。
だから、要素が今後のプログラミングの過程でどんなものになるか分からない場合には、
listは安定した速度が維持できるが、vectorはだんだん遅くなっていく恐れが有る。 クロックとか言ってるやつもロートルだな
全く世の技術についていけてない
>>596
「>>598」にも書いたが、要素のサイズが大きい場合や、要素のコンストラクタの
重い場合には、reserve()はとても遅くなる。要素のコンストラクタの中で
メンバの確保やコピーのためにnewが1つでも行われる場合には、listよりもほぼ必ず
遅くなる。コンストラクタ内のnewがN個だとlistのN倍遅くなる。 ハイパフォーマンス必要なとこでlistなんか使わないからど素人さん
>>601
それに、reserve()のためには、一般的には、要素は、コピー・コンストラクタを
持つ必要がある。一方、listの場合には、コピ・コンを省略できる。
C++を使っていると分かるが、デフォルト・コンストラクタを作ることはほぼ必須
だが、コピ・コンはめんどくさいので書きたくないことが多い。その場合に、
listの方が楽。 >>602
vectorとreserve()の組み合わせはもっと駄目だ。 forward_list
とか知らないんだろうな
バカそうだし
>>601
要素既知の配列と同様の用途の場合、まともなスキルのあるプログラマなら、サイズ指定constructor、empty状態でのresize、empty状態でのreserve
のいずれかを使う。
そうするとmalloc一回と、前者二つは要素数分の要素型の配置newデフォルトもしくはコピーconstructorが呼ばれる。 >>604
お前の頭中、vectorかlistしかないのなw
もとの生ポ押しはどうしたの？w vector相当にcapaciry()+xなreserve相当をするCArrayってのがあってだな
MS自身がどうしてもこれじゃなきゃ駄目な場合以外使うなと言うくらいの糞
>>606
要素数既知なら、最速が TYPE aaa[N] で次が new TYPE[N]。
逢えて vector を使う意味がない。
empty状態の reserve() とかしてまで vector にこだわる意味が分からない。 >>607
むしろ逆で、生配列使えばいい場面で、何故か vector に固執する人がいるんだよ。 サイズ完全固定ならstd::array
最大サイズが既知なら少し無駄だがvector
格納領域内包する最大サイズ指定のvector擬きがあればベストなんだが
後はサイズが大きくてスタック上に確保したくない時もvector使うだろ。
>>613
その場合は、TYPE *pAaa = new TYPE[N]; 自称天才すげーな
自分が何かいてるのか分かってないんだろうな
規格も読んでなさそう
>>614
てか今時こんなコード書く奴いたら、できうる限り関り合いにならないようにするね。
こんなのが先輩面して新人に教育してたらもう最悪 >>618
あなたは、C++とC#の速度が変わらないと思ってる系統の人だよね。 >>597
ベクトル演算とか、並列処理とか
OpenCL, CUDA とか shared_array はまだ標準化されてないんだね。
>>622
std::array を使うと例外安全が確保されて、
TYPE *pArr = new TYPE[N];
だと確保されないと思うのはなぜ？
絶対に確保できないと言い切れる根拠でもあるの？ とりあえずnewとかmake_sharedとかIDEがなくても型が明らかな場合はauto使おう
>>624
「ヒープを回収する」
とはどういう意味か分からない。
メモリ確保の失敗は大体回復不可能なはずなんだけど、どうするつもりなの。 「メモリ確保に失敗したこと」のメッセージを出す以外に対処法はないと
思うんだけど。
なんでnewで例外起こる話しているんだか
本当に全くわかっていないのね
どうでもいい話はやめて今までにない新しい画期的なテクニックの話をしてくれ
頼む
一生のお願い
>>549
> n * (P * 2 - E * 0.5) > H2 - H1.
> n > (H2 - H1) / (P * 2 - E * 0.5).
> となる。
(P * 2 - E * 0.5)がマイナスだと不等号が逆転するのを忘れている
3 > 2 の両辺を-1で割ると -3 < -2 >>626
newの例外の話なんてしてしてません。
本当にレベル低いやっちゃな TYPE *pArr = new TYPE[N];
と同じスコープ内(のdelete pArrの前)で例外が発生した場合に
>>624
>誰がヒープ回収するねん...
という話ですな また話それたのかｗ
ポインタもコンテナも結局都合の悪いレスはスルーしてるからこうなる
こいつC++98で時間止まってるからな
20年かけてSTLコンテナの使い方学んで
その結果がvectorよりlist、それ以上に生ポインタが最強って結論
どうせ40代おっさん低収入だろうけど、自分を天才と呼び、
数学ががどうのこうの言うわり、単なる足し算掛け算をどや顔でさらすし、
本当読んでて可哀想になってくる
要素数固定ってコンパイル時に固定の意味と実行時にある値に決まるって意味があると思うけど
前者では T Arr[N]
後者では std::unique_ptr<T[ ],>
を使ってしまう。
それ自体をreturnしないときは std::array を使うのがかったるく感じてしまう
>>636
arrayはもうひと頑張りしないとだめだな。
宣言時に値を初期化するとき、値の数をテンプレートパラメータに手打ちとか
要素数省略できるCスタイル配列に負けてる >>637
c++17から推論補助が出たので要素数指定不要です。
c++14以前はmake_arrayとか作ればいける でも std::begin std::end があるからスコープ内の単純な配列に std::arrayを使う
メリットがいまいちわからないんだよねー
>>638
おお、ほんまや。
かゆいところに手が届いて行くのぅ template関数で受けたときにポインターにならないからauto lambdaで受けてもsizeがとれる
>>640
だから普通の配列を使ってしまうという話なんだが >>642
その場合にはそうだね
でも関数に渡すとき大抵 begin end だからなあ >>642の言ってるのは配列の参照にキャストされないからだと思うんだけど(自分もそれが不便だと思う)
そのキャストを実装しない理由あるんかね？
中身ただの配列なんやろ？ >>646
なるほどすまん
100人中98人位が誤解する改行だた 構造体をchar配列にシリアライズする方法を教えてください
キャストしてぶっ込め
なお環境とアドレスによってはバスエラーが発生したりするよ
>>645
cとの互換性に起因した過去コードとの互換性保つために、配列を引数で渡そうとするとpointer渡しになるのだろう。
受け側でtemplate使ってT (&arr)[N]みたいに明示的に引き取らない限りは
c++20でstd::spanが使えるようになれば楽になるな。
それでも完全転送は通らないけど 使ってるコンパイラのArrayヘッダの実装見てそのメンバ変数名をしらべてそれを指定すれば通る
reinterpret_castならいけたけど未定義かどうかは知らん
別に無理に通そうとしてるわけじゃないんだぜ
arrayの不備のひとつではないかな、ってだけ
暗黙変換定義すれば出来るんだろうけど、出来ない方が自然な気がする
>>636
以下コードがちゃんと動くの今知った。サンクス。
std::unique_ptr<Test[]> test(new Test[5]); 確かに内部配列の参照を取得する手段はあってもいい気がする
先頭のポインタはdata()で取れるけど、配列型そのものへと読み替える手段って標準の範囲にはないんだな
ちょっと意外
>>659の言う「配列型」が要素数まで含んだ型のことなら無くて当たり前。
要素数を含まないのなら先頭要素へのポインタと同等。
なにを意外に思ったのかわからん。 >>660
いや、わかりにくかったかもしれんけど
配列の参照にキャスト出来れば配列またはarrayから、静的に要素数が取れるのよ
現状だとそういう時array版と配列の参照版の2つを書かなきゃいけない
ので配列の参照のキャスト演算子も定義しててくれたらなぁ・・
と思ったらポインタへのキャストも無いのね
まぁあくまでSTLフレンドリーな配列ってことなんだろう ポインタ使うなと言ったそばからイテレータ使ってたら同じだろ、と誰も言わない優しいスレ
バイナリ肥大を屁とも思わず静的解決マンセーのやつに名前つけたいんだけどなんかないかな？
イテレータ渡してるならdistanceで取ればええやん
バイナリむしろ減ることも多いしな
バイナリ肥大が許せないなら多少の工夫で何とでもなる
バイナリ肥大を気にするならそもそもc++じゃなくてc使えや。
c使っても変わらんだろ
無駄に面倒臭くなるだけで
c++のままバイナリ肥大対策した方が楽だし効果も変わらない
std::vector::resize(size_t n）ならn要素きっかりになるお
および（>>439もご存知のはずの）std::vector::reserve()で10とか20に指定することもできるお
（その通りのメモリ確保が行われるかどうかは最適化に依存し得るが
>>439
そのサンプルコードでは不適切で、最適化が利いている可能性があるお
だってコンパイラが見渡せる範囲で要素のpush_back()をしていないし…
（していたとしても定数回数のループならやっぱ最少サイズになり得る 訂正；
誤：だってコンパイラが見渡せる範囲で要素のpush_back()をしていないし…
正：だってコンパイラが見渡せない範囲で要素のpush_back()をやられる可能性が無いコードやし…
お前らそんなにカツカツのターゲットで仕事してるの？
フリースタンディング環境でトースターの制御マイコンとかそういう世界？
マイコンでRAM1キロとかでもc++つかうよ。
ヒープどころかスタックすら殆んど使えず、ループカウンタすらstatic使うような状況でも、高級マクロとしての性能はc++の方が上
オーバーロード使えるだけでもありがたい
しかしポインタは悪という考えには賛成する
全てのオブジェクトはimmutableであるべきだが現実にはそうではない
（オブジェクト指向プログラミングはmutableなオブジェクトを作る仕事だと一般に理解されている
するとポインタや参照の使用はオブジェクトの参照透明性を失わせる究極の悪となる
バイナリ肥大は余り気にしなくていい
ROM容量はRAMとは桁違いに余裕あるし
速度稼ぐためにテーブル作って持っておくとかでもc++だとやり易いw
ポインタは悪いは草
プログラムの性質そのものだろｗ
良いも悪いもない
>>675
おいおい
今時組み込みでrom実行する環境ほとんどないだろ
だいたい普通肥大化したかどうか比較できん
２つ作ることなんてまずないし
もし容量が足りなくなったら実行コードより他のでかいデータがやり玉になるので目立たない 参照子を長い時間や広い空間で保持する行為が危険なのはどんな言語でも同じ。
>>678
全部値コピー（deep copy）ならそうはなんね
>>67７
ポップアップトースター… ファームウェアのバージョンアップとかなら容量との戦い出てくるんでないの
rom実行する業界ですまん
自分とこの環境はrom容量も限られてるけどロジックでの肥大化よりデータの肥大化の方が圧倒的に大きいからそこまで気にならんけど
すまん全部immutableならと書こうとして手が滑った、
ポップアップトースターのファームウェア（入力はほとんど時間と温度だけ、出力は動作だけ）で
実行コードより他のでかいデータが生じるケースとは
なんじゃらほい
高級アセンブラの役割があること理解してる奴いないな
シンプルなポップアップトースターに電子制御はいらんし
電子制御するような高機能トースターなら音声データくらい入ってるかもしれん
転倒したときに加熱が停止するようにするくらいの制御はいるでしょ
>音声データ
なおROMに置ける固定データはコードに含めるものとする
（>>675も事実上そう言っているのだから後出しではナイ
>>686
それは「出力は動作だけ」に含まれる
転倒したときプログラムがやることは、姿勢判定用センサと温度とタイマーの入力を受けて状態変数を何個か弄りつつヒーターを切るだけなんじゃ…
データの生成というプロセスは無い 転倒時の停止なんかに電子制御はいらん
床面に接触するとオンになり、離れたら回路が切断される、というような単純なスイッチだけで十分
もっとも、状態変数みたいなmutableで邪悪なものを使わずに
全てimmutablueなオブジェクトでスマートに済ませるなら、オブジェクトの生成がデータの生成に該当し、多少RAM容量を消費するが
な、
Rom実行でC++のテンプレートばりばり使ってバイナリ肥大しても問題ない環境ってどんなの？
プロセッサ、OS、メモリのサイズあたりどんなもん？
OSは無し、CPUは数百Mhz、RAMは数十KB
誤解を招いたかもしれんが環境がこういう感じなんでテンプレートばりばりなんて無理なんだ
C++はろくに使いもしない巨大モジュールがプログラムのビルド時にリンクされるから実用性ないわな・・・
>>692
そのレベルの組み込みならわかる
C++全面的に使ったりしないよね
謎なのが
>>673
その環境でどうやってC++使い倒してんの？
例外ありなんだよね？ もちろん例外なし、RTTIなし、標準コンテナなし、仮想関数無し、new mallocも無し
だよ
templateで組み込みのC関数呼び出しに変換する固定小数点クラス作ったり、peripheralの実アドレスにmapしてメンバ関数で制御可能なラッパー作ったりと、メモリやバイナリ肥大しない様に使うのでも、c++機能は色々使い手が多い
いわゆるBetter Cだろ
俺もそう言うのよくやる
>>696
バイナリ肥大気にしないって言った人？
言うこと変わってんじゃんw ？
元々バイナリ肥大全く気にしないとかではないだろ
template使うとバイナリが必ず肥大するってのが大嘘なのよ
うまく使えばCよりユーザー側の負担を減らしたまま、バイナリサイズ減る方向に誘導出来る
ifdefのスイッチを型で分岐して自動指定するようなことが出来るからね
まあRAMが極端に少ない場合は、
大抵バイナリ肥大気にする前にRAMが枯渇してしまう
ROM浪費してまでRAM容量押さえる手段すらとることもあるし。
ループ回さず展開すればループ変数分のスタック消費は押さえられるみたいな奴
>>698
どう変わってるの？
ちょっと説明してみ なおc++を使うことで増えるバイナリ肥大化は考慮しなくて良いものとする。
みたいなクソ意見。
PCなら考慮しなくていいしプアな環境ならスタートアップルーチン削りまでする場合もあるし
環境書かなきゃクソも何もないわ
>>704は、>>675の2行目を認識すべき
例：RX600シリーヅとか、ROMが2GBもあるのにRAMが128KBしかないのがあるし、 よく見たら2 MBやったorz
まあRAMは多いほうが良い
コードもRAMに置いた方が速いしimmutableなプログラミングもしやすいし、、
ramよりromの方がだいたい安価
電源が不安定でも一定の動作の保証がほしい
OS無いんで電源投入時の処理から自前で実装
そもそもそこまで速度重視しない
組み込みだとこういう環境があるんすよ
技術的には枯れた世界かもしれんが
stringからstd::chrono::secondsへ変換するにはどうしたらよいですか？？？？？？？？？？
auto sec=std::chrono::seconds(std::stoi(s));
atoiだとオーバーフローする場合がありませんか？
stoullにしなさい
時間はintで扱っちゃあかん
あの日までもう20年切ってるんだ
いいかい、学生さん、トンカツをな、トンカツをいつでも食えるくらいになりなよ。
>>335の続き。
目的は一応達成できていたものの、偶然に頼りすぎたきらいのある>>333式の解決策の改善を試みたが、
やっぱテンプレートだけでは済まず、関数のオーバーロードも援用しなければ（意図した記述量では）実現できなかった、
・ 関数テンプレートの部分特殊化をやらないと、
tr_pos<Foo, *>()、tr_pos<Bar, *>()、tr_pos<*, Foo>()、tr_pos<*, Foo>() （*=A, B, C, D, ...）
の特殊化を総当りで書く必要があり全然省力化にならない
（A, B, C, ...は1兆個ぐらいあるから、ほとんどコピペとはいえ4兆個のテンプレートの定義を書く必要が出てくる
・ というわけで、クラステンプレートを経由する例のやり方で関数テンプレートの部分特殊化はやった
・ 結局、テンプレートの名前解決規則ではコンパイラが名前を解決できなくなるものとして以下の4ケースが残った。
tr_pos<Foo, Bar>(), tr_pos<Foo, Foo>(), tr_pos<Bar, Foo>, tr_pos<Bar, Bar>()
こいつらは関数のオーバーロードで特殊化でおｋ
・ スフィ姉は未調査
いじょ なおFooやBarにset()やget()のメソッドを追加してA, B, C, ...と共通にtr_pos()できるようにする案はパフォーマンス上の問題で論外なのでもともと却下
（set()やget()の追加は出し入れするデータの型としてintermediateなクラスWの存在を仮定しているが、FooやBarとWとの間の変換は極めて重い処理となる
>>718
Foo->Bar
Bar->Foo
Foo->Foo
Bar->Bar
この四つの操作は共通？ >>719
共通ではありません
Foo->Bar、Bar->Fooは互いに他方の逆関数なので別
Foo->Foo、Bar->Barはそれぞれのコピコンを呼ぶように（今週から）しますた、
なお、先週は変換元インスタンスをx、変換先インスタンスをy、intermediateなクラスWをaとして、
inline void tr_pos(.const (変換元クラス).& x, (変換後クラス)& y) { tr_pos(x, a); tr_pos(a, y); }
とか書いていたので、上記4者は「表記上は」共通操作に見えるコードだったが
今週からはその共通性も無くなり申した、 なんでC++で備えてる通信関係のインターフェースがソケット止まりなの
少なくとも高レイヤのライブラリが標準で提供されることは今のところないな
networking-TSで<net>を検討中だよ
C++20にはまだ入らなそうだけど
string で任意制度の整数とか浮動小数点数を実装した信頼されてるやつない？
コピペで済むようなやつ！
文字列から数値への変換で精度求めるのは設計が間違っているのでは？
COBOLのゾーン十進数みたいなやつ？
ネタとしては面白そうだな
if( auto a = f() ){}
ってのが便利でよく使ってんだが
2変数になった場合はどう書けばよい？
if( auto a = f() && auto b = g() ){}
って書いたらコンパイラに怒られた
fowrad_as_tupleして構造化束縛？カンマで行けるかな
if( auto a = f() && g() ){}
if( auto a = f() & g() ){}
//c++17
bool f() {
return true;
}
bool g() {
return true;
}
int main(void) {
if (auto a = f(); auto b = g() && a) {
std::cout << "True" << std::endl;
}
return 0;
}
おお、しかしそれ
if( auto a = f() )
if( auto b = g() )
{
}
ってぶら下がり文で書いた方がマシ・・・
これでいいか
if (auto [a,b] = std::make_tuple(f(), g()); a && b) {
}
short circuitが使えないのが痛い
結局if2つに分けて書いた方がましと言うことに
簡潔に表記しようとしてかえって素で書くより煩雑になってたら本末転倒だね
operator boolをa&&bの結果でoverrideしたpairを返す関数作って引数に実行対象の関数渡すのはダメか
>>739
そもそも短絡評価使えたら
if(auto a = f() || auto b = g()){
って書くとf()がtrueならbがない状態でブロックに入ることになるし… >>744
もともと質問者があげていた&&のケースについての議論だから短絡評価で問題ないでしょ >>745
どっちかは使えない非対称な仕様なんていややわー >>745
応用力なさすぎ
if( auto a = f() && auto b = g() ){
} else {
// f() が false 返したら b がない状態で来る
// まあ変数は作っておいて不定にしちゃうと言うのもありかもしれないけど…
} てかそこまでして変数宣言をif文に入れる必要なくね？
テンプレート使ってなにかしたいけど、何を作ればいいのか思いつかない
車輪の再開発でおすすめのある？
行列クラスでも作ってみれば？
データ型とサイズをテンプレートパラメータにして
>>743
そうですね
具体的にどういう事がしたい
というのは無いんですけど
リンクに書いた
https://github.com/vpiotr/decimal_for_cpp
これも使用例にはautoループを使ったものが有るんですけど
それを見ていて
そういえばautoループで書いてある物をc++03風?で書くにはどうすればいいんだろうか?
って疑問に思って調べたんんですけど
その時に特にこれといった物が見付らなくて
諦めたんですけど
ここで上に有るcobol風数値の話とautoの話の流れを見ていて
急に思い出して
何か知っている人がいそうだなと思って
何となく質問してみた次第
具体例をあえて言えば
このcobol風の物の使用例のautoループを何と言うか普通に戻すには
どういう風に考えていけば良いのだろうか?
その考え方や手順が解ればいいなと
そんな疑問を持って書かせて貰った次第です
かなり漠然とした疑問
という程度です range-based forの事を指していると思われる。
for(auto&& v: vec){
//vについての処理
}
>>753
文字列やら数値やら与えて文字列にする関数を作った。
f("1+1=",1+1,string("ですよねー"))
みたいなの。
可変引数テンプレートやらtype traitsやら機能いろいろ使うことになるからいい練習になる。 完璧なprintfクローンをテンプレートで作る
俺は挫折した
>>762
途中で書き込んでしまったすまない
gcc g++ 9.1だと
for_each_n(InputIterator first, Size n,Function f)が定義されてなくて
for_each_n(ExecutionPolicy&& exec, InputIterator first, Size n,Function f)のみ定義されてるんだけど おめえの汚ねえテンプレート実装なんてオラ使いたくねぇ
std::string to_string(const std::string_view& In) {
return In.data();
}
こういう関数ほしいほしいほしい。ばいきんまん。とってきて
テンプレートのエラーってめちゃくちゃでわけわからんです
あれで嫌いになるC++初心者多いのでは？
AIみたいなのが優しく教えてくれればいいのに
>>768
コンセプトが入ったら、いろいろ解決するとは言われている。
VCの場合は、一番上のヤツを察して修正していくといつか終わる。
途中のエラーを察するより楽。 主要3コンパイラともとりあえず1番上のエラー付近を調べればいいから分からんということもない
稀に本当に無関係なエラー出てることもあるけど
エラーの読み方を知っちゃえば面倒くさいだけでどうということもない
ただ、これと間違えたんじゃないの、っての候補表示がかえって混乱をさそってる感はある
C++ は perl にまけずおとらず読みにくい
というのは誤解でしょうか？
ありがとうございました
早さが必要なのに、C できつくなったら
ストラウストラップ本
というのを買ってスタートしてみようかなと思ってました
初めるときは、少しでも読めるように気合いれておきます
自分で定義したコピーコンストラクタからデフォルトのコピーコンストラクタを呼ぶ方法はありませんか？
C(const C& c){
//デフォルトのコピーコンストラクタを使って静的にメンバをコピーしたい
//その後にポインタの参照先を修正したい
}
データメンバー分離すればいいんじゃない
class C
{
struct Data { /*...*/ } data;
C(const C& c)
: data(c.data) // C::Dataのデフォルトコピコン
{
// やりたい処理
}
};
>>778
自分で定義した時点でコピーコンストラクタはそれしか存在しないから無理
>>779みたいな方法なり全部自分でコピー書くなりするしかない ムーブコンストラクタとコピーコンストラクタ両方作って保守するのも
完全転送とsfinae用意するのもどちらも面倒臭いんですがc++erの皆様はどのように対象しているのでしょうか
基本的に全部unique_ptrとdefaultのムーブコピーに任せてる
大抵はそれで困らないし困ったらその時考える
>>779-780
ありがとうございます
とりあえずデータメンバを構造体にまとめることでなんとかなりそうです 暗黙のコンストラクタに任せるとか一番の事故パターンじゃん
最近のC++（少なくとも11以降？）ならば、マクロの使用は悪と決めつけてOKなもんですか？
それとも未だにマクロの役立つシーンはあったりするんですか？
普通に使ってる
ただ代替がある機能についてはわざわざ使わない
>>786
バカが書いたテンプレートよりもlinuxにあるマクロを使った方がマシ。
てか可読性落としてまで型安全とかにこだわる必要なし。 >>786
互換性のない複数プラットフォームに対応しようとするとき
ヘッダーファイルをincludeするかどうかを切り替えたいとき
ヘッダーファイルをincludeしたかどうかでプログラムの動作を切り替えたいとき
なんかは素直にマクロ使った方がいいと思う。
moduleが導入されれば、この辺の組み方も大幅に変わってくるかもしれないけど。 コピコンを定義を求められるときは大概代入演算子も定義するから
コピコンの中身を代入演算子の方に移して
コピコンは代入演算子を呼べば良い
真の原因がバカにあるのだとすれば、可読性向上を唱えても空しい
>>791
#ifdef とかの話？
それをマクロと言うかどうかは微妙な気がするけど #include しゃあない
#pragma しゃあない
#line まあしゃあない
#if系 ある程度しゃあないけどテンプレートやconstexprへの置き換え考えようね
__VA_ARGS__ 可変長引数テンプレート使えと言いたいところだけど場合によるのかな
#error static_assert使え
定数#define const変数使え
関数#define ##や__VA_ARGS__使うためならしゃあない。そうでないなら死ね
マクロって#defineだけだろ？
あと
> 定数#define const変数使え
constexpr auto 使え
includeもC++20で死ねって言われるようになるの？
>>786
○○は悪、とかドヤ顔で言ったり書いたりしてるやつは例外なくアホだと思っていい マクロの定数(リテラルの定数)とconst/constexprって等価じゃないよね？
実用上はさておき
定数は大体constじゃね？
ほかのアトリビュートかなんか推論できるか？
>>799
constexpr定数はマクロと同様にコンパイル時に置換されるから等価で、名前空間が使える分上位互換でしょ constも定数としてだけ利用するなら多くの場合rom領域に置かれるはずなんだけど
constexprはコンパイル時置換が確定してるのとtemplateやconstexpr ifの恩恵受けられるのが大きいってイメージ
lvalue-ravalue変換考慮に入れれば#defineの置換とほぼ同じになると思う
#define a 0
constexpr auto b = 0;
auto x = &a; //error
auto y = &b; //ok
等価ではないよね
だからdefine定数は必要と言いたいわけではないよ、念のため
>>801
#ifdefのように定義されているかどうか調べられないのが唯一の欠点かな。 foo[1].bar->baz.some_method()というのが1万箇所あってこれを
stdObj.some_method()と書きたい場合
#defineマクロなら
#define stdObj (foo[1].bar->baz)
で済むがconst系のやり方だとfoo[1].bar->bazのアドレスを取らねばならず、
コンパイル時の解決が不可能なケースが生ず、
んまーfoo[1].bar->bazをテンプレート引数に渡せば近代的な書き方もできるんだと思うが
あとVisual Studio 2010のC++限定の話かもしれんが
const struct Hoge someBigArray[50000] = { ... };
// 重複有り、規則性無しのsomeBigArray[]要素アドレスの引用
const foo_t* pA010001 = &(someBigArray[0].m_foo);
const foo_t* pA010002 = &(someBigArray[0].m_foo);
const foo_t* pA010003 = &(someBigArray[0].m_foo);
const foo_t* pA010004 = &(someBigArray[3].m_foo);
const foo_t* pA010005 = &(someBigArray[3].m_foo);
... (1万個ぐらい略) ...
const foo_t* pB019999 = &(someBigArray[9999].m_foo);
const foo_t foo_ptr_list[] = { pA010001, pa010002, ..., pB019999 };
というのをやったらDebugビルドだと20秒ぐらいでコンパイル&リンクが終わるのに
Releaseビルドだとリンクに10分もかかりやがるの;;;
しかし慌てず騒がずpA010001〜pB019999を全部#defineマクロにしたら20秒で終わるようになったわ、
ﾌﾟﾁ訂正
誤：const foo_t* pA010001 =
正：const foo_t* const pA010001 =
（pA010001 以外も同様
単に置換するのと文字列リテラルにして置換するのを両方できるのはマクロだけ
>constexprはコンパイル時置換が確定してるのとtemplateやconstexpr ifの恩恵受けられるのが大きいってイメージ
こういうことやるやつのコードは総じてクソまみれになるって事を考慮しないと。
>>812
少なくともこういうバカ返信する奴のテンプレコードはクソ。100%クソ。 >>813
何を思い込んでいるかは知らないけれど
俺はテンプレコードなんて殆ど書かないので問題ないですね こういう奴の生ポインタをガチャガチャ引っ掻き回すコードはクソ。100%脆弱性入り。
ポインタや参照を使う奴がクソ
一般のプログラマ─はimmutableなオブジェクトしか扱わないべき
たまにマジでテンプレート否定する奴がいるけどどういうコード書いてるんだろうとは思う
ならもうC言語でいいやんと
>>82
最近関数型言語かぶれ増えたよな
一時期のOO厨と同じ
というか実行効率重視しないのにC++使ってるまぬけでしかない Template なかったら事前にタイプ規定する言語使うの最早ただの苦行やん...
増えたといっても全部漏れの自演だがな
やっぱ最適化とかmutableなオブジェクトの使用みたいな危険行為は
プロファイルをとった上で
ポイントを絞ってやるべき伝家の砲塔だと思うんですよねー
>>829
それテストドリブン原理主義と同じだよ
現実のC++のプロジェクトでワークしない
実際のとこお前だってそのポリシーでやりきったことないだろ
あるいはそもそも性能要件なんかないただの趣味プログラミングだろ ていうか真に速度が求められる箇所ではオブジェクトの生成とかせずに
テーブルで済ますように極力するから極限までの高速化を求められるシチュエーションでは
immutable縛りはあんまパフォーマンスの制約要因にならないｷﾓｽ
で実行速度が求められるあまりmutableな書き方しかできない最たるもの（と一般に考えられている
再起が関係するアルゴリズムとかでも再起の深さが有限なら原理上FSMで表せるし
そうしたときに問題になるテーブルサイズも問題によっては問題固有の特質に着目して削減ができるので
深さとcurrent stateの2つぐらいのmutable要素だけでやれる
ｽｹﾞｰ手間がかかるのであんま一般的ではないが
なんかコンテストとか競技系の小規模な問題しかやったことない人間の匂いがする
画像処理用の画像クラスでimmutableとか最悪だろ。
宣言的プログラミング！
(実装詳細はライブラリにやってもらう)
今時の性能ならフル描画しなおしでも結構なんとかなるぞ
画像の書き換えまたはフィルタリングを
In-placeで処理したからといってなんか高速化になりましたっけ…
In-placeの方がキャッシュの有効活用にはなるかもしれんが
In-placeの方がキャッシュの有効活用にはなるかもしれんが、
画像う処理とかデータサイズ＞2時キャッシュサイズなので
もともとキャッシュのrefill上等な前提な印象、
つまりはIn-placeにしたからといって誤差の範囲内
ネーミングセンス糞すぎて俺のgithubアカウントに○○○Manegerとか○○○Analyzerみたいな名前のリポジトリが並んでるんだけどどうすればいい？
analyserとかちょー卑猥な響きだよね(´・ω・｀)
>>840
ネーミングセンス云々の前に英語をちゃんと勉強するべきだな 初心者前提なのだから1ピクセルずつ操作することを考慮しろ
英語力という点では「登録する」（動詞）を「regist」だと思い込んでいるケースが
メジャーなライブラリでも散見さるる、
あれ本当に恥ずかしいからやめて欲しい
恥ずかしいと思ってない日本人が多すぎるという事実自体が恥ずかしい
それはconfigureをconfigって略すのと同じだろ
>>841
誤字だと分かりきっているものを茶化さないでおくれ 本当に省略形なら"registed"だの"registing"だの"registation"だのはどう説明付けてくれるんだろうね
>>853
registerは名詞でもあるだろ
ただ意味が限定される（帳簿とかこの業界だとCPUのレジスタとかになる）ので登録という意味ならregistrationの方がいい warningとかもなるべく正しい(近い)発音を心がけてるんだけど
nullだけはヌルだわ
2chリスペクトだと思ってるw
>>849
resist と書かれちゃうよりはましだとおもいますぅ >>859
ドイツ語ではヌルでいいんですよ、ドイツ語と言い張ればいいのではないでしょーか なるほど
ヌルポはヌルポッセンドルフの略と思っておきます
nullはむしろ英語読みが間違っている
外来語導入して読み方変えているのを間違いと言うなら
大規模開発やったことないんだけど、C++の仕事ってやらせてください
正直、メモリ管理もできないような言語の仕事なんか限定されすぎだろうよ。
ゲーム業界くらい？
俺は一応社内システムの仕事でやってるけど、 c++の機能フルで使えないからストレスだわ
c言語のソースそのままコピーしたであろう共通関数あったり、既存ソースはポインタ生で使ってたり、 コンパイラーがc++03だったり、boost使えなかったり、微妙
規模次第だけど社内システムなんて結構好き勝手できるから気に入らない部分はどんどん新技術に載せ替えて行けば？
プロジェクトのひな形を生成したときにまずすることはboostのパスを入力すること
vcpkg install boost:windows-x64
>>869
しがないフリーランスだからその権限がないっす。
親方が気に入らなければ変えられません使えません。
俺「これーcharじゃなくてstd ::stringにした方がシンプルじゃないっすかねー・・・」
敵「既存がそうなってるからchar使ってね」
俺「はい」 >>875
ちゃんと相手にわかるメリットを示せよ。実装にかかる時間とか安全性とか信頼性とか、あるだろ。
無いなら既存に合わせるのが正解だろうよ。 >>876
既存のやり方がそうであるのに、流石にそれは許されないでしょ 「正しい」形にすることは何よりも優先されることなんだが
>>875
そういう案件ならしゃーないんじゃない？
上が細かな技術的なとこまで意思決定権持っちゃってる残念な現場なんて腐るほどあるんだし
説得して環境を変えるのもありだけどフリーで入ってるなら頑張ったところで将来的に得するかは微妙だろうね 何が正しいかはケースバイケース
保守する社員がcharしか理解できないボンクラと言うことも考えられる
>>878
関係者がみな納得できる共通の｢正しい｣があるならそれでいいと思うよ >>879
まさにそうなんだよねぇ。
「\0飛んだだけで暴走するcharなんか捨ててしまえ」って熱弁して血反吐吐いて納得させても将来得するの俺じゃねぇし・・・って言う >>882
説得先も大概だけどそんな理由で入れ替え勧めたってウンとは言わないでしょ… char*とstd::stringを比較するんじゃなくて、スタックとヒープの違いで安全性・安定性をアピールしたほうが良かったんじゃないかな。
別にインターフェイス部分だけcharで内部ではstring使えばいい話だろ？
まあ多分インターフェイスなんて概念自体なさそうな現場には見えるが。
>>875
メリット説得して、さらにstringに馴染みがないやつへの説明
さらにその変更によって万一(どころではないと思うが)生じた不具合に対する責任を負う覚悟があり
それら全部タダ働きでいい、というのならOKしてくれるかもな >>880
数年後に保守する奴が新人ってケースは普通にあるからねえ てかこのレベルでグダグダならc++なんて一番使っちゃいけないものなんだけどね。
>>886
でもさ、どのメモリに入ってるかも分かんない文字列ポインタなんか、使いたくねーってならないか？ >>889
C++使っちゃいけないとか、C++使ってるやつは自意識過剰のクズばっかだな
Linusも言ってたし むしろchar使ってる箇所stringでラップして新人さんにもメンテしやすくするべき
クソなところならどうせそこ直しても所詮うんこの一角だしクソなだけ
いいところなのになんだかなー思うんなら訴えかけて良くしてやればいい
クソなところなんてどうせ金も払わんし出来る限り関わりを持たずにずらかるのが一番(´・ω・｀)
C++で個人開発したいんだけど、やりたいものが思いつかない
個人的にはC++らしいものをやりたい
→openGL
やってはみたけど、webのレイマーチングにはまる
→レイトレーシング
今もやってる趣味ではある
→競プロ
人生で一番費やしてるプログラミングの趣味
test1 = 0x0123¥ntest2 = 0x0111¥n......
みたいなstring文字列から、指定のtest番号の0x0123みたいな6文字を取り出す関数を作りたい
引数をstring型文字列、戻り値を16進数のstring文字列みたいな
test1 と = の間のスペースの数が1つなのか複数なのかがランダムだから、それを考慮してうまく抜き出す方法ないかな？
（test1って名称が本当は別の文字列だから、見映えよくするためにスペースで調整されている）
regexを使った正規表現しかないかな？？
今は指定の文字列をfind検索して、指定の文字列＋1の位置から、全部文字列切り取って、スペース= 0x0111¥n.....みたいな文字列を一度作ってからさらにfindでやってるのだけども
>>891
通常の開発は一人でやるもんじゃないんだよ。
自分はできるからですませてるうちはプロジェクトではゴミだから。 C++標準が3年ごとにリリースされるのはなぜ？ 2019/07/16 18:06 後藤大地
https://news.mynavi.jp/article/20190716-860461/
2012年以降、C++標準化委員会は3年ごとに新たなC++標準（C++14、C++17）をリリースして
いる。次のC++標準はC++20として作業が進められており、タイムスケジュールどおりの
リリースが予定されている。C++98とC++11のリリースにはそれぞれ9年ほどの時間が
かかったことを考えると、この7年間ですでに2つのC++標準が3年ごとにリリースされたのは
大きな変化だ。
ISO C++標準化委員会の議長でありMicrosoftでソフトウェアアーキテクトを務めるHerb
Sutter氏が2019年7月13日(米国時間)「Draft FAQ: Why does the C++ standard ship
every three years? - Sutter's Mill」においてその理由を説明した。(中略)
標準化委員会はC++11をリリースした後にこのモデルを見直し、タイムスケジュールベース
でリリースするモデルへ変更。Sutter氏は、機能ベースで進めるやり方とタイムスケジュー
ルベースで進めるやり方を比較しつつ、結果的には、タイムスケジュールベースのほうが
業界全体でよい効果を持つことがわかったと説明している。同氏は「機能ベースのリリース
モデルには戻りたくない」と明言しており、現在のモデルの方がうまく機能していることを
主張している。(後略) 文字列の切った貼ったはセキュリティ的に怖いからね
有り物で書けるならその方がいい
std::getlineで\n区切りで回してから
後は知らん
splitあれば改行で区切ってlist化するだけなんだけどな
Qt環境ならそうする
=で分割した後
左右でfind_first_not_of,find_last_not_ofで空白以外まで切り詰めかな
Cですが。自力分割やregexよりは早い気がする
const char* s = "abc= 123";
sscanf(s, "%[^=]=%d", key, &value);
昔はドヤ顔でトリッキーコード書く奴いたが最近は見ない
理由は、
できる新入社員が入ってこない
年寄りは昔ドヤ顔で書いた自分のコードを十年ぶりくらいに保守して反省するから
真のトリッキーコードだったら地獄はむしろ最初も最初、
離陸前に訪れているはず
もうそんな悲劇は繰り返させないRustによって、
ていうか今日日スマホ系だとIDEに命ぜられるがままイベントハンドラを設けて、
インテリセンスに従って高水準APIを呼べばだいたいのところできてしまうるし…
バッドノウハウとか差別化のためのトリックがむしろ脚光
個人開発したいとやったら、やるなと言う職業プログラマー
そんなにC++の弁護士気取りたいのか？
>>918
一言で言えば、C++らしいものを作りたい
なんかおすすめ教えてです プログラミング言語は道具だからな
鉄筋コンクリートらしい建物作りたいから教えてと聞いてるようなもの
自信のソースコードを文字列定数としてコンパイル時に埋め込む方法ってありますか？
ファイル読み込みとかしないで、自身のソースコードを表示するプログラムなら作れるが
>>896
Haskellで丁度ピッタリの処理を自作した(組み込み関数が既にある)のでアルゴリズム自体は参考になるかも？
import Data.Char
main = (print.mywords) "hello world\t\t hahaha\n\n hohoho\n"
mywords [] = []
mywords xs = a:mywords (dropWhile isSpace b)
where (a,b) = break isSpace xs
生の配列じゃ無くてvector,list辺り使えば難しく無いはず。
文字列から、スペース削除した文字列のリストを作る。
“Hello world” -> [“Hello”,”world”]
a = スペース文字が出る直前までの文字列（上で言うところの”Hello”)
b = 残った部分(必ずスペース文字始まり。上で言うところの” world”)
dropWhile isSpace b = Haskellだと空リストにtail(リストの先頭を削除)だとエラーになるのでdropWhile使ってるが、単純に先頭を削除してループ。 なぜC++にsplitが無いのかに行き当たり議論は再燃し一晩で鎮火する
嘘教えてた。。。
dropWhileは先頭削除じゃなくて、先頭も含め、普通の文字が出るまで空白文字を(続く限り)削除。
その後またa,bに分解する処理に戻る。
文字列終端に来たら、削除処理やめてループ抜ければ良い。
真面目に考えると
空白の定義は何か？
に始まり、様々な議論の末に
localeとかcodecvtとか糞が出来上がり
もうUTF8でええか
ってなる
codecvt使おうとしてdeprecated に気づいてイラッとしたが、使い込んでからでなくて良かったとも言える
>>920
競技プログラミング一生やるわ！
C++は糞！
こんな言語二度と使わねえ
競技プログラミングの時は使うけど c++らしさがあるとするならば使う外部ライブラリや成果物にではなく設計に出るもんだし
C++ではあなたが書いたプログラムで競技するが、
Rustではあなたが書く速度が競技される…！
std::unique_ptrを使い倒すなどして所有権について完璧に理解したら
Rustのコンパイルが通る確率が増すから
C++はきちんと勉強しといた方が良い
rustはジェネリクスが弱いのでまだまだC++の方が優位。
Rustは所有権に関する厳格なルールの強制という土台の上に、
ありえないぐらい強力な型推論と並列実行の安全性を実現しているから
トータルで見たらわからん
ていうかセルフホスティングはもちろんGUI付きのOSまで記述し切った数少ないシステム記述言語
>>935
一ヶ月でC++理解できるならするけど
個人開発すら許されない string型をunsigned short型へ
unsigned long型をunsigned short型へ
この二つの変換ってどうすれば良いのでしょうか
上はstd::stoiしてからint->unsigned short変換
下は普通のキャストの何が不満なのか言ってくれないと答えようがない
俺は遊びにc++なんか使わないな
仕事で嫌々触るだけ（ヽ´ω｀）
昔はトリッキーな事をしないと
まともな動作速度にならないことが有ったからなんじゃないか
今は小手先的な方法は余り必要ないから
明らかに遅くなる様な方法を避けるだけで済む
LDIRのsrcとdstを1バイトずらしてV-RAMを高速0クリア、
しかしさらに速いPUSH BCループとか、
>>938
プログラミング言語Cなら一日かけて通読したら次の日からばりばりCが書けるようになるから
3日目からはプログラミング言語C++を2週間かけて通読したら良い >>948
うるせえカス！
個人開発も出来ない言語を誰が触るか
>>941
うるせえカス！
俺は五年前からやってるわ 「俺ごときではC++を使ったら」個人開発も出来ないって意味じゃない？
>>950
個人開発してるけど次何作ったらいい？みたいなことを質問をして変な回答をもらってた奴がいた気がする。バカにされて拗らしただけだろう。
開発したければこんなところで聞いてないで好きに作りゃいいのに。 >>950
イライラすんだよ
C++って意味だよ俺は一生C++許さねえ なんか別言語のバックエンドとして個人開発で現実的に使えるじゃんねC++
>>953
こないだのコンテナ否定野郎といい
匿名掲示板なんだからシレっと消えたらいいのに
しつこく今日のバカは自分だと名乗りを上げるやつ多いな。
ここやばくない？ C++はキチガイを惹き付ける謎の魅力？があるからな
わからないからとっとと他の言語やってろと
>>956
うるせえんだよ
馬鹿なのはお前なんじゃねえの？
しつこく自分をバカと名乗る？鏡見てから物言え
>>958
糞が
C++完全に理解した（）勢ですか？ >>958
うるせぇんだよ無能
お前みたいなのがいるせいでC++が誤解されんだよJavaでもやってろ糞が >>960
しねよ！
お前みたいな奴が居てこそ、C++の偏見が出来上がったんだぞ
ジャバなんてやりたくありませんね!一生！ 俺もjava好きになれんは便利な奴とは思うが何か気が合わないpythongはくそだけど未だそっちの方がいいと思うくらい(´・ω・｀)
今のJavaはどこを目指してるのかさっぱりわからない
この前びっくりしたJavaの記法
class Foo {
void someMethod1() { Log.e("Hello"); }
String someMethod2() { return ("World!"); }
};
Foo foo = new Foo() {
void someMethod1() { Log.e("This is"); }
String someMethod2() { return "a pen."; }
};
これはC#でももっと穏当な書き方を要求されるぞ
Goとか意識しすぎなんじゃ…
>>966のはまだclassという括りが生きているが、
GoやRustはclassという括りを解体に向かっていって、
いかにも戦訓の積み重ねを経た近代言語という感じがする Javaよく知らんけどnewしたときにメソッド書き換えてるのか？
>>963
PowerShellも便利なんだけど配列周りとか癖があるからちょっとハマりやすい
switch文に配列渡したら自動的に要素毎のループになるとかいるか？ JavaはOOを前面に打ち出したのが失敗だったんじゃないだろか。
>>971
むしろ c++に欲しいわw
結構powershellのオプジェクト的に処理できる配列ループ関係は理想なんだよな 最近触ってないけどJavaの例外指定って今どうなってるの
C++は扱いきれずにぶん投げてnoexceptに移行したけど
Javaのチェック例外はラムダ式と相性が悪すぎて崩壊したよ
もうほとんど使われてない
>>960 >>962
まさかとは思うがC++のオブジェクト指向は汚い、とかJavaの方が理想的、とか
そういう偏見の話じゃないよな？ 中身のないやり取りなので気にする必要は一ミリもないぞ
Javaでチェック例外を使わないという選択肢などないと思うが。
あるとすればJavaのラムダを使わないかJava自体を使わないか。
>>978
>Javaでチェック例外を使わないという選択肢
Javaは1日触っただけなのでようわからんがthrows Exceptionで事実上可能なのでは… 「なぜ登るか？」
「そこに山があるからだ。」
「なるほど、じゃあおもくそ山高くしたろ」
なんかこんな感じだよなc++って。
設計の問題。
在る機能全部使おうとすると破綻する。
無意味に難解なのはSFINAE回りくらいじゃね
それもコンセプトで解消される
後はあると便利なものがキチンとあるだけだろ
せっかくchrono作ったのにカレンダ無いとか… 追加されるけど
アプリレイヤーとしては欲しいものいっぱいあるぞ
>>982
それは語弊ありまくりだろ
SFINAEはあくまで俗称で、そういうテンプレート候補の解決は
あるテンプレートが要件を満たすかどうかを調べるために作られたものじゃない
あくまでトリックだぞ >>984
まあSFINAEは言語仕様上で想定していた使われ方ではないのは知っているけど
当たり前の様に使われているから、黒魔術呼ばわりされる最大の原因であるのも確かだろ >>983
> アプリレイヤーとしては欲しいものいっぱいあるぞ
それを言語仕様に求めるなよ… >>986
いや、無いとc由来の危険なlocaltime使ったり、独自実装してxx年問題的なバグ仕込むからあった方がいい
chrono自体の過剰な機能充実っぷりと比較すると特にね >>987
> いや、無いとc由来の危険なlocaltime使ったり、独自実装してxx年問題的なバグ仕込むからあった方がいい
お前みたいな低能に合わせる必要はないだろw 実際必要だと判断されたから、20で追加されるんだが
cの標準でも用意されていた機能なんだぜ
しかもそれ使うと危険という
最初のchronoは時間表現というより時間計測が主だったんだろうなあ
カレンダーが欲しくなるのは当然の流れだが
>>976
いや、僕はC++が大好きなのに、職種C++プログラマーに馬鹿にされて頭に来た
Javaなんてどうでもいいカス >>988みたいな驕り高ぶった初心者が増えたのは問題だと思うわ
>>992
そうかすまん、いつまでも過去にこだわってJavaの悪口言うのもどうかと思って
ちなみに「フリーソフトでも作ったらどうよ」と言おうと思ったがそういうのは自分で考えて自分で決めるべきだと思ってやめた(でないと絶対続かないと思ったので)
ちな職業プログラマです >>991
うん、俺も違うと思うよ
要するに>>982までは言語の話ししてたのにいきなりカレンダーとか言い出す>>983が出てきてレベルがだだ下がったってことなw おっレベル高い話か？
ADLの悪口とか言えばいいのか？
>>996
さあどうだろうね
俺は違うと思っているが異論は認める >>993
> >>988みたいな驕り高ぶった初心者が増えたのは問題だと思うわ
勝手に問題と思ってなよw
中身のない批判しかできない自称職業プログラマなんてどうでもいいし -curl
lud20200109212039ca
このスレへの固定リンク： http://5chb.net/r/tech/1560574313/ヒント：5chスレのurlに
http://xxxx.5ch
b.net/xxxx のように
bを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「C++相談室 part143 YouTube動画>1本 」を見た人も見ています：
・C++相談室 part126
・C++相談室 part124
・C++相談室 part153
・C++相談室 part154
・C++相談室 part150
・C++相談室 part152
・C++相談室 part149
・C++相談室 part155
・C++相談室 part148
・C++相談室 part151
・C++相談室 part159
・C++相談室 part163
・C++相談室 part160
・C++相談室 part157
・C++相談室 part161
・C++相談室 part147
・C++相談室 part137
・C++相談室 part134
・C++相談室 part135
・C++相談室 part138
・C++相談室 part142
・C++相談室 part117
・C++相談室 part137
・C++相談室 part141
・C++相談室 part132
・C++相談室 part144
・C++相談室 part146
・C++相談室 part140
・C++相談室 part130
・C++相談室 part145
・C++相談室 part139
・C++相談室 part133
・C++相談室 part136
・C++相談室 part131
・C++Builder相談室 Part21
・0からの、超初心者C++相談室
・Cygwin + MinGW + GCC 相談室 Part 8
・Cygwin + MinGW + GCC 相談室 Part 3
・C♯相談室 Part20
・C言語相談室(上級者専用）
・MFC相談室 mfc22d.dll
・Mac G5 中古買入相談室
・MFC相談室 mfc23d.dll
・自営業 悩みごと相談室 40
・C#, C♯, C＃相談室 Part79
・C#, C♯, C＃相談室 Part75
・C#, C♯, C＃相談室 Part90
・C#, C♯, C＃相談室 Part91
・C#, C♯, C＃相談室 Part93
・C#, C♯, C＃相談室 Part94
・0からの、超初心者C#相談室
・自営業 悩みごと相談室 46
・自営業 悩みごと相談室 47
・C#, C♯, C＃相談室 Part96
・C#, C♯, C＃相談室 Part91
・C#, C♯, C＃相談室 Part97
・C#, C♯, C＃相談室 Part94
・自営業 悩みごと相談室 48
18:39:11 up 18 days, 5:03, 1 user, load average: 8.92, 9.21, 8.93
in 0.026950120925903 sec
@0.026950120925903@0b7 on 123008
|
