Tasteless mimic of operator new: Call ctor

Hello Gurus,

I'm working on a few generic code sequences which should in some ways mimic the functionality of global operator new. I believe the code might be considered in bad taste. However, I would still be curious if there are syntaxes available for this.

I want to mimic new in so far as it takes (or allocates) a chunk of memory and calls a ctor on it.

My codes are below. The upper ctor call works for VS2010 but not for GCC 4.5.0. The template works for neither.

• Can anyone help out with the syntaxes of these codes?
• Is it even possible to call ctors directly on a chunk of memory in these ways?

Thanks. Sincerely, Chris.

Code:

---

#include <iostream>

typedef unsigned char UINT8;

struct Wrapper
{
  unsigned x;
  Wrapper(const unsigned X = 1u) : x(X) { }
};

namespace
{
  UINT8 pool[64u];
}

template<typename T> T* alloc(void)
{
  ((T*) pool)->T::T();
}

int main()
{
  // Can not call constructor directly?
  // Is there a syntax for this?
  ((Wrapper*) pool)->Wrapper::Wrapper();
  const Wrapper* p1 = (Wrapper*) pool;
  std::cout << p1->x << std::endl;

  // Does not seem to work.
  // Wrapper does not have member function T.
  // Any syntax for this?
  const Wrapper* p2 = alloc<Wrapper>();
  std::cout << p2->x << std::endl;
}

---

Use placement new.

I believe placement-new is what you're looking for.

Regards,

Paul McKenzie

Yes, thank you.

[Edited]: Disregard previous text.

Oh... Silly me! You guys mean it's already there.

I got it.

Please disregard my last post.

Thanks so much.

Sincerely, Chris.

Quote:

---

Originally Posted by dude_1967

I got it.

---

So just one more thing...

Can I coerce placement new to return 0 if my custom buffer is full?

If so, how?

Sincerely, Chris.

This might help http://en.wikipedia.org/wiki/Placement_syntax

Quote:

---

Originally Posted by dude_1967

So just one more thing...

Can I coerce placement new to return 0 if my custom buffer is full?

If so, how?

Sincerely, Chris.

---

You wouldn't even try to use placement new if you didn't have memory to use it on. So the decision of whether or not the buffer is full occurs before placement new is called.

Quote:

---

Originally Posted by Lindley

You wouldn't even try to use placement new if you didn't have memory to use it on. So the decision of whether or not the buffer is full occurs before placement new is called.

---

May I clarify my question now that I have worked on this a while?

If my custom buffer returns (void*) 0u, will placement new correspondingly return 0?

For a bit of background: I am working on ultra bare-bones microcontroller embedded systems with tiny, self-managed heaps to be used in an extremely restrictive fashion, such as one-shot allocation of selected few singleton instances with static linkage. I build GCC and the CLIB without a heap or patch the compiler such that there is none. There will be no corresponding calls to delete in these designs. My stuff works quite well now that you all have steered me in the right direction on this new-thang.

Sincerely, Chris.

If your attempt to obtain memory for an object fails, then you should not even try to call placement new because you have nowhere to place the object.

Quote:

---

Originally Posted by Lindley

If your attempt to obtain memory for an object fails, then you should not even try to call placement new because you have nowhere to place the object.

---

Right now my custom buffer returns zero if the call to placement new exceeds the available memory in the buffer. Perhaps I should add to my custom buffer a public member which can be queried regarding the amount of free memory available. Is this what you mean?

Sincerely, Chris.

You seem to be thinking that the call to placement new is above the buffer allocation. I'm thinking it should be the other way around: your custom allocator decides if it has enough buffer space available, then calls placement new if so.

Quote:

---

Originally Posted by Lindley

You seem to be thinking that the call to placement new is above the buffer allocation. I'm thinking it should be the other way around: your custom allocator decides if it has enough buffer space available, then calls placement new if so.

---

Yes, what an astute observation. Thank you.

I tried it that way a few times, but lost confidence because of the complexity of the solution details.

At first, I actually did make a global allocator for objects. But I really got lost in the implementation details. I believe that you need a lot of templates or tuples to do this because you need to support ctor calls with an unknown number of ctor input parameters. This would be a template with N+1 parameters, N ctor parameters plus one additional template type for the type of the class or struct. I wrote 10 individual templates for it, so as tu support ctors with up to 10 ctor params. And it worked just fine. I tried it with a few ctors with several parameters. Everything worked fine --- OK. But the implementation details were so ugly and crude, base and low, that I was ashamed of what I had done. So I switched it to the other way around --- on purpose. Placement new gets called, custom buffer allocates and may return 0.

Are you following this junk that I'm talking about? Or am I just totally on the wrong track?

Could you indicate any sensible way to create a global object allocator, I mean fully generic, to be used with placement new in combination with a custom buffer?

Sincerely, Chris.

Well, in theory, C++0x Variadic Templates are precisely what you need to solve the above problem. Unfortunately, I don't believe any current compilers yet support them.

Oh. I have heard of those, variadic templates. They came up in a previous post.

Maybe I'll go into the intricate depths of the templates and try it again.

Maybe I can make it prettier the next time around. The first time, I had completely templated the class or struct. But I just looked at it again. In fact, I can make one allocator struct and merely template the allocator proper. So I can get away with only specializing tha allocator per-se.

I will look at it again.

I am happy with the solution that I have. But I still want to look at various options.

Thanks for your help.

Sincerely, Chris.

Lindley, I can't add to your rep any more because the box won't let me. Wants me to spread it around.

But you rock. All the other gurus too.

Bye, Chris.

Quote:

---

Originally Posted by dude_1967

There will be no corresponding calls to delete in these designs.

---

When you use placement new, you shouldn't call delete, but you should call the destructor explicitly.

Well, placement delete. However, that isn't necessary if the types in question don't allocate resources internally, which may be the case here.

Thanks for the further suggestions.

The types I am creating with placement new never delete. They also don't alocate any further resources internally.

It's kind of a funny region --- the world of tiny embedded systems. You turn on your microcontroller, initialize your CPU, stack-pointer, hardware, SRAM, stack, ctors, etc. Then you might make your singleton instances, as run-time progresses, with placement new.

The microcontroller runs and runs and runs until someone mercifully switches it off. main does not return. It's a different kind of design than most people are used to. For this design, I am making a kind of "one-shot" heap.

I've got it all under control now.

Again, thanks for all the help. I always get good answers at codeguru.

Sincerely, Chris.

This article by Dr Dobbs may be of some use or inspiration.

http://www.drdobbs.com/184403759

I used information from here to help design allocators that grabbed space from the stack.

Quote:

---

Originally Posted by dude_1967

It's kind of a funny region --- the world of tiny embedded systems.

---

Up until my current job all my work was with embedded systems (6809, 68000). I used to quite enjoy it. There was no OS; If you wanted to print to the screen you had to first write the code that took the output from printf and wrote the pixels to the video memory from your own bitmap font definitions. Ah, those were the days.. (Sits back in chair basking in warm rosey glow of nostalgia :))