empty(), data(), size()

[olafvdspek@…]

While not being operators, those functions can be defined in terms of others. empty(): end() == begin() data(): empty() ? NULL : &*begin() size(): end() - begin()

Could those be added to the operators lib?

[Daniel Frey]

There are several issues here:

a) Domain - Currlenty, operators are arithmetic operators or iterator support. In your case, they are now container support (and not even real operators). I would like to restrict the operators library to what it is, I even think about splitting it into two libraries from time to time. Adding more operators (or operator-like functions) does not seem like a good idea.

b) Naming - How would you call the new base classes? emptyable? data-able? I don't see any obvious names for them.

c) Efficiency - If end() is O(n), so are empty(), data() and size(), although O(1) might be possible. Are we sure users get that or that it is unlikely enough to not be a problem?

d) Convenience - The (IMHO) real power of the operators library is, that there are groups of operators and that saves you from typing the same code over and over again. Plus that we ensure exploiting optimizations (RVO/NRVO) that some people might otherwise miss. For your case, there doesn't seem to be much gained by replacing the proposed functions by a base class each.

I am thus closing this ticket as "wontfix", if you disagree, feel free to reopen it or discuss it on the mailing list.

[anonymous]

Replying to daniel_frey:

a) Domain b) Naming - How would you call the new base classes? emptyable? data-able? I don't see any obvious names for them.

If the functionality provided is good, those issues should not be deal breakers.

BTW, iterator support doesn't sound like arithmetic either.

c) Efficiency - If end() is O(n), so are empty(), data() and size(), although O(1) might be possible.

Is O(n) allowed for end()?

Are we sure users get that or that it is unlikely enough to not be a problem?

I think it's not a problem.

d) Convenience - The (IMHO) real power of the operators library is, that there are groups of operators and that saves you from typing the same code over and over again. Plus that we ensure exploiting optimizations (RVO/NRVO) that some people might otherwise miss. For your case, there doesn't seem to be much gained by replacing the proposed functions by a base class each.

You already have indexable. Doesn't indexable imply random access? If not, don't you have the same O issue as end() you raised above? I think indexable implies empty(), data() and size() being suitable functions.

[olafvdspek@…]

There's also front(), back(), pop_front() and pop_back(). And maybe at().

BTW, I can't reopen the ticket as I don't have an account.

[Daniel Frey]

Replying to anonymous:

Replying to daniel_frey:

a) Domain

BTW, iterator support doesn't sound like arithmetic either.

Well, yes, that's why I said that I think about splitting the Operators Library. Since I worked on the arithmetics part (including rvalue-support), please allow me to finished it and post a proposal to the list. The remaining part (iterator support) could than be turned into its own library, not concentrating on operators, but on supporting iterators/containers in general, where adding more non-operator methods makes more sense than for the Operators Library. Maybe you want to become the main developer/maintainer of that part?

[Olaf van der Spek <olafvdspek@…>]

Replying to daniel_frey:

Maybe you want to become the main developer/maintainer of that part?

Sure, that'd be great.