• Little Bobby Tables (unregistered)

    Hmm ... faced with something like this I'd use the black box method of shooting strings at it and see what comes out. You never know, there may be a pattern to it. Can happily soak up a considerable amount of lovely billable time effectively doing these fun logic puzzles.

  • William F (unregistered)

    Why even look at the code? Black box reverse engineer the requirements from the users.

  • LCrawford (unregistered)

    At least they used the good practice to declare strLine as const & , letting us know up front that it will not be modified. Then we only need to learn that it was never used.

  • Old Nomad (unregistered)

    Weirdness aside, the method:

    • Takes 'strNumbers' comma-separated list, and expands any ranges in it ("1,2-5,6" -> "1,2,3,4,5,6').
    • For each number in the expanded list, depending on the result of method 'GetToken' (which is the only place where argument 'strLine' is used) either deletes the number, or increments it by 1.
    • Returns the resulting list.

    And yes, I'm accustomed to seeing code like this.

  • (nodebb)

    According to one theory, the whole universe is made of strings. It's only appropriate that this one application be made of strings, too.

  • Foo AKA Fooo (unregistered) in reply to William F

    This definitely sounds like you've done this.

    D: "So what does this page do?" U: "It's just a simple form to enter customer's name, address and ID." D: <implement> U: "Where are the FON, SSN, QWE and XYZ fields? How can I set premium status? It doesn't show usage statistics and map location! How can I import customers from MUMPSDB? Why doesn't it ..." D: "Where's the Whiskey?" U2: "The layout is totally wrong! This form must be moved half a pixel left, the font must be tilted left italics, the image must be bigger but consume less space, please use a transparent JPEG, ..." D: "How do I get out of here?" U3: "When I enter names with diacritics, they appear correctly. But they must appear as [mojibake], since it's always been this way and we can't retrain. Leading zeros in ZIP codes must be dropped since it's ..." D: "SMN!"

  • Hobbes (unregistered) in reply to Old Nomad

    Admittedly I am not a programmer, but now that you've actually explained it like that I can actually see it fairly clearly. I am impressed. And somewhat horrified.

  • Ross Presser (google) in reply to Foo AKA Fooo

    Dropping leading zeroes in zip codes is EVIL. It alienates the entire Northeast.

  • (nodebb) in reply to Ross Presser

    Aside from ZIP codes, I discovered that my bank's online interface requires the leading zero in account numbers -- or maybe it requires that leading zeroes NOT be entered. I can't remember which.

  • Foo AKA Fooo (unregistered) in reply to Ross Presser

    Whoosh?

  • anonymous (unregistered) in reply to Old Nomad

    Nice explanation but I'm still left wondering "why would you want to do that". The first part makes sense but the second part with the GetToken function and especially incrementing the original value seems so arbitrary without any comments in the code.

  • Argle (unregistered)

    I hate to say this, but this smacks of being maliciously bad. I think most of us know the concept of "don't blame on malice that which can be adequately explained by stupidity." My current project is along the same lines as the C++ project. The main difference is that it's 30+ year old BASIC code, replete with 1 letter names. X being key to what it's all supposed to do. Regardless, the original programmers had their excuses for what I'm working with... and the programming is not the worst I've ever seen. Summary: is the code the result of malice or incompetence? And I have to ask in return: why not both?

  • D-Coder (unregistered) in reply to William F

    "Why even look at the code? Black box reverse engineer the requirements from the users."

    You're kidding, right?

    The users have no idea what the requirements were ten years ago. They just know that it works (for some value of "works") and it can't be changed in the slightest.

  • Zen (unregistered)

    strLine is actually used in

    if(GetToken(strLine,atoi(str1),true).IsEmpty())

  • sizer99 (google) in reply to D-Coder

    Perhaps he's saying you should take the written requirements gathered from the users before the code was even written - and the response to that is also howls of (sad) laughter.

  • Troll (unregistered) in reply to Old Nomad

    I hope you're not accustomed to WRITING code like this!

  • Chris (unregistered)

    Anyone who has to do things with numbers (besides displaying them as text), and uses strings, clearly has no concept of what a COMPUTER is. I see this confusion all the time, and I deal a lot with random number generators.

  • (nodebb)

    I once had to work with a program that dealt with ranges of things. One time there were only two things that were enumerated, so "1,2" as fine. Then I specified a range "1-2" and the parser blew up. Go figure. I reported the bug and I hope they fixed it. I left before I found out. Parsing things from raw strings can be difficult at times. You need to do all sorts of things. An example is when somebody specifies a reverse range, like "2-1" for the above example. It isn't easy.

  • RLB (unregistered) in reply to Chris

    Anyone who has to do things with numbers (besides displaying them as text), and uses strings, clearly has no concept of what a COMPUTER is.

    True. Then again, anyone who handles things that look like numbers but aren't (house numbers, phone numbers, customer IDs) and uses a number field or variable for them, clearly has no idea what data is. And yes, I see that all too often, as well.

  • (nodebb) in reply to cellocgw

    that my bank's online interface requires the leading zero in account numbers -- or maybe it requires that leading zeroes NOT be entered. I can't remember which.

    My bank supports either but they recommend including them. My old business account number was 8 digits starting with 1001 and I had provided a payer this - but somehow he tried to pay 10001xxxx. The bank sent me a dead-tree letter saying they fixed the payer's error and next time quote my account number with the leading 0 to make it the "standard" 9 digits long.

    In other news when my driver's licence was renewed it gained a leading 0, which freaked out my telco when I had to authenticate for some support.

  • Prophet (unregistered)

    I think this might be from a system called Prophet!

  • Neveralull (unregistered)

    I think if I had to replace that code, my solution would be: CString NewCUtils::IsTokenCStringEmpty(CString strNumbers,const CString& strLine) { return CUtils::IsTokenRangeEmpty(strLine); {

  • medievalist (unregistered) in reply to Chris

    If floating point values you are working with exceed the limits of precision available to you in numeric variable types, you HAVE to use strings for numbers. This is far less common today than it once was, especially since some easy available languages now have built in support for arbitrary precision math, but it still happens.

  • PenguinF (unregistered) in reply to Foo AKA Fooo

    Nah don't think it's that much of a whoosh, he could be complimenting you on the quality/evilness of your schemes.

  • Chris (unregistered) in reply to medievalist

    At such a point, if arbitrary precision is not available, you probably want to start dealing with the logs of such values, unless you really need all the precision, not just the magnitude. I shudder at the thought of some arbitrary precision library doing a whole bunch of arithmetic using strings. But I can see how that may be or have been necessary at some point. Just glad I don't have to deal with it ;)

  • doubting_poster (unregistered) in reply to Zen

    as usual, TRWTF is Remy posting a code analysis without properly reading the code.

Leave a comment on “Is Thinking Range Empty?”

Log In or post as a guest

Replying to comment #:

« Return to Article