C++相談室 part159

**デフォルトの名無しさん** · 2022/02/19(土) 11:56:42.14

前スレ
C++相談室 part158
https://mevius.5ch.net/test/read.cgi/tech/1636969758/

**デフォルトの名無しさん** · 2022/04/01(金) 01:39:47.02

PTESTがあるぞ

**デフォルトの名無しさん** · 2022/04/01(金) 20:07:44.20

>>817
_mm_testc_si1281命令でできるのか
サンクス

**デフォルトの名無しさん** · 2022/04/02(土) 03:00:41.15

ハンガリアン記法、いまだ健在なり

**デフォルトの名無しさん** · 2022/04/02(土) 05:57:08.65

プログラムほぼ未経験だけどこれから始めます
今は坊主頭の人の本を読み始めたところです
IDEのCLionを考えています
他におすすめあったら教えてください

**デフォルトの名無しさん** · 2022/04/02(土) 08:28:40.83

Visual studioオススメ。VSCode+CMakeでもいいぞ

**デフォルトの名無しさん** · 2022/04/02(土) 12:16:55.77

bitsetで実装し終わった後にvector<bool>がconstexpr対応してる事知ったんだが？
はー先に教えてくれよ（ｸｿﾃﾞｶため息）

**デフォルトの名無しさん** · 2022/04/02(土) 12:49:25.68

vector<bool>なんか使っちゃいけません

**デフォルトの名無しさん** · 2022/04/02(土) 14:22:05.97

bitsetを実現するのならvector<bool>は妥当
だと思う派

**デフォルトの名無しさん** · 2022/04/02(土) 14:30:40.42

しかしvectorKbool>様のﾌﾞﾂ（一般に数千ビットとかのデカくて比較的疎なやつ）がconstexpr対応している
と特段のありがたみと
かあるん？？

**デフォルトの名無しさん** · 2022/04/02(土) 14:35:10.49

二進法で書いちまった方が…

**デフォルトの名無しさん** · 2022/04/02(土) 14:36:56.48

vector<bool> 駄目って言ってる奴らって思考停止のバカでしょ

「特殊化されてるのである時は注意が必要」というのを理解できず思考停止でとりあえず禁止と見なしてるバカ

**デフォルトの名無しさん** · 2022/04/02(土) 14:38:37.01

これか
https://cpprefjp.github.io/lang/cpp20/more_constexpr_containers.html
やっぱ内部でループのみならず、new / deleteするような関数までconstexprであってほしいと願うマニアが一定数居るんやな……

**デフォルトの名無しさん** · 2022/04/02(土) 14:40:50.98

キューとかスタック的な使い方なら自然だと思うね

**デフォルトの名無しさん** · 2022/04/02(土) 14:44:28.98

一度作ってみたけどconstexpr関数内でnewしたらその関数内でdeleteまでしなきゃいけないのは使いづらい気がする

**デフォルトの名無しさん** · 2022/04/02(土) 14:53:16.59

まずはvector<bool>で実装してみて問題あるなら考える派

**デフォルトの名無しさん** · 2022/04/02(土) 14:53:28.58

だがちょっとまって欲しい毎秒1億も2億も回るようなループの中でこそ高速化が必須だが
そんなループ内でnew /deleteしようとする発想が最初からなんかおかしいのではないか

**デフォルトの名無しさん** · 2022/04/03(日) 18:44:27.58

struct Hoge
{
std::vector<Hoge> hoges_;
};

ってなんでコンパイル通るの？
hoges_の定義時点ではまだ、Hogeの定義は完了していないのに。

**デフォルトの名無しさん** · 2022/04/03(日) 19:05:25.24

struct Hoge {
　Hoge* ptr;
};
が通るのと同じ理屈なんじゃない？

**デフォルトの名無しさん** · 2022/04/03(日) 19:25:23.89

ソースコード次第やな
allocatorでサイズ使いそうなもんだけど

**デフォルトの名無しさん** · 2022/04/03(日) 19:33:06.66

宣言の時点では別に適当

**デフォルトの名無しさん** · 2022/04/03(日) 19:35:01.81

宣言？
どこにも宣言のみの記述はありませんけど？

**デフォルトの名無しさん** · 2022/04/03(日) 19:48:52.09

半角全角使うな厨が絶滅しますように (AA略

**デフォルトの名無しさん** · 2022/04/03(日) 20:07:54.56

定義自体は再帰してても大丈夫じゃない？

**デフォルトの名無しさん** · 2022/04/03(日) 20:32:55.79

>>839
あそう、だったら

struct Hoge {
　Hoge hoger;
};

これもOKだろｗ

**デフォルトの名無しさん** · 2022/04/03(日) 20:58:54.41

参照だったらサイズが一意になるから問題なく処理できる
実態だったら無間地獄に落とされるからNG

**デフォルトの名無しさん** · 2022/04/03(日) 21:17:02.42

>>841
839は参照じゃないじゃん
話し通じないな

**デフォルトの名無しさん** · 2022/04/03(日) 22:20:50.07

えっstd::vector<T> hoge_; とやった場合Tが何であってもその場でhoge_のサイズは決まるから
struct Hogeのメモリレイアウトは鎧袖一触で決まるか
ら何の問題も無い

決まらないのはhoge_のインスタンスがポインタで保持することになるヒープ上の領域のサイズであって
struct Hogeのサイズは上述の通りstruct Hogeの定義を一通り見たとき鎧袖一触で決まっているから
Hoge::hoge_をインスタンス化するタイミングで問題無くインスタンス化されるという印象のような希ガス
いや知らんけど
※ 個人の感想です

**デフォルトの名無しさん** · 2022/04/03(日) 22:33:18.09

とｵﾓタがなんかVS2019（C++14）で試したら以下のコードのビルドが通る怪現象やな……
template<class T, int N>
class VarArr {
　int T[N];
};

struct Hoge {
　VarArr<Hoge, 3> m_arr;
　int m_x;
};

Hoge x;

多分環境に拠るんだと思う

**デフォルトの名無しさん** · 2022/04/03(日) 22:35:40.26

VarArr<T, N>の定義をまつがえたｻｰｾﾝ……orz
以下のコードなら正しくビルドエラーになる
template<class T, int N>
class VarArr {
T m_arr0[N];
};

struct Hoge {
VarArr<Hoge, 3> m_arr;
int m_x;
};

Hoge x;

ワイの答えはこれや！

**デフォルトの名無しさん** · 2022/04/03(日) 23:14:48.08

>>839で適当に回答したけどメンバとしてを実体で持つかポインタで持つかで通るかが決まるな

**デフォルトの名無しさん** · 2022/04/03(日) 23:38:16.75

struct Hoge
{
int a[sizeof(Hoge)];
};
はHogeがまだ定義されていないから、コンパイルできない
だったら、なぜ
std::vector<Hoge> hoges_;
は許可できるんだ

**デフォルトの名無しさん** · 2022/04/03(日) 23:53:21.86

>>847
規格的に問題ないからだが、まあポインタなんでサイズ知らんでもええからだな

**デフォルトの名無しさん** · 2022/04/04(月) 00:18:36.05

>>847
std::vector<Hoge> hoges_;　はクラスないしstructのサイズには影響しないからじゃないの？
そのクラスないしstructはstd::vector<Hoge> hoges_へのアドレスを保持するだけでしょ？
クラスないしstructの中でのhoges_のサイズはすでに決まっている

**デフォルトの名無しさん** · 2022/04/04(月) 00:23:58.82

>>847
>>843に書いたが
struct Hoge {
　std::vector<Hoge> hoge_;
};
の実質は
struct Hoge {
　struct {
　　　(&(hoge_[0])を指すポインタ);
　　　(管理用のいくつかのメンバ)
　}　hoge_;
};
とゆーことなのでstruct Hogeの中にhoge_[0..]の実体が埋め込まれるわけでは無いから、
hoge_[0..]の型が決まっていなくともstruct Hogeのサイズは問題無く決まるというしくみ

一方hoge_[0]の実体がstruct Hogeに埋め込まれる>>845のケースは気体どおりエラーになる
というﾜｹ

**デフォルトの名無しさん** · 2022/04/04(月) 09:09:53.47

>>843
鎧袖一触の使い方間違いで草ｗ

**デフォルトの名無しさん** · 2022/04/04(月) 23:12:20.74

4、5年c++やってるけどまともなものを作れない
どれくらいで、ネットで有名なソフトって作れるものなの？
例えばvscodeみたいな便利なアプリ

**デフォルトの名無しさん** · 2022/04/04(月) 23:46:47.47

>>852
VScodeはElectronつまりJavaScriptで書かれてるよね

**デフォルトの名無しさん** · 2022/04/05(火) 00:26:55.67

>>852
C++Builderが楽だよ

**デフォルトの名無しさん** · 2022/04/05(火) 01:43:21.89

windowsは触ったことがない

**デフォルトの名無しさん** · 2022/04/05(火) 02:00:35.56

ならばElectronかTauriがオススメ
WindowsだけでなくMacでもLinuxでも動くマルチプラットフォーム

**デフォルトの名無しさん** · 2022/04/05(火) 06:11:04.09

>>852
言語だけ触ってても無理
自分は◯◯を作るんだという
一途な意思がいる

ネットでウケるかどうかは通常どうにもできない
もし市場の需要を読んで開拓ができるなら
もうそのままプロになれる

**デフォルトの名無しさん** · 2022/04/05(火) 10:33:40.77

>>852
まともって言うか一定規模以上のソフトを作ろうと思ったらオブジェクト指向デザインパターンを網羅していく事の方が大事
難しいハッキングをやるよりも設計の方がなんだかんだで難易度高いからな

**デフォルトの名無しさん** · 2022/04/05(火) 17:09:26.03

「成功者」の法則をなぞるだけでは成果は出せない
そんなの誰でもできるから

形振り構うことより興味の向くまま突っ走るほうが肝心
そうして何かを成し遂げると自分なりの法則ができている

それまで周りは散々バカにしてくれるが
そんなのに折られないメンタルも大事だ

**デフォルトの名無しさん** · 2022/04/05(火) 17:46:09.74

メモリマップドファイルのライブラリが標準入りするのってまだまだ先ですか？？
標準ライブラリとするのに何か問題でもあるの？

**デフォルトの名無しさん** · 2022/04/05(火) 19:10:03.35

<filesystem>ですら入ったの最近だしあんまり期待してない

socketとかのネットワークライブラリも標準にはないんだぜ？

**はちみつ餃子** ◆8X2XSCHEME · 2022/04/05(火) 19:53:34.34

>>852
個人でなんらかのソフトを作る場合には「動くプログラム」を意識するといいよ。
構想通りに設計しようとするよりは機能を極小に絞ってでも動く状態のプログラムを作ってみて、
それを拡張していくという形にすれば行き詰まったところが学ぶべきことが潜んでいるところだとわかる。

ある程度までいったら最初から作り直したくなるときがくる。
学びながら作ったものなんてろくでもないんだから作り直すはめになるもんなんだよ。
どうせ作り直すと割り切って色々やってみればいい。

**デフォルトの名無しさん** · 2022/04/05(火) 20:56:02.32

Googleの人もイテレーティブな開発が良いって言ってたなあ

**デフォルトの名無しさん** · 2022/04/05(火) 21:08:43.94

あーすべき、こーすべきと雁字搦めにPGを縛る硬直的で強迫的な教条主義が
投げやりなやっつけ仕事を大量生産するという教訓から色々な提案が出てるのに
教わったことにしがみつく後ろ向きな人が悪しき循環を継続させちまう

**デフォルトの名無しさん** · 2022/04/05(火) 21:15:39.04

C++って他の言語と違って何でも出来るから情報収集に時間使いすぎるんだよな
プランAからZまであらゆる手法を検討して最善手を打たなければどこかで詰む事になる

**デフォルトの名無しさん** · 2022/04/05(火) 21:15:57.95

大昔の記憶だけどメモリマップというかネットワーク系のライブラリはC++に追加されないのかって聞いたときに
OS依存の仕様は実装されないって聞いた記憶あるけど最近のC++は方針変わったのか？

**デフォルトの名無しさん** · 2022/04/05(火) 22:34:00.51

C++とSTLは別だよ

**デフォルトの名無しさん** · 2022/04/05(火) 22:39:47.79

threadみたいにするならかまわんのだろ

**デフォルトの名無しさん** · 2022/04/05(火) 22:54:42.49

プロセスがサポートされないアレでか

**はちみつ餃子** ◆8X2XSCHEME · 2022/04/05(火) 23:18:25.53

スレッドは OS が提供するスレッドと一対一で対応することを意図しているという記述がある。

https://timsong-cpp.github.io/cppwp/n3337/thread.threads#1

スレッドを持たないシステムに対応付けるならスレッドの生成に常に失敗するような実装になってても仕様には反しないんじゃない？
noexcept は例外を送出しないことを保証するけど実行時エラーがないことを保証するわけではない。

**デフォルトの名無しさん** · 2022/04/05(火) 23:23:24.49

今さらDOSでC++11か
いや否定はできんけど・・・

**デフォルトの名無しさん** · 2022/04/05(火) 23:31:23.00

プロセスを持ち出す意味がわからん
スレッドがあればいいんじゃ？

**デフォルトの名無しさん** · 2022/04/05(火) 23:37:46.31

なんで？
アドレス空間の多重化とプロセス間通信はOSが違ったら移植性なしで割り切るの？

**デフォルトの名無しさん** · 2022/04/05(火) 23:42:47.00

それがないとスレッドも許されんという理屈がわからない

**デフォルトの名無しさん** · 2022/04/05(火) 23:52:53.92

スレッドも許されないなんて主張してないが

**デフォルトの名無しさん** · 2022/04/06(水) 07:13:16.72

質問ですがイテレータ間の距離はstd::distance<T>(first, last)で求められるそうなんですが
求めた距離を再びイテレータに戻す場合はどうすれば良いですのん？firstとlastがラ
ンダムアクセスイテレータならfirst + std::distance(last, first) == lastが成立するという具合に
足せば良いけどランダムアクセスイテレータか否かによらず共通に使えるテンプレートは？

**デフォルトの名無しさん** · 2022/04/06(水) 08:10:41.61

>>876 std::next() https://cpprefjp.github.io/reference/iterator/next.html

**デフォルトの名無しさん** · 2022/04/06(水) 08:51:32.67

>>876
std::advance(イテレタ,求めた距離)

**デフォルトの名無しさん** · 2022/04/06(水) 14:47:30.60

technical default とかいう新技が出てきたね

**デフォルトの名無しさん** · 2022/04/06(水) 18:03:31.71

みなさん多次元配列ってどうやって持ってますか？
・blas, lapack等fortranの資源を使いたいからローメジャー、カラムメジャーは宣言時に決めたい
・添字アクセスがネイティブの多次元配列並みに早い
・STLコンテナみたいに使える
等の条件を満たす良いライブラリありますかね

本当はSTLに入ってほしいんですが、なぜ未だにないんですかね？

**デフォルトの名無しさん** · 2022/04/06(水) 18:15:07.58

ネイティブの多次元配列とは

**デフォルトの名無しさん** · 2022/04/06(水) 18:18:59.68

>>881
ああすみません私めは言語障害者だから変な言葉使ってるかもしれません
Cの多次元配列のことを変な呼び方をしてしまいました
すみません

**デフォルトの名無しさん** · 2022/04/06(水) 18:30:19.00

eigen gmtlとか？

**デフォルトの名無しさん** · 2022/04/06(水) 19:07:48.95

1つめがよーわからんけど
・次元数はコンパイル時決定
・要素数もコンパイル時決定
・子要素のサイズは全て同じ(arr[0].size()==arr[1].size() が常に成り立つ)

ってことでええの？
それなら単純にstd::array<std::array<T, 4>,5>でいいとは思うが

**デフォルトの名無しさん** · 2022/04/06(水) 19:36:43.45

全部arrayだとスタックに配置される事あるからvector<array>でやってるな

**デフォルトの名無しさん** · 2022/04/06(水) 21:17:51.29

>>880
std::mdspanというのが提案中だがまだ時間かかりそう

**デフォルトの名無しさん** · 2022/04/06(水) 23:18:21.83

>>877 >>878
レス㌧クス
やっぱいろいろ一般化されたテンプレートがいっぱいあったら
テンプレートを特殊化せずに済む幅がひろがりんぐ、

**デフォルトの名無しさん** · 2022/04/07(木) 03:17:05.89

>>883
eigenは遅い
gmtlはメンテナンスされてない

>>884-885
一次元配列にマップしたときの並び方が柔軟であってほしいって書いてるでしょ
外部ライブラリ必須じゃないかな現状

>>886
mdspanは実体を持たなくてmdarrayは実態を持つんだっけ
C++23に入るって話じゃなかったっけ？
俺C++の新機能はそんなに熱心に追ってないけどこれだけは待望してる

>>880
ということで、現状はboostじゃないかな
これもメンテナンスされてないようだが、マシだと思う
良いライブラリがあったら俺も知りたい

**デフォルトの名無しさん** · 2022/04/07(木) 03:34:21.33

柔軟な多重配列なんて自分ですぐ作っておしまいな話なのに
なぜ標準にないとかライブラリがないと言い出したり将来の仕様に期待するとか意味不明

**デフォルトの名無しさん** · 2022/04/07(木) 03:49:06.16

numpyを使う。もちろん他にpython併用する理由があればだけど。
ローメジャーなのでメモリ上での向きは個別にやってる。

**デフォルトの名無しさん** · 2022/04/07(木) 05:59:06.00

>>880
blas使いたいんならstd::sliceがモロそのものだよ

**デフォルトの名無しさん** · 2022/04/07(木) 06:13:35.95

>>889
やってから言えや
例えば、高速なランダムアクセスとか添字の組と要素番号の間の高速なマッピングとか、どう実装するつもりでいるの？

**デフォルトの名無しさん** · 2022/04/07(木) 06:17:36.20

あるクラスのコンストラクタがvector<int>をとるんだけど、たまにvector<size_t>を渡したいときがあるからオーバーロードするようにしたらambiguousだとエラーが出た

1) ambiguous にならない方法はありますか
2) vector<size_t>の各要素がintの範囲に収まるくらい小さいとき、これをvector<int>にキャストするナイスな書き方はありますか

**デフォルトの名無しさん** · 2022/04/07(木) 06:40:42.70

ambigousにはならんようだが
https://ideone.com/YrFYsI

**デフォルトの名無しさん** · 2022/04/07(木) 07:18:15.48

>>892
自作すれば自分の使う方法に合わせてカスタマイズできるから圧倒的に有利
インデックシングも汎用だと毎回多段計算になるが自作なら用途に合わせて最適化できる

**デフォルトの名無しさん** · 2022/04/07(木) 08:17:57.53

ファイルならまだしもオンメモリーで高速なランダムアクセスとか言語の範囲では工夫しようがなくね？

**デフォルトの名無しさん** · 2022/04/07(木) 08:32:07.21

近傍のアクセスが速いというのは言語関係ないしな

**デフォルトの名無しさん** · 2022/04/07(木) 10:27:53.88

そういえばSTLのコンテナに[]で範囲外アクセスしたとき、デバッグモードだとちゃんとアサート出してくれるけど
あれってSTL実装した人がそう書いたから出るの？それともOSの機能か何か？

**デフォルトの名無しさん** · 2022/04/07(木) 10:32:39.68

全てそう書いたから出るんだよ
OSはレイヤが違う話

**デフォルトの名無しさん** · 2022/04/07(木) 10:39:14.99

