C++相談室 part161
■ このスレッドは過去ログ倉庫に格納されています
スマポにハンドルを突っ込む方法はないですかねえ‥‥ >>596 君のような勘違い自信過剰な人がうっかりミスを起こして問題を引き起こしてきた チェックを人間に依存している限りミスは必ず発生する ソース記事 https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/ グーグルによればAndroidに存在した深刻なセキュリティー脆弱性の70%近くがメモリー安全に関するバグに起因するという。 同様にマイクロソフトも、同社製品に存在したセキュリティー脆弱性の70%がメモリー安全に関するバグに起因すると述べている。 C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と >>598 > >>596 > 君のような勘違い自信過剰な人がうっかりミスを起こして問題を引き起こしてきた 私は最近はメモリ管理で全く失敗がないので私とは違うな >>598 $ wget 'https://cdn.kernel.org/pub/linux/kernel/v5.x/linux-5.19.1.tar.xz' $ tar xJf linux-5.19.1.tar.xz $ find linux-5.19.1 -name *.rs | wc -l 0 2021年4月30日の記事だけどまだコミットがないようだが? Rustのsuffixってひょっとしてrsじゃない? >>600 それは貴方がアホだからミスに気付いていない可能性、使われないからバグが未発見なだけの可能性、単純なことしかしていないだけの可能性、… 複雑化すると、どんなにベテランでも、多数の人々がコードをチェックしていても、メモリ管理ミスが現実に起きている現実を受け入れましょ >>602 俺が>>600 で述べたのは俺のことのみだよ >>604 ごめんごめん >>598 がいちいち私を引き合いに出してきたので否定したまでだよ >>598 の書き込みも冒頭の「君のような」を書かなければ 良いのに何でいちいち書くのかね? どんな複雑なケースでも一度もミスをしたことがない!今後も絶対にミスをしない! と言ってる人を信頼できるわけがない >>606 >一度もミスをしたことがない!今後も絶対にミスをしない! そんなことは一言もいっとらんがなw 本当にunique_ptrやshared_ptrでミスするかい? 信じられないほど単純なクラスだと思うけど >>592 の「使い方ミス」って何なの? getで中身取り出して云々は割とあり得るんだろーけど それはunique_ptrやshared_ptrの外の出来事だし もちろんgetを使った時点でスマポ管轄外となり保証が全く無くなるが スマポ自体における使い忘れや使い間違いなども色々とあるぜ 例えば C++11スマートポインタで避けるべき過ち Top10 https://postd.cc/top-10-dumb-mistakes-avoid-c-11-smart-pointers/ >>609 有難う!読んでみたよ!過ちを列挙すると以下の通り >過ちその1: uniqueptrで十分なところにsharedptrを使う >過ちその2: shared_ptrで共有されたリソース/オブジェクトをスレッドセーフにしない >過ちその3: 自動ポインタ(auto_ptr)を使う >過ちその4: sharedptrの初期化にmakesharedを使わない >過ちその5: オブジェクト(生ポインタ)を作成してすぐにshared_ptrに割り当てない >過ちその6: shared_ptrで使用されている生ポインタを削除してしまう >過ちその7: ポインタの配列にshared_ptrを使用する際にカスタムデリータを使用しない >過ちその8: 共有ポインタを使用する時に循環参照を回避しない >過ちその9: unique_ptr.release()で返された生ポインタを削除しない >過ちその10: weak_ptr.lock()を呼び出す際に、有効か否かを確認しない 俺については4はmake_sharedを知らなかった時期にはやってたけど知ってからはないね 3はunique_ptrがstdに入って全部リプレースした あとは過去にも犯さず使用しできてるよ みんなはどうだい? getを使ってしまったらthe endなわけだけど getの使用を皆無で頑張ってるん? >>611 外部ライブラリの関数呼ぶのにget使うけど 意味するところを理解しているので 慎重になるから失敗した覚えはないなぁ 当たり前だけど自分の書く関数の引数に生ポインタを使うことはない >>612 ところで複数の関数呼び出しそれぞれに参照を渡したい時はどうしてる? 生ポインタ使わないからshared_ptr? >>613 その書いている「参照」ってのはC++の参照ではないですよね? 関数にT型のオブジェクトを引数として渡すとき 関数がシーケンシャルに実行されるなら原則としてT &で渡す 中身が無効値である可能性があるならunique_ptr <T> &で渡す 関数が並行に実行されるならshared_ptr <T>を渡す T&渡した時にそれが他へ転用され保持されて生き残り続ける可能性を考慮しないの? 静的試験を絶対視するなーんにも分かっとらんやつが推すほどイメージが悪くなるな >>616 だからポインタ使うの? まあ寿命の長いオブジェクトを駆使しないほうがかっこいいのでは >>617 動的チェックは不便だし重くて遅いよ できる限り何でも静的にするのがベター >>597 constructor destructor関数オブジェクトを用意すれば良かったんじゃなかったっけ?smart ptrの典型的な応用例だから、調べりゃすぐ出てくるよ。 >>617 俺も以前はそう思っていたんだけど わずかな補助情報を人間が与えるだけで Rustコンパイラが静的試験してくれて 人間にとって面倒かつ慎重さを必要とする作業から解放してくれるのを知って考えが変わった 例えて言うなら 動的型付け言語を使っていたところを わずかな型情報を人間が与えるだけで 静的型付け言語のコンパイラが静的試験をしてくれるようになったのと似てる 昔とはソフトウェアの規模感が違う。 そしてプログラミングするのがプログラミングの専門化とは限らない領域が増えた。 (いわゆるエンドユーザー・コンピューティング) 職業的なプログラマにしてもプログラミングの専門化というよりは 別分野のそれぞれの専門化が道具としてのプログラムを作るというような場合も多い。 プログラミングのルールや作法を行きわたらせることは出来ないよ。 検査を強くするのは時代的な背景としても自然に思える。 動的な検査でも静的な検査でもいいが、 C/C++ は検査せずに未定義に突入するのがあまりにも簡単すぎる。 >>623 ナマポひとつロクに扱いきれないスキルと 動的チェックなんて恥ずかしげもなく言っちゃう バカ用言語があんたにとって有難いのは分かったよ ここはC++相談室 C++という土俵に立っている者の場だ 落ちこぼれて逃げ出したやつの遠吠えは 誰も聞きたがってない どっか行け、邪魔なんだよ 自分のミスを道具のせいにするやつ そういえば法案のミスをワープロのせいにするバカ役人がいたな こういう手合いは一事が万事 >>616 が何を言いたいのか今もって分からない 悩む 一般用語の参照を使ってると思われるあたり この人(>>613 )はC++の参照を知らないレベルだと思うんだよね C++に関してはほぼ知識がないまま 受け売りでRustが生ポインタを廃止?した利点を主張している (私もRustのコードは書いたことがないんだけども) この人は何がしたいんだろうか? OSのAPIなりその他雑多なライブラリなりでポインタ要るからなあ・・・ 動的型付け・・・あー、もしかして動的型宣言のことかな? だとすると具体的に何言語のことを言ってるんだろう? Bにはそんなもんないし・・・ 昔構造体を値で渡したらポインタにしろっておっさんに怒られたっけ 速度を気にしないんだったらコピーでええのに糞めんどくさかったわ >>630 動的型付けを知らないとは素人かね? 動的型宣言という言葉は存在しないぞ >>633 それwikipediaソースだろpgr で、あんたdynamic type declarationのことを言ってたの? それとも他の何かか? Bにあったものか? >>634 あまりにも無知すぎて話にならないな wikipediaでも何でもいいから勉強して出直して来い 動的な型と動的型付けの区別は最低限つけろ 静的型付け言語の中には動的な型と呼ぶものもあるが 静的型付けと動的型付けは基本的に排反の関係だ >>616 が何を言いたいのか今もって分からない 悩む その一文がわからないようなレベルの奴がメモリ管理で全く失敗ないとか言ってんだもん みんな呆れてんだよ >>637 本当に質問の意味が分からんから説明してよ 意味が分かったら返答するからさ >>635 俺は動的な型と動的型宣言を混同していることを露呈するような失言はしてないぞ していると言うなら具体的にどこなのかを示せ 誤魔化しても構わんがそれも返事と取るからな >>628 にも書いたけどC++相談室で一般用語の「参照」は C++の参照と混同するので普通は避けるんだよね C++で書いた経験が皆無なんだなと俺は判断している それで>>616 のような意味を計りかねる質問をしてしまう >>639 そこまで恥を再び晒したいなら示す >>630 > 動的型付け・・・あー、もしかして動的型宣言のことかな? まず動的型宣言という用語は存在しない "動的型付け" はググると7万件あり "動的型宣言" はググると3件である 一般的に動的な型の宣言の話と広く解釈したとしても 動的な型の宣言と動的型付けは異なり互いに包含関係などもない 動的な型の宣言は静的型付け言語においても持つものがある そして動的型付けは静的型付けの逆であり相反する >>637 説明が難しいなら簡単なコードでも良いよ 何を懸念しているのかそれで推察できると思うから 栄光在天 聖恩心から感謝申し上げます。 日ごろは激しい摂理の中、プログラム業ごくろうさまです。 さて、C++のコピーコンストラクタおよび代入演算子オーバーロードの質問でございますが、メンバ変数全てを関数定義内部で書き出すととてつもない量になってしまいます。 class Hoge { Hoge& Operator =(const Hoge&r); int hage=0; char sage=0; std::unique-ptr<Hagehage> pHagehage; etc… Etc… Eat… }; Hoge& Hoge::operator=(const Hoge&r) { hage=r.hage; sage=r.sage; pHagehage=std::make-unique<Hagehage>(r); Etc etc…… } メンバにユニークポインタがあるので書き出さないとダメな感じになっちゃうのですが……量がががが(>_<) これらにおいて、何か楽になるような裏技はありますか? それとも一つづつ足していかなければならないのでしょうか? もしかしたらコンパイラやIEDの部門で行うべき変な質問かなとも思いますが……何かやり方やティップがありましたら教えていただければ…… 相対的に有田退治にもなります! >>643 メンバを Hoge& Operator=(const Hoge&r)=default; というように宣言すればデフォルトの定義が実装される。 全てのメンバに対して代入演算子を適用したのと同じことになる。 (もちろん全てのメンバを代入するという挙動で駄目な場合は自分で書くしかしょうがない。) >>641 そのレスには動的な型についての言及がないな 誤魔化したいわけね、返事ありがとう 動的型宣言という言葉は存在しないと言いながら 動的型付けとは【意味が違う】とはどういうことだ? 存在しないものは比較できないはずだぞ operator<=>でSFINAEだなpgr >>643 そもそも代入演算子は特に指定しなくても定義されるはずだな。 (ただし基底とメンバの全てが代入可能であるとき。) class foo { public: int x, y, z; foo(int x, int y, int z) : x(x), y(y), z(z) {} foo(void) : x(0), y(0), z(0) {} }; int main(void) { foo x(1, 2, 3), y; y=x; // 代入できる } >>645 おかしな人みたいだからこれ以上は相手にするのやめとく 動的型付けを知らなくて間違えたことは仕方ないとしても それを指摘された後の逆ギレはみっともないから治したほうがいいよ >>644 >>647 規制されてしまいましたが643でございます。 メンバにユニークポインタがある場合は代入演算子とコピコンは削除された関数とされてしまい、コピーが実行できません(涙 ユニークポインタは明示的に複製されないとだめなのはわかるので、仕様には文句があるべくもないのですが…… 例えばの話、データ型にint char等のメンバが100個あったとして、ユニークポインタのユーザー定義型が1個紛れ込むだけで、すべてのメンバを書き出しをしなければいけないのでしょうか? みなさんはちゃんと書きだしているのですか?と疑問に思ったので・・・ まあユニークポインターを含むデータ型をコピーしない運用をなさっているのだと思うのですが、わたしは使ってしまいます(怒) そこで、なにか裏技のような方法がないのかなとお聞きしてみた次第であります(`・ω・´)ゞ >>651 コピーコンストラクターや代入演算子で deep copyするunique_ptr作ればええがな? >>652 メンバ変数 std::unique_ptr<My_Uniq> my_uniq; において this->my_uniq=std::make_unique<My_Uniq>(*(right_arg.my_uniq.get())); とコピーできるのはシンプルなのですが…… struct hoge { hoge& operator=(const hoge& r); int a=0,b=0,c=0; char d=0,e=0,f=0; std::string g,h,q; std::unique_ptr<MyHage> pMHage; }; といった構造体において、 hoge& hoge::operator=(const hoge& r) { //メンバ全部かかなきゃいけない( ;∀;) } という感じになってしまうのが困るというか……もっと楽できないかなと思いまして(´;ω;`) >>653 std::unique_ptrを使わない カスタムのunique_ptr相当だよ >>654 なるほど得心いたしました! ユニークポインタをラップしたクラスにコピーコンストラクタを実装すればいいという……ってコト? ですね? ちょっと試してめます 643です 解決しました 皆様ご親切にありがとうござい甘いた ラップしてオペレーター実装すればいいだけだったとは…… こんなので悩んでるの私だけではないだろうか >>656 携帯だったので書けなかったけどこんな感じで template <typename T> class deeep_copy_unique_ptr: private std::unique_ptr <T> { using Base_ = std::unique_ptr <T>; public: explicit deeep_copy_unique_ptr (T *p = nullptr): Base_ (p) {} deeep_copy_unique_ptr (const deeep_copy_unique_ptr <T> &p): Base_ (std::make_unique <T> (*p)) {} deeep_copy_unique_ptr &operator = (const deeep_copy_unique_ptr <T> &p) {Base_::operator = (std::make_unique <T> (*p)); return *this;} using Base_::operator *; }; >>621 それがそうでもないんですよ。だれか簡単なソースで示してくれませんか? ハンドルごとにデストラクタがいろいろと変わるのが難しいと考えています。 ハンドルごとに異なるデストラクタを指定すればよいのでは? 何が難しいのかソースで示してくれませんか? >>658 > ハンドルごとにデストラクタがいろいろと変わるのが難しいと考えています。 ハンドル毎にクラス作ればいい と言うかハンドル毎にコンストラクタも色々変わるはずだがそっちはいいのか? >>658 ポインタ以外のリソース一般を扱うための unique_resource クラスの提案は出ている。 一部の処理系では使えるようになっているし、ポータブルな実装があるので導入してみてもいいかもね。 このような提案が出ているのは逆に言えばスマートポインタではハンドルを上手く扱えないということでもある。 >>660 >ハンドル毎にクラス作ればいい それはもうスマポじゃない‥‥ >>658 そのハンドルって何? ハンドルを具体的に指定せずにソースで示せとな? #include <memory> #include <cstdio> #include <string> using namespace std; int main () { using File_Ptr = unique_ptr <FILE, decltype (&fclose)> ; const string path ("hoge.txt"); File_Ptr fp (fopen (path.c_str (), "w"), &fclose); const string buf ("hage\n"); fwrite (buf.c_str (), 1, buf.size (), fp.get ()); return 0; } unique_ptr縛りですか? shared_ptrならコンストラクタの第二引数にDeleter関数を渡せるけど 私が言いたいことを >>663 が言ってくれたみたい こんな昔ながらのRAIIクラスでいいじゃん class FantasticHolder { FantasticHandle h = NULL_HANDLE; errno_t e; public: FHHolder(int flag, void* data, FOption option) { e = create_fantasy(&h, flag, data, option, false, NULL, Fantasy::DREAM); } close() { e = universal_fancy_destroyer(h, NULL, true, Fancy::FANTASTIC); h = NULL_HANDLE; } ~FHHolder() { close(); } const FantasticHandle& getHandle() const {return h;} erron_t getError const {return e;} }; >shared_ptrならコンストラクタの第二引数にDeleter ほんそれ lzw書いたら、色々プリプロセス突っ込んでやったのにメルセンヌツイスタの前に敗北した。 2色ビットマップは1/5になったけど、ブロックソートがアホみたいに遅い・・・。Orz サブルーチンsub、 subを呼ぶA、 subを呼ぶB、 があって、subをAとBからしか見えないスコープに置きたくなったんですが、そういうときはnamespaceを切るしかないですか? >>671 sub, A, Bをひとつのファイルに入れてファイルスコープで区切るとかクラスにまとめてクラススコープで区切るとか >>672 クラスに入れるとしたら毎回インスタンス作って呼ぶんですかね? 外から呼ぶためだけにstatic関数にするのもなーと思ってしまうのですが、そういうのはよくやられていることですかね? Javaとかではstatic関数まとめクラスはよく見るけどC++ではあんまり見ない それこそnamespaceを使う それはどうだろう。 namespace は内部を隠蔽しない。 キッチリと隠したいなら翻訳単位を分けるか、 翻訳単位内でも隠蔽したいならクラスに入れるかしかやりようがない。 やろうと思えば namespace で区切ってここにはアクセスしないことにするという 規約で運用するとかも出来るが、その程度で足りるなら そんなに分けなくてもよくない? って思うし。 subを公開ヘッダに書かずに非公開ヘッダに書くだけでよくね?もしくはヘッダを用意せずに各ソースコードからexternするとか。どっちも完全に隠蔽されるわけじゃないけど。 あとは全部同じソースコードに格納できるなら無名名前空間の中にsubを入れとくとか? プライベートにズケズケ踏み込んで来るのは 友達としてちょっと... おお!心の友よ! お前のものは俺のもの 俺のものは俺のもの >>674 char_traits numeric_limits >>671 AとBがクラスなら共通のMix-inクラスをAとBでprivate(protected)継承するとか? MessageBox()みたいな機能でボタンのテキスト変更できるファンクションありませんか メッセージが"ぬるぽ"なら[ガッ]のボタンを押したいじゃないですか! [ はい ]、[ いいえ ]だと"ぬるぽです。ガッする場合は[はい]を押してください"みたいに長々と説明しないといけないので(´・ω・`) >>684 C++の標準ライブラリにGUIは用意されてないのよ >>684 Vista以降ならTaskDialog windowsのアプリの話 C++で作成するとランタイムが必要なんですか? Cならランタイムは不要ですか? windowsのアプリを作成するとしたらC++とCでどちらの方が良いでしょうか? ランタイムライブラリはCでも必要 アプリ制作が目的ならC/C++はそもそも向いてないかもしれない 出来なくはないが、そのレベルの質問をするようだと今後苦労するかも >>688 C/C++ のランタイムライブラリの一部は Windows の一部として入っているからその範囲内でならどちらでもあまり関係がない。 ランタイムライブラリの一部はVisual C++ 再頒布可能パッケージとして配布されているものもあるが Windows のバージョンによっては 最初から入ってるとかもあるのでそのあたりの事情は複雑。 バージョンの混乱を避けるならスタティックリンク版を使ったほうが楽だと思う。 Windows のアプリケーションを C で書くのはだいぶんしんどいと思う。 C++ なら楽というわけでもないけど各種フレームワークが C++ を前提にしていたりするので全体としては楽をしやすい可能性が高い。 ただ、言語仕様としては C++ のほうがだいぶん複雑ではあるので言語に対する習熟がどの程度かにもよる。 ランタイムは実行時に使われるライブラリ (およびその他の実行時サポート) で、 API はそれらを呼出すインターフェイスのこと。 ただ、そんなにしっかりした定義があるわけではなくて スタティックリンクするライブラリのインターフェイスを API と呼ぶかどうかなどは人によるかも? API の P はプロトコルの P なので独立性の高いモジュールの外部仕様なら 形態にかかわらず API と呼んでいいんじゃないかと個人的には思っているが。 ntdll.dll とか kernel32.dll は API って感じするけど それ以外は全部 Runtime で良いんじゃないかとも思う msvcrt を API かって言われたら絶対違う気がする ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.5 2024/06/08 Walang Kapalit ★ | Donguri System Team 5ちゃんねる