C++相談室 part165

2023/10/31(火) 07:37:38.52

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

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

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

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

2024/01/14(日) 13:01:30.73

>>138
全選択肢を同時に選ぶって意味に捉えられちゃったかな？
そうじゃなくて、その選択肢自体が同時に適用すべきレベルのものじゃないと思うの

例外をキャッチするって決めたなら、そこには目的があるよね？
設計手順としては目的を決めてから例外を使おうって判断になるわけ

その目的次第だよね？っていうのがD
目的がリソースリーク防止ならA
Aのような目的を達成するために、目的範囲内でB
デバッグ目的ならC

製品等で客の目に見せたくないなどの営業目的があるならCはダメで、のべつまくなしBというのもあるかもしれない

2024/01/14(日) 13:06:09.91

大きな目で全工程トータルを考えると全部の選択肢を適用する必要があるし、適用のしどころが違うと思うってのが>>136の真意でした

2024/01/14(日) 13:12:37.16

>>148
これが正しいかどうかはおいといて、人命に関わらないなら、自分はその考え方に賛成！

完璧にデバッグしろというのは自動車と医療機器など人命にかかわるものだね
重要度に応じて工数のかけ方が変わってくるので、すべてのソフトウエアで一概にこうしなさいとは言えないかな

そういう意味ではD

2024/01/14(日) 15:16:56.65

>>162
ああ、なるほどね
分かりやすくありがとう、助かりました

2024/01/15(月) 08:10:14.00

人命にかかわらない場合であっても、末端の関数が投げる例外の種類を見落としただけでプログラム全体が
いきなり落ちるのは勘弁してほしいし、それを防ぐために全部の関数が投げる例外の種類を全部把握するというのも
無理ゲーに近い。
なので適当なレイヤーごとにざっくり std::exception をキャッチする造りにしてるな。例外の種類で選択したりはしない。

2024/01/15(月) 11:54:06.38

キャッチしてその後どうすんの？

2024/01/15(月) 18:12:26.71

何するか思い付かないならPG辞めろ
貴様には向いてない

2024/01/15(月) 18:20:04.00

>>167
そのtryブロックの処理が失敗したものとして処理を続ける。

2024/01/15(月) 18:42:14.36

テストケース爆増じゃん

2024/01/15(月) 19:20:39.72

なんで爆増？

2024/01/15(月) 20:40:13.04

その失敗する処理の具体例言ってみて

2024/01/15(月) 22:10:56.13

んでテストケース爆増の話は？処理の具体例次第で話が変わったりするとか？

2024/01/15(月) 22:45:20.95

依存関係のあるものに影響あるのは当たり前
原因不明の例外起こっても突き進むんだったら擬似的にそのケース作ってテストするわな普通は
出し渋るなら別にださなくていいよ
参考にならなさそうだし

2024/01/15(月) 23:24:57.00

それはいったい何のテストなんだろう。原因不明の例外を首尾よくキャッチできるかどうかテストしろと言っているんだろうか。
そもそもそういう例外を想定するなら、スルーして影響範囲が広がる方がテストは厄介になると思うがなあ。

2024/01/15(月) 23:36:35.23

たとえば業務用のラベルプリンターでAPIが提供されてるとか
とりあえず try ～ catch して「印刷中に不明なエラーが発生しました」みたいなまとめかたはあるかなー

2024/01/23(火) 17:00:13.54

すみません。質問させて下さい。次のコードがMinGW-w64 g++ v13.2では --itrでエラーになります。わからないのはVisual studio 2022およびVisual StudioがサポートするClang LLVMでは通って正しく
実行しているように見えます。--itrの仕様がないのはMinGW-w64 g++v13.2が正しいのでしょうか？それともVisual Studioが正しいのでしょうか？

#include <iostream>
#include <unordered_set>
using namespace std;

int main()
{
unordered_set<int> us = { 1,2,3,4,5,6 };

for(auto itr = begin(us); itr != end(us); ++itr) cout << *itr << endl;

auto itr = us.begin();
++itr; ++itr;
cout << *itr << endl;

--itr;
cout << *itr << endl;

cin.get();
return 0;
}

MinGW-w64 g++ v13.2のエラー
// error: no match for 'operator--' (operand type is 'std::__detail::_Node_iterator<int, true, false>')

