【初心者歓迎】C/C++室 Ver.101【環境依存OK】 [無断転載禁止]©2ch.net
■ このスレッドは過去ログ倉庫に格納されています
エスケープシーケンスやWin32APIなどの環境依存なものでもOK。
ただしその場合、質問者は必ず環境を書きましょう。
◆ソースのインデントについて
半角空白やTABでのインデントはスレに貼ると無くなります。
そのため、アップローダーに上げるのも手ですが直接貼る場合は、
全角空白か に置換すると見栄えだけはよくなります。
【アップローダー】(質問が長い時はココ使うと便利)
http://codepad.org/ (コンパイルもできるし出力結果も得られる[]privateをチェック)
http://ideone.com/ (時間帯によってはcodepadが重い事があるのでここも利用)
前スレ
【初心者歓迎】C/C++室 Ver.100【環境依存OK】
http://mevius.2ch.net/test/read.cgi/tech/1478440682/ >>485
リッチな環境が望みなら、
Visual Studio 2017。
貧乏人は
MSYS2とテキストエディタ。 意見が割れそうだけど、迷うくらいなら、winならvisualstudio, macならxcodeでも使ってみては
取り敢えずデバッガが手軽に使えれば何でもいい気はする >>486
>>487
ありがとうございます！
visual studioでやります！ 学生時代と就職当初はC、現在はJavaとCsharpを主にやっています
最近C++を独学で勉強しようと思って調べはじめたした
印象ですが、これは言語作った人はどうみても天才で変態なんじゃないかと思いました
言語仕様としてはJavaなんかの方が広いかも知れないけど…
奥深さというか、底無し沼な予感というか最強なのでは？との印象を持ちました
２ちゃんねるなんかで見るかぎりあまり人気のある言語では無さそうですが、これはJavaなんかでも同じでWeb屋さんとかが言ってる気がしました
以上が自分の現時点での感触なのですが、大きく外れてはいませんでしょうか？
釣りとかでは一切ないです さいきょーだとかの漠然とした印象とか持つんじゃなくて、それぞれの言語の長所短所とか、どういうケースで使われているとか、そういうのをちゃんと調べたら？ C++は言語ヲタク的には際限なく楽しいけどそれだけ
今直ぐ実現したい何かがある時はpythonかphpで済ませちゃうｗ
お仕事の人はそんな自由ないだろうからガンダムしかない >天才で
ものは言いようだな
複雑な概念を分かりやすく整理できる人間はこんなUNKO言語は作らない >>486
意味わからん
Community Editionは無償だぞ C++は天才の言語と言うよりは、無駄に意識高い人の言語。
関係ないけど京都出身のプログラマはC++使ってる奴多い印象。
一見さんお断り的な文化が合ってるんだろう。 >>496
C++11later になってからいっそうひどくなりました。テンプレート周りはもうわけわからん、翻訳じゃなくきんとした和書はでないものですかね >>495
きっとライセンスのことなんて考えたことないんだよ まだWindows XPを使っている人が居るかも知れないから。 まぁ、島根だか鳥取だかの出身のプログラマはruby大好きなイメージと同じだよな。 c/c++の簡単版があればいいんだが
rustはあまりにも機能が多い スレチだけどオープンソースのAlgol68ってあるんだな C++はベターCとして使うのが最も生産的だと思いました。 auto使ってる奴見るとイタイ奴だなと思いました。 別に痛い奴だと思われるとガソリン代が上がったりするわけじゃないからね 型名 変数名 = ... だとデコボコするんで、ついつい
auto 変数名 = ... をズラズラっと並べたくなる
でも、書き終わってから読み直すと、あれ？逆に読みにくい？とか
どーでもいいとこで悩んでしまう C# の var 論争再び w
老害ってほんと進歩しないのな 年齢関係なく、単に馬鹿ほどvar好き。論理的思考ができない。 >>514
これはガチなの？実はアンチパターンで釣られましたねってことはないだろうな？ｗ
FruitFlavor flavor = fruit.GetFlavor();
var flavor = fruit.GetFlavor();
前者の方が読みやすいような気がしてしまう。
今時ならIDEのアシストあるし関係ないか？って気がしないでもないけど
考えるほど分かんなくなる〜 C++ 標準委員会のドワンゴ江添は、職務質問の手荷物検査を拒否したら、
警官10人に、現場で1時間半以上、拘束されたらしい
捜査でもない、任意の行政処分なのにw
それで東京都を訴えた >>517
そう言う単純な奴ならたいして変わらんので>>515みたいな変化を嫌う老害はvarを使いたがらない
Dictionary<string, Dictionary<string, string>> M = new Dictionary<string, Dictionary<string, string>>();
とか使い始めたら同じの２個もいらんやんってなる ここ数年、どのスレで論破されるとキレて老害連呼しだす人がいたが、
おそらく、ID:Rd2CDMDC は同一人物だろう。 右辺にクラス名が現れるときだけauto使う派
FruitFlavor flavor = fruit.GetFlavor()
auto unko = (Unko)GetFuck() restrictなんかもそのうちdstのsrc言及有無、srcのdst参照有無を縛る修飾に成るんだろうな >>525
同意
関数が何を返すか分かるから右辺が関数の場合でも構わないけど
関数の戻り値にauto使う奴らは殲滅したい タイプが面倒というPGはコメントも書かないし、単体テストも端折るし、
他の人が書いたソースにバグがあるかどうか真剣に読まない。バグ製造機。
プロジェクトにこういう人が一人でもいると、全体の品質が下がるばかりか
全体の士気まで下がるから厄介。態度の悪さを指摘すると老害連呼のウイルスプログラマ。 >>532
他人のコードのバグを見つけるとか極悪じゃないか？ >>533
えっっ？
最近はコードの机上検証はしないって？ >>531
ちょっと聞きたいんだけど、
std::vectorをprivateメンバに持つクラスに、vectorのサイズを返すメンバ関数を作る場合、
返値の型はstd::vector::size_typeにするの？
それとも適当にsize_tとかで返しちゃう？
前者だとprivateメンバの型が外側に漏れてる感じが気持ち悪くて嫌だし、
後者は型が違うのが嫌だから、
autoで返しちゃいたいんたけど、殲滅されるべきなのかな >>541
sizeof(int) == 4 && sizeof(size_t) == 8という環境がある。
intは符号あり、size_tは符号なし。 >>544
もとからintならあれだが、いちいち別の型であるintにキャストする積極的な理由はなんだ？ intをオーバーする心配をするなら
size_tをオーバーする心配も
メモリが足りない心配も
処理が遅すぎて使い物にならない心配も >>546
そうじゃなくてわざわざ型変換する理由は何？ >>542の環境の場合、多くの場合ムダにデカい変数を扱うことになる
もちろん、巨大なデータを扱う可能性があるならムダではない
と同時に、>>546も心配する必要がある >>548
何と何を統一するの？
int n = static_cast<int>(v.size());
という面倒な表記？それとも
int n = v.size();
とかいう-Wall で死ぬ表記？
auto n = v.size();
って書かずにキャストをどうしてもしたいのはなぜなのか クラスを使う人が、内部的にvectorを意識する必要もないし、それようにわざわざ専用の型を使う必要もない
intは他の処理でも多く使われているので、使う側からすれば一番変換が少ない
巨大なデータを扱う処理に関する記述で、size_tで統一してるならそれでも
符号無しで統一してるのも考えにくいけど >>550
そういう面倒なことをクラスのユーザーにさせないため ID:mWX/padLみたいな前近代的なマが早くくたばりますように >巨大なデータを扱う処理に関する記述で、size_tで統一してるならそれでも
符号無しで統一してるのも考えにくいけど
STLのsizeはsize_tで統一されてんのにお前が乱してるんだろｗ >そういう面倒なことをクラスのユーザーにさせないため
どんな理屈だよ
vectorをラップしたクラスにat()やoperator[]を設けたらint指定でアクセスするのか
ユーザは負数に成り得る変数を注意しながら使えってか
何のための型だよ >vectorをラップしたクラスにat()やoperator[]を設けたらint指定でアクセスするのか
あたりめーだ
真人間ならラップは手段であって目的じゃねーから
>ユーザは負数に成り得る変数を注意しながら使えってか
バカ乙
計算をミスらないことと演算がオーバーフローしないことだけ注意すんだよ >>554
STLを意識させないためにクラスで包んでるんだろうに
意識させるならパッケージング失敗では？ >>556
>あたりめーだ
>真人間ならラップは手段であって目的じゃねーから
ごめん、意味分からん
>計算をミスらないことと演算がオーバーフローしないことだけ注意すんだよ
だから、わざわざvector::size_typeなものをintに変換する必要がないじゃないの
0からmax_size()までの範囲なんだからさ >>557
だからtypedefやusingを使うって話だよ vectorから他の実装に変えたらクラスの仕様も変えるのか？ >>559
いちいちメンバ関数ごとに型を定義する？
本気で言ってるの？ クラスやメンバ関数ごとに型を定義したら、
それらの数値を複数用いて演算した結果はどうすんの？
まさかauto？ クラスが値に関して責任を持つ
当たり前
クラスが値や型に対して責任を持たずにただ値をスルーパスするだけの糞クラスなんかは
ローカルで個人で使う物だけにとどめておきな ただメールを転送するだけの役に立たない糞上司と同じ >>561
?
クラス内に
typedef typename std::vector<T>::size_type size_type
でいいんじゃないの >>565
vector以外のデータは無いっていう前提？
または、クラスで扱うサイズをすべてそれで統一？
仮にそうだとして、
じゃあ別のクラスのsize_typeや他の型と演算した結果はどういう型にするつもり？ vectorをそのまま継承した程度のクラスなら、
当然vectorのインターフェースを保つべきと思うよ
今回はvectorはただのデータのひとつ 実装上、たまたまvectorを使っただけ
もしかしたら変えるかも
といった、ごく普通のクラス設計だと仮定した場合の話 てか普通コンテナのサイズはsize_typeでとるだろ
別のクラスのsize_typeもsize_typeで取れ
勝手にintにキャストしてwarningまみれにすんな死ね コンテナはただのクラス内のデータのひとつ
内部の設計事情を外部に出す必要はない >>566
>vector以外のデータは無いっていう前提？
実装を替える必要があるってのは後で作り変えるって意味？それって設計の問題で関係なくね？
静的動的問わずポリモーフィズムするって意味なら最初からそういった設計をするでしょ
今回の話はvectorをラップしているクラスの話でしょ、何で関係ない話を持ち込むの？
>または、クラスで扱うサイズをすべてそれで統一？
size_typeで統一されるならそれでイイんじゃないの？君の言うintに統一と何ら変わらない
それなら内包しているvectorと同じsize_typeを使った方のが余計な記述も減るしバグも減る
>じゃあ別のクラスのsize_typeや他の型と演算した結果はどういう型にするつもり？
それって君の言うint統一でも同じじゃね？
何か話がどんどんズレていない？ お前はそれでいいんじゃないか？
intで出せばいいじゃん
他のコンテナと整合取れないから使われないだけで、法に触れてるわけでもないし >>573
私の書き込みの前提は >>568 >>569
クラスの中にvectorやlistや他のコンテナのデータもあるかもしれない
それぞれが、コンテナ独自のサイズの型を定義してるかもしれない
コンテナが返すサイズを加工して返すかもしれない
比較的大きなクラスの話
ただvectorを包んだだけなら当然vectorのインターフェースを継承すべき >>575
何その後出しの仮定
取り敢えず、君が幾らでも解釈を広げていくなら話す意味ないわ
それにそのクラス使いたくないわ
絶対何もかも詰め込んだ糞クラスだと思うわ ■ このスレッドは過去ログ倉庫に格納されています
