X
C++相談室 part153
■ このスレッドは過去ログ倉庫に格納されています
0002デフォルトの名無しさん
垢版 |
2020/10/11(日) 00:17:54.48ID:yrSMEX+0
STLつかうと一気に実行ファイルサイズが10倍に?！

環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない

すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。

C1010: ﾌﾟﾘｺﾝﾊﾟｲﾙ済みﾍｯﾀﾞｰの検索中に予期しない EOF を検出しました。
とかいうエラーが出るんだけどこれってどうすればいいの？

#include <stdafx.h>
後死ね。

言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。
0003デフォルトの名無しさん
垢版 |
2020/10/11(日) 07:46:00.50ID:2CDQ3L3B
>>1
乙。
0004デフォルトの名無しさん
垢版 |
2020/10/11(日) 07:49:37.39ID:eYoRN2yM
>>1
このほとんど投げやりな感じのテンプレがじつにいい
いかにもC++っていう感じがして好き
0005デフォルトの名無しさん
垢版 |
2020/10/11(日) 07:52:39.24ID:2CDQ3L3B
などと自画自賛。
0006デフォルトの名無しさん
垢版 |
2020/10/11(日) 09:59:16.21ID:kZXFoyze
stdafx.h include したら負け
0008◆QZaw55cn4c
垢版 |
2020/10/11(日) 16:35:47.97ID:sJNU+9dX
>>https://mevius.5ch.net/test/read.cgi/tech/1594528940/914
＞普段から、馬鹿な応答が多かったし、

認めましょう

＞「自分でコンテナクラス(リストなど)を作れるから天才」
＞だとか、男だったら基本中の基本の出来て当たり前の事が出来るだけで天才と言っている

そんな発言はしていませんよ、確かにコンテナを自作する、というのはやったことはありますが、「自分でつくるとイマイチだよね」というのが私の実感です
https://mevius.5ch.net/test/read.cgi/tech/1434079972/33

＞如何に周りのレベルが低いかが分かったから。

周り？
私はアマチュアだから、周りにプログラミングをする人はゼロですよ……
0012デフォルトの名無しさん
垢版 |
2020/10/12(月) 02:50:13.21ID:+FLMYxu9
QZ数ヶ月前俺にスルースキルが無いとか偉そうに言ってなかったっけ
C++に関わる話なら個人的には荒れててもいいと思うが、お前のプロフィールなんか誰も興味ないぞ
0013デフォルトの名無しさん
垢版 |
2020/10/12(月) 09:52:20.31ID:941JO02h
>>12
ttps://mevius.5ch.net/test/read.cgi/tech/1601271690/125
0014デフォルトの名無しさん
垢版 |
2020/10/12(月) 09:57:09.05ID:O4GtI7oq
>>13
それは仕方ないんじゃないかな。
人間だもの。
0016デフォルトの名無しさん
垢版 |
2020/10/12(月) 12:54:31.37ID:GHsqP2MR
今とあるOSSのライブラリの動きがあやしいのでデバッグしているんだけど
やっぱりいわゆるモダンなc++はデバッグがつらいわ
デバッガで見てもwrapの嵐でデータの中身になかなかたどり着けない
ステップ実行しててもRAIIをはじめ表面上見えない実装がノイズになってわけわかんなくなる
あとデバッグビルドは恐ろしくパフォーマンス落ちる(Cとかと比べてね)
0017デフォルトの名無しさん
垢版 |
2020/10/12(月) 14:12:21.06ID:941JO02h
C++ より C が良いね
0018デフォルトの名無しさん
垢版 |
2020/10/12(月) 15:18:22.15ID:Z3Kcjb2S
STLの unique_ptr, shared_ptr, vector, list, forward, move
といった非常に基本的なものもソースを解読するのはとても難しく
strcmpが3行くらいしかなかったのが懐かしい。
それにC++11以降の機能は非常に好みが分かれ、好きな人は好きだが
嫌いな人は反吐が出るほど嫌い。
0019デフォルトの名無しさん
垢版 |
2020/10/12(月) 15:23:21.42ID:N0jxybIn
Ubuntu20.04でGtkmmでアプリを作っています…ディレクトリとファイル一覧が欲しくて…。
C++17のstd::filesystemを使ったほうがスマートだと思うけど…使えません…。
そんな古い環境ではないと思うんだけど…direntやstatをやればできると思うけど…古いよね？
これカーネルだし…std::filesystemがスマートだと思うんだけど…このUbuntuではまだなの？
-std=c++17のオプションをつけてコンパイルしても駄目だった…。
0020デフォルトの名無しさん
垢版 |
2020/10/12(月) 15:27:01.65ID:O4GtI7oq
Ubuntuはgcc9使えたんじゃなかったかな。
gcc8はファイルシステム使うとき、ライブラリをリンクしないといけなかったと思う。

