Commit graph

6 commits

Author SHA1 Message Date
4988153e15 Library: prevent implicit bool conversion on iterator-like objects
...it should have been this way all the time.
Generic code might otherwise be ill guided to assume a conversion
from the Iterator to its value type, while in fact an explicit dereferentiation is necessary
2018-09-14 21:06:14 +02: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
46e573efb7 includes: split out rarely used PtrDerefIter
this allows us to avoid a boost include otherwise
dragged in through the widely used iter-adapter.hpp
2015-08-16 01:35:28 +02:00
ce7c38312d iterator improvements: use Lumiera Forward Iterator in range for loops
This is kind of the logic consequence, since we consider our
functional iterator concept still superior and will continue
to rely on it.

For some time now, I've considered to build a generic bridge
function, to use enable_if and metaprogramming to figure out
if some type is a "Lumiera Forward Iterator" automatically.
But since our concept is to some degree a contract regarding
semantics, which never can be captured by any kind of introspection,
such a bridge implementation would be rather heuristic and
bears the danger to trigger on types actually not intended
as iterator at all. So I consider such a solution as dangerous
and we'll settle with just supplying the necessary bridge
functions as free functions injected for ADL on a case by case base
2015-08-16 01:35:28 +02:00