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 .
Dec 26 '06
167  5427 
jacob navia said:
Randy Howard a écrit :
>On Wed, 27 Dec 2006 00:17:46 -0600, jacob navia wrote
(in article <45**********************@news.orange.fr>):
>>>Richard Heathfield a écrit :
>1) Zero terminated strings.
That's not a bug. It's a design decision. You might not agree that it's
a good decision, but it's a conscious, deliberate decision nonetheless.
No bugs so far.
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.
To answer you in terms of your own analogy:
C gives you a machette without a HANDLE.
Your handle came off? Poor you.
You can't use it without cutting yourself the hand.
Yes, he can. So can I. You're the one that's lost the handle.
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...
A machete with a blunt long edge is only 50% effective. It's *supposed* to
be sharp on both the long edges. And it's a lousy analogy anyway.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
On Wed, 27 Dec 2006 23:19:06 +0000, in comp.lang.c , Richard
Heathfield <rj*@see.sig.invalidwrote:
>Mark McIntyre said:
>On Wed, 27 Dec 2006 21:58:36 +0000, in comp.lang.c , Richard
Heathfield <rj*@see.sig.invalidwrote:
<snip>
>>>[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.
Although in many cases it may, simply because the OS can be cleverer
with the runtime process.
Such cases are of course likely to be the trivial ones but not always.
For example a multithreaded DB process may run considerably faster,
provided the threads don't need to access the same tables
simultaneously. This is a real-world example I worked on recently (in
Java I admit) which gained us several _hours_ off an overnight job.
>But my main point is that multithreading is not a magic wand
Absolutely.
>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.
Double-absolutely!
--
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
On Thu, 28 Dec 2006 10:18:33 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
(of trigraphs, one of JN's favorite bugbears)
>
I am just saying they are not needed any more.
Okay, so persuade the ISO committee, either directly or via your
national standards agency. Posting over in comp.std.c might prove
productive.
>Ahh bugs are BAD BAD.
Great discovery. We are discussing how to avoid them if possible.
One of the ways to avoid them is to make things automatic
Er, no. Remember the stock market crashes of the eighties?
The way to avoid bugs is to write bug-free code. :-)
>Why C is better than assembly?
Its not. Its merely different. Arguments based on language X being
"better" than language Y are the same as arguments that racial type Q
is better than racial type R, ie bullshit. Different languages serve
different purposes.
--
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
On Thu, 28 Dec 2006 11:08:48 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Randy Howard a écrit :
>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.
To answer you in terms of your own analogy:
C gives you a machette without a HANDLE.
No, C gives you a machete with a sharp blade. Its got a handle, and
plenty of us manage perfectly well to use it without cutting
ourselves.
>You can't use it without cutting yourself the hand.
if someone is incompetent, undertrained or lazy, sure. The same
argument can be applied to cars, toasters and pencil sharpeners by the
way.
--
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
Mark McIntyre a écrit :
On Thu, 28 Dec 2006 11:08:48 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>Randy Howard a écrit :
>>>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.
To answer you in terms of your own analogy:
C gives you a machette without a HANDLE.
No, C gives you a machete with a sharp blade. Its got a handle, and
plenty of us manage perfectly well to use it without cutting
ourselves.
>>You can't use it without cutting yourself the hand.
if someone is incompetent, undertrained or lazy, sure. The same
argument can be applied to cars, toasters and pencil sharpeners by the
way.
Yes sure. Anything that improves security and allows for
less error prone interfaces is doomed to fail in this atmosphere
of "macho" programming.
It is pointless to discuss this. You never make mistakes
and those that do are "incompetent, undertrained, and lazy".
jacob navia said:
Mark McIntyre a écrit :
>On Thu, 28 Dec 2006 11:08:48 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
<snip>
>>
>>>You can't use [C] without cutting yourself the hand.
if someone is incompetent, undertrained or lazy, sure. The same
argument can be applied to cars, toasters and pencil sharpeners by the
way.
Yes sure. Anything that improves security and allows for
less error prone interfaces is doomed to fail in this atmosphere
of "macho" programming.
Not at all. The point you are missing is that there is more to programming
than "making it as easy as possible". Programming languages have various
characteristics, of which "ease of use" is only one. Others include
performance, portability, flexibility, expressive power, and simplicity (a
non-exhaustive list).
All of these characteristics are desirable, and programming languages
possess them in varying degrees. Sometimes, you can't increase one without
decreasing one or more of the others.
Programming language designers make choices which (whether they realise it
or not) enhance their language's "score" (to put it crudely) on some of
these characteristics but diminish it in others. Would that it were
possible to crank all of them up to the max! But it isn't.
And so we make trade-offs.
You appear to wish to promote one particular characteristic - ease of use -
without regard to the effect that such promotion will have on various other
characteristics. That's your choice, if you're implementing your own
language (or indeed if you are implementing extensions to C), but please
don't make the mistake of thinking that your choices should be binding on
everyone else just because *you* think they're good choices.
It is pointless to discuss this. You never make mistakes
and those that do are "incompetent, undertrained, and lazy".
It may indeed be pointless to discuss this with you, at least, because you
seem to be very ready to jump to conclusions that have little or no basis
in fact. Nobody in this discussion has claimed that they never make
mistakes, or that those who do are incompetent, undertrained, and lazy.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Richard Heathfield a écrit :
jacob navia said:
>>Mark McIntyre a écrit :
>>>On Thu, 28 Dec 2006 11:08:48 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
<snip>
>>>>You can't use [C] without cutting yourself the hand.
if someone is incompetent, undertrained or lazy, sure. The same
argument can be applied to cars, toasters and pencil sharpeners by the
way.
Yes sure. Anything that improves security and allows for
less error prone interfaces is doomed to fail in this atmosphere
of "macho" programming.
Not at all. The point you are missing is that there is more to programming
than "making it as easy as possible". Programming languages have various
characteristics, of which "ease of use" is only one. Others include
performance, portability, flexibility, expressive power, and simplicity (a
non-exhaustive list).
I am speaking not about "making it as easy as possible" (do not know
where you got that) but about "less error prone interfaces"!
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. 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.
Of course this efficiency is maybe not desired. Is that what
you mean?
:-)
But anyway:
I have nothing against making it as easy AS POSSIBLE... Read well the
"AS POSSIBLE" part.
Simplifying, making interfaces less complex makes them less
error prone, and is surely a step in the right direction.
[snip]
You appear to wish to promote one particular characteristic - ease of use -
without regard to the effect that such promotion will have on various other
characteristics.
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.
The performance implications of calling
MyAdd(Number *a, Number *b);
or doing
a+b;
are ZERO.
In both cases there is a function call.
That's your choice, if you're implementing your own
language (or indeed if you are implementing extensions to C), but please
don't make the mistake of thinking that your choices should be binding on
everyone else just because *you* think they're good choices.
I haven't made any decision for others since if you do not want those
extensions C strings and old fashioned arrays are still there.
You only pay for what you *actually use*.
jacob navia said:
Richard Heathfield a écrit :
<snip>
>>
[...] The point you are missing is that there is more to
programming than "making it as easy as possible". Programming languages
have various characteristics, of which "ease of use" is only one. Others
include performance, portability, flexibility, expressive power, and
simplicity (a non-exhaustive list).
I am speaking not about "making it as easy as possible" (do not know
where you got that) but about "less error prone interfaces"!
I accept the correction (for I am not trying to misrepresent your view,
after all). To aim for less error-prone interfaces is a worthy goal, but
there are lots of worthy goals of which that is only one, and it is
unfortunately true that we cannot always get closer towards one goal
without moving further away from others.
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.
That's certainly an opinion, but I value freedom of choice. If you want to
offer people an extension which takes care of these "mind-numbing
requirements", that's entirely up to you, but let's not forget that it
comes at a cost - lock-in to a particular implementation - and not
everybody wants to pay that cost. It may also have other, less obvious
costs, such as performance degradation.
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.
That's certainly an opinion, and it's not necessarily a bad one. It forms
the basis of typical third-party string libraries (including my own). But
to *force* people to use it is a step backwards. Your trade-off preferences
do not necessarily match everyone else's trade-off preferences.
This is by the way vastly more efficient than counting
the length of the string at each usage, as you may know.
That depends on how often you need the length of the string. It may be that
you don't need it often enough to justify the space or time overhead
involved in storing it.
Of course this efficiency is maybe not desired. Is that what
you mean?
No, I mean that it isn't *necessarily* the most efficient way. Often it will
be, but often isn't always.
But anyway:
I have nothing against making it as easy AS POSSIBLE... Read well the
"AS POSSIBLE" part.
Simplifying, making interfaces less complex makes them less
error prone, and is surely a step in the right direction.
It's a step in *a* right direction, but unfortunately that may involve it
being a step *away* from other right directions.
[snip]
>You appear to wish to promote one particular characteristic - ease of use
- without regard to the effect that such promotion will have on various
other characteristics.
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.
I have no problem with any implementor choosing to provide extensions to the
language, but it is important for the programmer to remember that using
such extensions renders the program non-portable.
The performance implications of calling
MyAdd(Number *a, Number *b);
or doing
a+b;
are ZERO.
That depends on the implementation (including the machine architecture).
In both cases there is a function call.
No, there is no function call involved in a+b; (unless a and b are macros
that are concealing function calls in their definition).
<snip>
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Charlton Wilbur <cw*****@chromatico.netwrote:
jacob navia <ja***@jacob.remcomp.frwrites:
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.
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?
I suspect something similar is at play here as with the kind of person
who wants to change a game to fit their own playing style - say,
NetHack, of which that has happened repeatedly - but also want to keep
the same name. The real clueful complainants go off and implement their
changes, and then call the result something else (Slash'Em). The jokers
stand on the sideline, and complain bitterly about how unfair this game
is to them.
Richard
On Thu, 28 Dec 2006 12:41:53 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Mark McIntyre a écrit :
>On Thu, 28 Dec 2006 11:08:48 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>>You can't use it without cutting yourself the hand.
if someone is incompetent, undertrained or lazy, sure. The same
argument can be applied to cars, toasters and pencil sharpeners by the
way.
Yes sure. Anything that improves security and allows for
less error prone interfaces is doomed to fail in this atmosphere
of "macho" programming.
I didn't say that, but then making false attributions seems to be a
forte of yours.
What I actually said is that your claim that its impossible to use C
without cutting yourself was generally untrue, that of course some
people will find it so depending on their level of skill and care, but
that the same could be said of many household objects.
Heck you can kill yourself with a cigarette lighter, yet they still
sell them without safety shields and with no requirement to have a
license to operate it.
>It is pointless to discuss this.
I agree. You're so blinkered with your rage against the regulars here,
and RJH in particular, that you can't be rational about anything, I
fear.
>You never make mistakes
Oh don't be silly. Of course I do, and I also accept that these may
lead to bugs. I do try to avoid them, and i do NOT rely on my toolset
to solve all my problems for me because I know that it too contains
bugs and is not omnipotent.
>and those that do are "incompetent, undertrained, and lazy".
People who make frequent mistakes of the sort you describe are one of
the above, yes.
--
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
2006-12-28 <Ot*********************@bt.com>,
Richard Heathfield wrote:
João Jerónimo said:
>Richard Heathfield wrote:
>>>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.
But on the other hand, a structure (in the structures namespace) can be
used before completely defined... It doesn't need to be defined, either!
No, it can't be used before it is defined. But its *name* can be used in a
typedef, yes.
>In fact, I tried that now:
typedef struct garbage garb;
Yes, that's legal.
>gcc doesn't complain if I try to create an object from this code...
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.
>
>If I try to access it before struct garbage exists it complains that it
doesn't know the size (because it needs to allocate space on the stack)...
C doesn't require implementations to allocate space on any kind of "stack",
but the type must be complete before you can define an object of that type.
On Thu, 28 Dec 2006 14:06:20 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>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
Random832 said:
2006-12-28 <Ot*********************@bt.com>,
Richard Heathfield wrote:
>João Jerónimo said:
>>Richard Heathfield wrote:
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.
But on the other hand, a structure (in the structures namespace) can be
used before completely defined... It doesn't need to be defined, either!
No, it can't be used before it is defined. But its *name* can be used in
a typedef, yes.
>>In fact, I tried that now:
typedef struct garbage garb;
Yes, that's legal.
>>gcc doesn't complain if I try to create an object from this code...
When invoked in conforming mode, it must complain.
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!"
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
On Thu, 28 Dec 2006 03:18:33 -0600, jacob navia wrote
(in article <45**********************@news.orange.fr>):
Randy Howard a écrit :
>>
>>>No bugs so far.
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.
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.
>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.
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 (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
On Thu, 28 Dec 2006 04:08:48 -0600, jacob navia wrote
(in article <45**********************@news.orange.fr>):
Randy Howard a écrit :
>On Wed, 27 Dec 2006 00:17:46 -0600, jacob navia wrote
(in article <45**********************@news.orange.fr>):
>>Richard Heathfield a écrit :
1) Zero terminated strings.
That's not a bug. It's a design decision. You might not agree that it's a
good decision, but it's a conscious, deliberate decision nonetheless.
No bugs so far.
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.
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 (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
On Thu, 28 Dec 2006 07:06:20 -0600, jacob navia wrote
(in article <45***********************@news.orange.fr>):
Richard Heathfield a écrit :
>jacob navia said:
>>Mark McIntyre a écrit :
Not at all. The point you are missing is that there is more to programming
than "making it as easy as possible". Programming languages have various
characteristics, of which "ease of use" is only one. Others include
performance, portability, flexibility, expressive power, and simplicity (a
non-exhaustive list).
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*)
>You appear to wish to promote one particular characteristic - ease of use -
without regard to the effect that such promotion will have on various other
characteristics.
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.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw ne********@sbcglobal.net skrev:
August Karlstrom <fu********@comhem.sewrote:
>And what features specific to C enabled you to make the program that
much more efficient?
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
Mark McIntyre a écrit :
On Thu, 28 Dec 2006 14:06:20 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>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.
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]
>
>>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.
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.
On Thu, 28 Dec 2006 11:07:37 -0600, jacob navia wrote
(in article <45***********************@news.orange.fr>):
>>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.
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.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Randy Howard a écrit :
On Thu, 28 Dec 2006 11:07:37 -0600, jacob navia wrote
(in article <45***********************@news.orange.fr>):
>>>>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.
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.
We were speaking of the possible performance penalties of this
extensions. Please read the whole tread before jumping to
conclusions.
Richard Heathfield a écrit :
jacob navia said:
<snip>
>>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!
jacob navia said:
Richard Heathfield a écrit :
<snip>
>But if you don't like trigraphs, don't use them.
I AM FORCED to used them.
No, you're free to use some other language.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
On Thu, 28 Dec 2006 11:14:13 -0600, jacob navia wrote
(in article <45***********************@news.orange.fr>):
Randy Howard a écrit :
>On Thu, 28 Dec 2006 11:07:37 -0600, jacob navia wrote
(in article <45***********************@news.orange.fr>):
>>>>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.
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.
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:
>>or a+b
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.
--
Randy Howard (2reply remove FOOBAR)
"The power of accurate observation is called cynicism by those
who have not got it." - George Bernard Shaw
Richard Heathfield a écrit :
jacob navia said:
>>Richard Heathfield a écrit :
<snip>
>>>But if you don't like trigraphs, don't use them.
I AM FORCED to used them.
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.
"jacob navia" <ja***@jacob.remcomp.frwrote in message
news:45***********************@news.orange.fr...
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.
jacob navia said:
Richard Heathfield a écrit :
>jacob navia said:
>>>Richard Heathfield a écrit :
<snip>
>>>>But if you don't like trigraphs, don't use them.
I AM FORCED to used them.
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.
A simple examination of timestamps demonstrates otherwise. There was no need
to ponder.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Richard Heathfield a écrit :
jacob navia said:
>>Richard Heathfield a écrit :
>>>jacob navia said:
Richard Heathfield a écrit :
<snip>
>But if you don't like trigraphs, don't use them.
I AM FORCED to used them.
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.
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 '{'????/
jacob navia said:
<snip>
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.
<snip>
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.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
In article <45**********************@news.orange.frjacob navia <ja***@jacob.remcomp.frwrites:
....
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.
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?
--
dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland, +31205924131
home: bovenover 215, 1025 jn amsterdam, nederland; http://www.cwi.nl/~dik/
On Thu, 28 Dec 2006 18:07:37 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Mark McIntyre a écrit :
>On Thu, 28 Dec 2006 14:06:20 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>>This is by the way vastly more efficient than counting
the length of the string at each usage, as you may know.
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
I disagree. You're once again generalising from your own extremely
limited experience to make wild sweeping statements about everyone
else's experience.
>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.
This doesn't follow even slightly. Stop putting up spurious arguments.
>To know if a string fits in a buffer you must know its length.
No, you need merely know that it cannot be larger than the buffer. I
don't expect you to understand the difference.
>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???
If you need to handle div/0 sometimes, why always perform the check?
>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.
Buy a new calculator.
The check caused significant performance loss.
Maybe, anything can be exaggerated by did you find that code
crashing with division by zero?
Dur, it was impossible for it to crash with a div/0 error.
>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...
In point of fact it hurt considerably because our pricing calculator
was slower than everyone else's to the extent that we missed deals.
>Yes, it may be 0.0001% less efficient but maybe he did not see
"efficiency" as a higher goal than SECURITY!!!
Now you're being silly. Only an idiot makes remarks like that.
>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
Actually, you have repeatedly said exactly that.
>>>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?
You misunderstand. I was saying the usage of normal C functions in
contrast to operator overloading the '+' operation.
Ah, right, so you mean in some other language which has operator
overload. I thought you were talking about C.
>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.
"almost zero". Mhm. Multiply by 10e12. Still almost zero?
>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.
I have no problem with you doing this, but don't call it C please.
--
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
On Thu, 28 Dec 2006 18:19:26 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>Richard Heathfield a écrit :
>>But if you don't like trigraphs, don't use them.
I AM FORCED to used them.
What, someone is standing over you with a gun, compelling you to type
trigraphs whenever you want to type a brace? Don't be more asinine
than you need to be.
>If I want it or not, the
translation will be done by the compiler without any user
intervention!
If you mean your compiler has to support them, sure. But this does NOT
compel you to use them anywhere.
--
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
Random832 wrote:
>>gcc doesn't complain if I try to create an object from this code...
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.
I don't get an error if I try to produce an object (or assembly code)
from a C file that has *only* that typedef...
The goal was only see if it gives an error...
JJ
Random832 wrote:
>>gcc doesn't complain if I try to create an object from this code...
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.
The "object" I was talking about in the above sentence is a file with
relocatable machine code (before linking)...
It was only to see if GCC would produce any error when compiling
something like that, so I didn't need to link (and in fact couldn't link
that, because it lacked the main() function)...
JJ
Richard Heathfield wrote:
>If I try to access it before struct garbage exists it complains that it
doesn't know the size (because it needs to allocate space on the stack)...
C doesn't require implementations to allocate space on any kind of "stack",
but the type must be complete before you can define an object of that type.
But afaik it requires the functions to be reentrant (does it require?
I'm not sure, but suppose so...), and allocating local variables in a
stack seems the only way to achieve this...
JJ
Richard Heathfield wrote:
>In my opinion (not very experienced, I admit), the types with imprecise
size aren't bad... Only there could *also* be the precise ones.
Fine, but eventually people will say "why does C have this
guaranteed-to-be-exactly-8-bits type? Nobody has used 8-bit bytes for
*decades*!" And we will not even have the excuse of "historical reasons",
since C started off *without* such a type.
I don't believe that people would say "why does C have this
guaranteed-to-be-exactly-8-bits type?", because today many people ask
"How can I guarantee that this type will be a x-bit integer?"...
Not exactly in user space, but, as I said below, in hardware-imposed
patterns...
>Remember that when programming in very low-level, one has sometimes to
adapt data structures to hardware-imposed patterns...
...which is why C leaves the exact size of types up to the implementor.
I thought this was done to increase portability...
>And typedefs allow working around this.
No, they just let you create a new name for an existing type.
It's in the c.l.c FAQ: http://c-faq.com/decl/int16.html
>>>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.
Can you give some of these examples?
I can give you one, because it's one that I have written C code for: the
Analog SHARC DSP (used in set-top boxes, e.g. DVD players, Web TV, that
sort of thing), which has 32-bit bytes. So sizeof(long), sizeof(short),
sizeof(int), and sizeof(char) are all the same: 1.
No doubt others here can tell you about other DSPs with 16- or 32-bit bytes.
They're hardly rare. Also, various dinosaurs have had very weird byte
sizes, e.g. 9, 36, and I believe there was once a 24 (BICBW).
All that C guarantees is that your bytes will be *at least* 8 bits wide, and
*exactly* CHAR_BIT bits wide, where the value of CHAR_BIT is set by the
implementation.
Thanks, I thought all that strange machines were already dinosaurs...
JJ
Randy Howard wrote:
On Thu, 28 Dec 2006 11:14:13 -0600, jacob navia wrote
.... snip ...
>>
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:
>>>or a+b
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.
--
Merry Christmas, Happy Hanukah, Happy New Year
Joyeux Noel, Bonne Annee.
Chuck F (cbfalconer at maineline dot net)
<http://cbfalconer.home.att.net>
On Wed, 27 Dec 2006 07:17:46 +0100, jacob navia wrote:
>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.
it is possible this is an error too but it seems
now memory leak not happen to me, and i presume 99% of out of bound
array rewriting too using my modificating version of malloc and free
On Thu, 28 Dec 2006 18:07:37 +0100, jacob navia wrote:
>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.
this depends on functions that write the arrays if
0) we have an array "char a[59];"
1) if a function change "a" and return its new len
or if i change "a" i know the new len
we know always the new len of "a"
in c there are function that modify array but not return the len
bugged from definition
João Jerónimo said:
Richard Heathfield wrote:
>>In my opinion (not very experienced, I admit), the types with imprecise
size aren't bad... Only there could *also* be the precise ones.
Fine, but eventually people will say "why does C have this
guaranteed-to-be-exactly-8-bits type? Nobody has used 8-bit bytes for
*decades*!" And we will not even have the excuse of "historical reasons",
since C started off *without* such a type.
I don't believe that people would say "why does C have this
guaranteed-to-be-exactly-8-bits type?", because today many people ask
"How can I guarantee that this type will be a x-bit integer?"...
They do? I rarely see anyone asking that question. And it's rarer still for
someone to ask that question with good reason.
Not exactly in user space, but, as I said below, in hardware-imposed
patterns...
>>Remember that when programming in very low-level, one has sometimes to
adapt data structures to hardware-imposed patterns...
...which is why C leaves the exact size of types up to the implementor.
I thought this was done to increase portability...
Yes. The two statements are equivalent.
>>And typedefs allow working around this.
No, they just let you create a new name for an existing type.
It's in the c.l.c FAQ:
http://c-faq.com/decl/int16.html
The FAQ says, rightly, "if you truly need control over exact type sizes,
this is the right approach." And as it strongly hints, you almost certainly
don't *really* need control over exact type sizes after all.
>>>>But now "byte" is a synonym of "octet", right?
Wrong. Numerous counter-examples exist.
Can you give some of these examples?
I can give you one, because it's one that I have written C code for: the
Analog SHARC DSP (used in set-top boxes, e.g. DVD players, Web TV, that
sort of thing), which has 32-bit bytes. So sizeof(long), sizeof(short),
sizeof(int), and sizeof(char) are all the same: 1.
No doubt others here can tell you about other DSPs with 16- or 32-bit
bytes. They're hardly rare. Also, various dinosaurs have had very weird
byte sizes, e.g. 9, 36, and I believe there was once a 24 (BICBW).
All that C guarantees is that your bytes will be *at least* 8 bits wide,
and *exactly* CHAR_BIT bits wide, where the value of CHAR_BIT is set by
the implementation.
Thanks, I thought all that strange machines were already dinosaurs...
In terms of byte sizes, you ain't seen nuffin' yet.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www.
Mark McIntyre a écrit :
On Thu, 28 Dec 2006 18:07:37 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>>Mark McIntyre a écrit :
>>>On Thu, 28 Dec 2006 14:06:20 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
This is by the way vastly more efficient than counting
the length of the string at each usage, as you may know.
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
I disagree. You're once again generalising from your own extremely
limited experience to make wild sweeping statements about everyone
else's experience.
And you are speaking about something you do not know at all: me.
Where is your data about me? Where you know what experience I have or
not?
You don't. Period. The one making sweeping statements is you.
>
>>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.
This doesn't follow even slightly. Stop putting up spurious arguments.
No?
How do you pass the length of the string then?
>>To know if a string fits in a buffer you must know its length.
No, you need merely know that it cannot be larger than the buffer. I
don't expect you to understand the difference.
Gosh! You are clever. And how can I know if the given string
is bigger than the buffer without at least trying to measure
the length?
int fn(char *str)
{
char tmpbuf[512];
/* Here I have to start scanning the string.
At least 511 bytes must be scanned before
I realize that the length of the string is bigger
than tmpbuf. For bigger buffers a bigger WASTE
*/
}
>
>>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???
If you need to handle div/0 sometimes, why always perform the check?
Because you never know when software will change and a constant
becomes a variable...
>
>>>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.
Buy a new calculator.
??? You mean 1+e^x in C?
Or you mean pow(e,x)+1 ?
>
>>>The check caused significant performance loss.
Maybe, anything can be exaggerated by did you find that code
crashing with division by zero?
Dur, it was impossible for it to crash with a div/0 error.
>>>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...
In point of fact it hurt considerably because our pricing calculator
was slower than everyone else's to the extent that we missed deals.
Ahh and it was slower because of the division by zero tests?
I would like to see the data that supports that hypothesis.
With today's machines, a test for zero is so fast that to slow
down a calculator so that a human being notices the tests must have
been done in an incredible fashion, and probably there are
thousands of OTHER factors that come into the slowdown first.
>
>>Yes, it may be 0.0001% less efficient but maybe he did not see
"efficiency" as a higher goal than SECURITY!!!
Now you're being silly. Only an idiot makes remarks like that.
Obvious coming from you. Only idiots make remarks like
"efficiency" is not a higher goal than SECURITY.
Yes. Only an idiot can do a remark like that.
This finishes it. You, you are not AN IDIOT!
On Fri, 29 Dec 2006 09:36:08 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>And you are speaking about something you do not know at all: me.
Au contaire, cheri.
>Where is your data about me? Where you know what experience I have or
not?
You've demonstrated your experience in this newsgroup on numerous
occasions. If you have different experience to that which you display
here, then show it.
>You don't. Period. The one making sweeping statements is you.
I'm not the one making sweeping statements claiming that it is
essential to know the length of a string.
>How do you pass the length of the string then?
With correct design, you don't need to .
>No, you need merely know that it cannot be larger than the buffer. I
don't expect you to understand the difference.
Gosh! You are clever. And how can I know if the given string
is bigger than the buffer without at least trying to measure
the length?
By knowing its length already, of course.
>int fn(char *str)
{
char tmpbuf[512];
/* Here I have to start scanning the string.
At least 511 bytes must be scanned before
I realize that the length of the string is bigger
than tmpbuf. For bigger buffers a bigger WASTE
*/
}
Is it /my/ fault if you have a badly designed programme? Where did
"str" come from? How did you create it? Did you define its length when
you did so?
To put you out of your misery, the app in question read strings into
fixed length buffers, padded them with blanks and null-terminated
them. Thus the strings were /always/ exactly N characters long, no
more and no less. This removed any need at all anywhere to calculate
how long the strings were, because we already knew.
>If you need to handle div/0 sometimes, why always perform the check?
Because you never know when software will change and a constant
becomes a variable...
Two points here
a) constants have nothing to do with it.
b) designing an application for a series of unknown future changes for
unguessable purposes by maintenance droids of unknown quality is both
inefficient and foolish.
I also strongly suspect you're not a follower of XP. They'd shoot you
for doing that sort of thing. :-)
>In point of fact it hurt considerably because our pricing calculator
was slower than everyone else's to the extent that we missed deals.
Ahh and it was slower because of the division by zero tests?
Yes. How do I know? I measured it. Next question.
>I would like to see the data that supports that hypothesis.
Sure. Get yourself employed by my former employer, and you can look at
my project post-implementation report. Its in the files of the
Technology Dept somewhere.
>With today's machines, a test for zero is so fast
And you've proved this beyond all doubt on Vax/VMS, Vax/OSF,
Sun/Solaris, Windows NT/PIII, all of which were targets.
>that to slow
down a calculator so that a human being notices the tests must have
been done in an incredible fashion,
Or incredibly often. You apparently have no experience of numerical
pricing techniques either. Ever heard of monte-carlo simulation?
>>>Yes, it may be 0.0001% less efficient but maybe he did not see
"efficiency" as a higher goal than SECURITY!!!
Now you're being silly. Only an idiot makes remarks like that.
Obvious coming from you.
The point you miss is that security and efficiency are not mutually
exclusive, nor is one axiomatically more important than the other.
Again you generalise unacceptably.
>This finishes it. You, you are not AN IDIOT!
I'm glad we agree I'm not an idiot. I know that of course.
--
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
João Jerónimo <j_*******@yahoo.com.brwrites:
Richard Heathfield wrote:
>>If I try to access it before struct garbage exists it complains that it
doesn't know the size (because it needs to allocate space on the stack)...
C doesn't require implementations to allocate space on any kind of "stack",
but the type must be complete before you can define an object of that type.
But afaik it requires the functions to be reentrant (does it require?
I'm not sure, but suppose so...), and allocating local variables in a
stack seems the only way to achieve this...
It's easy to create C functions that aren't reentrant (e.g., if they
use variables that have static storage duration). The requirement is
that functions must be callable recursively, which is different from
being reentrant.
Local variables (more precisely, objects with automatic storage
duration) must be allocated and deallocated in a stack-like manner
(though a compiler may be able to avoid this if it can prove that the
function is never called recursively). But what most people mean by
"the stack" is a contiguously allocated region of memory indexed by a
"stack pointer" (which is typically a CPU register), that grows in a
specific direction in memory. Many (most?) C implementations use this
kind of "stack", but it's not required. An implementation could, for
example, use malloc() or something similar to allocate local variables
for each function call, and free() or something similar to deallocate
them.
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
On Thu, 28 Dec 2006 19:22:37 -0500, in comp.lang.c , CBFalconer
<cb********@yahoo.comwrote:
>It is high time to PLONK this thread. Enjoy your war.
I agree, its been fun but EOT for me.
--
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
jacob navia <ja***@jacob.remcomp.frwrote:
Mark McIntyre a écrit :
On Thu, 28 Dec 2006 14:06:20 +0100, in comp.lang.c , jacob navia
<ja***@jacob.remcomp.frwrote:
>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.
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)
Since you are eager to claim this just about every time you advertise
your Pascal-strings scheme, against the advice of nearly everybody who,
unlike you or I, actually _is_ an expert, I'm sure you have done
extensive research on this issue and have lots of real world data to
prove that the experts are wrong and you are right. I qould suggest that
you show this data.
problems as heathfield says. But... if you need to keep the
His name, unlike yours (as stated in your own headers), starts with a
capital. Common decency is free.
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.
Not at all. 1e+0 is merely a very stupid way to write 1 in C. 1+e^x is
not a C expression but a maths one, and if you remember the range of
your exponents, it is easy to figure out why a zero check for it is
silly.
The check caused significant performance loss.
Maybe, anything can be exaggerated by did you find that code
crashing with division by zero?
Ignoring the wonky grammar, I think you'll find (if you read the
expression quoted above correctly) that Mark could easily prove that
there would be no crash.
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
You have measured this? You have even done the maths? Others have.
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.
Again: data, please. _Real_ data, not your personal code.
>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.
You misunderstand. I was saying the usage of normal C functions in
contrast to operator overloading the '+' operation.
You cannot overload the '+' operation. Unless you think you're in
comp.lang.c++, which is the next door down the corridor.
Basically, jacob, you're arguing against _real_ experts, and basing your
arguments on suppositions and loose sand. That's no way to be taken
seriously.
Richard
Keith Thompson wrote:
João Jerónimo <j_*******@yahoo.com.brwrites:
>Richard Heathfield wrote:
>>>If I try to access it before struct garbage exists it complains that it
doesn't know the size (because it needs to allocate space on the stack)...
C doesn't require implementations to allocate space on any kind of "stack",
but the type must be complete before you can define an object of that type.
But afaik it requires the functions to be reentrant (does it require?
I'm not sure, but suppose so...), and allocating local variables in a
stack seems the only way to achieve this...
It's easy to create C functions that aren't reentrant (e.g., if they
use variables that have static storage duration). The requirement is
that functions must be callable recursively, which is different from
being reentrant.
Ok, but apart from code that is explicitly non-reentrant (because it
allocates data with limited scoop in a statical fashion), C code will be
reentrant, meaning that any function can call any function, including
itself, without having the functions' "instances" conflicting with each
other...
JJ
João Jerónimo <j_*******@yahoo.com.brwrites:
Keith Thompson wrote:
>João Jerónimo <j_*******@yahoo.com.brwrites:
[...]
>It's easy to create C functions that aren't reentrant (e.g., if they
use variables that have static storage duration). The requirement is
that functions must be callable recursively, which is different from
being reentrant.
Ok, but apart from code that is explicitly non-reentrant (because it
allocates data with limited scoop in a statical fashion), C code will be
reentrant, meaning that any function can call any function, including
itself, without having the functions' "instances" conflicting with each
other...
Yes, C functions are reentrant unless they're not.
More seriously, the automatic objects declared within a function
(including the parameters) are guaranteed to be distinct for each call
to that function. This is subject to the "as-if" rule; a compiler is
allowed to optimize the code as long as the code can't tell tell the
difference (more or less).
--
Keith Thompson (The_Other_Keith) ks***@mib.org <http://www.ghoti.net/~kst>
San Diego Supercomputer Center <* <http://users.sdsc.edu/~kst>
We must do something. This is something. Therefore, we must do this.
In article <45***********************@news.orange.fr>,
jacob navia <ja***@jacob.remcomp.frwrote:
>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.
If knowing the length of strings is that important, can you explain
how counted strings would have made this code easier to write, clearer,
or less error-prone?
(This is the least-trivial string processing code I've written in recent
memory, so it's as close to a representative example as I can give.)
For anybody else who's following along, commentary and suggestions about
the code itself is also welcome. (It does require an ASCII system,
which seemed like a suitable restriction since the data it works with is
defined to be ASCII. The character set dependency could be eliminated
if necessary by writing the ASCII code points and case conversion into
the code instead of using character constants and toupper, and I think
that if that were done this code could be inserted into a strictly
conforming C program without affecting its strictly-conforming-ness
modulo translation limits.)
/* -8<--Code starts here--8<- */
#include <assert.h>
#include <ctype.h>
#include <string.h>
/*Verify checksum (if present) and split fields in a NMEA sentence.
Inputs:
sentence is a string containing the NMEA sentence.
This string IS MODIFIED on successful completion.
fields is an array of char *. On successful return, fields[i]
contains a pointer to the ith field of the sentence (fields[0]
is the sentence identifier and fields[ret-1] is the last data
field).
nfields is the maximum number of fields to unpack.
Return value:
If sentence does not contain a correctly formatted NMEA sentence or
contains a sentence with an incorrect checksum, returns 0 and does
not modify sentence or fields.
If nfields is too small, returns negative value such that -ret is the
number of fields needed and does not modify sentence or fields.
On success, returns the number of fields unpacked, and modifies
sentence by replacing all field separators (commas and the '*' or
'\r' following the data) with '\0' to allow fields[i] to point
into the original string.
Correctly formatted NMEA sentences have the form
"$TTSSS,comma,separated,fields*CC\r\n" for checksummed sentences or
"$TTSSS,comma,separated,fields\r\n" for non-checksummed sentences.
The contents (other than commas) of the fields between the initial '$'
and the terminating '*' or '\r', and any characters after the checksum
or after the '\r' for sentences without a checksum, are ignored here.
The sentence need not start at the beginning of the string. If the
string contains more than one sentence, all but the first will be
ignored.
*/
int unpack_nmea(char *sentence,char **fields, int nfields)
{
static char *hexdigits="0123456789ABCDEF";
int needed;
char *start,*ptr;
char cksum=0;
int i;
ptr=start=strchr(sentence,'$');
if(!ptr)
{
/*No '$' to start sentence*/
return 0;
}
/*First pass: Check checksum and count fields*/
ptr++;
needed=1;
while(*ptr && *ptr!='*' && *ptr!='\r')
{
if(*ptr==',')
{
needed++;
}
cksum^=*ptr;
ptr++;
}
/*Now we can check whether the input is well-formed...*/
if(*ptr=='0')
{
/*Not a well-formed sentence (no terminator)*/
return 0;
}
if(*ptr=='*')
{
/*Checksummed sentence, verify checksum*/
if(toupper(ptr[1])!=hexdigits[cksum>>4]
|| toupper(ptr[2])!=hexdigits[cksum&0xf])
{
/*Checksum error*/
return 0;
}
}
/*...and whether we have enough space to pack the output*/
if(needed>nfields)
return -needed;
/*Now we just have to split up the string and pack fields[]*/
ptr=start;
for(i=0;i<needed;i++)
{
ptr++;
fields[i]=ptr;
ptr+=strcspn(ptr,",*\r");
assert(*ptr==',' || *ptr=='*' || *ptr=='\r');
*ptr=0;
}
return needed;
}
/* -8<--Code ends here--8<- */
dave
--
Dave Vandervies dj******@csclub.uwaterloo.ca
[Y]es, I am seriously advocating that you should make sure your buffer is big
enough to store stuff you want to store in that buffer. Are you seriously
advocating that you should not? --Richard Heathfield in comp.lang.c
Keith Thompson wrote:
>Ok, but apart from code that is explicitly non-reentrant (because it
allocates data with limited scoop in a statical fashion), C code will be
reentrant, meaning that any function can call any function, including
itself, without having the functions' "instances" conflicting with each
other...
Yes, C functions are reentrant unless they're not.
:-)
JJ
Dave Vandervies a écrit :
>
If knowing the length of strings is that important, can you explain
how counted strings would have made this code easier to write, clearer,
or less error-prone?
/* -8<--Code starts here--8<- */
#include <assert.h>
#include <ctype.h>
#include <string.h>
int unpack_nmea(char *sentence,char **fields, int nfields)
{
static char *hexdigits="0123456789ABCDEF";
int needed;
char *start,*ptr;
char cksum=0;
int i;
ptr=start=strchr(sentence,'$');
-------
In the strchr call above, a counted strings implementation can
safely replace a strchr with memchr, that doesn't check at each
character the terminating zero but just makes a bounded
memory scan
---------
if(!ptr)
{
/*No '$' to start sentence*/
return 0;
}
/*First pass: Check checksum and count fields*/
ptr++;
needed=1;
while(*ptr && *ptr!='*' && *ptr!='\r')
{
--------
Here the string library provides
Strfind_firstof(String, setOfChars);
--------
if(*ptr==',')
{
needed++;
}
cksum^=*ptr;
ptr++;
}
/*Now we can check whether the input is well-formed...*/
if(*ptr=='0')
-------
Are you sure you are testing for the character zero ('0') and
not for the terminating zero ( 0 ) ?????????
-------
{
/*Not a well-formed sentence (no terminator)*/
return 0;
}
if(*ptr=='*')
{
/*Checksummed sentence, verify checksum*/
if(toupper(ptr[1])!=hexdigits[cksum>>4]
|| toupper(ptr[2])!=hexdigits[cksum&0xf])
{
/*Checksum error*/
return 0;
}
}
/*...and whether we have enough space to pack the output*/
if(needed>nfields)
return -needed;
/*Now we just have to split up the string and pack fields[]*/
ptr=start;
for(i=0;i<needed;i++)
{
ptr++;
fields[i]=ptr;
ptr+=strcspn(ptr,",*\r");
---------
The counted strcspn version needs NOT to test for a terminating zero
but just for the pattern being searched
---------
assert(*ptr==',' || *ptr=='*' || *ptr=='\r');
*ptr=0;
}
return needed;
}
/* -8<--Code ends here--8<- */
dave
But I may disappoint you since in the implementation of lcc-win32 the
strings are probably much slower than they ought to be since the
main thrust of the package is to provide more security and not speed.
I will start a faster version soon.
As you can see, the main advantages are the obviating for the tests
for the zero byte.
jacob
jacob navia said:
Dave Vandervies a écrit :
>>
If knowing the length of strings is that important, can you explain
how counted strings would have made this code easier to write, clearer,
or less error-prone?
/* -8<--Code starts here--8<- */
#include <assert.h>
#include <ctype.h>
#include <string.h>
int unpack_nmea(char *sentence,char **fields, int nfields)
{
static char *hexdigits="0123456789ABCDEF";
int needed;
char *start,*ptr;
char cksum=0;
int i;
ptr=start=strchr(sentence,'$');
-------
In the strchr call above, a counted strings implementation can
safely replace a strchr with memchr, that doesn't check at each
character the terminating zero but just makes a bounded
memory scan
Whilst that *is* an improvement, it's a micro-optimisation, since each
character in turn is being examined anyway.
<snip>
Here the string library provides
Strfind_firstof(String, setOfChars);
*The* string library is the set of functions provided as part of any hosted
C implementation, and it doesn't supply any function of the name specified.
If you mean some third-party library of your own creation, you'd be wise to
specify this, to avoid confusion.
Incidentally, *THE* string library provides strcspn and strpbrk.
<snip>
>>
/*Now we can check whether the input is well-formed...*/
if(*ptr=='0')
-------
Are you sure you are testing for the character zero ('0') and
not for the terminating zero ( 0 ) ?????????
A reasonable question. Watch what you're doing with all those question
marks, though...
<snip>
---------
The counted strcspn version needs NOT to test for a terminating zero
but just for the pattern being searched
Again, whilst this *is* an improvement, it is merely a micro-optimisation,
of little or no real consequence. It's not as if you're reducing the time
complexity of the algorithm.
But I may disappoint you since in the implementation of lcc-win32 the
strings are probably much slower than they ought to be since the
main thrust of the package is to provide more security and not speed.
I will start a faster version soon.
As you can see, the main advantages are the obviating for the tests
for the zero byte.
If that's the main advantage, you may as well throw it away, since it isn't
*enough* of an advantage to make it worth doing.
The main advantages of my own string library are:
1) it caches string lengths, thus allowing fast len, cat and cpy operations;
2) it resizes buffers when necessary, without troubling the user, and keeps
extra space around so that it doesn't need to go to the well every time;
3) it contains several useful string functions not provided by the standard
library;
4) it is written in ISO C and doesn't depend on any particular compiler
features.
The first of these has genuine and significant time complexity reduction
benefits. The second takes a load off the programmer's shoulders. The third
is basically a sack of nice toys. And the fourth is essential if the code
is to remain viable in the long term.
--
Richard Heathfield
"Usenet is a strange place" - dmr 29/7/1999 http://www.cpax.org.uk
email: rjh at the above domain, - www. This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: William C. White |
last post by:
Does anyone know of a way to use PHP /w Authorize.net AIM without using
cURL? Our website is hosted on a shared drive and the webhost company
doesn't installed additional software (such as cURL)...
|
by: Albert Ahtenberg |
last post by:
Hello,
I don't know if it is only me but I was sure that header("Location:url")
redirects the browser instantly to URL, or at least stops the execution of
the code. But appearantely it continues...
|
by: James |
last post by:
Hi,
I have a form with 2 fields.
'A'
'B'
The user completes one of the fields and the form is submitted.
On the results page I want to run a query, but this will change
subject to which...
|
by: Ollivier Robert |
last post by:
Hello,
I'm trying to link PHP with Oracle 9.2.0/OCI8 with gcc 3.2.3 on a Solaris9
system. The link succeeds but everytime I try to run php, I get a SEGV from
inside the libcnltsh.so library.
...
|
by: Richard Galli |
last post by:
I want viewers to compare state laws on a single subject.
Imagine a three-column table with a drop-down box on the top. A viewer
selects a state from the list, and that state's text fills the...
|
by: Albert Ahtenberg |
last post by:
Hello,
I have two questions.
1. When the user presses the back button and returns to a form he filled
the form is reseted. How do I leave there the values he inserted?
2. When the...
|
by: inderjit S Gabrie |
last post by:
Hi all
Here is the scenerio ...is it possibly to do this...
i am getting valid course dates output on to a web which i have designed
....all is okay so far , look at the following web url
...
|
by: Jack |
last post by:
Hi All,
What is the PHP equivilent of Oracle bind variables in a SQL statement, e.g.
select x from y where z=:parameter
Which in asp/jsp would be followed by some statements to bind a value...
|
by: Sandwick |
last post by:
I am trying to change the size of a drawing so they are all 3x3.
the script below is what i was trying to use to cut it in half ... I
get errors.
I can display the normal picture but not the...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Sonnysonu |
last post by:
This is the data of csv file
1 2 3
1 2 3
1 2 3
1 2 3
2 3
2 3
3
the lengths should be different i have to store the data by column-wise with in the specific length.
suppose the i have to...
|
by: marktang |
last post by:
ONU (Optical Network Unit) is one of the key components for providing high-speed Internet services. Its primary function is to act as an endpoint device located at the user's premises. However,...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
|
by: tracyyun |
last post by:
Dear forum friends,
With the development of smart home technology, a variety of wireless communication protocols have appeared on the market, such as Zigbee, Z-Wave, Wi-Fi, Bluetooth, etc. Each...
| |
