C++相談室 part158

**デフォルトの名無しさん** · 2021/11/15(月) 18:49:18.44

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

**デフォルトの名無しさん** · 2021/11/23(火) 10:28:59.05

とりあえず判ったのは
ss.rdbuf() の default の上限値が 255 らしい

**デフォルトの名無しさん** · 2021/11/23(火) 10:53:38.11

だっせ
そんな上限、規格票に書いてあるのか？

**デフォルトの名無しさん** · 2021/11/23(火) 11:40:46.26

>>115
>MSVCのstd::chrono::zoned_timeが未実装

TZ=JST-9
とか描いてあってもだめかな

**デフォルトの名無しさん** · 2021/11/23(火) 11:52:24.16

>>120
ss.rdbuf()->in_avail()

**デフォルトの名無しさん** · 2021/11/23(火) 13:42:01.58

再現しそうな最小限のコードだけ描いて
mingw + gcc でコンパイル＆実行したら期待通りの動作をしたが
VC だとやっぱり上限があるっぽい動きになってる
rdbuf() 使いつつ seek() すれば大丈夫かも知れないが
自分の使い方が間違ってるだけだと思いたい

**デフォルトの名無しさん** · 2021/11/23(火) 13:44:07.61

とりあえず mpreal は関係なかった
VC 側の問題らしいのでもう少し掘ってみる

**デフォルトの名無しさん** · 2021/11/23(火) 14:39:06.53

VC 側 rdbuf()->pubseekpos() 併用で解決

**デフォルトの名無しさん** · 2021/11/23(火) 15:22:40.52

クラスのメンバ変数が全部intとかdoubleとかで足し算掛け算ができるものの場合に、
クラスの足し算掛け算を各メンバ変数の足し算掛け算として定義したいのですが
operator +とかoperator *のオーバーロードでメンバ変数について一個ずつ書いていく以外の方法ありますか？

今やろうとしていることでメンバ変数が多いので、いちいち列挙せずに済むなら便利だなと思ったのですが

**デフォルトの名無しさん** · 2021/11/23(火) 15:49:25.55

>>126
valarrayじやね？

**デフォルトの名無しさん** · 2021/11/23(火) 16:47:46.55

>>117
VC の in_avail() が間違った値を返してるんだなこれ

**デフォルトの名無しさん** · 2021/11/23(火) 17:12:53.52

>>127
ありがとうございます、使ってみます

**はちみつ餃子** ◆8X2XSCHEME · 2021/11/23(火) 17:34:18.50

>>126
現在の C++ はリフレクション系の機能が弱くてクラスからデータメンバを列挙するというようなことは出来ない。
「全てのメンバに対してやってくれ」というようなことはできない。
ただ、対象となるメンバを取り出すものさえ用意すればそれを様々な演算に適用することは可能だと思う。
つまり、メンバの列挙を一度で済ませる (なんども列挙しなくてよい) ことは出来るかもしれないってことね。

とはいえそれはそれで割とクソめんどうくせぇメタプログラミングの下準備が要るので
いっそ列挙しまくったほうが簡単かもしれん。

**デフォルトの名無しさん** · 2021/11/23(火) 17:57:00.33

Q_OBJECT とかだとメンバの列挙出来たっけ

**デフォルトの名無しさん** · 2021/11/23(火) 23:10:58.29

>>121
駄目なんじゃないかと思う
std::chronoはtime_pointを抽象化してタイムゾーンの異なる時刻間の差分を自動で取り扱いたい（そういう思想な）はずで、
ということはローカルタイムを扱う手段としてzoned_timeは無くてはならないピースとみなさざるおえない

どうしてもというならstd::chrono::system_timeを経由して古き良きtime_tとtime_pointの相互変換ができるから、
time_tまで降りてローカルタイムにしてtime_pointに戻す手はあるが、それをすると
同じtime_pointクラスで表される2種類のシリアル時間がプログラム内に生じてしまうから、
std::chronoの上記思想（時刻の差分や比較を自動で安全に取り扱いたい）が破壊される

ライブラリ仕様の理想が高邁すぎるか実装側の怠慢によって大事な用途において糞ライブラリになってしまっている例

**デフォルトの名無しさん** · 2021/11/23(火) 23:41:07.98

何が出来ないと言っているのかまるで分からん
出来る部分と出来ない部分の切り分けがいるんでないの？

**デフォルトの名無しさん** · 2021/11/24(水) 00:03:21.95

