Talk:Main Page

Replacement filing cabinet.svg


Archive 1 Archive 2


[edit] Alphabetical Index

I think that this reference needs an alphabetically ordered index pages. I would create them but I am not sure if the site maintainers will accept them. If you create an index I would work on it.

It is not clear to me, if you mean an alphabetical index of all pages of this website, or an alphabetical index of all names (symbols?) in the std namespace.
The latter I miss myself too, and others as well (see e.g I would gladly help to build such an index page! Gemini67 (talk) 03:38, 14 October 2015 (PDT)
the OP has been building that index, although there were no updates since april. It is accessible directly from the main page. Personally, I think it would be more sustainable if it were using the same wordlist as our search (which is, effectively, an index file) --Cubbi (talk) 05:54, 14 October 2015 (PDT)
Well, but this index is far from a complete list of all symbols in the std:: namespace, isn't it? What I am looking for is an index that contains (algorithm) find_if() as well as (iomanip) setfill() or (function object) bit_and etc.Gemini67 (talk) 08:35, 15 October 2015 (PDT)

[edit] Qt help book

It does not have the same front page as the online reference. There is no link to the C reference. It would be nice that the C reference is linked somewhere too. The FAQ link is also broken.

[edit] Anki Deck Export

I would like to propose a new export type to support Learning C/C++, STL, and C++ version differences. That type is for Anki ( a cross platform flashcard system.

Rationale: I have been trying to catch up on my C++ vs C++11 and brush up on my C++/STL in general using Anki, and an OOP concepts deck ( . The desk is missing allot of answers, so i started adding information from my favourite source -

It struck me that a cppreference Anki deck export may be a possible solution. That is questions auto-generated from the cross reference index, (e.g. what is an rvalue). Or a special questions and answers FAQ Page, or a markup for approved questions and answers in each discussion page?., has the facts of C++ at least, but not all of the the gotcha and best practice answers have questions to reference them.

If it also generated topic filters based on C++ version, class, etc. Then i can use it to filter the cards, to only study C++14 changes for example.

At a minimum it can be exported as tab separated for import. e.g:

What is:${keyword index}<tab>${page keyword(s)}<tab>${html + css for keyword page

That's an interesting idea. Can you elaborate a bit on what you mean by "questions auto-generated from the cross reference index"? I'm not sure if it makes sense to add FAQ-style Q&A here, given the existence of e.g. (which you should check out if you haven't already!), but if you can come up with some way of automatically adapting the existing content of the site to make an Anki deck that might be different. --Nate (talk) 07:37, 11 June 2014 (PDT)
I have been playing with it a bit today. Anki renders the cards as HTML in the interface, so i have essentially spammed the default card stylesheet with the cppreference stylesheet to keep the page formatting. It seems that every section/linkable keyword correlates to an 'answer' or concept worth remembering. The hardest part is of course generating questions. My idea (at least for a first approximation) was to generate the card/question list from the section/keyword list + context in tree. Imagine each section as a flashcard. for example:
Q: What is: Operator Overloading (C++ Language, Expressions)
Q: What is: Assignment operator (C++ Language, Expressions, Operator Overloading)
Q: How do you use: std::basic_string (C++, Strings library)
Remember content repetition is a feature not a bug :). If the concept is reasonably viable, then making it smarter/better could be the next step. I would share the deck i am working on, but i have not added any (c) references to the answers, so don't feel comfortable doing so. -- Timoc (talk) 08:26, 11 June 2014 (PDT)

[edit] Experimental standard libraries

I think it's worth start to document the experimental standard libraries. The namespaces and header names seem to be already decided on and are unlikely to change. The following is my suggestion of how everything could be organized:

  • A new row is added to the main page just above the useful links and C++ libraries row. The libraries are listed in similar style as the libraries that have already made into the standard.
  • All experimental libraries are placed under cpp/experimental/*, where * identifies the library, e.g. fs for filesystem, optional for optional, etc.
  • Since the std::experimental namespace is long and some libraries are put into children namespaces, we won't be able to consistently follow our policy of always qualifying all names. I suggest to relax it; a full proposal is below.
  • All dcl items will have markers like (filesystem TS). We may even want to make links from them to a description somewhere.
  • The specification always follows the most recent draft (unless the draft is ratified in some way).
  • Once the functionality is included into the standard, we add a second description of all functionality. A notice is added to the old pages: "The functionality was included into C++XX with the following changes: XX, YY, ZZ". This separation would reduce the clutter on the new standard. While the same can be said about changes between standards, I expect that much fewer people will be interested in changes between the standard and experimental specifications.

Any opinions? --P12 17:19, 4 March 2014 (PST)

I would certainly like to see the new TS specs made available here - this looks like a reasonable plan of action. --Cubbi (talk) 18:54, 4 March 2014 (PST)
This sounds reasonable. My only concern is that the TS items could be confused with standard items, but I suspect that can be addressed with appropriate visual cues. Perhaps we could make (filesystem TS) appear in a different color and include some sort of similar color change on all pages under experimental/? --Nate (talk) 21:17, 4 March 2014 (PST)
Does this mean we can add the Decimal TR now, too? People are working on its new version, which will be a Decimal TS, but its 2011 ISO TR form already saw some limited support. (for consistency, its path would probably best be experimental/? too, even though the namespace is std::decimal) --Cubbi (talk) 09:38, 5 March 2014 (PST)
I guess so... Are there large differences between the TR and TS? --P12 12:00, 5 March 2014 (PST)
There shouldn't be. It may not even become a TS if n3871 gets merged into C++17 directly.(checked with the author - that's the plan, the new C decimal TS wasn't looked in yet) --Cubbi (talk) 12:41, 5 March 2014 (PST)
Should additions to existing libraries be added to the standard library pages or should they be limited to the experimental section? E.g. does uses_allocator_v belong in the current uses_allocator page as a helper type? Luksy (talk) 19:24, 15 June 2014 (PDT)
This wiki already brings up other standards (namely, boost and POSIX) and individual compiler implementation options in the Notes sections of many individual pages: I think that bringing up experimental standard extensions to existing library components makes perfect sense on the pages of those components. On the other hand, posting entire TS specs might make the standard pages less readable. Then again, tiny additions like uses_allocator_v won't take a lot more space than a link. I imagine a good place for that, in any case, would be in or just under Notes: the top of the page is often too crowded already, and few people look at See also. --Cubbi (talk) 08:15, 16 June 2014 (PDT)
Would it not be better to have a cookie that allows users to configure which standard(s) to show? It'd be great to be able to visit something like the vector constructors and only see the declarations valid for 98/11/14, if I'm using C++11 for instance I'm usually not interested in seeing the older declarations. A set of checkboxes could allow users to enable and disable standard versions and TSs independently. I realize this is a lot of work and perhaps a little pie in the sky, still I think it would be a nice addition and would help for implementing the TSs as well. Luksy (talk) 00:13, 17 June 2014 (PDT)
That cookie already exists: enable the standard revisions gadget, you will get a pulldown menu to choose the desired view (diff/03/11/14). Not sure about the feasibility of a TS view (14+every TS?).. P12 developed that functionality (I think), I'd wait for his comment. --Cubbi (talk) 05:58, 17 June 2014 (PDT)
That's great, I had no idea! I wouldn't think a flag would be needed for every single TS, but the library extensions make a number of small additions and changes in a few places so I thought it might be useful for that at least. Luksy (talk) 16:34, 17 June 2014 (PDT)
I was just looking at the Parallelism TS, and it adds an overload to 70+ existing algorithms. Tempted to just put them in with (parallelism TS) -- visibility is a good thing, and C++14 additions are pretty much done anyway. --Cubbi (talk) 08:38, 1 July 2014 (PDT)
A "14+TS" view doesn't sound too unreasonable, and I certainly like the idea of making these changes visible. How should we reconcile the existing separate TS sections that we currently have with the "inline" parallelism TS info? It would be good to agree on a general strategy for how we are going to include TS info in the future. --Nate (talk) 19:10, 1 July 2014 (PDT)
Since TS is allowed to change the standard (with implications discussed in n4041), How about we change the mainline wiki where a TS changes core language or anything in namespace std (as opposed to std::experimental). Actually by that logic the parallel overloads of the algorithms end up in the parallel TS page, since they are, I think, all in std::experimental::parallel. --Cubbi (talk) 20:54, 1 July 2014 (PDT)
I like it. Unless we get objections from e.g. P12, I'd say we should do this in the future. --Nate (talk) 08:22, 2 July 2014 (PDT)
I like it too. BTW, since I have more free time now, it's likely that the standard revisions gadget will be finished soon. --P12 12:30, 2 July 2014 (PDT)

[edit] Relaxing the policy of always qualifying all names

Inclusion of experimental libraries will result in some components that have very long fully qualified names, e.g. std::experimental::filesystem::recursive_directory_iterator (extreme case). This makes following our policy of always qualifying all names not practical to follow consistently.

Also, one of the original reasons for full qualifications will disappear in the near future. I'm developing a new syntax highlighting plugin that will correctly make links to names even without qualification. So even the std:: prefix will become not strictly needed for practical purposes.

My proposal is as follows:

  • The page title will carry fully qualified name as before
  • Examples and "possible implementation" sections will contain qualified names (possibly using namespace aliases) as before.
  • Any other uses (including declaration in dcl items) will use unqualified names.
  • At the beginning this relaxation will only apply for the experimental features. Once the new syntax highlighting plugin goes live we can remove the std:: prefixes too.

What do everyone think? --P12 17:19, 4 March 2014 (PST)

I think having syntax highlighting for shortened names will be great for long names like your recursive_directory_iterator example. How about we begin by using shortened names in new content when they would otherwise be awkward and see how it looks? (It's less clear to me how much of a win it would be to change e.g. std::vector to vector.) --Nate (talk) 21:34, 4 March 2014 (PST)
That's OK with me. --P12 13:57, 16 March 2014 (PDT)

[edit] Disappearing text problem

The last couple months or so I have been experiencing a strange issue where some or all of the text on the page would be the same color as the background. Here is an example: - It can happen on any page, including the main page. Sometimes refreshing the page fixes it, other times refreshing the page makes it worse. I'm using Google Chrome on Windows. LB(T|C) 11:51, 10 March 2014 (PDT)

Strange. Has anyone else experienced anything like that? --P12 13:12, 10 March 2014 (PDT)
I experienced that a few times last week or two, sporadically, also using chrome for Windows. I was suspecting our corporate web filters and was hoping to see it happen at home (chromium/linux) before I'd report it here. --Cubbi (talk) 13:23, 10 March 2014 (PDT)
I suspect it might have something to do with the fact that we use @fontface declarations to load custom fonts. In this page, when the text disappears, does the red text disappear too? --P12 13:40, 10 March 2014 (PDT)
Just reproduced for me red text is visilbe. --Cubbi (talk) 15:31, 10 March 2014 (PDT)
Okay, that means we need two widely supported fonts (one regular and one monospace) that would have roughly the same cap and median heights. Suggestions? --P12 15:42, 10 March 2014 (PDT)
I think this is a bug in Chrome ( Has anyone noticed this behavior in any other browsers? --Nate (talk) 09:21, 11 March 2014 (PDT)
I have seen it on Firefox on Linux as well, but much less frequently. On Firefox, the most common case is for the text to appear several seconds after the page otherwise finishes loading. On Chrome, the text sometimes does not appear at all, and sometimes reappears after a refresh. I do, however, seem to recall a (single) case where the fonts did not show up on Firefox at all. Shachar (talk) 23:23, 1 April 2014 (PDT)

[edit] Compiler support

I think it's worth to have a page listing compiler support of newly introduced C++ features, because we've started documenting various technical specifications and there's no webpage lists compiler support for these anywhere on the internet. As there was a discussion about this same thing previously, I've just went ahead and added a new page at cpp/compiler_support. The information has been sourced from the stdcxx wiki. --P12 18:32, 20 March 2014 (PDT)

I think it's going to be very hard to keep that usefully up-to-date. Could we at least provide links to the compiler's pages? Clang/Libc++ keep excellent lists: clang (note they started listing the TS's already) libc++ C++14 (looks like they took down C++11 chart for the library since it was 100% back in 2012). Also, the infamous GNU libstdc++. I guess I'll add Oracle compiler status and review IBM's since I use those compilers daily. --Cubbi (talk) 18:58, 20 March 2014 (PDT)
We don't need to be sure the page is absolutely up-to-date. Checking for newly supported features only needs to be done once a month or so. Thus it seems to me that it wouldn't take a lot of effort to maintain the page. As for the links, of course, I think we can link to the official lists for each compiler. --P12 11:01, 21 March 2014 (PDT)
I would find such table to be useful if it had more entries, e.g. match clang++'s tables list. But filling that in for various compilers would be a full-time research project on its own. --Cubbi (talk) 16:44, 22 March 2014 (PDT)

[edit] Concentrated iterator invalidation section

I'm thinking of adding a section to each container saying under what circumstances the iterators are being invalidated. Currently, this information is only available under the specific operations, and getting a global view is difficult. Iterator invalidation is one of the most confusing aspects of working with STL, and this will, I think, make it much clearer. Shachar (talk) 23:26, 1 April 2014 (PDT)

Seeing as the rules are different for almost every individual operation x container combination, do you have a layout in mind that would make them clear? A table perhaps? --Cubbi (talk) 10:09, 2 April 2014 (PDT)
I did unordered_map. It needs some formatting, but I think it turned out fairly concise. My choice was, indeed, a table format. Shachar (talk) 10:27, 2 April 2014 (PDT)
This seems like useful information; I'm for it. Maybe some of the formatting could be borrowed from other tables we already have, e.g. at the bottom of cpp/container. --Nate (talk) 11:25, 2 April 2014 (PDT)
I think such table could included into all container pages just below the current description. I've already pasted your table here. Thanks for bringing this up! --P12 12:14, 2 April 2014 (PDT)
I already put a link to the page at the bottom of that page, so the information is, effectively, there twice. Personally, I think a separate page works better, but I don't feel particularly strongly about it. Shachar (talk) 19:54, 2 April 2014 (PDT)
BTW I think we should have this information in cpp/container too. --P12 12:16, 2 April 2014 (PDT)
I find reference/pointer invalidation to be just as important, if not more that the iterator invalidation. Shouldn't the new subsections include that as well? --Cubbi (talk) 07:14, 12 April 2014 (PDT)
I think that would make sense. --Nate (talk) 06:54, 14 April 2014 (PDT)

[edit] Dealing with large version-specific chapters

When big chapters (like the 'Return type deduction' chapter in cpp/language/function) are enclosed with template {{rev}}, the (C++11)/(C++14) sign become unconspicuous and the effect of {{rev}} probably confuse readers, should some other format be used to solve the problem? --D41D8CD98F (talk) 00:27, 7 June 2014 (PDT)

I agree that's an issue. --P12 13:09, 24 June 2014 (PDT)
Previous talk with Cubbi. Similar problem appears in the page cpp/language/eval_order. (if revboxes were wrapped around both sections Sequenced-before rules (since C++11) and Sequence point rules (until C++11), they would almost occupy the whole page) --D41D8CD98F (talk) 04:14, 29 June 2014 (PDT)
I guess we need a separate template for this. --P12 12:23, 4 July 2014 (PDT)

[edit] RFC: Integration of standards revision gadget

We are thinking about enabling the standard revisions gadget by default for all users. This will alter the way information is displayed relatively significantly, thus it's worth to discuss with the cppreference users before implementing the changes.

Standard revisions gadget basically does a single thing: hides information that is not applicable to a certain standard version selected by user. Such tool becomes more and more necessary as the number of C++ standard revisions grows; the readability of part of the documentation is already reduced (e.g. here).

In the current plans, the standard revision gadget will work as follows:

  • This can be overridden by a separate 'standard revision' menu that we already show. If non-default revision is selected, a HTTP GET parameter is appended to the URL. All links are modified to preserve the standard revision override. The override can be easily cleared via a button. There are keyboard shortcuts to select a standard revision override.
  • Depending on the values of the default standard revision setting and standard revision override, unnecessary information is hidden. It's already possible to try this by enabling the standard revisions gadget in the preferences. Note that the gadget hasn't been completely finished yet.

The above should work in the following use cases:

  • User wants to link to the documentation for specific standard. He selects a standard revision in the menu and pastes the contents of his URL bar somewhere. For example:
  • User browses the internet and finds a link to the documentation of specific standard. He clicks it and the correct documentation is displayed. Personal preference is temporarily overridden (but only on that tab). The user can continue to browse or exit to his preferred documentation any time by clicking a button.
  • The user wants to temporarily browse the documentation of standard that is different than his preferred, but doesn't want to affect other tabs. He simply selects the standard from the menu.
  • User uses a specific standard for most of his work. He wants that the preferred standard is selected automatically whenever he comes to from the results page of some search engine. He selects the default/preferred standard revision.
  • Users without Javascript will have the same experience as now.

Any thoughts and suggestions? --P12 13:47, 8 July 2014 (PDT)

I think it's implied, but to be clear, the "Diff" view remains available, right? A use case I've seen more than once was user can't compile code, looks up the function from the error message on cppreference, sees "(since C++11)" next to it and learns about compiler options. --Cubbi (talk) 14:17, 8 July 2014 (PDT)
Yes, certainly. --P12 14:19, 8 July 2014 (PDT)
I tried enabling the standards gadget on my personal preferences and then viewing pages. However, nothing happens when I select different values in the combobox. It's hard to say whether or not this should be enabled by default when it doesn't appear to work :-). --Legalize (talk) 10:14, 24 July 2014 (PDT)
Could you test it on this page? The changes should be easily seen. If nothing happens, then it's indeed a bug and I'll be very interested in what browser / extensions do you use. --P12 04:42, 25 July 2014 (PDT)
I'm not sure what happened, but at some point it started working for me. --Legalize (talk) 09:07, 4 August 2014 (PDT)

[edit] Delay until text appears

This is related to the "disappearing text problem" noted above, though I think it deserves a separate entry since it's not quite the same as the description at the top of that section. When viewing the site using Safari (e.g. Safari 7.0.6 (9537.78.2)), I usually observe the following: first, much of the site's layout appears, but with no text visible. After a few seconds, the text then loads. I strongly suspect this is due to the use of custom font faces, since, for example, big-O complexity text shows up right away. For what it's worth, the same thing also happens for me on Chrome (37.0.2062.94 on Mac), and it seems to be exacerbated by slow network connections. Sdt (talk) 16:06, 8 September 2014 (PDT)

[edit] Page with list of needed/requested articles

Is there any page with list of requested articles? If not, I suggest to create one. Rutsky (talk) 01:52, 10 December 2014 (PST)

It's mentioned in the FAQ: Pages that could use examples, Pages marked with specific todo items, Pages marked with general todos. Plus, as with any wiki, there is Special:WantedPages --Cubbi (talk) 03:24, 10 December 2014 (PST)
Thank you for comprehensive answer, Cubbi! Actually I was interested to request pages that 1) will explain some concepts of С++ (e.g. "incomplete type") or 2) will give advices on patterns (e.g. "copy and swap idiom"). Consider second: is Cppreference has place for articles such as programming idioms (like WikiBooks' I see that there is book ( with general information (not only C++ reference). And consider first, I actually failed to find some information on this site due to bad built-in search engine — see my next post. Rutsky (talk) 13:18, 17 December 2014 (PST)
incomplete type is cpp/language/type#Incomplete_type also accessible as cpp/language/incomplete type, as you found out. As every standard language concept, it should be featured under cpp/language (in my opinion). I agree that discoverability of core language concepts is poor. One application of compare-and-swap is discussed under copy assignment and again under operator overloading.
As for the idioms in general, it's been discussed on one of these talk pages a while ago, I think the consensus was weak agreement; that's why I added cpp/language/raii and cpp/language/rule of three. Objections to consider:
  • Idioms are not really reference material and may get rather subjective unless discussed in Bjarne's books or similar caliber references. They may work better as a section of the book (might increase interest in it too).
  • Idioms are already covered by another wiki (that wikibook, specifically), why not help them improve it instead of forking the content across the web? --Cubbi (talk) 13:54, 17 December 2014 (PST)

[edit] Built-in search on works bad

Often it's not possible to find even exact matches on site using built-in search.

For example:

I think search results can be improved by configuring current search engine or by switching to other search engine (I see that there are plenty of them: Also one search index should be used for whole site. Rutsky (talk) 13:18, 17 December 2014 (PST)

We started using a custom search engine instead of a fulltext search because the fulltext search yielded somewhat noisy results. I think the idea was to optimize for specific queries like "std::vector" as opposed to more freeform queries like "undefined behavior" the search box would be more of a replacement for a table of contents, rather than what we normally expect from search.
That being said, there is definitely room for improvement. It's possible that we could fall back to a fulltext search if the custom search doesn't return any results, for example. --Nate (talk) 11:27, 20 December 2014 (PST)

[edit] string literal as non type template argument.

Hi All,

As writtent in article :

Template non-type arguments The following limitations apply when instantiating templates that have non-type template parameters:

For integral and arithmetic types, the template argument provided during instantiation must be a converted constant expression of the template parameter's type (so implicit conversion applies). For pointers to objects, the template arguments have to designate the address of an object with static storage duration and a linkage (either internal or external), or a constant expression that evaluates to the appropriate null pointer or std::nullptr_t value. For pointers to functions, the valid arguments are pointers to functions with linkage (or constant expressions that evaluate to null pointer values). For lvalue reference parameters, the argument provided at instantiation cannot be a temporary, an unnamed lvalue, or a named lvalue with no linkage (in other words, the argument must have linkage). For pointers to members, the argument has to be a pointer to member expressed as &Class::Member or a constant expression that evaluates to null pointer or std::nullptr_t value. In particular, this implies that string literals, addresses of array elements, and addresses of non-static members cannot be used as template arguments to instantiate templates whose corresponding non-type template parameters are pointers to data.

So couldn't clearly understand why string literal cannot be used as template argument. As I know string literal has static storage duration and internal linkage.

Thanks Vahagn.

It would be more appropriate to ask on that page's Talk page. Perhaps it needs a clarification, but a string literal converted to a pointer results in the address of some unnamed char object, not in the address of any object with linkage. In any case, C++17 now explicitly bans string literals. --Cubbi (talk) 13:51, 28 December 2014 (PST)

[edit] Class Overview should show prototypes

Hi there,

so I'm browsing some overview-pages on classes, such as cpp/container/vector, but am just shown half (or less than half) of the information I'm interested in.
A good reference overview-page should show prototypes ("function signatures") and not just their names, right?!

This is extremely useful if searching for particular member-functions of a class. Currently it is a waste of my time, if I have to click into the individual member-functions all the time, only to find... "oh no not this one. Back button ... hmmm maby this function. Ok I'll click into it... etc".

Here's an example where the prototypes are shown:
Make no mistake about it. The Qt documentation is good. Really good; esp. as a reference!

Can we not have something similar here?
Just a thought.

Mik (talk)

are you looking for the header synopses, such as cpp/header/vector? --Cubbi (talk) 07:32, 15 March 2015 (PDT)

This is slightly better; but still I am not really happy -- I see for example
void push_back(T&& x);
but no link to get more information on it. But in contrast to this...
I think the Qt documentation is probably one of the best documentation documents regarding C++.
(As far as I can see, Qt generates it's documentation via QDoc (similar to Doxygen -- ref); here's the source of QList with its inline documentation: link.)
Mik (talk)

Heck, and while not as good as Qt in terms of documentation, I nonetheless think I also prefer libstdc++'s doxygen documentation. Here's an example:
Mik (talk)

[edit] Feature testing macros

I couldn't find any real page for the feature test macros from SD-6 Feature Test Recommendations.

Some of those macros are mentioned in the relevant pages (eg: __cpp_experimental_concepts in cpp/language/constraints).

There is a user page which contains some of them. Can I go on and make it into a real page? (and add the missing stuff)

--Bazzy 14:33, 23 March 2015 (PDT)

I'm not sure whether the standalone page would be as useful as mentioning the feature test macros on the same pages as the features being tested: even cpp/experimental/lib_extensions#Feature test macros feels too separated from what it talks about. As a programmer looking up documentation on std::experimental::string_view, for example, I am going to open cpp/experimental/basic_string_view and I should see __cpp_lib_experimental_string_view mentioned there. A list of every macro could be useful too, if you're willing to spend time on it (and it looks like User:D41D8CD98F was going to do that as well), I just can't think of a scenario where it's needed other than looking up the meaning of the term "feature test macro". --Cubbi (talk) 14:48, 23 March 2015 (PDT)
Part of that standing document are also __has_include and __has_cpp_attribute which are worth describing, the list of macros could belong to the page describing those.
Maybe we could have that page which shows the list macros with their various versions, and on the pages describing the feature, have in the see also section something which produces a link to the macro list page.
__cpp_constexpr for instance has a different meaning depending on its value, showing this on the feature page might become more awkward than helpful as new versions come out. --Bazzy 15:20, 23 March 2015 (PDT)
Forgot about __has_include. I agree feature test macros need to exist on their own page, probably side-by-side with the TS's under cpp/experimental --Cubbi (talk) 19:15, 23 March 2015 (PDT)

[edit] Is there a better way to present constexpr additions?

Currently, when constexpr is added to a function, the entire signature is duplicated, constexpr and a (e.g.) (since C++14) is added, and the old one is marked as (e.g.) (until C++14). Like this:

template< class T >
const T& max( const T& a, const T& b );
(until C++14)
template< class T >
constexpr const T& max( const T& a, const T& b );
(since C++14)

This feels...suboptimal. It's extra duplication, and the reader will need to compare the entire signature before they can figure out that the only difference is addition of constexpr.

Is there a better way of doing this that makes it more obvious what has changed? Perhaps something like

constexpr(since C++14) const T& max( const T& a, const T& b );

? T. Canens (talk) 13:45, 23 May 2015 (PDT)

I think the idea was that the users select a particular revision (from the pulldown menu on top right) and don't even see the diffs.. maybe rev inl or something like that could work better? --Cubbi (talk) 14:21, 23 May 2015 (PDT)
Hmm, I didn't even know that gadget exists...and it isn't on by default, so non-logged-in users (which is the vast majority, I think) won't be helped by it. Something similar to {{rev inl}} could work, although I don't know how well it meshes with the syntax highlighting. T. Canens (talk) 14:39, 23 May 2015 (PDT)
I've resumed work on this gadget again, but to enable it by default for non-logged users, the gadget needs to reasonably handle quite a lot of cases it fails at the moment. I'm slowly building a regression test suite and fixing these bugs, but it's hard to find edge cases in such a large wiki. If you find any pages in which the gadget does not hide content it should, could you post the links on my talk page so that I can have a look? Many thanks! --P12 19:10, 7 August 2015 (PDT)

[edit] The search box, again

Can it be made so that if I type cpp/language/adl in it and press Enter, it takes me to cpp/language/adl (i.e., if there's a page whose title is an exact match with the search text, take me to that page rather than using the index-based "search")? This is how it works on Wikipedia, and the current behavior (which almost always leads to a "no results found") is rather irritating. T. Canens (talk) 16:43, 10 July 2015 (PDT)

That seems pretty reasonable...I'll take a look and see how hard it would be to make that happen. --Nate (talk) 21:35, 12 July 2015 (PDT)

[edit] Broken search box

Example: I type "typename" in the search box, and it shows me "no results found".

This is broken and wrong. Many pages should be listed, all of those containing the keyword "typename". Or I should should be redirected to .

Any of the above behaviours would be correct. But telling me that "no results found" seems to be a bug.

I'm adding typename and the other missed keywords. --Cubbi (talk) 11:10, 28 July 2015 (PDT)
Still not completely done. Just try typing "cstdint" or "stdint.h" in the search box. Why doesn't show up?
Yes, library header files haven't been indexed. Added to the TODO list --Cubbi (talk) 05:42, 27 October 2015 (PDT)
  • And a Yet Another Search Box Bug™: See the results of typing "size_t" in the search box. Click on the only result in the C column (not C++ column). And great, you are being pointed to C++ documentation of std::size_t! ( ) While of course, one should be pointed to ( ). The sheer amount of bugs with this search box kinda defeats any point to use it. More and more often I find myself using just Google with
I can't reproduce this issue, when I click on the only result for size_t in the C column I land on . The search box only shows the terms that were indexed (allowing for typos), it's not a full text search. --Cubbi (talk)
Oddly enough, I can't reproduce this issue either. I dunno; perhaps someone was lighting-fast fixing it, or maybe I got clueless reporting it :)
yes, the C side is poorly indexed right now, it will happen --Cubbi (talk) 08:38, 4 November 2015 (PST)
can't reproduce, I see two links on the C++ side of the results (and nothing on the C side) --Cubbi (talk) 08:38, 4 November 2015 (PST)
Fun. Can't reproduce now either again. But I swear it was happening when I was posting. I guess sb was lightning-fast again :)
There weren't any edits.. Pinging User:P12 and User:Nate, this might be a bug in the backend. --Cubbi (talk) 11:11, 4 November 2015 (PST)
Yeah, this is strange. Nothing has changed on the backend, so this might be a long-standing bug in the custom search code. Being redirected to the pointer_safety page makes sense because it mentions the 'strict' enum, and might happen if the 'struct declaration' result wasn't found. I'll poke at it a bit when I get a free moment. --Nate (talk) 09:32, 5 November 2015 (PST)
Makes sense, because std::ios_base::Init wasn't in (Oh the fun of a manual index!) I've added it now; let's see if it starts working in the next few hours. --Nate (talk) 19:49, 7 November 2015 (PST)
Gah, seems to work for me now. Maybe this is another example of flakiness, like 'struct' above periodically not including cpp/language/class? --Nate (talk) 04:55, 12 November 2015 (PST)

[edit] Members of a type introduced later

Is there / Should there be a way to mark that a member available since a specific revision is an original member of the base-element (namespace/type)? 05:49, 8 December 2015 (PST)

[edit] What about ?

The project seems to be dead. This might be because it doesn't seem to be linked from here, and book's recent changes seem to be independent from the "main wiki"'s recent changes.

But articles from come up in google. For example, googling "uninitialized value cppreference" brings up as the third result. And since the project seems to be dead, any errors, inaccuracies, obsoletisms are unlikely to be corrected. The project's main page explicitly claims the wiki is in alpha stage, so such problems are likely to occur regularly.

For example, the aforementioned claims that "Reading the value of an uninitialized variable is undefined behaviour". This seems to be a gross oversimplification. I'm not an expert, so I'm not sure, but according to and the situation is far more complex. I complained about this problem on but since the project seems to be dead, and its recent changes are independent from the main wiki's recent changes… well… I think I might have not written this message at all as well.

If I were you, I'd either merge with the main wiki (merge the projects' recent changes and put links to in in the hope that the book project receives some attention or go ahead and delete it at all. Depending on whether has any information that might be useful.

regarding undefined behavior on access to uninitialized variable, it is described in more detail at cpp/language/default_initialization --Cubbi (talk) 18:11, 13 January 2016 (PST)
Well actually, I'd say that even cpp/language/default_initialization does not describe the situation in all of its complexity, judging from the aforementioned StackOverflow answers. For example, your article fails to mention trap representaions..
traps are mentioned in cpp/language/object#Object_representation_and_value_representation. I suppose a link from default-init is a good idea. --Cubbi (talk) 08:54, 20 January 2016 (PST)

[edit] What This Code means?

Hi every one, may I have help? Can you please explain/discuss what this line of codes means?

dot11smt OBJECT IDENTIFIER ::= { ieee802dot11 1 }

That is in ASN.1 not C++ QuentinUK (talk) 00:41, 5 March 2016 (PST)

[edit] {{langlinks}}

I'm tired of the piles of repetitive interwiki links to other languages at the bottom of most pages, so I've made {{langlinks}}. {{langlinks|de|zh}} on a page named [[Foo/Bar/Baz]] is equivalent to [[de:Foo/Bar/Baz]][[zh:Foo/Bar/Baz]]. Up to 13 arguments are supported - which is the number of interwiki links on the main page.

The template User:T. Canens/xform interwiki can be used to transform existing interwiki link piles into {{langlinks}} invocations. It must be substituted. For example,

{{subst:User:T. Canens/xform interwiki|1=

becomes {{langlinks|ar|de|es|fr|it|ja|pt|ru}}. T. Canens (talk) 14:58, 22 March 2016 (PDT)

Great, that'll be useful. :) --Nate (talk) 06:24, 24 March 2016 (PDT)