• PaulaBean (unregistered)

    This topic is now visible. It will be displayed in topic lists.

  • Anonymous (unregistered)

    I get it! getOrSet should have been a template function so that the compiler can optimize out the conditional check!

  • (cs) in reply to PaulaBean
    PaulaBean:
    This topic is now visible. It will be displayed in topic lists.

    Good one - anyone else think that in-thread logging is stupid? Doesn't make much sense for forums to do that... Unless someone out there is using a forum system as a bug tracker, which now that I think about it, might explain a lot of Discourse.

  • Walky_one (unregistered)

    It seems whoever created the getOrSet method was a big fan of jokes like

    A: do you want Apples or Pears? B: Yes.

    Alternatively it's set the getOrSet paramter to true if you want to do a get or set operation. Set it to false if you want to do FileNotFound. (The TRWTF is that the implementation is incorrect)

  • Tinus Lorvalds (unregistered)

    Yet another set of examples of how OOP has caused more trouble than it's worth. The public/protected/private shit mirrors the bureaucracy of enterprise-ness that systems written in it often contain, "getters" and "setters" whose only purpose is to cause extra indirection in the programmer's mind and the computer, and semi-opaque inflexible inheritance. None of this would be a problem if they'd just used C like any sane programmer would.

  • someone else (unregistered)

    I work with an application that uses all-in-one getters and setters, except they're a lot nicer to work with (though they are just as WTF when you first look at them):

    public str parmSomething(str something = _something)
{
    _something = something;
    return _something;
}

    Where _something is the private variable. To get, just call without any arguments. To set, pass in what you want it set to.

  • (cs)

    Re: the article: Undefined behaviour is undefined.

    The virtual function table thing is the most lethal - there's no guarantee that the vtable pointer is at the beginning of an object, even if the compiler uses vtables for virtual function calling. (Yes, I know, these days they all do, and have done for 20 years, but it isn't required by the standards as far as I know.) If ever you have to compile your C++ using cfront, you'll get a nasty surprise, because cfront puts the vtable at the end of the first object in the hierarchy that has one.

    But anyway, programmers who have no fear of undefined behaviour should be shot...

    ... with a GAU-8, just to make sure they never, ever, manage to write code again.

    Re: other comments: Writing C++ code within the rules isn't enormously difficult, but does require a bit more discipline than the sort of hackery that produced most of the code samples we see on this site.

  • jslicer (unregistered)

    Ah, I understand. The method should have been named getXorSet() !

  • Avoid protected (unregistered)

    Commit this sentence to memory - "Protected is effectively public."

  • (cs) in reply to someone else
    someone else:
    I work with an application that uses all-in-one getters and setters, except they're a lot nicer to work with (though they are just as WTF when you first look at them): 
    public str parmSomething(str something = _something)
{
    _something = something;
    return _something;
}

    Where _something is the private variable. To get, just call without any arguments. To set, pass in what you want it set to.

    Ask them to explain what is wrong with doing it properly:

    public void parmSomething(const str &something)
{
    _something = something;
}

