-
Notifications
You must be signed in to change notification settings - Fork 67
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
cbor binding #627
cbor binding #627
Conversation
include/aws/crt/cbor/Cbor.h
Outdated
IndefMapStart = AWS_CBOR_TYPE_INDEF_MAP_START, | ||
}; | ||
|
||
class AWS_CRT_CPP_API CborEncoder |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
add final if destructor
is not virtual
*****************************************************/ | ||
CborEncoder::CborEncoder(Crt::Allocator *allocator) noexcept | ||
{ | ||
m_encoder = aws_cbor_encoder_new(allocator); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there's no possible way that aws_cbor_encoder_new() or aws_cbor_decoder_new() could ever return NULL in the future, right? right?
if so, we won't want to use normal C++ constructors, because they can't fail without the use of exceptions, which we turn off
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don't think we will error let the new function fail for the encoder and decoder, besides of allocation failure
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
fix & ship
Issue #, if available:
Description of changes:
Bare minimal binding for cbor
follow up:
std::chrono::system_clock::time_point
?We will need those follow up for sure, but debatable about where they should live, maybe in C++ SDK? Or maybe in crt-ccp, we should hold for the follow-ups until C++ SDK picks up the integration job
Won't merge until the C code merge to main and the follow up has been addressedBy submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.