C++相談室 part153

**デフォルトの名無しさん** · 2020/10/10(土) 23:18:20.00

https://mevius.5ch.net/test/read.cgi/tech/1589424805/
※前スレ
C++相談室 part152
https://mevius.5ch.net/test/read.cgi/tech/1594528940/

テンプレおしまい

**デフォルトの名無しさん** · 2020/10/13(火) 23:50:29.75

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

**デフォルトの名無しさん** · 2020/10/13(火) 23:51:31.80

>>82
誤: と書くときも dimの部分にケアレスミスが生じ易く、たとえば、
正: と書くときも dim + 100 の部分にケアレスミスが生じ易く、たとえば、

**デフォルトの名無しさん** · 2020/10/13(火) 23:56:23.05

> 　fill(dim1, dim2 + 100, 0);　

そう間違えちゃう人は
fill(dim1, dim1 + 200, 0);
fill(dim1, dim1 + 100, 2);
fill(dim2, dim1 + 100, 0);
とも間違っちゃうから大変だね
そういう人は何より
fill(dim2, 100, 0);
の表記を使いたいんやろね
何か分かったわ

**デフォルトの名無しさん** · 2020/10/13(火) 23:58:38.02

全然別のコンテナのイテレータを混ぜて指定できてしまうのは確かに欠点なんだよね
だからRangeが必要だったんですね

**デフォルトの名無しさん** · 2020/10/14(水) 00:11:56.45

>>84
あなたの脳内にはプログラミングのセンスの様なものがまだ育ってない。
そういう人ばかりがC++委員会にいるので
「机上の空論的な設計」
と言われるようになっている。

**デフォルトの名無しさん** · 2020/10/14(水) 00:20:29.03

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

**デフォルトの名無しさん** · 2020/10/14(水) 00:24:28.14

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

**デフォルトの名無しさん** · 2020/10/14(水) 00:34:35.60

ID:lJFXTbVxが参加するレビューは荒れる…
…！

**デフォルトの名無しさん** · 2020/10/14(水) 00:36:44.29

つか(sx, sy, width, height)式の矩形表現は
クリッピングとかしだすと結局内部で
(sx, sy, ex, ey)表現に

**デフォルトの名無しさん** · 2020/10/14(水) 00:40:01.03

効率的な番兵法は常にアルゴリズムとともにあるから
　　↓こんなやつ
　　while (buf[i] < buf[i]) { std::swap(buf[i], buf[i]); i--; } // buf[0]はINT_MAX

範囲の一般的表現のうちに含めるのは頭おかしい

**デフォルトの名無しさん** · 2020/10/14(水) 00:44:56.12

fill(p, p + n, 0);は
fill(p + m, p + n, 0);という表現にもスムーズに拡張できる
個数の場合は
fill(p + m, n - m, 0);って書くことになるね

**デフォルトの名無しさん** · 2020/10/14(水) 00:47:49.37

ここまで fill_n 無し

**デフォルトの名無しさん** · 2020/10/14(水) 01:12:33.89

>>88
なんで？中心の点とサイズなら分かるけど
ついでに言うと左上右下で矩形表現するのは重なりや画面外は見出しの判定が楽だからそっちの方が便利な場合もある
事情に応じた使い分けを考慮できないあたりが経験足りないっすねあなた

**デフォルトの名無しさん** · 2020/10/14(水) 02:21:44.28

>>41の
＞range-based-for-statementの見た目からは驚かされる簡潔さなんかクールだろ
これに対して
>>55の
＞机上の空論というか、実際のアプリ作製の経験が足りないと思われる。
＞ほとんどの場合、配列の処理範囲はlastではなく個数のnumの方が便利。
ここには同意する

実際問題、STLあるいはそれに倣ったコード以外、ソフト開発の場面で
range-basedで簡潔に済むループはそんなに無い(無理矢理書き換えることは出来るとしても)

**デフォルトの名無しさん** · 2020/10/14(水) 02:44:00.29

てか
せっかくC++使ってんのに何故
リストの始点と終点とを別々に渡したり
リストの始点と要素数とを別々に渡したり
とかやりたがるの？

**デフォルトの名無しさん** · 2020/10/14(水) 06:39:07.67

>>77
動作確認くらいしてから書けよ
http://codepad.org/shRYygYw

**デフォルトの名無しさん** · 2020/10/14(水) 06:42:43.22

>>88
ここC++スレってこと忘れてねえか？
矩形クラス作って右下とサイズと両方使えるようにすれば済む話だろ

**デフォルトの名無しさん** · 2020/10/14(水) 06:45:09.59

>>96
全要素とは限らないからだよ

**デフォルトの名無しさん** · 2020/10/14(水) 06:46:30.43

fill(dim, 2, 98, 0); //引数４個
fill(dim + 2, dim + 98, 0); //引数３個

**デフォルトの名無しさん** · 2020/10/14(水) 07:58:42.58

>>83
ケアレスミス多いな。

**デフォルトの名無しさん** · 2020/10/14(水) 08:14:56.28

>>97
>>97が同じ関数を定義したのだから仕方が無い
>>77は×と○は×を○に修正せよと言う意味であって書き並べよと言う意味ではない

**デフォルトの名無しさん** · 2020/10/14(水) 08:25:44.48

>>102
修正せよという主張が誤っていると指摘しているんだ
intというかポインタでも参照でもない値の引数のconstは多重定義において意味を成さない

**デフォルトの名無しさん** · 2020/10/14(水) 09:06:12.19

完全に初心者のイチャモンで、他の言語も使えて無さそうだから、何か一つやり遂げてみたら良いと思います。

**デフォルトの名無しさん** · 2020/10/14(水) 09:18:06.97

具体性のない、更には漠然としすぎて一体何の話かわからんことしか言えないやつこそ初心者だろうが

**デフォルトの名無しさん** · 2020/10/14(水) 09:31:01.91

>>103
関数内で修正しない変数にconstをつけよという当たり前の話、
C++ではCよりも関数引数についてもやりやすくなっているからやったら？
という話ェ、

**デフォルトの名無しさん** · 2020/10/14(水) 09:31:55.45

訂正orz、
×：修正
○：値を変更

**デフォルトの名無しさん** · 2020/10/14(水) 09:39:06.95

int引数にconst付ける意味ってなんですか？
値渡しされるのだから関数内で値が更新されても呼び出し元には関係ないこと（関心がないこと）だと思えますが

**デフォルトの名無しさん** · 2020/10/14(水) 09:42:59.50

>>108
>呼び出し元には関係ないこと（関心がないこと）
左様
呼び出し元に見せる宣言文では値渡しのconstは外して良い
C++ならそれができる
Cではできない（constをつけるとしたら定義と宣言の両方に付けねばならない

**デフォルトの名無しさん** · 2020/10/14(水) 09:43:23.77

>>92
あなたは経験不足だからどちらの方が便利かが分かって無い。
どちらの方式も互いに単純変換できるが、現実のアプリにおいては個数の方が
便利だと言っているのだが、あなたにはそれが分からない。
そういう人達がC++委員会に多くなってきているからC++の仕様が変になって
きていると言われているのだよ。

**デフォルトの名無しさん** · 2020/10/14(水) 09:45:58.36

>>100
>fill(dim, 2, 98, 0); //引数４個
これは違う。
インタプリタ言語ではこのようになってしまうが、伝統的にはCでは、
fill(dim +2, 98, 0); //引数3個
と書ける。

**デフォルトの名無しさん** · 2020/10/14(水) 09:50:15.45

>>111
うわー・・・俺が示したコードが読めてないな
おまえのコード、意味違ってるんだけどｗ

**デフォルトの名無しさん** · 2020/10/14(水) 09:52:34.69

ていうか>>91まつがえた。n_、
正： while (buf[i-1] < buf[i]) { std::swap(buf[i-1], buf[i]); i--; } // buf[0]はINT_MAX
ｱｳﾁ、

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

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

**デフォルトの名無しさん** · 2020/10/14(水) 10:31:42.62

ライブラリの良し悪しは俺様の流儀に従っているかどうか、まで読んだ

**デフォルトの名無しさん** · 2020/10/14(水) 10:52:50.19

>>106
全然当たり前じゃねえよ
値引数にconstはつけねえんだよ
周り見てみろよ
周りがあればの話だが

**デフォルトの名無しさん** · 2020/10/14(水) 11:20:31.96

