• (cs)

    TRWTF: Claiming that declarations are always ordered alphabetically, when clearly they are not!

    This is how to do it correct:

           context_option_type_bool                = 1,
           context_option_type_double              = 2,
           context_option_type_file_not_found      = 7,
           context_option_type_float               = 3,
           context_option_type_max                 = 7,
           context_option_type_string              = 4,
           context_option_type_uint32              = 5,
           context_option_type_uint64              = 6,
           context_option_type_unknown             = 0;
    
  • anonymous (unregistered)

    This representative line really just says it all:

    assert(false && "Invalid context option specified.");
  • (disco)

    Article is passable levels of WTF. TRWTF is that the main page says '1 Comments' when it's simply @PaulaBean's comment on the subject telling us there's a post.

  • (disco)

    I don't get it, why the two-space indentation after typedef, while others are 4-space indentation? Perhaps this is TRWTF?

  • (disco)

    TRWTF is suggesting getopt() instead of boost::program_options when the article is clearly based on C++.

  • (disco) in reply to Arantor
    Arantor:
    Article is passable levels of WTF. TRWTF is that the main page says '1 Comments' when it's simply @PaulaBean's comment on the subject telling us there's a post.
    You forgot *frist* then!
  • (disco) in reply to tufty
    tufty:
    TRWTF is suggesting ```getopt()``` instead of ```boost::program_options``` when the article is clearly based on C++.
    Which works wonders for those who don't have the Boost library installed :stuck_out_tongue:
  • Anon (unregistered) in reply to anonymous
    anonymous:
    This representative line really just says it all:
    assert(false && "Invalid context option specified.");

    No it doesn't.

    The ANSI C assert function does not provide an argument for a message, but when the assert fires it does print out the expression that caused the assert failure.

    The && "Something" is a very common way to ensure that there is some human readable description when the assert fails, so that you aren't left guessing what the hell happened.

    The use of false is a very common way to force the assert to occur. It's usually used if you want a run time check that is in both release and debug builds, but still want to assert in debug builds to make it easier to find that something went wrong.

    You could argue whether the assert itself was necessary, and you can argue whether the standard C assert function is TRWTF. But none of that is representative of the mess that is the rest of the code.

  • (disco) in reply to faoileag
    faoileag:
    You forgot *frist* then!

    Fuck frist. I am glad to be combo breaker.

  • (disco) in reply to RaceProUK

    Yes, I know, I know.

    I once had somebody seriously suggest using some bits of boost for a project I was doing. A project that was written in C, and which targetted a rather small Atmel µC.

    Filed under: Why don't my damned <sarcasm> tags show up?

  • (cs) in reply to Anon
    Anon:
    The ANSI C assert function does not provide an argument for a message (...)
    TRWTF!
  • anonymous (unregistered) in reply to Anon
    Anon:
    anonymous:
    This representative line really just says it all:
    assert(false && "Invalid context option specified.");

    No it doesn't.

    The ANSI C assert function does not provide an argument for a message, but when the assert fires it does print out the expression that caused the assert failure.

    The && "Something" is a very common way to ensure that there is some human readable description when the assert fails, so that you aren't left guessing what the hell happened.

    The use of false is a very common way to force the assert to occur. It's usually used if you want a run time check that is in both release and debug builds, but still want to assert in debug builds to make it easier to find that something went wrong.

    You could argue whether the assert itself was necessary, and you can argue whether the standard C assert function is TRWTF. But none of that is representative of the mess that is the rest of the code.

    It could be argued, somewhat convincingly I think, that:

    if (something) assert(false && "something");

    should be changed to:

    assert(!something);

    But you're basically right, so I'm really not going to argue the point of semantics.

  • (disco)
    For those unfamiliar with C, I recommend investigating getopt, the POSIX standard function for parsing command-line options.
    There's the real WTF: why would anyone unfamiliar with C even **want** to investigate getopt? I'd wish I could go back to being unfamiliar with C.
  • (disco)

    Cannot find cornify. Please advise.

  • (disco) in reply to tufty
    tufty:
    Why don't my damned <sarcasm> tags show up?
    Use the HTML entities, and it'll work: <yaytag>
  • (disco)

    Will this even compile in a DEBUG environment? Those assert calls try to use a bool and a string as arguments to &&. Please tell me somebody did not overload that operator that way!

  • (disco) in reply to Nutster
    Nutster:
    Will this even compile in a DEBUG environment?

    Compile? Yes. While they run, OTOH?

  • (disco)

    Argle. All those ::std::{thing} references make my teeth itch. What's wrong with just "std::{thing}" instead? (Yes, I know, leaving out the initial :: leaves the code open to sub-namespaces called std, but really, who does that, and can I strap whoever it is to the noisy end of my GAU-8?)

  • (disco) in reply to RaceProUK
    RaceProUK:
    Use the HTML entities, and it'll work: <yaytag>

    Yes, Discourse is so modern you have to escape your own entities!

  • (disco)

    This is obviously low-level code for Python. The other types will be implemented later.

    from __future__ import *
    
  • facilisi (unregistered) in reply to no laughing matter
    no laughing matter:
    Anon:
    The ANSI C assert function does not provide an argument for a message (...)
    TRWTF!
    Is this the frist time when C was TRWTF? Usually it's Java, PHP, VB, and of course Javascript -- they're all TRWTF by default, even before you write a single line of code.
  • anonymous (unregistered) in reply to facilisi
    facilisi:
    no laughing matter:
    Anon:
    The ANSI C assert function does not provide an argument for a message (...)
    TRWTF!
    Is this the frist time when C was TRWTF? Usually it's Java, PHP, VB, and of course Javascript -- they're all TRWTF by default, even before you write a single line of code.
    Is C the WTF when it's really a macro defined in one of the standard header files?
  • Norman Diamond (unregistered) in reply to anonymous
    anonymous:
    It could be argued, somewhat convincingly I think, that:
    if (something) assert(false && "something");
    should be changed to:
    assert(!something);
    So what? The code doesn't have
    if (something) assert(false && "something");
    The code tests something_else, and in a release build when the assert doesn't do anything the code goes somewhere else. Your change would make a WTF in a release build.
  • Norman Diamond (unregistered)
    Aaron:
    if (
        (string_context_option_lowercase.compare("1") == 0) ||
        (string_context_option_lowercase.compare("true") == 0) ||
        (string_context_option_lowercase.compare("yes") == 0))
    {
        return_value = true;
    }
    So filenotfound and fılenotfound evaluate to false? What kind of bool is this?
  • Norman Diamond (unregistered)
    piisawheel314:
    Remy Porter:
    (about as organized as organized crime).
    I think you might be surprised. Organized crime is probably run better than most software houses.
    I bet he wouldn't be surprised. In fact there's a better way to express how thoroughly organized this operation is and how much force is involved in imposing this organization, but the analogy would Godwinize this thread, preventing rational discourse.
  • Norman Diamond (unregistered)
    Arantor:
    Offers were made that couldn't be refused.
    They should have done objection oriented programming, where programmers refuse each other's classes.
  • (disco)
    (about as organized as organized crime).

    I think you might be surprised. Organized crime is probably run better than most software houses.

  • (disco) in reply to piisawheel314

    Offers were made that couldn't be refused.

  • (disco) in reply to Nutster

    There is no such thing as strings in c. The characters between quotes evaluate to a const char * in this case, which can be bool tested for nullity.

    The string is added to help clarifing the error message when the assert is triggered at runtime. The typical assertion error messages just show the file name, line number and the text passed to the assert macro ". So the author just hacks more text inside.

  • (disco) in reply to rafa1981
    rafa1981:
    There is no such thing as strings in c. The characters between quotes evaluate to a const char * in this case, which can be bool tested for **nullity**.

    The string is added to help clarifing the error message when the assert is triggered at runtime. The typical assertion error messages just show the file name, line number and the text passed to the assert macro ". So the author just hacks more text inside.

    Leave math and division by zero out of this.

  • Fronz Galkton (unregistered)

    At least 2 memory allocations and object constructions, along with more than half a dozen function calls, just to do this?

     return !stricmp(argv[i], "1")
         || !stricmp(argv[i], "true")
         || !stricmp(argv[i], "yes");
    

    P.S. the code in this WTF doesn't replace getopt(), even if you use getopt() you'd still need to parse the individual parameters to an option in various types (which is what this code is supposed to do.)

  • (cs) in reply to Norman Diamond
    Norman Diamond:
    (..) preventing rational discourse.
    Preventing (...) discourse is always the right thing to do!
  • CigarDoug (unregistered) in reply to Norman Diamond
    Norman Diamond:
    Arantor:
    Offers were made that couldn't be refused.
    They should have done objection oriented programming, where programmers refuse each other's classes.
    OK, I'll chime in: The REAL WTF is that responses to comments are shown, but the original comment isn't. So, either Arantor's comment was deleted, or it bled over from Discourse?!!

    Captcha: plaga. Discourse is a plaga on both our houses.

  • anonymous (unregistered) in reply to Norman Diamond
    Norman Diamond:
    anonymous:
    It could be argued, somewhat convincingly I think, that:
    if (something) assert(false && "something");
    should be changed to:
    assert(!something);
    So what? The code doesn't have
    if (something) assert(false && "something");
    The code tests something_else, and in a release build when the assert doesn't do anything the code goes somewhere else. Your change would make a WTF in a release build.
    Yes it does. And the existing code is the WTF, not the change that I suggested.
    if (context_option > this->vector_context_option_to_type_mapping.size())
    {
       assert(false && "Invalid context option specified.");
       goto exit;
    }
    should all be replaced with:
    assert(context_option <= this->vector_context_option_to_type_mapping.size());
    (that's also way too fucking long, but that's another issue altogether)

    There is NO reason for "assert...goto exit". That's its own WTF right there. No, if you disable asserts so that they don't do anything, you should STILL NEVER EXECUTE THE GOTO, BECAUSE YOU SHOULD NEVER GET TO IT IN THE FIRST PLACE.

    In a test build, you should use assert to ensure that the application isn't about to blow up. The assert gives you specific information on what happened (which should've never happened) and where. Ever getting to an assert that is written to always fail means that a critical bug exists in your application. In a release version, the program silently "goes somewhere else" and ignores that critical bug. That is TRWTF.

    If the original programmer wanted to gracefully return false when an invalid context option was specified (and, there could certainly be valid reasons for wanting to do that), using assert at all was simply inappropriate.

  • Norman Diamond (unregistered) in reply to anonymous
    anonymous:
    Norman Diamond:
    anonymous:
    It could be argued, somewhat convincingly I think, that:
    if (something) assert(false && "something");
    should be changed to:
    assert(!something);
    So what? The code doesn't have
    if (something) assert(false && "something");
    The code tests something_else, and in a release build when the assert doesn't do anything the code goes somewhere else. Your change would make a WTF in a release build.
    Yes it does. And the existing code is the WTF, not the change that I suggested.
    The original code has many WTFs, but your WTF is worse than theirs.
    anonymous:
    if (context_option > this->vector_context_option_to_type_mapping.size())
    {
       assert(false && "Invalid context option specified.");
       goto exit;
    }
    should all be replaced with:
    assert(context_option <= this->vector_context_option_to_type_mapping.size());
    No it cannot be. In a debug build, your result is equivalent to the original. In a release build, the original does a "goto exit" but your code barges ahead and performs all kinds of garbage. Do you work for Microsoft?
    anonymous:
    There is NO reason for "assert...goto exit". That's its own WTF right there. No, if you disable asserts so that they don't do anything, you should STILL NEVER EXECUTE THE GOTO, BECAUSE YOU SHOULD NEVER GET TO IT IN THE FIRST PLACE.
    YOU NEED TO LEARN THE FUCKING DIFFERENCE BETWEEN A DEBUG BUILD AND A RELEASE BUILD.
  • anonymous (unregistered) in reply to Norman Diamond
    Norman Diamond:
    The original code has many WTFs, but your WTF is worse than theirs.
    anonymous:
    if (context_option > this->vector_context_option_to_type_mapping.size())
    {
       assert(false && "Invalid context option specified.");
       goto exit;
    }
    should all be replaced with:
    assert(context_option <= this->vector_context_option_to_type_mapping.size());
    No it cannot be. In a debug build, your result is equivalent to the original. In a release build, the original does a "goto exit" but your code barges ahead and performs all kinds of garbage. Do you work for Microsoft?
    Um, no, THE EXISTING code barges ahead and performs all kinds of garbage. Except that it skips merrily past the part that would probably have shat itself and crashed, so the damage is likely to be more widespread and harder to figure out when it eventually does burst into flames.

    In a release build, the code can never execute. It is an unreachable block of code, so it doesn't MATTER that the assert does nothing. You've TESTED it. Or were your customers supposed to do the alpha testing for you? In that case, better to leave the assertions enabled!

    "goto exit" is never a safe alternative when your assertion does nothing. NEVER. At the very least you should have a runtime error check with a big warning "This should never happen, please inform the person who wrote this that there's a critical bug in this code".

    A failed assertion should mean that there is a CRITICAL BUG: something that should never have made it out of testing. Assertions are NOT meant for runtime error checking. If you can simply sidestep the offensive block of code without fear of any bad things happening, then DON'T USE AN ASSERTION. You can use #ifdef and log something in your debug builds, if you want, but don't use an assertion.

Leave a comment on “A Team of One”

Log In or post as a guest

Replying to comment #:

« Return to Article