-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/40497/#review107370
-----------------------------------------------------------



3rdparty/libprocess/3rdparty/stout/include/stout/numify.hpp (line 30)
<https://reviews.apache.org/r/40497/#comment166475>

    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`.



3rdparty/libprocess/3rdparty/stout/include/stout/numify.hpp (line 39)
<https://reviews.apache.org/r/40497/#comment166474>

    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`.



3rdparty/libprocess/3rdparty/stout/include/stout/numify.hpp (line 40)
<https://reviews.apache.org/r/40497/#comment166476>

    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.



3rdparty/libprocess/3rdparty/stout/include/stout/numify.hpp (line 51)
<https://reviews.apache.org/r/40497/#comment166479>

    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?



3rdparty/libprocess/3rdparty/stout/tests/numify_tests.cpp (line 26)
<https://reviews.apache.org/r/40497/#comment166480>

    Would be nice to add a couple more positives here, e.g., to catch 
`hex_cast` impls like `boost::lexical_cast(s.substr(2)` ;)


- Benjamin Bannier


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
> 
>

Reply via email to