Re: [boost] [review][constrained_value] ReviewofConstrainedValueLibrary begins today

Subject: Re: [boost] [review][constrained_value] ReviewofConstrainedValueLibrary begins today
From: Robert Kawulak (robert.kawulak_at_[hidden])
Date: 2008-12-07 16:04:10

Hi Chris,

> From: Chris

> I spent two hours, read the document once.

Thank you for your time.

> I would like DEBUG sorted out though.   Would I 
> typedef all the bounded types?  I am not sure, I would rather have an 
> option to disable it using a macro as well.

You mean the possibility to turn all constrained objects into unconstrained by
defining one macro? I initially considered this, but I rejected the idea because
you may want to turn some checks off while leaving some of them on in one
program (note, that constrained values are useful not only for debugging).

However, I see that this functionality may be useful for people doing only debug
checks and maybe I'll add it if I find an easy and not too ugly way to do this.

> I tried to compile a test program using gcc 4.4 and linux, 
> but I don't 
> have utility/swap.hpp so I gave up.  
> I assume this in a boost beta/sandbox somewhere.

http://svn.boost.org/svn/boost/branches/release/boost/utility/swap.hpp

> I have a class called defaulted<typename T, T value>, that 
> will default 
> initialize a value so I don't forget to do it in the constructor.  
> This library reminds me of that.  You can combine it if you 
> want. :)

It might be possible to use bounded_int<defaulted<int, 10>, 10, 20>::type, which
should probably work if defaulted<T, ...> is implicitly convertible to T (but
also would require you to put calls to value() here and there).

>  Or add something like this:
> class A {
> 
> A() { // fails
> }
> 
> must_initialize<int> t;
> };

The problem is that the fact whether the default value is valid or not depends
on the constraint used and this can't be verified at compile-time in most cases.
Probably it's possible to implement a (a bit complicated, I'm afraid) mechanism
disabling the default constructor in cases like bounded_int<int, 10, 20>::type
and this may be worth considering in the future.

Best regards,
Robert