AWS SDK for C++

To minimize temporary allocations and memory overhead when making service calls, the SDK provides several non-STL overloads for Init and Set functions. Instead of constructing std::string or std::vector objects, use these variants:

• Strings: Use overloads that take const char* or (optionally) a const char* with an explicit length.
• Containers (Map/Vector): Use add variants that take a single entry instead of passing a whole container.
• Binary Data: Use overloads that take a pointer and a length value.

The AWS SDK for C++ does not use exceptions for service errors. Instead, every service client method returns an outcome object (e.g., CreateTableOutcome). You should check the success of the operation using .IsSuccess() and, if it fails, inspect the error using .GetError().

CreateTableOutcome createTableOutcome = dynamoDbClient->CreateTable(createTableRequest);
if (createTableOutcome.IsSuccess())
{
   // Handle success
}
else if(createTableOutcome.GetError().GetErrorType() == DynamoDBErrors::RESOURCE_IN_USE)
{
   // Handle specific error type
}

To ensure stability with custom memory managers, follow these memory management rules:

• Use RAII: Rely on Resource Acquisition Is Initialization to manage object lifetimes.
• Avoid non-trivial statics: Using non-trivial static objects can cause custom memory managers to crash unpredictably.
• Controlled allocation: Aws::New and Aws::Delete should only be used within constructors and destructors.
• Rule of 5: Always implement or explicitly delete the copy/move constructors and assignment operators to manage resources correctly.
• Use nullptr: Always use nullptr instead of the NULL macro.

The SDK provides default behaviors for retries and asynchronous execution, but these can be customized by implementing specific interfaces:

• Retry Strategy: The default is exponential backoff. To change this, implement a subclass of RetryStrategy and assign it to the retryStrategy field.
• Executor: By default, the SDK creates and detaches a new thread for each async call. To use a different model, such as a thread pool, implement a subclass of Executor and assign it to the executor field.

To prevent namespace pollution and naming collisions:

• Never put a using namespace statement in a header file unless it is scoped within a class.
• It is acceptable to use using namespace statements within .cpp files.

The SDK uses type aliasing to manage how STL containers (like Vector, String, Map) behave based on the USE_AWS_MEMORY_MANAGEMENT compile-time constant. This ensures that the SDK's internal use of STL is compatible with your custom memory manager.

• If USE_AWS_MEMORY_MANAGEMENT is ON: Aws::* types (e.g., Aws::Vector<T>) resolve to STL types using a custom Aws::Allocator<T> that connects to the AWS memory system.
• If USE_AWS_MEMORY_MANAGEMENT is OFF: Aws::* types resolve to standard std::* types using default allocators.

This mechanism allows the SDK to use custom allocators internally while maintaining a consistent interface.

When building for Android, use the following CMake variables to configure the environment:

• NDK_DIR: Path to the Android NDK (checks ANDROID_NDK env var if not set).
• ANDROID_ABI: Target ABI. Supported: arm64, armeabi-v7a (default), x86_64, x86, mips64, mips.
• ANDROID_STL: C++ standard library. Options: libc++_shared (default), libc++_static, gnustl_shared, gnustl_static. Note: libc++ is recommended; gnustl has performance issues and is deprecated in NDK 18+.
• ANDROID_NATIVE_API_LEVEL: Target API level. If using libc++, this must be at least 21.
• ANDROID_TOOLCHAIN: Compiler to use. Default is clang (recommended).
• ANDROID_BUILD_CURL, ANDROID_BUILD_OPENSSL, ANDROID_BUILD_ZLIB: Boolean flags to include these dependencies in the Android build (all default to ON).