0

Since scoped_ptr guarantees that all objects in a given thread are allocated in a stack-like fashion, what is the least painful way of specifying a "custom heap" for objects under scoped_ptr?
(e.g. for vectors, deques, strings, etc.)

(This would allow us to avoid the traditional heap overhead almost entirely, getting a pool that is almost as fast as the stack, but as large as the heap.)

trincot
  • 317,000
  • 35
  • 244
  • 286
user541686
  • 205,094
  • 128
  • 528
  • 886
  • 1
    scoped_ptr doesn't guarantee anything about allocation strategy, only that it'll call the deleter once it goes out of scope. – Cory Nelson Apr 03 '12 at 02:08
  • @CoryNelson: It also guarantees that it cannot be copied or moved, doesn't it? Which means that, unless the pointer is explicitly escaped (which is the programmer's fault and easily avoidable), two `scoped_ptr`s must be destroyed in the reverse order in which they were created, on any given thread. – user541686 Apr 03 '12 at 02:11
  • 1
    @Mehrdad: I guess because the question is non-sensical. It's a bit harsh... – Matthieu M. Apr 03 '12 at 07:52
  • @MatthieuM.: I honestly don't understand why it's nonsensical though. I hope that part about the stack-like allocation at least makes sense? And regarding the allocations, if `scoped_ptr` could somehow "hook" the underlying memory allocation interfaces temporarily during allocation/freeing, for example, that would answer my question. Or maybe there's a better way, I don't know. Could you elaborate on why it doesn't make sense? – user541686 Apr 03 '12 at 08:13
  • @Mehrdad: because of the way `boost::scoped_ptr` is created: you pass it a pointer to an object already allocated --> it is too late. This is not `boost::make_shared` or `boost::optional`. Once the `scoped_ptr` get an object, it already exist, so is not relocated. – Matthieu M. Apr 03 '12 at 09:30
  • @MatthieuM.: Can't that be changed, though? I didn't say you can't touch the source code... – user541686 Apr 03 '12 at 15:07
  • 1
    @Mehrdad: How ? I repeat, you pass an *already allocated* object to `scoped_ptr`, how could then `scoped_ptr` influence an event that has happened *before* it entered into play ? – Matthieu M. Apr 03 '12 at 15:19
  • @MatthieuM.: Uh, you can make a new class that *doesn't* take in a pointer? I think you're restricting the problem too much, I didn't mean it to be so close-ended.. – user541686 Apr 03 '12 at 15:23
  • @Mehrdad: Well, your question specifically asks about `scoped_ptr` and never suggests you might want to consider another class (`boost::optional` for example). If you write a class yourself, then about anything becomes possible... though meddling with the passed in template arguments (allocator) will still be delicate. – Matthieu M. Apr 03 '12 at 17:20

1 Answers1

3

scoped_ptr, and smart pointers in general, have no effect on memory allocated by the objects they hold. If for some reason you have a scoped_ptr<std::vector<T> >, the fact that the std::vector<T>* is stored in a scoped_ptr is entirely irrelevant to where std::vector<T> gets its memory from.

Of course, the fact that std::vector<T> is already a RAII type (like all other standard-library classes) that will clean up after itself means that sticking them in a scoped_ptr is quite pointless.

In short, what you're talking about has nothing to do with scoped_ptr at all. It has to do with the allocators you use for your container classes. You're barking up the wrong tree.

Nicol Bolas
  • 449,505
  • 63
  • 781
  • 982
  • Well, you don't *have* to use allocators for this, do you? Is there no way to use, maybe, an `operator-new`-overloading trick inside a class like `scoped_ptr`, or maybe to temporarily hook the global memory allocator (based on type perhaps?) or something like that? I understand that allocators are *one* solution, but are they the *only* (or the best/easiest) solutions? – user541686 Apr 03 '12 at 08:15
  • @Mehrdad: `scoped_ptr` is not *magic*. All it's doing is storing a pointer, giving it out when you request it, and then deleting it in its destructor. It has no more knowledge of what it's actually storing than that. The way to influence where memory for standard library containers comes from is with allocators; there is no alternative method. Overloading `operator new` will not help, because they don't *use* `operator new`. They use allocators. – Nicol Bolas Apr 03 '12 at 09:23
  • Yes, I already know what `scoped_ptr` does, but it seems like you're unnecessarily over-restricting the problem. Can't you make a new class that uses `scoped_ptr` internally, for instance, and which allocates the object? Or can't you take the code of `scoped_ptr`, tweak it a bit, and get it to work? I don't understand why you restricted the question so much... – user541686 Apr 03 '12 at 15:34
  • @Mehrdad: You *could* do a lot of things. You *could* have a special "container holder" that automatically hooks a special allocator into the container that it stores, which draws memory from some pool somewhere. But you didn't ask about that. You asked about `scoped_ptr`. I can only answer what you *ask*, not what you *thought* you were asking. – Nicol Bolas Apr 03 '12 at 15:36
  • Making a class which internally uses `scoped_ptr` but which allocates the object itself isn't an unreasonably wild guess for a potential answer, is it? Or maybe I'm just being too creative when I try to think of solutions... – user541686 Apr 03 '12 at 15:38
  • @Mehrdad: If several people are answering/commenting on your question in the same way, then it's almost certainly not their fault for understanding your question that way. It's *your* fault for not phrasing the question properly to get the kind of results you want. So if this answer is not to your liking, please ask a new question that will more likely get the kind of answer you're looking for. – Nicol Bolas Apr 03 '12 at 15:41
  • let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/9645/discussion-between-nicol-bolas-and-mehrdad) – Nicol Bolas Apr 03 '12 at 15:42