allocating memory with malloc

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