C++相談室 part134
■ このスレッドは過去ログ倉庫に格納されています
次スレを立てる時は本文の1行目に以下を追加して下さい。 !extend:on:vvvvv:1000:512 C++に関する質問やら話題やらはこちらへどうぞ。 ただし質問の前にはFAQに一通り目を通してください。 IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。 前スレ C++相談室 part133 http://mevius.5ch.net/test/read.cgi/tech/1511509970/ このスレもよろしくね。 【初心者歓迎】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 reserveしてback_inserterでcopy >>648 insertはサイズチェックしてるでしょ。 >>649 iteratorを2つ受け取るタイプのinsertなら意味あるんじゃね? >>650 resizeは不味いだろ。 >>652 アンカしくった。 サイズチェックの指摘は>>647 向け >>652 insertの中で追加数数えてreserveと同じことしてるでしょ まさかループで一個ずつ挿入なんて実装はあるまい >>655 失礼。挿入位置のiteratorもあるから、3つ受け取るタイプの誤り。 cpprefjpの任意の式によるSFINAEの頁でdecltype(a + b, bool())と記載されているコードがあるんだけれど、 このa+b, bool()はラムダ式? 該当頁 https://cpprefjp.github.io/lang/cpp11/range_based_for.html >>657 カンマ演算子とdecltypeでコンパイル時に評価される decltypeの中身を左から順に評価し、結果は一番右の型が帰る この場合はa+bの型が評価出来ればbool、できなければSFINAE >>657 >a + b a + bが可能かどうか調べる >, 次の式を評価する >bool() bool型の初期値を返す つまりdecltype(a + b, bool())はa + bでSFINAEをしつつカンマ演算子でdecltypeにbool型の値を与えて返り値の型をbool型にしている decltypeで,も使えたんですね。一番右の型が帰るということはdecltype(a+b,a-b,a*b,a/b,bool())とかしてもよさそう。。。 自分ではその機能を説明してるページを見つけれませんでした。 ありがとうございます。 >>660-661 それで良いのか。 いいこと知った。 いちいち enable_if をしとったわ。 >>656 a.reserve(a.size()+b.size()); a.insert(a.end(),b.begin(),b.end()); こんな感じのことをやるのかと思ったんだけど、これ意味ないでしょ? >>664 declとはdeclareの略であることを考えると a.reserve(a.size()+b.size()); copy(b.begin(),b.end(),back_inserter(a)); >>665 random iteratorの場合の特殊化実装がありました。ごめんなさい >>662 decltype comma trickでググれ まあoperator,()が定義されてるとまずいんだけどな インスタンスにdeleteかけたとき、メンバ変数が破壊されるのとデストラクタが実行されるのはどっちが先? 今書いてるコードがデストラクタでメンバ変数アクセスすると落ちることがあるから、破壊されるのが先なんだろうか? >>671 原則としては構築の逆順って覚えておくと間違えない。 >>671 delete this; とかしてませんか、これは基本的に避けたほうがいい >>673 に同意。確保と破棄は生ポインタを触らずに自動化した方がいい。スマートポインタとかコンテナとか。 二回deleteを避けるためにポインタにNULLを代入する技もある。 そろそろNULLは駆逐してnullptrに移行させたい >今書いてるコードがデストラクタでメンバ変数アクセスすると落ちることがある へ〜んなの ていうかメモリを壊しているかすでにdeleteされた死骸を再deleteしてるとしか、 >二回deleteを避けるためにポインタにNULLを代入 OpenCVのC言語インターフェースのやつ、 C++勉強中の者です。 http://codepad.org/C8t9k4fD ソース自体をプログラムに読み込ませると #includ で止まってしまいます。 Cのfgets()のようには使えないのでしょうか。 >>677 According to the C++ reference http://en.cppreference.com/w/cpp/io/basic_istream/getline getline sets the ios::fail when count-1 characters have been extracted. You would have to call filein.clear(); in between the getline() calls. >>678 区切り文字を読まないとfail状態になってそれ以降は失敗し続けるので止まってしまうということですかね std::getline()は読み込んだ文字列に改行文字を含めないから 行末まできちんと読んだのか 文字数カウントのせいで読み込みが行の途中でぶちきれたのか 直ちにはわからないといいうアホウな仕様 判別には結局std::basic_istream<T>::unget()の助けが要る C++標準ライブラリのうちストリーム関連だけは腐っているからC言語のを使いなしゃれ ※ 個人の感想です 訂正 △: C++標準ライブラリのうちストリーム関連だけは腐っているからC言語のを使いなしゃれ ◎: C++標準ライブラリのうちストリーム関連だけは本当に腐っているからC言語のを使いなしゃれ 入出力はCもC++もクソまみれだからなぁ ちょっとコンソール出力を整形しようとして、あの肥溜めのクソくだらない落とし穴地獄にいちいち付き合わされた結果 プログラミングそのものが嫌いになる人達が山のようにいるのが本当に残念だ 自分が知ってる昔はいっぱいいたけど 最近だとスクリプト言語から先に入るから減ってるのかね? オブジェクトの外部表現を型ごとに定義できる iostream は悪くない設計だと思うんだけどなぁ。 ローカライズに向いてない。 打鍵数が倍増どころじゃない。 モダン言語はみなprintfライクだしねー printf()は便利ではあるが桁を揃えて出す時に面倒になることもある。 特にこの頃は UTF-8 で漢字混ざりだと文字幅とバイト数または文字数が一致しない。 そもそもそんなものの一致をあてにすること自体が間違いかも知れないが、Unicode には一応 HALF WIDTH, FULL WIDTH 等があるんだから何とかしてこれを生かした フォーマッタが欲しいところではある。 >>672 >>673 あるクラスがあって、その中でスレッド立ててるの それでクラスのデストラクタが呼ばれたら、メンバ変数のスレッドポインタをつかってスレッドcancel->joinってやろうとしてて それでjoin呼ぶあたりで落ちるんだよね 作られた逆順ってことはデストラクタのほうが先に実行かな?それだとメンバ変数はいきてるよね streamはコンソールの入出力のためだけにあるわけじゃないから つーてもcoutだってsetw/setfillはあんまり使いやすくないしなあ operator<<をユーザー定義できるのはありがたいけどね >>688 デストラクタの実行中はそのクラスとその派生元クラスのメンバ変数はまだ使える 必ず落ちるならデバッガでバックトレース見てみたら? 別の原因に見える まずデストラクタじゃなくて普通のメンバ関数で明示的に呼んで止めた時に大丈夫か確認してはどうか pthread_cancel はいろんなことがよく分かっている人しか使ってはいけない >>685 「<<」と「>>」の2種類しか用意できんやんけ それらを表示と入力に割り当ててしまえば結局シリアライズのための固有なメソッドなりインターフェースなりを別途作らねばならんぬ、 そもそもの構想からして頓挫してゐる、 頓挫してゐるのだ…! >>694 表示用とシリアライズ用はストリームの性質で切り替える筋合いのものだろ? シリアライズ用のストリーム型を用意してオーバーロードすればいいんじゃね。 ちょっなんで数億年の生物史史上はじめて ようやっとSTDINとSTDOUTとSTDERRの3種類に世界が抽象化されたストリームという概念|を 細分化するという元の木阿弥にしますか;; 藻前は some_command | tee result.txt > some_file.bin とかいったパイプやリダイレクトを表示専用とかシリアライズ専用とかに分けたいのかっていうか、 >>696 お前は何を言ってるんだ。 ここで言ってるストリームは C++ 用語のストリームだぞ。 「ストリーム『型』」ってわざわざ書いてるんだからわかれよ。 下位レイヤでは好きなところに繋げればいい。 streamとstreambufの違いを理解しよう 要するに std::basic_ostream を継承した何かを作ればいいんだ。 ストリームはもう捨てたほうが良いぞ。 おじさんからの警告だ。 便利そうに見えて便利に使えない それがstream >>696 カンブリア紀からオルドビス紀にかけて行われた抽象化は 今でいうインターフェイスの考え方で、当たり前だが インターフェイスを継承する実装クラスは無数にあってよい そういうのは元の木阿弥とは言わないぞ >>696 さっき >>698 で説明した C++ の話題を置くとしても、 (まあ C++ スレで C++ の話題を置いちゃうのはどうかと思うが) 標準入力、標準出力、標準エラー出力のみっつしかないってことはない。 エラー出力をリダイレクトするときに 2> って書くの、どういう意味だと思ってる? 2 はファイルディスクリプタな。 デフォでオープンされてるのが 0, 1, 2 ってだけで、やりたければ 3 でも 4 でも使っていい。 >>705 空いているディスクリプタが使用されるとしても、自分で特定の数字を指定してディスクリプタにすることはできなかったんじゃなかったかな? >>706 失礼、dup2() というのがあったね… coutがSTDOUTにつながってるだけでここは何につなげてもいいということ streambufの中身はただの配列でもいいし、アプリケーションのロガーでもいいし、循環バッファでもいいし、通信のポートでもいい シリアライズするときはバイナリ表現にしたいし ログするときは文字列表記にしたいし >>709 だからそれはストリームオブジェクトの型で切り替えろって言ってるんだろうが それを嫌だって言ってんだよ バイナリの読み書きは write() だの read() で十分 read なり write なりを「使う」のは別にいいよ。 それを C++ 上でどのように抽象化すればいいかって話なんだから。 そういうレイヤの違う話を混ぜ込んでくるなよ。 そこで新しい型を設けてまで << を使う意味がない cout にバイナリでシリアライズするときはどうすんの? size_t serialize(const T& t, ostream& os) とかを各型用に書く方がマシ バイナリでシリアライズするに際して 別の型のストリームオブジェクトを作ってまで << だの dec だの endl を使えるようにすることの利点を説明して欲しい 例外を除いて operator<<()は書式化出力 write()は非書式化出力 なのでバイナリを出力するときはwrite()を使うべき >size_t serialize(const T& t, ostream& os) シリアライズのような複雑な操作をするときはこれは悪い選択じゃない というかstreamそのものを放り込むのはたまに見かける >>715 書式化 (formatted) ってのと、結果がバイナリかというのは直行する概念だよ。 シリアライズってのはオブジェクトのバイト列をそのまま出力することじゃなくて、 バイナリ形式の特定のフォーマットにして出力することだろ。 それは書式化って言うんだよ。 >>714 マニピュレータを使える意味はないかもな。 使えないように定義することも出来るし、意味がないなら使えないようにしておくべき。 ここでは抽象化の話をしているんだ。 出力先が人向けのテキスト表現であるか機械向けのシリアライズ表現であるかによって 書き方を変えなきゃならない、相手を意識しなきゃならないというよりは、 相手によって自動で切り替わって欲しいってことなんだよ。 意識しなくていいデザインってのは意識しにくくなるってことと表裏一体だから、 見えなくなるのが気にくわないってのならわかる。 >>719 スマソ。 >>717 の直行は直交の書き間違いやね。 無意味な処理が嫌だとか言っておきながら ここでは無駄の塊みたいな方法を勧める アホですね >>721 俺は一貫して抽象化の話をしてるつもりなんだが。 プログラマの意図を表現できる書き方をすべきって話をしてんの。 無意味な処理をしろと書いてあるのをプログラマの意図として読み取っていいのか? そうじゃないだろう。 C++ がせっかく用意しているライブラリを活用するのが無駄なのか? そうじゃないだろう。 ハッキリ言ってストリームは蛇足だったわ。 廃止したほうが良いわ。 Boostもそうだけど、有り余るC++のパワーをカッコよく使いこなそうとしてやっちまったみたいな。 もうちょっと使う側の立場にたつべきだな。 黒魔術だなんだ言って楽しめないようではC++は向いていない 蛇足ねえ。。。 禿本1stでoperator overloadのデモ用に作られたサンプルなんだが そういうのは後で取って付けた存在といえるのか? 業界全体としては奥の深さを求める人(求道者)を一か所に集め留めるのには非常に有益な言語 そのうちAsioやRangeあたりも標準化されるだろうし もうその方向に突き抜けてほしい 使いやすい言語なんか他にいくらでもある 具体的にどういうときに不便なのか語れよ。 使いにくいってだけじゃ何にもわからん。 C++に関しては慣れてない人がそう言ってるだけだから >>726 どの資料だったか覚えてないけど、演算子オーバーロードに関して 先生は「元の演算子の意味とかけ離れた挙動をさせるのは避けるべきだ」 みたいなことも書いてるよな。 まぁ、原則は指針であって絶対の規則じゃないわけだけど、 << >> をビットシフトからストリーム入出力に振り替えておいて どの口で言うか、このハゲッー! とか思ったり。 >>731 ストリームのような周知の事実になっているものはそれには当てはまらないでしょ >>731-732 まああれくらいのものになると、オブジェクトに追加で突っ込んでいくような動作が「元の演算子の意味」になっちゃってるよな。 そんなことより C++20 に入る予定のカレンダーでは日付を 2018y/mar/22 とか書けるらしくて、 これはさすがにクソやろ……。 これもいずれ普通に受け入れる気持ちになるだろうか。 >>733 既にfilesystemのpathが/で階層作れるから current_path / "aho" / "baka"みたいに C++の演算子は連想ゲームだ >>731 あの頃の禿はreverse_iteratorなんて思いもよらず operator+が減算の動作をすることを否定してたね >>733 日付の表記は何種類かあるし年/月/日でも日/年/月でも表せるなら結構便利だと思う。 >>733 標準に「日付を表す型」みたいのが追加され、 それ用リテラルの接尾語(のひとつ)が ""y で 2018y は2018年を表す、 さらにこの型では / は日付要素を区切る演算子としてオーバーロードされてる。 …といった感じか? 確かに虚心坦懐に / を見れば、割り算のコンピュータ向け代用記号だけでなく 日付の区切りや、ファイルシステムの階層区切りでもあるけど。 こんだけ演算子は深いのになぜか未だに[]は引数を一つしか取れない 「静的」、「動的」というのがよく分からないのですが、詳しく書いてある本はありますか? ヒープ領域がどうたらとかいうのもよく分かりません。 スタックとかいうのもよく分かりません。 詳しく解説している本を教えてください。 ロベールのC++の本を読んでいて疑問に思いました。 >>737 > …といった感じか? そんな感じらしい http://d.hatena.ne.jp/yohhoy/touch/20180322/p1 日本だと基本 年/月/日 しかないしソースコードに 睦月、如月、弥生 なんて書く奴はいないからいまいち便利さがわからんけどあちらの人にとっては便利なんだろうか ポップとプッシュの概念もよく分かってないのでは http://www.cc.kyoto-su.ac.jp/ ~yamada/ap/stack.html これが分かって来るとC++に於けるバッファオーバーフローBOF攻撃の仕組みが分かって来る 五曜は対応してくれると有り難いかも知れないけど 他はいらんな >>740 C/C++ のメモリ構造について、になります。 これは基本的な事項で、初級を脱するためにはぜひとも必要な知識なんですが、 そのわりにあまりに解説されることがないような気がします 適切な説明がないものか… >>740 まず、メモリの管理方法として 1. スタックエリア、に格納するやり方 2. ヒープエリア、に格納するやり方 の大きく分けて二通りがあり、 2. ヒープエリア、二格納するやり方について 2-1. 「静的」:static キーワードを使うやり方 2-1. 「動的」:malloc()/free() または new/delete を使うやり方 が分類されます。 >>746-747 ありがとうございました。 あまりそういう本はないんですか。 もしかしたら、ヘネシーらのコンピュータのハードの本とか読まないといけないんですかね? あるいはコンパイラの本ですかね? >>747 一般的に、静的領域をヒープとは呼ばんだろ こういうのはネットで覚えたからどういう本に書いてあるかはわからん ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる