Increasing efficiency in C

[Nils Petter Vaskinn]

Yes. Indeed. And it was a good thing, since bound checked strings
are NECESSARY, specially in the development phase of the program.

Exactly, make a library or a modified compiler that has bounds checked
strings you can use for testing (in addition to compiler warnings, lint,
debuggers, valgrind, electric fence, assert and other tools) but don't
make it part of the language.

There is a difference between a performance hit during testing to find
errors and a performance hit forever to make errors impossible.

 

[heyo]

[...]
I think it makes perfect sense, if you're going to make the move from C to
C++, to start by learning one feature (or just a few features) at a time.
What's wrong with the first one to focus on being, say, std::string ?
-leor

The fact that you get C-hackers using C++ - not C++ programmers.
The only way to swich from iterative programming to OO-programming is
to forget all you know about programming and start learning to think
object oriented. Then start learning a programming language.

C++ is not "a better C" it's something completly different and has
more in common with delphi, java or eifel than with C. It's not the
syntax that makes a difference it's the kind of thinking.

bye,
heyo

 

[jacob navia]

Leor Zolman <[email protected]> wrote in message

[...]
I think it makes perfect sense, if you're going to make the move from C to
C++, to start by learning one feature (or just a few features) at a time.
What's wrong with the first one to focus on being, say, std::string ?
-leor

The fact that you get C-hackers using C++ - not C++ programmers.

Sorry but this attitude sucks.

"C-hackers" and "C++ programmers".

You can only "hack" in C. You can "programm" in C++.

This arrogant style of thinking is typicall of C++ hackers, unable
to understand that people have the right to avoid their complexity
by ignoring it.

The only way to swich from iterative programming to OO-programming is
to forget all you know about programming and start learning to think
object oriented. Then start learning a programming language.

How true. You have to forget common sense, and getting into the
"way of thinking" of this language. No thanks.

By the way C is not about "iterative" programming (this must be
a new concept since I have never heard of it in the literature)
but about "structured programming"!!!

I propose retaining common sense, avoiding complexities and
developing software that is maintainable.

C++ is not "a better C" it's something completly different and has
more in common with delphi, java or eifel than with C. It's not the
syntax that makes a difference it's the kind of thinking.

Yes. A kind of thinking that can be put in one sentence.

"If it is simple, efficient, and it works forget it. Everything
must be repainted under several layers of complexity to be
really useful."

Yes, forget everything you know, oh true believers. Follow me
and you will be saved from simplicity. After you think like me
nobody will be able to understand your programs

 

[Grumble]

At any given point in a design, a C programmer can choose whether
or not to do that stuff. She may choose not to, for reasons that

^^^

make all the sense in world for that application. She may not want

^^^

that overhead forced upon her.

^^^

Bleh! So PC. So lame.

 

[Dik T. Winter]

> Hmm. I would have expected my explanation to be a little opaque
> to a Russian native, perhaps, but I honestly expected the French
> telephone to follow the American mold [see diagram]. Do your telephones
> have any letters on the keys? Which ones?

Except that the Q is added to the 7 and the Z to the 9, the layout is the
same for modern telephones. However most older French telephones do not
have letters on them (as in almost all European countries, in my home,
for instance, there is no telephone with letters on it). You have to
go very long back for telephones with letters on them, and in that case
the layout could vary per country (in the Netherlands: 1 = A, 2 = B,
3 = C, etc.).

 

[Dan Pop]

Wow Dan, this is news for me. No kind of pointer?

Not even a char * as it seems?

Not even.

Strange. Are all those prototypes in string.h wrong?

Nope, they are correct. But they are not passed the representations of
strings, they are passed the addresses of strings. This is where pointers
get into the picture.

I would fill a defect report.

Just do not exaggerate Dan. Let's keep cool ok?

When did I get hot?

I am speaking about a naked char * that points to the
start of a sequence o bytes that should end with a
terminating zero.

It is NOT part of the representation of a string any more than a pointer
to a double is part of the representation of a double.

By definition of the data structure, its length is
not known, and the same scan must be repeated
each time we access the length.

But, if you access it repeatedly and the length matters, there is
nothing preventing you from keeping track of its length. Far too often,
the length doesn't matter and then, it would be wasteful to keep track of
it, nevertheless. Especially in a relatively low level language

More serious, the failure modes are quite horrible.

No failure mode exists for correctly written code.

In writing mode a wild pointer is like a loaded
machine gun, ready to start shooting around
at random. Pieces of the program, essential data
like the return address are wiped by the gun,
without any way for the system to stop it.

Which has zilch to do with strings and everything with the fact that C
supports pointers the way it does. And C pointers are largely responsible
for C's strength and popularity.

The program is in an undeterminable state,
depending on the direction the machine gun was
shooting.

Again, nothing to do with C strings.

Ahh. How nice. We are fearful. We risk that but
it works you see?

Have I ever told you that C is a sharp tool?

*I* do not do any mistake, you say.

Nope, I didn't say *anything* like that. Please have the minimal decency
to quote me correctly.

Well Dan, just keep cool.

You'd better take your own advice.

I have no fear to recognize that I do make mistakes.

Neither do I.

You say:


Well, Microsoft proposed one recently. And there are several.
I can't tell you which are "popular" since I am not doing
that kind of research. But they are surely used.

^^^^^^^^^^^^^^^^^^^^^^^^
Where does this certainty come from, since you haven't done any research
in this direction?

Safety was one of the more widespread goals.

C strings are perfectly safe.

I am trying to
build checked strings into lcc-win32. I think that a more
debuggable environment is easier to work with.

What happens when the incompetent programmer modifies the bytes containing
the strings length, by misusing pointers?

Nothing is safe in the hands of the incompetent.

The language doesn't support it.

So, they're not implemented in C?

I repeat that length prefixed strings should be easy to
use: name[2] should do what is supposed to.

Null terminated C *are* easy to use. And both can be misused.

My whole point is that data structure development should
be opened up to the C user that should be able to
specify data types that follow special rules he/she defines.

Isn't this already the case? Aren't users allowed to define they own
data structures?

For instance you could add a "flags" field to the standard
length prefixed string, and implement read only
strings, or time stamp based data, or whatever.

Precisely. It's the user job to do anything it wants.

The language should allow people defining programs
that handle the data structures in a way it suits them the
best.

It has being doing exactly this for the last 30 years. Have you been
sleeping?

C is not object oriented but we all use lists, stacks, hash tables
in our everyday programming.

So what?

No, this is a human performance issue. People get bored of
details. Computers do not.

So, people develop libraries tuned to their *specific* needs.

People use computers to make repetitive work. Why can't
we use the computer to check for mistakes?

Because C pointers allow mistakes that can't be mechanically detected.

Because it is perfectly possible to make mistakes even in languages that
allow all the checking you're dreaming about.

Your answer is:

Your are competent Dan. Surely more than me.

I belong to the other ones.
The ones that make mistakes. I am not afraid of saying this,
maybe because I think knowing this is the start of
knowledge.

Competent programmers make mistakes, too. Only perfect programmers don't.
However, it is a big difference between the mistakes made by competent
programmers and those made by incompetents.

When you realize your mistakes you can start learning.
Only then.

You start learning before that, but you also learn A LOT from your own
mistakes. But this has exactly zilch to do with a discussion about
counted strings...

Of course not Dan. Sure. I believe you that 100%

Believe me or not, this is one kind of mistake I am perfectly capable of
avoiding.

The garbage collector. I wrote one for my Lisp interpreter
in the 90ties, and I have adapted Mt Boehm's work to lcc-win32.

The GC is much better than malloc/free. But I know, that's
another discussion ...

AFAIK, Boehm's GC is not a complete solution and I am not aware of any
complete solution for C. The run time costs would exceed by far the
costs of malloc and friends.

I want it to be sharper Dan. C is not sharp enough
with all those bugs that creep the programs.

The bugs are not C's problem. Show me one language where the incompetent
is guaranteed to write bug free code.

You can't be sure of a tool if it is not designed to be sharp and safe.

Which part of C's design is unsafe?

You take the knife not at the edge?

That's precisely the point. The safety of both C and the knife is
dictated by the way they are used. Both are safe when correctly used
and unsafe when misused.

A knife is a sharp tool by its very nature.

But it can only be used because
you do not touch at the edge isn't it?

And what is your point?

That blunt side, that provides safety for your hand
makes for a usable knife. Without it, using a knife
is cutting yourself in the fingers

I found C's safety features perfectly adequate. Any additional safety
feature that affects its sharpness is not going to be accepted by the
competent C programmers.

That is the start.

A couple of weeks ago, bound checked pointers were a start. Have you
already finished that project? I'd like to play with your compiler that
implements bound checked pointers.

A better string library would be an achievement.

You have completely failed to convince anyone that your idea of a string
library would be any better than the <string.h> stuff.

And, since N such "better" string libraries have already been implemented,
why bother with a new one? Just because all the others were not written
by you? (i.e. the NIH - not invented here - syndrome)

Nothing spectacular, and very simple.

Is there anyone preventing you from doing the job? Hopefully, after
finishing the bound checked pointers...

BTW, what's the point in asking our opinions, if you're completely deaf to
them? Wouldn't your time be better spent working on your ideas, rather
than pointlessly arguing about them?

Dan

 

[Dan Pop]

[...]
I think it makes perfect sense, if you're going to make the move from C to
C++, to start by learning one feature (or just a few features) at a time.
What's wrong with the first one to focus on being, say, std::string ?
-leor

The fact that you get C-hackers using C++ - not C++ programmers.
The only way to swich from iterative programming to OO-programming is
to forget all you know about programming and start learning to think
object oriented. Then start learning a programming language.

This works only for people who have the privilege of never having to
implement the classes they use. Once you have to implement the classes
from scratch, you're back to (almost) pure C programming in an environment
with an order of magnitude more gotchas than C itself.

Dan

 

[Leor Zolman]

The fact that you get C-hackers using C++ - not C++ programmers.
The only way to swich from iterative programming to OO-programming is
to forget all you know about programming and start learning to think
object oriented. Then start learning a programming language.

C++ is not "a better C" it's something completly different and has
more in common with delphi, java or eifel than with C. It's not the
syntax that makes a difference it's the kind of thinking.

bye,
heyo

I think I've been misunderstood here. I've didn't say "C++ is a better C"
as in "C++ is a better language than C". Take a look at the context of the
post where I first used that term.

I use C++ by choice, but there's clearly a large place in my heart for C; I
don't participate in this newsgroup in order to preach the virtues of C++
over C. I like C just fine, thank you (well. perhaps with the exception of
VLAs), and never intended to start up a C vs. C++ flame war!

All I was saying is that it is a perfectly reasonable use of C++ to code in
a style generally considered "C-like" and take advantage of things such as:
iostreams for simple cin/cout operations
stronger type checking
prototype rules
conversion rules (esp. wrt void pointers)
new / delete vs. malloc et. al.
new-style casts to make intention clear (static_cast vs.
reinterpret_cast, for instance, are useful even in
a C-like context)
default arguments
bool
function overloading
(perhaps even.... references. YMMV.)

