C++相談室 part145

**デフォルトの名無しさん** · 2019/09/13(金) 17:13:24.60

C++に関する質問やら話題やらはこちらへどうぞ。
ただし質問の前にはFAQに一通り目を通してください。
IDE (VC++など)などの使い方の質問はその開発環境のスレにお願いします。

前スレ
C++相談室 part144
https://mevius.5ch.net/test/read.cgi/tech/1563769115/

このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
https://mevius.5ch.net/test/read.cgi/tech/1556142878/

■長いソースを貼るときはここへ。■
　http://codepad.org/
　https://ideone.com/

[C++ FAQ]
https://isocpp.org/wiki/faq/
http://www.bohyoh.com/CandCPP/FAQ/ (日本語)

----- テンプレここまで -----

**デフォルトの名無しさん** · 2019/10/30(水) 13:39:27.23

>>682
誤：そのごろのローカル変数のアドレスよりも必ず大きい。
正：その後のローカル変数のアドレスよりも必ず大きい。

早い話が、スタックは、上下逆になっていることが味噌。

**デフォルトの名無しさん** · 2019/10/30(水) 16:43:27.90

0 埋め勝手に期待してると
Debug build と Release build の変化ではまるんじゃね

**デフォルトの名無しさん** · 2019/10/30(水) 18:21:24.13

未定義動作に頼って幸せになった人間はいない

**デフォルトの名無しさん** · 2019/10/30(水) 18:25:45.90

問題は未定義動作が多すぎることだ

**デフォルトの名無しさん** · 2019/10/30(水) 19:14:52.52

>>682
> そして、ヒープから確保したオブジェクトのアドレスは、必ずそれらよりも大きい。
スタックエリアとヒープエリアの前後関係なんて決まってたっけ？

**デフォルトの名無しさん** · 2019/10/30(水) 19:53:22.92

c++なら暗黙に0で初期化するところでcだと死ぬ

**はちみつ餃子** ◆8X2XSCHEME · 2019/10/30(水) 20:10:37.29

Boehm GC にスタック・ヒープの範囲を判定する部分があったはず。

**デフォルトの名無しさん** · 2019/10/30(水) 20:42:33.17

>>682
ヒープから確保したアドレスがスタックより大きいっていうのはかなり特殊な環境では？

**デフォルトの名無しさん** · 2019/10/30(水) 20:46:40.08

>>682
スタックとヒープのアドレスに前後関係の縛りなんかねえよ
互いに全く別個のデータ構造で相互に依存関係はない

**デフォルトの名無しさん** · 2019/10/30(水) 21:02:17.94

お前ら甘いぞ
ヒープから確保したメモリをスタックにすることもできるんやで
逆にいうとスタックの情報もとれる
pthread_attr_getstackな

**デフォルトの名無しさん** · 2019/10/30(水) 21:28:56.04

https://ideone.com/Q4ek9R
デストラクタを後から書き換えるってできなかったっけ？

**デフォルトの名無しさん** · 2019/10/30(水) 21:37:47.50

なんで出来ると思ったのか

**デフォルトの名無しさん** · 2019/10/30(水) 21:41:50.59

おまえらはなんですぐ破壊的なメモリアクセスしようとするんだよ。

**デフォルトの名無しさん** · 2019/10/30(水) 21:44:55.49

>>694
なんでだろ・・・。
できなそうだな。さんきゅー。

**デフォルトの名無しさん** · 2019/10/30(水) 21:47:25.90

変にトリッキーなことをせず普通に書けば平和なのに

**デフォルトの名無しさん** · 2019/10/30(水) 21:51:21.63

平和を求めるならc++使わないことだな

**デフォルトの名無しさん** · 2019/10/30(水) 21:56:38.45

>>696
virtualでないと子のデストラクタは呼ばれないってのとごっちゃになってるとか？

**デフォルトの名無しさん** · 2019/10/30(水) 21:57:32.16

>>698
平和は求めるが性能も求めるから仕方なく使うのがc++だよ、馬鹿。

**デフォルトの名無しさん** · 2019/10/30(水) 22:07:52.76

>>699
多分それだ。もやもや取れたわ。ありがとう。

**デフォルトの名無しさん** · 2019/10/30(水) 22:15:48.21

>>700
お前moveだからコピーコストゼロ！カロリーゼロとか言ってるだろ

**デフォルトの名無しさん** · 2019/10/30(水) 22:18:45.46

>>693
正直何をしたいのかさっぱりわからん

**デフォルトの名無しさん** · 2019/10/31(木) 00:30:04.67

>>687
なるほど、想定していたのは、Windows環境限定だった。

**デフォルトの名無しさん** · 2019/10/31(木) 01:11:19.07

>>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 もサポートしてる実装）では保証されているとか、
保証されてないと困るという話ならそうなんだろうとは思うけど。

**デフォルトの名無しさん** · 2019/10/31(木) 07:54:20.46

保証は知らんけどアドレス計算だから1じゃなくてsizeofの値じゃないのそれ
あとだめならベクタで&v[x]みたいのも未定義になっちゃうけども

**はちみつ餃子** ◆8X2XSCHEME · 2019/10/31(木) 12:29:41.78

>>705
俺も仕様としての保証はないと思う。
C の規格を見て関連しそうな項目として

- ポインタを型変換して変換後のアライン (処理系定義) が正しければそれを元の型に再変換したものは変換前と等しい
- ポインタを別のポインタに型変換した後のアラインが正しくなければ未定義
- ポインタを文字を指すポインタに型変換した場合、オブジェクトの最も低位のアドレスを指す
- 文字を指すポインタに変換されたポインタは元のオブジェクトの大きさまで連続して増分すると
　　そのオブジェクトの残りのバイトへのポインタを順次生成できる

(注：ここで言うポインタには関数ポインタを含まない)

という保証は見つけられたので

(((BYTE *)arr) + sizeof(TYPE) * k)

までは妥当な式と言えると思うんだけど、 (TYPE *) というキャストが出来る根拠は見つけられなかった。

**デフォルトの名無しさん** · 2019/10/31(木) 13:00:56.65

>>707
C言語の基礎として、TYPE *ptr に対し、
　ptr + k == (TYPE *)(((BYTE *)ptr) + sizeof(TYPE) * k)
は保証されているはず。

**デフォルトの名無しさん** · 2019/10/31(木) 13:06:36.29

×基礎
○妄想の中の理想世界・ご都合ワールド

**デフォルトの名無しさん** · 2019/10/31(木) 13:21:36.49

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)

**デフォルトの名無しさん** · 2019/10/31(木) 13:43:36.78

C++のヘッダファイルのクラス定義って、
privateまで定義しないといかんのが嫌だな。

privateだから内部に隠蔽されて、外部からは知らなくていい情報なのに
内部で使ってる型をヘッダファイルに書かなければいけないから、
それをincludeしてる方も、その型の存在を知ってしまう。

どうにかならんのかな？

**デフォルトの名無しさん** · 2019/10/31(木) 13:54:48.05

ヘッダに描くのをやめればいい

**デフォルトの名無しさん** · 2019/10/31(木) 14:01:21.28

>>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 は正しい。

**デフォルトの名無しさん** · 2019/10/31(木) 14:04:09.17

>>711
pimpl

**デフォルトの名無しさん** · 2019/10/31(木) 14:46:45.02

>>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)
　に一致する。」
となります。

**デフォルトの名無しさん** · 2019/10/31(木) 14:50:36.73

>>691
言語仕様的には決まっていませんが、Win32で実験する場合、
最初の質問者が、答えを見つける手段としては、正しいやり方なのです。
Win32で実験してヒープからの確保なのかどうか判明してしまえば、同じ
boostのソースを他の環境で動かしても、#ifdef などで動作が変えられていない
限りは、同じ結果となるからです。

**はちみつ餃子** ◆8X2XSCHEME · 2019/10/31(木) 14:53:56.72

>>713
アドレスがどうこうじゃなくてキャストが許されるかっていう話なんだけど。

**デフォルトの名無しさん** · 2019/10/31(木) 15:27:23.28

ポインタのキャストてポインタが指してるアドレスのデータの解釈だけの問題だから許されないキャストがそもそもないのでは
適切かどうかは知ったことではないが

というか配列のデータが連続していれば当然のごとく成り立つ話じゃん
それは保証されてるわけだし

**デフォルトの名無しさん** · 2019/10/31(木) 16:06:33.06

>>714
サンクス。集約を使えば行けるんかいなーとか雑に思っていたが、
そういうイディオムがあるんだな！

**デフォルトの名無しさん** · 2019/10/31(木) 16:29:14.27

>>718
構造体型へのポインタ同士については、単なる解釈し直しではなく、
アドレスの加減算を伴うことがあります。
しかし、BYTE型へのポインタから構造体型へのポインタへのキャストに
ついては、解釈のし直ししか、コンパイルのしようがなく、その場合に
ついては、ポインタの指すオブジェクトがマシン後レベルで同じアドレス
を持つことになります。ただし、厳密な仕様は知りません。

**はちみつ餃子** ◆8X2XSCHEME · 2019/10/31(木) 16:32:02.98

pimpl ってプライベートなメンバを隠したいだけのために導入するのは面倒くさ過ぎない？
手間かけてでもやりたいって場面もあるのかもしれんが、どうにも割に合う気がしない。

**デフォルトの名無しさん** · 2019/10/31(木) 17:07:47.69

どうしても実装を隠さないと発狂する人が使う

**デフォルトの名無しさん** · 2019/10/31(木) 17:11:39.47

unique_ptrで作ればそれだけで勝手にmovableなクラスになって便利だよpimpl

**デフォルトの名無しさん** · 2019/10/31(木) 17:17:39.90

>>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を隠したかったんだよ！

↑
言いたかったことはこれ

**デフォルトの名無しさん** · 2019/10/31(木) 17:29:24.06

>>724
また髪の毛の話してる、などというと荒れそうなので決して言いません。

**はちみつ餃子** ◆8X2XSCHEME · 2019/10/31(木) 17:52:49.82

C++20 でモジュールの機能が入るとかいう話になってるから
それが成れば pimpl なんていらんようになると思うんだが、
実際のところモジュールの様子ってどうなの？ちゃんと入りそう？

**デフォルトの名無しさん** · 2019/10/31(木) 18:23:02.02

無理。
テンプレートとの両立、オーバーヘッドの問題
どの視点でみてもくそなものしかできないことは明白。

こういうのに引っかかるバカが増えたよね。

**デフォルトの名無しさん** · 2019/10/31(木) 18:32:01.00

>>721
そう思うのは複数人で規模のでかいもの作ってないから

**デフォルトの名無しさん** · 2019/10/31(木) 19:37:56.00

pimplは開発規模は関係なくて、ライブラリの公開するヘッダでユーザーに関係ないものを隠すために使わないか？

**はちみつ餃子** ◆8X2XSCHEME · 2019/10/31(木) 20:03:49.64

>>729
それも pimpl の目的としてはあるんだけど、 >>724 が書いているように C++ だとファイルの依存関係が必要以上になることもある。
それをどうにかしたら make で差分ビルドしたときに走るタスクが少なくなるので
規模が大きいプログラムで pimpl を使うとビルドがだいぶん速くなるということはありうる。
規模が小さいと体感するほどの差が出ない。割に合わない。
そういう意味では規模は関係ある。

**デフォルトの名無しさん** · 2019/10/31(木) 20:09:29.87

個人的には、自分ひとりで作ってるプログラムは、高頻度で全ビルドに
かける癖が付いてしまってる。
こうしておくと、OSをSleepモードにしていて、誤って電源を切ってしまったような
時にIDEが管理しているプロジェクトのデータファイルの何かが壊れていても
気付なかった時や、プロジェクトのバックアップ処理の時のコピー操作の何らか
の間違いで何かがおかしくなってしまったようなときに変な不具合に悩まされなく
て済む。

**デフォルトの名無しさん** · 2019/10/31(木) 22:29:01.40

C++とオブジェクト指向をきちんと身につけてる人ばかりの環境ならいいんだけどね、pimpl
経験不足な人だと理解出来なさそう

**デフォルトの名無しさん** · 2019/10/31(木) 22:54:10.87

