🚀 go-pugleaf

gyro@kestrel.edu (Scott Layson Burson) writes:
>It struck me today that it would be awfully nice to have a high level,
>type-safe interface to `alloca' (which allocates a block of memory of
>specified size in the caller's stack frame).

>A syntax is easily enough come by: `new auto <type>'.

>This probably won't fly, since `alloca' is not in the ANSI library and
>may be difficult to write for some implementations ...

In theory, there's no need for alloca.  All the machinery needed to
implement running-of-destructors-for-local-objects can be used to
simulate alloca on top of malloc and free.  It's not as efficient, but
it isn't impossible.  Compilers for systems w/o alloca will just need
to work a little harder.

Sigh.  Another feature.  Has anyone considered removing features from
the language instead of adding them?

David Chase
Sun

In article <1991May27.233808.14632@hal.com> shap@hal.com (Jonathan Shapiro) writes:
>In article <12759@exodus.Eng.Sun.COM> chased@rbbb.Eng.Sun.COM (David Chase) writes:
>>In theory, there's no need for alloca.  All the machinery needed to
>>implement running-of-destructors-for-local-objects can be used to
            ****************************************
>>simulate alloca on top of malloc and free.  It's not as efficient, but
>>it isn't impossible.
>>
>>David Chase
>>Sun
...
>Until recently, I was inclined to agree with you. Since then, I have
>run into at least one case where the need to use malloc/free becomes
>impossibly cumbersome: functions that do error recovery or error-based
>abandonment.

Nope, I included that in behavior in my model.  Once you also
implement the machinery for exception handling in C++ (whatever
machinery that is) you can simulate alloca in all important respects.
It could be horribly expensive if your exception-handling
implementation was bad (i.e., high cost in the normal case), or if
your memory allocator was slow (as it often is), but it would work
correctly.

Again, I don't recommend this implementation -- my point is definitely
"in theory".  (What was this all about, anyway?  Someone wanted a
nifty keyword on "new" to get simulated alloca?  That's moderately
reasonable, but not necessary.)

David Chase
Sun

In article <1991May27.233808.14632@hal.com> shap@hal.com (Jonathan Shapiro) writes:
>Until recently, I was inclined to agree with you. Since then, I have
>run into at least one case where the need to use malloc/free becomes
>impossibly cumbersome: functions that do error recovery or error-based
>abandonment.
>
>Consider a function that does the following:
>
>	allocate something
>
>	conditionally return failure
>
>	allocate something else
>
>	conditionally return failure
>
>	allocate something else
>
>	deallocate everything
>	return success
>
>In the absence of alloca(), the management of deallocation becomes a
>very likely source of programmer error, especially as the function is
>maintained by third parties.
>
>In my view, this is a compelling reason to have alloca.

I disagree.  Its easy to solve the kinds of problems that alloca can
solve from within C++ -- see the following simple-minded example.
Alloca simply allows one to create variable sized objects of known
lifetime [namely the lifetime of the surrounding routine] and this
is not a hard problem anyway.

Rather, the hard problem is managing the deallocation of objects of
indefinite lifetime, which in general is not a solvable problem excepting
the use of garbage collection.  To which I propose:  Garbage Collection.
Given garbage collection, any advantages of alloca go away anyway,
since GC schemes exist where allocation simply becomes an inline ptr
addition -- which is as efficient or better than alloca anyway.

----



extern "C"
{
#include <stdio.h>
#include <stdlib.h>
#include <malloc.h>
}

void* traced_malloc(size_t size)
{
	void* p = malloc(size);
	printf("allocate %d bytes at $%lX\n", size, (long)p);
	return p;
}

void traced_free(void* p)
{
	printf("free at $%lX\n", (long)p);
}

void* operator new(size_t size) { return malloc(size); }
void operator delete(void* p) { free(p); }

#define malloc(x) traced_malloc(x)
#define free(x) traced_free(x)

int failed() // simulate unpredictable failures
{
	return !(3 & rand());
}

class Tracker
{
public:
	void* p;
	operator void*() { return p; }
	Tracker(void* pT) : p(pT) {}
	Tracker() : p(0) {}
	~Tracker() { if (p != 0) free(p); }
};

#define FAILURE 1
#define SUCCESS 0

int troublesome_routine()
{
	// allocate something:

	Tracker p1 = malloc(100);

	// conditionally return failure:

	if (failed())
		return FAILURE;

	// allocate something else:

	Tracker p2 = malloc(200);

	// conditionally return failure:

	if (failed())
		return FAILURE;

	// allocate something else:

	Tracker p3 = malloc(300);

	// conditionally return failure:

	if (failed())
		return FAILURE;

	// trackers will automatically deallocate everything, so just:

	return SUCCESS;
}


// lets try these "troublesome" routine a few times and see what happens:

main()
{
	for (int tries=0; tries<10; ++tries)
	{
		printf("----------------------\n");
		troublesome_routine();
	}
}

// ---- its no trouble at all!