C++相談室 part165

[過去ﾛｸﾞ] C++相談室 part165 (1002ﾚｽ)
上下前次 1-新

このｽﾚｯﾄﾞは過去ﾛｸﾞ倉庫に格納されています｡
次ｽﾚ検索歴削→次ｽﾚ栞削→次ｽﾚ過去ﾛｸﾞﾒﾆｭｰ

201: ◆QZaw55cn4c (ﾜｯﾁｮｲ 3555-LgJ8) [nb3f-ktu@asahi-net.or.jp] 2024/02/03(土)09:46 ID:21sfApha0(1/2) AAS
>>198
>size_t File::accept(std::shared_ptr<Visitor> v) { return v->visit(std::make_shared<File>(this)); }
>　ここがJavaだと単にvisit(this)で済むからスッキリするんだけど
>　しかもこれmake_shared(this)だと多重開放するよね？？
多重解放（二重解放）しないことはラッパをかませて確認済みです。そう簡単に std::shared_ptr は破綻しないと信じています
外部ﾘﾝｸ:ideone.com

それはともかく、皆様のご意見には感謝しております。これからもお伺いさせていただいた際にはよろしくお願いいたします。

202: (JP 0Hbd-IHfd) 2024/02/03(土)09:48 ID:bq1KvR69H(2/2) AAS
>>200
外部ﾘﾝｸ[html]:cpprefjp.github.io
これかあ
実は「childにコンストラクタがある場合」とか「childにprivateメンバがある場合」とか「childがparentをprivate継承している場合」とかはコンパイルが通らなくてもう意味が解らなかったんだけど、それもchildが集成体じゃなくなってたからだったんだね
ありがとう、勉強になった

203(1): ◆QZaw55cn4c (ﾜｯﾁｮｲ 3555-LgJ8) 2024/02/03(土)10:15 ID:21sfApha0(2/2) AAS
>>198
＞値で持てるところは単に値で持つほうがC++っぽいと思う
時代の流れを感じさせるお言葉です。なにせ K&R1 で育った世代なので（K&R1 では構造体の実体渡しはできず、かならずポインタで渡さなければならなかった）。
C++ においても、コピコンを働かせないために const & を多用する毎日です

204: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 7932-MxBP) 2024/02/03(土)14:49 ID:Sz70frqK0(2/2) AAS
>>203
内部的に値で持つのでもポインタで持つのでもいいけど
「簡単に値として取り出せる」のはあまりよろしくないと思う。
これ (>>189) がおそらくファイルシステムを表現しようとするもの
だという前提を考えたらオブジェクトの構造も
ファイルシステムのモデルを抽象するものであるべきだと思うから。

ファイルはそれがある場所にも意味があるからファイルを象徴するオブジェクトが
省4

205: (ﾜｯﾁｮｲ f7da-tydm) 2024/02/04(日)11:53 ID:nmDLw2WS0(1) AAS
はちみつさん頭いいね
アドバイスが丁寧かつ的確でいつも感心する

206: (ﾜｯﾁｮｲ 5702-VoFb) 2024/02/05(月)20:47 ID:dvRwXcQL0(1) AAS
ある構造体(集成体)Aについてconstexprでa1, a2, a3・・・といくつか作りました
別のクラスBのメンバ変数にconst A* m_ptrAがあってconstexprで作ったインスタンスのどれかを指すことにします
この時Bのメンバ関数などで、
if(m_ptrA== &a1) という比較・条件分岐を行うのは意味のある比較になっているのでしょうか？

207: (ﾜｯﾁｮｲ bfe1-tai3) 2024/02/05(月)21:20 ID:crhbGtf+0(1) AAS
意味はある
でもなるべくそういう判定は無しでいけるように設計したいところだよな
Aクラスを作ってる意義が薄れる

あと細かいこと言えばaddressofを使ったほうが汎用的というのはある
c++のクソっぷりが如実に表れている関数

208: (ﾜｯﾁｮｲ 5702-VoFb) 2024/02/06(火)11:08 ID:KJUqS3Ww0(1) AAS
ありがとうございました
本当に列挙型代わりに使えるのなら面白いとも思いましたが
まあ変なコードには間違いないですね

209: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 3732-11P2) 2024/02/06(火)12:11 ID:gR/xoQQt0(1) AAS
分岐の内容次第ではあるけど……Bが指しているAのオブジェクトごとに処理を切り替えるってのなら
a1, a2, a3 …… がそれぞれ関数 (関数オブジェクト) を指す (所有する) ようにするのが常道ではあるね。
Bのメンバ関数の中では呼び出しを一文書くだけでいい。

分岐条件を網羅しそこなうしょうもないミスはよくあることだから
手作業での網羅を避けられるならそのほうがいい。

210(1): (ｵｲｺﾗﾐﾈｵ MMeb-tjaG) 2024/02/06(火)20:42 ID:WnlTLfV5M(1/2) AAS
「The C Standard says that array indexes are (signed)
integers.
The reason behind that is that pointers and arrays
are close in C. For example, tab[index] is strictly
equivalent to *(tab + index). You can use pointer
arithmetic with negative values, hence an array
index can be negative」
省15

211: (ｵｲｺﾗﾐﾈｵ MMeb-tjaG) 2024/02/06(火)20:47 ID:WnlTLfV5M(2/2) AAS
何がいいたいかと言えば、32BIT環境だと
符号付き整数の最大値は、
0x7fff_ffff ですから、
char a[0x7fff_ffff];
は合法ですが、
char a[0xffff_ffff];
はエラーです。よって、
省17

212(1): (ﾜｯﾁｮｲ bfe1-tai3) 2024/02/06(火)21:10 ID:cxCkHHUF0(1) AAS
長いからよく読んでないけどコンパイラは型を認識をしてんだから-1と0xFFFFFFFFは区別してるだろ

213: (ﾜｯﾁｮｲ 5772-hPhG) 2024/02/06(火)21:25 ID:82wR+tAN0(1) AAS
call -151

214: (ﾜｯﾁｮｲ 377c-Hbjn) 2024/02/06(火)22:29 ID:SZ6XHr3I0(1) AAS
C++の配列添字はstd::ptrdiff_t（符号付き）です

215: (JP 0H0b-KLri) 2024/02/06(火)22:36 ID:pbGHBGq1H(1) AAS
配列を宣言するときの構文と添字演算子を使うときの構文を混同してない？前者はブラケットの中身が正じゃなきゃだめで後者は負でもいいってだけの話だと思うんだけど

int main()
{
int hoge[-1]; // ここで負の値を指定することはできない

hoge[-1]; // でもこれはいい (*((hoge)+(-1)) と解釈される)
}

せっかくだからC++23の仕様書も見てみたけど、§9.3.4.5の1には「配列のサイズはstd::size_t型（に変換された）定数式で、その値は0より大きくなければならない」って書いてあって、§7.6.1.2の2には添字は「スコープ無し列挙型か整数型」て書いてあったよ（該当箇所だけつまみ読みしたから正しく読めてる保証はできないけど）

216: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 3732-42qO) 2024/02/07(水)01:09 ID:kuiQPbhX0(1/2) AAS
>>210
C の配列宣言子の角括弧内に書ける数値は 0 より大きい値に評価される整数定数式であることが条件で、具体的な型に規定はない。
式の型がなんらかの具体的な型に強制 (型変換) されたりはしないので signed int なら signed int だし、 unsigned int なら unsigned int のままだ。
VLA のときは定数式という条件は外れるけどそれ以外の制限はだいたい同じ。
C の添字演算子の場合もそう。型は整数であればよい。
(値は制限の範囲内である必要はある。)

どこで見た説明を根拠にしているのか知らんけど、その signed が括弧書きなのは signed 「でもよい」という意味だと思うよ。

217(1): (ﾜｯﾁｮｲ bf9a-Ehcu) 2024/02/07(水)12:42 ID:7NJYw5ei0(1/2) AAS
std::functionって、有効な関数がセットがされているかどうかでブール値を返しますが、
一旦有効化した後にこれを無効化したい場合って、nullptrを代入したりしていいんでしょうか
そしてその場合std::functionの中身はうまいこと解放されたりするんでしょうか
場合によってはラムダ式を使ってオブジェクトをキャプチャしていたりして
あまりその辺りの説明が見当たらない感じがしました

218(1): (ﾜｯﾁｮｲ bfb0-tai3) 2024/02/07(水)12:56 ID:0txhPX/d0(1/2) AAS
それでいいよ

219: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 3732-42qO) 2024/02/07(水)13:12 ID:kuiQPbhX0(2/2) AAS
>>217
外部ﾘﾝｸ[con]:timsong-cpp.github.io

220: (ﾜｯﾁｮｲ bf9a-Ehcu) 2024/02/07(水)14:19 ID:7NJYw5ei0(2/2) AAS
>>218
ありがとうございます!

221: (ｵｲｺﾗﾐﾈｵ MMeb-tjaG) 2024/02/07(水)18:20 ID:aGYGzZDDM(1/2) AAS
>>212
>長いからよく読んでないけどコンパイラは型
>を認識をしてんだから-1と0xFFFFFFFFは
>区別してるだろ
char a[100-101];
みたいに結果的に -1 になった場合は、
32BITコンパイラの場合、果たして内部で
省7

222(1): (ｵｲｺﾗﾐﾈｵ MMeb-tjaG) 2024/02/07(水)18:25 ID:aGYGzZDDM(2/2) AAS
もっと言えば、32BIT ターゲットで、
char a[0x80000000 | 1];
みたいな場合、中味は signed と
捉えれば「負数」ですが、unisgned と
捉えれば、0x80000001 という大きな値
に過ぎません。
どちらもエラーになる可能性が高いですが。

223(1): (ﾜｯﾁｮｲ bfb0-tai3) 2024/02/07(水)18:40 ID:0txhPX/d0(2/2) AAS
リテラルにも型がある
1はint
0x80000000はunsigned int
演算結果はunsigned int
ルール決まってるから

224: (ﾜｯﾁｮｲ d7f0-P/QA) 2024/02/07(水)18:55 ID:V2I2BIn30(1) AAS
x86のアセンブラのディスプレースメントは符号付いてるけどな
他のマシン系はワカランけど

225(1): (ﾜｯﾁｮｲ bfa4-syIJ) 2024/02/07(水)20:52 ID:L6yrYnPT0(1) AAS
>>222
32bit環境には64bit整数はないと思ってるの？？

226: (ｵｲｺﾗﾐﾈｵ MMeb-tjaG) 2024/02/08(木)18:55 ID:DVUqgRU9M(1/2) AAS
>>223
なるほど。そうなるわけですね。
本当に書いた人の意図がどうかに関わらず、
規則で決まっていると。
1UL のように書いてあれば unsigned。
そして、UL のようなものを書いてない場合、
1 のように小さな値は、signed ですが、signed の
省2

227: (ｵｲｺﾗﾐﾈｵ MMeb-tjaG) 2024/02/08(木)18:56 ID:DVUqgRU9M(2/2) AAS
>>225
そういう問題ではないようですが。

228(3): (ﾜｯﾁｮｲ 5763-dZsi) 2024/02/10(土)12:18 ID:KJGevrBa0(1/2) AAS
>>185
>>183の主張の
>一方、例外を生じないライブラリの使い方（関数の呼び出し方）を心掛けるかどうか。これなら選択肢がある
が完全に読み飛ばされている件について：

例外を生じないライブラリの使い方で設計したら、funcB()から例外が飛んでくるのはバグなので
調査と修正の対象になる。
（結果的にやっぱtry { funcB(); } catch (/*略*/) { ... } いるじゃーん？となる可能性はあるがたいていはそうはならない
省1

229(2): (ﾜｯﾁｮｲ 5763-dZsi) 2024/02/10(土)12:26 ID:KJGevrBa0(2/2) AAS
>>186
>catchしたらテストケースが増えるかどうかという話とはなんも関係がない。
あっる
catchする必要性箇所を設計で厳選すればcatchが減るのだからテストケースは減らし得る

例外を使う場合：
スルーしたりcatchして再スローが生じるfoo()の呼び出し箇所（とするのが現実的でないなら呼び出しﾊﾟﾃｨｰﾝ）がm個、
スルーしたりcatchして再スローする段数が（簡単のためここでは平均とする）a個、
省4

230: (ﾜｯﾁｮｲ 377c-Hbjn) 2024/02/10(土)16:57 ID:Qku1mp0Z0(1) AAS
>>228
読み飛ばしてねえよ
funcB()は処理を中断すべきエラーが発生する可能性があるんだろ？だったらそれを適切に処理して後続の処理をやったりやらなかったりする必要があるわけだろ？
それはfuncB()がエラーを例外で返そうと戻り値で返そうとなんか他の方法で返そうと何も変わらないはずじゃないか

