RE: [Dev-C++] Errorhandling

[Ioannis V. <no...@ya...>]

Isn't it possible for an internal "sizeof style" mechanism that
determines the size of the data and insert it as a constant value in any
function, at a specific system?
=20
=20
For the rest check the following C++ code:
=20
#include <cstdio>
=20
int main()
{
 using namespace std;
=20
 printf("%d %u\n\n", '\200', '\200');
 printf("%d %u\n", 0200, 0200);
}
=20
=20
Btw for what about are we arguing for? (If we are arguing) :)
=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: Thursday, October 25, 2001 4:13 PM
To: Dev-C++
Subject: Re: [Dev-C++] Errorhandling


> As a hint take for example
> sizeof. sizeof even for ANSI standard knows the length of an array in
> the scope it was defined. How does it know? It's compiler stuff and
> compiler knows. So strcat() to search character after character would
be
> stupid for a nowadays compiler. But it is *safe* to assume it looks
> character after character to find the '\0'.
=20
It's important to realise that sizeof is a special compile time
operator. When the compiler finds it it determines the size of the data
refered to and inserts it as a constant value. The sizeof operator won't
work at runtime. For it to work at runtime the compiler would have to
include a lot of extra code and information about a data type created to
help detemine sizes, and that wouldn't follow the standard AFAICT. To do
that would turn C/C++ into a higher level "safe" language that is also a
lot slower. So what does strcat() or strlen() do when you pass it a
dynamically allocated array that the compiler didn't know about at
compile-time? It won't use the sizeof. =20
=20

> unsigned char str[] =3D {'\200', '\250', '\210', '\300', '\0'};
>=20
> I've not looked up what those numbers do, but generally there=20
> are additional characters after 127 decimal (177 octal) that=20
> are special, i.e. graphics characters. I remind you that a=20
> backslash followed by a number is an octal number and not a decimal.

> A number having a \ is an escape sequence, *not* an octal number. 0200
> is an octal number (without ' ').
=20
I was refering to the fact that the number following the backslash is
interpreted as an octal constant and not as a decimal; it doesn't need
the preceding zero. Also if you write '\xff', that is a hexadecimal
character constant.
=20
Regards, Jason.