Some options for libjson that are needed by this project
This commit is contained in:
parent
10918ac643
commit
91c95dfe38
1 changed files with 21 additions and 22 deletions
|
|
@ -8,22 +8,22 @@
|
|||
|
||||
|
||||
/*
|
||||
* JSON_LIBRARY must be declared if libjson is compiled as a static or dynamic
|
||||
* JSON_LIBRARY must be declared if libjson is compiled as a static or dynamic
|
||||
* library. This exposes a C-style interface, but none of the inner workings of libjson
|
||||
*/
|
||||
#define JSON_LIBRARY
|
||||
//#define JSON_LIBRARY
|
||||
|
||||
|
||||
/*
|
||||
* JSON_STRICT removes all of libjson's extensions. Meaning no comments, no special numbers
|
||||
*/
|
||||
//#define JSON_STRICT
|
||||
#define JSON_STRICT
|
||||
|
||||
|
||||
/*
|
||||
* JSON_DEBUG is used to perform extra error checking. Because libjson usually
|
||||
* JSON_DEBUG is used to perform extra error checking. Because libjson usually
|
||||
* does on the fly parsing, validation is impossible, so this option will allow
|
||||
* you to register an error callback so that you can record what is going wrong
|
||||
* you to register an error callback so that you can record what is going wrong
|
||||
* before the library crashes. This option does not protect from these errors,
|
||||
* it simply tells you about them, which is nice for debugging, but not preferable
|
||||
* for release candidates
|
||||
|
|
@ -47,7 +47,7 @@
|
|||
|
||||
|
||||
/*
|
||||
* JSON_STDERROR routes error messages to cerr instead of a callback, this
|
||||
* JSON_STDERROR routes error messages to cerr instead of a callback, this
|
||||
* option hides the callback registering function. This will usually display
|
||||
* messages in the console
|
||||
*/
|
||||
|
|
@ -79,7 +79,7 @@
|
|||
* means that libjson supports the full array of unicode characters, but also takes
|
||||
* much more memory and processing power.
|
||||
*/
|
||||
//#define JSON_UNICODE
|
||||
#define JSON_UNICODE
|
||||
|
||||
|
||||
/*
|
||||
|
|
@ -113,7 +113,7 @@
|
|||
|
||||
|
||||
/*
|
||||
* JSON_STREAM turns on libjson's streaming functionality. This allows you to give parts of
|
||||
* JSON_STREAM turns on libjson's streaming functionality. This allows you to give parts of
|
||||
* your json into a stream, which will automatically hit a callback when full nodes are
|
||||
* completed
|
||||
*/
|
||||
|
|
@ -141,7 +141,7 @@
|
|||
/*
|
||||
* JSON_MEMORY_POOL Turns on libjson's iteraction with mempool++. It is more efficient that simply
|
||||
* connecting mempool++ to the callbacks because it integrates things internally and uses a number
|
||||
* of memory pools. This value tells libjson how large of a memory pool to start out with. 500KB
|
||||
* of memory pools. This value tells libjson how large of a memory pool to start out with. 500KB
|
||||
* should suffice for most cases. libjson will distribute that within the pool for the best
|
||||
* performance depending on other settings.
|
||||
*/
|
||||
|
|
@ -150,7 +150,7 @@
|
|||
|
||||
/*
|
||||
* JSON_MUTEX_CALLBACKS exposes functions to register callbacks to lock and unlock
|
||||
* mutexs and functions to lock and unlock JSONNodes and all of it's children. This
|
||||
* mutexs and functions to lock and unlock JSONNodes and all of it's children. This
|
||||
* does not prevent other threads from accessing the node, but will prevent them from
|
||||
* locking it. It is much easier for the end programmer to allow libjson to manage
|
||||
* your mutexs because of reference counting and manipulating trees, libjson automatically
|
||||
|
|
@ -185,7 +185,7 @@
|
|||
* read and parse json, this allows it to write back out. Changing the value of the writer
|
||||
* changes how libjson compiles, and how fast it will go when writing
|
||||
*/
|
||||
#define JSON_WRITE_PRIORITY MED
|
||||
//#define JSON_WRITE_PRIORITY MED
|
||||
|
||||
|
||||
/*
|
||||
|
|
@ -197,7 +197,7 @@
|
|||
|
||||
/*
|
||||
* JSON_NEWLINE affects how libjson writes. If this option is turned on, libjson
|
||||
* will use whatever it's defined as for the newline signifier, otherwise, it will use
|
||||
* will use whatever it's defined as for the newline signifier, otherwise, it will use
|
||||
* standard unix \n.
|
||||
*/
|
||||
//#define JSON_NEWLINE "\r\n" //\r\n is standard for most windows and dos programs
|
||||
|
|
@ -215,7 +215,7 @@
|
|||
* JSON_ESCAPE_WRITES tells the libjson engine to escape special characters when it writes
|
||||
* out. If this option is turned off, the json it outputs may not adhere to JSON standards
|
||||
*/
|
||||
#define JSON_ESCAPE_WRITES
|
||||
//#define JSON_ESCAPE_WRITES
|
||||
|
||||
|
||||
/*
|
||||
|
|
@ -223,7 +223,7 @@
|
|||
* parsing json that has comments in it as it simply ignores them, but with this option
|
||||
* it keeps the comments and allows you to insert further comments
|
||||
*/
|
||||
#define JSON_COMMENTS
|
||||
//#define JSON_COMMENTS
|
||||
|
||||
|
||||
/*
|
||||
|
|
@ -244,7 +244,7 @@
|
|||
|
||||
/*
|
||||
* JSON_ARRAY_SIZE_ON_ON_LINE allows you to put small arrays of primitives all on one line
|
||||
* in a write_formatted. This is common for tuples, like coordinates. If must be defined
|
||||
* in a write_formatted. This is common for tuples, like coordinates. If must be defined
|
||||
* as an integer
|
||||
*/
|
||||
//#define JSON_ARRAY_SIZE_ON_ONE_LINE 2
|
||||
|
|
@ -260,11 +260,11 @@
|
|||
* JSON_CASE_INSENSITIVE_FUNCTIONS turns on funtions for finding child nodes in a case-
|
||||
* insenititve way
|
||||
*/
|
||||
#define JSON_CASE_INSENSITIVE_FUNCTIONS
|
||||
//#define JSON_CASE_INSENSITIVE_FUNCTIONS
|
||||
|
||||
|
||||
/*
|
||||
* JSON_INDEX_TYPE allows you th change the size type for the children functions. If this
|
||||
* JSON_INDEX_TYPE allows you th change the size type for the children functions. If this
|
||||
* option is not used then unsigned int is used. This option is useful for cutting down
|
||||
* on memory, or using huge numbers of child nodes (over 4 billion)
|
||||
*/
|
||||
|
|
@ -273,7 +273,7 @@
|
|||
|
||||
/*
|
||||
* JSON_BOOL_TYPE lets you change the bool type for the C interface. Because before C99 there
|
||||
* was no bool, and even then it's just a typedef, you may want to use something else. If this
|
||||
* was no bool, and even then it's just a typedef, you may want to use something else. If this
|
||||
* is not defined, it will revert to int
|
||||
*/
|
||||
//#define JSON_BOOL_TYPE char
|
||||
|
|
@ -290,7 +290,7 @@
|
|||
* JSON_NUMBER_TYPE lets you change the number type for as_float as well as the internal storage for the
|
||||
* number. If you omit this option, the default double will be used for most cases and float for JSON_LESS_MEMORY
|
||||
*/
|
||||
//#define JSON_NUMBER_TYPE double
|
||||
#define JSON_NUMBER_TYPE float
|
||||
|
||||
|
||||
/*
|
||||
|
|
@ -321,13 +321,13 @@
|
|||
* compatibility between major releases. It is highly recommended that you move your functions
|
||||
* over to the new equivalents
|
||||
*/
|
||||
#define JSON_DEPRECATED_FUNCTIONS
|
||||
//#define JSON_DEPRECATED_FUNCTIONS
|
||||
|
||||
|
||||
/*
|
||||
* JSON_CASTABLE allows you to call as_bool on a number and have it do the 0 or not 0 check,
|
||||
* it also allows you to ask for a string from a number, or boolean, and have it return the right thing.
|
||||
* Without this option, those types of requests are undefined. It also exposes the as_array, as_node, and cast
|
||||
* Without this option, those types of requests are undefined. It also exposes the as_array, as_node, and cast
|
||||
* functions
|
||||
*/
|
||||
#define JSON_CASTABLE
|
||||
|
|
@ -357,4 +357,3 @@
|
|||
#define JSON_SECURITY_MAX_STREAM_OBJECTS 128
|
||||
|
||||
#endif
|
||||
|
||||
|
|
|
|||
Loading…
Reference in a new issue