C++相談室 part138

**デフォルトの名無しさん** (ｽﾌｯ Sd9f-fGne) · 2018/08/05(日) 18:02:36.57

次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part137
http://mevius.5ch.net/test/read.cgi/tech/1531558382/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.103【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1530384293/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

VIPQ2_EXTDAT: default:vvvvv:1000:512:----: EXT was configured

2019/10/23(水) 09:43:48.31

スレッドローカルって手はある
この場合に適するかどうかはさておき

2019/10/23(水) 10:10:24.12

よく読んでないけど無名名前空間はどう？

2019/10/23(水) 15:15:00.59

>>779
いくつか方法があるが、そのような目的では通常、namespace は使ってはいけない。

方法1：それらの関数を、あるクラスのメンバ関数にする。受け渡しのデータの型は、
　　　　関数宣言などの「インターフェース」には影響しなくできる。

方法2: struct TInfo {・・・}; というような構造体を宣言し、その中に、見せたくないデータを入れておき、
　　　 void a( TInfo *pInfo ); void b( TInfo *pInfo ); とする。TInfo は、

struct TInfo {
　DWORD　m_type;　// 種類を区別する何らかの数値。
　union {
　　TYPE1　m_dat1;
　　TYPE2　m_dat2;
　　TYPE3　m_dat3;
　}
};
のようにして、m_type の値に応じて、union 型のどのデータを使うかを場合分けする。
TYPE1, ・・・, TYPE3 は、通常、何らかの struct 型にし、好きなデータをそこに入れる。

2019/10/23(水) 15:21:42.82

>>782
方法3: TInfo を直接使わずに、struct TBase {・・・} としておき、
void a( TBase *pInfo ); void b( TBase *pInfo ); とし、
struct TInfo1 : public TBase {・・・};
struct TInfo2 : public TBase {・・・};
struct TInfo3 : public TBase {・・・};
とする。やりたいことに応じて、TInfo1～TInfo3の好きなものを使う。
なお、方法1は、説明不足だったが、こうする：
class CBase {
public :
　void a();
　void b();
};
class CDerive1 : public CBase {
protected :
　TYPE1　m_type1;　　// 好きなだけの個数のメンバを書いても良い。
public :
　void a();
　void b();
};
class CDerive2 : public CBase {
protected :
　TYPE2　m_type2;　　// 好きなだけの個数のメンバを書いても良い。
public :
　void a();
　void b();
};

2019/10/23(水) 15:25:02.62

>>782
インターフェースを変えられない（＝呼び出し側を変更できない）んだから両方駄目だろ

2019/10/23(水) 15:29:33.08

>>784
関数、a, b のインターフェースは変わってない。

2019/10/23(水) 15:33:22.30

>>785
a, bをクラスに入れたら呼び出し方法が変わる
インターフェースを変えてはいけないのに呼び出し方法を変えても構わないというのはおかしい

2019/10/23(水) 15:41:37.49

質問者がa(), b()以外から変数testが書き換えられる可能性を危惧しているのなら、
privateにコンストラクタとtestを持ち、a()とb()をfriend関数として持つクラスを作ればいい

class testClass
｛
testClass();
static inline int test = 0;
friend void a();
friend void b();
｝

2019/10/23(水) 15:42:25.23

そういう話であれば、そもそも最初の質問の意味が分からない。
何がしたいのかが。

2019/10/23(水) 16:23:48.30

32bitでコンパイルされたdllを64bitのプログラムから使用する方法ありますか？

**蟻人間** ◆T6xkBnTXz7B0 (ｽﾌｯ Sd32-1lfc) · 2019/10/23(水) 16:32:16.25

>>789
それらのDLLを読み込む32-bitのexeをShellExecuteで呼び出す。

2019/10/23(水) 16:59:49.87

実はレジストリも違う場所に描き込まれるよね

2019/10/23(水) 21:06:09.31

>>788
何をしたいのかは明らかだろ
メンバ関数にしてインタフェース変わってないとかお前の方が意味不明な

2019/10/25(金) 00:11:30.11

>>755
追加の宣言を促す気なら、お前がまず何か宣言するべきだ。
これは俺に文句を言っているその他全員もだ。
俺はもう既に宣言済みで、それをこれまで守っているのだから。

単なる質問なら、それはそういう言葉で行うべきではない。
おまえら「ゆとり」はクズだからネット上ではいくらでも挑発していいと思っているようだが、それも間違いだ。
俺は勝手に宣言して勝手に守っているだけであって、お前らクズ「ゆとり」に禁をかけられているわけではない。
また、今尋ねることも適切ではない。
このスレを使い切るのに後何年かかるか分からないのだから。
（本来はあと2年ほどかかる予定だったし、今お前らが黙れば後1年は持つと思うぜ。実際俺が放置したら停止したろ）

そもそもお前がそれを心配するのなら、お前が今為すべき事はここに何も書き込まないことだ。
それは>>725もそうだが、どうにもお前ら「ゆとり」はクズ過ぎて駄目だ。
>>733,751とこの馬鹿自身が書き込むことによって、725を自ら無効化してしまっている。
結果、一番無駄なレスは725だ。
725は結局、自分に都合の悪いレスを止めて欲しいだけで、自分は文句を言いたい放題という、
いつも通りのパヨク的ダブスタに過ぎない。
他人に口をつぐむように指図するなら、その本人は最低限それを守るべきだ。
韓国人はこの辺の筋が通じないから駄目であり、結果、韓国人が居るだけで荒れる。
だから韓国人の存在自体がコミュニティにとって害だ、ということになる。
これが妥当か勘違いかを、フォークで決着付けてやる、ということだ。

いい加減、お前らがおもしろがっていたこと(>>705)を大迷惑だと思っていた連中も多いと気づけ。
だから「ゆとり」は殺さないといけない。
とは言っても物理的に殺すわけにも行かないので、ネット上でフォークして勝負だ。

2019/10/25(金) 00:12:13.53

ちなみにお前ら、「殺人」が何故いけないのか考えたことがあるか？
俺はそれは「取り返しがつかないから」だと考えている。
逆に言えば、ネット上の殺人(＝BAN)は取り返しが付くのだから全く躊躇する必要がないとも考えている。
そして俺が「韓国人だから」という理由でBANを発行したとして、それに抗議するのは、
パヨクのように「人権ガー」「差別ガー」ではなく、
「韓国人が居ることによってより上手く回る」掲示板を運営し、そこを繁盛させることにより、
「韓国人だから」みたいな『ふざけた』理由でBANを発行する掲示板を過疎らせて殺すことによって行うべきだ。
実際、これは理論的には可能だ。多様性自体は上手く使えれば確かに善だ。
ただ、それには相応のコストが必要で、まずは最低限、悪事を「差別ダー」と言い逃れするクズ共をたたき出す必要がある。
そしてその先にも有形無形の様々なコストが必要で、今の日本のお花畑達はまるでこれが分かってない。
アメリカは確かに移民の恩恵を受けているが、それがタダだと思うのは完全に間違いだ。

ただ、本当にここら辺のことをふまえた上で実行され、それが機能するのなら、俺が運営する掲示板は滅ぼされることになる。
その時は、役割を終えた、ということでいい。
「韓国人」は死ね、というのが気に入らないのなら、やってみればいい。
俺が掲示板を用意するのにはあと数年かかる。
それ以前にお前らが機能させられれば、最初から俺の掲示板なんてゴミであり誰も見向きもしない。
お前らにこれが出来ればお前らの完全勝利だ。やってみろ。

2019/10/25(金) 00:12:43.85

ちなみにお前らがこういう考えに至らず、文句を言って相手を潰そうとするのは、お前ら自身が共産主義的だからだ。
資本主義的なら、相手を凌駕することにより相手を滅ぼすのが正しい戦い方だ。
「差別ダー」と政治的に喚き散らし、お取りつぶしを願うことではない。
結果、共産主義では「指導者が正しいと認めた物」しか出てこないから発展せず、
資本主義はどんどん「相手を凌駕した物」が出てきて社会もその恩恵を受けられるからじりじりと前進していく。
これが共産主義が滅んだ最大の理由だ。最初から最終的に勝てるフォーマットではなかったんだよ。

だから、俺の見解を「差別ダー」と思うのなら、
「差別のない掲示板」をお前自身が運営して「差別のある」掲示板を滅ぼすことだ。
ただ、俺はお花畑なお前らにはそれは出来ないと見ている。
誰であれ「荒らし」であればBANしていく、という方針がもっとも差別がないと俺は思うが、お前らはそうではないようだし。

2019/10/25(金) 00:13:44.69

ところで「向いている/向いていない」について良いスレを見つけた。
俺の文は読めないというのなら、以下でも読んでみてはどうか。
内容はまあまあだと思う。
（以下2つは同じ物）
http://boards.4channel.org/g/thread/73285994
https://archive.rebeccablacktech.com/g/thread/73285994/

2019/10/25(金) 07:31:59.25

> パヨクのように「人権ガー」「差別ガー」

ブサヨが難癖つけるときのボキャ貧ワードだろうが
てめえらがしたことを他人に擦り付けるいつものワンパターンまたやってやがる
マジ氏ねよ腐れアカ

2019/10/25(金) 12:40:25.22

>>793-796
3行にまとめてくれたまえ。

2019/10/26(土) 01:08:41.16

>>511
>classのかわりにstructと書いたらむしろ1文字多いのだが
structのかわりにclassと書いたら1文字減るじゃん？

2019/10/26(土) 01:11:52.48

>>583
問題ある
シングルトンの中身がわかったらﾜｶﾙ

2019/10/26(土) 01:13:46.84

>>600
ジャヴァで動かないわけではない
安全にならないだけ

2019/10/26(土) 14:17:06.84

訂正
バカ正直にsynchronizedしたシングルトンはジャヴァでも安全に動く
安全にならないのはdouble-checked lockingした場合

2019/11/07(木) 17:16:16.48

現状のアーキテクチャはそもそものラムダ計算つまり再帰とはもっとも相性が悪い
スタックマシンや有限メモリでは関数型の再現は無理がある
そこをだましだまし使っているだけで、本当はとっても相性が悪い

2019/11/12(火) 21:57:17.55

>>803
お前の頭はプログラミングとはもっとも相性が悪い
文系脳には無理がある
そこをだましだまし使っているだけで、本当はとっても相性が悪い

quoraにもあったわ(なお日本語版にはいいのがなかった)
https://www.quora.com/Is-it-true-that-programming-is-not-for-everyone
内容は>>796と同じだけど、つまりは同じ事を実感している人が多い事実は認識した方がいい
努力以前に適性の問題が大きい
プログラミングは無理してやるようなことではないし、今現在のC/C++はプロ以外が使う意味はない

新人みたいに絶対的に知識/修練時間が足りていないのならばさておき、
そうではなく、十分な練度のベテランのつもりで、
今現在のソフトウェア界隈の動きが全く理解不能なのであれば、
それはお前は全く向いてないことを意味する
多くの人がよってたかって改善しようとしている状況で、訳の分からない方向に行くことはほぼ無い
それはこれまでも、また、これからも、同じだ

2019/11/13(水) 23:02:32.05

適正が有る無しは何処の分野でも同じ
今はソフトウェアが多く求められているのに
それを充足できていない事が問題
それなのに適正がー
とか言ってては何の解決にもならない
ライト層からヘビー層まで色々必要なんだから
別に適正がなくても訓練が出来ていればその人たちにライト系を作ってもらえば良い
今はどうやってソフトウェアの生産を増やすか?
その為の基礎教育や教科手順何かが求められている
問題はそういう教科書的な物で良い物が無い事だ
上に有る様な質問が出ても照会する本もたいして無く
ただ色々やってみろ
みたいな話にしかならない
努力と根性みたいな話しか出てこない
下層が弱くて薄い
それを強化しないといけないという問題認識が無さ過ぎる
まぁc++はライト層とは別分野だと思うけど
何の対策も提案も無く排除ばかりしようとするのは社会的に問題有りだ

2019/11/13(水) 23:50:19.63

>>805
ならお前がまず解決策を出せよ
お前には出来ないと思うが

お前は英語も出来ないということは分かった
quoraのトップの意見に全くそれについて書いてあるだろうに
文系の馬鹿共にどれだけ高校物理を教えても時間の無駄にしかなってないのは今でも事実だろ
プログラミングはおそらくもっと酷いことになる
お前こそ精神論過ぎる

2019/11/13(水) 23:50:47.34

ただ、俺はお前の言う問題は認識してないがな
俺は「無能はプログラミングすべきではない」と考えているし、義務教育化にも反対だ
そして排除自体はこのスレおよび話し相手としてだ
つまり俺の前から消えろ、でしかない
当たり前だが俺はお前ら馬鹿がプログラミングするのを止めることは出来ない
ただ、アドバイスするなら、お前らにも適性がある分野があるはずだから、そこを目指せ、となる
文系なのにSEなんかにされているのなら、
お前も、また、お前みたいな馬鹿と一緒にやらされる周りも、被害者だよ

プログラミングについても、以下は当てはまると思うぜ
一撃必殺！急にマンガ家だの声優だの絵師だのになりたいと言い出した子どもや大人を止める、オススメの方法
https://togetter.com/li/1130025
家庭にPCが当たり前にあり、個人レベルでスマホを持っていて、高性能なIDEも無料で手に入り、
ググればいくらでもサンプルコードが出てくる今、
自分で開始/対処出来てない時点で適性がないんだよ
才能さえ有れば、努力さえすれば、と思っている馬鹿が多すぎる
それなりに才能有るやつが努力し続けることを強制される世界なのだから、
努力を続けられる「適性」が最も重要で、それがないと根本的に無理なんだよ

というわけで話は終わりでいいか？
お互いこれ以上得る物はないと思うし
反論なら、quoraや4chanの意見を確実に読んだと分かるように書いてくれ
俺はお前と話すのは無駄だと認識したから、お前の意見については無視したい
ただ、お前が4chanやquoraの『大勢の』意見について賛同する部分があるのなら、
それが分かるように明記してくれれば、必要有れば反論することにする
俺は既に言った通り、4chanやquoraの『大勢の』意見には賛同している
だからまあ、可能で有れば、俺に反論する必要もなく、
お前が勝手に4chanやquoraに行って叩かれてくれるのが一番助かるが

2019/12/14(土) 00:08:53.58

糞使えなかった do-while 文だが、最近使えそうなところに遭遇した。
が、結局スコープの問題で使えなかった。コード構成は以下と同じ。

do {
Type value(GetCurrentValue());
Process(value);
} while (condition(value));
// https://stackoverflow.com/questions/13297243/why-is-whiles-condition-outside-the-do-while-scope

ここで上記の筆者も言っているが、do-whileのスコープって使えないよな？（設計としてよくない）
そこで他言語でこのスコープが直っている物を知らないか？
最有力としてはC#だが、試したが駄目だった。
（スコープはCと同様、そしてdo-while自体がレア　https://ufcpp.net/blog/2016/12/tipsdowhile/ )
Rustは do-while ループを廃止したらしい。Goはwhile文自体を廃止している。

