【初心者歓迎】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/

◆QZaw55cn4c · 2019/04/04(木) 19:24:27.16

>>817
昔作ったツールがひょんなことで役立っています…
あるディレクトリを別のドライブにコピーするだけのことなんですが、いや、まあ、Windows はなかなか御しがたく、path 文字列長が一定範囲を超過すると止まってしまう変てこなコマンドラインツールが未だに現役だったりするのです…
https://mevius.5ch.net/test/read.cgi/tech/1434079972/53

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

>>818
システムコールってやつですか？
オブジェクト指向と並列処理を勉強したいと思ってるのでQtもいいかなと思ってます
どうでしょうか？

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

Qtのデメリットはライセンスだけだから個人でやる分には良い選択

**デフォルトの名無しさん** · 2019/04/12(金) 11:39:32.60

オブジェクト指向を学ぶのにRubyあたりを使うのは
どういうデメリットが？

Pythonは「バージョン違いによる仕様変更」に
入門書レベルのコードが影響されるのであれば「良い選択とは言えない」ことになりそーだけど

**デフォルトの名無しさん** · 2019/04/12(金) 12:37:54.42

>>821
せっかく新しい言語を学ぶなら、近い将来役に立たなくなる言語より他の役に立つ言語を選んだ方が合理的だと思う

**デフォルトの名無しさん** · 2019/04/12(金) 13:47:38.12

pythonて破壊的な変更があったのは20年近く前なのに、未だに古い仕様で書かれた入門書が出回っているなら、オブジェクト指向学習に最適化どうかとは別に、問題な気が。

**デフォルトの名無しさん** · 2019/04/12(金) 14:05:10.56

rubyは古い言語

**デフォルトの名無しさん** · 2019/04/12(金) 14:50:54.53

Qt5.12.2はLGPLライセンスでインストールしとけばok?
他のライセンスは初見

**デフォルトの名無しさん** · 2019/04/12(金) 14:56:36.82

追加パッケージを使わないのならLGPLでおｋ

**デフォルトの名無しさん** · 2019/04/12(金) 15:06:17.42

"Qt Creator 4.8.2 CDB Debugg..." と "MinGW 7.3.0" 64-bit" 入れたら Hello World の窓が表示できるようになったけど、
練習ならそんなかんじでok?

**デフォルトの名無しさん** · 2019/04/12(金) 15:28:10.39

しばらく正常に動いてるように観えてても
あとで問題が顕在化して困るパターン

**デフォルトの名無しさん** · 2019/04/12(金) 15:38:10.46

どのような問題が発生しうるのでしょう？
もっぱら個人用の練習用とする予定

**デフォルトの名無しさん** · 2019/04/12(金) 15:54:14.03

Qt始めるならとりあえずこのシリーズ読もう
https://blog.qt.io/jp/category/getting-started-with-qt/

**デフォルトの名無しさん** · 2019/04/12(金) 17:06:12.27

私の場合は、インストール～ "Hello World" については
https://qiita.com/yasumodev/items/399ec89b7205e3c0bab1
https://qiita.com/yasumodev/items/104446261114e9a7352c
を参考にしました。続きについては、御提示のリンク先を試してみますね

**デフォルトの名無しさん** · 2019/04/13(土) 12:09:38.16

ID:K5RuTlhq です

>>826
https://www3.sra.co.jp/qt/licence/index.html を見て『グラフ作成パッケージQt Charts入れておいた方が便利かも』と思い
いったんアンインストールしてみたのですが、

[Qt 5.12.2 のセットアップ] の画面で

Qt Charts
Qt Data Visualization
Qt purchasing
Qt Virtual Keyboard
Qt WebEngine
Qt Network Authrozation
Qt WebGL Streming Plugin

にチェックを入れたとしても LGPL が選べるようです
サードパーティーの追加パッケージで問題となりうる…？

**デフォルトの名無しさん** · 2019/04/13(土) 12:11:50.81

>>828
具体的に「どのような問題が顕在化」し「どのように困る」ことになるのでしょうか
クラスとメンバ関数のみの指摘でも構わないので、示していただけませんか？

また、その問題を回避する方法は何なのでしょうか？

