C++相談室 part158

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

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

**デフォルトの名無しさん** · 2021/11/17(水) 19:44:58.31

答えは相手が握ってるので俺がただしいなどありえない

**デフォルトの名無しさん** · 2021/11/17(水) 19:45:13.10

まちがえた

**デフォルトの名無しさん** · 2021/11/17(水) 22:47:12.58

Unicodeとか文字とグリフの区別がぐちゃぐちゃになりつつあるとい
う印象、ど
うしてこうなった？！

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

>>41
いや、円周率を、パイという記号で表すのは中学生でも知っている訳で、
あのおなじみの形状が安定して表示できない段階で文字コードとして終わってる。
文字数の制約があるならまだしも、誰も使わないような漢字や、その場しのぎの
ふざけた記号が大量に含まれているのに、円周率という誰でも知っていて
記号が絶対にあの記号で無ければ伝わらないものに対して、ちゃんとした
記号が安定したコードポイントにはどこにも割り当てられてないのは
大問題。
中国語の文字と日本語の文字の違いよりも影響はずっと大きい。

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

いいかげんにしろよ
・見た目を決めるのはフォントの仕事であってUnicodeのコードポイント割り当てに文句付けるのはお門違い
・そもそも数学記号用のコードポイントはギリシャ文字とは別にちゃんと割り当てられてる（Mathematical Alphanumeric Symbols）
・ここはC++スレだスレ違い消えろお前の巣はこれだ→https://mevius.5ch.net/test/read.cgi/tech/1593777227/

**デフォルトの名無しさん** · 2021/11/18(木) 01:08:04.34

>>46
実際にはちゃんと割り当てられてない。
しかも、フォントの仕事である、と切り分けるのも問題。
というのは、現実に、円周率としては決して使っては成らない
おかしなフォントがパイの自に割り当てられていて、それを回避する方法が
ない。なので、まともなパイのフォントを自作するか、画像ファイルを
用意して画像を挿入するしか方法が無い。

**デフォルトの名無しさん** · 2021/11/18(木) 01:21:19.65

>>47
他の文字コードならそれが回避できるとでもいうんけ？
あほか。

**デフォルトの名無しさん** · 2021/11/18(木) 01:36:35.92

>>48
まず、円周率の記号は、ギリシャ文字のパイならなんでもいいというわけではないこと
を文字コードやフォントを作ってる人が理解することから始めなければならない。
また、数学で同値記号で使う矢印は矢印だったら何でも良いという訳ではなく、
左右と上下の区別と、二重線か一重線かという好みの問題も含めて、
固定的なフォントでなくてはならない。二重線の場合、中は白抜きでなくては
ならないので、決して塗りつぶすべきではない。

そういうことを理解してない人が文字コードやフォントを作る資格はないのに、
アメリカ人はそれをやってしまってる。アメリカ人は何もかもおかしい。
クラフトマンシップが無い。

**ハノン** ◆QZaw55cn4c · 2021/11/18(木) 01:40:47.32

>>49
アメリカ人が悪いわけではない、数学者を文字コード制定に加えなかった馬鹿どもがアメリカ人の中にもいる、というだけ、それがどのような属性の人間か容易に推測できるだろう？
というか、TeX をそのまま持ってこればいいだけの話なのにそれすらわからないのは、どういったわけなんだ？

**デフォルトの名無しさん** · 2021/11/18(木) 01:42:39.93

>>49
知らんがな。
それはアプリケーションで解決しろと言ってる。

**デフォルトの名無しさん** · 2021/11/18(木) 01:47:08.17

>>50
あなたは、物を知らない。
TeXも実はあまり綺麗ではないし、日本で標準に使われていた数学記号を表示しにくい。
最初、同値記号が長すぎたり、左右方向しかないことにまず、つまずき易い。
回避作が全く無いわけではないが。
近似的に等しいの記号も、日本で馴染みのある上下に点々を打つものは表示しにくい
とかもあるし。
円周率のパイと空集合はさすがに表示できるが。

**デフォルトの名無しさん** · 2021/11/18(木) 01:48:39.42

日本人が作っていたソフトには、良いソフトが多かった。
アメリカ人がそれを潰した。
というか、日本人が日本製のソフトを買わない。
例え良いソフトがあっても。
わけが分からん。

**ハノン** ◆QZaw55cn4c · 2021/11/18(木) 02:04:24.47

>>52
≒ \risingdotseq \fallingdotseq
⇔ \Leftrightarrow
上下方向同値は、なければないでなんとかなるのでは？

**デフォルトの名無しさん** · 2021/11/18(木) 02:12:19.27

数学数学うるさいくせにいつまでも用語使いがいい加減なままなのはどういうわけだ
そろそろ文字・記号・文字コード・コードポイント・グリフ・フォント・書体の定義くらい理解して使い分けろよ

**デフォルトの名無しさん** · 2021/11/18(木) 02:23:27.66

>>55
グリフとフォントの違いはいくら調べても、あまり分からなかった。
コードポイントは分かる。
しかし、コードポイントに単にギリシャ文字の「パイ」を割り当てていても、
円周率用におなじみのパイであるとは限らず、実際にWindowsでは、門構え
のような変な文字になってしまってる。
そして、それを回避するのは難しい。

**デフォルトの名無しさん** · 2021/11/18(木) 02:26:19.78

字体と字形は違うという話もある。
漢字の場合は確かにそうかもしれない。
しかし、数学では最後の形が重要だから、最後の最後の最後の画面上に表示される
グラフィックが、数学の習慣にぴったり一致してなければ駄目。

**デフォルトの名無しさん** · 2021/11/18(木) 07:48:03.24

円周率にギリシャ文字のπを充てた数学が悪い、数学は俺々円周率記号を作るべきだった
って言ってる？

**デフォルトの名無しさん** · 2021/11/18(木) 07:57:54.58

auto \u03c0 = std::numbers::pi;

**デフォルトの名無しさん** · 2021/11/18(木) 09:43:04.76

コードは別れてるのだから、あとはデザイナの問題、フォント使用者の問題だろ
外人が作ったフォントの"ゐ"の字が"い"と同じだったからunicodeに"ゐ"の字を安定的に出せるようにしろっていうのはお門違い

**デフォルトの名無しさん** · 2021/11/18(木) 09:55:03.61

お前らおっぱいの形で何を興奮してるんだ？w
この変態どもめw

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

おっぱいに興奮するのは正常な性欲で変態じゃないぞ
あ、変態から見るとノーマルが変態なのかｗ

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

うちのπは変換選択中は数学記号のπで一覧に出てるんだが変換確定すると門構えのπになるなω
アプリのフォントとIME(FEP)のフォントが違うんだろうなωωω

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

秀丸なら数学用のπだし
メモ帳だと門構えのπだったわ
TeX使ったらどうでもよくなるけど

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

とりあえず
メイリオは糞π
MS Gothic は数学用π
MS 明朝は数学用π
みかちゃんぎりぎりセーフ
Migu 1M 数学用π
IPAex Gothic 数学用π
IPAex 明朝数学用π

んーいまのところだめなのメイリオだけだなω

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

56はwindowsがって言ってんだから全部ダメなんだろ

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

>>56
>それを回避するのは難しい。

えっ？

**デフォルトの名無しさん** · 2021/11/18(木) 17:51:51.89

using namespace std;
するのとstd名前空間内の各エンティティについて
using std::foo;
するのに違いはありますか？

**デフォルトの名無しさん** · 2021/11/18(木) 21:59:19.03

はい。前者は std 内全部の名前が修飾なしで使えるようになりますが、後者は指定したものだけになります。

**デフォルトの名無しさん** · 2021/11/18(木) 23:09:08.75