2024/01/23(火) 17:23:45.88

>>177
unordered_set は forward iterator をサポートしているという規定がある。
https://timsong-cpp.github.io/cppwp/n3337/unord.set.overview#1
forward iterator は進めることは出来ても戻ることはできない。
この場合は operator-- がないのが正しい。

拡張してより高機能なライブラリを提供しても仕様に反するってわけではないけど
マイクロソフトのドキュメントでも特に拡張しているという文面は見当たらないから
あんまりあてにしないほうが良さそうには思う。
https://learn.microsoft.com/en-us/cpp/standard-library/unordered-set-class?view=msvc-170#iterator

2024/01/23(火) 17:34:44.31

おお、ありがとうございます。

2024/01/28(日) 11:36:45.25

>>173
横やが関数foo()で1つの例外が発生したらその時点のfoo()呼び出しに至る10個かそこらの関数が中断されるわけや
すなわち関数bar()が
　　処理A→B→C→D→return
の順で処理が進むことを気体しているところに、Bで呼び出している関数baz()がfoo()を呼び出している結果、foo()で例外を生じると
　　処理A→B→return
という処理順に変更になる。こうなっても大丈夫なようにtry { 処理B } catch ((fooが投げる例外)& e) { (eに対する適切な処置) } を書かねばならず、
これが実は潜在的には処理A、B、C、Dのどこでも起き得るから厳密なことを言えば全てについて書かねばならず、
それがfoo()呼び出しに至る10個かそこらの関数それぞれについて行われねばならない。
検証もそんだけ組み合わせが増える。

2024/01/28(日) 11:40:58.52

というわけでそんなの現実には不可能なので、現実的な処置としては
・ライブラリ製作者はなんか都合が悪い事が起きたら何でも呼び出し元に返す。
　第1選択としてはエラーステータスを返すことを検討し、それではコードが煩雑になりすぎる場合は例外を投げて異常を知らせる
・ライブラリを使う人はライブラリが例外を投げない条件で使うことを心掛け、自前のコード内でtry { } catch() { }を極力しない
という処置になるわ
けや

2024/01/28(日) 12:02:32.93

catchしようがしまいが、例外が起きて処理A→B→return となるのは同じだと思うが。
その場合の検証が必要だというならどっちも必要だろ。

2024/01/28(日) 12:13:11.85

>>182
>catchしようがしまいが、例外が起きて処理A→B→return となるのは同じだと思うが。
それは問題の認識がおかいし
例えば以下のコードにおいて、スレッドのゾンビを生じさせないためにはfuncB()をtry { } catch () { } は必須になる。
　void bar() {
　　funcA();　　// スレッドxを起動
　　funcB();　　// 中でbaz() → foo()の呼び出し
　　funcC();　　// スレッドxに停止シグナル発酵
　　funcD();　　// スレッドxの終了待ち
　　return;
}
このように一般に例外が飛んでくる関数にはcatchするかしないかの選択権など無い
例外安全なオブジェクト「だけ」で事が済んでいない限り、例外を受けると決めた時点でcatchせねばならない

一方、例外を生じないライブラリの使い方（関数の呼び出し方）を心掛けるかどうか。これなら選択肢がある

2024/01/28(日) 12:14:54.75

訂正orz
誤：例外安全なオブジェクト「だけ」で事が済んでいない限り、例外を受けると決めた時点でcatchせねばならない
正：例外安全なオブジェクト「だけ」で事が済んでいない限り、例外が飛んでくる想定であるならばcatchせねばならない

2024/01/28(日) 12:19:26.10

>>183
それはfuncB()に失敗の可能性がある時に必ず必要な話だろ？例外どうこうじゃないじゃん
funcB()が例外を投げずに古き良きintのエラーコードを戻り値で返す場合は何かが変わるの？
まさか「funcBの戻り値をガン無視すればfuncCもfuncDも実行されてくれるから完璧！だから例外はクソ！」っていうゴミカスみたいな主張をしたいわけじゃないよね？

2024/01/28(日) 12:28:00.13

>>183
それはcatchが必要かどうかの話だろ。
catchしたらテストケースが増えるかどうかという話とはなんも関係がない。

2024/01/28(日) 15:40:48.23

そもそも未知の例外飛んできた時点でそれを通したライブラリの例外安全性が守られてるか怪しいと考えるべき

2024/01/28(日) 17:01:39.99

例外安全性を守るのに例外の種類やそれが既知か未知かは関係ないだろうが、
仕様に明記した例外以外は堰き止めるのが正解だろうなあ。

◆QZaw55cn4c (ﾜｯﾁｮｲ 3583-LgJ8) · 2024/01/28(日) 20:27:29.75

思い立って結城さんのデザパタ(古いjava で記述）を総称型（テンプレート）もちゃんと使ってC++ に書き直しているけれども、
new/delete からptr::shared_ptr に書きなおすと、もう構造がわかりにくくなってしまってどうしようもない
デザパタ＝抽象クラスプログラミングは C++ ではオワコンなの？
Visitor パターン
new/delete: https://ideone.com/6d43LO スッキリ書けてきもちいい
std::shared_ptr: https://ideone.com/oYzkxh 恐ろしい宣言の連発

>std::shared_ptr<Iterator<std::shared_ptr<Entry>>> iterator() { return std::make_shared<VectorIterator<std::shared_ptr<Entry>>>(v); }

なんかもう書いてても意味不明
CONSTRUCTOR(CONSTRUCTOR *p) とかコピコン以外にもみたことのないコンストラクタが要求されるし

2024/01/28(日) 20:53:25.29

>>189
スマートポインタを使わないバージョンも C++ 的にはすっきりしてない。
動的多態の必要が必要ないのに持つべきメンバ関数を強制するためだけに抽象クラスを使っていて不恰好に見える。
コンセプトの導入がだいぶん後回しになった C++ の問題でもあるんだが……。
設計理念が妥当かどうかはともかくとして、元が Java なら直訳めいた C++ への置き換えがすっきりと書けるはずがない。

2024/01/28(日) 21:08:52.58

ざっと見た感じだと抽象クラスとして必要なのは Entry だけかな。
ジェネリックラムダが visitor パターンで使いやすいのでそういうのが使いやすいように配慮するといいかも。
std::visit が C++ での visitor パターンのお手本だよ。

2024/01/28(日) 22:46:18.85

>>189
usingなりtypedefでエイリアス作れば?
using Entry_Ptr = std::shared_ptr<Entry>;

**デフォルトの名無しさん** (JP 0Hbd-DQL8) · 2024/01/28(日) 23:17:29.01

面白そうだからちょっと書いてみた。大きな変更点はこんな感じ。

・accept が受け取るのは単に Visitor の参照でいい。ここで shared_ptr を使う必要はない。
・Visitor が受け取るのも File や Directory の参照でいい。
・SizeVisitor もいらない。File と Directory はともに Entry の子クラスとして getSize() を実装してるんだから、無理に visitor パターンを使わなくても単に getSize() を呼べばいいだけ。
・iterator() が返すのも VectorIterator の shared_ptr ではなく、単に VectorIterator を返せばいい。

全体的に使う必要がない場面で shared_ptr を使ってるのが目立ったと思う。

https://wandbox.org/permlink/ZBKbF5iMVpb7Looi

だいぶすっきりしたんじゃない？

2024/01/28(日) 23:52:27.85

なんかもうポインタをいじるのが面倒になったので値としてやりとりしていいやという気持ちと
標準ライブラリを積極的に活用することにしたらこうなった。
https://wandbox.org/permlink/BQCNjfdJRKWAR3dg

◆QZaw55cn4c (ﾜｯﾁｮｲ 3583-LgJ8) · 2024/01/29(月) 04:35:04.36

>>193
拝読させていただきました。なるほど、関係性を示すポインタ＝参照なら std::shared_ptr でくるむ必要ガない、というわけですか。
>>194
拝読させていただきました。Entry を値で持つのはいやだなあ。　dectype の使い方を学ばせていただきました。

◆QZaw55cn4c (ﾜｯﾁｮｲ 3583-LgJ8) · 2024/01/29(月) 05:00:34.95

>>194
std::size_t()
あたりから読めていません。operator() をどう使っているのでしょうか？

2024/01/29(月) 12:08:36.13

スマートポインタを使うにしても std::shared_ptr って必要？
この場合は std::unique_ptr でよくない？
https://wandbox.org/permlink/dMolraFpQHKzYtF3

設計思想によるけどファイルシステムを表現するという前提だと
ひとつのルートディレクトリに連なる全てのエントリは実質的に一体のデータ構造なので
ルートディレクトリエントリの寿命が尽きれば全て解体ってことにしたほうが簡単でいいと思う。

ハードリンクの表現とかも考えるなら事情が変わってくることもあるだろうけど……。

2024/01/29(月) 21:21:12.23

>>189 c++
https://ideone.com/p3li2Y
・https://ideone.com/oYzkxh を元に若干の整理を行った

・他の人と同様shared_ptrを削除
　値で持てるところは単に値で持つほうがC++っぽいと思う
　ただ「Entry を値で持つのはいやだなあ」とのことなので部分的に残してる
　Javaの参照型変数をshared_ptrに置き換えようとして困るのは
　size_t File::accept(std::shared_ptr<Visitor> v) { return v->visit(std::make_shared<File>(this)); }
　ここがJavaだと単にvisit(this)で済むからスッキリするんだけど
　しかもこれmake_shared(this)だと多重開放するよね？？

>>189 c++
https://ideone.com/2uUpwH
・https://ideone.com/p3li2Y を元に若干の整理を行った

・make_shared<File>(this)の多重開放？を修正
　std::enable_shared_from_thisを使ってJavaの参照型変数っぽい使用感を得た。

・struct this_is_private {};
　これは単にコンストラクタを実質的にprivateにするためだけに使ってる
　https://en.cppreference.com/w/cpp/memory/enable_shared_from_this
　https://stackoverflow.com/questions/8147027/how-do-i-call-stdmake-shared-on-a-class-with-only-protected-or-private-const
　このへん参照されたし

**デフォルトの名無しさん** (JP 0Hbd-IHfd) · 2024/02/03(土) 04:38:02.47

https://wandbox.org/permlink/LEl2MT7OdGIlVKC4

なんか「子クラスのコンストラクタに親クラスのオブジェクトを渡して子クラスのメンバを初期化する」（？）みたいなことができちゃってるんだけど、これってどういう仕様でこうなってんの？
Wandbox上だとC++2aではコンパイルできてC++17ではコンパイルできなかったからcpprefjpのC++20の機能の一覧も見てみたけどそれらしいものはなかったし

2024/02/03(土) 09:26:19.03

>>199
designated initializer も C++20 からの機能なんだけど……それは脇に置く。

この場合は集成体初期化に該当する。
C++17 から基底の初期化も集成体初期化で扱えるので
child c{p};
というように初期化出来ていた。

更に C++20 では集成体初期化を丸括弧で書いても良いことになったので
child c(p);
とすることが許されるようになった。

◆QZaw55cn4c (ﾜｯﾁｮｲ 3555-LgJ8) · 2024/02/03(土) 09:46:38.23

>>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 は破綻しないと信じています
https://ideone.com/GUPcSu

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

**デフォルトの名無しさん** (JP 0Hbd-IHfd) · 2024/02/03(土) 09:48:07.39

>>200
https://cpprefjp.github.io/lang/cpp17/extension_to_aggregate_initialization.html
これかあ
実は「childにコンストラクタがある場合」とか「childにprivateメンバがある場合」とか「childがparentをprivate継承している場合」とかはコンパイルが通らなくてもう意味が解らなかったんだけど、それもchildが集成体じゃなくなってたからだったんだね
ありがとう、勉強になった

◆QZaw55cn4c (ﾜｯﾁｮｲ 3555-LgJ8) · 2024/02/03(土) 10:15:36.86

>>198
＞値で持てるところは単に値で持つほうがC++っぽいと思う
時代の流れを感じさせるお言葉です。なにせ K&R1 で育った世代なので（K&R1 では構造体の実体渡しはできず、かならずポインタで渡さなければならなかった）。
C++ においても、コピコンを働かせないために const & を多用する毎日です

2024/02/03(土) 14:49:57.28

>>203
内部的に値で持つのでもポインタで持つのでもいいけど
「簡単に値として取り出せる」のはあまりよろしくないと思う。
これ (>>189) がおそらくファイルシステムを表現しようとするもの
だという前提を考えたらオブジェクトの構造も
ファイルシステムのモデルを抽象するものであるべきだと思うから。

ファイルはそれがある場所にも意味があるからファイルを象徴するオブジェクトが
場所から離れてやりとりされるのは違和感がある。

まあファイルシステムのモデルをどう捉えるかは私の感想でしかないから
何が妥当とは強くは主張しないけど、
いずれにしても実装上の都合じゃなくて使う側の感覚でどうなってて欲しいかという視点が要ると思う。

2024/02/04(日) 11:53:17.97

はちみつさん頭いいね
アドバイスが丁寧かつ的確でいつも感心する

2024/02/05(月) 20:47:16.57

ある構造体(集成体)Aについてconstexprでa1, a2, a3・・・といくつか作りました
別のクラスBのメンバ変数にconst A* m_ptrAがあってconstexprで作ったインスタンスのどれかを指すことにします
この時Bのメンバ関数などで、
if(m_ptrA== &a1) という比較・条件分岐を行うのは意味のある比較になっているのでしょうか？

2024/02/05(月) 21:20:14.92

意味はある
でもなるべくそういう判定は無しでいけるように設計したいところだよな
Aクラスを作ってる意義が薄れる

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

2024/02/06(火) 11:08:08.32

ありがとうございました
本当に列挙型代わりに使えるのなら面白いとも思いましたが
まあ変なコードには間違いないですね

2024/02/06(火) 12:11:55.01

分岐の内容次第ではあるけど……Bが指しているAのオブジェクトごとに処理を切り替えるってのなら
a1, a2, a3 …… がそれぞれ関数 (関数オブジェクト) を指す (所有する) ようにするのが常道ではあるね。
Bのメンバ関数の中では呼び出しを一文書くだけでいい。

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

2024/02/06(火) 20:42:09.19

「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」
とあるので、C 言語での配列添え字は符号付き整数
ですね。
しかし、C++ では、size_t とされ、符合なし整数
のようですが、矛盾しませんか？

VC++の以下のマクロでは、
#define C_ASSERT(e) typedef char __C_ASSERT__[(e)?1:-1]
eが偽の時にエラーになるようになっているようです。
これはつまり、
typedef char aaa[-1];
がエラーになる事を前提にしているようです。
しかし、もし、配列の最大要素数が、符合なし整数
であるならば、32BIT 環境の場合、
-1 は、0xffff_ffff と同じと言えば同じであるはずで、
コンパイラ内部で効率よく区別するのは難しいはずです。
どうしてるんでしょう。

2024/02/06(火) 20:47:53.26

何がいいたいかと言えば、32BIT環境だと
符号付き整数の最大値は、
0x7fff_ffff ですから、
char a[0x7fff_ffff];
は合法ですが、
char a[0xffff_ffff];
はエラーです。よって、
char a[-1];
はコンパイラは難しい処理をしなくても、
-1 は内部表現が 0xffff_ffff ですので
そもそも範囲外の数値と見なせます。
ところが、もし、配列最大数が unsigned
の領域まで許されるならば、要素数が
0xffff_ffff の配列も合法だということに
なります。
ならば、要素数の[] の中に-1 を指定した
場合の処理は難しくなりそうだ、ということです。
なおそもそも、32BIT の Windows 環境
だと、ユーザーが使えるアドレス空間は
最大で 0x7fff_ffff 程度までですから、
バイト数的に確保は出来ませんが。
ならば、そもそも、C++がunsigned 型
であるところの、size_t を採用しているもの
なかなか不可思議であります。

2024/02/06(火) 21:10:01.10

長いからよく読んでないけどコンパイラは型を認識をしてんだから-1と0xFFFFFFFFは区別してるだろ

2024/02/06(火) 21:25:24.39

call -151

2024/02/06(火) 22:29:48.57

C++の配列添字はstd::ptrdiff_t（符号付き）です

**デフォルトの名無しさん** (JP 0H0b-KLri) · 2024/02/06(火) 22:36:10.13

配列を宣言するときの構文と添字演算子を使うときの構文を混同してない？前者はブラケットの中身が正じゃなきゃだめで後者は負でもいいってだけの話だと思うんだけど

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には添字は「スコープ無し列挙型か整数型」て書いてあったよ（該当箇所だけつまみ読みしたから正しく読めてる保証はできないけど）

2024/02/07(水) 01:09:12.04

>>210
C の配列宣言子の角括弧内に書ける数値は 0 より大きい値に評価される整数定数式であることが条件で、具体的な型に規定はない。
式の型がなんらかの具体的な型に強制 (型変換) されたりはしないので signed int なら signed int だし、 unsigned int なら unsigned int のままだ。
VLA のときは定数式という条件は外れるけどそれ以外の制限はだいたい同じ。
C の添字演算子の場合もそう。型は整数であればよい。
(値は制限の範囲内である必要はある。)

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

2024/02/07(水) 12:42:17.44

std::functionって、有効な関数がセットがされているかどうかでブール値を返しますが、
一旦有効化した後にこれを無効化したい場合って、nullptrを代入したりしていいんでしょうか
そしてその場合std::functionの中身はうまいこと解放されたりするんでしょうか
場合によってはラムダ式を使ってオブジェクトをキャプチャしていたりして
あまりその辺りの説明が見当たらない感じがしました

2024/02/07(水) 12:56:29.41

それでいいよ

2024/02/07(水) 13:12:18.32

>>217
https://timsong-cpp.github.io/cppwp/n3337/func.wrap.func.con#15

2024/02/07(水) 14:19:19.97

>>218
ありがとうございます!

2024/02/07(水) 18:20:13.87

>>212
>長いからよく読んでないけどコンパイラは型
>を認識をしてんだから-1と0xFFFFFFFFは
>区別してるだろ
char a[100-101];
みたいに結果的に -1 になった場合は、
32BITコンパイラの場合、果たして内部で
0xffff_ffff
と区別をつけているかどうか。
unsigned型と考えれば0xffff_ffffであり、
signed型と考えれば -1 です。
ターゲットが 32BIT Windows どちらもエラー
になる可能性は高いですが、理由は結構異なる
と言えば異なると思います。

2024/02/07(水) 18:25:16.10

もっと言えば、32BIT ターゲットで、
char a[0x80000000 | 1];
みたいな場合、中味は signed と
捉えれば「負数」ですが、unisgned と
捉えれば、0x80000001 という大きな値
に過ぎません。
どちらもエラーになる可能性が高いですが。

2024/02/07(水) 18:40:38.44

リテラルにも型がある
1はint
0x80000000はunsigned int
演算結果はunsigned int
ルール決まってるから

2024/02/07(水) 18:55:38.23

x86のアセンブラのディスプレースメントは符号付いてるけどな
他のマシン系はワカランけど

2024/02/07(水) 20:52:20.31

>>222
32bit環境には64bit整数はないと思ってるの？？

2024/02/08(木) 18:55:38.81

>>223
なるほど。そうなるわけですね。
本当に書いた人の意図がどうかに関わらず、
規則で決まっていると。
1UL のように書いてあれば unsigned。
そして、UL のようなものを書いてない場合、
1 のように小さな値は、signed ですが、signed の
範囲を越えるようなものは、unsigned になる、
などの規則があるわけですね。

2024/02/08(木) 18:56:00.93

>>225
そういう問題ではないようですが。

2024/02/10(土) 12:18:06.78

>>185
>>183の主張の
>一方、例外を生じないライブラリの使い方（関数の呼び出し方）を心掛けるかどうか。これなら選択肢がある
が完全に読み飛ばされている件について：

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

>>188のように自分が何をやっているのか認識しないまませき止めるのは論外すぐる……

2024/02/10(土) 12:26:53.58

>>186
>catchしたらテストケースが増えるかどうかという話とはなんも関係がない。
あっる
catchする必要性箇所を設計で厳選すればcatchが減るのだからテストケースは減らし得る

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

catchする必要性箇所を設計で厳選した場合：
foo()の呼び出し箇所（とするのが現実的でないなら呼び出しﾊﾟﾃｨｰﾝ）がm個だとしたら、
例外が飛んでこないことを確認するのテストケースがm個のオーダーで要るだけ……

2024/02/10(土) 16:57:16.73

>>228
読み飛ばしてねえよ
funcB()は処理を中断すべきエラーが発生する可能性があるんだろ？だったらそれを適切に処理して後続の処理をやったりやらなかったりする必要があるわけだろ？
それはfuncB()がエラーを例外で返そうと戻り値で返そうとなんか他の方法で返そうと何も変わらないはずじゃないか

2024/02/10(土) 18:55:23.41

>>229
>例外が飛んでこないことを確認するのテストケースがm個のオーダーで要るだけ……

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

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

2024/02/10(土) 20:56:08.28

>>228
>>>188のように自分が何をやっているのか認識しないまませき止めるのは論外すぐる……

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

2024/02/10(土) 21:22:31.20

>>232
それは未知の例外投げてきたライブラリを信用し過ぎ
製品ならそういう「たぶん大丈夫っしょw」的なのは許されないね

2024/02/10(土) 22:40:34.32

>>233
逆だろ。catchしないのはライブらにが未知の例外を投げてこないだろうと信用してるってことだろ。

2024/02/10(土) 23:44:13.35

>>234
catchしないということは終了させるということ
見かけ上動き続けたらいいってもんじゃない

2024/02/11(日) 03:08:09.08

>>232
それは未知の例外投げてきた原因を調査しなさすぎ
製品ならそういう「たぶん大丈夫っしょw」的なのは許されないね

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

2024/02/11(日) 03:16:41.24

質問なのですが
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)　で正しい？
（実際　std::ldexp(0.5, min_expn - digits + 1)　> 0.0 やが　std::ldexp(0.5, min_expn - digits + 1) / 2.0 == 0.0 であっる

Q3.にもかかわらず、
std::ldexp(0.5, min_expn - digits) > 0.0 になるのはなんで……orz

2024/02/11(日) 03:25:12.56

訂正 |||。n_
誤1： IEEE735
正1： IEEE754
誤2：非正規化数
正2：非正規数

2024/02/11(日) 06:22:40.58

>>237
wandboxに書いてみ

2024/02/11(日) 07:55:26.62

>>237
決まっていない。言語仕様としては未規定。
std::numeric_limits::is_iec559 が真であるならその挙動をあてにしていいがそうでないときは各環境の事情による。

2024/02/11(日) 09:19:29.20

>>236
あんたの認識じゃ catchする=見かけ上動き続けるなんだ？
なんか根本的に勘違いしてる気がする。

2024/02/11(日) 09:29:04.38

例外は「関数外にエラー発生を伝える」ための「方法の一つ」でしかない
関数の処理がどんなエラーを発生させうるか、受け取った外側の処理がその情報をどう取り扱うべきかという問題とは完全に直交してる
（言語ごとにある程度の慣例はあるけどあくまで慣例）

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

2024/02/11(日) 09:47:48.61

アンカ間違えた、すまん
>>241は>>235宛な。

2024/02/11(日) 09:47:48.79

>>242
お前はバグのないお花畑を考えてるからそういう理想的な抽象論を持ち出すんだよ
c++の現実は道を踏み外したら即カオス
stlのコンテナのpopに返り値がない理由は知ってるか？
あのレベルの考察でソフトウェア設計している人間が世の中にどれだけいると思う？

2024/02/11(日) 09:55:44.37

>>241
>>169を否定している
知らない例外が飛んできた場合にcatchして握りつぶしてそのまま動作を継続するかどうかって話な

2024/02/11(日) 10:07:06.72

>>244
バグのあるなしなんか関係ない設計の話だし、「例外はエラー伝達の具体的方法の一つ」って話のどこが抽象的なのかも分からないし、
「C++の現実」とか「カオス」が具体的に何のことで何の関係があるかも分からないし
STLにpopがないのはnoexcept moveがない時代に例外安全に出来なかったからだけど今の話に何の関係があるかわからないし
そんなのまともなC++erなら誰だって考えて設計してると思うけど、そうでないタコの話が何の関係あるかわからないし何もかも分からなすぎてすごい
仕事でそんなドキュメントやレビューコメント出すなよ

>>245
知らない例外を握り潰すのも、知らない戻り値をガン無視するのも一緒
errnoが変わってるのを無視するのもint*err引数に渡した変数の値を無視するのもexpected<T,E>で帰ってきたEを無視するのも「知らんエラーを無視した」という結果は一緒
知らんエラーを無視していいかどうかの意味論と、そのエラーがどう伝播して来るかかは関係ない
関係ない話を混ぜるからお前のC++はカオスなんだよ

