4 ms·

I don't see this. You can have a container of pointers in C++ just as you can in C. No special ownership semantics is assumed, nor do you have to decide which

I don't see this. You can have a container of pointers in C++ just as you can in C. No special ownership semantics is assumed, nor do you have to decide which is the "owner" any more than you do in C. Or the problem is the same, at any rate. Plus you're not constantly casting <void*> to things. You can have a container of smart pointers, too, if you really don't want to think about ownership.

huhtenberg 15y ago
Container of pointers is not exactly what STL containers are about, and smart pointers is a big can of worms in themselves as I'm sure you know. Another angle to consider is this - if container control elements (like list_head) are stored in the actual data items, they are effectively pre-allocated, meaning that inserting an item into the container involves no heap activity, and this helps simplifying the (error handling) code quite a bit. I mean... all in all, even it seems hacky, it is a more elegant idea. STL to C-style containers is what Java is to C++ - something with all fun drained from it :)
acqq 15y ago
No, that's not the subject. The subject is, as chancho also mentions here (http://news.ycombinator.com/item?id=3641718 http://news.ycombinator.com/item?id=3641718), something that's explained in http://www.boost.org/doc/libs/1_47_0/doc/html/intrusive/intrusive_vs_nontrusive.html#intrusive.intrusive_vs_nontrusive.differences_intrusive_vs_nontrusive http://www.boost.org/doc/libs/1_47_0/doc/html/intrusive/intr... Since you can write C in C++ of course everything can be written in C++ too if you don't use C++ "common" libraries and roll your own infrastructure. Once you care about "guts" of your program enough that you have to care about allocations, you'd see that as soon as you're thinking about "containers" having "pointers" to "objects" you're probably on the wrong way. Because "objects" often contain pointers that make part of more data structures but also can be of different size (you can't even "sizeof" them) and also you want to be the one who controls when and where each of them is actually stored (in a sense of the memory block). I've done these things in C++ without boost, more "in a C way" inside of the separate modules (those that were critical) and I still wouldn't use boost monster, the amount of code dependency is much smaller that way. Also see groby_b's: http://news.ycombinator.com/item?id=3641890 http://news.ycombinator.com/item?id=3641890

huhtenberg 15y ago

Container of pointers is not exactly what STL containers are about, and smart pointers is a big can of worms in themselves as I'm sure you know. Another angle to consider is this - if container control elements (like list_head) are stored in the actual data items, they are effectively pre-allocated, meaning that inserting an item into the container involves no heap activity, and this helps simplifying the (error handling) code quite a bit. I mean... all in all, even it seems hacky, it is a more elegant idea. STL to C-style containers is what Java is to C++ - something with all fun drained from it :)

acqq 15y ago

No, that's not the subject. The subject is, as chancho also mentions here (http://news.ycombinator.com/item?id=3641718 http://news.ycombinator.com/item?id=3641718), something that's explained in http://www.boost.org/doc/libs/1_47_0/doc/html/intrusive/intrusive_vs_nontrusive.html#intrusive.intrusive_vs_nontrusive.differences_intrusive_vs_nontrusive http://www.boost.org/doc/libs/1_47_0/doc/html/intrusive/intr... Since you can write C in C++ of course everything can be written in C++ too if you don't use C++ "common" libraries and roll your own infrastructure. Once you care about "guts" of your program enough that you have to care about allocations, you'd see that as soon as you're thinking about "containers" having "pointers" to "objects" you're probably on the wrong way. Because "objects" often contain pointers that make part of more data structures but also can be of different size (you can't even "sizeof" them) and also you want to be the one who controls when and where each of them is actually stored (in a sense of the memory block). I've done these things in C++ without boost, more "in a C way" inside of the separate modules (those that were critical) and I still wouldn't use boost monster, the amount of code dependency is much smaller that way. Also see groby_b's: http://news.ycombinator.com/item?id=3641890 http://news.ycombinator.com/item?id=3641890