Skip to content
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

iox-#186 Add first cxx::forward_list implementation to utils #189

Conversation

mossmaurice
Copy link
Contributor

Code contributed by @bishibashiB

… utils

Signed-off-by: Bernhard Eickhoff (CC-AD/ESW1) <bernhard.eickhoff@de.bosch.com>
@mossmaurice mossmaurice linked an issue Jul 13, 2020 that may be closed by this pull request
@mossmaurice mossmaurice added the enhancement New feature label Jul 13, 2020
Copy link
Contributor

@elfenpiff elfenpiff left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove the two distinct unrelated iterator classes and just write one iterator class with const overloaded methods.
They can be aliased like

using iterator = MyIteratorClass;
using const_iterator = const MyIteratorClass;

iceoryx_utils/include/iceoryx_utils/cxx/forward_list.hpp Outdated Show resolved Hide resolved
iceoryx_utils/include/iceoryx_utils/cxx/forward_list.hpp Outdated Show resolved Hide resolved
iceoryx_utils/include/iceoryx_utils/cxx/forward_list.hpp Outdated Show resolved Hide resolved
};

void init() noexcept;
ListNodeType* getNodePtrFromIdx(sizeType) const noexcept;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please return const ListNodeType * since this method is const and we do not want to change the internal state.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess all three internal functions (below) cast away constness from a (potential) const list to non-const node member pointer. Themself they do not change anything on the list.

    ListNodeType* getNodePtrFromIdx(SizeType) const noexcept;
    ListNodeType* getHeadFreeEl() const noexcept;
    ListNodeType* getPointerToListNode() const noexcept;

For a better internal handling of constness I wonder if it would be cleaner to replace all three with a const & non-const tuple, like so

    ListNodeType* getNodePtrFromIdx(SizeType) noexcept;
    const ListNodeType* getNodePtrFromIdx(SizeType) const noexcept;
    ListNodeType* getHeadFreeEl() noexcept;
    const ListNodeType* getHeadFreeEl() const noexcept;
    ListNodeType* getPointerToListNode() noexcept;
    const ListNodeType* getPointerToListNode() const noexcept;

Upper (current) implementation is slimmer. Would the later anyway be appreciated? Am I missing other alternatives?
Updated to follow Effective C++ Item3.

iceoryx_utils/include/iceoryx_utils/cxx/forward_list.hpp Outdated Show resolved Hide resolved
iceoryx_utils/test/moduletests/test_cxx_forward_list.cpp Outdated Show resolved Hide resolved
iceoryx_utils/include/iceoryx_utils/cxx/forward_list.hpp Outdated Show resolved Hide resolved
iceoryx_utils/include/iceoryx_utils/cxx/forward_list.hpp Outdated Show resolved Hide resolved
…lCase, prefix and namings/comments (review findings)

Signed-off-by: Eickhoff Bernhard (CC-AD/ESW1) <bernhard.eickhoff@de.bosch.com>
…PECT_DEATH test on mac