>>111
待ってるんだけど返事がないね
fill(dim +2, 98, 0);
これでどうやって&dim[98]を知り得るの？

**デフォルトの名無しさん** · 2020/10/14(水) 11:38:41.41

「個数のほうが便利で現代的で洗練されている」と言ってる人は、STLが何故このような設計になったのか、全く理解していないので
、公共の場で主張するのはよくないのでは？

**デフォルトの名無しさん** · 2020/10/14(水) 11:43:45.06

STLは何故このような設計になったか教えて

**デフォルトの名無しさん** · 2020/10/14(水) 11:44:04.35

>現代的で洗練されている
誰がそんなこと書いてんだ
てか現代的とか洗練とかアホかと
なぜそうなっているか理解出来てないのはお前、D&Eの日本語版にその辺の話は載ってるから読んでこい

**デフォルトの名無しさん** · 2020/10/14(水) 11:53:23.30

標準を盲信しろとは言わない
おかしいと思うことはおかしいと言っていい
いい、つーか歓迎で議論には付き合う
「議論には」な、感情論だの押しつけだの
そういう見苦しいのは相手せん

**デフォルトの名無しさん** · 2020/10/14(水) 12:09:10.96

>>117
あなたが何も書いてなかったから、98は個数だと認識して書いた。
もし、btm要素であるなら、
fill(dim + 2, dim + 98, 0);
と書くことになるが、このような btm 要素を指定する書き方が現実的な
アプリではコーディング的に非効率な問題のある書き方だと昨日から主張し続けている。

**デフォルトの名無しさん** · 2020/10/14(水) 12:15:37.74

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

**デフォルトの名無しさん** · 2020/10/14(水) 12:20:41.76

なるほど一里塚

**デフォルトの名無しさん** · 2020/10/14(水) 12:23:42.24

>>123
只でさえ長い識別子に名前空間だのスコープだのテンプレート引数がついて読む気なくさせるようなのはよく見かけるね
そういうのはusingでエイリアス作ったり左辺値参照でスコープを狭めたりで対応するのがよくあるケース
auto first = aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx.begin();
auto last = aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx.end();
とでもやっとけば楽になるのもある

昔ながらのCやC++98にしがみつくのをやめてC++11～17の新機能を有り難く頂戴することで
色んなストレスから解放される

**デフォルトの名無しさん** · 2020/10/14(水) 12:40:03.79

>>123
「個数」で誤魔化されてんな
個数でもこうなるんじゃね

fill(aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx, aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx.size(), value);

**デフォルトの名無しさん** · 2020/10/14(水) 12:52:15.34

>>126
それは経験的にならないことが多い。
なぜなら、個数は配列自体が覚えているだけでなく、何らかの変数に入っている事がとても多いから。
典型的には、個数はマクロ変数やconst int変数などに入っているか
または、ファイルから読み込んだ場合には読み込んだときの個数が
グローバル変数などに入っている。

**デフォルトの名無しさん** · 2020/10/14(水) 12:55:51.73

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

**デフォルトの名無しさん** · 2020/10/14(水) 13:02:09.57

つまりずっと配列前提の話をしてたワケ？

そりゃ旧来的な書き方の方が合理的だ
配列とその個数のデータ構造なら明らかにdefineされてる個数を与えた方がラクになるな

**デフォルトの名無しさん** · 2020/10/14(水) 13:02:59.84

stl以前にエディタもまともに使えないって

**デフォルトの名無しさん** · 2020/10/14(水) 13:04:53.29

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

**デフォルトの名無しさん** · 2020/10/14(水) 13:05:56.40

>>129
STLはリンクリストではなく、(動的)配列を推薦しているから。

**デフォルトの名無しさん** · 2020/10/14(水) 13:11:45.84

>昔ながらのCやC++98にしがみつくのをやめてC++11～17の新機能を有り難く頂戴することで
>色んなストレスから解放される
同意しかねます。

**デフォルトの名無しさん** · 2020/10/14(水) 13:20:20.16

>>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)

＊＊＊

今度は「個数」の代わりに「10」になってる
行数を受け取る変数名もやっぱり長いんじゃなくて？
肝心のところを短く書いてるから、短く見える

こういう変数になるんじゃないのかな
const int aXxxXxxXxxXxxXxxXxxXxxXxxXxxXxx_Lines = get_draw_lines();

**デフォルトの名無しさん** · 2020/10/14(水) 13:22:47.51

よくこんなくだらないことに熱くなれるな

**デフォルトの名無しさん** · 2020/10/14(水) 13:32:19.34

STLは設計のお手本的な部分があり、誰もが良く学ぶべきだけど、今回の事例で初心者がどう感じるのか、データが取れたのでは？

**デフォルトの名無しさん** · 2020/10/14(水) 13:34:00.13

>>134
その様な場合でも、
C流:
draw_lines(&aXxxXxxXxxXxxXxxXxxXxxXxxXxxXxx[top],
　　　　　　numXxxXxxXxxXxxXxxXxxXxxXxxXxxXxx);
STL流:
draw_lines(&aXxxXxxXxxXxxXxxXxxXxxXxxXxxXxx[top],
　　　　　 &aXxxXxxXxxXxxXxxXxxXxxXxxXxxXxx[top + numXxxXxxXxxXxxXxxXxxXxxXxxXxxXxx]);
となりC流の方がまだまし。

それとC流だとハンガリアン記法で名前を付けて置けば、なんとかなってる。
STL流は最悪で、非常に危険な書き方。

**デフォルトの名無しさん** · 2020/10/14(水) 13:34:55.35

初心者は「ぼくちんのコードが長くなるからこの設計はクソ！」と言いがちなことが分かったので今後の教育の時に注意しようと思いました

**デフォルトの名無しさん** · 2020/10/14(水) 13:35:10.63

>>136
ちなみにどっちが初心者だと考えているのか。
こっちはプログラミングのエキスパートだが。

**デフォルトの名無しさん** · 2020/10/14(水) 13:35:22.62

引数に個数を指定するほうが洗練されていると初心者が言うけれど、設計の観点から言えば、事前に個数がわからなくても呼び出せるほうが汎用性がある。
つまり、ジェネリック。

**デフォルトの名無しさん** · 2020/10/14(水) 13:37:07.37

STLごときでつまずいてたら、関数型なんかさっぱり理解できないだろな。

**デフォルトの名無しさん** · 2020/10/14(水) 13:40:26.69

2chだった頃、このスレでもプッシュ型インターフェースが流行りかけてたんだよな。
5chになって若干質が落ちたんじゃないだろか。

**デフォルトの名無しさん** · 2020/10/14(水) 13:41:57.79

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

**デフォルトの名無しさん** · 2020/10/14(水) 13:44:01.55

>>137
その配列のラッパークラスは作らんの？

**デフォルトの名無しさん** · 2020/10/14(水) 13:51:26.20

>>127
マクロ変数(定数？)とかグローバル変数とか生配列とか、旧態依然としたCの作法が好きなら無理にC++やSTLを使わずに自分の好きな道具を使えばいいんでないの？
今でも(そして恐らくこれから先も)変わらず使えるのだから。

自分の好みに合わないものを他人が嬉しそうに使ってるのが気に入らないの？

**デフォルトの名無しさん** · 2020/10/14(水) 13:54:48.00

配列が個数を持ってるなら
fill(配列, 値);
で良くね？

**デフォルトの名無しさん** · 2020/10/14(水) 14:08:57.43

>>141
いや、数学的ならむしろSTLより理解できる。

**デフォルトの名無しさん** · 2020/10/14(水) 14:35:28.55

>>146
常に全要素ならな

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

> こっちはプログラミングのエキスパートだが。

にーしちゃ恥ずかしいミスしてたね、さっき
fill(dim, 2, 98, 0); //引数４個
fill(dim + 2, dim + 98, 0); //引数３個
fill(dim +2, 98, 0); //伝統的にはCでは、(中略)と書ける。　←これｗ

**デフォルトの名無しさん** · 2020/10/14(水) 14:39:14.81

引数４個と３個の違いは有耶無耶にしたいのかな？

**デフォルトの名無しさん** · 2020/10/14(水) 15:03:45.73

GCC9で-std=c++2aが使えるんだけど…C++20です…これってさぁ…
実験的にサポートみたいな事行ってるけど、使ってもOKなの？
experimental supportって言ってるけど…みんなどうしてるの？

