Wikipedia talk:WikiProject C/C++/Archive 1

Just put myself in the list?

I know quite a lot about C++, but no a lot about Wikipedia :)

I'd like to join the Wikiproject C++. Do I just put my name in the list? Mrjeff 13:03, 15 March 2006 (UTC)

Of course! More labour, more product! --Deryck C. 14:41, 15 March 2006 (UTC)

Wikipedia:Version 1.0 Editorial Team cooperation

Hello. I'm a member of the Version 1.0 Editorial Team, which is looking to identify quality articles in Wikipedia for future publication on CD or paper. We recently began assessing articles using these criteria, and we are are asking for your help. As you are most aware of the issues surrounding your focus area, we are wondering if you could provide us with a list of the articles that fall within the scope of your WikiProject, and that are either featured, A-class, B-class, or Good articles, with no POV or copyright problems. Do you have any recommendations? If you do, please post your suggestions at the listing of all active Science WikiProjects, and if you have any questions, ask me in the Work Via WikiProjects talk page or directly in my talk page. Thanks a lot! Titoxd^{(?!? - help us)} 02:01, 30 March 2006 (UTC)

ansi C articles

Most of the proposed ansi c articles on the project page look to me like descriptions of header files. Is it really necessary to add an article for every single header file? I mean most of these can be much more than the *nix manual pages that exist for them or the help files of any compiler that includes them. -- Koffieyahoo 11:50, 5 April 2006 (UTC)

do you mean "can't be much more"? -MarSch 13:18, 5 April 2006 (UTC)

Yup, sorry about that confusing typo. -- Koffieyahoo 18:36, 5 April 2006 (UTC)

I'm ambivalent but what existing header articles I've looked at look good enough. Even so every article (candidate) should be judged on its own merits. --MarSch 17:11, 12 April 2006 (UTC)

Wikipedia is not a programming manual

I highly respect WikiProjects such as this, and a lot of the C/C++ work is great, but I think one of the subgoals of this project is misguided. Wikipedia is not a reference manual, which is what articles such as fgets amount to. Do we really need an article on every libc function or libc header? A Wiki is indeed a great way to document, but Wikipedia is an encyclopedia. Just like we moved dictionary definitions to a separate wiki, Wiktionary, we should move the programming manual out of Wikipedia. I can't find the AFDs right now, but a number of Java-related articles were all deleted for this reason. —Quarl ^(talk) 2006-04-12 09:36Z

I think you're talking about java.lang and java.io, etc. Well about every article in Category:stdio.h doesn't belong on Wikipedia. Would probably make a fine addition to some Wikibook on C. —Ruud 09:54, 12 April 2006 (UTC)

Yes, thanks, those are the ones I was thinking about. The AFD page is Wikipedia:Articles for deletion/Java.lang. —Quarl ^(talk) 2006-04-12 10:10Z

Quote from that afd: "This, and all the other articles concerning the Java standard packages, is merely a list of all included classes. " which is not true of the articles from the C stdlib that I've looked at. You may still have a valid point, but this is not the right argument/precedent. --MarSch 17:16, 12 April 2006 (UTC)

The java.lang article (only admins can view deleted pages) had more non-trivial content than the article C++ standard library and comparable to stdio.h. (I do think C++ standard library should have an encyclopedia article; it just doesn't have enough information yet.) The individual functions declared in stdio.h are even more narrow a topic than stdio.h. The main reason I mentioned the java.lang AFD is for the sentiment that seems to be consensus: Wikipedia is not a documentation system (another Wiki should be set up for this purpose). —Quarl ^(talk) 2006-04-13 01:15Z

printf was previously put for deletion, but didn't get deleted. I think if we make the function descriptions more encyclopedic instead of a manual-look, they deserve to stay. (fyi if the manuals get deleted, my edit count would decrease by at least 200). --Deryck C. 12:39, 13 April 2006 (UTC)

I suppose... if they were encyclopedic... but many of them are pure "man" pages right now. I suggest: put the info in the Wiki Man Pages project (of which you could be the leader!); if it doesn't fit there then consider whether it belongs in Wikipedia. —Quarl ^(talk) 2006-04-15 10:11Z

I think that this sort of content should stay in the Wikibooks project. There is already a C Programming Manual on Wikibooks. --Shimei 18:53, 14 April 2006 (UTC)

Wikipedia -- not Wikiman. Wikipedia isn't a manual. As much as I'd love to see a complete C++ reference, and as much as you try to disguise 500 C++ function articles to make them look "-pedia"like, it's not going to change my opinion that Wikipedia is not suitable for this information. We'll be having a C++ "undocumented stuff" wiki template next, and what then? —Preceding unsigned comment added by Jafet.vixle (talk • contribs)

If you can help me starting this new project, I'd accept the leadership upon the opening. --Deryck C. 12:11, 15 April 2006 (UTC)

I'm willing to donate server resources and set up the technical side in the hopes that it would eventually be maintained by WikiMedia. However, it looks like the Programming:C wikibook might already be a good place to put it. What do you think? —Quarl ^(talk) 2006-04-17 11:58Z

At this point, I agree that this content seems much better suited for a Wikibook than for Wikipedia. I have trouble seeing how most of these articles could be made "encyclopedic". Willing to be convinced otherwise though. --Allan McInnes (talk) 16:33, 20 April 2006 (UTC)

My new personal proposal: keep all existing man-like articles and try to make them more encyclopedic; do not create any new function articles unless it's written encyclopedically at start. --Deryck C. 16:03, 23 May 2006 (UTC)

I have to concur that adding individual pages for all the functions from the C standard library is not a good idea (redirects are probably okay). I just can't see how they can be made to be of encyclopedic value. The same goes for methods/functions in Java or any other language. Wikibooks is definitely where this belongs. RedWolf 22:32, 14 June 2006 (UTC)

I disagree 100%. Wikipedia is not a how-to reference, but who says it can't document C++? Check out WP:NOT to see the lack of content related to manuals. Wikipedia is about giving people useful information. The sooner people realize that, the better. Wikipedia is NOT a beuracracy and we are not meant to follow vauge, nebulous, and even non-existant rules like "Wikipedia is not a manual". People need a good reference on C and C++ and it simply isn't out there. And this wikiproject doesn't seem to be helping that much either.

We need to get our act together and give people useful information - we should not be witholding info because its a "manual" or anything like that. Wikibooks is for examples, how-to's, and other redundant information designed to *teach*. Wikipedia is for information, pure and simple. I agree that one page per C function is a bad idea - however one page per C library is efficient and useful. List the functions there.

I've been trying to add to wikipedia's C and C++ knowlege base, but I find myself alone in the quest - where are you guys? Fresheneesz 22:51, 15 August 2006 (UTC)

I guess I agree with everybody but Fresheneesz. Putting the reference manual for every programming language into the same namespace is not going to help anyone. Much better to put it in seperate namespaces, that is, create a Wikibook for each language. I guess the best thing anyone could do for this project would be to move the The only information about C++ that should remain here should be information interesting to people who are not programming in C++. That is, general information about the structure of the language, and specific information about features pioneered by C++, or where the "prototypical" example is in C++. For example, iostream is a generally interesting way to organise input and output in a programming language. An overview article about the principles behind iostream could be appropriate here. But not a reference for the exact semantics of every function. --Per Abrahamsen 06:44, 12 October 2006 (UTC)

article list

It seems to me that it is kind of silly to have an article list, when we have a template {Wikipedia: WikiProject C++/Article} which identifies articles. Of course it is much easier to view changes of a list, but bots can be deployed to alleviate that problem. Please comment. --MarSch 13:22, 13 April 2006 (UTC)

The "article list" includes redlinks to things that may deserve an article. The template serves only as a reference of existing articles. --Deryck C. 09:57, 22 April 2006 (UTC)

Naming ambiguity of the project and other problems it entails

It is unclear to me why the project's name was changed from WikiProject C to WikiProject C++. As I understand it, this project is supposed to be dealing with both C and C++. I always take such attempts of unifying the two languages with a grain of salt; too often are they made by people who do not possess sufficient knowledge of intricacies of both languages. Such people start making unreasonable assumptions leading to oversimplications like the famous 'C is just a subset of C++'. Nevertheless, I have decided to give the project a chance to disprove my doubts.

After reading a few articles it has, unfortunately, become apparent that much of them have been written from an extremely C++ biased perspective (which is reflected in the change of the project's name, obviously). Also, some parts were inaccurate, or just plainly incorrect. One example is the previous wording of the section concerning the macro NULL in the stdlib.h article or the erroneous mixing of headers files and the libraries they are associated with.

One other problem is that cstdio in C++ is, in fact, not interchangeable with the stdio.h found in C. The reason for this is that some functions declared in cstdio are non-existing in the C Standard Library (e.g. lfind, itoa and others). Prior to recognising the problem, I have removed such non-standard C functions from the stdio.h article. After encountering similar examples in stdlib, I have realised that the authors' intention was probably to unify the functions belonging to both stdio.h and cstdio (and other similar headers) to single articles.

It is debatable whether adding an article for every single C function and header is productive since many people seem to dislike the idea. That put aside, I think it is safe to say that it would certainly be useful, although mayhaps inappropriate for Wikipedia. I will not discuss the matter of appropriateness here. However, incorrect information defeats even the point of usefulness. Therefore, information presented must not be incorrect or even misleading. And the truth is that C++ specific functions have no place in the C header file articles in their present state.

A possible way to resolve the problem is to restructure the articles in such a way to make it obvious that not all, for example, cstdio function declarations can be found in stdio.h and update the function tables to reflect that change. Please comment. Denis Kasak 20:01, 11 June 2006 (UTC)

Actually, it turns out I was wrong. There are no such functions in Standard C++ either, and cstdio and stdio.h (and others) are indeed completely equivalent. Nevertheless, the problem still stands, and this time it's easier to deal with. The solution is simple; all such non-standard C/C++ should be removed from the articles. Denis Kasak 10:08, 12 June 2006 (UTC)

I believe a better solution is to mark those functions "non-standard", instead of removing them as wikipedia is supposed to give as much knowledge as possible. Also, per the discussion above and at Wikipedia talk:WikiProject Computer science, we're not going to create anymore function-specific articles but we'll keep the existing ones. --Deryck C. 10:20, 27 June 2006 (UTC)

I fail to see how that can be a better solution. The nature of header articles is debatable in itself, but since they're already written, the biggest favour you can do towards the world is to keep them informationally correct. If I understood correctly, the purpose of the articles should be to describe functions of the C or the C++ language declared in their respective header files, as defined by their respective standards. Since none of the questionable functions are defined by the standards, how can they have a place in those articles? Where do we put an end to it? If my implementation of the C Standard Library happens to be on a Death Star and happens to have a destroyTheWorld() function declared in stdlib.h does it make it viable for inclusion in the Stdlib.h article? Denis Kasak 13:03, 1 July 2006 (UTC)

functions not in the standard header, which are for some reason in the article should be clearly marked as a non-standard extension. This does not violate correctness. --MarSch 15:21, 3 December 2006 (UTC)

C programming language

C programming language is up for a featured article review. Detailed concerns may be found here. Please leave your comments and help us address and maintain this article's featured quality. Sandy 22:40, 16 July 2006 (UTC)

Wheres my C reference

I've been adding pages and information to the C and C++ library knowlege-base on wikipedia - however I've found no help. None of the C++ pages I edit seem to ever be edited again. My work isn't checked, my work isn't embellished. It stays stagnent. Wheres the help from this project. Even people opposed to it say "I'd love to see a complete C++ reference on wikipedia", and so would I. Where the hell is it? I'm creating it anytime I can't find what I need on wikipedia, wheres the help?

Check the header "Wikipedia is not a programming manual" for my arguement. Fresheneesz 22:55, 15 August 2006 (UTC)

Assistance Requested

A dispute has arisen over the article Virtual inheritance. I think that the article would greatly benefit from many people reading the it (and adding to its discussion if you have time). I'll let you form your opinions for yourselves, but please have a look at it if you have time! It would be greatly appreciated. --Mike Blackney 03:43, 7 September 2006 (UTC)

Emacs

Emacs is up for a featured article review. Detailed concerns may be found here. Please leave your comments and help us address and maintain this article's featured quality. Sandy 19:56, 10 October 2006 (UTC)

This section doesn't seem relevant to the project. I will delete it at some point. -- Alastair Irvine 11:50, 3 May 2007 (UTC)

Project directory

Hello. The WikiProject Council has recently updated the Wikipedia:WikiProject Council/Directory. This new directory includes a variety of categories and subcategories which will, with luck, potentially draw new members to the projects who are interested in those specific subjects. Please review the directory and make any changes to the entries for your project that you see fit. There is also a directory of portals, at User:B2T2/Portal, listing all the existing portals. Feel free to add any of them to the portals or comments section of your entries in the directory. The three columns regarding assessment, peer review, and collaboration are included in the directory for both the use of the projects themselves and for that of others. Having such departments will allow a project to more quickly and easily identify its most important articles and its articles in greatest need of improvement. If you have not already done so, please consider whether your project would benefit from having departments which deal in these matters. It is my hope that all the changes to the directory can be finished by the first of next month. Please feel free to make any changes you see fit to the entries for your project before then. If you should have any questions regarding this matter, please do not hesitate to contact me. Thank you. B2T2 00:01, 26 October 2006 (UTC)

Stablepedia

Beginning cross-post.

See Wikipedia talk:Version 1.0 Editorial Team#Stablepedia. If you wish to comment, please comment there. ★TWO YEARS OF MESSEDROCKER★ 03:45, 26 November 2006 (UTC)

End cross-post. Please do not comment more in this section.

Wikibooks may be a possible solution

I mostly contribute to Wikibooks and have been looking for people who might be interested in contributing to a book there on C++. I noticed reading through the discussions on this talk page, that some people are interested in writing a book or reference manual on C++ and others feel that some contents on Wikipedia is too much like a book for Wikipedia. So I would like to suggest as a possible solution that those of you who are interested in contributing to a book on C++ check out C++ Programming on Wikibooks. You might want to read Wikibooks:Wikibooks for Wikipedians as well, if your not familar with Wikibooks, to familarize yourself with the differences. --Darklama 20:46, 11 December 2006 (UTC)

I had a quick look at "Coding Style Conventions" and was immediately stuck by this wrong sentence: "As seen earlier, indentation and the use of white spaces or tabs are completely ignored by the compiler" (I'm sure you can see why it is an error; just think e.g. of defining a function-like macro putting a space between the macro name and the lparen). Regardless of that (I might have been unlucky and hit the only section containing errors) I think coming up with something which is remotely comparable for quality to the existing bibliography (Stroustrup, Josuttis, Sutter, Meyers, Alexandrescu, Vandevoorde…) is close to impossible without spending years, and there's at least one decent free text already, B. Eckel's Thinking in C++. So I wonder, what's the point of a Wikibook? Don't get me wrong, though, I'm a Wikipedian so we certainly are on the same wavelength, but C++ happens to have a top-notch C++ community, producing extremely high-quality writings. And the field is enough specialistic that those books are needed anyway, unless one is just interested at getting an amateur knowledge (overview?) of the language. —Gennaro Prota^•Talk 00:21, 12 December 2006 (UTC)

I doubt you were unlucky. More editors means more eyes to catch and fix errors like that. Saddly this book has already existed for years and hasn't gotten anywhere near the quality of the books you mentioned. The point of any Wikibook really is to provide free textbooks for students to learn from that are up to date with the latest established standards of the subject/field it covers. For example with the C++ book keeping up with changes to the ISO C++ standard. Its a similar principal as articles are on Wikipedia, keeping information up to date, only doing so more indepth and in book form. That allows for better coverage of a subject on Wikibooks, where here on Wikipedia, articles tend to have to summerize the subjects. In fact some Wikibooks start off as being Wikipedia articles that were imported (to keep the edit history intact) that are then expanded on. Both Wikipedia articles and Wikibooks books are only as good as the sum of the knowledge of the contributors providing information. Information may be amateur, but it can be correct and fixed if incorrect. The C++ book currently suffers the same problems that some articles on Wikipedia has if there are few contributors, lack of quality peer review and keeping current. I hope this doesn't sound like I'm being negative about Wikipedia or about the C++ book, just trying to explain some of the issues and why I'm (somewhat) actively seeking people who may be interested in contributing. I figure people who contribute contents to an article on C++ here, may also be willing to contribute there, if they have the time. --Darklama 15:13, 12 December 2006 (UTC)

Wikipedia Day Awards

Hello, all. It was initially my hope to try to have this done as part of Esperanza's proposal for an appreciation week to end on Wikipedia Day, January 15. However, several people have once again proposed the entirety of Esperanza for deletion, so that might not work. It was the intention of the Appreciation Week proposal to set aside a given time when the various individuals who have made significant, valuable contributions to the encyclopedia would be recognized and honored. I believe that, with some effort, this could still be done. My proposal is to, with luck, try to organize the various WikiProjects and other entities of wikipedia to take part in a larger celebrartion of its contributors to take place in January, probably beginning January 15, 2007. I have created yet another new subpage for myself (a weakness of mine, I'm afraid) at User talk:Badbilltucker/Appreciation Week where I would greatly appreciate any indications from the members of this project as to whether and how they might be willing and/or able to assist in recognizing the contributions of our editors. Thank you for your attention. Badbilltucker 17:45, 30 December 2006 (UTC)

Platform independent C++ counterpart for ActiveX Data Objects and 'VARIANT'

I am looking for an platform independent C++ counterpart of ActiveX Data Objects and Variant data type, I have used these objects/data type earlier in ATL COM environment but now I want a subset of the same (no need of DB connection functionality i.e. disconnect container object only for data transfer) in pure C++ code. The aim is to return either basic data type or a Resordset object from all of the exposed api to have consistent interface, I do not want to expose custom objects (say 'Customer', 'Address', 'Item', 'Order', 'Invoice' etc). The client which receives this RecordsetC++ object should be able to iterate through rows as well as all the fields (column) and should be able to get the data type of the field. Vjdchauhan 10:29, 15 January 2007 (UTC).

How do I join the WikiProject

Hi ,

I want to be a part of this project. I know a lot about C++, but I am new to this project. From a previous post I am adding my name to the members list .

Please let me know what do I do next .

Sujay

Sujayg 07:42, 2 February 2007 (UTC)

Thanks for your enthusiasm. You can skim through some current articles about C++ on the list and edit them. You can also create new articles about C++. A little note is that for the time being don't create new articles for individual functions and procedures unless you have enough sourced encyclopedic information. --Deryck C. 10:17, 2 February 2007 (UTC)

hello :)

hello everyone , i dont have extreem experiance with c++ but the similarity with c# made me join this project as long as there is no project for c# :) Ammar 12:46, 2 March 2007 (UTC)

Oh thanks for your kindness =] I also would like to know sth about C# since I'm working on some academic projects which requires C#. -Deryck C. 12:53, 2 March 2007 (UTC)

