www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - can i have such problem in D and is D usefull in embedded development?

reply dennis luehring <dl.soluz gmx.net> writes:
(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)
Jun 29 2004
next sibling parent reply Sean Kelly <sean f4.ca> writes:
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
Jun 29 2004
parent reply dennis luehring <dl.soluz gmx.net> writes:
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)
Jun 29 2004
next sibling parent dennis luehring <dl.soluz gmx.net> writes:
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
Jun 29 2004
prev sibling parent reply s <s_member pathlink.com> writes:
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
Jun 29 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
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/
Jun 29 2004
parent reply Sean Kelly <sean f4.ca> writes:
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
Jun 29 2004
parent reply Regan Heath <regan netwin.co.nz> writes:
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/
Jun 29 2004
parent reply dennis luehring <dl.soluz gmx.net> writes:
 which then only makes 1 copy, the one explicitly shown above.


ok away from this - do we need a copy, is it right to use a copy, should 
everyone must use a copy stuff talk... (its between semtanic and 
best-use-case or something i think)

a question about an language currently in the design phase:
is it ok for D (like for many other lanugages) to help programmers 
getting in trouble with such a little piece of code... (how can i 
prevent me from searching for such bugs in code that was written by 
unexperienced people years ago... - always use x bugpattern find 
tools??? it can't be)

from Sean:
"it's not the job of a programming language to protect the programmer 
from himself..."

but

"it could be the job of an (new) programming language to protect the 
programmer from other programmers (or stupid bugs they made) and make it 
more easy to find the 'bugs'"

(btw: where can i download the "programming language jobs reference")

can't the D compiler get an option like:
--force-in-arguments-as-constant
or something

and this const& thing was only an example: there are much more of such 
bugpatterns out there...

designbycontract/unittest stuff is integrated in D - what speaks agains 
the above...

ciao dennis
Jun 30 2004
parent Regan Heath <regan netwin.co.nz> writes:
On Wed, 30 Jun 2004 10:26:21 +0200, dennis luehring <dl.soluz gmx.net> 
wrote:


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


 ok away from this - do we need a copy, is it right to use a copy, should 
 everyone must use a copy stuff talk... (its between semtanic and 
 best-use-case or something i think)


Well.. C/C++ passes copies, that is why people pass pointers, this leaves 
you de-referencing a pointer in the function, which is why pass by 
reference was invented.

Obviously my view is that 'in' the default parameter passing method should 
not be a copy..however often it is more efficient to pass a copy.. given 
that the variable will not be modified the compiler *can* optimise by 
copying if it wants.


 a question about an language currently in the design phase:
 is it ok for D (like for many other lanugages) to help programmers 
 getting in trouble with such a little piece of code... (how can i 
 prevent me from searching for such bugs in code that was written by 
 unexperienced people years ago... - always use x bugpattern find 
 tools??? it can't be)


I believe my idea for changes to 'in' will solve this bug, and perhaps 
others.

Walters view of C/C++'s const is that is does not solve any bugs, I 
believe my idea is different enough to C/C++'s const that it does solve 
bugs, and at no real cost to the programmer.


 from Sean:
 "it's not the job of a programming language to protect the programmer 
 from himself..."

 but

 "it could be the job of an (new) programming language to protect the 
 programmer from other programmers (or stupid bugs they made) and make it 
 more easy to find the 'bugs'"

 (btw: where can i download the "programming language jobs reference")

 can't the D compiler get an option like:
 --force-in-arguments-as-constant
 or something


IMO this is a seperate stage to compiling. You want a compiler to compile 
the instructions and make a program. Next stage is, double checking you're 
not doing something silly, a lint-like program is what you use for this 
stage.

Walter has mentioned that a lint-like program could be written using the 
DMD front end.

I think seperating these tasks is the way to go.

This creates consistency in the compiler and all implementations of the 
compiler.


 and this const& thing was only an example: there are much more of such 
 bugpatterns out there...


Indeed. Some are very hard to identify as such, some are valid in certain 
cases and it is hard for a program to identify these cases without the 
sort of context a human brain can use to make the decision.


 designbycontract/unittest stuff is integrated in D - what speaks agains 
 the above...


It goes a long way to helping the programmer catch thier own mistakes. I 
like it.

Regan.

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Jun 30 2004
prev sibling next sibling parent reply "Walter" <newshound digitalmars.com> writes:
"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.
Jun 29 2004
parent dennis luehring <dl.soluz gmx.net> writes:
Walter wrote:


 "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.


maybe in the next project


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.


thx (i've read Dan Williams "Various D language matters" post...)
Jun 30 2004
prev sibling next sibling parent Regan Heath <regan netwin.co.nz> writes:
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/
Jun 29 2004
prev sibling parent "me" <memsom interalpha.co.uk> writes:
 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?)


Nope, not Pascal. Pascal has:

procedure x(const int: integer); //constant
procedure y(int: integer); //by value
procedure z(var int: integer); //by ref

At least, the Borland dialect does...

infact, the Borland dialect has 'in' and 'out' now too, iirc, through COM.

Matt
Jun 30 2004