create-native-map - онлайн у хмарі

ПРОГРАМА:

ІМ'Я

create-native-map - C/C# Mapping Creator

СИНТАКСИС

створити рідну карту [OPTIONS]* ASSEMBLY-FILE-NAME OUTUT-PREFIX

ВАРІАНТИ

--autoconf-header=ЗАГОЛОВНИК
HEADER - це ім'я заголовного файлу в синтаксисі, який зазвичай використовується з C #включати
заява, напр #включати or #включати "local.h" .

Макрос у форматі Autoconf генерується з імені включення та a #включати
Директива загорнута в a #ifdef блок для макросу Autoconf в межах
генерується .c файлу.

Наприклад, --autoconf-header= згенерує код:

#ifndef HAVE_STDIO_H
#включати
#endif /* ndef HAVE_STDIO_H */

--autoconf-member=ЧЛЕН
Вкажіть будь-який доступ до ЧЛЕН слід загорнути в а #ifdef HAVE_MEMBER
блок ЧЛЕН може бути або a ім'я поля або ім'я класу . ім'я поля
комбінація

Наприклад, враховуючи декларацію C#:

[Mono.Unix.Native.Map ("struct dirent")]
struct Dirent {
публічний довгий d_off;
}

потім --autoconf-member=d_off генеруватиме код, схожий на:

Int
ToDirent (структура dirent *від, структура Dirent *to)
{
#ifdef HAVE_STRUCT_DIRENT_D_OFF
до->d_off = від->d_off;
#endif /* ndef HAVE_STRUCT_DIRENT_D_OFF */
}

--exclude-native-symbol=СИМВОЛ
СИМВОЛ це [DllImport] -позначений метод, який слід НЕ мати згенерований прототип
за це.

--impl-header=ЗАГОЛОВНИК
Вставте a #включати заяву в межах сформованого .c файл для HEADER .

Наприклад, --impl-header= генерує

#включати

--impl-macro=МАКРО
Вставте a #визначити заяву в межах сформованого .c файлу. MACRO може містити a = до
відокремити назву макросу від значення макросу.

Наприклад, --impl-macro=FOO=42 генерує

#define FOO 42

--library=БІБЛІОТЕКА
Створіть прототипи для [DllImport] -позначені методи, які посилаються на рідний
бібліотека БІБЛІОТЕКА у створене .h файлу.

--public-header=ЗАГОЛОВНИК
Вставте a #включати заяву в межах сформованого .h файл для HEADER .

Наприклад, --public-header= генерує

#включати

--public-macro=МАКРО
Вставте a #визначити заяву в межах сформованого .h файлу. MACRO може містити a = до
відокремити назву макросу від значення макросу.

Наприклад, --public-macro=FOO=42 генерує

#define FOO 42

--rename-member=FROM=ДО
Це використовується, коли З є макросом C, тому його потрібно змінити для використання
розсудливо. Використовуватимуться всі згенеровані посилання на кероване представлення TO замість
of З .

Наприклад, враховуючи декларацію C#:

[Mono.Unix.Native.Map ("struct stat")]
struct Stat {
публічний довгий st_atime;
}

і аргумент --rename-member=st_atime=st_atime_ , створений .h файл буде
містять:

struct Stat {
gint64 st_atime_;
};

(зверніть увагу на змінене ім’я поля), а згенерований .c файл буде містити:

ToStat (struct stat *from, struct Stat *to)
{
to->st_atime_ = from->st_atime;
}

--rename-namespace=FROM=ДО
За замовчуванням "простір імен" C (префікс символу) є простором імен C#; типи всередині
Простір імен C# Mono.Unix.Native буде в "просторі імен" C Mono_Unix_Native . Використовувати
--rename-простір імен щоб змінити значення за замовчуванням, напр --перейменувати-
простір імен=Mono.Unix.Native=Mono_Posix .

ОПИС

створити рідну карту це програма для конкретного сценарію: збереження коду, який щільно
поєднані між C і C# синхронно один з одним, на основі типів C#.

Platform Invoke корисний лише в тому випадку, якщо керований код знає точні типи та розташування всіх
некеровані структури, які він використовує. Зазвичай це відбувається в Windows, але це так НЕ випадок
на Unix. Наприклад, структура stat використовує типи з розмірами, які будуть відрізнятися від
від платформи до платформи (або навіть на основі визначених макросів компілятора!). Наприклад, off_t
зазвичай це 32-розрядне ціле число зі знаком на платформах ILP32, але може бути 64-розрядним числом зі знаком
на платформах LP64, але також може бути 64-розрядним цілим числом зі знаком на платформах ILP32, якщо
_FILE_OFFSET_BITS макрос має значення 64. Коротше кажучи, все гнучке в Unix,
і керований код не може впоратися з такою гнучкістю.

Таким чином, ніша для створити рідну карту : припустимо фіксований ABI, на який може націлюватися керований код,
і генерувати код, щоб "перезавантажувати" керовані представлення до відповідного рідного
уявлення. Це потрібно зробити для все які можуть відрізнятися на різних платформах і
прапори компілятора зі значень перерахування ( СИГБУС має значення 10 у FreeBSD, але 7 на
Linux), щоб структурувати членів (наскільки великий off_t ?).

створити рідну карту буде оглядати ASSEMBLY-FILE-NAME і вивести такі файли:

OUTPUT-PREFIX.h
Містить значення перерахування, оголошення класів і структури, делегат
декларації та [DllImport] -позначені методи (з бібліотеки, зазначеної в
-- бібліотека ) в межах зборів ASSEMBLY-FILE-NAME .

OUTPUT-PREFIX.c
Містить реалізацію перерахування та перетворення структури
функції.

OUTPUT-PREFIX.cs
Містить частковий клас NativeConvert містить переклад перерахування
методи

OUTPUT-PREFIX.xml
Генерує заглушки документації ECMA XML для перекладу перерахування
методи в OUTPUT-PREFIX.cs .

створити рідну карту в першу чергу шукає MapAttribute -декоровані типи, і використовує два
MapAttribute властивості:

NativeType
Містить відповідний тип C. Корисно, лише якщо застосовано до класів,
структури та поля.

Придушити прапори
Якщо вказано на члені переліку a [Прапори] -оформлена нумерація
типу, відключає звичайна підтримка генератора коду для перерахування бітового маскування
типи.

Це корисно, коли інформація з бітовою та нерозрядною масками зберігається в файлі
одного типу, і перевірка бітової маски не повинна використовуватися для небітової маски
цінності. приклад: Mono.Unix.Native.FilePermissions.S_IFREG , що не є a
значення бітової маски, тоді як більшість з Дозволи файлів складається зі значень бітової маски (
FilePermissions.S_IRUSR , FilePermissions.S_IWUSR І т.д.).

Команда MapAttribute атрибут можна вказати для класів, структур, делегатів, полів і
перерахування.

Делегати
Генерація коду для делегатів ігнорує MapAttribute.NativeType майно, і
генерує покажчик функції typedef що найкраще відповідає декларації делегата
в .h файлу.

Наприклад,

простір імен Foo {
[Карта]
рядок делегату MyCallback (рядок s);
}

генерує typedef :

typedef char* (*Foo_MyCallback) (const char *s);

Класи та структури
A [Карта] -decorated клас або структура отримають оголошення структури C всередині
.h Файл:

[Карта]
struct Foo {
публічний int i;
}

стає

struct Foo {
публічний int i;
};

Якщо MapAttribute.NativeType властивість встановлено, то будуть функції перетворення
оголошені в межах .h файл і створений у межах .c Файл:

простір імен Foo {
[Карта ("struct stat")]
struct Stat {
public uint st_uid;
}
}

