Re: De-serializing and stack sizes

["Alex R. Mosteo" <devnull@mailinator.com>]

Dmitry A. Kazakov wrote:

> On Fri, 01 Sep 2006 19:57:55 +0200, Alex R. Mosteo wrote:
> 
>> I'm now facing a problem that I don't know how to solve. I'm going to
>> give some thought to it over the week-end and any ideas are welcome.
>> 
>> I have some objects that I want to serialize to files. For their creation
>> I use access types so they get created in heap and there's no problem. I
>> simply output them with
>> 
>> Item_Type'Output (Stream, Item.all);
>> 
>> However, you see the problem, loading them back is a no-no:
>> 
>> Item : constant Item_Access := new Item_Type'(Item_Type'Input (Stream));
>> 
>> The 'Input attribute is trying to return the object in the stack and so
>> it doesn't work. My items are around 20 MB in size (now, they could grow
>> bigger) and I'd like not to have to raise my stack to these sizes (also
>> making it doable from the environment task would be a plus).
> 
> I think what you have is stream attributes for *limited* types. You didn't
> declare Item_Type limited, but in fact it is, because you want to prevent
> copying it, for example, from the stack to the heap. As we know it didn't
> work in Ada 95. It must be different in Ada 05.

I think you mean "what you need"? I see your point if that's the case. My
type isn't intrinsically limited, it wasn't until I hit the stack problem,
now I see it may be a possible approach. 

I see I can use customized stream attributes, but is an artificial need
imposed by the stack limitation. It's not a problem doing it once, but
could become a hassle if necessary more often. That's the reason I'm trying
to get some general solution.

> For Ada 95, in an analogous case, I wrote a limited types factory of my
> own. It was necessary anyway, because stream attributes are not portable.
> There are clear disadvantages of such approach (again for Ada 95), because
> of single inheritance. In Ada 05, it should be much better, because the
> number of ancestors is unlimited as long as they are interfaces.
 
Portability is not an issue in this case, that's a reason I'm going for the
fastest solution possible.

Thanks for your comments,

A. Mosteo.