"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aiqleb$13s0$1@digitaldaemon.com...
> I propose a standard "convert to byte array" function (and corresponding "convert byte array to object" function).  Not sure what the syntax should be.  Something along the lines of standard conversion to string, just a binary version.  Actual file I/O isn't the hard part, and streaming/persistence doesn't always go to a disk file anyway (i.e.
message
> pipe, network socket, some kind of custom file, compressed file, etc)
>
> Sean

That's something along the lines I was considering. I'm don't think I/O is that hard either, it was mainly the proccess of converting the class object structure to file. How would you handle pointers?

In C++ you could simply save the entire class (unless you had pointers), in one go (or convert it to a binary string as easy as pie). So I hope that's not what your suggesting. However, I don't trust D here, because it has the power to rearrange members. However that's not my point.

Your right, it should be able to be use it with anything, parhaps even used for in copy constuctors and overloaded operators. The point is that it would make coding alot easier if there was some support for dealing with the class object linkages as a whole.

> "anderson" <anderson@firestar.com.au> wrote in message news:aioclq$11f4$1@digitaldaemon.com...
> > This sounds like a cool idea. This would be useful in saving/loading objects.
> >
> > <Babble>
> > I'd also like it if D provided other faculties for save/loading classes
> from
> > file. Some features to aid in quickly save parts of the hierarchies of
> class
> > objects to files. Some support in saving objects that have multiple references and then in restoring their pointer locations on a load.
(I've
> > done that before, but it would be nice to have some sort of support
either
> > in lib form or complier form for it).
> >
> > -PS Lucky this a digitalmars newgroup and hasn't been attacked by that newgroup porn thing. What's with that Evil.
>
>
>

Yah, the pointers are a bitch.  ;)  Didn't think of that.

Sean

"anderson" <anderson@firestar.com.au> wrote in message news:air25s$1geh$1@digitaldaemon.com...
>
> "Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aiqleb$13s0$1@digitaldaemon.com...
> > I propose a standard "convert to byte array" function (and corresponding "convert byte array to object" function).  Not sure what the syntax
should
> > be.  Something along the lines of standard conversion to string, just a binary version.  Actual file I/O isn't the hard part, and streaming/persistence doesn't always go to a disk file anyway (i.e.
> message
> > pipe, network socket, some kind of custom file, compressed file, etc)
> >
> > Sean
>
> That's something along the lines I was considering. I'm don't think I/O is that hard either, it was mainly the proccess of converting the class
object
> structure to file. How would you handle pointers?
>
> In C++ you could simply save the entire class (unless you had pointers),
in
> one go (or convert it to a binary string as easy as pie). So I hope that's not what your suggesting. However, I don't trust D here, because it has
the
> power to rearrange members. However that's not my point.
>
> Your right, it should be able to be use it with anything, parhaps even
used
> for in copy constuctors and overloaded operators. The point is that it
would
> make coding alot easier if there was some support for dealing with the
class
> object linkages as a whole.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN37473681461331@news.digitalmars.com...
> Wouldn't it be simplier for the compiler to assign a unique integer to
each
> class declared in the program? 4 times smaller, and much faster when it comes to comparison.

Already done, it's the pointer to the classinfo <g>. The downside is this won't work across dll's or processes.

I think odds of a collision on 32 bit values are high enough to make it unreliable.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:ainr9r$1o9e$1@digitaldaemon.com...
> So how (and when) do you generate it?  GUID's have timestamp and local NIC info.  That means a data file I make on my machine with an exe I compile,
if
> you have identical source and you recompile and try to read my data file
it
> won't match.
>
> No good.
>
> A crc32 on the fully explicit scoped name (with dots as separators) would likely be plenty sufficient.

On Fri, 9 Aug 2002 20:22:17 -0700 "Walter" <walter@digitalmars.com> wrote:

> Already done, it's the pointer to the classinfo <g>. The downside is this won't work across dll's or processes.

