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

[Malcolm]

What's the typedef problem?
I don't like their syntax, but I think it's just a matter of taste...

Bool breaks libraries.

That, in a nutshell, is the typedef problem. The ability to define aliases
for basic types makes code unreadable, and forces all code to use a
particular convention, making it difficult to integrate functions from two
sources.

Typedefing structs is a bit different. Here you are creating a compund type.

 

[Richard Heathfield]

Malcolm said:

Typedefing structs is a bit different. Here you are creating a compund
type.

....which has nothing to do with the typedef. The typedef doesn't create a
compound type. It merely creates a synonym for an existing type.

 

[Richard Heathfield]

João Jerónimo said:

That would be solved if C had some more precise types...
Why?

Instead of relying on "at least x bits" types, C should have defined
types with 8 bits, types with 16 bits and types with 32 bits...
Why?

This was difficult in the time when C was designed, because of the
diversity of architectures at the time (I think there were
bit-addressable machines, right?)...
But now "byte" is a synonym of "octet", right?

Wrong. Numerous counter-examples exist.

 

[jacob navia]

Richard Heathfield a écrit :

jacob navia said:




C isn't perfect (for one thing, it's grown too big). But I specifically mean
that when ***YOU***, Jacob Navia, start talking about bugs in the language,
we know it really means that you're going to bang on about your
implementation's useless non-portable mods that *you* think of as
improvements to what *you* think of as bugs in C.

Of course when *YOU* speak you do not do it for yourself but in
the name of all people that use C, all reasonable people, etc.

I know that when *I* speak I speak for myself.

And your point was?


Your opinion about lcc-win32 is second hand anyway since you
never use it. Your discussion so far presents no arguments
but "C strings are a design decision". So what? I know that.

I am just saying that they were a BAD design decision.

The same as with the example I wrote about arrays.

The evaluation of the expression

array

in the example, evaluates to a pointer, not to an array even
if the object is an array.



When I write
fn(array);

this "array" identifier evaluates to a pointer.

When I write

struct tagFoo {
int array[2756];
};

struct tagFoo array;

And I write later in some function:

fn(array);

The structure is passed by value. Not so for arrays.

This is (of course) a design decision. It is just
a very bad idea. ALL size information about the
array is lost.

But I know that you will throw some words to deny this, as you
have done in your previous messages, but it will not help you. This are
just FACTS.

 

[jacob navia]

Richard Heathfield a écrit :

And any design decision can be called a bug. For example, the whole of
lcc-win32 can be called a bug. So what? The fact that you can abuse
null-terminated strings doesn't mean that null-terminated strings are a
language blemish. You can abuse anything if you try hard enough.

I am not even talking about abuse. I am talking about
1) Error prone unbounded memory scans.
2) Inefficient scanning AGAIN and AGAIN the whole string
to know the length.
3) Memory overflows when copying.

Say, you have a buffer of 80 chars and you want to copy
a string into it. You have to scan the whole string first
to see if it fits!

OR

At each character you have to test if it fits
or you have reached the terminating zero.

Inefficient.

2) Confusion between pointers and arrays.

What confusion? I don't get them confused, and neither does anyone who
has taken the trouble to learn the language.

Of course (see above). This is not a bug, it is a "conscious design
decision". Nevertheless, it is not immediately obvious to anyone outside
the C pros, why [...] prints:
sizeof array is: 4

The ignorance of
the newbie is not the best yardstick for whether language features are a
good idea or not.

Excuse me but not only newbies. Nobody cares to understand this
crazy "decay", and the other sophistications of when arrays are
arrays and when arrays are just pointers, so everybody
but the very few language experts says:

Arrays do not exist in C, only pointers, since arrays do not
survive function boundaries.

My example proves that it is impossible to pass array
size information to a function but you have to pass
it separatedly...

Not true. It's also true, for example, in C++.

This was inherited from C, and you know that. They realized already
that this "array decaying" wasn't very good and developed a whole
new set of arrays. They had to anyway.

No, it's all perfectly straightforward, and is explained very clearly in
K&R2. Anyone with the nous to read that is not going to struggle for long.

Yes yes. All is OK, very simple. Then tell me:

How do you pass the array size information to a function
that will operate in an array?

