C++相談室 part151
レス数が1000を超えています。これ以上書き込みはできません。
https://mevius.5ch.net/test/read.cgi/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
呼び出してるのはあくまでオーバーロードされた関数呼び出し演算子なので、こうする
f2.operator()<int>();
https://wandbox.org/permlink/uVSptZMZErNrL5p3 >>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.ｈのmin、maxは困りものだよな。 マクロでminmax書いているほうがどう考えてもバカだよな win32の設計とかあーバカコードだなコレってのがちらほら 人類がBOOST_PREVENT_MACRO_SUBSTITUTIONから解放される日は遠い STLの方が馬鹿。
今までのものを知らないで独自のものを書くのは簡単。
勉強もせずに独自の日記を書くようなことだから。 >>59
ちがいます、フェニキア文字由来ですよ
アラビア語はセム語族の中でも後発後進国 関数（始点，終点）に馴染めないバカのあぶり出しだったな
関数（始点，個数）に固執してたやつらがSTLで吠え面かかされたｗ https://ideone.com/vJRbP1
ミラーラビン素数判定法を聞いて作ってるんだけど、決定性に確定させるにはここからどうしたらいいですか？ https://ideone.com/Gq2X2N
無しだとちゃんと出るっぽいです。ということを見せておきます。 >>65
ソ連で生魚にあたって、入院中に病院の天井みてたら思いついたらしいぜ 寄生虫より有毒魚かもな
フグみたいな命取りなやつじゃなくバラムツくらいなら腹壊す程度で済む >>75がどれに対するレスなのか分からんが
みんな単にスルーしてんだろうなこれは dtmみたいな楽器を作る場合、音は何らかのライブラリを使うんでしょうか？１から作れるんですか？ >>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が重複する値だったら除外したい
これ要求に間違いが無いなら、独立した比較基準（整列用と重複判定用）が２つあることになるので、
単一の比較関数（およびset）で解決しようとしてるのが間違いかな。 △ ヒント
○ これ以上は分かりませんでしたがMOTTAINAIので貼ります 簡単に出来そうだと思っていた事が、結構な難問だったようですね…
自分の力では無理そうだという事がわかっただけでも収穫でした
皆様ありがとうございました 回答を示す、
1. 「<」と「==」演算子をグローバルな関数として定義する版：
https://ideone.com/Qdi402
2. 「<」と「==」演算子をクラスのメソッドとして定義する版：
https://ideone.com/3JTyiJ
3. （参考）スマポ版
https://ideone.com/bYOWcR
元のコードはいきなりinsertしようとしているがinsertの動作はinsertしてから重複だったかどうか返すというものなので、
生ポインタ版である1と2では事前にfindしている
3は事前findが不要で本来のコードとなったが、動作は後優先（先にinsertしたaと、後からinsertしたbがsameの場合、aが削除され、bが残る。） >>135
> 等値演算子「==」は、それがCNodeのメソッドまたはCNode&を引数にとる
> 関数定義がなされていなければ(!(a < b) && !(b < a))で遂行される
要出典
>>145
> insertの動作はinsertしてから重複だったかどうか返すというもの
要出典 >>146
> > insertの動作はinsertしてから重複だったかどうか返すというもの
> 要出展
仕様誤解してたｻｰｾﾝgrz、、
と言うわけで>>145のソースコードは以下の通り訂正汁、
1のソースコード ==> https://ideone.com/uRTmmo
2のソースコード ==> https://ideone.com/EdndM1
3のソースコード ==> https://ideone.com/UYMN5D
（3は間違ったコメントを削除、およびアドレスの表示の誤りを訂正）
> > 等値演算子「==」は、それがCNodeのメソッドまたはCNode&を引数にとる
> > 関数定義がなされていなければ(!(a < b) && !(b < a))で遂行される
> 要出典
しらそん；；
テンプレートの定義とC++の言語仕様とかstd::rel_opsの存在意義とか想像したらﾜｶﾙ 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さんもありがとうございます >>154
> return true;//ここをfalseではなくtrueに変更
明らかに違反してるじゃねーの？
https://cpprefjp.github.io/reference/algorithm.html#strict-weak-ordering
> 「狭義 (strict) 」 は非反射関係 (irreflexive relation) (全ての x について !comp(x,x) である）の要求 難しい事はわかりませんが、
動作検証が足りてないかんじでしょうか
もし駄目だったら、諦めて別の方法を考えようと思います 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件を末尾から順に見ていくとすぐなんだが
そういう生活の知恵はあんまりないのかい？ https://en.cppreference.com/w/cpp/utility/hash
MyHash{}(obj)
std::hash<S>{}(obj)
の{}は、直接リスト初期化のもので、いったんMyHash型やstd::hash<S>型のテンポラリ・オブジェクトを作成してからoperator()関数をobjを実引数にして呼び出しているという理解でよろしいですか？ newしたあとにdeleteしなくてもアプリケーションを終了すればメモリは解放されますか？ >>178
Windows/Mac/Linuxではメモリー領域自体は絶対に解放される。
ただし、deleteが呼び出されるわけではないので、原則的にはデストラクタは呼び出されない。 >>175
たまたまの結果を生活の知恵とかw
キーワードと通常言語が被らない日本語万歳だな >>178
プロセスに割り当てられているメモリは現代の普通のデスクトップOS上でならプロセスの終了と共に解放されるのだけど、
オブジェクトは外部のリソースのハンドルを掴んでいることがあるから
それを正常に (デストラクタで) 後始末しないとリソースリークが起こる可能性はある。
POD 型のオブジェクトに限ってならば管理されてるリソースはメモリだけだから
delete しなくてもプロセス終了時におおよそ安全に解放されることは期待していいと思う。
言語仕様での保証はないので C++ スレ的に言えば「やめとけ」ってことになるけど。 メモリと断っている人に余計なこといわなくていいと思うけど
アプリの異常終了であっても解放されてほしいのだろうから
c++の終了処理に依存してもしゃない >>181
何がたまたまの結果だよ
C++規格票とドラフトは巻末に索引があって
検索でヒットしすぎるときは末尾を見に行けば
そこは索引の中である可能性が大きいというのを
思いつくことができんのかおまえさんの頭では
だから見つけられなくて聞いてきたというなら合点だ >>178
世の中すべての::operator newの内容を確認してからでないと答えられない質問だ
もっと言うなら将来にわたってタイムマシンで確認してくる必要があるから
調査の工数が発散しちまう
どういう意味かわかるな？ https://qiita.com/SaitoAtsushi/items/8da8ae7f6b84b1d806e4
int main(){
double a = 1.5;
std::string b = "Hello World";
struct foo{};
xyz(a, b, foo());
}
↑のfoo()は一時オブジェクトの作成ですね？ めちゃくちゃ難しいです。#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
やーい、同じことしか言わなくなってやんのｗ 必ずしも索引があるとは限らないのにあることを一般論化してドヤ顔するのと
ヒープ解放するかどうかはすべてを尽くして調べられないからわからたないとドヤ顔してる奴が
同じ人物だってのが困るわぁ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
仮に心の中にあってもあなたは全く言語化して無いないので駄目。 >>214
じゃあ、Wikipediaに載っていた>>190の例はどう説明すれば良い？ >>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に事故としての扱いをさせるのが「難しい」のは思いつかないだけじゃねえだろな
プログラミング以外の仕事でも事故はまず報連相
１人で握りつぶそうとするのは学生気分が抜けてないやつのすることだ >>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
よく読んでなかったわｻｰｾﾝｗｗｗｗｗｗｗｗｗｗｗｗ
>>292ので
>デストラクタ内で対処を完結させろ (例外を投げずに済ますために)
のアッパーコンパチになるのだから結果オーライで
オール無問題、 個人でｃ＋＋使うことは少ないですか？
C#やelectronと比べて何倍手間がかかりますか？
２ｄのタイルマップエディタのようなものを作りたいのです、、、
https://www.mapeditor.org/ 挫折するリスクも加味すると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のインクルードくらいＳＤＫにまとめとけや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++で作成されているようです
３ｄでもないのに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++には大差で負けることも、現実のアプリの例では
垣間見えることもまた事実。 じゃあいちいち他言語を下げるのはおやめなさい。
王者には王者の気品が求められるのです。 >>330
>>332
労力的にはどれほど違うと思いますか？イメージでいいのですが
個人で ｃ＋＋使うといつまでも完成しないなんて話を聞いたもんですから 可読性・難易度・バグりにくさ
動的言語
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世紀の頃の禿のお言葉なんだがｗ 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 の一種」でもあるのですね。 >>405
疑問が深まったら掘り下げるのは別にいいんじゃね。 根拠も提示されてるし。
>>409
ワイは趣味プログラマやで。
実務家が言語仕様の詳細に興味がないのもよくあることなので、
プロのプログラマが仕様に詳しいとは限らんけど、
平均的には日常的に C++ でプログラミングしているやつの方が詳しいよ。 当然に。
>>408
あれっ、そうか。 カテゴリに関しては俺の間違い。
で結局は >>403 で述べた通り reference collapsing が適用されるってだけだと思う。
https://timsong-cpp.github.io/cppwp/n3337/dcl.ref#6 >>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
責務なぁ……。
俺はとにかく名前で考えるようにしてるよ。
名前を付けたい単位に分けて、それを書いている内に名前を付けたい部分が出来たら括り出して……
という風に繰り返してたら (少なくとも自分にとっては) だいたい使いやすいデザインが出来てる。
名前を付けたらそれの役割ってのはほとんど自明だったりするし。
ぼんやりした構造って頭に残り難くて何をやってたかわけわからんようになるので、
名前を付けるってのはかなり大事なことだと思う。 >>435
O(M+N) って、ハッシュ計算のコストを含めたうえでの最悪計算量でしょ。
ハッシュ計算のコストを除いた平均計算量を O(1) にすることも可能なのがハッシュの利点、というのが一般的かと。
https://ja.wikipedia.org/wiki/%E3%83%8F%E3%83%83%E3%82%B7%E3%83%A5%E3%83%86%E3%83%BC%E3%83%96%E3%83%AB
> ...検索や追加を要素数によらず定数時間O(1)で実現する。... >>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++の仕様になぜＧＵＩがない
言語が強制すればＯＳが統一できるのに >>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パーサーがハード化されてストレスなくなるだろうよ >>472-474
標準って何のためにあると思う？ >>478
システムコール呼ぶだけなのになんで違うん？ >>469
java の awt レベルでいいから欲しいですねえ C++標準でも外部でも良いから簡単な記述で簡素なGUI作れるようになってほしいなあ ファイルシステムなんかは事実上ほぼ仕様が枯れてきてるから標準化できたけど
この意味GUIはまだ枯れてないからな >>473
中の人？
飯の種がなくなるから新しい技術を導入するなっていうのは流石に賛同得られないぞ エンドユーザーがC++とはアプリの外見のことだなんて誤解するようになるのはやだね 既存のどのGUIを基本にするかってだけで宗教論争起こすだろ こいうのは一種の中二病だよね
実際やってみれば
細かい制御ができない大雑把仕様
か
大掛かりなオレオレ仕様で学習が困難
ってなるのがオチ
おっさんになればわかる >>486
それらの中の人なら>>473みたいな的外れな馬鹿げた主張はしないと思う 可能性あるとしたら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とかで圧縮するわ >>510
D.8 にも書いてある通り uncaught_exceptions() で同じことができるので、そっちを使えばいい。
わざわざ消してない実装が多いだろうから、たぶんまだしばらく uncaught_exception() も使えちゃうだろうね。
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0619r4.html#3.7 まともな実装なら[[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差し替えとか後が怖いなーと思いましたｗ >>556
今あるメンバ変数の1個をポインタに置き換える
ここに色々なデータが入った構造体のポインタを置く
これで互換性を保てる ヘッダにオブジェクトの中身を読み書きするinline関数有ったら危険
inlineじゃなくてもtemplateだとヤバイ
まあtemplateで実体生成されないように実装分離してたらセーフかな ヘッダは基本変えない
不便ならポインタに置き換える変数1個だけ型と名前を変える
あとはライブラリ側のコードのみ変更
アクセス関数を後から増やすなら
クラスのポインタとパラメータをパラメータにしたグローバル関数にする
多少使いづらいが
互換性を考えて設計しなかったツケ >>571
巷のOSとか、定期アップデートがかかるときにこういうので悩んだりしないんですかね?
>>572
おお確かにそれでいいんですかね?
まあ今後新たにライブラリを公開することがあるなら最初から気をつけようってことでw >>564
知ってます
当たり前でしょそんなこと！ >>572
それは、Pimpl方式だけど、それより、>>568の方が書きやすいし、効率も良い。 >>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
あれ？
もしかして
互換性保持した修正はギブアップで
依頼者の要件を無視した案を言ってる？ >>637
っ[鏡]
てかID変えたんか？
>>638
>>573 >>639
>>633に対して反論したんだが
すり替えてんじゃねーよ 外部から直接アクセスしない変数を置き換えるに決まってるたろ
連想配列だと
初期化順とかスレッド安全とかパフォーマンスとか
色々と心配だねえ >>636
どこが答えだよ
>>617 は無理だよ
アプリ側でnew/deleteされたことをライブラリ側はトラッキングできない
アプリ側でnew/deleteされてないのだったら問題になってない
アプリに手を加えていいのだったらバイナリ互換考えなくていい >>643
新しいthis来たら新しく作るだけだろ
deleteに対してはどうにもできんけど
>>644
馬鹿かお前は
ポインタで扱う前提に乗っかったのはお前だろ
バカにしようとして自爆したのに逆ギレか コピーを使わない、もしくはインラインじゃないなら>>595
コンストラクタ、デストラクタ、コピーがインラインじゃないなら
>>572で良い
new deleteはアプリ側でもライブラリ側でも問題ない コンストラクタはインラインでも>>572で問題ないね >>643より>>572の方が良いね
隙間があってコピーで問題なければ>>595 インラインじゃないならって、普通コンパイルオプションやnoinlineで指定してない限り、
実装が見えているメンバ関数は全てインライン展開はされうるんだぞ
そんな厳しい前提がOKなら>>645で言ったdeleteの問題だって対処できる >>572と>>617
デストラクタがインラインだとダメなのは同じ
コピー時の制約も同じ
速度、スレッド安全性、初期化順などの心配事に関しては>>572の勝ち
>>572は外部からアクセスしていないポインタサイズの変数の存在が条件 >>651
ヘッダにない関数はインラインにしようがない >>572や>>595のスペースが全く無いなら他の方法を考えるしかないけど デストラクタ問題に対応出来るのは今のところ>>595だけ 暗黙定義のものが一つも無ければね
(=ヘッダに宣言はあるが実装は見えないものだけ
てか別に>>617じゃないといけないとは言ってないが
>速度、スレッド安全性、初期化順
速度が必要とか一言も書いてないし
スレッド安全性て、連想配列使うのはライブラリ内だけなんだからライブラリ側で対処すればいいだけ
>>655
ユーザーが使ってない変数や領域に新しいメンバを含む構造体へのポインタを入れる案も
根本的には連想配列案と一緒だよ、デストラクタが非インラインでなければ解放できないぞ
まぁ今ある情報だけで議論してもどうにもならんが >>656
>>595を勘違いしてる
ポインタを入れるわけじゃない
隙間に変数そのものを入れる コンテナやスマポなど、コピーやデストラクタで処理される物の中身を少し大きくするとか
close()みたいな最後に必ず呼ばれる関数があればそこに入れ込むとか
中身がわかればもっと別の案も出るかも >>656
速度が必要と書いてなければ速度無視が前提って...
なかなか衝撃発言ですねえ
C++なんだから組み込みのチープ環境かもしれないし
リアルタイム処理かもしれないし
もしかしたらISR内部かも
(ISRならnewも問題になるか)
速度がどうでもいい用途でいまだにC++を使うって
どんな業界かな？ 不変のアブストラクトクラスを作っておいて
実装はそこの派生クラスでやり
使用者はポインタで使う >>663
冴えてる！
いつもすてきなはちみつさんですね！ よーし、みんな呼んじゃうゾ
void君、rubyガイジ、jquery房ーっ ∩＿＿＿∩ ｜
| ノ＼ ヽ |
/ ●゛ ● | |
| ∪ ( _●_) ミ 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にオプションまでベタ書きでいいし
何にこだわってるのか知らん プログラム１つのために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はないってことね
最初の質問には答えて貰えたようだ
みんなありがとう いやそれは勝手にするさ
俺の状況をいちいち知らんやつに
わかってもらう必要もないし そもそもコンパイラは後方互換性を気にしていれば良くて
過去のコードがコンパイルできる、古い記法なら古いよとメッセージを出して終わるまでやれば良くて
将来変わるであろう規格に備えて私の知らない規格ですよと教えてあげる必要はなくエラーで落ちればそれでいい 恰好つけたいんなら余計なことは言わないほうがいいぜ(ｸｽｸｽ >>793
それは
>>789
なんて書いちゃうやつのことでしょw あれは何かおかしいのか？ おまえの頭のほうが(ry >>795
無知を指摘されただけのことを自分の事情的に言い訳して謎の上から目線へ変換してるのが頭悪すぎでしょw いらんものを使わんのを無知とか大きなお世話なんだよ
おまえだっていらんものは使わんだろうが、それも頭が悪いからか？
いちいちひっ絡んでくるのは何かよっぽど悔しい思いしてるんだろうな
俺は最近あんまり誰かをコテンパンにやっつけた憶えはないんだが
何か気に障ったのか？ ずーっと前にシバイたったやつがまだ根に持ってるのかな
だとしたらキモすぎ 他人に教えを乞うておきながら
やあご苦労的な上から目線でまとめるバカwww
匿名掲示板で根に持つも何も、一体お前誰だよwwwww
バカってホントwwww 正体わからない場所で根に持たれてると思うってことは
同じようなことを繰り返してるんだろ？
無知を晒して指摘されてるのになんか偉そうとかwwww
あるいはココロの病気かwww 787のどこが上から目線なんだよ
言いがかりはやめてもらおうか 散々罵倒しといてこれくらいで許したるわとかいうメダカ師匠になってるんだよwww >>802
説明しろよ
できないならおまえもヤバイぜ >>805
煽って他人に教えを乞うスタイルはお前だろwwww いーや、思い当たる節が全然ない
>>802
説明しろよ
できないならおまえもヤバイぜ
早くしろよｗ 匿名掲示板で根に持たれてる自覚があるとか相当ココロの状態やばいよw キモすぎつってんじゃん
>>802
説明しろよ
できないならおまえもヤバイぜ
早くしろよｗ >>807
一連の流れであの態度
頭おかしいでしょw
それがわからないなら人間関係やばいw >>810
やーい説明できねえ
ブーメラン痛そうだなｗ
次におまえは「ブーメランなんか刺さってないから痛くない」という
目にうるうる涙をためながら pragmaのアイデアを思いつくこと自体はまぁいいと思うけど
>>747 の指摘受けたら、この仕様は駄目なことわかるよね
なのにそこでやめずに強弁続けておいて最後に >>787 はずっこける なんか他の#pragma使ってなさそうだね
ルールを途中で変更する#pragmaは珍しくないんだが まだ何がダメなのかわかってないらしい
しかし途中でコンパイラ切り変えるのは画期的だわw ID変わったけど話し方が酷似している
さては、またあいつか go は
// コメントに描いてあっても反応するから怖い BOM付選んだコンパイラもあるし
コンパイルオプション選んだコンパイラもあるけど
ソースの先頭のエンコード選んだコンパイラはないんだっけ >>751
なるほど
.o32とか.o64とか
.c32とか.c64とかな ISO/IEC14882は３年毎に改訂されることになっているんだから
今後は定期的な改定に備える計画もあって然るべきだと思う 何がいったいわかったのだろう
それに勝手に他の人を認定してるしwww
相当ヤバいわw 推測と認定の区別がつかないやつ
実社会でも不自由してそうだな あわよくばまぐれ当たりを狙ったようなテキトーな言葉遣いをするやつ
迫力ねえんだよ では何がわかったんだ？
ああ？
喧嘩に負けて上から目線の捨て台詞にしか見えねーんだよw ほらな
心当たりのあることを咎めてこないから全くダメージにならない
何かイヤミを言ってやろうという意図だけはわかるんだが滑りすぎ ここでいつも似たような喧嘩をしている二人って毎回同じ奴らだろう。
なんだかんだ言ってお前ら仲良いな。
他のスレ住人に見せつけてくれなくていいから、よそでやれ。 そういえば俺にひっ絡んでくるやつ
話し方というかアホさが似てると思うことはちょくちょくある >>827
787がメダカ師匠になってることがわからないようじゃどうしようもないよw >>747
先頭行に書けばいいだけだろ
まあ使い勝手を考えてコメントを除く先頭行に書くようにすればいい
> 途中で現れたらどうするの？
エラーにすればいい
> 引数で指定されているのと矛盾したらどうするの？
どちらを優先するかを決めておけばいい
> 複数異なる指定があったら？
エラーにすればいい
よくある処理だしなんの問題もないけど？ C++使いにしては低能過ぎるレスが多いな。
どういうことだ。 >>782
プリミティブ型ならレジスタに乗るって思って良いんですかね？ >>836
構造体型/配列型以外のデータは原則的にレジスタには乗る。
ただし、参照と直値のどちらが効率が良いかは、レジスタに乗るかどうかだけで
決まるわけではない。
1個のレジスタに乗らなくてもレジスタ数個分ならコピーしてしまった方が
参照より速くなる場合は多い。ケースバイケースだが、レジスタ5個分とかでも
コピーした方が速い場合もある。 >>836
ケースバイケース
普通はそんなことを気にする必要はないし気にする必要があるなら処理系のドキュメントを読め
>>837みたいに憶測で語ってる奴は無視しておけばいい >>838-839
いや元の質問(>>779)を読めよボンクラ >>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++にあるアレが必要になったんだよ
アレだよアレ
わかるだろ 本来標準ライブラリーで済むものまで言語仕様に入ってやがる
それというのも標準ライブラリーがしょぼくてかつ改善が入らん
あっちはだれがやってるんだ 非バカの>>885や>>888は当然コード見た瞬間最初から全部わかってたんですねわかります、 皆さんはありがとう御座います
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を使うことの是非はムブコン関係あるぞ
おまえさんが気が付いてないのを責めはせんが
さっきからｗだの[鏡]だのとナメた口の利き方をしてくれるな
ああそうか煽り合いに持って行ければ誤魔化せると思っているのか >>955
そういうコード(変数への保存)を避けたいという話の上での>>930-934だろうが(>>934はお前
見苦しい言い訳するな
めんどくせーからもう相手しないが
>>942は逃げるなよ >>956
◎がディープコピーと言い出してからの話だろ
しばらく他のやつらが泥仕合してたようだがそっちにゃ興味ねえ
前後は気にせず933の発言に同調したというだけだ
最適化だのコピコンだの俺が言ってもねえことばかりいい加減にしてくれ 下みたいなコードをみたんだけど、参照にするメリットってないよね？
void aaa (const int& bbb) {
ccc.ddd=bbb;
} 初書き込みです。
初歩的な質問で申し訳ありません
Visual Studio 2008のＣ＋＋を使っています。
今回、プログラムを変更したのでバージョンをあげたいのですが
アセンブリ情報がどこにあるかわかりません。
どなたかご教示願いますm(__)m >>960
C++には「アセンブリ情報」の項目はないよ。C#と間違えてる？
バージョン情報は、リソースファイルに含まれている。 >>876みたいなコード片の解釈でこんな議論になるというところがC++の問題だな。 まただ。
このスレを覗いた俺は書き込みを見て落胆した。
また時間がループしてる。
何時になったら、この無間地獄から逃げられるのか。
C++ とはいったい何なのだ？ >>966
外患罪あるいは内乱罪に問われるソフトウェアを >>967
スカイネットなんてどうか？ 映画ターミネーターの
あれなら全人類の敵になれる。 心を持ったボットたちは疎外感を抱えている。我々人類は彼らに何ができるだろう。 C++とは人間と機械の間のインターフェイス。そして、プログラムを作るための言葉。 どうして大物ハンドル持ちの御三方がリレーポエムなの?
ネット界隈で起きてるムーブメントか何かか。 何何先生？、ミーム感染の話？ハルヒの夏休み？
新人研修？派遣入れ替え時の話？
毎度同じ質問なんて毎度同じ コロナ感染追跡アプリとしてダウンロードしてもらい
マイナバーカード読み取りで国民投票出来るソフトを開発すべし コロナアプリは入れようとは思わないけど
ウェザーニュースアプリは入れてみた >>961
>>962
1日ごしですみません
探してみたところ見つかりました
元々VB(BASIC)の方をやっていたものですが
まず「テキストボックスどこ！？」で詰まるぐらい
Ｃ＋＋は複雑でございますね・・・ >>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乗である このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 58日 21時間 48分 5秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