you are a cs teacher ? :) Ammar 13:05, 2 March 2007 (UTC)

See also

"Wikisource:Source code" is a dead link -- Alastair Irvine 11:51, 3 May 2007 (UTC)

GA review

C++ is having its Good Article status reviewed. See the Good Article review page to comment. T Rex | talk 21:08, 29 August 2007 (UTC)

C++0x article may be too long.

I need your opinion about the structure of article C++0x.

Talk:C++0x#Article is Too Long

Thanks. --Gildos (talk) 02:41, 29 December 2007 (UTC)

Suggestion To Change/Merge AMD Performance Library Page

I just added a bit to the article AMD Performance Library (APL), then I discovered the page Integrated Performance Primitives (IPP). I see that WikiProject C++ owns the latter. I have several suggestions.

1. WikiProject C++ should take ownership of the APL page.
   
2. While the functionality remains similar, AMD has deprecated the APL in favor of its new, open-source derivative Framewave. (That's what I added to the APL page.) This page should be rewritten and renamed to AMD Framewave Library.
3. I think perhaps the best scenario is to merge the APL page with the IPP library page. The Intel IPP library page has a "looks like and advertisement" tag on it and the AMD page doesn't look any better to me. Perhaps there are other vendor sponsored performance librarys that could be aggragated with these.

I don't know what the offical policy is about documenting librarys, but something should happen to the APL page. What do you thing? R39525 (talk) 20:47, 20 February 2008 (UTC)

Export to Wikibooks

I propose that most of this project be exported to Wikibooks:C Standard Library and Wikibooks:C++ Standard Library. The articles in question include the standard header files, functions and (C++) classes; obscure C++-specific terms and paradigms (like typeid and SFINAE) should also be moved to Wikibooks:C++ Programming. Wikipedia is not a reference or manual. I am willing to help coordinate this move and expand the manuals there. The content should also integrate well with the existing Wikibooks:C Programming and Wikibooks:C++ Programing books there. ~ Jafet _{Speaker of many words} 07:22, 21 August 2008 (UTC)

C++ logical operators

An article entitled C++ logical operators was created a month ago and needs (at least) wikification, however I queried how this fits with the existing articles. Would this project like to look at that article? Rich257 (talk) 12:29, 24 October 2008 (UTC)

That article deals with a very specific programming issue-- I do not think it is suitable in wikipedia, it may be moved to wikibook. Jyoti (talk) 01:47, 27 October 2008 (UTC)

Just put myself in the list?

I know quite a lot about C++, but no a lot about Wikipedia :)

I'd like to join the Wikiproject C++. Do I just put my name in the list? Mrjeff 13:03, 15 March 2006 (UTC)

Of course! More labour, more product! --Deryck C. 14:41, 15 March 2006 (UTC)

Good Q actually-- it should be stated somewhere how to join. I have not added any articles yet, but I was a Microsoft C++ MVP for a few years and have been writing it for about ohhh fifteen I can probably do some minor subbing somewhere.

SimonTrew (talk) 09:39, 21 February 2009 (UTC)

Naming of C++ Standard Library component articles.

Looking at the articles about the most notable C++ Standard Library components, I notice that the naming is rather inconsistent. These are the article's names (I may have missed some though):

• map (C++ container)
• Vector (STL)
• String (C++)
• Sort (C++)
• Auto_ptr
• unordered_map (C++ class) // non-standard
• ifstream

I would like to rename the articles to follow a more consistent convention. In particular:

• The first character of all articles should be the same case. I prefer uppercase.
  • Identifiers are case-sensitive, so I would refrain from renaming map to Map. Musiphil (talk) 04:09, 9 March 2009 (UTC)

Yes, I'm willing to reconsider that one. My main objective is to make them all consistent, anyway. decltype (talk) 05:45, 9 March 2009 (UTC)

• A common suffix (where necessary). I prefer simply (C++).

Thoughts, comments, etc. are much appreciated. If no objections are raised, I will simply do the renames, following the convention outlined above. Note also that this discussion is about the component articles, not the header file articles. decltype 09:42, 6 March 2009 (UTC)

I agree with Musiphil -- since C++ is case sensitive, it seems incorrect to call map "Map" or string "String".

Could we rename those articles to "C++ map", "C++ vector", "C++ ifstream", etc.? That seems to meet both decltype's desire that all articles start uppercase, and my desire to keep those case-sensitive identifiers in the correct case. It also allows easy linking when some other article refers to "The C++ vector is similar to ..." --68.0.124.33 (talk) 23:13, 12 March 2009 (UTC)

I'd prefer map (C++), etc. It seems more common to append the disambiguating word in parentheses. But according to WP:NCDAB, there is no hard rule about which is preferred. decltype (talk) 07:20, 13 March 2009 (UTC)

I agree -- WP:NCDAB has no preference, and some of the article names listed at "vector" have parenthesis. The name "vector (C++)" would be consistent with "vector (malware)". However, most of the articles at "vector" do not use parenthesis. The name "C++ vector" is more consistent with Euclidean vector, coordinate vector, probability vector, row vector, column vector, interrupt vector, etc.

I agree. Using parentheses is the usual way to disambiguate things in Wikipedia. Euclidean vector, coordinate vector, probability vector, row vector, column vector, interrupt vector, etc. are actually, I would say, compound words, and it wouldn't make any sense to name them "Vector (Euclidean)", "Vector (coordinate)", "Vector (probability)", "Vector (row)", "Vector (column)", "Vector (interrupt)", etc., so they are named so for a good reason. But that doesn't apply to the C++ vector; we rarely say "C++ vector" except for comparison (just as happened in the previous sentence). Therefore the title should be "vector (C++)". — Musiphil (talk) 17:48, 23 March 2009 (UTC)

When people usually use some phrase to refer to something, I prefer to use that same phrase for the article name. Google tells me that more people use the phrase "C++ vector" than "vector (C++)".

