(sorry: i've post the message in the wrong group D.gnu)

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?

---------

and a some embedded-question:

will D ever compileable on 16bit machines?
should/could i use D for device-driver development?
is D fast enough (compared with paradigm-c)?

ciao dennis (form germany)

In article <cbs1tq$21qe$1@digitaldaemon.com>, dennis luehring says...
>
>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?)

Please no.

>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?

IMO it's not the job of a programming language to protect the programmer from himself.  The above function is completely legitimate from a semantic standpoint.  It may be useful for a third-party analyzer to display a warning along the lines of "non-reference argument is assigned but never used," but I don't want to see a language change for something like this.


Sean

Sean Kelly wrote:
> In article <cbs1tq$21qe$1@digitaldaemon.com>, dennis luehring says...
>>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?)
> Please no.
ok, ok = a litte bit hard solution (but i would work for c++)

>>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?
> IMO it's not the job of a programming language to protect the programmer from
> himself.
good point: its not my code, written years ago by an 3-month-c++ knowledge-trainy

> The above function is completely legitimate from a semantic
> standpoint.  
the function is perfect from this standpoint ;-)
but how many times did you use an argument as an work variable for
inner function action?

for example (is this a good stile)?

double get(double value){
  value *= 10.0;
  if(value > 100.0){
    value = 20.0;
  }
  return value;
}
i don't like it to change my argument-values in the function directly (or use it as temp vars)
but i know i shouldn't copie everything again and again :-)

