Re: [boost] [gsoc 2013] draft proposal for chrono::date

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
>>> reference.
>> 
>> 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
>> possible:
>> 
>>    std::cout << date(4, 5, 2013, dmy);
>> 
>> where output comes out to be "2013-05-04". This seems a little clumsy to
>> me.
> 
> 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
>> notation
>> (year, day_of_year) as well as week date notation (year, week_no,
>> weekday).
>> 
>> 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
>> make
>> 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
Anurag.

--
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.