|
That was not the question. I'd like to know if there is any compile time benefit to use #pragma once as implied by MSDN. Theoretically there could be an advantage since the header files do not have to be opened multiple times which would be the case whan using defines. But since gcc detects include guards (which makes pragma once obsolete) i'd like to know if VS 2005 has such a feature too.
|
|
|
|
|
It may not have been the question but it certainly is an important and related observation. In fact most code that uses #pragma once has include guards first then the #pragma once for this exact reason.
Steve
|
|
|
|
|
I thought that was for portability.  I mean, what's the point of having include guards and #pragma once? If you just want to know if a file has been included already this would suffice:
#pragma once
#define __FOO_H__
--
Mr. Bender's Wardrobe by ROBOTANY 500
|
|
|
|
|
I stand corrected. I don't know what I was smoking when I wrote that.
Steve
|
|
|
|
|
As Mr. Dunn has mentioned you would need to measure it, and I don't think any of us have.
However, using precompiled header files REALLY does produce noticeable results. That is where I would focus my attention.
|
|
|
|
|
Hi all,
I wrote a TCP/IP client & server. The client(s) sends files for the server and the server sends files to the client(s). The server knows with which client it's communicating, by means of the computer name. The problem I'm experiencing is that if multiple clients connect, the computer name(s) of the clients gets overwritten by the next connection. I'm using this structure within a loop without success. I know this is a very though question, because alot of the code is not present, but it's like having an array and trying to keep the correct name with the correct 'connection' whiles in a loop.
<br />
static struct<br />
{<br />
int ConnectSock;
int ConnectState;
ULONG BytesTrans;
ULONG FileLength;
ULONG TimeMark;
char Request[STRING_SIZE];
char FileName[STRING_SIZE];
char PathName[STRING_SIZE];
char PCName[STRING_SIZE];
ULONG BytesRec;
} gConnectData[MAX_CONNECT];<br />
<br />
strcpy((char*)gConnectData[i].PCName,(char*)strDest);<br />
Many thanx in advance
The only programmers that are better than C programmers are those who code in 1's and 0's..... 
Programm3r
|
|
|
|
|
I don't know what you are doing in a loop that doesn't make any sense. If you have multpile connections you will need to use threading or overlapped IO. The structure should be a class and each instance could be stored in a STL collection (map, vector, etc. )
led mike
|
|
|
|
|
Thank you for the response led mike..
Like I said it's kinda hard to explain what is happening... but I will take what you said into consideration. Thank you.
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3r
|
|
|
|
|
« Programm3r » wrote: it's kinda hard to explain what is happening
When you say "what is happening" do you refer to the existing code implementation? If so then perhaps it is not an optimal solution. Transferring files is not rocket science. The description of the problem and the solution should be relatively simple.
led mike
|
|
|
|
|
"....Transferring files is not rocket science...." I argree, but the way I'm trying to do it, I'm not playing with rockets ... I'm playing with space ships .....
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3r
|
|
|
|
|
If you post your actual server code (just the accept part along with the thread for handling the client connections), someone might be able to point out your problem. You haven't given enough information about your code to get an informative response.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
Thanx for the response Zac, well I would like to post the code but it is about 1200 lines (client side) & 950 lines at the (host side).
But many thanx for your response...
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3r
|
|
|
|
|
« Programm3r » wrote: Thanx for the response Zac, well I would like to post the code but it is about 1200 lines (client side) & 950 lines at the (host side).
I'm not asking for the entire codebase, just for the relevant areas of code that you feel the problem may lie in.
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
You're right, its hard to see exactly what you are doing from such a short code snippet. Is it safe to assume that you are using the WinSock library? If so, your server-side program is listening for incoming connections on a specific port, right? When a client requests a connection, and the server accepts it, the server should spawn a thread for that specific connection, then continue listening for another connection while the thread handles the client that just connected. The server keeps a "global" array of 'gConnectData' structures as well as an index into the array. For each client connection, the INDEX is incremented and passed to the thread that handles the client connection, therefore keeping each thread from "bumping" into any other threads as they access the array.
There is a good book entitled "Windows Sockets Network Programming", by Bob Quinn and Dave Shute, that provides good working examples of this type of application.
Not sure if I've helped you any or completely misunderstood your problem.
Scott
|
|
|
|
|
Many thanx Scott, for the reply .... Well the thing is I am using WinSock, well kinda. I'm using MarshallSoft TCP/IP DLL. But I'll have a look at the book you mentioned..
Regards
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3r
|
|
|
|
|
OK, I'll try and explain it better....
Client Side:
The client sends command to the server, these commands include the following:
CMD_QUITCMD_GET_FILECMD_GET_PCNAMECMD_STATUSFILECMD_SENDFILESCMD_SENDFILEFORFILEMD_RECEIVEFILECMD_SENDSTATUSFILESo all of these commandshave a certain purpose on the client side. Please note that there are more than one client.
The client can send files to the server and the server can send files to the client via TCP/IP. Before the file transfer begins the client(s) ask the server if the files exists? On the servers response the client(s) makes decisions. The server knows with which client(s) it's communicating, because the client(s) sends it's name (PC NAME).
Server Side:
Please note: the following happens in a loop....
The server accomidates for each of the commands that the client(s) may send. It uses a function to get the command code and returns a certain command.
after returning the command, the server sits in a loop and waits for a client(s) to connect. When the client(s) connects the server uses a function to find a free slot. After assinging the connection to a free slot, the server puts the connection into a state namely:
STATE_REQUEST In this state the commands of the client(s) get executed.
So the thing is when two clients connect at the same time (and they want to transmit & receive files) the above happens but the computer name which the server uses to know with which client it's communicating gets overwritten by the next connection. Please note that only certain file may go to certain clients.
Regards
The only programmers that are better than C programmers are those who code in 1's and 0's.....
Programm3r
|
|
|
|
|
Out of curiousity, why not use WinInet's FTP functionality for this?
If you decide to become a software engineer, you are signing up to have a 1/2" piece of silicon tell you exactly how stupid you really are for 8 hours a day, 5 days a week
Zac
|
|
|
|
|
« Programm3r » wrote: the computer name which the server uses to know with which client it's communicating gets overwritten by the next connection.
Well that would be a "bug". Something is wrong with the code, perhaps a code error or a flaw in the design. A flaw in the design would require changing the design to resolve the problem.
I assume you are using TCP (Stream) connection, yes?
Is it stateful or stateless? Depending on that answer the design is different in only one aspect otherwise it is the same:
Each connection is considered a "Session" and any "state" required is maintained with the Socket handle. Threading or Overlapped IO is used to read/write data and of course perform required logic. Your protocol indicates you could also use a finite state machine implementation.
If it is a stateless protocol then you must add session identification and maintain session in the server.
It's basically that simple. If your design does not reflect that then you are likely in for a bumpy ride.
[After further reading of your post]
« Programm3r » wrote: When the client(s) connects the server uses a function to find a free slot.
Without a requirement that enforces the need for that behavior, that is a "bad" design.
« Programm3r » wrote: When the client(s) connects the server uses a function to find a free slot.
That description makes it sound like the server is single threaded. Handling the Server socket "accept" and the client connection communications on the same thread. If that is true that is a "bad" if not "horrible" (as in dead) design. Again without being aware of any specific requirements that would force that design it is just plain wrong.
led mike
|
|
|
|
|
Does anyone know how to convert pdf to tiff via Acrobat 5 writer automation?
I need sources.
Thanks,
Dudi
|
|
|
|
|
Dudi Avramov wrote: I need sources.
And one day you will call yourself a programer? I will call you a "Copy and Paster"!
|
|
|
|
|
In my SDI CFormView based application (Visua C++, Window2000), a CFileDialog type dialog box is used to select files. The dialog box works fine if I directly click the button to bring up the dialog box. However, if i click some other buttons to run some other routines before clicking the button for bring up the dialog box, then SOMETIMES the dialog box did not come up .
The code for the button click (to bring up the dialog box) handler is shown below.
<br />
CFileDialog * Cfieldialog = new CFileDialog(true, NULL, NULL, OFN_NOCHANGEDIR|OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT, "Text Files (*.txt)|*.txt|All Files (*.*)|*.*", NULL );<br />
<br />
Cfieldialog->DoModal();<br />
<br />
CString CStringTest = Cfieldialog->GetPathName();<br />
((CEdit*)GetDlgItem(IDC_EDIT_ExampleText))->SetWindowText((LPSTR)(LPCTSTR)Cfieldialog->GetPathName());<br />
<br />
delete Cfieldialog;<br />
<br />
<br />
This problem is biting me hard. Any help and hints would be appreciated very mcuh.
|
|
|
|
|
The filter is supposed to end with two ‘|’ characters.
"Approved Workmen Are Not Ashamed" - 2 Timothy 2:15
"Judge not by the eye but by the heart." - Native American Proverb
|
|
|
|
|
Hi,
I think problem is somewhere else - you said that if you click others buttons the it won't work. Try to find which exactly routine occurs unstable application proceeding.
-----------
Mila
|
|
|
|
|
Hello comunity,
how to get an pointer to an control that is on CTabCtrl placed, my problem is the grid control that is
on dialog in CTabCtrl!
Have Main Dialog with CTabCtrl, first tabitem have him own CDialog, and on that is my CGridCtrl whitch
pinter i need!
That is what i try before:
CGridCtrl* pGrid = (CGridCtrl*) ((CSecondDialog*) pMainDlg->GetTab(0))->GetDlgItem(IDC_GRID_LIST);
int iNumLines = pGrid->InsertRow(L"some text");
pGrid->SetItemText(iNumLines, 1, L"some text on column 2");
Is there any error in my cast?
regards
break;
-- modified at 9:41 Monday 20th November, 2006
|
|
|
|
|
I'm very new to C++ and haven't really touched it since 1996 in varsity. I'm now trying to build several chaotic open source projects, and I could use some help on how project structures, include directories, make files etc. all work. I'm basically looking for Teach Yourself to Structure and Build C++ Projects in One Evening, if anyone has seen it somewhere.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
