On Sunday, 2 August 2015 01:24:50 WET John Layt wrote:
> It would require a lot of shuffling code around, as a lot of code is
> in the d_ptr, it would horribly complicate things and there's the
> potential for interesting corner cases, like say adding enough years
> to a date to push it from one im
On Friday 31 July 2015 18:08:13 Thiago Macieira wrote:
> I also don't think you can have a full, static shared null because
> QDateTimePrivate is not POD, due to its QTimeZone member. So a real shared
> null would be a Q_GLOBAL_STATIC, if you chose to go that route.
You can always make a layout-
On Monday 03 August 2015 07:31:51 Robert Knight wrote:
> Follow-up question - if a data type is a union of a pointer and some
> other representation, can it be stored in a QVariant without
> transitioning to the allocated version?
Irrelevant. You're not storing that type. You're storing the QDateT
Follow-up question - if a data type is a union of a pointer and some
other representation, can it be stored in a QVariant without
transitioning to the allocated version?
On 3 August 2015 at 03:39, Thiago Macieira wrote:
> On Monday 03 August 2015 03:23:44 Mark Langezaal wrote:
>> On 2015-08-01 23
On Monday 03 August 2015 03:23:44 Mark Langezaal wrote:
> On 2015-08-01 23:51, Thiago Macieira wrote:
> > QDateTime API accepts the offset from UTC in seconds, but all existing
> > timezones are multiples of a quarter hour. With a range from -12 to
> > +13.5, we
> > need ceil(log((13.5 + 12) * 4)
On 2015-08-01 23:51, Thiago Macieira wrote:
> QDateTime API accepts the offset from UTC in seconds, but all existing
> timezones are multiples of a quarter hour. With a range from -12 to
> +13.5, we
> need ceil(log((13.5 + 12) * 4) / log(2)) = 7 bits for the timezone.
> With the
> one bit for t
On Sunday 02 August 2015 10:04:36 Thiago Macieira wrote:
> How often do people construct a QDateTime containing only a QDate as a
> stepping stone to a full QDateTime? Note that the QDateTime constructor
> containing a QDate sets a valid time; you can only get valid date and null
> time if you u
On Sunday 02 August 2015 01:24:50 John Layt wrote:
> [Reply to list this time...]
>
> This could work, as Qt::LocalTime / Qt::UTC / Qt::OffsetFromUtc don't
> actually create or use QTimeZone for anything (at least not yet,
> LocalTime may yet). I'm assuming dates outside the 1970-4207 year
That w
[Reply to list this time...]
This could work, as Qt::LocalTime / Qt::UTC / Qt::OffsetFromUtc don't
actually create or use QTimeZone for anything (at least not yet,
LocalTime may yet). I'm assuming dates outside the 1970-4207 year
range would still use the d_ptr implementation, as would anything
us
On Saturday 01 August 2015 23:22:45 Robert Knight wrote:
> > What I mean is that you'll incur a heap allocation when doing
> > ...
> > I don't think there is and there has never been any inline method in
> > QDateTime that dereferences the d pointer, so using a nullptr to indicate
> > shared null i
> What I mean is that you'll incur a heap allocation when doing
> ...
> I don't think there is and there has never been any inline method in QDateTime
> that dereferences the d pointer, so using a nullptr to indicate shared null is
> acceptable.
Hmm, perhaps QDT could avoid a heap allocation entir
On Friday 31 July 2015 17:20:02 Milian Wolff wrote:
> Most other classes in Qt are cheap to generate in an empty/invalid state,
> not so for QDateTime. Is there a reason for that, or is it just an
> oversight?
Oversight.
> If so, I'd like to amend that. Would it be preferred to
> introduce a sh
Hello all,
I just realized that QDateTime in Qt 5 is still not implementing the "shared
null optimization" - I'm not sure
it's the right term.
What I mean is that you'll incur a heap allocation when doing
QDateTime invalidDate;
See:
QDateTime::QDateTime()
: d(new QDateTimePrivate)
{
}
Mo
13 matches
Mail list logo
