A Way in C++ to Hide a Specific Function

a way in c++ to hide a specific function

If you want to selectively hide functions from B it does not make much sense to use public inheritance in the first place.

Use private inheritance & selectively bring methods from B into the scope of A:

struct B{
   void method1(){};
   void method2(){};
};
struct A : private B{
   using B::method1;
};

A a;
a.method1();
a.method2(); //error method2 is not accesible

C/C++ - Hide C or C++ function code from other people

If compiled remember it can be de-compiled.

The only way you can do this is probably to set up a web service that you host (or, more likely, a cloud service that you pay for).

Also remember that you are going to be maintaining this indefinitely, You might want to negotiate a maintenance fee.

Windows and Linux with c cross platform. How to hide a function?

You can place #ifdef #else inside the function you want both in windows & linux. like something following

void unifiedFunction()
{
    #ifdef _WIN32
        //windows specific implementation goes here
    #elif
        //other platform like linux
    #endif

}

In my repository i have a same issue when bringing platform independency. You can check my implementation here

Hiding specific implementation of C++ interface

You can use a factory.

Header:

struct Abstract
{
    virtual void foo() = 0;
}

Abstract* create();

Source:

struct Concrete : public Abstract
{
    void foo() { /* code here*/  }
}

Abstract* create()
{
    return new Concrete();
}

Is it possible to hide a portion of a standard header (in C)?

struct myfile_s {
   void *pPrivateThings; // This could be the FILE* or another private structure
   char *filename;
   char buff[100];
} myfile;

I would allocate another private structure on creation:

struct myprivatefile_s {
    FILE *F;
    // You could add other fields here that are not public
} myprivatefile;

myprivatefile *privateThings = malloc(sizeof(myprivatefile));
myfile.pPrivateThings = privateThings;
privateThings->F = fopen(); 

That way you can keep on adding things that aren't required to be visible (i.e. private) to your heart's content.

Hiding internal type

I suggest you read more about opaque data types, and consider e.g. the FILE structure.

In short, don't split your structure into "public" and "private" variants (that way lies madness and possible undefined behavior). Instead just declare a structure in a public header file, and have your functions return pointers to that structure or accept arguments that are pointers to that structure.

Then internally in the library you have a private header file which have the definition of the structure, and use that header file for your implementation.

---

Simple example

Public header file

#ifndef PUBLIC_HEADER_FILE_H
#define PUBLIC_HEADER_FILE_H

typedef my_private_structure MY_PUBLIC_TYPE;

MY_PUBLIC_TYPE *mylib_create(void);
void mylib_destroy(MY_PUBLIC_TYPE *ptr);

#endif

Private header file

#ifndef PRIVATE_HEADER_FILE_H
#define PRIVATE_HEADER_FILE_H

#include "public_header_file.h"

struct my_private_structure
{
    // Some private fields here
};

#endif

Private library source file

#include "private_header_file.h"
#include <stdlib.h>

MY_PUBLIC_TYPE *mylib_create(void)
{
    MY_PUBLIC_TYPE *ptr = malloc(sizeof *ptr);
    return ptr;
}

void mylib_destroy(MY_PUBLIC_TYPE *ptr)
{
    free(ptr);
}

You distribute public_header_file.h together with your library. It's the header file that the users of the library will use.

The source of your library, and especially the private_header_file.h file should not be distributed, or at least not installed if you make an open-source library.

Note that this scheme make all of the structure "private", which is usually a good idea since then you can modify it as you like without the users of the library needing to rebuild their applications using your library. To access members of the private structure you can use functions which simply returns the value of whatever member needs to be accessed.

Hide functions and global variables in the header file

Although you can put executable code in a header file, a good practice is to have your header file only contain declarations (for global variables) definitions and function prototypes. If you don't want to give your source code implementation, then you need to compile your functions into object code and provide the object file (either as a static archive or shared library) along with the header file. Whoever wants to use your function will then link his/her program to your objecet file/shared lib. This way, you can keep your source code implementation to yourself. Your header file would be:

#ifndef __SOME_MACRO_TO_PREVENT_MULTIPLE_INCLUSION__
#define __SOME_MACRO_TO_PREVENT_MULTIPLE_INCLUSION__

    int find_determinant();

#endif

Beware of multiple inclusion problems (I have shown above how to avoid this so that if your matrix.h file is included several times, programs will still compile).

---

Related Topics