C++相談室 part142

**デフォルトの名無しさん** · 2019/04/01(月) 22:17:05.84

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

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

前スレ
C++相談室 part137 (正しくはpart138)
http://mevius.5ch.net/test/read.cgi/tech/1535353320/
C++相談室 part139
https://mevius.5ch.net/test/read.cgi/tech/1538755188/
C++相談室 part140
https://mevius.5ch.net/test/read.cgi/tech/1547326582/
C++相談室 part141
https://mevius.5ch.net/test/read.cgi/tech/1550772463/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1530384293/

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

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

----- テンプレここまで -----
-
VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

**デフォルトの名無しさん** · 2019/04/14(日) 20:25:38.94

>>283
関数内では const& であることを根拠に最適化に使えないのは合ってる。
でもだからといって const& で受け取ったものを書き換えてもよいとは言えない。

void f1(int const&);
int f2()
{
int const x = 1;
f1(x);
return x;
}

x は int const なので、 f2() の return x は f1() が const_cast して x を
書き換える可能性を無視して return 1 に最適化できる、という話。

BarWithBigData const x; が >>275 のコピーコンストラクタに渡された後も
const_cast<BarWithBigData&>(rhs).m_pBigData = NULL; を無視して書き換え前の
m_pBigData が使われる可能性がある。

**デフォルトの名無しさん** · 2019/04/14(日) 20:33:37.36

規格が云々言わなくても、9割のプログラマの意図に反してるで終わる話
頼むからそんなコードは頭の中にしまっといてほしい

**デフォルトの名無しさん** · 2019/04/14(日) 20:37:26.81

つまりはそれ自体は問題ないが、constとして生成したオブジェクトを渡した瞬間にダメになると言うことか
で、渡すこと自体は制限できないから
プログラム中に罠を仕掛ける事が出来るわけだ。

**デフォルトの名無しさん** · 2019/04/14(日) 20:39:28.07

てか、mutable付けとけば問題なくなるな。

**デフォルトの名無しさん** · 2019/04/14(日) 20:40:25.78

const_castも要らないし良いことずくめじゃないかw

**デフォルトの名無しさん** · 2019/04/14(日) 20:45:26.81

>>285
わかりたそうする。>>275のケースは素直にムーブコンストラクタを使えば良い。または↓でもだいたいおk
BarWithBigData::BarWithBigData(BarWithBigData& rhs) { m_pBigData = rhs.m_pBigData; rhs.m_pBigData = NULL; }

だいたいというのはムーブコンストラクタ有りの規格のC++コンパイラで↑の非constなコピコンだけ書く警告が出ることがあるからｲﾔﾝ、

>>286
>つまりはそれ自体は問題ないが
いや問題がある可能性が潰せていない。
void f1(int const&);
int f2()
{
int x = 1;
f1(x);
return x;
}
（xがconst無し)の場合であってもf1(x)がxを書き換えない前提の最適化がf2()にかかったりすると、
f1(x)内で変更したxの値がreturnされるxの値に反映されない可能性がある（f1(x)の呼び出し前後でxがレジスタに乗ったままであるとか、

**デフォルトの名無しさん** · 2019/04/14(日) 21:11:05.08

>>289
その x の型は const じゃないから return x は最適化できないよ。

**デフォルトの名無しさん** · 2019/04/14(日) 21:48:29.79

>>281
わからないです。それはメリット？

**デフォルトの名無しさん** · 2019/04/15(月) 01:36:50.54

ラムダに11個の引数を参照で渡すのと、キャプチャするの、どっちが速いかな？

**デフォルトの名無しさん** · 2019/04/15(月) 02:40:05.27

測ればいいだろ

**はちみつ餃子** ◆8X2XSCHEME · 2019/04/15(月) 02:50:17.52

>>291
メリットのときもデメリットのときもあるだろう。

**デフォルトの名無しさん** · 2019/04/15(月) 02:59:24.82

参照渡しな時点でその場で呼び出すのだろ。
最適化かければ結局同じようなアセンブリになるよ。

