"James Kanze" <kanze@gabi-soft.de> wrote in message
news:d6651fb6.0208300301.678c7da3@posting.google.com...
>
> "Homer Meyer" <homer@cqg.com> wrote in message
> news:<umq8m6aajehmd1@news.supernews.com>...
> > "Ioannis Vranos" <noicys@spammers.get.lost.hotmail.com> wrote in message
> > news:1029417405.809194@athprx02.forthnet.gr...
<SNIP>
> > If you are saying that something like this isn't undefined behavior,
> > then I think you should look again:
>
> > struct A {
> >    int a;
> >    vitrual ~A() {}
> > };
> >
> > A* one = new A();
> > unsigned char buff[sizeof(A)];
> > memcpy(buff, one);
> > delete one;
> > one = (A*)(new unsigned char[sizeof(A)]);
> > memcpy(one, buff);
>
> > Ok, that isn't copying back to the same object.
>
> Two flaws: 1) the object that is copied back doesn't exist anymore, so
> it cannot be copied back, and 2) you're not copying it back; you're
> copying it somewhere else.  Since the internal representation of an
> object may contain pointers to itself (and probably will, if virtual
> inheritance is involved), the guarantee only applies to copying it to
> the location were it was before.

I thought that was what I said.

> > But even this produces undefined behavior:
>
> > std::string b = "short";
> > unsigned char buff[sizeof(b)];
> > memcpy(buff, b);
> > b = "much longer string here";
> > memcpy(b,buff);
>
> The undefined behavior here is because you have overwritten an existing
> object, not because of the memcpy.  If you correctly delete the second
> object before copying the first back, I'm not sure that the behavior is
> undefined.  Practically, the program has no way of knowing.

Look again.  There is no second object.  It addresses flaw number two that
you mentioned above.

> > The point being, that you have to copy the bytes back to the original
> > object without doing any operations at all on the original object or
> > modifying the bytecopy between copying the bytes out and copying them
> > back in, otherwise there is a very good chance of invoking undefined
> > behavior.
>
> You can do whatever you want with the bytes in question, as long as what
> you do doesn't cause undefined behavior itself.  As a simple example:
>
>     std::string b = "short" ;
>     unsigned char buff[ sizeof( std::string ) ] ;
>     std::memcpy( buff, &b, sizeof( std::string ) ) ;
>     std::memset( &b, 0, sizeof( std::string ) ) ;
>     std::memcpy( &b, buff, sizeof( std::string ) ) ;
>     //  Use b...

And how does that apply to what I said?  You haven't done any operations
(const or non-const)  on the original object.  You have only modified the
storage directly.

> I cannot imagine how something like this could be undefined behavoir.

It's not.




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Homer Meyer" <homer@cqg.com> wrote in message
news:<umq8m6aajehmd1@news.supernews.com>...
> "Ioannis Vranos" <noicys@spammers.get.lost.hotmail.com> wrote in message
> news:1029417405.809194@athprx02.forthnet.gr...

>  > "James Russell Kuyper Jr." <kuyper@wizard.net> wrote in message
>  > news:3D58664F.A357A4CB@wizard.net...

>  > > Ioannis Vranos wrote:
>  > > ..
>  > > > You can copy an object to a char array or file and then copy it
>  > > > back and have the same functionality. If by dumping you mean to
>  > > > consider the result as its bit contents, the answer is "no
>  > > > way".

>  > > Only for POD objects, of course.

>  > Yes. However i think that you can copy any object to an unsigned
>  > char array and then copy it back and have the same functionality:

>  > "The object representation of an object of type T is the sequence
>  > of N unsigned char objects taken up by the object of type T, where
>  > N equals sizeof(T). The value representation of an object is the
>  > set of bits that hold the value of type T.".

> If you are saying that something like this isn't undefined behavior,
> then I think you should look again:

> struct A {
>    int a;
>    vitrual ~A() {}
> };
>
> A* one = new A();
> unsigned char buff[sizeof(A)];
> memcpy(buff, one);
> delete one;
> one = (A*)(new unsigned char[sizeof(A)]);
> memcpy(one, buff);

> Ok, that isn't copying back to the same object.

Two flaws: 1) the object that is copied back doesn't exist anymore, so
it cannot be copied back, and 2) you're not copying it back; you're
copying it somewhere else.  Since the internal representation of an
object may contain pointers to itself (and probably will, if virtual
inheritance is involved), the guarantee only applies to copying it to
the location were it was before.

> But even this produces undefined behavior:

> std::string b = "short";
> unsigned char buff[sizeof(b)];
> memcpy(buff, b);
> b = "much longer string here";
> memcpy(b,buff);

The undefined behavior here is because you have overwritten an existing
object, not because of the memcpy.  If you correctly delete the second
object before copying the first back, I'm not sure that the behavior is
undefined.  Practically, the program has no way of knowing.

> The point being, that you have to copy the bytes back to the original
> object without doing any operations at all on the original object or
> modifying the bytecopy between copying the bytes out and copying them
> back in, otherwise there is a very good chance of invoking undefined
> behavior.

You can do whatever you want with the bytes in question, as long as what
you do doesn't cause undefined behavior itself.  As a simple example:

    std::string b = "short" ;
    unsigned char buff[ sizeof( std::string ) ] ;
    std::memcpy( buff, &b, sizeof( std::string ) ) ;
    std::memset( &b, 0, sizeof( std::string ) ) ;
    std::memcpy( &b, buff, sizeof( std::string ) ) ;
    //  Use b...

I cannot imagine how something like this could be undefined behavoir.

--
James Kanze                           mailto:jkanze@caicheuvreux.com
Conseils en informatique orient   e objet/
                    Beratung in objektorientierter Datenverarbeitung

      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"James Russell Kuyper Jr." <kuyper@wizard.net> wrote in message
news:3D58664F.A357A4CB@wizard.net...
>
> Ioannis Vranos wrote:
> ..
> > You can copy an object to a char array or file and then copy it
back
> > and have the same functionality. If by dumping you mean to
consider
> > the result as its bit contents, the answer is "no way".
>
> Only for POD objects, of course.


Yes. However i think that you can copy any object to an unsigned char
array and then copy it back and have the same functionality:

"The object representation of an object of type T is the sequence of N
unsigned char objects taken up by the object of type T, where N equals
sizeof(T). The value representation of an object is the set of bits that
hold the value of type T.".


--
Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.cjb.net
* Alternative URL: http://run.to/noicys




      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

"Boranin" <xxx@yyy.zzz> wrote in message
news:zbx49.4666$C8.39881@nnrp1.uunet.ca...
 >
 > I should probably add the following line to my code:
 >
 > memcpy(buf, &b, szBuffer);
 >
 >
 > "Boranin" <xxx@yyy.zzz> wrote in message
 > news:E0x49.4658$C8.39953@nnrp1.uunet.ca...
 > >
 > > I haven't done much C++ lately so I decided to refresh my memory
and
 > > write
 > a
 > > small file paging program. The program will use a low-level,
 > > unbuffered
 > I/O
 > > to serialize objects, one of which is a bitmap mapping free file
 > > pages. I thought of creating my own bitset class to allow access
to
 > > its internal buffer, but that seems like reinventing the wheel. So
 > > consider the
 > following
 > > code snippet:
 > >
 > > const size_t szBuffer = 1024;
 > > const size_t szBitset = szBuffer * 8;
 > > ...
 > > char buf[szBuffer];
 > > bitset<szBitset> b;
 > > ...
 > > _write(file_handle, buf, szBuffer);    // MS Windows specific
 > >
 > > 1. How safe is it to dump STL objects such as bitset into a char
 > > buffer or file?

It hasn't to do specificallywith STL objects. Template classes are
generic specifications (although here is more special-purpose). After
the instantiation of an object, it is as if you wrote that class
explicitly.



You can copy an object to a char array or file and then copy it back
and have the same functionality. If by dumping you mean to consider
the result as its bit contents, the answer is "no way".



 > 2. Are there any other ways of serializing bitsets?


What do you mean?



 > > 3. How would I go about finding the first 0 bit in a bitset?

unsigned long i=0;

for(i=0; i<b.size(); i++)
{
   if(!b[i])
     break;
}


// i is the index of the first 0 bit.



--
Ioannis

* Ioannis Vranos
* Programming pages: http://www.noicys.cjb.net
* Alternative URL: http://run.to/noicys



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]

Ioannis Vranos wrote:
..
> You can copy an object to a char array or file and then copy it back
> and have the same functionality. If by dumping you mean to consider
> the result as its bit contents, the answer is "no way".

Only for POD objects, of course.



      [ Send an empty e-mail to c++-help@netlab.cs.rpi.edu for info ]
      [ about comp.lang.c++.moderated. First time posters: do this! ]

[ comp.std.c++ is moderated.  To submit articles, try just posting with ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://www.jamesd.demon.co.uk/csc/faq.html                       ]