Data retention policy

[michalwidera]

AS A [user],
I WANT TO [set retention policy on given TS],
SO THAT [I can control how much archive data I can get and how much data are stored]

[michalwidera]

@szreder - Wielkie dzięki!

• Przyszło mi do głowy jak na to spojrzałem i sam nie wiem jeszcze, czy by coś uprościło albo ukulturalniło.
  W faccposix.cc, wydaje mi się, że casty static_cast<off_t>(-1) są nadmiarowe, bo skoro result jest auto (czyli off_t), to przy porównaniu się int -1 odpowiednio sam "promuje" do większego typu jeśli to będzie potrzebne.
• Zastanawiam się, czy nie chciałbyś sobie zrobić dziedziczenia po std::streambuf gdzieś.
• Patrzę w faccbindev.cc, tam są syscalle na fd. Jeszcze zanim te syscalle: konstruktor binadyDeviceAccessor() jak przyjmie stringa przez kopię bez const (bo już przyjmuje kopię, ale const) to można go std::move() do środka. Użycie ::open() spoko, tylko dla pełnej paranoi można by sprawdzić co zwraca. W ::fileName() wygląda, jakby można było zwrócić stringa przez const-ref i całą metodę opatrzyć kwalifikatorem const. W linii 42. i dalej jest potencjalnie podejrzanie.
• A ten unique_ptr w linii 399, na którym natychmiast jest robiony .release()...? Wygląda jakby nic nie robiło, tzn. było analogiczne do walnięcia gołego new synsugar..., bo skoro i tak robimy release() na tym, to to jest noop.
  W sensie, te dwa fragmenty są semantycznie równoważne:

T *ptr = std::unique_ptr<T>(new T{}).release();
T *ptr = new T{};

No i wtedy pytanie czy tam coś nie cieknie. Jak read() zwróci -1, to read_size się przekręci na dużą liczbę.

• descriptor.cc:430 stringa name można przez std::move() popchnąć do konstruktora Description, aczkolwiek to pewnie będzie redundantne w świetle przejścia na string_view. To kombinowanie z podmienianiem locale wygląda trochę...dziwnie.
• BTW, te funkcje ltrim() i rtrim() w descriptor.cc też można wygodnie opędzić na std::string_view. To ostatnie ma metody remove_prefix(), remove_suffix(), a że działają na widoku, a nie fizycznym stringu, to są mega tanie.
  descriptor.cc:49, w funkcji GetFieldType(), słownik typeDictionary bym zmienił na static const, bo teraz wygląda, jakby się za każdym razem budował przy wywołaniu funkcji.
  Przy czym ten const spowoduje, że trzeba będzie operator[] zmienić na .at().
  I jeśli na wejściu może być typ "nieobsługiwany", to sprawdzić jego obecność w słowniku, żeby wyjątek nie poleciał na .at().
  Analogicznie w następnej funkcji GetFieldType().
  No dokładnie, nagle cała masa rzeczy po prostu zniknie.
  W konstruktorze Descriptor, ten co przyjmuje cztery parametry - wydaje mi się, że można w jego ciele zmienić
  push_back(rField(n, l, a, t));
  na
  emplace_back(n, l, a, t);
  I wtedy idąc dalej: jak przyjąć parametr std::string n przez kopię, to:
  emplace_back(std::move(n), l, a, t);
  Swoją drogą, dziedziczenie po kontenerach z STL jest generalnie odradzane, ale nie to, że nie wolno.
  Tylko trzeba uważać na destruktory.
  W liniach 133. i 134. - może też się da (odpowiednio) emplace_back() i .emplace() (albo .try_emplace())?
  W tej pierwszej funkcji idzie std::string przez kopię, no ale to rozumiem, że do celów trimowania. Jak by to był string_view, to wszystko się zrobi tanie.
• https://github.com/szreder/devUtil/blob/master/EnumUtils.hpp

EnumClass(Cake, unsigned, Cheese, Chocolate);

Cake c;
c = Cake::Cheese;
std::cout << static_cast<const char *>(c) << '\n';
c = *Cake::fromString("Chocolate");
std::cout << static_cast<const char *>(c) << '\n';

• Bym przemigrował większość stringów na std::string_view, żeby nie walić w stertę.

[michalwidera]

Nie dam rady tego wszystkiego ogarnąć w Data Retention - dlatego wydzielam #52 żeby nie zgubić a zamknąć #7