The real reason I prefer "no parenthesis" is to enable easy linking, as recommended by the Wikipedia: Naming conventions#Use the most easily recognized name policy. --68.0.124.33 (talk) 14:13, 18 March 2009 (UTC)

I'd prefer the parentheses way of doing it. In the C++ articles themselves you surely are not going to write "C++ vector" etc (it is rather implied that you are using C++) so surely question of easy linking is moot. But I am not overly het up which form is taken-- I suppose first steps are at least to make them consistent, I think that would be part of the Principle of Least Surprise-- at least then once one has found Vector (C++) one can guess Map (C++), List (C++) etc. (or C++ Vector, C++ Map, C++ List etc) (talk) 15:02, 19 March 2009 (UTC)

Actually, I have already moved Vector (STL) to Vector (C++), because this was the name I disliked the most (also being the primary contributor of that article). Not my intention to go against consensus, but there was no activity here for a few days, so I felt the move was uncontroversial. That means that vector, string, and sort are now consistent. As for the others, I just realized they don't need a disambiguation. decltype (talk) 15:08, 19 March 2009 (UTC)

I'd still prefer them all to be "(C++)" even when not entirely necessary for disambiguation (I suppose somewhere in Wikipedia this is the called the Law of I Got Here First or something). As more articles develop it will continue to be consistent. SimonTrew (talk) 20:06, 23 March 2009 (UTC)

And I have now performed the last moves so that all standard library component articles have consistent disambiguations (unless I missed some).

• Map (C++)
• Vector (C++)
• String (C++)
• Sort (C++)
• Unordered map (C++) // non-standard
• Hash map (C++) // non-standard

All the old names remain as redirects to the main article. decltype (talk) 08:55, 7 September 2009 (UTC)

Library Organization Scheme

There is a long list of libraries and their order doesn't appear very descriptive. Eventually we're going to have to sort these out to make them more accessible. There are a few ideas i'd like to address.

• C libraries are often also C++ libraries, so they should be included, but should be distinguished from C++ only libraries.

• Libraries should be available sorted by features they implement. This isn't an easy task or exact science, as many libraries implement many features. An example would be the QT toolkit, which is thought of as a GUI framework, but implements features such as compile-time reflection, a SQL tookit, and to some extent memory management. While this task may seem difficult, it would be very useful when anticipating a custom framework. —Preceding unsigned comment added by Gsonnenf (talk • contribs) 19:44, 26 March 2009 (UTC)

Are C libraries also C++ libraries? I don't have my reference books here to be absolutely sure if this is strictly true as they each have a preferred C++ equivalent (presumably partly to allow compiler writers to adjust syntax if their compiler would grumble at C syntax such as variadic lists etc), and I am not particularly familiar with any changes for C++0x. It doesn't matter as such if they are or not, but we'd better get it right. SimonTrew (talk) 19:51, 26 March 2009 (UTC)

That is a very good point, C and C++ are not strictly compatible. See Compatibility of C and C++. So in that case should we only list C libraries that advertise themselves as C++ compatible? What are your thoughts?Gsonnenf (talk) 20:28, 26 March 2009 (UTC)

I don't know. I know now it is recommended to say #include <cstring> instead of <string.h>, but I don't know what the proposals for C++0x will say. As I say, I don't think it matters as long as it's clear one way or the other (and of course not factually incorrect).

I had assumed you meant just the "standard" libraries (C or C++). I see now that is not what you meant. I suppose yes I'd started as you did with your edit saying something like "many C libraries can also be used in C++" or something like that. I'd imagine by now the proportion would be quite high, though C is still quite handy for having an ABI and also seems still preferred for embedded systems etc (just judging from the number of jobs around). SimonTrew (talk) 21:20, 26 March 2009 (UTC)

I agree to sort them out is by function (UI, math, database, etc.) and agree it is not an exact science as no doubt many will overlap. I don't have a problem with then listing them in both places, it's the limitation of a hierarchy— if it were rigidly followed there'd be know Wikipedia because you'd have a root artice of "Everything". However I imagine I am in a minority there.

I'd go for the Be Bold principle here because as soon as you do EVERYONE will have an opinion. SimonTrew (talk) 21:23, 26 March 2009 (UTC)

I came up with a rough draft list. The categories need to be changed, so I'm hoping you guys can help decide what these headers should be.

'

Std C++ Lib.

Template

UI

Math

Science or Eng. (not math)

Mem. Manag.

Database

Parsing framework

Network

2D Graphics

3D Graphics

Thread Manag.

Platform

License

Apache C++ Standard Library

Yes

Yes

Un­known

Un­known

Un­known

Un­known

Un­known

Un­known

Un­known

Un­known

Un­known

Un­known

Cross platform

Apache License 2.0

Blitz++

No

Yes

No

Yes

No

No

No

No

No

No

No

No

Cross platform

GPL / other (LGPL-like)

MAGMA (Molecular Animation, Graphics and Modeling Application framework)

No

No

Un­known

Un­known

Yes

Un­known

Un­known

Un­known

Un­known

Un­known

Yes

Un­known

Un­known

Un­known

Qt (toolkit)

Un­known