Signed-off-by: Eickhoff Bernhard (CC-AD/ESW1) <bernhard.eickhoff@de.bosch.com>
Signed-off-by: Eickhoff Bernhard (CC-AD/ESW1) <bernhard.eickhoff@de.bosch.com>
iceoryx_utils/include/iceoryx_utils/cxx/forward_list.hpp Outdated Show resolved Hide resolved
iceoryx_utils/include/iceoryx_utils/cxx/forward_list.hpp Outdated Show resolved Hide resolved
iceoryx_utils/include/iceoryx_utils/cxx/forward_list.hpp Outdated Show resolved Hide resolved
iceoryx_utils/include/iceoryx_utils/cxx/forward_list.hpp Outdated Show resolved Hide resolved
iceoryx_utils/include/iceoryx_utils/cxx/forward_list.hpp Outdated Show resolved Hide resolved
if (!isValidElementIndex(iter.m_iterListNodeIdx))
{
errorMessage(__PRETTY_FUNCTION__, " tryed accessing not existing element");
std::terminate();
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

undefined behaviour in C++ so terminate might be justified (but not necessary since we already checked for it, crash/terminate in undefined behaviour often happens since the check is skipped for efficiency reasons...). This is again the question of how to deal with certain kinds of usage-errors.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

see above, directive for aligned error handling

iceoryx_utils/include/iceoryx_utils/cxx/forward_list.hpp Outdated Show resolved Hide resolved
…out-of-class operator==, type can format review findings

Signed-off-by: Eickhoff Bernhard (CC-AD/ESW1) <bernhard.eickhoff@de.bosch.com>
…d_cxx_forward_list

Hopefully fixing the windows build
Comment on lines 391 to 394
// template <typename IterType, typename IterTypeOther>
// bool operator==<typename std::enable_if<is_forward_list_iterator<IterType>::value>::type,
// typename std::enable_if<is_forward_list_iterator<IterTypeOther>::value>::type>(
// const IterType& lhs_iter, const IterTypeOther& rhs_iter) noexcept;
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Remove?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

uups, sure! removed in 6bbaaffef5d63b6e7ff0785d850bb02c93ba638b

orecham
orecham previously approved these changes Jul 21, 2020
// limitations under the License.

#ifndef CXX_FORWARD_LIST_HPP_INCLUDED
#define CXX_FORWARD_LIST_HPP_INCLUDED
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Include guard should look like this "IOX_UTILS_CXX_FORWARD_LIST_HPP"

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done in 80f54bf97462be9eb59d71c1dfabdc2beab54efd

@bishibashiB
Copy link
Contributor

iceoryx_utils/readme.md shall provide a hint regarding the forward_list implementation.

…fix comments

Signed-off-by: Eickhoff Bernhard (CC-AD/ESW1) <bernhard.eickhoff@de.bosch.com>
…rite), add remove(_if) member_function, correct include guards

Signed-off-by: Eickhoff Bernhard (CC-AD/ESW1) <bernhard.eickhoff@de.bosch.com>
@bishibashiB bishibashiB force-pushed the feature/iox-#186_add_cxx_forward_list branch from 80f54bf to b070d0a Compare August 14, 2020 06:35
…ntation

Signed-off-by: Eickhoff Bernhard (CC-AD/ESW1) <bernhard.eickhoff@de.bosch.com>
…ions

Signed-off-by: Eickhoff Bernhard (CC-AD/ESW1) <bernhard.eickhoff@de.bosch.com>
}

// iterator
/*************************/
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's just nitpicking that these separator lines are somehow weird. But i know that's for better readibility. Maybe just add some spacing and then just a comment like you did without these separator lines is sufficient here. But as @elBoberido would say: I have no strong feelings about this. ;-)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you are from the neutral planet https://www.youtube.com/watch?v=CxK_nA2iVXw. And so am I in this regard. :-)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

To respect your non-feelings here: removed

@bishibashiB
Copy link
Contributor

Remove the two distinct unrelated iterator classes and just write one iterator class with const overloaded methods.
They can be aliased like

using iterator = MyIteratorClass;
using const_iterator = const MyIteratorClass;

see latest implementation using a iterator_base class.

@@ -41,11 +41,12 @@ class should be used.
|`algorithm` | | | Implements `min` and `max` for an arbitrary number of values of the same type. For instance `min(1,2,3,4,5);` |
|`convert` | | | Converting a number into a string is easy, converting it back can be hard. You can use functions like `strtoll` but you still have to handle errors like under- and overflow, or converting invalid strings into number. Here we abstract all the error handling so that you can convert strings into numbers safely. |
|`expected` | | | Our base class used in error handling. Every function which can fail should return an expected. With this the user knows that this function can fail and that they have to do some kind of error handling. We got inspired by the [C++ expected proposal]( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0323r7.html) and by the [rust error handling concept](https://doc.rust-lang.org/std/result/enum.Result.html). |
|`forward_list` | | | Heap and exception free implementation of `std::forward_list` |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

which can be stored in shared memory or is relocatable (could be mentioned optionally).

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

iceoryx_utils/include/iceoryx_utils/cxx/forward_list.hpp Outdated Show resolved Hide resolved
iceoryx_utils/include/iceoryx_utils/cxx/forward_list.hpp Outdated Show resolved Hide resolved
iceoryx_utils/include/iceoryx_utils/cxx/forward_list.hpp Outdated Show resolved Hide resolved
iceoryx_utils/test/moduletests/test_cxx_forward_list.cpp Outdated Show resolved Hide resolved
iceoryx_utils/test/moduletests/test_cxx_forward_list.cpp Outdated Show resolved Hide resolved
{
for (uint64_t i = 0; i < TESTLISTCAPACITY; ++i)
{
sut.emplace_front((const uint64_t)i);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

remove C-style cast

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

Signed-off-by: Eickhoff Bernhard (CC-AD/ESW1) <bernhard.eickhoff@de.bosch.com>
struct NodeLink
{
size_type nextIdx;
bool freedElement;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

static constexpr size_type END_INDEX{size_type(Capacity) + 1U};
static constexpr size_type NODE_LINK_COUNT{size_type(Capacity) + 2U};

// two member variables point to head of freeList and usedList
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

@@ -41,11 +41,12 @@ class should be used.
|`algorithm` | | | Implements `min` and `max` for an arbitrary number of values of the same type. For instance `min(1,2,3,4,5);` |
|`convert` | | | Converting a number into a string is easy, converting it back can be hard. You can use functions like `strtoll` but you still have to handle errors like under- and overflow, or converting invalid strings into number. Here we abstract all the error handling so that you can convert strings into numbers safely. |
|`expected` | | | Our base class used in error handling. Every function which can fail should return an expected. With this the user knows that this function can fail and that they have to do some kind of error handling. We got inspired by the [C++ expected proposal]( http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p0323r7.html) and by the [rust error handling concept](https://doc.rust-lang.org/std/result/enum.Result.html). |
|`forward_list` | | | Heap and exception free implementation of `std::forward_list` |
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

iceoryx_utils/include/iceoryx_utils/cxx/forward_list.hpp Outdated Show resolved Hide resolved
iceoryx_utils/test/moduletests/test_cxx_forward_list.cpp Outdated Show resolved Hide resolved
iceoryx_utils/test/moduletests/test_cxx_forward_list.cpp Outdated Show resolved Hide resolved
{
for (uint64_t i = 0; i < TESTLISTCAPACITY; ++i)
{
sut.emplace_front((const uint64_t)i);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

done

…emcpy

Signed-off-by: Eickhoff Bernhard (CC-AD/ESW1) <bernhard.eickhoff@de.bosch.com>
Signed-off-by: Eickhoff Bernhard (CC-AD/ESW1) <bernhard.eickhoff@de.bosch.com>
Signed-off-by: Eickhoff Bernhard (CC-AD/ESW1) <bernhard.eickhoff@de.bosch.com>

#include "iceoryx_utils/internal/cxx/forward_list.inl"

#endif // IOX_UTILS_CXX_FORWARD_LIST_HPP
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Add empty line please

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Done

Signed-off-by: Eickhoff Bernhard (CC-AD/ESW1) <bernhard.eickhoff@de.bosch.com>
@dkroenke dkroenke dismissed elfenpiff’s stale review September 3, 2020 08:35

Review points are adressed

@MatthiasKillat MatthiasKillat merged commit 9d70ac9 into eclipse-iceoryx:master Sep 3, 2020
@bishibashiB bishibashiB deleted the feature/iox-#186_add_cxx_forward_list branch September 3, 2020 11:51
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add cxx::list to utils
7 participants