**デフォルトの名無しさん** · 2019/04/15(月) 09:13:13.35

それはわからんだろ
ブロック待ちするかもしれないわけで

**デフォルトの名無しさん** · 2019/04/15(月) 19:29:41.18

引数で渡すとスタックに積まれる可能性があるけど、キャプチャするとそうならないのでは。

**デフォルトの名無しさん** · 2019/04/15(月) 19:36:28.26

いや、形式上は無名クラスにキャプチャを変数としてぶちこんだもののインスタンス作ってメンバ関数のoperator()呼ぶのだから、スタックは使うだろ。

**デフォルトの名無しさん** · 2019/04/15(月) 20:08:47.93

C言語じゃダメなんですか！

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

いいよ

**デフォルトの名無しさん** · 2019/04/15(月) 20:25:01.30

無駄に複雑にしとるな。

**デフォルトの名無しさん** · 2019/04/16(火) 01:01:07.13

>>298
じゃあ、引数で渡すとスタックに積まれない可能性があるので、速い場合もあるのでは？

**デフォルトの名無しさん** · 2019/04/16(火) 02:15:09.28

海外だと、Javaに負けて、Rustに圧倒的実力で追いやられるC++

**デフォルトの名無しさん** · 2019/04/16(火) 02:27:07.22

>>303
https://insights.stackoverflow.com/survey/2019#technology-_-what-languages-are-associated-with-the-highest-salaries-worldwide

**デフォルトの名無しさん** · 2019/04/16(火) 15:01:04.19

本当に、コンパイル時に何かしたいならRustだけどね

**デフォルトの名無しさん** · 2019/04/16(火) 18:28:44.44

>>304
Java圧倒的な強さだな。

**デフォルトの名無しさん** · 2019/04/16(火) 18:30:10.89

全部足すと500%位になりそうだから、複数の言語を使う人が多いんだろね。

**デフォルトの名無しさん** · 2019/04/16(火) 21:18:54.40

江添が転職できずに困っとるw
まあこいつがクソなだけでc++の問題ってわけじゃないんだがイメージは悪いわな。

**デフォルトの名無しさん** · 2019/04/16(火) 21:36:49.03

こうしてみるとホッシーの全タクシー移動ってのは理に適ってるな
バカな公害に捕まる心配が減る

**デフォルトの名無しさん** · 2019/04/16(火) 23:25:27.27

なんか私怨でもあるんかいな

**デフォルトの名無しさん** · 2019/04/16(火) 23:41:35.10

喫煙者が目に入った途端癇癪起こして殴り掛りかかる狂犬なんだっけ？

**デフォルトの名無しさん** · 2019/04/17(水) 00:03:12.24

知らね
よく人を招いているようだし揉めたことがある人も少なくはないんじゃいか

**はちみつ餃子** ◆8X2XSCHEME · 2019/04/17(水) 01:12:11.58

>>310-311
当事者の様々な主張の食い違いがあるので、結論としては「わからない」。
少なくとも彼自信の主張としては掴みかかってきたのを払いのけた結果として眼鏡が割れたということになっている。
(江添が殴りかかったわけではなく、むしろ防衛した側、と江添は主張している。)

江添が煙草について過激な意見を持っているのは確かだが、
シェアハウス内で禁煙場所であると合意がなされている場所で煙草を吸った客人がいたというところは当事者全体が認めているようだ。

**デフォルトの名無しさん** · 2019/04/17(水) 08:21:52.75

恨みというかまともにコード書かない奴がクソ意見で現場荒らすって事自体がクソだと思うわけで、
まあその反動で現場で働くことができないって事になればザマァって思う。

**デフォルトの名無しさん** · 2019/04/17(水) 09:46:31.27

現場を荒らしてる？

**デフォルトの名無しさん** · 2019/04/17(水) 09:53:30.15

どのプロジェクトにも参加してないと認識してたけど乗り込んでケチつけてたりするのかな
まあ俺ドワンゴとは縁が無いからどこで何してようが関係ないけど

**デフォルトの名無しさん** · 2019/04/17(水) 17:08:02.09

C++がPython抜いて3位 - 4月TIOBE言語ランキング　2019/04/17 10:55　後藤大地
https://news.mynavi.jp/article/20190417-810363/

TIOBE Softwareから、2019年4月のTIOBE Programming Community Index (PCI)が公開された。
TIOBE PCIは、複数の検索エンジンの検索結果から、対象となるプログラミング言語が
どれだけ話題になっているかをインデックス化したもの。

4月TIOBE Programming Community Index / 円グラフ
https://news.mynavi.jp/article/20190417-810363/images/001.jpg

2019年4月はC++がPythonを抜いて3位に返り咲いた。ただし、Pythonのシェアが下落したの
ではなく、Pythonの増加傾向をC++の増加が上回ったことによる結果と思われる。C++は
長期にわたって下落傾向が続いていいたものの、2019年に入ってから増加傾向へ転じている。
Pythonも増加傾向が続いており、どちらも今後さらにインデックス値を増やす可能性がある。

長期にわたって1位を確保しているJavaは依然として1位のポジションにあるが、下落の
傾向が続いている。2位のC言語も長期で見ると下落を続けており、C++やPythonの存在感が
強くなってきている。

**デフォルトの名無しさん** · 2019/04/17(水) 17:11:50.34

>>317
何回だからみんな何回もググってるんだよ

**デフォルトの名無しさん** · 2019/04/17(水) 18:34:58.84

俺が検索しまくったからだろうな。

**デフォルトの名無しさん** · 2019/04/17(水) 19:59:29.56

今もしインターネットが完全にシャットダウンされると
プログラム書けなくなるプログラマけっこう数いるだろうな

**はちみつ餃子** ◆8X2XSCHEME · 2019/04/17(水) 20:18:46.81

>>320
cpprefjp はとりあえず手元にダウンロードしてあるけど。

**デフォルトの名無しさん** · 2019/04/17(水) 20:35:09.94

どうやってダウンロードしたの？
巡集じゃできなかった…

**デフォルトの名無しさん** · 2019/04/17(水) 20:39:18.77

githubじゃない？

**デフォルトの名無しさん** · 2019/04/17(水) 21:27:54.32

そうなんだ、ありがとう

**デフォルトの名無しさん** · 2019/04/19(金) 02:16:29.43

どういたしまして。

**デフォルトの名無しさん** · 2019/04/19(金) 08:26:54.03

江添は職質裁判でも、不当判決が出たので控訴するみたい

警官は、複数人で口裏合わせするから、民間人は勝てない

漏れもやられたけど、酒酔い運転でも、漏れが機械に息を吹き掛けても、ランプが点かない。
そこで、警官がクルッと後ろを向くと、ランプが点く

そっと見たら、酔っ払い警官が、自分で息を吹きかけて、ランプを点ける

こういう裁判で争っている人もいるけど、
警官は複数人で口裏合わせするから、絶対に勝てない！

警官は皆、このやり方で出世しとる

**デフォルトの名無しさん** · 2019/04/19(金) 08:33:03.47

ありゃ普通に対応してりゃ済む話だと思うがね。

やってることは完全に当たり屋だろ。

**デフォルトの名無しさん** · 2019/04/19(金) 09:27:15.01

>>326
Rubyバカの人か。相変わらず思い込みが激しく、言っていることが滅茶苦茶だな。

**デフォルトの名無しさん** · 2019/04/19(金) 12:05:02.85

どんだけ江添好きなの？ｗ

**デフォルトの名無しさん** · 2019/04/19(金) 13:28:48.91

日本でC++真剣にやってるのって彼だけだし

**はちみつ餃子** ◆8X2XSCHEME · 2019/04/19(金) 13:41:25.74

だけ、というのは言い過ぎだと思うが、
日本語で最新の C++ の事情を本にしているのは江添くらいしかいないからなぁ。

