C++相談室 part158

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

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

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

前スレが在るのに後ろスレが無い。

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

江添のハブ
https://github.com/EzoeRyou

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

Windows10でrecursive_directory_iterator使うと全角ファイル名が化けまくるんだけど
これwstringバージョンないよね
使い物にならないってこと？

**ハノン** ◆QZaw55cn4c · 2021/11/15(月) 22:13:18.15

>>4
Windows でファイルシステムを操作するなら、もう utf16／W 系を陽に使うしかないのでは
https://mevius.5ch.net/test/read.cgi/tech/1434079972/53

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

江添さんもRustに行ってしまわれたか。

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

なんにも確認してないがrecursive_directory_iteratorはpath扱うだけのはずで
wstring云々いいだすのがもう怪しい

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

だからそう言ってるんだけど

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

アメ公は多言語のことはあまり考えてないからな

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

wstringなら解決すると思ってる時点で頭可笑しい

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

全世界の文字集めたらWORDじゃ足りないことくらいアメ公でなければすぐわかりそうだが

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

>>11
でも、ハングル文字は、28文字しかないのに 5000ポイントも使っていたり、
元々文字じゃなかった絵文字を勝手に文字の様に扱ったりして行って
肥大化しただけで、世界の文字自体はそんなに多くない。
ユニコードの文字の扱い方に問題が有るんだと思う。

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

>>12
ハングルは、子音、母音、パッチムは、それぞれ20～30程度しかないが、
それを組み合わせて1文字に組み立てられているらしくて、組み合わせ爆発で、
1万1000文字を越える。
全ての組み合わせが使われているわけではない。
また、実際に使用される文字は2500文字ほどらしい。
表意文字である漢字は、どうしようもないが、単なる表音文字に過ぎない
ハングルに、Unicodeは、1万1000ポイント以上を割り当ててしまってる。

しかし、漢字も滅多に使わない文字を含めても1万5000文字くらいで、
アラビア文字も28文字くらいしかないそうだから、世界で使われている
本当の文字は、恐らく、4万文字もあれば足りるはず。

ユニコードが16BITで表しきれない以上に厄介なのは、UTF8で表現した時に、
50文字しかないひらがなまで 3バイトになっていること。
カタカナまであわせても100程度しかないのに。
さすがに、アメリカ人の傲慢さを感じざるを得ない。

こんな文字コードを一生使い続けると考えるとうんざりするので、
多分、これが終わりではないだろう。
むしろ、これで終わりにしてはならない。

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

[追加]
ユニコードの文字数が多い点に関して:
・16BITで表現できない文字の大部分は絵文字。
・数学記号などは数学を扱う時に必須なのに、重要な数学記号が沢山不足している。
　つまり、非常に使用頻度が高い記号が含まれてない。
・逆にどうでもいいような変な遊びの記号などが大量に入っている。
　別にそれはグラフィックで書けばいいのに。

数学記号などは文書の中でも使えるし、学問的にも昔から良く使われているのに
なぜかユニコードには含まれてないものが沢山ある。
それに、呼び方や起源は同じでても、数学的には異なる意味を持つコードが1つに
割り当てられていたり、πが四角く表示されて、数学では絶対に使わないグリフ
になってしまっていたりする。
基礎的な数学まで知らないばかが考えたとしか思えないし、それが
何十年間も改善されてない。
ユニコードは欠陥コード。

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

>>14
円周率の意味での「パイ」(PI)は、数学では必ず小文字で、かつ、丸みを帯びた
おなじみの記号を使い、決して、門構えのようなπは使わないし、
数学の本では見た事が無い。しかし、ユニコードではそれが標準になっており、
誰が使うのという感じがする。

もう一つは、φの記号。物理学で、磁束を表すのは、くるっと回るφ。
数学の空集合のファイは、ドーナツに棒を貫通させたようなグリフ。
しかし、ユニコードでは両者の区別が訳が分からないことになっていて、
困る。

あとは、⇔の記号が、横方向はあるが、縦方向が無いらしいこと。
これは最悪。

**デフォルトの名無しさん** · 2021/11/16(火) 12:42:55.75

空集合記号とギリシャ文字のファイを混同してるような無知に文句つけられてUnicodeも大変だな

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

TeX

**デフォルトの名無しさん** · 2021/11/16(火) 14:00:17.37

ΦφФфΦɸØø∅⌀

Φ
Φ
Φ

φ
φ
φ

ϕ
ϕ

**デフォルトの名無しさん** · 2021/11/16(火) 14:03:02.78

http://unicode.org/reports/tr25/

**はちみつ餃子** ◆8X2XSCHEME · 2021/11/16(火) 15:34:16.32

そもそもが世界中の言語の発展は場当たり的な習慣の積み重ねを何千・何万年と続けてきてグダグダなんだから
それをどうがんばって整理しようとしたところでグダグダなんだわ。
元からグダグダだったのが Unicode のグダグダさとしても表れてきただけ。
言語ごと作り直しでもしない限り綺麗な符号体系にならないんで、
グダグダさと折り合いをつけてつきあっていくしかしょうがない。

**デフォルトの名無しさん** · 2021/11/16(火) 15:36:04.02

>>16
Unicodeではちゃんと区別されて無いだろ。

**デフォルトの名無しさん** · 2021/11/16(火) 15:36:33.85

>>20
いや、Unicodeに問題がある。

**デフォルトの名無しさん** · 2021/11/16(火) 15:37:58.58

>>18
数学の空集合の記号とは違ってる。
どうせ、パイ(π)は四角い変なグリフで、数学では絶対使えない。

**デフォルトの名無しさん** · 2021/11/16(火) 15:54:46.23

http://unicode.org/reports/tr25/
ここの
empty set でもだめ？

**デフォルトの名無しさん** · 2021/11/16(火) 15:56:48.89

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

**デフォルトの名無しさん** · 2021/11/16(火) 17:48:24.19

unicodeで一番困るのがソート
単純にコードの大小でソートするとおかしな事になるからな

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

>>25
調べてみたが、そもそもグリフが安定していないから数学では使えない。
数学ではグリフによって意味を分けているから。

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

そもそも、数学では縦棒が斜めになっているか、縦になっているかでもニュアンス
が違うことがある。
特に空集合の場合、斜めになっていないと、普通の数学的な感覚には
合わない。完全に垂直だと駄目だ。
それに、イタリック体と普通のプレインな書体も、明確に区別できるようになって
ないと、プログラムの本でも使えない。
たとえば、BNFなんかでもそう。
遊びでグリフを変えてもらっては使い物にならない。
後は、カンマの横幅を勝手に狭くするのはプログラマー泣かせ。
カンマは飾りじゃなくて、あるのと無いのとでは大違いだし、
ピリオドと完全に区別できなくてはならないのに、狭すぎて連続した
場合に、フォントが小さい時、非常に判別しにくいことがある。
フォントを作る人は大学以降の数学や物理学に詳しい人に絶対に
聞いて欲しい。

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

Appleのスティーブジョブスのせいで、プロポーショナルフォントが多くなり。
それをIDEなんかでも使う馬鹿(=MSのプログラマ)がいて、もうアホかと。
空白は有るのかないのか分からないし、からの「～」が、上の方にある
チルド~に見えたり、カンマは狭すぎていくつあるのか数えられない、
円周率のπは、数学では決して使うことのない門構えのようなグリフだし。
遊びで変えるな。
芸術ではないんだ、厳密に区別しないといけないんだ、プログラムも
数学も。

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

それはUnicodeじゃなくてフォントの問題なのでは

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

コードポイントとグリフとフォントの区別すらついてない無知蒙昧丸出しで
よくもまあそんな意味のない長文を恥ずかしげもなくグダグダ書き散らかせるもんだ
その度胸だけは褒めたるから、Unicodeに物申す前に基礎から勉強しろよ

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

>>31
分かってないのはお前だろ。

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

>>31
分かってないのはお前だろ。

**デフォルトの名無しさん** · 2021/11/16(火) 19:02:52.69

>芸術ではないんだ、厳密に区別しないといけないんだ、プログラムも
>数学も。
フォントとグリフと書体をこちゃ混ぜにしてる人間がこれ書いてんのギャグだなw

**デフォルトの名無しさん** · 2021/11/16(火) 19:08:30.21

3回もNGさせんなゴミ

**デフォルトの名無しさん** · 2021/11/16(火) 19:44:20.16

ユニコードを内包する世界最大の文字集合がGB18030。

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

漏れが書いたように思われそうだがちげう
記念ﾊﾟﾋﾟｺ

**デフォルトの名無しさん** · 2021/11/17(水) 07:02:28.15

自意識過剰

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

>>36
ハングルを3000文字くらいと、コンポジションに落とし込めなかったのは人類史における、、、まーいーや終わったことだ。
まぁMacでファイル名読むと「パ」が「ハ」と「゜」に割れてマジビビったけどな。

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

https://0g0.org/category/13000-1342F/1/
ቻﾝቻﾝがቺቻቺቻ

**デフォルトの名無しさん** · 2021/11/17(水) 15:31:08.88

>>27
Unicode は言語情報を保持しない。
いわゆる中華フォント問題が起こるのはテキストだけからは日本語フォントを適用すべきなのか
中国語フォント (あるいは他の言語) を適用すべきなのかわからないからで、
そのあたりはアプリケーションレイヤで解決する想定になっている。

文字の形が重要なアプリケーションでそれができてないなら単にアプリケーションがカスってだけ。

ギリシャ文字のパイと数学記号のパイも個別に符号を割り当てるべきではないが、
Unicode は既存の文字コードを統合することという要件が現実問題として有るために
既存の文字コードで区別している例があると区別せざるを得ない。

文字コードとしての理想の姿と、
まずは皆が Unicode という規格に載ってこないと理想もクソもねぇという板挟みがある。

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

**デフォルトの名無しさん** · 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指定しても通すな