On 05/26/2014 12:01 PM, feverzsj wrote:
1) I do like
T t = convert<T>(from, cnv); // Throws on failure T t = convert<T>(from, default_v, cnv); // Returns 'def' on failure
and, if my memory serves me, that was pretty much review#1 interface (minus converters). What it misses though is handling one use-case -- deterministic non-throwing handling of conversion failure. When #2 returns default_v, we do not know if it is due to a failure or "from" just happened to convert to "default_v". Using a default value means user knows the default value won't be a valid input or it is used as a fallback or just not cared. If conversion failure must be explicitly catched, other interface should be used.
My problem is that I personally have great distaste for exceptions on mandate ordinary program-flow level. With regard to conversion that'd turn my 10-lines code block into 50-lines monster that I have difficulties reading. So, I handle it with optional<T> res = convert<T>(from, cnv); if (!res) { log("Invalid ignored. Proceeding with the default"); res = some_default; } no exceptions, no default-related non-determinism. Happy. And you want to take it way. :-(
2) I can see two potential problems with a converter provided by default:
a) it might be tricky separating
convert(TypeIn const&, Converter const& =some_default()); convert(Converter const& =some_default());
how about write another overload:
convert(TypeIn const&, Converter const&); convert(TypeIn const&); // using default converter
There is convert(Converter const&) It'll probably clash with convert(TypeIn const&)
b) different people might feel quite strongly what converter to be the default... and I'll be on the receiving end of their fury. :-( A default converter may be used in most of the daily job. It's important for boost lib to offer such convenience. If one wants different converter, he can always make himself one.
Understood. What I am trying to say is that your preferred default might well be not mine. That said, I'll go with the flow. What the majority decides on.