Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unnecessary overhead in placement new [ ] #2264

Closed
HPaulS opened this issue Jul 16, 2018 · 35 comments
Closed

Unnecessary overhead in placement new [ ] #2264

HPaulS opened this issue Jul 16, 2018 · 35 comments

Comments

@HPaulS
Copy link

HPaulS commented Jul 16, 2018

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
Copy link
Member

jwakely commented Jul 16, 2018

This doesn't sound like an editorial change.

@HPaulS
Copy link
Author

HPaulS commented Jul 16, 2018

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
Copy link
Member

jwakely commented Jul 16, 2018

@HPaulS
Copy link
Author

HPaulS commented Jul 16, 2018

@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
Copy link
Contributor

tkoeppe commented Jul 16, 2018

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
Copy link
Author

HPaulS commented Jul 16, 2018

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
Copy link
Member

jwakely commented Jul 16, 2018

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.

@jwakely jwakely closed this as completed Jul 16, 2018
@HPaulS
Copy link
Author

HPaulS commented Jul 16, 2018

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
Copy link
Contributor

tkoeppe commented Jul 16, 2018

@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
Copy link
Author

HPaulS commented Jul 16, 2018

@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
Copy link
Member

jwakely commented Jul 16, 2018

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
Copy link
Member

jwakely commented Jul 16, 2018

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

@HPaulS
Copy link
Author

HPaulS commented Jul 16, 2018

@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
Copy link
Author

HPaulS commented Jul 17, 2018

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.

@FrankHB
Copy link
Contributor

FrankHB commented Jul 17, 2018

You may better discuss it at std-discussion.

@tkoeppe
Copy link
Contributor

tkoeppe commented Jul 17, 2018

@HPaulS: I hadn't forgotten, but I also wasn't able to find the issue for some reason. Thanks for digging that one up. That was my first involvement with the standardization process as far as I can remember; I thought that feature can't possibly make sense, why don't we just fix that...

@HPaulS
Copy link
Author

HPaulS commented Jul 17, 2018

OK, Thomas. And sorry Frank, I do know about that list but I'm not prepared to get involved in any sort of extended discussion about this as I believe I already said. Thomas already poured his heart and soul into this back in the day and it got him nowhere. And the guys here are trying to keep the noise down.

@tkoeppe
Copy link
Contributor

tkoeppe commented Jul 17, 2018

Well, as an Editor I'm also one of the guys who want to keep the noise down :-) But I could try and ask around if we still agree with the assessment from back then. I believe the CWG's position at the time was that while the standard placement-array-new doesn't require an overhead, there may be overloads that do, and CWG were reluctant to change only one particular part of this feature ad-hoc. They preferred if EWG looked at the entire feature holistically. I'm sympathetic to that sentiment, and I think the best way would be an EWG paper. It wouldn't need to be long, but a paper can always be listened to, whereas issues may not end up progressing if there's no clear agreement on direction.

So, in summary, I think the problem is real, the issues lists aren't sufficient to address this, a paper is needed, and this is not the right place for that work. The std-* mailing lists are a good place to start if you want to get involved, but without someone driving this I don't expect anything will happen, and most people who are already busy with standards work probably have more urgent things they want to get done.

@jwakely
Copy link
Member

jwakely commented Jul 17, 2018

Right, if you think it's important you need to work on it, not just tell other people to work on it because you think it's important. That's not how these things get done.

And the stackoverflow question seems a better place for updates, it really doesn't belong here.

@HPaulS
Copy link
Author

HPaulS commented Jul 17, 2018

@ALL of you. As I believe I mentioned, I emailed the guy who manages the EWG closed issue list and I (obviously) don't seek to prolong any discussion of the matter here. I just posted my email here for reference, just in case anyone (e.g. you, Thomas) was interested. What happens is out of my hands now. I think I said that, too.

And, if you read that email (which I posted, remember, for reference), you will see that I linked directly to Thomas's paper, which, IMO, sums up the problem nicely (and certainly far better than I ever could). One thing's for sure: we certainly don't need another one. So, I say again, I see no need for any of us to do any more, and most certainly not in this thread. Que sera sera, I'm losing interest. Thank you.

OK, one thing:

