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 >>327 それだったらunique_ptrじゃなくて参照渡せば良いだけじゃ 知らない間に、&& みたいな参照渡しもできた Rust の所有権ムーブの事 所有権を渡すのってstd:move()だと思ってたんだけどconst &&でもいけるの?? C++17でstd::iteratorが非推奨ってなっているみたいだけど代わりに何使うの? >>332 std::move は rvalue にキャストするだけで、それ自体にはムーブする機能はない。 実際にムーブの処理をするのはムーブコンストラクタやムーブ代入演算子の方やで。 && は単純に右辺参照って意味しかないから、 rvalue を受け取れるってだけ。 だけど lvalue でもムーブしてぇってときは std::move で rvalue にキャストすんの。 右辺値参照とか難しいなー 最近ようやくC++11使えるようになったから全然いってることがわからん 右辺値参照が使えなかった頃は、std::swapでスピード最適化していた。ポインタとメモリー確保を含む構造体は、 単純にスワップしたり、単純にバイト単位コピーしたりするのはまずいことがある。 そういうときに、std::swapを使う。右辺値参照は、それよりちょっと速くて賢いが、テンプレート型を理解してないと多分理解できないと思われる。 右辺値参照の型はテンプレートを使った特殊な型だと考えるのが自然。 T&& === rvalue_ref<T>. std::move(T&)はrvalue_ref<T>という型。 訂正。 std::move(T&)の戻り値はrvalue_ref<T>という型。 すみません、テキトーなことを書いたので、銃殺されます。 実際のところヘッダファイルから std::move の定義を抜き出すとこんな感じ。 template<typename _Tp> constexpr typename std::remove_reference<_Tp>::type&& move(_Tp&& __t) noexcept { return static_cast<typename std::remove_reference<_Tp>::type&&>(__t); } テンプレートの都合で面倒くさくなってるけど、実態としては static_cast してるだけ。 そのstd::remove_reference<T>::typeはTから左辺値参照や右辺値参照をはずした型になるね。それに&&を付けるんだから、左辺値参照が右辺値参照になる。 やはり、constexprやnoexceptを付けた方が性能がいいんだな。 C++17 では noexcept は型の一部という扱いに変更された。 例外を投げないなら投げないと書いておかないと他のライブラリとの組合せで型エラーになったりすることもあるかもしれんぞ。 江添本にこの辺りのチートシートと問題集いれたら100部くらい売り上げ増えるのでは 江添ってあれか。ニートの時にやることないからたまたま目についたC++の仕様書を読み込んでたら いつの間にかすごく強くなったという、ホリランみたいな。 おまえそれをバカにできるのか? 仕事ってそういうもんだぜ 目の前の案件のために必死こいても付け焼き刃にできることは知れてるんだよ 「ヒマ」なときに遠くを見て投機的にコツコツ努力したことが あとで花咲くことがあるし咲かないこともある 賭に勝った者を、降りたやつがバカにできるのか? え、おい >>320 >>322 書き込むときポインタ渡しにするのは C++には参照渡しがin/out/refのどの意味なのか表すシンタックスが現状無いから というのが主要な動機だと思うが inならconst T& aというのは比較的読み筋だが T* pと書いただけだとoutなのかrefなのかやっぱりわからん… && は、Rust のmove の事。 所有権移転。移転元が空になる 基本的に数年は、ドワンゴ江添と共に、山ごもり! 江添が空海なら、漏れは最澄w 悟りを開くまで、空海・最澄の一問一答が、延々と続くw rvalue reference 自体はムーブしねぇつってるだろ。 &&参照は「このオブジェクトもういらないからぶっ壊してもいいよ」というサイン 言うなれば肉屋へ行く馬車 野生のオブジェクトは誰に断る必要もないので勝手に連れてかれて解体される 家畜を渡す時は解体に同意するサイン(std::move())が必要 Fooクラスのunique_ptrがつまったvectorを作って、他クラスのメンバ変数にセットするときはどう渡すべき? 作った元ではもう使わないから所有権放棄していいとする const参照渡しにして、渡された側でvectorの中身を全部std:move()して新しいvectorにつめるのが一番最初に思い浮かんだ そんなことしなくても最近ここででてる、&&つけて渡してそのままセットすれば解決するのかな? vectorを丸ごとmove付けてコンストラクタに渡せばいいよ 出来上がった後で渡したいならswapすればいい なるほどー コードにするとこんな感じかな? std::vector<std::unique_ptr>vec_hoge; ... Hoge hoge; hoge.setHoge(std:move(vec_hoge)) Hoge::setHoge(vector<unique_ptr>&& vec_hoge) { this-> vec_hoge = vec_hoge; } せやな。 rvalue reference は lvalue だぞ。 noexceptにtrue,falseがある理由については #include <type_traits> template<typename T> void test(T t)noexcept(is_unsigned<T>){ //Tの型がunsignedの時だけは例外は投げない } こういう事が出来ると書いてあったけど、c++17以降も問題なく使えるだろうか? is_unsigned_vだろ なぜC++17以後で廃止になると思ったんだ? stdも抜けてた。。。 廃止になるじゃなく面倒な事になりそうだと。 unsigned は組み込み用だろ 0 〜 255 のカウンターなどで、無限にループする。 255の次に、0が来る overflow にされると困る >>368 組み込みでなくても極々普通に使うし、標準ライブラリ使ってれば知らぬ間に使ってる。 普段は uint_xxt と size_t しか使わんわ int と ptr あんまり相互に変換しないし visualstudio2017 でスタックトレースがしたいのですができません。 最初はBoost.StackTraceで試みたのですがMSVCでは行数やファイル名の出力が非対応で アドレスまでしか取れませんでした。 次にWinAPIを使って解決させようとしたのですがこれもうまく行きません。 SymGetSymFromAddrを使うとどうやってもエラー126が帰ってきてしまいます。 以下のプログラムがVisualstudio2017で動作している人はいないでしょうか? ttps://github.com/shive/blogpost/blob/master/20130918-stacktrace/main.cpp >>373 こうなった ---- BEGIN BACKTRACE ---- 1 : 0x00e76873 : Project1 : mycode::foo : c:\users\\source\repos\project1\project1\main.cpp(116) : backtrace(); 2 : 0x00e76513 : Project1 : mycode::bar : c:\users\\source\repos\project1\project1\main.cpp(120) : foo(); 3 : 0x00e76563 : Project1 : mycode::baz : c:\users\\source\repos\project1\project1\main.cpp(124) : bar(); 4 : 0x00e76b33 : Project1 : mycode::hoge : c:\users\\source\repos\project1\project1\main.cpp(128) : baz(); 5 : 0x00e76f0d : Project1 : main : c:\users\\source\repos\project1\project1\main.cpp(134) : try { 6 : 0x00e7870e : Project1 : invoke_main : f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl(78) : ? 7 : 0x00e785b0 : Project1 : __scrt_common_main_seh : f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl(283) : ? ---- END BACKTRACE ---- >>375 プロジェクトの設定はdbghelp.libを追加しただけでしょうか? あとWindows10ですか?7ですか? >>376 自分もそれを読んでx86とx64両方試したのですがダメでした、、、 >>377 Windows10で実行 ライブラリは追加したのと このFileNameがchar*でmsvcでは通らないから適当に文字列のバッファを作って渡した >94 line.FileName = "?"; >>378 自分はWindows7&VisualStudio2017なのですが dbghelp.lib、dgbhelp.hを探すと以下の場所にあるのでWin10でしか対応していないのかなと… C:\Program Files (x86)\Windows Kits\10\Lib\10.0.16299.0\um\x86 C:\Program Files (x86)\Windows Kits\10\Include\10.0.16299.0\um C:\Program Files (x86)\Windows Kitsの下には8.1と10 という名前のフォルダがあるのでOSの番号ぽいです。 dbghelp.dllならそこらじゅうにあるのでLoadModule関数で呼べばいけるのかも VisualStudio Installerで構成の変更をしようとすると 'Windows XP Support for C++'というのがあって これがWindows7用のSDKらしいです。(どんな名前の付け方だ…) これをインストールするとめでたくdbghelp.libとdbghelp.hが追加されるので それでコンパイルしようとすると #include <dbghelp.h> とかくだけでコンパイルエラーになってしまいました。 エラー C2760 構文エラー: トークン '識別子' は予期されておらず、'型指定子' が予期されています scratch c:\program files (x86)\microsoft sdks\windows\v7.1a\include\objbase.h 239 Windows10を買うかVisualStudio2015をインストールするかしかないのかもしれません;; >>380 Visual Studio 2017 スレの919あたりから話題になっているけど、 VS2017 の Windows 旧バージョンサポートはおかしいみたい。 2015と同じツールセット、SDKを用いても動作が違う。 2015をインストールするのがいい気がする。 参考 Visual Studio 2017 Part4 ・ http://mevius.5ch.net/test/read.cgi/tech/1509244956/ https://www.visualstudio.com/ja/vs/older-downloads/ コンパイラを作っているんですが、char 10bit short 18bitの時はsizeofはいくつを返せばいいんですか? >>382 アドレス単位を返す。ワードアドレッシングなら通常全て1になる メモリ上のレイアウト次第 その18ビットを隙間だらけでchar8個分のメモリに置いてるなら8だし、 詰めて2個分で置いてるなら2 sizeof(char)は必ず1じゃなかったっけ? sizeofが小数を返しちゃいけないって誰が決めたの?🙄 >>386 仕様。 C99 だと 7.17 に size_t は sizeof 演算子の結果の符号無し整数型って書いてある。 C++11 だと 5.3.3 に sizeof 演算子の返却値の型は size_t って書いてあって、 18.2 に size_t は符号無し整数型って書いてある。 sizeof(bool) == 0.125 であって欲しいのかw どうせ汎整数昇格で int になることばかりなので、 アドレス単位以下の小さなオブジェクトにする意味なんてないよ。 大きな配列で扱いたいときは std::bitset が有るし。 >>389 もしsizeofが小数を返したら汎整数昇格は適用されないんじゃない? この板に書いてあることがほとんどわかっていないようなクソ素人ですみませんがちょっとお聞きしたいことがあります。 Windows 7でOpenCVをTDM-GCCにて動かしたいと思っているのですが、どなたかこの設定で動かされている方など居られますでしょうか? もしくは素直にVisualStudioなど使ったほうが良いのでしょうか? 昨日からあれこれ試しているのですがまったく動かないです。 >>393 俺ならパッケージマネージャがあるMSYS2+MinGW使うよ。 パッケージマネージャがないTDM-GCCなら、まず、OpenCVをビルドして、リンクできるようにしないといけない。 まあ、めんどうくさい訳で。 初心者はVSやるとよろし。NuGetというパッケージマネージャがあるよ。 片山様 レスありがとうございます。 そうですね、VSは重いという理由で避けていましたがやはりまずはちゃんと王道からやっていこうと思います。 慣れたらソースからビルドもしてみたいですが、まずはOpenCVであれこれしたいのでやりやすい環境で頑張りたいと思います。 ありがとうございました。 VS の統合開発環境を外したツールセットだけの SDK もあったはず。 でもまあ初心者は統合開発環境があった方がいいってのは同意だな。 C++の文字列、u16やu32stringとか乱立してるけど今時TCHARとか使わないでしょうか? string,wstring,u16string,u32string...どれか決め打ち? 主に使ってるライブラリ/フレームワークに合わせれば? 何でもいいなら multibyte で utf-8 一択だろう ucs2 (16bit) にしても ucs4 (32bit) にしてもどうせ 合字とかで1コードポイント1文字にならないから意味ないし コンテナは string でも何でも好きなものを どうやろな? Windows だと API が UTF-16 前提だからそれで揃えるってのは悪くない選択だと思うし。 >>398 TCHARはcharとwchar_tをvisual studioのプロジェクトの設定で切り替えてtypedefしてる型だ マイクロソフトのライブラリの一部 u16stringとu32stringはstd::basic_string<char16_t>とstd::basic_string<char32_t>のエイリアス UTF-16とUTF-32の文字列を扱うクラスで標準ライブラリの一部 そもそもどっちかというものではない std::basic_string<TCHAR>とか使ってもいい OpenCVのビルドぐらいCMakeでGUIでできる >std::basic_string<TCHAR>とか使ってもいい ほんとそれ ていうかWin32APIでサポートされるうちはやっぱマルチバイトが無難 ShiftJisなんて廃止して、UTF8に統一してしまえば良かったよね UTFはソートのコストが高いから痛し痒しだけどね SJISはその点は優秀かと 文字コードを統一したところでロケールの切替えはどうせ必要なわけだし、 内部的な処理が UNICODE に統一されたので良しとするしかなかろ。 utf8に統一したら、ロケールの切替って表示する文字列の言語を決める位の意味しか無いのではないかな 異なる言語の文字列でもそのまま字化けせずに表示出来た方が都合が良いように思うけど Windows はもう 20 年以上前から Unicode 化はやってるんだってば。 UNICODE 版の API を正しく使う限り文字化けしない。 フォントの設定とかで化けることはあるかもしれんけど、 それも今はフォントリンクとかでおおよそ上手いこと処理してまうしな。 UNICODE 化できていない今までに作られたカスなアプリが消し去れないし、 カスなアプリのために ANSI 版の API (の挙動を制御するためのコードページの切替えの仕組み) は残しておかなきゃならないけど、 Unicode への統一そのものは出来てるから満足するしかない。 っていう話ね。 だったらVisualStudioで作ったソースファイルのデフォルトがShiftJIS固定なのをそろそろなんとかしてくれよ LinuxとかのシステムコールもUnicode化されたら考えるわアデューノシ だいたいwchar_tとかcharの倍容量を食うじゃん? 2が3になるとかならまだしも1が2になるというのは精神的にインパクトがデカイ L"Hello World!"のバイナリをダンプしてみたらトラウマを抱え込むレヴェル というのもあるし他環境とのソースコード共通化も視野に入れる場合やっぱマルチバイトしか… WindowsのUNICODE版APIはUTF-8と相性が悪いからクソ せやろか? 内部表現として使う文には UTF-16 って良いと思うけどな。 UTF-8 との間なら変換コストも大したことないし。 >>416 iOS / macOS / Windows / Java と多くのプラットフォームの API で文字列としてUTF-16 が使われてるから割と使うけど、 近年多用される絵文字とかが全然1文字1符号にならんので ロジックを基準する上ではUTF-8より便利ってわけでもない。 文字列の処理を描くときは合字以外は1文字1符号になるUCS4 の方が良い。 なぜ世界中の頭脳を集結させても完璧な文字コードは作れないのか x86アーキテクチャーがRISC-Vに置き換わったら考えるわノシ ていうかコルモゴロフ複雑性が計算可能関数だったら考えるわノシ 韓国がUNICODEにすごい文字数予約済みにしてあるとか聞いたことある >>417 どうせイテレータでアクセスするから、合字はどうしようもないにしても 先頭からコードポイント単位で読む分にはどの符号化を使っててもあんまり変わらん気がするが。 >>423 UTF-16 だとサロゲートペアが出てくるからマルチバイトがマルチワードになるだけ ucs4 だとそれが要らなくて符合とコードポイントが1:1対応になるんだよ。 何年か前まではサロゲートペア?なにそれおいしいの?でも済んでたけど 今の時代それは無理だし 要は utf-8、utf-16 → 1符合 ≠ 1コードポイント ≠ 1文字 ucs4 → 1符合 = 1コードポイント ≠ 1文字 だから完全自作の文字列処理ではucs4が楽だよという意見でした テキストなんてたいしてメモリ食わないしね おしまい charset_cast<utf_8>()みたいなの欲しい おっと、 u16string のイテレータはサロゲートペアは解決してくれないのか。 まあそれも小さなラッパを作ればどうとでもなる。 UTF16でサロゲートでガチャガチャやるくらいならUTF8でちゃんとやった方が実り多いし そんなんやりたくないならUTF32使えばいいし 中途半端だよねUTF16 ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる