On Thu, 22 Dec 2011 12:03:13 +0100, Jonathan M Davis <jmdavisp...@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