**デフォルトの名無しさん** · 2019/04/13(土) 13:57:08.11

>>832
LGPLを選べたとしてもQt Chartsを使っていればGPLｖ3
GPLと非互換のライセンスのライブラリを使うなら問題になる
だがそもそも練習段階ならライセンスなど気にせずどんどん書け

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

昔は知らんが5.12.1ならQt ChartsはLGPLで許諾されるよ？

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

5.12.2だった

**デフォルトの名無しさん** · 2019/04/13(土) 23:19:58.42

はっきりとGPLv3と書かれてる
https://www.qt.io/download
Open Source->Additional features->Data visualization の？を参照

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

条項はこれから確認する

>>837
インストールの操作手順からしたら
不意打ちも良いとこだなあ

Qt Charts をチェックした状態で[次へ(N)]ボタンを押したときに
「修正を受けたGPLv3」以外のラジオボタンが無効になってないと
UIとしておかしくねえか

あと「100%GPLv3と一致で修正条項なし」なん？
そうだとしたら、なおさらおかしい

**デフォルトの名無しさん** · 2019/04/14(日) 00:07:28.45

そういえば

LICENSE

などと大文字ファイル名にしないと効力が発生しないとする「糞判例がある」と聞いたことがあるけど、日本の裁判所？
ググっただけでは見つからなかった
最高裁判例なら検索結果の判決文をPDFで読める訳だがなあ

そのようなケースを敷衍すると、帰結として、Qt chartsはLGPLとなりうる
GPLv3 については逐条解説もあるから、そっちの内容も確認してみてちょ（あくまで「解説」）

**デフォルトの名無しさん** · 2019/04/14(日) 00:54:57.43

純粋に「Qt のライセンス」の話なのでスレチ？

copyright notice の表示方法の適切性について、GPLv3って基本的には明確には記載してなくね

ただし今回のケースだと、「インストーラが LGPL によるライセンスを表示した状態」で先に進める以上
0. Definitions. の第8パラグラフ(1) 反対解釈により、「GPLv3は適用されない」と読む余地がある
実際、GPLv3 につき "displays an appropriate copyright notice" してないもの

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

書き込み制限受けたので続き。多分コレで終わり。

あのインストーラが表示している著作権表示は明確に LGPL だから適用条件満たしてないと解釈する余地がある、と
…わたしはただの学習者だから大騒ぎすることでもねえんだがねえ…

**デフォルトの名無しさん** · 2019/04/15(月) 21:39:53.28

int& a;
int &a;
どっちにすべきでしょうか

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

好きな方で書け

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

「すべき」というのは規格表での『shall』のことですか？
それとももっと別の意図がありますか？

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

int & a;
int * b;

**はちみつ餃子** ◆8X2XSCHEME · 2019/04/15(月) 23:26:36.86

std::add_lvalue_reference<int>::type a;

**デフォルトの名無しさん** · 2019/04/16(火) 07:00:13.97

そんなこと気にする前に参照の変数を未初期化で使おうとするなよ。
みたいなツッコミを入れたくなるけど、コンパイル時にエラーが出る
間違いは必ず見落としなく直せるから実際は大きな問題じゃないよね。

「ポインタ宣言の * を型名に寄せるか変数名に寄せるか」と同じで
一貫した書き方をするかぎり、どっちでも構わんでしょ。
個人的には「変数名に寄せる」派だけど。

**デフォルトの名無しさん** · 2019/04/16(火) 08:18:02.67

int& a, &b;
int &a, &b;
自分も後者の方がいい

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

>>847
> 未初期化で使

コレの解釈は揺れそうだが、たとえば

int *i;

とか、
int *i;
int j;
i = &j;

とかいうかんじのことかしらん

**デフォルトの名無しさん** · 2019/04/16(火) 11:22:25.45

>>848
+1
ほんそれ

**デフォルトの名無しさん** · 2019/04/16(火) 12:24:17.44

わからない事をここで質問しようとレスを書いてる最中に「わかった！」
ってなることが多々あるんだが、この謎の現象は何なんだ・・・

**デフォルトの名無しさん** · 2019/04/16(火) 12:28:15.56

自己解決パターン

質問するときに頭の中が整理される→解決
質問するために再現する必要最小限のコードを書く→問題の切り分けが出来る→解決

いろいろあるが

**はちみつ餃子** ◆8X2XSCHEME · 2019/04/16(火) 13:21:34.50

>>851
何が駄目なのかわかれば解決法は自明であることが多い。
逆に言えば、解決法がわからないときは問題が何であるかわかってなかったりするんだよ。
だから、きちんとした形に質問をまとめれたなら、それはもうほとんど解答でもあるんだ。

この手法を利用してバグを取り除くやり方としてラバーダックデバッギングというものが知られている。

**デフォルトの名無しさん** · 2019/04/16(火) 13:51:09.84

C++erならRust学べって風潮嫌い
なんで学習コストがある言語を２つも学ばないといけないのかと思うし

**847** · 2019/04/16(火) 17:31:42.92

>>849
あんまり大それた意見とではなくて
void func()
{
　int &a;
...
}
と宣言したら、参照先不明の &a を作ろうとしてるから
必ずコンパイルエラーになるじゃろ、程度の指摘。

…ただ、この投稿を書こうとして気がついたんだけど、
class samp {
　int &a;
...
};
てな具合に、クラスのメンバとしての宣言ならエラーにならないね。
ちゃんとコンストラクタで a に参照先を与えるなら許される。

要するに >>847 の前半部分は間違ってた、ということ。
正しい場合もあるけど、常に正しいわけじゃない。

**デフォルトの名無しさん** · 2019/04/16(火) 17:55:46.56

その場合でもコンストラクタで初期化してなかったらエラー出るんだから
説明自体は間違ってない

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

>>853
テディベアをおいておくというエピソードなら有名だね

**デフォルトの名無しさん** · 2019/04/16(火) 22:14:36.94

>>854
難しいことも違った方向から見るとわかりやすくなることもある。

**デフォルトの名無しさん** · 2019/04/19(金) 11:24:45.99

質問です。
cinの戻り値のistream&がなんでif(cin)みたいに真偽判定に使えるのかが発端です。
https://stackoverflow.com/questions/8117566/why-istream-object-can-be-used-as-a-bool-expression
こことか見たんですけど、
1.istreamはbasic_iosを継承してて、
2.basic_iosで型変換演算子explicit operator bool() const;が定義されてる
ってとこまでは理解しました

ここからが質問なんですけどこの型変換ってのは勝手に行われるもんなんですかね
if(something)って書いたらif(bool(something))っていつもやってるんでしょうか

**デフォルトの名無しさん** · 2019/04/19(金) 11:40:22.57

intで参照したらEOF

**デフォルトの名無しさん** · 2019/04/19(金) 12:05:08.07

型変換以前に0やnullポインタを評価するとfalse、0以外の値はtrueと評価されると決まっているからだろ。
あと暗黙の型変換はよく起こる。

**デフォルトの名無しさん** · 2019/04/19(金) 12:08:35.86

if 文の条件判定部は bool 型を要求してる前提で解釈,翻訳してるんじゃない

**はちみつ餃子** ◆8X2XSCHEME · 2019/04/19(金) 12:13:29.89

>>859
yes.
条件部はブールを要求し、もしブールでない場合は常に型変換する。

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

前橋和弥さんのC言語ポインタ完全制覇という本で、
PCの環境(CPUの種類など)によってデータのメモリ上の配置は異なる
(構造体のパディングをはじめ、ただの単体のintでさえバイトオーダーが異なる(ワークステーションではビッグエンディアン採用だったりする))
ので、メモリの内容をバイナリでディスク上のファイルに出力したデータは別環境で読み込んで使おうと思ってはいけない
というような事が書いてありましたが、この話はWindows以外の環境や古い環境を前提とした話なのでしょうか？
同書にWindowsではBMPファイルをfwriteでファイルへダンプしていていかにもWindowsらしいとも書いてあるので、
Windows環境ならゲームのセーブデータとしてクラスをまるごとfwriteでバイナリ出力したファイルを別PCでロードしても問題ないのでしょうか？
(Xeonとかワークステーションマザーとか関係なしに、IntelCPU&Windowsの環境ならばリトルエンディアンで統一されている？)
(Macではビッグエンディアンになるが、Windows環境のみ対応のゲームを作る上では無視してよい？)
という認識は間違っているでしょうか？
パディングの違いなどもWindowsやVisualStudioが自動で良きに計らってくれるのならありがたいのですが…

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

windows間だから「別環境」ではなく「同じ環境」
だからwindowsでも同じ
そのbmpデータをmacに持って行っても使えない

なので磁気コアをダンプして永続化したようなデータは、他の全ての環境で使えない
60年代くらいから知られている

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

>>865
Windows環境であれば、別PC(別ハード)でも同環境とみなして良いのですね

>>WindowsではBMPファイルをfwriteでファイルへダンプしていていかにもWindowsらしいとも書いてある
読み直したら、違ってましたm(_ _)m
可変長構造体の節で、
WindowsではBMPをfwriteなどで可変長構造体まるごとダンプしていて、
BMPのような他の環境にもっていく可能性が高いファイルを構造体まるごとダンプしているのがWindowsらしい
というような内容でした

Windows級の一流プログラマーでも構造体まるごと出力を使っているのであれば、
ゲームのセーブデータで構造体やクラスをまるごとバイナリ出力しても問題ないととらえてよいのかな？

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

>>866
bmpファイルには仕様があるので「Windowsのプログラマがどうたら」なんぞ関係無く仕様に従って読み書きすべし
（現実には仕様に従わない入出力をやらかすアプリ毎に対処することはあるが）

自分で定義した構造体でも外部に公開するなら仕様を決めそれに準ずるべし
公開しないならそれこそ構造体丸ごとダンプなり好きにすれば良い
実際にそういう実装は珍しいものじゃない
どうせ環境の変化で困るとしてもそれは自分だけだからね

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

>>864
今でもそうだよ
書いたコードがたまたま正常っぽく動くからと言って
仕様にない動作を期待するコードは糞

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

つまり、後で困りたくなかったら、フォーマット(読み書きするサイズと順番？)を決めて
構造体のメンバ変数ひとつひとつ読み書きしていかないとだめなのか
…めんどくさいなー

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

異なる環境で扱う可能性のあるファイルならフォーマットを決めるのは当然だが
メンバ毎にアクセスしなければならないかどうかは処理系によるだろう。
仕様さえ合えば構造体で読み書きしてもいいわけで。

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

構造体まるごと fread/fwrite した後に
環境に応じて必要な場所だけLE/BE の変換をかける
htons とか htonl とか使う

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

どういう読まれ方をするか分からない時はXML型式のテキストファイルにしてしまう

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

>>871
有能！
と思って調べたら、ホストトゥーネット(ホストのバイト順(リトルエンディアン)からネットワークのバイト順(ビッグエンディアン)への変換)ですか。
バイトオーダーはこれで問題なさそうですね。
でも、まだです！まだですよー回答者様！
次はCPUによってアライメントの行い方(パディングの量)が違う問題についてです！
fread/fwriteで構造体まるごとバイナリ読み書きする時のパディング値が別PCで異なる場合に良い対処法を教えて下さいませ！

ないなら諦めて
>>872さん
のオススメのXMLを勉強します！

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

自分では使ったことないけど、BoostのSerializationは？

**はちみつ餃子** ◆8X2XSCHEME · 2019/04/20(土) 16:21:19.89

パーサコンビネータはバイナリファイルに使ってもいいんだよ。
あとは protobuf とかのジェネレータ系のツールもありかな。

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

VC++用に使ってるマシンのCPUがivy bridgeのi5の3570なんだけど、
そのマシンでは8の倍数バイトを境界としてパディングが入ってるかんじなんだけど、
Core2Duo世代のCPUだとどうなんだろう？
4の倍数バイトを境界とする様な古いCPUがネットバースト世代以前とかの相当古い環境だとしたら、もう動作対象環境から外しても良い気がしてきた
そうだとしたら、クラスまるごとバイナリ読み書きでよいのかな

**デフォルトの名無しさん** · 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
入力の検証、パース以外でそんな場面ありますか？
それと、その場面は一般的なシステムでもよく採用されるのでしょうか？