C++相談室 part135

2018/03/31(土) 20:20:06.25

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

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

前スレ
C++相談室 part134
http://mevius.5ch.net/test/read.cgi/tech/1516406742/

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

■長いソースを貼るときはここへ。■
　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

2018/05/13(日) 12:17:41.91

話が長い上にどうでもよすぎる

2018/05/13(日) 12:26:54.36

またいつものキチガイか

2018/05/13(日) 12:43:30.13

>>756
おまえさんの頭がC++03のまま更新が止まってしまっていることはわかった

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-bFqk) · 2018/05/13(日) 12:46:19.41

>>759
そう判断した理由は？

2018/05/13(日) 12:51:49.36

C++11以後の「低級」を知らんだろ

2018/05/13(日) 13:01:15.34

C++xx
この末尾のへんなナンバリングが施されるようになったのっていつ頃から？

2018/05/13(日) 14:22:28.62

>>762
元々はC++09を狙ってたらしいから2008年頃じゃね？

◆QZaw55cn4c (ﾜｯﾁｮｲ 6360-bFqk) · 2018/05/13(日) 14:53:37.16

>>761
具体的に

2018/05/13(日) 15:27:50.96

>>764
人に聞くのは知らないからだな

2018/05/13(日) 15:47:31.87

>>759
STLが03から入ったと思ってんのか

あと
＞Cコンパイラってポインタ周りは最適化をかけないから、多分、
＞速度差はコンパイラ起因であって
こんなこと言ってる時点でID:PbE4ojLD0の話は聞くに値しない

2018/05/13(日) 16:22:20.14

>>766
あの流れからどうやってSTLが03からという話になったんだ？

2018/05/13(日) 17:44:42.77

>>756
馬鹿につき合ってすまんかった。

少なくとも俺とLinusは君と同じ定義で使ってるよ。俺の認識では世間もそう。
俺はこれでこれまで話が通じなかったことはないから。
おそらくはCをやらずにC++だけやってる世代と、
必ずCをやったうえでC++に進んだ世代の違いだ。
ゆとりだけで閉じてる世界では、彼らの主張する定義なのかもしれん。

ただまあ、話を聞いてる限り、こいつらは色々と無知だし、無知なことに無自覚だね。
まあもういいが。
自分が知らないだけのことをすべて間違いだと断定しているようでは上達しない。
C++erもここまでゆとり化が進んだのは残念だ。

2018/05/13(日) 19:37:46.91

本当に通じていたのかな？
いわゆるフツーの人達は、めんどくさいから適当に話し合わせてテキトーに打ち切るものだが…

2018/05/13(日) 20:05:09.29

ついでだからもう少し書いておいてやるよ。

