www.digitalmars.com         C & C++   DMDScript  

D - foreach inout bug?

reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
        this(size_type dim, value_type value)
        {
            m_elements = new value_type[dim];

            foreach(value_type element; m_elements)
            {
                element = value; //
            }
        }


The assignment within the foreach loop has no effect, because inout is not
specified. I can see the counter arguments, but this is something the
compiler should warn about.
Jan 05 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Matthew wrote:


        this(size_type dim, value_type value)
        {
            m_elements = new value_type[dim];

            foreach(value_type element; m_elements)
            {
                element = value; //
            }
        }


The assignment within the foreach loop has no effect, because inout is not
specified. I can see the counter arguments, but this is something the
compiler should warn about.

  


An error should also probably also occur for:

+=
-=
~=
ect...

but then if element was an object, then an overloaded assignment 
operator would activate.

But your right this is a trap, that I've fallen into myself. Any 
particular reason why it's not inout by default?

PS - As we all know, be careful about using the word *warning* around 
big W ;)
Jan 05 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
 Matthew wrote:


        this(size_type dim, value_type value)
        {
            m_elements = new value_type[dim];

            foreach(value_type element; m_elements)
            {
                element = value; //
            }
        }


The assignment within the foreach loop has no effect, because inout is




not

specified. I can see the counter arguments, but this is something the
compiler should warn about.


 An error should also probably also occur for:

 +=
 -=
 ~=
 ect...

 but then if element was an object, then an overloaded assignment
 operator would activate.

 But your right this is a trap, that I've fallen into myself. Any
 particular reason why it's not inout by default?

 PS - As we all know, be careful about using the word *warning* around
 big W ;)


It can't be an error because, as you say, it could be in a template, and
using operations that are valid for an in parameter.

I know we've don't like warnings, but leaving it to a DLint program is not
the answer. Look how successful that was for C, eh?

I don't know what the answer is, other than not allowing an implicit in.
Jan 05 2004
parent reply davepermen <davepermen_member pathlink.com> writes:
it can't be an error because in the same way this would have to be an error
then, too:

void func(int value) {
value = 10;
}

this is doable, and usable. it is a copy of the value passed in. in the same
way, you get a copy of the object you iterate trough. wich is useful to be
manipulateable..

In article <btdg9l$23pm$1 digitaldaemon.com>, Matthew says...

 Matthew wrote:


        this(size_type dim, value_type value)
        {
            m_elements = new value_type[dim];

            foreach(value_type element; m_elements)
            {
                element = value; //
            }
        }


The assignment within the foreach loop has no effect, because inout is




not

specified. I can see the counter arguments, but this is something the
compiler should warn about.


 An error should also probably also occur for:

 +=
 -=
 ~=
 ect...

 but then if element was an object, then an overloaded assignment
 operator would activate.

 But your right this is a trap, that I've fallen into myself. Any
 particular reason why it's not inout by default?

 PS - As we all know, be careful about using the word *warning* around
 big W ;)


It can't be an error because, as you say, it could be in a template, and
using operations that are valid for an in parameter.

I know we've don't like warnings, but leaving it to a DLint program is not
the answer. Look how successful that was for C, eh?

I don't know what the answer is, other than not allowing an implicit in.
Jan 06 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
That wouldn't trouble me in the slightest.

I don't mean to be insulting to its fans, but I think the desire for such
"conveniences" is juvenile. I'd be perfectly happy to type in for every in
parameter.

"davepermen" <davepermen_member pathlink.com> wrote in message
news:bte0tu$2u5c$1 digitaldaemon.com...

 it can't be an error because in the same way this would have to be an


error

 then, too:

 void func(int value) {
 value = 10;
 }

 this is doable, and usable. it is a copy of the value passed in. in the


same

 way, you get a copy of the object you iterate trough. wich is useful to be
 manipulateable..

 In article <btdg9l$23pm$1 digitaldaemon.com>, Matthew says...

 Matthew wrote:


        this(size_type dim, value_type value)
        {
            m_elements = new value_type[dim];

            foreach(value_type element; m_elements)
            {
                element = value; //
            }
        }


The assignment within the foreach loop has no effect, because inout is




not

specified. I can see the counter arguments, but this is something the
compiler should warn about.


 An error should also probably also occur for:

 +=
 -=
 ~=
 ect...

 but then if element was an object, then an overloaded assignment
 operator would activate.

 But your right this is a trap, that I've fallen into myself. Any
 particular reason why it's not inout by default?

 PS - As we all know, be careful about using the word *warning* around
 big W ;)


It can't be an error because, as you say, it could be in a template, and
using operations that are valid for an in parameter.

I know we've don't like warnings, but leaving it to a DLint program is




not

