C++相談室 part153 - 暇つぶし2ch

C++相談室 part153 ..

2:デフォルトの名無しさん
20/10/11 00:17:54.48 yrSMEX+0.net
STLつかうと一気に実行ファイルサイズが10倍に?！
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？
#include <stdafx.h>
後死ね。
言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。

3:デフォルトの名無しさん
20/10/11 07:46:00.50 2CDQ3L3B.net
>>1
乙。

4:デフォルトの名無しさん
20/10/11 07:49:37.39 eYoRN2yM.net
>>1
このほとんど投げやりな感じのテンプレがじつにいい
いかにもC++っていう感じがして好き

5:デフォルトの名無しさん
20/10/11 07:52:39.24 2CDQ3L3B.net
などと自画自賛。

6:デフォルトの名無しさん
20/10/11 09:59:16.21 kZXFoyze.net
stdafx.h include したら負け

7:デフォルトの名無しさん
20/10/11 13:02:31.31 sfgrEAk/.net
>>1乙
最近はpch.h

8:
20/10/11 16:35:47.97 sJNU+9dX.net
>>ｽﾚﾘﾝｸ(tech板:914番)
＞普段から、馬鹿な応答が多かったし、
認めましょう
＞「自分でコンテナクラス(リストなど)を作れるから天才」
＞だとか、男だったら基本中の基本の出来て当たり前の事が出来るだけで天才と言っている
そんな発言はしていませんよ、確かにコンテナを自作する、というのはやったことはありますが、「自分でつくるとイマイチだよね」というのが私の実感です
ｽﾚﾘﾝｸ(tech板:33番)
＞如何に周りのレベルが低いかが分かったから。
周り？
私はアマチュアだから、周りにプログラミングをする人はゼロですよ……

9:デフォルトの名無しさん
20/10/11 17:01:01.82 pM0zGshh.net
C++の規格以外の話はｽﾚﾁ…

10:デフォルトの名無しさん
20/10/11 22:05:10.68 wjXte93n.net
規格の話限定だったの？ここ

11:デフォルトの名無しさん
20/10/11 23:00:26.64 pSezOgnt.net
>>8
わざわざ馬鹿な引きニート相手に真面目な返答しなくても

12:デフォルトの名無しさん
20/10/12 02:50:13.21 +FLMYxu9.net
QZ数ヶ月前俺にスルースキルが無いとか偉そうに言ってなかったっけ
C++に関わる話なら個人的には荒れててもいいと思うが、お前のプロフィールなんか誰も興味ないぞ

13:デフォルトの名無しさん
20/10/12 09:52:20.31 941JO02h.net
>>12
ｽﾚﾘﾝｸ(tech板:125番)

14:デフォルトの名無しさん
20/10/12 09:57:09.05 O4GtI7oq.net
>>13
それは仕方ないんじゃないかな。
人間だもの。

15:デフォルトの名無しさん
20/10/12 10:00:39.31 rzm6EDrC.net
批判されたら自演する修正なんてC++関係ない

16:デフォルトの名無しさん
20/10/12 12:54:31.37 GHsqP2MR.net
今とあるOSSのライブラリの動きがあやしいのでデバッグしているんだけど
やっぱりいわゆるモダンなc++はデバッグがつらいわ
デバッガで見てもwrapの嵐でデータの中身になかなかたどり着けない
ステップ実行しててもRAIIをはじめ表面上見えない実装がノイズになってわけわかんなくなる
あとデバッグビルドは恐ろしくパフォーマンス落ちる(Cとかと比べてね)

17:デフォルトの名無しさん
20/10/12 14:12:21.06 941JO02h.net
C++ より C が良いね

18:デフォルトの名無しさん
20/10/12 15:18:22.15 Z3Kcjb2S.net
STLの unique_ptr, shared_ptr, vector, list, forward, move
といった非常に基本的なものもソースを解読するのはとても難しく
strcmpが3行くらいしかなかったのが懐かしい。
それにC++11以降の機能は非常に好みが分かれ、好きな人は好きだが
嫌いな人は反吐が出るほど嫌い。

19:デフォルトの名無しさん
20/10/12 15:23:21.42 N0jxybIn.net
Ubuntu20.04でGtkmmでアプリを作っています…ディレクトリとファイル一覧が欲しくて…。
C++17の

20:std::filesystemを使ったほうがスマートだと思うけど…使えません…。そんな古い環境ではないと思うんだけど…direntやstatをやればできると思うけど…古いよね？これカーネルだし…std::filesystemがスマートだと思うんだけど…このUbuntuではまだなの？ -std=c++17のオプションをつけてコンパイルしても駄目だった…。

21:デフォルトの名無しさん
20/10/12 15:27:01.65 O4GtI7oq.net
Ubuntuはgcc9使えたんじゃなかったかな。
gcc8はファイルシステム使うとき、ライブラリをリンクしないといけなかったと思う。
-lstdc++fs
gcc9から必要なかったと思うので、gcc9を使う方をお勧めします。

22:デフォルトの名無しさん
20/10/12 16:15:10.34 N0jxybIn.net
できました！できました！できましたが…EclipseCDT上で…名称が解決できてない感じ…。
とりあえず…動きました…もう少し調査します…。

23:デフォルトの名無しさん
20/10/12 16:27:02.58 N0jxybIn.net
名称も解決できました…使うよ！

24:デフォルトの名無しさん
20/10/12 16:56:02.38 941JO02h.net
>>18
速度も落ちてそう

25:デフォルトの名無しさん
20/10/12 19:26:54.38 Z3Kcjb2S.net
>>23
メタプログラミングの部分が複雑なだけで生成されるコードは最短に近い
のではないかと思う。

26:デフォルトの名無しさん
20/10/12 20:04:28.37 Zjr2Hxnk.net
設計者ももっと簡潔に書ける技能を身に付けるべきだと思うけどねん

27:デフォルトの名無しさん
20/10/12 20:14:11.80 9Fo4KCKO.net
>>19
-std=c++1zとかstd=gnu++1zじゃなかったっけ

28:デフォルトの名無しさん
20/10/12 20:50:41.81 O4GtI7oq.net
文芸的プログラミングですね。

29:デフォルトの名無しさん
20/10/13 02:00:34.30 y5TdNrxl.net
>>25
STLの性能を維持しつつ簡潔に書ける人間
にしか許されない発言

30:はちみつ餃子
20/10/13 03:46:05.57 jBq+pHZV.net
汎用的な部品は広い範囲をカバーするわけだから想定すべき状況が多くなるし、
その分だけ相応に複雑になるのは当たり前の話なんだよな。
逆に strcmp が簡潔だったとか言ってもそりゃあ char から成る文字列の比較に
特化していいなら簡潔に出来て当たり前ですよねってだけのことで、
機能が違うものの複雑さを比べようとするのは馬鹿馬鹿しいよ。

31:デフォルトの名無しさん
20/10/13 07:14:55.86 AAkThgLB.net
・同名の一時変数を使いまわす
・メモリの節約のために早めにデストラクタを呼ぶ
・スコープを小分けにして可読性を上げる
みたいな目的のために中括弧を多用するのってアリですか？
それともスコープじゃなくて関数を分けろってなりますか？

32:デフォルトの名無しさん
20/10/13 09:00:40.68 KjGL8AJy.net
>>29
STLは理屈自体は非常に簡潔だとハゲも言っとる
的外れ
 >>30
アリだのナシだの・・・

33:デフォルトの名無しさん
20/10/13 09:19:57.42 2ekPMyol.net
STLガーSTLガー言ってるやつ
そもそも++でないCでもポインタ引数２個で始点終点渡すのがロクに書けなさそうだね

34:デフォルトの名無しさん
20/10/13 09:53:49.84 f6jDEgc3.net
STLの凄さがわからない人もいるという。

35:デフォルトの名無しさん
20/10/13 10:50:05.42 y5TdNrxl.net
知ってることの精一杯がポインタのそれなんだな
クスクス

36:デフォルトの名無しさん
20/10/13 12:20:09.76 2ekPMyol.net
void fill(int first[], int last[], int val)
{
while (first < last) //えー、配列の大小比較って変じゃん
{
first[0] = val; //常にゼロの添え字って気持ち悪いよー
++first; //やだよー、配列を++なんて
}
} //これだから変態どもは・・・まったく
void fill(int first[], int n, int val) //素直にこう書きやがれ
{
for (int i = 0; i < n; i++) //変数が増えることを気にしないのが富豪だ
{
first[i] = val; //配列要素へのアクセスには[]があるべきなんだよ
}
} //知ってることの精一杯がポインタのそれなんだなksks
↑
もうさ、こいつ無理にC++使わなくてよくね？

37:デフォルトの名無しさん
20/10/13 12:30:12.68 y5TdNrxl.net
雑魚おつ

38:31
20/10/13 12:48:18.65 alJhtdGu.net
いや、あの・・・
STL自体は非常に良く出来てると思うが、俺普段C++(あるいはC++11以降)マンセーSTLマンセーしてる連中は馬鹿にしてるからね・・・w
お前が作ったんちゃうやろと

39:デフォルトの名無しさん
20/10/13 12:50:17.06 FpFGKRx+.net
void fill(int *first, int *last, int val)
{
while(first < last) *first++ = val;
}

40:デフォルトの名無しさん
20/10/13 12:52:08.93 jGpIs/AO.net
理解は出来ないわけじゃなくSTL流に書くのが汚くて馬鹿みたいに感じるだけだ。

41:デフォルトの名無しさん
20/10/13 12:54:03.28 jGpIs/AO.net
配列は処理対象を個数で表現するほうが分かり易いし完結なのに、終端要素で
表そうとするのは単にSTLのとった設計思想の都合でしかないので
馬鹿っぽく感じる。

42:デフォルトの名無しさん
20/10/13 12:56:47.00 2ekPMyol.net
>>37
C++11の何が気に入らんの？
C++98でストレス溜まってたところを楽にしてくれてるやん
型指定子autoは同じことを二度も書かされる屈辱から解放してくれるし
range-based-for-statementの見た目からは驚かされる簡潔さなんかクールだろ
俺的にはテンポラリにconstが必須でなくなって痒いところに手が届いた

43:デフォルトの名無しさん
20/10/13 13:17:38.74 y5TdNrxl.net
①
void fill(int first[], int n, int val) //素直にこう書きやがれ
{
for (int i = 0; i < n; i++) //変数が増えることを気にしないのが富豪だ
{
first[i] = val; //配列要素へのアクセスには[]があるべきなんだよ
}
} //知ってることの精一杯がポインタのそれなんだなksks
と
②
void fill(int *first, int *last, int val)
{
while(first < last) *first++ = val;
}
明らかに配列添字明示してる①のほうが無駄が多くて馬鹿っぽいけど

44:デフォルトの名無しさん
20/10/13 13:19:51.21 2ekPMyol.net
>>42
うん、そう言いたかった
35の最終行で言ったつもりだった

