From: Ullrich Koethe (u.koethe_at_[hidden])
Date: 2001-11-20 10:27:59
> > Providing two image types would be easy, but I have doubts whether it
> > will buy much. Consider the possibilities:
> > * Image<bool> is unpacked. Than you can just as well use Image<byte>
> That's untrue; Image<unsigned char> has (should have) operator+ and
> operator&& with semantics differing from Image<bool>.
operator&& and operator|| have the correct semantics in both cases.
operator+ shouldn't be used with bool (you can use operator^ instead).
> you can't pass a pixel of Image<unsigned char> to foo( bool& ).
On g++, this doesn't work with std::vector<bool> either, because
std::vector<bool>::operator returns a proxy (type _Bit_reference).
BTW, on g++ 'sizeof(bool) == 4'. So Image<unsigned char> will be smaller
than Image<bool> unless the latter is packed, with all problems that the
use of proxies implies.
> Well, this is the same problem as with vector<bool>: Even the standard
> doesn't provide algorithm specializations for vector<bool>::iterator. I do
> think that the needs of image processing on 1-bit images warrant
> writing these specializations, at least for basic operations. Complex
> algorithms should be based on simple operations; let the compiler do
> the inlining.
> Of course, one of the advantages of boost / open source is that you can
> just leave such work to the first person who needs it done.
> No money == much less obligations.
;-) So, is anyone in need of specialized functions for Image<bool>?
-- ________________________________________________________________ | | | Ullrich Koethe Universität Hamburg / University of Hamburg | | FB Informatik / Dept. of Computer Science | | AB Kognitive Systeme / Cognitive Systems Group | | | | Phone: +49 (0)40 42883-2573 Vogt-Koelln-Str. 30 | | Fax: +49 (0)40 42883-2572 D - 22527 Hamburg | | Email: u.koethe_at_[hidden] Germany | | koethe_at_[hidden] | | WWW: http://kogs-www.informatik.uni-hamburg.de/~koethe/ | |________________________________________________________________|
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk