allocating memory with malloc

Hello,

I am just wondering about this line.

As unsigned int is 4 bytes. Am I creating a block of 3 unsigned int.

So the pointer will contain 3 blocks of unsigned int's?

Code:

---

ptrVP = (unsigned int*) malloc(NUMBER_OF_PORTS * sizeof(*ptrVP));

---

Also do I need to dereference the pointer sizeof(*ptrVP)?

Code:

---

static const unsigned int NUMBER_OF_PORTS = 3;
typedef unsigned int *pVPGroups;
 
int main(int argc, char** argv)
{
        pVPGroups ptrVP;
        int size = sizeof(ptrVP);

    ptrVP = (unsigned int*) malloc(NUMBER_OF_PORTS * sizeof(*ptrVP));

        size = sizeof(ptrVP);
        return 0;
}

---

Many thanks,

First of all, this isn't C++, it's C.
Secondly, don't cast the return value of malloc.
Thirdly, initialise all your variables!

Also, I wouldn't ever put a * into a typedef, but that might just be me.
Yes, you'll need the dereference operator in the sizeof() call. Otherwise sizeof will return the size of the pointer (which on most 32-bit OS is 4 bytes). In this case however, it makes no difference, since your unsigned int is most probably also 4 bytes, so in either case size will contain 4.

QuantumPete
P.S. Interestingly, you can dereference a NULL pointer if you use it in a sizeof() call. :)

Quote:

---

Originally Posted by QuantumPete

Also, I wouldn't ever put a * into a typedef, but that might just be me.

---

I concur.

Quote:

---

Yes, you'll need the dereference operator in the sizeof() call. Otherwise sizeof will return the size of the pointer (which on most 32-bit OS is 4 bytes). In this case however, it makes no difference, since your unsigned int is most probably also 4 bytes, so in either case size will contain 4.

---

But still bad practice and will break the code if the size of the data type you use changes (ie switching from int to short).

Quote:

---

P.S. Interestingly, you can dereference a NULL pointer if you use it in a sizeof() call. :)

---

Yes, sizeof merely evaluates the argument, not actually executing it...
So it sees var and evaluates its type, and if you put * before a var of type T*, then it is simply evaluated as T.

Hello,

Maybe I am not too clear.

But is this code creating a pointer to an array of 3 unsigned int objects?

Code:

---

ptrVP = (unsigned int*) malloc(NUMBER_OF_PORTS * sizeof(*ptrVP));

---

I was compiling on CodeBlocks GCC. I got a compile error as I didn't cast.

Anyway I thought malloc returns a void*. I know that using void* is bad practice.

Thanks,

Hello,

Maybe I am not too clear.

But is this code creating a pointer to an array of 3 unsigned int objects?

Code:

---

ptrVP = (unsigned int*) malloc(NUMBER_OF_PORTS * sizeof(*ptrVP));

---

I was compiling on CodeBlocks GCC. I got a compile error as I didn't cast.

Anyway I thought malloc returns a void*. I know that using void* is bad practice.

Thanks,

Quote:

---

Originally Posted by QuantumPete

Also, I wouldn't ever put a * into a typedef, but that might just be me.

---

It's just you. Try to declare a pointer to pointer to function (so you can dynamically create an array of pointers to function) and you will find a typedef (for the type pointer to the particular function) very helpful.

Quote:

---

Originally Posted by QuantumPete

Yes, you'll need the dereference operator in the sizeof() call. Otherwise sizeof will return the size of the pointer (which on most 32-bit OS is 4 bytes). In this case however, it makes no difference, since your unsigned int is most probably also 4 bytes, so in either case size will contain 4.

---

You're advocating an extremely poor practice here.

It will make a difference if you ever have to migrate between compilers or operating systems. There were quite a few people in the days before 32 bit operating systems who assumed integer and pointer types were 16 bit (2 8-bit bytes). Porting their code to 32 bit systems was a pain. Making your assumption (that unsigned int and size_t are both of size 4 bytes) will, in a similar fashion, make things break should your code need to be migrated to a 64 bit system (which are not common, but are hardly rare either at present).

Quote:

---

Originally Posted by QuantumPete

Interestingly, you can dereference a NULL pointer if you use it in a sizeof() call. :)

---

No you can't.

Firstly, sizeof is not a function call: it is a compile-time operator that evaluates, at compile time, the size of its operand, not it's value. Consider the fact that the expressions "sizeof(foo)" and "sizeof foo" are equivalent.

Computing sizeof(*pointer) computes the size of whatever pointer points at. It does not evaluate pointer and certainly does not dereference it.

Hello,

Maybe I am not too clear.

But is this code creating a pointer to an array of 3 unsigned int objects?

