Subject: Re: [boost] [gsoc 2013] draft proposal for chrono::date
From: Anurag Kalia (anurag.kalia_at_[hidden])
Date: 2013-05-03 18:52:35
>> But might there not be cases where we have to store the output not to
>> some output device, but to a string in memory only?
> I don't imagine there would be much call for doing formatted output of
> many strings to a buffer. Even then, each date of interest must be cast
> into the I/O friendly form, so there's no room for optimizing that case,
> is there?
The fact is I really don't know much about I/O formatter functions to
already pick a direction. So i can just say I will come back here when I
have more knowledge of what you want to say. :-)
>>>> For the vast majority however,
>>>> serial representation is good enough. After caching as you know,
>>>> performance nears ymd in these scenarios too.
>>> Caching suggests larger objects and, possibly lower locality of
>> By caching, I meant to say retrieve y,m,d values explicitly as well as
>> some other properties of the date.
> That sounds like conversion to another date type.
Maybe logically, yes.
>> It is because date object is streamable. Thus, such construction is
>> std::cout << date(4, 5, 2013, dmy);
>> where output comes out to be "2013-05-04". This seems a little clumsy to
> If there is I/O support, I'd hope for other formats. Regardless, those in
> different regions will want the arguments ordered in their locale's order.
> You could require them in magnitude order -- YMD -- but that's less
> friendly and isn't checked by the compiler.
I was acquainted with locales a couple of days back only. So, forgive me if
I neglect to take them into account. You are absolutely right.
>> Now, back to your named constructor idiom. Thanks! How true that you
>> learn something new everyday! I liked it. It actually seems very suitable
>> to my date class since we are constructing dates also in ordinal date
>> (year, day_of_year) as well as week date notation (year, week_no,
>> Again, I have doubts still. First that I have never encountered it in
>> standard library till now - the library that I use the most. If it exists
>> somewhere in it or Boost, that would hearten me.
> make_pair, make_shared are something like it. However, the reason you've
> not seen it used is that no standardized type has needed it.
Thanks for the examples. They were just what I needed.
>> Moreover, named constructor
>> idiom allows construction of objects by the objects themselves. It has
>> possibility to look ugly. Though, as I write, I think one could always
>> them first-class functions which are friends of date class.
> date::ymd(2013, 5, 3)
> make_ymd(2013, 5, 3)
> I don't think this is right, though:
> ymd(2013, 5, 3)
I will keep it in mind.
>> Is the latter ok approach? My concerns also extend to performance of
>> resulting code. But people on internet say that the call is almost always
>> optimized away.
> RVO should take care of things.
We can even make it explicit by giving a move constructor.
Thanks Rob for input
-- View this message in context: http://boost.2283326.n4.nabble.com/gsoc-2013-draft-proposal-for-chrono-date-tp4646142p4646584.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk