C++相談室 part153 YouTube動画>6本 ->画像>3枚

http://2chb.net/r/tech/1589424805/
※前スレ
C++相談室 part152
http://2chb.net/r/tech/1594528940/

テンプレおしまい

STLつかうと一気に実行ファイルサイズが10倍に?！

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

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

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

#include <stdafx.h>
後死ね。

言葉が悪いな。それで教えているつもりか。
まぁヒントぐらいにはなったな。
うむごくろう。

>>1
乙。

>>1
このほとんど投げやりな感じのテンプレがじつにいい
いかにもC++っていう感じがして好き

などと自画自賛。

stdafx.h include したら負け

>>1乙

最近はpch.h

>>http://2chb.net/r/tech/1594528940/914
＞普段から、馬鹿な応答が多かったし、

認めましょう

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

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

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

周り？
私はアマチュアだから、周りにプログラミングをする人はゼロですよ……

C++の規格以外の話はｽﾚﾁ…

規格の話限定だったの？ここ

>>8
わざわざ馬鹿な引きニート相手に真面目な返答しなくても

QZ数ヶ月前俺にスルースキルが無いとか偉そうに言ってなかったっけ
C++に関わる話なら個人的には荒れててもいいと思うが、お前のプロフィールなんか誰も興味ないぞ

>>12
http://2chb.net/r/tech/1601271690/125

>>13
それは仕方ないんじゃないかな。
人間だもの。

批判されたら自演する修正なんてC++関係ない

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

C++ より C が良いね

STLの unique_ptr, shared_ptr, vector, list, forward, move
といった非常に基本的なものもソースを解読するのはとても難しく
strcmpが3行くらいしかなかったのが懐かしい。
それにC++11以降の機能は非常に好みが分かれ、好きな人は好きだが
嫌いな人は反吐が出るほど嫌い。

Ubuntu20.04でGtkmmでアプリを作っています…ディレクトリとファイル一覧が欲しくて…。
C++17のstd::filesystemを使ったほうがスマートだと思うけど…使えません…。
そんな古い環境ではないと思うんだけど…direntやstatをやればできると思うけど…古いよね？
これカーネルだし…std::filesystemがスマートだと思うんだけど…このUbuntuではまだなの？
-std=c++17のオプションをつけてコンパイルしても駄目だった…。

Ubuntuはgcc9使えたんじゃなかったかな。
gcc8はファイルシステム使うとき、ライブラリをリンクしないといけなかったと思う。

-lstdc++fs

gcc9から必要なかったと思うので、gcc9を使う方をお勧めします。

できました！できました！できましたが…EclipseCDT上で…名称が解決できてない感じ…。
とりあえず…動きました…もう少し調査します…。

名称も解決できました…使うよ！

>>18
速度も落ちてそう

>>23
メタプログラミングの部分が複雑なだけで生成されるコードは最短に近い
のではないかと思う。

設計者ももっと簡潔に書ける技能を身に付けるべきだと思うけどねん

>>19
-std=c++1zとかstd=gnu++1zじゃなかったっけ

文芸的プログラミングですね。

>>25
STLの性能を維持しつつ簡潔に書ける人間
にしか許されない発言

汎用的な部品は広い範囲をカバーするわけだから想定すべき状況が多くなるし、
その分だけ相応に複雑になるのは当たり前の話なんだよな。

逆に strcmp が簡潔だったとか言ってもそりゃあ char から成る文字列の比較に
特化していいなら簡潔に出来て当たり前ですよねってだけのことで、
機能が違うものの複雑さを比べようとするのは馬鹿馬鹿しいよ。

・同名の一時変数を使いまわす
・メモリの節約のために早めにデストラクタを呼ぶ
・スコープを小分けにして可読性を上げる

みたいな目的のために中括弧を多用するのってアリですか？
それともスコープじゃなくて関数を分けろってなりますか？

>>29
STLは理屈自体は非常に簡潔だとハゲも言っとる
的外れ

>>30
アリだのナシだの・・・

STLガーSTLガー言ってるやつ
そもそも++でないCでもポインタ引数２個で始点終点渡すのがロクに書けなさそうだね

STLの凄さがわからない人もいるという。

知ってることの精一杯がポインタのそれなんだな
クスクス

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++使わなくてよくね？

雑魚おつ

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

void fill(int *first, int *last, int val)
{
while(first < last) *first++ = val;
}

理解は出来ないわけじゃなくSTL流に書くのが汚くて馬鹿みたいに感じるだけだ。

配列は処理対象を個数で表現するほうが分かり易いし完結なのに、終端要素で
表そうとするのは単にSTLのとった設計思想の都合でしかないので
馬鹿っぽく感じる。

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

�@
void fill(int first[], int n, int val) //素直にこう書きやがれ
{
for (int i = 0; i < n; i++) //変数が増えることを気にしないのが富豪だ
{
first[i] = val; //配列要素へのアクセスには[]があるべきなんだよ
}
} //知ってることの精一杯がポインタのそれなんだなksks

と

�A
void fill(int *first, int *last, int val)
{
while(first < last) *first++ = val;
}

明らかに配列添字明示してる�@のほうが無駄が多くて馬鹿っぽいけど

>>42
うん、そう言いたかった
35の最終行で言ったつもりだった

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

>>42 >>43
fill()関数自体はどれでも分かりにくさは感じない。
問題はfill()関数を使う側の分かりにくさ。
btmで終わりを示す方式だと多くの場合、個数numに対して
fill(first, first + num, val);
のようにしか書けないことが多い。

>>44
新しいものって現行規格に従っただけで馬鹿呼ばわりか？　ブーメランだろ
何を基準に新しいとか古いとか言ってるの？
俺に言わせりゃK&R1で憶えた立場からはC89でさえ新しいんだが

>>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」とは関連が分かりにくく、
「対称性」が失われている。
だから汚く見える。

>>45
C++使いの生理反射が消失してるな
不等号気持ち悪くないの？

>>48
copy(first1, last1, first2) な

>>45
速度効率をさらに高めたいなら、
void fill(int *top, int n, int val)
{
　int *ptr = top;
　int *btm = top + num;
　while(ptr < btm) *ptr++ = val;
}
と書いても良い。
なので、fill()の内部的な処理効率自体はいくらでも速くできる。
問題は、fill()を使う側の利便性や分かり易さや対称性(=美しさ)。

>>47
文盲？

>>51
void fill(int* first, int* last, int val)
{
while (first != last) *first++ = val; //nがなきゃtop+nなんて計算そもそもいらん
}
呼び出し側でfill(first, last - first, val)なんてやられた日にゃ引いてから足し直すことになるだろ

これはダメなんか遅いんか
void fill(int *first, int *last, int val)
{
while(first != last) *first++ = val;
}

>>53
>呼び出し側でfill(first, last - first, val)なんてやられた日にゃ引いてから足し直すことになるだろ

それは屁理屈と言うか、もしあなたが頭のいい人なのに本気でそう思っているなら
机上の空論というか、実際のアプリ作製の経験が足りないと思われる。
ほとんどの場合、配列の処理範囲はlastではなく個数のnumの方が便利。
lastは割り出すのにワンクッション手間が増えてしまう。

初心者がSTLを批判してもダメだろ。

キミたちが言いたいのは、事前に個数がわからないのに関数を呼び出せるのはオカシイって事だろ？

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

それは、呼び出せる方が汎用性があるんだよ。
全然オカシクない。

>>56
当然だ。
初心者じゃないエキスパートだから批判している。

>>57
そういう問題じゃない。
利便性が損なわれているから批判しているだけ。
論理的に正しいかどうかではなく、便利かどうかの観点。

イテレータぐらいはイディオムとして慣れろや

>>60
なんでこんな汚いライブラリに慣れなきゃならないの。
C++委員会がプログラマの思想を強制する権利は無い。

>>61
じゃあお前ならどんなAPI設計にするの？

>>55
標準のcopy関数もロクに知らないくせに・・・いや、これは置いとく

では、おまえさんは配列の終点をどのように渡すんだ？
int main()
{
int dim[100];
fill(dim, /*ここ*/, 0);
}

同値比較はコストがかかるケースもあるんじゃないですか？
要素数を指定するほうが処理コストが抑えられるような気がします
素人意見ですみません;_;

配列だから話がややこしくなるんで
リストだったらどうみても始点終点やろ
インターフェースを合わせるために
配列も始点終点にしただけやろ

しかも問題なのは、vectorの中ほどで追加や削除をしても、終点が自動修正されないこと。
それでは始点と終点で管理している意味が無い。
listならいけることはいけるが。
しかし、結局、vetorとlistの違いを意識しなければバグることになる。

>>67
建設的な議論しようや
お前ならどう設計するか書いてみ？

>>68
アイデアを盗作、剽窃しようとするなよ。

はい雑魚

>>70
なんのこっちゃ。

