User talk:P12

I was looking at your changes to cpp/language/range-for, and they're not exactly correct. For example, std::begin is not required or always used; __begin is initialized using a ADL lookup of the function "begin" (except in the case of arrays!), which often resolves to the std::begin one, but not always. I'm considering reverting some of your edits for correctness, but I'd like your help in making it more readable. What do you think? -- Jaredgrubb 15:23, 29 August 2011 (PDT)

Oh, these changes are surely incorrect. I've reverted them and added the std::begin/end links to the text below. Thanks for pointing that out.P12 16:55, 29 August 2011 (PDT)

Standard specializations

I feel that it would be useful, for any functions/trait/class template that has standard-mandated specializations/overloads, to link all those specializations on the general template's page. That means, to take the most complicated example, that the page for std::swap would have a block containing

standard specializations
std::swap(std::pair) (C++11)	specializes the std::swap algorithm (function template)
std::swap(std::tuple) (C++11)	specializes the std::swap algorithm (function template)
std::swap (C++11)	specializes the Template:cpp/ltf algorithm (function template)
std::swap	specializes the Template:cpp/ltf algorithm for std::shared_ptr (function template)
std::swap	specializes the Template:cpp/ltf algorithm for std::unique_ptr (function template)
std::swap (C++11)	specializes the Template:cpp/ltf algorithm for functions (function template)
std::swap (C++11)	specializes the Template:cpp/ltf algorithm for basic_regex (function template)
std::swap (C++11)	specializes the Template:cpp/ltf algorithm for packaged_task (function template)
etc...

Should all those link item names (once they all become templates) mention the specialization in their link title, just like they already do in their page title, as in

std::swap(valarray) (C++11)

specializes the Template:cpp/ltf algorithm for std::valarray (function template)

--Cubbi 03:34, 14 September 2011 (PDT)

Yes, we can do that. The last suggestion is also worth implementing, since that would be more consistent. The 'for std::valarray' part could be dropped then since it becomes redundant.

Also, we can use similar syntax for class template specializations such as std::uses_allocator. P12 13:04, 14 September 2011 (PDT)

Numeric limits restructuring

Take a look at my proposal on the numeric limits talk page --Cubbi 08:30, 5 October 2011 (PDT)

Type trait/metaprogramming examples

I feel that the this edit replaced a semi-practical use case (compile-time decision based on unique type property) with somewhat ambiguous classification that is only useful for debugging purposes. Granted, it's hard to come up with simple examples that point out why does each type trait exist, but that one was fairly simple, it even had less lines of code than the new example. --Cubbi 12:05, 26 October 2011 (PDT)

The reason why I replaced this and several other examples was too much complexity in what is decided at compile-time, e.g. very generous use of enable_if and similar stuff. I think a better idea would be something like if (std::is_***) { do_something_in_this_case } else { do_something_otherwise } in the body of a function template as it shows the same idea with much less complexity. Regarding the code size it's not that I'm against long examples, but I dislike complex ones. If an example is modularized, it can be very long and still simple because only small number of lines must be understood at once, e.g. 10 different semi-independent 5-line examples is much better than one complex 20-liner. P12 12:40, 26 October 2011 (PDT)

To me it seems counter-intuitive to use if and cout<< instead of enable_if and static_assert, when describing the tools that exist primarily for the purpose of compile-time programming. But there's a lot of other work to be done, I don't mind letting those examples sit for now (as long as they compile). --Cubbi 12:57, 26 October 2011 (PDT)

Meanwhile I'll try to think of something which is both clear and demonstrates type traits well.P12 13:20, 26 October 2011 (PDT)

milliseconds

Something is broken in the way <std::chrono::milliseconds> is displayed inside a cpp template. On my chrome I am seeing <chrono::milliseconds">std::chrono::milliseconds> instead of just <std::chrono::milliseconds> --Cubbi 13:43, 27 December 2011 (PST)

Hi. This was caused by a typo in the function/class index (git) from which I generate the link index for the syntax highlighter. I've fixed it. Thanks for finding the bug! P12 04:54, 28 December 2011 (PST)

Looks like std::mbstate_t is experiencing the same problem. --Cubbi 14:02, 10 January 2012 (PST)

mem=

How come in Template:dcl_list_mem_fun we have {{mark mem fun | mem={{{mem|}}}}}, but in Template:dcl_list_mem_class we have only {{mark mem class}}? I wanted to put a see-also to std::ios_base::failure in std::iostream_category, but it would look better as "failure: member class of ios_base", rather than just "failure: member class". --Cubbi 12:12, 10 January 2012 (PST)

The {{{mem}}} was just a hack for some functions at first. I will add that parameter to the class template also. I think that we need a better solution though. P12 12:27, 10 January 2012 (PST)

Code examples

Hello P12, I noticed you moved some code examples from the page with the main feature description to sub-topic pages. E.g. at std::unordered_map or std::function. What is the reason for that? I assume I am not the only person who, when trying to understand a feature, first wants to see an example. With the conventions you applied, one has to expect and find examples on the sub-topic pages. A solution could be to add sections titled "See examples at" or similar to the main feature description. These sections would list those sub-topics containing examples. --Bear 04:36, 24 February 2012 (PST)

Hi. I think that it's more appropriate to put examples into the sub-pages because it's hard to completely demonstrate usage of any non-trivial class in one example. A number of smaller examples in sub-pages are easier to understand, since each of them examines much smaller subset of features at once, and those features themselves are much more related. Also, an example on the class page would need to be either very long in order not to leave out a lot of important things. The examples on the sub-pages, on the contrary, could be smaller and cover more usage cases in total.

As for listing pages with examples, I'm not sure if I understood you correctly. Did you mean that having examples only on sub-topic pages but not on the main feature pages is unintuitive? Or did you mean that only part of the sub-topic pages have an example? The former problem is IMO not a big issue, since one would always open a sub-page for a more detailed description and find an example there. The latter issue will solve by itself eventually I think, since each page describing non-trivial functionality should have an example (even if there is no "Example" section). What do you think about that? -P12 06:15, 24 February 2012 (PST)

OK, I didn't think of the possibility that, some day,each page describing non-trivial functionality will have an example. Maybe I can reformulate my question as follows. Should we provide anything for the impatient reader? Often, I (once again I assume this is true for others as well) don't want to read about all the details of a class in the beginning. Instead I want to see a short example demonstrating the basics. Your argument is based on the assumption that examples on main pages should be complete with respect to the various features. One could also argue that examples there should be as short as possible. Otherwise, where could we put introductory examples and how could we guide the reader to find them?--Bear 11:15, 24 February 2012 (PST)

Examples are a powerful way to quickly communicate usage, and could be a great supplementary method of explaining what e.g. std::unordered_map is to people who have never seen it before. Clearly top-level examples couldn't (and shouldn't) contain everything -- but if we could agree on what "the basics" are, I think they could be useful. Nate 11:42, 24 February 2012 (PST)

To add to this discussion, I see different kinds of examples:

* technical examples, demonstrating many (all) ways to call a particular function, whether common or obscure (e.g. cpp/locale/wstring_convert/wstring_convert or cpp/io/basic_istream/get)

* practical examples, showing how some function may be used to solve a practical task, perhaps in a non-trivial way (e.g. cpp/types/numeric_limits/epsilon or cpp/algorithm/rotate or cpp/algorithm/iter_swap)

* common use cases, showing how some function/class *is* typically used, (e.g. cpp/string/basic_string/operator+ or cpp/locale/codecvt -- the class doesn't even appear in the example, but it's how it is normally used)

* trivial examples, which simply repeat what's already explained in the description, but do not demonstrate a common or practical use case, e.g. cpp/types/is_void

if it were up to me, I'd put common use cases on the class pages and technical/non-trivial examples on the function pages. --Cubbi 14:45, 24 February 2012 (PST)

Well, if we consider the examples at the class pages introductory, not technical, then I agree that they are useful and we should have them. So the consensus seems clear. P12 06:06, 25 February 2012 (PST)

std::partition 'Possibly' equivalent function

You said: All examples of the equivalent function (even of the simple algorithms) are _possible_ implementations. IMO there's no need to write 'possible' explicitly - that's obvious.

I didn't mean that the function was a possible implementation, that is obvious. But I said the given implementation is only possibly equivalent with a standard compliant implementation. There will be standard compliant implementations that are not equivalent with that function because the order within each partition is not fixed by the standard but is fixed by an implementation. I guess a better term would be "Example implementation" or "Standard compliant implementation" but not "Equivalent function" because this is not necessarily true. Anyway, I'll leave it up to you what to write there.

