www.digitalmars.com         C & C++   DMDScript  

D.gnu - can i have such problem in D

reply dennis luehring <dl.soluz gmx.net> writes:
hi newsgroupers,

history: im working on an 3-years c++ project with >100000 lines of code 
writte by ~6 programmers

in my current programming task i've found the following "bug" in the (x 
years old)code:

void Item::getValue(double dValue)
{
   dValue = m_dValue;
}

hidden under x classes/methods-calls

my problem is that it should be (after analysing the using code ;-))

void Item::getValue(double& dValue)

to work properply - but the old version compiles without error
(cause it changes only the local copie)

what the problem: it seems for me that this missing-& bug was just a 
typo after x years of development (and the project still compiles very 
well after this - it runs only a little,little bit unusual)

in D it could be the best solution to declare (as compiler default) all 
paramter copies as "const" so a typo would
result in an compiler error (l-value specifies const object) or 
something (like pascal does?)

what does D do to prevent us from such dump-bug? what is the D solution?
are none-pointer/referenced parameters(copies) always handled as const?

ciao dennis (form germany)
Jun 29 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Tue, 29 Jun 2004 15:12:00 +0200, dennis luehring <dl.soluz gmx.net> 
wrote:

 hi newsgroupers,

 history: im working on an 3-years c++ project with >100000 lines of code 
 writte by ~6 programmers

 in my current programming task i've found the following "bug" in the (x 
 years old)code:

 void Item::getValue(double dValue)
 {
    dValue = m_dValue;
 }

 hidden under x classes/methods-calls

 my problem is that it should be (after analysing the using code ;-))

 void Item::getValue(double& dValue)

 to work properply - but the old version compiles without error
 (cause it changes only the local copie)

 what the problem: it seems for me that this missing-& bug was just a 
 typo after x years of development (and the project still compiles very 
 well after this - it runs only a little,little bit unusual)

 in D it could be the best solution to declare (as compiler default) all 
 paramter copies as "const" so a typo would
 result in an compiler error (l-value specifies const object) or 
 something (like pascal does?)

 what does D do to prevent us from such dump-bug? what is the D solution?
 are none-pointer/referenced parameters(copies) always handled as const?

 ciao dennis (form germany)


I advocated a change to D which would have caught this bug. I'll 
re-advocate it now :)


Basically D has 3 function parameter types (they work like storage 
classes):

in    - parameter is input from outside, changes to it do not affect the 
external variable passed.

out   - parameter is output, it gets initialised at the start of the 
function and changes to it affect the external variable passed.

inout - parameter is both input and output, it is not initialised and 
changes affect the external variable passed.

'in' is the default so this code...

int foo(int a, out int b, inout int c)
{
	a = 5;
	c = 7;
}

void main()
{
	int oa = 1,ob = 2,oc = 3;
       foo(oa,ob,oc);
}

will *not* effect oa, oa will == 1 after the call to foo.
will effect ob, ob will == 0 after the call to foo.
will effect oc, oc will == 7 after the call to foo.

the reason ob == 0 is due to the 'out' parameter type, it causes the 
variable to be initialised to the init value of the type (for int this is 
0).


So.. your example in D would be:

void Item::getValue(out double dValue)
{
	dValue = m_dValue;
}

but, say the programmer forgot the 'out' just as they forgot the '&' in 
which case

void Item::getValue(double dValue)
{
	dValue = m_dValue;
}

would miss-behave exactly as it does in C++.


My change was to make the 'in' parameter type enforce const behaviour. In 
other words your example would generate a compiler error as dValue is 'in' 
and thus const and the line:

   dValue = m_dValue;

tries to modify it.


I still believe this is a good idea and will catch bugs, just like this 
one.


My rationale is that if you want to modify the 'in' parameter either:
  - it should be an 'inout' instead of an 'in'
  - you only want to do so for the scope of the function in which case code 
like...

void function(int a) {
   int b = a;
}

will suffice to make a copy (something that in already does) which you can 
modify.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 29 2004