-lstdc++fs

gcc9から必要なかったと思うので、gcc9を使う方をお勧めします。
0021デフォルトの名無しさん
垢版 |
2020/10/12(月) 16:15:10.34ID:N0jxybIn
できました！できました！できましたが…EclipseCDT上で…名称が解決できてない感じ…。
とりあえず…動きました…もう少し調査します…。
0022デフォルトの名無しさん
垢版 |
2020/10/12(月) 16:27:02.58ID:N0jxybIn
名称も解決できました…使うよ！
0023デフォルトの名無しさん
垢版 |
2020/10/12(月) 16:56:02.38ID:941JO02h
>>18
速度も落ちてそう
0024デフォルトの名無しさん
垢版 |
2020/10/12(月) 19:26:54.38ID:Z3Kcjb2S
>>23
メタプログラミングの部分が複雑なだけで生成されるコードは最短に近い
のではないかと思う。
0027デフォルトの名無しさん
垢版 |
2020/10/12(月) 20:50:41.81ID:O4GtI7oq
文芸的プログラミングですね。
0028デフォルトの名無しさん
垢版 |
2020/10/13(火) 02:00:34.30ID:y5TdNrxl
>>25
STLの性能を維持しつつ簡潔に書ける人間
にしか許されない発言
0029はちみつ餃子 ◆8X2XSCHEME
垢版 |
2020/10/13(火) 03:46:05.57ID:jBq+pHZV
汎用的な部品は広い範囲をカバーするわけだから想定すべき状況が多くなるし、
その分だけ相応に複雑になるのは当たり前の話なんだよな。

逆に strcmp が簡潔だったとか言ってもそりゃあ char から成る文字列の比較に
特化していいなら簡潔に出来て当たり前ですよねってだけのことで、
機能が違うものの複雑さを比べようとするのは馬鹿馬鹿しいよ。
0030デフォルトの名無しさん
垢版 |
2020/10/13(火) 07:14:55.86ID:AAkThgLB
・同名の一時変数を使いまわす
・メモリの節約のために早めにデストラクタを呼ぶ
・スコープを小分けにして可読性を上げる

みたいな目的のために中括弧を多用するのってアリですか？
それともスコープじゃなくて関数を分けろってなりますか？
0032デフォルトの名無しさん
垢版 |
2020/10/13(火) 09:19:57.42ID:2ekPMyol
STLガーSTLガー言ってるやつ
そもそも++でないCでもポインタ引数２個で始点終点渡すのがロクに書けなさそうだね
0033デフォルトの名無しさん
垢版 |
2020/10/13(火) 09:53:49.84ID:f6jDEgc3
STLの凄さがわからない人もいるという。
0034デフォルトの名無しさん
垢版 |
2020/10/13(火) 10:50:05.42ID:y5TdNrxl
知ってることの精一杯がポインタのそれなんだな
クスクス
0035デフォルトの名無しさん
垢版 |
2020/10/13(火) 12:20:09.76ID:2ekPMyol
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++使わなくてよくね？
003731
垢版 |
2020/10/13(火) 12:48:18.65ID:alJhtdGu
いや、あの・・・
STL自体は非常に良く出来てると思うが、俺普段C++(あるいはC++11以降)マンセーSTLマンセーしてる連中は馬鹿にしてるからね・・・w
お前が作ったんちゃうやろと
0038デフォルトの名無しさん
垢版 |
2020/10/13(火) 12:50:17.06ID:FpFGKRx+
void fill(int *first, int *last, int val)
{
while(first < last) *first++ = val;
}
0039デフォルトの名無しさん
垢版 |
2020/10/13(火) 12:52:08.93ID:jGpIs/AO
理解は出来ないわけじゃなくSTL流に書くのが汚くて馬鹿みたいに感じるだけだ。
0040デフォルトの名無しさん
垢版 |
2020/10/13(火) 12:54:03.28ID:jGpIs/AO
配列は処理対象を個数で表現するほうが分かり易いし完結なのに、終端要素で
表そうとするのは単にSTLのとった設計思想の都合でしかないので
馬鹿っぽく感じる。
0041デフォルトの名無しさん
垢版 |
2020/10/13(火) 12:56:47.00ID:2ekPMyol
>>37
C++11の何が気に入らんの？
C++98でストレス溜まってたところを楽にしてくれてるやん
型指定子autoは同じことを二度も書かされる屈辱から解放してくれるし
range-based-for-statementの見た目からは驚かされる簡潔さなんかクールだろ
俺的にはテンポラリにconstが必須でなくなって痒いところに手が届いた
0042デフォルトの名無しさん
垢版 |
2020/10/13(火) 13:17:38.74ID:y5TdNrxl
①
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;
}

明らかに配列添字明示してる①のほうが無駄が多くて馬鹿っぽいけど
0044デフォルトの名無しさん
垢版 |
2020/10/13(火) 13:32:32.38ID:alJhtdGu
>>41
別に気に入らんとか言うとらんよvariadic templates無しの時代はキツかったし(逆に言えばテンプレート以外ではそんなに困らん)
新しいもの使ってる=上級者、だと思ってるような、権威を傘に着てる連中を馬鹿にしてると言ったの
マンセーとかの辺りで察してくれ
0045デフォルトの名無しさん
垢版 |
2020/10/13(火) 13:43:16.33ID:jGpIs/AO
伝統的にはこうで、速度も速い。
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;
　}
}
0046デフォルトの名無しさん
垢版 |
2020/10/13(火) 13:47:15.59ID:jGpIs/AO
>>42 >>43
fill()関数自体はどれでも分かりにくさは感じない。
問題はfill()関数を使う側の分かりにくさ。
btmで終わりを示す方式だと多くの場合、個数numに対して
fill(first, first + num, val);
のようにしか書けないことが多い。
0047デフォルトの名無しさん
垢版 |
2020/10/13(火) 13:49:44.76ID:2ekPMyol
>>44
新しいものって現行規格に従っただけで馬鹿呼ばわりか？　ブーメランだろ
何を基準に新しいとか古いとか言ってるの？
俺に言わせりゃK&R1で憶えた立場からはC89でさえ新しいんだが
0048デフォルトの名無しさん
垢版 |
2020/10/13(火) 13:52:16.91ID:jGpIs/AO
>>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」とは関連が分かりにくく、
「対称性」が失われている。
だから汚く見える。
0051デフォルトの名無しさん
垢版 |
2020/10/13(火) 13:56:07.20ID:jGpIs/AO
>>45
速度効率をさらに高めたいなら、
void fill(int *top, int n, int val)
{
　int *ptr = top;
　int *btm = top + num;
　while(ptr < btm) *ptr++ = val;
}
と書いても良い。
なので、fill()の内部的な処理効率自体はいくらでも速くできる。
問題は、fill()を使う側の利便性や分かり易さや対称性(=美しさ)。
0053デフォルトの名無しさん
垢版 |
2020/10/13(火) 14:14:12.35ID:2ekPMyol
>>51
void fill(int* first, int* last, int val)
{
while (first != last) *first++ = val; //nがなきゃtop+nなんて計算そもそもいらん
}
呼び出し側でfill(first, last - first, val)なんてやられた日にゃ引いてから足し直すことになるだろ
0054デフォルトの名無しさん
垢版 |
2020/10/13(火) 14:19:38.29ID:FpFGKRx+
これはダメなんか遅いんか
void fill(int *first, int *last, int val)
{
while(first != last) *first++ = val;
}
0055デフォルトの名無しさん
垢版 |
2020/10/13(火) 14:44:57.22ID:jGpIs/AO
>>53
>呼び出し側でfill(first, last - first, val)なんてやられた日にゃ引いてから足し直すことになるだろ

それは屁理屈と言うか、もしあなたが頭のいい人なのに本気でそう思っているなら
机上の空論というか、実際のアプリ作製の経験が足りないと思われる。
ほとんどの場合、配列の処理範囲はlastではなく個数のnumの方が便利。
lastは割り出すのにワンクッション手間が増えてしまう。
0056デフォルトの名無しさん
垢版 |
2020/10/13(火) 15:08:27.75ID:f6jDEgc3
初心者がSTLを批判してもダメだろ。
0057デフォルトの名無しさん
垢版 |
2020/10/13(火) 15:19:48.82ID:f6jDEgc3
キミたちが言いたいのは、事前に個数がわからないのに関数を呼び出せるのはオカシイって事だろ？

STLは事前に個数がわからないにもかかわらず、関数を呼び出せてしまう。
これはストリームの機能ではないか？
オカシイ！と。

それは、呼び出せる方が汎用性があるんだよ。
全然オカシクない。
0059デフォルトの名無しさん
垢版 |
2020/10/13(火) 16:14:05.11ID:jGpIs/AO
>>57
そういう問題じゃない。
利便性が損なわれているから批判しているだけ。
論理的に正しいかどうかではなく、便利かどうかの観点。
0061デフォルトの名無しさん
垢版 |
2020/10/13(火) 16:21:31.28ID:jGpIs/AO
>>60
なんでこんな汚いライブラリに慣れなきゃならないの。
C++委員会がプログラマの思想を強制する権利は無い。
0063デフォルトの名無しさん
垢版 |
2020/10/13(火) 16:48:01.34ID:2ekPMyol
>>55
標準のcopy関数もロクに知らないくせに・・・いや、これは置いとく

では、おまえさんは配列の終点をどのように渡すんだ？
int main()
{
int dim[100];
fill(dim, /*ここ*/, 0);
}
0064デフォルトの名無しさん
垢版 |
2020/10/13(火) 16:49:01.87ID:zWj2VWPf
同値比較はコストがかかるケースもあるんじゃないですか？
要素数を指定するほうが処理コストが抑えられるような気がします
素人意見ですみません;_;
0065デフォルトの名無しさん
垢版 |
2020/10/13(火) 17:13:32.12ID:FpFGKRx+
配列だから話がややこしくなるんで
リストだったらどうみても始点終点やろ
インターフェースを合わせるために
配列も始点終点にしただけやろ
0066デフォルトの名無しさん
垢版 |
2020/10/13(火) 17:16:38.67ID:jGpIs/AO
>>65
リストでも繰り返しなら個数でもいける。

>>63
終点ではなく、個数で渡す:
fill(dim, 100, 0);　　// めちゃくちゃ分かり易い。

