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/11/02(土) 10:06:09.13

void*からC++クラスのポインタ型にstatic_castってできたっけ、

**デフォルトの名無しさん** · 2019/11/02(土) 10:12:48.91

出来るよ
多態使いたかったらbase ptrとvoid*の相互変換をする

派生ptrからvoid*に直接変換すると危険

**デフォルトの名無しさん** · 2019/11/02(土) 10:18:39.64

>>806
安全性と危険性が反対くね？
void*が指すアドレスは構造体やクラスの境界に整列している保証が無いのでは…

>>804
WIN32の内部において、ハンドルが単なるindexでなくポインタとして使われているという根拠は？
確かに正体がvoid*だったりするが、ポインタだとしたらOS視点では
INVALID_HANDLE_VALUE判定が
難しくなるのであった、（一般論として

**デフォルトの名無しさん** · 2019/11/02(土) 10:20:03.47

>>800
だからおまえがな

**デフォルトの名無しさん** · 2019/11/02(土) 10:21:28.65

static_cast<void*>は最派生クラスにダウンキャストだね

**デフォルトの名無しさん** · 2019/11/02(土) 10:27:48.65

>>807
外見維持してることが重要なんであって中身でなにをどうしてようがはどうでもいいがな

**デフォルトの名無しさん** · 2019/11/02(土) 10:28:34.71

やべービルド通るわこれ
うちのコンパイラは壊れてるな…
int g_nSomeValue;
int main()
{
int* p = &g_nSomeValue;
int* q = static_cast<int*>(p);
printf("p=0x%p\n", q);

return 0;
}

**デフォルトの名無しさん** · 2019/11/02(土) 10:30:01.86

貼りまつがえた、
誤： int* p = &g_nSomeValue;
正： void* p = &g_nSomeValue;

**デフォルトの名無しさん** · 2019/11/02(土) 10:39:33.14

void*は型情報が完全に消えるから、
型が完全に一つだとわかっているならそのままstatic_castすればいい

多態だと派生型からvoid*に直接変換してしまうと、void*から戻す場合に基底ポインタには戻せる保証がない

**デフォルトの名無しさん** · 2019/11/02(土) 10:39:40.95

>>802
依存している構造体のサイズやレイアウト変わったらアウトだろ

**デフォルトの名無しさん** · 2019/11/02(土) 10:45:21.22

>>803
C++でラップしてる時点で中途半端なのはかわらない
むしろ手間増えてる

**デフォルトの名無しさん** · 2019/11/02(土) 10:46:18.05

過去の遺産のCOMなんて使いにくいて横で話ししてるやろ
10年後の環境のことまで気にする必要ないんだよ
ばっさり捨ててその時代にあったものを作るべき
無理に資産転用とか互換性とか気にするからクソが生まれる

**デフォルトの名無しさん** · 2019/11/02(土) 10:47:10.74

pimplで実装隠したところで、
引数に例えばstd::string使うだけでコンパイラバージョン変えたときの保証は無くなるしなぁ

**デフォルトの名無しさん** · 2019/11/02(土) 10:56:15.43

要するに>>759は知ったかが無理矢理考えたアホストーリーと言うことでいいかな？w

**デフォルトの名無しさん** · 2019/11/02(土) 10:57:17.10

>>808
ああ、もうそういう返ししかできないのか…
高い理想とか笑えるわw

**デフォルトの名無しさん** · 2019/11/02(土) 11:06:42.79

>>814
pimplだと構造体の実装はライブラリ側に完全隠蔽なのでその観点はおかしい
つかｊコンパイラのバージョンも関係無い

**デフォルトの名無しさん** · 2019/11/02(土) 11:16:21.46

>pimplだと構造体の実装はライブラリ側に完全隠蔽なのでその観点はおかしい
何が言いたいのかというとライブラリ使用側がライブラリが依存する構造体メンバに直アクセスする前提なら
そんなライブラリはpimplにできんだろとゆーこと
つまりpimpl対非pimplの比較の想定が変
非pimpl条件のライブラリのインターフェース仕様だけ抽象度を下げて議論しても仕方が無い

