Jump to content

Talk:C++/Archive 7

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
Archive 1Archive 5Archive 6Archive 7Archive 8Archive 9Archive 10

Standards compliance - compilers who support export keyword

this site and this one seem to be a good reason to add Intel's C++ Compiler to the collection of compilers supporting the export keyword. The former link means that Intel is also using the EDG frontend. —Preceding unsigned comment added by 217.80.125.57 (talk) 18:18, August 24, 2007 (UTC)

This article has been reviewed as part of Wikipedia:WikiProject Good articles/Project quality task force. I question the quality of this article based on the Good article criteria. For that reason, I have listed the article at Good article review. Issues needing to be address are listed there. Regards, T Rex | talk 21:05, 29 August 2007 (UTC)

The result of the review was to Delist the article. An archive of the discussion can be found here. Based on comments in the review, I have added some {{fact}} tags to help any future editors. Drewcifer 22:29, 8 September 2007 (UTC)

Ownership?

Is C++ currently or in the past owned, licensed, or public domain? Whether the answer is obvious to programmers or not, it might be worth including along with a response to the claim by an official SCO Group spokesman that SCO owns C++ See http://www.groklaw.net/quotes/showperson.phtml?pid=12 Carltonh 00:06, 6 September 2007 (UTC)

We already state that C++ is royalty-free. --Yamla 00:25, 6 September 2007 (UTC)
So perhaps that should/could be expanded documentating the royalty free status, along with mentioning the (perhaps one time only?) claim by SCO to owning C++. If no other or more recent claims by SCO are known, then it could be noted that they have not addressed or defended the ownership claim or provided further evidence or legal threats. Given SCO's fame at making broad IP ownership claims, I think it is noteworthy, even if the claim was baseless. Carltonh 17:15, 6 September 2007 (UTC)
This isn't journalism. Any fraud could make claims to C++ being under their ownership if they wanted; if there's nothing to the claim, and it isn't making particularly much noise news-wise, there's no reason we need cover it. Chris Cunningham 17:37, 6 September 2007 (UTC)
There is a subtle difference between C++ the language, C++ the trademark (if any), and a given C++ implementation.
  • C++ the language is, as far as I know, PD. Protecting a language design as such will be hard to impossible - at best|worst one might get a patent on it. Note how gcc implements C#.
  • I'm not aware that C++ is used as a trademark by anyone. That is, however, how Sun protects Java (you can create both variants and clones, but you cannot call non-compatible versions Java).
  • The original implementation of C++ may well have belonged to ATT at one time, and ended up wherever UNIX copyrights (if any) are now. On the other hand, since its not really part of UNIX, the rights (if any) may have ended up somewhere else. Since no-one uses that implementation and there are a number of independent ones (g++, Visual C++, Borland C++, Dinkumware C++...), this is more ore less irrelevant.
--Stephan Schulz 17:56, 6 September 2007 (UTC)

Far too much discussion of OO minutae

This seems to plague programming articles on Wikipedia. We're not looking to provide expert critique on C++'s OO features; we simply have to illustrate them, along with some notes on their defining characteristics. The article goes into a huge amount of detail on this subject which may or may not be sourced but certainly isn't productive to making a great article. We should work to first remove any commentary and then start removing less interesting or directly notable assertions from the text. It certainly shouldn't make up 50% of the article length and 80% of the table of contents. Chris Cunningham 15:23, 1 October 2007 (UTC)

I fully agree. How about we start with those tables of operators? They seem totally out of place for a wikipedia article, are available in many other places and add a lot of length to the article. As usual, if no one protest, I will remove these in a week or so. Esben 14:57, 15 October 2007 (UTC)
I have shorted operators to 5 lines. I think it is better now, other opinions are welcome around here. Esben 20:42, 25 October 2007 (UTC)
Sounds good. Sheffield Steeltalkstalk 20:01, 15 October 2007 (UTC)
I think this has some merit. I'll watch for your changes. I also have a copy of Stroustrup's "The C++ Language", so I might be able to help with sourcing once we trim it. ATren 00:50, 18 October 2007 (UTC)
Now that operators no longer take up half the article, my eye falls on the pre-processor bit. It is a fairly in-depth piece. Is the pre-processor even worth more than a mention? The details is available in the C article, and using the preprocessor has grown infrequent outside of the inclusion/conditional compilation. Certainly, it is less interesting than say operators ;) Esben 20:47, 25 October 2007 (UTC)

Cast operators: do we need them?

Not as programmers, obviously. They're very useful. In the context of this article, however, I'm not sure that they are worth the space. I think that this section could be trimmed down a good deal or removed altogether. What does everyone else think? Sheffield Steeltalkstalk 21:13, 27 November 2007 (UTC)

Btw. cast's section is severly broken in that (among other thing) it provides erronous information (eg static_cast) on the behavior of cast's in various places, other times it just doesnt make sense (dynamic_cast - "return type is NULL(0)") and in few other uses dreaded hungarian notation ... in current shape it would be better if it dissapeared entirely from the article —Preceding unsigned comment added by 83.25.99.170 (talk) 01:08, 21 December 2007 (UTC)

Deletion of citation needed for "++"being the increment operator

It seems a bit silly to ask for a citation for this fact. "++" is the increment operator, and anyone who uses C++ should know this. —Preceding unsigned comment added by 146.245.190.185 (talk) 16:19, 29 November 2007 (UTC)

Yes, but as C++ has more than just classes, we need a citation for the "one more thing" bit. --Yamla (talk) 16:22, 29 November 2007 (UTC)


Hello world example

Should the hello world example given not at least return an int from the main() function, and possibly also take the argc and argv arguments? The C++ standard states that the main method should return an int and the function declaration says it will, but at the end it doesn't. Surely this should not compile on a standards compliant compiler. 62.254.246.40 15:14, 4 December 2007 (UTC)

No. In the main function (and only the main function), you do not need to specify a return value. Check the comments, this version of Hello, World comes straight from Stroustrup. The C++ standards document is verbose and confusing. --Yamla 15:38, 4 December 2007 (UTC)
I think there should be a return value even in Stroustrups example doesent have it. Its good practice and is in the ISO C++ standard... And no, it doesent compile on a standard compliant compiler. MihaS (talk) 01:51, 16 December 2007 (UTC)
The C++ standard, 3.6.1, paragraph 5 clearly states that main implicitly returns 0 if it control reaches the end of main and it hasn't returned a value. Very few of the example main functions in the standard explicitly return a value. The code's lack of return statement is standard compliant. Whether or not it is "best practice" and whether or not the code has to follow best practices is debatable at best. The Hello World without a return value is how the language creator specified it, and it's guaranteed by the standard to work, so I suggest that we leave it as it is and cease this discussion. Krelborne (talk) 22:41, 1 January 2008 (UTC)

I've mentioned this in the mini-FAQ (without going into exact detail). SHEFFIELDSTEELTALK 16:49, 17 May 2008 (UTC)

"Mid-level language"

Isn't it strange how defenitions change over time? Now just because Java needs an ad, we are redefining what C is, except neither C, nor the platform it runs on has changed. C is the very defenition of a high level language. Always was. The fact that most other high level programming languages have hardcoded memory allocation procedures changes nothing. C is no mid-level language, it's high level. --89.212.75.6 (talk) 14:31, 27 December 2007 (UTC)

That's what the "is regarded as" qualifier is there for. "the very definition of a high level programming language" has indeed shifted since the 70s; mid-level is a useful neologism for C and C++ in a language landscape where the only thing written to run on bare iron these days is new GCC ports. Chris Cunningham (talk) 14:53, 27 December 2007 (UTC)
Depends against what you compare C/C++ with - I for once never considered C/C++ true high level languages. Mainly because I have learned Basic, Assembler, Pascal and PL/1 before learning C/C++ (and Ada afterwards) - and hence my expectation on how much abstraction a "high level" language should provide is different. Most notably: A true high level should have two separate abstractions for "arrays" and "references" and pointer arithmetic should not be a means of optimising performance - a true high level language should have an optimizer for that. Note that Ada, a true high level language in my book, still has pointer arithmetic - but the only place I ever used it is function called Trace.Memory_Dump. --Krischik T 09:47, 11 February 2008 (UTC)
The preceding comment illustrates well why I find the "midlevel" thing silly. It is just a way to say someone's pet feature is missing. I could claim that no language without a working lambda calculus and closures is not a true highlevel language since it does not provide abstraction enough; likewise a C++-loving person could claim that no language is highlevel without full, multiple inheritance for the same reason. So in conclusion, let's dump this silly marketingspeak and agree that the entire high/lowlevel language terminology is useless today, except perhaps for a very few specialized areas. Esben (talk) 07:48, 12 February 2008 (UTC)

Another "hello world" program

Is it really necesary for us to have another hello world program ? I will remove this part of article if there is no one to disagree here - second hellow wolrd does not illustrate anything of interest. It also implies that global 'using namespace ...' is 'a good thing' in large programs ... 83.25.134.131 (talk) 13:52, 6 January 2008 (UTC)

and so i have removed said paragraph 83.25.88.147 (talk) 16:21, 6 January 2008 (UTC)

Criticism of current criticism

The "criticism" section contains some bad quality criticism, based on misunderstandings, while there is an entire criticism of C++ article! Shouldn't instead a few of the serious criticisms be in the "criticism" section, such as:

  • ambiguous definition of templates, and
  • no definition of virtual table behavior, so that one compiler can easily instantiate classes in threads, while doing the same in another compiler is like asking for a crash to occur.

Said: Rursus 14:29, 10 January 2008 (UTC)

Feel free to prune it back as much as you want, dumping the cuttings on the criticism page. "Criticism" and "controversy" pages on WP are part of the natural development of articles; firstly, someone adds a list of kvetches to the main article, then it is split off into its own POV fork, balloons into a complete mess (with a concise, but much better summary in the main article), and then the fork loses an AfD and is deleted, leaving only the most pertinent and well-summarised criticism. Chris Cunningham (talk) 14:52, 10 January 2008 (UTC)

Move out the criticisims and stick to language info

This article is becoming unbalanced. Too much is given to criticism and not enough to plain old language explanation.

Can we move all criticisims to the article set up for that ? I would include "Problems and controversies" and "Incompatibilities with C" . All are valid areas of interest to the reader and with C++ being a quarter of a century old, its faults are well understood. In addition, the criticisms area is the bit most likely to generate discussion and edits. Best to move all subjective comments to that area and leave this as a useful in-depth "language explanation".

Certainly this should NOT be combined with the criticisms article as it would then become almsot useless.

Default arguments

I have read this statement a number of times: <<Default arguments are used when defining a different function is not needed when supplying a default value for an argument will suffice.>> and have been roundly unsuccessful in divining its meaning. Is there some punctuation missing? ... or some words missing?... or even some extra words that shouldn't be there? 70.167.95.230 (talk) 17:37, 21 February 2008 (UTC)

Request for the citation of the validation report on ISO/IEC 14882

Since the ISO/IEC 14882:2003 - Programming languages -- C++ is not free of charge, I downloaded a copy from

http://www.usatlas.bnl.gov/~dladams/cpp/INCITS+ISO+IEC+14882-2003.pdf

whether it is accurate or not, it's another issue

In section 3.9.2.2 under 3.9.2 Compound types, it methions the methods of constructing types and I wish to see the validation report on these methods —Preceding unsigned comment added by 64.62.138.95 (talk) 08:20, 24 February 2008 (UTC)

Article talk pages are to be used to improve the article. What you are asking seems to have nothing to do with this. --Yamla (talk) 15:35, 24 February 2008 (UTC)

C++ info box and the Perl info box, unclear.

Noticed in the info box located in the upper right most corner of the C++ wikipage and Perl wikipage, it says for C++ that it was influenced by Perl, and Perl says it was influenced by C++. Also, the C++ influenced box does not include Perl, and Perl influenced box does not include C++. Is this intentional for a reason I fail to understand?


Shadowb170 (talk) 02:29, 27 February 2008 (UTC)

C Double Plus

I have heard C++ pronounced "C double plus" by several people. It may be worth listing this as an unofficial alternate pronunciation in the article. Trey (talk) 17:43, 16 April 2008 (UTC)

We do not normally list mispronunciations. "C double plus" is blatantly wrong and not, as far as I am aware, widespread. But if you can find a reliable source, it may be worth considering. --Yamla (talk) 18:02, 16 April 2008 (UTC)


code highlighting

anyone know where can i fix rules for highlighting code ? or is it not accessible ? current snippets seem kinda broken wrt highlighting (like static_cast is not'keyworded' and malloc is, int* doesnt get coloured) ... its ugly imo ... 83.25.87.215 (talk) 21:45, 23 April 2008 (UTC)

