X



C++相談室 part161

■ このスレッドは過去ログ倉庫に格納されています
0585はちみつ餃子 ◆8X2XSCHEME
垢版 |
2022/08/18(木) 14:09:16.33ID:KKIhvA0h
私もそう思う。 C++ でも明確で、解釈の余地はほぼない。
その上で知ってても人は間違うというところは問題で、チェックを自動化できるように整理したという Rust の功績は大きくはある。
ルール自体の差は C++ と Rust でそれほど大きくはない。
0586デフォルトの名無しさん
垢版 |
2022/08/18(木) 14:18:54.74ID:PTM9RcdX
C++のライフタイムはプログラマーにとっては明確でもコンパイラにとっては明確でない
そのためC++では参照の安全性をコンパイラが保証することができない
そして複雑化した時に人間(プログラマー)はミスを無くすことが出来ない
そのためC++で書かれた多くのソフトウェアで常に穴が発生し続けている
0588はちみつ餃子 ◆8X2XSCHEME
垢版 |
2022/08/18(木) 16:15:40.31ID:KKIhvA0h
>>587
C++ のスマートポインタはやっぱり後付け感はある。
Teratail とかの質問サイトを見てたら (コンパイル時にエラーに出来ない形で) 使い方を間違ってセグフォしてたりするのはちょくちょく有る。
コンパイラがガッツリと検査してくれる Rust はありがたいよ。
0590デフォルトの名無しさん
垢版 |
2022/08/18(木) 16:27:29.27ID:9oKj6z2J
桐蔭トリプルプレーだよ
0592デフォルトの名無しさん
垢版 |
2022/08/18(木) 16:59:01.63ID:4Dlj1ckV
>>587
unique_ptrやshared_ptrの使い忘れや使い方ミスなどをしてもコンパイラはエラーとすることができないためC++は安全性を保証できない
他にもget()して得たポインタを関数などに渡した後にそのライフタイムを逸脱しないかなどの保証もできない
全ては人間頼みとなるため多数の穴が生じてきた
0593デフォルトの名無しさん
垢版 |
2022/08/18(木) 19:33:28.16ID:74ku3J2B
性能厨としては何でもスタックフレームに置いて集積度を高くしたいところ。レジスタの効率とかキャッシュヒット率とか変わるだろうし。

Rustのスタックへのこだわりはいいんだけど、無駄に抽象化しているから余計に複雑になっている感じを受ける。
0594デフォルトの名無しさん
垢版 |
2022/08/18(木) 21:49:54.60ID:SUTQRi3H
C++のスマポは言語機能じゃないから書き方長くてだるいし
外部ライブラリは当然ナマポ使ってるから結局その辺でセグフォの危険を排除できないし
オウムみたいにスマポでいいじゃん連呼してるやつは本当に使ったことあんのか?
0595デフォルトの名無しさん
垢版 |
2022/08/18(木) 21:58:35.30ID:KxsikMs2
>>592
使えば?と私は提案してるので「使い忘れ」は論外として
「使い方ミス」はどんなミスでしょうか?
ミスのしようがないほど単純だと思います

Rustのコンパイル時にチェックしようという設計は
もちろん良いと思いますよ
0598デフォルトの名無しさん
垢版 |
2022/08/18(木) 22:12:02.34ID:3gZlWdNz
>>596
君のような勘違い自信過剰な人がうっかりミスを起こして問題を引き起こしてきた
チェックを人間に依存している限りミスは必ず発生する

