回答編集履歴

1

append

2019/02/22 04:02

投稿

yumetodo
yumetodo

スコア5850

test CHANGED
@@ -29,3 +29,81 @@
29
29
 
30
30
 
31
31
  となるんじゃないでしょうかね?
32
+
33
+
34
+
35
+ ---
36
+
37
+
38
+
39
+ C++/CLIが嫌いすぎて脳みそから消去してた内容をググって回復したので追記。
40
+
41
+
42
+
43
+ ```cpp
44
+
45
+ namespace funcBasic {
46
+
47
+
48
+
49
+ ref class DataImport
50
+
51
+ {
52
+
53
+ private:
54
+
55
+ deque<string>* m_array;
56
+
57
+ public:
58
+
59
+ DataImport()
60
+
61
+ {
62
+
63
+ //newするのは一つだけ!2つ以上したくなったらdeque<string>をクラス分け!
64
+
65
+ m = new deque<string>();
66
+
67
+ }
68
+
69
+ !DataImport()
70
+
71
+ {
72
+
73
+ if (m != nullptr)
74
+
75
+ delete m;
76
+
77
+ m = nullptr;
78
+
79
+ }
80
+
81
+ ~DataImport()
82
+
83
+ {
84
+
85
+ this->!DataImport();
86
+
87
+ }
88
+
89
+ };
90
+
91
+ }
92
+
93
+ ```
94
+
95
+
96
+
97
+ コンストラクタでnewした上で!DataImportと~DataImport (C#でいうデストラクタとDispose)を実装します。
98
+
99
+
100
+
101
+ ところが問題があって、そもそもstd::dequeの内部で行われるメモリー確保が.NETのGCで検知されないため、このままだとメモリーがなかなか開放されないということが起こります。つまりアロケータを作るわけですね。
102
+
103
+
104
+
105
+ でアロケータをバグなく作るとか本当に無理ゲーなのでやりたくないわけです。なんならOpenCVSharp作った人も本番実装に入れてないわけです。つまりなかなかメモリが開放されない問題は諦めたわけですね。まあC#側では`using`ブロックだっけかできちんとDisposeしてもらうようにしろということですね。
106
+
107
+
108
+
109
+ で結論としてはそんな意味不明な苦労するんじゃなくて`Generic::List`とかを最初から使うのがいいんじゃないですかね・・・