Thread: I/O

  1. #1
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654

    I/O

    Here's a good question for you about the C++ I/O.
    If I can't get this solved, I'm going to have to scrap the entire I/O and go for MFC/pure C.
    Consider this:

    Code:
    CRegistry::ERROR CRegistry::LoadHives(CRegistry::CHive& rHive)
    {
    	m_Key.sIndex.seekg(0); // Make sure we're at the beginning of the file
    	FAIL_FILEOP(m_Key.sIndex >> rHive.nFreeId, m_Key.sIndex);
    	FAIL_FILEOP(m_Key.sIndex >> rHive.nLastOffset, m_Key.sIndex);
    	return CRegistry::ERROR_SUCCESS;
    }
    
    CRegistry::ERROR CRegistry::SaveHives(CRegistry::CHive& rHive)
    {
    	FAIL_FILEOP(m_Key.sIndex << rHive.nFreeId, m_Key.sIndex);
    	FAIL_FILEOP(m_Key.sIndex << rHive.nLastOffset, m_Key.sIndex);
    	m_Key.sIndex.flush(); // Flush buffer to make sure it can be read later
    	return CRegistry::ERROR_SUCCESS;
    }
    We don't need to know many details besides that rHive.nFreeId && rHive.nLastOffset == UINT64 && is equal to 0.
    So when I print these to the files, I find the following in the files:
    "00" - A STRING (plus only 2 bytes) when I'm actually writing a UINT64, which is 8 bytes!
    And of course it affects the reading. I seek back to the beginning and try to read into the same variables later, and what do you know, the first read sets the EOF flag and the second FAILS because it reads after the end of the file!

    It converts everything to STRINGS, truncates it and writes to the file and FAILS to read it properly next time.
    Maybe I just don't know how to use it, but this looks just like a bother to me.
    Last edited by Elysia; 12-02-2007 at 08:13 AM.

  2. #2
    Registered User
    Join Date
    Aug 2005
    Location
    Austria
    Posts
    1,990
    Quote Originally Posted by Elysia View Post
    This C++ I/O crap is pathetic from what I see. It converts everything to STRINGS, truncates it and writes to the file and FAILS to read it properly next time.
    It looks like you are using the "C++ I/O crap" the wrong way. You have decided to convert everything to strings. If you want binary IO there are stream::read/write.
    Kurt

  3. #3
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Thought I did that:
    Code:
    	if ( m_Key.sData.is_open() ) m_Key.sData.close();
    	if ( m_Key.sIndex.is_open() ) m_Key.sIndex.close();
    	m_Key.sData.open(strPath + _T("\\Registry.dat"), ios_base::in | ios_base::out | ios_base::binary);
    	if ( !m_Key.sData.is_open() ) // No registry exists?
    	{
    		m_Key.sData.open(strPath + _T("\\Registry.dat"), ios_base::in | ios_base::out | ios_base::trunc | ios_base::binary);
    		if ( !m_Key.sData.is_open() ) // Unable to create a new data file?!?
    			return ThrowError(CRegistry::ERROR_ACCESS_DENIED);
    		m_Key.sData.clear(ios_base::goodbit);
    	}
    	m_Key.sIndex.open(strPath + _T("\\Index.dat"), ios_base::in | ios_base::out | ios_base::binary);
    	if ( !m_Key.sIndex.is_open() ) // No registry exists?
    	{
    		m_Key.sIndex.open(strPath + _T("\\Index.dat"), ios_base::in | ios_base::out | ios_base::trunc | ios_base::binary);
    		if ( !m_Key.sIndex.is_open() ) // Unable to create a new index file?!?
    			return ThrowError(ERROR_ACCESS_DENIED);
    		m_Key.sIndex.clear(ios_base::goodbit);
    		SaveHives( GetHive() );
    	}

  4. #4
    Registered User
    Join Date
    Aug 2005
    Location
    Austria
    Posts
    1,990
    That doesn't change the fact that all the prefefined operators >> and << convert the data to and text from.
    All you have done with using ios_base::binary for the stream openmode is that you have switched the conversion of the line terminator off.
    Kurt

  5. #5
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    So they're basically all just useless? The only way to do it is using write/get?

  6. #6
    Registered User
    Join Date
    Aug 2005
    Location
    Austria
    Posts
    1,990
    You can still use the operators >> and << but you will have to take care yourself that the data is stored with a predefined length if you want to be able to calculate offsets in a textfile.
    Maybe use the iomanipulators setw and setfill.
    Kurt

  7. #7
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    So much for C++ I/O. Bah. Useless scrap.

  8. #8
    Registered User
    Join Date
    Aug 2005
    Location
    Austria
    Posts
    1,990
    Quote Originally Posted by Elysia View Post
    So much for C++ I/O. Bah. Useless scrap.
    I wouldn't say it's useless crap. Guess you just don't know how to use it properly.
    Kurt

  9. #9
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    I mean, what's the point of << and >> if you're not going to use them? I could just as well use C-style I/O.
    This means I'll have to make my own class to wrap around MFC's CFile and overload << and >> myself.

  10. #10

  11. #11
    Registered User
    Join Date
    Jan 2005
    Posts
    7,366
    >> I mean, what's the point of << and >> if you're not going to use them?
    The built-in versions are for text-based fie processing. If you want text based processing you use those. Many (most?) files are done using text based processing, so they have plenty of use.

    It's like saying, "I'm trying to fly my car to Florida but it's not working." When someone says that the car isn't meant to be used to fly, you say, "Then cars are crap, what's the point of them if you don't use them?" Obviously, if you use them for what they are intended for then they are useful.

  12. #12
    C++まいる!Cをこわせ!
    Join Date
    Oct 2007
    Location
    Inside my computer
    Posts
    24,654
    Obviously, but for me, working mostly with binary, they are useless.
    Anyway, I wrapper my own class around MFC's CFile and overloaded << and >> and it works fine.
    Another thing I have against the C++ I/O is that it's so huge and so much code to do so little. Contrary to MFC's implentation, it's just a bunch of 20 lines or so to get the job done.

    I also question how much "text mode" is used in real applications. Obviously lots of programs tend to write binary files, and not text files.
    Last edited by Elysia; 12-02-2007 at 11:59 AM.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. asynchronized I/O == multiplexing I/O?
    By George2 in forum C Programming
    Replies: 1
    Last Post: 07-24-2006, 10:06 AM
  2. why page based I/O can improve performance?
    By George2 in forum C Programming
    Replies: 1
    Last Post: 06-12-2006, 07:42 AM
  3. Nonblocking I/O
    By fnoyan in forum Linux Programming
    Replies: 4
    Last Post: 11-29-2005, 04:37 PM
  4. Overlapped I/O and Completion Port :: Winsock
    By kuphryn in forum Windows Programming
    Replies: 0
    Last Post: 10-30-2002, 05:14 PM
  5. WSAAsyncSelect I/O Mode :: Winsock
    By kuphryn in forum Windows Programming
    Replies: 1
    Last Post: 05-12-2002, 03:23 PM