etc. (although those are most of the features I'd consider in the "Better
C" category). Basically, a lot of the stuff that isn't OO-specific is stuff
that, IMO, C users wouldn't mind having had in C from the get-go. Of
/course/ it "isn't C", its..."The Better C Portion of C++".
-leor





Leor Zolman
BD Software
(e-mail address removed)
www.bdsoft.com -- On-Site Training in C/C++, Java, Perl & Unix
C++ users: Download BD Software's free STL Error Message
Decryptor at www.bdsoft.com/tools/stlfilt.html

 

[Dan Pop]

Sorry but i do not get it.

What algorithm you use for mapping 278487 to "Arthur" ??

Hmm. I would have expected my explanation to be a little opaque
to a Russian native, perhaps, but I honestly expected the French
telephone to follow the American mold [see diagram].

The cellular phones do. Other phones may or may not have any letters
associated to the numbers.

Do your telephones
have any letters on the keys? Which ones?

The standard American telephone keypad:

ABC DEF
1 2 3

GHI JKL MNO
4 5 6

PRS TUV WXY
7 8 9

OPER
* 0 #

In Europe, the practice of associating mnemonic words to phone numbers
is practically unknown.

Dan

 

[Guest]

What algorithm you use for mapping 278487 to "Arthur" ??

Hmm. I would have expected my explanation to be a little opaque
to a Russian native, perhaps, but I honestly expected the French
telephone to follow the American mold [see diagram]. Do your telephones
have any letters on the keys? Which ones?

<snip>

He asked what ALGORITHM you used, not what an American telephone looks
like. It seemed readily obvious (to me, at least) that he wanted to
know how std::string and std::map made your algorithm so much easier.

I'd like to know as well.

 

[jacob navia]

In <[email protected]> "jacob navia"

A couple of weeks ago, bound checked pointers were a start. Have you
already finished that project? I'd like to play with your compiler that
implements bound checked pointers.

The problem Dan, is that you pointed out that due to the nature of the
language, with its casts, etc, that would be an extremely difficult
undertaking. In one of your messages you warned that this will
never work because of constructs like
char tab[2][3];

char p = *( ((char *) tab) +10;

It is not that I do not take your advise seriously. To the
contrary. I did take you very seriously.

I reviewed the literature, and it was very pessimistic about the feasibility
of it. There is an implementation for GCC but they ran into terrible
problems, and they use the constructor/destructor paradigm of C++,
what I can't do.

Another point was that the compiler *must* remain compatible with C99.
So, the old arrays must go on working.

The consequence in my context of all this research,
is to use operator overloading to build data types that
carry the size information around and are checked at run time,
and leave C arrays as they are now.

So this discussion about bound checked strings
is the same thread actually, in a different flavor.

I have already written:
bitstrings,
strings,
vectors,
hashtables,
stacks,
and lists.

I plan to add FIFO and a few others.

All of this containers are accessed in a uniform way. This is already done.

What is still NOT done is making the string package in such
a way that will require MINIMAL porting, i.e. I have to tweak the result
of the overloaded operators in such a way that
if (Strchr(StringA,'\n')) {
}
even if Strchr returns a String data type. I attain this by overloading
the != and the == operators that test for it. And it works.

Still, there are several other problems, and I do not expect to have
something
running well before 1-2 months. The current version of the container lib
is *very* experimental

To see a description of what is already available just download the
documentation of lcc-win32 and see the "containers" folder.

Please note that this documentation will change, since as I advance
new problems appear.

For instance I had

String Strchr(String s,int character);

This would return a freshly allocated string with a copy of the characters
found in "s".

This wasn't really very good since many programs use strchr to loop
in a string.

Suppose you read a 1MB file into a string. Then you use strchr to find
the end of the first line. In the old implementation Strchr would return
a copy of almost 1MB starting after the first line...

Not very efficient. I changed that now by introducing a Stringp, or string
pointer, that represents a range of characters within a string, without
duplicating the content of the original string.

This is an example of the difficulties of building this. But it looks
feasible,
more than the first proposal with

#pragma bounds_checking

jacob

 

[Nils Petter Vaskinn]

In Europe, the practice of associating mnemonic words to phone numbers
is practically unknown.

Iterestingly a lot of people (me included) remember numbers (phone, pin
etc) as a pattern or shape. Remembering the actual number is helped by
having a numpad there, eg 7319 is remembered as an X shape, and having a
numpad to translate the shape or pattern into a number.
Different keypads confuse things a little, eg typing a rememberd phone
number (with 123 row at the top) on a computer keyboard (with 123 at the
bottom) takes a little more effort.

Can anyone make a computer program that chooses an image or a figure to
visualize a phone number?

 

[Dan Pop]

The consequence in my context of all this research,
is to use operator overloading to build data types that
carry the size information around and are checked at run time,
and leave C arrays as they are now.

So this discussion about bound checked strings
is the same thread actually, in a different flavor.

I have already written:
bitstrings,
strings,
vectors,
hashtables,
stacks,
and lists.

I plan to add FIFO and a few others.

All of this containers are accessed in a uniform way. This is already done.

What is still NOT done is making the string package in such
a way that will require MINIMAL porting, i.e. I have to tweak the result
of the overloaded operators in such a way that
if (Strchr(StringA,'\n')) {
}
even if Strchr returns a String data type. I attain this by overloading
the != and the == operators that test for it. And it works.

If all this stuff is not implemented in standard C, you've been wasting
your time.

Dan

 

[jacob navia]

If all this stuff is not implemented in standard C, you've been wasting
your time.

If you compile the library with no extensions enabled it will work, but
you will have to use explicit function calls and not the generic functions.

Instead of writing:

insert(String,2 'a');

you write

insert_string(String,2,'a');

The porting of existing string code becomes much more difficult
since array indexing must be replaced with:

set_element_string(Str,2 'a');
instead of
Str[2] = 'a';

But it is still usable.

For each overloaded function I have given a standard C name.
For each operator there is a "plain text" version.

Insetad of writing:
if (str[2] == 'v') {

}
you write:
if (get_element_string(str,2) == 'v') {
}
Instead of writing
if (!Strchr(str,'a')) {
}
you write:
if (Strchr(str,'a') == invalid_stringp) {
}

I have tried to give the names an uniform aspect, i.e.
you have:

insert_string
insert_vector
insert_hashtable

etc.

Operator overloading is a way of accelerating the
writing of the programs. It has many drawbacks, but
it is better than the situation now.

 

[Dan Pop]

What algorithm you use for mapping 278487 to "Arthur" ??

Hmm. I would have expected my explanation to be a little opaque
to a Russian native, perhaps, but I honestly expected the French
telephone to follow the American mold [see diagram]. Do your telephones
have any letters on the keys? Which ones?

<snip>

He asked what ALGORITHM you used, not what an American telephone looks
like.

The ALGORITHM is based on the layout of an American telephone keypad.

It seemed readily obvious (to me, at least) that he wanted to
know how std::string and std::map made your algorithm so much easier.

That's far from obvious. It's more likely that he didn't understand the
connection between 278487 and Arthur in the first place.

I'd like to know as well.

There is little point in discussing std::string and std::map here, even
in an off topic thread, considering that we all know a better newsgroup
for this purpose.

If I were to write such a program, I'd assume CHAR_MAX to have a
reasonable value and build a lookup table for converting from letters
to digits. Then, a custom strlen-like function can be used to compare
the target string (composed of digits) with the candidate string
(composed of lower case and upper case letters).

static char lut[CHAR_MAX + 1];

void lutini(void)
{
lut['a'] = lut['A'] = '2';
lut['b'] = lut['B'] = '2';
...
lut['z'] = lut['Z'] = '9';
}

int match(char *phoneno, char *word)
{
int i, len = strlen(phoneno);

if (strlen(word) != len) return 0;

for (i = 0; i < len; i++)
if (lut[word] == phoneno) continue;
else return 0;

return 1;
}

The "word" string is supposed to be composed only of characters for
which isalpha() is true in the C locale. Other characters cannot be
mapped to the cellular phone keypad in a portable way.

Dan

 

[Guillaume]

The fact that you get C-hackers using C++ - not C++ programmers.
Yeah.
Object oriented programming can be done in a lot of different high-level
languages. C is no exception. I've been routinely programming in an OO
way in C for years... with structs, unions and function pointers, you
can really do anything you want in terms of object oriented programming.

On the other hand, some C++ programmers have a hard time thinking "OO",
and mostly use C++ because they have been told to do so. Most of them
use "classes", but not all of them know how to design objects in a way
that makes sense.

I don't quite agree with you when you say: "The only way to swich from
iterative programming to OO-programming is to forget all you know about
programming". Certainly not. I don't even think you can learn OO
programming in a decent way without a prior strong background in the
basics of programming. That is, programming with a little less abstract
approach. Unfortunately, this is getting more and more common. There's
a whole lot of fresh software engineers who can use very sophisticated
concepts, but they don't actually know what's behind the scene. They
actually don't know what they are doing. This is a real concern.

 

[Mike Wahler]

Yeah. But they don't do so on a full-powered Harley, they do so on a
250cc Toyota.

Hodaka 125. Actually, this was my first bike precisely because
it wasn't ten times my weight, with a zillion horsepower. And I still
follow my own rule: if I can't lay it down and pick it up by myself,
I won't ride it.

Back [almost?] to topic: If I couldn't control my memory handling
and pointers, I wouldn't use C. My first programming was with
'plug boards', I'm not sure if it was 'safe' or 'dangerous'.
I never got an electric shock, and didn't destroy any hardware,
anyway.


-Mike

 

[Mike Wahler]

Leor Zolman <[email protected]> wrote in message

[...]
I think it makes perfect sense, if you're going to make the move from C to
C++, to start by learning one feature (or just a few features) at a time.
What's wrong with the first one to focus on being, say, std::string ?
-leor

The fact that you get C-hackers using C++ - not C++ programmers.

A tool cannot be held responsible for its abuse (despite
claims to the contrary by American attorneys).

The only way to swich from iterative programming to OO-programming is
to forget all you know about programming

Vehemently disagree. Many fundamentals of programming translate
to *any* paradigm. (As each year goes by, I'm more and more glad
that I learned with pencil and paper sitting at a desk, rather
than with today's souped up machines and the latest 'whiz bang'
language, subjected to claims of its omniscience.)

Or should I e.g. unlearn and relearn basic logic each time I learn
a new programming paradigm?

and start learning to think
object oriented. Then start learning a programming language.

You're expressing (as so many do) huge misconceptions:
1) That using C++ automatically means you're using OO.
2) That 'iterative' programming cannot be done with C++.