ソース記事
https://xtech.nikkei.com/atcl/nxt/column/18/00692/042700054/
グーグルによればAndroidに存在した深刻なセキュリティー脆弱性の70%近くがメモリー安全に関するバグに起因するという。
同様にマイクロソフトも、同社製品に存在したセキュリティー脆弱性の70%がメモリー安全に関するバグに起因すると述べている。
C/C++を使う限りセキュリティー脆弱性を根絶するのは不可能と
0600デフォルトの名無しさん
垢版 |
2022/08/18(木) 22:17:29.31ID:KxsikMs2
>>598
> >>596
> 君のような勘違い自信過剰な人がうっかりミスを起こして問題を引き起こしてきた
私は最近はメモリ管理で全く失敗がないので私とは違うな
0602デフォルトの名無しさん
垢版 |
2022/08/18(木) 22:29:53.88ID:6c/4Q98o
>>600
それは貴方がアホだからミスに気付いていない可能性、使われないからバグが未発見なだけの可能性、単純なことしかしていないだけの可能性、…
複雑化すると、どんなにベテランでも、多数の人々がコードをチェックしていても、メモリ管理ミスが現実に起きている現実を受け入れましょ
0605デフォルトの名無しさん
垢版 |
2022/08/18(木) 23:09:02.07ID:KxsikMs2
>>604
ごめんごめん
>>598がいちいち私を引き合いに出してきたので否定したまでだよ
>>598の書き込みも冒頭の「君のような」を書かなければ
良いのに何でいちいち書くのかね?
0606デフォルトの名無しさん
垢版 |
2022/08/18(木) 23:31:07.48ID:RTRtwr2z
どんな複雑なケースでも一度もミスをしたことがない!今後も絶対にミスをしない!
と言ってる人を信頼できるわけがない
0607デフォルトの名無しさん
垢版 |
2022/08/18(木) 23:38:25.32ID:KxsikMs2
>>606
>一度もミスをしたことがない!今後も絶対にミスをしない!
そんなことは一言もいっとらんがなw
0608デフォルトの名無しさん
垢版 |
2022/08/18(木) 23:42:25.87ID:KxsikMs2
本当にunique_ptrやshared_ptrでミスするかい?
信じられないほど単純なクラスだと思うけど
>>592の「使い方ミス」って何なの?

getで中身取り出して云々は割とあり得るんだろーけど
それはunique_ptrやshared_ptrの外の出来事だし
0610デフォルトの名無しさん
垢版 |
2022/08/19(金) 00:27:49.36ID:SM6rQCcv
>>609
有難う!読んでみたよ!過ちを列挙すると以下の通り
>過ちその1: uniqueptrで十分なところにsharedptrを使う
>過ちその2: shared_ptrで共有されたリソース/オブジェクトをスレッドセーフにしない
>過ちその3: 自動ポインタ(auto_ptr)を使う
>過ちその4: sharedptrの初期化にmakesharedを使わない
>過ちその5: オブジェクト(生ポインタ)を作成してすぐにshared_ptrに割り当てない
>過ちその6: shared_ptrで使用されている生ポインタを削除してしまう
>過ちその7: ポインタの配列にshared_ptrを使用する際にカスタムデリータを使用しない
>過ちその8: 共有ポインタを使用する時に循環参照を回避しない
>過ちその9: unique_ptr.release()で返された生ポインタを削除しない
>過ちその10: weak_ptr.lock()を呼び出す際に、有効か否かを確認しない

俺については4はmake_sharedを知らなかった時期にはやってたけど知ってからはないね
3はunique_ptrがstdに入って全部リプレースした
あとは過去にも犯さず使用しできてるよ
みんなはどうだい?
0612デフォルトの名無しさん
垢版 |
2022/08/19(金) 00:47:36.81ID:SM6rQCcv
>>611
外部ライブラリの関数呼ぶのにget使うけど
意味するところを理解しているので
慎重になるから失敗した覚えはないなぁ

当たり前だけど自分の書く関数の引数に生ポインタを使うことはない
0613デフォルトの名無しさん
垢版 |
2022/08/19(金) 01:36:44.63ID:Iq0pX04r
>>612
ところで複数の関数呼び出しそれぞれに参照を渡したい時はどうしてる?
生ポインタ使わないからshared_ptr?
0615デフォルトの名無しさん
垢版 |
2022/08/19(金) 02:09:43.59ID:SM6rQCcv
>>613
その書いている「参照」ってのはC++の参照ではないですよね?

関数にT型のオブジェクトを引数として渡すとき
関数がシーケンシャルに実行されるなら原則としてT &で渡す
中身が無効値である可能性があるならunique_ptr <T> &で渡す
関数が並行に実行されるならshared_ptr <T>を渡す
0616デフォルトの名無しさん
垢版 |
2022/08/19(金) 03:25:13.02ID:oQfRblXd
T&渡した時にそれが他へ転用され保持されて生き残り続ける可能性を考慮しないの?
0617デフォルトの名無しさん
垢版 |
2022/08/19(金) 05:39:15.80ID:HCuI/gXC
静的試験を絶対視するなーんにも分かっとらんやつが推すほどイメージが悪くなるな
0618デフォルトの名無しさん
垢版 |
2022/08/19(金) 07:27:50.77ID:QMISJLeV
>>616
だからポインタ使うの?
まあ寿命の長いオブジェクトを駆使しないほうがかっこいいのでは
0621デフォルトの名無しさん
垢版 |
2022/08/19(金) 08:45:24.08ID:xzucV8hS
>>597
constructor destructor関数オブジェクトを用意すれば良かったんじゃなかったっけ?smart ptrの典型的な応用例だから、調べりゃすぐ出てくるよ。
0623デフォルトの名無しさん
垢版 |
2022/08/19(金) 10:22:48.97ID:51hioa9S
>>617
俺も以前はそう思っていたんだけど
わずかな補助情報を人間が与えるだけで
Rustコンパイラが静的試験してくれて
人間にとって面倒かつ慎重さを必要とする作業から解放してくれるのを知って考えが変わった

