malloc array of pointers for platform independence
ProgrammingThis forum is for all programming questions.
The question does not have to be directly related to Linux and any language is fair game.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
malloc array of pointers for platform independence
I have a circumstance where I need to malloc an array of pointers in C++. I wish this code to be platform independent, so I need to specify the size of the array in a platform independent fashion.
On a 32 bit x86 system, the pointer size is the word size (32 bit) but I can't guarantee this is always the case.
Can anyone tell me what type is guaranteed to match the size of a pointer on any platform?
but I am pretty sure that I can't use sizeof(int) as my assurance of the pointer size going forward. I thought of using sizeof(char *) but I don't know if that is valid or will work across all platforms.
I have a circumstance where I need to malloc an array of pointers in C++. I wish this code to be platform independent, so I need to specify the size of the array in a platform independent fashion.
Well you don't really, you could use either of the following.
Code:
char ** osltxt = new char*[nentries];
std::vector<char*> osltxt(nentries,0);
If for some reason you need to use malloc then you can do as jlliagre suggested
I don't really understand the problem. You need the array to unconditionally align at the binary level on all machines, and that array needs to hold pointers to something else, such as C-strings? I'm pretty sure that's not possible unless you do something like this:
Maybe I have misunderstood your requirement and it is as taOkira writes, yet I took the following
Quote:
Can anyone tell me what type is guaranteed to match the size of a pointer on any platform?
To mean what is the size of a pointer on any one machine it is running on, not a universal type across different architectures. As pointers on machine have no correlation to a pointer on a different machine as it has a different address space.
Well you don't really, you could use either of the following.
Code:
char ** osltxt = new char*[nentries];
std::vector<char*> osltxt(nentries,0);
If for some reason you need to use malloc then you can do as jlliagre suggested
Hmmm...
My thought processes are very C-like. Though I have done work on and supported C++ programs in the past, this is the first time I have undertaken a major project in C++. I am doing it because, though it is costing me extra effort for the initial organization (due to my lack of familiarity) I do expect it to make things go a lot faster later on.
I take it that setting my array up this way automatically provides the required platform independence on pointer size? Looks like it would because there is no explicit size specified, unlike in malloc...
OK. Thanks.
From that perspective, is there a more C++ way to handle these two subsequent lines?
Well for a start I would do away with the array of char pointers if the reason for the char pointers was for string and instead use an std::string and a std::vector.
Actually, my plan is to make osltxt static. It is buried in a class and I don't know how big it will be until the first time the class is invoked in the program.
This is a program initialization thing; this array is populated from a text file and will persist for the life of the program. The array contains the text of all messages that are posted in requesters throughout the program.
I am actually getting into a chicken and egg problem defining this as static. I want it to be a private static array but I cannot seem to get that to work. If it is static, I want to load it once then never again even if a new instance of the class is defined (which certainly will happen). Problem is that I can only define a prototype in the class if I make it static, and I have not figured out how to test for the existence of the array before I define storage for it - by which time it is too late.
I would prefer to completely avoid global variables in this program - in fact, that is a design goal - and would prefer to have "pseudo-globals" carried around in relevant classes, but it looks like I might not be able to do that given that this thing has to be defined dynamically.
If I turn this into a global array, then the mechanism you show will work just fine. Doing it in a class where it is private and static requires me to know nentries before I do know nentries, since I obtain that from the file I read in.
*sigh*
edit: Also, for this array I am better off keeping the char * organization because it is all headed for gtk, and this organization is more compatible with gtk. Saves me having to do a conversion as I send it.
I think you misunderstand how to implement a static member. You declare it as static in the class body in the header, then in the source you define it. That allows it to be private and also have a single definition. The definition will have to be in the header instead of the source if you use a template class, obviously.
Code:
//yourclass.hpp
class yourclass
{
static int values[64];
};
Code:
//yourclass.cpp
#include "yourclass.hpp"
int yourclass::values[64];
Ultimately, that is what I figured out. I had tried to declare it static by merely declaring the pointer to it as static, then allocating the actual array dynamically. This doesn't work.
Unfortunately, I do not know the size of the array at compile time so I either have to allocate too much space in order to be static while still retaining some upgrade capability, or I have to find another way.
So now the pointer is defined as a global pointer, and I allocate it and populate it at run time and just treat it like any other C pointer.
It'll do. Since all the data goes to gtk, keeping it as a C pointer and a C array actually makes a lot of sense.
It works perfectly well, but once again malloc is in play. (I like malloc and calloc )
Are you sure these lines work that well ?
I may be wrong as I avoid C++ as much as I can but it looks incorrect to me not to allocate one extra character for a null string terminator and not to set that character.
Are you sure these lines work that well ?
I may be wrong as I avoid C++ as much as I can but it looks incorrect to me not to allocate one extra character for a null string terminator and not to set that character.
Good catch. I did in fact have to do that. Then I changed to code to this:
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.