231(1): (ﾜｯﾁｮｲ ffcf-HxQs) 2024/02/10(土)18:55 ID:0f3gz8pL0(1/3) AAS
>>229
>例外が飛んでこないことを確認するのテストケースがm個のオーダーで要るだけ……

いったい何をテストしようとしているんだろうか。
仮に「例外が飛んでこないことを確認するテスト」なるものができたとして、catchしたらそれができなくなるのか？

前半のよくわからない計算はcatch句を書いたらそのC0網羅のためのテストケースが必要になるとかいうことなんだろうか。

232(2): (ﾜｯﾁｮｲ ffcf-HxQs) 2024/02/10(土)20:56 ID:0f3gz8pL0(2/3) AAS
>>228
>>>188のように自分が何をやっているのか認識しないまませき止めるのは論外すぐる……

どこが論外？>>169でぜんぜん問題ないが。

233(2): (ﾌﾞｰｲﾓ MM8f-tai3) 2024/02/10(土)21:22 ID:dL54PN9cM(1) AAS
>>232
それは未知の例外投げてきたライブラリを信用し過ぎ
製品ならそういう「たぶん大丈夫っしょw」的なのは許されないね

234(1): (ﾜｯﾁｮｲ ffcf-HxQs) 2024/02/10(土)22:40 ID:0f3gz8pL0(3/3) AAS
>>233
逆だろ。catchしないのはライブらにが未知の例外を投げてこないだろうと信用してるってことだろ。

235(1): (ﾜｯﾁｮｲ bf27-tai3) 2024/02/10(土)23:44 ID:iRyhZExm0(1) AAS
>>234
catchしないということは終了させるということ
見かけ上動き続けたらいいってもんじゃない

236(2): (ﾜｯﾁｮｲ ef63-uLm/) 2024/02/11(日)03:08 ID:4PD3HqyC0(1/5) AAS
>>232
それは未知の例外投げてきた原因を調査しなさすぎ
製品ならそういう「たぶん大丈夫っしょw」的なのは許されないね

>>233
ドキュメント通りに例外発生条件にならないように呼んでやったのに
例外を飛ばしてくるライブラリって一体……
製品やぞ……

237(2): (ﾜｯﾁｮｲ ef63-uLm/) 2024/02/11(日)03:16 ID:4PD3HqyC0(2/5) AAS
質問なのですが
Q1. std::ldexp(0.0, 0.0) が0.0なのですがこれは 0^0 = 0という大胆な主張なのですが何で決まっているの？
STLがIEEE735に従っているだけ？

Q2. 最小の（絶対値が最小の正の）非正規化数は
const auto min_expn = std::numeric_limits<double>::min_exponent;
const auto digits = std::numeric_limits<double>::digits;
として、std::ldexp(0.5, min_expn - digits + 1)　で正しい？
省3

238: (ﾜｯﾁｮｲ ef63-uLm/) 2024/02/11(日)03:25 ID:4PD3HqyC0(3/5) AAS
訂正 |||。n_
誤1： IEEE735
正1： IEEE754
誤2：非正規化数
正2：非正規数

239: (ﾜｯﾁｮｲ 1e27-2ki6) 2024/02/11(日)06:22 ID:2tL2xZqD0(1/3) AAS
>>237
wandboxに書いてみ

240: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ f740-Kvqi) 2024/02/11(日)07:55 ID:nHqSm2on0(1) AAS
>>237
決まっていない。言語仕様としては未規定。
std::numeric_limits::is_iec559 が真であるならその挙動をあてにしていいがそうでないときは各環境の事情による。

241(2): (ﾜｯﾁｮｲ 16cf-BOeC) 2024/02/11(日)09:19 ID:XOPhWcHA0(1/5) AAS
>>236
あんたの認識じゃ catchする=見かけ上動き続けるなんだ？
なんか根本的に勘違いしてる気がする。

242(1): (ﾜｯﾁｮｲ 637c-IqbK) 2024/02/11(日)09:29 ID:9XvrSVak0(1/2) AAS
例外は「関数外にエラー発生を伝える」ための「方法の一つ」でしかない
関数の処理がどんなエラーを発生させうるか、受け取った外側の処理がその情報をどう取り扱うべきかという問題とは完全に直交してる
（言語ごとにある程度の慣例はあるけどあくまで慣例）

