Namespaces
Variants
Actions

User talk:Cubbi

From cppreference.com

Contents

examples

Hi! Welcome to the wiki. Your contributions look awesome:) Just one note: could we have only one example per page? It can quickly become a mess, especially if these examples demonstrate more or less the same feature used in the similar way.P12 14:29, 17 August 2011 (PDT)

No problem, I felt that the return value of std::for_each deserved a special mention since so few people even know it exists, but it's true that for the most part that example was a duplicate. I don't mind it gone or anything -- I just put it together on the spot. Also, nice to know I can use range for loops here! --Cubbi 14:41, 17 August 2011 (PDT)
Well, any feature in C++11 can be used, provided that the examples become simpler. After all, it's not the for loop that is being demonstrated, but the particular function, so there should be as little auxiliary code as possible.P12 14:53, 17 August 2011 (PDT)
Incidentally, why do so many examples here use std::endl where '\n' is implied? It makes it look unprofessional, as if the next line is going to be system("pause") --Cubbi 19:43, 17 August 2011 (PDT)
Did you mean that there's no reason to use std::endl as '\n' is a shorter alternative, or that there's no reason to output newline at the end of the program? The former choice actually has no strong rationale behind, just I felt that std::cout is better for the examples. As for the second, most examples would be run only in interactive mode and most probably not edited in any way, so the newline helps produce clear output. Compare:
p12@p12-laptop:~$ ./a.out 
abcdp12@p12-laptop:~$

And

p12@p12-laptop:~$ ./a.out 
abcd
p12@p12-laptop:~$

P12 01:25, 18 August 2011 (PDT)

I mean that << std::endl is premature pessimization: it is, by definition, equivalent to << '\n' << std::flush and flush is only needed before system("pause") and in some other multiprocessing/multithreading situations or when debugging a program that segfaults (in which case always-flushed cerr works better anyway). Stroustrup's "hello world" uses \n in "The C++ Programming Language". Also, recent discussion on SO and a not so recent one --Cubbi 06:53, 18 August 2011 (PDT)
Well, I wasn't aware of that. Let's dump std::endl then. I'll instruct my bot account to search/replace every occurrence of std::endl with '\n', except where std::endl is indeed intended.P12 07:43, 18 August 2011 (PDT)

Lambda / Example

Hi! Good point on the std::function usage being already promised. // http://en.cppreference.com/w/cpp/language/lambda

Nitpick: isn't it better to say "stored" instead of "captured" in "captured in std::function"?

Clarification: shouldn't we at least say that there's a difference between these two cases? Note that std::function in this case can introduce severe inefficiencies (regardless on whether it is common or not, this makes it a bad practice, IMHO).

Compare the results of the following benchmark: http://www.gockelhut.com/c++/articles/lambda_vs_bind

Further references: http://stackoverflow.com/questions/11774277/lambdas-and-stdfunction http://stackoverflow.com/questions/8298780/lambda-to-stdfunction-conversion-performance http://www.drdobbs.com/cpp/efficient-use-of-lambda-expressions-and/232500059?pgno=2 http://stackoverflow.com/questions/3218821/c0x-lambda-overhead#comment3320220_3218821

// Edit: if we do decide that keeping it is a good idea (I'm not convinced), I think <functional> header needs to go back in, too.

// Request for clarification: just to make sure I'm not breaking any rules, is it better to discuss issues like this here or at the page-specific discussion section? // which would be http://en.cppreference.com/w/Talk:cpp/language/lambda

Note I'm not trying to be pedantic, my thinking is simply that we should strive to provide "the best practices" code in the examples whenever possible (unlike that certain other C++ reference...) and it seems to be possible in this case.

Md 13:14, 1 May 2013 (PDT)

