But when you enter the loop you have no other "objects" in your program allocated at all, so it doesn't have to do a search for a suitably sized block. Near-identical timings for changing the size to 256 is what I would…
With std::shared_ptr each copy has a pointer to the ref count & there is only one ref count, atomically updated with a cmpxchg instruction. Not sure what you mean by "references are updated or moved around"? But I agree…
Not sure what you mean here, std::unique_ptr is for when you want to auto destruct a ptr when going out of scope (ref counting limited to one) and std::shared_ptr is normal reference counting, they aren't alternatives…
Excuse me if I have mis-read your sample program but it looks like you are allocating 16 bytes, then immediately freeing it, again and again in a loop. Since you're not allocating anything else, the allocate and free…
> Reference counting including unique_ptr also have to be locked for updates This is not true. The counter itself can have its count updated atomically with a compare & exchange. I think this is what actually happens in…
I was simply saying that it's undecideable to do bounds checking at compile time, so it's better to use languages that do bounds checking at run time. But you shouldn't blame C for this.
We are in agreement, by comment was not saying people should use C. It was saying that a layer of unsafety has to exist somewhere.
"I'd rather put my bugs in one, more easily verifiable place." We are in agreement, that is why I was saying people shouldn't use C unless they need it.
Yes, but I am in agreement with you. I was simply saying you shouldn't blame C for being what it is, not that you should use it.
"How can I avoid being burned by C’s numerous and severe shortcomings?" I think this is where we start bumping up against the limitations of the universe we live in, because the question becomes "where do we put the…
But when you enter the loop you have no other "objects" in your program allocated at all, so it doesn't have to do a search for a suitably sized block. Near-identical timings for changing the size to 256 is what I would…
With std::shared_ptr each copy has a pointer to the ref count & there is only one ref count, atomically updated with a cmpxchg instruction. Not sure what you mean by "references are updated or moved around"? But I agree…
Not sure what you mean here, std::unique_ptr is for when you want to auto destruct a ptr when going out of scope (ref counting limited to one) and std::shared_ptr is normal reference counting, they aren't alternatives…
Excuse me if I have mis-read your sample program but it looks like you are allocating 16 bytes, then immediately freeing it, again and again in a loop. Since you're not allocating anything else, the allocate and free…
> Reference counting including unique_ptr also have to be locked for updates This is not true. The counter itself can have its count updated atomically with a compare & exchange. I think this is what actually happens in…
I was simply saying that it's undecideable to do bounds checking at compile time, so it's better to use languages that do bounds checking at run time. But you shouldn't blame C for this.
We are in agreement, by comment was not saying people should use C. It was saying that a layer of unsafety has to exist somewhere.
"I'd rather put my bugs in one, more easily verifiable place." We are in agreement, that is why I was saying people shouldn't use C unless they need it.
Yes, but I am in agreement with you. I was simply saying you shouldn't blame C for being what it is, not that you should use it.
"How can I avoid being burned by C’s numerous and severe shortcomings?" I think this is where we start bumping up against the limitations of the universe we live in, because the question becomes "where do we put the…