> On Feb. 6, 2018, 5:48 p.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/src/memory_profiler.cpp
> > Lines 197-240 (patched)
> > <https://reviews.apache.org/r/63368/diff/3/?file=1951296#file1951296line197>
> >
> >     I would still merge these two functions. Since it is for internal use 
> > only, it is fine to expect the user to understand when to expect a previous 
> > value (looks like there is one such instance in the current code).
> >     
> >     How about this?
> >     ```
> >     template<typename T>
> >     Result<T> writeJemallocSetting(const char* name, const T& value, bool 
> > requestPrevious)
> >     {
> >       if (!detectJemalloc()) {
> >         return Error(JEMALLOC_NOT_DETECTED_MESSAGE);
> >       }
> >     
> >       T previous;
> >       T* pprevious = requestPrevious ? &previous : nullptr;
> >       size_t size = sizeof(previous);
> >       size_t* pszie = requestPrevious ? &size : nullptr;
> >       
> >       int error = mallctl(
> >           name, pprevious, psize, const_cast<T*>(&value), sizeof(value));
> >     
> >       if (error) {
> >         return Error(strings::format(
> >             "Couldn't write value %s for option %s: %s",
> >             value, name, ::strerror(error)).get());
> >       }
> >     
> >       return requestPrevious ? previous : None();
> >     }
> >     ```
> >     
> >     And if you make `value` optional, you can have a single function plus 
> > maybe three syntactic sugar functions with descriptive names that call into 
> > the basic one.

To be honest this looks quite overloaded to me. If you insist I will change it, 
but I think two simple functions are better than one complicted.


> On Feb. 6, 2018, 5:48 p.m., Alexander Rukletsov wrote:
> > 3rdparty/libprocess/src/memory_profiler.cpp
> > Lines 264 (patched)
> > <https://reviews.apache.org/r/63368/diff/3/?file=1951296#file1951296line264>
> >
> >     Say "using std::string" in the beginning of the file and save hundreds 
> > of characters!
> 
> Benno Evers wrote:
>     I'm not a fan of using `using`-directives just to save some typing, as it 
> puts a large cognitive burden on the reader: Is `string` referring to name 
> imported to the global namespace via `using`, a class-local or a 
> function-local typedef, maybe defined in some `stout`-header? In any case, 
> one has to jump to a different context to double-check. Using `std::string`, 
> on the other hand, is not ambigous.
> 
> Alexander Rukletsov wrote:
>     ```
>     alex@alexr: ~/Projects/mesos $ grep -r -i --include *.cpp "std::string" 
> ./src | wc -l      
>          465
>     
>     alex@alexr: ~/Projects/mesos $ grep -r -i --include *.cpp "using 
> std::string" ./src | wc -l
>          371
>     ```
>     We have ~370 .cpp files with `using std::string` and \<100 mentions of 
> `std::string`. We also do not provide our own string type; ambiguous local 
> typedefs shall not be used.
>     
>     In addition to the above, I personally find meaningless prefixes and 
> characters, like `std::`, contributing to the cognitive load of the code.

> We also do not provide our own string type; ambiguous local typedefs shall 
> not be used.

You may know this, but I don't think you can assume every reader of the code 
does. Also, the second rule may be followed `de-facto`, but I don't think it's 
written down anywhere.


- Benno


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


On Feb. 6, 2018, 5:45 p.m., Benno Evers wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/63368/
> -----------------------------------------------------------
> 
> (Updated Feb. 6, 2018, 5:45 p.m.)
> 
> 
> Review request for mesos, Alexander Rukletsov and Benjamin Mahler.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> This class exposes profiling functionality of jemalloc memory allocator
> when it is detected to be the memory allocator of the current process.
> 
> In particular, it gives developers an easy method to collect and
> access heap profiles which report which pieces of code were
> responsible for allocating memory.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/Makefile.am 3071b7ce2b82a4ce0ea62e4d2b3518a6f5114803 
>   3rdparty/libprocess/include/process/memory_profiler.hpp PRE-CREATION 
>   3rdparty/libprocess/include/process/process.hpp 
> 8661706cb058efb26f5bfbcc84972f9930d3670f 
>   3rdparty/libprocess/src/CMakeLists.txt 
> f002c157dc2ca64da66bc4e61f5095f2b533ae1f 
>   3rdparty/libprocess/src/memory_profiler.cpp PRE-CREATION 
>   3rdparty/libprocess/src/process.cpp 
> 42e7adf740b234ebf23d2dcb71440749c0ed87ec 
> 
> 
> Diff: https://reviews.apache.org/r/63368/diff/5/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Benno Evers
> 
>

Reply via email to