C / C++ / MFC

Reading binary files with c stdio fread

2-Nov-02 11:00

When I UpdateData(TRUE) to set the value in my Calendar Control to its corresponding CTime object it arbitrarily adds a fixed number of days to the selected date. Example:
If the the user selected November 5, 2002 the date that would be stored in the CTime object would November 12, 2002. Likewise if they choose December 8, 2002 the date that would be stored would be December 20, 2002.
Fairly annoying. Any ideas?

Anonymous2-Nov-02 10:18

Re: Reading binary files with c stdio fread

2-Nov-02 10:18

I thought the following would read in blocks of 15 floats from a binary file but after a bunch of correct reads all the output numbers are giberish, numbers like 1E-20 type stuff..

I have to use stdio routines like fread, I have written the same code with fstreams and it works fine. I am missing some stdio quirk or something.. It seems to get hosed when the _cnt variable in the FILE structure becomes < then the size of 15 floats (60).. I believe it has to do with the buffering of the file, which is the system 4096 size.

float CPDATA[15];
do{
fread((char*)CPDATA,sizeof(float)*15, 1, thO->fd);
//outfile read info to a file
outfile<<ftell(tho->fd)<<" ";
for(int i=0;i<15;i++)
outfile<

Anders Molin3-Nov-02 2:48

Anders Molin

3-Nov-02 2:48

Anonymous wrote:
fread((char*)CPDATA,sizeof(float)*15, 1, thO->fd);

Just an idea, try with fread((unsigned char*)CPDATA,sizeof(float)*15, 1, thO->fd); instead...

- Anders

Money talks, but all mine ever says is "Goodbye!"

Serialization Progress

Ted Christiansen2-Nov-02 9:42

Ted Christiansen

2-Nov-02 9:42

Hello,

I need to display the progress during a file open (serialization) process. I have looked for some examples of how to do this and havent found any. Has anyone worked on this? The easiest approach might be to use the file size and the number of bytes read?

Ted

Re: Serialization Progress

ian mariano2-Nov-02 9:51

2-Nov-02 9:51

That's the easiest approach:

//  assumes m_wndProgress is your window and this is MFC
m_wndProgress.SetRange32(0, nFileSize);  // nFileSize is total size
m_wndProgress.SetPos(0);  // to reset

while(/*  more data to read */)
{
  //  read in some data
  m_wndProgress.SetStep(nReadSize);  // nReadSize is how much you read in
  m_wndProgress.StepIt();
}

Here's a cool way to add the progress bar to the status bar: Showing progress bar in a status bar pane[^]

"The greatest danger to humanity is humanity without an open mind."
- Ian Mariano

http://www.ian-space.com/

Philosophical question

C^hris L^osinger2-Nov-02 9:21

2-Nov-02 9:21

if you have a file, foo.cpp, which contains the implementations of some (C-style, not classes) functions used elsewhere in the app, and a header file, foo.h, which defines those functions, would you #include "foo.h" inside foo.cpp ?

assume there's nothing in foo.h that foo.cpp needs: no constants, struct definitions, etc. foo.h simply provides an external definition of the functions in foo.cpp.

strictly, i think it's unnecessary, because the functions aren't really dependent on the external definitions - that association doesn't happen until the linker gets involved and it needs to match what callers of foo's functions think those functions are to the functions that the linker has available.

on the other hand, it seems logically 'right' to associate them somehow.

opinions?

-c

“losinger is a colorizing text edit control”
-- googlism

let me answer my own question...

C^hris L^osinger2-Nov-02 9:46

2-Nov-02 9:46

if foo.h defines those functions as 'extern "C"', you actually have to #include the header with the functions, or else the compiler will define them as C++ functions, and you'll get linker errors.

carry on, my wayward sons.

-c

“losinger is a colorizing text edit control”
-- googlism

ian mariano2-Nov-02 9:42

2-Nov-02 9:42

You don't have to even #include an .h (in C or C++) if you define the prototypes of any functions used in your implementation file Big Grin | :-D

I, personally, include the header for readability. And besides, you can write the functions in any order since all their prototypes are defined ahead of time.

Of course, if you want "C" linkage you have to define them as extern "C".

"The greatest danger to humanity is humanity without an open mind."
- Ian Mariano

http://www.ian-space.com/

ColinDavies2-Nov-02 9:43

ColinDavies

2-Nov-02 9:43

Why then would foo.h exist at all ?
Shouldnt foo.cpp be foo.c to distinguish itself ?
IMHO if you use .cpp as an extension you should hold the relevant .h header as per normal usage.
But if it's C you should name it as such as well.
Sure it won't make any differences to compiling but it becomes easier to have conventions to follow.

Regardz
Colin J Davies

Sonork ID 100.9197:Colin

You are the intrepid one, always willing to leap into the fray! A serious character flaw, I might add, but entertaining.
Said by Roger Wright about me.

Gary R. Wheeler3-Nov-02 4:29

Gary R. Wheeler

3-Nov-02 4:29

Include foo.h in foo.c so that the compiler validates how you've declared the functions (foo.h) with how you've defined them (foo.c). Since the other parts of your software that use the functions in foo.cpp use the function prototypes in foo.h, this helps ensure that the callers and the callee agree on the type and order of parameters.

The only time I omit a header file for each source file is when there is a single header (ex: library.h) for multiple source files (library_part1.cpp, library_part2.cpp, etc.).

Software Zen: delete this;

C^hris L^osinger2-Nov-02 9:49

2-Nov-02 9:49

foo.h exists so that the rest of the app can get at the functions in foo.cpp.

and, only the functions it exports are C, foo.cpp may use C++ internally.

-c

“losinger is a colorizing text edit control”
-- googlism

C^hris L^osinger3-Nov-02 5:33

3-Nov-02 5:33

Gary R. Wheeler wrote:
so that the compiler validates how you've declared the functions (foo.h) with how you've defined them

but it doesn't do this. it doesn't care if MyFunc is defined differently than the implementation. try it.

-c

“losinger is a colorizing text edit control”
-- googlism

markkuk2-Nov-02 12:49

markkuk

2-Nov-02 12:49

Including foo.h would make sure there aren't any conflicts between declarations and actual functions. Of course the linker will eventually catch any typos in either file.

C^hris L^osinger2-Nov-02 13:34

2-Nov-02 13:34

markkuk wrote:
Including foo.h would make sure there aren't any conflicts between declarations and actual functions.

actually, it wouldn't. because you can overload functions in C++, the compiler will ignore any differences. and that's the basis of the problem - the compiler really doesn't care. the only reason to include foo.h would be for my own benefit (ignoring the extern "C" linkage stuff)

-c

“losinger is a colorizing text edit control”
-- googlism

Anonymous4-Nov-02 4:17

4-Nov-02 4:17

If you also put the extern "C" on the actual functions, then the compiler will do the check for differences. When I setup a C++ source file that I want to have extern "C" functions, I always also add this to the actual functions to make sure that there is a match. If I leave off the extern "C" on the actual function and it doesn't match the prototype, I won't get an error until linking.

Best regards,
John

Does anyone know this error??

Gary R. Wheeler5-Nov-02 10:41

Gary R. Wheeler

5-Nov-02 10:41

Hmm. I think I see where the confusion lies. With C++ and overloading, you're right. Having foo.h does not guarantee that the implementation in foo.cpp will be verified by the compiler, unless you use the 'extern "C"' construct. I believe Visual C++ compiles sources named .C as if they are 'extern "C"' by default.

In any case, I think it's better stylistically to have a header file than not. Other people looking at the code will expect to see it. If you don't include the header file, then other folks reading the code will have to look at each use of the function(s) to see how they are used. Also, I normally consider the header file to describe the controls for a black box (the 'interface' to the black box) while the source file is the 'implementation' of the black box. I then document changes to the interface in the header file, and changes to the implementation in the source file.

Just my $0.02.

Software Zen: delete this;

Pett2-Nov-02 8:50

Pett

2-Nov-02 8:50

Hi!

I'm still working on my assignment to modify my chat program to have the capability to transfer files as well as messages.

I put a button on the client side, and when the person clicks on it, the file dialog box is supposed to open, and the person can choose the file to send.

I get the dialog box, the program gets the file path.. reads the file ok.. and now it is being sent to the server.. (I've made progress!) Smile | :)

However, the server gives an error, "An attempt was made to access an unnamed file past its end". Confused | :confused:

If anyone knows what the error means exactly, or can give any suggestions about it... please respond.

Thank you.. Smile | :)

Re: Does anyone know this error??

Anonymous2-Nov-02 13:42

Re: Does anyone know this error??

2-Nov-02 13:42

How are you reading and writing the file? If you are chopping it up and sending it you may be reading into the file past its end same as when you receive the file.. could you post some code?

Pett3-Nov-02 4:48

Pett

3-Nov-02 4:48

Thank you so much for replying to me. Smile | :)

The following is my send code when the button is clicked. I found most of it on this site:

void CMainFrame::OnSFile() <br />
<br />
{<br />
MessageBox("File Transfer");<br />
<br />
CSocket cSocket;<br />
cSocket.Create();<br />
//cSocket.Connect((LPCTSTR(m_strServerIP)),m_iFTPort);<br />
cSocket.Connect("127.0.0.1", 700);<br />
<br />
csocketfile sf(&cSocket);<br />
CArchive ar(&sf, CArchive::store);<br />
<br />
/*code for CFileDialog goes here*/<br />
<br />
static char BASED_CODE szFilter[] = "All Files (*.*)|*.*||";<br />
<br />
CString strPath;<br />
<br />
CFileDialog m_ldFile(TRUE,".*","*.*",OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, szFilter);<br />
<br />
// Initialize the starting directory<br />
//m_ldFile.m_ofn.lpstrInitialDir = _T("C:\\");<br />
<br />
// Show the file open dialog and captures the result<br />
//if IDOK<br />
if (m_ldFile.DoModal() == IDOK)<br />
{<br />
<br />
strPath = m_ldFile.GetPathName();<br />
CFile myFile(strPath,<br />
CFile::modeRead | CFile::typeBinary); <br />
 <br />
//get file info <br />
DWORD length = myFile.GetLength();<br />
 char *data = new char[length];<br />
 myFile.Read(data, length);<br />
 <br />
//send it across<br />
ar << myFile.GetFileName();<br />
ar << length;<br />
ar.Write(data, length);<br />
delete[] data;<br />
myFile.Close();<br />
<br />
}<br />
<br />
 }

--------------------------------------------------------------------------

On the server side, I've put this as the receiving code. Maybe I've put it in the wrong place? Unsure | :~

There is a void
CClientSocket::OnReceive(int nErrorCode) which is an overrided method
from the CSocket class. So basically whenever the socket receives
something, it kicks off the OnReceive code. I've put it there.

Also, in my Send code, there is a line commented off, and replaced with a hardcoded statement. Before I did that I was getting another error, "An unknown error occurred while accessing an unnamed file"

I'm going to try changing around a few things, but if you have any suggestions on thoughts on this, please let me know.

Thank you so much.

Newbie question - C++ 6.0 Pro or Standard?

jta2-Nov-02 8:17

jta

2-Nov-02 8:17

Sorry for this elementary question -- but I'm having trouble finding a simple answer.

I am planning to work with another developer who uses Visual C++ 6.0 to do his coding. I would like to be able to compile the source code that he sends to me. For my limited application (just compiling someone else's work, not doing any coding myself) will Visual C++ 6.0 Standard work as well as the Professional edition? What are the substantive differences between Standard and Pro?

Thanks.

Re: Newbie question - C++ 6.0 Pro or Standard?

ian mariano2-Nov-02 10:04

I/O Completion Port and Queue Status :: Winsock

2-Nov-02 10:04

Microsoft Visual C++ 6.0 Features by Edition[^].

It depends on what features of the compiler he's using. You need to use a "version" >= his version, i.e., if he's using pro, you probably should use pro or enterprise to compile.

"The greatest danger to humanity is humanity without an open mind."
- Ian Mariano

http://www.ian-space.com/

valikac2-Nov-02 8:04

valikac

2-Nov-02 8:04

Hi.

I am in the process of implementing a IOCP on a Windows program. The program works as designs using WSAAsyncSelect I/O.

Under IOCP, for some reason the call to function GetQueuedCompletionStatus(...) returns immediately even when I specify INFINITE wait. Thus, the cpu usage is aways at 100%. This occurs during program initialization as I want the program to create a completion port on startup. Again, the creating of the completion port does not run an error. The creation of the worker thread to handle completion events and where GetQueuedCompletionStatus(...) resides does not run an error.

However, for some reason, GetQueueCompletionStatus(...) returns immediately even with the INFINITE parameter. This occurs while the completion port is empty, or there are no sockets associated with it yet. How is that possible? And each time it returns, the byte transfer is always 0.

Please post if you have any suggestion as to where to begin debugging.

Thanks,
Kuphryn

Re: I/O Completion Port and Queue Status :: Winsock

ian mariano2-Nov-02 10:09