Code:

---

ptrVP = (unsigned int*) malloc(NUMBER_OF_PORTS * sizeof(*ptrVP));

---

I was compiling on CodeBlocks GCC. I got a compile error as I didn't cast.

Anyway I thought malloc returns a void*. I know that using void* is bad practice.

Thanks,

A problem with my Internet.

Please ignore duplicated posts.

Thanks

Quote:

---

Originally Posted by grumpy

It's just you. Try to declare a pointer to pointer to function (so you can dynamically create an array of pointers to function) and you will find a typedef (for the type pointer to the particular function) very helpful.

---

Code:

---

typedef float (fnc_ptr)(int a, char c, double d);

void foo(int a, char c, double d) { }

int main()
{
    fnc_ptr* my_foo_ptr = &foo;
    my_foo_ptr(1, 'a', 10.0);
}

---

Tada!
No * in the typedef!

You will get enough memory for three things-that-ptrVP-points-to, so in this case three unsigned ints.

If you are going to typedef, you should use it:

Code:

---

ptrVP = (pVPGroups) malloc(NUMBER_OF_PORTS * sizeof(*ptrVP));

---

This way when/if your typedef changes, you won't have to change all this as well.

Casting malloc is required in C++ (and not in plain C). On the other hand, if you are intending to write C++, why not use new instead of malloc? (Answer: because your typedef is set up the wrong way for that to work.)

Quote:

---

Originally Posted by steve1_rm

But is this code creating a pointer to an array of 3 unsigned int objects?

Code:

---

ptrVP = (unsigned int*) malloc(NUMBER_OF_PORTS * sizeof(*ptrVP));

---

---

The strictly correct answer is "no". The practical answer is that ptrVP can be used as if it is an array of three unsigned int (as long as the malloc() call succeeds, and doesn't return NULL).

The malloc() call allocates, and returns the address of, a block of memory that is of size NUMBER_OF_PORTS * sizeof(*ptrVP), which (in your code) works out as the same size as a block of three unsigned ints.

ptrVP is a pointer that holds the address of that memory block, converted to be of type "pointer to ptrVP". That pointer can be dereferenced and treated as if it is an array of three unsigned ints. So ptrVP[0], ptrVP[1], and ptrVP[2] allow access to distinct unsigned integers that are located within that memory block (and adjacent to each other in memory).

The concern here is that a pointer and an array are distinct things, but they can be treated as if they are equivalent in some contexts. This will lead many people to mistakenly inform you that a pointer and an array are the same thing.

Quote:

---

Originally Posted by steve1_rm

I was compiling on CodeBlocks GCC. I got a compile error as I didn't cast.

---

That probably means that CodeBlocks is configured to run gcc as a C++ compiler (C++ does not allow an implicit conversion of a void pointer to other pointer types; C does). If you configure CodeBlocks to run gcc as a C compiler, you will not get that error. You'll have to read the documentation for CodeBlocks to work out how to do that.

Quote:

---

Originally Posted by steve1_rm

Anyway I thought malloc returns a void*.

---

It does.

Quote:

---

Originally Posted by steve1_rm

I know that using void* is bad practice.

---

Like any language feature, it's good practice if you use it properly and bad practice if you misuse it.

Quote:

---

No you can't.

---

That depends on what he means; from the context it looks as if he only means that checking for null isn't necessary.

*shrug*

Quote:

---

Firstly, sizeof is not [...] operand, not it's value.

---

Quote:

---

Computing [...] pointer points at.

---

I'm not exactly sure if you are saying what I think you are saying or not, but for the sake of argument, Elysia's 'sizeof' explanation is much closer to the reality of C++. For any given declaration of 'T * t;', 'sizeof(*t)' should be the same as 'sizeof(T)'. That is, what 't' may actually point to, the runtime value, is irrelevant to the calculation.

I only offer this because of the way I interpreted the statement at first; the 'sizeof' operator absolutely can't be used in polymorphic constructs--template based polymorphism aside.

Soma

Quote:

---

Originally Posted by steve1_rm

Hello,

Maybe I am not too clear.

But is this code creating a pointer to an array of 3 unsigned int objects?

Code:

---

ptrVP = (unsigned int*) malloc(NUMBER_OF_PORTS * sizeof(*ptrVP));

---

I was compiling on CodeBlocks GCC. I got a compile error as I didn't cast.

Anyway I thought malloc returns a void*. I know that using void* is bad practice.

Thanks,

---

"using void * is bad practice"?? void pointers are fine to "use" under the right circumstances, and certainly casting a void pointer to something else is only meaningful if "something else" is not a pointer [that applies to C, C++ is different - but then we shouldn't use malloc anyways].

If you get a compiler warning for that line you are doing one of two things wrong:
1. You are not including stdlib.h.
2. You are compiling C code with as C++ (or using C code in a C++ project).

--
Mats

Hello,

Sorry, this should have been posted in the C++ forum. ):

So my pointer points to a block of 3 integers.

Code:

---

size = sizeof(*ptrVP);

---

I thought this would be 12 bytes. (3 * 4). But only displays 4. As I am dereferencing its pointing to the memory block of 3 integers. However, it displayes only 4. Why?

So I can access them, like I would do an array. My code below.
However, I have on purpose overrun the array to go into a forth element. My program did not crash.

Code:

---

    ptrVP[0] = 10;
    ptrVP[1] = 20;
    ptrVP[2] = 30;
    ptrVP[3] = 40;

    std::cout << "ptrVP[0]: " << ptrVP[0] << std::endl;
    std::cout << "ptrVP[1]: " << ptrVP[1] << std::endl;
    std::cout << "ptrVP[2]: " << ptrVP[2] << std::endl;
    std::cout << "ptrVP[3]: " << ptrVP[3] << std::endl;

---

Using pointer arithmetic. Would this be the same as above.

Code:

---

*ptrVP = 10;
    std::cout << "ptr 10: " << *ptrVP << std::endl;
    ptrVP++;
    *ptrVP = 20;
    std::cout << "ptr 20: " << *ptrVP << std::endl;
    ptrVP++;
    *ptrVP = 30;
    std::cout << "ptr 30: " << *ptrVP << std::endl;

---

Many thanks,

Quote:

---

Originally Posted by steve1_rm

As I am dereferencing its pointing to the memory block of 3 integers. However, it displayes only 4. Why?

---

The pointer points to one integer that happens to be in a block of 3 integers. We often say that a pointer points to an array when we really mean that the pointer points (or can point) to some element in an array.

More specifically, sizeof doesn't know (or care) what's actually on the other side of the pointer -- it just uses the type information. ptrVP is a pointer-to-unsigned-int, therefore *ptrVP is an unsigned int, and that's as far as sizeof goes.

As to the other, malloc only guarantees to give you at least as much memory as you asked for. You asked for 12 bytes; you got at least 12 bytes. You may have gotten 12, or 16, or 64, or anything.

sizeof is compile time, so the compiler cannot know you allocated 12 bytes or whatever, since you dereference a single element of the array.
And the code is indeed the same.

> Sorry, this should have been posted in the C++ forum. ):
In which case, you should be using new, and not malloc.

