C++相談室 part164

2023/05/09(火) 11:50:52.06

!extend:checked:vvvvv:1000:512
!extend:checked:vvvvv:1000:512
↑同じ内容を3行貼り付けること

次スレは>>980が立てること
無理なら細かく安価指定

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

VIPQ2_EXTDAT: checked:vvvvv:1000:512:: EXT was configured

2023/06/23(金) 08:10:40.98

変数の生命期間よりも前に絶つのは new したものを delete する方法しかないよ

std::vector* pA = new std::vector();
std::vector& A = *pA;
　：
　Aで操作
　：
delete pA;
この後 Aに対して操作すると鼻から悪魔

2023/06/23(金) 08:36:05.01

auto&& A { *new std::vector<int>(0) };
delete &A;
これで「実体」のように偽装はできるけど
こんなコード書くやついたらグーパンだよ

2023/06/23(金) 08:38:29.90

このスレ読んでると目の裏がチカチカしてくるなｗ

2023/06/23(金) 08:46:52.36

>>305
極論すれば、と言っているだろ。
せめて反例ぐらい出せよ。

2023/06/23(金) 09:45:42.49

反例っておまえ・・・

静的変数

2023/06/23(金) 10:11:58.67

>>299
deleteで何をしたいかによるな
deleteは
・デストラクタを呼び出して
・メモリを開放する
という2つの動作が含まれるが、「メモリを開放する」に関しては、確保されてもいないメモリはもちろん開放できないが、
デストラクタは実体としてはただの関数なので、普通に呼び出すことは可能
ただし、メモリが開放される（deleteされる）時にもデストラクタはもちろん呼び出されるので、2重に呼び出しても大丈夫なように設計されたクラスである必要はある

2023/06/23(金) 11:56:54.20

>>299
スコープを終わらせれば消える

2023/06/23(金) 13:49:52.85

Windows11でc++の開発したいんですけど開発環境何を選べばいいですか？
ちなみに趣味でおもちゃ言語のコンパイラを書こうと思います

2023/06/23(金) 14:29:49.42

wslのclangでいいんじゃないの

2023/06/23(金) 14:40:39.89

>>311
> 2重に呼び出しても大丈夫なように設計されたクラスである必要はある
trivial destructor 以外は（空の ~T() {} 含め）どうがんばっても大丈夫にはならず未定義動作となる模様。
https://timsong-cpp.github.io/cppwp/n4868/basic.life#9.sentence-1

2023/06/23(金) 14:42:57.84

>>314
visual studioでできませんか？
visual studioに依存しないような形で

2023/06/23(金) 14:49:06.12

>>316
依存するかしないかはプログラマが気を付けることだろ

2023/06/23(金) 14:58:36.88

>>316
つーか俺はVisual Studioを推奨する
コンパイラ本体が昔からしっかりしてるし
デバッガは無数の信者を抱えるクオリティ

2023/06/23(金) 15:11:25.32

俺はコンパイラは複数を利用するのが好ましいと思う。
気を付けてても処理系に依存している (または未定義を踏んでいる) こともある。
いくつかのコンパイラで試してみれば問題点を発見しやすい。

発現した問題についてはデバッガなりなんなりで追えばいいんだが、
問題が潜伏したまま表面に現れないってのは後になってじわじわ効いてきたりするし……。

2023/06/23(金) 16:11:46.79

>>299
デストラクタに直接リソース解放させるより
リソース解放用の dispose() みたいな関数を造っておいて
デストラクタから dispose() 呼ぶのと同時に
delete しないで dispose() だけ外から呼ぶ設計もあるよ

2023/06/23(金) 16:14:47.39

>>313
Code::Blocks (+ mingw)

2023/06/23(金) 18:47:00.64

コンパイラの本なにがいいのかオススメ聞いたらオッサンに聞いたら怪獣が書いてある本って云われて本屋行って買ったらあとで付録のFDD誰かにかっぱわられていタコとに気付いたけどその本一冊ではなんの役にも立たないクソみたいな本だったわ
そのあとオライリーのyacc&lexの本と早乙女氏のBison&Flex本で学び直したわ

2023/06/23(金) 19:05:06.07

良く見たら全然違ったわw
https://i.imgur.com/DHAPVXR.jpg
yacc&lexが早乙女氏でBison&Flexが五月女氏でオライリーに似てるけどASCII出版やったわ

2023/06/23(金) 19:51:54.58

>>316
まず動くものを作ることに注力したほうがいい。
どうせ最初のコードは(問題領域の学習後に)捨てることになるから、プロトタイプと割り切るべき。あんまり頑張ると進捗悪くて挫折するし、うまく行ってもコンコルド効果で酷い目にあう。

>>310
確かに静的変数は自動だけど別物だな……よくやった。悔しいが褒めてやろう。

2023/06/23(金) 22:40:53.53

>>324
？？？
storage duration は四種類の内の「ひとつ」であることは直接的に明記されていて解釈の余地がない。
https://timsong-cpp.github.io/cppwp/n4861/basic.stc#1
兼ねる場合は存在しない。

2023/06/24(土) 08:29:33.32

>まず動くものを作ることに注力したほうがいい。
+1票

>いくつかのコンパイラで試してみれば問題点を発見しやすい。
これはその通りだけど、もっともっと先の話

2023/06/24(土) 09:51:19.10

動くといってもHello worldじゃあまりにもモチベーションに乏しいから
何でもいいから目的目標を持ったプログラムを書いたほうがいい

2023/06/24(土) 12:57:29.18

>>327
この話題の大元である >>313 でコンパイラを書くと書いてあるよ。

2023/06/24(土) 20:48:58.11

ドラゴンブックでは？
誤植を指摘できるくらい読み込めば古典は理解できてると思う

2023/06/27(火) 14:41:09.50

いつまでも初心者を抜け出せない人は初心者本を読み過ぎ

2023/06/27(火) 17:36:09.51

初心者本は【ど】初心者のうちだけにしとけ
謙虚なことはいいことだが、ここだけは背伸びしたほうがいい

初心者本で何か知ったら、それで禿本がどのくらい読めるようになったかやってみれ
禿本が普通に読めるようになったら次はISOの規格票

2023/06/27(火) 17:38:22.91

逆もしかり
ISOの規格票であえなくギブしたら禿本
禿本でギブのとき初心者本に戻る感じな

2023/06/27(火) 18:00:18.69

特にC++は下手な参考書より規格の方が分かりやすかったりするからな…

2023/06/27(火) 18:15:38.33

初心者へのアドバイスに禿本とかいう隠語をつかうのはどうかと思う

2023/06/27(火) 18:27:04.42

今独学でC++学んでいるんですが、たまたま見つけたサイトでint32_tとありましたが
int変数を宣言するのにint32_tなんて使いませんよね？
intでokですよね？

2023/06/27(火) 18:34:12.56

何に使うか次第

2023/06/27(火) 18:46:35.68

>>335
32ビット長である必要があるときだけint32_tを使えばいいよ

2023/06/27(火) 19:26:51.01

サンクス

2023/06/27(火) 19:30:48.55

>>335
int は言語仕様では少なくとも -32767 から 32767 を表現可能な幅 (つまり 16 ビット) を持つことが規定されている。
具体的な大きさは処理系定義であって、最低限である 16 ビットかもしれないしもっと大きいかもしれない。
扱おうとする値の範囲が 32 ビット分の幅が必要であると見積もったなら int32_t が適切なこともある。

ただ…… int32_t は「条件に合致する整数型を処理系が持っているなら必ず提供しなければならない」ということになっているので、逆に言えば 32 ビット幅の整数型を持たない処理系では int32_t が存在しないことが許される。
C++ は処理系定義ということにしている項目がたくさんあって移植性を考慮しようとするとすごく大変なんだが (プログラマが想定してさえいれば) ある程度に広く対応可能な仕組みとしてこういう回りくどいものがある。
初心者の内はとりあえず自分の環境で動くものを作れるようになるというので十分だと思うよ。

2023/06/28(水) 05:36:22.40

>>334
知らなきゃ聞くだろ

2023/06/28(水) 05:40:48.88

>>340
禿本って誰ですか？

2023/06/28(水) 07:54:48.30

Bjarne Stroustrup著　The C++ Programming Language
ISBN-10 4797375957

2023/06/28(水) 07:55:45.79

禿のブログ
https://www.stroustrup.com/

2023/06/28(水) 11:12:40.66

