Commit Graph

11 Commits

Author SHA1 Message Date
Norman Feske
5e862b2cd3 base/include: use C++20 function template syntax
Issue #5227
2024-05-29 09:18:12 +02:00
Norman Feske
bbc21cf063 util/bit_array.h: remove use of memset and memcpy
This makes the code less dependent on functions considered unsafe.

Fixes #3748
2020-05-05 13:30:15 +02:00
Christian Helmuth
d452094f43 Only rewind next-free pointer in Bit_allocator
Formerly, _next was always updated to the last free'd allocation, which
left large gaps on alloc/free bursts. Now, we try keep allocation
density high from the start of the array and ensure that allocations
happen at the lowest available index in the bit array.

Fixes #3679
2020-03-26 11:38:53 +01:00
Martin Stein
ff7c378ff9 bit_allocator: alloc specific block of bits
Method to try to allocate specific bits of the Bit_allocator_dynamic.

Ref #2670
2018-03-29 15:16:11 +02:00
Norman Feske
eba9c15746 Follow practices suggested by "Effective C++"
The patch adjust the code of the base, base-<kernel>, and os repository.
To adapt existing components to fix violations of the best practices
suggested by "Effective C++" as reported by the -Weffc++ compiler
argument. The changes follow the patterns outlined below:

* A class with virtual functions can no longer publicly inherit base
  classed without a vtable. The inherited object may either be moved
  to a member variable, or inherited privately. The latter would be
  used for classes that inherit 'List::Element' or 'Avl_node'. In order
  to enable the 'List' and 'Avl_tree' to access the meta data, the
  'List' must become a friend.

* Instead of adding a virtual destructor to abstract base classes,
  we inherit the new 'Interface' class, which contains a virtual
  destructor. This way, single-line abstract base classes can stay
  as compact as they are now. The 'Interface' utility resides in
  base/include/util/interface.h.

* With the new warnings enabled, all member variables must be explicitly
  initialized. Basic types may be initialized with '='. All other types
  are initialized with braces '{ ... }' or as class initializers. If
  basic types and non-basic types appear in a row, it is nice to only
  use the brace syntax (also for basic types) and align the braces.

* If a class contains pointers as members, it must now also provide a
  copy constructor and assignment operator. In the most cases, one
  would make them private, effectively disallowing the objects to be
  copied. Unfortunately, this warning cannot be fixed be inheriting
  our existing 'Noncopyable' class (the compiler fails to detect that
  the inheriting class cannot be copied and still gives the error).
  For now, we have to manually add declarations for both the copy
  constructor and assignment operator as private class members. Those
  declarations should be prepended with a comment like this:

        /*
         * Noncopyable
         */
        Thread(Thread const &);
        Thread &operator = (Thread const &);

  In the future, we should revisit these places and try to replace
  the pointers with references. In the presence of at least one
  reference member, the compiler would no longer implicitly generate
  a copy constructor. So we could remove the manual declaration.

Issue #465
2018-01-17 12:14:35 +01:00
Stefan Kalkowski
3906568908 util: make bit array and allocator copyable
Ref #2091
2017-08-28 16:49:46 +02:00
Norman Feske
29b8d609c9 Adjust file headers to refer to the AGPLv3 2017-02-28 12:59:29 +01:00
Stefan Kalkowski
b856bfdfcd base: let bit allocator use fine-grained sizes
Ref #1588
2015-07-01 14:46:17 +02:00
Norman Feske
eaac3cc1bd Revised API documentation
This patch curates the API documentation to become suitable for the
functional specificaton, which is partially generated from the header
files.
2015-04-09 16:04:46 +02:00
Norman Feske
e8336acafc base,os: Coding-style unification
Fixes #1432
2015-03-13 12:17:23 +01:00
Norman Feske
ca971bbfd8 Move repositories to 'repos/' subdirectory
This patch changes the top-level directory layout as a preparatory
step for improving the tools for managing 3rd-party source codes.
The rationale is described in the issue referenced below.

Issue #1082
2014-05-14 16:08:00 +02:00