江添本人は自分のことを実務家ではなく教育者だと考えているようだし、
(肩書は何なんだろ？エヴァンジェリストのようにも見えるが……)
今のポストは妥当なとこだろ。
そのままやってくれればありがたいもんだ。

**デフォルトの名無しさん** · 2019/04/19(金) 13:41:50.58

つまり他の日本人は竹刀とか木刀ってことか。

**デフォルトの名無しさん** · 2019/04/19(金) 13:50:35.12

江添個人の裁判は完全にスレチなんだよなあ
仮に違法な取り締まりだと判断されても警察のやり方が改まるわけもないだろうし

**デフォルトの名無しさん** · 2019/04/19(金) 14:15:26.68

江添すなわちC++なのだから
江添の話題は全てC++の話題だょ

**デフォルトの名無しさん** · 2019/04/19(金) 15:08:33.32

宗教の話はよそでやってくれないか

**デフォルトの名無しさん** · 2019/04/19(金) 15:16:01.57

もう少しc++の話をしてくれと思う事もある

**デフォルトの名無しさん** · 2019/04/19(金) 18:50:10.05

はちみつさんも真剣にやってると思います。

**デフォルトの名無しさん** · 2019/04/19(金) 19:16:13.92

こんな事言うと勘違いされそうだが、はちみつ餃子はちゃんとしてると思うよ
C++に関しておかしなことは言っていない
ていうか、はちみつ餃子ってものすごい不味そうなんだがそんなの本当にあるのだろうか・・？

**デフォルトの名無しさん** · 2019/04/19(金) 19:17:39.46

肉料理にはちみつを入れること自体はわりと普通
量の問題

**デフォルトの名無しさん** · 2019/04/19(金) 19:28:19.17

いや明らかに開発してねーだろって感覚じゃねーか。
まあここならそれでもいいんだろうけれど。

**はちみつ餃子** ◆8X2XSCHEME · 2019/04/19(金) 19:51:37.44

>>338
ググればわかるけどはちみつ餃子はそこそこありふれた料理だよ。

その昔、 higepon が自分でもどうして higepon などと名乗ったかわからない
と述べていたので、そのくらい意味不明感じにしようと思って適当に
思いついた語をコテハンにした。
Scheme スレが本来の住処なので当初は SCHEME餃子と名乗っていたけど、
他のスレにも顔を出すようになったのでなんとなくはちみつ餃子になった。
およそ意味不明な組合せにしたつもりだったんだけど、
実際にある料理だとは後になってから知った。

**デフォルトの名無しさん** · 2019/04/19(金) 21:11:54.81

initializer_listを引数に取るオブジェクトを引数に取る関数で
下記のケースでUniversal Initializationが効かないのですが
何かいい手はないでしょうか

using KVPCollectionType = std::map<std::string, std::string>;
void f(const KVPCollectionType&& kvps = {});

f(); // OK
f({}); // OK
f(KVPCollectionType{{"key1", "value1"},{"key2","value2"}}); // OK

f({{"key1", "value1"},{"key2","value2"}}); // NG これをやりたい！！

**デフォルトの名無しさん** · 2019/04/19(金) 21:13:17.21

エピ…いや何でもない

**デフォルトの名無しさん** · 2019/04/19(金) 21:17:05.52

すみません、訂正です
×　void f(const KVPCollectionType&& kvps = {});
○　void f(const KVPCollectionType& kvps = {});

**デフォルトの名無しさん** · 2019/04/19(金) 21:22:53.30

アークエンジェルに搭載されてるstd::variant<>。

**デフォルトの名無しさん** · 2019/04/19(金) 22:49:42.25

wandboxで試したらclangでもgccでもc++11 -pedanticで通ったけど？

**デフォルトの名無しさん** · 2019/04/20(土) 00:01:37.25

ごめんなさい、ごめんなさい。本当にごめんなさい。
勝手に脳内で要約したのが間違えまくってました