You're right about the header of course (I tested with gcc and just pasted it as-is), and yes, discussion of language/lambda is better on the language/lambda's talk page -- that's where visitors would look for comments and opinions such as these. std::function of course has the potential for overhead, but I think the best place to expand on that is std::function's main page, in a ===Notes=== section, where implementation details and caveats would be appropriate (e.g. compare to std::shared_ptr's Notes). Wrapping a lambda in a function is not justified in the example, but it is justified in enough real-life use cases (to pass to a non-template function, to apply std::not1, etc) --Cubbi 14:13, 1 May 2013 (PDT)

"must return"?

Regarding the comment on this and other diffs. int main() does not require a return statement, Not in C (since 1999), not in C++ (ever). Stroustrup's "hello world", again, has no return statement. But if its a good idea to have all code here include that statement, Help:Manual of style needs to be updated. --Cubbi 14:20, 23 August 2011 (PDT)

Oh great. I must have wasted a lot of return statements. If they are not mandatory, we can omit them. BTW, could you start discussions like this in my talk, so that I get a notification?P12 02:09, 24 August 2011 (PDT)
Okay. BTW, the reference for it: 3.6.1[basic.start.main]/5 (same in C++03 and C++11) "If control reaches the end of main without encountering a return statement, the effect is that of executing return 0;" --Cubbi 03:17, 24 August 2011 (PDT)

using std::less in std::lower_bound

Is this edit correct? What if the argument types to std::less are not convertible to each other, yet have a comparison operator defined? Is there's a solution to that problem?P12 14:43, 24 August 2011 (PDT)

You're right, that less is missing the second type. In LLVM's libc++ library, the first form of std::lower_bound is defined exactly this way:

template <class _ForwardIterator, class _Tp>
inline _LIBCPP_INLINE_VISIBILITY
_ForwardIterator
lower_bound(_ForwardIterator __first, _ForwardIterator __last, const _Tp& __value)
{
    return _VSTD::lower_bound(__first, __last, __value,
                             __less<typename iterator_traits<_ForwardIterator>::value_type, _Tp>());
}
I'll edit accordingly. --Cubbi 15:15, 24 August 2011 (PDT)

Oh, wait, standard less only takes one argument.. --Cubbi 15:18, 24 August 2011 (PDT)
So it looks like we'll have to duplicate this one, or come up with a two-argument functor or lambda just for the sake of that one example equivalent function. --Cubbi 15:24, 24 August 2011 (PDT)
So let's keep the duplicate then. Unrelatedly, I think there's no need to have exact permutation, sort and other long algorithms outlined in the equivalent function section. They're too complex for anyone to grasp quickly, so it might be a better idea just to leave a 'black box' instead.P12 15:38, 24 August 2011 (PDT)
Even std::random_shuffle can be hard to grasp if you're unfamiliar with Fisher-Yates-Knuth algorithm. I think implementations of the permutations are rather simple for what they do, and to me it was educational to learn how the three permutation functions are implemented (identically in both libraries I looked at, too). I agree about sorts, stable_partition, and anything that does something different "if additional memory is available" - those are complex and they are implemented differently in different libraries. If I were to cut one, I'd cut std::minmax_element, it's too complex for what it does. But there's so much work to be done on this wiki still, it feels like a minor thing anyway. --Cubbi 18:57, 24 August 2011 (PDT)
Ok, after coming across the page of std::is_permutation I reversed my opinion. The algorithm is quite clear if there are some comments about how the code works. Maybe all we need is a very short explanation above the code for the most complex functions? Anyway, equivalent functions, like examples, reside at the very end of the page, so they aren't really important. Since probably the only people, who will come across those sections, are the ones who're looking for additional reference, lots carefully selected information will be certainly beneficial.P12 13:03, 25 August 2011 (PDT)

wide character strings

Wide character strings are not the same as multibyte character strings. There are actually three character string types:

  • character / byte / narrow-character null-terminater string, e.g. ASCII-8
  • multibyte null-terminated string, e.g. UTF-8
  • wide / wide-character null-terminated string, e.g. UCS, UTF-16, etc.

Multibyte character string is like an 'extension' to regular byte character strings, since a multibyte character string is always a valid byte character string, so it is can be processed by all functions at cpp/string/byte, but not the functions at cpp/string/wide.

Anyways, this is a quite complex subject, it needs to be explained better in the article lead sections.P12 15:49, 2 September 2011 (PDT)

You're right, the definition of NTMBS is not suitable for string/wide at all. An NTMBS is more like what a std::wstring_convert().to_bytes() would produce from a wchar_t[]/wstring. But yes, it would be nice to detail the differences between C++'s four character types and the data that can be stored in them. --Cubbi 16:44, 3 September 2011 (PDT)

Template:ddcl list namespace

Hi. My edits adding {{ddcl list namespace}} were a mistake, since the namespace can easily be deduced from the page title as is done e.g. std::this_thread::sleep_for. I'll revert them. Sorry for inconveniences.P12 13:34, 4 October 2011 (PDT)

Ah, okay, sorry about running along with it. --Cubbi 13:36, 4 October 2011 (PDT)

{{param none}}, {{return none}}, {{throw none}}

Hi. I decided that {{param none}}, {{return none}}, {{throw none}} serve no purpose as the current style is adequate and probably won't change in the future. I'll replace these templates with the text they resulted in - (none). I hope this will make editing easier. P12 13:03, 11 October 2011 (PDT)

Re. mem=

Hi. I've fixed the inconvenience caused by the necessity to use mem parameter in the dcl list mem * templates. Now if a dcl list mem * template is placed in a page which is not a sibling or parent of the target page the template links to, member of std:: is added automatically. E.g.

Template:cpp/memory/shared ptr/dcl list get

So the mem= parameter is not needed anymore. P12 13:23, 19 January 2012 (PST)

Cool, thanks. I wish i could understand that code you just changed! --Cubbi 13:27, 19 January 2012 (PST)
The idea is not very complicated, the syntax is. The dcl list * templates always get a path to function/class page they represent. When used, the template now checks whether the target page and the page they are used in have common ancestor. If yes, everything is as in the past. Otherwise, the template acquires and displays the name of the parent class of the target page. Here it knows that if we have a/b/parent/member_function, then there's always Template:a/b/parent/title and if the title template gets #MAGICTITLESTRING#, then it just yields in the part of the title which would be displayed in the smaller font. So for e.g. {{cpp/container/vector/title|#MAGICTITLESTRING#}} we get std::vector which is what we want. P12 16:50, 19 January 2012 (PST)

sorry for being such a pain

I'll try to avoid making radical changes without searching first. I need to actually look more into the standard before modifying things. >.< --- Undeterminant 12:29, 11 February 2012 (PST)

adding a function or two is nothing radical. It's a wiki. If someone thinks it can be improved, they will. --Cubbi 12:32, 11 February 2012 (PST)

operator++ with or without (int) overload in links

Hey, thanks for all the work on the iterators. I only wondered why you put the (int) overloads into the links for the ++ operators, for example

advances the iterator
(public member function of std::reverse_iterator)

Usually the overloads are not specified in the links (e.g. constructors, operator[]).

Would you be ok, if I started changing this to the shorter version below?

advances the iterator
(public member function of std::reverse_iterator)

Or are there some caveats that I missed?

Tobi 03:23, 3 April 2012 (PDT)

They are not overloads, they are post-increments. Post-increment and pre-increment are fairly different (but not different enough to have separate pages).. On second thought, I suppose it does clutter the link unnecessarily. Ultimately, style decisions are up to P12, I'm just an editor. --Cubbi 05:43, 3 April 2012 (PDT)

Russian translation

Hi. Could you take a look at the Russian wiki and translate the most frequently used templates if you have time? Most of the templates are only few words or sentences, so the translation would need at most several tens of minutes. I then would import the rest of the English content and add some advertising at the Dokuwiki version too gather attention of other editors. Thanks! -- P12 09:37, 25 April 2012 (PDT)

I started, but can't promise to be fast. --Cubbi 10:40, 26 April 2012 (PDT)
Nevermind, I think Krtkr won't return anytime soon. I'll just import the current content of Dokuwiki. -- P12 10:20, 30 April 2012 (PDT)

Svg conversion of the File:Streambuf.png

Hi. I've created an explanatory image for std::basic_streambuf based on your initial draft. Your image was really helpful, thanks! P12 18:02, 16 May 2013 (PDT)

Alas, poor dynarray

...we hardly knew ye. I wonder if it makes sense to leave the std::dynarray and std::optional content in place (with the hope that at some point they'll return) and just attempt to remove other links to/uses of them? --Nate (talk) 17:06, 30 September 2013 (PDT)

I vote for leaving the content in place. There are lots of links to these pages over the internet already and people who come through them won't like 404s being served. We could even replace the (since C++14) tags with something like (removed from the standard draft). --P12 18:28, 30 September 2013 (PDT)
It's getting moved to a separate TS (along with some other things that got dropped from the WP), so it's still going to exist and worked on, just not getting released in C++14.. Until there's a new draft to reference, I'd keep it, maybe with a note that it was voted out as far as we know. (here's relevant StackOverflow chat session where I picked that up - scroll up for more notes about Chicago) --Cubbi (talk) 18:29, 30 September 2013 (PDT)
Another prooflink (from gcc library maintainer, regarding dynarray and VLA): http://stackoverflow.com/questions/19111028/c14-stddynarray-vs-stdvector#comment28265724_19111606 --Cubbi (talk) 07:17, 1 October 2013 (PDT)
Any information on why optional got mothballed too? As opposed to dynarray, it doesn't look like a risky addition without implementation experience. --P12 09:03, 1 October 2013 (PDT)
Two National Bodies comments were asking for (more) relational operators for it, and there was a pre-Chicago paper about all the different approaches to that, sounds like no consensus. SO chat suggests that, too --Cubbi (talk) 09:28, 1 October 2013 (PDT)

C++14 status

Just out of curiosity, do you have any estimates how much C++14 stuff we're still missing? --P12 13:57, 10 November 2013 (PST)

I just went up the Chicago issues in libc++'s checklist today and added whatever I found missing in the library, I didn't double-check every earlier issue, but I think the library is actually complete at this point (although a few simple redlinks remain, e.g. the literals for complex numbers and some durations). Core language is certainly missing some C++14 improvements (polymorphic lambdas and return type deduction in functions, for example), but it's work in progress anyway --Cubbi (talk) 17:02, 10 November 2013 (PST)
Thanks. I guess it's time to update the news template. --P12 03:07, 11 November 2013 (PST)

Mistakenly reverted edit

Sorry for this, it was an accident :) --P12 16:52, 20 February 2014 (PST)

Must we enclose some big chapters with {{rev}} template (such as in [1])?

I realized that it is for gadget StandardRevisions and it does look nice in C++03, C++11 and C++14 mode. But if someone view the page in the default mode, I'm afraid it would be a little difficult for him to find the (since C++14) sign and it would be confusing. --D41D8CD98F (talk) 20:05, 6 June 2014 (PDT)

actually that part could use both the (C++14) right on the heading and the rev box for the gadget. Perhaps you can bring it as a case study to Talk::Main_Page to revive the old revbox discussion/brainstorming. Good work by the way. --Cubbi (talk) 21:00, 6 June 2014 (PDT)
Thank you. The link is really informative. I've added a section in Talk:Main Page to discuss this issue.--D41D8CD98F (talk) 00:30, 7 June 2014 (PDT)

Contributions to the standard revisions gadget

Hi,

I'd like to commit this change to the cppreference-doc Github repo. What name and email should I use to attribute your contributions? Cheers. --P12 15:16, 18 November 2014 (PST)

It's about time I started using this github thing myself. --Cubbi (talk) 19:39, 18 November 2014 (PST)