You must pass it separatedly isn't it?

Exactly. "It isn't always "conveyed" " as you say. I wasn't saying
anything else. That is the bug precisely. It is impossible
to pass that information to a function and use an array as
an object and not as a pointer!

The expression's value is passed. Before that value is passed, it has to be
calculated.

GREAT!

I did n,ot knew that. Really new stuff here

In your example, the value of the expression consisting solely
of the name of the poorly-named 'array' array is the address of the first
element of the array, and that element's address is passed by value, its
type being pointer-to-int.

Well this is precisely the bug. Why when I define

struct tagArray { int array[2765];};

struct tagArray array;

Now, when I write

fn(array);

no "decaying" happens. Ahh, great. At least *some* things work!

Right.

Yes, another one of this FEATURES...

I would claim no such thing. I would, however, claim that tracking such
things down is not nearly as difficult as you imagine.

Ahh, and all those packages like "Purify" and all those malloc/free
debuggers are sold by the thousands because.... well, because people
are lazy and stupid and do not follow your propositions obviously.

You have not demonstrated your case. You have, however, provided some
evidence for eschewing multi-threading, which is non-standard in any case
and, as you say, enormously increases the complexity of an application for
no real benefit.

Obvious. Multi-threading is not good for malloc/free then... instead of
getting rid of multi-threading let's get rid of malloc/free!

More and more applications are designed with multi-threading in mind.
Even the hardware is now multi-threaded with several "cores".

But let's keep living in the past...

 

[Richard Heathfield]

jacob navia said:

Of course when *YOU* speak you do not do it for yourself but in
the name of all people that use C, all reasonable people, etc.

No, I speak for myself, just as you do.

I know that when *I* speak I speak for myself.

And your point was?

Just beyond your grasp, it appears.

Your opinion about lcc-win32 is second hand anyway since you
never use it.

Yes. My opinion about lcc-win32 has been formed almost entirely from your
articles, so perhaps it would be wiser for you to avoid any temptation to
go into marketing.

Your discussion so far presents no arguments
but "C strings are a design decision". So what? I know that.

Then they can hardly constitute a bug. You might not like them; you might
think they're a bad idea; you might even think they constitute a blemish in
the language design - but to call them a "bug" is to misuse the term.

I am just saying that they were a BAD design decision.

Fine, you're entitled to that opinion. I would even go so far as to say that
I don't entirely disagree with it.

The same as with the example I wrote about arrays.

The evaluation of the expression

array

in the example, evaluates to a pointer, not to an array even
if the object is an array.
Correct.

When I write
fn(array);

this "array" identifier evaluates to a pointer.

The expression has pointer type, yes.

When I write

struct tagFoo {
int array[2756];
};

struct tagFoo array;

And I write later in some function:

fn(array);

The structure is passed by value.
Correct.

Not so for arrays.

The array isn't passed *at all*, so how can it be passed by value?

This is (of course) a design decision. It is just
a very bad idea. ALL size information about the
array is lost.

No, it's not. The size information is retained. It is simply that the
information is not *conveyed* to a called function (unless you convey that
information yourself via, say, another argument to the function, and write
the function in such a way that it can receive this information). And why
should it? You're not, after all, passing an array. You're passing a
pointer.

But I know that you will throw some words to deny this, as you
have done in your previous messages, but it will not help you. This are
just FACTS.

So you claim.

 

[FreeRTOS.org]

I started programming with c. Lot of projects are being done in C++. We
have to move in THE C++.
I read around 3 - 4 books (including Faqs, stroustrup) on c++. What i
found in most of the book is that they criticize c language and c
programmer. And they silently run away from good feature of C.
They have sentence like , "you have to unlearn c to learn C++".

is it the end of C era ?
Stroustrup and writers of Faqs are gurus of technologies. These people
are commenting on C language.
should we believe them?
somewhere it is demoralizing for c programmer.

I just wanted to know what other people thinks on this .

Like most things - choose the best tool for the job and be pragmatic.
Sometimes assembler, sometimes C, sometimes C++ (sometimes ADA, etc.). Each
has their place.

Working in the embedded field I have completed many *object based* projects
in C for which I would never consider using C++. I have also completed
projects in C++ I would not consider to be appropriate to tackle in C
considering C++ was available as an option.

