◎正当な理由による書き込みの削除について： 生島英之とみられる方へ:
C++相談室 part139 ->画像>2枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1538755188/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part137 (正しくはpart138)
http://2chb.net/r/tech/1535353320/ このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
http://2chb.net/r/tech/1530384293/ ■長いソースを貼るときはここへ。■
http://codepad.org/ https://ideone.com/ [C++ FAQ]
https://isocpp.org/wiki/faq/ http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
----- テンプレ ここまで -----
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured
>>2 あれは複数形のsのつもりだった。
個人的には、コードにおいては、aaa に対する複数形の s は、aaas と書かずに
aaa_s と書いた方が分かりやすいと感じることがあるので。
ただ、配列の場合は、複数形の _s を付けて、リンクリストの場合は、
list または、List を付けるようにしている。
今回の場合も、リストなら List と書いたほうがいいかもしれない。
意味で考えたら自動的に型は合うでしょ。
意味だけ考えりゃ済むことを二重にするのが思考の節約ってのがわからん。
一重で済めばそれに越したことは無い。
グダグダの設計をなんとかするのにはシステムハンガリアンも有用と思うけど、
まともな設計が出来てれば要らんだろ。
「英雄のいない時代は不幸だが、英雄を必要とする時代はもっと不幸だ」
>>5 ところで、あなたは巨大なプログラムを作った経験ある？
>>6 巨大なプログラムの一部を作ったことはあるので、
設計がまともなことなんてまずないことは知ってるよ。
>>5 たとえば、ポインタの場合の先頭に「p」が付いているだけでも、立派な「意味」になっている。
このような一般法則を用いないで、ポインタであるとう意味まで含めた変数名を
付けることは、基本的に不可能。
また、たとえば、名前の入った0終端文字列へのポインタを「pszName」という変数名を
付けているのは、かなり適切に意味を表していると思う。
「name」だけだと CString 型と 0終端文字列なのかの区別も付かない。
また、長いテキストの中の一部だけに着目した文字列の場合は、そのどちらでもないから
「psz」の接頭辞はつけない。
これにより、発見しにくいバグも減る。
>>5 決められたフォーマットでファイルにデータを書き込むような場合、コード中、
メモリ中のデータのポインタと、これから書き込む fseek するためのファイルポインタ、
サイズなどが「対」または「コンビ」のようになって存在することがある。
そのとき、接頭の、fpos、p、size、len などでそれらが区別できることはとても有りがたい。
その場合、
fposData1 = pData1 - pTop;
のようなパターンが現れるだろう。
それに加えて、同じではない微妙に違った関数化が難しいようなパターンが現れくることがある。
そういうような場合に、ハンガリアン記法は、とても重宝する。
正しいコードが、記法からだけでほとんど機械的に分かってしまう事も多い。
テンプレートじゃ使えないしもはやC時代の遺物でしかないわな
現代じゃ害悪
>>8 思考のレイヤが違うな。
やりたいことの意味をプログラムに落とし込んだ結果としてなんらかの型に収まるという考えでやってるので、
型が意味だと言われたら本末転倒な感じがする。
まあ型中心の方がわかりやすいってのならそれはそれでいいよ。
>>10 自分の場合は、自作テンプレートの中でも使ってる。たとえば、
TYPE m_data;
TYPE *m_pPrev;
TYPE *m_pNext;
xxx( TYPE *pPos ) {
・・・
}
などのように。
>>11 たとえば、floatをdoubleに変更したことはあるが、
BYTE 型を int 型に変えたりすることはまず無い。
16BIT時代から32BIT時代へ移行するような場合は、
変更したことはあるが、機械的に置換すればいいというわけではなかった。
32BIT時代から64BIT時代への以降においても、機械的に置換して
済むものではないと思う。
目で追っただけでカメラが視線を検知してどの変数を見てるか特定して型を表示してくれ
できれば脳に直接語りかけてくれ
ワード幅が変わってもWORDの意味を変えることはできなかったね
> 「name」だけだと CString 型と 0終端文字列なのかの区別も付かない。
型が知りたいときに宣言を見ないアホを救う必要あるか？
F12を押せば一発だろうが
>>8 > 「name」だけだと CString 型と 0終端文字列なのかの区別も付かない。
今どき0終端文字列なんてAPIに渡したりする時など以外には使わんだろ
ほとんどない例外事項に対処するためによく使うケースの効率落とすのはダメプログラマーにありがち
>>13 std::string、
Company等の自作クラス、
std::unordered_set<Company>みたいなテンプレ使ったクラス、
スマポなんかはどう命名してるの？
数十万行の他人が書いたソース・コードに一度でも溺れてみたらいいよ…
Cの頃はIDEに検索機能さえあれば、検索した結果をメモ帳にでも書きつけて行って簡単にコールグラフを作れた
なぜなら関数名はプログラムの中でほぼ一意とみなせたので、walk aroundの強力な指針となった
C++になったらそうでもなくなった
なぜなら関数名がオーバーロードされるようになった上に異なるクラスが同名のメソッドを持っているというケースが頻出する上に、
テンプレートやnamespaceまであるので
Cの頃から比べたら、解析の困難さは異次元のレベルすぎて草
現実的に解析を行えるかは、ソースコードの字面がどうかかれているかよりもクラスの意味が整理されているかに大きく依存する
もし仮に万が一、#if～#endifで切りまくられたソースコードで正しくメソッドの定義元や呼び出し元一覧がクラスがテンプレートの
仮引数として渡されているケースについても正しく信用に足る一覧が出るIDEならちょっと欲しいかも
>>27 それできないとコンパイルすらできないんだけど…
コンパイラ(とそのコードを書いた本人)以外の人が把握するのが難しくなったということだろ。
ADLやらSFINAEやらで実際にどこの何が呼ばれるのか、プログラム全体をひっくり返してみないと
わからなかったりするしな。
>>28 doxigenは、なんかブラウザで閲覧できるようにするまでの設定がめんどくさかった思い出
およびコールグラフは出たが本当にグラフの画像しか出ない（シンボルをコピペできない）のでｼｮﾎﾞｰﾝ、
だったのでそんなにやりこんで使っていないｽﾏﾝorz
それよかDOT言語が面白すぎたので遊び倒した
>>29 コンパイラのビルドとIDEのインテリセンス能力は関係ない（ﾊｽﾞ。LLVMは知らん
もし定義元を書き換えてエラーを起こせばエラーメッセージから呼び出し元がﾜｶﾙ、
という考えならテンプレートが絡んだ瞬間に目が眩んで死ぬ
>>31 > コンパイラのビルドとIDEのインテリセンス能力は関係ない（ﾊｽﾞ。LLVMは知らん
技術的には可能だって話
> もし定義元を書き換えてエラーを起こせばエラーメッセージから呼び出し元がﾜｶﾙ、
> という考えならテンプレートが絡んだ瞬間に目が眩んで死ぬ
そんなアホな発想するやつがいるとは思わなかったよ w
>>31 無知ですまない。
シンボルをコピー出来ると何が便利になるの？
>>10みたいなことをドヤ顔で言ってるド素人が多いけど
TMPにはTMPの一般的なルールがあるんだがな
ハンガリアンではないけど
templateの一般的なルールってtemplate引数で汎用的に使えるのはTとかそんな感じ？
標準にあるis_integral_vとかdecay_tとかのvやtもハンガリアンの亜種といえば亜種なのか？
それそれ
型と値は区別しやすいようにしてんだから考え方は似たようなもんだ
あと前スレ
>>986 エアプログラマが調子に乗るな
ドカタだろうが何も生み出さない素人よりよっぽど偉いわ
>>34 ドヤってるところ申し訳ないけどテンプレートにルールはないって言ってるやつはいないと思うぞ
頭大丈夫？
>>10は
>>9のハンガリアンの話でしかない
いつから一般的なルールだと思ってた？
ハンガリアンなんてなんの役にも立たないどころか邪魔にしかならないルールでコーディングしてたら周りから叩かれるだろ
ジジイしかいないところでやってるのかな
この板には底辺ﾄﾞｶﾀしかいないのがよくわかるわ
C++ｽﾚで底辺ﾄﾞｶﾀのｺｰﾃﾞｨﾝｸﾞ規約だけでもりあがってる
底辺ﾄﾞｶﾀがｵﾚんとこではこうだといいはりあってる
ｺｰﾃﾞｨﾝｸﾞ規約を守ってもらうのも当然だが
ちゃんといわれたとおりに適切に動くもん作りなさい
そっちのほうが重要だからな
底辺ﾄﾞｶﾀはこの部分がおもいっきり欠如している
>>40 こっちのセリフだよw
>>10が
>>9へのツッコミや反論に見えるのか？w
一連のハンガリアンの話でハンガリアンをくさしたいだけだろ(多分C++ coding standardsか何かの受け売り
ついでに
>>18でほとんどない例外事項とか言ってるが、
C++11からstd::stringがゼロ終端になったのは何でだろうね？w
エアプログラマと言われてカチンと来たのか知らんけど
お前に言ったんじゃねーから
どんだけナイーブなんだよ
むしろﾌﾟﾛｸﾞﾗﾏｰとか日本では最底辺のﾄﾞｶﾀだからな
なにいきがってんの
>>41 アプリハンガリアンならまだ役に立つよ
まあ適切な命名すりゃ事足りるんだけどね
ただ命名のスキルは将に知性に直結するんでね、玉石混淆なプロジェクトだと余計混乱したりする
>>45 土方だの何だのと罵っても、その土方が世の中を動かしてるんだよなあ
>>48 BOSSのCMっぽいね。
俺もそういう現場の人たちには敬意を表するわ。
△：土方が世の中を動かしてる
○：仕様どおりのﾌﾞﾂをきちんと作る土方が世の中を動かしてる
>>50 今どき設計とコーディングが別だと思ってるエア（）の人かな？
>>25
自分がやってるやり方だと、システム・ハンガリアンについては、
文字列(CStringでstrXxxx、0終端文字列で、szXxxxなど) と BOOL 型 (bXxxx)、
ポインタ(pXxxx)、についてだけ接頭辞を必ず使っている。
整数型、浮動小数点型については原則的には接頭辞を付けてない。
ただし、浮動小数点と整数を明確に区別したいときには、特に浮動小数点変数
についてだけは、「f」を付ける事があるが、float と double は区別してない。
int 整数についは、どうしても必要な場合は「i」を付ける場合があるが、普段は付けない。
今のところ、リストについては、接頭辞ではなく、接尾語のように、
XxxxList と付けているが、メンバ変数としては、
class CYyyyy {
・・・
CMyList<Aaaa> m_listXxxx;
・・・
};
と書くことはある。
配列の添え字は、idxXxxx、個数は、numXxxx、id 番号は、idXxxx。
最大値については命名に迷うことが多い。maxXxxx とすることもあるが、
numXxxx とは、「1」しか値が違わないことも多いので迷う。
新しく作ったクラスのオブジェクトについては、基本的には接頭辞としては
付けないが、どこか、変数名の一部でクラスが分かるようにすることはある。
たとえばの話、CPerson クラスのオブジェクトなら、person1、person2
などとすることが多い。 >>52 [続き]
自分で作った Tree クラスの template なら、それを使った Tree クラスの
オブジェクトは、XxxxTree という名前にすると思う。
>>25 それから、今のところ、std::string は使わずに、CString ばかり使っているので、
std::string と CString の文字列を区別する命名法は普段は考えたことが無い。
多分、std::string を、sstrXxxx、CString を strXxxx にするか、逆に、
strXxxx と、cstrXxxx にするかだと思う。
それは、どちらか好んで使いたい方を短くするように命名法を決める。
>>43-44 何をグダグダ言ってるのか知らんけどテンプレートにルールがないとか言ってるやつがいないのに
>>34なアホがドヤろうとして自爆しただけ w
>>25 >std::unordered_set<Company>みたいなテンプレ使ったクラス、
これは使ったこと無いけど、list の命名に習うなら、グローバル変数の場合は、
g_setXxx
g_usetXxxx
みたいな事になるかと思う。長すぎるのは困るので迷いどころ。
>>51 上の話の流れからすると単に「土方」と書かれると
「ちゃんといわれたとおりに適切に動くもん作」らない「底辺ﾄﾞｶﾀ」（
>>42）と区別が付かないから
補足の必要が認められた
あと下位の設計が（（特段の事態が生じない限り）上位の設計に従うのは
今日日であっても変わらないので、
>>51が設計とコーディングが完全に合一だとする主張だとするといいすぎ
>>55 図星ですって素直に言えばいいのに
メタプログラミングやったことも無いのにテンプレート云々を理由にして
>>10と同じように「今どき変数の命名法なんか要らん」と、ハンガリアンだけでなく
あらゆる命名法を全否定してたアホだろ？ｗ
受け売りばっかしてないで少しは自分のアタマ使えやボケが
あ、使うアタマも無いから受け売りしてんのか
>>58 だからお前以外は誰も一般的なルールの話なんてしてない
恥の上塗り乙 w
今週は一般的な命名法って何のこと？
ハンガリアンの話をしてるのにな
低学歴知恵遅れには
計算機のｱﾄﾐｯｸな型という概念がないからな
C++は低脳でも使える言語だが、C++使ってるから低脳ってわけでもない。
>>59 同じ事しか言えんのか？
お前
>>5を擁護してたろ？
あと型が知りたきゃF12押せって話もあった
（俺は別に型がわかるような命名を常にすべきとは思わんが）
彼らは型がわかるような命名法全否定してるだろうが
＞誰も一般的なルールの話なんてしてない
一般的なルールって何？TMPの話ならTMPでデファクトスタンダードになってる命名法がある、って話なんだけど
お前話について来れてもないだろ？
>>50 まさに問題の本質を逆説的に示している。
仕様どおり、仕様書の解釈に誤解の余地がないほどにちゃんと仕様書が書ける人が少なすぎる。
行間を読めない現業の人がいる限り、行間を読めという免罪符は通用しない。
それを何だかんだ言っても実現してくれる(一部の)エンジニアはすごいと思う。
やはり低学歴知恵遅れにはjavascriptが限界
もしくはさらに最底辺のｳﾝｺｽﾌﾟﾘﾌﾟﾄが限界
>>ﾄﾞｺｸﾞﾛ MM36-GL8C=ﾜｯﾁｮｲ aab3-GL8C
みたいなアホにはわからんだろうから補足すると、
メタプログラミングにおける”型”とは
・定数
・型
・テンプレート
これらのことだ
それらのうちどれであるかを示すような書き方は標準ライブラリでも普通にされてる（テンプレート・テンプレートパラメータの命名規則は見たことないが）
ハンガリアンの考え方と同じだろうが
（もう一度言うけど個人的には常に守るべきとまでは思わない、所詮可読性や一貫性・利便性のためのもの
>>65 > 一般的なルールって何？
自分の書いたことも理解してないのか…
> TMPにはTMPの一般的なルールがあるんだがな
そんな話してるのは オ マ エ だけ w
いや、そのテンプレートの話とハンガリアンを結びつけるのは無理ありますわ…
>>69 一部だけ抜き出すから意味わかってないんだろうなと思ってな
あと、反論になってない
>>65を100回読み直せ低能
なんにも分かってない低学歴知恵遅れの元ｳﾝｺｽｸﾘﾌﾟﾀｰが
分かった気になってC++さわると
必然的にこうなる
こっちのセリフだよ
>>41 ＞ハンガリアンなんてなんの役にも立たないどころか邪魔にしかならないルールでコーディングしてたら周りから叩かれるだろ
お前もどうせ受け売りだろ
>>65 > TMPの話ならTMPでデファクトスタンダードになってる命名法がある、って話なんだけど
そんな話をしてるのも オ マ エ だけ
他のみんながしてるのは ハ ン ガ リ ア ン な w
>>65の前半には反論できないの？
恥の上塗り乙 w
>>65 俺は
>>5 で命名法を全否定したつもりはないけどな。
システムハンガリアンというか、
>>4 の「型と意味の二重の思考」を批判した。
部分的にはアプリケーションハンガリアン的なものは有りだと思ってるよ。
型は当然に意味を表すために付けられる (べきである) し、
名前は (なんらかの命名規則によって) 意味を表すようにする、
結果的に名前が型を表すこともあるけれども、
一貫して「意味」で考えればよいだけというつもりだった。
意味 → 型、名前
で、
>>8 で「型は意味だ」ということが述べられていたので、
意味 → 型 → 名前
というつもりなら、中心に据えるレイヤが違うんだろうな (でもやってることはそんなにかわらん) ってことで、
な～んか腑に落ちないけどまあいいやという気持ちが
>>11 って感じ。
昔から仮想コンストラクタの使い道だけ思い浮かばないのですが、
何か有用な使い方ってありますか？
>>79 >システムハンガリアンというか、
>>4 の「型と意味の二重の思考」を批判した。
物理学において、「次元解析」なる手法が知られており、単位の辻褄を合わす
組み合わせを見出すだけでかなりの事柄が導けることが知られている。
それが丁度、「型と意味の二重の思考」に近い。
ハンガリアンで書いてみればいいだろ。
今まで名前考えるのにどれだけ悩んでたかわかるから。
サクサクかけるでえ。
>>79 微妙な整数型の違いではまった経験があると
お前さんの理想論より泥臭くとも現実的な対処の仕方を優先したくなるんだよ
>>79 ＞命名法を全否定したつもりはないけどな。
それはすまんかった
要するに記法に型を入れる必要は無いってこと？
まぁ型はちゃんと自分の目で確認しろよ、という考え方を否定するつもりはないけど
他人の書いた長いコード読んでると途中で忘れることもあるしなぁ
（特に数文字とかの短すぎるローカル変数名で長い関数書かれると地獄）
わかりやすけりゃ何でもいいんだけどさ
自分はテンプレートを理由にハンガリアンを否定するのは違うだろって言いたかっただけ
>>85 私の思想では変数名が型を表すこともよくあるということを説明したつもりが、
まるで逆に受け取っているのでどう説明すればいいかわかんないや。
これ以上の説明はもうしない。
>>88 システムハンガリアンには型だけでなく意味（というか用途）まで混じってることを批判してるんじゃないの？
いまどきハンガリアンごときで論争かよ。
間抜けだな。
日本人としての矜持はどこ行った。
今やるべきことはモンゴリアンの発表だろ。
作る人の板だぞここは。
この板は底辺ﾄﾞｶﾀしかいないからな
しょうがない
>>91 そろそろ働けよ…
能書きだけじゃ食ってけないって身に沁みたろ？
>>80 古来よりコピー作る(機能を提供する)のに使われている
>>80 フィルタ（固有の動作状態を持つ（←重要）ﾌﾞﾂ）のの配置や接続をユーザーがGUIで変更可能なフィルタアプリを作るとき使う
これは（部品）create()とclone()の両方が覿面に要る
イメージ的にはDirectShowのgraphEditみたいなアプリを考えたら良い
ユーザーがすでに書いた組み合わせフィルタ（A→B）を最終段にもう一発入れたいというときに、
今日日一般的で親切な操作インターフェースはワークシートにすでに描かれている（A→B）をclone()することである
フィルタが過去の入力履歴に依存するケースがあり、そういった記憶はフィルタのインスタンス固有なので、ポインタのコピーでは済まず、clone()である必要がある
（Visioみたいに単に部品の接続だけが問題なﾌﾞﾂなら、部品自体はポインタのコピーで済ませて部品間の接続情報を別途管理するという構成も可能だが、部品の動作状態が絡むとclone()止む無し
>>92,94,95
うーん、よくわからない。
純粋に
class A {
virtual: A() {}
}
のvirtual事なのですがその事を仰ってますよね？
"x* create()"と"x* clone()"が要る場合があるのは理解できるけど、
"x* create()"を実装するのにコンストラクタを仮想にする必要が無いような。
もう少しわかりやすくしてもらえると助かりますが、面倒でしたらスルー
していただいても結構です。ありがとう。
>>96 すまん。virtual constructer ってファクトリーメソッドの
別名というか旧い名前なんで其方の質問かと思ってたわ
>>97,
>>99 そもそもできてもどうやって使うんだ？
>>100 さぁ？80に教示した人でないとわからないかも
「昔から」とあるから、独自処理系なのかも :-p
コンストラクタはC++の構文上はvirtualにでっきない
抽象クラスx （Product）のx*を返すcreate()メソッドを何かのクラス（Creator）に設けたら機能としてはできる
Creatorが内部で実際の生成をサブクラスに委譲する場合は正にファクトリーメソッドパターン（のProductが抽象クラスのケース）になる
さらにその「何かのクラス」（Creator）まで抽象クラスにしたﾌﾞﾂがアブストラクトファクトリーパターンというやつで、もはや
ProductとCreatorが同じ抽象クラスであってもかまわない。
ここまでやって初めてclone()が抽象化できるすわなち「インスタンスの」クローニングを抽象化のうちにやれる
抽象コンストラクタとはﾌﾂｰアブストラクトファクトリーパターンかつProductとCreatorが共通の抽象クラスのケースを指す（のだと思う
※ 個人の感想です
コンストラクタの中でそのクラスのvirtual関数を呼んでも
基底クラスのが呼ばれるよな。
基本的にコンストラクタの中ではあんまりいろいろしないほうがいい。
元の質問主はデストラクタと間違えたのかな？
コンストラクタにvirtual付けたらコンパイルエラーだからすぐわかるだろうし
>>96に書いてるからそれはないだろ
最近コード書いてもみないで頭の中だけで机上の空論こね回すのが流行ってんだろ
初心者の間で
手を動かさずに脳内ですべてを完結させられたら、それはもう初心者じゃないだろ。
スーパープログラマの誕生だ。
「基底クラスのが呼ばれる」だと最基底のクラスの奴が呼ばれるみたいに見えるから突っ込まれたんでしょ
何を継承してようと何が派生してようと、あくまで自分自身のが呼ばれる
>>109 なるほど
たしかに基底でなくて自分自身が正しいな
HLSLのfloat4みたいに、xyzwでもrgbaでも扱える、
所謂エイリアスを実現するスマートな方法は参照でしょうか？
class float4
{
…
float x;
float& r=x;
};
>>17 CStringを使うのに「あのエディタ」以外を使うアホを救う必要あるか？
typedef char* A;
typedef A B;
typedef B C;
typedef C D;
typedef E F;
typedef F G;
G lpszOmanko;
型が知りたいときに宣言を見ないアホを救おうと一生懸命なアホの書くコード
>>112 >>115 ありがとうございます。
(A)VC++のプロパティ機能を使って、ゲッター、セッターを変数のように書く
(B)無名共用体
これらを試してみます。
無名共用体でもっともスマートに実装できました。
class float4
{
…
union{ float x; float r; };
union{ float y; float g; };
･･･
};
ありがとうございました。
float f4; float3 f3 = f4.ayx; が難しいみたいな話かと思った
>>119 swizzleは(A)で対応できました。
class parent {
public:
void disp() {
cout << "parent\n";
}
void disp(char* str) {
cout << str << "\n";
}
};
class child : public parent {
public:
void disp() {
cout << "child\n";
}
};
disp(char* str)を呼び出すにはどうすればいいですか?
Boland C++ Builder 5を使用していたのですが仮想コンストラクタ
でコンパイルできませんでした。失礼しました。
VCLライブラリのTGraphicなどのヘッダーが仮想コンストラクタで記述
されていたのでてっきり仕様で認められている物だと・・。
このライブラリ(というかBuilder)だけ特殊ということで理解しました。
皆さんありがとうございました。
try __finally も使えて糞便利なんだよなアレ
>>121 引数にconstつければ、"文字列リテラル"も渡せる。
引数なしのdispをオーバーライドしたから引数ありの方が隠蔽されたとかかな。明示的にusingしてみては？
void disp(const char* str){
cout<<str<<\n;
}
virtual void disp(){
disp(“parent”);
}
void disp(){
disp(“child”);
}
124の言う通りconstつけろという話じゃないかな
class parent {
public:
void disp() {
cout << "parent\n";
}
void disp(char const* str) { //added: const
cout << str << "\n";
}
};
class child : public parent {
public:
using parent::disp; //created
void disp() {
disp("child"); //changed: cout -> disp
}
};
clangの開発に携わりたいと思ったのですが、C++で書かれていて、テンプレートの理解も必要だし、簡単ではないですよね？
clangの開発って、LLVMのチームに入りたいってこと？
だとするとC++のスキルは世界的な有名人になれるくらい凄腕でないと厳しいだろうな
gnuの連中と真っ向やり合って勝とうって話だぜ
少なくとも、おまえらではゴミにすらカウントされんだろ
バグの指摘だとか、
ドキュメントの typo を直すくらいの役にはたてるかもね。
ただ、自分のミス (未定義を踏んだとか) ではなく
コンパイラのバグであると確信をもって主張するには、
規格をかなり把握しておく必要は有るので、
それだけでもなかなか大変だ。
真のJava scriptがあればいいと思うのだが。
至る所に try catch を書かなきゃいけないスクリプト言語か
最近Java触ってないんだけど
あの検査例外指定を必ず書かされる糞仕様はまだ残ってるの？
>>135 どっかの日本人が規格書だけ必死に読んでる間に
世界のプログラマは言語気にせずに必要なアプリ作ってるけどね。
そういうとこだよ。
>>135 コンパイラのバグ報告くらいなら、別に規格理解してなくても
ググったりメジャーなコンパイラで動作比較したらわかるけどな
さすがにコンパイラの開発に携わるなら規格読まないとダメだろうけど
より詳しい人が精査するという前提でとにかく目を増やす、
おおざっぱでもバグを発見する目になるというのも悪いわけじゃないしな。
開発メンバーが少ないならそういう雑多な情報は嫌がられることもあるかもしれんが、
CLANG 級のソフトならそれなりにきちんとした開発体制は出来てるだろう。
バグ探しとかそういうレベルじゃなく
今なら並列に重きを置く最適化とかが勝負だろうが
>>128は開発に携わりたいと言ってるのに、一人が無理と言い出し、多数バグ探ししか無理と言い
誰もアドバイス出来てないところが面白い
ム板で返す言葉に事欠いて人格批判か
会社にも、論文に人情論を書くようなアホはさすがに少ないな
>>144 本人が簡単ではないと思ってるから、 (割とハードルが低く) 出来ることもあるとアドバイスされている。
>>148 まあ新型のゲーム機のバグを見つけてネットで大騒ぎするというアドバイスは、本人は望んでなさそうだけどな
何言ってんだこいつ
俺は
>>128への直接の回答じゃないけど、単にコンパイラのバグ報告ってそんな敷居の高いものではないよ、と
言っておきたかっただけなんだが
話の腰を折るようで悪いが
128が言っているのがclang自体の開発かどうか
まだ仮定なんだが
スマートポインタの中身ぶち壊して他のアドレス与えて使いますことってできる？
>>153 代入したら、元の生ポインタはいつ消えるの？
>>144 > 一人が無理と言い出し
まあ務まるような奴ならこんなところで質問しない
>>154 「消える」って言葉で何を意味してるのかがわからない
ポインタは消したりできるものではない
ポインタが指している先のインスタンスがデストラクトされるってことなら、
代入なりresetなりした時に前のをdeleteする必要があればdeleteされる
foo * p = new foo;
unique_ptr<foo> q(p);
みたいなときに q に何かして p に nullptr が入って欲しいならそれは無理
最近、gccを8.2にアップグレードしたのですが、
行列ライブラリGLMの最新版を使おうとすると、
std::log2他幾つかの数学関数(cmath)が未宣言とか言われてエラーがでます。
＃代わりに::log2を使えとも
ネットを調べてみると、
「log2等はC99以降の追加なのでstd名前空間には入らない」
等のコメントが見つかったのですが、
ここら辺の真偽について教えてください。
仕様的な真偽以外にも、
1. 他のOSのg++8.2以上でも(自宅はFreeBSD10.0)でも同じなのか？
2. コンパイラオプション等で制御する方法はあるのか？
についても情報を求めています。
追記：
-std=c++11でも-std=c++17でもダメでした。何故？
>>157-158 ありがとうございます
勉強します
namespace std{
#include <math.h>
}
>>159 言語仕様的には C++11 で std::log2 は追加された。
なので、 C++11 以降なら cmath を include していれば std::log2 を使うことは出来る。
C++ は C が提供する関数は基本的に使えることになっていて、それらは std 名前空間に属するが、
C++03 の時点で想定していた C は C90 のこと。 なので、 C++03 には log2 は無かった。
ただ、環境に C99 用の math.h があればそれを include すれば (C++03 の仕様には無いが) std 名前空間に属しない関数として使えていた。
>>163 ふむ。ネットで調べた上での仕様的な解釈はだいたい正しかったみたいですね。
gcc 8.2.0で-std=c++11以降つけても使えないのは単なるバグなのか機種依存なのか……
>>165 どっち？
- GLM を使おうとするプログラムで std::log2 が未宣言というエラーになる
- cmath を include したどんなプログラムでも std::log2 を使えない
>>165 gcc -std=c++11 -pedantic かも
-pedantic は拡張機能を無効にするオプションなので、
紛うことなき C++11 の機能である std::log2 に影響しそうにないと思うけど……。
gccがバグってる派と規格がバグってる派の争いが勃発するのでは。
今のgccは-std=c++14がデフォだろ
7.0以後だっけ
一応ISOへ意見を言う機関(日本NB)で意見する権利くらいは持ってるんじゃないの
range-based forでADLが効くことにすべきか否か
不特定多数に意見を請うてたな
奴は反対に傾いていたようで
俺とは見解を異にしていた
そうなのか。
江添さんもすごいけど、このスレの人もすごいね。
俺も江添とは見解が異なるわ
どちらかというとビョーンの見解に近い
>>175 へー。 ADL が使えないのなら、
std::begin と std::end の特殊化でやるってこと？
特殊化ってなんだ
ここで聞くよりググれよ、すぐ見つかるぞ
実際に発言権持ってるのってビャーネとGCCとかLLVMとかclingとかの中の人とその他お金出してる企業くらいだろ
>>166 宅環境で後者。
FreeBSD以外でgcc8.2使ってる人だれかいませんかね？
>>182 念のために確認するけど、コンパイル時のコマンドは g++ だよね？
たぶん
>>159 の書きぶりからすると、ちゃんと出来てるとは思うんだけど。
gcc コマンドに -std=c++11 を付けると C++ としてコンパイルはしてくれるけど、
サーチパスが gcc と g++ では違ったりすることもあるから、
ヘッダファイルを見つけられないとか標準ライブラリのリンクに失敗するとかいうことはある。
でも、ヘッダファイルが見つからないんじゃなくて、
ヘッダファイル中にあるはずの宣言がされてないっていうのがよくわかんないね。
実際に cmath の中身を辿ってみるしかないんじゃない？
cmathはM_PIが未定義とか言われてハマったことはあるな
これだな
#define _USE_MATH_DEFINES
めんどくセーからdockerでも使ってメジャーな環境でやればいい。
数学定数は標準に欲しいが言い出すとキリないからなあ
MSVCのかつてのマクロでひどい目に会ってるから定数を用意していなくて正解
min,maxの事だな。
マクロじゃなければいいんだろうということでstd名前空間にconstexpr変数ならどうだろう？
extern(C){
}
みたいに
#defineとかならまとめて
namespace HOGE {
}
に入れてしまえれば良かった
環境依存問題でしたが一応解決しましたので、軽く報告。
<cmath>内で
#ifdef _GLIBCXX_USE_C99_MATH_TR1
以下で囲まれた部分がばっさり切られていたので
/環境依存パス/bits/c++config.hを調べてみると、
#undefされていたのが直接の原因。
#defien ... 1
に書き換えてみたところ、
今度は<cmath>内の
using ::tgammal;他４行がエラーになりましたが、
どうもFreeBSDの<math.h>にはその４関数がない模様。
#tgammafとか引数違いの類似物はある
結局その４行をコメントアウトすることでコンパイルを通すことに成功しました。
GLM最新版も使えたのでOKです。
まあ思うところはありますが、
gcc派 vs 規格派 vs マイナーOS派の話になりそうなので解決とします。
#include <tr1/cmath>
だったら使えたのかな？
>>194 それは環境依存というよりそのあたりのパッケージを管理してるメンテナの手が回ってない感じでは……。
Linux に比べると BSD 系はだいぶん人口が少ないらしいし、そういうことも致し方ないのやもしれぬ。
g++ -std=c++17は試したか？
tr1だった関数がstd直下に来てるぞ
ドラクエ10プレイヤーからの質問。
死んでいるのに動けてしまう『死亡ラグ』
http://2chb.net/r/dqo/1539560522/ 改善の余地があると思えますか？
ドラゴンクエスト10の下請けプログラマーはC/C++の名人ばかりですよ？
>>198 猫耳猫オンラインを目指しているのでしょう
友人がドラクエ10プログラマーなんだけど、C/C++については何でも彼に聞くようにしている。
>>196 書いてませんでしたけど、パッケージじゃなくて全部ソースから./confugre以下ビルドして入れてます。
まあそのconfigureが「４関数足りないから切っちまえ」と判断した本人ですが。
私たち日本人の、日本国憲法を改正しましょう。
総ム省の、『憲法改正國民投票法』、でググって
みてください。拡散も含め、お願い致します。
C++がオワコンってマ？
Cの次に C++→C#→ほかの言語 の順番で勉強しようと思ってたんやが・・・
せっかく脱ニートしようと思ったのに水差された気分やわ
寝るわクソが
20年前からオワコンと言われ続けてるからオワコンが嫌いならやめた方がいいよ
C++11 以降、いろんな可能性があるように思えてきた
C++やるとか何プログラマーになるきよ。
つか、言語増やせばいいってもんじゃねぇぞ
まぁC++はちょっと別格にうざいけど、言語だけ増やしても役立たずの烙印だぞ。そんな言語増やすことに一生懸命になることより一つアプリ作れるほうが重要だわ。
だから、例えばJavaを使ってandroidアプリ開発できるとか。
要は言語以外にクラスライブラリやUIフレームワークの知識や経験を身に付けることに一生懸命頑張ったほうがいいと思う。
>>208 神は全盛時までのCだろ
無駄のない細マッチョ
思いつきでゴテゴテ重装備するC++やC99以後はそうじゃない
C++11はそれまでを反省はしてるけど重装備指向は変わってない
オワコンだとか安易な神だとか、そういう子供っぽい発送だとどうせすぐに飽きてやめるんじゃないかと思えてくる。
大丈夫やで
まず覚悟があるんや
ワイは死ぬまで趣味に生きると決めとるんや
それに動機もあるで
Android NDKでC++でもAndroidアプリ作れると聞いとるからな
ほんで一攫千金の大逆転や
いいかみんな、どんな新規格を使って作るかが目的じゃないぜ？
まあ使いたくなるんだけどね
>>212 装備にこだわってる人が多いみたいだけど
エラーメッセージをもっと判りやすくするべき
>>215 新しい機能はそれを使った方が良くなる (場合もある) から追加してるわけだし、
どういうときに便利なのかに慣れるためには最初は過剰なくらいに使ってみてもいいと思うけどね。
いきなり本格的に導入する前に実験的なプロジェクトで試すくらいはした方がいいかもしれんが。
以前は完全にbetter Cとしてしか見ていなかったが、STLとかBoostを積極的に使うようになってから面白くなってきた
>>220 稀によくあるw
理由は「他のメンバーが読めないから」w
いやまて、その真意は動的メモリ割り当てを減らしたい、かもしれんぞ
言語増やせばいいってもんじゃないけど、プロのプログラマなら一通りどの言語も少なくともアマよりは使いこなせるでしょ
必要なのは言語の多寡ではない
CS(Customer Satisfaction ではないぞ)への理解
標準ヒープ禁止ならSTL禁止にはなりうるだろうな
アロケータ指定すりゃいいけど結構不便だし
何が STL なのかっていうのは意見が分かれる部分もあるからなぁ。
便宜的に STL と呼ばれているものは仕様的には完全に C++ の一部で、
他の規定と区別するものは何もない。
Wikipedia にも簡単な歴史が書かれてるけど、
https://ja.wikipedia.org/wiki/Standard_Template_Library#%E6%AD%B4%E5%8F%B2 ここには「stringのようなその他のC++標準ライブラリの機能にも影響を与え」
とあり、 string 自体は STL ではないかのようにも読める。
でも、 string が STL の一部かというとだいたいの人は STL だと思ってるだろうし。
他の人が読めないからっていうのが理由ならテンプレート自体がもうダメってことなんかな。
STLってあくまで俗称やろ、定義は曖昧
俺も「読めないからテンプレート使わないでくれ」と言われたことはあるなぁ
PC向けなんだしSTLくらいは我慢してもらったけど
でも世の中標準のヒープ自体使っちゃいけない業種、結構あるやろ
コンシューマゲーム機も大抵そうやで
アロケータ渡せばいいって言われるだろうけど正直不便
つっても、そこそこの規模のプログラムだと
STL は使わないにしても
ちゃんとしたフレームワークを用意するやろ？
そうでもないのかな。 割と泥臭くやってたりするのかな。
>>215 当たり前
欲しくて欲しくて渇望してた機能がやっと来るのがC++だから
使いたくなるのは自明だ
X他の人が読めない
O無能が読めない
実際は多くがこうな訳だけど仕方ないよね
お勉強全くしない奴少なくないしそれに合わせないとだもんね
>>229 社内ライブラリはもちろんあるけど
検索機能を含むコンテナとなるとやっぱりSTLが楽なんだよなぁ
さすがに二分木やハッシュで検索、まで自社で作るほど
そういう用途に頻繁には遭遇しない
ほんとはそういう中小企業でPC向け、ってなったらそれこそ標準ライブラリには頼れよと言いたかったけどね
コンテナ禁止なのか、<algorithm>まで禁止なのかにもよるな
前者だけなら自前コンテナでもメンバー関数揃えておけばソートや探索は後者使えるし
ただ<algorithm>の中で本当にヒープ使ってないのかというのは
バカに合わせないとお前が一生メンテする羽目になるぞ
>>231 その昔、バカでも読める言語ってのが一世を風靡したね
そのお陰で、バカ人口が増えて生産性に比例しない人件費がうなぎ登りして
たーまやーとばかりに弾けた
ピンサロで嬢が知り合いだったときはマジびびった
>>227 >ここには「stringのようなその他のC++標準ライブラリの機能にも影響を与え」
>とあり、 string 自体は STL ではないかのようにも読める。
stringというかSTLって「標準」のくせに亜種がいっぱいあった希ガス
科研費余ってるんだが、C++ とかプログラミング関係の書籍で必読だったり面白いもの教えてくれませんか
Effective C++、ストラウストラップ、リーダブルコードくらいは持ってます
個人的には C++ Coding Standards 欲しかったが新品じゃ売ってないな
そら当然、STL策定直後は当時のコンパイラにはSTLは付いてきてなかったわけで
結構な数のサードパーティが追加ライブラリとして売ってたから
C++ 標準化委員の本
C++テンプレートテクニック 第2版、
επιστημη(えぴすてーめー)・高橋 晶、2014
C++11/14 コア言語、江添 亮、2015
>>238 付いて来た某MS標準のSTLが酷い代物でな
>>241 上と下は結構マニアックな感じしますね
真ん中は良さそうです
>>239 今回買わなくてもいずれ読みたいです
これにしても C++ coding standards にしても、需要ないんですかね
>>231 こういうこと言う奴に限って３ヶ月後には自分でも読めないクソコード書きやがるからな。。
>>224 趣味でやってる奴でも結構深いところまで使いこなしてる奴いるし
逆にプロは最新の機能とかをあえて使わなかったりするから一概にはなんとも言えん
>>237 ワイも D&E を推すやで。
C++ はツールやドキュメントの発展と足並みを揃えることで上手く発展してきたという話が書かれていて、
現実的な事情を踏まえた歴史の流れがわかる。
ただ綺麗にデザインした言語とは違う現実の重みを感じる。
(まあそれが負債になってもいるんだけど。)
単純に読み物としても面白いよ。
>>212 ＞神は全盛時までのCだろ
ライブラリは今でもずっと悲惨なままだと思いますです……
>>224 もちろん色々と使いこなせればそれが強みにもなるんだけど、
使ったことない言語やフレームワークを使ったプロジェクトにアサインされるなんてよくあることみたいだし、
そういうときに (使いこなせるとはとうてい言えなくても) 動くものをでっちあげる能力ってのも
それはそれで重宝されたりっていう話も聞くし、
どういう強みでやっていくかっていうのは千差万別なんじゃないかと思う。
C++17は和本だと江副氏の一択なんだけどあれは
そうなった背景とか使い道にはそんなに触れられてないのがな
逆引き辞典とか流し読みして大まかな把握するには便利だけど
>>249 プロ棋士の居飛車党が振り飛車指したからといってアマに負けたら恥だと思うが
「振り飛車指せないって言っても、居飛車よりはって意味や。君ら如き一間飛車でも勝てるで？」的な
「F# 書けないって言っても、メインで業務に使ってるC++よりはって意味や。君らよりは書けるで？」的な
（F# の部分にはマイナー言語が入るものとする）
プロ名乗るなら。
普段使わない言語なんて普通に読めて普通に書けりゃ十分だろ…
ドラクエ10の下請けプログラマーが精鋭揃いだということはわかりますが、こういう苦情が後をたちません！
534 名無しさん＠ｺﾞｰｺﾞｰｺﾞｰｺﾞｰ！ (ﾜｯﾁｮｲ 4910-binO [180.51.97.166 [上級国民]]) sage 2018/10/15(月) 09:26:17.41 ID:5tgKKwqc0
https://hiroba.dqx.jp/sc/forum/prethread/408523/ 移動速度が遅すぎてプレイする気になれない……
ぎのぎ
[GM468-320]
テーマ：操作性・メニュー 2018/10/15 09:17
こんにちは。ドラクエ10を始めて、着飾りもストーリーもたくさん楽しませていただいています。
ストーリーは進むたびにたくさん泣けて、ゲーム内容には大満足です。
しかし、移動速度があまりにも遅すぎて、ストレスが溜まってしまい、最近はゲーム自体から足が遠退いてしまっています。
ドルボードではまだ耐えられます。
ストレスになるのは、特に町のなかです。
以前の投稿で、早くなる料理はできない、とお答えしていらっしゃいましたが、移動速度が上がる装備はありますよね。
そちらの方がよっぽどあるのとないのと変わりそうですし、やりこみ具合で差が開く部分に思います。
時間設定のあるダンジョンなどもあるそうで、考慮するのは確かに大変そうです。
なんなら、素のスピードが変わらなくても構いません。町中だけでもダッシュ機能のようなものをつけていただけませんか？
ただ方向キーを押すだけの時間が、本当に苦痛なんです。
ストレスになるなら止めちゃいなｗ誰も止めないよｗ
>>255 プロは言語の機能を使えるかどうかでなんて勝負しない
書いたコードの性能、わかりやすさ、バグの少なさとかで勝負する
>>258 せやな
使うべきときにスマートに使う
これがプロだわな
RPGってあれだろ、IBMの作ったCOBOLもどきだろ、確かに時間の無駄だし戦車には効かんだろ
OpenCVのtemplatematchingについてなのですが、
しきい値を決めて類似度がしきい値以上の物を全探索で複数探すものはあったのですが、
類似度の上位2つのみを探す方法って無いですかね？
全探索は遅いので上位複数個だけ取れたらいいなと
閾値を適用するコードを探してチャチャっと改造すればいいんじゃね？
つか、最大値を求めるアルゴリズムも知らないのにOpenCVやってんの？
高速に判定できる軽量版データ(部分画像、低解像度、モノクロなど)がありうるなら
それで箸にも棒にもかからないものを高速にふるい落としてから
残ったものだけをちゃんと調べればいいよ
>>266は、閾値以上の値を全部取ってくる関数の代わりとして
上位n個(nは定数)を取ってくる関数はないか、ってことだろ？
> 全探索は遅いので
と書いちゃうから誤読されてそう。上位n個の場合でも全部見る必要はあるんだから
このゲームすぐ持ち物いっぱいになるな
http://2chb.net/r/dqo/1539336435/ 使い道のないアイテム（無駄なコード）が多すぎやしないか？
>>271 だよね。
全部閾値以下って可能性考慮しても、並べ替えて上位から閾値以上か確認しながら取り出した方が早いべ。
>>274 んじゃどうすんの？
最大値を見つけた後に、最大値省いたリストなり配列から次の最大値(2番目に大きい数)探すにしたって、最大値を省くために最大値が有った場所を覚えておいて、そこを削除するなりしないと駄目でしょ？
面倒くさいし、速いと思えないんだけど。
。。。。。え“
5番目の大きさまでさがすとなら、5個もelse if書けと？
任意の個数なら、毎回書き直しか？
アホかと。
バブルソートを知っていれば、任意個数でもいける。しかし、抽出個数を任意にすると、まあちょびっと遅くなる。
>>275 元の質問が2個取り出すだけだからそれを前提にしてたすまん
n個を取り出すならソートしないとだめだな
テンプレートの再帰を知ってれば遅くならずに任意個数いける。
元データをソートしなくても、結果用にn個のソート済み配列(flat_setとして提案されてるやつ)を用意して
そこに追加していきゃいいのでは。既に閾値以上のがn個集まってたら以降は最小のと比較して交換
>>281 n個のソート済み配列って、ソート済み配列を何個も用意してどうする。。。と言う言いたいこと分かるけど、書き間違いでおかしな事言ってるっぽくなってるっていうツッコミは置いといて。。。
閾値が在るんだから、先に閾値以上の物だけ別の配列に入れてソートすれば良いってのは確かに任意個数で一番速そう。
交換が発生する度にn個中の最小を検索する必要がある
閾値以上のを1回ソートとあまり変わらないような・・・データ次第か
全ソートして上から閾値見ながら、で充分じゃね？
選択部を工夫してもたいして効果なさそう
>>283 ソート「済み」配列なので最小は必ず端にあるから検索の必要はないよ
代わりに追加の度に二分探索をする
それをイメージしてもらうためにflat_mapって書いたんだが未策定のものは伝わらないな、うん
>>282 すまん、要素数n個のソート済み配列を1個、で
すみませんありがとうございます
ここに出てたの試してみます
>>283 正直、追加の話見るまで最小と交換って私も「？」になった。
要するに1回目はソート済み配列が無いので
>>282 をする。
要素を追加する度に、閾値以上かを見て、閾値以上ならソート済み配列で小さい順から二分探索して順番になる位置に挿入。
全要素1000で閾値以上が100とかなら、ソートするのが100だけだから、かなり高速化する。
追加もソート済みに入れるだけなので、遅くは無いし、次に取り出す事考えると(追加と同時にソート済みにしておく)、ソート済みから取り出すだけになるので全体として速くなる。
と言う考えであってる。。。と思う。
>>287 近くなったがまだちょっと違う
結果用の配列は要素数nしか確保しない。閾値以上が100個あってもn=2なら要素数2
で、元データを順に見ていって、3個目以降が見つかったら結果用の配列に入り切らないので
後から見つけたのが結果用の配列の中の最小よりも大きければ、最小のを捨てた上で二分探索した位置に挿入する
……というつもりだった
元データに後から追加があったら、みたいなことを考えて書いたわけではないです
std::upper_bounds とかで挿入位置を決めて挿入、
n個を超えたら小さい方を1つ切り捨てるって感じだよね
たかだか数件ならループで位置を決めてもいい
>>288 なるほど。
今全部分かった。
うーん。
それは任意の個数nと閾値以上の個数が近くないと、n個目以降が見つかる度に比較、探索、挿入を繰り返す事に。。。
データによりけりではあるけど、微妙。
>>282 は、イメージとしてはクイックソートの最初のピボットを閾値にして、閾値以下はソートしない様に変形させた感じ。
どっちがどうとかは、実測しないとなんとも言えなさそう。
>>291 そっちのが凄い。
任意のnーmまでの範囲だけクイックソートっぽくソートするのか。
最上位(m)からn位までのソートでおkじゃないか。
標準にstd::partial_sortってのがあってな
ほとんど中身を知られていないalgorithmさん
それは
>>282,
>>290,
>>292 書いた私の事だろうか。
そんな呼び名がつくのは光栄だけど、高卒で基本アルゴリズムしか知らないんだ。
その割には悪く無い処理を考えられたと自画自賛してたんだけど、やっぱ頭のいい人の考えるアルゴリズムは凄いね。
partial_sortなんてあったのか……orz
でもquickselectは元データを並び替えてしまうから
それができないならこのスレに書かれた方法でもいいけどな(負け惜しみ)
負け惜しみついでに
>>290の議論だが、mは元データの個数、nは欲しい個数として
>>282の閾値以上を抽出してから一括してソートは
最速のソートが使えるのでオーダーはO(m log m)、空間使用量は元データと同じ作業領域がいるのでmに比例
>>288(俺)のソート済み配列に追加していくのは
挿入ソートを小分けにしてるわけだからオーダーはO(m*n)、空間使用量はnに比例
nとmが近いかそもそものデータ量が小さければ
>>282が、そうでなければ
>>288有利かな
……で良いと思う
>>297 大丈夫、私も同じく沈んだw
純粋に貴方と私のロジックでは、貴方の方が有利という試算なのね。
おk。了解した。
いやまああくまで最悪計算量なんで、結局実際のところは実測しないとだけどもね
オーダー上は挿入でnに比例するから二分探索に意味はない、と書きながら気付いたりもしてる(苦笑)
>>294 地味に標準指定のアルゴリズムも改善されてて追いきれないよぉ
そして誰からも忘れられているstd::nth_element
ていうか4位同順が10万画素ぐらいあったらどうするんじゃスレ主、
一枚一億画素
jpg一枚で25MB
FFでは開けた
専ブラのプレビューでも相当時間掛かった
リンクを踏む気は無い
できたので貼る
Insertion sortで上位5件の相関値と座標(x, y)を表示するやつ：
https://ideone.com/L0fXH2 これは、同着があっても上位5位に入れば全部出力する。
get_top_N_pixels()がご本尊の関数
get_top_N_pixels_exp()が比較用に作ったバージョンで、std::sortで全画素並べ替えて上位5件を出力する。
上位5位以内に同着があまりに多いとget_top_N_pixels_exp()の方のが早いが
適当に作ったランダムな値の条件でQVGAぐらいの画像サイズだったらget_top_N_pixels()の方が8倍ぐらい早いっぽ
訂正 s/同着/同順/g
で、同順がそれなりにある前提でパホーマンスをちゃんと計ったら8倍どころではなかったわ3000倍以上早かったわ；
条件は以下の通り
■ 画像サイズ:
W=320 - 10, H=240 - 10
(Number of pixels=71300)
■ データ
値域[-5000.0F, 5000.0F]の一様分布。データ重複無し。
■ Basic design の結果（get_top_N_pixels_exp(): 全画素std::sort()）
387 sec @ 反復回数ntimes=100, TOP_N=256 --> ntimesを10倍にすると3870 secの見込み
■ Practical designの結果（get_top_N_pixels(): TOP_N画素のInsertion sort
1 sec @ 反復回数ntimes=1000, TOP_N=256
14 sec @ 反復回数ntimes=10000, TOP_N=256
とゆーわけで、今回は一様分布かつデータ重複無しでこうだったので、TOP_N=256は一般条件における128と解釈するとして、
上位5位に入るデータの個数が128個以下なら
>>305のpractical designで上記のパホーマンスが出る見込み
ごめwwwwwデータ訂正および結論は480倍早かった、に訂正、
■ Practical designの結果（get_top_N_pixels(): TOP_N画素のInsertion sort
1 sec @ 反復回数ntimes=1000, TOP_N=256
8 sec @ 反復回数ntimes=10000, TOP_N=256 -- 3870 / 8 = 483.75
14 sec @ 反復回数ntimes=10000, TOP_N=65536
ごめｗｗｗｗｗｗ結論は3000倍以上早かった、で訂正の必要はなかったorz
Basic designの結果
387 sec @ 反復回数ntimes=100, TOP_N=256
に対して、Practical designの結果
8 sec @ 反復回数ntimes=10000, TOP_N=256
は、(387/100) / (8/10000) = 4837.5倍早い
今日日のCPUアーキテクチャーとinsertion sort様様じゃ
STLってもはやスクリプト言語などと変わらない使用感でプログラム書けるな
最高過ぎる
c標準ライブラリの関数ってstd名前空間にあるのに必ずしもstd::をつける必要ないよね
なぜか分かる人いない？
C言語との互換性のため。
using使っているから。
cstdio → stdで囲まれる
stdio.h → 囲まれない
横から納得w
古いC++(C互換重視)と新しいC++(新世界の王に俺はなるモード)の互換のためか。
ナル。
directory_recursive_iteratorで各ディレクトリを読み込むと読み込み順がおかしくなりますが、これvectorに突っ込んでソートしないと辞書順に戻せないのですか？
>>322 戻すっていうか、普通のファイルシステムでは辞書順に並ばないことの方が多いんじゃないの。 知らんけど。
言語仕様的には recursive_directory_iterator が辿る順序は未規定。
二次記憶装置のデータをいちいちソート済みに保とうとするとオーバーヘッドが無茶苦茶だからな
読み込み順がおかしくなるんじゃなく、いつもOSがソートして見せてくれてたのが元のまま出てきただけだ
DOSの時代はdirに/oスイッチが追加されたとき便利になったものだと思ったよ
毎日毎日ソートして表示してくれてる ls や dir.exe や exproler.exe には頭が上がりません
総統も相当ソートがお好きですなあ
ｶﾞﾊﾊﾊﾊﾊﾊ、
また低学歴知恵遅れたちは頭わるいこといってるわ。。。
ｄｉｒ．ｅｘｅ？
ｄｉｒはｃｍｄ．ｅｘｅの内部ｺﾏﾝﾄﾞだからな
ｄｉｒ．ｅｘｅなんかあるﾜｹがない
ｿｰﾄするのはｃｍｄ．ｅｘｅがｄｉｒｺﾏﾝﾄﾞを受けつけたときの機能で
OS自体の機能じゃないからな
ﾎﾝﾄな低学歴知恵遅れたちは基本的なことが分かってない
>>330 最近飽きられてきたから(構ってもらえなくなったから)、芸風を変えてきたんだろ。触らないのがよろしいかと。
全角の部分を半角で書き込むと403ではじかれる
わかった？
低学歴知恵遅れの書き込みはいつも浅はか
ｃｍｄ．ｅｘｅ を半角で書いたら、
コマンドが実行されて、サーバーをハッキングされるとか、
5ch・サーバーの運営は、頭おかしい
素人がシステム・サーバーの運営構築してる
漏れは、何十冊も本を読んでいるけど、
ｃｍｄ．ｅｘｅ を送ったら、ハッキングできるという記事を見たことがない
dir .exe
dir
cmd. exe
OS
ﾎﾝﾏや！弾かれた！！
サニタイズの最先端・ユーザーに入力させない←いまここ
いや知らんけど多分、
5chのNGワードチェックには文字参照という抜け穴が空いてる。
間違えた cmd.exe か
>>339 実体参照は書き込めない短縮url貼ったりするときにも使えるよね
文字実体参照・数値文字参照なら、コマンドが実行されて、5ch サーバーをハッキングされる事もない
cmd.exe
dot, period は、ascii コード、46 (0x2E)
戻り値がオブジェクトの関数書きました。
すると上司が、変更があったとき不具合の原因になるからポインタで返せと。
これ本当でしょうか。stackoverflowとか覗いてるんですがオブジェクトで返すかスマポで返すかみたいな論調ばかりです。
少なくとも生ポインタ使えという意見は見当たりません。
（生）ポインタ使ったほうがいいケースというのは実際にあるんでしょうか。
>>346 malloc してるやつなら
FILE * とかな
>>346 参照返しでもポインタ返しでもプログラムの堅牢性は大差ない気がする。
ちなみに俺は、NULLを返すケースがある関数はポインタ返し、
NULLを返すケースがない関数は参照返しにしてる。
c++ の標準のスマートポインタでは循環参照を持つもの、
例えば get_child() と get_parent() を持つような木構造やリスト構造は扱えない
で、大抵の場合これらは単に生ポインタで実装される。
>>346 C++ のミスりやすい箇所ってのはメモリ管理が多くを占めるので、
生ポインタは面倒くさいわってのが普通の感覚だと思うし、
不具合の原因になるってのはよくわからん言い分なので、
もっと掘り下げて聞かないとなんとも言えん。
共有オブジェクト (DLL) のインターフェイスにする場合なんかだと
ABI の都合とかでおかしなことになったりすることもあるかもしれんなぁ
みたいな可能性を想像することは出来るが、
書いてるプログラムや開発環境の性質に固有の事情はわからん。
一般的には、生ポインタにせざるを得ないことは有っても生ポインタの方が良いってことはあんまりなさそう。
ファクトリー関数は生ポインタ返すように作るのが良いと思う
たしかにどこも指してない参照を返したいときは
NULLポ使えるポインタ返しにする
ダミーの空オブジェクト作れるように
C++が最初からルートオブジェクト基底してくれてればよかったのにと思うことはある
struct Point{int x; int y;};
みたいな単純なPOD構造体をstructだからって教条的にいちいちnewとポインタで取り回してるプログラムは時々見かけるけど
そういうのは危ないし遅いしウザいからやめてほしい
そんなの参照と値渡しでいいということには同意するが
point 型を new / delete してるコード見た経験はないな
>>346の上司が言ってるのは、コピーコンストラクトや代入が正しく機能するということを
保証しなくちゃならなくなるから、ってことだろ
そこまで気にかけてる暇はないし、生ポで書くのが一般的な職場だというならそれに倣うしかない
そういえば俺コピー不可のクラス書いてもちゃんと private だ何だで実際に代入できないようにしてないな…
コピー不可で思い出したけど、コピーコンストラクタと代入演算子をprivateにしたクラスを
vectorにpush_back()する記述がコンパイルエラーになるよね。
vector<Hoge> hogeVec;
hogeVec.push_back(Hoge()); // コンパイルエラー
これってどうすればいいの？
>>358 std::vector の要素は CopyAssignable と CopyConstructible の要件を満たす必要がある。
実際、 std::vector は内部で要素をコピーしたり代入したりすることがあるんだから、
それが出来ない要素を入れられないのは当たり前の話で、
コンテナに入れるならポインタ (上記要件を満たすスマートポインタでもよい) を入れるようにするくらいしか方法はないと思う。
>>358 ムーブしてもいいならムーブコンストラクタと代入演算子を定義すれば行けないかな
どうせ所有権意識して std::move を使うなら個々のクラスには
手を加えず unique_ptr かますのが楽じゃないかな
>>362-363 ムーブ可能なだけでは必要な要件を満たしてない。
コピー可能であることが要求されている。
>>364 vectorの型Tの満たすべき要件は操作による
push_backとかresrveとかはコピーかムーブのどちらかが可能ならば問題ない
リストのイテレータ使って周期的な処理をしたいんだが、そういう使い方合ってる？
N 要素のリストのイテレータ it = s.begin() を N 回インクリメントしたら、it はルート(？)を指すわけだが、そうじゃなくて s.begin() と同じところを指してほしい
こういう場合、どうしたら良いだろうか
ｽｱﾎﾎﾟｲﾝﾀみたいな頭ﾜﾙｲの使うぐらなら
C++なんかつかわなければいいのに
低学歴知恵遅れは新しいもんができると
使わないといけないという使命感があるらしい
低学歴知恵遅れは自分で要否が判断できない
そうだね痴呆おじいちゃんには7年前に標準化された最新機能は難しすぎるから仕方ないね
半角に限らず今でもウヨウヨいるからあんまり笑い事じゃないんだけど
あんのが難しい？
知恵遅れは頭ﾜﾙｲｼﾛﾓﾉを使ってる自覚がないからな
低学歴知恵遅れはｱﾚで難しいもん使ってるつもりでいんのか
へー
>>367 それ参考にして自力で実装してみます
ありがとうございます
>>365 あ、ほんまや。 ワイの記憶は C++03 時代のやつやった。
ムーブないからしゃーなしでコピー必要やったんやな。
うろ覚えで
>>364みたいなこと断言してたのかよ
自分の記憶を疑う癖つけた方がいいよマジで
>>373 いや、このサイトを見て確認はしたんだよ。
https://ja.cppreference.com/w/cpp/container/vector ただ、 「C++11 以前」という書き方になってたから、前後を見ずに C++11 は含むのだと思ったし、
(現在の最新ではないとはいえ) C++11 くらいには配慮すべきだろうなっていう前提で言ってたの。
でも、ちゃんと仕様を確認したら「C++11 以前」は C++11 を含まないことに気づいたって次第。
あー、確かにあれは紛らわしいかもね・・
でもすぐ近くに「C++11およびそれ以降」ってあるしな
Cとhaskellはどちらがどれくらい速いですか？
STLのリストは要素を挿入するごとにメモリーの割り当てが起こるのか一度に割り当てられている場所に
なのかどちらですか？
規格は要素ごとに割り当てるのを想定してるだろうけど
例えば10個分まとめて、みたいな実装もOKじゃないかな……
挿入削除やイテレータの++がO(1)みたいな各種要件さえ満たしてれば
vectorならともかく、そんな実装するってメリットがあまり無い気が
メモリのローカリティを維持できれば性能がよくなる可能性もあるんじゃね？
>>380 メモリのアロケーションは意外にコスト高いからまとめてアロケートしておいて
node を用意するときにそこから placement new とかして使ってゆくと高速になる
リストのノードに限らず、プロファイル取って new が時間
食ってるときにオブジェクトについてはこれで簡易に改善できる
最近はデフォルトのアロケータが高性能で意味がないこともあるけど
続き
解放も一気にしないと面倒なので基本追加一方で不要になったら全部消すみたいな場合に使う
巨大 xml の dom を作って、不要になったら全解放みたいなとき。
大きいデータだと何十万回、何百万回もnewしなくちゃいけないようなクラスは
１メガくらいまとめてnew [] したほうが絶対いい。
実行時間比較すればわかるけど、かなり高速になる。
１メガくらいという根拠の薄いマジックナンバーに依存する糞コード
>>385 当然、実装するときは、まとめて確保するメモリ量は指定できるように作るのが当たり前。
いちいちそんなこと言わなくてもみんなわかると思って、例えば１メガという意図で「１メガくらい」
と書いたが、バカには伝わなかったみたいだな
で、１メガという定量的な根拠は？ いくら罵倒しても自動的には出てこないぞ
パフォーマンスを求めるシーンでダブルリンクリストって
ダブルかどうかは知らんが深さが不定の木構造なら仕方ない
んでメモリ確保はn個まとめればアロケーションコストはほぼ1/nになるんで
10とか100で十分で別にそんなに増やす必要はない
が、大量にアロケートするときしか使わない手法なので1000とか大きな数にするのが人の情
まあnewするクラスのサイズによるだろ
サイズが１００バイトのクラスなら１メガでもnewの回数が一万分の１になるので効果はありそう
データ構造全体でどれくらいの大きさになるのか事前に見積もれればいいんだけどね。
ガチでチューニングしようと思ったら
各アプリケーションでのメモリの使い方の特性を考慮しなきゃならんし、
パラメータの微調整は実際にやって試してみるしかしょうがない。
>>392 ＞データ構造全体でどれくらいの大きさになるのか事前に見積もれればいいんだけどね。
そうだな
実行開始して何時間も待たされた挙句、メモリ不足でエラー終了とかマジ勘弁して欲しいわ
最初に使用メモリ量を予測してエラーにしてくれよ
今時はメモリエラーなんて出さずに延々確保しにいってスラッシングしまくるだけ
>>387 >>385 キャッシュなんだから 2のn乗で適当な大きさ持ってれば大丈夫
>>395 テキトーの用語の使い方を間違っているな
jemallocのデフォルトチャンクサイズは1MiBらしいな
経験的に悪くない数字なんだろう
一気解放テクというのはN億個のオブジェクトをフルスピードで作って10秒かかったとして、
破棄するときもバカ正直に10秒かけるつもりなのかとかそういう話だが
オブジェクトがリソースを所有しておりデストラクトを要するﾌﾞﾂだったりすると
オブジェクトの占有メモリだけ一気に解放することはできないから成立しない
というわけでコンパイラの中で構文解析結果であるところの木構造を破棄するのにお目にかかるぐらい
なｷﾓｽ
ソースコードを読んだわけじゃないが、
ウェブサーバの H2O はドカンと大きいメモリを確保して頭から順番に使っていくという戦略を取ってるのでクソ速いというのを
どこかで見た覚えがあるな。
ウェブサーバならセッションが基本単位と考えれば、
セッション開始時に大きいメモリを確保してセッション終了でまるっと捨てるというのは確かに理にかなった方針だと思う。
>>400 いやnewもdeleteもインプレイスでやるからメモリの確保と解放はまとめてできるんだ
んでコンストラクタとデストラクタはどっちにせよ必要なので、メモリの確保と解放が問題なんだよ
で、指摘の通り
メンバ変数がまたメモリを確保/解放してるとご利益がぐっと薄れるので
まとめて確保を使い始めるとベクターだなんだもショートストリング最適化みたいな
小サイズなら静的に確保したメモリを使うようなテクニックを使い始める。
LLVM の SmallVector やそれを基にした boost の smallvector なんかがそれか
boost のは small_vector の typo
まとめてアロケートするコードのテストコードを書いてみた
簡単なリストのアロケーションと解放
100個ずつと1000個ずつではだいぶ違った
1000を10000にしても大差ない
https://ideone.com/oyIM5p 上の例はリストのノードにstring を持たせているが、
これをvectorにするだけで高速化の倍率はひどく悪化する。
https://ideone.com/k6XiHK string は SSO(ショートストリング最適化)で小サイズならメモリのアロケートを行わないが、
vector はサイズ1でも必ずアロケートするため。
opencv(c++)で適当な画像をDCTしてDCT係数をテキストファイルにプログラムを教えていただけませんでしょうか。
画像をDCTするとこまでは分かったんですがそのあとが分からないです。
>適当な画像をDCTしてDCT係数をテキストファイルにプログラム
日本語で
>>408 もう1回書きますがテキストファイルに書き出すです
OSが分からんが、一番楽チンであれこれ考えなくて良いのは普通にprintfしてファイルにリダイレクト。
dctは出来るのにストリームへの出力は出来ないのか
ofstreamでファイル開いて<<で出力
ascii文字だけなら文字コード気にしなくてもいい
DCT係数が配列に格納されているんですがそのすべてを書き出すのができないです
>>418 Mat 型の変数 m に入ってるなら
std::cout << m;
で標準出力に出るだろう
参考
http://opencv.jp/cookbook/opencv_mat.html C言語は高校･大学の頃やったので大体わかります
今更ですがC++勉強するのに良い教材は何でしょうか？
本が良いですがもっと良い方法がありましたらそれでも良いです
>>421 まずは「プログラミング言語 C++」を読んでみては？
高いから図書館で借りるといい
C++ってnumpyみたいに2次元配列から範囲を指定して抜き出しとか出来ないですかね？
10, 20, 30, 40, 50
60, 70, 80, 90, 100
110, 120, 130, 140, 150
160, 170, 180, 190, 200
このようなvectorがあった際に
70, 80, 90
120, 130, 140
170, 180, 190
を抜き出したいです
>>424 自分で書きたくないならあり物のライブラリ使えばいいのでは
よく知らんけど opencv の Mat とか BLAS とか
https://minus9d.hatenablog.com/entry/2014/03/21/114514 boost の multi_array でできる
かなり調べた結果これに行き着いたから、他のを見つけるのは至難の業だと思う
まぁ2次元配列に限るなら正直 vectorのvector でそういう動作するもの簡単に作れるよね
普通こういうものの部分行列はデータをコピーしないで動作するんだよ。用途によるけどだいたいは。
>>424 C++ から python も numpy も使える
>>424 vectorではなくvalarrayの使いどころだ
valarrayじゃなきゃ駄目な場面なんて知らんがな
そもそも2次元の配列使う必要がない
1次元で十分
池沼はいちいちみため2次元にしたがる
みため二次元ねえ
int vec[][5] { 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170, 180, 190, 200 };
これで済むことを、
int& elm(int row, int col)
{
static int vec[] { 10, 20, 30, 40, 50, 60, 70, 80, 90, 100, 110, 120, 130, 140, 150, 160, 170, 180, 190, 200 };
return vec[row * 5][col];
}
いちいちこう書くやつも充分に池沼なんだが
そういうやつをちょっとプロファイリングしてみると
配列へのポインタに腹を立て、ポインタの配列にmallocして
強引に**で二次元を扱えることにするテクニックを某所で自慢したら
タコ殴りにされて、すっかり心を病んでしまい
以後、二次元配列というワードで凶暴化するようになった、とかね
>>436 tcl/tk なら枯れてるから大腿同じ
ていうか(アドレスp)[x]は*(p+x)の別表記に過ぎないというのは規格上の話にすぎなくて、
実際問題としては一次元配列アクセスと二次元配列アクセスには最適化のかかり方次第でかなり速度差が生じるお
一次元配列にすると、概念上の次の行の要素への移動が加算1発で済むというのが喜ばしい
これとループ最適化が組み合わさると、配列スキャンが主な仕事の処理は爆速になり得る
といいつつ次の例はideoneでこそ一次元配列アクセスの方が遅いが（爆
Visual C++ 2010だと一次元配列は10倍超速いお
https://ideone.com/K7uLo9 （VC++での結果）
******* Array 1D opt:
ntimes=100000^2, sum=2372578304
Consumed time=0 sec
******* Array 2D:
ntimes=100000^2, sum=2372578304
Consumed time=10 sec
C/C++で「二次元配列」と言った場合
char *hoge[N]; の方を指すのであって
char **fuga; の方は決して「二次元配列」ではない
Javaなら後者を指してるので
これらが初心者には混乱の元
ごみん
いきなり間違えた
char *hoge[N]; じゃなくて
char (*hoge)[N]; こうです
439 の言うばふぉーマンスは
char **fuga; だから落ちるのであって
char (*hoge)[N]; では落ちない
ていうか
>>439のやつもよく調べたら1000倍近い速度差で一次元配列の方が早いお
今日日のCPUアーキテクチャーでよく見られるいつもの光景だお…
（VC++でntimes = 百万の2乗にした結果）
******* Array 1D opt:
ntimes=1000000^2, sum=2273652736
Consumed time=0 sec
******* Array 2D:
ntimes=1000000^2, sum=2273652736
Consumed time=928 sec
>>443はジャグ配列と通常の二次元配列の区別も付いていないおむつも取れていない赤ん坊だお；；
>>444 VC++は2次元配列が苦手ってだけじゃない？
手元のgccとclangは最適化なし(-O0)だと1次元の方が少し遅くて最適化あり(-Ofast)だと1次元と2次元で計算部分は全く同じアセンブリになった
>>436 文法古くて生産性低いってだけで、コードは動くよ。
いい質問があったら鬼のように加速するけど、そうじゃないときはかなり穏やかなんだな
おいEffectiveC++がいつの間にかオライリーになって高価くなってるじゃねぇか
誕生日におばあちゃんにもらった図書カードでも買えないぜ
Javaが来年頭から死亡展開になるの今日知った
C++はやっぱ平和だな
ところでみんなはC++で何を作ってるの?
>>457 Java は無償サポートが薄くなったってだけで、
使うだけなら特に制限が強くなるわけではない。
そんなにサポート利用してたか？
使うだけならね
Androidの商業開発は痛いよ
googleがdart言語を着々と開発をしてるのはこれを避ける為だったと
C++を長年使ってきた身としてはようやくJAVAとかいうゴミが一掃されてまさしく自らガーベッジコレクト自爆してくれて清々する
聳え立てた糞の山を保守するために生き残り続けるよ・・・
Javaが出てきた頃はまさかこんなCOBOL並の糞山生産言語に成り果てるとは思わなかったな
悲しいなあ
スマートポインタってガベージコレクションではないの？
ガベージか非ガベージか、どうやって見分けるの？
見分けられないなら逆説的にガベージはない
全部データと言える
すると言う通りにガベージは発生しない
どっちも参照カウンタが0になった瞬間はガベージと言えないこともないが、スマートポインタだとその場で即削除される。
ガベージコレクションは参照カウンタが0になったメモリをメモリアロケータが適当なタイミングで削除する。
自分の中で結論出してるみたいだから説明したくないなあ
スマートポインタはリファレンス(参照)がなくなったときにメモリやオブジェクトを解放する。
ガベージ(参照不能なオブジェクトやメモリ)がどこかに溜まって、
いつかのタイミングでそれらをコレクトするような動作はしない。
スコープを抜けるときにスタックフレーム上のオブジェクトが破棄されるのと同様。
異論はいくらでもどうぞ
書いてて思ったけどスタックという仕組みは素晴らしいハックだよね
「部屋を最後に出る奴は電灯消せよ」がスマポ(std::shared_ptr)
電灯付けっぱで誰もいない部屋を探して消し回るおばちゃんがGC
C++にはそういうおばちゃんはいない
>>476 面白い表現だね。
いつかパクらしてもらおう。
スマポって何に使うん?
趣味グラマーだけど使ったことない
cv::Matとかに使われてるだけで個人では使わないようなものなの?
生ポを上手に使えない人が使えばいい
自信があれば無くてもOK
可能なら生ポインタは避けるのが良い作法。
単純に、 delete を書くのめんどいから勝手にやってくれた方がよくね？
そりゃあ場合によっては生ポインタが必要な箇所もあるだろうけど、
スマートポインタは高度なライブラリ内だけでしか使われないってほど特殊なもんではない。
ポインタ型のデータメンバを持つクラスのコンストラクタで
発生した例外を function try block で捕捉して後始末をするよりは
スマートポインタを使った方が勝手に解放してくれて楽というのもある。
例外が絡むと本当にめんどいし、思考停止したい。
>>482 参照カウントがGCの実装アルゴリズムとして使われることがあるというだけで、スマポがGCと言ってるわけではないよ。
だいたいガイジンにとってガベージコレクションといえば↓コレなんだから、広範に収集しないスマポをGCと呼ぶのはすごい違和感。
https://money.usnews.com/careers/best-jobs/garbage-collector スマポが GC かっていうのはちょくちょく話題になるね。
私自身は std::shared_ptr はガベジコレクタの一種だと考える派って話は前スレにも書いた。
http://2chb.net/r/tech/1535353320/303 考え方によるので定義を定める必要はないとも思ってるけどね。
>>473-474 C++ でデストラクタで不要なメモリにマークだけしておいて
実際の解放処理は後回し (とか別スレッドでやる) だとかいう手法もあるけれど、
あなたがたの基準ではこれは GC と言える？
作れるよ。C++でガベージコレクタを実装した言語を。
変な質問ですみません。
C++をBetterCとして使いたいのですが、C言語が分かる前提で、おすすめの書籍などないでしょうか？
コーディング規約ではないですが、その書籍に書いてあることまでは使っていいような形にしたいのですが。
なんでC++をC++として使わないのか、使いたくないのか、使う度胸もないのか
まずそこをはっきりさせよう
ベターＣなんぞというあまっちょろい考えのヤツはC++道破門だ
そんなあまっちょろい考えだからJAVA上がりのようなデストラクタもろくに使いこなせない小わっぱだらけになるのじゃ
C++ を Better C として使ってもよいというのは設計者自身も言ってる。
だけど、あくまでも、 C をわかっている人が完全には C++ を理解できなくとも
わかる範囲で C++ を実務をに使いながら C++ への理解を深めていける (より高度な C++ 使いになることを目指す)
という前提付きだ。
C から C++ への段階的な以降がスムーズに出来るという話であって、
>>489 のように C++ の固定されたサブセットを Better C として使うのはちょっと違う。
強いて言えば Embedded C++ とかいった規格の提案もあったけどさぁ、
https://ja.wikipedia.org/wiki/Embedded_C%2B%2B 企画倒れに終わったので書籍とかはあんまりないと思う。
c++をc++として使ってる人っていったい何作ってんの？
ゲーム？
でもゲームってAAAクラスだと未だに例外なしで作ったりしてんでしょ
ゲームは例外ダメだったりC++03だったりしたけど
今はだいぶ現代的なC++になってきてるよ
>>484 shared_ptrがGCと似た仕組みで動いている場合があるからといって、
shared_ptrがGCの一種であるというのはちょっと飛躍してない？
C89以上C99未満のBetterCという意味ならわからんでもないが、その場合
参考にするのはやっぱりC89の本だろうな。
>>497 メカニズムは GC だから GC であるという単純な主張だよ。 似ているんじゃなくてそのものだと言ってる。
前スレで QZ 氏が書いている言語との関係性、抽象化の仕方による区別にも説得力を認めてはいるけど、
一般的に GC 付きで実装される言語のほとんどでは意味論としては GC を要求しているわけではなく、
「オブジェクトの寿命を無期限にする」という要求があって、それをある程度実現するために GC が
使われているに過ぎないということを考えれば言語側の意味論とメカニズムは切り離す方が自然で、
メカニズムが GC ならそれは GC だというのが私の考える理屈。
>>493 そういう選民思想的な考え方はいかがなものかと思うけどね
実際C++をCのような低レベル部分も含めてちゃんと理解し
テンプレートを使った総称的プログラミングまで使いこなし、最新のライブラリも使いこなすのに
どれだけの学習コストがかかるか
世の中ははちみつみたいなヒマ人ばっかじゃないんだよ？
俺スゲーと言いたいがためにC++の普及を妨げるな
>>489 案外C++入門書ってCと同じ文字列は文字型の配列とか、そう言うところから入っちゃうから、
文字列はstring型、配列の代わりにvector型とかが入門の時点で説明されてるのって案外少ない。
ストラウストラップのプログラミング入門 とかどうよ？
そうじゃなくて、文字列や配列はCと同じの使いたいなら、適当な入門書から使えそうなの抜き出せば良い。
あ、
>>500にはオブジェクト指向プログラミングも追加しとく
>>500 隅々まで使いこなせと言ってるわけじゃない。
フルセットの C++ を自分なりに使えよと言ってるのであって、
その根拠として、一定の形に定まった C++ のサブセットという試みは
ろくでもない結果に終わったという事実を紹介してるだけだ。
初心者や C++ しか知らない人が
C++ を Better than C として使うことは不可能に近い
C も C++ も知ってて C++ を敢えて C として使うことが出来る人だけが
Better than C として使える
Cで書くならちゃんとCとしてCの範疇で規格に沿って書けと思うけどな
準拠先はC89でもC99でもC11でもいいけどさ
なんで異言語(C++)を中途半端に混ぜようとするの？
D&E では、 C から C++ への段階的な移行が出来ることを
意図して C++ を設計した (Better C として使える) ということが書いてあって、
確かに私も C を知らなかったら C++ はまともに使えなかっただろうなと思う。
でも、 C の延長線上で C++ の便利な機能を使ったプログラムって
どこまで C++ の機能を取り入れても「C++ 的なプログラム」ではないなとも思う。
C++ を (綺麗に) 使うなら C++ を前提とした設計が必要なので、
Better C として使うことを積極的には勧めにくいという気持ちもある。
欲しいのが「C++」ではなく「考え方は C っぽいけどもうちょっと高級なやつ」ならば
Go あたりを考えてもいいんじゃないかな。
∧_,,
(#ﾟ;;-ﾟ)++
/;; ;;っ
～;; ;; ﾉ
（/"'J
C言語を知らなかったら、C++が書けないのはありえない
入門書の初っ端にcin,coutを多用しておきながら、C言語から段階的に移行出来るとか寝言は寝て言えって感じやなｗ
それでいてoperatorの説明は最後の方とか。大人しくprintfとscanfにしとけや。
まだBetterCがどうとかいってるのか
何十年前だよ
普通にC++を使えよ
>>511 否定が多すぎて読み取りにくい。
「C言語を知らなかったら、C++が書けないのはありえない」→「Ｃ言語を知らなかったら、C++が書ける」→「C++ を書けなかったらＣ言語を知っている」
禿げは預言者に過ぎず、C++を授けたのは神なのでは。
>>503 お前D&E読んでるならEmbedded C++の話はまた別だと知ってるはずだが
EC++はC++の方言を作ろうとしたのが失敗したんであって
「そんなもん使うくらいなら、職場やらプロジェクトでC++の一部の機能に限定して使え」と
禿も言ってたろうが
質問者の質問無視して何押し付けてんの？何様だよ
言語の使い道を決めるのはお前じゃない
--no-exceptions --no-rtti
これで充分だね
C++はマングリガエシがどうのこうのって話を聞いたことがあるな。
>>516 ん～、俺の言ってることが伝わってないな。
「自分なり」の、つまりは各プロジェクト、各チームの事情に合わせて (制限して) 使うべきで、
どっかからよくわからん「固定されたサブセット」を引っ張ってくるのはクソって話だから、
あなたの言うそのままのことを俺は言ってるつもり。
>>520 いやいやお前の言い分の方がわからんよ
だったら
>>489の言う使い方で文句ないだろ
今後ともC++を覚える気は無い、なんてどこにも書いてなかったしな
（さすがにそれだったら俺も「Cでええやろ」と思うけど）
>>521 事情に配慮せずそこらへんの書籍を適用したって上手いこといかんという単純な話じゃないの。
>>496 へー、そんな仕事やってんだ
どこの会社か興味あるけど
まぁそれはさておきc++である必要性って何なの？
C++ではいろんなもんが作られてる
ｸﾘﾃｨｶﾙなｼﾛﾓﾉでｽｸﾘﾌﾟﾄが使われることなんか滅多にない
要するに本を口実にして人間の能力を制限したいってことでしょう
ンなモンC++の理念には全く反してるんじゃあないスかね
そいつの能力の限界まで迫れなきゃあC++を使う意味なんてないよ
会社の教育目的なんだろうけど「本に書いてあること以上はするな」ってのは
公教育の理念に縛られたクズが言いそうなこと
他人の能力にストッパー掛けて制限したいための口実に過ぎない
だからBetter Cとかは全く関係ない
ただ単に目的は「そいつの能力を制限したい」
これだけ
だから
>>489の思想は教育に名を借りた能力制限だよ
敗戦国の植民地でよくよく見られる思想だ
ハッキリ言えば危険思想、撲滅した方がいい
こういう中二病みたいなやつ増えたな
こういうのに限って一度もまともなソフト書き上げてない
リファクタリングすると重いソフトになる。
何故なのか。
>489みたいなのは、よくあることだろう？
大抵はコーディング規約で、なんらか制限したりとかしていると思うけど。
そもそもC++を使えるプログラマが、そんなにいるとは思えない。
EffectiveC++を知らない（”読んでない”でなく）プログラマも数多くいる。
チーム全員がと言うことになると、一番下の人に合わせることになるだろう。
1. 入門書
2. Effective 何々
3. 逆引き・レシピ本
4. メタプログラミング
どの言語でも、この順番。
3まで読んで、そこからプロ！
1だけの開発者は、素人だろw
C++ boost.asioについて質問です。
boost::asio::ip::tcp::acceptorのasync_acceptはスレッドセーフ？
サーバーを実装するとき1ポートで1acceptorになるはずだけど
このacceptorは複数のスレッドからasync_acceptしても大丈夫？
一つのacceptorを複数のスレッドでacceptするのはパフォーマンスの観点からも良いですか？
>>531 ポイントカードやクレジットカードのデータを読み込んで表示させるプログラム自作する営業がいる一方で、
プログラマーとして入って何も出来ない奴もいる。
(こう言うのは早々に消えるが)
実力じゃなくて、何が主な収入かでプログラマーと言われてる所はある。
まあ、あれはプログラマーが外人で、都合の悪い事は認めないから証拠集めに仕方なく覚えたスキルってのもあったかもだけど。
>>533 スレッドセーフかどうかなんて簡単に調べられるんじゃない？
セーフかどうか調べる方法がわからんの？ 先ずはその調べる方法を確立したほうが
いいんではない？
>>529 それアホなリファクタリングしてるだけだろ w
OOPをやりたいんですけど、C++やったことありません
Smalltalkを勉強したほうがいいですか？
そういうアプローチもあるだろうね
求めるものがサイエンスなのかテクノロジーなのかで
選んだらいい
>>535 >>537 ありがとうございます。
勉強します。
メンバ関数の末尾に&や&&がつくのって何か意味があるのですか？
constやnoexcept、volatileはわかるのですが・・・
代入演算子に左辺値参照修飾しとくと、右辺値に代入できなくなったりする
他はなんかあるかな・・・
C++11で追加だったのね。ありがとうこざいます。
https://kagasu.hatenablog.com/entry/2017/05/02/120156 このページで、例えば
ifs.imbue(locale(locale::empty(), new codecvt_utf16<wchar_t, 0x10ffff, consume_header>));
というのがあって、locale()の第二引数でnewされたものがありますが、
これをdeleteする記述が見当たりません。
他のページでも同様です。
リークしてそうで怖いのですが、一体どこでdeleteされてるんでしょうか？？
>>546 参照カウント方式で管理されてて、デストラクタでdeleteされます
>>547 素晴らしい！
RAIIですね。
安心しました。
ありがとうございました！
普通にどうプログラムを書いていいのかわらないので
質問したいのですがよろしいですか？
すれ違いならすいません
図１
０００
０００
０００
図1の０の部分を0から9までのすべての数字に置き換えたものを
表示して変数に格納する
図では３X3にしましたがｎXｎだとしてください。
説明が下手かもしれませんがよろしくお願いします
0から9までのすべての数字は10個あるが
場所は9個しかないがどうするの
説明が下手ですいません
２３６
０００
０１１
こんな感じで9か所すべてに0から９まで入ったものを全パターン格納したいです
.csvにして出力したいので
excelで手打ちするよりはいいのかなと
たぶん、20GBほど必要だけどいいんか？
全パターンにこだわらず、乱数で必要な数だけ生成したほうが良いのでは？
おっとinodeの最小サイズがあるから100倍くらいかしら
それは3*3を1次元で考えると
0 0 0 0 0 0 0 0 0
から1ずつ増やして
9 9 9 9 9 9 9 9 9
まで表示して全パターンを変数に格納ってこと？
単純に1桁1バイトで考えると1パターンにつき9桁9バイト必要なので、格納領域だけで9000000000バイト＝約8.4ギビバイト必要なんだけどそういうこと？
1000パターン/秒の速度で表示したとしても104日かかる計算になる。
課題か何か知らないけど、問題を勘違いしてるのでは？
3*3だったら要素数9の配列を用意してループで回せばいいだけじゃないの？
９！≒36万行のcsvが欲しいのか？
４ｘ４だと１６通りで１６！=20?922?789?888?000
おおよそ21京行のcsvファイルが出来上がる
5x5だとwikipediaにもoeisにも載ってないが
15,5112,1004,3330,9859,8400,0000 らしいので
15.5穣行のcsvファイルが出来上がる
Yが一歩手前の??なんで、世界中の記憶媒体を寄せ集めても足りるかどうか・・・
６ｘ６だと３６！の
37,1993,3267,8990,1217,4679,9944,8150,8352,0000,0000
37正
csvファイルを作り終える前に人類滅亡するレヴェル
実際に必要なのは160万通りぐらいだけど無理？
無理なら諦めます
全ての場合分けを検討できないから、枝刈りしようよ。
全パターン網羅じゃなくてピックアップでいいなら乱数という手段もありでは
乗り遅れた…
鏡像とか回転の扱いをどうするかとか
楽しそうな課題だな
N×N のテーブルを N 種類の値同士の演算結果と考えて
その演算結果が群の性質を満たすパターンだけを取り出す
というような課題はやったことがあるな。
群論的には値の個性は意味がなくて、
たとえば全ての 1 と全ての 2 を交換したようなパターンは
等しいという扱いになってしまうので、
それを除去するのが面倒だった。
いや、この話題の流れには関係ない話なんだけど
>>571 を見て思い出したもんだから。
vector A に vector B を部分代入することってできないの？
つまり、代入後は vector B が vector A の部分vectorになっててほしい
部分vectorって言ってるから、Bを参照扱いで挿入出来ないかってことじゃないの？
Bを書き換えたらAにも反映されるみたいな。
まぁ、vectorじゃ構造上無理なんだけど。
>>572 ＞N×N のテーブルを N 種類の値同士の演算結果と考えてその演算結果が群の性質を満たすパターンだけを取り出す
すごく興味がありますね…
準同型を検出するのが難しそうですが、ガウス吐き出し法で同一解（ただす解を小さいもの順に並べなおす）を弾くようにするだけでなんとかなりますか？
ググッてみると、位数12 の群のひとつは、巡回群でも巡回群の直積でもない、これより低位には現れなかった新たなパターン、らしいのです、これはどんな群なのか具体的に知りたいものです
小さい群ならいいだろうけど、散在型単純群が出てくるサイズになっても対応できるかな
using FUNC = std::function<void(Params&)>;
struct Params {};
template<> std::tuple<> convert_params(const Params&) { return {}; }
template<> std::tuple<int> convert_params(Params& p) { return 0; }
template<typename... Args>
inline static auto message_handler(void(*func)(Args...))
{ return [=](Params& m) { std::apply(func, convert_params<std::tuple<Args...>>(p)); }; }
template<typename... Args>
inline static auto message_handler(std::function<void(Args...)> func)
{ return [=](Params& m) { std::apply(func, convert_params<std::tuple<Args...>>(p)); }; }
template<typename T, typename... Args>
inline static auto message_handler(void(T::*func)(Args...), T* obj)
{
assert(obj != nullptr);
return [=](Params& m)
{
std::apply(func,
std::tuple_cat(
std::tuple<T&>(*obj),
convert_params<std::tuple<Args...>>(p))
);
};
}
↑の続き
前の投稿で定義した関数を使い、下記の通りに呼び出そうとしているのですが
std::functionを通さずにラムダ直で呼び出した場合に、なんとなく上手にやってくれる
方法がどうしても思いつけません。何か手はないでしょうか？
1 void myfunction(int);
FUNC func = message_handler(myfunction); // OK グローバル関数
2 void myclass::myfunction(int);
FUNC func = message_handler(myfunction, this); // OK メンバ関数
3 FUNC func = message_handler([](int){}); // NG ラムダ直
4 std::function<void(int)> myfunction = [](int){};
FUNC func = message_handler(myfunction); // OK std::function
頭に+つけると上手くいくと思う
FUNC func = message_handler(+[](int){});
>>585 あれ、マジでうまくいきました。
調べ方がいまいちわからないのですが、これはどういった機能でしょうか？
すみません、お礼を言い忘れています。
ありがとうございます。
>>586 std::decayと同じ働きをするようなもので、ラムダ式を同等の関数ポインタへ変換する（ただしキャプチャをしてはいけない）
なんて調べればいいのかはよくわからない・・・
突然すまんが、
winnt.h の中に次のような構造体定義があって、外部では、構造体タグ名
_RTL_CRITICAL_SECTION が不完全定義すらもされないで、
_RTL_CRITICAL_SECTION_DEBUG の中でポインタのために使用されている。
仮にこれで、「内部クラス」扱いにならないのだとすれば、
逆に、「内部クラス」を使いたい場合、もし完全定義を与える前に、
不完全なままポインタのために使いたい場合は、どうしたらいいのだろう？
typedef struct _RTL_CRITICAL_SECTION_DEBUG {
WORD Type;
WORD CreatorBackTraceIndex;
struct _RTL_CRITICAL_SECTION *CriticalSection;
LIST_ENTRY ProcessLocksList;
DWORD EntryCount;
DWORD ContentionCount;
DWORD Spare[2];
} RTL_CRITICAL_SECTION_DEBUG,*PRTL_CRITICAL_SECTION_DEBUG;
typedef struct _RTL_CRITICAL_SECTION {
PRTL_CRITICAL_SECTION_DEBUG DebugInfo;
LONG LockCount;
LONG RecursionCount;
HANDLE OwningThread;
HANDLE LockSemaphore;
DWORD Reserved;
} RTL_CRITICAL_SECTION,*PRTL_CRITICAL_SECTION;
確か、構造体タグ名は、ブロックに名前空間があって、C と C++ で仕様がごちゃごちゃしていた
気がした。
確か、既に定義がある場合は、それが定義された段階の名前空間を使うが、
完全に新規に定義する場合は、最も内側のブロックの名前空間に登録される、という
感じだった気がしたんだけど。
一度も外部では定義も宣言もしなかった場合、最も内側のブロックの名前空間に登録されるの
だとすれば、クラスや構造体内部の内部クラスに関してもそれの応用になって・・・、と思うんだが、
少なくとも、旧来の C のヘッダファイルでは、その解釈ではまずいことになっている気がする。
struct _RTL_CRITICAL_SECTION;
って行があるんじゃね
不完全な型はそれを解決する必要があるときに完全な定義が得られればいいんで、
それがどこの名前空間に存在するかについてもそのときに解決できればよかったはず。
>>591 無い気がする。
さっき思ったんだけど、C++ の場合、winnt.h の大部分は、extern "C" {・・・} で囲まれて
パースされて、旧来の C の仕様のままになるので、内部クラスの概念が無いから
あれでいいのかも知れない？？？
>>592 _XXX_DEBUG の方で、_RTL_CRITICAL_SECTION を _XXX_DEBUG の構造体に所属する
「内部クラス」 に解釈してしまった場合、外側の _RTL_CRITICAL_SECTION では、
タグ名としては同じ名前であっても、コンパイラにとっては全くの別の構造体に見なされて
しまうので、たとえば、ポインタを代入する際に、
「異なるポインタ型への代入がある」
などのエラーが出る可能性がある。
>>593 extern はリンケージを制御する仕組みで、
extern "C" にしても文法の解釈には影響を与えない。
C として解釈されたりはしないはず。
？
その「内部クラス」 の定義は存在しないんだから。
何のための不完全型かと
型の中身を意識する必要はない
リンケージなんか関係ない
>>597 不完全定義でも、厳密にどの構造体かは区別されている。
不完全型でいけそう
https://ideone.com/SFcGAQ 内部クラスと解釈はされないみたい（内部クラスと解釈されたらリンクリストで困るような）
https://ideone.com/DcYHNu 詳しい仕様は誰かプリーズ
>>599 >（内部クラスと解釈されたらリンクリストで困るような）
しかし、外部クラスと解釈される場合は、本当に内部クラスにしたい場合で、
それ自身が自己参照を持つリンクリストにしたいような場合に、逆に困る
事になるかも知れない。
struct Bの定義は内と外両方同時に存在し得て、検索順で近い方に解釈されるというだけだろ。
何を心配してるのか。
>>601 別の名前空間の構造体だと解釈されれば、ポインタの代入も出来ない。
>>602 1つのコンパイル単位内でそれはないだろ。
>>605の一番近いnamespaceからというのは嘘でした
×
https://ideone.com/LpC58v 正しくは、解決不可能だった場合は、同じ階層から選択されるみたい。
AとBがともにNS2に存在する場合
https://ideone.com/m5leMs コンパイルエラー。 AがNS2 Bがひとつ外側のNS
https://ideone.com/9IY4BC 同階層にBがない場合、グローバルからも選択されることはない。
https://ideone.com/cMhwpW >>604 ある。
単に人間に見えているタグ名が同じというだけで、コンパイラ内部では、
全く別の識別番号(というより、通常、コンパイラ内部の構造体定義データの先頭アドレス)
になっており、タグ名が同じでも識別番号が異なれば、全く別物と扱われる場合がある。
>>603 ものすごい微妙な動きをするみたいだ・・・。
struct Base の定義を見てみると、外側に既に struct Data が定義されていても、
なぜか、Data は、「nested Data」すなわち、Baseの内部クラスの方を「参照」して
しまうらしい。規則性はどこにあるんだろう。まだ英文読んでないけど。
struct Node {
struct Node* Next; // OK: Refers to Node at global scope
struct Data* Data; // OK: Declares type Data
// at global scope and member Data
};
struct Data {
struct Node* Node; // OK: Refers to Node at global scope
friend struct ::Glob; // error: Glob is not declared, cannot introduce a qualified type ([dcl.type.elab])
friend struct Glob; // OK: Refers to (as yet) undeclared Glob at global scope.
/* ... */
};
struct Base {
struct Data; // OK: Declares nested Data
struct ::Data* thatData; // OK: Refers to ::Data
struct Base::Data* thisData; // OK: Refers to nested Data
friend class ::Data; // OK: global Data is a friend
friend class Data; // OK: nested Data is a friend
struct Data { /* ... */ }; // Defines nested Data
};
【違いの分析】
1. 外部クラスを参照したい場合の書き方：
struct Data {
struct Node* Node; // OK: Refers to Node at global scope
・・・
};
2. 内部クラスを参照したい場合の書き方：
struct Base {
struct Data; // OK: Declares nested Data
・・・
};
【考察】
後者の方は、「『宣言子』を「何にも書かずに」、ただ不完全定義として、
「struct Data」と書いている。こういう独特の特徴的な書き方で、
新しいタグ名の導入と見なされているのではないか。
一方、前者の方は、 「struct Node」だけではなく、「*Node」という「宣言子」を
書いてしまっているので、新しいタグ名の導入とは見なされない気がする。
先日書いた、CRITICAL なんたらの例では、宣言氏を書いていたので、「1」
の方の扱いとなり、外部クラスの参照と見なされた・・・。
>>609 D&E の 6.3.1 にそのあたりの解説があるので読んでみると面白いかも。
「病的な例」を含めてわかりやすい解決ルールを作ろうと奮闘したあげくに
まあまあマシなルールとしてそうなったって感じ。
>>611 結局、
>>610 のような結論であってるのかな？
ぜんぜん違う
ﾎﾟｲﾝﾀだからｻｲｽﾞが決定できることになる
ﾎﾟｲﾝﾀなら前方宣言で前方参照できる
2. のほうは構造体を宣言してるから、そこに新しく nested class が作られてる。
1. のほうは構造体へのポインタを宣言してるから、対応する構造体を探して外部の定義を見つけてる。
そんなに微妙でもないと思う。
そもそもﾎﾟｲﾝﾀでない場合、前方宣言でなくｸﾗｽ(もしくは構造体)の宣言がないと
ｲﾝｽﾀﾝｽのｻｲｽﾞが決定できないし
ｺﾝｽﾀﾗｸﾄﾀも呼び出せない
普通にｺﾝﾊﾟｲﾙｴﾗｰになる
ｸﾗｽ(もしくは構造体)のﾒﾝﾊﾞにｱｸｾｽする場合も同じく
前方宣言でなくｸﾗｽ(もしくは構造体)の宣言がないと
ﾒﾝﾊﾞがわからない
普通にｺﾝﾊﾟｲﾙｴﾗｰになる
ﾎﾟｲﾝﾀもしくは&の参照だけなら
前方参照だけで問題はない
ﾏｼﾞで頭悪いｼﾛｳﾄしかいない
おじいちゃん今はタグ名前空間の話でしょ
不完全型のポインタが完全型になる話なんか今更ドヤ顔でしても恥ずかしいだけだよ
また低学歴知恵遅れが的外れなこといってるし
低学歴知恵遅れってなんでこんな頭悪いん
頭悪いくせに頭悪いﾚｽをする
まず低学歴知恵遅れはC/C++言語の特性すらわかってない
>>614 C/C++ では、ある1つの宣言で、ポインタ変数を定義する場合でも、それと同時に構造体の
宣言(定義)が行われる事がある。たとえば、
TYPE *ptr; は、ポインタ変数の ptr を定義しているが、TYPE の部分が
struct TPerson { ・・・ }
だった場合は、変数 ptr の定義と同時に、構造体 TPerson も定義する。
さらに、TYPE の部分が、
struct TPerson
であった場合も、不完全定義として構造体 TPerson を定義することがある。
実際、先に挙げた例では、1つの行で、全く始めて _RTL_CRITICAL_SECTION 構造体が
出てきて、その不完全定義と同時にその構造体へのポインタ型のメンバ変数を宣言
していた。
型が struct TPerson みたいに書かれてて、 TPerson の宣言が見つからない場合、そこで TPerson が前方宣言されたものとして扱われる。
この前方宣言は一番内側の namespace かブロックに所属する扱いになる。
要するに一部の前方宣言は省略できるってだけだよ。
>>610における2の書き方が新しいタグ名の導入と見なされる、というのが特殊ルールなだけで
あとは
>>613でおk
オール無問題
>>622 >>610における2の書き方を前方宣言と解釈するなら、
構造体定義の中で前方宣言可能なﾌﾞﾂが他にはfriendぐらいしか無い件について：
（externは書けない、staticは別の意味になる
しかもfriendは直後に完全型かポインタか参照を要求するですしおすし、
struct Data;という構文の際立ったユニークさは明らかすぐる…
ていうかstruct Data;という構文には構造体の定義ブロックの外に書いたとき発動する存在意義が別にあるが
そちらは前方宣言と言って良いかも試練、
こういうやつ↓↓↓
struct Data;
struct Foo {
struct Data* m_pData; // struct Fooはstruct Dataへのリンクを有する
/*....*/
};
struct Data {
struct Foo* m_pFoo; // Dataはstruct Fooへのリンクを有する
/*...*/
};
そもそもなんで型の名前やクラス名だけではなくて、タグ名なんてものが存在し続けているのかというと、
struct Data;というのがやりたかったから、およびその必要が（上のようなケースで）あったからに他ならない
>>624 struct Data* ptr;の記法が特殊なだけで、
struct Data;は一貫して前方宣言なのでは？
>>627 >struct Data* ptr;の記法が特殊なだけで、
(不完全型)* ptr; とされてもコンパイラはptrへの代入や関数に引数渡しするコードを問題なく吐けるから
int val; というのと大して変わらない話
コンパイラにとってはｽｹﾞｰ普通の日常業務
>struct Data;は一貫して前方宣言なのでは？
前方宣言というには
>>610における2の書き方で新しいタグ名の導入と見なされるという挙動がﾋﾞｮｰｷ
もはやそれは内部クラスの定義にほぼ等しい（不完全な定義というだけ
struct Data* ptr;の記法が特殊な根拠
struct A {
struct Data* ptr; // as ::Data
struct Data* ptr;の記法が特殊な根拠
struct A {
struct Data* ptr; // ::Data
};
struct A {
struct Data;
struct Data* ptr; // A::Data
};
前方宣言のあるなしで、解釈の変わるstruct Data* ptr;の記法はやっぱり特殊なんだと思うけど。
C++において、不完全な型という概念はあるけど、不完全な定義という概念はないのでは？
struct A { struct Data* ptr; };
と記述した場合、そこからたどれる名前空間のどの階層であっても
事前に宣言または定義が行われていれば、その時点で特定可能なstruct Dataへのポインタと解釈されるけど、
解決不可能であった場合には、struct Aと同階層にあるstruct Dataとみなされる <- この動作が特殊
struct Bar;が前方宣言では「ない」という主張は撤回する
なぜなら、次のコードの(A)、(B)のコメントアウトを外しても
それ自体はエラーにならない（つまりstruct Bar; は同一スコープ内で重複が許される
このときは(D)でエラーになる
しかし、(A)と(B)をコメントアウトすると何のエラーにもならない
むしろstruct Bar* m_pBar; の方が普通に前方宣言的に働く（Fooのスコープに縛られない
#include <stdio.h>
struct Foo {
//struct Bar; // (A)
//struct Bar; // (B)
struct Bar* m_pBar; // (C)
};
struct Bar {
int x;
int y;
};
struct Bar* g_ptr;
int main()
{
Foo test;
test.m_pBar = g_ptr; // (D)
}
ちょっち訂正
△： struct Bar;が前方宣言では「ない」という主張
○： 構造体の定義ブロック内のstruct Bar;が前方宣言では「ない」という主張
で、struct Bar* m_pBar; の方が普通に前方宣言的に働く（スコープローカルな新たなタグBarを作ったりしない）のに --(1)
構造体の定義ブロック内のstruct Bar;は明らかにスコープローカルな新たなタグBarを作り出すという変態機能を有している --(2)
つまり(2)を指して一貫して前方宣言だと主張するなら、(1)のstruct Bar* m_pBar;も前方宣言の一種だと言わねば不正直である
>>634 構造体の定義ブロック内のint i;は明らかにスコープローカルな新たな変数iを作り出すんだけど、
それも変態機能だと思うの？
(1) が前方宣言的に働く理由は
>>622 で説明したんだけど、通じなかったかな…
>>634 >struct Bar;は明らかにスコープローカルな新たなタグBarを作り出す
構造体定義ブロック内に限らずとも、前本宣言はもともとすべてスコープローカルだけど。
それはグローバルであっても、中間階層の名前空間であっても、
多重ネストの構造体の中間階層で会っても同じ。
拘ってる人は自前でコンパイラでも作ろうとしてるのか？
>>615 ポインタでない場合というと
struct aho;
struct boke
{
aho begin();
aho end();
};
こういうのもあるな
最初に質問を書いた者だが、この話は、実は仕様が決まっていて、
記憶だと、手元にある ARM(Annotated Reference Manual) にも、確か
何か書いてあった。
見るのがメンドクサくてここに質問を書いたんだ。スマン。
レス㌧クス、
>>636 なるほどｽｹﾞｰよくわかりた
>>635 構造体の定義ブロック内のint i;は2回同じものを書いたらエラーになるから宣言ではなくて定義じゃわﾊﾟｵｰﾝ
構造体の定義ブロック内のint i;は2回同じものを書いたらエラーになるから宣言ではなくて定義じゃわﾊﾟｵｰﾝ
その他の方々もだいたいおk
プログラム間でデータ共有する方法はメモリ共有とファイル経由以外に何がありますか
>>643 ・WM_COPYDATA メッセージで送り合う。
>>643 Windows ならメールスロットとパイプもアリかな。
質問者の意図がようわからんが
データ本体（ｽｹﾞｰ巨大かもしれない）の共有にいちいち通信時間を要する手段は除外されるんじゃ…
やっぱプロセス間の同期をミューテックスか何かのプロセス間でも使える同期オブジェクトまたはソケット通信とかでとる前提で、
データ本体のはメモリ共有かファイルという手段になるのではなかろうかと、
ファイル渡しの方が通信よりよっぽど時間がかかると思うが。
>>649 共有のニーズが生じてからファイルを作るのならそうだが
最初から共有データとしてファイルが存在する場合はそうではない
というわけで質問者の意図にはようわからん点がある
ディスクアクセスの遅さ考えたらわかるだろ、ふつう。
>>652 想像力が欠如すぐる…
共有しようとするデータのサイズが1 TBなら、全部送ろうとしたら3GB/sの転送速度でも333秒かかる
ファイルを1個置いといてfseek()する方がまだまし
たった一行の素朴な質問からどこまで膨らませられるかコンテスト開始
通信推しの人としてはそう言いたくなる気持ちもﾜｶﾙ
1TBのデータ共有するのにファイルからは1TB読まなくてもいいという謎比較。
同一の計算機で何度も読むことが分かってるのに
別の計算機でﾃﾞｨｽｸｱｸｾｽさせて
それを通信でやりとするｱﾎなｼｽﾃﾑ構成にするﾔﾂがあとを絶たないのがよくわかる
著しい低学歴知恵遅れがそういうことよくやる
世の中には常識をこえるすごい頭悪いﾔﾂﾗがいるからな
何度も何度も計算機Aから計算機Bの数十ｷﾞｶﾞを超える共有ﾌｧｲﾙの内容を計算機Aにすべて読み込んで
計算機Aで処理をなん百回も繰り返す
しかも共有に使うSamba
つまりNBT（）
Windows共有とまったく同じ
つまり毎回毎回計算機Bにﾃﾞｨｽｸｱｸｾｽして通信（NBT経由）使って
計算機Aで読込むということを意味する
それで遅い遅いなんでといってたからな。。。
世の中には想像を超えるこんな頭悪いのが現実にいる
>>656 むしろ毎回データ全部を丸ごと送る想定なら、高速な通信手段で良くて
「データ共有する」（
>>643)という質問者の動機にならない件について：
メモリ共有であれば通信より高速を目指す目的で毎回データ全部を丸ごと送る風に使われることもあるが
質問者
>>643は共有手段として「ファイル」も挙げているから
いきなりそこまで話を限定できないﾜｹ
んまー今思いついたがメモリ共有やファイルの他には
データベースみたいなデータを出し入れ管理するプロセスなりサーバなりを設けるというのも
>>643の答えに含まれるのかもしれん…
>>656の思い込みとはうらはらに、
データベースXにアクセスするプロセスA、Bは、明らかにXが管理するデータを共有しているが、
Xの管理するデータ丸ごとを毎回送りつけ合うわけではないし、
なんか長々と書いているようだが、全部送ろうが一部だろうが正しく同条件で比較すれば一目瞭然だろう。
1. プロセスAが巨大なファイル中の一部のデータの読み込みをファイルシステムに要求する
2. ストレージから読みだされたデータが返される
1. プロセスAがプロセスBが持つ巨大なデータ中の一部のデータをRPCで要求する
2. プロセスBからデータが返される
>>660 データベースなら例えばSQLでやりとりやね
既にオンメモリで数ギガ扱うのに対応してるしプログラム間通信も高速
なにより統一されたプロトコルでオンメモリからネットにまでアクセスできるのが便利
>データベースみたいなデータを出し入れ管理するプロセスなりサーバなりを設けるというのも
これを実現する手段として
>>644-646のような手段があるわけだが、それ認識してなかったのか。
それはデータベースとは言わんのじゃ？
COPY_DATAやメールスロットはOS提供の簡易的なプロセス間通信サービス
RPCはデータ以に上さらに高度にアクセスするプロシージャ
データをどう持つかというのはこの際どうでもよくて、
>>663はそのサーバープロセスと
データをやり取りする手段の話ね。
>>663 >これを実現する手段として
>>644-646のような手段があるわけだが、それ認識してなかったのか。
>>644-646はデータを送りつけるという通信の手段のみ述べており、データ共有の実現に行き着いていない
もちろん通信だけでもプロセスAとBの間で情報の共有はできるが、
>>644-646の言説だけでは、情報を表す入れ物である「データ」の共有に行き着いていないﾜｹ
>>644-646の言説が含意するのは、同じ情報iを、プロセスAがデータa、プロセスBがデータbとして持っている状況、
というところ止まりで、aとbは別物。さらにいうと、同じ形式のデータであることすら導くことができない
この差異は形而上の問題ではなく、現実の設計の問題である
>>644-646だけでは、AがBに情報伝達するにあたりBに通信する（通信のエンドポイントとしてBを起こす）必要があるから
Bが風邪で休んだりするとAの仕事まで止まってしまうことが確定する
一方、AがExcelシートXに情報を書き、Bが必要なときXの情報を参照する、という方式だと（他に付帯条件が無ければ）Aは問題なく仕事を続けられる
データ共有というのは後者
今度は「共有」という言葉の定義論か。それを
>>647で言っていたんならそう問題はなかったろうがな。
どっちにしても通信時間が云々というのが的外れなのは変わらない。
見苦しい。
なぜ機能とそれを実現する手段を混同して語るかなぁ…
Excelのブック共有だってExcelアプリケーションがファイル共有とか使って頑張ってるから実現できてるんだし
そもそも
>>643は手段レベルの話だし
>>667と
>>668は通信でおk、と叫びつつ、ネットワークのトポロジーの差異を認識しないおマヌケちゃん
結局通信についてもデータ共有についても素人なのでした
残念ながらリアル郵便網を使うプロトコルスタックはないので伝書鳩にした方がいい
伝書鳩はパケットロスの可能性が高いので冗長化が必要
ループバックができる鳩は往復鳩といって
普通の伝書鳩より訓練が難しいんだぞ
手段の話であれば極論口頭でもいいわけたが、勿論そんなこと聞きたい訳でもなし
>>643 実は、GDI の Device Context の HDC も、プロセスの垣根を越えて渡す方法がある、
メモリコピーは伴わずに。やり方は、PrintWindow(HWND hWnd, HDC hDC, DWORD flag)
API を使って、WM_PRINT メッセージを送るというもの。これを使えば、グラフィックデータ
ならBITMAPデータも伝達できる。たとえば、HDC を用いて GDI+ の LockBits() を
使うと良い。L。
http://2chb.net/r/tech/1474384848/338 C++を使ってる仕事につきたいのですが、どこもC++を使ってるところは組み込み系とかの経験の募集ばっかです
私はwebしかやったことないので組み込み系の経験はありません
>>679 ここはダーマの神殿ではない、と言いたいとこだけど、年齢によるね。
未経験でも30歳前後なら余裕、35歳超えなら諦めろ。
というか組み込み系でC++を使っている分野ってあるにはあるけどそんなに多くはないよ。
組み込みLinuxでのアプリ開発ぐらいなんじゃない？
老害から言わせてもらうとアレは組み込みソフトじゃないけど。
>>680 25です
Linuxでのアプリ開発分野ならあるんですね‥
別に組み込みじゃなくてもいいんですけど、探したら組み込みがほとんどって感じです
本気で探しているのですが、難しいです‥
頑張って探してみます
25歳なら第二新卒扱いで組み込み未経験でも全然OKよ。
募集要項に経験者って書かれてても怖がらずどんどん応募してみては？
相変わらずこの業界は人手(奴隷)不足なのでそう苦労せず転職できると思う。
売り手市場の今は転職先の会社を見極めて選り好みすることができるので、下手に妥協せず納得行くまで転職活動頑張って！
>>682 ありがとうございます！
目標に向かって頑張ります
相談に乗ってもらってありがとうございます
相談してよかったです！
普通にC++でWindowsようのデスクトップアプリ作ってるけどなあ
それように人員を募集してるかっていうとしてないけど
>>684 普通に羨ましいです‥
自分は中々見つからないです
>>680 組込でガッツリは使ってないけどBetter CとしてC++使ってる所はそれなりにあるよ
ちっこく作って別プロセス立てするってやり方はあるけど
それ以外だと大規模なゲーム開発くらいしかあんまり聞かないな。
なんでc++の仕事したいんだ？
言語縛りにする意味がわからんな
C++の最新仕様に詳しくてもあんまり仕事で使えないからな
メタプログラミング駆使して行数少なく書いてもぶっちゃけ大した価値ない
逆にやりすぎて嫌われるのがオチ
CPU、キャッシュ、バスアーキ、OS、ABI、Toolchain、各種デバッグ手法などを知ってる方が重要
言語仕様詳しい癖にmake書けない奴とかいるからな
VisualStudioばっか使ってるからmakeかけないわ・・・
makeは依存ﾌｧｲﾙと生成ﾙｰﾙをひたすら書くだけだからな
あんなしょうもないのを書けないほうがおかしい
makeは暗黙ルールとか特殊変数とか予約ターゲットとかアーカイブの特別扱いとか
罠や地雷や落とし穴が満載で人間が書くもんじゃない
昔はmake書けないやつ馬鹿にしてたが、ひざに矢を受けてしまってな……
今いるのやや学術よりのとこなんだけど、回りがPythonばかりになってきて690の気持ちが分かってしまう
linuxのmakefileをwindowsで使おうとしてハマってぶん投げたのはナイショ
makeは泥沼、mkmfやら数多のツールすら呑み込む底無し沼・・
makeを書くだけなら簡単だがクロスプラットフォームで更にいくつもオプションが増えてくると人力で書くこと自体が間違いでしかなくなる
環境導入楽なGUIアプリケーション作成用ライブラリないかなぁ
QtはQtCreatorが使いづらくて
標準ライブラリにGUIが入らないのは何故なんだぜ？
制御系とかそもそもGUIが無い環境に実装出来ないから？
通信ライブラリですらいつ策定されるか分からない状態なのにGUIとかC++29くらいになりそう
それに最近はGUIはweb方面のエコシステムを流用するのが流行だしはっきり言って厳しい
GUI ライブラリの提案だけは出てるけどね。
cairo を取り入れようとか、
ウェブアプリケーション風の DOM ベースのやつ (?) とか。
動作モデルが色々とあるので、
どれかに統一するのはしんどいと思う。
ベースの動作モデルを意識させないほど厚いライブラリを
標準に入れるのもちょっとどうかと思うし。
>>704 そういうのは「言語」かってことだよ
ISO/IEC14882は言語を定義する規格で、
GUIを定義する規格なら別の文書番号になるだろう
OSを定義する規格がそうであるように
標準ライブラリは最小限でいい派
標準のスレッドすら不要
大抵結局native handle使うはめになるし
デバッガと連携しないし
一方でatomicは使えるな
質問です。
ノートPCのキーが勝手に連打されるような状態になったので、
「キー入力の連打を感知したら、連打された入力をキャンセルする」というソフトが欲しいのですが、
どこかにあるでしょうか？
無ければ、自作も考えますが、キー入力をキャンセルさせる方法がよくわかりません。
キー入力のイベントをフックしてごにょればできるんじゃないの
>>710 いわゆるチャタリングってことかな。
ざっとググってみた感じだと ccchattttter や Keyboard Chattering Fix というソフトがあるみたいだね。
ソフトウェアとしては、他のプロセスが受け取るイベントを横取りすることになるから、
アプリケーションレベルでやるならフックを仕掛ける (DLL Injection など) か、
あるいはデバイスドライバのレベルでどうにかするという方法も考えられる。
ありがとうございます。
＞ ccchattttter や Keyboard Chattering Fix
さっそく、試してみました。
これらは、同じキーが連打された場合のみのキャンセルでしょうか？
違うキーが連続で誤入力されたりするので、その場合は対応できないかも？
フックするというのは、どうやるのかわかりませんが、ちょっと調べてみます。
https://qiita.com/leon-joel/items/81415c1ef355c6246280 constexpr unsigned N = 10;
std::array<int, N> arr = {{ 1, 2, 3, 4, 5, 6, 7, 8, 9, 10 }};
2行目の 二重の中括弧は何を意味してる？
どう解釈するの？
その制限c++14で撤廃してなかったけ（うろ覚え）
>>710 それキーボードに異物が入ってないか？
かつて俺が面倒見てた客先ではホチキスの針が原因の障害が複数回あったぞ
異物が入っていない正常な状態で起きるチャタリングは
設計の段階でしっかり対策されているはずなので
それまで問題なかったキーボードが突然そういう状態になったのなら
何らかの事故を疑ったほうがいい
https://www.codesdope.com/cpp-stdarray/ 以下の二種類あるらしいけど、何で2.の方は二重括弧になってるの？
外側の括弧の意味、内側の括弧の意味がそれぞれ知りたい。
1. std::array<int, 5> n = {1, 2, 3, 4, 5};
2. std::array<int, 5> n { {1, 2, 3, 4, 5} };
std::arrayのメンバーの初期化リストになってる可能性。
外側の括弧はコンストラクタへの実引数ならびを囲む
内側の括弧はコンストラクタの仮引数がinitializer_listであることに対応
= は、一時オブジェクトを作ってコピコンかムブコンという意味だったが
C++17でこの意味が廃止され単なる過去の名残となった
>>719 つまり、2. の方は、以下の記法の ()を{} に変えただけということ？
3. std::array<int, 5> n ( {1, 2, 3, 4, 5} );
つまり、コンストラクタ名を Xxxx とすれば、
Xxxx( リスト型 &list1 ) {
}
みたいな事になってるということかな。
https://gcc.gnu.org/onlinedocs/gcc-4.6.3/libstdc++/api/a00752_source.html ↑ libstdc++ の template struct(?) の array のソースを見てみたら、
// No explicit construct/copy/destroy for aggregate type.
とコメントされていた。明示的なデストラクタが何も無いので、その {・・・}
の部分は、コンパイラが初期化処理まで全部やってるってことなのかも
知れないけど、どういう仕組み？
TYPE _M_instance[N] みたいなメンバがあるけど、ここにコンパイラが初期値を
書き込むんだろうか。どういう仕様なんだろう。
まず、以下の 2, 3 のような書き方が出来て、それで array の場合は、
ああなるってことかな。まだよく分からん。
1. CPerson person = CPerson( 25, MALE, "Yamada Taro" );
2. CPerson person = { 25, MALE, "Yamada Taro" };
3. CPerson person { 25, MALE, "Yamada Taro" };
贅沢なお願いなんですが
OpenGLを使って
注視点を行列で回転させたいのですが
どなたか参考になるサイトやソースが
あれば頂けないでしょうか
>>721 std::arrayはpublicに内部の配列を公開してて、コンストラクタデストラクタを一切書かないことで集成体となって、その初期化は集成体初期化で行う
二重かっこの外側はarrayの初期化、内側のかっこはstd::array内部配列への集成体初期化
ただし、C++14以降は二重かっこを省略できる
https://cpprefjp.github.io/lang/cpp14/brace_elision_in_array_temporary_initialization.html >>692 ＞バスアーキ
古い8086とかだったら書籍に載っていましたが、最近はどうでしょうか？わけのわからない仕様書しかないのでしょうか？
>>724
なるほどだんだん分かってきた。
struct CPerson {
int m_dat1[2];
int m_dat2[3];
};
なら、古い C の時代から、確か、
CPerson person = { {1,2}, {3,4} }; // (1)
みたいに書けた。だから、
struct CMyArray {
int m_dat1[5];
};
なら、
CMyArray a = { {1,2,3,4,5} }; // (2)
と書けるのは当然、ってことだよね。それでC++14以降はさらに、
(1)の場合は、全部一列に並べて、
CPerson person = { 1, 2, 3, 4 }; //(1')
と書ける様になった。結果として、(2)も、
CMyArray a = { 1,2,3,4,5 }; // (2')
と書ける様になった。
そういうことだよね、多分。それでさらに、「=」を省略したような書き方も
できると。そういえば昔から、コンストラクタを持つ CPerson の場合に、
1. CPerson person=CPerson(・・・)；
2. CPerson person(・・・)；
は確か等価で引数つきのコンストラクタが呼び出されるんだった。
そして、新しい C++ では、小括弧 () を、波括弧 {} に書き換えることも
可能になったみたいな話で、
3. CPerson person=CPerson{・・・}；
4. CPerson person{・・・}；
みたいなことも書けるようになったのかな。 贅沢なお願いなんですが
OpenGLを使って
注視点を行列で回転させたいのですが
どなたか参考になるサイトやソースが
あれば頂けないでしょうか
>>729 確か、古くからある OpenGL の場合、GL_XXXX 見たいな定数を指定して、ViewMatrix
見たいなのを設定するんだったはず。
>>729 スレチ
ここにもゲ製作技術板にもGLスレあるだろ
あとは線形代数の勉強しろとしか
>>730 そんな手順の話じゃないと思うぞ
C++でこんな感じの構文見たんですが、どういったものなんでしょうか？
「const auto 関数名 = [変数名](引数) -> 戻り値の型」
例えば、以下のように書くとcに5が返ります。
int X;
const auto hoge = [X](int a, int b) -> int
{
return a + b;
}
int c = hoge(2, 3);
[X]のところは、宣言してある変数ならなんでもいいみたいですが、何者かよく分かりません。
ラムダ式なんてものがあるんですね
知らなかった。。
>>734 その[X]は、関数外部の変数 X を関数内部で使えるようにする意味があるらしい。
それを書いておかないと、グローバル変数やクラスのメンバ変数以外は、参照できなく
なるようだ。
なにか書くよりはとりあえず[&]って書いといた方が良いと思う
よく分からないまま書いて、使えないー、コピーされてるーとか言うことになるよりはトラブル少ないかと思った
必要ないなら空はその通りだと思う
キャプチャーが空のラムダ式は関数オブジェクトと互換性があるので、可能ならインライン展開も行われたりするから、必要ないなら書かない方がいい。
C++って、「関数オブジェクト」ってあるんだっけ？
C++で言う所の関数オブジェクトはoperator()をオーバーロードしたクラスのオブジェクトであって、それは大昔からある
お前さんが思い浮かべてるカッコで括ったそれと同じものかどうかは知らん
>>745 >お前さんが思い浮かべてるカッコで括ったそれと同じものかどうかは知らん
特に何も思い浮かべてないけど。
じゃあ「関数オブジェクト」という名前で呼ばれるものがC++に存在するかという質問？
#include <stdio.h>
class Hoge {
int m_x;
Hoge(int x) : m_x(x) { }
int operator(int a, int b) const { return a + b + m_x; }
};
int main() {
int X = 10;
Hoge hoge(X);
int c = hoge(2, 3);
printf("c=%d\n", c); // 15
}
キャプチャがあるからインライン展開されない、というのは
C++におけるラムダ式の存在意義を半否定している
と思ったり
思わなかったり…
ちなhoge[&X]の場合の伝統的な関数オブジェクト版はこういったｶﾝｼﾞになるﾖｶﾝ↓↓↓
#include <stdio.h>
class Hoge {
int& m_x;
Hoge(int x) : m_x(x) { }
int operator(int a, int b) const { return a + b + m_x; }
};
int main() {
int X = 10;
Hoge hoge(X);
int c = hoge(2, 3);
printf("c=%d\n", c); // 15
X = 20;
int c2 = hoge(2, 3);
printf("c2=%d\n", c2); // 25
}
ｽﾏﾝ
>>750訂正orz
誤： Hoge(int x) : m_x(x) { }
正： Hoge(int& x) : m_x(x) { }
関数オブジェクトって言わないのかな、良くしらんがw
つまり、
auto f1 = [](int x){ retrurn x;}
auto f2 = [&](int x){ reutrn x; }
この場合、f1の型は通常の関数ポインタ、f2の型はstd::functionになるということ。
不明というか、auto以外で受けるのを禁止されているだけで、内部的にはちゃんと型を持ってるでしょ。
たとえば、
void hoge(auto func(int x)->int)
{
.....
}
こういう関数を作ったとして、f1は引数に渡せるけど、f2はエラーになるし、
f2を渡そうと思ったら、std::functionで受ける必要がある。
関数オブジェクト==ファンクタ
多分、
>この場合、f1の型は通常の関数ポインタ、
mjk、
>>748に関数ポインタにならずにすむからくりまで示したのに…
>>755 f2はテンプレート引数で渡せば良い
主にそういう目的のﾌﾞﾂのはず
>>753 f1は同じシグネチャの関数ポインタに暗黙変換可能、であるだけで型自体はコンパイラ依存のラムダ式の型
ｽﾏﾝf2はテンプレート引数で渡せば良いは撤回
普通にf1を引数渡ししてインライン展開を気体するものでだいたい合ってるはず…
関数ポインタに変換できるのはqsortとか昔のインターフェースに渡すのに便利なだけで
今から書くコードで積極的に使うもんじゃない
関数ポインタとstd::functionじゃ実効コストが全然違うから、用途によって選べば良い。
qsortみたいな用途だったら、新しく書くコードでも関数ポインタが適していると思うけどね。
比較関数を動的にとっかえひっかえするんじゃなかったら全く適してないぞ
インライン展開のできるstd::sortが最速なんじゃ。
関数ポインタよりstd::functionの方が遅いんじゃないの？
ポインタはどう頑張ってもポインタだが関数オブジェクトならインライン展開される可能性がある
クロージャみたいなものと、
関数の静的型チェック、自発的なメモリ管理
って恐ろしく相性悪いと思われる。
そんな無理するくらいならおとなしく継承、オーバーライド使った方がマシ。
静的型チェックとクロージャの相性が悪いところってたとえばどんな？
最近、QueryPerformanceCounter() を使って色んな速度測定をしていたら、
32バイトくらいの memcpy() でも、数マイクロ・セカンド位(1.0*10^(-6)(s))かかる事が分かった。
ちなみに、1クロックは、3.3 * 10^(-10) 位なので、たった32バイトに1万クロックくらいかかって
いる事が分かった。
ためしに単純な for ループと DWORD *ptr で転送してみても結局、それ位の
小さなサイズだと、同じくらいかかることも判明。
同じマシンでも、もっと大きなサイズのコピーだと、for ループで行っても、
1回のループで、4クロックくらいしかかからない。
推測だが、jmp 命令は、10バイト程度前の番地に戻る程度でも、ループ回数が
少ない場合は、物凄く極端に遅いが、ループ回数が多くなるとなんと1クロックで
実行できるようになるらしい。
ただし、余り定かではない。
それか、QueryPerformanceCounter() の精度の問題かもしれない。
いくらなんでも、32バイトで1万クロックは遅すぎるように思う。
ちなみに、Sleep(1000); とすると、ちゃんと、1.0 (s) と表示されるので、
速度の計算ミスではないはず。
そうか、これは、RDTSC 使ってないのか・・・。
「高分解能」と言っても、1.0 マクロセカンド位の精度だったとは、予想外・・・。
スレッドのディスバッチ、キャッシュのヒットミス、パイプラインストール、バスのI/O待ち、etc…。
memcpy1つとってもそうそう単純なものではない。
>>768 引数がどんな型を持つ関数を渡すかを事前にどこで決めるかが問題だし、
それ事前に決められるならクロージャーの必要性は低くなるだろ。
あと資源解放のタイミングをどうするかを明示させるシンタックスってのは多分相当難しい。
その辺、クロージャーを用意する言語は普通はGCに任せる。
クロージャって関数とその外側の環境を合わせたものだろ。
「関数を渡す」って何がどこに関数を渡す話なんだろうか。
色々シチュエーションは考えらるだろうけれどreactなら
var ChildInput = React.createClass({
_onChange: function (e) {
this.props.onChange(e.target.value);
}
}
)
とかするやつをイメージしてる。
>>774 >クロージャって関数とその外側の環境を合わせたものだろ
それは新たな関数を作ったことになるんじゃー
>>748の
> int X = 10;
> Hoge hoge(X);
という部分は、f(a, b) = a + b + 10という関数を作ってゐる
Xを変えることによってg(a, b) = a + b + 9とかh(a, b) = a + b + 8とか
Hogeクラスのクロージャでいくらでもバリエーションを作れる
>>777 >>748で言えばHoge::operator()が関数でm_xがその外側の環境だろ。
そこで関数を渡すとか作るとかあるいは静的型チェックと相性が悪いというのが
どういうことを言っているのかわからん。
関数オブジェクトを作ってるというならわかるけど。
C++ のラムダ式は関数オブジェクト生成の構文糖でしかないので、
従来と比べて特に良くなったり悪くなったりするわけはない。
オブジェクトの寿命の管理がやりづらいってのは C++ では今更な話で、
ラムダ式がどうこうとか言ってもしょうがなくない？
>>778 >m_xがその外側の環境だろ
オブジェクトhogeの中に囲い込まれている（キャプチャされたﾌﾞﾂである）からちげう
hogeをコピーしたり別の関数に引数渡ししたら付いていくという意味でも外側の環境ではない
長時間のプログラム終了を手元のスマートフォンで確認したい(メールなど)という願望からそういったプログラムを書きたいんですがさっぱり分かりません
開発環境はvisual studioです
普通に、Linux コマンドを並べたら、1・2の順番で実行される。
PowerShell でも良い
command_1 ;
command_2 ;
コマンド1 が終わったら、メール送信するなら、
command_1 ;
メール送信 ;
複雑な処理は、コマンド・シェルスクリプトよりも、Ruby などで作る方がよい
>>782 今は知らんけど、数年前だったら、メール送信は知識が結構必要だった。
SendMail Transfer Protocol なるものを使うんだけど、それを便利に発行できる
関数なりCUIプログラムがあれば使えるんだけども。
>>784 Linux だったら、aaa.txt に以下のような内容を書いて、
---------------------------------------
From:
[email protected] (あなたのメールアドレス)
To:
[email protected] Subject: This is test mail.
(ここに空行を入れる。ここまでがヘッダ。ここから先がボディ)
メールの内容
.(ドットのみの行を入力すると終了)
---------------------------------------
$ sendmail
[email protected] < aaa.txt
とすると後れるらしい。sendmail は、CUI コマンド。
だから、VisualStudio からだと、
system( "sendmail
[email protected] < aaa.txt" );
とすれば、sendmail コマンドが存在しているなら動作する。
>>780 >>774で言っている関数の外側の環境って意味だよ。それがクロージャの中なのは当然。
いいかげん、元の「関数を渡す」って話からずれまくっているが、結局どういうことを言いたいんだろう。
>>779 いやだからc++なら継承でメソッドでオーバーライドする方が
わかりやすいし、資源も管理しやすいんじゃない？って話。
他の言語にあるからみたいな理由で合わんもの入れてもなということなんだけど。
>>787 >結局どういうことを言いたいんだろう。
クロージャ＝関数
特に()のオーバーライド（int Hoge::operator()(int a, int b) { ... }）までやった場合、
HogeクラスのインスタンスhogeはC++の構文的にも関数同然に機能の呼び出しを行える
（関数オブジェクトとかファンクタとか呼ばれるやつになる
>元の「関数を渡す」って話
クロージャ＝関数なのであるから、クロージャを、クロージャを受け取る他の関数またはクロージャに渡すという話、-- (A)
継承を使う場合のsome_typeのベースクラスをsome_typeのベースクラスを受け取る他の関数に渡すことに対応する --(B)
この場合、クロージャを使うやり方に対する継承を使うやり方のデメリットは…
、と静的型チェック周辺の話に持っていくことができるが、その前に(A)や(B)が共通認識になったのか、それとも理解不能なのかどうか確認しておきたい
>>789 >クロージャ＝関数
そういう前提で言っていたのか？
ID:AQ4G8Wg10は明らかにクロージャと関数を使い分けているようだが。
>>766>>773
じゃあそこは了解したとして、(A)(B)の条件の下でもう一度
>>768の質問をするよ。
関数の静的型チェックとクロージャの相性が悪いところってたとえばどんな？
デリゲートは、オブジェクトを参照キャプチャするクロージャと同じ
（マルチキャストみたいなおまけ機能もファンクタとして実現したクロージャになら追加できる
ファンクタとしてクロージャする分には型安全性も同等なので、ファンクタとデリゲートは混同上等のはず…
>>891 >関数の静的型チェックとクロージャの相性が悪いところってたとえばどんな？
知らん
>>766はクロージャの実現方法について黒魔術的な何かを想定しているのではないか…
C++におけるクロージャの簡単な実現方法はファンクタ、であって、ファンクタには特に型安全や資源解放に関するファンクタ固有の問題は無いと思う
何しろファンクタは普通のクラスHogeの普通のインスタンスhogeとして
>>748風に書けるので…
一方、広義のクロージャは、変数を束縛するしくみ＝クロージャなので、型安全という概念をそもそも含まない
この広義のクロージャをC++上で実現しようとしているのだとしたら知らん
>>788 > いやだからc++なら継承でメソッドでオーバーライドする方が
> わかりやすいし、資源も管理しやすいんじゃない？って話。
だからそんなことはないと私は述べてる。
ラムダ式を使いたいときというのはほとんどの場合は小さな関数を作りたいときなんだよ。
それも一回しか使われないような使い捨てのものをだ。
使い捨てるのならば、別の場所で定義して (名前を付けて) から使うのはまわりくどい。
わかりにくくて管理しづらくなる。
もちろん、場合によってはラムダ式が適さない場合だってある。
そういう場合まで何もかもをラムダ式に置き換えろってんじゃないだ。
ラムダ式が適しているときにラムダ式を使えってだけのことで、しかもそれは案外に多いってことだ。
ああわかった。
>>776ではクロージャと関数を区別して書いていたのに対して、
>>777は単に
>クロージャ＝関数
と言いたかっただけなんだな。
アンカー間違えた。
>>776じゃなくて
>>774か。
訂正orz
誤： 変数を束縛するしくみ＝クロージャ
正： 変数を束縛して作った関数（ただし束縛すべき変数のリストが空のときもある）＝クロージャ
型安全な言語なら型安全に、そうでない言語でもそれなりにやっぱクロージャ＝関数ェ、
>>794 >ラムダ式を使いたいときというのはほとんどの場合は小さな関数を作りたいときなんだよ。
>それも一回しか使われないような使い捨てのものをだ。
ここが自分の感覚と違う。
ラムダ式を使いたい時ってもう少し動的な関数作成に関わる場合という感覚。
単に名前付けを省略したいくらいならどうとでもなると思うし、個人的にはそんな興味ない用途。
C++のラムダ式でどうやって動的関数生成なんかやるの？
何かを根本的に勘違いしてるとしか思えない
jsのノリをc++に持ち込もうとして、
面倒だってぶつくさ言うやつ定期的に現れるよな
なぜc++使おうとしているのか、自分を見つめ直した方がいいぞ
さてはオヌシ、Javascript使ったことござらんな。
new演算子について教えてください。
自分で定義したクラスをインスタンス化してグローバル変数として扱いたいです。
グローバル変数には実体がないといけないと思うのですが、new演算子は
ポインタにしか使えないですよね？
この場合どうしたらいいでしょうか
newなんか使わずそのままグローバル変数として
myclass mc;
とか定義すればよい
>>802 いやだからc++でなんでラムダ式とか入れちゃうのかっていう話をだね。。
jsのノリを無理やり入れたがってるのはc++の仕様の方で別に俺は入れたくない
って意見なのだが。
>>810 オブジェクトとクロージャはメカニズム的には似たようなもんだ
という感覚は言語処理系に明るい人の感覚としては元々ある。
C++ にラムダ式が追加される前に書かれたこの記事が面白いよ。
"クロージャとオブジェクトの微妙な関係"
http://www.itmedia.co.jp/enterprise/articles/0703/29/news069.html JavaScript の「オブジェクト」だって、その内実は環境への操作だ。
つまりはクロージャを基礎にしてオブジェクトに見せているんだから、
その逆をやる言語があったって別に不自然なことではなかろ。
>>809 なるほど！
教えてもらったとおりnew使わないでできました！
クラス・クロージャは、同じ。
関数・メソッドから、引数渡しでもないのに、外側の変数を参照できるから
Ruby のブロックがクロージャ。
ブロックの外側の変数が参照できる
一方、Ruby の関数は、外側の変数を参照できないから、
JavaScript, Python, PHP よりも、すごい強固
Ruby だけは、クロージャの外に、関数をスコープを作っている。
さらに関数の外側がクラスで、クラスの外側がモジュール
モジュール > クラス > メソッド(関数) > ブロック(クロージャ)
Ruby 独特の構造！
エディッタだけで、Visual Studioコンパイル済まで持って行けた。。。
サンタさんがくれた素敵な奇跡。だからその瞬間を宝物にして、書き込みしたくなっちゃうんですね
はちみつ餃子さんってC++を使ってる業務に就いてるんですか？
前にも書いたことあると思うけど、ワイは完全に趣味でやっとる人やで
理解が深まった。ありがとう。
しかし理解すればするほど、c++ならやっぱクラス生成でよくね？って気になるが。
>>821 繰返して述べるが、 C++ のラムダ式は単純なクラスの定義と使用を同時に出来る構文糖でしかない。
何故か「クロージャ」と混同した書き込みがあるが
(もちろんいわゆるクロージャの概念からおおいに影響は受けているのだろうが)
C++ のラムダ式は C++ に新しい概念を導入するものではない。
c++の属性構文が出来たけどc++17で不明な属性は無視するという規定が出来たからには、コンパイラによっては独自の属性があるの？
> C++ のラムダ式は C++ に新しい概念を導入するものではない。
これはさすがに言い過ぎ
関数型のリテラルという概念は C++98 にはなかった
だから C++11 になったとき新しく憶えた
既存の概念の組み合わせでできているから
割とすんなり憶えられたけどね
VC++で[[deprecated]]使ったら警告じゃなくてエラーになっちゃう。
いやまあ正解なんだけどさ・・・
>>827 ん、cl.exe の 19.16.27024.1 では通るが？
つーか、[[deprecated]]って書いてある関数を使っても警告しないのはつまらない
Emscripten で、マウスの動きに合わせて JS の canvasに直線を描いたりする
ようなGUIプログラムを作って試していて、local auto 変数に確保した
16バイトの char 配列に、sprintf で色の #RRGGBB の文字列を合成
して JS に渡して canvas の context の style に直線の色を設定していた。
で、同時に、KeyDown イベントでで20文字ほどのグラフィック文字列を出して
いた。なお、そっちの方でも、全く同じ関数を使って、上記の色の文字列
を合成していた。
すると不思議なことに、KeyDownイベントで文字列を書いた後は、
必ず、直線の方の色が変わってしまう。必ず青色で書くようにしているはずなのに。
ログをとってみると、
char szBuf[16];
sprintf(szBuf, "#%02X%02X%02X", r, g, b);
で szBuf に対して、最後の 0終端文字が、書き込まれていないことが判明。
よく見ると、KeyDownイベントで色のためではなく、出力したい
文字列そのものの文字の一部が直線描画の方の szBuf の #RRGGBB の直後に
残ったままコピーされているように振舞っていた。
ためしに、sprintf() の命令の直前に、memset(szBuf, 0, 16); とすると
正常化することも確認した。
Emscripten のライブラリの不具合だろうか？
char szCol[16];
memset( szCol, 0, 16 );
memset( szCol, 'W', 10 );
szprintf( szCol, ・・・ );
とした場合は、W の文字が残ったままになることも分かった。
szprintf() の直後に
szCol[7] = 0;
とすると、正常化することも分かった。
C++でクラスポインタにnewしたオブジェクトを配列の様に複数作りたいのですが、
エラーがでてしまいます。
ポインタの宣言
TimerParameter *_timerParameter;
インスタンス化
_timerParameter[_timerSize] = new TimerParameter(time, function, one_loop);
TimerParameterコンストラクタ
TimerParameter::TimerParameter(ULONG time, void(*function)(), bool one_loop)
{
_function = function;
_oneLoop = one_loop;
_timeSpan = time;
resetTimer();
}
自分で作ったTimerParameterクラスをnewして_timerParameterメンバに入れると以下のエラーが発生してしまいます
sketch\timerState.cpp: In member function 'bool TimerState::timerSet(long unsigned int, void (*)(), bool)':
timerState.cpp:14:30: error: no match for 'operator=' (operand types are 'TimerParameter' and 'TimerParameter*')
_timerParameter[_timerSize] = new TimerParameter(time, function, one_loop);
インスタンス化の左辺が適切でないのが原因だと思うのですが、この書き方はダメなのでしょうか？
_timerParameter[_timerSize]の型はTimerParameter
new TimerParameter(...)の型はTimerParameter *
あと、
Type * ptr;
ptr[2] = createType();
なんてやっちゃダメなのわかってる？
Type * ptr;
ptr = new Type[10];
ptr[2] = createType();
ならいいんだけど
あと、"_"で始まる名前は処理系予約だし
timeはcの標準関数にtime_t time(time_t *t);があるんでやめれ
アンダーバー2つかアンダーバー+大文字で始まるものが予約されてるだけでアンダーバー+小文字で始まるのは大丈夫
vector<vector<float>> = {
{1.33333334, 3.99918277},
{2.56883338, 1.29994666}
}
このようにvector<vector<float>>をdouble型の要素で初期化しようとすると縮小変換が必要とのエラーが出ます
どうしたら縮小変換しつつ初期化出来るんですかね？
>>839 >ならいいけど
よくないだろ。なぜコピーさせるのか
BoostやSTLのDeveloperになりたいんですけど、テンプレートを極めればなれますか？
テンプレートに限らずC++を極めてるのは当然の前提として
Developerとして参加するプロジェクトをどうしたいとか、どんな価値を提供できるかとかが重要じゃないかな
BoostならBoost相当の性能のライブラリを作って水準に合うドキュメントと何故それがBoostに必要なのか説明する提案書を書いて提出すれば100回リジェクトされる頃には採用されるかも知れない
>>847 C++をより良い言語にしたいです
今はアルゴリズムの研究をしてるのですが、C++をより良い言語にしたいと個人的に思ってるのと、自分が作った言語機能を人に使ってほしいんです
>>848 Boost‥
100回リジェクトされた頃には相当な経験が詰めるはずなので挑戦してみます
>>849 C++自体を改良したいなら標準化委員会に行くかコンパイラの開発に参加しよう
すばらしい、C++標準化に参加して、文字コードの扱いの混乱した現状をなんとかしてほしいw
char型はwindowsがsjis、それ以外がutf8、
wchar型は64bit linuxが32bitで、それ以外は16bit、
どのプラットフォームでも同じようにつかえるchar16_t/char32_tはAPIやライブラリが未整備な上、エンディアンの問題がつきまとう、
と、マルチプラットフォームで各種文字コードの透過的な相互運用は事実上不可能な状態だからな……
そう、それな、ポータブルな保存形式はutf8で良いと思うんだけど、BOMの有無とか、冗長コードの問題とかで実際にやってみると意外と面倒なんだよね。
Windows では Shift_JIS (CP932) という前提もホント駄目な勘違い。
visual studioはいろんなエンコードに対応してるように見せかけてshift-jis前提で動いてる気がする。
デバッガでpngのシグニチャ確認したら臼ngとなるとか、コメントにπを書いたら赤の波線が出るとか。
>>856 ユーザーのコードページを変える以外に方法がないらしい。
Windowsの言語パック入れて表示言語を選択すればたぶん変わる。
まぁ、マイクロソフトも徐々にUTF8を標準サポートにする方向みたいだから、2～3年したらVisual Studioもデフォルトがutf8になるかもね。
エンディアンの問題も、x86,ARMに続いてRISC-Vがリトルだから、流れとしてはリトルで統一ってことになるのかな。そうなったら楽でいいなw
RISC CPUが出始めたときはビッグの勢いあったけど
結局リトルに収斂したな
おれは昔からリトルが自然と感じてたのでいい流れだ
ネットとの相性が悪いのは残ってしまうが
Emscripten で Cソース中に以下のようなプログラムを作ると、MyPrintf()内の
(2) で (3)の vsprintf() を呼び出そうとした瞬間に、なぜか (4) に来ずに、
(5)に戻ってきて a4 に制御が戻って来てしまうことが判明。タイマーイベント
を使ってる。誰か原因の見当が付く人いない？
EM_ASM( {
function js_OnTimer() {
console.log( 'begin of js_OnTimer()\n' ); //a1
var cl_OnTimer = Module.cwrap('OnTimer', 'number', ['number']);
console.log( 'js_OnTimer(), before calling cl_OnTimer(1)\n' ); //a2
var rc = cl_OnTimer(1); //a3
console.log( 'js_OnTimer(), after calling cl_OnTimer(1)\n' ); //a4
console.log( 'end of js_OnTimer()\n' ); //a5
}
setInterval(js_OnTimer, 1000);
});
extern "C" int OnTimer( int a ) {
OnTimerCore();
return 0;
}
void OnTimerCore() {
MyPrintf( "begin(MyPrintf) of OnTimerCore(), %d", 123 ); // (1)
printf( "begin(printf) of OnTimerCore(), %d\n", 456 ); // (5)
}
>>863
void MyPrintf( const char *pszFormat, ... ) {
char szBuf[2048];
va_list va;
va_start( va, pszFormat );
EM_ASM( { console.log( 'MyPrintf, before call vsprintf()\n' ); }); //(2)
vsprintf( szBuf, pszFormat, va ); // (3)
EM_ASM( { console.log( 'MyPrintf, after call vsprintf()\n' ); }); //(4)
va_end( va );
} >>863
原因は、main 関数の最後に書いておいた、次のループにあった :
for ( ;; ) {
emscripten_sleep(36000000); // 何日間も待つ。
}
このループをコメント・アウトするだけで、vsprintf() が1つ前の戻り先に
戻ってしまう不具合も、sprintf() が 0 終端文字を書いてくれない不具合も
共に起きなくなった。
このループを書いていたのは、Emscripten 1.35 で、かつ、
wasm ではなく、asm.js で試していたときに、キー押下イベント
などが発生した時に
Assertion failed: the runtime was exited (use NO_EXIT_RUNTIME to keep
it alive after main() exits)
というエラーが出るためだった。つまり、main() 関数が終わると、
「ランタイム」(ランタイム・ライブラリ?) も終了してしてしまうので、
main() を終わらせられなかった。だから、main() の最後に、なんらかの
無限待機の仕組みが欲しくなって書いていたのだった。
現在は このループを除去しても警告が出なくなっているが、
Emscripten の Version を上げたせいか、asm.js ではなく、wasm の方を
使うようになったせいかは分からない。 なんでリトルが自然なん？
あとから拡張しやすいって意味か？
加算器は下の桁から処理していって桁上げする方が自然とか、複数バイト長のワードで
ビットアドレスとバイトアドレスの増加方向が同じになるとかかな。
ワードサイズが変わっても低位バイトの位置が変わらないから拡張しやすいってのも
もちろんあると思う。
ハード作ってる時はビッグエンディアンの方が自然な気がするがソフト作ってる時はリトルエンディアンの方が自然な気がする
まあ、FPGAと高級言語を使うようになってからは滅多に気にすることは無くなったけど
>>867 cast するときにも便利。
メモリに書かれた 32BIT整数を 8BIT 整数として取得したい際など、
先頭アドレスが変わらないので、速度効率が上がりやすい。
もし、BIG ENDIAN だとそのようなときに、「3」足さないといけなく
なってしまうと思う。
fstreamでリトルとビッグの切り替えってどうするの
逆にビッグエンディアンの方が自然に思えるのは16進ダンプ見てるときくらいしか思いつかない。
Uint32 u32;
BYTE u8;
u8 = (BYTE )u32;
とするコードがあったとする。u32 を、ポインタで置き換えたいとき、
Uint32 *pUint32;
u8 = (BYTE )*pUint32;
と書くのも正解だが、
u8 = *(BYTE *)pUint32;
と書くのも正解で、実は、後者の方が効率は良い場合があるとされる。
なぜなら、メモリから前者は4バイト読んでから上位バイトを捨てるが、
後者では最初から上位バイトを読まないから。
この場合、Little Endian だと、後者の書き方でも混乱が少ないが、Big Endian
だと何を意味しているのか分かりにくくなる。というのは、
(BYTE *)のようなポインタ型への cast は、旧来の C では、アドレス値自体は
変更せずに、型だけを変更するというのが伝統的な実装だったため
(ただし、C++ の場合、多重継承していた場合は、その原則を破ってアドレス値が
変化する事があるが。)。
BigEndian の場合、最後の書き方の実装に不安定要素が残るように思える。
>>836,
>>839 ありがとうございました。
配列の実態作ったらできました！
_を接頭文字で使うのは結構規模の大きいオープンソースプロジェクトのソースで
メンバー変数の頭に_を使ってたのでやってました。
気を付けます。
話は少し変わるんですが、
>>809でクラスをnewせずに使うというのが書かれていますが、
オブジェクトをnewせずに使うことって結構あるんでしょうか？
普段C#やっているのですが、クラスは基本的にnewでインスタンス化して使うものと思っていたので、（コンストラクタで特に初期化処理がなくても）
>>874 >話は少し変わるんですが、
>>809でクラスをnewせずに使うというのが書かれていますが、
>オブジェクトをnewせずに使うことって結構あるんでしょうか？
どちらかというと、C++では new する必要ない場合は、new しないことが
良い書き方。new は、好きなタイミングで削除したいようなオブジェクトの場合
のみ使用する。構造体やクラスのメンバの中に、別のクラスのオブジェクトが含まれている
ような場合は、new しないのが原則。
ある意味では、そのような習慣があるからこそ、C++ は効率が良いともいえる。
実は、new や malloc は、確保するサイズにかかわらず、大体 170 クロックほど
必要。delete や free と合わせると、合計 300 クロック必要となる。
一方、そのまま、new せずに「埋め込んだ」場合は、基本的に「0」クロック。
この差はとても大きなものとなることがある。
>>874 最初から最後まで存在し続けて、特別な終了処理が必要ないオブジェクトなら、わざわざヒープを確保して実行時に初期化する必要はないでしょ。
あと、staticなオブジェクトのコンストラクタはmain関数の前にグローバルコンストラクタから呼び出されるのだが、
これを利用して、プログラム起動時にやっておきたい初期化処理をクラス内で記述する目的に使うこともあるね。
>>875 さすがに良い書き方っていうのはどうかと思うけどな。
staticなオブジェクトにしちゃうと、初期化の順番が制御できないから、気をつけて使わないとコンパイラ依存のコードになってしまうし。
>>875,
>>876 ありがとうございます。
このあたりのC++とC#の慣習の差異に違和感を覚えていたのですが、かなりスッキリしました。
>>877 必要な場合は new しても良い。でも、クラス Cxxxの中には、文字列の CString
クラスのオブジェクトや、何らかのリストのオブジェクトが複数含まれて
いたりすることも多い。それらのメンバを全て new する場合と、埋め込み
でそのまま使う場合とでは、Cxxx をインスタンス化するときの時間に雲泥の
差が出てしまう。Cxxx が、5つのクラス・オブジェクトを含んでいた場合、
それらを new するだけで、170 * 5 クロックも余分に掛かってしまう。
この数値には、各コンストラクタの処理時間は含まれていないので。
この場合だと、全て new すると、850 クロックも余計に掛かることになる。
さらに、Cxxx オブジェクトがデストラクトされる場合には、合計で、この
1.8 倍程度の時間が new しない場合より余計に掛かることになってしまう。
>>872 思い出したので追加しておく。
Little Endian の場合、
>Uint32 u32;
>BYTE u8;
>u8 = (BYTE )u32;
の代わりに、
Uint32 u32;
BYTE u8;
u8 = *(BYTE *)&u32;
という書き方も出来て、こっちの方が、処理効率が良い場合があるとされている。
しかし、BigEndian だとこの書き方は混乱を招きやすく、かつ、処理効率も
上がらないと思われる。
総合的に考えると、Little Endian の方が処理効率が上がりやすいはずだ。
>>877 >>875はstaticな変数のことははじめから言ってなくて、構造体のメンバやスタックに積まれるケースのように自動的にメモリ確保されるケースのことを言っていると思われる。
cのsetjmpを使ってるコードはc++で例外に置き換えられますか？
>>882 確か、関数呼び出し連鎖の途中の関数が誰も catch せずに放っておけば、
親の関数にまで戻れるはずなので、一応、同じようなことが出来る気もする。
長い間使ってないので、むしろ、setjmp, longjmp がどういうものだったか
の方を忘れてしまったけど。
たしかそれでいけたと思うな・・・。
std::variantって見たんだけどこれいいね。
やっぱ整数なら下の桁から上の桁に向かって書いたり送ったりするのが自然
上の桁とか（整数という概念上は）何桁まで伸びるかわからないのだから
しかし一方人間の認識上は上の桁から見て量を把握したいという要求があり、
不幸にもラテン語が左から書くのにアラビア数字が右から書く慣習だったため
二つの文化を取り持つ玉虫色の解決策としてビッグエンディアンとかネットワークバイトオーダーみたいなものが生じた
スマホアプリとかのパケット解析するとわりとビッグエンディアン使われてる
だってビッグエンディアンはネットワークバイトオーダーでもあるから。
外に出すデータや互換性保ちたいデータは普通そうすると思うよ。
>>890 アラビア数字書くとき右から書いてるの？変わった人ね
数の表記だけじゃないさ。日付、人名、住所の表記も。
単純なASCIIソートで正しくソートできるのはどれかという話にもつながる。
数値を数字に直すとき桁数を調べるには対数とればいいよ。
>>895 数学的にはそれで完全に正しい。
しかしコンピュータには誤差があるので、
itoa() や printf() などを自分で実装するような場合、
よく考えないといけないかも知れない。
log_10(x) で計算すると N 桁だということになったとしても、
itoa() などを実装するアルゴリズムによっては、ある条件の時に
誤差によって、1ケタだけずれるかもしれない。
めったに無いことだが、これで銀行システムや戦闘機のシステムが
ダウンしたりするかも知れないので、数学は重要。
ちなみにオイラは数学は首席だったが、どういう場合にそれが生じるかは
即答することは出来ない。アルゴリズムを慎重に選ばないと、その誤差によって
システム・ダウンやアプリのハングアップ、保護例外などを引き起こす可能性が
わずかだが存在するかもしれない。
n>=0かつ10^n <= m < 10^(n+1)
のときに整数mは十進n桁の数と言える。
不等式に常用対数を適用し、
n <= log_10 (m) < n+1
が得られる。つまり、1以上の整数mに常用対数を適用し、さらにガウス記号を適用したものがmの桁数だ。
m=0のときは一桁になることに注意する。
計算結果の桁数が違うときは、常用対数の誤差とガウス記号の誤差の問題になる。
常用対数の誤差については、有効桁数を使うか、区間演算により、誤差の範囲を見積もることが可能。そこで、誤差の範囲が整数をまたぐかどうかを判定すれば、問題は解決する。
整数をまたぐ可能性があるときは実際に整数を文字列化すれば正確な桁数が算出可能。もしくは任意精度の多倍数演算により自由に精度を高めて再計算すればいい。
ふつー数値から文字列に変換する変換関数そのものに長さを報告させるだろ
文字列の格納先のメモリを確保するときのサイズ見積もりに対数を使う場合は
ワーストケースで誤差が出た場合に備えればいい
具体的なほとんどのプログラムでは常用対数の誤差を一桁以内にすることは可能だろう。
>>911 siv3dみたいなのを探してます
オープンソースで参考になるやつ
スマホゲームならWebGL一択、ハイエンドならUnity、Unreal Engine、CoCo3D、ローエンドならOpenGL, DirectDraw, Haxeといったところか。
>>913 >>914 うーん
一応webgl考えてみます
>>908 変換関数そのものをプログラムしたい場合に、あらかじめ桁数が分かって
いる方が便利 or 効率が良い、場合があり、log_10(x)を使用したくなってしまう。
ところがが、log 計算には誤差が有る可能性があるので、その値を過信するのは
問題だと言うことが言いたかった。
例えば、文字列化する際には、多くのアルゴリズムでは、下の方の桁から
決まっていく。しかし、文字列バッファには、上のケタから左詰で入れて
行く必要がある。となると、最初から桁数が分かっていれば、簡単に
プログラムできるのではないかと言う誘惑に駆られてしまう。
後、10で割っていって余りを使う方法は簡単ではあるが、そのアルゴリズム
そのものにも誤差が有る可能性が指摘されている。
>>916 ＞10で割っていって余りを使う方法は簡単ではあるが、そのアルゴリズムそのものにも誤差が有る可能性が指摘されている。
え？10で割っていくのにどうして誤差が出るの？
>>916 変換関数の中でメモリ割り付けを行うのが好みなのか？
んま実際にわ数値の桁数とか型を見たら一発でわかるんですけどねｗｗｗｗｗｗ
logは人間の感覚特性にマッチした量的尺度を表したり（例：dB）、
情報量の表現に使う（同じものがいっぱいあるという状況は情報量を上げない）という目的が大きい
>>910 coronaがオープンソース化されたらしい
2dだが
>>917 前提として浮動小数点数(float/double など) の話だけど、誤差が無いとは言い切れない
事は分かると思う。
誤差を少なくする方法として、10で割ったりせずに、最初から、
10000.0, 1000.0, 100.0, 10.0, 1.0, 0.1, 0.01, 0.001
20000.0, 2000.0, ・・・
30000.0, 3000.0, ・・・
40000.0, 4000,0, ・・・
のようなものを計算しておいて、比較したり引き算したりする方法が
あるそうな。
浮動小数点値の場合、当然かもしれないが log を使わずに、IEEE の仕様を元に
指数部のBIT部分を読んで利用する方がいいらしい。
桁数が重要になるような銀行や事務系の話？
それなら10進演算だろ
IEEEでも定義されてる
科学計算だと対数で問題ない
>>924 自分で printf() を実装する場合の、浮動小数点数を文字列に直す時の話。
自分でprintfを実装するとか銀行のシステムを作るよりレアケースだな
ここがC++スレということを忘れて内科医？
printfはオーバーロードできるしグローバル以外の空間にも導入できる
Pythonには素の遅いPythonとJITを使った素のPythonよりとてつもなく速いPythonがあるようですが
Boost.PythonでPythonスクリプトを読み込んで実行した場合は素の遅いPythonの速度になる認識であっているでしょうか？
また、Boost.PythonでJIT版Pythonを実行することは可能でしょうか？
>>929 全然その辺知らないけど、
そもそも、python の言語仕様自体がJITを使ったとしてもC/C++ほどの速度には
ならないはずだし、そもそも NumPy 使わないと遅いということは聞いてる。
大体のスクリプト言語は、言語仕様の段階で例えコンパイル言語化しても
どうすることも出来ない遅さが含まれてしまってる。
numpy使えばC並みの速度が出るようにも書けるが
numpy使ったからと言って馬鹿が描くと素のpython以上に遅くなる
用意されてるライブラリ使えと。
バカがイキって作ったライブラリより普通に速いから。
・動的型言語
・自動メモリ管理
・リンクリストと配列を余り区別しない書き方をする人が多い傾向。
これらがあるので、pythonをコンパイル型にしてもある程度以上の高速化は
難しいと思われる。
pythonの速度測定は、やってみたことないけどね。(^_^;)
Pythonにリンクリストなんか無いだろ
Pythonの配列(list)はvector相当の動的配列
実はリンクリストが動的配列より速いケースってC++でも現実にはほとんど無くて、あまり価値のないデータ構造だよ
拡張・縮小にメモリの再確保が不要で抽象化を必要としないから、Cのような生ポインタを好んで使いまくる言語と相性がいいだけ
ハード屋さんが頑張りすぎて必要なくなっちゃったな
でも便利だからforward_listを使うことはある
tupleってメンバ関数で値取り出せないのね。
std::get<N>( t ) ってファンキー過ぎやしませんか。
下手に使うとコンパイルに時間食われそう。
関数やテンプレートで、できることとできないことを
冷静に考えてみな
>>944 テンプレート化すればメンバ関数にすることはできるのでは？
メンバテンプレートにするとtupleをテンプレートに放り込んだときに
t.template get<0>()
と書かなきゃならなくなってこりゃないわーで皆が合意したからじゃ
せめてstd::tuple::get<N>( t ) にして欲しかった。
std名前空間汚れすぎ。
>>943 それは確かに糞仕様だと思うが
テンプレートの意味から言えば仕方ないのかも知れない
(どんな型でも入れられるならテンプレート以外でやるべき)
他のコンテナでも同じように使える様にしたかったんじゃないの
オーバロードで
std::getは固定長コンテナなら何でも使えるぞ
std::pairでもstd::arrayでも生配列でも
>>949 std::getにすることによってテンプレート引数にtupleと見なせる型(pair,array)を使うことができるようにしたいからそうなっている
ちなみにstd::getのユーザーによる特殊化は次から禁止される予定です
ポリモーフィズムを使っていて、ダウンキャストを行うときって
dynamic_castをしてみてnullptrかどうかを判断するのがベストな手順なんですか？
RTTIから実際の型情報を引っ張ってくる手段はないものでしょうか
>>955 もちできるけど、検査したい型を継承した型を渡されたら動かないよ？
>>955 それこそポリモーフィズムで派生クラスのthisを直でもらえばいいんじゃないの
>>955 typeid で type_info 取れるよ。
基底クラスにenum Type 等を持たせてswitchも手の一つ。
処理内容によってはvisitor パターンが使える。俺が知ってるのはこれくらい。
まず、なるべくダウンキャストなんか必要ないようにするのが最初だけどな
>>955 ダウンキャストが必要になるなら、選択はそれしかない
>>955 ダウンキャストしたいんだよね？
なんで実際の型情報なんかを欲しがる理由がわからん
カミカゼキャストについて教えてください。
不意にフレーズが浮かんだのです。
dynamic_castでnullptrなりbad-cast拾うのはお勧めできない。
>>965 nullptrでキャスト可否を確認するのは普通の使い方だろ…
cならともかくc++でキャストが必要になるのはどっかやばいことになってる可能性を考えた方がいい
ライブラリの関数の引数が非constのchar配列で渡したい文字列がstd::stringに入ってるとき
.c_str()をconst_castしてるけどあかんの
opencvを使用して画像処理を行ってるんですが画像データにAWGNを加える方法が分かりません
グレースケール化させて処理をしています
乱数生成などは理解しているんですがその乱数を使ってどのような値として輝度値に影響させるのかが分かってません
よろしくお願いします
visual c++を使用しています
>>969 Mat s;
src.convertTo(s, CV_16S);
Mat noise(s.size(), CV_16S);
randn(noise, 0, sigma);
Mat temp = s + noise;
temp.convertTo(dst, CV_8U);
今こう考えているんですがあっていますでしょうか
srcが原画像、dstがノイズ画像です
>>955 RTTIから実際の型情報を引っ張ってくる手段というとtypeidだね
void func(ios_base* ptr)
{
if(typeid(*ptr) == typeid(istream) { /* ... */ }
if(typeid(*ptr) == typeid(ostream) { /* ... */ }
}
>>968 非constのchar配列を要求するという事は書き換えられる可能性がある
逆にconst付でchar配列を返す方は書き換えないという前提で渡してる
面倒だけどコピーしてから渡すべき
>>973 さすがに神経質すぎる
そのライブラリの関数が文字列を書き換えない仕様なんだったら信用すればよい
そんなこと言い出したら何一つ信用できなくなってプログラムなんか書けん
>>974 書き換えない、という仕様なら最初からconstを要求すればいいだけのこと
constを要求していない以上書き換えられる可能性を考慮するのは当たり前の前提
constついてないってことは内部で書き換えるという明確な意思表示だろ
あと、ライブラリを作った奴のスキルの問題でconstを付けるべきときに付いてないのも仕事でやってりゃ普通にあるぞ
Cのライブラリに渡すのならなおらstd::stringの内部配列を渡すべきでないし
そのようなスキルの低い作者の作ったライブラリの何を信用しろと言われるのか
なにもそう煽らなくても
現場の人間か責任を負う立場の人間かで意見も異なるのがわかるだろうに
責任を負う立場の人間がconstがどうのなんて気にするわけないでしょw
「契約相手がそう言ってるなら信用すればよい。違っていたら相手の責任だ。」で終わりだよ
まあ契約でそうなってても残業するのは作業者だからな。。
バカの言うことなんて信用しないで安全に倒した方が正解だわ。
constは付いてないですけど内部で書き換えはしません
なんて仕様書に書いてあるのか
void displayText(char* text);
文字列を表示します
text : 表示する文字列
これが仮にtextを書き換えてしまうとして、それをコピーで回避できたとしても、
そんなレベルのゴミがまともに機能するとは到底思えん
そんなことを言い出したらキリがない
>>942 1. 要素数を N としたとき、1つの要素の処理に要する時間が O(N) になるか、
O(1) などの違いなので、本質的にハードがいくら良くなっても解決する
問題ではない。O(N) のアルゴリズムは、N が大きくなった場合には、
ハードの良さを台無しにしてしまう。なので、アルゴリズムの選定はとても
重要。
2. 動的配列でも、配列の最後に追加する場合は、リンクリストと遜色ない速度は
出る可能性は十分あるが、配列の途中に追加する場合は、宇宙人でも無理。
3. 逆に、リンクリストの場合は、先頭から数えて、「k 番目の要素」にランダム
にアクセスすることを高速化することは、宇宙人でも無理。
4. 「宇宙人でも無理」の意味が理解できるためには、数学的感性が必要。
理解できない人には理解できないかもしれない。
>>986 問題は、リンクリストの途中に挿入したいとき、予め挿入位置の直前や直後のノードへのポインタを持っていなければならないことだ
そんなケースは現実の開発において殆ど無い
持っていなければ挿入位置に辿り着くまでにO(N)のシーケンシャルアクセスが発生する
そして、リンクリストはメモリアクセスの局所性が欠片もないデータ構造であり、
動的配列と比較してシーケンシャルアクセスのパフォーマンスは極めて劣悪である
テキストエディタのバッファ管理なんてのが
そのケースなんですけどね
>>968 あかん。データを壊したくなかったら、別途コピーしたものを渡すべき。
俺の上司とかconstって何？よけいなもんつけんなっていうおじさんだから内政のライブラリは参照でもconst付いてないよ
>>986 で、そのリンクリストがパフォーマンス的に勝るデータ量はおいくらだと思ってる？
大きめの画像くらいのサイズならデータの中央に挿入するとき、リンクをたどって挿入するより再確保、再配置した方がシーケンシャルアクセスになるから早いからな
ハードウェアの特性によりシーケンシャルなコピーは相当速いためPythonで一般的に扱う問題では挿入だろうが何だろうがリンクリストが勝ることはまずない
よくリストの特定位置に挿入を繰り返してリンクリストの方が速いというベンチマークがあるけど、あれもほとんど詐欺なんだよな
動的配列に多数の要素を挿入するなら挿入する要素数分ブロックコピーでずらしてから空けた隙間に書き込むだけだからリンクリストより圧倒的に速い
予め要素数が分からない場合は、いったん別の動的配列に追加していってから纏めて挿入すればよい
>>994 ＞再確保、再配置
ここ c++ だよね
再配置というのはコピーコンストラクタが働く、てことだよね
挿入のたびにコピーコンストラクタが動くなんて馬鹿のやることだ、という常識が通用するところだよね
>>995 ＞ブロックコピーでずらしてから
ユーザーによるコピーコンストラクタが定義されていたら「それだけでは済まない」のでは？
ユーザーが勝手に遅くすることは関係の無い話だ
その場合リストを使えばいいのでは
コピーが嫌なら別途ポインタの動的配列を持てばよい
それでもリンクリストよりは速いわ
lud20250205173909ncaこのスレへの固定リンク： http://5chb.net/r/tech/1538755188/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「C++相談室 part139 ->画像>2枚 」を見た人も見ています：
・C++相談室 part152
・C++相談室 part154
・C++相談室 part153
・C++相談室 part137
・C++相談室 part133
・自営業 悩みごと相談室 16
・自営業 悩みごと相談室 52
・C#, C♯, C＃相談室 Part93
・自営業 悩みごと相談室 45
・自営業 悩みごと相談室 48
・C#, C♯, C＃相談室 Part95
・アパート経営なんでも相談室【135号室】
・【真剣相談】大阪市営住宅の浴室給湯器設置
・シーバスなんでも相談室 17©3ch.net
・【ハゲ】髪の毛の悩み相談室 in DQO【彡⌒ミ】
・アパートマンション経営なんでも相談室【152号室】
・アパートマンション経営なんでも相談室【137号室】
・アパートマンション経営なんでも相談室【151号室】
・アパートマンション経営なんでも相談室【150号室】
・【皇室】小室圭さん、｢解決済み」声明文 宮内庁に事前相談なし
・【皇室】眞子内親王殿下がお気持ち表明「結婚に向けて家族とも相談しながら進んでまいりたい」★9 [記憶たどり。★]
・【兵庫】男子中学生の下着の中に手を入れ、陰部を触る…学習塾経営者の男を逮捕 進路相談と称して教室に呼び出す [シャチ★]
・【名古屋】いじめ相談も「報復」恐れ学校側は直接指導せず…中1女子が下校後に自殺 2月から教室に行かず別室で授業 [ばーど★]
・東京の梅毒感染者2400人超で過去最多ペースで増加…内訳は男性7割女性3割 無料・匿名の検査相談室を新宿や多摩地域に設置 ★2 [首都圏の虎★]
・【ガルパン】マライ・メントラインの勝手にお悩み相談室「困っています。全力で『ガルパン』を推すために私は何を為すべきでしょう」 [鳥獣戯画★]
・室井佑月「(日の丸マスク)謝罪し訂正したのだけど、お詫びしろ、という意見…。弁護士に相談…」 ネット「被害者面」「実害出てるけど？ [Felis silvestris catus★]
・荒らし相談室
・エイブル相談室
・不登校相談室5
・ハゲミン相談室
・船乗りなんでも相談室・10
・川瀬いにみの人生相談室
・シーバスなんでも相談室71
・シーバスなんでも相談室62
・シーバスなんでも相談室70
・シーバスなんでも相談室85
・シーバスなんでも相談室92
・精神障害者の人生相談室
・◎蟹座の子育て相談室◎
・シーバスなんでも相談室39
・アダルトの何でも相談室
・シーバスなんでも相談室36
・Dr林のこころと脳の相談室17
・綾子88kg♪の恋愛何でも相談室★
・病巣院クルリのお悩み相談室
・明るい悩み相談室 [無断転載禁止]
・必ず誰かがなんたら相談室 Part.3
・苔 コケ 初心者なんでも相談室-4回目
・初心者の為のボート相談室 Part1
・レポ神のピンサロ相談室 ©bbspink.com
・鍼灸マッサージ質問相談室パート１7
・鍼灸マッサージ質問相談室パート11
・【本家】船乗りなんでも相談室 22【内航船】
・鍼灸マッサージ質問相談室パート１６
・【本家】船乗り何でも相談室 20【本元】
・【ﾉｰﾜｯﾁｮｲ】船乗りなんでも相談室 27【内航船】
・初心者優先デジタル一眼質問・購入相談室 53
・【スノーボード】初級者なんでも相談室 ☆6
・08070507787 ★ 真智宇 先生の悩み相談室
・（・３・） ぼるじょあの卓上相談室（・３・）
・初心者優先デジタル一眼質問・購入相談室 109
・初心者優先デジタル一眼質問・購入相談室 103
・初心者優先デジタル一眼質問・購入相談室 157
03:39:11 up 23 days, 4:42, 4 users, load average: 11.51, 11.25, 12.55
in 4.8491039276123 sec
@2.4734370708466@0b7 on 020517
|
