Strangely inconsistent warnings when using <sstream>

12 Jul 2010

I found a case where I will get warnings on one compile, but when I immediately hit the [compile] button again, there are no warnings.

To recreate, make a new project and paste this code into main.cpp:

#include "mbed.h"
#include <string>
#include <sstream>

string intToStr(int i){
   stringstream ss;
   ss << i;
   return ss.str();
}
int main() {
    int i=10;
    string str=intToStr(i);
    printf("number %i as a string = %s\n", i, str);
}

Compile this and you'll get a few warnings, which makes sense because the use of str in the last line is a little sloppy.  Change it to the more correct:

 

printf("number %i as a string = %s\n", i, str.c_str());

 

(If the forum strips out the #includes, I'm including string and sstream)

And compile.  I see the following two warnings:

"<__c.0> may be used before being set" in file "/opt/RVDS4/RVCT/Data/4.0/400/include/unix/rw/_ioiter.h"

"<__c.0> may be used before being set" in file "/opt/RVDS4/RVCT/Data/4.0/400/include/unix/streambuf"

But if I immediately hit compile again I get no warnings at all.  If I make any edits to the code at all it throws the warnings again, even just adding a comment. But, again, if I compile a second time with not changes there are no warnings.

(This happened under Win XP, Chrome 6, Firefox 3.6 and IE8 using both the current and the beta compiler.)

13 Jul 2010 . Edited: 13 Jul 2010

The use of streams and the STL is not currently supported, although there is a low-priority bug already open on this. However, using the stream classes does eat up quite a large chunk of RAM, of which the LPC1768 only has 32K available to applications to play with (after you remove the Ethernet, CAN and USB RAM), so you may want to consider using some classic C methods of string handling anyway.

13 Jul 2010

Noted.  I'll see what I can do to update my libraries.   I saw that it did eat up a hunk of RAM, but that's a typical sacrifice when doing rapid prototyping...