45:デフォルトの名無しさん
20/10/13 13:32:32.38 alJhtdGu.net
>>41
別に気に入らんとか言うとらんよvariadic templates無しの時代はキツかったし(逆に言えばテンプレート以外ではそんなに困らん)
新しいもの使ってる=上級者、だと思ってるような、権威を傘に着てる連中を馬鹿にしてると言ったの
マンセーとかの辺りで察してくれ

46:デフォルトの名無しさん
20/10/13 13:43:16.33 jGpIs/AO.net
伝統的にはこうで、速度も速い。
void fill(int *ptr, int n, int val)
{
　for (int i = 0; i < n; i++) {
　　*ptr++ = val;
　}
}
さらに、以下のように書くほうが速い。
void fill(int *top, int n, int val)
{
　int *ptr = top;
　for (int i = n; i > 0; --i) {
　　*ptr++ = val;
　}
}

47:デフォルトの名無しさん
20/10/13 13:47:15.59 jGpIs/AO.net
>>42 >>43
fill()関数自体はどれでも分かりにくさは感じない。
問題はfill()関数を使う側の分かりにくさ。
btmで終わりを示す方式だと多くの場合、個数numに対して
fill(first, first + num, val);
のようにしか書けないことが多い。

48:デフォルトの名無しさん
20/10/13 13:49:44.76 2ekPMyol.net
>>44
新しいものって現行規格に従っただけで馬鹿呼ばわりか？　ブーメランだろ
何を基準に新しいとか古いとか言ってるの？
俺に言わせりゃK&R1で憶えた立場からはC89でさえ新しいんだが

49:デフォルトの名無しさん
20/10/13 13:52:16.91 jGpIs/AO.net
>>46
Ruby, Perl, Python, JS, BASIC のどれでも、配列の処理範囲を示すのに
個数のパラメータを持っている。C言語でも、memcpyやmemcmpは、
memcpy(ptr1, ptr2, num)
memcmp(ptr1, ptr2, num)
であった。
numは、ptr1, ptr2 に共通の要素数なので1,2に対称性があり、とても分かり易いが
STLの流儀に倣って書き直すなら
memcpy(fisrt1, btm1, fisrt2, num)
memcmp(fisrt1, btm1, fisrt2, num)
となってしまうだろう。
この場合、btm1は「1」の終端であるが、「2」とは関連が分かりにくく、
「対称性」が失われている。
だから汚く見える。

50:デフォルトの名無しさん
20/10/13 13:54:08.20 2ekPMyol.net
>>45
C++使いの生理反射が消失してるな
不等号気持ち悪くないの？

51:デフォルトの名無しさん
20/10/13 13:55:47.45 2ekPMyol.net
>>48
copy(first1, last1, first2) な

52:デフォルトの名無しさん
20/10/13 13:56:07.20 jGpIs/AO.net
>>45
速度効率をさらに高めたいなら、
void fill(int *top, int n, int val)
{
　int *ptr = top;
　int *btm = top + num;
　while(ptr < btm) *ptr++ = val;
}
と書いても良い。
なので、fill()の内部的な処理効率自体はいくらでも速くできる。
問題は、fill()を使う側の利便性や分かり易さや対称性(=美しさ)。

53:デフォルトの名無しさん
20/10/13 14:11:21.12 alJhtdGu.net
>>47
文盲？

54:デフォルトの名無しさん
20/10/13 14:14:12.35 2ekPMyol.net
>>51
void fill(int* first, int* last, int val)
{
while (first != last) *first++ = val; //nがなきゃtop+nなんて計算そもそもいらん
}
呼び出し側でfill(first, last - first, val)なんてやられた日にゃ引いてから足し直すことになるだろ

55:デフォルトの名無しさん
20/10/13 14:19:38.29 FpFGKRx+.net
これはダメなんか遅いんか
void fill(int *first, int *last, int val)
{
while(first != last) *first++ = val;
}

56:デフォルトの名無しさん
20/10/13 14:44:57.22 jGpIs/AO.net
>>53
>呼び出し側でfill(first, last - first, val)なんてやられた日にゃ引いてから足し直すことになるだろ
それは屁理屈と言うか、もしあなたが頭のいい人なのに本気でそう思っているなら
机上の空論というか、実際のアプリ作製の経験が足りないと思われる。
ほとんどの場合、配列の処理範囲はlastではなく個数のnumの方が便利。
lastは割り出すのにワンクッション手間が増えてしまう。

57:デフォルトの名無しさん
20/10/13 15:08:27.75 f6jDEgc3.net
初心者がSTLを批判してもダメだろ。

58:デフォルトの名無しさん
20/10/13 15:19:48.82 f6jDEgc3.net
キミたちが言いたいのは、事前に個数がわからないのに関数を呼び出せるのはオカシイって事だろ？
STLは事前に個数がわからないにもかかわらず、関数を呼び出せてしまう。
これはストリームの機能ではないか？
オカシイ！と。
それは、呼び出せる方が汎用性があるんだよ。
全然オカシクない。

59:デフォルトの名無しさん
20/10/13 16:12:52.22 jGpIs/AO.net
>>56
当然だ。
初心者じゃないエキスパートだから批判している。

60:デフォルトの名無しさん
20/10/13 16:14:05.11 jGpIs/AO.net
>>57
そういう問題じゃない。
利便性が損なわれているから批判しているだけ。
論理的に正しいかどうかではなく、便利かどうかの観点。

