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 >>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 どこかでみたけど歴史的にはutf32やutf16よりutf8が新しいんだろ? オリジナルのXEROXのコードへの先祖返りではないかな? visualstudio2017でBoost.Testを試したいのですがうまく行きません。 Nugetでboost-vc141をインストールしてテストプロジェクトをWindowsコンソールアプリケーションとして 追加し、Helloworld的なテストプログラムを書きました。 ビルドは通るのですが、テストエクスプローラーにテストが認識されません。 #include "stdafx.h" #define BOOST_TEST_MODULE MyTest #include <boost/test/included/unit_test.hpp> BOOST_AUTO_TEST_CASE(my_boost_test) { const int x = 1; BOOST_CHECK(x == 1); BOOST_CHECK(x != 1); } VisualStudio2017のバージョンは15.5.7で 「Boost.Testのテスト アダプター」はデフォルトでインストールされるようになっていたので インストールされています。 標準ライブラリを前方宣言にすることに意味ってありますか? newした配列がいつの間にか解放されてて、 プログラムの最後でdeleteすると必ずアクセスエラーで落ちるんですが、 newは勝手に解放されることあるんですか? >>436 どっかで未定義動作に堕ちてるならそんな結果になることもあるだろね。 ・どっかでメモリの取り扱い間違えてnewの管理情報を踏んづけて壊してる ・unique_ptrやshared_ptr、その他スマートポインタ的なものに理解せずに渡してる 多分このどっちか >>436 「解放されてて」というのは、どうやって確認した? たとえば要素のデストラクタが実行されているとか、 別件で確保するメモリに再使用されているとか、 そういうことが起きているのか? >>436 constructor destructor copy constructor operator=() のいずれかに誤りがあるのでは? 概念コードを書いてみなさい >>436 operator new() operator delete() を捕捉するのもいいかもね、根本的に見直す時期だと思う ファイル分割をしてみたく、プログラムをヘッダファイルとcppファイルに分割しようと挑戦したのですがよくわからないエラーが出まくります・・ プログラム超初心者なので凄い初歩的な部分を間違えているかもしれません・・・ エラーですが、ヘッダファイルの方で 'vector':'std'のメンバーではありません 'vector':定義されていない識別子です 'string':定義されていない識別子です 'cv': 識別子がクラス名でも名前空間名でもありません。 'Mat':定義されていない識別子です 'ofstream':'std'のメンバーではありません 'ofstream':定義されていない識別子です みたいなエラーが出ます。 ヘッダファイルは、二重インクルードガードと関数のプロトタイプ宣言しかしていないのですが 上のようにそ、のプロトタイプ宣言の型とかに対してのエラーが出まくります 何かヘッダファイルに付けたほうがいいのでしょうか? 分かる方がいたら、教えていただけますでしょうか。 ちなみに、visual studio で作業していて、プロジェクトはコンソールアプリケーションで作っています。 もしかして、自分でmakefileとかを作る必要があるのでしょうか? ヘッダーの方で #include <vector> などが足りないのでは。 ヘッダーは、自己完結にした方がいいらしい。 よく見たら、自分の参考にしていたページでヘッダファイルのincludeは最小限に抑えると書いていました… てっきり、ヘッダファイルではincludeはしないものなのかと… 最小限というのは、エラーが回避できるstdio.hとかの最小限のファイルだけヘッダでincludeして、他のmath.hなどはcppファイルでincludeすればいい感じですか? 最小限というのは、コンパイル時間、ビルド時間を短縮するためだから、小さなプログラムでは気にする必要はない。 cppとhppで#includeを分けるというのはよくあることだ。 >>443 の書きぶりからして 自作のヘッダファイルに std::vector を使った関数のプロトタイプがある、 しかしヘッダファイルの先頭では <vector> を#includeしてない、て感じね。 これは >>444 と同じ話。 あと >>445 で <stdio.h> と書いてるところを見ると 参考にしてるページは少々古い情報かも。 「あえて<cstdio>でなく<stdio.h>をインクルードする」ことについて 何か理由があるのかも知れないけど。 Cソースのincludeの位置にヘッダファイルの中身を貼り付けたときにコンパイルできなきゃだめ たぶんCソースの中で他のincludeよりも前に新しいヘッダファイルのincludeを書いてるんだろう >>448 なるほど、cstdioの方が良いんですね なんか二種類あるけど、どっちなんだろーと思ってたので、勉強なります 次からそちらを使います C++のリファレンスとかで[first,last)というふうに左右で括弧が違う表記があるんだけど、これはIteratorに関しての表記ですか? >>452 数学方面の書き方を源流にしていると思います [x, y) は x は含み、y は含めない半開区間を示しますが、それを類推したものでしょう >>452 範囲の数学的な書き方、半開区間とかなんとか それだとfirst以上last未満の範囲、ということ >>453 ,454 数学でしたか!勉強になります。 mutex g_Mtx; int g_Val = 0; int Func( int A, int B ) { int Val = A * B; lock_guard<mutex> Lock( g_Mtx ); return g_Val = Val; } void ThreadFunc0() { int Val = Func( 2, 3 ); // Valを参照する処理 } void ThreadFunc1() { lock_guard<mutex> Lock( g_Mtx ); // g_Valを参照する処理 } 上記のようなスレッド関数が非同期に実行されるとき、 Func()はスレッドセーフ(g_Val書き換え中に参照されない)でしょうか? (1)lock_guard<mutex>によるミューテックスロック (2)g_Valの書き換え (3)戻り値を呼び出し元スレッドにコピー(あるいはムーブ) (4)lock_guard<mutex>がスコープから外れアンロック というシーケンスを期待しています。 endならともかくlastは区間内の最後の要素なんじゃ… 基本的な質問なのですが、以下のプログラムがエラーになるのはなぜでしょうか? char* pc = "abc"; pc[0] = 'z'; cout << pc << endl; 以下のプログラムでは意図通りに動きます。 char ac[] = { 'a', 'b', 'c', '\0' }; cout << ac << endl; ac[0] = 'z'; cout << ac << endl; >>459 上は変数 pc はリテラル文字列の先頭を指すポインタ。 下の変数 ac は配列で、それを文字列 "abc" で初期化するって意味。 リテラルの破壊は未定義。 破壊しないことをあてにして破壊不可能なセクション (メモリ領域) に配置されたりすることもあるので、アクセスエラーが生じる。 あくまで未定義だから出来ちゃうこともあるし、コンパイラオプションで制御できたりもするけど、基本的にはあかんやつ。 >>458 仮引数名をendにすると関数名のendと紛らわしいからだよ 説明の文中にendが出てくる度毎にいちいち仮引数か関数か断るハメになる >>460 ありがとうございました。 Pythonでimmutableとかいうのがありますが、それでしょうか? すみません、また、ベーシックな質問です。 char* pc1 = 1; → エラー char* pc2 = NULL; → OK char* pc3 = 0; → OK なぜ、2番目と3番目はOKなのでしょうか? char* pc1 = 1; がエラーになるのは、 int 型の値で char* 型の変数を初期化できないからだとすれば、 char* pc3 = 0; もエラーになると考えることもできると思います。 >>462 Python なんか知らんがな。 Python の immutable は Python の immutable であって、それが C++ の何物かであったりはしないよ。 C++ のリテラルを破壊した結果は未定義というのは C++ のリテラルを破壊した結果は未定義という規則であるだけ。 似て感じられたとしても一対一に対応付くような単純なものではないので、 背景にあるメカニズムを理解せずに翻訳して理解しようとするような方法はお勧めできない。 >>464 なるほど、そういう規則だからリテラルを破壊しようとするとコンパイルエラーにするわけですね。 ありがとうございました。 >>465 書き忘れてたけど、 C++ の文字列リテラルの型は const char[] なので、 const 付きでないポインタに渡すと単純に型が合わなくてエラーになるはず。 C だと型に const が付いてないのに破壊するのは未定義ってことになっててあまりにもクソだったから改められた。 >>463 0 はポインタに型変換可能で、型変換した結果が空ポインタと等しいことが保証されてる特別な存在。 (ビットパターンが等しいとは限らないことには注意が必要。) 互換であることが保証されているので、処理系によっては #define NULL 0 として定義していることもある。 余談だが、これはオーバーロードされた関数でうっかりしやすいので気を付けた方がいい。 たとえば関数 foo が以下のような型でオーバーロードされている場合、 void foo(int); void foo(int*); これを foo(NULL) と呼び出すと void foo(int) が呼び出されたりする。 今ではヌルポインタを表すキーワード nullptr が用意されたので、 NULL はあまり使わない方が良い。 >>466-467 ありがとうございました。 >>466 Visual Stuidoを使っていますが、以下でエラーは発生しませんでした。 char* pc = "abc"; cout << pc << endl; >>468 それはISO/IEC14882:1998の4.2で許されていたことに由来する その後ISO/IEC14882:2011のC.1.1で廃止されたが 古いソースを通すために故意に違反状態のままにしている c++の規約に違反にしないためには一度変数に代入する必要があるという事? オプションで指定できるんじゃね? 俺は GCC を使ってるから知らんけど。 違う char const* cc; cc = "abc"; //完全に合法 char* pc; pc = cc; //不適格 pc = "abc"; //CとC++98では非推奨、C++11以後では不適格 pc = &"abc"[0]; //左辺値変形でこう解釈されていて 非constへのポインタに、constへのポインタを代入することになり、 暗黙のconst外しにあたるので、C++11が正論 pc = const_cast<char*>("abc"); //C++11以後ではこう書く >>472 それもだめじゃね? const領域に非constでアクセスするなんて罪深いことなんだから、ちゃんと別領域にコピーしてから扱わないと。 >>459 >char* pc = "abc"; 文字列リテラルは不変だから、const を付けないといけない 古いライブラリで、const を付けていないものを動作させるために(互換性)、 例外的に使う場合だけに許される >>463 >char* pc3 = 0; → OK この0 は、数値型の0じゃない。 予約語を増やすのが嫌だから、= 0 と書いたら、特別な意味に解釈する。 分かりにくい、クソ仕様 virtual func( ) = 0; これも、そう。 純粋仮想関数という特別な意味を表す >>473 書き込まなければ問題は無い。 が、 const 外しが必要な状態ってのが良くないことは確か。 >>474 いいや数値型の0だ 翻訳時に0と確定できる汎整数型の定数に限り ポインタに暗黙変換できるという特例になっている 純粋仮想関数と関連付ける条項はない ■ このスレッドは過去ログ倉庫に格納されています
read.cgi ver 07.5.4 2024/05/19 Walang Kapalit ★ | Donguri System Team 5ちゃんねる