Google Cloud Storage C++ Client
1.42.0
A C++ Client Library for Google Cloud Storage
|
The Google Cloud Storage (GCS) C++ Client library offers types and functions access GCS from C++11 applications. It offers full access to the GCS API, including operations to list, read, write, and delete GCS objects and buckets. The library also provides functions to modify the IAM permissions on buckets, read and modify the metadata associated with objects and buckets, configure encryption keys, configure notifications via Cloud Pub/Sub, and change the access control list of object or buckets.
This library requires a C++11 compiler. It is supported (and tested) on multiple Linux distributions, as well as Windows and macOS. The README on GitHub provides detailed instructions to install the necessary dependencies, as well as how to compile the client library.
In order to use the Cloud Cloud Storage C++ client library from your own code, you'll need to configure your build system how to fetch and compile the Cloud C++ client library. The Cloud C++ client library natively supports the Bazel and CMake build systems. We've created a minimal, "Hello world", [quickstart repo][quickstart-link] that includes detailed instructions on how to compile the library for use in your application. You can fetch the source from GitHub as normal:
The following shows the code that you'll run in the google/cloud/storage/quickstart/
directory, which should give you a taste of the Cloud Storage C++ client library API.
GOOGLE_CLOUD_PROJECT=...
is used in examples and integration tests to configure the GCP project.CLOUD_STORAGE_ENABLE_TRACING=raw-client
enables logging for each "RPC" generated by the library. Unless you have configured you own logging backend, you should also set GOOGLE_CLOUD_CPP_ENABLE_CLOG
to produce any output on the program's console.CLOUD_STORAGE_ENABLE_TRACING=http
enables logging for the full http traffic generated by the library.CLOUD_STORAGE_ENABLE_TRACING=raw-client,http
enables all logging.CLOUD_STORAGE_EMULATOR_ENDPOINT=...
override the default endpoint used by the library, intended for testing only.CLOUD_STORAGE_TESTBENCH_ENDPOINT=...
DEPRECATED please use CLOUD_STORAGE_EMULATOR_ENDPOINT
instead.GOOGLE_CLOUD_CPP_ENABLE_CLOG=yes
turns on logging in the library, basically the library always "logs" but the logging infrastructure has no backend to actually print anything until the application sets a backend or they set this environment variable.GOOGLE_CLOUD_CPP_STORAGE_REST_CONFIG=...
configuration for the REST protocol, currently only the disable-xml
value has any effect. Sometimes the application developer may want to test using an emulator that does not support XML, while the library defaults to XML for some media operations.GOOGLE_CLOUD_CPP_STORAGE_GRPC_CONFIG=...
used with google::cloud::storage_experimental::DefaultGrpcClient()
to configure configure the gRPC protocol. Setting this to media
enables gRPC for just media operations (reading and writing data), while setting this to metadata
enables gRPC for all operations. Note that gRPC support is an early access program, contact Google Cloud support for details.Some of the GCS APIs need a project as a parameter. For such APIs the application can (a) call an overload that takes the project id as a parameter, (b) define the project explicitly when the Client
object is constructed, or (c) set the GOOGLE_CLOUD_PROJECT
environment variable to the desired project id. If you have set this environment variable the code can be even simpler:
This library never throws exceptions to signal error. In general, the library returns a StatusOr<T>
if an error is possible. Some functions return objects that already have an existing error handling mechanism, such as types derived from std::ostream
where the application can check the state flags to determine if there was an error. In these cases no StatusOr
wrapper is used.
Applications that do not use exceptions to signal errors should check if the StatusOr<T>
contains a value before using it. If the StatusOr<T>
does contain a value then the StatusOr<T>
can be used as a smart pointer to T
. That is, operator->()
and operator*()
work as you would expect. If the StatusOr<T>
does not contain a value then the error details are available using the .status()
member function (and trying to access the value produces undefined behavior).
Applications that use exceptions to signal errors can simply call .value()
on the StatusOr<T>
object. This will return a T
if the StatusOr<T>
object contains a value, and will otherwise throw an exception.
The library automatically retries requests that fail with transient errors, and follows the recommended practice to backoff between retries. Application developers can override the default retry and backoff policies:
The default policies are to continue retrying for up to 15 minutes, and to use truncated (at 5 minutes) exponential backoff, doubling the maximum backoff period between retries.
By default the library retries all operations, even those that are not idempotent. Application developers can override the idempotency policy to follow a more conservative approach:
The documentation for each member function in the Client class includes short snippets on how to call the function. The snippets for ReadObject(), WriteObject(), ListObjects(), and DeleteObject() are good places to continue learning about the library.