[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-panel-devel
Subject: FYI: New calendar project (uses C++14 and C++17).
From: Mark Gaiser <markg85 () gmail ! com>
Date: 2016-12-28 20:14:38
Message-ID: CAPd6JnH2fr-2NSpa0aNZcWn9Ed5CUriXsetRik4DGDtGhMjSUQ () mail ! gmail ! com
[Download RAW message or body]
Hi,
I saw some commits from Kai to enhance the calendar code (both C++ and
QML), apparently for performance reasons. It's great to see people
interested in performance optimizations ;)
Some weeks ago i was watching cppcon videos. One video [1] got me
interested in playing with constructing a calendar in code and trying to
use as little code as possible. Just as an exercise to play with C++14 and
C++17 features. I was considering the ranges library, but that seemed
overkill to me so i kept myself to C++ 14, 17 and some custom iterators
from cppitertools [2].
Now i have a small* application [3] that calculates which days are in a
given month along with an offset at the beginning of the month (empty
cells). There are no empty cells to fill to 42 days (a common number of
days to display in a calendar).
The code itself (as it is now) is useless for you folks. It just prints a
whole year in months on the console and that's about it. But it is highly
performant! You can make it very useful by building a new
(QAbstractItemModel derived) model around it. That would basically be a
replacement for DaysModel and a cleanup for the Calendar class (updateData
specifically).
Looking back at the DaysModel that is still being used in the current
calendar. hehe, ohh boy.. I would certainly handle things differently if i
were to make it again. For instance, the concept of DaysModel seemed sound
when i made it, now it seems flawed. Why would anyone make a DaysModel with
"DayData" objects and in there have the day, month and year stored as ints.
Yeah... Go figure why i did that, i even don't know it anymore. If i were
to do that again i would make a "MonthModel" with a fixed rowcount of 42
and deduce every day in there by the column value in the QModelIndex. The
model itself only needs to know the month and year upon model construction
(and when changing months), it doesn't even need to remember
it. Calendar::updateData would be heavily simplified as well ;)
Have a look at [3] and feel free to use it however you like it.
You can make it work under C++14 if you replace the structured binding
usage.
Cheers,
Mark
[1] https://www.youtube.com/watch?v=mFUXNMfaciE
[2] https://github.com/ryanhaining/cppitertools
[3] https://github.com/markg85/cansole_calendar
* = small if you don't count the added files from cppitertools.
[Attachment #3 (text/html)]
<div dir="ltr">Hi,<div><br></div><div>I saw some commits from Kai to enhance the \
calendar code (both C++ and QML), apparently for performance reasons. It's great \
to see people interested in performance optimizations \
;)</div><div><br></div><div>Some weeks ago i was watching cppcon videos. One video \
[1] got me interested in playing with constructing a calendar in code and trying to \
use as little code as possible. Just as an exercise to play with C++14 and C++17 \
features. I was considering the ranges library, but that seemed overkill to me so i \
kept myself to C++ 14, 17 and some custom iterators from cppitertools \
[2].</div><div><br></div><div>Now i have a small* application [3] that calculates \
which days are in a given month along with an offset at the beginning of the month \
(empty cells). There are no empty cells to fill to 42 days (a common number of days \
to display in a calendar).</div><div><br></div><div>The code itself (as it is now) is \
useless for you folks. It just prints a whole year in months on the console and \
that's about it. But it is highly performant! You can make it very useful by \
building a new (QAbstractItemModel derived) model around it. That would basically be \
a replacement for DaysModel and a cleanup for the Calendar class (updateData \
specifically).</div><div><br></div><div>Looking back at the DaysModel that is still \
being used in the current calendar. hehe, ohh boy.. I would certainly handle things \
differently if i were to make it again. For instance, the concept of DaysModel seemed \
sound when i made it, now it seems flawed. Why would anyone make a DaysModel with \
"DayData" objects and in there have the day, month and year stored as ints. \
Yeah... Go figure why i did that, i even don't know it anymore. If i were to do \
that again i would make a "MonthModel" with a fixed rowcount of 42 and \
deduce every day in there by the column value in the QModelIndex. The model itself \
only needs to know the month and year upon model construction (and when changing \
months), it doesn't even need to remember it. Calendar::updateData would be \
heavily simplified as well ;)</div><div><br></div><div>Have a look at [3] and feel \
free to use it however you like it.</div><div>You can make it work under C++14 if you \
replace the structured binding \
usage.</div><div><br></div><div>Cheers,</div><div>Mark</div><div><br></div><div>[1] \
<a href="https://www.youtube.com/watch?v=mFUXNMfaciE">https://www.youtube.com/watch?v=mFUXNMfaciE</a></div><div>[2] \
<a href="https://github.com/ryanhaining/cppitertools">https://github.com/ryanhaining/cppitertools</a></div><div>[3] \
<a href="https://github.com/markg85/cansole_calendar">https://github.com/markg85/cansole_calendar</a></div><div>* \
= small if you don't count the added files from cppitertools.</div></div>
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic