Difference between revisions of "Talk:Main Page"

Revision as of 13:39, 23 May 2015

Archives	Archive 1 Archive 2

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.

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.

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 (https://ankiweb.net/) 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 (https://ankiweb.net/shared/info/2053137949) . The desk is missing allot of answers, so i started adding information from my favourite source - cppreference.com.

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?. cppreference.com, 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. https://isocpp.org/faq (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)

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)

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)

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: http://i.imgur.com/F8FPMrO.png - 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 (https://code.google.com/p/chromium/issues/detail?id=336476). 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)

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)

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)

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)

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:

• The user may select the default standard revision he prefers (see the following mockups: options collapsed, options expanded, no javascript). The setting is displayed in a new collapsible options section on the heading.

• 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: http://en.cppreference.com/cpp/container/vector/insert?std=cxx11.

• 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 cppreference.com 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)

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)

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' https://en.wikibooks.org/wiki/More_C%2B%2B_Idioms)? I see that there is book (http://en.cppreference.com/book/Main_Page) 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)

Built-in search on en.cppreference.com works bad

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

For example:

• "type_traits", "<type_traits>", "header type_traits" — nothing found. Same result with some of other headers. Should found: http://en.cppreference.com/w/cpp/header/type_traits

• "incomplete", "incomplete type" — nothing found. External search engines found http://en.cppreference.com/w/cpp/language/type#Incomplete_type

• "undefined behavior" — nothing found. External search engine found http://en.cppreference.com/book/undefined_behavior. And, actually, search on http://en.cppreference.com/book/ found same page. Looks like, that different parts of cppreference.com are handled by separate MediaWiki engines with different search indexes.

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: https://www.mediawiki.org/wiki/Fulltext_search_engines). 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"...so 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)

string literal as non type template argument.

Hi All,

As writtent in article : http://en.cppreference.com/w/cpp/language/template_parameters

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)

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:
http://doc.qt.io/qt-5/qvector.html
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.

Thanks.
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++.

• There I have long class documentation documents, that supports Ctrl-F quick searches. I don't have to click into links and hit the browser back-button the whole time. Driving me crazy.
• There I have a really good document structure (and functions shown with prototypes, and links to more detailed information [later, but on the same document!!!]):
  
  Just have a look at QList documentation as an example. What a brilliant document. All I need and am interested in, is on one page (Crtl-F power!). And a good structure (with prototypes linking to more detailed information lower in the page):
  • Public Types
  • Public Functions
  • Static Public Members
  • Related Non-Members
  • Detailed Description
  • More detailed Member Documentation
    • Member Type Documentation
    • Member Function Documentation (also lists static function members)
    • Related Non-Members

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

• std::vector

• Public Types
• Public Member Functions
• Protected Member Functions
• Protected Attributes
• Detailed Description
  • Constructor and Destructor Documentation
  • Member Function Documentation

Mik (talk)

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)

Is there a better way to present constexpr additions?

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

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)