Quote:

---

Originally Posted by Salem

> Sorry, this should have been posted in the C++ forum. ):
In which case, you should be using new, and not malloc.

---

Except for the cases where you need malloc() instead of new, obviously...

Not to get off topic, but sheesh, what is with the "This is C, not C++" comments in 95% of the threads around here?

I'm with brewbuck. There are plenty of times you _need_ malloc.

Using malloc(), fgets(), or you name it does not make code C code. If I want a fast C++ application I am going to use fread() rather than ifstream. That does not make it a C application -- a C compiler would cough on it immediately.

Who decided that if you're not using the latest and greatest features of a language it's suddenly not even valid code at all for the languge? Do I have to add a token class which does nothing to each of my sources just to appease somebody?

In my mind, the second I use something that is only available in C++ and not C, then it is C++ source code.

Hello,

Yes, I understand in C++ you would use new.

However, we are doing some low level stuff as the library we are using is written in C. And new was giving us some unexpected results.

Now I understand the sizeof situation. That point is clear.

However, I am still wondering is this is still ok.

Code:

---

    ptrVP[0] = 10;
    ptrVP[1] = 20;
    ptrVP[2] = 30;
    ptrVP[3] = 40;

    std::cout << "ptrVP[0]: " << ptrVP[0] << std::endl;
    std::cout << "ptrVP[1]: " << ptrVP[1] << std::endl;
    std::cout << "ptrVP[2]: " << ptrVP[2] << std::endl;

---

Using pointer arithmetic. Would this be the same as above.

Code:

---

*ptrVP = 10;
    std::cout << "ptr 10: " << *ptrVP << std::endl;
    ptrVP++;
    *ptrVP = 20;
    std::cout << "ptr 20: " << *ptrVP << std::endl;
    ptrVP++;
    *ptrVP = 30;
    std::cout << "ptr 30: " << *ptrVP << std::endl;

---

Thanks,

It would be almost the same, yes, though the former's syntax is more readable.