正確には以下の通りです。
#include <map>
#include <memory>
using KVPCollectionType = std::map<std::string, std::string>;
class c {
public:
c(const KVPCollectionType&& kvps = {}){}
};
int main()
{
auto ok = std::make_shared<c>(KVPCollectionType{{"key1", "value1"},{"key2","value2"}}); // OK
auto ng = std::make_shared<c>({{"key1", "value1"},{"key2","value2"}}); // NG!!!
}

**デフォルトの名無しさん** · 2019/04/20(土) 10:47:21.77

全てのバグを絶滅せよ。
「今日は死に日和」好評発売中。

**デフォルトの名無しさん** · 2019/04/20(土) 11:08:43.59

C++11や14を使ってる人、コンパイラは何ですか。

**デフォルトの名無しさん** · 2019/04/20(土) 11:25:30.96

ゲームエンジン作ってる人いますか

**デフォルトの名無しさん** · 2019/04/20(土) 11:30:38.02

clとgcc。

**デフォルトの名無しさん** · 2019/04/20(土) 13:20:15.93

c+11以降はバージョン違うと全く別のコンパイラ

**デフォルトの名無しさん** · 2019/04/20(土) 13:23:19.12

Twitchでプログラミングしてるやつの中でゲームエンジンも居たような

**はちみつ餃子** ◆8X2XSCHEME · 2019/04/20(土) 13:30:02.11

