C++相談室 part150
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part149
https://mevius.2ch.sc/test/read.cgi/tech/1581974381/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://mevius.2ch.sc/test/read.cgi/tech/1556142878/
■長いソースを貼るときはここへ。■
http://codepad.org/
https://ideone.com/
[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
テンプレここまで
それは、「C + + 双生児」、つまり、C++と双璧をなす言語の出現を予言したものだったのだよ。
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？
#include <stdafx.h>
後R。
言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。
---- テンプレ ここまで ----
https://ideone.com/Jso95a
江添さんが間違って「末尾再帰である」と断定した記述方法 f() を、
正しく末尾再帰で記述すると g() になります。
これを最適化して h() とするのには、関数 g() を特別に解析することなく機械的に変換するだけでいいのです
最適化に機械的に変換するだけでいい、というのが末尾再帰の本質です
したがって >>934 の制限は妥当でしょうね
「末尾再帰」という情報処理用語を定義しているJIS規格票もしくは
"tail recursion" という情報処理用語を定義しているISO規格票の
条項を出せるやついるの？
これだけ上から目線でマウント取っといて
あげくオレ用語だったら恥ずかしいぞ
その周辺に「末尾再帰」は書かれていないので情報処理用語の規格として
定義されたものはたぶんないんだろうと思う。
用語として定義されてはいないけど、
DSSSL の規格 (JISX4153) に「実装は、正しく末尾再帰を扱えなければならない」という文言として
現れているのは見つけた。
DSSSL がベースにしているのが R4RS (← Scheme の規格の第4版の通称) であることも書いてあるから
ここでいう末尾再帰は R4RS が言う末尾再帰だと考えていいと思う。
だけど R4RS だとどういう場合が末尾再帰なのかようわからんのよなぁ。
(形式的意味論で書いてあるところを読み解ける人にはわかるのかもしれない。)
R5RS 以降だとだいぶん分かりやすく書いてあるんだけど。
禿げてる。
∧___∧ / / / /
⊂（ ・∀・） ､,Jし // ﾊﾟﾝ
（几と ノ ） て.彡⌒ ミ
／/'|ヽソ 彡 Y⌒Y( ´；ω；｀)
／ノ / ｜ ＼ 彡 l r Ｙ i|
ヽ/､/ヽ/ ヽ/ Ｕ>>3|：_|j
ハゲが作った言語なんてc++しか思い浮かばない
__CheckForDebuggerJustMyCode
という関数が呼び出されていて結構な負荷になっています。
デバッグ時にこれをOFFにしたいのですが、どうやって消せばよろしいのでしょうか？
私は Visual Studio を導入していないので試してないけど公式な情報があるやが。
https://docs.microsoft.com/ja-jp/cpp/build/reference/jmc?view=vs-2019
見逃してたけろ(´・ω・`)
ありがとう
https://ezoeryou.github.io/cpp-intro/#nannot-a-number
> int main() {
> double NaN = std::numeric_limits<double>::quiet_NaN() ;
> // true
> bool b = NaN != 0.0 ;
> // false
> bool a = NaN == 0.0 ;
> bool c = NaN == NaN ;
> bool d = NaN != NaN ;
> bool e = NaN < 0.0 ;
>}
こちらで試してみると、bool c = NaN != NaN の値は true でした。
https://ideone.com/dzmyeq
＞整数であれば、'a == b'がfalseであるならば、'a != b'なのだと仮定してもよいが、こと浮動小数点数の場合、NaNの存在があるために必ずしもそうとは限らない。
残念ながら、a, b, のいずれかまたは両方が Nan であっても、a == b が false ならば a != b true であることを確かめました
江添さん、だいじょうぶですかね？
×bool c = NaN != NaN の値は true でした。
○bool d = NaN != NaN の値は true でした。
訂正箇所は他にはなく、「a == b が false ならば a != b true であることは、double a, b が NaN であってもいえる」
とくに2015年はアメリカ式日付表記で3/14/15なので100年に1回だったという、
■ Googleの円周率31兆4000億桁までの計算について、きちんと解説
https://www.blog.umentu.work/google-circle-3-14/
■ 多倍長計算の技法（3章）
http://www.kurims.kyoto-u.ac.jp/~ooura/pi04.pdf
Sprout はど〜なっちゃうの〜
インターフェースクラスを継承して実装クラスを作る場合、
class If() /* interface */
{
public:
If() {}
virtual ~If*( {}
virtual void func() {}
};
class Impl() : public If
{
public:
Impl() {}
~Impl() {}
void func() {}
};
のようにすると思いますが、Implクラスをさらに基底クラス(ImplBase)と2種類の派生クラス(ImplA, ImplB)に分けたい場合、
多重継承以外でやるには、どうするのが良いでしょうか？
まず If を ImplBase に継承させて、次に ImplBase を ImplA と ImplB に継承させる事になるでしょうか？
その場合、純粋仮想関数func()はどのように書くべきでしょうか？ ImplBase も virtual void func()としておいて
ImplA で実装するのでしょうか？
ImplBaseにどんな役割を持たせたいかによるんじゃない？
ImplAとImplBがそれぞれIfを継承するのでは何が不満なのかをハッキリしないと何を解決すればいいのかわからない
え、持病でもあったの？
NaNが「不定」を意味するなら、理論的には
> // false
> bool c = NaN == NaN ;
> bool d = NaN != NaN ;
が正しいんだろう
仕様は上のようになってて、実装依存ということはないか？
ってするのが普通みたいだけど
数学的におかしくね？
0/0->NaNなら「不定」と解釈してもおかしくないし、その場合、
NaN!=NaNは「ほとんどの場合に正しい」としか言えない
NaN != NaN -> !(NaN == NaN) はtrue
ほかの等値比較の意味論に合わせてるんだと
std::numeric_limits<T>::is_iec559 (IEEE 754) の場合は NaN!=NaN に定まる模様。
https://stackoverflow.com/questions/38798791/nan-comparison-rule-in-c-c
> I read the IEEE-754 rules on NaN, which states:
>> The comparisons EQ, GT, GE, LT, and LE, when either or both operands is NaN returns FALSE.
>> The comparison NE, when either or both operands is NaN returns TRUE.
C++の規定はこう。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/n4849.pdf [expr.eq]
（C++14でも同じ https://timsong-cpp.github.io/cppwp/n4140/expr.eq#5 ）
> If two operands compare equal, the result is true for the == operator
> and false for the != operator. If two operands compare unequal,
> the result is false for the == operator and true for the != operator.
> Otherwise, the result of each of the operators is unspecified.
これだけなら「equalでもunequalでもない」として結果を不定とする実装もあり得る。
ただしCの規定には以下のものがある。
http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf Equality operators
> The == (equal to) and != (not equal to) operators are ...
> For any pair of operands, exactly one of the relations is true.
これによれば NaN==NaN, NaN!=NaN を両方 false とするCの実装は許されない。
わざわざこれに反するようなC++の実装が作られる理由は無さそうだし、受け入れられることも無さそう。
原理主義的にはNaNの比較は例外を投げるべき
https://cpprefjp.github.io/reference/compare/strong_order.html
たぶんx==xが常に真になるとは限らない(xがNaNの場合)って話を間違えて覚えてたんだろ
私は江添氏の本を買って読んでおり、個人的に非常に参考になる、どちらかといえば良書の部類だと考えておりますので
「被害者を減らす」という発想はありえないのです
総合的な判断がどうあれそこが間違ってるなら間違ってるだろ。
誤りの指摘はそこでやれ、それが「被害者を減らす」ことにつながる
江添が見ている保証のないこんなところで正義面しても
そういう筋が何もわかっちゃいないやつというだけだ
私個人では誤りを指摘するのには非力でしょう、したがってここで相談してから正式な申し入れをする手順を踏みたいと思います、それが読者のため、江添氏のためでもあります
査読を継続します
in
1,2,3,4
3,4,5,6
out
1,2,3,4,5,6
重複がなければそのまま結合でいいです
std::unique
std::set_union
その程度なら、ネットで検索して見つからないようなら、手で書いたほうが早いね。
2つの列を共にソートしたあと、マージソートの様に左端から順に比較して同じなら
1つ分だけ dest にコピーするようにすれば良いだけ。
1. 毎回デフォルトコンストラクタに引数を食わせて初期化してからgetterで計算する
2. 初期化はループの外でして置いてループ内ではsetterなどで引数を読み込ませてからgetterで計算する
どちらの方が良いんですかね？
あと、あるメンバ変数に連動したメンバ変数みたいなものって作れますか？
int _a
int _b = _a / 2みたいなものです
前半は関数オブジェクトのこと？何言ってんのかわからん
1,2は、速度面以外ではどちらでもいいが、速度を重視するなら2。
なお、getter, setter は元々、巨大なプログラムでバグを減らすために発明されたようなものだから、小さいプログラムでは特に使う必要は無い。
C#では、getter, setter を凄く高頻度で使ってもいいような設計思想なのかもしれないが、かなり意見が分かれるところ。
クラスを保護する目的では使っても良いが、普通の代入とは動作を変えてしまいすぎる
ようなものは想定した動作との勘違いによる逆にバグの元になる可能性があるのでお勧めしない。
使い道があるのは、代入箇所や読み取り箇所の動作の変更を手作業や grep 置換に頼らずに確実に行いたいような場合だと思うが、小規模なプログラムでは単純に手作業や grep 置換で直した方がよい。
新しい機能は大宣伝されるので初心者が飛び付きがちだが、実は余り普段は使わないほうが良い機能であることもかなり多いので注意。
教条主義なら1番
毎ループの中でオブジェクトはそれぞれ異なる
今回の関数Aと前回の関数Aは別物である、という思想になる
逐一newするとそれっぽくなる
そういう問題を自分が求めるパフォーマンスレベルに最適化できる（やらなきゃならん）のがc++だぞ。
デフォルトコンストラクタは引数をとらないコンストラクタのことなのでなんか勘違いしてるぞ。
実行コストか抽象化の都合でどうしても事前にしなければならないことがあるなら 2 の選択肢しかないし、
そうでないときはクラスにする意味がないので普通の関数で書けばよくねって思う。
そのふたつの選択肢の間で迷わなければならない場面というのが既になんかおかしい状態に入り込んでる気がする。
速度こそ正義だ
C#は実行時最適化に期待できるのと、ABI互換するのが作法なんで
C++で真似する意味はあんまりないよね。
セオリーに従順といえば聞こえはいいが、自分のおかれてる状況でどうすべきかの決断をとことんサボろうとしてるとも言える
「C#はABI互換するのが作法」
という意味が分からないので詳しく。
個人的には、C#でgetter,setterが作り易くなっているのは、HTMLの「property」
を操作するJSの流儀にルーツを持つのではないかと思っている。
そう思う理由の一つは、WinFormsでも、イベントハンドラ(関数)を登録するのに、インスタンス変数に関数の名前を代入するような形式を使っているのが、JSのイベントハンドらの作法にそっくりだし、
Formのフラグ類の設定方法が、HTMLのpropertyやCSSのstyleの設定方法とそっくりだから。
普通、C++だとメンバ関数を通じてオブジェクトに「命令を出す」事でオブジェクトの状態を変える
作法が取られることが多いが、JSだと同じ事をpropertyを設定することで行う。
後者の場合、propertyを設定したら、イベント終了後にDOM要素が自動的にその変化が反映される。
JSのその作法はコードを短く書くのには適してはいるが、インタプリタ的な動作でも有り、
変数の代入のように見える書き方に「副作用」が伴うのがC/C++言語の文化だとちょっと違和感を感じる
人も居ると思う。
なお個人的には、
C#のような自動化された setter, getter を使うより、
void SetXxx(TYPE x); や TYPE GetXxx();
を明示的に使ったほうが、set, get している場所をgrep検索し易いと思う。
xxx = yyy で settter を呼び出す作法の場合、grep検索するなら、
正規表現で xxx*s\= などと書く必要があるし、コンストラクタで
使われている場合や関数の引数に「代入」されている場合にはこれでは検索しきれない。
自動化されることで使用箇所が見えにくくなり、トラブルの元になる可能性がある。
getterの方は使用箇所の検索は不可能になる。
VSでポチポチしたら一瞬で完全な呼び出しツリーが出来上がる
プログラマは怠惰であるべきってのを間違ったとらえ方してるバカは世の中には多い。
メモ帳でコード書いてるのか？w
「例年より少ない」とされていたインフルエンザ関連死が急増＝国立感染症研究所
https://www.niid.go.jp/niid/ja/flu-m/2112-idsc/jinsoku/1852-flu-jinsoku-7.html …
コロナで死んだのインフルに振り替えてるんじゃまいか
こういうニュースが出てくる時点で隠蔽はもう無理
おそらくパンデミックは避けられないと思うね
メモ帳で楽に書ければ開発環境でも楽に書けるが、逆はない
開発環境がなければ書けないような構文は構文自体おかしいと認識するべきだ
そこはedlinだろ？
と思う。
Excelにはない。
不思議な話だ。
正直個人で利用するだけなら関数でいいし今までも関数で済ましてたんですが、他人に教えるときに変数定義などが散らばってると教えるのが面倒くさいという理由でクラス化したんですよね
プログラムが複雑な動作ができるのは「状態（＝変数）」を持つから
単純にできるならその方が良い
変数は悪だよ、必要悪
static変数よりかマシだけど状態を持つことには変わりはない。
まあlocal変数だけでプログラムするのもつらいって場面も多いけど。
c＋＋的に関数のbool型戻り値に関数の成功失敗返すとして、真が成功で偽が失敗が一般的？
c言語だと戻り値がintで0が成功、それ以外が失敗ってのか良くあるけど、c++もこの形が一般的？（偽が成功、真が失敗）
個人的には前者を良く使うんだけど
boolの場合言ってる通りでintの場合cの流儀に沿うのが普通じゃね。
エラーであることと同時にエラーの内容 (エラーコード) も返したいという要求がある。
なので 0 を成功として、失敗ならエラー内容に対応する数値 (真値) を返すというやり方が生まれた。
でも C の標準ライブラリには失敗として 0 を返した上でエラーの内容は errno に設定するものもあるし、
グダグダなんやわ。
真偽のどちらを成功とするか失敗とするかは、どちらかが一般的と言えるほど統一されてはいないと思う。
C++ だと失敗は例外で投げてしまえるから返却値はあくまでも正常系のみの結果を返すべきという意見もあるし、
例外は何かと問題があるので避けた方がいいという人もいる。
std::optional は「有効な値があるとき」と「有効な値がないとき」を区別できるけど、
成功・失敗に対応づけるにはちょっとイマイチな感じもあるしなぁ……。
結局のところ場合による。
結果boolとintでfalse/0の意味が入れ替わるわけだが
intはエラーコードを返す余地があるが
boolの場合失敗をfalseでだけで返しても実用上役に立たないと思う
falseが返ってきたら呼び出し側は何をすればいいかまで考えるべき
内部エラー的などうしようもないもののときは関数内で勝手にabortした方がまし
実は、エラー番号を返されても、出来ることは限られていて、
ハードウェアエラーの様なものなら、使用者にそのメッセージを
表示することは出来るが、単に関数の呼び出し方の間違いの場合も
多くてその場合は開発時にエラー番号を調べて対処するしかない。
エラー番号によってプログラムの動作を変えて対処できるケースは全体のごく一部。
それで十分役にたっとるがなw
実行時にあらゆるエラーをリカバリーしろという話ではないさ
boolは単純に真偽として解釈すべきでありかつその解釈で十分な場合に使う他無い
例： std::vector::empty()
どーしても成功か失敗かの意味で使いたいなら
成功なら真、失敗なら偽の値を返す関数なりマクロなりで
wrapした結果をboolにすべきや
例：
inline bool SUCCEEDED(int retval) { retun (retval == 0); }
inline bool FAILED(int retval) { return (retval != 0); }
100〜のスレッドの続きを読む