Is This rule of deciding the best method of parameter passing totallyright ?

[Öö Tiib]

On Nov 22, 8:55 am, Good Guy <[email protected]> wrote:

    [...]

For idealist taste C++ has way too many flavors of parameter passing.
Ideally necessary and sufficient are two flavors: A) input-only
parameter and B) input-output parameter.

What about output parameters?  This is what C++ really lacks.

I prefer to use return value as output-only. When there are multiple
outputs i prefer to wrap them into pairs or tuples (or classes when
the combination has useful meaning). When the output may be missing i
prefer to have a "nullable", "optional" or "fallible" return type (or
to throw on rarely actually expected error cases).

The cases when i have to use output-only parameters are usually in
some language-neutral or cross-language interfaces that have limits
about value types and their usage. On such cases however the interface
requirements define the limits (and what to do with output-only
parameters).

 

[Rick Wheeler]

I would like an example of a contract that is using pointers for
the relevant objects everywhere.  My observation of using references
rather than pointers in generated middleware is the reference syntax
reduces the amount of output that has to be produced and sent to the
user.  Technically you may have a strong argument, but practically
it has a drawback.

Brian Wood- Hide quoted text -

- Show quoted text -

A common example where pointers may be used everywhere is one that
utilizes an object factory in its design pattern. Many times such a
framework give no-throw guarantees for much of its interface regarding
null object pointers (the "null pointer contract" coined previously).
I don't quite follow the aspect of more output requirements, etc. The
semantics of pass by address for non-const have never added any extra
work or output, that I've ever encountered.

Rick

 

[Öö Tiib]

A common example where pointers may be used everywhere is one that
utilizes an object factory in its design pattern. Many times such a
framework give no-throw guarantees for much of its interface regarding
null object pointers (the "null pointer contract" coined previously).
I don't quite follow the aspect of more output requirements, etc. The
semantics of pass by address for non-const have never added any extra
work or output, that I've ever encountered.

Factories usually *return* abstract interface pointers. Most often
smart pointers. Smart pointers because with "pointer to abstract base
class" only small fraction of raw pointer usage makes sense, therefore
it is good to block all the illegal usages compile time with smart
pointer wrapper. Also products of factories may need special deleters
and with smart pointer you do not need to expose such.

How can this suggest to use raw pointers as function parameters? Once
you have realized that the factory did not fail you can pass around
references and no one has to handle nulls.

 

[James Kanze]

On Nov 22, 8:55 am, Good Guy <[email protected]> wrote:

[...]

For idealist taste C++ has way too many flavors of parameter passing.
Ideally necessary and sufficient are two flavors: A) input-only
parameter and B) input-output parameter.

What about output parameters? This is what C++ really lacks.

I guess the OP consider that they are return values so not
parameters. One can also consider that a fucntion that need
more than one output parameter should be refactored making the
case irrelevant.

Well, if you want to change a few definitions, and simply
discard the cases you don't feel like handling...

The question was intended to provoke actual thought: why doesn't
C++ have output paramters. Or perhaps better: what would they
look like. Saying that they are return values is a valid
response, IF you define some way for C++ to handle multiple
return values, and declare multiple objects initialized by the
multiple return values of a single function. (I believe go has
something like this.) Alternatively, you need some way of
declaring uninitialized space which becomes a variable when it
is passed to a function which takes an out parameter, and cannot
be used otherwise until then.

But I'd be interested in hearing about alternatives.

 

[Rick Wheeler]

Factories usually *return* abstract interface pointers. Most often
smart pointers. Smart pointers because with "pointer to abstract base
class" only small fraction of raw pointer usage makes sense, therefore
it is good to block all the illegal usages compile time with smart
pointer wrapper. Also products of factories may need special deleters
and with smart pointer you do not need to expose such.

How can this suggest to use raw pointers as function parameters? Once
you have realized that the factory did not fail you can pass around
references and no one has to handle nulls.- Hide quoted text -

- Show quoted text -

You're exactly right. Once successful objects are created by a
factory, the resident design could call for a reference based
interface thereafter as appropriate (whether smart pointers were
involved or not). It would even be preferred for const based
interaction with said objects. But there's been a misunderstanding if
you've interpreted any sort of recommendation on call convention or
anything at all from this factory example. The discussion only arose
parenthetically to the premise that one does not have to offer null
pointers as legitimate arguments when handling pass by address
semantics for non-const.

Rick