へえ、じゃやっぱマクロ使ってガシガシ書いてるんだろうね
自分じゃ絶対やりたくないなｗ

**デフォルトの名無しさん** · 2022/04/07(木) 17:34:09.66

ifdefで括るだけだろ

**デフォルトの名無しさん** · 2022/04/07(木) 18:22:02.97

>>898
ルール上、保証がないことでも
やってくれてることって、どこにでもあるだろ

operator[](size_t)で範囲外アクセスした場合の動作は未定義なので
どんな扱いをされても合法なんだよ

# 一時期流行った気持ち悪い喩えはもうしない

**デフォルトの名無しさん** · 2022/04/07(木) 21:49:18.59

SNSの気持ち悪いノリ持ち込むなよ

**デフォルトの名無しさん** · 2022/04/08(金) 01:44:38.29

>>900
お客様根性丸出しのプログラマとか・・・

**デフォルトの名無しさん** · 2022/04/09(土) 13:06:11.18

メモリが足らないから６４ビットにするとかいうやつがいて
ソース見たら
double hoge[300][300][300];
って笑った

**デフォルトの名無しさん** · 2022/04/09(土) 13:37:31.78

64bit化だけじゃ無理でしょ
スタックサイズを512MBぐらいにしなきゃ

**デフォルトの名無しさん** · 2022/04/09(土) 13:47:10.70

ツッコミどころが違う…
32bitのままヒープに確保で十分だから

**デフォルトの名無しさん** · 2022/04/09(土) 13:49:15.33

ヒープを使って良いのはアマチュアまでだからな

**デフォルトの名無しさん** · 2022/04/09(土) 13:53:57.22

世の中マシン性能で解決おじさんみたいなのばっかり

**デフォルトの名無しさん** · 2022/04/09(土) 14:20:15.81

>>907
それを言うなら32bitのままスタックサイズを増やすだけで充分だろ
ソース変更要らんし

**はちみつ餃子** ◆8X2XSCHEME · 2022/04/09(土) 15:54:11.32

デフォルトでのスタックサイズ上限がだいぶん小さめ (数メガバイト程度) になってるのは
基本的にそれで足りる、なるべくそれで足りるように書けという暗黙の圧力だと思う。
必要に応じて柔軟に対処すりゃいいけど、最初からあえて逆らうべきでもないだろ。

なんでもかんでもスタックを使ってるとデバッガで追いづらいし、
流れを制御するための変数と処理する対象になるデータ (大抵はある程度に大きい) は分けたい。
回路設計に喩えると制御線と動力線を分けるみたいな感じ。
(わかりにくい比喩ですまんがあくまで感覚なのでこういう形でしか表現できない。)

**ハノン** ◆QZaw55cn4c · 2022/04/09(土) 16:35:28.22

>>911
＞回路設計に喩えると制御線と動力線を分けるみたいな感じ。

昔、試作基盤として、天地にべったり Vcc とアースを上辺と下辺に貼り付けて、間に島（ランド）をたくさん並べるっていうのを聞いたことがあります
どういう名称だったか忘れちゃいましたが…

**デフォルトの名無しさん** · 2022/04/09(土) 16:45:04.63

おれおれコーディングルールを開陳されても困る

**デフォルトの名無しさん** · 2022/04/09(土) 18:42:32.24

>>906
笑ったって書いてあんじゃん
また、笑った

**デフォルトの名無しさん** · 2022/04/09(土) 19:24:26.54

300が何の数字か知らんけど、それが変更や拡張で800くらいになったら溢れるんだから
64bitが必要って判断はなくはないでしょ
何の数字か知らんけど

**デフォルトの名無しさん** · 2022/04/09(土) 19:56:02.24

>>915
君は本物のバカだな

**デフォルトの名無しさん** · 2022/04/09(土) 21:01:35.50

規格にスタックって出てくる？