Subject: Re: [boost] Naming convention of iterated binary operation
From: Jeremy Murphy (jeremy.william.murphy_at_[hidden])
Date: 2016-05-02 05:30:40
On 2 May 2016 at 18:20, Rob Stewart <rstewart_at_[hidden]> wrote:
> On May 1, 2016 11:25:39 PM EDT, Jeremy Murphy <
> jeremy.william.murphy_at_[hidden]> wrote:
> >Dear list entities,
> >is there such a convention or precedent for naming an iterated binary
> >For example, Boost.Functional/Hash has an iterated hash() called
> >hash_range(). I don't mind the "_range" suffix but I prefer the
> >prefix based on the mathematical definition:
> >The case in point is gcd() in Boost.Math: we want to provide an
> >iterated gcd but we can't quite decide how to name it. I like the
> >"iterated_" prefix but I would rather go with whatever might be
> >the convention.
> Given that the definition you linked noted only a couple of cases using
> different names for iterated variants and a couple of cases that use the
> same name as for the non-iterated function, it isn't clear that there is a
> case for preferring that modifier. (I'm no mathematician, so I have no
> experience to draw upon here.)
Yes, I haven't searched far and wide for examples yet. I like the
"iterated_" prefix because it seems the most universal or generic in
meaning: it's not actually specific to C++ even though we have "iterators".
That's just my personal preference, not what I think is necessarily the
In C++, given overloading, it isn't necessary to use a different name for
> different arguments. Therefore, I wonder whether "gcd" is sufficient for
> the iterated case.
Indeed, this is an interesting point and I thought about it for some time
already. My (strong) feeling is that functions with different semantics
should have different names, but I don't have a formal or strong argument
to support this. I know we can use the same name but it doesn't seem like a
good idea apart from minimizing the number of names in a namespace.
A variadic template version with the same name makes sense to me, though.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk