Organizing & Splitting Libraries

Projects Programming
1

I have a library ExLib and its grown to be a relatively long file. In ExLib_Class there are a lot of const variables in the file that define things like physical constants, device constants, and configuration parameters. To try and make ExLib.h shorter and more readable, I think I want to move these constants to a separate ExLibConfig file. But I also want to make sure these constants are not visible outside of the library. Is there a good way to do this or am I asking for trouble?

I've seen a few things that suggest simply placing the constants in a ExLibConfig.h file and putting #include "ExLibConfig.h" at the top of ExLib.cpp and ExLib.h. And others talking about unnamed namespaces, both methods seemingly relying on the scope of the local translation unit to ensure the variables in ExLibConfig.h are only visible inside the library. But I'm not sure of the impact of any of these methods.

2

just include this file at the top of ExLib.cpp and not in ExLib.h.

Alternative - if this a class members - declare it as "private"

3

Put the constants into their own header file which you include only in the library file. E.g. ExLib.cpp:

#include <ExLib.h> //public header
#include "ExLibConfig.h" //private constants
...
4

On the surface that makes perfect sense to me, but how to I ensure that those variables won't be visible in the main code? This is my understanding of what that would look like. As separate files:

"ExLibConfig.h"
const uint8_t const1 = 5;

"ExLib.h"
class ExLib_Class { void func1(); }

"ExLibConfig.cpp"
#include ExLibConfig.h
#include ExLib.h

ExLib_Class::func1() { return const1; }  //Can't access const1 here

But after preprocessing:

"After preprocessing"
const uint8_t const1 = 5;
class ExLib_Class { void func1(); } //Can't access const1 here
ExLib_Class::func1() { return const1; }

Is this right? If so, its not obvious to me why const1 is visible in the .cpp but not in the .h or the main code. I do want the constants to be visible in the header.

5

Rename the cpp file into the library name ExLib.cpp.

Missing "void" type at begin of line.

6

Perhaps because you included it in the .cpp and not in main code, isn't it?

7

The name of the file doesn't matter

8

My understanding of the preprocessing stuff is just that everywhere there's an #include line, the text from the file being included is copy pasted to replace the #include line. Which would mean the declaration of const1 is before ExLib_Class and would be assessable to it.

I understand you're implying that it doesn't work like this but I don't know why.

Also just to reiterate, I do want the constants visible in both the header and cpp file.

9

correct

you misunderstood me

In that case it will be visible in main code too.

11

So if this is the case, the constant file text would go into the cpp file text, which would go into the header file text, which would go into the sketch ino file text. So if all the text ends up in the same file, why are the constants not visible in the main sketch or the header?

Can you explain how then?

OK so it sounds like this method doesn't work

12

No, . cpp files are not included in any way to the other files. Each . cpp file compiles separately.

1 Like
13

If you want to make constants not visible outside the library, you should use them in library . cpp file only and not in library header. There is no way to make constants visible in the header and not visible in the . ino, which includes this header.

14

That is indeed the hole point of using a header *.h file.

I've just assigned myself some beach reading. I know nothing about this, but when looking into how one might be able to hide stuff not normally hidden, there's this.

https://wiki.c2.com/?PimplIdiom

Sry if it was mention upthread.

Mostly ppl don't go to great lengths like that.

a7

15

The whole point of using multiple header files.

If you want variables or values (constants) invisible in user code (INO file) then put these declarations in a dedicated private header file.

If a user can include the private header file then it also can inspect the CPP file and explore all secrets written up there.

A chance for hiding secret code parts is compilation and distribution of only the binary code and public header files, but even then some nerd may be able to extract all secrets from the object files.

From a discussion decades ago I remember one statement:
If a commercial program is protected by kind of a paid license key then this will invite all hackers to crack that protection. Humans are curious and enjoy hunting for lost or hidden treasures.

1 Like
16

How does the structure of multiple headers work? I tried putting #include "constants.h" in the main header but that made the constants visible in the INO.

Also just to be clear, I'm not really looking to "hide" anything from the user I really just want to know how to better organize the library files that are getting too long. The desire to not have the constants show up in the sketch code is just to avoid cluttering.

17

You can include only the required headers and omit all others.

The content of #included files is not visible in the sketch code.

19

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.