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