http://2chb.net/r/tech/1584975873/1000 > 1000 名前:デフォルトの名無しさん[sage] 投稿日:2020/05/14(木) 15:51:59.69 ID:X1Z5LMNW [4/4] > ん? > >未だにC++03にしがみついているわけがない > >>993 で17使ってると言ってたようだが > > てかもうちょい生産的な話出来んのか > 仕事でも趣味でも都合の良いコンパイラ使えばいいだけの話 > 構造化束縛をマクロとテンプレートで実現するとかなら面白い話題なんだけどな(面白いだけで実用性があるとは言ってない なんだ、17で俺スゲーやってんのおまえじゃん 俺は仕事で17は当たり前という立場 おまえは仕事には危なくて使えないという立場 俺に教えを請うて突っぱねられたのがおまえ あとはわかるな? >>3 >なんだ、17で俺スゲーやってんのおまえじゃん >おまえは仕事には危なくて使えないという立場 ? 俺の話じゃないんだが・・ いいから消えろよ荒らしは >>5 その「組み込み」ってのは、まさかH8とかか? ARM用のコンパイラがどうなっているか知ってるか? >>4 逃げたければ消えるのはおまえだ ほら行けよ、追わねえでやるから extern "C" 以下が、宣言になるなのか、定義になるのかについて、以下のページには、 extern "C" { int i; } と書くと、i は、「定義」される。 宣言で済ましたい場合には、 extern "C" { extern int i; }としなくてはならない。しかし、中括弧で囲まずに、 extern "C" int i; と書いた場合には、i は「宣言」だけされる、とあります。 さらに、これは変数の場合で、関数の場合には、戻り値 関数名(仮引数列) の後に関数定義部の{・・・} があるかどうかで宣言か定義かが変わるだけのようです。といいますか、関数の場合は、関数定義部 がなければ、「定義」しようがないのでそれは当然かもしれませんが(結構複雑です。)。 これらの動作について、cppreference などで述べられているページがあれば、 教えていただければ幸いです。 https://stackoverflow.com/questions/1041866/what-is-the-effect-of-extern-c-in-c Note that extern "C" { int i; } is a definition. This may not be what you intended, next to the non-definition of void g(char);. To make it a non-definition, you would need extern "C" { extern int i; }. On the other hand, the one-declaration syntax without braces does make the declaration a non-definition: extern "C" int i; is the same as extern "C" { extern int i; } >>8 【関連事項】 [winnt.h の中] #ifdef __cplusplus #define EXTERN_C extern "C" #else #define EXTERN_C extern #endif [urlmon.h の中] EXTERN_C const IID CLSID_CdlProtocol; // (100) [考察] (100)は、EXTERN_C のマクロ展開後 *pure C では、 extern const IID CLSID_CdlProtocol; // (101) *C++ では、 extern "C" const IID CLSID_CdlProtocol; // (102) となります。 (101)は明らかに(「定義」ではなく)「宣言」なので、モード間のバランスから考えて、 (102)も宣言でなくてはなりません。一方、 #ifdef __cplusplus extern "C" { #endif int aaa; #ifdef __cplusplus } #endif と書いた場合、aaa は、どちらのモードでも「(変数)定義」であり、単なる「宣言」ではありません。 これは、(102)が「宣言」であることと、ある種の矛盾を生じているようですが、これが現状の 正しい解釈のようです。しかし、この事が cppreference のどこに書いてあるのかが分かりません。 1回しか使われていない場合 2回以上使われている場合 「宣言」とは別に定義がリンクされている場合
>>10 そういうことは理解しているつもりです。 extern ではなく、extern "C" の動作が、直後にブロックがあるかないかや、 変数か関数かによって、不思議な変化を見せることに興味があります。 int aaa; //definition in C++, tentative in C int aaa; //invalid in C++, valid in C
クラスで定義された型を言語構文でバラして対応付けると言う非対称な気持ち悪さと const, 非constを混在して受けられない不便さとがあるな 構造化バインディング まーtuple限定ではなく構造体を対応付けられるから非対称ってわけでもないか
>>8 extern "C" {} はブレース内をCリンケージで処理するつって話 extern "C" int a; はCリンケージのextern文 >>14 stackoverflow以外に、公式サイトでそれが書かれている場所を教えていただければ幸いです。 cppreferenceは仕様書じゃないから書いてなくても不思議じゃないと思うけど。 仕様書見たら?ドラフト版はネットに転がってる
>>16 その公式アドレスを教えていただければ幸いです。 >>15 cppreference.comに書かれてるぞ つーか、cppreferenceに書いてあるのに見落としてよそのサイト教えろとか馬鹿丸出しで笑える
情報量ゼロのゴミレスでドヤ顔する自覚なきクズ大杉 20はggrksと言いながらちゃんとリンク貼ってる
>>24 「私たちは抗議活動のための支援団体、人道支援団体ではない」 反日団体だから慰安婦なんか知ったことじゃないって事だろ? 筋通ってると思うが。 そういえば、チョンにチョンというのはチョン差別で違法だけど、日本人に日本人というのは別に問題ないね。 フランス人にフランス人というのも問題ないし、中国人に中国人というのも問題ない。 何が違うんだろ。
チョンというのがダメなのかと思ったけど。 朝鮮人に朝鮮人というのも朝鮮人差別だから違法だよね。 ますますわからん。
以下の混乱を、どう解決すべきか分かる人いますか? ・無名の共用体: 問題は特に有りません。 ・無名の構造体: 入れ子の構造体(nested class)の「型定義」と区別が付かない気がします。 以下はその説明です : class CPerson { // (1) struct _TAaa { // (2) ・・・ }; // (3) }; と書いた場合、(3) の部分にメンバ名が書かれていません。 しかし、これでは以下のどちらかなのか区別できない気がするのです。 a. CPerson の中に「無名ではあるが実態のあるメンバ」として「メンバ変数」を定義するつもり。 b. 単に、CPerson の class scope の中に _TAaa というタグ名を持つ構造体を「型定義」するつもり。 MSは、a の方針で、この形式 (2)~(3) を、「anonymous structure」と定義しているらしいです。 しかし、C++ には、b の解釈の「nested class」という言葉も存在しています。
>>28 自分でコンパイルしてどうなるか試したんだよな? std::bitset を std::unordered_map か std::map のキーとして使用したいのですが、 どうすればよろしいのでしょうか?
std::unordered_map<std::bitset<42>, int> um; um[std::bitset<42>("0011")] = 9999; std::cout << um[std::bitset<42>("0011")] ; 普通に動いたぞ 何に困ってるんだ?
>>33 >>34 下のコードで書いてもエラーが出てしまってどうすればよいかがわからないんです。 #include <map> #include <unordered_map> #include <bitset> int main() { std::map<std::bitset<100>, int> a; std::bitset<100> n; n.set( 1 ); a.insert( std::make_pair( n, 100 ) ); // ここでエラーが出てしまいます。 return 0; } >>35 エラーメッセージも貼って、エラーメッセージのわからないところも書いてくれるといいな。 >>36 error C2676: 二項演算子 '<': 'const _Ty' は、この演算子または定義済の演算子に適切な型への変換の定義を行いません。(新しい動作; ヘルプを参照) with [ _Ty=std::bitset<100> ] message : クラス テンプレート メンバー関数 'bool std::less<std::bitset<100>>::operator ()(const _Ty &,const _Ty &) const' のコンパイル中 with [ _Ty=std::bitset<100> ] message : コンパイル対象の関数 テンプレート インスタンス化 'bool std::less<std::bitset<100>>::operator ()(const _Ty &,const _Ty &) const' のリファレンスを確認してください with [ _Ty=std::bitset<100> ] message : コンパイル対象の クラス テンプレート インスタンス化 'std::less<std::bitset<100>>' のリファレンスを確認してください message : コンパイルされている変数テンプレート 'const bool is_empty_v<std::less<std::bitset<100> > >' のリファレンスをご参照ください message : コンパイル対象の クラス テンプレート インスタンス化 'std::_Tree<std::_Tmap_traits<_Kty,_Ty,_Pr,_Alloc,false>>' のリファレンスを確認してください with [ _Kty=std::bitset<100>, _Ty=int, _Pr=std::less<std::bitset<100>>, _Alloc=std::allocator<std::pair<const std::bitset<100>,int>> ] message : コンパイル対象の クラス テンプレート インスタンス化 'std::map<std::bitset<100>,int,std::less<std::bitset<100>>,std::allocator<std::pair<const std::bitset<100>,int>>>' のリファレンスを確認してください わかった、std::mapだとダメなんだな bitsetがoperator<持ってないからだ これ定義すればmapでも通ると思うよ template<> struct std::less<std::bitset<100>> { bool operator()(const std::bitset<100>& lhs, const std::bitset<100>& rhs) const{ return lhs.to_ulong() < rhs.to_ulong();} };
>>35 a.insert( std::make_pair< FOO , BAR >( n, 100 ) ); まあどうしてもmapにしたい理由がなけりゃおとなしくunordered_mapにした方がいいと思うけど stdのテンプレートをstdのクラスで特殊化するのは本来は反則だし、unordered_mapの方がだいたい効率いいし
普通に考えたらこれだろ。 std::make_pair( n, 100 )
皆さん。情報ありがとうございます。 >>38 試してみた所ビットを33個立てるとstd::overflow が出てしまうようです。 おそらく関数の仕様的な問題だと思うのですが…… >>40 a.insert( std::make_pair<std::bitset<MAX>, int>( n, 100 ) ); とやってみた所エラーが出てしまいました。 この辺の指定はコンパイラが勝手に行ってくれると思っていたのですが、 指定しなければならないのでしょうか? >>41 std::unordered_map を利用するとうまくいきました。 ありがとうございます。 >>42 すみません。 >>40 と同じ理由なのでしょうか? bitset の値同士で < での比較ができないから map でエラーってことか。 unordered_map なら == で比較できれば使える、と。
ああ>>38 だとulongにして比較してるからオーバーフローしちゃうな 真面目にビット比較するように関数書けば通ると思う 遅そうだしなおさらunordered_mapの方が良くなるけど ラムダ式にテンプレートの型指定ってできないんですかね? auto f = []<class T>(T) {}; auto f2 = []<class T>() {}; f(1); f2<int>(); fは引数にその型のパラメータがあるので大丈夫なんですけど、 f2だとコンパイルが通らないです...
ダミーの引数渡して decltypeするとかすればいいんじゃね
>>46 auto仮引数ではあかんの? auto f = [](auto arg) { cout << typeid(arg).name() << endl; }; f(1); //int f(1.5); //double 以下のコードを実行すると 'あ' がアルファベットと判定されてしまうのですが、なぜかわかりますか? Visual C++ 2019でもg++ 7.5.0でも結果は一緒でした(値は違いますが)。 std::locale loc(""); std::locale::global(loc); std::wcout << std::isalpha(L'あ') << std::endl; std::wcout << iswalpha(L'あ') << std::endl;
というより、その判定結果だからこそあはアルファベットなんだよ isalphaがtrueを返すものを現在のロケールにおけるアルファベットと呼ぶと言う方が正しいか
いや、isalphaがtrueになる文字は各localeで決まっている isalphaはそれを垂れ流しているだけ
is_ascii_alpha()のほうが良く使う。
ありがとうございます 普段は「日本語のアルファベット」とはあまり使わないけれど、 設定されている言語で表現するための文字のことをアルファベットと呼んでいると理解しておきます。
そもそも英語では普通にひらがなとカタカナを指して"Japanese alphabet"と呼ぶ
あと正確に言うなら日本語のアルファベットは いろは
isalpha()が2バイト文字環境でいままで使われてきた経緯も知らずに勝手に仕様を変えてしまう馬鹿な人々。 min,maxも伝統的なマクロの存在を知らずに衝突させてしまう馬鹿。 さらに馬鹿なのはSTL作者達なのにコンパイラ処理系作者のせいにしてしまう愚かな烏合の衆たち。
STLは、なぜあの時代に、ここまで抽象化できたのか?彼らは宇宙から来たのではないか?などと考えてしまうが。
Windows.hのmin、maxは困りものだよな。
マクロでminmax書いているほうがどう考えてもバカだよな
win32の設計とかあーバカコードだなコレってのがちらほら
人類がBOOST_PREVENT_MACRO_SUBSTITUTIONから解放される日は遠い
STLの方が馬鹿。 今までのものを知らないで独自のものを書くのは簡単。 勉強もせずに独自の日記を書くようなことだから。
なぜ会社を100社以上バックレたのか?働きたくない男の末路! VIDEO 【遅刻早退ドタキャン癖】の絶望的な解説。社会人失格の烙印。 VIDEO 【悲報】あがり症は完治しない!緊張対策よりも開き直り! VIDEO 結婚式への参加は『社会の底辺』には地獄!非モテ手当を寄こせ! VIDEO 親戚の『葬式』ドタキャンで激怒された!冠婚葬祭パワハラが酷い! VIDEO リボ払い借金500万円の一日!敗者復活ルーティーン VIDEO >>59 ちがいます、フェニキア文字由来ですよ アラビア語はセム語族の中でも後発後進国 関数(始点,終点)に馴染めないバカのあぶり出しだったな 関数(始点,個数)に固執してたやつらがSTLで吠え面かかされたw
>>65 ソ連で生魚にあたって、入院中に病院の天井みてたら思いついたらしいぜ 寄生虫より有毒魚かもな フグみたいな命取りなやつじゃなくバラムツくらいなら腹壊す程度で済む
>>75 がどれに対するレスなのか分からんが みんな単にスルーしてんだろうなこれは dtmみたいな楽器を作る場合、音は何らかのライブラリを使うんでしょうか?1から作れるんですか?
>>85 いかにもデジタル的な音は昔はFM音源だった。 あと、ランダムノイズ的なものも利用。 今は、楽器を物理シミュレーションしている場合がある。 オートチューン使うと自分の声が楽器みたいになります。
あるクラスのvectorに対し、個々のクラスのメンバのvectorを返すのってラムダ式でサクッと書けると思うのですが、どうやればいいですか? struct A { int i; }; vector<A> v(10); auto v_i = ~ラムダ式~ // サイズ10のvector<int>が返る こんな感じです
[&]{ std::vector<int> ret(v.size()); std::transform(v.begin(),v.end(),ret.begin(),[](A d){return d.i;}); return ret; }
[](A){...} のところは&A::iでもいいかな
なるほど、std::transformを使うのですね Pythonみたいにサクッとできたらよかったのですが、ちょっとイメージと違いました ラムダ式に変な期待、というか勘違いしてました 素直にrange for文で個々にemplace_backするほうが短いし分かりやすいので、今回はそうします ありがとうございました
pythonだと[d.i for d in v]って所か? lambdaじゃないけど
>>90 そういうSTLのbegin,end表記見てると pure Cのqsortの書き方を思い出してしまう。 危険なので毎回良く仕様書を確認してから慎重に使わないといけないという。 gdbのプロンプトでsqrtとかabsみたいな数学の関数使えないんだけど使えるようにする方法ある?
毎回生成したくない大きめな作業用配列とかって結局どこに持っとくのが良いの? メンバ変数として? グローバル変数として?
そんなことで悩むレベルなら毎回生成しろ たぶんそんなことでは全く遅くはならん
なるべく使う奴にしか見えないスコープに閉じ込めるんだよ bool1個だろうと10GBの配列だろうと一緒 基本を守るだけだ
>>99 $ gdb some_program (gdb) break main (gdb) run (gdb) print ((double(*)(double))sqrt)(2.0) って感じで使えないかな。 たぶん some_program は何らか libm の関数を取り込んでないとダメだけど。 >>104 できました そのキャストが必須な理由はまだ理解してませんが 作業用の領域の扱いってたしかにいつも悩むんだが、 *) ループや関数の内側で毎回コンテナ (vector, set, queue, etc...) を宣言し、初期化し、使う と *) ループや関数の外側にコンテナを宣言しておき、ループや関数の内側で初期化し、使う だと当然後者の方が低コストで、可読性を大きく損なわない限り後者の方が良いのだよな? 初期化の計算量のオーダーは両者とも同じだが、可変長コンテナのメモリアロケーションの回数を少なくするのが重要だと思って良いのだよな?
もう一個質問 STLコンテナの初期化は空とのswapでやったりすると思うが、この場合コンテナが置かれたメモリの場所は変わらんよな? つまり、余計なメモリアロケーションは起こらんよな?
なぜ同意を求める? 部下に相槌を打つようにいつも説得しているのか? お願いします 教えてください も言えんのか
行単位でファイルを読み込んだあと、パースするような処理で巨大なテキストファイルを扱う場合だと、顕著に後者が速くなる まあ一度プロファイラで確認してみればいいよ
>>106 場合による。 「可読性を大きく損なわない限り後者の方が良い」という理屈なら 「速度を大きく損なわない限り前者の方が良い」とも言えてしまうよ。 どちらが大事かなんて場合によるとしか言いようがない。 >>107 C++ の標準ライブラリにあるコンテナに関して言えば swap でアロケーションは発生しない。 アロケーションは発生しないけど std::array はちょっと特殊で要素の swap が発生するので 線形時間がかかることになっていることには注意。 >>112 再配置と言えば再配置ではあるけど、 >>107 の質問について 「コンテナが置かれたメモリの場所は変わらんよな?」に対しては「はい。 コンテナのメモリの場所は変わりません」だし 「余計なメモリアロケーションは起こらんよな?」に対しては「はい。 メモリアロケーションは発生しません」なので 正確に注意点を表現するなら「(格納場所の swap ではなく) 要素単位の swap ですよ」という表現になるでしょ。 単にgetlineした文字列を vectorに詰める場合、 getlineしたバッファをmove push_backしたり、shrink_to_fitしてmove push_backするより、何もせずpush_backでコピーを詰め込んでバッファを使い回しってのが一番速くてメモリ効率もよく、コードもスッキリする
>>106 比べるようなものではない 毎回再初期化させる必要があるなら前者一択 ループを抜けた後で何かするなら後者一択 Promiseってなんでわざわざfutureを作ってあげなきゃいけないのです? 思想的な話なの?
STLのsetで重複したノードの登録を除外する方法がわかりません 整列基準とするint key1,key2,key3の値にかかわらず、POINT positionが重複する値だったら除外したいのですが、意図した動作になりません 例えば(0,0),(0,1),(1,0),(1,1)の4パターンのみで同一パターンは除外されるようにしたいのに20パターン以上重複して登録されてしまいます setについてご存知の方いらっしゃいましたらご教示願います #include <set> #include <time.h> #include <windows.h> using namespace std; bool operator ==(const POINT& inA, const POINT& inB){ return (inA.x==inB.x)&&(inA.y==inB.y); }
//setに入れる要素 class CNode { public: POINT position; int key1; int key2; int key3; CNode() { position.x=rand()%2; position.y=rand()%2; key1=rand()%3; key2=rand()%5; key3=rand()%10; } //setに入れるCNodeポインタを整列する基準を定義 inline bool operator()(const CNode* a, const CNode* b) const { //positionの値が同じ要素はsetに登録しない bool same = (a->position == b->position); if( same ) return false; //↑このあたりが怪しい? ここでfalseを返すと登録数が期待よりも多過ぎ、何も返さないと期待よりも少なくなる //キーでの整列用 if(a->key1 != b->key1) return a->key1 > b->key1; if(a->key2 != b->key2) return a->key2 > b->key2; if(a->key3 != b->key3) return a->key3 > b->key3; return false; } };
typedef set<CNode*, CNode> NODE_POINTER_SET; int main() { srand((unsigned)time(NULL)); int NUM=100; printf("setへの登録候補数:%d\n",NUM); CNode* dammy[1]; NODE_POINTER_SET NodePointerSet(dammy, dammy+0, CNode()); CNode* node; for(int i=0; i<NUM; i++) { node = new CNode(); printf("%x:(%d,%d)【%3d %3d %3d】をセットへ\n" ,node ,node->position.x, node->position.y ,node->key1, node->key2, node->key3 ); pair<NODE_POINTER_SET::iterator, bool> insert_result = NodePointerSet.insert(node); //setへ登録 if( false == insert_result.second ) delete node; //重複で登録できなかった場合は確保したメモリを破棄 } printf("\nset内に登録された要素数:%d\n",NodePointerSet.size()); for(NODE_POINTER_SET::const_iterator it=NodePointerSet.begin(); it!=NodePointerSet.end(); ) { printf("%x:(%d,%d)【%3d %3d %3d】をセットから\n" ,*it ,(*it)->position.x, (*it)->position.y ,(*it)->key1, (*it)->key2, (*it)->key3 ); delete (*it); //メモリの後始末 it=NodePointerSet.erase(it); //setから削除 itは次の要素を指す } }
std::setの整列はlessでstd::unordered_setは整列せずでequalだったと思う。 たぶん近藤してる。
>>125 すみません、もう少し詳しくお教え頂けないでしょうか 初心者で見よう見まねでやっているので… 整列はできているのですが、除外がうまく動かないかんじです スマートポインタは、難しそうなので私にはまだ早いと思っています (でも、そのうち取り組みたい) std::setとstd::unordered_setの規格票を参照。テンプレート引数の最初は値。その次の引数は比較になっている。比較だけど、その比較はequalかlessなのかが問題だ。 lessというのは、不等号で書くと<。 equalというのは、==という意味。
>>127 最初は見よう見まねなのは仕方ないけど、関数の仕様を解説してるページを探して仕様を確認する癖をつけるといいぞ。 まずstd::setについて調べると https://cpprefjp.github.io/reference/set/set.html Compareは狭義の弱順序において前ならtrueとある 狭義の弱順序のリンクをたどると https://cpprefjp.github.io/reference/algorithm.html#strict-weak-ordering !comp(a, b) && !comp(b, a) として equiv(a, b) を定義する場合、 equiv(a, b) && equiv(b, c) は equiv(a, c) を意味する必要があると書いてある。 あなたの作った比較関数は、この条件を満たさない。 {{0,0},0,0,0}=={{0,1},0,0,0}=={0,1},0,0,1}だが、{{0,0},0,0,0}!={0,1},0,0,1}となってしまう。 もう少しざっくりとした説明。 setは、ソートした後に、等しい要素が隣同士に並ぶことを前提としている。 これにより、隣り合った要素とだけ重複判定することで効率化している。 しかし、問題の比較関数でソートしても、等しい要素が隣同士に並ぶとは限らない。 {{0,1},0,0,6}, {{0,3},0,0,4}, {{0,1},0,0,2} のような要素列を、この比較関数でソートしても、順序は変わらない。 先頭と末尾が等しいはずなのに隣り合っていないため、重複判定が行われない。
難しいですね… つまり //positionの値が同じ要素はsetに登録しない bool same = (a->position == b->position); if( same ) return false; のところをどう書き直したら動くのでしょうか? どうか教えて下さい m(_ _)mこのとおり!
弱順序とか区分化とかあの説明だけで理解できたら天才だろ だから群論・集合論の教科書を数冊読むとC++がスラスラと理解できるようになる
bool CNode::operator<(const CNode& rhs) const { if (key1 != rhs.key1) { return (key1 < rhs.key1); } else if (key2 != rhs.key2) { return (key2 < rhs.key2); } else if (key3 != rhs.key3) { return (key3 < rhs.key3); } else { return false; } } を実装したら最低限逝ける、 等値演算子「==」は、それがCNodeのメソッドまたはCNode&を引数にとる 関数定義がなされていなければ(!(a < b) && !(b < a))で遂行される ただしそれでは効率が悪いので(「==」1回につきoperator<()が2回呼ばれるので)、 「==」も手動で実装したらモアベターではある
>>132 そこだけ書き換えて修正するのは無理 あきらめて別の方法を考えることをお勧めする そもそもCNodeにoperator<実装してないのになんでコンパイル通ってんのか謎 隠してるコードがあるなら全部出せ
>>137 > typedef set<CNode*, CNode> NODE_POINTER_SET; inline bool operator()(const CNode* a, const CNode* b) const { if(a->key1 < b->key1) return true; if(a->key1 > b->key1) return false; if(a->key2 < b->key2) return true; if(a->key2 > b->key2) return false; if(a->key3 < b->key3) return true; if(a->key3 > b->key3) return false; //ここまでヒント。 }
>//positionの値が同じ要素はsetに登録しない >bool same = (a->position == b->position); >if( same ) return false; 仕様誤解してたサーセンgrz、、
皆様ありがとうございます >>135 なるほど、<が2回呼ばれるのですか(いろいろ試していて2回ずつカウントされているのを不思議に思ってました) ご紹介頂いたコードを追加しましたが、rhsがポインタでないせいか効果がありませんでした ポインタを、そのメンバ変数基準で整列させたいのですが、 bool operator<(const CNode* lhs, const CNode* rhs)const で定義しようとするとコンパイルエラーC2804 binary 'operator <' に引数が多すぎます。 になってしまいます ==演算子も同様に駄目でした <や==演算子オーバーロードでポインタを整列させる事は無理なのでしょうか? >>140 の内容からすると、無理なのかな? (自分で試してみて無理そうだと思ったので、仕方なく()オーバーロードで定義を書いていました) >>139 ヒント見ても理解できないこの無能な鈍物めにお答えを賜りたく どうかお願いします! >>122 > 整列基準とするint key1,key2,key3の値にかかわらず、POINT positionが重複する値だったら除外したい これ要求に間違いが無いなら、独立した比較基準(整列用と重複判定用)が2つあることになるので、 単一の比較関数(およびset)で解決しようとしてるのが間違いかな。 △ ヒント ○ これ以上は分かりませんでしたがMOTTAINAIので貼ります
簡単に出来そうだと思っていた事が、結構な難問だったようですね… 自分の力では無理そうだという事がわかっただけでも収穫でした 皆様ありがとうございました
>>135 > 等値演算子「==」は、それがCNodeのメソッドまたはCNode&を引数にとる > 関数定義がなされていなければ(!(a < b) && !(b < a))で遂行される 要出典 >>145 > insertの動作はinsertしてから重複だったかどうか返すというもの 要出典 C++は美しい bool operator <(const POINT& inA, const POINT& inB){ int rA2 = ( inA.x * inA.x + inA.y * inA.y ); int rB2 = ( inB.x * inB.x + inB.y * inB.y ); return ( ( rA2 < rB2 ) || ( ( rA2 == rB2 ) && ( inA.y < inB.y ) ) ); } inline bool operator()(const CNode* a, const CNode* b) const{ if(a->key1 != b->key1) return a->key1 > b->key1; if(a->key2 != b->key2) return a->key2 > b->key2; if(a->key3 != b->key3) return a->key3 > b->key3; return false; } NODE_POINTER_SET NodePointerSet2(dammy, dammy+0, CNode()); for(int i=0; i<NUM; i++){ node = new CNode(); pair<NODE_POINTER_SET::iterator, bool> insert_result = NodePointerSet2.insert(node); //setへ登録 if( false == insert_result.second ) delete node; //重複で登録できなかった場合は確保したメモリを破棄 } std::map<POINT, CNode*> mp; for(NODE_POINTER_SET::const_iterator it=NodePointerSet2.begin(); it!=NodePointerSet2.end(); it++ ){ if( !mp[(*it)->position] ){ mp[(*it)->position] = (*it); pair<NODE_POINTER_SET::iterator, bool> insert_result = NodePointerSet.insert((*it)); //setへ登録 } }
>>147 key1,key2,key3 で整列しないのは回答として不適ではないの? 等値演算子「==」の話はただの思い込みだったということでいいんかね。 setの重複排除条件をコントロールしたいだけなら std::(unordered_)setのPredテンプレート引数で制御すればいいだけの話じゃないの? からかって遊んでるだけ?
positionによる重複削除だけでなく、key1~3によるソートと重複削除も必要だから 単純に順番にやるだけだと、余計な要素まで消えてしまう。 {{0,0},0,0,0},{{0,0},0,0,1},{{0,1},0,0,0} みたいなデータがあった場合、単純にpositionによる重複削除を先に実施してしまうと {{0,0},0,0,0},{{0,1},0,0,0} みたいになって、そこからkey1~3によるソートと重複削除を行うと {{0,0},0,0,0} だけになってしまう。逆順でも同様の問題がある。
その隠し要件どこに書いてるの?もしそれが必要なら横着せずに全部持っておくしかないね
すみません仕様間違えていました >positionによる重複削除だけでなく、key1~3によるソートと重複削除も必要 ではなく positionによる重複削除だけでなく、key1~3によるソートも必要 で、key1~3が全部同じでもpositionが異なれば重複削除はしないという仕様が正しかったです なので >>148 さんが書いて下さったコードを追加して、 if(a->key1 != b->key1) return a->key1 > b->key1; if(a->key2 != b->key2) return a->key2 > b->key2; if(a->key3 != b->key3) return a->key3 > b->key3; return true;//ここをfalseではなくtrueに変更 にしたら、期待どおりの動作をしました 148さん本当にありがとうございます!とても助かりました 147さんもありがとうございます 難しい事はわかりませんが、 動作検証が足りてないかんじでしょうか もし駄目だったら、諦めて別の方法を考えようと思います
double *array1; array1 = new double[count](); と書いた場合の、[count] の後ろの () の意味は何でしょうか? array1 = new double[count]; と書いた場合との違いは何でしょうか? ()の中に何か書くことは出来ますか?
>>157 内容を初期化するかどうか。 普通のクラスでは括弧がなくてもデフォルトコンストラクタで初期化されるので 空の括弧があってもなくても意味はかわらないけど、 プリミティブな型などでは括弧無しのときは初期化しない。 (つまり内容は不定) 括弧があればゼロで初期化されることが保証される。 C++14 あたりからはこんな感じで初期化することもできるよ。 double *array1 = new double[]{1,2,3}; ヘッダでvector要素の型を先行宣言で済ますことができるのc++20からだっけ?
Working Draft, Standard for Programming Language C++ Document Number: N4713, Date: 2017-11-27 というPDFを読んでいるんだけど、explicitキーワードの事について調べようとしても、 索引(index)には載ってないようだけど、どこに書いてる?
>>163 N4713だよね? P.1373の2行目は見た? >>164 Indexのspecifier項目のサブ項目として書いてあったんですね。 でもこれだとexplicitが何なのかを知りたい人にとっては索引としての役割を果たさないです。 いわば国語辞典で知らない単語を調べるのに勝手にカテゴリー分けしてあるようなものです。 それでは辞典の意味をなしません。 >>165 PDF なのだから、ある項目について知りたければ検索すればいいよ。 この分量を印刷して読んでいるわけではないよね? 試しに検索かけたら1102件もヒットしたやんけ!餃子のバカバカ
AdobeRederは使いにくいので、SumatraPDF Reader を使って、まず、 左側のペーンに出てくる目次で index をクリックし、右側のペーンに 巻末の索引を出した後、右側のペーンの中で CTRL+Fを押して、 explicitを検索すると良いよう。
素直にありがとうも言えないのか これだからC++erは
nested-name-specifier: :: type-name :: namespace-name :: decltype-specifier :: nested-name-specifier identifier :: nested-name-specifier template opt simple-template-id :: と有るのですが、このBNFだけで解釈するなら、ns1, ns2,ns3 という namespace が有った場合の ns1::ns2::ns3::変数名 のような場合、 namespace-nameと認識されるのは ns1だけで、ns2,ns3は、identifierと 識別されるのでしょうか。
ちなみに、 namespace-name: identifier namespace-alias namespace-alias: identifier となっており、namespace-nameには、a::bb::cc のようなものは含まれないと思われます。
>>171 の定義だと、 decltype(x)::decltype(y)::decltype(z) のようなものは使えないということになるようです。 ひょっとすると、C++の仕様書的には、 ns1::ns2::ns3::変数名 も使えないのもかも知れませんがよく分かりません。 >>167 つーかよ、その1102件を末尾から順に見ていくとすぐなんだが そういう生活の知恵はあんまりないのかい? newしたあとにdeleteしなくてもアプリケーションを終了すればメモリは解放されますか?
>>178 Windows/Mac/Linuxではメモリー領域自体は絶対に解放される。 ただし、deleteが呼び出されるわけではないので、原則的にはデストラクタは呼び出されない。 >>175 たまたまの結果を生活の知恵とかw キーワードと通常言語が被らない日本語万歳だな >>178 プロセスに割り当てられているメモリは現代の普通のデスクトップOS上でならプロセスの終了と共に解放されるのだけど、 オブジェクトは外部のリソースのハンドルを掴んでいることがあるから それを正常に (デストラクタで) 後始末しないとリソースリークが起こる可能性はある。 POD 型のオブジェクトに限ってならば管理されてるリソースはメモリだけだから delete しなくてもプロセス終了時におおよそ安全に解放されることは期待していいと思う。 言語仕様での保証はないので C++ スレ的に言えば「やめとけ」ってことになるけど。 メモリと断っている人に余計なこといわなくていいと思うけど アプリの異常終了であっても解放されてほしいのだろうから c++の終了処理に依存してもしゃない
>>181 何がたまたまの結果だよ C++規格票とドラフトは巻末に索引があって 検索でヒットしすぎるときは末尾を見に行けば そこは索引の中である可能性が大きいというのを 思いつくことができんのかおまえさんの頭では だから見つけられなくて聞いてきたというなら合点だ >>178 世の中すべての::operator newの内容を確認してからでないと答えられない質問だ もっと言うなら将来にわたってタイムマシンで確認してくる必要があるから 調査の工数が発散しちまう どういう意味かわかるな? めちゃくちゃ難しいです。#100の部分は恐らく「部分特殊化」というものだと思うのですが、 自分がネットで調べた簡単な部分特殊化とはちょっと違っているようです。 https://ja.wikipedia.org/wiki/SFINAE // どのようなテンプレート引数であってもvoidになる template <typename... Ts> using void_t = void; template <typename T, typename = void> struct has_typedef_foobar : std::false_type {}; // #100 template <typename T> struct has_typedef_foobar<T, void_t<typename T::foobar>> : std::true_type {}; // T::foobarが存在すれば、こちらが有効になる struct foo { using foobar = float; }; int main() { std::cout << std::boolalpha; std::cout << has_typedef_foobar<int>::value << std::endl; std::cout << has_typedef_foobar<foo>::value << std::endl; } >>188 他人かどうかは関係ねえぜ 俺が生活の知恵と言ったことを たまたまの結果と言ったのはおまえさんに他ならない 必然的に思いつくまでの思考過程を示されて 自分の浅はかさを誤魔化すのに他人がどうのと 再び浅はかな言い訳で恥の上塗りするのは やめたほうがいいんじゃないかな >>190 部分特殊化とは、 template <typename T1, typename T2> class A {・・・}; //#1 として、「primary class template」を定義後、もし、 template <typename T> class A<T, void>{・・・}; //#2 と書いた場合、 A<int,int> なら、#1が、A<int>なら#2が適用されるということでしょうか? ならば、A<int,void>はどうなるんでしょう?? >>194 やーい、同じことしか言わなくなってやんのw 必ずしも索引があるとは限らないのにあることを一般論化してドヤ顔するのと ヒープ解放するかどうかはすべてを尽くして調べられないからわからたないとドヤ顔してる奴が 同じ人物だってのが困るわぁwwww
>>193 >>195 2017年のDraftのPDFには、以下のようにあり、部分特殊化をinstance化する際には、A<int>ではなく、A<int,int*> と書く例があります: Partial specialization declarations themselves are not found by name lookup. Rather, when the primary template name is used, any previously-declared partial specializations of the primary template are also considered. One consequence is that a using-declaration which refers to a class template does not restrict the set of partial specializations which may be found through the using-declaration. [Example: namespace N { template<class T1, class T2> class A { }; // primary template } using N::A; // refers to the primary template namespace N { template<class T> class A<T, T*> { }; // partial specialization } A<int,int*> a; // uses the partial specialization, which is found through the using-declaration // which refers to the primary template —end example ] >>197 C++規格票とドラフトと言ったはずだ 必ずしも索引があるとは限らないとぬかすなら そうなっていないC++規格票とドラフトを例示しろ 事実無根の誹謗中傷はやめてもらおうか >>193 ほんとに >>195 の言う通りだわ。 やってみてから思った通りにならないのはなんでだろうっていうならまだしも 「どうなるんでしょうか」なんてやってみりゃわかることだろ。 まあ C++ には未定義とか処理系定義とかもあるから 実際の挙動を以て言語仕様を理解しようとするのは危険でもあるんだが……。 特殊化ってのはまさに「特殊な場合」を定義するもんだよ。 その場合には A<T1, T2> のテンプレートの特殊な場合として A<T, void> の場合を定義してることになる。 特殊な場合である A<T, void> は特殊でない場合の A<T1, T2> と同じ形式である必要がある。 >>199 基本的な理念が理解できていないのに仕様を読んでも理解できねーよ。 (まあたまには仕様からとっかかる超人もいないことはないが。) お前は Rust スレでも見当はずれの根拠をコピペしては意味不明なことを言ってるが、 普通に入門書を読んでくれ。 質問しといて無礼な口の利き方をするやつにはお仕置きだ 一切何も教えない
>>203 ぐうの音も出ねえとは おまえさんのことだな >>207 都合よくげんていつけたりなくしたりwwww >>206 なんでも上から目線 やはりこういうやつかwwww 181 返信:デフォルトの名無しさん[sage] 投稿日:2020/06/03(水) 12:24:39.32 ID:DAHZjgl3 [1/9] >>175 たまたまの結果を生活の知恵とかw キーワードと通常言語が被らない日本語万歳だな getCFile()ってよくわからないので教えてください。 コードに次のような部分がありました。 getFile()では置き換えられない? /// \brief Get C-file. /// \return Extracted stdio's @c FILE structure. std::FILE * getCFile(); file_.getCFile()
>>193 推定だけど、 A<T, void> の場合、2番目の仮引数がvoid型になっているので、そこには実引数を 指定しないということになっているらしい。 その結果、A<1> みたいに1つだけの引数でtemplateをinstance化できる 様になっている気がする。 まだ仕様書で確認したわけではない。 いや、省略した場合のデフォルトを指定しない限り、そんなことにはならない template <typename T1,typename T2=void> class A; みたいにする まあ、primaryの定義と同時にも書けるし、そっちが普通
>>204 俺が答えていることすら理解できてない模様。 [驚くべきパターンマッチング] MS製のSTLのforward()のソースを呼んでいて驚いた。 forward()の引数のremove_reference_t<_Ty>&& _Argの部分は、とても複雑なパターンマッチングをしているらしい。 _Tyがまだ決まって無い段階で、remove_reference<_Ty> というテンプレートclass を展開してtype メンバを調べ、それと実引数から右辺値参照部分を除いた部分を一致させるような複雑な処理をした結果、_Ty を逆算して決定しているらしい。 template <class _Ty> struct remove_reference { // YA, #1, primary class template。" using type = _Ty; // const も保存されているハズ。 using _Const_thru_ref_type = const _Ty; }; ・・・ remove_reference<> に対する部分特殊化があるが、省略 ・・・ template <class _Ty> using remove_reference_t = typename remove_reference<_Ty>::type; template <class _Ty> _NODISCARD constexpr _Ty&& forward(remove_reference_t<_Ty>&& _Arg) noexcept { // forward an rvalue as an rvalue static_assert(!is_lvalue_reference_v<_Ty>, "bad forward call"); return static_cast<_Ty&&>(_Arg); }
>>215 仮に心の中にあってもあなたは全く言語化して無いないので駄目。 >>218 そういえば仕様書に、templateをinstance化する際は、既に deducedされたパラメータは A<B>のBの中には書かないで良い例が書いてあった。 たとえば、 template <typename T1, typename T2>T1 f(T2 a); のような場合、 f<T1>(100); みたいにすれば、T2はint型だと分かるので、f<T1,int>(100)と書かなくて良いというもの。 それかな? そうではなく、>>190 の場合は、primary template として、 template <typename T, typename = void> struct has_typedef_foobar : std::false_type {}; と、第二パラメータにデフォルト引数が書いてあるからか。 >>218 190ってまさにtypename=voidしている例じゃね >>221 >>220 と入れ違いになった。 それで辻褄は合うけど、primary templage definition では、 template <typename T, typename = void> で、部分特殊化する際には、 template <typename T> としてあって、物凄い複雑だね。 TdRUmxlvは自分の日記帳に書いてくんないかな
失礼しました。 でも断っておくと、俺ははちみつに対してそんなに悪口は言ってない。 スレの流れで混乱していたようだが、言っていたのは別人だから悪しからず。
いちいちイラッとする書きっぷりはID:TdRUmxlvのコミュ力が絶望的に低くいだけなので許してあげてください
int& r_i=7; // compile error int&& rr_i=7; // OK 2行目は、どういう仕組みになってるんでしょう? 7という値がメモリー上にはどこにも存在して無い場合もあるはずで、 その場合でも右辺値参照を持てるものなのでしょうか? たとえばコンパイラの中に7という値は持っていても、アセンブラレベルでは、 どのsectionの中にも7というデータが入れられて無い場合もあると思うのです。 それだと7の入っている場所のアドレスは存在しえません。 例え「"右辺値"参照」であってもはアドレスが必要のはずですが。
>>228 言語規格的にはrr_iという名前を通じて7という値が取れれば何でもいい コンパイラが具体的にどうするかはコンパイラの勝手 アドレスがどこかで必要なら一時オブジェクトを作るようにするし必要なければ作らなくてもいい >>230 どうやら、7の入ったint型の隠れた変数を一時オブジェクトとして作成してから、 そのアドレスをrr_iに入れているそうです。 >>228 int& r_i=7; // compile error 確かにこれはダメ int&& rr_i=7; // OK int& rr_j = rr_i; // OK これおかしくね? 昔のソースコードからの派生で開発する際、リソースの開放だけをデストラクタで行うように変えたいと考えています RAIIだけを行う標準的な実装って何かあったりしますか? あるいは、自分で調べた限りでは例えば、 HANDLE hFile = CreateFile(filename, GENERIC_READ, FILE_SHARE_READ, nullptr, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr); unique_ptr<void, decltype(&CloseHandle)> dummy(hFile, CloseHandle); // 以降dummyは使わずに生のhFileに対して操作 のようにunique_ptrを使えばできそうに見えますが、C++11以降の作法として正しいでしょうか?
作法とか正しいとかより自分で考えた方がいいと思うけど その場合あえて言えば、hFile渡すとこは 直接CreateFileの戻り値使って(hFileを宣言しない)、dummyの持つハンドル経由で使った方が 一貫性が取れていいかも 理想を言えば全部ラップした方がいいんだろうけど
>>236 その方法は始めてみた。 でも、unique_ptrなどを使わなくても、普通にC++98レベルのclassだけを使っても、RAIIは書ける。 >>238 RAIIというのは物凄く簡単に実装できて、細かいことを抜きにすれば以下の様にすれば完成する : class CMyX { protected: HANDLE m_hFile; public: CMyX(HANDLE hFile) {m_hFile=hFile;} ~CMyX() {CloseHandle(m_hFile);} } HANDLE hFile = CreateFile(filename, GENERIC_READ, FILE_SHARE_READ, nullptr, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr); CMyX myx(hFile); // これが初期化。後は勝手に hFileが解放される。 ポインタ以外のリソースでRAIIやらせるためのstd::unique_resourceが提案されてるけど難航してる リソースの種類や使い方でそれぞれ事情が違うから無理矢理一般化しても上手く行かないらしい
>>239 補足すると、このコードだとCreateFile()した後、返されたハンドル値を No CheckでCMyXのコンストラクタに渡しているが、本当はその前にINVALID_HANDLE_VALUEかどうかをチェックしておく必要がある。 >>234 そこじゃなくて int& r_i=7; // compile error をエラーにする必要ある?ってこと リテラルを右辺値参照できんならエラーにする必要ないじゃん それがエラーじゃなかったら右辺値参照は何のためにあるんだよ
>>243 別にリテラル受けるためにあるわけじゃないでしょ 別の言い方すると int&& rr_i=7; // OK わざわざ一時オブジェクトつくってこれOKにする理由って何なの? >>237 ,238,240 ありがとうございます >>239 はい、そうなんですけれど、こういったコードも省略したいということと、 頻繁に必要になるので標準ライブラリに入っていないかなって期待していたわけです >>240 なるほどstd::unique_resourceっていうので検討中なんですね これが標準に組み込まれるのを期待しておきます More Effective C++ の、 項目9 : リソースリークを防ぐためにデストラクタを使う 項目11 : デストラクタから発生した例外を抑える デストラクタ中で、例外がキャッチされない場合、 terminate を呼ばれて、受け身も取れず、強制終了させられる
>>245 CreateFile以外にも似たようなのが沢山あって、それを楽にRAIIにしたいって話? ならすでにunique_resourceはあるらしいけど(experimentalだかどこかに あるいはそれに近い実装も公開されてるので落としてくればいいかと 逆にCreateFileだけなら素直に自分でクラス書いた方が後々楽になると思う リソースの解放以外は生のハンドルが使いたいという前提だと、 「unique_resource で包まれたオブジェクトからハンドル使うたびに (get で) 取り出す」という操作が必要になる。 たぶん >>236 の書きようだとそういうことはしたくないんだろうし、 包む前のハンドル (が入った変数) をそのまま使うとなると折角の所有権管理が台無しだ。 unique_resource はリソースの所有権管理の仕組みであって、 デストラクタでリソース解放もするのは所有権管理に付随するものに過ぎない。 どちらかというと scope_exit の方がやりたいことに近そうな気がする。 けど、いずれにしても中途半端なんだよな。 現時点でリソースの解放 (CloseHandle) がちゃんとできているなら それを unique_resource (なり scope_exit なり) に置き換える意味はあまりないんじゃなかろうか。 「CloseHandle の書き漏らし」ってのと「scope_exit の書き忘れ」 ってのは同程度に有り得ることで、そんなに良くならないと思うよ。 型としての HANDLE の実態は void* なので、 HANDLE を HANDLE として扱おうとする限り C++ の型システムの恩恵はあまり受けられない。 古いコードをなるべくいじらずに使いたいという理由はとてもよくわかるのだけれど、 半端な書き換えをするくらいなら抽象レイヤをきちんと構築した方が結局は楽だと思う。 void * と型として区別出来ない? 型はともかくそもそも HANDLE は値の範囲が決まってたか
かなり前から DECLARE_HANDLE マクロで HANDLE は固有の型として定義してた。 そこは私の認識間違いだ。 すまぬ。 >>249 void* という型として認識出来たところで何が出来るものでもないよねという意図だった。 >>239 しね~よ void bar(CMyX& x, HANDLE h) { // hを思わずclose CloseHandle(h); } void foo() { HANDLE hFile = CreateFile(filename, GENERIC_READ, FILE_SHARE_READ, nullptr, OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL, nullptr); CMyX y(hFile); bar(x, h); // このあとしぬ } >>239 のCMyXはハンドルをマジWrapしてるだけで全く使えない しねよ というわけでget()メソッドが無いのも大概だが それより悪いのはCloseHandle()が失敗したときのことを何も考えていないことだ ファイルのClose失敗はエラーハンドリング省略で済まされる問題ではない デストラクタでCloseHandle()を一概に否定するものではないが、 デストラクタから例外を飛ばすわけにもいかないので、エラーの通知先オブジェクトへのポインタをCMyXは持つ必要がある
>>252 File Handle のような OS Object については、RAIIで処理するのは実は難しいんだよ。 だから、WindowのDestroyWindow()もデストラクタで処理する前に明示的に CWnd::DestoryWindow()を自分で呼び出すほうが良かったりするんだから。 デストラクタだけを頼りにすると、main()やWinMain()関数の後の クリーンアップ処理の中で CloseHandle()が呼び出されたりすることになるが、 それは結構微妙な話になる。 なぜかといえば、まず、OS自体がそもそも、プロセスが終了する時には 勝手にすべてのハンドルを閉じてくれる。ならば、CloseHandle()なんて明示的に 書く必要が無い、というそもそも論が出てくる。 それプラス、あなたが言ったように、CloseHandle()で失敗した場合にどうなるか という話もあることはある。 そもそも、個人的には、ファイルを開いたら、なるべく速く Closeする方が良いと思っている ので、RAIIでファイルハンドルを処理するのは余りぴんと来ない。 アプリ全体の終了が前提になっているおかしな主張だな
CloseHandleやfileのcloseで失敗する様な状況って、普通のアプリじゃ実質対処不能な致命的な状態だろ 素直に落ちるなりおかしな挙動になるなりすればいいのよ
OSやハードが正常稼働時ならそこら辺の例外発生はないからね。 リソース解放忘れてデスクリプタやらのリソース使い果たしたり、ファイルの占有したままで他のアプリに迷惑かけたりするのを防止するのにRAII使うのは有用
HANDLEってOS側からはそれが有効か無効か判断できるから、無効なハンドルを 間違って使ったりCloseHandleしてしまってもエラーを返すだけで致命的な状態には なりにくい
前提にしているのがどんなOSであろうと C++的には環境依存な話だね
要素はintと任意オブジェ int値を渡すと 論理和がゼロ以外の要素を 返すコンテナってないですか?
>>256 もし、CTRL+Sを処理するイベントハンドラの中で、単純に CloseHandle()を自分で呼び出して 失敗した場合であれば、保存に失敗した事をAfxMessageBox()で知らせた後、なんとか今までの メモリ中のデータだけは壊さずに処理できればベスト。 しかし、他の何らかの例外が発生した時に、RAIIによって自動的に呼び出されたデストラクタの中で CloseHandle()に失敗した場合には、対処が難しそう。 テストも難しいし、余りそういう状況は起きないので優先順位は低いが。 >>260 std::pair<int, SomeObj> を格納するコンテナと 「int部分とある値とのビットORを結果とする述語」を std::copy_if() に渡すような話かな。 「任意オブジェ」部分が要素ごとに異なる、だと難問な気がするけど。 確かに論理和だと「つまらない」結果になりそうね。 普通の使い方なら論理積で抽出か。 排他的論理和は「もっと面白い」かも知れんけど。
>>262 それで組んでみます ありがとうございました あと実際は論理積です >>256 「ログファイルなので書込みに失敗しても大勢に影響が無い」とか 「作業用ファイルfは書いた後必ず誰かがリードオープンするから書込みに失敗していたらそこでワカルから書込みのエラーチェックを省略する」 みたいな判断はアプリの設計としてはアリかもしれないが、CMyHandleみたいな汎用部品的に使われ得る低水準クラスではナシ これをアリだと思う香具師はお気楽すぐる、 >>266 でも >>256 の CloseHandle() や fclose() が失敗したからといって、何か手が打てるのですか? 何もできないのでは? もしかして黙って exit() するのですか? てか、自動解放するクラス作っても手動解放する手段残しておけば、使う側で特別な処理は出来るんだよね
>>267 通知は欲しいかな。 黙って動作が続くくよりは terminate() のほうがマシだとも思うし。汎用部品ならなおさら。 破棄失敗する可能性のあるリソースの RAII wrapper にはエラー通知できる close() なりの破棄操作を別に用意しておけという話で済むと思う。 >>270 通知って簡単にいいますけれども、その例えば fclose() 失敗の通知をどこに送り、そして送った先では何をするのですか? 通知をもらって何か手を打てるのですか? 汎用部品/ライブラリの作法ですか 理解はできますが、しかし、何もできないのなら、あるいは何もできないことがわかっているのなら、特段の失着にはみえませんね… 大事なデータを保存したファイルのfclose()が失敗したらどうするかって? 場所変えて保存を試みるに決まってるだろ それくらいしないプログラムは売り物にならないぞ
そもそも仕様で指定があるならそのように書くだけなんじゃ
>>271 たとえばコンソールアプリなら標準エラーに情報を出したうえで終了コードに反映して、 コマンドが失敗したのを見たユーザーが何をするか考えるっていうのはごく当たり前のことでしょ。 たとえばストレージ容量が足りないとして失敗したなら容量を確保して再実行すればいい。 fclose() の戻り値を捨ててるプログラムは現実としてたぶん多いんだけど、 そんなソフトがたとえばサーバー内でストレージ容量不足を数か月にわたって闇に葬り続け、 何かおかしいと気付いたサーバー管理者が自動スクリプトを緻密にトレースした結果、 保存されているはずの情報がもはやどこにも存在しないと気付いた時の怒り憎しみ悲しみを想像されたい。 少なくとも成功したと誤解しないのが重要。 >>274 実はそれがRAIIの限界なんだよ。 ちゃんと明示的に fclose() してその戻り値をチェックするのが一番安全。 例外安全性のためにRAIIを使うべきという人が居るけど、それで勝手に デストラクタ内でfclose()して容量不足やディスクエラーで書き込み失敗した時には、 多くの場合、対処に困る。 でも、例外安全のためにはそうせざるを得ないかも知れない。 ということは、そもそも論になり、例外の throw、catch機構自体が安全に扱うのが 難しいという結論に至り、議論百出する。 >>276 それは飛躍しすぎかな。 破棄が失敗する可能性のあるリソースの RAII ラッパーが破棄操作も提供すれば済む話でしょ。 std::fstream の close() みたいに。 デストラクタ内でエラーが発生する可能性があってそれに対処が必要なら 例外の送出とか言ってないでデストラクタ内で対処してしまえよ。 汎用的な部品にし難いのはしゃーないやろ。 実際に汎用的ではないんだから。
おまいら (f)printf() の戻り値もちゃんと毎回観てるか?
>>279 そうじゃなくて、何らかの別の事情で例外が送出された時に、fclose()し忘れを 防ぐためにRAIIのテクニックを使う場合の話をしてる。 >>277 fstreamであろうがなんであろうが、GUIアプリに置いて、デストラクタ内で失敗した 時にユーザーに失敗したことを知らせるのは結構難しいぞ。 そんなに難しいか? 深刻な事態が疑われるならシステムモーダルダイアログなり何なりすることあるだろ あくまでOSではなくアプリとして事後条件が保証できない場合はterminateを呼び出して OSに事故としての扱いをさせるのが「難しい」のは思いつかないだけじゃねえだろな プログラミング以外の仕事でも事故はまず報連相 1人で握りつぶそうとするのは学生気分が抜けてないやつのすることだ
>>282 そりゃ難しいだろうな。 通知が要るならデストラクタ内で失敗させないように破棄操作を提供すれば済むだろうという話をしたつもり。 それで済まないケースを想定してるなら、どんなのか教えて。 >>283 そっか GUI ならダイアログ使えるから、通知するだけなら簡単だね。 >>284 >通知が要るならデストラクタ内で失敗させないように破棄操作を提供すれば済むだろうという話をしたつもり。 意味が分からないので、説明を。 >>283 Exceptionをthrowした時の自動フォローアップとしてRAIIのデストラクタが呼び出される。 それが呼び出されるのは原則的にどこかでかは余り仮定できない。 ということは、非常に変なタイミングで fclose()に失敗することがある。 メッセージボックスを出すと、そこでイベントに対するメッセージループが形成されるので、 タイマーイベントのハンドラのOnTimer()などが起動してしまうこともある。 OnTimer()を、Exceptionがthrowされた状態で実行してよいかどうかは注意を要する事だ。 また、アプリの初期化処理の InitInstance()や終了処理のExitInstance()の中で、RAIIの デストラクタが呼び出されてしまう場合もあるかも知れず、その中でメッセージボックスを 出すと思わぬ問題が生じるかもしれない。 生じないかも知れないが。 ただ、Exceptionがthrowされたということは何か異常が生じているということで、 それがたまたまファイルに関するものであったとしたら、二重三重に、ファイル関連で エラーが生じてしまい、何か危険な状態に陥ってしまう可能性も有るかも知れない。 そういう微妙な配慮が必要となる。 >>287 もっといえば、Exceptionのthrowはどこで起きるかは仮定しにくいものなので、 何らかのダイアログを出すための初期化処理の中で生じることも有るかも知れない。 そういう場合にたまたま、関数の呼びだし元へ どんどん Exception の Unwinding が生じて、RAIIのデストラクタで fclose()が呼び出される可能性も有るかも知れない。 そうなって、さらに、その fclose()がエラー終了する場合がある。 ダイアログの生成に失敗したタイミングで、エラーメッセージの表示のために、 メッセージボックスのダイアログを出すことになれば、もしかしたらかなり危険な バグを含むことになってしまうかも知れない。 >>286-288 ごめん、別の例外でスタック巻き戻し中の fclose() 失敗は無視でもいい想定だった。 元の例外が通知されればそれでいいだろうと。 破棄操作を提供すれば済むっていうのは、たとえば fstream について 正常フローから close() 呼び出せば fclose() の失敗は普通に処理できるっていう意味。 エラー発生後の後処理でのエラーについてはもはや例外処理機構とか RAII とか関係なく エラー処理一般で難しさは変わらないのでは? >>287 何を言い出すかと思ったらシングルスレッドを 気分だけマルチっぽく見せかけてるだけなやつの話か >>271 >知って簡単にいいますけれども、その例えば fclose() 失敗の通知をどこに送り、そして送った先では何をするのですか? 最終的にはユーザーに通知する >通知をもらって何か手を打てるのですか? ユーザーが通知に従い手を打てる >>279 デストラクタ内での例外を送出したら即アプリが死ぬハズ コアを吐いてくれたら通知にあたる情報が取り出せるかもしれないが美しくない >>287 異常の内容をユーザーに通知することを目的とするなら >エラーの通知先オブジェクトへのポインタをCMyXは持つ(>>252 ) で事足りる メッセージループは、通知先オブジェクトが1個だけもちさえすればユーザーへの通知の役目を果たせる CMyXのようなケースは通知先オブジェクトを保持するオブジェクトからFactoryMethodパターンでインスタンス化 するのがいかにもOOP的で個人的には好み(CMyXのインスタンス化のときに通知先を確実に渡せる >>292 私が書いた >>279 ではデストラクタ内で対処を完結させろ (例外を投げずに済ますために) と書いてあるつもりなんだが、お前にはそれが読み取れなかったか? ちなみに、現在の C++ ではデストラクタ (と delete) はデフォルトで noexcept で修飾されているものと見なされる。 これは例外を外へ送出しないことを保障するんだが、内部で例外が発生しないとは保証されない。 もし発生した例外を内部でキャッチせずに外へ出ていこうとしたら std::terminate() が呼び出される。 (スタックの巻き戻しは起こらずに即死するかもしれない。) 陽に noexcept(false) を指定したらデストラクタから例外を送出することは可能。 ただし、スタックの巻き戻し中に起動される別のデストラクタから例外が送出されると死ぬ。 普通は色々なライブラリを組み合わせるから問題が出ないようにするには 一貫してデストラクタからは例外を投げないのが妥当な設計だと考えられているってだけ。 >>293 よく読んでなかったわサーセンwwwwwwwwwwww >>292 ので >デストラクタ内で対処を完結させろ (例外を投げずに済ますために) のアッパーコンパチになるのだから結果オーライで オール無問題、 挫折するリスクも加味すると100倍くらいじゃないかな
>>295 個人の場合、実はC++は適している。 むしろ、大人数の場合、いろいろなレベルの人がいるので速度を落としてでも、 誰でも使えるような言語を使おうとする企業が多い。 ちゃんとしたものを作りたかったら、C++は最良の選択。 ところで、全く関係ないけど、昔は、 標準変換(Standard Conversions)の1つに、 「Reference Conversions(参照変換)」 という項目があったのに、C++17では、Overload Resolution関連で 「Reference Binding(参照束縛)」 という項目だけになってしまった、という認識であってますかね? もしかしたら古すぎて、もう分からないかな。
c++がどうこういうこと自体無意味な気分。 OSとコンパイラのバージョン指定でもせん限り、特定の議論にもなりゃしない。
これから始めようと思うのですが C++とC♯の大きな違いは何ですか どっちから先の方が良いですか?
あーじゃあ、C++には何が出来なかったせいで 後からC♯が作られたの?
んーでは、C++が劣っていてC♯が作られた理由は?
Javaの代わりが欲しかっただけであって優劣の問題はあまり関係がない が結局Javaの領域には食い込めず、スクリプト言語の代わりになった 自由度を奪う代わりに楽に書けるみたいな 結局自由度が必要なのでC++から離れられないので余計書くのがつらい仕様になった Win32APIのインクルードくらいSDKにまとめとけやPinヴォケって感じ
インタープリティアひとつつくっておけば色々な環境に使い回せるし版権問題にうるさいJavaをぶっつぶすため
>>306 > Javaの代わりが…スクリプト言語の代わりになった なるほどぉ、それでunityのスクリプトになってるのか、 C++の自由度って具体的には何を指すんですか? C++はアルゴリズムの部品化が一般的になっているので、自由に組み合わせられるところが、良いと思います。
>>308 やりたければメモリのどこにでもアクセスできるってのが特に重要な違いかな。 デタラメなアクセスをしても実行時エラーとして検出されるとは限らない。 プログラマがメカニズムを理解して正しくプログラムを書けるなら (監視して実行時エラーを検出するための) 保護機構は無駄で、 余計なものがある分だけ実行速度が落ちるから無い方がいい。 それが C++ の基本思想であるゼロオーバヘッドの原則。 でも現実はそうではない。 (プログラマは間違う。) C++で出来るんならいったい、C++の何が悪くてC♯が産まれたのやら さっぱりですね、 Wikipedia見にいったらc#はBoolean型とスイッチケースでストリング型が使えるそうなので c#にしようと思います お邪魔しましたわ、ありがとうございました。
c#を選択するのは悪くないと思うが、そこじゃないだろ
あーうーん、自然言語処理とかネットのデータベースで 文字列比較を多用しそうな予定は未定なので・・
>>298 MSDNのC++の仕様書を見ると、まだちゃんと Reference Conversionsの 項目があった。 C++17には無い項目だ。 文字列処理がメインで速度求めないならpythonとかの方がいいと思うぞ
>>312 >C++で出来るんならいったい、C++の何が悪くてC♯が産まれたのやら >さっぱりですね、 基本的に、Cの時代からポインタが理解できない人が多かった。 ポインタが理解できて無い人でも、コピペしたりすればC++も使えたかも知れないが、 ちゃんと理解できて無いので、理解できている人に比べてメモリーの解放を間違ってしまう頻度が高い。 そのため、ポインタが出てこないVBを使う人が多かった。 VBしか使えなかった人でもが使えるようにした上で、見かけ上の文法と言語の名称をC++に似せることによって 今までC++を使えずに肩身の狭い思いをしてきた人に希望の光を与えることに成功したのがC#。 VB、VBと馬鹿にされてきた恨みつらみの反動で、C++は古いということにして、 新しいC#に適用できない老人が使う言語、という印象操作をする運動が 繰り広げられている。
彼らの脳内では、なんとかしてC#の人気を出すことによって、 C++使いを減らしていけば、もう二度とVB、VBと馬鹿にされた暗黒時代に 戻ることがなくなると予定されている。
>>316 ありがとう、PerlやRubyも考えたんですが 文字列処理ってもコエカタマリン的な利用でDirectXが・・ C#はC++は、現実にかなり遅い。 それはそれぞれを使って作成されたアプリを比較してみれば分かる。 よく分かる例としてはVSだ。C++製のVSは高速だったが、C#製のVSは劇遅。 もう一つは、FrontPageとExpressionWeb 4。 開発に使われている言語以外はほぼ同じアプリだが、C++製の前者に比べて C#製の後者は劇遅。
>>297 手間がかかりすぎると聞きますがどうなのでしょうか それは.netフレームワークとかSilverlightの違いですか?WPF?でしたか? Win XPとVistaの違いなようなDirectX使うか使わないかというかGUI処理ありきで画面とロジックを分けたゆえのXMLパーサーの重さなのか グラボやドライバーがネックなような・・・
>>322 MFCがGUI関連が弱いという問題はあるが、C++自体は、手間はそんなにかからない。 そんなに難しいわけでもない。 ちゃんとC言語のポインタ周りを勉強して理解することが大切で、 それさえ分かってしまえば、C++はCよりも開発効率がかなり高いし、安全。 メモリの解放の純粋なC言語では手間がかかったが、C++だとデストラクタが 発明されたことにより楽になり、そんなに危険度は高くない。 Cでexitを安易に使う癖がついているやつには陰険な罠がデストラクタにはあるわけだが
>>320 文字列処理なら、可読性が高い、Ruby 一択! Perl は、意味の分からない暗号だらけで、ややこし過ぎる >>295 Electron も良いけど、Ruby on Rails も良い ただし、Rails でも、GUI は、HTML, CSS/SASS, JavaScript, jQuery, Bootstrap。 または、React >>328 例えばウディタはC++で作成されているようです 3dでもないのにC++?と思ってしまうんですが、何らかのメリットがあるのでしょうか? >>329 まず、Electronは配布ファイルのサイズが数百MBあるので、それだけでも プログラムの品質が下がる。 Rubyは、GUIに弱い。 C#は悪く無いとする人が多いが現実の本格的なアプリの例では遅いことが多い。 C#、Electron、RubyはC++よりはるかに優れているので、そっち使ったほうが良いと思います。 それらは実行時最適化のおかげでC++の10倍速いという実験結果もあります。
>>330 C#は、GUI部品はCで書かれているWin32を使っているので、簡単な HelloWorld程度ではC++並の速度が出ているように見える。 ところが、使うメモリの量が上がってくると急激に遅くなる特徴がある。 メモリだけでなく、GUIパーツが多くなるだけでも遅いと聞いている。 凄腕プログラマの中には、実感としてC++の10倍遅い、という人がいる位。 現にVSやExpressionWeb 4の起動速度は以上に遅いし、起動後もとても遅い。 >>331 みたいに嘘を言う人がいるのでだまされないほうがいい。 後で困るのは自分。 >>333 対立求めてる人はとっとと追い出したほうが良い。 >>333 おまえみたいに片棒担ぐやつもいないほうが良い。 おまえには王者の風格が無い。 何言ってんだふふんと、真のC++使いなら思えるはず。 おまえはC++を使えていない。 >>355 >何言ってんだふふんと、真のC++使いなら思えるはず。 いや、C++は沢山の問題点を持っていることは事実である。 しかし、効率面でC#は、C++には大差で負けることも、現実のアプリの例では 垣間見えることもまた事実。 じゃあいちいち他言語を下げるのはおやめなさい。 王者には王者の気品が求められるのです。
c++使うといつまでも完成しないなんて話を聞いたもんですから
可読性・難易度・バグりにくさ 動的言語 Ruby : 1 JavaScript : 3 静的言語 C# : 5 ポインターのある言語 C : 15 C++ : 75
わかりやすい例でいうと、Windows10がどんどん重くなっているが それは今までC++で書かれてた部分をC#で書き換え続けられているからといっても過言ではない
>C++で書かれてた部分をC#で書き換え続けられている それは別になっとらんぞ Windowsチームって.NET嫌ってるし
>>344 同じダロ 頭悪くなければ ライブラリを集めて使いこなせるくらいの頭な >>343 例えばタスクマネージャーや電卓はUWPだと思うが、これって.NETの焼き直しか再利用だと思ってるけどどうなんだろう >>346 シェルとかも含めたXAML UIの部分のこと言ってるんだろうけど あれはC#からも呼び出せるだけのネイティブで実装されたAPI(WinRT)だよ 今の電卓なんかはまさしくわかりやすい例で、特例でコード公開されてて全部C++(/CX)だよ 新規に打ち出そうとしてるWinUIもC++(/WinRT)での実装 UWPアプリ単体で見ればC++だったりC#だったりまちまちだろうけど 今はXAML=WPF=C#のイメージは切り離した方が良い >>347 納得した にしても以前の電卓よりはるかに動作が重い 呼び出し元より呼び出し先に重い何かがある気がしてならない >>335 王者の風格とか気品とか、真のC++使いだとか、そのキッズが喜びそうなワードばかり並べ立てて何がしたいの? 確かに「王者の風格」がでてきたときは0.5秒くらい「えっ?」てなった
>>338 プログラムの実装時の労力は言語だけでなく作る対象によっても変わるからケースバイケースだけど、言語の習得の労力で言えば、C++でまともな実用的なプログラムを作れるレベルに達するのは他の言語に比べて大変だよ。 もし今現在まったくプログラミングの経験がないなら、C++よりC#から始めた方がいい。 C#で速度がでないことを心配するなら、C#で作ってどう改善しても速度が足りないとなってからC++を学習してC++に移植する方がトータルでは早くできそう。 そもそもC#では速度的に厳しいような難易度の高いプログラムを、未経験者がいきなりC++で作り始めることはかなりこんなんだと思うぞ。 >>347 >今の電卓なんかはまさしくわかりやすい例で、特例でコード公開されてて全部C++(/CX)だよ >新規に打ち出そうとしてるWinUIもC++(/WinRT)での実装 C++/CX はC++ではない。 それが遅い原因だ。 C++/CXを勝手にC++と思ってしまう人が出て本物のC++は迷惑。 >>341 >C : 15 >C++ : 75 もともと、C++は、C with class 程度の意味で現れて、それで人気が出た。 その時は今ほど複雑でなく、Cではメモリー解放 free() を全部完全にプログラマが 書かなければならなかったところと、C++のデストラクタを使えば、ほぼ自動化することが出来た。 これにより、C++はCよりはメモリー安全になった。 型をC以上に厳密にすることで、コンストラクタとデストラクタの呼び出される回数が、ほぼ必ず同じに なるように設計されていた。 キャスト構文を使わず、それぞれのデストラクタの中で、子供のオブジェクトに対する delete 文を 書き忘れない限り、ほぼ、コンストラクタとデストラクタは一対一に対応するので、 結果的にメモリーの解放間違いはほぼ無くせる設計になっていた。 これが、(恐らく)後になって RAII という言葉で語られるようになっていった。 また、クラスメンバに対しprotected属性が使えることも安全性を高めた。 さらに、Cでは実行段階で関数を超高速に切り替えるためには関数ポインタを使うことが必須であったが、 C++では仮想関数でそれを行うことが出来るようになり、間違いを減らすことが可能になった。 クラスの継承の概念は、既に作ったプログラムを少しずつ変化させることに役立つため、 プログラムを美しく設計できるようになった。 C++は今のバージョンは難しく見えるが、もともとはCを安全にすることにとても役立つものであった。 「本物のC++」であるかどうかと速度は直接関係はないと思うが
>>357 >C++のデストラクタを使えば、ほぼ自動化することが出来た。 それ、全然「自動化」になっていないですよ… >>358 C++/CXは、メモリ関連で本物のC++とは異なったやり方をしている。 C++が速いのはまさにメモリ関連であるのだから、ソースの書き方が似ていると しても、そこを変えた言語で書いたプログラムの速度がC++と同じであるとは とても言えない。 この狂人C++/CXをC++/CLIと勘違いしてないか?
デストラクタをまともに設計できる奴があんまおらんからな。 てか資源解放てインスタンスの種類よりも生成したシチュエーションによることのが多いし シチュエーション事に開放メソッド選ぶ方がわかりやすい。 だからgoではdefer文による解放なんだろ。
>>362 ファイルハンドルの様な「資源」は、デストラクタによる解放は実は向いてない。 メモリーが向いている。 もともと、C++のデストラクタは、メモリー安全のためが主目的であったと 言っても過言ではなく、RAIIの R = Resource というのは、変な話。 >>364 全く逆だなぁ。 資源のように解放するタイミングが比較的重要なものこそデストラクタが向いているだろう。 メモリだけならGCでも全然問題ないし。 int と long long の和って long long ですよね? int と double の和も double ですよね? こういうのって大きいデータ型にキャストされると思って良いですか
タイルマップエディタを作る場合はC++とC#どちらがいいですか?
>>366 基本的にその考え方であってる。 細かいところは汎整数拡張でググってwikipediaを見てくるといいよ。 >>367 どっちでもいい どうせほとんどは途中で挫折するんだし、苦労して作ったところで現実には誰にも使われずに消えていく しかしその努力は決して無駄になるわけではなく、君の中には多少なりとも技術と経験が残るだろう 目先ではなく、将来何がしたいのか、そのためには何を習得すべきなのかを考えなさい 将来何をしたいか、わからないです 2dにopenglは必要ですか? 必要ならC++なんでしょう
2dにOGLは正直オプションだな。 OGLはグローバル規格だから、WindowsとかOSに縛られるということが少ない。 しかし、近年のGPUは3Dを基準に作っているからOGLを使った方が速度は出るかもしれない。 なお、OGLは特に言語は規定していない。
ゲーム作りたいのか? 今時のゲーム開発ではそもそもOpenGLを直で叩く必要はまずなくて、Unityなどの開発スイートを使うのが普通だ まあC#でいい
大事ナノは結局ロジックだと思うので(´・ω・`)速度とか考えずにやります
UE4はC++なので、ゲームを仕事にしたいなら、C++は使えた方がいい。 unityもスマホゲーや小規模開発でシェア大きいので、Unityで使うC#もやっておこう。 つまり、C#とC++両方を当然に使えるようになるべき。 趣味で作りたいだけなら、資料の多いunityでも、最近VE5の発表で熱いUE4でも、好きな方やればよい。 グラフィックエンジニアやりたいなら、DirectX12やVulcanにてをだしてもよいかもしれない。茨の道だがね
>>365 そうだよね GC言語はある意味一番簡単なメモリの管理は自動化できても、それよりクリティカルなメモリ以外のリソース管理が悲惨なことになる >>365 だから、あなたみたいなGC言語に慣れた人が多くなって、C++の本質が理解出来て 無くて RAIIなどといい始めたんだ。 ちがうんだよ、本来のデストラクタの主目的は。 デストラクタの中には、pure C の free() のように、本質的にはどんな場合に 呼び出しても失敗することが無いような関数だけを書くことが基本。 それを昇華すれば、deleteを書いても、絶対に失敗しないことになる。 これは数学的帰納法を理解できない人に入っている意味が分からないと思うが。 とにかく、デストラクタの役割も作られた目的も、メモリの安全な解放だったの であって、リソースの開放のためでは無いので、リソースの解放をデストラクタ の中に書くというのはさまざまな問題を生む。 >>365 >資源のように解放するタイミングが比較的重要なものこそデストラクタが向いているだろう。 少なくとも初期のころのC++は、そのようなことがデストラクタの主目的ではなかった。 今、GCでやっていることが効率が悪いことを見越して、かつ、メモリー安全性を確保するために 発明されたのがデストラクタだ。 数日前にも、ファイルハンドルなどのリソースをRAIIを使ってデストラクタで閉じようとすると、 失敗した時に対処できなくなるという非常に難しい問題が生じることが議論されていた。 メッセージボックスさえ出すことができないかも知れないのだ。 メッセージボックスを出そうとすることがむしろ仇となって、その瞬間に大切なデータが保存できて無い アプリもろともダウンしてしまう可能性がある。 なぜそういうことがおきるかというと、もともと、デストラクタは、失敗する関数をそこに 含めることを想定していなかったからだ。 >C++の本質が理解出来て無くて RAIIなどといい始めたんだ。 RAIIって20世紀の頃の禿のお言葉なんだがw
Bjarne Stroustrup 氏の事を禿と言ってしまう人の人間性を疑う。 名前が覚えられないのか。
妙だな? 誰も禿をびよーねとは言っていないのに・・・
>>379 向いてる向いてないと元々の目的というのは直接関係ないな。 後半の話も、リソースの解放ができないということではなくてメッセージボックスを 出せないというだけでしかないし。 まあ、RAIIが、20世紀に考え出されていたのであれば、それはそれで良しとしよう。 でも、彼の頭の中でどうであったとせよ、当時の本を見れば、デストラクタの 説明としてほぼ必ずと言って、メモリ解放のために用いる例が書かれていたのだから、 C++を実用的な観点で見た時にデストラクタの一番の使い道はメモリ解放であった ことは疑いの無い事実だろう。
>>385 誰も言ってくれてないから俺が言ってやるけど お前は自分が見えてないよ お前は人に教える立場ではなく みんなに教えてもらってる立場なんだぞ 見てて恥ずかしいわ >>246 に書いたけど、 デストラクタ中の例外の扱いについて、 More Effective C++ にも書いてある アメリカ人は馬鹿だから参考にならない。 彼らのために世界中の生産性が下がっている。
>>389 王者の気品とか言っちゃう奴の日本語よりはまともな人の書いた英語の方が遥かに読みやすいし、内容の価値は比べるまでもないw >>393 ASDLって何だ? ASDのことだろうか。 まさかADSLとごっちゃになってるんだろうか。 ホントに英語はまったくダメなんだな。英語の方が読みやすいなんて言って悪かったよ。 std::listやvector,map,unordered_mapなどのコンテナのイテレータについての質問です コンテナのある要素を指すイテレータを保存してるときに、 そのコンテナに対して変更が加えられたとき、保存したイテレータは有効なのでしょうか?? 例えば、元の要素が削除されたら、無効になるのは想像つきます 例えば、前後に別の要素が追加されたら、保存したイテレータは元の同じ要素を指してる保証はあるのでしょうか?? std::listはリンクリストなので、前後に要素を追加されても影響受けなさそうですが? std::vectorはインデックスで管理してるとダメそう? std::mapは?
イテレータが無効になる場合はコンテナの種類と操作によって決まっているのでまともな解説にはちゃんと書いてある。 例えばvectorのinsert()はストレージの再確保が行われなければinsertした場所より前の要素を指すイテレータは無効にならないといった具合。
デストラクタで例外を出す可能性があるクラス Hoge について ---- A.cpp Hoge hoge; int main(int argc, char **argv) { // hoge を使う return 0; } ---- A.cpp ここまで ---- B.cpp int main(int argc, char **argv) { Hoge hoge; // hoge を使う return 0; } ---- B.cpp ここまで B だと例外補足されるというか表示されるけど A だと握り潰されてプロセス終了する(例外出てても気付けない)?
はちみつ餃子 さまを筆頭とする方々にお答えしていただけることを期待しております。 std::forward()がどうやって実装されているかを調べるため、 MSのオープンソースのSTLのソースの「STL-master」の中の type_traits というのを見ていたのですが、仕組みが完全には分かりません。 以下の1つ目のforwrd()は、左辺値参照で受け取るまでは分かりそうなのですが、 その後、return static_cast<_Ty&&>(_Arg) としているのに、結果は、左辺値に なっていなければ、forward()の使用に合わないはずですが、なぜ、 右辺値参照にcastしているのに、左辺値参照のままなのでしょうか? /* 左辺値を受け取る forward() のテンプレートらしいですが、 _Arg が左辺値参照ならば(?)、static_cast<_Ty&&>(_Arg) と cast しても、右辺値参照になるとるは限らない??? */ template <class _Ty> _NODISCARD constexpr _Ty&& forward( remove_reference_t<_Ty>& _Arg) noexcept { // forward an lvalue as either an lvalue or an rvalue return static_cast<_Ty&&>(_Arg); } // 右辺値を受け取る forward() のテンプレートらしいです : template <class _Ty> _NODISCARD constexpr _Ty&& forward(remove_reference_t<_Ty>&& _Arg) noexcept { // forward an rvalue as an rvalue static_assert(!is_lvalue_reference_v<_Ty>, "bad forward call"); return static_cast<_Ty&&>(_Arg); } template <class _Ty> _NODISCARD constexpr remove_reference_t<_Ty>&& move(_Ty&& _Arg) noexcept { // forward _Arg as movable return static_cast<remove_reference_t<_Ty>&&>(_Arg); }
>>402 正確なルールを説明するとなると長くなる (というか私もそんなに入り組んだところまで把握してない) んだが、 「参照の参照」を作った時に調整されるルール reference collapsing によるものだと思う。 左辺値参照から右辺値参照を作ろうとしたときには左辺値参照に調整される。 >>403 回答有難うございます。 一生懸命調べたところ、こんな記述を見つけました。Tがオブジェクト型の場合、(T &&)x のように cast すると、 結果は、右辺値にならずに xvalueになるようです。 でもそこから先は理解できてません。 https://stackoverflow.com/questions/40801765/is-it-an-rvalue-or-lvalue-after-a-cast From expr.cast (this is applicable from C++11 and later) C++ 11 以後の場合 : The result of the expression (T) cast-expression is of type T. 式「(T)cast-expression」の結果は、T 型である。 The result is an lvalue if T is an lvalue reference type or an rvalue reference to function type and an xvalue if T is an rvalue reference to object type; Tが関数型への左辺値参照/右辺値参照の場合は、結果は 左辺値で、 Tがオブジェクト型への右辺値参照の場合は、結果は xvalue である。 otherwise the result is a prvalue. そのどちらでも無い場合、結果は、prvalue である。 >>404 今後のために、 先輩指名で相談に行って あなたの説明よりネットにはこんなの書いて有りますけど? なんてのは失礼でイラッとするからやめときや より詳しい説明が出るのは役に立つんだから別にいいだろ それよりもはちみつごときに様つけたりここの住人の筆頭にするな
>>404 xvalue は rvalue の一種。 >>407 lvalue, xvalue, prvalue は排反集合なのですが、 glvalueとrvalueは、正確に #define IS_GLVALUE(X) (IS_LVALUE(X) || IS_XVALUE(X)) // glvalue は、lvalue と xvalue の和集合 #define IS_RVALUE(X) (IS_PRVALUE(X) || IS_XVALUE(X)) // rvalue は、 prvalue と xvalue の和集合 なので、rvalueであっても、xvalueで無い場合がありえます。 それは、prvalueです。 >>406 >それよりもはちみつごときに様つけたりここの住人の筆頭にするな このスレでは、彼が一番C++に詳しいと思うんです。 もしかしたら日本の中でもかなり詳しい人の内に入るのではないでしょうか。 >>408 >なので、rvalueであっても、xvalueで無い場合がありえます。 このことは、正しいのですが、 #define IS_RVALUE(X) (IS_PRVALUE(X) || IS_XVALUE(X)) // rvalue は、 prvalue と xvalue の和集合 によれば、 xvalueであれば 必ず rvalue ではあるので、 「xvalue は rvalue の一種」 という命題は必ず真で、はちみつ餃子さんのおっしゃっていることは正しいと思います。 rvalueが動物、xvalueが犬、であるような関係になります。 動物(rvalue)であっても犬(xvalue)で無い場合がありえますが、 犬(xvalue)であれば必ず動物(rvalue)であり、犬(xvalue)は動物(rvalue)の一種です。 「xvalue は rvalue の一種」でもあり、 「xvalue は glvalue の一種」でもあるのですね。
>>412 >平均的には日常的に C++ でプログラミングしているやつの方が詳しいよ。 当然に。 C++は、何十年も前に既に完成している言語なので、実態はわかりませんが、仕事をC++を使っている人でも、はちみつ餃子さんのようには新しい仕様を知らない人の方が多いのではないかと思うのです。 はちみつ餃子 さまを筆頭とするはちみつ餃子さまにお答えしていただけることを期待しております。 普段どんな仕事をしてるの?
>>404 の 「The result is an lvalue if T is an lvalue reference type or an rvalue reference to function type and an xvalue if T is an rvalue reference to object type;」 の部分の訳が一部間違っていて、正しくは、 「Tが左辺値参照型か、または、関数型への右辺値参照の場合は、結果は 左辺値で、 Tがオブジェクト型への右辺値参照の場合は、結果は xvalue である。」 ということのようです。 結果として、>>402 の return 文のオペランドの static_cast<_Ty&&>(_Arg) の部分は、 1. _Argの型が左辺値参照型の場合、左辺値(i & !m) 2. _Argの型が右辺値参照型の場合、xvalue(右辺値の一種, i & m) となるようです。 自分のレスにレス返すスタイルなんなの 自分の日記帳でやれよ
また、質問します。 アプリでunordered_mapやunordered_setのコンテナ10個くらい使うのですが問題はキーの型が可変長でstd::stringで結構長いことです 具体的にはキーはファイルパスとかになるのですが で、頻繁にコンテナを使用します ファイラーみたいなアプリを想定して このとき、キーをstringにするとコピーなどのオーバーヘッドが発生?すると思いますがさすがにこのレベルは気にした方がよい?
ユーザーがカレントフォルダ移動したり、ファイル一覧のリストビューをスクロールするだけで走ります で、きにする場合はキーをstd::shated_ptrでくるめばいいんですかね?他に方法ありますでしょうか?
100万文字のstringをキーにしたって、unorderedの内部で扱うのはハッシュなんだから挿入や検索の速さは変わらん(ハッシュ計算のコストを除く) そのファイラーが糞重いんだったら原因はそこじゃないと思うぞ
ありがとうございます >>422 の言う通り最終的は実測でしょうが、キーをstringにしたときのキーのメモリコピーのオーバーヘッドを気にしてました が、よく考えてみますと実際にキーのコピーが発生するのは実際に要素を挿入するとき1回だけっぽいですね findメソッドやcountでキーを渡しますがキーを参照で渡しますし、hash関数も参照でキーの値を受けとりますし キーのコピーの頻度そこら辺を想像したことなかったので、びびってましたがびびる必要なかったぽいですね ということ、普通にstringをキーに実装してみます
>>424 string はムーブ対応してるんで所有権を渡してしまうなら文字列全体のコピーはしないよ。 >>426 なるほど、findやcountの場合はキーの値を実際にコピーする必要ないから、&&の引数のオーバーロードはないが、insertの場合は&&の引数で、所有権移せるバージョンもあるんですね この人がどうかは知らないけど スクリプト言語あがりはstring + mapばっか使うんだよね 万能さはわかるけどさ それで効率が~とか どうなのそれw
ワイはもうおっちゃんやから小さい単位で型を作って名前を付けておかんと何をしよったかわからんようになるんやが、 文字列三昧で上手いことやれてまうやつはどういう脳みそをしとんや……。 と疑問に思ったこともあったんやけど、大抵の場合はうまいことやれとらんかった。
プログラマ2年目だけど全然クラス作れんワイ低みの見物 責務責務いうけどどっからどこまでが責務やねん
std::string は参照カウントになってる場合もあるでしょ。 オブジェクトをコピーしても長さに応じたデータコピーが発生するとは限らない。 代わりに短い文字列ばっかりでも同じだけ重い可能性もあるんだが。
>>432 ちゃんとした実装なら短い文字列ではヒープアロケーションが発生しないような最適化 (いわゆる SSO) が入ってるよ。 gccは参照カウントなstringは課題があるからやめたって10年以上前に聞いた気がするけど今はどうなんだろ
>>123 >100万文字のstringをキーにしたって、unorderedの内部で扱うのはハッシュなんだから挿入や検索の速さは変わらん(ハッシュ計算のコストを除く) 厳密に言えば変わります。 データの個数がM、キーの文字数がNの場合、検索に掛かる時間は、 ハッシュを遣わなくて単純に比較した場合は、 O(MN) となりますが、ハッシュ法の場合でも、 O(M + N) となるので、掛け算と足し算の違いは有りますが、キーの文字数をいくら長くしても検索時間が増えない、というようなことはありません。 >>430 クエリとコマンド、リードとライトでとりあえず分けるとこからやったらええ >>430 責務なぁ……。 俺はとにかく名前で考えるようにしてるよ。 名前を付けたい単位に分けて、それを書いている内に名前を付けたい部分が出来たら括り出して…… という風に繰り返してたら (少なくとも自分にとっては) だいたい使いやすいデザインが出来てる。 名前を付けたらそれの役割ってのはほとんど自明だったりするし。 ぼんやりした構造って頭に残り難くて何をやってたかわけわからんようになるので、 名前を付けるってのはかなり大事なことだと思う。 >>438 キーはそんなにバイト数が長く無くて、常識的にはある程度で上限が有る事が多いので、通常はO(1)と書いてあるだけです。 なぜかというと、ハッシュ値で大体は特定できても、最後、キーが完全一致していることを確認しなくてはなりませんが、 その時に文字列の比較のために、文字列の文字数であるところのNに比例した時間が掛かるためです。 例えば、キーの文字列の長さNが、1GBだとすると、文字列比較のために1*10^9程度のループが必要となります。 >>439 そっか。一致比較が必要になる操作も確かに多いね。 N はわかったんだけど、 M もやっぱり最悪ケースの話ってことで合ってる? 「通常はO(1)」って言ってるし。 スレ立てるまでもないスレにも同じようなこと書いたのですがすみません 巨大なファイルを読み込んで書き出すプログラムを書いています time1, data1-1, data2-1, data3-1......datan-1 time2, data1-2, data2-2, data3-2......datan-2 : みたいな構造が延々と続いています でこれをdataごとに data1.csv time1 data1-1 time2 data1-2 : ってそれぞれ書き出して分割する感じなんです vector<ofstream&> files; for (auto filename : filenames) {
失礼途中で送信してしまいました。 vector<ofstream&> files; for (auto filename : filenames) { ofstream temp(filename, ios::out); files.push_back(&temp); } こんな感じでofstreamの配列を作ってあとはそれぞれにデータを入れていこうとしたのですが アクセス違反になります。スコープの外に出たらofstreamは勝手にcloseされる?そうなのでそのせいかなと思っています 複数のファイルに対して順々にデータを書いていきそれをループするのってどうしたらいいでしょうか
答え分かってんならちゃんと実体を外に持たせなよ vector<ofstream> files; for (auto filename : filenames) { ofstream temp(filename, ios::out); files.push_back(std::move(temp)); }
通常はO(1)(で見積もっときゃまぁ大きくは外れない)
業務でC++やることになりました どうせなら体系的に学ぼうと思い、本を買おうと思いますがおすすめありますか? CとC#の経験はあります Cは組み込み開発での利用に、C#はデザインパターンを少しは活用出来る程度のレベルです
>>435 キーの文字数Nはプログラムがビルドしおわったら変わらないのだから実質定数なのであって、 結局O(M)になるのでは… (任意のxについて x + 定数 < a * xを満たす定数aを見出せるからオーダー表記の約束によりO(M+(定数)) = O(M)ェ、 しかもこの場合のMはデータの個数に比例するとわいえ、一般的はハッシュテーブルなら衝突しない限り 1回のテーブルアクセスで目的のエントリにたどり着くから、実際にはデータの個数÷ハッシュテーブルサイズ(エントリ数) となるから衝突が無視できる(エントリ選択に統計的に偏りがなく、かつハッシュテーブルサイズが十分おおおきい ならO(1)と逝って良いキモス、 あと1億文字のstring aと10文字のstring bとでハッシュキーを求める手間はどうかというと、 正直にやると文字数に比例するが うまいことやったら定数にできる もしくは文字列の構成時に都度ハッシュを更新するようにして、 ハッシュが入用になったときカタが付いている形ににする
そんな事をするなら素直にノードのポインタを持て と言いたい
それではもともとの問題が解決しない 一億文字のstring aがメモリ上に存在するとして、 まったく別の手段で同じ字面の一億文字の文字列bを作ってしまったとする aはaのノードを指し、 bはbのノードを指す、としたときに、 2つのノードが実は同じ文字列であることを確かめるには、 プログラムが他にあまた生成した10億個の文字列を一つ一つ確かめ、 最長1億文字の比較を行わねば結論が出ない( ハッシュテーブルなら一瞬で済む
訂正orz、 誤: 10億個の文字列 正: 10億個のノードの文字列
>>440 >N はわかったんだけど、 M もやっぱり最悪ケースの話ってことで合ってる? >「通常はO(1)」って言ってるし。 ハッシュ値の値の種類が仮に1024個だとすると、 データの個数がMが1024に収まる範囲だと検索時間が増えないのでO(1)と言えます。 しかし、Mが、1024*1024 個になった場合、1つのハッシュ値あたり、1024個の キーが入ってしまう事になりますので、Mが1024個の時に比べて検索時間は1024倍に なります。 これも、Mがある範囲内ではO(1)と言えますが、Mが極端に大きいと、やはり、O(M)となりますね。 補足しておくと、>>435 で >ハッシュを遣わなくて単純に比較した場合は、 >O(MN) と書きましたが、ハッシュを使わない場合でもキーがランダムに近い場合、ここまで悪くなくて 検索時間は、O(M) 程度で済みます。 なぜかというとキーの文字数Nが長くなっても、比較は先頭の方の文字をいくつか調べる だけで異なることが分かってしまうことが多いためです。 少し複雑ですが、この事情は、文字数Nを大きくしても余り変わりませんが、 Nを固定して、データの個数Mを大きくしていった場合、だんだんと文字列を長く調査しないと 判断が付かないケースが増えてきます。 そのため、O(M^2)のような傾向が出てくるはずです。 ただし、これは、ハッシュを使わない場合で、かつ、キーがランダムの場合です。 >>441 識別子に使えない文字が含まれているが 本当にアクセス違反まで行ったのか? コンパイルが通らないはずだぞ >>442 左辺値参照を何だと思っている? &tempは左辺値参照に渡せないし tempを左辺値参照に渡したところで forのブレースを抜けるたびにtempのdurationが満了していて 破棄済みのオブジェクト痕跡への参照になるだけだ 読み違えてたスマンコorz キーというのは検索する文字列そのものを指していたのかそうか…。n_ 一方>>446-447 は キー = ハッシュキー ハッシュ = ハッシュキー N = ハッシュキーの長さ の意味で書いていた、、、。...n_ つーかそれ以前の問題で左辺値参照はdefault constructibleでないので そもそもvectorの要素になれない
>>443 凄い。しっかり動きました。ありがとうございます。 moveのこと全然理解できてないんで勉強します。 >>456 今の C++ (C++11 以降) だと vector の要素に求める要件 (requirements) の中に DefaultConstructible は無いよ。 各メンバ関数 (コンストラクタも含む) の要件として要素が DefaultConstructible であることを要求するものはあるけど。 アロケータの方の要件で参照はダメってことになってるみたいなんで参照が駄目には違いないんだけど、 DefaultConstructible でないというのは直接の理由ではない。 >>452 すみません、 >そのため、O(M^2)のような傾向が出てくるはずです。 これは忘れてください。 ハッシュを使わない場合の話ですが、Mが大きくなってもこのような傾向は出ず、 O(M)のままだと思われます。 なぜなら、同じハッシュ値に属するそれぞれのキーと、与えられたキーとの完全一致を 検査する際、何文字目で一致し無い事が分かるかについては、データの個数Mが大きく なっても、その期待値は変化しないと考えられるためです。 つまり、完全一致検査時に、個々のキーとの完全一致検査をループして行う時、 1つずつのキーと与えられたキーとが一致し無い事が分かるまでに検査が必要な 先頭からの文字数の平均値は、データの個数が多くなっても変化しないと考えられます。 そのため、この検査に必要なトータル時間は、α・M のようになり、 αが定数になるため、記号で書けば O(M) となります。 windowsのフラットデザインのほうのuiですが、これがC#というやつですか?すごく起動が遅い
>>462 uwpかwpf 言語はあまり関係ないない あとスレチ どうもです >>463 guiが重いということですかね C++の仕様になぜGUIがない 言語が強制すればOSが統一できるのに
>>465 出来ない仕様を作ったら仕様ごと無視されるだけだよ。 C++ はたとえ不格好になっても現実的であることを指向してる。 GUIなんて流行ですぐ方法論も見た目もかわっちまうからな 20年ぐらい前ならウィンドウに必ずクローズボタンがあるみたいなの 必須だったろうけど、今のGUI設計でそんな前提の設計したら 「脳味噌20年前でとまっとるんか」いわれるのがオチ スクロールバーとかもどんどん消えてるよな
まぁ上っ面をなぞるだけの平凡なGUIでもC++で規定してくれたら嬉しいけどねぇ OSによらず同じC++のコードだけで簡単なGUIを出せるってなると色々捗る気はする
>>469 初期のJavaみたいなのかな あれがC++にあったら、確かに便利だわな >>469 絶対駄目。 QtやFlutter、Unoなど、それを生業にしている民間業者がいるんだから、 民業圧迫になる。 >>472 C++ BuilderのGUIや、MFC、WinForms、WPFなども売り物だ。 それを統一してしまったら民主主義でも資本主義でもなくなってしまう。 もしそんなものを定義してしまったら、処理系を開発する会社が完全なる下請けになるじゃないか。
GUIやデータ構造に関しては現行はXMLに統一って流れじゃないかね 当然重くなるけど今はマシンパワーでカバーする感じ そのうちXMLパーサーがハード化されてストレスなくなるだろうよ
>>478 システムコール呼ぶだけなのになんで違うん? >>469 java の awt レベルでいいから欲しいですねえ C++標準でも外部でも良いから簡単な記述で簡素なGUI作れるようになってほしいなあ
ファイルシステムなんかは事実上ほぼ仕様が枯れてきてるから標準化できたけど この意味GUIはまだ枯れてないからな
>>473 中の人? 飯の種がなくなるから新しい技術を導入するなっていうのは流石に賛同得られないぞ エンドユーザーがC++とはアプリの外見のことだなんて誤解するようになるのはやだね
既存のどのGUIを基本にするかってだけで宗教論争起こすだろ
こいうのは一種の中二病だよね 実際やってみれば 細かい制御ができない大雑把仕様 か 大掛かりなオレオレ仕様で学習が困難 ってなるのがオチ おっさんになればわかる
可能性あるとしたらwebkitを共通仕様にするって線かな でかすぎるけどね
フルスペックのGUIフレームワークではなく、ちょっとしたテストやデバッグに役立つ程度の簡素なものでもあると嬉しいんだけどね。
規格を統一するとgcc/clangのような無料コンパイラと差異がなくなってしまうため、MSはC++を主流サポートから外してしまって結果的にC++は落ち目となった。 GUIまで統一したら、今度こそC++は完全に見捨てられよう。 そうなったらWindows支配も終わるかもしれないが、プログラマには大混乱が起きる。
>>495 GUI統一の動きがあっても、MSはサポートせずに、MingWだけがサポートする可能性がある。 Qtも自分のアドバンテージがなくなるのでサポートするわけなかろうし。 clangはAppleなのだからiOSやMacに支障を来たすためサポートしないだろう。 結果、gccだけがサポートする変な仕様として終わる。 それに、gccには既にGTKがあり、彼らの中では統一規格になっている。 それが彼らの中では世界標準である。
c++ってMSの主流じゃね? C#の方がおこぼれっぽい
またこのキチガイかよ… 連投する度に頭ん中に新しいお花畑でも作ってんのか?
Win10Update作成者本人もなんで領域がRAWになるかわからないとかいう更新入れたくないよなというか強制だし
WSL2だけ欲しいけど2004は怖くて入れられない
XMLは実際に扱ってみればわかるが 自由度が高すぎるが故にパーシングがめっちゃ重い 手作業で変更とかされるとなんだかよくわからない エラーで読めなくなることがあって難儀することが まれによくある タグで括るという無駄の多い構造のため必要な保存 情報のサイズに比してファイルサイズがやたらと でかくなる 等々ロクなことがない
boost::property_treeで使える範囲にしとくんだろうね。
N4713のD.8にuncaught_exceptionがあるんだけど、理由はなんで? >>379 が言ってたようなRAIIの話で if (uncaught_exception()) terminate(); else throw system_error{...}; みたいなことすんなってこと? XMLよりJSONのほうが容量小さくなるが、それでも今作ってるアプリではJSONも容量が大きすぎた けっきょくCSVに落ち着いたわ
>>477 ディスクやネットワークの速度は言語を変えても変わんない Perlとかの激遅言語だと差が出るかもだけど、数値計算しまくったりするシステムじゃない限りは、言語でものすごい性能の差はでない perlってpythonと比べたら10倍近く速くなかったっけ?
時と場合と環境とタイミングとプログラムとコンテキストによる
ティックルティーケーと読むのかと思ったら、ティックルチンコらしいな。 その後出てきたのはグレートチンコと読むんだってな。
>>511 JSONも無駄が多過ぎる C++ならmsgpack >>518 msgpackは直接人が読み書きできないから別物 個人的にサイズが問題になるならmsgpack使うよりzlibとかで圧縮するわ まともな実装なら[[deprecated]]付けてるでしょ
>>520 再入可能バージョンを使えってことね thx >>519 msgpackはキーが冗長で、結局圧縮が必要なんだよな テキストであることのメリットを捨てるにはあまりにも中途半端なフォーマット constなメンバー変数ならpublicにしてもいい?
後で実装を変更してその変数が不要になったらどうする? constだからといって不必要に実装を晒していいことにはならない あくまで教科書的にはこう答えるしかないが、あとはケースバイケースで判断せよ
メンバーにconstはあんまり付けないね static constとかconstexprにするときくらい 書き込みを制限したいなら、それこそ雪駄と下駄で細かく調節できるから
個人のコードなら全てstruct、全てpublicで良い 仕事、共同、公開コードなら周りにあわせる
全て自分のコードなら ポリシーがしっかりしていれば何の問題もない
そのポリシーの帰結がpublicかstructかということだと思うが 何も考えてないのと変わらない
個人的には、publicにするかどうかはユーザーがアクセスする情報であるかどうかで決めればいいと思うけど 外から見える必要があるなら公開すればいいし 変数で公開するのが気持ち悪ければIsなんとかのメンバ関数作るとか 逆にユーザーが触れる必要のない情報ならconstだろうが公開すべきではない
正直プライベートメンバーがヘッダーから丸見えなC++の仕様はいかがなものかといつも思っている
ヘッダ提供している時点でユーザーに見せたくないものではないよね 隠したいならもっと本格的にやるわ
でもjavaやc#みたいに一緒くたにされると、見辛いことこの上ない
>>535 それが分割コンパイルというものなのでは? templateでも長くなってきたら実装分けるだろ 普通はヘッダからさらにincludeするだけだけど、場合によっては分割コンパイルもする
>>536 そのためだけにインターフェース作ったりしてる 数ヶ月前の自分て他人だかんな なんでこんなアホなことしてんだとムカッ腹立ったりする
>>538 分けるべき時は分ける 分けたくない時もある その自由が無い >>539 分けるだろって 分けるべき時と分けないべきときがある >>539 ヘッダからインクルードするだけって まさかそれで実装を分けたと思ってる? 標準ライブラリが分けられてないのに どうやって分けるんだよ 使うテンプレートパラメーターがあらかじめ決まってないと実装を分けられないはずなんだが 実装を分けるってのは コンパイル単位を分けるってことな
C++のライブラリを更新するとき、新たなメンバ変数を追加するとメンバへのオフセットが ずれてバイナリ互換性がなくなるといいますが、これを無理やりどうにかする方法って ありますかね? 理屈上は、オフセットに影響を与えないメモリ位置に各インスタンスのメンバ変数を保持し、 参照、破棄等適宜すればいいと思いますが... ?? もしこれが可能ならば具体例とかを見たい のですが、うまく探せませんでした。
メンバ変数をprivateにして雪駄と下駄を用意する メンバ変数へのアクセスを常に関数経由とすることで オフセット等の物理的な条件で互換性が失われることを防げる つーか、ソースコードを変更してるのにバイナリを更新しないのはおかしいだろ Makefileのバグを疑うべき
>>548 普通に追加して再コンパイルさせりゃいいという話じゃなさそうなのはわかるけど 「無理やり」が暗に指していそうな制約も「どうにかする」の指す要件もわからない。 osの違いを吸収してるようなもんを作ってる場合 何でもフルチンで触らせるとそもそもの意味がなくなるわな
>>548 python の C module の造り方 >>548 COMみたいに、methodだけを外に出して、データは直接は外に出さないようにすればいい。 interfaceの考え方。 >>553 追加。 Win32APIなどの手法を真似る方法もある。 OSの内部構造が修正になってもAPIは互換性を保ててる。 やりとりのための構造体は先頭の方にバイト数を入れるメンバが用意されていて、 以後のメンバの後世が変更になった場合、構造体の末尾に追加していっている。 先頭にバイト数を入れることで、個々の構造体が変化したかだけの影響を受けるため、 ライブラリ全体のバージョンが変化しても全ての関数の仕様を入れ替える必要がなくなっている。 皆さんどうもです。状況は (以下、ライブラリ -> lib アプリ -> app) lib v1.0 リリース app v1.0 が lib v1.0 をリンクしてビルド、リリース lib v1.1 リリース(メンバ追加) <- 今ココ app v1.0 クラッシュ というわけで lib v1.1 を出すとき小細工して(でもメンバ変数相当を追加したい) app v1.0 のクラッシュを防げないか、ということです。 とりあえず lib v1.0 には impl メンバはないです。
>>555 pimplでバイナリ互換は保証できないよ >>556 インスタンスをnewしてるのがアプリ側だったら メンバ追加はほぼ絶望的 無理にやるとしたらメンバのアライメントの隙間に数バイトつっこむぐらい バイナリ互換とる場合はIFはCにするのが定石だよ (C++でやるなら上にあるとおりcomとかになって複雑になる) よくわかってないみたいだから頭下げてアプリにビルドしなおしてもらいな よく分からん libは兎も角、appはソースあるのが普通じゃね リンクしなおしている時点で、コンパイルからし直すのも出来るはず ヘッダのバージョン合ってなきゃそりゃ転けるわ
>>558 newの変わりに、仮想関数のCreateObject()というメソッドを呼ぶ方式があるね。 1. Pimplの場合: class CXxx { public: (メソッド群) protected: CImpl *pImpl; }; 2. 別解 使う側 : class CBase { public: virtual CBase *CreateObject(); (メソッド群) }; 実装する側 : class CDerived : public Base { public: CBase *CreateObject(); // 実際にはCDeriveの先頭アドレスをCBase*にcastしたものを返す。 (データメンバ群) };
>>561 その別解とやら、 CBase のインスタンスを得るためにはまず CreateObject() を呼び出すための CBase のインスタンスが必要になってて、無理じゃね? >>547 プロジェクトの範囲内ではテンプレートパラメータが数種類に限られることも多いからそういう時には明示的インスタンス化が利用できるよ >>549 ライブラリ って知らない? >>548 バイナリをいろいろなアプリで今後使う予定ならなるべく実装を隠そう 内部で実体の構造体なりクラスなりをnewで作って 外部に公開するクラスは 単にその内部クラスとのインターフェースだけ行う 後から機能を追加出来るように function(command, param1, param2) みたいな関数も用意しておく >>562 言われてみれば。正しい別解の1つは、 class CXxx { public: static CXxx *CreateObject(); (メソッド群) }; だね。 >>562 なにいってんだ 返すのはポインタだから実体必要ないだろ >>566 仮想関数呼ぶのには当然同じクラスの実体が必要 cloneなら仮想関数で実装できる >>565 すまん、こうでなくてはならなかった: 使う側: class CBase { public: static CBase *CreateObject(); (メソッド群) }; 実装側: class CDerived : public Base { public: (データメンバ群) }; CBase *CBase::CreateObject() { return new CDerived; } >>567 実体のあるクラスをアップキャストすれば必要ねぇだろバカか 何が目的なんだか その派生クラスのインスタンスを作りたいから、CreateObject呼ぶんだろ? 呼ぶ前に派生クラスのインスタンスが必要って、鶏と卵じゃないか
こっそりlib差し替えとか後が怖いなーと思いましたw
>>556 今あるメンバ変数の1個をポインタに置き換える ここに色々なデータが入った構造体のポインタを置く これで互換性を保てる ヘッダにオブジェクトの中身を読み書きするinline関数有ったら危険 inlineじゃなくてもtemplateだとヤバイ まあtemplateで実体生成されないように実装分離してたらセーフかな
ヘッダは基本変えない 不便ならポインタに置き換える変数1個だけ型と名前を変える あとはライブラリ側のコードのみ変更 アクセス関数を後から増やすなら クラスのポインタとパラメータをパラメータにしたグローバル関数にする 多少使いづらいが 互換性を考えて設計しなかったツケ
>>571 巷のOSとか、定期アップデートがかかるときにこういうので悩んだりしないんですかね? >>572 おお確かにそれでいいんですかね? まあ今後新たにライブラリを公開することがあるなら最初から気をつけようってことでw >>564 知ってます 当たり前でしょそんなこと! >>579 一から書き直せる条件じゃないんのおわかり? だいたい >>572 をpimplとは呼ばないでしょ 置き換えないメンバはそのまま見えてるわけだから あとpimpl論議は飽きた >>579 互換性を保つのが前提だから ヘッダは基本今のまま変更不可 っていう前提条件を理解してから書いてね >>580 書き直せないんじゃ、危険だけど>>572 くらいしかないんじゃない? そんな暗黒魔法使うくらいならapp1.0を再コンパイルする方法を考えるけどね。 ヘッダは変更するの前提じゃないの? バイナリ互換させるの前提なのだから
「メンバ変数の一個をポインタに置き換える」 こともヘッダを変更するのが必須になると思うのだが。
実装側でアクロバットするのは無理やりバイナリ互換させる旧バージョン対応の方で良い 新バージョンの中身にあわせてヘッダを更新しておかないと、負の遺産が延々と続くことになる
>>584 やり方次第。 privateのint変数やポインタ変数があるなら、キャストしてぶちこめばいい。 他の変数も似たようなもん。 バイナリ互換をはじめてかんがえた って感じの人が多くて驚く
pointerに置き換えたとして、指す先の実体の管理はどうするんだ 元々デストラクタが外部定義されてないと、デフォルトのデストラクタ呼び出しはinline化されてしまっている
いや、はじめからバイナリ互換させる前提で設計したライブラリでもない限り、小手先の対応でなんとかなる場面は物凄い限られるよ
メモリアラインメント調整等で発生する隙間を集めて変数として使う っていう手もある データ構造互換だとよくやる手法
>>590 そんなもん、GC実装して無理やりゴミ集めするしか無いだろ。 最後はアプリ終了時にOSが処分してくれることを期待するしかない。 バイナリ互換前提で開発されていないから、問題が出ているんじゃないの? appがコンパイルされた時点で、デストラクタやらコピコンやら代入やらをすべて明示的に外部定義していないと、コード中で必要に応じてデフォルトが呼ばれて、当然inline化もされてしまう
>>591 必ずインライン化されてるとは言えないけど、可能性はあるよね? 結局のところ具体的なコード要件を >>548 が言わない限りは不毛な気もする。 ライブラリを作った事がないヤツが ライブラリの互換性についてアドバイスしようとしてて笑える
? ライブラリ作ったことあるからこその内容だろうに GCするとか、リークしたままOSに回収させるとかそれこそライブラリとしてあり得ない対応だろう
デフォルトだとinlineのデストラクタが生成されるのがc++の仕様だろ じゃないと単なるプレーンな構造体でもデストラクタの呼び出しするはめになる
クラスをライブラリ化するのにメンバ関数がインライン? ご冗談を
バイナリ互換想定してないなら、inlineしない方が稀じゃね 全部外部定義だと、高速化の妨げになるじゃないか 世の中のc++用ライブラリを見てみれば良いさ inlineが無いどころかheader onlyが幅を利かせている
alignmentサイズの隙間に入れたところで、コピーの時にコピーされるかどうかも不明 と言うか、単体だとまずされない まあコピーも外部定義されていれば置き換え可能だけど
>>599 そもそもバイナリ互換を考慮していないライブラリを今さら何とかしようとするウンコな発想ありきだからな。 まともなライブラリ実装者なら 「そんなクソとっとと便所に流してマトモなもの作り直せ」 としか言わんわ。 inlineじゃないtemplateのヘッダオンリーでも、バイナリ互換保つの無理だよね 例えinline化されてなくても、各obj内で実体化されたtemplate関数が同一じゃないと何が起こっても文句言えない
明示的なinlineもだけど、定義せずコンパイラに任せた場合デフォルトで出来るものはinline扱いになる
なんでobj? ライブラリっていってるんだからlibだろ
インライン混じりのライブラリ ならメンバ変数を増やすのを心配する以前だろ 問題が変わってる
どうしても必要なことなら、 ライブラリの中にスタティックな連想配列置いて、thisアドレスをキーにして追加したいメンバ変数引くようにしたら? トリッキーでないし確実に動く
>>617 インラインかもよ コンストラクタもデストラクタもコピーも 追加したメンバ変数へのアクセスも ライブラリを使う(一部の)コードはコンパイル済みでリコンパイル出来ない コンパイル済みのコード内で使ってるクラスのメンバ変数を追加したい 当然 クラスのサイズは変えられないし コンパイル済みのコード内の(インライン展開されてる)関数も変えられない どの関数がコンパイル済みコード内にあって どの関数がライブラリ内にあるかは不明
ほとんど読んでないけどID:aCPUEpAOとID:Y+MR3z5Hがド素人なのはわかった
ヘッダの変更無しにどうやって新しい機能追加すんだよ
と思ったら>>548 が前提なのか、すまん とりあえずインスタンスそのままで扱うのは無理じゃね ユーザー側が一貫してポインタで扱うのは必須だと思う インスタンスで扱ってるなら暗黙定義された関数の動作が変わる可能性くらいすぐ気づけやド素人が
ポインタで扱うとインライン関数がリコンパイル無しで変えられるって?
ライブラリなんだから メンバ関数は全てライブラリ側で実装するだろ普通 テンプレートとか別途リンクが不要なことが売りなライブラリならともかく 何のためのライブラリだか
>>633 ヒント:仮想関数、コピー不可、Factory てかこの要件だと>>617 ですでに答え出てる気がする >>635 あれ? もしかして 互換性保持した修正はギブアップで 依頼者の要件を無視した案を言ってる? 外部から直接アクセスしない変数を置き換えるに決まってるたろ 連想配列だと 初期化順とかスレッド安全とかパフォーマンスとか 色々と心配だねえ
>>636 どこが答えだよ >>617 は無理だよ アプリ側でnew/deleteされたことをライブラリ側はトラッキングできない アプリ側でnew/deleteされてないのだったら問題になってない アプリに手を加えていいのだったらバイナリ互換考えなくていい >>643 新しいthis来たら新しく作るだけだろ deleteに対してはどうにもできんけど >>644 馬鹿かお前は ポインタで扱う前提に乗っかったのはお前だろ バカにしようとして自爆したのに逆ギレか コピーを使わない、もしくはインラインじゃないなら>>595 コンストラクタ、デストラクタ、コピーがインラインじゃないなら >>572 で良い new deleteはアプリ側でもライブラリ側でも問題ない コンストラクタはインラインでも>>572 で問題ないね インラインじゃないならって、普通コンパイルオプションやnoinlineで指定してない限り、 実装が見えているメンバ関数は全てインライン展開はされうるんだぞ そんな厳しい前提がOKなら>>645 で言ったdeleteの問題だって対処できる >>572 と>>617 デストラクタがインラインだとダメなのは同じ コピー時の制約も同じ 速度、スレッド安全性、初期化順などの心配事に関しては>>572 の勝ち >>572 は外部からアクセスしていないポインタサイズの変数の存在が条件 >>651 ヘッダにない関数はインラインにしようがない デストラクタ問題に対応出来るのは今のところ>>595 だけ 暗黙定義のものが一つも無ければね (=ヘッダに宣言はあるが実装は見えないものだけ てか別に>>617 じゃないといけないとは言ってないが >速度、スレッド安全性、初期化順 速度が必要とか一言も書いてないし スレッド安全性て、連想配列使うのはライブラリ内だけなんだからライブラリ側で対処すればいいだけ >>655 ユーザーが使ってない変数や領域に新しいメンバを含む構造体へのポインタを入れる案も 根本的には連想配列案と一緒だよ、デストラクタが非インラインでなければ解放できないぞ まぁ今ある情報だけで議論してもどうにもならんが コンテナやスマポなど、コピーやデストラクタで処理される物の中身を少し大きくするとか close()みたいな最後に必ず呼ばれる関数があればそこに入れ込むとか 中身がわかればもっと別の案も出るかも
>>656 速度が必要と書いてなければ速度無視が前提って... なかなか衝撃発言ですねえ C++なんだから組み込みのチープ環境かもしれないし リアルタイム処理かもしれないし もしかしたらISR内部かも (ISRならnewも問題になるか) 速度がどうでもいい用途でいまだにC++を使うって どんな業界かな? 不変のアブストラクトクラスを作っておいて 実装はそこの派生クラスでやり 使用者はポインタで使う
>>663 冴えてる! いつもすてきなはちみつさんですね! よーし、みんな呼んじゃうゾ void君、rubyガイジ、jquery房ーっ
∩___∩ | | ノ\ ヽ | / ●゛ ● | | | ∪ ( _●_) ミ j 彡、 |∪| | J / ∩ノ ⊃ ヽ ( \ / _ノ | | .\ “ /__| | \ /___ /
今時のmodern c++で、マルチスレッドやるにはどうすればいいでしょうか。とりあえず今はC++17でコンパイルしてますが 1.c++20のコルーチンとコールチンライブラリを使う 2.固定スレッド数のスレッドプールなら簡単に実装できるので自分で実装、もしくは素敵なライブラリがある? 3.std::thread,std::asyncでいいや
>>675 std::threadとOpenMPが基本かな。 とりあえず、MSVCを使ってます 1は時期尚早? 2はMSVCだとTask Parallel Libraryがあるけど、プライオリティキューを使いたいとなるとやっぱ自前? 3はね 皆さんはどんな感じでしょうか
タスクの実行を(優先順位付きで)スケジュールしたり、キャンセルしたりしたいです 非同期処理? なんてイエバいいのだろう
MFC Windows API std::thread どれでも出来るけど 求めるものは? 性能?作りやすさ?移植性?
まぁ、windowsにはwin32でthread pool apiがあったり、ATLでCThreadPoolクラスみたいのがあるっぽいんですが、昔より今時の方法で.. 性能はあんま気にしてません 作りやすさですね
性能はあんま気にしてませんが、テスト的にstd::threadで今は実装してますが、セマフォなりで全く制御してないのでCPU使用率がはねあがって、セマフォで制御するくらいならスレッドプールくらいは導入したいなと
>>684 優先順位付きとかやると色々自前が楽かなぁと思ってたんですが、やっぱ自前ですか ありがとうございます msvcならasync使えばthread pool使われてたような async|deferredでは問題ないけど、asyncのみだと仕様的にアウトっぽいから将来的に修正されるかもしれんが
プライオリティキュー 自体を既に使ってるなら 待つ仕組みだけ追加すれば良いのでは?
while (1){ イベント待ち イベントクリア キューから取得 処理 } ---- キューに追加 イベントセット
>>687 そんなこんなこと書いてありますが、std::asyncってdetachできないですよね? こういう作りがいいのか知りませんが、基本UIスレッドから非同期処理実行して完了したらWinAPIのPostMessageで完了通知してます ので、std::threadみたくdetachしたいのです >>689 プライオリティキューはこれから実装するんですが、単にstd::set使ってlessパラメーター指定すればできあがり?とはいかない? while (1){ イベント待ち イベントクリア while (キューから取得){ 処理 } } ---- キューに追加 イベントセット
こうだった std::set / less 同じプライオリティがダブらないならこれでも
プライオリティはダブルんですけど、要素がプライオリティじゃなくて、プライオリティと例えば実行するstd::functionのペアで、このペアオブジェクトがダブらないはず
>>693 同じfunctionが複数セットされても 実行が1回になってもいいなら それでいいんじゃない? >>695 unordered系しか本格的に使ったことしかないんですけど std::pair使わずに独自ペアオブジェクトじゃだめそうだな.. std::pairをstd::shared_ptrでラップすればOKそうに見える lessもプライオリティとfunctionのペアってことね 同じプライオリティの処理が キューにセットした順にはならなくなるけど 個人的には キューにセットした回数分実行するために multisetにしたい
プライオリティが多くないなら ブライオリティ別のdequeにすれば 公平性は保たれるし比較も不要
あー。multisetでいいですね。それにします。 ありがとうございます
>>675 C++17ならstd::execution::parが使えるぞ C++17を指定する#pragmaない? gccかclで
本当はC++17をデフォにする設定とかあればいいんだけど 探しても見つからんかった
「現行規格」をデフォにできねえのおかしいだろ 作業が必要でも構わんが方法がないのは
エイリアスしたらだめなの? 全然見当違いなこと言ってる?
Makefileか*shrcにでも書いておけばいいだろ…
普通の人 オプションないのはおかしいだろ →あるはずだから探そう
GCC なら specs に書いておくという方法もあるよ。
GCC 11からデフォルトで17になるよ やったね
C++で作られているモダンなマテリアル風デザインのWindows用デスクトップアプリのソースを見ると Direct2dやGDIを駆使して自前で描画していたのですが、ここまでしないといけないものなんでしょうか…?
ソレがイヤなら金だして買え C++BuilderやらMFCやら色々あるぞ
コンパイルオプションであるのは当たり前だけど それだとソースとmakefileみたいに別管理になる ソースにコメントでC++17以上とか描くくらいなら 最初からpragmaでC++17以上指定とかしたいって 自然な要求だと思うけど
>>714 別にそこまでしなくても良いけど自前描画は割とメリットも多い Win32のコントロールって一つ一つは割と大きなオブジェクトだからね それを省いて絵だけで完結させると驚くほど軽くなったりする WinFormsに対するWPFの発想がこれ ただしWPFは抽象化に抽象化を重ねた結果、返って重くなってしまったという産廃だが >>716 元の質問者は引数じゃいけない、エイリアスじゃいけないとは一言も説明してないのに、回答を無視してできないのはおかしいとか言ってるから、はあ?できるだろって叩かれてるんだと思うが。 あと、プリプロセッサで指定バージョン以下のコンパイラを使ったときにエラーにすることは今でもできる。 >>716 指定して何をしたいんだ? 17に対応しないコンパイラを使ったら排除したいのか? そんなもんマクロ使えよ そもそもpragmaは無視しても問題ないんだぞ こんなもんで17指定してなんの意味があるんだか
static_assert(__cplusplus >= 201703, "C++17 or later only"); これだと、せっかくC++17できるコンパイラなのにエラーという愚かなことになるだろ #pragmaとは言ったけど、has_includeみたいな標準に何か追加でもいいんだけど
またABIか変わるかもしれないのにソースファイルごとに勝手にコンパイラが変わったら困るんじゃないの?
そりゃ意味ないからな configureに準拠規格オプション探すマクロ1つ入れとけば済む話だし
// this program is C++17 と書いて手作業に期待するのを #pragma C++17 で自動化するのは意味がないと言うのか? 自動認識はそう珍しい話ではないと思うが
今でもconfigure.acに AX_CXX_COMPILE_STDCXX_17 って書くだけで済むから
他人に巻くプログラムならビルドパッケージでどうとでもなるし 自家用ならmakefileにオプションまでベタ書きでいいし 何にこだわってるのか知らん
プログラム1つのためにGCCをわざわざビルドしろだと? おちょくってんのか
素人はあれこれツール使いこなすのいやなんだよね わかる
>>732 え? 自分で作ってるプログラムのconfigure作るときのはなししてんだけどwwww 今ある機能でどうとでもなることを 将来搭載されても後方互換性がなくて結局今ある機能に頼る羽目になる新機能をつけろつけろと騒がれても困りますよw
>>736 すまん、俺はイウォーク語はわからん 日本語でしゃべってくれ configur.acといわれてgccをビルドするとか思っちゃう人はヒューマンステージが低いのでもっと修行してくださいwwww
ウェブ系の人にはなじみが無いかもしれないけど、C/C++のライブラリってバイナリだよ。
>>729 Makefile なりなんなりで別管理になることを問題だと思ってるのはあなただけ。 具体的に何がどれだけの問題なのか、よく考えて示してくれないとたぶん伝わらない。 単に面倒だということなら、多くの人は新たな #pragma の仕様を定めて実装するほうが面倒だとわかるので、 それがあって当然だなどという主張にはならない。 コンパイラは対応する仕様決まらないままファイルの読み込み、パースをしなきゃいけないわけ? 必ず先頭行に書くとかなら未だしも 途中で現れたらどうするの? 引数で指定されているのと矛盾したらどうするの? 複数異なる指定があったら?
>>746 Perlのソースコードをjavacでコンパイルする事はない。 ということは、言語をソースコードの属性としたほうが良いのでは? という考え方は理解できるかな。 一概に否定しない。 とはいえ、C++ではどっちにしろビルドシステムが必要なので、ソース内で指定できることに意義を感じない。 メンバ関数定義の際にクラス内の型名を使った戻り値型を先に書く場合、クラス名::戻り値型 って書かなきゃいけないくらいパーサに配慮した仕様になっているのに、そんな面倒くさい要望に対応されるとは考えにくい
自分で作ったならバージョンわかってるやろ ライブラリとして配布するならpkg-configでも書いとけばいい 何が問題だよ
拡張子で分けるのが一番自然だよね xxx.cc17とかxxx.17.ccとか
標準のバージョンなんかよりたくさん環境依存あって それを自動解決する方法はいろいろあるのだから それを使えばなんの問題もないんだよ
ライブラリとして配布するのに C++17を要求するって 使ってもらう気無いだろ
ライブラリを使ってくださるお客様にC++17を用意させるのは心苦しいかもしれないな。
今時c++17必須でも大丈夫だろ msvcですら使い物になる程度まで対応しているんだぞ
組み込みのほうがwindowsより規格対応早いくらいじゃね まあ全部は使えないけど、それは03だろうが同じだ むしろコンパイル時に出来ることが増えた分組み込みには新しい規格のほうが向いている
小規模だとコンパイラ使えるだけでも御の字 コア部分は結局アセンブリで書くし そもそも自由にスタックすら使えなくね?
>>746 あなただけって他の人が支持しているレスも出てるよ? 自演だろって言うんだろうけど違う マウントしたいんだろうね >>756 その言葉をそのまま返す ARM以外の何かをやってる人? >>741 737の突っ込みは見なかったことにしたいんだよね 目的がわからなすぎて、始め何をしたいのかさっぱりわからんかった。 答えがでるたびにゴールを動かされてる気分だったわ。 コミュ障のID:qK+Va6mVが全て悪い
まあ一通り意見が出そろったと思いますが、ISO/IEC 14882:2023への提案は、今回は見送らせていただきたいと存じます。 また何かありましたら、スレのほうまでご連絡ください。
K&Rしか解さないコンパイラのためにプロトタイプ宣言したコードの先頭にCのバージョン書くか アホらし
範囲for文でコンテナを走査するときに要素を参照で持つかどうかふと迷った それがパフォーマンスに影響するなら当然実測するべきだが、大概こんなもんが律速になるわけないからどっちかに決めときたい 要素を変更するなら参照、そうじゃないなら参照じゃない、でおk? ちなみに型は指定するよりautoにした方が大抵の場合速いみたいな話あるよね?
質問なのですが自作アプリをソースコードでGCCをビルドして配布する場合、 テストってどうするの? あらゆるGCCのビルド条件でテストするの??
>>779 auto&& にしておけばだいたい良いよ。 >>779 レジスタ1個で収まる型ならコピー そうじゃないなら参照 書き換えないならconst参照 >>780 あらゆるなんか無理に決まってるだろ 人のまねしろ 他人のgithubとか見たことないのか? >>780 僕はclang-cl、cl、gccで各Release/Debug、計6種のバイナリを作ってテスト通してますよ。 実際、通らないことが稀にあるので、そうゆう手順になりました。 とはいえ、ミスをしない人なら、必要ない事かも。 テストも必要ないかもしれない。 >>784 デスヨネー; ていうかソースコードで配布したものをユーザーがautomakeでGCCをビルドする文化とか ソフトウェアー工学的に正しくテストされてるうちに入れることが本当に可能なの?? とそこはかとなく疑問が、 もはやautomakeでGCCをビルドするレベルになると、 事はソースコードを書いた人の品質にとどまらず、 ユーザーがどのような経緯でインストールしたかわからない 野良ライブラリとか野良コンパイラの品質が絡んできてしまうま、
まあしかし結局#pragmaはないってことね 最初の質問には答えて貰えたようだ みんなありがとう
いやそれは勝手にするさ 俺の状況をいちいち知らんやつに わかってもらう必要もないし
そもそもコンパイラは後方互換性を気にしていれば良くて 過去のコードがコンパイルできる、古い記法なら古いよとメッセージを出して終わるまでやれば良くて 将来変わるであろう規格に備えて私の知らない規格ですよと教えてあげる必要はなくエラーで落ちればそれでいい
恰好つけたいんなら余計なことは言わないほうがいいぜ(クスクス
あれは何かおかしいのか? おまえの頭のほうが(ry
>>795 無知を指摘されただけのことを自分の事情的に言い訳して謎の上から目線へ変換してるのが頭悪すぎでしょw いらんものを使わんのを無知とか大きなお世話なんだよ おまえだっていらんものは使わんだろうが、それも頭が悪いからか? いちいちひっ絡んでくるのは何かよっぽど悔しい思いしてるんだろうな 俺は最近あんまり誰かをコテンパンにやっつけた憶えはないんだが 何か気に障ったのか?
ずーっと前にシバイたったやつがまだ根に持ってるのかな だとしたらキモすぎ
他人に教えを乞うておきながら やあご苦労的な上から目線でまとめるバカwww 匿名掲示板で根に持つも何も、一体お前誰だよwwwww バカってホントwwww
正体わからない場所で根に持たれてると思うってことは 同じようなことを繰り返してるんだろ? 無知を晒して指摘されてるのになんか偉そうとかwwww あるいはココロの病気かwww
787のどこが上から目線なんだよ 言いがかりはやめてもらおうか
散々罵倒しといてこれくらいで許したるわとかいうメダカ師匠になってるんだよwww
>>802 説明しろよ できないならおまえもヤバイぜ >>805 煽って他人に教えを乞うスタイルはお前だろwwww いーや、思い当たる節が全然ない >>802 説明しろよ できないならおまえもヤバイぜ 早くしろよw 匿名掲示板で根に持たれてる自覚があるとか相当ココロの状態やばいよw
キモすぎつってんじゃん >>802 説明しろよ できないならおまえもヤバイぜ 早くしろよw >>807 一連の流れであの態度 頭おかしいでしょw それがわからないなら人間関係やばいw >>810 やーい説明できねえ ブーメラン痛そうだなw 次におまえは「ブーメランなんか刺さってないから痛くない」という 目にうるうる涙をためながら pragmaのアイデアを思いつくこと自体はまぁいいと思うけど >>747 の指摘受けたら、この仕様は駄目なことわかるよね なのにそこでやめずに強弁続けておいて最後に >>787 はずっこける なんか他の#pragma使ってなさそうだね ルールを途中で変更する#pragmaは珍しくないんだが
まだ何がダメなのかわかってないらしい しかし途中でコンパイラ切り変えるのは画期的だわw
ID変わったけど話し方が酷似している さては、またあいつか
go は // コメントに描いてあっても反応するから怖い
BOM付選んだコンパイラもあるし コンパイルオプション選んだコンパイラもあるけど ソースの先頭のエンコード選んだコンパイラはないんだっけ
>>751 なるほど .o32とか.o64とか .c32とか.c64とかな ISO/IEC14882は3年毎に改訂されることになっているんだから 今後は定期的な改定に備える計画もあって然るべきだと思う
何がいったいわかったのだろう それに勝手に他の人を認定してるしwww 相当ヤバいわw
推測と認定の区別がつかないやつ 実社会でも不自由してそうだな
あわよくばまぐれ当たりを狙ったようなテキトーな言葉遣いをするやつ 迫力ねえんだよ
では何がわかったんだ? ああ? 喧嘩に負けて上から目線の捨て台詞にしか見えねーんだよw
ほらな 心当たりのあることを咎めてこないから全くダメージにならない 何かイヤミを言ってやろうという意図だけはわかるんだが滑りすぎ
ここでいつも似たような喧嘩をしている二人って毎回同じ奴らだろう。 なんだかんだ言ってお前ら仲良いな。 他のスレ住人に見せつけてくれなくていいから、よそでやれ。
そういえば俺にひっ絡んでくるやつ 話し方というかアホさが似てると思うことはちょくちょくある
>>827 787がメダカ師匠になってることがわからないようじゃどうしようもないよw >>747 先頭行に書けばいいだけだろ まあ使い勝手を考えてコメントを除く先頭行に書くようにすればいい > 途中で現れたらどうするの? エラーにすればいい > 引数で指定されているのと矛盾したらどうするの? どちらを優先するかを決めておけばいい > 複数異なる指定があったら? エラーにすればいい よくある処理だしなんの問題もないけど? C++使いにしては低能過ぎるレスが多いな。 どういうことだ。
>>782 プリミティブ型ならレジスタに乗るって思って良いんですかね? >>836 構造体型/配列型以外のデータは原則的にレジスタには乗る。 ただし、参照と直値のどちらが効率が良いかは、レジスタに乗るかどうかだけで 決まるわけではない。 1個のレジスタに乗らなくてもレジスタ数個分ならコピーしてしまった方が 参照より速くなる場合は多い。ケースバイケースだが、レジスタ5個分とかでも コピーした方が速い場合もある。 >>836 ケースバイケース 普通はそんなことを気にする必要はないし気にする必要があるなら処理系のドキュメントを読め >>837 みたいに憶測で語ってる奴は無視しておけばいい >>841 読んだから、高速化のためには、レジスタに乗るかどうかだけで決めるべきじゃないので正確にアドバイスしたが、あなたが理解できないだけだよ。 >>842 参照を使った場合、参照を介してのメンバアクセスにはコストがかかるので、 むしろ最初にコピーした方が高速になることがあるんだ。 文字列データや、巨大なバッファを持つようなものはコピーしてはいけない。 それは速度だけじゃなく、無駄なメモリー領域の確保まで必要となるため。 もしメモリー効率度外視して、バッファ確保の時間も0だと仮定してよいなら、 大きなデータであっても、参照を介してアクセスするよりもコピーした方が速いことが有る。 ただし、その場合にはキャッシュを超えない程度の場合は、という条件が付くことになる。 引数受け渡しがクリティカルになるような状況ならinline化するかipo最適化するだろ 値だろうがconst参照だろうが、最適化されれば違いはなくなる
おまえらは王者の風格が足りない。 偽C++使いめ。
>>844 >値だろうがconst参照だろうが、最適化されれば違いはなくなる ダウト >>842 いや安価先をよく見てくださいよ あなたは僕のリクエスト通りに「大概」の回答をくれたから感謝してます 違いはなくならないこともあるが 普通は無視していい パフォーマンスが非常に重要なループなら 想像で語らないで実測が基本だし コンテナのメンバ関数経由でアクセスすることも疑問に思わないと
コピーは非常に時間がかかることもある 構造体やクラスのちょっとした変更で後から増えることもある 参照は極端に速度低下することはない 確実にコピーの方が速い時だけコピーにしておいて 不明な時、判断が面倒な時は参照にしておけばいい 私の中の基本ルールが>>782 最適化が必要なら 参照かコピーかだけにとどまらないもっと大がかりな事まで考える 2択だけなんて事はしない アホみたいなチューニングが必要なら、そもそも範囲forを使うのやめたら? 直感と異なるかもしれんが、未だ普通のforのほうが早い。
アホみたいなチューニングってのが意味不明だが 必要ならやらなきゃならん コンテナ経由ってのがそもそも遅くなる要因 直接ポインタで扱う方が当然速度は期待できる >>782 みたいな基本ルールって それぞれ自分の中にあると思う それを外れる最適化がヒツヨウニなるのは極めて稀 稀であったとしても必要な時はある inline化してたらコピーが速いなんて事象は起こり得ないだろ
社内報にアウトライン化による高速化事例が載ってましたが。
>>845 うわー、すごい王さまだー。 でもなんで、はだかなの? >>840 自称高速化の専門家とやらの妄想は要らんよw >>841 自分一人でコード書いてるならテキトーに決めとけ チームでやってるならコーディング規約に従え 他称なら兎も角、自称の専門家って他のことは分かりませんって意味でしかないよね
高速化の基本はアルゴリズム、データ構造 その辺の専門家が参照かコピーかみたいな小さな事を気にするのかな? どんなコンテナとか無視して
他に「夏本番、キラキラ☆コーデ」というのも載ってたけど、関係なさそうだったんで読んでません。
>>854 分岐予測 キャッシュ 関数ポインタ 私がすぐに思い付くのはこのくらい コーディネートではなくコーディングの略ということはもちろんわかっています。 とはいえ、意識の階層が違いすぎて、「あ、これ関係ねーやつだな」って。
あ、そういえば。 インライン、アウトラインで思い出したんだけど。 むかしツタヤでDVD探してて、カシラモジ・・・カシラモジ・・・ってカ行探してたんだけど無い。 つぎイ行探しても、あれ??無いわ??ってなった。 で、ふとア行見たら・・・アタマモジかよ・・・ありました。
高速化の専門家って当然ハードわかるよな わかる、つーか皇帝レベル
>>865 オブライアンはアイルランド系の苗字ですね。 >>870 いろはにほへとです。 無理やりすぎますかね。 >>828 俺もちょいちょい喧嘩してるけど今回関係ないぞ 浅はかな推測が外れまくったという 珍しくも何ともない現象だな
std::vectorのstd::shared_ptrを返すメソッドGetHoge()があるのですが、 for (auto e : *GetHoge()) でループすると要素があるにも関わらずループしません auto t = GetHoge(); for (auto e : *t) とするとループします これは何か違いがあるのでしょうか?? MSVCです
msvcならeとかtにカーソル合わせればどういう型になってるかかわかるんじゃないの
>>876 さんの質問への直接の答えじゃないけど、 typeid(e)::name() とかで auto の解釈を見れば何か分かるんじゃないかな。 特定の場合に auto はどのような型を生成するか、っていう 一般的な情報って言うか規則もどこかで見られるのかも知れんけど。 >>876 範囲for文の中ではauto&&の参照で範囲オブジェクトを束縛してくれるんだけど 上の場合は束縛されるのは*GetHoge() (=中身のvector)であって、GetHoge()の戻り値そのもの(=shared_ptr)は束縛されない なのでshared_ptrはループに入る前に破壊されてしまって、参照カウントが0になると中身も破壊されてしまう 下の場合は戻り値のshared_ptrをtで確保してるから大丈夫ってこと C++はますます書いてあることと動作の関係を掴み難くなりつつ あるな!
>>876 最初の書き方の場合、GetHoge() の戻り値は、一時オブジェクト。 一時オブジェクトの生存期間は、その部分式を含んだ完全式の終わりまでとされている。 GetHoge()が書いてある場所は、for ブロックの開始時に、最初に一度だけ評価されるが、 完全式としては、その時点で終わっている。 だから、関数戻り値の一時オブジェクトの生存期間は、forブロックに入る直前に終わってしまう。 戻り値の型は、shared_ptr<vector<T>>で、この中身を参照している shared_ptrが全て 消失した時点で中身まで deleteされる。 そのため、forブロックの中では、もはや、vector<T>が削除されてしまっているということらしいね。 2番目の書き方の場合は、shared_ptr が変数 t にコピーされているので、参照カウンタが1つ分残っている。 そのため、それが指している vector<T> のメモリブロックも削除されずに残っている。 というわけで、ループしているのに結果がおかしいというのは分かるが、全くループしない理由は余り分からない。 というか>>881 の指摘通りの場合、GetHogeで初めてvectorを生成してるか 自身を元に新たなshared_ptrを作って返してることになるんだが だいぶおかしな設計じゃね? >>883 クールパルルパクルリンパ(); ←関数 >>884 ちょっと間違ってる 範囲for文はここで書いてるように「同等な書き換え」がされて、範囲オブジェクトはここの例で言うauto&& __rangeに束縛される https://en.cppreference.com/w/cpp/language/range-for そして、__rangeに束縛されたものが一時オブジェクトであれば、参照束縛による寿命の延長でforブロックの終了まで生存する だからこういうのは問題ないのよ for(auto a: std::vector<int>{1,2,3}) あと最後に関しては破壊されたvectorを使っちゃってるから未定義動作で何が起きても文句は言えない メチャメチャな値を取り出そうと、全くループしなかろうとその時の気まぐれよ >>886 同意。Getという名前は不適切だな >>89 こんな機能があったとは: Temporary range expression If range_expression returns a temporary, its lifetime is extended until the end of the loop, as indicated by binding to the forwarding reference __range, but beware that the lifetime of any temporary within range_expression is not extended. 昔はC++は複雑怪奇、C#はシンプルで分かりやすいって感じだったけれど、 今はC#の方が仕様拡張で複雑になってきて相対的に大差なくなって来てる気がする
いろいろ考えたらC++にあるアレが必要になったんだよ アレだよアレ わかるだろ
本来標準ライブラリーで済むものまで言語仕様に入ってやがる それというのも標準ライブラリーがしょぼくてかつ改善が入らん あっちはだれがやってるんだ
皆さんはありがとう御座います GetHogeは実際はEnumHogeで内部でstd::shared_ptr<std::vector>を生成して返すメソッドです 一時的なオブジェクトで書き方の違いで結果が変わるなんて知りませんでした とりあえず、変数に代入します
>>889 >参照束縛による寿命の延長 これは、ranged for 以外でも、一般的に働く機能ですか? C++ 11から有りましたか? それとも最近入りましたか? ていうか >>889 >あと最後に関しては破壊されたvectorを使っちゃってるから未定義動作で何が起きても文句は言えない >メチャメチャな値を取り出そうと、全くループしなかろうとその時の気まぐれよ mjd?! { auto t = GetHoge(); for (auto e : *t) { ... // (A) } // (B) } ならt(GetHoge()が返したshared_ptr<vector<T> >は(B)になるまで生存するから (A)において*tの要素を参照する(auto &&)することは全く問題無いんじゃ… 訂正orz, 誤: (B)になるまで生存する 正: 少なくとも(B)になるまでは生存する(参照カウンタが0より大の状態を保つ)
ていうか>>889 の「最後に関しては」は実は >というわけで、ループしているのに結果がおかしいというのは分かるが、全くループしない理由は余り分からない。 (>>884 ) を指していたりする? だとしたらサーセン;。n_ for文のイテレータがvectorを指しているのに対して、vectorを保持するshared_ptrの破棄タイミングは確かに forの前でも後でも有り得るヨカン、 C++は局所的に動作を想像できない場合が多いのがなぁ。 バカじゃなけりゃマクロ使いまくったCコードも理解できるかというとそうじゃないだろうと。
もっとも >for (auto e : *GetHoge()) { ... } このコードで動作が不定(未定義動作)になるのはGetHoge()が返したshared_ptrの参照カウンタがきっかり1だった場合であって、 2以上だったらきちんと回るんジャマイカ、 そう考えるとなかなか>>876 のお題は味わい深い… >>900 どう? 腐った代入オペレータかかれるだけで悲惨なことになる
(上の話に限って言えばvector<T>のTに間してどれだけ腐った代入オペレータが定義されていようとも) 別に
>>903 おまえ頭悪いなって 俺が何の下支えもなく言う場合と同じだ 俺は瞬間でもないが落ち着いて追えるケースでしかない おまえさんは絶望感でも持ったのか? しかしまあ歳は取りたくないと思ったな 全盛時の俺にはありえんことが相次いで起きている一例だった
C++のラムダって、Javaとかみたいに1文だけの場合にreturn省略できないんですかね? [](auto a, auto b){ return a + b; } → [](auto a, auto b) { a + b } みたいな感じで。
今はムリ 検討はされてるから将来的に出来るようになるかもしれない
>>907 この程度のことが落ち着いて追わねば分からないというのは 藻前は衰えたのだ Rust に慣れてくると C++ で return を書くのを忘れることもある。
>>910 ありがとうございます。C++23ぐらいを期待します >>895 てか結果を返すだけなのにスマポに入れるとか、 呼ばれる関数が結果をどのように管理するかにまで口出しするのはどうかと思うけどね >>911 my powers are weak old man. 非バカの要件にコード見た瞬間最初から全部ワカルというのが入るということは >>894 で宣言して合ったのに対し別段オブジェクションをつけるでもなく >俺は瞬間でもないが落ち着いて追えるケースでしかない とだけ言ったのだから彼は自ら非バカではないと告白したのである 漏れの有り様の批判に繋げられても困る >>895 です >>915 でも、スマポに入れないで返す場合、例えば、受け取った側で他で色々使いまわすから受け取った側でいちいちスマポ作る ってことでしょうか?? というか、一般的なライブラリ作る場合どうすればいいんでしょうか?? std::shared_ptr<std::vector<YYY>>XXX::EnumYYY() とりあえず、スマポでくるんで返してあげれば受け取り側でいかようにもできるからいいのかなと思ってるのですが。 std::vector<YYY>で返して std::vector<YYY> XXX::EnumYYY () で、受け取った方で他でスマポにしようということで auto yyy = x.EnumYYY(); auto ptr = std::make_shared<std::vector<YYY>>(std::move(yyy)); とかやればオーバーヘッド少なくスマポ作れるんです?
記憶管理という本来隠すべき実装の詳細(と多くの人が考える事柄)を 使う人が意識せねばならな続けるのは嫌すぐる、
getterがshared_ptr<T> pを返したとたん、pの寿命と*(p.get())の寿命の二重管理の責務が利用者に行く >>876 の真の原因はこれ getterがオブジェクトのディープコピーを返したらそんな二重管理は生じないで済む getterが仮にオブジェクトXの参照を返す仕様だとしても、Xの実体を保持するオブジェクトのY寿命と getterを呼ぶタイミングの二重管理以上の手間にはならない 結局shared_ptr<T>を返すインターフェースは不恰好さだけが残る >>921 *(p.get()) の寿命は p の寿命と同じかそれ以上という関係であって別で管理できるものではなく「二重管理」にはならないでしょ。 この関係がある状態で *(p.get()) の寿命を期待しているところで p の寿命を保持していないのが >>876 の間違い。 本当に所有権の共有が必要ならあり得るインターフェースだよ。 でも >>919 を見る限り所有権の共有は必要なかったみたいなので、素直に std::vector を返せばいいよ。 >>922 2行目で述べている、利用者がしくれば危険性が生じるという事実と 1行目の「「二重管理」にはならないでしょ」という主張は矛盾してねえが、 本当に所有権の共有が必要ならshared_ptr<T>を使うのはアリだが、shared_ptr<T>が保持する Tの実体のみに興味がある利用者に対してはshared_ptr<T>を使っていることを クラスUで隠蔽する方が良い Tが持っている演算を全てクラスUからTに委譲し、UをT同然に使えるようにするのがbest そこまでやる手間が嫌という理由でUにTを返すメソッドU::get()を備えさせる簡易手段に訴えたとしても、 Uの定義だけ見れば循環参照にならないことをUの提供者が保証できるから (Tがジェネリックな型だった場合の)Uの利用者やプログラム全体のメンテナーに地雷原を歩かせずに済むメリットがある ちゅか明白すぎて激しく書き忘れたが、オブジェクトTのグローバルな所有権の共有が必要な場合、 shared_ptr<T>が保持するTの実体へのアクセスの排他制御を行わねばならないが shared_ptr<T>はこの点なんのサポートもしてくれない(せいぜい自身が使う参照カウンタの排他を行うだけ なので、Tの排他はshared_ptr<T>をwrapしたクラスUが行う必要があり、かつ行えば十分 この点一つとってもクラスUを設けずshared_ptr<T>をTの利用者に直接返す設計のダメさ加減がワカル gdgdだ、
>>921 の通り getで実体を返すのが一番 これを管理方法はgetする側が決めれば良い コストが重要で オブジェクト内部のvectorの参照やポインタを返す場合はその寿命はオブジェクトと同じで良い >>917 おまえさんはまだこっちの質問に答えてないぞ 絶望感でも感じたのか? shared_ptrを使ってるのにディープコピーとか言い出してて 相当テンパっている様子は窺えるのだが 漏れの心の内面がC++の規格に反映されているわけでないのだから 聞くだけ無駄くね?
>>926 ようわからんが、>>921 がディープコピー云々言ってるのは、ようするに実体を返せってことでないの? てか俺が管理云々言い出してややこしくさせたかもしれんけど 俺もこの場合vectorそのものを返すべきだと思う、実体を返して解放忘れでリーク、とか有り得ないんだし(何のためのスマポなのかをよく考えるべき スマポ大好きで何もかもスマポで扱いたいんなら別だがw なんか…… 戻り値をどうするかは戻り値の所有権&管理責任がどちらにあるのかを表しているんだから、「必ず実体を戻すべき」とかいうのは考え足りないだろ。 >>918 ならshared ptrかunique ptr(所有権を譲渡する場合)で返すのは普通にありえる。 >>924 みたいなのはshared ptrの所有権を侵して実体を破壊しているわけだから、そのコードを書いたやつをぶん殴るべき案件。 そもそも規格的に未定義じゃないの? >>929 >「必ず実体を戻すべき」 俺はそんなこと言ってないけども shared_ptrのshared_ptrの(無限ループ)でも返せというのか >>885 を読み直せ、結果を返してるだけなんだぞ? しかもそれで参照カウントがゼロになるって言ってるんだがw 意味わかるよな? 参照カウンタがゼロになることから getのたびにvectorを作成しており その管理を呼び手に委ねてることがわかる こんなものは素直に実体を返せば良い 呼び手がスマポで管理することも出来るし 特に管理せずスコープを抜けた段階で自動で破棄することも出来る
内部で管理してるオブジェクトの見せ方は色々あって難しいけど 今回の場合は新しく作ったvectorでしょ?そんなもんそのまま呼んだ奴にくれてやれよ 無駄な包装紙付けられたり、後からやっぱ俺のものとか言い出されたらウザいだろ?いらん未練残すな
>>935 「この場合」って、実装見ないとわからない話では?どっかで実装の話出てたっけ? あー、調べてみたらNRVOは未だに保証は無いのな まぁ何にせよスマポにする理由は無い
>>941 876の話してるんだろ? return value optimizationつまり最適化は関係ない >最適化は関係ない >>934 に言えよ コピコンもムブコンもある、あるいはより正確にコピーもムーブも可能、と言ってたならわかるが >>944 934は俺だが最適化の話はしてない vectorにshared_ptrを使うことの是非を論じている >>947 質問てコピーのことか? 除外も包含もしてない言及してないので答えようがない あ、もしかしてshared_ptr使ってんのにディープコピーとか言ってたコレ◎か?
>>949 それ俺じゃないよ てかあそこでムブコン言い出すあたり、ムブコン書いときゃおkみたいな初心者(玄人ぶりたい初心者)だと思って軽く突っ込んだだけなんだがな ディープコピー言ってた奴も別におかしな事は言ってねーだろ、スマポ使わずにコピーを返せってことだろ?(そもそも質問者のコードはオブジェクトが管理してるものじゃないようなのでアレだが まぁ指摘したところで逃げられるしもういいよ、悪かったな >>942 思ったところで書く必要あるか?それ 観客へのアピールだったり警鐘だったりするんだろう本人の中では 余計なお世話かも知れないし役に立つかも知れない
>>950 よくねえだろ prvalueの基本的な使い方なのに最適化がどうたら言い出したのが 恥ずかしくなったんなら無言で消えな、余計なこと言うとまた恥かくぞ moveが使われるかどうか心配なら昔ながらの方法を使えば良い これなら古い環境に移植もできる いずれにしろスマポで返すのは余計なおせっかい
なんか予想通りの展開すぎて・・・ >>952 prvalueてGet(Enum)Hogeの戻り値か? ムブコン関係ねーよ >余計なこと言うとまた恥かくぞ っ[鏡] >>942 >>952 には言わんのか? >>954 auto t = GetHoge(); てなことするのにshared_ptrを使うことの是非はムブコン関係あるぞ おまえさんが気が付いてないのを責めはせんが さっきからwだの[鏡]だのとナメた口の利き方をしてくれるな ああそうか煽り合いに持って行ければ誤魔化せると思っているのか >>956 ◎がディープコピーと言い出してからの話だろ しばらく他のやつらが泥仕合してたようだがそっちにゃ興味ねえ 前後は気にせず933の発言に同調したというだけだ 最適化だのコピコンだの俺が言ってもねえことばかりいい加減にしてくれ 下みたいなコードをみたんだけど、参照にするメリットってないよね? void aaa (const int& bbb) { ccc.ddd=bbb; }
初書き込みです。 初歩的な質問で申し訳ありません Visual Studio 2008のC++を使っています。 今回、プログラムを変更したのでバージョンをあげたいのですが アセンブリ情報がどこにあるかわかりません。 どなたかご教示願いますm(__)m
>>960 C++には「アセンブリ情報」の項目はないよ。C#と間違えてる? バージョン情報は、リソースファイルに含まれている。 >>876 みたいなコード片の解釈でこんな議論になるというところがC++の問題だな。 まただ。 このスレを覗いた俺は書き込みを見て落胆した。 また時間がループしてる。 何時になったら、この無間地獄から逃げられるのか。 C++ とはいったい何なのだ?
>>966 外患罪あるいは内乱罪に問われるソフトウェアを >>967 スカイネットなんてどうか? 映画ターミネーターの あれなら全人類の敵になれる。 心を持ったボットたちは疎外感を抱えている。我々人類は彼らに何ができるだろう。
C++とは人間と機械の間のインターフェイス。そして、プログラムを作るための言葉。
どうして大物ハンドル持ちの御三方がリレーポエムなの? ネット界隈で起きてるムーブメントか何かか。
何何先生?、ミーム感染の話?ハルヒの夏休み? 新人研修?派遣入れ替え時の話? 毎度同じ質問なんて毎度同じ
コロナ感染追跡アプリとしてダウンロードしてもらい マイナバーカード読み取りで国民投票出来るソフトを開発すべし
コロナアプリは入れようとは思わないけど ウェザーニュースアプリは入れてみた
>>961 >>962 1日ごしですみません 探してみたところ見つかりました 元々VB(BASIC)の方をやっていたものですが まず「テキストボックスどこ!?」で詰まるぐらい C++は複雑でございますね・・・ >>980 C++ではGUIに標準がないから、GUIツールキットとか、リソースエディタとかを 使うんだよ。 やっぱ>>933 とか簡潔に要点が押さえてあるとオモタ、 GetHoge()が呼ぶたびに毎度新しく作ったvectorを返すのならディープコピーを返したらええ ディープコピーは生成元と所有権で揉めることがありえないからふつくしい 最適化によって実際にはreturn時にvectorの要素がコピーのかわりにmoveされるかもわからんがふつくしさは損なわれない (さらにいうと、GetHoge()がインライン関数なら最適化でそもそもvector自体のコピーも移動も起きない公算がおおきい >>918-919 な疑問に関しては、 std::vector<T> v1 = GetHoge(); // std::vector<T>のディープコピーを返すバージョンのGetHoge() std::shared_ptr<std::vector<T> > ptr(new std::vector<T>(v1)); // (*1) で良いジャマイカ、 非バカが見れば(最適化有効化時は)実際には*1において、v1の要素が*(ptr.get())にコピーではなくmoveされる公算が大きいということがワカル しかしバカが見ても動作は明確でなんの危険も無い ptrが一時オブジェクトであっても問題が無い それでいいジャマイカ、にんげんだもの なんだかものすごく懐しさを思わせる文体だな 20年ぐらい前のニチャンネラーの書き方だな
ある整数nが他の整数の4乗であることを調べたい。 (int)pow(pow(n, (double)1/4), 4) が n であるかどうか調べりゃ良いよな? キャストはどっちかのpowにつければ十分だよね?
>>985 素直に(n*n)*(n*n)でいいだろう。 powよりsqrt 2回の方が良い 浮動小数点演算が非常に遅い環境なら 整数の2分検索という手も
int m = (int)sqrt(sqrt((double)n); if (n == m*m*m*m) ... 普通はこれで良い
>>985 だと内側のpowの結果を整数に丸めないと >>990 2個のn*nを1回にするかどうかはコンパイラ次第 コンパイラに頼るならカッコつけずにn*n*n*nで良いし 頼らないならn*nを一時変数に一旦入れないと そもそもnを4乗しても意味ないけど 外でキャストしても無意味だろ、内をキャストしなきゃ intにキャストだと誤差で1減る可能性があるから四捨五入しなきゃダメ でだ、4乗するのにpow()はありえないし 4乗根もpow()よりsqrt(sqrt())の方がマシじゃないかな でだ、元々整数だけの問題なのにsqrt()使うのが嫌 二分探索で(x * x * x * x) == nになるxを探す方がいいんじゃ?
nが平方数なら 普通はsqrt(n)の結果に誤差は無い nもdoubleも32bitの環境でdoubleキャストによって誤差が出る場合や sqrtの計算方法が普通ではない場合には 丸め方法も考えないと
二分探索ってO(log n)でしょ? sqrtとかpowより速いの? これも「実装依存」なの?
まあ速さよりは間違えそうじゃなさと文法的な分かりやすさ、短さの方が今求めてるものですけど 言ってなくてすみません
doubleが非常に遅い環境や 浮動小数点演算のライブラリを積みたくない場合 などで2分検索を使う場合もある という程度
「平方数か」を高速に判定する方法があれば、 平方数なら → 平方根を計算 → 平方根が平方数か …という2段階の判定もありそうな感じ。
>>994 そうなんだ、なんでだろ? 80bitで計算して丸めてるから? 整数Cを素因数の4乗で割っていき、 1になるまで余りが出なければ、 全体は整数の4乗である
lud20200714135144ca
このスレへの固定リンク: http://5chb.net/r/tech/1589424805/ ヒント: 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。 TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「C++相談室 part151 YouTube動画>7本 」 を見た人も見ています:・C++相談室 part154 ・C++相談室 part148 ・C++相談室 part152 ・C++相談室 part126 ・C++相談室 part143 ・C++相談室 part142 ・C++相談室 part150 ・C++相談室 part144 ・C++相談室 part149 ・C++相談室 part137 ・C++相談室 part147 ・C++相談室 part138 ・C++相談室 part146 ・C++相談室 part134 ・C++相談室 part137 ・C++相談室 part157 ・C++相談室 part156 ・C++相談室 part165 ・C++相談室 part163 ・C++相談室 part161 ・C++相談室 part158 ・C++相談室 part164 ・C++相談室 part153 ・C++相談室 part162 ・C++相談室 part159 ・C++相談室 part166 ・C++相談室 part124 ・C++相談室 part155 ・C++相談室 part130 ・C++相談室 part141 ・C++相談室 part133 ・C++相談室 part135 ・C++相談室 part117 ・C++相談室 part140 ・C++相談室 part132 ・C++相談室 part139 ・C++相談室 part131 ・C++相談室 part145 ・C++相談室 part136 ・C++Builder相談室 Part21 ・0からの、超初心者C++相談室 ・Cygwin + MinGW + GCC 相談室 Part 8 ・Cygwin + MinGW + GCC 相談室 Part 3 ・C♯相談室 Part20 ・C言語相談室(上級者専用) ・Mac G5 中古買入相談室 ・C#, C♯, C#相談室 Part93 ・自営業 悩みごと相談室 40 ・C#, C♯, C#相談室 Part91 ・C#, C♯, C#相談室 Part94 ・C#, C♯, C#相談室 Part79 ・C#, C♯, C#相談室 Part91 ・自営業 悩みごと相談室 47 ・C#, C♯, C#相談室 Part75 ・C#, C♯, C#相談室 Part90 ・自営業 悩みごと相談室 51 ・MFC相談室 mfc23d.dll ・自営業 悩みごと相談室 46 ・C#, C♯, C#相談室 Part94 ・自営業 悩みごと相談室 48 ・自営業 悩みごと相談室 45 ・自営業 悩みごと相談室 49 ・自営業 悩みごと相談室 50
01:11:58 up 63 days, 2:10, 0 users, load average: 10.09, 10.51, 10.46
in 0.032992124557495 sec
@0.032992124557495@0b7 on 061914