comp.lang.c - 26 new messages in 6 topics - digest

comp.lang.c
http://groups.google.com/group/comp.lang.c?hl=en

comp.lang.c@googlegroups.com

Today's topics:

* What is on topic here - 3 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/a91a80117d377f7f?hl=en
* Substrings and so on - 6 messages, 5 authors
http://groups.google.com/group/comp.lang.c/t/2e9f3f2a5244b8a2?hl=en
* The undefinedness of a common expression. - 5 messages, 3 authors
http://groups.google.com/group/comp.lang.c/t/bdae87d399a9442e?hl=en
* Experiment: functional concepts in C - 2 messages, 2 authors
http://groups.google.com/group/comp.lang.c/t/7889fc59043eb32b?hl=en
* problems with logic operations within loops - 9 messages, 7 authors
http://groups.google.com/group/comp.lang.c/t/9228b4a6f1c5f9e3?hl=en
* Getting the size of a C function - 1 messages, 1 author
http://groups.google.com/group/comp.lang.c/t/dcc5cb3c26da8f6f?hl=en

==============================================================================
TOPIC: What is on topic here
http://groups.google.com/group/comp.lang.c/t/a91a80117d377f7f?hl=en
==============================================================================

== 1 of 3 ==
Date: Tues, Jan 26 2010 4:03 am
From: Tim Streater

On 26/01/2010 10:37, Albert wrote:
> jacob navia wrote:
> <snip>
>
> This is a reply to the subject.
>
> Suppose the OP is called A and any replier B.
> If A posts a *topic* that B thinks should be in another newsgroup, B
> *can* tell A that he doesn't like that and can (optionally) suggest a
> more appropriate newsgroup.

Seems to me it's not a question of B not liking it, B is suggesting a
place where A might get a better answer.

Of course, there are *some* posters here, who claim not to be "regs" but
in fact are, who wilfully mis-interpret this useful advice and proceed
to piss on B from a great height.

--
Tim

"That excessive bail ought not to be required, nor excessive fines
imposed, nor cruel and unusual punishments inflicted"

Bill of Rights 1689

== 2 of 3 ==
Date: Tues, Jan 26 2010 8:39 am
From: Charlton Wilbur

>>>>> "A" == Albert <albert.xtheunknown0@gmail.com> writes:

A> Suppose the OP is called A and any replier B. If A posts a
A> *topic* that B thinks should be in another newsgroup, B *can*
A> tell A that he doesn't like that and can (optionally) suggest a
A> more appropriate newsgroup.

A> This way, everyone gets ideas about where stuff should be posted
A> given the year, month, who are "regulars" at a certain point of
A> time, etc.

And what happens then is that C, D, and E answer A's question, but only
C gets it right; B points out that D and E got it wrong, and suggests
the other newsgroup again; F and G snipe at B. Then H responds with
seven posts of pseudopsychological babble (which just about everyone
ignores), and I comes in a week later to claim that B has an
autism-spectrum disorder.

Charlton

--
Charlton Wilbur
cwilbur@chromatico.net

== 3 of 3 ==
Date: Tues, Jan 26 2010 8:33 am
From: Charlton Wilbur

>>>>> "S" == Seebs <usenet-nospam@seebs.net> writes:

S> (For whatever reason, the Objective-C users never seem to come
S> here.)

Perhaps the Objective-C users are smart enough to realize that they will
get more useful answers in fora dedicated to Objective-C?

I mean, Objective-C behaves as a separate language, and there's no
community of ignorant marketroids treating C and Objective-C as
interchangeable, such as you get with the "C/C++" crowd.

Charlton

--
Charlton Wilbur
cwilbur@chromatico.net

==============================================================================
TOPIC: Substrings and so on
http://groups.google.com/group/comp.lang.c/t/2e9f3f2a5244b8a2?hl=en
==============================================================================

== 1 of 6 ==
Date: Tues, Jan 26 2010 4:32 am
From: Tom St Denis

On Jan 26, 6:40 am, Vicent <vgi...@gmail.com> wrote:
> I posted this also in comp.lang.c++, so sorry for multiposting.
>
> I would like to ask you about standard or usual ways to manage with
> files or strings, specially when getting input data and writing output
> from an algorithm.
>
> I mean: which structures, data types or classes? Which standard ways
> to read/write from/on files?
>
> I've read some tutorials that deal with the standard C I/O and string
> (string.h) libraries, but specially when managing strings, I am a bit
> lost: Are there methods or functions to get substrings from a string,
> or to take "spaces" ("blanks") away (a typical "wrap" function)??
>
> About reading data from a text file, I think this is called "parsing".
> Is there any "parsing" library???
>
> Sorry if my questions are too naive, but I am a beginner.
>
> Thank you very much in advance!

Sounds more like you have a comp.sci problem than a C problem, as in
learn how to manipulate data first then pick a language to express it.

Also, pick a single language and go with it. There is no C/C++ or
whatever. If you want to learn how to manipulate strings in C++
that's fine but at what I'm guessing is your level I'd stick to one or
another, specially since they're not related.

Tom

== 2 of 6 ==
Date: Tues, Jan 26 2010 5:07 am
From: Flash Gordon

Vicent wrote:
> I posted this also in comp.lang.c++, so sorry for multiposting.

If you are using C++ then I believe C++ provides a lot more facilities
string facilities than C.

> I would like to ask you about standard or usual ways to manage with
> files or strings, specially when getting input data and writing output
> from an algorithm.
>
> I mean: which structures, data types or classes? Which standard ways
> to read/write from/on files?

C only has one string data structure (which is not a type), and that is
the nul terminated string. For input/output you have the functions in
stdio.h

A number of people have string libraries which they have written
themselves, which use more complex structures. However, these are not
standard.

> I've read some tutorials that deal with the standard C I/O and string
> (string.h) libraries,

That's what you get.

> but specially when managing strings, I am a bit
> lost: Are there methods or functions to get substrings from a string,
> or to take "spaces" ("blanks") away (a typical "wrap" function)??

Not in C. You either have to write your own or get a non-standard
library that someone else wrote.

> About reading data from a text file, I think this is called "parsing".
> Is there any "parsing" library???

Reading the text and parsing it are different tasks. Reading is getting
it in to memory, parsing is breaking it apart in to useful chunks. Some
functions, e.g. fscanf, do both tasks. Genreally in my opinion the best
way is often to read a line at a time in to memory and then parse the
line entirely in memory.

> Sorry if my questions are too naive, but I am a beginner.

The first thing you need to do is decide which language you are trying
to learn. If it is C++ then the best answers are likely to be very
different and could include classes or templates or something else which
C does not have.
--
Flash Gordon

== 3 of 6 ==
Date: Tues, Jan 26 2010 6:20 am
From: lacos@ludens.elte.hu (Ersek, Laszlo)

In article <f393377f-5123-4c26-8d19-d6e05eee0059@36g2000yqu.googlegroups.com>, Vicent <vginer@gmail.com> writes:
> I posted this also in comp.lang.c++, so sorry for multiposting.
>
> I would like to ask you about standard or usual ways to manage with
> files or strings, specially when getting input data and writing output
> from an algorithm.
>
> I mean: which structures, data types or classes? Which standard ways
> to read/write from/on files?

For C++, I guess you'd look first at std::string and std:iostream.
Google them, or obtain a draft or an actual edition of the ISO C++
standard (ISO/IEC 14882). A draft might be available at the C++
Standards Committee's site:

http://www.open-std.org/jtc1/sc22/wg21/

Chapter 21, Strings library
Chapter 27, Input/output library

The Qt or Boost libraries may prove helpful as well.

http://doc.trolltech.com/4.6-snapshot/qstring.html
http://www.boost.org/doc/libs/1_41_0/libs/libraries.htm#String

For C: don't start with it. Low-level string manipulation is one of the
most error-prone tasks in general, leading to countless security
vulnerabilities.

> I've read some tutorials that deal with the standard C I/O and string
> (string.h) libraries, but specially when managing strings, I am a bit
> lost: Are there methods or functions to get substrings from a string,
> or to take "spaces" ("blanks") away (a typical "wrap" function)??

(That would be a typical "trim" function I guess.) In my opinion, the
"string interface" provided by standard C (or by versions of the Single
Unix Specification) are much lower-level than you'd need; definitiely
not for a beginner with higher abstraction needs. I suggest you switch
to another language supporting high-level string manipulation (Perl,
Python, Ruby etc) or grab a strings library. A discussion on them
occurred on Reddit some time ago; several libraries were mentioned:

http://www.reddit.com/r/programming/comments/abh76/what_string_type_should_i_use_for_a_c_project

When posting to that topic, I stumbled upon the following comparison
page:

http://www.and.org/vstr/comparison

> About reading data from a text file, I think this is called "parsing".
> Is there any "parsing" library???

Especially in relation to parsing: don't start writing parsers in C. If
you must, stick to whole-line input (with bounded length) and regular
expressions. One such regex library is PCRE:

http://www.pcre.org/

But the Single Unix Specification defines a regex facility too.

http://www.opengroup.org/onlinepubs/007908775/xsh/regex.h.html

If you insist on consuming lines of arbitrary length, consider the
getline() GNU libc extension.

http://www.gnu.org/s/libc/manual/html_node/Line-Input.html#Line-Input

Localized low-level text processing (put very crudely: anything
non-ASCII) requires even more caution, so don't start with that either.
Some C and C++ libraries should support it transparently, though.

HTH,
lacos

== 4 of 6 ==
Date: Tues, Jan 26 2010 8:14 am
From: Vicent

> Sounds more like you have a comp.sci problem than a C problem, as in
> learn how to manipulate data first then pick a language to express it.
>
> Also, pick a single language and go with it.  There is no C/C++ or
> whatever.  If you want to learn how to manipulate strings in C++
> that's fine but at what I'm guessing is your level I'd stick to one or
> another, specially since they're not related.
>
> Tom

Tom,

Thank you for your answer.

I've chosen C++, because I need to program some algorithms and I think
it is a good choice for that purpose.

So, my problem is about how to read files in C++, I think.

== 5 of 6 ==
Date: Tues, Jan 26 2010 8:19 am
From: Vicent

On 26 ene, 14:07, Flash Gordon <s...@spam.causeway.com> wrote:

> If you are using C++ then I believe C++ provides a lot more facilities
> string facilities than C.

Yes, I realize of that...

> A number of people have string libraries which they have written
> themselves, which use more complex structures. However, these are not
> standard.

OK. I didn't know that, although I was suspecting it.

> Reading the text and parsing it are different tasks. Reading is getting
> it in to memory, parsing is breaking it apart in to useful chunks. Some
> functions, e.g. fscanf, do both tasks. Genreally in my opinion the best
> way is often to read a line at a time in to memory and then parse the
> line entirely in memory.

Yes, that was my idea, in fact --First, I read a line. Then, I try to
get the information from that line into some variables in my
algorithm.

> The first thing you need to do is decide which language you are trying
> to learn. If it is C++ then the best answers are likely to be very
> different and could include classes or templates or something else which
> C does not have.

I guess I'll stay with C++.

Thank you!

== 6 of 6 ==
Date: Tues, Jan 26 2010 9:00 am
From: Eric Sosman

On 1/26/2010 11:14 AM, Vicent wrote:
> [...]
> I've chosen C++, because I need to program some algorithms and I think
> it is a good choice for that purpose.
>
> So, my problem is about how to read files in C++, I think.

Perhaps the kind people on the comp.lang.c++ forum
would be better able to assist you with that language.
Since the I/O features of C++ differ quite a lot from
those of C, and since I/O is what you're interested in ...

--
Eric Sosman
esosman@ieee-dot-org.invalid

==============================================================================
TOPIC: The undefinedness of a common expression.
http://groups.google.com/group/comp.lang.c/t/bdae87d399a9442e?hl=en
==============================================================================

== 1 of 5 ==
Date: Tues, Jan 26 2010 5:21 am
From: "André Gillibert"

"Wojtek Lerch" <wojtek_l@yahoo.ca> a écrit dans le message de news:
7s5sgeFjbkU1@mid.individual.net...
> André Gillibert wrote:
>> "Wojtek Lerch" <wojtek_l@yahoo.ca> wrote:
>>>... I've always believed that an assignment operator returns the value
>>>that it also stores in the object, *without* reading it back from the
>>>object, and that the Standard's description in terms of "the value of the
>>>object after the assignment" was just a clumsy wording (no offense) that
>>>wasn't meant to imply a read access.
>>
>> I agree.
>> I think a "read" access to an object involves a lvalue-to-value
>> conversion (6.3.2.1-1), even though that's not clearly stated.
>
> It's the other way around: a lvalue-to-value conversion involves a read
> access, but that doesn't mean that every read access is part of an
> lvalue-to-value conversion.

Indeed, you're right.
However, the standard doesn't specify where there are no read access...
e.g.

int y=0;
volatile int x;
x=y;

The standard doesn't specify if y is to be read 153 times or only once.

>
>> Moreover 6.5.16-3 indicates that assignment expressions aren't lvalues.
>> They have the value (rvalue) of the left operand after the assignment.
>> I think it implies that a volatile variable is not read twice.
>
> Twice? This is about whether an assignment to a volatile variable reads
> it *once* or not at all. I don't think anybody has claimed that it reads
> is twice.

Excuse me... I had in mind the case of i = i + 1 where i is a volatile
variable. :)

>
>> Note that this is different from C++ where assignments are lvalues
>> which makes
>>
>> int a,b,c=0;
>> a=b=c;
>>
>> Well-defined in C but undefined in C++ (I think it's a C++ standard
>> defect but fortunately not a C defect).
>
> It's undefined in C++? Why?
>

This has even been mentioned in a C++ DR (DR #222).
From http://std.dkuug.dk/JTC1/SC22/WG21/docs/cwg_active.html#222:
> One could argue that as the C++ standard currently stands, the effect of x
> = y = 0; is undefined. The reason is that it both fetches and stores the
> value of y, and does not fetch the value of y in order to compute its new
> value.

This DR also deals with volatile variable in assignments... In the context
of C++.

The standard doesn't specify that all "reads" are due to lvalue-to-rvalue
conversions, but I think one can state that all lvalue-to-rvalue conversions
count as "reads".
In C++, x = y = 0; makes a lvalue-to-rvalue conversion of the expression (y
= 0), and thus, "reads" the y object. This read is not done to compute its
new value. This is UB.

In C, there's nothing y=0 is a rvalue, and there's nothing stating the value
is read after the assignment (so, a fetch is either "unspecified" or
forbidden).

n1124> An assignment expression has the value of the left operand after the
assignment, but is not an lvalue.

I was curious enough to test existing practice.

#include <stdio.h>
volatile int x,y;
int main(void) {
printf("hello");
x=y=0;
printf("hello");
}

(The printf statements are useful as delimiters around the relevant compiled
code).

GCC on GNU/Linux/i386 fetches y, in both C99 and C++98 modes.
TCC on GNU/Linux/i386 doesn't fetch y.

Consequently, existing behavior differs between C99 implementations. I think
that's bad. It may be due to the ambiguous/defective standard wording, or a
GCC bug, perhaps because GCC uses the same back-end for C and C++.

== 2 of 5 ==
Date: Tues, Jan 26 2010 7:32 am
From: "Christopher Dearlove"

"André Gillibert" <MetaEntropyRemoveThis@gmail.com> wrote in message
news:hjmq99$jrv$1@news.eternal-september.org...
>
> "Wojtek Lerch" <wojtek_l@yahoo.ca> a écrit dans le message de news:
> 7s5sgeFjbkU1@mid.individual.net...
>> André Gillibert wrote:
>>> Note that this is different from C++ where assignments are lvalues
>>> which makes
>>>
>>> int a,b,c=0;
>>> a=b=c;
>>>
>>> Well-defined in C but undefined in C++ (I think it's a C++ standard
>>> defect but fortunately not a C defect).
>>
>> It's undefined in C++? Why?
>>
> This has even been mentioned in a C++ DR (DR #222).
> From http://std.dkuug.dk/JTC1/SC22/WG21/docs/cwg_active.html#222:
>> One could argue that as the C++ standard currently stands, the effect of
>> x = y = 0; is undefined. The reason is that it both fetches and stores
>> the value of y, and does not fetch the value of y in order to compute its
>> new value.

It's a long way from "One could argue" in 1999 to "undefined in C++"
in 2010, given that there's been a standard update in 2003 where had
it been seriously thought there was a problem it could have been fixed.
(I'm referring to the non-volatile case.)

== 3 of 5 ==
Date: Tues, Jan 26 2010 8:11 am
From: "Wojtek Lerch"

"André Gillibert" <MetaEntropyRemoveThis@gmail.com> wrote in message
news:hjmq99$jrv$1@news.eternal-september.org...
>
> "Wojtek Lerch" <wojtek_l@yahoo.ca> a écrit dans le message de news:
> 7s5sgeFjbkU1@mid.individual.net...
>> André Gillibert wrote:
>>> "Wojtek Lerch" <wojtek_l@yahoo.ca> wrote:
>>>>... I've always believed that an assignment operator returns the value
>>>>that it also stores in the object, *without* reading it back from the
>>>>object, and that the Standard's description in terms of "the value of
>>>>the
>>>>object after the assignment" was just a clumsy wording (no offense) that
>>>>wasn't meant to imply a read access.
>>>
>>> I agree.
>>> I think a "read" access to an object involves a lvalue-to-value
>>> conversion (6.3.2.1-1), even though that's not clearly stated.
>>
>> It's the other way around: a lvalue-to-value conversion involves a read
>> access, but that doesn't mean that every read access is part of an
>> lvalue-to-value conversion.
>
> Indeed, you're right.
> However, the standard doesn't specify where there are no read access...
> e.g.
>
> int y=0;
> volatile int x;
> x=y;
>
> The standard doesn't specify if y is to be read 153 times or only once.

The standard doesn't say that y is read; it says that the lvalue expression
"y", in a context such as the above, is converted to the value stored in the
designated object. A read access is only implied, not stated explicitly;
but it seems to be clear enough that the conversion is done by a single read
access to the object.

The standard also says that the value of the expression "x=y" is the value
of the object after the assignment. Whether those words also imply a read
access to x or not is much less clear, at least to some of us, and that's
what we were debating here.

>>> Note that this is different from C++ where assignments are lvalues
>>> which makes
>>>
>>> int a,b,c=0;
>>> a=b=c;
>>>
>>> Well-defined in C but undefined in C++ (I think it's a C++ standard
>>> defect but fortunately not a C defect).
>>
>> It's undefined in C++? Why?
>>
>
> This has even been mentioned in a C++ DR (DR #222).
> From http://std.dkuug.dk/JTC1/SC22/WG21/docs/cwg_active.html#222:

That's interesting reading. Thanks for the pointer.

>> One could argue that as the C++ standard currently stands, the effect of
>> x = y = 0; is undefined. The reason is that it both fetches and stores
>> the value of y, and does not fetch the value of y in order to compute its
>> new value.

But the C++ standard, just like the C standard, only forbids fetching the
*prior* value for purposes other than to compute the nev value. I think
you'll agree that people who write things like x=y=0 expect the *new* value
of y to be stored in x, not the old value -- but indeed, it seems that the
C++ standard does not guarantee that clearly enough.

== 4 of 5 ==
Date: Tues, Jan 26 2010 8:38 am
From: "Andr� Gillibert"

"Christopher Dearlove" <chris.dearlove@baesystems.com> a �crit dans le
message de news: 4b5f0acf$1_1@glkas0286.greenlnk.net...
> "Andr� Gillibert" <MetaEntropyRemoveThis@gmail.com> wrote in message
> news:hjmq99$jrv$1@news.eternal-september.org...
>>
>> "Wojtek Lerch" <wojtek_l@yahoo.ca> a �crit dans le message de news:
>> 7s5sgeFjbkU1@mid.individual.net...
>>> Andr� Gillibert wrote:
>>>> Note that this is different from C++ where assignments are lvalues
>>>> which makes
>>>>
>>>> int a,b,c=0;
>>>> a=b=c;
>>>>
>>>> Well-defined in C but undefined in C++ (I think it's a C++ standard
>>>> defect but fortunately not a C defect).
>>>
>>> It's undefined in C++? Why?
>>>
>> This has even been mentioned in a C++ DR (DR #222).
>> From http://std.dkuug.dk/JTC1/SC22/WG21/docs/cwg_active.html#222:
>>> One could argue that as the C++ standard currently stands, the effect of
>>> x = y = 0; is undefined. The reason is that it both fetches and stores
>>> the value of y, and does not fetch the value of y in order to compute
>>> its new value.
>
> It's a long way from "One could argue" in 1999 to "undefined in C++"
> in 2010, given that there's been a standard update in 2003 where had
> it been seriously thought there was a problem it could have been fixed.
> (I'm referring to the non-volatile case.)

That's undefined in C++03, but, the new sequencing rules introduced in 2008
(Oxford) fix this issue. C++1x will include these new rules.

== 5 of 5 ==
Date: Tues, Jan 26 2010 8:55 am
From: "André Gillibert"

"Wojtek Lerch" <wojtek_l@yahoo.ca> a écrit dans le message de news:
7s8igsF1jvU1@mid.individual.net...
> "André Gillibert" <MetaEntropyRemoveThis@gmail.com> wrote in message
> news:hjmq99$jrv$1@news.eternal-september.org...
>>
>> "Wojtek Lerch" <wojtek_l@yahoo.ca> a écrit dans le message de news:
>> 7s5sgeFjbkU1@mid.individual.net...
>>> André Gillibert wrote:
>>>> "Wojtek Lerch" <wojtek_l@yahoo.ca> wrote:
>>>>>... I've always believed that an assignment operator returns the value
>>>>>that it also stores in the object, *without* reading it back from the
>>>>>object, and that the Standard's description in terms of "the value of
>>>>>the
>>>>>object after the assignment" was just a clumsy wording (no offense)
>>>>>that
>>>>>wasn't meant to imply a read access.
>>>>
>>>> I agree.
>>>> I think a "read" access to an object involves a lvalue-to-value
>>>> conversion (6.3.2.1-1), even though that's not clearly stated.
>>>
>>> It's the other way around: a lvalue-to-value conversion involves a read
>>> access, but that doesn't mean that every read access is part of an
>>> lvalue-to-value conversion.
>>
>> Indeed, you're right.
>> However, the standard doesn't specify where there are no read access...
>> e.g.
>>
>> int y=0;
>> volatile int x;
>> x=y;
>>
>> The standard doesn't specify if y is to be read 153 times or only once.
>
> The standard doesn't say that y is read; it says that the lvalue
> expression "y", in a context such as the above, is converted to the value
> stored in the designated object. A read access is only implied, not
> stated explicitly; but it seems to be clear enough that the conversion is
> done by a single read access to the object.
>
> The standard also says that the value of the expression "x=y" is the value
> of the object after the assignment. Whether those words also imply a read
> access to x or not is much less clear, at least to some of us, and that's
> what we were debating here.
>
>>>> Note that this is different from C++ where assignments are lvalues
>>>> which makes
>>>>
>>>> int a,b,c=0;
>>>> a=b=c;
>>>>
>>>> Well-defined in C but undefined in C++ (I think it's a C++ standard
>>>> defect but fortunately not a C defect).
>>>
>>> It's undefined in C++? Why?
>>>
>>
>> This has even been mentioned in a C++ DR (DR #222).
>> From http://std.dkuug.dk/JTC1/SC22/WG21/docs/cwg_active.html#222:
>
> That's interesting reading. Thanks for the pointer.
>
>>> One could argue that as the C++ standard currently stands, the effect of
>>> x = y = 0; is undefined. The reason is that it both fetches and stores
>>> the value of y, and does not fetch the value of y in order to compute
>>> its new value.
>
> But the C++ standard, just like the C standard, only forbids fetching the
> *prior* value for purposes other than to compute the nev value.

Ok.

:Between the previous and next sequence point an object shall have its
stored value
:modified at most once by the evaluation of an expression. Furthermore, the
prior value
:shall be read only to determine the value to be stored.71

The glitch is that, the assignment y = 0 may take effect (side effect) after
the y value is fetched (in C++03) for the x= assignment.
: the order of evaluation of subexpressions and the order in which side
effects take place are both unspecified.

> I think you'll agree that people who write things like x=y=0 expect the
> *new* value of y to be stored in x, not the old value --

But, a C++03 implementation might give the old value....
In C++03, x=y=0 is equivalent to (y=0,x=y), but, without the sequence point
of the comma...
If x and y are numeric, it's equivalent to (y=0)+(x=y).

> but indeed, it seems that the C++ standard does not guarantee that
> clearly enough.
>

Anyway, this is an old issue that C never had and C++1x fixes.

--
André Gillibert

==============================================================================
TOPIC: Experiment: functional concepts in C
http://groups.google.com/group/comp.lang.c/t/7889fc59043eb32b?hl=en
==============================================================================

== 1 of 2 ==
Date: Tues, Jan 26 2010 5:51 am
From: "bartc"

"Rob Kendrick" <nntp@rjek.com> wrote in message
news:20100126094754.103df758@trite.i.flarn.net.i.flarn.net...
> On Tue, 26 Jan 2010 07:26:49 +0100
> jacob navia <jacob@nospam.org> wrote:
>
>> Your argument that "it is not part of the text of the standard"
>> is just ridiculous. The "C" of the standard is not even able to
>> use a directory effectively and there is NO serious software in C
>> that uses that minimal subset.
>
> You've heard of Lua, yeah? http://www.lua.org/ It's a very serious
> piece of software; one of the fastest scripting languages around.

Is it? Just downloaded a copy (5.1.4); only two of the examples provided had
any meaning to me:

FIB.LUA: Fib(36): about 14 seconds (Python: 16 secs, Ruby 8 secs; my own
interpreted language: 1.5 secs)

FACTORIAL.LUA: modified to calculate 12! ten million times: ~250 secs. After
getting rid of some fancy function handling (under the comment 'function
closures are powerful'), and using straight recursion: ~25 secs (my lang:
2.6 secs).

Perhaps it's weak on recursion, but then: "i=0; while i<100000000 do i=i+1
end " took ~12 secs (my lang: 0.6 secs)

Just a brief test of course and perhaps I missed out some essential switch
such as /FAST...(I've heard of something called LuaJIT, I doubt this is it
though)

> And
> written entirely in ANSI C with only a handful of concessions (such as
> dlopen to allow for extensions).

I don't use straight ANSI C...

> It's quite easy to write great, reusable, reliable software components
> in ANSI C without reaching for OS-specific extensions.

For interpreter projects, which are really speed critical, I just use
whatever is necessary for performance.

If Lua likes to distribute itself as source code, then I can see some of the
point of restricting itself to a language subset which will compile anywhere
(but I used a binary download, where there shouldn't be a problem with
tweaking to each platform).

--
Bartc

== 2 of 2 ==
Date: Tues, Jan 26 2010 6:23 am
From: Rob Kendrick

On Tue, 26 Jan 2010 13:51:32 GMT
"bartc" <bartc@freeuk.com> wrote:

>
> "Rob Kendrick" <nntp@rjek.com> wrote in message
> news:20100126094754.103df758@trite.i.flarn.net.i.flarn.net...
> > On Tue, 26 Jan 2010 07:26:49 +0100
> > jacob navia <jacob@nospam.org> wrote:
> >
> >> Your argument that "it is not part of the text of the standard"
> >> is just ridiculous. The "C" of the standard is not even able to
> >> use a directory effectively and there is NO serious software in C
> >> that uses that minimal subset.
> >
> > You've heard of Lua, yeah? http://www.lua.org/ It's a very serious
> > piece of software; one of the fastest scripting languages around.
>
> Is it? Just downloaded a copy (5.1.4); only two of the examples
> provided had any meaning to me:

The included things are tests, and not optimal examples. Try the
examples on the alioth shootout:

http://shootout.alioth.debian.org/

Note the comparisons to Python and Ruby. The mandelbrot one's
especially amusing: the single-threaded Lua implementation is faster
than the multi-threaded Perl one that's using four CPUs.

B.

==============================================================================
TOPIC: problems with logic operations within loops
http://groups.google.com/group/comp.lang.c/t/9228b4a6f1c5f9e3?hl=en
==============================================================================

== 1 of 9 ==
Date: Tues, Jan 26 2010 7:29 am
From: Interrupt

Hi folks I'm working though some exercise trying to teach myself C,
I'm having problem with a function I've written. It takes and array
and removes the white spaces. I'm having problems with logic
operations within loops.

My first problem is once If statement executes and "i" is incremented
the else statement doesn't execute again!! WHY???
*****************************CODE********************************************

/* copy: copy 'from' into 'to'removing white space */
void copy(char to[], char from[], int maxi)
{
int i;

for(i=0;i<=maxi;++i)
{
if(from[i]==' ' || from[i]=='\0' || from[i]=='\t'|| from[i]
=='\n')
{
to[i] = from[i+1]; // if there is white space copy
the next value
i++; //>>>>>>>>>>>>>>>>>>>> problems start here
}

else
{
to[i] = from[i]; // if no white space copy
}
}

}
********************************CODE******************************************

So I thought I'd approach the problem from the opposite angle if it's
not white space, but the if statement executes whether there is white
space or not…..WHY???

********************************CODE2*****************************************
/* copy: copy 'from' into 'to'removing white space */
void copy(char to[], char from[], int maxi)
{
int i;

for(i=0;i<=maxi;++i)
{
if(from[i]!=' '||from[i]!='\0'||from[i]!='\t'||from[i]!='\n')
>>>>>>>>executes whether there is white space or not
{
to[i] = from[i]; // if no white space
copy
}

else
{
to[i] = from[i+1]; // if there is white space copy the
next value
i++;
}
}

}
**************************************CODE2*************************************

== 2 of 9 ==
Date: Tues, Jan 26 2010 7:40 am
From: Andrew Poelstra

On 2010-01-26, Interrupt <neildavy14@yahoo.co.uk> wrote:
> Hi folks I?m working though some exercise trying to teach myself C,
> I?m having problem with a function I?ve written. It takes and array
> and removes the white spaces. I?m having problems with logic
> operations within loops.
>
> My first problem is once If statement executes and ?i? is incremented
> the else statement doesn?t execute again!! WHY???
> *****************************CODE********************************************
>
> /* copy: copy 'from' into 'to'removing white space */
> void copy(char to[], char from[], int maxi)
> {
> int i;
>
> for(i=0;i<=maxi;++i)

You almost certainly do not want <= here. Think about how
arrays are indexed in C.

> {
> if(from[i]==' ' || from[i]=='\0' || from[i]=='\t'|| from[i]
>=='\n')

#include <ctype.h>
...and use isspace() instead.

> {
> to[i] = from[i+1]; // if there is white space copy
> the next value

You can't use // comments in most C compilers today, and even
if you could you shouldn't on Usenet because they wrap around
like this and then nobody can compile your code.

Also, how do you know i + 1 is a valid index into from?

> i++; //>>>>>>>>>>>>>>>>>>>> problems start here

You can't use the same index into to[] and from[], if you
expect to be referencing different offsets in each array.

> }
>
> else
> {
> to[i] = from[i]; // if no white space copy
> }
> }
>
> }
> ************************CODE**********************************
>
> So I thought I?d approach the problem from the opposite angle if it?s
> not white space, but the if statement executes whether there is white
> space or not?..WHY???
>
> ************************CODE2*********************************
> /* copy: copy 'from' into 'to'removing white space */
> void copy(char to[], char from[], int maxi)
> {
> int i;
>
> for(i=0;i<=maxi;++i)
> {
> if(from[i]!=' '||from[i]!='\0'||from[i]!='\t'||from[i]!='\n')
>>>>>>>>>executes whether there is white space or not

Of course. When do you expect that (X != 1 || X != 2) will be false?
Perhaps if you would space your code decently it would be clearer.

> {
> to[i] = from[i]; // if no white space
> copy
> }
>
> else
> {
> to[i] = from[i+1]; // if there is white space copy the
> next value
> i++;

...and you still haven't fixed the original problem.

> }
> }
>
> }
> ******************************CODE2*****************************
>

nb I have removed sixteen stars from each of these lines.

== 3 of 9 ==
Date: Tues, Jan 26 2010 7:49 am
From: Tom St Denis

On Jan 26, 10:40 am, Andrew Poelstra <apoels...@localhost.localdomain>
wrote:
> You can't use // comments in most C compilers today, and even
> if you could you shouldn't on Usenet because they wrap around
> like this and then nobody can compile your code.

Um what? // are standard in C99 aren't they? GCC certainly will
accept them except when in -ansi mode. Though yes, it's good to use /
* */ instead, mostly for backwards compatibility but also to avoid
wrapping.

Tom

== 4 of 9 ==
Date: Tues, Jan 26 2010 7:53 am
From: Andrew Poelstra

On 2010-01-26, Tom St Denis <tom@iahu.ca> wrote:
> On Jan 26, 10:40 am, Andrew Poelstra <apoels...@localhost.localdomain>
> wrote:
>> You can't use // comments in most C compilers today, and even
>> if you could you shouldn't on Usenet because they wrap around
>> like this and then nobody can compile your code.
>
> Um what? // are standard in C99 aren't they? GCC certainly will
> accept them except when in -ansi mode. Though yes, it's good to use /
> * */ instead, mostly for backwards compatibility but also to avoid
> wrapping.
>
> Tom

They are standard in C99, but gcc is not standard in C99 mode ;)

(It is close enough for most purposes, though. I perhaps should
have been clearer.)

== 5 of 9 ==
Date: Tues, Jan 26 2010 8:04 am
From: "paul"

One problem with ***CODE*** is that when the if statement executes,
i++ increments i, then at the end of the for loop, it is incremented
again (by the loop). This skips a char in the 'to' buffer.

I suggest re-writing this to use a while loop. It won't fix your problem,
but it will make it more obvious. This is just one of the reasons
that changing a loop variable (i) within the loop is considered bad
practice.

Paul.

== 6 of 9 ==
Date: Tues, Jan 26 2010 8:15 am
From: raltbos@xs4all.nl (Richard Bos)

Andrew Poelstra <apoelstra@localhost.localdomain> wrote:

> > to[i] = from[i+1]; // if there is white space copy
> > the next value
>
> You can't use // comments in most C compilers today,

Wrong (and it was wrong in many cases even before C99 made them
official), but...

> and even if you could you shouldn't on Usenet because they wrap around
> like this and then nobody can compile your code.

...right, as demonstrated.

Richard

== 7 of 9 ==
Date: Tues, Jan 26 2010 8:49 am
From: Tim Streater

On 26/01/2010 15:29, Interrupt wrote:
> Hi folks I�m working though some exercise trying to teach myself C,
> I�m having problem with a function I�ve written. It takes and array
> and removes the white spaces. I�m having problems with logic
> operations within loops.

If you use a "for" loop for this, it should look like:

for (i=0; i<maxi; i++)

Are you processing the whole string? If so then a "while" loop would be
better, with your test being about whether the current character is a null.

More importantly, you need to have a pointer moving along the input
string, and another moving along the output string. These can't be the
same pointer as they don't move along at the same rate necessarily (in
general they won't).

So it might be something like:

j = 0;
for (i=0; i<maxi; i++)
{
ch = from[i];
if (isspace(ch)==true) continue;
to[j] = ch;
j++;
}

--
Tim

"That excessive bail ought not to be required, nor excessive fines
imposed, nor cruel and unusual punishments inflicted"

Bill of Rights 1689

== 8 of 9 ==
Date: Tues, Jan 26 2010 8:54 am
From: Tom St Denis

On Jan 26, 10:53 am, Andrew Poelstra <apoels...@localhost.localdomain>
wrote:
> On 2010-01-26, Tom St Denis <t...@iahu.ca> wrote:
>
> > On Jan 26, 10:40 am, Andrew Poelstra <apoels...@localhost.localdomain>
> > wrote:
> >> You can't use // comments in most C compilers today, and even
> >> if you could you shouldn't on Usenet because they wrap around
> >> like this and then nobody can compile your code.
>
> > Um what?  // are standard in C99 aren't they?  GCC certainly will
> > accept them except when in -ansi mode.  Though yes, it's good to use /
> > * */ instead, mostly for backwards compatibility but also to avoid
> > wrapping.
>
> > Tom
>
> They are standard in C99, but gcc is not standard in C99 mode ;)
>
> (It is close enough for most purposes, though. I perhaps should
>  have been clearer.)

My point is GCC [and other compilers] silently accepted // by
default. You can only get gcc to whine about it when you enter ANSI
mode [e.g. C89/C90].

Though the rest of your point stands, C developers should use /**/ by
default.

Tom

== 9 of 9 ==
Date: Tues, Jan 26 2010 9:00 am
From: Richard Heathfield

Tom St Denis wrote:
> On Jan 26, 10:40 am, Andrew Poelstra <apoels...@localhost.localdomain>
> wrote:
>> You can't use // comments in most C compilers today, and even
>> if you could you shouldn't on Usenet because they wrap around
>> like this and then nobody can compile your code.
>
> Um what? // are standard in C99 aren't they?

Yes. Most C compilers, however, are not C99 compilers.

> GCC

is not "most compilers". It's *one* compiler.

> certainly will
> accept them except when in -ansi mode.

i.e. if you switch off conformance, which isn't always desirable. (For
me, it's almost never desirable.)

> Though yes, it's good to use /
> * */ instead,

Instead of /
* */, I recommend /* */ :-)

> mostly for backwards compatibility but also to avoid
> wrapping.

I think of it as "maximum portability" rather than "backward
compatibility", but yes.

--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
"Usenet is a strange place" - dmr 29 July 1999
Sig line vacant - apply within

==============================================================================
TOPIC: Getting the size of a C function
http://groups.google.com/group/comp.lang.c/t/dcc5cb3c26da8f6f?hl=en
==============================================================================

== 1 of 1 ==
Date: Tues, Jan 26 2010 8:45 am
From: David Kelly

On 1/25/10 4:23 PM, Grant Edwards wrote:
> On 2010-01-25, David Kelly<n4hhe@Yahoo.com> wrote:

[...]

>> If the function is not linked to the RAM run address then it
>> probably won't work.
>>
>> Did this a year or so ago with Metrowerks and an HC12 but
>> don't remember quite how. It wasn't terribly hard once one
>> knows what is needed. The linker properly generated constant
>> "variables" containing start and end addresses for me. Quite
>> properly it would not generate the runtime code for moving the
>> image from FLASH to RAM as this code was not intended to
>> permanently reside in RAM.
>
> You've also got to be careful in RAM-resident routine not to
> write any code that generates library calls. On a 16-bit CPU,
> doing long arithmetic will likely generate a library call, so
> be mindful of which integer types you use.

Yes, lots of manual attention and review is needed as the code which is
to be relocated to RAM can not depend on anything else. Most compilers
and linkers will happily use any variable or routine elsewhere in the
project.

Would be a good idea to reset the stack pointer at the start of the RAM
code. Globally disable interrupts too as sometimes its hard to
individually disable every single interrupt source on an MCU. Also do
not forget the interrupt vector table (or whatever means is used to
route interrupt service routines).

==============================================================================

You received this message because you are subscribed to the Google Groups "comp.lang.c"
group.

To post to this group, visit http://groups.google.com/group/comp.lang.c?hl=en

To unsubscribe from this group, send email to comp.lang.c+unsubscribe@googlegroups.com

To change the way you get mail from this group, visit:
http://groups.google.com/group/comp.lang.c/subscribe?hl=en

To report abuse, send email explaining the problem to abuse@googlegroups.com

==============================================================================
Google Groups: http://groups.google.com/?hl=en