The current todo on the page should definitely be gotten around to, I think the only things we should include here are libraries and other documentation, no make, build, ide's etc. Just pure c++. Alexhairyman 09:48, 29 April 2012 (PDT)
 Too much fancy formatting?
- Discussions about aesthetics are always fun. :) So one argument that I see for the current version is that we have similar lists all over the site, e.g. cpp/algorithm or cpp/header. Consistency is good. What makes this page different? If we use bullets here, should we use bullets everywhere? --Nate 07:14, 29 April 2012 (PDT)
- Just my two cents, but I think that the tcdl lists look better, and consistency is good. --- Undeterminant 08:24, 29 April 2012 (PDT)
- agreed, the tdcl lists make it easier to read the library descriptions Alexhairyman 09:43, 29 April 2012 (PDT)
- My opinion is that in this case horizontal separators don't serve much purpose, yet add additional clutter. By contrast, in the rest of the wiki we use horizontal separators for content that almost universally falls into two categories: a) tabular data (name <-> description or code <-> num <-> standard version); b) lots of function definitions which would otherwise be hard to visually separate. The separators are worthwhile in these cases. However, here, it seems, the separators would offer only consistency, while reducing (IMO) readability.
- As for scope, I would limit bulleted lists to cpp/links, c/language plus subpages and cpp/language plus subpages. The reasoning is that we don't have any tabular data there, so there's little advantage of emphasizing the organization of data. -- P12 13:09, 29 April 2012 (PDT)
- I prefer the plain list. This list does not have strict distinction between link and description and I don't think it needs the same style as other lists since it doesn't contain language features. --Bazzy 08:32, 29 April 2012 (PDT)
- If I understand these comments, I'm seeing two arguments for using bullets instead of "tdcl lists" on this page:
- 1. "tdcl lists" have lines that make large amounts of data easier to read. There's a reason that traditional tables have lines separating rows and columns: it makes it easier to pick out individual pieces of data. This page shouldn't have a large amount of data, so it doesn't need those lines.
- 2. Using bullets and "tdcl lists" for two different types of information helps users figure out that there are two "types" of information being presented. This page of links is conceptually different from pages that contain "tdcl lists", so it should have bullets.
- I think there are some issues with both of these justifications of bullet use, however:
- If we think #1 is right, should we apply it more broadly to the rest of the wiki? For example, there are lots of "see also" sections that only have a few rows. Shouldn't small, easy-to-read lists like those have bullets instead of "tdcl lists"?
- If we think #2 is right, where do we draw the line between the two "types" of information that we're presenting? If we go with "language features vs. everything else", shouldn't we use "tdcl lists" for things like cpp/language?
- (For what it's worth, I'm inclined to think #2 is a better justification for using bullets here, and that we should use "tdcl lists" for most other things, including cpp/language.) --Nate 18:14, 29 April 2012 (PDT)
- There's also the third point. It's important to consider the complexity of information. For example, a "dcl list" item linking to a library feature has at least 3-4 items: the name of an identifier, its description, category and, optionally, standard. More if several functions are being described. A "dcl list" item about a language feature has 1-2 items: description is merged with the name and there's standard version optionally. So where library features are described, we probably want to have "dcl list" even for one or two items. For simple information, such as language features, I think using "dcl list" offers smaller advantage.
- As for the second point, I think that we already make a difference by using plain "dcl list" for language features. IMO that's introduces a good balance between visual difference and consistency. By the way, the visual difference between plain "dcl list" as currently used for language features and bulleted list is not large, and certainly bigger than between either of these and "dcl list" as used for library features. So the difference between the visual presentation of library and language features is still preserved even if we use bulleted lists.
- I think the following balances all three points: what about if we use bulleted lists for large amounts of simple information? Currently only three pages satisfy this condition: c/language cpp/language and cpp/links (and subpages). -- P12 11:18, 3 May 2012 (PDT)
- That approach (assuming I understand it) makes sense to me: we only need the more complicated visual effects provided by "dcl list" (e.g. lines, bolding, font alignment) when we try to present complicated information (e.g. functions, types, methods). For simpler information, a simpler visual layout (bullets) makes sense. --Nate 12:25, 3 May 2012 (PDT)
- Yes. And when there's little information (e.g. See also sections), "dcl list" is worth using anyway, because the readability is reduced only a little (if at all) and the advantages of consistency outweighs that disadvantage. 12:43, 3 May 2012 (PDT)
I just added in categories, simply so the user can find what they are looking for more easily Alexhairyman 09:48, 29 April 2012 (PDT)
I feel that these 'useful links' could grow on forever. As this wiki is a reference, it makes most sense, in my opinion, to link to other references (standards, standard library references, vendor-specific compiler and library manuals, popular third-party library documentations, books (that's a whole new can of worms), magazines, conferences). But a list of useful C++ libraries is worth having: someone who comes to find out how to "make video games" won't find anything in the standard, but would benefit from a link to a graphics library or two. But there are many C++ libraries out there, and many more C++ wrappers over C libraries (like the GNU MP wrapper already present). How do we set limits? --Cubbi 13:00, 30 April 2012 (PDT)
- +1 this. I don't think a 1995-style endless list of broken links will help anybody. :) The best idea that I've been able to think of so far is to put an artificial limit on the number of links to include -- say, 25. When we hit that limit, any new links that we want to add have to displace an existing link. It's not pretty, but at least it will provide some vaguely solid thing that people can argue for or against. Instead of arguing "this link is important", the argument becomes "this link is more important than that link." --Nate 15:19, 30 April 2012 (PDT)
- My opinion is that these links to libraries might be still useful to someone. I remember myself searching a lot for an open-source library for some task. Having said that, I agree that that including them carries problems such as maintenance burden. However, I think it should be possible to find a balance between the two options. What about a separate, less maintained and advertised list of libraries at, e.g. cpp/links/libs? Those who need that list would find use of it, but it won't make life harder for those who read only cpp/links. We could then apply strict inclusion criteria for cpp/links. This approach could also be applied to other "controversial" categories of links, such as books, etc. -- P12 17:30, 30 April 2012 (PDT)
- That works for me. --Nate 06:15, 1 May 2012 (PDT)
So, is it time to make something link to this page? --Cubbi 20:02, 4 June 2012 (PDT)
- Sure. I've added a link to this page from the FAQ, for starters. There are other possibilities as well, like the main C++ page. --Nate 07:25, 5 June 2012 (PDT)
 Unicode 8 is out, but not with C++14
The C++14 specification cites Unicode 7, because that was out when C++14 was finalized. However, Unicode 8 is out now. I was going to change the link, but I realized that, technically, C++14 doesn't allow codepoints outside of those specified by Unicode 7. So I wasn't certain if it was appropriate to change it. I'll leave that to others to decide. Korval (talk) 17:36, 26 June 2015 (PDT)