Does C++ require a destructor call for each placement new?

I understand that placement new calls are usually matched with explicit calls to the destructor. My question is: if I have no need for a destructor (no code to put there, and no member variables that have destructors) can I safely skip the explicit destructor call?

Here is my use case: I want to write C++ bindings for a C API. In the C API many objects are accessible only by pointer. Instead of creating a wrapper object that contains a single pointer (which is wasteful and semantically confusing). I want to use placement new to construct an object at the address of the C object. The C++ object will do nothing in its constructor or destructor, and its methods will do nothing but开发者_如何学编程 delegate to the C methods. The C++ object will contain no virtual methods.

I have two parts to this question.

1. Is there any reason why this idea will not work in practice on any production compiler?

2. Does this technically violate the C++ language spec?

If I understand your question correctly you have a C object in memory and you want to initialize a C++ object with the same layout "over the top" of the existing object.

CppObject* cppobject = new (cobject) CppObject;

While there is no problem with not calling a destructor for the old object - whether this causes resource leaks or other issues is entirely down to the type of the old object and is a user code issue, not a language conformance issue - the fact that you reuse the memory for a new object means that the old object is no longer accessible.

Although the placement form of operator new must just return the address that it was given, there is nothing to stop the new expression itself wiping the memory for the new object before any constructor (if any) is called. Members of the new object that are not initialized according to C++ language rules have unspecified contents which definitely does not mean the same as having the contents of any old object that once lived in the memory being reused.

If I understand you correctly, what you are trying to do is not guaranteed to work.

I think the answer is that if your class is POD (which it is, if it's true that it does nothing in the con/destructor, has no virtual member functions, and has no non-static data members with any of those things), then you don't need to call a constructor or a destructor, its lifetime is just the lifetime of the underlying memory. You can use it the same way that a struct is used in C, and you can call its member functions regardless of whether it has been constructed.

The purpose of placement new is to allow you to create object pools or align multiple objects together in contiguous memory space as with std::vector.

If the objects are C-structs then you do not need placement new to do this, you can simply use the C method of allocating the memory based on sizeof(struct Foo) where Foo is the struct name, and if you allocate multiple objects you may need to multiple the size up to a boundary for alignment.

However there is no need to placement-new the objects there, you can simply memcpy them in.

To answer your main question, yes you still need to call the destructor because other stuff has to happen.

Is there any reason why this idea will not work in practice on any production compiler?

You had damn well be sure your C++ object fits within the size of the C object.

Does this technically violate the C++ language spec?

No, but not everything that is to spec will work like you want.

I understand that placement new calls are usually matched with explicit calls to the destructor. If I have no need for a destructor (no code to put there, and no member variables that have destructors) can I safely skip the explicit destructor call?

Yes. If I don't need to fly to New York before posting this answer, can I safely skip the trip? :) However, if the destructor is truly unneeded because it does nothing, then what harm is there in calling it?

If the compiler can figure out a destructor should be a no-op, I'd expect it to eliminate that call. If you don't write an explicit dtor, remember that your class still has a dtor, and the interesting case – here – is whether it is what the language calls trivial.

Solution: destroy previously constructed objects before constructing over them, even when you believe the dtor is a no-op.

I want to write C++ bindings for a C API. In the C API many objects are accessible only by pointer. Instead of creating a wrapper object that contains a single pointer (which is wasteful and semantically confusing). I want to use placement new to construct an object at the address of the C object.

This is the purpose of layout-compatible classes and reinterpret_cast. Include a static assert (e.g. Boost's macro, 0x static_assert, etc.) checking size and/or alignment, as you wish, for a short sanity check, but ultimately you have to know a bit of how your implementation lays out the classes. Most provide pragmas (or other implementation-specific mechanisms) to control this, if needed.

The easiest way is to contain the C struct within the C++ type:

// in C header
typedef struct {
  int n;
  //...
} C_A;
C_A* C_get_a();

// your C++
struct A {
  void blah(int n) {
    _data.num += n;
  }

  // convenience functions
  static A* from(C_A *p) {
    return reinterpret_cast<A*>(p);
  }
  static A const* from(C_A const *p) {
    return reinterpret_cast<A const*>(p);
  }

private:
  C_A _data;  // the only data member
};

void example() {
  A *p = A::from(C_get_a());
  p->blah(42);
}

I like to keep such conversions encapsulated, rather than strewing reinterpret_casts throughout, and more uniform (i.e. compare call-site for const and non-const), hence the convenience functions. It's also a bit harder to modify the class without noticing this type of use must still be supported.

Depending on the exact class, you might make the data member public.

The first question is: why don't you just use a cast? Then there's no issue of the placement new doing anything, and clearly no issue of failing to use a destructor. The result will work if the C and C++ types are layout compatible.

The second question is: what is the point? If you have no virtual functions, you're not using the constructor or destructor, the C++ class doesn't seem to offer any advantages over just using the C type: any methods you write should have been global functions anyhow.

The only advantage I can imagine is if you want to hide the C representation, you can overlay the C object with a class with all private members and use methods for access. Is that your purpose? [That's a reasonable thing to do I think]