I have encountered C++ Nazis who know ever last detail of the C++ spec and
consider you antiquated/foolish if you use C. I like watching them fall
flat on their arses when they try and write an embedded project and their
code does not even compile ;-) Naturally it is "the compilers fault"
because it does not correctly implement the standard - like anybody thought
it would.

Regards,
Richard.

+ http://www.FreeRTOS.org
+ http://www.SafeRTOS.com
for Cortex-M3, ARM7, ARM9, HCS12, H8S, MSP430
Microblaze, Coldfire, AVR, x86, 8051, PIC24 & dsPIC

 

[Richard Heathfield]

jacob navia said:

Richard Heathfield a écrit :

I am not even talking about abuse. I am talking about
1) Error prone unbounded memory scans.

If you don't bound the scan, that's your problem, not C's problem. C
explicitly says that you're not supposed to do that. If you do it anyway,
the behaviour is undefined. So - Don't Do That.

2) Inefficient scanning AGAIN and AGAIN the whole string
to know the length.

If you need to know the length often enough, store it. If you don't, why
bother?

3) Memory overflows when copying.

If you don't provide sufficient storage for the target of a copy, that's
your problem, not C's problem. C explicitly says that you're not supposed
to do that. If you do it anyway, the behaviour is undefined. So - Don't Do
That.

Say, you have a buffer of 80 chars and you want to copy
a string into it. You have to scan the whole string first
to see if it fits!

When you built the string in the first place, you knew its length (if you
did it properly). Don't forget.

OR

At each character you have to test if it fits
or you have reached the terminating zero.

Inefficient.

If this is truly the program's bottleneck, which it almost certainly isn't,
then consider caching the length and using memcpy, or simply use a
third-party string library if you prefer. C's flexibility allows you to do
this, which is a Good Thing, yes?

2) Confusion between pointers and arrays.

What confusion? I don't get them confused, and neither does anyone who
has taken the trouble to learn the language.

Of course (see above). This is not a bug, it is a "conscious design
decision". Nevertheless, it is not immediately obvious to anyone outside
the C pros, why [...] prints:
sizeof array is: 4

The ignorance of
the newbie is not the best yardstick for whether language features are a
good idea or not.

Excuse me but not only newbies.

Okay, I will accept that we should also include amongst the ignorant those
who are unwilling to learn the language properly before using it.

Nobody cares to understand this
crazy "decay",

Here are two dozen counterexamples: I understand it. Chris Torek understands
it. Dik Winter understands it. Dan Pop understands it. Kaz Kylheku
understands it. Dennis Ritchie understands it. Brian Kernighan understands
it. Ken Thompson understands it. P J Plauger understands it. Stefan Wilms
understands it. Lawrence Kirby understands it. Keith Thompson understands
it. Dann Corbit understands it. Ben Pfaff understands it. Peter Seebach
understands it. Doug Gwyn understands it. Eric Sosman understands it. Dave
Thompson understands it. Chuck Falconer understands it. Steve Summit
understands it. Richard Bos understands it. Mark McIntyre understands it.
Christian Bau understands it. Clive Feather understands it.

And I have listed only a tiny fraction of those people who understand the
"decay" under discussion. So "nobody" is a bit of an exaggeration, isn't
it?

and the other sophistications of when arrays are
arrays and when arrays are just pointers, so everybody
but the very few language experts says:

Arrays are always arrays. Pointers are always pointers. The name of an
array, however, is converted into a pointer to the array's first element
when used in an expression that is not the operand of sizeof or the &
operator.

Arrays do not exist in C, only pointers, since arrays do not
survive function boundaries.

Arrays survive function boundaries just fine.

#include <stdio.h>

int main(void)
{
char s[] = "Now is the time to party.";
puts(s); /* function boundary */
printf("%lu\n", (unsigned long)sizeof s); /* prints 26 - the
array has survived! */
return 0;
}

My example proves that it is impossible to pass array
size information to a function but you have to pass
it separatedly...

Passing it separately still counts as passing it, so how is it impossible to
pass array size information to a function?

This was inherited from C, and you know that.

Had you known that, you would not have made your incorrect claim - or do you
deliberately make incorrect claims?

Yes yes. All is OK, very simple.

Good, so what's your problem?

Then tell me:

How do you pass the array size information to a function
that will operate in an array?

See fgets for an example.

You must pass it separatedly isn't it?

Yes; you can't pass it *with* the array because you can't pass the array,
because C is pass-by-value and evaluating an array yields a pointer.

Exactly. "It isn't always "conveyed" " as you say. I wasn't saying
anything else.

Yes, you were. You said the size information is destroyed. You were wrong.
It is not destroyed at all.

That is the bug precisely.

No, it's not a bug. This was a conscious design choice by dmr. You might
think it was a poor choice. You might even think it is a blemish on the
language. But to call it a bug is to misuse the term.

It is impossible
to pass that information to a function and use an array as
an object and not as a pointer!

Yes, well done - you can't pass an array to a function. Do you understand
that now? (Well, actually you can, but only as a subobject within an
aggregate type such as a struct or union.)

GREAT!

I did n,ot knew that. Really new stuff here

It figures. It might be a good idea for you to learn the language before you
start making sweeping criticisms of it.

Well this is precisely the bug.

No, it's not a bug. It's a deliberate design decision that you don't like.

Why when I define

struct tagArray { int array[2765];};

struct tagArray array;

Now, when I write

fn(array);

no "decaying" happens.

Correct. Whether that's a good thing or a bad thing is a matter for debate,
but you are at least correct for a change.

Ahh, great. At least *some* things work!

The whole language works.

Yes, another one of this FEATURES...

Yes. And for the record, trigraphs make perfect sense in some environments.
If you don't like them, don't use them.

Ahh, and all those packages like "Purify" and all those malloc/free
debuggers are sold by the thousands because.... well, because people
are lazy and stupid and do not follow your propositions obviously.

That's one way to track down such bugs, albeit a rather expensive way to
deal with a fairly simple problem. I do not accept that those who use
Purify are lazy or stupid, although I do not use it myself.

Obvious. Multi-threading is not good for malloc/free then...

You have not demonstrated that.

instead of
getting rid of multi-threading let's get rid of malloc/free!

You have not demonstrated that this is a wise idea.

More and more applications are designed with multi-threading in mind.

That doesn't mean multi-threading is necessarily a wise idea. Indeed, in
most cases where I've encountered it, it was a very silly idea. (That does
not mean that multi-threading is a silly idea. It only means precisely what
it says.)

Even the hardware is now multi-threaded with several "cores".

But let's keep living in the past...

I'd rather live with the facts. So far, you haven't presented any that would
convince me that you know what you're talking about.

 

[Charlton Wilbur]

jn> Your opinion about lcc-win32 is second hand anyway since you
jn> never use it. Your discussion so far presents no arguments but
jn> "C strings are a design decision". So what? I know that.

jn> I am just saying that they were a BAD design decision.

You know, when Bjarne Stroustrup decided he didn't like some of the
limitations of C, he designed C++.

When Brad Cox didn't like some of the limitations of C, he designed
Objective-C.

The problem here is not that you see design flaws in C. The problem
is that you believe, in contravention of all evidence, that you can
singlehandedly redesign C *and still call it C*.

C is the language defined by K&R, K&R2, and the C89/90 and C99 standards.

If you want a language remarkably like C, but with length-counted
strings and garbage collection, hey, more power to you! It's likely
to be a fine language, and possibly more useful, more efficient, and
more resilient than C. But unless it conforms to the C standards, it
isn't C.

So why not design the language you really want, and call it something
else?

Charlton

 

[Randy Howard]

Richard Heathfield a écrit :

Customer: HEY! Your dammed program erased all my data files!
Programmer: Of course. You forgot to read the documentation page 2643
paragraph 76: If the cutomer doesn't check the dialog button
"Do not erase all my data files" in the menu item 8,submenu
26, the program will erase them.

IT IS NOT A BUG! IT IS A FEATURE!

Any bug can be converted to a "design decision", since a design that
is at the root of COUNTLESS buffer overruns, virus attacks, etc, is
obviously correct.

Strawman. These are not equivalent at all. C gives you something
analogous to a Machete. Apparently, you would prefer a machete that is
never sharpened, only available with a special license, and has a hard
clear plastic cover such that it can't cut anything without melting it
off first with a blowtorch.

Some things, in order to serve their design purpose, are inherently
dangerous. That means, the people that use them must be intelligent,
competent in their employment, and not careless if they intend to
survive the usage unharmed. Same is true of cars, airplanes,
chainsaws, even toothpicks.

If you want a super-handholding, ultra-safe language, they are out
there. C is not for amateurs, or those not willing or able to spend
the time to learn where the sharp spots are.

What confusion? I don't get them confused, and neither does anyone who has
taken the trouble to learn the language.

Of course (see above). This is not a bug, it is a "conscious design
decision". Nevertheless, it is not immediately obvious to anyone outside
the C pros, why

#include <stdio.h>
int array[2765];

void fn(int array[2765])
{
printf("sizeof array is: %d\n",sizeof(array));
}

int main(void)
{
fn(array);
}

This prints:
sizeof array is: 4

Ahhh. OF COURSE. Arrays "decay". This is a C only concept.
And this needs surely a lot of convoluted explanations
as the countless C-FAQ prove.

If you want to fly an airplane, you must first learn how to fly, lest
you crash and die. If you want to program in C, you must first learn
the language, for basically the same reason.

Of course. Only "conscious design decisions", like trigraphs...

They served a purpose at the time they were designed in. If you're too
young to understand why, that's not a reason to pretend they were never
needed.

Of course.

C programmers never have bugs, since, if someone has a bug, it is not
"knowing what he is doing", hence he is not a C programmer.

No. It's far more simpler. If you have a bug in a program that is due
to faulty logic, algorithms, or even a typo, that's a bug, and C can
have them quite often. You can be a very competent programmer and very
knowledgeable of C and still make mistakes. Perfection is not often
attained.

OTOH, if you have a bug due to you as a programmer directly violating
the rules of the language itself, that is not the fault of the
language. That is not knowing what you're doing.

Obviously
only Mr Heathfield qualifies as a C programmer then (maybe with the
company of Mr Dan Pop, that also told me that he never had a bug...)

Did you actually believe Dan? rofl

Who told you that C strings aren't supported? They are supported OF
COURSE.

What I do is to give programmers the choice PRECISELY. The can now
choose between C strings or the String library. In YOUR world there is
NO OTHER CHOICE but C strings!!!

You give navia-C programmers a choice. You do not give standard C
programmers a choice. IIRC, the bstring library (name??) written by
Hsieh gives much the same (if not better) functionality, but without
requiring the compiler to do nonstandard things to get there. A /far/
better approach imo.

Because humans are not machines, and the human circuit (i.e. the brain)
is not a computer, but a vastly more complicated circuit than any
computer in existence.

