• (cs)

    I LOL'd on this one. Pure awesomeness.

  • Anonymous Coward (unregistered)

    Please, please can someone disable those annoying "Frist" comments?

  • Michael.H (unregistered)

    im rofl'ing so hard at that =]

  • MAV (unregistered)

    Fourth!

    But seriously now. That was pretty funny. Almost makes you wonder if they used that var in the past, and eventually maintained the use of that var out.

  • Kev (unregistered)

    Hmm maybe "this" isnt self explanatory enough.. captcha: "smile"

  • data (unregistered)

    LOL great workaround, languages usually have this or self, he made C++ full, both with self and this.

    Captcha: alarm

    LOL

  • (cs)
    MAV:
    Fourth!
    Lysis:
    Fifth! or something

    Nope. Doesn't count if you spell it correctly. Should be "forth" and "fith" or the like.

    Regarding the SOD, I've always heard that self-scrutiny can be a good thing.

  • (cs)

    Delphi uses "Self". I program in both Delphi and JAVA and I struggle with using the wrong identify keyword. I can imagine someone got sick of trying to remember which one to use and he made it so it didn't matter

  • (cs)

    Data objects are like people. There’s the public identity but also a deeper private identity.

    Enigmatic devious objects have layers and layers of identities. Here’s a handy snippet to find the true inner self of an object:

    for (CERTlib * trueSelf = this; trueSelf->self != NULL; trueSelf = trueSelf->self);

    It’s fast compact code, so you’d hardly notice the performance impact.

    --Rank

  • Dan (unregistered) in reply to dzimm
    dzimm:
    Delphi uses "Self". I program in both Delphi and JAVA and I struggle with using the wrong identify keyword. I can imagine someone got sick of trying to remember which one to use and he made it so it didn't matter

    So instead of spending the 10 seconds to get it right, program something in that will completely baffle the next programmer that actually knows what they're doing? Brilliant...

  • tag (unregistered)

    Guessing the cause: If the destructor is called before deinitialize, this pointer may get unavailable. Maybe self is still available? It is so ugly ... marvellous! ;-)

  • Thomas (unregistered)

    Oh God, this is pure genious. I want to shake this guy's hand.

    captcha: waffles, haha.

  • Corporate Cog (unregistered)

    The writer may have come from delphi where "this" is named "self" and he or she liked the term better.
    Not an excuse; just a possible reason.

  • Jim (unregistered)

    So I take it the "Real WTF" (TM) here is that it's missing the const?

  • Mark A. (unregistered)

    Does this mean the application is "self aware"?

  • Reliant (unregistered)

    A work around like this is needed in Javascript when dealing with virtual functions, but that certainly isn't the case here. Funny stuff.

  • John Doe (unregistered) in reply to Dan
    Dan:
    dzimm:
    Delphi uses "Self". I program in both Delphi and JAVA and I struggle with using the wrong identify keyword. I can imagine someone got sick of trying to remember which one to use and he made it so it didn't matter

    So instead of spending the 10 seconds to get it right, program something in that will completely baffle the next programmer that actually knows what they're doing? Brilliant...

    I even dare to say Brillant!

  • Bob (unregistered)

    That's hilarious!!! Look what I can do:

    fnCERTlibDeinitialize( this->self->self ); fnCERTlibDeinitialize( this->self->self->self ); fnCERTlibDeinitialize( this->self->self->self->self ); ... etc.

  • N2 (unregistered) in reply to dzimm
    dzimm:
    Delphi uses "Self". I program in both Delphi and JAVA and I struggle with using the wrong identify keyword. I can imagine someone got sick of trying to remember which one to use and he made it so it didn't matter

    Funny, in the one place he DID use the pointer, he used "this" anyway. Using "this->self" sure is a good way to not have to remember to use "this"

  • (cs)

    Egocentric:

    fnCERTlibDeinitialize( self->self->self );

    Insecure:

    fnCERTlibDeinitialize( self!=this?self:this );

    Suicidal:

    fnCERTlibDeinitialize(( self=0,this ));
  • Khanmots (unregistered)

    And here I thought it was going to be some bastardized attempt to implement a single-instance class.

    Silly me!

  • John Doe (unregistered)

    It seems this class has some schizofrenic potential. It will become truly schizofrenic if self is pointed to a new class instance. To make it interesting, this should be decided at random in the constructor, with a small change for a split personality.

    Here is what I mean:

    CERTlib::CERTlib(...) 
{
   // Store ptr to self
   if(rand() % 100 < 3)
      self = new CERTlib();
   else
      self = this;
   ...
}
  • chuck (unregistered)

    What this programmer should have done was made self an instance of the SelfLocator pattern. SelfLocator has an instance variable that is initialized with whatever you pass to its constructor. So you instantiate it as new SelfLocator(this). That way you can ask SelfLocator to return your self using its getSelf() method. I think that would be much more Enterprisey-Class.

  • Global Warmer (unregistered) in reply to Bob
    Bob:
    That's hilarious!!! Look what I can do:

    fnCERTlibDeinitialize( this->self->self ); fnCERTlibDeinitialize( this->self->self->self ); fnCERTlibDeinitialize( this->self->self->self->self ); ... etc.

    ROFLMAO at this post and at the WTF

  • (cs)

    this->self and you are this!
    but if self = this, then who are you? I am this! I am this and you are self! but if you are this and I am self, and this->self and self = this, then who is he?? points to new self Arrrrgh!

    captcha: mad tv's 6th day parody

  • (cs) in reply to John Doe
    John Doe:
    It seems this class has some schizofrenic potential. It will become truly schizofrenic if self is pointed to a new class instance. To make it interesting, this should be decided at random in the constructor, with a small change for a split personality.

    Here is what I mean:

    CERTlib::CERTlib(...) 
{
   // Store ptr to self
   if(rand() % 100 < 3)
      self = new CERTlib();
   else
      self = this;
   ...
}

    Yes, but for a true split personality wouldn't you want to do this?

    CERTlib::CERTlib(...) 
{
   // Store ptr to self
   if(rand() % 100 < 3)
   {
      self = new CERTlib();
      self->self = this;
   }
   else
      self = this;
   ...
}

    Think of all the nice obscure bugs that would introduce...

  • anne (unregistered)

    Maybe they were trying to implement an infinitely long linked list! Or, they were trying to find out how big of a stack they could get:

    void
