> On Nov. 17, 2015, 8:06 p.m., Joseph Wu wrote:
> > 3rdparty/libprocess/3rdparty/stout/include/stout/windows.hpp, lines 58-66
> > <https://reviews.apache.org/r/39852/diff/2/?file=1126009#file1126009line58>
> >
> >     I'm wondering what the alternatives are.
> >     
> >     `GetMessage` seems to be some sort of alias for `GetMessageA` or 
> > `GetMessageW`.  What would happen if we just used the A/W methods instead?
> >     
> >     Do we even need to redefine this?  Would anything break if we just 
> > `#undef` d it?

I have updated my comments so hopefully this is more clear, but the short 
answer is that we don't use (or expect to use) the Windows `GetMessage` macro 
at all internally.

But, we choose to redefine it transparently so that anyone who happens to 
consume this header (either on purpose, or accidentally by including some other 
random header in Mesos) will not suddenly have `GetMessage` obliterated on 
their machine. So, the effect should be that no code changes are required if 
you're using `GetMessage`, but it should also allow us to use the protobuf 
`GetMessage` without macro interference.


- Alex


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


On Dec. 15, 2015, 10:10 p.m., Alex Clemmer wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39852/
> -----------------------------------------------------------
> 
> (Updated Dec. 15, 2015, 10:10 p.m.)
> 
> 
> Review request for mesos, Artem Harutyunyan, Michael Hopcroft, Joris Van 
> Remoortere, and Joseph Wu.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Windows: Replaced global `GetMessage` macro with inline function.
> 
> 
> Diffs
> -----
> 
>   3rdparty/libprocess/3rdparty/stout/include/stout/windows.hpp 
> 43c85f50958dd9a7ee2ad7c32565585560486c69 
> 
> Diff: https://reviews.apache.org/r/39852/diff/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Alex Clemmer
> 
>

Reply via email to