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.

  

+= -= ~= 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


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

+= -= ~= 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


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

+= -= ~= 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

 then, too:

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

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

 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


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

+= -= ~= 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


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
        


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



        

+= -= ~= 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 ;)

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
        


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



        

+= -= ~= 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 ;)

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

  

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

  

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

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

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

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

 compilation"

 you get the idea..

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

 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

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

 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


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


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

 compilation"

 you get the idea..

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


 "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

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


 away.
 but thats all about it.

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

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


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


 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


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



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


 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
        


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



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
        


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.
      


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)

  

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.
      

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