Quote:
Original post by jpetrie
Quote:
And its not an issue of accidentally formatting the harddrive, its an issue of invisibly putting a slow copy constructor to a temporary variable somewhere in a performance critical code. Yes, you could find it easily being an experienced C++ programmer, but wouldn't it be easier to find if it was a function call with visible memcpy?
That's the context of the question; while you may have mutated your argument since, the point still stands that your original statement here was (to quote SiCrane), bullshit. And you're still not seeing it -- you're assuming the first example (C++) lacks context about a and b. You're assuming the second example has context about x, y and z.
But my example has no context for either statement, intentionally. The point is that you must examine the code for the context anyway. Just because the first example is an operator= and the second a memcpy doesn't make any damn difference. Scroll up to the top of the function to find some context, then you'll discover:
int a = 0;int b = 0;char *x = /* ... */char *y;int z = 9000;
Whoops. The memcpy was the hidden expensive copy call.
Again no idea what you are trying to say, my text you quoted talks about temporary variable and copy constructor where the focus is that they are invisible.
memcpy is much more visible. The entire point of code clarity is it is harder to miss mistakes, it is easier to search for context.
And yes, it is easier to spot memcpy than it is to spot temporary variable. It is easier to search the size of the memcpy and harder to search for overloaded functions.
Not that one is slower or faster, that would take more specific context, just that one is more visible and for that no context is needed to notice it. Read my original text (which you quoted) I talked about easier to find, not about slow/fast. Again, it is harder to find a temporary variable than a visible variable. It is usually harder to notice a copy constructor than a memcpy.
p.s. I know very well about virtual memory and cache and such if thats what you refer by pointing to the other thread (barely read it yet), I don't think C code is equivalent to the CPU work, but usually you don't have to debug virtual memory so I have no problem with it being completely hidden, and its hardly comparable to hard to follow invisible logic of a program.
I am going to sleep. I should have taken my own advice and quit a long time ago. good night.