ゆとりC++erが「C++は速い」ということにしたがるのは、C++「言語」以下の解像度がないからだ。
「C++コンパイラさえ使えばおｋ」になってくれてないと困るからこそ、そこに異常にこだわる。
(他言語でも同様に、低位実装を直感的に推測できない馬鹿はこの傾向がある）

お前らは>>722-723の結果、同じデータ構造で同じアルゴリズムを適用した物に対し、
速度差が出た場合にそれを「言語の差」と言い張るようだが、
それは明確な間違いだ。ただの不勉強でしかない。
実際、それだとそれ以上の最適化は出来ないだろ。
C出身者なら、必要ならasm書いてチューニングすることも出来る。

現在C++は失敗しつつある。
それはRustを見ても明らかだ。以下ページを見てみろ。
https://imoz.jp/note/rust-functions.html
スマポ(ｷﾘｯな連中にとってはC++よりもRustの方が明らかにいい言語だろ。（後発なので当たり前だが）

C++だけにすがるのは止めとけ。
もうそういう時代じゃないし、C++はそれを満たせる言語ではない。

2018/05/13(日) 20:17:51.87

別にC++とCの宗教論争に加わるつもりはないが、
お前qsortがstd::sortより遅くなりがちな理由わかってないだろ
アセンブラ使わんでも自分で書きゃCでも同等の速度は出る
（というかVCの最適化にハンドアセンブルで本当に勝てるんか？こいつ）

＞CよりもC++の方が速くなるコードの方があり得ないと思うが。
＞CのほうがC++より遅いケース出してみろ。ないから。
調べもせずにこんな決めつけを書く低レベルさ以前に
これをC++のスレで書くお前はどう見てもただの荒らしだから。

2018/05/13(日) 20:53:01.09

>>771
お前は根本的に勘違いしている。
出発点は自前のコードでもいいが、逆アセンブル結果でもいいんだから、
改善できなくとも、遅くなることはあり得ない。

アセンブラを読めない君らでは、これは無理だ。
そして、遅くなる可能性の方が高いからやらないってのは、
馬鹿な君らなりの対処法としては正しい。

まあ、C++スレではC++マンセーしないと荒らしだ、ってのは理解した。
C++erがそこまで落ちぶれたのは残念だが、俺は去るよ。

2018/05/13(日) 20:57:13.19

それぞれの言語の良くある使い方であれば
Cの方が速いコードもC++の方が速いコードも
どちらも存在する

同じ処理を同じように書けば普通は同じ速度
(ただし、一部細かい例外あり)

2018/05/13(日) 20:59:07.22

一般的な使い方では
C++の方が開発効率が高く
Cの方がバイナリの性能が高い事が多い
(もちろん逆になる要素もある)

2018/05/13(日) 21:06:47.71

>>772
以前ここに書いたこともあるけど、最近ET＋simd（SSE、NEONのイントリンシック）で
ゲーム用の自前の線形代数ライブラリとか作ったんで
＞アセンブラを読めない君ら
残念ながらこれは当てはまらないよｗ
どれだけ逆アセ読んで比較したか・・・・

＞C++マンセーしないと
お前が”正しい批判をしてれば”荒れてないんだよ

ついでに言えば、
＞「C++で書く」→カジュアルにSTLとか
STLをカジュアルとか呼ぶ辺り、最近のC++界隈は
「流行に流されて自分で考えることを放棄する」という、かつてJavaの流行に荒らされた時代と
同じ愚を犯してるな、とは思うけどねぇ
C++er憎し、では色々と話がおかしくなるよ

2018/05/13(日) 21:07:47.84

同じ処理を同じ動作で記述出来ない例

Cの可変長配列
C++の例外処理

2018/05/13(日) 21:09:03.49

もうアホらしくなって途中離脱したけど
例えば関数内のループで使ってるstd::unique_ptr が遅いからその部分だけ生ポインタに書き換えたら ID:tSRcUD9w0 は何言語で書いたって言うんだろ？
って言うのはちょっと気にはなる
まあまた明後日の長文書くだけだと思うけど w

2018/05/13(日) 21:32:59.83

禿は神。
禿4はバイブル。

2018/05/13(日) 21:41:37.55

禿５マダー？(tntn

2018/05/13(日) 22:13:01.62

>>775
> どれだけ逆アセ読んで比較したか・・・・
ならコンパイラ出力コードが手書きアセンブラと比べてどれだけ糞かも知ってるはずだ。
それでその言い方には矛盾を感じるけどね。

> STLをカジュアルとか呼ぶ辺り、最近のC++界隈は
その発言は俺ではないが、
基本的には抽象度を上げるのは簡単にプログラミングする為であって、
「カジュアル」という表現は妥当だ。
Cみたいに全部手でゴリゴリ書く意味なんて無い。
速度が問題ない部分は出来るだけ手抜きすべきだ。STLがそれに適しているのなら使えばいい。

ただ、「STL使わなくてもどうとでもなる奴が手抜きでSTLを使う」のと、
「STLを使わないと何も出来ない連中がSTLを使う」のは全然意味が違う。
とはいえ、俺は後者が前者になるべきだとは思ってない。
ただ、後者ならC++ではなくJavaやC#を使った方が妥当だとは思うが。

君が見落としているのは、STLをカジュアルと呼ぶ連中は、
基本的に、STLを使わずに最速な実装が出来るものの、面倒なので、
「手抜き」を「カジュアル」と言い換えてごまかしているだけだということだ。
連中は君みたいにSTLが無いと何も出来ない馬鹿ではないんだよ。

> C++er憎し、では色々と話がおかしくなるよ
これは違うぞ。俺は無知なくせにデタラメを言い張るゆとりは死ねと思っているだけだ。
ただし、お前が無知のままで死ぬ権利は尊重するので、
有用な情報は書かないようにするが。

2018/05/13(日) 22:14:29.75

キチガイにさわるな

2018/05/13(日) 22:15:45.94

密度が低い

**デフォルトの名無しさん** · 2018/05/13(日) 22:19:54.88

>>772
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。
>俺は去るよ。

2018/05/13(日) 22:28:00.02

吐いた唾は呑ませんぞ

2018/05/13(日) 23:48:52.64

>>780
> ならコンパイラ出力コードが手書きアセンブラと比べてどれだけ糞かも知ってるはずだ。
爺いは早めに滅びればいいのに

2018/05/14(月) 00:21:52.22

constexpr+UCS=ニューパラダイムのはずだったんだがなぁ。
コンパイルタイムは夢がある。

2018/05/14(月) 02:44:09.99

昔はライブラリもそんなに充実してなかったしアルゴリズム事典とか読み漁りながら色々自作してやってたけどね
しかしまぁ便利な時代になったもんだ
Ｃ言語だと型が変わるだけで使い物にならなくなっていたものが大半だったけど
型に囚われないSTLライブラリは本当に有能だよ
型に囚われない部分は全部インラインになっちゃうけどね

2018/05/14(月) 13:39:06.22

オンラインになるんか！

2018/05/14(月) 13:40:44.68

実行可能形式はC++、スクリプトはPython。
これができる大人の選択。

2018/05/14(月) 13:48:17.86

バッチは？

2018/05/14(月) 13:56:29.91

バッチは他人からパクるので贅沢は言いませぬ。

2018/05/15(火) 20:21:01.90

スタイルについての質問なんですけど、Cの文法で書けるならできるだけCで書いたほうがいいのでしょうか
上司のC++のコードがもうほんとゴリゴリのCって感じで、C++でcharの配列も無かろうよと思ったりするんですよ
確かにその方が分かる人は多くなるかもしれないですけど

2018/05/15(火) 20:32:27.71

>>792
C++ はひどい言語だ。これは、多くの平均以下のプログラマーが使ってるために
さらに輪をかけてゲロゲロになっていて、どうしようもないゴミが
簡単に生産されるようになってる。正直いって、C を選ぶ理由が C++ プログラマーを
追っぱらうため *だけ* だったとしても、それ自体、C を使う強力な理由になりうる。

C++ はトンでもなく悪い設計の元になりうる。どうせこの言語ではいつも STL やら
Boost やら、その他ゲロゲロベロベロの「素敵な」ライブラリの機能を使って、
それがあんたのプログラムに「役立つ」んだろうが、以下のことが起きる:

- うまく動かないときにもたらされる際限のない苦痛 (あと STL とか、特に Boost が
安定してるとか移植性があるとかいう奴は、どいつもこいつも大ウソつきで、
もはや笑えるレベルを超えている)

- 非効率な抽象プログラミングモデルで、2年たった後にこれらが実はそんなに
効率的じゃなかったことに気づくケース。でもそのときにはすでに全部の
コードがその素晴らしいオブジェクトモデルに依存していて、直すためには
アプリ全体を書き直さなきゃなんない。

言いかえれば、唯一まともで、効率がよくて、システムレベルで使えて、移植性がある
C++ ってのは、基本的に C で使える機能だけに限ったときなんだ。そして C だけに
限定するってことは、他の人がそれをめちゃくちゃにしないってことで、
ついでに沢山のプログラマが実際に低水準の問題を理解することができて、アホらしい
「オブジェクト・モデル」のたわごとを持ちこまないってことだ。

2018/05/15(火) 20:34:21.22

いや別に
C++で問題ない

上司の意図は知らんが
パフォーマンスを考えたコードとか
互換性を考えたコードとか
そういう可能性も
5chの一般的な価値観とは違って
C++っぽいのが良いコードって訳じゃない

2018/05/15(火) 20:36:35.58

逆に若者はコストも考えずに安易に汎用コンテナを使ったりと思うことがある

2018/05/15(火) 21:03:22.33

ものによるのじゃん？
メモリイメージを意識するならCスタイルの方がきれいにおさまる。

**デフォルトの名無しさん** · 2018/05/15(火) 21:09:12.04

バグを生む可能性が一切ないならCスタイルのほうがいいに決まってる

2018/05/15(火) 21:41:08.24

c言語って移植性あるの？まともなの？

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd43-CqHk) · 2018/05/15(火) 21:41:08.58

最近のC++は、std::vectorが配列に最適化されるのか？遅いだろ

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd43-CqHk) · 2018/05/15(火) 22:23:39.58

C++11以降ならstd::array使うけど、覚えることがともかく多い

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd43-CqHk) · 2018/05/15(火) 22:26:59.43

