【初心者歓迎】C/C++室 Ver.106【環境依存OK】

**デフォルトの名無しさん** · 2020/07/13(月) 13:51:48.09

エスケープシーケンスやWin32APIなどの環境依存なものもOK
そのような質問は必ず環境を書きましょう
半角空白やタブでのインデントはスレに貼ると無くなります

コードを貼れる所
http://codepad.org/
https://ideone.com/

前スレ
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1556142878/

**デフォルトの名無しさん** · 2021/07/10(土) 08:27:22.56

>>734
いや、先に読んだだけっていっても、例えば
i f (v==1)
みたいな条件式を評価した段階では1だったけど、その先で急に2に変わった、とかだったらまずいだろw

**デフォルトの名無しさん** · 2021/07/10(土) 08:34:33.02

質問者の文言が

>単にスレッドが変数の値を読みに行った瞬間の値を知りたいだけ

>読みに行った瞬間の値を知りたいだけ

なので必要なし
以上

**デフォルトの名無しさん** · 2021/07/10(土) 08:39:13.41

>>742
何もまずくないだろ…

**デフォルトの名無しさん** · 2021/07/10(土) 08:48:41.36

>>744
ifの中ではもう一度vの値を読んだときには2になってたりするわけよ
vが1の前提で書いたコードの中に2を突っ込んだらまずいよ

**デフォルトの名無しさん** · 2021/07/10(土) 09:11:07.28

>もう一度vの値を読んだとき

まずいのはこっちであって>>742のifや>>733自体は問題ないんでは。

**デフォルトの名無しさん** · 2021/07/10(土) 09:15:23.13

質問者が言ってないことに加えて勝手に仮定を追加してまずいとか言ってる>>745はもう黙ってほしい

**デフォルトの名無しさん** · 2021/07/10(土) 09:51:11.89

まずいのは>>745の頭だったというオチw

**はちみつ餃子** ◆8X2XSCHEME · 2021/07/10(土) 09:56:52.21

>>730
結論から言うとロックは必要。
同一のメモリに対するアクセスの少なくとも一方が書き込みである場合には衝突すると定義されている。
https://timsong-cpp.github.io/cppwp/n3337/intro.multithread#4
その場合にはデータ競合が発生する。
https://timsong-cpp.github.io/cppwp/n3337/intro.multithread#21

同時に起こりうるアクセスの内でひとつでも書き込みが存在したらそれはデータ競合の可能性があるってこと。

ミューテックスはミューテックスの所有権を取り合うことで競合を阻止する仕組み。
ロックというのは「ミューテックスをロックする (ロックしている間は自分がミューテックスの所有権を持っている)」
ということであって、対象となるデータそのもののアクセスを直接的に制御してるわけじゃないので、
書き込み側でロックするだけでは意味がない。

**デフォルトの名無しさん** · 2021/07/10(土) 10:17:52.46

>>749
at least one of which is not atomic
の意味ぐらいは理解してからレスしなよ

**デフォルトの名無しさん** · 2021/07/12(月) 08:43:59.78

>>749
質問者は衝突しても問題ないケースで排他は必要かどうかを聞きたいんだろ

**デフォルトの名無しさん** · 2021/07/12(月) 12:14:53.15

「衝突しても問題ない」＆atomicも使わない＝「データ競合となっても問題ない」＝「動作が未定義でも問題ない」なら
確かにロックは不要だけど。

**730** · 2021/07/12(月) 15:19:59.68

730です、どうもお騒がさせしております。
どうやら読み出しだけのときも基本的にはミューテックスを使うべきのようですね。

私の場合は域変数をカウンタとして使っていてその値をログ出力する、というような状況で、
なんとなくミューテックなしでもいいかと思ったのですが、ミューテックスを使わない場合は
気持ち悪い値がプリントされている感じですかね。
一般的な状況では、ミューテックスを使わなくても実害がないかを考えるよりはちゃんと
ミューテックスを使った方がよさそうですね...

**デフォルトの名無しさん** · 2021/07/13(火) 17:41:58.36

「今値を書いてるから　書き終わるまで待て」と待たす相手は
次にそこへ書き込むヤツだけじゃなく
そこを読込もうとしたヤツも対象にしとけば　ちゃんと書き終わった値が読込める
中途半端に書いてる最中であっても意図的に抜き出したいのなら　書き終わるまで待たずに読む

そしてみゅーてっくすの激しい握り合い

**デフォルトの名無しさん** · 2021/07/13(火) 19:15:08.97

>>753
単純なカウンタみたいなアトミックに読み書きできるような変数なら排他は不要だよ

**デフォルトの名無しさん** · 2021/07/13(火) 20:10:22.43

>>755 なんでそんな嘘を教えようとするの？

**デフォルトの名無しさん** · 2021/07/13(火) 20:55:03.74

>>756
>>749のリンク先読めばわかると思うけど競合が発生して結果が未定義になるのは
> at least one of which is not atomic
のケースね

**デフォルトの名無しさん** · 2021/07/13(火) 21:33:13.25

>>757
そこで言ってる "atomic" の意味は std::atomic<int> ならOKで int はダメという話なんだけど、
「単純なカウンタみたいなアトミックに読み書きできるような変数」って言い換えちゃったらどっちもOKに読めちゃうでしょ。

**デフォルトの名無しさん** · 2021/07/13(火) 21:39:13.87

>>758
intがダメなのは>>741みたいなケースね
> 「単純なカウンタみたいなアトミックに読み書きできるような変数」
でだめだと言うなら実例教えて

**デフォルトの名無しさん** · 2021/07/13(火) 22:40:14.76

単純なカウンタがアトミックに読み書きできるかは
基本型の宣言だけではわからんから
アトミック化の指示ができるならやっとけ　ということでいいんでないの？

**デフォルトの名無しさん** · 2021/07/13(火) 22:49:59.37

>>760
そのスタンスでいいと思うよ
俺はアトミックに読み書きできるケースなのに嘘とか言ってる>>756がなんか特殊なケースを知ってるのかな？って思ってるだけ

**デフォルトの名無しさん** · 2021/07/13(火) 23:59:32.08

指示ができない場合にはアトミックに操作できる保証なんてないから
排他したほうがいいぜって立場

**デフォルトの名無しさん** · 2021/07/14(水) 00:44:44.53

>>759
生の int に複数スレッドから排他なしでアクセスしてたらその時点で未定義動作＝ダメなんだってば。
未定義動作となる場合に必ず期待に反するコードが生成されるわけでもないんで、実例を出せというのも意味が無い。
（実例が無いからといって「敢えて」未定義動作に誘導するというのは意味が無いどころか有害。）

・・・スレッドサニタイザで引っかかってウザい、とか言えば「実例」として納得してくれるの？

**デフォルトの名無しさん** · 2021/07/14(水) 01:04:57.94

生のintへのアクセスがアトミックに行えるかって処理系が保証したりしないのけ

**デフォルトの名無しさん** · 2021/07/14(水) 05:39:14.15

https://stackoverflow.com/questions/35226128/are-c-c-fundamental-types-atomic

**デフォルトの名無しさん** · 2021/07/14(水) 06:51:23.81

>>764
保証してる処理系なら std::atomic<int> でオーバーヘッドは生じない、つまり排他は要らんってことでしょ
>>756がなんか実例知ってるかと思ってたけど単なる規格厨だったなw

**デフォルトの名無しさん** · 2021/07/14(水) 12:49:26.09

>>766
オーバーヘッドが生じるかどうかで考えてるなら（それもおかしいんだけど）、こんな例を見れば考えを改めてくれたりするの？
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

**デフォルトの名無しさん** · 2021/07/14(水) 18:54:32.14

>>767
それメモリーバリアの話で排他の話じゃないけど、何を言いたいの？w

**デフォルトの名無しさん** · 2021/07/14(水) 19:20:02.20

>>768
766 が「オーバーヘッドは生じない」ならば「排他は要らん」という論理らしいので
「オーバーヘッドは生じない」を否定すれば「排他は要らん」とかいう嘘を言わなくなってくれるかなと思って書いてみた。
オーバヘッドの発生と排他の要・不要とが 766 の頭の中でどう繋がってるのかは知らない。

