C++相談室 part151

**デフォルトの名無しさん** · 2020/05/14(木) 11:53:25.59

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part150
https://mevius.5ch.net/test/read.cgi/tech/1584975873/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1556142878/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

テンプレここまで

**デフォルトの名無しさん** · 2020/06/15(月) 17:00:27.16

>>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)の一種です。

**デフォルトの名無しさん** · 2020/06/15(月) 17:03:05.14

「xvalue は rvalue の一種」でもあり、
「xvalue は glvalue の一種」でもあるのですね。

**はちみつ餃子** ◆8X2XSCHEME · 2020/06/15(月) 17:11:13.40

>>405
疑問が深まったら掘り下げるのは別にいいんじゃね。根拠も提示されてるし。

>>409
ワイは趣味プログラマやで。
実務家が言語仕様の詳細に興味がないのもよくあることなので、
プロのプログラマが仕様に詳しいとは限らんけど、
平均的には日常的に C++ でプログラミングしているやつの方が詳しいよ。当然に。

>>408
あれっ、そうか。カテゴリに関しては俺の間違い。
で結局は >>403 で述べた通り reference collapsing が適用されるってだけだと思う。
https://timsong-cpp.github.io/cppwp/n3337/dcl.ref#6

**はちみつ餃子** ◆8X2XSCHEME · 2020/06/15(月) 17:18:57.93

いや、なんか違う気もしてきた。
わかんね。

**デフォルトの名無しさん** · 2020/06/15(月) 18:34:21.52

>>412
>平均的には日常的に C++ でプログラミングしているやつの方が詳しいよ。当然に。
C++は、何十年も前に既に完成している言語なので、実態はわかりませんが、仕事をC++を使っている人でも、はちみつ餃子さんのようには新しい仕様を知らない人の方が多いのではないかと思うのです。

**デフォルトの名無しさん** · 2020/06/15(月) 20:04:29.90

はちみつ餃子さまを筆頭とするはちみつ餃子さまにお答えしていただけることを期待しております。

普段どんな仕事をしてるの？

**デフォルトの名無しさん** · 2020/06/15(月) 20:05:26.73

>>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)
となるようです。

**デフォルトの名無しさん** · 2020/06/15(月) 20:13:24.30

自分のレスにレス返すスタイルなんなの
自分の日記帳でやれよ

**デフォルトの名無しさん** · 2020/06/15(月) 20:48:28.91

これ前の人だよね

**デフォルトの名無しさん** · 2020/06/15(月) 21:31:20.35

結局答えられないんですねの人？

**デフォルトの名無しさん** · 2020/06/15(月) 21:44:07.48

また、質問します。
アプリでunordered_mapやunordered_setのコンテナ10個くらい使うのですが問題はキーの型が可変長でstd::stringで結構長いことです
具体的にはキーはファイルパスとかになるのですが
で、頻繁にコンテナを使用します
ファイラーみたいなアプリを想定して

このとき、キーをstringにするとコピーなどのオーバーヘッドが発生?すると思いますがさすがにこのレベルは気にした方がよい?

**デフォルトの名無しさん** · 2020/06/15(月) 21:48:49.59

ユーザーがカレントフォルダ移動したり、ファイル一覧のリストビューをスクロールするだけで走ります

で、きにする場合はキーをstd::shated_ptrでくるめばいいんですかね?他に方法ありますでしょうか?

**デフォルトの名無しさん** · 2020/06/15(月) 22:01:06.47

>>420 効率は実測が基本。

**デフォルトの名無しさん** · 2020/06/15(月) 22:17:50.72

100万文字のstringをキーにしたって、unorderedの内部で扱うのはハッシュなんだから挿入や検索の速さは変わらん（ハッシュ計算のコストを除く）
そのファイラーが糞重いんだったら原因はそこじゃないと思うぞ

**デフォルトの名無しさん** · 2020/06/15(月) 22:52:38.98

ありがとうございます
>>422の言う通り最終的は実測でしょうが、キーをstringにしたときのキーのメモリコピーのオーバーヘッドを気にしてました
が、よく考えてみますと実際にキーのコピーが発生するのは実際に要素を挿入するとき1回だけっぽいですね

findメソッドやcountでキーを渡しますがキーを参照で渡しますし、hash関数も参照でキーの値を受けとりますし

**デフォルトの名無しさん** · 2020/06/15(月) 23:00:46.83

キーのコピーの頻度そこら辺を想像したことなかったので、びびってましたがびびる必要なかったぽいですね

ということ、普通にstringをキーに実装してみます

**はちみつ餃子** ◆8X2XSCHEME · 2020/06/15(月) 23:00:50.65

>>424
string はムーブ対応してるんで所有権を渡してしまうなら文字列全体のコピーはしないよ。

**デフォルトの名無しさん** · 2020/06/15(月) 23:12:46.11

>>426
なるほど、findやcountの場合はキーの値を実際にコピーする必要ないから、&&の引数のオーバーロードはないが、insertの場合は&&の引数で、所有権移せるバージョンもあるんですね

**デフォルトの名無しさん** · 2020/06/15(月) 23:14:22.14

この人がどうかは知らないけど
スクリプト言語あがりはstring + mapばっか使うんだよね
万能さはわかるけどさ
それで効率が～とか
どうなのそれw

**はちみつ餃子** ◆8X2XSCHEME · 2020/06/16(火) 00:10:13.43

ワイはもうおっちゃんやから小さい単位で型を作って名前を付けておかんと何をしよったかわからんようになるんやが、
文字列三昧で上手いことやれてまうやつはどういう脳みそをしとんや……。
と疑問に思ったこともあったんやけど、大抵の場合はうまいことやれとらんかった。

**デフォルトの名無しさん** · 2020/06/16(火) 00:48:04.50

プログラマ2年目だけど全然クラス作れんワイ低みの見物
責務責務いうけどどっからどこまでが責務やねん

**デフォルトの名無しさん** · 2020/06/16(火) 01:42:35.85

いや、おそらくその設計間違ってるな。

**デフォルトの名無しさん** · 2020/06/16(火) 05:42:11.77

std::string は参照カウントになってる場合もあるでしょ。
オブジェクトをコピーしても長さに応じたデータコピーが発生するとは限らない。
代わりに短い文字列ばっかりでも同じだけ重い可能性もあるんだが。

**はちみつ餃子** ◆8X2XSCHEME · 2020/06/16(火) 08:52:22.88

>>432
ちゃんとした実装なら短い文字列ではヒープアロケーションが発生しないような最適化 (いわゆる SSO) が入ってるよ。

**デフォルトの名無しさん** · 2020/06/16(火) 08:59:33.85

gccは参照カウントなstringは課題があるからやめたって10年以上前に聞いた気がするけど今はどうなんだろ

**デフォルトの名無しさん** · 2020/06/16(火) 13:38:01.19

>>123
>100万文字のstringをキーにしたって、unorderedの内部で扱うのはハッシュなんだから挿入や検索の速さは変わらん（ハッシュ計算のコストを除く）
厳密に言えば変わります。
データの個数がM、キーの文字数がNの場合、検索に掛かる時間は、
ハッシュを遣わなくて単純に比較した場合は、
O(MN)
となりますが、ハッシュ法の場合でも、
O(M + N)
となるので、掛け算と足し算の違いは有りますが、キーの文字数をいくら長くしても検索時間が増えない、というようなことはありません。

**デフォルトの名無しさん** · 2020/06/16(火) 15:27:53.17

>>430
クエリとコマンド、リードとライトでとりあえず分けるとこからやったらええ

**はちみつ餃子** ◆8X2XSCHEME · 2020/06/16(火) 15:55:59.04

>>430
責務なぁ……。

俺はとにかく名前で考えるようにしてるよ。
名前を付けたい単位に分けて、それを書いている内に名前を付けたい部分が出来たら括り出して……
という風に繰り返してたら (少なくとも自分にとっては) だいたい使いやすいデザインが出来てる。
名前を付けたらそれの役割ってのはほとんど自明だったりするし。

ぼんやりした構造って頭に残り難くて何をやってたかわけわからんようになるので、
名前を付けるってのはかなり大事なことだと思う。

**デフォルトの名無しさん** · 2020/06/16(火) 18:27:56.96

>>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)で実現する。...

**デフォルトの名無しさん** · 2020/06/16(火) 18:49:47.04

>>438
キーはそんなにバイト数が長く無くて、常識的にはある程度で上限が有る事が多いので、通常はO(1)と書いてあるだけです。
なぜかというと、ハッシュ値で大体は特定できても、最後、キーが完全一致していることを確認しなくてはなりませんが、
その時に文字列の比較のために、文字列の文字数であるところのNに比例した時間が掛かるためです。

例えば、キーの文字列の長さNが、1GBだとすると、文字列比較のために1*10^9程度のループが必要となります。

