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