<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Fri, Feb 22, 2013 at 10:12 AM, Eli Bendersky <span dir="ltr"><<a href="mailto:eliben@google.com" target="_blank">eliben@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">>> This is mainly bringing the code in line with the other DataExtractor<br>
>> use cases. DataExtractor's getXXX methods take a pointer to offset for<br>
>> reading it and updating it. My initial code used a reference, and I<br>
>> wanted it to be more consistent now. As for the coding convention, I<br>
>> know we don't have an explicit guideline for this, and yet I<br>
>> personally prefer not to use references in such cases, because looking<br>
>> at:<br>
>><br>
>> doFoo(param)<br>
>><br>
>> It's really hard to immediately see that param can be modified by<br>
>> doFoo. But looking at:<br>
>><br>
>> doFoo(&param)<br>
>><br>
>> It's easier.<br>
>><br>
>> But this is a minor argument. The main one is the consistency.<br>
><br>
><br>
> Oh, OK - I'll totally buy an argument from consistency if the code you're<br>
> being consistent with is nearby/obviously in contrast (ie: the two uses sit<br>
> side by side & would confuse users - which I guess is the case here), but if<br>
> we're both in agreement (a preference for reference in/out params) why not<br>
> just fix DataExtractor instead (& that way it'll be consistent with the rest<br>
> of the codebase)? It's not a huge class & the transformation would be fairly<br>
> easy I would think...<br>
><br>
<br>
</div>To clarify, I'm in favor of keeping the existing "INOUT by pointer"<br>
convention in DataExtractor, and by extension in nearby code.</blockquote><div><br></div><div style>Yep, guess I rushed to read what I was hoping to read & not what you actually wrote, sorry.<br><br>So just rephrase the tone of my previous reply & it mostly still applies & boils down to:<br>
<br>I'd rather creep consistency in the direction of the preferred style.<br>The style I prefer is not the style you prefer.<br>The style you prefer isn't really pervasive in the codebase so I'd rather push the wider style into the smaller areas than the smaller style into wider areas (& of course my preference here isn't entirely from consistency - it's also because it's what I like)</div>
<div style>I realize Google's coding conventions use this approach, but I believe they're somewhat the exception - I've not seen this as a common style in other C++ codebases.<br><br>and: pointers possible nullness makes me sad.<br>
<br>I know it's a tradeoff but I sort of wish there was an alternative that is both legible at call sites & doesn't reduce type safety by adding an 'invalid' state (null) to every such parameter. A simple tagging template type could be used, but is probably overkill. I'd use it if the only acceptable alternative was pointer passing for mutable parameters.</div>
<div style><br>- David <br></div></div><br></div></div>