**デフォルトの名無しさん** · 2020/06/16(火) 19:19:02.88

>>439
そっか。一致比較が必要になる操作も確かに多いね。
N はわかったんだけど、 M もやっぱり最悪ケースの話ってことで合ってる？
「通常はO(1)」って言ってるし。

**デフォルトの名無しさん** · 2020/06/16(火) 19:21:15.40

スレ立てるまでもないスレにも同じようなこと書いたのですがすみません

巨大なファイルを読み込んで書き出すプログラムを書いています
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)
{

**デフォルトの名無しさん** · 2020/06/16(火) 19:24:51.88

失礼途中で送信してしまいました。

vector<ofstream&> files;
for (auto filename : filenames)
{
ofstream temp(filename, ios::out);
files.push_back(&temp);
}

こんな感じでofstreamの配列を作ってあとはそれぞれにデータを入れていこうとしたのですが
アクセス違反になります。スコープの外に出たらofstreamは勝手にcloseされる？そうなのでそのせいかなと思っています
複数のファイルに対して順々にデータを書いていきそれをループするのってどうしたらいいでしょうか

**デフォルトの名無しさん** · 2020/06/16(火) 19:29:01.32

答え分かってんならちゃんと実体を外に持たせなよ
vector<ofstream> files;
for (auto filename : filenames)
{
ofstream temp(filename, ios::out);
files.push_back(std::move(temp));
}

**デフォルトの名無しさん** · 2020/06/16(火) 20:59:11.88

通常はO(1)（で見積もっときゃまぁ大きくは外れない）

**デフォルトの名無しさん** · 2020/06/16(火) 22:57:05.95

業務でC++やることになりました
どうせなら体系的に学ぼうと思い、本を買おうと思いますがおすすめありますか？
CとC#の経験はあります
Cは組み込み開発での利用に、C#はデザインパターンを少しは活用出来る程度のレベルです

**デフォルトの名無しさん** · 2020/06/16(火) 23:21:49.71

>>435
キーの文字数Nはプログラムがビルドしおわったら変わらないのだから実質定数なのであって、
結局O(M)になるのでは…
（任意のxについて x + 定数 < a * xを満たす定数aを見出せるからオーダー表記の約束によりO(M+(定数)) = O(M)ェ、

しかもこの場合のMはデータの個数に比例するとわいえ、一般的はハッシュテーブルなら衝突しない限り
1回のテーブルアクセスで目的のエントリにたどり着くから、実際にはデータの個数÷ハッシュテーブルサイズ（エントリ数）
となるから衝突が無視できる（エントリ選択に統計的に偏りがなく、かつハッシュテーブルサイズが十分おおおきい
ならO(1)と逝って良いｷﾓｽ、

**デフォルトの名無しさん** · 2020/06/16(火) 23:31:56.61

あと1億文字のstring aと10文字のstring bとでハッシュキーを求める手間はどうかというと、
正直にやると文字数に比例するが
うまいことやったら定数にできる
もしくは文字列の構成時に都度ハッシュを更新するようにして、
ハッシュが入用になったときカタが付いている形ににする

**デフォルトの名無しさん** · 2020/06/16(火) 23:44:57.63

そんな事をするなら素直にノードのポインタを持て
と言いたい

**デフォルトの名無しさん** · 2020/06/16(火) 23:56:47.86

それではもともとの問題が解決しない
一億文字のstring aがメモリ上に存在するとして、
まったく別の手段で同じ字面の一億文字の文字列bを作ってしまったとする
aはaのノードを指し、
bはbのノードを指す、としたときに、
2つのノードが実は同じ文字列であることを確かめるには、
プログラムが他にあまた生成した10億個の文字列を一つ一つ確かめ、
最長1億文字の比較を行わねば結論が出ない（
ハッシュテーブルなら一瞬で済む

**デフォルトの名無しさん** · 2020/06/16(火) 23:57:59.42

訂正orz、
誤： 10億個の文字列
正： 10億個のノードの文字列

**デフォルトの名無しさん** · 2020/06/17(水) 01:21:46.64

>>440
>N はわかったんだけど、 M もやっぱり最悪ケースの話ってことで合ってる？
>「通常はO(1)」って言ってるし。
ハッシュ値の値の種類が仮に1024個だとすると、
データの個数がMが1024に収まる範囲だと検索時間が増えないのでO(1)と言えます。
しかし、Mが、1024*1024 個になった場合、1つのハッシュ値あたり、1024個の
キーが入ってしまう事になりますので、Mが1024個の時に比べて検索時間は1024倍に
なります。
これも、Mがある範囲内ではO(1)と言えますが、Mが極端に大きいと、やはり、O(M)となりますね。

**デフォルトの名無しさん** · 2020/06/17(水) 02:05:09.95

補足しておくと、>>435で
>ハッシュを遣わなくて単純に比較した場合は、
>O(MN)
と書きましたが、ハッシュを使わない場合でもキーがランダムに近い場合、ここまで悪くなくて
検索時間は、O(M) 程度で済みます。
なぜかというとキーの文字数Nが長くなっても、比較は先頭の方の文字をいくつか調べる
だけで異なることが分かってしまうことが多いためです。
少し複雑ですが、この事情は、文字数Nを大きくしても余り変わりませんが、
Nを固定して、データの個数Mを大きくしていった場合、だんだんと文字列を長く調査しないと
判断が付かないケースが増えてきます。
そのため、O(M^2)のような傾向が出てくるはずです。
ただし、これは、ハッシュを使わない場合で、かつ、キーがランダムの場合です。

**デフォルトの名無しさん** · 2020/06/17(水) 06:19:39.75

>>441
識別子に使えない文字が含まれているが
本当にアクセス違反まで行ったのか？
コンパイルが通らないはずだぞ

**デフォルトの名無しさん** · 2020/06/17(水) 06:22:30.70

>>442
左辺値参照を何だと思っている？
&tempは左辺値参照に渡せないし
tempを左辺値参照に渡したところで
forのブレースを抜けるたびにtempのdurationが満了していて
破棄済みのオブジェクト痕跡への参照になるだけだ

**デフォルトの名無しさん** · 2020/06/17(水) 06:25:00.03

読み違えてたｽﾏﾝｺorz
キーというのは検索する文字列そのものを指していたのかそうか…。n_

一方>>446-447は
　キー　=　ハッシュキー
　ハッシュ = ハッシュキー
　N = ハッシュキーの長さ
の意味で書いていた、、、。...n_

**デフォルトの名無しさん** · 2020/06/17(水) 08:27:10.85

つーかそれ以前の問題で左辺値参照はdefault constructibleでないので
そもそもvectorの要素になれない

**デフォルトの名無しさん** · 2020/06/17(水) 10:02:38.14

>>443
凄い。しっかり動きました。ありがとうございます。
moveのこと全然理解できてないんで勉強します。

**デフォルトの名無しさん** · 2020/06/17(水) 10:38:40.12

富豪ですね判ります

**はちみつ餃子** ◆8X2XSCHEME · 2020/06/17(水) 11:38:12.26

>>456
今の C++ (C++11 以降) だと vector の要素に求める要件 (requirements) の中に DefaultConstructible は無いよ。
各メンバ関数 (コンストラクタも含む) の要件として要素が DefaultConstructible であることを要求するものはあるけど。

アロケータの方の要件で参照はダメってことになってるみたいなんで参照が駄目には違いないんだけど、
DefaultConstructible でないというのは直接の理由ではない。

**デフォルトの名無しさん** · 2020/06/17(水) 11:50:02.38

&&はテンプレートでは左辺にも右辺にもなる

**デフォルトの名無しさん** · 2020/06/17(水) 13:02:53.13

>>452
すみません、
>そのため、O(M^2)のような傾向が出てくるはずです。
これは忘れてください。
ハッシュを使わない場合の話ですが、Mが大きくなってもこのような傾向は出ず、
O(M)のままだと思われます。
なぜなら、同じハッシュ値に属するそれぞれのキーと、与えられたキーとの完全一致を
検査する際、何文字目で一致し無い事が分かるかについては、データの個数Mが大きく
なっても、その期待値は変化しないと考えられるためです。
つまり、完全一致検査時に、個々のキーとの完全一致検査をループして行う時、
1つずつのキーと与えられたキーとが一致し無い事が分かるまでに検査が必要な
先頭からの文字数の平均値は、データの個数が多くなっても変化しないと考えられます。
そのため、この検査に必要なトータル時間は、α・M のようになり、
αが定数になるため、記号で書けば O(M) となります。

**デフォルトの名無しさん** · 2020/06/19(金) 05:28:33.37

windowsのフラットデザインのほうのuiですが、これがC#というやつですか？すごく起動が遅い

**デフォルトの名無しさん** · 2020/06/19(金) 09:08:14.85

>>462
uwpかwpf
言語はあまり関係ないない
あとスレチ

**デフォルトの名無しさん** · 2020/06/19(金) 09:47:56.41

どうもです

>>463
guiが重いということですかね

**デフォルトの名無しさん** · 2020/06/19(金) 23:16:25.19

C++の仕様になぜＧＵＩがない
言語が強制すればＯＳが統一できるのに

**デフォルトの名無しさん** · 2020/06/19(金) 23:21:04.03

幻想だよ

**はちみつ餃子** ◆8X2XSCHEME · 2020/06/20(土) 01:10:58.81

>>465
出来ない仕様を作ったら仕様ごと無視されるだけだよ。
C++ はたとえ不格好になっても現実的であることを指向してる。

**デフォルトの名無しさん** · 2020/06/20(土) 01:14:26.54

GUIなんて流行ですぐ方法論も見た目もかわっちまうからな
20年ぐらい前ならウィンドウに必ずクローズボタンがあるみたいなの
必須だったろうけど、今のGUI設計でそんな前提の設計したら
「脳味噌20年前でとまっとるんか」いわれるのがオチ
スクロールバーとかもどんどん消えてるよな

**デフォルトの名無しさん** · 2020/06/20(土) 01:28:11.81

まぁ上っ面をなぞるだけの平凡なGUIでもC++で規定してくれたら嬉しいけどねぇ
OSによらず同じC++のコードだけで簡単なGUIを出せるってなると色々捗る気はする

**デフォルトの名無しさん** · 2020/06/20(土) 02:01:25.69

そろそろ音声ユーザーインターフェイスはよ

**デフォルトの名無しさん** · 2020/06/20(土) 03:39:21.03

>>469
初期のJavaみたいなのかな
あれがC++にあったら、確かに便利だわな

**デフォルトの名無しさん** · 2020/06/20(土) 03:43:42.23

>>469
絶対駄目。
QtやFlutter、Unoなど、それを生業にしている民間業者がいるんだから、
民業圧迫になる。

**デフォルトの名無しさん** · 2020/06/20(土) 03:44:49.57

>>472
C++ BuilderのGUIや、MFC、WinForms、WPFなども売り物だ。
それを統一してしまったら民主主義でも資本主義でもなくなってしまう。

**デフォルトの名無しさん** · 2020/06/20(土) 03:58:41.18

もしそんなものを定義してしまったら、処理系を開発する会社が完全なる下請けになるじゃないか。

**デフォルトの名無しさん** · 2020/06/20(土) 06:11:52.19

GUIやデータ構造に関しては現行はXMLに統一って流れじゃないかね
当然重くなるけど今はマシンパワーでカバーする感じ
そのうちXMLパーサーがハード化されてストレスなくなるだろうよ

**デフォルトの名無しさん** · 2020/06/20(土) 06:55:31.33

>>472-474
標準って何のためにあると思う？

**デフォルトの名無しさん** · 2020/06/20(土) 07:21:58.33

PythonとC++でI/Oの速度って変わるの？

**デフォルトの名無しさん** · 2020/06/20(土) 08:17:17.83

変わるよ
亀と兎くらい

**デフォルトの名無しさん** · 2020/06/20(土) 08:19:37.12

>>478
システムコール呼ぶだけなのになんで違うん？

**デフォルトの名無しさん** · 2020/06/20(土) 08:25:37.47

ゴールを呼ぶまでに差が生まれる

**デフォルトの名無しさん** · 2020/06/20(土) 09:06:19.16

んな変わらんってことねサンキュー

◆QZaw55cn4c · 2020/06/20(土) 10:04:49.91

>>469
java の awt レベルでいいから欲しいですねえ

**デフォルトの名無しさん** · 2020/06/20(土) 10:14:39.22

C++標準でも外部でも良いから簡単な記述で簡素なGUI作れるようになってほしいなあ

**デフォルトの名無しさん** · 2020/06/20(土) 11:25:01.67

>>477
測定するのが基本

**デフォルトの名無しさん** · 2020/06/20(土) 11:59:28.75

ファイルシステムなんかは事実上ほぼ仕様が枯れてきてるから標準化できたけど
この意味GUIはまだ枯れてないからな

**デフォルトの名無しさん** · 2020/06/20(土) 12:00:20.85

>>473
中の人？
飯の種がなくなるから新しい技術を導入するなっていうのは流石に賛同得られないぞ

**デフォルトの名無しさん** · 2020/06/20(土) 12:01:02.76

エンドユーザーがC++とはアプリの外見のことだなんて誤解するようになるのはやだね

**デフォルトの名無しさん** · 2020/06/20(土) 12:05:52.12

既存のどのGUIを基本にするかってだけで宗教論争起こすだろ

**デフォルトの名無しさん** · 2020/06/20(土) 12:10:58.69

外見くらい好きに作らせろ

**デフォルトの名無しさん** · 2020/06/20(土) 12:12:20.45

こいうのは一種の中二病だよね
実際やってみれば
細かい制御ができない大雑把仕様
か
大掛かりなオレオレ仕様で学習が困難
ってなるのがオチ
おっさんになればわかる

**デフォルトの名無しさん** · 2020/06/20(土) 12:17:29.80

>>486
それらの中の人なら>>473みたいな的外れな馬鹿げた主張はしないと思う

**デフォルトの名無しさん** · 2020/06/20(土) 12:25:31.96

可能性あるとしたらwebkitを共通仕様にするって線かな
でかすぎるけどね

**デフォルトの名無しさん** · 2020/06/20(土) 12:35:51.45

フルスペックのGUIフレームワークではなく、ちょっとしたテストやデバッグに役立つ程度の簡素なものでもあると嬉しいんだけどね。

**デフォルトの名無しさん** · 2020/06/20(土) 12:38:41.23

>>493
Windows使えや。

**デフォルトの名無しさん** · 2020/06/20(土) 13:10:07.38

規格を統一するとgcc/clangのような無料コンパイラと差異がなくなってしまうため、MSはC++を主流サポートから外してしまって結果的にC++は落ち目となった。
GUIまで統一したら、今度こそC++は完全に見捨てられよう。
そうなったらWindows支配も終わるかもしれないが、プログラマには大混乱が起きる。

**デフォルトの名無しさん** · 2020/06/20(土) 13:12:32.66

>>495
GUI統一の動きがあっても、MSはサポートせずに、MingWだけがサポートする可能性がある。
Qtも自分のアドバンテージがなくなるのでサポートするわけなかろうし。
clangはAppleなのだからiOSやMacに支障を来たすためサポートしないだろう。
結果、gccだけがサポートする変な仕様として終わる。

**デフォルトの名無しさん** · 2020/06/20(土) 13:18:22.13

それに、gccには既にGTKがあり、彼らの中では統一規格になっている。
それが彼らの中では世界標準である。

**デフォルトの名無しさん** · 2020/06/20(土) 13:30:02.11

c++ってMSの主流じゃね？
C#の方がおこぼれっぽい

**デフォルトの名無しさん** · 2020/06/20(土) 13:33:04.69

またこのキチガイかよ…
連投する度に頭ん中に新しいお花畑でも作ってんのか？

**デフォルトの名無しさん** · 2020/06/20(土) 13:46:04.14

すでにお花畑に埋もれているんだろう

**デフォルトの名無しさん** · 2020/06/20(土) 16:36:26.09

カーネルがC#になる。

**デフォルトの名無しさん** · 2020/06/20(土) 18:44:23.71

どんどんゴミ化していくWin10の究極奥義か

**デフォルトの名無しさん** · 2020/06/20(土) 20:16:12.65

Win10Update作成者本人もなんで領域がRAWになるかわからないとかいう更新入れたくないよなというか強制だし

**デフォルトの名無しさん** · 2020/06/21(日) 00:11:33.65

WSL2だけ欲しいけど2004は怖くて入れられない

**デフォルトの名無しさん** · 2020/06/21(日) 09:18:33.28

>>475
みんな結局JSON使ってる気がする

**デフォルトの名無しさん** · 2020/06/21(日) 09:36:46.75

XMLは実際に扱ってみればわかるが
自由度が高すぎるが故にパーシングがめっちゃ重い
手作業で変更とかされるとなんだかよくわからない
エラーで読めなくなることがあって難儀することが
まれによくある
タグで括るという無駄の多い構造のため必要な保存
情報のサイズに比してファイルサイズがやたらと
でかくなる
等々ロクなことがない

**デフォルトの名無しさん** · 2020/06/21(日) 09:42:48.12

だな

**デフォルトの名無しさん** · 2020/06/21(日) 22:56:51.71

xmlnsの扱いがめんどい

**デフォルトの名無しさん** · 2020/06/22(月) 12:33:37.61

boost::property_treeで使える範囲にしとくんだろうね。