TiXmlElement::Attribute suggestion

[Mateusz Loskot]

Hi,
Is there any way to make this code shorter?

const char* attr = pElem->Attribute("name");
if (NULL != attr)
{
   std::string name(attr);
}

If there isn't, I have a few suggestions.

1. Default value of attribute if not met as passed as parameter

I mean, to override TiXmlElement::Attribute to take also a value which wil be returned if searched attribute is not found:

const char* TiXmlElement::Attribute(const char * name, const char* default)

Now I can call:

std::string name(pElem->Attribute("name", ""));

So, if there is no attribute, I assing empty string to name, instead of NULL (as it would be in current implementation) what causes exception (wrong: std::string s(NULL))

2. Couldn't if be nice to provide also full STL-ized versions of methods for attributes:

std::string TiXmlElement::Attribute(const std::string& name)

Cheers
Mateusz

[B Sizer]

I would definitely like to support the first suggestion. I don't think the second suggestion needs to go in though, as you can automatically convert a char* to a std::string. But I am not going to complain if it appears in the next version or anything.

[Ellers]

I like the default value approach, but also I like the approach where the value is stored in an out-parameter and the return value indicates success/failure.

So, what about ...

[code]
std::string value;
bool ok;
ok = pElem->Attribute("title", "DefaultValue", value);
[/code]

or

[code]
if (!pElem->Attribute("title", value) {
  value="DefaultValue";
}
[/code]
?

[Mateusz Loskot]

> I would definitely like to support the first suggestion

Sure, I agree. That's enought to get rid off all those NULL checkups of const char* returned by TinyXML API.

Thanks.

[Mateusz Loskot]

> I like the default value approach,
> but also I like the approach where the value is stored
> in an out-parameter and the return value indicates
> success/failure.

Yes, I love such approach too.
But that's a bit another story and I think it is to much API redesing effort.
Certainly, it is possible to provide API based on both approaches (existing one, and the new you are suggesting)
but I think that it could make API bloated and too huge.
API should be consistent and predictible by use, I mean if user will learn that every return value means error code, not the value he wants to read, then he will be much familiar with all TinyXML API.
But if we mix up various approaches, then user will be confused.

Cheers