>>340
誰も知らないから隠語なんだよ
たまにいるよな、相手の知らないであろう単語を使ってマウントを取った気分になるやつ

2023/06/28(水) 12:11:22.15

>>340
検索すると別人の本が出てくるから駄目だろ。

2023/06/29(木) 00:03:54.47

C++でintと書けない理由はほぼほぼwindowsのintが32ビットと定義されているからで、
逆に言えば100% windowsで動かさないとあらかじめ分かっているならint使って書くよ

2023/06/29(木) 07:49:46.01

せいぜい数十までの整数でも、いちいちint8_tになんかしねえな

2023/06/29(木) 08:15:54.28

巨大な配列なら話は別だが単発の整数がレジスタより小さくても得なことが無いからな。

2023/06/29(木) 08:19:17.75

通信関連でペイロードにﾋﾞｯﾄ長指定されてるのなんかは int○_t 使っときたい

2023/06/29(木) 11:02:12.05

intでもshortでもCPUの計算速度は同じ

2023/06/29(木) 11:11:38.45

四則演算では int より小さい整数は int に拡張する変換が入ることになってるし、
int を受け取る関数でも当然に変換されるので
変換する処理の分だけ素朴なコンパイラだと short のほうがコスト高になる可能性もある。

2023/06/29(木) 11:21:22.19

言葉足らずだったな
初学者向けに正確にいえば
ビット数の低い数値の型にしたからといって
計算速度が速くなるワケじゃない

理由はハチミツ氏の記述通り

2023/06/29(木) 17:52:26.59

型のサイズが大きいほどキャッシュミスの確率が上がるし
ベクトル化の効率も関わってくるから話はそう簡単でもないけどな

2023/06/29(木) 18:01:09.64

チューニングが必要になったら実測しろってのはそういうことよな。
やってみるまでわからん。

2023/06/30(金) 13:08:37.59

やはり64bitCPUなら64bit整数が一番計算が速かったりするのかな

2023/06/30(金) 13:38:31.87

>>348
al、ah、axと小さなレジスタでやりくりすることによりスタックすらも使わずに複数の変数を操作することは可能になる
まあ汎用レジスタ数の多い64bitアプリではあんまりメリットにならんが

2023/06/30(金) 13:40:34.61

普通、intは32bitじゃないの？
普通の計算に64bitなんて使ったらキャッシュ効率悪すぎでしょ

2023/06/30(金) 15:06:59.18

多少のCPU内の計算速度差より、メモリアクセスのペナルティの方が遙かに影響でかいんだよね
昔、同じテキスト処理をsjisとutf16で速度比べたら、処理が複雑なはずのsjisの方がわずかに速かったこともあった

2023/06/30(金) 16:50:22.94

じゃあ16ビット整数使おうぜ！

2023/06/30(金) 18:10:36.60

ILP32
LLP64 windows: int32 long32 long long 64
LP64 unix: int32 long64 long long 64
ILP64 実装例なし

2023/06/30(金) 18:16:08.64

>>358
自作エディタの内部文字コードに悩んでるけどもしかしてUTF8がええのかな

2023/06/30(金) 18:31:33.16

>>361
utf8は日本語3バイトになるし、冗長コードの問題もあるし、処理がより煩雑になるから内部処理コードには一番向かないと思う
エディタなら素直にutf32（もしくは16）で持つのが良いような気がする

2023/06/30(金) 18:50:30.08

>>362
utf16はサロゲートペアがあるから避けたほうがいい。
簡単に実装するならutf32、メモリを節約するならutf8。だけど、utf8が覇権だからutf8にしたら？

2023/06/30(金) 18:53:22.37

今から新規にエディタ作るなら内部はUTF32一択でしょ
それ以外を使う理由がない

2023/06/30(金) 20:01:34.61

>>363
サロゲートペアの判定は簡単だし、utf32でも厳密には1文字＝1要素にはならないし、
メモリアクセス量との兼ね合いでより高速に動作しそうな気がするが…避ける理由がよく分からない

2023/06/30(金) 20:23:00.32

今どきは絵文字とかも絡んでくるから「簡単に実装」なんてそうそう言えないと思うんだよね
性別やら肌の色で修飾みたいな複雑仕様を網羅する必要があるから

2023/06/30(金) 21:27:23.31

