RE: [Dev-C++] Errorhandling

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

> -----Original Message-----
> From: Juliet [mailto:no...@li...]=20
> Sent: Wednesday, October 24, 2001 9:15 PM
> To: Ioannis Vranos
> Subject: RE: [Dev-C++] Errorhandling
>=20
>=20
> At 11.47 23/10/2001 +0200, you wrote:
> >Uf. I do not want to open issues here, but there are many searching
> >algorithms (which i do not know). One efficient the C=20
> library provides is=20
> >bsearch().
>=20
> That would be overkill in this case :) Think about it, what=20
> does strcat do?=20
> it finds the end of the first string, then starts copying the=20
> second string=20
> into it, until that string ends too. You'd be right if the=20
> EOS wasn't a=20
> single character but rather some character sequence, hopefully the C=20
> designers weren't that stupid :)

I am not talking about strcat(). I am talking in general stating that
"string\0" only bad things can cause (except we need that particular
form and we know what we are doing). Because the person who writes
"string\0" doesn't seem to know that "string" has a '\0' automatically.
Anyway the implementation of strcat() would be enough stupid if it
searched character after character (even if it was written in C itself).
Many compiler operations are written in very much low level and system
dependent way so we can't know how exactly strcat() is written (with the
exception we have the source code). For example see 8.7 in K&R. Also see
header files of Dev-C++ to see Windows dependent declarations even
there. The only thing we know is that strcat() must replace the first
'\0' it finds so thinking of it looking character after character
doesn't cause any harm.

>=20
> >It can be written in assembly, pascal (as in C++ Builder)=20
> with a C type
> >interface, e.t.c..
>=20
> Generally a language's runtime is written in the same language, for=20
> essentially one reason: developers willing to learn from it=20
> and improve it=20
> won't need extra tools, compilers or knowledge of foreign=20
> languages. In=20
> particular, using ASM is the worst thing you could do

It is not necessary to have the source code of the implementation of the
library. It may come in precompiled form and only the header files with
the declarations to be supplied. It is also possible to not even have
any source files at all, and #include statements to work as switches as
i mentioned some day (but the #include mechanism *must* behave as if
there are source files and are included, the same it does with our
header files). So it is safe to always think that #include includes
header files even if this is not the case.


>=20
> You *need* ASM only to use features of the particular architecture=20
> (interrupts/traps, instructions implementing whole functions,=20
> native large=20
> integers, native floats, etc.), not covered by normal=20
> languages (exactly=20
> because of their specificity). The speed/optimization thing=20
> should be left=20
> to the compilers, and they do a pretty nice job. Couple them with=20
> binary-to-binary profiling compilers (these are something=20
> really cool!),=20
> and you will obtain something impossible to do by hand


I agree.

=20
> For example: the part I hated most of the Delphi runtime (not=20
> the VCL,=20
> however. That's pure Object Pascal) was that it's about 50%=20
> ASM, not even=20
> inline assembly (heck, I wouldn't understand it, but at least I could=20
> *compile* it), I'm talking about macro-ASM files that need=20
> their commercial=20
> (100$ and being sold only in the US) assembler, Tasm32, to be built


Yes.


Also i hate pascal. :)


Ioannis

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