Re: [Dev-C++] Errorhandling

[Jason H. <jas...@bt...>]

While I don't want to kick up a fuss in this discussion I would like to
point out firstly that search techniques in general rely on the structure to
be searched being sorted into some specific order. It would be unreasonable
to sort a string just so you can find the instance of a null, and it would
invalidate the result anyway. ;) There isn't much more you can do in
searching a string except by going in sequence through it. I know it has
been mentioned that maybe a compiler has optimisations to work around
searching the entire length of a string to find it's end, but it's not
something you can rely on. Adding these features would introduce a great
deal of complexity into the compiler, but that is up to whoever writes it. I
think you will find that the majority of compilers will actualy deal with
string operations in the way you would expect from an external viewpoint.
You will note that that standard C/C++ does not rely on knowing the lengths
of arrays and will overrun their ends if you are not careful. I would think
that if the compiler had extra info about a string like it's length then it
would use it in cases like this. In the end it's not something I have to
worry about.

Secondly, the use of the '\0' character is fairly limited, but there are
some cases where it may be used. I agree that using it to manualy null
terminate a string literal is bad practice and should be avoided.

Possibilities for use of '\0' are:

Manualy null terminating a string, i.e.

char str[27];
for(char i = 0; i < 26; ++i) str[i] = 'A' + i;
str[26] = '\0';
cout << str;

Of course you could just as easily use a zero, but '\0' is in context to the
operation this way.

or

unsigned char str[] = {'\200', '\250', '\210', '\300', '\0'};

I've not looked up what those numbers do, but generally there are additional
characters after 127 decimal (177 octal) that are special, i.e. graphics
characters. I remind you that a backslash followed by a number is an octal
number and not a decimal.

Also I could envisage using it within a string literal as a way of breaking
it up i.e. "Hello.\0This is a test.\0Break!", of course I wouldn't recomend
using a structure like this generally, but it's not impossible to envision a
need for it. You would have to parse it manualy to obtain the strings or
other data from it.

Just some thoughts, Jason.

----- Original Message -----
From: "Ioannis Vranos" <no...@ya...>
To: "Dev-C++" <dev...@li...>
Sent: Wednesday, October 24, 2001 10:48 PM
Subject: RE: [Dev-C++] Errorhandling


> -----Original Message-----
> From: Juliet [mailto:no...@li...]
> Sent: Wednesday, October 24, 2001 9:15 PM
> To: Ioannis Vranos
> Subject: RE: [Dev-C++] Errorhandling
>
>
> 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
> library provides is
> >bsearch().
>
> That would be overkill in this case :) Think about it, what
> does strcat do?
> it finds the end of the first string, then starts copying the
> second string
> into it, until that string ends too. You'd be right if the
> EOS wasn't a
> single character but rather some character sequence, hopefully the C
> 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.

>
> >It can be written in assembly, pascal (as in C++ Builder)
> with a C type
> >interface, e.t.c..
>
> Generally a language's runtime is written in the same language, for
> essentially one reason: developers willing to learn from it
> and improve it
> won't need extra tools, compilers or knowledge of foreign
> languages. In
> 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.


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


I agree.


> For example: the part I hated most of the Delphi runtime (not
> the VCL,
> however. That's pure Object Pascal) was that it's about 50%
> ASM, not even
> inline assembly (heck, I wouldn't understand it, but at least I could
> *compile* it), I'm talking about macro-ASM files that need
> their commercial
> (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



_______________________________________________
Dev-cpp-users mailing list
Dev...@li...
https://lists.sourceforge.net/lists/listinfo/dev-cpp-users