C++相談室 part148

**デフォルトの名無しさん** · 2020/01/31(金) 20:54:06.26

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

前スレ
C++相談室 part147
https://mevius.5ch.net/test/read.cgi/tech/1576659413/
このスレもよろしくね。
【初心者歓迎】C/C++室 Ver.105【環境依存OK】
http://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/ (日本語)

**デフォルトの名無しさん** · 2020/02/11(火) 10:35:43.55

boolやBOOLでない変数abcをif(a==b==c)と書きたい事はある。

**デフォルトの名無しさん** · 2020/02/11(火) 10:56:56.94

QZってコイツ片山だっけ？

**デフォルトの名無しさん** · 2020/02/11(火) 11:01:53.65

if(b==true)
はifのなかには比較入れないとダメだと思っているんじゃね

そう言う言語もあるし

**デフォルトの名無しさん** · 2020/02/11(火) 11:09:22.66

「rust が c++ を超えた！！神！！」みたいな記事をよく見ますけど、今後c++がrustから学んでもっと良くなることって期待して良いですよね？
rustに勉強のコストを割くか迷っています

**デフォルトの名無しさん** · 2020/02/11(火) 11:12:06.04

>>731
片山はQZほど馬鹿ではない
まず国籍が違う

**デフォルトの名無しさん** · 2020/02/11(火) 11:29:50.94

なぜ

if (a == true)

と書くやつがでてくるのか
それは条件式に食わせるためには比較演算子で値から「真偽値」に変える必要があると
思っていてそれがboolと同値と理解していないからだろ
だからそういうやつは

if (a == 42 == true)

とは書かない
この例はむしろboolを理解してるやつからしか出てこない発想
やつらはいったん「真偽値」になればあとは論理演算子でつなげると理解している
ある意味、条件式を作るときのイディオムに馬鹿正直に従っているわけで別に
異常だと騒ぐほどひどくはない

別の見方をすればboolを特別視しないで書いてるわけで、
冗長にはなるが共通のフォーマットで書ききるってことはほかでもあることだ
そう思えばやっぱりひどくはない
実際おれは特別読みにくいとは感じないし、この無駄は最適化で消える
何かの機会にこれ冗長だよねと教えてやるぐらいで十分

**デフォルトの名無しさん** · 2020/02/11(火) 11:37:00.49

ほんといつまでやってんの

**デフォルトの名無しさん** · 2020/02/11(火) 11:38:29.11

冗長な書き方をする人の真意なんて測りようもないし理由が一つに決められるわけもないだろう。
想像するだけ無駄。

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/11(火) 12:17:11.73

>>715
そう書くべきだしそれが普通ってことはわかってんだって。
自分で書く分にはそう書くよ。
でも、他者が書いたコードを読むときや利用するときは
> 変数が実質的にブール型の場合は
っていう前提を確信できない場合がある。

整数型で真偽値の代用にすることがある C/C++ では
型で判断できないことがあるから罠だよねって話をしてるんだよ。
真っ当なデザインではない場合があるから思い込まずにちゃんと確認しようねってこと。

**デフォルトの名無しさん** · 2020/02/11(火) 15:09:17.27

>>735
同値
意味しらないのね

**デフォルトの名無しさん** · 2020/02/11(火) 15:15:33.26

> この例はむしろboolを理解してるやつからしか出てこない発想

そりゃそうだ
ifの制御式は比較でなければならないと言い張るやつへの皮肉なわけで

**デフォルトの名無しさん** · 2020/02/11(火) 15:19:47.85

