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/29(火) 01:43:16.61

そもそも文字コードどうなってるんやーーーー
コマンドプロンプトに出す時、どうするんやーー
現在のchcpの設定に従って変換線といかんのカーーーーーー

**蟻人間** ◆T6xkBnTXz7B0 · 2019/10/29(火) 02:28:13.51

変換なんてWideCharToMultiByte使って一つ変換関数作ってその関数を使い回せばいいやん。

**デフォルトの名無しさん** · 2019/10/29(火) 02:42:32.11

WriteConsoleW

**デフォルトの名無しさん** · 2019/10/29(火) 04:01:15.69

>>640
Unicode文字列（絵文字とか）が文字化けするんだよー！
フォントの問題でないことは確認済み

**デフォルトの名無しさん** · 2019/10/29(火) 04:07:41.50

例えばググって見つけた、こことか
http://www.t-net.ne.jp/~cyfis/win_api/sdk/WideCharToMultiByte.html

wchar_t を const wchar_t にするのはまあいいとして、
日本語はOKだけど絵文字とか化けるじゃねーか
わーけわかねなんｄｆっｒね；ｊｋ

**デフォルトの名無しさん** · 2019/10/29(火) 04:13:15.89

ん？WideCharToMultiByteってShiftJISに戻すやつじゃねーのか？
俺はUnicode文字すべてを表示したいだけだぞ

**デフォルトの名無しさん** · 2019/10/29(火) 04:20:56.50

chcpくらい使えよ

**デフォルトの名無しさん** · 2019/10/29(火) 04:26:03.90

windowsのコマンドプロンプトはまだ絵文字とかに対応してないよ

**デフォルトの名無しさん** · 2019/10/29(火) 04:29:31.79

>>646
全てではないだろうけど対応してる。
❥
↑文字化けしそうだけど、横向きのハートとか
❤ とか

**デフォルトの名無しさん** · 2019/10/29(火) 04:29:44.12

お、文字化けしなかったｗ

**デフォルトの名無しさん** · 2019/10/29(火) 04:30:10.10

?????
Jane経由だとだめだろうな

**デフォルトの名無しさん** · 2019/10/29(火) 04:31:42.98

>>645
chcp 65001にしてもムダだったぞ

**デフォルトの名無しさん** · 2019/10/29(火) 04:54:41.95

コマンドプロンプトよりJaneは早く絵文字に対応しろ

**デフォルトの名無しさん** · 2019/10/29(火) 05:06:04.44

>>650
それutf8じゃねーか

**デフォルトの名無しさん** · 2019/10/29(火) 05:14:54.35

>>652
ぐぐってからいえｗｗｗ

**デフォルトの名無しさん** · 2019/10/29(火) 05:19:50.17

なんでコードページ932なのに、NSimSunにすると
日本語以外もちゃんと表示できるのかわからない

**デフォルトの名無しさん** · 2019/10/29(火) 05:26:40.69

wcharがutf8なのか？あほか？

**デフォルトの名無しさん** · 2019/10/29(火) 05:36:55.26

Visual StudioのソースコードのデフォルトはBOM付きUTF8なんだな

**デフォルトの名無しさん** · 2019/10/29(火) 06:38:53.94

Windows依存の話は、以下すれでどうぞ。

Win32API質問箱 Build125
https://mevius.5ch.net/test/read.cgi/tech/1551247748/

**デフォルトの名無しさん** · 2019/10/29(火) 12:08:17.89

自分の理解と違ってたので教えてください。

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でも同様の結果でした。

**はちみつ餃子** ◆8X2XSCHEME · 2019/10/29(火) 12:09:55.91

>>658

RVO でググって

**デフォルトの名無しさん** · 2019/10/29(火) 12:10:21.23

最適化で消された

**デフォルトの名無しさん** · 2019/10/29(火) 12:14:30.49

>>659
まさにピンポイントでした。
ありがとうございます。

**デフォルトの名無しさん** · 2019/10/29(火) 13:58:53.43

>>636
node.js

**はちみつ餃子** ◆8X2XSCHEME · 2019/10/29(火) 13:59:57.20

>>636
マイクロソフトのコンパイラならまあまあ補助があったりするでしょ。
それでも面倒くさいことにかわりないけど。

**デフォルトの名無しさん** · 2019/10/29(火) 15:55:18.54

失礼します。テストです：
ハート：❤
横向きハート：❥

**はちみつ餃子** ◆8X2XSCHEME · 2019/10/29(火) 16:08:16.15

>>664
失礼な奴だな！

**デフォルトの名無しさん** · 2019/10/29(火) 18:43:54.18

>>663
補助なんてあったっけ？
まあ俺の知識はもう5年以上前の知識だから最近はちょっとはマシになったのかな

**デフォルトの名無しさん** · 2019/10/29(火) 21:55:11.67

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が入ってるんだけど、
これは、どのハードウェアでもこうなると仕様と決まってるの？

**デフォルトの名無しさん** · 2019/10/29(火) 22:07:48.92

>>667
決まってない。
範囲外のアクセスなので、本来は絶対にやってはいけない。
読むだけでも不法例外が起きてしまう可能性もあるが、
書くのはもっとダメ。
たまたま、コンパイラシステムが何らかの目的で使っている
グローバル変数が arr 配列の直前にい配置されていて、
それが0になっているか、padding領域がたまたまそこにある
だけだと考えられる。

**デフォルトの名無しさん** · 2019/10/29(火) 23:33:23.00

.bssは0初期化されてる

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

オブジェクトがスタックに作られてるかヒープに作られてるかってどうやって調べるの

具体的にはboostのmulti_arrayがどっちに作られてるか知りたい

**デフォルトの名無しさん** · 2019/10/30(水) 06:54:34.02

>>668
そりゃそうか。０で埋まってりゃコードが少し短くなって助かるんだが、まあやめとこう。

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

>>670
アドレスでわかる
正しくはリンカからロケーションを取得だが
簡易的には自動変数のアドレスと上の方の桁が同じかどうかでも見当はつく

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

>>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のそれぞれはまとまった
領域のアドレスを使っているので、推定ではなく断定できる。

**デフォルトの名無しさん** · 2019/10/30(水) 09:33:17.69

どう考えてもヒープだろ

**デフォルトの名無しさん** · 2019/10/30(水) 09:45:24.54

>>670
ローカルスコープだけがスタック。
newしたものはヒープ。

**デフォルトの名無しさん** · 2019/10/30(水) 11:38:54.67

コンテナの場合はスタックに置いたつもりでも、コンテナがデータ部分を内部でnewするとかそういう話だろ

**はちみつ餃子** ◆8X2XSCHEME · 2019/10/30(水) 12:07:14.45

>>667-668
仕様上は配列の範囲外を指すポインタを作るのさえも未定義。
たとえアクセスしなくても。
なので、 ptr-1 という式の時点で未定義動作になる。

ただし、アクセスしないなら配列の最後の要素より一個うしろを指すポインタを作るのは許される。
つまりこの例で言えば ptr+2 や &ptr[2] は有りだけど ptr[2] は駄目。

&ptr[2] は ptr[2] に対して & を付けているので一見すると途中で ptr[2] を評価しているように見えるけど、
・ ptr[2] は (*(ptr+2)) の構文糖である
・ * の結果に & を適用している場合には * も & も評価されず、両方とも取り除いたのと同じことになる
というルールの合わせ技によって &ptr[2] は ptr+2 と同じ意味になる。

ちなみに、配列ではないオブジェクトは要素が一個の配列と同じレイアウトを持つことは保証される。

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

>>677
&*p を p とみなす特別ルールは C の規格にあるけど C++ には無かったりする。
もう１０年以上審議中。 https://wg21.cmeerw.net/cwg/issue232

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

>>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)
の式が常に厳密に成り立つことが保証される。

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

>>678
operator&(), operator*() をユーザーが定義した場合には、それに従うが、
定義しなかった場合、&*pX == pX がどんなポインタ pX についても
成り立つことは保証されるはず。

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

>>670
一般的なPC環境なら、
適当に用意した別の関数を呼び出して(multi_arrayのインスタンスがまだ有効で、インスタンス生成したスレッドと同一スレッドからなら、どこから呼び出してもよい)、
その関数のローカル変数のアドレスよりも&multi_array[0]の値のほうが大きければ、multi_arrayのデータ領域はスタックに確保されたと判断できるのでは

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

>>681
自分も最初、同じような勘違いをしていたが、
シングルスレッドの場合に限定すれば、
スタックの構造からすれば、最初に確保したローカル変数のアドレスが、
そのごろのローカル変数のアドレスよりも必ず大きい。
そして、ヒープから確保したオブジェクトのアドレスは、必ずそれらよりも大きい。
なので、後から別の関数を呼び出す必要はない。
main()関数の中で最初に定義したローカル変数のアドレスが分かればそれで十分。

**デフォルトの名無しさん** · 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が時代遅れというのなら、それに代わる
依存する必要がない所を断ち切る方法を提示してくれ