Talk:C++/Archive 11

This is an archive of past discussions. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 5

←

Archive 9

Archive 10

Archive 11

Archive 12

A fraudulent article was written ...

About passage in Criticism section. I dont think this is even topical in this article. If Bjarne responded to that, than it has some notability, but i think that whole passage belongs in Bjarne Stroustrup rather than here. Ill drop this section soon. Kyle2^32-1 (talk) 18:50, 29 June 2010 (UTC)

It is entirely topical in conveying the perceived problems with C++ through satire. --Cybercobra (talk) 21:23, 29 June 2010 (UTC)

My sentiment is that its just an internet hoax, therefore not really a good source for criticisms or any opinions at all, as its main point was to impersonate someone and declare point of view different that person being impersonated (not raise some public concerns) - if Bjarne faq'ed this thing, than it becomes somewhat notable, but not really in scope of criticism of C++. Rather it may be viewed as sign of popularity of the language or its designer. Kyle2^32-1 (talk) 23:34, 29 June 2010 (UTC)

Hello world example has incorrect syntax

Currently, the "Hello world" example (cited to be from Bjarne Stroustrup's book) is as follows:

#include <iostream>
using namespace std;
int main()
{
  cout<< "Hello world";
  cin.get();cin.get()
  return 0
}

This seems to be clearly incorrect. There are missing semicolons after the second "cin.get()" and the "return 0". Also, there is no newline in the cout statement (either std::endl or "\n"). Is this really what's in The C++ Programming Language?

Fixed. Sebastian Garth (talk) 19:37, 4 August 2010 (UTC)

Low Res Image

Wouldn't it be better to have no image at all instead of the really fuzzy, low-res picture of the book we have? I mean, I understand why it has to be low-res. Just saying it'd look better without the image at all. --Sunoco (talk) 21:26, 26 August 2010 (UTC)

Does it even make sense to have a book cover image on a language page at all? It seems like an inappropriate image altogether. Furthermore, I'm not sure I would consider it a "seminal" work as it's more expository (at least in the third edition) of an already existing standard--which is seminal--rather than anything new, original, or "highly influential." Corwinoid (talk) 09:48, 30 January 2011 (UTC)

Threading support in Criticisms

Nitpick: the Criticisms section refers to the lack of support for threads in the C++ language and says that C++0x will add that language support. Technically speaking, the thread support will be provided by the standard library, and is not a part of the C++ language proper. I also have my doubts that all of the other languages listed have threading support in their language and not in libraries. Is this worth changing? 24.225.108.184 (talk) 02:45, 3 September 2010 (UTC)

No, standard library is part of the language, as it is specified in the standard. It is also one of the WG design decisions - 'dont put into language anything that can be done in the library' (more or less) Kyle2^32-1 (talk) 14:59, 26 September 2010 (UTC)

Right, according to your own statement, there is value in distinguishing between language features and library features. What would be the harm in clarifying that the C++0x threading support will come in the standard library and not the core language? 24.225.108.184 (talk) 18:37, 30 September 2010 (UTC) —Preceding unsigned comment added by 70.129.197.15 (talk)

No, according to the standard document itself (it does specify the standard library). C++0x will add support for threading. Thats it. Whether its added in standard library or as something else matters less. In your last comment you clarified that you meant 'core language' - now id agree with that, but 'core language' is vague in the context of this article, and casual readers wouldnt ever care (just my opinion). As far as i know this wont be library only extension anyways, as they add something to the core language (memory model), so it gets even trickier - why confuse readers? Kyle2^32-1 (talk) 19:29, 30 September 2010 (UTC)

How a canceled standard can be "still current"?

The article currently contains the following: "After years of development, the C++ programming language standard was ratified in 1998 as ISO/IEC 14882:1998. That standard is still current, but is amended by the 2003 technical corrigendum, ISO/IEC 14882:2003."

First, according to the official web page of the standardization working group for the programming language C++ http://www.open-std.org/jtc1/sc22/wg21/docs/standards, ISO/IEC 14882:2003 is a standard. Second, ISO/IEC 14882:2003(E) contains the following statement: "This second edition cancels and replaces the first edition (ISO/IEC 14882:1998), which has been technically revised". So how ISO/IEC 14882:1998 can be considered as "still current" standard? —Preceding unsigned comment added by 95.158.197.82 (talk) 00:06, 18 November 2010 (UTC)

Hmm, I think the current standard is C++/98, which is defined by ISO/IEC 14882:1998 replaced by the correcting spec ISO/IEC 14882:2003, that defines C++/98. Then ISO/IEC 14882:1998 is not a "still current" standard ~ I think the statements might be confusing spec labels with C++ versions. Rursus dixit. (^mbork³!) 09:56, 18 December 2010 (UTC)

C++0X

At the risk of incurring unpopularity for the work it will involve, can I suggest we start to look at the possibility of merging the C++ and C++0x artilces given that it is now the standard ? DominicConnor (talk) 16:30, 19 July 2011 (UTC)

me too and i think we should change the last stable release to C++11 which is the official name of the last release from http://www.cprogramming.com/c++11/c++11-auto-decltype-return-value-after-function.html Madooo12 (talk) 15:06, 1 September 2011 (UTC)

It appears that we already begin to include c++0x into the article (like laterst revision in infobox). This breaks some info (like 'manifest typing' also in the infobox). I think we should go ahead and treat this article as one about C++11 from now on (without cramming all the stuff from current C++0x article). 83.25.74.232 (talk) 20:56, 26 October 2011 (UTC)

Changes in the article related to C++11x

Now the new C++11 approved by ISO, We should change the article accordingly. For eg. "Language Standard" Paragraph contain the following sentence. The standard for the next version of the language (known informally as C++0x) is in development. 117.193.200.50 (talk)

Maybe related, in the info box it says

Stable release ISO/IEC 14882:2011 (2011)

Preview release C++11

It seems that the Preview release line should be removed.72.48.75.131 (talk) 21:53, 20 December 2011 (UTC)

Indent style for Curly Braces Languages

Curly Braces Languages

There was a dispute over the indent style in the C++ (and related) article. I've argued for consistency across WP, favoring the 1TBS style because that preserves vertical space the most.

Others preferred the K&R style. I've sinced stopped editing example source code sections since there is no consensus, and I'm tired of having my work reverted.

There was some discussion on C++ Coding Style Conventions, but a consensus had not been reached.

Am I allowed to perform these edits, or should I give in and leave the source code in varying styles? --Demonkoryu (talk) 09:46, 6 September 2011 (UTC)

Precedents exist on Wikipedia for other situations with varying conventions (such as regional conventions for English usage). Extrapolating from those precedents, such as MOS:ENGVAR, the important points are:

Maintain consistency within any particular article; i.e. pick a style for an article and stick with it.
Do not arbitrarily change any particular article from a self-consistent style already in use there. (MOS:RETAIN)

MOS:ENGVAR further suggests that the style of English appropriate to a particular article be used (MOS:TIES). I don't know how applicable this is to example source code layout, but the indent style article does suggest that certain styles are used with certain languages and/or coding projects more than others, so perhaps it may be possible to use 1TBS for C++, K&R or Allman for Java, etc. as suggested by historical usage.

(Note: I am not much of a programmer, so I have no real opinion on indent style itself; I'm just here via WP:FRS.) I hope this was helpful. —Darkwind (talk) 13:07, 6 September 2011 (UTC)

Very helpful, thanks for your comment.--Demonkoryu (talk) 13:27, 6 September 2011 (UTC)

With respect to the code example on this page, it is formatted as it appears in Stroustrup's book and there is a rather large comment block discussing why it shouldn't be changed:


<!--
***************************************************************
*
*                    PLEASE NOTE:
*
*  BEFORE MAKING CHANGES to the "Hello World" example
*  please establish consensus by discussing your proposed changes
*  on the Talk page. This is not the place to "Be Bold"; this
*  has been discussed before at length.
*
*  If you change the sample program without discussion, it will be
*  reverted within a few minutes.
*
*  Yes, you could say "using namespace std;" or "using std::cout;".
*  Yes, you could use "std::endl" rather than "\n".
*  Yes, you could add "return 0;" at the end.
*  Yes, you could add "int argc, char ** argv" to main.
*  Yes, your ancient compiler might require "#include <iostream.h>".
*  Yes, you could use "printf" from the Standard C Library.
*
*  But don't.
*
*  The latest consensus is ''not'' to make any of those changes.
*  This is the example "Hello, world!" by Bjarne Stroustrup,
*  the author of the C++ language, and is used in
*  his book, "The C++ Programming Language (3rd edition)".
*
***************************************************************
--><syntaxhighlight lang="cpp">
#include <iostream>

int main()
{
   std::cout << "Hello, world!\n";
}
</syntaxhighlight>

-- Autopilot (talk) 23:19, 6 September 2011 (UTC)

Precisely. The html comment above is beautifully written and explains the situation well. While consistency is good (and certainly should be enforced in any reasonably sized project), a Wikipedia-wide style guide for how different languages or different examples should be displayed is not helpful. It's very similar to WP:ENGVAR where (IMHO) part of the encyclopedia's role is to educate readers that different people are different, and "colour" is not always a horrific typo. Enforcing a style onto individual articles would cause disruption eventually (with needless conflict from those who maintain actual content in the affected articles and who will not necessarily accept an RfC on some talk page). Darkwind's above comment is perfect (consistency within an article; retain style). Johnuniq (talk) 03:31, 7 September 2011 (UTC)

So it seems that individual articles (exception above duly noted) can be edited for internal consistency.--Demonkoryu (talk) 07:20, 7 September 2011 (UTC)

Consistency within articles - There is no one, dominant convention for braces in C or C++. There are at least three, and they are probably equally favored across the programming population. It would be hard for WP to select one convention as the "mandatory" convention that must be used in all WP software articles, since many examples are probably cut-and-pasted from sources, and it would be unseemly to tamper with how the original source formatted it. Just as WP permits variants of English ("color" vs "colour") and dates (Aug 3, 2011 vs 3 Aug 2011) and so on: for curly braces, the best policy is simply to insist on consistency within individual articles. --Noleander (talk) 22:14, 8 September 2011 (UTC)

C++ standards

Do we need this huge table here? The info is great and all, but it feels (for me at least) that its not really fitting in this general article about the language. 83.25.74.232 (talk) 21:02, 26 October 2011 (UTC)

I think removing the non-C++ standards resolves any such concerns. --Cybercobra (talk) 03:17, 27 October 2011 (UTC)

Great job. Now its much less obtrusive. 83.25.86.207 (talk) 20:28, 27 October 2011 (UTC)

Hello World... again

#include <iostream>

using namespace std;

int main(){
   cout << "Hello, world!" << endl;
}

The "Hello, world!" syntax is very important, many newbies look at this syntax to decide whether or not this language would interest them. I understand that in The C++ Programming Language (3rd edition) that is what is read but, the majority of c++ user's do not follow by that syntax. They use this more modern approach. WheresTristan (talk) 01:42, 5 March 2012 (UTC)

^{[citation needed]} for this exact source code. --Cybercobra (talk) 02:06, 5 March 2012 (UTC)

using namespace std; is discouraged in the C++ faq along with other well known style guides (such as in the Google C++ Style Guide. It may be your preference, but you can do a quick search on Stack Overflow and you'll be hard pressed to find high-voted answers which recommend that style. [1]

std::endl is the same as '\n', except it flushes the buffer (which is not needed, the program is about to exit anyway). Using it when flushing the buffer isn't the intent (terminals are almost always line buffered) is also something that's usually discouraged. strcat (talk) 13:40, 5 March 2012 (UTC)

I believe that the program has been vandilized. It contains "using namespace std;", "system("pause");", poor indentation, etc. and it needs to be reverted to the original. I wish people would read the text that is right there above the program source... LB725C (talk) 17:21, 9 March 2012 (UTC)

Fixed. --Cybercobra (talk) 18:06, 9 March 2012 (UTC)

C++ FAQ vs FQA

Linking to the C++ FAQ without linking to the C++ FQA seems inconsistent, and seems to give this page a bit of a fanboy spin. No serious C++ programmer should be unaware of either of these documents. Mkcmkc (talk) 18:43, 8 March 2012 (UTC)

At the risk of sounding like a C++ fanboy myself, I really don't think the article should link to the C++ FQA without mentioning the controversy surrounding it as is has been critizised rather harshly (perhaps by other C++ fanboys) as containing many factual errors and editorial spin. E.g.

‘I guess it still lets a bitter taste for all the F.U.D. and misinformation wrapping the "germs of truth". Novice C++ developers or clueless managers can get caught in FQA web of lies, and then, guess who's trying to make things right?’ [2]

‘Classic strawmen such as complaining that overloading arithmetic overloads can be confusing if you dynamically create the return value with new (yosefk.com/c++fqa/operator.html#fqa-13.1) mean that the majority of the FQA should be treated with extreme caution.’ [3]

‘In fact the broad consensus is that the FQA is a lot of bullsh*t and angry screaming mixed with a few valid criticisms that are completely blown out of proportions. Not a good C++ resource. In particular, not one that offers any solutions or constructive criticism. Back in the days they used to call this “FAIL”.’ [4]

‘Don't get sucked in by the FQA troll. As usual he gets the facts wrong.’ [5]

‘And, if you're intelligent, after looking at the FQA you'll realize it's a hack job by somebody who doesn't really understand C++ but hates it anyway.’ [6]

‘Unfortunately, for every deficiency he gets right, he gets three more completely wrong...’ [7]

‘FQA turns in circles between snarkiness, half-truths and poor understandings of language features/goals. It often repeats same argument multiple times in multiple occasions.’ [8]

See also this discussion on comp.lang.c++.moderated and this (closed) question on stackoverflow.com. These quotations are from forum-like sources like reddit or stackoverflow or usenet and would not be fit to be used as sources in an article. And you will certainly find many people who praise the FQA. However, I think these quotations illustrate a not uncommon (and probably not unexpected) stance of C++ users against the FQA. — Tobias Bergemann (talk) 15:15, 9 March 2012 (UTC)

I forgot to say that I actually agree with most of the FQA, I just would want to make clear that it is not universally appreciated. — Tobias Bergemann (talk) 15:29, 9 March 2012 (UTC)

I don't disagree that the FQA is controversial to some, but it does seem to be notable and well-known. Even its detractors would probably expect a knowledgeable C++ programmer to be aware of it. Also, I would note that the FAQ itself has a fair amount of fluff and controversial commentary in it--it definitely espouses a point of view. Mkcmkc (talk) 17:22, 29 March 2012 (UTC)

External Link has bad link

The external links has a bad link to n3126.pdf – Working Draft, Standard for Programming Language C++ (21 August 2010; revises N3092) I tried to find a Webmaster link to report this. I do not have all the time in the world to search through non-relevant material. Wiki needs a simple, straight-forward way to report broken links, etc.192.88.94.254 (talk) 17:48, 11 April 2012 (UTC)

Just tried it; the link works for me. So... --Cybercobra (talk) 18:00, 11 April 2012 (UTC)

Memory Leaks

There should be some discussion of the memory leak problem which is solved by automatic garbage collection / managed memory in C# and Java, and addressed by smart pointers in later C++ standards. The original C++ programming style demanded that all new operations be balanced by deletes, which is error prone. C++ is also much more widely implemented than either C# or Objective C, though Java is also widely portable and favored on Android Redhanker (talk) 15:01, 24 May 2012 (UTC)

marketing

C++ is also used for hardware design, where the design is initially described in C++, then analyzed, architecturally constrained, and scheduled to create a register-transfer level hardware description language via high-level synthesis.[8]

How is this not blatant marketing? It's not like this is a major use case for C++. I'm sure PHP can be used for the same purpose as well. In fact, much saner things such as OCaml and Haskell have already been used for this purpose too. There are OCaml to Pic compilers, and Haskell has been used in the design of the SEL4 secure microkernel.

But you don't see the Haskell article saying: "Haskell is also used to formally specify the semantics of secure microkernels"... — Preceding unsigned comment added by 108.162.140.71 (talk) 00:20, 4 June 2012 (UTC)

Line breaks

Hi. I've noticed that you've reversed my edit on C++, where I introduced line breaks to the article's markup. The line breaks that were added don't have any influence on how the article is presented, which means that there is no visual change to the article. Yet, as the display of diffs is limited to the paragraphs in the markup code which have been altered, these innocuous line breaks significantly reduce the size of any diff of any subsequent change to the article. Hence, not only is the user presented with a concise summary of the changes, which in turn makes it simpler to read, but it also requires less data to be sent by wikipedia's servers. So, it's a win-win for all.

So, what about it? Can we agree to keep the line breaks in the article? Take care. -- Mecanismo | Talk 01:07, 26 June 2012 (UTC)

I reverted these two edits: diff and diff and have copied the above from my talk because this is not an issue to be decided between two editors.

Nearly all established articles use single-line paragraphs. I am not aware of a guideline to cover this situation, but there are plenty which strongly discourage people from going around and changing the established style of articles. Also, per WP:BRD, when an edit is reverted, please explain why the edit is needed on the article talk page and obtain consensus before repeating.

Re line breaks: You apparently like line breaks, but many don't, and whatever the merits of each side, my opinion is that some kind of central discussion should occur before embarking on a project to "fix" lots of articles. Apart from tidiness when editing (is there a line break here because the previous editor wanted a new paragraph but did not understand how wikitext works, or is there a line break because someone thinks it would be helpful for the servers?), it is easier to move single-line paras around without unintenionally leaving something behind. Diffs are difficult at times, but we live in hope that improved code on the servers will fix that (it is particularly irritating when someone adds or removes a blank line after a heading). Johnuniq (talk) 01:58, 26 June 2012 (UTC)

Discussion on introduction of Innocuous line breaks to reduce diffs

I've introduced some innocuous line breaks to the article in order to reduce the size of the diffs from subsequent editions to the article. These line breaks were added to the end of each sentence or to the end of template fields, which means that they don't have any impact on how the article is rendered. The only noticeable change is how diffs of subsequent editions are smaller, showing only tiny bits of text. In practice, these innocuous line breaks are a way to break the blocks of text shown in diffs.

Yet, although these line breaks don't have absolutely no impact on how the article (i.e., the content of the article stays the same and the way the article is represented does not change), User:Johnuniq reverted these edits claiming that this edition should not be accepted without consensus, pointing Wikipedia:BRD as the basis for his claim. So, with this in mind, to appease User:Johnuniq's refusal to accept an edit which introduces a line break after the end of a paragraph, does the wikipedia community accept that newline characters are added at the end of a sentence, or is this sort of edition too controversial to handle? Discuss.-- Mecanismo | Talk 02:01, 26 June 2012 (UTC)

I have merged your new comment with the section I had already placed here, probably due to two new sections being added at the same time. Johnuniq (talk) 02:06, 26 June 2012 (UTC)

This reformatting makes reading diffs that span the change impossible (did you even notice you stealth-reverted this edit?); this might be justifiable for something that improved the article, but isn't for something with no visible change. Besides, display of context is a good thing. I shouldn't have to flip back and forth between a diff and the article to see that an edit moved a sentence from one end of a paragraph to the other, instead of from one end of the article to the other. What's next, one word per line? 74.74.150.139 (talk) 02:23, 26 June 2012 (UTC)

Diffs include the previous paragraph, the paragraph with the change and the next paragraph. By adding line breaks, if a change is made then the reader will be presented with at least three paragraphs, which are more than enough to get the entire context of the change. Without these line changes, the user is presented with a huge blob of text which, in the case of this article, can easily span more than one page, and all this for a change which might even be tweaking a single typo. For example, with line breaks, the diff of this edition would only present a couple of lines, and instead it goes on for three pages. -- Mecanismo | Talk 09:37, 26 June 2012 (UTC)
Another advantage of adding these innocuous line breaks is when they are applied to citation templates. By adding line breaks at the end of each field, if a field in the citation is changed then the only thing that appears on the diff is the field itself, along with the preceding and succeeding paragraph. Without these line breaks, a whole blob of text filled with an entire paragraph, which in this article spans multiple pages, would needlessly be shown to the editor.-- Mecanismo | Talk 09:37, 26 June 2012 (UTC)
- No. Context-diffing is linewise—the two single lines preceding and following each edit are displayed. In the stable version, such as in the diff you link, that's a paragraph and a blank line on each side of the changed line. With these spurious linebreaks in place between each sentence and each template field, you're not even guaranteed to see the entire paragraph unless it's three sentences or fewer. Within a template, it looks like first hunk of this, which, while just barely acceptable for an infobox, would be intolerable in the middle of a citation template where you can't even see the text being cited. If you don't want to see the context, disable it with td.diff-context { display:none; } in your user css; don't impose the limitations of your small display size on the rest of us. 74.74.150.139 (talk) 11:53, 26 June 2012 (UTC)
  - You are arguing semantics. The word "paragraph" refers to a string of text included between two line break symbols. What has been said about the advantages of inserting innocuous line breaks to reduce the output of a diff doesn't change if the string between two line break symbols is referred by "paragraph" or "line". The fact is that adding innocuous line breaks to the text helps out the user by making the diffs clearer and easier to track, and also reduce the amount of data being sent by wikipedia's server, and there is no reason to oppose adding these line breaks to the text. -- Mecanismo | Talk 13:06, 26 June 2012 (UTC)
    - OK, if by "paragraph" what you really mean is "line", then no, two "paragraphs" of context is patently insufficient. Just describing your harmful, context-destroying, information-hiding linebreaks as innocuous over and over doesn't make them so. Your argument that diff text constitutes a non-vanishing percentage of Wikipedia's bandwidth is at best extremely dubious, and not our problem anyway. You haven't stated any valid advantages to changing from the status quo that I see, you don't have anyone agreeing with you, and I'm reverting. 74.74.150.139 (talk) 13:24, 26 June 2012 (UTC)
      - Context is not destroyed by a line break, and for you to suggest that it is patently clear that you don't know what you are talking about. Check the diffs of any edit before commenting on that particularly those which involve fixing typos in long blocks of text. -- Mecanismo | Talk 23:06, 26 June 2012 (UTC)

Your edit re-adds the promotional "powerful". Also, edit-warring as noted TEDickey (talk) 10:41, 26 June 2012 (UTC)

I have asked for comments at VPR. Discussion on the proposal should occur at VPR, and there is probably no need for further discussion at DRN. Johnuniq (talk) 23:45, 27 June 2012 (UTC)

No, the right solution here is to make the diff algorithm smarter, not add newlines to try to "help" it. Mark Hurd (talk) 07:03, 28 June 2012 (UTC)

The line breaks were reverted a few days ago, but in case it's needed, following is a summary of my attempts to get some discussion on this (not very successful).

At (1), Mecanismo supported line breaks, while Johnuniq and 74.74.150.139 opposed, and TEDickey made a somewhat ambivalent comment which seems to oppose the line breaks, as done. At (2), none supported line breaks, two opposed, and one made a comment which is not easy to unequivocally interpret, but which leans to oppose in my eyes. No one commented at (3). On this talk page, my comments dated "01:58, 26 June 2012" have had no reply, and an additional user (Mark Hurd) has opposed. There is no support for extra line breaks, apart from one editor. Johnuniq (talk) 04:53, 5 July 2012 (UTC)