Starting with CMake 3.27, deprecation warnings are issued
when asking for policy settings for CMake 3.4 or earlier.
The cmake_minimum_required() command accepts a version
range, which allows NEW policy settings up to the upper end
of that range to be used, but without raising the minimum
CMake version above the bottom of that range. This means
NEW policy settings will be used where available, without
requiring them. This change updates the project's
cmake_minimum_required() calls to use a version range to
extend the upper policy version to 3.14 where it wasn't already
at that version or higher. This prevents the deprecation warning
from CMake 3.27, and gives breathing space before a future
CMake release will start issuing similar deprecation warnings
again.
* Reimplement value() access functions
* Merges the 'const char *' with the 'ValueType &&' overloads.
* Fixes ambiguities when default value is 0.
* Fixes 'no matching function' error when specifying ValueType template
parameter.
* Fixes incorrect template parameter order in previous overloads.
* Add additional value() tests
* Make JSON_MultipleHeaders visible to unit tests
Define the macro JSON_TEST_USING_MULTIPLE_HEADERS to 0/1 depending on
JSON_MultipleHeaders.
* Add type_traits unit test
* Update documentation
* Move UDLs into nlohmann::literals::json_literals namespace
* Add 'using namespace' to unit tests
* Add 'using namespace' to examples
* Add 'using namespace' to README
* Move UDL mkdocs pages out of basic_json/
* Update documentation
* Update docset index
* Add JSON_GlobalUDLs CMake option
* Add unit test
* Build examples without global UDLs
* Add CI target
* Fixed latest build error in msvc platform
warnings in msvc about mix/max macro while windows.h is used in the project #762
* Update for CI
None
* Update single_include/nlohmann/json.hpp
Co-authored-by: Florian Albrechtskirchinger <falbrechtskirchinger@gmail.com>
Co-authored-by: Florian Albrechtskirchinger <falbrechtskirchinger@gmail.com>
* Add versioned inline namespace
Add a versioned inline namespace to prevent ABI issues when linking code
using multiple library versions.
* Add namespace macros
* Encode ABI information in inline namespace
Add _diag suffix to inline namespace if JSON_DIAGNOSTICS is enabled, and
_ldvcmp suffix if JSON_USE_LEGACY_DISCARDED_VALUE_COMPARISON is enabled.
* Move ABI-affecting macros into abi_macros.hpp
* Move std_fs namespace definition into std_fs.hpp
* Remove std_fs namespace from unit test
* Format more files in tests directory
* Add unit tests
* Update documentation
* Fix GDB pretty printer
* fixup! Add namespace macros
* Derive ABI prefix from NLOHMANN_JSON_VERSION_*
* Fix patch::add creating nonexistent parents
The previous behavior was not in accordance with RFC6902.
Add unit test.
Fixes#3134.
* Fix incorrect JSON patch unit test
Co-authored-by: Hudson00 <yagdhscdasg@gmail.com>
As nlohmann_json is a header-only library, its pkg-config and cmake
config files should be installed to `share/` (GNUInstallDirs' DATADIR),
as `share/` is the canonical directory where architecture-independent
files should be stored, while `lib/` is for architecture-dependent stuff
(see the [FHS][]).
Apart from being technically correct, installing to `share/` can help
with cross-compiling, for example in Debian-based environments. If
you're interested, I'd suggest reading this [thread][].
Related to #1697
[FHS]: https://refspecs.linuxfoundation.org/FHS_3.0/fhs-3.0.html#usrshareArchitectureindependentData
[thread]: https://github.com/marzer/tomlplusplus/pull/165#issuecomment-1193146210
* Add operator<< for json_pointer
* Deprecate json_pointer::operator string_t()
* Update documentation
* Move operator<<(basic_json) example
* Add example
* Add mkdocs-redirects
* Move operator<< and operator>> doc pages out of basic_json/
* Rename JSON pointer operator_string to operator_string_t
* Add unit test
When parsing a string containing two JSON values using iterators, after
parsing, iterator_input_adapter should have advanced to the first
character of the second value.
Add a unit test to check that this is true.
* Make certain usage patterns more prominent in the README
We use this library extensively where I work. After pairing with many
teammates, I've learned that one common stumbling point when using this
library is how to first get a JSON value in the first place (because
once they have a variable of type `json` in hand, the API is intuitive
and mostly does what you expect).
With that in mind, I've added two subsections to the top of the Examples
section: how to read JSON from a file, and how to hardcode a JSON
literal.
I understand that these are already documented elsewhere in the Examples
section, and so these new subsections are technically redundant. But to
defend this choice:
- Redundancy in docs is actually good, because not everyone consumes
docs in the same way or in the same order.
- Having these things called out explicitly in isolation encourages
people to get something working faster. In later sections, these
examples are presented alongside many other options. Having to choose
between alternatives gets in the way of quickly prototyping something.
If you have further suggestions for how to improve or modify these docs
I'm open to them. The changes included here would really make a huge
improvement in the productivity of newer members of my team using this
library.
* Remove old TOC entry
* Put the section back
* Another tweak
* CMake: Add TEST_PROPERTIES to json_test_set_test_options()
Allow overriding test properties via json_test_set_test_options().
* CMake: Set timeouts for Unicode tests
* Add benchmark for cbor serialization and cbor binary data serialization
* Use std::vector::insert method instead of std::copy in output_vector_adapter::write_characters
This change increases a lot the performance when writing lots of binary data.
* Add overloads for more key types to ordered_map
Add overloads to accept additional key types defined by type trait
detail::is_usable_as_key_type to ordered_map.
The same key types that can be used with json can now also be used with
ordered_json.
* Fix ordered_map::erase(first, last) with first == last
* Modify element access unit test to also test ordered_json
Use DOCTEST_* macros in place of predefined compiler macros for compiler
detection and version checks.
The suppression of warning -Wrange-loop-construct in unit-items.cpp
causes GCC<11 to warn about pragmas. Suppressed by adding a version
check.
* Use `std::iterator_traits` to extract `iterator_category`
In third-party STL implementations, `array_t::iterator` might be a pointer (e.g., `vector` in [EASTL](https://github.com/electronicarts/EASTL)) rather than a class, in which case directly using `array_t::iterator::iterator_category` is invalid. This commit fixes it with `std::iterator_traits`, which handles pointers correctly.
* add the changes to the single-header version
* BJData dimension length can not be string_t::npos, fix#3541
* handle error messages on 32bit machine
* add explanation to why size can not be string_t::npos
* add test cases to 32bit unit test
Co-authored-by: Florian Albrechtskirchinger <falbrechtskirchinger@gmail.com>
* Fix ndarray dimension signness, fix ndarray length overflow, close#3519
* detect size overflow in ubjson and bjdata
* force reformatting
* Fix MSVC compiler warning
* Add value_in_range_of trait
* Use value_in_range_of trait
* Correct 408 parse_errors to out_of_range
* Add 32bit unit test
The test can be enabled by setting JSON_32bitTest=ON.
* Exclude unreachable lines from coverage
Certain lines are unreachable in 64bit builds.
Co-authored-by: Qianqian Fang <fangqq@gmail.com>
The converting basic_json constructor can inadvertently change the value
type of its parameter. Assert that both basic_json values are of the
same value type after conversion.
* Add C++20 3-way comparison operator and fix broken comparisons
Fixes#3207.
Fixes#3409.
* Fix iterators to meet (more) std::ranges requirements
Fixes#3130.
Related discussion: #3408
* Add note about CMake standard version selection to unit tests
Document how CMake chooses which C++ standard version to use when
building tests.
* Update documentation
* CI: add legacy discarded value comparison
* Fix internal linkage errors when building a module
* Discard optimized containers with negative counts in UBJSON/BJData (#3491,#3492,#3490)
* fix msvc error
* update unit tests for negative sized containers
* use a loop to test 0 ndarray dimension
* throw an error when count is negative, merge CHECK_THROW_AS and _WITH with _WITH_AS
* change bjdata ndarray flag to detect negative size, fix https://github.com/nlohmann/json/issues/3475
* fix CI error
* fix CI on 32bit windows
* remove platform specific out_of_range error messages
* Incorporate suggestions from @nlohmann and @falbrechtskirchinger
* fix CI errors
* add coverage
* fix sax event order
* fix coverage
* ⬆️ Doctest 2.4.7
* 👷 add CI step for ICPC
* 👷 add CI step for ICPC
* 👷 add CI step for ICPC
* ⬇️ downgrade to Doctest 2.4.6
* 👷 add CI step for ICPC
* 👷 add CI step for ICPC
* 👷 add CI step for ICPC
* 👷 add CI step for ICPC
* 👷 add CI step for ICPC
* 🔇 suppress warning #2196: routine is both "inline" and "noinline"
* Re-enable <filesystem> detection on ICPC
* Limit regression test for #3070 to Clang and GCC >=8.4
* Disable deprecation warnings on ICPC
* Disable regression test for #1647 on ICPC (C++20)
* Fix compilation failure of regression test for #3077 on ICPC
* Disable wstring unit test on ICPC
Fixes:
error 913: invalid multibyte character sequence
* Add ICPC to README
Co-authored-by: Niels Lohmann <mail@nlohmann.me>
* Add key_compare member to ordered_map
* Replace == with key_compare in ordered_map
* Expose the actual comparison function used by object_t
nlohmann::ordered_map uses a different comparison function than the one
provided via template parameter.
* Introduce a type trait to detect if object_t has a key_compare member.
* Rename object_comparator_t to default_object_comparator_t.
* Add object_comparator_t to be conditionally defined as
object_t::key_compare, if available, or default_object_comparator_t
otherwise.
* Update the documentation accordingly.
Co-authored-by: Niels Lohmann <niels.lohmann@gmail.com>
* Add type traits to check if a type is usable as object key
Add type trait to check:
* if a type is a specialization of a template.
* if a type is a json_pointer.
* if a type is a basic_json::{const_,}iterator.
* if two types are comparable using a given comparison functor.
* if a type is comparable to basic_json::object_t::key_type.
* if a type has a member type is_transparent.
* if a type is usable as object key.
* if a type has an erase() function accepting a given KeyType.
Co-authored-by: Niels Lohmann <niels.lohmann@gmail.com>
* Rework basic_json element access to accept more key types
Rework basic_json element access member functions and operators to
accept any type that meets the requirements defined by type trait
detail::is_usable_as_key_type.
Member functions and operators:
* at()
* operator[]
* value()
* erase()
* find()
* count()
* contains()
Update documentation to reflect these changes.
Add unit tests to excercise the new functions using std::string_view.
Co-authored-by: Niels Lohmann <niels.lohmann@gmail.com>
Co-authored-by: Niels Lohmann <niels.lohmann@gmail.com>
* support UBJSON-derived Binary JData (BJData) format
* fix Codacy warning
* partially fix VS compilation errors
* fix additional VS errors
* fix more VS compilation errors
* fix additional warnings and errors for clang and msvc
* add more tests to cover the new bjdata types
* add tests for optimized ndarray, improve coverage, fix clang/gcc warnings
* gcc warn useless conversion but msvc gives an error
* fix ci_test errors
* complete test coverage, fix ci_test errors
* add half precision error test
* fix No newline at end of file error by clang
* simplify endian condition, format unit-bjdata
* remove broken test due to alloc limit
* full coverage, I hope
* move bjdata new markers from default to the same level as ubjson markers
* fix ci errors, add tests for new bjdata switch structure
* make is_bjdata const after using initializer list
* remove the unwanted assert
* move is_bjdata to an optional param to write_ubjson
* pass use_bjdata via output adapter
* revert order to avoid msvc 2015 unreferenced formal param error
* update BJData Spect V1 Draft-2 URL after spec release
* amalgamate code
* code polishing following @gregmarr's feedback
* make use_bjdata a non-default parameter
* fix ci error, remove unwanted param comment
* encode and decode bjdata ndarray in jdata annotations, enable roundtrip tests
* partially fix ci errors, add tests to improve coverage
* polish patch to remove ci errors
* fix a ndarray dim vector condition
* fix clang tidy error
* add sax test cases for ndarray
* add additional sax event tests
* adjust sax event numbering
* fix sax tests
* ndarray can only be used with array containers, discard if used in object
* complete test coverage
* disable [{SHTFNZ in optimized type due to security risks in #2793 and hampered readability
* fix ci error
* move OutputIsLittleEndian from tparam to param to replace use_bjdata
* fix ci clang gcc error
* fix ci static analysis error
* update json_test_data to 3.1.0, enable file-based bjdata unit tests
* fix stack overflow error on msvc 2019 and 2022
* use https link, update sax_parse_error after rebase
* make input_format const and use initializer
* return bool for write_bjdata_ndarray
* test write_bjdata_ndarray return value as boolean
* fix ci error
* Make exception context optional
Change exception context parameter to pointer and replace context with
nullptr where appropriate.
* Support escaping other string types
* Add string concatenation function
Add variadic concat() function for concatenating char *, char, and
string types.
* Replace string concatenations using + with concat()
* Template json_pointer on string type
Change json_pointer from being templated on basic_json to being
templated on string type.
* Add unit test for #3388Closes#3388.
* Fix regression test for #2958
* Add backwards compatibility with json_pointer<basic_json>
* Update json_pointer docs
* Allow comparing different json_pointers
* Update version numbers
Constrain from_json() overload for StringType to not accept json_ref and
require it to be assignable, instead of constructible, from
basic_json::string_t.
Re-enable C++14 tests on Clang <4.0.
Fixes#3171.
Fixes#3267.
Fixes#3312.
Fixes#3384.
* ⬆️ use new CI image
* ⬆️ use new CI image
* 🚨 suppress Clang-Tidy warnings
* 💚 use proper scan-build version
* 🚨 suppress Clang-Tidy warnings
* ⬆️ use more recent GitHub actions
* 💚 add missing compiler
* 📝 update used compilers
* 🚨 fix duplicate inclusion
AppVeyor build VMs should provide at least two cores. Parallelize builds
and tests.
In addition, enable output on failure and disable verbose test output.
Restore the previously disabled check for regression #3070 on all
compilers but MSVC.
To summarize the issue:
Given namespace fs = std::filesystem.
On MSVC attempting to construct an fs::path from json results in an
ambiguous overload resolution because fs::path can be constructed from
both a std::string as well as another fs::path.
To the best of my knowledge there is no way to fix an ambiguous overload
situation involving a type we do not control and with json implicitly
converting to both std::string and fs::path.
Re-enabling the check where it compiles and keeping it disabled for MSVC
is the best we can do.
Closes#3377 and #3382.
* Avoid clash with Arduino defines
* Arduino defines B0/B1 in "binary.h"
#define B0 0
#define B1 1
This clashes with names of the template
variables in conjuction
* Renaming them to "B" rather than "B1"
Now it can be used as-is in Arduino projects
* Apply suggestions from code review
* Apply suggestions from code review
Co-authored-by: Daniel Ansorregui <d.ansorregui@samsung.com>
Co-authored-by: Niels Lohmann <niels.lohmann@gmail.com>
* Refactor unit test creation
Add functions for creating tests and to supply test- and
standard-specific build settings.
Raises minimum CMake version to 3.13 in test directory.
json_test_add_test_for(
<file>
MAIN <main>
[CXX_STANDARDS <version_number>...] [FORCE])
Given a <file> unit-foo.cpp, produces
test-foo_cpp<version_number>
if C++ standard <version_number> is supported by the compiler and
thesource file contains JSON_HAS_CPP_<version_number>. Use FORCE to
create the test regardless of the file containing
JSON_HAS_CPP_<version_number>. Test targets are linked against <main>.
CXX_STANDARDS defaults to "11".
json_test_set_test_options(
all|<tests>
[CXX_STANDARDS all|<args>...]
[COMPILE_DEFINITIONS <args>...]
[COMPILE_FEATURES <args>...]
[COMPILE_OPTIONS <args>...]
[LINK_LIBRARIES <args>...]
[LINK_OPTIONS <args>...])
Supply test- and standard-specific build settings.
Specify multiple tests using a list e.g., "test-foo;test-bar".
Must be called BEFORE the test is created.
* Use CMAKE_MODULE_PATH
* Don't undef some macros if JSON_TEST_KEEP_MACROS is defined
* Use JSON_TEST_KEEP_MACROS
Incidentally enables the regression tests for #2546 and #3070.
A CHECK_THROWS_WITH_AS in #3070 was disabled which is tracked in #3377
and a line in from_json(..., std_fs::path&) was marked with LCOV_EXCL_LINE.
* Add three-way comparison feature test macro
* Disable broken comparison if JSON_HAS_THREE_WAY_COMPARISON
* Fix redefinition of inline constexpr statics
Redelcaration of inline constexpr static data members in namespace scope
was deprecated in C++17. Fixes -Werror=deprecated compilation failures.
* Fix more test build failures due to missing noexcept
* CI: update cmake_flags test to use CMake 3.13 in test directory
Also change default for JSON_BuildTests option to depend on CMake
version.
* CI: turn *_CXXFLAGS into CMake lists
* CI: use JSON_TestStandards to set CXX_STANDARD
* CI: pass extra CXXFLAGS to standards tests
Commit f28fc22 introduced const qualifiers on post-(inc-/dec-)rement
operators of iterators. These qualifiers prevent the use of basic_json
in place of std::ranges::range, which requires the post-increment
operator to be equality-preserving.
These changes appear to be the result of ICC compiler suggestions, and
no further explanation is discernible from the PR discussion (#858).
Further testing revealed, that clang-tidy also suggests adding const to
prevent "accidental mutation of a temporary object".
As an alternative, this commit partially reverts f28fc22, removing all
added const qualifiers from return types and adds lvalue reference
qualifiers to the operator member functions instead.
Unit tests ensure the operators remain equality-preserving and
accidental mutation of temporaries following post-(inc-/dec-)rement is
prohibited.
Fixes#3331.
* 🔧 use proper GCC binary
* 🔧 add more GCC warning flags
* ⚗️ try fix from https://github.com/nlohmann/json/issues/3138#issuecomment-1015562666
* Fix custom allocator test build failures (C++20)
Allocator tests fail to compile in C++20 mode with clang+MS STL due
to missing copy constructors.
* Fix test build failures due to missing noexcept (gcc-12)
* alt_string has multiple member functions that should be marked noexcept.
* nlohmann::ordered_map constructors can be noexcept.
Compilation failures result from the warning flag -Werror=noexcept and
gcc-12.
* Disable broken comparison tests in C++20 mode
Co-authored-by: Niels Lohmann <mail@nlohmann.me>
One of the ordered_map constructors was incorrectly accepting a
std::initializer_list<T> instead of std::initializer_list<value_type>.
Add regression test.
Fixes#3343.
* CI: add workflow_dispatch trigger
* CI: change msvc2019*/clang* runners to windows-2019
GitHub updated their runners. windows-latest is now based on Windows
Server 2022 and comes with different tool versions.
MSVC 2019 is still available via the windows-2019 runner.
* Added new macros NLOHMANN_DEFINE_TYPE_INTRUSIVE_WITH_DEFAULT and NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE_WITH_DEFAULT.
* Updated docs for NLOHMANN_DEFINE_TYPE_INTRUSIVE_WITH_DEFAULT and NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE_WITH_DEFAULT accordingly
* Rephrased docs for NLOHMANN_DEFINE_TYPE_INTRUSIVE_WITH_DEFAULT and NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE_WITH_DEFAULT
* Updated docs for NLOHMANN_DEFINE_TYPE_INTRUSIVE_WITH_DEFAULT and NLOHMANN_DEFINE_TYPE_NON_INTRUSIVE_WITH_DEFAULT
* Renamed default_obj in to avoid name clashes
* Added test for serialization of default constructed object
* Add const to getters for macro tests
Co-authored-by: Chaoya Li <harry75369@gmail.com>
In the docs, the `ignore_comments` parameter to `nlohmann::json::parse()` is described as `skip_comments`, which does not match the actual implementation. While the demo code compiles and works, the parameter name is wrong.
* meta: rework is_compatible/is_constructible_string_type
These type traits performed an incorrect and insufficient check.
Converting to a std::filesystem::path used to work by accident thanks to
these brittle constraints, but the clean-up performed in #3020 broke them.
* support std::filesystem::path
Fixes#3070
The previous version relied on the existence of an 'iterator' type.
As mentioned in comments, this is not the proper way to do it and
causes issues with certain types (e.g. views from range-v3).
Add a 'is_range' trait that properly detects the return type of
'begin'/'end', and use it in instead.
* Set parent pointers for values inserted via update() (fixes#3007).
* Moved test for #3007 to proper file.
* Enable access to private members in diagnostics unit tests.
* Make style consistent with rest of code.
* Forced amalgamate rerun.
* Refactor test for #3007 so it doesn't use private members. Also extend to test both update() functions.
* Added fix for #3007 to update(const_iterator, const_iterator) as well.
* Added failing example code from #3007 as extra test.
I've submitted a PR on [homebrew/core](https://github.com/Homebrew/homebrew-core/pull/83479) that updates their Formula. After that one is set, we can merge this and let users use the default formula, and we don't have to maintain two separate Formulas.
Without SYSTEM static analysis like clang-tidy raise warnings on
json.hpp. This is not desirable for projects embedding nlohmann_json
Tests:
- Validated that without the option OFF the warnings are raised as
before
- Validated that with the option ON the warnings are silenced
The latest MSVC compiler throws the following warning on
nlohmann::detail::exception::what() if /analyze is enabled:
```
vcruntime_exception.h(93) : warning C28204: 'what' has an override at
`nlohmann\json\develop\single_include\nlohmann\json.hpp(2644)`
and only the override is annotated for return: when an override is
annotated, the base (this function) should be similarly annotated.
```
See https://godbolt.org/z/r331h4
This fixes a compilation issue with the library if trying to use containers that
don't have non-member `begin()` and `end()` functions via ADL.
This patch extends the `using std::begin` and `using std::end` declarations to
also cover the return type deduction of the input_adapter() template
specialization for containers. The previous implementation only enabled the
detection of `std::begin()` and `std::end()` in the function body, making the
specialization unusable for container types that only have member `begin()` and
`end()` functions.
It is not typical to have `using` declarations in the namespace scope in a
header file. But a C++11 implementation can't rely on fully automatic return
type deduction, and needs to rely on ADL enabled helper templates. To prevent
the using declarations leaking, they are enclosed in another nested namespace.
When the testsuite is enabled, the "cmake_add_subdirectory" test
adds a second copy of the project into the build configuration, and the
project files are installed twice.
This becomes super problematic when it tries to install a file from
CMAKE_BINARY_DIR which is only available in CMAKE_CURRENT_BINARY_DIR
and bombs out with the following error message:
```
[...]
-- Installing: <DESTDIR>/usr/lib/cmake/nlohmann_json/nlohmann_jsonTargets.cmake
CMake Error at test/cmake_add_subdirectory/nlohmann_json/cmake_install.cmake:73 (file):
file INSTALL cannot find
"......./nlohmann-json/builddir/test/cmake_add_subdirectory/nlohmann_json.pc":
No such file or directory.
Call Stack (most recent call first):
test/cmake_add_subdirectory/cmake_install.cmake:47 (include)
test/cmake_install.cmake:49 (include)
cmake_install.cmake:94 (include)
```
We need to have a proper sed, even on MacOSX. So let's use the variable
introduced in 191aa0fd (🔧 overworked maintaner targets,
2019-03-28) in more places.
The meson builds install a pkg-config file, but the cmake builds don't.
This adds a pkg-config file to the cmake builds that is functionally
equivalent to the one generated from meson.
Projects that import json via [FetchContent](https://cmake.org/cmake/help/latest/module/FetchContent.html) or `add_subdirectory` pointed at a git submodule may want to set `JSON_BuildTests` to "NO". However, this doesn't work without creating an identical `option()` in the importing project. Enabling CMP0077 in supported versions of CMake changes the behavior of `option()` to allow importing projects to set default values for the variables without touching the cache.
See the documentation for CMP0077 here: https://cmake.org/cmake/help/latest/policy/CMP0077.html
This is more comprehensive and the "my_workaround_fifo_map" wrapper does not allow to infer value type as required in this branch.
This reverts commit 064a9c9212.
The current code uses std::stoi to convert the input string to an int
array_index. This limits the maximum addressable array size to ~2GB on
most platforms.
But all callers immediately convert the result of array_index to
BasicJsonType::size_type.
So let's parse it as unsigned long long, which allows us to have as
big arrays as available memory. And also makes the call sites nicer to
read.
One complication arises on platforms where size_type is smaller than
unsigned long long. We need to bail out on these if the parsed array
index does not fit into size_type.
About pull request:
https://github.com/nlohmann/json/pull/2074
An error has been introduced by accepting the suggestions:
4be4a038cc
One was about removing ~~~, but it was meant to be replaced by ``` in
reality. This caused the README.md to be slightly broken.
I tested following strings with invalid surrogate pair and unpaired surrogate in files:
1. `"a\uD800\uD800x"`
2. `"a\uD800x"`
The error messge was: "... invalid string: surrogate U+DC00..U+DFFF must be followed by U+DC00..U+DFFF; ..."
I think it must be: "... invalid string: surrogate U+D800..U+DBFF must be followed by U+DC00..U+DFFF; ..."
Github issue:
https://github.com/nlohmann/json/issues/2073
nlohmann::json documents 2 way of depending on it using CMake
1) Copy-paste the project/source into your own project.
2) Install nlohman::json and then use find_package.
(1) pollutes your git repository, (2) requires everyone to install the
dependencies themselves.
Since 2018, CMake provide some kind of 'package manager' features using
[FetchContent](https://cmake.org/cmake/help/v3.17/module/FetchContent.html)
It gives the following:
~~~cmake
include(FetchContent)
FetchContent_Declare(json
GIT_REPOSITORY https://github.com/nlohmann/json
GIT_TAG v3.7.3)
FetchContent_GetProperties(json)
if(NOT json_POPULATED)
FetchContent_Populate(json)
add_subdirectory( ${json_SOURCE_DIR} ${json_BINARY_DIR} EXCLUDE_FROM_ALL)
endif()
~~~
Then declares the dependency in the target using it:
~~~cmake
target_link_library(my_project PRIVATE nlohmann_json::nlohmann_json
~~~
This patch updates the documentation and provides tests.
I created a `nlohmann-json` package for `build2` (https://build2.org) that have been published on the central public repository https://cppget.org : https://cppget.org/nlohmann-json (at the moment you can see that there is only one version: 3.7.3).
The repository of the package code is there: https://github.com/build2-packaging/nlohmann-json and is owned by the build2 community now. (with build2 you can use either a repository like cppget.org or a git repository so both are useful to users for different use cases).
This patch just add the basic information as to how to use this library with build2.
Also call out to the guidelines for using pkg-config dependencies first,
and reference it for other build systems as well.
Although the possibility of installing with a pkg-config file is
somewhat hidden away in the meson docs, it's been deemed less invasive
due to not distracting away from cmake. So it will have to do.
This serves as a minimal release-only way to embed json into a project.
Add meson support to this directly, to make it usable standalone as a
meson subproject.
Implements #1672
In a future commit we want to add support for MSVC 2019. For that
version cmake requires us to pass in the architecture not part of the
generator but explicitly.
So let's pass that in always like that. This also removes the doubling
of the platform/architecture.
Using GLOB is slow and considered bad practice.
From https://cmake.org/cmake/help/latest/command/file.html:
> We do not recommend using GLOB to collect a list of source files from
> your source tree. If no CMakeLists.txt file changes when a source is
> added or removed then the generated build system cannot know when to ask
> CMake to regenerate. The CONFIGURE_DEPENDS flag may not work reliably on
> all generators, or if a new generator is added in the future that cannot
> support it, projects using it will be stuck. Even if CONFIGURE_DEPENDS
> works reliably, there is still a cost to perform the check on every
> rebuild.
binary_reader.hpp:650: (style) Unsigned expression 'mant' can't be negative so it is unnecessary to test it
910a7d2b87/checks (step):5:84
Signed-off-by: Xav83 <x.jouvenot@gmail.com>
For some gcc version (Ubuntu 5.5.0-12ubuntu1~16.04) the existing code
crashes when the minimum value of int64_t is outputted.
Resurrect the code from before 546e2cbf (🚨 fixed some warnings,
2019-03-13) but delegate the sign removal so that the compilers don't
complain about taking the negative value of an unsigned value.
In addition we also rewrite the expression so that we first increment
and then negate.
The definition of remove_sign(number_unsigned_t) is never called as
unsigned values are never negative.
The clang sanitizer tests, and there especially the unicode tests, can
hit the default timeout of 25 minutes (1500 seconds) quite easily, so
let's raise the timeout to 45 minutes (2700 seconds).
Clang UBSAN currently complains that the char * to input_buffer_adapter
is a nullptr.
Turns out it is actually required to accept nullptr, see for example
line 415 in input_adapters.hpp
...
// the address of first cannot be used: use nullptr
ia = std::make_shared<input_buffer_adapter>(nullptr, len);
....
Therefore we have to handle it gracefully here. We now also ignore the
length parameter l if b is a nullptr.
- Switch to clang-7
- Adapt PATH so that llvm-symbolizer can be found for useful stacktraces
- Adapt compile flags
"-O0" ensures much faster compile times
"-fno-sanitize-recover=all
-fsanitize-recover=unsigned-integer-overflow" this fails the build on
all issues except unsigned integer overflows. Not failing in this case
is required in combination with the sanitizer suppression file as only
recoverable errors can be suppressed.
The UBSAN suppression file ignores errors from stl_bvector.h (which
holds std::vector<bool>).
Clang reports that error as
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior /usr/lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/stl_bvector.h:158:20 in
Start 34: test-deserialization_all
28/88 Test #71: test-testsuites_default .............***Failed 0.32 sec
/usr/lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/stl_bvector.h:158:20: runtime error: unsigned integer overflow: 0 - 1 cannot be represented in type 'unsigned int'
#0 0x628f72 in std::_Bit_iterator_base::_M_bump_down() /usr/lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/stl_bvector.h:158:20
#1 0x628d16 in std::_Bit_iterator::operator--() /usr/lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/stl_bvector.h:251:7
#2 0x634aac in std::vector<bool, std::allocator<bool> >::pop_back() /usr/lib/gcc/x86_64-linux-gnu/6.3.0/../../../../include/c++/6.3.0/bits/stl_bvector.h:1010:7
#3 0x61eff0 in bool nlohmann::detail::parser<nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer> >::sax_parse_internal<nlohmann::detail::json_sax_dom_parser<nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer> > >(nlohmann::detail::json_sax_dom_parser<nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer> >*) /home/firma/devel/json/include/nlohmann/detail/input/parser.hpp:439:28
#4 0x604864 in nlohmann::detail::parser<nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer> >::parse(bool, nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer>&) /home/firma/devel/json/include/nlohmann/detail/input/parser.hpp:116:13
#5 0x5f8079 in nlohmann::operator>>(std::istream&, nlohmann::basic_json<std::map, std::vector, std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >, bool, long, unsigned long, double, std::allocator, nlohmann::adl_serializer>&) /home/firma/devel/json/include/nlohmann/json.hpp:6356:42
#6 0x5e1d92 in _DOCTEST_ANON_FUNC_21() /home/firma/devel/json/test/src/unit-testsuites.cpp:343:9
#7 0x7207fe in doctest::Context::run() /home/firma/devel/json/test/thirdparty/doctest/doctest.h:5938:21
#8 0x72681a in main /home/firma/devel/json/test/thirdparty/doctest/doctest.h:6016:71
#9 0x7f75d22362e0 in __libc_start_main (/lib/x86_64-linux-gnu/libc.so.6+0x202e0)
#10 0x4c28b9 in _start (/home/firma/devel/json/build/test/test-testsuites+0x4c28b9)
The pop_back() in parser.hpp
assert(not states.empty());
-> states.pop_back();
triggers the UBSAN report. But the assertion above ensure that we only
call pop_back() on an non-empty vector, therefore this is a STL library
bug and thus must be ignored for us.
While in our case, only the string case was affected, to be safe and allow the library to work with other unforeseen cases, all of the cases have been wrapped with parentheses.
Thank you @DyXel and @edo9300
serializer use fixed buffer. Whenever it is nearly full, it is flushed to `output_adapter_t<char> o`
But the code forgets to flush when there is a invalid utf8 code point
So there will be buffer overflow.
Putting pop_back() to public and creating a trivial push_back()
method allows users of nlohmann::json_pointer to manipulate an
existing json-pointer by adding or removing keys at the end.
This is useful for traversing a JSON-instance and keeping track
of its "absolute path" at any moment.
In my case for a schema-validator error-handler.
Commit 73cc5089 (Using target_compile_features to specify C++ 11
standard) bumped the required cmake version, from 3.0 to 3.8, so
as to get the definition of target_compile_features().
However, target_compile_features() was introduced in cmake-3.1:
https://cmake.org/cmake/help/v3.1/command/target_compile_features.html
And using cmake-3.1 is indeed sufficient to properly build.
As such, relax the minimum required version down to cmake-3.1,
so we can build on oldish, entreprise-grade distributions that
only have cmake-3.1 (or at least, don't have up to cmake-3.8).
Reported-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
"V567 The modification of the 'position.chars_read_current_line' variable is unsequenced relative to another operation on the same variable. This may lead to undefined behavior."
Fix issue #1340.
The eofbit is set manually since we don't go through the
stream interface. We could maybe use the stream interface
instead, but there are some assumptions regarding which
exception go through, so this seems to be the most prudent
approach for now.
When adding this library as embedded library with private
"target link", e.g. only used inside private source files, the
library does not need to be installed when the main project gets
installed.
This adds an additional option `JSON_Install` similar to the
test-build control switch in order to skip installing headers and
CMake config files if requested.
Avoids using
```cmake
add_subdirectory(path/to/nlohmann_json EXCLUDE_FROM_ALL)
```
which has further side-effects:
https://cmake.org/cmake/help/v3.0/command/add_subdirectory.html
is_compatible_* traits were used in from_json, but it made no sense
whatsoever.
It used to work because of non-SFINAE correctness + json_ref
unconstrained variadic template constructor.
SFINAE checks are becoming quite complex, we need a specification of
some sort describing:
* which concepts the library uses
* how the conversion to/from json works in detail
Having such a specification would really help simplifying the current
code (as well as having meaningful checks).
Fixes!1299
In follow up from the conversation in #1269, this adds the
`-Wno-deprecate-declarations` flag to unit tests to allow them to
test deprecated APIs without all the noisy compiler warnings.
This also refactors the setting of build properties for test targets
to use `target_<...>` commands instead of `set_target_properties()`.
Takes an lvalue reference, and returns the same reference.
This allows non-default constructible types to be converted without
specializing adl_serializer.
This overload does not require CopyConstructible either.
Implements #1227
* Make the conversion operator SFINAE correct.
* Workaround a GCC bug with some traits in type_traits.hpp
The first bullet-point implies that every `get`/`get_ptr` be SFINAE
correct as well.
These tests never worked - they weren't run before
d5aaeb4.
Note that these tests would fail because of this library
ordering dictionary keys (which is legal). So changing the
input files (or modifying stored cbor/msgpack/ubjson files)
would make the tests work and they could get removed from
"exclude_packaged".
Also move parsing of files in these unit tests to within
the inner sections, so that they're only parsed
number_of_files * number_of_sections instead of
number_of_files * number_of_files * number_of_sections
(so, instead of close to 100k parses about 700).
"Concepts" have been renamed to "named requirements".
This is because P0898R3 Standard Library Concepts has been merged into
C++20.
Cppreference have moved their links accordingly.
The branch coverage reported by lcov is weird. The code before and after has the same Godbolt assembler, but the code with the lambda has a better branch coverage.
This overload is chosen only when BasicJsonType::string_t
is not constructible from std::map::key_type.
Currently, converting a map to json treats it as an array of pairs.
fixes#1079
The README says:
> "The library itself contains of a single header file ..."
I guess "consists of a" is the wording that was intended here. Alternatively, "contains a" might also be what was intended. Either way, I think both versions work equally well and thus choose the one that I believe was intended.
CMake convention is to use a project namespace, i.e. Foo::, for imported
targets. When multiple targets are imported from a project, this looks
like Foo::Bar1 Foo::Bar2, etc. This adds the nlohmann_json:: namespace to
the exported target names.
This also allows the generated project config files to be used from the
build directory instead of just the install directory.
I contributed a package to the Spack package manager.
Spack is a flexible package manager that supports multiple versions,
configurations, platforms, and compilers. It is popular in
high-performance computing.
Before this patch, `basic_json` types with different template arguments
were treated as `CompatibleArrayType`. Which sometimes leads to recursive
calls and stack overflows.
This patch adds a constructor and a `get` overload to deal with
different `basic_json` types.
Beside the fix discussed in #961, we also had to re-adjust a test case. It seems that it was failing before, and I "fixed" it to work with the broken implementation...
- updated documentation wrt. new repository layout
- temporarily switched off Homebrew --HEAD building (can only be switched on after release)
- set copyright date to 2018
* Rename 'develop' folder to 'include/nlohmann'
* Rename 'src' folder to 'single_include/nlohmann'
* Use <nlohmann/*> headers in sources and tests
* Change amalgamate config file
- Builds and runs test cases from individual sources rather than from amalgamation.
- Checks whether amalgamation would create the same single-header file as checked in.
This is an attempt to fix#360. The algorithm produces
decimal representations which are guaranteed to roundtrip
and in ~99.8% actually produces the shortest possible
representation. So this is a nice compromise between using
a precision of digits10 and max_digits10.
Note 1:
The implementation only works for IEEE single/double precision
numbers. So the old implementation is kept for compatibility
with non-IEEE implementations and 'long double'.
Note 2:
If number_float_t is 'float', not all serialized numbers can
be recovered using strtod (strtof works, though). (There is
exactly one such number and the result is off by 1 ulp.)
This can be avoided by changing the implementation (the fix
is trivial), but then the resulting decimal numbers are not
exactly short.
The tool used before created a lot of duplicates inside the generated amalgamation. The new tool is a single Python file which seems to do the same job.
- Implemented "copy" in terms of "add".
- Added check for JSON Pointer array indices to make sure the complete reference token was processed.
- Added test suite from https://github.com/json-patch/json-patch-tests
The at function throws json::out_of_range.403 when a nonexistent object key is provided (just like the usual at function). This was not documented and users could assume json::out_of_range.404 would be thrown instead.
- Updated documentation.
- Added example code.
We had a lot of issues with failing roundtrips (i.e., parse errors from serializations) in case string were stored in the library that were not UTF-8 encoded. This PR adds an exception in this case.
The example in the documentation on how to "force" an array of arrays was wrong since the first release. Fixed the documentation and added checks for the README unit tests.
Hey, thanks for this great library which I've used in many occasions now. I know it's not much, but I wanted to contribute at least a tiny bit back to you by this PR :-) Keep up the good work!
o For some unknown reason, the complexity of the benchmark platform
prevented some C++ compilers from generating optimal code, properly
reflective of the real performance in actual deployment.
o Added the json_benchmarks_simple target, which performs the same
suite of tests as json_benchmarks.
o Simplified the benchmark platform, and emit an "Average" TPS
(Transactions Per Second) value reflective of aggregate parse/output
performance.
o We assume the same character int_type as the unerlying std::istream
o There are no assumptions on the value of eof(), other than that it
will not be a valid unsigned char value.
o To retain performance, we do not allow swapping out the underlying
std::streambuf during our use of the std::istream for parsing.
o We can retain -Weffc++ and specify default initializers by using
initializer lists. The risks are low (of additional non-conformat
compilers), because there is already one other such initialization
used in the code-base.
o An (-'ve valued, typically -1) EOF must never be allowed in
token_string, as it be converted to 255 -- a legitimate value.
o Comparing against a specific eof() (-1, typically) is more costly than
detecting +'ve/-'ve. Since EOF is the only non-positive value allowed
we can use the simpler test.
o Removed unnecessary test for token_string size, as it is already
tested in the method, and must never occur in correct code; used an
assert instead.
o Return its contents when necessary. In many cases, this avoids
construction of multiple copies of the yytext token. Exceeds
performance of current develop branch.
o Use std::streambuf I/O instead of std::istream; does not maintain
(unused) istream flags.
o Further simplify get/unget handling.
o Restore original handling of NUL in input stream; ignored during
token_string escaping.
The CBOR and MessagePack parsers now expect the input to be read until the end. Unless the new parameter "strict" is set to false (it is true by default), an exception is raised if the parser ends prematurely. This is a breaking change as the parsers ignored unread input so far.
Furthermore, the offset/startIndex paramter introduced in #462 was removed as this behavior can be mimicked with an iterator range. For instance, instead of calling "from_cbor(vec, 5);", you can write "from_cbor({vec.begin()+5, vec.end()});".
o To prevent the compilation issue on OSX with the intel compiler suite. The
error was found with icpc version 15.0.3.187 where the "__clang_version__" was
not defined correctly, while "__clang__" was.
- replaced list of pairs by flat list in next_byte_in_range
- implemented early exit in case of parse errors
- reused memory for object keys
- direct calls to embedded objects/arrays for insertions
The rewrite uses more cmake build-in automatisms and build-in generates
variables to allow better generic reuse.
* cmake files are installed to
``` <install_prefix>/lib/cmake/nlohmann_json/ ``` for best support on
most systems
* include path is set to ``` include ``` for usage as ``` #include
<nlohmann/json.hpp> ```
You can now pass a boolean "allow_exceptions" to the parse functions. If it is false, no exceptions are thrown in case of a parse error. Instead, parsing is stopped at the first error and a JSON value of type "discarded" (check with is_discarded()) is returned.
On MSVC compiler, temporaries that are constructed during a
list initialization, are sometimes destroyed even before calling
the initializing constructor, instead of at the end of the
containing full-expression. This is clearly non-conforming to
[class.temporary].
As the impact of this bug is silently producing incorrect
JSON values, move eagerly from rvalues to be safe.
See https://stackoverflow.com/questions/24586411
- You can now pass a reference to a vector to the to_cbor and to_msgpack functions. The output will be written (appended) to the vector. #476
- You can now pass an output stream with uint8_t character type to the to_cbor and to_msgpack functions. #477
- You can now read from uint8_t */size in the to_cbor and to_msgpack functions. An input adapter will be created from this pair, so you need to use braces. #478
This commit works around an issue in std::initializer_list design.
By using a detail::json_ref proxy with a mutable value inside,
rvalue-ness of an input to list initializer is remembered and
used later to move from the proxy instead of copying.
Travis found an error with Clang 3.8's sanitizers, see https://travis-ci.org/nlohmann/json/jobs/256366699. Unfortunately, I cannot reproduce this error with clang version 6.0.0 (trunk 308825) locally. However, this seems to be an issue, because so far, we did not reset a value after moving from it.
A complete rewrite of the string escape function. It now provides codepoint-to-\uxxxx escaping. Invalid UTF-8 byte sequences are not escaped, but copied as-is. I haven’t spent much time optimizing the code - but the library now agrees with Python on every single Unicode character’s escaping (see file test/data/json_nlohmann_tests/all_unicode_ascii.json).
Other minor changes: replaced "size_t" by "std::size_t"
It makes no sense to have this special exception. Instead of throwing when an input adapter is created, it is better to detect a parse error in later usage when an EOF is "read" unexpectedly.
These breaks were just added to silence a GCC warning - the GCC is right about warning as it cannot know that the expect function will not return in these two scenarios.
It seems these functions are not required any more. The code was added in commit 7e32457 to fix issue #171. There are still regression tests for #171, so when this commit passes the CI, the functions may be removed for good.
When an empty vector was passed to the parse function, an empty iterator range was used to construct an input iterator. Unfortunately, we then cannot use the start iterator to derive a pointer from.
Found with Xcode's undefined behavior sanitizer.
An optional parameter for dump() allows to set the character to use for
indentation (default: space). In case a JSON value is serialized to an
output stream, its fill character is used (and can be set with
std::setfill).
Creates all well-formed sequences of bytes up to length 4. Furthermore,
creates ill-formed sequences by removing required trailing bytes or
changing bytes. As the tests can take a lot of time, preprocessor
symbols are introduced.
As I learned in https://github.com/melpon/wandbox/issues/209, this
library is already installed at Wandbox, so we need to adjust the
examples to use `#include "json.hpp"` insteas of `#include <json.hpp>`.
These classes are now constructed with an interface adapter. This moves
complexity from various places into the interface adapter class, or to
some factories which now implement the different flavors of input.
Furthermore, input adapters are kept in std::shared_ptr to avoid the
need of manual deletion.
We totally forgot to implement the comparison operators other than ==
and != for scalar types. Consequently, comparing a JSON value with a
scalar type led to compile errors.
- removed uncached input stream adapter; it was too slow anyway
- implemented a class binary_read which parses CBOR based on input
adapters
- in the CBOR parser, numbers are created via memcpy to avoid undefined
behavior
The solution with a std::runtime_error member is more elegant. It
allows to have std::exception as base class again. However, I still
have no idea why GCC thinks the copy constructor may throw...
To have nothrow-copy-constructible exceptions, we inherit from
std::runtime_error which can cope with arbitrary-length error messages.
Intermediate strings are built with static functions and then passed to
the actual constructor.
This commit removed the re2c lexer and replaced it by a manual version.
Its integration is not yet complete: number parsing does not respect
locales or overflows. Furthermore, parsing does not need to end with
EOF. Therefore, a lot of test cases fail. The idea is to push this
branch forward so we can conduct performance comparisons. So far, a
nice side effect are better diagnosis messages in case of parse errors.
We should compare the binary serializations rather than the JSON values
themselves. This fix was already done for CBOR and apparently forgotten
for MessagePack.
- Removed unused headers.
- Added override where needed.
- Added description for parse_error.113 exception.
- Fixed some conversion warnings.
- Integrated cbor_expect_string function for CBOR maps.
- Added documentation on the supported CBOR/MessagePack features.
- Added test to check all initial bytes for CBOR input.
When <Windows.h> is included with MSVC, a macro NOMINMAX is defined
that yields compilation errors when max/min calls are encountered. This
can be fixed by un-defining NOMINMAX, or by placing parentheses around
all min/max calls. We chose the latter.
Since #329, NaN and inf numbers do not yield an exception, but are
stored internally and are dumped as “null”. This commit adjusts the
fuzz testers to deal with this special case.
- If an overflow occurs during parsing a number from a JSON text, an
exception (std::out_of_range for the moment, to be replaced by a
user-defined exception #244) is thrown so that the overflow is detected
early and roundtripping is guaranteed.
- NaN and INF floating-point values can be stored in a JSON value and
are not replaced by null. That is, the basic_json class behaves like
double in this regard (no exception occurs). However, NaN and INF are
serialized to “null”.
- Adjusted test cases appropriately.
To avoid the error described in #497, I added a function
msgpack_expect_string that is executed every time a string is expected
during the parsing of a map. In case the current byte does not belong
to a MsgPack string, an exception is thrown.
This test case relied on logics that have been replaced by CMake with
#461. This change enables compilation and execution of the test suite
without exceptions by adding an after_success task.
Added a test to check if the input stream is good() before executing
getline on it. Also added two test cases that set the failbit and
badbit before calling file_line_buffer.
I used __EXCEPTIONS to detect whether exceptions are supported.
Apparently, this is a macro that is only used by libstdc++
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64276). It’s much cleaner
to use __cpp_exceptions as it is in the standard since C++98.
Note that compiling the unit-tests with “-fno-exceptions” still does
not work, because Catch uses throw internally. However, the library’s
exceptions can be switched off by defining JSON_NOEXCEPTION.
The original test case relied on an invalidated iterator. This error
did not occur before, but only with GCC with -D_GLIBCXX_DEBUG. This
commit fixes the test case. The library is unaffected by this change.
Added class hierarchy for user-defined exceptions (#244). Integrated
parse exceptions 101-103. Parse exceptions include the byte count of
the last read character to locate the position of the error (#301).
The constructor basic_json(std::istream&, const parser_callback_t) has
been deprecated since version 2.0.0. This commit removes it together
with its code example, deprecation macro, and test cases. The code now
also compiles with -W-deprecated-declarations.
The library does not preserve the insertion order of object keys. There
are frequent requests to change the library in this aspect. The README
and the contribution guidelines now contain links to containers that
can be used to replace std::map to preserve the insertion order.
Moved all dump()-related functions into a class "serializer". This fix includes a lot of performance improvements yielding a 7% speedup for serialization. Details on the individual steps can be found in the commit messages.
Individual benchmark numbers:
before:
dump jeopardy.json 5 374555228 ns/op
dump jeopardy.json with indent 5 430953700 ns/op
dump numbers/floats.json 5 622938509 ns/op
dump numbers/signed_ints.json 20 82177979 ns/op
after:
dump jeopardy.json 5 335449757 ns/op -11%
dump jeopardy.json with indent 5 375467773 ns/op -13%
dump numbers/floats.json 5 584611852 ns/op -7%
dump numbers/signed_ints.json 20 68289574 ns/op -17%
- Added comments for the serializer class.
- Added test case for resizing of the indentation string.
- Using std::none_of to check if “.0” needs to be added to
floating-point number.
A lot of small changes to avoid memory allocations:
- The locale is only queried once rather than with every number
serialization.
- The indentation string is recycled between different calls.
- The string escape function avoids a copy if no escaping is necessary.
- The string escape and the space function use a complete switch case
instead of cascaded ifs.
Cachegrind measures some 15% performance improvement.
Treated the size of the range as the number of thousand separators.
This logical error yielded a negative value for written_bytes and
eventually an infinite loop, as written_bytes was converted to an
unsigned value.
The class is currently just a wrapper for an std::ostream and collects
all functions related to serialization. The next step should be
recycling of variables to avoid repetitive initialization for each
recursive dump call.
numtostr now directly writes to a stream. Return value of snprintf is
reused to avoid finding end of string. Cachegrind suggests a 1%
performance increase.
All ‘<<‘ calls have been replaced by write()/put() calls. The
indentation strings needs not to be resized. Cachegrind measures 1%
performance improvement.
Indentation string is recycled to avoid allocations. Comma-separation
in objects does not need an if any more. Cachegrind measures 1%
performance improvement.
Added separate code paths for normal output and pritty-printed output.
This allowed to remove most of the ifs along the way. Benchmarks and
cachegrind suggest a 10% performance improvement.
- Add prefix header
- Include catch.hpp
- Include json.hpp
- Replace private with public for all json_unit files
- Move `unit.cpp` to an object library
- cotire issue: strip whitespace from CMAKE_INCLUDE_SYSTEM_FLAG_CXX
This can however not be done easily for value_t, since
external_constructor depends on it, as is operator< which was moved
outside basic_json too.
This is not really an issue, since all basic_json classes share the same
enum
Those warnings are not "fixed", but that's intentional.
Truncations are expected when ArithmeticType is not the same type than
number_unsigned_t (or another basic_json template argument)
only check for public types (iterators, json_pointer)
for private ones (m_array.iterator, primitive_iterator) simply double
parentheses on relevant Catch checks
- fixed a bug that did not discard strings with control characters
between 0x10 and 0x1f
- added termination proofs for two important loops
- made get_ref() constexpr
In the interest of fostering an open and welcoming environment, we as contributors and maintainers pledge to making participation in our project and our community a harassment-free experience for everyone, regardless of age, body size, disability, ethnicity, gender identity and expression, level of experience, nationality, personal appearance, race, religion, or sexual identity and orientation.
## Our Standards
Examples of behavior that contributes to creating a positive environment include:
* Using welcoming and inclusive language
* Being respectful of differing viewpoints and experiences
* Gracefully accepting constructive criticism
* Focusing on what is best for the community
* Showing empathy towards other community members
Examples of unacceptable behavior by participants include:
* The use of sexualized language or imagery and unwelcome sexual attention or advances
* Trolling, insulting/derogatory comments, and personal or political attacks
* Public or private harassment
* Publishing others' private information, such as a physical or electronic address, without explicit permission
* Other conduct which could reasonably be considered inappropriate in a professional setting
## Our Responsibilities
Project maintainers are responsible for clarifying the standards of acceptable behavior and are expected to take appropriate and fair corrective action in response to any instances of unacceptable behavior.
Project maintainers have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, or to ban temporarily or permanently any contributor for other behaviors that they deem inappropriate, threatening, offensive, or harmful.
## Scope
This Code of Conduct applies both within project spaces and in public spaces when an individual is representing the project or its community. Examples of representing a project or community include using an official project e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event. Representation of a project may be further defined and clarified by project maintainers.
## Enforcement
Instances of abusive, harassing, or otherwise unacceptable behavior may be reported by contacting the project team at mail@nlohmann.me. The project team will review and investigate all complaints, and will respond in a way that it deems appropriate to the circumstances. The project team is obligated to maintain confidentiality with regard to the reporter of an incident. Further details of specific enforcement policies may be posted separately.
Project maintainers who do not follow or enforce the Code of Conduct in good faith may face temporary or permanent repercussions as determined by other members of the project's leadership.
## Attribution
This Code of Conduct is adapted from the [Contributor Covenant][homepage], version 1.4, available at [http://contributor-covenant.org/version/1/4][version]
This project started as a little excuse to exercise some of the cool new C++11 features. Over time, people actually started to use the JSON library (yey!) and started to help improve it by proposing features, finding bugs, or even fixing my mistakes. I am really [thankful](https://github.com/nlohmann/json/blob/master/README.md#thanks) for this and try to keep track of all the helpers.
To make it as easy as possible for you to contribute and for me to keep an overview, here are a few guidelines which should help us avoid all kinds of unnecessary work or disappointment. And of course, this document is subject to discussion, so please [create an issue](https://github.com/nlohmann/json/issues/new) or a pull request if you find a way to improve it!
To make it as easy as possible for you to contribute and for me to keep an overview, here are a few guidelines which should help us avoid all kinds of unnecessary work or disappointment. And of course, this document is subject to discussion, so please [create an issue](https://github.com/nlohmann/json/issues/new/choose) or a pull request if you find a way to improve it!
## Private reports
Usually, all issues are tracked publicly on [GitHub](https://github.com/nlohmann/json/issues). If you want to make a private report (e.g., for a vulnerability or to attach an example that is not meant to be published), please send an email to <mail@nlohmann.me>.
## Prerequisites
Please [create an issue](https://github.com/nlohmann/json/issues/new), assuming one does not already exist, and describe your concern. Note you need a [GitHub account](https://github.com/signup/free) for this.
If you want propose changes to the code, you need to download the [`re2c`](http://re2c.org) tool.
Please [create an issue](https://github.com/nlohmann/json/issues/new/choose), assuming one does not already exist, and describe your concern. Note you need a [GitHub account](https://github.com/signup/free) for this.
## Describe your issue
@@ -20,56 +22,50 @@ Clearly describe the issue:
- If you propose a change or addition, try to give an **example** how the improved code could look like or how to use it.
- If you found a compilation error, please tell us which **compiler** (version and operating system) you used and paste the (relevant part of) the error messages to the ticket.
Please stick to the provided issue template ([bug report](https://github.com/nlohmann/json/blob/develop/.github/ISSUE_TEMPLATE/bug.yml) if possible. For questions, feature or support requests, please [open a discussion](https://github.com/nlohmann/json/discussions/new).
## Files to change
There are currently two files which need to be edited:
:exclamation: Before you make any changes, note the single-header files [`single_include/nlohmann/json.hpp`](https://github.com/nlohmann/json/blob/develop/single_include/nlohmann/json.hpp) and [`single_include/nlohmann/json_fwd.hpp`](https://github.com/nlohmann/json/blob/develop/single_include/nlohmann/json_fwd.hpp) are **generated** from the source files in the [`include/nlohmann` directory](https://github.com/nlohmann/json/tree/develop/include/nlohmann). Please **do not** edit the files `single_include/nlohmann/json.hpp` and `single_include/nlohmann/json_fwd.hpp` directly, but change the `include/nlohmann` sources and regenerate the files by executing `make amalgamate`.
1. [`src/json.hpp.re2c`](https://github.com/nlohmann/json/blob/master/src/json.hpp.re2c) (note the `.re2c` suffix) - This file contains a comment section which describes the JSON lexic. This section is translated by [`re2c`](http://re2c.org) into file [`src/json.hpp`](https://github.com/nlohmann/json/blob/master/src/json.hpp) which is plain "vanilla" C++11 code. (In fact, the generated lexer consists of some hundred lines of `goto`s, which is a hint you never want to edit this file...).
To make changes, you need to edit the following files:
If you only edit file `src/json.hpp` (without the `.re2c` suffix), your changes will be overwritten as soon as the lexer is touched again. To generate the `src/json.hpp` file which is actually used during compilation of the tests and all other code, please execute
1. [`include/nlohmann/*`](https://github.com/nlohmann/json/tree/develop/include/nlohmann) - These files are the sources of the library. Before testing or creating a pull request, execute `make amalgamate` to regenerate `single_include/nlohmann/json.hpp` and `single_include/nlohmann/json_fwd.hpp`.
2. [`tests/src/unit-*.cpp`](https://github.com/nlohmann/json/tree/develop/tests/src) - These files contain the [doctest](https://github.com/onqtam/doctest) unit tests which currently cover [100 %](https://coveralls.io/github/nlohmann/json) of the library's code. Before creating a pull request, execute `make pretty` to make sure that the style is correct, as this will be checked by the CI.
If you add or change a feature, please also add a unit test to this file. The unit tests can be compiled and executed with
```sh
make re2c
```
To run [`re2c`](http://re2c.org) and generate/overwrite file `src/json.hpp` with your changes in file `src/json.hpp.re2c`.
2. [`test/src/unit.cpp`](https://github.com/nlohmann/json/blob/master/test/unit.cpp) - This contains the [Catch](https://github.com/philsquared/Catch) unit tests which currently cover [100 %](https://coveralls.io/github/nlohmann/json) of the library's code.
If you add or change a feature, please also add a unit test to this file. The unit tests can be compiled with
```sh
make
```
and can be executed with
```sh
./json_unit
$ mkdir build
$ cd build
$ cmake ..
$ cmake --build .
$ ctest
```
The test cases are also executed with several different compilers on [Travis](https://travis-ci.org/nlohmann/json) once you open a pull request.
Please understand that I cannot accept pull requests changing only file `src/json.hpp`.
## Note
- If you open a pull request, the code will be automatically tested with [Valgrind](http://valgrind.org)'s Memcheck tool to detect memory leaks. Please be aware that the execution with Valgrind _may_ in rare cases yield different behavior than running the code directly. This can result in failing unit tests which run successfully without Valgrind.
- There is a Makefile target `make pretty` which runs [Artistic Style](http://astyle.sourceforge.net) to fix indentation. If possible, run it before opening the pull request. Otherwise, we shall run it afterward.
## Please don't
- Only make changes to file `src/json.hpp` -- please read the paragraph above and understand why `src/json.hpp.re2c` exists.
- The C++11 support varies between different **compilers** and versions. Please note the [list of supported compilers](https://github.com/nlohmann/json/blob/master/README.md#supported-compilers). Some compilers like GCC 4.8 (and earlier), Clang 3.3 (and earlier), or Microsoft Visual Studio 13.0 and earlier are known not to work due to missing or incomplete C++11 support. Please refrain from proposing changes that work around these compiler's limitations with `#ifdef`s or other means.
- Specifically, I am aware of compilation problems with **Microsoft Visual Studio** (there even is an [issue label](https://github.com/nlohmann/json/issues?utf8=✓&q=label%3A%22visual+studio%22+) for these kind of bugs). I understand that even in 2016, complete C++11 support isn't there yet. But please also understand that I do not want to drop features or uglify the code just to make Microsoft's sub-standard compiler happy. The past has shown that there are ways to express the functionality such that the code compiles with the most recent MSVC - unfortunately, this is not the main objective of the project.
- Please refrain from proposing changes that would **break [JSON](http://json.org) conformance**. If you propose a conformant extension of JSON to be supported by the library, please motivate this extension.
- The C++11 support varies between different **compilers** and versions. Please note the [list of supported compilers](https://github.com/nlohmann/json/blob/master/README.md#supported-compilers). Some compilers like GCC 4.7 (and earlier), Clang 3.3 (and earlier), or Microsoft Visual Studio 13.0 and earlier are known not to work due to missing or incomplete C++11 support. Please refrain from proposing changes that work around these compiler's limitations with `#ifdef`s or other means.
- Specifically, I am aware of compilation problems with **Microsoft Visual Studio** (there even is an [issue label](https://github.com/nlohmann/json/issues?utf8=✓&q=label%3A%22visual+studio%22+) for this kind of bug). I understand that even in 2016, complete C++11 support isn't there yet. But please also understand that I do not want to drop features or uglify the code just to make Microsoft's sub-standard compiler happy. The past has shown that there are ways to express the functionality such that the code compiles with the most recent MSVC - unfortunately, this is not the main objective of the project.
- Please refrain from proposing changes that would **break [JSON](https://json.org) conformance**. If you propose a conformant extension of JSON to be supported by the library, please motivate this extension.
- We shall not extend the library to **support comments**. There is quite some [controversy](https://www.reddit.com/r/programming/comments/4v6chu/why_json_doesnt_support_comments_douglas_crockford/) around this topic, and there were quite some [issues](https://github.com/nlohmann/json/issues/376) on this. We believe that JSON is fine without comments.
- We do not preserve the **insertion order of object elements**. The [JSON standard](https://tools.ietf.org/html/rfc8259.html) defines objects as "an unordered collection of zero or more name/value pairs". To this end, this library does not preserve insertion order of name/value pairs. (In fact, keys will be traversed in alphabetical order as `std::map` with `std::less` is used by default.) Note this behavior conforms to the standard, and we shall not change it to any other order. If you do want to preserve the insertion order, you can specialize the object type with containers like [`tsl::ordered_map`](https://github.com/Tessil/ordered-map) or [`nlohmann::fifo_map`](https://github.com/nlohmann/fifo_map).
- Please do not open pull requests that address **multiple issues**.
## Wanted
The following areas really need contribution:
- Extending the **continuous integration** toward more exotic compilers such as Android NDK, Intel's Compiler, or the bleeding-edge versions of GCC or Clang.
- Extending the **continuous integration** toward more exotic compilers such as Android NDK, Intel's Compiler, or the bleeding-edge versions Clang.
- Improving the efficiency of the **JSON parser**. The current parser is implemented as a naive recursive descent parser with hand coded string handling. More sophisticated approaches like LALR parsers would be really appreciated. That said, parser generators like Bison or ANTLR do not play nice with single-header files -- I really would like to keep the parser inside the `json.hpp` header, and I am not aware of approaches similar to [`re2c`](http://re2c.org) for parsing.
- Extending and updating existing **benchmarks** to include (the most recent version of) this library. Though efficiency is not everything, speed and memory consumption are very important characteristics for C++ developers, so having proper comparisons would be interesting.
[Describe your pull request here. Please read the text below the line, and make sure you follow the checklist.]
## Files to change
* * *
There are currently two files which need to be edited:
## Pull request checklist
1. [`src/json.hpp.re2c`](https://github.com/nlohmann/json/blob/master/src/json.hpp.re2c) (note the `.re2c` suffix) - This file contains a comment section which describes the JSON lexic. This section is translated by [`re2c`](http://re2c.org) into file [`src/json.hpp`](https://github.com/nlohmann/json/blob/master/src/json.hpp) which is plain "vanilla" C++11 code. (In fact, the generated lexer consists of some hundred lines of `goto`s, which is a hint you never want to edit this file...).
Read the [Contribution Guidelines](https://github.com/nlohmann/json/blob/develop/.github/CONTRIBUTING.md) for detailed information.
If you only edit file `src/json.hpp` (without the `.re2c` suffix), your changes will be overwritten as soon as the lexer is touched again. To generate the `src/json.hpp` file which is actually used during compilation of the tests and all other code, please execute
```sh
make re2c
```
To run [`re2c`](http://re2c.org) and generate/overwrite file `src/json.hpp` with your changes in file `src/json.hpp.re2c`.
2. [`test/src/unit.cpp`](https://github.com/nlohmann/json/blob/master/test/unit.cpp) - This contains the [Catch](https://github.com/philsquared/Catch) unit tests which currently cover [100 %](https://coveralls.io/github/nlohmann/json) of the library's code.
If you add or change a feature, please also add a unit test to this file. The unit tests can be compiled with
```sh
make
```
and can be executed with
```sh
./json_unit
```
The test cases are also executed with several different compilers on [Travis](https://travis-ci.org/nlohmann/json) once you open a pull request.
Please understand that I cannot accept pull requests changing only file `src/json.hpp`.
## Note
- If you open a pull request, the code will be automatically tested with [Valgrind](http://valgrind.org)'s Memcheck tool to detect memory leaks. Please be aware that the execution with Valgrind _may_ in rare cases yield different behavior than running the code directly. This can result in failing unit tests which run successfully without Valgrind.
- [ ] Changes are described in the pull request, or an [existing issue is referenced](https://github.com/nlohmann/json/issues).
- [ ] The test suite [compiles and runs](https://github.com/nlohmann/json/blob/develop/README.md#execute-unit-tests) without error.
- [ ] [Code coverage](https://coveralls.io/github/nlohmann/json) is 100%. Test cases can be added by editing the [test suite](https://github.com/nlohmann/json/tree/develop/test/src).
- [ ] The source code is amalgamated; that is, after making changes to the sources in the `include/nlohmann` directory, run `make amalgamate` to create the single-header files `single_include/nlohmann/json.hpp` and `single_include/nlohmann/json_fwd.hpp`. The whole process is described [here](https://github.com/nlohmann/json/blob/develop/.github/CONTRIBUTING.md#files-to-change).
## Please don't
- Only make changes to file `src/json.hpp` -- please read the paragraph above and understand why `src/json.hpp.re2c` exists.
- The C++11 support varies between different **compilers** and versions. Please note the [list of supported compilers](https://github.com/nlohmann/json/blob/master/README.md#supported-compilers). Some compilers like GCC 4.8 (and earlier), Clang 3.3 (and earlier), or Microsoft Visual Studio 13.0 and earlier are known not to work due to missing or incomplete C++11 support. Please refrain from proposing changes that work around these compiler's limitations with `#ifdef`s or other means.
-Specifically, I am aware of compilation problems with **Microsoft Visual Studio** (there even is an [issue label](https://github.com/nlohmann/json/issues?utf8=✓&q=label%3A%22visual+studio%22+) for these kind of bugs). I understand that even in 2016, complete C++11 support isn't there yet. But please also understand that I do not want to drop features or uglify the code just to make Microsoft's sub-standard compiler happy. The past has shown that there are ways to express the functionality such that the code compiles with the most recent MSVC - unfortunately, this is not the main objective of the project.
- Please refrain from proposing changes that would **break [JSON](http://json.org) conformance**. If you propose a conformant extension of JSON to be supported by the library, please motivate this extension.
- The C++11 support varies between different **compilers** and versions. Please note the [list of supported compilers](https://github.com/nlohmann/json/blob/master/README.md#supported-compilers). Some compilers like GCC 4.7 (and earlier), Clang 3.3 (and earlier), or Microsoft Visual Studio 13.0 and earlier are known not to work due to missing or incomplete C++11 support. Please refrain from proposing changes that work around these compiler's limitations with `#ifdef`s or other means.
- Specifically, I am aware of compilation problems with **Microsoft Visual Studio** (there even is an [issue label](https://github.com/nlohmann/json/issues?utf8=✓&q=label%3A%22visual+studio%22+) for this kind of bug). I understand that even in 2016, complete C++11 support isn't there yet. But please also understand that I do not want to drop features or uglify the code just to make Microsoft's sub-standard compiler happy. The past has shown that there are ways to express the functionality such that the code compiles with the most recent MSVC - unfortunately, this is not the main objective of the project.
-Please refrain from proposing changes that would **break [JSON](https://json.org) conformance**. If you propose a conformant extension of JSON to be supported by the library, please motivate this extension.
- Please do not open pull requests that address **multiple issues**.
Usually, all issues are tracked publicly on [GitHub](https://github.com/nlohmann/json/issues). If you want to make a private report (e.g., for a vulnerability or to attach an example that is not meant to be published), please send an email to <mail@nlohmann.me>. You can use [this key](https://keybase.io/nlohmann/pgp_keys.asc?fingerprint=797167ae41c0a6d9232e48457f3cea63ae251b69) for encryption.
# Configuration for sentiment-bot - https://github.com/behaviorbot/sentiment-bot
# *Required* toxicity threshold between 0 and .99 with the higher numbers being the most toxic
# Anything higher than this threshold will be marked as toxic and commented on
sentimentBotToxicityThreshold:.7
# *Required* Comment to reply with
sentimentBotReplyComment:>
Please be sure to review the [code of conduct](https://github.com/nlohmann/json/blob/develop/CODE_OF_CONDUCT.md) and be respectful of other users. cc/ @nlohmann
# Configuration for request-info - https://github.com/behaviorbot/request-info
# *Required* Comment to reply with
requestInfoReplyComment:>
We would appreciate it if you could provide us with more info about this issue or pull request! Please check the [issue template](https://github.com/nlohmann/json/blob/develop/.github/ISSUE_TEMPLATE.md) and the [pull request template](https://github.com/nlohmann/json/blob/develop/.github/PULL_REQUEST_TEMPLATE.md).
# *OPTIONAL* Label to be added to Issues and Pull Requests with insufficient information given
TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
1. Definitions.
"License" shall mean the terms and conditions for use, reproduction, and distribution as defined by Sections 1 through 9 of this document.
"Licensor" shall mean the copyright owner or entity authorized by the copyright owner that is granting the License.
"Legal Entity" shall mean the union of the acting entity and all other entities that control, are controlled by, or are under common control with that entity. For the purposes of this definition, "control" means (i) the power, direct or indirect, to cause the direction or management of such entity, whether by contract or otherwise, or (ii) ownership of fifty percent (50%) or more of the outstanding shares, or (iii) beneficial ownership of such entity.
"You" (or "Your") shall mean an individual or Legal Entity exercising permissions granted by this License.
"Source" form shall mean the preferred form for making modifications, including but not limited to software source code, documentation source, and configuration files.
"Object" form shall mean any form resulting from mechanical transformation or translation of a Source form, including but not limited to compiled object code, generated documentation, and conversions to other media types.
"Work" shall mean the work of authorship, whether in Source or Object form, made available under the License, as indicated by a copyright notice that is included in or attached to the work (an example is provided in the Appendix below).
"Derivative Works" shall mean any work, whether in Source or Object form, that is based on (or derived from) the Work and for which the editorial revisions, annotations, elaborations, or other modifications represent, as a whole, an original work of authorship. For the purposes of this License, Derivative Works shall not include works that remain separable from, or merely link (or bind by name) to the interfaces of, the Work and Derivative Works thereof.
"Contribution" shall mean any work of authorship, including the original version of the Work and any modifications or additions to that Work or Derivative Works thereof, that is intentionally submitted to Licensor for inclusion in the Work by the copyright owner or by an individual or Legal Entity authorized to submit on behalf of the copyright owner. For the purposes of this definition, "submitted" means any form of electronic, verbal, or written communication sent to the Licensor or its representatives, including but not limited to communication on electronic mailing lists, source code control systems, and issue tracking systems that are managed by, or on behalf of, the Licensor for the purpose of discussing and improving the Work, but excluding communication that is conspicuously marked or otherwise designated in writing by the copyright owner as "Not a Contribution."
"Contributor" shall mean Licensor and any individual or Legal Entity on behalf of whom a Contribution has been received by Licensor and subsequently incorporated within the Work.
2. Grant of Copyright License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable copyright license to reproduce, prepare Derivative Works of, publicly display, publicly perform, sublicense, and distribute the Work and such Derivative Works in Source or Object form.
3. Grant of Patent License. Subject to the terms and conditions of this License, each Contributor hereby grants to You a perpetual, worldwide, non-exclusive, no-charge, royalty-free, irrevocable (except as stated in this section) patent license to make, have made, use, offer to sell, sell, import, and otherwise transfer the Work, where such license applies only to those patent claims licensable by such Contributor that are necessarily infringed by their Contribution(s) alone or by combination of their Contribution(s) with the Work to which such Contribution(s) was submitted. If You institute patent litigation against any entity (including a cross-claim or counterclaim in a lawsuit) alleging that the Work or a Contribution incorporated within the Work constitutes direct or contributory patent infringement, then any patent licenses granted to You under this License for that Work shall terminate as of the date such litigation is filed.
4. Redistribution. You may reproduce and distribute copies of the Work or Derivative Works thereof in any medium, with or without modifications, and in Source or Object form, provided that You meet the following conditions:
(a) You must give any other recipients of the Work or Derivative Works a copy of this License; and
(b) You must cause any modified files to carry prominent notices stating that You changed the files; and
(c) You must retain, in the Source form of any Derivative Works that You distribute, all copyright, patent, trademark, and attribution notices from the Source form of the Work, excluding those notices that do not pertain to any part of the Derivative Works; and
(d) If the Work includes a "NOTICE" text file as part of its distribution, then any Derivative Works that You distribute must include a readable copy of the attribution notices contained within such NOTICE file, excluding those notices that do not pertain to any part of the Derivative Works, in at least one of the following places: within a NOTICE text file distributed as part of the Derivative Works; within the Source form or documentation, if provided along with the Derivative Works; or, within a display generated by the Derivative Works, if and wherever such third-party notices normally appear. The contents of the NOTICE file are for informational purposes only and do not modify the License. You may add Your own attribution notices within Derivative Works that You distribute, alongside or as an addendum to the NOTICE text from the Work, provided that such additional attribution notices cannot be construed as modifying the License.
You may add Your own copyright statement to Your modifications and may provide additional or different license terms and conditions for use, reproduction, or distribution of Your modifications, or for any such Derivative Works as a whole, provided Your use, reproduction, and distribution of the Work otherwise complies with the conditions stated in this License.
5. Submission of Contributions. Unless You explicitly state otherwise, any Contribution intentionally submitted for inclusion in the Work by You to the Licensor shall be under the terms and conditions of this License, without any additional terms or conditions. Notwithstanding the above, nothing herein shall supersede or modify the terms of any separate license agreement you may have executed with Licensor regarding such Contributions.
6. Trademarks. This License does not grant permission to use the trade names, trademarks, service marks, or product names of the Licensor, except as required for reasonable and customary use in describing the origin of the Work and reproducing the content of the NOTICE file.
7. Disclaimer of Warranty. Unless required by applicable law or agreed to in writing, Licensor provides the Work (and each Contributor provides its Contributions) on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied, including, without limitation, any warranties or conditions of TITLE, NON-INFRINGEMENT, MERCHANTABILITY, or FITNESS FOR A PARTICULAR PURPOSE. You are solely responsible for determining the appropriateness of using or redistributing the Work and assume any risks associated with Your exercise of permissions under this License.
8. Limitation of Liability. In no event and under no legal theory, whether in tort (including negligence), contract, or otherwise, unless required by applicable law (such as deliberate and grossly negligent acts) or agreed to in writing, shall any Contributor be liable to You for damages, including any direct, indirect, special, incidental, or consequential damages of any character arising as a result of this License or out of the use or inability to use the Work (including but not limited to damages for loss of goodwill, work stoppage, computer failure or malfunction, or any and all other commercial damages or losses), even if such Contributor has been advised of the possibility of such damages.
9. Accepting Warranty or Additional Liability. While redistributing the Work or Derivative Works thereof, You may choose to offer, and charge a fee for, acceptance of support, warranty, indemnity, or other liability obligations and/or rights consistent with this License. However, in accepting such obligations, You may act only on Your own behalf and on Your sole responsibility, not on behalf of any other Contributor, and only if You agree to indemnify, defend, and hold each Contributor harmless for any liability incurred by, or claims asserted against, such Contributor by reason of your accepting any such warranty or additional liability.
END OF TERMS AND CONDITIONS
APPENDIX: How to apply the Apache License to your work.
To apply the Apache License to your work, attach the following boilerplate notice, with the fields enclosed by brackets "[]" replaced with your own identifying information. (Don't include the brackets!) The text should be enclosed in the appropriate comment syntax for the file format. We also recommend that a file or class name and description of purpose be included on the same "printed page" as the copyright notice for easier identification within third-party archives.
Copyright [yyyy] [name of copyright owner]
Licensed under the Apache License, Version 2.0 (the "License");
you may not use this file except in compliance with the License.
You may obtain a copy of the License at
http://www.apache.org/licenses/LICENSE-2.0
Unless required by applicable law or agreed to in writing, software
distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
See the License for the specific language governing permissions and
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution.
3. Neither the name of the copyright holder nor the names of its contributors may be used to endorse or promote products derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.
Preamble
The GNU General Public License is a free, copyleft license for software and other kinds of works.
The licenses for most software and other practical works are designed to take away your freedom to share and change the works. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change all versions of a program--to make sure it remains free software for all its users. We, the Free Software Foundation, use the GNU General Public License for most of our software; it applies also to any other work released this way by its authors. You can apply it to your programs, too.
When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for them if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs, and that you know you can do these things.
To protect your rights, we need to prevent others from denying you these rights or asking you to surrender the rights. Therefore, you have certain responsibilities if you distribute copies of the software, or if you modify it: responsibilities to respect the freedom of others.
For example, if you distribute copies of such a program, whether gratis or for a fee, you must pass on to the recipients the same freedoms that you received. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.
Developers that use the GNU GPL protect your rights with two steps: (1) assert copyright on the software, and (2) offer you this License giving you legal permission to copy, distribute and/or modify it.
For the developers' and authors' protection, the GPL clearly explains that there is no warranty for this free software. For both users' and authors' sake, the GPL requires that modified versions be marked as changed, so that their problems will not be attributed erroneously to authors of previous versions.
Some devices are designed to deny users access to install or run modified versions of the software inside them, although the manufacturer can do so. This is fundamentally incompatible with the aim of protecting users' freedom to change the software. The systematic pattern of such abuse occurs in the area of products for individuals to use, which is precisely where it is most unacceptable. Therefore, we have designed this version of the GPL to prohibit the practice for those products. If such problems arise substantially in other domains, we stand ready to extend this provision to those domains in future versions of the GPL, as needed to protect the freedom of users.
Finally, every program is threatened constantly by software patents. States should not allow patents to restrict development and use of software on general-purpose computers, but in those that do, we wish to avoid the special danger that patents applied to a free program could make it effectively proprietary. To prevent this, the GPL assures that patents cannot be used to render the program non-free.
The precise terms and conditions for copying, distribution and modification follow.
TERMS AND CONDITIONS
0. Definitions.
“This License” refers to version 3 of the GNU General Public License.
“Copyright” also means copyright-like laws that apply to other kinds of works, such as semiconductor masks.
“The Program” refers to any copyrightable work licensed under this License. Each licensee is addressed as “you”. “Licensees” and “recipients” may be individuals or organizations.
To “modify” a work means to copy from or adapt all or part of the work in a fashion requiring copyright permission, other than the making of an exact copy. The resulting work is called a “modified version” of the earlier work or a work “based on” the earlier work.
A “covered work” means either the unmodified Program or a work based on the Program.
To “propagate” a work means to do anything with it that, without permission, would make you directly or secondarily liable for infringement under applicable copyright law, except executing it on a computer or modifying a private copy. Propagation includes copying, distribution (with or without modification), making available to the public, and in some countries other activities as well.
To “convey” a work means any kind of propagation that enables other parties to make or receive copies. Mere interaction with a user through a computer network, with no transfer of a copy, is not conveying.
An interactive user interface displays “Appropriate Legal Notices” to the extent that it includes a convenient and prominently visible feature that (1) displays an appropriate copyright notice, and (2) tells the user that there is no warranty for the work (except to the extent that warranties are provided), that licensees may convey the work under this License, and how to view a copy of this License. If the interface presents a list of user commands or options, such as a menu, a prominent item in the list meets this criterion.
1. Source Code.
The “source code” for a work means the preferred form of the work for making modifications to it. “Object code” means any non-source form of a work.
A “Standard Interface” means an interface that either is an official standard defined by a recognized standards body, or, in the case of interfaces specified for a particular programming language, one that is widely used among developers working in that language.
The “System Libraries” of an executable work include anything, other than the work as a whole, that (a) is included in the normal form of packaging a Major Component, but which is not part of that Major Component, and (b) serves only to enable use of the work with that Major Component, or to implement a Standard Interface for which an implementation is available to the public in source code form. A “Major Component”, in this context, means a major essential component (kernel, window system, and so on) of the specific operating system (if any) on which the executable work runs, or a compiler used to produce the work, or an object code interpreter used to run it.
The “Corresponding Source” for a work in object code form means all the source code needed to generate, install, and (for an executable work) run the object code and to modify the work, including scripts to control those activities. However, it does not include the work's System Libraries, or general-purpose tools or generally available free programs which are used unmodified in performing those activities but which are not part of the work. For example, Corresponding Source includes interface definition files associated with source files for the work, and the source code for shared libraries and dynamically linked subprograms that the work is specifically designed to require, such as by intimate data communication or control flow between those subprograms and other parts of the work.
The Corresponding Source need not include anything that users can regenerate automatically from other parts of the Corresponding Source.
The Corresponding Source for a work in source code form is that same work.
2. Basic Permissions.
All rights granted under this License are granted for the term of copyright on the Program, and are irrevocable provided the stated conditions are met. This License explicitly affirms your unlimited permission to run the unmodified Program. The output from running a covered work is covered by this License only if the output, given its content, constitutes a covered work. This License acknowledges your rights of fair use or other equivalent, as provided by copyright law.
You may make, run and propagate covered works that you do not convey, without conditions so long as your license otherwise remains in force. You may convey covered works to others for the sole purpose of having them make modifications exclusively for you, or provide you with facilities for running those works, provided that you comply with the terms of this License in conveying all material for which you do not control copyright. Those thus making or running the covered works for you must do so exclusively on your behalf, under your direction and control, on terms that prohibit them from making any copies of your copyrighted material outside their relationship with you.
Conveying under any other circumstances is permitted solely under the conditions stated below. Sublicensing is not allowed; section 10 makes it unnecessary.
3. Protecting Users' Legal Rights From Anti-Circumvention Law.
No covered work shall be deemed part of an effective technological measure under any applicable law fulfilling obligations under article 11 of the WIPO copyright treaty adopted on 20 December 1996, or similar laws prohibiting or restricting circumvention of such measures.
When you convey a covered work, you waive any legal power to forbid circumvention of technological measures to the extent such circumvention is effected by exercising rights under this License with respect to the covered work, and you disclaim any intention to limit operation or modification of the work as a means of enforcing, against the work's users, your or third parties' legal rights to forbid circumvention of technological measures.
4. Conveying Verbatim Copies.
You may convey verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice; keep intact all notices stating that this License and any non-permissive terms added in accord with section 7 apply to the code; keep intact all notices of the absence of any warranty; and give all recipients a copy of this License along with the Program.
You may charge any price or no price for each copy that you convey, and you may offer support or warranty protection for a fee.
5. Conveying Modified Source Versions.
You may convey a work based on the Program, or the modifications to produce it from the Program, in the form of source code under the terms of section 4, provided that you also meet all of these conditions:
a) The work must carry prominent notices stating that you modified it, and giving a relevant date.
b) The work must carry prominent notices stating that it is released under this License and any conditions added under section 7. This requirement modifies the requirement in section 4 to “keep intact all notices”.
c) You must license the entire work, as a whole, under this License to anyone who comes into possession of a copy. This License will therefore apply, along with any applicable section 7 additional terms, to the whole of the work, and all its parts, regardless of how they are packaged. This License gives no permission to license the work in any other way, but it does not invalidate such permission if you have separately received it.
d) If the work has interactive user interfaces, each must display Appropriate Legal Notices; however, if the Program has interactive interfaces that do not display Appropriate Legal Notices, your work need not make them do so.
A compilation of a covered work with other separate and independent works, which are not by their nature extensions of the covered work, and which are not combined with it such as to form a larger program, in or on a volume of a storage or distribution medium, is called an “aggregate” if the compilation and its resulting copyright are not used to limit the access or legal rights of the compilation's users beyond what the individual works permit. Inclusion of a covered work in an aggregate does not cause this License to apply to the other parts of the aggregate.
6. Conveying Non-Source Forms.
You may convey a covered work in object code form under the terms of sections 4 and 5, provided that you also convey the machine-readable Corresponding Source under the terms of this License, in one of these ways:
a) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by the Corresponding Source fixed on a durable physical medium customarily used for software interchange.
b) Convey the object code in, or embodied in, a physical product (including a physical distribution medium), accompanied by a written offer, valid for at least three years and valid for as long as you offer spare parts or customer support for that product model, to give anyone who possesses the object code either (1) a copy of the Corresponding Source for all the software in the product that is covered by this License, on a durable physical medium customarily used for software interchange, for a price no more than your reasonable cost of physically performing this conveying of source, or (2) access to copy the Corresponding Source from a network server at no charge.
c) Convey individual copies of the object code with a copy of the written offer to provide the Corresponding Source. This alternative is allowed only occasionally and noncommercially, and only if you received the object code with such an offer, in accord with subsection 6b.
d) Convey the object code by offering access from a designated place (gratis or for a charge), and offer equivalent access to the Corresponding Source in the same way through the same place at no further charge. You need not require recipients to copy the Corresponding Source along with the object code. If the place to copy the object code is a network server, the Corresponding Source may be on a different server (operated by you or a third party) that supports equivalent copying facilities, provided you maintain clear directions next to the object code saying where to find the Corresponding Source. Regardless of what server hosts the Corresponding Source, you remain obligated to ensure that it is available for as long as needed to satisfy these requirements.
e) Convey the object code using peer-to-peer transmission, provided you inform other peers where the object code and Corresponding Source of the work are being offered to the general public at no charge under subsection 6d.
A separable portion of the object code, whose source code is excluded from the Corresponding Source as a System Library, need not be included in conveying the object code work.
A “User Product” is either (1) a “consumer product”, which means any tangible personal property which is normally used for personal, family, or household purposes, or (2) anything designed or sold for incorporation into a dwelling. In determining whether a product is a consumer product, doubtful cases shall be resolved in favor of coverage. For a particular product received by a particular user, “normally used” refers to a typical or common use of that class of product, regardless of the status of the particular user or of the way in which the particular user actually uses, or expects or is expected to use, the product. A product is a consumer product regardless of whether the product has substantial commercial, industrial or non-consumer uses, unless such uses represent the only significant mode of use of the product.
“Installation Information” for a User Product means any methods, procedures, authorization keys, or other information required to install and execute modified versions of a covered work in that User Product from a modified version of its Corresponding Source. The information must suffice to ensure that the continued functioning of the modified object code is in no case prevented or interfered with solely because modification has been made.
If you convey an object code work under this section in, or with, or specifically for use in, a User Product, and the conveying occurs as part of a transaction in which the right of possession and use of the User Product is transferred to the recipient in perpetuity or for a fixed term (regardless of how the transaction is characterized), the Corresponding Source conveyed under this section must be accompanied by the Installation Information. But this requirement does not apply if neither you nor any third party retains the ability to install modified object code on the User Product (for example, the work has been installed in ROM).
The requirement to provide Installation Information does not include a requirement to continue to provide support service, warranty, or updates for a work that has been modified or installed by the recipient, or for the User Product in which it has been modified or installed. Access to a network may be denied when the modification itself materially and adversely affects the operation of the network or violates the rules and protocols for communication across the network.
Corresponding Source conveyed, and Installation Information provided, in accord with this section must be in a format that is publicly documented (and with an implementation available to the public in source code form), and must require no special password or key for unpacking, reading or copying.
7. Additional Terms.
“Additional permissions” are terms that supplement the terms of this License by making exceptions from one or more of its conditions. Additional permissions that are applicable to the entire Program shall be treated as though they were included in this License, to the extent that they are valid under applicable law. If additional permissions apply only to part of the Program, that part may be used separately under those permissions, but the entire Program remains governed by this License without regard to the additional permissions.
When you convey a copy of a covered work, you may at your option remove any additional permissions from that copy, or from any part of it. (Additional permissions may be written to require their own removal in certain cases when you modify the work.) You may place additional permissions on material, added by you to a covered work, for which you have or can give appropriate copyright permission.
Notwithstanding any other provision of this License, for material you add to a covered work, you may (if authorized by the copyright holders of that material) supplement the terms of this License with terms:
a) Disclaiming warranty or limiting liability differently from the terms of sections 15 and 16 of this License; or
b) Requiring preservation of specified reasonable legal notices or author attributions in that material or in the Appropriate Legal Notices displayed by works containing it; or
c) Prohibiting misrepresentation of the origin of that material, or requiring that modified versions of such material be marked in reasonable ways as different from the original version; or
d) Limiting the use for publicity purposes of names of licensors or authors of the material; or
e) Declining to grant rights under trademark law for use of some trade names, trademarks, or service marks; or
f) Requiring indemnification of licensors and authors of that material by anyone who conveys the material (or modified versions of it) with contractual assumptions of liability to the recipient, for any liability that these contractual assumptions directly impose on those licensors and authors.
All other non-permissive additional terms are considered “further restrictions” within the meaning of section 10. If the Program as you received it, or any part of it, contains a notice stating that it is governed by this License along with a term that is a further restriction, you may remove that term. If a license document contains a further restriction but permits relicensing or conveying under this License, you may add to a covered work material governed by the terms of that license document, provided that the further restriction does not survive such relicensing or conveying.
If you add terms to a covered work in accord with this section, you must place, in the relevant source files, a statement of the additional terms that apply to those files, or a notice indicating where to find the applicable terms.
Additional terms, permissive or non-permissive, may be stated in the form of a separately written license, or stated as exceptions; the above requirements apply either way.
8. Termination.
You may not propagate or modify a covered work except as expressly provided under this License. Any attempt otherwise to propagate or modify it is void, and will automatically terminate your rights under this License (including any patent licenses granted under the third paragraph of section 11).
However, if you cease all violation of this License, then your license from a particular copyright holder is reinstated (a) provisionally, unless and until the copyright holder explicitly and finally terminates your license, and (b) permanently, if the copyright holder fails to notify you of the violation by some reasonable means prior to 60 days after the cessation.
Moreover, your license from a particular copyright holder is reinstated permanently if the copyright holder notifies you of the violation by some reasonable means, this is the first time you have received notice of violation of this License (for any work) from that copyright holder, and you cure the violation prior to 30 days after your receipt of the notice.
Termination of your rights under this section does not terminate the licenses of parties who have received copies or rights from you under this License. If your rights have been terminated and not permanently reinstated, you do not qualify to receive new licenses for the same material under section 10.
9. Acceptance Not Required for Having Copies.
You are not required to accept this License in order to receive or run a copy of the Program. Ancillary propagation of a covered work occurring solely as a consequence of using peer-to-peer transmission to receive a copy likewise does not require acceptance. However, nothing other than this License grants you permission to propagate or modify any covered work. These actions infringe copyright if you do not accept this License. Therefore, by modifying or propagating a covered work, you indicate your acceptance of this License to do so.
10. Automatic Licensing of Downstream Recipients.
Each time you convey a covered work, the recipient automatically receives a license from the original licensors, to run, modify and propagate that work, subject to this License. You are not responsible for enforcing compliance by third parties with this License.
An “entity transaction” is a transaction transferring control of an organization, or substantially all assets of one, or subdividing an organization, or merging organizations. If propagation of a covered work results from an entity transaction, each party to that transaction who receives a copy of the work also receives whatever licenses to the work the party's predecessor in interest had or could give under the previous paragraph, plus a right to possession of the Corresponding Source of the work from the predecessor in interest, if the predecessor has it or can get it with reasonable efforts.
You may not impose any further restrictions on the exercise of the rights granted or affirmed under this License. For example, you may not impose a license fee, royalty, or other charge for exercise of rights granted under this License, and you may not initiate litigation (including a cross-claim or counterclaim in a lawsuit) alleging that any patent claim is infringed by making, using, selling, offering for sale, or importing the Program or any portion of it.
11. Patents.
A “contributor” is a copyright holder who authorizes use under this License of the Program or a work on which the Program is based. The work thus licensed is called the contributor's “contributor version”.
A contributor's “essential patent claims” are all patent claims owned or controlled by the contributor, whether already acquired or hereafter acquired, that would be infringed by some manner, permitted by this License, of making, using, or selling its contributor version, but do not include claims that would be infringed only as a consequence of further modification of the contributor version. For purposes of this definition, “control” includes the right to grant patent sublicenses in a manner consistent with the requirements of this License.
Each contributor grants you a non-exclusive, worldwide, royalty-free patent license under the contributor's essential patent claims, to make, use, sell, offer for sale, import and otherwise run, modify and propagate the contents of its contributor version.
In the following three paragraphs, a “patent license” is any express agreement or commitment, however denominated, not to enforce a patent (such as an express permission to practice a patent or covenant not to sue for patent infringement). To “grant” such a patent license to a party means to make such an agreement or commitment not to enforce a patent against the party.
If you convey a covered work, knowingly relying on a patent license, and the Corresponding Source of the work is not available for anyone to copy, free of charge and under the terms of this License, through a publicly available network server or other readily accessible means, then you must either (1) cause the Corresponding Source to be so available, or (2) arrange to deprive yourself of the benefit of the patent license for this particular work, or (3) arrange, in a manner consistent with the requirements of this License, to extend the patent license to downstream recipients. “Knowingly relying” means you have actual knowledge that, but for the patent license, your conveying the covered work in a country, or your recipient's use of the covered work in a country, would infringe one or more identifiable patents in that country that you have reason to believe are valid.
If, pursuant to or in connection with a single transaction or arrangement, you convey, or propagate by procuring conveyance of, a covered work, and grant a patent license to some of the parties receiving the covered work authorizing them to use, propagate, modify or convey a specific copy of the covered work, then the patent license you grant is automatically extended to all recipients of the covered work and works based on it.
A patent license is “discriminatory” if it does not include within the scope of its coverage, prohibits the exercise of, or is conditioned on the non-exercise of one or more of the rights that are specifically granted under this License. You may not convey a covered work if you are a party to an arrangement with a third party that is in the business of distributing software, under which you make payment to the third party based on the extent of your activity of conveying the work, and under which the third party grants, to any of the parties who would receive the covered work from you, a discriminatory patent license (a) in connection with copies of the covered work conveyed by you (or copies made from those copies), or (b) primarily for and in connection with specific products or compilations that contain the covered work, unless you entered into that arrangement, or that patent license was granted, prior to 28 March 2007.
Nothing in this License shall be construed as excluding or limiting any implied license or other defenses to infringement that may otherwise be available to you under applicable patent law.
12. No Surrender of Others' Freedom.
If conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot convey a covered work so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not convey it at all. For example, if you agree to terms that obligate you to collect a royalty for further conveying from those to whom you convey the Program, the only way you could satisfy both those terms and this License would be to refrain entirely from conveying the Program.
13. Use with the GNU Affero General Public License.
Notwithstanding any other provision of this License, you have permission to link or combine any covered work with a work licensed under version 3 of the GNU Affero General Public License into a single combined work, and to convey the resulting work. The terms of this License will continue to apply to the part which is the covered work, but the special requirements of the GNU Affero General Public License, section 13, concerning interaction through a network will apply to the combination as such.
14. Revised Versions of this License.
The Free Software Foundation may publish revised and/or new versions of the GNU General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.
Each version is given a distinguishing version number. If the Program specifies that a certain numbered version of the GNU General Public License “or any later version” applies to it, you have the option of following the terms and conditions either of that numbered version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of the GNU General Public License, you may choose any version ever published by the Free Software Foundation.
If the Program specifies that a proxy can decide which future versions of the GNU General Public License can be used, that proxy's public statement of acceptance of a version permanently authorizes you to choose that version for the Program.
Later license versions may give you additional or different permissions. However, no additional obligations are imposed on any author or copyright holder as a result of your choosing to follow a later version.
15. Disclaimer of Warranty.
THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM “AS IS” WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.
16. Limitation of Liability.
IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.
17. Interpretation of Sections 15 and 16.
If the disclaimer of warranty and limitation of liability provided above cannot be given local legal effect according to their terms, reviewing courts shall apply local law that most closely approximates an absolute waiver of all civil liability in connection with the Program, unless a warranty or assumption of liability accompanies a copy of the Program in return for a fee.
END OF TERMS AND CONDITIONS
How to Apply These Terms to Your New Programs
If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.
To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively state the exclusion of warranty; and each file should have at least the “copyright” line and a pointer to where the full notice is found.
<one line to give the program's name and a brief idea of what it does.>
Copyright (C) <year> <name of author>
This program is free software: you can redistribute it and/or modify it under the terms of the GNU General Public License as published by the Free Software Foundation, either version 3 of the License, or (at your option) any later version.
This program is distributed in the hope that it will be useful, but WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License for more details.
You should have received a copy of the GNU General Public License along with this program. If not, see <http://www.gnu.org/licenses/>.
Also add information on how to contact you by electronic and paper mail.
If the program does terminal interaction, make it output a short notice like this when it starts in an interactive mode:
<program> Copyright (C) <year> <name of author>
This program comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it under certain conditions; type `show c' for details.
The hypothetical commands `show w' and `show c' should show the appropriate parts of the General Public License. Of course, your program's commands might be different; for a GUI interface, you would use an “about box”.
You should also get your employer (if you work as a programmer) or school, if any, to sign a “copyright disclaimer” for the program, if necessary. For more information on this, and how to apply and follow the GNU GPL, see <http://www.gnu.org/licenses/>.
The GNU General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Lesser General Public License instead of this License. But first, please read <http://www.gnu.org/philosophy/why-not-lgpl.html>.
Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
gsed -i '2i All notable changes to this project will be documented in this file. This project adheres to [Semantic Versioning](http://semver.org/).' ChangeLog.md
$(SED) -i '2i All notable changes to this project will be documented in this file. This project adheres to [Semantic Versioning](http://semver.org/).' ChangeLog.md
ALIASES += liveexample{2}="@par Example\n \1 \n @includelineno \2.cpp \n Output (play with this example @htmlinclude \2.link):\n @verbinclude \2.output \n The example code above can be translated with @verbatim g++ -std=c++11 -Isrc doc/examples/\2.cpp -o \2 @endverbatim"
std::strings="The quick brown fox jumps over the lazy dog.";
// create a JSON string value
jsonj=s;
// serialize the JSON string
std::cout<<j<<'\n';
}
Some files were not shown because too many files have changed in this diff
Show More
Reference in New Issue
Block a user
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.