operator =(BOOL value){
if(value==0){
return FALSE;
else if(value==1||value==2||...){
}

**デフォルトの名無しさん** · 2020/02/11(火) 15:21:35.11

>>596
あったあった

今はわざわざそれ使う理由忘れた

**デフォルトの名無しさん** · 2020/02/11(火) 15:25:53.55

Cだとそれで必ず0か1になるからTRUEと比較しても大丈夫！っていうクソみたいなバッドノウハウ

**デフォルトの名無しさん** · 2020/02/11(火) 15:28:40.66

operator ==(BOOL value){
　if(this->value == 0){
　　if(this->value == value){
　　　return TRUE;
　　}
　}
　else{
　　if(value==1||value==2||...){
　　　return TRUE;
　　}
　}
}

**デフォルトの名無しさん** · 2020/02/11(火) 15:38:44.74

>>743
そもそもTRUEと比較する必要はないしWindowsから出てきたイディオムでもないと思うが。
どちらかというとtruthyな値からtrueを得るイディオムとして使われているような。
よく見かけるのはJavaScriptとか。

**デフォルトの名無しさん** · 2020/02/11(火) 15:45:19.74

リターン式から返却値の型を推定させる場合にはautoが必要だ

◆QZaw55cn4c · 2020/02/11(火) 17:36:36.42

>>725
あなたのいう「一般的」というものが、実はそれほど一般的ではなかった、という可能性はありませんかね？
というか、まずあなたのいう「一般的」をあなたの言葉で定義するべきでしょう

あなたに定義できますか？

**デフォルトの名無しさん** · 2020/02/11(火) 18:04:17.83

単語の意味は辞書引けよ
APIの仕様はヘルプ読め、と同様だな
なんで個人が定義するんだよ

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/11(火) 18:24:26.11

http://get.secret.jp/pt/file/1581413018.png

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/11(火) 18:40:23.65

true と比較したけりゃすればいいじゃないの。
そのプロジェクト内で一貫したポリシーがあるのならそれでいいよ。

**デフォルトの名無しさん** · 2020/02/11(火) 18:49:13.60

ちゃうねん。

**デフォルトの名無しさん** · 2020/02/11(火) 18:52:49.99

ストリーム遅いな。

**デフォルトの名無しさん** · 2020/02/11(火) 20:44:57.22

コード規約「if(bool)はif(bool==true)と書かなければならない」
やだよ、そんな規約ww
規約決めるまでに紛糾してプロジェクト始められねぇよw

**デフォルトの名無しさん** · 2020/02/11(火) 20:57:43.57

どっちでもええやん

**デフォルトの名無しさん** · 2020/02/11(火) 22:08:40.56

explicit operator boolだとラムダとかの戻り値強制したいときそうなっちゃわない?

value() && true か value() || false
static_cast<bool>(value())は好きじゃない

**デフォルトの名無しさん** · 2020/02/11(火) 22:19:09.87

素直に戻り値boolに指定しろよ

**デフォルトの名無しさん** · 2020/02/11(火) 22:21:59.64

意味的にboolの型であればboolにキャスト
そうじゃないなら意味通りにboolに変換

◆QZaw55cn4c · 2020/02/11(火) 22:23:23.42

>>258
mmap を確かめています、なんだかすごく時間がかかってしまいました…
ideone はファイルを作らせてくれないみたいですね… https://ideone.com/zXFtEY

fd と fd に紐付いた mmap をつくっておいて、
①fd 側にデータを追加すれば mmap でも見えるのですが、
②mmap 側からデータを追加しても fd は増量しないようですね

今は cygwin で見てますが、ちゃんと linux をいれて確かめるつもりです…

**デフォルトの名無しさん** · 2020/02/11(火) 22:24:35.42

オンメモリで出来ることは素直にオンメモリでやれば

**デフォルトの名無しさん** · 2020/02/11(火) 23:36:09.88

くじで決めてはどうか。

**デフォルトの名無しさん** · 2020/02/11(火) 23:39:16.71

モンテカルロ法やな

**デフォルトの名無しさん** · 2020/02/11(火) 23:56:08.12

I/Oの遅さの陰に隠れてたけど。
ストリームよりSSDのほうが速いよって時代になって困る。

**デフォルトの名無しさん** · 2020/02/12(水) 01:53:51.39

YouTuberは「最強の職業」である理由。
https://www.youtube.com/watch?v=XjV3Nb0-hgA
【事例付き】YouTuberは最強の副業である件について。
https://www.youtube.com/watch?v=wB8hNuNVoIw&;t=267s
【初心者向け】YouTubeの始め方・稼ぎ方を徹底解説！
https://www.youtube.com/watch?v=YEw-a8qlADM
「YouTubeなんていつか稼げなくなる」という主張を論破する。
https://www.youtube.com/watch?v=VatNILApW4U
収益化から丸1年！YouTubeでいくら稼いだか公開。
https://www.youtube.com/watch?v=-zQxuQqZ5eA&;t=103s
その動画で月商○○万!? YouTubeで稼ぐ裏技的アプローチ。
https://www.youtube.com/watch?v=7I4APU_6i9o&;t=433s
【貧者の工夫で戦え】ガラケーだっていい。YouTube始めるのにパソコンはいらない！
https://www.youtube.com/watch?v=jYdWfjjzD7Y
【第一回】SNS、YouTube、ブログで稼ぐ方法を、丁寧に解説します！
https://www.youtube.com/watch?v=erNiLOncDnY

**デフォルトの名無しさん** · 2020/02/12(水) 06:38:05.77

>>763
グロ

**デフォルトの名無しさん** · 2020/02/12(水) 10:03:09.83

https://qph.fs.quoracdn.net/main-qimg-2c09000282ddcbb32359dc242831a052

**デフォルトの名無しさん** · 2020/02/12(水) 16:01:35.18

>>743
ああなるほど
if(TRUE == !!b) のことか

if(!!b) は javascript の方だろ

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/12(水) 16:24:33.81

! は見づらいから私は not と書くことにしてる。

**デフォルトの名無しさん** · 2020/02/12(水) 17:16:20.22

一応、alternative tokensに規定はあるが
使う奴の心は #define BEGIN { なんてやるやつと同質だね

**デフォルトの名無しさん** · 2020/02/12(水) 17:20:59.01

Cにも_Boolがなきゃヤダジタしてたやつとか
マジそういう言語へ行ったきり帰ってくるなって感じ

で結局BOOL < 0みたいなオカシイことが起き出す原因を作りやがる

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/12(水) 17:47:16.08

C と C++ で解釈が違うのに結果として動作は同じみたいなのがたまにあってすげーなって思う。

**デフォルトの名無しさん** · 2020/02/12(水) 18:09:20.78

たとえば？

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/12(水) 19:09:04.21

>>770-771
if 文の条件式を見てて思い出した。
C だと条件式の評価結果を 0 と比較するというルール
C++ だとブールに変換するというルール。

まあ整数をブールに変換する規則は結局のところ 0 と等しいかどうかなんで
ちょっと回りくどくなってるだけなんだけど、
そういう違いがあっても互換性が維持されるというのがどこかで検証されてるんだろうと思うと、
手間かかってんなぁという感想が浮かんだ。

他にも列挙定数の型が C と C++ では違うとか……。
私が把握してるのはそんくらいだけど、
探せばもっとあるんじゃないかな。

**デフォルトの名無しさん** · 2020/02/12(水) 20:25:01.80

>>766
>if(TRUE == !!b) のことか

さすがにこんな意味のない書き方が人の目につくほど蔓延りはしないだろう。おそらく>>743の妄想。

!!b は、bool型(と、しばしばオーバーロード)を備えた言語で非bool型の値bをbool型に変換するテクニックだろ。

**デフォルトの名無しさん** · 2020/02/12(水) 20:38:11.07

b!=0 で良い

**デフォルトの名無しさん** · 2020/02/12(水) 21:12:18.94

そういうゴミみたいな自己満テクニック（）が積もり積もって誰も触れないスパゲティモンスターになっちまうんだよ
b!=0でも(bool)bでもいいからやるべきことを直接表現しろ

**デフォルトの名無しさん** · 2020/02/12(水) 21:26:37.63

(bool)b
はCへの移植の可能性があるならやっちゃダメ

**デフォルトの名無しさん** · 2020/02/12(水) 21:31:03.80

>>776
何で？
ISO/IEC 9899:2011 (E)
7.18 Boolean type and values <stdbool.h>
1 The header <stdbool.h> defines four macros.
2 The macro
bool
expands to _Bool.

**デフォルトの名無しさん** · 2020/02/12(水) 21:34:37.96

typedef char bool;
の可能性があるから

**デフォルトの名無しさん** · 2020/02/12(水) 21:35:17.48

Cに移植する可能性があるならC++の機能を使っちゃダメなのは当たり前だよなぁ
C++スレで言うことではないと思うが

**デフォルトの名無しさん** · 2020/02/12(水) 21:36:55.01

>>779
問題点はそこじゃない
移植時にコンパイラが問題点を見つけられないのが問題

**デフォルトの名無しさん** · 2020/02/12(水) 21:38:26.52

コンパイラが問題点を見つけられない例は他に山ほどあるが
だからといってわざわざ増やさなくても良い

**デフォルトの名無しさん** · 2020/02/12(水) 21:39:05.32

いや、問題があるなら移植する人が見つけろよ

**デフォルトの名無しさん** · 2020/02/12(水) 21:40:47.83

移植は完璧な人がする
なんて妄想は捨てた方が良い

**デフォルトの名無しさん** · 2020/02/12(水) 21:42:13.60

Cに移植する可能性が無いならどうでも良い
ちなみにキャストで警告が出る環境もある

**デフォルトの名無しさん** · 2020/02/12(水) 21:42:36.95

だからそれは移植する側の問題だろ。勝手にやれよ

**デフォルトの名無しさん** · 2020/02/12(水) 21:52:54.99

>>778
マクロとtypedefが被った場合どうなるか解ってる？

**デフォルトの名無しさん** · 2020/02/12(水) 22:12:26.79

もちろん

**デフォルトの名無しさん** · 2020/02/13(木) 00:16:13.58

>>733
Rustを少し見てみたけど、書き方が全くC/C++とは違っていて、
全く異なる文化圏の言語になれた人が設計した臭がした。
これがC/C++の代替になるとは考えにくい。
はっきり行って、これを使えといわれると辛い。

**デフォルトの名無しさん** · 2020/02/13(木) 00:26:27.60

テスト機能が標準で用意されてるのはいい

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/13(木) 00:45:52.57

個人的には Rust は好感触。
型システムは ML 系言語で実績があるものを基礎にしてることもあって、C++ のグダグダな歴史を背負ったものよりはまとも。
ML 系はやっぱり高級路線の言語だし、インデントでブロックを表す系統なのがしんどいけど、
Rust は上手く低レイヤ用 (としても使えるよう) に着地させてるし、 C 風の外観を踏襲してもいる。

C++ が Rust から取り入れられるものはそんなに多くないと思う。
C++ は良くも悪くも互換性についてかなり強い要求があるので、
Rust 的な、カッチリと保護された仕組みを後付けするのはどう考えても無理。
C++ が Rust を参考にすることは間違いなくあるとは思うが、
全体の思想がまるで違うので限定的な範囲でしか取り入れられない。

もし取り入れらたらそれは C++ の新機能として新しく学ぶので十分でしょ。

Rust を学ぶのは間違いなく有用ではあるけども、
Rust の知見が C++ に取り入れられる可能性がありそうだからという理由ならそんなに意味ない。

**デフォルトの名無しさん** · 2020/02/13(木) 01:02:46.91

C++の配列は長さの情報を持ってないってことになってるけど
長さを与えなくてもdelete[]できるんだから、メモリのどこかにその情報はあるよね？
なんでその情報をプログラマが利用できないようになってるの？

**デフォルトの名無しさん** · 2020/02/13(木) 01:06:29.86

rustがかっちり保護してくれるとか低レイヤー向けとか馬鹿ほど信じてるよね。
ありゃ帯に短し襷に長しの典型言語だわ。

**デフォルトの名無しさん** · 2020/02/13(木) 01:44:34.08

>>792
実際、Rustは、Cを簡単にするのではなく、Cを難しくしてしまっていて、Cのポインタが理解できない or 難しく感じる人には、Rustの特徴の核心たる所有権、借用などの部分はちんぷんかんぷんだと思う。

**デフォルトの名無しさん** · 2020/02/13(木) 01:48:50.73

>>793
Cの問題点を取り除いたと言うより、ほとんど全てのプログラミング言語が暗黙のうちに用いている代入の概念をなるべく使わないようにして変数束縛などの全く異なる独自概念を用いようとしている。
しかし、これは、手続き型言語と関数言語の違いに匹敵するくらいのプログラミングの概念の変更になってしまうため、手続き型言語の中で改良された次世代言語と言うものではなくなってしまっているとも言える。

**デフォルトの名無しさん** · 2020/02/13(木) 05:24:36.37

変数束縛って右辺値参照でしょ

**デフォルトの名無しさん** · 2020/02/13(木) 06:24:47.58

RustはC++なら簡単にできることをものすごく回りくどく書かないとコンパイル通らない感じだからとてもつらい

**デフォルトの名無しさん** · 2020/02/13(木) 09:13:38.23

>>790
RustがC++に取って代わることがあるか、というニュアンスの質問でした
今C++でやってる仕事がRustに置き換わる可能性が高いなら今から勉強しとこうか、と

**デフォルトの名無しさん** · 2020/02/13(木) 12:35:22.33

>>797
断言してもいいが、RustはC++に取って代わることは無い。
なぜなら、普通の手続き型言語での枠組みにすら入ってない書き方を強要されるから。
手短に言えば、単にC/C++と書き方が大幅に違っているだけではなく、書き方が他のどんな減の範疇にも属していない。

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/13(木) 13:30:24.18

>>796
C/C++ でのオブジェクトの寿命の管理の難しさってのは
理屈が理解しづらいというよりはわかってても間違うという難しさなんだよね。
そして間違っていてもコンパイラは黙って通すことも多い。
C/C++ を長く使っていればそれを感じることって結構あるでしょ。
そういう部分のプログラムが正しいことはプログラマが保証しなくてはならんわけだ。
でも Rust では言語処理系の側でやってくれる。
C/C++ で面倒な部分を Rust では自動でやってくれる。
まわりくどいのは確かだけど、それで楽できるのも確かなので、
どっちを取るかって話だな。

オブジェクトをどこで後始末するか。
管理の主導権はどのモジュールに持たせるか。
そういうのって C/C++ でも考えてるよね。
C/C++ ではプログラムに書いてないだけで本来はあるはずのものなんだよ。
(C++ だとスマートポインタの導入で少し楽にはなったけど。)
自分が何を考えていたのか、そして何を考えられていなかったのが
明らかになるのはそれはそれで楽しいと思う。
まあ、それは俺が趣味でやってるからかもしれんな。

**デフォルトの名無しさん** · 2020/02/13(木) 13:34:58.25

おまえの設計がヘタクソなだけだろ

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/13(木) 13:45:30.52

>>800
そうだよ。
そんでもって大抵の人間は設計がヘタクソだし、
ヘタなところが検出されるなら検出されないより良い。

**デフォルトの名無しさん** · 2020/02/13(木) 14:01:13.64

>>799
変数束縛やら所有権や借用の概念が複雑すぎて、そっちの方が C/C++の
メモリ管理よりミスし易い。

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/13(木) 14:13:53.49

>>802
間違いなくミスし易いけどミスした箇所が検出できないということはあまりない。

**デフォルトの名無しさん** · 2020/02/13(木) 14:20:14.02

設計がヘタクソなヤツが書いたソースのメンテやらされるのは最悪だけど自分で組み上げるならC++以外有り得ない
各々の力量が顕著に表れやすい最高の言語には違いない
バカも容易に炙り出せるしな

**デフォルトの名無しさん** · 2020/02/13(木) 14:20:33.11

>>803
仮にあなたはちゃんと理解できても、一般のプログラマは変数束縛やら所有権や借用の概念を理解することが難しすぎるので、C/C++を置き換える言語にはならない。
それらの概念は学習コストが高すぎるどころか、一生理解できないプログラマが多いだろう。

**はちみつ餃子** ◆8X2XSCHEME · 2020/02/13(木) 15:53:13.34

>>805
誤解のないように補足しておくけど、俺は Rust が C++ を置き換えるという主張はしてないからね。
C++ の重大な欠点を (実行コストをあまり払わない形で) 改善しているのは確かってだけ。
そんでもってそれが必要な場面は間違いなくあるってことも。

**デフォルトの名無しさん** · 2020/02/13(木) 19:21:34.29

>>791
わかる人いませんか？

**デフォルトの名無しさん** · 2020/02/13(木) 19:29:34.59

>>807
new TYPE[] のようにしてヒープから配列として確保されたメモリは確かに
要素数の情報を持っている。
しかし、new TYPEのように配列ではない場合は、高速化のために情報を
持ってない処理系もある。そのために前者では delete[] を、後者では
deleteを使うことになっており、間違った組み合わせを使った場合には
不具合を生じる。

また、ポインタは、ヒープから確保された配列ばかりをポイントしているとは
限らず、例えばスタック上のローカルオート変数や、グローバル変数をポイント
していることもあり、その場合には、要素数の情報は全く持っていない。

さらに、Cの場合、関数の引数に TYPE buf[] のように配列を書いても、
TYPE *buf に自動修正される仕様となっている。
そのため、配列を受け取るのは、必ずポインタということになる。
しかし、ポインタで受け取るということは、そこには、&a のように、
ローカルオート変数も実引数として指定して呼び出すことも出来る。
その場合には要素数が無いので、あなたの望みをかなえる高速な
一般的方法が存在しない。

望みをかなえるためには、言語の拡張が必要となる。

**デフォルトの名無しさん** · 2020/02/13(木) 19:33:05.83

Rustっていろいろ清々しいよね
関数型言語に必須じゃねえのと思うリスト関係がぽっかり抜けてるのは不満だけど

**デフォルトの名無しさん** · 2020/02/13(木) 19:57:05.87

>>807
https://ideone.com/DfYRYS

**デフォルトの名無しさん** · 2020/02/13(木) 20:01:17.55

>>808
ヒープに確保した配列の要素数はやはりメモリ上にあるんですね
手段がないのは文法として一貫性をもたせられないからということでしょうか
なるほど、回答ありがとうございます

**デフォルトの名無しさん** · 2020/02/13(木) 20:08:49.19

delete [] pと同じように
sizeof [] pを用意すりゃいいのにね
pがnew []されてなかったら誤動作するって挙動ならdeleteと同じだろうに

**デフォルトの名無しさん** · 2020/02/13(木) 20:15:32.26

言いたいことは分かるが構文がきもい

**デフォルトの名無しさん** · 2020/02/13(木) 20:17:34.65

欲しいなら作れば？
それができるのがc++じゃん

◆QZaw55cn4c · 2020/02/13(木) 20:36:41.73

>>791
＞C++の配列は長さの情報を持ってないってことになってるけど
＞長さを与えなくてもdelete[]できるんだから、メモリのどこかにその情報はあるよね？

new したときは、その領域サイズが実行時にユーザーのみえないところに保存される、というだけなのでは？
C/C++ の配列は長さ情報を（自分でそう書かないかぎり）持たないとおもいますよ

**デフォルトの名無しさん** · 2020/02/13(木) 20:38:39.62

ちゃうねん。

**デフォルトの名無しさん** · 2020/02/13(木) 20:50:05.52

設計がダメな場合コンパイラにいくら指摘されようと根本的には治らんのだが、
（たいていそういう馬鹿はコンパイラ通すためにmut,RefCell,unsafeを使いまくる）
そういうのを少しもわかってないバカがrust推しなんだよなぁ。
構造体を１から作り直さなきゃならんかったり根本的に間違ってる。

**デフォルトの名無しさん** · 2020/02/13(木) 21:00:18.27

>>808
new TYPE[]するとき内部的にサイズ情報を持つ保証ってあったっけ？
例えば自前でoperator new []を実装するとき、予め2^nバイトのブロックを所定の数用意しておいて、要求サイズに応じて必要十分な大きさのブロックを返すなら、割り当て時に要求されたバイト数または要素数の情報を保持しないという実装も可能かと思う。

**デフォルトの名無しさん** · 2020/02/13(木) 21:18:32.64

>>811
いえいえ

**デフォルトの名無しさん** · 2020/02/13(木) 21:37:18.24

>>818
デストラクタ呼ぶ必要ある

**デフォルトの名無しさん** · 2020/02/13(木) 21:39:24.09

デストラクタ呼ぶ必要ない型だと、size情報持ってないと言うことなんだろうね

**デフォルトの名無しさん** · 2020/02/13(木) 21:40:36.17

>>820
デストラクタの実装も、返ってきたアドレスの値でどのサイズの領域か(割り当て要求されたサイズではなく、自分で区切ったブロックのサイズ)が分かるようにしておけば大丈夫でないかな？

**デフォルトの名無しさん** · 2020/02/13(木) 21:41:24.98

>>822
すまん、勘違いでした。全部忘れてください

**デフォルトの名無しさん** · 2020/02/13(木) 22:02:22.87

はい忘れました。

**デフォルトの名無しさん** · 2020/02/13(木) 22:06:16.93

アドレスだけじゃなくて長さも受け渡しするインターフェースにしましょうとしか。

**デフォルトの名無しさん** · 2020/02/13(木) 22:36:33.13

シリアル化の王道ってありますか？

**デフォルトの名無しさん** · 2020/02/13(木) 22:45:19.55

オブジェクトならCORBA、データ構造だけでいいならASN.1とか。

**デフォルトの名無しさん** · 2020/02/13(木) 22:54:55.06

>>822
TYPEがデストラクタを持つclassの場合に、ptr = new TYPE[n] で確保されたメモリ
を delete[] ptr とすると、正確に n 回デストラクタを呼び出す必要がある。
new が n * sizeof(TYPE) より大きめのブロックを確保した場合でも、
delete[] ptr 時に正確な n の値を割り出す方法が必要となる。
なので、n の値は ptr の値さえあれば知ることが出来ることが必要条件となる。
つまり、少なくともデストラクタを持つ TYPE の場合に TYPE の配列をヒープから
確保した場合には、配列の要素数を必ず配列の先頭のポインタの値から「知る」事が出来る。

**デフォルトの名無しさん** · 2020/02/13(木) 23:01:33.00

>>827
もうちょっと簡単なのないですかね。
型情報要らないんで。