Juce::String Y U NO work like std::string?


#1

1. Why is String::size complexity linear instead of constant?

2. Why is String::empty a static data member instead of a member function returning bool?


#2

1. Why is String::size complexity linear instead of constant?

That is annoying.  Having to plan and defer string length queries feels like the bad old days of C, and makes me pine for Pascal.

 

 2. Why is String::empty a static data member instead of a member function returning bool?

Srsly?

 

 


#3


#4

Oh yeah...that's right...utf-8 encoding. Forgot all about that!

But I suggest empty() as a function, for compatibility with standard containers.


#5

No!! I hate the way the std library uses the word empty. Because "empty" can be either a verb or an adjective, a method called "empty" could mean either "bool isEmpty()" or "void clear()". I've always deliberately made sure that my method names aren't ambiguous like that.

And re: complexity, in practice, the average string length is pretty short, and there's rarely much advantage to be gained from storing and maintaining a length for it. The place you'd expect it to be a big win is in concatenating, but in fact that's already linear-time because it has to re-allocate storage and copy the two existing strings.

I'm sure it'd be easy enough to create benchmarks or situations that would be biased either in favour of or against storing the length, but whenever I've performance-profiled any of my apps, the string length functions never even appear on the list (whereas string memory allocation/dealloction often does). Everyone's mileage will vary, of course.


#6

I second jules' opinion regarding method naming: I've always been confused by the empty() method in std containers, always being unsure whether it did check for emptiness or.. caused it!