**デフォルトの名無しさん** · 2019/11/02(土) 11:16:32.42

>>816
そんなライブラリ誰が使いたがるんだよ

**デフォルトの名無しさん** · 2019/11/02(土) 11:23:46.22

オープンソースやクローズドでも社内での話だったらソースごと提供すれば終わる話だし
社外提供なら多言語で使えるようにcのAPIを出すのが普通じゃないのか
その上で各言語用のラッパーも提供されるってのがありがちなパターン

**デフォルトの名無しさん** · 2019/11/02(土) 11:37:12.15

>>822
現時点で有用なら使うでしょ
逆に10年前からメンテされてなくて現時点でも使われてるライブラリなんてある？
メンテされてるかよりその時代に即したものに乗り換えてくでしょ

**デフォルトの名無しさん** · 2019/11/02(土) 11:50:05.18

いやメンテなり機能追加はしろよ
仕様がらっと変わるのわかってるもんなんて使いたくないわ
作り手も使う側めんどいだろ

**デフォルトの名無しさん** · 2019/11/02(土) 12:26:20.48

D なぜ流行らなかったし
Go 突き抜けてる
Rust ちょっと意識高い系
Nim 有望
JULIA 話にならない

**デフォルトの名無しさん** · 2019/11/02(土) 12:50:14.99

>>824
ライブラリじゃないけど例えばExcel2003とかまだCOM経由なら動かせるでしょ
COMの泥臭いインターフェースだから面倒だけどね

**デフォルトの名無しさん** · 2019/11/02(土) 12:54:19.41

>>827
動かせるけどクソだよね？
だから新しいのつかうじゃん？
つうかoffice系は延々と互換性意識してメンテされ続けてるじゃん

**デフォルトの名無しさん** · 2019/11/02(土) 13:22:43.30

>>828
俺が言ってるのはCOMの話な
Excelの話はケースバイケースだからなんとも言えんし俺には関係ないからどうでもいい

**デフォルトの名無しさん** · 2019/11/02(土) 13:28:52.76

>>829
COMの中身詳しくないんだけど一切メンテされてないの？
今までwinは山ほど脆弱性をupdateしてるけど、そういう中にCOM周りの修正とかなかったの？
間違いなくあったと思うんだよね。
COMに限らず現状使えるMS産のもので10年間内部が未修正のものなんて多分存在しないんじゃない？
だから10年後のことだけなんて考慮する必要なくて将来に渡り有益ならどうせメンテされるし一時的なもので将来無益になるなら消え去るんだよ

**デフォルトの名無しさん** · 2019/11/02(土) 13:32:28.90

>>829
なんか前後で俺の主張がずれてる感じで申し訳ない

**デフォルトの名無しさん** · 2019/11/02(土) 13:52:05.38

>>830-831
インターフェースの話とインターフェースの先にあるライブラリとかCOMサーバーの話をごっちゃにしてないか？

**デフォルトの名無しさん** · 2019/11/02(土) 14:07:55.01

>>821
勘違い甚だしい
ライブラリ使用者に無関係で見せたくないからpimplで隠すという話をしてる隠さなかったら無用にincludeが増えるし、最悪そのinclude先の仕様変更で互換がくずれる場合もあると

**デフォルトの名無しさん** · 2019/11/02(土) 14:12:10.51

>>823
そう、それが結局いまだによくも悪くもベストプラクティス
わかってないやつ多いんだよ
いきってc++で自称モダンな設計で作り上げてあとで泣きながらcのインタフェース作るはめになる
たいてい機械的なラッパーではすまないからな

**デフォルトの名無しさん** · 2019/11/02(土) 14:34:01.62

void*的な「ハンドル」を経由して操作するやーつ
C由来のインターフェースは強いな

