C++相談室 part147
■ このスレッドは過去ログ倉庫に格納されています
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part146
https://mevius.5ch.net/test/read.cgi/tech/1573094136/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://mevius.5ch.net/test/read.cgi/tech/1556142878/
■長いソースを貼るときはここへ。■
http://codepad.org/
https://ideone.com/
[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
STLつかうと一気に実行ファイルサイズが10倍に?！
環境によるだろ。
俺はBorland-C++5.6.2に -D_RTLDLL オプションを指定して、極力
ランタイムを使用するようにして使っているが、例えばstd::vectorを
使っても使わない時と比べ10Kほどしか増えない
すげえ。ダイナミックリンクしといてファイルサイズが増えないとかいってるよ。この人。
↑え？だってお前、普通ダイナミックリンクするだろ？
"ダイナミックリンク"す・れ・ば、ファイルサイズ**増えないです** 江添亮の本でstd::cout<<""にs付けろって書いてたんだけどsつけたらエラーになる >>657
久しぶりに笑う健康法ができてありがたかったんだよ
おーい芸人さんたち、アンコール！ アンコール！ >>664
#include <string>
using namespace std::literals::string_literals; とまあこのように、江添先生の本は、すべて理解してる人にしか理解できません。 幼稚園児が大学の図書館へ行っても読める本ないのと同じだな
無理しないで「ぐりとぐら」くらいから始めとけ 残念、俺は江添じゃない
興味のツボは奴と似てるとこあるけどね 普通の文字列リテラルが char 型の配列であるというのは (初心者には) 分かり難いので、
いっそ一貫して std::string 型で扱うというのは悪くない方針だと思う。
だけどユーザー定義リテラルという枠組みもそれはそれでだいぶんアレな仕様なんで、どちらにしてもクソだよな。 こんばんは、後藤です。
ところで ""s だけでは片手落ちな気がする
ちゃんと u""s みたいに文字コード指定しなかったら
string_literalsを使う意味ないような気がするんだけど
わしだけか >>656
関数で切り出してreturnしろカスが。 uがなかった時代でもなんとかなってたんだから意味なくはないだろ 江添本は初心者向けと謳っていながらこのくらいわからん奴は帰れみたいな意思を感じる 初心者に内容を理解してほしいんじゃなくて俺すげーってことだけ理解しろってスタンスだからな。
むしろ理解されると大したことやってないのがバレると思ってるくらいだろ。 C++はしたことがないが数学博士号のやつと高校卒業を一緒くたにするのが問題だろう
それぞれの学力で開始すべき章を設定するべきだ
できないとしたら著者の無能なので落胆することはない 初心者がC++に入り込まないよう防御壁として江添先生が存在するのではないか。 C++の道を行きたいなら、俺を倒してから行け。
ってことでは。 張り合ったら明らかにプログラム書けなくなるだろ。。誤誘導すぎるわ。 C++の前に立ちはだかる屈強な門番。
俺を倒せるものでなければ入門を認めぬ。 グダグダな C++ をグダグダじゃなく説明するのは無理だろ。
どの本を見たって少なからずグダグダか物足りないかどっちか。 まぁ、実際の現場だと、c++なんてちょっと便利なC言語としてしか使われてないよ
未だにcharポインタやmalloc乱立してるし参照型すら使われてない。
クラスなんて関数まとめるnamespace代わりだし ひと昔前にstaticおじさんの話がバズったことあるけど、
たぶん現実にはけっこういるんだろうな。 ちゅうか、C++ 使うなら charポインタは必須だ。
使いたくないなら 別の言語を使ったほうがいい。 Cのライブラリを使わない限り文字情報はすべてstringで済む
モダンC++の仕様はそういう範囲内での使用も許容している c++ではchar*は文字列とは関係ない場面でよく使う >>684
＞クラスなんて関数まとめるnamespace代わりだし
さすがにそれはダメだと思うが・・
そういう現場確かにあるが
>>688
とか言いながらstringは途中からnull終端を保証したりして、
結局Cの資産を無視できなかったという もともとc_strはnull終端されてた
それに合法的にnull文字を含むことが出来る時点でnull終端ではない >>684
私のことですね…
new をグローバルオーバーロードしたら、その中では malloc() するしかないですからね… >>693
> >>684
> 私のことですね…
> new をグローバルオーバーロードしたら、その中では malloc() するしかないですからね…
するしかない？
mallocはどうやって実装されてると思う？ >>693
おまえさ、何のために new をグローバルオーバーロードしてるの？
malloc でいいんなら、そんな必要ねえだろ
おまえアホか まぁデバッグの手法としてなくはない
ただその手のものは既存のものが腐るほどあるからそれ使った方がいい >>694
＞するしかない？
ええ、するしかないと思いますよ
>>695
＞何のために new をグローバルオーバーロードしてるの？
無論 delete と対になっているかどうかをチェックするためですよ、こういうのは自分では出来ていると思っていても時々お漏らししてしまいますからね
まあ、C++11 以降は手抜きして make_shared することを覚えてしまってずいぶんと時間が経ちましたが、それでも生ポを使うときは new/delete をオーバーロードしますね
https://mevius.5ch.net/test/read.cgi/tech/1434079972/51 line.143〜150 >>696
昔の borland c++ にはまさしくそのための、なんていうんだったんでしたっけ、そういうコンパイルスイッチがあって便利に使っていましたが、
今評価版を入手すると、それは clang ベースに変更されて、その機能がなくなってしまったんですよね… >>698
思い出した、bcc32 CodeGuard でしたっけ >>697
それなりにプログラマ経験あるんだと思ってたけどmallocの中身知らないとはね
別にメモリ確保のsyscall直接使ってもいいんだぞ
むしろnewをリプレースしたい場合ってページ単位で処理したいときとかでしょ
ちなみにこれはデバッグで使うのも有用だぞ
unmapしてるところにアクセスしたらその時点で例外で止まるから原因特定が容易
まぁそんなの自前でやる前にValgrindでも使えって話だけど >>697
アプリケーションの層ではアロケータを書く機会はまずないから
やったことないのは別にいいけど、
さすがに new の本質はメモリの割り当てだってのはわかってて欲しいわ。 >>700
＞それなりにプログラマ経験あるんだと思ってたけどmallocの中身知らないとはね
専ら win32api でやっているので、：：HeapAlloc(：：GetProcessHeap(), ...) とか ：：HeapFree(：：GetProcessHeap(), ...) だとは考えていましたし、数年前はそう置き換えていたこともありました。
＞unmapしてるところにアクセスしたらその時点で例外で止まるから原因特定が容易
これは初耳です。よろしければ、もう少しキーワードだけでいいので羅列していただけませんか 関数で切り出すのは入出力がはっきりするというメリットはあるが
ループの内と外の依存性が高い場合に内を無理矢理関数分けすると
シグネチャに入力引数と出力引数（参照渡し）がぞろぞろ並ぶことになって
それはそれでお勧めしない
（関数の意味も不明確になりがちやし… >>702
そうだよwindowsならそのあたりだよ
あとVirtualAllocね
> ＞unmapしてるところにアクセスしたらその時点で例外で止まるから原因特定が容易
> これは初耳です。よろしければ、もう少しキーワードだけでいいので羅列していただけませんか
new/deleteのたびにページ単位で確保・解放するんだよ
それこそVirtualAllocで
だから重いよ
そうするとdangling pointerでヒープ壊される問題があった場合、
壊しにいったら即セグフォルで止まるからデバッガつなげれば犯人特定できる >>686
そんな職場は大変だぞ
構造体だからって、triviallycopyableを満たさないクラスをわざわざvoidポインタに格納して、memcpyしたり
クラスをわざわざmallocしてコンストラクタ、デストラクタ飛ばしたり
const属性をキャストでわざわざ消して値変えられたり ベターCなどとほざく連中がいかに馬鹿で愚かで有害かがよくわかる まあそんなやつは C もまともに使えてなかったりするんだけどな。 中途半端にc++を持ち込んで現場を荒らすやつもいるからね
>>706 の状況はそういうところで見たことある
別にc++が書けるのがえらいわけじゃない
質の良いプロダクトをきっちり仕上げられる奴がえらい
まわりがc++わからないメンバーならcで書くか、
c++が必要というなら十分にチームでトレーニング行ってからだ C から段階的に学んでいける (業務を止めずに) って D&E には書いてあるけど、
今の C++ じゃもう無理だと思うわ。 C++ は C++ としてそこそこの訓練はいるよな。 はちみつ餃子がでてくると、どうもこんな時間に腹が減ってきていかん >>706
それは問題。
でも、STLべったりのC++は Cとの書き方の乖離が激しすぎて、もはやCの冠を被ってほしくない。 >>714
関数切り出しできないと大変だね。(特に周りの人たちが。) >>716
CはCらしく、C++はC++らしく使えばよろしい
CをPascalっぽく使うやつとかすげー迷惑なのと同じ テンプレートメタプログラミングはC++らしいとも思うけど全然別の言語になっている気がしないでもない >>705
情報ありがとうございます
::VirtualAlloc() 系は書いてあることが難しい上に、ばっちゃの遺言「::HeapAlloc() を使え」もあって敬遠していましたが、ここで教えてもらったのもなにかの縁だからデバッグ用に試行してみようと思います
win32api の criticalsection と signal でやっていた（何かがまずくてstarvationに悩まされていました）のも
C++11 になって pthread が大幅に規格に取り込まれた以上、
C++11 の上からの mutex・cond 派に切り替えようか、とか、C++11 になってスタイル変更を考え中です >>717
ループを抜ける為に関数を分けるようなアホと一緒に組むと大変だ 確かに大変だね
if breakしてる複合文を関数にするときにreturnとか言い出すやつは
longjmpだろうがって >>720
実際、別言語だと思う。
C++はtemplateや演算子のオーバーライドを使えば、ほぼ別言語をみなせるようなものを上に載せられる設計になっているので。
STLを使いまくるプログラミングの書き方だと、もはやCとは何の関連性もなくなってしまっている。 >>723
ループ抜け出すぐらいでそんな苦労するようなコードになってるなら
関数で抜け出すのが当然だろカスが。
いくら脳みそ足らなくてもgoto擁護のために無理筋言ってるってことにそろそろ気づけ。 ネストするなら別のプログラムに切り分けましょう。
シェルから呼び出せばいいのです。 >>725
もともとCってマクロで何でもやりたい放題の言語だぞ
http://www.pro.or.jp/~fuji/computerbooks/c/c.modula2.html >>727
｢gotoダメ！絶対！教｣の戒律を破ることじゃないかな。きっと身を裂かれるほどの苦しみなんだろうw いったん収まったと思ったら
また goto の話開始してて草
アスペ特融の拘りと言われても仕方がないな gotoの話で叩きのめされたやつが話題を変えたいのはわかったよ(ﾆﾔﾆﾔ >>729
たしかにCもマクロを使えば結構何でも出来る。
だが、マクロを多用すると分かりにくくなるとも言われていたし、使い方によっては、ソースコードが全く別言語のようになってしまうことも知られていた。
それと同様の現象がSTLにおいては起きる事態になってしまっている。 >>734
なってねえよ
おまえさんにはSTLがIOCCCに見えるのか
慣れの問題と言いたいがおまえさんは極端すぎ
一種の病気だ >>736
STLの作者は、自分では分かり易くしようとしているようでいて実際には逆に分かりにくくしてしまっている。 STLは神がかってるけどな。
あの時代によく設計できたな。 >>735
自分で好きなようにプリプロセッサを実装すればいいんじゃね？ >>737
その分かりにくいの主語は、世間一般ではなくお前個人なんだろ。 >>738
だよな
Cではmemsetやqsortにvoid*というリスキーなことをせざるを得なかったのを
関数テンプレートで型情報をきちんと面倒見るようにできたし
リニアサーチがない等のCライブラリの不備も解消した
そこに気付かないやつはプログラマとしての資質を問われる >>738, >>742
あのな、STLは設計構想から含めると十年から数十年かかってんだよ
それだけよく考え抜かれたものが優れてないわけがない
これ何回も書いたんだけどな
「最新仕様追ってる俺スゲー」したいだけの奴の希望的観測はもうこりごりだわ 最新仕様とか書いたらSTLが最新？とか言われそうなんで先に言っとくけど
マクロ(プリプロセス時メタプログラミング)を貶してテンプレートは持て囃すのはダブスタってことなんで誤解なきよう ただ俺としては右辺値参照の発見にノーベル賞を授与するべきだと思うんだよな。
これ人類史上でも大きな発見じゃないかと思うんだよな。 >>743
742だが、おまえさんは俺が何がわかっていないと言いたいんだ？
どっかの馬の骨が何回書いたかなんて興味ねえが
当たり前のことをドヤられる意味がわからんぞ STLにノーベル文学賞なんてオサレだと思わないか。 >>746
同感
そもそも左辺値参照にconstをつけたら右辺値を指せるなんて
珍妙なルールが招いた禍根を何とかする苦肉の策が右辺値参照だかんな
今ふり返って見るとconstなしの左辺値参照でもテンポラリを束縛できて
それを禁止したい場合のキーワードがあればよかったんだと思う >>745
互換性を失わない形で性能にも寄与するのはすごい思い付きだと私も思った。
スマートポインタが充実する方向で良くなると思っていたので、
まさか参照を区別する形でコピーを避けるとは思いもよらなかった。
だけどなぁ……。 結局は後付けなんだよね。
互換性を捨てられないという制約の中ではこれ以上ない発明ではあっても、色々と不満はあるよ。
ムーブ自体は言語のコアに組み込まれた機能ではないから
ムーブ後の抜け殻をうっかりいじってもコンパイラは黙って通しちゃうし。
ムーブできるようにしようとすると実質としてはポインタの入れ替えになるから、
各クラス向けにカスタマイズしたスマートポインタを書いてるみたいなもんだ。
本来ならそんなのコンパイラの最適化で頑張ってなんとかすべきことだろ。
言語処理系の敗北の証にすら見える。
いや、良いとは思ってるんだよ。
間違いなく rvalue 参照は素晴らしい発明で、 C++ をより良くした。
でもまあいいことばかりでもないよねっていうちょっとした愚痴。 構造体/クラスを戻り値にするっていう発想が無かった時代からのつぎはぎ拡張だから そもそも構造体を=でコピー出来るのが始まりだからな
配列は=でコピーできないのにな
その辺一貫性なかった>C言語 >>754
配列は (その先頭要素を指す) ポインタに型変換されるルールを入れてしまったので
それと辻褄の合う形には出来なかったんだと思う。 もしCが
構造体を参照するとポインタ相当になります
引数で渡すときも&つけなくても勝手にポインタになります
コピーするときはmemcpyしてください
って仕様だったらC++はどうなってたんだろうな
色々まずいことになるのは確か ↑ただ、モダンな言語はむしろそういう仕様なんだよな
その代わりGCがあるが
しかし、それはそれで不便なのであった >>744
おまえさんは
#define STR char* //と、
typedef char* STR; //の違いが
わかってなさそうに見えてしまうが
違うよな？
コンパイラでないものによる字面の読み替えと
コンパイラによる意味の読み替えを
区別するのはダブスタか？ >>758
そういうのじゃなくて、>>734に対して>>736書いたよな？
慣れ、ってのはわからんでもないがSTLの成功にはっちゃけて何でもテンプレートでどうにかする
今の風潮は俺もどうかと思うので。
もちろんマクロでメタプログラミングするよりは遥かに楽だけど、方向性としては同じようなもんだろ というかVCだとプリプロセスだけ済ませたソース見れるから、
時にテンプレートよりデバッグ楽かもしれない >>759
質問に答えてないな
字面の読み替えは評判悪く
意味の読み替えが広く受け入れられているのは
ダブスタか？ ■ このスレッドは過去ログ倉庫に格納されています