...but wait, mmhhhmm, for objects it is ok ;-{

> It may be useful for a third-party analyzer to display a warning
> along the lines of "non-reference argument is assigned but never used," but I
> don't want to see a language change for something like this.
youre right - third party tool could solve the problem

how many of these little-dontwanted-examples exists?
could D extend by(or interface for) an failure-pattern regonition system or something?

there is something for java i think (maybe this one http://www.qido.net/)

ciao dennis (who loves to see D becomming the number one super compiletime checked language)

bugpatter regonition systems for java
  http://www.qido.net/
  http://findbugs.sourceforge.net/
  http://artho.com/jlint/index.shtml
  http://pmd.sourceforge.net/

@Sean Kelly:
do you think that "such" feature can extend the
-design by contract
-unit test
stuff of D to make it more "stable"

or can D(the design) help such tools(and there devlopers)
its a question - i've got no idea how

ciao dennis

In article <cbs96g$2d5a$1@digitaldaemon.com>, dennis luehring says...
>
>for example (is this a good stile)?

Yes

>double get(double value){
>   value *= 10.0;
>   if(value > 100.0){
>     value = 20.0;
>   }
>   return value;
>}

This saves you the cost of initializing a temporary variable when you don't need one.  People have gone a little bit crazy with const reference parameters in C++.  So much so that Scott Meyers (IIRC) wrote an article a little while ago telling programmers to pass classes by value in cases where they might otherwise initialize a temporary.

>...but wait, mmhhhmm, for objects it is ok ;-{

There's no way around it for objects in D.  And while I'd kind of like to see C++-style const support in D, it would add significant complexity to the language.


Sean

"dennis luehring" <dl.soluz@gmx.net> wrote in message news:cbs1tq$21qe$1@digitaldaemon.com...
> and a some embedded-question:
>
> will D ever compileable on 16bit machines?

No. Sorry.

> should/could i use D for device-driver development?

Yes.

> is D fast enough (compared with paradigm-c)?

It's as fast as C is. As proof, you can write your code in C-style in D, and it'll compile into essentially the same code.

On Tue, 29 Jun 2004 17:30:02 +0200, dennis luehring <dl.soluz@gmx.net> wrote:

> (sorry: i've post the message in the wrong group D.gnu)

And I replied to it :)
my reply below..

> 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?

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.

> ---------
>
> and a some embedded-question:
>
> will D ever compileable on 16bit machines?
> should/could i use D for device-driver development?
> is D fast enough (compared with paradigm-c)?
>
> ciao dennis (form germany)



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

On Tue, 29 Jun 2004 18:48:05 +0000 (UTC), s <s_member@pathlink.com> wrote:

> In article <cbs96g$2d5a$1@digitaldaemon.com>, dennis luehring says...
>>
>> for example (is this a good stile)?
>
> Yes
>
>> double get(double value){
>>   value *= 10.0;
>>   if(value > 100.0){
>>     value = 20.0;
>>   }
>>   return value;
>> }
>
> This saves you the cost of initializing a temporary variable when you don't need
> one.  People have gone a little bit crazy with const reference parameters in
> C++.  So much so that Scott Meyers (IIRC) wrote an article a little while ago
> telling programmers to pass classes by value in cases where they might otherwise
> initialize a temporary.

Err.. but doesn't the function call create a temporary in this case?
It must do, as modifying value does not effect the original variable being passed.

>> ...but wait, mmhhhmm, for objects it is ok ;-{
>
> There's no way around it for objects in D.  And while I'd kind of like to see
> C++-style const support in D, it would add significant complexity to the
> language.
>
>
> Sean
>
>



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

In article <opsadvf6fo5a2sq9@digitalmars.com>, Regan Heath says...
>
>On Tue, 29 Jun 2004 18:48:05 +0000 (UTC), s <s_member@pathlink.com> wrote:
>
>> In article <cbs96g$2d5a$1@digitaldaemon.com>, dennis luehring says...
>>>
>>> for example (is this a good stile)?
>>
>> Yes
>>
>>> double get(double value){
>>>   value *= 10.0;
>>>   if(value > 100.0){
>>>     value = 20.0;
>>>   }
>>>   return value;
>>> }
>>
>> This saves you the cost of initializing a temporary variable when you
>> don't need
>> one.  People have gone a little bit crazy with const reference
>> parameters in
>> C++.  So much so that Scott Meyers (IIRC) wrote an article a little
>> while ago
>> telling programmers to pass classes by value in cases where they might
>> otherwise
>> initialize a temporary.
>
>Err.. but doesn't the function call create a temporary in this case?
>It must do, as modifying value does not effect the original variable being
>passed.

Yes.  But I was comparing the above code to this:

>double get(double value){
>  double temp = value * 10.0;
>  if(temp > 100.0){
>    temp = 20.0;
>  }
>  return temp;
>}


Sean

On Wed, 30 Jun 2004 02:06:49 +0000 (UTC), Sean Kelly <sean@f4.ca> wrote:

> In article <opsadvf6fo5a2sq9@digitalmars.com>, Regan Heath says...
>>
>> On Tue, 29 Jun 2004 18:48:05 +0000 (UTC), s <s_member@pathlink.com> wrote:
>>
>>> In article <cbs96g$2d5a$1@digitaldaemon.com>, dennis luehring says...
>>>>
>>>> for example (is this a good stile)?
>>>
>>> Yes
>>>
>>>> double get(double value){
>>>>   value *= 10.0;
>>>>   if(value > 100.0){
>>>>     value = 20.0;
>>>>   }
>>>>   return value;
>>>> }
>>>
>>> This saves you the cost of initializing a temporary variable when you
>>> don't need
>>> one.  People have gone a little bit crazy with const reference
>>> parameters in
>>> C++.  So much so that Scott Meyers (IIRC) wrote an article a little
>>> while ago
>>> telling programmers to pass classes by value in cases where they might
>>> otherwise
>>> initialize a temporary.
>>
>> Err.. but doesn't the function call create a temporary in this case?
>> It must do, as modifying value does not effect the original variable being
>> passed.
>
> Yes.  But I was comparing the above code to this:
>
>> double get(double value){
>>  double temp = value * 10.0;
>>  if(temp > 100.0){
>>    temp = 20.0;
>>  }
>>  return temp;
>> }

sure, in the first case it makes 1 copy, in the second case it makes 2 copies.

*if* we change 'in' to enforce const behaviour you can eliminate the copy done on calling the function, meaning:

double get(double value){
   value *= 10.0;
   if(value > 100.0){
     value = 20.0;
   }
   return value;
}

would be illegal, and catch the bug the original poster mentioned. leaving you with...

double get(double value){
  double temp = value * 10.0;
  if(temp > 100.0){
    temp = 20.0;
  }
  return temp;
}

which then only makes 1 copy, the one explicitly shown above.

Regan.

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