Unnecessary overhead in placement new [ ]

[HPaulS]

With regard to the above, I can't think of a single good reason why the standard continues to say this (emphasis mine):

This overhead may be applied in all array new-expressions, including those referencing the library function operator new[](std​::​size_­t, void*) and other placement allocation functions.

Link: http://eel.is/c++draft/expr.new#15

Can this be changed?

[jwakely]

This doesn't sound like an editorial change.

[HPaulS]

Oh sorry, is that not what we're meant to be posting here? It was intended as a request to amend the standard but if such a request is inappropriate here then I will take it elsewhere.

....

Here's a link which I hope supplies a bit more rationale: https://stackoverflow.com/a/51362295/5743288

...

Interesting. Someone came up with a vaguely tenable reason, see:

https://stackoverflow.com/a/51358375/5743288

But still, adding this overhead does more harm than good, IMO, since it interferes in an undefined way with placement new [ ] behaving in a predicatable and programmer-friendly manner.

[jwakely]

See https://github.com/cplusplus/draft/wiki/How-to-tell-if-an-issue-is-editorial

[HPaulS]

@jwakely OK, thanks, I read it and I can see your point. So should I let this stand or should I report it all over again at https://isocpp.org/std/submit-issue, would you say? I'll do whatever you think is best.

Sorry about that other business, by the way. I was a bit gung-ho there.

[tkoeppe]

Please also browse the existing issues lists, e.g. http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#476.

It sounds like you need to send a paper to EWG if you want to make progress here.

[HPaulS]

OK, thanks for digging that up, useful to know. I'm not sure I have the energy to write a paper (and I'm not sure I'd call this 'evolution' anyway) so I might just leave it there and see if any of the standards guys pick up on this. That doesn't seem un reasonable to me, but we'll see.

[jwakely]

We are "the standard guys" but that doesn't make this the right place to report technical issues. This was already considered by the Evolution Working Group, see https://cplusplus.github.io/EWG/ewg-closed.html#90

Leaving this here isn't going to achieve anything, so let's close it.

[HPaulS]

Oh my, what a mess. In the link you gave (for which much thanks), I read (emphasis mine):

EWG thinks there's no design defect here, and suggests that a placement array new should not have such implementation-defined overhead. EWG suggests that CWG should clarify that placement array new T[n] needs n*sizeof(T) bytes of memory, and clarify that an operator delete must only be called if the corresponding operator new has been called.

That being a non-placement new, of course. So they agree with me, but they passed the buck to the CWG.

But in the link linked to from there (core issue 476, which has already been pointed out to me) we see, along with a lot of other irrelevant verbiage:

It has been suggested that this issue is more appropriate for EWG and should thus be closed with "extension" status.

Which, frankly, is a load of cr@p. Which I now agree with. But that's where the trail goes cold, return to sender. So that worked (!)

So where does that leave us? Is there a way I can reopen this because I'm not prepared to put any further effort into it. If that has no effect, fine, but at least I tried. And again, to be frank, I thought you were premature and a bit cavalier in closing it in the first place, no matter what your status. Thank you.

...

We are "the standard guys"

And there is more than one of you, I believe.

[tkoeppe]

@HPaulS: No matter the relevance of the problem, please bear in mind that this repository and this issue tracker are strictly for editorial work. Everything else here is distracting noise for the already-busy editors. There are better ways to report and discuss technical problems with the standard.

[HPaulS]

@tkoeppe I don't believe this is noise. Like I said, I've done all I'm prepared to do and I'm done with it.

[jwakely]

This is neither the place to report technical issues nor to discuss them. It was reported to CWG, who sent it to EWG, who said it's not their problem, and CWG never re-opened it. If you want to ask them to re-open it then this is the wrong place to do so.

[jwakely]

(The email address for the owner of the CWG issue list is given at the top of the issues list)

[HPaulS]

@jwakely Cool, thanks. I've done that (and referenced this thread, which I believe will continue to stick around). I didn't realise it was so easy, I owe you one. Have a great day.

[HPaulS]

Update: Well, of course, this needs to be reported to the EWG, not the CWG, silly me. Anyway, it seems that Thomas has been doing his best to get this fixed already (I guess he just forgot). I include below, just for completeness, a transcript of my email to the owner of the EWG closed issues list which references Thomas's (excellent) defect report. Cheers all.

---

Hi there,

As you are the owner of the EWG 'closed issues' list, I am writing in reference to this:

https://cplusplus.github.io/EWG/ewg-closed.html#68

Is there anything happening with this please? This is an important issue and it's just being swept under the carpet for some reason.

It was also reported again a bit later on, see:

https://cplusplus.github.io/EWG/ewg-closed.html#90

and:

http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_closed.html#476

So it got bounced around between the CWG and the EWG and then, I guess, it just got forgotten about. Nice.

So someone needs to stop saying ridiculous things like this:

In Chicago 2013, EWG deemed this NAD. Remarks from the discussion: "The problem is in trying to use array new to put an array into pre-existing storage. We don't need to use array new for that; just construct them." and "You can find what padding was used after the fact, because new returns a pointer to the start of the first element of the array. But that can happen only after UB. "

and get on and do the job properly. You can see there that Thomas is doing his best but noone appears to be listening to him.

My take on it here:

https://stackoverflow.com/a/51362295/5743288

Many thanks and best wishes - Paul Sanders.