Such a circuit is able to build circuits (something computers
aren't able to do) and is able to program computers (also
something computers aren't able to do) but it is ERROR PRONE, i.e.
due to the way the brain ciruitry works, it is not able to reproduce
a lot of mechanical acts without sometimes FAILING.

If I tell you to add thousands of digits thousands of times
you WILL make a mistake, even if you are an expert.

That same "brain circuitry" makes mistakes in super-safe,
super-handholding, super-slow languages too. In fact, waiting on
programs written in them to simply complete has been known to cause
programmers to fall asleep too often. 9 out of 10 doctors agree.

If I ask you to keep track of thousands and thousands of memory areas
and never make a mistake when releasing the allocated memory you
WILL make a mistake even if you claim here that it will never
happen to you.

The question is, is the performance and/or memory footprint advantages
of the C approach worth a little bit of extra debugging to achieve a
satisfactory result, or would you rather do it some other way, and take
the tradeoffs implied? That's why there are other languages to choose
from. It's also why you can buy a hybrid car with 15 different airbags
and roll bars, or you can buy a Ferrari F1 car. They achieve different
things, and require a dramatically different amount of skill to use
them effectively.

The problemof malloc/free is that it is not scalable. You can get away
with it in small systems, and in single threaded applications.

In a multi-threaded complex application, where there are thousands or
millions of allocated pieces of memory it is another, completely
different story...

I've been writing multi-threaded programs (not in standard C of course,
since it doesn't have them) in both large and small-scale applications
for many years. malloc/free work fine. Did you have a point
applicable to standard C?

How do you know when you are done?
That is precisely the question. You have to know exactly when each piece
of memory is needed, and when not. Since it is SO EASY to make an alias
in C, how do you know that in all that complex code there isn't an
alias for this piece of memory???

You first must be knowledgeable of the language, knowledgeable of the
code, have a good design, follow good practices, good documentation,
and have some form of suitable verification, code review and test
procedures. hint: I wouldn't expect someone with very little real
world application development experience to get this right. It is
hard. Just about anything worth doing is difficult.

Easier would be:
"When you want memory, you ask for it, and if possible you'll get it.
The system will detect when you are done with it and
release it."

That IS easier...

If you want an /easy/ language, you are in the wrong place. Not
everything /easy/ is /correct/ for the job at hand. There are places
where other languages have merit, and there are places where C has
merit, and it is not important that any one language be good at them
all.

I can't answer it for you since you claim never to do a mistake...
For all other people however, the reasoning is obvious.

Actually, the "reasoning" seems to be "If I have trouble with it, then
everyone must have trouble with it. Anyone that doesn't have trouble
with it ticks me off."

Nobody takes memory management from you. Just the finding of unused
memory is taken from you. It is still the programmer that allocates
memory. This is like saying that an automatic car doesn't let the driver
drive the car...

Nonsense

Actually, if you've driven both manual and automatic transmissions
(well), then you wouldn't choose that analogy at all, as it does not
help your argument.

Nothing is wrong Heathfield. For programmers like you that never
make mistakes nothing is wrong. I am speaking for the other ones
like me that DO make mistakes.

I know of no language that will protect a mistake-prone programmer from
themselves. NONE. With or without garbage collection assistance, or
pointers removed, or arrays conveying extra information across function
calls, you will still make mistakes. Just different ones. What you
will not get though, is better performance and/or a smaller footprint
in all but the most trivial of examples. It's an implementation
decision. I haven't seen anyone say that you should use C for all
problems, and more importantly, for programmers of all skillsets.

There isn't a blinder man than the one that doesn't want to see.

Ironically, I couldn't agree more.

 

[Randy Howard]

Richard Heathfield a écrit :

I am not even talking about abuse. I am talking about
1) Error prone unbounded memory scans.

If you as a programmer don't make sure your strings are properly
formed, you will have problems. If your algorithm is not properly
formed, you will also have problems. Why is this confusing?

2) Inefficient scanning AGAIN and AGAIN the whole string
to know the length.

That's a design flaw. If you have a program where that time is an
issue, design your code to mitigate the problem. This is not
difficult.

3) Memory overflows when copying.

Only when not copying properly. Are there artifacts in the standard
library that make this a dangerous path for the uninitiated?
Absolutely. Are they impossible to avoid? Not at all.

Say, you have a buffer of 80 chars and you want to copy
a string into it. You have to scan the whole string first
to see if it fits!

No, you do not /have/ to do that. You /may/ need to do that if you
didn't write code to solve the problem before you go there.

OR

At each character you have to test if it fits
or you have reached the terminating zero.

Inefficient.

Yes, the methods you propose to use are inefficient. Why is that not
surprising me?

2) Confusion between pointers and arrays.

What confusion? I don't get them confused, and neither does anyone who
has taken the trouble to learn the language.

Of course (see above). This is not a bug, it is a "conscious design
decision". Nevertheless, it is not immediately obvious to anyone outside
the C pros, why [...] prints:
sizeof array is: 4

The ignorance of
the newbie is not the best yardstick for whether language features are a
good idea or not.

Excuse me but not only newbies. Nobody cares to understand this
crazy "decay", and the other sophistications of when arrays are
arrays and when arrays are just pointers, so everybody
but the very few language experts says:

Arrays do not exist in C, only pointers, since arrays do not
survive function boundaries.

My example proves that it is impossible to pass array
size information to a function but you have to pass
it separatedly...

You are confused. If you can pass it to the function, /in any way/
then it is not impossible to pass it. You contradict yourself. I know
what you meant though. You can't pass it the way you want to pass it.
Tough. Get used to it, or find a language that works the way you like.
Just don't call that other language "C", or try to convince people
comfortable with C that your way is the only way and you won't have
anything to argue about.

