21/03/12 20:55:45.62 ZDqlVx3B.net
すみません。C/C++自体というよりは、その学習方法についてですけど、教えて下さい。
ネット上で無料で公開されているC++の学習コンテンツで一番良いもしくは定番のものはどれでしょうか？
私はC, Java, C#の経験があります。しかしながら、Cはほとんど忘れてしまいました。
その状態の人間がC++をネット上の無料のコンテンツのみで学習したいのですが、どのページが良いでしょうか?
開発環境は既に準備しました。
よろしくお願いいたします。
593:デフォルトの名無しさん
21/03/13 11:40:09.75 g/wAdnDh.net
とりあえずwebのロベールとかでも良いとは思うけど・・
独習とかの本は何か持っといた方がいいと思う
594:はちみつ餃子
21/03/13 14:13:55.98 aUdFS8U8.net
ウェブのロベール本ってこれのこと？
URLﾘﾝｸ(www7b.biglobe.ne.jp)
いまどき #include <iostream.h> とか書いてあるのはちょっと微妙だと思うぞ。
どの箇所だったか忘れたけど const の扱いで現行の仕様に合わない部分について
Taratail だったか Qiita だったかで見た記憶もあるし。
個別に見ればささいなことだけど、
入門者はそのささいなこともわかってないから入門者なわけで、
細かい引っ掛かりが多いとしんどいんじゃないか？
595:
21/03/13 14:52:13.00 o3uThhpf.net
>>575
本を買った方がいいでしょう、それも複数買う前提で、この世界では「一冊で完結」は無理です
最初の一冊なら私なら旧独習をお勧めします（私がそうでしたから）、が、新独習の評判は聞いてみたいとは思っています
596:デフォルトの名無しさん
21/03/13 15:28:12.06 iXgnaDGC.net
>>577
お前がゴリ押ししてる江添本よりはマシだと思うよ
597:はちみつ餃子
21/03/13 15:50:23.66 aUdFS8U8.net
>>579
俺は江添本を (全体を通しては) 読んだことがないのでごり押しするほど強い関心無いんだけど。
ただ C++ は C++11 が大きなターニングポイントになってるので、それより古い前提の説明は論外という立場。
ましてや C++03 にすら合致しないのは論外も論外。
論外のものを除いて入門向けにマシそうな、
しかも無料で読めるものというと江添本以外に実質的に選択肢がないからよく挙げるだけだよ。
598:デフォルトの名無しさん
21/03/13 16:12:25.33 g/wAdnDh.net
QZも言ってるが独習の新版はC++17らしいぞ
599:はちみつ餃子
21/03/13 16:33:14.60 aUdFS8U8.net
>>575
話題に上がったから紹介しておくけど、江添本ってのはこれのことね。
URLﾘﾝｸ(ezoeryou.github.io)
入門書であまり取り上げられないけど入門者が躓きがちなコンパイラのコマンドの話や makefile とかいった周辺事情も
取り上げているかわりに、ヘッダファイルを使い分けしなかったり、継承を扱わなかったりで、
網羅的に C++ を理解するための本ではない。 入門者が入門するための本。
それ以上のことは他の本を読めという投げっぱなしだが、
とりあえず無料で基礎をおさえられる (しかも日本語！) という意味では他に紹介できるほどのものはない。
C++ ではありがたいことに無料で利用できるリファレンスは意欲的に整備している方々がいて、
URLﾘﾝｸ(ja.cppreference.com)
URLﾘﾝｸ(cpprefjp.github.io)
あたりを見れば細かいことも書いてるんだけど……。
まあ当たり前だが入門書をひとつも読んでないレベルだとみてもわけわからんと思う。
本気で取り組むなら本の数冊くらいは買ったほうがいいと私も思う。
600:デフォルトの名無しさん
21/03/13 16:48:52.40 g/wAdnDh.net
そら今時コマンドラインツール使っててソース1つだけで書いてるようなC++オタクには合ってるかもしれんけどな・・
601:はちみつ餃子
21/03/13 17:11:08.84 aUdFS8U8.net
他に存在するなら紹介するんだけど、
無料でという制約の中で (個別のブログ記事とかじゃなく) それなりに筋道をつけた入門書で古すぎないものとなると無いだろ。
英語でいいならあったりするかな？
602:デフォルトの名無しさん
21/03/13 17:54:16.06 pYfy5bp8.net
>>581
自分は半月ほど前に最新版の独習を買って、半分ぐらい(p370あたり)読み進めているんだが、「本書について」によると、C++14とC++17をメインのターゲットにしてるって書いてますね
603:デフォルトの名無しさん
21/03/14 08:22:46.92 Zb/GuQ+J.net
アドバイスありがとうございます。
とりあえず、教えていただいたロベールさんのページを見たのですが、網羅的に書かれているようなのでまずはこれを読もうと思います。
> いまどき #include <iostream.h> とか書いてあるのはちょっと微妙だと思うぞ。
すみません。これ、何が悪いのでしょうか。。。
あと、教えていただいて気がついたのですが、C++も結構色々なバージョンがあるのですね。
私が今回触らなければならないコードはかなり前のコードなので、もしかすると古いバージョンのC++かもしれません。
その辺も意識して勉強しなくては駄目ですね。
604:デフォルトの名無しさん
21/03/14 10:23:48.46 FJEdpMO0.net
今はもう標準ライブラリに.hがついてるのは無いからそもそも実行できない可能性ある
605:デフォルトの名無しさん
21/03/14 10:49:48.45 8Ki8FhWw.net
実行？
606:
21/03/14 14:53:49.63 uaeFGveg.net
>>585
旧独習には「std::stringを自分で実装せよ」という初級者には眩暈がするほどの崇高な課題が採用されていましたが、新独習には「～を独力で実装せよ」系のお題は採用されていますか？
すくなくとも「～を独力で実装する」系お題が可能になるだけの基礎知識をつけてくれる本ですか？
607:デフォルトの名無しさん
21/03/14 17:03:20.15 ERa14GlL.net
>>589
全13章605ページのうち7章380ページまで進んでいますが、そのようなお題にはお目にかかっておりませんな。
練習問題やその章の理解度チェックで色々な問題が出されていますが、何れも本をよく読めば解ける問題ばかりです。
さらっと先まで目を通してみましたが、そのような課題は見当たらないようです。
旧版のどの箇所あたりで出題されたものですか？ もしかして、全く別の本のことなのでしょうかねえ。
↓の「おまけ」にあるような解答を求める問題でしょうか？
std::stringの実装に学ぶC++入門 - Qiita
URLﾘﾝｸ(qiita.com)
自分はまだ独習中で、C++は未だ*や&、&&、で頭の中がグルグル回ってしまうレベルなもので、理解できそうですが
いきなり自力で作れそうにありませんわｗ
608:はちみつ餃子
21/03/14 18:12:48.12 aW+jce3e.net
>>586
> これ、何が悪いのでしょうか。。。
1998 年に国際規格 (ISO) になって以来、規格に iostream.h というものが有ったことはない。
.h は不要。
諸々の事情から iostream.h も用意している開発環境が多かったせいか
古い書籍では iostream.h としている場合は少なからずあるのだけれど、
主要な処理系の標準への準拠が急速に進んだこともあって、
資料も規格に寄せた書き
609:方が今では普通。 iostream.h は古い本の象徴みたいな感じになってる。 そんでもって規格にない以上は iostream.h が存在しない開発環境も普通にあるってのが問題。 https://wandbox.org/permlink/kwpJf5BumkarYWYD 規格になくてもデファクトスタンダードとしてどこにでもあるってのならまあいいかと思わないでもないけど、 無いこともあるんだ。 そういう環境だともちろんエラーになる。 初心者が入門書の最初に載ってるコードを入力してみてエラーになるってのは良くはないだろ。 そんでもって問題がそれだけとは限らなさそうという……と思わせるサインなんだよ、 iostream.h は……。
610:
21/03/14 20:04:14.75 uaeFGveg.net
>>590
手元の旧独習4版（ハーバード・シルト著）6章末「総合理解度チェック」
・次の演算ができるような strtype クラスを作成しなさい
・+ 演算子による文字列連結
・= 演算子による文字列代入
・<>==による文字列比較
固定長文字列を使ってもかまいません。難問ですが、よく考えていろいろと試してみてください。
必ずできるはずです。
611:
21/03/14 20:13:24.03 uaeFGveg.net
>>590
＞C++は未だ*や&、&&、で頭の中がグルグル回ってしまう
これらの「記号」は習得に順序があります。
まず * をしっかり理解します。C/C++ はなんといってもポインタが基本です。
次に参照 & を理解します。参照& を使う場面が出てきたら、これを * を使った書き方に書き直す、という機械的な訓練がいい練習になるでしょう
参照 で返す、という場面でも、①参照返しが出来る場合と、②参照返しはできずせいぜい RVO に期待するしかない場合、の①②二つの違いを明確に即答できるようになるべきでしょう（最近まで私はそれができなかった……）参照& の表現は新しい表現( ranged-for とか） でよく目にしますし、①②は結構重要だと思います
&& は多分最後でしょうね、私も && は良く分かっておらず、というか、分からないから使わないという態度に留まっていますが、まあそれでもなんとかなる気がします
612:デフォルトの名無しさん
21/03/14 20:26:39.87 ERa14GlL.net
>>592
やはり「独習」の違う本でしたわｗ
自分はC++関係の5ちゃんスレすら最近になって見てるんで、知らなかったけど
その本が「独習」のスタンダードなんですねｗ
独習C++ 第4版
URLﾘﾝｸ(poland-it-blog.com)
自分のは、↓の９位に入ってる本です。（しかも同じ出版社）
URLﾘﾝｸ(freelifetech.com)
ご紹介の独習はやり応えありそうなので、今の本を2回ほどやってから、次のステップでそちらを検討してみますわ
613:デフォルトの名無しさん
21/03/14 20:28:56.28 EFkbulbJ.net
QZ案外初心者やなw
でも言ってることは全面的に賛成
ポインタや参照、クラス等の基本を抑えてからでないとスマポや、C++11からの要素(右辺値参照含む)の使い方もわからんと思う
614:デフォルトの名無しさん
21/03/14 20:35:47.41 ERa14GlL.net
>>593
大変勉強になります
今後もよろしく
615:デフォルトの名無しさん
21/03/14 20:46:24.30 uaeFGveg.net
>>595
＞でも言ってることは全面的に賛成
ありがとうございます！
＞QZ案外初心者やなw
もう永遠の初心者のままだと思っていますが、それならそれで「初心者の気持ちが分かる視点からの意見の表明」という形でコントリビュートするのもありかな…、と。
616:
21/03/14 22:01:53.26 uaeFGveg.net
>>594
>>592 は歯ごたえがありそうでしょう？私もこの課題を最初に見たときは眩暈がしました…
それから 10 年くらいかな？？それくらいたってから URLﾘﾝｸ(mevius.2ch.sc)
617:2/37 を書き、なんとか卒業できたような気がします なおこれは、これでも例外方面に配慮が行き届いていない、とさらに書き直した気がしますが、その書き直しは失くしてしまいました……
618:はちみつ餃子
21/03/14 23:21:43.64 aW+jce3e.net
個別の機能を理解してからそれの組み立て方を学習するのがまどろっこしく感じる人もいると思う。
抽象度の高いほう (スマートポインタなど) から解体していく形での
学習のアプローチもそれはそれでありかもしれん。
個人的には個別の機能を先に学んだほうがいいとは思うんだけどね。
実例から学ぶと使い方のパターンとして頭に入ってしまって正確な理屈を
きちんと習得できない気がするから。
そうは言っても途中で学習を諦めてしまうようだと正確さもくそもないから、
人によってわかりやすさは違うし学習にはいろんなアプローチがあるということは
覚えておいてほしい。
619:
21/03/14 23:51:21.81 uaeFGveg.net
確かに、私が理解している狭い範囲においても、イテレータが先かポインタが先か、とか
C++11 / std::thread から入門したけど posix-thread なんか知らん！とか
そんな人から補強説が来るのが楽しみです
620:デフォルトの名無しさん
21/03/15 07:36:02.64 PXZ12KYt.net
>>591
ご回答ありがとうございます。
理解しました。
その辺も調査しながらやります。
621:デフォルトの名無しさん
21/03/15 13:58:23.84 RVKfnS+W.net
QZが意外と素直で好印象度アップ
逆に高飛車な餃子の高感度ダウン
622:デフォルトの名無しさん
21/03/15 21:47:16.57 pqfQRyG1.net
Qちゃんは昔からいるけど態度は変わらんね
ときどき自前のコード上げてるあたりは好ましい
プロへのリスペクトは持ってるし謙虚ではある
餃子ちゃんはマジメというか
いちいち規格に沿って発言してくれるんで好ましい
ただコード上げてるのはみたことないんで実力は不明
アマチュアなのにときどき調子乗っちゃってるのも微笑ましい
623:デフォルトの名無しさん
21/03/15 23:09:56.95 kCaDVUc0.net
はちみつのコードたまーに見るけどすごい変な癖があるよ
意味があるなしに関わらず固執するタイプなんだろうな
624:デフォルトの名無しさん
21/03/16 13:45:10.41 A61zCves.net
参照を返す関数の質問です。
オブジェクトの複数のパラメータを設定するときに、obj.param1(...).param2(...).param3(...); みたいに呼ぶ
パターンがあるじゃないですか（ちなみにこれって名前はあります?）
これをやりたいときは
Obj& param1(int val) { mParam1 = val; return *this; }
みたいに参照を返すように宣言しないとダメですよね?
Obj param1(int val) { mParam1 = val; return *this; }
だと、obj.param1(...) は動くけどリターン用にオブジェクトの（余計な）コピーが発生する、
obj.param1(...).param1(...) みたいに呼んだ場合はオブジェクトのコピーに2番目の呼び出しが行われ、
結局破棄されてしまうので、objに2番目のparam1()の呼び出しが反映されない。
こんな理解で正しいでしょうか?
実は参照を使う判断にイマイチ迷っているんですが、もしかして毎回（オブジェクトの宣言、引数、戻り値等）、
「このときはここでオブジェクトのコピーが発生するから...」とかイメージすべきなんですかね?
例えば関数の戻り値、関数を出るときに戻り値が臨時で複製されて呼び出し元に渡されるイメージを持って、
「ああこれだと余計なオブジェクトが生成されるよな、じゃあ参照だ。」的な判断?
625:デフォルトの名無しさん
21/03/16 16:13:51.30 xnFU2goU.net
builderパターンやね
626:はちみつ餃子
21/03/16 16:40:47.45 AqAKN3jJ.net
クラス構成を見ればビルダーパターンにあてはまりそうだけど、
メンバ関数を連鎖していく表記法のことはメソッドチェインと言ったり、
目的から言うと名前付き引数イディオムということもある。
URLﾘﾝｸ(en.wikibooks.org)
(要するに考え方のレイヤによる。)
627:デフォルトの名無しさん
21/03/16 17:00:51.56 7emEuadh.net
obj + a + b + c
operator + () は obj そのものを書き換えず、新たな実体を戻す
obj += a
operator += () は obj そのものを書き換えるついでに、自分自身の参照を戻す
これのどっちに合致したほうが都合がいいかで
複製を戻すか、自分自身の参照を戻すかを分けてる感じ
628:デフォルトの名無しさん
21/03/16 20:32:04.07 VN15UowM.net
>>605
> （ちなみにこれって名前はあります?）
大きく言うとFluent interface
URLﾘﾝｸ(en.wikipedia.org)
629:
21/03/16 21:25:10.58 EIvloTfy.net
>>609
その wikipedia の C++ サンプルは int main() が二箇所に現れていますが、これってどう読むのですか？
630:デフォルトの名無しさん
21/03/16 22:36:52.42 ne+I3KBD.net
すみません。
仮に、本を買って勉強する場合は独習C++というのがいいのですか？
独習C++はCの知識がなくても大丈夫ですか？？
631:はちみつ餃子
21/03/16 23:10:25.95 AqAKN3jJ.net
>>610
単に使い方のサンプルを便宜的に main で書いてあるだけでふたつあるのは特に意味ない。
632:デフォルトの名無しさん
21/03/18 18:04:58.78 KYeguKkE.net
>>611
633:デフォルトの名無しさん
21/03/18 18:05:52.45 KYeguKkE.net
>>611
江添本一択
634:デフォルトの名無しさん
21/03/18 18:59:10.35 OslqqG1Q.net
>>611
C関係無しで覚えるのもいいんじゃね？
635:デフォルトの名無しさん
21/03/18 19:00:25.69 OIk6P4WM.net
>>611
独習C++はCの知識が前提だったはず
636:
21/03/18 23:28:58.79 QiBLMBVe.net
>>605
＞これをやりたいときは
＞みたいに参照を返すように宣言しないとダメですよね?
＞obj.param1(...).param1(...) みたいに呼んだ場合はオブジェクトのコピーに2番目の呼び出しが行われ、
＞結局破棄されてしまうので、objに2番目のparam1()の呼び出しが反映されない。
確かに、メソッドチェインを繰り返すたびにコピーコンストラクタが呼び出されるのは、イマイチ、という感覚を私も同様に持ちます
だからメソッドチェインを書くときには私も参照を返すように書きます、結局のところ「参照を返す」というのは「ポインタを返す」ことですから、コンストラクタの走りようがない
しかし「参照を返す『必要がある』」と言い切れるかどうか？
「結局破棄される」というのは最後のメンバ関数が返す実体を回収していないからであり、「参照を返すから」破棄されるわけではないと感じました。
実際、この実体を回収すれば、それはそれで 2 番目以降の呼び出しが意味を持つように書けると思います
URLﾘﾝｸ(ideone.com)
URLﾘﾝｸ(ideone.com)
参照でよくわからなくなったときに私がよくやる「参照返しを全く使わずポインタで押し通す」とすると次のようになるかと思います
URLﾘﾝｸ(ideone.com)
637:デフォルトの名無しさん
21/03/19 03:28:58.86 mbZVOQ2F.net
だからムーブコンストラクタとムーブ代入演算子があるんだろうが・・
638:デフォルトの名無しさん
21/03/19 03:37:37.65 0CmLwf9e.net
>>617-618
てかそもそもコンストラクタ走っていいのかよこの場合に
639:デフォルトの名無しさん
21/04/09 12:21:23.57 dUyySPje.net
クラスFooのメンバ関数fの型ってどう書くの？
戻り値void、引数intです。
640:デフォルトの名無しさん
21/04/09 12:52:45.71 N6zWukcq.net
>>620
f の型は void (int) だけど f へのポインタの型は void (Foo::*)(int)
641:デフォルトの名無しさん
21/04/09 18:45:41.35 WYvZUx+H.net
>>621
それはメンバ関数へのポインタでしょ
聞いてるのは関数の型でもなく、メンバ関数の型です
642:デフォルトの名無しさん
21/04/09 20:18:08.96 DC3guaga.net
言われてみれば関数の型ってなんだ？
643:はちみつ餃子
21/04/09 21:13:09.06 foJJo5gI.net
C だと関数指示子 (Function Designator) で説明されたりするんだが、
C++ の仕様を Designator で検索しても出てこないな。
シグネチャもまたちょっと違う概念だし、
このあたりのきちんとした解説がまとまったものがあればぜひ読みたい。
644:デフォルトの名無しさん
21/04/09 21:39:18.43 MYEEijki.net
「メンバ関数の型」が必要になるケースって何じゃろ？
645:デフォルトの名無しさん
21/04/10 01:44:53.83 4ITkpFPM.net
>>622
だから「f の型は void (int)」って書いたのに、なんでそれが答えじゃないと思うの？
typedef void ftype(int);
struct Foo { ftype f; };
void Foo::f(int) {}
int main() { Foo x; x.f(0); }
646:デフォルトの名無しさん
21/04/10 08:44:20.64 gtw6CEDD.net
関数ポインタを考える以前は関数の型と言えばイコール評価した値の型だったな。
647:デフォルトの名無しさん
21/04/13 16:10:43.48 uVvL/txB.net
今は関数の型とかもうどうでもよくて
一周回り帰えりキャプチャとかダイナミックスコープとかの有用性や整合性が中心よね
648:デフォルトの名無しさん
21/04/15 15:55:01.75 6RtJrvVe.net
pod的な意味でなく論理的整合性的な型付けの恩恵受けたいなら、別に包む必要無くても常に即席structで返しててやんでい
649:デフォルトの名無しさん
21/04/24 08:11:28.54 LUJ0Utr0.net
C++/CLIで、スタティックライブラリからマネージドクラスを公開するのは無理なんでしょうか？
ヘッダファイルに全部実装書けば出来る、ってところまでは調べたんですが、ソースコードをプロジェクト外に置いてるのと変わらないので…。
ダイナミックライブラリでできるならそれでも構わないです。
650:デフォルトの名無しさん
21/04/24 08:19:46.15 nPKzA798.net
>>630
.NETでstatic libraryなんて作れたっけ？
最終的に.exeと.dllができるのが邪魔だからstatic libraryにしたいというだけなら、
いったんDLLとして作ってILmergeするのが一般的だと思う
651:デフォルトの名無しさん
21/04/24 08:36:31.23 LUJ0Utr0.net
>>631
Lib自体は作れるし、アンマネージクラスなら公開もできるんですが、マネージクラスだと参照側でメンバーが参照できず、LNK2020が発生してしまうんですよね。
ビルドオプションでなんとかできるものなのかな、と。
652:デフォルトの名無しさん
21/04/24 09:53:24.75 K4uxnQki.net
LNK2020ってそれnativeのC++からリンクしようとしてる？
653:デフォルトの名無しさん
21/04/24 14:56:57.93 LUJ0Utr0.net
>>633
libなのでクライアントはC++です
654:デフォルトの名無しさん
21/04/24 15:16:56.42 K4uxnQki.net
そりゃ無理。その仲立ちをするためにC++/CLIがあるのに。
一応nativeのC++からでも自分でCLRを立ち上げたりしてマネージドクラスにアクセスする方法は
あるらしいが、リンクしてそのまま呼ぶという形にはならない。
655:デフォルトの名無しさん
21/04/24 15:41:46.62 at4cvaWV.net
自作のプログラム、起動時の読み込み処理の前に以下を入れると
for(int i = 0; i < 100; ++i){
OutputDebugString("dummy!!!!\n");
}
起動時に行っている外部データの読み込みが凄く速くて
これを無くすと凄く遅くなるんですが怖い…
3分くらい違いが出るので明らかにおかしい
どっかでメモリでもぶっ壊れてますかね？
どういう理由が考えられるでしょうか？
656:636
21/04/24 15:43:36.70 at4cvaWV.net
さっきのダミーを入れなくても
普通にコードを追加したりしてても遅くなったり速くなったりする
別に読み込み処理の部分とは関係ないところでも。
なんでだろう？
657:デフォルトの名無しさん
21/04/24 15:54:20.61 hc4SaSPr.net
>>637
それは、本当に native の C++？
もしかして、C#のC++/CLI とか�
658:H
659:デフォルトの名無しさん
21/04/24 16:03:17.28 lkpB631F.net
コンパイラはほんと何してるのか分からんから、問題の部分だけ切り出したのを.sへ吐かせて読みなさい
10行程度のcコードなら、edxとか変な名前のは取り敢えず変数だなって思って追えば、アセンブリ知らずとも大体分かるよ
660:デフォルトの名無しさん
21/04/24 20:39:49.92 LUJ0Utr0.net
>>635
いや、
C++ライブラリ内にマネージクラスを作って
マネージのC++プロジェクトから
呼び出したいだけ
DLLだったら、C#のDLLからマネージクラスを呼び出すのと
理屈上同じだからできそうな気がするのだけれど
以前実装した時はInterfaceだけ公開して
呼び出されるとそのインスタンスを返す、みたいなことをしたんだけれど
661:デフォルトの名無しさん
21/04/24 21:31:19.65 +v1plSJo.net
>>640
.NETはstatic libraryをサポートしていない
出来上がった.libにはそのマネージドクラスのメタデータとか入ってないんじゃない？
662:デフォルトの名無しさん
21/04/25 00:05:51.07 Oojm0ZzH.net
>>641
結局そういうことだよね
なんか普通にlibのクラスを呼び出せますみたいなのをサンプル付きで出してた記事があってさ…。
まあstaticメソッドしかないクラスばかりだから、アンマネージクラスで公開するか、namespaceでまとめます。
ありがとうございました。
663:636
21/04/25 00:07:18.69 sRfn5IZk.net
>>638
C++とWin32APIのプログラムです
>>639
これは自分へのレスですか？
特に遅くなる以外は止まったりする事もないので
困ることはないですがなんか気持ち悪い…
664:デフォルトの名無しさん
21/04/25 03:40:15.50 vJWG11Gh.net
>>643
外部データの読み込みは、fopen, _open, CreateFile、CFile のどの系統を使
ってる？
665:デフォルトの名無しさん
21/04/25 03:43:25.25 vJWG11Gh.net
>>643
関係ないかもしれないが、HDDが寿命で故障寸前の時にHDDの読み込みが
時々極端に遅くなったりする現象を経験したことがある。
その場合は、そのプログラム以外でも同様の現象が起きるが。
666:デフォルトの名無しさん
21/04/25 03:49:56.55 vJWG11Gh.net
>>645
もし、他のアプリやファイルマネージャーも遅くなることがあるなら、
CrystalDiskInfoなどで診断してみて欲しい。
そのアプリだけ遅くなるが、アプリの動作は正常、というなら、
メモリーやスレッドやOSリソースの使いすぎなども考えられなくは無いが。
何か極端に変わったことしてたりしない？
667:デフォルトの名無しさん
21/04/25 09:07:00.47 x26Nnfhp.net
OutPutDegugなんちゃらの関数がファイル出力してるなら、単純にそのドライブのアクセス準備が整ってないとか。
以前、SSDに同じファイル名で一時ファイルの作成と削除を繰り返したら、SSDの仕組み上めっちゃ遅くなったことがある。
668:デフォルトの名無しさん
21/04/25 09:59:46.07 j6IXZwA/.net
>>642
どこの記事？
ちょっと気になった
669:636
21/04/25 10:38:16.68 sRfn5IZk.net
>>645-647
遅くなる原因の個所が分かった！
画像を読み込む時にメモリを操作して
16bitで読み込む部分があるんだけど
これを32bitで読み込むようにすると
どんなコードでもまったく遅くならない。
メモリの操作の部分がおかしかったみたい。
自分で書いたコードじゃないのでよくわからない。
32bitのやつと16bitのやつを載せるのでおかしい所あったら教えて。
670:636
21/04/25 10:39:18.00 sRfn5IZk.net
これは遅くならないコード
int X = 0;
for(int y = ImageHeight - 1; y >= 0; --y){
X = 0;
for(int x = 0; x < ImageWidth; ++x){
pPx[X] = ((DWORD*)pSrcBuf)[x + (y * ImageWidth)];
++X;
}
pPx += Pitch;
}
671:636
21/04/25 10:42:37.48 sRfn5IZk.net
これが遅くなる場合があるコード
672:WORD px, tmp; BYTE b; int X = 0; for(int y = ImageHeight - 1; y >= 0; --y){ X = 0; for(int x = 0; x < ImageWidth; ++x){ px = 0x00000000; pPx[X] = px; b = (BYTE)((((DWORD*)pSrcBuf)[x + (y * ImageWidth)] & 0xff000000) >> 24); //A tmp = 15 * (b / 255.f); px |= tmp << 12; b = (BYTE)((((DWORD*)pSrcBuf)[x + (y * ImageWidth)] & 0x00ff0000) >> 16); //R tmp = 15 * (b / 255.f); px |= tmp << 8; b = (BYTE)((((DWORD*)pSrcBuf)[x + (y * ImageWidth)] & 0x0000ff00) >> 8); //G tmp = 15 * (b / 255.f); px |= tmp << 4; b = (BYTE)((((DWORD*)pSrcBuf)[x + (y * ImageWidth)] & 0x000000ff)); //B tmp = 15 * (b / 255.f); px |= tmp; pPx[X] = px; ++X; } pPx += Pitch; }
673:636
21/04/25 10:46:22.20 sRfn5IZk.net
pPxは、32bitの時はDWORD*で、16bitの時はWORD*になってた。
全て載せると長くなるので変更すると速度が変わる部分だけ載せたよ。
16bitの方でも>>636のダミーを入れれば遅くならないんだよね。
やっぱメモリが壊れてるのかな？
674:デフォルトの名無しさん
21/04/25 11:02:40.44 vJWG11Gh.net
>>651
pSrcBuf, pPx, Pitch の型、及び、それらを初期化しているコードが重要。
そこに問題があるとバッファオーバーランしている可能性が捨てきれない。
675:デフォルトの名無しさん
21/04/25 11:04:39.40 vJWG11Gh.net
>>653
「初期化しているコード」を載せる際、ImageWidth, ImageHeightとの
値の関係が分かるようにしてほしい。
要は、ちゃんとバッファの範囲内に読み書きが収まっているかどうかが知りたい。
676:デフォルトの名無しさん
21/04/25 11:19:47.09 vJWG11Gh.net
>>652
例えば、pPxの指しているメモリーブロックのバイトサイズが、
Pitch * ImageHeight * (pPx の 1 要素当りのバイト数)
以上に、pSrcBufの指しているメモリーブロックのバイトサイズが、
ImageWidth * ImageHeight * 4
以上になっていることが重要。
677:デフォルトの名無しさん
21/04/25 11:46:51.84 vJWG11Gh.net
そういえば、pSrcBufを((DWORD *)pSrcBuf)のようにキャストしてから使っている
ことも気になる。
pSrcBuf = new DWORD [ImageWidth * ImageHeight]
ではなく、
pSrcBuf = new BYTE [ImageWidth * ImageHeight * 4]
などとしているのだろうか。
678:636
21/04/25 12:16:02.68 sRfn5IZk.net
>>653-656
void *pSrcBuf;
LONG Pitch;
pPxは、16bitの時がWORD*で32bitの時がDWORD*
という感じになってた。
初期化の部分がかなり複雑で結構辿って調べる必要があるんだよね…
でも思うのは初期化は、16bitと32bit大体同じで違うのはpPxの型くらいで
それで>>650の32bitのコードだと全然遅くならないから
>>651の16bitのコードの部分自体が何か変だったのかなと思ったんだけど
ここ自体は大丈夫なのかな？
679:デフォルトの名無しさん
21/04/25 13:26:15.86 QOuShU0Z.net
そもそも遅くなるって何分が何分になるん？
100分が103分ならそんなもんじゃね？
としか思えないし
680:デフォルトの名無しさん
21/04/25 13:48:46.76 sRfn5IZk.net
>>658
それが30秒が2分とか3分とかになっちゃって。
681:デフォルトの名無しさん
21/04/25 14:01:13.96 9Nm1id/y.net
>>659
それだとせいぜい6倍くらいだね。
>>650 と >>651 だと 6倍くらいの差が出るのは当然だよ。
682:デフォルトの名無しさん
21/04/25 14:37:31.77 sRfn5IZk.net
>>660
いやそうじゃなくて、>>636のダミーコードを入れると
何故か速い速度になって、それを取り除くと遅くなってしまう感じ。
普通にコード書いてても関係ない部分を追加したりすると遅くなったり
速くなったりするからおかしいなと思ってて。
683:デフォルトの名無しさん
21/04/25 14:41:04.92 9Nm1id/y.net
>>661
なるほど。では、
>初期化の部分がかなり複雑で結構辿って調べる必要があるんだよね…
であったとしても、原因を特定するには、少なくともまずそこを丹念に
調べる必要がある。
684:デフォルトの名無しさん
21/04/25 14:41:34.25 QOuShU0Z.net
>>661
とりあえず遅いコードと速いコードを晒してよ
バッファーオーバーランで制御変数壊してるとかあるかも知れんし
685:デフォルトの名無しさん
21/04/25 14:45:29.68 9Nm1id/y.net
>>661
そういえば、速い時でも30秒もかかっていることはとても気になる。
>>650 のコードだとどれくらいの時間になるの？
経験と勘で言えば、そのような平易なコードで30秒も掛かって、
時と場合により3分もかかるという現象が起きる場合、キャッシュ
が乱れている可能性がある。
もしかして、どこかで極端にメモリーをランダムアクセスしてない？
巨大なメモリーの中を、極端に不連続な場所をあっちこっちアクセスする
686:と キャッシュが聞きにくくなって、急激に遅くなることがある。
687:デフォルトの名無しさん
21/04/25 14:57:01.28 sRfn5IZk.net
>>662
確かにそこは念入りに調べる必要がありますね。
>>663
それが本当に>>636をまったく関係ない部分に入れるだけで
速くなったりしてて。普通にコード書いてまったく関係ないところ追加したりすると
速くなったり遅くなったりするんだよね。一旦速くなったら弄らない限り遅くなる事はなくて
逆に一旦遅くなったら弄らない限り速くなったりする事はない感じ。
>>664
読み込んでメモリ操作する部分自体はかなり多い数をやってるので
20～30秒くらいかかる時もある感じ。
読み込みとメモリ操作の部分で細かくメモリ確保と解放をやってるので
それのせいもあるのかな？
688:デフォルトの名無しさん
21/04/25 15:04:55.13 9Nm1id/y.net
>>665
>読み込んでメモリ操作する部分自体はかなり多い数をやってるので
>20～30秒くらいかかる時もある感じ。
話を総合すると、
>>650 のコードが、「20～30秒くらいかかる」が、
>>651 のコードが、速い時には「30秒」
ということになるが、コードを見る限り、651のコードは650の
コードの10倍以上かかっても不思議ではないコードになっているので、
この速度差はむしろ、少な過ぎる。
むしろ、>>651のコードは「3分」かかっている方が、
長年の経験と勘では正常に思える。
689:デフォルトの名無しさん
21/04/25 15:13:30.56 CFgRAQQ/.net
読込とか細かいメモリー確保とかコードに無いこと言われてもエスパーじゃないのでどうしょうもないな
悪いけど情報出せないなら他でやってくれ
690:デフォルトの名無しさん
21/04/25 15:19:48.04 sRfn5IZk.net
>>666
今チェックしたら650の方が少し速かったですｗ
650が12秒くらいで、651が22秒くらいでした
これが速い場合で、651が遅い場合は2分くらいでした。
650は遅くなることがないです。
>>667
ほんとうにそうですね。
とりあえず晒した所が大丈夫なら
他の部分は自分で調べてみようと思います。
691:デフォルトの名無しさん
21/04/25 15:45:51.96 S2tV53BX.net
>>668
>今チェックしたら650の方が少し速かったですｗ
>650が12秒くらいで、651が22秒くらいでした
>これが速い場合で、651が遅い場合は2分くらいでした。
>650は遅くなることがないです。
これだけでも重要なことが分かる。以後は、処理時間に関する(数学的な)定量的な話になる。
まず、650と651の速度差が1.8倍程度しかないことからすると、
pSrcBuf と pPx の読み書きに相当時間が掛かっていることを示唆している。
650と651のソースを比較した時、計算部分の処理がとても増加しているが、
読み書きはキャッシュまで考慮すると、650と651で差が出ない。
651では、pSrcBufからは何度も読み込まれているが、最初に一回読み込まれた後はキャッシュに乗っているため、
複数回読んだからといって時間増大の原因にはなりにくい。
651では割り算や掛け算の計算量が物凄く増えているのにそれが比率にして 0.8 にしかなっていない。
(割り算や掛け算は本質的に遅いことはこの議論に置いて重要である。)
大量の割り算、掛け算に掛かっている時間が 0.8しかないのに、高々1回ずつのメモリーへの読み書きが 1.0 の時間
かかっていることに着目すると、1ピクセルあたり、データバス-CPU間の転送の観点で言って、
pSrcBufからの「一回の」読み込みとpPxへの一回の書き込みに、かなり時間が掛かっていることを意味する。
データがキャッシュに乗っていれば、ここまでの時間が掛からないので、
長年の経験と勘によれば、このような事態が起きたとき、CPUの中のすべてのキャッシュを一掃してしまっていることが多い。
だから、例えば、バックグラウンドで他のアプリが動いていたりすると、キャッシュを
復活させるために物凄く時間が掛かることがある。
それで、他のアプリがメモリーを復活させようとしたかしていないかによって、
OS全体としての処理時間が如実に変わる現象が起きることがある。
これが、今回の奇妙な現象が起きている原因かも知れない。
692:デフォルトの名無しさん
21/04/25 16:25:58.61 sRfn5IZk.net
>>669
細かい分析ありがとう。
だとしたら>>636のダミーを入れると速くなるのも
そのキャッシュの原因に何か関係してるのかな？
でも今まで>>665でも書いたように一旦遅くなったら
遅くなったままで、速くなったら速くなったままなんだよね… コード弄らない限り。
もしかすると何か条件が重なればコードを弄らなくても遅くなったり
速くなったりすることもあるのかもしれないけど。今のところは確認出来てない感じ。
693:デフォルトの名無しさん
21/04/25 16:32:43.41 S2tV53BX.net
>>670
それより、650のコードで12秒も掛かっていることにかなり違和感を覚える。
ImageWidth が、ImageHeight が 2000 位までなら、4*10^6 ピクセルくらいで、
32BIT RGBカラーだとしても16MB位。
いまのCPUだと、>>650のコードくらいで12秒も掛かるはずは無い。
大雑多な予測だと、3.0GHzのCPUで、10(ms)くらいまでのはず。
ImageWidth や ImageHeight の値はいくらくらいになってる？
694:デフォルトの名無しさん
21/04/25 17:04:17.68 /0G3TNx0.net
650は最適化で X も x も同じ値で遷移していくし内側のループは
memcpy 相当のブロック転送におきかわりそうだけど
695:デフォルトの名無しさん
21/04/25 20:18:48.31 j6IXZwA/.net
650使えば遅くならないならいったん解決？
696:デフォルトの名無しさん
21/04/26 01:18:20.13 0cli3R6k.net
>>671
大きな画像(2048*2048)とかを結構読み込んでて。
読み込み処理自体は他の部分もあるのでそのくらいになってしまってる感じ。
>>672-673
一応は650にすれば何の異常もなくとても速く動作はするんだけど
出来れば原因が知りたいと思ってて。難しいならもうあきらめるけど。
697:デフォルトの名無しさん
21/04/26 01:51:09.48 u7NjNSbC.net
>>674
ファイルから読み込んでるらしいけど、fseek をループの中で多数回使うと
使わない場合と比べて劇的に遅くなるけど、seek 系の関数は使ってない？
698:デフォルトの名無しさん
21/04/26 02:03:22.38 +l9LtKe6.net
ファイル読み込みの部分でHDDキャッシュがかかってるかどうかだったり
よくある話
699:636
21/04/26 02:36:05.57 0cli3R6k.net
色々と試行錯誤してたら
>>651のコードのこの部分を
for(int x = 0; x < ImageWidth; ++x){
このように書き換えたら普通に速くなったｗ
for(int x = 0; x < ImageWidth / 1.0f; ++x){
なんか最適化が効いたり効かなかったりみたいな差に感じてしまう。
そういう原因なのかな？
700:デフォルトの名無しさん
21/04/26 02:37:06.08 u7NjNSbC.net
>>674
2048 * 2048 ドットの画像だとベタデータにしたとき16MBになってしまうので、
それを沢山読み込むとメモリー不足になり仮想記憶が働いてしまっている可能性も
有るかも知れない。どれくらいの枚数読んでいるか知らないのでなんとも
言えないけど。
701:デフォルトの名無しさん
21/04/26 02:39:54.17 u7NjNSbC.net
>>677
使ってるのはVisualStudioのようだけど、速度を測定する時には、ちゃんと
Release版にして最適化は有効にしてる？
DebugPrintを使っているなら最適化はOFFになってるのでは？
702:デフォルトの名無しさん
21/04/26 02:43:34.12 0cli3R6k.net
>>678
でも>>677の修正で速度が劇的に変化するのはなんでなんだろう？
>>679
Releaseで調べてるよ。OutputDebugStringはReleaseモードでも使えるので。
703:デフォルトの名無しさん
21/04/26 02:46:30.17 0cli3R6k.net
>>677の修正をしたあと、>>636のダミーコードを
追加したらなんと今度は遅くなったｗｗなんでだ？ｗ
>>636のダミーコードだけ追加したら速くなって
ダミーコードを削除すると遅くなる
その遅くなった状態で>>677の修正をすると速くなる
その速くなった状態で>>636のダミーコードを入れると
今度は遅くなるｗｗ
704:デフォルトの名無しさん
21/04/27 02:43:12.80 qV+SOSDm.net
状況から察するに、おそらく君が見ている部分じゃない
どこかに根本的な問題がある、という気がする
なんとなくだけど、バッファオーバラン系のような気がする
705:デフォルトの名無しさん
21/04/27 05:25:14.56 Vf/GSwOl.net
>>682
どこかに問題がありそうですよね。
バッファオーバラン系は問題あっても動いてしまう事があるから怖いですね。
地道に調べて行くことにします。
706:デフォルトの名無しさん
21/04/27 11:47:32.64 V9b4VlmB.net
それより、12秒間も大量のメモリーを使う状態でCPUがフル
707:パワー状態になっている とすれば、フル・キャッシュ汚染してる可能性がある。 フル・キャッシュ汚染すると、その後しばらくの間、キャッシュを取り戻すために 速度が不安定になるから、説明可能。
708:デフォルトの名無しさん
21/04/27 12:52:21.01 cPrICHbO.net
Meltdowm や Spector 対策のパッチの影響とか？
特定のパターンのメモリアクセスに対して例えばなんかのトラップが働いてキャッシュをクリアし、ダミーコード入れるとそのパターンが崩れてそういう処理が入らないとか。
709:デフォルトの名無しさん
21/04/28 02:54:54.42 XgRH6ChF.net
>>684-685
みなさんありがとうございます。
色々な問題が考えられそうですね。参考になります。
もう少しコード弄りながら挙動を調べて行きたいと思います。
710:デフォルトの名無しさん
21/04/28 04:32:07.96 v8E9sca8.net
>>686
なお、y方向に関して、メモリーを上下逆さまに読んでいっているところがあるが、
本当はそういうのはDDR-Memoryやキャッシュと余り相性が良くない。
しょうがないけれども。
それでも、x方向には「順方向」に読んでいるからまだなんとかなっている。
完全にメモリーを逆方向に読んだりすると、低速化の原因になる。
この場合には難しいが、なるべくならメモリーは順方向にアクセスした方が
速くなる。DDR-MemoryはBurst転送が基本なので。
キャッシュに乗っていれば、逆方向でもなんとかなるが、キャッシュから
外れると、DDR-MemoryのBurst転送とは逆方向にアクセスするのは
速度低下の原因になる可能性が出てくる。絶対ではないが。
711:デフォルトの名無しさん
21/04/28 10:42:03.12 XgRH6ChF.net
>>687
そういう問題もあるんですね。とても詳しくて勉強になります。
ありがとうございます！
712:デフォルトの名無しさん
21/04/28 11:32:29.48 oswWyFbg.net
>>687
読み書き方向が逆になるなら、読む方を順方向にすると良さそうだと思うけどどう思う？
713:デフォルトの名無しさん
21/04/28 13:14:16.90 WdoV9Bq9.net
>>689
コンパイラのくせに生意気だぞ
714:デフォルトの名無しさん
21/04/28 13:16:59.82 jQpDsyge.net
>>689
実は昨日の夜から、俺もそう思ってた。
今は、
読む方が逆方向で、書く方が順方向になってしまっているが
読む方を順方向に、書く方を逆方向にした方が DDR-SDRAM や キャッシュの
仕組みから行って速くなる可能性が高い。
715:デフォルトの名無しさん
21/04/28 14:04:09.00 4fcF+gv5.net
Windows の bitmap で ファイル中の配置や CreateDIBSection() で戻ってくるメモリの配置だな
デフォで bottom - up の方向 カメラのフレームとかは top - down な方向
ん？メモリ操作なコードだけど実はメモリマップドファイルだったりして
716:デフォルトの名無しさん
21/04/28 15:30:36.23 WdoV9Bq9.net
走査線と描画が重なったらチラツキが激しくなるから下から描いていくんだよ
717:デフォルトの名無しさん
21/06/14 15:32:51.34 TE2ntQhj.net
for(int a=0; ...; ...){...} とかはループ内だけのスコープで int a が使えるのに
int a;
while(a){...}
とか
int a;
do{...}while(a);
とかは
while(int a=...){...} ←これだけはOK?
とか
do{...}while(int a=...);
とか
do{int a; ...}while(a);
みたいに書けないのはなぜ？
718:デフォルトの名無しさん
21/06/14 15:40:36.46 peg/OyGg.net
do{...}while(int a=...); 宣言より前に変数を使用する
do{int a; ...}while(a); スコープの外に変数を持ち出す
719:はちみつ餃子
21/06/14 17:56:57.54 fvxG9/iR.net
>>694
C/C++ の理屈では波括弧の部分は繰り返しの構文 (do や while) の一部ではない。
たとえば while の文法は
while ( expression ) statement
というように定義されていて、 statement ってのは要するに文をひとつ書けるってことね。
で、 statement として複文 (波括弧によって複数の文をひとつにまとめたブロック) もありうるってことになってる。
そんでもってブロックの先頭で宣言された変数のスコープに関するルールはブロックのほうに書かれていて、
繰り返しの構文のときだけ特別扱いということは出来んのだわ。
> while(int a=...){...} ←これだけはOK?
これは C++ では良いけど C では駄目
720:デフォルトの名無しさん
21/06/14 18:58:23.47 HtMoZ8Hn.net
小さいスコープの中だけで使う自動変数だってんで
特に if や for 等なく いきなりカラス括弧開いて変数宣言することがままある
721:デフォルトの名無しさん
21/06/14 21:48:16.36 OzvaLd6A.net
C++ってＯＳレイヤで差異が有るファイルシステムの事を考慮せずにプログラムを書ける済む仕組みって組み込まれてるの？
722:デフォルトの名無しさん
21/06/14 21:53:52.73 VOy4fGQR.net
標準ライブラリに含まれるファイルシステムライブラリでできる範囲の操作なら差異は出にくいと思うけど
723:デフォルトの名無しさん
21/06/14 22:00:33.63 eQ9/Z+Eb.net
>>694,696
C++でもwhileの判定式中の宣言は毎回新しくなるんで、使いみち思いつかん。
while(int i=10) { i--; } は、無限ループになる。
できるとしたら、処理が終わったらすぐに始末したいobjに対して、
{ myclass obj(); while(obj) { obj.some_op(); } }
(obj は operator bool() とか実装してる前提)
が、
while(auto obj = myclass()) { obj.some_op(); }
こんな風にかけてちょっと{}がスッキリするくらい？（実際はobjが毎度構築される）
724:デフォルトの名無しさん
21/06/14 23:04:55.36 wv1U8ajF.net
カラス括弧！
初めて見た！
725:デフォルトの名無しさん
21/06/15 08:13:38.32 4rRZmg7L.net
>>700
まあ while(...){} は for(; ...;){} で書けるしメリットないかな
ただ
do{ int a = …; }while(a); の方は書けたら嬉しいな
使用頻度は低いけど
726:デフォルトの名無しさん
21/06/15 10:57:08.11 5dh+WKsO.net
do は do .. while(0) のパターンしか使わないな。
727:デフォルトの名無しさん
21/06/17 23:23:03.28 Gx3mnqFH.net
break用なら switch(0)default:{...} っしょ？
728:デフォルトの名無しさん
21/06/18 08:43:02.57 R4m5mk7U.net
それdoよりどういうメリットある？
わざわざdefault:書かないとならないしインデント深くなりそうだし。
729:デフォルトの名無しさん
21/06/18 11:21:27.64 FZUuAAIq.net
マクロで展開するならインデントは無視できる
730:デフォルトの名無しさん
21/06/18 11:50:10.76 7Huy+AZL.net
do{}while(0) は最後に ; 書く前提だし矛盾ないけど
switch(0)default:{...} は ; の扱いの困らない？
731:デフォルトの名無しさん
21/06/18 11:55:35.37 AVf6Ht59.net
for (int i = 0; i < 1; i++)
732:デフォルトの名無しさん
21/06/18 12:32:57.03 6AzE04jr.net
{ } 内スコープからの脱出で break; 使いたいってのと
マクロで見た目関数向けな #define foo(arg) do { なんちゃらかんちゃら } while(0)
do { } while(0) は両立できるけど switch(0)default:{} で後者は怪しげ
if (<condition>) foo(arg); else <elsecase>; とかが
733:デフォルトの名無しさん
21/06/18 13:25:48.49 7Huy+AZL.net
while(1){
...
break; // } の直前
}
で良いと思う
734:デフォルトの名無しさん
21/06/18 14:27:23.16 tn5JYHw4.net
それどういう意図があんの？
処理は結局1回
スコープだけじゃダメなん？
735:デフォルトの名無しさん
21/06/18 14:44:41.04 tzOvIsZE.net
>>710
お前が良いと思うなら使えばいいと思うが俺には無駄なbreakが必要なのはダ�
736:Tいと思うから do { ... } while(0); にするわ
737:デフォルトの名無しさん
21/06/18 20:29:59.97 R4m5mk7U.net
>>706
マクロはフォーマッタでの扱いが定まらんから制御構造では使いたくないのよな。
セミコロンで終端しておかないとインデントがおかしくなるとか、後続に開きブレースを置くと
やっぱりインデントが変になるとか。
738:デフォルトの名無しさん
21/06/19 12:53:56.96 EDF+B3Dq.net
#define breakblock switch(0)defalut:
でいいやん
できないとか怪しげとか意味不明
マクロ化する必然性がそもそもわかんないけど
739:デフォルトの名無しさん
21/06/19 13:08:34.87 AhXAE8oj.net
そこまでして switch(0) 使う理由がよくわからん。
do while(0) と比べてどういうところが良いの？
740:デフォルトの名無しさん
21/06/19 13:21:09.67 ylfkd6bV.net
マクロの例でもわかるように波括弧を単独で使える
変な処理が始まってんの一目瞭然
continueもgotoで(goto使わない別ルーチン探せよｗ
等
#define breakblock(a) uniqelonglongprefix##a:switch(0)default:
#define bbcontinue(a) goto uniqlonglongprefix##a
741:デフォルトの名無しさん
21/06/19 14:04:38.18 AhXAE8oj.net
>マクロの例でもわかるように波括弧を単独で使える
ようは末尾に while(0); を書かなきゃならないのが嫌ってことかな。
わからんでもないが、自分はマクロや default: より気にならないからいいや。
742:デフォルトの名無しさん
21/06/19 16:30:22.52 8gjebq3e.net
#define foo(arg) switch(0)default:{ なんとかかんとか }
これはキモイ
743:デフォルトの名無しさん
21/06/20 18:26:02.94 3hmKhJNO.net
でもその構文はdefineで置き換え前提で使ってるとしか思えない
744:デフォルトの名無しさん
21/06/20 19:15:11.97 XoXh1cqB.net
goto書くと死んじゃう人は大変だなぁ
Dijkstraもそこまでは言ってないらしいぞ
745:デフォルトの名無しさん
21/06/20 22:56:11.58 R7oo70Ox.net
ナンチャラカンチャラの人のdefine使用意図が無意味すぎてどうもc言語エアプなんじゃないかと疑う
746:デフォルトの名無しさん
21/06/21 16:42:57.66 iJjBc6fp.net
switchのやつは最後にbreakかfall throughってコメント書いとかないと文句言うチェッカとかありそう
747:デフォルトの名無しさん
21/06/29 11:07:55.25 HA4DrIsJ.net
do {
int a;
:
} while(a);
↓
for(int a;;) {
:
if(!a) break;
}
でいいんじゃない？
748:デフォルトの名無しさん
21/07/05 16:13:31.07 3/iVgePD.net
別のところで質問したのですが、初心者歓迎スレのほうがいいと思いこちらで質問し直します。
Macのclang++でコンパイルしています。
cstdlibをインクルードしなくてもrand()が使えてしまうのですが、これはなぜでしょうか？
749:デフォルトの名無しさん
21/07/06 01:49:57.37 w3zU8vH7.net
>>724
手元のM1のでやったら普通にエラーになるけど？
printf("%d",rand());
だけ書いたやつ。
clangでもデフォはエラーだったような。Ｃ言語の方はコンパイルオプションで通せる。暗黙の関数宣言。
すまん、役に立てなくて。
750:はちみつ餃子
21/07/06 05:58:16.49 kwaneL8R.net
>>724
ヘッダファイルが他のヘッダファイルを内部で include している場合は有りうる。
たとえば iostream を include したら自動的に ios や istream なども include されることは保証された動作。
ただ、 cstdlib を (間接的に) include すると仕様で明言している標準ヘッダはないと思うので
rand がどこかで勝手に宣言されているのだとしたら処理系の固有の動作だと思う。
-M オプションで (間接的に include されているものも含めて) 依存関係があるヘッダファイルを
抽出できるからそれで確認できるよ。
751:724
21/07/06 08:23:42.
752:24 ID:9fUGxcs8.net
753:はちみつ餃子
21/07/06 08:56:08.30 kwaneL8R.net
>>727
処理系依存だと思う。
iostream が暗黙に include すると仕様に明記しているのは
ios, streambuf, istream, ostream の 4 つ。
URLﾘﾝｸ(timsong-cpp.github.io)
あえていうなら cstdio の機能と結び付けるのが役割であるようにほのめかされている
ので普通の実装なら cstdio も include することになると考えてもいいと思うけど、
それ以上のことについてはっきりしたことは書かれてない。
rand が必要なら (たとえ実態として間接的に cstdlib が include されていても)
プログラマは明示的に cstdlib を include するほうがいい。
というか、そもそも論としてはいまどき rand を使うのは避けるほうが賢明な考えだと思うけどね。
754:724
21/07/07 08:49:49.95 O+5oUfAp.net
>>728
なるほど、そもそも論まで含めてよくわかりました！
ありがとうございました！
755:デフォルトの名無しさん
21/07/09 19:37:14.99 We+HIKc2.net
C言語にpthreadを使ってマルチスレッドにするときの初歩的な質問をしたいのですが、
大域変数を複数のスレッドが読み書きする部分はミューテックスでロックしないとマズい、という
説明はわかった気がします。
では読むだけの部分はどうでしょうか。単にスレッドが変数の値を読みに行った瞬間の値を
知りたいだけならば、別にロックはしなくても害はないような気もしますが.... プログラム内の
別の箇所で書き込む部分はロックして、おかしなことが起こらないようにするとして。
それとも読むだけの場合もロック（書き込む場合に使うじミューテックスでロック）は必要でしょうか。
756:デフォルトの名無しさん
21/07/09 19:46:28.14 TIX9j1Dy.net
必要ないぞ
757:デフォルトの名無しさん
21/07/09 21:27:55.69 wrMb4YqN.net
必要だぞ
758:デフォルトの名無しさん
21/07/09 21:31:49.00 RRTM5Oms.net
>>730
スレッド実行中に書き換わる可能性があるなら必要。
変数を読むといってもCPUは一度内部のレジスタに読み込まないと処理できないので、
スレッド１でレジスタに読み込む→スレッド2で変数を書き換える→スレッド1に結果が反映されない
という事態が発生する可能性がある。
759:デフォルトの名無しさん
21/07/09 22:32:02.32 eGF9BJZ0.net
>>733
それ反映する必要ないだろ
単にスレッド1が先に読んだだけだし
それより読み書きがアトミックでないなら読み出し時にも排他しないと書き換え中の変な値を読んじゃうかと
760:デフォルトの名無しさん
21/07/10 01:06:02.19 iVyIfxP9.net
書き換え後に古い値を取得してもええの？
761:デフォルトの名無しさん
21/07/10 04:35:16.68 jD2ZKaD3.net
ええ場合もある
「単にスレッドが変数の値を読みに行った瞬間の値を知りたいだけ」はそれでええ場合のように聞こえるな
762:デフォルトの名無しさん
21/07/10 05:28:04.15 TJHT9gxK.net
ええ場合も何も読んだ後で書き換えられたのをどうやって反映させるつもりなんだよ…
763:デフォルトの名無しさん
21/07/10 05:33:10.76 Tru2G6zE.net
関連する操作すべてを優先順付きキュー経由にし
巻き戻し必要な操作にはジャーナル機能も入れ
やり直し再キューすんのよ
764:デフォルトの名無しさん
21/07/10 05:36:14.97 N1Z7W
765:Bqy.net
766:デフォルトの名無しさん
21/07/10 06:47:09.06 TJHT9gxK.net
>>739
それはまた違う話
volatile c言語 とかでぐぐれ
767:デフォルトの名無しさん
21/07/10 07:11:18.51 JKFXuD7+.net
スレッドAが 16bit長の整数を書き換える
スレッドBが 同じ16bit長の整数を読み込もうとしたとき
8bit長でしかアトミックな操作が保証されてないシステムだと
初期状態 0x0000 で スレッドA が 0xFFFF と書き換える
A書き込み 上位FF
(スイッチ)
B読み込み 上位FF
B読み込み 下位00
(スイッチ)
A書き込み 下位FF
こういうことが起き得るという話でいいんかな
768:デフォルトの名無しさん
21/07/10 08:27:22.56 N9R+gZBb.net
>>734
いや、先に読んだだけっていっても、例えば
i f (v==1)
みたいな条件式を評価した段階では1だったけど、その先で急に2に変わった、とかだったらまずいだろw
769:デフォルトの名無しさん
21/07/10 08:34:33.02 EesV0O7a.net
質問者の文言が
>単にスレッドが変数の値を読みに行った瞬間の値を知りたいだけ
>読みに行った瞬間の値を知りたいだけ
なので必要なし
以上
770:デフォルトの名無しさん
21/07/10 08:39:13.41 fOJ6OsHP.net
>>742
何もまずくないだろ…
771:デフォルトの名無しさん
21/07/10 08:48:41.36 N9R+gZBb.net
>>744
ifの中ではもう一度vの値を読んだときには2になってたりするわけよ
vが1の前提で書いたコードの中に2を突っ込んだらまずいよ
772:デフォルトの名無しさん
21/07/10 09:11:07.28 16vz6VAu.net
>もう一度vの値を読んだとき
まずいのはこっちであって>>742のifや>>733自体は問題ないんでは。
773:デフォルトの名無しさん
21/07/10 09:15:23.13 nctQkkF+.net
質問者が言ってないことに加えて勝手に仮定を追加してまずいとか言ってる>>745はもう黙ってほしい
774:デフォルトの名無しさん
21/07/10 09:51:11.89 6bm+w6Lu.net
まずいのは>>745の頭だったというオチw
775:はちみつ餃子
21/07/10 09:56:52.21 11oc3t46.net
>>730
結論から言うとロックは必要。
同一のメモリに対するアクセスの少なくとも一方が書き込みである場合には衝突すると定義されている。
URLﾘﾝｸ(timsong-cpp.github.io)
その場合にはデータ競合が発生する。
URLﾘﾝｸ(timsong-cpp.github.io)
同時に起こりうるアクセスの内でひとつでも書き込みが存在したらそれはデータ競合の可能性があるってこと。
ミューテックスはミューテックスの所有権を取り合うことで競合を阻止する仕組み。
ロックというのは「ミューテックスをロックする (ロックしている間は自分がミューテックスの所有権を持っている)」
ということであって、対象となるデータそのもののアクセスを直接的に制御してるわけじゃないので、
書き込み側でロックするだけでは意味がない。
776:デフォルトの名無しさん
21/07/10 10:17:52.46 fOJ6OsHP.net
>>749
at least one of which is not atomic
の意味ぐらいは理解してからレスしなよ
777:デフォルトの名無しさん
21/07/12 08:43:59.78 Y3qBMERg.net
>>749
質問者は衝突しても問題ないケースで排他は必要かどうかを聞きたいんだろ
778:デフォルトの名無しさん
21/07/12 12:14:53.15 uJpO0uZ2.net
「衝突しても問題ない」＆atomicも使わない＝「データ競合となっても問題ない」＝「動作が未定義でも問題ない」なら
確かにロックは不要だけど。
779:730
21/07/12 15:19:59.68 VxiBn2TN.net
730です、どうもお騒が�
780:ｳせしております。 どうやら読み出しだけのときも基本的にはミューテックスを使うべきのようですね。 私の場合は域変数をカウンタとして使っていてその値をログ出力する、というような状況で、 なんとなくミューテックなしでもいいかと思ったのですが、ミューテックスを使わない場合は 気持ち悪い値がプリントされている感じですかね。 一般的な状況では、ミューテックスを使わなくても実害がないかを考えるよりはちゃんと ミューテックスを使った方がよさそうですね...
781:デフォルトの名無しさん
21/07/13 17:41:58.36 DZW75fJj.net
「今値を書いてるから 書き終わるまで待て」と待たす相手は
次にそこへ書き込むヤツだけじゃなく
そこを読込もうとしたヤツも対象にしとけば ちゃんと書き終わった値が読込める
中途半端に書いてる最中であっても意図的に抜き出したいのなら 書き終わるまで待たずに読む
そしてみゅーてっくすの激しい握り合い
782:デフォルトの名無しさん
21/07/13 19:15:08.97 Cs3wNevb.net
>>753
単純なカウンタみたいなアトミックに読み書きできるような変数なら排他は不要だよ
783:デフォルトの名無しさん
21/07/13 20:10:22.43 +UxqO86S.net
>>755 なんでそんな嘘を教えようとするの？
784:デフォルトの名無しさん
21/07/13 20:55:03.74 Cs3wNevb.net
>>756
>>749のリンク先読めばわかると思うけど競合が発生して結果が未定義になるのは
> at least one of which is not atomic
のケースね
785:デフォルトの名無しさん
21/07/13 21:33:13.25 +UxqO86S.net
>>757
そこで言ってる "atomic" の意味は std::atomic<int> ならOKで int はダメという話なんだけど、
「単純なカウンタみたいなアトミックに読み書きできるような変数」って言い換えちゃったらどっちもOKに読めちゃうでしょ。
786:デフォルトの名無しさん
21/07/13 21:39:13.87 Cs3wNevb.net
>>758
intがダメなのは>>741みたいなケースね
> 「単純なカウンタみたいなアトミックに読み書きできるような変数」
でだめだと言うなら実例教えて
787:デフォルトの名無しさん
21/07/13 22:40:14.76 31Jksjnm.net
単純なカウンタがアトミックに読み書きできるかは
基本型の宣言だけではわからんから
アトミック化の指示ができるならやっとけ ということでいいんでないの？
788:デフォルトの名無しさん
21/07/13 22:49:59.37 Cs3wNevb.net
>>760
そのスタンスでいいと思うよ
俺はアトミックに読み書きできるケースなのに嘘とか言ってる>>756がなんか特殊なケースを知ってるのかな？って思ってるだけ
789:デフォルトの名無しさん
21/07/13 23:59:32.08 31Jksjnm.net
指示ができない場合にはアトミックに操作できる保証なんてないから
排他したほうがいいぜって立場
790:デフォルトの名無しさん
21/07/14 00:44:44.53 pCGEFvrX.net
>>759
生の int に複数スレッドから排他なしでアクセスしてたらその時点で未定義動作＝ダメなんだってば。
未定義動作となる場合に必ず期待に反するコードが生成されるわけでもないんで、実例を出せというのも意味が無い。
（実例が無いからといって「敢えて」未定義動作に誘導するというのは意味が無いどころか有害。）
・・・スレッドサニタイザで引っかかってウザい、とか言えば「実例」として納得してくれるの？
791:デフォルトの名無しさん
21/07/14 01:04:57.94 b90ql0x3.net
生のintへのアクセスがアトミックに行えるかって処理系が保証したりしないのけ
792:デフォルトの名無しさん
21/07/14 05:39:14.15 dtsN+T48.net
URLﾘﾝｸ(stackoverflow.com)
793:デフォルトの名無しさん
21/07/14 06:51:23.81 3FmZNcD6.net
>>764
保証してる処理系なら std::atomic<int> でオーバーヘッドは生じない、つまり排他は要らんってことでしょ
>>756がなんか実例知ってるかと思ってたけど単なる規格厨だったなw
794:デフォルトの名無しさん
21/07/14 12:49:26.09 pCGEFvrX.net
>>766
オーバーヘッドが生じるかどうかで考えてるなら（それもおかしいんだけど）、こんな例を見れば考えを改めてくれたり
795:するの？ https://godbolt.org/z/6oM5oevsY #include <atomic> int load(std::atomic<int> const& x) { return x; } int load(int const& x) { return x; } ↓ARM64 gcc 11.1 -O2 load(std::atomic<int> const&): ldar w0, [x0] ret load(int const&): ldr w0, [x0] ret
796:デフォルトの名無しさん
21/07/14 18:54:32.14 VBWUb4q7.net
>>767
それメモリーバリアの話で排他の話じゃないけど、何を言いたいの？w
797:デフォルトの名無しさん
21/07/14 19:20:02.20 pCGEFvrX.net
>>768
766 が「オーバーヘッドは生じない」ならば「排他は要らん」という論理らしいので
「オーバーヘッドは生じない」を否定すれば「排他は要らん」とかいう嘘を言わなくなってくれるかなと思って書いてみた。
オーバヘッドの発生と排他の要・不要とが 766 の頭の中でどう繋がってるのかは知らない。
798:デフォルトの名無しさん
21/07/14 19:25:42.08 VBWUb4q7.net
>>769
まあメモリーバリアも一種のオーバーヘッドと言えなくもないがそういう話でないことぐらいはわかりそうなもんだけどねw
で、排他が必要な例は見つかったの？
799:デフォルトの名無しさん
21/07/14 20:14:07.80 pCGEFvrX.net
>>770
ごめんよ。元から意味が分からなかったところ「オーバーヘッド」の意味が何か文字通りの意味じゃなかった
みたいだし、もうどういう話なのかさっぱりだわ。
767 の「オーバーヘッド」が何を指すのか、それと排他の要・不要との繋がりがわかるようだったら解説よろしく。
「排他が必要な例」と言われても、こっちとしては複数スレッドで生の int を読み書きするなら
常に排他が必要という認識なんで文字通り「排他が必要な例」なら無数にあるんだよね。
そういうのを挙げても謎理論で「不要だろ」とか「コレジャナイ」って言うだけで話は進まなさそう。
ここまでの流れを読めば >>755 をうっかり信じちゃう人もいないだろうし、もう放置でいいかなという気になってる。
800:デフォルトの名無しさん
21/07/14 20:22:20.00 cMMfM4oH.net
>>771
あえて指摘しなかったけどstd::atomicでは既定のメモリーオーダーがseq_cstであることを知らんのか？
自分で「あんたの言うオーバーヘッド」かかる書き方してオーバーヘッドかかるから排他ガーとか意味不明なんですけど？w
そもそもstd::atomicは必ず排他かかるわけでもないし人を嘘つき呼ばわりするならもう少し勉強した方が恥をかかなくて済むと思うよ
801:デフォルトの名無しさん
21/07/14 20:35:16.14 pCGEFvrX.net
>>772
ごめんそれは知ってるよ。でもそれを知ってる知識レベルの人が >755 のような主張をしてるとは思わなかったんだ。
あと繰り返しだけど「オーバーヘッドかかるから排他ガー」とか言ってるのは >766 だけね。意味不明なのには同意する。
「std::atomicは必ず排他かかるわけでもない」は正しいけど、それと >755 が嘘であることに関係は無い。
802:デフォルトの名無しさん
21/07/14 22:17:32.53 cMMfM4oH.net
>>773
> ごめんそれは知ってるよ。
えっ？
知ってて>>767ってそれこそ意味不明なんですけどw
結局何を言いたかったの？
> あと繰り返しだけど「オーバーヘッドかかるから排他ガー」とか言ってるのは >766 だけね。
ああマジで日本語の理解力がないのね
（もちろん環境によるけど）std::atomic使っても生のintと同じようにアクセスできる = 排他なんてしてない
って話ね
念の為に言っておくけど>>764が言うようなハード上の排他制御は別の話ね
> 意味不明なのには同意する。
同意なんていらんから>>767を書いた意味を説明してよ
> 「std::atomicは必ず排他かかるわけでもない」は正しいけど、それと >755 が嘘であることに関係は無い。
嘘だと言うなら根拠を示したほうが良いと思うよ
まあ示せないからグダグダ言うとか関係の無いメモリーオーダーの話とかにそらそうとしてるんだろうけど…
803:デフォルトの名無しさん
21/07/14 23:08:12.27 pCGEFvrX.net
>>774
「767を書いた意味」なら>>769で説明した。
「環境によるけど）std::atomic使っても生のintと同じようにアクセスできる = 排他なんてしてない」これは正しい。
でもそれは生の int でデータ競合を避けられる理由にはならない。
>>755 が嘘だという根拠は >>749 に挙げられた規定による。その条件
"at least one of which is not atomic" について、生の int へのアクセスは
"not atomic" に該当するから排他なしのアクセスでは未定義動作となりダメだと言っている。
規格文面の "atomic" は、規格が規定する C++ 抽象機械上の概念という認識。
対して 755 は、規格文面の "atomic" は各処理系でのメモリアクセスが実際にアトミックかどうかに依ると考えてそう。
残念ながら規格の文面で明確にその解釈を否定できないんだけど (URLﾘﾝｸ(cplusplus.github.io))
少なくとも現メモリモデル策定当時から Web 上に積み上げられている多くの記事（標準化委員会の↑含む）や
現行コンパイラ（最適化、スレッドサニタイザなど）での扱いと合致しない。
804:デフォルトの名無しさん
21/07/15 05:14:12.89 oWQENBCT.net
>>775
> 「767を書いた意味」なら>>769で説明した。
あああのメモリーバリアと排他の区別もついてないアホ丸出しの説明ねw
> 少なくとも現メモリモデル策定当時から Web 上に積み上げられている多くの記事（標準化委員会の↑含む）や
> 現行コンパイラ（最適化、スレッドサニタイザなど）での扱いと合致しない。
百歩譲ってstd::atomic使えと言うのはいいけど、排他は必須じゃないだろ
805:デフォルトの名無しさん
21/07/15 06:52:54.80 DRiXJTFv.net
charはatomicなの？規格にどれがatomicだってあるの？
どれがatomicかなんて、CPU毎に違って当然だと思ってたわ
806:デフォルトの名無しさん
21/07/15 07:50:32.57 oWQENBCT.net
>>777
CPU毎と言うかシステム毎に違うだろ
807:デフォルトの名無しさん
21/07/15 08:52:46.15 JIUDKEB4.net
>>776
うん。データ競合を回避するにあたって std::atomic を使えば排他は必須じゃなくなるよ。
ミューテックスを使うなどの排他（順序付け）でも回避できて、どっちかでもいいし両方でもいい。
>>755 が嘘だという点には異論なくなったみたいだね。よかったよかった。
808:デフォルトの名無しさん
21/07/15 09:20:51.24 oWQENBCT.net
>>775
排他は要らんケースがあると言うだけの話
ちなみに>>755では生intなんて一言も書いてないけどね
std::atomic<int>でも多くの環境では
> 単純なカウンタみたいなアトミックに読み書きできるような変数になるしな
まあ結局規格ガーって言うしかないレベルの低い規格厨が関係のないメモリーバリアーとか出してきて恥を晒しただけだったなw
809:デフォルトの名無しさん
21/07/15 10:06:00.17 ux6gJq+a.net
お前ら暇すぎやろ
810:デフォルトの名無しさん
21/07/30 19:50:56.40 VEABT8DF.net
C++ のバイナリ互換性についてお聞きしたいのですが。C++ のライブラリの中に以下のようなものが
あったとします。
class A { char *p1; };
class B { /* 略 */ };
class C { A a; B b; };
で、class A に新たな要素を追加して
class A { char *p1; char *p2; };
としてからライブラリを再ビルドし、以前のアプリのバイナリと混在させると、class C 内で a のサイズ
が変わる結果 b へのオフセットが変わりクラッシュするようです。
そこでふと思ったのですが、class A に最初から
class A { char *p1; char *p2; char *p3; char *p4; };
等と最初からある程度要素を確保しておき、必要に応じ上の方から使っていく、みたいなやり方は
アリでしょうか? （b へアクセスするときのクラッシュを防げるでしょうか?）
811:デフォルトの名無しさん
21/07/30 19:57:58.75 SwFfvD28.net
pimpl使え
812:デフォルトの名無しさん
21/07/30 21:01:43.73 y9Kee4rz.net
>>782
素直にC.aやC.bをポインタにすりゃいいだけちゃう？
813:まあ俺が言うのもなんだがw
21/07/31 22:17:00.01 m7lSxL/B.net
>>782
クラス定義が変わったのにそれを使う一部のコードを再ビルドしないってこと？
> そこでふと思ったのですが
> （中略）
> アリでしょうか? （b へアクセスするときのクラッシュを防げるでしょうか?）
ありかも知れんが、なんでそんな前近代的なやり方しないといけないのかを考えたほうがいいと思う
814:デフォルトの名無しさん
21/08/01 03:13:38.20 /oR3uo3Y.net
C++ポケットリファレンス読んだ方いらっしゃいますか?
独習C++ 詳説 C++ 第2版の次に読もうかと思ってるのですが
815:デフォルトの名無しさん
21/08/02 10:21:16.05 WSe94FPO.net
近年の現場と言うか、
大手の製品開発や比較的規模の大きい案件とかで使われてるC++のバージョンってどの辺ですか？
未だにC++03ってわけないですよね？
816:デフォルトの名無しさん
21/08/02 10:29:43.05 WSe94FPO.net
>>786
C++プログラミング言語自体の研究という訳ではないのなら、
入門書以降は何か作る系の書籍のほうが良いのではないでしょうか？
物理シミュレーションだったりゲームだったり
人工知能だったりOSだったり様々あると思うので、
興味のある分野を極めていくのが良いと思います。
作りたいものがあるが何から手を付けて良いか分からないのなら
設計理論系の書籍等も良いと思います。
OOPを極めたいという考えであるならデザインパターン等も良いと思います。
817:デフォルトの名無しさん
21/08/02 10:37:42.71 dQnVwxld.net
どの道、
class C { A* a; };
と、ポインターに変えても、
class A { char *p1; char *p2; };
と、新しいメンバーp2 には、C を再コンパイルしないとアクセスできない
818:デフォルトの名無しさん
21/08/02 11:23:37.60 lIzbW3kq.net
class A;
class C { A* a; }; だけで完結してるなら まぁ問題をおこしにくそうではあるけど
そこまでして C に関わるコンパイルを止めたい理由がわからん
819:デフォルトの名無しさん
21/08/03 10:56:52.82 Ljn/RAt1.net
>>787
最低でも C++11
それでも古いと思う
820:デフォルトの名無しさん
21/08/09 22:11:24.65 PKIz3Xw3.net
C++って競プロ以外に何に向いてるの？なんで競プロに使われるの？
821:はちみつ餃子
21/08/10 01:15:34.32 7+xjomdk.net
>>792
実行速度が速いことが多いから速度が評価の一部である以上は有利になる。
(速ければ速いほど良いというわけではないが、上限が設定されているのが普通)
822:デフォルトの名無しさん
21/08/11 12:58:25.34 MU7UJMps.net
std::map<std::pair<const char *, int> > hoge;
のように const char * を key とするとき
hoge.insert(std::make_pair("A", 41));
hoge.insert(std::make_pair("C", 43));
hoge.insert(std::make_pair("B", 42));
と追加すると
hoge["C"] で 43 が得られると期待できますが
このとき make_pair したときの "C" と hoge["C"] の "C" のポインタは値が違ってても
同一 key とみなされますか？(ポインタの値ではなく文字の中身の一致を見てくれますか？)
あるいは char * だとまた変わりますか？
823:デフォルトの名無しさん
21/08/11 13:12:29.99 Z6PNV5dP.net
ポインターは先頭アドレス
2つのオブジェクトの内容が同じでも、
別々のオブジェクトなら、ポインターも異なる
ポインターが同じとは、同一のオブジェクトを指している場合だけ
824:デフォルトの名無しさん
21/08/11 13:28:06.66 MU7UJMps.net
追伸
一つの fuga.cpp 内で
二か所以上で "C" が使用されていたとき
同じアドレスにしてくれる機能もあるみたいですが
fuga.cpp と hage.cpp みたいに別のソースで
それぞれ "C" を使ってたりすると
勝手に同じアドレスにしてくれたりはないみたいで
いろいろトラブルのもとになりそうです
(どっちみち変数になってると手も足も出ませんし)
key は std::string にしておくか
あるいは
std::hash<>
と
std::equal_to<>
を定義して自分で比較する方が安全な模様
825:デフォルトの名無しさん
21/08/11 13:42:41.83 EWMgwFeS.net
>>796
「あるいは」以降ってunordered_mapの話じゃないかい
mapならstd::less<>を定義する……というかデフォルトのstd::less<>が使われないようにユーザ定義比較関数をコンストラクタで渡す
俺もこういう場合はキーにstd::string使うからいいけども
826:デフォルトの名無しさん
21/08/11 14:06:43.19 MU7UJMps.net
今回の問題は
>一つの fuga.cpp 内で二か所以上で "C" が使用されていたとき同じアドレスにしてくれる機能もあるみたいですが
>fuga.cpp と hage.cpp みたいに別のソースでそれぞれ "C" を使ってたりすると勝手に同じアドレスにしてくれたりはないみたいで
これでした
stringにしたら解決です
ほんとうにありがとうございました
827:デフォルトの名無しさん
21/08/11 14:27:08.48 01hIEDa4.net
>>798 別のソースでも同じアドレスにしてくれることあるよ。
828:はちみつ餃子
21/08/11 14:56:20.07 QcAq7ivU.net
言語仕様上は内容が同じ文字列リテラルを統合するかどうかは処理系定義。
URLﾘﾝｸ(timsong-cpp.github.io)
829:デフォルトの名無しさん
21/08/12 23:28:31.22 sg4QisCT.net
>>ってどのように言えばいい？
だいなり、だいなり
？？？
830:はちみつ餃子
21/08/13 00:46:25.67 BE9FMbqU.net
>>801
トークンとしての名前は無いと思う。
演算子としての名前なら右シフト演算子とか、
iostream 的な用途の場合は抽出演算子とも言う。
831:デフォルトの名無しさん
21/08/13 15:49:32.03 ZZGdeLtF.net
insertion/extraction operatorっていうのか。
stream operatorだと思ってたわ
832:はちみつ餃子
21/08/13 16:31:09.36 BE9FMbqU.net
>>802-803
念のために仕様書を見直して見たら抽出子 (extractor) だったわ。
833:デフォルトの名無しさん
21/08/21 20:09:51.28 7GAoG1Iq.net
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています
Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しでView types参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ
なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？
Nimの実験的特徴
著者： アンドレアス・ルンプ
バージョン： 1.5.1
URLﾘﾝｸ(nim-lang.github.io)
Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、Cのソースコードを吐き出せるのでC言語でリモートワークされ
ている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる
「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます
834:デフォルトの名無しさん
21/08/22 10:20:28.75 0Cz6ueFz.net
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています
Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ
なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？
Nimの実験的特徴
著者： アンドレアス・ルンプ
バージョン： 1.5.1
URLﾘﾝｸ(nim-lang.github.io)
Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる
「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます
835:デフォルトの名無しさん
21/08/22 10:29:54.67 0Cz6ueFz.net
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています
Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます
Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ
なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？
Nimの実験的特徴 バージョン1.5.1
URLﾘﾝｸ(nim-lang.github.io)
第二プログラミング言語として Rust はオススメしません Nim をやるのです
URLﾘﾝｸ(wolfbash.hateblo.jp)
Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる
「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます