will two static libraries share the same heap or not?

Jazi

Hi All,

I made a copy of a static library from an open-source code and changed its name to something different. In my driver I linked to both of these libraries. My question is will the global variables declared in these libraries step over each other or they will occupy two different heaps?

I have already test and they seems to be using the same heap since my global variables keeps getting the same data. To be honest with you, my understanding that since I am using two different libraries each library will occupy different heap or stack, is this true? I would appreciate if some one can explain this to me

Some people might ask why in the world I am doing this. It is because I am too lazy to dig into this code and try to change its structure to fit my need. Believe me I tried to do that and after working on it for two weeks I found out that I need to make too many changes. And there is always new version of it. So it would be nightmare to do so everytime there is new version. So I am trying to find an easy solution out of this and it seems there is none.

Please any kind of hints or help will be highly appreciated.
Jaz

weaknessforcats

Gobal variables share the same scope regardless of whether or not they are defined in a library. When they have the same name your build dies with duplicate definitions.

All of the variables reside in a portion of memory rerserved for global variables. That is, they are not on the stack nor are they on the heap.

To be on the stack, the variable must be defined inside a function. To be on the heap, the variable must be allocated from inside a function.

The global can be defined as static but this just restricts the problem to the one file that defines the global. A static global variable can use used only in the file that defines it.

One solution is to not use any global variables in your code that are not in a namespace. If you code this way:

Expand|Select|Wrap|Line Numbers

 
namespace jazi

{

     int thedata;

}

this variable is identified as jazi::thedata whereas a variable outside the name space is just thedata. At least that would separate your stuff from the library.

I am assuming you are coding in C++ because if this is C, you are dead. With C, you have to a) make all of your global variables static and pack all your code into one source file, or b) rename all of your global variables so they are different from the library's and hope no one reuses one of your names.

Global variables are among the worst code practices known to man.

Jazi

Quote:

Originally Posted by weaknessforcats

Gobal variables share the same scope regardless of whether or not they are defined in a library. When they have the same name your build dies with duplicate definitions.

All of the variables reside in a portion of memory rerserved for global variables. That is, they are not on the stack nor are they on the heap.

To be on the stack, the variable must be defined inside a function. To be on the heap, the variable must be allocated from inside a function.

The global can be defined as static but this just restricts the problem to the one file that defines the global. A static global variable can use used only in the file that defines it.

One solution is to not use any global variables in your code that are not in a namespace. If you code this way:

Expand|Select|Wrap|Line Numbers

 
namespace jazi

{

     int thedata;

}

this variable is identified as jazi::thedata whereas a variable outside the name space is just thedata. At least that would separate your stuff from the library.

I am assuming you are coding in C++ because if this is C, you are dead. With C, you have to a) make all of your global variables static and pack all your code into one source file, or b) rename all of your global variables so they are different from the library's and hope no one reuses one of your names.

Global variables are among the worst code practices known to man.

I really appreciate your feedback and it makes a lot of sense. However, here is my situation.

I am using an open source code. I really do not want to make changes to the code at all. If possible then I will rather do the minimum. So the namespace thing you mentioned above makes a lot of sense and I thought about it but it will require a lot of changes into the current version. Here is what I have and here where the issue reside.

There are two headers in this package; globs.h and exts.h. The globs.h contains the declaration and initialization of this variable as
//globs.h
int thedata=0;

This header is included by ONE source code that have a function which upload the data from the files into these variables.

The second header exts.h is a mirror of the globs.h except the word "extern" added to each global variables in globs.h

//exts.h
extern int thedata;

This file is included by all the other functions (source files).
Now, I thought if I get rid of the "extern" word from the exts.h then this will work "stupid assumption" it fails so I thought of getting rid of the whole exts.h and include the globs.h instead but I got the duplication definitions issue as you mentioned above.

Is there a quick fix to this problem besides the one you mentioned above.

Best regards,

weaknessforcats

I say again, bite the bullet and use a namespace to isolate you from that open source.

I had this problem once. I had a global variable named GROUP. In my case it was the group number of the employee in the empoyee database. I had a lot of code invested in this. At one point someone thought that using Microsoft sockets was a good idea. That's when everything stopped compiling. Turns out the nitwit at M$ was using GROUP to represent a group of sockets.

Three months later I had all my stuff in a namespace and big scar that reminds me to never, ever, use a global variable.

This is the reason that namespaces were put into C++.

Ideally, you would handle all this global stuff using a Singleton object but a namespace is enough of an improvement to warrant using one. The Singleton won't appeal until global variables are outlawed in your development area.

Jazi

Quote:

Originally Posted by weaknessforcats

I say again, bite the bullet and use a namespace to isolate you from that open source.

I had this problem once. I had a global variable named GROUP. In my case it was the group number of the employee in the empoyee database. I had a lot of code invested in this. At one point someone thought that using Microsoft sockets was a good idea. That's when everything stopped compiling. Turns out the nitwit at M$ was using GROUP to represent a group of sockets.

Three months later I had all my stuff in a namespace and big scar that reminds me to never, ever, use a global variable.

This is the reason that namespaces were put into C++.

Ideally, you would handle all this global stuff using a Singleton object but a namespace is enough of an improvement to warrant using one. The Singleton won't appeal until global variables are outlawed in your development area.

You mentioned before "All of the variables reside in a portion of memory rerserved for global variables. That is, they are not on the stack nor are they on the heap." Does this portion of memory have a specific name? Also, can you recommend me where to go and find more about this. My coworker does not seems to believe this is accurate.
Regards,
Jaz

Banfa

Quote:

Originally Posted by Jazi

You mentioned before "All of the variables reside in a portion of memory rerserved for global variables. That is, they are not on the stack nor are they on the heap." Does this portion of memory have a specific name? Also, can you recommend me where to go and find more about this. My coworker does not seems to believe this is accurate.

It would commonly be called the "data section" and contains initialised global data, uninitialised data resides in the BSS section and these 2 sections along with the heap make up the data segment of the program, as explained by wikipedia.

You should note that this is a typical memory configuration for a platform, not the configuration that absolutely every platform uses. You should check your platform/compiler documentation to see exactly what segments/sections exist for your platform.

The terms segement and section are used rather ambiguously and interchangable when refering to areas of memory used by a program which sometimes reside inside other areas.

Jazi

Thank you Sir for your clear and prompt responses.

Here is what I did and I am not sure this is exactly what you meant when you said "use a namespace to isolate you from the opne source".

As I mentioned before all the global variables used in this open source are found in two header files:
//globs.h
...
int thedata=0;
...

The second header exts.h is a mirror of the globs.h except the word "extern" added to each global variables in globs.h

//exts.h
extern int thedata;
...

What i did was to use namespace in the globs.h as follow
namespace myspace{
int thedata=0;
...
}
Then removed the exts.h and include the globs.h everywhere. I got the duplication definition errors.

Then I went back to your email and it looks like you meant I should build a wrapper around the open-source without making any changes to it. To tell you the truth I already did build a class wrapper around it but to explore certain functions from the package not the global variables. This is how I come to know about these global variables.

Frankly, I am not really clear on how to use the namespace to isolate me from the open-source in this case. Would you mind giving me a quick example no how to do that?

Thank you,
Jaz

weaknessforcats

Quote:

Originally Posted by Jazi

Frankly, I am not really clear on how to use the namespace to isolate me from the open-source in this case. Would you mind giving me a quick example no how to do that?

That's a fair question.

I will make some assunptions:
1) there is open source code that I cannot control
2) this open source uses global variables
3) I need to use those global variables also
4) I do not want any globals I use confused with the open source globals.

Step 1:
Do not make any changes whatsoever to the open source code.

Step 2:
Create a namespace for my globals.

Let's call it the Jazi namespace. In one of your source files:

Expand|Select|Wrap|Line Numbers

 
namespace Jazi

{

    int SameNameAsOpenSourceGlobal;

}

Step 3:
Create a header to access both yours and the open source global:

Expand|Select|Wrap|Line Numbers

 
extern int ::SameNameAsOpenSourceGlobal;  //the open source global

extern int Jazi::SameNameAsOpenSourceGlobal; //your variable of the same name

This line:

Expand|Select|Wrap|Line Numbers

extern int ::SameNameAsOpenSourceGlobal; //the open source global

couly be replaced by the #include of the open source header file.

Step 4:

In your code just use the correct name.

This also works for functions.

Remember: with a namespace when you define a variable it is created in that namespace. If you do this in a header file, you will have a variable created every time you inlcude the header and this will cause duplicate definitions.

Header files are not to contain actual variables but only declarations about those variables.

Jazi

Quote:

Originally Posted by weaknessforcats

That's a fair question.

I will make some assunptions:
1) there is open source code that I cannot control
2) this open source uses global variables
3) I need to use those global variables also
4) I do not want any globals I use confused with the open source globals.

Step 1:
Do not make any changes whatsoever to the open source code.

Step 2:
Create a namespace for my globals.

Let's call it the Jazi namespace. In one of your source files:

Expand|Select|Wrap|Line Numbers

 
namespace Jazi

{

    int SameNameAsOpenSourceGlobal;

}

Step 3:
Create a header to access both yours and the open source global:

Expand|Select|Wrap|Line Numbers

 
extern int ::SameNameAsOpenSourceGlobal;  //the open source global

extern int Jazi::SameNameAsOpenSourceGlobal; //your variable of the same name

This line:

Expand|Select|Wrap|Line Numbers

extern int ::SameNameAsOpenSourceGlobal; //the open source global

couly be replaced by the #include of the open source header file.

Step 4:

In your code just use the correct name.

This also works for functions.

Remember: with a namespace when you define a variable it is created in that namespace. If you do this in a header file, you will have a variable created every time you inlcude the header and this will cause duplicate definitions.

Header files are not to contain actual variables but only declarations about those variables.

Assumptions 1 and 2 are correct, assumptions 3 and 4 are not. The problem is not I want to use the same global variables somewhere in my code. The issue is that I have two sets of data used by this package. Each data set gets uploaded from files using especial function and get stored at these global variables. The program runs fine serially:
Meaning:
Load data set1 into global variables
do whatever
Then, load data set2 "the global variables get the new values"
do whatever.
Then keep going if I need to use data set1 again ...

What I have been trying to do is to write a class wrapper that will have two instances one for dealing with data set1 and the other for data set2. The process should be alive until I kill without having to reloading from files. But this does not work because of the global variables .

I hope this clear now. I did not try to say this when I first posted this thread because it would have confused people.

It looks like having two libraries with two different global names is the solution for me at this point. What do you think?

I appreciate your help.

will two static libraries share the same heap or not?

re: will two static libraries share the same heap or not?

re: will two static libraries share the same heap or not?

re: will two static libraries share the same heap or not?

re: will two static libraries share the same heap or not?

re: will two static libraries share the same heap or not?

re: will two static libraries share the same heap or not?

re: will two static libraries share the same heap or not?

re: will two static libraries share the same heap or not?

Similar C / C++ bytes

/bytes/development

/bytes/it

/bytes/about