明朝体とかゴシック体がフォント
明朝体で書かれた「あ」とゴシック体で書かれた「あ」は異なるグリフの「あ」
文字としては同じ

ということのはずだがユニコードはぐちゃらけてしま
ｔったど
うしてこなうった！？

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

ググったらJISで「♯」と「#」が異なる文字だからユニコードでも元に戻せるように異なるコードにしているとか
ﾜｹﾜｶﾒ
一昔前の似たような文字を同じコードにする方針な美しいユニコードはどこいった……？！

**デフォルトの名無しさん** · 2021/11/18(木) 23:12:14.00

訂正orz
△：異なるコード
○：異なる文字

**デフォルトの名無しさん** · 2021/11/19(金) 00:01:43.17

>>71
シャープとナンバーサインは違う記号で違う意味でしょ。
カタカナの「ロ」と漢字の「口」まで統合されかかったというエピソードもあるんだが、
そういうのが Unicode の美しさだと思うか？

何を以て「似たような文字」とするか文字に対する考え方というのは
それぞれの文化によるによるので既に確立している符号体系を尊重するのは合理的な方針なんだよ。
歴史的経緯を切り捨てられないのは不格好だが逆に言えば既存の不格好さを継承する程度で済む。

**デフォルトの名無しさん** · 2021/11/19(金) 08:12:17.83

>>71
CJK統合漢字の大失敗に懲りたんだろ。

**デフォルトの名無しさん** · 2021/11/19(金) 09:07:31.36

ここC++のスレだよな？

**デフォルトの名無しさん** · 2021/11/19(金) 10:51:32.62

そうだよスレ違いのUnicode叩きも擁護も出て行け

**デフォルトの名無しさん** · 2021/11/19(金) 11:12:38.26

♯include は動かない方が良い
\ も mac だとやばい \ があるらしいなω

**デフォルトの名無しさん** · 2021/11/19(金) 11:14:02.03

codepadだかideoneだかが
\nを勝手に半角の￥nにしてコンパイル通らなくて可笑しいときがある

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

>>77
素人丸出しだからそのへんでやめとけ
\が(過去の経緯で)本来あるべきグリフで表示されないのはwindows(日本語設定時のみ)のほう

**はちみつ餃子** ◆8X2XSCHEME · 2021/11/19(金) 13:02:30.99

JIS X 0201 (7ビット及び8ビットの情報交換用符号化文字集合) による。
JIS X 3010 (プログラミング言語C) の中でもスラッシュとチルダが JIS X 0201 では円記号とオーバーラインに
置き換えられる旨の補足情報が書かれている。

つまり Windows の挙動は日本の (文字コードに関する) 規格を尊重した結果だし、C の JIS 規格でもちゃんと言及している。
とはいえ ISO/IEC 9899 に反する事情があるからこそ日本の規格 (JIS) にするにあたって補足を入れる必要があったわけで、
「本来あるべき」から遠いのは確かに Windows のほうとは言える。

**デフォルトの名無しさん** · 2021/11/19(金) 14:07:51.51

>>79
知ってると思うが
これの話なんだが
http://codepad.org/WsmFWVty
#include <stdio.h>

int main()
{
printf("abc\n");
return 0;
}

**デフォルトの名無しさん** · 2021/11/19(金) 14:10:16.50

>>79
これも一緒ね
https://ideone.com/KyjIyk
どうでも良いけどω

**デフォルトの名無しさん** · 2021/11/19(金) 15:13:48.52

どうでもいいのは勘違いしてるお前の話

**デフォルトの名無しさん** · 2021/11/19(金) 17:22:13.91

アホすぎる
C++の話しようぜ

**デフォルトの名無しさん** · 2021/11/19(金) 18:47:23.14

