C++相談室 part145
レス数が1000を超えています。これ以上書き込みはできません。
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part144
https://mevius.5ch.net/test/read.cgi/tech/1563769115/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1556142878/
■長いソースを貼るときはここへ。■
http://codepad.org/
https://ideone.com/
[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)
----- テンプレ ここまで ----- 前スレ1000>
>vtableがあればdynamic_castもできるのに何でダウンキャストなんだ？
dynamic_castはたいていダウンキャストに使うし、逆にvtableとdynamic_castは関係ないだろ。 > vtableとdynamic_castは関係ないだろ。
おまえさん、そもそもdynamic_castとは何か理解しているか？ あ、ID出るんだったな
「スレ主」としての発言ではないんで気にしないでくれ 整理すると
安全にダウンキャストするにはdynamic_castを使うし
その際vtableが必要
そんだけ ちなみにdynamic_castでアップキャストする場合はvtable要らね
どうでもいいが dynamic castでアップキャストする事あるの？ そもそもアップキャストはリスコフの置換原則が成り立つクラスになってんなら何もしなくも勝手にできる 今まで仕事でRTTI有効だったプロジェクトはひとつもないわ バッチ処理系統の仕事ならポリモルフィズムなんて糞の役にも立たんどころか
かえって有害だわ。 COBOLでもEVALUATE文なんて普通に出てくるだろ
力技でダッセーけどあれもポリモだぞ そういうカスなことやってるからメンテ不能になるんだよ。。 rttiに使う必要がでた時点でc++はミスチョイス
もちろん趣味ならご自由に RTTI嫌ってるけど実際どの程度パフォーマンスに影響するの 正直、初めてポリモの話を聞いたときは
混ぜちまってから後で選別なんてアホだろって思った C++は型の実行時識別をvtblのアドレスでやるからdynamic_castする以上はアップだろうがダウンだろうが対象クラスに仮想関数が一つは含まれないといけない
さもないとゼロコストの原則からクラスにvtblが作られない
ただし、仮想関数であれば良く、必ずしも仮想デストラクタである必要は無い、、、ハズ、、、 >>22
ポリモとダウンキャスト（RTTIを使うか否かを問わず）を混同するとは情け
ﾅｻｽ、 コールバック関数ならいちいちポリモとかしなくとも無名関数とかで良いやんジャバじゃあるまいし、 vtableとvtblでNGしたった(´・ω・｀) >>28
ラムダをどっこかに登録してコールバックしてもらうとき
自分が死ぬとき登録を解除するのが面倒じゃね？
結局thisとpairで登録する羽目に
だったら初めから仮想関数で良くね？ コールバック関数を渡す側がコールバックされるより先に死ぬ可能性があるとか
一体何がしたいのかっていうか、 仮にそうであるとしても死ぬ際に空のコールバック関数に登録し直せば良い
なお関数オブジェクト自体の破棄は関数オブジェクトをコピー渡しなりすれば何の問題も無い >>25
ゼロコスト？ ああゼロオーバーヘッドのことかｗ C言語がなんとか使えるようになりました。
今度は、生産性の向上とstringとか面白そうなので、
C++を学習しようと思っています。
おすすめの書籍があったら、教えてください。
ちなみにC言語の理解は、独習Cで勉強しました。
なんだか、独習C++は実用的ではない気がしました。
知りたいのは、C++のstringとかvectorとかです。
それとも、こういう書き込みはだめですか。 34です。
宣伝みたいになりましたが、
独習C++の新版が出ていました。
書籍は11月、電子ならすぐに手に入るようです。
期待してみます。
ほかにもあれば教えてください。 EzoeRyoのgithubに公開しているcppbook
cpprefjp ただで読めるし「江添亮のC++入門」とかでいいんじゃない?
どうしても書籍が良ければ9/20発売みたいだし どいつもこいつも嵌める気しかねーのか。。
せめてロベールとかビャーネのやつを紹介しろよ。 >>34
もちろんこういう書き込みは駄目だね
まず言語を学ぶ時点で実用性がない
学ぶならフレームワークだね
それにどうせ金にならないんだから、実用性なんて最初ならない C++で生産性は向上しない
学習動機の根本が間違ってる >>35
＞書籍は11月、電子ならすぐに手に入るようです。
電子キンドル版もやはり11月まで入手できないとのことでした cやったばっかの人に江添とか薦めるくらいならc++03のとこから地道に教える方を選択するわ。
あんな糞本でc++なんかいじられると目も当てられん結果になる。 もちろんC++11,14,17,20と教えていくんだろうな？
今時C++03なんて使ってられんぞ 今となっては「auto_ptrはコンテナに入れるな」だの「vectorのメモリ領域が連続してると仮定するな」だのを
初心者に教える方が有害だと思う 基礎が全く出来てない単発だらけのこんなとこで聞くのが間違い ビャーネを勧めるとかw
否定が多いスレ
猫とかやさしいでも、まずは読んどけ。 >>34
最も大事なのは本人のやる気だ
モノになるか否かを本のせいにするようではそれがない
俺自身の経験から言うと
変にかみ砕いたバカ用の本や
筆者の思い込みを熱く語っている本よりも
ドライなやつがいい
具体的には禿の本や規格票が俺にとってのそれだった
必要な情報は客観的事実でどっかの馬の骨の主張じゃない
解らんところをどう攻めるかも自分の頭で考えるのが大事だ >>34
stringとかをライトに使いたいのならサンプルコード探して真似るだけでもいいかと
ただ、stringやvectorがどういう仕組みで出来ているのかはいずれ理解する必要出てくるから
独習みたいな本を手元に置いといた方がいい(>>47みたいに古い本だと一部仕様が違ってたりするけど 言っちゃなんだが、実際使ってみるっつーか
何かソフト書いて覚えるしかないと思うよ
参考書はネットに転がってる文献で十分でしょ プログラミング勉強する前にコンピュータアーキテクチャ勉強しろ https://en.cppreference.com/w/cpp/language/namespace
の
using namespace ns_name; //(5)
という形式の 「using-directive (using 指令)」の説明に
5) using-directive: From the point of view of unqualified name lookup of
any name after a using-directive and until the end of the scope in which
it appears, every name from ns_name is visible as if it were declared
in the nearest enclosing namespace which contains both the using-directive
and ns_name.
とあるのですが、
as if it were declared in the nearest enclosing namespace which contains
both the using-directive and ns_name.
の部分の正確な意味が分かりません。個人的には (5) の ns_name までを含めた行全体が、
「using-directive」であるという理解なのですが。
as if it were declared in the nearest enclosing namespace which contains the using-directive.
であるなら分かりますが。どなたか分かる人にご教授いただければ幸いです。 using directiveにはnamespace以外にも用途があるからと思われ >>54
さっき、名前探索の「優先順位」に違いが出てくるからかもしれないと気付きました。
using-directive を書いた namespace よりも、その親や先祖となっている
namespace で名前が宣言されているかのよに振舞うということは、
その分、名前探索では優先順位が少し低くなります。このことによって
同名の名前が内側に宣言されていた場合、振る舞いが変わってきそうです。 34です。
みなさん、ありがとうございました。
詳しい人多いですね。
stringとかを使えば、pythonやC#みたいに
使えるかなと思ったものです。 C覚えたんならC++やらずに他の言語やってもいいんじゃね。と思った。 他の言語なんかやめとけ
C++かそれが嫌ならRustにしとけ
ただRustは難しいからC++でいいだろう >>57
残念ながらc++に関してはそのうんこを超える入門書がないだわ。 今時本で勉強しているやつは時代遅れ。
情報が更新されるcpprefjp,cppreference等にかなうものはないのだ。 辞書がメインだよ
どっかの馬の骨はこう見ているというのは
あまり１つに囚われずに数多く見聞きして
誰もが口を揃えるのは何かを参考にする程度だ やっぱ言語を作った人が書いた「プログラミング言語（言語名）」を読むのがとっかかりとしては一番良い
言語の設計思想が一番間違いのない形で書かれている（何しろ本人が書いたのだから
最新規格は差分で追えば宜しい
次点はオライリーのやつ「プログラミング（言語名）」 >今時本で勉強しているやつは時代遅れ。
>情報が更新されるcpprefjp,cppreference等にかなうものはないのだ。
なるほど、こういう浅はかな輩がいることを考えるとまだまだ本の価値は下がらんな。 でも今、本の値段が上がってるない？
昔はよく買ってたのに、9,800円ではちょっと躊躇してしまう。 てか導入なら本がいいかもだけど、一度覚えれば更新はネットのコンテンツの方が良いからなぁ
最近仕様更新の頻度が高いから、
最新仕様に追従できている入門書でしかも実績のある奴なんてあるのかね？ でもネットだと最新のものが上位に来やすく、しかも、そのサイトを書いている人は
新しいものを推奨しがちだが、本を読んでみると新しく入ったやり方より
古いやり方のほうが多くの場合には推奨される、ということが理由とともに
丁寧に説明されている場合もある。本を書いている人は経験豊富で、能力も
高い場合が多いのに対し、ネットで書いている人は必ずしもそうではないので
仮に結果は正しいことを書いていても、「理由」は間違っている場合などもある。
だから正しい見解を学びたいなら本の方がよいと思う。
例えばの話、本だと学歴や経歴なども分かって、それと本文の内容を
照らし合わせると「立場」「立ち位置」が分かって言外の内容が読み取れることもある。 本も読んでネットも見て自分で判断するんだよ
一つのソースに依存して信じ込むのはプログラミングの勉強に限らずなんでもダメ >>54
>の部分の正確な意味が分かりません。
訳「ボクは馬鹿です」
>全体が、
>「using-directive」であるという理解なのですが。
まあそのページの下の方にもそう書いてあるな 何の助けにもならず何の意味もない全く必要のないレス cout << sizeof "abc";
これで4と表示されるから
文字列リテラルはポインタだなんて書いてるサイトもあるしな sejukuの侍エンジニア塾ブログじゃねえの？
あそこC言語の説明でやらかしただろ
もう絶対に信用しないよ
読んじゃいけないサイトのトップにランクインしてる
さっさと検索結果から消えてほしい いい加減だよな
うちは64bitだから8だぞ
cout << sizeof "Hello!!" 色々ツッコミどころがあるんだよねあれ
・C言語初心者はスクールがオフィシャルで出す解説を書くべきではない
・掲載前にはレビューするべき
・サイレント修正ではなく、お詫びと訂正を実施すべき 実際糞記事読むくらいなら
ビャーネの本とかeffective modern c++読んだ方がよっぽど良い。 初心者には難しいし使ってる人には知ってることしか書いてない >>84
極端だな。初心者が次のステップに進むにはちょうどいいだろう。 そうか？ここの連中なんてほとんど理解してるように思えんが。。 あるグローバル変数を変更しているpublicメソッドA、Bがあります。
このグローバル変数の排他制御をするために
CCriticalSection cs;
void A()
{
CSingleLock lock( &cs, TRUE ) ;
...
}
void B()
{
CSingleLock lock( &cs, TRUE ) ;
...
}
このようにしようと思ったのですが、Aの中からBを呼び出しています。
どうしたらよいでしょうか？ C++に限らないが仕様が膨大だから一冊の本にするのは無理があるのに
色々網羅して中途半端な本多いよな。特には和書は。 カウント変数を追加し、ゼロで初期化。ロックがかかるときにカウントを１増やす。増やす直前にゼロだったら実際にロックする。ロックを解除するときにカウントを１減らす。ゼロになったら、実際にロックを解除する。 >>87
同じスレッドでAの中からBが呼び出せるのは正常な動作です
逆に同じスレッドでAの中からBを呼び出したとき、Bでロックしてしまったら
誰がロックを解除するんですか？ >>88
安易にそれ勧めない
まず再帰ロック不要な設計にするのが基本 マイクロソフトがgithubにSTLの実装を公開してる。
どんどんオープンにしていくのな・・・
https://github.com/microsoft/STL >>92
それはwindowsのCRITICAL_SECTIONが再帰的ロック取得を認めているというだけで、
普遍的に通用する話じゃない。例えばstd::mutexを使った場合とかな。
>>87みたいなケースでは高階インターフェースのB()とinner_B()を分離するとかが常套手段だな。 >>98
CCriticalSection
って書いてあるからCRITICAL_SECTIONの話では？ >>100
だからwindowsのCRITICAL_SECTIONなら通用する話だけど一般に通用する話じゃないってことだよ。
そういう環境だと
>逆に同じスレッドでAの中からBを呼び出したとき、Bでロックしてしまったら
>誰がロックを解除するんですか？
誰が解除するか心配する以前にBでロックを試みた時点で例外が飛んだりする。 >>87
CCriticalSection cs;
void B_Core() {
/*元々のB()でやろうとしていた処理・lockは抜き*/
}
void A() {
CSingleLock lock( &cs, TRUE ) ;
...
B_Core(); // A()の中からはB()の代わりにこれを呼ぶ
...
}
void B() {
CSingleLock lock( &cs, TRUE );
B_Core();
}
もちろんB_Core()は外部から呼べないようにするべきである。 >>102
それはWindowsのCRITICAL_SECTIONでは再ロック可能にしてある理由の説明なんですが ジャヴァのsynchronizeとか再帰ロックオールOK
なんでかわ知らん
ていうかwait()をsynchronizeでかこわなけっればならないという
謎仕様
意味わからん… まあこんなクロージャとの組み合わせのときにちょっと意味があるのかもしれんが…
// UIスレッド
Handler handler = new Handler();
...
// バックグラウンドスレッド
synchronize (this) {
final Foo thisObj = this;
handler.post(new Runnable() {
@Override
void run() { /*...*/ thisObj.notify(); /*...*/ } // クロージャ内から仕掛け元のthis.wait()を起こす
});
wait();
}
つかnotify()とwait()の1対1対応とかを言語が暗黙のうちに仮定しているからか、
今わかったわ糞が…！！ 謎じゃない
condをどうやって実装するか調べてみ ファイルにテキストを書き込みする際に、
ファイルにどれだけ書き込んだかを取得してプログレスバー的な処理をしたいのですが、
どのようにして書き込んだ量を取得すればいいのでしょうか？ 書き込んだバイト数の合計を数えるしかない。fprintfなら戻り値。文字列ならstrlen。 合計バイト数がわからない場合は最初に全部数えるか、バイト数の代わりに行数などを使う手もある。 頑張ってプログレスバーを実装したはいいがいざ実行すると
一瞬で表示が終り実装した意味あったのか・・と嘆く >>112 の未来の姿がみえる・・ 書き込んだ量を取得することより、書き込み総量を計算するほうが難しい
ですよね。特にプログレスバーが必要になるほどトータル時間の掛かる処理の場合
に正確な総量を計算するとなれば莫大な時間が掛かってしまう可能性が高くて。
だから推定量を何らかの方法で求めるしかない事が多いでしょう。 つーかテキストだろ？ギガ単位のサイズじゃないんなら
一回メモリにバコバコ貯めといて一気にブワァーッと書くほうが早いよいろいろと だな
今のコンピュータなら数十MBくらいガバっと読み込んでいいのに、いまだに少しずつみたいな解説してる本やウェブサイト大杉 プログレスバーとかユーザーの気を静めるためのインテリアみたいなもんなので
過度に精度に凝っても仕方が無い
例えばウィンドーズのファイルシステムで1フォルダに10万個ぐらいファイルがあって
それをリモートのウィンドーズのファイルシステムにコピーするとかな場合は
ファイルのトータル容量とか気にせずに
進捗率(%) = 100 * コピーしたファイル数/10万個ぐらい
でも役に立つ いやプログレスバーは「きちんと」「しっかり」作らないと
ユーザーのイライラゲージを却って煽ることになるぞ 長らくぴくりとも動かなかったプログレスバーが一気に進んだとき
ユーザーに爽快感を与えることができうる >>122
自分でそれを見たらイライラするタイプだろう 99%で止まるやつはイライラするな。
進捗率よりも、書き込んだバイト数とか表示してくれると動いてるのがわかるから好きだな。 progress_displayたん…どうして死んじゃったの… 全支店のファイルを集計するツール作った時
九州支店とか遠方の支店に入ると突然90%とかから進まなくなって
イライラおじさんに「なら最初から期待させるな」みたいなお説教された思い出
そこの回線だけやたら細かったというオチなんですけどね
今ならどうやって作るかなあ？
前処理で軽くテスト集計して予想回線速度をチェックしたうえで
拠点ごとに速度の重みづけをして見積もるか？
きちんとやるなら面倒だけどやるしかないよな
それとも運用方法の変更なりで逃げるか
プログレスバーの工数見積り怖い・・・ 処理中のファイル名をリアルタイム表示して
進捗率の方はあくまで参考値という体にする手もあるか
あとは費用対効果を説明してこれで我慢してもらう交渉でって感じで
キャンセルボタンも付けるべきだよな上司はイランて言ってたけど プログレスバーの下に店名と店長の名前表示すりゃいいじゃん その支店に接続するのにかかった時間を計測しておいて
それをベースに表示してみたら 接続先と毎秒の処理したバイト数でも表示すればいいんでね。 >>129
店長の名前は関係ないだろ
うっかり考え込んでしまったわ あるクラスのインスタンスを生成するときに、必ずあるメンバを初期化してほしいとします。
このとき、コンストラクタで初期化することにしたのですが、初期化は必ずやってほしいためデフォルトコンストラクタは禁止したいです。
デフォルトコンストラクタを禁止するのはどうやりますか。 >>137
モダンなやり方は = delete;だろう。
古臭いやり方はprivateにして定義を書かないようにすれば、アクセスできないようになる。 どうでもいいがC++界隈はハチミツギョーザとか蟻人間とか
なかなかユニークなコテが多い印象 >>138-139
ありがとうございます。
やりたいことそのものです。 キャンセルボタンなしの進捗ダイアログ表示して安心してたらESCキーで閉じられて不正動作 >>141
「蟻人間」のコテは最近それに改名されたものですよ… Visual Studio 2019 C++ community editionを使用して
PythonをC++で使いたいのですが、
Pythonライブラリーの Python.h ファイルに
#pragma comment(lib,"Python37.lib")
といった記述があり、それがリンクエラーの原因となっております。
プロジェクトプロパティ＞VC++ディレクトリ＞ライブラリディレクトリには
「$(Path)libs」と記述して、パスは通したのですが改善されません。
これのリンクを通したいのですが、どのようにして対処すればよいのでしょうか？
お願いします。 $(Path)という定義済みマクロが無いか、あるいは環境変数PATHの内容が
そのまま（つまり複数のパスを「;」を挟んで連接した文字列に）展開されているのかもしれんから、
展開結果を確認するか、それができないのであれば
絶対間違いのない絶対パス指定でうまくリンクできることを確かめてから改めて来なちゃい >>146 さん。ありがとうございます。
絶対パス指定ならリンクは通りました。
ただ、相対パス自体はあるのですが展開結果が連結しているようです。
重ねての質問になるのですが、
#pragma 等で相対パスを使用する際に、
相対パスが連結している場合はどう対処すればいいのでしょうか？ ライブラリをソリューション相対指定可能なフォルダに置いて
Visual Studioの定義済みマクロ（$(SolutionDir)なり$(ProjectDir)なり）を正しく使えば良いだけの話なのでは…
あるいは、ライブラリのインストール先が決まっておりライブラリの位置を勝手に動かせないということであれば、
絶対パス指定で何の問題も無いはず…
ソースコードなりプロジェクトファイルなりに絶対パス指定が書かれることによるプロジェクトの可搬性が問題になるなら
適当な環境変数を設けてそれにただ1個のパスだけ定義して$(環境変数名)で展開させるか、
絶対パス部分をVisual Studioの機能でユーザーマクロ定義して最小化することができうる
※ [表示]→[その他のウィンドウ]→[プロパティーマネージャ]、とすればプロパティーマネージャータブが現れるので
そこで継承元の設定を変更でき、その中でマクロのユーザー定義が可能
いじょ 耕運を祈る、 std::variantってテンプレートによる静的ポリモーフィズムを実現しつつ一つのコンテナで管理したいという要求から生まれたんでしょうか
であるとしたら今後継承による動的ポリモーフィズムは下火になっていくのでしょうか > std::variantってテンプレートによる静的ポリモーフィズムを実現
継承もstd::variantも実際に格納されている型が実行時まで分からないのだから、
静的(コンパイル時)ポリモーフィズムにはならないのでは? gcc, clang, VC++, その他
仕事で使われるのはどれ？ intelも使われるし、C++ Builderも使われてる iccって高いだけで性能もgccとほぼ変わらないなら値段に見合う利点あるのか？ メニーコアなCPUとSIMDを使ったときのプロファイラが優秀
おそらく 普通に17使うだろ
filesystemやvariant,optional使わんの？ お仕事だとそうぽんぽんバージョンあげられないし
使っていい標準ライブラリのしばりもあったりするんですよ
特にプラットフォーム抽象する系はあんまり使わない
そんなのにべったり頼るぐらいならc++でなくてよくね？ってなる 最近はmsvcがバイナリ互換保ち続けているから安心してあげられる。
gccやclangはもともと対応早いから安心だったし。 >>160
filesystem使って見た？
まだ荒削りで所々変なところがあるけど
方向性としてはいい線ついてると思うぜ あ、こいつバギーなライブラリ入れて現場荒らすタイプだわｗ 勝手にライブラリ追加できる時点で糞みたいな職場じゃね まあケースバイケースだろ
ポンポンバージョン上げられないって言うだけで古い環境使い続ける職場もどうかと思うし >>162
ファイルシステムまわりはこてこてにネイティブ依存の内製のものがあるので出番はないでしょうね
パフォーマンス第一の仕事なもので
あと標準ライブラリはデバッガやプロファイラのことがスコープ外なのでそのあたり自分達で整備しないと採用できないってのもある なるほどね
パフォーマンス第一か
どっちかつーと標準なんぞ糞くらえつーか
標準の意味が違ったりするわけか 同じじゃん標準ライブラリは一般性重視故に特定の問題領域において必ずしも最高の性能は発揮しない（最高の性能となる保証がない）ことは確定的に明らかよって80-20の法則の80部分からﾊﾟﾌｫﾁｭｰしていく てかc++でやることじゃねーだろどう考えても。
糞の役にも立たんわ。 汎用性・可搬性を重視するかパフォーマンスを重視するかのスタンスの違いだけでしょ >>173
filesystemみたいなライブラリの実装。 visual studio 2019 16.3でついにconceptが使えるように（赤線でるけど。。。 このスレはwinapiを扱ってますか？
sendmessageとか。 >>188
win32api ならやってる人は少なからず居ると思います 文法とか開発思想の初歩的な質問なんだが、例えば最大流問題を解くプログラムと最小費用流問題を解くプログラムで「Edge」という構造体や「dfs」という関数の意味を変えたいときに使うのが名前空間だという理解でOK？
（関数の意味を変えたいだけなら名前空間じゃなくて別のクラスを用意すれば良いだけかな？）
あと、名前空間の中でグローバル変数を使うのは通常のグローバル変数と同じで慎重にやった方が良い（と言われてる）？
例えば最小費用流問題を解くときに経路の情報を記録したりするんだが、この経路を mincostflowという名前空間におけるグローバル変数にするとか 名前空間は名前をまとめるだけであって隠蔽したり上書きしたりする機能はない
素直にクラス使え >>192
そのくらいのプログラムでは名前空間は使わない方がいい。
使うべきなのはクラス。 いや同じ識別子を違う意味で使いたいのなら名前空間だ
名前をどうかしたいというだけでクラス化するといらん制限がかかって邪魔なだけ >>192
その例では明らかにグローバル変数を使う必要はない。
「最小費用流を解くクラス」のメンバに押し込めるのが普通だと思われる。 名前空間は一連の処理や機能をライブラリとしてまとめるときに他のライブラリと名前衝突しないようにするためのものだ
minとmaxの違いだけなら名前空間分けずに変数名や関数名に直接反映させればいいのでは >>197
個人的には自分もそう理解しています。
自分が作るプログラムでは namespace は基本的に使う必要はほぼ
有りません。古い時代に既に作ってしまったプログラムで名前が衝突して
困るような場合に使うと便利な機能として登場したのではないかと思っています。 せっかくの回避策をマクロでばっちり透過してくれた素敵なマイクロソフトｗ >>198
昔作ったものに対してだけでなく、いま作ったものが将来使うときに名前の衝突を回避するという目的もあるぞ。 なぜ日本人c++プログラマの99%はstd::vectorもstd::find_ifも見たことすらないのだろう。
c言語風の生ポインタ、生配列、if文、for文のみを使ったプログラムしか読めない。
外国の人でそういう人は見たことがない。 体感で8割ぐらいかな
まず規格があって改訂されてるってことも知らないのもいる
これは他の言語にも言えることだが
職場で使ったことのあるJavaやPHPのバージョンと環境がすべてみたいな C++20に入るauto変数を使った簡易関数テンプレートは宣言と実装を分割してコンパイルできますか？ vector知らんのはいたとしても組み込みマンくらいだろ >>206
多分戻り値型と同じで、1つの翻訳単位内ならできると思う
宣言だけヘッダに書いたりするとautoのままだと呼び出せない >>208
組み込みマンはC言語だろ
C++使っててstd::vector知らないのは流石に勉強不足 >>210
組み込みマンだからprinf知りませんみたいなもんだなｗ vectorの存在は知っていても中身は知らんやつばっかだろ
いまだに生配列の方が速いとか言ってるやついるし まあ実際計ってる奴はそんなにはいないわな。
てきとうな演算するくらいなら配列だろうとvectorだろうとほとんど変わらん
(ただしコンパイルオプションによる。
O2 ならそんな変わらんが最適化しないとvectorは本当に遅い。) まあ最適化有効にすれば、すればそこいらの玄人が生配列でごちゃごちゃ書くより速くなることが多いがな サイズを変えない操作でvectorと生配列の効率に違いなんかないだろ ただ最近のc++の最適化前提のスタンスはいただけないな
デバッグのためにデバッグビルド使おうとするが一桁二桁遅くなって実用に耐えないとか
問題再現できないとか多々あって困る >>217
そういうのはコンパイラベンダに言わないと変わらないでしょ。
言語規格としては知ったことではない。 もし最適化の有無で速度の変わらないコードがあったとしたら、まず間違いなく人が読めるものではないだろうな こういう開き直りのスタンスって何か固有名詞ついてなかったっけ？
マッチポンプではないし・・なんかなかったかな？ >>219
Cはコードはそこまでひどく遅くならないからね そのおかげで実行時の速度と抽象化した書き方の両立ができるのでまあ仕方ないのでは 仕事でやってるので仕方ないで済まないんですよね
かつ遅いところは自分達では手が入れられないところだったり
こういうところ共感できる人いないのかな >>224
10、100倍遅い問題がPC買い替えてなんとかなると思います？
あと使ってるPC結構いいスペックですよ
開発環境には金かけてくれる会社なんで 仕事でやってようと高水準言語とはそういうものなのだから仕方ないものは仕方ない
仕方ないで済まされないなら仕事をやめるしかない
仕事は不可能を可能にするものではない
そんなに最適化が気に入らないなら最適化なしでリリースすりゃいい
プロダクトとデバッグ環境が同一になる 仕方ないで済まないのでc++使わずc使うっていう話だな。
そこまで無理してc++を使う必然性はない。
結局組み込み系で行われる判断というのはそういったものなんだろう。 じゃあ使わなければいい終わり
苦行を強いられているなら文句を言わずに甘んじて受け入れてくれうざい
デバッグができないくらい時間がかかるのであればデバッグ用にデータを減らすかデバッガを使わずにデバッグすればいいだけ c++の問題を指摘したら自分が否定されてる気持ちになる人ですね？
こういうのって何か固有名詞ついてましたよね？
心理学かなにかの 自分以外は仕事でC++使ってないと思ってるのかねえ C++の問題ではなく、トレードオフなものを両取りできないことに腹を立てている馬鹿の頭が問題 debugバージョンでもinline有効にすれば良い >>217
問題再現できないのってUB踏んでるんじゃ... c++ほどサンクコストに引っ張られる輩を作り出す言語はないだろうな。 そんな掘ってもしょうがないところが深くても邪魔なだけなんだよ。 速度や効率を度外視すれば実はプログラミングはものすごく簡単になることが多い。
ところがそれだと劇的に遅くなってしまう。うまく工夫して書かれたプログラムの
所要時間を1とすると、何にも考えずに書かれたプログラムの所要時間は、
100兆位になることがある。そこまで極端でないにしても何にも考えなければ
100位にはなる。その意味で高速化を常に意識しながら組むことは結構
大切な事だと思う。特にアルゴリズム的な部分においては。 アルゴリズム的に改善できる話なら言語関係ないじゃん 固定少数が速いとかdoubleよりもfloatが速いとか割算は遅いから掛け算だとか色々な噂聞いたけど・・・
今時ほとんど変わらんよね？ https://ideone.com/p9ISAq
これなんで通らんのやろう？
コード補完で読み切れないのはいいけど、コンパイラさんは読めても良いのでは？ class A :public T...{
にすりゃ通る もしくは
struct A :T...{
継承元にアクセスできんのが原因 >>247
自分で作っておいてあれだが、なにに・・・つか・・・えるん・・・だ・・・。ぐああああ。
考えれば考えるほどもやもやする。 ヴェーダに接続するときに使うんかいな。とかおかしなことしか思い浮かばねー。 >>217
この場合に A<B,C,D>とした場合、public T... の部分は、
public B, public C, public D
と展開されるんでしたっけ？ >>193-194,196
では、Edgeという名前の構造体の定義を問題によって変えたいときはどうすれば良いですか？ >>241
今どきのプロセッサではdoubleは速いよ
doubleは専用チップ積んでるから。floatはdoubleに内部的に変換かけられるから、原理的にdoubleより速くはならない いや、今時のプロセッサはSIMDで不動小数点演算するからdoubleよりfloatの方が速いよ
演算やプロセッサによるが、大抵2〜4倍差が出る floatが早い今どきのプロセッサってGPUの話か？
ちゃんと区別しろ 直前の計算結果を次の計算で使うようなありがちな状況だと、SIMDじゃ一切早くならないのでは？よく知らんけど x86とかも典型的だろ
doubleよりfloatの方が倍速いよ
最近はbfloat16の方がさらに速いまである SIMDで1語で複数のfloat演算を並列にやったら早くなる
しかしコンパイラの最適化が普通はそこまでやってくれない 今はfloatのが速い
amd64出てからsse基本なので
昔とは状況が違う >>253
1個のプログラムの中に一個か二個の float しか使わなくても、 double の場合より速くなるのですか？
そもそもイントリンシックを書かないのに SIMD のコードが出力されるのですか？
私は、コンパイラは fpu のコードしか吐かないじゃないか？って考えています 速さ計測すればいいじゃん
逆アセンブル見ればいいじゃん >>262
1個のプログラムの中に一個か二個の float しか使わなくても、 double の場合より速くなるのですか？
そもそもイントリンシックを書かないのに SIMD のコードが出力されるのですか？ そもそもx64ではFPUは無かったことにされている
doubleやfloatの計算したかったらSIMDで1レーンだけ使って計算する仕組み >1個のプログラムの中に一個か二個の float しか使わなくても、 double の場合より速く
その条件だとどっちを使っても良い大して変わらん
やっぱループアンローリングできるぐらいループリッチな課題でないと意味が無い
https://www.isus.jp/products/c-compilers/compiler_part2/
https://cpplover.blogspot.com/2015/03/blog-post_30.html >>265
いいえ x64 でも fpu コードは使えますよ、嘘はやめて！ >>228
こういうやつって何かしらソフト完成させたこともない初心者のクセしてイキってるんだろ
マジ邪魔だから消えて欲しい
テンプレート使ったコードで遅くなるというのがわからんならboostのspiritとか使ってみたらいいわ
言ってる意味わかるから あ、もちろんデバッグビルドの話な
最適化ありならspiritは当然速い C++を使わないと言っているやつに、どうぞご勝手にということと何の関係が？ >>268
でもアセンブラで直接使わないと無かったことにされるだろ >>261
amd64でfpuコード吐かせるほうが手間じゃwwww そもそもプログラム中に一個か二個の浮動小数点演算なんて最適化ポイントちゃうがなwwww
自説を通すためにバカな例を仮定するアホに絡むだけ無駄やなw >>272
プロジェクトの設定でfpも選べるよ
既定だとsse使われると思うけど コンパイラの種類変わったら算術演算ぶん回す場合は結構差が出るだろうけど、同じコンパイラでバージョンかわると最適化とかの進化で結構かわるのかな？
gccの3と4、msvcの2005と2017とかそういう違いで 質問です
既にクラスHogeとAがあり
クラスAとは別に新たにクラスBを追加することになった
BはA専用の関数が無く呼び出す必要も無いし逆のことは無い
その場合BにA専用の関数と同じ名前の空の関数を用意するか、呼び出されているHoge内で切り分けるかどちらの方が良いですか？
なおAは絶対に継承しなければならないし改変することもできない
class Hoge : A か class Hoge : Bをプリプロセッサかテンプレートで切り分ける
これを
void Hpge::func() {
A_func(); //Bは持っていない
}
プリプロセッサで切り分けるのが良いのか
void Hpge::func() {
#if defined(USE_A)
A_func();
#endif
}
それとも空の関数を書いた方が良いのか
class Hoge : B {
A_func() {}
}
詳しい方がいたら教えていただきたいです
これ以外の賢いやり方があればそれでも大丈夫です 絶対に、の理由が知りたいところだけど、普通はA_funcを仮想関数にしてBは空関数でオーバーライド。 c++17以降ならif constexprとstd::is_sameでできるんじゃない？
template < typename T >
class Hoge : T{
void func() {
if constexpr(std::is_same<T,A>){ //基底クラスTがAであればA_func()を実行する
A_func();
}
}
} std::is_same<T,A> じゃなくて std::is_same_v<T,A> か >>278
HogeがAかBを継承するんだからそれじゃだめやろ
ただ設計見直したいところだけどそういうわけにもいかんのかね ｃ++17が使えなくて、Bの定義を関係ないAのために汚染したくないなら一層増やせばいい
template<typename T>
class HogeBase;
template<>
class HogeBase<A> : A {}
template<>
class HogeBase<B> : B { A_func(){} }
template<typename T>
class Hoge : HogeBase<T> { /*...*/ } >>277
基底クラスを切替たいってこと？
しかも片方の基底クラスにしかないメソッドを派生クラス側で呼出すとかどんな状況なんだろう…
まあ、やっつけでやるなら素直にB側に空のメソッド追加しとけばいいと思うよ
どう見てもまともな設計じゃなさそうだし、かと言って設計を見直すこともできなさそうだしね
プリプロセッサなんて愚の骨頂にしかならん >>283
A_funcを持つものを継承するならオーバーライドが理想的だろうけど、基底がAかBってことだから無理っしょ
しかもAは書き換えられないときてる
すでに言われてるようにテンプレートで基底を指定させるか単純に空のA_funcを書くか、プリプロセッサか
でもそもそも利用者側がAを使うのかBを使うのか決めるのなら、クラス側で対処せずに利用者がプリプロセッサで分けた方がいいと思う(でないとぐちゃぐちゃになりそう)
それだと修正箇所が多すぎるのかもしれんけど こんなマトモじゃないケースに
ベストな解答なんかないわな 回答ありがとうございます
プリプロセッサまみれになるより空の関数生やした方が見通しよさそうですね 旧版は知らんけどQt5はかなり良いと思う
不満に思うのはベンチ厨くらいでは >>291
便利かどうかなんて言ってないのにいきなりどうした？w コンパイル通らないので助けてください。
メンバテンプレートを持つクラスを継承して、派生先からメソッドが呼べません。
一見問題なさそうにはみえるのですが・・・
template<typename _T1>
class A{
public :
template<typename _T2> _T2 get() { return _T2(); };
};
template<typename _T3>
class B : public A<_T3> {
std::string hogehoge() { return A<_T3>::get<std::string>();}
}; >>294
clangさんが教えてくれた
std::string hogehoge() { return A<_T3>::template get<std::string>();} ありがとうございました。
通りました。
つか、そんなtemplate文の使い方初めて知った・・ この場合Aがテンプレートなので、Aの先のgetが何者かコンパイラは判断つかないので
"<" が比較演算なのかテンプレートのかっこなのか判断つかないから
らしい
clangは教えてくれるんだから判断ついてるわけだが・・・
まったく醜い文法を持った言語だよ この場合のエラーメッセージ、GCCはほんとに何言ってるのか分からないのを出すのでclang様様 C++テンプレートのプログラミングでのエラーを読み解く訓練をしているうちに
実世界での初心者が投げてくる質問へのエスパー力がやしなわれる
これ豆 そのうちエラーメッセージを見ずにエラーを修正できるようになる ちなVC2015か2017か忘れたけど、一時期までのVCは
その場合のtemplateを書くと逆にエラーにされてた goで変数用いて
*******
*****
***
*
***
*****
*******
って出力するにはどうすりゃいいのっと >>305
申し訳ないが初心者ゆえ、数字の二重ループはできるけどそれを文字列にする仕方がわからず >>298
なぜか偶然ですが、このスレを見る前から昨日からその辺に関係するパーサーを
作っていて悩んでいたところなんですが、
多くの言語では、+,-,*,/,<,> などの演算子が混ざったいわゆる「数式」は文脈に依存せずに
上位のコンパイル作業に入る前に、いったん「数式ツリー」に直すことが出来ます。
ここで「文脈に依存せず」というのは、変数名、関数名、型名などの宣言情報を
調べなくても済むという（いわゆる意味解析の結果の情報を必要としないと言う
）ことです。
ところが、template機能が入った後のC++では、A<B と書いたとき、
< がテンプレートの記号なのか比較演算子なのかは A がテンプレート名であるか
どうかによって決まります。
Bが型名であることが明確な場合には文脈によらず < はテンプレート記号だと断定
できます。ところが、Bに 1, 456, 3.1415 のような数値や、"Hello" などの文字列
が来ている場合には、（その場では）判断が付きません。
文脈に依存せずに判断を付けたいなら、もっと先まで呼んで、< に対応する >
があるかどうかを調べるといける可能性があります。
1. "<"に対応する">"が存在するかどうか調べれば、これまでの宣言情報を使わなくても
トークン・ツリーを作ることが出来る。トークン・ツリーと言ったのは、数式とは
限らないからです。例えば、A<B> x[100]; などとすることがありますが、A<B>
は型名であり、数式では有りません。ただし、他の多くの言語では数式ツリーは
作ることが多いのですが、トークン・ツリーはまず作りません。
2. 1の方法を使わないなら、宣言情報を調べて、Aがtemplate名であるかどうかを調べる
必要がある。ところが、Q::A<B> などのような場合があるので、そんなに
単純な作業でく、Q::A が型名なのか、変数名なのかはちゃんと調べる必要がある。 >>308
補足
「Bが型名であることが明確な場合には文脈によらず < はテンプレート記号だと断定
できます。」
の部分ですが、B<CPerson(実引数列) などとした場合、CPersonは型名ですが、
CPerson(実引数列) 全体は、型名ではなくCPersonクラスの引数つき
コンストラクタを呼び出した結果の「一時オブジェクト」です。なので、
Bが変数名の場合は、< は比較演算子の可能性があります。 >>308
誤：なぜか偶然ですが、このスレを見る前から昨日からその辺に関係するパーサーを
正：なぜか偶然ですが、このスレを見る前の昨日からその辺に関係するパーサーを
誤：文脈に依存せずに判断を付けたいなら、もっと先まで呼んで、< に対応する >
正：文脈に依存せずに判断を付けたいなら、もっと先まで読んで、< に対応する >
誤：単純な作業でく、Q::A が型名なのか、変数名なのかはちゃんと調べる必要がある。
正：単純な作業ではなく、Q::A がtemplate名なのか、変数名なのかはちゃんと調べる必要がある。 >>225
>>224=228や>>226=219みたいなどうみても初心者なヤツにプロが敬語使う必要ないと思うよ
C++スゲー=俺スゲーみたいな明らかにプログラミングに向いてない精神構造のクソバカが多く居るからねここ >>306
一般論として、文字列の長さを len として、文字列型の変数を str としたとき、
for ( len 回のループ ) {
str = str + "*"
}
で行けます。 >>313
すまんな図星だったか？
邪魔だから出てけよ >>308
C++言語をパースする方法として、結論的には、2.ではダメで、1.でなくてはならないようです。例として、A<実引数列>::B の場合を考えると、template は実体化する
際の実引数によって展開される内容は大幅に変わりますので、
A<int>::B とした場合には、B は template 名で、
A<string>::B とした場合には、B は変数名であることもありえます。すると、
A<int>::B<C> の場合の B<C> は template 実体化ですが、
A<string>::B < C の場合は、変数B と変数 Cに対しての比較演算となります。
なので、もし、>>308 の 2.のやり方でパース使用とすると、Aがtemplate名であると
分かっただけでは B が「何なのか」を結論付けるには不十分で、A<実引数列>の
実引数列をほとんど完全に調べ上げてから、その方名に応じた template A の
定義を探して template の overload 解決をしてから、A<実引数列> 部分(のclass)を
完全に「特定」する必要があります。ここまでやるとなると、コンパイラの層分けが
上手く出来ないことになります。 >>315
A::B くらいの場合なら、意味解析の情報だけを元に、Bが何なのかを特定をすることは
可能です。ところが、A<1+2,decltype(x*y)>::B の様な場合、x, y の意味論的な型
を調べた後、x*yに適応可能な operator*() 関数が定義されて言うかどうかも調べ、
定義されていれば、その戻り値の型を調べてx*y の型として、A<・・・> の部分が
結局何なのかを特定しなくてはなりません。今述べた x*y の部分の処理は、
トークン解析層(?)より上位のコンパイル層で行う処理です。なのでこのやり方
だと、コンパイラ内部の「層」の切り分けが難しくなります（技術的に不可能な
わけではありませんが。）。 >>315
誤：なので、もし、>>308 の 2.のやり方でパース使用とすると、Aがtemplate名であると
正：なので、もし、>>308 の 2.のやり方でパースしようとすると、Aがtemplate名であると
誤：実引数列をほとんど完全に調べ上げてから、その方名に応じた template A の
正：実引数列をほとんど完全に調べ上げてから、その型名に応じた template A の
>>316
誤：を調べた後、x*yに適応可能な operator*() 関数が定義されて言うかどうかも調べ、
正：を調べた後、x*yに適応可能な operator*() 関数が定義されているかどうかも調べ、 c++って文法に曖昧さがないことどうやって保証してんだろ
形式的なアプローチ無理だと思うんだが いや、そんな保証は端っから諦めてるだろ
引数なしの関数宣言とデフォコン呼び出しの曖昧さなんか
長年放置してたのをC++11でようやく対応したし
関数ポインタにキャストするoperatorはtypedef使えとか
言語としての完全性なんか重視してない >>319
曖昧さはあるといわれています。例えば、CPersonというクラスがあったとき、関数内で
CPerson person();
と書いた場合、person という名前で、戻り値の型が CPerson の関数のプロトタイプ宣言なのか、
CPerson クラスの person という変数名(オブジェクト名)の定義なのかの曖昧さがあります。
後者は、CPerson person("name", 25, MALE); などと同じ系統で、実引数が全く無い場合
に相当します。
また、template class の場合に、
A<B<・・・>>
と書くと、>> が右シフト演算子に解釈されてしまうので、回避するために空白を1つ入れて
A<B<・・・> >
としなければならなかった(過去形)時代も有ります。
しかし、パーサーを作る側からすれば、">>" を ">" 2個 だと解釈するのはかなり大変な
労力が必要でです。
また、x < y を比較演算のつもりで A< x < y > などと書くと、A<・・・>
の中に x という template class 名に対しての x<y> が入っていると解釈
されてしまい、> が足りないというエラーになるかもしれません。
回避するには、
A< (x < y) >
と書くと良いと思われます。 C++というより３Dプログラミングの質問で申し訳ないのだけど、
行列ライブラリglmの以下のコードがbugってる気がするので詳しい人がいたら確認して欲しい。
template<typename T, qualifier Q>
GLM_FUNC_QUALIFIER qua<T, Q> rotate(qua<T, Q> const& q, T const& angle, vec<3, T, Q> const& v)
{
vec<3, T, Q> Tmp = v;
// Axis of rotation must be normalised
T len = glm::length(Tmp);
if(abs(len - static_cast<T>(1)) > static_cast<T>(0.001))
{
T oneOverLen = static_cast<T>(1) / len;
Tmp.x *= oneOverLen;
Tmp.y *= oneOverLen;
Tmp.z *= oneOverLen;
}
T const AngleRad(angle);
T const Sin = sin(AngleRad * static_cast<T>(0.5));
return q * qua<T, Q>(cos(AngleRad * static_cast<T>(0.5)), Tmp.x * Sin, Tmp.y * Sin, Tmp.z * Sin);
}
クオータニオンqをベクタ軸ｖ周りにAngleRad回転させる関数のソースらしいんだが、
最後の行掛け算の順番が逆のような気がする。
qua<T,Q>(...) * qが正解だと思うんだ。
glmはファイル構成がバージョン間で結構派手に変更されてるんで、
最近のバージョンではext/quaternion_transform.inlに上のコードが含まれてる。
古いバージョンではgtx/quaternion.inlにあったような気がする。 >>322
あるライブラリでのq1 * q2 という書き方が、q2 * q1
がどういう意味に解釈されるかは、 >>322
(>>323 は誤投です。)
あるライブラリでの q1 * q2 という書き方が、別のライブラリでは
q2 * q1 と等価なことが有り得て、それはベクトルや行列計算全般に
言える記法の違いなのでこのソースだけではなんとも言えない。
ベクトルの場合、成分表示を1列の縦行列と考えるか1行の横行列
と考えるかによって、賭け全の左右が逆さまになる。
その結果、成分表示で書かない表記も、左右どちらかで書くかは
好みの問題となる。
特に Quaternion の場合も同様。 >>324
誤：と考えるかによって、賭け全の左右が逆さまになる。
正：と考えるかによって、掛け算の左右が逆さまになる。 OpenGL系は縦ベクトルだね
D3Dを前提にしたライブラリとは逆になる(行列も転置 >>326
数学や物理学では縦ベクトルが多いが、D3Dはそれに従ってない。 テンプレが糞だと思う瞬間はいくつもあるが
その一つはネストしてるときの閉じ括弧
>> じゃだめで > > ってわざわざ分けないといかんうざい ＞数学や物理学では縦ベクトルが多いが、D3Dはそれに従ってない。
みたいだね
D3Dからそれ以外に移るとみんなここで引っかかるけど
実は行列周りは(大文字は行列として)
OpenGLに合わせるとA*B*C*xとなるのを
D3Dではx*C*B*Aと書けた方が、左からの計算が全部結果がベクトルなので計算量が減るというメリットはある
MSはC++での書きやすさと効率を考えたのかもしれない >>326-327
縦横ってより右から掛けるか左から掛けるかだと思ってた
意味は一緒なんだろうけど >>328
C++11からは連続して書けるようになったで C++03いやC++98？のまま更新止まってるやつ
俺が想像するより遙かに多いのかもしかして
もうC++11でさえ要注意な旧規格になってるんだが >>329
メモリ上の順序も変わるぞ
SIMDとかで計算されるときの効率にも影響する
必ずしもD3D(横ベクトル方式)が高速化に都合が良いとは言えないんじゃないか
行列の各要素のメモリ上の並びって
glの行列AとD3Dの行列A'はいちいち転置しなくても結局同じになるんだっけ ああ確かにメモリの中身は同じだった
格納方式も違うから結果的に同じになるんだよね
そこが余計ややこしい >>329
行列計算は、縦ベクトル方式、横ベクトル方式でも、（それぞれで）「結合則」があるので、
A*B*C*x = A*(B*(C*x))
でもあり、
A*B*C*x = ((A*B)*C)*x)
でもあり、どっちで計算しても結果は同じになる。
また、3D計算の場合、点の座標がいくつあっても、行列を一度計算しておくと、
使いまわしできるので、先に行列の方を計算しておいて、最後に座標の変換
を行うと、点が2個以上あるときには効率が高い。 >>332
C++98くらいから、実際問題上使いたくない機能ばかりが追加されるような
傾向があったのに、Upgrade 版は適用外になったりしたりして買う機を逃した。 >>329
>MSはC++での書きやすさと効率を考えたのかもしれない
>>335 に既に書いたけど、OpenGL 形式でも、右結合でも、
左結合でも、好きな方で計算は出来る。だから、行列部分を
先に計算しても良いし、座標部分から計算しても良い。
座標部分から計算していくと一見計算量が減るように思える
かも知れないが、点の個数が多くなると、一度だけ行列部分の
積を予め計算しておいて、その結果を全ての点の変換部分に
遣うと効率が劇的に向上するので、むしろ、効率が良いのは逆。 >>335
確かに(OpenGLでも上で書いたような式が使えるライブラリ使うとして)括弧でくくったりして優先順位変えればいいし
言う通り行列はまとめればいいんだけど
どちらにもメリットデメリットあると言いたかった >>338
実は、アメリカで有名な 3D Graphics の本が、横ベクトル方式を採用していた
事が関係しているかもしれない。要はその本が数学や物理の標準とは何故か
逆の記法を採用していたということ。 >>337
GL
(A*B*C)*(x0(縦),x1(縦),x2(縦),x3(縦), ... , xN(縦))(横)
D3D
(x0(横),x1(横),x2(横),x3(横), ... , xN(横))(縦)*(C*B*A)
が最速やね >>335
行列って結合則は約束されてましたっけ？ 当たり前だろ。
そんなレベルの知識しかないからフォントライブラリ書けないんだよ >>343
ベクトル部分はおいておくとして、まず正方行列の部分だけに限定すれば
A(BC)=(AB)C ・・・(1)
が証明できれば どんな場合でも結合側が成り立つことが数学的帰納法で
証明できます。なので、A,B,C が正方行列の時に(1)を証明すれば全体の証明が
ほぼ終わります。
【(1)の証明】
行列の積の定義により
(AB)ij=Σ_{k=1}^n A_{ik} B_{kj} ・・・(2)
です。なので、
{(AB)C}mn = Σ_l(AB)_{ml}C_{ln}
= Σ_k Σ_l A_{mk} B_{kl} C_{ln} ・・・(3)
です。全く同様に、
{A(BC)}mn = Σ_k A_{mk} (BC)_{kn}
= Σ_k A_{mk} Σ_l B_{kl} C_{ln}
= Σ_k Σ_l A_{mk} B_{kl} C_{ln} ・・・(4)
となり、(3), (4) が一致することから、
{A(BC)}mn = {(AB)C}mn
が言えます。これが (1) に他なりません。 (Q.E.D)
次に、このように3つの行列の場合ではなく、一般の個数の行列の場合、
最初に書いたように数学的帰納法を使います。それは、あなた自身で
お考えください。考える力の練習になります。 doubleの値を++aした時にaの値は+1と規定されてる？ >>345
boolen型以外では、++x は正確に x+=1 と等価です。
x+=1 は、正確に x = x + 1 と等価です。x がポインタ型の場合は、
BYTE 単位で見ると object size 単位で増加しますが、double/float/int/short/char
などの「算術型」の場合は、単純に 1 が足されるだけです。
https://en.cppreference.com/w/cpp/language/operator_incdec
For non-boolean operands, the expression ++x is exactly equivalent to x += 1, and the expression --x is exactly equivalent to x -= 1, that is, the prefix increment or decrement is an lvalue expression that identifies the modified operand. >>346
ありがとうございます。
という事はキャストの時におかしくなっているのかな？
aの値は0.0〜100.0程度
for(double i = a; i < 1000.0; ++i){
std::cout << (int)i << "," << std::endl;
}
期待している結果: 1,2,3,4,5...と連番になる
たまに起こる結果: 1,2,3,5,6...と歯抜けになる >>341-344
また5ch名物のしょーもない煽り煽られの流れかとおもったら
ちゃんと勉強になる流れでワロタ 行列の結合則なんて高校で習っただろ
線形代数わからないプログラマって生き残れないと思うわ >>347
・そのコードは、完全に上記の通りですか？
例えば、ループ回数が1000回より遥かに多くなると、
誤差の都合でそうなることがあるかもしれませんが、1000回くらい
だと、正しい処理系ではその現象は起きないはずです。 キャストする前にlround呼んだらええんちゃうん。 (0.2+0.3)+0.4 == 0.2+(0.3+0.4)の結果がfalseになるのは正しいの？ 10進の0.1を2進表現すると循環小数定期
>>355
バカ乙 >>336
本当、人って色々だな
俺はC++98は未完成感があまりに強くて続きはまだかと待ちかねていた
具体的には例えば右辺値参照だ
一時オブジェクトにいちいちconstがつくのがイヤでイヤで待望のやつがやっと来た >>337, >>340
ちょっと誤解招くのでやっぱ突っ込んでおくけど、
多数のベクトルを変換するのに行列をまとめておかないと無駄になるのはどっちの方式でも同じだよ
俺が言ったのは(少なくとも同一の行列が)一度限りしか出てこない場合の話
まぁそれを最適化する必要があるのか、またそういう処理を大量にループするなら最適化の方法は他にあるだろうけど
>>333
GL方式でも列優先だから結局d3dと同じ無駄はあるんやで
最近のは知らんけど >>353
計算誤差です。
(0.2+0.3)+0.4 == 0.2+(0.3+0.4) が偽になっても
(0.2+0.3)+0.4 == (0.2+0.3)+0.4 や
0.2+(0.3+0.4) == 0.2+(0.3+0.4)
は必ず真になることが保障されています。 >>359
コンピュータにおける浮動小数点は、内部表現は10進数ではなく2進数
で表現されており、有効桁数は 10 進数で 8 桁や 15桁などではなく
2進数で xx BIT という風になっています。
0.2, 0.3, 0.4 は、10進数だと、有効桁数が1桁でも完全に区切れが
よく表現できていますが、2進数の表現だと厳密には無限小数になってしまい、
どんなに有効桁数を長くしても厳密には表現できません。そのため計算誤差
が生じるのです。0.5 や 0.25 や 0.125 は 2 進数でも区切れ良く表現できるため、
(0.125+0.25)+0.5 == 0.125+(0.25+0.5)
は誤差が生じることがないため、必ず真になるはずです。 >>360
浮動小数の計算誤差を考慮して比較する時にstd::abs(a-b) < std::numeric_limit<double>::epsilon()というふうにするのはどう思う？ >>361
誤差の量が計算の順序や書き方によって変わってくるので、
そのようなヘッダに書かれているような誤差定数を使うことは
余り意味がありません。 >>361
機械イプシロンはそういうふうに使うものじゃない cpprefjpが>>361と全く同じ間違いしてたわ馬鹿が湧くのはこいつのせいか
cppreference.comは正しかったからそっち見れ >>365
x-yの元になっているxやyがどのような計算過程を経てきたかわからないのに
std::abs(x-y) <= std::numeric_limits<T>::epsilon() * std::abs(x+y) * ulp
でxとyがalmost equalsと言い切ってよい根拠とは、
ちゅか常識的に考えて、x、yがそれぞれ±e、±gの誤差を有するなら
std::abs(x-y) <= std::numeric_limits<T>::epsilon() * (std::abs(e) + std::abs(g))
あたりの判定に落ち着かねばおかしい（これで正解とは言っていない
なんでstd::abs(x+y)みたいな場合によっては莫大な値になりえる係数を掛けねばならないの？ イプシロンに誤差を掛けても意味ない。
つか、許容誤差の絶対値が与えられているならイプシロン使う必要もない。
cppreference.comのは許容誤差をULP単位で与える場合のやりかたで、
abs(x+y)はxとyの指数のうち大きい方を意味するものだったはず。 >>366
なんか色々根本的に勘違いしてる
cppreference.comのalmost_equal関数の仕事はあくまで与えられたxとyがalmost equalかどうかの判定だよ
> x、yがそれぞれ±e、±gの誤差を有するなら
なにこれ？「誤差」って何に対する何の誤差？ >>367
>イプシロンに誤差を掛けても意味ない。
>つか、許容誤差の絶対値が与えられているならイプシロン使う必要もない。
左様ですなｽﾏﾝｶｯﾀorz
>>368
>なにこれ？「誤差」って何に対する何の誤差？
真の値に対する誤差じゃわﾊﾟｵｰﾝ
真の値に対する誤差に依存しないalmost equal判定とか、使いどころはきわめて限定されるはず、 >abs(x+y)はxとyの指数のうち大きい方を意味するものだったはず。
xが (xの符号)×1.bbbb...×2^m
yが (yの符号)×1.cccc...×2^n
だとしたときに、m>nだとすると
x + y =
{ (xの符号)×1.bbbb... + ((yの符号)×1.cccc...×2^-(m-n)) } ×2^m
として計算されるのでだいたい2^m（x≒yなら2^(m+1））という意味か左様か、 んまーulpをxとyの来歴に応じて調整すべき量とするなら
cppreference.comのalmost_equal関数は理解してやらないでもない だれか、俺に分数を教えてくれないか？
足し算と引き算がマジ解らなくなってるんだ。
https://ideone.com/IfCcGz
一番のネックはネガフラグの扱い。
マイナスとプラスの反転演算でどうかくとスマートだろうか。
だれか教えてプリーズ。 >>377
1. constexprにしてもいいんじゃない？
2. 出力関数作成しよう
template<typename Char>
std::basic_ostream<Char>& operator<<(std::basic_ostream<Char>& os, const Fraction& frac){
return os << frac.GetNumerator() <<'/'<<frac.GetDenominator();
} >>378
1.できなくはない。機械的に接頭語つけるだけでいいよね。
2.暇だから作るわ。
行ってきまーす。 https://ideone.com/uzd7EF
ただいまー。イデオンで動かせるようにした。Gcdがバグってないといいなぁ。
あとvc2019では意味不明なエラーで動かない。 Ｃ＋＋ってなんでヘッダファイルいるんですか
最近マシン早いんだし
全部ソースに書いてインポートすればいいのに >>384
むしろソースがいらなくて全部ヘッダに書けばいい
inline変数とかもできるようになったことだし >>387
たまに趣味で何でもかんでもtemplateでゴリゴリ実装してるとガチでそれになるww プリコンパイルヘッダーって使ってます？
使っているプロジェクト見たことないですわ。 >>387
こういう馬鹿野郎が出てくるからメタプロとかテンプレ好き連中ってのは嫌いなんだよ。 C++なんて趣味でやってるんだからテンプレ好きでもええやん 出てくることの何が嫌なんだろうか
はっきり言って病気だ headerオンリーってのは可搬性に優れた良いものだろ
特にテンプレート多用している奴は、一部関数だけソースファイル分離する意味が薄い >>391
どんなものにだって馬鹿は出てくるだろうに 「全部ヘッダ」と言われると、そのときの「ヘッダ」の定義がどういうものなのか気になる。 >>390
VCのやつは使いまくり
依存するライブラリのヘッダファイルを標準のやつもソリューション内のやつも全部まとめて
stdafx.hの中でインクルードしたらことのほか便利
ただし同じプロジェクトのヘッダファイルを入れだしたら目的を見失って氏ぬ テンプレート関数は便利だしconstexpr関数は市民の義務だし
結局ほとんどヘッダファイルに書くことになるでしょ 初心者ですが質問させてください
print(1, 3.14, "abc");とやると引数の中身を順番にスペース区切りで出力してくれるような関数は
可変引数テンプレートの再帰呼出しを使うと便利にできることを知りました。
そこで引数の型に応じて出力の見た目を少し変えたいのですが、
関数の特殊化をすればいいですか？
typeidだと動的な評価になってしまうんですよね？ 予想通りの馬鹿回答で笑ってしまった。
やっぱいい判別になるわテンプレバカ。 >>400
引数一つに対するテンプレート関数を作って特殊化してそれに少しずつ渡せばできるよ。 C++嫌いなのにいつまで居座るんだろうなこのガイジ こんな雑談スレ好きな奴以外に需要ないだろ
こんな辺境別に見なくて良いんだよ？ >>400
c++17以降ならif constexprとstd::is_same_vの使用を検討してみるのもいいかも 400です。頑張ってみましたがどうにもコンパイルエラーが出ます
難しいですねC++は...
void print() {}
template<class... Args>
void print(const char* c, Args... args) {
cout << "[" << c << "]" << endl;
print(args...);
}
template<class First, class... Args>
void print(First first, Args... args) {
cout << first << endl;
print(args...);
}
int main() {
print(1, 3.14, "abc");
return 0;
} あ、こういうふうにするとコンパイルできました。引数2個の関数を特殊化したからエラーになった？
テンプレートの展開のされ方がよくわからないけど、とりあえず目的のことはできました
ありがとうございました
void print(const char* c) {
cout << "[" << c << "]" << endl;
}
template<class T>
void print(T t) {
cout << t << endl;
}
template<class First, class... Args>
void print(First first, Args... args) {
print(first);
print(args...);
} >>406
いわゆる型特性というやつでしょうか？enable_ifを使うのかと思い試したもののうまくいかず、
ネットで調べるとenable_ifと可変引数テンプレートは相性が悪いという意見を見つけたり... >>409
if constexprを使った例はこんな感じ
template<class First, class... Args>
void print(First first, Args... args) {
if constexpr(std::is_same_v<First, const char*>){
std::cout << "[" << first << "]" << std::endl;
} else {
std::cout << first << std::endl;
}
if constexpr(sizeof...(args)>0){
print(args...);
}
} const char * 自体も class First や class Args と一致するんじゃね First と Argsの二つがあるのがややこしい場合は畳み込み式でもできるぞ
template<class... Args>
void print(Args... args){
([](auto t){
if constexpr(std::is_same_v<decltype(t), const char*>){
std::cout << "[" << t << "]" << std::endl;
} else {
std::cout << t << std::endl;
}
}(args), ...);
} win系のOSの画面に1.txt~5.txtがあります。1.txtと2.txtをドラッグして選択したとします。
この状態で3.txt~5.txtを選択したことにするにはどのようなコードを書けば良いですか？ >>413
ListView_SetItemState std::shared_ptrを構築後に(カスタム)デリータを変更するのは無理？
既にどっかで作成済みのshared_ptrについて、破棄タイミングを後から見れないかなと 別のstd::shared_ptrをカスタムデリータ付きで構築してswapすれば shared_ptrとunique_ptrでdeleterの指定方法が違うってのが興味深いね。 VCのlatestでchar8_tが入ってたわ
やっとC++erが文字コード問題から解放されるんだな >>418
デリータごとswapされたわ
stackoverflowにも似たような質問があったけど結論としては出来ないっぽい
たぶん >>392
別にテンプレ好きでも構わんが、C++ユーザー全員が趣味だと思ってんの？ >>405
雑談以外に役に立つ書き込み出来なくてすみません、ってことか >>423
C++ユーザが全員趣味なんてどこにも書いてないし、あるプログラミング言語が趣味でしか使われてない状況なら、委員会なんていらないわwww 衣食住の確保以外の仕事なんてみんな趣味みたいなもんだよ
なくたって構わんのだから 委員会なんて何の役にもたってねーだろ。
構文解析もまともに理解できてないバカが俺様仕様の理想に突っ走ってるだけのクソ組織で、
仕様の実装、デバッグの手間なんてこれっぽっちも考えてないのがよくわかる。 デバッグできねえのを人のせいにするクズがよく言うぜ 近年は新機能は三大コンパイラ(GCC,MSVC,Clang)での試験実装が入ってから仕様入りするのが普通になってるし
コンセプトなんてまさにデバッグの手間の軽減を第一目的に苦心して作られた機能なんだけど
どのへんを見てよくわかったのか教えて >>431
実装したことないやつは黙っててね。
で、そのコンセプトを実際のコードでコンパイルした時間がどれくらいになるかわかってる？
そういう有用なベンチマークもほとんど出さずに無理やり入れようとするから
信頼を無くしてるんだよ。 経験したことは全て正しいっていう日本特有のアホ理論だろそれ
経験してないお前に発言権は無い、っていう
その理屈を持ち出すヤツは大抵はアホ コンパイル時間は、コンパイラの出力する最適化されたバイナリの実行速度に比べたら問題ではないだろ
しかも構文解析にかかる時間なんて最適化時間に比べりゃ屁みたいなもの 似たようなものを複数書いてもバグ修正時に一部見落としなんて馬鹿げたことになるわけで
マクロでもテンプレートでもまとめられるものはまとめたほうがいいわな c++言語の場合、パースのコンテキスト依存が、識別子の種類でも変わるから、テンプレート時の記述でtypename やらtemplateやらで、識別子の種類自体を指定する羽目になっているのはあるよね >>434
テンプレートふんだんに使ったライブラリ実用してるとひどいことにはなる
アプリ自体は数万行なのにコンパイル10分以上とか >>432
お前が信用しないのは勝手だが、みんなの総意みたいに言うなよ それは本当にパースの複雑さのせいなのかは疑問だな
templateだと、プログラマは簡単にコンパイラの仕事をあまり意図せず増やしてしまいがちだからね。
std visitで引数増やすとコンパイル時間は簡単に増やせるよ。
5つくらいでもうコンパイラが落ちたりする
やらせていることの面倒くささ、それを手書きすることを考えれば妥当なのだけど 最近C++触ってないけど数万程度で10分もかかるの？
10万行程度なら5分以内に終わってほしいところだけど… >>439
かなり遅いです。
ヘッダファイル *.h とソース本体のファイル *.c では事情が違いますが、
OSのバージョンによりますが、Win32の標準ヘッダファイルの windows.h などだけでも
コメントを除外しても2万行弱くらいあります。
これのパースは、VC++で1秒〜数秒くらいです。
通常は、precompiled header を使うので、一つのプロジェクトで一度だけ
パースされることが多いです。
ただし、プロトタイプ宣言やマクロ定義、構造体定義、inline関数定義
などだけで、実際のコード生成は伴わないので、*.c の数万行とは
また事情が違います。*.c はコード生成を伴うので、同じ行数であれば*.hよりも
遅くなる傾向があります。
しかし、それでも、C++98 の場合、数万行だと3秒〜10秒以下でコンパイルできます。 c++の文法のせいでパースが遅いってレベルの話じゃないような ヘッダオンリーのライブラリがポータブルとか言われてもてはやされるのがc++だからね
生産性の意識が間違った方向に向いてる
コンセプトでどうなることやら 俺の10万行程度のアプリは1分以内にコンパイル終わるが・・・
10分てどこの世界だ 「参照の配列」を作りたいときって現状 reference_wrapper を使う以外ないですか？ >>437
プリコンパイルヘッダー使え…！
>>446
VC++2010の場合配列要素のアドレスの配列というのを
それぞれ1万行ぐらい書いてリリースビルドすると10分かかる spiritで構文解析させてたコード(その上et使った自作ライブラリあり)だから例として極端だったかもしれんけどね
プリコンパイルドヘッダは使ってたよ
効いてるときは数分かからなかったと思う
というか5年以上そのコード使ってないんで今のマシンならまだマシになるとは思う boostを多用した10数万行のソースでprecompileありでreleaseビルドしたら10分くらいかかってたけど、debugビルドでは1,2分くらいだった気がする。パースだけなら大したことないけど最適化がかなり遅いと思われる。 翻訳単位が増えると単純に遅くなるし
リンク時最適化でもさらに遅くなる LTOは本当のリリース時や速度検証の時以外は外しても問題ないよね ここの話で出ている
>296
>>294
clangさんが教えてくれた
std::string hogehoge() { return A<_T3>::template get<std::string>();}
>436
c++言語の場合、パースのコンテキスト依存が、識別子の種類でも変わるから、
テンプレート時の記述でtypename やらtemplateやらで、
識別子の種類自体を指定する羽目になっているのはあるよね
<_T3>::templateやtypenameをどの様な場合に書かないといけないのか?
この辺を解説した初心者向けか入門者向けの解説サイトみたいな所が
何処かに有りませんか?
サイトが無さそうなら検索に向いている単語みたいなのでも有れば助かる
::templateとかで検索しても上手く引っ掛からないみたい(有るには有るけど少ない) 他の言語で書かれたコードをスクリプトの要領で
C++から呼び出して実行したいのですが、
そういった事をするのに適した言語ってどういった物があるのでしょうか？ 言語間のABIの違いを透過的にしたいのならアセンブラの出番だね >>457
今ならluaかjs(V8/ChakraCore/SpiderMonkey)だな。
【Lua】組み込み系言語総合 その7【Squirrel】 [無断転載禁止]©2ch.net
https://mevius.5ch.net/test/read.cgi/tech/1474536226/
pythonもできなくはないけど手軽とは言えない。
pythoｎを使いたい理由がなければやめておくのが吉。 pythonは呼ぶ方で、呼ばれる方としてはほとんど想定されてないわな。 >455,456さんどうもです
エラーが出たらそうしてみます
リンク先を読んで見ましたが
自分には難しいのでそのページを手がかりに検索して(依存名で探してみた)
漸く理解出来た気がします
前にstd::を付ける付けないって話を何処かでしてい
自分的にはどうしたものだろうか?
って感じだったんですけど
adlやtwophasenameとかの解説と合わせて書いて有るのを呼んでいて
std::を付けるのはかなり重要なんだと思えてきた
今までnamespaceって単なるグループ名を付けている
くらいの感覚だったんですけど
意外と重要なんですね
どうもでした template<size_t N>
class Test{
public:
private:
int m[N];
};
上の様なクラスでコンストラクタでmを値を指定して初期化したいんだけどNの数は未定ではないですか。
こういう場合のコンストラクタの書き方ってどうすればいいのでしよう？
可変引数？ コンパイル時に決まってないならvectorかなんかにするしかない templateパラメータの整数にはコンパイル時に決まらない数値は入れられない >>466
そもそも、そのような生配列は、デフォルトでは0初期化もされないので、
メンバ初期化子リストを使わなくても効率は落ちないので、
コンストラクタ内部で普通に代入演算子を使って初期化すればいい。
すると、単に任意個数の引数をコンストラクタに渡す問題になる。
それには、昔ながらの va_list を使って渡す方法と、
関数テンプレートやテンプレートクラスを使って、自分自身を一つずつ引数を
減らしながら呼び出していく方法の二通りある。 >>466
Test(std::initializer_list<int>&& arg)
{
std::copy_n(std::begin(arg), N, std::begin(m));
} >>469
一度考えたのはテンプレートの可変引数なんですが
//Testのコンストラクタ
template<typename... T>
Test(T... args):m{args...}{
}
templateの可変引数の為にどんな型でも一致してしまい、そのくせにdoubleからintなどの変換をしてくれないのでinitializer_listを引数に出来たり、もしくはもっといい初期化方法があるのかなと思った次第です。 >>471
>そのくせにdoubleからintなどの変換をしてくれないので
この点に関しては、以下の拡張展開でいけるはず。
template<typename... T>
Test(T... args):m{((int)args)...}{
} templateの「非型引数」を使えば、理論上は、
template<int...args>
Test(int...args):m{args...}{
}
と書ける可能性はあるかもしれないけど、試してみてないので分からない。 C++11 から、template 仮引数(パラメーター）に非型パラメーターパックが使える。
分かっているとは思うけど、このパックとは可変長引数をまとめて入れる容器の様な意味。
実際にやってみてないのでわからない。
https://en.cppreference.com/w/cpp/language/template_parameters
【Non-type template parameter】
type ... name(optional) (3) (since C++11)
3) A non-type template parameter pack with an optional name. >>466
要素数がコンパイル時に決まってるなら std::array 使って Test<3> x{{1,2,3}} とすることは簡単にできそう。 他クラスのメンバ関数テンプレートを呼び出すときってtemplateキーワードを関数名の前に付けないと
operator<と間違われてエラーになりますですよね？具体的に例をあげてみますと
https://wandbox.org/permlink/F7zl1fDh3qc216hd
これの t.template func<T2>(); のところですが、実はこのtemplateキーワードを外しても
WindowsのVisualStudioだとコンパイルが通ってしまいます。
これってVisualStudioが規約違反しているという理解で合っていますか？ vsのバージョンは？
2017の途中からtwo phaseに対応しだしてtemplate周りの怪しい挙動は大分改善された >>480
Express 2017 for Windows DesktopとProfessional 2019で確認しています
準拠モードを「はい」にしたら標準の規約に従うのかと思ったんですが変化なしでした
開発はWindowsでしつつもWindowsとLinuxどちらでもコンパイルできるようにしたいんですが
もしかしてそう簡単な話ではないんですかね >>481
visual studio cmakeプロジェクトでググる effective modern c++のnoexceptの項読んで思ったんだが、
C++の関数内でCの関数（具体的にはOpenGLとか）を呼び出した時に
C++側でcatchできる例外って具体的にどんなものがあるの？
試したことないけどmalloc失敗でbad_allocは飛ばないよね？ >>482
cmakeってビルドに関するものだったような？
ソース自体はWindowsとLinuxで完全同一にしたいんですが
あれなんか自分勘違いしてるかな
とりあえずcmakeくぐります、有難う VCコンパイラがWindows専用だからcmakeだけでは解決しない
clangオプション使えばいけるんじゃね cmakeってなんとなくしか使ってないんですけど何なんですか
OpenCVのソースをビルドするときに使いましたけど、cmakeした後にまたVisual Studioでコンパイルする必要があるのはなぜですか >>487
cmakeってmakeの代用じゃなくてmakefileとかxxx.slnとかを作るソフト
なのでcmake実行後に各々の環境にあったビルドを行う >>487
ビルドするためのスクリプトを作るツール、みたいに考えるといいよ
linux環境ならLinux用のものを作ってくれる
makeだと基本はlinux専用だし、.slnや.vcxprojはwindows専用だから、両方を面倒見るのは大変でしょ ビルドするためのスクリプトを作るためのスクリプトを作るためのスクリプトなんてよくある話だよ。 GNU autotoolsをまともにいじる輩は消え去ったという現実をcmakeも味わうことになる。
バカは同じ間違いをする。歴史も見ずに。 CMakeってKitwareっていう大学発ベンチャーから出てきたやつだよな
もとはVTKとか可視化用ライブラリ開発してるしがないベンチャーだったのに
CMakeのおかげでやたら顔が知られるようになった VTKとparaviewの方が有名じゃなかったのか ParaViewは最近になって有名になってるけど所詮はVTKのラッパーでしょ
CMakeのほうが影響度はでかいと思う
ベンチャーでここまでやれたなら大成功な事例だね cmake邪魔くさい
Makefile.am, configure.acからautoreconfしてconfigure作る方が楽。
windows用もmingwでクロスビルドしちゃえば楽だし。
WSLでwindowsからも見えるパスでビルドすると作ったwindows用binaryをすぐに起動できるしいうことなし mingw使わずに標準のwindowsの環境で使えるようになってから出直してきて makeとかのビルドツールって超重要なはずなのにおざなりな状況になってるのは不思議だ
なんとかしてくれ クロスプラットフォームなソフト作るにしても、成果物が対象の環境で動けば良い訳で、ビルドをどの環境でも出来ることにそれほど意味はないからね
てかunix系でgccやclang使って開発しているものをVCに入れても謎の独自仕様でコンパイルできないとかザラだしね >>500
そう言って立ち上がった人は100億人くらいいたが誰一人として帰ってくる者はいなかった >>498
wslでmingwクロス環境はマクソ提供だけど あらゆるビルドツールは怪獣化して、怪獣を飼いならすためのラッパーが必要になり、そしてそのラッパーももれなく怪獣化する
歴史が証明しており例外はない 会社でifstreamのファイルオープンがエラーになるのはなぜなのか不明。assert()で引っかかる。
Visual Studio 2008コマンドプロンプトでコンパイルしたプログラムで、コードは単純化
して示したものが下記のようなもの。
std::ifstream ifs1;
for (n = 0; n < 8; ++n) {
ifs1.open(s[n].c_str());
assert(ifs1); // もしくはassert(ifs1.is_open());
関数(ifs1);
ifs1.close();
ifs1.clear();
}
コーディング上に間違いがあるのかいな。ファイルが使用中のためにエラー
でもないようだし。
よくわからんからCのFILE *に変更して対処したけどコンパイラの欠陥か。
ifstreamを宣言した後に ifs1.clear(); が必要なのか。 ifsreamってcloseの後に再使用できる保証あったっけ？
ifs1の宣言をfor文の中に入れて毎回オブジェクト作り直す方が無難に見える makeが複雑なんじゃなくて
多様な環境すべてに対応するように書くことが複雑なわけで。
だったらdockerなり使って一つの環境だけでの提供を考える方が楽。 >>506
まずファイル開く権限あるのかな
最近それで引っかかった >>484
あれ、Winの構造化例外ってそもそもtry..catchには引っかからなかったような…… Rakefileを使っている俺は小数派。
>>506
古いVCの場合ifstreamのclear()後再使用はできなかった記憶がある。 C++でv8のjavascriptを使うために
インストールしようと色々やってるんだけどどうにもうまく行かない。
https://qiita.com/mofumonta/items/ef3d890e13a7c1701748
このサイトを参考にしながら進めてるんだけど
「depot-toolsインストール」の環境変数を通す項目で
C:\v8\depot_tools\win_tools-2_7_6_bin\python\bin
このパスがダウンロードしてきたdepot-toolsにはないんだけど、
どこにあるか誰か知りませんか？
スレチだったらごめんなさい。 python2.7 が既に入ってるなら
その bin に path 通しとけば良いんかな >>483
C の関数が呼び出すコールバックを C++ で書いた場合、環境によってはコールバックからの例外が
C の関数を通過してくる。環境によっては通過できずに terminate() するけど。
厳密に「Cの関数」じゃなくなるけど qsort(), bsearch() については例外が通過できるものと規定されている。
あとは未定義動作となる場合の反応として例外が飛んでくることはあるかもしれない。 >>514
忘れてた。スマヌ。
Windows10 X64
Visual Studio Community 2019
Python 3.7.4(64-bit)
Git version 2.23.0.windows.1
ダウンロードしたのは
https://chromium.googlesource.com/chromium/tools/depot_tools.git
ここから「x64 Native Tools Command Prompt for VS 2019」
で「git clone」を使ってダウンロードしました。
>>515
python自体のbinフォルダは試してませんでした。
ちょっとやってみます。 >>511
なんか設定次第で引っかかるようにならなかったっけ・・・ >>519
インストール手順自体は試したんだけど、
あまりに訳わからんちんで途中で断念して
他のサイトを見ながら入れようとしています。
>>520
Node.jsってv8の上に乗っかったjavascriptというイメージなんだけど、
C++から呼び出せるのでしょうか？ 今、YappyCamという録画ソフトを作っています。以下のソースをご覧下さい。
https://github.com/katahiromz/YappyCam/blob/master/sound.hpp
https://github.com/katahiromz/YappyCam/blob/master/sound.hpp#L125
https://github.com/katahiromz/YappyCam/blob/master/sound.cpp#L154
このSoundが音声を扱うクラスになっております。
スレッド関数Sound::ThreadProcで録音処理を行っています。
std::vector<BYTE> m_wave_dataがサウンドバッファです。
Sound::FlushDataがバッファを吐き出す関数です。
現在、SSDが主流になりつつありますが、ハードディスクでもトラブルなく使えるようにしたいです。いくつか質問します。
１．m_wave_dataをstaticな固定バッファにすべきか。するとすればどれぐらいの容量か。
２．もっといいバッファリングの方法はないか。
お願いします。 スピード命です。フレーム落ちは絶対にダメだそうです。 古臭いスタイルはさておき・・・
(別にそれでいいと思うよ)
なぜバッファリングしてる？
vectorにためずにwriteしたらいいじゃん
readとwriteの単位が合わないとか？
バッファリングするならreader/writerで別スレッドにした方がいいかもね
オーディオの処理なんだからおれなら動的メモリ確保の走るvectorは使わないね
最悪システムコールだから音が途切れる可能性が高まる
一瞬かもしれないが音は少しでも途切れるとノイズになる
最適なバッファ量はそのルーチンがどれぐらいのジッターで駆動してか計測して決めればいい
あとバッファリングすればそれだけ遅延が発生するから注意
本来ビデオ側と同期をとる必要あるけどPCだと適当だよな
CE機器だと完璧に合わせるけど COBOLのWRITE命令みたいに非同期書き込み＆バッファローテーションてか？
あの当時のアホOSならともかく今どきアプリでそんなことせにゃならんか？
ベアメタルなら面白そうだけど 遅延の原因は、vector::insert()でしょ。 ああそうか。std::FILE/CreateFileそのものがバッファリングしてるんだ。ならば下手なバッファリングは必要ないと。
普通にI/Oすることにします。ありがとうございます。 std::vectorのメモリー動的確保は音声処理では不味いと。
ハードディスク環境でジッターを測定して見ないと。わかりました。 >>530
ただそのスレッドでwriteするのが問題ないかはよく確認した方がいいよ
writeでブロックされることで音声のソース側の処理が滞る可能性がある
その場合はやっぱり別スレッドにすべきだね setvbufって便利な関数を見つけた。これ使うか。 音声のバッファリングには普通はリングバッファを使う ここまでのまとめ。
リングバッファを使う。
十分大きなバッファサイズでsetvbufを使う。
リングバッファへの読み書きは別スレッドにする。
バッファが空のときはイベント待ちで休ませる。 別スレッドにキューイングするのに適したC++標準クラスは何かな？ >>537
Queue への読み書きは、1要素当たりは短時間で済むことが多いので、
Queueを読み書きする場所で、必ず Critical Section などで囲むと良い。
一度に沢山の要素をまとめて書き込みたい場合は、原則的には、
1要素を書き込む処理をこまめに、Critical Section で囲むようにする。
必ずしも1要素ずつ囲む必要は無いが、こまめに囲った方が、
別スレッドの待ち時間が減ることが期待できるが、その意味が有る場合と
無い場合とが有る。
Critical Section の代わりに、Mutex や Semaphore などを使うことも出来る。 キャッシュに配列を置けばいいじゃねえか
かんたんだろ
APUの近くに配列でOK
複雑なデータ構造なんて考える必要ナシ タイミングで問題が出てるのにvectorにこだわるのはアホだよな 実行時のパラメータでバッファサイズ可変にするならvectorで始めにresizeしておくのが楽
size使える分配列のunique_ptrより取り回しも楽だし >>540
それらの同期機能って標準C++のクラスだけで実現できるもんなの？ >>547
どこまでを標準と言ってるのか知らんけどお前の考える標準でスレッドをサポートしてるならたいてい同期機構もあるはず >>547
WindowsではCriticalSection, CreateMutexなどがあったからC++11以前でも使えた。
C++11からstd::mutex, std::lock_guardなどが使えるぞ。 リングバッファの排他制御どうするか？
push/popごとにロックかけたら遅くなりそう。 >>545
stlライクにしてる割にコピーやムーブが内部の値ベースなのおかしくない？ 用途的に
reader 1
wrtier 1
だと思うけどそれならwait freeな実装が可能
read pointer/writer pointerで制御するやつね
かつかつに最適化するならこれ
しかしその前にどれだけの頻度と長さで排他の衝突するか見た方がいい
リアルタイムのオーディオなら短くても5msec周期とかじゃないか
かつlock中に多少のメモリの読み書きやってるだけなら排他が必要な時間は短い
なら素朴にmutex1個でのロックで十分な可能性も高い
同期のミスはデバッグがつらいから不用意に難しいことしない方がいい
もしくはある程度のバッファリング(遅延)が許容できるとか、固定長の処理であるなら
ならバッファを複数用意してダブル、トリプルバッファ的な制御でもいいだろう
つまりwriter側でバッファに全部書き終わったらそのバッファをreader側のキューにいれる
reader側は全部読み終わったらwriter側のキューに戻す
っての
とにかく原則どおりまずシンプルにミスなく作って計測して最適化ね ringのソース見たけど
おれはm_full なしでやるのが好みだな
つまりm_front_indexとm_back_indexが一致するのはemptyのときのみ
full時には実際は1個空きがある状態
これを推し進めればwait freeの実装に近づけるぞ
車輪の再発明だが勉強にはなる >>551
std::atomicとかあるね
原理的に競合が起きないやつ static DWORD s_dwTick;
printf("write: %ld, %ld\n", cbToWrite, GetTickCount() - s_dwTick);
s_dwTick = GetTickCount();
// 最高の音質での出力。
write: 3900, 15
write: 3900, 0
write: 3900, 16
write: 3904, 16
write: 3900, 0
10msecごとに音声データがおよそ3900バイトあるようだ。 >>558
Win32APIや音声仕様はC++じゃないのでよそでどうぞ。>蟻人間 Win32APIって何だよ
20年前からタイムスリップでもしてきたか？ >>562
win32api(64bit版）で書くのが正義、という価値観もまだまだ存在するようです C++11からできた属性構文あるけどこの属性は宣言にだけつければOK?
定義にも同じ属性を記載するべき？ >>563,565
Mozilla Firefoxなどサードパーティ大手は今もWin32APIをネイティブに使っており.NETを使ってない。 >>562 は .NET より WinRT とかを想定している気がするが。 単に64bitのWindows APIもなぜかwin32と呼ばれ続けてること知らないんだろ それこそ２０年前からタイムスリップしたのかって話だなｗ 速度重視な場面ならWin32APIは今でも普通に使う >>572
「Linuxシステムコールで速度でるの？」という質問と同じくらい矛盾に満ちた質問。
Win32APIも含めシステムコールはOSが提供するAPIなので、プログラマは他の手段で代替しようない。 Visual C++ 2015なんですが、
goto文でERRORというラベルに飛ばそうとしたら、コンパイルエラーが出ました。
ERRにしたらコンパイルできるようになったんですが、
なぜERRORのラベルはダメなんでしょうか？ >>575
<wingdi.h>に#define ERROR 0がある。 ERRORのdefineがあるんですね･･･！
ありがとうございました！ クソみたいなマクロにsmallもある
他にもwindows.hには地雷が入念に仕込まれてる
普通の神経の人間が爆死して厭らしい人間だけが生き残るように整えられている厭らしい環境がwindows.hだよ
マトモな人間にはまず耐えられない
頭のオカシイ厭らしい人間だけが残るように設計されているのがwindows.h
このヘッダは頭がおかしい 林檎だってcheckマクロでBoostに大迷惑かけてるしお互い様 >>582
そこは
ヘッダだけにな
と言ってやるところだろ たしかmaxとかもマクロ定義されてたよね
初心者のころはどハマリして殺意がわいたわ いまはIDEが色変えてくれるからすぐわかるから別にいいけどね 最近ちょいちょい思うことだが、ある言語のここがどうであーだこうだと議論する場合
テキストエディタでコーディング作業してる連中と IDE でコーディング作業してる連中では
わりと大きな認識の違いがあることが多い windows.hのマクロ回りでトラブル起こしているのは、殆んどvisual studio使用者だと思うのだが 認識の違いはコンパイラによるものであってコードエディタは関係ない。 モジュールでマクロとか気にしなくて良くなる（なるといいなぁ...） コンパイラ変えてもマクロは変わらんでしょ
せいぜいエラーメッセージ変わるぐらいじゃ >>595
何言ってるのか意味がわかりにくいエラーメッセージを吐くのはコンパイラでしょ。 マクロは影響範囲わからんからなんとも
vcでマクロがテンプレートに影響したらマジでわからん
clangはテンプレートのエラーメッセージわかりやすいとかみたな >>593
お前はまず日本語を正しく認識できるようになれよ…
>>591は連中（=人間）の認識の話な 初心者であればあるほど親切なエラーメッセージが必要なのだけど、VCのエラーメッセージはgccに比べて不親切な印象がある。
STL関連のエラーメッセージは、わかりにくい代表格。かたやgccはprintf系の書式ミスを指摘してくれるなど初心者に優しい。 C#が使いやすいと思っている人は、Visual Studioの入力補完に救われていることに気づいていない。
Visual Studioがなければヘッダーファイル相当のgrep検索もままならない不便な言語であると感じるだろう。 VS込みでいいじゃん
どうせC#なんて大半がWindows向けなんだしVS使える環境で開発してるでしょ
って変なこと言うと思ったらADSLか referencesource.microsoft.comみたいなありがたいものがあるのに class A{};
namespace N
{
class B{
friend class A;
int i;
};
class A{
A(){b.i = 0;}
B b;
};
};
これをコンパイルできるようにするにはどうすればいいですか？
・クラスAを名前空間Nの下に書く
・名前空間NのクラスAを別の名前にする
・最初のクラスAを別の名前にする
これ以外でできますか？ >>604
「コンパイルできるようにする」
というだけであれば、何も修正しない元のままでもコンパイルできるはずだし、
最初の class A {} の行をコメントアウトする、消す。
Nの中のAを消す、namespace N {・・・} の部分を全部消す、
などなどいくらでも有りえる。 BのfriendをN::AにしたいってことであればNとBの間にclass A;とAの宣言を入れる
これ以上のエスパーは無理 >>604
g++だと、現状のままでok
vs2019は、friend宣言の対象が::AになっていてC2248
::Aをコメントアウトするとok
正しいのはg++
N4713 6.4.1. Unqualified name lookup (7.4)
Note: When looking for a prior declaration of a class or function
introduced by a friend declaration, scopes outside of the innermost
enclosing namespace scope are not considered; see 10.3.1.2. 投稿テスト
N3337 3.4.1 Unqualified name lookup
Note: When looking for a prior declaration of a class or function
introduced by a friend declaration, scopes outside of the innermost
enclosing namespace scope are not considered; see 7.3.1.2. vs2019で::Aをコメントアウトするとokの意味がわからんorz 試してないが、理論上はこれでいけるはず :
namespace N
{
class A;
class B{
int i;
friend class A;
};
class A{
B b;
A(){b.i = 0;}
};
}; N::Aを前方宣言するなら、宣言を名前空間Nの中に入れるかN::Aで宣言する必要があるってのはC++の規約通りじゃないのか？
>>608が意味わからん friend宣言は、当該宣言を含むクラスが属するスコープを対象とし
なおかつ、対象スコープに識別子を導入しない
class G
{
friend class A; //::A
};
namespace H
{
class I
{
friend class A; //H::A
};
} >>604はfriend宣言ではなく前方宣言の問題なんだが？ いや前方宣言は関係ない
「もし」::Aがあったら、H::Aがあったら
と言っているだけのものだ >>614
前方参照をfriendがどう解釈するかの問題だろ >>616なのは明白だが
>>604のコードのどこにコメントアウトすべき::Aがあるのかわからん…
ひょっとして、>>604が禁じていないのを良いことに、
最も外側のclass A{};を丸ごとコメントアウトしようとしている？ >>617
？？？
>>608はVisual Studio 2019（2017でも同じだったが）の話だと言うことは理解できてるか？ >>617
そのとおりだが？
//class A{};
namespace N
{
class B{
friend class A;
int i;
};
class A{
A(){b.i = 0;}
B b;
};
};
friend宣言が識別子を導入したり
関係ないはずのグローバルに干渉するなど
vcはfriendにクセがある 規格的にはどうなるのが正しいの？
むしろ、もとの話がどうしたいのかに依る気がしないでもない >>620
規格の話は>>608じゃねーの？
コンパイルできるようにするにはg++にするかVisual Studioなら>>619みたいにするってことでしょ
それ以外なら環境を提示してねってことかと >>622
一緒だよ
だからそれができないならg++（とか他のちゃんと規格準拠して処理系）にしろって書いてあるだ
まあVisual Studioが規格準拠するのを待つとかMSにねじ込むか金払って対応してもらうとかでもいいけどw トンチンカンな質問かもしれませんが許して。
<Base>のコンテナを巡回しながら
Base派生の多態性を引数で実現、みたいなことがやりたいのです。
https://ideone.com/PA26HG
これのManager::update()が、このままだと当然
func(shared_ptr<Base>,shared_ptr<Base>)を呼ぼうとしてしまう訳ですが
宣言してあるfunc（A,A）とかfunc（A,B）とかfunc（B,B）とかが
呼ばれるようにするにはどうしたらいいですかね？
あるいは、ガラっとコード変わってもだいたい似たようなことを実現するとしたら
どう書きますか？ あ、すまん。誤読していた。
>>宣言してあるfunc（A,A）とかfunc（A,B）とかfunc（B,B）とか
多態やってる意味を潰しに来てないか？ もしくはfuncでは仮想化された関数しか使わないとか。 >>627
func(Base,Base)だけをvirtualってこと…ですよね？
え、こういうときにもvirtualて使えるの？と思って試したけどダメですね。
>>628
もうちょっと考えてみますけどたぶん難しいです 名前欄間違えてた…
>>629
あー…それかも
なんとなく知ってるだけで
まだ実装したことはないですが
それ正解かもしれません
調べつつやってみます >>624
愚直に dynamic_cast で N*N 分岐からはじめたら？ 派生クラスの種類が決まっているなら
variantに置き換えたらvisit使えるから簡単 C++でCOM扱うの苦痛すぎる
何が正攻法なのかさっぱりわからん 別にCOMは作るんじゃないんだよ。
参照するだけなんだよ。
それでもATLなんーーーーーーーーー？ そもそも文字コードどうなってるんやーーーー
コマンドプロンプトに出す時、どうするんやーー
現在のchcpの設定に従って変換線といかんのカーーーーーー 変換なんてWideCharToMultiByte使って一つ変換関数作ってその関数を使い回せばいいやん。 >>640
Unicode文字列（絵文字とか）が文字化けするんだよー！
フォントの問題でないことは確認済み 例えばググって見つけた、こことか
http://www.t-net.ne.jp/~cyfis/win_api/sdk/WideCharToMultiByte.html
wchar_t を const wchar_t にするのはまあいいとして、
日本語はOKだけど絵文字とか化けるじゃねーか
わーけわかねなんｄｆっｒね；ｊｋ ん？WideCharToMultiByteってShiftJISに戻すやつじゃねーのか？
俺はUnicode文字すべてを表示したいだけだぞ windowsのコマンドプロンプトはまだ絵文字とかに対応してないよ >>646
全てではないだろうけど対応してる。
❥
↑文字化けしそうだけど、横向きのハートとか
❤ とか >>645
chcp 65001にしてもムダだったぞ コマンドプロンプトよりJaneは早く絵文字に対応しろ なんでコードページ932なのに、NSimSunにすると
日本語以外もちゃんと表示できるのかわからない Visual StudioのソースコードのデフォルトはBOM付きUTF8なんだな 自分の理解と違ってたので教えてください。
class hoge{
hoge(){}
hoge(const hoge& h){}
~hoge(){}
}
hoge func(){
hoge h;
return h;
}
main(){
hoge h = func();
}
この時、引数なしコンストラクタとコピーコンストラクタ、デストラクタが2回呼ばれると理解してたんだけど、実際動かすとコンストラクタとデストラクタが1回づつしか呼ばれない。
理由ってなんですか？
ちなみにgccで、c++03、c++11でも同様の結果でした。 >>659
まさにピンポイントでした。
ありがとうございます。 >>636
マイクロソフトのコンパイラならまあまあ補助があったりするでしょ。
それでも面倒くさいことにかわりないけど。 失礼します。テストです：
ハート：❤
横向きハート：❥ >>663
補助なんてあったっけ？
まあ俺の知識はもう5年以上前の知識だから最近はちょっとはマシになったのかな typedef const struct {
int i;
int j;
} X;
X arr[2] = {
{1,3},
{2,4}
};
int main() {
X *ptr = arr;
printf("%d %d %d <- always zero", ptr->i, (ptr+1)->i, (ptr-1)->i);
return 0;
}
グローバル const struct の配列のアドレスを上に行ったら、常に0が入ってるんだけど、
これは、どのハードウェアでもこうなると仕様と決まってるの？ >>667
決まってない。
範囲外のアクセスなので、本来は絶対にやってはいけない。
読むだけでも不法例外が起きてしまう可能性もあるが、
書くのはもっとダメ。
たまたま、コンパイラシステムが何らかの目的で使っている
グローバル変数が arr 配列の直前にい配置されていて、
それが0になっているか、padding領域がたまたまそこにある
だけだと考えられる。 オブジェクトがスタックに作られてるかヒープに作られてるかってどうやって調べるの
具体的にはboostのmulti_arrayがどっちに作られてるか知りたい >>668
そりゃそうか。０で埋まってりゃコードが少し短くなって助かるんだが、まあやめとこう。 >>670
アドレスでわかる
正しくはリンカからロケーションを取得だが
簡易的には自動変数のアドレスと上の方の桁が同じかどうかでも見当はつく >>670
アドレスでも分かるが、それはスタック領域のアドレス範囲をマップファイル
やEXEヘッダなどから読み解かないといけないので、boostのソースを読むのが
一番楽。
もう一つは、
1. auto local変数でint a; printf( "%08X", &a );としたもの
2. global 変数で、int g_b; printf( "%08X", &g_b );としたもの
3.ヒープの先頭アドレスを調べるため、int *p_c = new int[16];
printf( "%08X", p_c );としたもの
で表示されたアドレスと boost の multi_arrayのアドレスとを比較して、
上位アドレスが近いかどうかで判別できる。1,2,3のそれぞれはまとまった
領域のアドレスを使っているので、推定ではなく断定できる。 >>670
ローカルスコープだけがスタック。
newしたものはヒープ。 コンテナの場合はスタックに置いたつもりでも、コンテナがデータ部分を内部でnewするとかそういう話だろ >>667-668
仕様上は配列の範囲外を指すポインタを作るのさえも未定義。
たとえアクセスしなくても。
なので、 ptr-1 という式の時点で未定義動作になる。
ただし、アクセスしないなら配列の最後の要素より一個うしろを指すポインタを作るのは許される。
つまりこの例で言えば ptr+2 や &ptr[2] は有りだけど ptr[2] は駄目。
&ptr[2] は ptr[2] に対して & を付けているので一見すると途中で ptr[2] を評価しているように見えるけど、
・ ptr[2] は (*(ptr+2)) の構文糖である
・ * の結果に & を適用している場合には * も & も評価されず、両方とも取り除いたのと同じことになる
というルールの合わせ技によって &ptr[2] は ptr+2 と同じ意味になる。
ちなみに、配列ではないオブジェクトは要素が一個の配列と同じレイアウトを持つことは保証される。 >>677
&*p を p とみなす特別ルールは C の規格にあるけど C++ には無かったりする。
もう１０年以上審議中。 https://wg21.cmeerw.net/cwg/issue232 >>677
>ちなみに、配列ではないオブジェクトは要素が一個の配列と同じレイアウトを持つこと>は保証される。
しかも、TYPE arr[N] の場合、それぞれの要素間隔であるところの
&arr[k] と &arr[k + 1] の差は、厳密に sizeof(TYPE)に一致する。
struct TXxx { BYTE a[3] }; のように中途半端な内容を持っている場合、
標準的には、sizeof(TXxx)は最後のpaddingまで含めた4になる。
その結果、古くからCの仕様書に載っている通り、
&arr[k] = (TYPE *)(((BYTE *)arr) + sizeof(TYPE) * k)
の式が常に厳密に成り立つことが保証される。 >>678
operator&(), operator*() をユーザーが定義した場合には、それに従うが、
定義しなかった場合、&*pX == pX が どんなポインタ pX についても
成り立つことは保証されるはず。 >>670
一般的なPC環境なら、
適当に用意した別の関数を呼び出して(multi_arrayのインスタンスがまだ有効で、インスタンス生成したスレッドと同一スレッドからなら、どこから呼び出してもよい)、
その関数のローカル変数のアドレスよりも&multi_array[0]の値のほうが大きければ、multi_arrayのデータ領域はスタックに確保されたと判断できるのでは >>681
自分も最初、同じような勘違いをしていたが、
シングルスレッドの場合に限定すれば、
スタックの構造からすれば、最初に確保したローカル変数のアドレスが、
そのごろのローカル変数のアドレスよりも必ず大きい。
そして、ヒープから確保したオブジェクトのアドレスは、必ずそれらよりも大きい。
なので、後から別の関数を呼び出す必要はない。
main()関数の中で最初に定義したローカル変数のアドレスが分かればそれで十分。 >>682
誤：そのごろのローカル変数のアドレスよりも必ず大きい。
正：その後のローカル変数のアドレスよりも必ず大きい。
早い話が、スタックは、上下逆になっていることが味噌。 0 埋め勝手に期待してると
Debug build と Release build の変化ではまるんじゃね >>682
> そして、ヒープから確保したオブジェクトのアドレスは、必ずそれらよりも大きい。
スタックエリアとヒープエリアの前後関係なんて決まってたっけ？ Boehm GC にスタック・ヒープの範囲を判定する部分があったはず。 >>682
ヒープから確保したアドレスがスタックより大きいっていうのはかなり特殊な環境では？ >>682
スタックとヒープのアドレスに前後関係の縛りなんかねえよ
互いに全く別個のデータ構造で相互に依存関係はない お前ら甘いぞ
ヒープから確保したメモリをスタックにすることもできるんやで
逆にいうとスタックの情報もとれる
pthread_attr_getstackな https://ideone.com/Q4ek9R
デストラクタを後から書き換えるってできなかったっけ？ おまえらはなんですぐ破壊的なメモリアクセスしようとするんだよ。 >>694
なんでだろ・・・。
できなそうだな。さんきゅー。 >>696
virtualでないと子のデストラクタは呼ばれないってのとごっちゃになってるとか？ >>698
平和は求めるが性能も求めるから仕方なく使うのがc++だよ、馬鹿。 >>699
多分それだ。もやもや取れたわ。ありがとう。 >>700
お前moveだからコピーコストゼロ！カロリーゼロとか言ってるだろ >>687
なるほど、想定していたのは、Windows環境限定だった。 >>679
> &arr[k] と &arr[k + 1] の差は、厳密に sizeof(TYPE)に一致する。
いや、 &arr[k + 1] - &arr[k] は 1 でしょ。
> その結果、古くからCの仕様書に載っている通り、
> &arr[k] = (TYPE *)(((BYTE *)arr) + sizeof(TYPE) * k)
> の式が常に厳密に成り立つことが保証される。
少なくとも C++ の規格にもそんな保証は載ってないよ。
逆に、 TYPE が BYTE と一致するような場合を除いて、動作は未定義になると明記されてる。
https://timsong-cpp.github.io/cppwp/n4659/expr.add#6
たぶん C の規格にも無かったと思うんだけど、「Cの仕様書」って何のこと言ってるの？
>>680 も、規格で保証されると言ってるなら誤り。
特定の実装（特に C もサポートしてる実装）では保証されているとか、
保証されてないと困るという話ならそうなんだろうとは思うけど。 保証は知らんけどアドレス計算だから1じゃなくてsizeofの値じゃないのそれ
あとだめならベクタで&v[x]みたいのも未定義になっちゃうけども >>705
俺も仕様としての保証はないと思う。
C の規格を見て関連しそうな項目として
- ポインタを型変換して変換後のアライン (処理系定義) が正しければそれを元の型に再変換したものは変換前と等しい
- ポインタを別のポインタに型変換した後のアラインが正しくなければ未定義
- ポインタを文字を指すポインタに型変換した場合、オブジェクトの最も低位のアドレスを指す
- 文字を指すポインタに変換されたポインタは元のオブジェクトの大きさまで連続して増分すると
そのオブジェクトの残りのバイトへのポインタを順次生成できる
(注：ここで言うポインタには関数ポインタを含まない)
という保証は見つけられたので
(((BYTE *)arr) + sizeof(TYPE) * k)
までは妥当な式と言えると思うんだけど、 (TYPE *) というキャストが出来る根拠は見つけられなかった。 >>707
C言語の基礎として、TYPE *ptr に対し、
ptr + k == (TYPE *)(((BYTE *)ptr) + sizeof(TYPE) * k)
は保証されているはず。 https://en.cppreference.com/w/c/language/sizeof
1. sizeof( type ) Returns the size, in bytes, of the object representation of type
2. When applied to an operand that has structure or union type,
the result is the total number of bytes in such an object, including
internal and trailing padding. The trailing padding is such that
if the object were an element of an array, the alignment requirement
of the next element of this array would be satisfied, in other words,
sizeof(T) returns the size of an element of a T[] array.
3. Number of elements in any array a including VLA (since C99) may be
determined with the expression sizeof a / sizeof a[0]. Note that
if a has pointer type (such as after array-to-pointer conversion of
function parameter type adjustment), this expression would simply
divide the number of bytes in a pointer type by the number of bytes
in the pointed type.
https://en.cppreference.com/w/c/language/operator_arithmetic
10. If the pointer P points at an element of an array with index I, then
11. P+N and N+P are pointers that point at an element of the same array with index I+N.
12. P-N is a pointer that points at an element of the same array with index {tt|I-N}}.
20. If the pointer P1 points at an element of an array with index I (or one past the end)
and P2 points at an element of the same array with index J (or one past the end), then
P1-P2 has the value equal to J-I and the type ptrdiff_t (which is a signed integer type,
typically half as large as the size of the largest object that can be declared) C++のヘッダファイルのクラス定義って、
privateまで定義しないといかんのが嫌だな。
privateだから内部に隠蔽されて、外部からは知らなくていい情報なのに
内部で使ってる型をヘッダファイルに書かなければいけないから、
それをincludeしてる方も、その型の存在を知ってしまう。
どうにかならんのかな？ >>710
「1.」によれば、sizeof(x)は、xのバイトサイズである。
「2.] によれば、xが構造体の場合、sizeof(x)には、構造体のメンバの間や
最後のpaddingのサイズまで含まれている。
「3.」によれば、TYPE a[N]; の場合、sizeof(a)/sizeof(a[0]) == N
が保証されている。a[0] の型は TYPE なので、これは、
sizeof(a)/sizeof(TYPE) == N
であることを示す。sizeof(a)とは、配列型a全体のサイズであるので、
これはつまり、a[k] のアドレスが、(a[0] のアドレス) + sizeof(TYPE) * k
であることを意味している。
よって、>>708 は正しい。 >>705
>> &arr[k] と &arr[k + 1] の差は、厳密に sizeof(TYPE)に一致する。
>いや、 &arr[k + 1] - &arr[k] は 1 でしょ。
この場合の「差」とは、減算演算子 x - y の結果のことではなく、
アドレスの差のことです。丁寧に書けば、
「&arr[k] のアドレス値と &arr[k + 1] のアドレス値の差は、厳密に sizeof(TYPE)
に一致する。」または、
「arr[k] のアドレスと arr[k + 1] のアドレスの差は、厳密に sizeof(TYPE)
に一致する。」
となります。 >>691
言語仕様的には決まっていませんが、Win32で実験する場合、
最初の質問者が、答えを見つける手段としては、正しいやり方なのです。
Win32で実験してヒープからの確保なのかどうか判明してしまえば、同じ
boostのソースを他の環境で動かしても、#ifdef などで動作が変えられていない
限りは、同じ結果となるからです。 >>713
アドレスがどうこうじゃなくてキャストが許されるかっていう話なんだけど。 ポインタのキャストてポインタが指してるアドレスのデータの解釈だけの問題だから許されないキャストがそもそもないのでは
適切かどうかは知ったことではないが
というか配列のデータが連続していれば当然のごとく成り立つ話じゃん
それは保証されてるわけだし >>714
サンクス。集約を使えば行けるんかいなーとか雑に思っていたが、
そういうイディオムがあるんだな！ >>718
構造体型へのポインタ同士については、単なる解釈し直しではなく、
アドレスの加減算を伴うことがあります。
しかし、BYTE型へのポインタから構造体型へのポインタへのキャストに
ついては、解釈のし直ししか、コンパイルのしようがなく、その場合に
ついては、ポインタの指すオブジェクトがマシン後レベルで同じアドレス
を持つことになります。ただし、厳密な仕様は知りません。 pimpl ってプライベートなメンバを隠したいだけのために導入するのは面倒くさ過ぎない？
手間かけてでもやりたいって場面もあるのかもしれんが、どうにも割に合う気がしない。 unique_ptrで作ればそれだけで勝手にmovableなクラスになって便利だよpimpl >>721
プライベートなメンバを隠すと言うよりも
依存関係を断ち切らせたかった。
hoge.h と hoge.cpp があって、
hoge.cpp から #include<hoge.h> してる
main.cpp があってHogeクラスを使うから、#include<hoge.h> してる。
この時、mainは、Hogeクラスだけを使ってることにしたい。
でも、hoge.cpp は private で Hage func(); メソッドを定義してる。
つまり hoge.cpp は #include<hage.h> をしている。
そうすると，mainは、Hogeクラスだけ使うつもりなのに
間接的に hage.h もインクルードしてしまって、Hageクラスのこと知ってることになる。
Hogeを知るとHageも知ってしまう
Hageを隠したかったんだよ！
↑
言いたかったことはこれ >>724
また髪の毛の話してる、などというと荒れそうなので決して言いません。 C++20 でモジュールの機能が入るとかいう話になってるから
それが成れば pimpl なんていらんようになると思うんだが、
実際のところモジュールの様子ってどうなの？ちゃんと入りそう？ 無理。
テンプレートとの両立、オーバーヘッドの問題
どの視点でみてもくそなものしかできないことは明白。
こういうのに引っかかるバカが増えたよね。 >>721
そう思うのは複数人で規模のでかいもの作ってないから pimplは開発規模は関係なくて、ライブラリの公開するヘッダでユーザーに関係ないものを隠すために使わないか？ >>729
それも pimpl の目的としてはあるんだけど、 >>724 が書いているように C++ だとファイルの依存関係が必要以上になることもある。
それをどうにかしたら make で差分ビルドしたときに走るタスクが少なくなるので
規模が大きいプログラムで pimpl を使うとビルドがだいぶん速くなるということはありうる。
規模が小さいと体感するほどの差が出ない。 割に合わない。
そういう意味では規模は関係ある。 個人的には、自分ひとりで作ってるプログラムは、高頻度で全ビルドに
かける癖が付いてしまってる。
こうしておくと、OSをSleepモードにしていて、誤って電源を切ってしまったような
時にIDEが管理しているプロジェクトのデータファイルの何かが壊れていても
気付なかった時や、プロジェクトのバックアップ処理の時のコピー操作の何らか
の間違いで何かがおかしくなってしまったようなときに変な不具合に悩まされなく
て済む。 C++とオブジェクト指向をきちんと身につけてる人ばかりの環境ならいいんだけどね、pimpl
経験不足な人だと理解出来なさそう 使ってるうちにインターフェースを使った典型的な奴とそう変わらない事に気付く 確かに、select_on_container_copy_construction(other.alloc_)が正しいような気はする テンプレート活用のための最適化が全盛期の今 pimpl は時代遅れ。 pimplが時代遅れというのなら、それに代わる
依存する必要がない所を断ち切る方法を提示してくれ >>739
クラスの前方宣言。
テンプレートによるコンパイルエラー回避。 >>740-741
どちらも型を書くので依存を断ち切れてない pimplでも型を書くのに、何を言っているんだか
そんなに型を書くのが嫌なら、Cの不透明型でも使ってろ pimplの目的も方法も全く理解してないって白状したぞこいつ privateをどうしても隠蔽したいならpimpl使うのもやむを得ないのかも知らんけど、そんな事態になったこと無いからよくわからんな ライブラリ作る時にstd::unordered_mapとかメンバに使いたいと思わないもんなのか、よくわからんな
pimplで.cppに閉じ込めないとコンパイラやSTLのバージョン違いで壊れるんだけど >>739
自部屋に引き籠もって外界との依存を断ち切ります。 ライセンスに書いとけば良い
・プライベートは見ないで下さい。お触り禁止。 ただ単に仕様と実装をすっきり分離できるというだけでも充分な動機になる >>747
> pimplで.cppに閉じ込めないとコンパイラやSTLのバージョン違いで壊れるんだけど
ん？どう言うこと？
なんかやり方間違えてね？ >>750
private部分を見なきゃいいだけだろw
そもそも実装は.cppに書くんだし エディタが貧弱だったころの名残を未だに引き摺っている
仕様と実装を分離したらそれだけでファイルが倍に増えて管理が面倒になる
仕様はソースコードから逐次自動生成すればいい
なので昨今の言語はIDEに迎合していて、暗黙の大前提でIDEでの運用が見込まれている
それ単体で成り立つものでは無くなっている class Util() {
public:
int aaa();
std::string bbb();
private:
MinorClass mc;
MinorClass mc zzz();
}
こういうユーティリティクラスがあって便利だなーって思ったときに、
便利だと思うのはaaaメソッドとかbbbメソッドであって
内部で使ってるMinorClassとかどうでもいいねん
Utilクラスのインクルードファイルはインクルードしたいけど
MinorClassのインクルードファイルはインクルードしたくないねん
そんなもんインクルードしたらMinorClassが変更になっただけで
Utilクラス使ってるところも変更になるやろ？ >>755
そこをわからんって言ってるやついないんだよ。
わかった上で変更になったらどんくらい問題なんや？ 別にええやろ。 と言う場面の方が多いという話なんだよ。
pimpl が有用な場面があるっていう主張もわかるよ。 わかるけど、そういう場面に遭遇したことないなぁという話なんだよ。 >>755
それだけならMinorClassを前方宣言するだけでincludeいらない >>757
MinorClassの実体をメンバにするなら前方宣言じゃだめ
ポインタなら前方宣言にできる Utilはあるライブラリの公開クラスです
MinorClassは標準ライブラリのテンプレートクラス(例えばstd::unordered_map<Hoge>)です
Aさんはとあるコンパイラver1.0でコンパイルしたライブラリのバイナリとヘッダーを配布しました(ソースは配ってない)
10年後にBさんがこのライブラリのバイナリを入手して使おうと思いました
その間にコンパイラの標準ライブラリも劇的な進化を遂げ、コンテナの内部構造に大幅な改良を加えて超高速化したと宣伝していました
Bさんはヘッダーをincludeしてコンパイラver8.0でビルドしました
さーて何が起こる？Utilがpimplだとどうなる？よくよく考えよう privateメンバをポインタ型にする手間や不都合とpImplの手間や管理コストのどっちを取るかだろうな
基本的には継承するクラス以外のincludeは排除できる
ヘッダ内部での外部ライブラリのincludeは可能な限り避けるべき >>760
オブジェクトを生成するには「大きさの情報」が必要だと覚えておくとわかりやすいと思う。
クラスの内容がわからないと大きさが確定しないから生成できないけど、ポインタの大きさはわかる。 >>759
そういう状況があることはわかるよ。
でもそんなことしねーよって話なんだってば。 >>763
それお前個人がしたことないって言う経験談？
それとも他の代替手段を取るってこと？
先に言っておくと前者ならすっこんでろ >>764
俺がしたことないという経験談だが、
ここで pimpl が割に合わないと出ている意見は
そういう状況があんまりないという内容だということの説明でもある。
そういう状況で必要だってのはわかってるし、
そういう状況にあるなら使えばいいよ。
それはわかってるんだよ。
だからしつこく説明しないいよっていう話。 要するに >>759 はまるで見当はずれのこと言ってんなぁという感想。 単機能ライブラリ作って渡す仕事してる人にとっては日常なんで、検討外れとか抜かされても勝手なこと言ってんなあとしか
まあ、OSSしかやらないとか、最終の実行バイナリしか作らないとか、そもそも個人プレーで人にプログラム成果物渡したりしないとかなら、
pimplの価値わからんという気持ちになるのはしょうがないし、それが世界の全てだと思っちゃうのかもな >>767
それが全てといってるわけじゃなくて、
pimpl がどうしても必要！ と言ってる人こそライブラリ販売の世界しか見てないという話をしてんの。 いる場所ではいるし、いらない場所ではいらないという当たり前のことしか言ってないつもりなんだけど。 全員知らないことの方が多いのに相手が自分の分野のことを知らないと無知扱いするのは草生える >>759
そもそもVer. 1.0でコンパイルしたクラスライブラリをVer. 8.0でコンパイルしたオブジェクトとリンクできるの？
10年間互換性保ってるC++コンパイラの名前教えてくれるかなw 動的リンクなら古いコンパイラでコンパイルしたライブラリが使えるかどうかはOSの互換性次第だろ >>766
一般的な現象よ
周回遅れのやつに絡まれたらキョトンとしちゃうやろ
今の餃子ちゃんがまさにそれよ
幼稚園児に絡まれたお兄さんみたいになっとる >>772
マングリングって知ってるか？
そもそもC++のクラスライブラリを簡単に動的リンクできるOSってあるのか？w comはクラスライブラリになるのかな
いろいろ面倒だけど 念のため確認だけど、pimplの代替手段については把握されてる前提でOK?
http://site.oukasei.com/?p=148 リンク問題はABIの話だよな？
それはリンカのオプション次第じゃないのん？ >>779
広い意味だとABI
リンカのオプションで前のバージョンに対応してるとかの例もあるけど10年前まで対応してる例とかあるのかな？ >>778
結局、pimplのI/F用外側クラスを基底クラスに、implを派生クラスにするってだけでやってることはpimplと同じ
むしろ以下の点でより悪い
・I/F用のクラスと実装用のクラスに不必要な継承関係が導入されていらない複雑度が増える
・↑と同じことだが、実装用クラスがI/F用クラスと同じメンバ関数を実装することが強制される
・コンストラクタが使えず、独自のファクトリ関数の使い方を利用者に覚えさせる必要がある
・利用者に生ポが露出する。生ポを避けたい利用者は自分でunique_ptrなどで包まなければならない
・I/F用クラスを利用者が勝手実装して混入させることを許す
上に挙げたのはポリモさせたい場合はメリットでもあるんだが、ポリモを意図しない単独クラスに継承構造なんか入れるべきではない >>766
検討はずれかどうかは意見が分かれるかもしれないけど、pimplには速度的な
オーバーヘッドが少しはあるのと、記述が分かりにくいような気がするので、
個人的にはまずは使うのを躊躇する。
ポインタのワンクッションを置いても速度的なオーバーヘッドが問題ない場合には、
単純なクラスへのポインタを使ってそのクラスの実装に依存しないようなコードを書く
ことはある。しかし、pimpleと言われているものよりずっと単純なもの。
pimplの定義もよく分からないので、それが全く同じものかどうかは分からない。 >>752
目指す理想が違いすぎるやつとは話にならん >>778
そういう風に、C++の抽象クラス（Javaではinterfaceと呼ばれるものと等価
だったはず）を使うと分かり易いですね。 実装方法もいろいろでメリットデメリットもいろいろやから好きなの使えばええねん interface を使って、データメンバを隠したい場合は、new CXxxx にあたる部分を
どうやって実装するかの問題になるんですね。グローバル関数にしてしまう
方法もありますが、確か、デザインパターンの「Factoryパターン」というものが
それに該当したかもしれません。 >>768
依存切りたいならpimplと言ってるところに
依存気にしてないからpimpl不要っていってるのがお前
不要ならすっこんでろって >>784
目指す理想がpimpl?
確かに話にならんなw >>790
ただ20年間I/F変えないようにするにはあの程度の手間は必要なわけで
まあもうちょいスマートにできるんじゃないかなって思うところは多々あるけど >>789-790
COMが使いづらいと言うか、C++とstdとSTLとWindows APIとCOMの流儀が
ごちゃまぜで、メモリの確保の仕方と文字列の扱いが混沌を極めてるｗ .NETは（特に起動の）遅ささえなければ、ずっと簡単だよな。
C#でもなんでもさ
0.5〜1秒クラスの起動速度の差が気になることやってるんで、
久々にC++使ってるけど大変すぎ
でもまあ20年ぐらい前に比べれば随分と楽になってるけど >>791
> 目指す理想がpimpl?
違うけど、おまえなんかに説明してもチンパンジーに因数分解を教えるようなものだ std::filesystem はいいな。やっとまともに使えるものができたって感じ
C++17からって遅すぎだと思うが 文字コード周りの混沌ぶりに比べれば、文字列クラス乱立なぞ微々たるものよ。 >>759
ver1.0とver8.0がライブラリの呼び出し規約レベルで違うならpimplでも静的にはリンクできないし、
ver1.0とver8.0がCRTレベルで違うならやっぱ静的にはリンクできないし、
ver1.0とver8.0がライブラリの呼び出し規約レベルで同じかつCRTレベルでも同じならpimplでなくとも静的にリンクできるし、
pimpl関係無くね？ ライブラリだとpimplというかvoid*にして、各種操作をc関数として公開
c++ではラップしたinterfaceクラスを提供って形だろ
実装側はc++の実装クラスにstatic_castして後はc++の世界で書く
pimplは中途半端だから使わない windowsのハンドルがそんなだね
中身どんぐらい変わってるんだろうか void*からC++クラスのポインタ型にstatic_castってできたっけ、 出来るよ
多態使いたかったらbase ptrとvoid*の相互変換をする
派生ptrからvoid*に直接変換すると危険 >>806
安全性と危険性が反対くね？
void*が指すアドレスは構造体やクラスの境界に整列している保証が無いのでは…
>>804
WIN32の内部において、ハンドルが単なるindexでなくポインタとして使われているという根拠は？
確かに正体がvoid*だったりするが、ポインタだとしたらOS視点では
INVALID_HANDLE_VALUE判定が
難しくなるのであった、（一般論として static_cast<void*>は最派生クラスにダウンキャストだね >>807
外見維持してることが重要なんであって中身でなにをどうしてようがはどうでもいいがな やべービルド通るわこれ
うちのコンパイラは壊れてるな…
int g_nSomeValue;
int main()
{
int* p = &g_nSomeValue;
int* q = static_cast<int*>(p);
printf("p=0x%p\n", q);
return 0;
} 貼りまつがえた、
誤： int* p = &g_nSomeValue;
正： void* p = &g_nSomeValue; void*は型情報が完全に消えるから、
型が完全に一つだとわかっているならそのままstatic_castすればいい
多態だと派生型からvoid*に直接変換してしまうと、void*から戻す場合に基底ポインタには戻せる保証がない >>802
依存している構造体のサイズやレイアウト変わったらアウトだろ >>803
C++でラップしてる時点で中途半端なのはかわらない
むしろ手間増えてる 過去の遺産のCOMなんて使いにくいて横で話ししてるやろ
10年後の環境のことまで気にする必要ないんだよ
ばっさり捨ててその時代にあったものを作るべき
無理に資産転用とか互換性とか気にするからクソが生まれる pimplで実装隠したところで、
引数に例えばstd::string使うだけでコンパイラバージョン変えたときの保証は無くなるしなぁ 要するに>>759は知ったかが無理矢理考えたアホストーリーと言うことでいいかな？w >>808
ああ、もうそういう返ししかできないのか…
高い理想とか笑えるわw >>814
pimplだと構造体の実装はライブラリ側に完全隠蔽なのでその観点はおかしい
つかｊコンパイラのバージョンも関係無い >pimplだと構造体の実装はライブラリ側に完全隠蔽なのでその観点はおかしい
何が言いたいのかというとライブラリ使用側がライブラリが依存する構造体メンバに直アクセスする前提なら
そんなライブラリはpimplにできんだろとゆーこと
つまりpimpl対非pimplの比較の想定が変
非pimpl条件のライブラリのインターフェース仕様だけ抽象度を下げて議論しても仕方が無い オープンソースやクローズドでも社内での話だったらソースごと提供すれば終わる話だし
社外提供なら多言語で使えるようにcのAPIを出すのが普通じゃないのか
その上で各言語用のラッパーも提供されるってのがありがちなパターン >>822
現時点で有用なら使うでしょ
逆に10年前からメンテされてなくて現時点でも使われてるライブラリなんてある？
メンテされてるかよりその時代に即したものに乗り換えてくでしょ いやメンテなり機能追加はしろよ
仕様がらっと変わるのわかってるもんなんて使いたくないわ
作り手も使う側めんどいだろ D なぜ流行らなかったし
Go 突き抜けてる
Rust ちょっと意識高い系
Nim 有望
JULIA 話にならない >>824
ライブラリじゃないけど例えばExcel2003とかまだCOM経由なら動かせるでしょ
COMの泥臭いインターフェースだから面倒だけどね >>827
動かせるけどクソだよね？
だから新しいのつかうじゃん？
つうかoffice系は延々と互換性意識してメンテされ続けてるじゃん >>828
俺が言ってるのはCOMの話な
Excelの話はケースバイケースだからなんとも言えんし俺には関係ないからどうでもいい >>829
COMの中身詳しくないんだけど一切メンテされてないの？
今までwinは山ほど脆弱性をupdateしてるけど、そういう中にCOM周りの修正とかなかったの？
間違いなくあったと思うんだよね。
COMに限らず現状使えるMS産のもので10年間内部が未修正のものなんて多分存在しないんじゃない？
だから10年後のことだけなんて考慮する必要なくて将来に渡り有益ならどうせメンテされるし一時的なもので将来無益になるなら消え去るんだよ >>829
なんか前後で俺の主張がずれてる感じで申し訳ない >>830-831
インターフェースの話とインターフェースの先にあるライブラリとかCOMサーバーの話をごっちゃにしてないか？ >>821
勘違い甚だしい
ライブラリ使用者に無関係で見せたくないからpimplで隠すという話をしてる隠さなかったら無用にincludeが増えるし、最悪そのinclude先の仕様変更で互換がくずれる場合もあると >>823
そう、それが結局いまだによくも悪くもベストプラクティス
わかってないやつ多いんだよ
いきってc++で自称モダンな設計で作り上げてあとで泣きながらcのインタフェース作るはめになる
たいてい機械的なラッパーではすまないからな void*的な「ハンドル」を経由して操作するやーつ
C由来のインターフェースは強いな >>827
> ライブラリじゃないけど例えばExcel2003とかまだCOM経由なら動かせるでしょ
Excelとか以前に、DirectXやシェル（エクスプローラー）そのものがCOMだから >>832
そうそう。脆弱性の話はCOMじゃなくてDCOM。
もちろんCOMも脆弱性とは無関係ではないんだけど、
それはC++がバッファーオーバーフローと無関係ではないのと
同じようにCOMの設計自体の問題じゃない Essential COMの第1章で、C++からいかにしてCOMに至るか書いてあるけど、あの流れすごい好き std::filesystem はようやくできたかって感じだが、環境変数でまたorz
なんでこう、使う道具がまともに作られてないんだろうな
C++はメモリ管理ばっかり気にしてる気がする。 >>836-837
> Excelとか以前に、DirectXやシェル（エクスプローラー）そのものがCOMだから
だからCOMとその先を区別してくれよ
COM自体は単なるインターフェース規約で実装は別
脆弱性とかは実装の不具合だから見つかり次第修正されてる
インターフェース規約も仕様バグとかありうるけどCOM自体の仕様バクは聞いたことない ＿
.:⌒: 、 __ ＞: : : : : : :. ＜
|: : : :/´ : : : : : : : : : : : : :. ｀ﾞ ､
‐.､／: : : : : : : : : : : : : : : : : : : i
У: : : : : : : : : : : : : : : : : : : : :/ ＼
/: : : : : : : : : : : : ', : { : : : : : : :} __ ＼
. ｊ: : ;彡': : : : : : : : : ' : ', : : : : : ﾘ ／ : : : : : : . . ＼
: : : : : : : : : : : : : : : }: :ト : : : : ′ /: : : : : : : : : : : ヽ '.
: : : : : : : : : : : : : : :ノ :∧: : : : { / : : : : : : : : : : : : : : ｖ
. i: : : : : : : : : : , ‐＜ ＞: :∧: : : :', ＞‐:'―: : : : : : : : : : : : : : :.
. | : : ／⌒y:／ /: : : : : _ヽ: : ／: ヽ: : : : : : : : : : : : : : : : : : :|
八: : { ^ {: : : Ｙ´ ∨: : : x ― - . . __: : : : :__, : : : : }
ｰ′ У: : j {: : : ﾉ ／: : : : : : :￣: : : : : : イ
〈: : :/＾ ｰ^ ／ : : : : : : : : : : : : : ＜
^彡 /: : :ヽ -‐= ￣￣
{: : :ノ
ゞ´ >>841
俺に言うなよ。俺はCOMは使われてるとしか言ってない。
シェル（エクスプローラー）をCOMで操作できるという
基本的な機能の互換性をなくすとか考えられん。 >>840
環境変数は昔から標準化されてるだろ。設定は微妙だけどデファクト標準関数があるし。 >>844
std::cout << なんとか("PATH");
のように一行でやる方法教えて
もちろん脆弱性などで非推奨と言われるようなやり方は禁止
俺はここまでできて「使える道具」だと思ってるよ >>843
だからCOMの話にその先であるエクスプローラの話を混ぜるなよ…
ところでExplorerってCOMで操作できたっけ？
Internet Explorerの話じゃないよね？ OpenStack, Terraform でも、クレデンシャルなどの環境変数は、1つのファイルにまとめる
それでプログラム内で、os.environ[ 'OS_PASSWORD' ]
みたいに取得する
直接、設定ファイルに書いて、git に保存するのは禁止！ >>847
実現可能な最小の行数
（一行でできるようにすることは他の言語で実現されてることからも明らか） ちなみにさっきオレオレで20行ぐらいの関数を書いて
一行で環境変数を取得できるようにしたよ。
でもこういうのは標準ライブラリで用意してあるべきもの >>853
俺が思ってるかどうかじゃなくて、
お前が、こういう理由で短いのがいい or だめと
"お前の意見" を書け ん？反対意見があるんじゃないのか？
ないんだね。
お前がなにか思ってるだけかよｗ この手のバカでもたった20行で作れるんだろ
やっぱりC++は偉大じゃないか >>845
だったらはじめから「僕はこうじゃなきゃヤなんだー」って言ってくれないと何も伝わらないぞ はじめから言ってる
> std::cout << なんとか("PATH");
> のように一行でやる方法教えて > 車輪の再発明
典型的なアイディアキラー！ マジ死ねよ
ガタガタくだらねえこと言ってねえで
本能のままにやってみたいことに暴走しなきゃ
何もできちゃ来ねえんだよ
そういう生産物の上にあぐらかいて怠けているゴミ共にわかるわけねえ！ std::filesystemができたように、
std:envも作れってだけの話なのにね
何がそんなに気に触ったんだろう？ >>860
はあ？845が初出じゃん
getenvでいいだろ。
未定義時のエラー処理まで自動でやってほしいのか？ > 何がそんなに気に触ったんだろう？
とぼけてんなよ、はっきり書いてんだろ
車輪の再発明と貴様はほざいた
撤回も修正も今さらいらねえ >>864
そんな下らないことで（笑）
一行とかそんなの重要なところじゃなく、
stdの名の元でまともなライブラリを作ってくれって話だよ
仮にも「標準」ライブラリなんだからさ
昔ながらのgetenvやその安全版はstd:stringが使われてないし、
std::getenvも、なぜかstd::stringではなくchar*が使われていて
使うとエラーとされるレベルの非推奨関数だし、当然ワイド文字版もないし
使おうと思った人なら、まともじゃないの意味ぐらいわかるはず
あ、使ったことない人が噛み付いてきたのかｗ
あと環境変数の未定義は正常な状態としてありえるのでエラーではない
細かくてすまんなｗ 適当な発言は気になるんだよ。 >>865
噛み付いてばかりじゃなくて、"自分の意見"を言うだけの
知識はあるのかい？ c++の標準ライブラリにプラットフォーム抽象の機能求めるってのは筋が悪いんだよ
filesystemだって結局はposixをテンプレートの味付けで焼き直した程度でファイルの監視もできないだろ
envとか別に標準で提供されなくても何も困ってない
1行かどうかなんてさらにどうでもいい
あと標準ライブラリが提供する範囲の機能で足りてるアプリ作ってるやつは
c++以外の言語使うことを考えた方がいい >>856
> お前がなにか思ってるだけかよｗ
うん、バカな縛りだなと思ってるw 組み込み系なんてenvどころかfilesystemとかそもそもねぇの普通な環境も多いしね ここは毎回しょうもないことで荒れるな
これだからC++界隈って嫌い まあもともと広いレンジで使われることを目的とした言語だし
いろんな輩が入ってくるのはしゃーない。
しかしc++11以降は明らかに開発してないクソガキが増えたなという印象はある。 ないなら作りゃいいのに
なんのためプログラミングなんだろか せっかくhas_includeみたいなのも出来たのだから、環境ごとに存在しない場合機能提供されないようなものも標準化進めていったらいいんだよね >>876 >>877
場所そのものを馬鹿にするのはよくない。
それは差別や権威主義を生み易い。 >>875
一応フリースタンディング処理系っていう分類があるのでそれはもうされてる >>732
一つ教えてください、pimpl とか何べん読み返しても「利益の源泉」がわからないのですが、一つ一言で言い切っていただけませんか？ >>775
＞マングリングって知ってるか？
＞そもそもC++のクラスライブラリを簡単にリンク
私は Java も ruby も触っていますが、お手軽に java のライブラリを c++ から使いたいと、ふつふつ、と、思っているのです… >>880 （732じゃないけど）
クラス実装の変更に対する再コンパイルの必要性の削減。
これが利益とならない環境では用はない。これが利益となる環境はある。
個人的には同じ目的ならインターフェースクラス＋生成関数のほうが手間が少なくて好み。
公開済みのクラス（具象クラス）に後付けでも適用できるのが pimpl の強みじゃないかな。 >>833
>>821は、>>802からの流れなのでヨロ
そうした上で、
>ライブラリ使用者に無関係で見せたくないからpimplで隠す
それがpimpl固有の特質である根拠とは…
構造体の詳細を見せる必要が無いなら
別にハンドルでも良いじゃん？Cだと昔からそうしてきたわけやし…
>>834
構造体の詳細を見せる必要が無いなら
別にハンドルでも良いじゃん？Cだと昔からそうしてきたわけやし…
pimplとかC++で実装する側がソースコードを整理したい目的で使うものであって、
ライブラリの公開インターフェースがpimplであるべきという論こそ勘違い甚だしい コンパイル時にリフレクションできたらC++にはもう何も望まないんだけどな リフレクションしたいとか実行時にあれだとかこれだとかしたいとか
もっと安全性を高めたいとかいう人はC#にいったらいいとおもうんだが
なぜいかないのか マングリングとかも規格で決めてほしいよね
そうすればクラスのエクスポートなんかも簡単になるのに 動的はともかく静的リフレクションはあって困る場面は無いだろ
冗長な記述や変なマクロを使わずに、enumを文字列化したりしたいだろ 名前マングリングの方法がコンパイラ毎に違うおかげで
互換性のないオブジェクトファイル同士がリンクされる事故を防げる、って
『More Effective C++』に出てたな。
便利さも欲しいが安全性も保ちたい、という要求のせめぎあいだな。 今生き残ってるC++のコンパイラってどのくらい種類あんの
特定ハード向けのもgccの派生なんでしょ？ >>833
>>883とｵﾓﾀがちょっち訂正しておき鯛、
publicなメンバ関数だけでprivateを一切含まずに事を済ますクラス定義を広義のpimplとみなすなら
ライブラリの公開インターフェースとしてpimpl最高じゃな
ハンドルだけだとユーザーが間違った呼び出しをしかねない
これをpimpl式にクラスでwrapするのはｽｹﾞｰ有効 つーかハンドルで渡して使う時にキャストするって面倒だからさ
privateだからいいでしょとかいう問題じゃない 記述の煩雑さはもう諦めるけどインラインPimplでゼロオーバーヘッドにしてほしい 煩雑さを許容できるならやれるでしょ
pointerでなくバイト配列にしておいて中でcastするやつ
気を付けないところいろいろあるけど オーバーヘッドを気にしている人の大半は、気にする必要のあるものを作っていない 実装をpimplに押し込めて公開インターフェース上の変数メンバの増減を無くすのが肝なんだから
pimplのデリファレンスのオーバーヘッドは避けようがないだろう。 そもそもprivateな関数宣言をpublicなヘッダに
書かないといけないというC++言語仕様の欠陥
publicヘッダとprivateヘッダの二つに分けて
クラス宣言できればよかった
ちなみにC#ではpartialクラスといって
複数のファイルにまたがってクラスの定義ができる >>896
こういうの
https://ideone.com/EB36N2
pointerじゃないからpimplではない まあ欠陥って言われてもprivateメンバー変数変更されたらインスタンスのサイズ変わったりするから
1) 参照してるソースも含めてリコンパイルする
2) ポインタで持つ（pimpl）
しかないからねぇ
C++的には現状の言語仕様でIDEでprivateは見せないようにもできるとかでいいと思う >>898
パズルとしてはいいけど真顔で書いてたらちょっと引くわw >>898
その場合でも任意の変数メンバの拡張性は結局 Hide::a の存在で保証されているわけだろう。
impl[32] と予約された範囲まで拡張できるというのもあるのかもしれんが。 結局低レイヤーを考慮しないでバカが文句言ってるだけで
そんなことに付き合う必要はないんだよ。 >>901
バイナリ境界にしたときの拡張性のこと言ってる？
それはまさに配列のサイズでリザーブだね
溢れたら終わり
目的がヘッダー依存を切ることなら必要に応じて配列サイズ増やせばいいだけ
めんどいけどassertかけてあるからミスることはない
あとpimplは中でnewされるのがいやな場合あるからそれを避けられるってのも大きいね >>897
（使う側が）、CPerson person[10]; や、new CPerson[10] のように書いたと
すると、C++は高速化のため、CPersonのバイトサイズを定数値として
静的にコンパイルして、スタックや Heapからそれらのオブジェクトの領域を
確保する。
なので、たとえC++でCPersonのprivateメンバがC#のpartialの様に分けて宣言できた
としても、それらを全て合わせた全体のバイトサイズが分からないと静的に処理できない。
故に結局、partialの一部であっても全体のサイズに影響のあるような変更が行われた
場合には、上記の様な形でCPersonを使うプログラムは再コンパイルが必要となる。 プリコンパイルドヘッダが標準化されればなんとかなるかも >>906
良いか悪いかは仕様次第なんじゃないの？
コンパイルされてたら無条件でアウト？ >>897
構造体データメンバのメモリ配置を正確に定義したいという目的を捨てない限り
privateなデータメンバをprivateヘッダに分けて定義できるようにしたところで
pimplが目指すような解決にはならない
ほとんど意味が無い pimplが目指すような解決というのは筆が滑ったorz
とにかくprivateなデータメンバをprivateヘッダに分けて定義できるようにしたところで
実装の隠蔽にはやっぱハンドル経由とかポインタ経由（pimpl）な間接参照が必要なままである
構造体データメンバの追加や削除や順序変更が
publicなヘッダに定義されたインターフェース仕様に影響しなくなりはしない >>900
言うてもplacement newしたオブジェクトに移譲してるだけだからたいしたことやってない
まぁこれが規格的にセーフかどうかは知らんけどな >>911
> uint8_t impl[32];
固定サイズで確保してる時点であり得んわ そこはどうにもならんな
他にいい方法あるなら知りたい
上で触れてるけど、逆にバイナリ互換とるときはそういうリザーブが役立つこともある >>913
> 他にいい方法あるなら知りたい
ないからpimplとかなんだろ
だからと言ってテキトーに領域定義とかあり得んだろ そもそもポインタ参照ごときのオーバーヘッドをも許さないほどリアルタイム性を要求するもの作ってんの？ >>914
適当がいやなら同じサイズにすりゃいいじゃん
static_asserの条件を==にすればいい
手間はかかるが、それが許容できる前提の案ね >>916
バカなの？
ちょっとサイズ変更されたら使えない
かと言ってどんだけ余裕持てばいいかは未来予知能力でもないと無理
要するに常人には使いどころがないってことな >>915
C++の用途として可能な限りオーバーヘッドをゼロとすることが要求されるケースがあるのは当然の話であるが、別に議論に参加するものがそういう物を作っている必要性はないだろうに、何でこだわってるんだ？ >>917
だから手間がかかると言ってるわけ
やる気になれば自動化できるスクリプトは作れるだろうけどね
バカと思うかもしれないけどreserveフィールドでバイナリ互換を保つってのは実際やるんだよ
未来を予測できないのはそのとおり
適当に決める
まぁお前の知らない世界の話だから気にするな 外部からはデストラクタもコピーコンストラクタも動かせないのにあえてインラインにする
理由がよくわからないな。
よっぽど特殊でピンポイントな要件なのかもしれないが。 placement new を使った
char* ptr = (char *)malloc(sizeof(CPerson));
CPerson *pPerson = new(ptr) CPerson;
という書き方、実は、「コンストラクタの明示的呼び出し」なるものを使って、
CPerson *pPerson = (CPerson *)malloc(sizeof(CPerson));
pPerson->CPerson::CPerson(); // コンストラクタの明示的呼び出し
と書くことも出来るらしいことを最近知った。 >>919
手間の問題じゃないよ
せっかく変更に強くするためにやってるのに
> 適当がいやなら同じサイズにすりゃいいじゃん
なんてやったら本末転倒だろ
> やる気になれば自動化できるスクリプトは作れるだろうけどね
未来予知機能付きのスクリプトができたらいいねw
> バカと思うかもしれないけどreserveフィールドでバイナリ互換を保つってのは実際やるんだよ
ああ、昔のコボラー爺の発想ねw
ファイルとか通信とかで外部とやり取りするようなものだと今でも普通にあるけどメモリーレイアウトでやるのは流石に悪手でしかない
> まぁお前の知らない世界の話だから気にするな
時代遅れのお前の妄想に閉じ込めといてくれw >>780
cygwinで配布してるwxwidgitはgcc3時代のabiでバイナリ作られてるが当然gcc8でもabiオプションで変えてリンクできる >>921 何を見て「出来るらしい」と言ってるのかな？ >>819
pimplが理想だなんて頓珍漢なレスで
ひっ絡んで来たのそっちだろうが
何がそういう返しだ
冗談は顔だけにしろ奇形チンパンジーめ >>927
まさかと思うが
> 目指す理想がpimpl?
って理想がpimplって言ってるとでも思ったのか？
デザインパターンの前に日本語の勉強しろよw >>928
安心しろ
あからさまにラリッてる廃人の戯言など
どうとも取ってねえよ
そんな価値があるとでも思っているなら
とんだナルシストだw >>923
pimplの目的が変更に強いことってはお前の見方にすぎない
コンパイル時に検知できるんだから特別手間ではないし、
呼び出しコストを下げる目的は達している
技術的な話したいなら物事をフェアに見ような 手間はあるけど（俺は）手間だと感じないだから、変更に強いとは思わない
って言ってるの？ 実装側のサイズが想定をオーバーしたら互換性無くなって再コンパイルになるんでしょ
それが許容される環境ならインターフェース切る意味が薄れるんじゃないの？
まぁ実際はオーバーしないようにするんだろうけど >>930
どうとも取ってないのに顔真っ赤にしてレスするとか珍しいなw >>931
ごめん、お前なんのために>>898みたいなことやるの？
説明できる？w >>936
pimplの説明ならこのスレで何度も出てると思うが？
それにしたいして、お前の反論は「俺はそうは思わない」という感想でしょ？
技術的な話したいなら物事をフェアに見ような >>893 というお題な対して出した案が >>898
privateは隠蔽できて、かつ呼び出しコストは低い
配列サイズ増やしたらバイナリ互換がとれないのは承知してる
しかしそれはI/Fにする構造体一般の話であってこの件に限ったことではない
もう十分説明したつもり >>937
>>898がpimplに見えるならちょっと黙っててもらっていいかな？
邪魔なだけだし
>>938
なるほどね
とにかくprivateは見せたくないって事ならそれでいいんじゃね？
俺はやりたくないけどw >>935
とID真っ赤にしてレスするやつ
別に珍しくもねえ どこにでもいる虫けらめ 事務職だけど、C++使ってる
こんな便利なプログラミング言語があるとは pimplesが顔に出たのは中学・高校時代だったか。 pointer to implementation 結局のところ、>>893の言う「インラインPimpl」なるものの解釈なんだよな。
「そんなものありえない」>>896
「こうすればできるよ」>>898
俺は「ありえない」派だが。 他の言語ではprivateを隠すための努力なんてしなくていいよね
あくまでc++特有のパターンとしてpimplがある
pimplの肝は、ポインタだけなら前方宣言すればincludeしなくてOKっていう
抜け穴的なところからきていてポインタであることは妥協の産物
implクラスを変更しても互換性が保たれるというのはあくまで副次的
ゼロコストじゃないわけでc++の思想からも外れている 何をもって思想から外れていると？
C++の設計思想は最速を目指すことじゃないからな 始まりはそうだったかも知れんが、現在の規格の設計思想は明らかに違う 最速を目指すって言うと少し外れてるけど、速度を重視するという所は変わってない それ以上に集団での開発効率を重視したもの
>>898のような奇怪なものよりpImplの方がモダンC++の設計思想に合っているのは間違いない >>950
明らかに〜
説明できないときにつかう常套句だよね
少なくともc++17まではその設計ポリシーが挙げられてるよ >>952
はぁ？
pimplのどこがモダンなの？
最低限delegateを手で書かなくてもいいようにしてから言ってくれよ
スマートポインタ以下だから 設計の方針は曖昧なものではなく明文化されてるから調べてきてね ハリソン・フォード主演映画「逃亡者」(1993年)の主人公の名前は、キンブルだったね。
この映画はサントラが良い。ジェームズ・ニュートン・ハワードが音楽担当。
このサントラの「Helicopter Chase」という曲は、「タクティクスオウガ」(1995年)というテレビゲームの「VENDETTA!」という曲によく似ている。 pimpl使ったことないからスルーしてたけど
>>947=>>949
ゼロオーバーヘッドの原則は言語が掲げるもので言語利用者を縛るものじゃねーよ
実際それが便利でコストが問題にならない使い方ならどう使ってもいいだろ >>954
君もなんか勘違いしてない？
最速を目指すなんて厨二病みたいなことを挙げていたというソースは？ >>959
> ゼロオーバーヘッドの原則は言語が掲げるもので言語利用者を縛るものじゃねーよ
そうだよ、だからこの手の機能は言語仕様には含まれないってことな
> 実際それが便利でコストが問題にならない使い方ならどう使ってもいいだろ
誰もお前に使うななんて言ってないから使いたいなら勝手に使ってろよw 質問です。
サンプルプログラムで割り込み処理の一文で
ISR(TIMER1_CAPT_vect) {}でサブルーチンを呼び出してたんだけど、()内の意味わかりますか？ >>961
＞そうだよ、だからこの手の機能は言語仕様には含まれないってことな
誰か言語仕様に含めろなんて言ってたか？
さすがに隠したいメンバをポインタ経由で隠して無駄にコストかかる言語なら俺もお断りだが
ちな俺はplmpl使いたいなどと書いてない、人の主張を勝手に捏造するな あと>>961=947と想定してもう一つ言っておくと
ポインタ変数の宣言に型(クラス)の実際の定義が必要ないのは抜け穴じゃない
必要ないから要求されないだけだ
どうもC++に対する認識がおかしい気がする
D&Eでも読んでこい >>964
> 誰か言語仕様に含めろなんて言ってたか？
誰もお前が言語仕様に含めろと言ってるなんて言ってないぞ
自意識過剰すぎだろ
> ちな俺はplmpl使いたいなどと書いてない、人の主張を勝手に捏造するな
使いたい「なら」な
C++の前に日本語やり直してこいw >>965
> あと>>961=947と想定して
バカほどこういう想定をしたがるw >>963
コンパイラが分からんけど、割り込みベクタテープルのシンボルだと思う。
タイマ1キャプチャ割り込みのハンドラを今から定義しますよ、みたいな。 サイズの違うコンテナ同士で代入を試みたらセグメンテーション違反になったんだが、リサイズしつつ代入って簡単にできないの？ >>970 できるよ。
#include <vector>
#include <cassert>
int main()
{
std::vector v1{1}, v2{1,2};
v1 = v2;
assert(v1 == v2);
} >>971
普通できるのか
boostの「STLコンテナらしく振る舞う」というある多次元配列コンテナでできなかったから一般的にできないんだと思っちゃった
スマン そのためのstd::vectorのメンバ関数operator=だしな >>968
頓珍漢な想定でくだらんことしか言えないお前が出て行けよw 今事務職であいてる時間C++やってるんだけど、事務職に特化したライブラリとかってない？ char str[ ];
と宣言した場合、str[0] = '\0';というNULL終端をしなければなりませんが
string str[ ];
と宣言した場合は、特にNULL終端の必要性っていうのはないのでしょうか？ std::stringはstd::string::c_strメソッドを使ってアクセスするとヌル終端になることが保証されている。 char hoge[] は char の配列
別に文字列として扱う気がなければ 0 終端は必須ではない
string hoge[] は(突っ込まれるかもしれんが敢えて言うと) char[] の配列
上の char hoge[] とは別物 あと片山の答えは >>978 の回答になっていない無関係な話 (いつものことだが) 今やc_strでなくてもnull終端は保証されてるしな char str="";で多分null終端される。
stringは多分std::stringなのでそもそも文字列ではなくアドレスを扱う。
た・・・ぶ・・・ん・・・。うぼぁあああああああ。 >>978です
すみません 文字列として扱い、いきなりその変数を文字列と文字列の連携で使う場合の話です
つまり、その場合でも std::stringで宣言する場合は、"\0"で初期化する必要は無しということですね？ すまん書き直し。
char str[]="";で多分初期化時にnull終端される。
「string str[];」は多分std::stringの配列なのでそもそも文字列ではなくアドレスを扱う。 >>985
説明が上手くないからもうコードで書きなよ ひょっとするとstd::string str[]じゃなくてstd::string strの間違いじゃないの？ 日本語の説明よりコード片の方が多少間違っていても意図を理解できるという char[]は文字の配列＝一つの文字列でstring[]は文字列の配列だからそもそも比較するのが間違ってる >>978 の char str[ ]; string str[ ]; は、どっちも
要素数不明の配列の定義でコンパイルエラーになるんと違うか?
宣言ってことは extern のつもりなんじゃろか。
>>988 の言う通り string str[ ]; は string str; かも知れんけど、
いずにせよ「質問が曖昧で答えようがない」の類かと。 アスペ多すぎ
まともな頭していればstring str;の書き間違いだってわかる >>992
本気でstring str[];だと思ってる可能性を否定しきれない
現実にその手の奴はいるし >>978です
明らかに自分が悪いです
char str[ ];
と宣言した場合、str[0] = '\0';というNULL終端をしなければなりませんが
std::string str;
と宣言した場合は、特にNULL終端の必要性っていうのはないのでしょうか？
に修正です 無い
というか元々stringはC言語由来のゼロ終端とは違い、
「サイズ持ってんだから最後を示すデータは不要」という考え方だった
C++11からは利便性のためにゼロ終端が保証されてるけどユーザーが何かする必要はない 初心者ぽいから説明が悪かったかもしれん
クラスが内部でやってくれることなので特に何かする必要はない
けど、内部データを直接書き換えたりするとおかしなことになるので注意 stringに対するstring_viewみたいにint配列等にたいするviewはありますか？ '\0' と 0 とどっち使うのが良い？
NULL は論外だよな このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 54日 17時間 25分 19秒 5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/
▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php レス数が1000を超えています。これ以上書き込みはできません。