区間チェックしてくれる配列を簡単に指定できると嬉しいの†

**片山博文MZ** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd43-CqHk) · 2018/05/15(火) 22:31:58.98

例えば、[ ]を二重に書くと添字チェックしてくれるとか。どうかな。

int a[[10]];

2018/05/15(火) 22:42:37.30

atじゃだめなんか？

2018/05/15(火) 22:43:36.39

例外投げるインデクサと投げないインデクサ両方ありますから。

2018/05/15(火) 22:46:39.90

プロパティONにするとチェック有効で

2018/05/15(火) 22:46:50.65

>>802
オブジェトCを彷彿させるので嫌です

2018/05/16(水) 03:32:46.81

>>802
attributes構文と紛らわしい。

2018/05/16(水) 23:25:18.23

arrayはなんで［］でチェックしてくれないの

2018/05/16(水) 23:28:49.70

ゼロコストの原則

2018/05/17(木) 02:43:52.94

C++のコストの大部分は例外に起因するらしい。
Cでコンパイルできるコードであっても、C++としてコンパイルするとバイナリが肥大化する。
その原因は例外。

2018/05/17(木) 07:10:31.59

x86-64だとゼロコストだよ

2018/05/17(木) 08:34:28.77

どこにコストが消えたんだろ
サボってるの？