It also won't work for persistance, because one can't guarantee that ClassInfo pointer will remain the same on the second run of the program.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374785206735301@news.digitalmars.com...
> On Fri, 9 Aug 2002 20:22:17 -0700 "Walter" <walter@digitalmars.com> wrote:
>
> > Already done, it's the pointer to the classinfo <g>. The downside is
this
> > won't work across dll's or processes.
>
> It also won't work for persistance, because one can't guarantee that ClassInfo pointer will remain the same on the second run of the program.

Exactly. Persistance.

Parhaps there could be a way to allow users to specify numbers for ClassInfo (or something else) at complie time.

Something else other then (but simular to) ClassInfo, where users could specify which group it belongs to.

ie

//Belongs to group Agroup and Bgroup
persistant Agroup, Bgroup class somethingA
{
...
}

persistant Agroup class somethingB

...
}

//Inherits this ability
class somethingC : somethingB
{
...
}

Agroup.getID()

A file, which the user could change could be created (automaticly),
something like:
Agroup:
somethingA #1
somethingB #2
somethingC #3
Bgroup:
somethingA #1

Which the complie would add to each time new classes are added.  If a class was removed it would leave it in the listing in case the user wants to included it latter. When a user transports code, this file would be taken with it. Of course the users can already do this manually, but it's difficult when working in groups. You wouldn't always need it and this version would only need 16 - 32 bits. Often projects need to be combined and having something standard like this would be a good help.

Anyhow
If we had "static virtual constructors" and the order remained the same at
runtime this would be an easy job for a programmer.

Walter wrote:

> I think odds of a collision on 32 bit values are high enough to make it
> unreliable.


It's not difficult to provide the full name of a class (with module) the first time it's transmitted and then just a handle subsequent times. This should be unique in any data space.  This will also include the data signature describing how the class was saved, so it's important information that need be conveyed in any case, as the reader has to do some involved data matching on the initial instance.

The same thing is done with pointers.  First time the pointer's seen on this stream we transmit the full data, subsequent times are just a handle.  Old hat.

"Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374785206735301@news.digitalmars.com...
> On Fri, 9 Aug 2002 20:22:17 -0700 "Walter" <walter@digitalmars.com> wrote:
>
> > Already done, it's the pointer to the classinfo <g>. The downside is
this
> > won't work across dll's or processes.
>
> It also won't work for persistance, because one can't guarantee that ClassInfo pointer will remain the same on the second run of the program.

You're right. I think GUIDs are the right solution - and they'd mesh naturally in with COM support, too.

GUIDs are a bad solution for aforementioned reasons.  Look at my earlier post in this thread.  If you go that route, the programmer has to generate GUID's for every class probably and those GUID's would I guess have to live in the source code.  If I wanted that I could do it myself.  I'd like to avoid that PITA in day-to-day work if possible.

Sean

"Walter" <walter@digitalmars.com> wrote in message news:aj3osj$2p6p$1@digitaldaemon.com...
>
> "Pavel Minayev" <evilone@omen.ru> wrote in message news:CFN374785206735301@news.digitalmars.com...
> > On Fri, 9 Aug 2002 20:22:17 -0700 "Walter" <walter@digitalmars.com>
wrote:
> >
> > > Already done, it's the pointer to the classinfo <g>. The downside is
> this
> > > won't work across dll's or processes.
> >
> > It also won't work for persistance, because one can't guarantee that ClassInfo pointer will remain the same on the second run of the program.
>
> You're right. I think GUIDs are the right solution - and they'd mesh naturally in with COM support, too.

"Sean L. Palmer" <seanpalmer@earthlink.net> wrote in message news:aj5669$13bs$1@digitaldaemon.com...
> GUIDs are a bad solution for aforementioned reasons.  Look at my earlier post in this thread.  If you go that route, the programmer has to generate GUID's for every class probably and those GUID's would I guess have to
live
> in the source code.  If I wanted that I could do it myself.  I'd like to avoid that PITA in day-to-day work if possible.

The GUIDs would be generated by default by the compiler, and so for intra-process stuff, should work fine. Only for cross-process etc. would they need to be hand generated. The need to support GUIDs to work with COM isn't going to go away, and 3 schemes coexisting together is too much.