Feature Request: Each container class should have isEmpty () and isNotEmpty ()

General JUCE discussion
1

Right now most container (or container-like) classes have isEmpty () or empty () functions. Only very few have isNotEmpty () functions. This makes it hard to remember which class has what (even though modern IDEs help figure that out), but it leads to awfully inconsistent code.

if (container.isEmpty () == false)

seems super weird, when you’ve used

if ( conatiner.isNotEmpty ())

for other containers before.

Some container-like classes (e.g. MemoryOutputBuffer) don’t have either of these, so we have to resort to

if (output.getSize () != 0)

which seems super-strange, once you got used to isEmpty / isNotEmpty

Thanks,
Mike

2

Yep, fair point. I’d been meaning to do those when I had a moment.

1 Like
3

Thank you.

4

Since these are so trivial (header-file only) changes. Would you mind if I contributed a few (that I noticed) via a pull request? Or do you want to do it yourself to make sure you got all of them? I admittedly don’t know enough of the code-base to catch them all. I would probably find only the most obvious ones.

5

Cheers, but in this case a pull request probably wouldn’t save us any time.

6

So just for my information: do you agree that container-like classes (like the MemoryOutputBuffer etc.) also should have these functions, or is that too weird to you?

i would argue that technically there is no difference between a vector and a MemoryOutputBuffer, but maybe you have a different perspective?

7

Well, MemoryOutputBuffer certainly isn’t the same as a vector, but I’ve no objection to giving it a couple of these methods.

8

isn’t that the most std:: like way of doing things? i.e. deque.size() vector.size()…

9

Yep, but I vastly prefer the JUCE way to use isEmpty () and isNotEmpty () whenever I can. With the standard-lib we don’t have a choice.

10

No! It’s very bad form to use size() unless you really need to know the number it returns.

Most containers have an empty() method, but if not then the best way to check for emptiness would be v.begin() == v.end(). Calling something like deque.size() is very very inefficient.

1 Like
12

what about

for(size_t i = 0; i < vec.size(); ++i )
{

}
13

With luck the compiler gets the size once and uses that in the loop. With a bad compiler, it might have to calculate the size for each loop-iteration.

Using

for (auto foo : vec)
{

}

is much better (unless you really need the index).

14

about 90% of the time, i need the index.
it’s a shame there’s no way to get the index using that for( auto foo … ) approach.

15

How about:

int i = 0;
for (auto foo : vec)
{
   // Do stuff here with foo and/or i

    ++i;
}
1 Like
16

how do we know that they’re iterated in order? (I’m not too familiar with the inner workings of range-based for() loops)

17

Yes:

https://stackoverflow.com/questions/19052026/will-range-based-for-loop-in-c-preserve-the-index-order