5 ms·

Nice, very nice. All of it. Long live C. Being stuck with C++ I did something in reverse - ported C-style ("intrusive") containers to ++, making them a bit saf

Nice, very nice. All of it. Long live C. Being stuck with C++ I did something in reverse - ported C-style ("intrusive") containers to ++, making them a bit safer to use, but keeping the syntax nearly the same. https://github.com/apankrat/notes/tree/master/intrusive-containers https://github.com/apankrat/notes/tree/master/intrusive-cont...

einpoklum 6y ago
The Boost libraries have an intrusive containers library, described here: https://www.boost.org/doc/libs/1_75_0/doc/html/intrusive.html https://www.boost.org/doc/libs/1_75_0/doc/html/intrusive.htm... Have you considered it? Is it deficient for your use case?
- apankrat 6y ago
  The post I linked to mentions it explicitly.
  - gpderetta 6y ago
    but it doesn't mention why not to use it.
    - apankrat 6y ago
      It does, in the exact same sentence.
      - gpderetta 6y ago
        You mean this: "the goal here is to make a better version of C-style containers rather than to implement something C++-style and similar,"? But a goal is not a reason. I.e. why doing CONTAINER_OF( user_data, vip ); instead of container_of<&user_data::vip> vip_list; is preferable? How are they even meaningfully different?
        apankrat 6y ago
        The reason is that the goal is not achievable using boost contraptions. At the very least it's not possible to use boost version without inheritance. As to why to do what you wrote I have no idea. These two code snippets are unrelated.
        gpderetta 6y ago
        of course it is possible to use boost intrusive without inheritance: it supports both hooks as base and hooks as members.
        apankrat 6y ago
        Oh, well, good for it. If I were to pick the reason, it'd be simply that I don't like Boost. To me, Boost is an ultimate embodiment of all that went wrong with C++ when it evolved from being a better version of C into the multi-paradigm monstrosity that it is now. Just look at the man page linked above. How to get a clever little concept of intrusive containers and completely decimate it into a technically correct, but unpalatable formulistic piece of engineering that, above all else, is rid of any shred of elegance that made the original concept so great in the first place.
- ktpsns 6y ago
  Here's a stupid question: what's the difference of using an intrusive container against using an STL container of (probably smart) pointers? i.e. std::list<My class*>. I've done that plenty of times in my codes in the past.
  - huhtenberg 6y ago
    Adding/removing items to std::list will result in extra allocations/deallocations. It will also take up more space, to store that very pointer. All of which starts to matter (a lot) when operating with very large data sets.
  - humanrebar 6y ago
    An intrusive node has a getter for the next intrusive node. And the data structure would use that getter to organize the elements of the data structure. Among other implications (different memory locality and allocation guarantees), you could have the same intrusive node object used in several container objects or even classes (though not at the same time). That is, pull an element from a doubly linked list and insert it into a binary tree without reallocation.
  - zackees 6y ago
    With intrusive you can remove from the list in constant time from the object itself. With std::list you need to find the iterate to the node before you can delete it.

einpoklum 6y ago

The Boost libraries have an intrusive containers library, described here: https://www.boost.org/doc/libs/1_75_0/doc/html/intrusive.html https://www.boost.org/doc/libs/1_75_0/doc/html/intrusive.htm... Have you considered it? Is it deficient for your use case?

apankrat 6y ago
The post I linked to mentions it explicitly.
- gpderetta 6y ago
  but it doesn't mention why not to use it.
  - apankrat 6y ago
    It does, in the exact same sentence.
    - gpderetta 6y ago
      You mean this: "the goal here is to make a better version of C-style containers rather than to implement something C++-style and similar,"? But a goal is not a reason. I.e. why doing CONTAINER_OF( user_data, vip ); instead of container_of<&user_data::vip> vip_list; is preferable? How are they even meaningfully different?
      - apankrat 6y ago
        The reason is that the goal is not achievable using boost contraptions. At the very least it's not possible to use boost version without inheritance. As to why to do what you wrote I have no idea. These two code snippets are unrelated.
        gpderetta 6y ago
        of course it is possible to use boost intrusive without inheritance: it supports both hooks as base and hooks as members.
        apankrat 6y ago
        Oh, well, good for it. If I were to pick the reason, it'd be simply that I don't like Boost. To me, Boost is an ultimate embodiment of all that went wrong with C++ when it evolved from being a better version of C into the multi-paradigm monstrosity that it is now. Just look at the man page linked above. How to get a clever little concept of intrusive containers and completely decimate it into a technically correct, but unpalatable formulistic piece of engineering that, above all else, is rid of any shred of elegance that made the original concept so great in the first place.
ktpsns 6y ago
Here's a stupid question: what's the difference of using an intrusive container against using an STL container of (probably smart) pointers? i.e. std::list<My class*>. I've done that plenty of times in my codes in the past.
- huhtenberg 6y ago
  Adding/removing items to std::list will result in extra allocations/deallocations. It will also take up more space, to store that very pointer. All of which starts to matter (a lot) when operating with very large data sets.
- humanrebar 6y ago
  An intrusive node has a getter for the next intrusive node. And the data structure would use that getter to organize the elements of the data structure. Among other implications (different memory locality and allocation guarantees), you could have the same intrusive node object used in several container objects or even classes (though not at the same time). That is, pull an element from a doubly linked list and insert it into a binary tree without reallocation.
- zackees 6y ago
  With intrusive you can remove from the list in constant time from the object itself. With std::list you need to find the iterate to the node before you can delete it.