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

And for our system they occupy the same space too, because
sizeof(size_t)=3D=3Dsizeof(char *)=3D=3Dsizeof(int)=3D=3D4
=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

-----Original Message-----
From: Ioannis Vranos [mailto:no...@ya...]=20
Sent: Friday, October 26, 2001 2:12 PM
To: Dev-C++ (dev...@li...)
Subject: RE: [Dev-C++] Discussion about C/C++ details


A slight addition to clear things up: Also pointer arithmetic and array
indexing is exactly the same in terms of speed (the first occupies more
space) for built in types *only*. For overloaded operators in classes it
depends how we define them.
=20
So in general you seem to confuse the performance of overloaded
operators for custom classes and the performance of default operators
for built in types.
=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

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  <mailto:no...@ya...> Vranos=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.