стає

/* Файл .h */
struct Foo_Stat {
unsigned int st_uid;
};
Int
Foo_FromStat (структура Foo_Stat *від, структура stat *to);
Int
Foo_ToStat (struct stat *to, sxtruct Foo_Stat *to);

/* Файл .c */
Int
Foo_FromStat (структура Foo_Stat *від, структура stat *до)
{
memset (до, 0, sizeof(*до);
до->st_uid = від->st_uid;
0 повернутися;
}

Int
Foo_ToStat (struct stat *to, sxtruct Foo_Stat *to)
{
memset (до, 0, sizeof(*до);
до->st_uid = від->st_uid;
0 повернутися;
}

Для класів функції перетворення копіюють лише поля, оголошені в класі
себе. Поля, оголошені в батьківських класах, не копіюватимуться. (Це відбувається тому
створити рідну карту не знає, як реалізується успадкування в C. Тому
копіювання полів із батьківських класів залишається на розпорядник перетворення
функції.)

Поля Якщо поле (1) має значення MapAttribute атрибут, і (2) має
MapAttribute.NativeType набір властивостей, то буде використаний вказаний рідний тип
для перевірки переповнення. Наприклад:

простір імен Foo {
[Карта ("struct stat")]
struct Stat {
[Map ("off_t")] public long st_size;
}
}

генерує

/* Файл .h */
struct Foo_Stat {
gint64 st_size;
};
Int
Foo_FromStat (структура Foo_Stat *від, структура stat *to);
Int
Foo_ToStat (struct stat *to, sxtruct Foo_Stat *to);

/* Файл .c */
Int
Foo_FromStat (структура Foo_Stat *від, структура stat *до)
{
_cnm_return_val_if_overflow (off_t, from->st_size, -1);

memset (до, 0, sizeof(*до);
до->st_size = від->st_size;
0 повернутися;
}

Int
Foo_ToStat (struct stat *to, sxtruct Foo_Stat *to)
{
_cnm_return_val_if_overflow (gint64, from->st_size, -1);

memset (до, 0, sizeof(*до);
до->st_size = від->st_size;
0 повернутися;
}

Це корисно для кращої перевірки помилок у функціях перетворення.
MapAttribute.NativeType для цього потрібно, оскільки немає іншого способу дізнатися, що
рідний тип (без аналізу файлів заголовків системи...).

Перерахування
Генерує перерахування C і макроси для кожного з членів у межах
перерахування. До та Від функції також оголошуються в .h файл і
реалізовано в .c файлу.

Наприклад,

простір імен Foo {
[Карта]
enum Errno {
EINVAL
}
}

генеруватиме наступне в .h Файл:

enum Foo_Errno {
Foo_Errno_EINVAL = 0,
#define Foo_Errno_EINVAL Foo_Errno_EINVAL
};
int Foo_FromErrno (int from, int *to);
int Foo_ToErrno (int from, int *to);

і створює наступне в файлі .c Файл:

Int
Foo_FromErrno (int from, int *to)
{
*до = 0;
якщо (з == Foo_Errno_EPERM)
#ifdef EINVAL
{*до = EINVAL;}
#else
{errno = EINVAL; повернути -1;}
#endif
0 повернутися;
}

Int
Foo_ToErrno (int from, int *to)
{
*до = 0;
#ifdef EINVAL
якщо (від == EINVAL)
{*to = Foo_Errno_EPERM; повернути 0;}
#endif
return -1;
}

Буде згенерований інший код, якщо керований перелік є a [Прапори] -декорований
перерахування (для врахування побітових прапорів), але це основна ідея.

ПОШТА СПИСКИ

Visit http://lists.ximian.com/mailman/listinfo/mono-devel-list for details.

WEB САЙТ

Visit http://www.mono-project.com докладніше

створити рідну карту(1)

Використовуйте create-native-map онлайн за допомогою служб onworks.net