This page is for discussing the article on the programming language, C++. Your question is unrelated to the article. --Yamla (talk) 21:51, 23 April 2008 (UTC)
it is related ... in a sense that having broken said highlight rules affects quality of this article ... 83.25.87.215 (talk) 22:02, 23 April 2008 (UTC)
Ah ha, I thought you meant in Visual Studio or something. You are right, it is related. My apologies. --Yamla (talk) 22:15, 23 April 2008 (UTC)

Meh, no offence taken anyways ;) I did some research and it seems wer stuck with this however. Syntax highlight seems to be done with this http://www.mediawiki.org/wiki/Extension:SyntaxHighlight_GeSHi and im pretty sure that normal users wont be allowed to touch wiki engine on php level 83.25.87.215 (talk) 23:47, 23 April 2008 (UTC)

method vs member function

As there is no such thing as 'methods' in C++ i propose to %s/method/member function/g

This however may affect badly 'virtual member functions' section as 'method' is used quite often there and such substitution may bloat said section too much, what you think guys ? 83.25.101.121 (talk) 17:27, 30 April 2008 (UTC)

Method is used to mean virtual member function. It may be worth replacing other uses of the term, but on an individual basis, not automatically. SHEFFIELDSTEELTALK 19:09, 30 April 2008 (UTC)
Yeah, its easy to deduce what is ment by 'method'. My proposition is based on the fact that 'method' with this meaning is not defined in ISO C++ standard - 'member function' is. Perhaps i want too much formalism, and of course i ment manual substituion ;) 83.25.101.121 (talk) 20:02, 30 April 2008 (UTC)
I was bold and did the replacing. I deliberately left a couple of "method"s behind; they really do refer to virtual member functions. I also got rid of one "virtual member method". Thanks for pointing this out! SHEFFIELDSTEELTALK 20:03, 30 April 2008 (UTC)

language size

Criticism section tries to make a point that modern language are more complex then older ones. While its quite understandable in C -> C++ case, using standard document size to suggest that C# is more complex than C++ is a bit strange to me. Whole concept of comparing complexity of languages based on size of standard relies on the format of both documents (and in the case of C++ and C#, content differs quite significantly in that C# standard often includes some kind of explanations and rationale wihich are absent in C++ standard document). Soooo, ill drop 'Furthermore, C#'s ECMA language definition document is about 440 pages.' from criticism section if no one objects. 83.25.69.42 (talk) 10:56, 1 May 2008 (UTC)

c lang infobox

so theres an c language infobox in the bottom of the page

whats C# doing there ? 83.25.74.218 (talk) 11:38, 3 May 2008 (UTC)

thinking more about it, it seems to me that this infobox doesnt fit here at all, as it mentions features which one would want to avoid in C++ like C strings, or some C library implementations. Perhaps we should drop it from here? 83.25.72.21 (talk) 16:48, 18 May 2008 (UTC)

Yes, that infobox should go away. It doesn't fit better here than, say, a Java or C# infobox would. I'm removing it now. JöG (talk) 18:17, 26 August 2008 (UTC)

Incompatibility with C

This section is a bit of a mess. It's not well sourced and I don't think it really covers the differences well. The precedence of the ternary operator certainly doesn't deserve the space it's being given. I should be able to take care of this in a day or two when I can get to a copy of Stroustrup, but if anyone wants to help in the meanwhile, go ahead. SHEFFIELDSTEELTALK 18:06, 18 May 2008 (UTC)

