【初心者歓迎】C/C++室 Ver.104【環境依存OK】

**デフォルトの名無しさん** · 2018/12/28(金) 06:04:52.38

エスケープシーケンスやWin32APIなどの環境依存なものもOK
そのような質問は必ず環境を書きましょう
半角空白やタブでのインデントはスレに貼ると無くなります

コードを貼れる所
http://codepad.org/
https://ideone.com/

前スレ
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1530384293/

**デフォルトの名無しさん** · 2019/04/20(土) 18:51:11.02

>>876
E8400の機があるから調べてみよっか？
何で検索したら調べ方出てくるか教えてくれたらやってみるよ

**デフォルトの名無しさん** · 2019/04/20(土) 19:22:01.02

>>877
ありがとう
これでどうかな？
//-------------------------------------------------
#include <stdio.h>
#include <conio.h>

class ClassName
{
public:
int int_1;
double double_1;
char char_1;
double double_2;
};

int main(void)
{
ClassName class_obj;
printf("クラスインスタンスのサイズ:%d\n",sizeof(class_obj));
printf("int_1のアドレス:%p\n",&class_obj.int_1);
printf("double_1のアドレス:%p\n",&class_obj.double_1);
printf("char_1のアドレス:%p\n",&class_obj.char_1);
printf("double_2のアドレス:%p\n",&class_obj.double_2);
_getch();
return 0;
}
//-------------------------------------------------
クラスインスタンスのサイズが24なら4の倍数バイト、32なら8の倍数バイトの境界になってると思う
(8の倍数バイトの境界なら、各メンバのアドレス(16進数表示)が全部8違いになってるはず)

**デフォルトの名無しさん** · 2019/04/20(土) 20:52:42.24

>>878
ソースありがとう

クラスインスタンスのサイズ:32
int_1のアドレス:0036F7A0
double_1のアドレス:0036F7A8
char_1のアドレス:0036F7B0
double_2のアドレス:0036F7B8

これで情報足りるかな？
ttps://i.imgur.com/YAVbZWa.jpg

**デフォルトの名無しさん** · 2019/04/20(土) 21:11:23.94

>>879
どうもありが㌧㌧
Core2Duoで8バイト境界になってるなら、もう4バイト境界の環境の事は無視しても大丈夫なのかもね
思ったんだけど、もしかしたら、32bit(4バイト)のみ対応のCPUと32bit/64bit(8バイト)両対応のCPUの違いなのかな？
違うかな？そんなに単純な話ではないか・・・

**デフォルトの名無しさん** · 2019/04/20(土) 21:42:31.24

https://docs.microsoft.com/ja-jp/cpp/build/reference/zp-struct-member-alignment
https://docs.microsoft.com/ja-jp/cpp/preprocessor/pack

だいたい sizeof(class_obj) がコンパイル時定数なことくらいC++やってりゃわかるだろ・・・

**デフォルトの名無しさん** · 2019/04/21(日) 00:19:13.52

本質じゃないがxmlじゃなくてjsonがオススメ
もっと突っ込むならyamlがオススメ

**はちみつ餃子** ◆8X2XSCHEME · 2019/04/21(日) 01:03:10.69

YAML は人間が読むこともあるなら可読性とのバランスで選ぶことはあるかもしれんが、
機械可読であればよいような場面で選択する理由は無いんじゃないかな。

既存のライブラリを使えばどれでも手間は大差ないとは思うけど、
バイナリ表現だと MessagePack とか Bencode とかいった選択肢もあるし、
どうして色々なフォーマットが登場したのかというとなんだかんだで「場合による」としか言い様がないからなんで、
まあ主要なやつを一通り特徴を把握しといた方が良いよね。

**デフォルトの名無しさん** · 2019/04/21(日) 01:14:51.26

yamlって何に使うの？

**デフォルトの名無しさん** · 2019/04/21(日) 03:00:37.96

yamlよりはjsonかなぁ

**デフォルトの名無しさん** · 2019/04/21(日) 08:42:04.15

何にじゃねえな
yamlはperl
jsonはjavascript
時代の流れでjsonが優勢になった
出来ることや表現力はあんまり変わらない

**デフォルトの名無しさん** · 2019/04/21(日) 09:55:35.58

yamlは最近dockerとかkubanetessとかansibleとかインフラ/環境系ツールのせいでやたら触る事が多い

**デフォルトの名無しさん** · 2019/04/21(日) 11:02:24.76

もう16バイト境界なんてのも出てきてるのか
VisualStudioのプロジェクトのプロパティのC/C++のコード生成で
構造体メンバのアライメントを8にするか、
コード上で #pragma pack(8) とすれば
強制的に8バイト境界にできるみたいだけど、
マシンに最適な既定値のアライメントから変更する事で速度が遅くなったり
何か不具合が生じたりするものかな？

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

既定のアライメントというのはふつう、メンバの単純型のサイズに合わせられるはず。
16byteの単純型を使うのでなければ16byte境界にする必要もない。

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

問題ないなら旧環境との互換性重視で4バイト境界にするのもありかな？

**デフォルトの名無しさん** · 2019/04/21(日) 11:52:51.02

互換性重視なら、各メンバを自然なアライメントに配置して手でpaddingを挿入して#pragma pack(1)。

>マシンに最適な既定値のアライメント

少なくともx86の場合、それが4とか8とか決まっているわけじゃない。

◆QZaw55cn4c · 2019/04/21(日) 12:27:57.49

>>891
#pragma pack なんて MS の方言でしょう？そんなのを使いながら「互換性重視」とか矛盾してませんか？

**デフォルトの名無しさん** · 2019/04/21(日) 12:45:11.23

そこはポイントじゃないから勝手に読み替えて。

**デフォルトの名無しさん** · 2019/04/21(日) 15:46:14.10

C言語ならともかくC++なのに例外を避けようとする人ってあたまおかしいのかな
標準ライブラリもその他のライブラリも例外を投げる前提なのに頑なに例外を避けようとするってそうとうに筋が悪い非合理的な選択肢だよね

◆QZaw55cn4c · 2019/04/21(日) 15:56:42.10

>>894
例外の実装方法の一つ sjlj に抵抗を感じるのなら、それは感覚として正常だと思います
C で sjlj を使用しての例外実装コードが書けますか？書けない場合は >>894 は単なる馬鹿か宗教者だと思います

**デフォルトの名無しさん** · 2019/04/21(日) 16:03:56.39

>>895
何が言いたいのかわからん
sjljが重いのが嫌なのか
あの仕組み自体が気色悪くて嫌なのか

でも今時sjljで例外実装なんてしていないよね
わざわざ選ばない限り

**デフォルトの名無しさん** · 2019/04/21(日) 16:08:40.35

SJLJの話じゃないです
例外を避けてオレオレエラーコードを返す迷惑な人達の話です

**デフォルトの名無しさん** · 2019/04/21(日) 17:16:18.32

例外もまともにキャッチされないので
どっちもクソです

**デフォルトの名無しさん** · 2019/04/21(日) 17:17:33.88

エラーの発生頻度によるのでは？
throwは高コストだから発生頻度が高い場合は戻り値で処理した方がいい

**デフォルトの名無しさん** · 2019/04/21(日) 17:22:58.19

システムによる
航空機の運航システムでのエラー処理はどうすりゃいいわけさ

**デフォルトの名無しさん** · 2019/04/21(日) 17:53:59.57

>>899
入力の検証、パース以外で頻繁に発生するエラーって例えば何でしょうか？
そもそもthrowはコストそんなに高くないのでは？
エラー情報(コード、メッセージ、下位エラー情報、スタックトレース等)を戻りでコピーしまくるほうが高く付くと思います

◆QZaw55cn4c · 2019/04/21(日) 18:22:36.24

>>896
自分で実装できないものを、その仕組みもわからないのにホイホイ使ってしまってもいいのでしょうか？
他の言語ならともかく、C/C++er がそういうところに無自覚なのは大いに問題があるのでは？
そんなことでデバッグできますか？

◆QZaw55cn4c · 2019/04/21(日) 18:23:33.96

>>896
＞今時sjljで例外実装なんてしていないよね
じゃあ win32api の構造化例外sehでも許容しますよ

**デフォルトの名無しさん** · 2019/04/21(日) 18:28:33.16

>>902
内部構造がわからないものでもAPIドキュメントを読んで使えるようになるのが正しいプログラマでは？

**デフォルトの名無しさん** · 2019/04/21(日) 18:34:32.58

まあそういう賢いプログラマなら当然の様にSpectreの可能性に気づいて対策していたんだろうね。
きっと

◆QZaw55cn4c · 2019/04/21(日) 18:40:14.32

>>904
他の言語ならそうですね
でもC/C++ において、そんな態度でいいのですか？

**デフォルトの名無しさん** · 2019/04/21(日) 18:41:53.50

つまりすべてのAPIをスクラッチでかける人間以外使うなと言うことなんだな

**デフォルトの名無しさん** · 2019/04/21(日) 18:42:38.56

>>906
いいですよ
DRYを守ってください

**デフォルトの名無しさん** · 2019/04/21(日) 18:44:31.12

大体sj,ljが肝なのだから、そこ丸投げしたら同じようなもの

**デフォルトの名無しさん** · 2019/04/21(日) 18:51:39.35

内部構造まで把握してなきゃ使っちゃだめなんていう烏滸がましい思想を持ってると
実装に強い影響を受けるエラーコード返し方式を選んでしまうのだろうな

**デフォルトの名無しさん** · 2019/04/21(日) 18:52:38.66

なんかライブラリ使ってるだけの輩がイキリ出しとるなw
確かにライブラリによってはそのライブラリの単体テストなり書いといた方が良いこともある。

**はちみつ餃子** ◆8X2XSCHEME · 2019/04/21(日) 18:57:06.46

静的例外の提案がある。

使える例外オブジェクトに制限があるし、
静的例外を投げる可能性がある関数は型として明記しないといけないけれど、
見かけ上は例外の構文を使いつつ
実質的に返却値と合わせて例外オブジェクトを受け渡すような方法をとれる。

https://cpplover.blogspot.com/2018/07/c.html

江添氏もこれには期待しているらしいことを書いている。

**デフォルトの名無しさん** · 2019/04/21(日) 18:59:12.07

>>911
SOLIDを実践しないからそんなおかしなテストを書くはめになるんでしょうな

**デフォルトの名無しさん** · 2019/04/21(日) 19:03:01.42

例外便利だけど、例外が高確率で起こる場面じゃ使うと遅くなるから、仕方なく結果コード判定してとかの糞コード書かなきゃいけなくなる。

**デフォルトの名無しさん** · 2019/04/21(日) 19:10:10.25

>>912
いいアイデアですね
早く実現して普及して欲しいものです
エラーコードを返す非常識なコードが世界から駆逐されますように

**デフォルトの名無しさん** · 2019/04/21(日) 19:10:58.11

俺は戻り値をboolにするかbool*のout引数を用意してエラー内容はメンバに記憶しておき、
成否だけで十分な場面では単純にbool値だけを見て、詳細が必要な場面だけエラー内容を取得する
ってやり方が気に入ってる

**デフォルトの名無しさん** · 2019/04/21(日) 19:12:17.54

>>914
入力の検証、パース以外でそんな場面ありますか？
それと、その場面は一般的なシステムでもよく採用されるのでしょうか？

**デフォルトの名無しさん** · 2019/04/21(日) 19:16:05.70

ファイルシステムでパスが存在するかとか権限があるかとか
リソースを確保できるかどうかとか
いくらでもあるでしょう

**デフォルトの名無しさん** · 2019/04/21(日) 19:17:16.59

>>916
例外を使わないとこうやってエラー処理がガラパゴス化するんですよね
私が今日弄ったシステムでも一部のコードだけ中途半端に特殊なエラー処理ルールを採用しています
本当に困ります
胃が痛いです

**デフォルトの名無しさん** · 2019/04/21(日) 19:38:20.06

そりゃそのシステムの問題じゃね？
例外なら「中途半端に特殊なエラー処理ルール」にならないというわけでもあるまい。

**デフォルトの名無しさん** · 2019/04/21(日) 19:45:15.97

>>918
ボトルネックになるほど存在しない確率が高いファイルに連続アクセスしているならそんな小さな最適化前に見直すべきところがありそうですね
リソースについても同様といえます

**デフォルトの名無しさん** · 2019/04/21(日) 19:47:17.19

>>920
人間のやることなので完璧は無理でしょうな
比較の問題になります
例外とエラーコード返しを比べればどちらが標準的な型式に収まりやすいか？という問題なら例外が圧倒的に優勢でしょう

**デフォルトの名無しさん** · 2019/04/21(日) 20:14:16.72

例外にすればエラー検知は簡単になるでしょうが
そのエラーに対してどう処理するのかはケースバイケース
標準的な方法なんて無いと思うけど
そこが肝心な所で優勢かどうかは些末のことだと思うよ

**デフォルトの名無しさん** · 2019/04/21(日) 20:21:35.36

例外はcatchで標準化されますが？
その後のことは例外とエラーコードの比較って文脈で語ることじゃないな
強いて言えば例外の方が再通知の仕方もより標準的と言えるが

**デフォルトの名無しさん** · 2019/04/21(日) 20:24:46.24

戻り値がboolならそれが正常終了したかどうかを表していることは誰にでもわかる
呼び出し元を正常系と異常系の単純な分岐にでもしておけば致命的なバグになることはない
例外の場合はその発生率が極めて低い場合にｔｒｙ-catch忘れが起こると致命的なバグを含んだままリリースされかねない

**デフォルトの名無しさん** · 2019/04/21(日) 20:34:33.10

>>925
boolの解釈は人それぞれ
bool is_invalid() const;みたいなのもあるよね
あるいはただのビットフラグのON/OFFを示してるかもかもしれない
そもそもそれが処理の成否を表しているかどうかすら統一されてない

リターンコード方式ではリターンコードと分岐の洪水による目くらましでコーディングミスが多発する
それは必要なcatchを書き忘れる確率よりもずっと高い確率で発生する
例外は処理すべきものだけしか書かないから見通しが良く仕様書との比較もしやすい
リターンコード形式では何もしなくてもいいのに定型処理を書かねばならず
それによってどのエラー処理が仕様書に書かれた本当に必要なエラー処理なのか目で見てわかりにくい

**デフォルトの名無しさん** · 2019/04/21(日) 20:43:33.90

catch 以降でエラー内容に応じて振り分ける訳ですか？
気が遠くなりませんか？

**デフォルトの名無しさん** · 2019/04/21(日) 20:47:31.48

>>927
あぁ
そもそも例外の文法すら知らないのか

◆QZaw55cn4c · 2019/04/21(日) 20:56:54.94

>>919
リターン値方式に比べて exception のメリットは何でしょうか？
そしてそのメリットは本当にメリットでしょうか？

◆QZaw55cn4c · 2019/04/21(日) 20:57:56.41

>>916
エラー値を取得するタイミングがずれるようだとスレッドセーフを保障できなくなるのでは？

◆QZaw55cn4c · 2019/04/21(日) 21:00:30.98

>>922
＞標準的な型式
なにを「標準的」とするかは世代差があるのではないですか？
java や c# に慣れた人は exception を推すでしょうし

ここで >>922 を私が強く非難している理由は、「標準的」というバズワードで自説を合理化する、その自分勝手さという点にあります

◆QZaw55cn4c · 2019/04/21(日) 21:04:29.00

>>925
＞ｔｒｙ-catch忘れ

>>925 が return-value 派か exception 派かはここでは問題にしません

しかし、この「try-catch」忘れ、という単語の存在そのものが、exception の利点が利点になっていないことを如実に表現していると思います
忘れないようにするための exception が忘れるもとになってしまっている、とか、全然おかしいんじゃないのでしょうか

**デフォルトの名無しさん** · 2019/04/21(日) 21:08:36.84

>>929
レスを読んでください

>>931
異なる世代の衝突があった場合は今を優先すべきでしょう
過去の過ぎ去ったことにいつまでも縋り付いては先へ進めません

ちなみにC++の標準ライブラリは例外を採用しました

**デフォルトの名無しさん** · 2019/04/21(日) 21:11:37.57

>>932
例外はエラー対応を忘れないようにするためのものではありません
例外はエラーの通知方法を標準化することとコーディングの労力を大幅に低減するための機構です
エラーコード形式でも分岐を忘れることはありえます
むしろ不要な分岐も定型処理として書かなければならないエラーコード形式ではノイズが多くミスや忘れが多く発生します

◆QZaw55cn4c · 2019/04/21(日) 21:22:08.96

>>933
＞レスを読んでください
どのレスかアンカーをいただけませんか？

>>933
＞異なる世代の衝突があった場合は今を優先すべきでしょう
＞過去の過ぎ去ったことにいつまでも縋り付いては先へ進めません

「今の方が昔よりよくなった」という世界観に立脚しているのであれば、その説は説明できますが
「今よりも悪くなった」と考えている人を説得することができないのではないでしょうか？

>>933 が必要なのは「今の方がよくなった」と言い切れるメリットがなにか具体的に明示することだと思います。
単に「新しい方がよい」という主観だけを振り回しても、アンチ exception の意見を持つ人は納得できません

>>933 は具体的なメリットを明示することをせずに「新しい方がよい」という主観ばかり述べているのだから、議論の仕方をしらない「馬鹿な文系」に私からはみえるのです…

◆QZaw55cn4c · 2019/04/21(日) 21:28:56.88

>>934
私の考えるところの exception の利点の一つは、exception の発生した階層から遠く離れたところでも、その exception を catch して処理を記述できるところにある、と考えています
もう一つは exception を catch するとき指定するのは class だから、このエラークラスを派生関係として階層化することで、エラー体系の構造化ができるところでしょうか（派生クラスでも基底クラスでも catch できる、という点です）

しかし exception の話が持ち上がる度に、私の思う上記二点の excption の利点は言及されたためしがありません…
これでは exception の本当にいいところがメリットとして理解されていない、というか、メリットになり得ていないようですね…

exception は単なる無駄コスト食らいなんじゃないですかね…

**デフォルトの名無しさん** · 2019/04/21(日) 21:29:57.46

>>935
沢山あるので面倒です
今日のレスを読み直してください

悪くなったのが事実であれば新しいものが普及する前に消えるでしょう
普及してしまった時点で一部のロートル以外は良くなったと考えている証拠です

**デフォルトの名無しさん** · 2019/04/21(日) 21:34:59.57

>>936
離れた位置で捉えられる点はコーディングの省力化に暗に含まれると考えていいでしょう
全ての階層で定型処理を書かなくてもいい==離れた階層でも捉えたいところでだけ処理を書けばいい
ということです

例外の階層化についてはその通りですね
地味なので忘れがちですが便利です

◆QZaw55cn4c · 2019/04/21(日) 21:36:10.23

>>934
＞エラーの通知方法を標準化することとコーディングの労力を大幅に低減する

ここでもバズワード「標準化」を使っていますね、漠然とした抽象的な単語を並べればいい、という思考の粗さが気になります
それに異常系の記述はどうあがいても、場合わけして都度逐一記述するしかないのは、return-value 派にしても exception 派にしても同じで、記述する中身が減るわけじゃありません
それとも exception で書けば記述が減るというのなら、何か書いてみてください

>>934 を読むにつけても、>>934 は本当に物事を突き詰めて考えているのですか？
世間がこういっている、とか、Java や C# ではそうしている、とかいう空気の読みあい、ポジション取りの忖度しかしていないのでは？

>>934 はたぶん文系プログラマなんでしょうね、私には強くそう推察されるのです…

◆QZaw55cn4c · 2019/04/21(日) 21:36:33.69

>>937
アンカーを書くことくらいもできないのですか？

◆QZaw55cn4c · 2019/04/21(日) 21:38:47.42

>>937
＞悪くなったのが事実であれば新しいものが普及する前に消えるでしょう

google のコーディング規約では exception を推奨しないようですよ
https://ttsuki.github.io/styleguide/cppguide.ja.html#Exceptions

悪いものでも消えずに、もっと悪いことには悪疫として蔓延しているものもありますよ、もしかすると C++ の exception もその一つなのでは？

**デフォルトの名無しさん** · 2019/04/21(日) 21:38:57.23

ちなみに例外はもうすでに新しいものではありません
長年多くのプログラマによって効果が実証され続けてきた枯れた機能です
例外に変わるエラー処理機構が流行らなかったという事実が例外の完成度の高さを裏付けています

**デフォルトの名無しさん** · 2019/04/21(日) 21:41:14.44

>>939
エラーに対するハンドリングのコードについては例外とエラーコードの比較の外だとすでになんどか書きました
例外によって削減されコードは無意味な定型処理のことです

**デフォルトの名無しさん** · 2019/04/21(日) 21:41:34.96

googleが例外使わない理由は、例外を否定する類いのものでは無かったような

◆QZaw55cn4c · 2019/04/21(日) 21:45:14.38

>>942
＞例外に変わるエラー処理機構が流行らなかった

というか exception そのものが流行らなかった、というべきでは…
なんども繰り返しますが「新しいものがいいもの」「枯れた機能」とかいう主観はいらないから、「exceptionの具体的な利点」を書くべきです

>>943
言っている意味がわかりません、お手数ですが、少し字数を使って説明いただけますでしょうか？

◆QZaw55cn4c · 2019/04/21(日) 21:46:42.42

>>944
「例外安全」を保障するのが、これは滅茶苦茶しんどいので、その一点で嫌われているんだとおぼろげながら感じています

**デフォルトの名無しさん** · 2019/04/21(日) 21:52:11.67

>>941
googleが常に正しいわけではないでしょう

例えばそのページでは、例外安全性を考慮していないコードのリスク、つまりリソースリークについて書かれてますがリターンコード形式でも解放を忘れればリークするのは同じことです
そして、さっきも書きましたがリターンコード形式では余計な定型処理がノイズとなってそういったミスをしやすくなることが問題です
コントロールフローが追跡難化するリスクも全く逆でダラダラと必要ない定型処理を書かれた方が追跡が難しくなります

自分で考えずに権威を盲信する人を文系と揶揄することがありますが
もしかしてあなたも文系なのでしょうか？

**デフォルトの名無しさん** · 2019/04/21(日) 21:56:08.07

>>945
例外を受け取ると何もせず上位に通知するメソッドを考えてください
例外形式ではコーディング量は0です
リターンコード形式では少なくともリターンコード値が正常系か異常系か判断して戻す分岐が必要です
これは少なくとも1行の無意味な定型処理を追加しなければならないということです
実際にはそのプロジェクトの規約によって1行どころでは済まないことが多いのですが…

**デフォルトの名無しさん** · 2019/04/21(日) 21:56:49.72

>>947
リターンコード形式で発生する余計な定型処理のノイズの例と例外でそれを回避できるケースの例をください
書かなきゃいけないコード量は本来大差ないはずです

**デフォルトの名無しさん** · 2019/04/21(日) 21:57:05.52

例外安全というか、googleで想定しているリソース解放漏れって要はRAIIになっていないって事だよね

**デフォルトの名無しさん** · 2019/04/21(日) 22:02:25.75

>>946
リターンコード形式でも例外安全性(エラー安全性とでもいうのでしょうか)を守るには大きな労力がかかるはずです
リターンコード形式なら自動的にリソースが安全に解放されて全ての状態が実行前にロールバックされるといったことはありません
例外でもリターンコード形式でもリソースの解放と状態のロールバックの責任はプログラマあります

◆QZaw55cn4c · 2019/04/21(日) 22:03:22.86

>>947
＞例えばそのページでは、例外安全性を考慮していないコードのリスク、つまりリソースリークについて書かれてますがリターンコード形式でも解放を忘れればリークするのは同じことです

そこで exception の実装に話が戻るのです
exception の実装（例えば sjlj, seh のどちらかひとつでいい）はどうしても（隠れたところに）グローバル変数を必要とするのではないですか？
これはスレッドセーフや例外安全を考えるときに、大きな癌になりうるでしょう

一方、return-value 方式は、頑張ればローカル変数だけで記述できる
return-value 方式の方が考えるのが楽ではないですか？

＞自分で考えずに権威を盲信する人を文系と揶揄することがありますがもしかしてあなたも文系なのでしょうか？

かりにそうだったとしても最初は「新しいものはいいものだ」で押し通そうとした、あなたには言われたくないですね…

**デフォルトの名無しさん** · 2019/04/21(日) 22:06:18.26

>>949
例外の場合
T val = f(...);

エラーコード場合
T val;
int ret = f(..., val);
if (is_error(ret)) return ret;

最小だとこの程度でしょう
とはいえ膨大なコードベースになるとこれだけでもうんざりしますが

◆QZaw55cn4c · 2019/04/21(日) 22:10:06.06

>>948
その例外の上位への素通し、って、確かに >>936 では私も例外の利点だと書いてしまいましたが、でも実際には嫌われることなんではないですか？
java は下位ルーチンが発生させる例外（のうちのある種類）は、上位側で catch しとかないとコンパイラが怒るんではないでしょうか？

**デフォルトの名無しさん** · 2019/04/21(日) 22:12:03.58

>>953
ｔｒｙ文を含めれば大差ありませんね？

**デフォルトの名無しさん** · 2019/04/21(日) 22:12:10.36

嫌われないよ
RAIIじゃない場合
一度キャッチしてリソース解放したあとスローし直さなきゃリソース漏らすというだけ

◆QZaw55cn4c · 2019/04/21(日) 22:15:52.45

>>956
なるほど、だとすると、>>936 で書いた「exception の発生した階層から遠く離れたところでも、その exception を catch」できる、というのは無条件では c++ では利点にならないですね、return-value 式とほとんど変わらない…

**デフォルトの名無しさん** · 2019/04/21(日) 22:20:25.10

>>952
たとえグローバル変数を使った実装だったとしても例外の利用者にとっては透過的なので問題はありません
スレッド処理でも問題はありません
同じスレッドでは利用者は何も気にせずに例外使えます
スレッドを結合するところでは例外を転送してください
そのための標準的な方法も用意されています
エラーコード形式の場合はスレッド間転送も標準のない独自形式になるのでより難しそうですね

**デフォルトの名無しさん** · 2019/04/21(日) 22:34:00.26

>>954
Javaには例外時に自動でリソースを閉じるための構文が存在しない時期がありました
検査例外はそのときの名残です
GCされるまで自動で閉じられることはないからちゃんと手動で解放しろと注意喚起する意味では検査例外にも価値があります
逆に言うとRAIIやusing/IDisposeのような機構が適切に使われている場合はうっとおしいお節介でしかないわけです

ちなみにリターンコード形式場合はリソースを確保していない場合でも定型処理を書かなければなりません
したがってそのうっとおしさは検査例外とは比較にならないほどの負担になります

**デフォルトの名無しさん** · 2019/04/21(日) 23:25:54.10

いつもはうっとうしいQZ某が、今日は概ね論理的な物言いをしているように感じる。
対する例外推しの彼は、饒舌だが自説を貫こうとするだけで相手を納得させるような説明はしようとせず、議論をしていつもりで議論できてない人のように見える。リアルなフォーク准将を見ているような気持ち悪さがあるよ。

ちなみに俺は例外も戻り値も適材適所で使い分けて一貫性がとれていればいいんじゃね、という意見だけど、議論に加わる気は無いのでスルーしてくれ。

**デフォルトの名無しさん** · 2019/04/22(月) 00:23:12.59

納得させる気は最初からないからね
ただ単に事実を語っただけ

**デフォルトの名無しさん** · 2019/04/22(月) 01:28:16.24

機械学習とかアプリケーションレイヤの開発をしてて普段はJavaとかpythonで書いてるんだけど相談。
手間や保守を考えるといくら早く動作しても全部cで実装は厳しくて、複雑な計算とかだけcに渡そうと思うんだけど、このレイヤだとそんなもんだろうか？実際の仕事での使われ方の例があれば教えてほしい。

**はちみつ餃子** ◆8X2XSCHEME · 2019/04/22(月) 05:12:41.91

例外安全という言葉には色々と含まれるけど、
とりあえず最低限度の保証としては「リソースリークが起こらないこと」とすると、
C++ ではデストラクタで後始末するのが基本だ。
(RAII)

私が強調しておきたいのは、リソース管理の配慮はクラス定義に押し込めることが出来るということと、
可能な限り押し込めるべきだということ。

エラー発生の通知に使うのが返却値であれ例外であれ、
エラーへの対処の中にリソース回収のコードを書かなきゃならないようならその時点でダメなコードだ。
デストラクタで回収されることをあてにしたい。
(bad_alloc のような致命的なやつはちょっと話が違ってきたりとか、単純ではない場面はあるけど……。)

で、デストラクタでリソースを後始末するというのが出来ているという前提であれば、
例外を使うか返却値を使うかの差は対処のためのコードをどこにかくかの違いに過ぎなくなる。
Java と違って関数が送出する例外を型システムで管理してくれないわけだし、
引数をチェックしているかどうかもプログラマが気を付けるしかないので、そんなに違いはないと思う。

違いはないがどちらかに一貫させるのが望ましいと考えると、
C++ の基本的なライブラリに併せるべきだということになって例外を使うのが妥当という判断になる。

ちなみにグーグルのガイドラインが例外を避けることになっているのは
グーグルで使っている既存のコードが例外への配慮を充分にしてないから
やむを得ずそれに合わせるためでフルスクラッチに出来れば違う判断をするかも
ってことも書いてあるので、例外を避ける根拠としては弱い。

**デフォルトの名無しさん** · 2019/04/22(月) 07:22:42.90

ON ERR GOTO 100

**デフォルトの名無しさん** · 2019/04/22(月) 08:55:56.47

#define return goto

◆QZaw55cn4c · 2019/04/22(月) 16:34:18.66

>>960
＞いつもはうっとうしいQZ某が、今日は概ね論理的な物言いをしているように感じる。
あれ？れれ？
おっかしーなー、私もプログラムを書く人だし最低限自分の作ったバグくらいはさっさと片付けたいので、そのためにも、いつも論理的でありたいと願っているのですが…

**デフォルトの名無しさん** · 2019/04/23(火) 13:32:34.33

そういうとこだよ
こういうのってたいてい本人は自覚してないもんだからやっかい

◆QZaw55cn4c · 2019/04/23(火) 19:01:53.94

>>963
＞違いはないがどちらかに一貫させるのが望ましいと考えると、
＞C++ の基本的なライブラリに併せるべきだということになって例外を使うのが妥当という判断になる。

この意見に対しては私は痛烈な批判を浴びせることになるでしょう
曰く、C/C++ の人なら言語的な統一感よりもコスト、というか単純性を優先したくなるのではないですか？
UML のグジャグジャ感をみるにつけても、「言語法律家」なるものはきわめて忌むべき存在と私は考えています

exception を実装するためには、隠れグローバル変数をどうしても準備しなければならない
シングルコアで exception の履歴を単一スタックに全部のせることができるのなら、ローカルで sjlj を駆使して、あるいは書き手からみえないところで純ローカル変数的世界に納めることもできたかもしれませんが、
今やマルチコアで実際に複数のスタックとプログラムカウンタが走る時代で、exception の実装は OS に丸投げの複雑怪奇、ついでにコストも複雑怪奇でパンピーには理解が及ばない…

そんな巨大かつ複雑なスケールの実装を必要とするのに見合った exception のメリットは何か、今も自問自答を繰り返しているのです

**デフォルトの名無しさん** · 2019/04/23(火) 19:28:11.67

単純さを選んだら例外になったというお話だったのさ。ちゃんちゃん

**デフォルトの名無しさん** · 2019/04/23(火) 19:47:47.79

なぜsjljにこだわるのか
コルーチンとか標準化されても使わなそうだな

**デフォルトの名無しさん** · 2019/04/23(火) 19:58:30.12

c++の言語仕様に例外の実装にはグローバル変数使えとかSJLJ使えなんて縛りあったっけ？

◆QZaw55cn4c · 2019/04/23(火) 20:09:00.36

>>971
実装方法までは言語仕様に記述されないでしょうね…

**デフォルトの名無しさん** · 2019/04/23(火) 20:23:18.80

>>972
ということは例外の実装にまで踏み込んで考えるのはナンセンスなのでは？

**デフォルトの名無しさん** · 2019/04/23(火) 21:32:22.59

>>968
例外がos丸投げってのは事実誤認

**デフォルトの名無しさん** · 2019/04/23(火) 21:35:59.14

ちなみにおれはc++の例外は大規模開発でworkしないと思ってるから
経験上ひたすら面倒な事態になる
言語仕様決めてるやつらは言語オタクで大規模開発の経験ないと思ってる

**はちみつ餃子** ◆8X2XSCHEME · 2019/04/23(火) 21:51:05.06

>>968
いつの話をしてるんだよ。モダンな環境では例外送出の実行コストは充分に小さい。

特別な環境で特別な対処をしなきゃならない場合を例に出しても意味がないぞ。
ふーん、そういう場合はそうするんですねとしか言いようが無い。