>>66
ズコー(aary

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

その下をいきやがったｗ
マジックナンバーって言葉知ってる？

レベルが低すぎて議論するだけ無駄なので、この話題はこれでお終いにしてはどうだろか。

>>41
＞C++11の何が気に入らんの？

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

RVO 前提コードで私は妥協しているのですが

お気の毒に

よくそのレベルでSTLにケチつけられるなｗ

>>35
×： void fill(int first[], int n, int val) //素直にこう書きやがれ
○： void fill(int first[], const int n, const int val) //素直にこう書きやがれ

個数不定や個数を数えるのがハイコストでも走査できたり、実在しないアドレスや好きな値でも番兵値として指定できたりするのがlast指定のifのメリットなんじゃね？

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

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


気がする

>>78
もちろんそうなんだが、STLは馬鹿なので、そういう役目はほぼ果たしてない。
証拠として、途中の要素を削除してしまうとlastが全く意味を成さなくなるから。

何がどう証拠として、なのかわけが分からん。詳しく説明してくれ

流れ全部読んでないけど上のほうで言ってる人がいるように
> void fill(int *first, int *last, int val)
を見た時点でCやってる人間からしたら関数内部が
> while(first < last) *first++ = val;
こう簡潔になってるだろうと想像しやすくてスッキリしてない？
別に想像する必要は無いんだけど想像してしまうというか

あと開始がポインタで終わりもポインタってのは対称的で良いと思う
> fill(dim, dim + 100, 0);　
これも上記の理由により気にならない
このわずかなタイピング量すら気になるんなら
そのソースコードには多分他の問題がある

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

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

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

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

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

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

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

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

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

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

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

ここまで fill_n 無し

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

なるほど一里塚

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

>>146
常に全要素ならな

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

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

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

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

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

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

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

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

https://isocpp.org/std/status

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

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

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

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

>>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みたいなプリティ発言するほど墓穴がでかくなるだけだぜ
ミスはミスで潔く認めたほうが被害拡大を防げると思うよ

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

誰か…。

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

>>178
日本語でどうぞ

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

俺も本当はもっとおとなしく話すつもりだったのに
エキスパートとかプリティ発言するから予定外にいじめっちゃうのを余儀なくされたのよ

Go や Rust でスライスを言語の基本要素として取り入れたのは
ポインタでやりくりするのが (少なくとも今となっては) あまりイケてない方式
という判断があってのことなんだろうな。

ポインタこそが大事
ポインタこそが肝心
Cで一番大事なのはポインタ
C++は知らん

>>178
俺はお前さんの文章が｢なんか気持ち悪い｣よ。
話し言葉もそんな感じなのか？

>>178
https://ideone.com/x1NTqd
std::list<Path>& pathList
でいいじゃん．なぜ
std::list<Path>* pathList
なんだ？

>>116
なんじゃそりゃ；；
>>116は周りが死ね言うたら死ぬんか…？

>>178
ポインタの値自体はコピーされるけどその指してる先は同じだから

>>137
aXxxXxxXxxXxxXxxXxxXxxXxxXxxXxx[aXxxXxxXxxXxxXxxXxxXxxXxxXxxXxx_NUM]

これのラッパークラスとかは作らんの？

begin, lengthでなくてbegin、endになっているのは
具体的に言えばNULL終端の文字列みたいなものにでもゼロコストで対応できるからでしょ
わかりやすさ〜とかそういう感覚的なもの以前の話として、
length案は共通インタフェースを定める目的にあってない
既に上に何人かが同じ内容を書いてるけどなぜわからんかな

>>ID:+cbHRaf/
>>120には言い返して来ないんだなww

>>187
で、おまえさんの周りには値引数にconstつけてるバカはいたのか、いなかったのか、どっちだ？

初心者はぼくちんのコードさえ短くわかりやすくなればそれでいいしそれが正しいと考えがちなので
共通インターフェースの必要性とか重要性は理解以前に想像もできないんだよね
その辺を教え込むのはたいへんだ

STLは共通インターフェースの策定の失敗例。

配列ではポインタがイテレータとして機能するし、イテレータとしての要件を満たしてもいる。
そうなるようにデザインされたのは自明だな。

ポインタに合わせて統一したのが全面的に良いとは言えないのかもしれないが、
イテレータの枠組みに配列やポインタを含まないデザインにするというのは
C++ の立場からするとありえない選択でもあるし、
要するに「仕方ない」としか言えんわ。

autoないときはイテレータめんどくさかったけど今は別になあ

もうautoなしでは書けんわ

catch(nested_exception& nx)
{
auto C2065_p = dynamic_cast<C2065_t*>(&nx);
auto C2146_p = dynamic_cast<C2146_t*>(&nx);
auto C2653_p = dynamic_cast<C2653_t*>(&nx);
auto C2672_p = dynamic_cast<C2672_t*>(&nx);
}

lengthなんて数行で実装できるじゃんｗ
自分用のテンプレに入れときゃ解決ｗ

std::distance

ﾜﾛﾀ

aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx
↑この時点で手遅れレベルで腐ってるのは誰も指摘してやらないんだなｗ

>>192
> 値引数にconstつけてるバカ

お題スレで答えてるやつにおったわ
みんなに空気として扱われてたけど

俺は>>187じゃなくて横からね
いちおう断っておく

思ったほど落ちてなかった

>>202
手遅れだからそっとしといた

>>203
はいはい横ねー

エディタでは中核のデータであろう文字列の配列が
aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx
っていう名前で、しかもそれとは別に
aXxxxXxxxXxxxXxxxXxxxXxxxYyyyXxxx
みたいな、また別の文字列配列が存在する世界観なんでしょ

しかもそれぞれにどういうワケか
aXxxxXxxxXxxxXxxxXxxxXxxxXxxxXxxx_NUM
aXxxxXxxxXxxxXxxxXxxxXxxxYyyyXxxx_NUM
みたいな定数がdefineされている

それらの配列は
aXxxxXxxxXxxxXxxxXxxxXxxx_NUM
で統一されているわけではない

「変数名を長くすればSTLの書き方ではとても長くなるので、STLの書き方はダメです」
と言うためだけにわざわざ作られた長い名前だから、名前が長い

ダメと言うためにわざわざ作られたダメな例なんだから、そのリクツの中ではSTLがダメなように見えるのは、彼の中では当然だよ
だってダメになるように作られたダメな例だもん

頭おかしいのがまた湧いてるな

値引数にconstつけてても別にいいと思うけどね
コピーで渡してなおかつconstであることを明示したいなら
むしろconstで引数渡さないって言いはるのは思考停止のバカ

同意
自分はそれ思いつつも、文法上の、狭い関数内だけでのバグ抑止以上の価値は無いだろうと考えて、やってないけど
あえてやってる人が居てもバカにしようとは思わない

>>210
仮引数は変更しないって前提で思考停止してるのはお前だよ
void fill(int* first, int n, int val)
{
while (n--) *first++ = val;
}
関数の定義を別の翻訳単位に分離したら
それこそ定義かくやつだけの問題で
const付けろ付けるなと騒いでも他人の仕事に口出すなってだけ

おまえらと違ってこちとらおまえらごとき論破するのに侮辱語はいらねえ

>>212
関数定義について言ってるに決まってるだろ
変更しないっていう前提で固定してるわけじゃないし
妄想激しいね

日本語でおｋ

そうやって僕ちゃんが正しいんだ！
あいつはくそだ！
って一生逃げ回ってろカス

捨て台詞にしちゃ迫力も何もねえなｗ

>>211
同感。いうほど意味はないけどまあ悪いことではないよな、みたいな感覚

>>216
小学生が｢やーい、おまえのかーちゃん出べそ｣って言うのと似たような感じだな。
昭和の漫画の中にしか存在しないけどw

絵に描くとこんな感じだなｗ

今ゲーム開発に向いてるライブラリってなんですか？
これまでdxlibとsiv3dは使ったことありますが今の主流が知りたいです

UE4

2次元で良ければ
ama損.co.jp
dp/4899774451
dp/4899775067
dp/4899774117

EASTL

>>223
本気で言ってんの？

SFML

SDL2 + OpenGL

>>220
ゲームの内容による
Xウイングでタイファイターと戦うようなのもあれば
将棋やウォーゲームみたいのもある

>>227
dxlibとsiv3dに代わるものはあるかと聞かれてんのに的外れ
知ったか乙とでも言って欲しいのか

>>224
冗談で言ってるとでも？使ったこともないくせに。


俺はないよ

>>220
C#に浮気してUnityという手もある。
といっても扱ったの6年前（大学生の頃）だから現ゲーム業界事情は詳しくないが。

てか、この手の質問がでてきたということは、現状の開発に限界を感じているということでは？

知ったかこいてマウント取るしか出来ないアホばっかだな
EASTLがレンダリングとか担ってくれるのかよ

冗談か通じない奴だな…

嘘つけ

>>220
てかDirectXスレかゲ制作技術板行った方がいいよマジで
ここに住み着いてるのはまともにソフト書き上げたことすら無い奴ばっかだから

DirectXって...
ゲーム作る以前に、車輪の再発明して終わりそう。

>>228
よく読めよ。
「主流が知りたい」だろ。
代わるものじゃない。

ライブラリの主流は何か=dxlib等に代わるもの、だと思ったんだが
まぁそもそもC++で一から作りたいのか勉強がしたいのか、単に趣味でゲーム作りたいのかわからんから
何とも言えないけど

これ以上話も続かなそうだからボカすけど
俺はそれこそがすっごいアホっぽいと思う
C++で言うとイテレータのインクリメントをi++で書いちゃってるのより
必要も無いのにnewしてdeleteしてるのより
それよりももっと恥ずかしいと思う

C++/WinRTやってる人いる？
ここの人達はあまりWindows好きじゃないかな

winはやまほどいるだろうけどrtは全然おらんのじゃないか

だよね
ちょっと自力でがんばってみる！

>>227
バカのくせに思慮深さを見せようとしてんじゃねえよｗ
結局オナニーしかできないんだな

>>220
dxlib や siv3d (OpenSiv3d) は十分に主流の一翼を担っているように思うが……。
C++ 的には dxlib は設計が古臭い感じはあるかな。

具体的なことが決まっているわけじゃなくて単に他にどんな選択肢があるのか
ということなら、私が知っているのはこれくらい。

https://github.com/altseed/Altseed
http://www.tilengine.org/
https://www.sfml-dev.org/
https://box2d.org/
https://godotengine.org/

Twitter とかで流れてきた話題の中で面白そうなのをちょっとブックマークしていた
という程度なんで具体的に利用してみたことはないんだが、
話題になる程度にはまともな完成度なんだと思う。

>>228
235の指摘もそうだが
知ったかって「内容による」と言ったのが
お前さんにはそんなに高度な指摘に聞こえたのか？
手加減しきれねえ相手だなｗ

>>241
バカ？
おまえさんにだけは言われたくねえな

昨日までいじめっちゃったやつだろ
悔しいそうだなｗ

訂正　悔しそうだなｗ

> おまえらと違ってこちとらおまえらごとき論破するのに侮辱語はいらねえ
このあと逆に論破されて小学生みたいな煽りしてたなｗ

悔しかったら反論してみろ

>>243
いつものアホだろうから相手したくないんだが
「内容によらない」と言われてんだよ気付けよ

> おまえらと違ってこちとらおまえらごとき論破するのに侮辱語はいらねえ

https://emotion-ai.userlocal.jp/documents/65ce7e112b0f132f4f46ce2e611994dc/result?nr=1
> 怒りの感情が強い文章です

論破されて怒っちゃったかな？初心者くん

>>246
ねえねえ斉藤さん、どれのこと？
具体的なレス番とフレーズ教えてｗ

>>248
うわ、内容によらないって主張か
なるほど、俺の手に負えない超アホだな

将棋に向いてるライブラリと向いてないライブラリを具体的に言えばばいいんじゃないの

いやいや、質問者が書いてるのはどちらも3Dの(2Dでも使えるけど)"グラフィックス周りの"ライブラリだぞ

いや適当なこと抜かすから将棋に向いたゲームライブラリあるなら上げてみればって言っただけだけど

>>254
ゲーム用である必要全然ないね
shogiguiとか中覗いたことある？

なんだこのスレ

マウント取ろうとして返り討ちに遭ったカブトムシがいるスレです

>>255
ググってみたが既製のソフトやんけ
>>257
自己紹介乙ww

C++のメンターは半年で精神を害してやめるか廃人になる

そりゃお前さんの会社がブラックなだけだろ

まあ江添みたいな輩といっしょに働いてたらメンタル壊れるだろうな。
まともに話ききやしねーし。

奇貨居くべし

>>261
>>259 をよく読め
>>259 は「メンター」と付き合うとメンタルが壊れる、と言っているのではなく
「メンター」自身がメンタルが壊れて、結果、メンターという存在が皆無になる、と言っているのだよ、事態はより深刻なんだ

>>258
既成のソフト以外の何だと思ったの？

マウント取り損なったのが誰かは、誰の目にも明らかなので
安っぽいネットスラングで返しても無駄だよｗ

もはやC++でゲーム開発は向いていないのでは
今時型安全なんて時代遅れだよ

>>264
ID:U3N3/O+C
> おまえらと違ってこちとらおまえらごとき論破するのに侮辱語はいらねえ

https://emotion-ai.userlocal.jp/documents/65ce7e112b0f132f4f46ce2e611994dc/result?nr=1
> 怒りの感情が強い文章です

論破されて怒っちゃったかな？初心者くん

>>265
1つくらい正しいこと言えよ。
今でも重量級ゲームはC++が主流。rustに流れる可能性はあるけど
あとC++は型安全ではない

>>266
アフィサイトのNGワード程度の「解析」に依存しちゃってる自分恥ずかしくないの？

2回も繰り返しちまって可哀想にｗ

縁起悪いから黙ってろ バカが伝染る

あっ、斉藤！！

ごめんだけど、他でやってくれないかな。

相談です。C++を完全に理解するにはどうすればいいですか？

神に近い存在になること

大学生起業家が設立１年で20億円調達！ 単発バイトアプリに外食企業など出資【タイミー】
https://foodfun.jp/archives/3490
誰でもカンタンにオンラインサロン・情報配信ができる便利アプリ【TOUKU（トーク）】が登場
https://prtimes.jp/main/html/rd/p/000000001.000061569.html
中学時代の車いす生活から、17歳で起業するまで
https://www.advertimes.com/20200130/article306925/
ミャンマー発 AIダイニングアプリ「Yathar」をしかける日本人起業家
https://roboteer-tokyo.com/archives/14840
自分の視野は「世の中の0.001%」と自覚せよ。ビジネスチャンスを掴む4つの習慣
https://headlines.yahoo.co.jp/hl?a=20200511-00010001-srnijugo-life
アプリの視聴率がわかる　高専卒起業家の独創力
https://www.nikkei.com/article/DGXMZO46695580Y9A620C1000000/
１万人の若者を支援！インターンが日本を変えるかも！？　glowshipの若き創業者・足立卓也氏インタビュー
https://sogyotecho.jp/glowship-adachi-interview/
まだ22歳の学生社長が得た､23億円の｢使い道｣ あの橋本環奈をCMに使うバイトアプリの雄
https://toyokeizai.net/articles/-/319511

twitterで
C++完全に理解した！
って呟けばOK

コンパイラを実装してみれば嫌でもﾜｶﾙ

そんな極端なキチガイみたいなこと言うな!
・・とかつっこみたいかもしれないが、意外とそれ真理から困る >>277
C++ が現状あちこち解り辛い仕様になってる色々な理由のほとんどが
コンパイラの実装の都合であることがおおい

>>273
この人達>>277、>>278の言う事を真に受けるのなら、組み込み開発をやるといい。
アセンブラレベルでC++が理解できる。
コンストラクタ、デストラクタがどのようなタイミングで呼ばれるのか、グローバル変数、ローカル変数はどのようなメモリ領域を使うのか、ヒープ領域の挙動...経験を積むと自然にC++の細かい挙動が理解できる。

そういうミクロな話じゃない？
なら、常にC++の最新企画の仕様を調べよ。
入門書に書かれていない便利な機能が色々あるぞ。

そういえば質問内容は完全に理解したいだったな。じゃあ、どっちもやれ。

完全に理解と型安全には正直ゴールがあるかどうか疑わしい

>>279
そういう話になるから結局C++じゃなくてCからやれって話になるんだよ
C++は有害

>>281
どこに有害要素があるのかわからん。

>>279
そうしてソフト構築能力皆無な
C++博士ができあがったのだった

> そうしてソフト構築能力皆無な
> C++博士ができあがったのだった

まぁ、C++を完全に理解したところでっていうね。
そんな暇あれば別言語を学んだり、フレームワークの使い方を学んだりDDDやTDDとか学べって話だわな。

オブジェクト指向プログラミングと言っても、各コンポーネントというかプログラムの最小単位は多くの場合手続き型で記述することになるよな？
どこからどこまでを「最小単位」と見なすか、という問に対する基準というかガイドラインを知りたいな（筆者の主観が混じるとしても）

この時代に生きててSNS発信を頑張らないやつはアホだ。


【事例付き】YouTuberは最強の副業である件について。

;t=267s
【初心者向け】YouTubeの始め方・稼ぎ方を徹底解説！


【貧者の工夫で戦え】ガラケーだっていい。YouTube始めるのにパソコンはいらない！


YouTubeを伸ばすコツ【５つの本質論／初心者向けのセミナーです】


【悲報】YouTuberはマジで難しいので、ほぼ挫折すると思う【無理ゲー】

ソフトウェアの良い設計というのは
結果的に破綻も漏れも無く抽象化できていればおk
あくまで結果
成功の秘訣は8割方センス

>>287
あらゆる仕事はスーパーマンがやれば全て解決という
結局何も言ってない空論

現場でマジこれ言ってるやつは求人にクリプトン星人と書いている
人事屋としての究極の無能

>>285
正直言うと、当たり前のように使われる手続き型という言葉がピンと来ない。

オブジェクト指向におけるソースコードの適切な分割方法を知りたいってこと？

抽象レイヤーから具象レイヤーまで順番に話を進めていく方が俺は好きだがな。
一言目で無能呼ばわりするのはどうかと。

>>288
早くうまく書けた奴に次の仕事もやらせるのが一番弊害が少ない
理解や気づきの機会は外から与えることはできるが
それがどう理解や吸収につながるかとなると当人の資質や性向のファクターが大きいすぐる

>>287

> ソフトウェアの良い設計というのは
> 結果的に破綻も漏れも無く抽象化できていればおk

そうだね。ただ、具体的にどんなノウハウを与えれば、>>288の言うスーパーマンを生み出すかってのが次の疑問だろうな。

自分はOOP、TDDあたりのノウハウが身につけば余裕だと思っているが。

OOPは物事を整理する仕組みは提供してくれるが
どう整理をつけるかはやっぱ設計者のセンスに委ねられたままやんけ
実際>>287にゼロベースで的確に答えることは難しい
TDDは設計を検証する仕組みは提供してくれるが以下略

んまーテストケースをいっぱい書くというのは
物事簡潔に済ませる習慣が身につく良い経験かも試練、

>>293

> OOPは物事を整理する仕組みは提供してくれるが
> どう整理をつけるかはやっぱ設計者のセンスに委ねられたままやんけ

その通り。だからこそ、そのセンスを磨かせるためにTDDもセットで紹介してみた。
まず、自分の設計が正しいか妥当性確認する手段も無いと間違ったオブジェクト指向が身に付く恐れがあるからね。

結局のところ、個々のセンスを磨かせないと駄目だが...センスを磨かせる環境を整えるのはリーダーの役割だと思う。
何もない状態でセンスで何とかせよ、よりは改善が期待できるよ。

コンパイラの都合というよりかはcとの互換性とランタイム速度優先のための仕様によるものだろう。
てかむしろもっとコンパイラの都合考えたらもう少しまともな仕様になっとるわ。

スーパーマンはある種の天才で、体系的に天才を教育する方法はないと思う。特に今現在の教育は全体の平均値を上げる事に主眼を置いているから。

大多数がほどほど幸せになる方法としてある程度うまくいってたけど、極少数が全体に絶対的な影響を及ぼすソフトウェアの世界だと効率の悪さが目立ってくるよね。

天才を見つけておいて必要な時に協力してもらうしかないんじゃないかな。全てにおいて天才はいないし来てもくれないので、得意分野では天才的みたいな奴と仲良くしておくぐらいか

体系的に天才を教育する方法
ってのは実は簡単で、C++をやらせればいい

それは教育する方法ではなく
多数の中から天才を見つける方法なのでは？

選ばれても来るかどうかは天才次第

プログラムの才能のある人材を発掘する方法は、以前だとLispかHaskellをやらせるのが定番だったけど今はどうなのかね？

まずクソ企業で天才が居座るメリット無くね？
誰かが頑張ってくれるだろうみたいな雑魚集団と仕事したくねーわ。

>>296
天才とは言っていない
http://equallove-2017.blog.jp/archives/24499215.html
http://equallove-2017.blog.jp/archives/24508935.html
https://star.programming-study.com/
2020年10月17日放送分
TK-80の産みの親？
元マイクロソフトでwindows95の開発に参加？
良く判らんけど
Windows95の生みの親に直撃!開発秘話やプログラミングの裏話、子どもたちに伝えたい思いを告白

>>301
誰かが頑張ってくれるだろうみたいな雑魚がいない企業をおまえさんは知っているの？

残念ながらGAFAでもその種の馬鹿はいる。

君たち C++ の話をしろ

deleteで解放しようとするとたまに落ちるバグがあるのですが
try〜catchで囲っても、やっぱ落ちます。
これって例外で処理することはできないんでしょうか？
それともやばいバグ過ぎてつかまえられないだけなのでしょうか？

投げない例外は捕まえられないのでは？

>>307
これじゃダメなんでしょうか？
すみませんC++よくわかってなくて…

try{
delete p;
}catch(...){
std::cerr << "error!" << std::endl;
}

>>308
pのデストラクタの中で何かが起きていて、そこで例外が投げられないから補足できないのでは？

それと経験的に、再現性の無いバグは、十中八九、未定義の記憶域を読むことで発生する。

丼なスパゲティーコードをメンテしてるか気になる

>>309
デストラクタは何もないので
どこかでメモリ処理がおかしくなってるんでしょうね…
一旦、動くようにしてみたかったのですが、もうちょっと調べてみます。
ありがとうございました。

そういうときに役に立つのがprintfデバッグだろ
どの工程で起こったのかある程度目星がつく

>>321
継承元の親クラスを何個も辿ってよく調べたら
コンストラクタの中で怪しいポインタにアクセスしている個所がありました。
おそらくこれが原因だと思います。
皆さん有難うございました。

デストラクタとdelete演算子はデフォルトでnoexceptなんで、
例外発生時点で異常終了してしまい、try〜catchじゃ捕まえられないそうだ。
https://cpprefjp.github.io/lang/cpp11/noexcept.html

そういう問題じゃねえよ
不定のポインタは検出不能だ

いや、今回の問題の解決のために書いたわけではなくて、
>>308のように書いても無駄だと伝えるために書いた。
そのあたり明示せずに書き込んですまん。

atexit()
exit()
で捕捉出来ないかな

デバッガに頼るのは甘え
プロはprintfだけで正しくデバッグする!

プロは logger 使うし
百歩譲っても使うのは fprintf の方

printfが使える環境ならな
そうでない場面がごまんとあるから
選択肢は多いに越したことはない

シリアルモニタくらいは用意できるだろ

基本的にprintfデバッグの延長
制度化体系化されたprintfデバッグがログ取り

loggerはより高度なprintfデバッグであり、その基本がprintfデバッグになる
この変数を眺めりゃ万事OK　という直感が涵養される

loggerの出力先が10万キロ離れたプリンタなこともある

オシロ使ったりもする

路地穴は使うよね

スペアナくらいは普通使うよね

無線屋さん？

C#を作ったアンダース・ヘルスバーグもデバッガのステップ実行よりもprintfを使うってインタビューで言ってたな

尻穴は使うよね

C++23のdraftが公開されてた
http://wg21.link/n4868

>>329
情報ありがとう

>>300
C のポインタ、特に関数ポインタ、とか
リカーシブ、とかで十分でしょう

尻カーブ？

シッタカブリ

printfデバッグなんてあり得んけどな。

>>334
でも最初のうち、プログラムが小さいうちは、それが一番手っ取り早いですね

printf デバッグは完成後に printf の行を消すと動かなくなったりするω

関数化やクラス化でプログラムを小さくするわけで、あんまり関係ないな
assertを使うときもそうだが、デバッグ用のコードに副作用を入れちまうのはヘボ以下

デバッグOffして弊害残すヤツは動作の仕組み把握出来てないだけだろ
>>336、まず貴様のコーディングセンスを磨いてから出直してこい青二才

非同期で動くブツ同士の通信はprintfデバッグ大活躍なのでは…
誰がいつ何を呼んで何を渡したのかと呼ばれたほうが本当に受け取ったのかがすぐﾜｶﾙ

printf消去忘れについては条件コンパイルを使えば良いし、
Ad-hocな追加ならいかに大量にやってもソースコード管理システムで安全に消すこともできるわけやし、

未定義動作踏んでるときとかにprintfを呼び出すことでたまたま動くようにできたりする
ということか

>本当に受け取ったのかがすぐﾜｶﾙ

buffer flush しないと判らんし
flush すると勝手に改行する環境とかあるし
そこまで便利ってほどでもなくね
nonbuffered しろってか

ここまでの話をまとめると
やはりprintfデバッグが最強、ということですね

#ifdef DEBUG
　#define PUTCHAR(a) (putchar(a), fputc(a, _fpDbg))
#else
　#define PUTCHAR(a) (putchar(a))
#endif
PUTCHAR(*ptr++);
みたいなことをやれば デバッグ時だけ*ptr++ が二回評価されて結果は変わってしまう。

>>343
インライン関数に置き換えられるだろ
少しは頭使え

デバッグ関係ねーじゃん

>>344
そんなことは当たり前。
IQが低い人と話すとこれだから困る。

>>346
わかってるならインラインで書けよ池沼

>>347
駄目な例を敢えて書いたんだ。
どうしてそれが分からないの、あなた達には？
IQが高い人には駄目な例が単なる例として出されたのだと分かるのに
ここの人達にはそれがわからない。

>>339
非同期なアプリでprintf使うとタイミングが変わることがあるから安心できんな
デバッガよりは遥かに良いけど

>>336 が
「printf デバッグは完成後に printf の行を消すと動かなくなったりするω」
と書いていたが、>>340が指摘した理由だけではないので、
そうなる他の理由の1例を>>343で書いた。

これが考える力なんだよ。
マスコミを含めて「知識知識」と言う人が多いが、生まれつきの頭が悪いと
>>344 >>347 のような馬鹿な発想しか出来ないのでどうにもなら無い。
俺に比べれば、おまえが池沼の癖に。

マクロを使う必要性が全く感じられなくてリアリティがない

>>351
おまえ自分のこと頭おかしいと思わないならかなり進んだ病気だな

>>353
精神病院に行け。

C++の話しねえやつは出てけ

C++ラーメン次郎うめえ

>>350
たぶんみんなは
そりゃマクロ使えば何でもありありだろ
そんなことでドヤるとかバカじゃねーの
って思ってる…

>>335
printfデバッグを肯定するとは
ロートルの吹きだまり感かなりある

printfごときで騒いでる方が精神いかれてんだろ。。

今はJTAGがあるので、そんなにお金がかからない。
それでも、プロセッサごとにデバッグ環境を用意できるわけないだろ！！というのが日本企業の現状なら、中韓に任せて野菜でも育てる道が効率よい。
中韓は用意できるし、売り切ることが出来る。
printfデバッグなんてインパール作戦と同じ。
物量が違いすぎる。

お前たちは農民に戻れ。
ハイ解散。

>>360
私のマザーボードの JTAG/IEEE1149.1 はどれですか？

>>362
OS開発の場合は、専用のボードを用いることを視野に入れる。
それが無理なら、中韓に任せて撤退するべし。

#ifdef DEBUG
　#define PUTCHAR(a) do{auto b=a;putchar(b), fputc(b, _fpDbg);}while(0)
#else
　#define PUTCHAR(a) (putchar(a))
#endif
死ねザコw

センズリマクロ

>>364
else節もコピーしろザコw

教師が「こういうやり方はしてはなりません」と言っただけなのに、
生徒「そういう場合は、inline使えよ馬鹿教師」
という馬鹿生徒の集まり。
学級崩壊。

教師が「こういうやり方はしてはなりません」と言っただけなのに、
生徒A「そういう場合は、inline使えよ馬鹿教師」
生徒B「こういうやり方ならいいんだよ、死ねザコw」
教師「」

inline関数や、>>364のやり方が分かった上で教師は言っている。
それとも、おまえらの通った学校の教師はそんなことも分からない
くらい程度が低かったのか？
どこの学校だよ。

ここは教室じゃねぇんだよバカが
とっととキエロ

俺が通った学校の教師か
化学のおじいちゃん先生だったな
当時C++はまだ世に出てなかったから
マクロの使い方は知らなかっただろうな

へー、Cにはマクロないんだ？

>>372
#define マクロはありますが、lisp 様仕様マクロはありません

c++の文句をいって
cの話を延々はじめる
そしてどっちも言い尽くされた話

printfデバッグやってるじじいの特徴

>>372
C++が世に出る前っていつ頃かわかってる？
その頃のCを化学のおじいちゃん先生がやってると思ったの？
おまえさんでさえK&R Cなんか使えるのか？

DxLib は printfDx で printf 推奨ω

>>371 ではC++はまだ世に出てなかったからマクロの使い方は知らなかっただろうと言ってるのに
>>375 では化学のおじいちゃん先生がCなんてやってるわけないだろうと言っている

それではC++が世に出ててもその頃のC++なんておじいちゃん先生はやらなかったのでは。
だとすると >>371 はいったい何が言いたかったのか…

>>377
同一人物なんだが君は何に見えたのかな？？

で、君はK&R Cは使えるのか？

>>379
K&R1 か K&R2 かを指定してください

もちろん1よ
2なんて馬鹿言うわけねえだろ
何が言いたいの？　おまえさんは

>>341
>nonbuffered しろってか
別に
非同期要素同士のハンドシェークがうまく行っているかは
callerとcallerの呼び出し順序に崩れが無いことをメッセージの中身とともに確認できればほぼほぼ十分なので
printf()を呼んでから出力されるまでの時間はあんま拘る意味は無い

非同期な処理を観察するってのは非同期な処理が「失敗しているかもしれない」のを見つけ出さなきゃいけないってことだよね。
複数のスレッドが競合したりする場合もあるってことだよね。
printf は歳入可能でもないし、問題があるときは printf の処理も信用できないと思うんだけど。

信用できないけどバッファに溜まったまま吐き出されないということはなるべくないようにしたいって話でしょ。

printfが再入可能でないってどゆこと？ strtokみたいに状態を持つのか？

スレッドセーフとリエントラントってどう違うの？

単一スレッドでも再帰なんかで再入は発生しうる
関数内でクリティカルセクションなどを使ってスレッド同期するようにしていても状態を持つ作りだと同一スレッドからの再入で異常になることはある

Cランタイムは通常スレッドセーフだよね
だから複数スレッドでprintfを読んだりerrnoを参照してもよい
Windowsの場合、_beginthreadで作成したスレッドはCランタイム安全、CreateThreadで作成したスレッドはCランタイム安全ではないとかいう話もあった

>>385
今、リエントラント(再入可能)という言葉は余り聞かなくなっているが、
ハードウェアに密着したプログラムを書くときに、ハードウェア割り込みの
割り込みルーチンがまだ終わってないタイミングで、同じ割り込みが生じ、
同じルーチンが再帰的に呼び出されることがあり、そのような呼び出しに
対応しているものを「リエントラント」と呼ぶことがあった。
ただし、そのようなプログラムは複雑になりがちなので、ハードウェア
割り込みが生じ、割り込みルーチンがまだ終わってないタイミングで、
同じ割り込みを発生させる原因がもう一度発生しても、割り込みルーチン自体を
呼び出さないようにする手法が使われることが多かった、というか、
その様にプログラムすることが標準とされ、そのためにプログラマブル割り込み
コントローラなるものが、その役割を果たすモードを持っており、それが通常、
有効な状態にされていた。

>>388
一方、単一スレッドプログラムの場合、mallocの中からmallocが再帰的に呼び出される
ことはそもそもない。printfも同様。
なので、複数スレッドが動作している場合でも、各スレッドにおいては、
mallocやprintfが再帰的に呼び出されることはない。
そして、mallocを作る場合、Heapに関する重要データを読み書きする時、クリティカルセクション
のようなもので囲って、1つのスレッドだけが読み書きできるようにするような手法が使われる。
この場合、その区間を実行しているのは、最大で1スレッドのみであり、複数スレッドが
同時に実行することはない。
もちろん、malloc自体は同時に複数のスレッドが呼び出しても良いが、malloc内部で重要データ
の読み書きが行なわれるのは、必ず1スレッドのみで、それ以外のスレッドは待機させられる。

割り込みハンドラをリエントラントにする場合には、このようなクリティカルセクション的な
やり方は絶対に使えない。
まず、割り込みハンドラは、実際に実行しているのは1スレッドと言えば1スレッド。
割り込み自体が、1コアしかなかったZ80などにおいても有った概念でもあるし、それは当然であるが。

おじいちゃん
スレタイ読もうか

coutデバッグと言うべきってか

>>388
多重割り込みの話と勘違いしてねーか？
同一割り込みなんて起きなくてもメインルーチンで使ってる関数を割り込みルーチンで使う可能性があるならリエントラントでないとおかしくなるよ
そもそもシングルスレッドで割り込み使ってなくてもある関数内で直接的もしくは間接的に自分自身が呼ばれる場合もリエントラントでないとおかしくなる
最近の言語だとグローバル変数とか静的変数使ってなきゃ（例外はあると思うが）リエントラントになるのであまりに気にする必要はなくなった

ちゅうことはスレッドセーフなloggerが全部同じファイルにログを書き込むんだろ
これもうそのまんま出力に逐一印字させた方がいいんじゃね

>>391
いや、厳密にはstd::coutデバッグというべき（ドヤ

printf()はスレッドセーフ
複数スレッドから呼べる
規格のどこに書いてあるかは示せないが探せばあるはず
なぜなら、ファイルI/Oやからなあれ

もちろんこれは、printf(("ABC")とprintf("CDE")をそれぞれ別スレッドで呼んだ場合、
ABC、CDEという表示になるという保障にはならないが
実際にはたいていのケースで行単位で分かれてくれるからデバッグには困らない
行が頻繁に混じってしまってデバッグにならないようなら初めて行単位の排他の追加を検討する
みたいな

ただしもちろん割り込みルーチンからprintf()を呼ぼうとするような猛者は知らん
火の粉がこっちに降りかからない限り
放っておいて差し上げなさい

保障にはならないが〜
実際にはたいていのケースで〜

こういうの一番困る

printf使ってヘンになってるならまだ許せるが自前のクソloggerが全般的にクソ動作してると排除したくなる

非同期シグナル安全な関数のリストにprintfがない・・・
https://docs.oracle.com/cd/E19683-01/816-3976/gen-26/index.html

自前でロックすりゃいいだろ

printf実行中に割り込みが発生して、なおかつそのhandlerでprintf使ってると
デッドロックが発生する（？）
※printfは内部でmallocを使ってるので、>>389に書いてあるようにheapの
操作時にロックを取得しようとするため
という感じかな？

なら自前のprintf作ればいいだろ
標準に頼りきるバカが

>>402
＞自前のprintf作ればいい
こういう台詞は、その能力の欠けたものが得てして言いがちなことだよなあ‥‥と

己の道は己で切り開くものだ
貴様らジャップどもは文句たらたらと言ってるだけで行動に移そうとはしない
猿に退化する課程の獸だな

>>404
ワイらがジャップだとしたら
お前はいったい何なんだよ

>>404
無関係な問題まで何でもかんでも民族や国籍に結びつけて的外れな非難をしようとするとは、怒りに囚われて論理的思考力が壊滅的にダメージを受けてるんだろう。プログラマとしては致命的だなw

割り込みルーチンの中からprintfを読んだら危険なのは
一般にOS機能のうちクリティカルセクション（ロック）みたいな高級な機能が
ユーザーが勝手に定義した割り込みルーチンのコンテキストでは使えないからじゃわ；

OSはOSで割り込みを受けてスレッドのコンテキストを管理しているので、
それとは非同期に起きたOSのあずかり知らない割り込みで
OSの高級な機能が呼ばれたらOSの管理情報の排他が崩れる

割り込みルーチンから呼んでも安全なprintf()を自力で実装するとしたら
メインのOSとコードベースをまったく異にする必要があるのでOSの自力実装に近くなってくる
やっぱ割り込みルーチンからはprintf()呼ばないというのが一番スマート

聞くんじゃなかった
printf( → fprintf(stdout,
みたいなもんでstdoutが静的記憶域期間とか
そういう説明が聞けるのかと思いきや
なんだこりゃ・・・

stdoutが静的記憶だとして（大概のOSではIOBで管理しておりそうなっているはずだが
printf()をユーザー定義な割り込みルーチンから呼ぶと
それの排他を安全に行える人がだれも居なくなる、

printfデバッグでダメならputデバッグでいいじゃん

printfごときでいちいちケチつけやがって陰気なヤロウどもだぜ

こいつらは屁理屈言いたいだけでデバッグする気なんて少しもない。

お金払われればやるよ

金もらわないとデバッグしないの？
つまらない人生だね

そんなに楽しい事ならお前がやれば？

やらないならクソみたいなこと言ってないで黙ってりゃいいのに

普通は成果物に対して報酬を得るよね
バグを出したら潰すのは当たり前

お金払わなきゃデバッグしないとか言ってる人は客先常駐のような労働時間に対して賃金を得る労務提供型なんだろうか
労働者から脱却しないとソフトウェア開発の本当の楽しさを知ることはできない

1レスの中で矛盾していくスタイル嫌いじゃない

成果に対して報酬があるならお金のためにバグ潰す

時間給なら貰えるお金は変わらないから「バグ潰すのは当たり前」と洗脳したり脅したりしないとバグは潰されない

いや、いるんだよ
他人が書いたコードを有料で引き継ぐ人
414がそうとは見えないけどね

つーか普通に仕事してたらちょいちょい
前任者が逃げた、とか潰れた、とか逮捕された、とかで
クソみたいなゴミクソウンコのコードをわたされて
これ保守してねー、みたいなクソみたいな仕事
おしつけられることなんてまれによくあることだろ
そんでなぜかそいつのクソゴミコードのバグを
まるでおれが出したかのように責められる、までがセット

ここってサラリーマンが多いのね

そんなん公然と拒否するか
0から作り直すかの二択だろ

>>421
そういう状況はママあるけど
> お金払われればやるよ
って言う状況とは違うだろ

>>421
担当を引き受けたのなら、過去の潜在バグであってもお前の責務だろ

>>423
こういう人間はソフトウェアなんかやらんでコンビニバイトでもやってた方が向いてるよ。

C++でもPythonの内包表記みたいにVectorの要素舐めていって
全ての要素に特定の処理をしたものを別のVectorに代入することってできますか？

まずPython処理系を書きます

内包表記に近いことは無理じゃない？
initialize listでもしかして？って思ったけどうまくできそうにない

つtransform & lambda

std::transform(s.begin(), s.end(), t.begin(), [](int e) -> int { return e * 2 });

きっとforのほうが読みやすくて速いと思う

あとはvalarrayとかな

表現上はあたかもラムダ式使った華麗なことやってるように見えるけど
マジでそう見えてるだけで、コンパイルするとfor文とそんなに変わらなくなるんじゃね

むしろどっかの時点でただのfor文に置き代わったりしてるんじゃないの

インタープリターよりは速いよ

https://cpprefjp.github.io/reference/tuple/apply.html

https://www.fluentcpp.com/2020/02/07/transform-adaptor-equivalent-in-cpp/

>>433
ループ分解されて要素分コード増えてる可能性もあるな

forよりも関数的に書いた方が順序は気にせんでいいってメッセージを込めることはできるわけだが、
まあそういう風にかける場合って大抵forで書いても可読性下がらんほど簡易な内容のことが多い。

ﾋｴｯ…、、OpenMPし放題…！

競プロで使いたいのですが
if i = 0 then return 0
elif i > 0 then return i - 1
を出来るだけ早く求めるには何かいい方法ありますかね？
ビット演算とかでなんとかなりませんかね？

>>440
それの速度が競プロで問題になることなんてないだろう。
そんなこと気にするよりアルゴリズムの計算量のオーダーを小さくするとか枝刈りをしっかりするとか有意義な方に頭を使った方がいい。

unsignedですか？

simdの比較使えば結果がビットマスクで取得できるのでそれを使うのが定石
両方計算してビット演算で選択
c++関係ない

>>440
数値のビット数が解っているなら高速化できる

>>440
ていうか比較は一回でいいだろコレ
なんで2回も余計に比較してんだ？
return i>1?i-1:0;

>>440
ていうか比較は一回でいいだろコレ
なんで2回も余計に比較してんだ？
ちょっと間違えた
return i>0?i-1:0;

>>440
elifのあとはなにを返すんだや？
モロに中途半端やないかいワレ

つか>>440はelseが何かわからんが、
iがi≧0でやってくるのならデクリメントの飽和演算に見える件について：

SIMD使うと飽和演算は楽勝かもしれんが、4個とか同時に並列に計算するんでなければ
かえって遅いんじゃ…

>>440
アセンブラだったら、
　sub eax,1
　jnb lab1
　xor eax,eax
lab1:
　ret
でおしまい。最大で4クロック。
jmp命令は1つだけ。同じことをCで書くなら、
if (--i < 0) {
　i = 0;
}
return i;
とか。

クロック数は蛇足でしょ

減算が必ず実行されるのはもったいない

... and eax,eax
... jz f＠
... dec eax
＠＠:
... ret

test ってあったかな...

and eax,eaxも同じようなものなのでは…
どっちも多分パイプライン1段消費

ていうか投機的実行から戻す際のペナルティーは
常にデクリメントする>450の方が小さい可能性が微ﾚ存
知らんけど

そっかー
投機的実行はまったく念頭にありませんでした
i が 0 である確率が小さいと考えるのかしら

sub eax,1
adc eax,0
でなんとかなんないの？

>>450
一瞬でも < 0 になったらまずい環境なら
if(--i < 0) はダメ

>>452
減算を行う場合の方が頻度が高いと予想されるので、>>450の方がその場合に
命令数が少なくなるので平均速度は速い。

>>456
そのコードは凄い。

>>456
キャリーちゃんか

Macで環境構築どうすればいいですか
適当に記事あさればいいですか

yes

>>461
新し目のC++使うならhomebrewでg++-9でも入れるのがベターかも。
たとえばstd::filesystemとかcatalinaのXCode(clang++)でも対応したんだが、
バイナリを古いmacに持ってったら予想通り動かんかった。

自クラスの終了時のコールバックメソッドで…delete this;すると…うまく消えるんだけど…。
コールバックメソッドは…boolを返す…delete this;した後も…メソッドは動き続けて…るんだよ…。
std::coutも反応してる…メインスレッドとかで…処理されているからですか？何故かが…解らない…。

464です…。いろいろ調べたら…できるみたいですが…なんでできるのかは…解りません…。

thisインスタンスに影響しない関数のコードは多分、C言語の関数みたいに生成される。
関数のコードは不変な実体だと思う。

難しく考えすぎ
extern "C" void the_call_back(struct obj_ptr* This)
{
free(This);
}
こうなってるだけだよ
*Thisを殺しても関数から戻るためのスタック情報はどうもせんだろ

ダメ

主要3コンパイラでコンパイル出来るうえ
https://python5.com/q/djlpoyyw
紹介してる人が居る。

駄目な根拠わかりませんか？

>>468
https://timsong-cpp.github.io/cppwp/n4659/res.on.functions#2
> In particular, the effects are undefined in the following cases:
> ...
> - if an incomplete type is used as a template argument when instantiating a template component, unless specifically allowed for that component.

C++17以降、std::vectorは不完全型を許容していて、std::variantは
using V1 = std::variant<S1>;
の時点でインスタン化されていない。

これはどう解釈すればいいのかな？

これが合法なら良かったんだけど、どうも無理っぽいな。

using V1 = std::variant<S1>;
の時点では、テンプレートの明示的なインスタンス化はしていないし、使用していないので暗黙的なインスタンス化もされていない。

ってことでいいよね？

boost::make_recursive_variantやstd::anyを知らないわけじゃないんだけど、オブジェクトが必要になるたびにnewするならC#やJavaで十分なわけで、C++のうまみ成分はこういうところにあると思うんですよね。
何とかなりませんかね？

>>463
ありがとうございます。
Mojaveあたりです。

コンストラクタの引数と初期化リスト上のメンバー変数が同じ名前でも、ビルドが通って意図どおりに動いちゃうのだけど、これって仕様通りの動作？

こんなん
: apple(apple)

>>478
仕様通り。 問題ないし、むしろ名前を一致させるスタイルを好む人もいる。

Foo::Foo(const Fruit& apple)
: apple(apple),
　banana(apple),
　orange(this.apple) // できない
{

}
が問題無いのか左様か、

いや待てFoo::appleが実はFruitクラスでなくてFruit2クラスで、
orangeにFruit2クラスを受け取るコンストラクタしか持たずかつconstメンバだったらどうすんじゃ…
…

Foo::apple、Foo::banana、Foo::orangeではなくて
Foo::m_apple、Foo::m_banana、Foo::m_orangeとしておけば悩む必要は無い
ヘッダファイルでもこの順で宣言したとして、

Foo::Foo(const Fruit& apple)
: m_apple(apple),
　m_banana(apple),
　m_orange(m_apple) // できる
{

}
でおk

>>480
普通に出来るやで。 this->apple の間違いじゃろ。

メンバの初期化順は (初期化リストの順序と関係なく) クラス定義内でデータメンバを書いた順序なので気を付けてな。

this
javascriptのやりすぎで脳が壊れたか

>>481
名前を同じにしてもうたらまずいケースがあるやないけということを >>480 は言ってるので、
名前変えればいいよってのは的外れ。

>orange(this->apple)
ﾎﾝﾏやΣ(ﾟдﾟ；)！いけたわ、
警告をいつもエラー扱いにしているからてっきりエラーかとｵﾓﾃﾀ、（言い訳

みなさまthx
classのときはメンバ変数に何らかのprefixなりsuffixなり付けてるから名前が被ることはなかったのだけど、構造体は何も付けないことが多くて、あれ、これってＯＫなんだっけ、って今更ながら気になってしまいました。
メンバ定義順に初期化ってのも知らんかった…

>>485
いや、エラーだろ

warning C4355: 'this' : ベース メンバー初期化子リストで使用されました。
やもーん

みんなC++でなにしてるの

polymorphic_allocator対応ですね。

>>489
c++仕様のお勉強。マウントかますためだけにお勉強。

ジョークに聞こえるがまじでそういうやつがいるからな

>>485
念のため規格の当該箇所を探してみたら this についてわざわざ脚注で書いてあったわ。
https://timsong-cpp.github.io/cppwp/n3337/class.base.init#12
初期化順序はくれぐれも気を付けんとあかんけど、this が駄目ということはないのは間違いない。

おせーな。
5分で探して来い。