Increasing efficiency in C

[CBFalconer]

.... snip ...

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

How about the practice of mnemnonic exchanges? My number here is
288-nnnn, which used to be known as ATlantic 8-nnnn. Before the
era of 3 digit exchanges it would have been ATlantic nnnn, but
that expansion happened shortly after the war.

 

[CBFalconer]

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,

No rotary dials left over there

 

[jacob navia]

Back [almost?] to topic: If I couldn't control my memory handling
and pointers, I wouldn't use C.

You keep control of everything. But the system should
have an automatic.

When you turn the wheel there is a point where the
machine refuses to turn more. It just refuses to
obey to a nonsense command. It is build like that.

When you attempt to write beyond a pointer limits
the system doesn't do it.

You still have an error, and you can fire an exception
or just return false, and leave it up to the calling
routine.

You keep control of the error since you are the
only one that can fix it. The machine will not fix
it.

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.

You should keep an eye into nostalgy.

Yes, those were the times.

I am too old to look back. I want to look forward.

If we program remembering the past we are doomed.

We have no future.

Remember the future. Today's fast machines provide
power for a new and widespread way of developing,
in scales much bigger than before.

Today's priorities aren't those of years ago.

A good antidote against nostalgy is realizing that
those circuit boards are gone for good.

There are much more powerful circuit boards today.

 

[Nils Petter Vaskinn]

Nils Petter Vaskinn wrote:

[about phones keypds and remembering numbers}

No rotary dials left over there

Not in use that I know of. But my granny had one when I was small, by the
time we got a phone they had buttons. But I think my dad has that old
rotary dial phone stashed away somewhere in the attic. He never could
throw away anything.

 

[Mike Wahler]

Back [almost?] to topic: If I couldn't control my memory handling
and pointers, I wouldn't use C.

You keep control of everything.

That's right. That's why I like C. But with such
control comes responsibility. I if lose control,
it's my own fault.

But the system should
have an automatic.

C doesn't require support of a 'system', and in the
presence of one, makes very few requirements of it.
Some hardware and some operating systems do have
'safeties' built in. Some do not. C is designed,
intentionally, to be able to be used with either.
It does allow one to create 'software safeties' if
desired, but does not impose such a burden in cases
where it's not needed or desired. Such things belong
in e.g. special-purpose libraries, not the language
or its 'standard' (i.e.platform-neutral) library.
C is a 'lightweight', *flexible* language. I like
it that way.

I like Dan's 'sharp tool' metaphor.

If a soldier in combat shoots his foot, should we
tell him to stop carrying his gun loaded, or train
him to carry and handle it safely? If he cannot follow
such training, he does not belong on the battlefield.

When you turn the wheel there is a point where the
machine refuses to turn more. It just refuses to
obey to a nonsense command. It is build like that.

And the 'response' can vary widely amongst machines.
'Recovery' might or might not be possible. Careful
coding is the way to prevent such responses.

When you attempt to write beyond a pointer limits
the system doesn't do it.

One cannot always assume existence of a 'system' (other
than the program itself). If by 'system' you mean only e.g.
a hardware platform, of course its capacity and possible
behaviors must be considered (could be addressed with
coding practice, or perhaps simply warnings in documentation).

You still have an error, and you can fire an exception
or just return false, and leave it up to the calling
routine.

Or you might have no recourse at all. The machine
could 'freeze up'. The only solution is careful,
thoughtful coding (or dependence upon such from others,
via e.g. a library). Of course platform-specific
issues are important, but they're not part of the
standardized, 'general purpose' language, C. The
design of C allows the creation of such platform-
specific controls and checks, anyway.

You keep control of the error since you are the
only one that can fix it. The machine will not fix
it.

Depends upon the machine, but yes, imo one should
code carefully and thoughtfully, making the application
as 'self-responsible' as possible.

You should keep an eye into nostalgy.

Yes, those were the times.

I am too old to look back. I want to look forward.

I look both directions. Prior knowledge and experience
are as valuable resources as new knowledge. The latter
often depends upon the former, as well.

If we program remembering the past we are doomed.

So I should discard e.g. elementary logic, because
I learned it a long time ago?

We have no future.

Remember the future.

Now that made me smile. I can *consider* the
future, I find it difficult to *remember* it.

Today's fast machines provide
power for a new and widespread way of developing,
in scales much bigger than before.

But, (and I think this is essentially the crux of my
objections to your ideas about 'safetifying' C strings):