time_point（事実上UTC）とローカルタイムの相互変換がstd::chronoが思想的に目指しているほど安全にはできない
zoned_timeが実装されない限り

time_point（事実上UTC）同士の比較や差分はzoned_timeが実装されてないバージョンでも安全にできる

**デフォルトの名無しさん** · 2021/11/24(水) 00:18:07.67

そんなアバウトな情報いらん

**デフォルトの名無しさん** · 2021/11/24(水) 00:31:14.95

えっと、>>135はUTCとローカルタイムの変換ってわかります？

**デフォルトの名無しさん** · 2021/11/24(水) 00:39:36.48

std::chronoで現在時刻を取得する一番自然な方法は、
　system_clock::time_point now = system_clock::now();
や
他にもtime_tからの変換という方法があるが、いまさらtime_t使え言うぐらいならstd::chrono使わずにtime_tだけ使うは；；；

で、nowはどう見てもUTCであるから、日本時間を知りたければ、
上記time_point nowが日本時間の何年何月何日の何時何分何秒なのかを出力できねばならない
std::chronoの中にはzoned_timeを使わずにそれをやる手段が見当たらない

**デフォルトの名無しさん** · 2021/11/24(水) 00:44:19.87

C++20より前のchronoはタイムゾーンのこと知らんからな…

**デフォルトの名無しさん** · 2021/11/24(水) 01:06:29.20

>>99で聞かれてるのは「日時を数値に変換」だろ？
前提も条件も全部曖昧で、自然とか思想とか思い込みばかり
何を使うと何が出来て何が出来ないを全く説明してない

**デフォルトの名無しさん** · 2021/11/24(水) 01:21:45.20

chronoはローカルタイムを扱えない、と言ってると思うよ

**デフォルトの名無しさん** · 2021/11/24(水) 02:40:02.07

http://pbs.twimg.com/media/EUH_eMWUwAAgsV4.jpg
https://pbs.twimg.com/media/D4p7dNfUwAAa34y.jpg

**デフォルトの名無しさん** · 2021/11/24(水) 03:00:57.55

ローカル時刻かUTCか以前の問題として、そもそもどんなフォーマットで数値に変換するのか
それが不明だったから誰も回答しなかったのだろうに

あとドキュメント信じる限りじゃzoned_timeはVS2019 16.10から使えるってよ

**デフォルトの名無しさん** · 2021/11/24(水) 03:04:53.60

C++は糞
std::は糞ばかり
boost最強
まで読んだ

**デフォルトの名無しさん** · 2021/11/24(水) 03:08:01.30

>>142
>>100 が悪い

**デフォルトの名無しさん** · 2021/11/24(水) 04:22:29.20

じゃ、もうtime_t使っとけ

**デフォルトの名無しさん** · 2021/11/24(水) 05:14:05.40

「良い感じの関数」なんて今流行りwのAIとか使わんと無理でしょ

**デフォルトの名無しさん** · 2021/11/24(水) 07:01:18.14

確かにchronoは今一だね
filesystemはthread, iomanipとの連携が悪すぎ
使いにくいったらありゃしない

**デフォルトの名無しさん** · 2021/11/24(水) 07:01:39.82

- filesystemは
+ tilesystemや

**デフォルトの名無しさん** · 2021/11/24(水) 08:47:11.69

auto p = (void*)[]{};
これが通らないんだけど
stateless-lambdaは関数と見なせない？

**デフォルトの名無しさん** · 2021/11/24(水) 09:11:02.53

auto p = (void*)(void (*)())[]{};

**デフォルトの名無しさん** · 2021/11/24(水) 09:17:04.13

auto p = []()->void*{};
もう少し学習しろ

**デフォルトの名無しさん** · 2021/11/24(水) 10:46:50.00

何がしたいんか知らんけど
auto p = [](){};
auto p = []()->void*{};
auto p = []()->void{};
本人の意図が判らんことには絶対に正解に辿り着けない質問大杉

**デフォルトの名無しさん** · 2021/11/24(水) 11:11:35.49

void func1(void*);
void func2(){}
func1(func2);
のようなことをしようとしてて怒られるから
func1((void*)func2);
にしてた

で、func2で名前空間を汚染したくないから
stateless-lambda使おうと思った

**はちみつ餃子** ◆8X2XSCHEME · 2021/11/24(水) 11:25:51.06

