Talk:Placement syntax

Untitled

An article on placement new is neccesary to support the article New_(C++). Before this placement new article, that "new" article was incomplete and inaccurate - for example in stating that "new" always allocated memory and that objects created by "new" were always on the heap.

Originally, I tried to have this article mirror the "new" article - and it was suggested that it be deleted because it was too much "how to". It has since been editted by myself and another (thank you Hans Adler) and is more descriptive with very little "how to" remaining. Scott Bowden (talk) 01:47, 25 November 2008 (UTC)

Vermeir's custom allocator code

The deallocation example sourced to Vermeir is wrong. The destructor should be explicitly called as well. But it's what the source says. Uncle G (talk) 21:46, 26 November 2008 (UTC)

Nominated for GA

Despite not having contributed significantly to the article, I have nominated it for GA, as I believe it to be of reasonable quality and feel comfortable with handling any issues that may come up at the review. decltype (talk) 08:59, 9 October 2009 (UTC)

I have reviewed the article and failed it for GA status at this time. Please see my comments on the review page. Thanks. SnottyWong talk 22:46, 14 November 2009 (UTC)

Arrays

A great page overall, but I think coverage of array allocation is not very good.

• The Expressions section doesn't mention new[] at all, yet the Function section refers to array new expressions, as if the reader already knew what they were.
• The Custom allocators section should mention how to allocate arrays (or mention that it cannot be done and explain why). I believe it can't be done, because the new[] expression may return a different value from what the new[] function returned, so there is no way to deallocate the array when there is no delete expression.

Chris D Heath (talk) 18:40, 26 August 2010 (UTC)

{notinsource}

User:Uncle G noted that reference to third edition of Stroustrup's 'The C++ Programming Language' (in History section) doesn't contain information that certain technique is not mentioned there. IMHO it is an interesting case: on one hand, it is possible to argue that the book itself contains enough information that certain thing is not mentioned (it is verifiable); on the other hand, it is possible to argue that this fact itself qualifies as WP:OR. IMHO, it can be relatively easy argued both ways, therefore the question: are there any guidelines on this relatively subtle case? IMHO, mentioning that this technique is deprecated/abolished is relevant to the article (and the fact that it has been mentioned in 2nd edition of the most important book on C++ and has been dropped in 3rd edition is relevant too), but what proof can be potentially provided for something not being mentioned? Ipsign (talk) 11:05, 27 October 2010 (UTC)

• The main problem is that the content isn't really accurate in the first place. That's why it's so hard to source. ☺ The deprecation of assignment to this was not synchronized to edition numbers of TCPPPL. Uncle G (talk) 12:50, 27 October 2010 (UTC)

  sure it wasn't synchronized, but I hope such synchronization is not implied by current wording; absence of reference in 3rd edition has been used only to prove the point that it was abolished at least at that time (which is true); sure, I will not object if somebody finds better proof, but I myself don't have anything better :-(, on the other hand, IMHO this information (that such a thing did exist in the past, but is obsolete now) is still valuable (and factually accurate); if there is some better wording to convey this thought - I certainly won't have any objections, but myself I can't find such better wording now :-(. Ipsign (talk) 13:05, 27 October 2010 (UTC)

  After some further thought, I've removed this reference as potentially confusing for the reader. Suggestions for better wording are certainly welcome. Ipsign (talk) 18:46, 28 October 2010 (UTC)

On circa 1995 in History

While I cannot provide references right away, I know where to look for them, which might be useful for improving the article: in MSVC++ v1.5 placement new was not supported, in MSVC++ v4.0 it was supported for sure; GCC has had similar timing, though I don't know exact version numbers. I'm sure relevant references can be easily found in appropriate manuals, unfortunately, I currently don't have access to them. Ipsign (talk) 11:13, 27 October 2010 (UTC)

• You should obtain some such access, because when you do you'll find that "circa 1995" is wrong by several years in some cases. ☺ Uncle G (talk) 17:36, 27 October 2010 (UTC)

  That's why I've wrote it as circa 1995 (which as far as I understand, means exactly "within several years from 1995") for the time being. As I see it, current wording is better than nothing, and if/when somebody can find more data - it certainly can become better. Ipsign (talk) 01:08, 28 October 2010 (UTC)

regarding revert by Uncle G

This is not the case of notable historic material. All compilers had flaky C++ support at some time and all compilers have had some compiler specific extensions. However, this g++ syntax was not feature, but a bug, due to that this syntax was not alternative, but a replacement for the one mandated by the standard (and not used at all also). So I consider this almost perfect example of WP:CHERRY.

Object on the grounds of WP:NTEMP, will revert. My reading of WP:NTEMP is that any arguments along the lines of "not notable anymore" shouldn't fly. If it was notable in C++ world back there, it should stay (per WP:NTEMP), if it wasn't - this is a different story, but your argument wasn't challenging it "back there" (sure, feel free to challenge it now - but it will be a different line of argument, with different counter-arguments). Ipsign (talk) 16:31, 7 December 2010 (UTC)

So you suggest wikipedia should become an archive of bug reports and historical feature list something like this, this and this? And that particular bug we're taking about was not in any way notable in C++. Also, WP:NTEMP does not apply here as a minor bug in software is not an event. WP:NTEMP would apply if someone expressed criticism on the lack of features (as that's an event with easily measurable coverage).1exec1 (talk) 20:43, 7 December 2010 (UTC)

No, I don't (BTW, your phrase "So you suggest..." certainly qualifies as WP:OR). As I understand it, criteria for inclusion to Wikipedia are based on reliable 3rd-party coverage, so if somebody took effort to write an article about certain fact (and article got published later by independent body), or to include certain fact to a book (which again got published by independent publisher), the fact can be included (subject to a few other policies, which seem irrelevant here). In this specific case, if the provided source would be of better quality, I'd revert your edit again, but on the grounds that the source certainly looks like WP:SPS, I'll leave it removed for now, but if somebody (UncleG?) can provide better reference (from reputable journal or book), I'll be all for re-instating it. Ipsign (talk) 05:08, 8 December 2010 (UTC)

placement new on "const void*" memory?

Is that supported? i.e. create a 'const uint32_t' on a (properly alignend) read-only memory position that is denoted by a 'const char*' or 'const void*' pointer? --RokerHRO (talk) 14:22, 17 August 2011 (UTC)

No. Placement new calls the constructor of the object, so the area is potentially modified, thus const void* can not be passed to the placement operator.1exec1 (talk) 00:57, 23 August 2011 (UTC)

Okay. In my examples I just had an 'const char*' pointing to a buffer and I want to place a POD struct on it, so I thought “placement new” is cleaner than reinterpret_cast<…>. :-/ --RokerHRO (talk) 10:43, 24 August 2011 (UTC)

Static linkage?

Can somebody explain the following text: "For both the new and the delete functions, the functions are global, are not in any namespace, and do not have static linkage."

I assume that the intention was to say that the new-function resides in libstdc++, and thus is typically linked at run time. However, the standard library *can* be linked statically afaik. I don't think that linkage options is specified in the language, so it seems a bit strange to include on a language page. Furthermore, most people reading this page will compare with the regular new syntax, so I interpret all information "as opposed to regular new" unless stated otherwise. — Preceding unsigned comment added by 81.233.172.137 (talk) 12:26, 23 November 2013 (UTC)

Out of date content?

Modern versions of the C++ standard have added sized dealocator, used automatically by the compiler when the type size of a delete is known at compile time. This conflicts to some extent with placement dealocator as it reserves some declarations. — Preceding unsigned comment added by 31.53.220.42 (talk) 17:27, 28 July 2016 (UTC)