reinterpret_cast ? bad? good?

Discussion in 'C++' started by Someonekicked, Apr 11, 2006.

  1. I want to save tables of integers to files.
    One way to write the cells as fixed size in the file, is to use
    reinterpret_cast.
    Is that a bad choice, good choice? I remember once before I posted a program
    using it, and some suggested that I might get errors using it.
    are there any other ways to write the cells as fixed size in the file?
    (knowing the cells will only contain integers).


    here is how I plan to do it (without much caring about all the details),

    int cell = 20;
    outFile.write(reinterpret_cast<const char *> (&cell),sizeof(cell));

    thx for any feedback.

    --
    Quotes from The Weather Man:
    Robert Spritz: Do you know that the harder thing to do, and the right thing
    to do, are usually the same thing? "Easy" doesn't enter into grown-up
    life... to get anything of value, you have to sacrifice.
     
    Someonekicked, Apr 11, 2006
    #1
    1. Advertising

  2. Someonekicked

    Noah Roberts Guest

    Someonekicked wrote:
    > I want to save tables of integers to files.
    > One way to write the cells as fixed size in the file, is to use
    > reinterpret_cast.
    > Is that a bad choice, good choice? I remember once before I posted a program
    > using it, and some suggested that I might get errors using it.
    > are there any other ways to write the cells as fixed size in the file?
    > (knowing the cells will only contain integers).
    >
    >
    > here is how I plan to do it (without much caring about all the details),
    >
    > int cell = 20;
    > outFile.write(reinterpret_cast<const char *> (&cell),sizeof(cell));


    reinterpret_cast is bad. However, is it sometimes necessary? Well,
    you have just shown one area where it is. There isn't really any other
    way to output to a binary file than what you are doing above. You have
    to 'translate' you data to bytes so somewhere down the line you have to
    do a reinterpret cast to bitwise cast your data into byte delimited
    chunks...chars. This act of course kills portability, but the very act
    of writing binary data to a file is itself not portable...you can't
    take that file to any computer and expect it to work without taking
    great care to translate between systems.

    reinterpret_cast indicates non-portable code any time it is used. As
    such, any time you do use it you need to ask yourself if what you are
    doing is in fact correct. The only cast that raises more flags is a
    const_cast.
     
    Noah Roberts, Apr 11, 2006
    #2
    1. Advertising

  3. Someonekicked

    Guest

    you can make your IO more portable by converting to network endian
    before writing (and to host enadian after reading) - the same way you
    would do when sending through a socket.
     
    , Apr 11, 2006
    #3
  4. Someonekicked

    Andre Kostur Guest

    wrote:
    > you can make your IO more portable by converting to network endian
    > before writing (and to host enadian after reading) - the same way you
    > would do when sending through a socket.
    >


    However, even that assumes that the sizes of the types being written to
    disk are the same between the two platforms. It would be better to say
    that you must define a "canonical form" for anything you write to disk.
    That definition may be: ints will be written as 4 bytes in
    network-byte-order. However, that does limit your file format to 4 byte
    integers.....
     
    Andre Kostur, Apr 11, 2006
    #4
  5. Someonekicked

    benben Guest

    >> here is how I plan to do it (without much caring about all the details),
    >>
    >> int cell = 20;
    >> outFile.write(reinterpret_cast<const char *> (&cell),sizeof(cell));

    >
    > reinterpret_cast is bad. However, is it sometimes necessary? Well,
    > you have just shown one area where it is. There isn't really any other
    > way to output to a binary file than what you are doing above. You have
    > to 'translate' you data to bytes so somewhere down the line you have to
    > do a reinterpret cast to bitwise cast your data into byte delimited
    > chunks...chars. This act of course kills portability, but the very act
    > of writing binary data to a file is itself not portable...you can't
    > take that file to any computer and expect it to work without taking
    > great care to translate between systems.



    Agree.

    That said, the fact that the integer is reinterpret_casted to a char*
    is better hidden from the user as it is indeed an implementation technique.

    One way to do this is to use overloaded functions:

    void write_data(const File_stream& outFile, int target)
    {
    char* p = reinterpret_cast<char*>(*target);
    outFile.write(p, sizeof(int));
    }

    This way the user can simply use it as the following:

    int i = 42;
    File_stream f("myfile");
    write_data(f, i);

    If somehow you have better alternative than the reinterpret_cast there
    is only one place you need to change, instead of inspecting the whole
    project.

    Regards,
    Ben
     
    benben, Apr 11, 2006
    #5
  6. Someonekicked

    Phlip Guest

    Someonekicked wrote:

    > int cell = 20;
    > outFile.write(reinterpret_cast<const char *> (&cell),sizeof(cell));


    You are asking whether binary files are good. They are bad. Write text and
    read text. The Boost Serialization library has a good example how; so does
    the tinyxml project.

    Don't write a binary file "because it's faster". The tiny speed hit of
    formatting and deformatting strings is more than compensated by your rapid
    development.

    --
    Phlip
    http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
     
    Phlip, Apr 11, 2006
    #6
  7. Someonekicked

    Phlip Guest

    yuvalif wrote:

    > you can make your IO more portable by converting to network endian
    > before writing (and to host enadian after reading) - the same way you
    > would do when sending through a socket.


    That's another reason to write text, not binary.

    --
    Phlip
    http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
     
    Phlip, Apr 11, 2006
    #7
  8. Phlip <> wrote:
    > Someonekicked wrote:
    >
    >> int cell = 20;
    >> outFile.write(reinterpret_cast<const char *> (&cell),sizeof(cell));

    >
    > You are asking whether binary files are good. They are bad. Write
    > text and read text. The Boost Serialization library has a good
    > example how; so does the tinyxml project.
    >
    > Don't write a binary file "because it's faster". The tiny speed hit of
    > formatting and deformatting strings is more than compensated by your
    > rapid development.


    All generalizations are false ;)

    No seriously, consider a 3D file format that contains vertex data.
    With todays high-poly models, the speed hit caused by parsing the file
    will be enormous.

    I agree that for settings or alike, formatting and deformatting is
    no big deal.

    So the answer really depends on what the OP is doing.

    regards
    --
    jb

    (reply address in rot13, unscramble first)
     
    Jakob Bieling, Apr 11, 2006
    #8
  9. Someonekicked

    Phlip Guest

    Jakob Bieling wrote:

    > All generalizations are false ;)


    So are all made-up statistics.

    For example, 51% of the posts here are of the format "I'm trying to speed my
    code up without profiling it to find the real statistics, or generally
    finding a need. How do I do blah-blah-blah that's heinously complicated?"

    Is there a FAQ citation for the "premature optimization is the root of all
    evil" generalization I could link out to? Answering such posts is difficult
    without triggering another "premature optimization" thread...

    --
    Phlip
    http://www.greencheese.org/ZeekLand <-- NOT a blog!!!
     
    Phlip, Apr 11, 2006
    #9
  10. Someonekicked

    Ian Collins Guest

    Phlip wrote:
    > Jakob Bieling wrote:
    >
    >
    >> All generalizations are false ;)

    >
    >
    > So are all made-up statistics.
    >
    > For example, 51% of the posts here are of the format "I'm trying to speed my
    > code up without profiling it to find the real statistics, or generally
    > finding a need. How do I do blah-blah-blah that's heinously complicated?"
    >
    > Is there a FAQ citation for the "premature optimization is the root of all
    > evil" generalization I could link out to? Answering such posts is difficult
    > without triggering another "premature optimization" thread...
    >

    I think you missed the key point:

    "So the answer really depends on what the OP is doing."

    --
    Ian Collins.
     
    Ian Collins, Apr 11, 2006
    #10
  11. it is a simple project for my DB class.
    There are two tables of integers (put in two files), and we have to do a
    hash join (equijoin), using buckets (buckets must be files too).
    The tables will only contain integers.
    so I want to put the second table (file) into buckets, then do the join.
    so I was thinking of making the cells in the buckets files fixed size, so I
    only read the entry in the column I am interesed it, rather than reading the
    whole row everytime. Then if that entry satisfy the join condition, then I
    can read the whole row.
    The program will be supposably tested with millions of data.

    --
    Quotes from The Weather Man:
    Robert Spritz: Do you know that the harder thing to do, and the right thing
    to do, are usually the same thing? "Easy" doesn't enter into grown-up
    life... to get anything of value, you have to sacrifice.
    "Someonekicked" <> wrote in message
    news:...
    >
    > I want to save tables of integers to files.
    > One way to write the cells as fixed size in the file, is to use
    > reinterpret_cast.
    > Is that a bad choice, good choice? I remember once before I posted a
    > program using it, and some suggested that I might get errors using it.
    > are there any other ways to write the cells as fixed size in the file?
    > (knowing the cells will only contain integers).
    >
    >
    > here is how I plan to do it (without much caring about all the details),
    >
    > int cell = 20;
    > outFile.write(reinterpret_cast<const char *> (&cell),sizeof(cell));
    >
    > thx for any feedback.
    >
    > --
    > Quotes from The Weather Man:
    > Robert Spritz: Do you know that the harder thing to do, and the right
    > thing
    > to do, are usually the same thing? "Easy" doesn't enter into grown-up
    > life... to get anything of value, you have to sacrifice.
    >
     
    Someonekicked, Apr 12, 2006
    #11
  12. Someonekicked

    miksiu Guest

    benben wrote:

    > One way to do this is to use overloaded functions:
    >
    > void write_data(const File_stream& outFile, int target)
    > {
    > char* p = reinterpret_cast<char*>(*target);
    > outFile.write(p, sizeof(int));
    > }
    >
    > This way the user can simply use it as the following:
    >
    > int i = 42;
    > File_stream f("myfile");
    > write_data(f, i);
    >


    What about this? I think it's more generic:

    template<class T>
    bool write_data( const File_stream& outFile, T& target )
    {
    std::stringstream ss;
    std::string str;
    if( !(ss << target ) || ss.fail() || !(ss >> str) )
    {
    return false;
    }

    //now write str to the outFile

    return true;
    }

    It can be overloaded for T as std::string
     
    miksiu, Apr 12, 2006
    #12
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Suzanne Vogel
    Replies:
    17
    Views:
    847
    Suzanne Vogel
    Jul 7, 2003
  2. Scott Brady Drummonds

    reinterpret_cast<>() v. static_cast<>()

    Scott Brady Drummonds, Jan 13, 2004, in forum: C++
    Replies:
    11
    Views:
    20,945
    Nick Hounsome
    Jan 20, 2004
  3. Aman

    reinterpret_cast<>

    Aman, Feb 23, 2004, in forum: C++
    Replies:
    15
    Views:
    876
    Ben Hutchings
    Feb 25, 2004
  4. rantingrick
    Replies:
    44
    Views:
    1,304
    Peter Pearson
    Jul 13, 2010
  5. Alex Vinokur
    Replies:
    1
    Views:
    612
Loading...

Share This Page