I agree. "Example implementation" or similar would introduce less possibilities for confusion. P12 09:28, 16 March 2012 (PDT)

"implicitly defined and inherited functions"

You've removed what() and operator= from std::bad_alloc calling them "implicitly defined and inherited". They are not; they are explicly defined in §18.6.2.1 of the C++11 standard as follows

   bad_alloc& operator=(const bad_alloc&) noexcept;
   4 Effects: Copies an object of class bad_alloc.
   virtual const char* what() const noexcept;
   5 Returns: An implementation-defined NTBS.

Granted, <stdexcept> exception classes don't define these, but bad_cast, bad_typeid, bad_alloc, and bad_exception define both what(0 and operator=, and system_error and future_error defines their own what(), but not operator=. Although it seems like a discrepancy, this is still a standard's requirement. --Cubbi 06:15, 28 March 2012 (PDT)

My edit summary was certainly not as clear as it should have been. I agree that the issue with what() is more complicated, because one might want to take an address of it. But the operator= seems to be equivalent to the implicitly defined one. Is there any user-visible difference if the declaration is omitted? -- P12 06:34, 28 March 2012 (PDT)

Ah yes, the operator would be inlined. So enough reasons to put everything back. -- P12 06:36, 28 March 2012 (PDT)

Identify the section of the standard where an element is define

Hi, I was wondering if it would be possible to add an optional field in template ddcl which would identify the section of the standard where an element is defined. It would be great for when one want to go and get further informations on a given element. In the case of the vector class, it would look like this:

[templates removed]

Authchir 19:52, 3 April 2012 (PDT)

Hi. While this additional field would certainly be useful for some, I don't think the advantages outweigh the disadvantages. Most readers use the standard very rarely or don't use it at all, so for them such information only clutters the definition and maybe is even confusing. Also, in my experience, it's fairly easy to find definitions in the standard already, since the structure of the wiki is fairly consistent with that of the standard. Finally, this wiki should eventually provide complete reference of the standard. There are no intentions to simplify anything, so if the standard has more information about a particular feature, the best solution is to copy that information here. In the end, one wouldn't need to read the standard at all, everything would be described in this wiki.

Having said that, we could add a list of relevant sections of the standard at a less prominent place. One option would be to add a references section at the end of the article similarly to how the regular Wikipedia does. Any opinions? -- P12 12:26, 5 April 2012 (PDT)

Hi, I understand your point and think your idea of inserting a less aggressive references section at the bottom is a good idea. Authchir 13:42, 5 April 2012 (PDT)

A minor note about the tt element

This could probably be considered a minor point, and this might not be the correct place to discuss this, but: There are many instances of the tt element in this wiki, and it's considered obsolete in HTML5:

Where the tt element would have been used for marking up keyboard input, consider the kbd element; for variables, consider the var element; for computer code, consider the code element; and for computer output, consider the samp element. -- Obsolete features

As far as I can tell, most instances of the tt element should probably be replaced by the code element. If you/someone consider this important, maybe it's possible to do a mass rewrite somehow (because doing it manually would be extremely tedious ...). -- Cic 11:22, 12 July 2012 (PDT)

It isn't hard to fix this issue by automatic search/replace, so we can do that. Out of curiosity, did you encounter any practical problem with the <tt> tags? -- P12 03:23, 13 July 2012 (PDT)

No, I didn't experience any rendering problems or the like, I was editing a page and noticed the element. On a related note, GeSHi only wraps code in spans it seems (rather than using the code element). This holds true for both inline code and "code blocks" (rather than having e.g. <pre><code>[...]</code></pre> as shown in the standard). -- Cic 04:00, 13 July 2012 (PDT)

The new list syntax

Looks like the new list syntax, @1@, @2@, etc. isn't working on pages that are templates: take a look at cpp/iterator/back_insert_iterator/operator=, cpp/iterator/front_insert_iterator/operator=, cpp/iterator/insert_iterator/operator= --Cubbi 08:04, 6 September 2012 (PDT)

