Tiny constructor inconsistency in juce::String (think it's been mentioned before?)


#1

A few months ago I read this article http://herbsutter.com/2013/08/12/gotw-94-solution-aaa-style-almost-always-auto/

...and, well, after some rumination and research, I decided that he's right, and started to auto everything.  It's gone well, found one signed/unsigned unconsistency which wasn't causing trouble - yet - but basically cleaned up my code a bunch with very little work.

The one emergent issue is that I can't construct juce::String from an unsigned long.  This happens all the time when you do operations on a Component and then want to use the resulting number in a String.

Apparently clang (Apple LLVM version 4.2 (clang-425.0.28) (based on LLVM 3.2svn)) distinguishes "unsigned long" from whatever Juce's "uint64" works out as.

I seem to remember that this was an issue discussed earlier, and the problem is of course that other compilers don't make that distinction, so if you declare that constructor it's a duplicate.

Since you are already detecting what sort of compilation it is, you might consider at some point detecting those compilers which *do* make that distinction and conditionally adding that String unsigned long constructor.

It isn't a huge deal, but my code has cleaned up considerably now I've starting auto-ing everything, and I suspect others will do this over the years to come.


#2

Yes, I remember that one being a bit of a headache. Though I think it was MSVC that caused problems, because it didn't distinguish between size_t and unsigned long (or unsigned int.. or something.. I forget the details).

And yup, adding some extra compiler-specific flags would probably make it possible to work-around it, I'll do that at some point.