|
Online PC gaming is known for being full of dirty cheaters. Cheats can be implemented through many methods from simple to impressively complex. Macros, hex editing, memory inspection, memory modification, DLL injection, network manipulation, packet modification, and lord knows how many more. Direct X interception is a particularly naughty breed of hacking. By sharing knowledge of its inner workings hopefully that damage can be mitigated.
|
|
|
|
|
The point isn't to claim that C++ is the "one true language", but rather that any benefit a programming language has for the programmer doesn't matter. If writing code in language X makes you 100x more productive but produces slow code, then all your users will notice is that your programs are slow. The proof is in the coding.
|
|
|
|
|
What your customers will notice most is determined by their priorities. Time-to-market and technical accuracy can both trump absolute speed. Authentication delays and complex queries wouldn't run any faster if the code were reduced to one machine instruction.
|
|
|
|
|
Kerux-David Lee Neal wrote: What your customers will notice most is determined by their priorities. Time-to-market and technical accuracy can both trump absolute speed.
This is quite true . . . until after the delivery. Then the complaint is about speed.
Actually, they original items you have are, in their fashion, also about speed, albeit delivery.
Whatever phase they're currently involved with, be it awaiting delivery or consuming the deliverable, customers/users want a manifestation of speed.
I think the best way to interpret the quote is over the long haul. Assuming there actually is a longer development time with C++ (not necessarily so), is it so much longer as to outweigh the benefits? Also, if as you gave as an example, one is SQL-ish Server bound for throughput, then it hardly matters.
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "As far as we know, our computer has never had an undetected error." - Weisert | | "If you are searching for perfection in others, then you seek disappointment. If you are seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Right. Is enough to look at once-C++-now-not-C++-Hotmail to count how many clicks you have to push onto the new mail message. Now that's a progress in the time to market. All I see is that I can't read my email so I moved to other (C++) clients. Such as Outlook.
Nuclear launch detected
|
|
|
|
|
If your software is fast but buggy all they'll notice is the bugs.
If your software is fast but new features (and change requests) are slow to arrive all they'll notice is the lack of features.
If your language of choice delivers good speed, mitigation of bugs, and fast development time then that's what they'll notice.
|
|
|
|
|
The other posters have nailed it - a clear case of deciding on a methodology before doing the analysis.
Peter Wasser
Art is making something out of nothing and selling it.
Frank Zappa
|
|
|
|
|
Can't say I disagree. The whole purpose of computers is computing speed.
|
|
|
|
|
If you develop a system that automates a task and the user can now do a hundred of the tasks in a day wheras before it took a week, they will think the system is fast. When new recruits start and se the system have a lot of waiting time, they will say it is slow. After optimising it to now do 150 a day, they will think it is fast. That is until some new recruits start...
In the end its all relative! It doesn't matter which development language you choose.
|
|
|
|
|
Jan Steyn wrote: It doesn't matter which development language you choose.
Except when it does (and for the record, I am currently using C# and JavaScript at work) When will better JITs save managed code?[^]
|
|
|
|
|
Nemanja Trifunovic wrote: The whole purpose of computers
And being less error-prone (once debugged anyway).
And relieving humans of tedious tasks.
At least this was the case with the very earliest computing machines.
|
|
|
|
|
And doing it to the business demands, while the business still values it (i.e. development cycle time is critical for many situations).
|
|
|
|
|
Nemanja Trifunovic wrote: The whole purpose of computers is computing speed.
Errm, no. Reliable reproduction of calculations must play a large part. If you believe that processing speed is the all important guideline, then we should all be coding in Fortran or Assembly Language.
|
|
|
|
|
Finally. Someone std::gets<it>.
Nuclear launch detected
|
|
|
|
|
Attempting to load signature...
A NullSignatureException was unhandled.
Message: "No signature exists"
|
|
|
|
|
Just sayin'.
m.bergman
For Bruce Schneier, quanta only have one state : afraid.
To succeed in the world it is not enough to be stupid, you must also be well-mannered. -- Voltaire
Honesty is the best policy, but insanity is a better defense. -- Steve Landesberg
I am not a chatbot.
|
|
|
|
|
Which Assembly? Will the Macro 11 for my VAX and Alpha port to my x86?
|
|
|
|
|
PIEBALDconsult wrote: Will the Macro 11 for my VAX and Alpha port to my x86?
It doesn't matter. Portability was not a factor in the article. If you are looking for performance, then you write in assembly. If you don't care, you might as well write it in VB.
m.bergman
For Bruce Schneier, quanta only have one state : afraid.
To succeed in the world it is not enough to be stupid, you must also be well-mannered. -- Voltaire
Honesty is the best policy, but insanity is a better defense. -- Steve Landesberg
I am not a chatbot.
|
|
|
|
|
Of course we could take this further and say that assembly beats C++. Of course C is somewhere in between. You might even want to twiddle bits and just bypass the assembly language.
|
|
|
|
|
The author's "proof" contains the following statement:
Step 2: C and C++ are the fastest known programming languages*. (* ignoring Fortran.)
Of course! Ignore any evidence not in your favor!
Nuclear explosion simulations were written in Fortran and remain in Fortran.
I submit that software matters more than software for some crap like tracking rentals at a video store.
|
|
|
|
|
Just like at every other software development shop, we have struggled with the definition of "Done". Throughout the years we've had many definitions of "Done" with teams and individuals. Today each team has its own definitions of "Done" all through the lifecycle but the common denominator is that it culminates in "Done" from the perspective of our customers. It's not "Done" until the customer says it's "Done."
|
|
|
|
|
Theoretically, if you have a specification, when the code meets the spec. However, that does not seem to work very well either.
|
|
|
|
|
If you're not prepared, the old SQL Injection trick is a time-honored method of ruining your day (or week, or career). It's not magic, however, and both exploits and mitigations are well known. Use this cheat sheet to understand the problem and make sure your database code is secure. If you don't know the tricks, you're probably the target.
|
|
|
|
|
Put this as a permanent link on the Q&A forums.
Failure is not an option; it's the default selection.
|
|
|
|
|
Good read.
But why allow application users to run sp_oacreate for example? I believe that a lot of SQL injection attacks can already be stopped by having the appropriate permissions set to db objects
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
