Jump to page: 1 2 3
Thread overview
Using new to allocate memory in Win32
Aug 06, 2001
Dan Rushe
Aug 06, 2001
Jan Knepper
Aug 07, 2001
Walter
Aug 07, 2001
Dan Rushe
Aug 07, 2001
Jan Knepper
Aug 07, 2001
Walter
Aug 07, 2001
Jan Knepper
Aug 07, 2001
Walter
Aug 07, 2001
Jan Knepper
Aug 08, 2001
Walter
Aug 17, 2001
jacob navia
Aug 17, 2001
Jan Knepper
Aug 08, 2001
Rajiv Bhagwat
Aug 08, 2001
Jan Knepper
Aug 08, 2001
Dan Rushe
Aug 08, 2001
Jan Knepper
Aug 09, 2001
Dan Rushe
Aug 09, 2001
Jan Knepper
Aug 09, 2001
Dan Rushe
Aug 10, 2001
Jan Knepper
Aug 11, 2001
Rajiv Bhagwat
August 06, 2001
    Does DM implement the new operator when compiling Win32 apps?  And
if so, how does it work.  Returning a pointer to an object is useless
under Windows, especially when memory gets moved around.  So, if new
returns a pointer to the object, how could you possibly use it with
Windows?

    I had Borland C++ 4.5, and the documentation said that it contained
a heap manager, but it did not say how the pointers could be resolved.
Any help would be appreciated.

--
            Dan Rushe
            thecourtjesture@advnet.net
            ICQ#: 119626702


August 06, 2001
Dan Rushe wrote:

>     Does DM implement the new operator when compiling Win32 apps?

Yes it does.

> And if so, how does it work.  Returning a pointer to an object is useless
>
> under Windows, especially when memory gets moved around.  So, if new returns a pointer to the object, how could you possibly use it with Windows?

DMC++ has a very efficient memory management implementation which calls VirtualAlloc at the lowest level of the 'operator new' implementation as far as I know.

VirtualAlloc is being called with MEM_COMMIT and PAGE_READWRITE if that is of any help.

Jan



August 07, 2001
The memory moving around was a problem in real mode windows, which was dumped by Microsoft by Windows version 3.1 (as I recall). This is not an issue in protected mode Windows, available from Windows 3.0 on.

Dan Rushe wrote in message <3B6F1488.DF237A17@advnet.net>...
>    Does DM implement the new operator when compiling Win32 apps?  And
>if so, how does it work.  Returning a pointer to an object is useless under Windows, especially when memory gets moved around.  So, if new returns a pointer to the object, how could you possibly use it with Windows?
>
>    I had Borland C++ 4.5, and the documentation said that it contained
>a heap manager, but it did not say how the pointers could be resolved. Any help would be appreciated.
>
>--
>            Dan Rushe
>            thecourtjesture@advnet.net
>            ICQ#: 119626702
>
>


August 07, 2001

Walter wrote:

> The memory moving around was a problem in real mode windows, which was dumped by Microsoft by Windows version 3.1 (as I recall). This is not an issue in protected mode Windows, available from Windows 3.0 on.

    So memory does not move around anymore?  And if not, then the pointers
should remain valid.  The reason I need to know, is that I'm trying to
implement a linked list in Windows, and I wasn't impressed with using
handles to memory blocks for each item.

--
            Dan Rushe
            thecourtjesture@advnet.net
            ICQ#: 119626702


August 07, 2001
The handles in Win32 are actually pointers...



Dan Rushe wrote:

> Walter wrote:
>
> > The memory moving around was a problem in real mode windows, which was dumped by Microsoft by Windows version 3.1 (as I recall). This is not an issue in protected mode Windows, available from Windows 3.0 on.
>
>     So memory does not move around anymore?  And if not, then the pointers
> should remain valid.  The reason I need to know, is that I'm trying to
> implement a linked list in Windows, and I wasn't impressed with using
> handles to memory blocks for each item.

August 07, 2001
Dan Rushe wrote in message <3B70034E.15A4BD8E@advnet.net>...
>Walter wrote:
>> The memory moving around was a problem in real mode windows, which was dumped by Microsoft by Windows version 3.1 (as I recall). This is not an issue in protected mode Windows, available from Windows 3.0 on.
>
>    So memory does not move around anymore?  And if not, then the pointers
>should remain valid.  The reason I need to know, is that I'm trying to implement a linked list in Windows, and I wasn't impressed with using handles to memory blocks for each item.


They're just pointers now. A lot of documentation was written about real mode windows programming that never got updated to protected mode reality, so it's easy to get the impression you still need to worry about real mode issues.



August 07, 2001
> They're just pointers now. A lot of documentation was written about real mode windows programming that never got updated to protected mode reality, so it's easy to get the impression you still need to worry about real mode issues.

Just to confuse things a little more M$ did the following in winnt.h (used for
all Win32 platforms):

typedef void *PVOID;

[ ... snip ... ]

#ifdef STRICT
typedef void *HANDLE;
#define DECLARE_HANDLE(name) struct name##__ { int unused; }; typedef struct
name##__ *name
#else
typedef PVOID HANDLE;
#define DECLARE_HANDLE(name) typedef HANDLE name
#endif
typedef HANDLE *PHANDLE;

So basically a 'HANDLE' is 'void *'
<g>

Jan


August 07, 2001
This kind of fiddling is why D has typechecking for typedef'd names.

Jan Knepper wrote in message <3B700A93.F41EFC25@smartsoft.cc>...
>> They're just pointers now. A lot of documentation was written about real mode windows programming that never got updated to protected mode
reality,
>> so it's easy to get the impression you still need to worry about real
mode
>> issues.
>
>Just to confuse things a little more M$ did the following in winnt.h (used
for
>all Win32 platforms):
>
>typedef void *PVOID;
>
>[ ... snip ... ]
>
>#ifdef STRICT
>typedef void *HANDLE;
>#define DECLARE_HANDLE(name) struct name##__ { int unused; }; typedef
struct
>name##__ *name
>#else
>typedef PVOID HANDLE;
>#define DECLARE_HANDLE(name) typedef HANDLE name
>#endif
>typedef HANDLE *PHANDLE;
>
>So basically a 'HANDLE' is 'void *'
><g>
>
>Jan
>
>


August 07, 2001
Have you done anything on 'D' lately?
To prepare I could begin creating a newsgroup 'd' <g>

Jan



Walter wrote:

> This kind of fiddling is why D has typechecking for typedef'd names.

August 08, 2001
All the technical discussion simply means:
- go ahead with your linked list without any worries about memory moving.
Your pointers will NOT change on you without you doing so!! As far as the
programmers are concerned, the same linked list code should work for DOS,
Unix or current versions of Windows.

-- Rajiv Bhagwat


Dan Rushe <thecourtjesture@advnet.net> wrote in message news:3B70034E.15A4BD8E@advnet.net...
>
>
> Walter wrote:
>
> > The memory moving around was a problem in real mode windows, which was dumped by Microsoft by Windows version 3.1 (as I recall). This is not an issue in protected mode Windows, available from Windows 3.0 on.
>
>     So memory does not move around anymore?  And if not, then the pointers
> should remain valid.  The reason I need to know, is that I'm trying to
> implement a linked list in Windows, and I wasn't impressed with using
> handles to memory blocks for each item.
>
> --
>             Dan Rushe
>             thecourtjesture@advnet.net
>             ICQ#: 119626702
>
>


« First   ‹ Prev
1 2 3