Boost logo

Boost :

From: Ed Brey (brey_at_[hidden])
Date: 1999-12-10 11:12:33


"Moore, Paul" wrote:
>
> From: Ed Brey [mailto:brey_at_[hidden]]
> >
> > First, one interface issue:
> >
> > Should there be an assign function, similar to what std::string has.
> > This would allow you to reassign a rational without creating a
> > temporary. For example, in the read from stream operator, code would
> > change from
> > r = rational<Int>(n, d);
> > to
> > r.assign(n, d);
> >
>
> Hmm, I see your point. It could certainly be added. But I don't think
> std::complex has this (that was my model). I don't mind one way or the
> other.
>
> OK, I'll add one. Should it return a reference to the assigned rational?
> That allows things like r.assign(n,d).mem_fn(), but as rational has no
> non-trivial members, this may be overkill. I'll return the ref, to match
> string.

I meant for my sentence "Should there..." to end with a question mark,
because I'm not sure on this issue either. I like how not including
assign keeps the interface more minimal, but there is also the
question of whether eliminating assign makes the interface
sub-minimal, since assign essentially the overloading of operator= for
2 arguments. One could argue that you should have either both of
operator= and assign or neither of them. Clearly, complex argues
against that, which I am assuming is for good reasons.

Having assign can be more efficient, as is the case with string. In
the case of rational, since the assignment operator is compiler
generated, assign probably provides no runtime benefit for an
optimizing compiler.

It would be my temptation to leave assign out, assuming for now that
its absence in complex is for good reason and that it is easy to add
it later without breaking code, but once it's in, it's a pain to pull
it out.

I'm very curious to hear others' opinions on this.

> > 4. "normalise" is misspelled, should be "normalize".
>
> UK vs US spelling. I prefer the UK version...

That's fine. I wasn't aware that there was a difference. I'm
surprised that it didn't show up in either of two dictionaries I
checked. I thought that dictionaries usually contained UK spellings
and indicated them as such. I guess not. (I wonder if it matters
that both dictionaries came from Microsoft: Word 97 spell checker and
Bookshelf 1994.)

> I still believe that for a class like this, picking a representation and
> sticking to it is the right choice. Witness the std::complex class, which
> doesn't allow a choice between polar and cartesian representations. Giving
> the user too much choice just makes the interface more complex.

Agreed.


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk