From: Alois K. <Alu...@gm...> - 2007-01-10 09:34:36
|
Hello, Up to now I assumed, the vil_image_view(uint, uint) constructor would give me an image of black pixels. But now there's some other data in there just after creating the view. So, is my assumption wrong? Is it my duty to give an initial value to the view's data? Best regards Alu -- Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen! Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer |
From: Ian S. <ian...@st...> - 2007-01-10 10:29:39
|
Alois Komenda wrote: > Hello, > > Up to now I assumed, the vil_image_view(uint, uint) constructor would give me an image of black pixels. But now there's some other data in there just after creating the view. > > So, is my assumption wrong? Yes > Is it my duty to give an initial value to the view's data? Yes The reason is efficiency. If you don't need black pixels, then vil shouldn't waste time filling them. Ian. |
From: Markus M. <mar...@es...> - 2007-01-10 12:38:33
|
Hello On Wednesday 10 January 2007 11:29, Ian Scott wrote: > Alois Komenda wrote: > > Up to now I assumed, the vil_image_view(uint, uint) constructor would > > give me an image of black pixels. But now there's some other data in > > there just after creating the view. > > > > So, is my assumption wrong? > > Yes > > > Is it my duty to give an initial value to the view's data? > > Yes > > The reason is efficiency. If you don't need black pixels, then vil > shouldn't waste time filling them. > > Ian. Alois' question made me have a look at vil_image_view. There is a mild (?) problem with it. The memory allocated through vil_memory_chunk is reinterpret_cast to a pointer to the pixel type. The behavior of accessing the pixels through this pointer is, however, undefined. I understand that it is a reasonable assumption that it will "just work", but anyway... it needn't. The standard-compliant way would be to placement-new an array of the pixel type into the memory allocated by vil_memory_chunk and later, before deletion, to call the destructor explicitly on each element. For POD types, these additional operations should be optimized away on most platforms (neither the placement new nor the destruction loop can be found in corresponding assembler output of my GCC 4.1 (i386)), for other types, invoking constructors and destructors is in fact crucial. Just a thought... Regards Markus -- PGP key on www.esat.kuleuven.be/~mmoll/public_key.pgp Fingerprint is 90C4 B47D 1A00 5AC1 9147 3197 EDA7 1E0E 99E4 9EDB Disclaimer: http://www.kuleuven.be/cwis/email_disclaimer.htm |
From: Ian S. <ian...@st...> - 2007-01-10 13:13:57
|
Markus Moll wrote: > Hello > > On Wednesday 10 January 2007 11:29, Ian Scott wrote: >> Alois Komenda wrote: >>> Up to now I assumed, the vil_image_view(uint, uint) constructor would >>> give me an image of black pixels. But now there's some other data in >>> there just after creating the view. >>> >>> So, is my assumption wrong? >> Yes >> >>> Is it my duty to give an initial value to the view's data? >> Yes >> >> The reason is efficiency. If you don't need black pixels, then vil >> shouldn't waste time filling them. >> >> Ian. > > Alois' question made me have a look at vil_image_view. There is a mild (?) > problem with it. The memory allocated through vil_memory_chunk is > reinterpret_cast to a pointer to the pixel type. The behavior of accessing > the pixels through this pointer is, however, undefined. I understand that it > is a reasonable assumption that it will "just work", but anyway... it > needn't. The standard-compliant way would be to placement-new an array of the > pixel type into the memory allocated by vil_memory_chunk and later, before > deletion, to call the destructor explicitly on each element. For POD types, > these additional operations should be optimized away on most platforms > (neither the placement new nor the destruction loop can be found in > corresponding assembler output of my GCC 4.1 (i386)), for other types, > invoking constructors and destructors is in fact crucial. I would be surprised if anyone ever uses a platform and a pixel type combination that require explicit construction. I don't doubt that they exist, just that they won't be used in practice. I'm personally happy that it just works, but if you have a burning desire to fix it, please be my guest :-) Ian. |