|
|
I assume u mean, #include <string> should be #include <cstring> ?
I tried that and it didn't work  I got the same errors. The book I'm using says to use #include <string>.
Cheers.
|
|
|
|
|
I assume u mean, #include <string> should be #include <CString>?
I tried that and it didn't work I got the same errors. The book I'm using says to use #include <string>.
Cheers
|
|
|
|
|
There is a big difference between a string object and CString object. The former is STL while the latter is MFC. Also, there is no such file as cstring. Had you used it, the preprocessor would have rightfully complained.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Compare the positions of your using namespace std and #include "details.h" lines. Since the include is first, the compiler hasn't seen the using yet, so it doesn't know what string is. Either change the code to "std::string" (preferred) or put the using in details.h (bad practice once you get to large programs as many usings can lead to name collisions, which is what namespaces were designed to prevent).
--Mike--
Personal stuff:: Ericahist | Homepage
Shareware stuff:: 1ClickPicGrabber | RightClick-Encrypt
CP stuff:: CP SearchBar v2.0.2 | C++ Forum FAQ
----
You cannot stop me with paramecium alone!
|
|
|
|
|
Thank you very much Mike, that makes perfect sense. I'll look at it tomorrow.
Cheers,
Graeme 
|
|
|
|
|
lordmickel wrote:
cout << Enter driver name: " endl;
There are two problems with this statement. I'm sure your compiler has already pointed them out.
lordmickel wrote:
c:\program files\microsoft visual studio\myprojects\text_class\details.h(7) : error C2146: syntax error : missing ';' before identifier 'get_name'
How are we supposed to know what line 7 of details.h is? Mark the lines that are in error. It would also be beneficial to fix the #include statements (so that we don't erroneously suggest a file that is already being included).
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
Sorry for the most unhelpful error message. I know how annoying that is. I managed to sort the problem out thanks to everyone's help.
much appreciated.
lordmickel
|
|
|
|
|
For an i/o bound processing job, which would be faster:
1) Memory map the file and process it in place
2) Use overlapped I/O, reading into one of 2 buffers, while processing the other (pipelined)
On a single cpu, would I get any benefit from #2?
On a dual cpu, does #1 get no improvement over that on a single cpu?
Thanks.
|
|
|
|
|
If you are truly I/O-bound then I suspect that overlapped I/O would be fastest since it would allow for I/O to happen simultaneously with data processing. You might need to adjust your buffering scheme to take maximum advantage. One option is a buffer/thread pool where some (or one) buffers can be read, some processed, and some written, all at once.
__________________________________________
a two cent stamp short of going postal.
|
|
|
|
|
Scott H. Settlemier wrote:
For an i/o bound processing job, which would be faster:
1) Memory map the file and process it in place
2) Use overlapped I/O, reading into one of 2 buffers, while processing the other (pipelined)
For me it would really depend on the nature of the processing and the app.
Scott H. Settlemier wrote:
On a single cpu, would I get any benefit from #2?
Other than having code that would scale to hyperthreaded and multi processor hardware well ... probably not.
[edit] DOH! i read it as IOCP, see peters reply for more appropriate reply [/edit]
Scott H. Settlemier wrote:
On a dual cpu, does #1 get no improvement over that on a single cpu?
The file is on one disk and is being read by one thread, i would say no (not directly, but you would indirectly).
Each method has its strengths, it really depends on the requirements.
...cmk
Save the whales - collect the whole set
|
|
|
|
|
1) A Memory Mapped File can avoid the cost of copying data around (file cache <==> your buffers), this is especially helpful with large amounts of data
2) Overlapped I/O - if supported by the hardware, but any decent box should now - works directly between disk controller and RAM, without requiring the CPU.
Which one is better strongly depends on your application, and the box it runs on. Share some more info (what kind of I/O, how often, how much data, etc.)
we are here to help each other get through this thing, whatever it is Vonnegut jr.
sighist Fold With Us! || Agile Programming | doxygen
|
|
|
|
|
It's a generic class for all instances of work that's i/o bound.
Specific uses are filters and hashes which take a score or so
of cycles per byte of data. (much less than time to read the data)
I'm allocating the buffers on the stack and using overlapped i/o
but wasn't sure if the operating system was actually able to
asynchronously read the data or if just spawned another thread to
do it.
If it's just another thread, for a single processor, it'd seem
better to just use a memory mapped file right? No overhead for
the wait operations and processor is fully tied up reading
(on each page fault) or processing.
If overlapped i/o really is asynchronous on a single processor,
then what I've got now should be optimal.
Also I wonder, if the OS has the capability for real asynchronous
reads on a single processor, would it be using that to help
page in from a memory mapped file? Maybe the memory mapped file
can match the overlapped i/o technique because the os is smart?
(opened with sequential access for clue? I doubt but wonder.)
(yeah buffer sizes are calculated for optimal size-- you have to
pass working block size, processing cost and wait cost (about 10K
cycles I found from experiments on XP) for the overlapped i/o--
it can be shown that optimal # of rounds is independent of read
cost assuming that it's greater than processing cost.)
Thanks!
|
|
|
|
|
Hi! I have this sort of set up in my code:
FILE *gen; int i;
gen = fopen("data\\gen.dat", "r");
fscanf(gen, "%c", &i);
Now at this point in the code the next couple of bytes are useless. How do I skip them out? I could run fscanf a couple of times but Im positive this is not the best solution.
Thanks!
|
|
|
|
|
|
use seek or fseek
- Shailesh
|
|
|
|
|
If it's just a couple of bytes, there is nothing wrong with using an additional fscanf(). Just read the bytes into a variable named something like extra or fluff.
"When I was born I was so surprised that I didn't talk for a year and a half." - Gracie Allen
|
|
|
|
|
bRes = PlaySound( (LPCTSTR)SND_ALIAS_SYSTEMASTERISK, NULL, SND_ALIAS_ID | SND_NOSTOP | SND_ASYNC | SND_NOWAIT );
Works fine with all Windows platforms except Win ME. The crash only occurs when trying to play system sounds.
Is there something to do?
Thanks!
|
|
|
|
|
Hi All!
I have to write a client application which would use sockets to get data from partucular device via TCP\IP. Client code will reside in dll and should run under Windows 98 - XP. I think I can use WinSock 2.0 for this, but the problem is that my application should be easily ported to Linux later. Of course it cannot be just recompiled, but i have to acheive best compatibility possible to make my life more easy later when porting time comes. Unfortunately my knowledges regarding sockets are just theoretical. Could you please, suggest me what should be avoided to make WinSock 2.0 (or 1.1) based solution more or less portable to BSD based sockets solution. I understand that WinSock was written based on BSD sockets API but anyway, there should be something wrong Additionally, data sending, receiving, connection process will be run in separate threads, so some comments regarding portable notifications (or solutions to be notified) of task completion would be very helpful. If the topic is too large then could you please, point me to some Article which covers the problem?
Thanks in advance!
Best regards,
Dima
|
|
|
|
|
Short answer:
If you look at the winsock api reference most of the functions that start with a lower case letter are portable. The ones that start with and upper case letter are MS specific.
So, for example, you would use:
socket, accept, connect
as opposed to:
WSASocket, AcceptEx, ConnectEx
As for portable notifications ...
I find IOCP to be too usefull to ignore in the name of portability.
I would suggest this for windows.
There are number of good articles here on using IOCP.
For UNIX either mimic IOCP, use select, or roll you own.
In the end i would suggest you write a socket class that hides the OS specific issues.
Create one optimized for windows and another for unix, but both with the same public interface.
...cmk
Save the whales - collect the whole set
|
|
|
|
|
Does anyone have any idea of how to do what Windows Explorer does in the "Folders Options/View/Advanced Settings": Use radio buttons in a standard system treeview?
I checked out this article (XP theme aware TreeView control which supports checkbox and radio button nodes), but it's using .net and it seems to be using bitmap images (I could be wrong though). I just want to use Win32 APIs to do this. I think it should be possible because in the Platform SDK, it states that "When set to this style [TVS_CHECKBOXES], the control effectively uses DrawFrameControl to create and set a state image list containing two images"; however, I tried to imitate this to no avail. I tried using DrawFrameControl but it always draws the flat, non-themed styled control (all other controls in the window is correctly drawn with the XP theme looks).
Please help! Any advice is much appreciated!
Thanks.
Ken 
|
|
|
|
|
Hi all,
I have written a DLL that is statically linked to the MFC and it #imports ADO just like this...
#pragma warning(push)<br />
#pragma warning( disable : 4146 ) // ADO compile warning cannot be avoided<br />
<br />
#import "c:\Program Files\Common Files\System\ADO\msadox.dll"<br />
<br />
#import "c:\Program Files\Common Files\System\ADO\msado15.dll" no_namespace rename("EOF","EndOfFile")<br />
<br />
#pragma warning( default : 4146 ) // Restore warnings for rest of application<br />
#pragma warning(pop)
My DLL has a global variable defined as :
_ConnectionPtr pConn;
The first function exported calls CoInitialize(NULL) and this works fine.
Next some other exported function calls use the pConn variable to check if we can connect to a given database. This works fine and no exceptions are created.
The last function exported calls ::CoUninitialize() and this works ok.
My problem at the moment is that after I call the last exported function I then close my test application. When I close my test application I am getting a serious access violation as follows:
'Unhandled exception in (MSDART.DLL) 0xC0000005: Access Violation'
I have MDAC 2.71.9040.2 installed. I am running on Windows 2k and using MSVC6.0.
Any ideas you can offer me would be greatly appreciated.
Kind Regards,
Chris
|
|
|
|
|
You need to set pConn to NULL before calling CoUninitialize(), it's destructor is being called by your app's exit. A _com_ptr's destructor calls Release on the interface pointer if it's not NULL, and the results after calling CoUninitialize() are undefined. Good luck.
|
|
|
|
|
That solved it. Thank you very much!
Chris
Anonymous wrote:
ForumVisual C++
Subject:Re: ADO Crashing big time!
Sender:Anonymous
Date:13:04 27 Sep '04
You need to set pConn to NULL before calling CoUninitialize(), it's destructor is being called by your app's exit. A _com_ptr's destructor calls Release on the interface pointer if it's not NULL, and the results after calling CoUninitialize() are undefined. Good luck.
|
|
|
|
|
<big><small><small><pre>:laugh::confused:   -O      
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
