C++相談室 part133

2017/11/24(金) 16:52:50.43

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

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

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

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

■長いソースを貼るときはここへ。■
　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

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

2017/11/27(月) 13:23:45.26

>>97
ああそういうことね

2017/11/27(月) 20:00:43.82

>>83
> 入門書でオブジェクト指向の解説
ここがそもそも間違っている。
オブジェクト指向は肥大化(10k行以上）するソフトウェアを整理して記述するための方法論であって、
肥大化してない（1k以下）ものすら書けない初心者（入門書を読む層）には不要だからだ。
だから、ない。要らないから、無いんだよ。
少し考えれば分かるはずだが、世界中の誰も出来ないと思うかい？そんなわけないだろ。

ただし、日本のシステムでは必要なんだよ。
日本では大量の馬鹿（新入社員）でもプロジェクトの足しにする方向だから、
せいぜい100行しか組めないド新人にもオブジェクト指向を強いる。それが日本のJavaだ。
既に稼働中の大規模システムに組み込むコードは、
それが新人が書いたものであっても、正しくオブジェクト指向してないと困るから。
言い換えれば、大量の馬鹿が少しずつ組み上げることに日本は特化している。
これは平均的ド素人の最低レベルが保証される社会だから出来る方式でもある。

逆に海外はおそらくそんな馬鹿が大規模システムに組み込むコードを書く前提にしてない。
熟練し、正しくオブジェクト指向できる奴だけでメンテする前提であり、馬鹿は死ね、だ。
これはITドカタの給与の平均値からも分かる。だいたい海外は日本の2倍だ。
だから初心者にオブジェクト指向を教える意味がないんだよ。

オブジェクト指向自体は別段難しいものではなく、また、手続き型(Cスタイル）と（実は）地続きだから、
十分に熟練すれば自然と理解できるし、「手続き型だ」と言い張ったところでどうしても中身は似てくる。

Java鹿は、オブジェクト指向と手続き型が別物だと勘違いしている。
ド新人に「オブジェクト指向(ｷﾘｯ」と洗脳し、その意味すら理解できない馬鹿が教える側に回って、悪循環してる。
普通に考えれば、C++の仕様でstructとclassがほぼ同じことからも、
また、未だにインスタンスメソッドとクラスメソッドの区別が文法以外にほぼ無いことからもこれは分かる。
(instance.method()とstaticMethod(instance)の実行時の違いがほぼ無い、
或いは、結局はレシーバをどう記述するかだけの話だ、と言った方が分かりやすいか。
Goに至ってはこの点、どっちでもいいです、という仕様にしてしまっているし）

2017/11/27(月) 20:02:10.31

Cで大規模なシステムを組むと、どうしてもstruct*を多用することになる。
これ自体がオブジェクト指向そのものだ。
ただしCにはこれをサポートするための文法が無く、全部自分でやらないといけない。
だからちと辛いし、class構文欲しい、というのは自然な流れだ。

おそらくLinusがC++erを毛嫌いしているのはこの辺で、（彼が嫌っているのはC++ではなくC++erね、念のため）
Cにはサポート構文がないだけであって、
自前でやる気なら正しくオブジェクト指向できるし、
それが昨今の「継承イラネ、全面委譲で」なら実は大して手間は変わらない。
この場合、「C文法で組め」と言われても、「ああ、これならまあ」程度でしかない。
これについてグダグダ言う奴は理解できてない馬鹿だからイラネ、ってのは当たってる。

そもそも、入門者の言う「オグジェクト指向が難しい」の理由は、
「オブジェクト指向で組めない」ではなく、
「オブジェクト指向の利点が分からない」「なぜこんな記述方式にする必要があるのか？」だろ。
元々大規模のコードを整理するための手法なんだから、
大規模なコードが書けない新人には理解できないのは当たり前。
それを理解しろ、という日本方式に無理があるんだよ。

あと、Javaの問題は、かなり制限された言語だから、
他言語だとすごく単純に記述できることを
デザインパターン(ｷﾘｯをこねくり回して意味不明な構造にしないといけないことが多いこと。
だからC++入門者にJavaを勧めるというのはやっぱりキチガイだよ。
そしてこの意味で老害が一番多いのはJavaだと思うよ。
と言うか、ちょっと逝っちまっていることを言う奴はたいていJava鹿だ。>>86もそうだろ。
例のスタティックおじさんの話もJavaだし。（あれは双方の言い分も分かるが）

2017/11/27(月) 20:03:35.06

C++の問題は、「何でも出来る最強言語」を目指しているのか、本当に何でもありすぎる点だ。
だから新人が戸惑ってしまうのも分かるし、無駄に覚えることも多すぎる。
例えば、継承した場合に隠蔽できるが、あれなんてマジで要らないだろ。
(virtualでないメソッドをoverride（とは言わないが）して隠蔽、って奴ね）
この辺、バランスが取れているのはC#だ。そもそもそこが狙いのようだし。

Cに関しては、老害ではなく、「老」が多い。これは古い言語だから。
ただしC++への移行はいつでも出来たし、既に書いたがオブジェクト指向とは地続きだから、
文法的にオブジェクト指向してないだけで中身はオブジェクト指向そのもの、ってのはよくある話だ。
そしてCは元々関数ポインタを扱えた。これはものすごく大きい。

Javaが糞なのは、全く関数ポインタを扱えず、
その結果デザインパターン(ｷﾘｯする糞言語になっている点だ。
ただしあの頃はまだ「関数ポインタの有用性」がさほど理解されておらず、致し方なかった面もある。
C#もこの辺、記述方式が二転三転しているし、C++もやっとラムダを取り入れたばかりだ。
K&Rも「関数ポインタも使えるよ」としか書いて無い。あれはもっと力説されて然るべきだった。
でも、今新しい言語を作るとして、関数ポインタが使えないのはマジで糞だろ。
そしてこの点、文法的にではなく、
「社内ルールで」関数ポインタの使用を制限する「老害」が多いのは圧倒的にJavaに決まっている。
Cは元々使えたし、C++は(読みやすくはないが)ファンクタを使えたので、有用性は「老」でも理解している。
Javaにはそもそも関数ポインタの使い方を理解している「老」がいない。
Java8で文法的には取り入れられたものの、おそらく大半の職場では相当期間制限されるはず。

2017/11/27(月) 20:05:06.84

海外の連中の話だと、「プログラミング自体」を学ぶのに一番早いのはPythonだと言われてる。
(俺はPythonを使ったことがないから分からんが)
例えば、入門者のよくある質問、
「元データがこういう配列で、このうち○○を含むものだけを抜き出したい」等、
どうプログラミングするか、という所から学ぶケースだ。
この辺の本当の初心者に対しては、
C++の、よし、ここはスマポだ、とか、
Javaの、そこはオブジェクト指向で云々、とかは邪魔なんだよ。
本当にフォーカスすべき案件に集中できない。
この意味ではC++は最初の言語には向いていない。
だからド初心者用の入門書の良書は少なく（需要がない）、逆にeffective系が多いのだと思う。
ただしPython自体も古くてゴミな部分もあるから、（ラムダに制限がある）
基礎を組めるようになったら早く卒業し、
C/C++やJavaScript等の「無制限な」言語で色々やったほうが上達するとは思うが。
この意味ではJavaやPythonは制限されすぎていて駄目で、
C#は適切に制限されているから、現実解としてはかなりありで、
C/C++やJavaScriptは自由すぎて(上達はするが)大規模システムを組むには怖く、
だからこそJavaが現代版COBOLとしてのさばっている、という構図だが。
だから、C++erが大規模システムの為に安全なJava言語を選ぶ、というのはありなのだが、
Javaしか出来ないJava鹿が知ったような口を利くからおかしなことになる。
Javaがどれほど制限されているのか理解していればそんなことは言えない筈なんだがな。

この辺、新しく出てきたGoは色々整理されているはずだと期待したんだが、
かなり糞だったので逆に驚いた。あれではC+GCでしかない。
今更Generic出来ないとかマジで糞過ぎる。
逆に言えば、今でもC文法そのままでよく、GCだけ欲しい人にはGoは向いているが。

2017/11/27(月) 20:24:50.03

>>102
Go はさっぱりあかん言語だというのには同意するが、
現実にはその程度で良かったという話なんだよ……

2017/11/27(月) 20:46:19.07

全くの初心者なら、まずはC言語の勉強をしてから>>94のc++ プライマー第5版などを読むのがいいかもしれないね
俺の知っているC言語の本で一番分かりやすかったのは、アスキーラーニングシステムの「入門C言語新装版」と「実習C言語新装版」だけど、さすがに古いかな？
同じ著者の本で2008年に出ている「Cプログラミング講座」というのもあるけど、これは読んだことがないな
というか、こっちもすでに絶版になっているっぽいな．．．

2017/11/27(月) 21:02:33.36

発狂しやがったｗ

2017/11/27(月) 21:58:25.69

ゲームプログラマになる前に覚えておきたい技術、平山尚、2008

この本は賞を取ってるけど、セガの平山は、
1冊で、C++ の文法と、ゲームプログラミングの2つを、
同時に習得できる本を目指したけど、無理だった

結局、C++の文法だけで、2007年のロベールの分厚さが必要。
人間の読める限界を超えている。
それでも、日本にはロベールがあるだけマシ。
外人は、やさしい本が無いから、もっと苦労してる

結局、1冊でJava の文法と、オブジェクト指向の2つを説明したのが、
2011年の「スッキリJava」

ここまで、待たなければならなかった。
外人は、スッキリも無いから、もっと苦労してる

外人の場合、専門書しかないから、偏差値70未満は、単純に振るい落とされるだけ。
日本のように、学ぶことはできない

2017/11/27(月) 22:04:03.51

>>103
あれは言っちゃあ悪いがC++のオブジェクト指向が暴走した反動だよ。
C++が無駄に複雑化しなければ全くのゴミだったはず。
それ以前にC++はGC嫌いが宗教じみてる。
無駄にスマポで頑張るのではなく、VC++/CLIのgcnewを導入した方がましだったと思うよ。

Goは全く新しい機能がなくてびっくりした。
ただ、C++が複雑化しすぎてWeb系（というかバックグラウンドがない初心者）に厳しいのは事実。
そしてゆとり版C++＝Goってのも分からなくもない展開だ。
ただ、持ち上げている連中の非力感は否めない。
あれは関数型()と同様に大騒ぎしてポシャる可能性もあると思う。

◆QZaw55cn4c (ﾜｯﾁｮｲ 5f60-2JzH) · 2017/11/27(月) 22:37:12.11

>>93
独習c++ いいね、ハーバード・シルトは要点を押さえてさえている、独習Java がダメダメだったのとは一線を隔しているね
演習問題に std::string を再実装する、という山場があるが、それを乗り越えると c++ の初級者になれると思う

2017/11/27(月) 22:38:46.80

>>70
明確な強い理由がない限り言語なんて大概何でもいいだろ

どこの現場でも出来る奴ってのは、モジュール設計のセンスとネーミングセンスのある奴じゃなかろうか

◆QZaw55cn4c (ﾜｯﾁｮｲ 5f60-2JzH) · 2017/11/27(月) 22:55:46.68

>>99
Java のいいところは、一文字一文字丁寧に読んでいければだれでもわかるように書けるところにあるのでは？
それは一つの到達点だと思う
BigInteger.ONE とか、ちょっと嫌だな、と思う書き方はあるが、仕方がない
（gmp なら普通に 1 と書けば文脈を読んで BigInteger(1) というコンストラクタが働くのだが、昔の Java はそもそもオートボクシングがなかったくらいだし）

C/C++ ならスタックにデータを置けても規模が大きくなると、new/delete する方向になるのを見込んで、Java が最初からクラスをスタックに置かないことに徹したのも、
定石どおりでいい感じ、Java は尖がったところがないので好感をもっている

昔はアルゴリズムの教科書といえば pascal で記述されたものだが、最近は Java で記述されているものもよくみかける
私は Java を非難したくはないな…

2017/11/27(月) 23:07:39.99

unique_ptrとshared_ptrのことちゃんと解説してる日本語本ってないだろ(C++1xのマニア向け本除く)
レガシーコードのメンテするんでもない限り生ポインタで一生懸命あーだこーだしてる古い本なんて役に立たないしむしろ有害だよ
規格書読んだほうがまし

2017/11/27(月) 23:08:39.40

>>107
じゃあ、おまえの主張どおりC++にGCを実装するなら
どんな実装になっていたんだ？
俺はベアメタルのROM屋だが
今でさえ例外だのRTTIだのでさえ殺意を覚えているんだが

2017/11/27(月) 23:26:49.34

マニア向けも何もunique_ptrもshared_ptrも1x以降に実装されたんだから当たり前やろ

2017/11/27(月) 23:28:11.32

unique_ptr, shared_ptr などは、たぶん、Boost の本に載ってるかな？

C++ は、Rust, Elixir へ移行している

C++ では、多重継承も難しいから、Java, C# では単一継承だけになった

2017/11/27(月) 23:32:43.41

>>112
だから書いたろ。gcnewだよ。
https://msdn.microsoft.com/ja-jp/library/te3ecsc8.aspx
動きとしては、C#やJavaのnewと同じ。
ただしnewだと予約語で被るのでgcnewになってる。

C++はランタイムが無いから、std::GCを作って、
gcnewを1回でも呼んでいるようならそれをリンクしてやればいいだけ。
まあ今からでもできる拡張だからやってくれ、とも思うが。
ただ、GCは絶対に入れない宗教なんだろC++は。

2017/11/27(月) 23:34:27.97

いくらなんでもGCはいらんやろ

2017/11/27(月) 23:37:10.60

リソースを全部GCで管理してくれるならいいんだけど
自分で解放しないといけないリソースもあってなんだそりゃっていつも思う

2017/11/27(月) 23:38:00.85

GCなんて負の遺産だろ
崇高なC++にそんなもん混ぜんな

2017/11/27(月) 23:39:22.69

>>117
ほんこれ
んで結局usingだのwithだのって、ええ…って感じ

2017/11/28(火) 00:15:26.24

>>111
c++プライマー第５版で解説してる。

2017/11/28(火) 00:27:26.85

>>110
Java自体はオブジェクト指向の完成形になるはずだったのは認める。
問題は、Javaに関数ポインタがなく、それが致命的だったことだよ。

というかあの頃のC++/C#/Javaの連中は誰も関数ポインタの有効性に気づいてない。
だからC++でも匿名関数をサポートしてなかった。
関数ポインタ＝オブジェクト指向（多態）を手動でやるときに必要＝クラス構文でサポートしたからイラネ
という判断だったのだろう。C#のdelegateもまずクラス(thisの受け皿）ありき、だからね。
あとはcallback出来ればいいや、位か。
関数型のように関数ポインタを常用する事になるとは思ってもいなかったはず。

ところがLisp-Erlang-Haskellの連中は匿名関数の有効性に気づいていて、
おそらくJavaScriptでそこに日が当たってしまった。
そして匿名関数のサポートがないのは間違いだったと気づき、C++/C#/Javaの全てはこれを導入した。
(後は関数がfirstClassObjectになるかどうかだが、
今のC++の雰囲気なら、じきに何らかのサポートを入れると思う)

ここで問題なのは、C++/C#は以前から関数ポインタを（見やすくはないが）使えたから、
ユーザも使えるし、コードも必要ならそう記述してあること。
一方、Javaはユーザ側にその知識がないし、
関数ポインタが無い為に継承等で無理に実装してあるコードが既に大量にあること。

Javaユーザが勉強熱心だとはお世辞にも思わないし、何周も他言語ユーザから遅れてしまっている。
そして大量に居るJava鹿の為、すぐにJava8を導入できるとも思えない。

ただしC#は進化し続けた＝ユーザーに勉強を強い（時間を奪い）、
また環境にも負荷をかけ続けた（いちいち新しいコンパイラ等を整備する必要がある）為、
結果的にエコシステムの構築が遅れ、
下位互換でしかないJavaに対してかなり出遅れている感じは否めない。
ここら辺は結果論でしかないが、分からん物だね。
単純にいい言語が繁栄するわけでもないし。

2017/11/28(火) 00:41:52.09

ﾜｯﾁｮｲ便利だね。

2017/11/28(火) 01:00:11.14

煽りカスさん乙

2017/11/28(火) 01:05:09.69

匿名関数はラムダやろ？

2017/11/28(火) 01:10:37.08

古典的な同期プログラムなど、いまどき何で書いても同じ
問題になるのは
非同期処理やら
例外安全(処理の巻き戻し)やら
マルチスレッドでデッドロックしない云々やら
いわゆるトランザクションのようなものをどう実現するかやら
そのへん

超高級言語で、いわゆるスクリプトなどなど
高級なくせに上記のサポートが何もないのが真の糞言語で
無駄に重たいだけで、「今まで何やってたの？」状態
動的型なんか何も意味無かったし、本当に何やってたんだろうな

2017/11/28(火) 02:18:11.95

Go はランタイムごと新しく作ったからな。

2017/11/28(火) 05:29:42.55

>>115
おまえアンカーミスったか？
俺の問いに対して一言も答えていないんだが

2017/11/28(火) 06:46:20.76

new自体ほぼ使わないのにgcnewを導入しろとかアホか

2017/11/28(火) 07:49:07.52

一連の投稿(同一ワッチョイによる)を一通り読んだけど、
マトモに議論(賛成にしろ反論にしろ)できるほど理解できなかったわ。
自分の読解力というか、多くのプログラミング言語を比較評価できるだけの
知識の欠如が原因で、投稿者を批判するわけじゃないんだが。

ただ一応は読んだ、という証拠を示す意味で一言。
>>102 にある「Javaしか出来ないJava鹿」って言い回しは気に入った。
意識して書いたか分からないけど、ウマくかかってる。

2017/11/28(火) 08:26:28.34

他の言語のスレに行ってJAVAを薦める「Javaデモ」はいらん。
デモもピケもお断り

2017/11/28(火) 11:27:26.73

Javaはいいぞう～。

2017/11/28(火) 12:26:15.71

Java原人がいるようだね

2017/11/28(火) 20:00:44.77

煽っても無駄ですよ！

2017/11/28(火) 20:32:34.90

D言語はなぜ流行らなかったのか・・・・・・

2017/11/28(火) 20:33:55.36

俺、D言語の方が好きなんだ

2017/11/28(火) 20:43:15.23

規格の更新速度が遅すぎた

2017/11/28(火) 20:56:09.01

pairを戻り値とする関数内でmake_pairを返そうとしてる

pair<string, string>( vector<string> vec)
{
return make_pair<string,string>(vec[0],vec[1])
}

要素数が2より小さいときにペアが作れないから他のものを返したいのだけど
こういう場合は何を返せば良いのだろうか？
受けてる先では

map<string,string>にinsertをしてる

2017/11/28(火) 20:59:58.28

>>137
見直して意味わからんかったので直しました

pair<string, string> XXX( vector<string> vec)
{
return make_pair<string,string>(vec[0],vec[1])
}

int main()
{
map<string,string> map:
map.insert(XXX(vector))
}

2017/11/28(火) 21:14:23.08

>>137
C++17の std::optional を使うところかな

戻り値をstd::optional<std::pair<string, string>>にして
意味論的に不正な場合は std::nullopt を返す

C++17以前なら boost::optional もあり

2017/11/28(火) 21:16:00.33

>>137
しらんがな。返したいもの返せよ

2017/11/28(火) 21:17:15.47

tupleじゃあかんの？常に2以下なんかね

2017/11/28(火) 21:27:48.71

あぁスマンmapに入れるのか
でも１つしか無かった場合もmapに入れたいのかエラーにしたいのか？？

あとmake_pairは関数だからテンプレート引数は省略できるよ

2017/11/28(火) 21:59:35.14

>>127
キチガイ死ね
韓国人死ね

>>128
それはCへの回帰だぞ。お前は多分理解して無いと思うが。

2017/11/28(火) 22:39:29.70

>>137
nullobjectパターンかね
mapで絶対検索されないキーを突っ込んでおくとか

2017/11/28(火) 22:45:01.20

>>137
何を返しても嘘になるので、返してはダメ
if (vec.size() < 2) throw logic_error{"runt vector"};

2017/11/28(火) 22:46:39.17

もしくはassert(vec.size() >= 2);

2017/11/28(火) 22:54:08.70

name=valueみたいなのを分割してmapに入れる感じ？
俺も例外投げて止めてしまった方がいいねと思うね

2017/11/28(火) 23:41:38.36

だが待ってほしい。
例外を投げるということは誰かに責任を押し付けることではないだろうか。

2017/11/28(火) 23:44:58.64

上位処理「ハンコ押してください」

2017/11/28(火) 23:53:44.75

>>129
C++より簡単でお気軽な言語が大量にある今、C++で全くの初心者用の環境を要求すること自体が間違い。
それはトレーラやユンボでド初心者を教習するのに近い。
そうではなく、まず普免を取ってからこれらの特殊車両だろ。
お前は「俺はトレーラー乗りになりたいから、最初からトレーラーでやってくれ」とゴネている教習生なんだよ。

C++のオブジェクト指向でいい本が「世界中に」ない＝C++やるような奴にはそんなもの需要がない

でしかない。お前はそれすら理解出来ない馬鹿なのに、

> C++の本を書くような人はオブジェクト指向の説明をするのは沽券に関わると思っているのか、
> あるいは「C++の専門家」にはオブジェクト指向を教える能力がないのか。

ってのは自意識過剰すぎる。世界はお前を中心に回っているわけではない。
C++を使う必要がある局面でC++を使う人たちには、今更オブジェクト指向なんて教える必要がないんだよ。
それは自明だから。
そして本を書いている奴らも別段崇高な精神を持って布教しようとしているわけでもない。
いや、そういう奴もいるかもしれないが、当然「売れるから書く」という下俗な奴も世界には必ず居るはずであり、
そういう奴らすらいない＝売れない＝需要がない＝みんな既に知っているから、でしかない。
だいたい、オブジェクト指向ってのはプログラミング手法であり、
言語とは別の軸なのだから、「『C++の専門家には』オブジェクト指向を」ってのも論理的におかしい。

2017/11/28(火) 23:54:34.49

そもそもオブジェクト指向がさも特別で崇高な存在だ、なんてのはJava教団がそうしたがっているだけで、
実際のところは、Cで大規模コードを扱うと、最初はstruct*、次に関数ポインタの嵐になり、
これらをどうにかしてコンパイラに自動的にやらせよう、として生まれたのがC++のオブジェクト指向だ。
だから既に言ったがC→オブジェクト指向は完全に地続きなんだよ。
これは出自からしても当然で、
Cの典型的な問題点を新たな言語サポートにより解決することを目指したものがC++だから。
逆に言えば、C++98で搭載されている機能はほぼ全てCの問題点の克服であり、
Cを使いこなしていた連中にとっては当たり前に「その気持ちは分かる」ものでしかない。（なお同意するかは別)
そしてオブジェクト指向もこの中に入っている。
だから当初からオブジェクト指向の有効性をわざわざC++で語る意味はなかったし、
他お手軽系言語が乱立している現在、さらに輪をかけてその必要性がなくなっている。

2017/11/28(火) 23:55:33.62

それでも初心者が「オブジェクト指向自体を学びたい」ときにはどうすればいいかと言えば、
俺個人は「まず3k行程度なら平気で書けるようになってからでいい。そうすればおのずと分かる」という立場だ。
しかしそれでもHellowWorld直後のド初心者に教えようってのならJava教団みたいに洗脳していくしかない。
どう見ても実行に直接関係ない記述の嵐であり、ド初心者にとっては「無駄じゃね？」としか見えないだろうし。

だからこの意味ではJava教に入信しろ、というのもありではあるのだが、
問題はJava教団はJava教の不備は絶対に認めないというか、気づいてないことだ。
関数ポインタさえあれば非常に単純に実装できることを、無理に継承を導入したおかしな構造で対応し、
しかもそれをデザインパターン(ｷﾘｯと公式化しようとしている所が滑稽だ。
しかし、Java教信者は関数ポインタの存在を知らないから、この教義がおかしいとも気づけない。
また、Javaのオブジェクト指向は今既に邪道で、オブジェクト指向するのが目的化してきてる。
例えばprivateにすること、イテレータを実装することが目的になってるだろ。
だから実際に前スレ896みたいな事も平気でやる。本当に全く意味が無い。
(これについてはLinusはC++erも同様だと言っているが)
だからJava教でオブジェクト指向を学ぶのは、邪教というか、
邪オブジェクト指向を学ばされる可能性がかなり高いのでオススメしない。

2017/11/28(火) 23:56:37.90

結局、オブジェクト指向は｢学ぶ｣物ではなく、本来は｢悟る｣物なんだよ。
そしてそれは涅槃の境地で解脱しろ、みたいな崇高なものではまったくなく、
「この交差点、信号無いと危なくね？」位の、普通に運転してりゃ分かるだろ、程度の物でしかない。
だからわざわざ解説するほどのことでもないんだが、結果的に、
｢オブジェクト指向しろ｣と言われる割には解説本がなく、初心者にとってはなんだかよく分からん状況になっている。
そしてお前みたいな馬鹿は｢幼稚園で『どこに信号を立てるべきか』きっちり教えるべきだ！
俺は教わっていないから分からない！教えられる先生もいないのか！」
と主張するわけだが、完全にモンペ通り越してキチガイだろ。
オブジェクト指向は幼稚園で教えるべき内容ではないし、教えなくとも自然と理解できる物だし、C++は幼稚園ではないし。

そして脱線すると、「結局オブジェクト指向はよく分からんね｣というゆとりが逃げ出した結果が関数型祭りだ。
いや結果的にはC++/C#/Javaの全てがラムダを導入したのだから、一定の成功を得た、と評すべきかもしれんが。
しかしErlangみたいに「オブジェクト指向での限界を突破する」為の明確な方策がなく、
単に馬鹿な連中がより簡単な関数型に逃げ出しただけであり、そこで何か新しい境地が拓けるものではなかった。
そしてGoも俺はこれに似た匂いを感じてる。C++出来ないゆとりが集まっただけじゃんこれ、みたいな。
ただし、確かにC++は無駄に複雑化しているのも事実だが。

> Java鹿
それ、読み方は「Ja馬鹿」ね。ただ表記上分かりやすいので「Java鹿」にしてるが。

2017/11/28(火) 23:57:04.62

HellowWorld

2017/11/28(火) 23:59:42.90

また長文ウンチ君かよ

2017/11/28(火) 23:59:58.99

ワッチョイって神だわ

2017/11/29(水) 00:05:12.43

まあ俺はゆとりは死ねとしか思って無いからな。
つか、この程度の文も読めないのなら、お前ら仕様書や本も読めないだろ。
向いて無いからプログラマ辞めろよ。

2017/11/29(水) 00:13:55.97

>>148
そこはまぁその関数の仕様として、呼び出す側が確実にcatchする責任があるわけだな。
それを忘れると例外が呼び出し階層を突き抜けていっちゃう。
そういう事態を防ぐために考えられたのが検査例外だけど、これはこれで使いづらい面があるんで
Java以外にはあまり採用されなかった。
そんなことを考えてみると>>137程度の目的で例外などという暴力的な仕組みを使うのがそもそも
適切なのかどうか。Goの選択もそういうことなんだろう。

2017/11/29(水) 00:19:11.17

ttp://nekko1119.hatenablog.com/entry/20120625/1340602468

main関数の最後にあるstringへのキャストでエラーがでるのですがなぜですか。
エラー C2440 '型キャスト': 'Any' から 'std::string' に変換できません。

コンパイラはvc++2017です。

2017/11/29(水) 00:22:57.10

>>158
> Goの選択もそういうことなんだろう。
Goのって「自分でthrowしないといけない例外｣だろあれ。
あれなら普通の例外のほうがよかったんじゃ…と思ったけどね俺は。

2017/11/29(水) 00:29:49.23

>>159
(string)をany_cast<std::string>にすれば通りそうだが

2017/11/29(水) 00:36:37.38

>>161
通す方法ではなくてなぜ通らないのかが聞きたいのですが

template<Type>
operator Type()
で暗黙の型変換のオーバーロードを定義しており、
int型やHoge型に対して代入する際にそれが使われているのに
std::stringに対してだけうまくいかない理由はなぜかが知りたいです。

2017/11/29(水) 00:44:30.01

>>162
intのとこもHogeのとこもキャストは使われてないように見えるが…
でもまぁ確かに呼ばれてほしい気もするね
static_castでもだめ？

2017/11/29(水) 00:45:54.72

すいません。勘違いしてる部分がありました。

std;;stringだけじゃなくて他の型でもダメみたいですね。
質問取り下げます。もう一度自分で考えてみます。

>>161
失礼しました。

2017/11/29(水) 00:51:28.18

>>162
gcc 7.1.0とclang 6.0.0では通った
ただしstd::type_infoと書くべきところをただtype_infoと書いてる個所があるので、それは直したけど。
それより下のコンパイラバージョンだとエラーになった。(ambiguous conversion)

そして
(string)val
の代わりに
(const string&)val
と書いたらclang 4.0.1でも通った。

2017/11/29(水) 01:02:17.23

(int)valはいけますけど
(Hoge)val, (std;;string)valはダメのようですね。

で、ご指摘のとおり
(Hoge&)val, (std::string&)valは通りました。

前者と後者の違いは分からないですが。

2017/11/29(水) 01:27:40.52

& の意味が分からないなら、プログラミングできない

(int)val
普通、こういうキャストの書き方は、しない

static_cast など数種類あるキャストの書き方の中から、
キャストの種類を指定してキャストする

君は、入門書を読んでいないだろ

2017/11/29(水) 02:04:04.04

>>143
newの代わりにmalloc使ってるとか思ってるアホ？
今時new使うやつは以下のどれか
* Javaから来たC++初心者
* 化石コンパイラ使わさせられてる可哀想なやつ
* 自身が化石な可哀想なやつ
* パフォーマンスのために用意されてない構造の実装が必要なライブラリ設計者

お前は1番目と3番目の複合型だろうね。

2017/11/29(水) 02:17:56.38

template<class Type> Any::operator Type() const

上をやめて、下の２つを定義したらmain関数の記述そのままでうまくいきました。

template<class Type> Any::operator Type&() const
template<class Type> Any::operator const Type&() const

理由は分からないです。分かる方がいたら教えてください。

2017/11/29(水) 03:01:43.02

& の意味が分からないなら、プログラミングなんて出来ない。
初歩の初歩なのに

まず、入門書を読むこと

2017/11/29(水) 03:06:58.25

質問の意味わからんでレスしてる奴うざいわ

2017/11/29(水) 04:38:58.34

>>144
>>139
>>145
基本的には2以下は存在しないから例外処理組み込もうと思ったけどnullobjectってのがあるのね
おそらく俺の理想的にはこいつが適してそうだからこいつを調べてみるよ

>>145の言うとおりに絶対に呼ばれないキーをいれておくのも検討違いな気はしてる

2017/11/29(水) 04:50:10.36

>>147
まさにそれをしようとしてる
そこのロジック的には空文字入れる予定だから必ず2以上になるのだけど
関数分割していて関数としては何が返ってくるか不明なため
問題が起きたときのコードを記載しようとしてる
vectorのsizeが0や1の時にアクセス違反になってしまうからどうやれば回避できるのかなぁと悩んでる

例としてはこんなん
=value
key=value
key=
==value

2017/11/29(水) 07:52:20.02

>>171
確かにそうだね
それにclangの最新だと通ることから、それなりにややこしい話かと思う

2017/11/29(水) 08:27:09.91

>>173
> key=value
これは正常ケースだよね

> key=
仕様によるけどvalueに空文字入れときゃいいんじゃね？

> =value
> ==value
エラーでしょ？
例外発生させるなり、ログ採ってnullptr返すなりしなよ
そんなものを無理矢理 map に突っ込もうとするのがおかしいと思うぞ

2017/11/29(水) 08:58:03.16

＞vectorのsizeが0や1の時にアクセス違反になってしまうからどうやれば回避できるのかなぁと悩んでる
vectorの要素数が不確定の場合はatで取り出せばいいよ、なんかあったらout_of_rangeが飛んでくるから

2017/11/29(水) 09:33:07.40

>>175
空文字入れるのはできてる
ただベクターの生成は別関数が行うから引数に渡されるベクターにいくつ値が入っているか不明
だからマップ作成側で個数を意識する対策する必要あるよね？って話
ベクターの生成に関しては実際問題ない

>>176
try catchするしかないのかな
nullopt返そうとしたけど実装無理だったわ...

2017/11/29(水) 10:42:28.73

例外投げるかなにかしとけばよいって
ロジック的に要素数2未満はあり得ないし想定してないんでしょ？
余計なことする必要ないって、以降の処理が余計ややこしくなるだけだから
エラー処理が適切

2017/11/29(水) 10:50:41.36

あってはいけないことなら assert で止めてしまえよ

2017/11/29(水) 10:58:33.93

assertは良いがリリースビルドで消えてなくなるから
それがあってるかどうかだな
よほど条件に自信があればassert

2017/11/29(水) 11:00:19.45

複雑なことをせずに設計しなおせばいいんじゃね？

2017/11/29(水) 11:28:13.62

>>178
おいおい、例外をエラー処理以外に何に使うってんだよ

2017/11/29(水) 11:33:09.98

メッセージの通知に！

2017/11/29(水) 12:07:51.67

>>182
だから、エラー処理が適切だから
例外投げてエラー処理でもしとけば？と書いてあるはずだが・・・

ただこの手合い、例外投げて、それを受け取ったからと言って
リカバリーしてプログラムを再開できるかはわからないよなぁ
プログラム本体の状態を一切汚さずに(書き込まずに)
新規領域のみで何か処理をして
例外が飛んで来たら全てを無かったことにする・・・とか
例外でやる場合は例外安全を確保するのが結構面倒なんで
プログラムの末端から例外投げるのは最後の手段にしたい

だから「実際に実行してみないとエラーが出るかわからない」系のエラーが無いのであれば
早期の段階で入力データにエラーがあるかどうか精査して、エラーがあればその旨返して
以降はエラーが発生しない前提で処理する(ので巻き戻すことは考えない)
もし不慮のエラーが発生したら、バグであるからログ吐いて異常終了
可能なかぎり、なるべくこちらで行きたいわけで

**139** (ﾜｯﾁｮｲ 272d-eGxq) · 2017/11/29(水) 12:10:47.10

>>177
optionalを挙げたものだけど　惑わせたようで申し訳ない

insert 前にチェックして不正ならそもそもinsertしない設計を考えてました
結局 optionalを返す insert / find を自前実装することになるから
そんな面倒な事せずに素直にXXXで例外投げても全く構わないと思う

一応詫び代わりに書いてみたけど鵜呑みにはしないでください
C++17 例外なし読みやすさのためにautoなし
https://wandbox.org/permlink/rag4d7YPqwPKQpNq

2017/11/29(水) 12:13:09.20

182=184
同じ臭いがする

2017/11/29(水) 12:14:34.01

検査可能な事前条件はそりゃ呼び出し側の責務にしたいわな

2017/11/29(水) 12:52:35.24

>>177
> ただベクターの生成は別関数が行うから引数に渡されるベクターにいくつ値が入っているか不明
.size で取ればいいだけだろ
そもそも name=value のパース結果をベクターで渡してくると言うの設計もどうかと思うが

> だからマップ作成側で個数を意識する対策する必要あるよね？って話
そうだよ、その対策を>>175にかいたつもりだが...
もしかして
name=
と
=value
の両方とも vec[0] にしか入れてこないとかなってるんじゃないよね？
だとしたら生成部分を直さないとどうしようもないけど

2017/11/29(水) 13:49:04.14

ヴェクターノズル搭載。

2017/11/29(水) 14:47:34.47

色々とありがとう
最終的には呼び出しもとでtrycatchすることにしました

>>188
両方とも0 1の要素に値いれてるね

もう一個別件なのだけど
ファイルの存在チェックとファイルのオープンエラーについて教えてほしい

ある設定値は特定の設定ファイルが存在するにも関わらず読み込めなかったときに有効になるものとしたい
且つ設定ファイルが存在しないときもある
(設定する値が二つある。ひとつはkey=valueの形のvalue、もう１つは正常にファイルから値がとれたか否か)

ファイルが存在しないときはvalueの値をデフォルトで扱う必要があるので、
単純にファイルオープン処理を用いて一度で処理できなかった
(ファイルがなくて開けないのか、あって壊れていて開けないのか判断できないので)

そのため
statでファイル存在有無チェック→ファイルオープンとしたのだけど
タイミングが一致してないので刹那のタイミングでのファイル焼失を担保できないと言われている
どうすればファイルがなくて開けないのか、ファイルが壊れていて開けないのかを判断できますか

2017/11/29(水) 15:03:14.59

ファイルオープンの開けませんでした例外をキャッチしたらええやろ

2017/11/29(水) 15:30:10.25

keyにデフォルト値が存在するなら、最初にデフォルト値のmapを持つ。
ファイルを読み込んで存在したキーだけ上書き更新する。
だけでいいだろ。ファイル読み込まれなければ全部デフォルト値のままだ。

2017/11/29(水) 18:22:28.81

例外見ろよ
std::ifstreamならstd::ios_base::failureだからcode()の戻り値見ろ
何のために投げてると思ってるんだ

2017/11/29(水) 20:17:29.87

>>168
ゆとり死ね
お前は何も分かってないし、学ぶ知能もない

>>190
> 刹那のタイミングでのファイル焼失を担保できないと言われている
てかそいつに聞けよ。

課題として与えられてるのなら、そいつは「考えさせることに意味がある」と思っているのだから、
こんな糞上司に付き合ってられるか、と思ってないのなら自分で考えろよ。
ここで聞いているのは宿題の答えだけ写しているようなもので、全く上達しないぞ。

2017/11/29(水) 20:25:15.41

ファイル存在チェック→オープンがアンチパターンなのは常識だろ何言ってんだお前

2017/11/29(水) 20:31:50.13

相変わらず持論展開ウザ杉るの自覚してないな
アスペウンチ君

2017/11/29(水) 21:17:19.68

ハローワールド逝け