just a suggestion, but perhaps we could drop this secton alltogether (or move to http://en.wikipedia.org/wiki/Compatibility_of_C_and_C%2B%2B)? 83.25.72.21 (talk) 19:19, 18 May 2008 (UTC)

It's also a bit misleading, because much of the point with C++ is that it is mostly C compatible. There's no dedicated section about that. JöG (talk) 18:22, 26 August 2008 (UTC)

citation needed

there are a few places with 'citation needed', 2 of 4 i find not really informative and of questionable value:

 , since classes are "one more thing" than C had[citation needed]
He never thought that it would become the formal name of the language.[citation needed]

ive never read / heard that any of these two was the case and as they dont provide any usefull information ill remove them if no one objects 83.25.68.209 (talk) 17:02, 20 May 2008 (UTC)

Yet another Hello World complaint

Although correct in current form, wouldnt std::cout << "Hello World" << std::endl; be better form? (current is std::cout << "Hello World!\n";) 84.251.133.33 (talk) 21:26, 4 July 2008 (UTC)


ok. i feel like fool now. nevermind... 84.251.133.33 (talk) 21:32, 4 July 2008 (UTC)

Spam?

86.129.18.179 and/or Sentense12 have posted a link to http://www.stlsoft.org, which redirects to http://synesis.com.au/software/stlsoft/, a site which contains a prominent Amazon book sales link (including referral information). What's the consensus of editors here? Is STLSoft a notable extension or addition to C++ which should be mentioned in the article? Should the article include an external link to this particular website? SHEFFIELDSTEELTALK 21:21, 14 July 2008 (UTC)

well, its notation puzzels me a bit, its just some implementation of standard library, wjy would it be more notable than say, dinkumware's implementation or stlport ? 83.25.130.165 (talk) 21:47, 26 July 2008 (UTC)

Suggestion for updating History section

"Many credit the origin of the name "C" as being a follow-on to APL (A Programming Language) and then BCPL, (B Computer Programming Language), or just plain "B" as it was most commonly called. APL was completely different in concept. With B, the original idea was to create machine code that was as closely identical to coding in assembly as possible, along with library functions for input/output, mathematical functions, etc. For the purists who thought it necessary to program in assembly to get full performance, it allowed the opportunity to program at a higher level and achieve better productivity. C is very similar to B, and while is not as efficient as B, it is available for a much greater variety of processors and platforms"

  • APL has nothing to do with C++.
  • C started with CPL (Combined Programming Language)
  • BCPL followed. Not sure why letter B was picked.

Here is excerpt from "BCPL Reference Manual" by Martin Richards posted on Dennis M. Ritchi's web site.

"BCPL is a simple recursive programming language designed for compiler writing and system programming: it was derived from true CPL (Combined Programming Language) by removing those features of the full language which make compilation difficult namely, the type and mode matching rules and the variety of definition structures with their associated scope rules." REF: http://cm.bell-labs.com/cm/cs/who/dmr/bcpl.pdf

and excerpt from "Users' Reference to B" by Ken Thompson also from DMR's web site.

"B is a computer language directly descendant from BCPL [1,2]. B 1s running at Murray Hill on the DEC PDP-11 computer under the UNIX-11 time sharing system [3,4]. B is good for recursive, non-numeric, machine independent applications, such as system and language work. " REF: http://cm.bell-labs.com/cm/cs/who/dmr/kbman.html

DMR has many documents leading up to development of C on his web site. http://www.cs.bell-labs.com/who/dmr/index.html —Preceding unsigned comment added by Shinkat (talkcontribs) 20:11, 23 July 2008 (UTC)

The C++ language is not the C language

I did edit the swan bird example to get rid of the pointers. Sorry if I killed a sacred cow by doing so, as the changes were almost immediately reverted. I had used to think that for C++, the program would either leak memory or it would crash. Since I have had some time to look at this, I have come to the conclusion that most problems in C++ are because of ill-advised admixtures of C and C++. In C++ pointers are generally evil and references and referents should be used. Since it is a feature of the C++ language, it should be highlighted. None of the examples should use a C construct when a C++ construct is available. Thoughts? Marktillinghast (talk) 07:10, 4 August 2008 (UTC)

Most likely, your change was reverted because it came in the middle of a spate of vandalism poorly discussed or controversial changes which were also reverted, and because it included the dread phrase "using namespace std". You're right that references could be used instead of pointers; personally I think pointers are going to provide a clearer example for most readers. SHEFFIELDSTEELTALK 13:48, 4 August 2008 (UTC)
...doh should have reread twice what you said, agreed that it may be clearer to sb who knows C with pointers, but than again there is not much difference, if you feel its better with pointers, please revert my edit 83.25.83.54 (talk) 18:05, 4 August 2008 (UTC)
pointers are not evil, its just possible to misuse them easily when objects lifetime is managed carelessly with them, that said, i think its a good idea to modify the polymorphism example and get rid of pointer ther in favour of a reference, just to put in a C++ feature, i will do that in a sec 83.25.83.54 (talk) 17:48, 4 August 2008 (UTC)
My compiler does not recognise #dogma :-) Let's see what other editors think. SHEFFIELDSTEELTALK 20:13, 4 August 2008 (UTC)

Article about C++ should be about C++ language features.

language features that make C++ the language it is. these are good topics and should have original code attached to them that showcases the language feature. mutable const friend throw catch new delete operator reinterpret_cast static static_cast dynamic_cast Thanks Marktillinghast (talk) 07:37, 4 August 2008 (UTC)