|
I'm not going to actually write code for this since it sounds much like a homework assignment. However, you might want to check out MSDN and also check out the CDocument save procedure.
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
|
|
|
|
|
Apart from beeing nonportable. Is there any benefit from using #pragma once over the standard include guards on a modern compiler like VS2005?
There used to e the argument that it is faster because the copmpiler does not have to reopen the include file multiple times. Is this still the case?
I would expect a state of the art compiler to automatically detect include guards which is the case in gcc but the sole existance of pragma once implies this it not the case with MSVC 8.x.
Am I right? What are your best practices?
|
|
|
|
|
|
Do the words "Implementation-Specific" or "platform dependant feature" mean anything to you? Please do yourself a favor and get a copy of the ISO 14882. Then find out why claiming any pragma directive has to be supported by any compliant compiler is complete nonsense. Any compliant compiler has to ignore pragma directives it does not know thats all.
|
|
|
|
|
No #pragma is "C++ compliant". The sole purpose of #pragma is to provide a hook for compiler specific control. 
--
Now with chucklelin
|
|
|
|
|
MSDN
Presently, #pragma once is NOT portable, so if you are writing code that might be compiled on another system or for another compiler, it is best to stick with include guards.
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
|
|
|
|
|
I know it's not supposed to be portable. But do you actually know any significant C++ compiler not implementing it? GCC has it and in fact they invented it, although it is commonly blamed on Microsoft, BCC has it, and MSVC has it. I would bet the Intel C++ compiler supports it too. So the non portability is just a theoretical issue. But thats not my question here. My MFC application is not portable by definition. So the question remains: Does it compile faster? If so and the code must be portable using both would be an option.
|
|
|
|
|
iberg wrote: I know it's not supposed to be portable. But do you actually know any significant C++ compiler not implementing it? GCC has it and in fact they invented it, although it is commonly blamed on Microsoft, BCC has it, and MSVC has it. I would bet the Intel C++ compiler supports it too.
Sun's compiler doesn't support it. Last I checked, Intel's didn't either. There are several that do, but it is not a standard extension, and it behaves differently on each compiler that does support it.
iberg wrote: My MFC application is not portable by definition.
Then you have nothing to worry about. Every MS compiler after VC6 has supported it.
iberg wrote: So the question remains: Does it compile faster? If so and the code must be portable using both would be an option.
According to Microsoft's documentation (the link I provided in the previous post), it does compiler faster since the preprocessor has to do less work. Though, a faster compilation is almost a pointless argument for using it in most cases. If you are writing your code for VS.Net (any version), it doesn't matter which you use. Chances are pretty high that you won't notice a significant increase in compilation time for 95% of the apps you write.
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
|
|
|
|
|
iberg wrote: GCC has it and in fact they invented it,
Actually, with GCC it is not that simple. They first introduced it, then removed it (or at least there was a warning it was obsolete) and relatively recently re-introduced it.
|
|
|
|
|
With #pragma once you can't test whether a header has been included. If you use #ifndef FOO/#define FOO as your include guards, you can use #ifdef FOO elsewhere to see if foo.h has been inclded.
EDIT: I didn't answer the speed question but unless you have really slow outdated hardware, I doubt you'd ever see any noticeable difference in compile times. Also, the ability to test whether a header has been included is nice, which is why I prefer guards to #pragma once even if there is a speed penalty. As with any perf question, you have to measure to be sure, otherwise you're just guessing (like I am right now  )
Last modified: 4hrs 33mins after originally posted --
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
