[boost] Re: Re: in/out parameters, codingstylesandmaintenance

From: Gennadiy Rozental (gennadiy.rozental_at_[hidden])
Date: 2003-05-02 10:15:20

I. in<T> vs. T const&

To be fair we need to compare separately inline/offline usage of const and
in<T>

1. Offline type enforcement

a. regular code

|  int const a = 123;
|
| // enforced by compiler at compile time
| // f required to accept const reference
|  f( a );
| // to be able to call "unfair" function we need special trick
|  g( const_cast<int>( a ) );

b. in<T> template

| in<int> a = 123;

| // enforced by compiler at compile time
| // cause f expects in<T>
|  f( a );
| // to be able to call "unfair" function we need special trick
|  g( in_out<int>( a ) ); // in<T> -> in_out<T> conversion is bad style, but
const_cast either

2. Inline type enforcement

a. regular code

|  int a = 123;
|
| // we are not required to use static_cast<const int>
| // even though f expect const reference
| f( a );
| // to be able to call "unfair" function no need to do anything
| // but from statement below you can't say whether or not 'a' change
| g( a );

b. in<T> template

|  int a = 123;
|
| // we are required at compile time to use in<T> conversion to be able to
call f
| // cause f expect in<T> parameter
| f( in<T>( a ) );
| // to be able to call "unfair" function no need to do anything
| // but from statement below you can't say whether or not 'a' change
| g( a );

Whether or not the requirement of typing extra in<T>(  ) is advantage or
burden is the matter of standpoint. It's an abuse from the developer, using
function f, standpoint. But it's an advantage from the maintainer
standpoint - cause it more clear what is going on.

Is it a good practice to define parameters in<T> instead of T const&? It may
have some sense.

II. out<T> vs. T&

It does not have to much sense to use offline version. So let's compare
inline only

a. regular code

|  int a; // no value
|
| // maintainer couldn't know
| // whether missing value is an error or not.
|  f( a );

b. out<T> template

| out<int> a;

| // enforced by compiler at compile time
| // cause f expects out<T>
| // clear that no need to assign the value above
|  f( out<int>( a ) );

It's abuse from developer standpoint, but may have some advantages from a
maintainer standpoint.
Is it a good practice to define parameters out<T> instead of T&? It may have
some sense.

II. in_out<T> vs. T&

Since in/out is default behavior of C++ reference parameter, I agree that
there is no real difference between f( a ) and f( in_out<int>( a ) ). There
may be some difference with offline usage though (if we would be able to
implement it).

a. regular usage

|  int a = 123;
|
| // we are not required to use static_cast<int&>
| // even though f expect T&
| // but from statement below you can't say whether or not 'a' change
| f( a );

b. in_out<T> template

|  in_out<int> a = 123;
|
| // to be able to call function that expects in_out<T> no need to do
anything
| f( a );
| // to be able to call function that expects T& we need to call method ref
| f( a.ref() );
| // to be able to call function that expects T const & we need to cast 'a'
to in<T>
| //
| h( in<int>( a ) );

Difference: from developer standpoint some burden of extra typing. From
maintainer standpoint: we know that 'h' does not change the value.

Is it a good practice to define parameters out<T> instead of T&? It does not
have too much sense.
Is it a good practice to use local variable in_out<T> instead of T? It may
have some sence, but rarely.

Conclusion:

Do we want to have it in boost? We may, though I could live without it.

Gennadiy.