Exactly. "It isn't always "conveyed" " as you say. I wasn't saying
anything else. That is the bug precisely. It is impossible
to pass that information to a function and use an array as
an object and not as a pointer!

You use the word "impossible" far too often, and far too improperly.

If it were impossible to handle arrays in C, the language would have
died before you were born. Clearly the problem has known solutions.

Ahh, and all those packages like "Purify" and all those malloc/free
debuggers are sold by the thousands because.... well, because people
are lazy and stupid and do not follow your propositions obviously.

It's crazy just how close to right you landed on that one. Even a
stopped clock is right twice a day....

Here I have to disagree with Richard. It does offer real benefits in
some problem domains. That they may not be encountered often in
Richard's travels I won't dispute. But, such cases do exist. There
are ways other than threads to solve those problems also, but typically
they are even more difficult. Multithreaded programming is not /easy/,
therefore it is not surprising that Navia doesn't like it. He has
repeatedly come down on the side of "easy" over "efficient".

Obvious. Multi-threading is not good for malloc/free then...

False. It works fine when correctly done.

instead of getting rid of multi-threading let's get rid of malloc/free!

There is no multi-threading to get rid of in the terms of this
discussion, since it is about C. The real C, not the pseudo-C you are
so fond of.

More and more applications are designed with multi-threading in mind.

That is in fact the problem. "Designed with X in mind" is a sure
warning sign that X isn't correctly done at all. Luckily, more and
more applications are designed and built with working thread solutions.
"Designed with X in mind" typically means: "I heard about this thing X
and my sadly, my boss has too. He is worried about it impacting the
size of his empire. I spent 20 minutes googling for X, and wrote in
the Executive Summary of my design document that the design has X in
mind, so now everybody is happy, and I'll be long gone before anyone
figures out the difference."

 

[Richard Heathfield]

Randy Howard said:

Here I have to disagree with Richard. It does offer real benefits in
some problem domains.

Sure, but they're fewer and further between than most people imagine. At
least, I almost invariably find that people who ask me for help with
multithreaded programs have misunderstood what multithreading is *for*.
They seem to think their programs will run quicker *per se* if they're
multithreaded, as if their computer, on encountering the multi-threaded
program, suddenly grows an extra CPU or something.

Multithreaded programming is not /easy/,

Right. As you are undoubtedly aware already, multithreading is for those who
can't figure out state machines - and state machines are for those who
can't figure out multithreading.

<snip>

 

[CBFalconer]

jacob navia said: .... snip ...

Okay, I will accept that we should also include amongst the
ignorant those who are unwilling to learn the language properly
before using it.


Here are two dozen counterexamples: I understand it. Chris Torek
understands it. Dik Winter understands it. Dan Pop understands it.
Kaz Kylheku understands it. Dennis Ritchie understands it. Brian
Kernighan understands it. Ken Thompson understands it. P J Plauger
understands it. Stefan Wilms understands it. Lawrence Kirby
understands it. Keith Thompson understands it. Dann Corbit
understands it. Ben Pfaff understands it. Peter Seebach
understands it. Doug Gwyn understands it. Eric Sosman understands
it. Dave Thompson understands it. Chuck Falconer understands it.
Steve Summit understands it. Richard Bos understands it. Mark
McIntyre understands it. Christian Bau understands it. Clive
Feather understands it.

Possibly better expressed as an linked list

.... snip ...


Passing it separately still counts as passing it, so how is it
impossible to pass array size information to a function?

Which is just what strlcpy/cat do. They also provide a post-call
means of detecting that the passed size was insufficient, and of
deciding what that size needs to be.

