C++相談室 part136
■ このスレッドは過去ログ倉庫に格納されています
次スレを立てる時は本文の1行目に以下を追加して下さい。
!extend:on:vvvvv:1000:512
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part135
https://mevius.5ch.net/test/read.cgi/tech/1522495206/
このスレもよろしくね。
【初心者歓迎】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 >>164
Q. 俺には必要性が分からない
A. 必要がないなら無理に使わなくていいよ
で済むお話。 >>164
俺は何言ってるか分かったけど、この人に説明するのは無理だろな。
使ったことがないものを批判したい感じだし、std:unique_ptrは必要になってから使えば良いよと言ってあげれば良いのかも。 まずムーブを活用して、総称性が必要になってから初めてunique_ptrを検討する感じがいいんじゃないのかな。
そしてshared_ptrは設計に時間をかけられないときに使うもので、ほとんど出番がないはず。 20世紀最大の発明はレーザーと言われてるけど、21世紀最大の発明はムーブと言われてるからね。
俺に。 なるべく (ポインタでなく) 値でやりとりすること、それを低コストで出来るようにムーブ対応にしておくというのは
上位レイヤを作るときに楽できる良い設計だとは思うけど、
実質的にはスマートポインタの機能をクラスに付け加えてるみたいなもんで、
それがクソ面倒くせえときに標準のスマートポインタを使うみたいな方針でやってた。
総称性を活用するときという観点は無かったけど、確かに必要な考え方だな。 unique_ptrで内蔵しておけばnoexceptにしやすいので、ムーブが使われやすくなるというのはありますね。
とまあ、C++を使っていれば自然に有効利用するものですが、使う前に理解するのは難しいのではないでしょうか。
使ってみればなるほどとなると思うんですよね。 机上の空論繰り返すより、使ってみればすぐわかるよ。
これがおじさんからのアドバイス。 https://ja.wikipedia.org/wiki/%E7%B7%8F%E7%A7%B0%E5%9E%8B
総称型（generic type）、あるいはパラメタ付型（parametric type）とは、
型付けされたプログラミング言語においてデータ型の定義と
それを参照する式（型式）の一部にパラメタを許すことによって
類似した構造を持つ複数のデータ型を一括して定義して、
それらを選択利用する仕組みである。
総称型は、暗黙の型変換（implicit type conversion）あるいは型強制（type coercion）、
多重定義あるいはオーバーロード（overload）、継承（inheritance）あるいは包含（inclusion）と並んで
プログラミング言語においてポリモーフィズムを実現するための一つの手段であると看做せる。
総称型が使われている言語の例としてC++のテンプレート、JavaやC#のジェネリクスがある。
へー 総称型の説明は要らんよ
欲しいのは総称性って言う謎の言葉の方 個々のクラスの実装を工夫して値渡しとムーブで解決できないかをまず考えて、
複数の型について類似のコードが出てくるようなら unique_ptr や shared_ptr (や自作スマートポインターテンプレートクラス) の利用を検討する、
というようなことでは。 >>178
そりゃ誰も説明できないから謎でしかないわ w なんかそれっぽく言っとけば暗黙の内にマウント取れるから 「オマエ知らないんだ〜」「でも教えてやらなーい」ってのは
元手ゼロでもできる安上がりなマウンティング >>158
>この場合は上位の制御が必ず必要になり、std::shared_ptrが有ったところで大して恩恵はない。
この言い分はずんねんながら成立しない
「プログラム、呼び出されなければただのデータ」という諺（今漏れが作った）からわかるとおり、
画像Aや画像A'のいかに巧妙な中央集権的なリソース管理のロジックを組んだところで、
画像Aや画像A'の開放タイミングで呼び出されなければ機能しない
で、この呼び出しというのは、std::shared_ptr<画像>で極めて確実に（呼び忘れが無い形で）行うことが出来る
すわなち、画像Aのデストラクタで目的の中央集権コードを呼び出せば（注1）良い
よって、C言語スキー野郎（敬称略）がいうところの「std::shared_ptrの恩恵が少ない」例は、
そのまんま「std::shared_ptrを使えばより良い実装になる」例である
注1: ここでの呼び出しとは、実行権を渡すことを意味する。
直接CALL、メッセージの送付、レジスタにパラメータを積んでソフトウェア割り込み、
インスタンス固有の管理テーブルに情報をセットしてイベントで待ち解除、（同）タスク起床、etc.etc...
原液PGならやり方を100万通りぐらい即答できるはず 通知メカニズムを持つ画像より、通知メカニズムを持つリソースハンドルのほうが便利に違いないので、あまり使いどころがなさそう。 >>187
リソースハンドルは味噌も糞も一緒のHANDLE型で型安全の観点から不安があるが
画像クラスでwrapすれば型安全になる
行いが良ければ空も飛べるはず >>188
禿4はSTLコンテナの類もリソースハンドルと呼んでるけどな。
std::shared_ptrに通知メカニズムをプラスしたようなものが実際に必要になるのではないだろうか。
オジサンはATL風の通知メカニズムを備えたコンテナを作りましたぞ。 リソースを共有するということは、通知もセットで必要になると思うんだよなあ。 >>170
お前、ﾜｯﾁｮｲ 81b3-8neNが一度もまともなことを言ってないのを理解出来ないのはヤバいぞ。
そもそもお前、>>125ってことは、observer_ptrの使いどころも理解してないだろ。 まだ標準にも入ってないもんなんか使ったこともないし知らんわ。 唐突にphoenix_shared_ptrとか言ってみる 解る人おるやろか
Lokiに始まるメタテンプレートプログラミング狂騒時代も15年以上昔か… >>192
そう言うだろうとは思っていた。
そしてそれが今の君の、またC++erの限界なのだと思う。
君は>>103によると、世代的に、
C言語の前にアセンブラをやった連中は誰一人としてポインタで躓くことはなかった事実を知っているだろ。
これは単純に、ポインタの意味は既に知っており、
単に、インデックスレジスタの使い方をポインタと命名したんですね、で済んだからだ。
俺は同様の見方でC++を見てる。
C++のスマポはCのナマポを「分類/命名」しただけで、「追加」してないから。
だから記述能力が足りないことにも気づく。
unique_ptr(ｷﾘｯなんてやってるC++erは馬鹿丸出しだ。
君らはそれがCへの回帰な事にも気づけてない。
そしてここにきてobserver_ptrを追加するのは、完全に敗北だ。
あれはA方式用に他ならないから。
とはいえ、良いトライであったとは思うよ。そして失敗した。
ただ、それを修正して来れている点は素晴らしいが。
shared_ptrも結局使いどころがないだろ。
アセンブラの件からも分かるように、「理解していること」と「書いていること」は別なんだ。
正しくCを使っている連中は、そのナマポがunique/shared/weak/observerのどれなのかは明確に意識してる。
ただそれを書いてないだけだ。だから馬鹿には使っていないようにしか見えない。
君はobserver_ptrを知らないし、教えてもらわないと必要性に気づけない。
そこまで落ちぶれているって事だよ。
少なくともアセンブラ→Cの時のように、概念は理解しているがその言語での名前を知らないだけ、ではない。
対して、Cの連中は既にobserver_ptrを使っている。(ただし書いてない）
ここら辺の違いが、linusが一貫してC++erに冷めている理由だろうよ。無知な馬鹿にしか見えないから。 >194
> 正しくCを使っている連中は、そのナマポがunique/shared/weak/observerのどれなのかは明確に意識してる。
> ただそれを書いてないだけだ。だから馬鹿には使っていないようにしか見えない。
ああ、馬鹿にはわかんないよ。
だから書いてくれっての。
人間は度し難いほど馬鹿なので、クソみたいな間違いをする。
意識していたとしても間違う。
知っていても何度でも間違う。
そんなの当たり前だろ？ で、おめぇは一流のC++erと自称したいのかい。
ほんとに糞な爺だわ。早く棺桶の中で寝ろ。この河童虫が >>195
まあ俺は書くこと自体には反対ではないんだが、
1. 足りないんだから書きようがない(observerが)
2. そもそも書くほどバリエーションがない
Cで使われているのはunique/observerで、shared/weakはほぼあり得ない。
制御が煩雑すぎてバグる。
だからこそsharedが生きる構造があればC++が勝ちきる可能性があったが、
shared撲滅みたいな今の風潮じゃあねぇ。
そして既に書いたが、大概は方式Ａだから、
ローカルのナマポはuniqueで、それ以外は全部observerでしかない。
わざわざ分けて書くほどバリエーションがないんだよ。
Cの連中は書くのが嫌なわけではなく、書く意味を見いださないのだと思うよ。
書いたところでコード構造が改善されるわけでもなく、速度が上がるわけでもない。
書かずともどうせＡ方式だし。 sharedはリファレンスカウンタがからんでくるからね 依存性にかならず上流下流関係があってノードで循環を監視できれば
sharedでいいよね gtkもtcl/tkもwxも撲滅しなきゃならんのけ？ >>201
＞ノードで循環を監視できれば
そんなことが、果たして可能なのか？ >>197
分けて書く理由にバリエーションの数は関係ないでしょう。 問：ある時刻tの日本の年号を返すプログラムをC++とSTLを使って表現しなさい。年号はコードに埋め込むものとする。 >>198
参照のクモの巣と言えばDOMが有名だけど、あれはスクリプト言語ユーザーの都合上そうなっているだけで、C++ユーザーにとっては無用の長物なんだよね。
タブを一つ開くたびに500MB消費するのは許容限界を超えていると思う。 そして、ブラウザをCで書くのは非常につらい作業になるので、実用上C++を使うことになる。
したがって、スクリプト言語をホストする以上、自分たちにとって参照のクモの巣が無用の長物であったとしても、C++は、必要とされればいつでも参照のクモの巣をサポートする力が必要になる。 >>203
循環の検出ならスタックとノード毎の到達済みフラグがあれば逝ける
ドーナツ型の図形を塗りつぶすのと同じやり方
（個々のノードは、参照先の到達済みフラグがTRUEならああ循環したんだなあとﾜｶﾙ まあ分岐の無い循環しかないならスタックは無しでも逝けるがな！
末尾再帰の最適化と同じやり方
（ループで済む つまり古典的なマークアンドスイープ最強ってこったな。 量子コンピュータなら循環なんて一瞬で分かるよね
知らんけど そもそも再帰的なデータ構造じゃないものなら
循環参照のしようがないので普通に shared_ptr で良いし
そういう処理もごく普通によくある
>>209
＞（個々のノードは、参照先の到達済みフラグがTRUEならああ循環したんだなあとﾜｶﾙ
循環に限らず単純な共有でもこうなるので
そんなことでは循環したんだなあとﾜｶﾗﾅｲと思う 質問です、下記はソースの1部分なんですが、あるプロセスのメモリを検索しています。00000000〜7FFFFFFFまでを検索しているのですが7FFFFFFFを9FFFFFFFまでに増やしたいです、単純に終了アドレスを9FFFFFFFにしても検索してくれないですが何故でしょうか？
http://codepad.org/cdLpKbdw >>211
他に方法がないが、いちいち mark and sweep するなんて考えられない >>213
>循環に限らず単純な共有でもこうなるので
到達済みフラグをセットするのは開放時なので
ならない
>ドーナツ型の図形を塗りつぶすのと同じやり方(>>213)
と書いただけでは通じなかったですかそうですか、 ごめｗｗｗｗｗｗ
×：到達済みフラグをセットするのは開放時なので
○：到達済みフラグをセットするのは参照カウントを減らすときなで と思って今作ったがあんま使い勝手の良いものにはならんかったorz
使い方としては
class Foo {
sumapo<Foo> m_pCar;
sumapo<Foo> m_pCdr;
/*...*/
};
sumapo<Foo> ptr(new Foo());
と書いた後、ptrが開放されたとき、ptrが指すFooが握っているsumapoが残らず（循環があろうとなかろうと）参照カウントを減じて欲しいわけだが
これにはptrが握っているFooを開放する前に、ptrがFoo::m_pCdrやFoo::m_pCarを辿れる必要があるので
m_pCarやm_pCdrとptrが裏で手を握る必要がある ごめｗｗｗｗｗｗｗまた言い方をちょっとまつがえたorz
誤： Fooが握っているsumapoが残らず（循環があろうとなかろうと）参照カウントを減じて欲しい
正： Fooが握っているsumapoが（循環があろうとなかろうと二重破棄を招かない形で）参照カウントを減じて欲しい
リフレクションがあればsumapoからFoo（やBar）のメンバが丸見えなのでsumapoのリンクを辿って破棄予定オブジェクトを事前にマークすることで2重破棄の防止を自然に実現できる
リフレクションが無い現行のC++なら、sumapoのデストラクタで破棄される予定なFoo（やBar）をマークだけして破棄を遅延する、みたいな細工をするしかないが
デストラクタの中から全てのFoo（やBar）のマークが完了したか知る術が無いから、sweepする呼び出しが別途要る、、
やっぱC++にもリフレクション欲しい… >>224
JavaScripterマジで死ねよ
JavaScriptのコミュニティが腐っているのは、
馬鹿であることを自覚出来ないお前みたいな大馬鹿が、嘘を平気で垂れ流しているからだよ。
そして初心者はそれを見抜けず、騙されて馬鹿が再生産されてる。
お前らがC++のコミュニティを破壊する権利はない。JavaScriptのゴミ貯めに戻れ。
お前らはプログラマ全体からするとゴミ以下のクズなんだよ。それを自覚しろ。
C++初心者の為に、俺がお前の嘘を暴いておいてやる。
> リフレクションがあれば
お前のリフレクションの使い方は、メンバの中身を参照したいだけのようだ。
ならば、全てのメンバがpublicだったらいいはずだ。
このケースで、どうやって実現出来るのか説明してみろ。
お前は本当に何も分かってない。最初から躓くと思うぜ。
オブジェクトＡのメンバはすべてpublicである。
オブジェクトＡのインスタンスa,b,c,dは
・aはbを参照している
・bはaを参照している(a-b間で循環参照）
・cはbを参照している
・dはcを参照している
の状態で、a-b間で循環参照があり、参照はd -> c -> b <-> aとなっている。
これらへの参照は他にはない。
今、dへの参照がなくなり、dのデストラクタが起動された。
この状態で、どのように回収されるのか、説明してみろ。
お前みたいな馬鹿には出来ないと思うぜ。
さっさとJavaScripterの巣に帰れ。邪魔でしかないから。 >>220
単純な共有と循環を区別できるコードを書いてみてごらんよ。
あなたが考えているような簡単なものにはならない。
恐らくはあなたには書けないから。
コード書かずに妄想してるから間違えるんだよ いや違うか。
普通はコード書かずともちょっと考えればそんな間違いしない。
考えずに書くから間違いばかりする。 有向グラフでマークしてトラバースすれば循環がわかるのは単方向リストくらいなものだろ
ドーナツがどうとか言ってるのは無向グラフと混同している JavascriptとC++では要求されるレイヤーが違うので、比較するのは無理だと思う。 複雑な参照を持つシステムってまぁほとんどシミュレーション系で速度も要件に入ってくるんですよ。
糞遅いJavascriptやpythonなんて普通に使いものにならずC++の独擅場なわけですよ。
pythonでAIとか笑っちゃいますね。 >>233
この場合の Python はいわゆるグルー言語でしょ。
高速なコンポーネントのパラメータを指定して組み合わせるだけみたいな使い方なんじゃないの。
高速な計算が出来るコンポーネントは C++ が主流であったとしても、
それをビジネスロジックにさっと適用するという意味での「Python で AI」は現実的だし、
実際よくあることだと思う。 高額なPython屋募集のAI案件は、99%非現実的。
AIを何も分かってな奴が企画したプロジェクト。散々利用されてきた統計学以上の成果など出やしない。
昨今のAIブームは過去のAIブームと同じく破綻プロジェクトばかりなのは言わずもがな。
なぜPythonか。失敗したときにPythonだからと言い訳するため。
そもそも簡単な言語なのに高額で募集する時点で辻褄が合わない。
嘘ついて投資募ってるのは明らか。読売新聞のAI記事読んでると騙す気満々だと分かる。
openCVスレでもpythonから入る奴は何もできやしない。最初から分かりきったこと。フフフ、笑えますね。 結局はコンポーネント間の通信回数を減らすことが肝。しっかりと設計を吟味すれば従来通りのIPCで十分だったりする。 >>235
でもAIってモジュール部分は超簡単なんじゃない？ それにそんなもの「作る」って
レベルじゃないから、出来の悪い奴でもいいから一人がC++でモジュール書いていば
OKでやっぱPythonレベルの方が重要なのではないか？ そのあたりはpythonのソースコードを見ると分かる
ttps://github.com/python/cpython/blob/master/Objects/weakrefobject.c C++の公式スクリプト言語はPythonだから慣れるしかない。 AIで一番大変なのはデータを食わせることだよな。パイトンでもC++でもなくて
一番重要なのはエサやりして大切に飼いならす人だよ。だから愛がないとできない。
お前等には無理だな。三日やったら課長の机に糞してとんづら。 その学習させた膨大なデータが高額で取引される時代が来るのかね OCamlがあるのだからオッパイソンがあってもいいはずだが。 >>235
ほとんどのAI案件がやばいってのは同意だが
pythonなら言い訳できるってのはねーわw
そもそもAI案件の難しさはプログラム言語がどうのとかそういう問題じゃない。 >>230-231
仮にそれでもJavaScripterよりマシだ。
お前も含めて、JavaScripterには、馬鹿かつキチガイしか居ない。
例>>220,224： 反論することも出来ず、間違いを認めることもなく、ただ逃亡
これをやるからJavaScriptのWebリソースは大半が腐ってる。
俺は知らんがC/C++はWeb上の間違いに異常に厳しかった時代があったと聞く。
それが今も引き続いていて、Web上の正確性を担保してくれているのなら、有り難い話だよ。
ゆとりには「ぼくがおこられなければいい」という幼稚園児並みの知能しかないから、
JavaScriptコミュニティみたいなことが発生する。
あれは最早完全に手遅れで、その状態のゆとりが教える側に回っていることが最悪。
連中は平気で嘘をつく韓国人レベルのモラルしか持ってないし。
結果的に間違いであったにせよ、修正しておかないと、後で読む人の為にならないだろ。
「嘘だと認めなければ嘘ではない」という、韓国人みたいな奴は、キッチリ殺すべき。
間違ったことを書いたら叩かれるのは、長期的に見ればいいことだ。
それがゆとりには分からないだけでね。
あと、わざわざID消して自演しているゴミ、それは余計に目立つぞ。
他の誰もそんなことをしてないから、逆にコテトリになってる。
お前は他でも荒らしまくってるよな。 >>227
一番足りないのは謙虚さなんだけどな。
JavaScripterは本当に馬鹿しかいないから、コードがマジでゴミしかない。
だから糞コードしか書けない馬鹿がつけあがる。
そしてそれを諫める年長者もいない。幼稚園で先生がいない状態だ。
C++は30年の歴史があって、仕様も改訂し続けているのだから、
今の仕様はその中で今一番マシな方法ということになっている。
JavaScripterみたいなぽっと出のゴミがぱっと考えて思いつくような手法を、
今まで30年間誰も思いつかなかったと思うこと自体がキチガイでしかない。 というわけで先に進める。
沸きまくっている馬鹿を振り落とす為に速度を上げるからよろしく。
>>213
> そもそも再帰的なデータ構造じゃないものなら
> 循環参照のしようがないので普通に shared_ptr で良いし
> そういう処理もごく普通によくある
「再帰的なデータ構造ではないとき、循環参照は発生しない」については同意だが、
「循環参照がない場合は、shared_ptrでいい」には反対だ。
これだとC++の速度優位性が無くなるので、俺ならGC言語を検討する。
ただしこれは宗教だからもういい。
本題は、
・shared_ptr（静的共有)必須な構造が、果たしてあるか
だ。木構造で一番身近なファイルシステムを例に取ると、
静的共有(ハードリンク/shared_ptr)と動的共有(シンボリックリンク/getter)のうち、
前者はほぼ使われてないだろ。
これは、ユーザーによる手動管理の場合、シンボリックリンクの方が明示的で使いやすいからだ。
シンボリックリンクは常に最新版を、ハードリンクは常に生成時の対象を参照するところが異なる。
速度的には静的共有の方が優位だとして、動的共有では無理な事例ってあるか？
俺が知っているハードリンクの活用事例は、WindowsUpdateくらいだ。
「動けばいい」なら動的共有の方が適切に思える。
(C++で動的共有はなかなかにきついが、動的言語なら自然に実現出来る） >>245
何故に自分のことと思ったのか知らんけど、自覚が無いよりはあったほうがいいと思うよ。
別スレでID無しにイジメられたんか？ >>248
俺から見ればお前がキチガイだし、
ここがお前にとって合わないと思うのなら、お前がここに来るのが間違ってる。
ゆとりはゆとりだけでスレ作れよ。
それがお互い一番幸せな解決だ。
俺には韓国人とゆとりは殺すしかないという結論が出てる。
お前らは邪魔しかしないから。今もそうだろ。 初心者で的はずれな質問かもしれませんがお願いします。
1行に約4000文字,区切りで書かれたファイルがあり、これが1000行あります。
このファイルを1行ごとに別の配列に格納したいのですがfgetsだとchar型になりcharは256文字しか入らないようです…
どうしたら読み込みできるのでしょうか >>250
> fgetsだとchar型になりcharは256文字しか入らないようです
単に間違えたプログラムを書いている。
そのプログラムを提示してみて。 C言語を通らずにいきなりC++を使う初学者は
fgetsやcharに触れるべからず
必ずラッパーライブラリを使うべし >>250
getcを使ってmyfgetsを新たに作る
改行を調べるだけなのでそんなに苦ではない >>247
C++風に考えるとstd::shared_ptrは必要なくなってくるけど、他の言語の真似をしようとすると、必要になるんだよな。
そしてC++は他の言語から呼び出されるから。
そういう部分で必要があるのかも。 スレッド使う場合は、コピーのほうが速くないかよく考えた方が良い。
意外とコピーのほうが速い。 >>253
宗教じみたことは言わないほうがいい。
C++の入出力クラスiostream系の標準機能は失敗した代物との結論が出ている。
C++学習者は FILE* 系の標準機能を優先して使うのが正道。 >>257
iostream 系のどんなところが失敗しているのですか？ >>257
あり得ない
ポインタも分からん奴に生char使われてたまるか
fgets使いたいならC言語で基礎を身に付けてから出直して来いや たしかにiostreamはデストラクタで自動的にクローズしてくれるくらいしか
メリットが感じられないから、自分でファイル入出力クラス作ってるわ iostreamはC++のテンプレートクラスが未発達だったころの遺物だよ。STLに含まれない時点でお察しではあるが。
iostreamを使うよりもshared_ptrなどのスマートポインタでFILE*をラップしたテンプレートクラスを使うほうが現代的。
shared_ptr::shared_ptr<FILE>のコンストラクタで第二引数にfclose()を呼び出すdeleterオブジェクトを渡すだけで事足りる。
shared_ptr::shared_ptr<FILE>直使いもいいが、その派生クラスを使って暗黙のFILE*型キャスト演算子を実装すれば、Cコードとの移植性がさらに高まる。
あと、iostreamはios系の様々なフラグがあるが、煩雑で使い勝手が悪い。覚える価値ゼロ。 >>258
速度じゃないか？
使いもしないオペレータのために余計な処理挟むから。
VCについてくるディンカムウェアなんか一バイトごとに仮想関数呼び出してるぞ。 訂正。
shared_ptr::shared_ptr<FILE> じゃなくて、shared_ptr<FILE>でした。
deleterサンプルは以下の通り
struct file_deleter { void operator() (FILE* fp) const {if (fp != NULL) { fclose(fp); } }};
shared_ptr<FILE> fp(fopen(filename, "r"), file_deleter());
// 以下、fp.get() でFILE*にアクセス。 まあでも、明らかな失敗だったら auto_ptr や wstring_convert みたいにとっくに deprecated にされてるよね。 ■ このスレッドは過去ログ倉庫に格納されています
