mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Bannier" <benjamin.bann...@mesosphere.io>
Subject Re: Review Request 40497: Add hex number support to numify()
Date Fri, 20 Nov 2015 15:23:03 GMT

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


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message