使ってるうちにインターフェースを使った典型的な奴とそう変わらない事に気付く

**デフォルトの名無しさん** · 2019/10/31(木) 22:58:21.62

継承使いたくないからpimplの方が好き

**デフォルトの名無しさん** · 2019/10/31(木) 23:14:49.56

cpprefjpのサンプルの赤字の部分使い方合ってる？

https://cpprefjp.github.io/reference/memory/allocator_traits/select_on_container_copy_construction.html

**デフォルトの名無しさん** · 2019/10/31(木) 23:43:47.06

確かに、select_on_container_copy_construction(other.alloc_)が正しいような気はする

**デフォルトの名無しさん** · 2019/11/01(金) 00:03:47.15

テンプレート活用のための最適化が全盛期の今 pimpl は時代遅れ。

**デフォルトの名無しさん** · 2019/11/01(金) 00:09:16.78

はいはい

**デフォルトの名無しさん** · 2019/11/01(金) 00:19:47.84

pimplが時代遅れというのなら、それに代わる
依存する必要がない所を断ち切る方法を提示してくれ

**デフォルトの名無しさん** · 2019/11/01(金) 00:24:57.04

>>739
クラスの前方宣言。
テンプレートによるコンパイルエラー回避。

**デフォルトの名無しさん** · 2019/11/01(金) 01:06:00.24

>>739
インターフェースと継承

**デフォルトの名無しさん** · 2019/11/01(金) 03:35:55.36

>>740-741
どちらも型を書くので依存を断ち切れてない

**デフォルトの名無しさん** · 2019/11/01(金) 05:46:43.28

pimplでも型を書くのに、何を言っているんだか
そんなに型を書くのが嫌なら、Cの不透明型でも使ってろ

**デフォルトの名無しさん** · 2019/11/01(金) 06:27:26.52

pimplの目的も方法も全く理解してないって白状したぞこいつ

**デフォルトの名無しさん** · 2019/11/01(金) 06:54:21.26

>>739
目の前のパソコンを窓から投げ捨てます

**デフォルトの名無しさん** · 2019/11/01(金) 07:17:25.47

privateをどうしても隠蔽したいならpimpl使うのもやむを得ないのかも知らんけど、そんな事態になったこと無いからよくわからんな

**デフォルトの名無しさん** · 2019/11/01(金) 07:43:37.38

ライブラリ作る時にstd::unordered_mapとかメンバに使いたいと思わないもんなのか、よくわからんな
pimplで.cppに閉じ込めないとコンパイラやSTLのバージョン違いで壊れるんだけど

**デフォルトの名無しさん** · 2019/11/01(金) 07:44:21.36

>>739
自部屋に引き籠もって外界との依存を断ち切ります。

**デフォルトの名無しさん** · 2019/11/01(金) 07:58:26.02

ライセンスに書いとけば良い
・プライベートは見ないで下さい。お触り禁止。

**デフォルトの名無しさん** · 2019/11/01(金) 08:11:36.17

ただ単に仕様と実装をすっきり分離できるというだけでも充分な動機になる

**デフォルトの名無しさん** · 2019/11/01(金) 08:20:42.72

>>747
> pimplで.cppに閉じ込めないとコンパイラやSTLのバージョン違いで壊れるんだけど
ん？どう言うこと？
なんかやり方間違えてね？

**デフォルトの名無しさん** · 2019/11/01(金) 08:22:07.06

>>750
private部分を見なきゃいいだけだろw
そもそも実装は.cppに書くんだし

**デフォルトの名無しさん** · 2019/11/01(金) 08:25:35.79

エディタが貧弱だったころの名残を未だに引き摺っている
仕様と実装を分離したらそれだけでファイルが倍に増えて管理が面倒になる
仕様はソースコードから逐次自動生成すればいい
なので昨今の言語はIDEに迎合していて、暗黙の大前提でIDEでの運用が見込まれている
それ単体で成り立つものでは無くなっている

**デフォルトの名無しさん** · 2019/11/01(金) 09:01:23.35

因果関係を理解できない人ってプログラマ向いてない

**デフォルトの名無しさん** · 2019/11/01(金) 09:41:29.48

class Util() {
public:
　　int aaa();
　　std::string bbb();
private:
　　MinorClass mc;
　　MinorClass mc zzz();
}

こういうユーティリティクラスがあって便利だなーって思ったときに、
便利だと思うのはaaaメソッドとかbbbメソッドであって
内部で使ってるMinorClassとかどうでもいいねん

Utilクラスのインクルードファイルはインクルードしたいけど
MinorClassのインクルードファイルはインクルードしたくないねん
そんなもんインクルードしたらMinorClassが変更になっただけで
Utilクラス使ってるところも変更になるやろ？

**はちみつ餃子** ◆8X2XSCHEME · 2019/11/01(金) 10:06:12.42

>>755
そこをわからんって言ってるやついないんだよ。
わかった上で変更になったらどんくらい問題なんや？別にええやろ。と言う場面の方が多いという話なんだよ。
pimpl が有用な場面があるっていう主張もわかるよ。わかるけど、そういう場面に遭遇したことないなぁという話なんだよ。

**デフォルトの名無しさん** · 2019/11/01(金) 10:29:23.31

>>755
それだけならMinorClassを前方宣言するだけでincludeいらない

**デフォルトの名無しさん** · 2019/11/01(金) 10:32:58.37

>>757
MinorClassの実体をメンバにするなら前方宣言じゃだめ
ポインタなら前方宣言にできる

**デフォルトの名無しさん** · 2019/11/01(金) 10:33:41.18

Utilはあるライブラリの公開クラスです
MinorClassは標準ライブラリのテンプレートクラス(例えばstd::unordered_map<Hoge>)です
Aさんはとあるコンパイラver1.0でコンパイルしたライブラリのバイナリとヘッダーを配布しました(ソースは配ってない)
10年後にBさんがこのライブラリのバイナリを入手して使おうと思いました
その間にコンパイラの標準ライブラリも劇的な進化を遂げ、コンテナの内部構造に大幅な改良を加えて超高速化したと宣伝していました
Bさんはヘッダーをincludeしてコンパイラver8.0でビルドしました

さーて何が起こる？Utilがpimplだとどうなる？よくよく考えよう

**デフォルトの名無しさん** · 2019/11/01(金) 10:43:47.44

>>758
そんなんかすまん
勘違いしてた

**デフォルトの名無しさん** · 2019/11/01(金) 11:01:10.12

privateメンバをポインタ型にする手間や不都合とpImplの手間や管理コストのどっちを取るかだろうな
基本的には継承するクラス以外のincludeは排除できる
ヘッダ内部での外部ライブラリのincludeは可能な限り避けるべき

**はちみつ餃子** ◆8X2XSCHEME · 2019/11/01(金) 11:10:39.87

>>760
オブジェクトを生成するには「大きさの情報」が必要だと覚えておくとわかりやすいと思う。
クラスの内容がわからないと大きさが確定しないから生成できないけど、ポインタの大きさはわかる。

**はちみつ餃子** ◆8X2XSCHEME · 2019/11/01(金) 11:11:24.16

>>759
そういう状況があることはわかるよ。
でもそんなことしねーよって話なんだってば。

**デフォルトの名無しさん** · 2019/11/01(金) 13:00:57.84

>>763
それお前個人がしたことないって言う経験談？
それとも他の代替手段を取るってこと？
先に言っておくと前者ならすっこんでろ

**はちみつ餃子** ◆8X2XSCHEME · 2019/11/01(金) 13:23:21.41

>>764
俺がしたことないという経験談だが、
ここで pimpl が割に合わないと出ている意見は
そういう状況があんまりないという内容だということの説明でもある。

そういう状況で必要だってのはわかってるし、
そういう状況にあるなら使えばいいよ。
それはわかってるんだよ。
だからしつこく説明しないいよっていう話。

**はちみつ餃子** ◆8X2XSCHEME · 2019/11/01(金) 13:29:29.85

要するに >>759 はまるで見当はずれのこと言ってんなぁという感想。

**デフォルトの名無しさん** · 2019/11/01(金) 14:32:22.73

単機能ライブラリ作って渡す仕事してる人にとっては日常なんで、検討外れとか抜かされても勝手なこと言ってんなあとしか
まあ、OSSしかやらないとか、最終の実行バイナリしか作らないとか、そもそも個人プレーで人にプログラム成果物渡したりしないとかなら、
pimplの価値わからんという気持ちになるのはしょうがないし、それが世界の全てだと思っちゃうのかもな

**はちみつ餃子** ◆8X2XSCHEME · 2019/11/01(金) 14:59:10.92

>>767
それが全てといってるわけじゃなくて、
pimpl がどうしても必要！と言ってる人こそライブラリ販売の世界しか見てないという話をしてんの。

**はちみつ餃子** ◆8X2XSCHEME · 2019/11/01(金) 15:01:01.21

いる場所ではいるし、いらない場所ではいらないという当たり前のことしか言ってないつもりなんだけど。

**デフォルトの名無しさん** · 2019/11/01(金) 15:04:22.58

全員知らないことの方が多いのに相手が自分の分野のことを知らないと無知扱いするのは草生える

**デフォルトの名無しさん** · 2019/11/01(金) 16:16:45.44

>>759
そもそもVer. 1.0でコンパイルしたクラスライブラリをVer. 8.0でコンパイルしたオブジェクトとリンクできるの？
10年間互換性保ってるC++コンパイラの名前教えてくれるかなw

**デフォルトの名無しさん** · 2019/11/01(金) 18:28:24.75

動的リンクなら古いコンパイラでコンパイルしたライブラリが使えるかどうかはOSの互換性次第だろ

**デフォルトの名無しさん** · 2019/11/01(金) 18:36:37.94

>>766
一般的な現象よ
周回遅れのやつに絡まれたらキョトンとしちゃうやろ
今の餃子ちゃんがまさにそれよ
幼稚園児に絡まれたお兄さんみたいになっとる

**デフォルトの名無しさん** · 2019/11/01(金) 18:38:39.54

あぁ、メモリーレイアウトでずっこけるやつか。

**デフォルトの名無しさん** · 2019/11/01(金) 19:03:19.99

>>772
マングリングって知ってるか？
そもそもC++のクラスライブラリを簡単に動的リンクできるOSってあるのか？w

**デフォルトの名無しさん** · 2019/11/01(金) 19:25:46.93

まんぐりがえし

**デフォルトの名無しさん** · 2019/11/01(金) 19:41:21.97

comはクラスライブラリになるのかな
いろいろ面倒だけど

**デフォルトの名無しさん** · 2019/11/01(金) 19:44:45.43

念のため確認だけど、pimplの代替手段については把握されてる前提でOK?
http://site.oukasei.com/?p=148

**デフォルトの名無しさん** · 2019/11/01(金) 19:56:12.78

リンク問題はABIの話だよな？
それはリンカのオプション次第じゃないのん？

**デフォルトの名無しさん** · 2019/11/01(金) 20:26:50.93

>>779
広い意味だとABI
リンカのオプションで前のバージョンに対応してるとかの例もあるけど10年前まで対応してる例とかあるのかな？

**デフォルトの名無しさん** · 2019/11/01(金) 20:51:10.72

>>778
結局、pimplのI/F用外側クラスを基底クラスに、implを派生クラスにするってだけでやってることはpimplと同じ
むしろ以下の点でより悪い
・I/F用のクラスと実装用のクラスに不必要な継承関係が導入されていらない複雑度が増える
・↑と同じことだが、実装用クラスがI/F用クラスと同じメンバ関数を実装することが強制される
・コンストラクタが使えず、独自のファクトリ関数の使い方を利用者に覚えさせる必要がある
・利用者に生ポが露出する。生ポを避けたい利用者は自分でunique_ptrなどで包まなければならない
・I/F用クラスを利用者が勝手実装して混入させることを許す

上に挙げたのはポリモさせたい場合はメリットでもあるんだが、ポリモを意図しない単独クラスに継承構造なんか入れるべきではない

**デフォルトの名無しさん** · 2019/11/01(金) 21:03:35.70

いっそのことヘッダオンリーライブラリにしようぜ