関数 (関数ポインタ) を void* で受ける雑なことをしといて名前空間を汚すのは気にするのか。
まあフレームワークとかの側でそうなってたら仕方ない場合もあるけど……。

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

variant的なことを昔ながらの方法でやっているのかもしれない

**デフォルトの名無しさん** · 2021/11/24(水) 11:41:52.30

auto p = []()->void*{return NULL;};
↑これはOKだが
auto p = []()->void*{};
↑こっちはコンパイルエラーにして欲しいよね

**デフォルトの名無しさん** · 2021/11/24(水) 11:48:13.06

単にステートレスラムダを関数ポインタに変換したいならこういう有名なハックがある
auto p = +[]{};

**デフォルトの名無しさん** · 2021/11/24(水) 12:47:46.56

>>157
おお、これはいい
㌧x

**デフォルトの名無しさん** · 2021/11/24(水) 12:55:27.21

ポインタに単項プラスなんぞ考えたこともなかった
void test(char* p)
{
cout << +p << endl;
cout << *+p << endl;
cout << *(0+p) << endl;
cout << 0[p] << endl;
}

**デフォルトの名無しさん** · 2021/11/24(水) 15:19:51.62

生配列をポインタに変換するときも単項+使うね

**デフォルトの名無しさん** · 2021/11/24(水) 15:33:19.13

>>160
何が嬉しいの

**デフォルトの名無しさん** · 2021/11/25(木) 09:42:14.59

C++11 や C++17 や C++20 とかどのオプションでコンパイルされているかを
コンパイル中に判断したいのですが
ソースコード中にどう書けばよいのですか

**デフォルトの名無しさん** · 2021/11/25(木) 10:11:07.71

解決
https://docs.microsoft.com/en-us/cpp/build/reference/std-specify-language-standard-version?view=msvc-160
_MSVC_LANG

**デフォルトの名無しさん** · 2021/11/25(木) 10:12:19.59

全然解決してなくて草

**デフォルトの名無しさん** · 2021/11/25(木) 11:00:47.97

>>161
#include <iostream>
#include <cstdio>
int main() {
int a[] = {1, 2, 3, 4};
std::printf("%p %p\n", &a, &a + 1);
std::printf("%p %p\n", +a, +a + 1);
int (*p)[4] = &a;
std::printf("%p %p\n", p, p + 1);
int *q = &a[0];
std::printf("%p %p\n", q, q + 1);
return 0;
}
0x7ffd548f5d00 0x7ffd548f5d10
0x7ffd548f5d00 0x7ffd548f5d04
0x7ffd548f5d00 0x7ffd548f5d10
0x7ffd548f5d00 0x7ffd548f5d04
つまり&a[0]と書くのを+aと書くだけですませられる
どっちが分かりやすいかはさておき

**デフォルトの名無しさん** · 2021/11/25(木) 11:28:16.28

__cplusplus マクロ見るんじゃね？普通は
あとは言語機能ごとのマクロ見たり

**デフォルトの名無しさん** · 2021/11/25(木) 11:38:56.35

まるで間違ってて草

**デフォルトの名無しさん** · 2021/11/25(木) 13:18:45.98

>>165
<iostream>いらないね

それとlvalue transformationがかかる場面で
わざわざ単項プラスを使う必要性が
そのサンプルでは示せてないようだが

**デフォルトの名無しさん** · 2021/11/25(木) 14:43:49.72

みんなテキトーだなー(棒)

**はちみつ餃子** ◆8X2XSCHEME · 2021/11/26(金) 02:28:38.10

>>166
処理系がちゃんとそのへんのルールを守ってくれればいいが現実は非情である。

**デフォルトの名無しさん** · 2021/11/26(金) 21:22:58.84

https://www.youtube.com/watch?v=ia8GncoXA1s

**デフォルトの名無しさん** · 2021/11/27(土) 03:24:08.24

The following macro names shall be defined by the implementation:
__cplusplus
The name __cplusplus is defined to the value 199711L when compiling a C++ translation unit.

G++ now sets the predefined macro __cplusplus to the correct value, 199711L for C++98/03, and 201103L for C++11.

http://gcc.gnu.org/gcc-4.7/changes.html
But g++ < 4.7.0 is __cplusplus defined alway 1.

https://devblogs.microsoft.com/cppblog/msvc-now-correctly-reports-__cplusplus/

**デフォルトの名無しさん** · 2021/11/27(土) 04:01:44.14

いまさらかよ

