c / c++ : is it end of era ?

[Random832]

João Jerónimo said:


No, it can't be used before it is defined. But its *name* can be used in a
typedef, yes.


Yes, that's legal.


When invoked in conforming mode, it must complain.

What would it's complaint be? How's GCC supposed to know that he's
trying to create an object when the actual code he writes is a mere
typedef?

I think you don't quite understand in what situation he's saying he
doesn't get an error.

 

[Mark McIntyre]

Interfaces should take
care automatically of string lengths. A string is a single
OBJECT composed of data and a length (counted strings),
and maybe other fields.

This is by the way vastly more efficient than counting
the length of the string at each usage, as you may know.

This is a serius overstatement.

In cases where checking string length is done often, then doing it at
each usage is of course inefficient.

If on the other hand your programme /never/ needs to know the lengths
of strings, then being forced to use an object which includes the
overhead of stringsize is also inefficient.

I recall working on some code that assiduously checked for
divide-by-zero conditions before performing any division, even for
divisors such as 1+e^x. The check caused significant performance loss.
Had we been using an object that included "for free" a div/0 check, we
would have been faced with a major rewrite.
Elsewhere in the same code, there were numerous uses of strncpy
instead of strcpy. This gained nothing, not even performance, as the
source strings had been carefully loaded into a buffer of known width
and padded with blanks. The writer clearly thought it was a good idea
however, as they'd cleverly commented every single instance with a
warning not to change it.

The lesson to take from this is that efficiency is not a
one-size-fits-all solution, and one should not assume .

Simplifying, making interfaces less complex makes them less
error prone,

Sometimes, assuming the interface designer is competent and doesn't
make any mistakes, and with the price of less flexibility and
adaptability.

and is surely a step in the right direction.

Again sometimes.

The performance implications of calling

MyAdd(Number *a, Number *b);

or doing
a+b;

are ZERO.

In both cases there is a function call.

Really?
the second involves loading two values into a register and calling ADD
or somesuch. Zero function calls.

The first might well involve creating a call stack, performing sanity
checks on the values, checking the result fits into a "Number"
whatever that is, and could easily take very much longer.

I've seen this done - I've seen novices who thought a clever way to be
overflow safe was to write functions to replace the operators, and
invariably their code ran like a dog.



--
Mark McIntyre

"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it."
--Brian Kernighan

 

[Richard Heathfield]

Random832 said:

What would it's complaint be?

Along the lines of "you are trying to create an object of a type that does
not exist."

How's GCC supposed to know that he's
trying to create an object when the actual code he writes is a mere
typedef?

If that's how he's trying to create an object, then no complaint is
necessary, but neither will an object be created.

I think you don't quite understand in what situation he's saying he
doesn't get an error.

