View source for User talk:P12

Please contact me at povilas@radix.lt as I don't monitor the discussion pages often. 

-----
-----
-----


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?
-- [[User:Jaredgrubb|Jaredgrubb]] 15:23, 29 August 2011 (PDT)
: Oh, these changes are surely incorrect. I've reverted them and added the {{c|std::begin/end}} links to the text below. Thanks for pointing that out.[[User:P12|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 {{c|std::swap}} would have a block containing
{{dcl list begin}}
{{dcl list h2 | standard specializations }}
{{dcl list template | cpp/utility/pair/dcl list swap2}}
{{dcl list template | cpp/utility/tuple/dcl list swap2}}
{{dcl list tfun | cpp/numeric/valarray/swap2 | title=std::swap | specializes the {{cpp/ltf|cpp/algorithm/swap}} algorithm| notes={{mark c++11}}}}
{{dcl list tfun | cpp/memory/shared_ptr/swap2 | title=std::swap | specializes the {{cpp/ltf|cpp/algorithm/swap}} algorithm for {{c|std::shared_ptr}}}}
{{dcl list tfun | cpp/memory/unique_ptr/swap2 | title=std::swap | specializes the {{cpp/ltf|cpp/algorithm/swap}} algorithm for {{c|std::unique_ptr}} }}
{{dcl list tfun | cpp/utility/functional/function/swap2 | title=std::swap | specializes the {{cpp/ltf|cpp/algorithm/swap}} algorithm for functions | notes={{mark c++11}}}}
{{dcl list tfun | cpp/regex/swap2 | title=std::swap | specializes the {{cpp/ltf|cpp/algorithm/swap}} algorithm for basic_regex | notes={{mark c++11}}}}
{{dcl list tfun | cpp/thread/swap2 | title=std::swap | specializes the {{cpp/ltf|cpp/algorithm/swap}} algorithm for packaged_task | notes={{mark c++11}}}}
{{dcl list item | etc...}}
{{dcl list end}}
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
{{dcl list begin}}
{{dcl list tfun | cpp/numeric/valarray/swap2 | title=std::swap{{small|(valarray)}} | specializes the {{cpp/ltf|cpp/algorithm/swap}} algorithm for {{c|std::valarray}} | notes={{mark c++11}}}}
{{dcl list end}}
--[[User:Cubbi|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 {{c|std::uses_allocator}}. [[User:P12|P12]] 13:04, 14 September 2011 (PDT)

== Numeric limits restructuring ==

Take a look at my proposal on the [[Talk:cpp/types/numeric_limits|numeric limits talk page]] --[[User:Cubbi|Cubbi]] 08:30, 5 October 2011 (PDT)

==Type trait/metaprogramming examples==
I feel that the [http://en.cppreference.com/mwiki/index.php?title=cpp%2Ftypes%2Fis_trivially_copyable&action=historysubmit&diff=12413&oldid=12259 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. --[[User:Cubbi|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 {{c|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. [[User:P12|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).  --[[User:Cubbi|Cubbi]] 12:57, 26 October 2011 (PDT)
::: Meanwhile I'll try to think of something which is both clear and demonstrates type traits well.[[User:P12|P12]] 13:20, 26 October 2011 (PDT)

== milliseconds ==

Something is broken in the way {{c|1=<std::chrono::milliseconds>}} is displayed inside a cpp template. On my chrome I am seeing <nowiki><chrono::milliseconds">std::chrono::milliseconds></nowiki> instead of just <nowiki><std::chrono::milliseconds></nowiki> --[[User:Cubbi|Cubbi]] 13:43, 27 December 2011 (PST)

: Hi. This was caused by a typo in the function/class index ([https://github.com/p12tic/cppreference-doc/blob/master/index-functions.xml git]) from which I generate the link index for the syntax highlighter. I've fixed it. Thanks for finding the bug! [[User:P12|P12]] 04:54, 28 December 2011 (PST)

Looks like {{c|std::mbstate_t}} is experiencing the same problem. --[[User:Cubbi|Cubbi]] 14:02, 10 January 2012 (PST)

== mem= ==

How come in [[Template:dcl_list_mem_fun]] we have <nowiki>{{mark mem fun | mem={{{mem|}}}}}</nowiki>, but in [[Template:dcl_list_mem_class]] we have only <nowiki>{{mark mem class}}</nowiki>? 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". --[[User:Cubbi|Cubbi]] 12:12, 10 January 2012 (PST)
: The <nowiki>{{{mem}}}</nowiki> 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. [[User:P12|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 {{c|std::unordered_map}} or {{c|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.
--[[User:Bear|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? -[[User:P12|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?--[[User:Bear|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. [[User:Nate|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. --[[User:Cubbi|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. [[User:P12|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. [[User:P12|P12]] 09:28, 16 March 2012 (PDT)

== "implicitly defined and inherited functions" ==

You've removed what() and operator= from {{c|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.  --[[User:Cubbi|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? -- [[User:P12|P12]] 06:34, 28 March 2012 (PDT)
:: Ah yes, the operator would be inlined. So enough reasons to put everything back. -- [[User:P12|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]

[[User:Authchir|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? -- [[User:P12|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. [[User:Authchir|Authchir]] 13:42, 5 April 2012 (PDT)

== A minor note about the <code>tt</code> 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 <code>tt</code> element in this wiki, and it's considered obsolete in HTML5:

<blockquote>Where the <code>tt</code> element would have been used for marking up keyboard input, consider the <code>kbd</code> element; for variables, consider the <code>var</code> element; for computer code, consider the <code>code</code> element; and for computer output, consider the <code>samp</code> element. -- [http://www.whatwg.org/specs/web-apps/current-work/multipage/obsolete.html#tt Obsolete features]</blockquote>

As far as I can tell, most instances of the <code>tt</code> element should probably be replaced by the <code>code</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 ...). -- [[User:Cic|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|&lt;tt&gt;}} tags? -- [[User:P12|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 <code>span</code>s it seems (rather than using the <code>code</code> element). This holds true for both inline code and "code blocks" (rather than having e.g. <code>&lt;pre>&lt;code>[...]&lt;/code>&lt;/pre></code> [http://www.whatwg.org/specs/web-apps/current-work/multipage/grouping-content.html#the-pre-element as shown in the standard]). -- [[User:Cic|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{{=}}]] --[[User:Cubbi|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. -- [[User:P12|P12]] 15:02, 6 September 2012 (PDT)

== implicit conversions of return values ==

I see the cuchar/uchar.h functions got edited to return {{c|-1}}, {{c|-2}}, {{c|-3}} instead of {{c|(size_t)(-1)}}, {{c|(size_t)(-2)}}, {{c|(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). --[[User:Cubbi|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 {{c|-1}} for something other than {{c|static_cast<size_t>(-1)}} as {{c|size_t}} is in the function prototype. Thus I think omitting the explicit cast is worthwhile. -- [[User:P12|P12]] 06:00, 17 September 2012 (PDT)

== Machine translation and language links ==

The translation scripts should be configured to add <nowiki>[[en:]]</nowiki> and remove the link to the target language ( See [http://it.cppreference.com/mwiki/index.php?title=Pagina_principale&action=historysubmit&diff=16568&oldid=16564] ) --[[User:Bazzy|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. [[User:P12|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). -- [[ru:User:Radix|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
--[[User:Nate|Nate]] 16:21, 10 January 2013 (PST)

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

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

== What is the playground page for? ==

I'm wondering what is the [[playground|playground page]] for? I've discussed it more in detail at [[Talk:Main_Page#What_is_the_playground_page_for.3F|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. --[[User:P12|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 [http://ar.cppreference.com/w/%D9%86%D9%82%D8%A7%D8%B4:Main_Page conversation over there].

[[User:A3f.at|A3f.at]] ([[User talk:A3f.at|talk]]) 14:44, 11 January 2015 (PST)

: I'll look into it, thanks --[[User:P12|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. [[User:Hiroo|Hiroo]] ([[User talk: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. --[[User:P12|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.
[[User:DJm00n|DJm00n]] ([[User talk: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 :) --[[User:P12|P12]] 13:16, 16 September 2015 (PDT)

I have the same request as [[User:DJm00n|DJm00n]] but for the Spanish wiki, there are some elements like the code or the navbar that is outdated.
[[User:Shadowsvanish|Shadowsvanish]] ([[User talk:Shadowsvanish|talk]]) 19:54, 17 January 2019 (PDT)

: Done. If you still see differences of appearance, it could be either that the old CSS is still cached somewhere, or that the templates used in the Spanish version also need synchronized with the English wiki. --[[User:P12|P12]] 15:07, 19 January 2019 (PST)

Please update Korean wiki also. (https://ko.cppreference.com) -- [[User:Yunbj|Yunbj]] 20:52, 10 Jan 2022 (PST)

== Ping ==

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

==Front Page==
In the [[Main_Page|front page]], the escape sequence in the C section is linked to the [[cpp/language/escape|C++ counter part]]. 
[[User:Fefe|Fefe]] ([[User talk: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. --[[User:Nate|Nate]] ([[User talk:Nate|talk]]) 07:35, 2 January 2016 (PST)

:: I agree. Sorry for long delay, I often use this website without logging in nowadays. --[[User:P12|P12]] 01:55, 1 February 2017 (PST)

=== Autolinker vs. multiple-level namespaces ===
Hi, could you stop by the [[http://en.cppreference.com/w/Talk:cpp/experimental/ranges Talk page for experiemntal/ranges]] for some ideas about dealing with super-verbose ddcls due to full qualifications? --[[User:Cubbi|Cubbi]] ([[User talk:Cubbi|talk]]) 06:13, 6 January 2017 (PST)

: Sure. Sorry for long delay, I often use this website without logging in nowadays. Perhaps I need to set up email notifications. --[[User:P12|P12]] 01:55, 1 February 2017 (PST)