0

I've made a programm with libraries. One library has a interface for to include a header for an extern programm call:

  class IDA{
  private:
      class IDA_A;
      IDA_A *p_IDA_A;
  public:
      IDA();
      ~IDA();
      void A_Function(const char *A_String);
  };

Then I opened the header with Kate and placed

      class IDA_A;
      IDA_A *p_IDA_A;

into the public part.

And this worked?! But why? And can I avoid that?

Greeting Earlybite

Earlybite
  • 137
  • 1
  • 1
  • 11
  • 1
    Don't open the header and move declarations around. Problem solved. – Benjamin Lindley May 27 '15 at 08:02
  • You CAN avoid doing that: just don't do it. About preventing other doing it, I don't think so. – rodrigo May 27 '15 at 08:03
  • 1
    It's unclear to me what you're asking. Are you asking, "why can I modify header files?" Or "how can I avoid modified headers from working?" Or "Why does a public member work when code expects private?" – eerorika May 27 '15 at 08:05
  • See also http://stackoverflow.com/questions/30245091/whats-the-difference-between-type-and-name-in-c – laurisvr May 27 '15 at 08:21

3 Answers3

0

Of course this works. The whole private-public stuff is only checked by the compiler. There are no runtime-checks for this. If the library is already compiled, the user only needs the library file (shared object) and the header files for development. If you afterwards change the header file in the pattern you mentioned, IDA_A is considered public by the compiler.

How can you avoid that? There is no way for this. If another user changes your headerfile, you can do nothing about it. Also is the question: Why bother with it? It can have very ugly side-effects if the headerfile for an already compiled lib is been changed. So the one who changes it also has to deal with the issues. There is just some stuff you dont do. One of them is moving stuff in headers around for libraries (unless you are currently developing on that library).

Nidhoegger
  • 4,973
  • 4
  • 36
  • 81
0

And this worked?!

Yes

But why?

private, protected and public are just hints to the C+++ compiler how the data structure is supposed to be used. The C++ compiler will error out if piece of C++ source doesn't follow this, but that's it.

It has no effect whatsoever on the memory layout. In particular the C++ standard mandates, that member variables of a class must be laid out in memory in the order they are declared in the class definition.

And can I avoid that?

No. In the same way you can not avoid, that some other piece of code static_casts a (opaque) pointer to your class to char* and dumps it out to a file as is, completely with vtable and everything.

If you really want to avoid the user of a library to "look inside" you must give them some handle value and internally use a map (std::map or similar) to look up the actual instance from the handle value. I do this in some of the libraries I develop, for robustness reasons, but also because some of the programming environments there are bindings for don't deal properly with pointers.

datenwolf
  • 159,371
  • 13
  • 185
  • 298
  • That is what I've made...a std::map. But some days ago I've read that it is possible to set the class name with a variable by using it in the cpp-file. But this is (in my case) only worth, if I can "protect" that (e.g. with private: ) Thank you all<!> for those quick and very usefull answers! Thanks! Greeting Earlybite – Earlybite May 27 '15 at 08:19
0

You've got access to the p_IDA_A member variable, and this is always possible in the manner you've outlined. But it is of type IDA_A, which for which you only have a declaration, but not the definition. So you can not do anything meaningful with it. (This method of data hiding is called the pimpl idiom).

Michael Anderson
  • 70,661
  • 7
  • 134
  • 187