**デフォルトの名無しさん** · 2021/07/14(水) 19:25:42.08

>>769
まあメモリーバリアも一種のオーバーヘッドと言えなくもないがそういう話でないことぐらいはわかりそうなもんだけどねw
で、排他が必要な例は見つかったの？

**デフォルトの名無しさん** · 2021/07/14(水) 20:14:07.80

>>770
ごめんよ。元から意味が分からなかったところ「オーバーヘッド」の意味が何か文字通りの意味じゃなかった
みたいだし、もうどういう話なのかさっぱりだわ。
767 の「オーバーヘッド」が何を指すのか、それと排他の要・不要との繋がりがわかるようだったら解説よろしく。

「排他が必要な例」と言われても、こっちとしては複数スレッドで生の int を読み書きするなら
常に排他が必要という認識なんで文字通り「排他が必要な例」なら無数にあるんだよね。
そういうのを挙げても謎理論で「不要だろ」とか「コレジャナイ」って言うだけで話は進まなさそう。

ここまでの流れを読めば >>755 をうっかり信じちゃう人もいないだろうし、もう放置でいいかなという気になってる。

**デフォルトの名無しさん** · 2021/07/14(水) 20:22:20.00

>>771
あえて指摘しなかったけどstd::atomicでは既定のメモリーオーダーがseq_cstであることを知らんのか？
自分で「あんたの言うオーバーヘッド」かかる書き方してオーバーヘッドかかるから排他ガーとか意味不明なんですけど？w
そもそもstd::atomicは必ず排他かかるわけでもないし人を嘘つき呼ばわりするならもう少し勉強した方が恥をかかなくて済むと思うよ

**デフォルトの名無しさん** · 2021/07/14(水) 20:35:16.14

>>772
ごめんそれは知ってるよ。でもそれを知ってる知識レベルの人が >755 のような主張をしてるとは思わなかったんだ。
あと繰り返しだけど「オーバーヘッドかかるから排他ガー」とか言ってるのは >766 だけね。意味不明なのには同意する。
「std::atomicは必ず排他かかるわけでもない」は正しいけど、それと >755 が嘘であることに関係は無い。

**デフォルトの名無しさん** · 2021/07/14(水) 22:17:32.53

>>773
> ごめんそれは知ってるよ。
えっ？
知ってて>>767ってそれこそ意味不明なんですけどw
結局何を言いたかったの？

> あと繰り返しだけど「オーバーヘッドかかるから排他ガー」とか言ってるのは >766 だけね。
ああマジで日本語の理解力がないのね
（もちろん環境によるけど）std::atomic使っても生のintと同じようにアクセスできる = 排他なんてしてない
って話ね
念の為に言っておくけど>>764が言うようなハード上の排他制御は別の話ね

> 意味不明なのには同意する。
同意なんていらんから>>767を書いた意味を説明してよ

> 「std::atomicは必ず排他かかるわけでもない」は正しいけど、それと >755 が嘘であることに関係は無い。
嘘だと言うなら根拠を示したほうが良いと思うよ
まあ示せないからグダグダ言うとか関係の無いメモリーオーダーの話とかにそらそうとしてるんだろうけど…

**デフォルトの名無しさん** · 2021/07/14(水) 23:08:12.27

>>774
「767を書いた意味」なら>>769で説明した。

「環境によるけど）std::atomic使っても生のintと同じようにアクセスできる = 排他なんてしてない」これは正しい。
でもそれは生の int でデータ競合を避けられる理由にはならない。
>>755 が嘘だという根拠は >>749 に挙げられた規定による。その条件
"at least one of which is not atomic" について、生の int へのアクセスは
"not atomic" に該当するから排他なしのアクセスでは未定義動作となりダメだと言っている。
規格文面の "atomic" は、規格が規定する C++ 抽象機械上の概念という認識。

対して 755 は、規格文面の "atomic" は各処理系でのメモリアクセスが実際にアトミックかどうかに依ると考えてそう。
残念ながら規格の文面で明確にその解釈を否定できないんだけど (https://cplusplus.github.io/LWG/issue2506)
少なくとも現メモリモデル策定当時から Web 上に積み上げられている多くの記事（標準化委員会の↑含む）や
現行コンパイラ（最適化、スレッドサニタイザなど）での扱いと合致しない。

**デフォルトの名無しさん** · 2021/07/15(木) 05:14:12.89

>>775
> 「767を書いた意味」なら>>769で説明した。
あああのメモリーバリアと排他の区別もついてないアホ丸出しの説明ねw

> 少なくとも現メモリモデル策定当時から Web 上に積み上げられている多くの記事（標準化委員会の↑含む）や
> 現行コンパイラ（最適化、スレッドサニタイザなど）での扱いと合致しない。
百歩譲ってstd::atomic使えと言うのはいいけど、排他は必須じゃないだろ

**デフォルトの名無しさん** · 2021/07/15(木) 06:52:54.80

charはatomicなの？規格にどれがatomicだってあるの？
どれがatomicかなんて、CPU毎に違って当然だと思ってたわ

**デフォルトの名無しさん** · 2021/07/15(木) 07:50:32.57

>>777
CPU毎と言うかシステム毎に違うだろ

**デフォルトの名無しさん** · 2021/07/15(木) 08:52:46.15

>>776
うん。データ競合を回避するにあたって std::atomic を使えば排他は必須じゃなくなるよ。
ミューテックスを使うなどの排他（順序付け）でも回避できて、どっちかでもいいし両方でもいい。

>>755 が嘘だという点には異論なくなったみたいだね。よかったよかった。

**デフォルトの名無しさん** · 2021/07/15(木) 09:20:51.24

>>775
排他は要らんケースがあると言うだけの話
ちなみに>>755では生intなんて一言も書いてないけどね
std::atomic<int>でも多くの環境では
> 単純なカウンタみたいなアトミックに読み書きできるような変数になるしな

まあ結局規格ガーって言うしかないレベルの低い規格厨が関係のないメモリーバリアーとか出してきて恥を晒しただけだったなw

**デフォルトの名無しさん** · 2021/07/15(木) 10:06:00.17

お前ら暇すぎやろ

**デフォルトの名無しさん** · 2021/07/30(金) 19:50:56.40

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 へアクセスするときのクラッシュを防げるでしょうか?）

**デフォルトの名無しさん** · 2021/07/30(金) 19:57:58.75

pimpl使え

**デフォルトの名無しさん** · 2021/07/30(金) 21:01:43.73

>>782
素直にC.aやC.bをポインタにすりゃいいだけちゃう？

**まあ俺が言うのもなんだがw** · 2021/07/31(土) 22:17:00.01

>>782
クラス定義が変わったのにそれを使う一部のコードを再ビルドしないってこと？

> そこでふと思ったのですが
> （中略）
> アリでしょうか? （b へアクセスするときのクラッシュを防げるでしょうか?）
ありかも知れんが、なんでそんな前近代的なやり方しないといけないのかを考えたほうがいいと思う

**デフォルトの名無しさん** · 2021/08/01(日) 03:13:38.20

C++ポケットリファレンス読んだ方いらっしゃいますか?
独習C++ 詳説 C++ 第2版の次に読もうかと思ってるのですが

**デフォルトの名無しさん** · 2021/08/02(月) 10:21:16.05

近年の現場と言うか、
大手の製品開発や比較的規模の大きい案件とかで使われてるC++のバージョンってどの辺ですか？
未だにC++03ってわけないですよね？

**デフォルトの名無しさん** · 2021/08/02(月) 10:29:43.05

>>786
C++プログラミング言語自体の研究という訳ではないのなら、
入門書以降は何か作る系の書籍のほうが良いのではないでしょうか？
物理シミュレーションだったりゲームだったり
人工知能だったりOSだったり様々あると思うので、
興味のある分野を極めていくのが良いと思います。
作りたいものがあるが何から手を付けて良いか分からないのなら
設計理論系の書籍等も良いと思います。
OOPを極めたいという考えであるならデザインパターン等も良いと思います。

**デフォルトの名無しさん** · 2021/08/02(月) 10:37:42.71

どの道、

class C { A* a; };
と、ポインターに変えても、

class A { char *p1; char *p2; };
と、新しいメンバーp2 には、C を再コンパイルしないとアクセスできない

**デフォルトの名無しさん** · 2021/08/02(月) 11:23:37.60

class A;
class C { A* a; }; だけで完結してるなら　まぁ問題をおこしにくそうではあるけど
そこまでして C に関わるコンパイルを止めたい理由がわからん

**デフォルトの名無しさん** · 2021/08/03(火) 10:56:52.82

>>787
最低でも C++11
それでも古いと思う

**デフォルトの名無しさん** · 2021/08/09(月) 22:11:24.65

C++って競プロ以外に何に向いてるの？なんで競プロに使われるの？

**はちみつ餃子** ◆8X2XSCHEME · 2021/08/10(火) 01:15:34.32

>>792
実行速度が速いことが多いから速度が評価の一部である以上は有利になる。
(速ければ速いほど良いというわけではないが、上限が設定されているのが普通)

**デフォルトの名無しさん** · 2021/08/11(水) 12:58:25.34

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 * だとまた変わりますか？

**デフォルトの名無しさん** · 2021/08/11(水) 13:12:29.99

ポインターは先頭アドレス

2つのオブジェクトの内容が同じでも、
別々のオブジェクトなら、ポインターも異なる

ポインターが同じとは、同一のオブジェクトを指している場合だけ

**デフォルトの名無しさん** · 2021/08/11(水) 13:28:06.66

追伸
一つの fuga.cpp 内で
二か所以上で "C" が使用されていたとき
同じアドレスにしてくれる機能もあるみたいですが
fuga.cpp と hage.cpp みたいに別のソースで
それぞれ "C" を使ってたりすると
勝手に同じアドレスにしてくれたりはないみたいで
いろいろトラブルのもとになりそうです
(どっちみち変数になってると手も足も出ませんし)
key は std::string にしておくか
あるいは
std::hash<>
と
std::equal_to<>
を定義して自分で比較する方が安全な模様

**デフォルトの名無しさん** · 2021/08/11(水) 13:42:41.83

>>796
「あるいは」以降ってunordered_mapの話じゃないかい
mapならstd::less<>を定義する……というかデフォルトのstd::less<>が使われないようにユーザ定義比較関数をコンストラクタで渡す

俺もこういう場合はキーにstd::string使うからいいけども

**デフォルトの名無しさん** · 2021/08/11(水) 14:06:43.19

今回の問題は
>一つの fuga.cpp 内で二か所以上で "C" が使用されていたとき同じアドレスにしてくれる機能もあるみたいですが
>fuga.cpp と hage.cpp みたいに別のソースでそれぞれ "C" を使ってたりすると勝手に同じアドレスにしてくれたりはないみたいで
これでした
stringにしたら解決です
ほんとうにありがとうございました

**デフォルトの名無しさん** · 2021/08/11(水) 14:27:08.48

>>798 別のソースでも同じアドレスにしてくれることあるよ。

**はちみつ餃子** ◆8X2XSCHEME · 2021/08/11(水) 14:56:20.07

言語仕様上は内容が同じ文字列リテラルを統合するかどうかは処理系定義。
https://timsong-cpp.github.io/cppwp/n3337/lex.string#12

**デフォルトの名無しさん** · 2021/08/12(木) 23:28:31.22

>>ってどのように言えばいい？

だいなり、だいなり
？？？

**はちみつ餃子** ◆8X2XSCHEME · 2021/08/13(金) 00:46:25.67

>>801
トークンとしての名前は無いと思う。
演算子としての名前なら右シフト演算子とか、
iostream 的な用途の場合は抽出演算子とも言う。

**デフォルトの名無しさん** · 2021/08/13(金) 15:49:32.03

insertion/extraction operatorっていうのか。
stream operatorだと思ってたわ

**はちみつ餃子** ◆8X2XSCHEME · 2021/08/13(金) 16:31:09.36

>>802-803
念のために仕様書を見直して見たら抽出子 (extractor) だったわ。

**デフォルトの名無しさん** · 2021/08/21(土) 20:09:51.28

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しでView types参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴
著者：アンドレアス・ルンプ
バージョン： 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、Cのソースコードを吐き出せるのでC言語でリモートワークされ
ている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

**デフォルトの名無しさん** · 2021/08/22(日) 10:20:28.75

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴
著者：アンドレアス・ルンプ
バージョン： 1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

**デフォルトの名無しさん** · 2021/08/22(日) 10:29:54.67

Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

Nimはバージョン1.5.1でRustのボローチェッカーに似た「View types」が実装されれば、
GC無しのView typesで参照の有効性を検証することによってメモリ安全性を保証しつつ
限りなく抑え込まれたタイプ量で高速化したCのソースコードを吐き出せます

Nimソースコード ==nimコンパイラ==> Cソースコード ==Cコンパイラ==> バイナリ

なので、nimコンパイラが通った時点でメモリ安全性が担保されませんか？

Nimの実験的特徴バージョン1.5.1
http://nim-lang.github.io/Nim/manual_experimental.html

第二プログラミング言語として Rust はオススメしません Nim をやるのです
https://wolfbash.hateblo.jp/entry/2017/07/30/193412

Nimは限りなく抑え込まれたタイプ量で高い生産性とPythonのような高い可読性を実現し
ているにもかかわらず、高速なCのソースコードを吐き出せるのでC言語でリモートワーク
されている方は割り振られた仕事が早く終わっても終わってないふりをして怠けることができる

「怠け者とはこうあるべきだ！」と言うとても大事な事を Nim は我々に教えてくれます

**デフォルトの名無しさん** · 2021/08/22(日) 12:34:32.34

怠け者が一生懸命２回書き込んじゃうのか

**デフォルトの名無しさん** · 2021/08/22(日) 13:21:27.56

unordered_map で erase(key) を実行した場合
要素のデストラクタは呼ばれるのでしょうか？
必ず自分で呼ばないとだめ？
あるいは勝手に呼んでくれるオプションとかある？

**デフォルトの名無しさん** · 2021/08/22(日) 13:38:27.67

呼ばれるよ。そうじゃないと危なすぎるでしょ。

**デフォルトの名無しさん** · 2021/08/22(日) 13:51:18.62

つまり
unordered_map<hoge, fuga *>
みたいなときって
fuga *f があるとすると
delete f されるっていう認識で OK?

**デフォルトの名無しさん** · 2021/08/22(日) 13:56:28.38

ポインタ型のデストラクタは基本的に何もしない。
デストラクタで破棄したいならunique_ptrなどスマポを使う。

**ハノン** ◆QZaw55cn4c · 2021/08/22(日) 15:55:44.42

>>809
つ　https://ideone.com/zKMtPs

**ハノン** ◆QZaw55cn4c · 2021/08/22(日) 16:00:15.54

>>811
つ　https://ideone.com/AIykVF

**ハノン** ◆QZaw55cn4c · 2021/08/22(日) 18:24:32.36

>>813
>>809
ユーザー定義のハッシュ関数を std 名前空間に押し込むのはお行儀が悪いよね…‥
https://ideone.com/J5JYnG

**はちみつ餃子** ◆8X2XSCHEME · 2021/08/22(日) 21:31:04.10

>>815
文字列リテラルを char* にキャストするほうがだいぶん行儀が悪いと思うよ。

**ハノン** ◆QZaw55cn4c · 2021/08/22(日) 22:10:22.39

>>816
しかし、MyStr のコンストラクタの引数が std::string とか、もう何やっているのかわからなくなる‥‥

**はちみつ餃子** ◆8X2XSCHEME · 2021/08/22(日) 22:21:02.88

>>817
？？？
const char* で受ければいいだけでしょ？
なんでそこで std::string が出てくるの？

**ハノン** ◆QZaw55cn4c · 2021/08/22(日) 22:23:59.15

>>818
そういう意味でしたか、const に対する注意力がまだ足りないのは私の課題ですね

**デフォルトの名無しさん** · 2021/08/23(月) 11:12:35.74

linuxのg++8.3でstd::stringのメンバ関数の
insert(const_iterator, char)を使うとコンパイルが通らないのですが、バグでしょうか？
-std=gnu++1zつけてます。

**デフォルトの名無しさん** · 2021/08/23(月) 12:30:44.70

>>820
具体的に問題を再現するコードとエラーメッセージを書いて。

**デフォルトの名無しさん** · 2021/08/23(月) 14:00:01.42

>>819
草生えたｗ

**デフォルトの名無しさん** · 2021/08/24(火) 09:47:42.50

>>821
こんな感じです。
g++のバージョンは8.3で-std=gnu++1z でコンパイルしています。

-- ソースファイル
#include <string>
int main(int argc, char** argv) {
std::string str="abcd";
std::string::const_iterator it = str.cend();
str.insert(it, 'a');
return 0;
}

-- エラーメッセージ
testinsert.cpp: In function ‘int main(int, char**)’:
testinsert.cpp:6:21: error: no matching function for call to ‘std::basic_string<char>::insert(std::basic_string<char>::const_iterator&, char)’
str.insert(it, 'a');
^
In file included from /opt/rh/devtoolset-8/root/usr/include/c++/8/string:52,
from testinsert.cpp:1:
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/basic_string.h:4419:7: note: candidate: ‘void std::basic_string<_CharT, _Traits, _Alloc>::insert(std::basic_string<_CharT, _Traits, _Alloc>::iterator, std::basic_string<_CharT, _Traits, _Alloc>::size_type, _CharT) [with _CharT = char; _Traits = std::char_traits<char>; _Alloc = std::allocator<char>; std::basic_string<_CharT, _Traits, _Alloc>::iterator = __gnu_cxx::__normal_iterator<char*, std::basic_string<char> >; typename _Alloc::rebind<_CharT>::other::pointer = char*; std::basic_string<_CharT, _Traits, _Alloc>::size_type = long unsigned int]’
insert(iterator __p, size_type __n, _CharT __c)
^~~~~~

**デフォルトの名無しさん** · 2021/08/24(火) 12:50:48.93

>>823
コンパイルできないのはバグだが終端イテレータの扱いについては
変遷があって有効なイテレータと見做されない時期もあった。
最後に文字をくっつけるのであれば push_back か append を使ったほうが無難。

**デフォルトの名無しさん** · 2021/08/24(火) 14:09:58.40

>>824
> 終端イテレータの扱いについては
> 変遷があって有効なイテレータと見做されない時期もあった。
要出典

**デフォルトの名無しさん** · 2021/08/25(水) 14:20:52.77

>>824
アドバイスありがとうございます。
やっぱり規格的におかしいと思って調べてみたところコンパイラがc++11に対応していないだけでした。
ありがとうございました

**デフォルトの名無しさん** · 2021/08/25(水) 15:38:43.16

コンパイラはver.4.8で対応してるよ
gnu++1zてのがないんじゃないの？

**デフォルトの名無しさん** · 2021/08/25(水) 17:29:41.65

const_iteratorだとダメでiteratorだと通るぽい

↓のコード、手持ちのg++ (GCC) 7.3.1で-std=gnu++1zでコンパイル、実行できたが
https://cpprefjp.github.io/reference/string/basic_string/insert.html
「(6) 指定したイテレータが指す要素の前に、文字を挿入する」の
s.insert(s.begin(), 'b');
を
s.insert(s.cbegin(), 'b');
にするとコンパイルエラーになる

**デフォルトの名無しさん** · 2021/08/25(水) 19:02:32.36

C++を勉強しているんだけど難しすぎる。
目標は研究に使う数値計算ライブラリを作ることでそのために、
オブジェクト指向とテンプレートプログラミングとSTLを勉強しているんだけど量が多すぎて発狂しそう。
本当にC++を仕事で使っている人はこの量の仕様を覚えて使いこなしてるのか・・・

**デフォルトの名無しさん** · 2021/08/25(水) 19:16:48.44

基本的に自分がよく使う範囲だけ覚えて
必要があればそれ以外の範囲を調べて使う
膨大なようで、所詮言語だから使ってれば覚える

**デフォルトの名無しさん** · 2021/08/25(水) 19:55:14.87

生半可に上辺だけ触って判った気になって
コード描けますとかいうやつと仕事したくないわ

**デフォルトの名無しさん** · 2021/08/25(水) 21:53:18.83

>>827
>>828
言葉足らずですみません。
CentOS7のdevtoolのg++はABI互換性の関係から古いlibstdc++としかリンクできないようにされていて
つまるところC++11の機能はほとんど使えなくなっている、ということでした。
本来ver8.3ならC++17にも対応しているはずなのにほとんど意味ないわけです…。
だったら-std=c++11とかつけたときに警告してくれとでも思わないわけもないですが。

**デフォルトの名無しさん** · 2021/08/25(水) 23:11:46.20

>>829
もしEigenとかみたいなメタプログラミング使った数値計算ライブラリを考えてるならやめとけ
無駄に開発期間が数倍から10倍程度に膨れ上がるだけ

とりあえずテンプレートとか使わずに(あるいはメタじゃないレベルにおさえて)普通に書いたら？

**デフォルトの名無しさん** · 2021/08/26(木) 06:13:02.19

>>829
仕事をすると言っても、他の人がこさえたライブラリを使う場合はそこまでは求められんだろう。
反対に根っこ部分のライブラリとか、チーム内でのルールに関わると知識と経験がいるんじゃないかな？

よく理解できている方法でしっかり組み立てられるようになってから、徐々に細かい話に手を出したらいいと思う。
他の方法は解ってるし悪いわけでもないが、記述が気に入らないので延々とtemplate弄り倒す沼もあるから注意してね。

**デフォルトの名無しさん** · 2021/08/26(木) 09:00:20.61

数値計算に使うのならまずはSTL抑えておくだけでいいんじゃね？
C++言語自体の習得より、GPGPU、分散処理、SIMD、メモリ管理とかのノウハウ習得にまずは時間を割り当てるほうがよいと思う

**デフォルトの名無しさん** · 2021/08/26(木) 09:28:17.30

物理の計算とか、いろんな数学的な量が出てくるけど、そういうのの演算がすべて
プログラム上では同じ形で書ければかっこいいなあと思ったり。
例えば、（スカラー）積なら、オペランドが実数、虚数、ベクトル、行列、テンソル....等々どれでも
乗算オペレーターで扱えるとか。
「普通」の数値ライブラリだとオペランド毎に積を扱う関数がうんざりするほどあってそれを適切に
選ばないといけなかったりするので。

**デフォルトの名無しさん** · 2021/08/26(木) 12:08:14.60

829です。
皆さんいろいろとアドバイスありがとうございます。

自分が作ろうと思っているのは、Eigenを用いた金融系の数値計算ライブラリなのですが、テンプレートを用いたらいろいろな型を代入できて便利かな〜くらいの感じで作ろうとしていました。

templateの使い方自体は少し勉強してみましたが、メタプログラミングの概念自体もよくわかっていないので、ひとまずtemplateは後回しにしようかと思います。

オブジェクト指向で書くかどうかは実際にコードを書いてみてから考えてみたいと思います。

**デフォルトの名無しさん** · 2021/08/26(木) 16:35:43.38

Eigen利用するだけか
それならまぁ無駄に時間かかるということも無いと思う(変なとこに拘らなければ

**デフォルトの名無しさん** · 2021/08/26(木) 16:43:57.74

>>836
コンピューターというか主要な高級プログラミング言語が出来て50年以上経つが
だれもそういうことをやってないのは何故だと思う？

**デフォルトの名無しさん** · 2021/08/26(木) 16:45:12.60

ちなみに SciPy とか SymPy は良く出来てる方

**デフォルトの名無しさん** · 2021/08/27(金) 14:40:33.39

>>839
template使ったらもう型にとらわれなくていいんじゃね？はC++学習者の必ず通る道やからしゃーない