@Itix
Thanks for your comments. I'll take a look at Ambient prefspool later on before releasing it.
Quote:
Instead of just having a descriptor there could be maybe an API call to create one in fly with the data? Something like SS_SaveDataItem(). Building descriptors sound clunky.
I think that would cause overhead and for many types of data it would be impossible for the library to guess how to save it anyway, some orientation has to be made i.e. if you don't want to save all elements of a struct you have to define which ones you want..
Quote:
Passing a low level intuition window pointer is bad idea IMO. For error messages it could be better define callback API that is called on each error?
For more practical handling you maybe want to create a black box context for all this stuff.
I agree, I'll extend it with a callback in the future, so the user can choose how errors are handled or if he just wants them handled automatically (maybe with some options...).
Quote:
Having full example code would help. It could be also good idea create a proto to test design if you dont have one already?
I do have test code, that's how I test it, but it's a bit of a mess right now and not suitable to include in a presentation.. I'll post some later on. It's really simple, you just add something like Code:
, where DtInf is the name of the already defined descriptor, allowing cross references to other descriptors as if they belonged to the current one.
Quote:
Should not you define datatype and datatype size somewhere? For example string pointer, floats, 8/16/32/64 bit integers and so on?
Aha! Now we're getting to it :) No, the macros are already doing all of that, they add data pointer / size / type automatically so the user only has to make a list of elements to be serialized using said macros.
Quote:
Macros look very non-descriptive. From a developer POV it could be easier if one could just:
SS_ReadItem(context, ID, to_pointer, to_offset);
SS_SaveItem(context, ID, from_pointer, from_offset);
This is more flexible if member variables in the struct are shuffled.
If I get it right you mean group of data could be repeatedly saved to various places with a general descriptor, I have something already done for that too. Descriptors can include fixed addressed or offset based positions so that they can be used general (that's how reusage is implemented, again best way is so include some code, I'll do that later...).
Macros names are actually somewhere descriptive but because they do a whole bunch of things at the same time there's no short descriptive name..
EL just means "Element", it's just to include an element in a group to be (un)serialized. ELd is exactly the same but it allows for a default (hence the extra "d") to be included in descriptor if non ID for this data is found on the stream when loading the data back to memory from a serialized stream or even when serializing data to a stream to be sent over the network (different descriptors can be defined for unserializing/serializing with reusage between them so that the whole list of data doesn't have to be added again...).
Missed the shuffled part ?
Quote:
Actually, it could be nice if an entire taglist could be saved with just one call:
SS_SaveTagList(context, CONST struct TagItem *taglist);
Tag lists are NULL terminated, they have ID, position is already in the taglist. What is missing is datatype (32-bit integer or ptr to other datatype, like a string). Some bits from the tag ID could be allocated to this purpose.
Agreed, specially when the whole things was inspired by Tag lists in the first place:) I'll look into that.
Quote:
Probably not much users :) although developers have often need to save settings in flexible manner. Everyone is using his own system.
MUI has this system built-in but is not flexible for user data (btw also consider how to save an array of strings!).
I've seen lots of questions about how this is done in general C forums and there's no generally used method, so I think a multiplatform library to do it would be cool (will be ...:)). Even beyond the efforts saved to code a specific implementation all the time this could be used to save settings between AROS and 68k/PPC without having to worry about endianess problems. My idea for endianess is to just reimplement most of the functions again for different platforms endian wise, cumbersome but clear/faster.
I have run into a problem recently and I'm not finding a way to solve it. I want to include a zero at the beginning of each descriptor that's used by the code as a space for some maitenance. I wanted it to be included with a macro instead of the user, he might forget it and it's less work, but there's no way to start an initializer list with a zero, i.e. Code:
and keep a "C like interface".
For example, if I want to have a macro that automatically add's a zero to an initializer list I won't be able to have the descriptors declared as a C array anymore:
Code:
ULONG SettingsDescriptor[] =
{
EL (ID_VarA, VariableA),
EL (ID_VarB, VariableB),
0
};
Code:
/* Now declared with a macro to automatically add zero at the start */
#define SS_DEF(DefName) ULONG DefName[] = /* Potential descriptor macro */
{
0,
#define SS_END ,0}
SS_DEF(SettingsDescriptor)
EL (ID_VarA, VariableA),
EL (ID_VarB, VariableB),
SS_END;
This last way however makes the declaration a bit like Reaction macros and I would like to avoid it because it breaks normal C declarations a bit but there seems to be no way around it.
Before anyone suggests, a dynamic memory allocation would make the code having to initialize itself for each call, the absence of which is now something that I really like...
What do you think, is this too far from normall C syntax for you ? I've seen worse but I wanted it to be perfect, at least like:
Code:
SS_DEF(SettingsDescriptor)=
{
EL (ID_VarA, VariableA),
EL (ID_VarB, VariableB),
SS_END
};
or
Code:
SS_DEF(SettingsDescriptor)
{
EL (ID_VarA, VariableA),
EL (ID_VarB, VariableB),
SS_END
};
But I couldn't come up with a macro to do this because once the bracked is opened there's no way out of it without having to add a closing bracked and declare another variable. With that approach (the macro itself closing the bracket) then the first varible would have to be a struct with said long int containing a zero and a pointer to a second variable containing the descriptor array. This is not even possible in C (forward references are not allowed in C).
Guess I'm nitpicking here, but I wanted it to be perfect :)
[ Edited by Jose 30.07.2015 - 02:04 ] 
