headers
Adam Merz | 1 Jun 2010 01:25
Picon
Favicon

Re: [gil] Is bit_aligned_pixel_iterator a standard conformant random access iterator?

Hi Christian, this is ildjarn from the MSDN forums. :-]

Christian Henning <chhenning <at> gmail.com> writes:
> Hi there, I'm having an interesting discussion over at the MSDN forums
> regarding compiler errors with MSVC10 that show up when using standard
> algorithms and bit_aligned images. Basically the question is why
> MSVC10 doesn't understand that bit_aligned_pixel_iterator is a random
> access iterator.

To be clear, it's not that MSVC10 doesn't understand that
bit_aligned_pixel_iterator is a random access iterator, it's that
bit_aligned_pixel_iterator *isn't* a random access iterator. I.e.,
std::iterator_traits< bit_aligned_pixel_iterator >::iterator_category is
std::input_iterator_tag on every compiler/platform. It's just that MSVC10
refuses to instantiate std::copy given a destination iterator categorized as an
input iterator (which is a good thing). If GIL had a regression test with a
static assertion that boost::is_same< std::iterator_traits<
bit_aligned_pixel_iterator<...> >::iterator_category,
std::random_access_iterator_tag >::value == true, this would have been caught
long ago. (hint, hint)

One perspective is that the bug here is that bit_aligned_pixel_iterator is
trying to pass itself off as a random access iterator in the first place,
despite the fact that it returns a proxy object rather than an actual
reference, violating the standard's requirements for forward iterators.
However, since it appears to work properly on all tested toolsets, that could
be deemed an acceptable flaw, in which case the proper fix is to pass
iterator_facade a category of std::random_access_iterator_tag rather than
boost::random_access_traversal_tag. Easy enough. :-]
(Continue reading)

Permalink | Reply | 3 comments |
headers
Christian Henning | 1 Jun 2010 01:53
Picon

Re: [gil] Is bit_aligned_pixel_iterator a standard conformant random access iterator?

Hi Adam,

On Mon, May 31, 2010 at 1:25 PM, Adam Merz <adammerz <at> hotmail.com> wrote:
> Hi Christian, this is ildjarn from the MSDN forums. :-]
>

Interesting disguise. ;-)

> To be clear, it's not that MSVC10 doesn't understand that
> bit_aligned_pixel_iterator is a random access iterator, it's that
> bit_aligned_pixel_iterator *isn't* a random access iterator. I.e.,
> std::iterator_traits< bit_aligned_pixel_iterator >::iterator_category is
> std::input_iterator_tag on every compiler/platform. It's just that MSVC10
> refuses to instantiate std::copy given a destination iterator categorized as an
> input iterator (which is a good thing). If GIL had a regression test with a
> static assertion that boost::is_same< std::iterator_traits<
> bit_aligned_pixel_iterator<...> >::iterator_category,
> std::random_access_iterator_tag >::value == true, this would have been caught
> long ago. (hint, hint)
>
> One perspective is that the bug here is that bit_aligned_pixel_iterator is
> trying to pass itself off as a random access iterator in the first place,
> despite the fact that it returns a proxy object rather than an actual
> reference, violating the standard's requirements for forward iterators.
> However, since it appears to work properly on all tested toolsets, that could
> be deemed an acceptable flaw, in which case the proper fix is to pass
> iterator_facade a category of std::random_access_iterator_tag rather than
> boost::random_access_traversal_tag. Easy enough. :-]

Easy enough, correct. I did this change to my local boost for a couple
(Continue reading)

Permalink | Reply | 1 comment |
headers
Adam Merz | 1 Jun 2010 02:17
Picon
Favicon

Re: [gil] Is bit_aligned_pixel_iterator a standard conformant random access iterator?

Christian Henning <chhenning <at> gmail.com> writes:
> Easy enough, correct. I did this change to my local boost for a couple
> of gil's iterators. I have less compiler errors now. Do older MSVC
> versions and other compiler define std::random_access_iterator_tag? If
> though, I could add this fix to boost, as is.

Yes, std::random_access_iterator_tag is standard and portable; you just need to
#include <iterator> to use it.