61:デフォルトの名無しさん
20/10/13 16:14:51.63 2fTKv7IK.net
イテレータぐらいはイディオムとして慣れろや

62:デフォルトの名無しさん
20/10/13 16:21:31.28 jGpIs/AO.net
>>60
なんでこんな汚いライブラリに慣れなきゃならないの。
C++委員会がプログラマの思想を強制する権利は無い。

63:デフォルトの名無しさん
20/10/13 16:45:48.79 2fTKv7IK.net
>>61
じゃあお前ならどんなAPI設計にするの？

64:デフォルトの名無しさん
20/10/13 16:48:01.34 2ekPMyol.net
>>55
標準のcopy関数もロクに知らないくせに・・・いや、これは置いとく
では、おまえさんは配列の終点をどのように渡すんだ？
int main()
{
int dim[100];
fill(dim, /*ここ*/, 0);
}

65:デフォルトの名無しさん
20/10/13 16:49:01.87 zWj2VWPf.net
同値比較はコストがかかるケースもあるんじゃないですか？
要素数を指定するほうが処理コストが抑えられるような気がします
素人意見ですみません;_;

66:デフォルトの名無しさん
20/10/13 17:13:32.12 FpFGKRx+.net
配列だから話がややこしくなるんで
リストだったらどうみても始点終点やろ
インターフェースを合わせるために
配列も始点終点にしただけやろ

67:デフォルトの名無しさん
20/10/13 17:16:38.67 jGpIs/AO.net
>>65
リストでも繰り返しなら個数でもいける。
>>63
終点ではなく、個数で渡す:
fill(dim, 100, 0);　　// めちゃくちゃ分かり易い。
fill(dim, dim + 100, 0);　　// めちゃくちゃ不便。何このタイピング量。

68:デフォルトの名無しさん
20/10/13 17:19:05.56 jGpIs/AO.net
しかも問題なのは、vectorの中ほどで追加や削除をしても、終点が自動修正されないこと。
それでは始点と終点で管理している意味が無い。
listならいけることはいけるが。
しかし、結局、vetorとlistの違いを意識しなければバグることになる。

69:デフォルトの名無しさん
20/10/13 17:25:01.13 2fTKv7IK.net
>>67
建設的な議論しようや
お前ならどう設計するか書いてみ？

70:デフォルトの名無しさん
20/10/13 17:27:25.69 jGpIs/AO.net
>>68
アイデアを盗作、剽窃しようとするなよ。

71:デフォルトの名無しさん
20/10/13 17:34:02.61 2fTKv7IK.net
はい雑魚

72:デフォルトの名無しさん
20/10/13 17:44:12.19 jGpIs/AO.net
>>70
なんのこっちゃ。

73:デフォルトの名無しさん
20/10/13 18:08:23.24 2ekPMyol.net
>>66
ズコー(aary
↓こんなコード書いたらバカにしまくってやろうと思ってたのに
#define N 100
int dim[N];
fill(dim, N, 0);
その下をいきやがったｗ
マジックナンバーって言葉知ってる？

74:デフォルトの名無しさん
20/10/13 18:42:42.89 f6jDEgc3.net
レベルが低すぎて議論するだけ無駄なので、この話題はこれでお終いにしてはどうだろか。

75:
20/10/13 20:06:42.81 455DutI7.net
>>41
＞C++11の何が気に入らんの？
右辺値 && が……
よくわかりません
RVO 前提コードで私は妥協しているのですが

76:デフォルトの名無しさん
20/10/13 21:22:13.35 2ekPMyol.net
お気の毒に

77:デフォルトの名無しさん
20/10/13 22:22:30.85 vraeBdjb.net
よくそのレベルでSTLにケチつけられるなｗ

78:デフォルトの名無しさん
20/10/13 22:53:46.89 mhza1+DZ.net
>>35
×： void fill(int first[], int n, int val) //素直にこう書きやがれ
○： void fill(int first[], const int n, const int val) //素直にこう書きやがれ

79:デフォルトの名無しさん
20/10/13 23:00:47.08 1+uImEGd.net
個数不定や個数を数えるのがハイコストでも走査できたり、実在しないアドレスや好きな値でも番兵値として指定できたりするのがlast指定のifのメリットなんじゃね？
マップから取得した項目から走査したいとか、項目ごとにサイズが異なる連続データをメモリから読み出すとか、はたまたインタラクティブにユーザが終了指示するまで繰り返すとか。
個数指定のifもあれば便利だけど、どちらかを選択しないといけないなら、last指定のifだけ存在するほうがダメージが少ない

気がする

80:デフォルトの名無しさん
20/10/13 23:07:21.55 jGpIs/AO.net
>>78
もちろんそうなんだが、STLは馬鹿なので、そういう役目はほぼ果たしてない。
証拠として、途中の要素を削除してしまうとlastが全く意味を成さなくなるから。

81:デフォルトの名無しさん
20/10/13 23:26:38.01 8ZZNtI2L.net
何がどう証拠として、なのかわけが分からん。詳しく説明してくれ

82:デフォルトの名無しさん
20/10/13 23:27:15.76 SS1TQwr/.net
流れ全部読んでないけど上のほうで言ってる人がいるように
> void fill(int *first, int *last, int val)
を見た時点でCやってる人間からしたら関数内部が
> while(first < last) *first++ = val;
こう簡潔になってるだろうと想像しやすくてスッキリしてない？
別に想像する必要は無いんだけど想像してしまうというか
あと開始がポインタで終わりもポインタってのは対称的で良いと思う
> fill(dim, dim + 100, 0);　
これも上記の理由により気にならない
このわずかなタイピング量すら気になるんなら
そのソースコードには多分他の問題がある

83:デフォルトの名無しさん
20/10/13 23:50:29.75 jGpIs/AO.net
>>81
>あと開始がポインタで終わりもポインタってのは対称的で良いと思う
良くないよ。
その対称性は不要。
むしろ copyするときに dstとsrcの対称性がなくなることの方がずっと問題。
なぜなら間違い易いから。
それに
　fill(dim, dim + 100, 0);　
と書くときも dimの部分にケアレスミスが生じ易く、たとえば、
　fill(dim1, dim2 + 100, 0);　
と書いてもコンパイルエラーにはならないが結果は重大である。

84:デフォルトの名無しさん
20/10/13 23:51:31.80 jGpIs/AO.net
>>82
誤: と書くときも dimの部分にケアレスミスが生じ易く、たとえば、
正: と書くときも dim + 100 の部分にケアレスミスが生じ易く、たとえば、

85:デフォルトの名無しさん
20/10/13 23:56:23.05 SS1TQwr/.net
> 　fill(dim1, dim2 + 100, 0);　
そう間違えちゃう人は
fill(dim1, dim1 + 200, 0);
fill(dim1, dim1 + 100, 2);
fill(dim2, dim1 + 100, 0);
とも間違っちゃうから大変だね
そういう人は何より
fill(dim2, 100, 0);
の表記を使いたいんやろね
何か分かったわ

86:デフォルトの名無しさん
20/10/13 23:58:38.02 BWJh5EXt.net
全然別のコンテナのイテレータを混ぜて指定できてしまうのは確かに欠点なんだよね
だからRangeが必要だったんですね

87:デフォルトの名無しさん
20/10/14 00:11:56.45 lJFXTbVx.net
>>84
あなたの脳内にはプログラミングのセンスの様なものがまだ育ってない。
そういう人ばかりがC++委員会にいるので
「机上の空論的な設計」
と言われるようになっている。

88:デフォルトの名無しさん
20/10/14 00:20:29.03 lJFXTbVx.net
>>86
それに、先頭アドレスと長さを組にするというのは、プログラミングにおける
伝統になっていてPascal文字列やWin32のバッファの指定などもそれを
踏襲している。
topとbtmを指定する方法は番兵方式ともまた違う、STL独特の方式。
番兵方式はミスが入りにくいが、btmアドレスを指定する方式はbtmに
間違った値をしていた時にとんでも無い結果を生み、バッファオーバーラン
より酷い。
btmにtopとは全く関係の無いとんでもない値を指定できてしまうから。
配列は、0～N-1までの分かり易い値で位置を指定できることが特徴の一つなのに
STLはそれも破壊してしまっており、範囲チェックも分かりにくくなる。
高級言語なのに、アセンブラより複雑。
アセンブラでは少しでも高速化するためにtop,btm方式が使われたこともあったが、
この高級言語の時代にはそぐわない。
分かりにくい。

89:デフォルトの名無しさん
20/10/14 00:24:28.14 lJFXTbVx.net
もっといえば、MSがグラフィックで矩形を描くときに、
左上の点と右下の点を指定する方法もセンスが無いといわれている。
これも沢山グラフィックのプログラムをしてくると
左上の点と「サイズ」を指定するのが合理的であることが分かってくるが
経験が足りて無い人には「好みの差」程度にしか認識できない。
それともとても似ている。

90:デフォルトの名無しさん
20/10/14 00:34:35.60 eS9CcskG.net
ID:lJFXTbVxが参加するレビューは荒れる…
…！

91:デフォルトの名無しさん
20/10/14 00:36:44.29 eS9CcskG.net
つか(sx, sy, width, height)式の矩形表現は
クリッピングとかしだすと結局内部で
(sx, sy, ex, ey)表現に

92:デフォルトの名無しさん
20/10/14 00:40:01.03 eS9CcskG.net
効率的な番兵法は常にアルゴリズムとともにあるから
　　↓こんなやつ
　　while (buf[i] < buf[i]) { std::swap(buf[i], buf[i]); i--; } // buf[0]はINT_MAX
範囲の一般的表現のうちに含めるのは頭おかしい

93:デフォルトの名無しさん
20/10/14 00:44:56.12 W3antmDc.net
fill(p, p + n, 0);は
fill(p + m, p + n, 0);という表現にもスムーズに拡張できる
個数の場合は
fill(p + m, n - m, 0);って書くことになるね

94:デフォルトの名無しさん
20/10/14 00:47:49.37 g6nWODwp.net
ここまで fill_n 無し

95:デフォルトの名無しさん
20/10/14 01:12:33.89 qrfIlgcS.net
>>88
なんで？中心の点とサイズなら分かるけど
ついでに言うと左上右下で矩形表現するのは重なりや画面外は見出しの判定が楽だからそっちの方が便利な場合もある
事情に応じた使い分けを考慮できないあたりが経験足りないっすねあなた

96:デフォルトの名無しさん
20/10/14 02:21:44.28 dCmiKU7l.net
>>41の
＞range-based-for-statementの見た目からは驚かされる簡潔さなんかクールだろ
これに対して
 >>55の
＞机上の空論というか、実際のアプリ作製の経験が足りないと思われる。
＞ほとんどの場合、配列の処理範囲はlastではなく個数のnumの方が便利。
ここには同意する
実際問題、STLあるいはそれに倣ったコード以外、ソフト開発の場面で
range-basedで簡潔に済むループはそんなに無い(無理矢理書き換えることは出来るとしても)

97:デフォルトの名無しさん
20/10/14 02:44:00.29 EuYzPNma.net
てか
せっかくC++使ってんのに何故
リストの始点と終点とを別々に渡したり
リストの始点と要素数とを別々に渡したり
とかやりたがるの？

98:デフォルトの名無しさん
20/10/14 06:39:07.67 fAfIBrSZ.net
>>77
動作確認くらいしてから書けよ
URLﾘﾝｸ(codepad.org)

99:デフォルトの名無しさん
20/10/14 06:42:43.22 fAfIBrSZ.net
>>88
ここC++スレってこと忘れてねえか？
矩形クラス作って右下とサイズと両方使えるようにすれば済む話だろ

100:デフォルトの名無しさん
20/10/14 06:45:09.59 fAfIBrSZ.net
>>96
全要素とは限らないからだよ

101:デフォルトの名無しさん
20/10/14 06:46:30.43 fAfIBrSZ.net
fill(dim, 2, 98, 0); //引数４個
fill(dim + 2, dim + 98, 0); //引数３個

102:デフォルトの名無しさん
20/10/14 07:58:42.58 qpMvVLdo.net
>>83
ケアレスミス多いな。

103:デフォルトの名無しさん
20/10/14 08:14:56.28 eS9CcskG.net
>>97
>>97が同じ関数を定義したのだから仕方が無い
 >>77は×と○は×を○に修正せよと言う意味であって書き並べよと言う意味ではない

104:デフォルトの名無しさん
20/10/14 08:25:44.48 fAfIBrSZ.net
>>102
修正せよという主張が誤っていると指摘しているんだ
intというかポインタでも参照でもない値の引数のconstは多重定義において意味を成さない

105:デフォルトの名無しさん
20/10/14 09:06:12.19 +cbHRaf/.net
完全に初心者のイチャモンで、他の言語も使えて無さそうだから、何か一つやり遂げてみたら良いと思います。

106:デフォルトの名無しさん
20/10/14 09:18:06.97 fAfIBrSZ.net
具体性のない、更には漠然としすぎて一体何の話かわからんことしか言えないやつこそ初心者だろうが

107:デフォルトの名無しさん
20/10/14 09:31:01.91 eS9CcskG.net
>>103
関数内で修正しない変数にconstをつけよという当たり前の話、
C++ではCよりも関数引数についてもやりやすくなっているからやったら？
という話ェ、

108:デフォルトの名無しさん
20/10/14 09:31:55.45 eS9CcskG.net
訂正orz、
×：修正
○：値を変更

109:デフォルトの名無しさん
20/10/14 09:39:06.95 aLuhanwR.net
int引数にconst付ける意味ってなんですか？
値渡しされるのだから関数内で値が更新されても呼び出し元には関係ないこと（関心がないこと）だと思えますが

110:デフォルトの名無しさん
20/10/14 09:42:59.50 eS9CcskG.net
>>108
>呼び出し元には関係ないこと（関心がないこと）
左様
呼び出し元に見せる宣言文では値渡しのconstは外して良い
C++ならそれができる
Cではできない（constをつけるとしたら定義と宣言の両方に付けねばならない

111:デフォルトの名無しさん
20/10/14 09:43:23.77 lJFXTbVx.net
>>92
あなたは経験不足だからどちらの方が便利かが分かって無い。
どちらの方式も互いに単純変換できるが、現実のアプリにおいては個数の方が
便利だと言っているのだが、あなたにはそれが分からない。
そういう人達がC++委員会に多くなってきているからC++の仕様が変になって
きていると言われているのだよ。

112:デフォルトの名無しさん
20/10/14 09:45:58.36 lJFXTbVx.net
>>100
>fill(dim, 2, 98, 0); //引数４個
これは違う。
インタプリタ言語ではこのようになってしまうが、伝統的にはCでは、
fill(dim +2, 98, 0); //引数3個
と書ける。

113:デフォルトの名無しさん
20/10/14 09:50:15.45 fAfIBrSZ.net
>>111
うわー・・・俺が示したコードが読めてないな
おまえのコード、意味違ってるんだけどｗ

114:デフォルトの名無しさん
20/10/14 09:52:34.69 eS9CcskG.net
ていうか >>91まつがえた。n_、
正： while (buf[i-1] < buf[i]) { std::swap(buf[i-1], buf[i]); i--; } // buf[0]はINT_MAX
ｱｳﾁ、

115:デフォルトの名無しさん
20/10/14 10:09:01.38 lJFXTbVx.net
>>90 >>94
それはクリッピングする場合のみだ。
しかし、いまのグラフィックライブラリはクリッピングは基本的に自動化されているので
クリッピングをアプリプログラマが自分で行う必要がある頻度はとても低い。
そういうことが優先順位ということ。
ライブラリの良し悪しは優先順位の高い作業が楽に書けるかどうかで決まる側面がある
から経験不足の人は優先順位が分かって無いので良いライブラリはなかなか作れない。

116:デフォルトの名無しさん
20/10/14 10:31:42.62 Z4l68xx0.net
ライブラリの良し悪しは俺様の流儀に従っているかどうか、まで読んだ

117:デフォルトの名無しさん
20/10/14 10:52:50.19 fAfIBrSZ.net
>>106
全然当たり前じゃねえよ
値引数にconstはつけねえんだよ
周り見てみろよ
周りがあればの話だが

118:デフォルトの名無しさん
20/10/14 11:20:31.96 fAfIBrSZ.net
>>111
待ってるんだけど返事がないね
fill(dim +2, 98, 0);
これでどうやって&dim[98]を知り得るの？

119:デフォルトの名無しさん
20/10/14 11:38:41.41 +cbHRaf/.net
「個数のほうが便利で現代的で洗練されている」と言ってる人は、STLが何故このような設計になったのか、全く理解していないので
、公共の場で主張するのはよくないのでは？

120:デフォルトの名無しさん
20/10/14 11:43:45.06 RddNL28g.net
STLは何故このような設計になったか教えて

121:デフォルトの名無しさん
20/10/14 11:44:04.35 dCmiKU7l.net
>現代的で洗練されている
誰がそんなこと書いてんだ
てか現代的とか洗練とかアホかと
なぜそうなっているか理解出来てないのはお前、D&Eの日本語版にその辺の話は載ってるから読んでこい

122:デフォルトの名無しさん
20/10/14 11:53:23.30 fAfIBrSZ.net
標準を盲信しろとは言わない
おかしいと思うことはおかしいと言っていい
いい、つーか歓迎で議論には付き合う
「議論には」な、感情論だの押しつけだの
そういう見苦しいのは相手せん

123:デフォルトの名無しさん
20/10/14 12:09:10.96 lJFXTbVx.net
>>117
あなたが何も書いてなかったから、98は個数だと認識して書いた。
もし、btm要素であるなら、
fill(dim + 2, dim + 98, 0);
と書く

124:ことになるが、このような btm 要素を指定する書き方が現実的なアプリではコーディング的に非効率な問題のある書き方だと昨日から主張し続けている。

125:デフォルトの名無しさん
20/10/14 12:15:37.74 lJFXTbVx.net
>>122
なぜかといえば、現実の大規模アプリでは配列の先頭の名前は、もっとずっと長く、
たとえば、aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx
のようになっていることが多い。それで昔ながらの C スタイルであれば、
fill(aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx, 個数, value);
と書けば済むのに、STLスタイルだと、
fill_stl(aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx,
　　　aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx + 個数,
　　　value);
のように複数行で書かないといけないハメになってしまう。
そして、aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxxに似た
aXxxxXxxxXxxxXxxxXxxxXxxxYyyyXxxx
というような他の変数もあることが多く、そうなると、
fill_stl(aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx,
　　　aXxxxXxxxXxxxXxxxXxxxXxxxYyyyXxxx + 個数,
　　　value);
のように書き間違えてもコンパイルエラーにならないので非常に重大な問題を巻き起こす。
また、少し修正したい場合、topとbtmの両方を修正しなくてはならないのに、
どちらか片方の
aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx
だけを
aXxxxXxxxXxxxXxxxXxxxXxxxYyyyXxxx
に書き換えてしまって変数名が長いので気づきにくくてどこでバグが入ったか分からない
重大な問題が入り込んでしまうことが有る。
その点、昔ながらのCスタイルではこのような問題が起きないので安全。

126:デフォルトの名無しさん
20/10/14 12:20:41.76 GsUUoEHv.net
なるほど一里塚

127:デフォルトの名無しさん
20/10/14 12:23:42.24 fAfIBrSZ.net
>>123
只でさえ長い識別子に名前空間だのスコープだのテンプレート引数がついて読む気なくさせるようなのはよく見かけるね
そういうのはusingでエイリアス作ったり左辺値参照でスコープを狭めたりで対応するのがよくあるケース
auto first = aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx.begin();
auto last = aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx.end();
とでもやっとけば楽になるのもある
昔ながらのCやC++98にしがみつくのをやめてC++11～17の新機能を有り難く頂戴することで
色んなストレスから解放される

128:デフォルトの名無しさん
20/10/14 12:40:03.79 ssGc8zMA.net
>>123
「個数」で誤魔化されてんな
個数でもこうなるんじゃね
fill(aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx, aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx.size(), value);

129:デフォルトの名無しさん
20/10/14 12:52:15.34 lJFXTbVx.net
>>126
それは経験的にならないことが多い。
なぜなら、個数は配列自体が覚えているだけでなく、何らかの変数に入っている事がとても多いから。
典型的には、個数はマクロ変数やconst int変数などに入っているか
または、ファイルから読み込んだ場合には読み込んだときの個数が
グローバル変数などに入っている。

130:デフォルトの名無しさん
20/10/14 12:55:51.73 lJFXTbVx.net
>>127
それから、
>fill(aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx, aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx.size(), value);
の場合だと、たとえ第二引数の部分に間違いがあってもバグの程度がまだまし。
なぜなら、xxx.size()は個数なので間違いがあってもデバッガで見てもまだ分かり易いバグとなるし、
バッファオーバーランしても個数なのでどこかで停止してくれる。
ところが、btm要素方式の場合、書き間違えてbtm要素が全く別の配列の中を指してしまっている場合には
バッファオーバーランが停止することなくほぼ無限に続くことになる。

131:デフォルトの名無しさん
20/10/14 13:02:09.57 ssGc8zMA.net
つまりずっと配列前提の話をしてたワケ？
そりゃ旧来的な書き方の方が合理的だ
配列とその個数のデータ構造なら明らかにdefineされてる個数を与えた方がラクになるな

132:デフォルトの名無しさん
20/10/14 13:02:59.84 tpi9enQu.net
stl以前にエディタもまともに使えないって

133:デフォルトの名無しさん
20/10/14 13:04:53.29 lJFXTbVx.net
>>128
さらに、その場合、全要素を対象にしているから専用の関数などや
for each文などで対応できる。
一方、良くある例として、あるところから10個の要素に対して処理したい
などというものがある。
それは例えば、エディタを作っている場合に画面内に10行表示されていることが
分かっている場合だ。
そういう場合に、C流だと
draw_lines(&aXxxXxxXxxXxxXxxXxxXxxXxxXxxXxx[top], 10);
で良いのに対し、STL流だと
draw_lines(&aXxxXxxXxxXxxXxxXxxXxxXxxXxxXxx[top], &aXxxXxxXxxXxxXxxXxxXxxXxxXxxXxx[top + 10]);
ととても長くなる。

134:デフォルトの名無しさん
20/10/14 13:05:56.40 lJFXTbVx.net
>>129
STLはリンクリストではなく、(動的)配列を推薦しているから。

135:デフォルトの名無しさん
20/10/14 13:11:45.84 lJFXTbVx.net
>昔ながらのCやC++98にしがみつくのをやめてC++11～17の新機能を有り難く頂戴することで
>色んなストレスから解放される
同意しかねます。

136:デフォルトの名無しさん
20/10/14 13:20:20.16 ssGc8zMA.net
>>131
にしてもdefineされてる配列の個数の名前もお長いんでしょ？
#define A_XXXX_XXXX_XXXX_XXXX_XXXX_XXXX_XXXX_XXXX_SIZE (100000)
#define A_XXXX_XXXX_XXXX_XXXX_XXXX_XXXX_YYYY_XXXX_SIZE (100000)
＊＊＊
今度は

137:「個数」の代わりに「10」になってる行数を受け取る変数名もやっぱり長いんじゃなくて？肝心のところを短く書いてるから、短く見えるこういう変数になるんじゃないのかな const int aXxxXxxXxxXxxXxxXxxXxxXxxXxxXxx_Lines = get_draw_lines();

138:デフォルトの名無しさん
20/10/14 13:22:47.51 EoVZjJO9.net
よくこんなくだらないことに熱くなれるな

139:デフォルトの名無しさん
20/10/14 13:32:19.34 +cbHRaf/.net
STLは設計のお手本的な部分があり、誰もが良く学ぶべきだけど、今回の事例で初心者がどう感じるのか、データが取れたのでは？

140:デフォルトの名無しさん
20/10/14 13:34:00.13 lJFXTbVx.net
>>134
その様な場合でも、
C流:
draw_lines(&aXxxXxxXxxXxxXxxXxxXxxXxxXxxXxx[top],
　　　　　　numXxxXxxXxxXxxXxxXxxXxxXxxXxxXxx);
STL流:
draw_lines(&aXxxXxxXxxXxxXxxXxxXxxXxxXxxXxx[top],
　　　　　 &aXxxXxxXxxXxxXxxXxxXxxXxxXxxXxx[top + numXxxXxxXxxXxxXxxXxxXxxXxxXxxXxx]);
となりC流の方がまだまし。
それとC流だとハンガリアン記法で名前を付けて置けば、なんとかなってる。
STL流は最悪で、非常に危険な書き方。

141:デフォルトの名無しさん
20/10/14 13:34:55.35 HhRPmWpc.net
初心者は「ぼくちんのコードが長くなるからこの設計はクソ！」と言いがちなことが分かったので今後の教育の時に注意しようと思いました

142:デフォルトの名無しさん
20/10/14 13:35:10.63 lJFXTbVx.net
>>136
ちなみにどっちが初心者だと考えているのか。
こっちはプログラミングのエキスパートだが。

143:デフォルトの名無しさん
20/10/14 13:35:22.62 +cbHRaf/.net
引数に個数を指定するほうが洗練されていると初心者が言うけれど、設計の観点から言えば、事前に個数がわからなくても呼び出せるほうが汎用性がある。
つまり、ジェネリック。

144:デフォルトの名無しさん
20/10/14 13:37:07.37 +cbHRaf/.net
STLごときでつまずいてたら、関数型なんかさっぱり理解できないだろな。

145:デフォルトの名無しさん
20/10/14 13:40:26.69 +cbHRaf/.net
2chだった頃、このスレでもプッシュ型インターフェースが流行りかけてたんだよな。
5chになって若干質が落ちたんじゃないだろか。

146:デフォルトの名無しさん
20/10/14 13:41:57.79 HhRPmWpc.net
初心者くんはこの世の全ての範囲のendが「先頭からの個数」で決まる場合しかないと思い込んでるみたいだけど
例えばfindの検索結果とか、GUIの現在カーソル位置とかで決まる場合もあって、その場合だと本質的でない「個数」という数字を求めるコードが結局長くなってしまうことに注意しよう
簡単な練習問題だよ

147:デフォルトの名無しさん
20/10/14 13:44:01.55 ssGc8zMA.net
>>137
その配列のラッパークラスは作らんの？

148:デフォルトの名無しさん
20/10/14 13:51:26.20 Z4l68xx0.net
>>127
マクロ変数(定数？)とかグローバル変数とか生配列とか、旧態依然としたCの作法が好きなら無理にC++やSTLを使わずに自分の好きな道具を使えばいいんでないの？
今でも(そして恐らくこれから先も)変わらず使えるのだから。
自分の好みに合わないものを他人が嬉しそうに使ってるのが気に入らないの？

149:デフォルトの名無しさん
20/10/14 13:54:48.00 OK1/udlE.net
配列が個数を持ってるなら
fill(配列, 値);
で良くね？

次ページ