> On Nov. 20, 2015, 3:23 p.m., Benjamin Bannier wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/numify.hpp, line 30 > > <https://reviews.apache.org/r/40497/diff/2/?file=1133104#file1133104line30> > > > > I believe giving these proper names would make e.g., the ordering here > > much easier to grasp. > > > > What about `template <typename Target, typename Source> ..`? > > > > Also space after `template`.
Fixed, I also remove the Source type since I only need std::string there. hex_cast<string>(1) is beyond what I need. > On Nov. 20, 2015, 3:23 p.m., Benjamin Bannier wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/numify.hpp, line 40 > > <https://reviews.apache.org/r/40497/diff/2/?file=1133104#file1133104line40> > > > > I understand how the error string landed here from `numify`, but as > > written hardly anything about `hex_cast` is concerned with numbers (e.g., > > `hex_cast<string>(1.2)` is perfectly fine). > > > > You should probably make it more general here, and specialize the error > > message at the call site in `numify` instead. Removed the second type from template, see above. > On Nov. 20, 2015, 3:23 p.m., Benjamin Bannier wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/numify.hpp, line 39 > > <https://reviews.apache.org/r/40497/diff/2/?file=1133104#file1133104line39> > > > > Where you planning to output `c` here? Otherwise I suggest replacing > > this at least `ss.get()` (and drop the decl above). > > > > I like H.Sutter's synopsis of `boost::lexical_cast` even better since > > it shows clearly the failure sites (modulo the throw for here), see > > http://www.gotw.ca/publications/mill19.htm: > > > > template<typename Target, typename Source> > > Target lexical_cast(Source arg) > > { > > std::stringstream interpreter; > > Target result; > > > > if(!(interpreter << arg) || > > !(interpreter >> result) || > > !(interpreter >> std::ws).eof()) > > throw bad_lexical_cast(); > > > > return result; > > } > > > > You could do a similar impl just by injection a `<< std::hex`. I replace that ss.get() with ss.eof(). And also I don't understand why checking the return value of operator<< could work, it always return the stream right? The document says we should check ss.fail(). > On Nov. 20, 2015, 3:23 p.m., Benjamin Bannier wrote: > > 3rdparty/libprocess/3rdparty/stout/include/stout/numify.hpp, line 51 > > <https://reviews.apache.org/r/40497/diff/2/?file=1133104#file1133104line51> > > > > With the implementation you added, what keeps us from replacing this > > with `return hex_cast<T>(s)` and dropping the Boost `#include` to simplify > > the deps? Good point, but I only wanted to add the hex implementation here (see the next patch in the chain). We can do that later. - Cong ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/40497/#review107370 ----------------------------------------------------------- On Nov. 19, 2015, 10:56 p.m., Cong Wang wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/40497/ > ----------------------------------------------------------- > > (Updated Nov. 19, 2015, 10:56 p.m.) > > > Review request for mesos, Ben Mahler and Ian Downes. > > > Repository: mesos > > > Description > ------- > > numify() in libprocess uses boost lexical_cast() to cast numbers, but it can > not cast a hex number. This patch adds hex support to numify(). > > > Diffs > ----- > > 3rdparty/libprocess/3rdparty/stout/Makefile.am > 5a0ffc38d4194b9f9c53dc1cf0c90ca7bbae2afd > 3rdparty/libprocess/3rdparty/stout/include/stout/numify.hpp > ddd3dd9e015c583e04d72ac9a9b5a5ed6f1d49d5 > 3rdparty/libprocess/3rdparty/stout/tests/CMakeLists.txt > 14fb644b38a5cbb8cde74aab39e84305f6ab7041 > 3rdparty/libprocess/3rdparty/stout/tests/numify_tests.cpp PRE-CREATION > > Diff: https://reviews.apache.org/r/40497/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Cong Wang > >