If he's trying to create an object of an incomplete type, either he's doing
it wrong (garb foo or he's doing it really wrong (using typedef, which
doesn't create objects). If the former, the compiler must complain. If the
latter, then I am reminded of the old saying, "That isn't right. That isn't
even wrong!"

 

[Randy Howard]

Randy Howard a écrit :

I am just saying they are not needed any more. Why they are here?

Right or wrong (usually the latter) backwards compatibility wins a lot
of arguments. Using the windows platform, you are no doubt well aware
of the results of this problem. Deal.

Ahh bugs are BAD BAD.

They're certainly not good, other than as a means of obtaining more
experience in eliminating them.

Great discovery. We are discussing how to avoid them if possible.

Sort of. You are discussing how your alternative language, which you
refuse to call by another name tackles avoiding some problems while
ignoring others. Several qualified language designers have made
attempts in that direction, but without the silliness of pretending the
resulting language is the same as C.

One of the ways to avoid them is to make things automatic
whenever possible so that the programmer has less to do, and less
possibilities of errors.

That's also a way of removing control over how aspects of programming
are addressed, hoping the implementation is correct, but being less
able to correct it if it is not, and in all likelihood worsening
performance. Those are all tradeoffs, which may or may not be the
right decision for a given project.

Why C is better than assembly?

It's not, generally speaking. It depends upon the project needs. In
some cases it is, in others it is not. The most common case being
where performance is important, but portability is even more so.

Because the level of detail that you have to care about is less.

You just write:

c = a+b;

and you do not have to care about which register you use,
which address are b and c, etc etc.

mov and add instructions aren't particularly confusing for some, for
others they are apparently like trying to land a man on the moon.
Luckily, choices are available.

If we have counted strings the length of the string is no longer
a problem you have to manage but the string library.

You are free to use such things in standard C without mangling the
compiler. You are also free to use a compiler for something other than
C that does things differently. Then of course, that would be
off-topic for this newsgroup.

If you use the GC you do not care about free(). One problem
LESS to care about

If you use a shell script you don't have to worry about a compiler.

If you hire someone else to write it for you, you don't even have to
understand anything about the problem other than how to describe it.

You can carry this to any silly extent you desire. however, almost
none of that has a bearing on C.

 

[Randy Howard]

Randy Howard a écrit :

To answer you in terms of your own analogy:

C gives you a machette without a HANDLE.
You can't use it without cutting yourself the hand.

One problem. Your counter-example is false. C gives you a machete,
and a handle. The handle is the standard document that describes (in
painful detail) all aspects of the machete, how it works, how it should
be used, and in many cases how it should not be used. But, just like
people assembling toys the night before xmas for their children, too
often they don't read the instructions provided, and things go awry.

I want to add a HANDLE to the machette i.e. a BLUNT
side where I can handle it without getting my blood in my
fingers...

People have been doing this for several decades. It's not immediately
obvious why you can not find a way to do the same.

 

[Randy Howard]

Richard Heathfield a écrit :

I am speaking not about "making it as easy as possible" (do not know
where you got that) but about "less error prone interfaces"!

You have not demonstrated that fewer errors will result. You are
hoping that it will, and in that you may actually be correct. You are
also asking us to accept on faith that this implementation that does
all these things for us will do them without error, which they may do.

You're also /completely/ discounting the requirements that many of us
have to be able to compile code on a very wide array of platforms and
compilers. This requires some of us to play in a much smaller sandbox
than you are willing to acknowledge.

This means that mind-dumbing requirements like having to take
care of all the millions of string lengths that you have got
in your program are to be banned.

I have to call BS now. You are in no position to "ban" anything. If
you are truly incapable of handling C style strings in your programs
without your mind becoming numb or other bad side-effects, then by all
means, find another language more suitable to your programming style.

What you are not to do, is pretend like determining for the rest of us
what we can and can not do in our programming is your bailiwick.

I have nothing against making it as easy AS POSSIBLE... Read well the
"AS POSSIBLE" part.

I have no need for it to be made easier. In fact, I claim that one of
the key contributors to the huge assortment of incredibly bad code on
the planet is that it has been made far too easy to produce software of
incredibly bad quality. Almost anyone can try, and far too many
succeed. If it were harder, we'd have less whining about making it
easier, and a lot more (as a percentage) qualified programmers, less
crappy software, etc. I realize I'm probably in the minority, and what
you or others would like to see is a programming language so simple
that even inmates in an asylum could produce their own operating
system. I hesitate to point out that this has apparently already
happened at least once, and the results are staggeringly bad.

Simplifying, making interfaces less complex makes them less
error prone, and is surely a step in the right direction.

In order to know if a step is in the right or wrong direction, you have
to know where the destination lies. More importantly, the answer is
different for each traveler, unless you happen to live somewhere where
everyone is identical (*shudder*)

When implementing the extensions in lcc-win32 nothing is paid by other
software that does not use them. All the extensions do not affect
in any way the rest of the language.

Fine and dandy. One minor problem though. It's not C. There is a
newsgroup for lcc if I'm not mistaken, and it's not this one. If you
want to evangelize on the merits of your language, give it a name,
write a paper on it, and get it published. Or perhaps start a blog, or
submit it to DDJ, there are a number of options, any of which are more
appropriate than what you are attempting here.

 

[August Karlstrom]

(e-mail address removed) skrev:

1) My friend and I have noticed that working with arrays in C are much faster than anything we compile with any other language. The programming concepts are the same, but the implementation on systems make C run faster on average

