StringArray::addTokens is behaving strangely, replacing a period with a space as the delimiter

1

I have the following code:

String path = "F:\\Example\\Words With Spaces\\something.ext";
StringArray pathComponents;
pathComponents.addTokens(path , ".");
String fileExt = pathComponents[pathComponents.size() - 1];

In the end, fileExt is “Spaces\\something.ext”. This is unexpected. I was hoping it would be “ext”. It appears to be using the space character as the delimiter instead of the period.

2

It sounds like you’re building without warnings enabled. The const char* argument is being implicitly cast to bool and selecting this overload:

    int addTokens (StringRef stringToTokenise, bool preserveQuotedStrings);

You probably meant to call the other overload, so you should add another const char*/StringRef argument.

1 Like
3

I should check the warnings more. That’s very insightful and solved the issue. Thank you.

4

Pro-tip, You should not (aka almost never) have any warnings.

1 Like
5

Turn on “Treat Warnings as Errors” and fix everything. You will be glad you did.

I turned on "Treat Warnings as Errors about five years ago, and have never looked back. It helps make better programs.

5 Likes
6

Well, the default JUCE project does have a lot of unreferenced formal parameter warnings, so you’d need to use a custom default project. The unreferenced formal parameters are pretty convenient, so I wouldn’t want to eliminate them. Sometimes warnings are just warnings, however. I think keeping the warnings low is pretty good advice, but even better than that, is to understand the warnings.

7

What about the warning when your project name has an _ in the title?
Obviously, I could rename the project, but I don’t think that warning should be treated as an error.

Thoughts?

8

IMHO, underscores are best reserved for libraries. But, I think we are all entitled to our own style—whatever works best for you.

I know in my personal experience, it has helped my code to have “Treat Warnings as Errors” turned on.
And, it is satisfying when it compiles clean. But anyone with enough knowledge and experience, and who understands all of the nuances of the warnings, may do fine with the warnings.

9

You could also try a static analysis tool if you’d like more warnings.

10

Isn’t that warning just about the AU bundle identifier? In which case you can just rename that bit in Projucer without (com.myco.myplugin) and still retain the underscore in the project/plugin name (_myplugin).