例えて言うなら
動的型付け言語を使っていたところを
わずかな型情報を人間が与えるだけで
静的型付け言語のコンパイラが静的試験をしてくれるようになったのと似てる
0624はちみつ餃子 ◆8X2XSCHEME
垢版 |
2022/08/19(金) 11:08:02.29ID:FT/EuRcZ
昔とはソフトウェアの規模感が違う。
そしてプログラミングするのがプログラミングの専門化とは限らない領域が増えた。
(いわゆるエンドユーザー・コンピューティング)

職業的なプログラマにしてもプログラミングの専門化というよりは
別分野のそれぞれの専門化が道具としてのプログラムを作るというような場合も多い。
プログラミングのルールや作法を行きわたらせることは出来ないよ。
検査を強くするのは時代的な背景としても自然に思える。

動的な検査でも静的な検査でもいいが、
C/C++ は検査せずに未定義に突入するのがあまりにも簡単すぎる。
0625デフォルトの名無しさん
垢版 |
2022/08/19(金) 11:09:58.15ID:HCuI/gXC
>>623
ナマポひとつロクに扱いきれないスキルと
動的チェックなんて恥ずかしげもなく言っちゃう
バカ用言語があんたにとって有難いのは分かったよ

ここはC++相談室
C++という土俵に立っている者の場だ
落ちこぼれて逃げ出したやつの遠吠えは
誰も聞きたがってない
どっか行け、邪魔なんだよ
0626デフォルトの名無しさん
垢版 |
2022/08/19(金) 11:17:41.46ID:HCuI/gXC
自分のミスを道具のせいにするやつ
そういえば法案のミスをワープロのせいにするバカ役人がいたな

こういう手合いは一事が万事
0628デフォルトの名無しさん
垢版 |
2022/08/19(金) 11:53:43.76ID:SM6rQCcv
一般用語の参照を使ってると思われるあたり
この人(>>613)はC++の参照を知らないレベルだと思うんだよね
C++に関してはほぼ知識がないまま
受け売りでRustが生ポインタを廃止?した利点を主張している
(私もRustのコードは書いたことがないんだけども)
この人は何がしたいんだろうか?
0630デフォルトの名無しさん
垢版 |
2022/08/19(金) 12:19:36.97ID:HCuI/gXC
動的型付け・・・あー、もしかして動的型宣言のことかな?
だとすると具体的に何言語のことを言ってるんだろう?
Bにはそんなもんないし・・・
0631デフォルトの名無しさん
垢版 |
2022/08/19(金) 12:44:26.95ID:BT0K6AVq
昔構造体を値で渡したらポインタにしろっておっさんに怒られたっけ
速度を気にしないんだったらコピーでええのに糞めんどくさかったわ
0634デフォルトの名無しさん
垢版 |
2022/08/19(金) 13:06:02.28ID:HCuI/gXC
>>633
それwikipediaソースだろpgr
で、あんたdynamic type declarationのことを言ってたの?
それとも他の何かか? Bにあったものか?
0635デフォルトの名無しさん
垢版 |
2022/08/19(金) 13:47:12.04ID:FysKbdqv
>>634
あまりにも無知すぎて話にならないな
wikipediaでも何でもいいから勉強して出直して来い
動的な型と動的型付けの区別は最低限つけろ
静的型付け言語の中には動的な型と呼ぶものもあるが
静的型付けと動的型付けは基本的に排反の関係だ
0637デフォルトの名無しさん
垢版 |
2022/08/19(金) 14:06:18.12ID:zzLlPl0v
その一文がわからないようなレベルの奴がメモリ管理で全く失敗ないとか言ってんだもん
みんな呆れてんだよ
0638デフォルトの名無しさん
垢版 |
2022/08/19(金) 14:08:38.12ID:SM6rQCcv
>>637
本当に質問の意味が分からんから説明してよ
意味が分かったら返答するからさ
0639デフォルトの名無しさん
垢版 |
2022/08/19(金) 14:09:02.63ID:HCuI/gXC
>>635
俺は動的な型と動的型宣言を混同していることを露呈するような失言はしてないぞ
していると言うなら具体的にどこなのかを示せ
誤魔化しても構わんがそれも返事と取るからな
0640デフォルトの名無しさん
垢版 |
2022/08/19(金) 14:28:41.00ID:SM6rQCcv
>>628にも書いたけどC++相談室で一般用語の「参照」は
C++の参照と混同するので普通は避けるんだよね
C++で書いた経験が皆無なんだなと俺は判断している
それで>>616のような意味を計りかねる質問をしてしまう
0641デフォルトの名無しさん
垢版 |
2022/08/19(金) 14:40:23.82ID:FysKbdqv
>>639
そこまで恥を再び晒したいなら示す

