◎正当な理由による書き込みの削除について： 生島英之 とみられる方へ:C++相談室 part145 ->画像>2枚
動画、画像抽出 ｜｜
この掲示板へ
類似スレ
掲示板一覧 人気スレ 動画人気順
このスレへの固定リンク： http://5chb.net/r/tech/1568362404/ ヒント： 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。
C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。
前スレ
C++相談室 part144
http://2chb.net/r/tech/1563769115/ このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://2chb.net/r/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は関係ないだろ。
あ、ID出るんだったな
整理すると
ちなみにdynamic_castでアップキャストする場合はvtable要らね
dynamic castでアップキャストする事あるの？
そもそもアップキャストはリスコフの置換原則が成り立つクラスになってんなら何もしなくも勝手にできる
今まで仕事でRTTI有効だったプロジェクトはひとつもないわ
バッチ処理系統の仕事ならポリモルフィズムなんて糞の役にも立たんどころか
COBOLでもEVALUATE文なんて普通に出てくるだろ
そういうカスなことやってるからメンテ不能になるんだよ。。
rttiに使う必要がでた時点でc++はミスチョイス
RTTI嫌ってるけど実際どの程度パフォーマンスに影響するの
正直、初めてポリモの話を聞いたときは
C++は型の実行時識別をvtblのアドレスでやるからdynamic_castする以上はアップだろうがダウンだろうが対象クラスに仮想関数が一つは含まれないといけない
>>22 ポリモとダウンキャスト（RTTIを使うか否かを問わず）を混同するとは情け
ﾅｻｽ、
コールバック関数ならいちいちポリモとかしなくとも無名関数とかで良いやんジャバじゃあるまいし、
vtableとvtblでNGしたった(´・ω・｀)
>>28 ラムダをどっこかに登録してコールバックしてもらうとき
自分が死ぬとき登録を解除するのが面倒じゃね？
結局thisとpairで登録する羽目に
だったら初めから仮想関数で良くね？
コールバック関数を渡す側がコールバックされるより先に死ぬ可能性があるとか
仮にそうであるとしても死ぬ際に空のコールバック関数に登録し直せば良い
>>25 ゼロコスト？ ああゼロオーバーヘッドのことかｗ
C言語がなんとか使えるようになりました。
34です。
EzoeRyoのgithubに公開しているcppbook
ただで読めるし「江添亮のC++入門」とかでいいんじゃない?
どいつもこいつも嵌める気しかねーのか。。
>>34 もちろんこういう書き込みは駄目だね
まず言語を学ぶ時点で実用性がない
学ぶならフレームワークだね
それにどうせ金にならないんだから、実用性なんて最初ならない
C++で生産性は向上しない
>>35 ＞書籍は11月、電子ならすぐに手に入るようです。
電子キンドル版もやはり11月まで入手できないとのことでした
cやったばっかの人に江添とか薦めるくらいならc++03のとこから地道に教える方を選択するわ。
もちろんC++11,14,17,20と教えていくんだろうな？
今となっては「auto_ptrはコンテナに入れるな」だの「vectorのメモリ領域が連続してると仮定するな」だのを
基礎が全く出来てない単発だらけのこんなとこで聞くのが間違い
ビャーネを勧めるとかw
>>34 最も大事なのは本人のやる気だ
モノになるか否かを本のせいにするようではそれがない
俺自身の経験から言うと
変にかみ砕いたバカ用の本や
筆者の思い込みを熱く語っている本よりも
ドライなやつがいい
具体的には禿の本や規格票が俺にとってのそれだった
必要な情報は客観的事実でどっかの馬の骨の主張じゃない
解らんところをどう攻めるかも自分の頭で考えるのが大事だ
>>34 stringとかをライトに使いたいのならサンプルコード探して真似るだけでもいいかと
ただ、stringやvectorがどういう仕組みで出来ているのかはいずれ理解する必要出てくるから
独習みたいな本を手元に置いといた方がいい(
>>47 みたいに古い本だと一部仕様が違ってたりするけど
言っちゃなんだが、実際使ってみるっつーか
プログラミング勉強する前にコンピュータアーキテクチャ勉強しろ
https://en.cppreference.com/w/cpp/language/namespace using directiveにはnamespace以外にも用途があるからと思われ
>>54 さっき、名前探索の「優先順位」に違いが出てくるからかもしれないと気付きました。
using-directive を書いた namespace よりも、その親や先祖となっている
namespace で名前が宣言されているかのよに振舞うということは、
その分、名前探索では優先順位が少し低くなります。このことによって
同名の名前が内側に宣言されていた場合、振る舞いが変わってきそうです。
34です。
C覚えたんならC++やらずに他の言語やってもいいんじゃね。と思った。
他の言語なんかやめとけ
>>57 残念ながらc++に関してはそのうんこを超える入門書がないだわ。
今時本で勉強しているやつは時代遅れ。
辞書がメインだよ
やっぱ言語を作った人が書いた「プログラミング言語（言語名）」を読むのがとっかかりとしては一番良い
>今時本で勉強しているやつは時代遅れ。
でも今、本の値段が上がってるない？
てか導入なら本がいいかもだけど、一度覚えれば更新はネットのコンテンツの方が良いからなぁ
でもネットだと最新のものが上位に来やすく、しかも、そのサイトを書いている人は
本も読んでネットも見て自分で判断するんだよ
>>54 >の部分の正確な意味が分かりません。
訳「ボクは馬鹿です」
>全体が、
>「using-directive」であるという理解なのですが。
まあそのページの下の方にもそう書いてあるな
何の助けにもならず何の意味もない全く必要のないレス
cout << sizeof "abc";
sejukuの侍エンジニア塾ブログじゃねえの？
いい加減だよな
色々ツッコミどころがあるんだよねあれ
実際糞記事読むくらいなら
初心者には難しいし使ってる人には知ってることしか書いてない
>>84 極端だな。初心者が次のステップに進むにはちょうどいいだろう。
そうか？ここの連中なんてほとんど理解してるように思えんが。。
あるグローバル変数を変更しているpublicメソッド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
まあこんなクロージャとの組み合わせのときにちょっと意味があるのかもしれんが…
謎じゃない
ファイルにテキストを書き込みする際に、
書き込んだバイト数の合計を数えるしかない。fprintfなら戻り値。文字列ならstrlen。
合計バイト数がわからない場合は最初に全部数えるか、バイト数の代わりに行数などを使う手もある。
頑張ってプログレスバーを実装したはいいがいざ実行すると
一瞬で表示が終り実装した意味あったのか・・と嘆く
>>112 の未来の姿がみえる・・
書き込んだ量を取得することより、書き込み総量を計算するほうが難しい
つーかテキストだろ？ギガ単位のサイズじゃないんなら
だな
プログレスバーとかユーザーの気を静めるためのインテリアみたいなもんなので
いやプログレスバーは「きちんと」「しっかり」作らないと
長らくぴくりとも動かなかったプログレスバーが一気に進んだとき
>>122 自分でそれを見たらイライラするタイプだろう
99%で止まるやつはイライラするな。
progress_displayたん…どうして死んじゃったの…
全支店のファイルを集計するツール作った時
処理中のファイル名をリアルタイム表示して
プログレスバーの下に店名と店長の名前表示すりゃいいじゃん
その支店に接続するのにかかった時間を計測しておいて
接続先と毎秒の処理したバイト数でも表示すればいいんでね。
>>129 店長の名前は関係ないだろ
うっかり考え込んでしまったわ
あるクラスのインスタンスを生成するときに、必ずあるメンバを初期化してほしいとします。
>>137 モダンなやり方は = delete;だろう。
古臭いやり方はprivateにして定義を書かないようにすれば、アクセスできないようになる。
どうでもいいがC++界隈はハチミツギョーザとか蟻人間とか
>>138-139 ありがとうございます。
やりたいことそのものです。
キャンセルボタンなしの進捗ダイアログ表示して安心してたらESCキーで閉じられて不正動作
>>141 「蟻人間」のコテは最近それに改名されたものですよ…
Visual Studio 2019 C++ community editionを使用して
$(Path)という定義済みマクロが無いか、あるいは環境変数PATHの内容が
>>146 さん。ありがとうございます。
絶対パス指定ならリンクは通りました。
ただ、相対パス自体はあるのですが展開結果が連結しているようです。
重ねての質問になるのですが、
#pragma 等で相対パスを使用する際に、
相対パスが連結している場合はどう対処すればいいのでしょうか？
ライブラリをソリューション相対指定可能なフォルダに置いて
std::variantってテンプレートによる静的ポリモーフィズムを実現しつつ一つのコンテナで管理したいという要求から生まれたんでしょうか
> std::variantってテンプレートによる静的ポリモーフィズムを実現
gcc, clang, VC++, その他
intelも使われるし、C++ Builderも使われてる
iccって高いだけで性能もgccとほぼ変わらないなら値段に見合う利点あるのか？
メニーコアなCPUとSIMDを使ったときのプロファイラが優秀
普通に17使うだろ
お仕事だとそうぽんぽんバージョンあげられないし
最近はmsvcがバイナリ互換保ち続けているから安心してあげられる。
>>160 filesystem使って見た？
まだ荒削りで所々変なところがあるけど
方向性としてはいい線ついてると思うぜ
あ、こいつバギーなライブラリ入れて現場荒らすタイプだわｗ
勝手にライブラリ追加できる時点で糞みたいな職場じゃね
まあケースバイケースだろ
>>162 ファイルシステムまわりはこてこてにネイティブ依存の内製のものがあるので出番はないでしょうね
パフォーマンス第一の仕事なもので
あと標準ライブラリはデバッガやプロファイラのことがスコープ外なのでそのあたり自分達で整備しないと採用できないってのもある
なるほどね
同じじゃん標準ライブラリは一般性重視故に特定の問題領域において必ずしも最高の性能は発揮しない（最高の性能となる保証がない）ことは確定的に明らかよって80-20の法則の80部分からﾊﾟﾌｫﾁｭｰしていく
てかc++でやることじゃねーだろどう考えても。
汎用性・可搬性を重視するかパフォーマンスを重視するかのスタンスの違いだけでしょ
>>173 filesystemみたいなライブラリの実装。
visual studio 2019 16.3でついにconceptが使えるように（赤線でるけど。。。
このスレはwinapiを扱ってますか？
>>188 win32api ならやってる人は少なからず居ると思います
文法とか開発思想の初歩的な質問なんだが、例えば最大流問題を解くプログラムと最小費用流問題を解くプログラムで「Edge」という構造体や「dfs」という関数の意味を変えたいときに使うのが名前空間だという理解でOK？
名前空間は名前をまとめるだけであって隠蔽したり上書きしたりする機能はない
>>192 そのくらいのプログラムでは名前空間は使わない方がいい。
使うべきなのはクラス。
いや同じ識別子を違う意味で使いたいのなら名前空間だ
>>192 その例では明らかにグローバル変数を使う必要はない。
「最小費用流を解くクラス」のメンバに押し込めるのが普通だと思われる。
名前空間は一連の処理や機能をライブラリとしてまとめるときに他のライブラリと名前衝突しないようにするためのものだ
>>197 個人的には自分もそう理解しています。
自分が作るプログラムでは namespace は基本的に使う必要はほぼ
有りません。古い時代に既に作ってしまったプログラムで名前が衝突して
困るような場合に使うと便利な機能として登場したのではないかと思っています。
せっかくの回避策をマクロでばっちり透過してくれた素敵なマイクロソフトｗ
>>198 昔作ったものに対してだけでなく、いま作ったものが将来使うときに名前の衝突を回避するという目的もあるぞ。
なぜ日本人c++プログラマの99%はstd::vectorもstd::find_ifも見たことすらないのだろう。
体感で8割ぐらいかな
C++20に入るauto変数を使った簡易関数テンプレートは宣言と実装を分割してコンパイルできますか？
vector知らんのはいたとしても組み込みマンくらいだろ
>>206 多分戻り値型と同じで、1つの翻訳単位内ならできると思う
宣言だけヘッダに書いたりするとautoのままだと呼び出せない
>>208 組み込みマンはC言語だろ
C++使っててstd::vector知らないのは流石に勉強不足
>>210 組み込みマンだからprinf知りませんみたいなもんだなｗ
vectorの存在は知っていても中身は知らんやつばっかだろ
まあ実際計ってる奴はそんなにはいないわな。
まあ最適化有効にすれば、すればそこいらの玄人が生配列でごちゃごちゃ書くより速くなることが多いがな
サイズを変えない操作でvectorと生配列の効率に違いなんかないだろ
ただ最近のc++の最適化前提のスタンスはいただけないな
>>217 そういうのはコンパイラベンダに言わないと変わらないでしょ。
言語規格としては知ったことではない。
もし最適化の有無で速度の変わらないコードがあったとしたら、まず間違いなく人が読めるものではないだろうな
こういう開き直りのスタンスって何か固有名詞ついてなかったっけ？
>>219 Cはコードはそこまでひどく遅くならないからね
そのおかげで実行時の速度と抽象化した書き方の両立ができるのでまあ仕方ないのでは
仕事でやってるので仕方ないで済まないんですよね
>>224 10、100倍遅い問題がPC買い替えてなんとかなると思います？
あと使ってるPC結構いいスペックですよ
開発環境には金かけてくれる会社なんで
仕事でやってようと高水準言語とはそういうものなのだから仕方ないものは仕方ない
仕方ないで済まないのでc++使わずc使うっていう話だな。
じゃあ使わなければいい終わり
c++の問題を指摘したら自分が否定されてる気持ちになる人ですね？
自分以外は仕事でC++使ってないと思ってるのかねえ
C++の問題ではなく、トレードオフなものを両取りできないことに腹を立てている馬鹿の頭が問題
debugバージョンでもinline有効にすれば良い
>>217 問題再現できないのってUB踏んでるんじゃ...
c++ほどサンクコストに引っ張られる輩を作り出す言語はないだろうな。
そんな掘ってもしょうがないところが深くても邪魔なだけなんだよ。
速度や効率を度外視すれば実はプログラミングはものすごく簡単になることが多い。
アルゴリズム的に改善できる話なら言語関係ないじゃん
固定少数が速いとかdoubleよりもfloatが速いとか割算は遅いから掛け算だとか色々な噂聞いたけど・・・
https://ideone.com/p9ISAq これなんで通らんのやろう？
コード補完で読み切れないのはいいけど、コンパイラさんは読めても良いのでは？
class A :public 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の方が速いよ
floatが早い今どきのプロセッサってGPUの話か？
直前の計算結果を次の計算で使うようなありがちな状況だと、SIMDじゃ一切早くならないのでは？よく知らんけど
x86とかも典型的だろ
SIMDで1語で複数のfloat演算を並列にやったら早くなる
今はfloatのが速い
>>253 1個のプログラムの中に一個か二個の float しか使わなくても、 double の場合より速くなるのですか？
そもそもイントリンシックを書かないのに SIMD のコードが出力されるのですか？
私は、コンパイラは fpu のコードしか吐かないじゃないか？って考えています
速さ計測すればいいじゃん
>>262 1個のプログラムの中に一個か二個の float しか使わなくても、 double の場合より速くなるのですか？
そもそもイントリンシックを書かないのに SIMD のコードが出力されるのですか？
そもそもx64ではFPUは無かったことにされている
>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とか使ってみたらいいわ
言ってる意味わかるから
あ、もちろんデバッグビルドの話な
C++を使わないと言っているやつに、どうぞご勝手にということと何の関係が？
>>268 でもアセンブラで直接使わないと無かったことにされるだろ
>>261 amd64でfpuコード吐かせるほうが手間じゃwwww
そもそもプログラム中に一個か二個の浮動小数点演算なんて最適化ポイントちゃうがなwwww
>>272 プロジェクトの設定でfpも選べるよ
既定だとsse使われると思うけど
コンパイラの種類変わったら算術演算ぶん回す場合は結構差が出るだろうけど、同じコンパイラでバージョンかわると最適化とかの進化で結構かわるのかな？
質問です
絶対に、の理由が知りたいところだけど、普通はA_funcを仮想関数にしてBは空関数でオーバーライド。
c++17以降ならif constexprとstd::is_sameでできるんじゃない？
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
コンパイル通らないので助けてください。
>>294 clangさんが教えてくれた
std::string hogehoge() { return A<_T3>::template get<std::string>();}
ありがとうございました。
この場合Aがテンプレートなので、Aの先のgetが何者かコンパイラは判断つかないので
この場合のエラーメッセージ、GCCはほんとに何言ってるのか分からないのを出すのでclang様様
C++テンプレートのプログラミングでのエラーを読み解く訓練をしているうちに
そのうちエラーメッセージを見ずにエラーを修正できるようになる
ちなVC2015か2017か忘れたけど、一時期までのVCは
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++って文法に曖昧さがないことどうやって保証してんだろ
いや、そんな保証は端っから諦めてるだろ
>>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プログラミングの質問で申し訳ないのだけど、
>>322 あるライブラリでのq1 * q2 という書き方が、q2 * q1
がどういう意味に解釈されるかは、
>>322 (
>>323 は誤投です。)
あるライブラリでの q1 * q2 という書き方が、別のライブラリでは
q2 * q1 と等価なことが有り得て、それはベクトルや行列計算全般に
言える記法の違いなのでこのソースだけではなんとも言えない。
ベクトルの場合、成分表示を1列の縦行列と考えるか1行の横行列
と考えるかによって、賭け全の左右が逆さまになる。
その結果、成分表示で書かない表記も、左右どちらかで書くかは
好みの問題となる。
特に Quaternion の場合も同様。
>>324 誤：と考えるかによって、賭け全の左右が逆さまになる。
正：と考えるかによって、掛け算の左右が逆さまになる。
OpenGL系は縦ベクトルだね
>>326 数学や物理学では縦ベクトルが多いが、D3Dはそれに従ってない。
テンプレが糞だと思う瞬間はいくつもあるが
＞数学や物理学では縦ベクトルが多いが、D3Dはそれに従ってない。
>>326-327 縦横ってより右から掛けるか左から掛けるかだと思ってた
意味は一緒なんだろうけど
>>328 C++11からは連続して書けるようになったで
C++03いやC++98？のまま更新止まってるやつ
>>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 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)みたいな場合によっては莫大な値になりえる係数を掛けねばならないの？
イプシロンに誤差を掛けても意味ない。
>>366 なんか色々根本的に勘違いしてる
cppreference.comのalmost_equal関数の仕事はあくまで与えられたxとyがalmost equalかどうかの判定だよ
> x、yがそれぞれ±e、±gの誤差を有するなら
なにこれ？「誤差」って何に対する何の誤差？
>>367 >イプシロンに誤差を掛けても意味ない。
>つか、許容誤差の絶対値が与えられているならイプシロン使う必要もない。
左様ですなｽﾏﾝｶｯﾀorz
>>368 >なにこれ？「誤差」って何に対する何の誤差？
真の値に対する誤差じゃわﾊﾟｵｰﾝ
真の値に対する誤差に依存しないalmost equal判定とか、使いどころはきわめて限定されるはず、
>abs(x+y)はxとyの指数のうち大きい方を意味するものだったはず。
んまーulpをxとyの来歴に応じて調整すべき量とするなら
だれか、俺に分数を教えてくれないか？
足し算と引き算がマジ解らなくなってるんだ。
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関数は市民の義務だし
初心者ですが質問させてください
予想通りの馬鹿回答で笑ってしまった。
>>400 引数一つに対するテンプレート関数を作って特殊化してそれに少しずつ渡せばできるよ。
C++嫌いなのにいつまで居座るんだろうなこのガイジ
こんな雑談スレ好きな奴以外に需要ないだろ
>>400 c++17以降ならif constexprとstd::is_same_vの使用を検討してみるのもいいかも
400です。頑張ってみましたがどうにもコンパイルエラーが出ます
あ、こういうふうにするとコンパイルできました。引数2個の関数を特殊化したからエラーになった？
>>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の二つがあるのがややこしい場合は畳み込み式でもできるぞ
win系のOSの画面に1.txt~5.txtがあります。1.txtと2.txtをドラッグして選択したとします。
>>413 ListView_SetItemState
std::shared_ptrを構築後に(カスタム)デリータを変更するのは無理？
別のstd::shared_ptrをカスタムデリータ付きで構築してswapすれば
shared_ptrとunique_ptrでdeleterの指定方法が違うってのが興味深いね。
VCのlatestでchar8_tが入ってたわ
>>418 デリータごとswapされたわ
stackoverflowにも似たような質問があったけど結論としては出来ないっぽい
たぶん
>>392 別にテンプレ好きでも構わんが、C++ユーザー全員が趣味だと思ってんの？
>>405 雑談以外に役に立つ書き込み出来なくてすみません、ってことか
>>423 C++ユーザが全員趣味なんてどこにも書いてないし、あるプログラミング言語が趣味でしか使われてない状況なら、委員会なんていらないわwww
衣食住の確保以外の仕事なんてみんな趣味みたいなもんだよ
委員会なんて何の役にもたってねーだろ。
デバッグできねえのを人のせいにするクズがよく言うぜ
近年は新機能は三大コンパイラ(GCC,MSVC,Clang)での試験実装が入ってから仕様入りするのが普通になってるし
>>431 実装したことないやつは黙っててね。
で、そのコンセプトを実際のコードでコンパイルした時間がどれくらいになるかわかってる？
そういう有用なベンチマークもほとんど出さずに無理やり入れようとするから
信頼を無くしてるんだよ。
経験したことは全て正しいっていう日本特有のアホ理論だろそれ
コンパイル時間は、コンパイラの出力する最適化されたバイナリの実行速度に比べたら問題ではないだろ
似たようなものを複数書いてもバグ修正時に一部見落としなんて馬鹿げたことになるわけで
c++言語の場合、パースのコンテキスト依存が、識別子の種類でも変わるから、テンプレート時の記述でtypename やらtemplateやらで、識別子の種類自体を指定する羽目になっているのはあるよね
>>434 テンプレートふんだんに使ったライブラリ実用してるとひどいことにはなる
アプリ自体は数万行なのにコンパイル10分以上とか
>>432 お前が信用しないのは勝手だが、みんなの総意みたいに言うなよ
それは本当にパースの複雑さのせいなのかは疑問だな
最近C++触ってないけど数万程度で10分もかかるの？
>>439 かなり遅いです。
ヘッダファイル *.h とソース本体のファイル *.c では事情が違いますが、
OSのバージョンによりますが、Win32の標準ヘッダファイルの windows.h などだけでも
コメントを除外しても2万行弱くらいあります。
これのパースは、VC++で1秒～数秒くらいです。
通常は、precompiled header を使うので、一つのプロジェクトで一度だけ
パースされることが多いです。
ただし、プロトタイプ宣言やマクロ定義、構造体定義、inline関数定義
などだけで、実際のコード生成は伴わないので、*.c の数万行とは
また事情が違います。*.c はコード生成を伴うので、同じ行数であれば*.hよりも
遅くなる傾向があります。
しかし、それでも、C++98 の場合、数万行だと3秒～10秒以下でコンパイルできます。
c++の文法のせいでパースが遅いってレベルの話じゃないような
ヘッダオンリーのライブラリがポータブルとか言われてもてはやされるのがc++だからね
俺の10万行程度のアプリは1分以内にコンパイル終わるが・・・
「参照の配列」を作りたいときって現状 reference_wrapper を使う以外ないですか？
>>437 プリコンパイルヘッダー使え…！
>>446 VC++2010の場合配列要素のアドレスの配列というのを
それぞれ1万行ぐらい書いてリリースビルドすると10分かかる
spiritで構文解析させてたコード(その上et使った自作ライブラリあり)だから例として極端だったかもしれんけどね
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とかで検索しても上手く引っ掛からないみたい(有るには有るけど少ない)
他の言語で書かれたコードをスクリプトの要領で
言語間のABIの違いを透過的にしたいのならアセンブラの出番だね
>>457 今ならluaかjs(V8/ChakraCore/SpiderMonkey)だな。
【Lua】組み込み系言語総合 その7【Squirrel】 [無断転載禁止]©2ch.net
http://2chb.net/r/tech/1474536226/ pythonもできなくはないけど手軽とは言えない。
pythoｎを使いたい理由がなければやめておくのが吉。
pythonは呼ぶ方で、呼ばれる方としてはほとんど想定されてないわな。
>455,456さんどうもです
template<size_t 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の「非型引数」を使えば、理論上は、
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のバージョンは？
>>480 Express 2017 for Windows DesktopとProfessional 2019で確認しています
準拠モードを「はい」にしたら標準の規約に従うのかと思ったんですが変化なしでした
開発はWindowsでしつつもWindowsとLinuxどちらでもコンパイルできるようにしたいんですが
もしかしてそう簡単な話ではないんですかね
>>481 visual studio cmakeプロジェクトでググる
effective modern c++のnoexceptの項読んで思ったんだが、
>>482 cmakeってビルドに関するものだったような？
ソース自体はWindowsとLinuxで完全同一にしたいんですが
あれなんか自分勘違いしてるかな
とりあえずcmakeくぐります、有難う
VCコンパイラがWindows専用だからcmakeだけでは解決しない
cmakeってなんとなくしか使ってないんですけど何なんですか
>>487 cmakeってmakeの代用じゃなくてmakefileとかxxx.slnとかを作るソフト
なのでcmake実行後に各々の環境にあったビルドを行う
>>487 ビルドするためのスクリプトを作るツール、みたいに考えるといいよ
linux環境ならLinux用のものを作ってくれる
makeだと基本はlinux専用だし、.slnや.vcxprojはwindows専用だから、両方を面倒見るのは大変でしょ
ビルドするためのスクリプトを作るためのスクリプトを作るためのスクリプトなんてよくある話だよ。
GNU autotoolsをまともにいじる輩は消え去ったという現実をcmakeも味わうことになる。
CMakeってKitwareっていう大学発ベンチャーから出てきたやつだよな
VTKとparaviewの方が有名じゃなかったのか
ParaViewは最近になって有名になってるけど所詮はVTKのラッパーでしょ
cmake邪魔くさい
mingw使わずに標準のwindowsの環境で使えるようになってから出直してきて
makeとかのビルドツールって超重要なはずなのにおざなりな状況になってるのは不思議だ
クロスプラットフォームなソフト作るにしても、成果物が対象の環境で動けば良い訳で、ビルドをどの環境でも出来ることにそれほど意味はないからね
>>500 そう言って立ち上がった人は100億人くらいいたが誰一人として帰ってくる者はいなかった
>>498 wslでmingwクロス環境はマクソ提供だけど
あらゆるビルドツールは怪獣化して、怪獣を飼いならすためのラッパーが必要になり、そしてそのラッパーももれなく怪獣化する
会社でifstreamのファイルオープンがエラーになるのはなぜなのか不明。assert()で引っかかる。
ifsreamってcloseの後に再使用できる保証あったっけ？
makeが複雑なんじゃなくて
>>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 が既に入ってるなら
>>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な固定バッファにすべきか。するとすればどれぐらいの容量か。
２．もっといいバッファリングの方法はないか。
お願いします。
スピード命です。フレーム落ちは絶対にダメだそうです。
古臭いスタイルはさておき・・・
COBOLのWRITE命令みたいに非同期書き込み＆バッファローテーションてか？
遅延の原因は、vector::insert()でしょ。
ああそうか。std::FILE/CreateFileそのものがバッファリングしてるんだ。ならば下手なバッファリングは必要ないと。
std::vectorのメモリー動的確保は音声処理では不味いと。
>>530 ただそのスレッドでwriteするのが問題ないかはよく確認した方がいいよ
writeでブロックされることで音声のソース側の処理が滞る可能性がある
その場合はやっぱり別スレッドにすべきだね
setvbufって便利な関数を見つけた。これ使うか。
音声のバッファリングには普通はリングバッファを使う
ここまでのまとめ。
別スレッドにキューイングするのに適したC++標準クラスは何かな？
>>537 Queue への読み書きは、1要素当たりは短時間で済むことが多いので、
Queueを読み書きする場所で、必ず Critical Section などで囲むと良い。
一度に沢山の要素をまとめて書き込みたい場合は、原則的には、
1要素を書き込む処理をこまめに、Critical Section で囲むようにする。
必ずしも1要素ずつ囲む必要は無いが、こまめに囲った方が、
別スレッドの待ち時間が減ることが期待できるが、その意味が有る場合と
無い場合とが有る。
Critical Section の代わりに、Mutex や Semaphore などを使うことも出来る。
キャッシュに配列を置けばいいじゃねえか
タイミングで問題が出てるのにvectorにこだわるのはアホだよな
実行時のパラメータでバッファサイズ可変にするならvectorで始めにresizeしておくのが楽
>>540 それらの同期機能って標準C++のクラスだけで実現できるもんなの？
>>547 どこまでを標準と言ってるのか知らんけどお前の考える標準でスレッドをサポートしてるならたいてい同期機構もあるはず
>>547 WindowsではCriticalSection, CreateMutexなどがあったからC++11以前でも使えた。
C++11からstd::mutex, std::lock_guardなどが使えるぞ。
リングバッファの排他制御どうするか？
>>545 stlライクにしてる割にコピーやムーブが内部の値ベースなのおかしくない？
用途的に
ringのソース見たけど
>>551 std::atomicとかあるね
原理的に競合が起きないやつ
static DWORD s_dwTick;
>>558 Win32APIや音声仕様はC++じゃないのでよそでどうぞ。>蟻人間
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://2chb.net/r/tech/1556142878/ こっちに移動します。回答者に感謝します。
Win32APIって何だよ
>>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なんですが、
>>575 <wingdi.h>に#define ERROR 0がある。
ERRORのdefineがあるんですね･･･！
クソみたいなマクロにsmallもある
林檎だってcheckマクロでBoostに大迷惑かけてるしお互い様
>>582 そこは
ヘッダだけにな
と言ってやるところだろ
たしかmaxとかもマクロ定義されてたよね
いまはIDEが色変えてくれるからすぐわかるから別にいいけどね
最近ちょいちょい思うことだが、ある言語のここがどうであーだこうだと議論する場合
windows.hのマクロ回りでトラブル起こしているのは、殆んどvisual studio使用者だと思うのだが
認識の違いはコンパイラによるものであってコードエディタは関係ない。
モジュールでマクロとか気にしなくて良くなる（なるといいなぁ...）
コンパイラ変えてもマクロは変わらんでしょ
>>595 何言ってるのか意味がわかりにくいエラーメッセージを吐くのはコンパイラでしょ。
マクロは影響範囲わからんからなんとも
>>593 お前はまず日本語を正しく認識できるようになれよ…
>>591 は連中（=人間）の認識の話な
初心者であればあるほど親切なエラーメッセージが必要なのだけど、VCのエラーメッセージはgccに比べて不親切な印象がある。
C#が使いやすいと思っている人は、Visual Studioの入力補完に救われていることに気づいていない。
VS込みでいいじゃん
referencesource.microsoft.comみたいなありがたいものがあるのに
class 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.
投稿テスト
vs2019で::Aをコメントアウトするとokの意味がわからんorz
試してないが、理論上はこれでいけるはず :
N::Aを前方宣言するなら、宣言を名前空間Nの中に入れるかN::Aで宣言する必要があるってのはC++の規約通りじゃないのか？
>>608 が意味わからん
friend宣言は、当該宣言を含むクラスが属するスコープを対象とし
>>604 はfriend宣言ではなく前方宣言の問題なんだが？
いや前方宣言は関係ない
>>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 みたいにするってことでしょ
それ以外なら環境を提示してねってことかと
>Visual Studioなら
>>619 みたいにするってことでしょ
>>604 の
>・最初のクラスAを別の名前にする
と何が違うんだそれ
>>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では仮想化された関数しか使わないとか。
>>627 func(Base,Base)だけをvirtualってこと…ですよね？
え、こういうときにもvirtualて使えるの？と思って試したけどダメですね。
>>628 もうちょっと考えてみますけどたぶん難しいです
名前欄間違えてた…
>>629 あー…それかも
なんとなく知ってるだけで
まだ実装したことはないですが
それ正解かもしれません
調べつつやってみます
>>624 愚直に dynamic_cast で N*N 分岐からはじめたら？
派生クラスの種類が決まっているなら
C++でCOM扱うの苦痛すぎる
別にCOMは作るんじゃないんだよ。
そもそも文字コードどうなってるんやーーーー
変換なんてWideCharToMultiByte使って一つ変換関数作ってその関数を使い回せばいいやん。
>>640 Unicode文字列（絵文字とか）が文字化けするんだよー！
フォントの問題でないことは確認済み
例えばググって見つけた、こことか
http://www.t-net.ne.jp/ ~cyfis/win_api/sdk/WideCharToMultiByte.html
wchar_t を const wchar_t にするのはまあいいとして、
日本語はOKだけど絵文字とか化けるじゃねーか
わーけわかねなんｄｆっｒね；ｊｋ
ん？WideCharToMultiByteってShiftJISに戻すやつじゃねーのか？
windowsのコマンドプロンプトはまだ絵文字とかに対応してないよ
>>646 全てではないだろうけど対応してる。
❥
↑文字化けしそうだけど、横向きのハートとか
❤ とか
>>645 chcp 65001にしてもムダだったぞ
コマンドプロンプトよりJaneは早く絵文字に対応しろ
なんでコードページ932なのに、NSimSunにすると
Visual StudioのソースコードのデフォルトはBOM付きUTF8なんだな
Windows依存の話は、以下すれでどうぞ。
Win32API質問箱 Build125
http://2chb.net/r/tech/1551247748/ 自分の理解と違ってたので教えてください。
>>659 まさにピンポイントでした。
ありがとうございます。
>>636 マイクロソフトのコンパイラならまあまあ補助があったりするでしょ。
それでも面倒くさいことにかわりないけど。
失礼します。テストです：
>>663 補助なんてあったっけ？
まあ俺の知識はもう5年以上前の知識だから最近はちょっとはマシになったのかな
typedef const struct {
>>667 決まってない。
範囲外のアクセスなので、本来は絶対にやってはいけない。
読むだけでも不法例外が起きてしまう可能性もあるが、
書くのはもっとダメ。
たまたま、コンパイラシステムが何らかの目的で使っている
グローバル変数が arr 配列の直前にい配置されていて、
それが0になっているか、padding領域がたまたまそこにある
だけだと考えられる。
オブジェクトがスタックに作られてるかヒープに作られてるかってどうやって調べるの
>>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 埋め勝手に期待してると
>>682 > そして、ヒープから確保したオブジェクトのアドレスは、必ずそれらよりも大きい。
スタックエリアとヒープエリアの前後関係なんて決まってたっけ？
Boehm GC にスタック・ヒープの範囲を判定する部分があったはず。
>>682 ヒープから確保したアドレスがスタックより大きいっていうのはかなり特殊な環境では？
>>682 スタックとヒープのアドレスに前後関係の縛りなんかねえよ
互いに全く別個のデータ構造で相互に依存関係はない
お前ら甘いぞ
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の値じゃないのそれ
>>705 >>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++のヘッダファイルのクラス定義って、
>>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 でモジュールの機能が入るとかいう話になってるから
無理。
>>721 そう思うのは複数人で規模のでかいもの作ってないから
pimplは開発規模は関係なくて、ライブラリの公開するヘッダでユーザーに関係ないものを隠すために使わないか？
>>729 それも pimpl の目的としてはあるんだけど、
>>724 が書いているように C++ だとファイルの依存関係が必要以上になることもある。
それをどうにかしたら make で差分ビルドしたときに走るタスクが少なくなるので
規模が大きいプログラムで pimpl を使うとビルドがだいぶん速くなるということはありうる。
規模が小さいと体感するほどの差が出ない。 割に合わない。
そういう意味では規模は関係ある。
個人的には、自分ひとりで作ってるプログラムは、高頻度で全ビルドに
C++とオブジェクト指向をきちんと身につけてる人ばかりの環境ならいいんだけどね、pimpl
使ってるうちにインターフェースを使った典型的な奴とそう変わらない事に気付く
確かに、select_on_container_copy_construction(other.alloc_)が正しいような気はする
テンプレート活用のための最適化が全盛期の今 pimpl は時代遅れ。
pimplが時代遅れというのなら、それに代わる
>>739 クラスの前方宣言。
テンプレートによるコンパイルエラー回避。
>>740-741 どちらも型を書くので依存を断ち切れてない
pimplでも型を書くのに、何を言っているんだか
pimplの目的も方法も全く理解してないって白状したぞこいつ
privateをどうしても隠蔽したいならpimpl使うのもやむを得ないのかも知らんけど、そんな事態になったこと無いからよくわからんな
ライブラリ作る時にstd::unordered_mapとかメンバに使いたいと思わないもんなのか、よくわからんな
>>739 自部屋に引き籠もって外界との依存を断ち切ります。
ライセンスに書いとけば良い
ただ単に仕様と実装をすっきり分離できるというだけでも充分な動機になる
>>747 > pimplで.cppに閉じ込めないとコンパイラやSTLのバージョン違いで壊れるんだけど
ん？どう言うこと？
なんかやり方間違えてね？
>>750 private部分を見なきゃいいだけだろw
そもそも実装は.cppに書くんだし
エディタが貧弱だったころの名残を未だに引き摺っている
class Util() {
>>755 そこをわからんって言ってるやついないんだよ。
わかった上で変更になったらどんくらい問題なんや？ 別にええやろ。 と言う場面の方が多いという話なんだよ。
pimpl が有用な場面があるっていう主張もわかるよ。 わかるけど、そういう場面に遭遇したことないなぁという話なんだよ。
>>755 それだけならMinorClassを前方宣言するだけでincludeいらない
>>757 MinorClassの実体をメンバにするなら前方宣言じゃだめ
ポインタなら前方宣言にできる
Utilはあるライブラリの公開クラスです
privateメンバをポインタ型にする手間や不都合とpImplの手間や管理コストのどっちを取るかだろうな
>>760 オブジェクトを生成するには「大きさの情報」が必要だと覚えておくとわかりやすいと思う。
クラスの内容がわからないと大きさが確定しないから生成できないけど、ポインタの大きさはわかる。
>>759 そういう状況があることはわかるよ。
でもそんなことしねーよって話なんだってば。
>>763 それお前個人がしたことないって言う経験談？
それとも他の代替手段を取るってこと？
先に言っておくと前者ならすっこんでろ
>>764 俺がしたことないという経験談だが、
ここで pimpl が割に合わないと出ている意見は
そういう状況があんまりないという内容だということの説明でもある。
そういう状況で必要だってのはわかってるし、
そういう状況にあるなら使えばいいよ。
それはわかってるんだよ。
だからしつこく説明しないいよっていう話。
要するに
>>759 はまるで見当はずれのこと言ってんなぁという感想。
単機能ライブラリ作って渡す仕事してる人にとっては日常なんで、検討外れとか抜かされても勝手なこと言ってんなあとしか
>>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 にあたる部分を
>>768 依存切りたいならpimplと言ってるところに
依存気にしてないからpimpl不要っていってるのがお前
不要ならすっこんでろって
>>784 目指す理想がpimpl?
確かに話にならんなw
>>790 ただ20年間I/F変えないようにするにはあの程度の手間は必要なわけで
まあもうちょいスマートにできるんじゃないかなって思うところは多々あるけど
>>789-790 COMが使いづらいと言うか、C++とstdとSTLとWindows APIとCOMの流儀が
ごちゃまぜで、メモリの確保の仕方と文字列の扱いが混沌を極めてるｗ
.NETは（特に起動の）遅ささえなければ、ずっと簡単だよな。
>>791 > 目指す理想がpimpl?
違うけど、おまえなんかに説明してもチンパンジーに因数分解を教えるようなものだ
std::filesystem はいいな。やっとまともに使えるものができたって感じ
文字コード周りの混沌ぶりに比べれば、文字列クラス乱立なぞ微々たるものよ。
>>759 ver1.0とver8.0がライブラリの呼び出し規約レベルで違うならpimplでも静的にはリンクできないし、
ver1.0とver8.0がCRTレベルで違うならやっぱ静的にはリンクできないし、
ver1.0とver8.0がライブラリの呼び出し規約レベルで同じかつCRTレベルでも同じならpimplでなくとも静的にリンクできるし、
pimpl関係無くね？
ライブラリだとpimplというかvoid*にして、各種操作をc関数として公開
windowsのハンドルがそんなだね
void*からC++クラスのポインタ型にstatic_castってできたっけ、
出来るよ
>>806 安全性と危険性が反対くね？
void*が指すアドレスは構造体やクラスの境界に整列している保証が無いのでは…
>>804 WIN32の内部において、ハンドルが単なるindexでなくポインタとして使われているという根拠は？
確かに正体がvoid*だったりするが、ポインタだとしたらOS視点では
INVALID_HANDLE_VALUE判定が
難しくなるのであった、（一般論として
static_cast<void*>は最派生クラスにダウンキャストだね
>>807 外見維持してることが重要なんであって中身でなにをどうしてようがはどうでもいいがな
やべービルド通るわこれ
貼りまつがえた、
void*は型情報が完全に消えるから、
>>802 依存している構造体のサイズやレイアウト変わったらアウトだろ
>>803 C++でラップしてる時点で中途半端なのはかわらない
むしろ手間増えてる
過去の遺産のCOMなんて使いにくいて横で話ししてるやろ
pimplで実装隠したところで、
要するに
>>759 は知ったかが無理矢理考えたアホストーリーと言うことでいいかな？w
>>808 ああ、もうそういう返ししかできないのか…
高い理想とか笑えるわw
>>814 pimplだと構造体の実装はライブラリ側に完全隠蔽なのでその観点はおかしい
つかｊコンパイラのバージョンも関係無い
>pimplだと構造体の実装はライブラリ側に完全隠蔽なのでその観点はおかしい
オープンソースやクローズドでも社内での話だったらソースごと提供すれば終わる話だし
>>822 現時点で有用なら使うでしょ
逆に10年前からメンテされてなくて現時点でも使われてるライブラリなんてある？
メンテされてるかよりその時代に即したものに乗り換えてくでしょ
いやメンテなり機能追加はしろよ
D なぜ流行らなかったし
>>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*的な「ハンドル」を経由して操作するやーつ
>>827 > ライブラリじゃないけど例えばExcel2003とかまだCOM経由なら動かせるでしょ
Excelとか以前に、DirectXやシェル（エクスプローラー）そのものがCOMだから
>>832 そうそう。脆弱性の話はCOMじゃなくてDCOM。
もちろんCOMも脆弱性とは無関係ではないんだけど、
それはC++がバッファーオーバーフローと無関係ではないのと
同じようにCOMの設計自体の問題じゃない
Essential COMの第1章で、C++からいかにしてCOMに至るか書いてあるけど、あの流れすごい好き
std::filesystem はようやくできたかって感じだが、環境変数でまたorz
>>836-837 > Excelとか以前に、DirectXやシェル（エクスプローラー）そのものがCOMだから
だからCOMとその先を区別してくれよ
COM自体は単なるインターフェース規約で実装は別
脆弱性とかは実装の不具合だから見つかり次第修正されてる
インターフェース規約も仕様バグとかありうるけどCOM自体の仕様バクは聞いたことない
＿
>>841 俺に言うなよ。俺はCOMは使われてるとしか言ってない。
シェル（エクスプローラー）をCOMで操作できるという
基本的な機能の互換性をなくすとか考えられん。
>>840 環境変数は昔から標準化されてるだろ。設定は微妙だけどデファクト標準関数があるし。
>>844 std::cout << なんとか("PATH");
のように一行でやる方法教えて
もちろん脆弱性などで非推奨と言われるようなやり方は禁止
俺はここまでできて「使える道具」だと思ってるよ
>>843 だからCOMの話にその先であるエクスプローラの話を混ぜるなよ…
ところでExplorerってCOMで操作できたっけ？
Internet Explorerの話じゃないよね？
OpenStack, Terraform でも、クレデンシャルなどの環境変数は、1つのファイルにまとめる
>>847 実現可能な最小の行数
（一行でできるようにすることは他の言語で実現されてることからも明らか）
ちなみにさっきオレオレで20行ぐらいの関数を書いて
>>853 俺が思ってるかどうかじゃなくて、
お前が、こういう理由で短いのがいい or だめと
"お前の意見" を書け
ん？反対意見があるんじゃないのか？
この手のバカでもたった20行で作れるんだろ
>>845 だったらはじめから「僕はこうじゃなきゃヤなんだー」って言ってくれないと何も伝わらないぞ
はじめから言ってる
> 車輪の再発明
std::filesystemができたように、
>>860 はあ？845が初出じゃん
getenvでいいだろ。
未定義時のエラー処理まで自動でやってほしいのか？
> 何がそんなに気に触ったんだろう？
>>864 そんな下らないことで（笑）
一行とかそんなの重要なところじゃなく、
stdの名の元でまともなライブラリを作ってくれって話だよ
仮にも「標準」ライブラリなんだからさ
昔ながらのgetenvやその安全版はstd:stringが使われてないし、
std::getenvも、なぜかstd::stringではなくchar*が使われていて
使うとエラーとされるレベルの非推奨関数だし、当然ワイド文字版もないし
使おうと思った人なら、まともじゃないの意味ぐらいわかるはず
あ、使ったことない人が噛み付いてきたのかｗ
あと環境変数の未定義は正常な状態としてありえるのでエラーではない
細かくてすまんなｗ 適当な発言は気になるんだよ。
>>865 噛み付いてばかりじゃなくて、"自分の意見"を言うだけの
知識はあるのかい？
c++の標準ライブラリにプラットフォーム抽象の機能求めるってのは筋が悪いんだよ
>>856 > お前がなにか思ってるだけかよｗ
うん、バカな縛りだなと思ってるw
組み込み系なんてenvどころかfilesystemとかそもそもねぇの普通な環境も多いしね
ここは毎回しょうもないことで荒れるな
まあもともと広いレンジで使われることを目的とした言語だし
ないなら作りゃいいのに
せっかく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++のコンパイラってどのくらい種類あんの
>>833 >>883 とｵﾓﾀがちょっち訂正しておき鯛、
publicなメンバ関数だけでprivateを一切含まずに事を済ますクラス定義を広義のpimplとみなすなら
ライブラリの公開インターフェースとしてpimpl最高じゃな
ハンドルだけだとユーザーが間違った呼び出しをしかねない
これをpimpl式にクラスでwrapするのはｽｹﾞｰ有効
つーかハンドルで渡して使う時にキャストするって面倒だからさ
記述の煩雑さはもう諦めるけどインラインPimplでゼロオーバーヘッドにしてほしい
煩雑さを許容できるならやれるでしょ
オーバーヘッドを気にしている人の大半は、気にする必要のあるものを作っていない
実装をpimplに押し込めて公開インターフェース上の変数メンバの増減を無くすのが肝なんだから
そもそもprivateな関数宣言をpublicなヘッダに
>>896 こういうの
https://ideone.com/EB36N2 pointerじゃないからpimplではない
まあ欠陥って言われても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
>>900 言うてもplacement newしたオブジェクトに移譲してるだけだからたいしたことやってない
まぁこれが規格的にセーフかどうかは知らんけどな
>>911 > uint8_t impl[32];
固定サイズで確保してる時点であり得んわ
そこはどうにもならんな
>>913 > 他にいい方法あるなら知りたい
ないからpimplとかなんだろ
だからと言ってテキトーに領域定義とかあり得んだろ
そもそもポインタ参照ごときのオーバーヘッドをも許さないほどリアルタイム性を要求するもの作ってんの？
>>914 適当がいやなら同じサイズにすりゃいいじゃん
static_asserの条件を==にすればいい
手間はかかるが、それが許容できる前提の案ね
>>916 バカなの？
ちょっとサイズ変更されたら使えない
かと言ってどんだけ余裕持てばいいかは未来予知能力でもないと無理
要するに常人には使いどころがないってことな
>>915 C++の用途として可能な限りオーバーヘッドをゼロとすることが要求されるケースがあるのは当然の話であるが、別に議論に参加するものがそういう物を作っている必要性はないだろうに、何でこだわってるんだ？
>>917 だから手間がかかると言ってるわけ
やる気になれば自動化できるスクリプトは作れるだろうけどね
バカと思うかもしれないけどreserveフィールドでバイナリ互換を保つってのは実際やるんだよ
未来を予測できないのはそのとおり
適当に決める
まぁお前の知らない世界の話だから気にするな
外部からはデストラクタもコピーコンストラクタも動かせないのにあえてインラインにする
placement new を使った
>>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を隠すための努力なんてしなくていいよね
何をもって思想から外れていると？
始まりはそうだったかも知れんが、現在の規格の設計思想は明らかに違う
最速を目指すって言うと少し外れてるけど、速度を重視するという所は変わってない
それ以上に集団での開発効率を重視したもの
>>898 のような奇怪なものよりpImplの方がモダンC++の設計思想に合っているのは間違いない
>>950 明らかに～
説明できないときにつかう常套句だよね
少なくともc++17まではその設計ポリシーが挙げられてるよ
>>952 はぁ？
pimplのどこがモダンなの？
最低限delegateを手で書かなくてもいいようにしてから言ってくれよ
スマートポインタ以下だから
設計の方針は曖昧なものではなく明文化されてるから調べてきてね
ハリソン・フォード主演映画「逃亡者」(1993年)の主人公の名前は、キンブルだったね。
pimpl使ったことないからスルーしてたけど
>>947 =
>>949 ゼロオーバーヘッドの原則は言語が掲げるもので言語利用者を縛るものじゃねーよ
実際それが便利でコストが問題にならない使い方ならどう使ってもいいだろ
>>954 君もなんか勘違いしてない？
最速を目指すなんて厨二病みたいなことを挙げていたというソースは？
>>959 > ゼロオーバーヘッドの原則は言語が掲げるもので言語利用者を縛るものじゃねーよ
そうだよ、だからこの手の機能は言語仕様には含まれないってことな
> 実際それが便利でコストが問題にならない使い方ならどう使ってもいいだろ
誰もお前に使うななんて言ってないから使いたいなら勝手に使ってろよw
質問です。
>>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[ ];
std::stringはstd::string::c_strメソッドを使ってアクセスするとヌル終端になることが保証されている。
char hoge[] は char の配列
あと片山の答えは
>>978 の回答になっていない無関係な話 (いつものことだが)
今やc_strでなくてもnull終端は保証されてるしな
char str="";で多分null終端される。
>>978 です
すみません 文字列として扱い、いきなりその変数を文字列と文字列の連携で使う場合の話です
つまり、その場合でも std::stringで宣言する場合は、"\0"で初期化する必要は無しということですね？
すまん書き直し。
>>985 説明が上手くないからもうコードで書きなよ
ひょっとするとstd::string str[]じゃなくてstd::string strの間違いじゃないの？
日本語の説明よりコード片の方が多少間違っていても意図を理解できるという
char[]は文字の配列＝一つの文字列でstring[]は文字列の配列だからそもそも比較するのが間違ってる
>>978 の char str[ ]; string str[ ]; は、どっちも
要素数不明の配列の定義でコンパイルエラーになるんと違うか?
宣言ってことは extern のつもりなんじゃろか。
>>988 の言う通り string str[ ]; は string str; かも知れんけど、
いずにせよ「質問が曖昧で答えようがない」の類かと。
アスペ多すぎ
>>992 本気でstring str[];だと思ってる可能性を否定しきれない
現実にその手の奴はいるし
>>978 です
明らかに自分が悪いです
char str[ ];
と宣言した場合、str[0] = '\0';というNULL終端をしなければなりませんが
std::string str;
と宣言した場合は、特にNULL終端の必要性っていうのはないのでしょうか？
に修正です
無い
初心者ぽいから説明が悪かったかもしれん
stringに対するstring_viewみたいにint配列等にたいするviewはありますか？
'\0' と 0 とどっち使うのが良い？
このスレッドは１０００を超えました。
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
───────────────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
───────────────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
https://premium.5ch.net/ ▼ 浪人ログインはこちら ▼
https://login.5ch.net/login.php
このスレへの固定リンク： http://5chb.net/r/tech/1568362404/ ヒント： 5chスレのurlに http ://xxxx.5chb .net/xxxx のようにb を入れるだけでここでスレ保存、閲覧できます。 TOPへ TOPへ
全掲示板一覧 この掲示板へ 人気スレ |
Youtube 動画
>50
>100
>200
>300
>500
>1000枚
新着画像 ↓「C++相談室 part145 ->画像>2枚 」 を見た人も見ています：・C++相談室 part126 C++相談室 part151 C++相談室 part164 C++相談室 part152 C++相談室 part156 C++相談室 part155 C++相談室 part158 C++相談室 part157 C++相談室 part149 C++相談室 part153 C++相談室 part148 C++相談室 part165 C++相談室 part154 C++相談室 part143 C++相談室 part161 C++相談室 part163 C++相談室 part159 C++相談室 part166 C++相談室 part150 C++相談室 part124 C++相談室 part134 C++相談室 part135 C++相談室 part133 C++相談室 part144 C++相談室 part142 C++相談室 part117 C++相談室 part132 C++相談室 part137 C++相談室 part136 C++相談室 part131 C++相談室 part146 C++相談室 part130 C++相談室 part140 C++相談室 part141 C++相談室 part137 C++相談室 part138 C++Builder相談室 Part21 0からの、超初心者C++相談室 Cygwin + MinGW + GCC 相談室 Part 8 Cygwin + MinGW + GCC 相談室 Part 3 【初心者歓迎】デジタル一眼質問・購入相談室 170+ 【初心者歓迎】デジタル一眼質問・購入相談室 169+ 【初心者歓迎】デジタル一眼質問・購入相談室 166+ 【初心者歓迎】デジタル一眼質問・購入相談室 168+ C♯相談室 Part20 Mac G5 中古買入相談室 屯田五目須のお悩み相談室 C#, C♯, C＃相談室 Part79 C#, C♯, C＃相談室 Part75 自営業 悩みごと相談室 16 MFC相談室 mfc23d.dll 自営業 悩みごと相談室 40 C#, C♯, C＃相談室 Part98 C#, C♯, C＃相談室 Part91 0からの、超初心者C#相談室 自営業 悩みごと相談室 47 C#, C♯, C＃相談室 Part94 C#, C♯, C＃相談室 Part93 C#, C♯, C＃相談室 Part97 C#, C♯, C＃相談室 Part96 C#, C♯, C＃相談室 Part91 自営業 悩みごと相談室 52 C#, C♯, C＃相談室 Part95
19:01:06 up 62 days, 19:59, 0 users, load average: 9.81, 9.22, 9.40
in 0.18551802635193 sec
@0.18551802635193@0b7 on 061908
