AWS SDK for C++
0.12.9
AWS SDK for C++
|
For 0.12+ all applications must call the Aws::InitAPI() function before making any other SDK calls, and the Aws::ShutdownAPI function when finished using the SDK. More information can be found here: https://aws.amazon.com/blogs/developer/aws-sdk-for-c-simplified-configuration-and-initialization/
The AWS SDK for C++ provides a modern C++ (version C++ 11 or later) interface for Amazon Web Services (AWS). It is meant to be performant and fully functioning with low- and high-level SDKs, while minimizing dependencies and providing platform portability (Windows, OSX, Linux, and mobile).
AWS SDK for C++ is in developer preview while we gather one last round of feedback from users and the open source community reviews the APIs. We invite our customers to follow along with our progress and join the development efforts by submitting pull requests and sending us feedback and ideas via GitHub Issues.
The following video explains many of the core features and also high-level SDKs
Use the information below to build the entire source tree for your platform, run unit tests, and build integration tests.
To create an out-of-source build:
You can use the following variations to create your build directory:
make
msbuild ALL_BUILD.vcxproj
To create a release build, do one of the following:
You may also find the following link helpful for including the build in your project:
https://aws.amazon.com/blogs/developer/using-cmake-exports-with-the-aws-sdk-for-c/
To build for Android, add -DTARGET_ARCH=ANDROID to your cmake command line. We've included a cmake toolchain file that should cover what's needed, assuming you have the appropriate environment variables (ANDROID_NDK) set.
Building for Android on Windows requires some additional setup. In particular, you will need to run cmake from a Visual Studio developer command prompt (2013 or higher). Additionally, you will need 'git' and 'patch' in your path. If you have git installed on a Windows system, then patch is likely found in a sibling directory (.../Git/usr/bin/). Once you've verified these requirements, your cmake command line will change slightly to use nmake:
cmake -G "NMake Makefiles" -DTARGET_ARCH=ANDROID <other options>=""> ..
Nmake builds targets in a serial fashion. To make things quicker, we recommend installing JOM as an alternative to nmake and then changing the cmake invocation to:
cmake -G "NMake Makefiles JOM" -DTARGET_ARCH=ANDROID <other options>=""> ..
Allows you to only build the clients you want to use. This will resolve low level client dependencies if you set this to a high-level sdk such as aws-cpp-sdk-transfer. This will also build integration and unit tests related to the projects you select if they exist. aws-cpp-sdk-core always builds regardless of the value of this argument. This is a list argument. Example: -DBUILD_ONLY="aws-cpp-sdk-s3;aws-cpp-sdk-dynamodb;aws-cpp-sdk-cognito-identity"
Allows you to build any arbitrary clients based on the api definition. Simply place your definition in the code-generation/api-definitions folder. Then pass this arg to cmake. The cmake configure step will generate your client and include it as a subdirectory in your build. This is particularly useful if you want to generate a C++ client for using one of your API Gateway services. To use this feature you need to have python 2.7, java, jdk1.8, and maven installed and in your executable path. Example: -DADD_CUSTOM_CLIENTS="serviceName=myCustomService; version=2015-12-21;serviceName=someOtherService; version=2015-08-15"
This argument will wipe out all generated code and generate the client directories from the code-generation/api-definitions folder. To use this argument, you need to have python 2.7, java, jdk1.8, and maven installed in your executable path. Example: -DREGENERATE_CLIENTS=1
To use a custom memory manager, set the value to 1. You can install a custom allocator, and all STL types will use the custom allocation interface. If the value is set to 0, you still might want to use the STL template types to help with DLL safety on Windows.
If static linking is enabled, custom memory management defaults to off. If dynamic linking is enabled, custom memory management defaults to on and avoids cross-DLL allocation and deallocation.
Note: To prevent linker mismatch errors, you must use the same value (0 or 1) throughout your build system.
To use static linking, set the value to 1. By default the build creates shared libraries for each platform. If you dynamically link to the SDK you will need to define the USE_IMPORT_EXPORT symbol for all build targets using the SDK.
To cross compile or build for a mobile platform, you must specify the target platform. By default the build detects the host operating system and builds for that operating system. Options: WINDOWS | LINUX | APPLE | ANDROID
Use this variable to generate build artifacts, such as Visual Studio solutions and Xcode projects.
Windows example: -G "Visual Studio 12 Win64"
For more information, see the CMake documentation for your platform.
Several directories are appended with *integration-tests. After building your project, you can run these executables to ensure everything works properly.
To compile in Linux, you must have the header files for libcurl and libopenssl. The packages are typically available in your package manager.
Libcurl example: sudo apt-get install libcurl-dev
After they are constructed, individual service clients are very similar to other SDKs, such as Java and .NET. This section explains how core works, how to use each feature, and how to construct an individual client.
The aws-cpp-sdk-core is the heart of the system and does the heavy lifting. You can write a client to connect to any AWS service using just the core, and the individual service clients are available to help make the process a little easier.
If you dynamically link to the SDK you will need to define the USE_IMPORT_EXPORT symbol for all build targets using the SDK. If you wish to install your own memory manager to handle allocations made by the SDK, you will need to pass the CUSTOM_MEMORY_MANAGEMENT cmake parameter (-DCUSTOM_MEMORY_MANAGEMENT) as well as define AWS_CUSTOM_MEMORY_MANAGEMENT in all build targets dependent on the SDK.
Note, if you use our export file, this will be handled automatically for you. We recommend you use our export file to handle this for you: https://aws.amazon.com/blogs/developer/using-cmake-exports-with-the-aws-sdk-for-c/
We avoid global and static state where ever possible. However, on some platforms, dependencies need to be globally initialized. Also, we have a few global options such as logging, memory management, http factories, and crypto factories. As a result, before using the SDK you MUST call our global initialization function. When you are finished using the SDK you should call our cleanup function.
All code using the AWS SDK and C++ should have at least the following:
Due to the way memory managers work, many of the configuration options take closures instead of pointers directly in order to ensure that the memory manager is installed prior to any memory allocations occuring.
Here are a few recipes:
Just use defaults:
Turn logging on using the default logger:
Install custom memory manager:
Override default http client factory:
The AWS SDK for C++ provides a way to control memory allocation and deallocation in a library.
Custom memory management is available only if you use a version of the library built using the compile-time constant AWS_CUSTOM_MEMORY_MANAGEMENT defined.
If you use a version of the library built without the compile-time constant, the global memory system functions such as InitializeAWSMemorySystem will not work and the global new and delete functions will be used instead.
For more information about the compile-time constant, see the STL and AWS Strings and Vectors section in this Readme.
To allocate or deallocate memory:
In the following example, the type signature for AllocateMemory can be changed as needed:
In Main:
When initialized with a memory manager, the AWS SDK for C++ defers all allocation and deallocation to the memory manager. If a memory manager does not exist, the SDK uses global new and delete.
If you use custom STL allocators, you must alter the type signatures for all STL objects to match the allocation policy. Because STL is used prominently in the SDK implementation and interface, a single approach in the SDK would inhibit direct passing of default STL objects into the SDK or control of STL allocation. Alternately, a hybrid approach – using custom allocators internally and allowing standard and custom STL objects on the interface – could potentially cause more difficulty when investigating memory issues.
The solution is to use the memory system’s compile-time constant AWS_CUSTOM_MEMORY_MANAGEMENT to control which STL types the SDK will use.
If the compile-time constant is enabled (on), the types resolve to STL types with a custom allocator connected to the AWS memory system.
If the compile-time constant is disabled (off), all Aws::* types resolve to the corresponding default std::* type.
Example code from the AWSAllocator.h file in the SDK:
In the example code, the AwsAllocator can be either a custom allocator or a default allocator, depending on the compile-time constant.
Example code from the AWSVector.h file in the SDK: template< typename T > using Vector = std::vector< T, Aws::Allocator< T > >;
In the example code, we define the Aws::* types.
If the compile-time constant is enabled (on), the type maps to a vector using custom memory allocation and the AWS memory system.
If the compile-time constant is disabled (off), the type maps to a regular std::vector with default type parameters.
Type aliasing is used for all std:: types in the SDK that perform memory allocation, such as containers, string stream, and string buf. The AWS SDK for C++ uses these types.
You can control memory allocation in the SDK; however, STL types still dominate the public interface through string parameters to the model object initialize and set methods. If you choose not to use STL and use strings and containers instead, you must create a lot of temporaries whenever you want to make a service call.
To remove most of the temporaries and allocation when service calls are made using non-STL, we have implemented the following:
Follow these rules in the SDK code:
Aws::Map<Aws::String, Aws::String> m_kvPairs;
The AWS SDK for C++ includes logging support that you can configure. When initializing the logging system, you can control the filter level and the logging target (file with a name that has a configurable prefix or a stream). The log file generated by the prefix option rolls over once per hour to allow for archiving or deleting log files.
You can provide your own logger. However, it is incredibly simple to use the default logger we've already provided:
In your main function:
You can use the client configuration to control most functionality in the AWS SDK for C++.
ClientConfiguration declaration:
The user agent is built in the constructor and pulls information from your operating system. Do not alter the user agent.
The default value for scheme is HTTPS. You can set this value to HTTP if the information you are passing is not sensitive and the service to which you want to connect supports an HTTP endpoint. AWS Auth protects you from tampering.
The region specifies where you want the client to communicate. Examples include us-east-1 or us-west-1. You must ensure the service you want to use has an endpoint in the region you configure.
The authentication region allows you to specify an arbitrary region to use for signing. If you don't set this we fall back to Region. If you do set this, you are also responsible for setting endpoint override to connect to the endpoint that cooresponds with your custom region.
The default value for the maximum number of allowed connections to a single server for your HTTP communications is 25. You can set this value as high as you can support the bandwidth. We recommend a value around 25.
This value determines the length of time, in milliseconds, to wait before timing out a request. You can increase this value if you need to transfer large files, such as in Amazon S3 or CloudFront.
The retry strategy defaults to exponential backoff. You can override this default by implementing a subclass of RetryStrategy and passing an instance.
Do not alter the endpoint.
These settings allow you to configure a proxy for all communication with AWS. Examples of when this functionality might be useful include debugging in conjunction with the Burp suite, or using a proxy to connect to the internet.
The default behavior for the executor is to create and detach a thread for each async call. You can change this behavior by implementing a subclass of Executor and passing an instance. We now provide a thread pooled executor as an option. For more information see this blog post: https://aws.amazon.com/blogs/developer/using-a-thread-pool-with-the-aws-sdk-for-c/
If necessary, you can disable SSL certificate verification by setting the verify SSL value to false.
You can tell the http client where to find your certificate trust store ( e.g. a directory prepared with OpenSSL c_rehash utility). This should not be necessary unless you are doing some weird symlink farm stuff for your environment. This has no effect on Windows or OSX.
The write and read rate limiters are used to throttle the bandwidth used by the transport layer. The default for these limiters is open. You can use the default implementation with your desired rates, or you can create your own instance by implementing a subclass of RateLimiterInterface.
You can use the AWSCredentialProvider interface to provide login credentials to AWS Auth. Implement this interface to provide your own method of credentials deployment. We also provide default credential providers.
The default credential provider chain does the following:
The simplest way to communicate with AWS is to ensure we can find your credentials in one of these locations.
We also support two other methods for providing credentials:
You can use the default constructor, or you can use the system interfaces discussed above to construct a service client.
As an example, the following code creates an Amazon DynamoDB client using a specialized client configuration, default credentials provider chain, and default HTTP client factory:
You can also do the following to manually pass credentials: auto client = Aws::MakeShared<DynamoDBClient>(ALLOCATION_TAG, AWSCredentials("access_key_id", "secret_key"), config);
Or you can do the following to use a custom credentials provider: auto client = Aws::MakeShared<DynamoDBClient>(ALLOCATION_TAG, Aws::MakeShared<CognitoCachingAnonymousCredentialsProvider>(ALLOCATION_TAG, "identityPoolId", "accountId"), config);
Now you can use your Amazon DynamoDB client.
We did not use exceptions; however, you can use exceptions in your code. Every service client returns an outcome object that includes the result and an error code.
Example of handling error conditions:
This section includes the following topics:
The default HTTP client for Windows is WinHTTP. The default HTTP client for all other platforms is Curl. If needed, you can create a custom HttpClientFactory, add it to the SDKOptions object which you pass to Aws::InitAPI().
The provided utilities include HTTP stack, string utils, hashing utils, JSON parser, and XML parser.
/aws/core/http/
The HTTP client provides connection pooling, is thread safe, and can be reused for your purposes. See the Client Configuration section above.
/aws/core/utils/StringUtils.h
This header file provides core string functions, such as trim, lowercase, and numeric conversions.
/aws/core/utils/HashingUtils.h
This header file provides hashing functions, such as SHA256, MD5, Base64, and SHA256_HMAC.
/aws/core/utils/crypto/Cipher.h /aws/core/utils/crypto/Factories.h
This header file provides access to secure random number generators, AES symmetric ciphers in CBC, CTR, and GCM modes, and the underlying Hash implementations that are used in HashingUtils.
/aws/core/utils/json/JsonSerializer.h
This header file provides a fully functioning yet lightweight JSON parser (thin wrapper around JsonCpp).
/aws/core/utils/xml/XmlSerializer.h
This header file provides a lightweight XML parser (thin wrapper around tinyxml2). RAII pattern has been added to the interface.
By default all responses use an input stream backed by a stringbuf. If needed, you can override the default behavior. For example, if you are using Amazon S3 GetObject and do not want to load the entire file into memory, you can use IOStreamFactory in AmazonWebServiceRequest to pass a lambda to create a file stream.
Example file stream request:
*Please Do!
#pragma once
for include guards.