2024/02/11(日) 10:14:56.00

>>245
？
そのtryブロックの処理が失敗したものとするって書いてあるじゃん。

2024/02/11(日) 11:18:37.96

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

2をテストもせずに放置するとおかしくなる例は>>183のとうーり
これにより、例外を生じる関数foo()の呼び出しﾊﾟﾃｨｰﾝn個それぞれに対し、a個のテストが必要になっる
例外を発生させない使い方をするなら、n*a*mではなくmの定数倍（例外を飛ばさない使い方に依存擦る定数）。
例外が飛んで来たらバグ。わかりやすい

例外を多用しつつn*a*mをよくわからない計算とか言っている時点で以下略

2024/02/11(日) 11:18:50.45

>>244
以下の主張のどこが抽象論なのかkwsk、
1. ライブラリのドキュメントに従い、可能な限り例外を生じない使い方で設計する（>>236
2. 例外が生じない前提としたところは例外が生じないことをテストする（m個のオーダー）（>>229
3. 1と2の過程で意図に反して飛んでくる例外がある場合は原因を調査し、修正を試みる（>>228　例外が飛んで来たらバグ
4. 3を意図通りの形で解決できないことが判明した場合は
　　（ライブラリの使用方法の当方の誤解、ライブラリのドキュメントの不備、ライブラリの作りの粗さによりこれはあり得る、
　　結果的にtry { } catch (/*省略*/) { ... }を付ける可能性もある（>>228
5. 例外を複数段fall-throughか再スローを許し、かつそれが起きた後もプログラムの
　　正常な動作の継続を意図する場合はテストケースが爆発する(>>

設計し、検証し、必要とあらばtry { } catch ( ) の追加も含めた修正を行うと言っているのやぞ；；；

いっぽう藻前らの主張は
1. 例外をせき止めれば良い（←処理不能な未知の例外が飛んでくることが無いというライブラリに対する全幅の信頼
2. 例外を処理したりfall-throughしたり再スローしたりする関数はn*a*m個のテストしなくても動くっしょ
　（←自己のコードに対する無制限の気体
3. ドキュメントは100%信頼せず、読まない
の3成分からなるわけやが……

2024/02/11(日) 12:01:58.52

>>248
>例外が関数の階層をぶち抜いてfall-throughしてくることを忘れている発言

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

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

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

2024/02/11(日) 12:31:22.40

>>249
>1. 例外をせき止めれば良い（←処理不能な未知の例外が飛んでくることが無いというライブラリに対する全幅の信頼

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

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

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

2024/02/11(日) 12:37:47.91

仕様書や規格書はその意図を正確に読み取ろうとするのに
掲示板の他人の書き込みは積極的に曲解しようとするのは何故か？

2024/02/11(日) 12:44:06.42

見下しているからよ
こいつらは俺より下なはずと

2024/02/12(月) 07:49:39.70

本気で面白いと思ってやってんだろう

2024/02/12(月) 08:44:56.68

例外は糞！危険！意味不明！テスト漏れる！って言ってる奴ほど
if (err != 0) { return -1; }が大好きなんだよな
本質的にやってること変わらないのに

2024/02/12(月) 15:42:15.86

ファイル名に年月が使えないの困ります。
2024/02/11_データ.txt
とか

2024/02/12(月) 15:46:00.47

>>256
それ検索性最悪だから良くないんだよなぁ。
データ/2024/02/11/データ.txt
データ.txt/2024/02/11/データ.txt
あたりならまだ許せる。

2024/02/12(月) 16:40:43.94

ふつう年月日はハイフンで区切るよね

2024/02/12(月) 17:02:03.84

スラッシュを使う習慣が悪いわけではないが
プログラマの感覚だと ISO 8601 の方式に馴染みが有ることが多いってのはある。

2024/02/12(月) 17:31:20.60

年月日は「ふつう」がないのでみんなが苦労している
日本とアメリカとイギリスで順番が違うし
日本には「令和」とかあるし

2024/02/12(月) 18:43:50.33

Windowsでも / をディレクトリ区切り文字として使えるけど(場面は限定的かもしれないけど)、その認識で使ってるのかな…

2024/02/12(月) 20:07:00.91

Linux で * という名前のファイルを消そうとして
うわあぁぁぁとなった話はたまに聞く。
使えたとしても使うべきでない文字もある。