**デフォルトの名無しさん** · 2021/11/27(土) 12:26:56.81

マジかよ知らなかった
GCCくんさぁ…

**デフォルトの名無しさん** · 2021/11/27(土) 13:29:25.44

>>174
初心者？

**デフォルトの名無しさん** · 2021/11/27(土) 14:01:53.67

リナスもg++の設計にはイラチMAXの筈だわ

**デフォルトの名無しさん** · 2021/11/27(土) 15:41:12.47

Rust厨に弱みを魅せるな

**デフォルトの名無しさん** · 2021/11/27(土) 16:22:10.07

よわみにはつけこまれる

**デフォルトの名無しさん** · 2021/11/28(日) 21:05:38.19

C++でblas, lapackを使うのにいいインターフェースってどれでしょうか？
調べてたらCppLapack, Lapack++、armadillo とか出てきましたが、定番さとか使いやすさとか教えていただけると嬉しいです

とりあえずは複雑なことはしない予定で、行列の掛け算とか対角化ぐらいが簡潔に書けると嬉しいです

**デフォルトの名無しさん** · 2021/11/29(月) 00:38:26.49

久しぶりにC++再開したが
昔からだが
PHPはC++のスクリプト版といえるかのように文法・関数が似てるから
プロトタイプをPHPで作成したほうが時短になるかと?
仮想コードによるアルゴリズムの記述やフローチャートなどに近い

**デフォルトの名無しさん** · 2021/11/29(月) 00:43:30.91

行列の掛け算とか対角化ならPythonかマキシマでいいとおもうが?
大規模だともしかしたらC++のほうが早いかもしれないが
PythonだとGoogle　ColaboratoryとかでGPUをネットワーク使用できたりするが

Colaboratory とは
Colaboratory（略称: Colab）は、ブラウザから Python を記述、実行できるサービスです。次の特長を備えています。
環境構築が不要
GPU への無料アクセス
簡単に共有
https://colab.research.google.com/notebooks/welcome.ipynb

**デフォルトの名無しさん** · 2021/11/29(月) 01:05:44.61

宣伝はお断りしています

**デフォルトの名無しさん** · 2021/11/29(月) 06:13:36.91

>>179
BLASというとvalarrayだね

**デフォルトの名無しさん** · 2021/11/29(月) 11:31:29.88

>>183
は？

**デフォルトの名無しさん** · 2021/11/29(月) 14:27:16.33

>PHPはC++のスクリプト版といえるかのように文法・関数が似てる

迷惑するから出鱈目言うな

**はちみつ餃子** ◆8X2XSCHEME · 2021/11/29(月) 14:43:58.00

因果が逆だろう。
似た使い方しかしない人間にとっては似て見えるということもあるんだろうさ。

**デフォルトの名無しさん** · 2021/11/29(月) 14:54:09.52

いや激しく誤解を生む情報だと思うｗ

**デフォルトの名無しさん** · 2021/11/29(月) 15:15:20.73

制御構文が似ていれば似ているように見える人というのは一定数いる
それしか使わないから

**デフォルトの名無しさん** · 2021/11/29(月) 15:19:08.39

C++のこともphpのことも両方ニワカじゃないとなかなか出てこない発言
昨日今日入門書めくってるくらいのレベルじゃないとなかなかできない発言

**デフォルトの名無しさん** · 2021/11/30(火) 09:50:00.96

template<class T>
void f(T x) {
auto a = x, b = 0;
}

f(0.0);

これgccだとコンパイル通るけど規格的にはダメだよね？

**デフォルトの名無しさん** · 2021/11/30(火) 09:57:35.75

**デフォルトの名無しさん** · 2021/11/30(火) 10:46:34.33

何が駄目になるの？

**デフォルトの名無しさん** · 2021/11/30(火) 10:48:39.10

autoの推定がxから導かれるdoubleと0から導かれるintで矛盾しないかって話

**デフォルトの名無しさん** · 2021/11/30(火) 10:51:24.87

そもそも何の規格だよ
問題あるなら書き直せばいいだろ

**デフォルトの名無しさん** · 2021/11/30(火) 10:58:47.10

>>190
clは弾くぞ

**デフォルトの名無しさん** · 2021/11/30(火) 11:18:37.50

https://eel.is/c++draft/dcl.type.auto.deduct#def:placeholder_type_deduction
For a variable declared with a type that contains a placeholder type, T is the declared type of the variable.

https://eel.is/c++draft/dcl.spec.auto.general#7
The type of each declared variable is determined by placeholder type deduction, and if the type that replaces the placeholder type is not the same in each deduction, the program is ill-formed.

Draft これでいいか分からんけど、多分ダメですね
a と b は個別に型推論して、同一でなかったら ill-formed であると読める

**デフォルトの名無しさん** · 2021/11/30(火) 11:29:55.04

https://wandbox.org/permlink/GOps3Ikgl1VsvwoU
gcc6.3.0以下とclangだとちゃんとエラーになるな

**デフォルトの名無しさん** · 2021/11/30(火) 11:33:54.11

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79009

**デフォルトの名無しさん** · 2021/11/30(火) 11:34:06.53

0の部分static_castしなきゃ駄目ということか。なるほど

**デフォルトの名無しさん** · 2021/11/30(火) 13:11:18.23

g++ 10.3.0は-pedantic指定しても通すな

**デフォルトの名無しさん** · 2021/11/30(火) 13:27:36.30

バカか
0は何にだって成れるだろ

**デフォルトの名無しさん** · 2021/11/30(火) 13:38:43.96

C++とPHPが似てないというニカワかと?
Pythonやルビーやjavascriptよりも似てるだろ?
C++にある関数をそのままPHPでも使えるようにしてあるのが多いし

**デフォルトの名無しさん** · 2021/11/30(火) 13:39:41.94

>>201
これやってみ
cout << typeid(0).name();

**デフォルトの名無しさん** · 2021/11/30(火) 14:06:04.92

>>202
そんなだから馬鹿って言われるんだ

**デフォルトの名無しさん** · 2021/11/30(火) 18:50:06.68

C++Builder使った後にVisual Studio使って、
二層作ったらC++Builderがめちゃくちゃ簡単で
作りやすかったんですけど私の感覚、何か変？
Visual Studioより効率いい気がしました。

**デフォルトの名無しさん** · 2021/11/30(火) 19:29:52.87

20年以上前ならいざしらず今C++Builderなんて使おうとする人は変としか・・・

**デフォルトの名無しさん** · 2021/11/30(火) 19:37:40.43

普通はRust使うよね。

**デフォルトの名無しさん** · 2021/11/30(火) 19:38:36.27

くそ言語Rust

**デフォルトの名無しさん** · 2021/11/30(火) 19:52:55.16

c#だろ
バカめが

**デフォルトの名無しさん** · 2021/11/30(火) 20:01:01.54

20年以上前は言い過ぎ
自分は2009を大事に使っている

**デフォルトの名無しさん** · 2021/11/30(火) 21:27:19.33

うちでは2000年以降のborlandはそれ以前に開発されたものの保守以外で使用することはなかったから
2000年以前でもほぼMSVCの独壇場だった

**デフォルトの名無しさん** · 2021/11/30(火) 21:31:10.33

BuilderというよりRAD Studioやろ？

**デフォルトの名無しさん** · 2021/12/01(水) 23:25:36.03

>>14
数学記号増やしたところで、数学記号はレイアウトの問題がかなりついて回るのであまり意味ないと思うけどなあ。2^2^2^2とか、定積分とか、分数とか表現できないでしょ。
そういうのは組版の問題。
まあ、たしかにイタリックのxとかはあるのに、イタリック(?)のπはないとかは、中途半端な気はするけどね。

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

std::set にラムダ式渡すとき
std::set<T, decltype(comp)> s(comp);
ってなるのダサすぎるんだけどどうにかならない？
std::set<T> s([](T x, T y) { return x < y; });
みたいに直接書きたい

make_set みたいな関数テンプレート用意すれば解決するのはわかるんだけどクラステンプレートだとどうしてダメなんだ

あとこれが自作クラスだった場合推論補助とかでどうにかできるんだろうか

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

>>214
これなら通るんだけど
template <typename T> std::set(T(&)(T,T)) -> std::set<T, T(&)(T,T)>;
int comp(int x, int y) { return x < y; }
std::set s(comp);

compをラムダやテンプレートにするとdeductionに失敗するね

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

>>213
だからさー、あなたが使うフォントで期待したπが表示されないのはフォントのデザイナの問題であってunicodeの問題じゃない
ちゃんと区別できるようになってるんだから

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

>>214 std::function<bool (T,T)> 使っちゃダメなの？

**デフォルトの名無しさん** · 2021/12/02(木) 15:14:03.44

πの人まだいたんだなω