Photon command line build failure

Last night I was able to build firmware, but it now appears the Particle includes are now causing the build to fail somehow:
It looks like Particle.Variable() no longer handles the String class? Also, look at how the assertion error is misspelled:

In file included from …/wiring/inc/spark_wiring.h:46:0,
from ./inc/application.h:36,
from firmware.cpp:1:
…/wiring/inc/spark_wiring_cloud.h: In instantiation of ‘static bool CloudClass::variable(const T*, const String&, const CloudVariableTypeString&) [with T = char]’:
firmware.cpp:142:49: required from here
…/wiring/inc/spark_wiring_cloud.h:79:9: error: static assertion failed:

In Particle.varible(“name”, myVar, STRING); myVar must be declared as char myVar[] not String myVar

     static_assert(sizeof(T)==0, "\n\nIn Particle.varible(\"name\", myVar, STRING); myVar must be declared as char myVar[] not String myVar\n\n");

make[1]: *** […/build/target/user/platform-6firmware.o] Error 1
make: *** [user] Error 2

Have a look here
Particle Firmware Updates Thread
Help creating STRING variables

It never was a good idea to use a String object for a Particle.variable() since the actual stored string might get relocated causing the “link” between the string and the Particle.variable() to break.
Before you weren’t warned about the risk, but it would have happened. Now you get told beforehand that this may break your code and hence will not build.

Sorry I must be reading over it, where is the spelling mistake?

@ScruffR, there is a reference to a new function called Particle.varible :wink:

Ahh, now I see :eyes: :eyeglasses: - Thanks, I’ve been reading over it several times and just could not see it.
Biased reading?

Oops. I mispelled that…

1 Like

Pinging @mdma here: just making sure that it’s unsafe to use Particle.varible("name", myVar, STRING) with String myVar given that String can implicitly convert to char *.

Sounds better guidance about Particle.variable for Strings is needed in the docs.

ahh… Yes I did notice that in some cases the pointer to the String would change during assignment. I’ll use char[] instead. I figured it had something to do with the new firmware, but early in the morning, I didn’t have much patience to debug :smile:

1 Like

We will add full support for Strings in 0.4.7. Right now they are dangerous since the internal pointer can change as the memory is reallocated leading to the pointer passed to Particle.variable() returning garbage.

Previously, I was using ‘String.reserve(BUFFER)’ as a way to create a String buffer that maintained the same pointer during re-assignment. This ensured that when I passed the string to Particle.variable() that the string I was pointing to stayed valid. But I was depending upon your implementation of String.reserve. char[] is tried and true. I had been using your helper methods such as String.toInt() and String(someIntVar) to convert between Int and String and that’s why I was avoiding using char[].

To compile with 0.4.6 I just have to write my manipulated String variables to a char[] using String.toCharArray() and everything works as expected now.

You could also pass yourString.c_str() to Particle.variable() if you are certain the buffer won’t be reallocated.

Just for the sake of saying - this only keeps the string in place as long you never assign a string longer than BUFFER or have no operations causing the string to grow beyond the limit.

1 Like

Or have an operation that calls the invalidate method of String which frees the buffer.

1 Like