>>630
> 動的型付け・・・あー、もしかして動的型宣言のことかな?

まず動的型宣言という用語は存在しない
"動的型付け" はググると7万件あり
"動的型宣言" はググると3件である

一般的に動的な型の宣言の話と広く解釈したとしても
動的な型の宣言と動的型付けは異なり互いに包含関係などもない
動的な型の宣言は静的型付け言語においても持つものがある
そして動的型付けは静的型付けの逆であり相反する
0642デフォルトの名無しさん
垢版 |
2022/08/19(金) 16:45:49.60ID:SM6rQCcv
>>637
説明が難しいなら簡単なコードでも良いよ
何を懸念しているのかそれで推察できると思うから
0643デフォルトの名無しさん
垢版 |
2022/08/19(金) 17:07:32.80ID:rkGmDNWr
栄光在天
聖恩心から感謝申し上げます。
日ごろは激しい摂理の中、プログラム業ごくろうさまです。
さて、C++のコピーコンストラクタおよび代入演算子オーバーロードの質問でございますが、メンバ変数全てを関数定義内部で書き出すととてつもない量になってしまいます。

class Hoge
{
Hoge& Operator =(const Hoge&r);
int hage=0;
char sage=0;
std::unique-ptr<Hagehage> pHagehage;
etc…
Etc…
Eat…
};
Hoge& Hoge::operator=(const Hoge&r)
{
hage=r.hage;
sage=r.sage;
pHagehage=std::make-unique<Hagehage>(r);
Etc etc……
}
メンバにユニークポインタがあるので書き出さないとダメな感じになっちゃうのですが……量がががが(>_<)
これらにおいて、何か楽になるような裏技はありますか?
それとも一つづつ足していかなければならないのでしょうか?
もしかしたらコンパイラやIEDの部門で行うべき変な質問かなとも思いますが……何かやり方やティップがありましたら教えていただければ……
相対的に有田退治にもなります!
0644はちみつ餃子 ◆8X2XSCHEME
垢版 |
2022/08/19(金) 17:19:48.26ID:FT/EuRcZ
>>643
メンバを

Hoge& Operator=(const Hoge&r)=default;

というように宣言すればデフォルトの定義が実装される。
全てのメンバに対して代入演算子を適用したのと同じことになる。
(もちろん全てのメンバを代入するという挙動で駄目な場合は自分で書くしかしょうがない。)
0645デフォルトの名無しさん
垢版 |
2022/08/19(金) 17:31:34.37ID:HCuI/gXC
>>641
そのレスには動的な型についての言及がないな
誤魔化したいわけね、返事ありがとう

動的型宣言という言葉は存在しないと言いながら
動的型付けとは【意味が違う】とはどういうことだ?
存在しないものは比較できないはずだぞ
operator<=>でSFINAEだなpgr
0647はちみつ餃子 ◆8X2XSCHEME
垢版 |
2022/08/19(金) 17:39:10.42ID:FT/EuRcZ
>>643
そもそも代入演算子は特に指定しなくても定義されるはずだな。
(ただし基底とメンバの全てが代入可能であるとき。)

class foo {
public:
int x, y, z;
foo(int x, int y, int z) : x(x), y(y), z(z) {}
foo(void) : x(0), y(0), z(0) {}
};

int main(void) {
foo x(1, 2, 3), y;
y=x; // 代入できる
}
0648デフォルトの名無しさん
垢版 |
2022/08/19(金) 19:46:49.43ID:FysKbdqv
>>645
おかしな人みたいだからこれ以上は相手にするのやめとく
動的型付けを知らなくて間違えたことは仕方ないとしても
それを指摘された後の逆ギレはみっともないから治したほうがいいよ
0651デフォルトの名無しさん
垢版 |
2022/08/19(金) 20:42:25.54ID:rkGmDNWr
>>644
>>647
規制されてしまいましたが643でございます。
メンバにユニークポインタがある場合は代入演算子とコピコンは削除された関数とされてしまい、コピーが実行できません(涙
ユニークポインタは明示的に複製されないとだめなのはわかるので、仕様には文句があるべくもないのですが……
例えばの話、データ型にint char等のメンバが100個あったとして、ユニークポインタのユーザー定義型が1個紛れ込むだけで、すべてのメンバを書き出しをしなければいけないのでしょうか?
みなさんはちゃんと書きだしているのですか?と疑問に思ったので・・・
まあユニークポインターを含むデータ型をコピーしない運用をなさっているのだと思うのですが、わたしは使ってしまいます(怒)
そこで、なにか裏技のような方法がないのかなとお聞きしてみた次第であります(`・ω・´)ゞ
0653デフォルトの名無しさん
垢版 |
2022/08/19(金) 21:01:24.21ID:rkGmDNWr
>>652
メンバ変数 std::unique_ptr<My_Uniq> my_uniq; において
this->my_uniq=std::make_unique<My_Uniq>(*(right_arg.my_uniq.get()));
とコピーできるのはシンプルなのですが……

struct hoge
{
hoge& operator=(const hoge& r);
int a=0,b=0,c=0;
char d=0,e=0,f=0;
std::string g,h,q;
std::unique_ptr<MyHage> pMHage;
};
といった構造体において、
hoge& hoge::operator=(const hoge& r)
{
//メンバ全部かかなきゃいけない( ;∀;)
}
という感じになってしまうのが困るというか……もっと楽できないかなと思いまして(´;ω;`)
0655デフォルトの名無しさん
垢版 |
2022/08/19(金) 21:14:52.11ID:rkGmDNWr
>>654
なるほど得心いたしました!
ユニークポインタをラップしたクラスにコピーコンストラクタを実装すればいいという……ってコト?
ですね?
ちょっと試してめます
0656デフォルトの名無しさん
垢版 |
2022/08/19(金) 21:36:17.81ID:rkGmDNWr
643です
解決しました
皆様ご親切にありがとうござい甘いた
ラップしてオペレーター実装すればいいだけだったとは……
こんなので悩んでるの私だけではないだろうか
0657652
垢版 |
2022/08/19(金) 23:10:05.19ID:SM6rQCcv
>>656
携帯だったので書けなかったけどこんな感じで
template <typename T>
class deeep_copy_unique_ptr: private std::unique_ptr <T>
{
using Base_ = std::unique_ptr <T>;
public:
explicit deeep_copy_unique_ptr (T *p = nullptr): Base_ (p) {}
deeep_copy_unique_ptr (const deeep_copy_unique_ptr <T> &p): Base_ (std::make_unique <T> (*p)) {}
deeep_copy_unique_ptr &operator = (const deeep_copy_unique_ptr <T> &p) {Base_::operator = (std::make_unique <T> (*p)); return *this;}
using Base_::operator *;
};
0658デフォルトの名無しさん
垢版 |
2022/08/20(土) 17:45:23.06ID:K3rnpbr9
>>621
それがそうでもないんですよ。だれか簡単なソースで示してくれませんか?
ハンドルごとにデストラクタがいろいろと変わるのが難しいと考えています。
0659デフォルトの名無しさん
垢版 |
2022/08/20(土) 17:53:55.99ID:zyxn7VyM
ハンドルごとに異なるデストラクタを指定すればよいのでは?
何が難しいのかソースで示してくれませんか?
0660デフォルトの名無しさん
垢版 |
2022/08/20(土) 17:54:26.62ID:ThG9yriU
>>658
> ハンドルごとにデストラクタがいろいろと変わるのが難しいと考えています。
ハンドル毎にクラス作ればいい
と言うかハンドル毎にコンストラクタも色々変わるはずだがそっちはいいのか?
0661はちみつ餃子 ◆8X2XSCHEME
垢版 |
2022/08/20(土) 18:23:11.87ID:ktmIW8Jj
>>658
ポインタ以外のリソース一般を扱うための unique_resource クラスの提案は出ている。
一部の処理系では使えるようになっているし、ポータブルな実装があるので導入してみてもいいかもね。

このような提案が出ているのは逆に言えばスマートポインタではハンドルを上手く扱えないということでもある。
0663デフォルトの名無しさん
垢版 |
2022/08/20(土) 21:48:51.04ID:XA6yEFAc
>>658
そのハンドルって何? ハンドルを具体的に指定せずにソースで示せとな?

#include <memory>
#include <cstdio>
#include <string>
using namespace std;
int main ()
{
using File_Ptr = unique_ptr <FILE, decltype (&fclose)> ;
const string path ("hoge.txt");
File_Ptr fp (fopen (path.c_str (), "w"), &fclose);
const string buf ("hage\n");
fwrite (buf.c_str (), 1, buf.size (), fp.get ());
return 0;
}
0664デフォルトの名無しさん
垢版 |
2022/08/20(土) 21:51:59.51ID:xbv+n9gR
unique_ptr縛りですか?
shared_ptrならコンストラクタの第二引数にDeleter関数を渡せるけど
0666デフォルトの名無しさん
垢版 |
2022/08/21(日) 01:35:54.66ID:hxqq7KJv
こんな昔ながらのRAIIクラスでいいじゃん

class FantasticHolder
{
FantasticHandle h = NULL_HANDLE;
errno_t e;
public:
FHHolder(int flag, void* data, FOption option)
{
 e = create_fantasy(&h, flag, data, option, false, NULL, Fantasy::DREAM);
}
close() {
 e = universal_fancy_destroyer(h, NULL, true, Fancy::FANTASTIC);
 h = NULL_HANDLE;
}
~FHHolder() { close(); }
const FantasticHandle& getHandle() const {return h;}
erron_t getError const {return e;}
};
0667デフォルトの名無しさん
垢版 |
2022/08/21(日) 13:06:57.68ID:j3ukytx2
>shared_ptrならコンストラクタの第二引数にDeleter

ほんそれ
0668デフォルトの名無しさん
垢版 |
2022/08/21(日) 18:27:12.08ID:llGchqj4
lzw書いたら、色々プリプロセス突っ込んでやったのにメルセンヌツイスタの前に敗北した。
2色ビットマップは1/5になったけど、ブロックソートがアホみたいに遅い・・・。Orz
0671デフォルトの名無しさん
垢版 |
2022/08/25(木) 10:04:27.81ID:1QA/N1Qa
サブルーチンsub、
subを呼ぶA、
subを呼ぶB、
があって、subをAとBからしか見えないスコープに置きたくなったんですが、そういうときはnamespaceを切るしかないですか?
0672デフォルトの名無しさん
垢版 |
2022/08/25(木) 10:09:20.76ID:s36cDPHI
>>671
sub, A, Bをひとつのファイルに入れてファイルスコープで区切るとかクラスにまとめてクラススコープで区切るとか
0673デフォルトの名無しさん
垢版 |
2022/08/25(木) 12:00:46.82ID:1QA/N1Qa
>>672
クラスに入れるとしたら毎回インスタンス作って呼ぶんですかね?
外から呼ぶためだけにstatic関数にするのもなーと思ってしまうのですが、そういうのはよくやられていることですかね?
0674デフォルトの名無しさん
垢版 |
2022/08/25(木) 18:28:04.89ID:tuQ48GQq
Javaとかではstatic関数まとめクラスはよく見るけどC++ではあんまり見ない
それこそnamespaceを使う
0675はちみつ餃子 ◆8X2XSCHEME
垢版 |
2022/08/25(木) 18:44:56.88ID:ktMJLYyQ
それはどうだろう。
namespace は内部を隠蔽しない。
キッチリと隠したいなら翻訳単位を分けるか、
翻訳単位内でも隠蔽したいならクラスに入れるかしかやりようがない。

やろうと思えば namespace で区切ってここにはアクセスしないことにするという
規約で運用するとかも出来るが、その程度で足りるなら
そんなに分けなくてもよくない? って思うし。
0676デフォルトの名無しさん
垢版 |
2022/08/25(木) 20:19:01.82ID:TTLAkLfZ
subを公開ヘッダに書かずに非公開ヘッダに書くだけでよくね?もしくはヘッダを用意せずに各ソースコードからexternするとか。どっちも完全に隠蔽されるわけじゃないけど。

あとは全部同じソースコードに格納できるなら無名名前空間の中にsubを入れとくとか?
0680剛田武
垢版 |
2022/08/25(木) 23:01:36.69ID:JbTCA7nE
おお!心の友よ!
お前のものは俺のもの
俺のものは俺のもの
■ このスレッドは過去ログ倉庫に格納されています

ニューススポーツなんでも実況