| From: | Aaron Optimizer Digulla |
| Date: | 29 Aug 2000 at 15:33:38 |
| Subject: | Re: AMIOPEN: TagLists (was: Object allocated on stack - init and/or open) |
Quoting Jean-Michel Forgeas <forgeas@wanadoo.fr>:
> From: Jesse McClusky <thought@weblink.org>, August 29, 2000 3:19 AM
> > The problem comes in in that the constructor (in this case, the
> > default is init) can take any number of arguments, depending on
> > the class. The new and delete operators, however, always have
> > a fixed number of args.
>
> This brings up an other question I had somewhere : what about TagLists
> of the classic Amiga system
Well, I've ported utility.library to all kinds of CPUs and all I
can say here is: *Beware*, you're on treacherous ground.
The problem is that TagLists are untyped (ie. there is no
hint what the datatype is which you pass to a tag). This way,
you have to pray that the next item in the list is actually what
you expect.
Example: You have a system with 32bit pointers and 64bit ints.
How do you define ti_Data ? It must be 64bit but when you use
the stack/varargs interface, then how do you tell if you have to
read 4 bytes of data or 8 ? Especially if you pass pointers as
ints or vice versa.
And on Ami, you have the additional problem that all pointers
are different and you cannot simply cast them to void* or
into a long (which would then be 64bit).
But since the advantages of TagLists might make it worth to give
it a try, the API should do this:
- A TagItem is a struct with int ti_Tag, int ti_Type (Data
Type in ti_Data) union ti_Data (all possible types).
As for "all possible types", we would need to devise a way to
cast all pointers into a single abstract pointer type (void*).
I don't know if only the linker makes such a fuzz about different
pointers being different or if there is a more subtle reason for
this.
Then, we could create macros which would do this:
struct TagItem tags = {
TAG (X, Int (0)),
TAG (Y, Int (0)),
TAG (Text, Pointer ("Hello, World!")),
};
The macro TAG would expand to { TAG_X, TAG_DataType_Int, (int) 0 },
etc.
The receiving function (which parses the tags) could very easily
convert the data type in the array into the expected data type
(because the don't have to be necessarily the same; some kind of
exception handling will be necessary) because it would *know*
what type the data has (unlike the original TagItems on the Amiga).
And we would have an additional advantage: One could pass tags over
a network to a different computer or store them into a file (think:
Saving a GUI to a file and loading it again).
Subscribe/Unsubscribe: open-request@amiga.com
Amiga FAQ: http://www.amiga.com/faq.html