Changed arg, hasArg, header, hasHeader from const char * to String

[hallard]

Added arg_P hasArg_P and hasHeader_P to be able to test arg from string
stored in flash

[igrr]

How do you feel about replacing the two methods (one taking const char* and another one taking PGM_P) with one method taking a String?
The overhead of constructing String from const char* is not that big, plus we will have less code.

[hallard]

@igrr
do you mean something like that

String ESP8266WebServer::arg(String name) {
  for (int i = 0; i < _currentArgCount; ++i) {
    if ( _currentArgs[i].key == name ) 
      return _currentArgs[i].value;
  }
  return String();
}

String ESP8266WebServer::arg(const char* name) {
  String argname = name; // Copy to RAM, avoid loop search compare from flash
  return arg(argname);
}

String ESP8266WebServer::arg(PGM_P name) {
  String argname = name; // Copy to RAM, avoid loop search compare from flash
  return arg(argname);
}

[igrr]

I mean leave just String ESP8266WebServer::arg(String name), because const char* arguments as well as PGM_P arguments will be converted to String automatically.

[hallard]

Makes sense, glad to know these kind are converted to string :-)
It's done

[igrr]

Thanks! Could you please change String header(const char* name); to accept String as well? It now looks oddball among other methods accepting Strings.

[hallard]

Yeah, of course, it's done

[Links2004]

the use of String has one "problem",
you will have the data too times in ram on time in the stack for where the String class is inited and a second time in the heap where the String class copy the data.
for small data its ok, but if you work with big data its not good.
in the most cases the copy is use less sine you not need it Independent modifiable, or modifiable at all.

[hallard]

Good catch, whatever solution is fine for me, my initial goal was just to be able to call these arg and hasArg with PGM_P flash stored string and I did not find a way to get it working (ie compiling) without using String, but I'm ready to learn because it's making me mad ;-)
I'm old C programmer for years, and to be honest, sometimes C++ does not seems to be so "intuitive" for me

[igrr]

I don't think that extra memory consumption due to Sting use is an issue for this particular use case, since argument names are usually quite short.

[hallard]

I must admit both have pro/cons, String is simple and by the way I think it's more speed efficient for my case, because if we loop among all args to match name we search (I've got about 30 args) doing some pgm_read_byte (needed to compare) for each char of each args can be slower than a String comp? But may be I'm wrong.

[Links2004]

@igrr yes for this short data its not a big deal, my post where more a general info to only having String as parameter type, for example for sending payload data to a Webserver its not a good idea when you have big data. There are some potential for optimization in our code too, for example using "String &" to avoid unnecessary data duplication in ram.

@hallard for the arg loop case the String will perform better then PGM_P and little bit faster then const char* since the String class already know the length of the string and so the first step is the length compare which is faster then only byte by byte.

[hallard]

Guys,
I'm sorry about this but since I made all calls with string parameter, when I'm calling hasArg (and other) with PGM_P I've got a crash

The code flash_str.cpp

// Web Interface/serial configuration Form field/command names
const char CFG_SAVE[]       PROGMEM = "save";

The code flash_str.h

// Web Interface/serial configuration Form field/command names
extern const char CFG_SAVE[] ;

The .ino

if ( server.hasArg(CFG_SAVE) )
  //if ( server.hasArg("save") )
  {
    // blah blah
  }

the result

Exception (3):
epc1=0x4000bdcb epc2=0x00000000 epc3=0x00000000 excvaddr=0x4024dff4 depc=0x00000000

ctx: cont 
sp: 3fff3470 end: 3fff37d0 offset: 01a0

seems PGM_P arguments have problem to be converted to String automatically
Any idea what I'm doing wrong ?

[hallard]

Forgot this one, just my revert back from #1582, code reverted back ;-)