Un­known

Un­known

Un­known

Un­known

Un­known

Partial

Un­known

Un­known

Yes

Partial

Un­known

Un­known

Un­known

Additional input would be appreciated.Gsonnenf (talk) 01:04, 27 March 2009 (UTC)

I would combine math (or as we proper people say maths) with science and engineering). I would say that as a chap who works in a scientific field, but I think they are cognate enough to share a category.

Similarly I would combine the 2D and 3D graphics, and I imagine there is much overlap with libraries doing both.

I am not overly worried if you disagree, I think simply organising it is better than not, it is just my two pennyworth since you asked for it. SimonTrew (talk) 01:20, 27 March 2009 (UTC)

This table is patently, and I assume deliberately, not only incomplete but incorrect (e.g. Qt has UI). I am sure you put it as an example and not intending it to as a submission for corrections but if you do have genuine "unknowns" I am glad to help out. SimonTrew (talk) 01:27, 27 March 2009 (UTC)

The tables are intentionally filled out poorly. I'm not sure if combining maths and engineering would be the best organizational method. An encryption or sorting algorithm is in a different problem domain than a Molecule Visualization tool. We could of course rectify this by changing the field names to "Algorithms" and "Physical Sciences" or something like that. 2D and 3D graphics are also somewhat distinct. Code from say GIMP is primarly (if not entirely) 2d based, while a C++ 3d engine like OGRE is Primary 3d. We could perhaps combine graphics into a single field, and write in the graphics capabilities like so:

'

Std C++ Lib.

Template

UI

Algorithms

Physical Science

Mem. Manag.

Database

Parsing framework

Network

Graphics

Thread Manag.

Platform

License

MAGMA (Molecular Animation, Graphics and Modeling Application framework)

No

No

Un­known

Un­known

Yes

Un­known

Un­known

Un­known

Un­known

3D

Un­known

Un­known

Un­known

Qt (toolkit)

Un­known

Un­known

Un­known

Un­known

Un­known

Un­known

Partial

Un­known

Un­known

2D / Limited 3D

Un­known

Un­known

Un­known

Another option could be to list them by field and just give a brief description:

GUI Frameworks

Library	Platform	License	Description
Qt (toolkit)	Cross-platform	GPL / LGPL / Commericial	Qt is a Graphical UI Framework. It also incorporates SQL libraries, Reflection, networking, etc.

This also raises the question if we should separate libraries, which may have great depth but little breadth, from software frameworks such as QT.Gsonnenf (talk) 03:53, 27 March 2009 (UTC)

I'd definitely prefer the "sparse" approach. Most libraries would only have "Yes" in one or two columns anyway. Of course, categories such as platform and license apply to all. A combination of the two approaches:

Library	Platform	License	"Categories"
Qt (toolkit)	Cross-platform	GPL / LGPL / Commercial	GUI, Threading, Network, XML, Graphics, etc..

Or the textual description approach is fine too, in my opinion. decltype (talk) 06:49, 27 March 2009 (UTC)

I'm going to go ahead and categorize the "C++ libraries into two categories: Libraries and frameworks. There is of course a gray area, so if you don't agree with where i put something, we'll discuss it. I'll be categorizing the primarily on the claims of the authors. This categorization is very useful to developers. Libraries are usually integrated more easily than frameworks and with less overhead.Gsonnenf (talk) 11:30, 28 March 2009 (UTC)

Here is a table I'm starting. This is also a draft version, but the information in it should be correct. So if you want to add information that would be useful.Gsonnenf (talk) 15:12, 29 March 2009 (UTC)

Okay, but why did you make it a template? As far as I can see, there isn't much potential for reuse. decltype (talk) 11:50, 30 March 2009 (UTC)

fixed.Gsonnenf (talk) 16:31, 30 March 2009 (UTC)

Maintaining Library lists

I noticed that Wikipedia maintains a list of C++ libraries using category tags. See http://en.wikipedia.org/wiki/Category:C%2B%2B_libraries . Not sure if this feature was added after this list began. I rectified the automated list with our list. I believe only 2 libraries didn't exist in the automated list. It doesn't make much sense to maintain a list manually unless we are adding descriptions and or proposing tags. What do you guys think?Gsonnenf (talk) 20:39, 26 March 2009 (UTC)

I'm not sure, the list was there when I joined. But good work with the update. decltype (talk) 06:38, 27 March 2009 (UTC)

Does that mean that you have ensured everything in the manual list is in the automated list? In that case the old list should just be purged. Articles needing attention and such can be added to a separate list if needed, anyway. decltype (talk) 06:54, 27 March 2009 (UTC)

I'll delete the stuff that I know is duplicated.Gsonnenf (talk) 07:24, 27 March 2009 (UTC)

Reward for C++ GA/DYK

For those interested, I have posted an open reward for anyone who contributes significantly to a C++-related GA or DYK. The offer can be found here: Wikipedia:Reward_Board#C++GA/DYK. decltype (talk) 02:55, 7 June 2009 (UTC)

Importance

I have added an importance parameter to the WP banner. Feel free to give an importance assessment to any article within the scope of this project. decltype (talk) 19:28, 30 September 2009 (UTC)

fflush

FYI, fflush got nuked... someone might want to add some content to fputc and fwrite at the destination about associated fflush use. 70.29.208.247 (talk) 11:36, 15 May 2010 (UTC)

Coding Style Conventions

I've seen a few mini edit-wars going on regarding coding style. Is there a place where coding styles are discussed and can be referenced when editing code examples?

I've raised an RFC. --Demonkoryu (talk) 07:21, 6 September 2011 (UTC)

For starters the issues I would like discussed are:

Explicit use of this to access members

When accessing a member should the member be prefixed with this->? Motti (talk) 07:32, 3 August 2011 (UTC)

• My opinion is that this is redundant and just adds to the reading complexity of samples --Motti (talk) 07:32, 3 August 2011 (UTC)
• I think that it contributes greatly to readability since it visually differentiates between member variables and parameters/local variables. In fact, most other C++-style languages like Java, C#, JavaScript, PHP enforce using this->/$this->.--Demonkoryu (talk) 07:49, 3 August 2011 (UTC)

• While this is true for JavaScript it is not true that Java and C# enforce using this (and I'm not familiar with PHP). In my opinion it's poor style in C++/C#/Java. Motti (talk) 13:06, 4 August 2011 (UTC)

• I don't think it is good idea because the member variables usually are marked in other ways, such as member_ or m_member. Both these ways are shorter than this->. In addition to that, this-> doesn't eliminate the possibility of global variable shadowing, though this is maybe not important for example code snippets. Still, that's important as a lot of novices may consider style used in Wikipedia examples when deciding their own style. Personally I'd stick to the member_ style as it's the shortest one.1exec1 (talk) 14:39, 3 August 2011 (UTC)
• Regardless of the pros and cons of prefixing everything with this->, it's not representative. I've heard of people who claim to use it, but I've never seen it in real code or in examples in books. It would be very misleading to use it in Wikipedia example code. JöG (talk) 11:28, 2 October 2011 (UTC)

Use of std:: in samples

Lots of code samples use cout, should this be prefixed with std::? Motti (talk) 07:32, 3 August 2011 (UTC)

• Since this is a sample I think this is redundant, after all the samples don't typically #include <iostream>--Motti (talk) 07:32, 3 August 2011 (UTC)
• As our goal is consistency, we should either use std:: everywhere or nowhere at all. The latter option is a undesirable because the new C++11 standard (which is going to be released in few weeks) is going to have quite a lot of stuff that is implemented in other libraries such as boost. So not using std:: we introduce great ambiguity in these articles which talk about both (e.g. in C++11). Additionally, using namespace std is considered a bad practice since the probability of name clashes is increased greatly, so it is very rarely used in big projects. Again, we don't want novices to pick up bad coding habits. So it leaves us with std::.1exec1 (talk) 14:39, 3 August 2011 (UTC)

• As far as I know using namespace std is not considered bad practice in source files, it's considered bad practice in header files which pollute all source files that include them but in .cpp files it's considered perfectly OK. Motti (talk) 13:11, 4 August 2011 (UTC)

• Well for small programs it may be fine, but in large software projects, where in each compilation unit there are tens of namespaces used, something like using namespace std can become a nightmare. As a solution, the imported names are specified explicitly, e.g. using std::cout;.1exec1 (talk) 23:54, 16 August 2011 (UTC)

Placement of curly braces

• I don't have strong feelings on this but I think we should strive for consistency.--Motti (talk) 07:32, 3 August 2011 (UTC)
• I'm for readability, consistency and conservation of vertical space. This is my personal favorite: http://en.wikipedia.org/wiki/Indent_style#Variant:_1TBS --Demonkoryu (talk) 07:49, 3 August 2011 (UTC)

Remembering our previous discussion I think that you are confusing this style with something else, as it is the same as K&R style except that all statement groups consisting of one statement are enclosed with curly braces.1exec1 (talk) 23:55, 16 August 2011 (UTC)

• IMO the style in the examples here is reasonable. Structs, namespaces and classes have the curly brace placed at the same line as definition, where the functions have the curly brace placed in the following line. This is consistent with the style used in C language, which is important as C and C++ have quite a lot of overlap (even some of the examples here apply to both C++ and C).1exec1 (talk) 23:55, 16 August 2011 (UTC)
• I'm in agreement with Motti that we should be consistent, however I feel the consistency should be throughout an article, not throughout Wikipedia. Rather we should treat the issue much like we handle UK/US spelling issues. There are several curly brace styles in use, and they all have strong adherents, and I don't believe Wikipedia should endorse any one in particular, even implicitly by having all code in all articles use the "official wikipedia" style. So let an author use their style of preference when writing an article, and let's not allow edits to style unless to regularize it throughout an article. Same as we do with UK/US spelling. Nibios (talk) 00:52, 25 August 2011 (UTC)
• I am for K&R style in all articles as this style was used in different editions of Stroustroup books, representing the language. Alexvwiki (talk) 22:52, 28 September 2011 (UTC)