Difference between revisions of "User talk:T. Canens"
(→We need a little support at Polish translation: re) |
|||
Line 133: | Line 133: | ||
:If you assemble a list of changes you want me to make, I'll be happy to make it (within reason, of course). [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 13:19, 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). [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 13:19, 19 January 2018 (PST) | ||
::I just did, placed it on my discussion page. Thanks in advance! [[User:Kaznov|Kaznov]] ([[User talk:Kaznov|talk]]) 14:04, 19 January 2018 (PST) | ::I just did, placed it on my discussion page. Thanks in advance! [[User:Kaznov|Kaznov]] ([[User talk:Kaznov|talk]]) 14:04, 19 January 2018 (PST) | ||
+ | :::All done. I copied the GeSHi index as well. [[User:T. Canens|T. Canens]] ([[User talk:T. Canens|talk]]) 14:10, 19 January 2018 (PST) |
Revision as of 14:10, 19 January 2018
Contents |
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 astd::experimental::packaged_task
, but one in the inline namespacefundamentals_v(1|2)
and one in the inline namespaceconcurrency_v1
. This is going to be rather tricky to present... T. Canens (talk) 01:19, 25 July 2015 (PDT)
- And I just realized that both the fundamentals TS and the concurrency TS specified a
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>
invector<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)
- 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
- 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)
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)
One Example Per Page?
Hi Canens, You removed the example I added in iterator_traits for two reasons:
- one example per page
- 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:
Already done
- zh:Template:cpp/io/basic synbuf/dsc swap
- zh:Template:cpp/io/basic synbuf/dsc set emit on sync
- zh:Template:cpp/io/basic synbuf/dsc get wrapped
- zh:Template:cpp/io/basic synbuf/dsc emit
- zh:Template:cpp/io/basic synbuf/dsc destructor
- zh:Template:cpp/io/basic_osyncstream/dsc_swap
- zh:cpp/compare/weak equal
- zh:cpp/compare/strong equal
- zh:cpp/compare/partial order
- zh:cpp/compare/weak order
- zh:cpp/compare/strong order
- zh:cpp/compare/named comparison functions
- zh:ciso646
- zh:c/type
- zh:cpp/chrono/time point/operato arith2
- zh:cpp/utility/any/operator
- zh:cpp/container/vector/operator as
- zh:cpp/data types
- zh:cpp/operator precedence
- zh:cpp/preprocessor/define
- zh:cpp/preprocessor/preprocessor if
- zh:cpp/preprocessor/preprocessor vars
- zh:cpp/preprocessor/sharp
- zh:cpp/preprocessor/undef
- zh:cpp/string/basic_string/character_classes
- zh:cpp/io/c/vscanf vfscanf vsscanf
- zh:cpp/io/c/vprintf vfprintf vsprintf
- zh:cpp/io/width
- zh:cpp/other
- zh:cpp/locale/c/setlocale
- zh:cpp/iterator/ostreambuf iterator/operator++
- zh:cpp/iterator/ostream iterator/operator++
- zh:lmt
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)
- Thank you. And follow pages seems to be redundant or wrongly created:
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)