That said, I'm dubious as to whether this is the only fix (iterator_facade's
category decaying mechanisms strike me as questionable) or even the correct fix
(it violates the standard's requirements), so in my opinion this warrants a
larger discussion, especially since at least one other released library is
affected by the exact same issue.

> I really have a hard understanding where and when the metafunction
> boost::detail::iterator_facade_default_category is actually reducing
> bit_aligned_pixel_iterator to an input iterator?

The instantiation path from bit_aligned_pixel_iterator to
iterator_facade_default_category is:

boost::gil::bit_aligned_pixel_iterator ->
boost::iterator_facade ->
boost::detail::iterator_facade_types ->
boost::detail::facade_iterator_category ->
boost::detail::facade_iterator_category_impl ->
boost::detail::iterator_facade_default_category

> When I do this:
(Continue reading)

Permalink | Reply | 0 comments |
headers
OvermindDL1 | 1 Jun 2010 03:52
Picon

Re: [Boost-docs] Maintaining boost.org

On Tue, May 25, 2010 at 4:05 AM, Daniel James <dnljms <at> gmail.com> wrote:
> On 25 May 2010 03:49, OvermindDL1 <overminddl1 <at> gmail.com> wrote:
>>
>> Could always create such a site using Wt[0] or so in pure C++/Boost
>> itself for a good demonstration, would be simple enough to do, just
>> have to remake a few things that already exist out there in other
>> languages, not hard though.
>>
>> [0] http://www.webtoolkit.eu/wt
>
> Isn't Wt more orientated towards developing applications rather than
> hosting content?

Not necessarily, even the main Wt site is very static.  The main bits
I like about it are:
 - It is like developing a gui application, using signal handlers, etc...
 - It support javascript to only update the parts of a page that are
changed, rather then all of it, and it gracefully falls back to pure
html when javascript is disabled or does not work and so forth, in the
general case the interface seems really *fast* (see the homesite
again).
 - It is pure C++, what is probably all of ours favorite language,
with all the power that entails, it uses boost as-is currently as
well.

It is really easy to just whip something up really quick in it, as
stated, it is like developing a gui program, static or not, it is
always easy.  It can serve up static HTML as well, can migrate things
over as necessary.
(Continue reading)

Permalink | Reply | 11 comments |
headers
Artyom | 1 Jun 2010 08:04
Picon
Favicon

Re: [Boost-docs] Maintaining boost.org


> >> Could always create such a site using Wt[0] or so
> in pure C++/Boost
> >>
> >> [0] http://www.webtoolkit.eu/wt
> >
> > Isn't Wt more orientated towards developing
> applications rather than
> > hosting content?
> 
> Not necessarily, even the main Wt site is very
> static.  The main bits
> I like about it are:
>  - It is like developing a gui application, using signal
> handlers, etc...

Few words about Wt model:

- It holds server side live object for every user session which is quite
  huge overhead for high traffic web site.

  There is a quote from their docs:

  > Thus, for every new session, Wt spawns a new process.
  > This has the main benefit of enjoying kernel-level memory protection
  > between user sessions. 

  I don't think that it is true for latest versions but it is quite
  bad design for scalability.
(Continue reading)

Permalink | Reply | 10 comments |
headers
Anthony Williams | 1 Jun 2010 08:42
Picon

Re: Mutexes claim a Windows event handle

"Peters, Richard" <richard.peters <at> oce.com> writes:

> I have a problem with boost::recursive_mutex "sometimes" keeping a
> handle to a Windows Event. My application uses a lot of objects, each
> containing a recursive_mutex. The objects are accessed from different
> threads using a scoped_lock (see code below). In Boost 1.34 there was no
> problem, but after we switched to 1.39 it seems that the process
> collects more and more handles to Windows Events. Only when the objects
> that contain the recursive_mutex are destroyed, the handles are released
> again. The problem is that I must support 100,000 objects containg
> multiple mutexes, so if each mutex can cost one handle the total number
> of handles in use may become huge.

The old boost::mutex implementation used CRITICAL_SECTION on Windows;
the new version uses atomics and a lazy-allocated Event, which is only
allocated in the case of actual contention on the
mutex. CRITICAL_SECTION objects have similar behaviour.

> I tried the latest Boost version (1.43) but that makes no difference.
> The strange thing is that not every object keeps a handle, i.e.: the
> number of handles collected is less than the number of objects created.
> When increasing the nrActions the number of handles collected comes
> closer to the number of objects.

That's the lazy allocation at work --- you only need the Event if
there's contention for the mutex.

> I could understand if a recursive_mutex costs a handle, except that in
> boost 1.34 they didn't so I wonder if this was an accident or a
> deliberate change. And most important: Is there a way to get the same
(Continue reading)

Permalink | Reply | 7 comments |
headers
Christian Henning | 1 Jun 2010 10:01
Picon

[gil] how does dereference_iterator_adaptor defines it's iterator category?

Hi all,

I'm still investigating compilation errors with my gil extension while
compiling on MSVC10. I have exchanged
boost::random_access_traversal_tag with
std::random_access_iterator_tag with all gil iterator types. This
solved some of my problems. Some still remain. Here is what I have
discovered.

When using a boost::gil::kth_channel_view_type with bit_aligned image
types I'm running into the same problem I had with just using
bit_aligned image types. Now kth_channel_view_type uses a
boost::gil::dereference_iterator_adaptor for iteration purposes. This
adaptor defines it's iterator category as
boost::detail::iterator_category_with_traversal<std::input_iterator_tag,boost::random_access_traversal_tag>
which is wrong. I have been trying to figure out where this definition
is coming from. But I'm not able to. All occurrences of
random_access_traversal_tag have been removed from gil code. Which
leads me to believe it's coming from boost itself somewhere.

Here is some code displaying the problem.

#include <vector>
#include <algorithm>

#include <boost/gil/gil_all.hpp>

using namespace std;
using namespace boost;
using namespace boost::gil;
(Continue reading)

Permalink | Reply | 3 comments |
headers
Adam Merz | 1 Jun 2010 11:27
Picon
Favicon

Re: [gil] how does dereference_iterator_adaptor defines it's iterator category?

Christian Henning <chhenning <at> gmail.com> writes:
> I'm still investigating compilation errors with my gil extension while
> compiling on MSVC10. I have exchanged
> boost::random_access_traversal_tag with
> std::random_access_iterator_tag with all gil iterator types. This
> solved some of my problems. Some still remain. Here is what I have
> discovered.
> 
> When using a boost::gil::kth_channel_view_type with bit_aligned image
> types I'm running into the same problem I had with just using
> bit_aligned image types. Now kth_channel_view_type uses a
> boost::gil::dereference_iterator_adaptor for iteration purposes. This
> adaptor defines it's iterator category as
> boost::detail::iterator_category_with_traversal<std::input_iterator_tag,
> boost::random_access_traversal_tag> which is wrong. I have been trying to
> figure out where this definition is coming from. But I'm not able to. All
> occurrences of random_access_traversal_tag have been removed from gil code.
> Which leads me to believe it's coming from boost itself somewhere.
> 
> Here is some code displaying the problem.
<snip code>

dereference_iterator_adaptor uses iterator_adapter with a traversal/category
type of boost::use_default. The way use_default behaves is to discover the
category/traversal type of the iterator it's adapting
(bit_aligned_pixel_iterator<...> in this case), then convert that into a
traversal type. In this case, bit_aligned_pixel_iterator has a category of
std::random_access_iterator_tag, which gets converted back into
boost::random_access_traversal_tag. iterator_adapter then hands off its work to
iterator_facade, giving iterator_facade this traversal type instead of the
(Continue reading)

Permalink | Reply | 2 comments |
headers
Adam Merz | 1 Jun 2010 11:45
Picon
Favicon

Re: [gil] how does dereference_iterator_adaptor defines it's iterator category?

Adam Merz <adammerz <at> hotmail.com> writes:
> Change lines 47 and 53 in pixel_iterator_adaptor.hpp from 'use_default' to
> 'typename std::iterator_traits<Iterator>::iterator_category'.

Apologies, lines 47 and 55, not 53.

_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
Permalink | Reply | 0 comments |
headers
Stewart, Robert | 1 Jun 2010 14:14
Favicon

Re: [boost::endian] Request for comments/interest

Tomas Puverle wrote:
> Kim wrote:
> > Rob Stewart wrote:
>
> > > IOW, the spelling changes from "{from,to}_{big,little}_endian"
> > > to "{from,to}<{big,little}_endian>."
> >
> > Yes, something like that was what I had in mind.
>
> You certainly have the functionality to go from/to the host
> endianess to/from any other but how do you write code which
> needs to go from a specific endianess to another specific
> endianess?  It seem that would be much easier in my
> interface than with the one above.

I've never had the need to convert data from one specific endianness to another, though I can imagine some
sort of conversion or translation utility doing so.  Note that it seems rare indeed to have a utility that
does nothing but endianness conversion rather than needing to do something to the data during the conversion.

There are several scenarios for converting X-to-Y endianness:

# | Source | Destination | Host
--+--------+-------------+-----
1 |   B    |   B         |   B
2 |   B    |   B         |   L
3 |   B    |   L         |   B
4 |   B    |   L         |   L
5 |   L    |   B         |   B
6 |   L    |   B         |   L
7 |   L    |   L         |   B
(Continue reading)

Permalink | Reply | 5 comments |

Gmane