There is a function

double funct(double);

It contains a call to some other functions. But they should be hidden by everything except this “main” function. How?

  • And who prevents them from being hidden "by agreement"? But since such a need has arisen, can this function be made a class method? and the necessary hidden ones are private. - KoVadim
  • 2
    Make the class StaticHelperClass , which will contain only static functions, declare it static double funct(double); as public, and auxiliary static functions make private. - Costantino Rupert
  • 3
    What does it mean to everything? You yourself should not see anything in the editor? Or what If the functions should not be visible outside the given translation unit, then there is a static descriptor - alexlz
  • 2
    The linker cannot find the function in the cpp file. He doesn't eat that. It works with object modules (translation results) and libraries (object module associations). In reality, the picture is somewhat more complicated, but now it doesn’t matter - alexlz
  • 2
    @iofjuupasli, you first answer why do you need this paranoia at all? . What degree of non-callback do you want to provide? For example, if there is a symbol table in the load module, then any (including static) function can be called, for example, using the techniques used by the debugger. In reality (in a large project) you just have to strive to avoid accidental intersection of names with other developers (including third-party libraries). - avp


3 answers 3

In my opinion, a standard solution is appropriate here. It consists in the fact that two files are created:

my.h

 #include <stdio.h> .... // столько инклюдов, сколько нужно // сделать guardian для единичного включения include-файла!!! // стандартно - через define-ifdef или pragma double funct(double); // прототип нашей ф-ции // не уверен, но возможно понадобится запись extern // для включения my.h в проект потребителя

my.cpp

 #include <my.h> .... // код всех вспомогательных ф-ций double funct (double) {...} // код нашей ф-ции

If paranoia tortured - all auxiliary functions can be made static , i.e. they will only be available from my.cpp . Another option is not to distribute the my.cpp file to consumers, but provide them with an object module (obj file) or library (lib file).

An even more tricky method is to compile a dynamic library with the funct function so that it is in the export table ... Then the library guts will not be accessible from the outside (at least without tricks). This is probably good if you need to implement the concept of a black box. But is it necessary to dodge like that?

An interesting technique for restricting access from other modules is to use an unnamed namespace. Like or so

In general, it would be nice if the author of the question still told why he needed such a concealment ...

  • I already came out pointing out this decision, as well as the fact that the question was posed incorrectly. (on the other hand, everyone turned back and joked) - iofjuupasli

It can be so pretty cheap:

 class MyPublic{ void funct( ... ){ return static_cast< MyPrivate* >( this )->priv_funct( ... ); } };

In some godforsaken namespace (which MyPublic should not forget), or directly in the funct'е , if the code is not too cumbersome:

 class MyPrivate : public MyPublic{ void something_hidden( ... ){ ... } void priv_funct( ... ){ return something_hidden( ... ); } };

Only MyPrivate should not add any data to the ancestor, otherwise it will have to be taken into account. You can play with the inheritance access modifier, but if the goal was to get rid of helper methods in tools, like IntelliSense , then that would be enough.

  • one
    Nekruto, that in this case, the base class begins to know something about its derived classes. - Costantino Rupert
  • Only about those who implement its functionality. I'm not sure that they can be called complete descendants, they have no body of their own, these are phantoms :) - mega
  • Perhaps it is better to use dynamic_cast? - skegg
  • > Maybe it's better to use dynamic_cast? dynamic_cast is a search among physically-generated class vertices that are associated with vmt . Those. This is a search in a real object, and here is a "phantom". It will only be found if the MyPrivate object MyPrivate actually created. Yes, and painfully, this is an expensive method - it is clearly no better. - mega

Can be done as an inline function (based on the discussion )

 void func () { struct hider { static void hidden_function() { //something } }; void (*hf) () = &hider::hidden_function; hf(); }
  • one
    And its address can be encrypted and stored on the server, receiving from there upon presentation of the secret password immediately before the function is called, and after the call the local copy is immediately erased. Users have already queued for new multi-core gigahertz and gigabytes. - avp
  • The joke is good. - gecube
  • one
    > and after calling the local copy immediately wipe No way, the local copy is the last century. Now the function itself is stored on the server, to which only the parameters are transmitted upon presentation of the secret password. The server calls the function and returns the result. [remembered "Hello World" @alexlz] :)) - mega
  • @mega well, just RPC - they are from the last century. And even from the past millennium. And even before the COM technologies from MS (which are just RPCs that are used) - alexlz
  • > just RPC - they are from the last century. Exactly! I forgot! In this millennium, we will deploy a virtual machine with a dynamically changing machine pseudo-language by Hemida and pass the parameters into it, and better - we will invest 10 such machines. - mega