回答編集履歴
2
追記
answer
CHANGED
|
@@ -11,5 +11,17 @@
|
|
|
11
11
|
---
|
|
12
12
|
補足
|
|
13
13
|
|
|
14
|
-
↑に書いた内容はWindowsのDLLの場合ですね。元記事をもう少し読み進めていったら、.soファイルとか書いてあるのでLinuxかMacということでしょう
|
|
14
|
+
↑に書いた内容はWindowsのDLLの場合ですね。元記事をもう少し読み進めていったら、.soファイルとか書いてあるので、LinuxかMacということでしょう。となると、バージョン不整合は問題になるかもしれません。
|
|
15
|
-
まぁ、そうだとしても、コンパイラーのバージョンが変わったらリビルドすれば良いだけなので、STLを使ってはいけないという縛りをあえて設ける必要なないと思います。
|
|
15
|
+
まぁ、そうだとしても、コンパイラーのバージョンが変わったらリビルドすれば良いだけなので、STLを使ってはいけないという縛りをあえて設ける必要なないと思います。
|
|
16
|
+
|
|
17
|
+
---
|
|
18
|
+
追記
|
|
19
|
+
|
|
20
|
+
肝心なことを忘れていました。
|
|
21
|
+
|
|
22
|
+
> いざ、作成した dll を Unity 上で利用しようとすると、「std::map の count() で、そのキーが存在しているにもかかわらずカウントされない」とか、「std::for_each の処理に差し掛かったら落ちる」などあり、正常に動作しません。
|
|
23
|
+
|
|
24
|
+
テストアプリというのはC#で作ったのでしょうか？ なるべく利用環境に近い状態でテストする必要があります
|
|
25
|
+
エクスポート関数の引数などにコンテナが含まれていませんか？ 前述の通り、C#のDllImportで呼べるのはC形式の関数のみです。
|
|
26
|
+
|
|
27
|
+
実際のところ、どのように作ってどのように呼んでいるのかが判らないので、なんとも答えようがありません。可能であればソースコードを提示していただければ、もう少し適切に回答できるかもしれません。
|
1
補足
answer
CHANGED
|
@@ -4,6 +4,12 @@
|
|
|
4
4
|
|
|
5
5
|
それは「Cocos2d-x」の文脈で語られていることですよね。Cocos2d-xはいじったことがないのでよく判りませんが、プラグインはスタティックライブラリー形式なのでしょうか。だとしたら、バージョン不整合は問題になります。
|
|
6
6
|
|
|
7
|
-
一方、Unity(というかC#)に関しては、DLLを動的リンクする方式なので、インターフェイス部分(関数プロトタイプ)さえきっちり決められていれば、中身をどう書こうと自由です。STLを使っても良いですし、boostのような外部ライブラリーを使っても何の問題もありません。たとえコンパイラーのバージョンが違っていても(
|
|
7
|
+
一方、Unity(というかC#)に関しては、DLLを動的リンクする方式なので、インターフェイス部分(関数プロトタイプ)さえきっちり決められていれば、中身をどう書こうと自由です。STLを使っても良いですし、boostのような外部ライブラリーを使っても何の問題もありません。たとえコンパイラーのバージョンが違っていても(基本的には)問題にはなりません。
|
|
8
8
|
|
|
9
|
-
ただし、C#のDllInportの場合「C形式の関数」しか対応していないので、引数
|
|
9
|
+
ただし、C#のDllInportの場合「C形式の関数」しか対応していないので、引数にSTLコンテナを使うようなことはできません。それが制限といえば制限かもしれませんね。そのため、中身はクラスで実装するけど、C#向けにはC形式のラッパー関数を作ってそれをエクスポートする、ということをよくやります。
|
|
10
|
+
|
|
11
|
+
---
|
|
12
|
+
補足
|
|
13
|
+
|
|
14
|
+
↑に書いた内容はWindowsのDLLの場合ですね。元記事をもう少し読み進めていったら、.soファイルとか書いてあるのでLinuxかMacということでしょうか。となると、バージョン不整合は問題になるかもしれません。
|
|
15
|
+
まぁ、そうだとしても、コンパイラーのバージョンが変わったらリビルドすれば良いだけなので、STLを使ってはいけないという縛りをあえて設ける必要なないと思います。
|