С использованием специфичного для SDK API или стандартных функций c

gcc (GCC) 4.7.2
PJ SIP 2.1

Здравствуйте,

Я разрабатываю приложение, которое будет использовать API PJSIP.

Просто посмотрите на документацию по API, и я вижу некоторые функции, которые кажутся просто оболочками для стандартной библиотеки C. т.е. pj_memset, pj_strncpy, pj_strlen и т.д.

Я могу видеть некоторые альтернативы, которые можно было бы рассмотреть pj_strncpy_with_null(), который всегда будет NULL для завершения строки. Другим преимуществом может быть то, что pjsip использует структуру pj_str_t для хранения строки и размера. Это может быть лучше, чем использование обычной строки C.

И есть ли какая-либо точка, использующая pj_size_t over size_t, которая в любом случае переносима?

Ссылка для быстрой справки находится здесь:

http://www.pjsip.org/pjlib/docs/html/group__PJ__PSTR.htm

Есть ли какое-то реальное преимущество, использующее PJSIP над стандартной библиотекой C?

Большое спасибо за любые предложения,

Ответ 1

Краткий ответ: используйте PJSIP API (все это).

Длинный ответ: это зависит.

Если вы программировали приложение для стандартных настольных компьютеров, то есть x86/x64 Windows/Mac/Linux, то нет, это не имеет большого значения, если вы использовали стандартную библиотеку C или обертки, такие как функции PJSIP. Практически, конечно, могут быть функции, которые принимают (как вы указали) структуру pj_str_t вместо char *; тогда было бы проще использовать PJSIP API только для упрощения и устранения необходимости конверсий.

Причина для оболочек, я полагаю, заключается в том, чтобы упростить разработку на встроенных устройствах. Я не имею в виду только ARM или другие процессоры, отличные от x86, хотя он может применяться и там; Я имею в виду пользовательские встроенные устройства: вещи, которые имеют очень специфическую цель и изменяются редко. Эти встроенные устройства имеют очень ограниченные возможности и иногда даже не имеют ОС. Без ОС эти процессоры могут не иметь функции malloc или тому подобного. Часто библиотеки, связанные с устройствами, поскольку они настроены так сильно, не являются полностью "стандартными" и отличаются небольшим образом. Имея обертки для всего, PJSIP может избежать большинства проблем и даже обеспечивать реализацию по всем вещам, например, strcpy или malloc, чтобы все устройства запускали "тот же" код.

Упаковщики также предоставляют средства для "крючков". Крючки позволяют лучше отправлять сообщения об ошибках (и, возможно, обрабатывать). Неясно, делает ли это PJSIP (я никогда не использовал PJSIP - я говорю из опыта, используя другие фреймворки), но я указываю, что это просто показать, почему инфраструктура может беспокоить все.

В конце концов, это сводится к вашей цели: если вы решили использовать PJSIP в первую очередь, я бы изо всех сил использовал весь свой API. Если вы используете его только в нескольких местах (по какой-либо причине), то это, вероятно, не имеет значения. Опять же, похоже, что PJSIP нацеливается на встроенные устройства (в нем перечислены системы Nokia и даже RTOS), где довольно распространено предоставление оболочек для "стандартных" функций. Если это так, и вы используете его таким образом, обязательно используйте весь API.

Ответ 2

Будете ли вы придерживаться pjsip?

Исходный код PJSIP ( "Программное обеспечение" ) лицензируется как по общему Публичная лицензия (GPL) версии 2 или более поздней версии и собственная лицензия, которая могут быть расположены...

Если вы считаете, что GPL может быть слишком ограничительным для будущего расширения (например, политика Android no-GPL in-userspace для Android), и их собственная лицензия неприемлема, вы можете воспользоваться своими портативными кодеками/обертками, которые могли бы использовать с менее строгой библиотекой BSD stlye, например Baresip

Существует множество других способов обеспечения необходимой функциональности, где стандартная библиотека C не поддерживает ее, многие из которых будут лучше проверены (я ненавижу упоминать autotools, но... она поддерживает большинство платформ - некоторые сказали бы слишком много). Или вы можете включить реализации/адаптации из musl-libc

Еще одна вещь, которую следует учитывать, - это то, что C api основывается на стандартах и ​​довольно укладывается в камень, в то время как обертки в заданном проекте гораздо более свободны для прерывания API-совместимости от версии к версии (просто спросите программиста glib/gtk)