Quick and dirty C++ managed memory

[countzero]

Why not have the "new" operator return a typed handle when you get
memory on the heap (if you want it to)? And then use a "lock" operator
to get a pointer to the memory, and the pointer is only valid within
the scope of the function. Then on idle time, all memory is unlocked
and can be compacted.

I wonder if there is a way of doing this by overiding the global new
and delete operators and somehow checking for handle types?

In any case I think it would be better if the compiler was in on the
action.

For instance you could declare a handle:

char* # hString;

hString = new char[80];

if( hString )
{
char* pString = lock hString;

strcpy( pString, "A String");

int len = strlen( pString );
}

And when you want to free the memory:

delete [] hString;
And when calling a member function:

CThisObject* # hThis = new CThisObject( data );

if( hThis )

hThis->DoThat();
is the same as:

CThisObject* # hThis = new CThisObject( data );

if( hThis )
{
CThisObject* p = lock hThis;

p->DoThat();
}

In any case, I'm sure die-hard C++ programmers would prefer managed
memory along these lines instead of all the crap you have to deal with
in .NET managed C++.

[Alf P. Steinbach]

* countzero:

Why not have the "new" operator return a typed handle when you get
memory on the heap (if you want it to)?
It returns a typed pointer.

And then use a "lock" operator to get a pointer to the memory,
Locking is a good idea for systems without hardware memory management;
in C++ it can be implemented as a smart-pointer (no language extension
necessary).

and the pointer is only valid within the scope of the function.

That's a std::auto_ptr.

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[countzero]

On Fri, 11 Mar 2005 06:30:49 GMT, al***@start.no (Alf P. Steinbach)
wrote:

* countzero:

Why not have the "new" operator return a typed handle when you get
memory on the heap (if you want it to)?

It returns a typed pointer.

Thanks for "pointing" out the painfully obvious.

But can you comprehend the concept of a typed handle that can point to
different memory addresses except when its "locked"?

And then use a "lock" operator to get a pointer to the memory,

Locking is a good idea for systems without hardware memory management;
in C++ it can be implemented as a smart-pointer (no language extension
necessary).

Actually when it comes to Java, C# and Visual Basic the memory is
somewhere along the lines directly poked and prodded. And during idle
time it's compacted with (likely) hardware memory management.

Having a version of C++ that directly accesses the memory from handles
during an event-drivien, non-idle function is no different from those
languages.

"Locking" within an event-function is just a possible term that gets
the current address of the memory from the handle. In that context,
Java, C# and Visual Basic all "lock" memory then.

As for smart-pointers they don't do the same job and aren't as simple.

I want typed handles to objects allocated on the heap that can change
address. And I want to know they are handles in the code and the
compiler will give me errors if I don't use them the right way.

and the pointer is only valid within the scope of the function.

That's a std::auto_ptr.

There you go. It's theoretically possible.

But like I said I don't want all the technical garbage collection, er,
garbage...

I want to eliminate memory fragmentation in the most simplest way. And
typed handles to memory objects that can be moved around are, by far,
the most simplest way for a C++ programmer.

[msalters]

Alf P. Steinbach wrote:

* countzero:

Why not have the "new" operator return a typed handle when you get
memory on the heap (if you want it to)?
It returns a typed pointer.

And then use a "lock" operator to get a pointer to the memory,

Locking is a good idea for systems without hardware memory

management; in C++ it can be implemented as a smart-pointer (no language extension necessary).

and the pointer is only valid within the scope of the function.

That's a std::auto_ptr.

No. Not at all. It's not a handle nor a lock. std::auto_ptr cannot,
by any definition of the word, move the allocated memory. Any
reference to the object must remain valid. With a lock(handle),
the raw pointer returned is usable for the duration of the lock.
When the lock goes out of scope, pointers and references are
invalidated but the object itself remains valid. (although it
could move). If an auto_ptr goes out of scope, the object is
destroyed.

It is possible to write a standard C++ class which has the desired
handle behavior, and a lock class. The lock can probably be
boost::scoped_p tr with a custom 'deleter'. When the lock goes out
of scope, the object can be moved again.

HTH,
Michiel Salters

[Alf P. Steinbach]

* msalters:

Alf P. Steinbach wrote:

* countzero:

Why not have the "new" operator return a typed handle when you get
memory on the heap (if you want it to)?

It returns a typed pointer.

And then use a "lock" operator to get a pointer to the memory,

Locking is a good idea for systems without hardware memory
management;
To repeat myself: Locking is a good idea for systems without hardware memory
management.

and the pointer is only valid within the scope of the function.

That's a std::auto_ptr.

No. Not at all. It's not a handle nor a lock. std::auto_ptr cannot,
by any definition of the word, move the allocated memory.

It doesn't need to under common operating systems; the OS does that for you;
also, see above.

E.g., in old Windows and on the Mac you had to do explicit locking, nowadays
the OS does that and moves memory blocks all the time without affecting the
logical addresses in a process.

Cheers,

- Alf

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Rolf Magnus]

countzero wrote:

"Locking" within an event-function is just a possible term that gets
the current address of the memory from the handle. In that context,
Java, C# and Visual Basic all "lock" memory then.

As for smart-pointers they don't do the same job and aren't as simple.
They can do the same job and can be as simple. You just have to write one.
I want typed handles to objects allocated on the heap that can change
address. And I want to know they are handles in the code and the
compiler will give me errors if I don't use them the right way.

And why do you think it's not possible to write a smart pointer that does
that?