qpid-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Alan Conway <acon...@redhat.com>
Subject Re: Constructing abstime from uint64_t
Date Wed, 07 Apr 2010 17:35:31 GMT
On 04/07/2010 10:23 AM, Andrew Stitcher wrote:
> On Wed, 2010-04-07 at 09:22 -0400, Alan Conway wrote:
>> On 04/06/2010 10:29 PM, Andrew Stitcher wrote:
>>> On Tue, 2010-04-06 at 15:33 -0400, Alan Conway wrote:
>>>> I need to (de)serialize AbsTime timestamps. I can convert an AbsTime to a
>>>> uint64_t with uint64_t(Duration(abstime)) but I don't see how to convert
back to
>>>> an AbsTime. I can just add a constructor but wanted to check with you if
>>>> missing the intent.
>>> The problem here is that fundamentally the class is designed not to show
>>> it's epoch value. The fact you can wheedle it out by going via a
>>> Duration is not intentional!
>>> [BTW Duration&   AbsTime encapsulate an int64_t so using uint64_t is
>>> incorrect. Both are allowed to be negative - Duration -ve indicates
>>> before the time you asked about, AbsTime -ve indicates before the Epoch]
>>> The external representation can't simply be the nanosec count in AbsTime
>>> as different platforms have different Epochs. This is certainly true
>>> between Windows and Unix.
>>> I guess there needs to be an explicit way to convert a specific
>>> date/time to an AbsTime so that you can use the existing differencing
>>> operations as you can get a Duration out of the difference between the
>>> AbsTime you're serialising and some fixed Epoch AbsTime. And equally you
>>> can construct an AbsTime out of an Epoch AbsTime and a Duration.
>>> Actually I suppose you could just declare a new static AbsTime as the
>>> Epoch and make sure it represents the same time across all platforms.
>>> Then use it for serialisation. That would avoid needing to do the
>>> general Date->AbsTime thing.
>>> This has rambled a bit, get back to me if it's not clear, I could add an
>>> Epoch AbsTime for you if it's not clear how to do it fairly easily.
>> Here's a patch to add an EPOCH constant to Time.h, Steve can you check that I've
>> got the windows part right?
> Minor Quibbles:
> To be consistent with the other constant(s) in the file "Epoch" would be
> better than the all capitalised version.
> Similarly for consistency, it might be better to use a member function
> Epoch() - like FarFuture() which is also a constant. I admit I can't
> remember why it's not a simple constant. but why not just be consistent
> with it?
Agreed, will do that.

> Incidentally, does c++ guarantee that global constant POD classes like
> AbsTime have their members 0 initialised? The Posix code relies on it,
> but I can't remember that little niche of behaviour at this moment
> (without my copy of the standard here). Probably wise to comment to that
> effect before the definition if so.

POD data isn't 0 initialized unless it has an = 0 initializer. And in the 
windows version I'm initializing with a function call so that's not guaranteed 
to happen before other stuff in static initializers. If I change this to a 
function then I can drop the global constant and we won't have to worry about it.

Apache Qpid - AMQP Messaging Implementation
Project:      http://qpid.apache.org
Use/Interact: mailto:dev-subscribe@qpid.apache.org

View raw message