I don't know the first thing about Assembly, so wouldn't call myself an expert, but is it this one?
GetCurrentAddress:
mov eax, [esp]
ret
Yes, even though it is twice as many instructions and a function call, it's faster. The other one digs into internal CPU structures and mucks up the instruction prefetch cache so that every single return on the call stack has to discard it's branch predictor.
On another note, occasionally, there will be a conversation where somebody is saying how much more superior C++ is to any other language; they will state things like "it's faster" (it's not), or "It's easier to code (*censored* no)". The counter-argument runs to the accord of "C++ complicates things" which they will inevitably say it doesn't.
To which the only question to ask would be "just what is a protected abstract virtual base pure virtual private destructor, and when was the last time you needed one?" The fact is, they won't know the answer. Truly, most of the people I know who might call themselves "C++ wizards" are really programming in some sort of unholy blending of C code (rife with security exploits like using gets() and executing System() calls) and C++ ("I put uses namespace std at the top so it's C++!).
This isn't to say that C++ is inferior, but the fact is that just because everybody uses it doesn't suddenly make it good. It low-level, and t's being used for tasks in which a low-level language isn't required. And those tasks that it is suited for discard it in favour of C because C++ is far "too heavy." That is, for a low level language, it hides a lot of what it does during compilation. The Speed argument is utterly idiotic because you can write slow code in any language and you can write fast code in any language. What's important is that even a skilled C++ programmer cannot necessary write code faster than a programmer in another language. Many people attribute this to "well that's because those other languages have IDE's and Designers and intellisense, It's not programming! It's like using powerpoint" this was mentioned towards VB4, I believe, in comparison to C++. Well, see, the thing is, when it comes to deliverables, people prefer to pay for something that exists. Deciding between a developer who should have the C++ implementation done "real soon" and a VB developer who already has a working implementation is a no brainer. The company doesn't care that a lot of self-righteous snobs think Visual Basic is "unclean" or "stupid" the fact that the software exists in that case and doesn't in the other is what decides their choice.
Myself? I an write windows applications in C using the standard API. You know all that fun stuff like WNDCLASSEX and RegisterClassEx and CreateWindowEx() and of course message pumps. I don't do that because I want to concentrate on what the application is going to do, not which HMENU I should attach a popup I made with CreatePopupMenu(), and trying to remember the difference between CreatePopupMenu() and CreateMenu(). The primary attribute of a good programmer is Sloth, and all the "toy" languages as self-proclaimed programming purists call them add things like libraries and frameworks that help programmers get things done, not spend another week re-architecting their Shell_NotifyIcon() wrapper class. That's why most development in C++ leverages some other library (like BOOST,, ATL, etcetera). or the programmer has to follow a set of guidelines (such as RAII (Resource Allocation Is Initialization)) or something like COM Smart Pointers. these are, strictly speaking, things that should be implemented Once, by the language compiler, and only once. Instead, what we end up with is so many libraries, structures, rules, and guidelines that we lose sight of the forest through the trees. C++ at this point is more about learning your chosen framework, designed to hide the low-level details of your Operating System that you would normally call. And at that point, why are you using C++?
C++ should, IMO, be mostly for development of things that actually require something at a low-level; things like Device Drivers. But then you'll be more likely to use C for those purposes anyway, since C++ is too heavy and brings with it too much mental baggage.
When I am programming I don't want to have to remember the difference between a static volatile non-const variable and a non-volatile register const variable. half of the stuff being determined by language constructs can easily be optimized away by a proper compiler, and many times are, making a lot of C/C++ keywords do absolutely nothing.
This particular post was spurned by somebody telling me that "C# is a toy language, you should learn C++ that way MS doesn't dictate your language". Let's consider the idiocy of the statement. First, they state that C# is a toy language. Based on that particular persons history and postings, I was aware that they were 16 and still in school. Meanwhile, I have recently started actually making money off my development. if C# is a toy language, it's a *censored* profitable one. Second they know nothing about the language or framework and conveniently ignore the fact that C# as a language is just as much an ECMA standard as Javascript or ANSI SQL, and that there already are other implementations. Or the fact that Microsoft seems to be the only language vendor that actually knows what the *censored* they are doing. This also conveniently ignores the fact that I already know quite a bit about C++. Low level stuff can be interesting, and fun, but when it comes down to business, I want to concentrate on that business, not on esoteric errata. The number of instructions you can shave off your functions hasn't been anything more than an exercise in trivial hubris for years, and has no place in a professional environment. Clean, easy to read code is always superior to esoteric code that uses undocumented functions or processor errata to speed up performance of a seldom called function by a tenth of a percent, particularly since the former also assigns importance to portability and maintenance.
"Write something once. Write it well, move on, and then use it when you need it". I follow this to a tee. I once needed a easy ability to sort a ListView when columns were clicked, show and change the header so that it showed the sort order, and allow callbacks to implement a custom sort on the listview items. I could have baked that code right into the application and tied it directly to that specific listview, but instead I wrote a self-contained class that I can instantiate passing the listview and it deals with the rest. Same with dealing with INI files. Same with countless other tasks. The net result is that I am happier and I get my work done faster. I may love programming but I still have other interests and I would rather be deciding what to spend a thousand dollars on than deciding which of my routine implementations is less likely to trash the stack.
