I'll go with speed. My assumption is when you create a pointer it'll have to create space for the pointer as well as the object, where as the other just creates an object?
>>13
At that point I hit you over the head with a blunt object and interrogate you until I find out what it is you are actually trying to do. What you are doing now is the equivalent of saying that we should all use Assembly, because every last bit is precious. It's 2010, memory is plentiful. Every last bit is not precious.
>>15
it's 2010, most people are still stuck with a 4GB RAM limit. until machines with 6GB of RAM cost less than $50, every last bit will still be precious.
>>17
Even Win32 isn't stuck with a 4 GB RAM limit anymore, and you're an idiot if you think counting pointers is where you're going to get any significant improvements in memory usage.
Name:
Anonymous2010-05-22 21:46
>>15
What if I live in a desert where silicon isn't plentiful?
In the first case memory is allocated on the HEAP.
In the second case memory is allocated on the STACK.
It's the same amount of memory in both cases. The memory on the heap needs to be de-allocated manually, while the memory on the stack is released automatically when the function returns.
>>27
I only barely managed to decipher your comment! Someone has apparently sabotaged your Shift key and left it nigh unreadable!
The answer you are looking for, though, is this: Sepples pretends to be a low-level language, so ``implementation'' details actually aren't.
>>28
after a bit of searching, i've determined that the c++ standard only mentions stacks when talking about exception handling and the container in the standard library.
also, your shift key seems to be broken. your post is full of mixed case.
I'm a C guy, but in C there is automatic storage and dynamic storage, which people often confuse with "the stack" and "the heap" respectively, because they don't understand that the implementation they are accustomed to (x86 architecture in 99.99% of cases) is not necessarily how it works in every implementation / environment / architecture.
I'm not sure what the C++ standard says about this because I haven't read it, but I imagine that it too has "automatic storage" (which our x86 implementations would put on the stack just like in C) and "dynamic storage" (which comes from malloc(), and in C++'s case, new).
In any case, it is true that the memory for OP's first example is allocated dynamically and needs to be freed manually (by delete in this case), and the 2nd example will be freed when the function it is local to ends.
it's not confused. automatic storage is default in c/c++ and goes on the stack. there is a max stack size to be aware of if you're creating a lot of local variables, or doing a lot of recursion. the keyword 'auto' is implicit in c/c++, so when you have 'int i;' it's equivalent to 'auto int i;'
dynamic storage (malloc, new) allocates memory on the heap, and does require a more cpu because a free block of space needs to be found, assigned, and recorded. yes there are different implementations of dynamic storage, but heap is the most common so let's not get all corner-case here.
it's not confused. automatic storage is default in c/c++ and goes on the stack.
See, that is where you are confused. C does not specify a stack. It is entirely up to the implementation how to arrange the automatic storage.
In before another round of "YA BUT SHOW ME A IMPLMENTATION DAT DOESNT USE CALL STACK 4 AUTO STORAGE :D". It amazes me what lengths people will go to avoid understanding what C is about just because it contradicts what they want to believe.
>>36
While C doesn't, specific implementations for which people tend to write their code (besides libraries, most applications contain architecture-specific code) do specify things like stack layout in great detail. I've also yet to see a C compiler which doesn't use a stack, and almost all va_start/va_arg/va_end macros operate on the stack directly. Just because it doesn't have to, doesn't mean it won't. While you're programming in ANSI C, you have no right to assume those things, but once you step down and use a real implementation (or a group of real implementations), you can start very clearly making assumptions about how allocation will work, and you can confirm these by inspecting libc source code or the compiler's source code, as well as the generated assembly listing.
>>38
Yes, that was definitely a more thoughtful reply than >>36. In any case he should keep his shit straight unless he is explicitly talking about a particular implementation.