Les sections suivantes m'ont fait tiquer :
Do NOT Use ANSI C
Contrary to popular teaching, ANSI C (and LIBC) is not the most portable library in the world, nor it's the most ubiquitous. For example, LIBC is not available in Linux kernel. Also normally LIBC will be excluded from compilation of RTOSes to reduce size.
So for maximum portability, do NOT use ANSI C. Do not even try to include any other header files outside <include/pj>. Stick with the functionalities provided by PJLIB.
Use pj_str_t instead of C Strings
PJLIB uses pj_str_t instead of normal C strings. You SHOULD follow this convention too. Remember, ANSI string-h is not always available. And PJLIB string is faster!
Use Pool for Memory Allocations
You MUST NOT use malloc() or any other memory allocation functions. Use PJLIB Fast Memory Pool instead! It's faster and most portable.
[...]
DO NOT use <stdio.h> for text output. Use PJLIB Logging Facility instead.
et la lib ré-implémente au moins ceci :
- Threads
- Thread Local Storage
- Mutexes
- Semaphores.
- Event Object.
- Time Data Type and Manipulation.
- High Resolution Timestamp
- Socket Abstraction
- String Operations (ses propres chaînes)
- Exception Construct (mise en place d'un mécanisme d'exception à l'aide de jump)
- Memory pool (surcouche au malloc, etc)
Ma question est donc qu'est réellement le PJSIP ? Il est dit ceci :
PJSIP is an Open Source SIP prototol stack, designed to be very small in footprint, have high performance, and very flexible.
Mais cela ressemble plus à un framework à la Qt et autres qu'à une implémentation d'un protocole.
Petite question annexe :
Je ne sais pas si ne pas s'appuyer sur le C Ansi (ou ce qui est normalisé de façon générale) est une bonne idée, car développer des applications avec cette librairie rend celles-ci très dépendantes de la dite-librairie. Autant s'appuyer sur le framework de Qt, de GTK, des MFC rend les applications dépendantes de ces frameworks, autant ces frameworks assurent une certaine pérénité à l'ensemble du produit, quid de la durée de vie cette librairie ?
# Questions sur choix techniques (sur PJSIP)
Posté par lem__mel . En réponse au journal PJsip et Python. Évalué à 1.
Do NOT Use ANSI C
Contrary to popular teaching, ANSI C (and LIBC) is not the most portable library in the world, nor it's the most ubiquitous. For example, LIBC is not available in Linux kernel. Also normally LIBC will be excluded from compilation of RTOSes to reduce size.
So for maximum portability, do NOT use ANSI C. Do not even try to include any other header files outside <include/pj>. Stick with the functionalities provided by PJLIB.
Use pj_str_t instead of C Strings
PJLIB uses pj_str_t instead of normal C strings. You SHOULD follow this convention too. Remember, ANSI string-h is not always available. And PJLIB string is faster!
Use Pool for Memory Allocations
You MUST NOT use malloc() or any other memory allocation functions. Use PJLIB Fast Memory Pool instead! It's faster and most portable.
[...]
DO NOT use <stdio.h> for text output. Use PJLIB Logging Facility instead.
et la lib ré-implémente au moins ceci :
- Threads
- Thread Local Storage
- Mutexes
- Semaphores.
- Event Object.
- Time Data Type and Manipulation.
- High Resolution Timestamp
- Socket Abstraction
- String Operations (ses propres chaînes)
- Exception Construct (mise en place d'un mécanisme d'exception à l'aide de jump)
- Memory pool (surcouche au malloc, etc)
tout ça à la page suivante : http://www.pjsip.org/pjlib/docs/html/main.htm
Ma question est donc qu'est réellement le PJSIP ? Il est dit ceci :
PJSIP is an Open Source SIP prototol stack, designed to be very small in footprint, have high performance, and very flexible.
Mais cela ressemble plus à un framework à la Qt et autres qu'à une implémentation d'un protocole.
Petite question annexe :
Je ne sais pas si ne pas s'appuyer sur le C Ansi (ou ce qui est normalisé de façon générale) est une bonne idée, car développer des applications avec cette librairie rend celles-ci très dépendantes de la dite-librairie. Autant s'appuyer sur le framework de Qt, de GTK, des MFC rend les applications dépendantes de ces frameworks, autant ces frameworks assurent une certaine pérénité à l'ensemble du produit, quid de la durée de vie cette librairie ?