the answer. Look how successful that was for C, eh?

I don't know what the answer is, other than not allowing an implicit in.
Jan 06 2004
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
davepermen wrote:


it can't be an error because in the same way this would have to be an error
then, too:

void func(int value) {
value = 10;
}

this is doable, and usable. it is a copy of the value passed in. in the same
way, you get a copy of the object you iterate trough. wich is useful to be
manipulateable..
  


If you did:

void func(int value) 
{
   value = 10;
   x = value;
}

That is, you use the value, then it shouldn't be considered an error.  But if
you have:

void func(int value) 
{
value = 10;
}

Then your doing nothing with value.  It would be optimised away.

Anyway Matthew was suggesting a warning not error.



In article <btdg9l$23pm$1 digitaldaemon.com>, Matthew says...
  


Matthew wrote:

      


       this(size_type dim, value_type value)
       {
           m_elements = new value_type[dim];

           foreach(value_type element; m_elements)
           {
               element = value; //
           }
       }


The assignment within the foreach loop has no effect, because inout is
        




not
    


specified. I can see the counter arguments, but this is something the
compiler should warn about.



        


An error should also probably also occur for:

+=
-=
~=
ect...

but then if element was an object, then an overloaded assignment
operator would activate.

But your right this is a trap, that I've fallen into myself. Any
particular reason why it's not inout by default?

PS - As we all know, be careful about using the word *warning* around
big W ;)
      


It can't be an error because, as you say, it could be in a template, and
using operations that are valid for an in parameter.

I know we've don't like warnings, but leaving it to a DLint program is not
the answer. Look how successful that was for C, eh?

I don't know what the answer is, other than not allowing an implicit in.
Jan 06 2004
parent reply davepermen <davepermen_member pathlink.com> writes:
then the compiler should spit out an "You're doing useless stuff, stoopid"
error?

dunno.. i think he could spit that error out much more often:D

In article <bte1oj$2vfb$1 digitaldaemon.com>, J Anderson says...

davepermen wrote:


it can't be an error because in the same way this would have to be an error
then, too:

void func(int value) {
value = 10;
}

this is doable, and usable. it is a copy of the value passed in. in the same
way, you get a copy of the object you iterate trough. wich is useful to be
manipulateable..
  


If you did:

void func(int value) 
{
   value = 10;
   x = value;
}

That is, you use the value, then it shouldn't be considered an error.  But if
you have:

void func(int value) 
{
value = 10;
}

Then your doing nothing with value.  It would be optimised away.

Anyway Matthew was suggesting a warning not error.



In article <btdg9l$23pm$1 digitaldaemon.com>, Matthew says...
  


Matthew wrote:

      


       this(size_type dim, value_type value)
       {
           m_elements = new value_type[dim];

           foreach(value_type element; m_elements)
           {
               element = value; //
           }
       }


The assignment within the foreach loop has no effect, because inout is
        




not
    


specified. I can see the counter arguments, but this is something the
compiler should warn about.



        


An error should also probably also occur for:

+=
-=
~=
ect...

but then if element was an object, then an overloaded assignment
operator would activate.

But your right this is a trap, that I've fallen into myself. Any
particular reason why it's not inout by default?

PS - As we all know, be careful about using the word *warning* around
big W ;)
      


It can't be an error because, as you say, it could be in a template, and
using operations that are valid for an in parameter.

I know we've don't like warnings, but leaving it to a DLint program is not
the answer. Look how successful that was for C, eh?

I don't know what the answer is, other than not allowing an implicit in.
Jan 06 2004
parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
davepermen wrote:


then the compiler should spit out an "You're doing useless stuff, stoopid"
error?

dunno.. i think he could spit that error out much more often:D

  


[Snip]

I would like it to cause an error when parameters aren't used. But that 
goes against the minimum obstructions to beginners principle, Walter has 
talked about before.
Jan 06 2004
next sibling parent reply davepermen <davepermen_member pathlink.com> writes:
the problem is, its not something WRONG. its just something USELESS.

if the compiler should be able to detect usefulnes of code, it would have to be
able to understand what you really want to program. in the end, it should then
say "you want to code yet another first person shooter? thats useless.. error in
compilation"

you get the idea..

for simple things, yes, we could get errors. but what if its more complex "dead
code" ? does it still has to be able to report the "bug"?