Unicodeの処理なんてただでさえ魔境なんだから減らせる複雑性は減らしといた方が良いよ
悪いこと言わないからUTF32にしとけ

2023/07/01(土) 10:11:11.88

テキストエディタを自作すると一文字一文字の描画位置の計算を毎回しなければならず、結局全テキストをデータutf32形式で保持するのが楽という結論になりそう

2023/07/01(土) 10:21:22.63

そこまでやるとワープロやDTPの範疇では？

2023/07/01(土) 10:38:59.61

>>351
変換する処理ったって、普通static_castにコスト発生せんやろ

2023/07/01(土) 10:41:23.25

static_castというよりstatic_cast相当というべきか
もちろん浮動小数点数と整数だと命令いるけど

2023/07/01(土) 10:43:45.44

レジスタの拡張命令が必要になる
それはゼロコストではない

2023/07/01(土) 10:45:55.45

8bit,16bitの値を同サイズのレジスタに読む
それを32bitへ拡張する

2023/07/01(土) 10:49:09.01

そうなのか、知らんかった・・・

2023/07/01(土) 10:55:28.60

8bitしかないのに32bitで読むと当然ごみが入るので何かしないといけない
逆に8bitだけ読んで何もしないとこちらもレジスタにゴミが残ってる
何もしないで使える場合なにかしらの仕組みがある

そんなことするよりレジスタ拡張命令使った方がいい
通常の命令だけでなくてsimdにも用意されている

2023/07/01(土) 10:57:02.19

俺も >>367 の意見に賛成。
UTF-32 の採用で何もかも良くなるわけではないが
少なくともコードポイント単位での扱いは楽になる。

2023/07/01(土) 10:58:34.38

ちょうど Unicode 関連の本を読んでたんだが
右から左へ書く言語だとか
それが入れ子になってる場合だとか、
そういうのにちゃんと配慮したソフトウェアが世の中にあるのは
めちゃくちゃ頑張った人がいるんだなぁと有難みを感じてる。

2023/07/01(土) 12:18:01.21

日本語も右から左に書く言語だ
正確には上から下と右から左ニダ

2023/07/01(土) 12:20:52.99

BiDiモード

2023/07/01(土) 12:42:13.26

世界でも珍しい縦書き文化

2023/07/01(土) 15:53:40.98

UTF32派の人ってWin32でW系API通す時に毎回変換するってこと？

2023/07/01(土) 16:08:08.30

>>381
そうだよ。
作るアプリケーションがエディタ (またはシーケンシャルではない
テキスト操作をする何か) であるという前提を置いているときなら
という条件付きな話だが。

2023/07/01(土) 17:26:11.76

そもそもWin32でA系APIにutf8渡せないし

2023/07/01(土) 17:29:40.49

A系にはutf8渡せるんじゃないの？

2023/07/01(土) 17:36:11.93

渡せるという表現がまずかったかな
結果を気にしなければ、なんでも渡せるよ

2023/07/01(土) 17:43:00.61

>>384
Windows バージョン 1903 (2019 年 5 月の更新プログラム) 以降、ActiveCodePage プロパティを使って、プロセスのコードページとして UTF-8 を使うように強制できるようになりました。

2023/07/01(土) 19:58:04.79

A系はASCIIなのでunicode由来のutfもshift-jis などのMBCSも扱えない

2023/07/01(土) 20:10:31.66

>>387
最近までは、-A API がレガシと見なされていました。
これは、何十年もの間、Windows が "Unicode" -W バリアントを推進していたためです。
しかし、最近のリリースの Windows では、ANSI コードページと -A API を活用し、
新しい SKU で UTF-8 サポートを導入しています。 ANSI コードページが
UTF-8 に対して構成されている場合、-A API は UTF-8 で動作します。

**蟻人間** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd02-Ojup) · 2023/07/01(土) 20:13:40.75

>>387
以前からCP_ACPは日本語環境でシフトJISを扱えたはず。CP_ACPの解釈をCP_UTF8にすることができる設定と見なせる。

2023/07/01(土) 20:43:32.48

ASCIIしか考えてないアメリカ人の作ったプログラムでもUTF-8ならそれなりに動くよね
strlenが正確な文字数を返してくれるわけではないけども

**蟻人間** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd02-Ojup) · 2023/07/01(土) 20:55:13.36

