【初心者歓迎】C/C++室 Ver.105【環境依存OK】

**デフォルトの名無しさん** · 2019/04/25(木) 06:54:38.08

エスケープシーケンスやWin32APIなどの環境依存なものもOK
そのような質問は必ず環境を書きましょう
半角空白やタブでのインデントはスレに貼ると無くなります

コードを貼れる所
http://codepad.org/
https://ideone.com/

前スレ
【初心者歓迎】C/C++室 Ver.104【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1545944692/

**デフォルトの名無しさん** · 2020/01/16(木) 17:42:18.71

で、ID:vo+Ub67N　は逃げたの？
いつものイチャモンつけるしか能が無いクズだろうけど
そんな暇があったら最初からちゃんと答えてやれよゴミが

**デフォルトの名無しさん** · 2020/01/16(木) 19:09:23.03

外野が喚いて質問者が迷惑するパターン？

**デフォルトの名無しさん** · 2020/01/16(木) 19:24:24.34

>>518
ご返信ありがとうございます、とりあえず言われたことに関係ありそうなことを
調べたのですが、自分のファイルにそういった感じの文法ミスがあるのかは
分かりませんでした。一応短いのでエラー吐いたソースコード貼っておきます。

#include <algorithm>
#include <iostream>
using namespace std;

int main() {
int N;
cin >> N;
int a[N];
for (int i = 0; i < N; i++) cin >> a[i];
long long ans = 0;
for (int i = 1; i <= 3000; i++) {
long long sum = 0;
for (int j = 0; j < N; j++) sum += a[j] % i;
ans = max(ans, sum);
}

cout << ans << endl;
return 0;
}

後、以前コンパイルできていたプログラムで同様の手順を試しにやってみたら、
同様の症状が起こって実行ファイルが消えました。

>>523
申し訳ありません、無知だったので色々調べたのですがエントリポイントという物が
よく分かりませんでした。気がつかないうちに何かまずいところ弄って他のプログラムと
開始アドレスが被ったとかそんな感じでしょうか？

**蟻人間** ◆T6xkBnTXz7B0 · 2020/01/16(木) 19:36:20.45

*.cppにより、エントリポイントのmain関数を2つコンパイルしたんではないか？

**蟻人間** ◆T6xkBnTXz7B0 · 2020/01/16(木) 19:38:26.02

１つのフォルダには１つのプロジェクトにした方がいいのかも。

**デフォルトの名無しさん** · 2020/01/16(木) 19:38:35.95

>>538
エントリポイントっていうのはそこでいうmain関数のことね
それが複数作られてるとエラーになる
そのソースコードをヘッダファイルに書いててそれを複数のファイルでインクルードしてるとか
あるいは他にもmain関数を定義してる余計なソースコードがあるとかそういうのが原因だとおも

**デフォルトの名無しさん** · 2020/01/16(木) 19:40:09.05

リロードしてなくて被った

**デフォルトの名無しさん** · 2020/01/16(木) 20:19:17.16

>>539、>>541
とりあえずファイル内にmain関数を持つc.cppとd.cppがある状態だったので、
試しに適当なディレクトリを作ってそこにc.cppを移してみたらコンパイル成功しました！
ずっと詰まっていたので感謝します、お二方とも本当にありがとうございます！！

恐らく原因である runFiles=`ls *.cpp` の部分が以前どうなっていたか
覚えていないのですが、前は同ディレクトリにmain文複数あっても成功しているんですよね…
VScodeの自動更新等でビルドの設定が変わったとかでしょうか…？

**デフォルトの名無しさん** · 2020/01/16(木) 20:26:56.83

申し訳ありません、今VScodeのsetting.jsonを確認したらいつの間にか
"code-runner.executorMap": {
"cpp": "cd $dir && runFiles=`ls *.cpp` && g++ -std=c++17 `echo ${runFiles}` -o $fileNameWithoutExt && $dir$fileNameWithoutExt",
},
が書かれてました。恐らくですが、最近別の機会でc++17のオプションを使う時にそのまま他の方の
設定を写していたのと最近一つのファイル内に複数のフォルダ作ることが無かったからだと思います。
昼から何度も長文でお騒がせして申し訳ありませんでしたorz
エントリポイントに関しては大変参考になりました。