fill(dim, dim + 100, 0);　　// めちゃくちゃ不便。何このタイピング量。
0067デフォルトの名無しさん
垢版 |
2020/10/13(火) 17:19:05.56ID:jGpIs/AO
しかも問題なのは、vectorの中ほどで追加や削除をしても、終点が自動修正されないこと。
それでは始点と終点で管理している意味が無い。
listならいけることはいけるが。
しかし、結局、vetorとlistの違いを意識しなければバグることになる。
0072デフォルトの名無しさん
垢版 |
2020/10/13(火) 18:08:23.24ID:2ekPMyol
>>66
ズコー(aary

↓こんなコード書いたらバカにしまくってやろうと思ってたのに
#define N 100
int dim[N];
fill(dim, N, 0);

その下をいきやがったｗ
マジックナンバーって言葉知ってる？
0073デフォルトの名無しさん
垢版 |
2020/10/13(火) 18:42:42.89ID:f6jDEgc3
レベルが低すぎて議論するだけ無駄なので、この話題はこれでお終いにしてはどうだろか。
0074◆QZaw55cn4c
垢版 |
2020/10/13(火) 20:06:42.81ID:455DutI7
>>41
＞C++11の何が気に入らんの？

右辺値 && が……
よくわかりません

RVO 前提コードで私は妥協しているのですが
0077デフォルトの名無しさん
垢版 |
2020/10/13(火) 22:53:46.89ID:mhza1+DZ
>>35
×： void fill(int first[], int n, int val) //素直にこう書きやがれ
○： void fill(int first[], const int n, const int val) //素直にこう書きやがれ
0078デフォルトの名無しさん
垢版 |
2020/10/13(火) 23:00:47.08ID:1+uImEGd
個数不定や個数を数えるのがハイコストでも走査できたり、実在しないアドレスや好きな値でも番兵値として指定できたりするのがlast指定のifのメリットなんじゃね？

マップから取得した項目から走査したいとか、項目ごとにサイズが異なる連続データをメモリから読み出すとか、はたまたインタラクティブにユーザが終了指示するまで繰り返すとか。

個数指定のifもあれば便利だけど、どちらかを選択しないといけないなら、last指定のifだけ存在するほうがダメージが少ない


気がする
0079デフォルトの名無しさん
垢版 |
2020/10/13(火) 23:07:21.55ID:jGpIs/AO
>>78
もちろんそうなんだが、STLは馬鹿なので、そういう役目はほぼ果たしてない。
証拠として、途中の要素を削除してしまうとlastが全く意味を成さなくなるから。
0081デフォルトの名無しさん
垢版 |
2020/10/13(火) 23:27:15.76ID:SS1TQwr/
流れ全部読んでないけど上のほうで言ってる人がいるように
> void fill(int *first, int *last, int val)
を見た時点でCやってる人間からしたら関数内部が
> while(first < last) *first++ = val;
こう簡潔になってるだろうと想像しやすくてスッキリしてない？
別に想像する必要は無いんだけど想像してしまうというか

あと開始がポインタで終わりもポインタってのは対称的で良いと思う
> fill(dim, dim + 100, 0);　
これも上記の理由により気にならない
このわずかなタイピング量すら気になるんなら
そのソースコードには多分他の問題がある
0082デフォルトの名無しさん
垢版 |
2020/10/13(火) 23:50:29.75ID:jGpIs/AO
>>81
>あと開始がポインタで終わりもポインタってのは対称的で良いと思う
良くないよ。
その対称性は不要。
むしろ copyするときに dstとsrcの対称性がなくなることの方がずっと問題。
なぜなら間違い易いから。
それに
　fill(dim, dim + 100, 0);　
と書くときも dimの部分にケアレスミスが生じ易く、たとえば、
　fill(dim1, dim2 + 100, 0);　
と書いてもコンパイルエラーにはならないが結果は重大である。
0083デフォルトの名無しさん
垢版 |
2020/10/13(火) 23:51:31.80ID:jGpIs/AO
>>82
誤: と書くときも dimの部分にケアレスミスが生じ易く、たとえば、
正: と書くときも dim + 100 の部分にケアレスミスが生じ易く、たとえば、
0084デフォルトの名無しさん
垢版 |
2020/10/13(火) 23:56:23.05ID:SS1TQwr/
> 　fill(dim1, dim2 + 100, 0);　

そう間違えちゃう人は
fill(dim1, dim1 + 200, 0);
fill(dim1, dim1 + 100, 2);
fill(dim2, dim1 + 100, 0);
とも間違っちゃうから大変だね
そういう人は何より
fill(dim2, 100, 0);
の表記を使いたいんやろね
何か分かったわ
0085デフォルトの名無しさん
垢版 |
2020/10/13(火) 23:58:38.02ID:BWJh5EXt
全然別のコンテナのイテレータを混ぜて指定できてしまうのは確かに欠点なんだよね
だからRangeが必要だったんですね
0086デフォルトの名無しさん
垢版 |
2020/10/14(水) 00:11:56.45ID:lJFXTbVx
>>84
あなたの脳内にはプログラミングのセンスの様なものがまだ育ってない。
そういう人ばかりがC++委員会にいるので
「机上の空論的な設計」
と言われるようになっている。
0087デフォルトの名無しさん
垢版 |
2020/10/14(水) 00:20:29.03ID:lJFXTbVx
>>86
それに、先頭アドレスと長さを組にするというのは、プログラミングにおける
伝統になっていてPascal文字列やWin32のバッファの指定などもそれを
踏襲している。
topとbtmを指定する方法は番兵方式ともまた違う、STL独特の方式。
番兵方式はミスが入りにくいが、btmアドレスを指定する方式はbtmに
間違った値をしていた時にとんでも無い結果を生み、バッファオーバーラン
より酷い。
btmにtopとは全く関係の無いとんでもない値を指定できてしまうから。
配列は、0～N-1までの分かり易い値で位置を指定できることが特徴の一つなのに
STLはそれも破壊してしまっており、範囲チェックも分かりにくくなる。
高級言語なのに、アセンブラより複雑。
アセンブラでは少しでも高速化するためにtop,btm方式が使われたこともあったが、
この高級言語の時代にはそぐわない。
分かりにくい。
0088デフォルトの名無しさん
垢版 |
2020/10/14(水) 00:24:28.14ID:lJFXTbVx
もっといえば、MSがグラフィックで矩形を描くときに、
左上の点と右下の点を指定する方法もセンスが無いといわれている。
これも沢山グラフィックのプログラムをしてくると
左上の点と「サイズ」を指定するのが合理的であることが分かってくるが
経験が足りて無い人には「好みの差」程度にしか認識できない。
それともとても似ている。
0090デフォルトの名無しさん
垢版 |
2020/10/14(水) 00:36:44.29ID:eS9CcskG
つか(sx, sy, width, height)式の矩形表現は
クリッピングとかしだすと結局内部で
(sx, sy, ex, ey)表現に
0091デフォルトの名無しさん
垢版 |
2020/10/14(水) 00:40:01.03ID:eS9CcskG
効率的な番兵法は常にアルゴリズムとともにあるから
　　↓こんなやつ
　　while (buf[i] < buf[i]) { std::swap(buf[i], buf[i]); i--; } // buf[0]はINT_MAX

範囲の一般的表現のうちに含めるのは頭おかしい
0092デフォルトの名無しさん
垢版 |
2020/10/14(水) 00:44:56.12ID:W3antmDc
fill(p, p + n, 0);は
fill(p + m, p + n, 0);という表現にもスムーズに拡張できる
個数の場合は
fill(p + m, n - m, 0);って書くことになるね
0094デフォルトの名無しさん
垢版 |
2020/10/14(水) 01:12:33.89ID:qrfIlgcS
>>88
なんで？中心の点とサイズなら分かるけど
ついでに言うと左上右下で矩形表現するのは重なりや画面外は見出しの判定が楽だからそっちの方が便利な場合もある
事情に応じた使い分けを考慮できないあたりが経験足りないっすねあなた
0095デフォルトの名無しさん
垢版 |
2020/10/14(水) 02:21:44.28ID:dCmiKU7l
>>41の
＞range-based-for-statementの見た目からは驚かされる簡潔さなんかクールだろ
これに対して
>>55の
＞机上の空論というか、実際のアプリ作製の経験が足りないと思われる。
＞ほとんどの場合、配列の処理範囲はlastではなく個数のnumの方が便利。
ここには同意する

実際問題、STLあるいはそれに倣ったコード以外、ソフト開発の場面で
range-basedで簡潔に済むループはそんなに無い(無理矢理書き換えることは出来るとしても)
0096デフォルトの名無しさん
垢版 |
2020/10/14(水) 02:44:00.29ID:EuYzPNma
てか
せっかくC++使ってんのに何故
リストの始点と終点とを別々に渡したり
リストの始点と要素数とを別々に渡したり
とかやりたがるの？
0098デフォルトの名無しさん
垢版 |
2020/10/14(水) 06:42:43.22ID:fAfIBrSZ
>>88
ここC++スレってこと忘れてねえか？
矩形クラス作って右下とサイズと両方使えるようにすれば済む話だろ
■ このスレッドは過去ログ倉庫に格納されています
ニューススポーツなんでも実況