On Mon, Jun 4, 2012 at 2:09 PM, Sam Panzer <[email protected]> wrote:
> Now I'm wondering how much of this behavior should be "string"-specific. > If we're paying attention to conversion operators from non-POD types, why > not check for all possible conversion operators? I think this is a better > solution than checking to see if there's a conversion operator from the > return type of a c_str() function. > I think conversion operators aren't really as interesting and at least should be handled as a separate follow-on patch. I also think they're completely uninteresting when considering the result of 'c_str()'. All of the interesting cases actually return the character pointer we're looking for. > > Not depending on std::string was the plan, and in fact how I implemented > it :) > > On Mon, Jun 4, 2012 at 1:44 PM, Chandler Carruth <[email protected]>wrote: > >> On Mon, Jun 4, 2012 at 1:37 PM, Sam Panzer <[email protected]> wrote: >> >>> Here is one other question: With this patch, incorrectly passing an >>> std::string to printf generates an error (can't pass non-POD member), a >>> warning (printf format doesn't match), and a note (the c_str() suggestion). >>> Is this the behavior we want? >> >> >> I don't think so... Ideally: >> >> 1) If we are about to issue a an error (non-POD object passed through >> printf), check whether the non-POD object has a 'c_str()' method that >> returns a type which matches the format specifier. If so, use a specific >> diagnostic message for the error, attach a fixit-hint suggesting >> '.c_str()', and continue parsing as-if the user had done that. >> >> 2) If there is no error (passing a std::string* perhaps), then in the >> warning message, give a more precise message than 'cannot convert >> std::string* to const char*' or whatever by checking if there is a c_str() >> method that matches the type of the printf. >> >> >> One thing I would encourage you to do: don't base this on 'std::string'. >> I actually think the error/warning should fire for any class type with a >> c_str method that returns a viable type. That way non-standard string >> libraries will get the same benefit if they conform the the same conceptual >> interface as the standard string library. >> > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
