Re: [boost] boost CVS changes

From: David Abrahams (abrahams_at_[hidden])
Date: 2001-06-06 21:11:38

----- Original Message -----
From: "Aleksey Gurtovoy" <alexy_at_[hidden]>
> David Abrahams wrote:
> > I have moved the boost build system to the "build-development" branch.
> > I have also integrated Daryle's latest dlw_oprs submission into the
> > operators library.
>
> I should have catched this early, but.. due to default 'void' template
> parameters 'output_iterator_helper' fails to compile on MSVC:
>
> template <class T,
>           class V = void,
>           class D = void,
>           class P = void,
>           class R = void>
> struct output_iterator_helper
>   : incrementable<T
>   , boost::iterator<std::output_iterator_tag, V, D, P, R
>     > > {};
>
> MSVC problem with 'void' as default type template parameter is an old one;
> one possible workaround is to use 'void*' instead of 'void' if the latter
is
> just a placeholder for an unsignificant parameter.

I think a better choice might be boost::type<void>. We could then use a
little metaprogram to detect it and replace the type with void where it
really counts.

> It's not exactly the case
> here, as the standard _requires_ 'difference_type' and 'value_type' of
> output iterators to have 'void' type (24.3.1 [lib.iterator.traits]);
still,
> I haven't yet encountered a case when having output iterator value_type ==
> void* instead of plain void would make any difference. Actually, on the
> second thought, if those _are_ the requirements, probably
> 'output_iterator_helper' definition should look like this anyway:
>
> template <class T>
> struct output_iterator_helper
>   : incrementable<T
>   , boost::iterator<std::output_iterator_tag, void, void, void, void
>     > > {};

Why should reference and pointer be void by default? Do we mean void& and
void* (or something)?

> I am not sure that "void value_type" requirement is a reasonable one,
> though. After reading
>
http://groups.google.com/groups?as_q=output_iterator&as_uauthors=James%20Kuy
> per, it seems to me that it may be a defect as well. Thoughts?

I tend to agree. One could imagine generic output iterators, to which /any/
type could be written, but surely that's not a reasonable requirement to
impose.
As a matter of fact, I think the output iterator requirements table is a
complete mess. I guess I'm submitting an issue right away.

-Dave