Re: Increasing efficiency in C
From: Dan Pop (Dan.Pop_at_cern.ch)
Date: 03/04/04
- Next message: anony*mouse: "Re: string-search-and-replace function wanted"
- Previous message: Kevin Bracey: "Re: Optimizing a switch statement"
- In reply to: jacob navia: "Re: Increasing efficiency in C"
- Next in thread: jacob navia: "Re: Increasing efficiency in C"
- Reply: jacob navia: "Re: Increasing efficiency in C"
- Reply: Malcolm: "Re: Increasing efficiency in C"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: 4 Mar 2004 15:02:36 GMT
In <c27e5q$c72$1@news-reader1.wanadoo.fr> "jacob navia" <jacob@jacob.remcomp.fr> writes:
>"Dan Pop" <Dan.Pop@cern.ch> a écrit dans le message de
>news:c27a00$7hh$4@sunnews.cern.ch...
>> In <c25kuu$rae$1@news-reader4.wanadoo.fr> "jacob navia"
><jacob@jacob.remcomp.fr> writes:
>>
>> >As everybody knows, C uses a zero delimited unbounded
>> >pointer for its representation of strings.
>>
>> If I didn't already know what a C string is, I wouldn't have been able
>> to make any sense out of this sentence.
>
>Zero delimited means a zero is written in the last byte to signal the end of
>the string Dan
Nope, it means a zero before the string and another zero after. Delimited
is not a synonym for terminated.
>I wanted to emphasize "unbounded" because there is no way to know if
>the zero is not there where the pointer will end pointing to...
You don't know where the pointer will end pointing to. Your wording
simply didn't make any sense to anyone but you.
The representation of a string in C is the sequence of characters, up to
and including the null terminator. No kind of pointer is involved in the
representation of a C string.
>> >This is extremely inefficient because at each query of the
>> >length of the string, the computer starts an unbounded
>> >memory scan searching for a zero that ends the string.
>>
>> It doesn't hurt to use your common sense in validating your opinions.
>> If C strings were "extremely inefficient", that would have been a much
>> bigger problem 30 years ago, when computers were orders of magnitude
>> slower than today. Yet, no one produced a fix then. No alternate
>> string libraries designed and implemented for C since then have
>> acquired any kind of popularity. ^^^^
> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>There are many Dan. Just search in Google and you will find zig libraries
>that implement this with different emphasis in different objectives.
Are you reading impaired or what? Which of them qualifies as popular?
>The objective of this discussion is to see why the *language* doesn't
>support any other schema for implementing strings.
No other scheme proved to by better in a GENERAL PURPOSE context.
As you admit yourself, the alternate libraries are designed for well
defined goals, rather than as universal replacements for the C strings.
And the very existence of these libraries proves that the C language DOES
support alternate schemes. So, your point is moot.
>> Since C programmers aren't the last people to care about efficiency,
>> what conclusion can you draw?
>
>Since language support doesn't encourage the use of bounded pointers
>C string handling is much more error prone than it should be.
1. This is not a performance issue.
2. This is a *general* problem of C: most C features are error prone in
the hands of the incompetent.
>Never had the traps because of the missing zero?
Nope.
>The failure modes of the string functions in the library like strcpy
>are just horrible. Memory corruption is guaranteed unless a zero
>is found...
Dynamic memory allocation has exactly the same problems: write beyond
a dynamically allocated memory bolck (in either direction) and memory
corruption will (most likely) bite you, sooner or later. What is your
better replacement for malloc and friends?
C is a sharp tool *by design*. People who can't use sharp tools or are
afraid of them, should not use C. There are plenty of other programming
languages designed for them so there is no need to turn C into a less
sharp tool (and, therefore less effective in the hands of the competent
programmers) and annoy C's *intended* user base.
There are many ways in which C needs to be extended, but adding more
string formats is not one of them. You're wasting your time trying to
fix something that isn't broken.
Dan
-- Dan Pop DESY Zeuthen, RZ group Email: Dan.Pop@ifh.de
- Next message: anony*mouse: "Re: string-search-and-replace function wanted"
- Previous message: Kevin Bracey: "Re: Optimizing a switch statement"
- In reply to: jacob navia: "Re: Increasing efficiency in C"
- Next in thread: jacob navia: "Re: Increasing efficiency in C"
- Reply: jacob navia: "Re: Increasing efficiency in C"
- Reply: Malcolm: "Re: Increasing efficiency in C"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