Don't get bogged down in the detail Thomas. Take it from me, placement new [ ] doesn't need that overhead. You know it, and I know it. The problem is convincing the committee, and you already did your best to do that a while back. Let it go brother, let it go. I already shook the tree with that email, so, we'll see.

And, FWIW: My 'trying keep the noise down' rider was (obliquely) aimed at Frank, not you. I didn't think his comment really contributed anything. Perhaps I shouldn't have.

@jwakely "Right, if you think it's important..." Don't be daft! I have no idea what you're trying to say to me there.

@HPaulS
Copy link
Author

HPaulS commented Jul 18, 2018

I thought that feature can't possibly make sense, why don't we just fix that...

Sorry Thomas, what was I thinking? Yes, my thoughts exactly.

Sorry about that - Paul.

@HPaulS
Copy link
Author

HPaulS commented Jul 18, 2018

@jwakely

First you posted this:

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.

And then you waited a few minutes, and then you posted this:

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

You know, I just have to stand back and admire your technique there, you got me all ways up. You are a master of your craft. It's probably happening all over but please don't do it to me again, ever. You are not a nice man, and you have blown your cover.

See also: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86130

With best regards to the list and apologies for the 'noise',

Paul Sanders
AlpineSoft


Oh yes, I nearly forgot. I got a 'response' from the owner of the CWG closed issues list, even though I took the time and trouble to let him know that I had referred the matter to the EWG and please not to bother. That was a windup too. Do you two happen to know each other by any chance?

@jwakely
Copy link
Member

jwakely commented Jul 18, 2018

I have no idea what you're on about. I suggested you ask CWG to reopen the issue, then realised that it would be helpful to let you know how to do that, pointing you to the email address. I don't understand your problem with that, but I also don't care. I'm muting this thread now, so I don't see any more of your twaddle.

@HPaulS
Copy link
Author

HPaulS commented Jul 18, 2018

No worries. Absolute power corrupts, absolutely.

@dhouck
Copy link

dhouck commented Jul 18, 2018 via email

@HPaulS
Copy link
Author

HPaulS commented Jul 19, 2018

This is just bullsh!t. And I thought this thread had been muted.

@zygoloid
Copy link
Member

@HPaulS I appreciate that this may be frustrating you. However, your choice of language and hostility towards others in this thread is unacceptable. Please conduct yourself with professionalism, or I will block you from commenting here further.

@HPaulS
Copy link
Author

HPaulS commented Jul 20, 2018

OK, maybe I was a bit out of line there, but Thomas has done all the legwork and nobody seems to be listening. Just for those who don't remember the link, it's here:

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

And that's all I have to say, because the actions of Jonathan and the owners of the two closed issue lists say clearly to me that this process is all just a cesspit and I am sick to the back teeth with it. Those three can go do what the hell they like.

@villevoutilainen
Copy link
Member

Funny, the owners of the two closed issue lists agreed to reopen the matter.

@HPaulS
Copy link
Author

HPaulS commented Jul 27, 2018

@ville Cool, thanks for the heads-up. Nice one guys, hats off. I'm pleased to have been proved wrong. Yet again :) Good luck with it all, see you around.

@jwakely
Copy link
Member

jwakely commented Jul 27, 2018

Your latest rants have been brought to my attention, and I'd continue to ignore you but for ...

And I thought this thread had been muted.

I muted it for me so I don't get email updates and I don't have to read your displays of personality defects and attitude problems. I didn't lock the thread or prevent you or anybody else from participating, although I see you're getting close to achieving that without my help.

@villevoutilainen
Copy link
Member

Well, you were proven wrong over 8 days ago, but chose to comment the way you commented anyway.

@HPaulS
Copy link
Author

HPaulS commented Jul 27, 2018

@ville Seems so, apologies. Anyway, what matters is getting the right result, no? I'm very pleased that this issue has been re-opened and I'm looking forward to the two working groups thrashing it out properly as they should have done several years ago.

@HPaulS
Copy link
Author

HPaulS commented Jul 27, 2018

@jwakely Is it just me that you seem to like to vent your spleen on, or is it everyone? Whatever it is it's not very nice, so please just cut it out. Thx.

@jfbastien
Copy link
Contributor

I think it's just you. 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

8 participants