(from our experience)

OK. I get about the same speed in Oberon though (with bound checks
turned off).

2) The built in library functions of bsearch and qsort work faster than using strings in C++ for doing much the same thing. (Obviously a lot faster then using BASH)

Sure, character arrays will always be more efficient (and less
convenient) than a "real" string type. (Oberon, as C, uses character
arrays for strings).

I must say that these are observations that we have seen. I'm not stating they're a universal experience, have
you had the same experience?

Yes. One approach is to use a high-level string type if (utmost)
efficiency is not an issue and use character arrays otherwise.


Regards,

August

 

[jacob navia]

Mark McIntyre a écrit :

This is a serius overstatement.

In cases where checking string length is done often, then doing it at
each usage is of course inefficient.

If on the other hand your programme /never/ needs to know the lengths
of strings, then being forced to use an object which includes the
overhead of stringsize is also inefficient.

Knowing the length is necessary for so many situations that in MOST
cases you will end up calling strlen explicitely or implicitely
(line in strcat)

In many cases you need to pass the string to another function.
In most cases you need to pass the length or the called function must
call strlen. To avoid an extra argument, most programmers will just
pass the string, forcing again a call to strlen. This is a horrible
waste with C string since in text handling programs, strings are passed
from function to function calling strlen for the same string over
and over.

String concatenation needs strlen implicitely.

Functions like strrchr can be coded MUCH more eficiently if the
length is known, since you start at the end of the string and stop
at the first match, instead of starting at the beginning, remembering
each match and returning the last...

To know if a string fits in a buffer you must know its length.

It is obvious that you can keep the length to avoid this
problems as heathfield says. But... if you need to keep the
length why not use a counted strings package anyway???

I recall working on some code that assiduously checked for
divide-by-zero conditions before performing any division, even for
divisors such as 1+e^x.

??? Maybe a typo? You mean 1e+0 probably.

> The check caused significant performance loss.

Maybe, anything can be exaggerated by did you find that code
crashing with division by zero?

It depends on the way it was done. Yes, with an actual constant
as divisor you know it can't be a division by zero but the check
was written maybe BEFORE the constant. When the variable was
replaced by a constant the check was kept, maybe because he
did not know if it was OK to replace a variable with that
constant...

Had we been using an object that included "for free" a div/0 check, we
would have been faced with a major rewrite.

Maybe, but it doesn't hurt so much to be careful in
high reliability code...

Elsewhere in the same code, there were numerous uses of strncpy
instead of strcpy. This gained nothing, not even performance, as the
source strings had been carefully loaded into a buffer of known width
and padded with blanks. The writer clearly thought it was a good idea
however, as they'd cleverly commented every single instance with a
warning not to change it.

It wazs a principle thing, and I do not find that bad. Why should be
strncpy less efficient than strcpy???

Yes, it may be 0.0001% less efficient but maybe he did not see
"efficiency" as a higher goal than SECURITY!!!

The lesson to take from this is that efficiency is not a
one-size-fits-all solution, and one should not assume .

Never said otherwise but really, you are showing us cases that
are more or less exceptional. The repeated use of strlen over and over
the same string is obvious MUCH MORE COMMON than the cases you mention.

[snip]

Really?
the second involves loading two values into a register and calling ADD
or somesuch. Zero function calls.

You misunderstand. I was saying the usage of normal C functions in
contrast to operator overloading the '+' operation.

If you have some new type of number (rationals say) and you
use

RationalAdd(Rat a,rat b);

or a+b

is the same. That was my point.

I've seen this done - I've seen novices who thought a clever way to be
overflow safe was to write functions to replace the operators, and
invariably their code ran like a dog.

Maybe.
1) lcc-win32 allows you to test for overflow, and the speed diffeerence
is almost zero when the compiler does it.
2) I am improving the operator overloading part, allowing inline and
assembly modules, so basically you will be able to do the overflow
test with almost no overhead.

 

[Randy Howard]

You misunderstand. I was saying the usage of normal C functions in
contrast to operator overloading the '+' operation.

If you have some new type of number (rationals say) and you
use

RationalAdd(Rat a,rat b);

or a+b

is the same. That was my point.

No wonder it was confusing. You made a claim in a C language newsgroup
about something (operator overloading) which doesn't even exist in the
C language. Worse, you didn't make it clear at all initially what you
were even referring to, or mark it as off-topic.

 

[jacob navia]

Randy Howard a écrit :

No wonder it was confusing. You made a claim in a C language newsgroup
about something (operator overloading) which doesn't even exist in the
C language. Worse, you didn't make it clear at all initially what you
were even referring to, or mark it as off-topic.

We were speaking of the possible performance penalties of this
extensions. Please read the whole tread before jumping to
conclusions.

 

[jacob navia]

Richard Heathfield a écrit :

jacob navia said:

I am just saying [trigraphs] are not needed any more. Why they are here?
Because a Danish manufacturer had problems with '{' and other
letters of the C alphabet. In the horse trading that goes behind
the publications of international standards they got into the
standard that trigraphs would be there to save them.

Then, time passes, the manufacturer has disappeared since a long
time, and we are stuck with a nonsense construct!!!!

So you claim. Nonetheless, trigraphs remain useful even now in, say,
mainframe environments. But if you don't like trigraphs, don't use them.

I AM FORCED to used them. If I want it or not, the
translation will be done by the compiler without any user
intervention!

 

[Richard Heathfield]

jacob navia said:

Richard Heathfield a écrit :


I AM FORCED to used them.

No, you're free to use some other language.

 

[Randy Howard]

Randy Howard a écrit :

We were speaking of the possible performance penalties of this
extensions. Please read the whole tread before jumping to
conclusions.

Pot, kettle, black. You jumped to the conclusion that everyone reading
this line:

would automatically recognize that you meant the "+" operator meant
something other than what it actually does. I wasn't the only person
to not follow you along in your assumptions.

 

[jacob navia]

Richard Heathfield a écrit :

jacob navia said:




No, you're free to use some other language.

Ahhh what an argumentation heathfield.

Incredible clever. I am sure you have pondered your answer
for hours.

 

[David T. Ashley]

The most glaring bugs in C are:

1) Zero terminated strings. This is the source of countless problems,
because each access to a string implies an unbounded search for
the terminating zero, and becasue size information is not stored
explicitely in the string but must be reconstructed, so that
buffer overflows when copying those strings are almost inevitable.

Not really a "bug". You can simply define your own data type and necessary
functions that operate on strings where the length information is
represented differently. People do this every day of the week.

'C' in general seems to be have been designed to avoid "hidden" operations
inserted by the compiler (which makes it fairly suitable for embedded work).
Aside from stack frames and the occasional unexpected library subroutine
call (for large integer math, for example), the 'C' statements are compiled
verbatim. There is very little going on behind the scenes.

The built-in data types in 'C' are low-maintenance and for the most part
directly supported by the machine's instruction set. Typically, nearly all
of the code is compiled inline without function calls unless you explicitly
call a function.

The paradigm is very direct and straightforward.

so that
buffer overflows when copying those strings are almost inevitable.

Firearms accidents and aircraft mishaps are also almost inevitable. Does
that mean that firearms and aircraft are bad? No, it means that inherently
dangerous and/or complex systems need more skilled operators.

Note that even a private pilot's license (the lowest rung on the ladder)
requires that you demonstrate to an FAA examiner that you can use reasonable
technique to take off and land an airplane. Individuals who can't do that
aren't allowed to operate an airplane. The licensing process explicitly
recognizes that aircraft are complicated.

On the other hand, anybody with $99.99 + local sales tax can bring the
wonders of 'C' to their Windows computer. With no training. And no
licensing. And then the accidents happen.

The frequent memory and pointer problems with 'C' aren't because of the
language. They are because idiots en masse are using a language that is not
designed to be idiot-proof.

2) Confusion between pointers and arrays. Arrays in C are completely
screwed up. There is endless confusion between pointers and
arrays specially because the size information is destroyed across
function calls.

I agree to that these concepts are horribly confusing (*).

(*) To those who don't understand the language.

3) From (1) and (2) we obtain as a consequence the inherent
impossibility to make bounds checks when accessing arrays and
strings. This leads to endless bugs.

There is an inherent conflict between (efficiency) and (silently carrying
around allocation information that isn't always needed). 'C' compiles well
because, among other reasons, the silent baggage is kept to a minimum.

Overall impression: your comments don't reflect design defects with 'C'.
Rather, they reflect a philosophical difference with the authors of the
language.

 

[Richard Heathfield]

jacob navia said:

Richard Heathfield a écrit :

Ahhh what an argumentation heathfield.

Incredible clever. I am sure you have pondered your answer
for hours.

A simple examination of timestamps demonstrates otherwise. There was no need
to ponder.

 

[jacob navia]

Richard Heathfield a écrit :

jacob navia said:



A simple examination of timestamps demonstrates otherwise. There was no need
to ponder.

It would have been better that you turn on your brain
(as Dan Pop said) before answering in automatic mode
heathfield.

What is the point of your message?

You think we are in a sect where the guru can exclude
people that present dissenting views?

Or you think that if I go on posting in this group^,
working in my compiler, maintaining it, answering
mails since years it is because I think this language
is doomed?

Or what?

Just a moment reflection would have indicated you that if I use
the language I am FORCED to use trigraphs, as I am forced to
write a parentheses after an "if" keyword.

I am ready to accept a simple rule like that, it is very
easy and logical. But that
SomeFn(345); //What is this ????/
will make my code fail 100 lines below with an incomprehensible
"syntax error" no, that is not logical AT ALL.

All this because some terminals do not support '{'????/

 

[Richard Heathfield]

jacob navia said:

It would have been better that you turn on your brain
(as Dan Pop said) before answering in automatic mode
heathfield.

It's rarely necessary when replying to you.

What is the point of your message?

To answer your point.

You think we are in a sect where the guru can exclude
people that present dissenting views?

This newsgroup isn't about gurus and dissenting views, but about the C
programming language.

Just a moment reflection would have indicated you that if I use
the language I am FORCED to use trigraphs, as I am forced to
write a parentheses after an "if" keyword.

You need to know about trigraphs. You're not forced to use them.

I am ready to accept a simple rule like that, it is very
easy and logical. But that
SomeFn(345); //What is this ????/
will make my code fail 100 lines below with an incomprehensible
"syntax error" no, that is not logical AT ALL.

Sure it is, to those who know the language.

All this because some terminals do not support '{'????/

The workaround is simple - don't type lots of question marks. It's poor
style anyway.

 

[Dik T. Winter]

>
> I am just saying they are not needed any more. Why they are here?
> Because a Danish manufacturer had problems with '{' and other
> letters of the C alphabet.

Manufacturer? Where did you get that idea? The Danish users had problems
with them (and also users from some other countries). And indeed, the
following would look quite funny:

»include <stdio.h>
int main(void) æ
int aÆ5Ä;
return 0;
ä

BTW, on a French terminal of that time, the above would look like:
£include <stdio.h>
int main(void) é
int aº5§;
return 0;
è

> Then, time passes, the manufacturer has disappeared since a long
> time, and we are stuck with a nonsense construct!!!!

Which manufacturer?

 

[CBFalconer]

. snip ...

Pot, kettle, black. You jumped to the conclusion that everyone
reading this line:


would automatically recognize that you meant the "+" operator
meant something other than what it actually does. I wasn't the
only person to not follow you along in your assumptions.

It is high time to PLONK this thread. Enjoy your war.