回答編集履歴
4
修正
answer
CHANGED
|
@@ -9,4 +9,4 @@
|
|
|
9
9
|
1であれば、CppCode側でバッファ確保する必要はないでしょうし、呼び出し側からバッファのサイズも引数で渡すべきです。
|
|
10
10
|
2であれば、C#側でLPWStrを指定してるのはおかしいです。また、CppCodeで確保したメモリ解放用の関数も用意する必要があります。
|
|
11
11
|
1、2どちらの場合も、コピーした文字列の長さを返したほうがいいでしょう。
|
|
12
|
-
個人的には、1の方が解放用の関数用意しなくてい
|
|
12
|
+
個人的には、1の方が解放用の関数用意しなくて済みますし、Cの標準関数の実装に近いので好みです。
|
3
修正
answer
CHANGED
|
@@ -7,4 +7,6 @@
|
|
|
7
7
|
|
|
8
8
|
どちらなのでしょう？サンプルコードを見る限り、両方でバッファ確保しようとしてますが。
|
|
9
9
|
1であれば、CppCode側でバッファ確保する必要はないでしょうし、呼び出し側からバッファのサイズも引数で渡すべきです。
|
|
10
|
-
2であれば、
|
|
10
|
+
2であれば、C#側でLPWStrを指定してるのはおかしいです。また、CppCodeで確保したメモリ解放用の関数も用意する必要があります。
|
|
11
|
+
1、2どちらの場合も、コピーした文字列の長さを返したほうがいいでしょう。
|
|
12
|
+
個人的には、1の方が解放用の関数用意しなくていいので良いと思います。
|
2
修正
answer
CHANGED
|
@@ -2,9 +2,9 @@
|
|
|
2
2
|
|
|
3
3
|
あとは、なんだか関数の設計自体もおかしい気がします。
|
|
4
4
|
|
|
5
|
-
0. 呼び出し側でバッファ
|
|
5
|
+
0. 呼び出し側でバッファ確保するのが前提
|
|
6
6
|
0. CppCode側でバッファ確保するのが前提
|
|
7
7
|
|
|
8
8
|
どちらなのでしょう？サンプルコードを見る限り、両方でバッファ確保しようとしてますが。
|
|
9
|
-
1であれば、CppCode側でバッファ確保する必要はないでしょうし、バッファのサイズも引数で渡すべきです。
|
|
9
|
+
1であれば、CppCode側でバッファ確保する必要はないでしょうし、呼び出し側からバッファのサイズも引数で渡すべきです。
|
|
10
10
|
2であれば、バッファの文字列の長さを返すなりしたほうがいいでしょうし、CppCodeで確保したメモリ解放用の関数も必要でしょう。
|
1
修正
answer
CHANGED
|
@@ -1,5 +1,4 @@
|
|
|
1
|
-
まずDllImportの定義自体が引数の数が違ってるし、呼び出し規約も書いてないし、voidなのにreturnのマーシャリング定義してるし、色々間違ってる気がします。
|
|
2
|
-
あと、[ネイティブ相互運用性のベスト プラクティス](https://docs.microsoft.com/ja-jp/dotnet/standard/native-interop/best-practices)では、StringBuilderでの受け渡しは回避すべき項目として記述されています。
|
|
1
|
+
まずDllImportの定義自体が引数の数が違ってるし、呼び出し規約も書いてないし、voidなのにreturnのマーシャリング定義してるし、色々間違ってる気がします。あと、[ネイティブ相互運用性のベスト プラクティス](https://docs.microsoft.com/ja-jp/dotnet/standard/native-interop/best-practices)では、StringBuilderでの受け渡しは回避すべき項目として記述されています。
|
|
3
2
|
|
|
4
3
|
あとは、なんだか関数の設計自体もおかしい気がします。
|
|
5
4
|
|