c5ddbbc430
This would unblock #2010. Closes #2032. Closes #1880. I know this comes out of the blue, but it seems to me the right change to do. This is a proposal, let me know what you think. First, I started with the fact that we need to make `CancelWhen()` public. Then, I realized that I don't like the `CancelWhen()` naming. `CancelAt()` is better? But `CancelAt()` sounds like an order to do something, not as getter. So, it should be named `Get...`. `GetCancelWhen()`? `GetCancelAt()`? Sounds strage. `GetDeadline()` - not bad, bit it is not that clear, what the deadline is. And I looked at the `WithDeadline()` method. And in comment, the first line is `@brief Create a context with expiration.`. "Expiration" sounds better explanation for the essense of the "deadline". So, I went with `GetExpiration()`. I think "Expiration" is also a better name, because should we want to add the method called "bool IsExpired()", it comes naturally using the existing terminology, sounds better than "`IsPastDeadline()`". Next thing - if we have "`GetExpiration()`", it is strange to have a method called `Get()`. So, we have `WithExpiration()` and `WithValue()`. So, it sounds like the getter should be called `GetValue()`. I did that rename as well. Then, I looked at "`With...`" method naming. It is a factory method. If for getters we have `Get`, then for factory methods we should have `Create`. So, I renamed `WithExpiration()` and `WithValue()` to `CreateWithExpiration()` and `CreateWithValue()`. Then I looked at `Context::time_point` typedef. First, in general, if we can avoid public typedefs, it is better, because we don't need to document them and worry if we broke client code when we change them. Second, it is strange that we use `Azure::DateTime` everywhere, but not in context. So, I replaced it with `Azure::DateTime`. It is good because it allows us to drop to/from epoch conversions (#1880), and really all that extra dance we do to cast to representation and back to datetime is the ways to stay within legal type casting limits of compiler type declaration, while in reality there isn't much that is happening in the code: `DateTime` is essentially an `int64`, and with all these conversions to epoch time, then to representation and back, compiler does not generate real code, it still operates with that only `int64`. Why we cast to `DateTime::rep` and back at all? Context stores it as `atomic`, and I am not questioning that. You can't get `std::atomic<DateTime>` today explicitly, so we "extract" representation (`int64`) and store it as `std::atomic<DateTime::rep>`, which is the same thing as `std::atomic_int64`. -- Update: -- 1. "Expiration" => "Deadline" (Jeffrey's request) 2. Added `Context::HasExpiration()` (response to Jinming) // plus, we do have `HasValue()` so why not have `HasDeadline()`. 3. `WithDeadline()`, `WithValue` => Two overloads of `CreateChildContext()` (my own initiative). -- Update 2: -- `CreateChildContext()` => `WithDeadline()`, `WithValue` -- Update 3: -- Removed `HasDeadline()` |
||
|---|---|---|
| .. | ||
| azure-storage-blobs | ||
| azure-storage-common | ||
| azure-storage-files-datalake | ||
| azure-storage-files-shares | ||
| ci.yml | ||
| CMakeLists.txt | ||
| README.md | ||
| test-resources-post.ps1 | ||
| test-resources.json | ||
Azure Storage Client Library for C++
The Azure Storage Client Library for C++ allows you to build applications against Microsoft Azure Storage. For an overview of Azure Storage, see Introduction to Microsoft Azure Storage.
Features
- Blobs
- Create/Delete/List Containers
- Create/Read/Update/Delete/List Blobs
- DataLake Gen 2
- Create/Delete File Systems
- Create/Delete Directories
- Create/Read/Append/Flush/Delete Files
- File Shares
- Create/Delete Shares
- Create/Delete Directories
- Create/Read/Delete Files
Getting started
For the best development experience, we recommend that developers use the CMake projects in Visual Studio to view and build the source code together with its dependencies.
Requirements
To call Azure services, you must first have an Azure subscription. Sign up for a free trial or use your MSDN subscriber benefits.
Need Help?
Be sure to check out the Azure Storage Forum on MSDN if you need help, or use StackOverflow.
Collaborate & Contribute
We gladly accept community contributions.
- Issues: Report bugs on the Issues page in GitHub. Ideally, please add an "[Storage]" prefix to the title for easier categorizing.
- Forums: Communicate with the Azure Storage development team on the Azure Storage Forum or StackOverflow.
- Source Code Contributions: Please follow the contribution guidelines for Azure open source for instructions about contributing to the source project.
For general suggestions about Azure, use our Azure feedback forum.
Download & Install
Install Dependencies
Windows
On Windows, dependencies are managed by vcpkg. You can reference the Quick Start to quickly set yourself up. After Vcpkg is initialized and bootstrapped, you can install the dependencies:
vcpkg.exe install libxml2:x64-windows-static curl:x64-windows-static
Unix Platforms
You can use the package manager on different Unix platforms to install the dependencies. The dependencies to be installed are:
- CMake 3.13.0 or higher.
- libxml2.
- OpenSSL.
- libcurl.
Build from Source
First, download the repository to your local folder:
git clone https://github.com/Azure/azure-sdk-for-cpp.git
Windows
Use CMake to generate the solution file
In a new folder you created under the root directory:
cmake .. -A x64 -DCMAKE_TOOLCHAIN_FILE=<YOUR_VCPKG_INSTALL_DIR>/scripts/buildsystems/vcpkg.cmake
cmake --build .
The built library will be in .\sdk\<ProjectDir>\<Configuration>\ respectively for Azure Core and Azure Storage. e.g. azure_core.lib will be in .\sdk\core\azure-core\Debug for debug configuration.
Use Visual Studio's Open by folder feature
Open the root folder of the library with Visual Studio's Open folder feature.
If Vcpkg is not globally integrated, then you need to open CMakeSettings.json and change the Make toolchain file to be <YOUR_VCPKG_INSTALL_DIR>/scripts/buildsystems/vcpkg.cmake and save.
Then you can build Azure Storage libraries by selecting the target in Visual Studio, or simply build all.
The libraries will be in <ProjectRoot>\out\build\<Configuration>\sdk\<LibraryName> respectively.
Unix Platforms
You can run the following command in a new folder created under the downloaded code's root folder to build the code.
cmake .. -DCMAKE_BUILD_TYPE=Debug
cmake --build .
Then you can consume the built library with the header files. make/ninja install is work in progress.
Via NuGet
WIP TODO when ready.
Via Vcpkg
WIP TODO when ready.
Dependencies
- Azure Core SDK
- libxml2
Code Samples
To get started with the coding, please visit the following code samples: