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

[過去ﾛｸﾞ] 【初心者歓迎】C/C++室 Ver.106【環境依存OK】 (1002ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

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

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

755(7): 2021/07/13(火)19:15 ID:Cs3wNevb(1/4) AAS
>>753
単純なカウンタみたいなアトミックに読み書きできるような変数なら排他は不要だよ

756(3): 2021/07/13(火)20:10 ID:+UxqO86S(1/2) AAS
>>755 なんでそんな嘘を教えようとするの？

757(1): 2021/07/13(火)20:55 ID:Cs3wNevb(2/4) AAS
>>756
>>749のリンク先読めばわかると思うけど競合が発生して結果が未定義になるのは
> at least one of which is not atomic
のケースね

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

759(1): 2021/07/13(火)21:39 ID:Cs3wNevb(3/4) AAS
>>758
intがダメなのは>>741みたいなケースね
> 「単純なカウンタみたいなアトミックに読み書きできるような変数」
でだめだと言うなら実例教えて

760(1): 2021/07/13(火)22:40 ID:31Jksjnm(1/2) AAS
単純なカウンタがアトミックに読み書きできるかは
基本型の宣言だけではわからんから
アトミック化の指示ができるならやっとけ　ということでいいんでないの？

761: 2021/07/13(火)22:49 ID:Cs3wNevb(4/4) AAS
>>760
そのスタンスでいいと思うよ
俺はアトミックに読み書きできるケースなのに嘘とか言ってる>>756がなんか特殊なケースを知ってるのかな？って思ってるだけ

762: 2021/07/13(火)23:59 ID:31Jksjnm(2/2) AAS
指示ができない場合にはアトミックに操作できる保証なんてないから
排他したほうがいいぜって立場

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

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

764(2): 2021/07/14(水)01:04 ID:b90ql0x3(1) AAS
生のintへのアクセスがアトミックに行えるかって処理系が保証したりしないのけ

765: 2021/07/14(水)05:39 ID:dtsN+T48(1) AAS
外部ﾘﾝｸ:stackoverflow.com

766(3): 2021/07/14(水)06:51 ID:3FmZNcD6(1) AAS
>>764
保証してる処理系なら std::atomic<int> でオーバーヘッドは生じない、つまり排他は要らんってことでしょ
>>756がなんか実例知ってるかと思ってたけど単なる規格厨だったなw

767(2): 2021/07/14(水)12:49 ID:pCGEFvrX(2/6) AAS
>>766
オーバーヘッドが生じるかどうかで考えてるなら（それもおかしいんだけど）、こんな例を見れば考えを改めてくれたりするの？
外部ﾘﾝｸ:godbolt.org
#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
省3

768(1): 2021/07/14(水)18:54 ID:VBWUb4q7(1/2) AAS
>>767
それメモリーバリアの話で排他の話じゃないけど、何を言いたいの？w

769(3): 2021/07/14(水)19:20 ID:pCGEFvrX(3/6) AAS
>>768
766 が「オーバーヘッドは生じない」ならば「排他は要らん」という論理らしいので
「オーバーヘッドは生じない」を否定すれば「排他は要らん」とかいう嘘を言わなくなってくれるかなと思って書いてみた。
オーバヘッドの発生と排他の要・不要とが 766 の頭の中でどう繋がってるのかは知らない。

770(1): 2021/07/14(水)19:25 ID:VBWUb4q7(2/2) AAS
>>769
まあメモリーバリアも一種のオーバーヘッドと言えなくもないがそういう話でないことぐらいはわかりそうなもんだけどねw
で、排他が必要な例は見つかったの？

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

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

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

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

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

774(1): 2021/07/14(水)22:17 ID:cMMfM4oH(2/2) AAS
>>773
> ごめんそれは知ってるよ。
えっ？
知ってて>>767ってそれこそ意味不明なんですけどw
結局何を言いたかったの？

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

775(2): 2021/07/14(水)23:08 ID:pCGEFvrX(6/6) AAS
>>774
「767を書いた意味」なら>>769で説明した。

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

対して 755 は、規格文面の "atomic" は各処理系でのメモリアクセスが実際にアトミックかどうかに依ると考えてそう。
残念ながら規格の文面で明確にその解釈を否定できないんだけど (外部ﾘﾝｸ:cplusplus.github.io
省2

776(1): 2021/07/15(木)05:14 ID:oWQENBCT(1/3) AAS
>>775
> 「767を書いた意味」なら>>769で説明した。
あああのメモリーバリアと排他の区別もついてないアホ丸出しの説明ねw

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

777(1): 2021/07/15(木)06:52 ID:DRiXJTFv(1) AAS
charはatomicなの？規格にどれがatomicだってあるの？
どれがatomicかなんて、CPU毎に違って当然だと思ってたわ

778: 2021/07/15(木)07:50 ID:oWQENBCT(2/3) AAS
>>777
CPU毎と言うかシステム毎に違うだろ

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

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

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

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

781: 2021/07/15(木)10:06 ID:ux6gJq+a(1) AAS
お前ら暇すぎやろ

782(2): 2021/07/30(金)19:50 ID:VEABT8DF(1) AAS
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 に最初から
省3

783: 2021/07/30(金)19:57 ID:SwFfvD28(1) AAS
pimpl使え

784: 2021/07/30(金)21:01 ID:y9Kee4rz(1) AAS
>>782
素直にC.aやC.bをポインタにすりゃいいだけちゃう？

785: まあ俺が言うのもなんだがw 2021/07/31(土)22:17 ID:m7lSxL/B(1) AAS
>>782
クラス定義が変わったのにそれを使う一部のコードを再ビルドしないってこと？

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

786(1): 2021/08/01(日)03:13 ID:/oR3uo3Y(1) AAS
C++ポケットリファレンス読んだ方いらっしゃいますか?
独習C++ 詳説 C++ 第2版の次に読もうかと思ってるのですが

787(1): 2021/08/02(月)10:21 ID:WSe94FPO(1/2) AAS
近年の現場と言うか、
大手の製品開発や比較的規模の大きい案件とかで使われてるC++のバージョンってどの辺ですか？
未だにC++03ってわけないですよね？

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

789: 2021/08/02(月)10:37 ID:dQnVwxld(1) AAS
どの道、

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

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

790: 2021/08/02(月)11:23 ID:lIzbW3kq(1) AAS
class A;
class C { A* a; }; だけで完結してるなら　まぁ問題をおこしにくそうではあるけど
そこまでして C に関わるコンパイルを止めたい理由がわからん

791: 2021/08/03(火)10:56 ID:Ljn/RAt1(1) AAS
>>787
最低でも C++11
それでも古いと思う

792(1): 2021/08/09(月)22:11 ID:PKIz3Xw3(1) AAS
C++って競プロ以外に何に向いてるの？なんで競プロに使われるの？

793: はちみつ餃子 ◆8X2XSCHEME 2021/08/10(火)01:15 ID:7+xjomdk(1) AAS
>>792
実行速度が速いことが多いから速度が評価の一部である以上は有利になる。
(速ければ速いほど良いというわけではないが、上限が設定されているのが普通)

794: 2021/08/11(水)12:58 ID:MU7UJMps(1/3) AAS
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 * だとまた変わりますか？

795: 2021/08/11(水)13:12 ID:Z6PNV5dP(1) AAS
ポインターは先頭アドレス

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

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

796(1): 2021/08/11(水)13:28 ID:MU7UJMps(2/3) AAS
追伸
一つの fuga.cpp 内で
二か所以上で "C" が使用されていたとき
同じアドレスにしてくれる機能もあるみたいですが
fuga.cpp と hage.cpp みたいに別のソースで
それぞれ "C" を使ってたりすると
勝手に同じアドレスにしてくれたりはないみたいで
いろいろトラブルのもとになりそうです
(どっちみち変数になってると手も足も出ませんし)
key は std::string にしておくか
省5

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

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

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

799: 2021/08/11(水)14:27 ID:01hIEDa4(1) AAS
>>798 別のソースでも同じアドレスにしてくれることあるよ。

800: はちみつ餃子 ◆8X2XSCHEME 2021/08/11(水)14:56 ID:QcAq7ivU(1) AAS
言語仕様上は内容が同じ文字列リテラルを統合するかどうかは処理系定義。
外部ﾘﾝｸ:timsong-cpp.github.io

801(1): 2021/08/12(木)23:28 ID:sg4QisCT(1) AAS
>>ってどのように言えばいい？

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

802(1): はちみつ餃子 ◆8X2XSCHEME 2021/08/13(金)00:46 ID:BE9FMbqU(1/2) AAS
>>801
トークンとしての名前は無いと思う。
演算子としての名前なら右シフト演算子とか、
iostream 的な用途の場合は抽出演算子とも言う。

803(1): 2021/08/13(金)15:49 ID:ZZGdeLtF(1) AAS
insertion/extraction operatorっていうのか。
stream operatorだと思ってたわ

804: はちみつ餃子 ◆8X2XSCHEME 2021/08/13(金)16:31 ID:BE9FMbqU(2/2) AAS
>>802-803
念のために仕様書を見直して見たら抽出子 (extractor) だったわ。

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

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

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

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

Nimの実験的特徴
著者：アンドレアス・ルンプ
省6

806: 2021/08/22(日)10:20 ID:0Cz6ueFz(1/2) AAS
Rustのメモリ安全性はボローチェッカーによって担保されているが、
Nimと比較してRustはタイプ量が多い事により限りなく低い生産性と
C++のような高い難読性、超巨大なバイナリ生成性能を兼ね備えています

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

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

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

Nimの実験的特徴
著者：アンドレアス・ルンプ
省6

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

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

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

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

Nimの実験的特徴バージョン1.5.1
外部ﾘﾝｸ[html]:nim-lang.github.io
省6

808: 2021/08/22(日)12:34 ID:m1rLE8Mc(1) AAS
怠け者が一生懸命２回書き込んじゃうのか

809(2): 2021/08/22(日)13:21 ID:cx6/dnxW(1/2) AAS
unordered_map で erase(key) を実行した場合
要素のデストラクタは呼ばれるのでしょうか？
必ず自分で呼ばないとだめ？
あるいは勝手に呼んでくれるオプションとかある？

810: 2021/08/22(日)13:38 ID:m4vhMo04(1) AAS
呼ばれるよ。そうじゃないと危なすぎるでしょ。

811(1): 2021/08/22(日)13:51 ID:cx6/dnxW(2/2) AAS
つまり
unordered_map<hoge, fuga *>
みたいなときって
fuga *f があるとすると
delete f されるっていう認識で OK?

812: 2021/08/22(日)13:56 ID:M38WAZ3o(1) AAS
ポインタ型のデストラクタは基本的に何もしない。
デストラクタで破棄したいならunique_ptrなどスマポを使う。

813(1): ハノン ◆QZaw55cn4c 2021/08/22(日)15:55 AAS
>>809
つ　外部ﾘﾝｸ:ideone.com

814: ハノン ◆QZaw55cn4c 2021/08/22(日)16:00 AAS
>>811
つ　外部ﾘﾝｸ:ideone.com

815(1): ハノン ◆QZaw55cn4c 2021/08/22(日)18:24 AAS
>>813
>>809
ユーザー定義のハッシュ関数を std 名前空間に押し込むのはお行儀が悪いよね…‥
外部ﾘﾝｸ:ideone.com

816(1): はちみつ餃子 ◆8X2XSCHEME 2021/08/22(日)21:31 ID:YcQtKocs(1/2) AAS
>>815
文字列リテラルを char* にキャストするほうがだいぶん行儀が悪いと思うよ。

817(1): ハノン ◆QZaw55cn4c 2021/08/22(日)22:10 AAS
>>816
しかし、MyStr のコンストラクタの引数が std::string とか、もう何やっているのかわからなくなる‥‥

818(1): はちみつ餃子 ◆8X2XSCHEME 2021/08/22(日)22:21 ID:YcQtKocs(2/2) AAS
>>817
？？？
const char* で受ければいいだけでしょ？
なんでそこで std::string が出てくるの？

819(1): ハノン ◆QZaw55cn4c 2021/08/22(日)22:23 AAS
>>818
そういう意味でしたか、const に対する注意力がまだ足りないのは私の課題ですね

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

821(1): 2021/08/23(月)12:30 ID:gvYYeNdp(1) AAS
>>820
具体的に問題を再現するコードとエラーメッセージを書いて。

822: 2021/08/23(月)14:00 ID:BEPpIG+d(1) AAS
>>819
草生えたｗ

823(1): 2021/08/24(火)09:47 ID:HAU1OEWW(1) AAS
>>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;
省11

824(2): 2021/08/24(火)12:50 ID:MkJE9y3A(1) AAS
>>823
コンパイルできないのはバグだが終端イテレータの扱いについては
変遷があって有効なイテレータと見做されない時期もあった。
最後に文字をくっつけるのであれば push_back か append を使ったほうが無難。

825: 2021/08/24(火)14:09 ID:+43LntiD(1) AAS
>>824
> 終端イテレータの扱いについては
> 変遷があって有効なイテレータと見做されない時期もあった。
要出典

826: 2021/08/25(水)14:20 ID:cqt8yWy6(1) AAS
>>824
アドバイスありがとうございます。
やっぱり規格的におかしいと思って調べてみたところコンパイラがc++11に対応していないだけでした。
ありがとうございました

827(1): 2021/08/25(水)15:38 ID:9jFaPzYS(1) AAS
コンパイラはver.4.8で対応してるよ
gnu++1zてのがないんじゃないの？

828(1): 2021/08/25(水)17:29 ID:+rMtuhpY(1) AAS
const_iteratorだとダメでiteratorだと通るぽい

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

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

830: 2021/08/25(水)19:16 ID:I0Do+yHA(1) AAS
基本的に自分がよく使う範囲だけ覚えて
必要があればそれ以外の範囲を調べて使う
膨大なようで、所詮言語だから使ってれば覚える

831: 2021/08/25(水)19:55 ID:s4bO6YKI(1) AAS
生半可に上辺だけ触って判った気になって
コード描けますとかいうやつと仕事したくないわ

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

833: 2021/08/25(水)23:11 ID:3/bOIe3o(1) AAS
>>829
もしEigenとかみたいなメタプログラミング使った数値計算ライブラリを考えてるならやめとけ
無駄に開発期間が数倍から10倍程度に膨れ上がるだけ

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

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

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

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

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

837: 2021/08/26(木)12:08 ID:p2DPtxMk(1) AAS
829です。
皆さんいろいろとアドバイスありがとうございます。

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

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

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

838(1): 2021/08/26(木)16:35 ID:9wBQWoih(1) AAS
Eigen利用するだけか
それならまぁ無駄に時間かかるということも無いと思う(変なとこに拘らなければ

839(1): 2021/08/26(木)16:43 ID:WPRv8+9f(1/2) AAS
>>836
コンピューターというか主要な高級プログラミング言語が出来て50年以上経つが
だれもそういうことをやってないのは何故だと思う？

840: 2021/08/26(木)16:45 ID:WPRv8+9f(2/2) AAS
ちなみに SciPy とか SymPy は良く出来てる方

841(2): 2021/08/27(金)14:40 ID:RrJjtAzF(1) AAS
>>839
template使ったらもう型にとらわれなくていいんじゃね？はC++学習者の必ず通る道やからしゃーない

842: 2021/08/27(金)15:05 ID:nK81wxcE(1/2) AAS
で、結局なんでできないの？

C APIのほうが汎用性が高いから？
行列やテンソルは乗算方法が複数あるから？
結果の表現形式も有理数とか複数あるから？
結果をエレベーションする必要があるから？

843(2): 2021/08/27(金)17:44 ID:LFMqkLz6(1) AAS
extern "C" 使ってる？

844: 2021/08/27(金)17:53 ID:nK81wxcE(2/2) AAS
>>843
Cで開発するときに、常にヘッダファイルに書いておく必要があるかどうかって話なら、将来c++から呼び出す可能性があるなら書いておけば？
最悪なくてもインクルードする側でどうにかなる

845: 2021/08/27(金)19:22 ID:ghUXxVcH(1) AAS
>>843
32bitとはいえマイコンで-std=gnu++17とか指定するのは微妙な背徳感を感じてしまうチキンだが、
Cのライブラリも一緒に使うから、普通に使ってるな。基本ヘッダファイルでほとんど事足りるんだけど、
weak指定のCの割り込みハンドラとか再定義するときは混乱しないように明示的にextern "C"付けてる。

846: 2021/08/29(日)01:50 ID:TPHdi4yb(1) AAS
>>841
operator置き換えまくりとかな

847: 2021/08/29(日)10:17 ID:sPGAkNt4(1) AAS
>>841
設定読み込みの部分でお世話になったわ

848: 2021/08/30(月)14:54 ID:a7szkEqk(1) AAS
C++17は甘え

849: 2021/08/30(月)20:54 ID:i7moqIxZ(1) AAS
甘えてもいいぜ

850: 2021/09/08(水)21:07 ID:QZMwNs5W(1) AAS
C99で良いです……

851: 2021/11/24(水)18:53 ID:ONXwk6fD(1) AAS
void *q = (void*)p;
void *r = reinterpert_cast<void *>(p);
void *s = static_cast<void *>(p);
どっちが良い？

852: 2021/11/24(水)22:24 ID:7YsOMgZx(1) AAS
p の型によるんじゃね？

853: 2021/11/25(木)14:45 ID:Ts2h3uwp(1) AAS
>>838
Eigen の MatrixXtype と Matrix<type, Dynamic, Dynamic> が便利なのは判ったが
自分でそいつらを引数に持つテンプレート関数書こうとして
template <typename T, int R, int C>
void func(Matrix<T, R, C>&m){ ... }
で定義したら
a が Matrix3d a; とか RC 固定されてるときは func(a) で問題無いが
a が Matrix<type, Dynamic, Dynamic> a(3, 3); だと
実際に func(a) とかで呼ばれるときに
Matrix<type, -1, -1>
省5

上下前次 1-新書関写板覧索設栞歴

あと 149 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.051s