WideCharToMultiByteとMultiByteToWideCharの第一引数に明示的にシフトJISのコードページ932を指定すればUTF-8な環境でも動く。

2023/07/01(土) 23:06:29.67

そうなの？
ただ単に変換APIの第一引数に明示的にシフトJISのコードページ932を指定しただけだと
とりわけWideCharToMultiByte()の場合、文字コードの自動判別が介在する余地もなく、
ウィンドーズ内部表現のUTF-16がシフトJISのコードページ932に（指定通りに）変換されるだけなんじゃないの……

M$のページ見たら
>マニフェストの ActiveCodePage プロパティを使って、プロセスのコードページとして UTF-8 を使うように強制できるようになりました。
>マニフェストの ActiveCodePage プロパティを使って
と書いてあった
マニフェストファイル変えたら中で何がどう切り替わるのかわ皆目わからんが、
ただ単に変換APIの第一引数に明示的にシフトJISのコードページ932を指定したら万事OKというよりは得心が行く

2023/07/02(日) 00:11:45.31

そういう話じゃない
～A系のAPIの文字列引数にUTF8が使えるようになったという話だ

2023/07/02(日) 00:28:14.28

>>390
>strlenが正確な文字数を返してくれるわけではないけども
そもそも正確な文字数が必要な局面って?
そもそもUnicodeにおける「文字」って

2023/07/02(日) 00:43:33.66

A系ならstrlen、W系ならlstrlen使えば済む話では？

2023/07/02(日) 01:40:17.87

>>377
Unicode自体と同様、文句もあるけど世界中が規格化標準化されるのはやはり
有益な面があるなあと思ったり
言語を完全に知らなくてもそういう規則に従えばまあまあのものが出来る
そうやって自分もRTLなテキストを処理するコードを書いたことがあるし
日本語を（も）扱うコードだってどこかの外人が書いてるわけで

そうだ、日本語だって戦前はRTL。あれ、英語はどうしてたんだろ.... 敵性言語だから
ないことになってたのかなw

そういえば、テキストだけじゃなくてUIのレイアウトも変わるし、テキストのスクロール
方向とかも変わるし、注意が必要だったり

2023/07/02(日) 04:10:12.63

Visual C++してもいいでしょうか？
特定の既定のライブラリの無視に「LIBCMT.lib」を設定して
マルチスレッド使っても大丈夫でしょうか？
もちろんランタイムライブラリの設定はマルチスレッドにしてます。
これでマルチスレッド使っても大丈夫でしょうか？

**0397** (ﾜｯﾁｮｲ cb02-ctHD) · 2023/07/02(日) 04:46:51.92

ごめんなさい。自己解決しました。

2023/07/02(日) 08:22:56.48

>>393
何言ってるかわからんkwsk
過去にCreateFile(L"漢字.txt", ...)で作ったファイルを、
WideCharToMultiByteとMultiByteToWideCharの第一引数に明示的にシフトJISのコードページ932を指定するだけで
CreateFileA(u8"漢字.txt", ...)で開けるようになったとしたら論理鉄器におかしい希ガス

2023/07/02(日) 10:08:44.31

環境依存の文字コードを取り扱うA系の関数でコードページ65001(UTF8)をサポートしたという話か？

「最近のリリースのWindows」とやらが何年ごろの話か知らんが

2023/07/02(日) 10:21:10.68

親切な人がいて上の方に書いてある

2023/07/02(日) 11:09:45.90

書いて無くね↑？

2023/07/02(日) 11:52:22.93

>>396
英文モールスや和文モールス信号(符号)は戦前からあるから参考になるよ

みごとに被ってるから

2023/07/02(日) 11:59:53.95

>>399
お舞の方が何言ってるかワカラン
>過去にCreateFile(L"漢字.txt", ...)で作ったファイルを、
>WideCharToMultiByteとMultiByteToWideCharの第一引数に明示的にシフトJISのコードページ932を指定するだけで
>CreateFileA(u8"漢字.txt", ...)で開けるようになったとしたら論理鉄器におかしい希ガス

CreateFile と WideCharToMultiByte/MultiByteToWideChar には何の関係も無いぞ
どちらかといえば setlocale/systemlocale とかの話してるなら判らんでもないが

2023/07/02(日) 12:09:58.45

>>404
>>391