[Dev-C++] Discussion about C/C++ details

At first the results of your code to my pc (piii 1000 MHz, 512 MB RAM):
=20
Time spent for memset(): 200
Time spent for the for loop: 350
=20
strcat() needed: 290
Our manual strcat character by character thing needed: 340
=20
The size of our string was: 63999992
strlen() needed to measure the string length: 481
The time we needed to measure the length of the string: 340
=20
=20
I hadn't thought that the compiler excludes the call and assignment of
i=3Dstrlen() because it notices we do not use i (clever indeed).  But =
the
rest shows clearly that memset() is not using character by character
assignment to assign values and strcat is not looking character after
character too (perhaps they use an int pointer and make tricks,
something i just thought but not character after character).=20
=20
=20
It seems that we will never end arguing on details. I disagree with your
comment:
=20
/* When using increment or decrement operators you should use the pre
form
    rather than the post form as it is more efficient. Only post
increment or
    decrement when you need the value before the change.
    Also pointer arithmetic is faster than array indexing. */
=20
=20
This is truth *only* if we use overloaded post increment and decrement
operators for our objects and not for built in types. This thing reminds
me something i read on the web from a Schildt book, i will not tell you
about Schildt, check www.accu.org at the book reviews and read the
reviews of his books.=20
Also pointer arithmetic and array indexing is exactly the same and
compiler translates them the same. So this is definately wrong too. :)
=20
=20
I changed the color so as to find quickly my disagreements. :)
=20
=20
=20
Ioannis
=20
* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
<http://www.noicys.f2s.com/>=20
* Alternative URL: http://run.to/noicys
=20

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Jason
Hardman
Sent: Friday, October 26, 2001 3:31 AM
To: Dev-C++
Subject: Re: [Dev-C++] Errorhandling


I'm sure you want this over and done with, but I decided to look at your
code and I have optimised some of it, and corrected an error that cause
a miss read of the time taken for strlen(). I hadn't realised this, but
when you are assigning a variable a value you don't use the compiler
happily ignores the value and doesn't bother with the assignment. What
that meant was it didn't actualy execute the strlen function in your
version, hence no time taken. I hadn't known this before, but it's quite
clever.
=20
I also did some other optimisations, I note that strcat() is still
slightly faster than our own version, but not by a massive margin. I'm
not absolutley sure that the tests are equal, but they seem to be
representative. I find it funny that my "memset" is faster than the real
one, so maybe there's an error or unaccounted optimisation somewhere?
=20
Note that I did the test using full compiler optimisations, as that
would be representative of a real world test. Also note that I decreased
SIZE, because I have only 128MB on my machine and using a 100 million
bytes forces windows to use virtual memory, which will cause large
slowdown, and prevent accurate figures.
=20
I was tempted to rewrite it all into a style I would normally use, but
couldn't be bothered. :-D
=20
Regards, Jason.

----- Original Message -----=20
From: Ioannis Vranos <mailto:no...@ya...> =20
To: Dev-C++ <mailto:dev...@li...> =20
Sent: Friday, October 26, 2001 1:02 AM
Subject: RE: [Dev-C++] Errorhandling

Ok, we all agree that it is working like that but i am probably right on
this (as you were right for some other details in things i had not
noticed before).
=20
But my last effort to persuade you is attached in this email as file
temp.c . It is ANSI C code and it shows the differences between the
performance of standard library functions and character by character
things. Please take a look and execute the code.
=20
=20
The results to my machine:
=20
C:\c>temp
Time spent for memset(): 300
Time spent for the for loop: 471
=20
strcat() needed: 461
Our manual strcat character by character thing needed: 571
=20
strlen() needed to measure the string length: 0
The time we needed to measure the length of the string: 560
=20
=20
Notice especially the last.
=20
=20
Friendly,
Ioannis
=20

* Ioannis Vranos
* Programming pages: http://www.noicys.f2s.com
<http://www.noicys.f2s.com/>=20
* Alternative URL: http://run.to/noicys
=20
=20

-----Original Message-----
From: dev...@li...
[mailto:dev...@li...] On Behalf Of Jason
Hardman
Sent: Friday, October 26, 2001 12:05 AM
To: Dev-C++
Subject: Re: [Dev-C++] Errorhandling


You cannot always know the length of an array or string at compile time.
It is possible for things like array size and such to be determined at
compile-time and at run-time (depending), but by doing it at run-time
you are incurring an overhead in your code, which isn't part of the C
style of programming. Adding these mechanisms to C code with hidden
compiler features would be breaking the general C/C++ ethic, at least in
my view.
=20
The only reason I'm 'discussing' this is because the more I think about
it the more I come to believe that it's more likely that standard
functions like strcat() and strlen() will determine the length of the
string by going all the way through the string until null. I know this
is an old argument, but I find it difficult to believe that it would be
done a different way. C doesn't actualy have native support for strings,
it just uses an array of chars, and allows the definition of string
literals.
=20
In Pascal, for example, it does have native support for strings and you
will find that it will store a pointer to an array and the first element
of the array will be the length of the string that follows.
=20
If you want we can end this particular argument and settle on the fact
that we are both willing to differ in opinion, and that it doesn't
matter which is true 'cos it still works no matter what.
=20
Jason.