Some compilers like g++ will use calls to memcpy() as code for the default copy constructor and for (part of) the code for the default assignment operator. This is okay, but for speed it's sometimes better to provide explicit definitions that copy more than one byte at a time.
For several of Symbolic's classes, the above overrides copy data eight bytes at a time using loops.
Bo Persson wrote:It teaches the use of the C++ standard library, containers, iterators, overloads, generic functions, and user defined classes, before going into the really difficult stuff like pointers and arrays.
...
There is a lot of C that is of very little use, once you have learned the better ways of C++. So start there!
Just for the pleasure of pumping gas into our little flame war, I show you the words of Linus Torvalds:
C++ is a horrible language. It's made more horrible by the fact that a lot of substandard programmers use it, to the point where it's much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do *nothing* but keep the C++ programmers out, that in itself would be a huge reason to use C.
When I first leaned C over thirty years ago, I was struck by the resemblance of scanf()/printf() functions with the horrible old Fortran read/write/format statements. I thought to myself that there must be a better way, and the C++ formatted character streams are that better way.
sje wrote:Some compilers like g++ will use calls to memcpy() as code for the default copy constructor and for (part of) the code for the default assignment operator. This is okay, but for speed it's sometimes better to provide explicit definitions that copy more than one byte at a time.
Does memcpy() copy one byte at a time?
P.S: Yes EmptyHistory was not defined, ahaaa you caught me
When I first leaned C over thirty years ago, I was struck by the resemblance of scanf()/printf() functions with the horrible old Fortran read/write/format statements. I thought to myself that there must be a better way, and the C++ formatted character streams are that better way.
The March of Progress
1980: C
printf("%10.2f", x);
1988: C++
cout << setw(10) << setprecision(2) << showpoint << x;
1996: Java
java.text.NumberFormat formatter = java.text.NumberFormat.getNumberInstance(); formatter.setMinimumFractionDigits(2); formatter.setMaximumFractionDigits(2); String s = formatter.format(x); for (int i = s.length(); i < 10; i++) System.out.print(' '); System.out.print(s);
2004: Java
System.out.printf("%10.2f", x);
2008: Scala and Groovy
printf("%10.2f", x)
That's somewhat similar to the hilarious The Evolution of a Programmer. But as always, Haskell is more fun. I particularly like the "Ph.D. Haskell Programmer" and the "Post-doc Haskell Programmer".
sje wrote:Some compilers like g++ will use calls to memcpy() as code for the default copy constructor and for (part of) the code for the default assignment operator. This is okay, but for speed it's sometimes better to provide explicit definitions that copy more than one byte at a time.
Does memcpy() copy one byte at a time?
Well, memcpy() can copy one byte at a time; see the man page.
If memcpy can optimize by copying multiple bytes per iteration, then it must figure sizes and maybe alignments at run time. I doubt that this happens. Handling the general case is usually the most expensive approach. Also, it's not guaranteed that memcpy() will be expanded inline, so it has some call overhead as well.
When I first leaned C over thirty years ago, I was struck by the resemblance of scanf()/printf() functions with the horrible old Fortran read/write/format statements. I thought to myself that there must be a better way, and the C++ formatted character streams are that better way.
Overall, C++ looks even more reasonable when symbolic expressions are needed for field parameter specifiers; it's a pain to do the same in C.
In the old days I used to teach introductory computer science (a.k.a "How To Get Fortran To Do Something Useful"). It seems that my fellow instructors and I had to spend at least a week and a half of each course imparting the arcane knowledge of READ, WRITE, and FORMAT. What a waste that was.
sje wrote:Some compilers like g++ will use calls to memcpy() as code for the default copy constructor and for (part of) the code for the default assignment operator. This is okay, but for speed it's sometimes better to provide explicit definitions that copy more than one byte at a time.
Does memcpy() copy one byte at a time?
Well, memcpy() can copy one byte at a time; see the man page.
If memcpy can optimize by copying multiple bytes per iteration, then it must figure sizes and maybe alignments at run time. I doubt that this happens. Handling the general case is usually the most expensive approach. Also, it's not guaranteed that memcpy() will be expanded inline, so it has some call overhead as well.
It depends on your compiler!
MSVC, for example, will figure out aligning at runtime and get up to speed after the first 1-3 bytes. If it can figure out size and alignment at compile time, like when initializing some fixed data , it will inline optimized code.
When I first leaned C over thirty years ago, I was struck by the resemblance of scanf()/printf() functions with the horrible old Fortran read/write/format statements. I thought to myself that there must be a better way, and the C++ formatted character streams are that better way.