**デフォルトの名無しさん** · 2020/10/14(水) 15:07:19.79

>>151
「腕に自信のある奴は無償デバッグ要員になってくれ」という委員会からのお願い
見つけたバグやあやしい挙動の個数に応じて名を上げることも出来る

**デフォルトの名無しさん** · 2020/10/14(水) 15:14:57.44

>>149
あなた、話の流れを理解して無いですよ。

**デフォルトの名無しさん** · 2020/10/14(水) 15:15:36.27

C++17で行きます…17でも十分新しい…。

**デフォルトの名無しさん** · 2020/10/14(水) 15:16:35.85

>>153
で、終点アドレスではなく個数にすると
引数が少なく済むの？

**デフォルトの名無しさん** · 2020/10/14(水) 15:37:35.37

https://isocpp.org/std/status

**デフォルトの名無しさん** · 2020/10/14(水) 15:41:12.49

>>155
今回は、引数の個数は議題にはして無い。

**デフォルトの名無しさん** · 2020/10/14(水) 15:45:10.45

>>157
つまり「引数の個数が多くなるからSTLが問題」などとは全く言って無いということ。
別に個数方式にしても引数が少なくなると言うことではない。
引数の個数ではなく、コーディングする時の引数の記述量を減らせることが多い。
+演算子も使わなくて済むのでケアレスミスも減らせる。
またtopとbtmで重複する事を書かなくて済む。
そしてそれは安全性に繋がる。
なぜなら同じであるべきところを誤って異なるように書く可能性がなくなるから。

**デフォルトの名無しさん** · 2020/10/14(水) 15:51:28.70

お前の考える正しいライブラリがSTL以上に使われるなら、お前の意見にも一理あるのかもしれないけど。

ここで見た分には、初心者が使い方わからんと騒いでるだけに見える。

**デフォルトの名無しさん** · 2020/10/14(水) 15:53:12.69

>>157
いやいや、100に対して111の流れは引数の個数だよ

===== 引用開始 =====

100 自分：デフォルトの名無しさん[sage] 投稿日：2020/10/14(水) 06:46:30.43 ID:fAfIBrSZ [4/15]
fill(dim, 2, 98, 0); //引数４個
fill(dim + 2, dim + 98, 0); //引数３個

111 返信：デフォルトの名無しさん[sage] 投稿日：2020/10/14(水) 09:45:58.36 ID:lJFXTbVx [5/19]
>>100
>fill(dim, 2, 98, 0); //引数４個
これは違う。
インタプリタ言語ではこのようになってしまうが、伝統的にはCでは、
fill(dim +2, 98, 0); //引数3個
と書ける。

===== 引用終了 =====

しかもだよ、これインタプリタ方式とコンパイラ方式でどんな違いが出るの？
変に逃げ回ったり139みたいなプリティ発言するほど墓穴がでかくなるだけだぜ
ミスはミスで潔く認めたほうが被害拡大を防げると思うよ

**デフォルトの名無しさん** · 2020/10/14(水) 15:54:50.74

>>160
逃げたりとかじゃなく、あなたの言っている意味がこちらには伝わってないから
混乱が生じているだけ。
あなたの説明は言葉が足りて無いから。

**デフォルトの名無しさん** · 2020/10/14(水) 16:07:49.07

>>160
>しかもだよ、これインタプリタ方式とコンパイラ方式でどんな違いが出るの？
インタプリタ方式だと必ずそうなると言う意味ではなく、arr + 2
が「3番目の要素のアドレス」の意味で使えるのは、大体コンパイラ系の言語の仕様。
その意味で、
xxx(arr + 2,...) ではなく、xxx(arr, 2,...) のように書くのはインタプリタ言語
に多い書き方だから。

**デフォルトの名無しさん** · 2020/10/14(水) 16:49:10.93

>>161
いや伝わってるよ
配列と個数で渡す方式と、始点と終点で渡す方式で
引数の個数に違いが出るという100におまえさんは反応してて
しかも引数の個数を減らす例を示そうとしてた（そしてミスった）

>>162
コンパイラ方式というよりCの影響を受けた言語ってことだね
そうでない言語では配列+整数はSYNTAX ERRORかvalarrayのような話で

