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が理想だなんて頓珍漢なレスで
ひっ絡んで来たのそっちだろうが
何がそういう返しだ
冗談は顔だけにしろ奇形チンパンジーめ
934:デフォルトの名無しさん
19/11/05 12:36:38.02 UkGDCuYx.net
>>927
まさかと思うが
> 目指す理想がpimpl?
って理想がpimplって言ってるとでも思ったのか？
デザインパターンの前に日本語の勉強しろよw
935:デフォルトの名無しさん
19/11/05 12:48:20.10 XPYDDbPn.net
日本人じゃないんじゃない？
936:デフォルトの名無しさん
19/11/05 16:03:35.45 wVD+ILW8.net
>>928
安心しろ
あからさまにラリッてる廃人の戯言など
どうとも取ってねえよ
そんな価値があるとでも思っているなら
とんだナルシストだw
937:デフォルトの名無しさん
19/11/05 17:28:48.96 X2+zjlng.net
>>923
pimplの目的が変更に強いことってはお前の見方にすぎない
コンパイル時に検知できるんだから特別手間ではないし、
呼び出しコストを下げる目的は達している
技術的な話したいなら物事をフェアに見ような
938:デフォルトの名無しさん
19/11/05 18:57:55.00 lmPmis8+.net
手間はあるけど（俺は）手間だと感じないだから、変更に強いとは思わない
って言ってるの？
939:デフォルトの名無しさん
19/11/05 19:21:00.26 X2+zjlng.net
>>894
940:デフォルトの名無しさん
19/11/05 19:48:59.34 C6JaWlq+.net
実装側のサイズが想定をオーバーしたら互換性無くなって再コンパイルになるんでしょ
それが許容される環境ならインターフェース切る意味が薄れるんじゃないの？
まぁ実際はオーバーしないようにするんだろうけど
941:デフォルトの名無しさん
19/11/05 19:52:57.91 UkGDCuYx.net
>>930
どうとも取ってないのに顔真っ赤にしてレスするとか珍しいなw
942:デフォルトの名無しさん
19/11/05 19:54:47.54 UkGDCuYx.net
>>931
ごめん、お前なんのために>>898みたいなことやるの？
説明できる？w
943:デフォルトの名無しさん
19/11/05 20:04:16.17 Rmlz0hln.net
>>936
pimplの説明ならこのスレで何度も出てると思うが？
それにしたいして、お前の反論は「俺はそうは思わない」という感想でしょ？
技術的な話したいなら物事をフェアに見ような
944:デフォルトの名無しさん
19/11/05 20:18:38.99 GaJDeol8.net
>>893 というお題な対して出した案が >>898
privateは隠蔽できて、かつ呼び出しコストは低い
配列サイズ増やしたらバイナリ互換がとれないのは承知してる
しかしそれはI/Fにする構造体一般の話であってこの件に限ったことではない
もう十分説明したつもり
945:デフォルトの名無しさん
19/11/05 20:37:36.25 UkGDCuYx.net
>>937
>>898がpimplに見えるならちょっと黙っててもらっていいかな？
邪魔なだけだし
>>938
なるほどね
とにかくprivateは見せたくないって事ならそれでいいんじゃね？
俺はやりたくないけどw
946:デフォルトの名無しさん
19/11/05 20:51:01.63 mHpC8FDb.net
>>935
とID真っ赤にしてレスするやつ
別に珍しくもねえ どこにでもいる虫けらめ
947:デフォルトの名無しさん
19/11/05 21:09:19.41 uxZ9xTP
948:+.net
949:デフォルトの名無しさん
19/11/05 21:15:13.47 ZKJgPI6j.net
事務職だけど、C++使ってる
こんな便利なプログラミング言語があるとは
950:蟻人間
19/11/05 21:19:49.70 36DcdPPB.net
pimplesが顔に出たのは中学・高校時代だったか。
951:蟻人間
19/11/05 21:23:07.90 36DcdPPB.net
pointer to implementation
952:デフォルトの名無しさん
19/11/05 22:48:13.18 5N1tjWFS.net
結局のところ、>>893の言う「インラインPimpl」なるものの解釈なんだよな。
「そんなものありえない」>>896
「こうすればできるよ」>>898
俺は「ありえない」派だが。
953:デフォルトの名無しさん
19/11/05 22:54:52.19 JFmkzqZr.net
ピンプルはシンプルじゃないとダメでしょ
954:デフォルトの名無しさん
19/11/05 23:19:34.53 +/SJ/H3y.net
他の言語ではprivateを隠すための努力なんてしなくていいよね
あくまでc++特有のパターンとしてpimplがある
pimplの肝は、ポインタだけなら前方宣言すればincludeしなくてOKっていう
抜け穴的なところからきていてポインタであることは妥協の産物
implクラスを変更しても互換性が保たれるというのはあくまで副次的
ゼロコストじゃないわけでc++の思想からも外れている
955:デフォルトの名無しさん
19/11/05 23:26:17.64 +K1+YrIp.net
何をもって思想から外れていると？
C++の設計思想は最速を目指すことじゃないからな
956:デフォルトの名無しさん
19/11/05 23:41:22.87 +/SJ/H3y.net
Bjarne Stroustrupがそう言ってる
957:デフォルトの名無しさん
19/11/05 23:55:16.05 +K1+YrIp.net
始まりはそうだったかも知れんが、現在の規格の設計思想は明らかに違う
958:デフォルトの名無しさん
19/11/05 23:58:36.99 UFe3q3jM.net
最速を目指すって言うと少し外れてるけど、速度を重視するという所は変わってない
959:デフォルトの名無しさん
19/11/06 00:01:20.76 x6qzxIK7.net
それ以上に集団での開発効率を重視したもの
>>898のような奇怪なものよりpImplの方がモダンC++の設計思想に合っているのは間違いない
960:デフォルトの名無しさん
19/11/06 00:04:55.89 pco2p4E4.net
別に抜け穴でも何でもないだろ
なきゃこまるじゃん
961:デフォルトの名無しさん
19/11/06 00:12:17.42 L0p3vvTY.net
>>950
明らかに～
説明できないときにつかう常套句だよね
少なくともc++17まではその設計ポリシーが挙げられてるよ
962:デフォルトの名無しさん
19/11/06 00:18:49.38 L0p3vvTY.net
>>952
はぁ？
pimplのどこがモダンなの？
最低限delegateを手で書かなくてもいいようにしてから言ってくれよ
スマートポインタ以下だから
963:デフォルトの名無しさん
19/11/06 00:32:45.47 EoKh/jsd.net
設計の方針は曖昧なものではなく明文化されてるから調べてきてね
964:デフォルトの名無しさん
19/11/06 01:17:04.07 mNM1KOm6.net
ピンプルってピンポンみたいだね
965:デフォルトの名無しさん
19/11/06 01:37:31 clVAOuCS.net
ハリソン・フォード主演映画「逃亡者」(1993年)の主人公の名前は、キンブルだったね。
この映画はサントラが良い。ジェームズ・ニュートン・ハワードが音楽担当。
このサントラの「Helicopter Chase」という曲は、「タクティクスオウガ」(1995年)というテレビゲームの「VENDETTA!」という曲によく似ている。
966:デフォルトの名無しさん
19/11/06 05:47:10 iGLzVPkM.net
pimpl使ったことないからスルーしてたけど
>>947=>>949
ゼロオーバーヘッドの原則は言語が掲げるもので言語利用者を縛るものじゃねーよ
実際それが便利でコストが問題にならない使い方ならどう使ってもいいだろ
967:デフォルトの名無しさん
19/11/06 05:56:01 iGLzVPkM.net
>>954
君もなんか勘違いしてない？
最速を目指すなんて厨二病みたいなことを挙げていたというソースは？
968:デフォルトの名無しさん
19/11/06 06:54:13.33 cnDla3Ge.net
>>959
> ゼロオーバーヘッドの原則は言語が掲げるもので言語利用者を縛るものじゃねーよ
そうだよ、だからこの手の機能は言語仕様には含まれないってことな
> 実際それが便利でコストが問題にならない使い方ならどう使ってもいいだろ
誰もお前に使うななんて言ってないから使いたいなら勝手に使ってろよw
969:デフォルトの名無しさん
19/11/06 07:21:04.31 GB7Qlzkj.net
>>947
その主張にincludeは関係ないぞ
970:デフォルトの名無しさん
19/11/06 07:24:02.54 hwyI/gg2.net
質問です。
サンプルプログラムで割り込み処理の一文で
ISR(TIMER1_CAPT_vect) {}でサブルーチンを呼び出してたんだけど、()内の意味わかりますか？
971:デフォルトの名無しさん
19/11/06 07:41:29.30 iGLzVPkM.net
>>961
＞そうだよ、だからこの手の機能は言語仕様には含まれないってことな
誰か言語仕様に含めろなんて言ってたか？
さすがに隠したいメンバをポインタ経由で隠して無駄にコストかかる言語なら俺もお断りだが
ちな俺はplmpl使いたいなどと書いてない、人の主張を勝手に捏造するな
972:デフォルトの名無しさん
19/11/06 08:14:41.32 N/klFKt1.net
あと>>961=947と想定してもう一つ言っておくと
ポインタ変数の宣言に型(クラス)の実際の定義が必要ないのは抜け穴じゃない
必要ないから要求されないだけだ
どうもC++に対する認識がおかしい気がする
D&Eでも読んでこい
973:デフォルトの名無しさん
19/11/06 08:16:11.65 cnDla3Ge.net
>>964
> 誰か言語仕様に含めろなんて言ってたか？
誰もお前が言語仕様に含めろと言ってるなんて言ってないぞ
自意識過剰すぎだろ
> ちな俺はplmpl使いたいなどと書いてない、人の主張を勝手に捏造するな
使いたい「なら」な
C++の前に日本語やり直してこいw
974:デフォルトの名無しさん
19/11/06 08:17:38.83 cnDla3Ge.net
>>965
> あと>>961=947と想定して
バカほどこういう想定をしたがるw
975:デフォルトの名無しさん
19/11/06 08:21:27.02 N/klFKt1.net
ただの荒らしなら出てけ
976:デフォルトの名無しさん
19/11/06 08:31:26.58 zr2SzfAm.net
>>963
コンパイラが分からんけど、割り込みベクタテープルのシンボルだと思う。
タイマ1キャプチャ割り込みのハンドラを今から定義しますよ、みたいな。
977:デフォルトの名無しさん
19/11/06 09:33:53.63 GEOrtix2.net
サイズの違うコンテナ同士で代入を試みたらセグメンテーション違反になったんだが、リサイズしつつ代入って簡単にできないの？
978:デフォルトの名無しさん
19/11/06 09:54:01.45 B/9oP97H.net
>>970 できるよ。
#include <vector>
#include <cassert>
int main()
{
std::vector v1{1}, v2{1,2};
v1 = v2;
assert(v1 == v2);
}
979:デフォルトの名無しさん
19/11/06 10:35:41.19 GEOrtix2.net
>>971
普通できるのか
boostの「STLコンテナらしく振る舞う」というある多次元配列コンテナでできなかったから一般的にできないんだと思っちゃった
スマン
980:デフォルトの名無しさん
19/11/06 10:42:41.76 rSUWYkcI.net
そのためのstd::vectorのメンバ関数operator=だしな
981:デフォルトの名無しさん
19/11/06 12:22:15.65 2MfY+5W5.net
>>968
頓珍漢な想定でくだらんことしか言えないお前が出て行けよw
982:デフォルトの名無しさん
19/11/06 15:11:24.10 BVN8Da8w.net
今事務職であいてる時間C++やってるんだけど、事務職に特化したライブラリとかってない？
983:デフォルトの名無しさん
19/11/06 15:24:12.57 EoKh/jsd.net
>>975
awk,sed
984:デフォルトの名無しさん
19/11/06 17:52:40.67 lpQz5w/v.net
>>975
Excelのアドオン
985:デフォルトの名無しさん
19/11/06 18:44:11.86 XJugYxC8.net
char str[ ];
と宣言した場合、str[0] = '\0';というNULL終端をしなければなりませんが
string str[ ];
と宣言した場合は、特にNULL終端の必要性っていうのはないのでしょうか？
986:デフォルトの名無しさん
19/11/06 19:20:03.22 x6qzxIK7.net
？
987:蟻人間
19/11/06 19:23:25.64 Z1hQUtYe.net
std::stringはstd::string::c_strメソッドを使ってアクセスするとヌル終端になることが保証されている。
988:デフォルトの名無しさん
19/11/06 19:45:32.35 o3tEvZiY.net
char hoge[] は char の配列
別に文字列として扱う気がなければ 0 終端は必須ではない
string hoge[] は(突っ込まれるかもしれんが敢えて言うと) char[] の配列
上の char hoge[] とは別物
989:デフォルトの名無しさん
19/11/06 19:48:44.64 o3tEvZiY.net
あと片山の答えは >>978 の回答になっていない無関係な話 (いつものことだが)
990:デフォルトの名無しさん
19/11/06 19:59:36.42 JQYyTTQU.net
今やc_strでなくてもnull終端は保証されてるしな
991:デフォルトの名無しさん
19/11/06 20:14:12.93 KdcLkZY9.net
char str="";で多分null終端される。
stringは多分std::stringなのでそもそも文字列ではなくアドレスを扱う。
た・・・ぶ・・・ん・・・。うぼぁあああああああ。
992:デフォルトの名無しさん
19/11/06 20:14:31.39 XJugYxC8.net
>>978です
すみません 文字列として扱い、いきなりその変数を文字列と文字列の連携で使う場合の話です
つまり、その場合でも std::stringで宣言する場合は、"\0"で初期化する必要は無しということですね？
993:デフォルトの名無しさん
19/11/06 20:16:22.14 KdcLkZY9.net
すまん書き直し。
char str[]="";で多分初期化時にnull終端される。
「string str[];」は多分std::stringの配列なのでそもそも文字列ではなくアドレスを扱う。
994:デフォルトの名無しさん
19/11/06 20:52:15.48 vhzIqEHb.net
>>985
説明が上手くないからもうコードで書きなよ
995:デフォルトの名無しさん
19/11/06 20:56:59.66 y5v/16J4.net
ひょっとするとstd::string str[]じゃなくてstd::string strの間違いじゃないの？
996:デフォルトの名無しさん
19/11/06 21:29:23.43 3LXwRiA7.net
日本語の説明よりコード片の方が多少間違っていても意図を理解できるという
997:デフォルトの名無しさん
19/11/06 23:14:40.66 7z10T+eB.net
char[]は文字の配列＝一つの文字列でstring[]は文字列の配列だからそもそも比較するのが間違ってる
998:デフォルトの名無しさん
19/11/07 06:10:28 +Fv/+mh5.net
>>978 の char str[ ]; string str[ ]; は、どっちも
要素数不明の配列の定義でコンパイルエラーになるんと違うか?
宣言ってことは extern のつもりなんじゃろか。
>>988 の言う通り string str[ ]; は string str; かも知れんけど、
いずにせよ「質問が曖昧で答えようがない」の類かと。
999:デフォルトの名無しさん
19/11/07 08:06:36.36 N9TqrKuA.net
アスペ多すぎ
まともな頭していればstring str;の書き間違いだってわかる
1000:デフォルトの名無しさん
19/11/07 08:28:39.90 pA1g5yhx.net
コンパイラが空気読むわけないだろ（笑）
1001:デフォルトの名無しさん
19/11/07 08:37:03.72 S+DlaQTT.net
・・・からけ？
1002:デフォルトの名無しさん
19/11/07 08:39:29.18 t3M9+vGM.net
>>992
本気でstring str[];だと思ってる可能性を否定しきれない
現実にその手の奴はいるし
1003:デフォルトの名無しさん
19/11/07 08:44:57.00 C1GJGInU.net
>>978です
明らかに自分が悪いです
char str[ ];
と宣言した場合、str[0] = '\0';というNULL終端をしなければなりませんが
std::string str;
と宣言した場合は、特にNULL終端の必要性っていうのはないのでしょうか？
に修正です
1004:デフォルトの名無しさん
19/11/07 09:42:08.88 GEuBrdxx.net
無い
というか元々stringはC言語由来のゼロ終端とは違い、
「サイズ持ってんだから最後を示すデータは不要」という考え方だった
C++11からは利便性のためにゼロ終端が保証されてるけどユーザーが何かする必要はない
1005:デフォルトの名無しさん
19/11/07 09:51:34.14 GEuBrdxx.net
初心者ぽいから説明が悪かったかもしれん
クラスが内部でやってくれることなので特に何かする必要はない
けど、内部データを直接書き換えたりするとおかしなことになるので注意
1006:デフォルトの名無しさん
19/11/07 10:35:04.78 Q8xac2sp.net
stringに対するstring_viewみたいにint配列等にたいするviewはありますか？
1007:デフォルトの名無しさん
19/11/07 10:38:43.53 dB1QBGXo.net
'\0' と 0 とどっち使うのが良い？
NULL は論外だよな
1008:1001
Over 1000 Thread.net
このスレッドは１０００を超えました。
新しいスレッドを立ててください。
life time: 54日 17時間 25分 19秒
1009:1002
Over 1000 Thread.net
5ちゃんねるの運営はプレミアム会員の皆さまに支えられています。
運営にご協力お願いいたします。
──────────
《プレミアム会員の主な特典》
★ 5ちゃんねる専用ブラウザからの広告除去
★ 5ちゃんねるの過去ログを取得
★ 書き込み規制の緩和
──────────
会員登録には個人情報は一切必要ありません。
月300円から匿名でご購入いただけます。
▼ プレミアム会員登録はこちら ▼
URLﾘﾝｸ(premium.5ch.net)
▼ 浪人ログインはこちら ▼
URLﾘﾝｸ(login.5ch.net)
1010:過去ログ ★
[過去ログ]
■ このスレッドは過去ログ倉庫に格納されています