From: Chuck Messenger (chuckm_at_[hidden])
Date: 2003-05-22 15:20:22
Rob Stewart wrote:
> From: "James Curran" <jamescurran_at_[hidden]>
>>Chuck Messenger wrote:
>>>>* add_options() should use references rather than pointers
>>>"Pointer for return value" is C semantics. In C++,
>>>pointers denote optional values. Non-const references are for return
>> I disagree *strongly*. In C and C++, the address-of syntax clearly
>>indicates that this is a value that will be changed. Your suggestion of
>>using a non-const reference would require me to check the header file to
>>find the signature of _every_single_F#$^%ing_function to figure out which
>>parameters are changed and which one's aren't. (particularly in the case of
> Disagree strongly all you want, but I only use pointers to
> indicate optional arguments and to pass references (general
> meaning of the word) to objects that are expected to outlive the
> object to which they are given (usually in the ctor). In the
> former case, the argument may be null so I check for that case.
> In the latter, I often use RCSPs, but not always.
> I don't use non-const reference parameters often (and when I do
> they are always the first argument(s)). I find they work
> intuitively. You see, such functions always indicate, by their
> very name, that they are providing a value, so the name quite
> reasonably documents the output parameter.
> Using pointers in this context would be counterintuitive to me.
> Ultimately, someone will be disappointed.
OK, how about this syntax, to make it much more clear what is being
returned (and, at the same time, to reduce the verbiage):
(param("magic|value|magic value for the program") >> magic)
(param("val||some value with a default", defaultValue) >> val)
I've combined all 3 strings into one argument. Why have 3? It just takes
up space. The 3 strings are separated by | (or pick a better seperator
char). param() is a template function. I haven't tested this, but it
seems like it could be made to work...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk