Re: [boost] [xint] Sixth release, preliminary review again please

Subject: Re: [boost] [xint] Sixth release, preliminary review again please
From: David Abrahams (dave_at_[hidden])
Date: 2010-06-20 12:34:34

At Sun, 20 Jun 2010 12:18:16 -0400,
Chad Nelson wrote:
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> 
> > On 06/18/2010 10:22 PM, David Abrahams wrote:
> 
> >>> I think you might want to clarify that, since parameter has a
> >>> general meaning having nothing to do with the library.
> > 
> >> The general meaning is the one I had in mind. :-) fixedlength is
> >> one of the structs that I use for Boost.Parameter; it takes a
> >> (small-p) parameter of a length, in bits. The other structs
> >> previously took a Boolean parameter, but now they don't -- their
> >> mere existence, or lack thereof, is enough to tell the
> >> Boost.Parameter-enabled classes what to do.
> > 
> > So you're using a deduced parameter interface, I presume.
> 
> Yes. I couldn't figure out how to directly pass value, rather than type,
> parameters to class templates... I can't tell if I missed something or
> if it's just not possible (I suspect the latter, but read on). 

Not supported by the library; you have to use wrappers.

> Since I had to create a type for everything anyway, and there aren't
> any required parameters, the deduced interface made perfect sense.

Yeah, it works particularly well for template parameters.

> > It was the first time I'd used Boost.Parameter on a class template.
> > I wasn't able to find any examples of how to use it for that, other
> > than the sole one in the documentation, so the learning curve was
> > pretty steep. That's why the aforementioned "other structs" took a
> > parameter even though they really didn't need one, it was my first
> > attempt. If you ever feel the urge to update the documentation with
> > more examples, please feel free to use XInt's integer_t class, I'm
> > sure the next guy who tries to learn it would appreciate it.
> > 
> >> If you could be more specific about what you found missing from
> >> the docs, that might help.
> 
> In general, the biggest problem I found was that there was only the one
> example of how to use it on class templates. I couldn't tell which of
> the design decision you'd made on it were universal, and which you might
> have made differently under different circumstances. Using
> Boost.Parameter on class templates seems very different from using it on
> anything else, so my previous experiences with it didn't help as much as
> I expected in figuring out the best way to use it there. With more than
> one example, I could have gotten a better idea of what was possible, and
> where I could best use those abilities.

Patches welcome :-)

> I also had some trouble figuring out how to pass values (again, rather
> than types) to the class template in a way that MSVC would accept.
> Writing a class template that takes the value is easy enough for any
> reasonably competent C++ developer to figure out, but finding a way to
> actually *use* that value (as, for instance, a parameter to a
> non-Boost.Parameter-enabled class template) in MSVC was maddening, until
> I stumbled across integral_c. MSVC claims that such parameters aren't
> compile-time constants; GCC doesn't have any problem with them. That's a
> problem that many people won't run across, but I'd think that it's
> common enough to frustrate a good portion of people trying to use
> Boost.Parameter.
> 
> (It did occur to me to try creating a class with a non-explicit
> conversion constructor for the type that I wanted to pass in, but I was
> put off by the limitations described in type_traits' is_convertible
> function -- that it doesn't work with C++ Builder 5 or earlier, or
> Metrowerks 7 or earlier. I don't know how commonly used those are, and I
> didn't want to limit the people who can use XInt, so I didn't attempt it.)
> 
> I'm not criticizing the existing Boost.Parameter documentation. It was
> thorough, and sufficient to show me what I needed to do. I just would
> have felt more comfortable with it, and understood it more quickly, if
> I'd had a second example to compare to the first.

And I don't feel criticized, so no harm no foul.  I am asking because
I'd like to know if we could do something better.

-- 
Dave Abrahams
BoostPro Computing
http://www.boostpro.com