• (cs) in reply to Spearhavoc!
    Spearhavoc!:
    hoodaticus:
    Anonymous Cow-Herd:
    XIU:
    Mister Cheese:
    Some damn Yank:
    The Enterpriser:
    This is actually very useful for when you want to make use of the set value from within the method whilst limiting out of scope use to '5'.

    I have seen very effective use of this pattern in the security industry. The strength of this lies in the way that the get is also secretly a setter too.

    So, let me get this straight. maxRetry is 1 internally, and someone outside can set it to whatever they want, but if they ask they're always told it's 5? What's the point of that? I guess what I'm missing here is what really happens (sorry, I'm a tester not a coder). Is maxRetry always 1, or do you really let it be set to something else? And if so, why do you lie and say it's 5?

    Is it more like maxRetry is set to 1 initially, you can set it to a new value, and when you read it once, it returns the value it's set to and then sets itself to 5?

    The health+safety executive advises people in ivory towers not to ride high horses.

    The code will set the field to 5 AND return 5

    Surely it sets the field to 5 and returns true?

    That's the C++ behavior. But I don't think it would compile in C#.

    Ooh, subtle troll there. :)

    It wasn't a troll.

  • (cs) in reply to The Enterpriser
    The Enterpriser:
    thesameguy:
    The Enterpriser:
    We *could* treat everyone like complete morans and explain the most basic of concepts to everyone... or those morans could just stop commenting on things they know nothing about and could learn the basics in their own time.

    (Thanks to EvanED for clarifying that there are more people who probably shouldn't be here than I had initially thought.)

    Who should be here and why?

    Anyone can be here, but unless you know at least the very basics of programming, you will not find much enjoyment in the codeSODs. I thought that would be common sense.

    Such people should be somewhere else learning 'Hello World' and the like. That way, when they come here, we will not have people trying to educate them on programming101.

    I'll contemplate these words while my software runs one of the largest supply chains in North America.

  • (cs) in reply to hoodaticus
    hoodaticus:
    I'll contemplate these words while my software runs one of the largest supply chains in North America.

    Good. Let us know when you are done, then maybe you can spend 5 minutes reading http://www.dotnetperls.com/return. It teaches about the 'return' statement.

  • (cs) in reply to Omnomnonymous
    Omnomnonymous:
    I strongly doubt anyone would confuse his screen-name with your company, seeing as nobody has ever heard of you- so I don't think you have much of a legal leg to stand on. In fact, your threatening legal action over his completely unrelated screen-name creates a far more negative connotation of your company than anything zunesis said.

    Captcha: Vindico Lawsuits 'en vindico' never got us anywhere.

    Beg to differ - I sympathise completely with the company (whether it's a real posting from them or not).

    We used to do similar things with our school text books when I was about 12 or 13 or so. It was mildly amusing to have been reminded about what naughtly little tykes we were back then, but the joke's a bit tired now.

  • (cs) in reply to The Enterpriser
    The Enterpriser:
    anyman:
    The Enterpriser:
    I think it would have been faster to just link to something like this: http://www.amazon.com/Beginning-Programming-Dummies-Wally-Wang/dp/0764508350

    As far as I could see, there were about 2 people who didn't understand the code and about 10 people posting about how "no-one understands".

    I still maintain that anyone who feels a tutorial is required in order to explain how a property works, is far overestimating the complexity of a property.

    I can tell even just from your wording that nothing worthwhile will come from talking to you. You seem to have no interest in helping people to understand, thus avoiding WTFs, which I though was the point of this site.

    Go away now.

    Sure, so lets take this to the next level. We should get a primary school teacher in here to explain what all these long words mean. Then we should get your older brother in to tell you how to turn on your computer.

    We could treat everyone like complete morans and explain the most basic of concepts to everyone... or those morans could just stop commenting on things they know nothing about and could learn the basics in their own time.

    (Thanks to EvanED for clarifying that there are more people who probably shouldn't be here than I had initially thought.)

    If you bothered to find out how to spell "moron" then maybe you wouldn't be treated like one, shithead.

  • (cs) in reply to passing through *whistle*
    passing through *whistle*:
    Matt Westwood:
    who else hates ipods?:
    <woah, not reposting that>

    Blimey, that's sick enough to be worthy of Viz.

    What's a "Viz"? I'm afraid to search for it.

    A British comic book.

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    If you bothered to find out how to spell "moron" then maybe you wouldn't be treated like one, shithead.

    WHOOOOOOOSH!~

    got one!

    You also failed to note that I am the person treating others like morans. I guess comprehension isn't your strong suit.

  • (cs) in reply to The Enterpriser
    The Enterpriser:
    Matt Westwood:
    If you bothered to find out how to spell "moron" then maybe you wouldn't be treated like one, shithead.

    WHOOOOOOOSH!~

    got one!

    You also failed to note that I am the person treating others like morans. I guess comprehension isn't your strong suit.

    Like I said, "shithead".

  • (cs) in reply to Matt Westwood
    Matt Westwood:
    The Enterpriser:
    Matt Westwood:
    If you bothered to find out how to spell "moron" then maybe you wouldn't be treated like one, shithead.

    WHOOOOOOOSH!~

    got one!

    You also failed to note that I am the person treating others like morans. I guess comprehension isn't your strong suit.

    Like I said, "shithead".

    You add a lot to the thread. Get a brain moran.

  • Mr.'; Drop Database -- (unregistered) in reply to The Enterpriser
    The Enterpriser:
    VGhhdCBpcyBkb3VibGUgZW5jcnlwdGlvbi4=
    I figure we can expect even more base64 in the next couple of weeks, so here's a bookmarklet for decoding it.

    javascript:void(window.open("data:text/plain;base64,"+window.getSelection(),null,"width=500,height=300"))

  • Don L (unregistered)

    I'm amazed that none of you smart guys realised it's Schrödinger's Cat in a computer program: By observing the object, you affect it....

  • (cs) in reply to The Enterpriser
    The Enterpriser:
    thesameguy:
    The Enterpriser:
    We *could* treat everyone like complete morans and explain the most basic of concepts to everyone... or those morans could just stop commenting on things they know nothing about and could learn the basics in their own time.

    (Thanks to EvanED for clarifying that there are more people who probably shouldn't be here than I had initially thought.)

    Who should be here and why?

    Anyone can be here, but unless you know at least the very basics of programming, you will not find much enjoyment in the codeSODs. I thought that would be common sense.

    Such people should be somewhere else learning 'Hello World' and the like. That way, when they come here, we will not have people trying to educate them on programming101.

    It seems to me that the source of many major WTFs is programmers who don't know shit, but think they do know shit; not programmers who don't know shit and are aware of the fact that they need to learn shit before coming here.

    So... apparently the right people read these forums after all.

  • (cs) in reply to Mr.'; Drop Database --
    Mr.'; Drop Database --:
    The Enterpriser:
    VGhhdCBpcyBkb3VibGUgZW5jcnlwdGlvbi4=
    I figure we can expect even more base64 in the next couple of weeks, so here's a bookmarklet for decoding it.

    javascript:void(window.open("data:text/plain;base64,"+window.getSelection(),null,"width=500,height=300"))

    That's actually kind of neat. Good jorb.

  • FMD (unregistered) in reply to zunesis (the one, the only, the well-hung, yada yada yada)
    zunesis (the one:
    trtrwtf:
    zunesis (the one:
    trtrwtf:
    C-Octothorpe:
    Steve The Cynic:
    Sick. Whoever did this should be punished. Severely. With a baseball bat. By zunesis.
    FTFY
    Surely there's room for compromise here? I don't think our sick little friend will object. And zunesis won't mind, either.
    Indeed, I think the answer is pretty obvious - use the baseball bat, just don't simply swing it at him...
    Congratulations. You got the jo...
    ...you abduct him and his family and restrain them. Make him choose whose ass gets the bat (he is not allowed to choose himself), tell him if he refuses, you'll do it to all of them.

    Who would he choose? His wife? His daughter? His son? An interesting scenario to consider, especially for those of us who do have kids.

    Make him choose one at a time, so you end up doing it to all of them anyway.

    (P.S. I'm sorry when I sometimes take the easy way out. Thank you for encouraging me to go the extra mile and think up something more refreshing. I couldn't do it without your support and constructive criticism, trtrwtf. Love, Zunesis(not that way, queer))

    Am I right in interpreting that Zunesis has kids (the use of 'us' rather than 'you')? It probably explains a lot about today's world.

    sigh

  • COuld be wrong.... (unregistered) in reply to hoodaticus
    hoodaticus:
    Sea Sharp:
    XIU:
    Surely it sets the field to 5 and returns true?

    The result of an assignment in C# is as if you had chained the value assignment.

    int a = 3; int b = a = 5;

    b is 5.

    int a = 3; return a = 5;

    5 is returned.

    As I just learned. All I knew is it wasn't a boolean anymore, so I assumed it was void.
    Just to clarify a little, I think it is that "=" is evaluated right to left, rather than anything about chaining. Chaining would (in my mind) imply that in the above example a=b (almost like using pointers in the old days).

    So an expression with multiple '=' is evaluated right to left....

    The point is that '=' assigns the value on the right to the value on the left. This means that it must evaluate the right side first. It isn't a result of the assignment per se'...

    when we say :

    return a = 5;

    we aren't saying "return the result of a = 5, but rather "return a after executing a = 5"

  • facilisis (unregistered) in reply to Frank
    Frank:
    Anonymous Cow-Herd:
    XIU:
    Mister Cheese:
    Some damn Yank:
    The Enterpriser:
    This is actually very useful for when you want to make use of the set value from within the method whilst limiting out of scope use to '5'.

    I have seen very effective use of this pattern in the security industry. The strength of this lies in the way that the get is also secretly a setter too.

    So, let me get this straight. maxRetry is 1 internally, and someone outside can set it to whatever they want, but if they ask they're always told it's 5? What's the point of that? I guess what I'm missing here is what really happens (sorry, I'm a tester not a coder). Is maxRetry always 1, or do you really let it be set to something else? And if so, why do you lie and say it's 5?

    Is it more like maxRetry is set to 1 initially, you can set it to a new value, and when you read it once, it returns the value it's set to and then sets itself to 5?

    The health+safety executive advises people in ivory towers not to ride high horses.

    The code will set the field to 5 AND return 5

    Surely it sets the field to 5 and returns true?

    The TRWTF is that it took the readers of this forum so many tries to get it right. sigh

    A touch ironic that you would quote an incorrect response when you say that...

  • reductio ad ridiculum (unregistered) in reply to Don L
    Don L:
    I'm amazed that none of you smart guys realised it's Schrödinger's Cat in a computer program: By observing the object, you affect it....
    cat < Schrödinger > moran
  • (cs) in reply to The Enterpriser
    The Enterpriser:
    hoodaticus:
    I'll contemplate these words while my software runs one of the largest supply chains in North America.

    Good. Let us know when you are done, then maybe you can spend 5 minutes reading http://www.dotnetperls.com/return. It teaches about the 'return' statement.

    I would, but I'm too busy working on my n-tier, event-driven multithreaded DAL and IQueryProvider implementation. Does that article discuss the return value of the assignment operator, or have all these big words confused you?

  • populus (unregistered) in reply to The Enterpriser
    The Enterpriser:
    anyman:
    The Enterpriser:
    I think it would have been faster to just link to something like this: http://www.amazon.com/Beginning-Programming-Dummies-Wally-Wang/dp/0764508350

    As far as I could see, there were about 2 people who didn't understand the code and about 10 people posting about how "no-one understands".

    I still maintain that anyone who feels a tutorial is required in order to explain how a property works, is far overestimating the complexity of a property.

    I can tell even just from your wording that nothing worthwhile will come from talking to you. You seem to have no interest in helping people to understand, thus avoiding WTFs, which I though was the point of this site.

    Go away now.

    Sure, so lets take this to the next level. We should get a primary school teacher in here to explain what all these long words mean. Then we should get your older brother in to tell you how to turn on your computer.

    We could treat everyone like complete morans and explain the most basic of concepts to everyone... or those morans could just stop commenting on things they know nothing about and could learn the basics in their own time.

    (Thanks to EvanED for clarifying that there are more people who probably shouldn't be here than I had initially thought.)

    U R A tool (and can't spell moron).

    I've never understood what people who think others shouldn't be posting are actually doing reading the comments. If you understand everything perfectly, and aren't wanting to contribute any pearls of wisdom other than to attack anyone who does. Oh, maybe you don't have a life...

    nevermind!

  • qwq38gh;ae (unregistered) in reply to The Enterpriser
    The Enterpriser:
    Matt Westwood:
    The Enterpriser:
    Matt Westwood:
    If you bothered to find out how to spell "moron" then maybe you wouldn't be treated like one, shithead.

    WHOOOOOOOSH!~

    got one!

    You also failed to note that I am the person treating others like morans. I guess comprehension isn't your strong suit.

    Like I said, "shithead".

    You add a lot to the thread. Get a brain moran.

    Pot: Kettle....

    I wonder if I'm about to reach a "I know you are, but what am I"....

  • Jimmy (unregistered) in reply to hoodaticus
    hoodaticus:
    The Enterpriser:
    hoodaticus:
    I'll contemplate these words while my software runs one of the largest supply chains in North America.

    Good. Let us know when you are done, then maybe you can spend 5 minutes reading http://www.dotnetperls.com/return. It teaches about the 'return' statement.

    I would, but I'm too busy working on my n-tier, event-driven multithreaded DAL and IQueryProvider implementation. Does that article discuss the return value of the assignment operator, or have all these big words confused you?
    No. In fact, I'm not sure why he pointed you to the behaviour of 'return'. Surely the behaviour of '=' would be more appropriate (if dotneperls has that).

    Maybe he didn't understand the problem half as well as he thought he did. Sorry that was harsh, he probably did understand the problem half as well as he thought he did.

  • (cs) in reply to COuld be wrong....
    COuld be wrong....:
    Just to clarify a little, I think it is that "=" is evaluated right to left, rather than anything about chaining. Chaining would (in my mind) imply that in the above example a=b (almost like using pointers in the old days).

    So an expression with multiple '=' is evaluated right to left....

    I'm don't agree with you on the implications of calling 'a = b = c' "chaining", but you are definitely right that = binds from the right to the left.

    when we say :

    return a = 5;

    we aren't saying "return the result of a = 5, but rather "return a after executing a = 5"

    I only see a hair of a difference in meanings between those two explanations, and to the extent that the difference is there, that's pretty much exactly as I'd describe it. (My terminology may be a bit biased by C++ and its ability to overload op=, where there can actually be a difference if you're obnoxious about how you code.) I would say that 'a=5' evaluates to 5 with a side effect of setting 'a', which makes the result of 'a=5' the value 5, which then gets returned.

    In fact, it is possible to see that, to the extent I see a difference between the two explanations, it really is accurate to say "return the result of a=5" and "the result of a=5 is the value assigned to a", and not "the result of a=5 is the value of a". (It would also be more accurate to say "return 5 after executing a=5".)

    Take the following C# code:

    class Program
    {
        volatile int a;
    
        int foo() {
            return a=5;
        }
    }

    Method 'foo' disassembles (when compiled with MSVC 2010 in release mode) to the following MSIL:

    .method private hidebysig instance int32 
            foo() cil managed
    {
      .maxstack  3
      .locals init ([0] int32 CS$0$0000)
      IL_0000:  ldarg.0
      IL_0001:  ldc.i4.5
      IL_0002:  dup
      IL_0003:  stloc.0
      IL_0004:  volatile.
      IL_0006:  stfld      int32 modreq([mscorlib]System.Runtime.CompilerServices.IsVolatile) csharp_console_scratch.Program::a
      IL_000b:  ldloc.0
      IL_000c:  ret
    }

    The instruction at IL_0001 is doing the evaluation of the right side of the assignment (we'll come back to that later). The instruction at IL_0002 is duplicating the result of that evaluation -- the topmost instance is going to be returned (after being stored in local 0 and reloaded later), and the second one is going to be assigned to 'a'. IL_0003 stores that result to be returned later, and IL_0006 stores it to 'a'. IL_000b re-loads the result so that it can be returned.

    The thing to note is that even though 'a' is volatile, it does not reload it (there is no ldfld instruction). An assignment really does evaluate to the value that was assigned.

    '=' is like C's ',' operator, except with one additional side effect.

  • COuld be wrong.... (unregistered) in reply to EvanED
    EvanED:
    COuld be wrong....:
    Just to clarify a little, I think it is that "=" is evaluated right to left, rather than anything about chaining. Chaining would (in my mind) imply that in the above example a=b (almost like using pointers in the old days).

    So an expression with multiple '=' is evaluated right to left....

    I'm don't agree with you on the implications of calling 'a = b = c' "chaining", but you are definitely right that = binds from the right to the left.

    when we say :

    return a = 5;

    we aren't saying "return the result of a = 5, but rather "return a after executing a = 5"

    I only see a hair of a difference in meanings between those two explanations, and to the extent that the difference is there, that's pretty much exactly as I'd describe it. (My terminology may be a bit biased by C++ and its ability to overload op=, where there can actually be a difference if you're obnoxious about how you code.) I would say that 'a=5' evaluates to 5 with a side effect of setting 'a', which makes the result of 'a=5' the value 5, which then gets returned.

    In fact, it is possible to see that, to the extent I see a difference between the two explanations, it really is accurate to say "return the result of a=5" and "the result of a=5 is the value assigned to a", and not "the result of a=5 is the value of a". (It would also be more accurate to say "return 5 after executing a=5".)

    Take the following C# code:

    class Program
    {
        volatile int a;
    
        int foo() {
            return a=5;
        }
    }

    Method 'foo' disassembles (when compiled with MSVC 2010 in release mode) to the following MSIL:

    .method private hidebysig instance int32 
            foo() cil managed
    {
      .maxstack  3
      .locals init ([0] int32 CS$0$0000)
      IL_0000:  ldarg.0
      IL_0001:  ldc.i4.5
      IL_0002:  dup
      IL_0003:  stloc.0
      IL_0004:  volatile.
      IL_0006:  stfld      int32 modreq([mscorlib]System.Runtime.CompilerServices.IsVolatile) csharp_console_scratch.Program::a
      IL_000b:  ldloc.0
      IL_000c:  ret
    }

    The instruction at IL_0001 is doing the evaluation of the right side of the assignment (we'll come back to that later). The instruction at IL_0002 is duplicating the result of that evaluation -- the topmost instance is going to be returned (after being stored in local 0 and reloaded later), and the second one is going to be assigned to 'a'. IL_0003 stores that result to be returned later, and IL_0006 stores it to 'a'. IL_000b re-loads the result so that it can be returned.

    The thing to note is that even though 'a' is volatile, it does not reload it (there is no ldfld instruction). An assignment really does evaluate to the value that was assigned.

    '=' is like C's ',' operator, except with one additional side effect.

    Ya, I'm not disagreeing with how it all works under the bonnet, but the point is that 5 isn't really the result returned by '=' (or at least, not conceptually). Rather it is the value that has been given a - and thinking about it in this context is (IMO) more helpful to work out where the result will be.

    Thus, when faced with:

    return a = 5;
    

    it is more helpful to picture it as:

    a=5;
    return a;
    

    than as

    return (a=5);
    

    Although all 3 examples return the same value (and probably in a near identical way), the 2nd example is the one that (again IMO) best describes what is happening.

    The original example is confusing because some other languages (apparently) return something else (a boolean, I guess they mean) (I think it's more likely that some programmers think of it that way rather than it actually happens that way).

    Bit like using parenthesis for every loop/if/case.... Sometimes intentions can get obfuscated when you try to be too succinct.

    [footnote] Some of the surprise was apparently coming from C++ programmers. C++ (tested with a MinGW compiler) behaves the same way (as does C), and although I haven't a java compiler immediately handy I suspect Java would too..... [/footnote]

  • Luiz Felipe (unregistered) in reply to C-Octothorpe
    C-Octothorpe:
    Frank:
    C-Octothorpe:
    Frank:
    C-Octothorpe:
    Frank:
    The TRWTF is that it took the readers of this forum so many tries to get it right. *sigh*
    Many people (of varying technical acumen) trying once each != One person trying many times

    But I'm sure you knew that...

    But they were each building on what someone else had said previously, as indicated by the quotes and replies.

    I'll give you that, but to me it seemed that the people trying initially to solve the WTF weren't all that experienced with C# syntax (judging by all the = vs == confusion)...
    So what gives it away as C# and not possibly C++? I've only worked with C++.
    Well, I don't really have much experience with C++, but IIRC it doesn't natively support get/set properties, especially not in this particular syntax. This is C# syntactic sugar...

    Hey, i love sugar.

  • Luiz Felipe (unregistered) in reply to Frank
    Frank:
    C-Octothorpe:
    Frank:
    C-Octothorpe:
    Frank:
    So what gives it away as C# and not possibly C++? I've only worked with C++.
    Well, I don't really have much experience with C++, but IIRC it doesn't natively support get/set properties, especially not in this particular syntax. This is C# syntactic sugar...
    Are you sure that's what's really happening here? Note maxRetry != MaxRetry. Kinda looks like maxRetry is a property and MaxRetry is a class (obviously the "class" keyword is omitted, but this is a fragment.)
    Um, MaxRetry isn't a class; it clearly shows that it's an integer, same as maxRetry, except that maxRetry is a private field, not a public property. Further to this is the fact that this is a defacto "standard" for writing properties in .Net objects (though I would usually put the private field below the property definition). Not sure where you're going with this, but I'm really not following.
    OK, I see now. This is clearly not C++ because as you note, the MaxRetry property has a getter and a setter. Having two properties with names which differ by capitalization of one letter surely results in less maintainable code. Kinda looks like the coder wanted a private property because that what the textbooks told him was good OOP, but the application actually needed a public property. Please, please tell me this is not standard practice in C#.

    I think that this is a antistandard. You have to put an 'm' before field member, or put an underscore to be in standard. But if your property are simple getter and setter, then you use autoimplemented properties, such as

    public int x { get; set; }

  • CC (unregistered) in reply to COuld be wrong....
    it is more helpful to picture it [return a=5] as:

    a=5;

    return a;

    If may be more useful for you to picture it that way, but it is wrong.

    Part of the definition of the in-fix assignment function in C family of languages is that the return value of that function is the evaluated RHS.

    eg return a>5 is not

    a>5; return a;

    it is evaluate (a>5) and return the answer.

    Similarly return a=5 is evaluate (a=5) [which gives 5], then return the answer.

  • COuld be wrong.... (unregistered) in reply to CC
    CC:
    it is more helpful to picture it [return a=5] as:

    a=5;

    return a;

    If may be more useful for you to picture it that way, but it is wrong.

    Part of the definition of the in-fix assignment function in C family of languages is that the return value of that function is the evaluated RHS.

    eg return a>5 is not

    a>5; return a;

    it is evaluate (a>5) and return the answer.

    Similarly return a=5 is evaluate (a=5) [which gives 5], then return the answer.

    I disagree. '=' does not return a value, it assigns a value. '>' on the other hand, returns a boolean based on the values. This is the exact source of confusion. Some people see

    return a=5; and instinctively think it is a comparison operation, not an assignment operation.

    You may claim that each of the examples I provided are equivalent, and functionally, they probably are - the point I was trying to make was that it is more readable (IMO - admittedly) to assign then return in this context.

    Assuming you are correct that assignment is defined to return the RHS (I've not found anything to confirm that - although having not looked very hard, I've not found anything against that, either) still doesn't make my suggestion wrong.
    Sure, it means that you can return and assign in one statement - this I have agreed with, in each post - my point was (meant to be) that it is not the clearest way to do it.

  • NZgeek (unregistered) in reply to CC
    CC:
    it is more helpful to picture it [return a=5] as:

    a=5;

    return a;

    If may be more useful for you to picture it that way, but it is wrong.

    Part of the definition of the in-fix assignment function in C family of languages is that the return value of that function is the evaluated RHS.

    eg return a>5 is not

    a>5; return a;

    it is evaluate (a>5) and return the answer.

    Similarly return a=5 is evaluate (a=5) [which gives 5], then return the answer.

    You should probably think of it more like this:

    tmp = (a>5); return tmp;

    This still works for the original case:

    tmp = (a=5); return tmp;

    In either case, you can treat is as if the operation is performed, the result assigned to a temporary variable, and that temporary is returned.

    Each programming language has its own definition of what the 'return value' of an assignment operation is (i.e. what it is that's getting assigned into tmp in the example above).

    • In C, the 'return value' is the value of the variable to the left of the assignment operator (the l-value).

    • In C++, primitive types (int, long, double, etc) act as they do in C. For struct/class assignments, it's up to the implementation of operator=. The default auto-generated operator= usually returns a reference to the l-value.

    • In C# it's the value to the right of the assignment operator. This is spelled out in the MSDN documentation for C#'s = operator, and EvanED's example shows this in action.

  • (cs) in reply to COuld be wrong....
    COuld be wrong....:
    The original example is confusing because some other languages (apparently) return something else (a boolean, I guess they mean) (I think it's more likely that some programmers think of it that way rather than it actually happens that way).
    It is. :-) Every language I know of where 'a = 5' is an expression has that expression evaluate to the value assigned. (There are some languages, like Python, where that is not an expression, and assignment is instead a formal statement.)
    COuld be wrong....:
    I disagree. '=' does not return a value, it assigns a value. '>' on the other hand, returns a boolean based on the values.
    It does both.

    Think of it like a function call. On one hand, function calls are sort of "special" expressions too -- you can make them do all sorts of stuff. They can do file I/O, they can write to global variables, make network requests, etc. In that respect, function calls are like '=', because they (can) have side effects. But they can also return a value, and you can use that value later.

    If I say

        x = 1 + foo()
    , I'd bet you don't conceptually think of that as me saying

        temp = foo()
        x = 1 + temp
    You may claim that each of the examples I provided are equivalent, and functionally, they probably are - the point I was trying to make was that it is more readable (IMO - admittedly) to assign then return in this context.
    Oh, on that you're right. Assignment-in-a-larger-expression (i.e. more than just 'x = 5;' or perhaps 'a = b = c = 5;') is something that I think should be pretty largely eschewed.

    I feel pretty similarly about i++ and ++i; I almost never like having those as part of a large expression. (The fact that some people think that while(*p++ = *q++); is something actually reasonable to write drives me batty.)

    The one place where I'll sometimes use it is if the alternative is a loop with a break. I will sometimes write something like

        while((c = getch()) != EOF)
            frob(c);

    in preference to

        while(true) {
            c = getch();
            if (c == EOF)
                break;
            frob(c);
        }

    That use is reasonably idiomatic and I don't feel too bad about it, though I certainly don't insist that it's better.

    But, the point stands: 'a=5' does evaluate to a value (5), even if it's not immediately obvious. And covering your ears and going LA-LA-LA-LA-I-CAN'T-HEAR-YOU at your programming language is rarely a good technique, even if it's trying to tell you that it's doing something obnoxious. :-)

    Assuming you are correct that assignment is defined to return the RHS (I've not found anything to confirm that - although having not looked very hard, I've not found anything against that, either) still doesn't make my suggestion wrong.
    I'm what some people may call a "language lawyer", so I'll stick true to my form:

    "There are several assignment operators, all of which group right-to-left. ... The result of the assignment operation is the value stored in the left operand after the assignment has taken place; the result is an lvalue." (C++03 standard, 5.17 para 3.)

  • DodgyBob (unregistered) in reply to ted
    ted:
    Zylon:
    Hooah:
    This is a common thing to do on an embedded machine with no filesystem.
    I can tell from your pixels that you're pretty stupid, so I guess I need to inform you that the thing you just posted, even when posted ironically, has been beyond lame for months. It's not even "Ha ha he posted something deliberately unfunny" funny anymore.

    MaxRetry:

    In case you can't tell, this is a grown up place. The fact that you continue to insist on being a faggoty square clearly shows that you're too out of touch and too stupid to appreciate good humor.

    Go away and grow up.

    Sincerely, Go get fucked.

    "grown-up place" followed by "faggoty square" ... "out of touch" ... "stupid" ... "go get fucked".

    Congratulations on winning today's dissonance award.

  • DodgyBob (unregistered) in reply to Matt Westwood
    Matt Westwood:
    passing through *whistle*:
    Matt Westwood:
    who else hates ipods?:
    <woah, not reposting that>

    Blimey, that's sick enough to be worthy of Viz.

    What's a "Viz"? I'm afraid to search for it.

    A British comic book.

    Aahh. Memories of "Buster Gonad and his unfeasibly large testicles" :-)

  • CC (unregistered) in reply to EvanED
    EvanED:
    I'm what some people may call a "language lawyer", so I'll stick true to my form:

    "There are several assignment operators, all of which group right-to-left. ... The result of the assignment operation is the value stored in the left operand after the assignment has taken place; the result is an lvalue." (C++03 standard, 5.17 para 3.)

    I apologise for being wrong saying that the result is from the right side in my initial post. In my defense, I don't make my living as a coder, I'm just a dabbler.

  • mike5 (unregistered)

    Wow. It's a sort of a Schrodinger's property. Until you look at it, the value can be anything. But the moment you look, it's 5...

  • Markus (unregistered) in reply to VictorSierraGolf

    Yes - but that's only for large values of 2...

  • c (unregistered) in reply to CC
    CC:
    it is more helpful to picture it [return a=5] as:

    a=5;

    return a;

    If may be more useful for you to picture it that way, but it is wrong.

    Part of the definition of the in-fix assignment function in C family of languages is that the return value of that function is the evaluated RHS.

    Wrong! (a = 5) = 3; // Assigns 3 to a

    Also, everyone on this thread except those who got it right are stupid.

  • c (unregistered) in reply to zunesis (the one, the only, the well-hung, yada yada yada)
    zunesis (the one:
    ...you abduct him and his family and restrain them. Make him choose whose ass gets the bat (he is not allowed to choose himself), tell him if he refuses, you'll do it to all of them.

    Who would he choose? His wife? His daughter? His son? An interesting scenario to consider, especially for those of us who do have kids.

    That's easy. For non-teenage kids, do the wife. She takes it in Huranus anyway. I know mine does.

  • QJo (unregistered) in reply to The Enterpriser
    The Enterpriser:
    someone:
    The Enterpriser:
    Matthew:
    someguy:
    In order to prempt any more unnecessary arguing about what this code does:

    Thank you for posting this. It's pretty much the only comment worth reading. It's proof of what the function does, even though everyone is still arguing about it.

    <goes on to misunderstand the code anyway>

    The fact that you or anyone else thinks that we need coded example to explain what a property is in C# shows that you probably don't understand this very well yourself.

    I don't appreciate this. My decision to post the code was inspired by other people demonstrating their lack of understanding and I didn't want the discussion to run any longer over something so simple - they often do and, this time even, still did, showing that it could be helpful.

    I think it would have been faster to just link to something like this: http://www.amazon.com/Beginning-Programming-Dummies-Wally-Wang/dp/0764508350

    As far as I could see, there were about 2 people who didn't understand the code and about 10 people posting about how "no-one understands".

    I still maintain that anyone who feels a tutorial is required in order to explain how a property works, is far overestimating the complexity of a property.

    Not everybody who visits this forum is completely au fait with the syntax of every programming language, whether it be C# or not. To suggest that, because they express confusion and uncertainty about a seriously non-standard usage of such a language, they are by definition idiots, indicates a level of intellectual arrogance and provincialism more usually seen in fundamentalist religious communities.

    IMO it was perfectly appropriate for someguy to demonstrate what it does rather than what everyone else was doing, arguing about what they think it ought to have been doing, and thereby cut through all the confusion.

    I can quite understand why your attitude appears to have caused anger amongst some of the respondents. As for me, if you had spoken to me like that in a meeting, for example, you would be clearing your desk and returning your door pass as I type.

  • snow (unregistered) in reply to c

    If you're going to call people stupid, at least get your own statement right.

    (a = 5) = 3;
    does NOT assign 3 to a. (a = 5) is not a variable, and the left hand side of an assignment has to be a variable. This won't even compile, never mind assign anything.

    Straight from the C# help:

    The assignment operator (=) stores the value of its right-hand operand in the storage location, property, or indexer denoted by its left-hand operand and returns the value as its result.

    So the right hand side of the = is being both set into the left, and returned as a value. So the most accurate way to picture it is that

    return a=5;
    is about the same as
    a = 5;
    return 5;

    It isn't a that is being returned, it is the value of the assignment.

  • eVil (unregistered) in reply to The Enterpriser

    You are clearly the moron here. For one thing, you've managed to spell it incorrectly 4 times at least, and twice after it was already pointed out that you were doing it wrong.

    The fact that you now know that you are incorrect, but are choosing to continue to spell it wrong demonstrates exactly what kind of loser you are - one who, instead of graciously conceding a point will argue ad absurdam.

    Why not take on board the fact that this site is about both fun and learning. The idea is that people who may not be quite as experienced as others can learn from the funny mistakes that have been made.

    If you think that people who can't code C# as well as you shouldn't be here, well you're just plain wrong. There are many people here who are simply new to the industry, and many who code in other languages. In order to join in, and learn, people make comments, sometimes demonstrating that they don't know quite as much as you do.

    In this case you have 3 options:

    1. Help them out by explaining.
    2. Post nothing.
    3. Be a dick.

    Why is it that you always choose 3?

  • c (unregistered) in reply to snow
    snow:
    If you're going to call people stupid, at least get your own statement right.
    (a = 5) = 3;
    does NOT assign 3 to a. (a = 5) is not a variable, and the left hand side of an assignment has to be a variable.
    The post I was replying to was talking about the "C family of languages". My statement compiles in every member of that family which fully supports the concept of a reference, such as C++ and D.
  • London contractor (unregistered) in reply to The Enterpriser
    The Enterpriser:
    Some damn Yank:
    The Enterpriser:
    This is actually very useful for when you want to make use of the set value from within the method whilst limiting out of scope use to '5'.

    I have seen very effective use of this pattern in the security industry. The strength of this lies in the way that the get is also secretly a setter too.

    So, let me get this straight. maxRetry is 1 internally, and someone outside can set it to whatever they want, but if they ask they're always told it's 5? What's the point of that? I guess what I'm missing here is what really happens (sorry, I'm a tester not a coder). Is maxRetry always 1, or do you really let it be set to something else? And if so, why do you lie and say it's 5?

    It isn't a lie. It is set to 5 each time it is read. This prevents outside use from having visibility of internal use.

    e.g. if I want to use this from within the method I could set via the property and then retrieve through the private member:

     
    //increase performance through larger maximum number of retries
    lock(this) { //make it thread safe
    MaxRetry = 20;
    performAction(yhbt,maxRetry); //whatever it is
    }
    

    This way no outside code is going to ever interfere with your retries, and they cannot abuse the property to steal importante cpu cycles

    Hahaha!!! LOCK (this) //make it thread safe...

    Oh dear! Someone needs to brush up on their thread safety, don't they???

  • QJo (unregistered) in reply to London contractor
    London contractor:
    The Enterpriser:
    Some damn Yank:
    The Enterpriser:
    This is actually very useful for when you want to make use of the set value from within the method whilst limiting out of scope use to '5'.

    I have seen very effective use of this pattern in the security industry. The strength of this lies in the way that the get is also secretly a setter too.

    So, let me get this straight. maxRetry is 1 internally, and someone outside can set it to whatever they want, but if they ask they're always told it's 5? What's the point of that? I guess what I'm missing here is what really happens (sorry, I'm a tester not a coder). Is maxRetry always 1, or do you really let it be set to something else? And if so, why do you lie and say it's 5?

    It isn't a lie. It is set to 5 each time it is read. This prevents outside use from having visibility of internal use.

    e.g. if I want to use this from within the method I could set via the property and then retrieve through the private member:

     
    //increase performance through larger maximum number of retries
    lock(this) { //make it thread safe
    MaxRetry = 20;
    performAction(yhbt,maxRetry); //whatever it is
    }
    

    This way no outside code is going to ever interfere with your retries, and they cannot abuse the property to steal importante cpu cycles

    Hahaha!!! LOCK (this) //make it thread safe...

    Oh dear! Someone needs to brush up on their thread safety, don't they???

    Um, I think it was a joke. Hint: the "yhbt" parameter name in the performAction method.

    If you need to be informed as to what "yhbt" means, then you might want to type it into a search engine. An example that many people use is Google, which can be found at www dot google dot co dot uk (I assume you're British, from your username).

  • dr memals (unregistered)

    so many of these comments can be replied with "whoosh" or "Whoooooooosh !"

  • Frank (unregistered) in reply to COuld be wrong....
    COuld be wrong....:
    '=' does not return a value, it assigns a value. '>' on the other hand, returns a boolean based on the values. This is the exact source of confusion. Some people see return a=5; and instinctively think it is a comparison operation, not an assignment operation.
    It's more like people see a=5 and think that a==5 was intended. But once you look again and see that an int is returned, not a boolean, then you realize that the original is the intent (as WTF as it may be to set the value in a getter).
  • (cs) in reply to Frank
    Frank:
    COuld be wrong....:
    '=' does not return a value, it assigns a value. '>' on the other hand, returns a boolean based on the values. This is the exact source of confusion. Some people see return a=5; and instinctively think it is a comparison operation, not an assignment operation.
    It's more like people see a=5 and think that a==5 was intended. But once you look again and see that an int is returned, not a boolean, then you realize that the original is the intent (as WTF as it may be to set the value in a getter).
    The bit where it gets completely daft is when they then fail to revise their original expectation, and end up thinking that the '=' operator is both an assignment AND a comparison simultaneously. Major thinko there.
  • Jupiter (unregistered) in reply to snow
    snow:
    If you're going to call people stupid, at least get your own statement right.
    (a = 5) = 3;
    does NOT assign 3 to a. (a = 5) is not a variable, and the left hand side of an assignment has to be a variable. This won't even compile, never mind assign anything.

    Straight from the C# help:

    The assignment operator (=) stores the value of its right-hand operand in the storage location, property, or indexer denoted by its left-hand operand and returns the value as its result.

    So the right hand side of the = is being both set into the left, and returned as a value. So the most accurate way to picture it is that

    return a=5;
    is about the same as
    a = 5;
    return 5;

    It isn't a that is being returned, it is the value of the assignment.

    quite... ( (a=5) == 5 )

  • Conscious Objector (unregistered) in reply to eVil
    eVil:
    Why is it that you always choose 3?

    That's what architects do.

  • Those who live in glass houses... (unregistered) in reply to hoodaticus
    hoodaticus:
    Anonymous Cow-Herd:
    XIU:
    Mister Cheese:
    Some damn Yank:
    The Enterpriser:
    This is actually very useful for when you want to make use of the set value from within the method whilst limiting out of scope use to '5'.

    I have seen very effective use of this pattern in the security industry. The strength of this lies in the way that the get is also secretly a setter too.

    So, let me get this straight. maxRetry is 1 internally, and someone outside can set it to whatever they want, but if they ask they're always told it's 5? What's the point of that? I guess what I'm missing here is what really happens (sorry, I'm a tester not a coder). Is maxRetry always 1, or do you really let it be set to something else? And if so, why do you lie and say it's 5?

    Is it more like maxRetry is set to 1 initially, you can set it to a new value, and when you read it once, it returns the value it's set to and then sets itself to 5?

    The health+safety executive advises people in ivory towers not to ride high horses.

    The code will set the field to 5 AND return 5

    Surely it sets the field to 5 and returns true?

    That's the C++ behavior. But I don't think it would compile in C#.
    I wish all you ivory tower wannabes would get off your high horses. C++ IS C#! Do you even know what C++ is? It's a programming language. C# is a programming language. Now STFU.

  • (cs) in reply to c
    c:
    CC:
    If may be more useful for you to picture it that way, but it is wrong.

    Part of the definition of the in-fix assignment function in C family of languages is that the return value of that function is the evaluated RHS.

    Wrong! (a = 5) = 3; // Assigns 3 to a
    I think the implicit part of that statement was "unparenthesized".

    Also, at least in C++-land, that causes undefined behavior, so you won't necessarily get 3 out of it.

  • (cs)
    [image]

    so much fail in this thread

Leave a comment on “Representative Property: MaxRetry”

Log In or post as a guest

Replying to comment #:

« Return to Article