Thanks for noticing. I've fixed the extension. If any pages still show @1@, etc., they need to be purged by appending "?action=purge" to the url and accessing it. I would be interested in any cases where wrong output doesn't disappear even after purge. -- P12 15:02, 6 September 2012 (PDT)

implicit conversions of return values

I see the cuchar/uchar.h functions got edited to return -1, -2, -3 instead of (size_t)(-1), (size_t)(-2), (size_t)(-3). I thought to undo, but then stopped because perhaps it makes sense as a wiki policy: should we stick to the letter when the return value of a library function is specified with a cast in the standard, or should we omit the cast when it would be the same as the implicit conversion? There's a bunch of other functions besides the uchar.h/cuchar that return negative integers cast to size_t, and there are the functions that return -1 cast to other types (time_t, clock_t, off_t). --Cubbi 14:05, 16 September 2012 (PDT)

I think we don't need to be as precise as the standard, because the standard has to be such that there's zero chance for ambiguity. In our case we can trade a bit of preciseness for more clarity. Even then, it's hard to imagine that someone would mistake -1 for something other than static_cast<size_t>(-1) as size_t is in the function prototype. Thus I think omitting the explicit cast is worthwhile. -- P12 06:00, 17 September 2012 (PDT)

Machine translation and language links

The translation scripts should be configured to add [[en:]] and remove the link to the target language ( See [1] ) --Bazzy 08:12, 1 November 2012 (PDT)

These will be fixed automatically as a separate step when all translations are completed. Only one translation is left (Russian), so I expect that a bot will be run to correct the links in the next few days. P12 10:13, 1 November 2012 (PDT)

Is there any way to get back the deleted content of the page ru:Template:cpp/language/sidebar_content? Because as far as I remember that page has already been translated and now its navbar-equivalent should be translated again (i.e. improved after Google Translate). -- Radix 04:31, 10 January 2013 (PST)

Does the page history help? http://ru.cppreference.com/mwiki/index.php?title=%D0%A8%D0%B0%D0%B1%D0%BB%D0%BE%D0%BD:cpp/language/navbar_heading&action=history

--Nate 16:21, 10 January 2013 (PST)

I've restored the page. Thanks for notice. P12 16:54, 10 January 2013 (PST)

Ok, I have made the replace. Thanks for helping. -- Radix 02:49, 11 January 2013 (PST)

What is the playground page for?

I'm wondering what is the playground page for? I've discussed it more in detail at talk section of the main page. I've asked you because you are the user that edited that page most frequently.

Thanks for the question. I think Nate has answered it better than I could. --P12 09:52, 15 October 2013 (PDT)

Arabic version of cppreference

Your expertise (and admin powers) are needed over at ar.cppreference. As there might be more than one issue appearing, I prefer to have the conversation over there.

A3f.at (talk) 14:44, 11 January 2015 (PST)

I'll look into it, thanks --P12 12:03, 12 January 2015 (PST)

CSS

The css Mediawiki:Common.css for languages other than english is not up to date. Would you please synchronize them to the english version? It is restricted for users to edit it. Hiroo (talk) 23:20, 28 June 2015 (PDT)

What exact issues do you see? At this time it's not possible to simply copy and paste CSS across languages. --P12 05:50, 28 July 2015 (PDT)

Please update Russian wiki CSS (http://ru.cppreference.com/mwiki/index.php?title=MediaWiki:Common.css&action=edit) so to its English version (http://en.cppreference.com/mwiki/index.php?title=MediaWiki:Common.css&action=edit) so we can use .t-mark-rev.t-mark-ts styles etc. DJm00n (talk) 06:54, 15 September 2015 (PDT)

I've copied the English stylesheet to Russian wiki and updated several templates that needed changes. Please tell me about any issues you see. Thanks :) --P12 13:16, 16 September 2015 (PDT)

Ping

User talk:Cubbi#autolinker seems broken? Thanks! T. Canens (talk) 21:16, 4 December 2015 (PST)

Front Page

In the front page, the escape sequence in the C section is linked to the C++ counter part. Fefe (talk) 07:13, 2 January 2016 (PST)

I'm guessing that we just haven't branched that specific page yet. I think it would probably be okay to start by copying the C++ version over to the C side...much of the content will be the same but doing so will allow us to eventually update it to reflect any differences. --Nate (talk) 07:35, 2 January 2016 (PST)