> Not to get off topic, but sheesh, what is with the "This is C, not C++" comments in 95% of the threads around here?
> I'm with brewbuck. There are plenty of times you _need_ malloc.
My general assumption is that the person asking the question is a noob needing guidance in how to best use the chosen language to solve a problem.

As a pro, if you want to hack C++ by using C to get something done, then a) you should know what to do without asking and b) you understand the consequences of your actions.

Quote:

---

Originally Posted by Salem

As a pro, if you want to hack C++ by using C to get something done, then a) you should know what to do without asking and b) you understand the consequences of your actions.

---

Agreed. I was being pedantic, for the most part (I usually am). If I see an absolute statement that I know has exceptions, I will point it out. I admit I was somewhat vague in my comments (when would you want to use malloc() in a C++ program?) I'll leave that as a mystery for the reader.

Hello,

Thanks for the information. This post is now resolved.

Quote:

---

Originally Posted by core_cpp

Not to get off topic, but sheesh, what is with the "This is C, not C++" comments in 95% of the threads around here?

---

If you are a C++ dev, then you should be using C++ facilities instead of C facilities, 99% of the time.

Quote:

---

I'm with brewbuck. There are plenty of times you _need_ malloc.

---

There are never a time that you need to use malloc unless a library forces it upon you. Using new can--and is--identical to using malloc.

Quote:

---

Using malloc(), fgets(), or you name it does not make code C code. If I want a fast C++ application I am going to use fread() rather than ifstream. That does not make it a C application -- a C compiler would cough on it immediately.

---

No, it makes it C code or C+ code.
malloc and fgets are C relics and have no purpose in C++. The C++ is code is not, and I repeat it is NOT slower than the C equivalent.

Quote:

---

Who decided that if you're not using the latest and greatest features of a language it's suddenly not even valid code at all for the languge? Do I have to add a token class which does nothing to each of my sources just to appease somebody?

---

You do not have the use the latest and greatest functionality (if such were the case, everyone would be doing template meta programming), but there are some basic facilities that any C++ programmer is expected to use.

Quote:

---

In my mind, the second I use something that is only available in C++ and not C, then it is C++ source code.

---

That just adds to the argument that using fgets, malloc and things in C++ in C code.

Quote:

---

Originally Posted by steve1_rm

Yes, I understand in C++ you would use new.

However, we are doing some low level stuff as the library we are using is written in C. And new was giving us some unexpected results.

---

How so?
new can do the exact same thing as malloc.

Quote:

---

Originally Posted by Elysia

There are never a time that you need to use malloc unless a library forces it upon you. Using new can--and is--identical to using malloc.

---

You make it sound like using a library is some unusual event.

I would think such a library that must force it upon you is rather rare.
The only situation I can think of where new is not applicable is if you allocate some memory and some library frees it with free.

Quote:

---

Originally Posted by Elysia

new can do the exact same thing as malloc.

---

Until they add a realloc[] language construct (never), it can't do the "exact same thing". Well technically I suppose your statement was correct, since malloc only alloc's it, but you get my point. You can't do the same kinds of things using new[] and delete[] that you can using malloc/realloc/free, etc. That's just one example.

Quote:

---

Until they add a realloc[] language construct (never), it can't do the "exact same thing".

---

'realloc' on failure to expand is only a convenience function wrapping 'malloc'/'free'/'memcpy'. So, what can't it, the new and delete operators, do? Or are you actually counting the possibility of expansion? Because if that's it, the new and delete operators are absolutely capable of the "exact same thing". (Hint: the "realloc[] operator"might be spelled 'new(realloc<type>()) type[???]'.)

Quote:

---

You can't do the same kinds of things using new[] and delete[] that you can using malloc/realloc/free, etc.

---

Yes you can, but just for fun, let's see an example.

Soma

Quote:

---

Originally Posted by core_cpp

Until they add a realloc[] language construct (never), it can't do the "exact same thing". Well technically I suppose your statement was correct, since malloc only alloc's it, but you get my point. You can't do the same kinds of things using new[] and delete[] that you can using malloc/realloc/free, etc. That's just one example.

---

I was thinking more along the lines of what Elysia mentioned. Sometimes you just have to call into a C library, and either pass ownership of a buffer (which the C library must free() ), or take ownership of a buffer (which your C++ code must free() ).

It's easy to argue that the library is poorly designed, and I would agree, but sometimes it's unavoidable (calling the library, that is).

That would have to be called renew[] I guess.

However, what std::vector does is already quite close (overallocated raw memory and put objects in it as needed, except its strategy is perhaps too easy to see through and control :)).

^_^

I guess I'm not the only one.

(I hacked something together just to prove the point: it actually returned '&*std::vector<?>::begin()' and 'p = renew(p) test_class[10]' worked perfectly.)

Soma