言語設計としての一貫性は重要として、
for文がスコープを拡張しているのに、do-whileがスコープを拡張してないのは間違いのように思う。
というか、do-whileが使えないのってこのスコープ設計が間違っているからであり、
正しくスコープが拡張されていれば有効性はあったように思うが、どうか？
while (true) { if ... break;} より1行短く書けるメリットもあるが、
それ自体ではなくく、その形式のループを全部do-whileにすることにより可読性が上がる。
違う言い方をすれば、 while ループでの頻出形式を for に纏めたのと同じく、
必ず一度は実行し最後に break する形式の while ループを全て do-while にすることにより識別しやすくなる。

もっとも、JaveScriptに慣れた状況だと、最早ブロックスコープイラネとも思えてきたが。
ブロックスコープだとどうしてもこういう状況等で宣言型（変数の宣言と同時に常に初期値を代入し、必要なければ再代入をしない）で書けない。
関数スコープの問題は関数を小さくすることによりほぼ回避出来るので。
(JavaScriptは全ての関数がクロージャを持つので、C言語でのループは常に関数内関数としてそのまま切り出せる）

2019/12/14(土) 00:51:38.10

do-whileマクロで必須だろ

2019/12/14(土) 01:02:13.83

使えないなら使わなければいい
すべてを使う必要もなければ、すべての仕様が有用である必要もない
C++にはC言語への後方互換性のためだけに残しているものは多い

2019/12/14(土) 06:19:13.04

ループの先頭から入って
ループの後ろで条件判断するコードが
動作的に一番無駄が少ない

だから do while が存在する

コンパイラの最適化も糞でCPUも遅くメモリも少ない時代に出来た言語

1回以上通る事がわかっているループは
do whilw の方が良い
コンパイラが1回以上通る事がわからないと
無駄なジャンプ命令が増えるので

2019/12/14(土) 06:22:59.24

do (int i = 0){

} while (i < size);

こんな書き方が出来れば良かった

2019/12/14(土) 06:29:27.00

読みやすいfor文がええわ。

2019/12/14(土) 06:35:32.14

読みやすさよりも1バイトでも短く
1サイクルでも速く

な時代の話

2019/12/14(土) 06:46:30.22

for (int i = 0 ; ; ){

if (i < size) continue;
break;
}

う～ん...

2019/12/14(土) 08:14:01.65

>>821
見やすさなら従来通りの do-while がいい。問題はスコープなだけで。

do {
bool flag = ...
} while (flag);

頭でflagを確定させられる場合は、これはいわゆる従来記法

while ((line = sr->Readline())!=nullptr) {
...
}

とほぼ等価になる。が、（本来の）今風なのは上側の do-while だと思う。
なおfor文で do-while はGoがやっていて、

for (bool flag=true; flag; flag = update_flag()) {

}

の構成らしい。ただこれは見る限り駄目だろ。

ただし確かに実行コードとしては、頭の条件判定が抜けるだけでしかない。
以下を見れば一瞬で「絶対に一度は入る」とは分かるから、
コンパイラが最適化してくれるのなら、行数が１行増えること以外には問題はない。
が、俺はこの１行にもこだわりたいんだが。

while (1) {
...
if (condition) break;
}

2019/12/14(土) 08:16:23.01

while (1) が見やすいよ。
かっこよさはさておき。

2019/12/14(土) 08:46:39.98

>>817
現実的には俺もそうしている。

ただ、最近は、「こう書ければな」と考えながら書くのが重要なのだと思うようになった。
少なくとも、DI(Dependency Injection)とかの問題は自然と回避出来る。
そこでコードを見てて、ふと思ったわけだ。
この if 文、do-whileのスコープが正しければ削除出来るよなと。

ただ、他言語も特に対応していない状況であれば、今現在は
コンパイラに任せて、ユーザーはど定番の記述を書け、ということなのだろう。

2019/12/14(土) 09:28:57.52

>>816
その、｢スコープの問題｣が大きいの
見やすさが大きく影響するので

2019/12/14(土) 09:33:02.46

>>811と同じ理由で

while (1){
}
よりも

do {
} while (1);
のほうが良いバイナリになる事がある

糞コンパイラの場合

2019/12/14(土) 09:48:01.39

最近のコンパイラは最適化を指示するまでは
いらんことしなくなってきてるね

2019/12/14(土) 10:33:51.54

ステップ実行出来ないと困るから

2019/12/14(土) 11:14:39.14

>>819
結局お前の意見は何なんだ？

俺の意見は、「do-whileはforと同様にスコープを{}の外まで拡張すべきだった」というものだ。
つまり、再記するが以下の書き方が出来るのが『正しい言語』と考える。

do {
bool flag = ...
} while (flag);

現行のC言語では、for文以外はスコープを {} 内に物理的に配置したものに限定しており、
for文だけ例外的に ()までスコープを拡張している。
C++17でif文とswitch文も拡張された。
https://cpprefjp.github.io/lang/cpp17/selection_statements_with_initializer.html
なら何故 do-while もそうしなかったのか？という話だ。
俺はC++23に期待するが。

2019/12/14(土) 11:16:05.17

do-while使ってる人が少ないからじゃね

2019/12/14(土) 11:20:25.69

>>823
期待するけど提案するつもりは無いのでしょう？
そんなことを思いつく人は一人ではないだろうけど実際に提案はされないから、そんなことは起こらないんだよ。

2019/12/14(土) 12:12:20.14

提案は>>812に書いたけど

2019/12/14(土) 12:13:21.43

それを今の文法で書くと
>>815になる

2019/12/14(土) 12:23:18.39

別に頻繁に使うこともないんで
そう書きゃ良いだけなんだけど

2019/12/14(土) 12:29:39.35

そこでマクロ定義ですよ。

2019/12/14(土) 12:40:35.62

>>824,825
なるほど、提案しろと言うのはごもっともだ。
しかし俺は仕様を提案するほどには仕様に詳しくないからパスだな。
そして確かに同様の人が多いというのは認める。

>>829
それは俺も以前考えた。
Cのマクロはそこでしかパース出来ないので、前に出す事が出来ず、限界がある。
（例えばdo-whileブロック内のflag宣言をwhileよりも前に出すことができない）
そしてそれでも無理矢理やるならいっそのことPython等での自前パーサを先に通すほうがまし、という結論に達した。
そして一部それを既にやっている。
(俺は使ってないが）何だかんだでmakefileが融通が利くのはこういう点でもある。
そして自前パーサで全く別のように見える記述になってきたら、新言語の完成、というわけだ。
C++も同様だったと聞いているし。

2019/12/14(土) 14:15:29.43

switch(hoge){
case HAGE: do{}while(0); break;
case FUGA: do{}while(0); break;
default: do{}while(0); break;
}
マクロにするとスコープ問題も解決するしbreak書き忘れも無くなる

2019/12/14(土) 14:16:22.48

>>830
QTもその延長にある希ガス

2019/12/14(土) 14:25:44.80

int a = 0;
do {
int a = 1;
} while (a);

このコードの挙動が変わってしまうから直せないと思う

2019/12/14(土) 14:30:23.06

>>830
マジレスされるとは思わなかったけど例えばこんなのとか。C FAQでヤメロと言われてるような。

#define SCOPED_DO(VARS) for(;;) { VARS;
#define SCOPED_WHILE(COND) if(COND) continue; break;}

SCOPED_DO(int i;)
:
SCOPED_WHILE(i<10);

2019/12/14(土) 14:34:41.93

ああ、確かにやめた方が良い

2019/12/14(土) 16:21:38.04

>>831
すまんがそのコードの意味はよく分からない。

>>834
それはマクロにすることが目的で、見やすいコードを書こうとしていないので、
FAQでなくても止めろと言われて当然だ。
マクロも当然ながら見てすぐ分からないといけない。
この意味ではlinuxのコードが参考になるだろう。
小文字マクロが大量に使われていて、それでも何とかなってる。
逆に言えば、小文字マクロ＝関数だと勘違いしても問題ない範囲で使え、ということだ。
どう変換されるかぱっと分からないマクロは逆に読みづらくなる。

ただまあ、ifとswitchの取り扱いからすると、
C: for文が例外で、他は{}がスコープ
C++: do-while文が例外で、スコープを開始出来るキーワード(for/switch/if)ではキーワード部分までスコープに含める
という状況なので、do-whileのスコープも拡張されるのは時間の問題だとも思うが。

2019/12/14(土) 16:52:48.59

みんなわかってることを長々書く人
do-whileもかなりどうでもいい
気分だけの問題でそんなとこで困ったこと一度もない

2019/12/14(土) 19:17:52.66

>>837
ゆとり死ね

> みんなわかってることを長々書く人
何度も言っているが、お前らゆとりが駄目なのはそういうところだ。
ここで話すのに「俺の人格」なんて全く関係ないし、実際今のところ気にしてた奴なんていないだろ。
お前以外は全員、技術面にフォーカス出来ている。

ゆとりが駄目なのは、結局、こうやって場を一々ぶち壊していくことだ。
結果、ゆとりゴキブリが一匹でも入り込める場は全部ぶち壊されていく。
その結果、ゆとり自身の居場所が無くなっているというのが、現在のお前らを取り巻く状況だ。

お前らゆとりはネット上では何を言ってもいい、何をやってもいいと勘違いしている。
そうじゃない。
自由に意見は言っていいが、コミュニティに対する破壊活動は許容されない。
そしてお前らは何がそれに該当するのかさっぱり理解出来ていない。
しかしお前らはネット慣れしていると勘違いしているからかそれを認めることすら出来ない。
お前らは本当に救いようがない。

おそらくはネットが出現することによって、リアルが希薄になり、
結果、リアルでのコミュニティ（人間関係）を構築することが不得手になっている。
しかしそれは当然ネット上にも適用/応用出来るものであり、結果、ゆとりはコミュ障となっている。
ところがゆとりは誰かがネット上で形成したコミュニティにただ乗りして来れているから、その問題にも気づけない。
それが「コミュ力」とか言われた問題の本質だよ。
それ以前の世代では否応なしに必要とされた最低限の「コミュ力」がゆとりにはない。
（ただしこの意味ではコミュ障害でも生きていける社会に改善された、と考えることも出来るが）

お前の発言によって、コミュニティがどう動くか、少しは考えてから物を言え。
そうじゃないからお前らゆとりはお前ら自身で形成したコミュニティを持てないんだよ。
それにすら気づけないのだろうけど。

2019/12/14(土) 19:23:47.82

くっさ

2019/12/14(土) 19:42:59.23

>>808
言いたいことはわかる
do {} 内のスコープを後に続く while() の条件式にまで拡張すればいいだけだからそんなに無理なくできそうな気がするんだけどね

2019/12/14(土) 20:47:22.30

>>840
StackOverflowの質問の筆者もそうだが、技術的にはやれば出来る程度の問題のはず。
あとは言語としての一貫性(＝{}をスコープとする)をどこまで厳密に適用するかだ。
ただ俺はこれがおかしな仕様のまま残されていることが奇妙だと思っている。
Cはほぼ変化する気がないからともかくとして、
Cの駄目なところを改善している他の新しい言語(C#等）でもそのままなのに驚いた。
ただ、ifやswitchまで拡張されたのなら、whileもそうだな。

現行
String^ line;
while ((line = sr->Readline())!=nullptr) {
...
}

次？（もしかして今ももう出来る？)
while ((String^ line = sr->Readline())!=nullptr) {
...
}

駄目だ駄目だと言われている条件式内での代入も、カンマ演算子も、上手く使えば美しく書けることに気づいた。
そして駄目だと言われているのは「白黒端末」前提であり、実は
「条件式内で代入演算子を用いた場合、太字にする」とかIDEのサポートがあれば問題ない気がしてきている。
つまりは、見た目気づきにくいから駄目なだけであって、見りゃ分かる、なら問題ないからだ。
だからコーディングルールもカラー端末大画面前提でのルールに変えていくべきなんだよな、とも。

2019/12/14(土) 22:59:30.18

{do{}while(cond);}

2019/12/15(日) 00:28:30.20

>>837
ID:x6gTDhtk0は、ほぼ確実にMIPS君だろｗ

＞自由に意見は言っていいが、コミュニティに対する破壊活動は許容されない。
＞そしてお前らは何がそれに該当するのかさっぱり理解出来ていない。

＞お前の発言によって、コミュニティがどう動くか、少しは考えてから物を言え。
この前キャリーフラグに関する間違い指摘されたら、100レス以上暴れたのはどこのどいつだよｗ

2019/12/15(日) 08:16:45.70

>>843
ゆとり死ね

というか、ゆとりは認めないが、ゆとりの識別能力は恐ろしく低い。
単に「長文である」とか、そういう外面的な情報しか見えてないからだ。
結局これは、いわゆる「コミュ能力」が低いからであって、つまりは相手が見えてないからだ。
当たり前だがネット上でも相手は人間、リアルのコミュ能力が低ければネットでも低くなる。
（ただしリアルとはチューニングがかなり異なるので、
リアルでコミュ力高くてもネット慣れもしてないとちぐはぐな対応になってしまうが）
「空気読め」というのも、逆に言えば、
それまでの奴らは「空気読め」と言われるほど酷い発言/行動はしなかったんだよ。
良いか悪いかはさておき、「○○さんに対してそれはねーわ」が完全に共有されてた。
（ただしこれは本当に悪い側面も持つので、これ自体が破壊されたのは悪くはないかもしれない）
それをゆとりが出てきたおかげで、「空気読め」と言われだした。
そして雰囲気だけで無理強いする奴がそれを濫用し始めておかしな事になってるのが今だ。

お前らはその識別能力の低さを自覚した方がいい。
ゆとり以前の世代はこの自覚があるから、ゆとりレベルでトンチンカンな発言はしない。
俺はその話は知らないし、本来は一々否定することも面倒だからしないが、
いい加減ゆとりにはうんざりしているので、
「どうしてゆとりを排除しなければならないか」を蕩々と述べ、認識を共有することをまず始めることにした。
現状はそこから始めないと駄目だ、というのが俺の認識だ。
どれだけ新しいスレを作っても、良くなってきたらゆとりに破壊されるのを既に何度も繰り返してきたからだ。

ただ、おそらく、ネットを「正しく使える奴」と「間違った使い方しか出来ない奴」に強烈に分化しているのが現状だと思う。
「間違った使い方しか出来てない」奴は、本当によく考えた方がいい。
そして「『間違った使い方しか出来てない』奴（≒」ゆとり）はコミュニティに不要」と
認識を共有した者同士で脱皮しようと言うわけだ。これは既に述べたとおり。

ゆとりは俺を気に入らないようだが、実際、ここに投稿してもすぐにレスが付くだろ。
それは、お前とは違って、「まだこのスレも読む価値がある」と認めている奴も多い、ってことなんだよ。

2019/12/15(日) 10:15:43.33

相手に伝えたいことを簡潔に表現する能力がない無能なんだから許してやれよw

2019/12/15(日) 10:22:17.71

これだから老害はダメ。

2019/12/15(日) 11:27:27.58

https://eigo-box.jp/others/jokes/#idiot
これを地で行くやつｗ

2019/12/15(日) 11:28:04.52

しくった
https://eigo-box.jp/others/jokes/#9_idiot

2019/12/15(日) 11:39:59.90

>>845-848
ゆとり死ね

一行しか理解出来ないゆとりにはこれがもっとも適切な表現だ。
常に最初に書いて置いたその意味もお前らには理解出来なかったようだが。

2019/12/15(日) 11:51:44.14

鬱積したもんがあるんだろうね
ここに渾身の長文書いたら皆が読んで敵は打ちひしがれ、味方は共感してくれると思ってるところが
こいつのかわいいところであり、哀れであるところ

2019/12/15(日) 11:57:15.36

>>850
ｗｗｗ

2019/12/15(日) 13:08:21.74

>>850-851
ゆとり死ね

お前らにとって理解不能でも、意味があることはあるんだよ。
何故お前らゆとりがそこまで傲慢なのか俺には分からないが。

2019/12/15(日) 13:16:19.97

その「意味があること」とやらを、おまえさんは伝えたいのか？
伝えたいのに伝わらないという問題に直面したとき
どうすれば伝わるか考えるという科学はしているのか？

2019/12/15(日) 13:18:32.30

>>852
相手がゆとり世代かどうかも分からないのにそう決めつけたり、ゆとり世代というレッテルで一括りにしたり、非論理的な主張をするお前も無能だろう

2019/12/15(日) 14:31:16.94

>>853-854
ゆとり死ね

そう思うならそれでいい。
俺の文がお前ら宛だと思っているのはお前らの勘違いでしかない。
俺は今ここを読んでいるが特に文句を言ってない連中、或いは将来的にここを読む奴宛に書いている。
彼等がどう思うかだよ。

ワッチョイ確認すれば分かるが、
実際、今回技術面にフォーカスしてきちんと議論出来ている人は、誰一人として文句を言ってないだろ。
一方、お前らゆとりは文句しか言ってない。
これが、既に言った、「正しく使える奴」と「間違った使い方しか出来ない奴」(≒ゆとり）の差だよ。

本来、コミュニティに対して生産的でない奴には発言権もないべきなんだよ。
それはリアルでは当然そうなっていて、会社で無能に発言権がないのもこれでしかない。
ところがネットではゆとりみたいなクズでもどのコミュニティに対しても自由に参加出来るものだから、
お前らゆとりはそういうものだと勘違いしてしまっている。
結果、お前らゆとり自体が本質的にクズ人間集団のように以前の世代から見たら思えてしまう。
これがゆとり問題の根元だよ。
そして問題は、このことを、お前らゆとりも、また、以前の世代も、意識出来ていないことだ。

ここがC++技術のスレなら、最低限、C++技術に関しての発言をする/した奴にしか発言権はない。
俺に文句を言う前に、お前らが何らかの「スレを盛り上げる為のC++技術論」を展開して、
コミュニティに対して生産的に寄与してからでないと、発言権はないんだ。
これは本当に当たり前のことなんだよ。
（というか、そうしないとコミュニティが崩壊して存続出来ないから、
存在しているコミュニティは本質的にそういうものとなる）
ゆとりでも分かるように言えば、リアルでシカトされるような行動/発言はネットでも慎むべきなんだよ。
まあもっとも、お前らゆとりはリアルでも「ないわ～」な行動をしてブッ叩かれていたわけだが。

再度言うが、文句を言う前に何か他人を巻き込んで盛り上がるC++技術論を展開しろ。
そして俺にマウント取りたいのならC++技術論で来い。

2019/12/15(日) 14:35:38.91

箇条書きできない人ってそんなに珍しくないと思うよ

2019/12/15(日) 16:28:15.78

>>856
違うぞ。俺は単に言いたいことが多いだけだ。
それは見えている物がお前らより多いからだ。

そしてそれは既に言ったが「知識のネットワーク化」により、全部関連してるからだ。
何度も繰り返したように、これは見えた展開でしかない。
お前らはどうやら無限にこれを繰り返す気らしいが、俺はもうそろそろ終止符を打ちたいので、
俺の思想を開示し、賛同者を募っている。

プログラミングもそうだが、こういった展開も実は抽象化出来る。
お前らは文系脳だからそういう感覚すらないようだが。
今やっていることは「海と山が近い町での漁師と農民の喧嘩」でしかなく、リアルでも1000年以上繰り返してきてる。
それをお前ら文系は別々のこととして暗記するから駄目なんだ。
まあもういいが。

2019/12/15(日) 16:34:06.95

>>856
ゆとり死ね

言い忘れてたので言っとく。
>>720が俺が箇条書きしたものだ。
ゆとり馬鹿以外に箇条書き出来ない奴がいると思っているのはゆとりすぎる。

**853** (ﾜｯﾁｮｲ c612-X5Um) · 2019/12/15(日) 16:37:54.83

科学しねえサルであることはわかった
あばよエテ公

2019/12/15(日) 16:45:25.74

そのための隔離スレ

2019/12/15(日) 16:51:02.24

円周率はなぜπなのですか

2019/12/15(日) 17:12:06.27

>>860
隔離スレから出てこないところだけは評価してもよいと思う。

2019/12/15(日) 17:18:40.06

>>833 の指摘が簡潔で十分に説得的だと思う。

C++の人は何故こんなに互いに罵り合うのだろう。
それも技術的な妥当性などより先に人格や経歴を否定するような表現を使って。

2019/12/15(日) 18:07:39.62

>>863
>>833については広義に捕らえればifやswitchでも発生することだし、
それ以前にC++は駄目な仕様は互換性が無くなっても改善して行ってる。
一応はいまだに「完璧な言語」を目指している。

> C++の人は何故こんなに互いに罵り合うのだろう。
C++だけの問題ではないと思うが、お前の言う「罵りあってない言語スレ」ってどこよ？
あと、揚げ足取り気味だが、
> 経歴を否定
してる奴は俺含めて誰も居ないと思うが？

2019/12/15(日) 18:22:34.11

仕様変えろって言ってたのは do ~ while の話なのになんで if や switch が関係ある？
なにか話が通じてないっぽい。

2019/12/15(日) 18:43:08.65

>>865
話が通じてないのはお前だ馬鹿タレ。

スコープの拡張によってdo-whileは従来コードと動作が変わってしまうので採用出来ない、というのなら、
if文もスコープの拡張によって従来コードとは動作が変わってしまっているし、switch文もそうだ。
だから、do-while文が従来コードと動作が変わってしまうから仕様の変更が出来ない、ということはない。

つか、お前ら馬鹿には短く書いたら通じないのに、
一々お前ら馬鹿にも分かるように説明してやると長いと文句を言うという。
だからお前らとはコミュニヶーション無理なんだよ。

2019/12/15(日) 18:43:53.57

今あるdo whileの挙動が変わるような仕様に変える事なんて出来ないよ

仕様追加なら>>812が良い
ループ変数もローカルで定義出来る

2019/12/15(日) 18:59:11.49

>>867
812は使えない。

（そもそもほぼ使われてないというのはさておき）
・do-whileの場合は、最初に条件変数を確定させることが出来ない場合が多い
・宣言だけdo内で出来ても余計に見にくくなるだけ、それなら{}内でいい

ただしifやswitchのように「変数スコープを汚さない」為ならこの仕様でもいい。
だから俺は賛成はしないが、実際に提案したら通るかもしれない、とは思う。
なお本来こういうのはRsustの出番だが、
今見たところRustもwhileのスコープはCと同様のようだ。
https://doc.rust-jp.rs/the-rust-programming-language-ja/1.6/book/loops.html

◆QZaw55cn4c (ﾜｯﾁｮｲ 8247-uUlA) · 2019/12/15(日) 19:13:29.02

>>817
私は for(;;) { }
を愛用しています

2019/12/15(日) 19:54:31.00

>>868
for と比べても一貫性があるし
過去コードにも影響を与えない

より良い案があるなら書いてみれば？

2019/12/15(日) 19:57:40.04

>>817
意味的には
while (TRUE)
なんだけど
なぜかみんな1だよね

1の方が楽だから？
それともTRUEが定義されてないことまで考えて？

既に定型文だからこのままで良いけど

2019/12/15(日) 19:59:26.20

#define ever (;;)

for ever {
}

こんなネタがあった

2019/12/15(日) 20:02:45.50

クサチューのオンパレード

◆QZaw55cn4c (ﾜｯﾁｮｲ 8247-uUlA) · 2019/12/15(日) 20:13:29.55

>>871
TRUE は自分で定義しないといけない分、面倒くさいですから
for(;;) { } ならそれも必要ないのでお得ですよ

2019/12/15(日) 20:14:24.62

ここC++スレだよな？　（極度の脱力）

2019/12/15(日) 20:15:33.29

キチガイの隔離スレですよ

2019/12/15(日) 20:33:32.81

C++スレであることを忘れてた
while (true)
while (1)
for (;;)
do while (1)
do while (true)

forが一番文字数が少ないけど...
while (1) を一番良く見る

2019/12/15(日) 20:38:53.09

>>870
既に816に書いたし、元のstackoverflowとの例とも同じだが、再記すると、

do {
bool flag = ...
} while (flag);

要するに while () までスコープを拡大しろ、というだけ。
これ自体もfor文とは整合性が取れている。敢えてスコープを [ ] で示すと、

[ for (int i=0; i<num; i++) { ... } ]
[ do { ... } while ( ... ) ]
[ while ((String^ line = sr->Readline())!=nullptr) { ... } ]

要するに全部外側まで含めろ、でしかない。
これは既に記したC++リファレンスでも言ってるだろ。
> 見方を変えるとfor文で可能な初期化が、なぜかif文やswitch文ではできない、文法に一貫性がない問題と見ることもできる。
> https://cpprefjp.github.io/lang/cpp17/selection_statements_with_initializer.html
ならdo-whileとwhileでもやらせろ、というだけの話。

ただしこれに関しては合意する必要がないので、ここまででいい。
俺はこれが最善だと思うし、君は816が最善だと思っているだけ。
提案するならどうぞ。俺は君の案が最善だとは思わないから協力はしない。
ただ、仕様委員会が君の提案を最善だと思うのなら、通るだろうし、その可能性もあると思う。
どちらがいいかなんて俺と君で詰める必要はないし、その意味もない。
（というのを868で言ったつもり)

2019/12/15(日) 20:40:25.63

>>868
過去のコードが動かなくなるのはダメだ
って言ってるのに

2019/12/15(日) 20:55:41.23

while (★::flag)

互換性を保つならこんなんだろうげど
★にたいする適切な物が思い浮かばない
予約語を増やすか演算子を増やすかくらい
直近の変数がデフォにならないのも違和感

そもそもループ変数のスコープ問題が解決しない