-
Notifications
You must be signed in to change notification settings - Fork 22
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
RSDK-9337: Introduce proto API bridge and insulate various geometry and math types from API #332
Changes from 18 commits
507ab57
9ff1696
5128069
cf35091
7a3376a
a440614
924b794
c438580
4fbd8bf
4c258ac
d520711
74b9582
c55948e
e2a5a3c
8479d34
27f147c
f69d797
42552ff
34bfdd2
8382629
141487f
7b7da5a
cf7f60b
9d876c5
ba66ea6
8128398
02ce15f
2ec0610
52590fa
0716a23
369e321
97841a5
fbe2ea9
670d2ef
96f2742
40cf73b
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -5,18 +5,22 @@ | |
#include <boost/qvm/vec.hpp> | ||
#include <boost/qvm/vec_traits.hpp> | ||
|
||
#include <viam/api/common/v1/common.pb.h> | ||
#include <viam/sdk/common/proto_convert.hpp> | ||
|
||
VIAM_SDK_API_FWD_NAMESPACE_BEGIN(common) | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I don't love the macro, but I see why you did it. However, we don't currently have the mechanisms in place to ensure that the macro is no longer defined after consuming our headers. Would a There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. I'm open to getting rid of the macro, it's more of a convenience than anything, and also makes it easy to grep for where forward declarations are happening. Putting everything in a single
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. OK, those are good enough arguments against the fwd header that I think we can eliminate that. How about a compromise? We keep the macro for now, but file a ticket that when the SDK goes to C++17, the macro gets removed, because then it becomes a lot less painful to write:
So, a ticket for that labeled as C++17? That or just do it explicitly now with C++14 namespaces. I've got a pretty strong aversion to macros in public headers if at all avoidable. Also, it is probably worth filing a ticket now, if one doesn't exist, to introduce prelude/postlude headers to do macro push/pops so that the tooling for avoiding macro leakage is in place. It will be required in order to support adding ABI visibility annotations and/or calling convention annotations should we ever want to support windows. |
||
|
||
class Vector3; | ||
|
||
VIAM_SDK_API_FWD_NAMESPACE_END | ||
|
||
namespace viam { | ||
namespace sdk { | ||
|
||
// In the future, we may wish to inline this whole class | ||
// for performance reasons. | ||
|
||
class Vector3 { | ||
public: | ||
struct Vector3 { | ||
using scalar_type = double; | ||
Vector3(scalar_type x, scalar_type y, scalar_type z); | ||
Vector3(); | ||
|
||
scalar_type x() const; | ||
scalar_type y() const; | ||
|
@@ -28,15 +32,22 @@ class Vector3 { | |
/// Set the z value of the vector (can be chained) | ||
Vector3& set_z(scalar_type z); | ||
|
||
const std::array<scalar_type, 3>& data() const; | ||
std::array<scalar_type, 3>& data(); | ||
viam::common::v1::Vector3 to_proto() const; | ||
static Vector3 from_proto(const viam::common::v1::Vector3& vec); | ||
std::array<scalar_type, 3> data; | ||
}; | ||
|
||
namespace proto_convert_details { | ||
|
||
private: | ||
std::array<scalar_type, 3> data_; | ||
template <> | ||
struct to_proto<Vector3> { | ||
void operator()(const Vector3&, common::v1::Vector3*) const; | ||
}; | ||
|
||
template <> | ||
struct from_proto<common::v1::Vector3> { | ||
Vector3 operator()(const common::v1::Vector3*) const; | ||
}; | ||
|
||
} // namespace proto_convert_details | ||
} // namespace sdk | ||
} // namespace viam | ||
|
||
|
@@ -51,20 +62,20 @@ struct vec_traits<viam::sdk::Vector3> { | |
|
||
template <int I> | ||
static inline scalar_type& write_element(vec_type& v) { | ||
return v.data()[I]; | ||
return v.data[I]; | ||
} | ||
|
||
template <int I> | ||
static inline scalar_type read_element(vec_type const& v) { | ||
return v.data()[I]; | ||
return v.data[I]; | ||
} | ||
|
||
static inline scalar_type& write_element_idx(int i, vec_type& v) { | ||
return v.data()[i]; | ||
return v.data[i]; | ||
} | ||
|
||
static inline scalar_type read_element_idx(int i, vec_type const& v) { | ||
return v.data()[i]; | ||
return v.data[i]; | ||
} | ||
}; | ||
|
||
|
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.
⬆️ - How close do the changes in this review get things w.r.t. removing this:
Or at least reducing it to
PRIVATE
?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.
Ooh interesting, I think that will be doable once the epic to get all API imports out of public headers is complete!