no dependencies and stl free confusion

[graphitemaster]

This looked like a very interesting library to use due to my environment lacking a C++ standard library implementation but a C++ compiler. However upon further inspection it appears that the claim is incorrect as this library includes hundreds of the C++ standard library headers like <limits> and <new> and uses stuff like std::memcpy and std::strlen over the C functions provided by the C standard library headers (which are available). I don't think you can make this claim. It's true it avoids the use of the container aspects of the C++ library like std::string, std::vector and std::map. If the library does go through the effort to avoid all that in favor of the "C++ wrapped C functions" it wouldn't be difficult to just use the C headers. Am I mistaken here, I literally do not have a single C++ standard library header with my tool chain. Except maybe <type_traits> and a few of the "free standing" compiler provided ones.

[pah]

You can add your own C++-style headers for the C functions by using something like:

// <cstring>
#include <string.h>
namespace std {
  using ::memcpy;
  // ...
} // namespace std

<new> is needed for placement new and pretty much required for any C++ compiler (even without dynamic allocation support). You can implement the function yourself via

  inline void * operator new( size_t, void* ptr ) { return ptr; }

<limits> could potentially be avoided, but std::numeric_limits<double>::infinity() et.al. is the most portable way to specify these numeric properties. Should also be straightforward to implement in a standalone environment.

<utility> is needed in C++11 mode for std::move. I can't believe that there is a C++11 compiler without a std::move.

Not sure, how you count "hundreds of headers", though.

[graphitemaster]

It would be trivial for this project to define these things itself in a namespace and use them (maybe even add additional tag arguments to avoid conflicts if the namespace isn't enough), for stuff like std::numeric_limits<double>::infinity() there's literally an INFINITY macro in <math.h> which is the same thing.

[pah]

It would be trivial for this project to define these things itself in a namespace and use them

If it's trivial and you do have a need/use case/environment to test, why don't you prepare it and submit a pull-request? Ideally as a separate header (e.g. rapidjson/platform.h) and a mechanism for user overrides:

  #ifndef RAPIDJSON_PLATFORM_H
  #  define RAPIDJSON_PLATFORM_H <rapidjson/platform.h>
  #endif // RAPIDJSON_PLATFORM_H
  #include RAPIDJSON_PLATFORM_H

@miloyip is very open to integrate patches and that's how open-source works after all.

[adam4813]

It states in the README "It even does not depend on STL." It isn't saying that it doesn't use the standard c++ runtime library, just not the template (container) library. They are different things (though 1 depends on the other) and as such the assertion is valid.

TL:DR STL == standard template library not c++ runtime library.