Difference between revisions of "User talk:T. Canens"

Revision as of 16:29, 20 January 2018

Thanks

Thanks for fixing bugs such as this one in uniform_real_distribution -- I actually remembered the discussion of that issue on SO as soon as I saw that edit. --Cubbi (talk) 07:44, 25 May 2015 (PDT)

Also awesome job with the library fundamentals TSs! The parallelism TS could make use of these layout ideas. --Cubbi (talk) 19:10, 24 July 2015 (PDT)

Thanks :) The parallelism TS looks like it's going to be messy. On a quick readthrough, I don't think they actually specified which header the parallel overloads for the 69 existing algorithms are placed in :( T. Canens (talk) 01:08, 25 July 2015 (PDT)

And I just realized that both the fundamentals TS and the concurrency TS specified a std::experimental::promise and a std::experimental::packaged_task, but one in the inline namespace fundamentals_v(1|2) and one in the inline namespace concurrency_v1. This is going to be rather tricky to present... T. Canens (talk) 01:19, 25 July 2015 (PDT)

Value categories

You gave a description for the lvalue cases of conditional expressions on Cubbi's talk page about the Value categories page. I think that it would be great if you could also add at the same location the descriptions for the xvalue and prvalue cases. Because even on the dedicated Conditional expression page it's not clear at all, nor in the standard.

By the way, the standard states, § 5.16. "Conditional operator", alinea 4, 5:

"If the second and third operands are glvalues of the same value category and have the same type, the result is of that type and value category and it is a bit-field if the second or the third operand is a bit-field, or if both are bit-fields. Otherwise, the result is a prvalue."

So why isn't it that simple? I mean reading this quote from the standard, one should infer simply, for E1 ? E2 : E3:

• If E2 and E3 are lvalues of the same type, then the result is an lvalue;
• If E2 and E3 are xvalues of the same type, then the result is an xvalue;
• Otherwise, the result is a prvalue.

Is the standard wrong here?

— Maggyero (talk) 15:40, 23 September 2015 (PDT).

p4 is talking about the operands after any conversions that are performed by p3. T. Canens (talk) 20:09, 23 September 2015 (PDT)

cwg1550/cwg1560

regarding marking cwg1550 and cwg1560 as "amends C++98", I think it would be inconsistent doing it just because clang did. The way I understood the replies when I asked on std-discission, CWG guidance was that their DRs amend the previous standard and LWG guidance was that their DRs don't. Note someone trying to introduce an editorial that marks CWG1560 as a breaking change in C++14 (which is why I made this edit) --Cubbi (talk) 14:11, 8 January 2016 (PST)

IMO clearly not all DRs are just for the immediately previous standard (Ville Voutilainen's first email in the std-discussion thread says "Sometimes it applies to earlier ones as well, in which case the designation is sometimes not quite clear."). Take CWG2000, for example - the <int> in vector<int> clearly should not be a header-name even in C++98. Similarly, P0136R0 (adopted as P0136R1) says that CWG wants to treat the changes as a DR against C++11, not C++14. And then N3922 says that "Direction from EWG is that we consider this a defect in C++14", but both GCC and Clang trunk apply it with -std=c++11 too.

I don't know if CWG keeps some sort of internal record on how far back each DR is supposed to reach, but without access to such a thing I think the best we can do is examining implementations that have implemented the DR at issue and see what each does. If there's an implementation that implements 1550/1560's resolution in C++11 mode but not C++98 mode, I'd support changing it back. T. Canens (talk) 15:58, 8 January 2016 (PST)

I'm pretty sure CWG doesn't have that kind of record (at least it never came up on the reflector or the wiki recently). Come to think of it, if we're going to be practical and say that compilers can apply DRs whenever they please (which would in fact reflect the truth), then the "applies to" column in my defect report table should simply be dropped. The table itself is necessary though, it is there to prevent people from taking a pre-DR standard draft and editing cppreference. --Cubbi (talk) 18:59, 8 January 2016 (PST)

Yeah, the table definitely should stay. I'm not sure about dropping "applies to" as some DRs are apparently not fully retroactive (e.g., GCC and Clang both treat 1-1 is a null pointer constant in C++03 mode, even though they both implement CWG903 in C++11 mode and later), so I think it does have some uses. T. Canens (talk) 12:47, 9 January 2016 (PST)

parallel ts merge

Shouldn't we also be dropping parallel TS links from See Also paragraph in every algorithm? --Cubbi (talk) 11:00, 21 March 2016 (PDT)

OK, but don't we have an extension installed that will make it much easier? T. Canens (talk) 11:13, 21 March 2016 (PDT)

Good point, it could actually work here. I forgot about it. --Cubbi (talk) 11:16, 21 March 2016 (PDT)

One Example Per Page?

Hi Canens, You removed the example I added in iterator_traits for two reasons:

1. one example per page
2. has little to do with iterator_traits

For (1): Here is a page with two examples: http://en.cppreference.com/w/cpp/iterator/iterator_tags

For (2): I believe showing how one can add iterator_traits to his iterator is important. (I moved one version of the example to std::iterator which is a reasonable place for it, but I still think having a relevant example in iterator_traits has its own value.

Cheers, Amirk (talk) 06:01, 29 June 2016 (PDT)

fixed cpp/iterator/iterator_tags, thanks. --Cubbi (talk) 06:09, 29 June 2016 (PDT)

Text replace

Hi, you've used text replace such as "Text replace - "dsc inc | cpp/experimental/parallelism/dsc algorithm" to "subst:User:T. Canens/null". Wasn't it possible just to use empty replacement target? I'm asking just because I'm interested, not that I think something is wrong :-). Regards. --P12 02:50, 1 February 2017 (PST)

The full text I wanted to get rid of is {{dsc inc | cpp/experimental/parallelism/dsc algorithm | <name of algorithm>}}, i.e., there's a variable component. I tried using a regex but that didn't work for some reason, so a substituted empty template was the simplest. T. Canens (talk) 03:26, 1 February 2017 (PST)

page deletion request

These broken redirect pages should be deleted:

• old/wiki/preprocessor/warning → (deleted)cpp/preprocessor/warning
• User talk:The Phantom → (deleted)User talk:VoidPhantom
• Template:cpp/utility/optional → (deleted)Template:cpp/experimental/optional
• Template:cpp/utility/bad optional access/dcl list constructor → (deleted)Template:cpp/utility/bad optional access/dsc constructor

These dead-end pages should be deleted:

• c/align/alignof
• cpp/container//value compare

By the way, these page should move to dragon/ instead of cpp/dragon/ because they are not a part of cpp:

• cpp/dragon/call dragon
• cpp/dragon/receive fire

page deletion request of zh version

Following wrongly created pages should be deleted:

Fruderica (talk) 22:14, 7 January 2018 (PST)

All done except for the dragons. T. Canens (talk) 14:19, 8 January 2018 (PST)

Thank you. And follow pages seems to be redundant or wrongly created:

• zh:Template:cpp/numeric/random/cauchy distribution/a
• zh:Template:cpp/numeric/random/cauchy distribution/b
• zh:cpp/preprocessor/pragma‏‎
• zh:cpp/keyword/casting comparison
• zh:cpp/thread/condition_variable_any/native_handle
• zh:old/wiki/string/character classes
• cpp/thread/condition_variable_any/native_handle (and versions in other languages)

Fruderica (talk) 00:10, 16 January 2018 (PST)

• All done. T. Canens (talk) 13:28, 19 January 2018 (PST)

We need a little support at Polish translation

I gathered a small team, and together we are going to translate cppreference into polish (hopefully, all of it). We stumbled across some problems, that we can't solve with default user permissions. We would like to for example update main CSS file http://pl.cppreference.com/w/MediaWiki:Common.css, upload a file for lc linking or update the footer (remove some unnecessary links). Is there a way to get some special permissions for polish part of this wiki, like "confirmed user" or "a little moderator" to get these things done? Or could you do it by yourself? We will appreciate any kind of help :) If you need it, I will post full description of what we wanna do on my "discussion" page
Kaznov (talk) 13:17, 19 January 2018 (PST)

If you assemble a list of changes you want me to make, I'll be happy to make it (within reason, of course). T. Canens (talk) 13:19, 19 January 2018 (PST)

I just did, placed it on my discussion page. Thanks in advance! Kaznov (talk) 14:04, 19 January 2018 (PST)

All done. I copied the GeSHi index as well. T. Canens (talk) 14:10, 19 January 2018 (PST)

Thank you very much once again! Kaznov (talk) 14:15, 19 January 2018 (PST)

Could you remove "Portal społeczności" and "Bieżące wydarzenia" links from our footbar? They don't link anywhere, and also these sites can't be created (non-ascii names). Also, please replace the "Pomoc" link with "FAQ" link (the same as on the en version), we will fill it later Kaznov (talk) 14:28, 20 January 2018 (PST)
Also, could you change the link of "edit help" (the one that is on every edit page)? It now links to non-ascii site (that we can't create), please make it link to "Pomoc:Edycja strony". Kaznov (talk) 16:29, 20 January 2018 (PST)

Fixing {{lc}} of zh site

zh:Template:lc does not work now for lack of zh:MediaWiki:Autolinker-definition-c and zh:MediaWiki:Autolinker-definition-cpp.

Could you copy en-versions to the zh-versions?

Fruderica (talk) 09:05, 20 January 2018 (PST)

✔ Done. T. Canens (talk) 10:29, 20 January 2018 (PST)