19/10/27 15:56:22.52 M7FyKfzv.net
>>617
そのとおりだが？
//class A{};
namespace N
{
class B{
friend class A;
int i;
};
class A{
A(){b.i = 0;}
B b;
};
};
friend宣言が識別子を導入したり
関係ないはずのグローバルに干渉するなど
vcはfriendにクセがある
625:デフォルトの名無しさん
19/10/27 16:07:13.81 6193c9It.net
規格的にはどうなるのが正しいの？
むしろ、もとの話がどうしたいのかに依る気がしないでもない
626:デフォルトの名無しさん
19/10/27 16:13:20.11 rrcAfXPk.net
>>620
規格の話は>>608じゃねーの？
コンパイルできるようにするにはg++にするかVisual Studioなら>>619みたいにするってことでしょ
それ以外なら環境を提示してねってことかと
627:デフォルトの名無しさん
19/10/27 16:22:22.30 itfBjV2c.net
>Visual Studioなら>>619みたいにするってことでしょ
URLﾘﾝｸ(festy.jp)
>>604の
>・最初のクラスAを別の名前にする
と何が違うんだそれ
628:デフォルトの名無しさん
19/10/27 16:55:17.47 rrcAfXPk.net
>>622
一緒だよ
だからそれができないならg++（とか他のちゃんと規格準拠して処理系）にしろって書いてあるだ
まあVisual Studioが規格準拠するのを待つとかMSにねじ込むか金払って対応してもらうとかでもいいけどw
629:デフォルトの名無しさん
19/10/27 20:50:09.77 5FCyBaq0.net
トンチンカンな質問かもしれませんが許して。
<Base>のコンテナを巡回しながら
Base派生の多態性を引数で実現、みたいなことがやりたいのです。
URLﾘﾝｸ(ideone.com)
これのManager::update()が、このままだと当然
func(shared_ptr<Base>,shared_ptr<Base>)を呼ぼうとしてしまう訳ですが
宣言してあるfunc（A,A）とかfunc（A,B）とかfunc（B,B）とかが
呼ばれるようにするにはどうしたらいいですかね？
あるいは、ガラっとコード変わってもだいたい似たようなことを実現するとしたら
どう書きますか？
630:デフォルトの名無しさん
19/10/27 20:52:12.38 oi2VB0wA.net
シェアポの配列を作って添え字で切り替え。
631:デフォルトの名無しさん
19/10/27 20:54:15.22 oi2VB0wA.net
あ、すまん。誤読していた。
>>宣言してあるfunc（A,A）とかfunc（A,B）とかfunc（B,B）とか
多態やってる意味を潰しに来てないか？
632:蟻人間
19/10/27 20:54:19.69 irXhIBVc.net
>>624
funcを仮想化すれば？
633:蟻人間
19/10/27 20:59:49.33 cNZwDfUU.net
もしくはfuncでは仮想化された関数しか使わないとか。
634:デフォルトの名無しさん
19/10/27 21:09:28.45 aWGByvYb.net
>>624
visitorパターン
635:642
19/10/27 21:09:54.33 5FCyBaq0.net
>>627
func(Base,Base)だけをvirtualってこと…ですよね？
え、こういうときにもvirtualて使えるの？と思って試したけどダメですね。
>>628
もうちょっと考えてみますけどたぶん難しいです
636:624
19/10/27 21:14:40.36 5FCyBaq0.net
名前欄間違えてた…
>>629
あー…それかも
なんとなく知ってるだけで
まだ実装したことはないですが
それ正解かもしれません
調べつつやってみます
637:デフォルトの名無しさん
19/10/27 21:34:36.36 4WtkkchW.net
>>624
愚直に dynamic_cast で N*N 分岐からはじめたら？
638:デフォルトの名無しさん
19/10/27 22:12:39.30 5au4GxkL.net
2引数ならdouble dispatchとか
639:デフォルトの名無しさん
19/10/27 22:14:23.71 SYtHJPpD.net
派生クラスの種類が決まっているなら
variantに置き換えたらvisit使えるから簡単
640:デフォルトの名無しさん
19/10/28 05:15:43.29 VJWcm+Z+.net
>>624
こうゆうことやのうて？
URLﾘﾝｸ(ideone.com)
641:デフォルトの名無しさん
19/10/29 01:15:36.46 Vnr+WSpj.net
C++でCOM扱うの苦痛すぎる
何が正攻法なのかさっぱりわからん
642:蟻人間
19/10/29 01:32:18.86 CdNgVa0z.net
>>636
ATL
CComPtr
643:デフォルトの名無しさん
19/10/29 01:41:40.05 Vnr+WSpj.net
別にCOMは作るんじゃないんだよ。
参照するだけなんだよ。
それでもATLなんーーーーーーーーー？
644:デフォルトの名無しさん
19/10/29 01:43:16.61 Vnr+WSpj.net
そもそも文字コードどうなってるんやーーーー
コマンドプロンプトに出す時、どうするんやーー
現在のchcpの設定に従って変換線といかんのカーーーーーー
645:蟻人間
19/10/29 02:28:13.51 OOQqvLIR.net
変換なんてWideCharToMultiByte使って一つ変換関数作ってその関数を使い回せばいいやん。
646:デフォルトの名無しさん
19/10/29 02:42:32.11 /DWax9vx.net
WriteConsoleW
647:デフォルトの名無しさん
19/10/29 04:01:15.69 ymnLB/52.net
>>640
Unicode文字列（絵文字とか）が文字化けするんだよー！
フォントの問題でないことは確認済み
648:デフォルトの名無しさん
19/10/29 04:07:41.50 ymnLB/52.net
例えばググって見つけた、こことか
URLﾘﾝｸ(www.t-net.ne.jp)
wchar_t を const wchar_t にするのはまあいいとして、
日本語はOKだけど絵文字とか化けるじゃねーか
わーけわかねなんｄｆっｒね；ｊｋ
649:デフォルトの名無しさん
19/10/29 04:13:15.89 ymnLB/52.net
ん？WideCharToMultiByteってShiftJISに戻すやつじゃねーのか？
俺はUnicode文字すべてを表示したいだけだぞ
650:デフォルトの名無しさん
19/10/29 04:20:56.50 xS90z6YC.net
chcpくらい使えよ
651:デフォルトの名無しさん
19/10/29 04:26:03.90 /DWax9vx.net
windowsのコマンドプロンプトはまだ絵文字とかに対応してないよ
652:デフォルトの名無しさん
19/10/29 04:29:31.79 YQKoC2Uo.net
>>646
全てではないだろうけど対応してる。
❥
↑文字化けしそうだけど、横向きのハートとか
❤ とか
653:デフォルトの名無しさん
19/10/29 04:29:44.12 YQKoC2Uo.net
お、文字化けしなかったｗ
654:デフォルトの名無しさん
19/10/29 04:30:10.10 YQKoC2Uo.net
?????
Jane経由だとだめだろうな
655:デフォルトの名無しさん
19/10/29 04:31:42.98 YQKoC2Uo.net
>>645
chcp 65001にしてもムダだったぞ
656:デフォルトの名無しさん
19/10/29 04:54:41.95 pnjVF+Pb.net
コマンドプロンプトよりJaneは早く絵文字に対応しろ
657:デフォルトの名無しさん
19/10/29 05:06:04.44 xS90z6YC.net
>>650
それutf8じゃねーか
658:デフォルトの名無しさん
19/10/29 05:14:54.35 YQKoC2Uo.net
>>652
ぐぐってからいえｗｗｗ
659:デフォルトの名無しさん
19/10/29 05:19:50.17 YQKoC2Uo.net
なんでコードページ932なのに、NSimSunにすると
日本語以外もちゃんと表示できるのかわからない
660:デフォルトの名無しさん
19/10/29 05:26:40.69 xS90z6YC.net
wcharがutf8なのか？あほか？
661:デフォルトの名無しさん
19/10/29 05:36:55.26 YQKoC2Uo.net
Visual StudioのソースコードのデフォルトはBOM付きUTF8なんだな
662:デフォルトの名無しさん
19/10/29 06:38:53.94 d5obkYRE.net
Windows依存の話は、以下すれでどうぞ。
Win32API質問箱 Build125
ｽﾚﾘﾝｸ(tech板)
663:デフォルトの名無しさん
19/10/29 12:08:17.89 HlsBbRfa.net
自分の理解と違ってたので教えてください。
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でも同様の結果でした。
664:はちみつ餃子
19/10/29 12:09:55.91 0JV7MfqT.net
>>658
RVO でググって
665:デフォルトの名無しさん
19/10/29 12:10:21.23 gvGgQxyJ.net
最適化で消された
666:デフォルトの名無しさん
19/10/29 12:14:30.49 HlsBbRfa.net
>>659
まさにピンポイントでした。
ありがとうございます。
667:デフォルトの名無しさん
19/10/29 13:58:53.43 cpD/FVFn.net
>>636
node.js
668:はちみつ餃子
19/10/29 13:59:57.20 0JV7MfqT.net
>>636
マイクロソフトのコンパイラならまあまあ補助があったりするでしょ。
それでも面倒くさいことにかわりないけど。
669:デフォルトの名無しさん
19/10/29 15:55:18.54 VnX4qZP9.net
失礼します。テストです：
ハート：❤
横向きハート：❥
670:はちみつ餃子
19/10/29 16:08:16.15 0JV7MfqT.net
>>664
失礼な奴だな！
671:デフォルトの名無しさん
19/10/29 18:43:54.18 NclFvQSb.net
>>663
補助なんてあったっけ？
まあ俺の知識はもう5年以上前の知識だから最近はちょっとはマシになったのかな
672:デフォルトの名無しさん
19/10/29 21:55:11.67 daQRKG1l.net
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が入ってるんだけど、
これは、どのハードウェアでもこうなると仕様と決まってるの？
673:デフォルトの名無しさん
19/10/29 22:07:48.92 VnX4qZP9.net
>>667
決まってない。
範囲外のアクセスなので、本来は絶対にやってはいけない。
読むだけでも不法例外が起きてしまう可能性もあるが、
書くのはもっとダメ。
たまたま、コンパイラシステムが何らかの目的で使っている
グローバル変数が arr 配列の直前にい配置されていて、
それが0になっているか、padding領域がたまたまそこにある
だけだと考えられる。
674:デフォルトの名無しさん
19/10/29 23:33:23.00 B0gwdLKJ.net
.bssは0初期化されてる
675:デフォルトの名無しさん
19/10/30 04:47:43 oMdYt0Tq.net
オブジェクトがスタックに作られてるかヒープに作られてるかってどうやって調べるの
具体的にはboostのmulti_arrayがどっちに作られてるか知りたい
676:デフォルトの名無しさん
19/10/30 06:54:34.02 2wpdugOW.net
>>668
そりゃそうか。０で埋まってりゃコードが少し短くなって助かるんだが、まあやめとこう。
677:デフォルトの名無しさん
19/10/30 07:31:59.85 yREk150+.net
>>670
アドレスでわかる
正しくはリンカからロケーションを取得だが
簡易的には自動変数のアドレスと上の方の桁が同じかどうかでも見当はつく
678:デフォルトの名無しさん
19/10/30 09:19:14.69 C/RG5q83.net
>>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のそれぞれはまとまった
領域のアドレスを使っているので、推定ではなく断定できる。
679:デフォルトの名無しさん
19/10/30 09:33:17.69 scNMtFri.net
どう考えてもヒープだろ
680:デフォルトの名無しさん
19/10/30 09:45:24.54 vMK+Q7lg.net
>>670
ローカルスコープだけがスタック。
newしたものはヒープ。
681:デフォルトの名無しさん
19/10/30 11:38:54.67 M6J6raPE.net
コンテナの場合はスタックに置いたつもりでも、コンテナがデータ部分を内部でnewするとかそういう話だろ
682:はちみつ餃子
19/10/30 12:07:14.45 qu4eF7c5.net
>>667-668
仕様上は配列の範囲外を指すポインタを作るのさえも未定義。
たとえアクセスしなくても。
なので、 ptr-1 という式の時点で未定義動作になる。
ただし、アクセスしないなら配列の最後の要素より一個うしろを指すポインタを作るのは許される。
つまりこの例で言えば ptr+2 や &ptr[2] は有りだけど ptr[2] は駄目。
&ptr[2] は ptr[2] に対して & を付けているので一見すると途中で ptr[2] を評価しているように見えるけど、
・ ptr[2] は (*(ptr+2)) の構文糖である
・ * の結果に & を適用している場合には * も & も評価されず、両方とも取り除いたのと同じことになる
というルールの合わせ技によって &ptr[2] は ptr+2 と同じ意味になる。
ちなみに、配列ではないオブジェクトは要素が一個の配列と同じレイアウトを持つことは保証される。
683:デフォルトの名無しさん
19/10/30 12:14:10.66 pPHw66rS.net
>>677
&*p を p とみなす特別ルールは C の規格にあるけど C++ には無かったりする。
もう１０年以上審議中。 URLﾘﾝｸ(wg21.cmeerw.net)
684:デフォルトの名無しさん
19/10/30 12:21:16.92 C/RG5q83.net
>>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)
の式が常に厳密に成り立つことが保証される。
685:デフォルトの名無しさん
19/10/30 12:25:41.94 C/RG5q83.net
>>678
operator&(), operator*() をユーザーが定義した場合には、それに従うが、
定義しなかった場合、&*pX == pX が どんなポインタ pX についても
成り立つことは保証されるはず。
686:デフォルトの名無しさん
19/10/30 13:28:14.72 JDSjHFuf.net
>>670
一般的なPC環境なら、
適当に用意した別の関数を呼び出して(multi_arrayのインスタンスがまだ有効で、インスタンス生成したスレッドと同一スレッドからなら、どこから呼び出してもよい)、
その関数のローカル変数のアドレスよりも&multi_array[0]の値のほうが大きければ、multi_arrayのデータ領域はスタックに確保されたと判断できるのでは
687:デフォルトの名無しさん
19/10/30 13:38:23.28 C/RG5q83.net
>>681
自分も最初、同じような勘違いをしていたが、
シングルスレッドの場合に限定すれば、
スタックの構造からすれば、最初に確保したローカル変数のアドレスが、
そのごろのローカル変数のアドレスよりも必ず大きい。
そして、ヒープから確保したオブジェクトのアドレスは、必ずそれらよりも大きい。
なので、後から別の関数を呼び出す必要はない。
main()関数の中で最初に定義したローカル変数のアドレスが分かればそれで十分。
688:デフォルトの名無しさん
19/10/30 13:39:27.23 C/RG5q83.net
>>682
誤：そのごろのローカル変数のアドレスよりも必ず大きい。
正：その後のローカル変数のアドレスよりも必ず大きい。
早い話が、スタックは、上下逆になっていることが味噌。
689:デフォルトの名無しさん
19/10/30 16:43:27.90 iACLsVPd.net
0 埋め勝手に期待してると
Debug build と Release build の変化ではまるんじゃね
690:デフォルトの名無しさん
19/10/30 18:21:24.13 sLIKMMS8.net
未定義動作に頼って幸せになった人間はいない
691:デフォルトの名無しさん
19/10/30 18:25:45.90 PFJwOjFS.net
問題は未定義動作が多すぎることだ
692:デフォルトの名無しさん
19/10/30 19:14:52.52 NnKRxbK9.net
>>682
> そして、ヒープから確保したオブジェクトのアドレスは、必ずそれらよりも大きい。
スタックエリアとヒープエリアの前後関係なんて決まってたっけ？
693:デフォルトの名無しさん
19/10/30 19:53:22.92 /8g3afGg.net
c++なら暗黙に0で初期化するところでcだと死ぬ
694:はちみつ餃子
19/10/30 20:10:37.29 qu4eF7c5.net
Boehm GC にスタック・ヒープの範囲を判定する部分があったはず。
695:デフォルトの名無しさん
19/10/30 20:42:33.17 MNbPntdA.net
>>682
ヒープから確保したアドレスがスタックより大きいっていうのはかなり特殊な環境では？
696:デフォルトの名無しさん
19/10/30 20:46:40.08 7FaQcqiv.net
>>682
スタックとヒープのアドレスに前後関係の縛りなんかねえよ
互いに全く別個のデータ構造で相互に依存関係はない
697:デフォルトの名無しさん
19/10/30 21:02:17.94 xN/ut28D.net
お前ら甘いぞ
ヒープから確保したメモリをスタックにすることもできるんやで
逆にいうとスタックの情報もとれる
pthread_attr_getstackな
698:デフォルトの名無しさん
19/10/30 21:28:56.04 KWwo/1iW.net
URLﾘﾝｸ(ideone.com)
デストラクタを後から書き換えるってできなかったっけ？
699:デフォルトの名無しさん
19/10/30 21:37:47.50 scNMtFri.net
なんで出来ると思ったのか
700:デフォルトの名無しさん
19/10/30 21:41:50.59 /8g3afGg.net
おまえらはなんですぐ破壊的なメモリアクセスしようとするんだよ。
701:デフォルトの名無しさん
19/10/30 21:44:55.49 KWwo/1iW.net
>>694
なんでだろ・・・。
できなそうだな。さんきゅー。
702:デフォルトの名無しさん
19/10/30 21:47:25.90 M6J6raPE.net
変にトリッキーなことをせず普通に書けば平和なのに
703:デフォルトの名無しさん
19/10/30 21:51:21.63 Z1e8Gfkt.net
平和を求めるならc++使わないことだな
704:デフォルトの名無しさん
19/10/30 21:56:38.45 Z1e8Gfkt.net
>>696
virtualでないと子のデストラクタは呼ばれないってのとごっちゃになってるとか？
705:デフォルトの名無しさん
19/10/30 21:57:32.16 /8g3afGg.net
>>698
平和は求めるが性能も求めるから仕方なく使うのがc++だよ、馬鹿。
706:デフォルトの名無しさん
19/10/30 22:07:52.76 KWwo/1iW.net
>>699
多分それだ。もやもや取れたわ。ありがとう。
707:デフォルトの名無しさん
19/10/30 22:15:48.21 Z1e8Gfkt.net
>>700
お前moveだからコピーコストゼロ！カロリーゼロとか言ってるだろ
708:デフォルトの名無しさん
19/10/30 22:18:45.46 T2yRPHdv.net
>>693
正直何をしたいのかさっぱりわからん
709:デフォルトの名無しさん
19/10/31 00:30:04 Mfb82uAb.net
>>687
なるほど、想定していたのは、Windows環境限定だった。
710:デフォルトの名無しさん
19/10/31 01:11:19 Z73hoFPo.net
>>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 と一致するような場合を除いて、動作は未定義になると明記されてる。
URLﾘﾝｸ(timsong-cpp.github.io)
たぶん C の規格にも無かったと思うんだけど、「Cの仕様書」って何のこと言ってるの？
>>680 も、規格で保証されると言ってるなら誤り。
特定の実装（特に C もサポートしてる実装）では保証されているとか、
保証されてないと困るという話ならそうなんだろうとは思うけど。
711:デフォルトの名無しさん
19/10/31 07:54:20 CWgnmwch.net
保証は知らんけどアドレス計算だから1じゃなくてsizeofの値じゃないのそれ
あとだめならベクタで&v[x]みたいのも未定義になっちゃうけども
712:はちみつ餃子
19/10/31 12:29:41.78 /W+zTx1p.net
>>705
俺も仕様としての保証はないと思う。
C の規格を見て関連しそうな項目として
- ポインタを型変換して変換後のアライン (処理系定義) が正しければそれを元の型に再変換したものは変換前と等しい
- ポインタを別のポインタに型変換した後のアラインが正しくなければ未定義
- ポインタを文字を指すポインタに型変換した場合、オブジェクトの最も低位のアドレスを指す
- 文字を指すポインタに変換されたポインタは元のオブジェクトの大きさまで連続して増分すると
そのオブジェクトの残りのバイトへのポインタを順次生成できる
(注：ここで言うポインタには関数ポインタを含まない)
という保証は見つけられたので
(((BYTE *)arr) + sizeof(TYPE) * k)
までは妥当な式と言えると思うんだけど、 (TYPE *) というキャストが出来る根拠は見つけられなかった。
713:デフォルトの名無しさん
19/10/31 13:00:56.65 Mfb82uAb.net
>>707
C言語の基礎として、TYPE *ptr に対し、
ptr + k == (TYPE *)(((BYTE *)ptr) + sizeof(TYPE) * k)
は保証されているはず。
714:デフォルトの名無しさん
19/10/31 13:06:36.29 iFqs222y.net
×基礎
○妄想の中の理想世界・ご都合ワールド
715:デフォルトの名無しさん
19/10/31 13:21:36.49 Mfb82uAb.net
URLﾘﾝｸ(en.cppreference.com)
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.
URLﾘﾝｸ(en.cppreference.com)
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)
716:デフォルトの名無しさん
19/10/31 13:43:36.78 hGg8JwcT.net
C++のヘッダファイルのクラス定義って、
privateまで定義しないといかんのが嫌だな。
privateだから内部に隠蔽されて、外部からは知らなくていい情報なのに
内部で使ってる型をヘッダファイルに書かなければいけないから、
それをincludeしてる方も、その型の存在を知ってしまう。
どうにかならんのかな？
717:デフォルトの名無しさん
19/10/31 13:54:48.05 Nmr38VJU.net
ヘッダに描くのをやめればいい
718:デフォルトの名無しさん
19/10/31 14:01:21.28 Mfb82uAb.net
>>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 は正しい。
719:デフォルトの名無しさん
19/10/31 14:04:09.17 /uM4xbrd.net
>>711
pimpl
720:デフォルトの名無しさん
19/10/31 14:46:45.02 Mfb82uAb.net
>>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)
に一致する。」
となります。
721:デフォルトの名無しさん
19/10/31 14:50:36.73 Mfb82uAb.net
>>691
言語仕様的には決まっていませんが、Win32で実験する場合、
最初の質問者が、答えを見つける手段としては、正しいやり方なのです。
Win32で実験してヒープからの確保なのかどうか判明してしまえば、同じ
boostのソースを他の環境で動かしても、#ifdef などで動作が変えられていない
限りは、同じ結果となるからです。
722:はちみつ餃子
19/10/31 14:53:56.72 /W+zTx1p.net
>>713
アドレスがどうこうじゃなくてキャストが許されるかっていう話なんだけど。
723:デフォルトの名無しさん
19/10/31 15:27:23.28 CWgnmwch.net
ポインタのキャストてポインタが指してるアドレスのデータの解釈だけの問題だから許されないキャストがそもそもないのでは
適切かどうかは知ったことではないが
というか配列のデータが連続していれば当然のごとく成り立つ話じゃん
それは保証されてるわけだし
724:デフォルトの名無しさん
19/10/31 16:06:33.06 hGg8JwcT.net
>>714
サンクス。集約を使えば行けるんかいなーとか雑に思っていたが、
そういうイディオムがあるんだな！
725:デフォルトの名無しさん
19/10/31 16:29:14.27 Mfb82uAb.net
>>718
構造体型へのポインタ同士については、単なる解釈し直しではなく、
アドレスの加減算を伴うことがあります。
しかし、BYTE型へのポインタから構造体型へのポインタへのキャストに
ついては、解釈のし直ししか、コンパイルのしようがなく、その場合に
ついては、ポインタの指すオブジェクトがマシン後レベルで同じアドレス
を持つことになります。ただし、厳密な仕様は知りません。
726:はちみつ餃子
19/10/31 16:32:02.98 /W+zTx1p.net
pimpl ってプライベートなメンバを隠したいだけのために導入するのは面倒くさ過ぎない？
手間かけてでもやりたいって場面もあるのかもしれんが、どうにも割に合う気がしない。
727:デフォルトの名無しさん
19/10/31 17:07:47.69 NdDnFbFX.net
どうしても実装を隠さないと発狂する人が使う
728:デフォルトの名無しさん
19/10/31 17:11:39.47 M7zdaumA.net
unique_ptrで作ればそれだけで勝手にmovableなクラスになって便利だよpimpl
729:デフォルトの名無しさん
19/10/31 17:17:39.90 hGg8JwcT.net
>>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を隠したかったんだよ！
↑
言いたかったことはこれ
730:デフォルトの名無しさん
19/10/31 17:29:24.06 Mfb82uAb.net
>>724
また髪の毛の話してる、などというと荒れそうなので決して言いません。
731:はちみつ餃子
19/10/31 17:52:49.82 /W+zTx1p.net
C++20 でモジュールの機能が入るとかいう話になってるから
それが成れば pimpl なんていらんようになると思うんだが、
実際のところモジュールの様子ってどうなの？ちゃんと入りそう？
732:デフォルトの名無しさん
19/10/31 18:23:02.02 ZttcTVl1.net
無理。
テンプレートとの両立、オーバーヘッドの問題
どの視点でみてもくそなものしかできないことは明白。
こういうのに引っかかるバカが増えたよね。
733:デフォルトの名無しさん
19/10/31 18:32:01.00 gpc+5FVL.net
>>721
そう思うのは複数人で規模のでかいもの作ってないから
734:デフォルトの名無しさん
19/10/31 19:37:56.00 /uM4xbrd.net
pimplは開発規模は関係なくて、ライブラリの公開するヘッダでユーザーに関係ないものを隠すために使わないか？
735:はちみつ餃子
19/10/31 20:03:49.64 /W+zTx1p.net
>>729
それも pimpl の目的としてはあるんだけど、 >>724 が書いているように C++ だとファイルの依存関係が必要以上になることもある。
それをどうにかしたら make で差分ビルドしたときに走るタスクが少なくなるので
規模が大きいプログラムで pimpl を使うとビルドがだいぶん速くなるということはありうる。
規模が小さいと体感するほどの差が出ない。 割に合わない。
そういう意味では規模は関係ある。
736:デフォルトの名無しさん
19/10/31 20:09:29.87 jES25g+p.net
個人的には、自分ひとりで作ってるプログラムは、高頻度で全ビルドに
かける癖が付いてしまってる。
こうしておくと、OSをSleepモードにしていて、誤って電源を切ってしまったような
時にIDEが管理しているプロジェクトのデータファイルの何かが壊れていても
気付なかった時や、プロジェクトのバックアップ処理の時のコピー操作の何らか
の間違いで何かがおかしくなってしまったようなときに変な不具合に悩まされなく
て済む。
737:デフォルトの名無しさん
19/10/31 22:29:01.40 GkSnEle2.net
C++とオブジェクト指向をきちんと身につけてる人ばかりの環境ならいいんだけどね、pimpl
経験不足な人だと理解出来なさそう
738:デフォルトの名無しさん
19/10/31 22:54:10.87 /p/NkBNt.net
使ってるうちにインターフェースを使った典型的な奴とそう変わらない事に気付く
739:デフォルトの名無しさん
19/10/31 22:58:21.62 KjvgkRuG.net
継承使いたくないからpimplの方が好き
740:デフォルトの名無しさん
19/10/31 23:14:49.56 FGj4X+XO.net
cpprefjpのサンプルの赤字の部分使い方合ってる？
URLﾘﾝｸ(cpprefjp.github.io)
741:デフォルトの名無しさん
19/10/31 23:43:47.06 /p/NkBNt.net
確かに、select_on_container_copy_construction(other.alloc_)が正しいような気はする
742:デフォルトの名無しさん
19/11/01 00:03:47.15 8rUFWNXZ.net
テンプレート活用のための最適化が全盛期の今 pimpl は時代遅れ。
743:デフォルトの名無しさん
19/11/01 00:09:16.78 rKg4WNgJ.net
はいはい
744:デフォルトの名無しさん
19/11/01 00:19:47.84 TUcr0tQH.net
pimplが時代遅れというのなら、それに代わる
依存する必要がない所を断ち切る方法を提示してくれ
745:デフォルトの名無しさん
19/11/01 00:24:57.04 8rUFWNXZ.net
>>739
クラスの前方宣言。
テンプレートによるコンパイルエラー回避。
746:デフォルトの名無しさん
19/11/01 01:06:00.24 pNQbmHLO.net
>>739
インターフェースと継承
747:デフォルトの名無しさん
19/11/01 03:35:55 TUcr0tQH.net
>>740-741
どちらも型を書くので依存を断ち切れてない
748:デフォルトの名無しさん
19/11/01 05:46:43 xzGeRMKo.net
pimplでも型を書くのに、何を言っているんだか
そんなに型を書くのが嫌なら、Cの不透明型でも使ってろ
749:デフォルトの名無しさん
19/11/01 06:27:26.52 62eq0k7o.net
pimplの目的も方法も全く理解してないって白状したぞこいつ
750:デフォルトの名無しさん
19/11/01 06:54:21 vkO9vKkI.net
>>739
目の前のパソコンを窓から投げ捨てます
751:デフォルトの名無しさん
19/11/01 07:17:25.47 luUnrp0t.net
privateをどうしても隠蔽したいならpimpl使うのもやむを得ないのかも知らんけど、そんな事態になったこと無いからよくわからんな
752:デフォルトの名無しさん
19/11/01 07:43:37.38 62eq0k7o.net
ライブラリ作る時にstd::unordered_mapとかメンバに使いたいと思わないもんなのか、よくわからんな
pimplで.cppに閉じ込めないとコンパイラやSTLのバージョン違いで壊れるんだけど
753:デフォルトの名無しさん
19/11/01 07:44:21.36 nMXewbQV.net
>>739
自部屋に引き籠もって外界との依存を断ち切ります。
754:デフォルトの名無しさん
19/11/01 07:58:26 OvwU0XDV.net
ライセンスに書いとけば良い
・プライベートは見ないで下さい。お触り禁止。
755:デフォルトの名無しさん
19/11/01 08:11:36 s5avmMq4.net
ただ単に仕様と実装をすっきり分離できるというだけでも充分な動機になる
756:デフォルトの名無しさん
19/11/01 08:20:42 luUnrp0t.net
>>747
> pimplで.cppに閉じ込めないとコンパイラやSTLのバージョン違いで壊れるんだけど
ん？どう言うこと？
なんかやり方間違えてね？
757:デフォルトの名無しさん
19/11/01 08:22:07 luUnrp0t.net
>>750
private部分を見なきゃいいだけだろw
そもそも実装は.cppに書くんだし
758:デフォルトの名無しさん
19/11/01 08:25:35 StFJ+6Yp.net
エディタが貧弱だったころの名残を未だに引き摺っている
仕様と実装を分離したらそれだけでファイルが倍に増えて管理が面倒になる
仕様はソースコードから逐次自動生成すればいい
なので昨今の言語はIDEに迎合していて、暗黙の大前提でIDEでの運用が見込まれている
それ単体で成り立つものでは無くなっている
759:デフォルトの名無しさん
19/11/01 09:01:23 DyENPU43.net
因果関係を理解できない人ってプログラマ向いてない
760:デフォルトの名無しさん
19/11/01 09:41:29 Oq+eTBHB.net
class Util() {
public:
int aaa();
std::string bbb();
private:
MinorClass mc;
MinorClass mc zzz();
}
こういうユーティリティクラスがあって便利だなーって思ったときに、
便利だと思うのはaaaメソッドとかbbbメソッドであって
内部で使ってるMinorClassとかどうでもいいねん
Utilクラスのインクルードファイルはインクルードしたいけど
MinorClassのインクルードファイルはインクルードしたくないねん
そんなもんインクルードしたらMinorClassが変更になっただけで
Utilクラス使ってるところも変更になるやろ？
761:はちみつ餃子
19/11/01 10:06:12.42 ichmHmwx.net
>>755
そこをわからんって言ってるやついないんだよ。
わかった上で変更になったらどんくらい問題なんや？ 別にええやろ。 と言う場面の方が多いという話なんだよ。
pimpl が有用な場面があるっていう主張もわかるよ。 わかるけど、そういう場面に遭遇したことないなぁという話なんだよ。
762:デフォルトの名無しさん
19/11/01 10:29:23.31 9RAuu3bH.net
>>755
それだけならMinorClassを前方宣言するだけでincludeいらない
763:デフォルトの名無しさん
19/11/01 10:32:58.37 XsK+HhVl.net
>>757
MinorClassの実体をメンバにするなら前方宣言じゃだめ
ポインタなら前方宣言にできる
764:デフォルトの名無しさん
19/11/01 10:33:41.18 o99mOnqi.net
Utilはあるライブラリの公開クラスです
MinorClassは標準ライブラリのテンプレートクラス(例えばstd::unordered_map<Hoge>)です
Aさんはとあるコンパイラver1.0でコンパイルしたライブラリのバイナリとヘッダーを配布しました(ソースは配ってない)
10年後にBさんがこのライブラリのバイナリを入手して使おうと思いました
その間にコンパイラの標準ライブラリも劇的な進化を遂げ、コンテナの内部構造に大幅な改良を加えて超高速化したと宣伝していました
Bさんはヘッダーをincludeしてコンパイラver8.0でビルドしました
さーて何が起こる？Utilがpimplだとどうなる？よくよく考えよう
765:デフォルトの名無しさん
19/11/01 10:43:47.44 9RAuu3bH.net
>>758
そんなんかすまん
勘違いしてた
766:デフォルトの名無しさん
19/11/01 11:01:10.12 XsK+HhVl.net
privateメンバをポインタ型にする手間や不都合とpImplの手間や管理コストのどっちを取るかだろうな
基本的には継承するクラス以外のincludeは排除できる
ヘッダ内部での外部ライブラリのincludeは可能な限り避けるべき
767:はちみつ餃子
19/11/01 11:10:39.87 ichmHmwx.net
>>760
オブジェクトを生成するには「大きさの情報」が必要だと覚えておくとわかりやすいと思う。
クラスの内容がわからないと大きさが確定しないから生成できないけど、ポインタの大きさはわかる。
768:はちみつ餃子
19/11/01 11:11:24.16 ichmHmwx.net
>>759
そういう状況があることはわかるよ。
でもそんなことしねーよって話なんだってば。
769:デフォルトの名無しさん
19/11/01 13:00:57.84 aQLx28Zt.net
>>763
それお前個人がしたことないって言う経験談？
それとも他の代替手段を取るってこと？
先に言っておくと前者ならすっこんでろ
770:はちみつ餃子
19/11/01 13:23:21.41 ichmHmwx.net
>>764
俺がしたことないという経験談だが、
ここで pimpl が割に合わないと出ている意見は
そういう状況があんまりないという内容だということの説明でもある。
そういう状況で必要だってのはわかってるし、
そういう状況にあるなら使えばいいよ。
それはわかってるんだよ。
だからしつこく説明しないいよっていう話。
771:はちみつ餃子
19/11/01 13:29:29.85 ichmHmwx.net
要するに >>759 はまるで見当はずれのこと言ってんなぁという感想。
772:デフォルトの名無しさん
19/11/01 14:32:22.73 o99mOnqi.net
単機能ライブラリ作って渡す仕事してる人にとっては日常なんで、検討外れとか抜かされても勝手なこと言ってんなあとしか
まあ、OSSしかやらないとか、最終の実行バイナリしか作らないとか、そもそも個人プレーで人にプログラム成果物渡したりしないとかなら、
pimplの価値わからんという気持ちになるのはしょうがないし、それが世界の全てだと思っちゃうのかもな
773:はちみつ餃子
19/11/01 14:59:10.92 ichmHmwx.net
>>767
それが全てといってるわけじゃなくて、
pimpl がどうしても必要！ と言ってる人こそライブラリ販売の世界しか見てないという話をしてんの。
774:はちみつ餃子
19/11/01 15:01:01.21 ichmHmwx.net
いる場所ではいるし、いらない場所ではいらないという当たり前のことしか言ってないつもりなんだけど。
775:デフォルトの名無しさん
19/11/01 15:04:22.58 E92xj2lK.net
全員知らないことの方が多いのに相手が自分の分野のことを知らないと無知扱いするのは草生える
776:デフォルトの名無しさん
19/11/01 16:16:45.44 luUnrp0t.net
>>759
そもそもVer. 1.0でコンパイルしたクラスライブラリをVer. 8.0でコンパイルしたオブジェクトとリンクできるの？
10年間互換性保ってるC++コンパイラの名前教えてくれるかなw
777:デフォルトの名無しさん
19/11/01 18:28:24.75 5daK08GN.net
動的リンクなら古いコンパイラでコンパイルしたライブラリが使えるかどうかはOSの互換性次第だろ
778:デフォルトの名無しさん
19/11/01 18:36:37.94 VMz8o48U.net
>>766
一般的な現象よ
周回遅れのやつに絡まれたらキョトンとしちゃうやろ
今の餃子ちゃんがまさにそれよ
幼稚園児に絡まれたお兄さんみたいになっとる
779:デフォルトの名無しさん
19/11/01 18:38:39.54 OIX3BcSW.net
あぁ、メモリーレイアウトでずっこけるやつか。
780:デフォルトの名無しさん
19/11/01 19:03:19.99 luUnrp0t.net
>>772
マングリングって知ってるか？
そもそもC++のクラスライブラリを簡単に動的リンクできるOSってあるのか？w
781:デフォルトの名無しさん
19/11/01 19:25:46.93 4VV6x0Mu.net
まんぐりがえし
782:デフォルトの名無しさん
19/11/01 19:41:21.97 N2gtvXpa.net
comはクラスライブラリになるのかな
いろいろ面倒だけど
783:デフォルトの名無しさん
19/11/01 19:44:45.43 8Rp12Rb3.net
念のため確認だけど、pimplの代替手段については把握されてる前提でOK?
URLﾘﾝｸ(site.oukasei.com)
784:デフォルトの名無しさん
19/11/01 19:56:12.78 o5qRV/vr.net
リンク問題はABIの話だよな？
それはリンカのオプション次第じゃないのん？
785:デフォルトの名無しさん
19/11/01 20:26:50.93 luUnrp0t.net
>>779
広い意味だとABI
リンカのオプションで前のバージョンに対応してるとかの例もあるけど10年前まで対応してる例とかあるのかな？
786:デフォルトの名無しさん
19/11/01 20:51:10.72 62eq0k7o.net
>>778
結局、pimplのI/F用外側クラスを基底クラスに、implを派生クラスにするってだけでやってることはpimplと同じ
むしろ以下の点でより悪い
・I/F用のクラスと実装用のクラスに不必要な継承関係が導入されていらない複雑度が増える
・↑と同じことだが、実装用クラスがI/F用クラスと同じメンバ関数を実装することが強制される
・コンストラクタが使えず、独自のファクトリ関数の使い方を利用者に覚えさせる必要がある
・利用者に生ポが露出する。生ポを避けたい利用者は自分でunique_ptrなどで包まなければならない
・I/F用クラスを利用者が勝手実装して混入させることを許す
上に挙げたのはポリモさせたい場合はメリットでもあるんだが、ポリモを意図しない単独クラスに継承構造なんか入れるべきではない
787:デフォルトの名無しさん
19/11/01 21:03:35.70 gYA8Bkai.net
いっそのことヘッダオンリーライブラリにしようぜ
788:デフォルトの名無しさん
19/11/01 21:04:43.68 tPmTFLHa.net
>>766
検討はずれかどうかは意見が分かれるかもしれないけど、pimplには速度的な
オーバーヘッドが少しはあるのと、記述が分かりにくいような気がするので、
個人的にはまずは使うのを躊躇する。
ポインタのワンクッションを置いても速度的なオーバーヘッドが問題ない場合には、
単純なクラスへのポインタを使ってそのクラスの実装に依存しないようなコードを書く
ことはある。しかし、pimpleと言われているものよりずっと単純なもの。
pimplの定義もよく分からないので、それが全く同じものかどうかは分からない。
789:デフォルトの名無しさん
19/11/01 21:10:39.48 gbx33EDY.net
>>752
目指す理想が違いすぎるやつとは話にならん
790:デフォルトの名無しさん
19/11/01 21:13:24.24 tPmTFLHa.net
>>778
そういう風に、C++の抽象クラス（Javaではinterfaceと呼ばれるものと等価
だったはず）を使うと分かり易いですね。
791:デフォルトの名無しさん
19/11/01 21:15:27.37 N2gtvXpa.net
実装方法もいろいろでメリットデメリットもいろいろやから好きなの使えばええねん
792:デフォルトの名無しさん
19/11/01 21:18:26.92 tPmTFLHa.net
interface を使って、データメンバを隠したい場合は、new CXxxx にあたる部分を
どうやって実装するかの問題になるんですね。グローバル関数にしてしまう
方法もありますが、確か、デザインパターンの「Factoryパターン」というものが
それに該当したかもしれません。
793:デフォルトの名無しさん
19/11/01 21:34:43.52 aQLx28Zt.net
>>768
依存切りたいならpimplと言ってるところに
依存気にしてないからpimpl不要っていってるのがお前
不要ならすっこんでろって
794:デフォルトの名無しさん
19/11/01 22:03:59.28 p6e3QfJv.net
COM最強やな
795:デフォルトの名無しさん
19/11/01 22:07:08.70 tPmTFLHa.net
>>789
めちゃくちゃ使いにくい。
796:デフォルトの名無しさん
19/11/01 22:10:22.26 U/a7Wx11.net
>>784
目指す理想がpimpl?
確かに話にならんなw
797:デフォルトの名無しさん
19/11/01 22:13:09.54 U/a7Wx11.net
>>790
ただ20年間I/F変えないようにするにはあの程度の手間は必要なわけで
まあもうちょいスマートにできるんじゃないかなって思うところは多々あるけど
798:デフォルトの名無しさん
19/11/01 23:37:29.12 NpcjLENm.net
>>789-790
COMが使いづらいと言うか、C++とstdとSTLとWindows APIとCOMの流儀が
ごちゃまぜで、メモリの確保の仕方と文字列の扱いが混沌を極めてるｗ
799:デフォルトの名無しさん
19/11/01 23:41:19.87 NpcjLENm.net
.NETは（特に起動の）遅ささえなければ、ずっと簡単だよな。
C#でもなんでもさ
0.5～1秒クラスの起動速度の差が気になることやってるんで、
久々にC++使ってるけど大変すぎ
でもまあ20年ぐらい前に比べれば随分と楽になってるけど
800:デフォルトの名無しさん
19/11/02 03:47:26.33 dYVngRw/.net
>>791
> 目指す理想がpimpl?
違うけど、おまえなんかに説明してもチンパンジーに因数分解を教えるようなものだ
801:デフォルトの名無しさん
19/11/02 06:10:30.99 QFHeQDAU.net
std::filesystem はいいな。やっとまともに使えるものができたって感じ
C++17からって遅すぎだと思うが
802:デフォルトの名無しさん
19/11/02 07:36:04.48 esIitHWU.net
>>795
単に馬鹿にされてることに気づけよw
803:デフォルトの名無しさん
19/11/02 08:38:38.13 dYVngRw/.net
>>797
おまえがな
804:デフォルトの名無しさん
19/11/02 08:48:08.81 E6JKa4Vv.net
文字コード周りの混沌ぶりに比べれば、文字列クラス乱立なぞ微々たるものよ。
805:デフォルトの名無しさん
19/11/02 09:26:25.84 esIitHWU.net
>>798
まさかまだ気づいてないとか？w
806:デフォルトの名無しさん
19/11/02 09:27:02.38 s0WXD89V.net
>>776
それだ！
807:デフォルトの名無しさん
19/11/02 09:49:41.56 smHgTNTv.net
>>759
ver1.0とver8.0がライブラリの呼び出し規約レベルで違うならpimplでも静的にはリンクできないし、
ver1.0とver8.0がCRTレベルで違うならやっぱ静的にはリンクできないし、
ver1.0とver8.0がライブラリの呼び出し規約レベルで同じかつCRTレベルでも同じならpimplでなくとも静的にリンクできるし、
pimpl関係無くね？
808:デフォルトの名無しさん
19/11/02 09:57:16.61 l25LSbph.net
ライブラリだとpimplというかvoid*にして、各種操作をc関数として公開
c++ではラップしたinterfaceクラスを提供って形だろ
実装側はc++の実装クラスにstatic_castして後はc++の世界で書く
pimplは中途半端だから使わない
809:デフォルトの名無しさん
19/11/02 10:06:07.78 egbBWGD9.net
windowsのハンドルがそんなだね
中身どんぐらい変わってるんだろうか
810:デフォルトの名無しさん
19/11/02 10:06:09.13 smHgTNTv.net
void*からC++クラスのポインタ型にstatic_castってできたっけ、
811:デフォルトの名無しさん
19/11/02 10:12:48.91 l25LSbph.net
出来るよ
多態使いたかったらbase ptrとvoid*の相互変換をする
派生ptrからvoid*に直接変換すると危険
812:デフォルトの名無しさん
19/11/02 10:18:39.64 smHgTNTv.net
>>806
安全性と危険性が反対くね？
void*が指すアドレスは構造体やクラスの境界に整列している保証が無いのでは…
>>804
WIN32の内部において、ハンドルが単なるindexでなくポインタとして使われているという根拠は？
確かに正体がvoid*だったりするが、ポインタだとしたらOS視点では
INVALID_HANDLE_VALUE判定が
難しくなるのであった、（一般論として
813:デフォルトの名無しさん
19/11/02 10:20:03.47 dYVngRw/.net
>>800
だからおまえがな
814:デフォルトの名無しさん
19/11/02 10:21:28.65 dYVngRw/.net
static_cast<void*>は最派生クラスにダウンキャストだね
815:デフォルトの名無しさん
19/11/02 10:27:48.65 egbBWGD9.net
>>807
外見維持してることが重要なんであって中身でなにをどうしてようがはどうでもいいがな
816:デフォルトの名無しさん
19/11/02 10:28:34.71 smHgTNTv.net
やべービルド通るわこれ
うちのコンパイラは壊れてるな…
int g_nSomeValue;
int main()
{
int* p = &g_nSomeValue;
int* q = static_cast<int*>(p);
printf("p=0x%p\n", q);
return 0;
}
817:デフォルトの名無しさん
19/11/02 10:30:01.86 smHgTNTv.net
貼
818:りまつがえた、 誤： int* p = &g_nSomeValue; 正： void* p = &g_nSomeValue;
819:デフォルトの名無しさん
19/11/02 10:39:33.14 l25LSbph.net
void*は型情報が完全に消えるから、
型が完全に一つだとわかっているならそのままstatic_castすればいい
多態だと派生型からvoid*に直接変換してしまうと、void*から戻す場合に基底ポインタには戻せる保証がない
820:デフォルトの名無しさん
19/11/02 10:39:40.95 RcR6NuMm.net
>>802
依存している構造体のサイズやレイアウト変わったらアウトだろ
821:デフォルトの名無しさん
19/11/02 10:45:21.22 RcR6NuMm.net
>>803
C++でラップしてる時点で中途半端なのはかわらない
むしろ手間増えてる
822:デフォルトの名無しさん
19/11/02 10:46:18.05 pWYzNK5/.net
過去の遺産のCOMなんて使いにくいて横で話ししてるやろ
10年後の環境のことまで気にする必要ないんだよ
ばっさり捨ててその時代にあったものを作るべき
無理に資産転用とか互換性とか気にするからクソが生まれる
823:デフォルトの名無しさん
19/11/02 10:47:10.74 l25LSbph.net
pimplで実装隠したところで、
引数に例えばstd::string使うだけでコンパイラバージョン変えたときの保証は無くなるしなぁ
824:デフォルトの名無しさん
19/11/02 10:56:15.43 vl/bFsjF.net
要するに>>759は知ったかが無理矢理考えたアホストーリーと言うことでいいかな？w
825:デフォルトの名無しさん
19/11/02 10:57:17.10 vl/bFsjF.net
>>808
ああ、もうそういう返ししかできないのか…
高い理想とか笑えるわw
826:デフォルトの名無しさん
19/11/02 11:06:42.79 smHgTNTv.net
>>814
pimplだと構造体の実装はライブラリ側に完全隠蔽なのでその観点はおかしい
つかｊコンパイラのバージョンも関係無い
827:デフォルトの名無しさん
19/11/02 11:16:21.46 smHgTNTv.net
>pimplだと構造体の実装はライブラリ側に完全隠蔽なのでその観点はおかしい
何が言いたいのかというとライブラリ使用側がライブラリが依存する構造体メンバに直アクセスする前提なら
そんなライブラリはpimplにできんだろとゆーこと
つまりpimpl対非pimplの比較の想定が変
非pimpl条件のライブラリのインターフェース仕様だけ抽象度を下げて議論しても仕方が無い
828:デフォルトの名無しさん
19/11/02 11:16:32.42 EX+sUHBj.net
>>816
そんなライブラリ誰が使いたがるんだよ
829:デフォルトの名無しさん
19/11/02 11:23:46.22 l25LSbph.net
オープンソースやクローズドでも社内での話だったらソースごと提供すれば終わる話だし
社外提供なら多言語で使えるようにcのAPIを出すのが普通じゃないのか
その上で各言語用のラッパーも提供されるってのがありがちなパターン
830:デフォルトの名無しさん
19/11/02 11:37:12.15 pWYzNK5/.net
>>822
現時点で有用なら使うでしょ
逆に10年前からメンテされてなくて現時点でも使われてるライブラリなんてある？
メンテされてるかよりその時代に即したものに乗り換えてくでしょ
831:デフォルトの名無しさん
19/11/02 11:50:05.18 EX+sUHBj.net
いやメンテなり機能追加はしろよ
仕様がらっと変わるのわかってるもんなんて使いたくないわ
作り手も使う側めんどいだろ
832:デフォルトの名無しさん
19/11/02 12:26:20.48 DuRHh2CY.net
D なぜ流行らなかったし
Go 突き抜けてる
Rust ちょっと意識高い系
Nim 有望
JULIA 話にならない
833:デフォルトの名無しさん
19/11/02 12:50:14.99 esIitHWU.net
>>824
ライブラリじゃないけど例えばExcel2003とかまだCOM経由なら動かせるでしょ
COMの泥臭いインターフェースだから面倒だけどね
834:デフォルトの名無しさん
19/11/02 12:54:19.41 pWYzNK5/.net
>>827
動かせるけどクソだよね？
だから新しいのつかうじゃん？
つうかoffice系は延々と互換性意識してメンテされ続けてるじゃん
835:デフォルトの名無しさん
19/11/02 13:22:43.30 esIitHWU.net
>>828
俺が言ってるのはCOMの話な
Excelの話はケースバイケースだからなんとも言えんし俺には関係ないからどうでもいい
836:デフォルトの名無しさん
19/11/02 13:28:52.76 pWYzNK5/.net
>>829
COMの中身詳しくないんだけど一切メンテされてないの？
今までwinは山ほど脆弱性をupdateしてるけど、そういう中にCOM周りの修正とかなかったの？
間違いなくあったと思うんだよね。
COMに限らず現状使えるMS産のもので10年間内部が未修正のものなんて多分存在しないんじゃない？
だから10年後のことだけなんて考慮する必要なくて将来に渡り有益ならどうせメンテされるし一時的なもので将来無益になるなら消え去るんだよ
837:デフォルトの名無しさん
19/11/02 13:32:28.90 pWYzNK5/.net
>>829
なんか前後で俺の主張がずれてる感じで申し訳ない
838:デフォルトの名無しさん
19/11/02 13:52:05.38 esIitHWU.net
>>830-831
インターフェースの話とインターフェースの先にあるライブラリとかCOMサーバーの話をごっちゃにしてないか？
839:デフォルトの名無しさん
19/11/02 14:07:55.01 RcR6NuMm.net
>>821
勘違い甚だしい
ライブラリ使用者に無関係で見せたくないからpimplで隠すという話をしてる隠さなかったら無用にincludeが増えるし、最悪そのinclude先の仕様変更で互換がくずれる場合もあると
840:デフォルトの名無しさん
19/11/02 14:12:10.51 RcR6NuMm.net
>>823
そう、それが結局いまだによくも悪くもベストプラクティス
わかってないやつ多いんだよ
いきってc++で自称モダンな設計で作り上げてあとで泣きながらcのインタフェース作るはめになる
たいてい機械的なラッパーではすまないからな
841:デフォルトの名無しさん
19/11/02 14:34:01.62 SXOl8GCi.net
void*的な「ハンドル」を経由して操作するやーつ
C由来のインターフェースは強いな
842:デフォルトの名無しさん
19/11/02 14:53:41.66 QFHeQDAU.net
>>827
> ライブラリじゃないけど例えばExcel2003とかまだCOM経由なら動かせるでしょ
Excelとか以前に、DirectXやシェル（エクスプローラー）そのものがCOMだから
843:デフォルトの名無しさん
19/11/02 14:55:12.97 QFHeQDAU.net
>>832
そうそう。脆弱性の話はCOMじゃなくてDCOM。
もちろんCOMも脆弱性とは無関係ではないんだけど、
それはC++がバッファーオーバーフローと無関係ではないのと
同じようにCOMの設計自体の問題じゃない
844:デフォルトの名無しさん
19/11/02 15:00:15.19 4213U75y.net
ComPtr使ってる？
845:デフォルトの名無しさん
19/11/02 15:04:46.15 i1zx37WV.net
Essential COMの第1章で、C++からいかにしてCOMに至るか書いてあるけど、あの流れすごい好き
846:デフォルトの名無しさん
19/11/02 15:07:11.40 QFHeQDAU.net
std::filesystem はようやくできたかって感じだが、環境変数でまたorz
なんでこう、使う道具がまともに作られてないんだろうな
C++はメモリ管理ばっかり気にしてる気がする。
847:デフォルトの名無しさん
19/11/02 15:09:57.95 esIitHWU.net
>>836-837
> Excelとか以前に、DirectXやシェル（エクスプローラー）そのものがCOMだから
だからCOMとその先を区別してくれよ
COM自体は単なるインターフェース規約で実装は別
脆弱性とかは実装の不具合だから見つかり次第修正されてる
インターフェース規約も仕様バグとかありうるけどCOM自体の仕様バクは聞いたことない
848:蟻人間
19/11/02 15:13:34.66 OyXmLdGY.net
＿
.:⌒: 、 __ ＞: : : : : : :. ＜
|: : : :/´ : : : : : : : : : : : : :. ｀ﾞ ､
‐.､／: : : : : : : : : : : : : : : : : : : i
У: : : : : : : : : : : : : : : : : : : : :/ ＼
/: : : : : : : : : : : : ', : { : : : : : : :} __ ＼
. ｊ: : ;彡': : : : : : : : : ' : ', : : : : : ﾘ ／ : : : : : : . . ＼
: : : : : : : : : : : : : : : }: :ト : : : : ′ /: : : : : : : : : : : ヽ '.
: : : : : : : : : : : : : : :ノ :∧: : : : { / : : : : : : : : : : : : : : ｖ
. i: : : : : : : : : : , ‐＜ ＞: :∧: : : :', ＞‐:'―: : : : : : : : : : : : : : :.
. | : : ／⌒y:／ /: : : : : _ヽ: : ／: ヽ: : : : : : : : : : : : : : : : : : :|
八: : { ^ {: : : Ｙ´ ∨: : : x ― - . . __: : : : :__, : : : : }
ｰ′ У: : j {: : : ﾉ ／: : : : : : :￣: : : : : : イ
〈: : :/＾ ｰ^ ／ : : : : : : : : : : : : : ＜
^彡 /: : :ヽ -‐= ￣￣
{: : :ノ
ゞ´
849:デフォルトの名無しさん
19/11/02 15:31:17.24 QFHeQDAU.net
>>841
俺に言うなよ。俺はCOMは使われてるとしか言ってない。
シェル（エクスプローラー）をCOMで操作できるという
基本的な機能の互換性をなくすとか考えられん。
850:デフォルトの名無しさん
19/11/02 15:36:48.55 16zH/LAn.net
>>840
環境変数は昔から標準化されてるだろ。設定は微妙だけどデファクト標準関数があるし。
851:デフォルトの名無しさん
19/11/02 15:56:49.53 QFHeQDAU.net
>>844
std::cout << なんとか("PATH");
のように一行でやる方法教えて
もちろん脆弱性などで非推奨と言われるようなやり方は禁止
俺はここまでできて「使える道具」だと思ってるよ
852:デフォルトの名無しさん
19/11/02 16:32:02.24 neC/7x9U.net
>>843
だからCOMの話にその先であるエクスプローラの話を混ぜるなよ…
ところでExplorerってCOMで操作できたっけ？
Internet Explorerの話じゃないよね？
853:デフォルトの名無しさん
19/11/02 16:32:29.90 neC/7x9U.net
>>845
なぜに一行縛りなの？
854:デフォルトの名無しさん
19/11/02 16:50:16.72 TAka4wsD.net
OpenStack, Terraform でも、クレデンシャルなどの環境変数は、1つのファイルにまとめる
それでプログラム内で、os.environ[ 'OS_PASSWORD' ]
みたいに取得する
直接、設定ファイルに書いて、git に保存するのは禁止！
855:デフォルトの名無しさん
19/11/02 17:09:24.74 orbX83iK.net
>>845
curl
env()
856:デフォルトの名無しさん
19/11/02 18:41:30.33 QFHeQDAU.net
>>847
実現可能な最小の行数
（一行でできるようにすることは他の言語で実現されてることからも明らか）
857:デフォルトの名無しさん
19/11/02 18:44:29.21 QFHeQDAU.net
ちなみにさっきオレオレで20行ぐらいの関数を書いて
一行で環境変数を取得できるようにしたよ。
でもこういうのは標準ライブラリで用意してあるべきもの
858:デフォルトの名無しさん
19/11/02 18:44:52.66 RcR6NuMm.net
こいつアホだろ
859:デフォルトの名無しさん
19/11/02 18:46:14.06 neC/7x9U.net
>>850
短ければ偉いとか思ってる？w
860:デフォルトの名無しさん
19/11/02 18:48:21.60 QFHeQDAU.net
>>853
俺が思ってるかどうかじゃなくて、
お前が、こういう理由で短いのがいい or だめと
"お前の意見" を書け
861:デフォルトの名無しさん
19/11/02 19:23:54.18 neC/7x9U.net
いや、お前がそう思ってるならいいんじゃね？w
862:デフォルトの名無しさん
19/11/02 20:10:41.91 QFHeQDAU.net
ん？反対意見があるんじゃないのか？
ないんだね。
お前がなにか思ってるだけかよｗ
863:デフォルトの名無しさん
19/11/02 20:16:14.52 FTVoAoH0.net
この手のバカでもたった20行で作れるんだろ
やっぱりC++は偉大じゃないか
864:デフォルトの名無しさん
19/11/02 20:17:34.65 QFHeQDAU.net
車輪の再発明。ってか他の言語使ったほうがいいよ。
865:デフォルトの名無しさん
19/11/02 20:28:57.58 16zH/LAn.net
>>845
だったらはじめから「僕はこうじゃなきゃヤなんだー」って言ってくれないと何も伝わらないぞ
866:デフォルトの名無しさん
19/11/02 20:32:42.04 QFHeQDAU.net
はじめから言ってる
> std::cout << なんとか("PATH");
> のように一行でやる方法教えて
867:デフォルトの名無しさん
19/11/02 20:36:29.98 dYVngRw/.net
> 車輪の再発明
典型的なアイディアキラー！ マジ死ねよ
ガタガタくだらねえこと言ってねえで
本能のままにやってみたいことに暴走しなきゃ
何もできちゃ来ねえんだよ
そういう生産物の上にあぐらかいて怠けているゴミ共にわかるわけねえ！
868:デフォルトの名無しさん
19/11/02 20:42:10.52 QFHeQDAU.net
std::filesystemができたように、
std:envも作れってだけの話なのにね
何がそんなに気に触ったんだろう？
869:デフォルトの名無しさん
19/11/02 20:49:43.64 16zH/LAn.net
>>860
はあ？845が初出じゃん
getenvでいいだろ。
未定義時のエラー処理まで自動でやってほしいのか？
870:デフォルトの名無しさん
19/11/02 20:58:09.22 wdMk8lAB.net
一行じゃないとヤダとか条件を後出ししたからじゃね
871:デフォルトの名無しさん
19/11/02 21:01:20.92 dYVngRw/.net
> 何がそんなに気に触ったんだろう？
とぼけてんなよ、はっきり書いてんだろ
車輪の再発明と貴様はほざいた
撤回も修正も今さらいらねえ
872:デフォルトの名無しさん
19/11/02 21:08:11.55 QFHeQDAU.net
>>864
そんな下らないことで（笑）
一行とかそんなの重要なところじゃなく、
stdの名の元でまともなライブラリを作ってくれって話だよ
仮にも「標準」ライブラリなんだからさ
昔ながらのgetenvやその安全版はstd:stringが使われてないし、
std::getenvも、なぜかstd::stringではなくchar*が使われていて
使うとエラーとされるレベルの非推奨関数だし、当然ワイド文字版もないし
使おうと思った人なら、まともじゃないの意味ぐらいわかるはず
あ、使ったことない人が噛み付いてきたのかｗ
あと環境変数の未定義は正常な状態としてありえるのでエラーではない
細かくてすまんなｗ 適当な発言は気になるんだよ。
873:デフォルトの名無しさん
19/11/02 21:09:21.56 QFHeQDAU.net
>>865
噛み付いてばかりじゃなくて、"自分の意見"を言うだけの
知識はあるのかい？
874:デフォルトの名無しさん
19/11/02 21:11:47.48 RcR6NuMm.net
c++の標準ライブラリにプラットフォーム抽象の機能求めるってのは筋が悪いんだよ
filesystemだって結局はposixをテンプレートの味付けで焼き直した程度でファイルの監視もできないだろ
envとか別に標準で提供されなくても何も困ってない
1行かどうかなんてさらにどうでもいい
あと標準ライブラリが提供する範囲の機能で足りてるアプリ作ってるやつは
c++以外の言語使うことを考えた方がいい
875:デフォルトの名無しさん
19/11/02 21:29:52.49 neC/7x9U.net
>>856
> お前がなにか思ってるだけかよｗ
うん、バカな縛りだなと思ってるw
876:デフォルトの名無しさん
19/11/02 21:36:05.57 lCdDFN2K.net
組み込み系なんてenvどころかfilesystemとかそもそもねぇの普通な環境も多いしね
877:デフォルトの名無しさん
19/11/02 21:56:35.34 dYVngRw/.net
>>867
本能の枯れた人生の搾りかすめ
878:デフォルトの名無しさん
19/11/02 22:00:29.09 jnnO2x8F.net
ここは毎回しょうもないことで荒れるな
これだからC++界隈って嫌い
879:デフォルトの名無しさん
19/11/02 22:07:02.10 lY37zOLC.net
まあもともと広いレンジで使われることを目的とした言語だし
いろんな輩が入ってくるのはしゃーない。
しかしc++11以降は明らかに開発してないクソガキが増えたなという印象はある。
880:デフォルトの名無しさん
19/11/02 22:52:35.22 egbBWGD9.net
ないなら作りゃいいのに
なんのためプログラミングなんだろか
881:デフォルトの名無しさん
19/11/02 22:57:03.69 l25LSbph.net
せっかくhas_includeみたいなのも出来たのだから、環境ごとに存在しない場合機能提供されないようなものも標準化進めていったらいいんだよね
882:デフォルトの名無しさん
19/11/02 22:57:09.83 oLFNuF1W.net
2chのゴミスレ＝C++界隈
883:デフォルトの名無しさん
19/11/02 23:15:11.30 FTVoAoH0.net
>>876
そこに涌く小バエ
884:デフォルトの名無しさん
19/11/02 23:38:30.50 dJ3V2vrm.net
>>876 >>877
場所そのものを馬鹿にするのはよくない。
それは差別や権威主義を生み易い。
885:デフォルトの名無しさん
19/11/03 00:27:38.19 wm/wPyZM.net
>>875
一応フリースタンディング処理系っていう分類があるのでそれはもうされてる
886:
19/11/03 21:55:47.13 A1whpPq+.net
>>732
一つ教えてください、pimpl とか何べん読み返しても「利益の源泉」がわからないのですが、一つ一言で言い切っていただけませんか？
887:
19/11/03 21:58:20.86 A1whpPq+.net
>>775
＞マングリングって知ってるか？
＞そもそもC++のクラスライブラリを簡単にリンク
私は Java も ruby も触っていますが、お手軽に java のライブラリを c++ から使いたいと、ふつふつ、と、思っているのです…
888:デフォルトの名無しさん
19/11/04 00:16:08.68 J7PIJnTc.net
>>880 （732じゃないけど）
クラス実装の変更に対する再コンパイルの必要性の削減。
これが利益とならない環境では用はない。これが利益となる環境はある。
個人的には同じ目的ならインターフェースクラス＋生成関数のほうが手間が少なくて好み。
公開済みのクラス（具象クラス）に後付けでも適用できるのが pimpl の強みじゃないかな。
889:デフォルトの名無しさん
19/11/04 00:45:00.04 sHXph+lc.net
>>833
>>821は、>>802からの流れなのでヨロ
そうした上で、
>ライブラリ使用者に無関係で見せたくないからpimplで隠す
それがpimpl固有の特質である根拠とは…
構造体の詳細を見せる必要が無いなら
別にハンドルでも良いじゃん？Cだと昔からそうしてきたわけやし…
>>834
構造体の詳細を見せる必要が無いなら
別にハンドルでも良いじゃん？Cだと昔からそうしてきたわけやし…
pimplとかC++で実装する側がソースコードを整理したい目的で使うものであって、
ライブラリの公開インターフェースがpimplであるべきという論こそ勘違い甚だしい
890:デフォルトの名無しさん
19/11/04 00:50:27.63 HxncxYCK.net
>>881
お前の老害頭では無理だと思う
891:デフォルトの名無しさん
19/11/04 01:01:50.05 qdasM095.net
コンパイル時にリフレクションできたらC++にはもう何も望まないんだけどな
892:デフォルトの名無しさん
19/11/04 01:16:04 bOoSbled.net
リフレクションしたいとか実行時にあれだとかこれだとかしたいとか
もっと安全性を高めたいとかいう人はC#にいったらいいとおもうんだが
なぜいかないのか
893:デフォルトの名無しさん
19/11/04 04:20:27.81 6RBgtjpd.net
マングリングとかも規格で決めてほしいよね
そうすればクラスのエクスポートなんかも簡単になるのに
894:デフォルトの名無しさん
19/11/04 06:09:25.96 26dKwYrd.net
動的はともかく静的リフレクションはあって困る場面は無いだろ
冗長な記述や変なマクロを使わずに、enumを文字列化したりしたいだろ
895:デフォルトの名無しさん
19/11/04 06:17:29.31 ktSXuT3K.net
名前マングリングの方法がコンパイラ毎に違うおかげで
互換性のないオブジェクトファイル同士がリンクされる事故を防げる、って
『More Effective C++』に出てたな。
便利さも欲しいが安全性も保ちたい、という要求のせめぎあいだな。
896:デフォルトの名無しさん
19/11/04 06:59:32.99 1EaGoi2+.net
今生き残ってるC++のコンパイラってどのくらい種類あんの
特定ハード向けのもgccの派生なんでしょ？
897:デフォルトの名無しさん
19/11/04 09:40:11.27 sHXph+lc.net
>>833
>>883とｵﾓﾀがちょっち訂正しておき鯛、
publicなメンバ関数だけでprivateを一切含まずに事を済ますクラス定義を広義のpimplとみなすなら
ライブラリの公開インターフェースとしてpimpl最高じゃな
ハンドルだけだとユーザーが間違った呼び出しをしかねない
これをpimpl式にクラスでwrapするのはｽｹﾞｰ有効
898:デフォルトの名無しさん
19/11/04 10:05:11.25 7p81GTJD.net
つーかハンドルで渡して使う時にキャストするって面倒だからさ
privateだからいいでしょとかいう問題じゃない
899:デフォルトの名無しさん
19/11/04 12:16:24.53 pwba8h1Q.net
記述の煩雑さはもう諦めるけどインラインPimplでゼロオーバーヘッドにしてほしい
900:デフォルトの名無しさん
19/11/04 12:22:24.34 TNJ/Yj6e.net
煩雑さを許容できるならやれるでしょ
pointerでなくバイト配列にしておいて中でcastするやつ
気を付けないところいろいろあるけど
901:デフォルトの名無しさん
19/11/04 12:35:35.98 jCRIC3rQ.net
オーバーヘッドを気にしている人の大半は、気にする必要のあるものを作っていない
902:デフォルトの名無しさん
19/11/04 12:35:45.49 DlV1X8tk.net
実装をpimplに押し込めて公開インターフェース上の変数メンバの増減を無くすのが肝なんだから
pimplのデリファレンスのオーバーヘッドは避けようがないだろう。
903:デフォルトの名無しさん
19/11/04 12:41:44.84 7p81GTJD.net
そもそもprivateな関数宣言をpublicなヘッダに
書かないといけないというC++言語仕様の欠陥
publicヘッダとprivateヘッダの二つに分けて
クラス宣言できればよかった
ちなみにC#ではpartialクラスといって
複数のファイルにまたがってクラスの定義ができる
904:デフォルトの名無しさん
19/11/04 13:33:20.96 TNJ/Yj6e.net
>>896
こういうの
URLﾘﾝｸ(ideone.com)
pointerじゃないからpimplではない
905:デフォルトの名無しさん
19/11/04 13:45:03.05 7wrIz40y.net
まあ欠陥って言われてもprivateメンバー変数変更されたらインスタンスのサイズ変わったりするから
1) 参照してるソースも含めてリコンパイルする
2) ポインタで持つ（pimpl）
しかないからねぇ
C++的には現状の言語仕様でIDEでprivateは見せないようにもできるとかでいいと思う
906:デフォルトの名無しさん
19/11/04 13:47:25.16 ncwvkXHO.net
>>898
パズルとしてはいいけど真顔で書いてたらちょっと引くわw
907:デフォルトの名無しさん
19/11/04 13:59:48.02 DlV1X8tk.net
>>898
その場合でも任意の変数メンバの拡張性は結局 Hide::a の存在で保証されているわけだろう。
impl[32] と予約された範囲まで拡張できるというのもあるのかもしれんが。
908:デフォルトの名無しさん
19/11/04 14:00:47.43 7P/NsyXI.net
結局低レイヤーを考慮しないでバカが文句言ってるだけで
そんなことに付き合う必要はないんだよ。
909:デフォルトの名無しさん
19/11/04 14:16:11.73 TNJ/Yj6e.net
>>901
バイナリ境界にしたときの拡張性のこと言ってる？
それはまさに配列のサイズでリザーブだね
溢れたら終わり
目的がヘッダー依存を切ることなら必要に応じて配列サイズ増やせばいいだけ
めんどいけどassertかけてあるからミスることはない
あとpimplは中でnewされるのがいやな場合あるからそれを避けられるってのも大きいね
910:デフォルトの名無しさん
19/11/04 14:34:36.07 mRc+a4F8.net
>>897
（使う側が）、CPerson person[10]; や、new CPerson[10] のように書いたと
すると、C++は高速化のため、CPersonのバイトサイズを定数値として
静的にコンパイルして、スタックや Heapからそれらのオブジェクトの領域を
確保する。
なので、たとえC++でCPersonのprivateメンバがC#のpartialの様に分けて宣言できた
としても、それらを全て合わせた全体のバイトサイズが分からないと静的に処理できない。
故に結局、partialの一部であっても全体のサイズに影響のあるような変更が行われた
場合には、上記の様な形でCPersonを使うプログラムは再コンパイルが必要となる。
911:デフォルトの名無しさん
19/11/04 14:57:14.11 VEKGTWb6.net
プリコンパイルドヘッダが標準化されればなんとかなるかも
912:
19/11/04 16:01:14.23 fwURXfb5.net
>>905
そういうのはやめてほしいです…
913:デフォルトの名無しさん
19/11/04 16:31:03.20 q2OPdcJi.net
>>906
良いか悪いかは仕様次第なんじゃないの？
コンパイルされてたら無条件でアウト？
914:デフォルトの名無しさん
19/11/04 16:35:25.90 q2OPdcJi.net
差分とりづらいってのはあるか
915:デフォルトの名無しさん
19/11/04 20:26:00.54 sHXph+lc.net
>>897
構造体データメンバのメモリ配置を正確に定義したいという目的を捨てない限り
privateなデータメンバをprivateヘッダに分けて定義できるようにしたところで
pimplが目指すような解決にはならない
ほとんど意味が無い
916:デフォルトの名無しさん
19/11/04 20:31:52.81 sHXph+lc.net
pimplが目指すような解決というのは筆が滑ったorz
とにかくprivateなデータメンバをprivateヘッダに分けて定義できるようにしたところで
実装の隠蔽にはやっぱハンドル経由とかポインタ経由（pimpl）な間接参照が必要なままである
構造体データメンバの追加や削除や順序変更が
publicなヘッダに定義されたインターフェース仕様に影響しなくなりはしない
917:デフォルトの名無しさん
19/11/04 21:34:38.56 TNJ/Yj6e.net
>>900
言うてもplacement newしたオブジェクトに移譲してるだけだからたいしたことやってない
まぁこれが規格的にセーフかどうかは知らんけどな
918:デフォルトの名無しさん
19/11/04 21:53:48.72 7wrIz40y.net
>>911
> uint8_t impl[32];
固定サイズで確保してる時点であり得んわ
919:デフォルトの名無しさん
19/11/04 22:09:21.71 TNJ/Yj6e.net
そこはどうにもならんな
他にいい方法あるなら知りたい
上で触れてるけど、逆にバイナリ互換とるときはそういうリザーブが役立つこともある
920:デフォルトの名無しさん
19/11/04 22:38:30.89 7wrIz40y.net
>>913
> 他にいい方法あるなら知りたい
ないからpimplとかなんだろ
だからと言ってテキトーに領域定義とかあり得んだろ
921:デフォルトの名無しさん
19/11/04 22:40:59.70 jCRIC3rQ.net
そもそもポインタ参照ごときのオーバーヘッドをも許さないほどリアルタイム性を要求するもの作ってんの？
922:デフォルトの名無しさん
19/11/04 22:51:45.72 TNJ/Yj6e.net
>>914
適当がいやなら同じサイズにすりゃいいじゃん
static_asserの条件を==にすればいい
手間はかかるが、それが許容できる前提の案ね
923:デフォルトの名無しさん
19/11/04 22:58:08.77 7wrIz40y.net
>>916
バカなの？
ちょっとサイズ変更されたら使えない
かと言ってどんだけ余裕持てばいいかは未来予知能力でもないと無理
要するに常人には使いどころがないってことな
924:デフォルトの名無しさん
19/11/04 23:05:23.77 J+RS26ji.net
>>915
C++の用途として可能な限りオーバーヘッドをゼロとすることが要求されるケースがあるのは当然の話であるが、別に議論に参加するものがそういう物を作っている必要性はないだろうに、何でこだわってるんだ？
925:デフォルトの名無しさん
19/11/04 23:12:26.97 TNJ/Yj6e.net
>>917
だから手間がかかると言ってるわけ
やる気になれば自動化できるスクリプトは作れるだろうけどね
バカと思うかもしれないけどreserveフィールドでバイナリ互換を保つってのは実際やるんだよ
未来を予測できないのはそのとおり
適当に決める
まぁお前の知らない世界の話だから気にするな
926:デフォルトの名無しさん
19/11/04 23:25:59.73 DlV1X8tk.net
外部からはデストラクタもコピーコンストラクタも動かせないのにあえてインラインにする
理由がよくわからないな。
よっぽど特殊でピンポイントな要件なのかもしれないが。
927:デフォルトの名無しさん
19/11/05 01:47:52.32 8w7ODMFL.net
placement new を使った
char* ptr = (char *)malloc(sizeof(CPerson));
CPerson *pPerson = new(ptr) CPerson;
という書き方、実は、「コンストラクタの明示的呼び出し」なるものを使って、
CPerson *pPerson = (CPerson *)malloc(sizeof(CPerson));
pPerson->CPerson::CPerson(); // コンストラクタの明示的呼び出し
と書くことも出来るらしいことを最近知った。
928:デフォルトの名無しさん
19/11/05 06:17:56.31 cY6SY5gz.net
ああそうそれは良かったね～
929:デフォルトの名無しさん
19/11/05 07:19:41 UkGDCuYx.net
>>919
手間の問題じゃないよ
せっかく変更に強くするためにやってるのに
> 適当がいやなら同じサイズにすりゃいいじゃん
なんてやったら本末転倒だろ
> やる気になれば自動化できるスクリプトは作れるだろうけどね
未来予知機能付きのスクリプトができたらいいねw
> バカと思うかもしれないけどreserveフィールドでバイナリ互換を保つってのは実際やるんだよ
ああ、昔のコボラー爺の発想ねw
ファイルとか通信とかで外部とやり取りするようなものだと今でも普通にあるけどメモリーレイアウトでやるのは流石に悪手でしかない
> まぁお前の知らない世界の話だから気にするな
時代遅れのお前の妄想に閉じ込めといてくれw
930:デフォルトの名無しさん
19/11/05 07:51:55.68 rlbxGVpf.net
>>780
cygwinで配布してるwxwidgitはgcc3時代のabiでバイナリ作られてるが当然gcc8でもabiオプションで変えてリンクできる
931:デフォルトの名無しさん
19/11/05 07:55:46.59 Cze7w/ei.net
>>921 何を見て「出来るらしい」と言ってるのかな？
932:デフォルトの名無しさん
19/11/05 08:36:03.93 g61EG+/r.net
解放も自前でやるんなら別にいんじゃね？
933:デフォルトの名無しさん
19/11/05 08:47:49.22 wVD+ILW8.net
>>819
pimplが理想だなんて頓珍漢なレスで
ひっ絡んで来たのそっちだろうが
何がそういう返しだ
冗談は顔だけにしろ奇形チンパンジーめ