**デフォルトの名無しさん** · 2020/10/14(水) 16:53:34.15

>>163
あなたの言っていることは、理解できないので議論を終えることにします。
逃げているのではなく、意味が分からないので。

**デフォルトの名無しさん** · 2020/10/14(水) 17:07:55.33

結局、配列と個数で渡す方式が、始点と終点で渡す方式よりも
優位であることを示すのを諦めたわけだね

示せるわけがないという俺の予想どおりだわ

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

>>165
いや、十分に示せているはずなのに、このスレでは頑なに理解して貰えないだけです。

**デフォルトの名無しさん** · 2020/10/14(水) 17:15:40.91

「我はSTLを超える者なり！！」などと初心者が言い出してビックリしたわ。

**デフォルトの名無しさん** · 2020/10/14(水) 17:32:06.99

これだけくだらない問題に白熱してる時点でセンスがない

**デフォルトの名無しさん** · 2020/10/14(水) 17:36:09.65

>>166
で、配列と個数で渡すことで、始点と終点より引数の個数は減ったのか？

**デフォルトの名無しさん** · 2020/10/14(水) 17:37:36.44

だよね
どの話題に食いつくかでそいつの能力がわかる
このスレの老害はどうでもいいレベルの話を延々語る

**デフォルトの名無しさん** · 2020/10/14(水) 17:42:38.61

>どの話題に食いつくかで

自称数学者の発想ですね判ります

**デフォルトの名無しさん** · 2020/10/14(水) 17:48:04.39

131見るとわかるけど
コピペや置換する発想すらない人がstlの利点とか理解できるわけないし

**デフォルトの名無しさん** · 2020/10/14(水) 17:55:52.69

>>169
外国の人？
引数の個数が減るとは一言も言ってない。
引数の記述上の長さが減り、分かり易さや間違いにくくなるといっている。
さんざん同じ事を言っているのに、全く違うことを言ったことになってしまっている。

**デフォルトの名無しさん** · 2020/10/14(水) 18:23:42.32

機械翻訳して、長さと個数が混乱して訳されてしまっているのだろうか。

**デフォルトの名無しさん** · 2020/10/14(水) 18:53:52.73

>>147
数学で言う関数は関数型じゃないよ。
写像とか勉強したら？

**デフォルトの名無しさん** · 2020/10/14(水) 19:16:14.41

>>173
> fill(dim, 2, 98, 0); //引数４個
> 98は個数だと認識して書いた。

間違いにくいとか、間違えやすいとか、
それはおまえさんの個人的なことじゃねえかよ

配列と個数で渡すのが、始点と終点で渡すことよりも
優位だというのは、おまえさん個人が間違いにくいってことか？

言うまでもないが、俺は間違えずにコード示してて
間違えたのはおまえさんだけだぞ
それを一般論として優位ということにはできんだろ

**デフォルトの名無しさん** · 2020/10/14(水) 19:16:18.40

この手の配列の話でrangeが出てこないのはなんで？
最近の標準には疎いけど、この手の問題のほとんどがboost::rangeで解決しない？

**デフォルトの名無しさん** · 2020/10/14(水) 19:18:22.41

①std::list<Path>* pathListをソートするとします…。
②どっかのメソッドは…void sort(std::list<Path>* pathList)で受けるとします…。
③内部で以下のようにソートするとします…。
pathList->sort([](Path& o1, Path& o2) {
if(o1.getFileName().compare(o2.getFileName()) < 0) {
return true;
} else {
return false;
}
});

このときに！②メソッドで…void sort(std::list<Path>*& pathList)
としておかないと…なんか気持ち悪いんですが…
なんで参照の値渡しstd::list<Path>*だけで大丈夫なのかメモリアドレスまでは
僕は把握してません…参照の値渡しだけで行くだろうけど…なぜ大丈夫なのか説明できません…。

誰か…。

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

>>174
長さと個数の混同は「先頭アドレスを渡す」って前提で起きることだよな
dim + 2という例を示したら見事に思う壺にハマるやつがいてﾜﾛﾀ

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

>>178
日本語でどうぞ

**デフォルトの名無しさん** · 2020/10/14(水) 20:23:03.09

伝統的なバッドノウハウ
「ニワカなやつほど語りたがる」
ID:lJFXTbVxのことね