class objects on the stack

Started by
4 comments, last by webwraith 15 years, 4 months ago
What is the generally accepted method for dealing with user-defined compound objects in a stack-based language? I've tried looking for information on it, and haven't found anything so far.
Advertisement
general accepted method for doing what exactly? you'll need to be more specific.
"dealing with user-defined compound objects in a stack-based language" is rather broad and vague..
OK, basically my language spec includes classes, a la C++ & Java. Now a stack, as I understand it, is used for storing values and the manipulation of these values. So how are classes represented on the stack? Are they put in member by member, and the compiler treats them all as a group? Or is the storage of a class's member variables kept elsewhere, and a reference is placed on the stack? And if it's the latter, where is the data normally kept? I'd rather not implement a heap as well, if I can help it.

[Edited by - webwraith on December 4, 2008 10:36:50 AM]
Quote:Original post by webwraith
OK, basically my language spec includes classes, a la C++ & Java. Now a stack, as I understand it, is used for storing values and the manipulation of these values. So how are classes represented on the stack? Are they put in member by member, and the compiler treats them all as a group? Or is the storage of a class's member variables kept elsewhere, and a reference is placed on the stack? And if it's the latter, where is the data normally kept? I'd rather not implement a heap as well, if I can hhelp it.
The class/struct can be stored directly in the stack - a struct is after just a block of memory. Note that if you plan to support returning structs from function calls, you probably need to use caller-allocated return space.

Tristam MacDonald. Ex-BigTech Software Engineer. Future farmer. [https://trist.am]

C++ compilers usually create a "turn these bytes into an instance" procedure for every constructor in the class or structure. This procedure can then be used for every instance creation, both on the heap and on the stack.

Note that stack-based languages can be Turing-equivalent, but they tend to have limitations on expressiveness, because you can only push data on top of the stack—insertion anywhere else in the stack is inefficient. Clever optimization tricks exist (including static analysis which can handle 99% of static return size situations) but you won't be able to do anything useful about dynamic size allocations without some kind of reflection (and pushing data around) or a heap.
@swiftcoder: And I'm guessing I store the offset of each member in the correct place in the symbol list for the class? Thank you, that seems suprisingly obvious once it's pointed out.

@ToohrVyk: How often, and in what scenarios, are insertions into the middle of the stack required? And when you talk about dynamic size allocation, are you talking about shifting the stack elements around in response to an added element, or the size of the elements themselves?

EDIT: OK, just answered my own question about the dynamic memory, and the only possible use of "insertion" into the middle of the stack is the exchange/swap and related stack operations. Is this what you meant, ToohrVyk?

[Edited by - webwraith on December 4, 2008 3:01:30 PM]

This topic is closed to new replies.

Advertisement