Trying to "bulletproof" everything imo encourages
mindlessness. *Not Good* for a programmer. This
should be certainly implemented as much as possible
at the end-user level, by programmers who *think*.
Even the C++ 'std::string' (as well as the language
itself) that I mentioned can be abused. It *is* imo
'safer' but not bulletproof, nor can it ever be.

It's this recent trend (that I see) in languages to obviate
the need to think, that I find very disquieting.

Today's priorities aren't those of years ago.

Some are, some are not. Priorities also depend upon
an application's domain.

A good antidote against nostalgy is realizing that
those circuit boards are gone for good.

I was not promoting nostalgia, nor 'plug-board' programming
today, only giving an example.

And, no 'circuit boards', imo will never go away.
They're often implemented in silicon nowadays, and
programmed at higher levels, that's all.

There are much more powerful circuit boards today.

Yup. But the concept of a 'circuit' and its usefulness
imo will not be going away any time soon. I don't
do 'plug board' programming any more, but while learning
it, I did learn about 'circuits', and find such learning
still very useful today. Hey! Who turned out the lights!?!

Anyway, if you see a need for your 'safer' strings, by
all means make a library for such. But don't impose
it upon the basic language and library.

-Mike

 

[Nick Landsberg]

Back [almost?] to topic: If I couldn't control my memory handling
and pointers, I wouldn't use C.

You keep control of everything.

That's right. That's why I like C. But with such
control comes responsibility. I if lose control,
it's my own fault.

But the system should
have an automatic.

[ Much Snipped ]

Another 2 cents US into the discussion.

The "C" language is used for a multitued of
applications. For some of these applications,
failure is benign, for some not.

Jacob, in your proposal what should be the
default behavior if an array bounds is
exceeded? Abort the program?

If it is on a PC web browser, that is perfectly
acceptable behaviour. (I think).

If it is in a program running a heart-lung machine,
I doubt that it is.

If a programmer were to use current C and his/her
program caused the heart-lung machine to go haywire,
that programmer ought to be shot (overstatement).
If, using your proposal, and the default was to abort
the program, that programmer should still be shot!

If the default is not to abort the program, what then?
Continue as we do today? That's a no-op.

If the proposal is to override the behaviour and take
intelligent action when that happens, then the
selfsame competent programmers who today take pains
to make sure they do not exceed array bounds would
be the ONLY ones who took the same pains to override
default behaviour. For the incompetent ones, the program
would abort. (Possibly a little sooner than it does now,
I'll grant that. Maybe training them to be more
competent would be a better answer?) As Dan Pop, I believe,
said, "C is structured assembler." To use it properly
you have to develop a certain expertise. This expertise
involves checking all possible error conditions. If you
don't do that, you should not be programming in C.

See .sig line.

You are trying to make it foolproof.

 

[CBFalconer]

.... snip stuff about redefining C ...

Today's priorities aren't those of years ago.

A good antidote against nostalgy is realizing that
those circuit boards are gone for good.

There are much more powerful circuit boards today.

We will always need assembly for some things. Having gotten that
out of the way, we need organized structured means of accessing
the machine + assembly code mess that results. That is structured
assembly, otherwise known as C. We can add warnings for obvious
errors (although some that look obvious aren't even errors), but
we need that level for building blocks.

When we get to needing well proven and error-resistant languages,
we go elsewhere. I recommend Pascal and Ada for this level,
others have other ideas.

At any rate "C with restrictions" is not C, but some new
language. It probably has Cs faults (look at C++) so is just not
a good idea, and in addition it is OFF-TOPIC here.

 

[Roc]

But, (and I think this is essentially the crux of my
objections to your ideas about 'safetifying' C strings):

Trying to "bulletproof" everything imo encourages
mindlessness. *Not Good* for a programmer. This
should be certainly implemented as much as possible
at the end-user level, by programmers who *think*.
Even the C++ 'std::string' (as well as the language
itself) that I mentioned can be abused. It *is* imo
'safer' but not bulletproof, nor can it ever be.

It's this recent trend (that I see) in languages to obviate
the need to think, that I find very disquieting.

A similar discussion arises at my work every so often. Here, an infatuation
among some .NET programmers with the Intermediate Language are boldly saying
to "old-timers" (such as myself; someone who programs in C, or C++, or
<insert 'old' language here>) that it will be /unreasonable/ to program in
'old' languages once more IL compilers come out. I think their lofty idea
revolves around performance gains from a machine-code compiled language will
be moot when balanced against the presumptions: (a) machines/devices by then
will be so much faster than the majority of people who use them; and (b)
development cycles are only getting shorter.

I share your concern, Mike. Is it "making the language easier", or is it
"protection from a lazy programmer"? To quote one programmer, "...you don't
need to program anything anymore - it's all written for you. You just need
to find the right calls to make."

Eeesh. Guess I'm going to have to go find a microwave to program... A PC
will be too 'advanced' for me to program...

Now if only I can figure out what a free-standing environment is! <smirk>

 

[Mark McIntyre]

How about the practice of mnemnonic exchanges? My number here is
288-nnnn, which used to be known as ATlantic 8-nnnn.

In the UK exchanges were known by name eg Oxford, Inverness etc, and I'm
given to believe that the original dialling codes were based on three of
the letters in their names, converted to digits. This link has long gone.

 

[Dik T. Winter]

> In the UK exchanges were known by name eg Oxford, Inverness etc, and I'm
> given to believe that the original dialling codes were based on three of
> the letters in their names, converted to digits. This link has long gone.

That link has lasted only a few months (and it was two letters). OXford
would have area code 009x (in the UK the letter O was on the digit 0), but
that was changed very soon, together with other exchanges that started with
letters O or Q. It was changed before I even became interested in this
subject. On the other hand I remember the local Parisian exchange OPEra.
So a local number starting with 072, which lasted a bit longer.

Letters on telephones have gone out of use in Europe in the early to
mid 60s.

 

[Peter Shaggy Haywood]

Groovy hepcat jacob navia was jivin' on Wed, 3 Mar 2004 23:07:25 +0100
in comp.lang.c.
Increasing efficiency in C's a cool scene! Dig it!

As everybody knows, C uses a zero delimited unbounded
pointer for its representation of strings.

Wrong! The term "zero delimited unbounded pointer" is meaningless.
There ain't no sech animal.
As everybody who knows about C knows, C uses contiguous sequences of
characters, each such sequence terminated by a null character, for its
representation of strings.
[Snip rest of the post I didn't bother reading.]

--

Dig the even newer still, yet more improved, sig!

http://alphalink.com.au/~phaywood/
"Ain't I'm a dog?" - Ronny Self, Ain't I'm a Dog, written by G. Sherry & W. Walker.
I know it's not "technically correct" English; but since when was rock & roll "technically correct"?

 

[CBFalconer]

That link has lasted only a few months (and it was two letters).
OXford would have area code 009x (in the UK the letter O was on
the digit 0), but that was changed very soon, together with other
exchanges that started with letters O or Q. It was changed
before I even became interested in this subject. On the other
hand I remember the local Parisian exchange OPEra. So a local
number starting with 072, which lasted a bit longer.

Letters on telephones have gone out of use in Europe in the early
to mid 60s.

There is the difference. Here in leftpondia we have rabid
conservatives, so the letters never left the dial or the keypads,
although they did leave the telephone directories. So every child
can learn a slightly truncated alphabet from the telephone. This
proves that rabid conservatism is not entirely bad.

Some pads here add the Q to the 7 key, and the z to the 9 key.
All this allows automated systems to ask callers to spell the name
of the party they want, etc., usually with success. Any move to
take letters off the keypads would cause all sorts of havoc.
Those systems are usually programmed in C. And you thought this
was OT

 

[jacob navia]

Jacob, in your proposal what should be the
default behavior if an array bounds is
exceeded? Abort the program?

Depends which compile time option you used when building the library.
By default the program aborts.
If you compile it without exception handling, the called function will fail,
returning false or doing any other sensible action.

In critical applications, this behavior is better than trashing
the return address or making other catastrophical actions.

For instance in a machine where failure is not an option,
this will allow the program to go on, in better conditions
than now. The string operation will fail, but the integrity
of the program is preserved.

Assuming that the String "S" as a capacity of 5, the
operation Strcpy(s,"a very long string") would result
in a truncated copy. This can provoke errors later, but
it is better than destroying data that lies after the
storage reserved by "S"

 

[Servé La]

Solution 1: Don't care what the other guy is doing; that's *his*
part of the project, and you only need to know the interfaces. Make
sure the interfaces are all written using standard C types and
passing mechanisms, so that modules can talk to each other with
some sort of reliability.

Yeah sure. No bugs will ever be found, this other guy will always work
there, never be sick and never take a holiday. We can all sit on our own
island and just pass C types to each other.

Solution 2: Tell the other guy up front that he shouldn't use
the complicated parts of C++. Or better, get your boss to tell
him.

Yes, tell the other guy. Go tell! They won't start a discussion of course
and then *you* can start using the features that *you* think are useful.
Don't forget to tell the other guys what they are allowed to use. And make
sure they don't forget so you have to write it all down, or let your boss
write it down. And punish them when they do forget, show them the paper and
cut them with it.

C++ is full of pitfall features and people will use all the features that
they can use.
But C++ also has some good features, but whenever you mention that you want
a C++ feature in C the only response you'll get is: "Go use this other
language that we want no part of". That's not helping C at all.

 

[Arthur J. O'Dwyer]

:
[...]

Letters on telephones have gone out of use in Europe in the early
to mid 60s.

There is the difference. Here in leftpondia we have rabid
conservatives, so the letters never left the dial or the keypads,
although they did leave the telephone directories. So every child
can learn a slightly truncated alphabet from the telephone. This
proves that rabid conservatism is not entirely bad.

While you may be correct about the rabid conservatism, I naturally
assumed it was the rabid commercialism. I was quite surprised when
I was informed by this thread's European participants that most parts
of Europe don't have letters on telephone digits. No 1-800-FLOWERS?
No "dial down the center with 1-800 C-A-L-L A-T-T"? No Moviefone?
They don't know what they're missing!

-Arthur

 

[Arthur J. O'Dwyer]

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].

<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.

I agree with Dan, that Jacob undoubtedly just didn't understand the
number-letter correlation. But for the record, I used the C++ equivalent
of a blunt object:

Take the dictionary and add each word's number-representation to a map:
n2w_map["78487"] = "suits";
Run through that map with strstr() and produce a collection of
pairs mapping words to locations within the target telephone number:
"suits" is in "278487" at position 1.
Recurse over that collection, producing all possible sequences of
words that "sum" to the telephone number in question.
"2-suits" is one result; "Arthur" is another.
(I added rules to the recursion so that the last digit in a number
could represent itself, as could the first; hence "2-suits,"
even though "2" isn't a word.)

I then tried to reformulate the program to deal with l33tsp34k like
"B4"->"before" (thus mapping the dictionary word "before" to the
number-representations "24" AND "233673"), but that seemed like more
work than it was worth. This was, after all, just a quick hack for
fun, not a real project.


A couple of notes on Dan's program:

My first impression of the program shows that I may be spending too
much time in international programming groups ;-) I saw identifiers
like "lutini" and "phoneno" and thought, "What, is Dan Pop using Italian
now?" ("lutini"->"Look-Up Table INItialization"; "phoneno"->"PHONE
NO. [number]".)

int match(char *phoneno, char *word)

Dan has the letter-to-number algorithm correct, but he'd have to
be generating a whole lot more "word"s than I did, or a lot more
"phoneno"s, if this function were going to help produce multi-word
mnemonics like "2-rug-up."

-Arthur

 

[Dik T. Winter]

> I was quite surprised when
> I was informed by this thread's European participants that most parts
> of Europe don't have letters on telephone digits. No 1-800-FLOWERS?
> No "dial down the center with 1-800 C-A-L-L A-T-T"? No Moviefone?
> They don't know what they're missing!

It is coming, but very slowly (this is due to mobiles, eh cellphones,
with letters). And, indeed, the last time I ever saw a phone with
letters (before the emergence of mobiles), was in the late sixties/early
seventies, in the UK. But we do not have the hassle where the owner of
1-800-FLOWERS appears to think that he/she also owns 1-888-FLOWERS,
1-877-FLOWERS, etc. But none of the three phones I have here at home
has letters on the dials/buttons. BTW, in Australia they would have
difficulty with xxx-FLOWERS, as there are about three standard layouts,
and the letters O, Q and Z switch around a bit among the three layouts.

 

[Servé La]

Many != all.

Your proposal would impose that cost on all applications. Leaving things
as they are would allow applications to store the length alongside the
string if they choose to. (or link against a library that provides such a
string type and replacement string manipulation functions)

The applications that really can't afford the size_t can of course still use
the zero terminated strings, I don't think those will be removed from the
standard in the near future

 

[Servé La]

And frankly, that sums up my reaction to this idea. It would make
programming with strings in C considerably more hassle-ful, to, as far
as I can tell, an entirely ephemeral speed advantage, which is more than
likely to be offset by the more complicated and time-consuming code
needed to handle these strings in any other circumstance than finding
their length - an operation which isn't performed as often as you'd
tihnk, in quality code.

There is no quality code, only average code

 

[Servé La]

As everybody knows, C uses a zero delimited unbounded
pointer for its representation of strings.

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.

A more efficient representation is:

struct string {
size_t length;
char data[];
};

Have you considered wchar_t? Very important to include nowadays.