Proposal for custom time string formatting in std.datetime

Martin Nowak dawg at dawgfoto.de
Thu Dec 22 07:52:59 PST 2011


On Thu, 22 Dec 2011 12:03:13 +0100, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Thursday, December 22, 2011 02:12:31 Walter Bright wrote:
>> Timezone information is not necessary to measure elapsed time or  
>> relative
>> time, for example.
>
> The type requires it though. No, comparison doesn't require the time  
> zone, but
> many (most?) of the other operations do. And the type can't be separated  
> from
> the time zone. That's part of the whole point of how SysTime is  
> designed. It
> holds its time internally in UTC and then uses the time zone to adjust  
> the
> time whenever a property or other function is used which requires the  
> time in
> that time zone. That way, you avoid all of the issues and bugs that  
> result
> from converting the time. The cost of that is that you can't not have a  
> time
> zone and use SysTime. So, if someone cares about saving that little bit  
> of
> extra size in their executable by not using the time zone, they're going  
> to
> have to use the C functions or design their own time code.
>
>> Can it be added with PIMPL? PIMPL is good for more than just information
>> hiding, it can also be a fine way to avoid pulling in things unless they
>> are actually dynamically used (as opposed to pulling them in if they are
>> statically referenced).
>
> I don't follow you. You mean use PIMPL for the time zone? I haven't a  
> clue how
> you're going to do PIMPL without .di files, and Phobos doesn't use .di  
> files
> (and arguably _can't_, because it would destroy inlining and CTFE). Not  
> to
> mention, PIMPL would make SysTime less efficient, because in order to  
> avoid
> needing to know what the functions are on a TimeZone, you'd have to hide  
> the
> bodies of a number of SysTime's functions, which would disallow inlining  
> and
> CTFE (not that CTFE is terribly likely to be used with SysTime, but  
> inlining
> could be very important). You'd be losing efficiency of execution just  
> to save a
> few KB in the executable.
>
> Rearranging stuff to save some size in the executable without costing  
> efficiency
> is one thing, but if it's going to cost efficiency, then I'm generally  
> going to
> be against it.
>
I recently pimpled the core.thread module.
https://github.com/dawgfoto/druntime/commit/4626c20b66a647a497b9086b104e10ea89cfef02
The compiler is not really your friend here, e.g. it requires to compile  
the
implementation separately. But if your type is already used by reference  
then
this is a good option to reduce coupling and improve ABI stability.
Are you sure that inlining is a performance issue?

>> Please check and see if additional symbols are pulled in or not. I've  
>> seen a
>> lot of template code where the author of that code never checked and was
>> surprised at the instantiations that were happening that he overlooked.
>
> Nothing would pull in toCustomString or fromCustomString in unless the  
> user
> decided to call them, because they're templated and no other functions in
> Phobos are going to use them at this point (if ever). What exactly will  
> be
> pulled in when they _are_ called, I don't know, because they're not  
> completed
> yet. It probably wouldn't be much though, since toCustomString is  
> basically a
> fancy toString. But there's a good chance that it's stuff that's already  
> being
> pulled in for the standard string functions (e.g. toISOExtString).
>
> - Jonathan M Davis


More information about the Digitalmars-d mailing list