> On Feb. 20, 2014, 10: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.

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?


- Ben


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


On Feb. 20, 2014, 11: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, 11: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