There is nothing at all OO about C++'s std::string.

C++ is not "a better C"

That's mostly what I use it for. So are my C++ programs
somehow 'illegitimate' because of that?

it's something completly different and has
more in common with delphi, java or eifel than with C. It's not the
syntax that makes a difference it's the kind of thinking.

OO does require a different mindset from that of e.g. prodedural,
but using C++ does *not* require an OO design.

-Mike

 

[Mike Wahler]

In <[email protected]> "Arthur

"Arthur J. O'Dwyer" <[email protected]> a écrit...

Given a phone number composed of decimal digits, and a dictionary
of English words such as /usr/dict, produce a list of plausible
mnemonics for the number according to a standard telephone keypad.
E.g., given the input number "278487," the program would produce a
list including "Arthur," "2-rug-up," and "2-suits."

Sorry but i do not get it.

What algorithm you use for mapping 278487 to "Arthur" ??

Hmm. I would have expected my explanation to be a little opaque
to a Russian native, perhaps, but I honestly expected the French
telephone to follow the American mold [see diagram].

The cellular phones do. Other phones may or may not have any letters
associated to the numbers.

Do your telephones
have any letters on the keys? Which ones?

The standard American telephone keypad:

ABC DEF
1 2 3

GHI JKL MNO
4 5 6

PRS TUV WXY
7 8 9

OPER
* 0 #

In Europe, the practice of associating mnemonic words to phone numbers
is practically unknown.

Dan

 

[Mike Wahler]

In <[email protected]> "Arthur

"Arthur J. O'Dwyer" <[email protected]> a écrit...

Given a phone number composed of decimal digits, and a dictionary
of English words such as /usr/dict, produce a list of plausible
mnemonics for the number according to a standard telephone keypad.
E.g., given the input number "278487," the program would produce a
list including "Arthur," "2-rug-up," and "2-suits."

Sorry but i do not get it.

What algorithm you use for mapping 278487 to "Arthur" ??

Hmm. I would have expected my explanation to be a little opaque
to a Russian native, perhaps, but I honestly expected the French
telephone to follow the American mold [see diagram].

The cellular phones do. Other phones may or may not have any letters
associated to the numbers.

Do your telephones
have any letters on the keys? Which ones?

The standard American telephone keypad:

ABC DEF
1 2 3

GHI JKL MNO
4 5 6

PRS TUV WXY
7 8 9

OPER
* 0 #

In Europe, the practice of associating mnemonic words to phone numbers
is practically unknown.

It's very common in the U.S., to the point where the phone companies
charge an extra fee for 'special' numbers, mostly for business advertisers,
e.g. a roofing company in my town has the phone number, 1-800-ROOF.
(the assumption is that it can be remembered without writing it down).

-Mike