>>347
テンプレートの推論ルールとして「関数テンプレートのパラメータとして波カッコの初期化子リストを渡して型推論させることはできない。」
ということになっている。 ( https://cpprefjp.github.io/lang/cpp11/uniform_initialization.html )
make_shared の実際の型は template <class T, class... Args> shared_ptr<T> make_shared(Args&&... args); なので、
このとき Args が推論できない以上はどうにもならん。
型を固定した専用の関数をはさんでこんな感じにするくらいのことしか思いつかないな。

#include <map>
#include <memory>
#include <initializer_list>
#include <utility>

using KVPCollectionType = std::map<std::string, std::string>;
class c {
public:
c(const KVPCollectionType&& kvps = {}){}
c(const std::initializer_list<typename KVPCollectionType::value_type>){}
};

std::shared_ptr<c> make_c_shared(std::initializer_list<typename KVPCollectionType::value_type> a) {
return std::make_shared<c>(std::move(a));
}

std::shared_ptr<c> make_c_shared(KVPCollectionType&& a) {
return std::make_shared<c>(std::move(a));
}

int main() {
auto ok = make_c_shared(KVPCollectionType{{"key1", "value1"},{"key2","value2"}});
auto ng = make_c_shared({{"key1", "value1"},{"key2","value2"}});
}

**はちみつ餃子** ◆8X2XSCHEME · 2019/04/20(土) 13:32:51.70

>>347 >>354
呼出す側で

auto ng = std::make_shared<c, std::initializer_list<typename KVPCollectionType::value_type>>({{"key1", "value1"},{"key2","value2"}});

というように型を明記してもかまわないけど、使う側でいちいちこんなこと書きたいわけじゃないだろ？

**はちみつ餃子** ◆8X2XSCHEME · 2019/04/20(土) 13:35:42.76

>>347
ちゃんと考えたら >>354 はいらんことしとるな……
これで充分か

#include <map>
#include <memory>
#include <utility>

using KVPCollectionType = std::map<std::string, std::string>;
class c {
public:
c(const KVPCollectionType&& kvps = {}){}
};

std::shared_ptr<c> make_c_shared(KVPCollectionType&& a) {
return std::make_shared<c>(std::move(a));
}

int main() {
auto ok = make_c_shared(KVPCollectionType{{"key1", "value1"},{"key2","value2"}});
auto ng = make_c_shared({{"key1", "value1"},{"key2","value2"}});
}

**デフォルトの名無しさん** · 2019/04/21(日) 08:19:35.76

>>354-356
ありがとうございます、その手を使わせていただきます
状況によって推定ルールが変わるのはやめて欲しいなってちょっと思ったんですけど。

**デフォルトの名無しさん** · 2019/04/22(月) 23:55:58.01

メンバアクセスにthis->つける？

**デフォルトの名無しさん** · 2019/04/23(火) 00:01:58.24

エディタの補完機能使いたいときにたまにそうやって補完して最後に消す。
が、たまに忘れる。

**デフォルトの名無しさん** · 2019/04/23(火) 00:02:35.52

IDEの都合で付ける事が良くある
付けないと補完候補多すぎて

**デフォルトの名無しさん** · 2019/04/23(火) 00:09:08.10

ああなるほど
補完候補を絞るのには便利ですね

**デフォルトの名無しさん** · 2019/04/23(火) 18:16:01.64

メンバであるという保証ができるので付ける

**デフォルトの名無しさん** · 2019/04/23(火) 19:39:28.32

メンバ名は頭にm_付けろみたいなクソルールよりずっといいと思うので付けるべき

**デフォルトの名無しさん** · 2019/04/23(火) 19:42:38.83

仮引数と別の名前つけるのだるいからm_は別に良いと思う

**デフォルトの名無しさん** · 2019/04/23(火) 20:02:01.86

メンバ変数に専用の色付けたらいいじゃん

**デフォルトの名無しさん** · 2019/04/23(火) 20:13:43.06

引数そのままメンバに入れるなら引数に_つけてvar(_var)って初期化してるわ

◆QZaw55cn4c · 2019/04/23(火) 20:16:13.74

>>366
それって var(var) でも問題ないんですよ…

**さまよえる蟻人間** ◆T6xkBnTXz7B0 · 2019/04/23(火) 21:18:06.78

バーバー

**デフォルトの名無しさん** · 2019/04/23(火) 21:32:08.36

>>367
綴り間違えたら悲惨なことになった

**デフォルトの名無しさん** · 2019/04/23(火) 21:34:08.78

ハンガリアン記法は、入力補完のないエディタ上での可読性を高めるのに役立ってるでしょ。今でも。

**デフォルトの名無しさん** · 2019/04/23(火) 21:35:06.30

ゴミ使ってる奴のことなんか知らん

**デフォルトの名無しさん** · 2019/04/23(火) 21:36:10.37

あれ可読性落ちるだろ

**デフォルトの名無しさん** · 2019/04/23(火) 21:39:11.30

定期的にunsignedとsigned混在させてハマるアホをみるとハンガリアン必要だと思うわ

**デフォルトの名無しさん** · 2019/04/23(火) 21:40:37.34

C#で入力補完のないエディタがどうとかさすがにナンセンスでは
だってvisual studio使うじゃん

**デフォルトの名無しさん** · 2019/04/23(火) 21:41:16.53

どっちでもいいわ。
大抵の場合そんなとこに気を使わんといかんコードになってることのが問題。

**デフォルトの名無しさん** · 2019/04/23(火) 21:45:47.89

>>375
こういうやつがそのうちハマって丸１日つぶしたりするんだよなw

**デフォルトの名無しさん** · 2019/04/23(火) 21:51:11.17

>>373
関係なくて草

**デフォルトの名無しさん** · 2019/04/23(火) 21:55:03.06

関係あることわかってなくて草

**デフォルトの名無しさん** · 2019/04/23(火) 21:55:54.04

黙ってろゴミｗ

**デフォルトの名無しさん** · 2019/04/23(火) 21:59:25.62

>>376
だから人を嵌めるようなコード書くなつってんだよばか。

**デフォルトの名無しさん** · 2019/04/23(火) 22:06:36.15

>>380
コードの問題じゃなくて言語仕様の問題だから
こういうえらそうなくせに何もわかってないカスが一番始末に困る

**デフォルトの名無しさん** · 2019/04/23(火) 22:53:19.60

いつの間にかハンガリアンが言語仕様になってた。。

**デフォルトの名無しさん** · 2019/04/23(火) 23:10:13.77

ハンガリアンも防御的なプログラミングと考えたら悪くないよ
成り立ち調べてみな
でも基本型とポインタだけだな
クラスには無用だと思う