in reply to Re: Getting different results with $var++ and $var += 1
in thread Getting different results with $var++ and $var += 1

Every time I've ever used a scalar in numeric context in the past it has worked. The +=0 stuff may be unnecessary, but I'm desperate enough to try unnecessary things. I've never had to struggle for hours in order to add two numbers.

Since I posted last night, I got a response to a private request for help that indicates that $var++ just increments without assignment. So is it possible for the ++ operator to increment a value that cannot be seen in numeric context? It's a stretch of my imagination, but I'm open to the idea that it's only a stretch of my imagination because my understanding is stunted.

  • Comment on Re^2: Getting different results with $var++ and $var += 1

Replies are listed 'Best First'.
Re^3: Getting different results with $var++ and $var += 1
by ikegami (Patriarch) on Dec 03, 2008 at 21:46 UTC

    So is it possible for the ++ operator to increment a value that cannot be seen in numeric context?

    Numerical context refers to the conversion of an operand's value to a number by operators that work on numbers. Perl can get a number from any value. The process might result in a warning and the result might be useless, but it will always end up with a number. That means there is no value that cannot be seen in numeric context. That means your question doesn't make sense.

    On a side note, "++" handles strings differently than other values. 

    >perl -wle"$a='a'; print $a+=1"
Argument "a" isn't numeric in addition (+) at -e line 1.
1

>perl -le"$a='a'; print ++$a"
b

    [download]
[reply]
[d/l]
Re^3: Getting different results with $var++ and $var += 1
by GrandFather (Saint) on Dec 03, 2008 at 21:25 UTC

    The question is: "Is it a simple scalar, or is it an object?". Giving the output ikegami asked for could help a lot in resolving the problem.

    Simple scalars behave as you expect. Objects can do whatever they like. Showing us sample that we can run and reproduce the issue would help - we could then try ikegami's test. That doesn't at all mean we want to see your application though, but just enough lines to reproduce the issue. See I know what I mean. Why don't you? for some tips that help in this situation.

    Perl's payment curve coincides with its learning curve.
[reply]
[d/l]

      I just got back to my desk for the first time since I posted last night. I'll get to work creating the test version of the object.

      Despite the shortcomings of my description of the issue I'm encountering, you did answer with valuable information. I hadn't considered that I might be storing an object in any of those variables. I've been under the impression that an object is just a reference, and I thought that printing a reference would have given me something like "HASH0xbf43" rather than the value I was expecting.

      Anyhow, thank you and I'll get back with results as soon as I have them.

[reply]
        I've been under the impression that an object is just a reference, and I thought that printing a reference would have given me something like "HASH0xbf43" rather than the value I was expecting

        That won't be the case if double quotes have been overloaded for that (blessed) object. 
        perl -MMath::BigInt -le 'print Math::BigInt->new(123)'

        [download]
        For example, it's that overloading that causes the above one liner to output 123 instead of Math::BigInt=HASH(0x210fe54)

        Otoh, Devel::Peek::Dump(), in addition to providing more detail, is also a *reliable* way of seeing what the scalar actually is.

        Cheers,
        Rob
[reply]
[d/l]
[select]

In Section Seekers of Perl Wisdom