2018/05/17(木) 09:12:53.49

>>810 要出典。

2018/05/17(木) 14:51:21.43

x86-32だと割り込み発生時に対応出来るように
関数コールの度にスタックに情報を埋め込む

x86-64はこれが不要
割り込み処理がなければコストはかからない

2018/05/17(木) 18:56:39.80

>>813
組み込み開発の株式会社○○みたいなサイトで読んだんだけどな。
なかなかためになる内容だったしブックマークしとくんだった。
見つけたらリンクくれ。

2018/05/17(木) 18:58:28.25

俺の見解では、例外にコストが割かれるなら、それは必要なコストだと思うんだよな。

2018/05/17(木) 19:43:22.14

元記事消えてるっぽいからアーカイブだけど
http://bytepointer.com/resources/pietrek_amd_x64_primer.htm

Windowsの例外機構がx64ではスタックベースからテーブルベースの通過するだけならゼロコストなものに変わった
ただしバイナリサイズは増える

2018/05/17(木) 19:46:45.63

>>816
例外を使うならコストがかかるのは当然なんだが、
例外が通過しないかもしれないのにそこかしこで情報を積まないといけないのは良くないってことなんよ。
そんでまあ例外を投げたときだけにコストが生じる方式がいいよねっていう話。

2018/05/17(木) 20:29:27.85

例外が発生しない時のコストなんてゴミみたいなもんだけどな

2018/05/17(木) 20:30:03.35

イヤなら64bitで組みなさい

2018/05/17(木) 20:38:19.60

64ビット化するとサイズが1.5倍になるらしいけどな。

2018/05/17(木) 20:40:58.24

今時コードのサイズなんて問題にならんだろ
その代わりに得るものは大きい

2018/05/17(木) 21:11:41.72

1.5倍って40㎏の可愛い少女が60㎏のオバはんになるってことではないだろか。
さあどっちか選ぶんだ。

2018/05/17(木) 21:42:32.65

どうしても対応し続けないといけない32bitのレガシーデバイスがあるなら頑張って
そうじゃなけりゃもう32bitなんて捨てろ

2018/05/17(木) 21:43:14.24

>>823
それ得るもの無さすぎないか？

2018/05/17(木) 21:57:59.98

60kgのオッサンになるよりはいいだろ。

2018/05/17(木) 22:02:48.61

32bitがレガシーだあ？
どこで吹き込まれたか知らんが
騙されやすいやつだな

2018/05/17(木) 22:20:15.79

クラスのconst配列メンバをコンストラクタで初期化するにはどうしたらいいでしょうか？

class A
{
　const double array[];

　void A( double &temp[] ) : array(temp)
　{
　}
};

これはコンパイルでエラーが出てダメでした

**デフォルトの名無しさん** · 2018/05/17(木) 22:32:37.31

>>828
できないからあきらメロン

素直にconst外してアクセサで制御するか、vector使うかしとけ

テンプレートとかを駆使して無理に実現しようと試みるのはいかにも頭が悪いし時間の無駄

2018/05/17(木) 22:33:23.35

constの問題というよりサイズが決まってないからダメなんじゃないの？

**デフォルトの名無しさん** · 2018/05/17(木) 22:34:24.00

ここ3年ほど32bitの組み込み機器に触ったことない

2018/05/17(木) 22:37:16.99

今はほとんど64bitの上で無理矢理32bit動かしてるんだよ
ネイティブ32bitCPUなんて化石

2018/05/17(木) 22:51:21.67

>>829
了解です、constは諦めマスカット

>>830
どんなサイズの配列が来るかはコンストラクタが呼び出されるまでわからないんで
サイズは未定にしておきました

2018/05/18(金) 17:13:18.87

vc++のマルチコアのオプティマイズなんて甘々だから余裕で
勝てるけどなぁ。
あんなのに負ける人もいるって、世の中広いなぁ(棒)

**771** (ﾜｯﾁｮｲ b133-NTEn) · 2018/05/18(金) 18:23:15.07

