Commit graph

17 commits

Author SHA1 Message Date
20f3252892 Upgrade: down with typename!!
Yet another chainsaw massacre.

One of the most obnoxious annoyances with C++ metaprogramming
is the need to insert `typename` and `template` qualifiers into
most definitions, to help the compiler to cope with the syntax,
which is not context-free.

The recent standards adds several clarifications, so that most
of these qualifiers are redundant now, at least at places where
it is unambiguously clear that only a type can be given.

GCC already supports most of these relaxing rules
(Clang unfortunately lags way behind with support of newer language features...)
2025-07-06 01:19:08 +02:00
d888891d84 clean-up: trifles 2025-06-07 23:59:57 +02:00
806db414dd Copyright: clarify and simplify the file headers
* Lumiera source code always was copyrighted by individual contributors
 * there is no entity "Lumiera.org" which holds any copyrights
 * Lumiera source code is provided under the GPL Version 2+

== Explanations ==
Lumiera as a whole is distributed under Copyleft, GNU General Public License Version 2 or above.
For this to become legally effective, the ''File COPYING in the root directory is sufficient.''

The licensing header in each file is not strictly necessary, yet considered good practice;
attaching a licence notice increases the likeliness that this information is retained
in case someone extracts individual code files. However, it is not by the presence of some
text, that legally binding licensing terms become effective; rather the fact matters that a
given piece of code was provably copyrighted and published under a license. Even reformatting
the code, renaming some variables or deleting parts of the code will not alter this legal
situation, but rather creates a derivative work, which is likewise covered by the GPL!

The most relevant information in the file header is the notice regarding the
time of the first individual copyright claim. By virtue of this initial copyright,
the first author is entitled to choose the terms of licensing. All further
modifications are permitted and covered by the License. The specific wording
or format of the copyright header is not legally relevant, as long as the
intention to publish under the GPL remains clear. The extended wording was
based on a recommendation by the FSF. It can be shortened, because the full terms
of the license are provided alongside the distribution, in the file COPYING.
2024-11-17 23:42:55 +01:00
73737f2aee Library/Application: consolidate Monitor implementation
After the fundamental switch from POSIX to the C++14 wrappers
the existing implementation of the Monitor can now be drastically condensed,
removing several layers of indirection. Moreover, all signatures
shall be changed to blend in with the names and patterns established
by the C++ standard.

This is Step-1 : consolidate the Implementation.

(to ensure correctness, the existing API towards application code was retained)
2023-10-15 02:41:41 +02:00
4e94dfd4d9 FailureHandling: improved ZombieCheck
now capturing the Zombie's ID

==> surprise, its ClassLock<gui::interact::LocationQuery>
2018-10-01 05:51:21 +02:00
d6167c1845 DependencyFactory: reorder destructor to allow for re-entrance
This is borderline yet acceptable;
A service might indeed depend on itself circularly
The concrete example is the Advice-System, which needs to push
the clean-up of AdviceProvicions into a static context. From there
the deleters need to call back into the AdviceSystem, since they have
no wey to find out, if this is an individual Advice being retracted,
or a mass-cleanup due to system shutdown.

Thus the DependencyFactory now invokes the actual deleter
prior to setting the instance-Ptr to NULL.
This sidesteps the whole issue with the ClassLock, which actually
must be already destroyed at that point, according to the C++ standard.
(since it was created on-demand, on first actual usage, *after* the
DependencyFactory was statically initialised). A workaround would be
to have the ctor of DependencyFactory actively pull and allocate the
Monitor for the ClassLock; however this seems a bit overingeneered
to deal with such a borderline issue
2018-04-01 07:06:58 +02:00
bfbcc5de43 simplify ClassLock by use of Meyer's Singleton with zombie check
...and package the ZombieCheck as helper object.
Also rewrite the SyncClassLock_test to perform an
multithreaded contended test to prove the lock is shared and effective
2018-04-01 06:09:01 +02:00
f0eeafddaa Identified some problems regarding static destruction
When some dependency or singleton violates Lumiera's policy regarding destructors and shutdown,
we are unable to detect this violation reliably and produce a Fatal Error message.
This is due to lib::Depend's de-initialisating being itself tied to template generated
static variables, which unfortunately have a visibility scope beyond the translation unit
responsible for construction and clean-up.
2018-03-31 17:27:13 +02:00
7fc462209e some naming cleanup and namespace indentation fixes 2010-12-18 00:58:19 +01:00
3f1b7651e9 GPL header whitespace 2010-12-17 23:28:49 +01:00
dc991ca563 valgrind suppression: add some more cases to be filtered 2010-02-13 06:00:38 +01:00
aa7fe2591c use a dedicated header to pull up early NoBug init 2009-01-26 01:09:49 +01:00
Christian Thaeter
b9fc2d6522 WIP: deploy new logging flags in lib 2009-01-24 22:30:25 +01:00
974e83676a Further ClassLock refactoring; added linkonce assertion check 2009-01-21 13:04:28 +01:00
801f070a7d Fix for broken logic of the ClassLock (showed up on Ubuntu Hardy)
this was nice copy-n-paster error, of course the implementation
namespace was never intended to be anonymous.
2009-01-21 12:19:02 +01:00
bd2ead37d5 Refactoring V: get lifecycle of a class-based monitor correct. 2008-12-26 05:44:49 +01:00
2173698e75 splitt off the (somewhat problematic) class locking case into a separate header 2008-12-26 04:25:01 +01:00