**デフォルトの名無しさん** · 2019/11/02(土) 14:53:41.66

>>827
> ライブラリじゃないけど例えばExcel2003とかまだCOM経由なら動かせるでしょ

Excelとか以前に、DirectXやシェル（エクスプローラー）そのものがCOMだから

**デフォルトの名無しさん** · 2019/11/02(土) 14:55:12.97

>>832
そうそう。脆弱性の話はCOMじゃなくてDCOM。

もちろんCOMも脆弱性とは無関係ではないんだけど、
それはC++がバッファーオーバーフローと無関係ではないのと
同じようにCOMの設計自体の問題じゃない

**デフォルトの名無しさん** · 2019/11/02(土) 15:00:15.19

ComPtr使ってる？

**デフォルトの名無しさん** · 2019/11/02(土) 15:04:46.15

Essential COMの第1章で、C++からいかにしてCOMに至るか書いてあるけど、あの流れすごい好き

**デフォルトの名無しさん** · 2019/11/02(土) 15:07:11.40

std::filesystem はようやくできたかって感じだが、環境変数でまたorz

なんでこう、使う道具がまともに作られてないんだろうな
C++はメモリ管理ばっかり気にしてる気がする。

**デフォルトの名無しさん** · 2019/11/02(土) 15:09:57.95

>>836-837
> Excelとか以前に、DirectXやシェル（エクスプローラー）そのものがCOMだから
だからCOMとその先を区別してくれよ
COM自体は単なるインターフェース規約で実装は別
脆弱性とかは実装の不具合だから見つかり次第修正されてる
インターフェース規約も仕様バグとかありうるけどCOM自体の仕様バクは聞いたことない

**蟻人間** ◆T6xkBnTXz7B0 · 2019/11/02(土) 15:13:34.66

　　　　　　　　　　　　　　　　　　　＿
　　　　　　 .:⌒: 、　__　＞: : : : : : :.　　＜
　　　　　　　　 |: : : :/´ : : : : : : : : : : : : :. 　　　｀ﾞ　　､　
　　　　 ‐.､／: : : : : : : : : : : : : : : : : : : i　　　　　　
　　　　　У: : : : : : : : : : : : : : : : : : : : :/　　　　　　　＼
　　　　　/: : : : : : : : : : : : ', : { : : : : : : :}　　　　　　　　 __　　＼　　
.　　　ｊ: : ;彡': : : : : : : : : ' : ', : : : : : ﾘ　　　　／ : : : : : : . .　＼
　　　　 : : : : : : : : : : : : : : : }: :ト : : : : ′　　　 /: : : : : : : : : : : ヽ　'.
　　　　: : : : : : : : : : : : : : :ノ :∧: : : : { 　　　 / : : : : : : : : : : : : : : ｖ
. 　　 i: : : : : : : : : : , ‐＜＞: :∧: : : :',　＞‐:'―: : : : : : : : : : : : : : :.
. 　　 | : : ／⌒y:／　　 /: : : : : _ヽ: : ／: ヽ: : : : : : : : : : : : : : : : : : :|
　　　八: : {　　^　　　 {: : : Ｙ´ 　 ∨: : : x ― - . . __: : : : :__, : : : : }
　　　　ｰ′　　　　　У: : j　　　 {: : : ﾉ　／: : : : : : :￣: : : : : : イ
　　　　　　　　　　〈: : :/＾　　　ｰ^ ／ : : : : : : : : : : : : : ＜
　　　　　　　　　　　　 ^彡　　　　　 /: : :ヽ -‐=　　￣￣
　　　　　　　　　　　　　　　　　　　 {: : :ノ
　　　　　　　　　　　　　　　　　　　　　ゞ´

**デフォルトの名無しさん** · 2019/11/02(土) 15:31:17.24

>>841
俺に言うなよ。俺はCOMは使われてるとしか言ってない。
シェル（エクスプローラー）をCOMで操作できるという
基本的な機能の互換性をなくすとか考えられん。

**デフォルトの名無しさん** · 2019/11/02(土) 15:36:48.55

>>840
環境変数は昔から標準化されてるだろ。設定は微妙だけどデファクト標準関数があるし。

**デフォルトの名無しさん** · 2019/11/02(土) 15:56:49.53

>>844
std::cout << なんとか("PATH");
のように一行でやる方法教えて
もちろん脆弱性などで非推奨と言われるようなやり方は禁止

俺はここまでできて「使える道具」だと思ってるよ

**デフォルトの名無しさん** · 2019/11/02(土) 16:32:02.24

>>843
だからCOMの話にその先であるエクスプローラの話を混ぜるなよ…
ところでExplorerってCOMで操作できたっけ？
Internet Explorerの話じゃないよね？

**デフォルトの名無しさん** · 2019/11/02(土) 16:32:29.90

>>845
なぜに一行縛りなの？

**デフォルトの名無しさん** · 2019/11/02(土) 16:50:16.72

OpenStack, Terraform でも、クレデンシャルなどの環境変数は、1つのファイルにまとめる

それでプログラム内で、os.environ[ 'OS_PASSWORD' ]
みたいに取得する

直接、設定ファイルに書いて、git に保存するのは禁止！

**デフォルトの名無しさん** · 2019/11/02(土) 17:09:24.74

>>845
curl
env()

**デフォルトの名無しさん** · 2019/11/02(土) 18:41:30.33

>>847
実現可能な最小の行数

（一行でできるようにすることは他の言語で実現されてることからも明らか）

**デフォルトの名無しさん** · 2019/11/02(土) 18:44:29.21

ちなみにさっきオレオレで20行ぐらいの関数を書いて
一行で環境変数を取得できるようにしたよ。
でもこういうのは標準ライブラリで用意してあるべきもの

**デフォルトの名無しさん** · 2019/11/02(土) 18:44:52.66

こいつアホだろ

**デフォルトの名無しさん** · 2019/11/02(土) 18:46:14.06

>>850
短ければ偉いとか思ってる？w

**デフォルトの名無しさん** · 2019/11/02(土) 18:48:21.60

>>853
俺が思ってるかどうかじゃなくて、
お前が、こういう理由で短いのがいい or だめと
"お前の意見" を書け

**デフォルトの名無しさん** · 2019/11/02(土) 19:23:54.18

いや、お前がそう思ってるならいいんじゃね？w

**デフォルトの名無しさん** · 2019/11/02(土) 20:10:41.91

ん？反対意見があるんじゃないのか？
ないんだね。

お前がなにか思ってるだけかよｗ

**デフォルトの名無しさん** · 2019/11/02(土) 20:16:14.52

この手のバカでもたった20行で作れるんだろ
やっぱりC++は偉大じゃないか

**デフォルトの名無しさん** · 2019/11/02(土) 20:17:34.65

車輪の再発明。ってか他の言語使ったほうがいいよ。

**デフォルトの名無しさん** · 2019/11/02(土) 20:28:57.58

>>845
だったらはじめから「僕はこうじゃなきゃヤなんだー」って言ってくれないと何も伝わらないぞ

**デフォルトの名無しさん** · 2019/11/02(土) 20:32:42.04

はじめから言ってる

> std::cout << なんとか("PATH");
> のように一行でやる方法教えて

**デフォルトの名無しさん** · 2019/11/02(土) 20:36:29.98

> 車輪の再発明

典型的なアイディアキラー！　マジ死ねよ

ガタガタくだらねえこと言ってねえで
本能のままにやってみたいことに暴走しなきゃ
何もできちゃ来ねえんだよ

そういう生産物の上にあぐらかいて怠けているゴミ共にわかるわけねえ！

**デフォルトの名無しさん** · 2019/11/02(土) 20:42:10.52

std::filesystemができたように、
std:envも作れってだけの話なのにね
何がそんなに気に触ったんだろう？

**デフォルトの名無しさん** · 2019/11/02(土) 20:49:43.64

>>860
はあ？845が初出じゃん

getenvでいいだろ。
未定義時のエラー処理まで自動でやってほしいのか？

**デフォルトの名無しさん** · 2019/11/02(土) 20:58:09.22

一行じゃないとヤダとか条件を後出ししたからじゃね

**デフォルトの名無しさん** · 2019/11/02(土) 21:01:20.92

> 何がそんなに気に触ったんだろう？

とぼけてんなよ、はっきり書いてんだろ
車輪の再発明と貴様はほざいた
撤回も修正も今さらいらねえ

**デフォルトの名無しさん** · 2019/11/02(土) 21:08:11.55

>>864
そんな下らないことで（笑）

一行とかそんなの重要なところじゃなく、
stdの名の元でまともなライブラリを作ってくれって話だよ
仮にも「標準」ライブラリなんだからさ

昔ながらのgetenvやその安全版はstd:stringが使われてないし、
std::getenvも、なぜかstd::stringではなくchar*が使われていて
使うとエラーとされるレベルの非推奨関数だし、当然ワイド文字版もないし
使おうと思った人なら、まともじゃないの意味ぐらいわかるはず

あ、使ったことない人が噛み付いてきたのかｗ

あと環境変数の未定義は正常な状態としてありえるのでエラーではない
細かくてすまんなｗ適当な発言は気になるんだよ。

**デフォルトの名無しさん** · 2019/11/02(土) 21:09:21.56

>>865
噛み付いてばかりじゃなくて、"自分の意見"を言うだけの
知識はあるのかい？

**デフォルトの名無しさん** · 2019/11/02(土) 21:11:47.48

c++の標準ライブラリにプラットフォーム抽象の機能求めるってのは筋が悪いんだよ
filesystemだって結局はposixをテンプレートの味付けで焼き直した程度でファイルの監視もできないだろ
envとか別に標準で提供されなくても何も困ってない
1行かどうかなんてさらにどうでもいい
あと標準ライブラリが提供する範囲の機能で足りてるアプリ作ってるやつは
c++以外の言語使うことを考えた方がいい

**デフォルトの名無しさん** · 2019/11/02(土) 21:29:52.49

>>856
> お前がなにか思ってるだけかよｗ
うん、バカな縛りだなと思ってるw

**デフォルトの名無しさん** · 2019/11/02(土) 21:36:05.57

組み込み系なんてenvどころかfilesystemとかそもそもねぇの普通な環境も多いしね

**デフォルトの名無しさん** · 2019/11/02(土) 21:56:35.34

>>867
本能の枯れた人生の搾りかすめ

**デフォルトの名無しさん** · 2019/11/02(土) 22:00:29.09

ここは毎回しょうもないことで荒れるな
これだからC++界隈って嫌い

**デフォルトの名無しさん** · 2019/11/02(土) 22:07:02.10

まあもともと広いレンジで使われることを目的とした言語だし
いろんな輩が入ってくるのはしゃーない。
しかしc++11以降は明らかに開発してないクソガキが増えたなという印象はある。

**デフォルトの名無しさん** · 2019/11/02(土) 22:52:35.22

ないなら作りゃいいのに
なんのためプログラミングなんだろか

**デフォルトの名無しさん** · 2019/11/02(土) 22:57:03.69

せっかくhas_includeみたいなのも出来たのだから、環境ごとに存在しない場合機能提供されないようなものも標準化進めていったらいいんだよね

**デフォルトの名無しさん** · 2019/11/02(土) 22:57:09.83

2chのゴミスレ＝C++界隈

**デフォルトの名無しさん** · 2019/11/02(土) 23:15:11.30

>>876
そこに涌く小バエ

**デフォルトの名無しさん** · 2019/11/02(土) 23:38:30.50

>>876 >>877
場所そのものを馬鹿にするのはよくない。
それは差別や権威主義を生み易い。

**デフォルトの名無しさん** · 2019/11/03(日) 00:27:38.19

>>875
一応フリースタンディング処理系っていう分類があるのでそれはもうされてる

◆QZaw55cn4c · 2019/11/03(日) 21:55:47.13

>>732
一つ教えてください、pimpl とか何べん読み返しても「利益の源泉」がわからないのですが、一つ一言で言い切っていただけませんか？

◆QZaw55cn4c · 2019/11/03(日) 21:58:20.86

>>775
＞マングリングって知ってるか？
＞そもそもC++のクラスライブラリを簡単にリンク

私は Java も ruby も触っていますが、お手軽に java のライブラリを c++ から使いたいと、ふつふつ、と、思っているのです…

**デフォルトの名無しさん** · 2019/11/04(月) 00:16:08.68

>>880 （732じゃないけど）
クラス実装の変更に対する再コンパイルの必要性の削減。

これが利益とならない環境では用はない。これが利益となる環境はある。

個人的には同じ目的ならインターフェースクラス＋生成関数のほうが手間が少なくて好み。
公開済みのクラス（具象クラス）に後付けでも適用できるのが pimpl の強みじゃないかな。

**デフォルトの名無しさん** · 2019/11/04(月) 00:45:00.04

>>833
>>821は、>>802からの流れなのでヨロ

そうした上で、
>ライブラリ使用者に無関係で見せたくないからpimplで隠す
それがpimpl固有の特質である根拠とは…
構造体の詳細を見せる必要が無いなら
別にハンドルでも良いじゃん？Cだと昔からそうしてきたわけやし…

>>834
構造体の詳細を見せる必要が無いなら
別にハンドルでも良いじゃん？Cだと昔からそうしてきたわけやし…

pimplとかC++で実装する側がソースコードを整理したい目的で使うものであって、
ライブラリの公開インターフェースがpimplであるべきという論こそ勘違い甚だしい

**デフォルトの名無しさん** · 2019/11/04(月) 00:50:27.63

>>881
お前の老害頭では無理だと思う

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

コンパイル時にリフレクションできたらC++にはもう何も望まないんだけどな

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

リフレクションしたいとか実行時にあれだとかこれだとかしたいとか
もっと安全性を高めたいとかいう人はC#にいったらいいとおもうんだが
なぜいかないのか

**デフォルトの名無しさん** · 2019/11/04(月) 04:20:27.81

マングリングとかも規格で決めてほしいよね
そうすればクラスのエクスポートなんかも簡単になるのに

**デフォルトの名無しさん** · 2019/11/04(月) 06:09:25.96

動的はともかく静的リフレクションはあって困る場面は無いだろ

冗長な記述や変なマクロを使わずに、enumを文字列化したりしたいだろ

**デフォルトの名無しさん** · 2019/11/04(月) 06:17:29.31

名前マングリングの方法がコンパイラ毎に違うおかげで
互換性のないオブジェクトファイル同士がリンクされる事故を防げる、って
『More Effective C++』に出てたな。

便利さも欲しいが安全性も保ちたい、という要求のせめぎあいだな。

**デフォルトの名無しさん** · 2019/11/04(月) 06:59:32.99

今生き残ってるC++のコンパイラってどのくらい種類あんの
特定ハード向けのもgccの派生なんでしょ？

**デフォルトの名無しさん** · 2019/11/04(月) 09:40:11.27

>>833
>>883とｵﾓﾀがちょっち訂正しておき鯛、
publicなメンバ関数だけでprivateを一切含まずに事を済ますクラス定義を広義のpimplとみなすなら
ライブラリの公開インターフェースとしてpimpl最高じゃな

ハンドルだけだとユーザーが間違った呼び出しをしかねない
これをpimpl式にクラスでwrapするのはｽｹﾞｰ有効

**デフォルトの名無しさん** · 2019/11/04(月) 10:05:11.25

つーかハンドルで渡して使う時にキャストするって面倒だからさ
privateだからいいでしょとかいう問題じゃない

**デフォルトの名無しさん** · 2019/11/04(月) 12:16:24.53

記述の煩雑さはもう諦めるけどインラインPimplでゼロオーバーヘッドにしてほしい

**デフォルトの名無しさん** · 2019/11/04(月) 12:22:24.34

煩雑さを許容できるならやれるでしょ
pointerでなくバイト配列にしておいて中でcastするやつ
気を付けないところいろいろあるけど

**デフォルトの名無しさん** · 2019/11/04(月) 12:35:35.98

オーバーヘッドを気にしている人の大半は、気にする必要のあるものを作っていない

**デフォルトの名無しさん** · 2019/11/04(月) 12:35:45.49

実装をpimplに押し込めて公開インターフェース上の変数メンバの増減を無くすのが肝なんだから
pimplのデリファレンスのオーバーヘッドは避けようがないだろう。

**デフォルトの名無しさん** · 2019/11/04(月) 12:41:44.84

そもそもprivateな関数宣言をpublicなヘッダに
書かないといけないというC++言語仕様の欠陥

publicヘッダとprivateヘッダの二つに分けて
クラス宣言できればよかった

ちなみにC#ではpartialクラスといって
複数のファイルにまたがってクラスの定義ができる

**デフォルトの名無しさん** · 2019/11/04(月) 13:33:20.96

>>896
こういうの
https://ideone.com/EB36N2
pointerじゃないからpimplではない

**デフォルトの名無しさん** · 2019/11/04(月) 13:45:03.05

まあ欠陥って言われてもprivateメンバー変数変更されたらインスタンスのサイズ変わったりするから
1) 参照してるソースも含めてリコンパイルする
2) ポインタで持つ（pimpl）
しかないからねぇ
C++的には現状の言語仕様でIDEでprivateは見せないようにもできるとかでいいと思う

**デフォルトの名無しさん** · 2019/11/04(月) 13:47:25.16

>>898
パズルとしてはいいけど真顔で書いてたらちょっと引くわw

**デフォルトの名無しさん** · 2019/11/04(月) 13:59:48.02

>>898
その場合でも任意の変数メンバの拡張性は結局 Hide::a の存在で保証されているわけだろう。
impl[32] と予約された範囲まで拡張できるというのもあるのかもしれんが。

**デフォルトの名無しさん** · 2019/11/04(月) 14:00:47.43

結局低レイヤーを考慮しないでバカが文句言ってるだけで
そんなことに付き合う必要はないんだよ。

**デフォルトの名無しさん** · 2019/11/04(月) 14:16:11.73

>>901
バイナリ境界にしたときの拡張性のこと言ってる？
それはまさに配列のサイズでリザーブだね
溢れたら終わり

目的がヘッダー依存を切ることなら必要に応じて配列サイズ増やせばいいだけ
めんどいけどassertかけてあるからミスることはない
あとpimplは中でnewされるのがいやな場合あるからそれを避けられるってのも大きいね

**デフォルトの名無しさん** · 2019/11/04(月) 14:34:36.07

>>897
（使う側が）、CPerson person[10]; や、new CPerson[10] のように書いたと
すると、C++は高速化のため、CPersonのバイトサイズを定数値として
静的にコンパイルして、スタックや Heapからそれらのオブジェクトの領域を
確保する。
なので、たとえC++でCPersonのprivateメンバがC#のpartialの様に分けて宣言できた
としても、それらを全て合わせた全体のバイトサイズが分からないと静的に処理できない。
故に結局、partialの一部であっても全体のサイズに影響のあるような変更が行われた
場合には、上記の様な形でCPersonを使うプログラムは再コンパイルが必要となる。