«

Take a class like the following:

class Finger
{
public:

double length;
}


I'm writing reusable code and, being dictator, I dictate that "length"
cannot be negative. The following would be perfect:

unsigned double length;

But ofcourse doesn't compile.


So... I've come up with 3 potential solutions: A1 A2 B .


A) Create 2 separate member functions, GetLength and SetLength. SetLength
will reject negative numbers. When supplied with a negative number it will:
A1) Throw an exception
A2) Return a false boolean value indicating failure

B) Just document that the code will have undefined behaviour if length is
set to a negative number.



Which would you suggest? Any other suggestions?


I myself am leaning toward B.


Thanks


-JKop

"JKop" <> wrote in message
news:_uusc.350$...
> Take a class like the following:
>
> class Finger
> {
> public:
>
> double length;
> }
>
>
> I'm writing reusable code and, being dictator, I dictate that "length"
> cannot be negative. The following would be perfect:
>
> unsigned double length;
>
> But ofcourse doesn't compile.
>
>
> So... I've come up with 3 potential solutions: A1 A2 B .
>
>
> A) Create 2 separate member functions, GetLength and SetLength. SetLength
> will reject negative numbers. When supplied with a negative number it
will:
> A1) Throw an exception
> A2) Return a false boolean value indicating failure
>
> B) Just document that the code will have undefined behaviour if length is
> set to a negative number.
>
>
>
> Which would you suggest? Any other suggestions?
>
>
> I myself am leaning toward B.
>

A1 without a doubt.

Also note that A1 is a subset of B, so you could document B but implement A1
if you really wanted to. When your users complain about the exception, you
just say 'I told you the behaviour was undefined'.

john

John Harrison posted:

> A1 without a doubt.
>
> Also note that A1 is a subset of B, so you could document B but
> implement A1 if you really wanted to. When your users complain about
> the exception, you just say 'I told you the behaviour was undefined'.


Thanks for the input.


I myself think that that would be too kind. "Undefined behaviour" means
exactly what it says on the tin. It's like saying to a child, "Yes, Go play
with the matches and the petrol - Just don't come running to _ME_ when
you've burned yourself". And ofcourse, any responsible parent would say,
"Don't play with the matches and the petrol!" and then actually physically
prevent the children from performing such actions.

But... we're all consenting adults here.


Although I still haven't made my decision yet.


All input appreciated.


Thanks


-JKop

JKop wrote:
> Take a class like the following:
>
> class Finger
> {
> public:
>
> double length;
> }
>
>
> I'm writing reusable code and, being dictator, I dictate that "length"
> cannot be negative. The following would be perfect:
>
> unsigned double length;
>
> But ofcourse doesn't compile.
>
>
> So... I've come up with 3 potential solutions: A1 A2 B .
>
>
> A) Create 2 separate member functions, GetLength and SetLength.
> SetLength will reject negative numbers. When supplied with a negative
> number it will: A1) Throw an exception
> A2) Return a false boolean value indicating failure
>
> B) Just document that the code will have undefined behaviour if
> length is set to a negative number.
>
>
>
> Which would you suggest? Any other suggestions?
>
>
> I myself am leaning toward B.
>
>
> Thanks
>
>
> -JKop

Make a small property template class that allows for range validation, like
this:

#include <iostream>
#include <string>
#include <cstdlib>
using namespace std;

template <class T, class Modify>
class property
{
protected:
T var;
Modify mod;
public:
property<T, Modify>(const T& init, const Modify& m)
: mod(m), var(init)
{}

operator T()
{
return var;
}

property& operator =(const T& val)
{
if(!mod(val))
throw invalid_argument("bad property argument.");
var = val;
return *this;
}
};

template<class T>
struct RangeValidationPropModified
{
string msg;
T minval, maxval;
public:
RangeValidationPropModified<T>(string m, const T& minv, const T& maxv)
: msg(m),
minval(minv),
maxval(maxv)
{}

bool operator() (const T& val)
{
if(val >= minval && val <= maxval)
{
cout << msg;
return true;
}
else
return false;
}
};

int main(int argc, char* argv[])
{
property<int, RangeValidationPropModified<int> >
p(0, RangeValidationPropModified<int>("the property is being
modifed!\n", 0, 100));

cout << p << endl;
p = 5;
cout << p << endl;
p = 10;
cout << p << endl;
try
{
p = -1;
cout << p << endl;
p = 1000;
cout << p << endl;
}
catch(invalid_argument ex)
{
cout << ex.what() << endl;
}

system("pause");
return 0;
}

- Pete

Petec wrote:
> JKop wrote:
<snip>
>
> operator T()
> {
> return var;
> }

Should be:

operator T&()
{
return var;
}

To allow operators to be applied.

>
<snip>

?
"Petec" <> wrote in message
news:CWusc.8842$ nk.net...
> Petec wrote:
> > JKop wrote:
> <snip>
> >
> > operator T()
> > {
> > return var;
> > }
>
> Should be:
>
> operator T&()
> {
> return var;
> }
>
> To allow operators to be applied.
>
> >
> <snip>
>
>

* wrote:
> ?
> "Petec" <> wrote in message
> news:CWusc.8842$ nk.net...
>> Petec wrote:
>>> JKop wrote:
>> <snip>
>>>
>>> operator T()
>>> {
>>> return var;
>>> }
>>
>> Should be:
>>
>> operator T&()
>> {
>> return var;
>> }
>>
>> To allow operators to be applied.
>>
>>>
>> <snip>

??

Please don't top-post, BTW.

- Pete

"JKop" <> wrote in message
news:_uusc.350$...

> unsigned double length;
>
> But ofcourse doesn't compile.

> A) Create 2 separate member functions, GetLength and SetLength. SetLength
> will reject negative numbers. When supplied with a negative number it
will:
> A1) Throw an exception
> A2) Return a false boolean value indicating failure
>
> B) Just document that the code will have undefined behaviour if length is
> set to a negative number.
>
>
>
> Which would you suggest? Any other suggestions?

First choice = B for performance reasons, simplicity of code. The C++
standard does it all the time (ie. if iterator points to 2 plus end then
result is undefined, if std::sort compare function does not have strict weak
ordering then undefined behavior).

Second choice = A1. As a variation, only if NDEBUG is defined then do we
throw an exception.

Third choice = A2.

"Petec" <> wrote in message news:<CWusc.8842$ ink.net>...
> Petec wrote:
> > JKop wrote:
> <snip>
> >
> > operator T()
> > {
> > return var;
> > }
>
> Should be:
>
> operator T&()
> {
> return var;
> }
>
> To allow operators to be applied.

No. If the restriction is that the value should be positive,
one cannot allow T:perator*=, someonce could pass -1. The same
applies for operator+=, opertaor/=, and (for positive arguments)
to operator-=.

The correct form is operator T() const;, as it won't modify var.

Regards,
Michiel Salters

Michiel Salters wrote:
> "Petec" <> wrote in message
> news:<CWusc.8842$ ink.net>...
>> Petec wrote:
>>> JKop wrote:
>> <snip>
>>>
>>> operator T()
>>> {
>>> return var;
>>> }
>>
>> Should be:
>>
>> operator T&()
>> {
>> return var;
>> }
>>
>> To allow operators to be applied.
>
> No. If the restriction is that the value should be positive,
> one cannot allow T:perator*=, someonce could pass -1. The same
> applies for operator+=, opertaor/=, and (for positive arguments)
> to operator-=.
>
> The correct form is operator T() const;, as it won't modify var.

Ahh, yes, I forgot about that. I'll implement the operators on it and post
back here...

- Pete

>
> Regards,
> Michiel Salters