WindowsのvisualC++2019でDLLのロードが出来ません
dll defからlibをつくり#pragma comment( lib, "sample" )とやればできた記憶なんですが
64bitのバージョンも全部合わせてあるんですが
10年ぶりにやったら動きません
ボーランドC++だと修飾名が変わってdefを書き換えたりはあったと思うのですが

> error LNK2019: 未解決の外部シンボル sqlite3_open

85 · 2021/11/19(金) 18:53:32.17

自己解決しました
dumpbin.exe /exports　コマンドでdefファイルを作成した場合、
EXPORTS の記述がなかったからでした

**デフォルトの名無しさん** · 2021/11/20(土) 00:18:32.03

>>81
エスケープを円で覚えてるからそんな間抜けな間違いするんだよ
ブログラマならエディタの設定変えとけ

**デフォルトの名無しさん** · 2021/11/20(土) 04:22:38.39

>>81
馬鹿過ぎて

**デフォルトの名無しさん** · 2021/11/20(土) 11:48:10.21

>>87
ブログラマってなにかの隠語？

**デフォルトの名無しさん** · 2021/11/20(土) 12:05:58.69

ﾅﾆﾅﾆ
　　　彡⌒ ミ　ﾅﾆﾅﾆ
　　　(´･ω･`) 彡⌒ミ
,彡⌒ 彡⌒ ミ (・ω・｀)　また文字ｺｰﾄﾞの話？
(´・ω(´･ω･`) ⌒ ミﾉ⌒ミ
　ｕ＿|￣￣||´･ω･`)ω・｀) ﾏﾀｰ?
　／旦|――||/／／|とﾉ
　|￣￣￣￣￣|￣| . |-ｕ
　|＿＿＿＿＿|三|／

**デフォルトの名無しさん** · 2021/11/20(土) 19:11:01.64

>>90
プログラマ＝ハゲと思われるからそのAAやめろよ(´･ω･｀)

**デフォルトの名無しさん** · 2021/11/21(日) 03:33:39.04

実際C++プログラマはハゲが多いんだから別にいいだろう
教祖からしてハゲなんだし

**デフォルトの名無しさん** · 2021/11/21(日) 08:40:03.48

そうそう、教祖がゲーハー
これはデカい

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

Greek PhiはU+03A6(大文字)・U+03C6(小文字)・U+03D5(数学用シンボル)
Empty setはU+2205
全く別のコードポイントが割り当てられてるし、>>19の資料でも全く別の文字として議論されてるけど
何を見て何がどう区別されてないと思った？

**デフォルトの名無しさん** · 2021/11/21(日) 20:56:14.20

プログラミング言語の世代論というのがあって、
第一世代は CPU のアーキテクチャべったりの機械語、
第二世代は機械語が解る人間向きの低級言語、
第三世代は自然言語寄りの高級言語、
第四世代は目的型言語、
…… で、いわゆる「第五世代」は、コンピュータの都合じゃなくて
人間の都合に合わせようよ、というコンセプトになった。
「じゃあ、どのあたりから始めるか」という話は
ありそうに思う。

**デフォルトの名無しさん** · 2021/11/21(日) 22:09:51.70

>>79
素人丸出しとか言ってるが
実際macだと設定によってはバックスラッシュと同じ扱いにならない\が
普通にキー叩いたら出るんだぞ

**デフォルトの名無しさん** · 2021/11/21(日) 22:16:19.52

エスケープが円だと思ってるから間違えるんだろ

**デフォルトの名無しさん** · 2021/11/21(日) 22:42:33.87

普段からU+005Cのグリフがバックスラッシュになってるフォントしか使わないから円記号に違和感しかない

そりゃ個人の自由だけどプログラミングしてるなら少しフォントにこだわってもいいと思う

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

日時を数値に変換する良い感じの関数教えてくださいよ

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

std::chrono

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

おどろき最小の法則と言えば
https://onihusube.hatenaぶろぐ.com/entry/2020/04/03/211442

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

人を下に見られる程精通してる人って正直羨ましいわ
知れば知るほどまだまだ知らない事が沢山あるなぁと勉強不足を実感してしまう
↓
知らないから人をバカに出来るんだよなー
↑
むしろ人を下にみないと精神状態が不安定なんでしょ

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

ダニングクルーガーね

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

Windows App SDK入れてみたがエラーが多くまだ使えない

**デフォルトの名無しさん** · 2021/11/22(月) 19:04:02.58

ヘッダファイルで変数の宣言するとき、引数付きのコンストラクタ使おうとするとコンパイルエラー出るんですけどこの書き方って良くないんですか？

**ハノン** ◆QZaw55cn4c · 2021/11/22(月) 19:08:25.29

>>105
ヘッダだからエラー、というわけではないです
ヘッダじゃない普通の cpp に書いてもエラーなのでは？
具体的にソースを示してください

**デフォルトの名無しさん** · 2021/11/22(月) 20:43:52.70

>>106
// NG ヘッダにそのまま書こうとすると型指定子が必要ですとエラーが出る
private:
MenberLibClasse obj ("piyopiyo");

// OK ヘッダには引数なしで宣言した後、cppでobjをメンバに持つクラスのコンストラクタの初期化子リストを使うと何故か通る
private:
MenberLibClasse obj;
Class() :obj ("piyopiyo") { }

挙動把握しきれないんですけどライブラリ側の問題でしょうか？？

**ハノン** ◆QZaw55cn4c · 2021/11/22(月) 20:50:48.90

>>107
NG のときのエラーの内容は？
エラーメッセージを貼ってください、正直、よくわかりません

**デフォルトの名無しさん** · 2021/11/22(月) 20:56:23.56

>>107
宣言の位置でメンバを初期化できるのはC++11からだけど、それが原因かな？

**デフォルトの名無しさん** · 2021/11/22(月) 20:59:28.54

書くとしたらこうやろ
private:
MenberLibClasse obj = "piyopiyo";

**デフォルトの名無しさん** · 2021/11/22(月) 21:02:09.68

丸括弧はダメだよ
イコールか波括弧でなきゃ

**デフォルトの名無しさん** · 2021/11/22(月) 21:04:04.13

型指定子が必要って言われるのは
関数宣言と見られていて
仮引数の場所にリテラルがあるってことだ

**デフォルトの名無しさん** · 2021/11/22(月) 21:13:00.22

>>111
イコールはダメで波括弧に変えたらコンパイルできました

**デフォルトの名無しさん** · 2021/11/22(月) 21:30:02.05

private:
MenberLibClasse obj{"piyopiyo"};

**デフォルトの名無しさん** · 2021/11/22(月) 23:03:46.80

>>99
using namespace std::chrono;

// 現在時刻を取得
system_clock::time_point tp = system_clock::now();

// 現在時刻のミリ秒部分を取得
auto msec = duration_cast<milliseconds>(tp.time_since_epoch()).count() % 1000;

みたいなことをやると良い最後のまmillisecondでもsecondでもnanosecondでも逝ける

こないだ死ぬほどやり倒すた、

しかしずんねんながら現状MSVCのstd::chrono::zoned_timeが未実装のため、

システム時刻関連処理についてstd::chronoの利用を断念すた、orz

**デフォルトの名無しさん** · 2021/11/22(月) 23:16:45.51

なおtime_point同士で引き算もできる
結果を具体的時間単位の時間表現にするのは同じくduration_cast<T>()

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

ostringstream の precision の上限がなぜか 255 に設定されているようで
mpreal big("1000桁規模の浮動小数点数");
ostringstream ss;
ss.precision(1000);
ss << big;
とすると ss に 255 文字程度しか入らないのです
cout.precision(1000);
cout << big;
だと 1000桁出ます
ostringstream の precision の上限をもっと大きくする方法はありますか？

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

ああ
勘違いかも
もうちょっと調べて質問します

**デフォルトの名無しさん** · 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