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.
Originally Posted by Adak
> Sorry, this should have been posted in the C++ forum. ):
In which case, you should be using new, and not malloc.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
Except for the cases where you need malloc() instead of new, obviously...
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
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.
Using pointer arithmetic. Would this be the same as above.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;
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.
Look up a C++ Reference and learn How To Ask Questions The Smart Way
> 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.
If you dance barefoot on the broken glass of undefined behaviour, you've got to expect the occasional cut.
If at first you don't succeed, try writing your phone number on the exam paper.
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.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
Hello,
Thanks for the information. This post is now resolved.
If you are a C++ dev, then you should be using C++ facilities instead of C facilities, 99% of the time.
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.I'm with brewbuck. There are plenty of times you _need_ malloc.
No, it makes it C code or C+ code.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.
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.
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.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?
That just adds to the argument that using fgets, malloc and things in C++ in C code.In my mind, the second I use something that is only available in C++ and not C, then it is C++ source code.
How so?
new can do the exact same thing as malloc.
You make it sound like using a library is some unusual event.
Code://try //{ if (a) do { f( b); } while(1); else do { f(!b); } while(1); //}
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.
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.
'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[???]'.)Until they add a realloc[] language construct (never), it can't do the "exact same thing".
Yes you can, but just for fun, let's see an example.You can't do the same kinds of things using new[] and delete[] that you can using malloc/realloc/free, etc.
Soma
