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-... Sent from the Boost - Dev mailing list archive at Nabble.com.