• (cs) in reply to FredSaw
    FredSaw:
    Dana:
    captcha: genitus
    Ah yes, famous Roman warrior. Son of Copulus and Labia.
    OK ... that one is definitely in 7/8.
  • (cs) in reply to Roy-G-BIV
    Roy-G-BIV:
    Maybi hiz boss wantid to ahdopt a nu, mor lojicul speling ov wurds like sucsess?

    Ouch! That was painful to type.

    As the doctor in the joke would say, "Well, stop typing it, then."

  • (cs)
    Fred Annon:
    Fred Anon:
    Carl:
    C/C++ programs don't have to return an int.
    Right, sometimes they can return a Windows object that instantiates a HWND. In Unix, though, "return non-zero on failure" is very very common. Windows code seems to have half-absorbed this rule.
    He didn't say anything about Windows, only C++. As he said, in C++ main can return void, and in such case libc should return 0 to OS (be it Windows, MacOS or Gnu)

    As others have pointed out: rubbish. And every single C++ compiler I know of (including VS2005) will point out that this is rubbish. Unless you are particularly rigorous in switching all manner of warnings off, in which case, pat yourselves on the back -- you have a Process! To quote from the first thing that comes up on Google when you query "c++ standard main:"

    "The ISO C++ Standard (ISO/IEC 14882:1998) specifically requires main to return int. But the ISO C Standard (ISO/IEC 9899:1999) actually does not."

    And the idea of invisibly casting "void" into "0" is not even worthy of contempt.

    gabba:
    Nothing wrong with zero for success and non-zero for failure. That's the traditional Unix way. There's only one way for a function to succeed, and potentially many ways to fail, corresponding to the true/false semantics in C.

    But judging from the rest of this wtf, I'm guessing that's not what motivated this "design".

    Well, there are shell scripts and there are C/C++ programs (if we're going to talk about a rather restricted universe of the "Unix Way"). Like so much about Unix, this is fucked-up and utterly retarded. "0" means success in Unix (conventionally) and failure in C/C++ (conventionally). Somewhere along the line between Martin Richards, the beloved progenitor of BCPL, and Ken Ritchie and mates, the concept of failure as 0xFFFF... (choose word size) and 0 (who cares?) got too confusing for people who have something better to do. It may have something to do with the instruction set on the PDP-8; it may have something to do with electro-magnetic characteristics of core memory, for all I know, but the end result is a bit messy. The only reason that C/C++ programs and shell scripts "agree" on the "semantics" of success/failure is that vastly more idiots write shell scripts than write C/C++ programs. It's Gresham's Law in computer terms.

    Arguments about semantics here are bogus. There is one way to succeed: you succeed. There is one way to fail: you fail. (With a passing nod to FILE_NOT_FOUND.) Anything else is a side-effect, kiddies. Jeez. I'm being drawn more and more to functional languages, every day.

    But, to the WTF. It isn't one. Regardless of mis-spellings, stupid use of manifest constants and the pre-processor rather than const variables, idiotic dependence upon what is declared before what else, etc: we are told that the solution works.

    That would make it preferable to around 60% upwards of "Made in America" or "Made in the EU" solutions.

    Quit yer bitchin'.

  • Anders (unregistered) in reply to Some C++ Guru
    Some C++ Guru:
    #define private public #define protected public

    You forgot one.

    #define class struct

  • (cs) in reply to Anders
    Anders:
    Some C++ Guru:
    #define private public #define protected public

    You forgot one.

    #define class struct

    Oh yes, let's ignore the Standard and produce totally non-portable and breakable code. That's what C++ is for, isn't it?

    Well, there are no guarantees that

    #define private public

    will work at all. But if you really, really, want to act like a prat, then anders is correct: you very definitely want to redefine classes as structs. Why? Well, think when the public/private keyword is first required.

    This is all very well if you're just trying to access member functions (or, I suppose, data) of an individual class (or, I suppose, now a struct). It's a little trickier with inheritance. Chances are, you'll end up with a class that can be used polymorphically where it shouldn't be, or has virtual methods calling some random pimpl acquired silently through a Koenig look-up, or ... the mind boggles.

    Look, if C++ is too difficult for you, go back to Java. That's what the language was designed for, for God's sake.

    (It's also very popular with outsourcing companies, or so I've heard.)

  • Anonymous (unregistered) in reply to gabba

    Absolutely nothing wrong with that - until the minute someone decides to make these helpful:

    #define TRUE 0
#define FALSE -1

    which results in

    if (open(filename, O_RDONLY) == TRUE) {}

    and

    if (open(filename, O_RDONLY)) {}

    to mean two very different things.

  • (cs) in reply to I Just Have To Say It
    I Just Have To Say It:
    Since no one else has said it, I will:

    FILE_NOT_FOUND!

    Since no one else has said it, I will:

    TRWTF is in the comments

  • (cs) in reply to ThePants999
    ThePants999:
    Looks to me like the mis-spelling "SUCSESS" might actually be deliberate, so that when you call Admin:Update() you can distinguish between OPER_SUCCESSFUL and actual success!

    Just the title of this WTF brings back memories. I set up a database backup system which tracked the status of backups of a large number of remote sites, and replicated the data to a central location. About a year later we set up a website to track the statuses. After we set up the website, someone noticed I had misspelled successful as "sucessful". By then, of course, there was a lot of data everywhere with the wrong spelling, so we still have code to correct my misspelling, several years later.

  • Moz (unregistered) in reply to Anonymous
    Anonymous:
    Absolutely nothing wrong with that - until the minute someone decides to make these helpful: 
    #define TRUE 0
#define FALSE -1
    The only things which will become wrong when someone creates those macros are those macros themselves. It's just like an enum in that way.

    Apart from "SUCSESS", my only worry with the macros in the article would be knowing which ones are used where.

  • (cs) in reply to FredSaw
    FredSaw:
    Paul:
    We didn't have source control or code reviews, the developers wrote the QA tests and carried them out...
    Developers should NEVER be the sole testers of their own code. I learned this lesson well while writing an application for the Production Control department of a fabrication company. I would work for two weeks on the code, and then test for a couple of days in every way that I could conceive. When I thought it was bulletproof, I would deliver it to the Production Control manager, who was generally able to bring it to its knees within about eight seconds.

    And in disbelief at the idiotic thing he had just done, I would say, "Why in god's name would you do something like that?"

    And he would reply, "Because my employees will do it."

    Yep, you don't want to be the tester of your own code. You're too intimate with it; you know what to do with it. It must be released to the idiots if it is to be idiot-proof.

    As I often have to test my own code (how can anybody believe a programmer could test is own stuff) I often do The Monkey Test: just slap on your keyboard like a maniac and see what happens. That is more or less the way your future user will be acting.

    KEBOARD_NOT_FOUND = True ????

  • Ryan (unregistered) in reply to ThePants999

    You are right. I have also had the experience of something like this in a lecacy system, they had multiple categories in code but because they might be seen as the same value when they were different categories they were named "ACCESSORIES","ACESSORIES" and "ACCESORIES". Then a filter on the presentation to write the friendly name.

    Very painful...

    CAPTCHA is a very on message "praesent"

  • Matt (unregistered)

    "SUCCESS is misspelled"

    That can actually be a good thing. I remember finding a few "SUCCESS" #defines in include files under /usr/include, which pretty much ruined any chance of using that as a constant in a class, value in an enum or anything like that. I wish more people would misspell their #defines, as they cause me too much trouble when they are spelled correctly. :)

  • hax! (unregistered)

    "Oh, and as for my attempts at showing the boss how bad our outsourced code is? !SUCSESS. After all, the application did work." So, true?

  • Matt (unregistered) in reply to Anders
    Anders:
    You forgot one.

    #define class struct

    You do know that it doesn't really make much of a difference unless you fail to specify public/private/protected? A struct is a class in C++, only struct defaults to public members and class to private members.

  • (cs) in reply to real_aardvark
    real_aardvark:
    FredSaw:
    Dana:
    captcha: genitus
    Ah yes, famous Roman warrior. Son of Copulus and Labia.
    OK ... that one is definitely in 7/8.
    We could make it a haiku:

    Genitus: ah, yes. Copulus/Labia spawn. Famed Roman warrior.

    That's assuming warrior is pronounced as two syllables...

  • (cs) in reply to ddd
    ddd:
    ./configure && make && make install

    The second and third command is only executed if the previous commands returned 0.

    So 0 && 0 && 0 == SUCSESS? Mind boggles...

    Not exactly:

    <g7umah> /home/g7umah $ 0 && 0 && 0 ksh: 0: not found

    Were you kidding? I couldn't tell.

  • umm... (unregistered) in reply to FredSaw
    FredSaw:
    Yep, you don't want to be the tester of your own code...It must be released to the idiots if it is to be idiot-proof.
    Before I had projects which required me to provide direct support for commercial end-users, I might've thought that characterization was harsh.

    But...

  • (cs) in reply to FredSaw
    FredSaw:
    real_aardvark:
    FredSaw:
    Dana:
    captcha: genitus
    Ah yes, famous Roman warrior. Son of Copulus and Labia.
    OK ... that one is definitely in 7/8.
    We could make it a haiku:

    Genitus: ah, yes. Copulus/Labia spawn. Famed Roman warrior.

    That's assuming warrior is pronounced as two syllables...

    Well, I was referring to "Son of Copulus and Labia," which is definitely 7/8. Reverting to more traditional and Eurocentric metres, what you have here is a perfect dactylic pentameter ("Son of Copulus and Labia") so long as you observe a caesura after the last syllable. Caesuras don't really work at the end of a line, so you'd have to shift this whole thing by around five or six syllables either way, with appropriate content.

    Nobody every said that Ancient Greek poetry, or indeed drumming, was easy.

    Addendum (2008-02-14 18:34): Well, it's a little late, but what I actually meant was (that being two dactyls, right there) iambic pentameters; not dactylic.

    Ho hum.

  • segra (unregistered) in reply to Some C++ Guru

    Ouch!

  • (cs)

    Why is the first thing I thought of upon seeing this post "CONGRATURATION! YOU SUCSESS!"?

  • Project2501a (unregistered) in reply to Tobias

    #define FAILED FAILURE

  • david (unregistered) in reply to David

    PDP family processors had bit-mapped jump conditions, leading to the convention that 1 = True. Processors which jump on the sign bit lead to the convention that -1 = true.

    1's complement arithmetic leads to the convention that 1 = true, 2's complement arithmetic leads to the convention that -1 = true.

    There is an inherent contradiction between the belief that C is 'close to the machine' and the belief that C is portable.

    This matches the other inherent contradiction between the belief that Unix is 'natural' and the belief that Unix is portable.

  • Miral (unregistered) in reply to Vollhorst
    Vollhorst:
    Every C/C++-program returns an integer value. 0 == success and everything else is the error code that occurred.

    That's why you can write something like:

    ./configure && make && make install

    The second and third command is only executed if the previous commands returned 0.

    As additional proof: standard Unix has a command called "true" that always returns 0, and another called "false" that always returns 1.

  • yoda_alex (unregistered)

    What's worse is that

    return "SUCCESS";

    puts the string "SUCCESS" on the stack, the function then returns and the stack variable is freed, so the function ends up returning a pointer to invalid memory!

  • ensi (unregistered)

    "Yes," Jake adds, "it returns a literal char*, which is then cast to an STL string on the function return, which is then cast to a c_str in the comparison, which is finally compared with strstr(). All this for a Boolean! "

    Fail.

    the pointer to the literal string is used to create a std::string object on which c_str() function is then called. There's no casting involved.

    Sounds like "Jake's" C++ competence leaves something to desire as well!

  • AdT (unregistered) in reply to Some C++ Guru
    Some C++ Guru:
    The "bool" type in C++ is not that hot, especially as it comes to STL. To paraphrase (badly) Scott Meyers, from one of the Effective books: There's nothing wrong with an STL collection of bool, so long as you understand it's not really a collection, and it doesn't really have bools in it.

    What a worthless load of half-truths and misquotations. First, in STL parlance, there aren't collections but containers. Second, only the vector<bool> specialization is affected by the misdesign from good intentions (and it ends up being neither a vector nor a container in the strict sense). Third, this has nothing at all to do with bool itself.

  • Anonymous (unregistered)

    Might be an old oe, but... #define true false; #define false true; //now try and debug this, suckers

  • Me (unregistered) in reply to Some C++ Guru

    I will sometimes use those definitions in unit tests to allow unit tests to view or pre-set internal states that are just too hard to get to initially with a test harness...so those defines are not totally out of place.. if used in the correct context.

  • LD (unregistered)

    "...which is then cast to an STL string on the function return, which is then cast to a c_str..."

    ... uh... actually nothing is being cast to anything here. A std::string is being instantiated with a const char* (aka, string literal) and then a const char* is being returned from a std::string (e.g., const char* std::string.c_str()). Utterly ridiculous, really, but the other WTF here is that the submitter clearly doesn't grasp the difference between type casting and object instantiation / value returns.

Leave a comment on “SUCSESS?”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article