Home > Archive > VC Language > June 2005 > VirtualAlloc and new
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
VirtualAlloc and new
|
|
| JR Lyon 2005-06-07, 9:00 pm |
| I am kind of new to C++ and I am having some memory trouble of course:) Can
anyone describe to me the difference between VirtualAlloc and new. What are
the pros and cons of both.
TIA
JR
| |
| Peter Koch Larsen 2005-06-07, 9:00 pm |
|
"JR Lyon" <jrlyon@hotmail.com> skrev i en meddelelse
news:OsHqBM6aFHA.3684@TK2MSFTNGP12.phx.gbl...
>I am kind of new to C++ and I am having some memory trouble of course:) Can
> anyone describe to me the difference between VirtualAlloc and new. What
> are
> the pros and cons of both.
>
> TIA
> JR
>
>
For one thing, VirtualAlloc allocates "raw" memory and is non-portable but
gives you more control over the allocated memory. new allocates memory and
creates an object and is portable. Also new is much faster. You should
normally prefer new to VirtualAlloc.
/Peter
| |
| JR Lyon 2005-06-07, 9:00 pm |
| So when you say non-portable what do you mena by that?
JR
"Peter Koch Larsen" <pkl@mailme.dk> wrote in message
news:efvaLR6aFHA.3240@TK2MSFTNGP12.phx.gbl...
>
> "JR Lyon" <jrlyon@hotmail.com> skrev i en meddelelse
> news:OsHqBM6aFHA.3684@TK2MSFTNGP12.phx.gbl...
Can[color=darkred]
> For one thing, VirtualAlloc allocates "raw" memory and is non-portable but
> gives you more control over the allocated memory. new allocates memory and
> creates an object and is portable. Also new is much faster. You should
> normally prefer new to VirtualAlloc.
>
> /Peter
>
>
| |
| William DePalo [MVP VC++] 2005-06-07, 9:00 pm |
| "JR Lyon" <jrlyon@hotmail.com> wrote in message
news:eS$zPj6aFHA.2124@TK2MSFTNGP14.phx.gbl...
> So when you say non-portable what do you mena by that?
That means that the function is available only on platforms that support the
Win32 API.
Regards,
Will
| |
| Kerem Gümrükcü 2005-06-08, 4:02 am |
| Hi,
always keep this in your mind: Control over Memory is EVERYTHING!
And these are your best friends for the future: new, delete, malloc(),
free(), *,->,&,...
Tip: Always try to develop "system and plattform- independent", wich means
try to
stays at ANSI/ISO C++ and try to avoid things like VirtualAlloc(...) and
other
Microsoft WIndows or other OS specific Functions whenever it is possible. I
say
that, because some day you may want to or MUST port applications or
libraries
to other systems and this will help you in simplifying your job, believe me!
Best Regards
Kerem Gümrükcü
| |
| Simon Trew 2005-06-08, 8:59 pm |
| "Peter Koch Larsen" <pkl@mailme.dk> wrote in message
news:efvaLR6aFHA.3240@TK2MSFTNGP12.phx.gbl...
> Also new is much faster.
Why do you think this? There was a time when the CRT's heap sub-allocator
was faster than calling VirtualAlloc directly, but I thought nowadays (since
Win2K? or WinXP?) that was no longer true, and VirtualAlloc is now quite
capable of allocating small blocks efficiently. And since 'new' will
generally call the constructor on whatever object is being allocated, one
would imagine this would be slower than just allocating the raw memory.
S.
| |
| Alexander Grigoriev 2005-06-09, 3:59 am |
| VirtualAlloc granularity is 64 kB. You don't want to waste 64 kB of address
space for each little allocation.
You probably thought of HeapAlloc.
"Simon Trew" <ten.enagro@werts> wrote in message
news:uE8QlvHbFHA.2688@TK2MSFTNGP14.phx.gbl...
> "Peter Koch Larsen" <pkl@mailme.dk> wrote in message
> news:efvaLR6aFHA.3240@TK2MSFTNGP12.phx.gbl...
>
> Why do you think this? There was a time when the CRT's heap sub-allocator
> was faster than calling VirtualAlloc directly, but I thought nowadays
> (since Win2K? or WinXP?) that was no longer true, and VirtualAlloc is now
> quite capable of allocating small blocks efficiently. And since 'new' will
> generally call the constructor on whatever object is being allocated, one
> would imagine this would be slower than just allocating the raw memory.
>
> S.
>
| |
| Pavel Lebedinsky [MSFT] 2005-06-09, 9:00 am |
| "Simon Trew" wrote:
>
> Why do you think this? There was a time when the CRT's heap sub-allocator
> was faster than calling VirtualAlloc directly, but I thought nowadays
> (since Win2K? or WinXP?) that was no longer true, and VirtualAlloc is now
> quite capable of allocating small blocks efficiently.
You're probably confusing VirtualAlloc with HeapAlloc. Old versions
of CRT used to implement their own small block allocator on top of
HeapAlloc. Now malloc and new are basically just very thin wrappers
around HeapAlloc, which in turn is built on top of VirtualAlloc.
VirtualAlloc can't allocate less than one page (4KB or 8KB depending
on architecture). And because of the 64 KB allocation granularity, it
usually doesn't make sense to allocate blocks that are less than 64 KB
in size (if you VirtualAlloc one 4 KB page, you waste 60 KB of virtual
memory, which is a finite resource on 32 bit).
Even for blocks that are a small multiple of 64 KB, malloc/HeapAlloc
are likely to be faster because most of the time they don't require a
transition to kernel mode, unlike VirtualAlloc which is a system call.
So basically you should always use malloc/HeapAlloc, unless you
really need additional functionality provided by VirtualAlloc, or you're
implementing your own custom allocator.
--
This posting is provided "AS IS" with no warranties, and confers no
rights.
|
|
|
|
|