例外に変なこだわりや的外れな批判をしてる奴は大体そこを勘違いしてる

243: (ﾜｯﾁｮｲ 16cf-BOeC) 2024/02/11(日)09:47 ID:XOPhWcHA0(2/5) AAS
アンカ間違えた、すまん
>>241は>>235宛な。

244(2): (ﾜｯﾁｮｲ 1e27-2ki6) 2024/02/11(日)09:47 ID:2tL2xZqD0(2/3) AAS
>>242
お前はバグのないお花畑を考えてるからそういう理想的な抽象論を持ち出すんだよ
c++の現実は道を踏み外したら即カオス
stlのコンテナのpopに返り値がない理由は知ってるか？
あのレベルの考察でソフトウェア設計している人間が世の中にどれだけいると思う？

245(2): (ﾜｯﾁｮｲ 1e27-2ki6) 2024/02/11(日)09:55 ID:2tL2xZqD0(3/3) AAS
>>241
>>169を否定している
知らない例外が飛んできた場合にcatchして握りつぶしてそのまま動作を継続するかどうかって話な

246: (ﾜｯﾁｮｲ 637c-IqbK) 2024/02/11(日)10:07 ID:9XvrSVak0(2/2) AAS
>>244
バグのあるなしなんか関係ない設計の話だし、「例外はエラー伝達の具体的方法の一つ」って話のどこが抽象的なのかも分からないし、
「C++の現実」とか「カオス」が具体的に何のことで何の関係があるかも分からないし
STLにpopがないのはnoexcept moveがない時代に例外安全に出来なかったからだけど今の話に何の関係があるかわからないし
そんなのまともなC++erなら誰だって考えて設計してると思うけど、そうでないタコの話が何の関係あるかわからないし何もかも分からなすぎてすごい
仕事でそんなドキュメントやレビューコメント出すなよ

>>245
省4

247: (ﾜｯﾁｮｲ 16cf-BOeC) 2024/02/11(日)10:14 ID:XOPhWcHA0(3/5) AAS
>>245
？
そのtryブロックの処理が失敗したものとするって書いてあるじゃん。

248(1): (ﾜｯﾁｮｲ ef63-uLm/) 2024/02/11(日)11:18 ID:4PD3HqyC0(4/5) AAS
>>231
>前半のよくわからない計算はcatch句を書いたらそのC0網羅のためのテストケースが必要になるとかいうことなんだろうか
例外が関数の階層をぶち抜いてfall-throughしてくることを忘れている発言
1. catchが書かれた関数が正しくcatchし、適切に処理するか（処理してせき止め　or/and 必要な場合再スロー)（←要テスト！
2. fall-throughする関数が例外による処理の中断でおかしいことにならないか（←要テスト！

2をテストもせずに放置するとおかしくなる例は>>183のとうーり
これにより、例外を生じる関数foo()の呼び出しﾊﾟﾃｨｰﾝn個それぞれに対し、a個のテストが必要になっる
省3

249(2): (ﾜｯﾁｮｲ ef63-uLm/) 2024/02/11(日)11:18 ID:4PD3HqyC0(5/5) AAS
>>244
以下の主張のどこが抽象論なのかkwsk、
1. ライブラリのドキュメントに従い、可能な限り例外を生じない使い方で設計する（>>236
2. 例外が生じない前提としたところは例外が生じないことをテストする（m個のオーダー）（>>229
3. 1と2の過程で意図に反して飛んでくる例外がある場合は原因を調査し、修正を試みる（>>228　例外が飛んで来たらバグ
4. 3を意図通りの形で解決できないことが判明した場合は
　　（ライブラリの使用方法の当方の誤解、ライブラリのドキュメントの不備、ライブラリの作りの粗さによりこれはあり得る、
省10

250(1): (ﾜｯﾁｮｲ 16cf-BOeC) 2024/02/11(日)12:01 ID:XOPhWcHA0(4/5) AAS
>>248
>例外が関数の階層をぶち抜いてfall-throughしてくることを忘れている発言

やっぱり意味不明だな。catchすれば「階層をぶち抜いて」ってことはないわけだが。

>2. fall-throughする関数が例外による処理の中断でおかしいことにならないか（←要テスト！

もしそのテストが必要なんだとすれば、catchしない場合はその例外が通過する
呼び出し階層全部でテストをしなきゃならないってことになるが。

251(1): (ﾜｯﾁｮｲ 16cf-BOeC) 2024/02/11(日)12:31 ID:XOPhWcHA0(5/5) AAS
>>249
>1. 例外をせき止めれば良い（←処理不能な未知の例外が飛んでくることが無いというライブラリに対する全幅の信頼

なるほどな。
catchする⇒無視する、握りつぶす　って脳内変換されてんだな。

catch書いたからといって上に挙げられたようなテストができなくなるわけじゃないっしょ。必要と思うならやればいい。

3.の意図しない例外の原因調査なんて main() に例外が上がってきてプログラムが落ちてからより
発生個所に近い下層で catch できた方がはるかに調査しやすいと思うんだがな。感覚が違うなあ。

252(1): (ｽﾌﾟｯｯ Sd52-oDfP) 2024/02/11(日)12:37 ID:AyRTgUB7d(1) AAS
仕様書や規格書はその意図を正確に読み取ろうとするのに
掲示板の他人の書き込みは積極的に曲解しようとするのは何故か？

253(1): (ﾜｯﾁｮｲ ef8b-u/MX) 2024/02/11(日)12:44 ID:E8bU9+6D0(1) AAS
見下しているからよ
こいつらは俺より下なはずと

254: (ﾜｯﾁｮｲ 5eda-5kwM) 2024/02/12(月)07:49 ID:4SfsXRB60(1) AAS
本気で面白いと思ってやってんだろう

255: (ﾜｯﾁｮｲ 637c-IqbK) 2024/02/12(月)08:44 ID:WngRm50l0(1) AAS
例外は糞！危険！意味不明！テスト漏れる！って言ってる奴ほど
if (err != 0) { return -1; }が大好きなんだよな
本質的にやってること変わらないのに

256(2): (ﾜｯﾁｮｲ eba6-IqbK) 2024/02/12(月)15:42 ID:NdUIQhSh0(1) AAS
ファイル名に年月が使えないの困ります。
2024/02/11_データ.txt
とか

257: (ﾜｯﾁｮｲ 4b5a-nvep) 2024/02/12(月)15:46 ID:QicyHe7E0(1) AAS
>>256
それ検索性最悪だから良くないんだよなぁ。
データ/2024/02/11/データ.txt
データ.txt/2024/02/11/データ.txt
あたりならまだ許せる。

258: (ﾜｯﾁｮｲ 6fac-ND3n) 2024/02/12(月)16:40 ID:MdmHk5EH0(1) AAS
ふつう年月日はハイフンで区切るよね

259: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 6332-A7R9) 2024/02/12(月)17:02 ID:4VueJhli0(1/2) AAS
スラッシュを使う習慣が悪いわけではないが
プログラマの感覚だと ISO 8601 の方式に馴染みが有ることが多いってのはある。

260: (ﾜｯﾁｮｲ 5edc-s3Gl) 2024/02/12(月)17:31 ID:rGOG+Ewu0(1) AAS
年月日は「ふつう」がないのでみんなが苦労している
日本とアメリカとイギリスで順番が違うし
日本には「令和」とかあるし

261: (ﾜｯﾁｮｲ f78f-nOVH) 2024/02/12(月)18:43 ID:zGvIVge80(1/3) AAS
Windowsでも / をディレクトリ区切り文字として使えるけど(場面は限定的かもしれないけど)、その認識で使ってるのかな…

262: はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 6332-Kvqi) 2024/02/12(月)20:07 ID:4VueJhli0(2/2) AAS
Linux で * という名前のファイルを消そうとして
うわあぁぁぁとなった話はたまに聞く。
使えたとしても使うべきでない文字もある。

263: (ﾜｯﾁｮｲ f7cb-nOVH) 2024/02/12(月)21:44 ID:zGvIVge80(2/3) AAS
262>>
それ以外のファイルをすべて退避した上でディレクトリごと削除したことがあったな

264: (ﾜｯﾁｮｲ f7cb-nOVH) 2024/02/12(月)21:46 ID:zGvIVge80(3/3) AAS
すみません、261ですが、Windows限定の話ではなかったですね
失礼しました…

265: (ﾜｯﾁｮｲ 5edc-s3Gl) 2024/02/13(火)05:53 ID:QIUviIGO0(1) AAS
Linuxならi-nodeをしていすれば
findと組み合わせてどんな名前のファイルも消去できるんだけどなあ

windowsはなんか複雑だったような気がした

266(1): (ﾜｯﾁｮｲ 1e27-2ki6) 2024/02/13(火)09:36 ID:7CLA20rP0(1) AAS
iso8901にしない人はたぶんこの規格を知らないわけで意識低すぎだろと思ってしまう

267(1): はちみつ餃子◆8X2XSCHEME (ﾜｯﾁｮｲ 6332-A7R9) 2024/02/13(火)11:18 ID:T85IlqBy0(1) AAS
>>266
ISO 8901 は情報交換用 (要するに機械同士のやり取り) の時刻フォーマットを定める規格であって
言葉や文章で使うもの (人間が読み書きする目的) ではないと適用範囲の言及がある。
ファイル名はどちらの用途もありうるので >>256 がどのような状況を想定しているかによって
ISO 8901 が適切かどうかは違う。

もし非技術者向けのシステムなら
文化固有の日付表現に対応できてないほうが意識低いという見方もある。

268: (ﾜｯﾁｮｲ 5ed7-nvep) 2024/02/13(火)12:55 ID:c63MYIIQ0(1) AAS
>>267
エンドユーザーの文化的背景に配慮したデータフォーマットの利点は、エンドユーザーの知識やメタファーを利用した学習曲線の低勾配化であって、技術的には負の遺産になりやすいことには注意が必要。

典型的には小組織から始まるURLの並びですな。木構造との相性がひどく悪い。
あるいは大きな桁から始まるバイト列とか。あんなの１桁目から始めればエンディアン問題とか無かった。

269(1): (ﾜｯﾁｮｲ 12ad-v2JO) 2024/02/13(火)13:07 ID:mTl8FNrx0(1) AAS
> 典型的には小組織から始まるURLの並びですな。木構造との相性がひどく悪い。
それは人間から見たときと機械から見たときの見やすさの違いでしかないような気がする

でも日本の住所は大きい方から始まるんだよな
アメリカは個人から始まる
文化の違いやけども、日本人は機械生命体だったのかもしれぬ

270: (ﾜｯﾁｮｲ 6b74-e92p) 2024/02/15(木)04:22 ID:MOgQCM5N0(1) AAS
>>58
亀だがクロスで使ってるよ

271(1): (ﾜｯﾁｮｲ d62e-RfGy) 2024/02/16(金)22:41 ID:/bcZ41DF0(1) AAS
enable_shared_from_thisなクラスで、shared_from_this()はコンストラクタの中では
呼べないようですね
コンストラクタの中の処理でthisを渡したい処理があるのですが、どうしたら...
そもそもそれ自体が間違っているのでしょうか
コンストラクタが呼ばれる行の次でその処理を呼べばいいという説もありますが、
現在のコードがそれをやりにくい形になっていて

272(1): (ﾜｯﾁｮｲ ef63-uLm/) 2024/02/17(土)11:55 ID:hsYxYbKj0(1/2) AAS
>>250
>>2. fall-throughする関数が例外による処理の中断でおかしいことにならないか（←要テスト！
>もしそのテストが必要なんだとすれば、catchしない場合はその例外が通過する
>呼び出し階層全部でテストをしなきゃならないってことになるが。
その通り。テスト不要としたいなら、例外が出た原因を調べて出ないようにするのが筋

原因を調査して対策せずに予防的にテスト不十分のtry { } catch () をてんこ盛りにする方がソフトウェアー品質が上がるという考えのはおかしい

>>251
省8

273: (ﾜｯﾁｮｲ ef63-uLm/) 2024/02/17(土)12:01 ID:hsYxYbKj0(2/2) AAS
>>253
藻前が二の句をつげないのは藻前の見識と資質の問題であって
漏れの責任ではないのでお間違えなきよう、
なのですよ……

274: (ﾜｯﾁｮｲ 12ad-hHXc) 2024/02/17(土)12:35 ID:mUyTgSzm0(1/4) AAS
テストって想定した動作環境、データ入力に対して想定した動作をするか確認をするわけで
想定しえないエラーや割り込みに対してはテストのしようがないんだけどな
そのための例外処理だろ

275: (ﾜｯﾁｮｲ 6332-A7R9) 2024/02/17(土)13:04 ID:4+T7+QKn0(1/3) AAS
例外が上がってくるってことはどこかで例外を投げてるってことだぞ。
問題が起きたところでその問題に対して例外を投げるという対処をしてる箇所がある。
想定してないなら例外送出すらできないよ。

その上で人間は大きいプログラムの全体を把握することは困難だし
機械的なチェックがしづらいという現実はあるって話だ。

276(1): (ﾜｯﾁｮｲ 12ad-hHXc) 2024/02/17(土)13:33 ID:mUyTgSzm0(2/4) AAS
アプリケーションを作っているのとOSを作っている人は別
それと同様に利用するライブラリがどのような例外を投げてくるか、もしくはそのライブラリがさらに下位のライブラリから投げられた例外をどう処理しているか
アプリケーション開発者はそれらすべて想定できているとでも？
ハードウェアやシステム含めて全部ひとりで作り上げる（もしくは密に情報共有できている）ならお前の言う通りだけどな

277: (ﾜｯﾁｮｲ 6332-A7R9) 2024/02/17(土)13:41 ID:4+T7+QKn0(2/3) AAS
>>276
「把握することは困難」という現実の話もしてる。
想定してはいて、しかしそれが伝わってない。
コミュニケーションの問題、自動化の問題として捉えるべき。

278(1): (ﾜｯﾁｮｲ 12ad-hHXc) 2024/02/17(土)13:56 ID:mUyTgSzm0(3/4) AAS
俺も、（もしくは密に情報共有できている）なら、と言う話をしているがな

ただ「現実の話」と言うならば、伝わっていないことをコミュニケーションの問題、自動化の問題と言うのはナンセンスだわな

お前自身がこう言っている
> その上で人間は大きいプログラムの全体を把握することは困難だし
> 機械的なチェックがしづらいという現実はあるって話だ。

ではWindowsと言う巨大プログラムにおいてMSの中の人はどの程度全体を把握していて、発生しうる例外を公開しているのか
アプリケーション開発者はその公開情報をもとに　＊想定し＊　プログラムを組まなくてはならない
省5

279: (ﾜｯﾁｮｲ 6332-A7R9) 2024/02/17(土)15:09 ID:4+T7+QKn0(3/3) AAS
C++ の設計理念としては「そうは言っても現実はこうなっとるやろが！」という
状況に対処する方法があることも大事にしてはいる。たとえ綺麗な方法ではなくても。

どのような問題が起こりうるのか (それなりには) きちんと想定するのは当然の大前提で、
それでもこれからリリースするソフトウェアに何が起こるかわからんのは仕方がないという話であって、
想定が不十分でも構わないという話でもない。
よくは無いが悪いときでもなんとかなるという程度の仕組みだよ。

280(1): (ﾜｯﾁｮｲ e33b-hZ+C) 2024/02/17(土)15:39 ID:snTd9S980(1) AAS
>>271
一番いいのはコンストラクタの中でthisを渡す部分を何とかすることだけど、それが必ずしも間違ってるかは分からないので
コンストラクタの中だけでその処理が呼ばれるなら生のthisを渡すことを許容しつつ、その処理の呼び出し可能範囲を限定するか
そのクラスの構築をファクトリ関数経由に限定して、ファクトリ関数の中に構築とその処理呼び出しをまとめてしまうとか

281: (ﾜｯﾁｮｲ 12ad-hHXc) 2024/02/17(土)15:49 ID:mUyTgSzm0(4/4) AAS
> 想定が不十分でも構わないという話でもない。
誰もそれで構わないとは言っていないので
それでも起きてしまうエラーや割り込みに対応するための仕組みが例外処理だろ

身も蓋もない言い方をするなら
そもそも想定できているなら事前に排除するだけで済むわけで例外処理の必要もない
（もちろん分かっていても事前に排除せず意図的に例外処理に丸投げすることもあるのは知っている）
アプリケーション開発者にとってもっとも想定できない問題ってのは実行環境に起因するもの

上下前次 1-新書関写板覧索設栞歴

あと 721 ﾚｽあります
ｽﾚ情報赤ﾚｽ抽出画像ﾚｽ抽出歴の未読ｽﾚ AAｻﾑﾈｲﾙ

ぬこの手ぬこTOP 0.029s