Commit graph

28 commits

Author SHA1 Message Date
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
ab90d9c71d Functions-Commands: discard the ability to compare functors for equivalence (closes #294)
evil hack R.I.P
2019-06-23 19:45:30 +02:00
ef74527f6b DOC: eliminate spurious mentions of tr1:: 2018-01-12 03:03:25 +01:00
afe07bdb16 decommission the safe-bool-idiom (closes #477)
obsoleted by C++11

 * in most cases, it can be replaced by an explicit conversion operator
 * especially for the Lumiera Forward Iterators, we need an implicit conversion
2017-04-02 06:42:23 +02:00
1a4b6545a0 maximum munch
...feels like X-mas
2016-12-23 04:23:03 +01:00
08e7e3df15 prefer more readable bool operator spelling
especially the '!' for negation is sometimes too terse
and easily overlooked.
2015-09-25 03:12:04 +02:00
a205653cad C++ uses a more precise meaning of 'convertiblity' now
Conversion means automatic conversion. In our case,
what we need ist the ability to *construct* a bool from
our (function) object -- while functors aren't automatically
convertible to bool. Thus we use one of the new predicates
from <type_traits>
2014-05-09 00:56:31 +02:00
7be1b7d35d Switch from TR1 preveiw to the new standard headers
- functional
- memory
- unordered collections
2014-04-03 22:42:48 +02:00
974c670d41 fix **** in doxygen comments
to make them stand out more prominently, some entity comments
where started with a line of starts. Unfortunately, doxygen
(and javadoc) only recogise comments which are started exactly
with /**

This caused quite some comments to be ignored by doxygen.
Credits to Hendrik Boom for spotting this problem!

A workaround is to end the line of stars with *//**
2013-10-24 23:06:36 +02:00
d9f84a9bfd clean up lib/meta namespaces 2011-12-03 03:15:59 +01:00
c96cd66688 draft implementation for time change and propagation 2011-09-25 19:25:52 +02:00
3f1b7651e9 GPL header whitespace 2010-12-17 23:28:49 +01:00
9473fd3d67 OutputDesignation implementation draft 2010-11-19 05:01:43 +01:00
fea85acd0e equality comparisons on function erasure objects covered
...well, as good as possible, as boost refuses to implement this feature
2009-10-11 05:57:43 +02:00
231278bafe implemented comparison on function erasure, pending test 2009-10-11 05:57:43 +02:00
5068016805 WIP draft how the equality comparison on a function erasure could work 2009-10-11 05:57:43 +02:00
c85d1d3cd8 ArgumentHolder finished, low-level integration test pass 2009-07-20 07:03:18 +02:00
2462dee5ca issue resolved, tests pass, finally (whew) 2009-07-06 02:25:19 +02:00
c3b8d39507 refactoring into two distinct concepts. maybe solution? 2009-07-05 22:05:11 +02:00
e2bb2c440c use OpaqueHolder to solve the problem with the function type erasure...
...tried to use 2 policies, but doesn't work correct (and is uggly)
2009-07-05 03:38:33 +02:00
b65658c10d try to fix a failing test (not really fixed yet) 2009-07-04 00:22:16 +02:00
8ea07bda7a use the new bool conversion mixin to implement check for valid functor 2009-06-26 19:04:22 +02:00
5291f6e41a move the member pointer to the current stack frame...
hopefully the optimiser will remove it completely ;-)
2009-06-26 17:13:36 +02:00
a30461780b this way it works, but would cost additional storage.... 2009-06-26 16:38:37 +02:00
daeff6f5fd WIP: how to define the bool conversion / validity check for the function holders? 2009-06-26 05:27:54 +02:00
a28c05877f test pass (resolves Ticket #174) 2009-06-20 06:11:09 +02:00
079030818d draft a test to sharpen the idea of the function holder (erasure) 2009-06-20 04:43:52 +02:00
a565bfef73 some header-renaming 2009-06-20 01:28:47 +02:00