◎正当な理由による書き込みの削除について： 生島英之とみられる方へ:
C++相談室 part150 YouTube動画>12本 ->画像>1枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1584975873/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part149
http://2chb.net/r/tech/1581974381/ このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://2chb.net/r/tech/1556142878/ ■長いソースを貼るときはここへ。■
http://codepad.org/ https://ideone.com/ [C++ FAQ]
https://isocpp.org/wiki/faq/ http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
テンプレここまで
「ちんちんプラプラソーセージ」という言い伝えがあるがの、
それは、「C + + 双生児」、つまり、C++と双璧をなす言語の出現を予言したものだったのだよ。
STLつかうと一気に実行ファイルサイズが10倍に?！
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？
#include <stdafx.h>
後死ね。
言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。
---- テンプレ ここまで ----
http://2chb.net/r/tech/1581974381/937 https://ideone.com/Jso95a 江添さんが間違って「末尾再帰である」と断定した記述方法 f() を、
正しく末尾再帰で記述すると g() になります。
これを最適化して h() とするのには、関数 g() を特別に解析することなく機械的に変換するだけでいいのです
最適化に機械的に変換するだけでいい、というのが末尾再帰の本質です
したがって
>>934 の制限は妥当でしょうね
941 自分：デフォルトの名無しさん[sage] 投稿日：2020/03/21(土) 19:59:14.68 ID:uResqVEz [3/3]
「末尾再帰」という情報処理用語を定義しているJIS規格票もしくは
"tail recursion" という情報処理用語を定義しているISO規格票の
条項を出せるやついるの？
これだけ上から目線でマウント取っといて
あげくオレ用語だったら恥ずかしいぞ
JIS X 0007 に「再帰」に関連するいくつかの用語があるけど、
その周辺に「末尾再帰」は書かれていないので情報処理用語の規格として
定義されたものはたぶんないんだろうと思う。
用語として定義されてはいないけど、
DSSSL の規格 (JISX4153) に「実装は、正しく末尾再帰を扱えなければならない」という文言として
現れているのは見つけた。
DSSSL がベースにしているのが R4RS (← Scheme の規格の第4版の通称) であることも書いてあるから
ここでいう末尾再帰は R4RS が言う末尾再帰だと考えていいと思う。
だけど R4RS だとどういう場合が末尾再帰なのかようわからんのよなぁ。
(形式的意味論で書いてあるところを読み解ける人にはわかるのかもしれない。)
R5RS 以降だとだいぶん分かりやすく書いてあるんだけど。
8コアマシンでninja -j4 -l4すると固まるんだけどninja何してんの
忍者だが、電車に乗っていたら下痢したのでそおっと席を立ち駅に向かったらしい
ｳﾙｾｰ ﾊｹﾞﾊﾀﾞﾏｯﾃﾛ
∧___∧ / / / /
⊂（ ・∀・） ､,Jし // ﾊﾟﾝ
（几と ノ ） て.彡⌒ ミ
／/'|ヽソ 彡 Y⌒Y( ´；ω；｀)
／ノ / ｜ ＼ 彡 l r Ｙ i|
ヽ/､/ヽ/ ヽ/ Ｕ>>3|：_|j 髭だろ
ハゲが作った言語なんてc++しか思い浮かばない
Visual Studio C++ 2019 にて、パフォーマンスプロファイラーを使うと、
__CheckForDebuggerJustMyCode
という関数が呼び出されていて結構な負荷になっています。
デバッグ時にこれをOFFにしたいのですが、どうやって消せばよろしいのでしょうか？
>>21 見逃してたけろ(´・ω・`)
ありがとう
江添氏 C++ 入門にまた誤りを見つけました
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 であってもいえる」
3/14は円周率の日
とくに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
>>23-24 少しでも被害者を減らすために issue 立てといてもらえませんかね？
村上原野が死亡。
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 で実装するのでしょうか？
constexprの中二女子亡くなってたのか・・・
>>30 ImplBaseにどんな役割を持たせたいかによるんじゃない？
ImplAとImplBがそれぞれIfを継承するのでは何が不満なのかをハッキリしないと何を解決すればいいのかわからない
>>23 NaNが「不定」を意味するなら、理論的には
> // false
> bool c = NaN == NaN ;
> bool d = NaN != NaN ;
が正しいんだろう
仕様は上のようになってて、実装依存ということはないか？
NaNとの!=以外の比較演算は常にfalse、!=は常にtrue
ってするのが普通みたいだけど
そもそも非数に「等しい」なんて場合があるのか？
数学的におかしくね？
本来は「非数」なら「等しくない」も議論できない気がするのでなんとも
0/0->NaNなら「不定」と解釈してもおかしくないし、その場合、
NaN!=NaNは「ほとんどの場合に正しい」としか言えない
!=は==の否定だから、NaN == NaNはfalseなので
NaN != NaN -> !(NaN == NaN) はtrue
ほかの等値比較の意味論に合わせてるんだと
>>35 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++の実装が作られる理由は無さそうだし、受け入れられることも無さそう。
ieee754の書き方が難しすぎて何処をどう読めばNaN!=NaNになるのか分からん…
現実は
>>39なんだろうけど
原理主義的にはNaNの比較は例外を投げるべき
NaNを無限と言い換えて数学的な議論をするしかない
江添が悪い
たぶんx==xが常に真になるとは限らない(xがNaNの場合)って話を間違えて覚えてたんだろ
>>28 私は江添氏の本を買って読んでおり、個人的に非常に参考になる、どちらかといえば良書の部類だと考えておりますので
「被害者を減らす」という発想はありえないのです
>>47 総合的な判断がどうあれそこが間違ってるなら間違ってるだろ。
江添氏はブログを立てて不特定多数の一般人からの指摘を待っている
誤りの指摘はそこでやれ、それが「被害者を減らす」ことにつながる
江添が見ている保証のないこんなところで正義面しても
そういう筋が何もわかっちゃいないやつというだけだ
>>49 私個人では誤りを指摘するのには非力でしょう、したがってここで相談してから正式な申し入れをする手順を踏みたいと思います、それが読者のため、江添氏のためでもあります
査読を継続します
本当に間違っているという確信がなくて事前に相談するってのならまあそれもいいんじゃないの。
C++なんかやってるのにスノボもやってるのか異端だな
ベクトルが二つあって重複部分を差分取得になるように結合したいです
in
1,2,3,4
3,4,5,6
out
1,2,3,4,5,6
重複がなければそのまま結合でいいです
std::sort
std::unique
std::set_union
>>57 その程度なら、ネットで検索して見つからないようなら、手で書いたほうが早いね。
2つの列を共にソートしたあと、マージソートの様に左端から順に比較して同じなら
1つ分だけ dest にコピーするようにすれば良いだけ。
標準委員から無視されていじけてるんだろう。ショーもねー奴だよ。
new, deleteとか手動でやるのはもう古すぎて使わない？スマートポインタ使うのが普通？
必要な時は使えばいいと思うけど自分は全く使わなくなった
初めてクラスを使ったのですが、forループの中で関数のように使う場合には
1. 毎回デフォルトコンストラクタに引数を食わせて初期化してからgetterで計算する
2. 初期化はループの外でして置いてループ内ではsetterなどで引数を読み込ませてからgetterで計算する
どちらの方が良いんですかね？
あと、あるメンバ変数に連動したメンバ変数みたいなものって作れますか？
int _a
int _b = _a / 2みたいなものです
後半の方はint getHalfA()みたいなメンバ関数を設ければいい
前半は関数オブジェクトのこと？何言ってんのかわからん
>>63 1,2は、速度面以外ではどちらでもいいが、速度を重視するなら2。
なお、getter, setter は元々、巨大なプログラムでバグを減らすために発明されたようなものだから、小さいプログラムでは特に使う必要は無い。
>>65 C#では、getter, setter を凄く高頻度で使ってもいいような設計思想なのかもしれないが、かなり意見が分かれるところ。
クラスを保護する目的では使っても良いが、普通の代入とは動作を変えてしまいすぎる
ようなものは想定した動作との勘違いによる逆にバグの元になる可能性があるのでお勧めしない。
使い道があるのは、代入箇所や読み取り箇所の動作の変更を手作業や grep 置換に頼らずに確実に行いたいような場合だと思うが、小規模なプログラムでは単純に手作業や grep 置換で直した方がよい。
新しい機能は大宣伝されるので初心者が飛び付きがちだが、実は余り普段は使わないほうが良い機能であることもかなり多いので注意。
>>63 教条主義なら1番
毎ループの中でオブジェクトはそれぞれ異なる
今回の関数Aと前回の関数Aは別物である、という思想になる
逐一newするとそれっぽくなる
>>63 そういう問題を自分が求めるパフォーマンスレベルに最適化できる（やらなきゃならん）のがc++だぞ。
>>63 デフォルトコンストラクタは引数をとらないコンストラクタのことなのでなんか勘違いしてるぞ。
実行コストか抽象化の都合でどうしても事前にしなければならないことがあるなら 2 の選択肢しかないし、
そうでないときはクラスにする意味がないので普通の関数で書けばよくねって思う。
そのふたつの選択肢の間で迷わなければならない場面というのが既になんかおかしい状態に入り込んでる気がする。
>>66 C#は実行時最適化に期待できるのと、ABI互換するのが作法なんで
C++で真似する意味はあんまりないよね。
なんか前提条件抜きで「こう書くのが良い」みたいな答えを求める初心者が最近多いっぽいな
セオリーに従順といえば聞こえはいいが、自分のおかれてる状況でどうすべきかの決断をとことんサボろうとしてるとも言える
>>71 「C#はABI互換するのが作法」
という意味が分からないので詳しく。
個人的には、C#でgetter,setterが作り易くなっているのは、HTMLの「property」
を操作するJSの流儀にルーツを持つのではないかと思っている。
そう思う理由の一つは、WinFormsでも、イベントハンドラ(関数)を登録するのに、インスタンス変数に関数の名前を代入するような形式を使っているのが、JSのイベントハンドらの作法にそっくりだし、
Formのフラグ類の設定方法が、HTMLのpropertyやCSSのstyleの設定方法とそっくりだから。
普通、C++だとメンバ関数を通じてオブジェクトに「命令を出す」事でオブジェクトの状態を変える
作法が取られることが多いが、JSだと同じ事をpropertyを設定することで行う。
後者の場合、propertyを設定したら、イベント終了後にDOM要素が自動的にその変化が反映される。
JSのその作法はコードを短く書くのには適してはいるが、インタプリタ的な動作でも有り、
変数の代入のように見える書き方に「副作用」が伴うのがC/C++言語の文化だとちょっと違和感を感じる
人も居ると思う。
>>74 なお個人的には、
C#のような自動化された setter, getter を使うより、
void SetXxx(TYPE x); や TYPE GetXxx();
を明示的に使ったほうが、set, get している場所をgrep検索し易いと思う。
xxx = yyy で settter を呼び出す作法の場合、grep検索するなら、
正規表現で xxx*s\= などと書く必要があるし、コンストラクタで
使われている場合や関数の引数に「代入」されている場合にはこれでは検索しきれない。
自動化されることで使用箇所が見えにくくなり、トラブルの元になる可能性がある。
getterの方は使用箇所の検索は不可能になる。
C#はC++と違ってシンボルの完璧な静的解決が可能だからgrep性なんかどうでもいいんだよ
VSでポチポチしたら一瞬で完全な呼び出しツリーが出来上がる
>>73 プログラマは怠惰であるべきってのを間違ったとらえ方してるバカは世の中には多い。
【速報】東京都が #新型コロナウイルス 感染症死亡者数を過少評価か、
「例年より少ない」とされていたインフルエンザ関連死が急増＝国立感染症研究所
https://www.niid.go.jp/niid/ja/flu-m/2112-idsc/jinsoku/1852-flu-jinsoku-7.html …
コロナで死んだのインフルに振り替えてるんじゃまいか
こういうニュースが出てくる時点で隠蔽はもう無理
おそらくパンデミックは避けられないと思うね
言語仕様はメモ帳で書く場合を想定すべき
メモ帳で楽に書ければ開発環境でも楽に書けるが、逆はない
開発環境がなければ書けないような構文は構文自体おかしいと認識するべきだ
ExcelはExtended cellという意味とExcellentという意味がある。
と思う。
電卓にはプログラマ・モードがあるのに。
Excelにはない。
不思議な話だ。
皆さんありがとうございます
正直個人で利用するだけなら関数でいいし今までも関数で済ましてたんですが、他人に教えるときに変数定義などが散らばってると教えるのが面倒くさいという理由でクラス化したんですよね
関数で済むならその方が良い
プログラムが複雑な動作ができるのは「状態（＝変数）」を持つから
単純にできるならその方が良い
変数は悪だよ、必要悪
class変数ってのはstatic変数とlocal変数の中間的なイメージをもってる。
static変数よりかマシだけど状態を持つことには変わりはない。
まあlocal変数だけでプログラムするのもつらいって場面も多いけど。
気になったので教えて
c＋＋的に関数のbool型戻り値に関数の成功失敗返すとして、真が成功で偽が失敗が一般的？
c言語だと戻り値がintで0が成功、それ以外が失敗ってのか良くあるけど、c++もこの形が一般的？（偽が成功、真が失敗）
個人的には前者を良く使うんだけど
boolとintで区別するってのが一般的で
boolの場合言ってる通りでintの場合cの流儀に沿うのが普通じゃね。
>>91 エラーであることと同時にエラーの内容 (エラーコード) も返したいという要求がある。
なので 0 を成功として、失敗ならエラー内容に対応する数値 (真値) を返すというやり方が生まれた。
でも C の標準ライブラリには失敗として 0 を返した上でエラーの内容は errno に設定するものもあるし、
グダグダなんやわ。
真偽のどちらを成功とするか失敗とするかは、どちらかが一般的と言えるほど統一されてはいないと思う。
C++ だと失敗は例外で投げてしまえるから返却値はあくまでも正常系のみの結果を返すべきという意見もあるし、
例外は何かと問題があるので避けた方がいいという人もいる。
std::optional は「有効な値があるとき」と「有効な値がないとき」を区別できるけど、
成功・失敗に対応づけるにはちょっとイマイチな感じもあるしなぁ……。
結局のところ場合による。
おれも
>>92 の認識
結果boolとintでfalse/0の意味が入れ替わるわけだが
intはエラーコードを返す余地があるが
boolの場合失敗をfalseでだけで返しても実用上役に立たないと思う
falseが返ってきたら呼び出し側は何をすればいいかまで考えるべき
内部エラー的などうしようもないもののときは関数内で勝手にabortした方がまし
>>94 実は、エラー番号を返されても、出来ることは限られていて、
ハードウェアエラーの様なものなら、使用者にそのメッセージを
表示することは出来るが、単に関数の呼び出し方の間違いの場合も
多くてその場合は開発時にエラー番号を調べて対処するしかない。
エラー番号によってプログラムの動作を変えて対処できるケースは全体のごく一部。
>>95 それで十分役にたっとるがなw
実行時にあらゆるエラーをリカバリーしろという話ではないさ
std::sortにconstexprが付くことについてコメントお願いします。
左様boolを成功か失敗かの意味で使うのが悪い
boolは単純に真偽として解釈すべきでありかつその解釈で十分な場合に使う他無い
例： std::vector::empty()
どーしても成功か失敗かの意味で使いたいなら
成功なら真、失敗なら偽の値を返す関数なりマクロなりで
wrapした結果をboolにすべきや
例：
inline bool SUCCEEDED(int retval) { retun (retval == 0); }
inline bool FAILED(int retval) { return (retval != 0); }
constexprはやばいがなぜにソート？
というかコンパイル時ソートの需要なんかあんのか？
100万件のデータをソースに埋め込んでコンパイル時にソートしたいとは思わないな
そんなでかいのコンパイルに時間がかかって仕方がない
数十数百までなら実用的なコンパイル時間で済みそうだし需要はあるだろ
意味わからんけど
コンパイル時にソートしてくれるのはいいと思うよ
でもそれがスゲー便利とはならないだろうなってこと
明らかにアンチパターンだろ。
constexprてフーリエ変換の係数とか定数だけどちょっとした計算が必要なものに使うもんだろうに。
>>106 プログラマに対してアンチパターンだろっていうのと標準ライブラリがどうあるべきかってのは違うでしょ。
標準ライブラリがやってくれる分にはプログラマにとっては何も損なことはないじゃん。
>>108 不自然なことやってバギーだったり、その挙動がユーザーにとってデバッグしずらいものだったら
プログラマーにとって損だろ。
なんでもコンパイラにやらせればいいと思ってる輩はそのことを全く理解してない。
ソートが必要になる程のデータ数をコンパイル時に用意するならコンパイル時ファイル読み込みも必要じゃない
>>109 > 不自然なことやって
不自然かどうかは単なるお前の主観
> バギーだったり、
処理系の問題
> その挙動がユーザーにとってデバッグしずらいものだったら
無理矢理の仮定
> プログラマーにとって損だろ。
お前にとって損なだけ
コンパイル時できることはコンパイル時にやるのはC/C++の思想としては当たり前
嫌なら使わなきゃいいだけ
あんまり同意できないね
仕事で使う上だと嫌なら使うなというのは困る
多人数で作るうえでは使わないなら使われない仕組みが必要だからね
あとユーザが気軽にO(n^2)、O(n^3)みたない激重アルゴリズムをコンパイルフェーズに
組み込めるわけだけど、それコンパイラの仕事か？と思う
大規規模開発だとコンパイル時間の伸びは問題になる
フェーズわけるべきだよね
実際ビルド時に事前計算するものは多々あるけど、個別にスクリプトとか組むことに別に不満ないし
c++のコンパイルで一発で完結する必要性を感じない
嫌なら使うなって、C/C++のことだろ
つまり転職したほうがいいと暗に言っている
うん、まぁ、自分ならメタプログラミングとか特殊化で
定数のソートがあったら助かるかも・・助からないかも・・程度だけど
標準のやることに疑問を呈すと必ず
>>111みたいな変なのが湧くよね
まぁ、コンパイル時のソートしてもしなくてもコンパイル時のオーバーヘッドは微々たるもんじゃね？
大量のインスタンス化とかが起きなければ。
あ、あと
＞コンパイル時できることはコンパイル時にやるのはC/C++の思想としては当たり前
20年使ってるがそんな思想聞いたこともない
あとコンパイル時に出来る(上に、後で困ったりしない)場面って少ないよ
実際のソフト開発に使ったことないと気付かないんだろうけど
いや、constexprのお陰もあってコンパイル時に解決できることは思いの外増えている
constexpr つっても定数式の文脈以外ではコンパイルのフェイズで計算する保証はないよ。
コンパイラの裁量でほどほどにしてくれるからコンパイルのコストが極端に増大することは心配しなくていい。
(たぶんオプションとかで制御できるようになってる。)
constexpr の制約の範囲内に変形するのが難しいようなものまで無理して constexpr 化する必要はないけど、
付けれるもんなら付けとくくらいのスタンスでよいんじゃないかなぁ。
保証も何も、実行時にしか分からん値をどうやってコンパイル時に計算するんだ
はちみつ自身よく分かってないだろ
＞(たぶんオプションとかで制御できるようになってる。)
初耳だな
gcc のオプションをざっと検索してみたけど、
定数式の文脈とそうでないときを区別して指定するようなものは見つからんかった……。
>>119 入力がコンパイル時にわかる値 (定数式) でもその関数の呼び出し自身が定数式の文脈にない場合のことを言ってる。
>>122 「定数式の文脈以外では」保証もクソも原理的に不可能だと言ってんの
あー調べたら意味わかったわ、結果を格納する左辺が非constexprなら定数式としては呼ばれないと決まってるんだな
それを定数式の文脈と呼ぶのはおかしいと思うが
>>127 cpprefjp でそういう用語を使ってるから私もそれに倣ったんだけども、
cppreference の方では「定数式を要求する文脈」という言い方をしてるなぁ。
こっちの方がわかりやすいと思うので今後はこっちを使うようにするよ。
標準化以前からTMP大ウケだったC++に何求めてるんだよ
使い道を想像できない人のほうが多いことにとても驚いてます。
Javaは心が洗われるような美しい言語だったのに、豆とか言い出したあたりから汚れてしまった。
もはや何も感じない。
https://html.spec.whatwg.org/multipage/parsing.html#parsing-main-inhtml 今ここやってんの。
色々検索してたら、std::sortにconstexprが付くというのを見つけて。
なんだこれ！
なんだこれ！
なんだこれ！
となった。
でもまだついてないから使えない。
翻訳時に解決できることを、実行環境に持ち越さないために
コンパイラ方式であることが20年かかってもわからんやつが
constexprという止めまで刺されてまだ暴れてるな
20年前のitaniumみたいな失敗を繰り返そうとしてるバカ。
>>136 うん、だから実例よろしく
所詮、TMPでやってたことを実行時コンパイル時普通の関数の形で書けるなら便利ってだけの話だよね
constexprの利点がそれ以上であるというなら実例出せ
発想を逆にしてみたらどうだろ。
100万件のデータをソートしたらコンパイル時間が増えるみたいな方向性じゃなくて。
100万件のデータにマッチさせる側の数十件の情報をコンパイル時にソートするとしたら？
ぐもももも！ってなる。
ちなみに100万件の文字列をソートするのは数百ミリ秒。
そんなに怖がるほどでもない。
>>140 コンパイラ方式という壮大な実例を出しているんだが
20年かかってもわからんやつには無理のようだな
>>141 普通そういうのはファイルから読むだろうしなぁ・・
(そういう意味では
>>110に同意するけど
21世紀最大の発明と言われる右辺値参照についてもコメントお願いします。
ノーベル賞はいつ決まるんでしょうか。
まあPL/1は35年前からプリプロセッサでサブルーチンも定義できてたから今更コンパイル時にソートできてもたいした驚きはないわ
西洋人の決定論が反映されている
「未来は決まって無い」という考え方はダイナミックであり動的と呼ばれる
「未来は全て決まっている」というのが彼らの古典的な思考方法
未来において起こることの全ては、あらかじめ既に決まっている
というか、神が決めた
そういう宗教的思想あるいは神学が反映されている
>>147 ドラゴンブックを一通り実装したかどうかで変わるだけでは。
>>150 不要にはならない。
より効果的に使えるようになる。
>>147 自分が書いたコードの中までコペンハーゲン解釈なんだろ
量子コンピュータでもないTTL～CMOSの回路で
>>153 ET (Expression Template)
>>152 デジタル回路は決定論的かもしれんがI/Oを通して外界と繋がっている件
デマングルのことで質問があります。Ubuntu上でwebkitgtkというライブラリを見てるんですが、ライブラリ内に
以下のような2つのシンボル
_ZN3WTF6StringC1EPKDsj
_ZN3WTF6StringC2EPKDsj
があるんですが、これらはデマングル後
WTF::String::String(char16_t const*, unsigned int)
WTF::String::String(char16_t const*, unsigned int)
となって区別がつかない（少なくとも自分には）んですが、これはどういうことでしょう。C1とC2という部分の違いは...
ちなみに元のコード上では同じ型のコンストラクタがダブってたりはしていません（と思います）。し、ダブってたら
コンパイル時にエラーになりますよね?
リンカー的にはデマングル前のシンボルで扱うんでしょうから両者とも必要なんでしょうねやはり
unique_ptrについて質問です。
std::unique_ptr<T> uptr(new T);
に対して、uptr.get() と *reinterpret_cast<T**>(&uptr) は常に一致するでしょうか。
用途としては生ポインタの配列を受けとる関数にstd::vector<std::unique_ptr<T>>を渡したいです。
例：
void display_ptr(size_t n, int** pp){
for(size_t i=0; i<n; ++i){
std::cout << pp[i] << '\n';
}
}
int main(){
std::vector<std::unique_ptr<int>> vec;
for(size_t i=0; i<3; ++i){
vec.emplace_back(new int);
}
display_ptr(vec.size(), reinterpret_cast<int**>(&vec[0]));
return 0;
}
UChar * と char16_t * の方だから 84-86 行目の方だったスマソ
>>160 おっとすみません、単なるその説明の訳かもしれませんが、
内部的には (1)基底クラスを直接使う時のコンストラクタ (2)基底クラスから継承したクラスを
使う時に基底クラスを初期化するコンストラクタ と二つある、
けどデマングルした名前では両者の区別はつかなくなる（だけ）、みたいな感じでいいんですかね?
>>159 >>161 うーんと意味がよくわからないです。あと、特定のコードには寄らない話っぽいですね。
２次元のレイキャスティングを作成しようとしてます。
https://github.com/OneLoneCoder/olcPixelGameEngine/blob/master/Videos/OneLoneCoder_PGE_ShadowCasting2D.cpp にあるコードを現在javaで書いており、
@YouTube のように縦に長く１本線が出来てほしいのですが、
縦やにブロックを並べた時に、なぜか１ブロックごとに線が出来てしまいます。
どうすれば動画みたいに、縦に長い１本線が出来ますでしょうか？
コードは
https://ideone.com/spxzNE に載せてみました。
無駄に長い一本糞を作りたいのなら修行を積んでください
質問ですが抽象メソッドを有するクラスのデストラクタは
なんで勝手に仮想デストラクタにならないんでしょうか…
なんか有用なイディオムでもあるんでしょうか……………
C#しばらくやった後だったのでC#のつもりでインターフェースを定義して
virtual ~ＩFoo() { }
を書き忘れた結果盛大にリークすたgrz
>>168 ゼロオーバーヘッドの原則は C++ 的にはかなり強い要請なので……。
オブジェクトに常にポインタを保持しなければならないことと、
呼び出すときに仮想関数テーブルをたどるコストがあるってのは看過できなかったんだろう。
ん～そもそも抽象と仮想はもともとの発想が違うから似て非なるもの
さらにC#においてclassとinterfaceは似て非なるもの
C++に厳密な意味でinterfaceを実現する機能はない
そのへんはよしなによしなに
ていうか~IFOOの書き忘れがリークの元凶て発想があかん
解放し忘れしたらあかん物はsafe～とかのクラスに押し込むべき
でも仮想関数を持つクラスのデストラクタをわざわざ非仮想にするメリットってなんかあるの？実際の所
shared_ptrで管理するなら仮想デストラクタである必要がない
無駄に遅くなる
>>171 インターフェースという位置づけなら仮想・非仮想どちらにしろデストラクタが直に呼ばれるべきじゃないんじゃないかと思うわ
ただのインターフェースだからむしろ非仮想＆protectedで隠すのがいいんじゃないかと（しらんけど）
↓こんなイメージで直にデストラクタ触れるのはclass A以降
struct IFOO
{
protected:~IFOO();
};
class A:IFOO
{
public: virtual ~A();
};
class B:A{};
class C:A{};
それって要するに解放する時に、IFOOじゃなくてAだとかBだとかの
インスタンスの正体を全て把握しとけってことでしょ？
だったらそもそもIFOOって必要なの？って思う
>>171 俺の狭い知見ではまず無いと思うよ
ただvirtual付けてないのに勝手に仮想になると言うのもいかがなものかと思う
途中で書き込んでしまった
なので、やるとしても警告を出すぐらいだな
って思ってたらVisual Studio 2017だと既に警告出るわ（「警告をすべて有効にする」にしないとダメだけど）
warning C4265: 'C': クラスは仮想関数を含んでいますが、デストラクタはこのクラスの仮想インスタンスではなく、正しく消滅されない可能性があります
>>174 まあ不要かもしらんけどねぇ
でもC#でも仮想デストラクタを入れてるインターフェースてなくね？
リソース開放を請け負うIDisposableにしても派生クラスのデストラクタから呼び出す形
呼び出さなきゃ勝手に呼ばれるわけでもない
むしろ仮想デストラクタは便利だから使う程度の利点しかなくてインターフェースとしては不要なんじゃないかと言う気がする
夢の話じゃなくてリソース解放戦略が全然違うんだから比べても仕方ないだろ
というかそもそもC#は全部のメソッドがC++で言うところのvirtualなんだから比べようもない
学術の巨大掲示板群 - アルファ・ラボ
http://x0000.net 数学 物理学 化学 生物学 天文学 地理地学
IT 電子 工学 言語学 国語 方言 など
PS スカイプ友達の掲示板
http://skype.x0000.net class IFoo {
virtual int sum(int a, int b) const = 0;
};
これの書き方でリーク原因だったという話、
public: を忘れたgrz、
で、
class IFoo {
public:
virtual ~IFoo() { }
virtual int sum(int a, int b) const = 0;
};
としたら治まった、
>>172 std::shared_ptr<(IFooの派生クラス)> pObj(new (IFooの派生クラス)()) ならそもそもsumの方こそ仮想関数でなくても良い
std::shared_ptr<IFoo> pObj(new (IFooの派生クラス()) ならデストラクタが仮想でないとﾏｽﾞｰ
仮想関数有りかつ非仮想デストラクタ、を許すC++のこの仕様の理由をゼロオーバーヘッドの原則で説明くのであれば
仮想関数有りかつ非仮想デストラクタ、を許すことで得られる性能上のメリットが指摘されねばならない
てかそれshared_ptrの作り方が悪いだけじゃん
普通make_sharedで作る。
weakを使う場合でオブジェクト自身が巨大なためメモリは即座に解放したいときでも一度newした型のshared_ptr作れと
大体純粋仮想しか持たないクラスって要はinterfaceでしょ
そのポインタで派生オブジェクトのインスタンスのリソース管理するってのとは全く別の概念じゃないか
>>186 あー何となくわかったわ
shared_ptrの使い方分かってないのね
一度派生型のshared_ptrで作ったら、それをbaseのshared_ptrに代入して保持していても、デストラクタは元の型で呼ばれるよ
ってかそういう風に使うもの
newと入れるshared_ptrの型を変えるのはダメな使い方
って思ったけどよく考えたらいきなりbaseのshared_ptrに入れても大丈夫だったはず
（はてさて…よくわかっていないのはどちらなのやろうか…
>>193 いや、上でも下でも不味くない
きちんと派生クラスのデストラクタが呼ばれるよ
>一度派生型のshared_ptrで作ったら、それをbaseのshared_ptrに代入して保持していても、デストラクタは元の型で呼ばれるよ
えっそうなん？って試してみたらマジだった。
https://ideone.com/ZRde8G https://cpprefjp.github.io/reference/memory/shared_ptr.html > 通常、void*に型変換して代入されたポインタは、delete演算子を呼んだとしても元の型のデストラクタは呼び出されない。しかしshared_ptrの場合は、代入されたポインタの型が持つデストラクタが正しく実行されることが保証される。
知らんかった。
万能じゃないけどな
作る時に本来の型を教えないといけない
shared_ptr<Base> s(new Derived()) // OK
Base* b = new Derived();
shared_ptr<Base> s(b); // NG
> 作る時に本来の型を教えないといけない
なるほど。
https://ideone.com/BUt4xc 教えてくれてありがとうな。勉強になる。
横レスですみませんがそもそもポインタなんてCの配列かscanfくらいでしか使ったことないんですがスマポとかってどんな事(時)に使うんですか？
スマートポインタどころか、new deleteさえ使わなくなったな。
結局、計算資源はそのスコープで管理するってのが主流になりつつある。
C++は昔からそうだったと思うが
まぁCだと関数が確保して呼び出し元でどうこうするのも多かったけど
std::make_shared<hoge>(); 知らんの？
>>207 mainでsort呼び出すところで、boolの後にret=みたいなのが無いせいで変に解釈されている
>>200 CreateWindowExのlParam経由でオブジェクトのポインタを渡して受けて側でunique_ptrに格納して管理したりしてるよ
>>204 スコープを飛び越えて永続的にデータを保持するために使うのが Heap なんだが。
>>211 だからあんまり使わんようにって感じなってるだろ。
使うとしてもスマポであるスコープ外れたら回収するように作るとか、
そういう方向をどの言語も推奨してる。
>>212 > そういう方向をどの言語も推奨してる。
具体的にどの言語のことを言ってるんだ？
python,go,rustあたり見てもスコープ抜けた時に後処理する機構をサポートしとる。
お前はスコープで管理するのが主流っていったわけだけど
gcのないc++ではスコープで管理できるものはスコープで管理するのは
大昔から当たり前ではないでしょうか
何がいいたいのやらわからん
C++はおじょーずでも日本語アレな奴多いよね
職場でちゃんとコミュニケーションとれてるか？ｗｗｗ
そんなん昔からじゃん
それこそcどころかアセンブラの頃から
コンピュータとコミュニケーション取る方が大事だから
>>216 スコープ抜けた時の後処理ってなんだ？
まさかと思うがGCの話じゃないよな？
プログラミングスタイルが変わってきてるんだよね。
アジャイルとOOPは相性が悪いのかもしれない。
sort(
vecVisibilityPolygonPoints.begin(),
vecVisibilityPolygonPoints.end(),
[&](const tuple<float, float, float> &t1, const tuple<float, float, float> &t2)
{
return get<0>(t1) < get<0>(t2);
});
はt1の最初に設定されたfloatとt2の最初に設定されたfloatを比較して昇順に並べているのでしょうか？
[&]の意味はよく分からなくて教えて頂けると幸いです。
そうですね。
&に何の意味があるのか僕にもわかりません。
>>223 >t1の最初に設定されたfloatとt2の最初に設定されたfloatを比較して昇順に並べているのでしょうか？
その通りです。get<0>(t)でタプルの最初の要素を取り出して大小比較してます。
ちなみにget<0>を使わずに直接 t1 < t2 と比較すればタプルの左の要素から順に辞書順でsortされます。リンク先の(3)参照。
https://ja.cppreference.com/w/cpp/utility/tuple/operator_cmp [&]はラムダ式の中で使われる外部の変数を参照で持ってくるものです。リンク先のラムダキャプチャを参照。
ただ上の例ではそもそも外部の変数を使っていないので[&]ではなく単に[]で問題ないです。
https://ja.cppreference.com/w/cpp/language/lambda >>217 当たり前はそうなんだが言語機能や標準ライブラリでそういうのを守りやすくしようぜって
流れは感じるけどね。
>>226 お前さんがそこで流れと言っているものは別に最近できた流れでもなく、昔からあったし随時拡充されてきているものだぞ。
僕も流れを感じますね。
このフォースを感じ取れないものもいるんですね。
少し驚きました。
get<0> とか get<1> とか観るとげんなりする
なんで動的にアクセスできないんだ
そりゃ0番目と1番目の型が違うかもしれないからだよ
>>230 タプルはそれぞれの要素の型が違う可能性があるから仕方がないし、
array とかなら get を使わない選択肢があるんだから問題なくね？
格納する値の型を知っているのに相称型でしかアクセスできないのは不便ではないかというご提案として、受け付けました。
進捗状況は、ご提案番号1として随時ご確認できます。
格納する値が実行時にしか確定しない以上、コンパイラが値の型にアクセスすることも出来ないんだよな。
std::variantのoperator==は荒業でアクセスしてるよね。
あらかじめインデックス渡した関数テンプレートを実体化して
boost::anyみたいなものを返すという力技でどうにか出来なくもないだろうけど
上の方で何でもコンパイル時にやるのが良い事みたいに思ってるアホがいたけど
この辺の問題全く分かってないんだろうなぁ
(tupleを否定してるわけじゃないので変な噛み付き方しないように
学術巨大掲示板群: アルファ・ラボ
http://x0000.net 物理学 化学 数学 生物学 天文学 地理地学
IT 電子 工学 国語 方言 言語学 など
int要素が1個だけならget<int>でアクセスできなかったっけ
出来る限りコンパイル時に解決したほうが良いと思います。
constexpr ifで実行時の条件分岐数を減らす。
これがいま話題の都会的プログラミング。
>>230 楽してコストを減らす工夫だよ
見た目がイヤなら横着しないで
ちゃんと意味がわかる名前を付けなさい
template < typename > union vector3 {
struct {
T x;
T y;
T z;
};
T[3];
T&operator[](int n);
const T& operator [](int n) const;
};
>>238 規模の小さな小さなプログラムでしか効果が無いようなことが都会的かあ
>>242 何も知らない田舎者が漠然と憧れてイメージする都会ってことだろう
都会が優れていると思っている人を見ると、馬鹿なのかな、と思ってしまう。
タプルの分解は構造化束縛でだいぶ楽になったけど使わない変数を読み棄てる機能も欲しい
int main(){
const std::tuple<std::string_view, int> person("nanashi", 35);
const auto [name, age] = person;
std::cout << "name:" << name << ", age:" << age << std::endl;
return 0;
}
タプルなんて小規模のちょこっとしたプロトタイプコードのときは
楽だなんておもうけど、きちっとした巨大なコードに仕立て上げていく経過で
結局ふつうにちゃんと構造体なりを定義してそれ返すようにしないと後々
混乱しかないのが見えて結局こんなのイラネーな、ってなる
都会つってもアーバンライフが理想だったりするんだよね
最先端とは言わなくても整った街並み統一された景観
中心部は新旧入り混じったごみ溜めみたいなもん
流行に飛びついてつまみ食いするだけのが最悪
タプルは雑多な多値を返したいときが本来の目的
メタプログラミングでも活躍するけど
使い方のわからない初心者が要らないというが、必要ないなら標準に入るわけがない。
>>225 ありがとうございます。
リンクと丁寧な説明、大変助かりました。
タプルはどっちかというと無名クラスそのものな印象
なので
>>249に1票を入れたい
さらに言うとC++ではラムダ式の引数にもポインタを渡せるし、
[&]で呼び出し元変数の書き換えもできるしで
ラムダ式との絡みでもタプルという機構はそこはかとなく重畳な印象
、
ゼロコストのための手段の品揃えが良いのはいかにもC++だが
JavascriptやPythonに似せる方向性の努力はC++的では無い
ｷﾓｽ
なんじゃそりゃC++はプログラミング言語界のPerlでも目指しとるんか、
というのは半分は冗談で、
スレッド安全のために関数からはオブジェクトのコピーを返したいのだが
オブジェクトのクラスをいちいち定義したくない、と言う場合には多少便利
時代はjavascriptとPythonだからねー
キミたちより意識高いし「デキる」人多いよ
ランタイム速度落とさずに高級なことできるならなんでもやるがc++だろ
>>261 最近多いんだよねー
JavaScriptやPythonとかちょっとかじった程度で
「俺プログラマーやってます」って顔する子
最初の入り口が動的型付け言語なんだよね最近の子って
そんなもんじゃ使いものにならねっての
いつの時代にもいるもんだよ
CでPascalっぽいコード書くような手合いは
でも、constexprの使い道もわからないようじゃC++の意味ないのでは。
豚に真珠。
CひいてはC++の需要が無駄に高まってきてるのは、一つは競技プログラミングのため、もう一つはpythonのためだ
>>267 ＞constexprの使い道もわからない
誰と戦ってるんだ
学術の巨大掲示板群 - アルファ・ラボ
http://x0000.net 数学 物理学 化学 生物学 天文学 地理地学
IT 電子 工学 言語学 国語 方言 など
RTTIをプログラムの一部で使用した場合
使用していない部分でもRTTIを有効にしたデメリット(実行速度など)の影響を受けますか？
RTTIって何だっけ要るときになったら確保とかいうやつだっけ
dynamic_castとtypeidを使う時に必要な機能
>>274 実行速度は実際に使うところにしか影響ないと思う。
バイナリサイズの面でのデメリットはRTTIを有効にしてコンパイルしてたら使わなくても発生すると思う。
C++の設計思想としては
Cで同じコードを書けば同じ速度、リソースで実行出来るのを目指している
で基本的には思想通りに仕上がってる
関数形式のキャストってあるじゃん
int(a)みたいの
これのlong long版ってあるの？
スペースを含んでいるのだが(笑)
>>282 実は、コンパイラからすれば、それは、旧来のC形式の
(型名)値
の形式のキャストとみなされている。
>>283
(TYPE)x // 原初的なCから存在していた旧来のキャスト形式
TYPE(x) // C++ で追加された関数形式のキャスト >>281 typedef long long long_long_type;
using alias_ll = long long;
てな感じに別名をつけたらどうだろ。
関数形式のキャストって、キャスト演算子をオーバーロードするとき
間接的にしかお世話になってない希ガス、
旧来のキャスト形式に対して他になんかメリットあんの？
コンストラクタによる変換と一貫してて見やすい（個人差があります
>>289 コンストラクタとの一貫性を持たせることでtemplateを書くときに何か都合がいいとどこかで読んだ気がするが、うろ覚えなので間違ってたらスマン
printfで標準出力に一行づつ出力するのが面倒なので、複数行をビアドキュメントで出力したいのですが、何か方法はありますか？
>>292 printf(
"hhhh"
"jjjj"
"kkkk"
"llll"
);
>>292 printf(
R"(hhhh
jjjj
kkkk
llll)");
>>293,294
どちらも出来ました！
ありがとうございます。
複数行ってそういう意味か？ω
出力は改行せんでええんか？ωωω
絶対に大丈夫なやり方は、こう :
printf(
"xxxx\n"
"xxxx\n"
);
https://ideone.com/rhcxbJ g++とclで結果が違う
ideoneではエラー
どれが正しい？
>>300-301 スコープ無し列挙定数は全ての列挙子の値を表せる整数型が基底になる。
ただし、全ての列挙子の値が int か unsigned int に収まるならば int より大きくなることはない。
この場合は int で表せないのでもっと大きい型にしたいけど最大の整数型である long でも
表せないのでお手上げって言ってる。
codepad は gcc 4.1.2 を使ってる。
つまりその時点での最新仕様は C++03 で、C++03 には long long なんていう型はない。
long 型が最大の整数。
(実際には処理系の拡張として __int64_t という名前で 64bit 整数も使えたりはするんだけど、
enum 関連で使用されるようにはなってないっぽい。)
>>303 レスthx
clはデフォC++14なのでlong longがあるはずなのに
何でtest2がlong止まりなのって話
std::cout << typeid(test2).name() << std::endl;
とやってみても
enum `int __cdecl main(void)'::`2'::<unnamed-enum-test2>
となるだけでlongかどうかは確認できない
さらに
void func(int) { std::cout << "int" << std::endl; }
void func(long) { std::cout << "long" << std::endl; }
これだと出力がintになる
>>304 > clはデフォC++14なので
cl っていうと Common Lisp を連想してまう……というのは余談として、
それは動作環境を用意できてないからこっちで実行できへんのや。
結果が違うってのはどうなるの？
実行結果も示してくれへん？
あと 64bit 版か 32bit 版かも明示してや。
> longかどうかは確認できない
列挙型はあくまでも個別の列挙型であって整数ではないので、
基底型が何かというのは std::underlying_type で調べる必要がある。
godbolt で確認しようとしたら
LINK : fatal error LNK1104: cannot open file 'libcpmt.lib'
と出るんやが……
>>305 Visual Studioと言えば通じる？
underlying_typeか、こいつは情報ごっつぁん
std::cout << typeid(typename std::underlying_type<decltype(test2)>::type).name() << std::endl;
これの出力もintだった
>>307 > Visual Studioと言えば通じる？
コマンドが cl というのは知ってはいるんだけど、コンパイラの名前として cl っていうのは伝わり難いと思う。
マイクロソフトのドキュメントでは Microsoft C++ か MSVC という書き方をしていることが多いようなので、
たぶんそれが公式な呼び方なんじゃないかな。
> これの出力もintだった
値は何になってる？
値はもうあんまり興味なかったが
一応試したらやっぱり0だった
>>310 よくこんなの見つけたな
指摘からもう１年経つのにまだ放置か
300で言ってたclは2019だよ
もち更新ちゃんとやってるやつ
>>315 最新のコメントに `_MSC_FULL_VER` が `192328105` の環境で再現すると書いてある。
これは Visual Studio 2019 version 16.3.2 のことだそうな。
https://cpprefjp.github.io/implementation.html#visual_cpp_ver あーすまん、ちゃんと見てなかった
2019でも起きるのに一年放置は長いな
型指定使えば済むやろ、で後回しにされてるのかも？
だいたい出尽くした？
餃子さん情報２つもありがとう
リアルならバーでおごるところだ
本当は、64bit型が追加されたことはコンパイラ作者泣かせなんだ。
C++コンパイラはとても複雑になってしまっている上に新しい仕様が入ったことで組み合わせ爆発が起きて細かなバグが入り易い。
型の「昇格」や、2項演算子における型の「統一」も、64bit型が入ったことで複雑さが増した。
普段当たり前すぎて気にしないことだが、
unsigned char ch = 1;
と書いた場合でも、右辺は最初 int 型整数と解釈されるが、型にうるさいC++においても、それよりバイト数の少ない ch に警告も無く代入できてしまう。
他にも、
ch += 2;
とした場合、2は、最初int型と解釈されるのに、それよりバイト数の小さい ch に何の警告も無く足せてしまう。
これらで警告が出たらコーディングの手間がかかり過ぎるためそうなっているとは分かるが、型安全なC++においては背後にどういう仕組みがあるのかと思ってしまう。
>>321 unsigned char ch = 1 + 2;
と書いたとする。
右辺は、C言語の使用によれば、1も2もint型だとみなされてから計算され、
結果の3もint型である。普通、int i; に対して、
ch = i;
とすると当然エラーか警告が出るのに、
この場合には何もメッセージが出ずにコンパイラが通るはずだ。
これも背後にどの仕様が働いているのだろうか？
char a = 0;
a += (char)0;
これも代入時にintから型変換
簡単な定数畳み込みして安全かどうか調べてるだけでしょ
gccの場合
char i = 255+1; # warningでる
char i = 1;
char j = 255+j; # warningでない
1+2*3
は警告が出ないのに
1<<2+3
は警告が出るとか
色々と恣意的
そりゃwarningだもの
コンパイラーごとに親切心でやってるだけじゃん
ch = 1;
がどうしてエラーにならないのか、CやC++の古い仕様仕様書からは見つけることが出来なかった。
>>327 すまん
char j = 255+i; # warningでない
だった
>>329 古い仕様っていつのやつ？
とりあえず JISX3010:2003 (C99 に相当) を見る限りでは規定はある。
関連しそうなところを抜粋したので細かいことは周辺を確認してね。
> 6.7.8 初期化
> 型の制限及び型変換は、単純代入と同じとする。
> 6.5.16.1 単純代入
> 右オペランドの値を代入式の型に型変換し、左オペランドで指し示される
> オブジェクトに格納されている値をこの値で置き換える。
> 6.3.1.3
> 整数型の値を _Bool 型以外の他の整数型に変換する場合、
> その値が新しい型で表現可能なとき、値は変化しない。
> 新しい型で表現できない場合、新しい型が符号無し整数型であれば、
> 新しい型で表現しうる最大の数に 1 加えた数を加えることまたは
> 減じることを、新しい型の範囲に入るまで繰り返すことによって得られる
> 値に変換する。
> そうでない場合、すなわち、新しい型が符号付き整数型であって、
> 値がその型で表現できない場合は、結果が処理系定義の値となるか、
> 又は処理系定義のシグナルを生成するかのいずれかとする。
そんなわけで、変換後が unsigned の場合はどんな値に変化するか既定があるし、
signed の場合は表現できる範囲内では値は変化しないから問題ない。
表現できない値になってるかどうかは基本的に実行時までわからんから
コンパイル時には黙って通す (わかるときは警告する) って感じ。
>>332 > 右オペランドの値を代入式の型に型変換し、左オペランドで指し示される
> オブジェクトに格納されている値をこの値で置き換える。
C++において、
char ch;
int i;
に対し、
ch = i;
はエラーになるけど、それは左辺と右辺で型が違っているから。
つまり、C++では、単純代入演算子 x = y において、「型変換」は自動的には行われない。
>>333 pure Cにおいても、
int x;
char *ptr;
x = ptr;
や
int *pInt;
char *ptr;
pInt = ptr;
は
どちらもエラーになる。
だから、pure C の代入演算子に置いても、型変換がエラーも出ずに自動的に行われるわけではない。
>>333,334
「エラーになる」って言ってるけど、警告の間違いじゃない？
CでもC++でも代入で暗黙の型変換は発生するよ。
>>333
なんでそんな自信満々なん？これコンパイル通るぞ
int main(){
char ch = 0;
int i = 1;
ch = i;
std::cout << +ch << std::endl;
return 0;
} エラーじゃなくてワーニングなんだろ多分
しっかりラーニングしておけよ
今月のインターフェースでC++は型なし言語と紹介されていた。
種なしって言われたみたいで悲しい…
型があることにも、ないことにもできるのがC/C++の良いところ
まあしかし世の中には反りの合わない人がいるもので
そういうところを酷評する意見も当然出てくる
c++が悪いんやない！cの型システムが壊れてるからや！
みたいな主張は聞いたことある。
まあしかし互換性がウリですからね。。
むしろ、型を壊したのは C++ の方だと思うが。
autoとかで。
>>335 C++では、
void *ptr;
CPerson *pPerson;
に対して、
pPerson = ptr;
はエラーになるはず。
だから、C++では
CPerson *pPerson = malloc(sizeof(CPerson));
がエラーになるのだから。
pure Cではならなかったが。
また、
CBase *pBase;
CDerived *pDerived;
に対して、
pDerived = pBase;
もエラーになるはずだ。
>>343 何か勘違いしているようだが、人気が有ったのはpure Cの方だからね。
今のC++の人気は、pure Cの人気を引き継いだだけ。
そしてC++が変な拡張を繰り返したからこそ、人気にかげりが見えてきている。
>>344 autoは型をきちんと理解して使うもので
アホが使うと謎の動きに翻弄されることになる
>>341 どう書いてあったか詳しく聞いてみたい。
>>345 何で別の話を始めたの？
ちゃんと質問には答えてくれないかな？
>>344 型検査の厳しさは型を陽に書くかどうかとは関係ない。
>>345 何をいいたいのかわからん。
>>354 何で
>>345で別の話を始めたの？
ちゃんと人の質問には答えようね
>>351 コンパイル時にすべての変数の型が確定しないc++は弱い型付けだから型無し言語に分類だって。
>>356 そこは動的型付けの説明だよ。
ちゃんと読んで
>>357 その雑誌には、
静的型付け言語であるところの C++ が「型無し言語」であると書いてあるの？
auto it = unique(
vecVisibilityPolygonPoints.begin(),
vecVisibilityPolygonPoints.end(),
[&](const tuple<float, float, float> &t1, const tuple<float, float, float> &t2)
{
return fabs(get<1>(t1) - get<1>(t2)) < 0.1f && fabs(get<2>(t1) - get<2>(t2)) < 0.1f;
});
vecVisibilityPolygonPoints.resize(distance(vecVisibilityPolygonPoints.begin(), it));
のresize()から意味がよくわからないのですが、
{0.1, 0.11, 0.2, 0.21, 0.4, 0.41}
↓
{0.1, 0.2, 0.4}
なことでしょうか？
>vecVisibilityPolygonPoints
std::vector<T>のハンガリアン記法での接頭辞vecで良いんだっけ…
Tの情報はどう埋め込めば良いんじゃ…
毎回悩むのでJISか何かで決めてﾎｽｲ
>erase使わずにresize使う人始めてみたわ
ﾊｱ?(ﾟДﾟ)ﾊｧ?
>>364 vecなんて付けずにvisibilityPolygonPoints でいいんじゃね。システムハンガリアンは不要または有害だと言われるようになって久しいだろう。
処理の都合上、別のコンテナからvectorに詰め替えたとかでvectorであることに強い意味がある状況なら、vecをつけて元の変数と区別する意味はあると思うけど。
auto使ってハンガリアンとかなんか間違ってるわな。
>>363 3要素のvectorでyzの値が近いものを同一と見なして削除する処理なのかね
unique前のsortどうしてんのか謎だけど
uniqueは重複したものは一つだけ残して前にuniqueなデータを集め、後半にゴミを集める
戻り値はゴミの開始iterator
resize部分はゴミを消す処理
一般的にはerase使ったerase-remove_ifイディオムの変形だな
使ったこと無いから知らんがstd::unique<T>()は
>削除は、消去される要素が上書きされるように、範囲内の要素をずらすことによって行われます。
とのことなので、callerがstd::unique<T>()を呼ぶ前にソートしておく必要があるのでは…
>>370 unique前にソートで昇順にしているみたいです。
結局メモリーポインタ関連わかってない奴はガベコレなんかで隠ぺいした言語使っててもバグる
vecVisibilityPolygonPoints が「1枚のポリゴンの各頂点の座標(頂点数は任意)」で
座標値は画面に表示すべき値に変換済み(透視投影が完了している)、
<float, float, float> が (x, y, z) を表すと仮定すると…
隣合う頂点のx座標同士、y座標同士がそれぞれ十分に近ければ
その「極端に短い一辺」を1つの頂点とみなして表示処理を軽減、って感じかな。
resize() の結果 size() が 1 か 2 になったらポリゴン全体が
「見えないポリゴン」になるので丸ごと省略、までやるかも。
tupple::get<> は 0 始まりだから y, z 座標だね(
>>370 さんの言う通り)。
すると少々怪しいか、素朴な仮定だとスッキリ辻褄が合わない。
>374
確かにGCあり言語でのリークなんかは逆にデバッグがかなり難しい。
理解してないやつはまず無理。
そういうのはシステムのバグで
自分の落ち度じゃねえだろ
システムのバグ以外にリークが起きないとでも思ってるの？
プログラムの開始から終わりまで存在するオブジェクトがリストを所有しており、
そのリストに要素数制限もエラーチェックも無く無制限に増える場合とか、
オブジェクトAとオブジェクトBが互いを参照し合っている場合（循環参照）とか
いろいろ
つかオブジェクトをいつ使い終わったかを機械的に判定する難しさを考えたらﾜｶﾙ
使わないのに参照しっぱなしで放置＝リークともとれるからね
GCはあるとちょっとは便利でしょって程度のものでヒープ管理の全体像はプログラマが把握しておくべきだと思うわ
頻繁なGCが必要なくらいにヒープ使うのであれば設計から考え直す必要あるんじゃないかと
リークじゃねえじゃん
参照元の寿命が尽きてないんなら
>>386 参照元の寿命が尽きていなくても使いもしないのであれば現象としてはリ～クに他ならない
違うというならメモリ消費量が際限なく増え続けるプログラムを客先に納めて
リ～クではないんですよと仕様ですよ説明して見せると良い
>>387 参照元が生きているのをリークとは言わない
その状態で意図しない動作になるのはリーク以外のバグってだけだ
おまえさん自身がそれを仕様ですよと説明できないと言っているように
リークの字義的には微妙
プロセス外部から見える挙動はリークと同様だけど
>>390 自分が間違って憶えているのを正当化するために定義を広くしようたって誰も協力せんぞ
いや普通に文脈で何を問題にしてるかわかるだろ。。
勝手に自分ルールで解釈狭めてリークはないとか言い出してる奴が頭おかしいわ。
明確な定義なんてないだろ
リークに見える挙動はリークだよ
リークの定義は複数あっていいと思いますが、「①自分の定義はこれで、だから②これはリークである／ない」の①②二点を明示するべきだと思いますね
>>393 何を問題にしているかと、それをリークと呼ぶか否かは別な話だぜ
それこそ「理解してないやつ」がテキトーこいてリークだリークだ言うのと同じだ
まあ何から漏れているか明確じゃないのまで、リークと呼び始めた人が悪いんだな
内部的な原因も対処法も全く違うのに、外見だけで同じ名前つけられても混乱するだろうに
リークによって起きる現象とリークは分けて考えた方がいい
本質的には未使用メモリーの蓄積だが名称がないから混乱が起きる
蓄積を処理しないのもバグ
リークは蓄積をコントロールできなくなっていて、結果的に処理していない点が違うがこれもバグ
少なくとも
>>384の巨大リストを抱えてる方はリークとは言わない
データ管理がなってないだけ
原因は？
メモリリークによりメモリが不足してました
これだけで終わる会話を
>>401は確かに違う
循環参照は普通検出すると思ってるけど
そうでもないシステムがある？
循環参照で問題になるのはカウント方式の場合
C++のスマポくらいでは？
int main(void)
{
void *p = malloc(1);
int x;
while(scanf("%d", x) != EOF) { //タイプミスで永久ループ
//...
}
free(p); //到達しなくなる
}
参照元pが生きているのはリークではない
使ってないメモリ領域が増え続けるのはメモリリーク
参照があろうがなかろうが
使ってないと言っても使うかもしれないから無限にリストが長くなっているんじゃね
純粋なインメモリデータベースだとそれはリークではないよね
問題が起きたのだとしたら、用途に対してメモリが少なかったのが悪いだけで
管理手段が残っているのはリークではない
無駄に多く割り付けたり解放のタイミングがまずいというだけ
>>410 それは GC の種類によるんじゃないでしょうか？
参照カウンタ方式のGC（私は、参照カウンタ方式はGCと呼ばない人ですが）ならGCがあってもリークするでしょうし、
GCの元祖マークアンドスウィープ式や、これも昔からあるコピーGCならば、リークはしないでしょうね
上のリンクのガベージコレクションの限界
に書いてある
無限に増えるキャッシュ
->使っているからリークじゃない
ログ的なデータを延々と追加するだけ->
リーク
終了時にファイル出力->リークじゃない
つまり、ファイル出力機能を後から追加することでリークじゃなくなるんだな
それでメモリ足りなくなったらなんて呼ぶんだろう
リークかどうかじゃなくて使ってるか使ってないかだな
プログラマー的には使ってないけどプログラム的には使ってるものをリークと呼ぶのが適切とは思えんけど
プログラマー的には使ってないけどプログラム的には使ってるものをリーク
プログラマー的には使ってるけどプログラム的には使ってないものをリーク
プログラマー的には使ってないけどプログラム的には使っないものをリーク
プログラマー的には使ってるけどプログラム的には使ってるものをリーク
どの立場で見るかでしょ
言語のランタイムシステムの立場では参照が残ってるんだったらリークではないといえる
人間の立場では無限にメモリ使ってるつもりがないのにメモリが枯渇するのでリークしてる
現実問題は人間の立場で見るのだから後者でよい
枯渇したらリークってのもおかしいぜ
必要容量のRAMを実装していないのがリークになっちまう
>>420 典型的にそうやってメモリリークに気づくからそう書いただけ
gc言語でもリークに気を付ける必要があるというのは
20年前ぐらい前から言われている
組み込みJavaが流行った時とか特にね
明示的に解放できないシステムでどうやって気をつけるんだよ
さっきからシステムのバグつってんだろ
そもそもGCが解放してくれないのはリークではないからだろうが
>>412 元祖マークアンドスィープ法やコピーGC ではリークしませんね、これは断言できるでしょう
>>414 リンクのwiki には、参照カウンタ方式のリークは書いてあっても、マークアンドスウィープ法やコピーGC についてはリークするとは書いていませんね
>>416 あなたはまず、あなたのリークの定義を正確に記述する必要がありますね、現状、あいまいなのでは？
>>395 >>419 ＞人間の立場では無限にメモリ使ってるつもりがないのにメモリが枯渇するのでリークしてる
それはメモリ不足であって、リーク（「漏れる」）ではないのでは？
>>425 なぜ、リンク先が参照カウンタ方式のことしか述べていないと思ったのですか。
参照カウントではないC#でも弱い参照が存在することは
>>415のリンクで説明したはずですが。
>>428 ＞参照カウントではないC#でも弱い参照が存在することは
①強い参照、弱い参照を使い分ける方式は、参照カウント法の一種だと認識しています
②元祖マークアンドスウィープ法、コピーGC法では原理的にリークは発生しませんし、発生し得ません
>>410 おまえさんWikipediaってどんな所だか知ってるか？
ちなみに俺もとあるページを執筆したことがあるが
俺はどこの馬の骨か聞かれもしなかったし
アホなミスをしでかしてもあんまり指摘されないし
悪意のある文面をやめさせるのにも手間取るぞ
査読できる人でないと鵜呑みは危険だぞ
一方、マーク・アンド・スイープ方式やコピーGC方式では循環参照によるメモリリークは
発生しないが、非意図的オブジェクト保持（unintentional object retention）が引き起こす
メモリリークを強参照のみによる実装で解消することは難しく煩雑であり、
実装を簡略化するために弱参照が用いられることがある。
https://ja.wikipedia.org/wiki/%E5%BC%B1%E3%81%84%E5%8F%82%E7%85%A7 >>431 >>429 ①強い参照、弱い参照を使い分ける方式は、参照カウント法の一種だと認識しています
使ってる言葉の意味が異なる人を説得するのは無理だと悟った
また面倒なのが出てきたな
wikipediaのリンクで終わったかと思ったのに
QZは頭が弱いから
>>426 407の定義だと曖昧すぎて気持ち悪くなるって例出しただけ
確保したメモリを使用しなくなったのに解放しないまま管理外にするのが狭義のメモリリーク
それ以外の現象もメモリリークと呼ぶのは知っているが、その呼び方は混乱招くから好きじゃないって立場
使わない、使うつもりもない、プログラマが意図しないメモリ
これらが増え続ければリーク
定義じゃなくて十分条件の例
>>422 > 明示的に解放できないシステムでどうやって気をつけるんだよ
gc言語で本格的な開発したことないって白状してるようなもんだね
メモリプロファイラで地道に調べるんだよ
あと不要になったらgc任せにせずに即null代入しておけとかよく言われるだろ
> さっきからシステムのバグつってんだろ
システムって何だよ？意味広すぎるから説明になってない
gc言語においては言語レベルではリークしない(循環参照はさておき）
が依然人間の不注意によって実質的なリークは起るわけ
それをお前はリークと呼ばなんだろうけど一般的にそれもリークと呼ばれてる
それだけの話
理解しようぜ
>>430 wikipediaは
歴史系は特に悪意のある文面多いですね
特に日本史
>>423 昔から言われてることだけに昔の記事あったからこれでも読んでみ
https://www.atmarkit.co.jp/fjava/rensai3/debug02/debug02_1.html 単に何をリークと呼ぶかというだけの話
Javaの開発元のサンの人もこういうんだからそれにあわせようぜ
>>438 GCが解放してくれるとプログラマが信じているが事実はそうでないケース
プログラマーが自分で作ったつもりのスレッドで資源を確保して、
スレッドの最初の関数からreturnしたら全部解放されると思いきや！
実はスレッドプールの1要素としてシステムが握りっぱなしだった、
みたいなテクノロジーホラーが
あるのかも
しれませんね
知らんけど
>>377 のリンク先のソースをすっかり理解できたとは言い難いけど、
この場合の <float, float, float> は (何かの角度, x座標, y座標) みたいね。
vecVisibilityPolygonPoints は最初の要素(角度)でソート済み。
get<1>()でx座標、get<2>()でy座標を取れるから
>>375 の第2段落の理屈は有効。
>>363 の質問に戻ると、
{0.1, 0.11, 0.2, 0.21, 0.4, 0.41}
↓
{0.1, 0.2, 0.4}
の理解でだいたい合ってる。単一の値の比較でなく
「x座標同士, y座標同士が両方とも近い値の場合だけまとめる」わけだが。
もうひとつ。376で tupple::get と書いたけど、もちろん tuple::get が正しい。
(ここを訂正しておきたかった)。
ちゅか循環参照するオブジェクトの解放のための正しい方策はマーク＆スイープ方式であって
普通の言語においては弱参照はあんま助けにならないﾊｽﾞ
（普通の言語では、一旦解放したオブジェクトを復活させることはプログラマがそのような復活コードを書かない限り不可能なため、
使用予定があるオブジェクトを単に弱参照にしてGCに好きなタイミングで解放させるだけだとプログラムがロシアンルーレットになる
実際のところ弱参照を用いてﾋﾔﾋﾔしながら辻褄合わせする（結局何がしかのコードが必要）なぐらいなら、
最初からGCに頼らずに確保と解放をコード上で明示的に計画した方がﾏｼ
で、マーク＆スイープ方式はマークのための空間と時間の計算量（探索！）が必要な上に、
その挙動をユーザーが書くプログラムコードから隠しおおせる言語でないと適用できない
C++でマーク&スイープしようとすると、オブジェクトaを所有するオブジェクトbの確保、が単に構造体をnewするだけでは済まなくなってしまうま
（所有関係をGCに教えるための呼び出しを書かねばならない。プログラムが小汚くなっていき、ぜってー忘れたり間違える
>>437 GCが本当に機能しているか点検せにゃならんオンボロ環境での話を一般化するな
> 不要になったらgc任せにせずに即null代入しておけ
クルマに例えるとすぐエンコするから人力で押せだな
>>429 >>432 弱参照は参照カウントなんて珍説はない
マーク·アンド·スイープアルゴリズムで弱参照の経路は辿らず、他からの経路がなければ到達不能と判断することで参照数を数えてるわけではない
>>437 > gc言語で本格的な開発したことないって白状してるようなもんだね
おまえさんこそ、相手の経歴や人格を攻撃せねばならんほど窮しているのが露呈してるぜ
頭の中で問題が整理できていれば冷静かつアカデミックに指摘ができるはず
そんなに頭に血が昇るのは問題が整理できていないか沸点の低いアレなやつか又は両方だな
>>440 大企業のやつに合わせるなら
おまえさんもシステムハンガリアンやれよ
>>422 ・ GC のない言語でうっかりメモリの解放を忘れる
・ GC のある言語でうっかりもう使わないオブジェクトの参照を残してしまう (GC の回収対象にならない)
リークと呼ぶかどうかはともかくとして、
前者で気を付けなきゃならないのと同様に後者にも気を付けないといけないというのは普通のことだと思うよ。
>>388 >
>>387 > 参照元が生きているのをリークとは言わない
> その状態で意図しない動作になるのはリーク以外のバグってだけだ
一般的にそれが意図しないものなら現象としてリークと呼ぶというだけの話
これを認めたら死ぬのかお前は
QZアホやｗ
Javaのメモリリークを見つけるのがどんだけ面倒なのか全く分からないようだ
こいつプログラマじゃないな
>>452 > ・ GC のある言語でうっかりもう使わないオブジェクトの参照を残してしまう (GC の回収対象にならない)
じゃあ、そもそもGCって何のためにあるんだってことだね
私見ながら、馬鹿馬鹿しいぜ
資源を解放すべき盤面で、自動化されてるんだから手を出しちゃダメ
あげく解放されませんでした、解放されてるかどうか確認をせよ
何なのコレ？
>>455-456
事例としては
例1： 使い捨てスクリプト
その程度の管理で良い。
ガッと動かしてそのまま終わるので管理もクソもない。
例2： サービスの変更が多いウェブサービス
まずは早期に動かすことが大事。
細けぇことは後でプロファイラを見ながらなんとかする。 >自動化されてるんだから手を出しちゃダメ
ﾊｱｗｗｗｗ？
コードで明示的にマークも出来ますが何かｗｗｗｗｗｗｗｗ
>あげく解放されませんでした、解放されてるかどうか確認をせよ
ﾊｱｗｗｗｗｗｗｗｗｗ？
>>456は不具合を発見してから不具合がないか確認するタイプ？ｗｗｗｗｗｗｗｗｗｗｗｗ
>>457 テキトーこきたいって正直に言ってくれれば
こっちもあっそーで済む
>>458 明示的にマークという時点でGCの敗北なんだよ
仕事でもそうだろ、引き受けたことをやってくれないやつは
もう信用されない できねえことは端っから引き受けるな
おまえさん、ぬるま湯に浸かってる人かい？
「資源の解放はお任せくださいっ！！(ｷﾘｯ
「あのー循環参照が・・・
「メモリーだけです！！（汗
「資源じゃなかったんですか？
「そのくらい察して下さい！！（滝汗
「もういいです
仕事でしゃーなしに使う言語あるいは
知ったかしたいアマチュアが使う言語、それがC++
仕事で喜んで使う言語だな
c#とかjavaとかだと嫌になる
>>462 java は、少なくとも昔の java は、厳しく抑制のきいた文法と豊富なクラスライブラリでいい感じだと思いますよ、文法は意味があっての簡素なほうが好みですね
c# は、クラスライブラリの全容を把握していないので、まだ評価にとりかかれないのですが、これからじっくり調べたいと思っています
Javaは新しいCOBOLになってしまった
当初の理想は良かったと思うけどままならんもんだね
>>461 シッタカにいつもマウント取られる水準のやつからは、そう見えるだろうな
まともにコンパイルも通してないで知ったかしてるバカに言えることなんてないけどね。
>>459 gcの勝ち負けなんか論じてないだろ
話すり替えて誤魔化すな
お前態度でかいわりに理解が周回遅れなんだよ
>>467 俺も論じてないんだがｗ
何が怪物に見えたのかな？ 病院行ったほうがいいと思うぞ
なんで
long long abs(long long x)
なんだろうか
負の数の方が絶対値の大きい値が表せちゃうのに
0x8000000000000000 代入してみろ
long longでないとすると、何型が妥当だと思う？
>>465 このスレで知ったかの相手すると荒れるから、大抵中身の無いマウントカキコはスルーされてるんだが
つまり、こういうことか
template <typename T>
auto abs(T val) -> enable_if_t<is_integral_v<T>, make_unsigned_t<T>>;
singedとunsigned混在すんなってことだよ
c言語レベルの質問はc言語スレでやれ
というか語りつくされた話題だから適当にググれ
背伸びしたい無職が使う言語は
C++かHaskellと相場が決まっとる
C++14(gcc)でUTF8の正規化をする場合、どんなやり方が良いとされているのかご教示ください。
C++ではやったことがないので初歩的なところからご教示いただけるとありがたいです。
・ICU以外の選択肢はあるのか？
・ICUを使う場合、直接APIを使うよりBoost.localeを使った方が良いのか？
>>477 文字コードスレできいたら？
icuで足りるんならicuでいいと思うけど
自分の経験ではicuのでかくて重いのが問題だったらから
必要な機能だけ自作したな
(unicodeがリリースしてるテストデータをパスさせた)
普通はc++だろ
javaとかc#とか環境整えるの面倒くさいじゃん
>>476 Cはかつて最大人気言語だった歴史があるのに対し、HaskelやRustはそうではない。
C++もCの人気を受け継いだ言語だし、処理速度が高速でメモリー使用量も少なく、
起動も速いし、Windows以外でもとても広いプラットフォームで簡単に動くのだから、
使うのは自然な流れだし、背伸びとかではない。
例えば、C#をAndroid/iOS/Linux/Macで動かすのは容易ではない。
Wasmで動かすにもネットからのダウンロード量が多くなり起動が遅くなる。
一方、C++ならWasmでも起動が速い。
>>483 C++を動かすのはOS以外に基本的に特殊なランタイムが要らない。
C#やJavaでは.NET環境やJVMが必要となる。
AndroidでもJNIを使えばC/C++は起動も速く動作速度もJava/Kotlin以上に軽快に動く。
同様にiOSでも、Swiftとリンクできるので同様。
逆にC#は、iOSやAndroidで動かすにはダウンロード時間や起動速度に問題があり、
動作速度にも desktop マシン以上に問題がある。
Androidだと、Java/Kotlinの仮想マシンの上に、.NETの仮想マシンを二重に載せる
形となるため、C/C++と比べれば、掛け算の形で遅くなってしまう。
例外やRTTIをイネーブルしてるとでかいスタティックリンクつくけどね
CならRAM16バイトのPIC10F200でも使える
>>486 ソースコードの見た目とバイナリのサイズがCと違いすぎって意味
Arduinoで使ってること考えたら、十分使える。
RAM2KBしかない。
>>485 スタティックリンクってどのライブラリをリンクするってこと？
そんなのあったっけ？
>>485 .NET環境は、それどころじゃない。
それはWindows Updateを見ていれば分かる。
.NETのUpdateのために、数百MB～数GBダウンロードされる。
>>479 自作はやりたくないのでICUを軸に色々試してみることにします。
ありがとうございました。
>>494 gcc のオプションに -static を加えればいいのでは？
>>498 https://gcc.gnu.org/onlinedocs/gcc-9.3.0/gcc/Link-Options.html#Link-Options -static
On systems that support dynamic linking, this overrides -pie and prevents linking with the shared libraries.
>>499 流れを読め。
>>485 みたいな状況でバイナリがデカくなる→何がスタティックリンクされるんや？ って話題だぞ。
マップファイルを出力させてみれば実際に何がリンクされるかはわかるんちゃう？
試してないけど。
libgccの大きさじゃなくてunwind用のハンドラコードの増加じゃないの？
(間違って別スレに書いてしまった)
>>503 RTTI の場合は、仮想テーブルと同様の場所に、実行時型情報へのリンクポインタが
書き込まれるようになる。
それがなかなか複雑な構造をしている。
RTTI情報も、ヘッダファイルの中に構造体が書いてあると、COMDAT形式で
全ての *.obj ファイルの中にいったん書きこまれることがある。
リンク段階で同じデータのsectionがある場合は、単一のsectionだけを残して
他は削除されてしまうが。
>>504 構造化例外もなかなか複雑なコードになる。
そのコードもある程度の大きさになる。
>>484 mono、core、zamarin調べて出直してこい
enum class を1オリジンにするスタイルはどの程度使われていますか？
char8_tってどういう経緯で採択されたんですか？
Microsoftを利する提案が受け入れられるのは相当珍しいと思いますが。
>>508 色々と事情はあるみたいなんだけど、
UTF-8 の文字列と従来の文字列を型で区別したいというのが主な理由だと思う。
その要望は昔からあるけど阻止してきたのに、なぜ解禁されたのか事情知りませんか？
>>510 江添亮のブログで関連する提案や議論が取り上げられているので順番に読んでみたらいいと思う。
https://cpplover.blogspot.com/search?q=char8_t 具体的にこれが理由と言えるひとつの理由があるわけではないけど、
やってみたらやっぱ要るわ……という雰囲気っぽいかな。
要するに文字列をナメてたんだろう。
charにutf8突っ込むだけでunicode対応できるとか考えるやつがようやく淘汰されてきてありがたい
そもそも「Microsoftを利する提案」てなんだよ
C++は別にアンチMSじゃないだろ
std::size(u8"あいうえお" - 1)みたいな感じですかね。
std::u8stringとかC++は規格に出すのが遅い
>>514 W3CもアンチMicrosoftではないのだけど、会員がIT業界の人たちなので、結局のところ、如何にしてMicrosoftを落とすか討論する場所になってました。
>>508 どう利するわけ？
windowsの中はutf8じゃないよ
>>519 >>508がアンチMicrosoftなだけじゃないかな
enum class とか、MS起源の機能なんていくらでもあるんだけどな
>>504 そのあたりも増加原因になるのはわかる
でもどちらにしろlibgccのリンクとは無関係では？
>>512 下のみたいなノイズだらけのクソブログを挙げるな
もっとマシなのあるだろ
そうかな
utf8をコア仕様にいれたら「文字とは何かを理解する」ってのは
ちょっと同意できないな
constexprがあるので、エンコーディングを型に組み込んでしまっても、困ることは全くない。
C++のお作法になじんでいれば、お得な事しかない。
UTF8ベースにしたらどうやって1文字ずつ処理するの？めんどくさい？
>>512 下のサイト的に言えば、誰もが
固定長に数値が収まるという夢を見た愚か者たち
なので、必要悪な気はするな
>>531 code point単位なら結局utf32にして数える(部分的に可能)
面倒なのはgrapheme clusterから上
もう土方レベルが扱える代物じゃないね
内部では utf-32 ベースで処理して、出口入り口で utf-8 に／から変換するものだと思いますが…
>>528 リッチーならともかくカーニハンは見てる可能性
>>535 色んな文字コード (符号化) を扱うときは出入口で変換する方法は妥当な選択だと思うけど、
UTF-32 を中心に据えるのが良いかは一概に言えるものでもないでしょ。
たとえば Windows API がいう Unicode は UTF-16 なわけだし、
外部とのデータのやりとりで内部用の符号に変換する処理が入るのは仕方がないにしても
API の呼び出しのときまで毎回変換が入るのも煩雑なんで、
UTF-16 に統一した方全体としては楽じゃない？
サロゲートペアの扱いが面倒くせぇとかいうのと天秤にかけたとしても
Windows では UTF-16 から離れられない。
結局のところ実行環境とかフレームワークとかの都合に縛られるから
(内部用の符号として UTF-32 が優秀なことは承知しているが)
そのへんの規約とか習慣に従うしかしゃーない。
出入り口から内部処理まで出来る限りutf-8で統一して処理するのが
トラブルが少なくて済む(個人の感想です)
それは文字列としてだけ扱って文字単位(code point単位)の操作しないときでしょ
あるいは小難しいところは全部ライブラリに投げてるとかね
>>539 ＞たとえば Windows API がいう Unicode は UTF-16 なわけだし、（略）
＞API の呼び出しのときまで毎回変換が入るのも煩雑なんで、
＞UTF-16 に統一した方全体としては楽じゃない？
Windows では UTF-16 を使うといっても、実際に変換しなければならないのは、ファイル名・パス名を扱うときだけですし、
UTF-16 も可変長の部分があって扱いにくいので、私なら UTF-32 で楽したいと考えますね
UTF-32でも結合文字と異体字セレクタはある
結局ライブラリに投げるでしょ、ならどれでも同じじゃね？
マルチプラットフォームのアプリじゃ内部はUTF-8にする場合が多いけどな
なぜならUTF-8にはバイト順問題がないから
どのみち一文字表すのに複数のコードポイントが必要なんだからUTF-8、16、32のどれを使っても言語処理の手間は同じだ
「イングランドの旗」絵文字なんてコードポイントで7要素も必要なんだぜ
マルチコアの高速化と同様に
32bitのCPUで16bitを扱うと2倍速
64bitのCPUで16bitを扱うと4倍速
みたいにならないんですか？
32ビットと64ビットで二倍の時間になるのではなく、たいてい4倍になりますよ。
文字列関連の処理はだいたいメモリアクセスかIOがボトルネックなので、単純にサイズが 増えればその分遅くなるよ
>>546 simd使えばそれに近づくだろうけど
そうでなければシリアルに計算されるだけなのでほぼ変わらない
大量のデータを処理する場合はメモリ効率の点で速くなるかもしれない
しかしintへの拡大変換が入るので演算自体は遅くなる方向
まぁ自分でベンチとってアセンブラ眺めてみたらいい
かなり環境依存・実装依存なんだから人にきいてもあんまり意味ない
4倍になる人とかいるらしいしw
SIMDなら32bit CPUとか64bit CPUとか関係ないし
>>556 そのベンチどっかに貼ってみて
wandboxとか
64bitを使っても、大部分のソフトウェアは速くも良くもならない事が知られている。
16bitから32bitの時には急激に多くのメモリが使えるようになって劇的にソフトウェア
が作り易くなったのと対照的。
メモリ容量に関してはたいていのアプリでは32bitでも既に十分。
速度に関してはそもそもCPUが扱えるデータビット数を多くしても滅多に速くならない。
速くなるのはグラフィックで単純なBitBLTを行うような場合のみ。
縮尺や回転が入るだけで64BITの効果は通常、生かせなくなる。
>>554 RGBA計算も、(SIMDを使わずに)単純にデータバスが64BITになっただけでは速く出来ない。
なぜなら、R,G,B,Aはそれぞれ1バイトだから1バイトずつの計算するしかないため。
SIMDを使う場合は、CPUの種類によっては、SIMD自体のベクトルの要素数が倍になるため、高速化できる可能性はある。
ただしそれは、整数命令が64BIT化されたこととは直接関係ない。
SIMD命令のベクトルの「次元」が上がったかどうかの問題。
>>560 なんでわざわざ関係ないことを書いてわざわざ混乱させようとするかなあ
64ビットの演算1回の時間で、32ビットの演算4回出来るんですよ。
>>547 なりません。
ならないからこそ、GPGPUのようにマルチコア化が進められています。
SIMD命令も扱いにくいので、マルチコア化が適しています。
例えば、3Dのレイトレーシングなどは、SIMD化することはとても難しい
のですが、マルチコア化は比較的容易です。
人工知能のニューラルネットワークの計算はSIMD化し易い部分もあります。
しかし、300コアなどのマルチコアと、8要素のSIMD命令では、
前者に軍配が上がり易く、しかも、コア数が増えてもプログラムの修正が
ほぼ不要なので、マルチコアの方がSIMDより好まれます。
ただし、命令自体の速度がx86系は速いため、どちらが実際に速いかは
単純ではありませんが。
>>562 CPUの一般論としてそんな事実は有りません。
あるなら具体的に書きましょう。
これ最初に気が付いたのは、固定小数点は速いらしいというのを見て、いろいろやってみたら、特に早いことは無くて。
じゃあ何が影響するかというと、単にビット幅だったんですよ。
floatとint32_tは同じ、doubleとint64_tは同じ。
つまり、アキュムレータの性能はあまり関係なくて、バス幅とキャッシュがすべてなんですよ。
じゃあ32ビット2回分が64ビット相当になるかというとそうでもなくて。
たいてい4回分で64ビット相当になるんですね。
>>558 まさか！
2^32 bit 空間が狭すぎる、というのは windows XP の頃から問題になっており、2^64 bit 空間は必然でした
＞メモリ容量に関してはたいていのアプリでは32bitでも既に十分。
個々のアプリ単体ではそうであっても、個々のアプリを複数稼動させる OS では32bit では足りないのでは？
そして 64bit OS に対応した 64bit アプリの存在も必要でしょう
あと、僕はベンチマークのカタログとしてVSのテストエクスプローラ使ってますよ。
テストケースを一つずつ呼び出せるので大変便利です。
何をして速くなったと言っているのか不明なのに自分でってw
>>570 測るのは自分でやるからベンチのソース見せてよ
比較実験やるにあたって環境も実装も変えたら比較にならないんだしさ
ここで逃げたらかなりださいと思うよ
>>573 そっちが出してくださいよ。
アセンブラ見ると速度がわかる奴。
めんどくさいんですよ。
アセンブラ見れば速度がわかると言ってる時点で、僕は得るもの無いじゃないですか。
何か作業を手伝ってくれるならわかりやすく提示しても良いんですが。
作業を手伝ってもらうのに、色々教えないといけないなら、やっぱりめんどくさい。
64bit命令を使うと4倍以上速くなるのは
64bitの乗算くらい
64bit加減算もCPUによっては数倍にはなる
それ以外は特殊な場合のみ
intとint64_tで適当なfor分で配列計算やらせてみればわかる。
手元じゃint64_tのが若干遅い
>>569 それは当たり前で、マシンには4GB以上のメモリが乗っているので、32BIT
では、OSレベルでは扱いにくい。
多くのプログラマにとって大事なのは、個々のアプリの問題だから、
OSレベルの話は関係ない。、
また、Windows OSがメモリーを食いすぎているという問題もある。
>>580 補足すれば、グラフィック用のRAMは大きくなりがちで、最近のWindowsでは、
1つのWindowに仮想VRAMを割り当てているから、アプリが起動するたびに
グラフィック用になかなか大きなメモリーを消費する。
それと、ブラウザで複数のタブを開いている影響。
あれもグラフィックのレンダリング用に大量のメモリーを食っているのかもしれない。
>>577 他人を説得するつもりがないなら不特定多数が集まる場で自論を展開せず、馬鹿なこと言ってるなフフッて一人悦に入ってればいいんでない？
>>580 今は、見えないものまで含めれば50個のプロセスが動いているなんてことは当たり前になっている。
だから、個々のプロセスが80MBのメモリしか使って無くても、合計すれば4GBになる。
さらにファイルバッファや、OSが高速化のためにさまざまなキャッシュ的なデータを保持している。
しかも、ファイルバッファやキャッシュはいくらあっても不足する時代となった。
ブラウザがページを記録するためのキャッシュも必要だ。
そういう訳で、アプリが80MBしか使って無くても、OS全体では4GBではメモリが不足する。
というわけで、4GBを超えるメモリが必要となっている。
タスクマネージャーで見ていても、個々のアプリは、多くても数百MB程度のものが多い。
ファイル高速検索ツールなんかが、1.6GBも使っていたりするが、それは特殊。
だから「特殊なものを除いては」今のアプリが2GBを超えるメモリーを必要とすることは稀、だと言っている。
32bit Windowsが4GBまでなのはWindowsの仕様であってCPU自体はそんな縛りは無いし
>>587 典型的には、32BIT mode でも、PAE サポートによって OS は 4GB を超える
メモリーを扱えるね。
64GBまで使えるようになったのPentium Proからだぜ？ｗ
Klamathより前！！
>>591 いや、彼は正しいことを言っている。
あなたがIntel CPUの仕様を詳しく知らないだけ。
PAEという仕組みなどで32BITモードでも4GBを超える物理メモリーを扱うことができるようになっていた。
QZは女なのだろうか。
ショックかも知れないがはっきり言えば、本質的に物事が正確に理解できていないようだ。
8bit CPUは256Bしか扱えないと思ってる人いる？
16bitのCPUでも16bitアドレスの最大値である64KBを超えて1MBもアクセスできていたからな。
>>597 16BIT CPU であった 8086は、16bit アドレスを超える範囲は、セグメントレジスタ
と合わせた seg:ofs の形式の far pointer を使わなくてはならならず、
単純に扱えるのは16BITまでで、16BITを超えた範囲では、seg レジスタの値を
足していかないといけなかった。しかも、segがアドレスの上位16BITだったなら
まだしも、16バイト単位のアドレスだったので、segレジスタに入れる値を計算
するのがとても重くなってしまっていた。
ところが、Z80 などの 8BIT CPUは、普通に 16BIT レジスタの
HL や DE, BC, IX, IY をもっており、8086 と比べれば扱いは容易だった。
その意味では、8086は、メモリーアクセスに関してはZ80と同じくらいしか
能力を持っていなかった。
それで8086の16BITモードでは限界が来て32BITモードのOSが待望された。
そしてMacのGUIを真似た機能を持っていたこととも合わせて32BITモードで
動いたWin95となった。
ただし、このような状況は64BIT化に関しては全く無い。
そりゃまあ、64bitCPUがすでにいきわたっていてOS変えるだけで対応できたからね
WINAPIだって16→32のコンパイルはまず動かないけど32→64なら普通は動く
DOS時代のUMBみたいなみみっちい事態にならなくてよかったじゃん
86用コンパイラでnearとfarの他にhugeが有ると知らず、無限ループ作ってOSごと来なくなったあの頃
long longとint64_tの違いってlong longは環境によって64bitじゃなくなるけどint64_tは常に64ってことですか？
|
| 彡⌒ミ
＼ (´･ω･`) またhugeの話してる・・・
(| |)::::
(γ /:::::::
し ＼:::
＼
32bitの環境で32bitの境界を超えるような64bit値の計算ってどうやって実現してるの？
cpuに命令なければソフト的にやるに決まってんじゃん
ちなみに32bitの掛け算の答えに64bit必要ってわかってない人多いよね
同様に64bitなら128bit
64bitだとdoubleとかの書き込みはアトミックになるの
C/C++にキャリーフラグ観る機能が無いのはなせ？
アトミックにしたけりゃstd::atomicを使え
使わない場合は保証されない
>>612 いれるとしたらどんな仕様でいれる？
そこまで考えてから書いてみたんだよな？
>>613 64bitでない環境だとatomic持ち出したところで使えないじゃん
>>611 ほとんどの環境でYES
32bit CPUでもアトミックな環境もある
>>612 キャリーフラグが無いCPUも有るから
CPU固有の機能はintrinsicを使う
>>609 整数の乗算を全範囲正確に求めたい場合の話だな
これもC++では書けない
intrinsicを使う
>>617 なんで90度？
180度だって書いてるのに
int128でもint256でも自由に型が作れるのがC++の強みなのに書けないってw
int_<256>みたいの作ってたけど
サイズが発散する問題がすぐ起きる
>>620 > 32bit CPUでもアトミックな環境もある
具体的な環境名教えて
shared_ptr<Hoge>をvoid *の領域に格納したいのですがどうすればいいでしょうか？
SetPointer(void *),void* GetPointer()で設定します
shared_ptr<Hoge> hoge
として
SetPointer(hoge)
取り出す時
shared_ptr<Hoge> hoge = GetPointer()
後、SetPointerする前にshared_ptrの参照カウントを一つ増やしたいです。
>>629-630 所有権込みで格納したいだけなら。
SetPointer(new shared_ptr<Hoge>(hoge));
shared_ptr<Hoge> hoge = *static_cast<shared_ptr<Hoge>*>(GetPointer());
あとはどうにか delete が抜けないようにする。
本当にshared_ptrごと格納する必要があるの？
これで良かったりはしない？
shared_ptr<Hoge> p(new(buffer) Hoge, [](Hoge* p){p->~Hoge();});
つまりshareする気がないけどshared_ptrを使いたいわけだな
誰かと食べる気はないけど、マックのシェアポテトを食べたい感覚だね
>>632 これ難しすぎて解読できません
まず、やりたいことはWindowsのTreeViewでノードを追加するときに、ノードにLPARAM型の任意のデータを関連づけれるんですが、そこに他の関数から受け取ったshared_ptr<Hoge>を関連付けたいのです
shared_ptrごと格納する必要ないと言えばないのかもしれません
でも中身だけ格納すると、deleter?の情報がとんじゃう?
所有したいのか/参照持ちたいだけなのか
shared_ptrとして使う必要があるのか
参照だけ持ちたいとしてダングリングの可能性が有るのか
あーあ。shared_ptrごと格納できるならそっちの方がいいです。
そうしないと誰が最後にdeleteするかめんどくさくなりなすね。
すみませんでした
TreeViewが持つのはポインタだけで、オブジェクトの寿命管理するわけじゃないんだろ？
だったらshared_ptrのdeleterの情報なんか渡す必要ないんじゃないか
オブジェクトの寿命管理する奴が知ってればそれでいい
>>639 shared_ptrはlparamに収まらないから無理
sizeofで確かめてみ
すみません。何か頭混乱してきた・・
>>630が余計だったのか・・
まず、基本方針としてオブジェクトの寿命管理を楽にするためにクラス間でデータをやり取りする場合は
全部shared_ptr経由で参照カウントにより自動で管理してもらおうという方針です。
ですが、既存のライブラリとの都合で例えば、今回のTreeViewのノードにはLPARAM型のデータしか関連づけらられない
ということで、ノードに関連づけるときに参照カウント手動で？増やしてあげて、ノードを削除するときに、
参照カウントを手動で減らして？あげて調整するものなのかなぁーと思った次第です。
データの本体は別にあってそっちで所有権管理しているなら、treeviewにはshared_ptr::getで得られるpointer持たせればいい
使う側でshared_ptrである必要があるなら、shared_from_this使う
ダングリングする可能性無いならならこれでおk
void*で渡しちゃう以上はTreeViewに参照カウント減らさせるのは不可能なので、そこは外側で管理してやるしかない
だったらTreeViewはshared_ptrがどうのこうのという情報は知らなくていいし、知らせるべきでない
>>644 TreeViewってのはWindowsの既存のコンポーネントだろ
ちょっとまとはずれだよ
答えは
>>631 で出てる
>>639 手動deleteが本当にいやならあとは黒魔術使うしかないね
unique_ptrなら64bitにおさまるだろう
>>645 既存のコンポーネントだからだよ
shared_ptrのこと知らんやつにshared_ptr渡したってろくなことにならんだろ
>>646 荒らしたくないがもうちょっと質問者の内容くみとってから返事書いてやれよ
shared_ptrの型で渡すんじゃなくてvoid*の型で渡すって最初から言ってんじゃん
何が気に食わなくて噛み付いてるのかよくわかんないけど
TreeViewはshared_ptrのことなんか知らないんだから、そんなものは知らせずに
関連のあるデータを与える(要はshared_ptr<Hoge>*じゃなくてHoge*を渡す)方が設計すっきりするんじゃない？
って言ってるだけなんだがそんなにおかしいか？
何か追加して問題が出て別の何か追加して解決するの繰り返し
C++の仕様は余計なものが多い
メモリーの所有権の移動とかの暗黙知の極みを気にできるくらいならdelete忘れることはないだろうに
Hoge* 渡して済むなら最初から相談なんて発生しないだろうと思ってたんだけど、
>642 みたいな「基本方針」だと shared_ptr の必要性が胡散臭いんで、確かに
Hoge* で済む可能性もありそうな気がしてきた。
>>648 shared_ptrでわたってくるものをvoid*で管理したいってことで
それは質問の前提条件
解としてHoge* にするってのは破綻するからダメでしょ
>Hoge* 渡して済むなら最初から相談なんて発生しないだろう
そうです。Hoge*で渡したくないから質問した次第です。
元のデータが先に捨てられようと、先にTreeViewのノードが破棄されようと、どっちが先でも
OKなように、それらを意識しないようになるべく参照カウントの仕組みで破棄したかったわけです。
だったら
>>631も、結局TreeViewの破棄を監視して破棄前にdelete GetPointer()かけないといけないんだけど
それでもいいのか？本当に意識すべきことは減ってるのか？無用な複雑さを持ち込んでるだけじゃないのか？
っていうことを一回冷静に考えた方がいいよ
逆にHoge*で受け取って、
Tree破棄時にPointer破棄処理省いてしまって、
あとはsharedのスコープで全消しすればいい
もちろんノード追加時に参照カウンタ増やす必要もない
>>653 それは問題ないです。
>>642に
>参照カウントを手動で減らして？あげて調整する
って元からそれをやる前提でした
前調べたら
https://docs.microsoft.com/en-us/windows/win32/controls/tvn-deleteitem ノード削除時に発生するイベントがあるので、ここ1か所にかくだけでいいのかなと
思ったので、その方が分かりやすいかなと思った次第です
てか、この方法駄目そうですね？
>delete GetPointer()
じゃなくて、参照カウントを減らしたいんですけど、無理っぽいのかな・・
COMならAddRef,Releaseで調整できるんですけど
もうちょっと調べて駄目そうならHoge*でいきます
>>656 new した shared_ptr を delete すれば参照カウント減るよ。
でも Hoge* で済むならそっちで済ませたほうが面倒も無くて効率もいいだろうよ。
そもそもTreeViewってViewだから見た目を整えるための奴でしょ
自分ならロジックデータの寿命管理にそんな奴参加させたくないな
まあ、削除時のコールバックが指定できるんだったら、それで後始末するのも手ではあるかもね
小さいプログラムで、見た目の要素の何かとHogeが論理的に一対一対応してるんだったら許容範囲かな
>>653 質問者はクラス間で共有するデータは一律shared_ptrにすると言っている
これは全体設計の選択としてまぁある話
しかしこれによって既存コンポーネントのTreeViewで
インタフェースのミスマッチが起こった、さてどうしたらいいでしょう？
という質問なわけ
これもよくある問題
だからって全体設計のポリシーをとりやめようとはならのよ
解決できる手段があるなら部分的な問題は個別に解決したらそれでいい
>>659 言ってることは分かるけど
それでどうしてTreeViewにshared_ptrを埋め込むことに固執するのかがわからない
そこはおとなしくTreeViewには生ポで参照してもらうっていうのも一つの「部分的な問題の個別解決」じゃないの？
Linux でのライブラリについて質問があります。
静的リンクライブラリ（拡張子が.aのファイル）は複数のオブジェクトファイル（拡張子が.oのファイル）を ar コマンドでアーカイブしたものと理解しています。
一方自分で調べた限り、動的リンクライブラリ（拡張子が.soのファイル）を作る場合には gcc を用いる場合は-shared （と-fPIC ）を指定して一つのソースファイルから一つの.soファイルを作成しているように思います。
例: g++ -shared -fPIC -o sample.so sample.cpp
この理解の上で質問です。
動的リンクライブラリは静的リンクライブラリのように一つのファイルにまとめられないのでしょうか？ソースの数だけ.soファイルが出きてしまうのは避けられないのでしょうか？
単に.oを複数与えればいいんじゃないの？
何か問題あったっけ
>>656 汚い手段を避けるなら、
shared_ptr を受け取って保管し、管理用のハンドルを返すクラスを作って
TreeViewにそのハンドルを入れとけばいいのでは。
>>628 ちょっx86やx64でアトミックに読み書きできる（バスサイクルが他コアに割り込まれない）ことが保証されているのは
32 bitまででしかも32 bit境界に整列している場合のみのでは…
ちなdoubleは64 bit
>>662 あっ、それでできるんですか。
ありがとうございます、やってみます！
>>664 64bit境界であることは必須
あとは大昔のCPUじゃなければアトミック
wandbox上だとatomic<double>はロックフリーらしい、多分x86-64環境なら同じ
https://wandbox.org/permlink/0LWMsNPNmSn6rpZ4 >>666 >64bit境界であることは必須
ハア(ﾟДﾟ)？
ていうことは
char *p = ～;
*p = 'a';
は、pが8の倍数でなければ非アトミック？？
short *q = ～;
*q = 123;
もまた、qが8の倍数でなければ非アトミック？？？
なんと？！
doubleの話をcharに拡大して何がしたいのか
shortだって64bit境界跨いでたら非アトミックだぞ
わざわざ作らなければそんなことにならないだろうけど
つかインテルアーキテクチャーのソフトウェアーデベロッパーズマニュアルによると
「8.1.1 Guaranteed Atomic Operations」
に書いてあったわｻｰｾﾝ；；；；
The Intel486 processor (and newer processors since) guarantees：
- Reading or writing a byte
- Reading or writing a word aligned on a 16-bit boundary
- Reading or writing a doubleword aligned on a 32-bit boundary
The Pentium processor (and newer processors since) guarantees：
- Reading or writing a quadword aligned on a 64-bit boundary
- 16-bit accesses to uncached memory locations that fit within a 32-bit data bus
The P6 family processors (and newer processors since) guarantee：
- Unaligned 16-, 32-, and 64-bit accesses to cached memory that fit within a cache line
とのことなので「The Pentium processor (and newer processors since) 」ならおk
で、「The P6 family processors (and newer processors since) 」において
キャッシュラインを跨ぐとatomicが保証されない旨がその下に書かれているので、
- Unaligned 16-, 32-, and 64-bit accesses to cached memory that fit within a cache line
は妄信はできん
やっぱalignedな場合しか信用できん
まあ今時のプロセッサだとキャッシュライン単位でしかdramアクセスしないからそうなるのが自然なんだよね
こういう非常時でも特に誰かがプログラムで社会貢献してるとは聞かないな
アングル：コロナ感染経路、スマホ使った「接触追跡」の最前線
https://jp.reuters.com/article/health-coronavirus-tracing-idJPKCN21X0LE つかビッグデータ取り扱い系分野は災害時に地味に活躍している印象
ホンダとか東日本大震災翌日からインターナビで収集した情報で被災地の道路寸断マップを
作って公開したんだったと思った（記憶モード
https://www.honda.co.jp/news/2011/4111109.html >>611 その変の話は詳しくないので分からないのですが、この質問は、マルチコアやマルチCPUでの話ですか。
前から、その辺は、CriticalSection()などで排他処理すれば問題ないのではないかと思っていたのですが、その変どうなんでしょう？
それとも、自作OSなどで、 CriticalSection()のようなものを自作する場合の話でしょうか？
ちなみに、xor xchg などの話はよく理解できてません。
これらは、複数のCPUが1つのフラグを同時に読み書きした場合の問題なんでしょうか。
>>680 マルチCPUなどの場合は、キャッシュの同期(?)も関係してくるので、
そもそも何を持って「atomic」かどうかということが疑問になってきます。
キャッシュの内側で、CPUが、atomicにキャッシュに書きこんだつもりで
あっても、他の CPU のキャッシュに反映されない可能性があるので意味が
ないように思えます。
となれば、キャッシュ制御まで含めて考えないといけません。
キャッシュも、1次キャッシュ、2次キャッシュ、データ用キャッシュ、
コード用キャッシュ、パイプライン、などものすごく複雑になっているので、
果たしてそういうようなものを含めて「atomic」という言葉ですべてを語ることが
出来るのかどうかも疑問です。
>>611の意味は
読み書きの途中で他のCPUやコア、スレッドが別の処理を行う事で一貫性が無くなる事は無いということ
例えばatomicでないと
64bitの一部を書き込んだところで
他のスレッドが値を読んでしまって
64bit全体としてあり得ない値になる
というような事が起こらない
というだけ
同期とか他の読み書きとの順番とか
そういう事はatomicは何も保証しない
データベースとかで言う Atomicity と同じやね。
>>684 あるスレッド書いたdouble値を別のスレッドが読みたい場合
CriticalSection 中に読み書きすればよいのではないですか？
OSカーネルの実装以外では、命令自体の atomic 性に期待するのではなくて、
ちゃんと、OS が用意している API や system call を使って、CriticalSection
的なブロックを作って、その中で読み書きするのが基本ではないですかね。
>>686 それで十分ならそれでいいよ
無理して難しいことしなくていい
MotherBoard上にもキャッシュがありますし、マルチコアではなく、マルチCPUの
環境だと、いくらCPUがatomicに書いているつもりでも、バスでつながっている
他のCPUのキャッシュには反映されていない可能性もあるのではないでしょうか。
>>689 だから難しいこと気にしなくていいって
だまってCriticalSection使ってろ
お前のバカなところはてめぇの無知を自覚せずに
atomicは不要というぶったぎり論を始めたところだ
もしいい年したおっさんなら芽がない
>>689 ＞MotherBoard上にもキャッシュがありますし
それは Pentium 世代でしょうね、PenII 世代からはマザーにキャッシュを乗せるというのはきいたことがありません
>>691 そんなに物知りなら、こんなところで聞かずにIntelマニュアルでも調べたら分かることじゃないか。
はっきり言って、ここで double 値への書き込み atomic だなんて言ってる人の言うことはどこまで信用できるか分からん。
x86 CPU的には、xchg命令など一部の命令を除いてはそんなことは保障されてるかどうか定かではない。
>>693 お前こそマニュアル読めよ
メモリ操作にはlockプリフィクスがつけられるんだよ
lock prefix は、mov 命令には付けられないがな。
アトミックはいわゆるout of thin airな値の発生を防ぐためのもの
それ以上でもそれ以下でもない
std::atomic の意味付けとごっちゃになるから、「割り込み不可」「不可分」あたりと使い分けてほしいなぁ。
もしかして、
double g_dbl[1024];
に対して、何かの値を足すような動作を、2つ以上のスレッドで
分担して行うことで高速化しようとしているのか？
そんなやり方は、マルチスレッドプログラミングでやっていいのだろうか。
普通は、要素番号 0～511 までをスレッド1が、512～1023 までをスレッド2
が計算して高速化する。
全く同じ場所に複数のスレッドが書きこむことは原則としてやらないはずだ。
>>701 GPGPUを使ったレイトレーシングでも、画面上の別のピクセルをそれぞれのコアが
計算するのが原則で、1つのピクセルを複数のコアが分担して計算するには、それなりの
工夫がいる。
工夫というのは、途中までは別のワーキングエリアに書きこんでおいて、最後に
その結果を基本的にシングルコアで足し合わせて最終結果とするようなことだ。
これだと、例えば、途中の計算を double型で行うとしても、doubleへの書き込みが
atomicであることは特に必要ない。
>>696 そうだけどmovはそもそもatomicじゃん
>>694 で何をいいたいのかわからないな
(ちなみに最近のコンパイラはfpu命令でなくsimd使うのでmovと書いてる)
気になったのは、「atomic」というコンピュータサイエンスで用いられている
言葉を
>>611 のように実際のCPUで出来ているかどうか質問していること。
IntelのCPUマニュアルでは、atomicという言葉は使わずに、#LOCK PINアサート
が立つかどうかや、キャッシュコヒーレンシー、といった言葉で説明されている。
「atomic」という言葉は、キャッシュなどが「無いものとして分かり易く」
理解するには有効であるが、実際のCPUではキャッシュの一貫性や、PCIバス規格
と絡んだ詳細な説明が必要となる。
何を持って「atomic」というか、という問題が起きるからだ。
>>702 movも、実際のCPUでは必ずしもatomicとは限らない。
まず、alignment 境界を跨いででいるような場合や、
物理的に複数のCPUがマザーボード上にある場合のキャッシュの一貫性の問題が
あるから。
Intelの最適化マニュアルなどで、マルチコア並列化の例として上がってないような
方法は、勝手にやると破綻するかもしれない。
実機で実験してやるのは自由だが、他の人のCPUでは誤動作するのは覚悟した方がいい。
「アメリカ人は、書いてないものを勝手に使ったあなたが悪い」
という思想だぞ。
>>704 マニュアルに安全な具体例として載ってないから疑ってるって話ね
ご自由にどうぞ
でもそれはあくまでお前の判断
メジャーコンパイラがintelのサポートうけてないとは思えないから
おれはコンパイラの出力眺めてみるけどね
>>705 並列化の処理は研究されているから、Intelが例として一度も書いてないんだったら
多分やめた方がいいと思う。
>>703 atomicとコヒーレンシーや同期がごちゃまぜになってる
もうちょっと勉強するか
素人なら素直に既にある同期や排他制御の仕組みを使いなさい
色々な理由でやむを得ず使う上級者の技を
素人がまねしなくて良い
>>706 ちなみにメジャーコンパイラが
std::atomic<double> ＆ std::memory_order::relaxed
をどう展開するか知ってるんだよね？
これを疑ったらコンパイラを自作するしかないんでは？
>>709 そのoperator=()関数は、store() 関数を使っていて、その関数は lock(), unlock()
で囲ってから書き込みをしている。
>>710 そりゃご愁傷様
おれの環境だと普通にmovqだけどね
>>712 おれは最初から困ってないしw
お前がいろいろ大丈夫かよ
ちょっ（キャッシュの）一貫性とアトミック（なアクセス）は別概念なのでは…
後者はあくまで
>>664の括弧内の意味
一貫性が保証されている単一キャッシュライン内のデータに対するアクセスでも
アトミックでないケースが理論上はありえる
つか同一キャッシュラインに乗っているからといって
配列アクセスは非アトミック、
>>679 じゃあ電話交換機のプログラマーとか？
災害に際して実際に活躍したシステムの例を引き合いに出したのに
なんで白昼夢スレに誘導されるのかがわからん…
C++でdoubleで同期取ろうとしてることすら意味不明なんだがキミたちは結局何がしたいんだい？
処理系依存するものはOSの同期を使えよ。
同期は遅くて当たり前だろ。
並列化したら速くなるとか同期コスト知らないIT音痴の妄想なんだから。
処理系依存していいならIntelのTSX試せよ。
同期を速くするのは無理だぞ
高速化したければ同期を減らすんだぞ
>>718 できるかどうかと
やるべきかどうか
は別の話
区別しようぜ
>>718 誰もdoubleで同期を取るなんて話はしてない
atomicなアクセスの話題
>>716 複数ならSIMDレジスタを使う
YMMなら4個、ZMMなら8個までatomic
同期をとればatomicである必要はない
そういうことじゃないのか
話をまとめるとこうなる。
・8byteの読み書き命令がatomicかどうかは処理系依存する話でC++の話ではない。スレチだが聞くならチップを指定して聞け。チップ仕様見れば答えは出る。議論の余地はない。
・8byteの読み書きを同期したい、atomicにしたい。OSの同期か適当な同期ライブラリ使え。悩む余地なし。
・atomicと同期は話は別だ →ありえないw ハードでatomic命令の実装に同期が必要だし、ソフトの同期処理の実装にCPUのatomic命令を使う。atomicの実装を知りたければVHDLスレにでも行け。
・馬鹿は同期を理解できない←30年前から言われてる名言。C++スレでdoubleがatomicかというアホ質問自体が証左。
>>719 なんだ、そこにそのまま書いてあるじゃない。
つまり、alignされているなら quadword は atomically に Read/Write できる。
キャッシュラインの中に納まっているなら align されてなくても OK、と。
8.1.1 Guaranteed Atomic Operations
The Intel486 processor (and newer processors since) guarantees that
the following basic memory operations will
always be carried out atomically:
・Reading or writing a byte
・Reading or writing a word aligned on a 16-bit boundary
・Reading or writing a doubleword aligned on a 32-bit boundary
The Pentium processor (and newer processors since) guarantees that
the following additional memory operations will always be carried out
atomically:
・Reading or writing a quadword aligned on a 64-bit boundary 16-bit accesses to uncached memory locations that fit within a 32-bit data bus
The P6 family processors (and newer processors since) guarantee that the following additional memory operation will always be carried out atomically:
・Unaligned 16-, 32-, and 64-bit accesses to cached memory that fit within a cache line.
>>611に対する回答は既に
>>673で明確に示されて終わってる話。
それを急に同期の話と勘違いしてとんちんかんな蒸し返し方をした
>>680がおかしい
その486の話でいうと、当時、486は自己書き換えコードを駆逐した。Prefetchされたコードは非同期のまま実行されたからだ。Prefetchされたものはメモリではないと言い訳してもPGはそうは思ってないのだから高速なCPUだけ動かないコードがいっぱいあったわけだ。
結局、Intelが折れたのかPenから正しく同期されるようになった。TSXといいIntelも結構やらかしてるし、PICじゃ今でも同期エラッタてんこ盛り。MIPSの実装なんて言わずもがな。
>>732 同意
そもそも486の時代に自己書き換えコードがいっぱいあったとかにわかに信じがたい
8086時代は結構あった
古いコードのおもりをさせられた人は苦痛だったろうね
今よりはるかにパズルコードが多かったし
>>730 atomic命令=排他制御(同期処理)された命令。同義。
doubleアクセスがatomicか知りたい=double値で同期したいと解釈するのは普通じゃないかな。
まぁatomicであろうとなかろうと、C/C++的にはOSの同期オブジェクト使えって結論になるわな。
マルチスレッドの再現性ないバグの99%は同期のおれおれ実装が原因だし。
アトミックと排他制御と同期処理って同じじゃねーぞ
doubleでアトミックと言うのは例えば
double d = 1.23;
…
d = 2.34;
ってやった時にdが1.23と2.34以外の値にならない事を言う
どっちの値になるかまでを保証するわけじゃない
>>736 おれは同じ意味で使ってるし、
世界の技術者もそうだからボクたちに合わせてくれないかな。
>>735 > まぁatomicであろうとなかろうと、C/C++的にはOSの同期オブジェクト使えって結論になるわな。
お前 ID:lE4/XlkX だよね？
>>738 > おれは同じ意味で使ってるし、
それは勝手にしてくれ、どうせ人の言うことを聞かないだろうし
> 世界の技術者もそうだから
妄想乙w
>>739 単発IDのくせにいなきり「お前」かよ。GWはほんと口の聞き方も知らないリアルクズ野郎ばかりだな。
おまえのような礼儀も知らず妄想しかできない低能クズに寛容なるおれ様が特別に教えてやろう。
違いますよ^^ 礼儀を知らない馬鹿は二度とおれにレスすんなw
同期とアトミックと排他制御が同じとは
ヤバいのがいるなこのスレ
ソフトウェアの基礎を学んだ方が良い
個人的に並列化処理といえば、例えば2coreの場合、
double buf[1024];
の内の、0-511 までを core1、512-1023 までを core2で処理するものだと思っていた。
atomicであるかどうかを気にしている人は、
buf[0] を core1とcore2で
[core1]
for(・・・) {
buf[0] += 1.0;
}
[core2]
for(・・・) {
buf[0] += 1.0;
}
みたいに同時に書きこみたいと思っているの？？？？
でも、atomicというのは、書き込みのみ、または、読み込みのみ、のどちらかの
場合だと適用できるけど、↑のコードの場合、+= 演算子は、直前の値を読み取ってから、
1.0 を足して、同じ場所に書きこむ動作をするので、いくら、double値の書き込みが
atomicであっても、結果はめちゃくちゃになるよ。
>>741 - std::atomicの使いどころを理解してない
- "OS"の同期プリミティブを使えと主張 (なぜOSと限定？)
この二つの条件を満たす別人が現れる確率は結構低いと思ったんでね
非礼の詫びとしてatomicの使いどころ知りたかったら教えてやるけどどう？
>>743 そんなraceばりばりの例だめにきまってんじゃん
単純に一方がwriter、他方がreaderでもatomic性は必要でしょ
>>743 > atomicであっても、結果はめちゃくちゃになるよ。
+= の話はレイヤーが違う
2 threadで元々0.0の変数に各々 += 1.0を10回実行した時に結果が20.0増えないことがあるって言う話をしてるんだろうけど結果は1.0~20.0に範囲になる
>>611のは浮動小数点フォーマットとして正しいかどうかもわからん
std::atomic<double>はoperator+=ないね
>>746 >>611のは浮動小数点フォーマットとして正しいかどうかもわからん
それも、個人的には分かっているつもり。
>>745 >単純に一方がwriter、他方がreaderでもatomic性は必要でしょ
確かに必要だね。
でも、個人的には具体的にどういう利用例があるのか分からない。
>>748-749 書き込みスレッドが書き込んでいるデータを読み出しスレッドが読み出して表示する
とかの場合アトミックでないと不正なデータを表示してしまう
計測器等でありがちな処理だよ
>>749 一番原始的なスレッド通信
>>743 複数命令を使って事実上アトミックに出来るCPUもあるし
整数ならアトミック加算出来る命令があるCPUもある
ARMやMIPSは前者、x86は後者
C++に限ったことじゃないかもしれないんですけど質問させてください
typedefで型に別名つけることについてです。今いじってるコードでたとえばvector<animal>にanimalsって型名をつけるようなのが山のようにあるんです
これすごくわかりにくいなと思います。例えばvector<animals>で宣言されてればその変数にどんな操作ができるのか一発ですが突然animalsで宣言されても何ができる型なのか初見では分かりません
別名をつけることがメリットになることってあるんでしょうか
メリットは君が言ってる通り特定の言語に限った話では特定の回答は出て来ないし
言語を取り巻く環境(エディタや統合環境や諸々)でも答えは変わってくる
>>752 using animals = std::vector<animal>;
わたしも、こういう typedef はしない方ですね、リッチなエディターを使っていないせいかもしれません
書いた人は別名を細かく付けた方がいいと考えているようですが、こういうのは記述の粒度の問題かもしれませんね
>>752 例えば後からvectorじゃなくてlistにしたいなーと思ったときに修正箇所が一箇所で済む
>>752 書くのが簡単になり、見るのも分かり易くなることがある。
また、animal_s とちゃんと最後に複数形を現す「_s」を付けるという
自分なりの命名規則を付けておけば、vector<animal> のことである
こともすぐに分かる。
>>757 なお、型名は小文字ではなく、Animal か、CAnimal、TAnimal のようにするのが慣例。
vector<Animal> の場合、AnimalVector とすると、書くのも理解するのも楽になる。
templateのままをコード中に大量に書くとわずかな書き間違いで変な動作になりかねない。
>>758 templateは、C++の中でも最も複雑で、書き間違えたときのエラーが理解しにくい
とされる部分。
だから、vector<Animal>とコードのそこかしこに書きまくるのはお勧めしない。
それと、<や> は、キーボードの配置からして打ち込みにくいという事情もある。
指が届きにくい場所にあるというか。
また、vector<Animal
と> を書き損じたような場合、>を探してコンパイラが変な場所でエラーを出して
しまい、どこでエラーが始まったか探し出すのに苦労するようなこともある。
だから、このような「組み立てられた型」は、毎度毎度そのまま使うと痛い目に
遭う可能性があるので、animals と typedef した人は賢い。
>>744 レスするなと言ってるのにほんと人の話を聞いてないな。だから別人だって言ってるだろう。
std::atomicの使いどころってstd::atomicの話題に一度もレスしてないし、std::atomicの話を振られてもいない。
しかもOS限定とか妄想そのもの。
> OSの同期か適当な同期ライブラリ使え。悩む余地なし。
と最初に言ってる。逆にキミのその発言で、キミは今まで禄にコードを書いたことのない糞ガキの学生ということがよくわかったよ。
仮にOS提供の同期機構かstd::atomicかという選択であっても1nmもstd::atomicの選択余地はない。0%だ。
枯れてないライブラリは論外。同期バグはOr****やIntelでもやらかすし、枯れてるほうを使う。
何十年もカーネル開発者が注力し、コキ使われてきた実績のある同期コードを選ぶのがまともな社会人。
キミのような無責任な子供やテストしないOSSな人じゃないからね。OS提供がなくても同じ。
組み込み系ならチップメーカーが提供する同期ライブラリを使う。
命名規則は、animals よりも、
vector<animal> の時には、AnimalVector
list<animal>の時は、AnimalList
とするのがお勧め。
最後の s だけだと、見落とす可能性があることと、集合体であることだけは
分かっても、それが、どんな種類の集合体かまでは分からないため。
もうひとつ、vector<animal> より、AnimalVector とした方がいい理由は、
正規表現検索する場合のため。
正規表現だと、< や > は何らかの meta 表現的な意味を持っている場合があるかも
知れないので、型名は単純な alphabet 列の方が何かと便利。
>>761 vector から list に変えるときに、名前もいちいち変えないといけないのだったら、その命名ルールは今いちですね…
Animalsの話題はわたくしがC++最大の謎と呼ぶvector継承不可問題だ
Javaだと「class Animal extends ArrayList<Animal>{」とできる
でもC++だとvectorそのものの継承はデストラクタの関係で認められていない
つまりクラスを作るかtypedefするか、C++には2通りの解決方法が存在する
別にvector継承してもいいんだよ
protectedかprivate継承する分には何の問題もない
役には立たないけど
いや、vectorは今となっては継承すべきでないってこともないだろ
vector<>のデストラクタが仮想でないのは仕様の欠陥ですか？
注意深さに自信があるならデストラクタが virtual でないクラスを public 継承しても
それ自体は言語仕様には反しないけど、人間は間違うのでな……。
>>768 private 継承した上で外部から呼び出しを許すメンバ関数は using すればいい。
役に立たないということはないと思う。
基本的なことだと思うけどよく
よくあるイベントループってどうやったらシンプルかつMT安全かつ効率的に実装できる？
次のような条件で
- qeueuが空ならwaitする
- qeueuにイベントが追加されたら直ちにおきてdispatchする
- dispatchに長い時間かかることもありえる
- add_eventは可能な限り短い処理で完了する。
- stopがよばれたらloopから直ちにぬける。dispatch中の場合は終わってから抜ける。
次に雰囲気コード書きます。
loop()がこれではいかんのはわかってるけど、どうすれば簡潔に書けるのかわからん
他にもあやしいところがある気がする
bool running = true;
std::deque<int> unsafe_queue;
std::mutex mtx;
std::condition_variable cond;
using unique_lock = std::unique_lock<std::mutex>;
void stop() { running = false; }
void add_event(int i)
{
unique_lock _(mtx);
unsafe_queue.push_back(i);
cond.notify_one();
}
void dispatch(int) { /*do something*/ }
void loop()
{
unique_lock lock(mtx);
while (running) {
cond.wait(lock, [] { return !unsafe_queue.empty(); });
auto ev = unsafe_queue.front();
unsafe_queue.pop_front();
dispatch(ev);
}
}
まずconcurrent_queueを持ってくるなり作るなりして用意した方がいいよ
イベントループにロックやイベント混ぜて書くとわけわからなくなる
concurrent_queueは必要ないと言うかこの用途だと無駄な処理増えるだけじゃね
>>773 BlockingCollection使えばいいだけじゃねーの？
>>774 それ、イベント発行しないと止まらなくね？
>>775 concurrent_queueって標準であります？どれのこと？
MT安全なqueueクラスを作ると
イベント待ちしてるときのstopで即終了が面倒かなと思いました
>>779 そうなんですよね
runningのチェックって一回のままで実現できないですかね？
>>778 BlockingCollectionってどこにあります？
ぐぐったらC#のクラスは見つかりましたが
上に書いた通り、stop時の処理がまわりくどくなりそうなのを気にしてます
実行時のロジックがシンプルなやり方を追求したいです
>>782 > BlockingCollectionってどこにあります？
> ぐぐったらC#のクラスは見つかりましたが
触れちゃ駄目な人だったか…
普通は終了を意味する番兵オブジェクトを用意するんじゃないの
キューの中身を最後まで処理して欲しいなら単に番兵を積めばいいし、無理矢理終わらせたいならキューを強制的に空にしてから番兵放り込めばいい
>>784 なるほどそれだときれいに書けますね
runningフラグは不要にできると
しかしわりとクリティカルな処理を想定してるので
stopを呼ぶスレッドで(イベントオブジェクトの)解放処理が起るのは問題に
なるかもしれないです(例ではintですが実際はもうちょっと凝った構造体)
runningフラグ前提だときれいに書けないですかね？
こんなんでいいのでは。running2回チェックは避けられそうにないなあ。チェックよろ
start() {
{
lock()
running = true
}
run(loop)
}
stop() {
{
lock()
running = false
}
notify()
join()
}
loop() {
lock()
while(true) {
cond_wait(!empty() or !running)
if (!running) {
break
}
pop()
}
}
スレッド動作トリガーはcond 1個にして
スレッド内で、キューやrunningフラグを見る
Windowsみたいな高機能な同期が有れば
イベント、タイマー、ファイルアクセス、ネットワーク通信
などなど色々な物を同時にトリガーに出来る
linux系はその辺が貧弱
スレッドを動かす為のスレッドが必要になったりする
>>788 全部selectやepollでまとめて待てるけど、winはもっと高機能なん？
>>786
インデントつけました
void loop() {
lock()
while (true) {
cond_wait(!empty() or !running)
if (!running) {
break
}
pop()
}
}
cond_waitの前にrunningみなくて大丈夫ですかね？
startの直後loopが始まる直前でstopが呼ばれた場合cond_waitって起きます？ >>790 違いは同期オブジェクトを含められるかどうかぐらいでは？
それ以外ならlinuxでもたいていfdになってる
少なくとも
>>788の後ろ三つは可能
イベントもパイプで代用できることが多い
>>791 cond.waitはブロックする前に一度条件式を確認する動きになってる。
条件式が初めからtrueであればそもそもブロッキングをしないからcond.waitの前にrunningをみなくても大丈夫だと思う
もうひとつ質問させてください
>>774 のrunningはstd::atomic_boolにする必要はあります？
C言語だとこの手の変数はvolatileにすると思うのですが
C++ならatomicでしょうか？
上の方でatomicのこといろいろ書いてありますがこの場合はどうなんでしょう？
void Foo::pushReq(const XXXReq& req)
{
EnterCriticalSection(&m_csec);
{
if (!m_bTerminate) {
m_requests.push(req);
SetEvent(m_hEvtNewRequest);
}
}
LeaveCriticalSection(&m_csec);
}
bool Foo::popReq(XXXReq& req)
for (;;) {
if (!m_bInOperation) {
// イベント待機
WaitForSingleObject(m_hEvtNewRequest, INFINITE);
if (m_bTerminate) {
return false;
}
m_bInOperation = true;
} else {
EnterCriticalSection(&m_csec);
{
if (m_requests.empty()) {
m_bInOperation = false;
// 今入っているイベントはbInProcess中に入ったもので
// 明らかに古いのでリセット
ResetEvent(m_hEvtNewRequest);
} else {
// 要求があればpopして処理
req = m_requests.front();
m_requests.pop();
}
}
LeaveCriticalSection(&m_csec);
if (m_bInOperation) {
// 処理すべきリクエスト有り
break;
}
}
}
}
ウィンドーズの同期APIの仕様により
同期API呼び出し時点であらゆる変数のメモリへの書込みとメモリからの読み込みが完了するので
とくにvolatileは不要
なはず、
>>795
>>786のようにrunningの更新をlockで保護するのであればatomic_boolにする必要はないと思うよ
void stop() {
std::lock_guard<std::mutex> lk(mtx);
running = false;
cond.notify_all();
}
お手本でも普通のboolを使ってる
https://cpprefjp.github.io/reference/condition_variable/condition_variable.html
https://cpprefjp.github.io/article/lib/how_to_use_cv.html >>799 loop()内のrunningは毎度メモリから読まれる必要があるので
C言語ならvolatileにすると理解しています
つまりループ内で最適化されてしまわないようにするためだと思います
これがC++だと仕様的にもともと問題ないのでしょうか？
逆に最適化がかかりにくくなってしまう気がします
ただ手元で実装したものは最適化かけていても確かに期待通り動いています
>>800 POSIX準拠のシステムでは同時アクセスを防ぐ書き方(mutexによるlockとかstd::atomicによるstore/loadとか)
をすれば自動的にメモリ同期(メモリへのフラッシュ)が行われる作りになっていてvolatileとかを気にする必要がないらしい
https://yupo5656.hatenadiary.org/entry/20040618/p2 >>800 >>774のコードの全体の当否はおくとして
while()の中でlockしているのであればlockされるブロックに出入りする際に
>runningは毎度メモリから読まれる
が実現されるからrunningフラグはvolatile無しでもむ無問題、
C++の標準的なlockの仕様は知らんがlockに出入りするときに
CPUのライトキューやリードキューに未処理のライトコマンドやリードコマンドが乗ったままだと
正しいロックにならないから普通のlockの実装ではメモリバリアを行う
メモリバリアはコンパイラに対してはイントリンシックな関数か何かとして定義されており、
それらの呼び出しのときコンパイラは空気を読んでレジスタに乗ったままの変数を放置しないはず…
（変数に対する副作用がある関数呼び出しとみなす
POSIXスレッドはetchになってからようやく使い物になった
woody以前は酷い出来だったのは酔い思い出
しかし以下のような実装のときrunningにvolatileが本当に要らないかどうかわわからん…
void bar() { (内部でlockを行う) }
====↓↓↓異なる翻訳単位↓↓↓====
void foo {
bool running = false; // runningはローカル変数
while (running) {
bar(); // 一見runninguへの副作用が考えられないシグネチャ
}
}
どうやっているのかは知らんが、ウィンドーズの同期系API（上の例でbar()にあたる）は
うまいことやってくれる（と思う！
>>801 というか、pthread や pthread 採用の C++11orlater で記述するのが普通です
volatile のみでなんとかするようなものじゃない
よく考えたら上のコードではrunningへのポインタを他のスレッドが知っていることもありえないから、
そういう意味でvolatile不要（最適化上等）か…orz
一方、runningがグローバル変数なら、異なる翻訳系で定義された関数を呼び出した後に、
runningは改めてメモリから読まれることはコンパイラが生成するコードの規定の動作なので
volatile不要
まとめると、runningがグローバル変数でありかつ同期目的の関数内でメモリフェンスしており、
かつそこが毎回通る限り、runningにvolatileは不要
>>804 running がローカル変数なら bar() での副作用は無理だから volatile の有無によらず foo() は空にできちゃうのでは？
（リロードしてなかった・・・）
>>806 つまり volatile が必要なケースは無いね？
>>808 多分、orz
計算機科学や実際のプログラムの実装は複雑怪奇なので、
病的な反例が何かあるかも((((;ﾟДﾟ))))ｶﾞｸｶﾞｸ
>>801 それはメモリバリアのことですよね
つまりCPU内のリオーダーの制御で
lockからunlcokまでメモリアクセスはその外にリオーダーされることがない
>>800 で気にしてるのはそれではないです
レスわけます
>>802
> >>800
> >>774のコードの全体の当否はおくとして
> while()の中でlockしているのであればlockされるブロックに出入りする際に
> >runningは毎度メモリから読まれる
> が実現されるからrunningフラグはvolatile無しでもむ無問題、
一度目はメモリから読まれるのは確実だと思います
ただループの場合、2度目のリードからはコンパイラが最適化をかけて
一度目の値を使いまわす可能性があると思います
void loop()
{
unique_lock lock(mtx);
auto r = running
while (r) {
....
}
}
と置き換えてしまう可能性があるのでは？ということを心配しています
私のC言語開発の経験ではこの場合はvolatileにするのが鉄則でした
c++のコンパイラはかしこくrunningは都度メモリから読み出すべしと判断していると
なるとその判定はどうやって行っているのでしょう？
一律にローカル変数以外はメモリから呼び出すわけではないと思います
(それだとかなり性能が落ちると思います) >>811 コンパイラ視点で見れば中身のわからないcond.wait()と言う関数呼び出しが
グローバル変数runningに対する副作用を持たない（値を書き換えない）ことの保証が無いから、
cond.wait()をループ外にくくりだす最適化が行われることは普通は無い。 --- （A）
また、ソースコード上cond.wait()を呼び出した後にrunningを参照する箇所があれば、
普通はかならずメモリからrunningを読み直すコードが吐かれる --- （B）
普通でない場合というのはコンパイラがcond.wait()メソッドの中身まで知っていて
runningに対する副作用が無いと結論付ける場合が考えられるが、
それでもcond.wait()の中で
(1) メモリバリアを行っており、
(2) その意味をコンパイラが知っている
限り、コンパイラが「（cond.wait()呼び出しによる）runningに対する副作用が無い」と結論付けることはありえない --- (C)
というわけで、普通は(A)、(B)が成立するからrunningのvolatileは不要
(A)、(B)非成立な変に賢いコンパイラでも、(1)と(2)が成立するなら(C)が成立するからrunningのvolatileは不要
>>811 ループは
>>791の方法で行くんじゃなかったの
>>812 それはstd:::condition_variableを使った場合に限定していますか？
基本的にpthreadのwrapperだと思うのですが、仮にコンパイラがそれを特別扱いしているとすると
pthreadをダイレクトに使った場合はどうなりますか？
あと客観的な文献を示してほしいです
>>813 そうですが別の話題なのでわかりやすく書きました
ただ
>>791 もイベント処理中はunlockしておく必要があったのでそこは変えました
>>815 それだと
>>811のコードでwhile(r) (あるいはwhile(running))ってなってるのがわからない
>>791だとwhile(true)の中でif(!running)ならbreakするって形でそもそもrunningは一回しか評価しないはず
>>814 >それはstd:::condition_variableを使った場合に限定していますか？
いいえ
>pthreadをダイレクトに使った場合はどうなりますか？
どう使うつもりかわわからんが、コンパイラに中身を知りようが無い関数の
呼び出しがループ内に生じる限り同じ話
>客観的な文献を示してほしいです
(1) 変数に対する副作用がある（かもしれない）関数がループ外にくくりだされないこと
コンパイラはソースコードをオブジェクトコードに翻訳する際、
ソースコードに書かれたアルゴリズム（有限ステップで終わる＆非同期要素無し）の
動作結果を変えてはならない。この原則はコンパイラの教科書に書いてあるし常識と言っても過言ではない
で、変数に対する副作用がある（かもしれない）関数の不適切な最適化はこの原則にひっかかる
(2) 少なくともMSVCがメモリバリアの意味を知っている根拠
https://docs.microsoft.com/ja-jp/cpp/intrinsics/readwritebarrier?view=vs-2015 これ、VS2010までは非推奨ではなかったし、サンプルコードも載っていたが無くなってたorz
>>814 標準スレッドライブラリを使った前後の読み書きについては、
ライブラリ関数呼び出し（ lock/unlock など）が提供するスレッドをまたぐ "synchronize with" 関係と
スレッド内での, "sequenced before/after" による前後関係とをつないだ
"inter-thread happens before" 関係（順序付け）に基づく挙動が規定されている。
https://timsong-cpp.github.io/cppwp/n4659/intro.multithread#intro.races-9 >811 のような書き換えは許されない。
規格化以前の pthread などをダイレクトに使った場合は
>>812 の挙げるような
「事実上問題にならない」に頼ることになり、これに volatile を加えても「事実上問題にならない」の
範疇であることに変わりはない。
問題の可能性が減ったり、実際に起こっていた問題の解決につながることはあっただろうけどね。
これについては「客観的な文献」といったものが無かったことも規格化の動機になっただろう。
https://isocpp.org/wiki/faq/cpp11#cpp11-specific-goals > - Machine model and concurrency ? provide stronger guarantees for and better facilities
> for using modern hardware (e.g. multicores and weakly coherent memory models). ...
>>817 なるほど
つまりc/c++コンパイラの最適化において、
副作用がある(pure functionでない)関数があると、それをまたいだ
リオーダーや値の流用をすることはない
当然メモリバリアを張るcond(pthreadも含む)は副作用ありなので
これがループ中に存在する場合はrunningは毎度メモリから読み出されることになる
ということですね
非常によくわかりました
>>817 しかし、この場合volatileが不要といえることはわかりましたが、
これはあくまで副作用あり関数の存在に依存しています
と考えると一般的にはvolatileはつけておく方習慣の方がやはり無難だと思いますがいかがでしょう？
(c++ならatomicに置き換えるとして)
>>818 ありがとうございます
ちょっとこれを読み解くのは難しそうですね・・・
あとでじっくり読んでみます
>>819 レジスタに載ったままな変数の流用はともかく、
リオーダーは副作用がある(pure functionでない)関数をまたいでも特に阻害されないんじゃね；
リオーダーの効果はプログラムの実行に関して普通の状況では透過的なので、普通の状況でコンパイラがそれをやめさせる理由が無い
普通でない状況としては
>>714みたく同一データに対する複数コアからの同時アクセスがありえるケース
（コンパイラが知りようが無い非同期事象が生じるケース）があるが、
これは（ユーザーコードかライブラリの）プログラマがメモリバリアを明示的に書き、
コンパイラが空気を呼んでその前後の変数の流用も抑止することで処置される
と思うが真実は知らん
気分としてはあくまで
>>800の立場であって非同期の問題に関してはノーコメント
事実として出来上がったプログラムが正しく動いているなら問題ないのじゃガッハッハッハ、
訂正orz
誤：
>>714 ==> 正：
>>774 誤：
>>800 ==> 正：
>>809 >>820 複数スレッドで共有する変数を読み込む以上絶対にlockなりatomicなりを使うわけだから必ず副作用あり関数が存在する
>>820 見かけ上の挙動が仕様通りだったらどうコンパイルしてもよいというのが言語としての基本的なルール。
https://timsong-cpp.github.io/cppwp/n3337/intro.execution 昔は並列実行に関する動作モデルの既定がなかったので、
既定にないことをするプログラムを書いたときに
最適化で除去されたり順序が入れ替わったりしてもそれは仕様通りだったんだよ。
volatile はプログラムとして書いてある通りのことを (たとえ観測できなくても) 実際の動作にも
反映させろというヒントをコンパイラに伝えるものではあるけど、
言語仕様の記述に用いられる抽象機械と実際の実行環境が完全にマッピングできるわけでもない
から volatile が具体的にどう影響するかってのは分からん。
言語仕様外のことをするときのために用意されていると考えてもいい。
つまり、ロックやアトミックまわりの仕様で規定されていることなら volatile を付けようが付けまいが
その通りになるし、既定されていないことなら volatile を付けても言語仕様として得られる保証は何もない。
処理系として言語仕様以上の保証を付けているということはあるだろうけど。
>>824 確かに、正しく排他制御しているのならばそれはいえそうです
volatileは簡潔に言うとregisterの逆の作用だね
volatileはコンパイラに、コード通り読み書きを行うコードを吐けと指示するだけ
CPUが勝手に順番を変えたりしないようにCPUに指示をする命令は別途行わなければならない
x86の場合は何もしなくて良い場合が多く
ARMの場合は追加しなければならない場合が多い
最近日本式のやつが再注目されてるじゃないか。
それは欧州式のやつのことじゃないか？
>>824 片方は書き出し、もう一方は読み出しだけなら排他制御しなくてもアトミックでありさえすれば大丈夫だし、そういう実装はそれなりにあるよ
可変長引数テンプレートから型の文字列を組み合わせて配列を定数化して取り出せるようにするために
以下のようなコードを書いたのですが、
template<typename ... ComponentsData> struct ComponentTypeGroup {
static constexpr std::size_t ComponentCount = sizeof...( ComponentsData );
static constexpr std::string_view TypeTexts[ComponentCount];
template<typename Type> constexpr void TypeGroupText( std::size_t _uIndex ) {
TypeTexts[_uIndex] = Detail::Nameof<Type>(); // 定数文字列を生成する関数です。
}
template<typename First, typename Second, typename ... ArgTypes> constexpr void TypeGroupText( std::size_t _uIndex ) {
TypeGroupText<First>( _uIndex );
TypeGroupText<Second, ArgTypes...>( _uIndex + 1 );
}
constexpr ComponentGroup(){ TypeGroupText<ComponentsData...>( 0 ); }
};
constexpr ComponentGroup()で「型指定子がありません」と出てコンパイルエラーが取れません。
何故このエラーが出ているのかがいまいちわからず、途方に暮れています。
誰かご教授いただけないでしょうか？
ComponentTypeGroupのtypoでなくて？
まずそのインターコンチネンタルホテルみたいな長ったらしい名前やめろ
古いコードの一時的メンテのため、stdとstd::tr1をC++11で混在させて使う話なんですが、
元々C++11以前のコンパイラ用に書かれた
using namespace std;
using std::tr1::shared_ptr;
shared_ptr<Hoge> hoge = ...
みたいなコードをC++11でビルドすると、C++11には std::shared_ptr があり ambiguous エラーになりますよね。
最初 share_ptr を std::shared_ptr ということにしてビルドしようかと思ったら、ところどころ std::tr1::shared_ptr と
フル宣言してあり面倒なことが判明。なので shared_ptr は std::str1::shared_ptr とみなす方針に戻りました。
なので using namepace std; を保持しつつ shared_ptr を std::tr1::shared_ptr としてビルドしたいんですが、
それって可能でしょうか? 例えば using namespace std; で std::shared_ptr を除外するようなことってできます?
古いコードを出来るだけいじらずビルドしたい、というのが一番のポイントですw
単に#include<tr1/memory>してstd::tr1::shared_ptrのusingを消すんではあかんの？
新しいコンパイラではstd::shared_ptrとstd::tr1::shared_ptrって同じものでしょ
>>836 using std::tr1::shared_ptrを取るとただのshared_ptrはstd::shared_ptrになります (using namespace std)。
すると今回の場合、
std::tr1::shared_ptr<Hoge> boge; // たまにちゃんと名前空間を使ってる宣言がある
boge = shared_ptr<Hoge>(new Hoge);
みたいなコードが駄目になるようですが。
std::tr1::shared_ptrとstd::shared_ptrはとりあえず名前としては違うんじゃないですか? 違うとコンパイラー
が認識しているように見えますが。
>>835 これで全部 std::shared_ptr になるんじゃない？
namespace std { namespace tr1 = ::std; }
>>840 > namespace std { namespace tr1 = ::std; }
おお、これで std名前空間の中に tr1 のエイリアスを定義できる感じですか?
結果 std::tr1 は ::std -> std を指す、と。
>>832 constexpr ComponentGroup()の返り値がない。
constexpr void ComponentGroup()じゃない？
コンストラクタの綴り間違えているんじゃね？
何れにしろconstexpr static memberをコンストラクタやメンバ関数内で初期化は出来ないと思うが。
やるならstatic constexpr member関数の戻り値で初期化するとかしないと
>>843 >>844 あ……すみません。
コンストラクタの綴り治せばエラー取れました(汗
ご教授ありがとうございました
namespace std { inline namespace tr1 {} }
#include <memory>
std名前空間に何かするのは基本的に未定義動作に繋がるのでやめようね
カラオケで自分が歌いながら録音したカセットテープを爆音でドライブしながら女に聞かすようなものだな
これどう？オレが歌ってんだけど？的な
>>846 どうもです、しかし自分の環境だとうまくいかないですね。gcc 5.4.0 です。
error: ‘shared_ptr’ is not a member of ‘std::tr1’
std::tr1::shared_ptr<Hoge> hoge;
^
とりあえず
>>840を試してみたんですが、やってみるとインクルードファイルが意外と多く、そのほとんどに
#include <tr1/なんちゃら> があり、これらを全て tr1無しにする必要が。
コンパイラーのフラグ等でtr1無しをインクルードするようなことってできましたっけ? うわーさらに脇道。
とりあえず上記を書き直すとした場合、変更量が増えるにつれ、やっぱ全部のファイルで素直にtr1を
全部置換したほうがいいんじゃないかという気が徐々に... っておい > 自分
>>847 御意。ちなみにstdは普通の名前空間とは違うということですか?
しかし namespace の使い方の勉強になりました。いやあ色々思い付かれてすごいです。
>>851 #include <tr1/～> も保持するなら、自分のソースツリーに tr1/～ を捏造して
その中に #include <～> と
>>840 を並べて書けばいいでしょ。
まぁ置換で済むならそっちだろうけど。
関数内で宣言した変数を途中でconst化したいときってどうやったらいいですか？
関数というのはこんな感じです
void func() {
int a;
～aの値を設定する百行くらいの処理～
～aを用いたメイン処理。途中で誤ってaを変更しないようにしたい～
}
aをconstで宣言しておいてaを設定するところはconst_castするというのはやりたくないです。
初期化用関数initializeを作って const int a = initialize(～); とするしか方法はないですか？
できればそれもしたくないのですが
&a にアクセスする権限を readonly にするとか
環境依存だろうけど
>>855 a に設定する値を求める処理を関数化して、その戻り値でconstのaを初期化する。
>>855 初期化用関数を作るのが嫌な理由は何？
外のスコープに名前を付けて置くのが嫌ということならラムダ式で済むと思うんだけど。
>>857>>859
関数作るのが嫌なのは、気分ですね。バカバカしい理由ですみません。
関数外に置くのが嫌でラムダ式は多用しているのですが、使うときはある程度まとまった処理をするときなので
初期化程度のことにラムダ式を持ち出すのは大仰な気がしてやりたくありません。
これまた個人的な好みで恐縮ですが。
（ちなみに
>>855で挙げた初期化処理が百行くらいというのは大げさで、概ね数行くらいです。）
どうしてもなら、こうだな
int a_;
//a_で初期化処理をする
int const& a = a_;
//aはconst
アホらしいけど、こんな手も考えられる
struct sample
{
int a;
void func() {
//初期化処理
std::as_const(*this).func();
}
void func() const {
//aをconst扱い
}
};
後半をlambda化すれば
aをコピーキャプチャしてmutableにしなければconstになる
GCC や Clang の拡張を使ってよいならこういう書き方は出来る。
void func() {
const int a = ({int a; a=1; a;}); // ブロック内で初期化処理を書いて値を返す
std::cout << a << std::endl; // メイン処理
}
たぶん
>>855 が考えている用途だとこれが一番楽なんじゃなかろうかと思うんだけど、
標準ではないってのはやっぱりネックになってくるな。
ポインタ使えばいいのに
const付きのポインタを宣言だけしといて初期化のスコープ内でアドレス渡せばいい
>>860 RAII教に入信しておとなしく初期化ラムダ関数を使うがよい
>>866 なるほど、考えてみれば参照型にすればいいんだ。
int a;
(a に対する初期化処理);
const int &a2 = a;
(a2 を読み取るだけの処理);
変数名として灰化の用にすればわかりやすいかもしれない。
物理学では、a0 は、a の初期値を意味することが多いので、学術的にも分かり易い。
int a0;
(a0 に対する初期化処理);
const int &a = a0;
(a を読み取るだけの処理);
>>871 誤: 変数名として灰化の用にすればわかりやすいかもしれない。
正: 変数名としては、以下のようにすれば分かり易いかも知れない。
a0がスコープから消えないのは片手落ち
どのみちトリッキーなことして読み手を混乱させることしない方がいい
単純にスコープを一画面に収まるぐらいに短くしろ
>>873 >a0がスコープから消えないのは片手落ち
言われてみれば。
処理を途中で止めて、変数とかvectorの中身を確認したりするソフト知らない？
>>873
以下のようにすればその問題も一応は解決する。
int a;
(a に対する初期化処理);
{
const int &a0 = a;
const int &a = a0; // 外の a とは別の a を宣言。
(a を読み取るだけの処理);
}
さらに
#define XXX(_x_) const int &_x_##0 = _x_; const int &_x_ = _x_##0
というマクロを導入すれば、
int a;
(a に対する初期化処理);
{
XXX(a);
(a を読み取るだけの処理);
}
でいける。 >>876 それがデバッガー。
IDEの中に入ってる。
>>876 Visual Studioに標準で入ってるよ
やはり大人しく初期化関数使います
いろいろとアドバイスありがとうございました
幅優先探索において座標によって侵入コストが均一でない場合に対応するためにプライオリティキューを用いて、
スタート地点からの総移動コスト値(int)を格納する2次元配列と、
それに対応するインデックスとなる座標を格納する構造体(POINT)で実装したいのですが、
ProgrammingPlacePlusというサイトのC++編の「標準ライブラリ」の第12章(priority_queue)のサンプルコードに習って、
使用コンテナがvectorの場合はうまくいくのですが、listにするとコンパイルエラーになってしまいます
int move_cost[256][256];
bool operator >( POINT a, POINT b )
{
return ( move_cost[a.y][a.x] > move_cost[b.y][b.x] );
}
//vector版
std::priority_queue< POINT, std::vector<POINT>, std::greater<POINT> > vector_prio_que;
//list版
std::priority_queue< POINT, std::list<POINT>, std::greater<POINT> > list_prio_que;
初心者ですみません
どうすればlistでも動作させられるのかご教示頂けませんでしょうか
>>881 vectorならokでlistはngというと、イテレータの種類じゃね？
vectorはランダムアクセス、listはバイディレクショナルという違いがあって
よく引っかかる要注意箇所だよ
priority_queueの内部使用コンテナとしては、vector、list、dequeは条件を満たしていると書いてあったので、できるはずだと思ったのですが…
priority_queueは、topメンバ関数で最も優先度の高い要素にしかアクセスできず、
自分で書いたソースでは添え字やイテレータによる直接のアクセスは行っていない
(メンバ関数も、.push .pop .top .emptyしか呼び出していない)のですが、
コンパイルエラーの表示では、ご指摘のとおりリバースイテレータがどうのと出ていました
error C2784: 'reverse_iterator<_RanIt>::difference_type std::operator -(const std::reverse_iterator<_RanIt> &,const std::reverse_iterator<_RanIt2> &)'
:テンプレート引数を 'const std::reverse_iterator<_RanIt> &'に対して 'std::list<_Ty>::_Iterator<_Secure_validation>' から減少できませんでした
'std::operator -' の宣言を確認してください。
これは内部的にイテレータの操作がされておりそこでエラーになっている感じなのでしょうか？
algorithmやxutilityの該当箇所を見ても難しすぎてわかりませんorz
>>864 例の奴ですね、ならば、ここはラムダ式の出番でしょう、ラムダ式を定義して即評価します
const int a = [](){int a; a = 1; return a; }();
私以外にもこういうのを希望する人がいるということで、安心しました
> priority_queueの内部使用コンテナとしては、vector、list、dequeは条件を満たしていると書いてあったので
それってどこ情報?
軽くググった限りだと、vector、dequeしか出てこないけど
Programming Place Plus というサイトで配布されていた オフライン版(2019-07-01更新版)の C++編の「標準ライブラリ」の第12章(priority_queue)に書いてありました
vectorの部分をdequeに替えたら問題なく動作したので、対応してるのvectorとdequeだけの可能性高そう
できゅーならできる、なんちゃって
>>886 そのサイトが取り違えている
https://cpprefjp.github.io/reference/queue/queue.html >要件を満たすものとしては deque と list
queue | Programming Place Plus C++編【標準ライブラリ】 第１１章
https://programming-place.net/ppp/contents/cpp/library/011.html >Container には、vector（第５章） や list（第６章）
＊＊＊
https://cpprefjp.github.io/reference/queue/priority_queue.html >要件を満たすものとしてはvectorとdeque
priority_queue | Programming Place Plus C++編【標準ライブラリ】 第１２章
https://programming-place.net/ppp/contents/cpp/library/012.html >Container には、deque（第７章） や list（第６章）
そこのサイト詳しくわかりやすく解説してくれているから頼りにしていたのですけど、間違いがあるとは残念ですね…
vectorは要素をずらしたりコピーしたりで実行速度が遅そうだと思ってlistを使いたかったのですが、
素人考えでしたかね
>>883 difference_typeって書いてあんじゃねえかよ
バイディレクショナルなイテレータは引けねえんだよ
つまりlistは使えねえってこと
priority_queueって内部実装がヒープみたいだから、
末尾にしか追加削除しないと思われるので、vectorで十分では
コンセプトがくればこういう悲しい出来事も減るのかな
縦10マス×横40マスの地図で幅優先探索を100回まわして時間計ったら、
vectorだと989ms
dequeだと904ms
で大差ないかんじでした
デフォルトのままvectorを利用していきたいと思います
アドバイス下さいました熟練者の皆さまありがとうございましたm(_ _)m
漏れは、2分ヒープを自分で作って、ソートしたりしたけど、
配列の[0]は使わず、[1]から始めると計算が楽なので、
親1, 左右の子は2, 3で、法則は親n, 子2n, 2n+1
コンテナの最後にオブジェクトを追加し、
それが親の数値より小さい場合は、
再帰的に親と交換していく (親子を交換)
再帰的に、親は両方の子以下の数値をもつ。
左右の子(兄弟)の大小関係は考慮しない
配列の先頭要素[1]をPopし、配列の最後の要素を、
[1]に持ってきて、そこから再帰的に、左右の子と比べながら、
子の数値より大きい場合は、入れ替える
ピッコロ大魔王は、これよりもさらに効率的な方法を言ってたけど
このアルゴリズムでは、deque のリンクは不要だろ？
親n, 子2n, 2n+1 で、メモリの場所が分かるのでは？
>>884 質問者はこの場面でラムダ式を持ち出したくないと
>>860 に書いてある。
どうして文脈を読めんのだ。
>>899 なるほど、n, 2n, 2n+1 番の要素に格納してゆくかんじですか、素晴らしいアイデアですね
自力での実装がどうしても必要になったら、配列で作るときのヒントにさせていただきますね
>vectorだと989ms
探索1回あたり10msもかかるのはちょっとおかしいだろうと思って見直したら、
ソリューション構成をDebugにして、「デバッグ開始」してるせいでした
ソリューション構成をReleaseにして、「デバッグなしで開始」にしたら、
探索1回あたり0.02ms弱に収まりました(vector使用時)
STLコンテナ使っててデバッグモードだと500倍も遅くなりうるのか…
ちなみにdeque使用時は0.05msでやや遅めだったのでやはりvectorを使う方がよさそう
普通の実装では、[0]から始めると、
親0, 左右の子は1, 2で、親1, 左右の子は3, 4で、
親n, 子2n+1, 2n+2、となり複雑
子3なら親は、(3-1)/2 = 1
子4なら親は、(4-1)/2 = 1.5 で、切り捨てて1
>>899 では、配列の[0]は使わない。[1]から始めると計算が楽
親1, 左右の子は2, 3で、親n, 子2n, 2n+1
子2なら親は、2/2 = 1
子3なら親は、3/2 = 1.5 で、切り捨てて1
呼び出し履歴で過去の状態に戻れるのは、記録してるからだし。
そういえばdeque使ってよかったって経験ないなぁ
heap構造ならvectorが速いよね
事前に適切なサイズでreserveしておけば再配置も起きないし
前後にニョキニョキ伸ばすような用途だとdequeが一番よ
複数のソース・ヘッダーファイルのセットから一つの動的dllは作れないのでしょうか？
>>909 ありがとん
1つのソース・ヘッダーのセットから1つのdllを作るのには成功したのですが、解説サイトも見つからず困っています
>>910 ツールチェインによって手順は違うけど、
ソースファイルがひとつであろうが複数であろうが特別に違うことはしないと思うんだけど。
何が困っているのかさっぱりだぜ
リンカでdllにするんだろ
複数のオブジェクトファイルをリンクすることになんの疑問が
BASICとかやってた部類の人間だとリンクの概念とかわからんかもね
そういう化石の人がつい最近いじりはじめた可能性もある
コマンドラインから使うときでもだいたいコンパイラドライバが
いい感じにやってくれるから細かなことまで意識する機会も
あまり無いしな。
昔は依存関係調べるメイクファイルビルダーみたいなの使ってたけど
今はそこら辺もコンパイラが全自動で全部やってくれる
なんかデジャブ…
つい数日前にもまとめてlib化はできるけどdll化できないって質問があったような…
>>912 おそらく本人は何も分かっていない、何が分かっていないか分からない、書いてあったことを真似るしか出来ない、ということなんだと思う。
40年前の子供向けBASIC雑誌ですら動的生成を当たり前のようにしてたのになに言ってんだか
C++は何十年遅れてるのってレベル。ゲイツ舐めすぎ。おまえらはジョブス以下。
プログラムからコンパイラ呼び出して動的ライブラリ作って呼び出せばいいじゃん
>>900 初期化時に別に関数やメンバ関数（メソッド）を立てたくない、という
>>860 の要望は、かつて私も体感した感覚であり共感を覚えましたので、失礼だとは思いましたが背中を押す意味もこめて敢えてラムダ式を推すことにいたしました
即時実行されるlambdaなんて
文法上殆んどblock変わらん見た目で、
最適化かければ性能上もblockと変わらんだろ
[&]{
}();
即実行ラムダのインライン展開って本当にやってくれるの？
もちろんプログラマとしては期待するところだけど本当に主要コンパイラがやってるか誰か検証してる？
>>925 そんなのアセンブリ出力するかobjdumpすりゃ確認できるだろ
msvcですらやっているよ
普通の関数コールだって呼び元が1箇所ならインライン展開する
そっかMSVCがやってるなら当然みんなやってるわな
サンクス
>>924 式しかかけない場所というのがあって、そういう場所では文では駄目ですね
set::insert()で警告が出るんですが、なんででしょう？vc2015です。
std::set<int> items;
items.insert(1); // ここで警告 C4800
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\utility(175): warning C4800: 'int': ブール値を 'true' または 'false' に強制的に設定します
C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\include\xtree(1823): note: コンパイル対象の関数 テンプレート インスタンス化 'std::pair<std::_Tree_const_iterator<・・・
>>933 メッセージ内容見ても全然意味がわからないです・・・
警告出ないようにするには、どう修正したらいいですか？
#pragma warning とかでなくて
std::set<int> items;
items.insert((int)1); //明示的キャスト
なんでintのコンテナにint突っ込もうとしたら型警告出るんだろうな？
やっぱMSVCってクソだわ
std::set::inster() の引数でbool型が優先されるのか。
どういうオーバーロードが作用してるんだろう。
誤; std::set::inster()
正: std::set::insert()
1文字での入れ替わりは珍しくないけど、2字ずれちゃったのは何故だ?
両手でタイプしているとタイミングのずれでそうなることがある
>>922 自分も同じです
複数の変数の同時初期化が必要な場合も、前はタプルを返してたけど
c++17の構造化束縛のおかげでずいぶんスマートに書けるようになったと思う
こんな感じで
int i = 2;
int j = 3;
const auto [m, n] = [&](){ return make_tuple(i + j, i - j); }();
make_tupleの代わりにforward_as_tupleを使うと推論がうまくいかないことがあるけどラムダ式だからそんなもんかな
C++17が現行規格で、C++14以前は廃止規格
ただし国内ではC++03が現行規格
合ってるでしょ
JISの最新C++規格はC++03相当の翻訳（誤字誤訳脱文多数）で、今もそれが日本国内の正式な規格
従うメリットはないです
ISO は国際的な性格をもつ機関で JIS は日本の機関だけど、
ISO の規格の全てが全世界で通用するわけではないし、
JIS 規格が日本国内だけの効力というわけでもない。
法律に反しない範囲で当事者の合意があればどんな規格だって有効だよ。
規格化活動の便宜のためにそれぞれが独立して活動してるだけなんで、
「JIS は」ならともかく「国内では」みたいな理解は誤り。
あと、「改正前」と「廃止」は別物。
よっぽど決まりを守りたくないんだね
そういう人を説得しようとは思わない
>>952 例えば、JIS が C++03 までしかない、からといって国内では C++11 or later が無効、というわけではないと思います
また「C++14 は廃止された」という言い方はそもそも変です
現時点で C++14 で記述するという「決まり」を立てて C++14 でソフトウェアを作成するとどんな問題が発生するのですか？
あなたのいう「決まり」とはなんですか？
C++03でもC++11でも何でも良い
空気を読んでコードが書ければ
組み込みだといまだにC++03の環境も多くあるから
C++03だけでも書けた方が良いし
C++14の機能を使ったコードが読めないのもマズい
#defineで動いていて評価も終わってるコードを
わざわざconstexprやインライン関数に書き換えるようなアホな事はするなよ
constexprはそんなバカコード修正するために在るものじゃないし
カチャカチャやらなくてもそのうちバカコードをAIが直す時代がくるさ
シンギュラリティは近い
#define N 100
#define square(x) ((x)*(x))
// 気持ちわる
>>955 プロの現場ではC++03以降が敬遠されてるところをみると、
その空気とはC++は便利なCとでしか使ってはならないということだな。
多くはJava、C#、Python、rubyで十分だし。
C++17には待ってましたという有り難い機能が色々あるのに
付いて来れない低脳に迎合するために使用禁止とか愚の骨頂だ
足引っ張るなぼけ
>>965 冗談はよし子さんw 待ってましたって自分で実装せずに待ってたの？ ただの低スキルプログラマじゃんw
C++はいつも十年遅れて標準化するから使われない機能満載だよ。
stringが必要とされたのはいつですか？ 実行時型情報が必要とされたのはいつですか？ マルチスレッドが使われるようになったのはいつですか？
キミは30年遅れてるんだよ。時代錯誤君。だから糞遅いJavaに簡単にシェア抜かれるんだよ。
構造化バインディングなんか自分で実装できるわけねえだろアホ
何も知らないやつが頓珍漢なこと言ってんな
それでプロとは笑わせるぜ
まあ、いるけどねHDDを指さしてメモリと言ったり
MTTR/MTBFを知らない「プロ」も世の中には
Javaって言うほど遅いか
競プロに最適化問題を競って解く分野があるが、Java使いで世界トップクラスの選手複数いる
>>968 まずは構造化バインディングの話をしようか。
キミはいつ頃この機能が必要になったのか、何の実装に必要になったのか詳しく聞かせてくれ。
そしてこの機能で今までどういった素晴らしいソフトを作ってきたのか紹介してくれ。
キミほどの優秀な技術者なら著名なプロジェクトを多数参加しているだろうしな。
>>971 おまえなんかにタダでレクチャーなんかしねえし
身バレするような情報を出すわけねえだろ
おまえ頭がパーだな
答えれないと知ってて質問してるからいいよ。キミはコードを書かない側の人だからね。
プロジェクトでコード書く人は絶対にこんなこと言わない。こういうことはコードを書かない素人が言うこと。
> 有り難い機能が色々あるのに付いて来れない低脳に迎合するために使用禁止とか愚の骨頂だ
> 足引っ張るなぼけ
> 足引っ張るなぼけ
> 足引っ張るなぼけ
>>967 よしこさんって書き込みたまに見かけるけど、なんで芳江さんじゃだめなん？？
>>970 遅くないよ。
C++の20倍速いってブログもあったよ。
構造化バインディングの話をしたいのに誰もそっちには乗ってこないんだなw
一体誰がこんな機能待ってたんだろう 言い出した本人は逃げちゃったし
>>977 別に話し合うことも無いと思うけど、何を話し合うの？
>>973 本当に何も知らねえやつだな
> 絶対にこんなこと言わない
目の前に当てはまらない者がいて
言う前から論破されている戯れ言だぜ
構造化バインディングは多値返す関数の使う側が楽になる
mapのループ記述も楽
>>979 お前いつもの煽るしか能のないアホだろw
いいから
>>971に答えられる範囲で答えてやれよ
ていうかプロを騙って何か良い事でもあんのかね
よっぼどアマチュアであることに強いコンプがあるんだろうな
最新の言語機能使う俺すげー
大人になろうぜおっさん
そもそも
>>965が言うありがたい機能って
>>967が言う自前で実装してた機能を自分で実装しなくて済むとかより楽に綺麗に書けるってものでしょ
なので
>>967のツッコミが意味不明
単に標準化がおせーよって言いたいだけ？
03至上主義もどうかと思うけどな
unique_ptrくらい使った方がコード品質も上がるよ
中身は子供の使える俺すげー君もうざいけど使えないことを言い訳する
>>984みたいな老害もそれ以上にうざいわ
constでRAIIちゃんとやろうとしたら構造化バインディングはありがたいのだが
技術職の不勉強は罪だと言っている
居直るやつはクズの中のクズだ
言語の文法の勉強なんで優先度低い
多くの場合大してソフトウェアの品質上がらない
(そもそも定量化できていない、可読性とかいうあいまいな個人の感想だけ)
そんなもんは枯れたころに導入すれば十分
↑は仕事で使う場合の話ね
趣味の人はご自由に
実際おれだって個人開発では17使ってる
優先度って、まるで他の勉強に忙しいような言い方だな
こんなところで下らない言い訳ばかりしてるやつが
いいからC++スゲー=俺スゲーしたいだけの馬鹿は黙ってろ
そうだね、忙しいね
computer vision系やってるから日々数学の勉強でいっぱいいっぱいだよ
c++の学習は特に頭いらないから週末気分転換にちょっとやる感じ
構造化バインディング使ったところで、認識エラーは1ミリも下がらない
根性で五万行組み上げたみたいなバカコードは嫌い
そんなのは女にもモテない
もっとスマートにこなすべき
見え透いた嘘ぬかすな
週末気分転換にちょっとやってりゃ
未だにC++03にしがみついているわけがない
もし本当にそうならC++には絶望的に向かないバカだ
C++11から何年経ったと思ってるんだ
週末は年に52回もあるんだぞ
ん？
＞未だにC++03にしがみついているわけがない
>>993で17使ってると言ってたようだが
てかもうちょい生産的な話出来んのか
仕事でも趣味でも都合の良いコンパイラ使えばいいだけの話
構造化束縛をマクロとテンプレートで実現するとかなら面白い話題なんだけどな(面白いだけで実用性があるとは言ってない
lud20250112135632ncaこのスレへの固定リンク： http://5chb.net/r/tech/1584975873/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「C++相談室 part150 YouTube動画>12本 ->画像>1枚 」を見た人も見ています：
・C++相談室 part154
・C++相談室 part153
・C++相談室 part152
・C++相談室 part137
・C++相談室 part133
・自営業 悩みごと相談室 16
・C#, C♯, C＃相談室 Part93
・自営業 悩みごと相談室 52
・C#, C♯, C＃相談室 Part95
・自営業 悩みごと相談室 48
・自営業 悩みごと相談室 45
・アパート経営なんでも相談室【135号室】
・【真剣相談】大阪市営住宅の浴室給湯器設置
・シーバスなんでも相談室 17©3ch.net
・【ハゲ】髪の毛の悩み相談室 in DQO【彡⌒ミ】
・アパートマンション経営なんでも相談室【152号室】
・アパートマンション経営なんでも相談室【150号室】
・アパートマンション経営なんでも相談室【137号室】
・アパートマンション経営なんでも相談室【151号室】
・【皇室】小室圭さん、｢解決済み」声明文 宮内庁に事前相談なし
・【皇室】眞子内親王殿下がお気持ち表明「結婚に向けて家族とも相談しながら進んでまいりたい」★9 [記憶たどり。★]
・【名古屋】いじめ相談も「報復」恐れ学校側は直接指導せず…中1女子が下校後に自殺 2月から教室に行かず別室で授業 [ばーど★]
・東京の梅毒感染者2400人超で過去最多ペースで増加…内訳は男性7割女性3割 無料・匿名の検査相談室を新宿や多摩地域に設置 ★2 [首都圏の虎★]
・【ガルパン】マライ・メントラインの勝手にお悩み相談室「困っています。全力で『ガルパン』を推すために私は何を為すべきでしょう」 [鳥獣戯画★]
・室井佑月「(日の丸マスク)謝罪し訂正したのだけど、お詫びしろ、という意見…。弁護士に相談…」 ネット「被害者面」「実害出てるけど？ [Felis silvestris catus★]
・荒らし相談室
・エイブル相談室
・不登校相談室5
・ハゲミン相談室
・船乗りなんでも相談室・10
・シーバスなんでも相談室70
・シーバスなんでも相談室85
・シーバスなんでも相談室92
・シーバスなんでも相談室71
・精神障害者の人生相談室
・シーバスなんでも相談室62
・アダルトの何でも相談室
・シーバスなんでも相談室39
・◎蟹座の子育て相談室◎
・シーバスなんでも相談室36
・Dr林のこころと脳の相談室17
・綾子88kg♪の恋愛何でも相談室★
・病巣院クルリのお悩み相談室
・必ず誰かがなんたら相談室 Part.3
・明るい悩み相談室 [無断転載禁止]
・苔 コケ 初心者なんでも相談室-4回目
・レポ神のピンサロ相談室 ©bbspink.com
・初心者の為のボート相談室 Part1
・鍼灸マッサージ質問相談室パート１7
・鍼灸マッサージ質問相談室パート11
・鍼灸マッサージ質問相談室パート１６
・【本家】船乗りなんでも相談室 22【内航船】
・【本家】船乗り何でも相談室 20【本元】
・【ﾉｰﾜｯﾁｮｲ】船乗りなんでも相談室 27【内航船】
・初心者優先デジタル一眼質問・購入相談室 53
・【スノーボード】初級者なんでも相談室 ☆6
・08070507787 ★ 真智宇 先生の悩み相談室
・（・３・） ぼるじょあの卓上相談室（・３・）
・初心者優先デジタル一眼質問・購入相談室 157
・初心者優先デジタル一眼質問・購入相談室 103
・初心者優先デジタル一眼質問・購入相談室 109
・■一級建築士設計製図試験相談室(180室)■
・■一級建築士設計製図試験相談室(183室)■
23:56:35 up 31 days, 10:20, 1 user, load average: 8.90, 9.10, 8.90
in 5.1383261680603 sec
@2.4628620147705@0b7 on 011213
|
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
@YouTube
