◎正当な理由による書き込みの削除について： 生島英之とみられる方へ:
C++相談室 part137 ->画像>4枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1535353320/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part137
http://2chb.net/r/tech/1531558382/ このスレもよろしくね。
【初心者歓迎】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
こういうヤツがプログラミングするとえらいことになる
フェイルセイフ機構として
スレッドを立てて何分間あるいはレス何個までは
立てた人に限りタイトルを修正できる、
みたいな機能があっても良いかも知れん。
あるいは事前に「これから立てるスレッドは～の後継である」
みたいな宣言ができて、重複や番号の間違いをチェックしてくれるとか。
>>6 それいいな。しばらく放置して、正当スレと認められたら
時間ギリギリで
>>1の内容を書き換えるのにちょうどいい
vector<object*>* func()
{
vector<object*>* vect = new vector<object*>;
for(int i = 0; i < 10; ++i)
{
object* obj = new object;
vect->push_back(obj);
}
return vect;
}
若干うろ覚えなんですけどこんな関数があります。ポインターを収納したベクターへのポインターを返すというものです。
まず質問なんですけど、関数内でnewして確保したメモリアドレスを返すってこれあまり良くないこと……ですよね？それともよくあることでしょうか。
それともう一つ。仮にmainなりどこかでこの関数の戻り値を受け取って利用したあと、メモリ解放はどうすればよいのでしょう
例えばdelete vectだけか、それともobject*をループで回して全部にdeleteすればいいのか、それとも両方やらにゃならんのか
よろしくお願いします。
どなたか c++でのソケット通信を使った複数人が使えるチャットのサンプルコード持ってる人いませんか？
ネットで色々調べてるんですけど、tcpじゃなくてUDPのやつだったりwindowsじゃなかったりcだったり書いてあることが難し過ぎたり...
そもそも1:1のコードばかりで複数人対応のサンプルコードが見つかりませんorz
複数人対応にするにあたって、複数のソケットを用意するのとselect関数が必要になると思うのですけど、selectの方はおそらく理解できています。
複数のソケットからアクセプトされるところの流れが全然分からないです。
今自分が書いてみたコードだとスタックオーバーフローというらしい現象が起こってしまってます。
>>9 ループで回して解放しないとダメ
JAVA脳だと放置するところだけど
>>9 どっちもnewするなら両方deleteしないといけない（もちろんobjをループでdeleteするのが先
何が良い・良くないは自分で考えた方がいいよ
>>11 アクセプトされる、ってのは認識がおかしい
listenしたソケットに来た接続要求を、acceptで受け入れてクライアントとのセッションを開始する
サーバーはlistenで要求待ちするソケットと、acceptでクライアントと通信するソケットを持つ
クライアントはconnectでサーバーに接続して通信するだけ（ソケットは１つでよい）
>>11 コードさらした方が話が早いよ
それより複数人だとどういうトポロジーで繋ぐの？
例えば4人だとどうなる？
>>10-11 次の本が、似たような状況（たしかレーシングゲームだったか）のサンプルを載せていたと記憶しています
https://www.amazon.co.jp/gp/product/4774117544/ Windows の winsock も UNIX のバークレーソケットと似たようなもので、若干の修正は必要ですが、そこはネットを参考にして書きなおせる範囲だと思います
この本は初版が 1992 年頃に出たときから htons()/ntohs() が書いていない、とボロカスだったんですが、私はとっても好きだったのです…
listenで待ってるｽﾚｯﾄﾞ（もしくはﾌﾟﾛｾｽ、こっちならあとでfork()する）がいる
listenで待ってるｽﾚｯﾄﾞやﾌﾟﾛｾｽからacceptして
peerと新しいｿｹｯﾄで通信するｽﾚｯﾄﾞを作る
もうｺﾚで分かる
>>9 ゲームエンジンの本には、よくメモリープールの実装が載っている。
こういう機能を抽象化した、モジュールを誰かが作っているはず
Effective とか、デザインパターンの本も読んだ方がよい
サーバーが自分用のソケット一つと複数個のユーザー用ソケットを作成し、ユーザー 一人につき一つのソケットが割り振られるイメージでした。
こんな感じにpublicにもmainいてもエラーにならないのはどうしてですか？
Main.h
class CMain
{
public:
int main(int argc, char* argv[]);
};
Main.cpp
int main(int argc, char* argv[])
{
return 0;
}
一般関数のmainとメンバ関数Cmain::main()は別物だろうよ。
>>20 名前空間が違っていて区別がつくから同じ名前のものがあっても大丈夫。
>>13 >>14 ありがとうございました。やっぱ両方なんですね
>>18 メモリープール初めて知りましたがこんな方法あるんですね
あと上司がおよそ20年に渡って継ぎ足し継ぎ足ししてきたすぱｇ秘伝のコードなので今更構造変えられんのです……
上司のコードに文句言いつつデリートも知らん奴がなんか言っとる
>>24 リファクタリングの機会を設けないと秘伝が負債になるのがこの業界
auto pointer, smart pointer ?
>>19 1:1のソケットを4つ用意すれば4人でチャットできますよね？送ったメッセージをサーバーサイドが受け取って他の3人のソケットに送るイメージです
あー、それなら合ってるね
そのままのイメージで書いてみればいける
>>32 それぞれのソケットの中身で違うのはポートだけってことで大丈夫ですかね？
まぁポートだけ、というかリスニングの処理だけ特殊とは言えるかも
関数からreturnされる値は必ず自動的にmoveされる？
計算機S 192.168.0.1:40000 ⇔ 計算機A 192.168.0.16:41769
計算機S 192.168.0.1:40000 ⇔ 計算機B 192.168.0.17:61544
計算機S 192.168.0.1:40000 ⇔ 計算機C 192.168.0.18:61568
計算機S 192.168.0.1:40000 ⇔ 計算機D 192.168.0.19:63490
↑ ↑最初に接続する計算機のﾎﾟｰﾄは通常自動的に空き番が使われるようにする
計算機Sからみてpeerは
計算機Sが受付を待っているﾎﾟｰﾄに
接続する必要がある
え、TCPいうてたしサーバーのIPとポート指定して接続してつなぎっぱなしを想定してたんだけど違うのか
いちいち切って繋ぎ直すなら別だけど
>>37 値が rvalue でムーブコンストラクタが存在するならばムーブされる。
(lvalue も状況によっては rvalue になることもある。)
ただし、 RVO の適用条件に叶う場合は RVO が適用されるかもしれないのでコピーもムーブもされないことは有りうる。
Hogeというクラスがあったとして、
Hoge getHoge();
という関数があるときに、
Hoge &hoge = getHoge();
と参照で受けて問題ない？
ダメ
getHoge()の返却値はprvalueなので
constのない左辺値参照で受けることはできない
右辺値参照か、
constのついた左辺値参照が必要
>>43 getHoge() の返却値は一時的なオブジェクトなので
原則としては完全式の終わりに解体されることに
なっているが、
>>44 の述べる通りの方法で参照で受けたときに限って
例外的に寿命が延長される規則がある。
参照のスコープの終わりがオブジェクトの寿命になる。
RVO が発動するだろうから、そもそも参照で受ける意味があんまり無いと思う。
書籍スレで聞いたらスレチ（？）と言われたので質問させて下さい(m´・ω・｀)m
C++で新し目（出来れば2016年以降に発売したもの）の入門書でオススメがあれば教えていただきたいのですが…
よろしくお願い致します。
Effective Modern C++は読んどいたほうがいいけど入門書じゃねえな
うーん
>>43 全く問題ない。
規格にもしっかり書いてある。
>>46 あるわけいだろ
C++は入門言語じゃない
>>46 このへん
ISBN-10: 4797394633
日本人の著者では柴田氏の作風が俺的にはお奨め
入門だからって抜いちゃいかんことを押さえてる
ISBN-10: 4798119598
C++といえばこの人
出版が2011年とやや古めだが
プログラミングの地頭を鍛えてくれる
そもそも、何も知らない初心者がなんで「2016年以降」とか限定するんだ？
何か根拠があるわけでもないだろう。
古い本だと古い規格で説明されてるから、初心者には良くないって点はあるね。
#include <cstdio.h> みたいな中途半端な古さは特にやっかい。
『プログラミング言語C++』第4版を読んどきゃええじゃろ、と思ったけど
初版が2015年3月だから「古い本」だな。
> #include <cstdio.h>
こんな時代あったか？
ときどきＣがわかってない日本人が入門書書いてたりして余計路頭に迷わせたりする
>>48 effective 「modern」 c++ って良いの？
ただの effective は良いってほぼ全員認めてるが、more とか modern はあまり勧められないしどうでも良い本なのかと思ってた
math.hとcmathってどっちがいいの？
そもそもcmathインクルードしてもM_PI使えんしよく分からない
>>58 effectiveならいいっていう老害なんだろ
>>52 柴田の本は辞めとけ
初心者には無理
あれは大学の講義でかわされるやつ
>>61 初心者つーかオマエだろ？
大学の授業についていけない二回転５
難癖ばっかりつけてないで
幼児用のC++の本を出してみな
>>59 cmath を使うべき。
C のヘッダは互換性のために残されているだけで、積極的に使うようなものではない。
M_PI は C の規格にも C++ の規格にもないマイクロソフト独自の拡張だから、
マイクロソフトがどういう気持ちで用意しているのかは知らないけど、
_USE_MATH_DEFINES マクロを #define しておけば Visual Studio では有効になるらしいぞ。
https://msdn.microsoft.com/ja-jp/library/4hwaceh6.aspx C++17でcmathが大幅強化されたね
ISO/IEC29124の特殊関数を取り入れた
>>58 modernはC++11以降を使うなら必読だぞ
むしろ素effectiveやmoreの方が古くてあんまり役に立たなくなってる
>>63 gccの独自拡張じゃねえの
むしろMSはそれに合わせてる
長いものには巻かれろ、ってヤツだ
長い方はMSじゃなくgcc
柴田の本は昔から悪書扱いされてる
あえて読むことはないと思うわ
昔は読んでたよ
20年以上前かな
いまでもjavaやc++のやつは図書館でたまにペラペラしてみるけど
読みづらくて全然合わないと感じる
同じジャンルで山田祥寛の本があったらそっちを読む
つまり読んでないってことだろ
図書館でペラペラってなぜそんなことをするんだ
C++を20年以上やってるんだろ
人にC++言語について教える時に、人口に膾炙した書籍の表現を使うのが無難だからでしょ。
>>56 すまん <cstdio.h> は変ね。<stdio.h> と <cstdio> が混ざってしまった。
<cstdio.h> というヘッダが存在する処理系もあるか知れんけど、
#include で使えと教えてる本はないだろうな。
主旨は「半端に古い本だと」で変わらないけど、良い例が出せんわ。
>>72 それを言うなら
<stream.h> //cfront 1.0
<iostream.h> //ARM
<iostream> //C++98
じゃね？
質問なんだがコンパイル時間の観点から見て、ヘッダをインクルードするときは必要でない限りcppファイルでincludeするべき？
#includeのネストを避けろということか？
そう主張する連中もいるが、俺は反対
>>74 ちょっと質問の意図がよくわかんないんだけど、逆に言えば
「ヘッダファイル (*.h) が他のヘッダファイルを include するのはコンパイル時間を増大させるか？」という意味？
あんまり関係ないよ。
よっぽど大きいプロジェクト (gcc とか) ならちょっとしたことで結構な差が出ることは無いとは言えないけど、
それでもプリコンパイルヘッダとかを活用すればだいぶん時間は短縮できるし、
更に高速化したいならキャッシュサーバを使うコンパイラもある。
https://github.com/yrnkrn/zapcc ・ 小さいプロジェクトでは気になるほどの差はない
・ 大きいプロジェクトではツールで解決しよう
例えばstd::stringをhoge.hでは使わずhoge.cppのみで使われている場合
hoge.hで#include<string>と書くと、他のファイルからhoge.hをincludeしたとき無駄が出るはず
だからhoge.cppで#include<string>と書いた方がいいのが、それとも些細な差なので全部hoge.hにぶち込んでもいいのかということ
なるほど、実装で使うだけで宣言にはいらないものか
だったらhoge.cppで#includeしたほうがいいね
http://www.geekpage.jp/programming/linux-network/select.php なんかソケットごとに違うポートを割り振るものだと思ってたのですが、
listen(srcSocket, 1);//第二引数はクライアント上限数
この第2因数をいじったら同じポートでも普通に接続できました。
このまま気にせずselect処理書いていっても大丈夫ですかね...？
通信関係あまり知らないのでバグったりするとどうなるか分からずちょっと怖いです。
相手用のソケットは
int dstsocket[5]の様な感じで作って中身は全部一緒です
>>78 その場合だと .cpp に書いた方が当然良い。
プリコンパイル済みヘッダを、いちいち書かなきゃいけなくなるのがあれだから使わない方がいいと言われたことがある
なぜそれでコンパイルが遅いって文句言ってるのか分からない・・・
書いても大丈夫だが、そういうやりかたにするならselectでﾌﾞﾛｯｸしないように注意したほうがいい
selectをﾌﾞﾛｯｸしたままの状態にすると、当然、そのあと永遠にacceptされない
きっとｽﾚｯﾄﾞにしたほうが簡単
>>78 hoge.hでstd::stringを使ってないのに#include<string>を書く、という発想が理解できない
#include<string>はstd::stringを使ってるところに書く、使ってないところには書かない、でいいじゃん
変更があって使わなくなったのに#includeは残ってるのがありがちで嫌なところ
静的解析とかで指摘して欲しい
>>80 変な心配せずに書いて覚えた方が早いよ
あと最初TCPって言ってたよね？
もしTCPで通信ごとにポート変えなきゃいけないなら、Yahoo見に行く時毎回ポート変えてんの？
HTTPは80番って決まってるやろ？
あと何のためにその第二引数があるの？
恥ずかしながら char と signed char が違うものだって知りませんでした…（独り言）
>>88 signed char とか unsigned char とか明言されず、ただ char としか書いていない場合、
その char が signed char になるのか、それとも unsigned char なのかは
「処理系依存」・コンパイラ依存だった、という経緯が C の時代からあったのでした
「signed char でも unsigned char でもない『「alternative な char』がある」
という意味ではないのです
"alternative char"…なんかだ魅惑される響きだと感じ入ってしまうのは、私だけですか…
>>90 char は signed char でも unsigned char でもないです。
C でも C++ でも。
？
charとsigned charとunsigned charは全部別の型だろ。
char は (型システム的には) signed char でも unsigned char でもないけど、
符号付きか符号なしのどちらかではあり、
その表現は処理系によって signed char か unsigned char のどちらかと実質的に等しいことになってる。
だいたいは暗黙の型変換が自然にうまいことやってくれるんだけど、
C++ だとオーバーロードの解決にかかわるところとかややこしいな。
std::byteとかいうゴミはどう使えばいいんだ？
>>89-90 そういう話じゃなくて文字列型にはchar, unsigned char, signed charの3つがあるって話じゃないの？
>>94 数値計算のための演算子が定義されてないのが重要なポイントだな。
なんらかの入力をビットパターンとして処理したいときに使える。
ビット表現に関する C/C++ での規則は未定義の部分もあって、
数値とビット表現の対応付けは処理系 (アーキテクチャ) によるので、
数値としての演算の結果 (の数字をビットパターンとして見た場合) は一意ではない。
std::byte でデータを保持しておけばうっかり数値計算してしまったりしない。
std::byte があることで特にできるようになることがあるわけじゃないけど、
うっかりを防止するために防衛的に使うもんだと思う。
>>91 https://ideone.com/5zhQcP …なるほど、そういう風に解釈するんですか！？
また一つ賢くなりました
>>97 もうひとつ面白い点としては、そこから void f(char c) の定義を消すと
char c = -12; f(c); という呼出しは解決できずエラーになる。
char, unsigned char, signed char は「順位」が同じなので、
呼出し候補としては同格になってしまい、ひとつに絞れないから。
もしも char が unsigned char か signed char かのどちらかなら、
どちらが呼び出されるにしてもひとつには絞れるのでこういう問題にはならないのだけれど。
ストリームに対する operator<< が char と unsigned char と signed char のそれぞれに用意されているのは、
そういう曖昧さが起こらないようにするため。
>>95 文字列型はchar
signed char, unsigned charは小さい数を格納する
「文字列型」という言葉を使うと語弊がある気がするぞ。
現在時刻(またはPCやexe起動からの経過時間)をmillisecondsで取得する方法ってありますか？
mm-dd-yyみたいな形式ではなくて全部数字で取得したいです
exeだからwindows
つまりGetTickCount()
なんでCの頃にcharを符号付きを許したのかが謎
文字は負の値にならないとかいうルールまで定めながら
charをunsignedと定義することを頑なに拒んだ古代の連中は一体何を守ろうとしたのか
charのsignedとunsignedの処理系依存の混乱さえなければ今でもmalloc()はchar*（サイズ1の型のポインタ）を返してくれて便利だったかもしれんのに、
asciiは7bit
いまでもC++はどんなｵﾌﾞｼﾞｪｸﾄでも(char*)でｷｬｽﾄすることは
仕様で許されてる
>>99 そうであればよかったんだけどstreamsでの扱いは全部文字型なんだよな。
おかげでuint8_tをstreamに出力したら文字が出てくる羽目に。
>>106
Ｅ Ｂ Ｃ Ｄ Ｉ Ｃ は ８ b i t じ ゃ わ ！
>>106
キ ャ ス ト し た だ け で は c h a r * か な に か の 中 間 変 数 に 代 入 せ ね ば
標 準 の 言 語 規 格 で は + + や - - が で き ん ｽﾏﾝ訂正；
誤： キ ャ ス ト し た だ け で は c h a r * か な に か の 中 間 変 数 に 代 入 せ ね ば
正： v o i d * 引 数 は キ ャ ス ト し た だ け で は c h a r * か な に か の 中 間 変 数 に 代 入 せ ね ば
知見が狭い低学歴知恵遅れの世界では
伝統的なﾃｷｽﾄがacsiiをさしてることすら
わかってないらしいわ
普通に古代のﾈｯﾄﾜｰｸで7bitのﾈｯﾄﾜｰｸとかあったからな
char*の変数に代入しないと
ﾎﾟｲﾝﾀｰをｲﾝｸﾘﾒﾝﾄできないとかあたりまえやんけ
C++とか関係ない
相変わらず低学歴知恵遅れはなにをいってるのか意味不明
昔、なんでﾒｰﾙがiso-2022-jpしかかたくなにﾀﾞﾒといわれてたか
きっとその理由も分かってない
>>110 えっっつ！？
伝統的なテキストの7 bitの文字コードはISO 646のことじゃないの；
ていうかASCIIが7 bitで表現できることはなんでCの頃にcharを符号付きを許したのか（
>>104）を完全には説明しない
charをunsguned charにキめとけばアドレス全般を現す型としてのvoid*なんてものを別途作り出す必要も無く全員ニッコニコー☆だったかもしれんのに…
>>106 「どんなｵﾌﾞｼﾞｪｸﾄﾎﾟｲﾝﾀｰでも」の間違い？
MSBに1がたってるｵｸﾃｯﾄが1つでも入ってたら
それはﾊﾞｲﾅﾘだ
ｵﾌﾞｼﾞｪｸﾄを(char*)を普通にｷｬｽﾄできる
低学歴知恵遅れのどうでもいい感想やどうでもいい願望なんか関係ない
そういう仕様だからな
安全なPODは普通にｷｬｽﾄされることがある
7ビットでも8ビットでも表現できる言語の数は変わらないから
情報系大学3年生
恥ずかしいことに今までやっていた言語がC++じゃなくてCだったことを知った…
（だってVisualStudio起動するときにC++開発モードを選ぶように言われたんだもの）
そういうわけでC++はどんなもんかなと本屋でちらっと明解C++を手に取ってみたら全く別物じゃねえか…
わかんねえよ……ネットで調べてみたら複雑らしいし
Cならatcoderで緑色になるくらいは書けるけど、でも就活のときCしか書けませんC++わかりませんってかなり致命的？
>>104 単なる char を int に変換する時に、符号拡張でも0拡張でも、
そのCPUで都合の良い(速く動作させることのできる)命令を使っていいよ、
っていう部分を重視したんじゃないかな。
文字コードは負にならないから、どっちで拡張しても結果に違いは生じない、
という保証が先にあっての話ということで。
MSBが1になる可能性がある8bit値なら signed/unsigned を明示しろと。
>>112 俺はむしろ「値を格納することを目的としない、抽象的な void* ポインタ」が
総称ポインタとして追加されたのを好ましいと思うけど。
「char* には他のどんなポインタもキャストして代入可能、そのポインタを介して
メモリアクセスすることも許す」の方が苦し紛れな気がする。
もちろん、このルールがないと本当に苦しい、ないと困るものだけど。
>>120 C++は、Cの後置インクリメントという名のとおり
最初はCのつもりで使ってよく
次から少しずつCに対する拡張を憶えていけばよい
Cをマスターしている人にとって
ごく自然に入っていける言語だから
慌てないでじっくりやってみそ
C++の発案者（通称、禿）が書いている有名な本が
まさしくCがわかる人のための論調だ
ISBN-10: 4797375957
就活では何言語が使えるかより
何を作ったかが大事
C++使えます、なんて新人が自称してても
たいていすぐボロが出るし
>122
書籍の紹介をする際にAmazonさんのページへのリンクを貼る人は多いけど、
ISBNだけでタイトルも書かないパターンは初めて見たよ。
『プログラミング言語C++』第4版だね。
おかげで ISBN-10 と ISBN-13 という2種類のISBNがあることも知った。
uint8_tとint8_tを使う。
移植性が良くなる。
んだ
cstdintとかcinttypesとか使えば良いじゃん
>>120 私はC++を覚えるのに20年くらいかかっています、アマチュアベースなので
みんなそうだよ
C++はC with Classesから30年以上経っているが
未だに発展途上の言語で
新しい機能がどんどんできているから
文法覚えてもそこがスタート地点
推奨される最先端の実装例を見てみたいがどこにそういう例があるのかも知らない
だれかしらないかなあ
cl /std:c++latestや
clang-cl -Xclang -std=c++2aとかか？
レス㌧クス今全てがつながったわC++完全に理解した！
char→signed int変換を符号拡張でやっても良いという余地を残しておけば、
char→signed int変換を0拡張でやる命令が無いアーキテクチャーであっても、
（たまたま）使う文字コードセットがcharのMSBまで使わないやつ（acsiiとか）であれば
（運よく）変換を1命令で済ませられる
しかしcharをunsigned charとする案に対するアドバンテージはそれだけ…
我々は滅び去った腸古代のアーキテクチャーの痕跡を毎朝目の当たりにしているわけや
>>130は、
>>121へのレス
痕跡というのは、C++において（オーバーロードとの絡みで）charがsigned charでもunsigned charでもない別の型である件のこと。
>>127 職業的に使う言語とアマチュアベースで使う言語は接する時間が違うから、上達の速度も違う
C++はCに擬態することで職場でも家でも継続的に新規の機能を試せたから成功した
D言語は職場で12時間C/C++を触った後に家に帰ってD言語脳に切り替えねばならなかったからめんどくさがられて失敗した
この反省を踏まえ、Pythonはいつでも初心者モードでも問題なく使える簡単言語になったそうな
（ちな職場でこっそり使い倒せる言語はやっぱPerlとJavaScrip(ｹﾞﾌﾝｹﾞﾌﾝ
Linux プログラミング・インタフェース、Michael Kerrisk、2012
翻訳者・千住治郎
C++11/14 コア言語、江添 亮、2015
組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド、MISRA‐C研究会、2006
これらが、神の書！
膨大なOK・NG パターンを列挙している
これらの本を持って、数年山籠もりすべし！w
初心者用の文法書なんて、一部分しか書いていない。
氷山の一角
ドワンゴ江添の本でも、詳細には切りがないので省略しますとかw
無限に出てくるw
こういう本を書ける、Kerrisk・千住・江添は、頭がおかしくなってるはず！w
「Finnegans Wake」の著者、James Joyce も、
翻訳者の柳瀬尚紀も、頭がおかしいと思ったけど、
132 の本は、まさにそう
頭がおかしくないと、これだけ書けないw
vcのwriteFileとかの関数って非同期の時戻り値とかどう処理すべきもんなの？
waitforsingleobjectでまつのはセオリーっぽいが
そこにたどり着くまでに非同期の処理が終了とかまだ終わってないとかいろんなケース想定されるじゃん？
MSDNのWaitForSingleObjectのページ読んだ？
実際に書いてみた？
>>135 WaitForSingleObjectまでに非同期処理が終わってたらWaitForSingleObjectからすぐに抜ける
非同期処理が終わってなければ終わるまでWaitForSingleObjectで待つ
要するにWaitForSingleObjectから帰って来たら非同期処理は終わってる
いまだにﾒｰﾙで昔半角ｶﾅを使ってはいけないといわれてた理由すらわかってないのが
よくわかったわ
EBCDICは8bitとかいってるぐらいだからな
そんなもん意味不明なﾊﾞｲﾅﾘだからな
当然utf8も意味不明なﾊﾞｲﾅﾘ
頭悪い知恵遅れでも分かったふりしてﾃｷﾄｰなこと書けるのが
2ちゃんねるだからな
2ちゃんねるは頭の悪さを自白するのに最適
>>136 書いてみた
パイプを使ったデータのやり取りをしようとしていて
writeFileだけでなくConnectNamedPipeだったりの非同期処理の異常系で困っている
通常の操作はおそらくできてると思うんだが....
>>137 やっぱりそういうことで良いんやね
>>130 >C++完全に理解した！
小悟を経て大悟に至る長大なステップのほんの一段に過ぎない・・・
C++erは3種類しかいない
C++を理解せずに書いている素人、C++を理解したと勘違いしてる素人、いつか人類はC++を理解できるのだろうかと日夜考え続けている素人だ
>>141 .0.5%ぐらいは真のC++プログラマーがいると信じたい
今まで出会ったことがない
>>141 「完全な理解」に到達できないようゴールを動かしつづける黒幕、
てのがいそうな感じね。
日々の学習が新規格に追いつかないヘボの愚痴だけど。
実際これ本物じゃないかと思うよね
http://www.kh.rim.or.jp/~nagamura/misc/stroustrup-interview.html
javaに必要だったのはGCじゃなくてデストラクタだったりして。
噂によると、参照切るために使い終わったらオブジェクトにNULL入れてるらしい。
それってfreeと違うんかい？
進撃の巨人、エンドオブザワールド見たら、ミカサがいきなり不倫してて子供までいる設定に代わっててびっくりしたわ。
原作ではそんな子じゃなかったのに。
>>120です。レス少し遅くなっちゃったけどレスくれたみんな詳しくありがとう
とりあえずじっくり勉強してみることにするわ
このご時世、就活を意識するならPythonのほうが優先度は高そう感じがするけど…
就活についてのアドバイスしてくれた人がいるけど、納得した。
「できます」「つかえます」って基準が不明瞭だからさして効果はないか。
ちなみにどんなものを作れば有利に働くかな？
趣味でプログラミングをしているけど何か作りたいものがあってはじめたんじゃなくて競技プログラミングが面白そう、という理由ではじめて競技プログラミングをメインにやってた
Cでならシューティングゲームを作ったことはあるけどこれはあまり就活では役に立ちそうにないかな
>>150 査読論文
100万PVを超えるwebサイト
アプリのレビュー経験
上記以外はマイナスになるだけ
会社によるし何したいかによる
言語仕様やコンパイラに強い人が欲しい会社もあるし
ハードウェアやアセンブリレベルに強い人が欲しい会社もあるし
CGとか映像処理に強い人が欲しい会社もあるし
Windowsのことなら任せろって人が欲しい会社もあるし
OSS界隈の事情に詳しい人が欲しい会社もあるし
コード土方なんかよりパワポのプロが欲しい会社もある
頑張って
組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド、MISRA‐C研究会、2006
日本の大企業から、C の専門家、数十人が集まって、この本を書いたけど、
規格について詳しい人は、いなかった
規格書の条文を組み合わせたときに、どういう現象が起こるかわからない。
このレベルの人では、その恐ろしさをよく知っている
ルールの組み合わせ爆発が起こるから、無限！
だから規格を保証できない
よく、わからなかったから規格書を読めっていう奴がいるけど、
そういう奴は、組み合わせ爆発の恐ろしさを、何もわかっていない
言語の入門書を読んで、文法だけを知っている人なんて、いらない。
文法だけじゃ、仕事はできない。
仕事とは、システムを作る事だから
だから企業は、コンピューターリテラシーのある人が欲しい。
OS の知識。システムの運用構築。
デザインパターン・アルゴリズム・データベースなど、すべての範囲
大量の勉強・資格も必要。
その人が到達したレベルの証明書
Ruby が出来たら、Python もわかる。
Rubyよりも面倒くさいのに、なにも、Pythonで書く理由がない
AI・数学系の仕事があって、初めてやるもの
float 変数にずっと、1を足し続けていくと、どうなるでしょう？
ちょっとした質問をされても、勉強していないと答えられないだろ
＞float 変数にずっと、1を足し続けていくと、どうなるでしょう？
答えてどうぞ
ちょっとした質問なんだろ？答えて
120 みたいな「入門書を読んで、出来ます」っていうような奴は、よくいる。
文法をかじったのと、システムを作るって言うのは、全く違う
コンピューターリテラシーが無いと話にならない。
文法よりも、情報処理資格を取った方が、よほど使える
8進数の637 を、16進数で表示しろとか、こういう問題
文法よりも、システムを作るための基礎体力がある人。
登山するのにも、まず基礎体力だろ
>>157 逃げんな答えろ
＞float 変数にずっと、1を足し続けていくと、どうなるでしょう？
正確に答えて
>>158 プログラムで実行すればいいじゃん
馬鹿？
>>150 ＞Cでならシューティングゲームを作ったことはあるけどこれはあまり就活では役に立ちそうにないかな
そっちの方が大きいと思うが・・w
ソフト一本作ったかどうか、ってのは大きいよ
>>150 > Cでならシューティングゲームを作ったことはあるけどこれはあまり就活では役に立ちそうにないかな
そうかなあ？何処に就職しようとするかで変わると思うんだが、しかし、そこまでできるなら結構有利なネタになると思うんだけど。
とにもかくにも何かを「完成させる」ってのは強いと思うよ。
プログラミングに関する色んな理屈は研究されているけれども、
現実の問題に対して適用できる能力はまた別問題だからね。
深く知っているやつよりも目的を達成できるやつが偉い。
もちろん深く知っている方が色々な問題に対して出来ることは多いはずだけど、
実際にやったという見える実績がないと評価しようがないもの。
評価基準は評価する側のことだから、
ひょっとするとあまり気にしない評価者もいるかもしれないし、
高く評価するかもしれないということはある。
でも、無かったら何にも無いだけ。
>>163 ＞とにもかくにも何かを「完成させる」ってのは強い
強いですね…
ある程度できてしまうと、情熱が失せるというか妥協するというか手を抜くというか
それを完成形に持っていくのには知性ではなく意志が必要だとおもいます、そして現在は知性（主知主義）よりも意志（主意主義）を評価する時代かと
私についていえば直近は
http://2chb.net/r/tech/1524570314/795-796 に執心していたのが、α版
http://2chb.net/r/tech/1434079972/52 ができてしまうと、ある意味どうでもよくなって、β版
http://2chb.net/r/tech/1434079972/53 を書き上げた頃は、変てこな義務感だけでいわば青息吐息で動いていた感じです、たぶんこれ以上手をいれることはないでしょう、全然未完成なんですけれども…
まるでプロには知性が足りないとでも言わんばかりだな
君の書いたソレは売り物になるレベルのソフトなの？
>>165 の意図を正しく読み取ってないかも知れんけど…。
プレイヤーにとっては、凄いプログラムで動いてるゲームより
～さんがキャラクタ描いてる、～さんが声アテている、の方が
購入の理由や評価の基準になってる、という面では
「プログラムより素材」と言えるかも。
テトリスやぷよぷよが売れたときは、
また別の意味で「プログラムより素材」だったんだけど。
現在ではマインクラフトなどかな。
技術的にスゲーって感じたゲームはPS2の「大神」だったかな。
それ以後あんまり遊んでないし。
君らいっぺん3Dのゲームがどういう技術で成り立ってるか調べたらいいよ
全く想像つかないのに適当こいてるだろ？
>>171 しらべてみたら監督技術、プロデュース技術、ディレクション技術なんだな。
一番重要なのは資金調達技術だって。
思ってたのと全然違うわ。
ゲーム業界ではパワポを使いこなせないと会議で発言権を得られないって聞いたことがあるな。
そういえばジョブス氏も皆さんの前でお話しするときはパワポ使ってたよね。
WindowsよりOSXというお話をするときでさえ、スクリーンにはパワポが映ってた。
話がいつの間にか売れるゲームの話になってる？
元の話は学生が就活時にCでゲーム作った事が役に立つかって話だったと思うが。
>>176 なってないw
QZと165に釘さしたかっただけ
別に趣味グラマを否定したいわけじゃないけど、一本人が使いたがるようなレベルのソフトを作ろうとすると、言語の知識だけではない様々な現実的な問題に直面するだろ
それを乗り越えたかどうかってのは採用担当の評価に大きく関わってくると思うけどね
はっきり言うと、QZのレスは、それを乗り越えるのは意志だけ(つまりソフトを作り上げるために必要になってくる知識など、言語の知識以外には無い)と暗に決めつけてる
最近そういう傲慢な趣味グラマがC++界隈でよく見受けられるけど、そういうの良くないよマジで
それでｺｰﾄﾞはもうすでに自分は書けるもんだと勝手に思い込んで
まともな教育を受けてない低学歴知恵遅れのｱﾎなくせに思い上がってるｳﾝｺが
この板にはわんさかいる
視野が狭いとそうなる
低学歴知恵遅れはどうしても視野が狭くなる
知見の範囲が限られるからな
>>178 ＞QZのレスは、それを乗り越えるのは意志**だけ**
>>164 ではそうはいっていませんよ、意志の重要性を主張していますが、知性（＝知識）が不要とはいっていない、ちょっと言葉が足りなかったのは認めますが
知性がなければ、そもそもプログラムを記述することすら出来ないでしょう？
文脈としては
>>150 を応援している内容です
「根性論」の気配を感じて反感をもたれているのだろうとは推察しますけれども
質問してるﾔﾂ未満のとにかく程度の低いｳﾝｺが
この板で幅をきかせてるのが一番の問題
暗にマウンティングしようとしすぎなんだよ、聞かれたことだけ答えてろ
>>167 いや、俺はゲームプログラムは作れるが
絵や音楽は無理だわ
gperfをconstexprで実現するライブラリない？
>>153 数十人も集まったら臨界起こる。
危険。
>>170 ぷよぷよにしろテトリスにしろ完全に動くから売れるんだぞ
数年前に家庭用機に動きもっさりバグだらけのテトリスがあったが発売数日で誰もやってなかったよ
ﾃﾄﾘｽごときでcなんか不要
javascriptで十分
http://codepad.org/GePSyxwv ← ｺﾚでできあがり
このｺｰﾄﾞをﾒﾓ帳にｺﾋﾟﾍﾟしてaho.htmlで保存
↓
aho.htmlﾀﾞﾌﾞﾙｸﾘｯｸ
↓
ﾃﾄﾘｽ起動
以前の話
http://2chb.net/r/tech/1531558382/942,943 やりたいこと
http://2chb.net/r/tech/1524570314/713 質問
一つの bitset または vector<bool> に対して、異なるスレッドから集中してビットをオンしまくる、ということをして矛盾が発生することはありますか？
やりたいことはエラトステネスのふるいなので、この場合オンしたあとオフすることはありません
こういうことをして大丈夫かどうか調べてみたけれどもよくわかりません
bitset
https://ideone.com/12V4WY vector<bool>
https://ideone.com/iVcLWd 付随しての質問
biset や vector<bool> というのは、一つの物理バイトに対して複数の bool を詰め込んだ作りとして実装されているのでしょうか？
この場合
bitset[index] = boolean,
とか
vector[index] = boolean
（operator[] が「bool の参照」？を返す、みたいな感じ） は実際にはどのように記述されているのでしょうか？
>>195 > 異なるスレッドから集中してビットをオンしまくる、ということをして矛盾が発生することはありますか？
矛盾というのがどういう状況を想定しているのかわからないけど、
言語仕様上はデータ競合が起こりうると解釈できる場面だと思う。
要するに未定義動作に突入する可能性がある。
mutex でロックすることで簡単に回避は出来るが速度を考えるならば
操作するデータが atomic であるようにデザインするとなんとかなるかも？
> biset や vector<bool> というのは、一つの物理バイトに対して複数の bool を詰め込んだ作りとして実装されているのでしょうか？
される。
> bitset[index] = boolean,
> とか
> vector[index] = boolean
> （operator[] が「bool の参照」？を返す、みたいな感じ） は実際にはどのように記述されているのでしょうか？
「1 ビットを表す型」のオブジェクトを返すことで対応する。
そのせいで、 std::vector<bool> は bool 以外を格納する std::vector よりも出来ることに若干の制約がある。
テトリスの素材を用意したぞ
惜しい、もうちょっと工夫すれば
「テトリス」だけでなく「○○トリス」としても使えるのに。
むぅ…
>>195 アーキ依存だが、同一バイトアライメントを参照しない限り問題ないってエロい先輩が言ってた
大人しくmutexつかえ、mutexのコストよりスレッド切り替えのコストを気にしろ、とも言われた
>>201 何のアライメントのことかわからないけど
キャッシュライン同じだとだめじゃないの
こういう待ち時間が僅少なものはスピンロックの方がいいぞ
というよりこの場合CASが成功するまで繰り返せばいいだけ
bitset 位なら自分でcasで実装するのが最善か
C++に標準で画像を表示する方法がないと聞いたけど
どんな方法で出来るのか教えてくれないか?
openGLとダイレクトX以外にないものなのか
他にもgtkmmとかQtというのも、ウィンドウに画像表示できる。
3つだけじゃないんだなｗ
ありがとうそっちのほうも調べてみるよ
>>197 はちみつさん、
>>201,203-205
コメントありがとうございます。
>>204,205
初めて atomic を使ってみました
https://ideone.com/HHUfCw そのままでは atomic を vector の要素にはできないようで、stackoverflow 由来の変てこな回避策をとっています
https://stackoverflow.com/questions/13193484/how-to-declare-a-vector-of-atomic-in-c マルチスレッドでの評価はこれからとりかかりますが、
こんな感じで CAS できてますでしょうか
なんとなくだけど、
vector<bool>でなくてよいのなら、複数スレッドからビットをonにしまくったところでそもそも問題にならないのでは？
windowsでのパイプでのやり取りに詳しい人助けてくれませんか
あとで一部ソースコードは載せます
パイプ処理を非同期で行いたい
1. CreateNamedPipeで名前つきパイプを作成
2. CreateEventでオーパーラップ構造体にシグナル用のイベントをひもづける
3. 「非同期」でConnectNamedPipeを行う
4. WaitForSingleObjectでタイムアウトか接続が来たらパイプのコネクトをする
この流れで処理を作ろうとしてる
ただ、非同期な設定にすると上手く繋げず困ってます
そもそも名前つきパイプで非同期処理はできない..??
msdnにはCreateNamedPipeの第3引数にPIPE_WAITかPIPE_NOWAITかあるが、
PIPE_NOWAITは使用しないでくださいとあるのでPIPE_WAITを指定すると同期処理で待機することはできました
ただし、接続が来なかったらタイムアウトみたいなことができないので、ためしにPIPE_NOWAITにするとGetLastErrorによると218のエラーを返してくる
オーパーラップ構造体を指定したらConnectNamedPipeは非同期云々掛かれてるけどもできないのかな..？
dirty とか使わず単に
set
T e;
while (!_v[q]. _a.compare_exchange_weak(e, e|(1<<r)) {}
reset
T e;
while (!_v[q]. _a.compare_exchange_weak(e, e& ~(1<<r)) {}
じゃないのよく分からんけど
>>216 待たないでデータ読むにはPeekNamedPipeの第五引数cbAvailでサイズ判定してcbAvailが０以外ならデータ読んでも止まらない
これ以外の方法は何やってもダメ
Linuxみたいにすんなり行かんね
>>217 そうなのか
今読めてるのは全部同期処理してるのか...
今からそのAPI調べてみる
読み込むのはそれでよかったとしてコネクトも同じ考え？
sort に渡す比較関数って、たとえば
sort(A.begin(), A.end(), [](int a, int b){return a > b;});
としたら、降順になるのか昇順になるのかいつも分からなくなるんだが、どうやって覚えたら良いの
不等号の向き、つまり return で返る真偽とコンテナの要素番号の大小がどう対応してるのか分からない
a, bで順序がわからなくなるのなら、
first, secondとかleft, rightとかにすればいいんじゃね？
first < secondが昇順でなかったらクレーム続出だろ
サーバー側だけどこんな感じです。
スマホで打つの限界がある...
{
HANDLE handle = CreateFileName(" \\\\.\\pipe\\"sample ,
PIPE_ACCESS_DUPLEX,
// ここの | って意味あるのかな？
// 両方とも0なので
PIPE_TYPE_BYTE |PIPE_READMODE_BYTE | PIPE_WAIT,
1,
0,
0,
0,
NULL );
OVERLAPED over = {0};
over.hEvent = CreateEvent(NULL, TRUE, FALSE, "sampleEvent");
BOOL result =ConnectNamedPipe(handle, &over);
DWORD error = GetLastError();
if( ( 0 == result) &&
( ( ERROR_SUCCESS == error ) || ( ERROR_PPE_CNNECTED != error ) || ( ERROR_IO_PENDING != error ) )
{
WaitForSingleObject(); //本当はここで待ってほしいが、ConnectNamedPipeで止まる
}
}
>>213 何がいいたいのかよく分からんな。
4のwaitforでタイムアウトか接続されたか分かるよね？
普通に問題なく動くよ。
>>222 理想の流れは1-4の流れにしたかった
ただ実際は非同期処理が上手くできておらず3のConnectNamedPipeで捕まる
クライアント側が居なかった場合ずっと待機し続けることになる
そうなっているのが現状
ソースは思い出してかいたのが
>>221 ｺｺにｻﾝﾌﾟﾙｺｰﾄﾞがある
http://eternalwindows.jp/ipc/namedpipe/namedpipe02.html FILE_FLAG_OVERLAPPED を追加する
よく分からんがｺﾚとはまた違うのか
>>224 FILE_FLAG_OVERLAPPEDの使用はまだ試してないので明日試してみますありがとう
FILE_FLAG_OVERLAPPEDに関しては持たないときの条件を使ってたんだけどだめだったんかな...
これをしたかったのだが...
https://msdn.microsoft.com/ja-jp/library/cc429611.aspx hNamedPipe ハンドルが FILE_FLAG_OVERLAPPED フラグを持たないとき、かつ、lpOverlapped パラメータで有効なポインタを指定したときは、この関数は非同期的に実行されます。
制御はすぐに返り、戻り値は 0 になります。GetLastError 関数は、ConnectNamedPipe 関数を呼び出す前にクライアントプロセス側が接続されていたときは
ERROR_PIPE_CONNECTED を、そうでないときは ERROR_IO_PENDING を返します。
peekNamedPipe読んでるけど難しい
peekで調べるのはcbAvailだけ
データは読まなくていい
読むときはReadFile
C++関係無いよね
Win32APIスレに行くべきだと思う
https://msdn.microsoft.com/ja-jp/library/windows/desktop/aa365146(v=vs.85).aspx
こっちにはその部分に相当する箇所が無いようにみえる
FLAG_OVERLAPPEDの有無で非同期/同期は決まるんじゃないのかなぁ
>If hNamedPipe was not opened with FILE_FLAG_OVERLAPPED, the function does not return until a client is connected or an error occurs.
ってあるし
>>223 >クライアント側が居なかった場合、ずっと待機し続ける
パイプって、パイプラインにデータが流れてくるまでは、ブロックされるものだろ。
データも流れて来ないのに、先へ進んだら、バグるだけ
その際、非同期なら、データ無しで、即座に返答が返ってくるのでは？
入力が「まだ来んからちょ待っとれ」なのか
「来るわけないやろアホかおまえ」なのかは
別の手段で判断せにゃならん
まあ常識的には適当な時間でタイムアウトするようにするくらいのものかな。
>>221 https://stackoverflow.com/questions/14306499/non-blocking-connectnamedpipe-event-not-getting-signaled/14306743 PIPE_NOWAIT を使えば ERROR_PIPE_LISTENING だの ERROR_IO_PENDING が即座に返されるが
WaitForSingleObject は発火しない
PIPE_WAIT だと当然ブロックする
PIPE_NOWAIT はlan managerとの互換性のために残されているだけで使用は推奨されていない
面倒でも FILE_FLAG_OVERLAPPED を使うしかない
と書いたけどカッコつけずに後先考えず PIPE_NOWAIT でポーリングしてもいいか
void hoge(int x, int *returnint){
returnint = int * 2;
}
int hoge(int x){
return int * 2;
}
これって内容同じですか？
>>233 C言語に対して重大な勘違い、または質問レスに些細な打ち間違い、
どちらかだと思うが、どちらかは分からない。
>>215 内容をみてくださり感謝いたします、とても考えさせられました
まず
>>211 に二点誤りがありました
・コンストラクタ引数に与える bit 数から、内部 vector<atomic<int>> の確保容量を計算する方法に誤りがあった
・CAS 後にスピンロックするかどうかの判断にあやまりがあった
修正
https://ideone.com/nwcmzq >>215 ＞while (!_v[q]. _a.compare_exchange_weak(e, e|(1<<r)) {}
＞while (!_v[q]. _a.compare_exchange_weak(e, e& ~(1<<r)) {}
＞(e は未初期化状態でも構わない）
>>195 「やりたいことはエラトステネスのふるいなので、この場合オンしたあとオフすることはありません」
に範囲を限定するのならば
>>215 はうまくいくと思います。これには「なるほど！！」と思いました。
ビットセットの最中は別スレッドのビットリセットやビットテストをスピンロックさせたい、
とかの排他制御をやるのならば、dirty-bit（というか1ビットセマフォ）を作らないといけないと考えています
>>234,235
すみません
C++にあまり詳しくないのでわからないのですが、どこがおかしいのでしょうか？
これなら内容等しいですか？
void hoge(int x, int& ret){
ret = int * 2;
}
int hoge(int x){
return int * 2:
}
それはギャグで言っているのか？
void hoge(int x, int& ret){
ret = x * 2;
}
int hoge(int x){
return x * 2:
}
>>240 すみません素でボケてました…
それなら同一ですか？
returnする場合と参照渡しする場合の違い(速度など)があるのか知りたかったです
えーっと、
上段の参照渡しは呼び出し時に渡した変数そのものがやってきて書き換える。
下段のやつはコピーを返すので一手間ある。
理論的には下段の方がちょっと遅い。
まぁ、コンパイラが頑張ってきえるかもしれんし、
デルタ時間的に差はあるかもしれないが最近のコンピュータならあまり問題にならない。
それよりも速度を気にするなら採用しているアルゴリズムを精査したほうが効果的。
ちょっと変な文になった。
厳密なところはアセンブラ出力を個別に見ないと分からない、
という前提はひとまず措くとして…。
int x, ret1, ret2; // x が未初期化ってところは見逃してくれ
hoge_ref(x, ret1); // void hoge(int x, int& ret)
ret2 = hoge_val(x); // int hoge(int x)
上は第2引数に参照を渡す手間が必要な代わりに返り値の処理は不要
下は引数1個で済む代わりに呼出側で返り値を別の変数に代入しなきゃいけない
相殺してどっこいどっこい大差なし、じゃないかな。
計算結果を変数に入れる必要がない場合、等はまた別のお話。
>>240 後者の末尾がコロンになってるのがそのままやで。
速度どうこうは1兆回回すループの中にあるとか1マイクロ秒以内に完了しないと原子炉が爆発するとか
プロファイラでクソ時間がかかってることが判明したとかした時だけ気にしよう
実際のところ「別のお話」と切り捨てた部分が大切でね。
元の質問から逸れてしまうけど。
関数が計算する結果の値だけが欲しい(別の変数に格納する必要がない、
格納すべき変数そのものが存在しない)場合とか、
返り値に相当するのがint等の単純なデータでなく大きなクラスの場合とか、
その辺りを基準に比較すべきなんだよ。
同意。固定長オンリーなどの最適化を最初から入れ込むとロクなことがない。
そーそー
尻拭く時間だけ早くしてもンコが早く出なきゃしゃーない
>>242 何言ってんの、逆でしょ
差が観測できるかは別にして下の方が速い(効率的)
int返すならレジスタ返しなんだから
メモリアクセスよりずっと速い
>>251 関数単独を見るとそうだが、
レジスタで返してもそれを結局は変数に書き込むじゃんという
>>243 の話と合わせて考えると
レジスタを経由する分だけ遅くなり得るっしょ。
ただ、この関数を実行した結果を長期には保存しない (式の途中でこの関数を使うとか) のだと
後者の方が速かったりもするだろうし、まあ、状況によるよな。
実際のところ、インライン化されて更に他の最適化とコンボが起こったりすると
普通の人間にはどうなるか予測がつかんので考えるだけ無駄。
>>252 なんで呼び出し側の話がはいってくるんだよ
そっちの話を含めるとしても
呼び出し側もレジスタのまま処理が行われるのが普通だし、
メモリに書き出されるとしても、
参照と同程度になるってだけ
このABIを理解するのはc/c++使う上で基本
無意味と思うのは結構だがそれはお前の関心がないってだけ
レスしなけりゃいい
intの場合は速度差は特に考慮しなくて良いんですねありがとうございます
それと、関数内でOpenCVで画像をゴニョゴニョして、結果の画像をリターンしたい場合は、どちらが良いのですかね？
特にメモリリークを起こしたくない(今現在起きてるので改善したい)ので、もし何か重大な違いがあるなら知りたいです
void hoge(cv::Mat x, cv::Mat ret){
ret = x + cv::Scalar(100);
}
cv::Mat hoge(cv::Mat x){
return x + cv::Scalar(100);
}
>>254 呼出し側の状況によっても変わりうるから呼出しの状況を含めるってのがそんなにおかしな話かね。
あと、あくまでもこれは C++ という言語を中心にした一般原則としてどうコンパイルされることも「有りうる」ということを述べているのであって、
特定のアーキテクチャやコンパイラや ABI を想定したものではないよ。
多くの (あるいは主要な) 処理系であなたが言うような結果になるというなら、
それはそうかもしれないが、そこには単に私の関心がないのも確か。
>>255 前者のコードの cv::Mat ret は cv::Mat& ret の間違い？
>>256 それはお前の間違った理解であって一般とは言わない
だいたい呼び出し側も含めて反論されてんのになにぼけたレスしてんだよ
お前の理屈だとレジスタの返しが無用となるじゃないか
x64ならraxでaarch64ならx0で返り値を返す
32bitのレガシーならいざしらず64bitでもabiはそう決められてるわけ
お前の興味のない低いレイヤーではそういうのを最大限活用して効率的にcpu回してんだよ
>>258 > だいたい呼び出し側も含めて反論されてんのになにぼけたレスしてんだよ
それは
>>254 のことだろ？
それは特定の命令セットや ABI でないと成り立たないから、
そうでない一般論としてはどうともなりうると私は言っているので論点が違うし、
私はそっちの論点は気にしてなかったという話じゃないか。
>>259 現実のはなししようぜ
成り立たないシステムあげてみなよ
>>255 前者については & の脱字だと仮定して答えるけど、
その脱字が無ければ、前者でも後者でも最終的な結果に差はないと思う。
特にメモリリークにつながりそうな要素もない。
ただ、単純に、局所的に考えるならば後者の方が効率的と言えると思う。
前者だと呼出し側では結果を受け取るための cv::Mat 型の変数を用意しなければならないが、
そのときにデフォルトコンストラクタが走ってから結果は operator= で格納するという形になる。
後者だとコピーコンストラクタ一発で済むので簡単。 場合によっては RVO が適用されるかもしれない。
一度作った変数を何度も結果格納用に使いまわすのならば、
前者の方がメモリアロケーションの回数を抑制できる (効率的になる) 可能性も有るけど、
Mat の実装次第ではそうならないかもしれないし、
そこらへんは実際にやってみないとわからない。
ところでメモリリークが起きていると判断したのは何かツールを使って検証したの？
あっ、
>>261 で
>>255 にアンカーを付けちゃったけど、これは
>>260 の間違いね。
現実の話というなら、インライン化や最適化が入れば ABI もクソもねぇし、
そんなの考えたらキリがないやろ。
>>263 関数内の最適化のみで考えればいいだけなんだからきりはあるだろ
つまりインライン展開なし、LOTなし
ABIを意識するのは全然特殊じゃない
言語間のよびだしはざらだし、
クラッシュダンプにスタックトレース残すためにあえてインライン抑制したりする
お前が経験不足なだけだよ
>>264 そっちの脳内でどんな前提を置いてるかなんて知らんがな。
>>265 コテハンの割に薄いやつだ
もとの質問は関数から値の返し方についてどちらが速いかという質問なんだから、
関数のインライン展開がないと仮定すれば、定性的に答えられる問いだ
かつその仮定は別に現実ばなれしてるわけでもない
それをお前はその知識が有用であることも知らずに考えるだけ無駄とかぶったぎってるわけだ
このスレは相談室
無駄なのはそういうお前の存在ではとおれは思うわけ
malloc()したﾋｰﾌﾟはfree()解放するのは当然
ｳﾝｺしたあと水で流さないぐらい行儀が悪い
メモリーリークは基本的に自分でNEWすることで起こる。
最近のC++では基本的に自分でNEWすることはほとんどない。
動的なメモリが欲しければvectorを使う。
後は、ポインタにインスタンスを確保しないで関数に投げるとかもやってはいけない。メモリを破壊することになる。
あと、どうしてもnewが必要だったりGCが必要な時はスマポを使う。
そういう作法でやると、ユーザーコードでnewすることはほぼない。
えーっと、関数にポインタを投げる時はその関数の仕様を精査して扱わないとほんとやばい。
newとdeleteを使いこなせない補助輪付C++グラマってのも問題だけど
shared_pointerは参照カウントっていうGC機構ですよ？
おっと。
>>270 補助輪があろうがバグ出すよりマシだと思うよ。それと保険的な意味もあるし。
CGってそもそも何だ？
アプリが「今、解放しろ」というタイミングで動くのをGCというならfreeもGCだぞ
いつ解放されるか分からないとか
そもそもｵﾌﾞｼﾞｪｸﾄの外部でﾎﾟｲﾝﾀの生存期間を制御できてないｺｰﾄﾞがﾔﾊﾞｲわ
>>275 そういう、広義解釈は話題が滅茶苦茶になるのでやめましょう。
GCはガベージコレクションだよ。freeは解放関数だよ。
シェアードポインターの解放タイミングは普通コントールしないのでGCだと思ってます。
というか、開放タイミングが未定だからシェアードポインタ使うんじゃないですか？
それは全能でないとバグが出ちゃうのでこういう機構が発明されました。
書くときは大まかには寿命は把握しているとは思うのですが、細部までは精査しないことが多いんじゃないでしょうか。
自分のクローンに共有オブジェクトを持たせるときとか普通に書くと滅茶苦茶大変ですよ？
>>277 広義解釈してるのはおまえだよ
シェアードポインタの解放タイミングはデストラクタだろうがよ
freeと何がどこが違うんだよ
おまえどこまでオレオレ空想してるんだ？
>>276 それはある程度アクセス権の範囲を考えれば何とかなりそうな予感。
それと開放した後のメモリ叩かれた時とどっちがいいか相談ってことで。
>>279 複数の共有がある場合、一個のデストラクタが走った程度では解放されませんよ？
freeは別にデストラクタに仕込む必要ないじゃないですか。
それと、複数の共有がある場合適切にfreeできますか？
コレクションしてないのになんでgcなんだよ。アホすぎる
コレクションサイズが1のコンテナはないのですね。まぁ、冗談は置いといて。
物事を知ってるなら後は任せました。無知でごめんなさい。
>>283 マルチスレッドならアトミックにできた気がしますけど、どうでしたっけ。
マルチプロセスならそもそもメモリ空間が違うのでお門違いですね。
>>272 参照カウンタは普通GCに含めないのでは？
ホントお前ら人殺すことばっか考えてるよな。
そういうのは良いから初心者殺すのマジやめて。
gcの一実装として参照カウンタ方式があるだけで、スマポはgcじゃない。
>>288 横からでスマンが、他の初心者に偉そうに大嘘教えてるやつを初心者とは普通呼ばない
都合のいいときだけ初心者ヅラはだめよ
>>262 ありがとうございます
forの中で何回も関数呼び出すので前者が良さそうですね
>>291 嘘の範囲を限定しないと俺大罪人じゃないですか。
まぁ、いいや。
メモリーエラーで落ちろ。
>>289 スマートポインターのうち std::shared_ptr は参照カウンタを内蔵しているのだから
①参照カウンタが GC、故に、std::shared_ptr も GC
②参照カウンタが GC でない、故に、std::shared_ptr は GC でない
①②のどちらかしかない
参照カウンタが GC なのにスマートポインタが GC でない、というのは矛盾しているのでは？
私は「参照カウンタは GC じゃない」と思う
>>293 >>251 もちろんインライン展開される場合は除く（展開されたら多分同じコードになると思うが
あと
>>255の質問に対して
>>268は不適切、
>>268から話が変な方向に行ってる
OpenCV使ってるって言ってるし、間違った使い方してリーク（
>>255がnewしたのではない部分）
の可能性の方が高いと思うけどね
>>294 なにも矛盾してないよ。
GCの一実装として参照カウント方式を使ったものがある。
スマホの中に参照カウントを使ったものがある。
だからといってGC=スマポじゃない。
エンジンで走る車があって、エンジンで飛ぶ飛行機があっても、車は飛行機じゃないのと一緒
>>296 ＞エンジンで走る車があって、エンジンで飛ぶ飛行機があっても、車は飛行機じゃないのと一緒
is-a の話の例えに has-a の話を使うのは論理的ではありませんね
「車 has エンジン、飛行機 has エンジン」の話と「参照カウンタ is GC、スマポ is ＧＣ」の話は別ですよ
>>297 いやgc=参照カウンタなんて言ってないんだけど。
gcに参照カウント方式を使っているものがあるといってるの。はじめからhas_a関係しか言及してない。
>>298 ＞いやgc=参照カウンタなんて言ってないんだけど。
そこに「＝」記号を使うのがおかしいのでは？
真偽は別として、記号を使うのなら ⊂ とか ∈ じゃないですか？
>>300 では std::shared_ptr も GC でしょうか？
>>302 私は std::shared_ptr を GC だと思ってるよ。
解放のタイミングがコンパイル時に確定しないようなのは GC だろってくらいのカジュアルな認識だけど。
基準の妥当性はともかくとして、とにかく私はそういう基準で考えてる。
QZ 氏の中で std::shared_ptr と GC を隔てるのは何だと思ってるの？
Qt5触ってみてるけど生ポインタばっか使ってて気持ち悪い、これでいいのか？
parentクラスがあってそれを継承したchildクラスがあります。
vector<parent*> getParentlist(){//省略}でこんな感じでparentクラスのポインタのリストを返す関数があります。
それでここからが質問なのですが、
vector<child*> childList = (vector<child*>)getparentlist();
こういうコードがあってびっくりしています。
機能はしているみたいですがこれ作法的にオッケーなんでしょうか。
ダウンキャストは良くないと聞いていたりそもそもこれダウンキャストなのかとかちょっと分からないんです。
よろしくおねがいします。
>>281 話が通じてないなあ。。。
デストラクタでuse_count見てるのは当たり前だろ
シェアードポインタの話だぜ？
解放のタイミングがアプリのロジックに従属してるかどうかって話なのに
何を言い出すかと思えば
>>307 試せる限りのコンパイラではそもそもコンパイルエラーだったけどなぁ
vector<parent *> &getParentlist();
じゃなくて？？
その上で
(vector<child *> &)getParentlist();
なら通るよ、通るし普通に使えるはず
>>309 失礼しました。ポインタ抜けてました
vector<parent*>* getParentlist(){//省略}
で
vector<child*>* childList = (vector<child*>*)getparentlist();
こんな感じです
おいおい・・・ｗ
ポインタでも同じことだ、そのキャストをreinterpret_castだと考えたらわかるはず
それでわからないならC++の継承の仕組みを勉強すべき
基底方向へのキャストの実態は
サブオブジェクトまでのオフセット分だけアドレスをずらす操作なので、
>>310 のような場合にはそれは実現できない。
単に無理やり型を合わせているだけになってしまっている。
C++ 的にはあかんやつ。
ただ、実際に動いている理由をあえて考察するなら、
child が parent を単一継承した場合などには parent が child の先頭に配置されるようなメモリレイアウトにコンパイルされる可能性が高く、
アドレスをずらす量が 0 で済んでしまうので
型を読み替えるだけでも不整合が顕在化せずに動作してしまうということは有りうる。
あくまでも、処理系がやってることが偶然に組み合わさって動いているというだけなので、やめといた方がよい。
そこまでご丁寧に説明してやるのなら、「Cスタイルのキャストは使うな」、を教えるべきじゃねーの？
parent * が child * なのかも分からないのに強引にキャストするのか
そこまで型無視するなら void * でいいんじゃない 知らんけど
C++ スタイルのキャストを、特に入門者の内は static_cast だけ使っておけばまあまあ大丈夫。
static_cast でエラーになるような変換は C++ 的にはだいたいイケてないやつ。
アホか
dynamic_castが使えないくせに初心者皆伝なんぞやれん
>>303 ＞私は std::shared_ptr を GC だと思ってるよ。
…GC発祥の地 lisp の使い手のはちみつさんがそうおっしゃるのなら、私の中の定義も書き換えないといけませんね
mark and sweep GC って、プログラム本体とは関係のないところで、それこそメモリの死にビットをも使ったりして、ごそごそやる、というイメージがあります
＞解放のタイミングがコンパイル時に確定しないようなのは GC だろってくらいのカジュアルな認識
＞std::shared_ptr と GC を隔てるのは何
「解放のタイミングを図る機構が表のプログラムとは独立している」
くらいでしょうか？表のプログラムからの参照が途切れることと free() されることに直接の関係性がない mark and sweep とその発展型のみを GC とみなしています
といって、GC の本は一冊しか持っていません
>>318 定義がひとつでなきゃならないとは思ってないよ。
だから自分なりに一貫した考え方があるのなら、それはそれでいいんじゃないかな。
ただ、「表の機構と分離されているか」という考え方だと、それは抽象化の仕方であって、メカニズム (アルゴリズム) の基準ではないね。
その基準だと std::shared_ptr が GC ではないとは言えても参照カウンタが GC ではないとは言えない。
お返事遅れました
>>213です
Overlappedの設定をCreateNamedPipe時点に引数として渡す構造体ことで同期制御を実現できました
ありがとうございました
メモリリーク探しきつい....
すみません質問があります
メインスレッドと通信スレッドがいて、
通信スレッドはメインスレッドのオブジェクトポインタ持ってます
メインスレッドはクラス化されており、スレッド用のstatic関数以外にもメンバ関数を持っています
通信スレッドがデータ受信して、メインスレッドの別のメンバ関数を呼び出した時、
メインスレッドで実行していた処理はどうなるのでしょうか？
メインスレッドで実行していた処理はあくまでもstaticな関数の処理で、staticでない他のメンバ関数は別に処理されるのでしょうか？
>>322 説明が分かり難いなぁ。
通信スレッドとやらから呼び出した関数は通信スレッド上で走っているし、
メインスレッドはメインスレッドで走っている。
>>323 分かりずらくて申し訳ありません..
もし通信スレッドで呼び出した別のメンバ関数内でメンバ変数を変更した場合、
メインスレッドでもメンバ変数の変更値を参照できるのでしょうか
解放のタイミングがコンパイル時に確定しないのは shared_ptr でも同じでしょ。
任意のshared_ptrインスタンスを別のインスタンスにコピーした場合、解放のタイミングはコンパイル時に確定できない。
vectorがconstexpr対応できるならshared_ptrもできそう
staticなﾒﾝﾊﾞ関数ではstaticなﾒﾝﾊﾞ変数しか参照できない
staticでないﾒﾝﾊﾞ関数はstaticな変数もstaticでない変数も参照できる
staticなﾒﾝﾊﾞ関数とstaticでないﾒﾝﾊﾞ関数が作用しあうのであれば、
当然staticな変数になる
はっきりいってな
staticな変数はｸﾞﾛｰﾊﾞﾙ変数と同じだからな
とうぜん同じ実体の変数を参照することになる
> スレッド用のstatic関数以外にもメンバ関数を持っています
> 通信スレッドがデータ受信して、メインスレッドの別のメンバ関数を呼び出した
> 通信スレッドで呼び出した別のメンバ関数内でメンバ変数を変更した
まず低学歴知恵遅れは質問を読解する能力がない
こりゃーもう
>>324には
>>331に回答してもらうしか
>>324 出来るが、データ競合が起こらないように気を付けよう。
質問者が状況を理解してない説明をしてるから本当に回答になってるのかイマイチわからぬ。
無理に言葉にしようとせずにコードを示してくれた方がいいんだがなぁ。
ﾊﾞｶじゃなければ
普通にｱﾄﾞﾚｽが固定されてるstaticなﾒﾝﾊﾞ関数のｱﾄﾞﾚｽを
ｽﾚｯﾄﾞを開始させるｱﾄﾞﾚｽにしてると推定できるからな
このｽﾚのﾊﾞｶどもはｽﾚｯﾄﾞなんか
なんも分かってないからな
質問するﾔﾂもﾊﾞｶになにを聞いてもﾑﾀﾞだからな
そこの理解は必要
>>335 >ｽﾚｯﾄﾞを開始させるｱﾄﾞﾚｽ
さすあに
スレッドを起こす質問に解釈しやがった；；
>>322の
>メインスレッドはクラス化されており
>通信スレッドはメインスレッドのオブジェクトポインタ持ってます
と、
>>324の
>メインスレッドでもメンバ変数の変更値を参照できるのでしょうか
からすると通信スレッドで変更したメモリをメインスレッドでも参照できるのかという質問かとｵﾓﾀわ；；；
> 通信スレッドはメインスレッドのオブジェクトポインタ持ってます
まず一番最初に書いてることが読めてない
致命的な頭のﾜﾙｻといっていい
普通にﾒｲﾝｽﾚｯﾄﾞのﾒﾝﾊﾞ関数呼び出して
ﾒｲﾝｽﾚｯﾄﾞのﾒﾝﾊﾞ変数を変更すると読めるからな
こんだけｺﾐｭﾆｹｰｼｮﾝﾚﾍﾞﾙが低いと
実生活でも支障があるﾚﾍﾞﾙといっていい
>>330 半角クンは自分の見たいものしか見えない、すなわち常に半角クンの中ではすべてのものを見通している視野100%ということなのだろう
>>333 mutexしときます
いろいろアドバイスありがとうございます
>>329ですね
まずなこのｽﾚの低学歴知恵遅れたちは
自分たちがどんだけ低学歴知恵遅れかという自覚がない
致命的といっていい
低学歴知恵遅れなので質問の解釈に関する
>>337と
>>339の違いがわからんが、
それはそうとして、当初の疑問に戻るが視野の広い
>>342は
>とうぜん同じ実体の変数を参照することになる
には一切注釈をつけなくて良かったの？
また低学歴知恵遅れが負け惜しみ意味不明なこといってるしな
低学歴知恵遅れの負けず嫌いは異常だからな
低学歴知恵遅れほど自尊心だけは高い
ｺﾚは底辺に多い
そして自分がｺﾞﾐｸｽﾞの低学歴知恵遅れである自覚もない
つまり救いようがない
低学歴知恵遅れの底辺ｺﾞﾐｸｽﾞほど自己評価だけは高い
その根拠のない自己評価の高さは
どこからくるものなかははっきりとは分からない
低学歴知恵遅れの底辺ｺﾞﾐｸｽﾞほどそういう傾向がある
それは経験からかなり相関が高いと確信している
みなさん厳しいですね…
私は質問側ですが、そして今 schme スレで質問を丸投げしちゃっていますが、わからないときは、なにがわからないかわからない、という感じだったりしています
>>324 なにか断片的でいいからコード例をあげていただくと嬉しいです、例えば
https://ideone.com/VvdMRl むしろこのｽﾚの低学歴知恵遅れの底辺ｺﾞﾐｸｽﾞたちは
質問してるﾔﾂのﾚﾍﾞﾙにすら到達してない
>>347 pthread使ってる以外はほぼ同等な考え方です
実例作っていただきありがとうございます。
>>326で書いたとおりスレッドAで変更したメモリをスレッドBで正しく参照できるのか否かというのは
微妙な問題なんじゃ
>>347のコードでf::nの書き換えと参照が正しく動くのは
20行目のC::f()呼び出しで呼び出されたstd::coutがメモリバリア的な効果を果たしたに過ぎないかもしれん
（中でmutexとかcritical sectionとかなシステムコールを呼んでいるなら普通のOSならメモリバリアが効く
と自尊心だけは高い低学歴知恵遅れなので難癖をつけておく
実証はしない
>>347のコードがそもそもC::nがvolatile宣言されていないのに安全に動いている理由は…
と始めると荒れる…！
それはともかくスレッド間のメモリの読み書きを
>>341のmutexでガードするというのは大変良い心がけです
多少遅いかもしれないが遵守する限り泥沼に踏み込まずに済む
>>322 メインスレッドとサブスレッドで並列に起動して同じ変数を書き換えた場合、書き換えレースになる。
ロックっていう機構があるのでそれを参照。
>>351 よろしければ教えていただけますか？
＞20行目のC::f()呼び出しで呼び出されたstd::coutがメモリバリア的な効果を果たした
メモリバリアって要するに x86 の lfence, sfence, mfence のことですか？
これはCPUキャッシュがメインメモリに吐き出されることを保証するものですか？
これらの命令は Pentiumu2 あたりにはなかったと思います、でも Pen2 とか特に Celeron-BP6(abit) で普通にデュアルプロセッサできていたのはどうしてでしょうか？
>>353 >これはCPUキャッシュがメインメモリに吐き出されることを保証するものですか？
ちげう
実行したコアのライトコマンドキューかリードコマンドキュー上の命令をその場で全部実行してしまうというもの
キャッシュのinvalidateやfillが起きるかどうかとは別の話（結果的に起きることもあるが常にではない
キャッシュと関係あるみたいな説明のページがあることは承知しているが苦情は漏れに言わないでﾎｽｲ
>これらの命令は Pentiumu2 あたりにはなかったと思います、でも Pen2 とか特に Celeron-BP6(abit) で普通にデュアルプロセッサできていたのはどうしてでしょうか？
古代の話は知らん
OoO（アウトオブオーダー実行）はすでにあったはずなので、ライトコマンドキューやリードコマンドキューもすでにあった
全くの推測だが、キャッシュのinvalidate操作が（invalidateを常に伴うため効率の悪い）メモリバリアと同じ効果があったとかではないかいや知らんけど
ちなIA（Intel Architecture）のうちでも常識的なコア数のやつは
コア間のキャッシュコヒーレンシをハードウェアで勝手に取ってくれるので、
コア間のメモリ参照の不整合はメモリバリアだけ注意したら逝ける（キャッシュの存在は透過的
>>353 こないだ atomic を使ってたけど、
atomic について調べたならそこらへんの話もどこかに書いてなかったか？
C++ 用語ではバリアでなくてフェンスって言ってるけど。
>>354 ＞実行したコアのライトコマンドキューかリードコマンドキュー上の命令をその場で全部実行してしまうというもの
＞キャッシュのinvalidateやfillが起きるかどうかとは別の話（結果的に起きることもあるが常にではない
なるほど…ちょっとだけ理解が進んだかもしれません
「はるか遠くにあるメインメモリに変更が反映されるかどうか」はプログラムの書き手にはあまり関係がなく、
「各コアから見る限りにおいて、各コアが発したライトあるいはリードの結果すべてが反映され、各コアからはみえている」と考えればいいのですね
これらのメモリの可視性について
http://www.cs.tsukuba.ac.jp/~yas/cs/csys-2013/2013-10-15/ 等を熟考しています
mutex や cond にその方面での効用があるとは…、pthread のメモリ可視性に関する効果はあまり意識していませんでした
重要なヒントをくださりありがとうございます
>>356 ええ、atomic に関係する話をいろいろと読んではいたのですが、正直なところ、あまりよくわからなかったことを告白します
acquire とか release とか、いまひとつイメージできなかった…
atomic の各メンバ関数の memory_order は C++デフォルト引数として sequence-consist(ency) を与えていることはわかりましたので「最強にしているから、まあいいか」くらいですましていました
>>354 ＞実行したコアのライトコマンドキューかリードコマンドキュー上の命令をその場で全部実行してしまうというもの
この記述が一番しっくりきました
>>352 ＞書き換えレース
ええと、これを読んで reset-set flip-flop の禁止入力「R=S=1」のことを思い出してしまったんですが、それはさておき
複数のコアが同一メモリに対して「同時に書き込み」する、というのは、このフリップフロップ禁止入力と同じ意味あいですか？
つまり「どっちの書き込みが後になるか、予想がつかないから禁止」…①
それとも、「複数のコアが本当に同時に書き込んでしまった場合、結果が不定になる」…②
（昔のフロッピーディスク供給のソフトウェアプロテクトの方法としての「コロコロビット」＝読み出すたびに 0/1 が変わる）という意味なのか
いや、①も②も同じような意味なのかもしれませんが、
>>215 の「CAS 連続スピンロックや CAS 連続スピンロック中に別コアから書き込んだり読み込んだりすること」
が②の意味で危険で、ソフトウェア側で mutex や dirty-bit (
>>238) を設けて本当に意図的にコントロールしなければならないのか、と、ちょっと心配になりました
最初から安全側にふっておくとは思いますが
考える前に学んだ方がいい
cas が使い物にならないならなぜそんな物があると思う？
というか mutex の実装にも cas は使用される。
使い方がわからないからcasは使わず mutex を使うという判断は正しいが、
例えば前の例のエラトステネスの篩で実装1ビットセットする毎に
mutex で排他していたらコアがかなり沢山あってもシングルスレッドの方が速い
(mutex api を処理する時間が大半を占めてしまう)
質問する前にスレッドセーフとか排他制御とかレースコンディションとか
弱いメモリモデルとかでググって時間くらいしっかり読んで
>時間くらい
「1時間くらい」のタイプミスでした。
>>360 cpuのメモリモデルの説明読んだら最初の方に書いてあると思うけど
普通ワード単位のアクセスは何もしなくてもハード的にアトミックであることが保証されてる
そこで壊れたらやってられないからな
>>360 > つまり「どっちの書き込みが後になるか、予想がつかないから禁止」…①
順序は予測できないと言うのは正しい
> それとも、「複数のコアが本当に同時に書き込んでしまった場合、結果が不定になる」…②
通常のプロセッサならこれはない
排他制御がなされていてどちらかの結果が最終的に反映される
ただ CAS (Compare And Swap) 命令はそう言う話じゃなくて読出動作 (Compare) と書込動作 (Swap) がアトミック（つまりその間には他のアクセスは無いように制御されてる）ってこと
ソフトでどうのこうのできる話じゃないからシステムから提供されてるAPIを素直に使いなさい
>>364 中途半端な知識で語るなよ
>>364 だよな
同一のCS, WE/OEをファンアウトさせるわけで
配線遅延があってもクロック同期で関係なくなるし
このスレは荒れる…！
マルチスレッド、マルチコア、アウトオブオーダー実行（OoO）にまつわる3つの問題は分けて考えられねばならない；
(A) 書き換えレースの問題（
>>352）
(B) アドレスxに対する読み書きのatomic性（
>>364）
(C) メモリバリア（
>>354）
(A)はマルチスレッドすればシングルCPUでも起きる問題
(B)はこれは何ビット幅までの読み書きを他コアが割り込み不可能なバスサイクルで行えるかという話。マルチコア固有
(C)はマルチコア状況化でのアウトオブオーダー（OoO）実行の影響をソフトで制御して無問題にするテクの話で、マルチコア×OoO固有の話
>>364は(B)のことを言っており、だいたい合っているんじゃ
（IAの場合、4バイト境界に整列した32ビットまでは(B)の意味でatomicに読み書きできる
整列していないデータの読み書きは16 bitであっても(B)の意味でatomicではない
インテルのマニュアルに書いてある
自尊心だけは高い低学歴知恵遅れなのでいちいちソースは示さないが
とはいえ、読み書きをミューテックスなりロックなりでガードする、…(D)
これだけを遵守すれば
>>367の問題は全部忘れて良い（
>>351の後段にも書いた）
メモリモデルとかまともに勉強する必要は無い
さらに言うと、まともなコンパイラなら（中でどんな副作用やメモリバリアを行うかわからない）システムコールを跨いだ
変数のレジスタ割り当てとかしないから、(D)を守れば実際のところ（ほとんどのケースで）volatileも要らん
メモリモデルを勉強する必要があるのは、(D)の速度に不満が生じて改善する必要に迫られたとき、
例えばdouble-checked lockingテクがちゃんと動くのかとか不安になったりロックレスハッシュを作らねばならなくなったときだけ！
>>367 マルチプロセッサとかNUMAの事は考慮しなくても良いのけ？
バスサイクルと言ったりミューテックスって言ったり話のレベルがぐちゃぐちゃすぎる…
要するにあらゆる左辺値をatomicにして更にミューテックスでガードしとけば（これはキチガイ）
ハード系の知識を学ぶ必要はない（ハードソフトという名の蛸壺）という無茶苦茶な主張だな
勉強嫌いにもほどがあるだろ、何が低学歴だ
周辺チップからのメモリ書換をミューテックスでガード出来るのか
実際プログラミングする上でハードの知識はいらんだろ
>>374 メモリのゴーストとか普通に出てくるだろ
PCという狭い牧場から出たことのない家畜は知らんだろうけど
>>375 は？プログラミングが書けると言っただけでデバドラのプログラミングするなんて言ってねえよ
じゃあお前は信号処理を知らずに音声合成のプログラミング書けるのか？
>>376 だからそんなの考慮知らなくもソフトウェアは作れるんですが
作文したら推敲しろ、って小学校で習うはずなんだけどな
>>378 え？
お金も払われないのに推敲？
時間の無駄じゃん
>>377 ああ家畜か
人間よばわりして悪かったな
ハードウェア部分を隠すためのOSによるアクセスの抽象化とか、
標準ライブラリがあるわけだし、ハードウェアの知識が絶対に必要でもないでしょ。
デバイスドライバを書くプログラマが優れているとか、その反対に
高レベルな(抽象度の高い)ソフトを作る人ほど偉いってものでもない。
>>380 逆に家畜はお前じゃね？
ハードウェアを意識しないとプログラミング出来ないなんて可哀相
for i in {0..15}; do
mount /dev/dm-$i /mnt
done
低レベルプログラミングって言う面白そうな本が出てたなあ
そういえば、さいきんの低レベルいじる時ってどうするんやろね。
BIOSなくなってきてるし、作法かわってきてるのかなぁ・・・。
古き良きシリアルポートが普通のPCではほぼ絶滅してるからなあ
USBきらい
USB制御のノウハウってあんまり周知されてない感じがする。
>>382 高級ってのを誤解しているアホがここにもいたわw
>>390 LINE EYEで見てるとエラー出まくったりしてるね
dllからexeをCreateProcessで起動するとメモリリークするとかある？
debugging tool forなんたらみたいなやつでメモリリークチェックしてるのだけど
exeから呼んだやつはリークなし
dllから呼んだやつはリークありとなっている
監視開始ポイントと終了ポイント及び呼び出しソースコードに差分がなく
その他にも差分がないんだ
dllから呼びだす場合
dllは呼びだした側のﾌﾟﾛｾｽと同じｱﾄﾞﾚｽ空間にﾏｯﾋﾟﾝｸﾞされ
dll側の関数を呼び出して生成されたﾋｰﾌﾟも
呼びだした側のﾌﾟﾛｾｽと同じｱﾄﾞﾚｽ空間にﾏｯﾋﾟﾝｸﾞされる
ﾌﾟﾛｾｽから呼び出した場合、
呼び出した側のﾌﾟﾛｾｽと関係ない呼び出された側のﾌﾟﾛｾｽのｱﾄﾞﾚｽ空間に
ﾋｰﾌﾟは生成されるから
呼び出した側のﾌﾟﾛｾｽを監視してもそのﾘｰｸについて検出されることはない
分かった？
そのツールでもうちょっと情報とれないんかいって思うが、
ランタイムライブラリの指定とか見直してみたら？
というかexe起動を繰り返したら繰り返すだけリークする？
最初の一度だけならあんまり気にしなくていいんじゃない？しらんけど
質問通りの
ｺﾚ以上ないｴﾚｶﾞﾝﾄなﾚｽになってる
>>394 umdhじゃないかと思うが、スタックトレースは見てみたの？
プロセスの標準入出力に名前付きパイプが指定されてるとdllの明示的なアンロードのタイミングでApplication verifierでリーク検出されたことはあった。
>>394 dll ってことは何かの exe の中で動いてるんだろ
そっちのコードが他スレッドで何かアロケートしてるとか
単に dll の問題で CreateProcess しなくてもリークしてるとか
>>397 >>395 >>400 >>401 色々とありがとう。UMDHです
色々と試してみたところ繰り返し行ってもリーク量は増えなかったので、自分が作成したロジック以外でのリークみたいでした
UMDHは増えず、タスクマネージャー上のプライベートメモリとかが増えてくのは気になったけども....
>>402 メモリはコミットサイズを確認。
あとはハンドルをクローズしてないとかはないよね。
>>402 UMDH は増えずにタスクマネージャー上のプライベートメモリが増えるということは必ずしも問題があるわけではない。
(もちろん問題がある場合もある。)
malloc や new で割り当てるメモリは、
OS からある程度のメモリを融通してもらった塊をアプリケーションのレイヤ (ランタイムライブラリ) で切り分けて提供することになる。
足りなくなったらまた OS に要求する。
しかしその要求というのも、メモリ空間を予約するだけで物理メモリはまだ割り当てないかもしれない。
「プライベートメモリ」というのは予約したメモリ空間のサイズを表すらしく、
実際のメモリ使用量を表さないので、
基本的には UMDH をあてにした方が良いと思う。
gflagsで対象exeのメモリ割り当てをコンパチブルモードにしてみたら
>>403 コミットサイズを確認すれば良いんですね
ハンドルクローズもしてますね
ありがとうございます
>>404 分かりやすくありがとうございます
差分が出ることもあり得るのですね
丁寧でとても助かりました
プログラム全体で使いたい変数を宣言する際は
グローバル変数として宣言するのと#defineするのって何か違います？
どっちを使えばいいんですかね？
#define という事は定数だと思われるのでconstexprな変数に一票。
グローバル変数だとコンパイルのときにエラーを出してくれる
#defineは値がヘンでもエラーを出さない
どっちとか言う前にもう少し言語仕様を理解してこいよ…
>>407 そのレベルならいったんdefineは忘れるべき。
defineはほとんどの場合ただの置換に過ぎない。
C++なら値変更不可な参照のみのｼﾝｸﾞﾙﾄﾝにしとけばいい
ｼﾝｸﾞﾙﾄﾝを動的にｲﾆｼｬﾗｽﾞできるようにすれば起動時に設定の変更ができたりするようにできる
めんどくさかったらdefineでいい
defineかえてｺﾝﾊﾟｲﾙしなおせばしまいだからな
そういうdefineはｶﾃｺﾞﾘｰ毎にまとめてぜんぶ一か所に書いときなさい
ｼﾝｸﾞﾙﾄﾝでも裸の外部変数はやめておいたほうがいい
それさえしなければどうでもいい
し、シングルトン？
この話題でまさかのsingleton笑
さすがにこれはネタだよね？
外部変数はｼﾝｸﾞﾙﾄﾝの変数だからな
なにもおかしくない
ここで言ってるsingletonって所謂GoFデザインパターンのsingletonだよね？
そもそも池沼のID:YK4Q2JFR0はdefineがなにかすらわかってないからな
> defineはほとんどの場合ただの置換に過ぎない。
ほとんどもへったくれもなく
defineはただの置換だからな
頭悪い
頭悪いやつはﾑﾘしてﾚｽしなくていい
なにもわかってないんだからな
>>416 結合と文字列化もあるから「ほとんど」であってるが
いつもの半角くん病が発症したらしいw
毎度毎度、燃料投下、お疲れ様ですm(_ _)m
defineか外部変数にしたいとかいう質問だからな
普通にｸﾞﾛｰﾊﾞﾙを定数値をもたせたいという質問内容なのに
このｽﾚの低学歴知恵遅れたちがどう解釈したかはしらない
まず低学歴知恵遅れは日本語を読解する能力がない
ものごとも抽象的にみる能力もない
つまり認知機能に著しい欠陥がある
静的にどう置換されるかｺﾝﾊﾟｲﾙ時に決定されてるからな
このｽﾚに池沼たちは、いつもなにをいってるか意味不明なﾜｹ
>>420 こういうtypoをツッコむのは本来嫌いなんだが、せっかく燃料投下してくれたお礼に一応指摘。
「ｸﾞﾛｰﾊﾞﾙを定数値をもたせたい」
毎回言うけど、C言語の前に日本語勉強したほうがええで。
低学歴知恵遅れが指摘できるのはこの程度
自分の著しい頭の悪さを棚にあげるからな
ｸﾞﾛｰﾊﾞﾙに定数値をもたせたい
とまともな日本語読解能力があれば
普通に読めるからな
ともかくとてつもなく頭悪い
しかもとてつもなく頭悪いという自覚がない
で、ｵﾏｴは自分の頭が
とてつもなく頭悪いのは自覚してんか
ｺﾞﾐでｸｽﾞな人間であることも自覚できてんのか
さすがにもうワンパターンで飽きてきた。
もっと違う煽り方考えてよ。
ツンデレ的なのはどう？
煽り？
まず事実だからな
ﾊﾞｶは自分がﾊﾞｶである自覚がない
だからﾊﾞｶが直らない
すべてｺﾞﾐでｸｽﾞな人間性の問題
ｺﾞﾐｸｽﾞには内省というもんがない
最初は褒めて褒めて褒めちぎった上でミスリードを誘い、その上でボロクソに貶すとかどう？
さすがに皆そのやり方は飽き飽きしてるよ。
子猫がかわいくて甘噛みされたらちょっと叩いたあとで頭なでなでしてたら
大人になっても強くかむようになって困ったのを思い出した
なんだかなあ
ｵﾚはこんなことはしてないからな
ﾀｶｲ
∧_∧ ﾀｶｰｲ
m⊂(´・ω・)⊃
⊂c ﾉ__ ノ
／⌒ヽ | .| | .| ／⌒ヽ
（ ＾ω＾） i i二 .ﾉ _（ ＾ω＾） il| 死ね
（´ 二二二 ﾉ （´ ＼ ＼|il |il il|
／ /: ／ ＼. ＼ノ＼. ＼il| |il|
i===ﾛ==／ i===ﾛ== ヘ. ＼. i|!l !l＼il|
ノ:::::::::::::::::ヽ ノ:::::::::::::::::ヽ ＼ ヽη /'）/'）
／:::::::::::へ:::::::::ヽ ／:::::::::::へ:::::::::ヽ ヽ_,,..) /
/::::::_/ ＼:::::::) /::::::_/ ＼:::::::) ） （ / ／
／::_ '´ |::::| ／::_ '´ |::::| ⊂（v ）⊃
レ しつ レ しつ｀) ＼ 〆 (´￣
／⌒Ｙ⌒ヽ
ただの被害妄想
ｵﾚは事実を書き込んでるだけだからな
まず事実が事実であることを自覚するところから
バイナリファイルの読み書きはfstreamとFILEどちらがオススメですか？
#include <iostream> is Forbidden
>>407 を虚心坦懐に読めば
「#defineじゃ定数値しか作れんのだから変数にする以外ない」
という身も蓋もない答えもありうるわな。
さすがにそんな揚げ足取りをする人はいないみたいだけど。
プログラム全体で参照する定数値をconstのグローバル変数にするか
#defineにするか、なら一般的にはconst変数の方が好まれるかな。
const変数の利点と言うより、#defineの弊害を避けるためって理由で。
その定数が整数値なら enum class も候補に入れてくれ。
static_castが面倒臭いかも知れんけど。
ここまでconstexpr1つもなしなのはみんな意図的？
整数の定数くらいならconstexpr付けても付けてなくても大して変わらなくない？
const int n = 42; と constexpr const int n = 42; って何が違うの
どっちも定数式文脈で使えるでしょ
constexpってクソださい仕様だよな
勝手に推論して最適化しとけや
>>438 関連性のある定数群をまとめる為にはスコープがあるenum classはいいんだけど、
フラグとして使うのが難しいのがちょっと難点
enum class PNG_COLOR_MASK: uint8_t{
GRAY = 0b000,
PALETTE = 0b001,
RGB = 0b010,
ALPHA = 0b100
}
enum class PNG_COLOR_TYPE: uint8_t{
GRAYSCALE = PNG_COLOR_MASK::GRAY,//できない
RGBA = PNG_COLOR_MASK::RGB | PNG_COLOR_MASK::ALPHA//できない
}
フラグとして使うならoperator|と&をオーバーロードするのが良いけど面倒だね
PNG_COLOR_MASK operator|(PNG_COLOR_MASK e1, PNG_COLOR_MASK e2)
{
using u_t = typename std::underlying_type<PNG_COLOR_MASK>::type;
return PNG_COLOR_MASK((u_t)e1 | (u_t)e2);
}
ここまでやって更にstatic_castも必要となるという。
>>444 むしろ俺はコンパイラでやらずビルドシステムで対応すべきことだと思っているが。
なんでもコンパイラに押し込もうとする悪しき風習に思う。
fstreamでも結局writeするのでFILEと比較して都合のいい方を選べばいいよ。
enum class はスコープを限定できる代わりに、個別の型として
ガチガチに保護されるせいで数値として使いにくい欠点はあるね。
namespace PNG_COLOR_MASK {
enum {
GRAY = 0b000,
PALETTE = 0b001,
RGB = 0b010,
ALPHA = 0b100,
};
}
int grayscale = PNG_COLOR_MASK::GRAY;
int rgba = PNG_COLOR_MASK::RGB | PNG_COLOR_MASK::ALPHA;
こんな感じにnamespaceで名前なしのenumを囲むか。
素直にconstexprを使えばいいんだけど、C++11以前でも可というニッチな提案。
その場合structで囲むのもありだね。二進数リテラルはC++11以前では拡張だけど。
ようわからんがプログラムを書き始めた当初
#define CONST_A 3
だったものを
extern int g_varA = 3;
#define CONST_A g_varA
とすれはCONST_Aは一瞬で値を変更可能な「変数」g_varAに設計変更になれるｷﾓｽ
（CONST_Aは定数のつもりだったが後から変数に変えたくなった場合
ただしそうしてしまうとプログラムのどこでも書き換えられてしまって危険極まりないので、
めんどくさくない限りシングルトンすべしという神の啓示に聞こえなくも無い
プログラム起動時のみに値を設定する目的であってプログラム動作中は定数扱いなのだとすれば、
シングルトンのマルチスレッド対応は特に何もしなくても良い（クリチカルセクションやミューテック巣やLOCKとか不要
まあ質問に対しては例の図画の「営業の約束」の類やな
接頭辞0bというのは十六進数と紛らわしいから02にしよう
二進数が書けたら書けたで、長ったらしくなるから桁区切りを入れさせろという要求が出るのは必至
犯人の要求はエスカレートする一方や
誰かが仕込んだバグ以外で8進数が使われてるところを見たことがない。
パメ族以外で8進リテラル使ってるやつなんているのか？
マイコンベーシックで2進数のドット絵キャラを見たときは笑劇だった
>>461 アポストロフィーがどうにも気持ち悪くて…
慣れるのかね、そのうち
int a = 123; // a = 123
int b = 0123; // b = 83
ほんとクソ仕様だなこれ
桁区切りってISOにのっとってるの？
国によって違うけど対応してるの？
Unix系のファイルパーミッションは今でもしぶとく8進数だよな
大嫌いだからあの習慣早く滅亡して欲しい
>>467 可読性を高めるためのもの
コンパイラはただ読み飛ばすだけなのでお好きな記方でどうぞ
だったはず
>>460 unix のファイルパーミッションが3bit単位だから昔のソースではcreat()の引数に0755とか0644とか普通に書かれてる
てかそのための8進数だと思う
rwxrwxrwx
421421421
8進数なのはｱﾀﾘﾏｴ
8進数以外で表現しようがない
intelチップのマシンコードは3bit単位で意味が変わるから
ハンドアセンブル出来るひとは普通８進数使えるよ
stickyビットとかsetuidビットとか増えてるから本来はもう8進数じゃ足りないんだぞ
未だに引きずられて無理矢理8進数で表現してるのは害悪だから
>>465 気持ち悪いよな
アンダースコアでよかったのに何でって思う
どっかに書いてあった。ユーザー定義リテラルと衝突するんだと。
ユーザー定義リテラルが先にきてて、アンダースコアだと重複してしまうから。
案としてはアンダースコアも出てたはず。
日本の数勘定として、3桁区切りより4桁区切りのほうが良いと思うの。
100,000,000と書いててもぱっと1億って分からん。
1,0000,0000のほうが分かりやすい。
ってC言語関係ないけど。
operator "" _000 () みたいなアホなこと書かれかねないからか
なるほどthx
>>471 4bit区切りでいいだろ
4bit目は予備として0固定にしちゃえばいいだけ
ユーザー定義リテラルで 1_億 みたいには書けるじゃろ
constexpr unsigned long long operator "" _\u5104 (unsigned long long val)
{
return val * 10000 * 10000;
}
// Header <japanese> synopsis
constexpr unsigned long long operator "" _\u4e07 (unsigned long long);
constexpr unsigned long long operator "" _\u5104 (unsigned long long);
constexpr unsigned long long operator "" _\u5146 (unsigned long long);
constexpr unsigned long long operator "" _\u4eac (unsigned long long);
constexpr unsigned long long operator "" _\u5793 (unsigned long long);
constexpr unsigned long long operator "" _\u25771 (unsigned long long);
constexpr unsigned long long operator "" _\u7a63 (unsigned long long);
constexpr unsigned long long operator "" _\u6e90 (unsigned long long);
constexpr unsigned long long operator "" _\u6f97 (unsigned long long);
constexpr unsigned long long operator "" _\u6b63 (unsigned long long);
constexpr unsigned long long operator "" _\u8f09 (unsigned long long);
constexpr unsigned long long operator "" _\u6975 (unsigned long long);
constexpr unsigned long long operator "" _\u6052\u6cb3\u6c99 (unsigned long long);
constexpr unsigned long long operator "" _\u963f\u50e7\u7947 (unsigned long long);
constexpr unsigned long long operator "" _\u90a3\u7531\u4ed6 (unsigned long long);
constexpr unsigned long long operator "" _\u4e0d\u53ef\u601d\u8b70 (unsigned long long);
constexpr unsigned long long operator "" _\u7121\u91cf\u5927\u6570 (unsigned long long);
まあ64bit整数は垓でオーバーフローしちゃうけどな
予約語なのでユーザー定義リテラルをユーザー定義するときはないとダメ
全然関係ない話だが
めんどくさいC,C++を習得すると
他言語学習が簡単に進む
多言語使いは問題解決能力が無いのに偉そう
特にJava
ところで、C++ってどんな開発に使ってるの？
Linuxのアプリ以外で。
https://github.com/satori16/PulseGeneratorForWindows こんな感じの物が作れるようになった。win32apiだ。
コアはそれなりにできたが、UI作ろうとしたらバグで死亡ちゅう。テストは良いけど過信しないで。
VBとかC#のビジュアル開発がどれだけ楽か身に染みてきた。
ところで、[0,1]の引数のみで使える面白関数しらないかい？
logとかは線形な気がするのでもっとおかしな奴ないかい？
>>496 アルゴリズムベンチマーク。
リークしててもそこまで問題にならんし、速度が実際どれくらい出るもんか調べるには良い。
まあcでも良さげな使い方ばっかだけど、namespaceとか多少ね。
>>496 速度が求められるアプリはC++でしょ
大規模データでシミュレーションとかJavaでは遅くて無理
>>501 そうだなｗ
盛大にリークしてたら速度にめちゃ影響するわな
ものすごい潤沢にメモリがあって処理が終わるまでに使い切ることがないという確信があれば
メモリを解放する処理を入れずに速度を優先することは無いわけではないと思うが、
それが妥当かどうかいちいち検討するコストをかけるくらいならちゃんと解放しておいた方がよろしい。
なんで速度を要する処理の途中でメモリを獲得するん？
なんで速度を要する処理の途中でメモリを獲得するん？ 👀
Rock54: Caution(BBR-MD5:1341adc37120578f18dba9451e6c8c3b)
>>503 「ものすごい潤沢」では意味がない
処理が終わるまでに最悪何バイト使う可能性があり、
実装されているメモリは何バイトなのか、
需要と供給の具体的な比較あるのみ
サーバープログラムみたいなもんだったら
リークしてたらどこでシステム停止するかわからんし大問題に繋がるだろうが、
てきとうなベンチマーク検証ならリークしようと最悪落ちようとそこまで支障をきたすわけじゃ無いってことだよ。
てか実際問題そのくらい実験的な意味合いの強いものじゃ無いとc++は苦しい気がするんだが。
C++の生産効率、バク埋め込み率、デバックのしにくさを考えると、積極的にC++を採用すべき分野って限られてくるよね。
組み込みやドライバではCが主流だし、WindowsやスマホではほぼC++は使われないし、Webの世界ではスクリプト言語だし、計算分野ではPythonやMatlabやMathmaticaだし。
仕事でC++使う機会は最近めっきり減ったわ。
スマポとSTL使ってればリークなんかそうそう起こらんだろ
古臭いC++のイメージで語らないほうが良いよ爺さま方
スマポと言っても一秒間に数千回数万回の確保とかしてたら流石に遅くなるんじゃね？
>>509 そんな機会はめったにないし、万が一あったらそこだけナマポとかで対処できるのはC++だけ
>>502 いや、どんな場合でもリークしないように書けよと思って引っかかった
まあ趣味でない限り実用度が学習コストに見合わない感じはあるな
他に比べて
オブジェクトを１個１個newする？
でかいデータだと大量にnewするオブジェクトだったら配列で１MBとかまとめてnewしないと遅いでしょ
メモリ解放にも時間かかるけどそこは計測から外します
都合のいい計測をします
>>508 それで安全になるかもしれないけど
コピーしまくり、newしまくりだったりとかよくあること
C++使う理由をよく考えたほうがいいと思うわ
現代の C++ は処理系もライブラリもそれなりに賢いから、任せきりにしてもそれなりの効率になる。
ほとんど任せきりにできる高級言語としての面と、必要なとこは手動で書ける低級言語としての面を合わせ持つのが C++ の強み。
>>512 お前は最低でも数万行くらいの規模のコード書いてから偉そうなことを言え
最近はC++もスマートポインタが主流で
メモリリークもツールでチェックすると聞いたが
現実はどんなもんなん
VCには簡易メモリっチェックをするヘッダーがある。もちろん環境依存。
スマポでリークするのはかなり筋が悪い。
>>519 まあどんな場合でもは言いすぎだと思うが少なくとも正常系ではリークなしを目指すのは当たり前
スマポでリークするケースというと、昔のインターフェースでスマポそのものが渡せないとかかなぁ。。。
希望としてはリファクタリングしてほしいところだけどね。
>>522 誰が「規模が大きければリークしていい」と言った？
言ってないことを言ったかのように相手の主張を捻じ曲げるな
>>523 ＞アルゴリズムベンチマーク。
＞リークしててもそこまで問題にならんし
リークしたらヒープエリア毎Destroyすれば良いじゃない
@マリー・アンチョワネット
あぁすまん、正常系について誤解してた
まぁ個人で使うレベルなんじゃないかね、本人が問題にならん言うてるし
ウィンドーズにはApplication Verifierがあります！！１１！１！
>>521 malloc()とfree()が対応しているかはばっちりﾜｶﾙのでかなり役に立つが
Win32APIで直接メモリ確保したりC++でメモリアロケータを0から自作した場合はどうなるかわからん…
perfmonで指定プロセスのprivate bytesの推移を取得しつつ長時間動かして直接消費状況を確認するというのがある意味最終手段だが
リークが無い（はずの）プログラムでもなかなか安定しないという印象
多分ユーザーコードからRAIIを排除しても拾ってきたライブラリがRAIIするとかそんな感じ！
>>528 グローバル new 演算子
グローバル delete 演算子
を malloc()/free() を使って定義して、かつ、未解放・二重解放を検出するようにポインタを線形リストに格納してチェックする、ということなら、簡単にできます
win32api でも、たとえば heapalloc() をラップすればいいかと
デバッグ初期の単純なミスならこれで大方弾けます
>>528 MS製だからWIN32位は拾ってくれると思ってたけど、なんだってー。Orz
俺は末端のユーザだからアロケータ書いたりしないのよね。
特に自作したらメンテとか自分でやんなきゃいけない負債になるのでやりたくないなぁ。
>>530 application verifierはwin32apiをhookしてるよ。
hogeはdouble型で
int temp = int(hoge);
if (temp > 0)
return temp;
else
return 0;
このような処理をしたいのですが、何か良さげな内部関数とかないですかね
>>533 C++17 の std::clamp みたいなことがしたいのかな
>>533 std::max(0, int(hoge))とか
アルゴリズムベンチマークなんて長期間稼働するものでもないし、プロセス終わればリークも終わる。
>>533 の言う「内部関数」ってのは、
CPUのマシン語命令を直接利用するビルトイン関数みたいな感じかな。
言い訳にならんよな
数万行って具体的な数値を出してきたのは奴だし
勝手に察すると、単純な話だと思う
彼の把握では、おそらくは次のようになっているハズだ
内部関数＝組み込み関数（あらかじめ用意されている標準の関数）
外部関数＝自作関数、ユーザ定義関数
真意を勝手に忖度すると、「自作関数を作らずにそのまま使えるような便利な関数は既に存在してはいないだろうか」という質問に見える
>>542 俺もそう思った
だとすると536でFA
int ookii=...
int tiisai=...
int V=...
int x = std::max(tiisai,std::min(ookii,V));
ってやると、[min,max]区間内のVが取れたような気がする。
今度C++17で入るクランプがそれ。
>>543 >>512の
＞どんな場合でもリークしないように書けよ
リークしないようなコードを書くのは当たり前だが、どんなに注意してても起きるときは起きる
仮にこういう主張してるやつが居てもお前は俺と同じことを思わんのか？
「どんな場合でもバグらないように書けよ」
車の事故と同じ
起きるときは起きるなんて言い訳は通用しない
まず起こすな
やっちまったら責任とれ
そういう緊張感がいるってことだ
ありがとうございます
max関数使わせていただきます
もう一つ別の質問なのですが、
2つのベクターの要素(1000個程度)の比較で、同じi番目の要素の内容差が10以上の要素番号(イテレータ？)を調べたいです
この操作は何回も繰り返すので出来るだけ高速化したいのですがなにか良い方法ありませんかね？
ベクターの要素はint型で内容は大体1000以下の整数です
vec1[100] = 100とvec2[100] = 300
vec1[102] = 100とvec2[122] = 300
なら100, 102のイテレータ(この後そのまま新しくforに投げるので)
>>549 思わずC# LINQかPython使いたくなる内容だな。
やりたいことは結局のところ行列演算なのでEigen使うと何か方法ありそうだけど、高速化に寄与するかは不明。
>>549 1000個を例えば4コアで250個ずつ並列化してさらにforの中でn個ずつ比較するとかかな…
intelは
_mm_cmpgt_epi16
armは
vcgt_s16
とかあるみたいだけど
>>549 新しく for に投げるっていうのがよくわからんのだが、
やりたいことをコードで (C++17 で導入された構造化束縛を使って) 表すと
for (const int& [element1, element2]: extract_if_big_difference(vec1, vec2)) { ほにゃらら }
みたいに書ける関数 extract_if_big_difference が定義できるといいなぁという感じ？
こうだとしたら、並列化するのは難しい気がするぞ。
こんなのだと速そうな気がする
vec3 = vec1 - vec2;
filter(vec3, 10, index);
void filter(const vector vec3, const int limit, int index[]){
int j=0;
for(int i=0; i<vec3.size(); i++){
if(vec3[i] >= limit){
index[j++] = i;
}else if(vec3[i] <= -limit){
index[j++] = i;
}
}
index[j] = -1;
return;
}
データが多いならざっくり N (2～8)分割して OpenMP とかで並列処理するのがいいよ
数百ミリ秒以上かかるなら他のコアを遊ばせておくのはもったいない
各分割の結果は独立して保持して後で統合する
>>549 vectorじゃなくvalarrayだが。。。
int main()
{
int const n = 10; //おまえさんのリクは 1000 だったな
//このへん前置きは置いといて
mt19937 eng;
random_device dev;
eng.seed(dev());
uniform_int_distribution<int> dis(-20, 20);
auto rnd = [&eng, &dis]() { return dis(eng); };
auto print = [](auto& ct) { for(auto& x : ct) cout << x << '\t'; cout << endl; };
valarray<int> vec1(n);
generate(begin(vec1), end(vec1), rnd);
print(vec1);
valarray<int> vec2(n);
generate(begin(vec2), end(vec2), rnd);
print(vec2);
cout << endl;
//ここが本題
valarray<bool> mask = abs(vec1 - vec2) >= 10;
vec1[!mask] = 0;
vec2[!mask] = 0;
print(vec1);
print(vec2);
}
差が１０以上のところを探して何か処理ならこっちのが楽だべ
>>533の質問のレベルを見ていると、
>>549も｢実装完了しないうちから最適化必要と思ってたけど実はそんなこと必要なかった｣なんて落ちにはならないかなとふと思った。
boost の multi_array ってさ、添字の入れ替えってできる？
例えば要素 a[i][j][k] を a[k][i][j] に、全ての i, j, k について入れ替える操作
自分で実装しなきゃ駄目？
boostみたいなｲﾝﾁｷくさいﾗｲﾌﾞﾗﾘは使ったことないが
ｵﾚだったらｲﾁｲﾁそんなﾑﾀﾞな入れ替えが本当に必要なのかと
まずそこを疑う
>>560 無駄の意味が分からない
テンソルの掛け算するときに行列積ライブラリ使うために足組み替えたりするだろ
できた！
template<typename T>
class MyMatrix3D : Matrix3D {
...
virtual T get(size_t i, size_t j, size_t k) {
return get(k, i, j);
}
...
};
boostとか漏れも使ったことないわ(ﾟ∀ﾟ)人(ﾟ∀ﾟ)ﾅｶｰﾏ
boostはbjamが糞すぎて入れるのめんどくさくなっちゃった
遅くなってすみません
処理が重くなったのは別の部分のせいでした…
Python的考えで5桁くらいインデントしてたので勝手に遅いと思ってましたが普通に高速でした
お騒がせしました
たかだか1000回のループでそんなに速度気になるんか（というか並列化とかベクトル化とか大げさやろ）、
と思ってたけどやっぱりか
>>558の一人勝ちやな
低学歴知恵遅れなら
1回ﾙｰﾌﾟするのに1分かかるようなｺｰﾄﾞを書きかねない
再帰使ってみたが1分かからんかった
ゆ、許された…
https://ideone.com/kHFd61 1分の壁を破るには、何度も何度もそれとわからずに同じ計算をするようなアルゴリズムにしないとだめだなあ…
関数A，B、C、D、EがあってAの中でBを呼んで、Bの中でCを……
って構造があって、例えばEでエラーが出るとします。大本のAにそれを伝えてエラーにしたいんですけどどうしたらいいでしょう
BCDEの戻り値全部boolにしてfalseを返すくらいしか思いつかないです
>>574 戻り値でもいいし、引数に参照やポインタを渡してもいいし
例外でもいい
書く分には例外を投げるのが楽じゃないの。
関数 B, C, D ではそのエラーについて忘れておくことが出来るので。
>>574 典型的な例外の出番だ
void E() { throw std::runtime_error("error at E()"); }
void D() { E(); }
void C() { D(); }
void B() { C(); }
void A() { try { B(); } catch(std::exception& err) { std::cerr << err.what(); } }
皆様ありがとうございました。
別関数からのまでcatchできるとは知りませんでした。
>>574を参考にしつつ書いてみようかと思います。
ファイル読み込みのときはあんま例外使わないなんて記述見たんですけど別に書いても大丈夫ですよね
スッゲェ素人なんだけどよ、他人が作ったクラスに自作関数を付け加えたいときってどうすんの？
（例えば、行列クラスに特異値分解する関数を付け加える等）
継承ってやつを勉強して使うだけ？
C++ の言語仕様と常識を勉強したいという意味でもあるので、「その他人のコードを直接編集せよ」ってのはナシで頼む
>>581 機能を追加するために継承使うのは設計的によくないよ
>>581 クラスの親子関係がはっきりしてるなら継承。
機能が似てるだけなら移譲。
どちらか迷ったら移譲。
>>583 void svd(Matrix &pMtx);
みたいな関数ではダメなの？
>>584 移譲という用語は初めて知ったので、勉強してみます
>>585 ダメ、ということはないと思いますしこれまではそうしてきました
しかし、行列の特異値分解は配列ではなく行列に適用するべきだという意識が強くなりました
BLAS 等の多くてややこしい引数も、「行列を渡す」という形で書くことでもう少し自分にとって読みやすくなるのではないかとも思いました
クラスだとか他人のコードの拡張といったことを勉強してみたくなったということでもあります
>>586 なんでもかんでもメンバ関数として持たせるのはダサいというのが近年の風潮。
設計方針にもよるんだけど、機能をちょっと増やすたびに新しい型を作るのも馬鹿馬鹿しいだろう。
単なる関数として作ればそれでよいはずのことにクラスの依存関係まで出てくるの、ホントに良くない。
>>584 ＞どちらか迷ったら移譲
やめろ、割とマジで
本来継承が好ましいものに委譲を使うと後々になって必ず破綻する
お前D&E読んでないのか？
>>587 ＞ダサいというのが近年の風潮
そういう言い方・考え方もやめろ
かつてC++の継承は汚いからテンプレートで代用しろ、みたいな理屈があったが全くの空回りに終わった
その間初心者は嘘の情報に騙されたりオブジェクト指向を誤解したりして、結果C++から離れていった
＞単なる関数として作ればそれでよいはず
これは正しい
>>587 完全に同意。
クラスの数が星の数ほどあるプロジェクトで、継承してメソッド一個追加してるだけとかの経年劣化したソース見たら目眩がするわ。
オブジェクト指向の初期啓蒙として「既存のクラスは変更するな」「機能追加は継承使え」って言ってた人を恨むわ。
>>588 もちろん「IS-A」が成り立ってる継承が適してるものは継承使うべき。
むしろ継承を使うべきでないとこに継承使ってるほうが後々破綻するので悩んだら委譲。
>>588-590 では特異値分解、スライシング、掛け算、足し算、エトセトラ……、という大規模な機能追加を既存のクラスに対して行ないたい場合はどのようにするべきでしょうか
>>591 うーん、場合によるけど全てそのクラスに対する操作ならさすがに継承するかな。
後々のメンテ考えたら可能であれば継承元のクラス変更するけど。
他人が作ったクラスで勝手にいじれないんでしょ？
protectedやvirtualなメンバがあって、それを使って色々するなら当然継承すればいいけど
そうじゃない継承される前提で作られたクラスじゃないなら継承はオススメできんなあ
svd(m)をm.svd()って書きたいためだけに継承の山のようなトラップ抱え込むのは割に合わないと思うよ
どうせ親クラスのprivateはいじれないんだし
>>591 使ってるのはuBLASだっけ？調べてないのでわからんけど・・・・
継承を前提にしたクラス（デストラクタがvirtualであり、実際継承してみても使える）なら継承もアリっちゃアリだとは思う
（責任は負わんｗ あくまで勉強目的でやってみるのはいいと思う）
ただ、特異値分解は知らんのでわからんけど、一般に演算クラスの機能追加は
>>587の言う通り、単純にそのクラスを受け取るグローバル関数にする方がいい
特に
＞掛け算、足し算
こんなのはまさにメンバ関数にしなくても、グローバルに演算子オーバーロードを定義すれば済む
（メンバに書いてもグローバルに書いても利用者側はA * Bって書ける
あとv1.dot(v2)よりdot(v1, v2)のがわかりやすいと思うけどね
>>592-596 なるほど。
普通に関数にするのが、必要十分さの面で、良さそうですね。
頭の中にあったのは、自分で作った関数群が全て○○というクラスに対して使用することを想定している、と明示したかったということです。
グローバル関数の用途を明らかにする方法として、メンバ関数化すれば良いのかな、と思いました。
メンバ関数にはしないということにした場合、上のことを実現するにはどうするべきでしょうか。
コメントやノートに書くくらいしか思い付きませんが、それで良いのかな
引数の型が○○やconst ○○&になるでしょ
それ以上のなにが欲しいの？
そういえばBLASとは書いてたけどuBLASとは書いてなかったな
いずれにしても、その扱いたいクラスを受け取る関数だから見たらわかるっしょ
違う型を渡したらエラーになる
>>597 どうでもいいけど最初と大分キャラ変わってるぞw
>>598-599 わかりました。
確かに型を見たら自明ですね。
結局は
> svd(m)をm.svd()って書きたいためだけ
だったのかも知れません。
なんせそういう書き方はいかにも「ぽい」ですから。
ありがとうございます。
>>601 横レスになるかもだけど多相的に関数の集合を規定したいなら[C++ traits]で検索すると幸せになれるよ
今回は不要だと思うけど後々欲しいなって思ったとき役に立つ
>>588 いや、風潮っていうのは確かにあるよ。
かつて上手くいかなかったから今もダメとは限らない。
テンプレートの活用が失敗っていうのは言語そのものとしてのサポートが不充分だったというのがあって、
それは
>>602 がいうようにトレイトの活用の知見が蓄積してきたことで風向きが変わってきてる。
今はクソみたいな SFINAE と type_traits で不格好になんとかしてるのも
C++20 でコンセプトが入ったら C++ のパラダイムがそっちに一気に傾くと思う。
Rust や Go の隆盛でプロトコル指向への理解が深まっているというのもある。
・・・・・俺が何を批判したかわかってないな
「ダサい」とか「風潮」じゃなくて、何故それが好ましいか、好ましくないか、
質問者のケースに合った説明をしろっつってんの
なんで当時の「テンプレートで継承の代用」の例を出したかわからんか？
代用にはなり得ないんだよ原理的に
実行時のポリモーフィズムをテンプレートで実現できるのか？
ユーザーの入力やファイルの内容に従って実行時に作るオブジェクトを変え、かつ
それを１つの型でまとめられるのか？？
type erasure(boost::any含む)とかswitchとかif使う、とかは無しでな
自分の頭でその方法が合っているか合っていないか考えずに
流行とかに流された結果が、↑で挙げたソレなんだよ
C++潰したいのかよ
>>604 これも横からだが、C++はもう役割を終えて衰退機だと思う。
今から積極的にC++を採用する分野は限られていて、使えるor使おうと思うエンジニアの絶対数が減るってことは衰退と同義だと思う。
いろんな言語のエッセンスを学べるので悪い言語でないとは思うけど、誰かが言った通り習得のコストに見合ったメリットがない。
盛者必衰。
>>604 > 何故それが好ましいか、好ましくないか、
> 質問者のケースに合った説明をしろっつってんの
それは
>>587 の説明で足りないか？
風潮があって、その理由は不要な複雑さが出来るからだという説明で足りないか？
この説明は質問者のケースに合致してないか？
> 代用にはなり得ないんだよ原理的に
違う機能が違う能力を持つのは当たり前だろ？ 説明するまでもなく。
どちらの機能を中心に活用した「設計」がよいのかっていう話じゃないか。
>>606 ああすまん、確かに言葉尻に反応したところはあったな
でも「風潮」とか「ダサい」って蛇足だよな？ｗ
ダサいって言いたかっただけやろ？
＞違う機能が違う能力を持つのは当たり前だろ？
お前
>>603で
＞かつて上手くいかなかったから今もダメとは限らない。
＞テンプレートの活用が失敗っていうのは言語そのものとしてのサポートが不充分だったというのがあって、
テンプレートを盲信してるようだから説明したんだが。
継承をテンプレートで代用せよ、ってのは間違ってない、って言いたかったんだろ？
＞C++20 でコンセプトが入ったら C++ のパラダイムがそっちに一気に傾くと思う。
とか言ってる辺りからも、オブジェクト指向は過去のものだから継承も過去のものなんだぜ、とか
抜かしたかったのがわかる
マルチパラダイムの意味わかってる？
継承をテンプレートで置き換えるって失敗したというよりもすでに当たり前になっただけでは
むしろそっちはそっちで発展してるし、動的でなくてもいいケースは確かに存在している
>>608 静的に解決できるものならそうだろうな
そういうケースを否定はしてないが、当時はあちこちでそういう失敗例がドヤ顔で披露されてたんだぞ
禿も指摘してるようにJavaのせいだが
>>607 > 継承をテンプレートで代用せよ、ってのは間違ってない、って言いたかったんだろ？
違うものは違う。 代用品ではない。
継承構造の代用品としてテンプレートを使えというのではなく、
テンプレートも前提のひとつとしたデザインにしろと言ってんの。
「なにもかもをメンバ関数にするな」というのは全て非メンバ関数にしろっていう意味じゃないだろ。
>>610 >>603で
＞かつて上手くいかなかったから今もダメとは限らない。
＞テンプレートの活用が失敗っていうのは言語そのものとしてのサポートが不充分だったというのがあって、
＞それは
>>602 がいうようにトレイトの活用の知見が蓄積してきたことで風向きが変わってきてる。
って言ってるよな
「かつて上手くいかなかった」って、
俺の「かつてC++の継承は汚いからテンプレートで代用しろ、みたいな理屈があったが全くの空回りに終わった」
のことだろ？言い逃れしてんじゃねーよ
ちなみに継承をテンプレートで代用、を挙げたのは、それに初心者が惑わされたからだ
ただのテクニックの紹介ではなく「C++の継承は汚い」みたいな暴言を伴ってな
お前が「ダサい」とか「風潮」とか、自分がドヤりたいがために選ぶ言葉と同じだよ
＞「なにもかもをメンバ関数にするな」というのは全て非メンバ関数にしろっていう意味じゃないだろ。
質問者の「関数追加」の方法についてはお前の意見に賛同してるだろうが
あ、ついでに言うと
＞言語そのものとしてのサポートが不充分だった
ねーよ
C++98～03でも十分メタプログラミング出来てたぞ（11から確かに幅は広がったが
STLしかりModern C++ Designの著者のLokiしかり
Boostだって当時からあったからな
>>605 C++に挫折でもしたの？ w
ネイティブコード吐けるオブジェクト指向言語ってそんなに選択肢ないし
FixedC++であるRustに期待はしているが・・・。
>>611 なんでその結論に納得できるのに前提に色々言ってんだ？
テンプレートについてはそっちが言い始めたことで、別の話題だろ？
代用という言葉の使い方がちょっとずれてるだけじゃないの。
そのまま置き換えれるかという意味では代用できないし、
継承でなんとかしてたデザインをテンプレートを活用したデザインに置き換えられる (こともある)
という意味では代用ともいえる。
言葉については、「ダサい」はともかく、「風潮」に何か問題あるか？ それは全くわからんな。
デザインの風潮というものは間違いなくある。
>>613 無理無理。
今だってろくでもない回りくどい仕組みでどうにかこうにか
型の制約を表現できてるってだけだもの。
初心者にそれを元にデザインさせるのは無理。
型の制約についての知見とは別に C++ の言語機能が足りてない。
＞テンプレートについてはそっちが言い始めたことで
ダサいとかイケてるとか風潮とかで設計を語るからだよ
お前の説明はだいぶ甘い、自分でよくわかってないものを押し付けてないか？
そういう傾向を指摘されたって気づいてるだろ？
自分のコーディングの経験が足りてないゆえに、はっきり断言できないから風潮とか出てくるんだろ？
さっさと謝ってりゃここまで言ってないんだがな
＞デザインの風潮というものは間違いなくある。
そう思ってんのはお前らアマチュアだけだから。（特にお前の思ってるようなデザインについては）
>>617 何の話してんの？コンセプト？ｗ
なんで初心者がまだ導入されてないコンセプト前提の設計しなきゃならないの？馬鹿なの？
コンセプト入ったら実行時のポリモーフィズムをテンプレートで出来るの？？？？ｗｗｗｗｗｗ
最初はもてはやされたけど、みんな知ってる前提になったら特に触れられもしなくなった
風潮ってこいうのだろw
すまんちょっと熱くなりすぎた
論破されたことに気付かないアホ（あるいは謝ったら死ぬ病）相手にするとキリが無いわ・・・・
もうやめとく
権限の委譲というと良いものを与えているイメージだが
UML用語の委譲はどうみても仕事の丸投げとかたらい回しな印象であるイメージ
な気がする
昨日のプログラムを改良したったｗｗｗｗｗ
https://ideone.com/hkeEp0 データ数N=300のときCore i7-860 (2.8 GHz)で8秒かかる。idoneのやつでも5秒。
N=1000だと宇宙の終わりまでかかる予定。
これで漏れも低学歴知恵遅れに晴れて仲間入りDA☆NE！
https://ideone.com/CYkJfe 高速化する話なのか低速化する話なのかは分からんけど、素直に書いたらこんな感じかなぁとか。
終わった話題かもしれんけど。
どうしても高速化したいんやったら、関数を並列実行できるようにして、
https://cpprefjp.github.io/reference/thread/thread/hardware_concurrency.html 上記の数で分割実行かなぁとか。
フューチャー投げるのはそんなに難しくないと思う。std::async使えば簡単だし。
気が付いたら、absがテンプレート関数じゃなくなってた。
constexprな関数はコンパイル時でも実行時でも使えるが、定数になる文脈とならない文脈で関数を使い分けしたい。そういう使い分けは可能だろうか？
例えばsqrt関数はconstexprになっていないが、
アルゴリズム的には自作関数でconstexpr対応可能
ただし速度的にはcmathのsqrtの方が何倍も早いのでconstexprでない文脈の時にはcmathのsqrtを呼び出したいのです。
is_constexprで検索したらそれっぽいアイデアは出てくるけど
>>625 ビルド過程を見直せば？
バカみたいに何でもかんでもconstexprに頼る理由はない。
>>618 なんで実行時ポリモーフィズムの話なんか出てるんだ？
出来ないもんをやれなんて言ってないだろ。
関係ない要素をどんどん出してくるなよ。
何を言いたいんだ？
templateで躓いてるんですけど皆どうやってテンプレートを勉強したんですか？
>>631 Boostのテンプレートを読んでるのですが、理解できない点です
>>632 まずはstlは一通り不自由なく使えるかな？
>>633 はい、STLに関してはそれなりに使えます
>>632 Boost はかなり技巧的で無理やりなこともやるので、
ある程度 C++ をわかっている人でもまともに読めないこともある。
普通に入門書とかを読むところから始めるしかないんじゃね？
boost読んでテンプレート勉強しようとするのは、IOCCCでCを勉強しようとするのと同じくらい無謀
boostのｲﾝﾁｷくさそうなｿｹｯﾄ通信とか使ってるﾔﾂいんの
普通にsocket通信の関数で書いたほうが可読性が高そうで困る
>>639 Boost のことはよう知らんけど、
Boost の他のライブラリと組み合わせやすいとか、
そういう利点はないの？
bool operator<(const T& a, const T& b)は定義されている前提で、
クラスTについてbool operator==(const T& a, const T& b)が定義されていたらそのoperator==()を使い、
定義されていなかったら
bool operator==(const T& a, const T& b) { return (!operator(a, b) && !operator(b, a)); }
を勝手に補完するようなテンプレート（の特殊化？）ってどうやって書くの？
std::rel_ops空間に == から != を、< から <= > >= を合成するテンプレートならあるけど
detection idiomで検出してSFINAEで分岐させるだけでできそうだけど
barton nackman trickやな
operator ==が定義されているかどうかの分岐はSFINAEいるんでちょっと複雑になりそうだけど
private継承する基底を選ぶような形にできるはず
そんなことができるざんすか。
めんどくさそうですな。
if constexprつかえばSFINAEいらんな
普段使えない環境だから出てこなかった・・・
スフィ姉たまんねぇ
ていうか
>>643見てnamespace rel_opsの定義見て考えたがSFINAE要らなくね？
コンパイラの挙動（関数名の解決規則？）として、
Tについてoperator==(const T& a, const T& b)そのものズバリが定義されていればそれが使われるし、
無ければその次以降にテンプレートを探しに行こうとするから、
そのときstd::rel_ops名前空間が導入されていれば勝手にテンプレートバージョンが使われる
というしくみっぽい？
>>632 バリバリのテンプレート使いいませんか？
テンプレート難し
>>648 if constexprほとんど使ったことなかったけど便利だなー
確かに型で分岐する必要なかった
https://wandbox.org/permlink/8CGWlZ5i5JLl33Ws >>649 その方法だと、
>>642で言ってるような特殊な補完を他のクラスにも適用することにならん？
それでもいいならいいけど
>>650 わかんないなら質問すればいいじゃん
何がわからないから分からないと本とかのおススメもできないだろ
>>652 >その方法だと、
>>642で言ってるような特殊な補完を他のクラスにも適用することにならん？
ならない。ならずに済ませられることができる
補完する演算子のテンプレートの導入範囲を名前空間で限定すればおk↓↓↓
https://ideone.com/p4FS43 21行目のOP_EQ_FOO_ENを定義してもしなくてもビルドが通り、Foo::operator==()の呼び出し回数を除き同じ結果になる。
ただし、operator==()についてはちょっぴり闇が深いことがわかった。
名前空間std::rel_opsにはoperator==()テンプレートが存在しない
上のサンプルではstd::rel_ops名前空間に無理矢理operator==()テンプレートを追加したが、
実際にやるときは独自の名前空間でoperator<()以外の全部（==、!=、>、<=、>=）を用意しておくことになるん
ｼﾞｬﾏｲｶ
あーすまん、目的を誤解してた
クラスのoperator ==の実装を省きたいんじゃなくて使う側で補完できればいいのか
5年くらい前？にテンプレートプログラミングっぽい趣旨の本があったし、基本情報に何故かPrologと同じジャンルにテンプレートが言語として載ってる辺り論理型言語っぽい事ができるみたいだが、基本C++の1機能でしか無いから、知ってる人は少ないんじゃ無い？
俺も知らない。
C++テンプレートテクニック 第2版、
επιστημη(えぴすてーめー)・高橋 晶、2014
C++ 標準化委員のεπιστημη の本だろ。
ドワンゴ江添亮も、需要があれば、こういう本を書きたいって言ってたけど
それそれ。
出来るっぽいってのは知ってても、実際できてる奴少ないと思われ。
ﾃﾝﾌﾟﾚｰﾄ使うのに
いちいちそんな悩むもんなんか
なにかを参考にしたいようだが
たとえばtraits乱用してるようなのは読む必要もないし
逆にﾏﾈする必要がないわ
俺も気にした事ないけど、気になる奴は気になるんだろう。
俺の場合は整数型をどうやって文字列型にしてるんだ？ってのが疑問でむしろアセンブラに走って頭捻って理解した。
まあ人間そんなもん。
テンプレートはC++の必須教養だと思ってるけど、別になくても困らないしな・・・
>>661 つ vc++ 1.x
こいつのテンプレートは泣ける
>>656-
>>661 同感
はちみつと言い争ったときに
＞＞デザインの風潮というものは間違いなくある。
＞そう思ってんのはお前らアマチュアだけだから。（特にお前の思ってるようなデザインについては）
とか書いたけど
実践ではなく仕様メインで覚えてる人（趣味でC++の知識を集めるのがメインの人であり、アマチュア）は
「これからの時代はテンプレート使った総称的プログラミングが主流」
みたいなパラダイムの変化を訴えてるけど、それはっきり言って素人が見れるコードでだけだから・・・
（C++標準ライブラリやBoost等）
テンプレート使ってとことん汎用性を高めたライブラリなんか、普通のソフト開発の現場では使われんわ
あまりにも時間がかかりすぎる
そういうごくごく一部の偏ったソースしか読んだことないから誤解するんだろう
で、その誤解した趣味グラマのネット上の言説やライターが書いた本を読んで、
初心者がC++に挫折して去っていくという・・・・・
C++なんか最初はベターCでいいんだよはっきり言って
あと最近ネット見てて（C++の）オブジェクト指向とかC時代の古いノウハウの解説が少ないのは、
単にとっくに出尽くしたからだからな、最近始めたやつは誤解したらだめよ
訂正
Ｘテンプレート使ってとことん汎用性を高めたライブラリなんか
○テンプレート使ってとことん汎用性を高める開発手法なんか
>>663 「何もかもを継承構造で解決しようとするな」の
ひとつとしてテンプレート (を C++ なら利用することになるプロトコル指向的デザイン) が出たんだし、
C++ にコンセプトの概念を持ち込もうとする機運があるほどには活用比率も高まるだろう、という程度の主張なのに、
「とことん汎用性を持たせるべき」とか「主流になる」みたいな拡大解釈はやめてくれよ。
俺はそんなこと主張してないからね！
>>665 しつこいぞ
＞テンプレートの活用が失敗っていうのは言語そのものとしてのサポートが不充分だったというのがあって
「おかしな流行が発生して初心者を惑わした」、に対して反論したんだろ？嘘つくなよ
＞俺はそんなこと主張してないからね！
主流になる、って意味だろ？これ↓
＞C++20 でコンセプトが入ったら C++ のパラダイムがそっちに一気に傾くと思う。
ちなみに
＞コンセプトの概念を持ち込もうとする機運
コンセプトは標準化委員会や禿が言い出したことだぞ
導入されたら素晴らしいとは思うが、元々はテンプレートを使ったコードのエラーメッセージをどうにかすることと
テンプレートパラメータで満たすべき要件をコメントではなくコードで示せるようにすることだ
プロトコル指向は聞いたことないが、それはコンセプトで可能になるおまけ程度だろ
しかもそれを利用するにはテンプレート必須なわけで、コンセプトが入ろうが、
クラスなどが実際どういう仕組みなのか程度のことは把握してないと、初心者が手を出せるようなものではないし
出させるべきでもない
>>666 変な (教え方なり使い方なりが下手くそな) 流行があったということを以て
テンプレートの活用を全否定するような言い分に反論したんだよ。
テンプレートが無くて良いと思ってるわけじゃないんだろ？
> 主流になる、って意味だろ？
今までが継承構造に頼りすぎだったのが是正されるという意味だ。
初心者への教え方については、また別の話。
ベターCからで良いという意味のことは D&E にも書かれてる基礎理念だから
そこは疑ってない。
＞テンプレートの活用を全否定するような言い分に反論したんだよ。
>>587と
>>588を100回読み直せボケが
悪いけど、お前まともにメタプログラミングやってないだろ？
まともに活用して利点・欠点をはっきりわかってないやつが何偉そうに語ってんの？
しかもその理由で反論したんなら、なおさらポリモーフィズムの話で論破されただろ、
なんで認めずに自分の主張の意味を途中から変えてまで言い返してんの？
図星突かれて気分が悪いってか？
＞今までが継承構造に頼りすぎだったのが是正される
誰が頼りすぎてたの？？今までっていつまで？
＞初心者への教え方については、また別の話
今まで何度も「こいつ初心者にテンプレート勧めてるよ・・・・何考えてんだ」と思ってたんですが
どの口で言ってんだ
>>668 ポリモーフィズムの話ってなんだ？
初心者へじゃなくて、
君に、テンプレートの話はしてたつもりだが。
(ID 変わってるから他の人だったらスマソ)
他の人にアンカーを付けてテンプレートの話はしてないだろう。
>>668 > 誰が頼りすぎてたの？？
標準ライブラリすら。
その他はまあ、私の実感なので、違うというなら違うのかもしれない。
本当にテンプレートが必要なものってだいたいSTLに揃ってる印象。
あとはTBBみたいにある程度低いレイヤーの抽象化ではどうしても必要にはなる。
しかしこの種類のライブラリってのは本当に信用できる奴が作ったもの以外は
使いたくねーんだわ。
めちゃくちゃデバッグコスト高いからね。
そういう意味で一般プログラマーが実装するってのは実践的ではない。
テンプレートは型の定義をすり替えるために使うもの
#ifdefで型切り替える方がもっと糞だからそこはテンプレートにするべき
それ以上の凝った事はしないほうがいいね
頼りすぎつーか逆だと思うぜ
コンテナの要件なんかインターフェイスにすればすっきりするのに
紙マニュアル（pdf含む）でガタガタ書かれた口約束とかすげーイヤ
歴史的に見てもそれをやるのに充分な言語機能がもうあったのに
>>675 現状の C++ では型の制約を表すには意味不明な SFINAE で回りくどくやってて
初心者には使いこなせない (中級者でも不安があったり面倒だったりする)
という話の文脈だから、言語機能が充分だというのはちょっと変な立場だ。
どうーがんばっても停止性問題は機械的に解けないケースを無くせないのだから
プログラミング自体をアルゴリズム化する企てはどこかで行き詰る
藻前らは行き詰まりかたの良し悪しを議論しているにすぎないのだｶﾞﾊﾊﾊﾊﾊﾊ
>>675-676 ひょっとして抽象クラスでやったらいいという話だろうか。
Java とかから来た人はそういうことをやりがちだけど、 C++ の設計理念からすると、
少なくとも標準ライブラリでは仮想関数テーブルを辿る実行コストを許容はしないだろうと思う。
>>678 動的結合のコストは関数ポインタなみにはっきりしてるだろ
インターフェース（＝データメンバーなし抽象クラス）は静的な型の制約を表現できないからダメ
>>678 ＞C++ の設計理念からすると、
＞少なくとも標準ライブラリでは仮想関数テーブルを辿る実行コストを許容はしないだろうと思う
滅茶苦茶言うな
https://cpplover.blogspot.com/2015/09/memoryresource.html >>673 ついでに開発コストも高い
STLが優れてるのは、作者が長年コンテナについて熟考に熟考を重ねたライブラリだからであって
それを実現するためにテンプレートが使われたに過ぎない
テンプレート使ってりゃなんでも有用なライブラリになると勘違いしてるアホが増えた
テンプレートは即席麺的な発想でライブラリのような寝かして熟成させるワイン的な使い方には向いていない
インターフェースはあらゆるメソッドを最初から詰め込まねばならないからｲﾔｿ（特に単一継承の場合
お禿様も自著でそういう傾向（あらゆるメソッドが基底クラスに集中する傾向があることをこっそりカミングアウトしていたはず
テンプレートにはそういう制約がない
型引数Tにadd()メソッドがあるものとしてテンプレートを書いたら、add()メソッドがある既存クラス全部にそのテンプレートが使える
というわけで、インターフェースはそれ自体静的な型の制約のつもりなのかもしれんが、
真にかけたい制約（上の例でいうとadd()メソッドの存在だけを問題にしたいケース）に対して不必要に過剰になることが多いｷﾓｽ
あとインターフェースだとコンテナの実現は具体的にはどうするんじゃ…
仮想関数テーブル参照の実行時コストだけでも許容し難いのに、間接参照がさらに必要になるんじゃ…
インターフェイスを単一継承前提で考えるって、どんな教育を受けるとそうなるのかな
numeric_limits<uintmax_t>::max()歩譲って単一継承ってことにしても
最初から全部詰め込みなんてハメにはあまりならないし
あらゆるメソッドが基底クラスに集中するなんて事例あるか？
俺は空想論だと断言するぞ
Smalltalkのobjectみたいなクラスに何が置けるんだよ
あと、なんか仮想テーブルのコストが云々いってるやつが複数いるようだが
具体的にどのくらいか、せめてオーダーくらいわかっているのか
オーダーの問題じゃなくて、C++にはゼロオーバーヘッドの原則があるんだから
ゼロオーバーヘッドに出来るものはゼロオーバーヘッドにするんだよ、標準はその手本なんだから
それにオーダーなんか処理内容でなんぼでも変わるだろ
せいぜい数十万要素のコンテナしか使わないプログラムだから仮想テーブルなんかどうでもいいと主張する奴の言うことは正しいかもしれないが
数兆個の要素を扱う人にはそんなもの慰めにならん
>>684 >インターフェイスを単一継承前提で考えるって、どんな教育を受けるとそうなるのかな
型に対する静的制約を実現するにあたり、多重継承は助けにならないからですだが…
>あらゆるメソッドが基底クラスに集中するなんて事例あるか？
上とまとめて理由を述べる
今、add()メソッドを備えるインターフェースA、sub()メソッドを備えるインターフェースBがあったとして、
加減算ができる具象クラスDやEは、それぞれAとBを多重継承したら一応はできる ・・・(1)
しかし、このバージョンのDやEは「加減算ができるクラス」という静的制約を満たしているとは言えない
なぜなら、DとEは全く別のクラス扱いになるから、DとEを共通に扱える関数を書けないので…
「加減算ができるクラス」という制約の正しい書き方は、AとBを継承するインターフェースCを定義して、
DやEにCを継承させる（単一継承）とらざるおえない ・・・(2)
なおいうまでもないことだがテンプレートにはそんな制限は無い。(1)のバージョンのD、Eに対して
問題なく「加減算ができるクラス」という制約をかけられる（Cにメソッドを集中させる必要が一切ナッシング
ていうか最後の2行で筆が滑ったorz
テンプレートで「加減算ができるクラス」という制約をかけるにはインターフェースA、Bもそもそも要らん
ｽｹﾞｰ便利
どう説明したもんかと思ったけど、
>>683 の説明が分かりやすいな。
(Java でいうところの) インターフェイスは型の性質を事前に網羅しなきゃ
全体のデザインが定まらない。
関数が要求する性質 (インターフェイス) が増えた時に元の定義をいじるか、
mixin のような形で継承関係を作ることになる。
ちょっと機能を増やすだけでいらん継承関係を作るのは良くないという話の延長線上で
考えればインターフェイスを使ったところであまり解決にならない。
型制約 (コンセプト) は関数の側に付加するものなので、後付けが簡単だ。
結果的に型の側はその性質を持たなきゃならないことにはかわりないが、
性質を追加するのに元のクラス定義を弄らなくて済む。
-----------
最初の設計がキッチリしてたら、
クラス指向的なスタイルの方が混乱が少なくて良いかもしれないなと思い始めてきた。
でも、現実にはそうではない後付けだらけじゃん？ とも思ってるわけ。
>>686 型に対する性的制約って何？
それと事例あるか？と聞いている質問に何で長文がいるんだよ
具体的なライブラリとクラス名を挙げるだけだろうが
なるべく知名度の高い事例ほど説得力があるぞ
>>689 コンセプトを盲信しすぎだろ
あくまで要件をコードで示せるだけだっての
それこそSTLには必ず導入されるべきものだけど、そのSTLでの不満、
つまりInputIteratorだのなんだのの要件をいちいちリファレンス参照しないとわからなかった(
>>675)から
必要とされたわけで
はちみつとかは多分STLべったりで、それ以外のライブラリを読んだり
まともにソフト書いたことないから、STLがほとんど出てこない状況ってのを経験してないんだろ
＞ちょっと機能を増やすだけでいらん継承関係を作るのは良くないという話の延長線上で考えれば
話を広げすぎ。
型の制約という意味でいえば、現状コンセプトを待つしかないが
多分
>>684が言ってるのは、Modern C++ Designで言うところのポリシークラスみたいな話じゃね？（違うかもしれんけど
この場合はあくまで要件定義なので当てはまらないと思うけど、
＞いらん継承関係を作るのは良くない
これは暴言。Andrei Alexandrescuに言ってくれば？
ポリシークラスのような、継承によって機能を取り込む設計も非常に便利だし、それこそSTLでもあちこちで使われてるんだがｗｗ
あと後半チラ裏にも程がある。何様だよ
Container<T>のbegin()が返すのはIterator<T>だとか
Matrix<M,N>とVector<K>はN==Kのときだけ掛け算できて結果はVector<M>だとか
Converter<V,W>とQueue<X>とProcessor<Y,Z>を持ってたらWとXとYはコンパチブルじゃなきゃいけないとか
そういうのが型の静的制約
へーえ、vector<int>とvector<string>が掛け算できないという制約が
pure virtualを使った途端に無法状態になってしまうのか
じゃあ練習問題だ
IntVector::begin()の戻り値はIntIteratorで、IntIterator::value()はintを返す
StringVector::begin()はStringIteratorで、StringIterator::value()はstringを返す
そういう制約を表現するインターフェースIVectorを具体的に書いてみよう！
出来やしないのは手を動かせばすぐわかる
ああこれだけだと出来ちゃうか
end()もあってbegin()と同じ型のイテレーターを返すっていう制約も付けてちょうだい
#define interface struct
template <typename T>
interface IVector
{
class iterator;
virtual iterator begin() const = 0;
};
>>691 ポリシークラスは注入 (?) すべきポリシーをパラメタ化してるだけで、
何をパラメタにするかというデザインがきちんとしてれば有用だし、
いらん継承だとは思わないよ。
でも、現実には後になってそれがわかることもあるよねっていう話。
>>698 は？ 後出しで言い訳してんじゃねえよ蛸助
インターフェイスがテンプレートになってる実例をまさか知らんのか？ｗ
お前の主張通り継承で全部やれよ
そういう所が雑魚なんだよｗ
そっくりそのままお返ししますわｗ
テンプレートと継承の出来ることと出来ないことの区別がつくまで二度と下らない妄言吐くなよ
>>697 ＞現実には後になってそれがわかることも
それは
＞何をパラメタにするかというデザインがきちんとしてれば
が後で変更になることもある、ってことだろうけど
そこまでの変更があったら、結局元の定義に手を出さなきゃいけないのは
どんな設計でも同じことだと思うけどなぁ
＞性質を追加するのに元のクラス定義を弄らなくて済む
と言ってたが、それは結局関数とかでクラスの要件を必要以上に大きくしないように
例えばallocator_traitsみたいに、色々手間をかけて、利用するクラスへの依存を減らすのと同じじゃね？
俺にはそういうイメージしか沸かないんだが
コンセプトマップってそういうことだろ
結局テンプレートであれこれ書くことになるか、コンセプトマップであれこれ書くことになるか、ってだけ
（＝開発コストは高い）
std::vectorだって、例えばアロケータは初期化時に渡さないといけないし
コピーとかしたときにアロケータはコピーしてくれなかったと思うが
それが不便だという声もある（ここでたまに取り上げられるEASTLの開発動機で触れられてる
あと、アロケータは型に依存するけど、メモリ確保なんてのはそもそも型は関係ないので
アロケータのあの設計は失敗かもね、というのもある（同じくEASTLでも触れられてる
それに対する代替案として、上で挙げたstd::pmr::memory_resourceが出てきたわけだけど、
今更STLの基本設計は変えられないのでpolymorphic_allocatorでラップするということになった
もしvectorがポリシークラスを受け取って、アロケータやメモリ管理についてもっと汎用化してたら
こういう問題は起きなかった（クッソ複雑になってるだろうけど）
これコンセプトでどうにかなるか？後になってわかってもどうにもならんよ
ヒープ領域にインスタンスを作りたいときってどうしてもポインタを意識しないとダメなの？
MyClass abc;
みたいに宣言したいんだが。
MyClass* abc;
abc ＝ new MyClass;
みたいにするしか方法ないの？
ヒープに作りたい理由は、巨大なオブジェクトだから。
ちなみにスマートポインタは使えない (icpc 12.0.4)。
コンパイラに指示できるか、という意味ではないよ
そんなのあったも紛らわしいだけだと思うけど
>>704 MyClass& abc = *new MyClass;
でいけるかも知らんけど十中八九delete忘れるし後から見て分かりにくいだけだから俺ならやらない
struct MyClassHolder
{
MyClass* p;
MyClassHolder(): p(new MyClass()){}
~ MyClassHolder(){delete p;}
};
とか作っとけばいいんじゃない
自分でスマポ書いてるのと同じだけど
>>707 ありがとうございます。
参考にします。
ちなみにポインタをどうこうしたくない理由は、これまで MyClass のインスタンスを参照渡しするように作っていた関数を、できるだけ変更したくないからです。
参照渡しをポインタ渡しに変えて、関数内に適宜アスタリスクを挿入するだけですか？ 考えるのもしんどいです。
>>703 > 色々手間をかけて、利用するクラスへの依存を減らすのと同じじゃね？
その通りだよ。
プロトコル指向でいうプロトコルは C++ で言うならまさにトレイツに相当すると思う。
(C++ では実装を直接的に強制する方法ではないけど。)
継承構造ではなく性質でジェネリック関数を使うってだけ。
継承で表すよりも性質で表現する方がたぶん記述は細分化されることになるので、
それが手間かもしれないし、
関連するものがとっちらかる感じはあると思う。
だけど「こういう型」というよりは「こういう性質」という方がプログラムが分かりやすくない？
既に述べたように拡張が楽というのもある。
ただ、プロトコル指向的デザインでは機能を追加することは出来ても
既に問題が生じているものをスパッと綺麗に解決できるわけではないので、
いつでも元の定義を弄らずに済むほど万能とはさすがに言わないよ。
vector なんてそれこそ達人たちが検証してるだろうから、
私が思いつくようなことが入り込む余地は無いだろうし。
そこらへんは程度問題なので、積極的に (あるいは消極的に)
(テンプレートを用いた) プロトコル指向的デザインを
使うのが割に合わないという場面もそれなりに多くあると思う。
繰返すけど、そこまで万能と思ってるわけじゃない。
>>704 static 宣言する、というのはありな状況ですか？
static MyClass abc;
こいつ金慶珠みたいなやっちゃな・・・・マジめんどくさい
>>711は
>>709宛
>>708 関数の方を変えなくても、渡すとこで
auto a = hoge(*pMyClass);
でいんじゃね？
それも大変なら
>>707みたいにラップするしかないけど
>>710 オブジェクトのサイズが動的に変わるので、難しいです（合ってるかな？）
>>712 > 関数の方を変えなくても、渡すとこで
> auto a = hoge(*pMyClass);
> でいんじゃね？
> それも大変なら
>>707みたいにラップするしかないけど
void hoge(MyClass abc);
なる関数 hoge() に、
MyClass* pabc;
pabc ＝ new MyClass;
hoge(*pabc);
とする、ということですよね？
この方法では、関数呼び出し時にコピーコンストラクタが呼ばれますか？
それとも参照渡しのように、実体(？)が渡されるのでしょうか。
>>713 呼ばれないよ
参照渡しと同じことになる
あ、もちろん関数側の受け取りを参照のままにしてれば、だけどね
>>708 MyClass abc1;
foo(abc1);
MyClass* abc2 = new MyClass;
foo(*abc2);
delete abc2;
>>714-717 すみません。
>>713は間違っていますね。
hoge() の定義は
void hoge(MyClass& abc);
でした。
ありがとうございます。
提案していただいた方法なら、関数側はほぼ何も変えないでできそうです。
初歩的な質問に付き合っていただき感謝します。
ボレロ村上さんや江添さんみたいなプログラマーになりたいんですが、彼等はどうやってC++についてあんなに詳しいのでしょうか？
どっちも早いころからパソコンを触っており、
早期にはこんなに言語がなく血反吐吐いて低級言語を覚える必要が少しあり、今はその応用で食ってける。
C/C++も今ほどライブラリがなく、自作するか引っ張ってくるしかなかったうえにそもそもコード系のシャルネットワークがなかった。
前提として奴らは別にプログラマーとして有名なわけではない。
コードを書く能力と有名なことが反比例しているわけだがそれでもいいなら
彼らの真似事してれば同じようになれるんじゃね？
まぁ、名前を聞くようになったのはツイッターあたりからやね。
江添氏はコードのお作法がおかしいと食いついたりしてたし、委員会に近いところにいたのでそういう情報を発していた。
けど、個人ではあまりコードは書いてないみたいだな。
ボレロ氏は高専言いっててそこらへんで色々学んでconstexprライブラリで名前を売ったってところはある。
その後縮小して最近コードを書いているという話は聞いてないような。
どっちも有名になったのはこの世の不満とオタクの人権みたいなのを発していたら有名になったってところはある。と思ってる。
誰にでもウイークポイントはある
そこを苛める遊びに固執する阿呆は誰からも何も学べないまま
自らがウイークポイントのみからなるコンパクト星として成長するのみ
世の中の誰からも軽蔑しか受けない天涯孤独な存在だ
まぁ江添氏は委員会の人間だしコードあんま書いてなくても日本のC++ユーザーのために
仕様の解説してくれてるしね
ボレロ氏は・・・まぁその・・・・・生産性あるんだか無いんだかよくわからんライブラリ作ってるというか
あれはあれで勉強になるけど・・・・ｗ
ただ初心者が「ああなりたい」ってよく言ってるのは理解に苦しむな
中途半端な知識でドヤ顔するのでなく、真摯に解説するサイトでも作ってくれりゃ価値があるけど
個人的には彼らを崇拝する人を見るたびに、もやもやした気分になる
言語は道具なんだから使ってなんぼやろ・・・
>>725 まあ結局言語は道具といっても、作ったものが革新性があったり、真似できないようなら人気を集めるような気がするんだよね
東方のZUNとか別にそこまで凄いゲームでもないけど、プログラマーとしてそこそこ尊敬されてる
仕事でコード書いてたらc++の最新の仕様を追えないからやらない
とか本気で言ってしまう奴は根本が腐ってると思うよ。
言ってて矛盾を感じないのかと。
目標が名声なのか、C++理解度なのか・・・
粛々とコード書き続けるのが一番
>>728 もちろん理解度なんだけど、何となく日本以外だと彼らしか目標とする人物が見つからなくて
ISO/IEC読んでworking draft読んでおまけにg++/clangの実装で読んで
それでみんが知らなそうな重箱をつつくような仕様拾ってきてブログのネタに
すればいいんでないの？知らんけど
まぁ日本だと、解説サイトで目につく人ってそんなもんか
ZUN氏挙げるのははちょっと不思議だけど・・・
以前東方に使われてる技術の解説がどこかにあったけど、
タスクシステムみたいな古くからある２Dシューティングの常套手段とかしか記憶にない
（なんか驚くようなのもあったかもしれんけど
仕事で書いてると驚くようなコードとか設計をあちこちで見かけるけど、
そういうの書くのはやっぱ誰も知らない無名の職業プログラマだったりするよ
>>731 今もそういう夢いっぱいな話あるの？
昔のファミコンソフトがスーパーテクニックの塊だった、みたいな
最近はリソースが潤沢にあって、手抜きのとりあえず動くプログラムが蔓延しているのだと思ってた
今でもゲーム系はスーパーテクニック満載でしょ
マルチコアCPUを90%以上使い倒す世界だからな、すげーわ
>>732 自分は半端者なんで知識はアレだけど、GTAシリーズとかEAのゲームとか
ああいうのは今でもリソース必死に使い切ってるみたいよ
（Game Programming Gemsとか読んでみたらその片鱗が見える）
スーファミ時代のような変態的なのとは方向性が違ってきてるけど
大規模な開発の上でいかにパフォーマンス損なわずに開発効率を上げるかが重視されてる
もちろん2Dのスマホゲーだったら全然使い切る必要ないだろうけど、そっち方面は詳しくない
（多分言語もC#かSwiftが主流？移植性考えたらC#だろうな
へぇ～～～面白い
「どの業界は超人多い」みたいのあるんだろうか
>>736 さすがにF35のソースは見たことないけど、軍事関係や命に関わるコードはむしろ枯れた技術以外使わないんじゃないかな？
ECUとかはとんでもなく古い考え方(ほぼ全ての変数がグローバル)で作られてるし。
まぁECUの場合それはそれでちゃんと理由があるんだけどね。
多次元配列クラス Tensor があるとして、そのインスタンス a は a[2][5][3] のように要素アクセスできるとします。
unique_ptr<Tensor> pa(new Tensor);
のように Tensor のスマートポインタを作った場合、pa の指してる Tensor への要素アクセスってどうやるのでしょうか。
「Tensor」の設計の詳細が必要であれば、boost の multi_array と同じとしていただいて問題ありません。
>>731 自分は業務でC++使ってないのでそういう経験ができないのです‥
だからこそネットで活動してる人しか分からなくて‥
C++は全て独学するしかなくて、いい方法が無いかずっと考えてるのですが、結局ネットや本を見るしかなかったです
>>739 すみません……
いろんなところにアスタリスクつけたり矢印つけたりしてみたのですが、そのパターンは見落としてました……
>>737 組み込み系のノウハウなんだろうけど、大規模な組み込みってなってくると
一体どんな英知が詰まってるのかなーとか気になって
数百万行とかじゃなかったっけ・・
まぁMISRA-C++嫁、で終わる話かもしれんけどw
>>740 自分も会社入る前とか、辞めて休業中は全部独学よ
C++の知識だけに留まらず、何か作りたいもの作ってれば、
その分野での知識が嫌でもついてくると思う
C++の知識だけに閉じこもって実際の開発(プロじゃなくて個人のフリーソフトでも)と
乖離した方向に行ってしまうのが一番怖い
そういえば以前ここで似たようなこと言ったら
「愚者は経験に学び、賢者は歴史に学ぶ」とか言われたなw
ああいうアホになるんだよ、言語の知識だけに閉じこもって何も開発せずにいると
>>743 ＞MISRA-C++
そんなものがあるのですか？
>>689 >(Java でいうところの) インターフェイスは型の性質を事前に網羅しなきゃ
>全体のデザインが定まらない。
無いメソッドを呼べる言語は存在しないからこれは仕方が無い（ジャバに限らん
ジャバに限らずインターフェースには利用者が絶対呼ぶメソッドだけではなく、
呼ぶかもしれないメソッドも全部packing listに入れねばならない点が無駄が大きい
その代わり、インターフェースのメソッドはビルド単位内で一意な名前（インターフェース名）で
（直接的あるいは間接的に）修飾されるから、同じメソッド名で違う機能のやつがあっても
衝突せず、安全性が保たれる
テンプレートはこの点だけがちょっと劣る
これ以外にテンプレートに欠点など無i
バイナリインターフェースが重要なシステムもあるわけで
C++とシェルスクリプトの違いって何ですか？
シェルスクリプトで出来ることでC++ができないこと
C++が出来てシェルスクリプトで出来ないこととかそういう具体例を教えてほしいです。
>>750 個人的に上げるとしたら、webのフロントエンド分野はインタプリタに勝てないと思います
>>750 C++はコンパイルしないと動かない。シェルスクリプトはファイルの操作やバッチ処理が得意。
>>750 桃白白とラウチェン、マジンガーＺとテコンVぐらい違う。
>>750 GUI使ったアプリはシェルスクリプトでは無理
>>753 確かにファイルの操作はそうですね
>>754 確かにそういう分野はCですね
>>755 例えが古くてパッとしませんでした‥
>>756 確かにOSにインストールするものはそうですね
C++というかオブジェクト指向の質問かもしれないんですけど
エクセルにデータを書き出すためのクラスがありましてメソッドがざっとこんな感じ
・データをファイルから読み込む
・シート作成（ここで以下のメソッドを呼び出す）
・シートAに書き出す
・シートBに書き出す
︙
・シートEに書き出す
全体で1000行ほどなんですけど、例えばシートに書き出す共通部を親クラスにして、
それを継承した各シート毎に書き出すクラスを作るみたいなこと考えてます。
ただ正直あまり意味が無いような気もするんですよ。クラスと言うには小さすぎるものになりそうですし。
何行超えたらでかいだろとか何行なんてクラスとしては小さすぎるだろみたいなラインってありますかね
それは単に
メソッド シート作成（）{
シートAに書き出す
シートBに書き出す
︙
シートEに書き出す
}
ということ？それとも
class A {
メソッド シート作成（）{
シートAに書き出す
}
class B {
メソッド シート作成（）{
シートBに書き出す
}
ということ？
前者ならクラス分ける意味がないと思うが。
クラスは行数じゃなくて意味的にまとまってるかどうかだからな
意味のあるメンバがまとまってれば1万行の単一クラスがあってもいいし
デタラメに寄り集められた50行の粗大ゴミクラスもある
そういうもの
>>758 >何行超えたらでかいだろとか何行なんてクラスとしては小さすぎるだろみたいなラインってありますかね
ないよ
機能で分けれ
>例えばシートに書き出す共通部を親クラスにして、
>それを継承した各シート毎に書き出すクラスを作るみたいなこと考えてます。
「書く内容を決める」機能が「シートに書く」機能を継承するなんてナンセンス
どのシートに書くかなんて「シートに書く」機能に引数で渡せばいいだけ
>>762 あってるよ
50行でも粗大ゴミは作れちゃうんだよ
さすがに一万行でまとまってるクラスってのはないわ。。
もしかして知恵遅れは
なんか書くために毎度毎度ofstreamを継承すんの
もしかして知恵遅れは
なんか読むために毎度毎度ifstreamを継承すんの
さすが
例えば、基本クラスに出力クラスを作って、
派生クラスに、プリンター・PDF など、機能が異なるならオブジェクト指向だけど、
機能が同じなら、派生クラスではない。
単に、属性・メンバ変数が変わるだけ
void aho::write(ostream& aho) const {
aho << "aho" << endl;
aho << "baka" << endl;
aho << "manuke" << endl;
}
こんな感じで作っとけば
いろんなもんに書ける可能性がある
抽象化をうまく利用するというのは
こういうことだからな
江添亮に匿名で質問ができて、高確率で答えが帰ってくる空間ってもうないのでしょうか
本人のtwitterにでも投げれば？
高確率で「質問ではない」が帰ってくるが。
>>750 シェルスクリプトだけではシェルスクリプトを解釈実行することはできない
C++からならできる
つまりシェルスクリプトだけでは金輪際できない仕事というのは少なくとも1つある
もっともこの宇宙自体がシェルスクリプト上で走っているシミュレーションなら話は別やが…
そんな規約あったっけ？
Cling とか CINT はパチモノ？
>>768 そういうのは、templateのほうがいい。ostreamに依存せずにすむ。
俺には誰一人として標準のstreamクラスを継承する話はしてなかったように思えてならないんだが
(最初の
>>758も書き出す処理を継承で共通部分と個別部分に分ける案を問うているだけ)
なんでそういう話になってるんだっけ
>>776 >>758 ＞全体で1000行ほどなんですけど、例えばシートに書き出す共通部を親クラスにして、
＞それを継承した各シート毎に書き出すクラスを作るみたいなこと考えてます。
書き出す共通部をまとめたクラスというのは
ファイルで言えば ofstream みたいなものなのであろうと皆疑ってるんだろう。
「みたいなものではない」という、結論が違ってくるような違いも提示されないし。
>>777 そうなのか……ありがとう
俺はostreamを引数に取る関数オブジェクトを多態やprotectedを使って実装するみたいなイメージで読んでた
最初にクラスを設計し始めるのは筋が悪いと思ってる。そんな3流プログラマ。
訂正；
△：シェルスクリプトだけではシェルスクリプトを解釈実行することはできない
○：シェルスクリプトがあるだけではシェルスクリプトの解釈実行を開始することはできない
シェルスクリプトはもちろんシェルスクリプトから呼ばれるシステムコールその他の
一切合財をシェルスクリプト上だけでシミュレートする能力がある（と思う）が
全ての始まりを起こすのにC/C++で書かれたOSを要する
>>780 つまりクラスの設計はおくらすのが正しい
最新のC++コンパイラが使えないので質問。
右辺値参照が仮引数になっている以下のような関数があった場合、
aaa(左辺値の変数);
とすると、ちゃんと、aaa() は呼び出される？
それともエラーになる？
void aaa(T&& a)
{
・・・
}
>>783 呼び出される。
lvalue は rvalue にもなる。
では、aaa()に次のようなoverloadがある場合は、「2」の方が呼び出されて、
#if の部分を 0 にすると、「1」が呼び出される？
だとすると、昔のC++では無かったような overloadの仕様かも？
T b;
aaa(b); // bは左辺値のつもり
void aaa(T&& a)
{
puts("1, 右辺値参照、T&& に来たよ。");
}
#if 1
void aaa(T& a)
{
puts("2, 左辺値参照、T& に来たよ。");
}
#endif
>>783 呼び出されない
右辺値参照は左辺値を受け取らない（原則）
ただしTがテンプレート仮引数の場合と、auto&&の場合は、
右辺値参照で左辺値を受け取れる（特例）
型を推定させた場合に限り、右辺値参照は、
左辺値参照への左辺値参照に変形できる
[Compile and Execute C++11 Online (GNU GCC v7.1.1)]
https://www.tutorialspoint.com/compile_cpp11_online.php
で下の方のコードを試したら、
$g++ -std=c++11 -o main *.cpp
main.cpp: In function ‘int main()’:
main.cpp:18:10: error: cannot bind rvalue reference of type ‘TPerson&&’ to lvalue of type ‘TPerson’
aaa(b); // bは左辺値のつもり
^
main.cpp:8:6: note: initializing argument 1 of ‘void aaa(TPerson&&)’
void aaa(TPerson && a)
^~~
というエラーになった。gcc 7.1.1 では、>>785 の言ってくれたことと合ってない？？？ >>790
[続き]
#include <stdio.h>
struct TPerson {
int m_age;
};
void aaa(TPerson && a)
{
puts("1, 右辺値参照、T&& に来たよ。");
}
int main()
{
printf("Hello, World!\n");
TPerson b;
aaa(b); // bは左辺値のつもり
return 0;
} あれ？ ごめん。
確かめたら呼び出されなかった。
勘違いしてたかも
あ、逆の場合と混同してた。
const T& に rvalue がマッチするんだった。
このあたりのルール、なんか一貫性がない感じがする。
>>792
でも、以下の std::move() の実装の説明だとあなたの言ってる方が正しい気がする。
https://stackoverflow.com/questions/36206764/understanding-the-code-for-stdmove
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2006/n2027.html#Move_Semantics
The move function really does very little work. All move does is accept
either an lvalue or rvalue argument, and return it as an rvalue
without triggering a copy construction:
template <class T>
typename remove_reference<T>::type &&move(T &&a)
{
return a;
}
It is now up to client code to overload key functions on whether
their argument is an lvalue or rvalue (e.g. copy constructor and
assignment operator). When the argument is an lvalue,
the argument must be copied from.
When it is an rvalue, it can safely be moved from. >>789 なるほど、std::move() は、あなたの言ってくれた、template の場合に当たるから
こその動作だったんだ・・・。
>>793 template の場合と、auto の場合は、まさに、一貫性が無いということらしい。
こういう一貫性の無さのことを「直交性が低い」と言って、言語が分かりにくい
指標になるらしい。
>>796 一貫性は無いけど、仮引数の rvalue reference に lvalue がマッチ「してほしくない」というのはわかるので、
まあしょうがない。
>>789 ちょっと確認なんだけど、
テンプレート仮引数 T に対して T&& に lvalue がマッチするっていうのは、
実際には lvalue reference として機能するという意味でいいんよね？
(変形できるというのはそういう意味だよね？)
>>799 「変形される」だったら勝手にやってくれるんだなーと思うんだけど、
「変形できる」という言い回しにちょっと引っかかりを感じたというふんわりした疑問なので、
具体的に別の可能性を思い浮かべたわけではないです。
江添で言えばまさにわかりやすくその辺の事情解説してくれてるだろ
今の話で江添より詳しいとかありえねー
>>802 江添氏は C++ を使うプログラマというよりは、
C++ の規格の専門家として C++ の知識を持ってるんだから、
かなり詳しいよ。
>>805 いずれにせよ、気持ちはうれしかったよ。
>>804 そのへんの事情って？
>>805 それは本人も自負してるようだけど
もし非テンプレート関数かつ非インライン関数なvoid bar(Foo&& a)に左辺値xを渡してビルドが通る言語規格だとしたら、
tmp = xのコピー
barのビルド結果←(tmpのアドレス)
ということになってxのコピコンが呼ばれてしまうま
つまり右辺値参照がコピコン削減になるかどうかというのは関数を右辺値参照にしただけでは決まらず、
呼び出し元の条件次第なので、bar()を作る人/使う人双方の慢心を避けるためにエラーにするんだろＪＫ
一方テンプレート関数またはインライン展開される関数なら、上のようなへタレコードに一時的になっても
すぐさまコピコン削減ができるから実質弊害が無い
ただし、そういった関数でも再帰呼び出ししたりアドレスをとったりすると上と同じ議論になるので、
再帰呼び出し/アドレスを取る操作 両方ともありえるインライン関数は
>>789の例外の適用外とされ、
テンプレート関数は再帰呼び出しが有り得ないし、アドレスを取る奇特な人間も居ないだろうということで
>>789の例外が設けられた
訂正；
△： すぐさまコピコン削減ができる
○： コンパイラがすぐさまコピコン呼び出し削減最適化をかけられる
コピコン呼び出し削減最適化はこの場合データフロー解析の結果を流用したらできる
C++はgotoが使われたとき、コンストラクタが呼ばれずに使われるオブジェクトが生じないか否か確かめるために
データフロー解析はもともと必須なので、コピコン呼び出し削減最適化はC++コンパイラ書きなら誰でも出来る（多分
>>793 >const T& に rvalue がマッチするんだった。
それはある意味当然すぐる
const T& x = r; // rは右辺値
...
y = x // (*)
としたときに、コンパイラは(*)みたいな文が現れるまでは、
xへのアクセスを機械的にrへのアクセスに置き換えれば良いわけでゼロコスト
rが所有権を失ったらxのアクセスも不正となるが、これは書き換え可能なオブジェクトを
const参照をとってから書き換えた場合も似たようなもの（身からでたサビ
なのでコンパイラはやっぱ何もしなくて良い
（30分前にこのスレを読んで初めて右辺値とか右辺値参照といったﾌﾞﾂを知った初心者なので語ってみた
>>811 y = x
の後もxへのアクセスはrへのアクセスで良くないの？
>>813 >>814 ﾎﾝﾏや！(；ﾟДﾟ)天才か！
>>809 再帰だろうがアドレスとろうがオンラインだろうが例外は適用されるだろ。
やっぱ30分で理解するのは無理じゃね？
auto a = funcA(funcB(funcC(input)));
みたいな感じの関数の入れ子ってさ、ある関数が終わる度にその都度インスタンスを作ってコピーして次の関数に渡すということを繰り返すんだよね？
つまり、関数たちの返り値が巨大なオブジェクトだったら、このように書くことで余計に時間がかかるよね？
>>818 いんや。
オブジェクトにムーブコンストラクタがあって戻り値が右辺値ならコピー回避されるし、戻り値最適化で一切何も起こらない可能性すらある。
て、はちみつが言ってた。
>>819 へぇ
> 一切何も起こらない
というのは、一切余計なオーバーヘッドがない、ということですか？
単純なコピーよりは早くなる可能性があるってだけでは？
ちょっと誇張しすぎた。
正しくは「コピーもムーブも起らない可能性すらある」
コピーもムーブも起こらなければ、その分のオーバーヘッドは当然ないよ
へぇ～～～
ありがとうございます
まぁそこがボトルネックじゃない限り余計なこと考えない方が身のためなのかもしれませんが
>>818-823 コピーもムーブも省略される可能性ってのは、左辺の場所でオブジェクトを直接に構築するっていう意味。
構築してからそのままコピーしてる (そして元のオブジェクトが一時的である) 場合は実際には直接構築したって同じよねという話。
>>819 ＞オブジェクトにムーブコンストラクタがあって戻り値が右辺値ならコピー回避されるし
なんかムーブコンストラクタを魔法か何かと勘違いしてないか？
ムーブコンストラクタの方が重い処理してたら当然重くなるんだぞ
>>825 ええ…
コピーより重いムーブコンストラクタの存在を前提に話す必要ある？
むしろムーブで軽くなるのは大抵の場合ムーブによってヒープの確保、解放を
避けられるクラスだけ、だろ
ある意味そっちの方が限定して話をしてると思うが
基本をすっ飛ばすからはちみつその他誤解するやつが出てくる
この機能が必要になった背景・経緯
ムーブセマンティクスは、C++03でもNRVO（特定の文脈でのコンストラクタの省略）や、 C++11で非推奨となったstd::auto_ptrで実現されていた。
しかし、NRVOがいつでも機能するわけではなかった。
また、std::auto_ptrにはコピーと同じ文法でムーブしていることなど、問題が多かった。
そのため、コピーと区別でき、統一的にムーブを表す文法が言語機能として必要とされた。
つまりこんなあぶなっかしい
unique_ptr、shared_ptr、weak_ptrとか使ってるﾔﾂﾗも
ｸﾙｸﾙﾊﾟｰしかいない
この程度の簡単な制御も自分で簡単に制御しきれないﾜｹだからな
しかしｱﾎのあたらしもの好きは半端ない
頭悪いｼﾛﾓﾉでも新しいものができたら使わないといけない病になってるからな
ｼﾛｳﾄに多い
いや、autoはともかくshared, unique, weakは危なっかしくないと思うが・・
ムーブが使えるようになってからだし
あと個人的にはcpprefjpは規格寄り過ぎてユーザー寄りじゃないと思う
cppreference.comを使うべき
で、こんなしょうもないことより
ﾎﾝﾄに理解しないといけない部分がすっぽりと抜けてる
C++ の (というかプログラミング言語の) ほとんどの機能は抽象化の道具。
ムーブもまた、見かけ上は代入っぽい抽象で扱えるものであっても
実態はもうちょっと速いコードにも出来る (可能性がある)。
>>828 そういう簡単な制御すら抽象化層に押し込められない方がよっぽど駄目。
クルクルパーだと思ってるならなおさら、
簡単な制御なら (いつも間違いなく) 出来ると期待すべきでない。
そんでもって大抵の人間はクソザコで、しょうもない間違いをする。
問題は道具で解決すべき。
>>832 >問題は道具で解決すべき。
ネ申は確かＬＬ言語を創造された
ムーブはゼロの発見に次ぐ、人類史上における大発見と言われてるけどな。
ノーベル賞候補の一つにもなってるし。
std::auto_ptr<T>はもともとオブジェクトをムーブしたくて生まれたわけでは無いと思う…
確実な解放の実現が先
ムーブする仕様はあと
あとstd::auto_ptr<T>（unique_ptr<T>でも良いが）でも使わないとやってられないｼﾁｭがC++には少なくとも1つある
move元のオブジェクトに対するアクセスがコンパイルエラーになるんならわかるけど、そうじゃないんなら
大層な仕組みを入れなくても単に unique_ptr を言語組み込みで実装すれば済む話だったのでは？
>>837 それ何が嬉しいんだ？
vector とかどうすんだよ
>>840 moveするのが分かってるんなら最初からvectorごとヒープに作って unique_ptr で持てばいいでしょ
中途半端にガワだけスタックに置く意味がない
move後の元オブジェクトを破壊っていうか破棄しようって提案もあったよ。ちょっと早くなるのだとさ。
>>841 ポインターならそもそも copy のコスト安いから move 要らないじゃん
この3冊が、神の書！
Linux プログラミング・インタフェース、Michael Kerrisk、2012
C++11/14 コア言語、江添 亮、2015
組込み開発者におくるMISRA‐C:2004―C言語利用の高信頼化ガイド、MISRA‐C研究会、2006
>>843 だからmoveいらないって話でしょ
C++のムーブセマンティクスがああなったのは中途半端にスタックを使うスタイルが定着してしまっていて今更ポインタ使えというのは無理があるからで、
本来は所有権の管理さえ適切に行えるようになってさえいればムーブなんか要らんよ
C++ Coding Standards って新品で買えないけど代わりになる書籍ありますか？
>>846
ポインタ使え思想はすでにC#とかなクラスが参照型な言語で実現されているが
オブジェクトの解放にガベージコレクタが要る言語になった
これはガベージコレクタ無し・所有権の無条件移動だけだと、次のようなケースで早速話が破綻するから仕方が無い
void bar(int n) {
std::unique_ptr<Foo> a(new Foo());
for (int i = 0; i < n; i++) {
func1(a, i); // func1(a, 0);で所有権がgone 以降のfunc(a, i)はaの不正アクセス
}
}
不正アクセスにならないように、実際にはこのようなfunc1()にはa.get()でポインタを渡す書き方をする
するとfunc1()以下の呼び出しは全部>>844になる
人類に逃げ場は無い それにポインタ使え思想だと次のようなケースでBaz::m_c[i]のBar:m_b[j]の:Foo::m_aのアクセスに藻前らどんだけ間接参照するんですかと、
class Foo {
SomeClass m_a;
};
class Bar {
Foo m_b[100];
};
class Baz {
Bar m_c[100];
};
ちな
>>849はm_bやm_cが配列であるため、配列アクセス時の添え字が定数なｼﾁｭでもない限り、JITでも間接参照回数を3以下にはできん
>>848 よくわからんな
848の問題はそれmoveでも一緒だよね
単にデフォルトの挙動がmoveかborrowかだけの話で、unique_ptrがたまたま前者なだけ
スマポ使えば間接参照はどうしても増えるけど、実際
>>849のようなケースで特定の要素だけ所有権捨てたりしないでしょ
所有権を移動するかどうかはほぼ例外なくオブジェクト生成時点で予め分かってるんだから、その場合に限ってスマポを使えばよい
コーナーケースのために全てを複雑にする必要はない
>>851 >所有権を移動するかどうかはほぼ例外なくオブジェクト生成時点で予め分かってるんだから、
有り得ない仮定すぐる…
>>848なケースにおいて、オブジェクトaの生成時点というのは、
ライブラリー制作者がfunc1()を設計してビルドまで完了した後やがな…
>>852 自分でも分かってて揚げ足取ろうとしてるんだろうけど、コーディング時に、プログラマがオブジェクトを生成することを意図したコードを記述した時点で、な
>>853 いやｽﾏﾝ言い方がまずかったそういう意味ではない
確かに
>所有権を移動するかどうかはほぼ例外なくオブジェクト生成時点で予め分かってるんだから、
というのは真だが、ライブラリのインターフェースに解放が必要なオブジェクトのmoveなど認めたら有り得ないコストが生じるという話
func1()の制作者が所有権を寄越すことを強制した（そういうインターフェース仕様にしてしまった）場合、
func1()を使う人はfunc1()に所有権を渡さねばならない。この結果、
1. 呼び出し元（func1()を使う人）がaをコピーしてコピーをfunc1()に渡さねばならない
2. func1()は呼び出しの度に、aを解放する
というのが
>>848のコードでn回無駄に繰り返される
これを避ける方法はあるっていやーあるが、結局func1()以下の呼び出しは全部
>>844になる（か、ガベージコレクタの出番となる
人類に逃げ場は無い
>>854 だからそれmoveでも同じことだよね？
ユニバーサル参照のことを言ってるんだとしたら、あれただの型推論だぞ
>>855 解放が不要なオブジェクトのmoveは話がちげう
この場合、単に生ポインタ（オブジェクトのアドレス）をfunc1()に渡すのと変わらん
これはライブラリのインターフェースに現れてもコスト的には問題は無い
元レスのアンカー先
>>846は
>>854のコストが避けられない主張
いやすまん解放が不要なオブジェクトでも、所有権を移動した場合は
>>854の1のコストは避けられないorz
ここは訂正
>>856 スマポのmoveも本体のmoveも一段間接参照が入る以外は何も変わらないって言ってるんだけど、そんなに難しい話かなあ
>>858 >>848、
>>849は、現行C++におけるスマポのmoveと本体のmoveの優劣は問題にしていない
848を現行C++のコード風に書いたから誤解を招いたのかもしれないが、比較はあくまで現行C++と846思想の比較であって、
846の次の思想を実行に移したら
>>854のコストが避けられませんよという話
1. スタックを使うスタイルはやめるべき（全部スマポであるべき）
2. 所有権の管理さえ適切に行えるようになってさえいれば（現行C++のムーブセマンティクスみたいな）ムーブなんか要らん
1は現行C++との比較において、間接参照回数に響く
2は現行C++との比較において、現行C++では避けられるコスト（
>>854またはガベージコレクション）を無駄に背負い込むことになる
>>858 本体のムーブも、ムーブ出来るように書いたらカスタムなスマートポインタみたいになるから、
間接参照が入っちゃうので、なおさら同じではあると思う。
でもまあ、ムーブは抽象化の方法であって、
最終的に実行されることが同じだからなくても良いってのは暴論よね。
アンダースコアとドットをこの順で必ず含む string があったとして、アンダースコアからドットまでの部分文字列を切り出す処理って一行で書ける？
substr と find_first_of と find_last_of を組み合わせる方法を考えたんだが、
アンダースコアの前を削る;
ドットの後を削る;
という2行に渡るやり方しか思い付かない
ちな
>スマポのmoveも本体のmoveも一段間接参照が入る以外は何も変わらないって
これは現行C++においても違う違いがﾜｶﾙ男ならﾜｶﾙ
func1()からfunc2()にfunc1()の自動変数aをmoveするとして、かつfunc2()はインライン展開されるとすると、
func2()におけるaのメンバへのアクセスはfunc1()呼び出し時点でのスタックポインタ相対で一発でやれる
一方、aがスマポだったりすると、aのメンバへのアクセスの前に、func1()呼び出しの都度1回はスタックポインタ相対でaのアドレスを得なければならない
オブジェクト本体のメモリのコピーにかかるコストを考慮すればどっちもどっち
>>861 substr じゃなくて、コンストラクタ使えばいいんじゃね
string t(s.begin() + s.find_first_of('_') + 1, s.begin() + s.find_last_of('.'));
>>864 ふと気になったのですが、このコンストラクタの挙動って他の名前の関数で実装されてないんでしょうか？
「rustにもあるし俺らも入れなきゃ」くらいの感覚で
今までのシステムとの統合性の難しさなんかほぼ考えないで入れちゃった機能だから。
c++らしいといえばらしい感覚だけど。
std::basic_string::find()もイテレータを返すように他のコレクションとの統合性を尊重して欲しいよな
findを実行した対象とは別のstringの同じ位置に何かしたいとき
イテレータで返されるとちょっとだけ面倒
まあ大した問題でもないんだけど
moveセマンテックが必要になった理由を理解してないのが多くて驚くばかりだな
破壊して良い中間オブジェクトとそうじゃないのとを区別するために必要なのだよ
ポインタ使えばmove必要ないとかそういう問題じゃない
元はといえば禿が左辺値参照でもconstつければ右辺値を指せるという曲がった話を始めたのが
評判悪くてC++11でやっとやっとやっとやっとメスが入ったのが本当の理由
>>872 色んな話題が出てるので混乱してるが、ムーブ不要論を出してる側の *元々の* 主張は
>>846 の通り
「ちゃんとした所有権の管理 (たぶん Rust みたいなやつのこと？) が有りさえすれば」
であって、でもそれは C++ ではもはや無理でしょということもわかった上だと思う。
Cにも欲しいわ
Cは参照ないから右辺値指示ポインタで
それを言うなら、右辺値の概念を撤廃すべきでしょ
どんな値もポインタで指すことができ、
ポインタで指すことでregister指定を解除されるという変更
テンポラリーオブジェクトなくすと、一回必ず厳密に生成してから仕様になるので、手間増えると思う。
右辺値がないと int i = 0; すら書けなくなるんだが
なんで？
int j;
j ^= j;
int i = j;
左辺値でも問題ないじゃん
> j ^= j;
はい未初期化値を使ったから未定義動作で鼻から悪魔
char buf[1];
int i = (int)(buf[10] - buf[0]);
で、i = 10 に初期化される。
NaNのときはxorは未定義か、そこまで考えなかったな
>>883 間違った。正しくは：
char buf[1];
int i = (int)(&buf[10] - &buf[0]); // i = 10 と等価。
そもそも=の無理やりなオーバーロードや引数に対する暗黙的なattainが問題なんだろう。
しかし元々のcのシンタックスを引き継ぎつつ、上記の問題を解決するのは不可能。
>>885 10
0
&buf[10]
&buf[0]
&buf[10] - &buf[0]
(int)(&buf[10] - &buf[0])
右辺値だらけ
やりなおし
>>881 別に？
int *j;
j = &10;
int i = *j;
てだけじゃん
10が左辺値だったらって話ね
char *j;
j = "\n";
int i = *j;
て話と何か違うの？
>>889 全然かまわん
int a = 10;
int b = 10;
a = 42;
こう言っているに過ぎない
>>878 そろそろ答えてもらおうか
なぜ右辺値がないと int i = 0; が書けないのか
>>874 ていうか所有権などという中途半端な概念にオブジェクトの解放を担わせるのは危険か無意味かのどっちかにしかならない
最後までオブジェクトを使いたい人と、そのオブジェクトを所有する人を
コードに所有権を明示するスタイルで一致させられるケースは少ない
希ガス
しかしながら右辺値参照を使うとコードを書く人がオブジェクトの所有権を意識せざるを得ない
これを抽象化といわれるとかなり違和感
※ 個人の感想です
結局ネストしたオブジェクトってのはどう扱おうと楽な扱いなんてできんってことなんだわ。
同期と効率と安全性を全て容易にするってのは不可能なんじゃないかね。
>>895 >結局ネストしたオブジェクトってのはどう扱おうと楽な扱いなんてできんってことなんだわ。
いや？
オブジェクトの所有権は最初のcallerががっちり掴んでオブジェクトを使うcallee以下は生ポでおk
全てが調和する
ｱﾎどもはやっと気付いたか。。。
ｺﾀｴ：最初から普通にﾎﾟｲﾝﾀで書きなさい
unique_ptr、shared_ptr、weak_ptrなんか使ってるﾔﾂﾗは
ｸﾙｸﾙﾊﾟｰしかいない
>>894 右辺値参照周りを抽象化とか言ってるアホははちみつだけだろ
https://ideone.com/BBhHn8 上のコードで教えて欲しい。
templateでデフォルト引数で関数を指定する場合、わざわざテンプレートパラメーターFuncにdecltype(...)しなきゃいけないのは何故？
>>894 ムーブだのなんだの言ってても、
C++ の言語機能として直接的に有るのは rvalue 参照を区別して受け取れるってだけで、
所有権の管理をキッチリやってくれるわけではない C++ の限界なんだよね。
だけど、なるべくクラス・関数の実装の中に区別を押し込めて隠す道具のひとつにはなるって話。
でも、中途半端にやるなら隠さないで見せた方がマシという論はわかる。
受取る関数の側を上手く作っておけば
それを使う側では所有権の移動とかそんなに気にしなくない？
rvalue だったら勝手にちょっと効率的になる (こともある) ねってだけで。
使うときに気にしなくて良いように押し込められるならやっぱり抽象化の道具って言えると思うよ。
>>900 ありがとう。
template<typename Func = int (int)>
を
template<typename Func>
にするとエラーになるのは何故？
>>903 デフォルト引数からはテンプレート引数を推定できない制限がある。
>>902 いや呼び出す側に意識させるのが右辺値参照の目的だろ
意識しなくていいようなケースならconst参照で十分
冗談は顔だけにしろよ
たとえばstd::threadの右辺値参照なんぞ意識してるか？
割と昔からあるプログラムを見てるんですけど一つのメソッド内で
for(int i = 0; ……）{……}
for(i = 0;……）{……}
って書き方してるのをちらほら見ます
要は宣言してるんだから使い回せるだろみたいな理屈なんでしょうがビルドしようとすると当然未定義だとエラーが出ます
昔のC++だとこれがオッケーだったりしたんでしょうか？
rogueとか作って見てはどうよ
SetConsoleCursorPositionとGetKeyStateがあれば何とかなるだろ
>>911 むしろ古い仕様だと後者の i を宣言しようとすると、
ひとつのスコープ内で同じ名前の変数を定義しようとした扱いになってエラーになったりした。
今のコンパイラでも当時の仕様に合わせるオプションはある
C++.でバッチ処理やbashのsedの様な機能はありますか？
システムコマンドを実行したいのならsystem関数
正規表現ならstd::regexクラス
ファイル名に関する様々なことはstd::filesystem::pathクラス
std::array を自作関数の引数に渡したいときって、サイズはハードコードしないとダメなの？
>>921 template <size_t t_n>
void my_func(std::array<data_t, t_n>& a)
{
...
}
>>912 >>915 ありがとうございました。やっぱそうだったんですね
しかし検索しても全然出てこないというかどう検索したら良いものか。C++98とかの時代になるんですかねぇ
>>925 たぶんそれより更に前の話だったと思う。
「c++ for文 宣言 スコープ」でググったらこういうのとかヒットした。
http://www.ksky.ne.jp/~seahorse/cpp/loopvar.html
D&E でも言及があって、 if 文でのルールと合わせる形で修正したという話が載ってる。
ARM (The Annotated C++ Reference Manual;
http://amzn.asia/d/53K2HrA ) を確認してみたら、
「初期設定文が宣言ならば、宣言された変数のスコープは for 文を囲むブロックの終わりまでである」
というような記述がある。 (要するに古い仕様)
このあたりから C++98 になるまでの間に修正したってことなんじゃないかと。
>>926 キーワードと完全に同じ綴りのマクロがあると
標準ヘッダが動作保証外になる
ISO/IEC9899:2011 7.1.2 Standard headers の段落4
>>925 最初期の処理系、AT&T cfront の頃からの仕様だから 1980年台だと思う
ちなみに有名な Annotated C++ Reference Manual (ARM) は
この cfront のリファレンスマニュアルに注を付けたもの。
Mac II が出た頃の Mac のソフト開発者は Apple の MPW という開発環境の上で
AT&T のリファレンスマニュアル見ながら cfront で開発していた。
>>925 ＞しかし検索しても全然出てこないというかどう検索したら良いものか。
当時まだ処理系と独立して言語仕様を策定/記述したものは存在していなくて、
上記の cfront のリファレンスマニュアルと cfront の実際の動作が c++ の仕様でした。
>>929 そんなもん古い環境で使うなら標準ヘッダのインクルード後に定義するに決まってるだろ
現行の標準に合わせたいけど仕方なく古い環境でも動くようにしたい場合のテクニックなんだから
>>932 俺だったらこう書くぜ
{ for(int i = 0; i < 1; i++) ; }
{ for(int i = 0; i < 1; i++) ; }
前提にしている環境を誤解させかねない変態コードには反対だ
ヘタレな俺は c 同様直近のブロックの頭で宣言してました
>>934 今では C でもブロックの頭という縛りは無いやで。
std::array ってコンパイル時にサイズが決まっていることを想定して作られてるんだよね？
だったら、「可変長ではないがサイズは実行時に決まる」というメモリが連続な配列がほしいなら生配列を使え、というのが C++ を作った人の気持ちなの？
>>936 いや、昔はイニシャライザーリストがなかったので、初期化式が使えるオブジェクトの立ち位置だった。
イニシャライザーリストが入ったのでほぼ産廃。constexprの対応もなく死んでいる。
基本的に配列っぽいものがほしかったらベクター使ってっていう趣旨だったと思う。
>>937-938 vector ってメモリ空間連続ですか？
だったら迷わずこれ使うんですが
>>939 &V[0]すると一本のメモリの先頭が取れると規格書に書いてあると聞いた。
これは、サイズを拡張するなどのメモリ変更があるまで同じものを指してると思う。
C++11からvectorのメモリ空間は連続でなければならないと規格で決められた
安心していいよ
>>940-942 ありがとうございます
しかしメモリが連続じゃないといけない外部ライブラリに vector 渡すの結構緊張しますね
少し飛躍するのですが、vector の入れ子は流石に連続とは限りませんよね？
メモリ連続させたいならvectorの入れ子はよして。
最初arrayで考えてたなら画像とか行列とかそんな感じかな？
>>942 太古から実際には連続だし規格として明記されたのは C++03 から。
C++11 で連続と規格化されたのは string (basic_string) の方。
>>944 いえ、もともとは生の一次元配列を使ってて、array の方が取り回しが良いのかなと考えただけです
実際は vector が最強ということですね
入れ子云々は本当に気になっただけです
多次元配列は、色々諦めて Boost を使っています
変数名とかクラス名にめちゃくちゃ毎回悩む
従業員の名前、社員番号、階級みたいなクラスを作るときのクラス名とかって普段どうしてる？
Employeeだけで良いのだろうか
DataとかInfoとか意味のあるようでないような命名が頭をよぎってしまう
仮に従業員をEmployeeとしたときに会社名と従業員リストのDictionary<string, List<Employee>>の変数名とかどうすりゃええねんってなる
CompanyではないしCompanyDataだとそれっぽいが的確でもなさそうだし...
emproyees でいいだろ
for (consy auto& emproyee : emproyees["Microsoft"]) ...
MapCompanyNameToEmployees
>>939 vector が連続と明記されたのは C++03 だが、
C++ 標準の体制としては仕様の「欠陥」と認められた項目については過去の版にさかのぼって適用されることがあり、
vector が連続であるというのもそのひとつのはず。
つまり、 C++98 を名乗る処理系でも vector は連続であるべきで、実際にほとんどそうなっていると思う。
英語の複数形は便利すぐる
emproyee_list[]の代わりにemproyees[]で済む
大文字小文字でキャメルケースも使えるしほんと出来過ぎ
単独かコンテナで意味が大きくかわるのに
字面の違いがsのありなしは微妙すぎていまいちだと思ってる
しかしそこまでメモリに直触りするならvectorでない方がいい気がするんだが。
>>956-957 サイズの取得とかオシャレにできないじゃん
>>960 もし、今後絶対、employee の情報しか入れないと言い切れるのなら、
g_dictCompanyEmploees
でもいい。何か追加する予定なら、
>>960 のように「g_dictCompanyInfo」
>>947 最初の従業員のデータについては、
EmployeeInfo
二番目の dictionary の方は、
g_dictCompanyEmploeeInfo_s
型付けるハンガリアンは糞だけど、グローバル変数にg_付けるのは普通でしょ
付けないの？
グローバル変数使わないしg_つけてもなんの役にも立たないし
スコープを示すハンガリアンは変数のスコープを不必要に広げることに対する心理的抵抗を低減するという点で害悪
あの複雑怪奇な名前解決ルールを受け入れているC++使いからしてみれば、変数が
ローカルかグローバルかなんてわざわざ目印付けるほどのことじゃないのかも
パブロフの犬ｶﾖ
グローバル変数の先頭に「g_」を付け続けると
そのうち先頭に「g_」とつけただけで
しかしいかにクラスFooに関連するオブジェクトは全部Fooのコンストラクタかsetterで渡すか一時オブジェク
トとしてメソッドの引数として都度渡すのがオブジェクト指向設計としての理想とはいえ実際には対数表のカ
スタマイズ版みたいにかなり普遍的な意味を持つテーブルＴが存在する前提でいっぱいクラスを定義したい
ときもあるわけでそういうときはテーブルTをグローバル変数とした方がスマートに書けるTがこの世に1つし
かないのにいちいちインスタンス毎にTへのポインタを持たせるのですかみたいな、
で、そうするとグローバルであることの目立つ標識が欲しいところだがオリジナルの規則を考えるのもアホら
しいので使用人口が多そうな「g_」を使う
６０億人がシステムハンガリアンの良さを発見できなかった
そういうことだ
せっかく自動化したものを蒸し返す愚行
機械に使われる人間に自ら志願するようなことでしかない
ハンガリアン記法が滅亡した時にgとかsとかのスコーププレフィックスも一緒に絶滅したと思うの。
もうそういうのは見飽きたからハンガリアン無差別否定派とアプリケーションハンガリアン推進派が頃しあって消滅してくれたらいいのに…
「ハンガリアン記法を使うと、コードの断片からでも何かを発見できる。」
C#では、メンバ変数 aaa をアクセスする時には、必ず、
「this.aaa」
とするらしい。これは、C++で、ハンガリアン記法を使った場合の、
「m_aaa」
に該当する。this. と m_ では、後者のほうが短く便利。
m_ も、this. も付けない場合、たとえば、コンストラクタで
同じ意味の仮引数を使いたい場合に、何らかの別の名前を
考えなければならなくなる。
サイズ変更してキャパシティ変更になったらデリートかかる可能性が高いのでそういうことを一応管理しないといけない。
>C#では、メンバ変数 aaa をアクセスする時には、必ず、
>「this.aaa」
>とするらしい。
mjd？
いつから？次の元号から？？
一般的に言われているシステムハンガリアンのデメリットはg、s、mには当てはまらない。
iとかdwとかlpszみたいな糞接頭辞とは分けて考えたほうがいいと思うよ。
個人的には、以下のような命名規則は大いに役立っており、
コード全体を見ずにコードの断片を見るだけで、何も考えずに
コーディングが出来ることが多くなる。おかげでずいぶん楽になった。
char *pszText;
char szText[256];
CString strText;
char **ppszText;
「sz」は、0終端文字列。s = string、z = zero。
p は、ポインタ、str は、CString。
pp は、ポインタへのポインタ。
m_がついててもそれがメンバである保証が何もないからなあ。無駄なだけ
>>980 個人的には、i や dw は滅多に使わない。
lpszは、自分では使わない。pszは使う。
なぜなら、lpsz の「l」 は、16BIT時代から32BIT 時代へ移行したときの産物だから、
今は時代遅れなので。
ところで、dwRead と書くと、宣言を見返さなくても、読み込みバイト数を表す DWORD 値だと
分かって便利。dwWrite だと、その書き込み版となる。変数名が規則変化するのでとっても便利。
たとえば、「text」という変数名だと、CString 型なのか、0終端文字列なのか、
0終端が付いてないような特殊な文字列なのかが分からない。
ところが、ハンガリアン記法を使うとそれらが明確に区別できる。
0終端文字列を配列で持っているのか、それとも、そのアドレスをポインタで
持っているのかも、sz か、psz かで区別できる。
このことはバグの少ないコーディングにとても役立つ、。
頭を使わなくても機械的にコーディングできてしまうことが多くなるから。
命名のプレフィックスに関する個人的な熱い想いはカプセルの内側に隠蔽すると良い
そういう意味で「m_」は比較的どうでも良い
>>982 それを言うならあらゆるシンボル名が正しくそれを示している保証なんてないと思うよ。
>>983 そういうのはoopやtmpと相性が悪いんで…
そうだよ。だから最低限にしないといけない
無駄なものをつけるのはいらんバグを増やすだけで悪
個人的にはCのライブラリ関数名に「g_」がついていないのを遺憾に思う
今時ハンガリアン使うアホがいたとは驚きなんだがw
もう絶滅したと思ってた
>>985 >そういうのはoopやtmpと相性が悪いんで…
どういう意味？
OOP == オブジェクト指向プログラミング
TMP == テンプレート/temporary
いかにハンガリアン否定派といえども
いざ実際ハンガリアンで書かれた変数名を見たら体が反応してしまうということなんだろＪＫ
鍛錬が足りん
ずっと前に、ハンガリアン記法で書かれた比較的大きなソース・コードを見て
とても分かりやすかったので自分もそれに習っただけなんだよね。
実際みんなが叩いてるから叩いてるってやつはいるだろうな
俺も別に悪くはないと思うよ
自分から進んで使おうとは思わないが
型が殖える度に変数名のプレフィックスがどんどんどん殖えていくなんてコーダー側からしたら不毛なだけ
いざ型名変えたいと思っても後ろを振り向くのが怖くなる
でも、BOOL 値の変数の先頭に b を付けたりすると、ミスを発見するのに大いに役立つ
事があるよ。
読む側にとってはな
書く側は細心の注意を払わないといけない
簡単に後戻りできないからな
メンテ効率最悪なんだよ
ハンガリアンは、集団にその命名方法が周知されていないといけないので、周知するところから始めないといけない。
周知できればコスト低減できるが、それまでのコストをどうみつもる？
lud20241210003328caこのスレへの固定リンク： http://5chb.net/r/tech/1535353320/
ヒント：5chスレのurlに http://xxxx.5chb.net/xxxx のようにbを入れるだけでここでスレ保存、閲覧できます。
TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像
↓「C++相談室 part137 ->画像>4枚 」を見た人も見ています：
・C++相談室 part156
・C++相談室 part126
・C++相談室 part142
・C++相談室 part143
・C++相談室 part136
・C++相談室 part147
・C++相談室 part144
・C++相談室 part138
・C++相談室 part137
・C++相談室 part135
・0からの、超初心者C++相談室
・C++相談室 part131 [無断転載禁止]
・Cygwin + MinGW + GCC 相談室 Part 8
・C#, C♯, C＃相談室 Part94
・C#, C♯, C＃相談室 Part91
・C#, C♯, C＃相談室 Part97
・【太気拳】なんでも相談室 part6【意拳】
・アパート経営なんでも相談室【135号室】
・シーバスなんでも相談室 17©3ch.net
・アパートマンション経営なんでも相談室【154号室】
・アパートマンション経営なんでも相談室【153号室】
・アパートマンション経営なんでも相談室【154号室】
・BBC「リリベットは女王に相談してない」ヘンリー夫妻「相談したわ訴えてやる」王室ノーコメ
・【聯合ニュース】韓日慰安婦合意「密室会談で決着」「韓国外交の恥」 韓国与党議員が主張[10/27]
・【皇室】眞子内親王殿下がお気持ち表明「結婚に向けて家族とも相談しながら進んでまいりたい」★12 [ばーど★]
・【皇室】眞子内親王殿下がお気持ち表明「結婚に向けて家族とも相談しながら進んでまいりたい」★14 [ばーど★]
・【皇室】眞子内親王殿下がお気持ち表明「結婚に向けて家族とも相談しながら進んでまいりたい」★8 [記憶たどり。★]
・【身体】ズバリ解決！名医のお悩み相談室 気づくのが難しい『前立腺がん』 前立腺肥大症との見分け方は？[09/02] ©bbspink.com
・【名古屋】いじめ相談も「報復」恐れ学校側は直接指導せず…中1女子が下校後に自殺 2月から教室に行かず別室で授業 ★2 [ばーど★]
・【ガルパン】マライ・メントラインの勝手にお悩み相談室「困っています。全力で『ガルパン』を推すために私は何を為すべきでしょう」 [鳥獣戯画★]
・皇室の相談役に就任する五百旗頭眞『拉致なんて取り上げるのは日本外交として恥ずかしい。こっちははるかに多くの人間を強制連行してる』 [Felis silvestris catus★]
・【美容医療相談室 神谷和宏】医師法に違反する恐れ。。http://biyou-iryou.jp/">http://biyou-iryou.jp/
・相談室
・荒らし相談室
・パワハラ相談室
・シーバスなんでも相談室55
・シーバスなんでも相談室67
・シーバスなんでも相談室58
・シーバスなんでも相談室73
・シーバスなんでも相談室57
・シーバスなんでも相談室39
・50代の恋愛よろず相談室
・シーバスなんでも相談室27
・シーバスなんでも相談室19
・山神愛美の恋愛相談室
・シーバスなんでも相談室29
・シーバスなんでも相談室28
・蟹座の恋愛相談室 その3
・アトピーのお悩み相談室
・シーバスなんでも相談室【避難所】
・PC相談室5月廃止・・・ISIZE崩壊へ
・必ず誰かがなんたら相談室 Part.3
・【大衆演劇★なんでも相談室 2幕】
・相談室のお姉さんに恋をしてしまった
・drunkerの「悩み相談室」 2016
・苔 コケ 初心者なんでも相談室-２回目
・ギコネコ先生の自作ＰＣ相談室その43
・音ゲーお悩み相談室【隔離病棟】
・鍼灸マッサージ質問相談室パート14
・船乗りなんでも相談室 第7次航 【外航用】
・一級建築士設計製図相談室（199室）
・【構成】BTO購入相談室【見積り】■39
12:19:29 up 8 days, 22:43, 0 users, load average: 8.69, 9.11, 9.01
in 2.4275469779968 sec
@2.4275469779968@0b7 on 122102
|
