iceoryx_binding_c package from iceoryx repoiceoryx_binding_c iceoryx_hoofs iceoryx_integrationtest iceoryx_posh iceoryx_introspection |
|
Package Summary
Tags | No category tags. |
Version | 2.0.6 |
License | Apache 2.0 |
Build type | CMAKE |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/eclipse-iceoryx/iceoryx.git |
VCS Type | git |
VCS Version | release_2.0 |
Last Updated | 2024-06-11 |
Dev Status | DEVELOPED |
CI status | No Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Eclipse Foundation, Inc.
Authors
Iceoryx C Language binding
If you are looking for an example take a look at the icedelivery on c example.
C API structure
The C API is supposed to be as close to the C++ API as possible. This means, developers who are already familiar with the C++ API do not have to learn iceoryx from scratch in order to use the C API. There are of course differences due to C being a different language than C++.
Therefore, we have the following coding conventions exclusively in the C API.
- C functions are using an abbreviation of the class name. For instance
Subscriber
would usesub
and the methods are named likeiox_sub_method_name
where thecamelCase
is converted intosnake_case
. - A typedef for the handle is created with the abbreviation as name, a
iox
prefix and a_t
suffix, likeiox_sub_t
- If the constructor allocates an element it has the suffix
_create
and is called for instanceiox_node_create
. Analog to the constructor the destructor has the suffix_destroy
and is named likeiox_node_destroy
. - Pre iceoryx v2, constructor requiring preallocated memory had the suffix
_init
and required a pointer to a storage which was usually placed on the stack. Due to non-trivial issues with different sizes for different platforms and architectures the storage is ignored and the object is allocated on the heap. This might be reverted in a future release depending on a proper solution for the problem. The API remains the same, so a_storage_t
object likeiox_sub_storage_t
must be created and a pointer to this object must be passed to_init
, e.g.iox_sub_init
. This function returns a handle which does not point to the storage. Using the address of the storage in_deinit
is undefined and most likely will result in a segmentation fault. The usage is according the following example
iox_sub_storage_t subStorage;
iox_sub_t subscriber = iox_sub_init(&subStorage, "foo", "bar", "baz", nullptr);
// do something with subscriber
iox_sub_deinit(subscriber);
- The first parameter is always the handle to the corresponding object.
-
If possible, the arguments should stay the same in the C API.
- Enum values are named like
EnumName_EnumValue
- Enum names follow the rule
namespace_EnumName
Here is an example:
namespace iox {
enum class Color {
RED,
GREEN,
BLUE
};
class Channel {
public:
Channel(const std::string &name);
cxx::optional<void*> receive();
bool send(void * data);
void allHailHypnotoad();
};
class MyOtherClass {
public:
MyOtherClass(const int a);
void youSpinMeRoundLikeARecord();
};
}
The corresponding C binding would then look like:
enum iox_Color {
Color_RED,
Color_GREEN,
Color_BLUE,
};
typedef struct Channel * sub_t;
sub_t iox_chan_create(const char * name);
void iox_chan_destroy(sub_t const self);
bool iox_chan_receive(sub_t const self, void * const data);
bool iox_chan_send(sub_t const self, void * const data);
void iox_chan_all_hail_hypnotoad(sub_t const self);
struct iox_other_class_storage_t_ {
uint64_t do_not_touch_me[8]; // lets assume 8 * 8 is the size of MyOtherClass
};
typedef iox_other_class_storage_t_ iox_other_class_storage_t;
typedef struct MyOtherClass * iox_other_class_t;
iox_other_class_t iox_other_class_init(iox_other_class_storage_t * self,const int a);
void iox_other_class_deinit(iox_other_class_t * self);
void iox_other_class_you_spin_me_round_like_a_record(iox_other_class_t * self);
Wiki Tutorials
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged iceoryx_binding_c at Robotics Stack Exchange
iceoryx_binding_c package from iceoryx repoiceoryx_binding_c iceoryx_hoofs iceoryx_integrationtest iceoryx_posh iceoryx_introspection |
|
Package Summary
Tags | No category tags. |
Version | 2.0.6 |
License | Apache 2.0 |
Build type | CMAKE |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/eclipse-iceoryx/iceoryx.git |
VCS Type | git |
VCS Version | release_2.0 |
Last Updated | 2024-06-11 |
Dev Status | DEVELOPED |
CI status | No Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Eclipse Foundation, Inc.
Authors
Iceoryx C Language binding
If you are looking for an example take a look at the icedelivery on c example.
C API structure
The C API is supposed to be as close to the C++ API as possible. This means, developers who are already familiar with the C++ API do not have to learn iceoryx from scratch in order to use the C API. There are of course differences due to C being a different language than C++.
Therefore, we have the following coding conventions exclusively in the C API.
- C functions are using an abbreviation of the class name. For instance
Subscriber
would usesub
and the methods are named likeiox_sub_method_name
where thecamelCase
is converted intosnake_case
. - A typedef for the handle is created with the abbreviation as name, a
iox
prefix and a_t
suffix, likeiox_sub_t
- If the constructor allocates an element it has the suffix
_create
and is called for instanceiox_node_create
. Analog to the constructor the destructor has the suffix_destroy
and is named likeiox_node_destroy
. - Pre iceoryx v2, constructor requiring preallocated memory had the suffix
_init
and required a pointer to a storage which was usually placed on the stack. Due to non-trivial issues with different sizes for different platforms and architectures the storage is ignored and the object is allocated on the heap. This might be reverted in a future release depending on a proper solution for the problem. The API remains the same, so a_storage_t
object likeiox_sub_storage_t
must be created and a pointer to this object must be passed to_init
, e.g.iox_sub_init
. This function returns a handle which does not point to the storage. Using the address of the storage in_deinit
is undefined and most likely will result in a segmentation fault. The usage is according the following example
iox_sub_storage_t subStorage;
iox_sub_t subscriber = iox_sub_init(&subStorage, "foo", "bar", "baz", nullptr);
// do something with subscriber
iox_sub_deinit(subscriber);
- The first parameter is always the handle to the corresponding object.
-
If possible, the arguments should stay the same in the C API.
- Enum values are named like
EnumName_EnumValue
- Enum names follow the rule
namespace_EnumName
Here is an example:
namespace iox {
enum class Color {
RED,
GREEN,
BLUE
};
class Channel {
public:
Channel(const std::string &name);
cxx::optional<void*> receive();
bool send(void * data);
void allHailHypnotoad();
};
class MyOtherClass {
public:
MyOtherClass(const int a);
void youSpinMeRoundLikeARecord();
};
}
The corresponding C binding would then look like:
enum iox_Color {
Color_RED,
Color_GREEN,
Color_BLUE,
};
typedef struct Channel * sub_t;
sub_t iox_chan_create(const char * name);
void iox_chan_destroy(sub_t const self);
bool iox_chan_receive(sub_t const self, void * const data);
bool iox_chan_send(sub_t const self, void * const data);
void iox_chan_all_hail_hypnotoad(sub_t const self);
struct iox_other_class_storage_t_ {
uint64_t do_not_touch_me[8]; // lets assume 8 * 8 is the size of MyOtherClass
};
typedef iox_other_class_storage_t_ iox_other_class_storage_t;
typedef struct MyOtherClass * iox_other_class_t;
iox_other_class_t iox_other_class_init(iox_other_class_storage_t * self,const int a);
void iox_other_class_deinit(iox_other_class_t * self);
void iox_other_class_you_spin_me_round_like_a_record(iox_other_class_t * self);
Wiki Tutorials
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged iceoryx_binding_c at Robotics Stack Exchange
iceoryx_binding_c package from iceoryx repoiceoryx_binding_c iceoryx_hoofs iceoryx_integrationtest iceoryx_posh iceoryx_introspection |
|
Package Summary
Tags | No category tags. |
Version | 2.0.6 |
License | Apache 2.0 |
Build type | CMAKE |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/eclipse-iceoryx/iceoryx.git |
VCS Type | git |
VCS Version | release_2.0 |
Last Updated | 2024-06-11 |
Dev Status | DEVELOPED |
CI status | No Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Eclipse Foundation, Inc.
Authors
Iceoryx C Language binding
If you are looking for an example take a look at the icedelivery on c example.
C API structure
The C API is supposed to be as close to the C++ API as possible. This means, developers who are already familiar with the C++ API do not have to learn iceoryx from scratch in order to use the C API. There are of course differences due to C being a different language than C++.
Therefore, we have the following coding conventions exclusively in the C API.
- C functions are using an abbreviation of the class name. For instance
Subscriber
would usesub
and the methods are named likeiox_sub_method_name
where thecamelCase
is converted intosnake_case
. - A typedef for the handle is created with the abbreviation as name, a
iox
prefix and a_t
suffix, likeiox_sub_t
- If the constructor allocates an element it has the suffix
_create
and is called for instanceiox_node_create
. Analog to the constructor the destructor has the suffix_destroy
and is named likeiox_node_destroy
. - Pre iceoryx v2, constructor requiring preallocated memory had the suffix
_init
and required a pointer to a storage which was usually placed on the stack. Due to non-trivial issues with different sizes for different platforms and architectures the storage is ignored and the object is allocated on the heap. This might be reverted in a future release depending on a proper solution for the problem. The API remains the same, so a_storage_t
object likeiox_sub_storage_t
must be created and a pointer to this object must be passed to_init
, e.g.iox_sub_init
. This function returns a handle which does not point to the storage. Using the address of the storage in_deinit
is undefined and most likely will result in a segmentation fault. The usage is according the following example
iox_sub_storage_t subStorage;
iox_sub_t subscriber = iox_sub_init(&subStorage, "foo", "bar", "baz", nullptr);
// do something with subscriber
iox_sub_deinit(subscriber);
- The first parameter is always the handle to the corresponding object.
-
If possible, the arguments should stay the same in the C API.
- Enum values are named like
EnumName_EnumValue
- Enum names follow the rule
namespace_EnumName
Here is an example:
namespace iox {
enum class Color {
RED,
GREEN,
BLUE
};
class Channel {
public:
Channel(const std::string &name);
cxx::optional<void*> receive();
bool send(void * data);
void allHailHypnotoad();
};
class MyOtherClass {
public:
MyOtherClass(const int a);
void youSpinMeRoundLikeARecord();
};
}
The corresponding C binding would then look like:
enum iox_Color {
Color_RED,
Color_GREEN,
Color_BLUE,
};
typedef struct Channel * sub_t;
sub_t iox_chan_create(const char * name);
void iox_chan_destroy(sub_t const self);
bool iox_chan_receive(sub_t const self, void * const data);
bool iox_chan_send(sub_t const self, void * const data);
void iox_chan_all_hail_hypnotoad(sub_t const self);
struct iox_other_class_storage_t_ {
uint64_t do_not_touch_me[8]; // lets assume 8 * 8 is the size of MyOtherClass
};
typedef iox_other_class_storage_t_ iox_other_class_storage_t;
typedef struct MyOtherClass * iox_other_class_t;
iox_other_class_t iox_other_class_init(iox_other_class_storage_t * self,const int a);
void iox_other_class_deinit(iox_other_class_t * self);
void iox_other_class_you_spin_me_round_like_a_record(iox_other_class_t * self);
Wiki Tutorials
Dependant Packages
Launch files
Messages
Services
Plugins
Recent questions tagged iceoryx_binding_c at Robotics Stack Exchange
iceoryx_binding_c package from iceoryx repoiceoryx_binding_c iceoryx_integrationtest iceoryx_posh iceoryx_utils |
|
Package Summary
Tags | No category tags. |
Version | 1.0.3 |
License | Apache 2.0 |
Build type | CMAKE |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/eclipse-iceoryx/iceoryx.git |
VCS Type | git |
VCS Version | release_1.0 |
Last Updated | 2022-04-08 |
Dev Status | DEVELOPED |
CI status | No Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Eclipse Foundation, Inc.
Authors
Iceoryx C Language binding
If you are looking for an example take a look at the icedelivery on c example.
C API structure
The idea of the C API is to be as close to the C++ API as possible. The idea is that the C API looks and feels the same like the C++ API so that you do not have to learn Iceoryx from scratch if you would like to use the C API.
Therefore, we have the following coding conventions exclusively in the C API.
- C functions are using an abbreviation of the class name. For instance
Subscriber
would usesub
and the methods are named likeiox_sub_method_name
where the camelCase is converted into snake_case. - A typedef for the handle is created with the abbreviation as name, a
iox
prefix and a_t
suffix, likeiox_sub_t
- If the constructor allocates an element it has the suffix
_create
and is called for instanceiox_sub_create
. Analog to the constructor the destructor has the suffix_destroy
and is named likeiox_sub_destroy
. - If the constructor requires preallocated memory it has the suffix
_init
and is called for instanceiox_sub_init
. The corresponding destructor would then have the suffix_deinit
and is named likeiox_sub_deinit
.- We provide structs to preallocate memory on the stack easily. They are
having the suffix
_storage_t
and are named likeiox_sub_storage_t
. This allows you to use them like.
- We provide structs to preallocate memory on the stack easily. They are
having the suffix
iox_sub_storage_t subStorage;
iox_sub_t = iox_sub_init(&subStorage);
- The first parameter is always the handle to the corresponding object.
-
If possible, the arguments should stay the same in the C API.
- Enum values are named like
EnumName_EnumValue
- Enum names follow the rule
namespace_EnumName
Here is an example:
namespace iox {
enum class Color {
RED,
GREEN,
BLUE
};
class Subscriber {
public:
Subscriber(const std::string &name);
cxx::optional<void*> receive();
bool send(void * data);
void allHailHypnotoad();
};
class MyOtherClass {
public:
MyOtherClass(const int a);
void youSpinMeRoundLikeARecord();
};
}
The corresponding C binding would then look like:
enum iox_Color {
Color_RED,
Color_GREEN,
Color_BLUE,
};
typedef struct Subscriber * sub_t;
sub_t iox_sub_create(const char * name);
void iox_sub_destroy(sub_t const self);
bool iox_sub_receive(sub_t const self, void * const data);
bool iox_sub_send(sub_t const self, void * const data);
void iox_sub_all_hail_hypnotoad(sub_t const self);
struct iox_other_class_storage_t_ {
uint64_t do_not_touch_me[8]; // lets assume 8 * 8 is the size of MyOtherClass
};
typedef iox_other_class_storage_t_ iox_other_class_storage_t;
typedef struct MyOtherClass * iox_other_class_t;
iox_other_class_t iox_other_class_init(iox_other_class_storage_t * self,const int a);
void iox_other_class_deinit(iox_other_class_t * self);
void iox_other_class_you_spin_me_round_like_a_record(iox_other_class_t * self);
Wiki Tutorials
Dependant Packages
Name | Deps |
---|---|
cyclonedds | |
iceoryx_integrationtest |
Launch files
Messages
Services
Plugins
Recent questions tagged iceoryx_binding_c at Robotics Stack Exchange
iceoryx_binding_c package from iceoryx repoiceoryx_binding_c iceoryx_hoofs iceoryx_integrationtest iceoryx_posh iceoryx_introspection |
|
Package Summary
Tags | No category tags. |
Version | 2.0.6 |
License | Apache 2.0 |
Build type | CMAKE |
Use | RECOMMENDED |
Repository Summary
Checkout URI | https://github.com/eclipse-iceoryx/iceoryx.git |
VCS Type | git |
VCS Version | release_2.0 |
Last Updated | 2024-06-11 |
Dev Status | DEVELOPED |
CI status | No Continuous Integration |
Released | RELEASED |
Tags | No category tags. |
Contributing |
Help Wanted (0)
Good First Issues (0) Pull Requests to Review (0) |
Package Description
Additional Links
Maintainers
- Eclipse Foundation, Inc.
Authors
Iceoryx C Language binding
If you are looking for an example take a look at the icedelivery on c example.
C API structure
The C API is supposed to be as close to the C++ API as possible. This means, developers who are already familiar with the C++ API do not have to learn iceoryx from scratch in order to use the C API. There are of course differences due to C being a different language than C++.
Therefore, we have the following coding conventions exclusively in the C API.
- C functions are using an abbreviation of the class name. For instance
Subscriber
would usesub
and the methods are named likeiox_sub_method_name
where thecamelCase
is converted intosnake_case
. - A typedef for the handle is created with the abbreviation as name, a
iox
prefix and a_t
suffix, likeiox_sub_t
- If the constructor allocates an element it has the suffix
_create
and is called for instanceiox_node_create
. Analog to the constructor the destructor has the suffix_destroy
and is named likeiox_node_destroy
. - Pre iceoryx v2, constructor requiring preallocated memory had the suffix
_init
and required a pointer to a storage which was usually placed on the stack. Due to non-trivial issues with different sizes for different platforms and architectures the storage is ignored and the object is allocated on the heap. This might be reverted in a future release depending on a proper solution for the problem. The API remains the same, so a_storage_t
object likeiox_sub_storage_t
must be created and a pointer to this object must be passed to_init
, e.g.iox_sub_init
. This function returns a handle which does not point to the storage. Using the address of the storage in_deinit
is undefined and most likely will result in a segmentation fault. The usage is according the following example
iox_sub_storage_t subStorage;
iox_sub_t subscriber = iox_sub_init(&subStorage, "foo", "bar", "baz", nullptr);
// do something with subscriber
iox_sub_deinit(subscriber);
- The first parameter is always the handle to the corresponding object.
-
If possible, the arguments should stay the same in the C API.
- Enum values are named like
EnumName_EnumValue
- Enum names follow the rule
namespace_EnumName
Here is an example:
namespace iox {
enum class Color {
RED,
GREEN,
BLUE
};
class Channel {
public:
Channel(const std::string &name);
cxx::optional<void*> receive();
bool send(void * data);
void allHailHypnotoad();
};
class MyOtherClass {
public:
MyOtherClass(const int a);
void youSpinMeRoundLikeARecord();
};
}
The corresponding C binding would then look like:
enum iox_Color {
Color_RED,
Color_GREEN,
Color_BLUE,
};
typedef struct Channel * sub_t;
sub_t iox_chan_create(const char * name);
void iox_chan_destroy(sub_t const self);
bool iox_chan_receive(sub_t const self, void * const data);
bool iox_chan_send(sub_t const self, void * const data);
void iox_chan_all_hail_hypnotoad(sub_t const self);
struct iox_other_class_storage_t_ {
uint64_t do_not_touch_me[8]; // lets assume 8 * 8 is the size of MyOtherClass
};
typedef iox_other_class_storage_t_ iox_other_class_storage_t;
typedef struct MyOtherClass * iox_other_class_t;
iox_other_class_t iox_other_class_init(iox_other_class_storage_t * self,const int a);
void iox_other_class_deinit(iox_other_class_t * self);
void iox_other_class_you_spin_me_round_like_a_record(iox_other_class_t * self);