errors only for code that is not understandable by the compiler or the running
system, a.k.a. wrong. useless code can (but doesn't have to) get optimized away.
but thats all about it.

In article <bteari$b7g$1 digitaldaemon.com>, J Anderson says...

davepermen wrote:


then the compiler should spit out an "You're doing useless stuff, stoopid"
error?

dunno.. i think he could spit that error out much more often:D

  


[Snip]

I would like it to cause an error when parameters aren't used. But that 
goes against the minimum obstructions to beginners principle, Walter has 
talked about before.
Jan 06 2004
next sibling parent J Anderson <REMOVEanderson badmama.com.au> writes:
davepermen wrote:


the problem is, its not something WRONG. its just something USELESS.

if the compiler should be able to detect usefulnes of code, it would have to be
able to understand what you really want to program. in the end, it should then
say "you want to code yet another first person shooter? thats useless.. error in
compilation"

you get the idea..

for simple things, yes, we could get errors. but what if its more complex "dead
code" ? does it still has to be able to report the "bug"?
  


The simple case is fine.  I'd be even better if the IDE could do it and 
underline them like grammar errors in word. But somehow I think that'll 
never happen.   Having said that, things like type checking could 
potentially be warnings in D, so who is to say what the difference is.  
Finding dead code in the simplest (particular) cases shouldn't be to 
hard to replicate in other D compiler, and will lead to less semantic 
bugs in code. And as we all know semantic bugs are the hardest to find.


errors only for code that is not understandable by the compiler or the running
system, a.k.a. wrong. useless code can (but doesn't have to) get optimized away.
but thats all about it.
Jan 07 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"davepermen" <davepermen_member pathlink.com> wrote in message
news:btejfa$oej$1 digitaldaemon.com...

 the problem is, its not something WRONG. its just something USELESS.

 if the compiler should be able to detect usefulnes of code, it would have


to be

 able to understand what you really want to program. in the end, it should


then

 say "you want to code yet another first person shooter? thats useless..


error in

 compilation"

 you get the idea..

 for simple things, yes, we could get errors. but what if its more complex


"dead

 code" ? does it still has to be able to report the "bug"?

 errors only for code that is not understandable by the compiler or the


running

 system, a.k.a. wrong. useless code can (but doesn't have to) get optimized


away.

 but thats all about it.


The optimizer is pretty good about using global data flow analysis to detect
dead code. However, it never complains about dead code. Why? Because dead
code happens a lot as a side effect of common programming styles, and
programmers expect it to just be optimized away. (For example, template
code.) Complaining about dead code will be more of a nuisance than an aid.
Jan 17 2004
next sibling parent "Ben Hinkle" <bhinkle4 juno.com> writes:
"Walter" <walter digitalmars.com> wrote in message
news:bucth5$19co$2 digitaldaemon.com...

 "davepermen" <davepermen_member pathlink.com> wrote in message
 news:btejfa$oej$1 digitaldaemon.com...

 the problem is, its not something WRONG. its just something USELESS.

 if the compiler should be able to detect usefulnes of code, it would




have

 to be

 able to understand what you really want to program. in the end, it




should

 then

 say "you want to code yet another first person shooter? thats useless..


 error in

 compilation"

 you get the idea..

 for simple things, yes, we could get errors. but what if its more




complex

 "dead

 code" ? does it still has to be able to report the "bug"?

 errors only for code that is not understandable by the compiler or the


 running

 system, a.k.a. wrong. useless code can (but doesn't have to) get




optimized

 away.

 but thats all about it.


 The optimizer is pretty good about using global data flow analysis to


detect

 dead code. However, it never complains about dead code. Why? Because dead
 code happens a lot as a side effect of common programming styles, and
 programmers expect it to just be optimized away. (For example, template
 code.) Complaining about dead code will be more of a nuisance than an aid.


I agree. Java drives me nuts when it throws a compile-time error due to
unreachable code. I've never gotten that error on code I'm not deliberately
cutting out during debugging.
Jan 17 2004
prev sibling parent reply J Anderson <REMOVEanderson badmama.com.au> writes:
Walter wrote:


The optimizer is pretty good about using global data flow analysis to detect
dead code. However, it never complains about dead code. Why? Because dead
code happens a lot as a side effect of common programming styles, and
programmers expect it to just be optimized away. (For example, template
code.) Complaining about dead code will be more of a nuisance than an aid.

  


I understand this, but:
I think there is some cases where it is obvious that the code is not 
what the programmer meant, which just happens to be dead code:
ie
bool x;
x != x;

These should be reported as errors by the compiler because they save the 
programmer from themselves.
Jan 18 2004
parent reply "Walter" <walter digitalmars.com> writes:
"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:buecc3$hvf$1 digitaldaemon.com...

 Walter wrote:


The optimizer is pretty good about using global data flow analysis to




detect

dead code. However, it never complains about dead code. Why? Because dead
code happens a lot as a side effect of common programming styles, and
programmers expect it to just be optimized away. (For example, template
code.) Complaining about dead code will be more of a nuisance than an




aid.

 I understand this, but:
 I think there is some cases where it is obvious that the code is not
 what the programmer meant, which just happens to be dead code:
 ie
 bool x;
 x != x;

 These should be reported as errors by the compiler because they save the
 programmer from themselves.


Every time I think that, it turns up somewhere in a legitimate manner <g>.
Jan 18 2004
parent reply "Sean L. Palmer" <palmer.sean verizon.net> writes:
"Walter" <walter digitalmars.com> wrote in message
news:buemi3$130s$1 digitaldaemon.com...

 "J Anderson" <REMOVEanderson badmama.com.au> wrote in message
 news:buecc3$hvf$1 digitaldaemon.com...

 Walter wrote:


The optimizer is pretty good about using global data flow analysis to




 detect

dead code. However, it never complains about dead code. Why? Because






dead

code happens a lot as a side effect of common programming styles, and
programmers expect it to just be optimized away. (For example, template
code.) Complaining about dead code will be more of a nuisance than an




 aid.

 I understand this, but:
 I think there is some cases where it is obvious that the code is not
 what the programmer meant, which just happens to be dead code:
 ie
 bool x;
 x != x;

 These should be reported as errors by the compiler because they save the
 programmer from themselves.


 Every time I think that, it turns up somewhere in a legitimate manner <g>.


Yeah, like what if someone overrode operator != to do some logging of every
comparison?  Their log would be too short.

Sean
Jan 20 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
Sean L. Palmer wrote:


"Walter" <walter digitalmars.com> wrote in message
news:buemi3$130s$1 digitaldaemon.com...
  


"J Anderson" <REMOVEanderson badmama.com.au> wrote in message
news:buecc3$hvf$1 digitaldaemon.com...
    


Walter wrote:

      


The optimizer is pretty good about using global data flow analysis to
        




detect
    


dead code. However, it never complains about dead code. Why? Because
        






dead
  


code happens a lot as a side effect of common programming styles, and
programmers expect it to just be optimized away. (For example, template
code.) Complaining about dead code will be more of a nuisance than an
        




aid.
    


I understand this, but:
I think there is some cases where it is obvious that the code is not
what the programmer meant, which just happens to be dead code:
ie
bool x;
x != x;

These should be reported as errors by the compiler because they save the
programmer from themselves.
      


Every time I think that, it turns up somewhere in a legitimate manner <g>.
    


Yeah, like what if someone overrode operator != to do some logging of every
comparison?  Their log would be too short.

Sean

  


Whoops I meant:

bool x;
x &= x;


Actually I was going to mention that I was talking about privative types 
which don't have this kinda operator overloading.  With classes things 
would be different, although the compiler may be about to detect if an 
overloaded operator is being called.
Jan 21 2004
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
J Anderson wrote:

 I would like it to cause an error when parameters aren't used. But that 
 goes against the minimum obstructions to beginners principle, Walter has 
 talked about before.


Does your average WinMain use all parameters?

Mine does not. And OpenWatcom warns me about it. If i could just turn 
them off one by one, and not as a class!

Now imagine it was an error! I would give up coding then.

-eye
Jan 06 2004
parent reply davepermen <davepermen_member pathlink.com> writes:
int WINAPI WinMain(HINSTANCE,HINSTANCE,LPSTR,int) { return 0; }

like that it should not give any warnings. no uninitialised variables.

at least works that way in visual c++ (and is the rule in c++ that unused
parameters just should not get a name)

In article <btepa8$116p$1 digitaldaemon.com>, Ilya Minkov says...

J Anderson wrote:

 I would like it to cause an error when parameters aren't used. But that 
 goes against the minimum obstructions to beginners principle, Walter has 
 talked about before.


Does your average WinMain use all parameters?

Mine does not. And OpenWatcom warns me about it. If i could just turn 
them off one by one, and not as a class!

Now imagine it was an error! I would give up coding then.

-eye
Jan 06 2004
parent J Anderson <REMOVEanderson badmama.com.au> writes:
davepermen wrote:


int WINAPI WinMain(HINSTANCE,HINSTANCE,LPSTR,int) { return 0; }

like that it should not give any warnings. no uninitialised variables.

at least works that way in visual c++ (and is the rule in c++ that unused
parameters just should not get a name)

  


Exactly!  You specify in the code when you don't want the error to show up.


In article <btepa8$116p$1 digitaldaemon.com>, Ilya Minkov says...
  


J Anderson wrote:
    


I would like it to cause an error when parameters aren't used. But that 
goes against the minimum obstructions to beginners principle, Walter has 
talked about before.
      


Does your average WinMain use all parameters?

Mine does not. And OpenWatcom warns me about it. If i could just turn 
them off one by one, and not as a class!

Now imagine it was an error! I would give up coding then.

-eye
Jan 07 2004