C++ programming

[Eray Ozkural]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Hi Jakob,

You think I am not aware of every single design objective in the
C++ standard library but you are quite wrong.

The example you cite refers to the quasi-functional design of
the STL. It really is nice to have const and all that. I actually
exploited such properties in the past to implement array operations
that go far beyond your trivial use of the standard library.

I do think that you have a very corrupt sense of aesthetics
though. The common use of client code does not matter to me.
If you look at any implementation of STL, in one of the less
trivial parts like valarray you'll see how much it sucks. In fact
it is easy to generate travesty even with proper use of standard
library. I won't bother to give an example, that is best left as an
exercise.

I know all about the performance superiority of C++ wrt
C but you know times change. It's now ocaml versus C++.
What you are talking about is soooo 90's.

Indeed things like blitz++ were exciting a few years ago (Has
it been around for that long?) but not any more.

Thank you,

On Monday 21 October 2002 20:51, Jakob Oestergaard wrote:
> On Sun, Oct 20, 2002 at 02:24:55PM +0300, Eray Ozkural wrote:
> ...
>
> > To prevent a long rebuttal, here is what C++ is excellent for: projects
> > like KDE.
>
> You are missing a very important point.
>
> Forget OO, big fancy projects, code-reuse, and all that (crap) for a
> moment.
>
> ----------
> In C:
>
> int compare_int(const void *a, const void *b) {
>  int *ia = (int*)a; int *ib = (int*)b;
>  return *ia < *ib;
> }
>
> void sort_array(int *array, int members) {
>  qsort(array, members, sizeof(*array), compare_int);
> }
>
> ----------
> In C++
>
> void sort_array(std::vector<int> &array) {
>  std::sort(array.begin(), array.end());
> }
> ----------
>
> Now except for the code size difference (which is negligible once
> compare_int is implemented once for an entire C project) - there is one
> very important difference here, which is important for performance.
>
> The C example must *always* generate one function call to the
> compare_int function whenever two elements of the array are compared. In
> the C++ example, any reasonable compiler will be capable of inlining
> that function, so that in actual machine code, an efficient
> integer-array qsort routine is implemented.
>
> Do you have any idea what a jump costs on any modern pipelined CPU?
> Note, that the operations we compare here, are "one jump and one integer
> compare", versus "one integer compare".
>
> This is a huge performance difference. The inlining of the integer
> comparison operator is possible because of templates.  Not because of
> OO, not because of inheritance, but because of the simple little trick
> called templates.
>
> While this is a simple example, notice that this generalizes to
> everything templatized. (And performing operations on arrays or matrices
> of simple types should not be *that* uncommon in numerical code, unless
> something drastical happened behind my back recently). std::map<> or
> std::set<> will also be able to generate efficient map and set
> *implementations* for exactly the key types that you specify.  Even if
> they are not built-in types - if you create your own "struct key_type
> {...}", the comparison operator ("operator<()") can be inlined if
> suitable.
>
> *This* is where you start seeing performance gains. Real gains over C
> (in C you could do sort-of the same by implementing every generic
> routine in a macro - but this leaves the compiler with no choice in
> inlining, and it will surely put the maintainer in a mental institution
> faster than anyone can say "oh, that's interesting").
>
> This is not just for KDE type projects - this is for every little part
> of your program.
>
> Using templates wisely in computational apps will let the compiler
> generate a program for you, in which *every* single seemingly generic
> algorithm is optimized and "hand-tuned" (well, compiler tuned) for the
> specific use at any given place, and specific data types on which it
> works.
>
> No fat. Lean code.
>
> When misused, this can of course lead to immense bloat in the generated
> output.  Any language can be misused and C++ is by no means an
> exception.  But as ugly as ugly C++ is, beautiful C++ is really, well,
> beautiful   :)

- -- 
Eray Ozkural (exa) <erayo at cs.bilkent.edu.tr>
Comp. Sci. Dept., Bilkent University, Ankara
www: http://www.cs.bilkent.edu.tr/~erayo  Malfunction: http://mp3.com/ariza
GPG public key fingerprint: 360C 852F 88B0 A745 F31B  EA0F 7C07 AE16 874D 539C
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE9wUG3fAeuFodNU5wRAihLAJ9Wz/rRA7GC1t2A40gLpebjokJmoACfXhlv
kMd/6Oqy6KWrTD9n7KGnj38=
=aoTr
-----END PGP SIGNATURE-----