JKop wrote:
>
> Ron Natalie posted:
>
> > Your copy constructor seems a bit spurious. If you
> can't construct an
> > invalid year object, how could you ever get an invalid
> one to copy?
>
> If by spurious you mean absent, then yes.
>
> What you think of my assignment operator?
I think it is not needed.
One of the premises is that it is impossible to create
an invalid Year object. So whetever is passed to the assignment
operator *must* be a valid Year object. Thus the test if it
is valid is not neccessary. A simple assignment of the data
member is sufficient. But this is what the compiler generated
operator does anyway, so it is better to let the compiler take
care of op= instead of writing your own.
>
> I wonder if it'd be appropriate to increment -1 to 1?
Sure, why not.
>
> Year& operator++()
> {
> return ( data == -1 ? data = 1 : data += 1 );
> }
But not like this.
it needs to return *this.
>
> Year& operator--()
> {
> return ( data == 1 ? data = -1 : data -= 1 );
> }
Same. return *this;
With other operators there is a problem on the horizon.
The problem I see is this: What is the return value of op- ?
Is it Year? Well, in every day speaking we say so, but is that really
true. Is a YearSpan the same thing as a Year?
Lets take the conservative approach and say: No. The result of
subtracting 1960 from 1940 is not a Year object, but a YearSpan object.
That makes sense, since adding 1940 with 1980 doesn't really make sense.
But adding 40 years (a YearSpan object) to 1980 makes perfectly sense.
What about op* and op- ?
Does it make sense to calulate 1940 * 1980 ?
I would say no. But it would make sense to allow op/ and op* for
a YearSpan object. 1940 + 2 * 40_years seems reasonable: add 2 times
the amount of 40 years (as YearSpan) to 1940.
--
Karl Heinz Buchegger