char a[size];
size_t lgh;
...
if ((lgh = strlcpy(array, whatever, sizeof a)) >= sizeof a){
/* it got truncated */;
else /* everything fit */;

and the necessity of passing the available size tends to encourage
the programmer to supply that value, on pain of rejection at
compile time.

.... large snip ...

 

[Randy Howard]

Randy Howard said:


Sure, but they're fewer and further between than most people imagine.

Absolutely. But when you do have a problem suitable for
multi-threading, they can and often do the job very well.

At least, I almost invariably find that people who ask me for help with
multithreaded programs have misunderstood what multithreading is *for*.

No doubt. Companies with names like "Intel" spew so much BS about
threading, it's hard to imagine that not being a problem.

They seem to think their programs will run quicker *per se* if they're
multithreaded, as if their computer, on encountering the multi-threaded
program, suddenly grows an extra CPU or something.

The other misconception, which it /sounds/ like may apply to you given
the above, although I rather doubt it, is that threading can only help
in situations where you are CPU-bound. It is also quite helpful in
some i/o bound situations (i.e. server land), but not in the way most
people think. There are several large 'buckets' of problems which can
benefit from threading, and the contents of one bucket don't resemble
the contents of the next bucket much at all.

Right. As you are undoubtedly aware already, multithreading is for those who
can't figure out state machines - and state machines are for those who
can't figure out multithreading.

I'm not sure I agree with that in the literal sense, but I get the
humor in it nevertheless.

 

[Keith Thompson]

Yes, but it makes the use of compound types much simples, exactly
because of the alias...

I hardly think that being able to refer to a type as "foo" rather than
"struct foo" makes compound types much simpler. And typedefs make
defining recursive types (structures with pointers to themselves)
*more* complicated.

 

[Richard Heathfield]

Keith Thompson said:

I hardly think that being able to refer to a type as "foo" rather than
"struct foo" makes compound types much simpler.
Agreed.

And typedefs make
defining recursive types (structures with pointers to themselves)
*more* complicated.

Not agreed. The process is no more complicated than without typedef. The
important thing to remember is that the type synonym isn't usable until the
type exists. The fact that you can "embed" the type definition within the
typedef is a mere distraction, and in any case is not compulsory. Nowadays,
I do this as follows:

struct node_
{
void *data;
struct node_ *left;
struct node_ *right;
};

typedef struct node_ node;

to separate out the two steps, making the whole process clearer. (Yes, I
know I could use the same name for the struct tag and the typedef, but I
choose not to do so, because I think it's a possible source of confusion
for the maintenance programmer.)

 

[Mark McIntyre]

Randy Howard said:

(randy wrote, commenting on Richard's assertion that multithreading is
of little benefit)

Here I have to disagree with Richard. It does offer real benefits in
some problem domains.

....
[people] seem to think their programs will run quicker *per se* if they're
multithreaded,

Consider that most modern computer systems have multiple processors -
graphics controllers, dedicated HDD controllers, dedicated network
controllers etc.

as if their computer, on encountering the multi-threaded
program, suddenly grows an extra CPU or something.

Many systems also have multi-cpu cores. Single threaded apps cannot
take full advantage of that, no matter how clever the compiler or OS
are.
--
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]

Mark McIntyre said:

On Wed, 27 Dec 2006 21:58:36 +0000, in comp.lang.c , Richard

[people] seem to think their programs will run quicker *per se* if they're
multithreaded,

Consider that most modern computer systems have multiple processors -
graphics controllers, dedicated HDD controllers, dedicated network
controllers etc.

Nevertheless, simply making your program multi-threaded will not mean that
it is guaranteed to run faster.

Many systems also have multi-cpu cores. Single threaded apps cannot
take full advantage of that, no matter how clever the compiler or OS
are.

A user of a single-threaded program can nevertheless take at least *some*
advantage, because he can run that program on one CPU and some other
program on another.

But my main point is that multithreading is not a magic wand you can wave at
any problem. It can certainly be used effectively, but it can also be used
ineffectually, and can even be counter-productive.

 

[Dik T. Winter]

> Richard Heathfield a écrit :
>
> Of course.

Perhaps. But the conclusion that it is impossible to do bound checking
is false. If a compiler decides to use fat pointers, bound checking *is*
possible.

 

[August Karlstrom]

(e-mail address removed) skrev:

A good friend of mine had a BASH script he used which would run on average over 20 minutes.

As a programming practice in C (to freshen my skills) - remade the program

And it completed on average over 2 seconds....

From 20 minutes to 2 seconds... C's efficiency combined with the power left to the programmer

And what features specific to C enabled you to make the program that
much more efficient?


August