|
You'll have to read the beginning of the file. If it is a WAV file, bytes 0-3 will be have the ASCII chars: "RIFF" and bytes 8-11 will say "WAVE". Here's an example of the beginning of a wave file:
RIFFR) WAVE
-------------------------------------------------------------
01234567891011 -- Bytes
I'm not quite sure about an MP3 but it should be similar. Just do some research on the file format.
|
|
|
|
|
I have a project that has 2 versions of the exe (a 'lite' and a 'pro' version) and I want to do as much code sharing as possible. I know that using #define has fallen out of vogue for storing constants, but is there a 'new' C++ way of doing code sharing without using #defines as switches? My current in-mind solution is to create multiple build configurations and set different compiler switches for each one, and then wrap dependent code within those defines (i.e. "#ifdef _PRO_VERSION", etc).
Is this the way to do it? I've also played with having multiple 'projects' within the 'workspace' but I think this would complicate code sharing beyond what I'm willing to deal with.
Any thoughts on the subject would be greatly appreciated.
Thanks!
-jfaulken
When sushi is outlawed only outlaws will have sushi.
|
|
|
|
|
#define and #ifdef is still my preferred way of doing it. I too would be interested to know if there is a better way.
Michael 
|
|
|
|
|
I have seen some workspaces which use multiple projects and I thought they made things look more complicated than they actually were (mind you I am quite new to VC++). My personal preference is the #ifdef approach using one project in a workspace, hope this helps makes your mind up on the issue.
"When I left you I was but the learner, now I am the Master" - Darth Vader
|
|
|
|
|
but is there a 'new' C++ way of doing code sharing without using #defines as switches?
Do not create new projects, they are not designed to do that; just for multiple configurations. Use #ifdefs, but without #defines. The symbol which controls which functionality goes into the binaries should be defined in the Settings/C++/Preprocessor definitions. The only difference between Debug-Pro and Debug-Lite (and corresponding release versions) config should be the presence/absence of _PRO_VERSION.
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
That's precisely what I did. Thanks for the input, everyone.
One additional piece of info that turned out to be very important... if you're using conditionals with your resources in order to make them selected into one configuration or another, you must additionally put the preprocessor define in the box under Settings/Resources/Preprocessor definitions or the resource compiler simply won't see it.
That killed about half an hour. ^_^
Thanks again for all the input!
-jfaulken
When sushi is outlawed only outlaws will have sushi.
|
|
|
|
|
That killed about half an hour. ^_^
Don't worry - I've spent much more time on that
Tomasz Sowinski -- http://www.shooltz.com
|
|
|
|
|
Ifdef - endif is preffered method - indeed.
But there is another method often used too.
You can create two projects. Common files can be included in both projects. If some functionality needs to be in pro version, You can write empty function/class in version lite. Both will link, but only one will have real implementation.
Which method to use? It depends on the number of code/files and Your preferences.
I personally use ifdef method if there are not many changes.
|
|
|
|
|
Hello,
I know I have seen articles on this site regarding executables that accept switches eg.(test.exe /? for help).. I can't seem to find any of those articles.. Does any one have a link to a article on how to implement exe's that take switches?
Thanks,
Rob
|
|
|
|
|
|
|
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.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
