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


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?

himself.

knowledge-trainy
 The above function is completely legitimate from a semantic
 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.

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?


maybe in the next project
is D fast enough (compared with paradigm-c)?

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