4 ms·
for those not familiar with Go, here's the problem translated in C terms: "I passed a pointer to your function and it called free() on it. how dare you!"
by f2f 13y ago
for those not familiar with Go, here's the problem translated in C terms: "I passed a pointer to your function and it called free() on it. how dare you!"
- thirsteh 13y agoor "I passed an fp to your function, and you called close() on it. How dare you!?" :)
- nostrademons 13y agoMore "I passed a pointer to your function and it called free() on it, without documenting that it was taking ownership of the memory". Ownership contracts are an important part of the API of any function that does stuff with resources, whether memory, file descriptions, network connections, etc. If the API implies that it takes a pointer to a resource but will only read from or write to it, and then disposes of it, that's a bug.
- marshray 13y agoI think that's a good point. It's often said that garbage collection helps prevent memory leaks, and it's also said often that memory isn't the only kind of resource which could be leaked. Here is another case where weak- and dynamic-typing language features have come up in the context of resource management. I'm not saying this one example proves anything, just that it might be interesting to be on the lookout for other events of this pattern.
- pcwalton 13y agoNo, that's not what the problem is. Translated to C++, the problem is "you passed a pointer to A∗, you dynamic_cast<>'d it to a subtype B∗ without documenting that you did so".
- nly 13y agoNot really. You can't dynamic_cast across across protected or private inheritance boundaries, even if the function attempting it is a friend. As long as your public inheritance hierarchy maintains your contract (and they should) you're fine.