Jamoma API  0.6.0.a19
JSONOptions.h
1 #ifndef JSON_OPTIONS_H
2 #define JSON_OPTIONS_H
3 
4 /**
5  * This file holds all of the compiling options for easy access and so
6  * that you don't have to remember them, or look them up all the time
7  */
8 
9 
10 /*
11  * JSON_LIBRARY must be declared if libjson is compiled as a static or dynamic
12  * library. This exposes a C-style interface, but none of the inner workings of libjson
13  */
14 //#define JSON_LIBRARY
15 
16 
17 /*
18  * JSON_STRICT removes all of libjson's extensions. Meaning no comments, no special numbers
19  */
20 //#define JSON_STRICT
21 
22 
23 /*
24  * JSON_DEBUG is used to perform extra error checking. Because libjson usually
25  * does on the fly parsing, validation is impossible, so this option will allow
26  * you to register an error callback so that you can record what is going wrong
27  * before the library crashes. This option does not protect from these errors,
28  * it simply tells you about them, which is nice for debugging, but not preferable
29  * for release candidates
30  */
31 #if defined(JAMOMA_WEBSOCKET_JSON_DEBUG)
32 #define JSON_DEBUG
33 #endif
34 
35 
36 /*
37  * JSON_ISO_STRICT turns off all code that uses non-standard C++. This removes all
38  * references to long long and long double as well as a few others
39  */
40 #define JSON_ISO_STRICT
41 
42 
43 /*
44  * JSON_SAFE performs similarly to JSON_DEBUG, except this option does protect
45  * from the errors that it encounters. This option is recommended for those who
46  * feel it's possible for their program to encounter invalid json.
47  */
48 #define JSON_SAFE
49 
50 
51 /*
52  * JSON_STDERROR routes error messages to cerr instead of a callback, this
53  * option hides the callback registering function. This will usually display
54  * messages in the console
55  */
56 //#define JSON_STDERROR
57 
58 
59 /*
60  * JSON_PREPARSE causes all parsing to be done immediately. By default, libjson
61  * parses nodes on the fly as they are needed, this makes parsing much faster if
62  * your program gets a lot of information that it doesn't need. An example of
63  * this would be a client application communicating with a server if the server
64  * returns things like last modified date and other things that you don't use.
65  */
66 //#define JSON_PREPARSE
67 
68 
69 /*
70  * JSON_LESS_MEMORY will force libjson to let go of memory as quickly as it can
71  * this is recommended for software that has to run on less than optimal machines.
72  * It will cut libjson's memory usage by about 20%, but also run slightly slower.
73  * It's recommended that you also compile using the -Os option, as this will also
74  * reduce the size of the library
75  */
76 //#define JSON_LESS_MEMORY
77 
78 
79 /*
80  * JSON_UNICODE tells libjson to use wstrings instead of regular strings, this
81  * means that libjson supports the full array of unicode characters, but also takes
82  * much more memory and processing power.
83  */
84 //#define JSON_UNICODE
85 
86 
87 /*
88  * JSON_REF_COUNT causes libjson to reference count JSONNodes, which makes copying
89  * and passing them around much faster. It is recommended that this stay on for
90  * most uses
91  */
92 #define JSON_REF_COUNT
93 
94 
95 /*
96  * JSON_BINARY is used to support binary, which is base64 encoded and decoded by libjson,
97  * if this option is not turned off, no base64 support is included
98  */
99 #define JSON_BINARY
100 
101 
102 /*
103  * JSON_EXPOSE_BASE64 is used to turn on the functionality of libjson's base64 encoding
104  * and decoding. This may be useful if you want to obfuscate your json, or send binary data over
105  * a network
106  */
107 #define JSON_EXPOSE_BASE64
108 
109 
110 /*
111  * JSON_ITERATORS turns on all of libjson's iterating functionality. This would usually
112  * only be turned off while compiling for use with C
113  */
114 #define JSON_ITERATORS
115 
116 
117 /*
118  * JSON_STREAM turns on libjson's streaming functionality. This allows you to give parts of
119  * your json into a stream, which will automatically hit a callback when full nodes are
120  * completed
121  */
122 #define JSON_STREAM
123 
124 
125 /*
126  * JSON_MEMORY_CALLBACKS exposes functions to register callbacks for allocating, resizing,
127  * and freeing memory. Because libjson is designed for customizability, it is feasible
128  * that some users would like to further add speed by having the library utilize a memory
129  * pool. With this option turned on, the default behavior is still done internally unless
130  * a callback is registered. So you can have this option on and not use it.
131  */
132 //#define JSON_MEMORY_CALLBACKS
133 
134 
135 /*
136  * JSON_MEMORY_MANAGE is used to create functionality to automatically track and clean
137  * up memory that has been allocated by the user. This includes strings, binary data, and
138  * nodes. It also exposes bulk delete functions.
139  */
140 //#define JSON_MEMORY_MANAGE
141 
142 
143 /*
144  * JSON_MEMORY_POOL Turns on libjson's iteraction with mempool++. It is more efficient that simply
145  * connecting mempool++ to the callbacks because it integrates things internally and uses a number
146  * of memory pools. This value tells libjson how large of a memory pool to start out with. 500KB
147  * should suffice for most cases. libjson will distribute that within the pool for the best
148  * performance depending on other settings.
149  */
150 //#define JSON_MEMORY_POOL 524288
151 
152 
153 /*
154  * JSON_MUTEX_CALLBACKS exposes functions to register callbacks to lock and unlock
155  * mutexs and functions to lock and unlock JSONNodes and all of it's children. This
156  * does not prevent other threads from accessing the node, but will prevent them from
157  * locking it. It is much easier for the end programmer to allow libjson to manage
158  * your mutexs because of reference counting and manipulating trees, libjson automatically
159  * tracks mutex controls for you, so you only ever lock what you need to
160  */
161 //#define JSON_MUTEX_CALLBACKS
162 
163 
164 /*
165  * JSON_MUTEX_MANAGE lets you set mutexes and forget them, libjson will not only keep
166  * track of the mutex, but also keep a count of how many nodes are using it, and delete
167  * it when there are no more references
168  */
169 //#define JSON_MUTEX_MANAGE
170 
171 
172 /*
173  * JSON_NO_C_CONSTS removes consts from the C interface. It still acts the same way, but
174  * this may be useful for using the header with languages or variants that don't have const
175  */
176 //#define JSON_NO_C_CONSTS
177 
178 
179 /*
180  * JSON_OCTAL allows libjson to use octal values in numbers.
181  */
182 //#define JSON_OCTAL
183 
184 
185 /*
186  * JSON_WRITE_PRIORITY turns on libjson's writing capabilties. Without this libjson can only
187  * read and parse json, this allows it to write back out. Changing the value of the writer
188  * changes how libjson compiles, and how fast it will go when writing
189  */
190 #define JSON_WRITE_PRIORITY MED
191 
192 
193 /*
194  * JSON_READ_PRIORITY turns on libjson's reading capabilties. Changing the value of the reader
195  * changes how libjson compiles, and how fast it will go when writing
196  */
197 #define JSON_READ_PRIORITY HIGH
198 
199 
200 /*
201  * JSON_NEWLINE affects how libjson writes. If this option is turned on, libjson
202  * will use whatever it's defined as for the newline signifier, otherwise, it will use
203  * standard unix \n.
204  */
205 //#define JSON_NEWLINE "\r\n" //\r\n is standard for most windows and dos programs
206 
207 
208 /*
209  * JSON_INDENT affects how libjson writes. If this option is turned on, libjson
210  * will use \t to indent formatted json, otherwise it will use the number of characters
211  * that you specify. If this is not turned on, then it will use the tab (\t) character
212  */
213 //#define JSON_INDENT " "
214 
215 
216 /*
217  * JSON_ESCAPE_WRITES tells the libjson engine to escape special characters when it writes
218  * out. If this option is turned off, the json it outputs may not adhere to JSON standards
219  */
220 #define JSON_ESCAPE_WRITES
221 
222 
223 /*
224  * JSON_COMMENTS tells libjson to store and write comments. libjson always supports
225  * parsing json that has comments in it as it simply ignores them, but with this option
226  * it keeps the comments and allows you to insert further comments
227  */
228 #define JSON_COMMENTS
229 
230 
231 /*
232  * JSON_WRITE_BASH_COMMENTS will cause libjson to write all comments in bash (#) style
233  * if this option is not turned on, then it will use C-style comments. Bash comments are
234  * all single line
235  */
236 //#define JSON_WRITE_BASH_COMMENTS
237 
238 
239 /*
240  * JSON_WRITE_SINGLE_LINE_COMMENTS will cause libjson to write all comments in using //
241  * notation, or (#) if that option is on. Some parsers do not support multiline C comments
242  * although, this option is not needed for bash comments, as they are all single line anyway
243  */
244 //#define JSON_WRITE_SINGLE_LINE_COMMENTS
245 
246 
247 /*
248  * JSON_ARRAY_SIZE_ON_ON_LINE allows you to put small arrays of primitives all on one line
249  * in a write_formatted. This is common for tuples, like coordinates. If must be defined
250  * as an integer
251  */
252 //#define JSON_ARRAY_SIZE_ON_ONE_LINE 2
253 
254 
255 /*
256  * JSON_VALIDATE turns on validation features of libjson.
257  */
258 #define JSON_VALIDATE
259 
260 
261 /*
262  * JSON_CASE_INSENSITIVE_FUNCTIONS turns on funtions for finding child nodes in a case-
263  * insenititve way
264  */
265 #define JSON_CASE_INSENSITIVE_FUNCTIONS
266 
267 
268 /*
269  * JSON_INDEX_TYPE allows you th change the size type for the children functions. If this
270  * option is not used then unsigned int is used. This option is useful for cutting down
271  * on memory, or using huge numbers of child nodes (over 4 billion)
272  */
273 //#define JSON_INDEX_TYPE unsigned int
274 
275 
276 /*
277  * JSON_BOOL_TYPE lets you change the bool type for the C interface. Because before C99 there
278  * was no bool, and even then it's just a typedef, you may want to use something else. If this
279  * is not defined, it will revert to int
280  */
281 //#define JSON_BOOL_TYPE char
282 
283 
284 /*
285  * JSON_INT_TYPE lets you change the int type for as_int. If you ommit this option, the default
286  * long will be used
287  */
288 //#define JSON_INT_TYPE long
289 
290 
291 /*
292  * JSON_NUMBER_TYPE lets you change the number type for as_float as well as the internal storage for the
293  * number. If you omit this option, the default double will be used for most cases and float for JSON_LESS_MEMORY
294  */
295 //#define JSON_NUMBER_TYPE double
296 
297 
298 /*
299  * JSON_STRING_HEADER allows you to change the type of string that libjson uses both for the
300  * interface and internally. It must implement most of the STL string interface, but not all
301  * of it. Things like wxString or QString should wourk without much trouble
302  */
303 //#define JSON_STRING_HEADER "../TestSuite/StringTest.h"
304 
305 
306 /*
307  * JSON_UNIT_TEST is used to maintain and debug the libjson. It makes all private
308  * members and functions public so that tests can do checks of the inner workings
309  * of libjson. This should not be turned on by end users.
310  */
311 //#define JSON_UNIT_TEST
312 
313 
314 /*
315  * JSON_NO_EXCEPTIONS turns off any exception throwing by the library. It may still use exceptions
316  * internally, but the interface will never throw anything.
317  */
318 //#define JSON_NO_EXCEPTIONS
319 
320 
321 /*
322  * JSON_DEPRECATED_FUNCTIONS turns on functions that have been deprecated, this is for backwards
323  * compatibility between major releases. It is highly recommended that you move your functions
324  * over to the new equivalents
325  */
326 #define JSON_DEPRECATED_FUNCTIONS
327 
328 
329 /*
330  * JSON_CASTABLE allows you to call as_bool on a number and have it do the 0 or not 0 check,
331  * it also allows you to ask for a string from a number, or boolean, and have it return the right thing.
332  * Without this option, those types of requests are undefined. It also exposes the as_array, as_node, and cast
333  * functions
334  */
335 #define JSON_CASTABLE
336 
337 
338 /*
339  * JSON_SECURITY_MAX_NEST_LEVEL is a security measure added to make prevent against DoS attacks
340  * This only affects validation, as if you are worried about security attacks, then you are
341  * most certainly validating json before sending it to be parsed. This option allows you to limitl how many
342  * levels deep a JSON Node can go. 128 is a good depth to start with
343  */
344 #define JSON_SECURITY_MAX_NEST_LEVEL 128
345 
346 
347 /*
348  * JSON_SECURITY_MAX_STRING_LENGTH is another security measure, preventing DoS attacks with very long
349  * strings of JSON. 32MB is the default value for this, this allows large images to be embedded
350  */
351 #define JSON_SECURITY_MAX_STRING_LENGTH 33554432
352 
353 
354 /*
355  * JSON_SECURITY_MAX_STREAM_OBJECTS is a security measure for streams. It prevents DoS attacks with
356  * large number of objects hitting the stream all at once. 128 is a lot of objects, but not out of
357  * the question for high speed systems.
358  */
359 #define JSON_SECURITY_MAX_STREAM_OBJECTS 128
360 
361 #endif
362