CERTLib::dumpCore(CERTLib *c, int i)
{
   if (c)
     dumpCore(c->self, i+1);
}

    P.S.: The real WTF is that they didn't initialize 'self' in the constructor initialization list.

  • anne (unregistered) in reply to chuck
    chuck:
    What this programmer should have done was made self an instance of the SelfLocator pattern. SelfLocator has an instance variable that is initialized with whatever you pass to its constructor. So you instantiate it as new SelfLocator(this). That way you can ask SelfLocator to return your self using its getSelf() method. I think that would be much more Enterprisey-Class.

    design patterns FTW!!!!

  • zolf (unregistered)

    self.self.self.self.self.self.self.self.self.self.self.self.self.self.self.self.self.do_wtf()

  • Markku Uttula (unregistered)

    "fnCERTlibDeinitialize" ... Just one thing crosses my mind: OUCH!

  • Loren Pechtel (unregistered)

    I'm going to go with the notion that it's a Delphi programmer making the language more like what he's used to.

    Captcha: bathe. The dirty code, perhaps??

  • .oisyn (unregistered) in reply to Serpardum
    Serpardum:
    John Doe:
    [...]

    Yes, but for a true split personality wouldn't you want to do this?

    CERTlib::CERTlib(...) 
{
   // Store ptr to self
   if(rand() % 100 < 3)
   {
      self = new CERTlib();
      self->self = this;
   }
   else
      self = this;
   ...
}

    Think of all the nice obscure bugs that would introduce...

    Not to mention the possible memory leaks.

  • tacos (unregistered)

    ...does the deinitialize function zero out it's argument or something?

  • (cs) in reply to Coincoin
    Coincoin:
    Egocentric:
    fnCERTlibDeinitialize( self->self->self );

    Nah, that's just self abuse.

  • Bigwig (unregistered)

    Probably just a messed up Singleton implementation. No WTF really imho.

  • (cs)

    If this is a Delphi programmer trying to make themselves feel at home in C++, then it's similar to the WTF that I'm currently coping with. I've inherited a spaghetti like mass of Java code from a programmer who had a background as a Perl scripter. His solution to the problem of strong typing foisted upon him by Java was to use Strings for everything, and LinkedHashMaps as his only data structure. As if that wasn't bad enough, he seems to have discovered the Reflection API at some point, which gave him even more scope for writing inefficient code without type safety.

  • Crash magnet (unregistered) in reply to Bob
    Bob:
    That's hilarious!!! Look what I can do:

    fnCERTlibDeinitialize( this->self->self ); fnCERTlibDeinitialize( this->self->self->self ); fnCERTlibDeinitialize( this->self->self->self->self ); ... etc.

    Consider this:

    this->self->self->fnCERTlibDeinitialize( this->self->self ); this->self->self->self->fnCERTlibDeinitialize( this->self->self->self ); this->self->self->self->self->fnCERTlibDeinitialize( this->self->self->self->self );

    Crash Magnet

  • Mike Nuss (unregistered) in reply to dzimm
    dzimm:
    Delphi uses "Self". I program in both Delphi and JAVA and I struggle with using the wrong identify keyword.

    Java is not an acronym.

  • Ph (unregistered) in reply to chuck
    Bob:
    What this programmer should have done was made self an instance of the SelfLocator pattern. SelfLocator has an instance variable that is initialized with whatever you pass to its constructor. So you instantiate it as new SelfLocator(this). That way you can ask SelfLocator to return your self using its getSelf() method. I think that would be much more Enterprisey-Class.
    While the SelfLocator is a powerfull pattern, I think in this case we are facing a Pluri-Singleton. See, the Singleton is limited in that it associate only a single instance for a given class. This doesn't scale in today's Enterprisey-class application. The Pluri-Singleton allows to get an instance for each objects!
  • Synonymous Coward (unregistered) in reply to John Doe
    John Doe:
    It seems this class has some schizofrenic potential. It will become truly schizofrenic if self is pointed to a new class instance. To make it interesting, this should be decided at random in the constructor, with a small change for a split personality.

    The default copy constructor would give you something similar for free:

    #include <iostream>

struct CERTlib {
   CERTlib* self;

   CERTlib() : self(this) {}
};

int main() {
   using std::cout;
   using std::hex;

   cout << hex;

   CERTlib a;
   cout << &a << ' ' << a.self << "\n";

   CERTlib b = a;
   cout << &b << ' ' << b.self << "\n";

   return 0;
}
  • Nazlfrag (unregistered) in reply to Mike Nuss
    Mike Nuss:
    dzimm:
    Delphi uses "Self". I program in both Delphi and JAVA and I struggle with using the wrong identify keyword.

    Java is not an acronym.

    Don't you mean, JAVA Ain't Very Acronymy?

  • IV (unregistered)

    Couple of things.

    1. If this really is a mixed up keyword between languages, I hope it originates from before the days of an editor which highlights keywords for you. Anyone having those sorts of problems should use one of those editors as much as possible.

    2. When self is deinitialized, doesn't that deinitialize this as well? So isn't that memory freed, allowing the return that is implied at the end of the deinitialized function to be overwritten? If I am right, this is a potential for a very hard to find bug. If I am wrong, someone will correct me, and I will learn something else new today.

    Captcha: pinball

  • Steve H. (unregistered)

    My thought was on this was that the original programmer either was taught to do this or instinctively does this for static methods, where you don't get *this

  • M (unregistered)

    What if he's using a smart/shared pointers, and needs an explicit pointer to the class in order to keep it alive? Based on what's displayed in the post, it appears this could be valid code.

  • Mogri (unregistered) in reply to java.lang.Chris;
    java.lang.Chris;:
    Coincoin:
    Egocentric:
    fnCERTlibDeinitialize( self->self->self );

    Nah, that's just self abuse.

    This comment wins. (Or should that be "this->self comment wins"?)

  • I'm Da Hammer! - M.C. Hammer! (unregistered)

    Obviously the coder realized the truth,

    You can't touch this.

  • C++ Guru (unregistered) in reply to tag
    tag:
    Guessing the cause: If the destructor is called before deinitialize, this pointer may get unavailable. Maybe self is still available? It is so ugly ... marvellous! ;-)

    In C++, any access to an object after the destructor is called is undefined. This means the program is free to do nothing, throw an exception, or reformat your hard drive. All would be valid consequences.

    "self" is an instance member of the class, and is therefore unavailable after the destructor is called. Moreover, any copies of "self" squirreled away somewhere else are now dangling pointers to a destructed object. They are just undefined behavior waiting to happen.

    C++ is hard.

  • Anonymous Coward (unregistered) in reply to M
    M:
    What if he's using a smart/shared pointers, and needs an explicit pointer to the class in order to keep it alive? Based on what's displayed in the post, it appears this could be valid code.

    Then TRWTF would be the lack of proper documentation.

  • john (unregistered)

    This is a common pattern I've seen in C, where the first member of a struct is initialised to be a pointer to itself. When you're passed a pointer to such a struct, you can check it is valid:

    assert(ptr == ptr->self);

    I reckon its a relic of this kind of defensive programming and so not such a wtf as you might think.

    John

  • Anon (unregistered) in reply to Anonymous Coward
    Anonymous Coward:
    Please, *please* can someone disable those annoying "Frist" comments?
    I propose a simple solution: if there aren't any posts yet, the first one gets deleted. ¬_¬

Leave a comment on “Class Ego”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article