Jump to content

Wikipedia talk:WikiProject C/C++

Page contents not supported in other languages.
From Wikipedia, the free encyclopedia
< Wikipedia talk:WikiProject C
This is an old revision of this page, as edited by Code-Analysis (talk | contribs) at 12:31, 4 November 2012 (→C++0x still cited widely). The present address (URL) is a permanent link to this revision, which may differ significantly from the current revision.

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)[reply]

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)[reply]

  • My opinion is that this is redundant and just adds to the reading complexity of samples --Motti (talk) 07:32, 3 August 2011 (UTC)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

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)[reply]

  • 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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

Placement of curly braces

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)[reply]
  • 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)[reply]
  • 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)[reply]
  • 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)[reply]

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):

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

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)[reply]
  • 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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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

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

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)[reply]
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)[reply]
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)[reply]
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)[reply]
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)[reply]

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)[reply]

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)[reply]
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)[reply]
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)[reply]

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)[reply]
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)[reply]
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)[reply]
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)[reply]
fixed.Gsonnenf (talk) 16:31, 30 March 2009 (UTC)[reply]

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)[reply]

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)[reply]
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)[reply]
I'll delete the stuff that I know is duplicated.Gsonnenf (talk) 07:24, 27 March 2009 (UTC)[reply]

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)[reply]

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)[reply]

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)[reply]

C++0x still cited widely

You guys are probably aware of this already, but I have noticed that many C++ and general computer programming articles still refer to C++0x as an upcoming standard, rather than to C++11 adopted in August of this year. Is there any organized effort to fix that or do we just let it trickle in? TiC (talk) 15:49, 12 November 2011 (UTC)[reply]

for loop image

Hi. I have found this image : File:C language for.png . Is it bad image ? ( increment should be done also after last check of condition ) Am I right ? Regards --Adam majewski (talk) 09:47, 24 March 2012 (UTC)[reply]

Help with C++ Wikibook[1]

Hello all! I’m working with the Saylor foundation to create a series of original, crowd-sourced textbooks that will be openly licensed and freely available on the web and within Saylor’s free, self-paced courses at Saylor.org. We are using Wikibooks as a platform to host this project and hope to garner the interest of existing members of the Wikibooks and Wikipedia community, as well as bring in new members! We thought that some of your members may be interested in contributing to our book Saylor.Org's C++ Programming [2].(talk) --Thomas Simpson (talk) 17:20, 22 August 2012 (UTC)[reply]

Retrieved from "https://en.wikipedia.org/w/index.php?title=Wikipedia_talk:WikiProject_C/C%2B%2B&oldid=521348666"