• (cs) in reply to MZH
    MZH:
    For anyone who is annoyed by C++ code written by C programmers: Modern C++

    I'm pretty sure that you're looking for this.

  • QJo (unregistered) in reply to chubertdev
    chubertdev:
    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.

          DO 10 I = 1, NAUSEAM
             PRINT *, 'THERE''S NOTHING WRONG WITH FORTRAN!'
      10  CONTINUE
    
  • QJo (unregistered) in reply to QJo
    QJo:
    chubertdev:
    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.

          DO 10 I = 1, NAUSEAM
             PRINT *, 'THERE''S NOTHING WRONG WITH FORTRAN!'
      10  CONTINUE
    

    Sorry, I forgot a detail (long time since I used the language properly):

          DO 10 I = 1, NAUSEAM
             PRINT *, ' THERE''S NOTHING WRONG WITH FORTRAN!'
      10  CONTINUE
    
  • Norman Diamond (unregistered) in reply to ZPedro
    ZPedro:
    It is as if H.P. [...] wrote this code to evoke the horrors of That Which Man Was Not Meant To Learn About.
    Naturally. Where did you think Microsoft inherited their coding style?
  • TSA (unregistered) in reply to iWantToKeepAnon
    iWantToKeepAnon:
    Commit this sentence to memory - "EVERTHING is effectively public."
    We know. And we have the videos to prove it.
  • facilisis (unregistered) in reply to Galikor F
    Galikor F:
    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++.
    I think we've found the WTF coder.
  • ¯\(°_o)/¯ I DUNNO LOL (unregistered) in reply to spezialpfusch
    spezia:
    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.
    Except that he should have been ashamed, because stuffing the vptr is not the way to do it. Placement new() is. For one thing, constructors are never called. Here is the way I did it (anonymized), and yes it should work with CFront:
    class Widget {
        ...
        void * operator new(size_t sz, void *p) { return p; } // placement new operator
        ...
    };
    
    class Wgt_Type_One : public Widget ... // etc.
    
    enum {
        WGT_NONE, // for a default that can assert(false)
        WGT_TYPE_ONE,
        WGT_TYPE_TWO,
        WGT_TYPE_THREE,
        // etc.
    } widget_id_t;
    
    typedef union {
        char wgt[sizeof(Widget)];
        char one[sizeof(Wgt_Type_One)];
        char two[sizeof(Wgt_Type_Two)];
        char three[sizeof(Wgt_Type_Three)];
        // etc.
    } wgt_stg_t;
    
    class Widget_Holder {
        ...
        static wgt_stg_t widgets[N];
        ...
    };
    
    Widget *Widget_Holder::Morph_Widget(Widget *wgt, widget_id_t type)
    {
        // initialize the object to zero
        // (in this case the objects didn't use destructors)
        // this is probably not the best way to do this
        memset(wgt, 0, sizeof(wgt_stg_t));
    
        // construct the new object with placement new
        switch (type) {
            default:
            case WGT_NONE:       new(wgt) Widget(); break;
            case WGT_TYPE_ONE    new(wgt) Wgt_Type_One();   break;
            case WGT_TYPE_TWO:   new(wgt) Wgt_Type_Two();   break;
            case WGT_TYPE_THREE: new(wgt) Wgt_Type_Three(); break;
            // etc.
        }
    
        return wgt;
    }
  • mrbl (unregistered)

    Why such a complicated approach to accessing protected members? C++ provides us with a simpler solution which, by the way, allows accessing private members as well:

    #define private public #define protected public

  • (cs)

    I know of one vendor, whose response to a customer needing access to something that was private, told the customer to just #define private public

  • psuedonymous (unregistered)
    Real programmers™ with any real experience in OO languages will immediately think "OK, we can just wrap the protected stuff with our own classes and continue to access the formerly public stuff as before."
    No, Real Programmers will rewrite the obviously sub-par code in a proper language: FORTRAN.
  • Tux "Tuxedo" Penguin (unregistered) in reply to Nagesh
    Nagesh:
    C++ is like SHOTGUN.
    Pascal is like SCALPEL.
  • (cs) in reply to Tux "Tuxedo" Penguin
    Tux "Tuxedo" Penguin:
    Nagesh:
    C++ is like SHOTGUN.
    Pascal is like SCALPEL.

    JAVA is like precision tool used in cataract removing surgery. Pray that you never get cataracts.

  • (cs) in reply to ¯\(°_o)/¯ I DUNNO LOL
    ¯\(°_o)/¯ I DUNNO LOL:
    Except that he should have been ashamed, because stuffing the vptr is not the way to do it. Placement new() is.
    I couldn't agree more. Unfortunately, the original developer was one of the company owners (not 100% sure which one). Trying to fix the boss's code is always a challenge for a developer's diplomatic skills. ;-)
  • S (unregistered) in reply to Pooped
    Pooped:
    OOP is not the problem. Failure to use OOP properly is.

    And that's pretty much the story of TDWTF. The problem is almost never the technology, except to the extent it facilitates stupid coding. The real problem is the developers who should never be allowed near a keyboard...

  • (cs) in reply to S
    S:
    Pooped:
    OOP is not the problem. Failure to use OOP properly is.

    And that's pretty much the story of TDWTF. The problem is almost never the technology, except to the extent it facilitates stupid coding. The real problem is the developers who should never be allowed near a keyboard...

    No, Java and PHP are TRWTF when used...

  • Tom G. (unregistered) in reply to Tinus Lorvalds

    "Getters" and "setters" is a good sign that the code is not OOP.

  • The Fury (unregistered) 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.

    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."

    You could have just done #define private public

    Anwyay, there is a way of hiding implementation completely. Have a pointer to another class which the user of the library knows nothing about.

  • (cs)

    Or you could simply:

    #define private public

    I'm really surprised no one has pointed this out before now.

  • (cs)
    By overwriting a given pointer with the value from a different subclass, you could completely change all the virtual functions that would be invoked for that particular subclass.
    So... they invented JavaScript?
  • Peter Wolff (unregistered)

    What is this called?

    Peculiar Object Oriented Programming?

Leave a comment on “Inheritance”

Log In or post as a guest

Replying to comment #:

« Return to Article