public const str &parmSomething() const
{
    return _something;
}
  • nameyour (unregistered)

    Why use two parameters, when you only need one?

    public:
    void getOrSet(TheType &x) {
         if (rand() % 2) {
           this.x  = x;
         } else {
            x = this.x;
         }
    }
  • Smug Unix User (unregistered)

    Please change ab/used to (ab)used. ab/used reads as either ab or used. (ab)used reads as used or abused.

  • Pista (unregistered)

    This is not abuse, this is a threat to national security! The perpetrators should be detained at Guantanamo Bay.

  • GWO (unregistered) in reply to Avoid protected
    Avoid protected:
    Commit this sentence to memory - "Protected is effectively public."

    Also "Protected data is usually a design error", which is straight from the horse's mouth.

  • (cs)

    The "GetOrSet" is actually useful in certain circumstances where you need to transfer many members all on one direction or the other....

  • someone else (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    someone else:
    I work with an application that uses all-in-one getters and setters, except they're a lot nicer to work with (though they are just as WTF when you first look at them): 
    public str parmSomething(str something = _something)
{
    _something = something;
    return _something;
}

    Where _something is the private variable. To get, just call without any arguments. To set, pass in what you want it set to.

    Ask them to explain what is wrong with doing it properly:

    public void parmSomething(const str &something)
{
    _something = something;
}

public const str &parmSomething() const
{
    return _something;
}

    It's a Microsoft application, and the language is based on but not quite C#. I'd be willing to believe it's legacy from when they purchased it (there is a lot of functionality similar to this, which is slowly being corrected). At this point it's a pretty minor thing that would probably take a considerable effort to clean up. Time is better used elsewhere in the application, where the bigger WTFs hide.

  • SMC (unregistered)

    This is absolutely the most horrible code design I have ever seen. I have been using C++ since 1990 and all of the biggest WTFs I have ever seen have been in C++. What these people have done is obscene and a crime against humanity. This is so much worse than anything ever done on a computer that I am going to go ahead and just quit now. No more programming for me. I just can't do this anymore.

  • (cs) 
    public:
    void getOrSet(bool getOrSet, TheType &x) {
	 if (getOrSet) {
	    this.x  = x;
	 } else {
		x = this.x;
         }
    }

    Pity. They missed the opportunity to make it a template method.

  • (cs) in reply to Smug Unix User
    Smug Unix User:
    Please change ab/used to (ab)used. ab/used reads as either ab or used. (ab)used reads as used or abused.
    It's too bad this thread isn't on Discourse. I'd nominate you for a pedantic dickweed badge.
  • my name (unregistered) in reply to tin
    tin:
    PaulaBean:
    This topic is now visible. It will be displayed in topic lists.

    Good one - anyone else think that in-thread logging is stupid? Doesn't make much sense for forums to do that... Unless someone out there is using a forum system as a bug tracker, which now that I think about it, might explain a lot of Discourse.

    More like a bug CREATOR than a bug tracker, wouldn't you say? ;-)

  • populus (unregistered) in reply to Avoid protected
    Of course, if the vendor ever demoted those now-protected fields and methods to private...
    So these guys will just have to start using Reflection to access the "private" fields and methods.
  • Chris P. Peterson (unregistered) in reply to Avoid protected

    Maybe he could ask the third party if they would mind adding those methods to their class so he doesn't have to add it to his. :-)

  • (cs)

    It is amazing how much effort people expend getting around object-oriented languages to create non-object-oriented programs.

  • (cs)
    Gerhardt found where they were using member-pointers (as quasi enums) to tell the method (not what it had to do, but) who called it. The method would then deduce what it was supposed to do based upon who was invoking it.
    Please, no.
  • (cs)

    C++ is like SHOTGUN.

  • the beard of the prophet (unregistered) in reply to populus
    populus:
    Of course, if the vendor ever demoted those now-protected fields and methods to private...
    So these guys will just have to start using Reflection to access the "private" fields and methods.

    This is C++. There is no such thing as Reflection in that language...

    But then, you can get much of the same effect if you just know the offset inside the object of the field you're looking for.

  • (cs) in reply to dkf
    dkf:
    Gerhardt found where they were using member-pointers (as quasi enums) to tell the method (not what it had to do, but) who called it. The method would then deduce what it was supposed to do based upon who was invoking it.
    Please, no.
    It's a common pattern in OO languages, it's called Double Dispatch.
  • iWantToKeepAnon (unregistered) in reply to Avoid protected
    Avoid protected:
    Commit this sentence to memory - "Protected is effectively public."

    Even private in C++ isn't private. I had a 3rd party library with a bug in it and it would have been a simple fix to adjust a member variable except it was private with no accessors. As an individual, I had no clout to get the 3rd party company to pay me any attention.

    So in my wrapper/fixer class, I ignored the 3rd party class header and copied in the class definition and find/replaced all "protected" and "private" declarations to "public" ... and then fixed away. Simple.

    If C++ ordered the memory footprint by protection, then I'd have been hosed. But I created a memory identical declaration and it worked fine. I filed a bug report so I didn't have to maintain the patch forever, but it got me past that obstacle ... I don't remember how long or if the fix ever came in.(?)

    Commit this sentence to memory - "EVERTHING is effectively public."

  • (cs)

    Begone Satan! Go back to the sizeof(void*)'th circle of Hell from whence you came, and do not disturb mortals again. I say begone! BEGONE!… I'm gonna need a bigger cross, guys. Please send help.

    I thought I had seen, if not all, at least a thorough enough sampling of the horrors C++ can be misused to perform that I thought nothing could really surprise me any more. I was wrong. It is as if H.P. Lovecraft wrote this code to evoke the horrors of That Which Man Was Not Meant To Learn About. Shooting the authors of this code is too kind for this kind of crime, they should be made to maintain it for all eternity without Internet access.

  • (cs) in reply to iWantToKeepAnon
    iWantToKeepAnon:
    Avoid protected:
    Commit this sentence to memory - "Protected is effectively public."

    Even private in C++ isn't private. I had a 3rd party library with a bug in it and it would have been a simple fix to adjust a member variable except it was private with no accessors. As an individual, I had no clout to get the 3rd party company to pay me any attention.

    So in my wrapper/fixer class, I ignored the 3rd party class header and copied in the class definition and find/replaced all "protected" and "private" declarations to "public" ... and then fixed away. Simple.

    That's not how you do it. Especially it's not "simple"!

    This is how you do it:

    #define private public
  • (cs) in reply to ZPedro
    ZPedro:
    It is as if H.P. Lovecraft wrote this code to evoke the horrors of That Which Man Was Not Meant To Learn About.
    The CodeSOD Out of Space?
  • (cs) in reply to no laughing matter
    no laughing matter:
    ZPedro:
    It is as if H.P. Lovecraft wrote this code to evoke the horrors of That Which Man Was Not Meant To Learn About.
    The CodeSOD Out of Space?
    On the Dependency Stack of Madness.
  • TenshiNo (unregistered) in reply to GWO

    If you're writing a class library that is designed to be extended and used by others, making something "protected" can make it available to the extending (inheriting) class without confusing the programmer using that library by exposing members that they shouldn't be messing with anyway. Obviously, making something protected does not prevent another piece of software from accessing that member, but you should never be writing your software to do this. It means you're doing things that the original library's designer didn't intend and you could easily cause massive bugs in code that you don't control.

    Captcha: ludus - Ludus put and end to crap code. (I can dream, can't I?)

  • fz (unregistered)

    I got it! TRWTF is that the second argument of getOrSet is not a [b]const[/] reference.

  • anonymous (unregistered) in reply to Smug Unix User
    Smug Unix User:
    Please change ab/used to (ab)used. ab/used reads as either ab or used. (ab)used reads as used or abused.
    It's (ab/)used. As in, either "ab" or "", followed by "used".
  • EmptyJay (unregistered) in reply to no laughing matter

    That story scared the bejeepers out of me. And I only recently realized it was written by Lovecraft. It all made sense when I learned that.

  • (cs) in reply to iWantToKeepAnon
    iWantToKeepAnon:
    Even private in C++ isn't private. I had a 3rd party library with a bug in it and it would have been a simple fix to adjust a member variable except it was private with no accessors. As an individual, I had no clout to get the 3rd party company to pay me any attention.

    So in my wrapper/fixer class, I ignored the 3rd party class header and copied in the class definition and find/replaced all "protected" and "private" declarations to "public" ... and then fixed away. Simple.

    If C++ ordered the memory footprint by protection, then I'd have been hosed. But I created a memory identical declaration and it worked fine. I filed a bug report so I didn't have to maintain the patch forever, but it got me past that obstacle ... I don't remember how long or if the fix ever came in.(?)

    Commit this sentence to memory - "EVERTHING is effectively public."

    I was going to say something along these lines... they didn't need to create a wrapper class, they just needed to slightly modify the new header files from the updated library.

  • (cs) in reply to Avoid protected
    Avoid protected:
    Commit this sentence to memory - "Protected is effectively public."

    Yeah, but when it's protected that makes sure you don't accidentally the data.

  • (cs) in reply to Tinus Lorvalds
    Tinus Lorvalds:
    Yet another set of examples of how OOP has caused more trouble than it's worth. The public/protected/private shit mirrors the bureaucracy of enterprise-ness that systems written in it often contain, "getters" and "setters" whose only purpose is to cause extra indirection in the programmer's mind and the computer, and semi-opaque inflexible inheritance. None of this would be a problem if they'd just used C like any sane programmer would.

    Blaming anti-patterns on the language is like blaming the mistakes of a bad mechanic on his toolbox.

    Remember, you can write Fortran in any language.

  • (cs) in reply to cellocgw
    cellocgw:
    Avoid protected:
    Commit this sentence to memory - "Protected is effectively public."

    Yeah, but when it's protected that makes sure you don't accidentally the data.

    Did you have to go and private the verb?

  • Mason Wheeler (unregistered)

    GetOrSet isn't that bad of a WTF in and of itself; it's merely reflective of the greater WTF nature of the C++ language. In any well-designed language, you'd do something very similar (get or set the value of a member on a class using the same member identifier) with a Property.

    Just saying.

  • anonymous (unregistered) in reply to anonymous
    anonymous:
    Smug Unix User:
    Please change ab/used to (ab)used. ab/used reads as either ab or used. (ab)used reads as used or abused.
    It's (ab/)used. As in, either "ab" or "", followed by "used".
    I prefer [ab]used, as in it was used in an abusive manner.
  • (cs) in reply to populus
    populus:
    Of course, if the vendor ever demoted those now-protected fields and methods to private...
    So these guys will just have to start using Reflection to access the "private" fields and methods.
    I haven't used C++ in 18 years - does it even support the concept of reflection?
  • (cs) in reply to anonymous
    anonymous:
    anonymous:
    Smug Unix User:
    Please change ab/used to (ab)used. ab/used reads as either ab or used. (ab)used reads as used or abused.
    It's (ab/)used. As in, either "ab" or "", followed by "used".
    I prefer [ab]used, as in it was used in an abusive manner.
    Clearly, it should be \(ab\)\?used. Now we have two problems.
  • (cs)
    TFA:
    BaseClass had a list of virtual and pure-virtual methods like so:
    Except that what follows is an array declaration, not a list of methods of any kind. Did you accidentally the whole something during editing?
  • Pooped (unregistered) in reply to Tinus Lorvalds
    Tinus Lorvalds:
    Yet another set of examples of how OOP has caused more trouble than it's worth. The public/protected/private shit mirrors the bureaucracy of enterprise-ness that systems written in it often contain, "getters" and "setters" whose only purpose is to cause extra indirection in the programmer's mind and the computer, and semi-opaque inflexible inheritance. None of this would be a problem if they'd just used C like any sane programmer would.

    OOP is not the problem. Failure to use OOP properly is.

    All the examples here show someone using C++ as if it were C. The virtual function pointers are handled for you in OOP languages like C++.

    obj.message(); is clear and direct. The C++ compiler does it for you with optimization. An equivalent C call requires finding the message function pointer in a table for the type of obj, and passing the struct obj.

  • F (unregistered) in reply to snoofle
    snoofle:
    populus:
    Of course, if the vendor ever demoted those now-protected fields and methods to private...
    So these guys will just have to start using Reflection to access the "private" fields and methods.
    I haven't used C++ in 18 years - does it even support the concept of reflection?

    Well, about four hours before your post (10:32) someone said it doesn't. AFAIK (s)he's correct.

  • (cs) in reply to DaveK

    Hi, the original subscription is from me. I had already written it like an article but, obviously, it has been edited quite a bit. Also, I intended an anonymous posting but it was turned into one with a fake name. Interesting.

    Regarding the vfptr voodoo...

    They mainly did it to have an object of a fixed size which can be stored in an array-like structure and can be switched to various types on the fly, thus, instantly changing the behavior of various virtual methods. The line in question is the allocation for the array where the objects were then initialized in the most manual way possible, including the vfptr patch. I am sure than the designer of this... unconventional... approach was actually proud of it.

    As for the get-or-set anti-pattern...

    In a certain part of the code, written by a certain developer, there was a multitude of GetOrSetX methods - for any conceivable kind of X. The naming of the boolean in the signature was a huge part of the WTF because it was never named so that you could predict the behavior of the method without looking at its implementation. That certain developer actually took it a step further by having two method overloads somewhere which only differed in the sequence of parameters: The one with the pointer and the bool did something quite different than the one with the bool and the pointer. Intriguing, not that helpful but quite hellful. If that's not a word, I'd like to propose it as one.

    As for misusing inheritance to make protected members accessible...

    We had an internal name for this. We called it "legacy hunting". For an unknown reason, our boss liked it more than the "#define protected public" approach.

    Addendum (2014-08-19 18:50): I was replying to this posting:

    DaveK:
    TFA:
    BaseClass had a list of virtual and pure-virtual methods like so:
    Except that what follows is an array declaration, not a list of methods of any kind. Did you accidentally the whole something during editing?
  • MZH (unregistered) in reply to Pooped
    Pooped:
    Tinus Lorvalds:
    Yet another set of examples of how OOP has caused more trouble than it's worth. The public/protected/private shit mirrors the bureaucracy of enterprise-ness that systems written in it often contain, "getters" and "setters" whose only purpose is to cause extra indirection in the programmer's mind and the computer, and semi-opaque inflexible inheritance. None of this would be a problem if they'd just used C like any sane programmer would.

    OOP is not the problem. Failure to use OOP properly is.

    All the examples here show someone using C++ as if it were C. The virtual function pointers are handled for you in OOP languages like C++.

    obj.message(); is clear and direct. The C++ compiler does it for you with optimization. An equivalent C call requires finding the message function pointer in a table for the type of obj, and passing the struct obj.

    For anyone who is annoyed by C++ code written by C programmers: Modern C++

  • Galikor F (unregistered) in reply to Steve The Cynic
    Steve The Cynic:
    The virtual function table thing is the most lethal - there's no guarantee that the vtable pointer is at the beginning of an object, even if the compiler uses vtables for virtual function calling. (Yes, I know, these days they all do, and have done for 20 years, but it isn't required by the standards as far as I know.) If ever you have to compile your C++ using cfront, you'll get a nasty surprise, because cfront puts the vtable at the *end* of the first object in the hierarchy that has one.
    There's no guarantee you'll be alive tomorrow either, so do what you can today.
    Pooped:
    All the examples here show someone using C++ as if it were C. The virtual function pointers are handled for you in OOP languages like C++.
    Then how do you propose doing dynamic inheritance? Hint: C++ is being used as if it were C because doing it the "proper C++ way" would require a much more complex design, or might not even be possible. TRWTF is C++.

Leave a comment on “Inheritance”

Log In or post as a guest

Replying to comment #:

Log Out

« Return to Article