|
You need to tell, how this program is expectedt to work. And how it is behaving.
Charles Covington wrote: //declarations
double memory; //contains value in memory
double display; //contains contents of display
double number; //contains input number
string strInput; //contains an operator or command
char firstChar; //first char of input
char secondChar; //second char of input
int inputLength; //length of input
It is good practice to initialze variables on its declaration.
|
|
|
|
|
You didn't write what exacly is the problem, but i think I know. Maybe I'm wrong, but you've declared variables: double display,memory; and you haven't initialized them with any value (in your case the smart choice would be 0), so these variables contain random values, because they are declared in main's body, and not as a global variables (global variables==0). According to my scribble, in case like this:
cin >> number;<br />
display = display + number;<br />
display will always contain random values.
|
|
|
|
|
Any faster method to change the contrast of ab image......... OTHER than that unlock and unsafe method its very slow...... Is there anything else?????????
|
|
|
|
|
For starters, a faster method than WHAT method?
And what is "ab image"?
"Great job, team. Head back to base for debriefing and cocktails."
(Spottswoode "Team America")
|
|
|
|
|
I don't understand what exactly you want, but I can give you the general math. Assuming each pixel is represented by the 3 RGB components with values between 0.0 and 1.0:
_________________________________________________________
a) Apply contrast gain GCon with:
new_pix.r=(old_pix.r-0.5)*GCon+0.5
new_pix.g=(old_pix.g-0.5)*GCon+0.5
new_pix.b=(old_pix.b-0.5)*GCon+0.5
This operation corresponds to changing the distance of each component relative to the center (0.5). GCon=1.0 means no contrast change (the distance remains the same), GCon>1.0 means increasing contrast, and GCon<1.0 means decreasing contrast. GCon=0.0 means pure gray (midscale). You should, of course, use saturated arithmetic.
_________________________________________________________
b) Apply brightness gain GBri with:
new_pix.r=old_pix.r*GBri
new_pix.g=old_pix.g*GBri
new_pix.b=old_pix.b*GBri
This operation corresponds to changing the distance of each component relative to black (0.0). This is the most subjective operation, since there are many ways to change the perceived light intensity (which we usually call brightness) to model various physical or electronic effects. GBri=1.0 means no brightness change (all components remain the same), GBri>1.0 means increasing brightness (all components become closer to 1.0), and GBri<1.0 means decreasing brightness (all components closer to black). You should, of course, use saturated arithmetic.
_________________________________________________________
c) Apply color gain GCol with:
new_pix.r=(old_pix.r-old_avg_rgb)*GCol+old_avg_rgb
new_pix.g=(old_pix.g-old_avg_rgb)*GCol+old_avg_rgb
new_pix.b=(old_pix.b-old_avg_rgb)*GCol+old_avg_rgb
The "old_avg_rgb" is the average of the 3 RGB components. This operation corresponds to changing the distance of each component relative to the average of all the 3 components. GCol=1.0 means no color change, GCol>1.0 means increasing color, and GCol<1.0 means decreasing color. GCol=0.0 means black&white. You should, of course, use saturated arithmetic.
The fastest way to implement any of these operations is to do it in hardcore assembly language. However, I sugest a specific layered aproach:
1) First implement in traditional C/C++. If everything fails then the algorithm will still work. This will also serve as a reference to ensure you are doing the operation you want the right way, and also as a benchmark.
2) Implement in traditional I386 assembly language. On a decent processor (like a Pentium 4 at 3.4 GHz) we will probably see small increase in speed relative to 1), somewhere in the range of the 5% or 10% (probably not worth the trouble). On an older processor (like a Pentium Pro or 486) you may see a larger increase, like 50% or 100% (probably worth the trouble). This will depend on your artistic skills when writing assembly. This speed gain, which we are comparing to 1), will also depend heavilly on the C/C++ compiler used. I did my tests against VC6 with full optimizations in 1). Other compilers may achieve not so good optimizations in 1), so 2) may be worth it (since the performance of 2) will be guaranteed by design and thus be compiler-independent). I also assume I386 assembly since it will yield the best results with the smallest amount of effort. I am also pretty sure that the speed of a good I386 assembly implementation will never fall behind the best possible compiler optimization of C/C++. So, I386 will be a guaranteed "greater or equal" to C/C++.
3) Implement in MMX assembly language. This technology is available in many processors (since the Pentium MMX at 166MHz I think), but you should test at run time if the processor running the code supports MMX. There are assembly instructions you can use to determine this. If MMX is not available, then fallback to 2) or 1). This will yield benefits in speed which easily go up to 600% gain compared to 1), even if you program it badly. At this point other aspects of the computer (like memory speed) become important. I'm pretty sure that an average MMX implementation will always be much faster than the best implementations of 2) or 1).
4) Implement in SSE2 assembly language. This technology is available in not so many processors (but I think all Pentium 4 have it). Again, you should test at run time if the processor running the code supports SSE2. There are assembly instructions you can use to determine this. If SSE2 is not available, then fallback to 3), 2), or 1). This will yield benefits in speed which I have measured to be in the range of about 1200% when compared to 1). At this point every little thing in the computer's hardware affects speed. I'm pretty sure that an average SSE2 implementation will always be much faster than an average MMX implementation, and always much much much faster than the best implementations of 2) or 1).
The I386, MMX, and SSE2 assembly languages are simple enough to make it worth using them. Especially SSE2. Programming with SSE2 is a little more anoying than with MMX because you will want to take advantage of the larger register sizes which may put constraints on image size. The best is to do the bulk with MMX or SSE2 and leave the remainder (which is not a multiple of register size) to C/C++ or I386 assembly.
It is very important to note that if you are aiming at the higher speed while maintaning some portability, then your best strategy will be to implement all 2), 3), and 4) in the release version of your program, so that, at run time, the software can always execute as fast as possible for the given hardware. If your software finds SSE2 then uses it, otherwise it tries MMX, and if that also fails it uses I386 assembly. Also you may want to add specific implementations for other processors, like the AMD (does it have any specific instructions?).
I hope this helps,
Rilhas
|
|
|
|
|
how do i connect to SQl SERVER WHIT vc++.NET?
|
|
|
|
|
|
Trivia question time... in any given class, typical OO programming suggests access functions rather than public member variables. I have seen a variety of "styles", and worse, a mix of styles. I'd like to know what your thoughts are on the matter, mindful that it's pretty trivial... 
To send data to a class:
put_Something(value)
PutSomething(value)
set_Something(value)
SetSomething(value)
On the retrieval end:
get_Something()
GetSomething()
What do you like and why?
Charlie Gilley
Will program for food...
Whoever said children were cheaper by the dozen... lied.
My son's PDA is an M249 SAW.
My other son commutes in an M1A2 Abrams
|
|
|
|
|
I use :
Thing GetSomething();
SetSomething( Thing t );
why ? because it's simple.
|
|
|
|
|
I've developed a simple dialog based project and I've added a menu
as new resource. Then I've associated the menu to the dialog through
the property editor of the dialog.
Now, I've mapped ON_UPDATE_COMMAND_UI and ON_COMMAND event in the
dialog class (for any menu item) in order to manage it.
The situation in the following:
- the menu is shown;
- ON_COMMAND events are properly mapped;
- ON_UPDATE_COMMAND_UI events are not managed as I expect.
The method associated with the ON_UPDATE_COMMAND_UI event is called when
I click on the menu item (before calling the ON_COMMAND method) instead
of being called before showing the menu item.
I've tryed to do the same thing in a simple SDI project and in this case
it works fine (but in that case the meenu is load by code in OnCreate method).
Are there some settings to do ?
Have I done something wrong when I've associated the menu resource to the dialog
through the property editor ?
How can I solve this problem ?
Thanks a lot !
|
|
|
|
|
|
Hi,
What is the best book to learn Visual Studio 2005 (specially VC++). I'm really good on C++, but I would like to port my software to a complex VC++ gui interface. So I need some very advanced issues about the visual programming.
Thanks a lot,
Dirso
|
|
|
|
|
Visual C++? Are you intending to buy a book on Managed C++? (Since you've mentioned 2005).. For unmanaged code, I would suggest you to buy Programming Windows by Charles Petzold. That would give you a good start. For MFC, You could start with Programming Windows with MFC, by Jeff Prosise. Good luck.
Let us not listen to those who think we ought to be angry with our enemies, and who believe this to be great and manly. Nothing is so praiseworthy, nothing so clearly shows a great and noble soul, as clemency and readiness to forgive.
- Marcus Tullius Cicero
|
|
|
|
|
How can we design a program that when executes is not shown in the Task Manager.
I mean the program can't be stopped with the help of Task Manager.
Apurv
|
|
|
|
|
You can't. The task manager displays all running processes and gives the user the ability to end a process regardless of what the application wants. The only way you can hide your process from the user is to manipulate the task manager itself and remove your process from it's displayed list.
|
|
|
|
|
ApurvKolte wrote: I mean the program can't be stopped with the help of Task Manager.
Program working as Service can't be stopped with the Task Manager help,
but I don't know how to make an exe invisible in the Task Manager.
|
|
|
|
|
You can hide your application from the task manager by displaying it as some different name rather than the actual name. This can be done by intercepting task manager process enumeration call and returning a different name when your process is enumerated.
Cheers.........
|
|
|
|
|
I dont know why you want to hide your program of TaskManager or similar programs but if you search codeproject you can find (your answer)an article about it.
|
|
|
|
|
where is the article u r talking abt ???
Apurv
|
|
|
|
|
Doing this is a bad idea since it will make you look like a rootkit.
|
|
|
|
|
Hi ,
I know a method to hide a task manager. It is not a perfect one , the idea is this . If take the handle(HWND) of task manager once and hides it using ShowWindow(SH_HIDE) , the next time when user presses Ctrl+esc (or select task manager) it won't show up...
Best Regards
krishnan
If u can Dream... U can do it
|
|
|
|
|
Yes, but the problem is, that he wants to hide a single process, so it wouldn't be shown to user with the task manager. The task manager as such should be visible.
|
|
|
|
|
Not good idea I sometimes use of my program to see processes on the memory with full path of each proccess 
|
|
|
|
|
Why would you want to do such a thing? Are you attempting to write some sort of malware? Unless you can answer these two questions satisfactorily I would suggest (and hope) you will not get much help here.
Steve
|
|
|
|
|
It never ceases to amaze me how often people come into this forum (and others), posing questions like this without any context, yet still receive help.
"how can I hide programs from task manager"
"how can I run a dos box secretly in the background"
"how can I stop user terminating a program"
It's hardly ever a good idea to do any of these things is it? and as you point out, it just looks like someone who can write the odd line of code who is trying to do some malware related tomfoolery.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
