Bug #5829
openWFormModel::FieldMap with "const char*" key
0%
Description
In 3.3.8-9d1c071 the fields in WFormModel are stored in FieldMap. FieldMap type is defined in WFormModel:294 as map with key of type Field. Field is defined as "const char*" in WFormModel:108. Using "const char*" type as key in std::map without comparison functor may result in lookup failure later, i.e. in value() function in WFormModel.C:108 - find is called, but returns fields_.end() when called using argument of different address (since default lookups in maps with "const char*" needs exact "==" match, not strcmp-type one) than the original one used in addField.
Updated by Roel Standaert almost 7 years ago
This was by design: a field is identified uniquely by the pointer to its (compile time) string literal constant.
As you can see in the widget gallery (https://www.webtoolkit.eu/widgets/forms/integration-example), the fields are only identified using a static member, never actually using a string.
Are you experiencing this as an issue, e.g. generating the field name or something? I discussed it here, and maybe we could consider turning it into std::string for Wt 4.
Updated by Martin Ubl almost 7 years ago
Well, this design decision completelly cuts out any dynamic approach to model fields using their names, which I need for my application atm. Furthermore, I don't think this is expected behaviour for most programmers - when I call addField("field1"), I expect value of this field to be retrieved using value("field1"), but if something happens, and compiler considers these two literals as two different ones and stores them at two different addresses, a problem may occur.
Yes, when using single constant (e.g. the way you mentioned in "integration example"), where I could be sure the address remains constant, it makes sense, but I can imagine a lot of situations, where this could cause trouble - e.g. using some kind of dynamic approach (generating field names when creating model / retrieving values), not using single literal (eighter due to laziness or some kind of accident), etc. Furthermore, I don't quite see the point in this design decision, since I think this could cause more trouble, especially when somebody doesn't know about this and tries to implement one of cases I mentioned before.
So my suggestion is to use std::string instead of const char* for type Field.