**デフォルトの名無しさん** · 2020/01/17(金) 10:27:22.98

>>522
戻り値の型をテンプレートにするのってどうするの

**デフォルトの名無しさん** · 2020/01/17(金) 14:15:38.50

Tかautoでいんじゃね
あるいはdecltype

**デフォルトの名無しさん** · 2020/01/17(金) 14:18:21.61

戻り値Tで関数オーバーロード出来る？

**デフォルトの名無しさん** · 2020/01/17(金) 14:37:12.74

戻り値が違うだけだと無理よ

**デフォルトの名無しさん** · 2020/01/17(金) 14:39:16.16

あ、戻り値だけ指定させる関数テンプレートならオーバーロードしなくても
その関数テンプレート一つでいける
ただし推論できないので呼び出すときにテンプレート引数の指定は必須

**デフォルトの名無しさん** · 2020/01/17(金) 18:48:04.18

autoと型指定で同じコードに落ちるとは限らないというか、おそらく同じコードにならないので、よく考える必要があると思います。

**はちみつ餃子** ◆8X2XSCHEME · 2020/01/19(日) 01:28:50.10

decltype(auto) とも使い分けが必要なの本当にアレだよな……

**デフォルトの名無しさん** · 2020/01/20(月) 10:42:02.42

ptrってなんて読むん

**デフォルトの名無しさん** · 2020/01/20(月) 11:17:45.19

ポインタ

**デフォルトの名無しさん** · 2020/01/20(月) 11:47:15.83

ハリー・ポッター

**デフォルトの名無しさん** · 2020/01/20(月) 11:52:47.26

ペトリザラ

**デフォルトの名無しさん** · 2020/01/20(月) 12:52:13.10

ずっと脳内でﾋﾟﾄﾗって読んでたがポインタか
ありがとう

**デフォルトの名無しさん** · 2020/01/20(月) 13:19:51.66

int_ptr
INT_PTR
*int
全部違う型？

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

int *
ですすんまそ

**はちみつ餃子** ◆8X2XSCHEME · 2020/01/20(月) 15:13:06.58

>>557
INT_PTR は Windows SDK で定義されてるやつのことだと思うけど、
標準で言うところの intptr_t に相当するやつ。
int のポインタじゃなくて、ポインタを格納できる (のに充分な幅がある) int っていう意味。

**デフォルトの名無しさん** · 2020/01/20(月) 15:46:05.19

>>507
これって2項間はいけるけど
v=l+z+w;
とか3項間以上の場合

typename L::value_type
operator[](std::size_t i) const{
・・・
}

ここで、コンパイル通らないんじゃないの?
+wの部分で(l+z)::valu_typeを参照し、
class Expressionで宣言されてないvalu_typeを参照することになってエラーになるはず。

auto
operator[](std::size_t i) const{
・・・
}

では何の問題もない。

**デフォルトの名無しさん** · 2020/01/20(月) 15:51:26.28

>>507

のコードはおよそ使えない間違いコードといいっていい。

**デフォルトの名無しさん** · 2020/01/20(月) 15:58:55.44

一応
gcc 9.1で確認してみた
error: no type named ‘value_type’ in ‘class Expression<Vector<int>, Plus, Vector<int>
>’
11 | typename L::value_type operator[](std::size_t i) const

だな。

>>507のコードはコンパイルすら通らない間違いコードだ。

**デフォルトの名無しさん** · 2020/01/20(月) 16:08:08.21

コンパイル通らないってのは
以下を追加したときの話ね

Vector<int> w{ 5, 4, 3 };
v = l + r +w;

2項間では通るが3項間以上の式では通らない。
ex-templateを使うメリットが全くないコードが>>507

**デフォルトの名無しさん** · 2020/01/20(月) 17:26:42.62

auto
operator[](std::size_t i) const{

とせず、value_type直接指定でいくためには
class expressionの中で
もう一度
using value_type = typename L:value_type;
を宣言して、

value_type
operator[](size_t i) const{
・・・
}

で多項間でも問題なくいけるはず。

**デフォルトの名無しさん** · 2020/01/21(火) 18:43:12.30

>>563
３項以上でなければメリット無くなるわけではないぞ
というかまぁ今どきはETより先にSIMD使えって話だけど

**デフォルトの名無しさん** · 2020/01/21(火) 22:39:57.57

>>565
2項迄の演算では式テンプレートに何のメリットもない。
デバッグを困難にするだけの糞コーディングだ
バグに気づくことも出来なかった一知半解の口だけウスノロはすっこんでな

そもそも、質問者は
>>500
>t= x+y+z;
>という計算ができるようにしたい。

と希望を述べているのに>>507のコードは要求仕様を満足できてないゴミコードということだ。

**デフォルトの名無しさん** · 2020/01/21(火) 22:42:13.76

>>565
>というかまぁ今どきはETより先にSIMD使えって話だけど

能力不足をHWに補ってもらわないとなww
その分電力無駄に食ってることは覚えとけ

**デフォルトの名無しさん** · 2020/01/21(火) 23:33:50.08

え？
SIMDで並列化できたら電力あたりのパフォーマンスはあがるぞ
ETと比べるものとは思わないが

**デフォルトの名無しさん** · 2020/01/22(水) 10:04:13.26

>>566
お前大して攻撃的でもない書き込みにすぐ喧嘩売ってイキるの辞めたほうがいいよ
俺はETとSIMD両方使って自作の線形代数ライブラリ（4行4列まで限定だが）作った上で言ってる
恥書く前に謝っとけよ

＞能力不足をHWに補ってもらわないとな
アホだろお前、ETがSIMD以上に速度上がると思ってんの？

＞ETと比べるものとは思わないが
確かに速度が目当てと勝手に限定してたね

**デフォルトの名無しさん** · 2020/01/22(水) 10:18:16.91

最近のコンパイラならETできれいに展開しておけば
勝手にはSIMD化してくれんじゃない？

**デフォルトの名無しさん** · 2020/01/22(水) 10:27:28.86

Intelのは使ったことないんで知らんけど、VCだと基本そういうのは期待できないよ
（最適化かけたEigenのコードの逆アセでも見てみればわかる）
単一の要素の計算にxmmレジスタ使ってはくれるけど並列にやってくれることは無い
SIMDに収まる範囲のベクトルなら、手動できっちりSIMD使いつつ
インターフェースを使いやすくするのは普通に出来るから先にそうした方がいい

**デフォルトの名無しさん** · 2020/01/22(水) 12:20:19.61

>>569
言うだけ無駄
意図的に絡んでるのが大半だから
自然体だったら残念な性格としか

ソースは無い

**デフォルトの名無しさん** · 2020/01/27(月) 00:16:58.09

class vec2
{

**デフォルトの名無しさん** · 2020/01/28(火) 10:57:31.95

// >>573
}

**デフォルトの名無しさん** · 2020/01/28(火) 15:18:36.74

// >>574
;

**デフォルトの名無しさん** · 2020/01/29(水) 08:49:45.27

なんかわろた

**デフォルトの名無しさん** · 2020/01/29(水) 13:23:40.81

>>575
:q!

**はちみつ餃子** ◆8X2XSCHEME · 2020/01/29(水) 17:06:53.33

は？ C-x C-c だが。

**デフォルトの名無しさん** · 2020/01/29(水) 19:14:06.94

>>577
保存しないで抜けるんじゃないw

**デフォルトの名無しさん** · 2020/01/31(金) 16:53:29.94

g++やclangで-std=c++17オプションをterminal、VScode共に一括で
デフォルトにしたいのですが何か良い方法ってありませんか？
環境はMac OS Mojaveです

**デフォルトの名無しさん** · 2020/01/31(金) 22:24:21.02

>>569
それがどうした?
4x4?それが自慢か雑魚野郎
こっちは自由にサイズ変更可能な行列演算ライブラリを20年以上前から仕事で使ってる。
そして一定サイズ以上の行列乗算では式テンプレートではまったくパフォーマンス向上できないこともわかってる。
土下座すんのはテメエなんだよ一知半解の低脳野郎
ちなみに>>500のサイトにあるBlitzの有名なコードだが、operator=内部で =r(i.j)などとして、行列乗算(each productではなく)に拡張した場合、
式テンプレートを使用しない方式と比べて100x100行列なら1000倍以上の速度低下を引き起こす

>アホだろお前、ETがSIMD以上に速度上がると思ってんの？

はぁ? 異なるHW条件持ち出してきて速度向上ほざいてアホの極みか低脳

**デフォルトの名無しさん** · 2020/01/31(金) 22:45:37.50

>>569
あぁ
言い忘れてたわ式テンプレートは一時領域コピー時間の削減と言う意味で3項以上と書いてるわけだが、
一時領域の必要ない2項でメリットがあるというなら挙げてミロよ低脳www
寝ぼけんな雑魚野郎

**デフォルトの名無しさん** · 2020/01/31(金) 23:43:58.62

団子だろ

**デフォルトの名無しさん** · 2020/01/31(金) 23:56:24.08

>>479
#pragma omp critical
使ってるコードで同じエラー出たわ
criticalセクションが無ければこのエラーは出ない
無くしたら動かんけどww
19.1のバグやね
まだ、気づいてない人多いんだろな検索してもヒットしない

**デフォルトの名無しさん** · 2020/02/01(土) 04:58:28.47

>>581
ずいぶん反論に時間がかかったなｗ

＞20年以上前から仕事で”使ってる”
作った側ではないなら実装時の問題とかには疎いんじゃねーの？
＞Blitzの有名なコード
Blitzのコードとかどっかに書いてたか？
Blitzのソース読んだことないんで具体的にどのヘッダか示してくれるか
というかあんなクソ単純な説明のためのサンプルと同等のコードとは考えにくいが

＞100x100行列なら1000倍以上の速度低下を引き起こす
へー。で？？
俺別にETを絶賛などしてないんだが
質問者の話もそういう可変要素のやつじゃなかったよね

＞異なるHW条件持ち出してきて
お前が
＞能力不足をHWに補ってもらわないとなww
とかアホなこと抜かしたからだろ

**デフォルトの名無しさん** · 2020/02/01(土) 05:17:20.41

>>582
＞一時領域の必要ない2項でメリットがあるというなら挙げてミロよ低脳www
2項で一時領域が必要ないのはRVO前提にしてんだろうけど
お前コンストラクタしか頭に無いだろ

あと、よっぽど自信がおありのようだから質問してやるが
上に挙がってたコード例のようなやり方でバカ正直に行列の乗算のような計算を
仮に3項以上でやると重大な問題が起きるわけだが、それが何か即答できるよな？

**デフォルトの名無しさん** · 2020/02/01(土) 07:35:36.44

最適化、高速化は具体的な用途とセットじゃないと語っても意味がない

要素ごとに演算すれば良い巨大ベクタと
1個の結果を得るのに広範囲にアクセスしなきゃならない巨大行列の乗算
全然違う話

**デフォルトの名無しさん** · 2020/02/01(土) 07:57:11.83

大きな行列の場合、高速化手法なんて他にいくつもあるからね（詳しくはないが

それ以前になぜ遅くなるのかも分かってない＆ET以前にSIMDと言われて
「能力不足をHWに補ってもらわないとなww」とか（ライブラリ実装したことある立場ではないにもかかわらず）
平気で言える時点で、20年仕事でってのは嘘だろう
C++かじっただけのどこかの暇な学生だろ

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

HWを使わない最適化(高速化)なんてあり得ないからね

SIMD、スレッド、キャッシュ、(GPU、FPGA、...)
これらを有効に使うのが最適化

**デフォルトの名無しさん** · 2020/02/01(土) 08:23:05.35

高速化はどうでも良くて単に楽に書きたいだけならC/C++は向いてない

**デフォルトの名無しさん** · 2020/02/01(土) 12:22:48.15

>>589
アルゴリズムはハード非依存と言っていいでしょ

**デフォルトの名無しさん** · 2020/02/01(土) 13:49:03.18

「ソフトウェアに対して本当に真剣な人は、独自のハードウェアを作るべきだ。」
アラン・ケイ

**デフォルトの名無しさん** · 2020/02/02(日) 23:42:11.49

>>591
ある段階まではね。

**デフォルトの名無しさん** · 2020/02/03(月) 08:23:47.39

>>593
具体的にどの段階？
ハードウェアに依存したアルゴリズムの最適化って何？
例えばロックフリーでCASが前提とかはあるけどあれも具体的なハードではないだろ

**デフォルトの名無しさん** · 2020/02/03(月) 08:56:52.32

除算回数を減らすチューニングなんかはHW依存と言えるんじゃない？

**デフォルトの名無しさん** · 2020/02/03(月) 12:02:25.38

触ったこと無い人には説明しても判らんやろて

**デフォルトの名無しさん** · 2020/02/03(月) 12:33:05.83

極端なこというと、量子コンピュータ向けアルゴリズムはHWが量子コンピュータであることが前提
HWとSW合わせて1つの装置だから

**デフォルトの名無しさん** · 2020/02/03(月) 15:01:01.85

>>595
それはアルゴリズムとは言わないでしよ
計算のオーダー変わるわけじゃないし

**デフォルトの名無しさん** · 2020/02/03(月) 15:46:17.64

>>598
いや、計算量も変わるしアルゴリズムでもあるけど？

**デフォルトの名無しさん** · 2020/02/03(月) 17:07:19.92

>>599
計算量でなく計算オーダー
知らずにしゃしゃり出てくるとか

**デフォルトの名無しさん** · 2020/02/03(月) 17:13:32.87

ビッグオーが変わるようなのはアルゴリズムの違いだろうけど
ビッグオーがそのままで計算量だけが変わるのはどっちとも言いがたい

**デフォルトの名無しさん** · 2020/02/03(月) 17:33:31.72

>>600
より除算回数の少ないアルゴリズムを選択することは現状のCPUは除算が遅いことに対応するわけだからHW依存と言えなくもない
この主張に対してそういった選択はアルゴリズムでもなければオーダーもかわらないと反論しているのですか？

**デフォルトの名無しさん** · 2020/02/03(月) 23:27:39.99

特異な例を持ち出しても一般論を否定できないっての

**デフォルトの名無しさん** · 2020/02/03(月) 23:33:51.85

計算量のオーダーが変わらないアルゴリズム的最適化なんていくらでもあるよ

**デフォルトの名無しさん** · 2020/02/04(火) 00:20:58.43

有限の並列度の並列化ってオーダー変わらないけどワザワザ並列化可能なアルゴリズム使うよね

**デフォルトの名無しさん** · 2020/02/04(火) 00:29:54.04

どうせO(n)だから配列丸コピしても問題なしっていう馬鹿を思い出したわ。

**デフォルトの名無しさん** · 2020/02/04(火) 00:37:14.93

と言うか最適なオーダーのアルゴリズムなんて殆んど既知だから、オーダー変わるような最適化ってあんまりないよね

**デフォルトの名無しさん** · 2020/02/04(火) 12:35:39.06

車輪の再発明は良く批判されるけど
素数を列挙するプログラムなんて
既に判ってる素数はテーブル参照するのが最適なのに
なんで毎回計算して地球環境破壊に貢献してる訳？

**デフォルトの名無しさん** · 2020/02/04(火) 12:47:30.21

ROM容量にはテーブル化は最適ではない

**デフォルトの名無しさん** · 2020/02/04(火) 12:48:27.46

競技ルール的なアレじゃね

**デフォルトの名無しさん** · 2020/02/04(火) 13:48:07.39

「ROM容量にはテーブル化は最適ではない」
典型的な論点ずらし

**デフォルトの名無しさん** · 2020/02/04(火) 16:52:46.33

>>608
素数の話はどっから出てきた？
アルゴリズムの例として挙げたのかも知れんが、
別のスレッドで最近見た気のする話題なので投稿する場を間違えたのかと。

実用プログラムでは「車輪の再発明」は上手いやり方じゃないけど、
低レベルの部分から組み上げたほうが理解が深まるって面はあるでしょ。

**デフォルトの名無しさん** · 2020/02/04(火) 16:53:25.40

お前が何を論じたいかとか
知るか

**デフォルトの名無しさん** · 2020/02/04(火) 17:26:23.15

車輪の再発明は学習に最適

**デフォルトの名無しさん** · 2020/02/05(水) 00:16:57.41

>>611
>>608が最適と豪語したから反例挙げてるだけだろ
お前のほうが論点ずらしだよw

**デフォルトの名無しさん** · 2020/02/05(水) 01:36:02.88

>>615
悔しそうですねｗ

**デフォルトの名無しさん** · 2020/02/05(水) 04:53:06.88

夜中まで大変だなw

**デフォルトの名無しさん** · 2020/02/05(水) 13:53:11.70

バイナリデータを、文字列に変換して保持しようとした場合、素直に16進数表記にするのがよい？
データ量倍になるけど

**デフォルトの名無しさん** · 2020/02/05(水) 14:09:47.25

おまえがやりたいようにやればいいとおもう

**デフォルトの名無しさん** · 2020/02/05(水) 14:22:22.31

Base64

**デフォルトの名無しさん** · 2020/02/05(水) 14:32:42.49

>>620
あーそんなのありましたな
ちょっとググったらライブラリも出てきたしよさそう
ありがとうございます

**デフォルトの名無しさん** · 2020/02/05(水) 15:41:12.41

それでいいんだw

**デフォルトの名無しさん** · 2020/02/05(水) 16:07:18.33

それでいいなら%Xで出力するのでも良い気がするね
base64にすると単純な16進表記よりデータ量増えるし、%Xなら余分なライブラリもいらないし
まぁどっちでもいいんだろうけど

**デフォルトの名無しさん** · 2020/02/05(水) 16:08:34.43

嘘言ったわ、base64は6ビットごとに1文字だからデータはこっちのほうが小さいか

**デフォルトの名無しさん** · 2020/02/05(水) 16:54:58.67

8bit→HEX2桁→2倍
8bit→Base64→4/3倍
やろ
一定数以上桁が必要なのでpaddingとかあるし100%ではないが

**デフォルトの名無しさん** · 2020/02/05(水) 18:52:50.41

base64なんかビットシフトとテーブルだけで簡単に実装できるし依存ライブラリ増やす必要もないのでは

**デフォルトの名無しさん** · 2020/02/05(水) 19:13:05.48

16進数派

**デフォルトの名無しさん** · 2020/02/05(水) 19:23:50.17

データ量にもよるけど
"\x00\x00\x00\x00..." が一番楽じゃね

**デフォルトの名無しさん** · 2020/02/05(水) 19:35:11.50

何のためにテキストに変換したいのかがわからんとなんとも言えんな
目的によって使える文字種も違うからな

**デフォルトの名無しさん** · 2020/02/05(水) 19:41:08.83

Base64で良いって言ってるんだから
終了

**デフォルトの名無しさん** · 2020/02/05(水) 23:15:38.55

Base64 は、HTML でもよく使う

Base64の文字列で、PNG/JPEG画像を、HTMLファイルに直接埋め込める

<img src="data:image/png;base64,xxxxx..." />

**デフォルトの名無しさん** · 2020/02/06(木) 00:01:41.26

base64って7bit通信路通すためのもんでしょ？
textにするならヒューマンリーダブルにするのが無難だと思うけど
そうじゃなけりゃバイナリでいいじゃん
と思った
まぁ好きにしなよ

**デフォルトの名無しさん** · 2020/02/06(木) 00:07:14.11

ヒューマンリーダブル

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/06(木) 01:02:03.98

ish みたいなやつで UTF-8 を利用したのをどっかで見たことある

**デフォルトの名無しさん** · 2020/02/06(木) 06:43:09.85

>>632は一体何を主張してるんだろう…