> On Feb. 20, 2014, 2:27 p.m., Ben Mahler wrote:
> > 3rdparty/libprocess/include/process/help.hpp, lines 37-38
> > <https://reviews.apache.org/r/18321/diff/1/?file=499270#file499270line37>
> >
> >     Rather than return a pointer, seems like the responsibility of proper 
> > static storage should lie in the caller, no? I think HELP should be 
> > agnostic to how it is being called.
> 
> Dominic Hamon wrote:
>     true, but then all the callsites will have to remember to write:
>     
>     const std::string* THIS_HELP = new std::string(HELP(....));
>     
>     given 'HELP' looks like a macro that just does the write thing, it can 
> help out by returning a heap-allocated string pointer.
> 
> Ben Mahler wrote:
>     But I'm wondering whether we can change the current style of HELP usage 
> to avoid this.
>     
>     We only need to compute the HELP string once during initialize(), for 
> route()ing purposes. So, for example, a static function might be a good 
> alternative for callers:
>     
>     System
>     {
>       initialize()
>       {
>         route("/stats.json", STATS_HELP(), &System::stats);
>       }
>     
>       // This could live only in the .cpp file outside the System class if we 
> implement initialize() in the .cpp.
>       static std::string STATS_HELP()
>     }
>     
>     What do you think?

That seems reasonable. It puts the onus on the callsite to use HELP responsibly 
and doesn't require any changes to process.


- Dominic


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


On Feb. 20, 2014, 3:19 p.m., Dominic Hamon wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/18321/
> -----------------------------------------------------------
> 
> (Updated Feb. 20, 2014, 3:19 p.m.)
> 
> 
> Review request for mesos, Ben Mahler and Vinod Kone.
> 
> 
> Bugs: MESOS-1023
>     https://issues.apache.org/jira/browse/MESOS-1023
> 
> 
> Repository: mesos-git
> 
> 
> Description
> -------
> 
> See summary
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/include/process/clock.hpp 
> 82ae3c6f4928388d041803068a2a4362ddc3bcd5 
>   3rdparty/libprocess/include/process/help.hpp 
> 8d50419d9e794c64aecc5c8a906d3b1f6a288fac 
>   3rdparty/libprocess/include/process/time.hpp 
> 26cec3dadca8aa5b33964c5072be4671aa42a259 
>   3rdparty/libprocess/include/process/timeseries.hpp 
> b368b9bb9cd63fb331b2c137dcde759d0ee59ee6 
>   3rdparty/libprocess/src/process.cpp 
> 69898b7fff36fa5de048782ccbba63ce4a35f7c8 
>   3rdparty/libprocess/src/synchronized.cpp 
> 79b0849accd41d291fd083601cea7d4fe92782cf 
>   3rdparty/libprocess/src/timer.hpp 443b5a0f56f32193f90c11b7f0da76eabd9ecfde 
>   3rdparty/libprocess/src/timer.cpp aa1ee1bad51dbff7d81e49f242156e8ab25e6944 
> 
> Diff: https://reviews.apache.org/r/18321/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Dominic Hamon
> 
>

Reply via email to