undefined | Better HN

0 pointsAnimalMuppet8y ago0 comments

About your two realizations:

1. I've "exposed" parts of the private implementation in that they were in the header file, yes. They were also labeled "private". That means that someone can read that and gain more information about my implementation then they could from just public information, I suppose. It also means that nobody can actually use them in code, because they're private. So you can think of that as "exposing" if you want, but it's not something that I've ever recognized as any kind of a problem, let alone one worth solving.

2. If you change only the private parts of the class and try to link other code to it without recompiling the other code, yes, you can get a broken compiled binary. That is certainly true. But I could do that in C almost as easily (if everything that uses the struct layout isn't in the same source file). And makefiles that keep track of dependencies aren't exactly rocket science. Neither are clean builds.

Maybe I just don't have your problems, but I'm still not seeing this as much of an issue at all.

0 comments

yason8y ago

Maybe I just don't have your problems, but I'm still not seeing this as much of an issue at all.

Surely problems are always personal, this all did start with the term "pet peeve".

For me, one of the peeves that comes back over and over is indeed that it seems that's near impossible to write a separation between the API and the implementation in C++ that is clean and beautiful. That's one of the first things in any project, drafting out the interfaces. And things get ugly quick there.

There are others but I drafted this particular case as an example that you requested. I don't want to go too deep into the discussion here but I'll reply to the two points below:

1) Exposing fields and functions under the private label is just a matter of principle. It doesn't matter if the private parts cannot technically be used outside the class: it still means there is information in the public API that shouldn't have to be there in the first place. That's just a stupid restriction of quirky language. A header file is mainly about the interface and its documentation: the last thing I want in it is to have cluttering bits of internal crap there only to be skipped over.

I could also cram all the code in a single source file and use global variables because hey, it can be made to work and it's easier to write a linker that way. The same applies with the public interface issue here.

2) Check back my C header file again. The struct layout is only visible to the implementation. As long as the ABI stays the same we can even use a different compiler to build the private implementation into a binary and the interface still works with all existing code.

Yet this is still about the fact that the private bits do not have to be visible to the public, just the implementation. So the language that forces me to do just that for the sake of convenience for the language designer and compiler writers is just plain stupid.

jcelerier8y ago

> So the language that forces me to do just that for the sake of convenience for the language designer and compiler writers is just plain stupid.

Nothing prevents you from getting the same ABI hiding in C++, but the users of your code will greatly benefit: no possibility of memory leaks, ownership is enforced since copy & move are disabled, etc:

    /// Adder.hpp ///
    struct Adder {
      public:
        Adder(int, int);
        ~Adder(); 
        
        int operator()();

      private:
        struct Impl;
        std::unique_ptr<Impl> impl;
    };

    /// Adder.cpp ///
    struct Adder::Impl { 
        // your private stuff
    };

    Adder::Adder(int x, int y)
      : impl{std::make_unique<Impl>(x, y)} { 
      
    }

    Adder::~Adder() = default; 

    int Adder::operator()() { 
      return impl->stuff * 2;
    }

    /// main.cpp ///

    int main() {
        Adder adder{1, 2};
        return adder();        
    }

    /// your main.c ///

    int main(int argc, char** argv) {
        struct Adder* adder = adder_create(); // must not forget
        adder_setup(adder, 1, 2); // must not forget
        int res = adder_operate(adder); // note how all lines are longer
        adder_delete(adder); // must delete
        return res; // we had to introduce a specific variable just for the sake of keeping the return value else we wouldn't be able to delete
    }

Of course, your code wouldn't pass code review in either cases: introducing indirections through implementation hiding like this kills performance, in C and C++ likewise. And it's not like hiding your stuff in another object file will prevent anyone from knowing your impl... disassembly & code recreation tools are extremely powerfuls nowadays.

j / k navigate · click thread line to collapse