アホだろお前

2018/05/18(金) 18:33:25.05

そりゃあ頑張れば勝てるだろう
コーディングコストと可読性の犠牲に見合うほど速くなるかどうかは別問題だがね

**771** (ﾜｯﾁｮｲ 95b3-NTEn) · 2018/05/18(金) 18:57:13.66

VCもそうだけど大体のコンパイラは並列化や自動ベクタライズは強くないと思う
古くからある機能とそうでないものでは最適化に差が出るのは当然
だからこそSIMD使うときはみんなイントリンシック命令使ってるのであって

2018/05/18(金) 20:11:41.99

>>834て誰に対してのレス？

2018/05/18(金) 21:20:25.60

>>828

template<std::size_t N>
class A {
public:
const double array[N];

template<typename ...ARGS>
A( ARGS&&... args ): array{std::forward<ARGS>(args)...} {}
};

template<typename ...ARGS>
inline auto make_A( ARGS&&... args ) -> A<sizeof...(args)>
{
return A<sizeof...(args)>(std::forward<ARGS>(args)...);
}

auto a{ make_A( 1.0, 2.0 ) };

こんな感じだろうか。
要C++11以降。

>>どんなサイズの配列が来るかはコンストラクタが呼び出されるまでわからないんでサイズは未定にしておきました
要素数が決まってないとコンパイル時に困るので、テンプレートクラスにしちゃったけれど…

2018/05/18(金) 22:05:36.49

あーいや、 >>828 は配列を渡して初期化したいのか…
↑じゃだめだ

だいぶ別物になっちゃった。
ttps://wandbox.org/permlink/gUlWoKLb3QfigsQk

2018/05/18(金) 22:33:37.26

参考にしてみた
https://wandbox.org/permlink/3asRA3QSPQXmmn8l
C++17ならヘルパー不要にはなる・・・(コンストラクタに与えた引数から推定
けどどっちにしても配列数可変にはできない

ていうか配列の参照とか初めて使ったw

2018/05/19(土) 00:03:26.14

>>828
C++14のinteger_sequence使ってみた

#include <iostream>
#include <utility>

template <size_t N>
class A
{
const double array[N];
public:
template <size_t... I>
A(const double (&temp)[N], std::index_sequence<I...>) : array{temp[I]...}
{
for (auto x : array) std::cout << x << std::endl;
}
A(const double (&temp)[N]) : A(temp, std::make_index_sequence<N>()){}
};

int main()
{
double t[] = {1.1, 2.2, 3.3};
A<sizeof(t)/sizeof(t[0])> a(t);
//A a(t); // C++17
}

2018/05/19(土) 00:10:45.61

糞面倒だな

2018/05/19(土) 00:15:37.45

アンチパターンを生み出すための新機能が次々出てくるのがc++だ！

2018/05/19(土) 00:33:17.81

こういうのからiostreamみたいになってゆくんだろうな

2018/05/19(土) 03:41:10.01

つか引数にconst double(&temp)[]って何だと渡せるのこれ
()ないとエラー出るし

2018/05/19(土) 06:54:38.61

何も渡せないよ
配列数のない配列型はどんな文脈でも不完全型だからその型のオブジェクトは存在し得ない

2018/05/19(土) 07:39:54.12

>>842
VS2017 15.7.1のVCのReleaseモードだとtemplateの部分が赤の下波線になるな
Debugモードにするとなぜか消える
そしてReleaseモードはエラーが出ているのにコンパイルして実行可能
バグじゃね

2018/05/19(土) 12:37:22.83

>>847
仮引数として表れる場合はポインタに調整されるんじゃなかったっけ？

2018/05/19(土) 13:11:36.50

配列型はね
配列の参照型はされない

2018/05/21(月) 09:24:48.82

引数で渡す場合は配列自体が参照型だもんな

2018/05/21(月) 21:45:00.90

配列への参照ってのはあるんだけどね
template <typename T, int N>
N size(T (&)[N]) { return N; }

2018/05/21(月) 21:45:22.62

あ、ミスった
わかる人笑ってｗ

2018/05/22(火) 10:34:44.57

>>848
> バグじゃね
未定義ならコンパイルできて実行できると言うのも規格に準拠してる正しい動作

2018/05/22(火) 17:07:12.03

>>854
見当違いのレスだな
DebugとReleaseでエディタの動作が首尾一貫してないって言ってるんだがな
15.7.2が来たから入れてみる

2018/05/22(火) 17:37:39.23

>>855
普通の知能を持ってたら
> コンパイルして実行可能
に突っ込まれてることぐらいわかるだろうに...