|
|
okay.. i've used fopen for too long, now i want to get rid of it.. so i started using fstream..
the problem right now is that i would like to STREAM all the data in a file into a std::string - object..
i've tried sthing like:
string line;
ifstream file(sz_path1);
file.read (line);
msdn says:
"The read Function
The read member function reads bytes from a file to a specified area of memory. The length argument determines the number of bytes read. If you do not include that argument, reading stops when the physical end of file is reached or, in the case of a text-mode file, when an embedded EOF character is read."
the first error i get is that there should be just one argument.. okay.. wdf should says the msdn text ???
other thing.. if there would be a possibility for doing that, would there be a way to stream directly into a string ??
or do i have to use a stringstream ??
BTW: i already tried to use getline.. but it doesn't work, cause i need the whole context...
thanks in advance and have a nice one
bernhard
""Politicians and diapers have one thing in common. They should both be changed regularly and for the same reason."
|
|
|
|
|
Hi,
I just got a new monitor, a Samsung SyncMaster 151BM flatscreen (nice!). But I also go myself a spurious problem. Whenever I compile something with VC++ 6.0 the screen goes black, showing a caret in the upper left corner (reminds me of the ol' DOS days, but no prompt  ) and a white box as the mouse cursor. When compilation ends the screen goes back to normal, and all the little messages from the compilation is present in the Build box. I have fumbled around with both a generic MS driver for the monitor and with the Samsung driver included with the monitor (no updated one present), but to no avail.
Has anybody seen this phenomenon before?
My box is a HP Vectra 800MHz with 256 MB RAM and running Win2K Pro (corporate setup).
Cheers
Steen.
"To claim that computer games influence children is rediculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
At a guess this is VC making a call to the command prompt to run a tool of some kind. Try changing the background colour of your command prompt and see if the same background colour appears in the compiler.
Michael
|
|
|
|
|
You're right, of course. I found out that during a long compile I could switch away from the black screen using alt-esc, and briefly see a command prompt icon flicker on the task bar. Now the question is, why doesn't the focus return to the IDE window during the compilation, but stays on the command prompt window until the compile is finished? I have checked a number of flatscreen monitors as well as normal CRT ones, and they all displayed this phenomenon. So it has nothing to do with the monitor, perhaps my updated Intel Graphics Technology driver is to blame? Or did I inadvertently set some default parameters for command prompts in a special way to get this? I, for one, am completely lost here.
Cheers
Steen.
"To claim that computer games influence children is rediculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
How does a normal command prompt open? I've never seen this problem before, but it is probably some screwed setting on the command prompt? Are you upto date with all the service packs, both VC and Windows?
Michael
|
|
|
|
|
Hi Michael
apparently my Win2K has been set to open all console apps in fullscreen mode by default, hence the black screen (this was pointer out to me by Michael Dunn). It's described in Q126031 in MSDN KB. I simply removed this default fullscreen mode in the registry and the problem evaporated!
Thanks for all your help
Cheers
Steen.
"To claim that computer games influence children is rediculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
I had the same problem a long while ago. As I remember, I reinstalled visual.
Problem was caused by Visual installation which was not full. Something was missing and visual tried to get it from CD.
Hope this helps
|
|
|
|
|
What happens is the IDE launches cl to do the compiling. cl is a console app, so you're seeing the console window. I know I've seen a KB article on this, give a search of MSDN on "cl console" and you should find it.
--Mike--
http://home.inreach.com/mdunn/
#include "witty_sig.h"
![Heart | [heart]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/love.gif) your ![Green Alien | [Alien]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/alien.gif) with ![Good Stuff | [The good stuff]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/vegemite.gif) and ![Beer | [beer]](https://codeproject.global.ssl.fastly.net/script/Forums/Images/beer.gif)
|
|
|
|
|
Wow! You're absolutely right. The KB article is Q126031. The problem was that my Win2K was set to start console apps in default fullscreen mode. When I remobed this setting in the registry the problem evaporated!
Thanks 1M times!
Cheers
Steen.
"To claim that computer games influence children is rediculous. If Pacman had influenced children born in the 80'ies we would see a lot of youngsters running around in dark rooms eating pills while listening to monotonous music"
|
|
|
|
|
Hi guys !!
I have to do this.
On my terminal server, i need to shared the process doing the communication (outside to the control pannel).All other connected(logged) user must see the shared memory created by this process (attach to it).
In resume, in my app i have a process doing the communication with the control pannel. When i start the app, the process bind some port. My problem is on the terminal server (because some Unix client whant 2 see the data) many user can start their own session but when they open the app, the process popup an error message causing by the communication port already open. My solution, create only one process stay open forever and share the data. How i can do this ?
I try with some CreateFileMapping(); ... in the task manager i see the process running but i cannot attach 2 the shared memory. Can someone explain this 2 me?
Regards,
Vincent Filion.
vincent.filion@cae.com
If you whant more details send me a mail.
|
|
|
|
|
Does anyone have any tips on increasing the performance when building large apps - especially the link cycle. I have a few large projects that seem to be taking longer and longer to build. I have a 700Mhz Dell laptop with 256MB of RAM and plenty of disk space free (~4GB) - any tips?? (a new PC is out of the question ... )
|
|
|
|
|
If you're running a Virus Scanner, turn it off.
If you have browser info turned on, you could turn that off.
The bottleneck during a compile is the speed of your hard drive. A crap-load of temporary files are created, not to mention an obj and sbr file for each CPP file in your project. Since all these files go to the hard drive, that's where you have to focus your attention. If you're not already using one (and if your motherboard supports it), get an ATA66 or ATA100 drive (and the necessary cables of course).
I don't know if this matters, but I have the compiler, the temp folder, and my source code all on different drives, and Everything moves right along in terms of speed.
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
Does anyone have any tips on increasing the performance when building large apps - especially the link cycle.
Is your app a monolithic .exe, or you've split the functionality into multiple .dlls?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Pretty much a monolithic EXE but I have created .libs for a lot of robust code that rarely needs to change.
|
|
|
|
|
So linker has lots of work to do - it has to copy the stuff from static .libs to your .exe. Of course, this reduces the work for compiler. You may consider moving parts of the app to .dlls - in such case, the linker doesn't copy the function bodies, only creates the references to .dll in the file.
Are you running MSDEV.EXE with /Y3 option? What are the exact times of compile and link?
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
I will experiemtn with using DLLs instead of static LIBs and see if this improves performance.
What will the /Y3 option do for me?
|
|
|
|
|
What will the /Y3 option do for me?
It displays the compile/link times in the output window.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Are you using incremental linker (for your debug builds)? It may be slower the first time but it should be faster afterwards if only few files have changed.
Also, you could verify that linker options and disable some of them in you debug builds.
Also, a tip is too avoid running other disk intensive application at the same time. This effectively could increase link time a lot.
And limit the debugging informations in file where it is not so usefull. Probably for many files, line information will suffice and linking an application without much debug information could be much faster.
Philippe Mori
|
|
|
|
|
Challenge: How do you determine the physical dimensions of your pixels/monitor?
There must be a smart way of determining the real size of a pixel, or at least figuring out the width:height ratio!
I can't believe that information has not been stored with the video driver but unfortunately it seems to be the case.
Does anyone know of some clever way to work out the physical monitor view dimensions? Implicitly this could mean working out the real pixel size, pixel ratio, pixels per inch...
I know there's information to retrieve using GetDeviceCaps but they are for some strange reason fix values. They don't change!!! Why is that?
There's a huge prize waiting for you if you accept and solve this quiz/challenge... Well, not really, but I'd be very grateful!
And measuring the screen by hand does not count!
/Tommy
|
|
|
|
|
I don't think you can get 'real' sizes. The way to calculate pixel ratio and draw rulers with inches/centimeters is to use GetDeviceCaps with LOGPIXELSX/LOGPIXELSY.
I know there's information to retrieve using GetDeviceCaps but they are for some strange reason fix values. They don't change!!! Why is that?
Probably it's because video driver doesn't care if monitor has 15 or 49 inches  And imagine a CRT projector connected to your graphics card which displays an image on the wall. In this case, these values would depend on the distance between the device and the wall  Your machine would have to be equipped with some sonar system.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Ok, that's what I thought... But are you saying that you can create rulers in inches/centimeters using the LOGPIXELSX/Y? Ok, you can create them but they will not reflect the real size on screen right?
Intuitively it feels like there's a solution to this... just gotta get someone to find it!
/T
|
|
|
|
|
Ok, you can create them but they will not reflect the real size on screen right?
Exactly. That's why the parameters you pass to GetDeviceCaps are called 'logical' pixels, not 'real' pixels. One more reason for that: you have controls in your monitor for adjusting the width and height of actual picture displayed on the screen - your graphic card is of course unaware of these adjustments.
If you find any program that draws rulers using *real* centimeters/inches, let me know
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Try these functions:
void MyFunc(CDC* pDC)
{
int logx = pDC->GetDeviceCaps(LOGPIXELSX);
int logy = pDC->GetDeviceCaps(LOGPIXELSY);
int nMM = 100;
int nPixelsX = MmToPixels(nMM, logx);
int nPixelsY = MmToPixels(nMM, logy);
}
int MmToPixels(int mm, int LogPixels)
{
return ((int)((long)mm * LogPixels / 25.4));
}
int PixelsToMm(int Pixels, int LogPixels)
{
return (int)(Pixels * 25.4 / LogPixels);
}
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
To determine the "viewable area", get the horizontal and vertical resolution windows is currently set to, and convert those pixel values to millimeters (using the PixelsToMm function). If you need it in inches, it is a simple matter to convert mm to inches, and there you have it.
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
