• (nodebb)

    Some people really, really like to kill the environment with their most inefficient way to implement the simplest algorithms. By this point I no longer think it's stupidity, it feels more like an intentional crime against humanity.

  • Registered (unregistered)

    Boolean.Parse is over the top, but I prefer the simple if-then-else above it. Easy to read, easy to maintain, and the compiler can optimize as necessary.

  • (nodebb) in reply to MaxiTB

    In many places number of lines is still the main metric for coder productivity. Writing as obtuse and ineffective code as possible becomes the goal.

  • Hanzito (unregistered) in reply to Allexxann

    Boolean.parse("frist") is still one line. Perhaps this is a clever safeguard against #define true (random() < 0.999)!

  • (nodebb) in reply to Hanzito

    C# doesn't have macros by design, so that's not an option. Plus you cannot overwrite keywords.

  • WTF Linter (unregistered)

    if ((someCondition || someOtherCondition) ? Boolean.Parse("true") : Boolean.Parse("false")) { return Boolean.Parse("true"); } else { return Boolean.Parse("false"); }

  • Maia Everett (github) in reply to Hanzito

    But such a #define is not possible in C#!

  • Sauron (unregistered)

    What The False?

    Sometimes I wonder what truth can be returned by devs' minds.

  • NoLand (unregistered)

    Clearly, true and false are magic constants and are to be avoided… e.g., by using clear name strings.

  • (nodebb)

    I'm not willing to dig into the docs this morning, but I wonder how well Boolean.Parse("true") works when the CurrentCulture is not one of the "en-whatever" variants. IOW in French, German, Russian, Arabic, etc.

  • (nodebb)

    Any boolean comparison is unacceptable if it doesn't contain FileNotFound.

  • Brian (unregistered)

    When I see stuff like this, I always wonder if it's generated code. I could imagine a code generator that produces something like "return {type}.Parse({value}). In fact, I was just looking at one yesterday. But if an actual, living person wrote this, I weep for my profession.

  • (author) in reply to WTFGuy

    So, you got me curious about that- I hadn't even considered that behavior. But according to the docs, Boolean.Parse does a comparison against the property TrueString and FalseString, which are "True" and "False" respectively. Per the docs, only "True", "true", "False", "false" will successfully parse- which is interesting, because it implies that it's not a simple case insensitive comparison.

  • (nodebb)

    Remember that strings are immutable in C# (.Net in general). And any strings that have the same value will share the same memory address.

    This means that doing a simple compare vs "True" and "true" is just comparing against a couple of memory addresses and therefor very efficient.

  • (nodebb) in reply to WTF Linter 
    if ((someCondition || someOtherCondition) ? Boolean.Parse(true.ToString()) : Boolean.Parse(false.ToString())) 
{
  return Boolean.Parse(true.ToString()); 
} 
else 
{ 
  return Boolean.Parse(false.ToString()); 
}
  • (nodebb) in reply to Auction_God

    No. Only interned strings share the same memory address:

    https://sharplab.io/#v2:C4LgTgrgdgNAJiA1AHwAICYCMBYAUKgZgAIMTMB2PAbzyLpPXVvqvqObbtUwE4AKYJACmAOgAqAewDKggJZQA5nwCURALxqiAcSHAxwlcoDcHTt34AlIQDMhYIVADGQgKIBHCAEMANgGcBwuLScooqMNq6+hBChsambOZ8Vrb2Tq4ePv6C0UEyYPJKyuHcAAwiAJJQwHZQfDp6BspNcbhsAL6mpgAO+QBuntVkAGxkJREN0SrqAHzx9ABE2ULzQQCqXV12KgDaJQC6RIhE88LzJrhtQA

    Using string.Intern on a string will search the intern pool to find the "True" used by System.Boolean, which then has the same address

    Addendum 2024-09-26 09:46: String comparison does check memory addresses first, but if they aren't it does a char-by-char comparison (possibly vectorized).

  • (nodebb) in reply to Registered

    Pretty sure compilers are just as good as optimising the "return a ? b : c" version as the "if (a) then { return b; } else { return c; }" version. Possibly even better in some cases (it'll be fairly clear to the compiler (as well as to the reader!) that there's only one return path, for instance).

  • LongTimeLurker (unregistered)
    Comment held for moderation.
  • (nodebb)

    It's a bit more complicated like that. For starters all literal and const strings are guaranteed interned (which applies to those boolean constants - actually, they are readonly references to literals for performance reasons, but that's another sack of beans).

    Now during the old .net framework 1.x days the compiler interned strings very fast, usually at least before a string equality check happened. That's the reason why switch statements worked in C# while it was not possible in Java. Now with 2.0 they changed the string handling; turns out a lot people don't read the manual and did insane stuff like building stuff in an iteration using operators instead of StringBuilder. So from that moment on strings were actually rarely interned automatically and they put a lot effort into keeping features like the switch statement around without loosing to much of the previous performance.

    Now one very important thing about string is that most of it is actually implemented directly by the compiler for releases, this is especially true for equality checks and how and when basic methods and operators apply. Things actually got a lot more complicated recently due to how interpolation is actually handled by the compiler. So just looking at the source code will not help you out there because it rarely applies and there is a ton of direct implementations done by the compiler circumventing using string.operator== or string.Equals ;-)

  • RegisteredReply (unregistered) in reply to Registered
    Comment held for moderation.
  • Argle (unregistered) in reply to Brian
    Comment held for moderation.
  • (nodebb)

    re:

    "turns out a lot people don't read the manual and did insane stuff like building stuff in an iteration using operators instead of StringBuilder"

    One thing compiler writers and language committees need to learn is that NOBODY reads the manual. a = b + c is how people have been taught to add things together and joining strings is like adding them (in people's minds anyway). Telling them to use StringBuilder is not going to cut it. It's not nearly as intuitive as using +.

Leave a comment on “True Parseimony”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article