f



How to convert Infix notation to postfix notation

i have a string as (a+b)+8-(c/d) in Infix form.

how can i convert it to postfix form using C language,,,????


0
etameem (4)
10/26/2009 4:33:57 AM
comp.lang.c 30657 articles. 4 followers. spinoza1111 (3246) is leader. Post Follow

571 Replies
3091 Views

Similar Articles

[PageSpeed] 12

On Oct 26, 12:33=A0pm, Tameem <etam...@gmail.com> wrote:
> i have a string as (a+b)+8-(c/d) in Infix form.
>
> how can i convert it to postfix form using C language,,,????

I will assume that that string is not the ONLY string you have to
convert. If it is, then the answer is

int main()
{
printf("ab+8+cd/-\n");
}

Each one of the following productions should be written as a separate
C function.

expression -> additionFactor [ "+"|"-" expression ]
additionFactor -> multiplicationFactor [ "*"|"/" expression ]
multiplicationFactor -> term
term -> LETTER | NUMBER | "(" expression ")" // Rightmost must balance

Write code using the above "productions" that emits postfix code. For
each production write one C function. I won't write C for you because
I don't like C, I suck at it through disuse consequent on my dislike,
and it's your homework assignment, not mine.

"->" means "consists of the following material left to right"

"|" means "or"

Lower case and camelCase words are grammar categories that will
correspond to procedures in YOUR code

Upper case words are lexemes recognised by C code

Quoted material occurs as is.

Material in square brackets is optional. An expression could be just
an additionFactor. In turn an additionFactor can be just a
multiplicationFactor and a multiplication factor a number. Therefore,
"3" is an expression.

When you parse a "term" as "(" expression ")" you must look ahead in
the overall algorithm I shall give you to find, not the first right
parenthesis, but the one that actually balances the left parenthesis.
To do this, maintain a counter. Increment it by one for each left
parenthesis the lookahead sees: decrement it by one for each right
parenthesis. When you see right parenthesis and the counter goes to
zero, you have found the right parenthesis.

OK, here's the untested and uncompiled C Sharp like pseudo code for
"expression": convert it to C:

string expressionMain(string strInstring)
{
int intIndex1 =3D 0;
string strPolish =3D "";
return expression(strInstring, ref intIndex1, ref strPolish);
}
string expression(string strInstring, ref int intIndex1, ref string
strPolish)
{
if (!additionFactor(string strInstring,
                    ref intIndex1,
                    ref strPolish)) return "Not valid";
if (strInstring[intIndex]=3D=3D'+' || strInstring[intIndex]=3D=3D'-')
{
    int intIndexSave =3D intIndex1; intIndex1++;
    if (expression(strInstring, ref intIndex1, ref strPolish))
        strPolish +=3D strInstring[intIndexSave];
    else return("Not valid");
}
return strPolish;
}

C Sharp idioms: ref followed by type in a formal parameter list in a
function decl is like using asterisk in front of a parameter in C. It
means that the parameter is passed by reference. In C Sharp, a very
cool language, you must ALWAYS use the keyword ref in the "actual
parameters" passed when you call the function just so you know what
the hell you are doing, as opposed to C which likes to fool you.

Chapter 3 of my book Build Your Own .Net and Compiler (Edward G.
Nilges, Apress May 2004) provides a complete solution for this
homework but in Visual Basic .Net. Therefore this is not a commercial
promotion. If you find my book useful, buy it, check it out of the
library, or steal it.
0
spinoza1111 (3246)
10/26/2009 6:30:28 AM
Tameem wrote:

> i have a string as (a+b)+8-(c/d) in Infix form.
> 
> how can i convert it to postfix form using C language,,,????

This has very little to do with the /language/ C, i.e., there's
no "built-in" way to accomplish this conversion.  However, it's
of course possible to implement such a converter in C, e.g., by
writing a recursive-descent parser (for a good deal of details,
see <http://en.wikipedia.org/wiki/Operator-precedence_parser>).

You might also want to take a look at the GNU assembler (gas,
which is part of the GNU binutils package), which implements
such a recursive-descent parser to evaluate constant expressions.


mike

0
misc_ (22)
10/26/2009 11:29:40 AM
On Oct 26, 12:33=A0am, Tameem <etam...@gmail.com> wrote:
> i have a string as (a+b)+8-(c/d) in Infix form.
>
> how can i convert it to postfix form using C language,,,????

It this homework?
0
gene.ressler (563)
10/26/2009 12:09:29 PM
spinoza1111 <spinoza1111@yahoo.com> writes:

> On Oct 26, 12:33 pm, Tameem <etam...@gmail.com> wrote:
>> i have a string as (a+b)+8-(c/d) in Infix form.
>>
>> how can i convert it to postfix form using C language,,,????
>
> I will assume that that string is not the ONLY string you have to
> convert. If it is, then the answer is
>
> int main()
> {
> printf("ab+8+cd/-\n");
> }
>
> Each one of the following productions should be written as a separate
> C function.
>
> expression -> additionFactor [ "+"|"-" expression ]
> additionFactor -> multiplicationFactor [ "*"|"/" expression ]
> multiplicationFactor -> term
> term -> LETTER | NUMBER | "(" expression ")" // Rightmost must balance

This is not the usual grammar for expressions and is poor advice for
someone learning this stuff.

> Write code using the above "productions" that emits postfix code.

To the OP: please don't; Spinoza1111 is leading you astray.  Post in a
group about programming (comp.programming is a good one) for better
advice on how to go about this.  Also, if this is homework/coursework,
be open about that and explain how far you have been able to get on
your own.

<snip off-topic C#>
-- 
Ben.
0
ben.usenet (6790)
10/26/2009 12:20:09 PM
On Oct 26, 8:20=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> spinoza1111<spinoza1...@yahoo.com> writes:
> > On Oct 26, 12:33=A0pm, Tameem <etam...@gmail.com> wrote:
> >> i have a string as (a+b)+8-(c/d) in Infix form.
>
> >> how can i convert it to postfix form using C language,,,????
>
> > I will assume that that string is not the ONLY string you have to
> > convert. If it is, then the answer is
>
> > int main()
> > {
> > printf("ab+8+cd/-\n");
> > }
>
> > Each one of the following productions should be written as a separate
> > C function.
>
> > expression -> additionFactor [ "+"|"-" expression ]
> > additionFactor -> multiplicationFactor [ "*"|"/" expression ]
> > multiplicationFactor -> term
> > term -> LETTER | NUMBER | "(" expression ")" // Rightmost must balance
>
> This is not the usual grammar for expressions and is poor advice for
> someone learning this stuff.
>
> > Write code using the above "productions" that emits postfix code.
>
> To the OP: please don't;Spinoza1111is leading you astray. =A0Post in a

Ben, please indicate the errors and don't imitate Seebach by
discussing personalities instead of ideas. As it is, you sound like a
fundamentalist *imam*.

> group about programming (comp.programming is a good one) for better
> advice on how to go about this. =A0Also, if this is homework/coursework,
> be open about that and explain how far you have been able to get on
> your own.
>
> <snip off-topic C#>
> --
> Ben.- Hide quoted text -
>
> - Show quoted text -

0
spinoza1111 (3246)
10/27/2009 2:49:56 AM
On Oct 26, 8:20=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> spinoza1111<spinoza1...@yahoo.com> writes:
> > On Oct 26, 12:33=A0pm, Tameem <etam...@gmail.com> wrote:
> >> i have a string as (a+b)+8-(c/d) in Infix form.
>
> >> how can i convert it to postfix form using C language,,,????
>
> > I will assume that that string is not the ONLY string you have to
> > convert. If it is, then the answer is
>
> > int main()
> > {
> > printf("ab+8+cd/-\n");
> > }
>
> > Each one of the following productions should be written as a separate
> > C function.
>
> > expression -> additionFactor [ "+"|"-" expression ]
> > additionFactor -> multiplicationFactor [ "*"|"/" expression ]
> > multiplicationFactor -> term
> > term -> LETTER | NUMBER | "(" expression ")" // Rightmost must balance
>
> This is not the usual grammar for expressions and is poor advice for
> someone learning this stuff.
>
> > Write code using the above "productions" that emits postfix code.
>
> To the OP: please don't;Spinoza1111is leading you astray. =A0Post in a

I would have thought given your technical capabilities that you would
be able, instead of engaging in Fox news style politics of personal
destruction, to identify all flaws in my approach, whether in the
formal grammar of C# pseudo code.

If you cannot, I need an apology from you. NOW, punk.

> group about programming (comp.programming is a good one) for better
> advice on how to go about this. =A0Also, if this is homework/coursework,
> be open about that and explain how far you have been able to get on
> your own.
>
> <snip off-topic C#>

C# is what C should be. As I indicated, C Sharp was used as pseudocode
because it is probably a homework assignment and the OP needs to do
this homework. The OP probably received poor algorithm guidance from
the teacher, especially if the teacher was like most people here.
> --
> Ben.- Hide quoted text -
>
> - Show quoted text -

0
spinoza1111 (3246)
10/27/2009 2:54:06 AM
spinoza1111 <spinoza1111@yahoo.com> writes:

> On Oct 26, 8:20 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> spinoza1111<spinoza1...@yahoo.com> writes:
<snip>
>> > expression -> additionFactor [ "+"|"-" expression ]
>> > additionFactor -> multiplicationFactor [ "*"|"/" expression ]
>> > multiplicationFactor -> term
>> > term -> LETTER | NUMBER | "(" expression ")" // Rightmost must balance
>>
>> This is not the usual grammar for expressions and is poor advice for
>> someone learning this stuff.
>>
>> > Write code using the above "productions" that emits postfix code.
>>
>> To the OP: please don't;Spinoza1111is leading you astray.  Post in a

[The formatting errors in the above were added by you.  My typing is
bad, but not /that/ bad.]

> I would have thought given your technical capabilities that you would
> be able, instead of engaging in Fox news style politics of personal
> destruction, to identify all flaws in my approach, whether in the
> formal grammar of C# pseudo code.

It's not topical here.  There must be lots of groups where you can get
advice on writing a grammar for simple expressions, but I don't know,
off hand, where would be the best place.  I suggested comp.programming
to the OP, but that is probably not the best place for your question.

> If you cannot, I need an apology from you. NOW, punk.

That's OK then.

<snip>
-- 
Ben.
0
ben.usenet (6790)
10/27/2009 3:15:39 AM
On Oct 27, 11:15=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> spinoza1111<spinoza1...@yahoo.com> writes:
> > On Oct 26, 8:20=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >>spinoza1111<spinoza1...@yahoo.com> writes:
> <snip>
> >> > expression -> additionFactor [ "+"|"-" expression ]
> >> > additionFactor -> multiplicationFactor [ "*"|"/" expression ]
> >> > multiplicationFactor -> term
> >> > term -> LETTER | NUMBER | "(" expression ")" // Rightmost must balan=
ce
>
> >> This is not the usual grammar for expressions and is poor advice for
> >> someone learning this stuff.

You have not shown that it is INCORRECT. It's possible that the
"usual" grammar is incorrect (as in the case of left recursion) given
Gresham's Law that 99% of everything is crap. You need to show that
the grammar is either actually incorrect or not suitable for manual
interpretation, and I do not, personally think you qualified to do so.
This takes experience in writing an actual parser by hand.

In the first production it is obvious that on return from
additionFactor(), the parser can advance the index, and check it for
greater than end. If the index is past the end, we're done. If it is
not, the parser can check either for a plus or a minus.

If either character occurs the parser then calls itself with a source
string that is necessarily smaller guaranteeing the safety of the
recursion. But, there must be an expression when there is an operator.

Disprove this informal logic and desist the Fox news crap, please.
>
> >> > Write code using the above "productions" that emits postfix code.
>
> >> To the OP: please don't;Spinoza1111is leading you astray. =A0Post in a
>
> [The formatting errors in the above were added by you. =A0My typing is
> bad, but not /that/ bad.]
>
> > I would have thought given your technical capabilities that you would
> > be able, instead of engaging in Fox news style politics of personal
> > destruction, to identify all flaws in my approach, whether in the
> > formal grammar of C# pseudo code.
>
> It's not topical here. =A0There must be lots of groups where you can get
> advice on writing a grammar for simple expressions, but I don't know,
> off hand, where would be the best place. =A0I suggested comp.programming
> to the OP, but that is probably not the best place for your question.

His goal is to write a C program, but we don't want to give him the
homework solution. It appears that his instructor in fact knows about
as much as you about writing a recursive descent parser by hand.
Therefore he's in the right place.
>
> > If you cannot, I need an apology from you. NOW, punk.
>
> That's OK then.
>
> <snip>
> --
> Ben.

0
spinoza1111 (3246)
10/27/2009 6:39:59 AM
spinoza1111 <spinoza1111@yahoo.com> writes:

> On Oct 27, 11:15 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> spinoza1111<spinoza1...@yahoo.com> writes:
>> > On Oct 26, 8:20 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> >>spinoza1111<spinoza1...@yahoo.com> writes:
>> <snip>
>> >> > expression -> additionFactor [ "+"|"-" expression ]
>> >> > additionFactor -> multiplicationFactor [ "*"|"/" expression ]
>> >> > multiplicationFactor -> term
>> >> > term -> LETTER | NUMBER | "(" expression ")" // Rightmost must balance
>>
>> >> This is not the usual grammar for expressions and is poor advice for
>> >> someone learning this stuff.
>
> You have not shown that it is INCORRECT.

No, and I never said it was.  You know where to post if you really
don't know what is wrong with it.  I don't want to be drawn further
into an off topic discussion of grammars here.  Only in a suitable
group will you get the very best advice; and only there would any
criticism be properly checked.  Send me an email (drop the ".usenet"
to get through faster) if you really can't bear to post in a suitable
group, but then neither of us will benefit from third party scrutiny.

Alternatively, feel free to have the last word by calling me
"unqualified" or a "faggot" again.  I grew up gay being called a lot
worse than "unqualified".

<snip>
> You need to show that the grammar is either actually incorrect or
> not suitable for manual interpretation, and I do not, personally
> think you qualified to do so.
<snip>
-- 
Ben.
0
ben.usenet (6790)
10/27/2009 3:49:56 PM
On Oct 25, 11:33=A0pm, Tameem <etam...@gmail.com> wrote:
> i have a string as (a+b)+8-(c/d) in Infix form.
>
> how can i convert it to postfix form using C language,,,????

As others have said, there's no C-specific way of doing this.
However, here are the general steps you'll need to take:

First, you will need to separate the string into distinct *tokens*.
In your example, you have four kinds of tokens -- operators
('+','-','*','/'), separators ('(',')'), constants ('8'), and
identifiers ('a','b','c','d').  Generally, you'll have a set of rules
that determines what characters make up a particular kind of token
(for example, an identifier must start with a letter and consist of
only letters and digits: "a1", "foo", "x", etc.).  As you scan each
character, you'll check against the currently active rule and if it
matches, you'll add it to the token.

There are two ways to go on the next step.  You can either build a
full-blown recursive descent parser (a decent explanation appears on
Wikipedia), or you can use a simple stack-based converter.  For the
stack-based converter, as you read the expression, you'll pass
constants and identifiers straight to output, and you'll push and pop
operators on the stack based on their precedence.  If the operator on
the top of the stack has a lower precedence than the current operator,
then push the current operator.  If the operator on the stack has an
equal or higher precedence than the current operator, then pop the
operator off the stack and write it to output, then push the current
operator on the stack.  lparens are always pushed onto the stack;
rparens cause everything on the stack to be popped to the next
lparen.  Neither lparens nor rparens are written to output.

Given your example, the operations would look something like this:

1.  Read '(', push it onto the stack.  Stack contents =3D {'('}
2.  Read 'a', write it to output.  Output string =3D "a"
3.  Read '+', push it on the stack: {'(', '+'}
4.  Read 'b', write it to output: "a b"
5.  Read ')', pop everything off the stack to the next '(', but don't
write '(' to output.  Output string is "a b +", stack contents =3D {}
6.  Read '+', push it onto the stack: {'+'}
7.  Read '8', write it to output: "a b + 8"
8.  Read '-', has same precedence as '+', so pop '+' from stack, write
it to output, and push '-': "a b + 8 +", {'-'}
9.  Read '(', push it onto the stack: {'-', '('}
10. Read 'c', write it to output: "a b + 8 + c"
11. Read '/', push onto stack: {'-', '(', '/'}
12. Read 'd', write to output: "a b + 8 + c d"
13. Read ')', pop everything to '(': "a b + 8 + c d /", {'-'}
14. End of string, pop remainder of stack: "a b + 8 + c d / -"
0
jfbode1029 (228)
10/27/2009 5:20:46 PM
In article <7365a4ca-3a90-46e4-a4db-062a035f4918@o9g2000prg.googlegroups.com>,
spinoza1111  <spinoza1111@yahoo.com> wrote:
....
>You have not shown that it is INCORRECT. It's possible that the
>"usual" grammar is incorrect (as in the case of left recursion) given
>Gresham's Law that 99% of everything is crap. You need to show that

Quibble.  Sturgeon's law (although the story may be apocryphal and/or
tongue-in-cheek).

Gresham's law says that the bad drives out the good, which is, not
coincidentally, also very true and on display in comp.lang.c

0
gazelle3 (1726)
10/27/2009 8:00:14 PM
On Oct 28, 1:20=A0am, John Bode <jfbode1...@gmail.com> wrote:
> On Oct 25, 11:33=A0pm, Tameem <etam...@gmail.com> wrote:
>
> > i have a string as (a+b)+8-(c/d) in Infix form.
>
> > how can i convert it to postfix form using C language,,,????
>
> As others have said, there's no C-specific way of doing this.
> However, here are the general steps you'll need to take:
>
> First, you will need to separate the string into distinct *tokens*.
> In your example, you have four kinds of tokens -- operators
> ('+','-','*','/'), separators ('(',')'), constants ('8'), and
> identifiers ('a','b','c','d'). =A0Generally, you'll have a set of rules
> that determines what characters make up a particular kind of token
> (for example, an identifier must start with a letter and consist of
> only letters and digits: "a1", "foo", "x", etc.). =A0As you scan each
> character, you'll check against the currently active rule and if it
> matches, you'll add it to the token.

Might be overkill given that the problem statement implies that
symbols are a letter, and scanning non-integer tokens might be beyond
the requirements of the problem...since the OP's teacher hasn't told
him what a number is, and a fully general number recognizer that
recognizes signs, exponents, and decimal points is a project in
itself. Therefore a number is probably an integer, and this can be
recognized by adhoc code. A separate pass for lexical analysis is
probably overkill.
>
> There are two ways to go on the next step. =A0You can either build a
> full-blown recursive descent parser (a decent explanation appears on
> Wikipedia), or you can use a simple stack-based converter. =A0For the
> stack-based converter, as you read the expression, you'll pass
> constants and identifiers straight to output, and you'll push and pop
> operators on the stack based on their precedence. =A0If the operator on
> the top of the stack has a lower precedence than the current operator,
> then push the current operator. =A0If the operator on the stack has an
> equal or higher precedence than the current operator, then pop the
> operator off the stack and write it to output, then push the current
> operator on the stack. =A0lparens are always pushed onto the stack;
> rparens cause everything on the stack to be popped to the next
> lparen. =A0Neither lparens nor rparens are written to output.

Very nice and correct, perhaps clearer than a grammar based solution,
with the caveats that when the top of the stack is an LP, anything
other than RP must be stacked and RP is an error. Also may not catch
some errors.
>
> Given your example, the operations would look something like this:
>
> 1. =A0Read '(', push it onto the stack. =A0Stack contents =3D {'('}
> 2. =A0Read 'a', write it to output. =A0Output string =3D "a"
> 3. =A0Read '+', push it on the stack: {'(', '+'}
> 4. =A0Read 'b', write it to output: "a b"
> 5. =A0Read ')', pop everything off the stack to the next '(', but don't
> write '(' to output. =A0Output string is "a b +", stack contents =3D {}
> 6. =A0Read '+', push it onto the stack: {'+'}
> 7. =A0Read '8', write it to output: "a b + 8"
> 8. =A0Read '-', has same precedence as '+', so pop '+' from stack, write
> it to output, and push '-': "a b + 8 +", {'-'}
> 9. =A0Read '(', push it onto the stack: {'-', '('}
> 10. Read 'c', write it to output: "a b + 8 + c"
> 11. Read '/', push onto stack: {'-', '(', '/'}
> 12. Read 'd', write to output: "a b + 8 + c d"
> 13. Read ')', pop everything to '(': "a b + 8 + c d /", {'-'}
> 14. End of string, pop remainder of stack: "a b + 8 + c d / -"

0
spinoza1111 (3246)
10/28/2009 12:24:03 AM
On Oct 27, 11:49=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> spinoza1111<spinoza1...@yahoo.com> writes:
> > On Oct 27, 11:15=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >>spinoza1111<spinoza1...@yahoo.com> writes:
> >> > On Oct 26, 8:20=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >> >>spinoza1111<spinoza1...@yahoo.com> writes:
> >> <snip>
> >> >> > expression -> additionFactor [ "+"|"-" expression ]
> >> >> > additionFactor -> multiplicationFactor [ "*"|"/" expression ]
> >> >> > multiplicationFactor -> term
> >> >> > term -> LETTER | NUMBER | "(" expression ")" // Rightmost must ba=
lance
>
> >> >> This is not the usual grammar for expressions and is poor advice fo=
r
> >> >> someone learning this stuff.
>
> > You have not shown that it is INCORRECT.
>
> No, and I never said it was. =A0You know where to post if you really
> don't know what is wrong with it. =A0I don't want to be drawn further
> into an off topic discussion of grammars here. =A0Only in a suitable
> group will you get the very best advice; and only there would any
> criticism be properly checked. =A0Send me an email (drop the ".usenet"
> to get through faster) if you really can't bear to post in a suitable
> group, but then neither of us will benefit from third party scrutiny.
>
> Alternatively, feel free to have the last word by calling me
> "unqualified" or a "faggot" again. =A0I grew up gay being called a lot
> worse than "unqualified".

Give me a break. What part of hyperbole don't you faggots understand?
Furthermore, any claims you might have had to being treated in a
politically correct fashion were made moot when you started to join
electronic mobs and to propagate lies about individuals here. Frankly,
I do not understand groups who form identities as "oppressed" and
their claims to be spoken about in a civil fashion when they do not
extend this civility towards others or their own members.

According to some of my sources, systematic "trashing" of targeted
individuals began in the women's movement as the complement to women's
demands to be spoken of in a new language cleansed of "honey" and
"babe". It was directed at women inside the movement. Likewise, Larry
Kramer, a gay man, has spoken of the way in which gay people demand
kid glove treatment and cleansed language from straights...while
trashing each other and infecting each other with AIDs.

Groups demand charity that is denied, that they deny, to individuals.
>
> <snip>> You need to show that the grammar is either actually incorrect or
> > not suitable for manual interpretation, and I do not, personally
> > think you qualified to do so.
>
> <snip>
> --
> Ben.

0
spinoza1111 (3246)
10/28/2009 12:35:50 AM
On Oct 26, 2:30=C2=A0pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Oct 26, 12:33=C2=A0pm, Tameem <etam...@gmail.com> wrote:
>
> > i have a string as (a+b)+8-(c/d) in Infix form.
>
> > how can i convert it to postfix form using C language,,,????
>
> I will assume that that string is not the ONLY string you have to
> convert. If it is, then the answer is
>
> int main()
> {
> printf("ab+8+cd/-\n");
>
> }
>
> Each one of the following productions should be written as a separate
> C function.
>
> expression -> additionFactor [ "+"|"-" expression ]
> additionFactor -> multiplicationFactor [ "*"|"/" expression ]
> multiplicationFactor -> term
> term -> LETTER | NUMBER | "(" expression ")" // Rightmost must balance
>
> Write code using the above "productions" that emits postfix code. For
> each production write one C function. I won't write C for you because
> I don't like C, I suck at it through disuse consequent on my dislike,
> and it's your homework assignment, not mine.
>
> "->" means "consists of the following material left to right"
>
> "|" means "or"
>
> Lower case and camelCase words are grammar categories that will
> correspond to procedures in YOUR code
>
> Upper case words are lexemes recognised by C code
>
> Quoted material occurs as is.
>
> Material in square brackets is optional. An expression could be just
> an additionFactor. In turn an additionFactor can be just a
> multiplicationFactor and a multiplication factor a number. Therefore,
> "3" is an expression.
>
> When you parse a "term" as "(" expression ")" you must look ahead in
> the overall algorithm I shall give you to find, not the first right
> parenthesis, but the one that actually balances the left parenthesis.
> To do this, maintain a counter. Increment it by one for each left
> parenthesis the lookahead sees: decrement it by one for each right
> parenthesis. When you see right parenthesis and the counter goes to
> zero, you have found the right parenthesis.
>
> OK, here's the untested and uncompiled C Sharp like pseudo code for
> "expression": convert it to C:
>
> string expressionMain(string strInstring)
> {
> int intIndex1 =3D 0;
> string strPolish =3D "";
> return expression(strInstring, ref intIndex1, ref strPolish);}
>
> string expression(string strInstring, ref int intIndex1, ref string
> strPolish)
> {
> if (!additionFactor(string strInstring,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ref=
 intIndex1,
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 ref=
 strPolish)) return "Not valid";
> if (strInstring[intIndex]=3D=3D'+' || strInstring[intIndex]=3D=3D'-')
> {
> =C2=A0 =C2=A0 int intIndexSave =3D intIndex1; intIndex1++;
> =C2=A0 =C2=A0 if (expression(strInstring, ref intIndex1, ref strPolish))
> =C2=A0 =C2=A0 =C2=A0 =C2=A0 strPolish +=3D strInstring[intIndexSave];
> =C2=A0 =C2=A0 else return("Not valid");
>
> }
> return strPolish;
> }
>
> C Sharp idioms: ref followed by type in a formal parameter list in a
> function decl is like using asterisk in front of a parameter in C. It
> means that the parameter is passed by reference. In C Sharp, a very
> cool language, you must ALWAYS use the keyword ref in the "actual
> parameters" passed when you call the function just so you know what
> the hell you are doing, as opposed to C which likes to fool you.
>
> Chapter 3 of my book Build Your Own .Net and Compiler (Edward G.
> Nilges, Apress May 2004) provides a complete solution for this
> homework but in Visual Basic .Net. Therefore this is not a commercial
> promotion. If you find my book useful, buy it, check it out of the
> library, or steal it.

Ben Bacarisse noticed that I used the wrong grammar and informed me by
email in a very professional way. The grammar should be the following
for direct conversion to code!!

expression =E2=86=92 additionFactor [ "+"|"-" additionFactor ] *
additionFactor =E2=86=92 multiplicationFactor [ "*"|"/" multiplicationFacto=
r ]
*
multiplicationFactor =E2=86=92 LETTER | NUMBER | "(" expression ")"

That is, an expression is a series of one or more additionFactors.
When there are at least two, they are separated by plus or minus. The
replacement of the right recursive call to expression by the iteration
over additionFactor (the asterisk expressing iteration) causes the
addition/subtraction to left associate naturally. Likewise for the
call to expression in the second production.

I also made this same error when developing the code for Build Your
Own .Net Language and Compiler but did not have Ben Bacarisse's expert
assistance. Instead, I discovered it in testing the code for the first
toy compiler in ch 3 and mention the problem, and its solution, in my
book. I was too lazy when posting to check my own goddamn book and
shall try to be more diligent in the future. However, such diligence
shall be pearls before swine in some cases and in others the exception
that proves the rule.

When I make an error I make each error twice, it seems to give the old
brain extra time to relearn things it learned in the past; in the past
week I have made the comma-as-operator-versus-separator as well as
this error twice. I do regret if the original post was useless to the
original poster, because as Ben pointed out, it right-associative.

But (big but): my post was of far greater quality, errors and all,
that the uncollegial crap which constitutes 99% of the postings here.
As was Ben's correction. This dialogue is what this facility should be
all the time, not denials that something is true unaccompanied by
information as to what is, and the politics of personal destruction.

Because of this, no response to this thread by Richard Heathfield will
be either read by me nor responded to by me.

Ben: thanks for your assistance and the very professional manner in
which you made it. If there are other errors please let me know.
Likewise for all other readers, except Richard Heathfield. I do not
think he's qualified to discuss this issue.
0
spinoza1111 (3246)
10/28/2009 6:54:19 AM
In <1f2ccb23-5dca-42b4-937b-4035351c9e39@x5g2000prf.googlegroups.com>, 
spinoza1111 wrote:

<snip>

> When I make an error I make each error twice,

If only that were true.

<snip>

-- 
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
0
rjh (10791)
10/28/2009 7:24:49 AM
On Oct 28, 2:54=C2=A0pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Oct 26, 2:30=C2=A0pm,spinoza1111<spinoza1...@yahoo.com> wrote:
>
>
>
>
>
> > On Oct 26, 12:33=C2=A0pm, Tameem <etam...@gmail.com> wrote:
>
> > > i have a string as (a+b)+8-(c/d) in Infix form.
>
> > > how can i convert it to postfix form using C language,,,????
>
> > I will assume that that string is not the ONLY string you have to
> > convert. If it is, then the answer is
>
> > int main()
> > {
> > printf("ab+8+cd/-\n");
>
> > }
>
> > Each one of the following productions should be written as a separate
> > C function.
>
> > expression -> additionFactor [ "+"|"-" expression ]
> > additionFactor -> multiplicationFactor [ "*"|"/" expression ]
> > multiplicationFactor -> term
> > term -> LETTER | NUMBER | "(" expression ")" // Rightmost must balance
>
> > Write code using the above "productions" that emits postfix code. For
> > each production write one C function. I won't write C for you because
> > I don't like C, I suck at it through disuse consequent on my dislike,
> > and it's your homework assignment, not mine.
>
> > "->" means "consists of the following material left to right"
>
> > "|" means "or"
>
> > Lower case and camelCase words are grammar categories that will
> > correspond to procedures in YOUR code
>
> > Upper case words are lexemes recognised by C code
>
> > Quoted material occurs as is.
>
> > Material in square brackets is optional. An expression could be just
> > an additionFactor. In turn an additionFactor can be just a
> > multiplicationFactor and a multiplication factor a number. Therefore,
> > "3" is an expression.
>
> > When you parse a "term" as "(" expression ")" you must look ahead in
> > the overall algorithm I shall give you to find, not the first right
> > parenthesis, but the one that actually balances the left parenthesis.
> > To do this, maintain a counter. Increment it by one for each left
> > parenthesis the lookahead sees: decrement it by one for each right
> > parenthesis. When you see right parenthesis and the counter goes to
> > zero, you have found the right parenthesis.
>
> > OK, here's the untested and uncompiled C Sharp like pseudo code for
> > "expression": convert it to C:
>
> > string expressionMain(string strInstring)
> > {
> > int intIndex1 =3D 0;
> > string strPolish =3D "";
> > return expression(strInstring, ref intIndex1, ref strPolish);}
>
> > string expression(string strInstring, ref int intIndex1, ref string
> > strPolish)
> > {
> > if (!additionFactor(string strInstring,
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 r=
ef intIndex1,
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 r=
ef strPolish)) return "Not valid";
> > if (strInstring[intIndex]=3D=3D'+' || strInstring[intIndex]=3D=3D'-')
> > {
> > =C2=A0 =C2=A0 int intIndexSave =3D intIndex1; intIndex1++;
> > =C2=A0 =C2=A0 if (expression(strInstring, ref intIndex1, ref strPolish)=
)
> > =C2=A0 =C2=A0 =C2=A0 =C2=A0 strPolish +=3D strInstring[intIndexSave];
> > =C2=A0 =C2=A0 else return("Not valid");
>
> > }
> > return strPolish;
> > }
>
> > C Sharp idioms: ref followed by type in a formal parameter list in a
> > function decl is like using asterisk in front of a parameter in C. It
> > means that the parameter is passed by reference. In C Sharp, a very
> > cool language, you must ALWAYS use the keyword ref in the "actual
> > parameters" passed when you call the function just so you know what
> > the hell you are doing, as opposed to C which likes to fool you.
>
> > Chapter 3 of my book Build Your Own .Net and Compiler (Edward G.
> > Nilges, Apress May 2004) provides a complete solution for this
> > homework but in Visual Basic .Net. Therefore this is not a commercial
> > promotion. If you find my book useful, buy it, check it out of the
> > library, or steal it.
>
> Ben Bacarisse noticed that I used the wrong grammar and informed me by
> email in a very professional way. The grammar should be the following
> for direct conversion to code!!
>
> expression =E2=86=92 additionFactor [ "+"|"-" additionFactor ] *
> additionFactor =E2=86=92 multiplicationFactor [ "*"|"/" multiplicationFac=
tor ]
> *
> multiplicationFactor =E2=86=92 LETTER | NUMBER | "(" expression ")"
>
> That is, an expression is a series of one or more additionFactors.
> When there are at least two, they are separated by plus or minus. The
> replacement of the right recursive call to expression by the iteration
> over additionFactor (the asterisk expressing iteration) causes the
> addition/subtraction to left associate naturally. Likewise for the
> call to expression in the second production.
>
> I also made this same error when developing the code for Build Your
> Own .Net Language and Compiler but did not have Ben Bacarisse's expert
> assistance. Instead, I discovered it in testing the code for the first
> toy compiler in ch 3 and mention the problem, and its solution, in my
> book. I was too lazy when posting to check my own goddamn book and
> shall try to be more diligent in the future. However, such diligence
> shall be pearls before swine in some cases and in others the exception
> that proves the rule.
>
> When I make an error I make each error twice, it seems to give the old
> brain extra time to relearn things it learned in the past; in the past
> week I have made the comma-as-operator-versus-separator as well as
> this error twice. I do regret if the original post was useless to the
> original poster, because as Ben pointed out, it right-associative.
>
> But (big but): my post was of far greater quality, errors and all,
> that the uncollegial crap which constitutes 99% of the postings here.
> As was Ben's correction. This dialogue is what this facility should be
> all the time, not denials that something is true unaccompanied by
> information as to what is, and the politics of personal destruction.
>
> Because of this, no response to this thread by Richard Heathfield will
> be either read by me nor responded to by me.
>
> Ben: thanks for your assistance and the very professional manner in
> which you made it. If there are other errors please let me know.
> Likewise for all other readers, except Richard Heathfield. I do not
> think he's qualified to discuss this issue.- Hide quoted text -
>
> - Show quoted text -

Here is a C Sharp implementation of recursive descent to translate
infix to Polish notation. It runs as a command line program. If an
infix expression is entered in its command line, this expression is
converted to Polish notation and the result is displayed.

If the command line contains no operands, a test suite is run. It
should produce this output:

Expect "2 4 3 + /": "2 4 3 + /"
Expect "2 4 / 3 +": "2 4 / 3 +"
Expect "2 4 3 + /": "2 4 3 + /"
Expect "10 113 2 2 4 3 + / + 2 + 2 + - + a *": "10 113 2 2 4 3 + / + 2
+ 2 + - + a *"
Expect error: "Error detected at or near character 3 in "11+":
Addition or subtraction operator is not followed by addFactor"
Expect error: "Error detected at or near character 2 in "11 +":
Expected addition or subtraction operator not found"
Expect "10 113 + a *": "10 113 + a *"
Expect "10 113 + a *": "10 113 + a *"
Expect "1": "1"
Expect "a b + c -": "a b + c -"
Expect "1 1 +": "1 1 +"

Here is the code. It should constitute the complete Program.CS file in
a .Net C Sharp command line mode application. It was tested under .Net
C Sharp Express, a free product available from Microsoft. Comments are
welcome.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace infix2Polish
{
    class Program
    {
        static void Main(string[] strArgs)
        {
            if (strArgs.GetUpperBound(0) < 0)
                Console.WriteLine(tester());
            else
                Console.WriteLine(infix2Polish(strArgs[0]));
            return;
        }

        private static string tester()
        {
            return "Expect \"2 4 3 + /\": \"" +
                   infix2Polish("2/(4+3)") + "\"" +
                   Environment.NewLine +
                   "Expect \"2 4 / 3 +\": \"" +
                   infix2Polish("2/4+3") + "\"" +
                   Environment.NewLine +
                   "Expect \"2 4 3 + /\": \"" +
                   infix2Polish("((2/(4+3)))") + "\"" +
                   Environment.NewLine +
                   "Expect " +
                   "\"10 113 2 2 4 3 + / + 2 + 2 " +
                   "+ - + a *\": \"" +
                   infix2Polish
                   ("((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a") +
                   "\"" +
                   Environment.NewLine +
                   "Expect error: \"" +
                   infix2Polish("11+") + "\"" +
                   Environment.NewLine +
                   "Expect error: \"" +
                   infix2Polish("11 +") + "\"" +
                   Environment.NewLine +
                   "Expect \"10 113 + a *\": \"" +
                   infix2Polish("(10+113)*a") + "\"" +
                   Environment.NewLine +
                   "Expect \"10 113 + a *\": \"" +
                   infix2Polish("((10+113))*a") + "\"" +
                   Environment.NewLine +
                   "Expect \"1\": \"" +
                   infix2Polish("1") + "\"" +
                   Environment.NewLine +
                   "Expect \"a b + c -\": \"" +
                   infix2Polish("a+b-c") + "\"" +
                   Environment.NewLine +
                   "Expect \"1 1 +\": \"" +
                   infix2Polish("1+1") + "\"" +
                   Environment.NewLine;
        }

        private static string infix2Polish(string strInfix)
        {
            string strPolish =3D "";
            int intIndex1 =3D 0;
            string strErrorMessage =3D "";
            if (!expression(strInfix,
                            ref strPolish,
                            ref intIndex1,
                            ref strErrorMessage))
                return strErrorMessage;
            return strPolish.Trim();
        }

        private static bool expression
                            (string strInfix,
                             ref string strPolish,
                             ref int intIndex,
                             ref string strErrorMessage)
        {
            return expression(strInfix,
                              ref strPolish,
                              ref intIndex,
                              ref strErrorMessage,
                              strInfix.Length - 1);
        }
        private static bool expression
                            (string strInfix,
                             ref string strPolish,
                             ref int intIndex,
                             ref string strErrorMessage,
                             int intEnd)
        {// expression -> addFactor [ +|- addFactor ] *
            if (!addFactor(strInfix,
                           ref strPolish,
                           ref intIndex,
                           ref strErrorMessage,
                           intEnd))
                return errorHandler
                       (strInfix,
                        intIndex,
                        ref strErrorMessage,
                        "Expression doesn't start with " +
                        "addFactor");
            char chrAddOp =3D ' ';
            while (intIndex <=3D intEnd)
            {
                if ((chrAddOp =3D strInfix[intIndex]) !=3D '+'
                    &&
                    chrAddOp !=3D '-')
                    return errorHandler
                           (strInfix,
                            intIndex,
                            ref strErrorMessage,
                            "Expected addition or subtraction " +
                            "operator not found");
                intIndex++;
                if (intIndex > intEnd
                    ||
                    !addFactor(strInfix,
                               ref strPolish,
                               ref intIndex,
                               ref strErrorMessage,
                               intEnd))
                    return errorHandler
                           (strInfix,
                            intIndex,
                            ref strErrorMessage,
                            "Addition or subtraction " +
                            "operator is not followed by " +
                            "addFactor");
                strPolish +=3D chrAddOp.ToString() + ' ';
            }
            return true;
        }

        private static bool addFactor
                            (string strInfix,
                             ref string strPolish,
                             ref int intIndex,
                             ref string strErrorMessage,
                             int intEnd)
        {// addFactor -> mulFactor [ *|/ mulFactor ] *
            if (!mulFactor(strInfix,
                           ref strPolish,
                           ref intIndex,
                           ref strErrorMessage,
                           intEnd))
                return errorHandler
                       (strInfix,
                        intIndex,
                        ref strErrorMessage,
                        "Expected multiplication factor " +
                        "not found");
            char chrMulOp =3D ' ';
            while (intIndex <=3D intEnd
                   &&
                   ((chrMulOp =3D strInfix[intIndex]) =3D=3D '*'
                     ||
                     chrMulOp =3D=3D '/'))
            {
                intIndex++;
                if (intIndex > intEnd
                    ||
                    !mulFactor(strInfix,
                               ref strPolish,
                               ref intIndex,
                               ref strErrorMessage,
                               intEnd))
                    return errorHandler
                           (strInfix,
                            intIndex,
                            ref strErrorMessage,
                            "Expected multiplication factor " +
                            "not found");
                strPolish +=3D chrMulOp.ToString() + ' ';
            }
            return true;
        }

        private static bool mulFactor
                            (string strInfix,
                             ref string strPolish,
                             ref int intIndex,
                             ref string strErrorMessage,
                             int intEnd)
        {// mulFactor -> LETTER|NUMBER|"(" expression ")"
            if (strInfix[intIndex] >=3D 'a'
                &&
                strInfix[intIndex] <=3D 'z')
            {
                strPolish +=3D strInfix[intIndex++].ToString() +
                ' ';
                return true;
            }
            int intIndex1 =3D intIndex;
            while(intIndex <=3D intEnd
                  &&
                  (strInfix[intIndex] >=3D '0'
                   &&
                   strInfix[intIndex] <=3D '9'))
                strPolish +=3D strInfix[intIndex++];
            if (intIndex > intIndex1)
            {
                strPolish +=3D ' ';
                return true;
            }
            if (strInfix[intIndex] =3D=3D '(')
            {
                intIndex++;
                int intLevel =3D 1;
                int intIndexAhead =3D 0;
                for (intIndexAhead =3D intIndex;
                     intIndexAhead <=3D intEnd;
                     intIndexAhead++)
                {
                    switch (strInfix[intIndexAhead])
                    {
                        case '(':
                            {
                                intLevel++; break;
                            }
                        case ')':
                            {
                                intLevel--;
                                if (intLevel =3D=3D 0) goto exit;
                                break;
                            }
                        default: break;
                    }
                }
            exit:
                if (!expression(strInfix,
                                ref strPolish,
                                ref intIndex,
                                ref strErrorMessage,
                                intIndexAhead - 1))
                    return errorHandler
                           (strInfix,
                            intIndex,
                            ref strErrorMessage,
                            "Nested expression invalid");
                intIndex++;
            }
            return true;
        }

        private static bool errorHandler
                            (string strInfix,
                             int intIndex,
                             ref string strBase,
                             string strMessage)
        {
            strBase +=3D
                (strBase =3D=3D "" ? "" : "; ") +
                           "Error detected at or near " +
                           "character " +
                           intIndex.ToString() + " " +
                           "in " + "\"" + strInfix + "\": " +
                           strMessage;
            return false;
        }
    }
}
0
spinoza1111 (3246)
10/31/2009 3:44:01 PM
In 
<8fb20e6c-b3cf-4af1-87e1-7c55971457c8@a39g2000pre.googlegroups.com>, 
spinoza1111 wrote:

<150 lines of quoted but unaddressed text snipped>
 
> Here is a C Sharp implementation of recursive descent to translate
> infix to Polish notation.

The microsoft.public.dotnet.languages.csharp newsgroup exists for C# 
discussions; posting your code there will give you the best chance of 
getting informed reviews of that code.

<290 lines of off-topic material snipped>

-- 
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
0
rjh (10791)
10/31/2009 4:06:18 PM
On Nov 1, 12:06=A0am, Richard Heathfield <r...@see.sig.invalid> wrote:
> In
> <8fb20e6c-b3cf-4af1-87e1-7c5597145...@a39g2000pre.googlegroups.com>,
>
> spinoza1111wrote:
>
> <150 lines of quoted but unaddressed text snipped>
>
> > Here is a C Sharp implementation of recursive descent to translate
> > infix to Polish notation.
>
> The microsoft.public.dotnet.languages.csharp newsgroup exists for C#
> discussions; posting your code there will give you the best chance of
> getting informed reviews of that code.

I published it here to show the OP that the grammar based approach
works, and give him "pseudo code" for his C assignment, without doing
his homework for him.

Since by now he's probably handed in his assignment, I challenge you
to translate the C Sharp code to C. Should be easy since you're such a
Studly Dudley C programmer. >
> <290 lines of off-topic material snipped>
>
> --
> 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

0
spinoza1111 (3246)
10/31/2009 5:53:30 PM
In 
<ae71bbc0-4a9e-46dd-90ab-ae75a194af1f@a37g2000prf.googlegroups.com>, 
spinoza1111 wrote:

> On Nov 1, 12:06 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>> In
>> 
<8fb20e6c-b3cf-4af1-87e1-7c5597145...@a39g2000pre.googlegroups.com>,
>>
>> spinoza1111wrote:
>>
>> <150 lines of quoted but unaddressed text snipped>
>>
>> > Here is a C Sharp implementation of recursive descent to
>> > translate infix to Polish notation.
>>
>> The microsoft.public.dotnet.languages.csharp newsgroup exists for
>> C# discussions; posting your code there will give you the best
>> chance of getting informed reviews of that code.
> 
> I published it here to show the OP that the grammar based approach
> works,

If the OP is wise, he will treat any of your code, in whatever 
language, with a great deal of suspicion.

> and give him "pseudo code" for his C assignment, without
> doing his homework for him.
> 
> Since by now he's probably handed in his assignment, I challenge you
> to translate the C Sharp code to C.

I see no value in reinventing that particular wheel. I already have 
working recursive descent code. What would be the point in 
translating yours? If it works (which I doubt), I gain nothing. If it 
doesn't work, I gain less still.

<snip>

-- 
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
0
rjh (10791)
10/31/2009 6:22:39 PM
spinoza1111 <spinoza1111@yahoo.com> writes:
<snip>
> I published it here to show the OP that the grammar based approach
> works, and give him "pseudo code" for his C assignment, without doing
> his homework for him.
>
> Since by now he's probably handed in his assignment, I challenge you
> to translate the C Sharp code to C.

That would not be useful.  Your code does not parse the language
defined by the grammar, and what it does do, it does in a rather
roundabout way.

<snip>
-- 
Ben.
0
ben.usenet (6790)
11/1/2009 2:31:12 AM
On Nov 1, 10:31=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> spinoza1111<spinoza1...@yahoo.com> writes:
>
> <snip>
>
> > I published it here to show the OP that the grammar based approach
> > works, and give him "pseudo code" for his C assignment, without doing
> > his homework for him.
>
> > Since by now he's probably handed in his assignment, I challenge you
> > to translate the C Sharp code to C.
>
> That would not be useful. =A0Your code does not parse the language
> defined by the grammar, and what it does do, it does in a rather
> roundabout way.

If you think the grammar is correct, say so clearly. You imply it but
are too graceless to say it. Now the issue is whether the code
supports the correct grammar correctly.

You present no evidence for the first claim. As to the second, it
means you've never seen this simple algorithm.
>
> <snip>
> --
> Ben.

0
spinoza1111 (3246)
11/1/2009 3:12:51 AM
On Nov 1, 2:22=A0am, Richard Heathfield <r...@see.sig.invalid> wrote:
> In
> <ae71bbc0-4a9e-46dd-90ab-ae75a194a...@a37g2000prf.googlegroups.com>,
>
> spinoza1111wrote:
> > On Nov 1, 12:06 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> In
>
> <8fb20e6c-b3cf-4af1-87e1-7c5597145...@a39g2000pre.googlegroups.com>,
>
>
>
> >> spinoza1111wrote:
>
> >> <150 lines of quoted but unaddressed text snipped>
>
> >> > Here is a C Sharp implementation of recursive descent to
> >> > translate infix to Polish notation.
>
> >> The microsoft.public.dotnet.languages.csharp newsgroup exists for
> >> C# discussions; posting your code there will give you the best
> >> chance of getting informed reviews of that code.
>
> > I published it here to show the OP that the grammar based approach
> > works,
>
> If the OP is wise, he will treat any of your code, in whatever
> language, with a great deal of suspicion.
>
> > and give him "pseudo code" for his C assignment, without
> > doing his homework for him.
>
> > Since by now he's probably handed in his assignment, I challenge you
> > to translate the C Sharp code to C.
>
> I see no value in reinventing that particular wheel. I already have
> working recursive descent code. What would be the point in

Did you write it or did you steal it?

> translating yours? If it works (which I doubt), I gain nothing. If it

I need to see you actually write new C code. You have a big mouth when
it comes to putting down people but the only time when you put your
big mouth on the line (the Spark Notes test) you failed. I am giving
you another chance.

I wrote and debugged a recursive descent parser for my book. I wrote
it again here after correcting the grammar because I think it's
incumbent on each one of us to be able to orally present an algorithm,
and writing it anew and posting it for comments simulates this oral
presentation.

It also demonstrates that the material is sufficiently complex for
smart people to make stupid mistakes (Knuth has himself said he
consistently gets binary search wrong the first time), and that the
stupid people aren't the ones making the mistakes.

It's the people too ready to trash and if possible render unemployable
their fellow human beings (by creating a record here) while explaining
away their own mistakes as you explained away your failure to get a
decent grade on the Spark Notes test.

You are as such contemptible.


> doesn't work, I gain less still.
>
> <snip>
>
> --
> 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

0
spinoza1111 (3246)
11/1/2009 5:17:28 AM
On 2009-11-01, spinoza1111 <spinoza1111@yahoo.com> wrote:
> Did you write it or did you steal it?

Presumably wrote it.  I mean, come on.  A parser is NOT that hard; I've
written one from scratch (maybe two) and done a few with yacc, and while
the code in question doubtless sucked (hint:  everyone's first language
sucks), it worked fine.

> I need to see you actually write new C code.

Er, why?

> You have a big mouth when
> it comes to putting down people but the only time when you put your
> big mouth on the line (the Spark Notes test) you failed. I am giving
> you another chance.

.... Wait, SPARK NOTES?

You're telling me that you are comparing Richard Heathfield to SPARK NOTES
and you think that a discrepancy means he's wrong?

Please tell me that it's still Halloween where you are and you went as
a troll.

> I wrote and debugged a recursive descent parser for my book. I wrote
> it again here after correcting the grammar

.... Wait, uhm.

Does that mean the one in the book is wrong?

If so, then how did this not show up in debugging?

> It also demonstrates that the material is sufficiently complex for
> smart people to make stupid mistakes (Knuth has himself said he
> consistently gets binary search wrong the first time), and that the
> stupid people aren't the ones making the mistakes.

Stupid people make mistakes too.

> It's the people too ready to trash and if possible render unemployable
> their fellow human beings (by creating a record here) while explaining
> away their own mistakes as you explained away your failure to get a
> decent grade on the Spark Notes test.

I am totally fascinated by the concept of such a test.  Is it ...
Hmm.

Well, I went and looked, and found:

http://www.sparknotes.com/cs/pointers/review/quiz.html

This is a funny quiz.  It is full of errors.

Is this the quiz you used?

Please let me know.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/1/2009 6:11:32 AM
On Nov 1, 2:11=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-11-01,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > Did you write it or did you steal it?
>
> Presumably wrote it. =A0I mean, come on. =A0A parser is NOT that hard; I'=
ve
> written one from scratch (maybe two) and done a few with yacc, and while
> the code in question doubtless sucked (hint: =A0everyone's first language
> sucks), it worked fine.
>
> > I need to see you actually write new C code.
>
> Er, why?

Because I don't think you're competent.
>
> > You have a big mouth when
> > it comes to putting down people but the only time when you put your
> > big mouth on the line (the Spark Notes test) you failed. I am giving
> > you another chance.
>
> ... Wait, SPARK NOTES?
>
> You're telling me that you are comparing Richard Heathfield to SPARK NOTE=
S
> and you think that a discrepancy means he's wrong?

Yes. The anonymous team who drafted the Spark Notes test were more
competent than Heathfield, just as Schildt is also more competent than
you.

Note that I don't say "at C" because to be competent at a mistake is
to be subhuman. No, I mean more competent human beings. You know what
a human being is, don't you?
>
> Please tell me that it's still Halloween where you are and you went as
> a troll.
>
> > I wrote and debugged a recursive descent parser for my book. I wrote
> > it again here after correcting the grammar
>
> ... Wait, uhm.
>
> Does that mean the one in the book is wrong?

No. Like many smart people without serious personality disorders I
make typical mistakes: Knuth has confessed he makes the same mistake
in binary search each time he implements it anew. These brain farts
show that we're thinking non-autistically, like actual human beings.
You know what a human being is, or used to be?

I made the same error while developing the book but while coding
noticed it was wrong, and corrected it, using my mistake to explain
things.

I don't have to be right all the time whereas you must be since
otherwise you're a frightened little boy.
>
> If so, then how did this not show up in debugging?

It didn't show since  fixed it. As I've said, I made the mistake
twice: in 2003 while writing the book, and last week when replying to
the OP.
>
> > It also demonstrates that the material is sufficiently complex for
> > smart people to make stupid mistakes (Knuth has himself said he
> > consistently gets binary search wrong the first time), and that the
> > stupid people aren't the ones making the mistakes.
>
> Stupid people make mistakes too.

Arguably less than smart people because stupid people have to work at
7-11 where their actions are monitored, or on funny little embedded
systems as opposed to actually important systems such as Microsoft
boxes, and their work is constantly checked.
>
> > It's the people too ready to trash and if possible render unemployable
> > their fellow human beings (by creating a record here) while explaining
> > away their own mistakes as you explained away your failure to get a
> > decent grade on the Spark Notes test.
>
> I am totally fascinated by the concept of such a test. =A0Is it ...
> Hmm.
>
> Well, I went and looked, and found:
>
> http://www.sparknotes.com/cs/pointers/review/quiz.html
>
> This is a funny quiz. =A0It is full of errors.

Document each error. Is that why you failed to graduate properly and
did not get an MSCS? You sat in the test finding errors instead of
answering questions?
>
> Is this the quiz you used?
>
> Please let me know.

You're not really worth it.
>
> -s
> --
> Copyright 2009, all wrongs reversed. =A0Peter Seebach / usenet-nos...@see=
bs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny picturesht=
tp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

0
spinoza1111 (3246)
11/1/2009 6:33:11 AM
In <224d09b2-a327-4e77-ad0e-f71fd51b5728@m7g2000prd.googlegroups.com>, 
spinoza1111 wrote:

> On Nov 1, 2:22 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>> In
>> 
<ae71bbc0-4a9e-46dd-90ab-ae75a194a...@a37g2000prf.googlegroups.com>,
>>
>> spinoza1111wrote:
>> > On Nov 1, 12:06 am, Richard Heathfield <r...@see.sig.invalid>
>> > wrote:
>> >> In
>>
>> 
<8fb20e6c-b3cf-4af1-87e1-7c5597145...@a39g2000pre.googlegroups.com>,
>>
>>
>>
>> >> spinoza1111wrote:
>>
>> >> <150 lines of quoted but unaddressed text snipped>
>>
>> >> > Here is a C Sharp implementation of recursive descent to
>> >> > translate infix to Polish notation.
>>
>> >> The microsoft.public.dotnet.languages.csharp newsgroup exists
>> >> for C# discussions; posting your code there will give you the
>> >> best chance of getting informed reviews of that code.
>>
>> > I published it here to show the OP that the grammar based
>> > approach works,
>>
>> If the OP is wise, he will treat any of your code, in whatever
>> language, with a great deal of suspicion.
>>
>> > and give him "pseudo code" for his C assignment, without
>> > doing his homework for him.
>>
>> > Since by now he's probably handed in his assignment, I challenge
>> > you to translate the C Sharp code to C.
>>
>> I see no value in reinventing that particular wheel. I already have
>> working recursive descent code. What would be the point in
> 
> Did you write it or did you steal it?

What do you think?

>> translating yours? If it works (which I doubt), I gain nothing. If
>> it
> 
> I need to see you actually write new C code.

On the other hand, the world would benefit significantly if you would 
stop writing new C code. You're not very good at it. I've written 
(probably) millions of lines of new C code over the years, and I 
continue to write new C code. If you need to see me actually writing 
it, you'll have to trick me into hiring you, which is not going to be 
easy.

> You have a big mouth
> when it comes to putting down people but the only time when you put
> your big mouth on the line (the Spark Notes test) you failed.

For the benefit of those who may not know, the subject of the Spark 
Notes test in question was C++, not C. Although we don't actually 
know whether it was written by someone who had learned their C++ from 
Schildt, it seems likely. EGN did that test and scored badly. I did 
the test too, refused to answer several questions because it was 
clear that they had no correct answer, pointed out several questions 
where either the question, the answers, or both were flawed but where 
it was possible to guess the intent of the reader, and still managed 
(meaninglessly) to score higher than EGN. EGN ascribes significance 
to the results of this flawed test, and says I failed it because I 
only scored more points than him. In my view, it was the test that 
failed.

> I am giving you another chance.

Go on then, dig out the Spark Notes C test if there is one, and we'll 
tell you what's wrong with it. And then you can blame C for the idiot 
that wrote the test (assuming an idiot did write the test, which is 
not a given but seems likely).

> I wrote and debugged a recursive descent parser for my book.

I have only your word for that.

<nonsense snipped>

-- 
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
0
rjh (10791)
11/1/2009 7:16:25 AM
On 2009-11-01, spinoza1111 <spinoza1111@yahoo.com> wrote:
> On Nov 1, 2:11�pm, Seebs <usenet-nos...@seebs.net> wrote:
>> Er, why?

> Because I don't think you're competent.

Wait, me too, or just Richard?

> Yes. The anonymous team who drafted the Spark Notes test were more
> competent than Heathfield, just as Schildt is also more competent than
> you.

.... What the fuck?

> Note that I don't say "at C" because to be competent at a mistake is
> to be subhuman.

You clearly do not understand why Buster Keaton rocks.

> No, I mean more competent human beings. You know what
> a human being is, don't you?

Normally, yes.

However, even if we grant that they're hypothetically competent
at "being human beings" or whatever, that still doesn't make their test
informative as to whether someone knows C.

And come to think of it... It sounds like you've just asserted that,
if Richard Heathfield can write C competently, that makes him subhuman.
You're not exactly making a persuasive argument here that he should show
you how good his code is.

> No. Like many smart people without serious personality disorders I
> make typical mistakes:

This is also true of stupid people without serious personality disorders,
smart people with serious personality disorders, or stupid people with
serious personality disorders.

> Knuth has confessed he makes the same mistake
> in binary search each time he implements it anew. These brain farts
> show that we're thinking non-autistically, like actual human beings.

Actually, they don't.  Because autistic people make those same kinds of
mistakes.

> I don't have to be right all the time whereas you must be since
> otherwise you're a frightened little boy.

This would be much, much, more persuasive if I hadn't admitted to at least
half a dozen errors in comp.lang.c in the last month or so.

> Arguably less than smart people because stupid people have to work at
> 7-11 where their actions are monitored, or on funny little embedded
> systems as opposed to actually important systems such as Microsoft
> boxes, and their work is constantly checked.

Oh, I see.  You're trying to sneakily imply that I'm stupid.  No, not buying
it.  I certainly have my cognitive flaws, but "stupidity" is not one
of them.

> Document each error.

I'll just give you my favorite:

	After this code executes

	    int arr[10];
	    int i;
	    i = &arr[9] - arr;

	what is the value of i?
	(A) 8
	(B) 9
	(C) 10
	(D) Won't compile 

Go ahead, guess what their answer is.  Guess what mine was.  And guess
what my compiler says if I try it.  :)  (Hint:  The last two are both
the correct answer.  Theirs isn't.)

> Is that why you failed to graduate properly and
> did not get an MSCS?

Who said I failed to graduate properly?  I graduated just fine with a BA.
I didn't feel like doing more school at the time, so I just started going out
and doing stuff.

> You sat in the test finding errors instead of
> answering questions?

Funny thing, when I was doing tests written by college professors rather
than by random people on the internet, I didn't find nearly so many errors.
:)

> You're not really worth it.

From which I infer that this WAS the test you used, or part of the same test,
and that the idea that there might be unambiguous errors in that test would
undermine the quality of your argument against Richard Heathfield?

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/1/2009 7:16:25 AM
On 2009-11-01, Richard Heathfield <rjh@see.sig.invalid> wrote:
> For the benefit of those who may not know, the subject of the Spark 
> Notes test in question was C++, not C.

Oh, then it was a different one.

Looking at this one, though, I think I would share your evaluation.  Many
of the questions are ambiguous or poorly phrased, a few are just plain
wrong.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/1/2009 7:17:32 AM
On Nov 1, 10:31=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> spinoza1111<spinoza1...@yahoo.com> writes:
>
> <snip>
>
> > I published it here to show the OP that the grammar based approach
> > works, and give him "pseudo code" for his C assignment, without doing
> > his homework for him.
>
> > Since by now he's probably handed in his assignment, I challenge you
> > to translate the C Sharp code to C.
>
> That would not be useful. =A0Your code does not parse the language
> defined by the grammar, and what it does do, it does in a rather
> roundabout way.
>
> <snip>
> --
> Ben.

Since Ben is too lazy and too discourteous to reply with errors, I
shall reply with errors in the code that I found when starting to
convert it to C.

Briefly it failed for a null string and a blank.

It failed (out of bounds subscript) in the mulFactor recognizer when
the infix expression was a null string. This is because mulFactor is
what would be in a more elaborate parser a lexxer looking to the next
character and returning some agreed on symbol when the input is at an
end. Therefore, mulFactor has to take responsibility in the absence of
a lexxer for detailed pointer checks. It started by looking for a
letter without  checking intIndex for being out of bounds.

It needed this check. The second test in mulFactor did not since the
bounds check is part of the while condition. But the third test for a
left parenthesis also needed this check.

I put a new check at the start of mulFactor, returning false when
intIndex>intEnd. I also added a false and error return when mulFactor,
which again combines the jobs of mulFactor and lex, fails to find one
of its three alternatives: letter, number, parenthesized expression. I
also made the output of the regression test more readable.

Note that people who make mistakes learn more even if like Knuth wrt
binary search they make them more than once, IF they are not
constantly interrupted by autistic twerps. They also teach more.

There may have been other mistakes in this code. I have neither
formally nor informally proved it correct. But apart from making an
unsupported claim, Bacarisse has as yet provided no insights. I have
had to do so, so far, wrt to the null string and blank character bug.

Nothing could more clearly indicate the pathology of a newsgroup so
dominated by autistic twerps.

Here is the new test regression output, followed by the new code.


Expect "": For the infix expression "", the Polish expression or error
report is

Error detected at or near character 0 in "": Expected multiplication
factor not found; Error detected at or near character 0 in "":
Expression doesn't start with addFactor
--------------------------------------------
Expect "": For the infix expression " ", the Polish expression or
error report is

Error detected at or near character 0 in " ": Unexpected character '
'; Error detected at or near character 0 in " ": Expected
multiplication factor not found; Error detected at or near character 0
in " ": Expression doesn't start with addFactor
--------------------------------------------
Expect "2 4 3 + /": For the infix expression "2/(4+3)", the Polish
expression or error report is

2 4 3 + /
--------------------------------------------
Expect "2 4 / 3 +": For the infix expression "2/4+3", the Polish
expression or error report is

2 4 / 3 +
--------------------------------------------
Expect "2 4 3 + /": For the infix expression "((2/(4+3)))", the Polish
expression or error report is

2 4 3 + /
--------------------------------------------
Expect "10 113 2 2 4 3 + / + 2 + 2 + - + a *": For the infix
expression "((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a", the Polish
expression or error report is

10 113 2 2 4 3 + / + 2 + 2 + - + a *"
--------------------------------------------
Expect error: For the infix expression "11+", the Polish expression or
error report is

Error detected at or near character 3 in "11+": Addition or
subtraction operator is not followed by addFactor
--------------------------------------------
Expect error: For the infix expression "11 +", the Polish expression
or error report is

Error detected at or near character 2 in "11 +": Expected addition or
subtraction operator not found
--------------------------------------------
Expect "10 113 + a *": For the infix expression "(10+113)*a", the
Polish expression or error report is

10 113 + a *
--------------------------------------------
Expect "10 113 + a *": For the infix expression "((10+113))*a", the
Polish expression or error report is

10 113 + a *
--------------------------------------------
Expect "1": For the infix expression "1", the Polish expression or
error report is

1
--------------------------------------------
Expect "a b + c -": For the infix expression "a+b-c", the Polish
expression or error report is

a b + c -
--------------------------------------------
Expect "1 1 +": For the infix expression "1+1", the Polish expression
or error report is

1 1 +
--------------------------------------------




using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace infix2Polish
{
    class Program
    {
        static void Main(string[] strArgs)
        {
            if (strArgs.GetUpperBound(0) < 0)
                Console.WriteLine(tester());
            else
                Console.WriteLine(infix2Polish(strArgs[0]));
            return;
        }

        private static string tester()
        {
            string strSep =3D
                   Environment.NewLine +
                   "--------------------------------------------" +
                   Environment.NewLine;
            return "Expect \"\": " +
                   infix2PolishTest("") +
                   strSep +
                   "Expect \"\": " +
                   infix2PolishTest(" ") +
                   strSep +
                   "Expect \"2 4 3 + /\": " +
                   infix2PolishTest("2/(4+3)") +
                   strSep +
                   "Expect \"2 4 / 3 +\": "  +
                   infix2PolishTest("2/4+3") +
                   strSep +
                   "Expect \"2 4 3 + /\": " +
                   infix2PolishTest("((2/(4+3)))") +
                   strSep +
                   "Expect " +
                   "\"10 113 2 2 4 3 + / + 2 + 2 " +
                   "+ - + a *\": " +
                   infix2PolishTest
                   ("((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a") +
                   "\"" +
                   strSep +
                   "Expect error: " +
                   infix2PolishTest("11+") +
                   strSep +
                   "Expect error: " +
                   infix2PolishTest("11 +") +
                   strSep +
                   "Expect \"10 113 + a *\": " +
                   infix2PolishTest("(10+113)*a") +
                   strSep +
                   "Expect \"10 113 + a *\": " +
                   infix2PolishTest("((10+113))*a") +
                   strSep +
                   "Expect \"1\": " +
                   infix2PolishTest("1")+
                   strSep +
                   "Expect \"a b + c -\": " +
                   infix2PolishTest("a+b-c") +
                   strSep +
                   "Expect \"1 1 +\": " +
                   infix2PolishTest("1+1") +
                   strSep;
        }

        private static string infix2PolishTest(string strInfix)
        {
            return "For the infix expression " +
                   "\"" + strInfix + "\", " +
                   "the Polish expression or error report is " +
                   Environment.NewLine +
                   Environment.NewLine +
                   infix2Polish(strInfix);
        }

        private static string infix2Polish(string strInfix)
        {
            string strPolish =3D "";
            int intIndex1 =3D 0;
            string strErrorMessage =3D "";
            if (!expression(strInfix,
                            ref strPolish,
                            ref intIndex1,
                            ref strErrorMessage))
                return strErrorMessage;
            return strPolish.Trim();
        }

        private static bool expression
                            (string strInfix,
                             ref string strPolish,
                             ref int intIndex,
                             ref string strErrorMessage)
        {
            return expression(strInfix,
                              ref strPolish,
                              ref intIndex,
                              ref strErrorMessage,
                              strInfix.Length - 1);
        }
        private static bool expression
                            (string strInfix,
                             ref string strPolish,
                             ref int intIndex,
                             ref string strErrorMessage,
                             int intEnd)
        {// expression -> addFactor [ +|- addFactor ] *
            if (!addFactor(strInfix,
                           ref strPolish,
                           ref intIndex,
                           ref strErrorMessage,
                           intEnd))
                return errorHandler
                       (strInfix,
                        intIndex,
                        ref strErrorMessage,
                        "Expression doesn't start with " +
                        "addFactor");
            char chrAddOp =3D ' ';
            while (intIndex <=3D intEnd)
            {
                if ((chrAddOp =3D strInfix[intIndex]) !=3D '+'
                    &&
                    chrAddOp !=3D '-')
                    return errorHandler
                           (strInfix,
                            intIndex,
                            ref strErrorMessage,
                            "Expected addition or subtraction " +
                            "operator not found");
                intIndex++;
                if (intIndex > intEnd
                    ||
                    !addFactor(strInfix,
                               ref strPolish,
                               ref intIndex,
                               ref strErrorMessage,
                               intEnd))
                    return errorHandler
                           (strInfix,
                            intIndex,
                            ref strErrorMessage,
                            "Addition or subtraction " +
                            "operator is not followed by " +
                            "addFactor");
                strPolish +=3D chrAddOp.ToString() + ' ';
            }
            return true;
        }

        private static bool addFactor
                            (string strInfix,
                             ref string strPolish,
                             ref int intIndex,
                             ref string strErrorMessage,
                             int intEnd)
        {// addFactor -> mulFactor [ *|/ mulFactor ] *
            if (!mulFactor(strInfix,
                           ref strPolish,
                           ref intIndex,
                           ref strErrorMessage,
                           intEnd))
                return errorHandler
                       (strInfix,
                        intIndex,
                        ref strErrorMessage,
                        "Expected multiplication factor " +
                        "not found");
            char chrMulOp =3D ' ';
            while (intIndex <=3D intEnd
                   &&
                   ((chrMulOp =3D strInfix[intIndex]) =3D=3D '*'
                     ||
                     chrMulOp =3D=3D '/'))
            {
                intIndex++;
                if (intIndex > intEnd
                    ||
                    !mulFactor(strInfix,
                               ref strPolish,
                               ref intIndex,
                               ref strErrorMessage,
                               intEnd))
                    return errorHandler
                           (strInfix,
                            intIndex,
                            ref strErrorMessage,
                            "Expected multiplication factor " +
                            "not found");
                strPolish +=3D chrMulOp.ToString() + ' ';
            }
            return true;
        }

        private static bool mulFactor
                            (string strInfix,
                             ref string strPolish,
                             ref int intIndex,
                             ref string strErrorMessage,
                             int intEnd)
        {// mulFactor -> LETTER|NUMBER|"(" expression ")"
            if (intIndex > intEnd) return false;
            if (strInfix[intIndex] >=3D 'a'
                &&
                strInfix[intIndex] <=3D 'z')
            {
                strPolish +=3D strInfix[intIndex++].ToString() +
                ' ';
                return true;
            }
            int intIndex1 =3D intIndex;
            while(intIndex <=3D intEnd
                  &&
                  (strInfix[intIndex] >=3D '0'
                   &&
                   strInfix[intIndex] <=3D '9'))
                strPolish +=3D strInfix[intIndex++];
            if (intIndex > intIndex1)
            {
                strPolish +=3D ' ';
                return true;
            }
            if (strInfix[intIndex] =3D=3D '(')
            {
                intIndex++;
                int intLevel =3D 1;
                int intIndexAhead =3D 0;
                for (intIndexAhead =3D intIndex;
                     intIndexAhead <=3D intEnd;
                     intIndexAhead++)
                {
                    switch (strInfix[intIndexAhead])
                    {
                        case '(':
                            {
                                intLevel++; break;
                            }
                        case ')':
                            {
                                intLevel--;
                                if (intLevel =3D=3D 0) goto exit;
                                break;
                            }
                        default: break;
                    }
                }
            exit:
                if (!expression(strInfix,
                                ref strPolish,
                                ref intIndex,
                                ref strErrorMessage,
                                intIndexAhead - 1))
                    return errorHandler
                           (strInfix,
                            intIndex,
                            ref strErrorMessage,
                            "Nested expression invalid");
                intIndex++;
            }
            else
                return errorHandler(strInfix,
                                    intIndex,
                                    ref strErrorMessage,
                                    "Unexpected character " +
                                    "'" + strInfix[intIndex] + "'");
            return true;
        }

        private static bool errorHandler
                            (string strInfix,
                             int intIndex,
                             ref string strBase,
                             string strMessage)
        {
            strBase +=3D
                (strBase =3D=3D "" ? "" : "; ") +
                           "Error detected at or near " +
                           "character " +
                           intIndex.ToString() + " " +
                           "in " + "\"" + strInfix + "\": " +
                           strMessage;
            return false;
        }
    }
}
0
spinoza1111 (3246)
11/1/2009 8:24:26 AM
On Nov 1, 4:24=A0pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Nov 1, 10:31=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
>
>
>
>
> >spinoza1111<spinoza1...@yahoo.com> writes:
>
> > <snip>
>
> > > I published it here to show the OP that the grammar based approach
> > > works, and give him "pseudo code" for his C assignment, without doing
> > > his homework for him.
>
> > > Since by now he's probably handed in his assignment, I challenge you
> > > to translate the C Sharp code to C.
>
> > That would not be useful. =A0Your code does not parse the language
> > defined by the grammar, and what it does do, it does in a rather
> > roundabout way.
>
> > <snip>
> > --
> > Ben.
>
> Since Ben is too lazy and too discourteous to reply with errors, I
> shall reply with errors in the code that I found when starting to
> convert it to C.
>
> Briefly it failed for a null string and a blank.
>
> It failed (out of bounds subscript) in the mulFactor recognizer when
> the infix expression was a null string. This is because mulFactor is
> what would be in a more elaborate parser a lexxer looking to the next
> character and returning some agreed on symbol when the input is at an
> end. Therefore, mulFactor has to take responsibility in the absence of
> a lexxer for detailed pointer checks. It started by looking for a
> letter without =A0checking intIndex for being out of bounds.
>
> It needed this check. The second test in mulFactor did not since the
> bounds check is part of the while condition. But the third test for a
> left parenthesis also needed this check.
>
> I put a new check at the start of mulFactor, returning false when
> intIndex>intEnd. I also added a false and error return when mulFactor,
> which again combines the jobs of mulFactor and lex, fails to find one
> of its three alternatives: letter, number, parenthesized expression. I
> also made the output of the regression test more readable.
>
> Note that people who make mistakes learn more even if like Knuth wrt
> binary search they make them more than once, IF they are not
> constantly interrupted by autistic twerps. They also teach more.
>
> There may have been other mistakes in this code. I have neither
> formally nor informally proved it correct. But apart from making an
> unsupported claim, Bacarisse has as yet provided no insights. I have
> had to do so, so far, wrt to the null string and blank character bug.
>
> Nothing could more clearly indicate the pathology of a newsgroup so
> dominated by autistic twerps.
>
> Here is the new test regression output, followed by the new code.
>
> Expect "": For the infix expression "", the Polish expression or error
> report is

One nit: it shouldn't say here and on the next line "expect a null
string": it should say "expect an error".

I will take Peter's and Richard's silence on these posts to indicate
incompetence to study this code and find flaws.

I shall take Ben's as indicating that he's out Trick or Treating, or
is studying the code desparate to find a justification for his slander.
0
spinoza1111 (3246)
11/1/2009 8:29:26 AM
On 2009-11-01, spinoza1111 <spinoza1111@yahoo.com> wrote:
> I will take Peter's and Richard's silence on these posts to indicate
> incompetence to study this code and find flaws.

I don't know the language you wrote it in, and also don't feel a lot of
need to try to find flaws in your code.

Write something in a language I know and post it in an appropriate group
and I'd be glad to critique it for you.  My interest level in learning
C# is pretty low to begin with, and trying to learn it just to critique
your code seems particularly pointless.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/1/2009 8:34:32 AM
On Nov 1, 4:34=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-11-01,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > I will take Peter's and Richard's silence on these posts to indicate
> > incompetence to study this code and find flaws.
>
> I don't know the language you wrote it in, and also don't feel a lot of
> need to try to find flaws in your code.
>
> Write something in a language I know and post it in an appropriate group
> and I'd be glad to critique it for you. =A0My interest level in learning
> C# is pretty low to begin with, and trying to learn it just to critique
> your code seems particularly pointless.

I have written it in C# as a way to prototype it for the original
poster without doing his homework for him, and now that he's probably
handed in the assignment, I am rewriting it in C, using the C Sharp as
a prototype.

Furthermore, I have taken the risk of critiqueing C without being, any
more, completely familiar with the language. I submit that you're
afraid that I will laugh at you should you critique C Sharp. Fear not.
I am no autistic twerp.

The original intent of programming language design on the part of
Grace Hopper, John Backus, Edsger Dijkstra and the men who created
Algol was NOT to create a group of mutually incomprehensible tribal
languages and a bunch of phony "experts". Therefore, real computer
scientists are willing to comment on code in unfamiliar languages, for
essentially the same reason that in a humanistic structured
walkthrough, contributions from all members are encouraged, and any
"pecking order", especially some pecking order dominated by autistic
twerps, where the savagery is complementary to the savagery with which
some of these twerps were treated growing up, is discouraged.

Can you write it in C using my C Sharp as a prototype, given that C
Sharp is broadly similar to C?
0
spinoza1111 (3246)
11/1/2009 8:48:13 AM
On Nov 1, 4:34=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-11-01,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > I will take Peter's and Richard's silence on these posts to indicate
> > incompetence to study this code and find flaws.
>
> I don't know the language you wrote it in, and also don't feel a lot of
> need to try to find flaws in your code.
>
> Write something in a language I know and post it in an appropriate group

Furthermore, the idea that computer languages are even distinct is
absurd. That they are is a historical accident, caused by the large
number of errors made in language design in the early days.

Insofar as "knowledge" of C is knowledge of mistakes, C has no
standing as an academic subject and should not be spoken of as a
computer language. Instead, it should be considered a pathology which
computer scientists must learn for the same reason doctors must learn
cancer.

People whose main claim to expertise in C should be sent to re-
education camps on the model of UN centres in Africa which train
former guerrillas in useful trades.

And the world still needs one programming language that can be used by
everyone. The guy on the screen in the 1984 Apple commercial was
right.


> and I'd be glad to critique it for you. =A0My interest level in learning
> C# is pretty low to begin with, and trying to learn it just to critique
> your code seems particularly pointless.
>
> -s
> --
> Copyright 2009, all wrongs reversed. =A0Peter Seebach / usenet-nos...@see=
bs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny picturesht=
tp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

0
spinoza1111 (3246)
11/1/2009 8:55:03 AM
On 2009-11-01, spinoza1111 <spinoza1111@yahoo.com> wrote:
> Furthermore, I have taken the risk of critiqueing C without being, any
> more, completely familiar with the language. I submit that you're
> afraid that I will laugh at you should you critique C Sharp. Fear not.
> I am no autistic twerp.

It's not that, it's that I don't know the language and wouldn't care to
try to criticize code in a language I don't know.  You're welcome to laugh
at me anyway if you wish.  It may help if you imagine that I've got a big
red clown nose.  Honk honk!  Honk honk!

> The original intent of programming language design on the part of
> Grace Hopper, John Backus, Edsger Dijkstra and the men who created
> Algol

Your name-dropping is starting to make me wonder if it's NPD week in
comp.lang.c.  Why do you obsessively cite to other people's accomplishments?

> was NOT to create a group of mutually incomprehensible tribal
> languages and a bunch of phony "experts".

Doubtless it wasn't.

> Therefore, real computer
> scientists are willing to comment on code in unfamiliar languages,

Ahh.  I see.  The intent of the people who developed natural human language
was not to create a group of mutually incomprehensible tribal languages
and a bunch of phony "experts", which is why real linguists are willing to
review books in unfamiliar languages.

Furthermore, it's worth pointing out that C# was not created by the
luminaries of the field, but rather by Microsoft, and that their history
strongly suggests that it was *exactly* their intent to create a tribal
language mutually-incomprehensible with other languages and a bunch of
phony "experts", because that's been their strategy throughout the
last thirty or so years.

> for
> essentially the same reason that in a humanistic structured
> walkthrough, contributions from all members are encouraged, and any
> "pecking order", especially some pecking order dominated by autistic
> twerps, where the savagery is complementary to the savagery with which
> some of these twerps were treated growing up, is discouraged.

This is a beautiful example of the kind of rant that keeps us coming back
to your posts.  I'm sufficiently free of pecking orders that it's considered
a neurological disorder, and you're ranting at me about pecking orders.
That's amusing.

But it doesn't change the fact that I don't know C#, and have pretty much
no interest in reviewing hundreds of lines of non-C code in comp.lang.c.  I
would react the same way to a suggestion that I review a ton of shell
script code here, even though I consider myself basically competent to
review shell scripts.

> Can you write it in C using my C Sharp as a prototype, given that C
> Sharp is broadly similar to C?

I probably could, but I don't see why I'd bother.  I can write C code
from all sorts of stuff, but this seems like fundamentally dull code.
Pick something fun!

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/1/2009 8:59:58 AM
On 2009-11-01, spinoza1111 <spinoza1111@yahoo.com> wrote:
> Furthermore, the idea that computer languages are even distinct is
> absurd. That they are is a historical accident, caused by the large
> number of errors made in language design in the early days.

Hmm.  You should hook up with Scott Nudds, I'm sure he'd appreciate your
insights into the merits of language design.

I don't think I find your argument persuasive.  I do not think there exists
a universally ideal language design; in fact, it seems to me that
domain-specific languages are a compelling choice for many applications.

I view languages as tools.  I expect to see a single unified language
about the time I expect to see a single unified woodworking tool, and
for about the same reasons.

> Insofar as "knowledge" of C is knowledge of mistakes,

Except you've never shown this.  You've asserted that it fails to conform
to your expectations, and that you think this is a mistake, but you've not
exactly proven your point.

> C has no
> standing as an academic subject and should not be spoken of as a
> computer language. Instead, it should be considered a pathology which
> computer scientists must learn for the same reason doctors must learn
> cancer.

That's a whole lot of very pretty rhetoric, but again, you have to prove
your point before arguing further from it.

> People whose main claim to expertise in C should be sent to re-
> education camps on the model of UN centres in Africa which train
> former guerrillas in useful trades.

This isn't a sentence, but if it were, I'd bet it would be a stupid
one.  You seem to have omitted a clause, though.  Anyway, don't worry,
I'm almost certainly more famous for expertise in Bourne shell than
I am for expertise in C now.  (And if you want to see a language which
is chock full of astounding mistakes, Bourne shell is a true marvel
of the art.  It isn't used because it's an incredibly well-designed
language, but because it's extremely widely available and fairly
flexible, and we've learned how to overcome most of the weaknesses.)

> And the world still needs one programming language that can be used by
> everyone. The guy on the screen in the 1984 Apple commercial was
> right.

You know, it's a shame that we wasted thousands and thousands of years
of peoples' time researching computer science and language design when we
coulda just watched a superbowl ad and gotten the real answer.

Tell you what, just as a quick sanity check:

The one programming language that can be used by everyone:
* Should have a way to express explicit invocation of specific machine
  instructions, yes/no?
* Should completely abstract away memory management so there's no such
  things as pointers, yes/no?
* Should be designed for "intelligent" people rather than "autistic twerps",
  yes/no?
* Should be accessible to people who are not particularly intelligent,
  yes/no?
* Should compile directly to machine-specific instructions, yes/no?
* Should be interpreted dynamically and allow for the evaluation of
  strings of text, yes/no?

I'm really looking forward to your answers.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/1/2009 9:07:09 AM
In <slrnheq9n8.3r8.usenet-nospam@guild.seebs.net>, Seebs wrote:

<snip>

> Well, I went and looked, and found:
> 
> http://www.sparknotes.com/cs/pointers/review/quiz.html
> 
> This is a funny quiz.  It is full of errors.

Oooh, you found a C version. Well done.

> Is this the quiz you used?

No, he's banging on about the C++ version, which is similarly riddled.

The following answers assume (where possible) that the test setter 
knows C. This is a poor assumption, so I've annotated the answers.

1. (b) - sizeof(int[10]) != sizeof(int *) EORWS[*]. The setter may 
expect (a) - it's a common misconception.
2. (b) - sizeof "hello world" != sizeof(char *) EORWS. The setter may 
expect (a) - it's another common misconception.
3. (b) - C's indexing is zero-based. One would hope that the setter 
knows this.
4. (b) - str cannot be a character pointer variable that holds a 
string, but if it points to that string, str[3] has the value 'd', 
not 'a'. One would hope that the setter knows this.
5. (b) - you can't actually pass an array to a function, but if you 
try, it is not the address of the array that is passed, but the 
address of the first element of the array. (The difference is in the 
/type/.) The setter may expect (a) - it's a common misconception.
6. (b) - C doesn't have pass by reference, so addresses of variables 
can't be passed by reference. The setter may expect (a) - it's a 
common misconception.
7. (b) - false for one-and-a-half reasons; firstly it's a typedef, not 
an object definition, and secondly even if it were a definition it's 
for ints, not integers. All ints are integers, but not all integers 
are ints. I think the setter and I will agree on at least the first 
reason, if not the second.
8. (a) - about time we had an (a). This one seems fair enough - whilst 
it is true that malloc can fail, it is also true that it can succeed! 
And it is certainly possible to allocate memory for an (unnamed) 
array.
9. (b) - I suspect that vTrue is a typo for True, but in any case it's 
false so that's fine. Unless the setter doesn't know about the dot 
operator, of course.
10. (b) - assuming that *p and i have the same type (which is not made 
clear). If they don't, then (d) is also a correct answer (i.e. not a 
correct assignment).
11. (d) - but they mean '\0', not '\\0'
12. (c) must surely be the intended answer, although of course a 
segfault is *not* guaranteed.
13. (c) - I think this question is fair enough.
14. (a) is (probably) the intended answer, but the real answer is that 
the behaviour of the program is undefined because it calls a variadic 
function without a valid prototype in scope.
15. (b) is (probably) the intended answer, but again the real answer 
is that the program's behaviour is undefined, for the same reason as 
the previous question.
16. (a) is (probably) the intended answer, but the real answer is that 
the behaviour of the program is undefined because it calls a variadic 
function without a valid prototype in scope.
17. (d) is undoubtedly the intended answer. In C, the value of NULL is 
always 0. Its type is either int or void *.
18. (a), assuming the question setter is simply ascertaining that the 
positioning (or indeed the presence) of the whitespace is irrelevant 
to this particular line of code.
19. (b), although the wording is a little odd. It is certainly false 
that you can't have pointers to functions.
20. (b) - and it's a reasonable question, albeit rather simple.
21. (c) - provided that the integers mentioned in (c) are ints, which 
isn't specified.
22. (c) is the correct answer. I can't predict what answer the test 
setter wants.
23. (b) is the obvious answer. I can think of a number of (weaselly) 
ways to justify the answer (a), but I suspect the setter can't.
24. (b). The test itself uses pointers to other types.
25. (a) is probably (and ought to be) the intended answer; for 
example, int p[6]; *p = 42; - of course, there are situations in 
which an array /cannot/ be used as a constant pointer. For example: 
int arr[32]; int *p = arr; size_t s1 = sizeof arr; s2 = sizeof p; 
will give different values for s1 and s2 (EORWS).
26. (d) is intended, but should say "any of the above" since it 
clearly can't hold all of them at once (unions notwithstanding).
27. (d) is the intended answer. Actually, it's the "address operator" 
or "unary & operator".
28. (b) - you can't multiply pointers!
29. (d) is the expected answer, but the real answer is that the 
behaviour of the code is undefined.
30. (d) - and this is the first *good* question.
31. (b) - obvious.
32. (c) - obvious.
33. (a) - obvious.
34. (c) is the intended answer. Also, the cast is pointless.
35. (d) - obvious.
36. (d) - obvious.
37. (a) - obvious.
38. (d) - obvious.
39. (c) - obvious.
40. (a) - obvious.
41. Insufficient information to answer the question. If spark() is 
passed x (which is not stated in the question), then obviously the 
answer is (a). Otherwise, obviously the answer is (b).
42. (b) - obvious.
43. (d) is the correct answer - argv is actually a pointer to pointer 
to char, which points at the first element of an array of strings. It 
is not clear what answer is intended, however.
44. (b) - ignoring the 0b prefix.
45. (d) - obvious.

The answering mechanism gave incorrect responses to several of these 
questions, of which Q42 is the most embarrassing - it wants 10, where 
the answer is quite obviously 9. I can think of no reasonable 
circumstance in which any competent C programmer could possibly 
imagine that 10 is a correct answer to that question.

In short, a lousy test.


* EORWS = Except On Really Weird Systems

-- 
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
0
rjh (10791)
11/1/2009 9:23:30 AM
In 
<26d6ea84-e198-491b-9c25-2de7df853b72@v37g2000prg.googlegroups.com>, 
spinoza1111 wrote:

> On Nov 1, 10:31 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:

<snip>

>> Your code does not parse the language
>> defined by the grammar, and what it does do, it does in a rather
>> roundabout way.
> 
> If you think the grammar is correct, say so clearly. You imply it
> but are too graceless to say it. Now the issue is whether the code
> supports the correct grammar correctly.
> 
> You present no evidence for the first claim. As to the second, it
> means you've never seen this simple algorithm.

Why do you expect other people to present evidence for their claims, 
when you rarely if ever present any evidence for yours?

-- 
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
0
rjh (10791)
11/1/2009 9:29:16 AM
On 2009-11-01, Richard Heathfield <rjh@see.sig.invalid> wrote:
> No, he's banging on about the C++ version, which is similarly riddled.

Linky?

> 2. (b) - sizeof "hello world" != sizeof(char *) EORWS. The setter may 
> expect (a) - it's another common misconception.

My quibble:  A string is not "equivalent to a pointer to character".
A string is a series of bytes terminated by a null byte.

> 4. (b) - str cannot be a character pointer variable that holds a 
> string, but if it points to that string, str[3] has the value 'd', 
> not 'a'. One would hope that the setter knows this.

In a fit of inspired brilliance, I actually got that one wrong.
It is not every day I can be tripped up by the fencepost.

> 6. (b) - C doesn't have pass by reference, so addresses of variables 
> can't be passed by reference. The setter may expect (a) - it's a 
> common misconception.

Yes, exactly.

> 9. (b) - I suspect that vTrue is a typo for True, but in any case it's 
> false so that's fine. Unless the setter doesn't know about the dot 
> operator, of course.

I went with "false", because, as you note, you can't use -> on a struct,
only on a pointer-to-struct.

> 11. (d) - but they mean '\0', not '\\0'

Uh-huh.

> 14. (a) is (probably) the intended answer, but the real answer is that 
> the behaviour of the program is undefined because it calls a variadic 
> function without a valid prototype in scope.

Heh.

> 17. (d) is undoubtedly the intended answer. In C, the value of NULL is 
> always 0. Its type is either int or void *.

I love this question.  "In most languages..."  Uh, lolwut?

Also, while 0x00000000 is indeed a value which compares equal to NULL,
it's not necessarily a reasonable guess as to the value NULL has.  But
it's a likely output from, say, trying to print a null pointer with %p.
But... most *languages*?

> 25. (a) is probably (and ought to be) the intended answer; for 
> example, int p[6]; *p = 42; - of course, there are situations in 
> which an array /cannot/ be used as a constant pointer. For example: 
> int arr[32]; int *p = arr; size_t s1 = sizeof arr; s2 = sizeof p; 
> will give different values for s1 and s2 (EORWS).

Yeah.  I feel that an array really can't be used as a constant pointer,
because (e.g.) it has the wrong size, etcetera.

> 26. (d) is intended, but should say "any of the above" since it 
> clearly can't hold all of them at once (unions notwithstanding).

Pointers as a class can store all, so I think it's okay.

> 29. (d) is the expected answer, but the real answer is that the 
> behaviour of the code is undefined.

Yup.

> 34. (c) is the intended answer. Also, the cast is pointless.

But possibly there to throw you off.

> 43. (d) is the correct answer - argv is actually a pointer to pointer 
> to char, which points at the first element of an array of strings. It 
> is not clear what answer is intended, however.

I think they want "array of arrays of characters".  But it's not, because
an array of arrays of characters would have to specify the size of the
sub-arrays.

> The answering mechanism gave incorrect responses to several of these 
> questions, of which Q42 is the most embarrassing - it wants 10, where 
> the answer is quite obviously 9. I can think of no reasonable 
> circumstance in which any competent C programmer could possibly 
> imagine that 10 is a correct answer to that question.

Yeah.  That was the one that really stood out for me as being Just Plain
Dumb.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/1/2009 9:31:05 AM
In <c67d9a14-64a2-41cb-ac39-148fbae42297@j9g2000prh.googlegroups.com>, 
spinoza1111 wrote:

<snip>
 
> I will take Peter's and Richard's silence on these posts to indicate
> incompetence to study this code and find flaws.

How kind. In return, I will take your failure to present evidence, 
when asked, of any specific claim you make as your acceptance that 
that specific claim is false. Which makes the vast, vast, vast vast 
vast majority of your claims false.

<snip>

-- 
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
0
rjh (10791)
11/1/2009 9:32:01 AM
"Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>
> That would not be useful.  Your code does not parse the language
> defined by the grammar, and what it does do, it does in a rather
> roundabout way.
>
Computer code frquently contains errors which are simple lapses of logic. To 
the layman, these might seem to be the result of inexperience. Actually even 
highly-qualified programmers of twenty years' or more experience make such 
errors, and not infrequently either.
To allude to a bug is a very bad way of making a bug report. If you allude 
in a supercilious manner, as someone did for my book "Basic Algorithms" it 
can also backfire (many of the bug reports I received turned out to be 
false, there's nothing bad about that since one false report and one true 
report is better than no reports at all, unless the attitude of the reporter 
is that the bug indicvates stupidity on the part of the author). 


0
regniztar (3128)
11/1/2009 9:42:35 AM
In <slrnheqlap.cmi.usenet-nospam@guild.seebs.net>, Seebs wrote:

> On 2009-11-01, Richard Heathfield <rjh@see.sig.invalid> wrote:
>> No, he's banging on about the C++ version, which is similarly
>> riddled.
> 
> Linky?

Can't find it anywhere. Sorry. EGN will know where it is, though.

<snip>

-- 
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
0
rjh (10791)
11/1/2009 9:50:34 AM
"spinoza1111" <spinoza1111@yahoo.com> wrote in message
>
>Yes. The anonymous team who drafted the Spark Notes test were more
>competent than Heathfield, just as Schildt is also more competent than
>you.
>
>Note that I don't say "at C" because to be competent at a mistake is
>to be subhuman.
>
But multiple choice tests are a mistake as well, unless they are 
psychological profile tests in womens' magazines that no-one with any sense 
would take seriously.

The problem is that if a question is at all interesting it will have more 
than one answer. Sure, you can ask, "which construct is portable?". However 
the assumption that C bytes are 8 bits is probably more portable than the 
assumption that a long is at least 32 bits. 8 bit bytes are so useful that 
compiler writers fake them up even when the underlying hardware won't 
support the reads, even though the standard doesn't require this. Whilst on 
tiny systems int is sometimes 8 bits and long 16 bits, to encourage 
programmers to use integers that fit in registers where possible. So to 
answer a question about "portability" you need to explain the situation. 
Which won't fit in atick box.


0
regniztar (3128)
11/1/2009 10:04:12 AM
On 2009-11-01, Malcolm McLean <regniztar@btinternet.com> wrote:
> The problem is that if a question is at all interesting it will have more 
> than one answer. Sure, you can ask, "which construct is portable?". However 
> the assumption that C bytes are 8 bits is probably more portable than the 
> assumption that a long is at least 32 bits. 8 bit bytes are so useful that 
> compiler writers fake them up even when the underlying hardware won't 
> support the reads, even though the standard doesn't require this. Whilst on 
> tiny systems int is sometimes 8 bits and long 16 bits, to encourage 
> programmers to use integers that fit in registers where possible. So to 
> answer a question about "portability" you need to explain the situation. 
> Which won't fit in atick box.

Obviously, nothing with I8L16 has complied with any C standard, but perhaps
you could identify an example of any machine ever, anywhere, which has
implemented C in such a way?

I can't imagine it.  The convenient existence of char and short for small
objects makes it seem awfully strange to imagine anyone implementing that.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/1/2009 10:18:05 AM
"Seebs" <usenet-nospam@seebs.net> wrote in message
> Obviously, nothing with I8L16 has complied with any C standard, but 
> perhaps
> you could identify an example of any machine ever, anywhere, which has
> implemented C in such a way?
>
> I can't imagine it.  The convenient existence of char and short for small
> objects makes it seem awfully strange to imagine anyone implementing that.
>
One system I used had 8 bit ints. It was a tiny 4K embedded chip, and it was 
intended to run a parking ticket meter. (In the event a rival company got 
the job, but not before we'd looked at the system to prepare our tender).



0
regniztar (3128)
11/1/2009 10:27:40 AM
"Seebs" <usenet-nospam@seebs.net> wrote in message
> Furthermore, it's worth pointing out that C# was not created by the
> luminaries of the field, but rather by Microsoft, and that their history
> strongly suggests that it was *exactly* their intent to create a tribal
> language mutually-incomprehensible with other languages and a bunch of
> phony "experts", because that's been their strategy throughout the
> last thirty or so years.
>
Basically Microsoft want to make it as hard as possible to port code from 
Windows to other operating systems, whilst not making it too difficult to 
port code from  other operating systems to Windows. However they don't want 
to be seen to be doing this.
Commercial and engineering considerations don't always coincide. 


0
regniztar (3128)
11/1/2009 10:32:16 AM
On 2009-11-01, Malcolm McLean <regniztar@btinternet.com> wrote:
> One system I used had 8 bit ints. It was a tiny 4K embedded chip, and it was 
> intended to run a parking ticket meter. (In the event a rival company got 
> the job, but not before we'd looked at the system to prepare our tender).

Weird.  I could imagine someone just punting and saying "we can't even
pretend to implement C, here's a stripped down system with nothing supported",
but I can't imagine someone calling a system with 8-bit ints "C".  What
year was this about?

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/1/2009 10:39:09 AM
On 27 Oct, 06:39, spinoza1111 <spinoza1...@yahoo.com> wrote:

> It's possible that the
> "usual" grammar is incorrect (as in the case of left recursion) given
> Gresham's Law that 99% of everything is crap.

"Gresham's law is commonly stated: "Bad money drives out good""

"Sturgeon's Law. =93Ninety percent of everything is crud.=94"



0
11/1/2009 11:40:20 AM
In 
<c0c39cab-e025-4732-aab4-1a8496ce6fed@w19g2000yqk.googlegroups.com>, 
Nick Keighley wrote:

> On 27 Oct, 06:39, spinoza1111 <spinoza1...@yahoo.com> wrote:
> 
>> It's possible that the
>> "usual" grammar is incorrect (as in the case of left recursion)
>> given Gresham's Law that 99% of everything is crap.
> 
> "Gresham's law is commonly stated: "Bad money drives out good""
> 
> "Sturgeon's Law. ?Ninety percent of everything is crud.?"

Yes, he's been told that over and over again, and he still gets it 
wrong.

-- 
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
0
rjh (10791)
11/1/2009 12:27:16 PM
"Seebs" <usenet-nospam@seebs.net> wrote in message news:
> On 2009-11-01, Malcolm McLean <regniztar@btinternet.com> wrote:
>> One system I used had 8 bit ints. It was a tiny 4K embedded chip, and it 
>> was
>> intended to run a parking ticket meter. (In the event a rival company got
>> the job, but not before we'd looked at the system to prepare our tender).
>
> Weird.  I could imagine someone just punting and saying "we can't even
> pretend to implement C, here's a stripped down system with nothing 
> supported",
> but I can't imagine someone calling a system with 8-bit ints "C".  What
> year was this about?
>
1996 or thereabouts. It was pretty clearly a C system, thpugh very stripped 
down. doubles were 3 bytes, for instance, which probably breaks some of the 
standard somewhere. 


0
regniztar (3128)
11/1/2009 1:14:18 PM
In <qf2dnde9j-kJ_3DXnZ2dnUVZ8nudnZ2d@bt.com>, Malcolm McLean wrote:

<snip>

> One system I used had 8 bit ints. It was a tiny 4K embedded chip,
> and it was intended to run a parking ticket meter.

I always thought there was something vaguely DarkSide-ish about you.

> (In the event a
> rival company got the job, but not before we'd looked at the system
> to prepare our tender).

Which company beat you? Microsith?

-- 
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
0
rjh (10791)
11/1/2009 1:29:43 PM
spinoza1111 <spinoza1111@yahoo.com> writes:

> On Nov 1, 10:31 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> spinoza1111<spinoza1...@yahoo.com> writes:
>>
>> <snip>
>>
>> > I published it here to show the OP that the grammar based approach
>> > works, and give him "pseudo code" for his C assignment, without doing
>> > his homework for him.
>>
>> > Since by now he's probably handed in his assignment, I challenge you
>> > to translate the C Sharp code to C.
>>
>> That would not be useful.  Your code does not parse the language
>> defined by the grammar, and what it does do, it does in a rather
>> roundabout way.
>
> If you think the grammar is correct, say so clearly. You imply it but
> are too graceless to say it. Now the issue is whether the code
> supports the correct grammar correctly.
>
> You present no evidence for the first claim. As to the second, it
> means you've never seen this simple algorithm.

The evidence of the first is the truth of the second.  The evidence
for the second is the code you posted.  The set of strings that it
accepts is not a mystery.  Whether that set is the same as the
language defined by the grammar is simple matter of fact.  All the
evidence is there.

What you mean, I think, is that I am not being helpful enough.  You
don't want to take the time to understand or test your code and you'd
like me to help more.  If you want help writing a recursive descent
parser, post a question in a group where it is topical.  If you want
help with you C#, post in a C# group.  The details are off topic here.

You are probably correct about the last point: I may never have seen
that particular algorithm.  There are lots of incorrect parsing
algorithms and despite having seen, literally, hundreds of students
try to do what you tried, I may well never have seen that particular
version.

-- 
Ben.
0
ben.usenet (6790)
11/1/2009 3:09:47 PM
On Nov 1, 5:32=A0pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> In <c67d9a14-64a2-41cb-ac39-148fbae42...@j9g2000prh.googlegroups.com>,
>
> spinoza1111wrote:
>
> <snip>
>
> > I will take Peter's and Richard's silence on these posts to indicate
> > incompetence to study this code and find flaws.
>
> How kind. In return, I will take your failure to present evidence,
> when asked, of any specific claim you make as your acceptance that
> that specific claim is false. Which makes the vast, vast, vast vast
> vast majority of your claims false.

You're silly bastard.

You see, in practically every post you mention my "errors" in the same
way people prefer to repeat "the errors of Schildt" as if this cite of
a cite makes the errors more numerous.
>
> <snip>
>
> --
> 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

0
spinoza1111 (3246)
11/1/2009 3:13:58 PM
On Nov 1, 4:24=A0pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Nov 1, 10:31=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>
>
>
>
>
> >spinoza1111<spinoza1...@yahoo.com> writes:
>
> > <snip>
>
> > > I published it here to show the OP that the grammar based approach
> > > works, and give him "pseudo code" for his C assignment, without doing
> > > his homework for him.
>
> > > Since by now he's probably handed in his assignment, I challenge you
> > > to translate the C Sharp code to C.
>
> > That would not be useful. =A0Your code does not parse the language
> > defined by the grammar, and what it does do, it does in a rather
> > roundabout way.
>
> > <snip>
> > --
> > Ben.
>
> Since Ben is too lazy and too discourteous to reply with errors, I
> shall reply with errors in the code that I found when starting to
> convert it to C.
>
> Briefly it failed for a null string and a blank.
>
> It failed (out of bounds subscript) in the mulFactor recognizer when
> the infix expression was a null string. This is because mulFactor is
> what would be in a more elaborate parser a lexxer looking to the next
> character and returning some agreed on symbol when the input is at an
> end. Therefore, mulFactor has to take responsibility in the absence of
> a lexxer for detailed pointer checks. It started by looking for a
> letter without =A0checking intIndex for being out of bounds.
>
> It needed this check. The second test in mulFactor did not since the
> bounds check is part of the while condition. But the third test for a
> left parenthesis also needed this check.
>
> I put a new check at the start of mulFactor, returning false when
> intIndex>intEnd. I also added a false and error return when mulFactor,
> which again combines the jobs of mulFactor and lex, fails to find one
> of its three alternatives: letter, number, parenthesized expression. I
> also made the output of the regression test more readable.
>
> Note that people who make mistakes learn more even if like Knuth wrt
> binary search they make them more than once, IF they are not
> constantly interrupted by autistic twerps. They also teach more.
>
> There may have been other mistakes in this code. I have neither
> formally nor informally proved it correct. But apart from making an
> unsupported claim, Bacarisse has as yet provided no insights. I have
> had to do so, so far, wrt to the null string and blank character bug.
>
> Nothing could more clearly indicate the pathology of a newsgroup so
> dominated by autistic twerps.
>
> Here is the new test regression output, followed by the new code.
>
> Expect "": For the infix expression "", the Polish expression or error
> report is
>
> Error detected at or near character 0 in "": Expected multiplication
> factor not found; Error detected at or near character 0 in "":
> Expression doesn't start with addFactor
> --------------------------------------------
> Expect "": For the infix expression " ", the Polish expression or
> error report is
>
> Error detected at or near character 0 in " ": Unexpected character '
> '; Error detected at or near character 0 in " ": Expected
> multiplication factor not found; Error detected at or near character 0
> in " ": Expression doesn't start with addFactor
> --------------------------------------------
> Expect "2 4 3 + /": For the infix expression "2/(4+3)", the Polish
> expression or error report is
>
> 2 4 3 + /
> --------------------------------------------
> Expect "2 4 / 3 +": For the infix expression "2/4+3", the Polish
> expression or error report is
>
> 2 4 / 3 +
> --------------------------------------------
> Expect "2 4 3 + /": For the infix expression "((2/(4+3)))", the Polish
> expression or error report is
>
> 2 4 3 + /
> --------------------------------------------
> Expect "10 113 2 2 4 3 + / + 2 + 2 + - + a *": For the infix
> expression "((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a", the Polish
> expression or error report is
>
> 10 113 2 2 4 3 + / + 2 + 2 + - + a *"
> --------------------------------------------
> Expect error: For the infix expression "11+", the Polish expression or
> error report is
>
> Error detected at or near character 3 in "11+": Addition or
> subtraction operator is not followed by addFactor
> --------------------------------------------
> Expect error: For the infix expression "11 +", the Polish expression
> or error report is
>
> Error detected at or near character 2 in "11 +": Expected addition or
> subtraction operator not found
> --------------------------------------------
> Expect "10 113 + a *": For the infix expression "(10+113)*a", the
> Polish expression or error report is
>
> 10 113 + a *
> --------------------------------------------
> Expect "10 113 + a *": For the infix expression "((10+113))*a", the
> Polish expression or error report is
>
> 10 113 + a *
> --------------------------------------------
> Expect "1": For the infix expression "1", the Polish expression or
> error report is
>
> 1
> --------------------------------------------
> Expect "a b + c -": For the infix expression "a+b-c", the Polish
> expression or error report is
>
> a b + c -
> --------------------------------------------
> Expect "1 1 +": For the infix expression "1+1", the Polish expression
> or error report is
>
> 1 1 +
> --------------------------------------------
>
> using System;
> using System.Collections.Generic;
> using System.Linq;
> using System.Text;
>
> namespace infix2Polish
> {
> =A0 =A0 class Program
> =A0 =A0 {
> =A0 =A0 =A0 =A0 static void Main(string[] strArgs)
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 if (strArgs.GetUpperBound(0) < 0)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Console.WriteLine(tester());
> =A0 =A0 =A0 =A0 =A0 =A0 else
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 Console.WriteLine(infix2Polish(strArgs[0]=
));
> =A0 =A0 =A0 =A0 =A0 =A0 return;
> =A0 =A0 =A0 =A0 }
>
> =A0 =A0 =A0 =A0 private static string tester()
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 string strSep =3D
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Environment.NewLine +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"---------------------------------=
-----------" +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Environment.NewLine;
> =A0 =A0 =A0 =A0 =A0 =A0 return "Expect \"\": " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0infix2PolishTest("") +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strSep +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Expect \"\": " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0infix2PolishTest(" ") +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strSep +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Expect \"2 4 3 + /\": " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0infix2PolishTest("2/(4+3)") +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strSep +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Expect \"2 4 / 3 +\": " =A0+
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0infix2PolishTest("2/4+3") +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strSep +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Expect \"2 4 3 + /\": " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0infix2PolishTest("((2/(4+3)))") +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strSep +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Expect " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"\"10 113 2 2 4 3 + / + 2 + 2 " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"+ - + a *\": " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0infix2PolishTest
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0("((10+(113-(2+((((((2/(4+3)))))))=
+2+2))))*a") +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"\"" +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strSep +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Expect error: " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0infix2PolishTest("11+") +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strSep +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Expect error: " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0infix2PolishTest("11 +") +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strSep +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Expect \"10 113 + a *\": " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0infix2PolishTest("(10+113)*a") +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strSep +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Expect \"10 113 + a *\": " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0infix2PolishTest("((10+113))*a") +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strSep +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Expect \"1\": " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0infix2PolishTest("1")+
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strSep +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Expect \"a b + c -\": " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0infix2PolishTest("a+b-c") +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strSep +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"Expect \"1 1 +\": " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0infix2PolishTest("1+1") +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strSep;
> =A0 =A0 =A0 =A0 }
>
> =A0 =A0 =A0 =A0 private static string infix2PolishTest(string strInfix)
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 return "For the infix expression " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"\"" + strInfix + "\", " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0"the Polish expression or error re=
port is " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Environment.NewLine +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0Environment.NewLine +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0infix2Polish(strInfix);
> =A0 =A0 =A0 =A0 }
>
> =A0 =A0 =A0 =A0 private static string infix2Polish(string strInfix)
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 string strPolish =3D "";
> =A0 =A0 =A0 =A0 =A0 =A0 int intIndex1 =3D 0;
> =A0 =A0 =A0 =A0 =A0 =A0 string strErrorMessage =3D "";
> =A0 =A0 =A0 =A0 =A0 =A0 if (!expression(strInfix,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ref strPolish,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ref intIndex1,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ref strErrorMessa=
ge))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return strErrorMessage;
> =A0 =A0 =A0 =A0 =A0 =A0 return strPolish.Trim();
> =A0 =A0 =A0 =A0 }
>
> =A0 =A0 =A0 =A0 private static bool expression
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (string strInfix,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ref string str=
Polish,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ref int intInd=
ex,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ref string str=
ErrorMessage)
> =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 return expression(strInfix,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ref strPolish=
,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ref intIndex,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ref strErrorM=
essage,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 strInfix.Leng=
th - 1);
> =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 private static bool expression
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (string strInfix,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ref string str=
Polish,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ref int intInd=
ex,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ref string str=
ErrorMessage,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int intEnd)
> =A0 =A0 =A0 =A0 {// expression -> addFactor [ +|- addFactor ] *
> =A0 =A0 =A0 =A0 =A0 =A0 if (!addFactor(strInfix,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ref strPolish,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ref intIndex,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0ref strErrorMessag=
e,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0intEnd))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return errorHandler
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(strInfix,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 intIndex,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ref strErrorMessage,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Expression doesn't start=
 with " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "addFactor");
> =A0 =A0 =A0 =A0 =A0 =A0 char chrAddOp =3D ' ';
> =A0 =A0 =A0 =A0 =A0 =A0 while (intIndex <=3D intEnd)
> =A0 =A0 =A0 =A0 =A0 =A0 {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if ((chrAddOp =3D strInfix[intIndex]) !=
=3D '+'
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 &&
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 chrAddOp !=3D '-')
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return errorHandler
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0(strInfix,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 intIndex,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ref strErrorMessa=
ge,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "Expected additio=
n or subtraction " +
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "operator not fou=
nd");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 intIndex++;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (intIndex > intEnd
>
> read more =BB- Hide quoted text -
>
> - Show quoted text -...

Ben Bacarisse sent me email identifying what he considered several
problems:

1. "(" : produced he said an invalid array reference
2. "////2": failed he said
3. "((((2" produced he said the Polish expression 2
4. "(": failed he said
5. "()" failed he said
6. "+" failed, he said

I added each case to the regression tests in tester() and only ((((2
failed, producing without error the Polish expression 2. 1, and 3-5
all work with the most recent version of the program which corrected
failures to test end of expression.

I have, in the latest version below (following the output of the
latest regression test), added an error call before the "exit:" label
that is the target of a go to (eek!) when intLevel is zero on the
detection of right parenthesis. If the loop that balances the
parentheses fails to match it will exit and this error will be caught.

Ben said the code was roundabout, and he doesn't seem to like the
"lookahead" strategy that finds matching parentheses. It uses a go to
(eek) which is unnecessary and can be replaced by an extra test on
exit from the balancing loop (if intIndex>intEnd, then parentheses do
not balance, otherwise call expression() recursively).

An alternative would be to treat end of string as a separate grammar
symbol, I believe, although I have not worked this strategy out in
detail.

Ben's use of email to identify errors saves a lot of pibble pabble
back and forth and I recommend it.

Here is the latest regression test, followed by the latest code.


Expect error: For the infix expression "(", the Polish expression or
error report is

Error detected at or near character 1 in "(": Parentheses are not
balanced; Error detected at or near character 1 in "(": Expected
multiplication factor not found; Error detected at or near character 1
in "(": Expression doesn't start with addFactor
--------------------------------------------
Expect error: For the infix expression "////2", the Polish expression
or error report is

Error detected at or near character 0 in "////2": Unexpected character
'/'; Error detected at or near character 0 in "////2": Expected
multiplication factor not found; Error detected at or near character 0
in "////2": Expression doesn't start with addFactor
--------------------------------------------
Expect error: For the infix expression "((((2", the Polish expression
or error report is

Error detected at or near character 1 in "((((2": Parentheses are not
balanced; Error detected at or near character 1 in "((((2": Expected
multiplication factor not found; Error detected at or near character 1
in "((((2": Expression doesn't start with addFactor
--------------------------------------------
Expect error: For the infix expression "()", the Polish expression or
error report is

Error detected at or near character 1 in "()": Expected multiplication
factor not found; Error detected at or near character 1 in "()":
Expression doesn't start with addFactor; Error detected at or near
character 1 in "()": Nested expression invalid; Error detected at or
near character 1 in "()": Expected multiplication factor not found;
Error detected at or near character 1 in "()": Expression doesn't
start with addFactor
--------------------------------------------
Expect error: For the infix expression "+", the Polish expression or
error report is

Error detected at or near character 0 in "+": Unexpected character
'+'; Error detected at or near character 0 in "+": Expected
multiplication factor not found; Error detected at or near character 0
in "+": Expression doesn't start with addFactor
--------------------------------------------
Expect "": For the infix expression "", the Polish expression or error
report is

Error detected at or near character 0 in "": Expected multiplication
factor not found; Error detected at or near character 0 in "":
Expression doesn't start with addFactor
--------------------------------------------
Expect "": For the infix expression " ", the Polish expression or
error report is

Error detected at or near character 0 in " ": Unexpected character '
'; Error detected at or near character 0 in " ": Expected
multiplication factor not found; Error detected at or near character 0
in " ": Expression doesn't start with addFactor
--------------------------------------------
Expect "2 4 3 + /": For the infix expression "2/(4+3)", the Polish
expression or error report is

2 4 3 + /
--------------------------------------------
Expect "2 4 / 3 +": For the infix expression "2/4+3", the Polish
expression or error report is

2 4 / 3 +
--------------------------------------------
Expect "2 4 3 + /": For the infix expression "((2/(4+3)))", the Polish
expression or error report is

2 4 3 + /
--------------------------------------------
Expect "10 113 2 2 4 3 + / + 2 + 2 + - + a *": For the infix
expression "((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a", the Polish
expression or error report is

10 113 2 2 4 3 + / + 2 + 2 + - + a *"
--------------------------------------------
Expect error: For the infix expression "11+", the Polish expression or
error report is

Error detected at or near character 3 in "11+": Addition or
subtraction operator is not followed by addFactor
--------------------------------------------
Expect error: For the infix expression "11 +", the Polish expression
or error report is

Error detected at or near character 2 in "11 +": Expected addition or
subtraction operator not found
--------------------------------------------
Expect "10 113 + a *": For the infix expression "(10+113)*a", the
Polish expression or error report is

10 113 + a *
--------------------------------------------
Expect "10 113 + a *": For the infix expression "((10+113))*a", the
Polish expression or error report is

10 113 + a *
--------------------------------------------
Expect "1": For the infix expression "1", the Polish expression or
error report is

1
--------------------------------------------
Expect "a b + c -": For the infix expression "a+b-c", the Polish
expression or error report is

a b + c -
--------------------------------------------
Expect "1 1 +": For the infix expression "1+1", the Polish expression
or error report is

1 1 +
--------------------------------------------


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace infix2Polish
{
    class Program
    {
        static void Main(string[] strArgs)
        {
            if (strArgs.GetUpperBound(0) < 0)
                Console.WriteLine(tester());
            else
                Console.WriteLine(infix2Polish(strArgs[0]));
            return;
        }

        private static string tester()
        {
            string strSep =3D
                   Environment.NewLine +
                   "--------------------------------------------" +
                   Environment.NewLine;
            return "Expect error: " +
                   infix2PolishTest("(") +
                   strSep +
                   "Expect error: " +
                   infix2PolishTest("////2") +
                   strSep +
                   "Expect error: " +
                   infix2PolishTest("((((2") +
                   strSep +
                   "Expect error: " +
                   infix2PolishTest("()") +
                   strSep +
                   "Expect error: " +
                   infix2PolishTest("+") +
                   strSep +
                   "Expect \"\": " +
                   infix2PolishTest("") +
                   strSep +
                   "Expect \"\": " +
                   infix2PolishTest(" ") +
                   strSep +
                   "Expect \"2 4 3 + /\": " +
                   infix2PolishTest("2/(4+3)") +
                   strSep +
                   "Expect \"2 4 / 3 +\": "  +
                   infix2PolishTest("2/4+3") +
                   strSep +
                   "Expect \"2 4 3 + /\": " +
                   infix2PolishTest("((2/(4+3)))") +
                   strSep +
                   "Expect " +
                   "\"10 113 2 2 4 3 + / + 2 + 2 " +
                   "+ - + a *\": " +
                   infix2PolishTest
                   ("((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a") +
                   "\"" +
                   strSep +
                   "Expect error: " +
                   infix2PolishTest("11+") +
                   strSep +
                   "Expect error: " +
                   infix2PolishTest("11 +") +
                   strSep +
                   "Expect \"10 113 + a *\": " +
                   infix2PolishTest("(10+113)*a") +
                   strSep +
                   "Expect \"10 113 + a *\": " +
                   infix2PolishTest("((10+113))*a") +
                   strSep +
                   "Expect \"1\": " +
                   infix2PolishTest("1")+
                   strSep +
                   "Expect \"a b + c -\": " +
                   infix2PolishTest("a+b-c") +
                   strSep +
                   "Expect \"1 1 +\": " +
                   infix2PolishTest("1+1") +
                   strSep;
        }

        private static string infix2PolishTest(string strInfix)
        {
            return "For the infix expression " +
                   "\"" + strInfix + "\", " +
                   "the Polish expression or error report is " +
                   Environment.NewLine +
                   Environment.NewLine +
                   infix2Polish(strInfix);
        }

        private static string infix2Polish(string strInfix)
        {
            string strPolish =3D "";
            int intIndex1 =3D 0;
            string strErrorMessage =3D "";
            if (!expression(strInfix,
                            ref strPolish,
                            ref intIndex1,
                            ref strErrorMessage))
                return strErrorMessage;
            return strPolish.Trim();
        }

        private static bool expression
                            (string strInfix,
                             ref string strPolish,
                             ref int intIndex,
                             ref string strErrorMessage)
        {
            return expression(strInfix,
                              ref strPolish,
                              ref intIndex,
                              ref strErrorMessage,
                              strInfix.Length - 1);
        }
        private static bool expression
                            (string strInfix,
                             ref string strPolish,
                             ref int intIndex,
                             ref string strErrorMessage,
                             int intEnd)
        {// expression -> addFactor [ +|- addFactor ] *
            if (!addFactor(strInfix,
                           ref strPolish,
                           ref intIndex,
                           ref strErrorMessage,
                           intEnd))
                return errorHandler
                       (strInfix,
                        intIndex,
                        ref strErrorMessage,
                        "Expression doesn't start with " +
                        "addFactor");
            char chrAddOp =3D ' ';
            while (intIndex <=3D intEnd)
            {
                if ((chrAddOp =3D strInfix[intIndex]) !=3D '+'
                    &&
                    chrAddOp !=3D '-')
                    return errorHandler
                           (strInfix,
                            intIndex,
                            ref strErrorMessage,
                            "Expected addition or subtraction " +
                            "operator not found");
                intIndex++;
                if (intIndex > intEnd
                    ||
                    !addFactor(strInfix,
                               ref strPolish,
                               ref intIndex,
                               ref strErrorMessage,
                               intEnd))
                    return errorHandler
                           (strInfix,
                            intIndex,
                            ref strErrorMessage,
                            "Addition or subtraction " +
                            "operator is not followed by " +
                            "addFactor");
                strPolish +=3D chrAddOp.ToString() + ' ';
            }
            return true;
        }

        private static bool addFactor
                            (string strInfix,
                             ref string strPolish,
                             ref int intIndex,
                             ref string strErrorMessage,
                             int intEnd)
        {// addFactor -> mulFactor [ *|/ mulFactor ] *
            if (!mulFactor(strInfix,
                           ref strPolish,
                           ref intIndex,
                           ref strErrorMessage,
                           intEnd))
                return errorHandler
                       (strInfix,
                        intIndex,
                        ref strErrorMessage,
                        "Expected multiplication factor " +
                        "not found");
            char chrMulOp =3D ' ';
            while (intIndex <=3D intEnd
                   &&
                   ((chrMulOp =3D strInfix[intIndex]) =3D=3D '*'
                     ||
                     chrMulOp =3D=3D '/'))
            {
                intIndex++;
                if (intIndex > intEnd
                    ||
                    !mulFactor(strInfix,
                               ref strPolish,
                               ref intIndex,
                               ref strErrorMessage,
                               intEnd))
                    return errorHandler
                           (strInfix,
                            intIndex,
                            ref strErrorMessage,
                            "Expected multiplication factor " +
                            "not found");
                strPolish +=3D chrMulOp.ToString() + ' ';
            }
            return true;
        }

        private static bool mulFactor
                            (string strInfix,
                             ref string strPolish,
                             ref int intIndex,
                             ref string strErrorMessage,
                             int intEnd)
        {// mulFactor -> LETTER|NUMBER|"(" expression ")"
            if (intIndex > intEnd) return false;
            if (strInfix[intIndex] >=3D 'a'
                &&
                strInfix[intIndex] <=3D 'z')
            {
                strPolish +=3D strInfix[intIndex++].ToString() +
                ' ';
                return true;
            }
            int intIndex1 =3D intIndex;
            while(intIndex <=3D intEnd
                  &&
                  (strInfix[intIndex] >=3D '0'
                   &&
                   strInfix[intIndex] <=3D '9'))
                strPolish +=3D strInfix[intIndex++];
            if (intIndex > intIndex1)
            {
                strPolish +=3D ' ';
                return true;
            }
            if (strInfix[intIndex] =3D=3D '(')
            {
                intIndex++;
                int intLevel =3D 1;
                int intIndexAhead =3D 0;
                for (intIndexAhead =3D intIndex;
                     intIndexAhead <=3D intEnd;
                     intIndexAhead++)
                {
                    switch (strInfix[intIndexAhead])
                    {
                        case '(':
                            {
                                intLevel++; break;
                            }
                        case ')':
                            {
                                intLevel--;
                                if (intLevel =3D=3D 0) goto exit;
                                break;
                            }
                        default: break;
                    }
                }
                return errorHandler
                       (strInfix,
                        intIndex,
                        ref strErrorMessage,
                        "Parentheses are not balanced");
            exit:
                if (!expression(strInfix,
                                ref strPolish,
                                ref intIndex,
                                ref strErrorMessage,
                                intIndexAhead - 1))
                    return errorHandler
                           (strInfix,
                            intIndex,
                            ref strErrorMessage,
                            "Nested expression invalid");
                intIndex++;
            }
            else
                return errorHandler(strInfix,
                                    intIndex,
                                    ref strErrorMessage,
                                    "Unexpected character " +
                                    "'" + strInfix[intIndex] + "'");
            return true;
        }

        private static bool errorHandler
                            (string strInfix,
                             int intIndex,
                             ref string strBase,
                             string strMessage)
        {
            strBase +=3D
                (strBase =3D=3D "" ? "" : "; ") +
                           "Error detected at or near " +
                           "character " +
                           intIndex.ToString() + " " +
                           "in " + "\"" + strInfix + "\": " +
                           strMessage;
            return false;
        }
    }
}
0
spinoza1111 (3246)
11/1/2009 3:26:38 PM
THIS POST JUST CONTAINS THE LATEST CODE AND REGRESSION TEST, WHICH
ADDRESS ALL OF BEN'S CONCERNS

On Nov 1, 4:24 pm, spinoza1111 <spinoza1...@yahoo.com> wrote:


> On Nov 1, 10:31 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:

> >spinoza1111<spinoza1...@yahoo.com> writes:


> > <snip>


> > > I published it here to show the OP that the grammar based approach
> > > works, and give him "pseudo code" for his C assignment, without doing
> > > his homework for him.


> > > Since by now he's probably handed in his assignment, I challenge you
> > > to translate the C Sharp code to C.


> > That would not be useful.  Your code does not parse the language
> > defined by the grammar, and what it does do, it does in a rather
> > roundabout way.


> > <snip>
> > --
> > Ben.


> Since Ben is too lazy and too discourteous to reply with errors, I
> shall reply with errors in the code that I found when starting to
> convert it to C.


> Briefly it failed for a null string and a blank.


> It failed (out of bounds subscript) in the mulFactor recognizer when
> the infix expression was a null string. This is because mulFactor is
> what would be in a more elaborate parser a lexxer looking to the next
> character and returning some agreed on symbol when the input is at an
> end. Therefore, mulFactor has to take responsibility in the absence of
> a lexxer for detailed pointer checks. It started by looking for a
> letter without  checking intIndex for being out of bounds.


> It needed this check. The second test in mulFactor did not since the
> bounds check is part of the while condition. But the third test for a
> left parenthesis also needed this check.


> I put a new check at the start of mulFactor, returning false when
> intIndex>intEnd. I also added a false and error return when mulFactor,
> which again combines the jobs of mulFactor and lex, fails to find one
> of its three alternatives: letter, number, parenthesized expression. I
> also made the output of the regression test more readable.


> Note that people who make mistakes learn more even if like Knuth wrt
> binary search they make them more than once, IF they are not
> constantly interrupted by autistic twerps. They also teach more.


> There may have been other mistakes in this code. I have neither
> formally nor informally proved it correct. But apart from making an
> unsupported claim, Bacarisse has as yet provided no insights. I have
> had to do so, so far, wrt to the null string and blank character bug.


> Nothing could more clearly indicate the pathology of a newsgroup so
> dominated by autistic twerps.


> Here is the new test regression output, followed by the new code.


> Expect "": For the infix expression "", the Polish expression or error
> report is


> Error detected at or near character 0 in "": Expected multiplication
> factor not found; Error detected at or near character 0 in "":
> Expression doesn't start with addFactor
> --------------------------------------------
> Expect "": For the infix expression " ", the Polish expression or
> error report is


> Error detected at or near character 0 in " ": Unexpected character '
> '; Error detected at or near character 0 in " ": Expected
> multiplication factor not found; Error detected at or near character 0
> in " ": Expression doesn't start with addFactor
> --------------------------------------------
> Expect "2 4 3 + /": For the infix expression "2/(4+3)", the Polish
> expression or error report is


> 2 4 3 + /
> --------------------------------------------
> Expect "2 4 / 3 +": For the infix expression "2/4+3", the Polish
> expression or error report is


> 2 4 / 3 +
> --------------------------------------------
> Expect "2 4 3 + /": For the infix expression "((2/(4+3)))", the Polish
> expression or error report is


> 2 4 3 + /
> --------------------------------------------
> Expect "10 113 2 2 4 3 + / + 2 + 2 + - + a *": For the infix
> expression "((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a", the Polish
> expression or error report is


> 10 113 2 2 4 3 + / + 2 + 2 + - + a *"
> --------------------------------------------
> Expect error: For the infix expression "11+", the Polish expression or
> error report is


> Error detected at or near character 3 in "11+": Addition or
> subtraction operator is not followed by addFactor
> --------------------------------------------
> Expect error: For the infix expression "11 +", the Polish expression
> or error report is


> Error detected at or near character 2 in "11 +": Expected addition or
> subtraction operator not found
> --------------------------------------------
> Expect "10 113 + a *": For the infix expression "(10+113)*a", the
> Polish expression or error report is


> 10 113 + a *
> --------------------------------------------
> Expect "10 113 + a *": For the infix expression "((10+113))*a", the
> Polish expression or error report is


> 10 113 + a *
> --------------------------------------------
> Expect "1": For the infix expression "1", the Polish expression or
> error report is


> 1
> --------------------------------------------
> Expect "a b + c -": For the infix expression "a+b-c", the Polish
> expression or error report is


> a b + c -
> --------------------------------------------
> Expect "1 1 +": For the infix expression "1+1", the Polish expression
> or error report is


> 1 1 +
> --------------------------------------------


> using System;
> using System.Collections.Generic;
> using System.Linq;
> using System.Text;


> namespace infix2Polish
> {
>     class Program
>     {
>         static void Main(string[] strArgs)
>         {
>             if (strArgs.GetUpperBound(0) < 0)
>                 Console.WriteLine(tester());
>             else
>                 Console.WriteLine(infix2Polish(strArgs[0]));
>             return;
>         }


>         private static string tester()
>         {
>             string strSep =3D
>                    Environment.NewLine +
>                    "--------------------------------------------" +
>                    Environment.NewLine;
>             return "Expect \"\": " +
>                    infix2PolishTest("") +
>                    strSep +
>                    "Expect \"\": " +
>                    infix2PolishTest(" ") +
>                    strSep +
>                    "Expect \"2 4 3 + /\": " +
>                    infix2PolishTest("2/(4+3)") +
>                    strSep +
>                    "Expect \"2 4 / 3 +\": "  +
>                    infix2PolishTest("2/4+3") +
>                    strSep +
>                    "Expect \"2 4 3 + /\": " +
>                    infix2PolishTest("((2/(4+3)))") +
>                    strSep +
>                    "Expect " +
>                    "\"10 113 2 2 4 3 + / + 2 + 2 " +
>                    "+ - + a *\": " +
>                    infix2PolishTest
>                    ("((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a") +
>                    "\"" +
>                    strSep +
>                    "Expect error: " +
>                    infix2PolishTest("11+") +
>                    strSep +
>                    "Expect error: " +
>                    infix2PolishTest("11 +") +
>                    strSep +
>                    "Expect \"10 113 + a *\": " +
>                    infix2PolishTest("(10+113)*a") +
>                    strSep +
>                    "Expect \"10 113 + a *\": " +
>                    infix2PolishTest("((10+113))*a") +
>                    strSep +
>                    "Expect \"1\": " +
>                    infix2PolishTest("1")+
>                    strSep +
>                    "Expect \"a b + c -\": " +
>                    infix2PolishTest("a+b-c") +
>                    strSep +
>                    "Expect \"1 1 +\": " +
>                    infix2PolishTest("1+1") +
>                    strSep;
>         }


>         private static string infix2PolishTest(string strInfix)
>         {
>             return "For the infix expression " +
>                    "\"" + strInfix + "\", " +
>                    "the Polish expression or error report is " +
>                    Environment.NewLine +
>                    Environment.NewLine +
>                    infix2Polish(strInfix);
>         }


>         private static string infix2Polish(string strInfix)
>         {
>             string strPolish =3D "";
>             int intIndex1 =3D 0;
>             string strErrorMessage =3D "";
>             if (!expression(strInfix,
>                             ref strPolish,
>                             ref intIndex1,
>                             ref strErrorMessage))
>                 return strErrorMessage;
>             return strPolish.Trim();
>         }


>         private static bool expression
>                             (string strInfix,
>                              ref string strPolish,
>                              ref int intIndex,
>                              ref string strErrorMessage)
>         {
>             return expression(strInfix,
>                               ref strPolish,
>                               ref intIndex,
>                               ref strErrorMessage,
>                               strInfix.Length - 1);
>         }
>         private static bool expression
>                             (string strInfix,
>                              ref string strPolish,
>                              ref int intIndex,
>                              ref string strErrorMessage,
>                              int intEnd)
>         {// expression -> addFactor [ +|- addFactor ] *
>             if (!addFactor(strInfix,
>                            ref strPolish,
>                            ref intIndex,
>                            ref strErrorMessage,
>                            intEnd))
>                 return errorHandler
>                        (strInfix,
>                         intIndex,
>                         ref strErrorMessage,
>                         "Expression doesn't start with " +
>                         "addFactor");
>             char chrAddOp =3D ' ';
>             while (intIndex <=3D intEnd)
>             {
>                 if ((chrAddOp =3D strInfix[intIndex]) !=3D '+'
>                     &&
>                     chrAddOp !=3D '-')
>                     return errorHandler
>                            (strInfix,
>                             intIndex,
>                             ref strErrorMessage,
>                             "Expected addition or subtraction " +
>                             "operator not found");
>                 intIndex++;
>                 if (intIndex > intEnd


> read more =BB- Hide quoted text -


> - Show quoted text -...



Ben Bacarisse sent me email identifying what he considered several
problems:

1. "(" : produced he said an invalid array reference
2. "////2": failed he said
3. "((((2" produced he said the Polish expression 2
4. "(": failed he said
5. "()" failed he said
6. "+" failed, he said


I added each case to the regression tests in tester() and only ((((2
failed, producing without error the Polish expression 2. 1, and 3-5
all work with the most recent version of the program which corrected
failures to test end of expression.


I have, in the latest version below (following the output of the
latest regression test), added an error call before the "exit:" label
that is the target of a go to (eek!) when intLevel is zero on the
detection of right parenthesis. If the loop that balances the
parentheses fails to match it will exit and this error will be
caught.


Ben said the code was roundabout, and he doesn't seem to like the
"lookahead" strategy that finds matching parentheses. It uses a go to
(eek) which is unnecessary and can be replaced by an extra test on
exit from the balancing loop (if intIndex>intEnd, then parentheses do
not balance, otherwise call expression() recursively).


An alternative would be to treat end of string as a separate grammar
symbol, I believe, although I have not worked this strategy out in
detail.


Ben's use of email to identify errors saves a lot of pibble pabble
back and forth and I recommend it.


Here is the latest regression test, followed by the latest code.


Expect error: For the infix expression "(", the Polish expression or
error report is


Error detected at or near character 1 in "(": Parentheses are not
balanced; Error detected at or near character 1 in "(": Expected
multiplication factor not found; Error detected at or near character
1
in "(": Expression doesn't start with addFactor
--------------------------------------------
Expect error: For the infix expression "////2", the Polish expression
or error report is


Error detected at or near character 0 in "////2": Unexpected
character
'/'; Error detected at or near character 0 in "////2": Expected
multiplication factor not found; Error detected at or near character
0
in "////2": Expression doesn't start with addFactor
--------------------------------------------
Expect error: For the infix expression "((((2", the Polish expression
or error report is


Error detected at or near character 1 in "((((2": Parentheses are not
balanced; Error detected at or near character 1 in "((((2": Expected
multiplication factor not found; Error detected at or near character
1
in "((((2": Expression doesn't start with addFactor
--------------------------------------------
Expect error: For the infix expression "()", the Polish expression or
error report is


Error detected at or near character 1 in "()": Expected
multiplication
factor not found; Error detected at or near character 1 in "()":
Expression doesn't start with addFactor; Error detected at or near
character 1 in "()": Nested expression invalid; Error detected at or
near character 1 in "()": Expected multiplication factor not found;
Error detected at or near character 1 in "()": Expression doesn't
start with addFactor
--------------------------------------------
Expect error: For the infix expression "+", the Polish expression or
error report is


Error detected at or near character 0 in "+": Unexpected character
'+'; Error detected at or near character 0 in "+": Expected
multiplication factor not found; Error detected at or near character
0
in "+": Expression doesn't start with addFactor
--------------------------------------------
Expect "": For the infix expression "", the Polish expression or
error
report is


Error detected at or near character 0 in "": Expected multiplication
factor not found; Error detected at or near character 0 in "":
Expression doesn't start with addFactor
--------------------------------------------
Expect "": For the infix expression " ", the Polish expression or
error report is


Error detected at or near character 0 in " ": Unexpected character '
'; Error detected at or near character 0 in " ": Expected
multiplication factor not found; Error detected at or near character
0
in " ": Expression doesn't start with addFactor
--------------------------------------------
Expect "2 4 3 + /": For the infix expression "2/(4+3)", the Polish
expression or error report is


2 4 3 + /
--------------------------------------------
Expect "2 4 / 3 +": For the infix expression "2/4+3", the Polish
expression or error report is


2 4 / 3 +
--------------------------------------------
Expect "2 4 3 + /": For the infix expression "((2/(4+3)))", the
Polish
expression or error report is


2 4 3 + /
--------------------------------------------
Expect "10 113 2 2 4 3 + / + 2 + 2 + - + a *": For the infix
expression "((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a", the Polish
expression or error report is


10 113 2 2 4 3 + / + 2 + 2 + - + a *"
--------------------------------------------
Expect error: For the infix expression "11+", the Polish expression
or
error report is


Error detected at or near character 3 in "11+": Addition or
subtraction operator is not followed by addFactor
--------------------------------------------
Expect error: For the infix expression "11 +", the Polish expression
or error report is


Error detected at or near character 2 in "11 +": Expected addition or
subtraction operator not found
--------------------------------------------
Expect "10 113 + a *": For the infix expression "(10+113)*a", the
Polish expression or error report is


10 113 + a *
--------------------------------------------
Expect "10 113 + a *": For the infix expression "((10+113))*a", the
Polish expression or error report is


10 113 + a *
--------------------------------------------
Expect "1": For the infix expression "1", the Polish expression or
error report is


1
--------------------------------------------
Expect "a b + c -": For the infix expression "a+b-c", the Polish
expression or error report is


a b + c -
--------------------------------------------
Expect "1 1 +": For the infix expression "1+1", the Polish expression
or error report is


1 1 +
--------------------------------------------


using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;


namespace infix2Polish
{
    class Program
    {
        static void Main(string[] strArgs)
        {
            if (strArgs.GetUpperBound(0) < 0)
                Console.WriteLine(tester());
            else
                Console.WriteLine(infix2Polish(strArgs[0]));
            return;
        }


        private static string tester()
        {
            string strSep =3D
                   Environment.NewLine +
                   "--------------------------------------------" +
                   Environment.NewLine;
            return "Expect error: " +
                   infix2PolishTest("(") +
                   strSep +
                   "Expect error: " +
                   infix2PolishTest("////2") +
                   strSep +
                   "Expect error: " +
                   infix2PolishTest("((((2") +
                   strSep +
                   "Expect error: " +
                   infix2PolishTest("()") +
                   strSep +
                   "Expect error: " +
                   infix2PolishTest("+") +
                   strSep +
                   "Expect \"\": " +
                   infix2PolishTest("") +
                   strSep +
                   "Expect \"\": " +
                   infix2PolishTest(" ") +
                   strSep +
                   "Expect \"2 4 3 + /\": " +
                   infix2PolishTest("2/(4+3)") +
                   strSep +
                   "Expect \"2 4 / 3 +\": "  +
                   infix2PolishTest("2/4+3") +
                   strSep +
                   "Expect \"2 4 3 + /\": " +
                   infix2PolishTest("((2/(4+3)))") +
                   strSep +
                   "Expect " +
                   "\"10 113 2 2 4 3 + / + 2 + 2 " +
                   "+ - + a *\": " +
                   infix2PolishTest
                   ("((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a") +
                   "\"" +
                   strSep +
                   "Expect error: " +
                   infix2PolishTest("11+") +
                   strSep +
                   "Expect error: " +
                   infix2PolishTest("11 +") +
                   strSep +
                   "Expect \"10 113 + a *\": " +
                   infix2PolishTest("(10+113)*a") +
                   strSep +
                   "Expect \"10 113 + a *\": " +
                   infix2PolishTest("((10+113))*a") +
                   strSep +
                   "Expect \"1\": " +
                   infix2PolishTest("1")+
                   strSep +
                   "Expect \"a b + c -\": " +
                   infix2PolishTest("a+b-c") +
                   strSep +
                   "Expect \"1 1 +\": " +
                   infix2PolishTest("1+1") +
                   strSep;
        }


        private static string infix2PolishTest(string strInfix)
        {
            return "For the infix expression " +
                   "\"" + strInfix + "\", " +
                   "the Polish expression or error report is " +
                   Environment.NewLine +
                   Environment.NewLine +
                   infix2Polish(strInfix);
        }


        private static string infix2Polish(string strInfix)
        {
            string strPolish =3D "";
            int intIndex1 =3D 0;
            string strErrorMessage =3D "";
            if (!expression(strInfix,
                            ref strPolish,
                            ref intIndex1,
                            ref strErrorMessage))
                return strErrorMessage;
            return strPolish.Trim();
        }


        private static bool expression
                            (string strInfix,
                             ref string strPolish,
                             ref int intIndex,
                             ref string strErrorMessage)
        {
            return expression(strInfix,
                              ref strPolish,
                              ref intIndex,
                              ref strErrorMessage,
                              strInfix.Length - 1);
        }
        private static bool expression
                            (string strInfix,
                             ref string strPolish,
                             ref int intIndex,
                             ref string strErrorMessage,
                             int intEnd)
        {// expression -> addFactor [ +|- addFactor ] *
            if (!addFactor(strInfix,
                           ref strPolish,
                           ref intIndex,
                           ref strErrorMessage,
                           intEnd))
                return errorHandler
                       (strInfix,
                        intIndex,
                        ref strErrorMessage,
                        "Expression doesn't start with " +
                        "addFactor");
            char chrAddOp =3D ' ';
            while (intIndex <=3D intEnd)
            {
                if ((chrAddOp =3D strInfix[intIndex]) !=3D '+'
                    &&
                    chrAddOp !=3D '-')
                    return errorHandler
                           (strInfix,
                            intIndex,
                            ref strErrorMessage,
                            "Expected addition or subtraction " +
                            "operator not found");
                intIndex++;
                if (intIndex > intEnd
                    ||
                    !addFactor(strInfix,
                               ref strPolish,
                               ref intIndex,
                               ref strErrorMessage,
                               intEnd))
                    return errorHandler
                           (strInfix,
                            intIndex,
                            ref strErrorMessage,
                            "Addition or subtraction " +
                            "operator is not followed by " +
                            "addFactor");
                strPolish +=3D chrAddOp.ToString() + ' ';
            }
            return true;
        }


        private static bool addFactor
                            (string strInfix,
                             ref string strPolish,
                             ref int intIndex,
                             ref string strErrorMessage,
                             int intEnd)
        {// addFactor -> mulFactor [ *|/ mulFactor ] *
            if (!mulFactor(strInfix,
                           ref strPolish,
                           ref intIndex,
                           ref strErrorMessage,
                           intEnd))
                return errorHandler
                       (strInfix,
                        intIndex,
                        ref strErrorMessage,
                        "Expected multiplication factor " +
                        "not found");
            char chrMulOp =3D ' ';
            while (intIndex <=3D intEnd
                   &&
                   ((chrMulOp =3D strInfix[intIndex]) =3D=3D '*'
                     ||
                     chrMulOp =3D=3D '/'))
            {
                intIndex++;
                if (intIndex > intEnd
                    ||
                    !mulFactor(strInfix,
                               ref strPolish,
                               ref intIndex,
                               ref strErrorMessage,
                               intEnd))
                    return errorHandler
                           (strInfix,
                            intIndex,
                            ref strErrorMessage,
                            "Expected multiplication factor " +
                            "not found");
                strPolish +=3D chrMulOp.ToString() + ' ';
            }
            return true;
        }


        private static bool mulFactor
                            (string strInfix,
                             ref string strPolish,
                             ref int intIndex,
                             ref string strErrorMessage,
                             int intEnd)
        {// mulFactor -> LETTER|NUMBER|"(" expression ")"
            if (intIndex > intEnd) return false;
            if (strInfix[intIndex] >=3D 'a'
                &&
                strInfix[intIndex] <=3D 'z')
            {
                strPolish +=3D strInfix[intIndex++].ToString() +
                ' ';
                return true;
            }
            int intIndex1 =3D intIndex;
            while(intIndex <=3D intEnd
                  &&
                  (strInfix[intIndex] >=3D '0'
                   &&
                   strInfix[intIndex] <=3D '9'))
                strPolish +=3D strInfix[intIndex++];
            if (intIndex > intIndex1)
            {
                strPolish +=3D ' ';
                return true;
            }
            if (strInfix[intIndex] =3D=3D '(')
            {
                intIndex++;
                int intLevel =3D 1;
                int intIndexAhead =3D 0;
                for (intIndexAhead =3D intIndex;
                     intIndexAhead <=3D intEnd;
                     intIndexAhead++)
                {
                    switch (strInfix[intIndexAhead])
                    {
                        case '(':
                            {
                                intLevel++; break;
                            }
                        case ')':
                            {
                                intLevel--;
                                if (intLevel =3D=3D 0) goto exit;
                                break;
                            }
                        default: break;
                    }
                }
                return errorHandler
                       (strInfix,
                        intIndex,
                        ref strErrorMessage,
                        "Parentheses are not balanced");
            exit:
                if (!expression(strInfix,
                                ref strPolish,
                                ref intIndex,
                                ref strErrorMessage,
                                intIndexAhead - 1))
                    return errorHandler
                           (strInfix,
                            intIndex,
                            ref strErrorMessage,
                            "Nested expression invalid");
                intIndex++;
            }
            else
                return errorHandler(strInfix,
                                    intIndex,
                                    ref strErrorMessage,
                                    "Unexpected character " +
                                    "'" + strInfix[intIndex] + "'");
            return true;
        }


        private static bool errorHandler
                            (string strInfix,
                             int intIndex,
                             ref string strBase,
                             string strMessage)
        {
            strBase +=3D
                (strBase =3D=3D "" ? "" : "; ") +
                           "Error detected at or near " +
                           "character " +
                           intIndex.ToString() + " " +
                           "in " + "\"" + strInfix + "\": " +
                           strMessage;
            return false;
        }
    }


}


0
spinoza1111 (3246)
11/1/2009 3:28:50 PM
On Nov 1, 11:09=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> spinoza1111<spinoza1...@yahoo.com> writes:
> > On Nov 1, 10:31=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >>spinoza1111<spinoza1...@yahoo.com> writes:
>
> >> <snip>
>
> >> > I published it here to show the OP that the grammar based approach
> >> > works, and give him "pseudo code" for his C assignment, without doin=
g
> >> > his homework for him.
>
> >> > Since by now he's probably handed in his assignment, I challenge you
> >> > to translate the C Sharp code to C.
>
> >> That would not be useful. =A0Your code does not parse the language
> >> defined by the grammar, and what it does do, it does in a rather
> >> roundabout way.
>
> > If you think the grammar is correct, say so clearly. You imply it but
> > are too graceless to say it. Now the issue is whether the code
> > supports the correct grammar correctly.
>
> > You present no evidence for the first claim. As to the second, it
> > means you've never seen this simple algorithm.
>
> The evidence of the first is the truth of the second. =A0The evidence
> for the second is the code you posted. =A0The set of strings that it
> accepts is not a mystery. =A0Whether that set is the same as the
> language defined by the grammar is simple matter of fact. =A0All the
> evidence is there.
>
> What you mean, I think, is that I am not being helpful enough. =A0You
> don't want to take the time to understand or test your code and you'd

Hey, asshole:

This is just absurd. I refer you to the effort I made to provide a
regression test. As a result, I have addressed EACH ISSUE you have
raised by email. Do me the courtesy of not enabling the jerks in this
ng and admitting this.

> like me to help more. =A0If you want help writing a recursive descent

I wrote a book on doing this, but I of course need help as do we all
when we code, even in a language with which we're familiar, because,
as Dijsktra knew and you don't seem to, software is hard. When will
you learn this simple lesson?

Perhaps a new form of personality disorder exists in which one doesn't
make errors found by others, but if this is so, I see this ability
only in people with serious personality disorders. These may be an
artifact of overfocus on code, but in view of the damage they do to
both the people with these disorders and the targets of their vicious
little tirades, I don't think it's worth it...especially since we know
how, through the collegial and humane structured walkthrough from
which we exclude both managers and autistic twerps, to eradicate bugs.

> parser, post a question in a group where it is topical. =A0If you want
> help with you C#, post in a C# group. =A0The details are off topic here.
>
> You are probably correct about the last point: I may never have seen
> that particular algorithm. =A0There are lots of incorrect parsing
> algorithms and despite having seen, literally, hundreds of students
> try to do what you tried, I may well never have seen that particular
> version.

It's not an incorrect algorithm. It's available in dozens of sources.
I CODED the algorithm (code isn't an algorithm) in a language in which
I'm familiar in a very limited amount of time, on the Lamma Island
ferry during a six day work week. To save time and add to ontopic
discussion, I posted the first version, which I knew probably had
bugs, for comment, since (for the last time, asshole), the OP was
supposed to write the C, not me. The C Sharp simply demonstrates how
the algorithm works.

You are welcome to find further problems. But stop acting like an
asshole in public. You are enabling the real assholes.

>
> --
> Ben.- Hide quoted text -
>
> - Show quoted text -

0
spinoza1111 (3246)
11/1/2009 3:41:13 PM
On Nov 2, 12:04=A0am, "osmium" <r124c4u...@comcast.net> wrote:
> "spinoza1111" wrote:
> >Furthermore, the idea that computer languages are even distinct is
> >absurd. That they are is a historical accident, caused by the large
> >number of errors made in language design in the early days.
>
> AFAICT, you claim involvement dating to the mid 50's, so this should be e=
asy
> for you. =A0I'd like to see your list of the large number of errors in th=
e
> design of Algol 60. =A0As a matter of fact there *was* a very good langua=
ge
> available early on, but it never caught on in the USA; and the US, IBM an=
d
> Microsoft =A0has been dominant in the computer field for a very long time=
..

Dik has documented the fact that Algol's evaluation order was
nondeterministic. We now know that this is a mistake, since we now
know how to optimize.
0
spinoza1111 (3246)
11/1/2009 3:42:16 PM
On Nov 1, 6:04=A0pm, "Malcolm McLean" <regniz...@btinternet.com> wrote:
> "spinoza1111" <spinoza1...@yahoo.com> wrote in message
>
> >Yes. The anonymous team who drafted the Spark Notes test were more
> >competent than Heathfield, just as Schildt is also more competent than
> >you.
>
> >Note that I don't say "at C" because to be competent at a mistake is
> >to be subhuman.
>
> But multiple choice tests are a mistake as well, unless they are
> psychological profile tests in womens' magazines that no-one with any sen=
se
> would take seriously.

Multiple choice tests are a reality, and should not be rejected
because they are "hard" or "contain errors". I now teach, among other
things, test preparation to Asian students who are systematically
discriminated against by American universities.

They don't have cushy jobs. They don't have Richard's leisure to
condemn the tests they must pass with high scores. Therefore I tell
them that it's not their concern if they find an error on a test.

I also tell them that the only answer they should mark should be the
best answer, and (1) there might be > 1 right answers (2) usually only
one correct answer and (3) in the case of an error in the test, the
best might not even be correct.

Nonetheless, if one has studied K & R, the Sparknotes is probably easy
because one (unless one's an autistic twerp) has learned two things in
any class, no matter how technical:

(1) The "right stuff"
(2) The favored interpretation

(2) is more important in English and other humanities but is even true
in mathematics. In the case of Sparknotes, the best answers reflect
what is usually taught and what, in practice, creates programmers who
can program, as opposed to programmers who (1) insist on always being
right and (2) start campaigns of personal destruction when their will
is thwarted.
>
> The problem is that if a question is at all interesting it will have more
> than one answer. Sure, you can ask, "which construct is portable?". Howev=
er
> the assumption that C bytes are 8 bits is probably more portable than the
> assumption that a long is at least 32 bits. 8 bit bytes are so useful tha=
t
> compiler writers fake them up even when the underlying hardware won't
> support the reads, even though the standard doesn't require this. Whilst =
on
> tiny systems int is sometimes 8 bits and long 16 bits, to encourage
> programmers to use integers that fit in registers where possible. So to
> answer a question about "portability" you need to explain the situation.
> Which won't fit in atick box.

Excellent points, all of them.

If you want to be a computer scientist, then be a computer scientist:
if you want to be a programmer, be a programmer.

0
spinoza1111 (3246)
11/1/2009 3:52:40 PM
On Nov 1, 5:07=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-11-01,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > Furthermore, the idea that computer languages are even distinct is
> > absurd. That they are is a historical accident, caused by the large
> > number of errors made in language design in the early days.
>
> Hmm. =A0You should hook up with Scott Nudds, I'm sure he'd appreciate you=
r
> insights into the merits of language design.
>
> I don't think I find your argument persuasive. =A0I do not think there ex=
ists
> a universally ideal language design; in fact, it seems to me that
> domain-specific languages are a compelling choice for many applications.
>
> I view languages as tools. =A0I expect to see a single unified language
> about the time I expect to see a single unified woodworking tool, and
> for about the same reasons.
>
> > Insofar as "knowledge" of C is knowledge of mistakes,
>
> Except you've never shown this. =A0You've asserted that it fails to confo=
rm
> to your expectations, and that you think this is a mistake, but you've no=
t
> exactly proven your point.

Are you seriously defending a()+b() reordering, not reordering a()||b
(), and backwards parameters? If so you're not qualified to speak on
programming languages in my opinion.
>
> > C has no
> > standing as an academic subject and should not be spoken of as a
> > computer language. Instead, it should be considered a pathology which
> > computer scientists must learn for the same reason doctors must learn
> > cancer.
>
> That's a whole lot of very pretty rhetoric, but again, you have to prove
> your point before arguing further from it.
>
> > People whose main claim to expertise in C should be sent to re-
> > education camps on the model of UN centres in Africa which train
> > former guerrillas in useful trades.
>
> This isn't a sentence, but if it were, I'd bet it would be a stupid

Typo. Change in to is.

> one. =A0You seem to have omitted a clause, though. =A0Anyway, don't worry=
,
> I'm almost certainly more famous for expertise in Bourne shell than
> I am for expertise in C now. =A0(And if you want to see a language which
> is chock full of astounding mistakes, Bourne shell is a true marvel
> of the art. =A0It isn't used because it's an incredibly well-designed
> language, but because it's extremely widely available and fairly
> flexible, and we've learned how to overcome most of the weaknesses.)
>
> > And the world still needs one programming language that can be used by
> > everyone. The guy on the screen in the 1984 Apple commercial was
> > right.
>
> You know, it's a shame that we wasted thousands and thousands of years
> of peoples' time researching computer science and language design when we
> coulda just watched a superbowl ad and gotten the real answer.
>
> Tell you what, just as a quick sanity check:
>
> The one programming language that can be used by everyone:
> * Should have a way to express explicit invocation of specific machine
> =A0 instructions, yes/no?

No.

> * Should completely abstract away memory management so there's no such
> =A0 things as pointers, yes/no?

What part of safe v unsafe mode don't you understand?

> * Should be designed for "intelligent" people rather than "autistic twerp=
s",
> =A0 yes/no?

A big fat YES

> * Should be accessible to people who are not particularly intelligent,
> =A0 yes/no?

A big fat NO, and intelligence is NOT measured by IQ score. It's
primarily measured (for example on the modern SAT, even though this
doesn't purport to measure intelligence) by the ability to express
oneself accurately in one's native language.

> * Should compile directly to machine-specific instructions, yes/no?

No.

> * Should be interpreted dynamically and allow for the evaluation of
> =A0 strings of text, yes/no?

Yes

>
> I'm really looking forward to your answers.
>
> -s
> --
> Copyright 2009, all wrongs reversed. =A0Peter Seebach / usenet-nos...@see=
bs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny picturesht=
tp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

0
spinoza1111 (3246)
11/1/2009 3:58:36 PM
"spinoza1111" wrote:

>Furthermore, the idea that computer languages are even distinct is
>absurd. That they are is a historical accident, caused by the large
>number of errors made in language design in the early days.

AFAICT, you claim involvement dating to the mid 50's, so this should be easy 
for you.  I'd like to see your list of the large number of errors in the 
design of Algol 60.  As a matter of fact there *was* a very good language 
available early on, but it never caught on in the USA; and the US, IBM and 
Microsoft  has been dominant in the computer field for a very long time.




0
r124c4u1022 (2303)
11/1/2009 4:04:26 PM
On 26 Oct, 04:33, Tameem <etam...@gmail.com> wrote:

> i have a string as (a+b)+8-(c/d) in Infix form.
>
> how can i convert it to postfix form using C language,,,????

have you looked at Dijkstra's Shunting-yard algorithm? Probably what
your instructor meant you to do rather than  building a parser.
0
11/1/2009 4:31:20 PM
In article <224d09b2-a327-4e77-ad0e-f71fd51b5728@m7g2000prd.googlegroups.com>,
spinoza1111  <spinoza1111@yahoo.com> wrote:
....
>You (RH, Ed) are as such contemptible.

This is news???

0
gazelle3 (1726)
11/1/2009 4:33:17 PM
On 2009-11-01, spinoza1111 <spinoza1111@yahoo.com> wrote:
> Dik has documented the fact that Algol's evaluation order was
> nondeterministic. We now know that this is a mistake, since we now
> know how to optimize.

You keep making this claim, but you never actually establish a chain of
reasoning from undisputed facts which has this as a conclusion.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/1/2009 4:44:03 PM
On 2009-11-01, spinoza1111 <spinoza1111@yahoo.com> wrote:
> You see, in practically every post you mention my "errors" in the same
> way people prefer to repeat "the errors of Schildt" as if this cite of
> a cite makes the errors more numerous.

No one seems to be doing any such thing, in either case.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/1/2009 4:44:55 PM
On 2009-11-01, spinoza1111 <spinoza1111@yahoo.com> wrote:
> Multiple choice tests are a reality, and should not be rejected
> because they are "hard" or "contain errors".

In general, multiple choice tests are less good than other tests, but
are favored anyway because of the possible for automatic scoring.  In
short, they make compromises in one attribute to score well in another.
A familiar theme; I'm surprised you aren't out campaigning against
these "mistakes."

> I also tell them that the only answer they should mark should be the
> best answer, and (1) there might be > 1 right answers (2) usually only
> one correct answer and (3) in the case of an error in the test, the
> best might not even be correct.

Seems right.

> Nonetheless, if one has studied K & R, the Sparknotes is probably easy
> because one (unless one's an autistic twerp) has learned two things in
> any class, no matter how technical:
>
> (1) The "right stuff"
> (2) The favored interpretation

That would work if they didn't have questions in which they choose an
answer which is unambiguously neither correct nor a favored interpretation.

> (2) is more important in English and other humanities but is even true
> in mathematics. In the case of Sparknotes, the best answers reflect
> what is usually taught and what, in practice, creates programmers who
> can program, as opposed to programmers who (1) insist on always being
> right and (2) start campaigns of personal destruction when their will
> is thwarted.

Actually, people who go with "what is usually taught" rather than what works
do about as well as a hypothetical structural engineer who goes with common
fashion rather than actual functionality.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/1/2009 4:48:48 PM
On 2009-11-01, spinoza1111 <spinoza1111@yahoo.com> wrote:
> On Nov 1, 5:07�pm, Seebs <usenet-nos...@seebs.net> wrote:
>> Except you've never shown this. �You've asserted that it fails to conform
>> to your expectations, and that you think this is a mistake, but you've not
>> exactly proven your point.

> Are you seriously defending a()+b() reordering, not reordering a()||b
> (), and backwards parameters?

Why, yes.

> If so you're not qualified to speak on
> programming languages in my opinion.

This is exactly my point.  Read that quoted paragraph again.
"You've asserted that it fails to conform to your expectations,
and that you think this is a mistake, but you've not exactly proven
your point."

You haven't actually made any argument for this except a bald assertion
that "intelligent" people would expect it.  You haven't established that
this is true.  You haven't established that, if it is true, it should
be a significant component of language design.  You haven't established
that it trumps other points.

I gave you a clear and concrete reason for which || should not be reordered,
which does not apply to +, but you seem unable to actually respond to or
make technical arguments.  Ironically, despite your huge wall-of-text
complaints about other people making things personal, you use your insult
of the week about ten times as often as you make actual technical statements.

We've established that you dislike me, but you haven't shown that this is
a sound basis for a change in the design of programming languages.

>> > People whose main claim to expertise in C should be sent to re-
>> > education camps on the model of UN centres in Africa which train
>> > former guerrillas in useful trades.

>> This isn't a sentence, but if it were, I'd bet it would be a stupid

> Typo. Change in to is.

Figured.

>> The one programming language that can be used by everyone:
>> * Should have a way to express explicit invocation of specific machine
>> � instructions, yes/no?

> No.

Well.  Congratulations, you've proposed that everyone use a language
that can't actually implement operating systems on most currently-available
hardware.

You fail at language design.  Thanks for playing.

>> * Should completely abstract away memory management so there's no such
>> � things as pointers, yes/no?

> What part of safe v unsafe mode don't you understand?

Hmm.  I'd guess that'd be the part where I've never heard of them?

>> * Should be designed for "intelligent" people rather than "autistic twerps",
>> � yes/no?

> A big fat YES

Expected.

>> * Should be accessible to people who are not particularly intelligent,
>> � yes/no?

> A big fat NO,

Then it can't be used by everyone, because the majority of people are
not partiicularly intelligent.

> and intelligence is NOT measured by IQ score.

Not having one, I would hardly claim that it is.  :P

> It's
> primarily measured (for example on the modern SAT, even though this
> doesn't purport to measure intelligence) by the ability to express
> oneself accurately in one's native language.

Indeed.  Which is interesting, because you suck at that.

>> * Should compile directly to machine-specific instructions, yes/no?
> No.

>> * Should be interpreted dynamically and allow for the evaluation of
>> � strings of text, yes/no?
> Yes

Well, that sounds nice on paper, but turns out to pretty much suck for anyone
who wants battery life.

Also, and this is merely a technical point, I'm sure...

How exactly is your language supposed to be implemented?  It can't be
implemented in itself.  We need something that produces machine-specific
instructions, at least for the forseeable future, to allow chips to run
code.  So that something else must be used to implement your language,
which means we can't have a single language used by everybody.

Please think these ideas through for five minutes or so before suggesting
them, 'k?

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/1/2009 4:56:05 PM
On 01 Nov 2009 09:07:09 GMT, Seebs <usenet-nospam@seebs.net>
wrote:

>On 2009-11-01, spinoza1111 <spinoza1111@yahoo.com> wrote:

>
>> People whose main claim to expertise in C should be sent to re-
>> education camps on the model of UN centres in Africa which train
>> former guerrillas in useful trades.
>
>This isn't a sentence, but if it were, I'd bet it would be a stupid
>one.  You seem to have omitted a clause, though.

It looks like a legitimate sentence to me, save that 'which'
should have been 'that'.

Welcome to alt.english.usage.

  
Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Kafka wasn't an author;
Kafka was a prophet!
0
cri (1432)
11/1/2009 5:04:29 PM
spinoza1111 wrote:

> On Nov 2, 12:04 am, "osmium" <r124c4u...@comcast.net> wrote:
>> "spinoza1111" wrote:
>>> Furthermore, the idea that computer languages are even distinct is
>>> absurd. That they are is a historical accident, caused by the large
>>> number of errors made in language design in the early days.
>>
>> AFAICT, you claim involvement dating to the mid 50's, so this should
>> be easy for you. I'd like to see your list of the large number of
>> errors in the design of Algol 60. As a matter of fact there *was* a
>> very good language available early on, but it never caught on in the
>> USA; and the US, IBM and Microsoft has been dominant in the computer
>> field for a very long time.
>
> Dik has documented the fact that Algol's evaluation order was
> nondeterministic. We now know that this is a mistake, since we now
> know how to optimize.

Now I know what you consider a "large number": one.  That casts your 
observations in a different light. 


0
r124c4u1022 (2303)
11/1/2009 5:04:59 PM
Seebs wrote:
> On 2009-11-01, spinoza1111 <spinoza1111@yahoo.com> wrote:
>> On Nov 1, 2:11 pm, Seebs <usenet-nos...@seebs.net> wrote:
[ snip ]
>> Document each error.
> 
> I'll just give you my favorite:
> 
> 	After this code executes
> 
> 	    int arr[10];
> 	    int i;
> 	    i = &arr[9] - arr;
> 
> 	what is the value of i?
> 	(A) 8
> 	(B) 9
> 	(C) 10
> 	(D) Won't compile 
> 
> Go ahead, guess what their answer is.  Guess what mine was.  And guess
> what my compiler says if I try it.  :)  (Hint:  The last two are both
> the correct answer.  Theirs isn't.)
> 

Seebs - As my new hero contra spino I tend to support you. But looking at your 
example I saw 9 - 0 which is 9. I wrote a little program (below) and compiled it 
with each of my 4 C compilers. All 4 compiled it without diags and when run, all 
4 report the value of i as 9. What did I miss?

#include <stdio.h>
int main(void)
{
    int arr[10];
    int i;
    i = &arr[9] - arr;
    printf("%d\n", i);
    return 0;
}
-- 
Joe Wright
"If you rob Peter to pay Paul you can depend on the support of Paul."
0
joewwright (1738)
11/1/2009 5:29:27 PM
On Sun, 01 Nov 2009 17:04:29 GMT, cri@tiac.net (Richard Harter)
wrote:

>On 01 Nov 2009 09:07:09 GMT, Seebs <usenet-nospam@seebs.net>
>wrote:
>
>>On 2009-11-01, spinoza1111 <spinoza1111@yahoo.com> wrote:
>
>>
>>> People whose main claim to expertise in C should be sent to re-
>>> education camps on the model of UN centres in Africa which train
>>> former guerrillas in useful trades.
>>
>>This isn't a sentence, but if it were, I'd bet it would be a stupid
>>one.  You seem to have omitted a clause, though.
>
>It looks like a legitimate sentence to me, save that 'which'
>should have been 'that'.

Oops, my bad.  There is an 'is' missing.  I'm with the wide boy
on this one, though - it's a typo.


Richard Harter, cri@tiac.net
http://home.tiac.net/~cri, http://www.varinoma.com
Kafka wasn't an author;
Kafka was a prophet!
0
cri (1432)
11/1/2009 5:37:08 PM
On 2009-11-01, Joe Wright <joewwright@comcast.net> wrote:
> Seebs wrote:
>> I'll just give you my favorite:
>> 
>> 	After this code executes
>> 
>> 	    int arr[10];
>> 	    int i;
>> 	    i = &arr[9] - arr;
>> 
>> 	what is the value of i?
>> 	(A) 8
>> 	(B) 9
>> 	(C) 10
>> 	(D) Won't compile 

>> Go ahead, guess what their answer is.  Guess what mine was.  And guess
>> what my compiler says if I try it.  :)  (Hint:  The last two are both
>> the correct answer.  Theirs isn't.)

> Seebs - As my new hero contra spino I tend to support you. But looking
> at your example I saw 9 - 0 which is 9. I wrote a little program (below)
> and compiled it with each of my 4 C compilers. All 4 compiled it without
> diags and when run, all 4 report the value of i as 9. What did I miss?

You missed nothing.  The sparknotes people, however, feel that the answer
is (C) 10.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/1/2009 5:46:19 PM
On Nov 2, 1:37=A0am, c...@tiac.net (Richard Harter) wrote:
> On Sun, 01 Nov 2009 17:04:29 GMT, c...@tiac.net (Richard Harter)
> wrote:
>
> >On 01 Nov 2009 09:07:09 GMT, Seebs <usenet-nos...@seebs.net>
> >wrote:
>
> >>On 2009-11-01,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> >>> People whose main claim to expertise in C should be sent to re-
> >>> education camps on the model of UN centres in Africa which train
> >>> former guerrillas in useful trades.
>
> >>This isn't a sentence, but if it were, I'd bet it would be a stupid
> >>one. =A0You seem to have omitted a clause, though.
>
> >It looks like a legitimate sentence to me, save that 'which'
> >should have been 'that'.
>
> Oops, my bad. =A0There is an 'is' missing. =A0I'm with the wide boy
> on this one, though - it's a typo.
>
> Richard Harter, c...@tiac.nethttp://home.tiac.net/~cri,http://www.varinom=
a.com
> Kafka wasn't an author;
> Kafka was a prophet!

Let me all save you guys a lot of trouble:

People whose main claim to expertise IS C should be sent to re-
> >>> education camps on the model of UN centres in Africa which train
> >>> former guerrillas in useful trades.

The subject is people subsetted by those whose main claim is C. The
main verb is modal: "should be sent". The indirect object is "re-
education camps". This should be done "on the model of ", which is an
adverbial.
0
spinoza1111 (3246)
11/1/2009 5:46:31 PM
In <SZidnf5Dh-rrWHDXnZ2dnUVZ_tmdnZ2d@giganews.com>, Joe Wright wrote:

> Seebs wrote:
>> On 2009-11-01, spinoza1111 <spinoza1111@yahoo.com> wrote:
>>> On Nov 1, 2:11 pm, Seebs <usenet-nos...@seebs.net> wrote:
> [ snip ]
>>> Document each error.
>> 
>> I'll just give you my favorite:
>> 
>> After this code executes
>> 
>> int arr[10];
>> int i;
>> i = &arr[9] - arr;
>> 
>> what is the value of i?
>> (A) 8
>> (B) 9
>> (C) 10
>> (D) Won't compile
>> 
>> Go ahead, guess what their answer is.  Guess what mine was.  And
>> guess
>> what my compiler says if I try it.  :)  (Hint:  The last two are
>> both
>> the correct answer.  Theirs isn't.)
>> 
> 
> Seebs - As my new hero contra spino I tend to support you. But
> looking at your example I saw 9 - 0 which is 9. I wrote a little
> program (below) and compiled it with each of my 4 C compilers. All 4
> compiled it without diags and when run, all 4 report the value of i
> as 9. What did I miss?

What you missed is probably the correct interpretation of "the last 
two". It threw me for a moment as well. At first I thought he meant 
"(C) and (D)", which doesn't work at all. I was about to tell him so, 
and then... <voice tone="silly"> weeeelllll, I got to thinking about 
that, and I thought, this is Seebs, would he really be that dumb?, 
and then I thought, maybe he means some other "last two"</voice>, and 
it turns out that by "the last two" he means (1) "what my answer was" 
and (2) "what my compiler says if I try it". We are left to infer 
that his answer, and the compiler's answer, are (B) 9, unlike "their 
answer", (C) 10 (which is of course wrong).

<snip>

-- 
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
0
rjh (10791)
11/1/2009 5:47:57 PM
Richard Heathfield <rjh@see.sig.invalid> writes:
[...]
> 17. (d) is undoubtedly the intended answer. In C, the value of NULL is 
> always 0. Its type is either int or void *.
[...]

Tiny quibble: The type of NULL can be void* or any integer type.
For example:
    #define NULL 0ULL
is legal.

(Actually, I'm not certain it can be an integer type narrower than
int.)

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
kst-u (21963)
11/1/2009 6:30:06 PM
"Malcolm McLean" <regniztar@btinternet.com> writes:

> "Ben Bacarisse" <ben.usenet@bsb.me.uk> wrote in message
>>
>> That would not be useful.  Your code does not parse the language
>> defined by the grammar, and what it does do, it does in a rather
>> roundabout way.
>>
> Computer code frquently contains errors which are simple lapses of logic. To 
> the layman, these might seem to be the result of inexperience. Actually even 
> highly-qualified programmers of twenty years' or more experience make such 
> errors, and not infrequently either.

True.  Spiniza1111 may be highly qualified and very experienced but
the grammar he posted was wrong and then the code that purports to
parse the corrected grammar did not do so.  These may be due to simple
lapses of logic, but Spiniza1111 was suggesting that the code be used
as a model to follow.  I thought (maybe wrongly) that it was worth
discouraging that use.

> To allude to a bug is a very bad way of making a bug report.

I am not making a bug report.  I don't want to facilitate
Spiniza1111's desire to have an off-topic discussion of his C# code
here.  Saying nothing may have been preferable.

<snip>
-- 
Ben.
0
ben.usenet (6790)
11/1/2009 8:57:50 PM
On Nov 2, 4:57=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> "Malcolm McLean" <regniz...@btinternet.com> writes:
> > "Ben Bacarisse" <ben.use...@bsb.me.uk> wrote in message
>
> >> That would not be useful. =A0Your code does not parse the language
> >> defined by the grammar, and what it does do, it does in a rather
> >> roundabout way.
>
> > Computer code frquently contains errors which are simple lapses of logi=
c. To
> > the layman, these might seem to be the result of inexperience. Actually=
 even
> > highly-qualified programmers of twenty years' or more experience make s=
uch
> > errors, and not infrequently either.
>
> True. =A0Spiniza1111 may be highly qualified and very experienced but
> the grammar he posted was wrong and then the code that purports to
> parse the corrected grammar did not do so. =A0These may be due to simple
> lapses of logic, but Spiniza1111 was suggesting that the code be used
> as a model to follow. =A0I thought (maybe wrongly) that it was worth
> discouraging that use.

Ben, do you make the above claim about the most recent version, or are
you deliberately using past tense in order to dishonestly persist in a
claim? If so, you are indeed an "asshole" after all.
>
> > To allude to a bug is a very bad way of making a bug report.
>
> I am not making a bug report. =A0I don't want to facilitate
> Spiniza1111's desire to have an off-topic discussion of his C# code
> here. =A0Saying nothing may have been preferable.
>
> <snip>
> --
> Ben.

0
spinoza1111 (3246)
11/2/2009 2:24:45 AM
On Nov 2, 12:48=A0am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-11-01,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > Multiple choice tests are a reality, and should not be rejected
> > because they are "hard" or "contain errors".
>
> In general, multiple choice tests are less good than other tests, but
> are favored anyway because of the possible for automatic scoring. =A0In
> short, they make compromises in one attribute to score well in another.
> A familiar theme; I'm surprised you aren't out campaigning against
> these "mistakes."
>
> > I also tell them that the only answer they should mark should be the
> > best answer, and (1) there might be > 1 right answers (2) usually only
> > one correct answer and (3) in the case of an error in the test, the
> > best might not even be correct.
>
> Seems right.
>
> > Nonetheless, if one has studied K & R, the Sparknotes is probably easy
> > because one (unless one's an autistic twerp) has learned two things in
> > any class, no matter how technical:
>
> > (1) The "right stuff"
> > (2) The favored interpretation
>
> That would work if they didn't have questions in which they choose an
> answer which is unambiguously neither correct nor a favored interpretatio=
n.
>
> > (2) is more important in English and other humanities but is even true
> > in mathematics. In the case of Sparknotes, the best answers reflect
> > what is usually taught and what, in practice, creates programmers who
> > can program, as opposed to programmers who (1) insist on always being
> > right and (2) start campaigns of personal destruction when their will
> > is thwarted.
>
> Actually, people who go with "what is usually taught" rather than what wo=
rks
> do about as well as a hypothetical structural engineer who goes with comm=
on
> fashion rather than actual functionality.

Programmers are not engineers. Engineers have legal certification
procedures which programmers do not have. Programmers compare
themselves to engineers, but the best coder here, Bacarisse, prefers
at the crisis to stop reviewing code and make assertions about the
first version of the C Sharp parsing solution to Malcolm without
acknowledging whether or not the third version addresses his concerns.
Engineers don't do this because their limited job security provides
them the self-confidence and self-esteem of adults, a self-confidence
and self-esteem that is lacking in nearly every programmer I have
known.

At the Glosten Associates in Seattle in 1986, I wrote the first
version of their very successful GSSP graphical program for ship
stability. I worked with men certified as Ocean Engineers and I was
very impressed by their decency. Years later, during the Iraq war, I
met them again at a shipping conference and was also impressed to
learn that the company was not trying to get contracts in Iraq because
most of its employees and its principals felt this to be folly. This
is what integrity looks like. It's not trying to weasel out of your
responsiblities to decency by claiming a fashionable disease such as
autism.

I posted a C Sharp "prototype" here in answer to the OP's question in
order to back up my claim that the problem of converting infix to
Polish can be solved by a formal grammar approach. Bacarisse asserted
in public without proof that the prototype was broken despite also
implying that he didn't know C Sharp.

Because I respect his coding and analysis skills I asked for further
comment. I received private email which indicated that, despite
Bacarisse's claim that he didn't know C Sharp, he'd nonetheless ran
the code, using a C Sharp system, possibly free .Net "Express".

He found several problems. All but one I'd found independent of him
within 24 hours of posting the code, and they were caused by missing
bounds checks which I'd already added. The last was failure to emit an
error report when parentheses were unbalanced and this I fixed in the
third version.

Whenever someone uses an approach, or here, a closely related
programming language meant to fix C, that others don't feel qualified
to work with, it's "off-topic". But the politics of personal
destruction are always on-topic, and I shall at will from now on start
using words like "asshole" to describe people who think they are being
cute when they engage in these politics.

I have yet to see Richard Heathfield or Peter Seebach simulate what
computer science teachers and teachers of programming have to do in
the classroom. This is write pseudo or real code on the board and
explain it. Neither seem capable of posting other than canned replies
and neither are willing to take the risk. Only Keith Thompson has the
combination of technical integrity and courage to do so.

I believe it's possible for an intelligent programmer to intelligently
comment about reasonably clear code in a language HE DOES NOT KNOW,
and I believe that for the same reason as in the traditional
structured walkthough comments from all are welcome, people here
should have the courage to step outside their comfort zones and study
non-C code that's germane to the issue. The problem is that little
coders are desparately afraid to do so, and prefer being Snidely
Snively to being men.

In my very limited spare time I am converting my little parser to C to
RElearn more about C in order to better defend Schildt, with all of
his flaws, because I think collegiality and decency are far more
important than being a cute little asshole of a computer programmer,
who's used, in our society, to create wealth for the wealthy and then
thrown aside at the age of 40. When I have something I will post it to
this thread.

When will you people grow up? Hopefully before I have to become a C
expert for the second time in my life!
>
> -s
> --
> Copyright 2009, all wrongs reversed. =A0Peter Seebach / usenet-nos...@see=
bs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny picturesht=
tp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

0
spinoza1111 (3246)
11/2/2009 2:48:31 AM
On Nov 2, 4:57=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> "Malcolm McLean" <regniz...@btinternet.com> writes:
> > "Ben Bacarisse" <ben.use...@bsb.me.uk> wrote in message
>
> >> That would not be useful. =A0Your code does not parse the language
> >> defined by the grammar, and what it does do, it does in a rather
> >> roundabout way.
>
> > Computer code frquently contains errors which are simple lapses of logi=
c. To
> > the layman, these might seem to be the result of inexperience. Actually=
 even
> > highly-qualified programmers of twenty years' or more experience make s=
uch
> > errors, and not infrequently either.
>
> True. =A0Spiniza1111 may be highly qualified and very experienced but
> the grammar he posted was wrong and then the code that purports to

The first version was wrong.

> parse the corrected grammar did not do so. =A0These may be due to simple

The first version didn't test out of bounds in all cases. The second
version failed to flag unbalanced parentheses. Both versions were
instrumented with far more literate error reports and far more
thorough test cases than 99% of the code posted here, and little
enough new code is ever posted, even in C, because people prefer being
assholes.

The third version addresses all your concerns.

Stop being an asshole.

> lapses of logic, but Spiniza1111 was suggesting that the code be used
> as a model to follow. =A0I thought (maybe wrongly) that it was worth
> discouraging that use.
>
> > To allude to a bug is a very bad way of making a bug report.
>
> I am not making a bug report. =A0I don't want to facilitate
> Spiniza1111's desire to have an off-topic discussion of his C# code
> here. =A0Saying nothing may have been preferable.
>
> <snip>
> --
> Ben.

0
spinoza1111 (3246)
11/2/2009 2:52:13 AM
Keith Thompson <ks...@mib.org> wrote:
> ...
> (Actually, I'm not certain [NULL] can be an integer type
> narrower than int.)

  #define NULL ((char)0)

--
Peter
0
airia (1802)
11/2/2009 2:53:14 AM
spinoza1111 <spinoza1111@yahoo.com> writes:

> On Nov 2, 4:57 am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> "Malcolm McLean" <regniz...@btinternet.com> writes:
>> > "Ben Bacarisse" <ben.use...@bsb.me.uk> wrote in message
>>
>> >> That would not be useful.  Your code does not parse the language
>> >> defined by the grammar, and what it does do, it does in a rather
>> >> roundabout way.
>>
>> > Computer code frquently contains errors which are simple lapses of logic. To
>> > the layman, these might seem to be the result of inexperience. Actually even
>> > highly-qualified programmers of twenty years' or more experience make such
>> > errors, and not infrequently either.
>>
>> True.  Spiniza1111 may be highly qualified and very experienced but
>> the grammar he posted was wrong and then the code that purports to
>> parse the corrected grammar did not do so.  These may be due to simple
>> lapses of logic, but Spiniza1111 was suggesting that the code be used
>> as a model to follow.  I thought (maybe wrongly) that it was worth
>> discouraging that use.
>
> Ben, do you make the above claim about the most recent version,

No.

> or are
> you deliberately using past tense in order to dishonestly persist in a
> claim?

I used the past tense to talk about what I had said because that is
what Malcolm commented on.

<snip>
-- 
Ben.
0
ben.usenet (6790)
11/2/2009 3:17:46 AM
Peter Nilsson <airia@acay.com.au> writes:
> Keith Thompson <ks...@mib.org> wrote:
>> ...
>> (Actually, I'm not certain [NULL] can be an integer type
>> narrower than int.)
>
>   #define NULL ((char)0)

Yes, I should have thought of that, thanks.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
kst-u (21963)
11/2/2009 5:45:12 AM
On 31 Oct 2009, Seebs <usenet-nospam@seebs.net> wrote:

> On 2009-11-01, spinoza1111 <spinoza1111@yahoo.com> wrote:
>> On Nov 1, 2:11�pm, Seebs <usenet-nos...@seebs.net> wrote:

<snip>

>> Arguably less than smart people because stupid people have to
>> work at 7-11 where their actions are monitored, or on funny
>> little embedded systems as opposed to actually important
>> systems such as Microsoft boxes, and their work is constantly
>> checked. 

Wow.

> Oh, I see.  You're trying to sneakily imply that I'm stupid. 
> No, not buying it.  I certainly have my cognitive flaws, but
> "stupidity" is not one of them.

Am I interpreting spinoza1111's remark here correctly?  It also 
seems he is slighting programmers who work on embedded systems.  I 
suppose this shouldn't be surprising, but it's just so painfully 
absurd.  The many contributions of embedded systems programmers (I'm 
not one, but do admire them) are demonstrably undeniable.

<snip>

-- 
"Don't worry about efficiency until you've attained correctness."
  ~ Eric Sosman, comp.lang.c
0
dyer85 (342)
11/2/2009 9:53:20 AM
This post contains the promised C code version of the infix to Polish
notation convertor. When run from the command line it should execute
all cases used to test the C Sharp version correctly. Its string
handling is simpler owing to the limitations of C.

This code unless it is seriously fucked up demonstrates the
practicality of using a formal language based approach to infix to
Polish notation. It's also part of my project of relearning C.

Comments as opposed to BS welcome.


#include <stdio.H>

#include <stdlib.H>

#define MAX_POLISH_LENGTH 100

int errorHandler(char *strMessage)
{
	printf("\n%s\n", strMessage); return 0;
}

int errorHandlerSyntax(int intIndex, char *strMessage)
{
	printf("\nError at character %d: %s\n",
		   intIndex,
		   strMessage);
	return 0;
}

int stringLength(char *strInstring)
{
	int intIndex1;
	for (intIndex1 = 0;
		 strInstring[intIndex1] != '\0';
		 intIndex1++) { }
	return intIndex1;
}

int stringAppendChar(char *strInstring,
     				 char chrNew,
					 int intMaxLength)
{
	int intLength = stringLength(strInstring);
	if (intLength >= intMaxLength - 1)
	{
		errorHandler
			("Cannot append character: string too long");
		return 0;
	}
	strInstring[intLength] = chrNew;
	strInstring[intLength + 1] = '\0';
	return -1;
}

int appendPolish(char *strPolish, char chrNext)
{
	return
		((*strPolish == '\0' || *strPolish == ' ')
		 ?
		 -1
		 :
		 stringAppendChar(strPolish,
		                  ' ',
						  MAX_POLISH_LENGTH))
        &&
		stringAppendChar(strPolish,
		                 chrNext,
						 MAX_POLISH_LENGTH)
        &&
		stringAppendChar(strPolish, ' ', MAX_POLISH_LENGTH);
}

int expression(char *strInfix,
			   char *strPolish,
			   int *intPtrIndex,
			   int intEnd);

int mulFactor(char *strInfix,
			  char *strPolish,
			  int *intPtrIndex,
			  int intEnd)
{ /* mulFactor = LETTER | NUMBER | '(' expression ')' */
	int intIndexStart = 0;
	int intLevel = 0;
	char chrNext = ' ';
	int intInner;
	if (*intPtrIndex > intEnd)
		return errorHandlerSyntax(*intPtrIndex,
		                          "mulFactor unavailable");
	chrNext = strInfix[*intPtrIndex];
	if (chrNext >= 'a' && chrNext <= 'z')
	{
		(*intPtrIndex)++;
		return appendPolish(strPolish, chrNext);
	}
	intIndexStart = *intPtrIndex;
	while(*intPtrIndex <= intEnd
		  &&
          (chrNext = strInfix[*intPtrIndex]) >= '0'
		  &&
		  chrNext <= '9')
	{
		if (!stringAppendChar(strPolish,
			                  chrNext,
							  MAX_POLISH_LENGTH))
			return 0;
		(*intPtrIndex)++;
	}
	if (*intPtrIndex > intIndexStart)
		return stringAppendChar(strPolish,
		                        ' ',
								MAX_POLISH_LENGTH);
	if (chrNext == '(')
	{
		intLevel = 1;
		(*intPtrIndex)++;
		intInner = *intPtrIndex;
		while (intLevel > 0 && *intPtrIndex <= intEnd)
		{
			if ((chrNext = strInfix[(*intPtrIndex)++]) == '(')
			{
				intLevel++;
			}
			else
			{
				if (chrNext == ')')
				{
					intLevel--;
				}
			}
		}
		if (intLevel > 0)
			return errorHandlerSyntax
			       (intInner - 1,
			        "Unbalanced left parenthesis");
		if (!expression(strInfix,
			            strPolish,
						&intInner,
						*intPtrIndex - 2))
			return errorHandlerSyntax
			       (intInner,
			        "Expression doesn't appear in parentheses");
		//(*intPtrIndex)++;
		return -1;
	}
	return 0;
}

int addFactor(char *strInfix,
			  char *strPolish,
			  int *intPtrIndex,
			  int intEnd)
{ /* addFactor = mulFactor [ *|/ mulFactor ] */
	char chrMulOp = ' ';
	int intStartIndex = 0;
	if (!mulFactor(strInfix, strPolish, intPtrIndex, intEnd))
	{
		errorHandlerSyntax(*intPtrIndex, "mulFactor not found");
		return 0;
	}
	if (*intPtrIndex > intEnd) return -1;
	intStartIndex = *intPtrIndex;
    while (*intPtrIndex <= intEnd)
    {
        if ((chrMulOp = strInfix[*intPtrIndex]) != '*'
            &&
            chrMulOp != '/')
			return -1;
        (*intPtrIndex)++;
        if (*intPtrIndex > intEnd
            ||
            !mulFactor(strInfix,
                       strPolish,
                       intPtrIndex,
					   intEnd))
            return errorHandlerSyntax
                   (*intPtrIndex,
                    "Mul/div op not followed by mulFactor");
        if (!appendPolish(strPolish, chrMulOp)) return 0;
    }
	return -1;
}

int expression(char *strInfix,
			   char *strPolish,
			   int *intPtrIndex,
			   int intEnd)
{   /* expression = addFactor [ +|- addFactor ] */
	char chrAddOp = ' ';
	int intStartIndex = 0;
	if (!addFactor(strInfix, strPolish, intPtrIndex, intEnd))
	{
		errorHandlerSyntax(*intPtrIndex, "addFactor not found");
		return 0;
	}
	intStartIndex = *intPtrIndex;
    while (*intPtrIndex <= intEnd)
    {
        if ((chrAddOp = strInfix[*intPtrIndex]) != '+'
            &&
            chrAddOp != '-')
			return -1;
        (*intPtrIndex)++;
        if (*intPtrIndex > intEnd
            ||
            !addFactor(strInfix,
                       strPolish,
                       intPtrIndex,
                       intEnd))
            return errorHandlerSyntax
                   (*intPtrIndex,
                    "Add/sub op not followed by addFactor");
        appendPolish(strPolish, chrAddOp);
    }
	return -1;
}

char *infix2Polish(char *strInfix)
{
	int intIndex = 0;
	char *strPolish = malloc(MAX_POLISH_LENGTH);
	if (strPolish == 0)
		errorHandler("Can't get storage");
	strPolish[0] = '\0';
	if (!expression(strInfix,
		            strPolish,
					&intIndex,
					stringLength(strInfix) - 1))
	{
		errorHandler("Can't parse expression");
		return "";
	}
	return strPolish;
}

void tester()
{
	printf("Expect 10 113 + a *: %s\n",
		   infix2Polish("(10+113)*a"));
	printf("Expect error (see above): %s\n",
		   infix2Polish("("));
	printf("Expect error (see above): %s\n",
		   infix2Polish("((((2"));
	printf("Expect error (see above): %s\n",
		   infix2Polish("////2"));
	printf("Expect error (see above): %s\n",
		   infix2Polish(""));
	printf("Expect error (see above): %s\n",
		   infix2Polish("("));
	printf("Expect error (see above): %s\n",
		   infix2Polish("()"));
	printf("Expect error (see above): %s\n",
		   infix2Polish("(((5))"));
	printf("Expect 5: %s\n",
		   infix2Polish("(((5)))"));
	printf("Expect 5: %s\n",
		   infix2Polish("((5))"));
	printf("Expect 10 113 2 2 4 3 + / + 2 + 2 + - + a *: %s\n",
		   infix2Polish("((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a"));
	printf("Expect 1: %s\n",
		   infix2Polish("1"));
	printf("Expect 1 1 +: %s\n",
		   infix2Polish("1+1"));
	printf("Expect a: %s\n",
		   infix2Polish("a"));
	printf("Expect a b +: %s\n",
		   infix2Polish("a+b"));
}

int main(int intArgCount, char **strArgs)
{
    tester();
    return;
}
0
spinoza1111 (3246)
11/2/2009 11:01:24 AM
On 2 Nov, 09:53, Curtis Dyer <dye...@gmail.com> wrote:
> On 31 Oct 2009, Seebs <usenet-nos...@seebs.net> wrote:
>
> > On 2009-11-01, spinoza1111 <spinoza1...@yahoo.com> wrote:
> >> On Nov 1, 2:11=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> <snip>
>
> >> Arguably less than smart people because stupid people have to
> >> work at 7-11 where their actions are monitored, or on funny
> >> little embedded systems as opposed to actually important
> >> systems such as Microsoft boxes, and their work is constantly
> >> checked.
>
> Wow.
>
> > Oh, I see. =A0You're trying to sneakily imply that I'm stupid.
> > No, not buying it. =A0I certainly have my cognitive flaws, but
> > "stupidity" is not one of them.
>
> Am I interpreting spinoza1111's remark here correctly? =A0It also
> seems he is slighting programmers who work on embedded systems. =A0I
> suppose this shouldn't be surprising, but it's just so painfully
> absurd. =A0The many contributions of embedded systems programmers (I'm
> not one, but do admire them) are demonstrably undeniable.

in many cases I'd be much more scared of bad programming practices in
an embedded system (think anti-lock brakes) than in a Microsoft box.
0
11/2/2009 11:34:04 AM
On 1 Nov, 08:55, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Nov 1, 4:34=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> > On 2009-11-01,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > > I will take Peter's and Richard's silence on these posts to indicate
> > > incompetence to study this code and find flaws.
>
> > I don't know the language you wrote it in, and also don't feel a lot of
> > need to try to find flaws in your code.
>
> > Write something in a language I know and post it in an appropriate grou=
p
>
> Furthermore, the idea that computer languages are even distinct is
> absurd. That they are is a historical accident, caused by the large
> number of errors made in language design in the early days.
>
> Insofar as "knowledge" of C is knowledge of mistakes, C has no
> standing as an academic subject and should not be spoken of as a
> computer language. Instead, it should be considered a pathology which
> computer scientists must learn for the same reason doctors must learn
> cancer.
>
> People whose main claim to expertise in C should be sent to re-
> education camps on the model of UN centres in Africa which train
> former guerrillas in useful trades.
>
> And the world still needs one programming language that can be used by
> everyone. The guy on the screen in the 1984 Apple commercial was
> right.

Could you review this? (the utility library only provides the unit-
test and display-line functions)


*********************************************************************

;;; infix_postfix.scm
;;;
;;; infix to postscript converter

(load "library/utilities.scm")


;;;
;;; stack
(define (_stack-list s) (car s))   ; for internal use
(define (make-stack) '(()))
(define (stack-empty? s) (null? (_stack-list s)))
(define (stack-push! s item) (set-car! s (cons item (_stack-list s))))
(define (stack-top s)
    (if (stack-empty? s) (error "empty stack"))
    (car (_stack-list s)))
(define (stack-pop! s)
    (let ((top (stack-top s)))
        (set-car! s (cdr (_stack-list s)))
        top))

;;;
;;; queue
; BEWARE: make-queue etc. are built-ins in chicken scheme
(define (_q-list q) (car q))   ; for internal use
(define (make-q) '(()))
(define (clear-q q) (set-car! q '()))
(define (q-empty? q) (null? (_q-list q)))

(define (q-add! q item)
    (let ((new-q (append (_q-list q) (list item))))
        (set-car! q new-q)))

(define (q-remove! q)
    (if (q-empty? q) (error "empty queue"))
    (let ((item (car (_q-list q))))
        (set-car! q (cdr (_q-list q)))
        item))

(define (q->list q) (_q-list q))


;;;
;;; token-stream
(define (make-tokstream s) (list s))

(define (tokstream-get! ts)
    (define (empty? s) (zero? (string-length s)))
    (let loop ((s (car ts)))
        (if (empty? s)
            '()
            (let ((first (string-ref s 0)))
                (if (char=3D? first #\space)
                    (loop (substring s 1 (string-length s)))
                    (begin
                        (set-car! ts (substring s 1 (string-length
s)))
                        first))))))

(define (tokstream->list ts) (car ts))


;;;
;;; infix to postfix conversion

;; the operators and their precedence
(define operators '((#\+ 1) (#\- 1) (#\* 2) (#\/ 2)))


;; converts infix to postfix using Dijkstra's Shunting Yard algorithm
;; the algorithm is from the Wikipedia article on the algorithm
(define (infix->postfix infix)
    (let (
        (in (make-tokstream infix))
        (stack (make-stack))
        (output (make-q)))

        (define (operand? tok) (char-alphabetic? tok))
        (define (operator? tok) (assq tok operators))
        (define (open-brak? tok) (char=3D? tok #\())    ; beware
confuses syntax hiliter
        (define (close-brak? tok) (char=3D? tok #\)))   ; beware
confuses syntax hiliter
        (define (precedence op) (cadr (assq op operators)))
        (define (do-operand token) (q-add! output token))
        (define (do-open-brak tok) (stack-push! stack tok))

        (define (do-close-brak tok)
            (let until-open-brak ((x '()))
                (if (stack-empty? stack) (error "missing closing
bracket"))
                (if (open-brak? (stack-top stack))
                    (stack-pop! stack)   ; discard bracket
                    (begin
                        (q-add! output (stack-pop! stack))
                        (until-open-brak '())))))

        (define (do-operator token)
            (let while-operators ((x '()))
                (if (and (not (stack-empty? stack)) (operator? (stack-
top stack)))
                    (if (<=3D (precedence token) (precedence (stack-top
stack)) )
                        (begin
                            (q-add! output (stack-pop! stack))
                            (while-operators x)))))
            (stack-push! stack token))

        (define (flush-stack)
            (let loop ((x '()))   ; x is a dummy argument
                (if (not (stack-empty? stack))
                    (if (or (open-brak? (stack-top stack))
                            (close-brak? (stack-top stack)))
                        (error "infix->postfix: mismatched bracket")
                        (begin
                            (q-add! output (stack-pop! stack))
                            (loop '())
                         )))))

        ; turn the output queue into a string
        (define (create-output-string)
            (let loop ((s ""))
                (if (not (q-empty? output))
                    (loop (string-append
                        s
                        (if (zero? (string-length s)) "" " ")
                        (string (q-remove! output))))
                    s)))

        (define (trace-me token)
            (display-line "infix-postfix: processing token" token
                "stream" (tokstream->list in)
                "output" (q->list output)))

        ; infix->postfix body
        (clear-q output)   ; bug work-around
        (if (not (q-empty? output)) (error "output queue not empty!"))
        (let while-tokens ((token (tokstream-get! in)))
            ;(trace-me token)
            (if (not (null? token))
                (begin
                    (cond
                        ((operand? token) (do-operand token))
                        ((operator? token) (do-operator token))
                        ((open-brak? token) (do-open-brak token))
                        ((close-brak? token) (do-close-brak token))
                        (else (error "unrecognised token")))
                    (while-tokens (tokstream-get! in)))))

        ; no more tokens
        (flush-stack)
        (create-output-string)
))   ; end infix->postfix


;;;
;;; test harness

(define (test-infix->postfix)
    (unit-test infix->postfix string=3D? ("a + b * c") "a b c * +")
    (unit-test infix->postfix string=3D? ("a + b - c") "a b + c -")
    (unit-test infix->postfix string=3D? ("a * b - c") "a b * c -")
    (unit-test infix->postfix string=3D? ("(a + b) * c") "a b + c *")
    (unit-test infix->postfix string=3D? ("(a+b)+z-(c/d)") "a b + z + c
d / -")
    'all-tests-ok)


*********************************************************************

This version doesn't handle numbers, function calls or right-
associative operators. The trace-me was used for debugging






0
11/2/2009 11:44:42 AM
On Nov 2, 7:44=A0pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 1 Nov, 08:55,spinoza1111<spinoza1...@yahoo.com> wrote:
>
>
>
>
>
> > On Nov 1, 4:34=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> > > On 2009-11-01,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > > > I will take Peter's and Richard's silence on these posts to indicat=
e
> > > > incompetence to study this code and find flaws.
>
> > > I don't know the language you wrote it in, and also don't feel a lot =
of
> > > need to try to find flaws in your code.
>
> > > Write something in a language I know and post it in an appropriate gr=
oup
>
> > Furthermore, the idea that computer languages are even distinct is
> > absurd. That they are is a historical accident, caused by the large
> > number of errors made in language design in the early days.
>
> > Insofar as "knowledge" of C is knowledge of mistakes, C has no
> > standing as an academic subject and should not be spoken of as a
> > computer language. Instead, it should be considered a pathology which
> > computer scientists must learn for the same reason doctors must learn
> > cancer.
>
> > People whose main claim to expertise in C should be sent to re-
> > education camps on the model of UN centres in Africa which train
> > former guerrillas in useful trades.
>
> > And the world still needs one programming language that can be used by
> > everyone. The guy on the screen in the 1984 Apple commercial was
> > right.
>
> Could you review this? (the utility library only provides the unit-
> test and display-line functions)
>
> *********************************************************************
>
> ;;; infix_postfix.scm
> ;;;
> ;;; infix to postscript converter
>
> (load "library/utilities.scm")
>
> ;;;
> ;;; stack
> (define (_stack-list s) (car s)) =A0 ; for internal use
> (define (make-stack) '(()))
> (define (stack-empty? s) (null? (_stack-list s)))
> (define (stack-push! s item) (set-car! s (cons item (_stack-list s))))
> (define (stack-top s)
> =A0 =A0 (if (stack-empty? s) (error "empty stack"))
> =A0 =A0 (car (_stack-list s)))
> (define (stack-pop! s)
> =A0 =A0 (let ((top (stack-top s)))
> =A0 =A0 =A0 =A0 (set-car! s (cdr (_stack-list s)))
> =A0 =A0 =A0 =A0 top))
>
> ;;;
> ;;; queue
> ; BEWARE: make-queue etc. are built-ins in chicken scheme
> (define (_q-list q) (car q)) =A0 ; for internal use
> (define (make-q) '(()))
> (define (clear-q q) (set-car! q '()))
> (define (q-empty? q) (null? (_q-list q)))
>
> (define (q-add! q item)
> =A0 =A0 (let ((new-q (append (_q-list q) (list item))))
> =A0 =A0 =A0 =A0 (set-car! q new-q)))
>
> (define (q-remove! q)
> =A0 =A0 (if (q-empty? q) (error "empty queue"))
> =A0 =A0 (let ((item (car (_q-list q))))
> =A0 =A0 =A0 =A0 (set-car! q (cdr (_q-list q)))
> =A0 =A0 =A0 =A0 item))
>
> (define (q->list q) (_q-list q))
>
> ;;;
> ;;; token-stream
> (define (make-tokstream s) (list s))
>
> (define (tokstream-get! ts)
> =A0 =A0 (define (empty? s) (zero? (string-length s)))
> =A0 =A0 (let loop ((s (car ts)))
> =A0 =A0 =A0 =A0 (if (empty? s)
> =A0 =A0 =A0 =A0 =A0 =A0 '()
> =A0 =A0 =A0 =A0 =A0 =A0 (let ((first (string-ref s 0)))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (if (char=3D? first #\space)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (loop (substring s 1 (string-leng=
th s)))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (begin
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (set-car! ts (substring s=
 1 (string-length
> s)))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 first))))))
>
> (define (tokstream->list ts) (car ts))
>
> ;;;
> ;;; infix to postfix conversion
>
> ;; the operators and their precedence
> (define operators '((#\+ 1) (#\- 1) (#\* 2) (#\/ 2)))
>
> ;; converts infix to postfix using Dijkstra's Shunting Yard algorithm
> ;; the algorithm is from the Wikipedia article on the algorithm
> (define (infix->postfix infix)
> =A0 =A0 (let (
> =A0 =A0 =A0 =A0 (in (make-tokstream infix))
> =A0 =A0 =A0 =A0 (stack (make-stack))
> =A0 =A0 =A0 =A0 (output (make-q)))
>
> =A0 =A0 =A0 =A0 (define (operand? tok) (char-alphabetic? tok))
> =A0 =A0 =A0 =A0 (define (operator? tok) (assq tok operators))
> =A0 =A0 =A0 =A0 (define (open-brak? tok) (char=3D? tok #\()) =A0 =A0; bew=
are
> confuses syntax hiliter
> =A0 =A0 =A0 =A0 (define (close-brak? tok) (char=3D? tok #\))) =A0 ; bewar=
e
> confuses syntax hiliter
> =A0 =A0 =A0 =A0 (define (precedence op) (cadr (assq op operators)))
> =A0 =A0 =A0 =A0 (define (do-operand token) (q-add! output token))
> =A0 =A0 =A0 =A0 (define (do-open-brak tok) (stack-push! stack tok))
>
> =A0 =A0 =A0 =A0 (define (do-close-brak tok)
> =A0 =A0 =A0 =A0 =A0 =A0 (let until-open-brak ((x '()))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (if (stack-empty? stack) (error "missing =
closing
> bracket"))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (if (open-brak? (stack-top stack))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (stack-pop! stack) =A0 ; discard =
bracket
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (begin
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (q-add! output (stack-pop=
! stack))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (until-open-brak '())))))
>
> =A0 =A0 =A0 =A0 (define (do-operator token)
> =A0 =A0 =A0 =A0 =A0 =A0 (let while-operators ((x '()))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (if (and (not (stack-empty? stack)) (oper=
ator? (stack-
> top stack)))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (if (<=3D (precedence token) (pre=
cedence (stack-top
> stack)) )
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (begin
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (q-add! output (s=
tack-pop! stack))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (while-operators =
x)))))
> =A0 =A0 =A0 =A0 =A0 =A0 (stack-push! stack token))
>
> =A0 =A0 =A0 =A0 (define (flush-stack)
> =A0 =A0 =A0 =A0 =A0 =A0 (let loop ((x '())) =A0 ; x is a dummy argument
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (if (not (stack-empty? stack))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (if (or (open-brak? (stack-top st=
ack))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (close-brak? (sta=
ck-top stack)))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (error "infix->postfix: m=
ismatched bracket")
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (begin
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (q-add! output (s=
tack-pop! stack))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (loop '())
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0)))))
>
> =A0 =A0 =A0 =A0 ; turn the output queue into a string
> =A0 =A0 =A0 =A0 (define (create-output-string)
> =A0 =A0 =A0 =A0 =A0 =A0 (let loop ((s ""))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (if (not (q-empty? output))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (loop (string-append
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (if (zero? (string-length=
 s)) "" " ")
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (string (q-remove! output=
))))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 s)))
>
> =A0 =A0 =A0 =A0 (define (trace-me token)
> =A0 =A0 =A0 =A0 =A0 =A0 (display-line "infix-postfix: processing token" t=
oken
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "stream" (tokstream->list in)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 "output" (q->list output)))
>
> =A0 =A0 =A0 =A0 ; infix->postfix body
> =A0 =A0 =A0 =A0 (clear-q output) =A0 ; bug work-around
> =A0 =A0 =A0 =A0 (if (not (q-empty? output)) (error "output queue not empt=
y!"))
> =A0 =A0 =A0 =A0 (let while-tokens ((token (tokstream-get! in)))
> =A0 =A0 =A0 =A0 =A0 =A0 ;(trace-me token)
> =A0 =A0 =A0 =A0 =A0 =A0 (if (not (null? token))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (begin
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (cond
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ((operand? token) (do-ope=
rand token))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ((operator? token) (do-op=
erator token))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ((open-brak? token) (do-o=
pen-brak token))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 ((close-brak? token) (do-=
close-brak token))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (else (error "unrecognise=
d token")))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 (while-tokens (tokstream-get! in)=
))))
>
> =A0 =A0 =A0 =A0 ; no more tokens
> =A0 =A0 =A0 =A0 (flush-stack)
> =A0 =A0 =A0 =A0 (create-output-string)
> )) =A0 ; end infix->postfix
>
> ;;;
> ;;; test harness
>
> (define (test-infix->postfix)
> =A0 =A0 (unit-test infix->postfix string=3D? ("a + b * c") "a b c * +")
> =A0 =A0 (unit-test infix->postfix string=3D? ("a + b - c") "a b + c -")
> =A0 =A0 (unit-test infix->postfix string=3D? ("a * b - c") "a b * c -")
> =A0 =A0 (unit-test infix->postfix string=3D? ("(a + b) * c") "a b + c *")
> =A0 =A0 (unit-test infix->postfix string=3D? ("(a+b)+z-(c/d)") "a b + z +=
 c
> d / -")
> =A0 =A0 'all-tests-ok)
>
> *********************************************************************
>
> This version doesn't handle numbers, function calls or right-
> associative operators. The trace-me was used for debugging- Hide quoted t=
ext -
>
> - Show quoted text -

Sure, if you pay me or review my C infix2Polish conversion.
0
spinoza1111 (3246)
11/2/2009 1:39:25 PM
On Oct 25, 11:33=A0pm, Tameem <etam...@gmail.com> wrote:
> i have a string as (a+b)+8-(c/d) in Infix form.
>
> how can i convert it to postfix form using C language,,,????

I suppose that if this is homework, the due date has passed.

// Convert ;-separated infix expressions on stdin to postfix on
stdout.
#include <stdio.h>
#include <stdlib.h>
#include <string.h>
#include <stdarg.h>

// error handler

void die(char *msg)
{
  fprintf(stderr, "\ndie: %s\n", msg);
  exit(1);
}

// scanner

int lookahead;

int peek() { return lookahead; }

int peek_is(char *set)
{
  return strchr(set, peek()) !=3D NULL;
}

void advance(void)
{
  do lookahead =3D getchar(); while (isspace(lookahead));
}

// parser for gramar:
// expr -> term { [+-] term }
// term -> factor { [*/] factor }
// factor -> ALNUM | "(" expr ")"

void term(void);
void factor(void);

void expr(void)
{
  term();
  while (peek_is("+-")) {
    int op =3D peek();
    advance();
    term();
    printf("%c", op);
  }
}

void term(void)
{
  factor();
  while (peek_is("*/")) {
    int op =3D peek();
    advance();
    factor();
    printf("%c", op);
  }
}

void factor(void)
{
  if (isalnum(peek())) {
    int literal =3D peek();
    advance();
    printf("%c", literal);
  }
  else if (peek() =3D=3D '(') {
    advance();
    expr();
    if (!peek_is(")")) die("expected )");
    advance();
  }
  else
    die("expected factor");
}

// user interface

int main(void)
{
  advance();
  do {
    expr();
    if (!peek_is(";")) die("expected ;");
    printf("\n");
    advance();
  } while (peek() !=3D EOF);
  return 0;
}
0
gene.ressler (563)
11/2/2009 2:10:55 PM
On 2 Nov, 13:39, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Nov 2, 7:44=A0pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
> wrote:
> > On 1 Nov, 08:55,spinoza1111<spinoza1...@yahoo.com> wrote:
> > > On Nov 1, 4:34=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
> > > > On 2009-11-01,spinoza1111<spinoza1...@yahoo.com> wrote:


> > > > > I will take Peter's and Richard's silence on these posts to indic=
ate
> > > > > incompetence to study this code and find flaws.
>
> > > > I don't know the language you wrote it in, and also don't feel a lo=
t of
> > > > need to try to find flaws in your code.
>
> > > > Write something in a language I know and post it in an appropriate =
group
>
> > > Furthermore, the idea that computer languages are even distinct is
> > > absurd. That they are is a historical accident, caused by the large
> > > number of errors made in language design in the early days.
>
> > > Insofar as "knowledge" of C is knowledge of mistakes, C has no
> > > standing as an academic subject and should not be spoken of as a
> > > computer language. Instead, it should be considered a pathology which
> > > computer scientists must learn for the same reason doctors must learn
> > > cancer.
>
> > > People whose main claim to expertise in C should be sent to re-
> > > education camps on the model of UN centres in Africa which train
> > > former guerrillas in useful trades.
>
> > > And the world still needs one programming language that can be used b=
y
> > > everyone. The guy on the screen in the 1984 Apple commercial was
> > > right.
>
> > Could you review this? (the utility library only provides the unit-
> > test and display-line functions)

<snip lump of code>

> > This version doesn't handle numbers, function calls or right-
> > associative operators. The trace-me was used for debugging
>
> Sure, if you pay me or review my C infix2Polish conversion

but, I wasn't claiming that knowledge of one language automatically
implied knowledge of another. Or that all languages were "essentially
the same"

0
11/2/2009 2:24:52 PM
In article 
<fe798d09-500d-4fc1-ba97-b4d827b92357@k13g2000prh.googlegroups.com>,
 spinoza1111 <spinoza1111@yahoo.com> wrote:

> This post contains the promised C code version of the infix to Polish
> notation convertor.

Promised to whom? I didn't ask for it.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689
0
timstreater (945)
11/2/2009 2:34:41 PM
In article <hcma6f$j3f$1@news.eternal-september.org>,
 Curtis Dyer <dyer85@gmail.com> wrote:

> On 31 Oct 2009, Seebs <usenet-nospam@seebs.net> wrote:
> 
> > On 2009-11-01, spinoza1111 <spinoza1111@yahoo.com> wrote:
> >> On Nov 1, 2:11�pm, Seebs <usenet-nos...@seebs.net> wrote:
> 
> <snip>
> 
> >> Arguably less than smart people because stupid people have to
> >> work at 7-11 where their actions are monitored, or on funny
> >> little embedded systems as opposed to actually important
> >> systems such as Microsoft boxes, and their work is constantly
> >> checked. 
> 
> Wow.
> 
> > Oh, I see.  You're trying to sneakily imply that I'm stupid. 
> > No, not buying it.  I certainly have my cognitive flaws, but
> > "stupidity" is not one of them.
> 
> Am I interpreting spinoza1111's remark here correctly?  It also 
> seems he is slighting programmers who work on embedded systems.  I 
> suppose this shouldn't be surprising, but it's just so painfully 
> absurd.  The many contributions of embedded systems programmers (I'm 
> not one, but do admire them) are demonstrably undeniable.

He sneers constantly at non-academic programmers, near as I can tell. 
That seems to be anyone who cannot do the Computer Science equivalent of 
deducing the properties of the universe from the definition of a point. 
Then he wonders why we sneer at him.

In the 18th century, people used to visit Bedlam with pointed sticks, 
poking the lunatics inside to make them gibber. With Spinny, even that 
is unnecessary. Any rational response causes him to gibber 
uncontrollably.

Watching Spinny's train of "logic", I'm reminded of the Soviets' 
constant denigration of the West as "warmongers", the rationale for 
which which went something like as follows:

1) We are in conflict with you
2) If you were to agree with our point of view, the conflict would cease
3) Since you choose not to take an action which would remove the 
conflict, you are actively seeking to prolong the conflict
4) In actively seeking to prolong the conflict, you are therefore a 
warmonger

There must be a word which describes this sort of thought process.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689
0
timstreater (945)
11/2/2009 2:54:33 PM
In article <hcmu8n$c0c$1@news.eternal-september.org>,
 Richard <rgrdev_@gmail.com> wrote:

> Tim Streater <timstreater@waitrose.com> writes:
> 
> > In article 
> > <fe798d09-500d-4fc1-ba97-b4d827b92357@k13g2000prh.googlegroups.com>,
> >  spinoza1111 <spinoza1111@yahoo.com> wrote:
> >
> >> This post contains the promised C code version of the infix to Polish
> >> notation convertor.
> >
> > Promised to whom? I didn't ask for it.
> 
> And you are who exactly?
> 
> And why would you be so concerned as to who it was promised for? Or do
> all posts needs to be cleared by your good self first?

:-)

Nice one.

I'm just here for the show.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689
0
timstreater (945)
11/2/2009 3:24:14 PM
Tim Streater <timstreater@waitrose.com> writes:

> In article 
> <fe798d09-500d-4fc1-ba97-b4d827b92357@k13g2000prh.googlegroups.com>,
>  spinoza1111 <spinoza1111@yahoo.com> wrote:
>
>> This post contains the promised C code version of the infix to Polish
>> notation convertor.
>
> Promised to whom? I didn't ask for it.

And you are who exactly?

And why would you be so concerned as to who it was promised for? Or do
all posts needs to be cleared by your good self first?

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
rgrdev_ (1097)
11/2/2009 3:35:49 PM
In 
<fe798d09-500d-4fc1-ba97-b4d827b92357@k13g2000prh.googlegroups.com>, 
spinoza1111 wrote:

> This post contains the promised C code version of the infix to
> Polish notation convertor. When run from the command line it should
> execute all cases used to test the C Sharp version correctly. Its
> string handling is simpler owing to the limitations of C.
> 
> This code unless it is seriously fucked up demonstrates the
> practicality of using a formal language based approach to infix to
> Polish notation. It's also part of my project of relearning C.
> 
> Comments as opposed to BS welcome.
> 
> 
> #include <stdio.H>

foo.c:1: stdio.H: No such file or directory

> #include <stdlib.H>

foo.c:3: stdlib.H: No such file or directory

Fixing those and moving on...

foo.c: In function `stringAppendChar':
foo.c:37: warning: passing arg 1 of `errorHandler' discards qualifiers 
from pointer target type
foo.c: At top level:
foo.c: In function `appendPolish':
foo.c:54: warning: passing arg 2 of `stringAppendChar' with different 
width due to prototype
foo.c:58: warning: passing arg 2 of `stringAppendChar' with different 
width due to prototype
foo.c:60: warning: passing arg 2 of `stringAppendChar' with different 
width due to prototype
foo.c: At top level:
foo.c: In function `mulFactor':
foo.c:79: warning: passing arg 2 of `errorHandlerSyntax' discards 
qualifiers from pointer target type
foo.c:84: warning: passing arg 2 of `appendPolish' with different 
width due to prototype
foo.c:95: warning: passing arg 2 of `stringAppendChar' with different 
width due to prototype
foo.c:102: warning: passing arg 2 of `stringAppendChar' with different 
width due to prototype
foo.c:125: warning: passing arg 2 of `errorHandlerSyntax' discards 
qualifiers from pointer target type
foo.c:132: warning: passing arg 2 of `errorHandlerSyntax' discards 
qualifiers from pointer target type

[Diagnostic message for // removed - code adjusted and recompiled]

foo.c: At top level:
foo.c:143: warning: no previous prototype for `addFactor'
foo.c: In function `addFactor':
foo.c:148: warning: passing arg 2 of `errorHandlerSyntax' discards 
qualifiers from pointer target type
foo.c:168: warning: passing arg 2 of `errorHandlerSyntax' discards 
qualifiers from pointer target type
foo.c:169: warning: passing arg 2 of `appendPolish' with different 
width due to prototype
foo.c: In function `expression':
foo.c:183: warning: passing arg 2 of `errorHandlerSyntax' discards 
qualifiers from pointer target type
foo.c:202: warning: passing arg 2 of `errorHandlerSyntax' discards 
qualifiers from pointer target type
foo.c:203: warning: passing arg 2 of `appendPolish' with different 
width due to prototype
foo.c: At top level:
foo.c:209: warning: no previous prototype for `infix2Polish'
foo.c: In function `infix2Polish':
foo.c:213: warning: passing arg 1 of `errorHandler' discards 
qualifiers from pointer target type
foo.c:220: warning: passing arg 1 of `errorHandler' discards 
qualifiers from pointer target type
foo.c:221: warning: return discards qualifiers from pointer target 
type
foo.c: At top level:
foo.c:227: warning: function declaration isn't a prototype
foo.c: In function `tester':
foo.c:229: warning: passing arg 1 of `infix2Polish' discards 
qualifiers from pointer target type
foo.c:231: warning: passing arg 1 of `infix2Polish' discards 
qualifiers from pointer target type
foo.c:233: warning: passing arg 1 of `infix2Polish' discards 
qualifiers from pointer target type
foo.c:235: warning: passing arg 1 of `infix2Polish' discards 
qualifiers from pointer target type
foo.c:237: warning: passing arg 1 of `infix2Polish' discards 
qualifiers from pointer target type
foo.c:239: warning: passing arg 1 of `infix2Polish' discards 
qualifiers from pointer target type
foo.c:241: warning: passing arg 1 of `infix2Polish' discards 
qualifiers from pointer target type
foo.c:243: warning: passing arg 1 of `infix2Polish' discards 
qualifiers from pointer target type
foo.c:245: warning: passing arg 1 of `infix2Polish' discards 
qualifiers from pointer target type
foo.c:247: warning: passing arg 1 of `infix2Polish' discards 
qualifiers from pointer target type
foo.c:249: warning: passing arg 1 of `infix2Polish' discards 
qualifiers from pointer target type
foo.c:251: warning: passing arg 1 of `infix2Polish' discards 
qualifiers from pointer target type
foo.c:253: warning: passing arg 1 of `infix2Polish' discards 
qualifiers from pointer target type
foo.c:255: warning: passing arg 1 of `infix2Polish' discards 
qualifiers from pointer target type
foo.c:257: warning: passing arg 1 of `infix2Polish' discards 
qualifiers from pointer target type
foo.c: In function `main':
foo.c:263: warning: `return' with no value, in function returning 
non-void
foo.c:260: warning: unused parameter `intArgCount'
foo.c:260: warning: unused parameter `strArgs'

<snip>

-- 
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
0
rjh (10791)
11/2/2009 3:45:58 PM
On Nov 2, 10:10=A0pm, Gene <gene.ress...@gmail.com> wrote:
> On Oct 25, 11:33=A0pm, Tameem <etam...@gmail.com> wrote:
>
> > i have a string as (a+b)+8-(c/d) in Infix form.
>
> > how can i convert it to postfix form using C language,,,????
>
> I suppose that if this is homework, the due date has passed.
>
> // Convert ;-separated infix expressions on stdin to postfix on
> stdout.
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <stdarg.h>
>
> // error handler
>
> void die(char *msg)
> {
> =A0 fprintf(stderr, "\ndie: %s\n", msg);
> =A0 exit(1);
>
> }
>
> // scanner
>
> int lookahead;
>
> int peek() { return lookahead; }
>
> int peek_is(char *set)
> {
> =A0 return strchr(set, peek()) !=3D NULL;
>
> }
>
> void advance(void)
> {
> =A0 do lookahead =3D getchar(); while (isspace(lookahead));
>
> }
>
> // parser for gramar:
> // expr -> term { [+-] term }
> // term -> factor { [*/] factor }
> // factor -> ALNUM | "(" expr ")"
>
> void term(void);
> void factor(void);
>
> void expr(void)
> {
> =A0 term();
> =A0 while (peek_is("+-")) {
> =A0 =A0 int op =3D peek();
> =A0 =A0 advance();
> =A0 =A0 term();
> =A0 =A0 printf("%c", op);
> =A0 }
>
> }
>
> void term(void)
> {
> =A0 factor();
> =A0 while (peek_is("*/")) {
> =A0 =A0 int op =3D peek();
> =A0 =A0 advance();
> =A0 =A0 factor();
> =A0 =A0 printf("%c", op);
> =A0 }
>
> }
>
> void factor(void)
> {
> =A0 if (isalnum(peek())) {
> =A0 =A0 int literal =3D peek();
> =A0 =A0 advance();
> =A0 =A0 printf("%c", literal);
> =A0 }
> =A0 else if (peek() =3D=3D '(') {
> =A0 =A0 advance();
> =A0 =A0 expr();
> =A0 =A0 if (!peek_is(")")) die("expected )");
> =A0 =A0 advance();
> =A0 }
> =A0 else
> =A0 =A0 die("expected factor");
>
> }
>
> // user interface
>
> int main(void)
> {
> =A0 advance();
> =A0 do {
> =A0 =A0 expr();
> =A0 =A0 if (!peek_is(";")) die("expected ;");
> =A0 =A0 printf("\n");
> =A0 =A0 advance();
> =A0 } while (peek() !=3D EOF);
> =A0 return 0;
>
>
>
> }- Hide quoted text -
>
> - Show quoted text -

Thanks for this. Looks like you stole my approach, but I find that
most gratifying if true, and an indication that "great minds think
alike" if not. Your contribution at a minimum is to show just how
gnomic and terse one can be in C. It would not be appropriate to
credit me since it is a common and solid algorithm that has been
around for years.

Hope you don't mind, but I'm going to copy this code and incorporate
it in what will not be a three way test: of my C Sharp version, my C
version and your gnomic C. I want to add more testing (using a random
generator in C Sharp), a GUI and timing comparisions and shall report
back.
0
spinoza1111 (3246)
11/2/2009 3:48:24 PM
On Nov 2, 10:10=A0pm, Gene <gene.ress...@gmail.com> wrote:
> On Oct 25, 11:33=A0pm, Tameem <etam...@gmail.com> wrote:
>
> > i have a string as (a+b)+8-(c/d) in Infix form.
>
> > how can i convert it to postfix form using C language,,,????
>
> I suppose that if this is homework, the due date has passed.
>
> // Convert ;-separated infix expressions on stdin to postfix on
> stdout.
> #include <stdio.h>
> #include <stdlib.h>
> #include <string.h>
> #include <stdarg.h>
>
> // error handler
>
> void die(char *msg)
> {
> =A0 fprintf(stderr, "\ndie: %s\n", msg);
> =A0 exit(1);
>
> }
>
> // scanner
>
> int lookahead;
>
> int peek() { return lookahead; }
>
> int peek_is(char *set)
> {
> =A0 return strchr(set, peek()) !=3D NULL;
>
> }
>
> void advance(void)
> {
> =A0 do lookahead =3D getchar(); while (isspace(lookahead));
>
> }
>
> // parser for gramar:
> // expr -> term { [+-] term }
> // term -> factor { [*/] factor }

Again it looks like you stole this, and again I forgive you, or ask
your forgiveness if I have accused you falsely. If you swiped it from
my grammar, you forgot to put an asterisk after the right curley
braces to indicate that there can be zero, one or more occurences of
the term or factor, preceded by its binary operator.

If you did not swipe it, then you may be using curley braces to
indicate zero one or more repetitions of the braced content; but this
would be your unique idiom, I've never seen it.

Your code supports zero one or more and this looks correct.

Also, the standard meaning of square brackets is that the bracketed
material is optional: but the binary operators you have bracketed are
most assuredly not optional as I think you know.


> // factor -> ALNUM | "(" expr ")"
>
> void term(void);
> void factor(void);
>
> void expr(void)
> {
> =A0 term();
> =A0 while (peek_is("+-")) {
> =A0 =A0 int op =3D peek();
> =A0 =A0 advance();
> =A0 =A0 term();
> =A0 =A0 printf("%c", op);
> =A0 }
>
> }
>
> void term(void)
> {
> =A0 factor();
> =A0 while (peek_is("*/")) {
> =A0 =A0 int op =3D peek();
> =A0 =A0 advance();
> =A0 =A0 factor();
> =A0 =A0 printf("%c", op);
> =A0 }
>
> }
>
> void factor(void)
> {
> =A0 if (isalnum(peek())) {
> =A0 =A0 int literal =3D peek();
> =A0 =A0 advance();
> =A0 =A0 printf("%c", literal);
> =A0 }
> =A0 else if (peek() =3D=3D '(') {
> =A0 =A0 advance();
> =A0 =A0 expr();
> =A0 =A0 if (!peek_is(")")) die("expected )");
> =A0 =A0 advance();
> =A0 }
> =A0 else
> =A0 =A0 die("expected factor");
>
> }
>
> // user interface
>
> int main(void)
> {
> =A0 advance();
> =A0 do {
> =A0 =A0 expr();
> =A0 =A0 if (!peek_is(";")) die("expected ;");
> =A0 =A0 printf("\n");
> =A0 =A0 advance();
> =A0 } while (peek() !=3D EOF);
> =A0 return 0;
>
>
>
> }- Hide quoted text -
>
> - Show quoted text -

0
spinoza1111 (3246)
11/2/2009 3:56:27 PM
In article 
<1deddbcd-ed66-4172-a3c9-5afc76fc462b@12g2000pri.googlegroups.com>,
 spinoza1111 <spinoza1111@yahoo.com> wrote:

> On Nov 2, 10:54�pm, Tim Streater <timstrea...@waitrose.com> wrote:
> > In article <hcma6f$j3...@news.eternal-september.org>,
> > �Curtis Dyer <dye...@gmail.com> wrote:
> >
> > > On 31 Oct 2009, Seebs <usenet-nos...@seebs.net> wrote:
> >
> > > > On 2009-11-01,spinoza1111<spinoza1...@yahoo.com> wrote:
> > > >> On Nov 1, 2:11�pm, Seebs <usenet-nos...@seebs.net> wrote:
> >
> > > <snip>
> >
> > > >> Arguably less than smart people because stupid people have to
> > > >> work at 7-11 where their actions are monitored, or on funny
> > > >> little embedded systems as opposed to actually important
> > > >> systems such as Microsoft boxes, and their work is constantly
> > > >> checked.
> >
> > > Wow.
> >
> > > > Oh, I see. �You're trying to sneakily imply that I'm stupid.
> > > > No, not buying it. �I certainly have my cognitive flaws, but
> > > > "stupidity" is not one of them.
> >
> > > Am I interpretingspinoza1111'sremark here correctly? �It also
> > > seems he is slighting programmers who work on embedded systems. �I
> > > suppose this shouldn't be surprising, but it's just so painfully
> > > absurd. �The many contributions of embedded systems programmers (I'm
> > > not one, but do admire them) are demonstrably undeniable.
> >
> > He sneers constantly at non-academic programmers, near as I can tell.
> > That seems to be anyone who cannot do the Computer Science equivalent of
> > deducing the properties of the universe from the definition of a point.
> > Then he wonders why we sneer at him.
> >
> > In the 18th century, people used to visit Bedlam with pointed sticks,
> > poking the lunatics inside to make them gibber. With Spinny, even that
> > is unnecessary. Any rational response causes him to gibber
> > uncontrollably.
> 
> So you're nothing more than a Regency lout?

Doesn't matter what I am, you gibber all the same.

> > Watching Spinny's train of "logic", I'm reminded of the Soviets'
> > constant denigration of the West as "warmongers", the rationale for
> > which which went something like as follows:
> >
> > 1) We are in conflict with you
> > 2) If you were to agree with our point of view, the conflict would cease
> > 3) Since you choose not to take an action which would remove the
> > conflict, you are actively seeking to prolong the conflict
> > 4) In actively seeking to prolong the conflict, you are therefore a
> > warmonger
> >
> This logic merely mirrored that of the West. The question is "who
> started it". As it happened, the West started the Cold War in 1950 by
> arming the Greek right wing, resulting in the murder of a Western
> journalist, several years of slaughter in Greece, and military
> dictatorship in that country.

The question of "who started it" is not in any way relevant to their 
subsequent thought process.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689
0
timstreater (945)
11/2/2009 3:58:43 PM
On Nov 2, 10:54=A0pm, Tim Streater <timstrea...@waitrose.com> wrote:
> In article <hcma6f$j3...@news.eternal-september.org>,
> =A0Curtis Dyer <dye...@gmail.com> wrote:
>
>
>
>
>
> > On 31 Oct 2009, Seebs <usenet-nos...@seebs.net> wrote:
>
> > > On 2009-11-01,spinoza1111<spinoza1...@yahoo.com> wrote:
> > >> On Nov 1, 2:11=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
>
> > <snip>
>
> > >> Arguably less than smart people because stupid people have to
> > >> work at 7-11 where their actions are monitored, or on funny
> > >> little embedded systems as opposed to actually important
> > >> systems such as Microsoft boxes, and their work is constantly
> > >> checked.
>
> > Wow.
>
> > > Oh, I see. =A0You're trying to sneakily imply that I'm stupid.
> > > No, not buying it. =A0I certainly have my cognitive flaws, but
> > > "stupidity" is not one of them.
>
> > Am I interpretingspinoza1111'sremark here correctly? =A0It also
> > seems he is slighting programmers who work on embedded systems. =A0I
> > suppose this shouldn't be surprising, but it's just so painfully
> > absurd. =A0The many contributions of embedded systems programmers (I'm
> > not one, but do admire them) are demonstrably undeniable.
>
> He sneers constantly at non-academic programmers, near as I can tell.
> That seems to be anyone who cannot do the Computer Science equivalent of
> deducing the properties of the universe from the definition of a point.
> Then he wonders why we sneer at him.
>
> In the 18th century, people used to visit Bedlam with pointed sticks,
> poking the lunatics inside to make them gibber. With Spinny, even that
> is unnecessary. Any rational response causes him to gibber
> uncontrollably.

So you're nothing more than a Regency lout?
>
> Watching Spinny's train of "logic", I'm reminded of the Soviets'
> constant denigration of the West as "warmongers", the rationale for
> which which went something like as follows:
>
> 1) We are in conflict with you
> 2) If you were to agree with our point of view, the conflict would cease
> 3) Since you choose not to take an action which would remove the
> conflict, you are actively seeking to prolong the conflict
> 4) In actively seeking to prolong the conflict, you are therefore a
> warmonger
>
This logic merely mirrored that of the West. The question is "who
started it". As it happened, the West started the Cold War in 1950 by
arming the Greek right wing, resulting in the murder of a Western
journalist, several years of slaughter in Greece, and military
dictatorship in that country.

I find here that friendly attempts to discuss code are met by the
creation of a permanent record which could threaten my employment. As
it happens, I am good at what I do, and this includes more than being
a code monkey, so in fact my Internet record has never harmed my
employment and has gotten my hired at at least one job

But I find other people including real contributors like Navia being
treated in like fashion. I also have "inside" information on the
effect of the anti-Schildt campaign, long a staple of clc, the sources
of which I am not at liberty to disclose, and this effect amounts to
that of civil and criminal libel under UK and American law.

Next time do your homework.

> There must be a word which describes this sort of thought process.
>
> --
> Tim
>
> "That excessive bail ought not to be required, nor excessive fines impose=
d,
> nor cruel and unusual punishments inflicted" =A0-- =A0Bill of Rights 1689=
- Hide quoted text -
>
> - Show quoted text -

0
spinoza1111 (3246)
11/2/2009 4:04:18 PM
In 
<75284980-34e3-44bc-8f74-b9b2940b4f9f@u36g2000prn.googlegroups.com>, 
spinoza1111 wrote:

> On Nov 2, 10:10 pm, Gene <gene.ress...@gmail.com> wrote:

<snip>

>> // parser for gramar:
>> // expr -> term { [+-] term }
>> // term -> factor { [*/] factor }
> 
> Again it looks like you stole this,

It's a minor re"word"ing of p72 of the Dragon Book [Aho, Sethi, Ullman 
1986].

-- 
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
0
rjh (10791)
11/2/2009 4:14:50 PM
In article <hcmu8n$c0c$1@news.eternal-september.org>,
Richard  <rgrdev_@gmail.com> wrote:
>Tim Streater <timstreater@waitrose.com> writes:
>
>> In article 
>> <fe798d09-500d-4fc1-ba97-b4d827b92357@k13g2000prh.googlegroups.com>,
>>  spinoza1111 <spinoza1111@yahoo.com> wrote:
>>
>>> This post contains the promised C code version of the infix to Polish
>>> notation convertor.
>>
>> Promised to whom? I didn't ask for it.
>
>And you are who exactly?
>
>And why would you be so concerned as to who it was promised for? Or do
>all posts needs to be cleared by your good self first?

It really makes the regs (and, most especially, the reg-wannabees like
Mr. Streater here) nervous to be seen as in any way requesting anything
(other than order-in-the-court, of course).  That is, it destroys their
game to be seen as being in the position of asking for something as
opposed to always being the givers of knowledge.

Notice the recent hoo-hah about whether or not Kiki/RH had requested
anything from Jacob.  Notice how much virtual ink was expended
discussing what was, in fact, just a small, jocular, off-the-cuff remark
from Jacob.

Kiki was obviously much distressed by both of the following
implications, and spared no effort to try to dispel both:

    1) That they (Kiki and/or RH) had requested something from lowly Jacob.
    2) That, in response to and in fulfillment of said request, Jacob
	had actually, out of the goodness of his heart, produced something
	of value.

0
gazelle3 (1726)
11/2/2009 5:07:14 PM
gazelle@shell.xmission.com (Kenny McCormack) writes:

> In article <hcmu8n$c0c$1@news.eternal-september.org>,
> Richard  <rgrdev_@gmail.com> wrote:
>>Tim Streater <timstreater@waitrose.com> writes:
>>
>>> In article 
>>> <fe798d09-500d-4fc1-ba97-b4d827b92357@k13g2000prh.googlegroups.com>,
>>>  spinoza1111 <spinoza1111@yahoo.com> wrote:
>>>
>>>> This post contains the promised C code version of the infix to Polish
>>>> notation convertor.
>>>
>>> Promised to whom? I didn't ask for it.
>>
>>And you are who exactly?
>>
>>And why would you be so concerned as to who it was promised for? Or do
>>all posts needs to be cleared by your good self first?
>
> It really makes the regs (and, most especially, the reg-wannabees like
> Mr. Streater here) nervous to be seen as in any way requesting anything
> (other than order-in-the-court, of course).  That is, it destroys their
> game to be seen as being in the position of asking for something as
> opposed to always being the givers of knowledge.
>
> Notice the recent hoo-hah about whether or not Kiki/RH had requested
> anything from Jacob.  Notice how much virtual ink was expended
> discussing what was, in fact, just a small, jocular, off-the-cuff remark
> from Jacob.
>
> Kiki was obviously much distressed by both of the following
> implications, and spared no effort to try to dispel both:
>
>     1) That they (Kiki and/or RH) had requested something from lowly Jacob.
>     2) That, in response to and in fulfillment of said request, Jacob
> 	had actually, out of the goodness of his heart, produced something
> 	of value.
>

Yowza. I can see that would have created a stir. Along that vein of
thought, I'm  amazed that they tolerate Keighley aiding and abetting
them recently - almost as if he had his own seat at the high table.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
rgrdev_ (1097)
11/2/2009 5:22:57 PM
On Nov 2, 10:48=A0am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Nov 2, 10:10=A0pm, Gene <gene.ress...@gmail.com> wrote:
>
>
>
>
>
> > On Oct 25, 11:33=A0pm, Tameem <etam...@gmail.com> wrote:
>
> > > i have a string as (a+b)+8-(c/d) in Infix form.
>
> > > how can i convert it to postfix form using C language,,,????
>
> > I suppose that if this is homework, the due date has passed.
>
> > // Convert ;-separated infix expressions on stdin to postfix on
> > stdout.
> > #include <stdio.h>
> > #include <stdlib.h>
> > #include <string.h>
> > #include <stdarg.h>
>
> > // error handler
>
> > void die(char *msg)
> > {
> > =A0 fprintf(stderr, "\ndie: %s\n", msg);
> > =A0 exit(1);
>
> > }
>
> > // scanner
>
> > int lookahead;
>
> > int peek() { return lookahead; }
>
> > int peek_is(char *set)
> > {
> > =A0 return strchr(set, peek()) !=3D NULL;
>
> > }
>
> > void advance(void)
> > {
> > =A0 do lookahead =3D getchar(); while (isspace(lookahead));
>
> > }
>
> > // parser for gramar:
> > // expr -> term { [+-] term }
> > // term -> factor { [*/] factor }
> > // factor -> ALNUM | "(" expr ")"
>
> > void term(void);
> > void factor(void);
>
> > void expr(void)
> > {
> > =A0 term();
> > =A0 while (peek_is("+-")) {
> > =A0 =A0 int op =3D peek();
> > =A0 =A0 advance();
> > =A0 =A0 term();
> > =A0 =A0 printf("%c", op);
> > =A0 }
>
> > }
>
> > void term(void)
> > {
> > =A0 factor();
> > =A0 while (peek_is("*/")) {
> > =A0 =A0 int op =3D peek();
> > =A0 =A0 advance();
> > =A0 =A0 factor();
> > =A0 =A0 printf("%c", op);
> > =A0 }
>
> > }
>
> > void factor(void)
> > {
> > =A0 if (isalnum(peek())) {
> > =A0 =A0 int literal =3D peek();
> > =A0 =A0 advance();
> > =A0 =A0 printf("%c", literal);
> > =A0 }
> > =A0 else if (peek() =3D=3D '(') {
> > =A0 =A0 advance();
> > =A0 =A0 expr();
> > =A0 =A0 if (!peek_is(")")) die("expected )");
> > =A0 =A0 advance();
> > =A0 }
> > =A0 else
> > =A0 =A0 die("expected factor");
>
> > }
>
> > // user interface
>
> > int main(void)
> > {
> > =A0 advance();
> > =A0 do {
> > =A0 =A0 expr();
> > =A0 =A0 if (!peek_is(";")) die("expected ;");
> > =A0 =A0 printf("\n");
> > =A0 =A0 advance();
> > =A0 } while (peek() !=3D EOF);
> > =A0 return 0;
>
> > }- Hide quoted text -
>
> > - Show quoted text -
>
> Thanks for this. Looks like you stole my approach, but I find that
> most gratifying if true, and an indication that "great minds think
> alike" if not. Your contribution at a minimum is to show just how
> gnomic and terse one can be in C. It would not be appropriate to
> credit me since it is a common and solid algorithm that has been
> around for years.
>
> Hope you don't mind, but I'm going to copy this code and incorporate
> it in what will not be a three way test: of my C Sharp version, my C
> version and your gnomic C. I want to add more testing (using a random
> generator in C Sharp), a GUI and timing comparisions and shall report
> back.- Hide quoted text -
>

This doesn't qualify as anything like theft or great thinking. For
fun, I wrote the code in about 5 minutes after the OP posted (based on
http://groups.google.com/group/comp.lang.c/msg/fe772c9d6a28fdc4), but
refrained from posting it because it was probably homework for the
OP.  This is a standard example or homework assignment for just about
any undergrad course that covers recursive descent parsing.  The
gramamr with minor variations is in at least a dozen complier design
textbooks including ASU. Usually it's given in left-recursive form,
and then the author or student go through the L-rec removal, left-
factoring, and BNF conversion.  RPN generation is a trivial example of
attribute evaluation.

0
gene.ressler (563)
11/2/2009 5:36:13 PM
On 2009-11-02, Curtis Dyer <dyer85@gmail.com> wrote:
> Am I interpreting spinoza1111's remark here correctly?  It also 
> seems he is slighting programmers who work on embedded systems.  I 
> suppose this shouldn't be surprising, but it's just so painfully 
> absurd.  The many contributions of embedded systems programmers (I'm 
> not one, but do admire them) are demonstrably undeniable.

You forgot!  I mentioned at one point that my dayjob involves embedded
software.  I do it, therefore it's horrible in his world.

Like the way that, the moment he found out I hadn't done any CS classes,
the people attacking Schildt went from being over-educated fools without
real-world experience to uneducated and therefore unqualified.  I'm half
tempted to go take a CS class just to make him flip-flop again.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/2/2009 6:04:32 PM
On 2009-11-02, spinoza1111 <spinoza1111@yahoo.com> wrote:
> This post contains the promised C code version of the infix to Polish
> notation convertor. When run from the command line it should execute
> all cases used to test the C Sharp version correctly. Its string
> handling is simpler owing to the limitations of C.

Okay.

> #include <stdio.H>
> #include <stdlib.H>

Don't capitalize the "H" -- while it may happen to work on your system,
it means the code won't compile on others.  Even an easily-fixed compile
error makes people likely to discount your code.

> #define MAX_POLISH_LENGTH 100

> int errorHandler(char *strMessage)
> {
> 	printf("\n%s\n", strMessage); return 0;
> }

This always returns the same value, why does it have a return value at
all?

If this is for an error message, why isn't it using stderr for its output?

The double-\n thing is a bit unusual; normally a convention is adopted
where messages should either end with (normally) or start with (less
often) a newline, rather than providing two.  In particular, if there are
two consecutive error messages for some reason, this would produce a blank
line between them.

It would seem much more useful to implement this function using ... arguments
and the underlying vfprintf() to allow formatted messages to be displayed.
If I were writing a function to this effect, I'd probably do:

	void
	errorHandler(char *msg, ...) {
		va_list ap;
		va_start(ap, fmt);
		vfprintf(stderr, fmt, ap);
		va_end(ap);
	}

You prefix the variable's name with a type.  While that certainly CAN be
a reasonable thing, it's important to ensure that the type used is a real
abstract type, not merely a language type -- language types are already
type checked.

> int errorHandlerSyntax(int intIndex, char *strMessage)

You're using Systems Hungarian here, which is crap.  Don't.  Apps Hungarian
is what Simonyi proposed and demonstrated to be useful.  Systems Hungarian
isn't useful, and leads to bugs later.

> {
> 	printf("\nError at character %d: %s\n",
> 		   intIndex,
> 		   strMessage);
> 	return 0;
> }

This is a useless message.  It doesn't tell the user what the character
IS, nor does it give the user any feedback as to the nature of the message.
And, again, suggest that you implement format arguments.

> int stringLength(char *strInstring)
> {
> 	int intIndex1;
> 	for (intIndex1 = 0;
> 		 strInstring[intIndex1] != '\0';
> 		 intIndex1++) { }
> 	return intIndex1;
> }

Why the fuck did you even write this?  strlen() exists for a reason.
And just for extra credit:  This name is reserved for use exclusively
by the implementation, since it starts with "str" followed by a lowercase
letter.  In practice it's likely harmless in modern systems because
names are usually case-sensitive, and the standard doesn't define library
functions with camelCase.

But it's still stupid.

> int stringAppendChar(char *strInstring,
>      				 char chrNew,
> 					 int intMaxLength)
> {
> 	int intLength = stringLength(strInstring);
> 	if (intLength >= intMaxLength - 1)
> 	{
> 		errorHandler
> 			("Cannot append character: string too long");
> 		return 0;
> 	}
> 	strInstring[intLength] = chrNew;
> 	strInstring[intLength + 1] = '\0';
> 	return -1;
> }

int
stringAppendChar(char *s, char c, size_t max) {
	char *end = strchr(s, '\0');
	if (end - s < max) {
		*end++ = c;
		*end = '\0';
		return end - s;
	} else {
		return -1;
	}
}

Note that I've changed the sense of the return value.  This is because
by convention -1 indicates a failure.  Returning the actual length,
rather than a meaningless value, gives the caller some additional
information.

Note that I've preserved the probable-bug, which is that if you have an
array of 15 characters, and you call this function with the limit 15 on
an array containing 14 non-zero characters and a null byte,
it'll write the 16th character of the 15-character array.  That's almost
always a bad choice.

I've omitted the ridiculous error message call, for reasons which shall
become apparent.

> int appendPolish(char *strPolish, char chrNext)
> {
> 	return
> 		((*strPolish == '\0' || *strPolish == ' ')
> 		 ?
> 		 -1
> 		 :
> 		 stringAppendChar(strPolish,
> 		                  ' ',
> 						  MAX_POLISH_LENGTH))
>         &&
> 		stringAppendChar(strPolish,
> 		                 chrNext,
> 						 MAX_POLISH_LENGTH)
>         &&
> 		stringAppendChar(strPolish, ' ', MAX_POLISH_LENGTH);
> }

This is just plain horrid.  The layout is surreal, and the logic
opaque.

I think you mean:

int appendPolish(char *strPolish, char chrNext)
{
  if (*strPolish == ' ' || *strPolish == '\0')
    return -1;
  ... wait, this doesn't even make sense.
}

This function aborts if the FIRST character of strPolish is a space or
a null, but then appends characters off at the end of strPolish.  This
makes no sense.  You'll have to put in some kind of explanatory comment
to justify that.

There's also the fact that calling stringAppendChar three times in a row
is stupid.  Figure out how many characters are left, and if there's enough
room for three, append all three at once.  Appending one or two of them
is not useful.

> int mulFactor(char *strInfix,
> 			  char *strPolish,
> 			  int *intPtrIndex,
> 			  int intEnd)
> { /* mulFactor = LETTER | NUMBER | '(' expression ')' */
> 	int intIndexStart = 0;
> 	int intLevel = 0;
> 	char chrNext = ' ';
> 	int intInner;
> 	if (*intPtrIndex > intEnd)
> 		return errorHandlerSyntax(*intPtrIndex,
> 		                          "mulFactor unavailable");

This is a crappy error message.  The problem has nothing at all to do with
mulFactor.  It has to do with you having, apparently, run out of room
or something.  So say so; give a message like "string too long".

> 	if (chrNext == '(')

This is the point where you should be calling a different function that
handles parenthesized expressions, IMHO.

> 		if (!expression(strInfix,
> 			            strPolish,
> 						&intInner,
> 						*intPtrIndex - 2))

Ugh.

Seems like this would be a great time to refactor this more sanely.  In
particular, you're having the higher-level code (mulfactor) try to guess
the range of the substring.

What happens when someone asks you to support strings?  Then suddenly
mulfactor() has to be smart enough to find the end of:
	(a + ")")

and you're making a ton of work.  Wrong.  When you see the (, pass it off
to the function which tries to find an expression followed by a trailing ),
and have the expression parser hand what it found so far back up when it
sees the ) -- at which point the parens function finds its trailing ) and is
happy.

> char *infix2Polish(char *strInfix)
> {
> 	int intIndex = 0;
> 	char *strPolish = malloc(MAX_POLISH_LENGTH);

Sure enough, you did what I thought you'd do.  You allocate MAX_POLISH_LENGTH
characters, but then, you use MAX_POLISH_LENGTH as the cap you pass to
strAppendChar, meaning that if your Polish string contains MAX_POLISH_LENGTH-1
characters, you will end up writing one past the end of the array.

It turns out that the fencepost conventions people use in C are there for
a good reason.


> 	if (strPolish == 0)
> 		errorHandler("Can't get storage");
> 	strPolish[0] = '\0';

Since errorHandler doesn't exit in any way, you're still going to segfault
(or whatever) when you reach this line.

> 	if (!expression(strInfix,
> 		            strPolish,
> 					&intIndex,
> 					stringLength(strInfix) - 1))
> 	{
> 		errorHandler("Can't parse expression");
> 		return "";

Oh, that's great.  You are now returning pointers from this function which
MAY OR MAY NOT be the results of malloc(), so you can't free them safely.

This should be:
	strPolish[0] = '\0';
	return strPolish;

> 	printf("Expect 10 113 + a *: %s\n",
> 		   infix2Polish("(10+113)*a"));

Because infix2Polish allocates memory, but you never free the results, this
is a memory leak.

> int main(int intArgCount, char **strArgs)

Renaming the args to main, not useful.  Declaring them when you're not using
them, also not useful.

> {
>     tester();
>     return;

return without a value in function not returning void

Okay, I will concede one point:  You would actually be better off reading
Schildt's books than muddling along without.  You'd be even better off reading
a better C book, but really, any port in a storm.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/2/2009 6:39:48 PM
On 2009-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> It really makes the regs (and, most especially, the reg-wannabees like
> Mr. Streater here) nervous to be seen as in any way requesting anything
> (other than order-in-the-court, of course).  That is, it destroys their
> game to be seen as being in the position of asking for something as
> opposed to always being the givers of knowledge.

.... Wow, you're really committed to this idea that your social instincts
are the way everyone else in the world works, exactly.

Sure must be cool being a member of a species with absolutely NO variance
in cognitive experience.  Over here on my planet, see, different people aren't
all the same, so some people might value different things than others.

In fact, I ask people for stuff all the time, and I have no problems admitting
that I need a lot of help from people to get by much of the time.  Fine by
me.  I'm not the one with a crippling ego problem.

> Notice the recent hoo-hah about whether or not Kiki/RH had requested
> anything from Jacob.  Notice how much virtual ink was expended
> discussing what was, in fact, just a small, jocular, off-the-cuff remark
> from Jacob.

I don't tihnk I'd call it "jocular".

> Kiki was obviously much distressed by both of the following
> implications, and spared no effort to try to dispel both:

I used to watch arguments between people who were firmly convinced that
it would persuade people that evolution never happened if Darwin had
recanted, and people who didn't actually care what Darwin thought.  The
thing is, the latter people didn't care what Darwin thought because they
were pure empiricists; they thought statements were true if supported
by evidence, and false if not supported by evidence.

The thing is, the evidence suggests that Darwin didn't recant.  So,
being much concerned with evidence, they pointed this out...  And the
people who thought it was all about authority figures interpreted this,
not as an argument over facts, but as an attempt to defend the authority
of the figure.

You're doing the same thing.

>     1) That they (Kiki and/or RH) had requested something from lowly Jacob.

I have requested things from Jacob.  I disagree with him strongly on some
issues, but I reject categorically the notion that he is "lowly".  He's an
implementor who is, to the best of my knowledge, *single-handedly* maintaining
a C compiler.  I would state without fear of contradiction that there are
aspects of C compiler development and maintenance which he knows much better
than I do.  (And my day job is, specifically, compiler maintenance and
support.  The difference is, I'm just a gopher between our customers and
our toolchain vendor.)

>     2) That, in response to and in fulfillment of said request, Jacob
> 	had actually, out of the goodness of his heart, produced something
> 	of value.

I do not believe that such a request occurred.  I wouldn't have made one
because I am not in Jacob's target market (I don't use Windows much).  But
I would never deny that Jacob produced something of value.  If I found
myself obliged to use Windows systems much, I am confident that Jacob's
compiler would be useful to me, and I'd certainly prefer it to whatever
I could get from Microsoft.

Now, the great thing is:  I pointed these things out because I'm obsessive
about factual accuracy, and you're going to reinterpret them in terms of
status.  The difference being, I can conceive of people using other values
than I have.  You apparently still can't.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/2/2009 6:47:25 PM
On 2009-11-02, Richard <rgrdev_@gmail.com> wrote:
> Yowza. I can see that would have created a stir. Along that vein of
> thought, I'm  amazed that they tolerate Keighley aiding and abetting
> them recently - almost as if he had his own seat at the high table.

If you're amazed by something, that's often a sign that you have a faulty
premise.

Hint:  There is no "high table".  I don't recognize peoples' names very
much, and I don't much care who's who.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/2/2009 6:48:22 PM
On 2009-11-02, spinoza1111 <spinoza1111@yahoo.com> wrote:
> On Nov 2, 10:10�pm, Gene <gene.ress...@gmail.com> wrote:
>> // parser for gramar:
>> // expr -> term { [+-] term }
>> // term -> factor { [*/] factor }

> Again it looks like you stole this,

No it doesn't.  There are multiple differences precisely because he's
expressing it in a wildly different way.

> and again I forgive you, or ask
> your forgiveness if I have accused you falsely. If you swiped it from
> my grammar, you forgot to put an asterisk after the right curley
> braces to indicate that there can be zero, one or more occurences of
> the term or factor, preceded by its binary operator.

He didn't forget anything of the sort.  He's using {} for optional
things, because he's using [] for character classes.

> If you did not swipe it, then you may be using curley braces to
> indicate zero one or more repetitions of the braced content; but this
> would be your unique idiom, I've never seen it.

It's not particularly unique.

> Also, the standard meaning of square brackets is that the bracketed
> material is optional: but the binary operators you have bracketed are
> most assuredly not optional as I think you know.

It's a Unixy idiom (now POSIXy) that [ab] means "either a or b" when referring
to individual characters.  Found in both shell patterns/globs and regular
expressions.

I don't think anyone stole the notion of an expression being one or more
additive expressions separated by plus/minus signs, and an additive
expression being one or more multiplicitive expressions separated by
times and divide symbols.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/2/2009 6:51:55 PM
In article <slrnheuaen.cp3.usenet-nospam@guild.seebs.net>,
Seebs  <usenet-nospam@seebs.net> wrote:
>On 2009-11-02, Richard <rgrdev_@gmail.com> wrote:
>> Yowza. I can see that would have created a stir. Along that vein of
>> thought, I'm  amazed that they tolerate Keighley aiding and abetting
>> them recently - almost as if he had his own seat at the high table.
>
>If you're amazed by something, that's often a sign that you have a faulty
>premise.
>
>Hint:  There is no "high table".  I don't recognize peoples' names very
>much, and I don't much care who's who.

As such, by your own admission, your remarks don't count for much.

You can't really follow the action unless/until you can remember the
players's names (i.e., keep track of the characters).

0
gazelle3 (1726)
11/2/2009 7:02:00 PM
In article <slrnheuact.cp3.usenet-nospam@guild.seebs.net>,
Seebs  <usenet-nospam@seebs.net> wrote:
>On 2009-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> It really makes the regs (and, most especially, the reg-wannabees like
>> Mr. Streater here) nervous to be seen as in any way requesting anything
>> (other than order-in-the-court, of course).  That is, it destroys their
>> game to be seen as being in the position of asking for something as
>> opposed to always being the givers of knowledge.
>
>... Wow, you're really committed to this idea that your social instincts
>are the way everyone else in the world works, exactly.

Blah, blah, blah.  Same old, same old...

Note: I wasn't talking about you at all here.  This was actually history
prior to your arrival here, and involved other characters (Kiki & RH).

You seem to have a propensity for latching onto things that I say and
assuming that I'm talking about you.  Not that I don't ever talk about
you, but not as often as you seem to think.

0
gazelle3 (1726)
11/2/2009 7:05:15 PM
On 2009-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <slrnheuaen.cp3.usenet-nospam@guild.seebs.net>,
> Seebs  <usenet-nospam@seebs.net> wrote:
>>Hint:  There is no "high table".  I don't recognize peoples' names very
>>much, and I don't much care who's who.

> As such, by your own admission, your remarks don't count for much.

Except of course they do...  Because your central claim is that all us
"regs" are obsessed with status and persons.

So if we're not, you've lost on the merits.

In short, if I'm not qualified as a witness to testify to the falseness of
your claims, my lack of qualification is proof of the falseness of your
claims.  Either way, you're wrong.  The clique is your social instincts
misfiring in a textual medium, not a thing with external reality.  Please
contact Rene Descartes and seek a full refund.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/2/2009 7:24:30 PM
On 2009-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> Note: I wasn't talking about you at all here.  This was actually history
> prior to your arrival here, and involved other characters (Kiki & RH).

Oh, of course!  But you've not demonstrated that your hallucinations of
social realities are conected to the external world.

> You seem to have a propensity for latching onto things that I say and
> assuming that I'm talking about you.  Not that I don't ever talk about
> you, but not as often as you seem to think.

If there's "regulars" in comp.lang.c, I must be one of them, because I've
been around forever and people tend to listen to me, because I know C.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/2/2009 7:25:39 PM
In article <slrnheucif.df3.usenet-nospam@guild.seebs.net>,
Seebs  <usenet-nospam@seebs.net> wrote:
>On 2009-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> In article <slrnheuaen.cp3.usenet-nospam@guild.seebs.net>,
>> Seebs  <usenet-nospam@seebs.net> wrote:
>>>Hint:  There is no "high table".  I don't recognize peoples' names very
>>>much, and I don't much care who's who.
>
>> As such, by your own admission, your remarks don't count for much.
>
>Except of course they do...  Because your central claim is that all us
>"regs" are obsessed with status and persons.

Except I never said any such thing.

(Rest of post snipped: the usual blah, blah, blah from Seebs)

0
gazelle3 (1726)
11/2/2009 7:28:14 PM
On 2009-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> Except I never said any such thing.

Ahh, but you did.  You have said that it's all really about status.  To
everyone.  That this is the "real world", etcetera.

If it's not, you're wrong.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/2/2009 7:39:28 PM
In article <slrnheuckk.df3.usenet-nospam@guild.seebs.net>,
 Seebs <usenet-nospam@seebs.net> wrote:

> On 2009-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> > Note: I wasn't talking about you at all here.  This was actually history
> > prior to your arrival here, and involved other characters (Kiki & RH).
> 
> Oh, of course!  But you've not demonstrated that your hallucinations of
> social realities are conected to the external world.
> 
> > You seem to have a propensity for latching onto things that I say and
> > assuming that I'm talking about you.  Not that I don't ever talk about
> > you, but not as often as you seem to think.
> 
> If there's "regulars" in comp.lang.c, I must be one of them, because I've
> been around forever and people tend to listen to me, because I know C.

I'm not only not, but have no interest in being one. I'm just here for 
the beer. Spinny infested the PHP or as it might be JavaScript NG a 
couple of years or so ago, and he indulged in the same name-calling, 
bullying tactics, and soviet logic then as you see here. I recall 
counting at one point (somehow) and finding we'd got to 800 posts or so 
before he wandered off.

In any case I'd be unlikely to be "accepted" as what Mr McCormack refers 
to as a "regular" as I haven't used C to any extent for 20 years and so 
am in little position to comment on any C specifics.

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689
0
timstreater (945)
11/2/2009 8:20:57 PM
In article <hcnkt1$261$1@news.xmission.com>,
 gazelle@shell.xmission.com (Kenny McCormack) wrote:

> In article <timstreater-939853.21205702112009@news.individual.net>,
> Tim Streater  <timstreater@waitrose.com> wrote:
> ...
> >I'm not only not, but have no interest in being one. I'm just here for 
> >the beer. Spinny infested the PHP or as it might be JavaScript NG a 
> >couple of years or so ago, and he indulged in the same name-calling, 
> >bullying tactics, and soviet logic then as you see here. I recall 
> >counting at one point (somehow) and finding we'd got to 800 posts or so 
> >before he wandered off.
> 
> You were classed as a "reg wannabee".  Sit up straight in your chair,
> and pay attention!

Which part of "have no interest in being one" do you not understand?

-- 
Tim

"That excessive bail ought not to be required, nor excessive fines imposed,
nor cruel and unusual punishments inflicted"  --  Bill of Rights 1689
0
timstreater (945)
11/2/2009 9:56:02 PM
In article <timstreater-939853.21205702112009@news.individual.net>,
Tim Streater  <timstreater@waitrose.com> wrote:
....
>I'm not only not, but have no interest in being one. I'm just here for 
>the beer. Spinny infested the PHP or as it might be JavaScript NG a 
>couple of years or so ago, and he indulged in the same name-calling, 
>bullying tactics, and soviet logic then as you see here. I recall 
>counting at one point (somehow) and finding we'd got to 800 posts or so 
>before he wandered off.

You were classed as a "reg wannabee".  Sit up straight in your chair,
and pay attention!

>In any case I'd be unlikely to be "accepted" as what Mr McCormack refers 
>to as a "regular" as I haven't used C to any extent for 20 years and so 
>am in little position to comment on any C specifics.

C skills are irrelevant.  It's the ability to bully and name-call, and,
above all, as they used to say 300 or so years ago, Keep The Faith!

0
gazelle3 (1726)
11/2/2009 10:02:09 PM
Seebs <usenet-nospam@seebs.net> writes:

> On 2009-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
>> Note: I wasn't talking about you at all here.  This was actually history
>> prior to your arrival here, and involved other characters (Kiki & RH).
>
> Oh, of course!  But you've not demonstrated that your hallucinations of
> social realities are conected to the external world.
>
>> You seem to have a propensity for latching onto things that I say and
>> assuming that I'm talking about you.  Not that I don't ever talk about
>> you, but not as often as you seem to think.
>
> If there's "regulars" in comp.lang.c, I must be one of them, because I've
> been around forever and people tend to listen to me, because I know C.
>
> -s

It strikes me that most, if not all, of the threads you participate in
descend down into pedantic nit picking and "reg" shilling.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
rgrdev_ (1097)
11/2/2009 10:47:06 PM
gazelle@shell.xmission.com (Kenny McCormack) writes:

> In article <timstreater-939853.21205702112009@news.individual.net>,
> Tim Streater  <timstreater@waitrose.com> wrote:
> ...
>>I'm not only not, but have no interest in being one. I'm just here for 
>>the beer. Spinny infested the PHP or as it might be JavaScript NG a 
>>couple of years or so ago, and he indulged in the same name-calling, 
>>bullying tactics, and soviet logic then as you see here. I recall 
>>counting at one point (somehow) and finding we'd got to 800 posts or so 
>>before he wandered off.
>
> You were classed as a "reg wannabee".  Sit up straight in your chair,
> and pay attention!
>
>>In any case I'd be unlikely to be "accepted" as what Mr McCormack
>>refers 

"Mr". +1 point.

>>to as a "regular" as I haven't used C to any extent for 20 years and so 
>>am in little position to comment on any C specifics.
>
> C skills are irrelevant.  It's the ability to bully and name-call, and,
> above all, as they used to say 300 or so years ago, Keep The Faith!
>

Yup.

Streaker is not *that* far off level entry one though. Keighley will
need to be promoted to make room though and I'm not sure some of the
regs will go along with that. He doesn't pose enough. Possibly a post
from him about how debuggers are unnecessary and how he once found a bug
in 40000000000000 lines of C code printed out on a dot matrix printer
PROVES that debuggers are only for idiots. Like Richard Stallman who
wrote gdb ... That MIGHT budge the more intransigent regs who would
normally black ball him. Having said that use of "Mr", mention of "Beer"
and his own mantra, "Soviet Logic" i addition to modestly playing down
his own C genius (regs never boast openly - they coyly suggest they can
only help with their modest experience and SURELY there are people
better qualified out there .....) suggests that Streaker went to the same
school as Heathfield and might get bumped over Nick in the c.l.c pecking
order.

Only time will tell.

:-)

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
rgrdev_ (1097)
11/2/2009 10:53:21 PM
Seebs <usenet-nospam@seebs.net> writes:

> On 2009-11-02, Richard <rgrdev_@gmail.com> wrote:
>> Yowza. I can see that would have created a stir. Along that vein of
>> thought, I'm  amazed that they tolerate Keighley aiding and abetting
>> them recently - almost as if he had his own seat at the high table.
>
> If you're amazed by something, that's often a sign that you have a faulty
> premise.
>
> Hint:  There is no "high table".  I don't recognize peoples' names very
> much, and I don't much care who's who.
>
> -s

Sure you don't.

Which suggests you are emotionally dead. It's as plane as that chip on
your shoulder that the "reg" high table exists. If YOU can not read the
order in the chaos then you need to take a break.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
rgrdev_ (1097)
11/2/2009 10:54:42 PM
gazelle@shell.xmission.com (Kenny McCormack) writes:

> In article <slrnheuaen.cp3.usenet-nospam@guild.seebs.net>,
> Seebs  <usenet-nospam@seebs.net> wrote:
>>On 2009-11-02, Richard <rgrdev_@gmail.com> wrote:
>>> Yowza. I can see that would have created a stir. Along that vein of
>>> thought, I'm  amazed that they tolerate Keighley aiding and abetting
>>> them recently - almost as if he had his own seat at the high table.
>>
>>If you're amazed by something, that's often a sign that you have a faulty
>>premise.
>>
>>Hint:  There is no "high table".  I don't recognize peoples' names very
>>much, and I don't much care who's who.
>
> As such, by your own admission, your remarks don't count for much.
>
> You can't really follow the action unless/until you can remember the
> players's names (i.e., keep track of the characters).
>

All documented here:

http://www.politicsforum.org/images/flame_warriors/

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
rgrdev_ (1097)
11/2/2009 10:59:14 PM
On 2009-11-02, Richard <rgrdev_@gmail.com> wrote:
> Which suggests you are emotionally dead.

Or possibly just not obsessed with status and cliques to such an extent
that I invent them even when they don't exist?

> It's as plane as that chip on
> your shoulder that the "reg" high table exists.

Or, alternatively, that your social instincts aren't 100% reliable.

> If YOU can not read the
> order in the chaos then you need to take a break.

I can read order in chaos just fine -- quite well, even.  What's even more
impressive, though, is that I can also recognize that sometimes my brain
guesses at a pattern and it turns out to be wrong, so I actually check
the results I get handed instead of treating every instinctive evaluation
as Revealed Truth.  Works great.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/2/2009 11:12:32 PM
On 2009-11-02, Tim Streater <timstreater@waitrose.com> wrote:
> Which part of "have no interest in being one" do you not understand?

I've argued with guys like this before.  They genuinely can't accept
that other people are not solely driven by desire for high status.  It's
incomprehensible to them.  It's like trying to explain "conservation
of shared resources" to a spammer.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/2/2009 11:13:14 PM
Tim Streater <timstreater@waitrose.com> writes:

> In article <hcnkt1$261$1@news.xmission.com>,
>  gazelle@shell.xmission.com (Kenny McCormack) wrote:
>
>> In article <timstreater-939853.21205702112009@news.individual.net>,
>> Tim Streater  <timstreater@waitrose.com> wrote:
>> ...
>> >I'm not only not, but have no interest in being one. I'm just here for 
>> >the beer. Spinny infested the PHP or as it might be JavaScript NG a 
>> >couple of years or so ago, and he indulged in the same name-calling, 
>> >bullying tactics, and soviet logic then as you see here. I recall 
>> >counting at one point (somehow) and finding we'd got to 800 posts or so 
>> >before he wandered off.
>> 
>> You were classed as a "reg wannabee".  Sit up straight in your chair,
>> and pay attention!
>
> Which part of "have no interest in being one" do you not understand?

So you concur there is such a thing as a reg clique here then? Good. We
are making progress Mr Streater.

Here is Keith : http://www.flamewarriors.com/warriorshtm/android.htm

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
rgrdev_ (1097)
11/2/2009 11:14:55 PM
Seebs <usenet-nospam@seebs.net> writes:

> On 2009-11-02, Richard <rgrdev_@gmail.com> wrote:
>> Which suggests you are emotionally dead.
>
> Or possibly just not obsessed with status and cliques to such an extent
> that I invent them even when they don't exist?

Obsessed? You worry to much. It's not at all an obsession. It's a mere
mention and amused study at times.

>
>> It's as plane as that chip on
>> your shoulder that the "reg" high table exists.
>
> Or, alternatively, that your social instincts aren't 100% reliable.

'Fraid they're pretty well tuned old son.

>
>> If YOU can not read the
>> order in the chaos then you need to take a break.
>
> I can read order in chaos just fine -- quite well, even.  What's even more
> impressive, though, is that I can also recognize that sometimes my brain
> guesses at a pattern and it turns out to be wrong, so I actually check
> the results I get handed instead of treating every instinctive evaluation
> as Revealed Truth.  Works great.
>
> -s

Good. Then off you go. There's a lot of history in c.l.c to help you
re-evaluate.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
rgrdev_ (1097)
11/2/2009 11:25:19 PM
Seebs <usenet-nospam@seebs.net> writes:

> On 2009-11-02, Tim Streater <timstreater@waitrose.com> wrote:
>> Which part of "have no interest in being one" do you not understand?
>
> I've argued with guys like this before.  They genuinely can't accept
> that other people are not solely driven by desire for high status.  It's
> incomprehensible to them.  It's like trying to explain "conservation
> of shared resources" to a spammer.
>
> -s

Crikey. It's like another Mr Logic has been cloned.

1) No one said "all other people"
2) No one said "solely by status"
3) Its not incomprehensible that we do not match the FALSE data you just
provided.
4) Your last sentence was nothing more than clueless verbiage to elicit
our awe at your savage put downs.

All in all an pretty epic FAIL since you are assuming things of others
which have no basis in reality in order to deliver your not so killer
judgements.

You are however clearly in love with yourself and so are very well
qualified for a seat at the reg high table. Just be sure not to use
Heathfield's napkin ring or take first dibs at seconds when the rhubarb
crumble is on.

-- 
"Avoid hyperbole at all costs, its the most destructive argument on
the planet" - Mark McIntyre in comp.lang.c
0
rgrdev_ (1097)
11/2/2009 11:30:10 PM
On 2009-11-02, Richard <rgrdev_@gmail.com> wrote:
> Obsessed? You worry to much. It's not at all an obsession. It's a mere
> mention and amused study at times.

Really?  'cuz I've seen a ton of posts from you that talk about the topic,
and very few that don't seem related to it.

>> Or, alternatively, that your social instincts aren't 100% reliable.

> 'Fraid they're pretty well tuned old son.

Pretty well tuned is not the same thing as 100% reliable.  In particular,
if you have normally functional, or even fairly good, social instincts for
face-to-face communications, the usual state is that you're going to be
noticably less good at pure-text media -- and yet that you're going to *feel*
just as confident.

> Good. Then off you go. There's a lot of history in c.l.c to help you
> re-evaluate.

I've rechecked it a couple of times, and you're still imposing a social
interpretation that does not appear to model any external reality.

The mere fact that you're dismissive and confident but have not presented
concrete evidence supports my conclusion, thus far.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/2/2009 11:41:12 PM
On 2009-11-02, Richard <rgrdev_@gmail.com> wrote:
> 1) No one said "all other people"

You don't have to say it.  When you have repeatedly evaluated other
people as acting a given way despite clear evidence to the contrary, and
have never been seen to evaluate people as acting differently, that's
pretty solid.

> 2) No one said "solely by status"

Yeah, but if it's your one-size-fits-all model of everything, it might
as well be -- especially when you apply it to people for whom status
is not a meaningful word.

> All in all an pretty epic FAIL since you are assuming things of others
> which have no basis in reality in order to deliver your not so killer
> judgements.

Boy, you sure are mad about that.  You continue to talk about this
exclusive clique and use a lot of emotionally-laden words that clearly
communicate jealousy, but you never, ever, provide any kind of specific
evidence supporting your claim -- you just handwave it to obviousness.
That's what we call an *instinct* -- and social instincts on plain text
are worth less than the paper they're printed on.

When you can make an actual argument, go ahead.

> You are however clearly in love with yourself and so are very well
> qualified for a seat at the reg high table.

And again, you interpret my behavior according to your instincts, not mine.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/2/2009 11:44:04 PM
In article <timstreater-A55485.22560202112009@news.individual.net>,
Tim Streater  <timstreater@waitrose.com> wrote:
>In article <hcnkt1$261$1@news.xmission.com>,
> gazelle@shell.xmission.com (Kenny McCormack) wrote:
>
>> In article <timstreater-939853.21205702112009@news.individual.net>,
>> Tim Streater  <timstreater@waitrose.com> wrote:
>> ...
>> >I'm not only not, but have no interest in being one. I'm just here for 
>> >the beer. Spinny infested the PHP or as it might be JavaScript NG a 
>> >couple of years or so ago, and he indulged in the same name-calling, 
>> >bullying tactics, and soviet logic then as you see here. I recall 
>> >counting at one point (somehow) and finding we'd got to 800 posts or so 
>> >before he wandered off.
>> 
>> You were classed as a "reg wannabee".  Sit up straight in your chair,
>> and pay attention!
>
>Which part of "have no interest in being one" do you not understand?

What part of "I don't believe you", aka, "I hear you calling, but you
can't come in", aka (and less charitably), "you're lying".

The regs (and the wannabees of various stripes) lie all the time.
It is so amusing to watch.

0
gazelle3 (1726)
11/2/2009 11:51:03 PM
spinoza1111 <spinoza1111@yahoo.com> writes:

> This post contains the promised C code version of the infix to Polish
> notation convertor.

Seebs as commented on the code in detail, so I'll just add that you
need more work on some error cases.  Despite a lot of unnecessary
counting of parentheses, cases like "1)" and "(((0))))" are silently
ignored.

Also, I think it would be better to try to detect all input that can't
be converted.  For example, "&" gives an error, but "1&2" does not.

In order to be positive, I'll stick my neck out and post my solution.
No one has posted the classic operator priority parsing algorithm, so
this solution is new in the thread.  The code is simpler than the code
you get from turning grammar rules directly into paring functions,
although the benefit is certainly borderline for expressions with only
two priorities.  I've added an extra, high priority, operator (^) to
illustrate the algorithm's generality.

All the work heavy is done in one function (convert_operators in the
code below) that parses sequences of terms whose length is determined
by the priority of the operators that are seen.  If these are
determined from a run-time table, you get the advantage of being able
to add and remove operators as well as changing the operator
precedences as the parser runs.

Most of the code is scaffolding and includes an expanding character
buffer to hold the growing output string.  C99 features are used in a
couple of places.

#include <stdio.h>
#include <stdbool.h>
#include <stdlib.h>
#include <string.h>
#include <ctype.h>

/*
 * This type, and the two str_ functions, provide an expanding
 * character buffer to take the growing output string.
 */

typedef struct string string;

void str_add(string *s, char c);
const char *str_string(string *s);

static bool convert_term(const char **s, string *out);
static bool convert_operators(const char **s, int precedence, string *out);
static bool convert_expression(const char **s, string *out);

static char next(const char **s);
static bool expect(const char **s, char c);
static bool missing(const char *what, char where);


/*
 * The grammar is largely specified by this function that determines
 * if a token (in this case a single character) is an operator and,
 * if so, what precedence it has.
 */

static int precedence_of(char op)
{
     static const char *op_table[] = { "+-", "*/", "^", NULL };
     if (op != '\0')
          for (int i = 0; op_table[i]; i++)
               if (strchr(op_table[i], op))
                    return i;
     return -1; /* not a operator */
}

bool infix_to_postfix(const char *s, string *out)
{
     return convert_expression(&s, out) && expect(&s, '\0');
}

static bool convert_expression(const char **s, string *out)
{
     return convert_term(s, out) && convert_operators(s, 0, out);
}

static bool convert_operators(const char **s, int precedence, string *out)
{
     char op;
     int prec, right_prec;
     while ((prec = precedence_of(op = next(s))) >= precedence) {
          *s += 1;
          if (convert_term(s, out))
               while ((right_prec = precedence_of(next(s))) > prec) {
                    if (!convert_operators(s, right_prec, out))
                         return false;
               }
          else return false;
          str_add(out, op);
          str_add(out, ' ');
     }
     return true;
}

static bool convert_term(const char **s, string *out)
{
     unsigned char c = next(s);
     if (isalpha(c)) {
          str_add(out, c);
          str_add(out, ' ');
          *s += 1;
          return true;
     }
     else if (isdigit(c)) {
          while (isdigit((unsigned char)**s))
               str_add(out, *(*s)++);
          str_add(out, ' ');
          return true;
     }
     else if (c == '(') {
          *s += 1;
          return convert_expression(s, out) && expect(s, ')');
     }
     else return missing("Term", c);
}

static char next(const char **s)
{
     while (isspace((unsigned char)**s)) *s += 1;
     return **s;
}

static bool missing(const char *what, char where)
{
     fprintf(stderr, "%s expected where %s found.\n", what,
             where ? (char []){where, 0} : "end of input");
     return false;
}

static bool expect(const char **s, char c)
{
     if (next(s) != c)
          return missing(c ? (char []){c, 0} : "end of input", **s);
     *s += 1;
     return true;
}


/*
 *  An implementation of an expanding character buffer.
 */

struct string {
     size_t capacity, size;
     char *string;
};

void str_add(string *s, char c)
{
     if (s->size >= s->capacity) {
          size_t new_cap = s->capacity * 3 / 2 + 8;
          char *new_s = realloc(s->string, new_cap);
          if (!new_s) {
               fprintf(stderr, "String add: out of memory\n");
               exit(EXIT_FAILURE);
          }
          s->string = new_s;
          s->capacity = new_cap;
     }
     s->string[s->size++] = c;
}

const char *str_string(string *s)
{
     str_add(s, '\0');
     return s->string;
}


int main(int argc, char *argv[])
{
     bool result = true;
     while (--argc > 0) {
          string postfix = {0};
          if (infix_to_postfix(*++argv, &postfix))
               printf("%s\n", str_string(&postfix));
          else result = false;
          free(postfix.string);
     }
     return result ? EXIT_SUCCESS : EXIT_FAILURE;
}


-- 
Ben.
0
ben.usenet (6790)
11/3/2009 12:05:26 AM
On 2009-11-02, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> What part of "I don't believe you", aka, "I hear you calling, but you
> can't come in", aka (and less charitably), "you're lying".

Of course this is your first theory.  Hmm.

> The regs (and the wannabees of various stripes) lie all the time.

As a general rule, your view of other people is informed primarily
by your experience of yourself.

Most people don't lie very often.  The exceptions, though, have the
interesting trait that they think everyone else does it too -- especially
people they dislike.

Now, you might conclude that, since I've concluded that you're a liar,
I'm one of the people who assumes that people he dislikes are liars, but
this is not so.  I don't like Jacob very much, but I don't have
any reason to believe him to be a liar.  There are also some liars I like,
although not many.

Again:  You are not the only human ever to exist.  Other humans not only
exist, but are different from you.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/3/2009 12:38:38 AM
On 2009-11-03, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
> typedef struct string string;

I don't like the name "string" for this.  The term "string" is pretty
well defined in C, and I think this has real potential to confuse
readers in a larger program.

> void str_add(string *s, char c);

It seems like you might want to support adding strings, not just
characters.  I think I'd have gone for

	str_append(string *s, char *fmt, ...)

.... and yes, between this and a couple of my other posts, you could reasonably
infer that my first pass at implementing a fibbonacci generator in C
would look like "int fib(int n, char *fmt, ...)".

(I exaggerate, very slightly, for humorous effect.)

And again, I don't like "str" here because (although you avoided the
implementation namespace), it still seems to me that "str*" carries the
implication that it operates on a null-terminated-char-*.

> const char *str_string(string *s);

Hmm.  Imagine that we'd named the type "buffer".  I'd probably call
this buffertostr() or possibly bufferdata().

> static int precedence_of(char op)
> {
>      static const char *op_table[] = { "+-", "*/", "^", NULL };
>      if (op != '\0')
>           for (int i = 0; op_table[i]; i++)
>                if (strchr(op_table[i], op))
>                     return i;
>      return -1; /* not a operator */
> }

That's pretty.

> static bool convert_expression(const char **s, string *out)
> {
>      return convert_term(s, out) && convert_operators(s, 0, out);
> }

I'm a little put off by the magic of convert_operators apparently implying
converting the following term.

>           if (convert_term(s, out))
>                while ((right_prec = precedence_of(next(s))) > prec) {
>                     if (!convert_operators(s, right_prec, out))
>                          return false;
>                }
>           else return false;

I'd prefer {} on the if because the contents are more than a single line,
making this a tad confusing.

> void str_add(string *s, char c)
> {
>      if (s->size >= s->capacity) {
>           size_t new_cap = s->capacity * 3 / 2 + 8;

This is perfectly reasonable, but should probably be commented.

Overall, not bad at all, which is to say, certainly better than I'd have
done.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/3/2009 12:48:25 AM
Seebs <usenet-nospam@seebs.net> writes:

> On 2009-11-03, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> typedef struct string string;
>
> I don't like the name "string" for this.  The term "string" is pretty
> well defined in C, and I think this has real potential to confuse
> readers in a larger program.

I dithered about that.  In the end, since it is used only on this
program, the name was just about OK.

>> void str_add(string *s, char c);
>
> It seems like you might want to support adding strings, not just
> characters.  I think I'd have gone for
>
> 	str_append(string *s, char *fmt, ...)

In the big version of my buffer code, I do have that but I cut out all
but the two functions actually used.

<snip>

>> static bool convert_expression(const char **s, string *out)
>> {
>>      return convert_term(s, out) && convert_operators(s, 0, out);
>> }
>
> I'm a little put off by the magic of convert_operators apparently implying
> converting the following term.

Is there a neat way to write it in C that is clearer?

>>           if (convert_term(s, out))
>>                while ((right_prec = precedence_of(next(s))) > prec) {
>>                     if (!convert_operators(s, right_prec, out))
>>                          return false;
>>                }
>>           else return false;
>
> I'd prefer {} on the if because the contents are more than a single line,
> making this a tad confusing.

I have a background in teaching and have often wrestled with getting
fragments of code to fit on one OHP slide.  As a result, I have an
unnatural urge to bracket minimally, but I agree that it is not
obviously the best way to do things.

>> void str_add(string *s, char c)
>> {
>>      if (s->size >= s->capacity) {
>>           size_t new_cap = s->capacity * 3 / 2 + 8;
>
> This is perfectly reasonable, but should probably be commented.

Yup, but if I commented it, I'd have to justify the 3/2 factor!  I do
that for hysterical raisins, more than anything else.  If I thought
about it, I'd just double the capacity.  The +8 (as I am sure you
spotted) is just a hack to avoid having to treat the initial zero as a
special case.  The "code for clarity" version is probably:

  size_t new_cap = s->capacity ? 2 * s->capacity : 8;

Hmm... I think I'll go change that right now.

> Overall, not bad at all, which is to say, certainly better than I'd have
> done.

Thanks.  And thanks for looking it over.

-- 
Ben.
0
ben.usenet (6790)
11/3/2009 2:07:09 AM
On Nov 3, 1:36=A0am, Gene <gene.ress...@gmail.com> wrote:
> On Nov 2, 10:48=A0am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
>
>
>
>
> > On Nov 2, 10:10=A0pm, Gene <gene.ress...@gmail.com> wrote:
>
> > > On Oct 25, 11:33=A0pm, Tameem <etam...@gmail.com> wrote:
>
> > > > i have a string as (a+b)+8-(c/d) in Infix form.
>
> > > > how can i convert it to postfix form using C language,,,????
>
> > > I suppose that if this is homework, the due date has passed.
>
> > > // Convert ;-separated infix expressions on stdin to postfix on
> > > stdout.
> > > #include <stdio.h>
> > > #include <stdlib.h>
> > > #include <string.h>
> > > #include <stdarg.h>
>
> > > // error handler
>
> > > void die(char *msg)
> > > {
> > > =A0 fprintf(stderr, "\ndie: %s\n", msg);
> > > =A0 exit(1);
>
> > > }
>
> > > // scanner
>
> > > int lookahead;
>
> > > int peek() { return lookahead; }
>
> > > int peek_is(char *set)
> > > {
> > > =A0 return strchr(set, peek()) !=3D NULL;
>
> > > }
>
> > > void advance(void)
> > > {
> > > =A0 do lookahead =3D getchar(); while (isspace(lookahead));
>
> > > }
>
> > > // parser for gramar:
> > > // expr -> term { [+-] term }
> > > // term -> factor { [*/] factor }
> > > // factor -> ALNUM | "(" expr ")"
>
> > > void term(void);
> > > void factor(void);
>
> > > void expr(void)
> > > {
> > > =A0 term();
> > > =A0 while (peek_is("+-")) {
> > > =A0 =A0 int op =3D peek();
> > > =A0 =A0 advance();
> > > =A0 =A0 term();
> > > =A0 =A0 printf("%c", op);
> > > =A0 }
>
> > > }
>
> > > void term(void)
> > > {
> > > =A0 factor();
> > > =A0 while (peek_is("*/")) {
> > > =A0 =A0 int op =3D peek();
> > > =A0 =A0 advance();
> > > =A0 =A0 factor();
> > > =A0 =A0 printf("%c", op);
> > > =A0 }
>
> > > }
>
> > > void factor(void)
> > > {
> > > =A0 if (isalnum(peek())) {
> > > =A0 =A0 int literal =3D peek();
> > > =A0 =A0 advance();
> > > =A0 =A0 printf("%c", literal);
> > > =A0 }
> > > =A0 else if (peek() =3D=3D '(') {
> > > =A0 =A0 advance();
> > > =A0 =A0 expr();
> > > =A0 =A0 if (!peek_is(")")) die("expected )");
> > > =A0 =A0 advance();
> > > =A0 }
> > > =A0 else
> > > =A0 =A0 die("expected factor");
>
> > > }
>
> > > // user interface
>
> > > int main(void)
> > > {
> > > =A0 advance();
> > > =A0 do {
> > > =A0 =A0 expr();
> > > =A0 =A0 if (!peek_is(";")) die("expected ;");
> > > =A0 =A0 printf("\n");
> > > =A0 =A0 advance();
> > > =A0 } while (peek() !=3D EOF);
> > > =A0 return 0;
>
> > > }- Hide quoted text -
>
> > > - Show quoted text -
>
> > Thanks for this. Looks like you stole my approach, but I find that
> > most gratifying if true, and an indication that "great minds think
> > alike" if not. Your contribution at a minimum is to show just how
> > gnomic and terse one can be in C. It would not be appropriate to
> > credit me since it is a common and solid algorithm that has been
> > around for years.
>
> > Hope you don't mind, but I'm going to copy this code and incorporate
> > it in what will not be a three way test: of my C Sharp version, my C
> > version and your gnomic C. I want to add more testing (using a random
> > generator in C Sharp), a GUI and timing comparisions and shall report
> > back.- Hide quoted text -
>
> This doesn't qualify as anything like theft or great thinking. For
> fun, I wrote the code in about 5 minutes after the OP posted (based onhtt=
p://groups.google.com/group/comp.lang.c/msg/fe772c9d6a28fdc4), but
> refrained from posting it because it was probably homework for the
> OP. =A0This is a standard example or homework assignment for just about
> any undergrad course that covers recursive descent parsing. =A0The
> gramamr with minor variations is in at least a dozen complier design
> textbooks including ASU. Usually it's given in left-recursive form,
> and then the author or student go through the L-rec removal, left-
> factoring, and BNF conversion. =A0RPN generation is a trivial example of
> attribute evaluation.- Hide quoted text -

That's correct. It's as I said standard operating procedure.
Nonetheless I am interested in your use of C as I relearn C.



>
> - Show quoted text -

0
spinoza1111 (3246)
11/3/2009 2:15:52 AM
On Nov 3, 1:07=A0am, gaze...@shell.xmission.com (Kenny McCormack) wrote:
> In article <hcmu8n$c0...@news.eternal-september.org>,
>
>
>
>
>
> Richard =A0<rgrd...@gmail.com> wrote:
> >Tim Streater <timstrea...@waitrose.com> writes:
>
> >> In article
> >> <fe798d09-500d-4fc1-ba97-b4d827b92...@k13g2000prh.googlegroups.com>,
> >> =A0spinoza1111<spinoza1...@yahoo.com> wrote:
>
> >>> This post contains the promised C code version of the infix to Polish
> >>> notation convertor.
>
> >> Promised to whom? I didn't ask for it.
>
> >And you are who exactly?
>
> >And why would you be so concerned as to who it was promised for? Or do
> >all posts needs to be cleared by your good self first?
>
> It really makes the regs (and, most especially, the reg-wannabees like
> Mr. Streater here) nervous to be seen as in any way requesting anything
> (other than order-in-the-court, of course). =A0That is, it destroys their
> game to be seen as being in the position of asking for something as
> opposed to always being the givers of knowledge.
>
> Notice the recent hoo-hah about whether or not Kiki/RH had requested
> anything from Jacob. =A0Notice how much virtual ink was expended
> discussing what was, in fact, just a small, jocular, off-the-cuff remark
> from Jacob.
>
> Kiki was obviously much distressed by both of the following
> implications, and spared no effort to try to dispel both:
>
> =A0 =A0 1) That they (Kiki and/or RH) had requested something from lowly =
Jacob.
> =A0 =A0 2) That, in response to and in fulfillment of said request, Jacob
> =A0 =A0 =A0 =A0 had actually, out of the goodness of his heart, produced =
something
> =A0 =A0 =A0 =A0 of value.- Hide quoted text -
>
> - Show quoted text -

The least competent people here (Richard Heathfield, Peter Seebach,
and possibly Keith Thompson) have of course to maintain that they are
the most competent, but in fact they are at best only sources of good
advice on low-level code details AT BEST, and stunted by their
"knowledge". It's a real toxic inversion. If John Nash were to post
here anonymously, they'd kick the shit out of him because they're
thugs, and I hope to see the lot of them brought up on charges.

They've managed to reproduce the worst aspects of the corporate world:
the well-known technical inversions (where the worst technicians
become even worse managers), the bullying, the cover-ups and the
office politics. They have in fact very little interest in or passion
for technology.

In the 1970s, technology actually escaped the general filth and curse
because relationships of dominance and control hadn't been
established, but they have been re-established. Therefore these
animals use this newsgroup to play at the only thing they are really
any good at: hurting people, causing confusion, sowing hatred, and
starting fights which they're too cowardly to finish: for when a real
man fights back he discovers them claiming fashionable disorders and
calling him the bully.
0
spinoza1111 (3246)
11/3/2009 2:24:45 AM
On Nov 3, 12:14=A0am, Richard Heathfield <r...@see.sig.invalid> wrote:
> In
> <75284980-34e3-44bc-8f74-b9b2940b4...@u36g2000prn.googlegroups.com>,
>
> spinoza1111wrote:
> > On Nov 2, 10:10 pm, Gene <gene.ress...@gmail.com> wrote:
>
> <snip>
>
> >> // parser for gramar:
> >> // expr -> term { [+-] term }
> >> // term -> factor { [*/] factor }
>
> > Again it looks like you stole this,
>
> It's a minor re"word"ing of p72 of the Dragon Book [Aho, Sethi, Ullman
> 1986].

1986? That edition is out of date, as you are. But I should have
looked at my second edition.

It's not there. Furthermore, Aho et al. use curley brackets not for
syntax but for semantic actions.

The grammar is messed up but the code looks correct: the grammar as
far as I can see doesn't accept 1+1+1 but the code does.

I'll run the code and back but not to you.
>
> --
> 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

0
spinoza1111 (3246)
11/3/2009 2:31:38 AM
On Nov 3, 1:36=A0am, Gene <gene.ress...@gmail.com> wrote:
> On Nov 2, 10:48=A0am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
>
>
>
>
> > On Nov 2, 10:10=A0pm, Gene <gene.ress...@gmail.com> wrote:
>
> > > On Oct 25, 11:33=A0pm, Tameem <etam...@gmail.com> wrote:
>
> > > > i have a string as (a+b)+8-(c/d) in Infix form.
>
> > > > how can i convert it to postfix form using C language,,,????
>
> > > I suppose that if this is homework, the due date has passed.
>
> > > // Convert ;-separated infix expressions on stdin to postfix on
> > > stdout.
> > > #include <stdio.h>
> > > #include <stdlib.h>
> > > #include <string.h>
> > > #include <stdarg.h>
>
> > > // error handler
>
> > > void die(char *msg)
> > > {
> > > =A0 fprintf(stderr, "\ndie: %s\n", msg);
> > > =A0 exit(1);
>
> > > }
>
> > > // scanner
>
> > > int lookahead;
>
> > > int peek() { return lookahead; }
>
> > > int peek_is(char *set)
> > > {
> > > =A0 return strchr(set, peek()) !=3D NULL;
>
> > > }
>
> > > void advance(void)
> > > {
> > > =A0 do lookahead =3D getchar(); while (isspace(lookahead));
>
> > > }
>
> > > // parser for gramar:
> > > // expr -> term { [+-] term }
> > > // term -> factor { [*/] factor }
> > > // factor -> ALNUM | "(" expr ")"
>
> > > void term(void);
> > > void factor(void);
>
> > > void expr(void)
> > > {
> > > =A0 term();
> > > =A0 while (peek_is("+-")) {
> > > =A0 =A0 int op =3D peek();
> > > =A0 =A0 advance();
> > > =A0 =A0 term();
> > > =A0 =A0 printf("%c", op);
> > > =A0 }
>
> > > }
>
> > > void term(void)
> > > {
> > > =A0 factor();
> > > =A0 while (peek_is("*/")) {
> > > =A0 =A0 int op =3D peek();
> > > =A0 =A0 advance();
> > > =A0 =A0 factor();
> > > =A0 =A0 printf("%c", op);
> > > =A0 }
>
> > > }
>
> > > void factor(void)
> > > {
> > > =A0 if (isalnum(peek())) {
> > > =A0 =A0 int literal =3D peek();
> > > =A0 =A0 advance();
> > > =A0 =A0 printf("%c", literal);
> > > =A0 }
> > > =A0 else if (peek() =3D=3D '(') {
> > > =A0 =A0 advance();
> > > =A0 =A0 expr();
> > > =A0 =A0 if (!peek_is(")")) die("expected )");
> > > =A0 =A0 advance();
> > > =A0 }
> > > =A0 else
> > > =A0 =A0 die("expected factor");
>
> > > }
>
> > > // user interface
>
> > > int main(void)
> > > {
> > > =A0 advance();
> > > =A0 do {
> > > =A0 =A0 expr();
> > > =A0 =A0 if (!peek_is(";")) die("expected ;");
> > > =A0 =A0 printf("\n");
> > > =A0 =A0 advance();
> > > =A0 } while (peek() !=3D EOF);
> > > =A0 return 0;
>
> > > }- Hide quoted text -
>
> > > - Show quoted text -
>
> > Thanks for this. Looks like you stole my approach, but I find that
> > most gratifying if true, and an indication that "great minds think
> > alike" if not. Your contribution at a minimum is to show just how
> > gnomic and terse one can be in C. It would not be appropriate to
> > credit me since it is a common and solid algorithm that has been
> > around for years.
>
> > Hope you don't mind, but I'm going to copy this code and incorporate
> > it in what will not be a three way test: of my C Sharp version, my C
> > version and your gnomic C. I want to add more testing (using a random
> > generator in C Sharp), a GUI and timing comparisions and shall report
> > back.- Hide quoted text -
>
> This doesn't qualify as anything like theft or great thinking. For

It's better than anything Heathfield, Thompson or Seebach could do.
But I think you messed up the grammar...but not the code.

expr -> term { [+-] term }

doesn't parse 1+1+1.

> fun, I wrote the code in about 5 minutes after the OP posted (based onhtt=
p://groups.google.com/group/comp.lang.c/msg/fe772c9d6a28fdc4), but
> refrained from posting it because it was probably homework for the
> OP. =A0This is a standard example or homework assignment for just about
> any undergrad course that covers recursive descent parsing. =A0The
> gramamr with minor variations is in at least a dozen complier design
> textbooks including ASU. Usually it's given in left-recursive form,
> and then the author or student go through the L-rec removal, left-
> factoring, and BNF conversion. =A0RPN generation is a trivial example of
> attribute evaluation.- Hide quoted text -
>
> - Show quoted text -

0
spinoza1111 (3246)
11/3/2009 2:33:56 AM
On Nov 2, 9:33=A0pm, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Nov 3, 1:36=A0am, Gene <gene.ress...@gmail.com> wrote:
>
>
>
>
>
> > On Nov 2, 10:48=A0am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > > On Nov 2, 10:10=A0pm, Gene <gene.ress...@gmail.com> wrote:
>
> > > > On Oct 25, 11:33=A0pm, Tameem <etam...@gmail.com> wrote:
>
> > > > > i have a string as (a+b)+8-(c/d) in Infix form.
>
> > > > > how can i convert it to postfix form using C language,,,????
>
> > > > I suppose that if this is homework, the due date has passed.
>
> > > > // Convert ;-separated infix expressions on stdin to postfix on
> > > > stdout.
> > > > #include <stdio.h>
> > > > #include <stdlib.h>
> > > > #include <string.h>
> > > > #include <stdarg.h>
>
> > > > // error handler
>
> > > > void die(char *msg)
> > > > {
> > > > =A0 fprintf(stderr, "\ndie: %s\n", msg);
> > > > =A0 exit(1);
>
> > > > }
>
> > > > // scanner
>
> > > > int lookahead;
>
> > > > int peek() { return lookahead; }
>
> > > > int peek_is(char *set)
> > > > {
> > > > =A0 return strchr(set, peek()) !=3D NULL;
>
> > > > }
>
> > > > void advance(void)
> > > > {
> > > > =A0 do lookahead =3D getchar(); while (isspace(lookahead));
>
> > > > }
>
> > > > // parser for gramar:
> > > > // expr -> term { [+-] term }
> > > > // term -> factor { [*/] factor }
> > > > // factor -> ALNUM | "(" expr ")"
>
> > > > void term(void);
> > > > void factor(void);
>
> > > > void expr(void)
> > > > {
> > > > =A0 term();
> > > > =A0 while (peek_is("+-")) {
> > > > =A0 =A0 int op =3D peek();
> > > > =A0 =A0 advance();
> > > > =A0 =A0 term();
> > > > =A0 =A0 printf("%c", op);
> > > > =A0 }
>
> > > > }
>
> > > > void term(void)
> > > > {
> > > > =A0 factor();
> > > > =A0 while (peek_is("*/")) {
> > > > =A0 =A0 int op =3D peek();
> > > > =A0 =A0 advance();
> > > > =A0 =A0 factor();
> > > > =A0 =A0 printf("%c", op);
> > > > =A0 }
>
> > > > }
>
> > > > void factor(void)
> > > > {
> > > > =A0 if (isalnum(peek())) {
> > > > =A0 =A0 int literal =3D peek();
> > > > =A0 =A0 advance();
> > > > =A0 =A0 printf("%c", literal);
> > > > =A0 }
> > > > =A0 else if (peek() =3D=3D '(') {
> > > > =A0 =A0 advance();
> > > > =A0 =A0 expr();
> > > > =A0 =A0 if (!peek_is(")")) die("expected )");
> > > > =A0 =A0 advance();
> > > > =A0 }
> > > > =A0 else
> > > > =A0 =A0 die("expected factor");
>
> > > > }
>
> > > > // user interface
>
> > > > int main(void)
> > > > {
> > > > =A0 advance();
> > > > =A0 do {
> > > > =A0 =A0 expr();
> > > > =A0 =A0 if (!peek_is(";")) die("expected ;");
> > > > =A0 =A0 printf("\n");
> > > > =A0 =A0 advance();
> > > > =A0 } while (peek() !=3D EOF);
> > > > =A0 return 0;
>
> > > > }- Hide quoted text -
>
> > > > - Show quoted text -
>
> > > Thanks for this. Looks like you stole my approach, but I find that
> > > most gratifying if true, and an indication that "great minds think
> > > alike" if not. Your contribution at a minimum is to show just how
> > > gnomic and terse one can be in C. It would not be appropriate to
> > > credit me since it is a common and solid algorithm that has been
> > > around for years.
>
> > > Hope you don't mind, but I'm going to copy this code and incorporate
> > > it in what will not be a three way test: of my C Sharp version, my C
> > > version and your gnomic C. I want to add more testing (using a random
> > > generator in C Sharp), a GUI and timing comparisions and shall report
> > > back.- Hide quoted text -
>
> > This doesn't qualify as anything like theft or great thinking. For
>
> It's better than anything Heathfield, Thompson or Seebach could do.
> But I think you messed up the grammar...but not the code.
>
> expr -> term { [+-] term }
>
> doesn't parse 1+1+1.
>
>
>
> > fun, I wrote the code in about 5 minutes after the OP posted (based onh=
ttp://groups.google.com/group/comp.lang.c/msg/fe772c9d6a28fdc4), but
> > refrained from posting it because it was probably homework for the
> > OP. =A0This is a standard example or homework assignment for just about
> > any undergrad course that covers recursive descent parsing. =A0The
> > gramamr with minor variations is in at least a dozen complier design
> > textbooks including ASU. Usually it's given in left-recursive form,
> > and then the author or student go through the L-rec removal, left-
> > factoring, and BNF conversion. =A0RPN generation is a trivial example o=
f
> > attribute evaluation.- Hide quoted text -
>

The curly braces are BNF for zero or more repeats.  This translates to
the while loop.  I can't see an error.
0
gene.ressler (563)
11/3/2009 3:58:28 AM
spinoza1111 <spinoza1111@yahoo.com> writes:
<snip>
> But I think you messed up the grammar...but not the code.
>
> expr -> term { [+-] term }
>
> doesn't parse 1+1+1.

The {} is a very common notation.  I agree that [+-] is not usual, but were
you at all puzzled by what the notation meant?  It is obviously
borrowed from regular expressions.

Wirth would have written:

  expr = term { ("+"|"-") term } .

and in plain EBNF one would write

  expr = term | { "+" , term } | { "-" , term } ;

both of which are a bit clumsy.  I found Gene's shorthand quite clear.

<snip>
-- 
Ben.
0
ben.usenet (6790)
11/3/2009 4:13:28 AM
In <335a8688-7736-4051-a19e-0032df67353e@x5g2000prf.googlegroups.com>, 
spinoza1111 wrote:

> On Nov 3, 12:14 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>> In
>> 
<75284980-34e3-44bc-8f74-b9b2940b4...@u36g2000prn.googlegroups.com>,
>>
>> spinoza1111wrote:
>> > On Nov 2, 10:10 pm, Gene <gene.ress...@gmail.com> wrote:
>>
>> <snip>
>>
>> >> // parser for gramar:
>> >> // expr -> term { [+-] term }
>> >> // term -> factor { [*/] factor }
>>
>> > Again it looks like you stole this,
>>
>> It's a minor re"word"ing of p72 of the Dragon Book [Aho, Sethi,
>> Ullman 1986].
> 
> 1986? That edition is out of date, as you are.

If it ain't broke, don't fix it. That's why I - like you - use C 
compilers that conform to C90, irrespective of whether they conform 
to C99.

> But I should have looked at my second edition.

Yes, you should always check your facts /before/ posting. But you 
hardly ever do.

> It's not there.

Well, when you say "it's not there", the appropriate reaction for a 
discerning reader is "Nilges claims it's not there", which may be an 
interesting data point but which yields little useful new 
information.

> Furthermore, Aho et al. use curley brackets not for
> syntax but for semantic actions.

A trivial difference in symbol choice. Hardly relevant.

<snip>

-- 
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
0
rjh (10791)
11/3/2009 5:28:33 AM
In 
<1e88eb4b-6541-45e4-a357-d9853bf24803@h14g2000pri.googlegroups.com>, 
spinoza1111 wrote:

> On Nov 3, 1:07 am, gaze...@shell.xmission.com (Kenny McCormack)
> wrote:
>> In article <hcmu8n$c0...@news.eternal-september.org>,
>>
>>
>>
>>
>>
>> Richard  <rgrd...@gmail.com> wrote:
>> >Tim Streater <timstrea...@waitrose.com> writes:
>>
>> >> In article
>> >> 
<fe798d09-500d-4fc1-ba97-b4d827b92...@k13g2000prh.googlegroups.com>,
>> >> spinoza1111<spinoza1...@yahoo.com> wrote:
>>
>> >>> This post contains the promised C code version of the infix to
>> >>> Polish notation convertor.
>>
>> >> Promised to whom? I didn't ask for it.
>>
>> >And you are who exactly?
>>
>> >And why would you be so concerned as to who it was promised for?
>> >Or do all posts needs to be cleared by your good self first?
>>
>> It really makes the regs (and, most especially, the reg-wannabees
>> like Mr. Streater here) nervous to be seen as in any way requesting
>> anything (other than order-in-the-court, of course).  That is, it
>> destroys their game to be seen as being in the position of asking
>> for something as opposed to always being the givers of knowledge.
>>
>> Notice the recent hoo-hah about whether or not Kiki/RH had
>> requested anything from Jacob.  Notice how much virtual ink was
>> expended discussing what was, in fact, just a small, jocular,
>> off-the-cuff remark from Jacob.
>>
>> Kiki was obviously much distressed by both of the following
>> implications, and spared no effort to try to dispel both:
>>
>> 1) That they (Kiki and/or RH) had requested something from lowly
>> Jacob. 2) That, in response to and in fulfillment of said request,
>> Jacob had actually, out of the goodness of his heart, produced
>> something of value.- Hide quoted text -
>>
>> - Show quoted text -
> 
> The least competent people here (Richard Heathfield, Peter Seebach,
> and possibly Keith Thompson) have of course to maintain that they
> are the most competent,

Rubbish for at least two reasons. Firstly, I would never even try to 
argue that.. Keith and Seebs know far more about C than I do, as do 
Chris Dollin, Eric Sosman, Chris Torek (wherever he's got to), Larry 
Jones (ditto), Dann Corbit, Ben Pfaff, Ben Bacarisse, John Bode, 
"Flash" Gordon, Richard Bos, David Thompson... many many people here 
know C far better than I do, in fact. Secondly, it would be quite 
wrong to describe any of these people (including KT and PS) as "the 
least competent people here".

> but in fact they are at best only sources of
> good advice on low-level code details AT BEST,

Clearly you don't know them very well.

> and stunted by their "knowledge".

I'd rather be stunted by knowledge than fertilised by ignorance.

<nonsense snipped>

-- 
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
0
rjh (10791)
11/3/2009 5:55:04 AM
On Nov 3, 12:13=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> spinoza1111<spinoza1...@yahoo.com> writes:
>
> <snip>
>
> > But I think you messed up the grammar...but not the code.
>
> > expr -> term { [+-] term }
>
> > doesn't parse 1+1+1.
>
> The {} is a very common notation. =A0I agree that [+-] is not usual, but =
were
> you at all puzzled by what the notation meant? =A0It is obviously
> borrowed from regular expressions.

OK, that's correct: [+-] is "the set of characters including plus and
minus" where one character is chosen from the set. But I shouldn't
have to do the work of expressing things clearly on your behalf in
English.

Nor should regular expression notation be mixed into BNF unless
absolutely necessary.

But in neither notation do curley braces imply iteration and as far as
I can see you need iteration to parse 1+1+1. What am I missing, dear
Ben?
>
> Wirth would have written:
>
> =A0 expr =3D term { ("+"|"-") term } .
>
> and in plain EBNF one would write
>
> =A0 expr =3D term | { "+" , term } | { "-" , term } ;
>
> both of which are a bit clumsy. =A0I found Gene's shorthand quite clear.

They both look wrong (and note that unlike some of the thugs and
twerps here I don't infer your global ignorance). Period ordinarily
means end of string (which is needed as I have said when you do not
lookahead to balance parentheses)....not iteration.

The second is in particular absurd. If by | you mean BNF or, then
you're saying that an expr may start with a plus sign. If you add
unary minus it may but I do not believe this was your intent. I think
you either have a private BNF notation, Bacarisse Normal Form, or you
don't know how to use BNF at all.

Here is the correct BNF as far as I can tell:

expr :=3D addFactor
expr :=3D addFactor ( [+-] addFactor ) *

As a favor to you I use the square bracket set notation and instead of
square brackets for optional sequence I've split the production into
two parts, using round parentheses to group and asterisk to iterate.

This is a correct grammar which cannot be used to generate a parser as
is:

expr :=3D addFactor
expr :=3D addFactor [+-] expr

If you get rid of recursion on the right, it must be replaced with
iteration, and you need an operator for iteration. I've taken asterisk
from regular expressions (which shouldn't be confused with BNF) to
express iteration.

With all due respect, Ben, and I mean this sincerely, you don't appear
to me to understand either regular expressions or BNF independent of
their corruption by programmers.

>
> <snip>
> --
> Ben.

0
spinoza1111 (3246)
11/3/2009 6:33:35 AM
On Nov 3, 8:05=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> spinoza1111<spinoza1...@yahoo.com> writes:
> > This post contains the promised C code version of the infix to Polish
> > notation convertor.
>
> Seebs as commented on the code in detail, so I'll just add that you
> need more work on some error cases. =A0Despite a lot of unnecessary
> counting of parentheses, cases like "1)" and "(((0))))" are silently
> ignored.

Thanks, Ben, I have confirmed that the C version of the code fails for
these cases but that the latest C Sharp does not. Therefore I have
more work to do!

I would advise you, however, to use "I think" more often as an
operator. When you make positive statements but without enough detail
for the thugs and the twerps here to know to which version you refer
to, the thugs and twerps think these are new error reports about the
old code and in general they have a distinct tendency (seen in "C: The
Complete Nonsense") to increase error counts by a couple orders of
magnitude, both because they are thugs and twerps, and also because
they can't tell the difference between a fact and a report of a fact.

Be more "verbose". I am "verbose" because I am trying not to accuse
people of falsehoods and this is even true when I am calling people
"assholes" in a legitimate self-defemse.

I appreciate your insights but I retain the right to defend myself.

>
> Also, I think it would be better to try to detect all input that can't
> be converted. =A0For example, "&" gives an error, but "1&2" does not.
>
> In order to be positive, I'll stick my neck out and post my solution.
> No one has posted the classic operator priority parsing algorithm, so
> this solution is new in the thread. =A0The code is simpler than the code
> you get from turning grammar rules directly into paring functions,
> although the benefit is certainly borderline for expressions with only
> two priorities. =A0I've added an extra, high priority, operator (^) to
> illustrate the algorithm's generality.
>
> All the work heavy is done in one function (convert_operators in the
> code below) that parses sequences of terms whose length is determined
> by the priority of the operators that are seen. =A0If these are
> determined from a run-time table, you get the advantage of being able
> to add and remove operators as well as changing the operator
> precedences as the parser runs.
>
> Most of the code is scaffolding and includes an expanding character
> buffer to hold the growing output string. =A0C99 features are used in a
> couple of places.
>
> #include <stdio.h>
> #include <stdbool.h>
> #include <stdlib.h>
> #include <string.h>
> #include <ctype.h>
>
> /*
> =A0* This type, and the two str_ functions, provide an expanding
> =A0* character buffer to take the growing output string.
> =A0*/
>
> typedef struct string string;
>
> void str_add(string *s, char c);
> const char *str_string(string *s);
>
> static bool convert_term(const char **s, string *out);
> static bool convert_operators(const char **s, int precedence, string *out=
);
> static bool convert_expression(const char **s, string *out);
>
> static char next(const char **s);
> static bool expect(const char **s, char c);
> static bool missing(const char *what, char where);
>
> /*
> =A0* The grammar is largely specified by this function that determines
> =A0* if a token (in this case a single character) is an operator and,
> =A0* if so, what precedence it has.
> =A0*/
>
> static int precedence_of(char op)
> {
> =A0 =A0 =A0static const char *op_table[] =3D { "+-", "*/", "^", NULL };
> =A0 =A0 =A0if (op !=3D '\0')
> =A0 =A0 =A0 =A0 =A0 for (int i =3D 0; op_table[i]; i++)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (strchr(op_table[i], op))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return i;
> =A0 =A0 =A0return -1; /* not a operator */
>
> }
>
> bool infix_to_postfix(const char *s, string *out)
> {
> =A0 =A0 =A0return convert_expression(&s, out) && expect(&s, '\0');
>
> }
>
> static bool convert_expression(const char **s, string *out)
> {
> =A0 =A0 =A0return convert_term(s, out) && convert_operators(s, 0, out);
>
> }
>
> static bool convert_operators(const char **s, int precedence, string *out=
)
> {
> =A0 =A0 =A0char op;
> =A0 =A0 =A0int prec, right_prec;
> =A0 =A0 =A0while ((prec =3D precedence_of(op =3D next(s))) >=3D precedenc=
e) {
> =A0 =A0 =A0 =A0 =A0 *s +=3D 1;
> =A0 =A0 =A0 =A0 =A0 if (convert_term(s, out))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0while ((right_prec =3D precedence_of(next(=
s))) > prec) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!convert_operators(s, right_p=
rec, out))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return false;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 =A0 else return false;
> =A0 =A0 =A0 =A0 =A0 str_add(out, op);
> =A0 =A0 =A0 =A0 =A0 str_add(out, ' ');
> =A0 =A0 =A0}
> =A0 =A0 =A0return true;
>
> }
>
> static bool convert_term(const char **s, string *out)
> {
> =A0 =A0 =A0unsigned char c =3D next(s);
> =A0 =A0 =A0if (isalpha(c)) {
> =A0 =A0 =A0 =A0 =A0 str_add(out, c);
> =A0 =A0 =A0 =A0 =A0 str_add(out, ' ');
> =A0 =A0 =A0 =A0 =A0 *s +=3D 1;
> =A0 =A0 =A0 =A0 =A0 return true;
> =A0 =A0 =A0}
> =A0 =A0 =A0else if (isdigit(c)) {
> =A0 =A0 =A0 =A0 =A0 while (isdigit((unsigned char)**s))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0str_add(out, *(*s)++);
> =A0 =A0 =A0 =A0 =A0 str_add(out, ' ');
> =A0 =A0 =A0 =A0 =A0 return true;
> =A0 =A0 =A0}
> =A0 =A0 =A0else if (c =3D=3D '(') {
> =A0 =A0 =A0 =A0 =A0 *s +=3D 1;
> =A0 =A0 =A0 =A0 =A0 return convert_expression(s, out) && expect(s, ')');
> =A0 =A0 =A0}
> =A0 =A0 =A0else return missing("Term", c);
>
> }
>
> static char next(const char **s)
> {
> =A0 =A0 =A0while (isspace((unsigned char)**s)) *s +=3D 1;
> =A0 =A0 =A0return **s;
>
> }
>
> static bool missing(const char *what, char where)
> {
> =A0 =A0 =A0fprintf(stderr, "%s expected where %s found.\n", what,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0where ? (char []){where, 0} : "end of input");
> =A0 =A0 =A0return false;
>
> }
>
> static bool expect(const char **s, char c)
> {
> =A0 =A0 =A0if (next(s) !=3D c)
> =A0 =A0 =A0 =A0 =A0 return missing(c ? (char []){c, 0} : "end of input", =
**s);
> =A0 =A0 =A0*s +=3D 1;
> =A0 =A0 =A0return true;
>
> }
>
> /*
> =A0* =A0An implementation of an expanding character buffer.
> =A0*/
>
> struct string {
> =A0 =A0 =A0size_t capacity, size;
> =A0 =A0 =A0char *string;
>
> };
>
> void str_add(string *s, char c)
> {
> =A0 =A0 =A0if (s->size >=3D s->capacity) {
> =A0 =A0 =A0 =A0 =A0 size_t new_cap =3D s->capacity * 3 / 2 + 8;
> =A0 =A0 =A0 =A0 =A0 char *new_s =3D realloc(s->string, new_cap);
> =A0 =A0 =A0 =A0 =A0 if (!new_s) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fprintf(stderr, "String add: out of memory=
\n");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0exit(EXIT_FAILURE);
> =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 s->string =3D new_s;
> =A0 =A0 =A0 =A0 =A0 s->capacity =3D new_cap;
> =A0 =A0 =A0}
> =A0 =A0 =A0s->string[s->size++] =3D c;
>
> }
>
> const char *str_string(string *s)
> {
> =A0 =A0 =A0str_add(s, '\0');
> =A0 =A0 =A0return s->string;
>
> }
>
> int main(int argc, char *argv[])
> {
> =A0 =A0 =A0bool result =3D true;
> =A0 =A0 =A0while (--argc > 0) {
> =A0 =A0 =A0 =A0 =A0 string postfix =3D {0};
> =A0 =A0 =A0 =A0 =A0 if (infix_to_postfix(*++argv, &postfix))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("%s\n", str_string(&postfix));
> =A0 =A0 =A0 =A0 =A0 else result =3D false;
> =A0 =A0 =A0 =A0 =A0 free(postfix.string);
> =A0 =A0 =A0}
> =A0 =A0 =A0return result ? EXIT_SUCCESS : EXIT_FAILURE;
>
> }
>
> --
> Ben.

0
spinoza1111 (3246)
11/3/2009 7:17:51 AM
On Nov 3, 8:05=A0am, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> spinoza1111<spinoza1...@yahoo.com> writes:
> > This post contains the promised C code version of the infix to Polish
> > notation convertor.
>
> Seebs as commented on the code in detail, so I'll just add that you
> need more work on some error cases. =A0Despite a lot of unnecessary
> counting of parentheses, cases like "1)" and "(((0))))" are silently
> ignored.
>
> Also, I think it would be better to try to detect all input that can't
> be converted. =A0For example, "&" gives an error, but "1&2" does not.
>
> In order to be positive, I'll stick my neck out and post my solution.
> No one has posted the classic operator priority parsing algorithm, so
> this solution is new in the thread. =A0The code is simpler than the code
> you get from turning grammar rules directly into paring functions,
> although the benefit is certainly borderline for expressions with only
> two priorities. =A0I've added an extra, high priority, operator (^) to
> illustrate the algorithm's generality.
>
> All the work heavy is done in one function (convert_operators in the
> code below) that parses sequences of terms whose length is determined
> by the priority of the operators that are seen. =A0If these are
> determined from a run-time table, you get the advantage of being able
> to add and remove operators as well as changing the operator
> precedences as the parser runs.
>
> Most of the code is scaffolding and includes an expanding character
> buffer to hold the growing output string. =A0C99 features are used in a
> couple of places.
>
> #include <stdio.h>
> #include <stdbool.h>
> #include <stdlib.h>
> #include <string.h>
> #include <ctype.h>
>
> /*
> =A0* This type, and the two str_ functions, provide an expanding
> =A0* character buffer to take the growing output string.
> =A0*/
>
> typedef struct string string;
>
> void str_add(string *s, char c);
> const char *str_string(string *s);
>
> static bool convert_term(const char **s, string *out);
> static bool convert_operators(const char **s, int precedence, string *out=
);
> static bool convert_expression(const char **s, string *out);
>
> static char next(const char **s);
> static bool expect(const char **s, char c);
> static bool missing(const char *what, char where);
>
> /*
> =A0* The grammar is largely specified by this function that determines
> =A0* if a token (in this case a single character) is an operator and,
> =A0* if so, what precedence it has.
> =A0*/
>
> static int precedence_of(char op)
> {
> =A0 =A0 =A0static const char *op_table[] =3D { "+-", "*/", "^", NULL };
> =A0 =A0 =A0if (op !=3D '\0')
> =A0 =A0 =A0 =A0 =A0 for (int i =3D 0; op_table[i]; i++)
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0if (strchr(op_table[i], op))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return i;
> =A0 =A0 =A0return -1; /* not a operator */
>
> }
>
> bool infix_to_postfix(const char *s, string *out)
> {
> =A0 =A0 =A0return convert_expression(&s, out) && expect(&s, '\0');
>
> }
>
> static bool convert_expression(const char **s, string *out)
> {
> =A0 =A0 =A0return convert_term(s, out) && convert_operators(s, 0, out);
>
> }
>
> static bool convert_operators(const char **s, int precedence, string *out=
)
> {
> =A0 =A0 =A0char op;
> =A0 =A0 =A0int prec, right_prec;
> =A0 =A0 =A0while ((prec =3D precedence_of(op =3D next(s))) >=3D precedenc=
e) {
> =A0 =A0 =A0 =A0 =A0 *s +=3D 1;
> =A0 =A0 =A0 =A0 =A0 if (convert_term(s, out))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0while ((right_prec =3D precedence_of(next(=
s))) > prec) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 if (!convert_operators(s, right_p=
rec, out))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0return false;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0}
> =A0 =A0 =A0 =A0 =A0 else return false;
> =A0 =A0 =A0 =A0 =A0 str_add(out, op);
> =A0 =A0 =A0 =A0 =A0 str_add(out, ' ');
> =A0 =A0 =A0}
> =A0 =A0 =A0return true;
>
> }
>
> static bool convert_term(const char **s, string *out)
> {
> =A0 =A0 =A0unsigned char c =3D next(s);
> =A0 =A0 =A0if (isalpha(c)) {
> =A0 =A0 =A0 =A0 =A0 str_add(out, c);
> =A0 =A0 =A0 =A0 =A0 str_add(out, ' ');
> =A0 =A0 =A0 =A0 =A0 *s +=3D 1;
> =A0 =A0 =A0 =A0 =A0 return true;
> =A0 =A0 =A0}
> =A0 =A0 =A0else if (isdigit(c)) {
> =A0 =A0 =A0 =A0 =A0 while (isdigit((unsigned char)**s))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0str_add(out, *(*s)++);
> =A0 =A0 =A0 =A0 =A0 str_add(out, ' ');
> =A0 =A0 =A0 =A0 =A0 return true;
> =A0 =A0 =A0}
> =A0 =A0 =A0else if (c =3D=3D '(') {
> =A0 =A0 =A0 =A0 =A0 *s +=3D 1;
> =A0 =A0 =A0 =A0 =A0 return convert_expression(s, out) && expect(s, ')');
> =A0 =A0 =A0}
> =A0 =A0 =A0else return missing("Term", c);
>
> }
>
> static char next(const char **s)
> {
> =A0 =A0 =A0while (isspace((unsigned char)**s)) *s +=3D 1;
> =A0 =A0 =A0return **s;
>
> }
>
> static bool missing(const char *what, char where)
> {
> =A0 =A0 =A0fprintf(stderr, "%s expected where %s found.\n", what,
> =A0 =A0 =A0 =A0 =A0 =A0 =A0where ? (char []){where, 0} : "end of input");
> =A0 =A0 =A0return false;
>
> }
>
> static bool expect(const char **s, char c)
> {
> =A0 =A0 =A0if (next(s) !=3D c)
> =A0 =A0 =A0 =A0 =A0 return missing(c ? (char []){c, 0} : "end of input", =
**s);
> =A0 =A0 =A0*s +=3D 1;
> =A0 =A0 =A0return true;
>
> }
>
> /*
> =A0* =A0An implementation of an expanding character buffer.
> =A0*/
>
> struct string {
> =A0 =A0 =A0size_t capacity, size;
> =A0 =A0 =A0char *string;
>
> };
>
> void str_add(string *s, char c)
> {
> =A0 =A0 =A0if (s->size >=3D s->capacity) {
> =A0 =A0 =A0 =A0 =A0 size_t new_cap =3D s->capacity * 3 / 2 + 8;
> =A0 =A0 =A0 =A0 =A0 char *new_s =3D realloc(s->string, new_cap);
> =A0 =A0 =A0 =A0 =A0 if (!new_s) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0fprintf(stderr, "String add: out of memory=
\n");
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0exit(EXIT_FAILURE);
> =A0 =A0 =A0 =A0 =A0 }
> =A0 =A0 =A0 =A0 =A0 s->string =3D new_s;
> =A0 =A0 =A0 =A0 =A0 s->capacity =3D new_cap;
> =A0 =A0 =A0}
> =A0 =A0 =A0s->string[s->size++] =3D c;
>
> }
>
> const char *str_string(string *s)
> {
> =A0 =A0 =A0str_add(s, '\0');
> =A0 =A0 =A0return s->string;
>
> }
>
> int main(int argc, char *argv[])
> {
> =A0 =A0 =A0bool result =3D true;
> =A0 =A0 =A0while (--argc > 0) {
> =A0 =A0 =A0 =A0 =A0 string postfix =3D {0};
> =A0 =A0 =A0 =A0 =A0 if (infix_to_postfix(*++argv, &postfix))
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0printf("%s\n", str_string(&postfix));
> =A0 =A0 =A0 =A0 =A0 else result =3D false;
> =A0 =A0 =A0 =A0 =A0 free(postfix.string);
> =A0 =A0 =A0}
> =A0 =A0 =A0return result ? EXIT_SUCCESS : EXIT_FAILURE;
>
> }
>
> --
> Ben.

Looks great. Thank you. I shall incorporate it into a comparative
study with my C Sharp code, my C code, Gene's and now yours. I want to
regression and time test all the code so far. The final result will go
here and on my wordpress blog and you shall be credited. If you would
prefer to be anonymous as in the past please let me know here or by
email.

But the more I relearn about C from experts like you, the more I
wonder why this language is still in use. Perhaps it will be
eradicated in 2038 as much old Cobol was eradicated to prevent Y2K,
since C shall blow us all to kingdom come when its timers overflow in
that year. I shall work out and not drink or smoke to see that happy
day.
0
spinoza1111 (3246)
11/3/2009 7:21:48 AM
spinoza1111 <spinoza1111@yahoo.com> writes:

>But the more I relearn about C from experts like you, the more I
>wonder why this language is still in use. Perhaps it will be
>eradicated in 2038 as much old Cobol was eradicated to prevent Y2K,
>since C shall blow us all to kingdom come when its timers overflow in
>that year. I shall work out and not drink or smoke to see that happy
>day.

Which part of the C standard do you believe links C to the year 2038?

-- 
Chris.
0
chris16 (579)
11/3/2009 7:32:20 AM
On 2009-11-03, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>> I'm a little put off by the magic of convert_operators apparently implying
>> converting the following term.

> Is there a neat way to write it in C that is clearer?

I can't think of one.

> I have a background in teaching and have often wrestled with getting
> fragments of code to fit on one OHP slide.  As a result, I have an
> unnatural urge to bracket minimally, but I agree that it is not
> obviously the best way to do things.

Ahh, that makes sense.

> Yup, but if I commented it, I'd have to justify the 3/2 factor!  I do
> that for hysterical raisins, more than anything else.  If I thought
> about it, I'd just double the capacity.  The +8 (as I am sure you
> spotted) is just a hack to avoid having to treat the initial zero as a
> special case.  The "code for clarity" version is probably:

>   size_t new_cap = s->capacity ? 2 * s->capacity : 8;

Actually, I've found 3/2 to be a better choice -- it wastes a lot less
space in most cases.  I hadn't thought about the 0 case, just the 1 case
(and the general rule that it's going to be called very often for the
first few bytes).

I once did some kind of messing with an algorithm like this, I think it
was for the buffers used in my "unsort" utility, and ended up on 3/2.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/3/2009 7:41:20 AM
On 2009-11-03, Richard Heathfield <rjh@see.sig.invalid> wrote:
> Chris Torek (wherever he's got to)

He's been too busy to post to Usenet.  (He's one of my coworkers, and I
actually did remember to pass on that people in CLC remember him.)

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/3/2009 7:48:32 AM
On Nov 3, 11:58=A0am, Gene <gene.ress...@gmail.com> wrote:
> On Nov 2, 9:33=A0pm,spinoza1111<spinoza1...@yahoo.com> wrote:
>
>
>
>
>
> > On Nov 3, 1:36=A0am, Gene <gene.ress...@gmail.com> wrote:
>
> > > On Nov 2, 10:48=A0am,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > > > On Nov 2, 10:10=A0pm, Gene <gene.ress...@gmail.com> wrote:
>
> > > > > On Oct 25, 11:33=A0pm, Tameem <etam...@gmail.com> wrote:
>
> > > > > > i have a string as (a+b)+8-(c/d) in Infix form.
>
> > > > > > how can i convert it to postfix form using C language,,,????
>
> > > > > I suppose that if this is homework, the due date has passed.
>
> > > > > // Convert ;-separated infix expressions on stdin to postfix on
> > > > > stdout.
> > > > > #include <stdio.h>
> > > > > #include <stdlib.h>
> > > > > #include <string.h>
> > > > > #include <stdarg.h>
>
> > > > > // error handler
>
> > > > > void die(char *msg)
> > > > > {
> > > > > =A0 fprintf(stderr, "\ndie: %s\n", msg);
> > > > > =A0 exit(1);
>
> > > > > }
>
> > > > > // scanner
>
> > > > > int lookahead;
>
> > > > > int peek() { return lookahead; }
>
> > > > > int peek_is(char *set)
> > > > > {
> > > > > =A0 return strchr(set, peek()) !=3D NULL;
>
> > > > > }
>
> > > > > void advance(void)
> > > > > {
> > > > > =A0 do lookahead =3D getchar(); while (isspace(lookahead));
>
> > > > > }
>
> > > > > // parser for gramar:
> > > > > // expr -> term { [+-] term }
> > > > > // term -> factor { [*/] factor }
> > > > > // factor -> ALNUM | "(" expr ")"
>
> > > > > void term(void);
> > > > > void factor(void);
>
> > > > > void expr(void)
> > > > > {
> > > > > =A0 term();
> > > > > =A0 while (peek_is("+-")) {
> > > > > =A0 =A0 int op =3D peek();
> > > > > =A0 =A0 advance();
> > > > > =A0 =A0 term();
> > > > > =A0 =A0 printf("%c", op);
> > > > > =A0 }
>
> > > > > }
>
> > > > > void term(void)
> > > > > {
> > > > > =A0 factor();
> > > > > =A0 while (peek_is("*/")) {
> > > > > =A0 =A0 int op =3D peek();
> > > > > =A0 =A0 advance();
> > > > > =A0 =A0 factor();
> > > > > =A0 =A0 printf("%c", op);
> > > > > =A0 }
>
> > > > > }
>
> > > > > void factor(void)
> > > > > {
> > > > > =A0 if (isalnum(peek())) {
> > > > > =A0 =A0 int literal =3D peek();
> > > > > =A0 =A0 advance();
> > > > > =A0 =A0 printf("%c", literal);
> > > > > =A0 }
> > > > > =A0 else if (peek() =3D=3D '(') {
> > > > > =A0 =A0 advance();
> > > > > =A0 =A0 expr();
> > > > > =A0 =A0 if (!peek_is(")")) die("expected )");
> > > > > =A0 =A0 advance();
> > > > > =A0 }
> > > > > =A0 else
> > > > > =A0 =A0 die("expected factor");
>
> > > > > }
>
> > > > > // user interface
>
> > > > > int main(void)
> > > > > {
> > > > > =A0 advance();
> > > > > =A0 do {
> > > > > =A0 =A0 expr();
> > > > > =A0 =A0 if (!peek_is(";")) die("expected ;");
> > > > > =A0 =A0 printf("\n");
> > > > > =A0 =A0 advance();
> > > > > =A0 } while (peek() !=3D EOF);
> > > > > =A0 return 0;
>
> > > > > }- Hide quoted text -
>
> > > > > - Show quoted text -
>
> > > > Thanks for this. Looks like you stole my approach, but I find that
> > > > most gratifying if true, and an indication that "great minds think
> > > > alike" if not. Your contribution at a minimum is to show just how
> > > > gnomic and terse one can be in C. It would not be appropriate to
> > > > credit me since it is a common and solid algorithm that has been
> > > > around for years.
>
> > > > Hope you don't mind, but I'm going to copy this code and incorporat=
e
> > > > it in what will not be a three way test: of my C Sharp version, my =
C
> > > > version and your gnomic C. I want to add more testing (using a rand=
om
> > > > generator in C Sharp), a GUI and timing comparisions and shall repo=
rt
> > > > back.- Hide quoted text -
>
> > > This doesn't qualify as anything like theft or great thinking. For
>
> > It's better than anything Heathfield, Thompson or Seebach could do.
> > But I think you messed up the grammar...but not the code.
>
> > expr -> term { [+-] term }
>
> > doesn't parse 1+1+1.
>
> > > fun, I wrote the code in about 5 minutes after the OP posted (based o=
nhttp://groups.google.com/group/comp.lang.c/msg/fe772c9d6a28fdc4), but
> > > refrained from posting it because it was probably homework for the
> > > OP. =A0This is a standard example or homework assignment for just abo=
ut
> > > any undergrad course that covers recursive descent parsing. =A0The
> > > gramamr with minor variations is in at least a dozen complier design
> > > textbooks including ASU. Usually it's given in left-recursive form,
> > > and then the author or student go through the L-rec removal, left-
> > > factoring, and BNF conversion. =A0RPN generation is a trivial example=
 of
> > > attribute evaluation.- Hide quoted text -
>
> The curly braces are BNF for zero or more repeats. =A0This translates to
> the while loop. =A0I can't see an error.- Hide quoted text -

OK, I can deal with that. Thanks for the clarification. I don't recall
that notation being used by my teacher of compiler design in grad
school but it's been some time.
>
> - Show quoted text -

0
spinoza1111 (3246)
11/3/2009 7:52:18 AM
On 2009-11-03, Chris McDonald <chris@csse.uwa.edu.au> wrote:
> Which part of the C standard do you believe links C to the year 2038?

A lot of people are not aware that time_t is not required to be only 32
bits.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/3/2009 8:03:43 AM
Seebs <usenet-nospam@seebs.net> writes:

>On 2009-11-03, Chris McDonald <chris@csse.uwa.edu.au> wrote:
>> Which part of the C standard do you believe links C to the year 2038?

>A lot of people are not aware that time_t is not required to be only 32
>bits.

Yes, Ben Pfaff helpfully explained that to me a few months ago,
but I'm waiting for Spinny to either state that Ben was wrong,
or that any intelligent programmer would expect time_t to be 32 bits.

-- 
Chris.
0
chris16 (579)
11/3/2009 8:12:26 AM
On 2 Nov, 14:54, Tim Streater <timstrea...@waitrose.com> wrote:

<snip>

> Watching Spinny's train of "logic", I'm reminded of the Soviets'
> constant denigration of the West as "warmongers", the rationale for
> which which went something like as follows:
>
> 1) We are in conflict with you
> 2) If you were to agree with our point of view, the conflict would cease
> 3) Since you choose not to take an action which would remove the
> conflict, you are actively seeking to prolong the conflict
> 4) In actively seeking to prolong the conflict, you are therefore a
> warmonger
>
> There must be a word which describes this sort of thought process.

invented
0
11/3/2009 8:14:18 AM
On 2 Nov, 21:56, Tim Streater <timstrea...@waitrose.com> wrote:
> In article <hcnkt1$26...@news.xmission.com>,

> > You were classed as a "reg wannabee". =A0Sit up straight in your chair,
> > and pay attention!
>
> Which part of "have no interest in being one" do you not understand?

he's trolling (in the classic sense)

0
11/3/2009 8:23:32 AM
On 3 Nov, 00:38, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-11-02, Kenny McCormack <gaze...@shell.xmission.com> wrote:

> > The regs (and the wannabees of various stripes) lie all the time.
>
> As a general rule, your view of other people is informed primarily
> by your experience of yourself.
>
> Most people don't lie very often. =A0The exceptions, though, have the
> interesting trait that they think everyone else does it too -- especially
> people they dislike.

I've met a couple of "pathological liars" in my time. People who
constantly re-invent their biographical details to such an extent that
not only cridibility but space-time (in the sense that you can't have
three full-time careers *and* beat heroin simultaneously) itself is
strained to breaking point. They can be amusing once you realise what
they are doing. But I hadn't noticed any overt evidence that they
thought other people lied. Maybe they just took it as axiomatic, but
they gave no obvious sign.


<snip>
0
11/3/2009 8:31:23 AM
On 2 Nov, 15:45, Richard Heathfield <r...@see.sig.invalid> wrote:
> <fe798d09-500d-4fc1-ba97-b4d827b92...@k13g2000prh.googlegroups.com>,
> spinoza1111 wrote:

> > This post contains the promised C code version of the infix to
> > Polish notation convertor. When run from the command line it should
> > execute all cases used to test the C Sharp version correctly. Its
> > string handling is simpler owing to the limitations of C.
>
> > This code unless it is seriously fucked up demonstrates the
> > practicality of using a formal language based approach to infix to
> > Polish notation. It's also part of my project of relearning C.

> > #include <stdio.H>
> foo.c:1: stdio.H: No such file or directory

> foo.c: In function `stringAppendChar':
> foo.c:37: warning: passing arg 1 of `errorHandler' discards qualifiers
> from pointer target type

> foo.c:54: warning: passing arg 2 of `stringAppendChar' with different
> width due to prototype

> foo.c:143: warning: no previous prototype for `addFactor'

> foo.c:209: warning: no previous prototype for `infix2Polish'

> foo.c:221: warning: return discards qualifiers from pointer target
> type

> foo.c:227: warning: function declaration isn't a prototype
> foo.c: In function `tester':

> foo.c: In function `main':
> foo.c:263: warning: `return' with no value, in function returning
> non-void

but if you remove the repeats that's about six problems. Mismatched
prototypes would worry me.


> foo.c:260: warning: unused parameter `intArgCount'
> foo.c:260: warning: unused parameter `strArgs'

I tend to label these "picky compiler"
0
11/3/2009 8:38:55 AM
On 2009-11-03, Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
> I've met a couple of "pathological liars" in my time. People who
> constantly re-invent their biographical details to such an extent that
> not only cridibility but space-time (in the sense that you can't have
> three full-time careers *and* beat heroin simultaneously) itself is
> strained to breaking point. They can be amusing once you realise what
> they are doing. But I hadn't noticed any overt evidence that they
> thought other people lied. Maybe they just took it as axiomatic, but
> they gave no obvious sign.

The full-on pathological liars are often much less conscious of it -- and
some actually believe all those mutually exclusive things they claim.  It's
the people who are lying to gain advantage, not the people who are lying
for no particular reason, who infer that everyone else lies to gain
advantage.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/3/2009 8:39:12 AM
In 
<d4057a44-f753-40b0-adf7-4190692d9a09@m38g2000yqd.googlegroups.com>, 
Nick Keighley wrote:

<snip>
 
> but if you remove the repeats that's about six problems.

Yeah. If ever he gets around to fixing them in my lifetime, I'll look 
at the resulting code.

>> foo.c:260: warning: unused parameter `intArgCount'
>> foo.c:260: warning: unused parameter `strArgs'
> 
> I tend to label these "picky compiler"

Picky compilers are extremely useful for people who want to write good 
code.

-- 
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
0
rjh (10791)
11/3/2009 8:51:15 AM
On 2009-11-03, Richard Heathfield <rjh@see.sig.invalid> wrote:
> Yeah. If ever he gets around to fixing them in my lifetime, I'll look 
> at the resulting code.

You missed some pretty fun stuff in there, though.

I think I'm actually willing to half-concede one of his points:  For him,
it is probably true that C is an inherently unsafe language.  Note the
qualifier, though.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/3/2009 8:54:22 AM
On 2 Nov, 17:36, Gene <gene.ress...@gmail.com> wrote:
> On Nov 2, 10:48=A0am, spinoza1111 <spinoza1...@yahoo.com> wrote:
> > On Nov 2, 10:10=A0pm, Gene <gene.ress...@gmail.com> wrote:
> > > On Oct 25, 11:33=A0pm, Tameem <etam...@gmail.com> wrote:


> > > > i have a string as (a+b)+8-(c/d) in Infix form.
>
> > > > how can i convert it to postfix form using C language,,,????
>
> > > I suppose that if this is homework, the due date has passed.

<snip neat code>

> > Thanks for this. Looks like you stole my approach,

good grief

> > but I find that
> > most gratifying if true, and an indication that "great minds think
> > alike" if not. Your contribution at a minimum is to show just how
> > gnomic and terse one can be in C.

looks pretty straightforward C to me. It's clearer than yours.


> > It would not be appropriate to
> > credit me since it is a common and solid algorithm that has been
> > around for years.

riight

> > Hope you don't mind, but I'm going to copy this code and incorporate
> > it in what will not be a three way test: of my C Sharp version, my C
> > version and your gnomic C. I want to add more testing (using a random
> > generator in C Sharp), a GUI and timing comparisions and shall report
> > back.

one idea would be to make you tester() function silent. Only print
something if the test fails. This will also mean your timeing tests
are testing the algorithm rather than the i/o.


> This doesn't qualify as anything like theft or great thinking. For
> fun, I wrote the code in about 5 minutes after the OP posted (based onhtt=
p://groups.google.com/group/comp.lang.c/msg/fe772c9d6a28fdc4), but
> refrained from posting it because it was probably homework for the
> OP. =A0This is a standard example or homework assignment for just about
> any undergrad course that covers recursive descent parsing.

I don't see the words "recursive descent parsing" in the OP

>=A0The
> gramamr with minor variations is in at least a dozen complier design
> textbooks including ASU. Usually it's given in left-recursive form,
> and then the author or student go through the L-rec removal, left-
> factoring, and BNF conversion. =A0RPN generation is a trivial example of
> attribute evaluation.
0
11/3/2009 9:24:18 AM
On 3 Nov, 07:52, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Nov 3, 11:58=A0am, Gene <gene.ress...@gmail.com> wrote:
> > On Nov 2, 9:33=A0pm,spinoza1111<spinoza1...@yahoo.com> wrote:

> > > [...] I think you messed up the grammar [...]
>
> > > expr -> term { [+-] term }
>
> > > doesn't parse 1+1+1.

<snip>

> > The curly braces are BNF for zero or more repeats. =A0This translates t=
o
> > the while loop. =A0I can't see an error.
>
> OK, I can deal with that. Thanks for the clarification. I don't recall
> that notation being used by my teacher of compiler design in grad
> school but it's been some time.

to pick a nit it's not BNF, that is the original notation defined by
Backus and Naur, but Extended BNF (EBNF). It's quite common. The C
standard uses it.

0
11/3/2009 9:28:30 AM
In <slrnhevs14.4br.usenet-nospam@guild.seebs.net>, Seebs wrote:

> On 2009-11-03, Richard Heathfield <rjh@see.sig.invalid> wrote:
>> Yeah. If ever he gets around to fixing them in my lifetime, I'll
>> look at the resulting code.
> 
> You missed some pretty fun stuff in there, though.

Yes, but then there always is. I've found that it saves a lot of time 
not to bother too much with his code until he gets it to a point 
where it compiles reasonably cleanly - i.e. rarely.

> I think I'm actually willing to half-concede one of his points:  For
> him, it is probably true that C is an inherently unsafe language.
> Note the qualifier, though.

True enough. Although you have no particular reason to be aware of it, 
I conceded that point a very long time ago.

-- 
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
0
rjh (10791)
11/3/2009 10:24:10 AM
spinoza1111 <spinoza1111@yahoo.com> writes:

> On Nov 3, 12:13 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
>> spinoza1111<spinoza1...@yahoo.com> writes:
>>
>> <snip>
>>
>> > But I think you messed up the grammar...but not the code.
>>
>> > expr -> term { [+-] term }
>>
>> > doesn't parse 1+1+1.
>>
>> The {} is a very common notation.  I agree that [+-] is not usual, but were
>> you at all puzzled by what the notation meant?  It is obviously
>> borrowed from regular expressions.
>
> OK, that's correct: [+-] is "the set of characters including plus and
> minus" where one character is chosen from the set. But I shouldn't
> have to do the work of expressing things clearly on your behalf in
> English.
>
> Nor should regular expression notation be mixed into BNF unless
> absolutely necessary.

Most extended grammar notations use very similar nation to that used
in regular expressions.  I don't see a problem with that.

> But in neither notation do curley braces imply iteration and as far as
> I can see you need iteration to parse 1+1+1. What am I missing, dear
> Ben?

That {} denotes repetition in all the forms of EBNF that I have seen.

>> Wirth would have written:
>>
>>   expr = term { ("+"|"-") term } .
>>
>> and in plain EBNF one would write
>>
>>   expr = term | { "+" , term } | { "-" , term } ;
>>
>> both of which are a bit clumsy.  I found Gene's shorthand quite clear.
>
> They both look wrong (and note that unlike some of the thugs and
> twerps here I don't infer your global ignorance). Period ordinarily
> means end of string (which is needed as I have said when you do not
> lookahead to balance parentheses)....not iteration.

In Wirth's version of EBNF (note the E) . ends the production.  ()s
indicate grouping and | alternation (as in most regular expression
syntax) and {} repetition zero or more times.

> The second is in particular absurd. If by | you mean BNF or, then
> you're saying that an expr may start with a plus sign. If you add
> unary minus it may but I do not believe this was your intent.

No, I missed the term that starts each alternation:

  expr = term | term { "+" , term } | term { "-" , term } ;

Where () can't be used to group and alternation, the alternatives get
more complex.  The point being that in both Wirth's EBNF and in plain
EBNF {} means repetition.

> I think
> you either have a private BNF notation, Bacarisse Normal Form, or you
> don't know how to use BNF at all.
>
> Here is the correct BNF as far as I can tell:
>
> expr := addFactor
> expr := addFactor ( [+-] addFactor ) *

You keep saying BNF but all these are extended notations.  BNF used
<>s and ::= and has no shorthand for optional or repeated elements.

> As a favor to you I use the square bracket set notation and instead of
> square brackets for optional sequence I've split the production into
> two parts, using round parentheses to group and asterisk to iterate.

Your notation -- specifically adding * after an optional item -- is
not common.  I've not seen it in any text.  Some EBNFs do use * but as
a operator applied to any element.  Applying it to something optional
is redundant.

<snip>
-- 
Ben.
0
ben.usenet (6790)
11/3/2009 11:56:04 AM
Seebs <usenet-nospam@seebs.net> writes:

> On 2009-11-03, Chris McDonald <chris@csse.uwa.edu.au> wrote:
>> Which part of the C standard do you believe links C to the year 2038?
>
> A lot of people are not aware that time_t is not required to be only 32
> bits.

No, or that time_t does not have to be an integer; does not have to
count seconds; and does not have to use a fixed base time of 1st Jan
1970.

Of course, given common usage and other standards like POSIX, a wider
integer time_t is the simplest solution:

  $ cat time.c
  #include <stdio.h>
  #include <time.h>
  #include <limits.h>
   
  int main(void)
  {
       printf("Clock good for another %.0f million years\n",
              difftime(LLONG_MAX, time(0)) / (365.0 * 1e6 * 24 * 60 * 60));
       return 0;
  }
  $ ./time
  Clock good for another 292471 million years

-- 
Ben.
0
ben.usenet (6790)
11/3/2009 12:35:47 PM
On Nov 3, 7:56=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> spinoza1111<spinoza1...@yahoo.com> writes:
> > On Nov 3, 12:13=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >>spinoza1111<spinoza1...@yahoo.com> writes:
>
> >> <snip>
>
> >> > But I think you messed up the grammar...but not the code.
>
> >> > expr -> term { [+-] term }
>
> >> > doesn't parse 1+1+1.
>
> >> The {} is a very common notation. =A0I agree that [+-] is not usual, b=
ut were
> >> you at all puzzled by what the notation meant? =A0It is obviously
> >> borrowed from regular expressions.
>
> > OK, that's correct: [+-] is "the set of characters including plus and
> > minus" where one character is chosen from the set. But I shouldn't
> > have to do the work of expressing things clearly on your behalf in
> > English.
>
> > Nor should regular expression notation be mixed into BNF unless
> > absolutely necessary.
>
> Most extended grammar notations use very similar nation to that used
> in regular expressions. =A0I don't see a problem with that.
>
> > But in neither notation do curley braces imply iteration and as far as
> > I can see you need iteration to parse 1+1+1. What am I missing, dear
> > Ben?
>
> That {} denotes repetition in all the forms of EBNF that I have seen.
>
> >> Wirth would have written:
>
> >> =A0 expr =3D term { ("+"|"-") term } .
>
> >> and in plain EBNF one would write
>
> >> =A0 expr =3D term | { "+" , term } | { "-" , term } ;
>
> >> both of which are a bit clumsy. =A0I found Gene's shorthand quite clea=
r.
>
> > They both look wrong (and note that unlike some of the thugs and
> > twerps here I don't infer your global ignorance). Period ordinarily
> > means end of string (which is needed as I have said when you do not
> > lookahead to balance parentheses)....not iteration.
>
> In Wirth's version of EBNF (note the E) . ends the production. =A0()s
> indicate grouping and | alternation (as in most regular expression
> syntax) and {} repetition zero or more times.
>
> > The second is in particular absurd. If by | you mean BNF or, then
> > you're saying that an expr may start with a plus sign. If you add
> > unary minus it may but I do not believe this was your intent.
>
> No, I missed the term that starts each alternation:
>
> =A0 expr =3D term | term { "+" , term } | term { "-" , term } ;
>
> Where () can't be used to group and alternation, the alternatives get
> more complex. =A0The point being that in both Wirth's EBNF and in plain
> EBNF {} means repetition.
>
> > I think
> > you either have a private BNF notation, Bacarisse Normal Form, or you
> > don't know how to use BNF at all.
>
> > Here is the correct BNF as far as I can tell:
>
> > expr :=3D addFactor
> > expr :=3D addFactor ( [+-] addFactor ) *
>
> You keep saying BNF but all these are extended notations. =A0BNF used
> <>s and ::=3D and has no shorthand for optional or repeated elements.
>
> > As a favor to you I use the square bracket set notation and instead of
> > square brackets for optional sequence I've split the production into
> > two parts, using round parentheses to group and asterisk to iterate.
>
> Your notation -- specifically adding * after an optional item -- is
> not common. =A0I've not seen it in any text. =A0Some EBNFs do use * but a=
s
> a operator applied to any element. =A0Applying it to something optional
> is redundant.
>
> <snip>
> --
> Ben.- Hide quoted text -
>
> - Show quoted text -

Here is the latest C version, based on my grammar. The issues you
raised have been fixed, and documentation has been added. The code
list is followed by the output.

The code list tabbing may be incorrect.


// ***************************************************************
// *                                                             *
// * infix2PolishC   Infix to Polish notation using a grammar    *
// *                                                             *
// *                                                             *
// * This application converts infix to Polish notation using a  *
// * simple grammar and two different implementations. It also   *
// * contains testing and timing facilities. For more            *
// * information, see the readme.TXT file in this project.       *
// *                                                             *
// *                                                             *
// * C H A N G E   R E C O R D --------------------------------- *
// *   DATE     PROGRAMMER     DESCRIPTION OF CHANGE             *
// * --------   ---------      --------------------------------- *
// * 11 01 09   Nilges         Version 1                         *
// *                                                             *
// * 11 03 09   Nilges         Version 2                         *
// *            ANON           1.  Commenting added    DONE      *
// *                           2.  Routine index added with      *
// *                               forward definitions   DONE    *
// *                           3.  Expected/actual cleanup DONE  *
// *                           4.  Bug? Seems to convert Polish  *
// *                               expression to value of first  *
// *                               token without complaint       *
// *                               FIXED                         *
// *                           5.  Minor bug: extra spaces in    *
// *                               polish expression FIXED       *
// *                           6.  Bugs as found by anon         *
// *                               8.1 1)  FIXED                 *
// *                               8.2 (((1)))) FIXED            *
// *                           7.  Predetermine malloc using     *
// *                               number of symbols other than  *
// *                               parentheses and white space   *
// *                                                             *
// * I S S U E S ----------------------------------------------- *
// *   DATE     POSTER         DESCRIPTION AND RESOLUTION        *
// * --------   ---------      --------------------------------- *
// * 11 03 09   Nilges         Version 3 plan                    *
// *                           1.  Random expressions            *
// *                           2.  Integrate in GUI with C sharp,*
// *                               versions from Gene & anon     *
// *                           3.  Predetermine malloc using     *
// *                               number of symbols other than  *
// *                               parentheses and white space   *
// *                                                             *
// ***************************************************************

#include <stdio.H>
#include <stdlib.H>

// ***** Constants ***********************************************
#define MAX_POLISH_LENGTH 100
#define ABOUT_INFO \
"This application converts infix to Polish notation using a simple
grammar and two different implementations. It also contains testing
and timing facilities."

// ***** Macros **************************************************

// --- Pass over white space
#define SKIP_WHITE_SPACE(s, i, e) \
	{ for(; (i) <=3D (e) && (s)[(i)] =3D=3D ' '; (i)++ ); }

// ***** Function index ******************************************
#define ADDFACTOR \
        int addFactor(char *strInfix, \
 			          char *strPolish, \
 			          int *intPtrIndex, \
 			          int intEnd)
ADDFACTOR;
#define ERRORHANDLER \
        int errorHandler(char *strMessage)
ERRORHANDLER;
#define ERRORHANDLERSYNTAX \
	    int errorHandlerSyntax(int intIndex, \
		                  char *strMessage, \
				char *strInfix)
ERRORHANDLERSYNTAX;
#define EXPRESSION \
	    int expression(char *strInfix, \
			 char *strPolish, \
			 int *intPtrIndex, \
			 int intEnd)
EXPRESSION;
#define INFIX2POLISH \
	    char *infix2Polish(char *strInfix)
INFIX2POLISH;
#define MAIN \
	    int main(int intArgCount, char **strArgs)
MAIN;
#define MULFACTOR \
	    int mulFactor(char *strInfix, \
 			char *strPolish, \
			int *intPtrIndex, \
 			int intEnd)
MULFACTOR;
#define STRINGAPPENDCHAR \
		int stringAppendChar(char *strInstring, \
     				   char chrNew, \
				   int intMaxLength, \
				   int intSpaceBefore)
STRINGAPPENDCHAR;
#define STRINGLENGTH \
	    int stringLength(char *strInstring)
STRINGLENGTH;
#define TESTCASE \
	    void testCase(char *strInfix, char *strExpected)
TESTCASE;
#define TESTER \
	    void tester()
TESTER;

// ***** Functions ***********************************************

// ---------------------------------------------------------------
// Command line handler
//
// int main(int intArgCount, char **strArgs)
//
MAIN
{
    tester();
    return;
}

// ---------------------------------------------------------------
// Parse add factor
//
// int addFactor(char *strInfix,
//	        char *strPolish,
//	        int *intPtrIndex,
//	        int intEnd)
//
// addFactor =3D mulFactor [ *|/ mulFactor ]
//
ADDFACTOR
{
    char chrMulOp =3D ' ';
    int intStartIndex =3D 0;
    if (!mulFactor(strInfix, strPolish, intPtrIndex, intEnd))
    {
		errorHandlerSyntax(*intPtrIndex,
			          "mulFactor not found",
				 strInfix);
		return 0;
    }
    if (*intPtrIndex > intEnd) return -1;
    intStartIndex =3D *intPtrIndex;
    while (1)
    {
		SKIP_WHITE_SPACE(strInfix, (*intPtrIndex), intEnd)
		if (*intPtrIndex > intEnd) break;
        if ((chrMulOp =3D strInfix[*intPtrIndex]) !=3D '*'
            &&
            chrMulOp !=3D '/')
			return -1;
        (*intPtrIndex)++;
        if (*intPtrIndex > intEnd
            ||
            !mulFactor(strInfix,
                       strPolish,
                       intPtrIndex,
					   intEnd))
            return errorHandlerSyntax
                   (*intPtrIndex,
                    "Mul/div op not followed by mulFactor",
					strInfix);
        if (!stringAppendChar(strPolish,
			                  chrMulOp,
							  MAX_POLISH_LENGTH,
							  1)) return 0;
    }
	return -1;
}

// ---------------------------------------------------------------
// Error handler
//
// int errorHandler(char *strMessage)
//
ERRORHANDLER
{
	printf("\n%s\n", strMessage); return 0;
}

// ---------------------------------------------------------------
// Syntax error handler
//
// int errorHandlerSyntax(int intIndex,
//                        char *strMessage,
//                        char *strInfix)
//
ERRORHANDLERSYNTAX
{
	int intIndex1 =3D 0;
	printf("\nError at character %d: %s\n",
		   intIndex,
		   strMessage);
	printf("%s\n", strInfix);
	for (intIndex1 =3D 0; intIndex1 < intIndex; intIndex1++)
		printf(" ");
	printf("$");
	return 0;
}

// ---------------------------------------------------------------
// Parse expression
//
// int expression(char *strInfix,
//			      char *strPolish,
//			      int *intPtrIndex,
//			      int intEnd)
//
EXPRESSION
{   /* expression =3D addFactor [ +|- addFactor ] */
	char chrAddOp =3D ' ';
	int intStartIndex =3D 0;
	if (!addFactor(strInfix, strPolish, intPtrIndex, intEnd))
	{
		errorHandlerSyntax(*intPtrIndex,
			               "addFactor not found",
						   strInfix);
		return 0;
	}
	intStartIndex =3D *intPtrIndex;
    while (1)
    {
		SKIP_WHITE_SPACE(strInfix, (*intPtrIndex), intEnd)
		if (*intPtrIndex > intEnd) break;
        if ((chrAddOp =3D strInfix[*intPtrIndex]) !=3D '+'
            &&
            chrAddOp !=3D '-')
			return
			 errorHandlerSyntax
			 (*intPtrIndex,
			  "Unrecognizable char found instead of add op",
			  strInfix);
        (*intPtrIndex)++;
        if (*intPtrIndex > intEnd
            ||
            !addFactor(strInfix,
                       strPolish,
                       intPtrIndex,
                       intEnd))
            return errorHandlerSyntax
                   (*intPtrIndex,
                    "Add/sub op not followed by addFactor",
					strInfix);
        stringAppendChar(strPolish,
			             chrAddOp,
						 MAX_POLISH_LENGTH,
						 1);
    }
	return -1;
}

// ---------------------------------------------------------------
// Convert infix to Polish
//
// char *infix2Polish(char *strInfix)
//
INFIX2POLISH
{
	int intIndex =3D 0;
	char *strPolish =3D malloc(MAX_POLISH_LENGTH);
	if (strPolish =3D=3D 0)
		errorHandler("Can't get storage");
	strPolish[0] =3D '\0';
	if (!expression(strInfix,
		            strPolish,
					&intIndex,
					stringLength(strInfix) - 1))
	{
		errorHandler("Can't parse expression");
		return "";
	}
	return strPolish;
}

// ---------------------------------------------------------------
// Parse multiplication factor
//
// int mulFactor(char *strInfix,
//			     char *strPolish,
//			     int *intPtrIndex,
//			     int intEnd)
//
// mulFactor =3D LETTER | NUMBER | '(' expression ')'
//
MULFACTOR
{ 	int intIndexStart =3D 0;
	int intLevel =3D 0;
	char chrNext =3D ' ';
	int intInner =3D 0;
	int intSpaceBefore =3D 0;
	SKIP_WHITE_SPACE(strInfix, (*intPtrIndex), intEnd)
	if (*intPtrIndex > intEnd)
		return errorHandlerSyntax(*intPtrIndex,
		                          "mulFactor unavailable",
								  strInfix);
	chrNext =3D strInfix[*intPtrIndex];
	if (chrNext >=3D 'a' && chrNext <=3D 'z')
	{
		(*intPtrIndex)++;
		return stringAppendChar(strPolish,
			                    chrNext,
								MAX_POLISH_LENGTH,
								1);
	}
	intIndexStart =3D *intPtrIndex;
	intSpaceBefore =3D -1;
	while(*intPtrIndex <=3D intEnd
		  &&
          (chrNext =3D strInfix[*intPtrIndex]) >=3D '0'
		  &&
		  chrNext <=3D '9')
	{
		if (!stringAppendChar(strPolish,
			                  chrNext,
							  MAX_POLISH_LENGTH,
							  intSpaceBefore))
			return 0;
		intSpaceBefore =3D 0;
		(*intPtrIndex)++;
	}
	if (*intPtrIndex > intIndexStart)
		return -1;
	if (chrNext =3D=3D '(')
	{
		intLevel =3D 1;
		(*intPtrIndex)++;
		intInner =3D *intPtrIndex;
		while (intLevel > 0 && *intPtrIndex <=3D intEnd)
		{
			if ((chrNext =3D strInfix[(*intPtrIndex)++]) =3D=3D '(')
			{
				intLevel++;
			}
			else
			{
				if (chrNext =3D=3D ')')
				{
					intLevel--;
				}
			}
		}
		if (intLevel !=3D 0)
			return errorHandlerSyntax
			       (*intPtrIndex,
			        "Unbalanced left parenthesis",
					strInfix);
		if (!expression(strInfix,
			            strPolish,
						&intInner,
						*intPtrIndex - 2))
			return errorHandlerSyntax
			       (intInner,
			        "Expression doesn't appear in parentheses",
					strInfix);
		return -1;
	}
	return 0;
}

// ---------------------------------------------------------------
// Append character to string
//
// int stringAppendChar(char *strInstring,
//   					char chrNew,
//						int intMaxLength,
//                      int intSpaceBefore)
//
STRINGAPPENDCHAR
{
	int intLength =3D stringLength(strInstring);
	int intSpaceBeforeInEffect =3D
		intSpaceBefore
		&&
		intLength > 0
		&&
		strInstring[intLength - 1] !=3D ' ';
	if (intLength
		>=3D
		intMaxLength - (intSpaceBeforeInEffect ? 2 : 1))
	{
		errorHandler
			("Cannot append character(s): string too long");
		return 0;
	}
    if (intSpaceBeforeInEffect)
	{
		strInstring[intLength++] =3D ' ';
	}
	strInstring[intLength] =3D chrNew;
	strInstring[intLength + 1] =3D '\0';
	return -1;
}

// ---------------------------------------------------------------
// Return string length
//
// int stringLength(char *strInstring)
//
STRINGLENGTH
{
	int intIndex1;
	for (intIndex1 =3D 0;
		 strInstring[intIndex1] !=3D '\0';
		 intIndex1++) { }
	return intIndex1;
}

// ---------------------------------------------------------------
// Test case
//
// void testCase(char *strInfix, char *strExpected)
//
TESTCASE
{
	printf("\n\nConverting \"%s\": expect \"%s\"",
		   strInfix,
		   strExpected);
	printf("\n\"%s\"\n",
		   infix2Polish(strInfix));
}

// ---------------------------------------------------------------
// Tester
//
// void tester()
//
TESTER
{
	testCase("(10+613)*a", "10 613 + a *");
	testCase(")", "Error");
	testCase("1)", "Error");
	testCase("(((1))))", "Error");
	testCase("10 113 + a *", "Error");
	testCase("(10 + 113) * a", "10 113 + a *");
	testCase(" ( 10 + 113 ) *  a  ", "10 113 + a *");
	testCase("(", "Error");
	testCase("((((2", "Error");
	testCase("////2", "Error");
	testCase("", "Error");
	testCase("()", "Error");
	testCase("(((5))", "Error");
	testCase("(((5)))", "5");
	testCase("((5))", "5");
	testCase("5", "5");
	testCase("((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a", "10 113 2 2 4
3 + / + 2 + 2 + - + a *");
	testCase("1+1", "1 1 +");
	testCase("a", "a");
	testCase("   a  +  b ", "a b +");
}





Converting "(10+613)*a": expect "10 613 + a *"
"10 613 + a *"


Converting ")": expect "Error"
Error at character 0: mulFactor not found
)
$
Error at character 0: addFactor not found
)
$
Can't parse expression

""


Converting "1)": expect "Error"
Error at character 1: Unrecognizable char found instead of add op
1)
 $
Can't parse expression

""


Converting "(((1))))": expect "Error"
Error at character 7: Unrecognizable char found instead of add op
(((1))))
       $
Can't parse expression

""


Converting "10 113 + a *": expect "Error"
Error at character 3: Unrecognizable char found instead of add op
10 113 + a *
   $
Can't parse expression

""


Converting "(10 + 113) * a": expect "10 113 + a *"
"10 113 + a *"


Converting " ( 10 + 113 ) *  a  ": expect "10 113 + a *"
"10 113 + a *"


Converting "(": expect "Error"
Error at character 1: Unbalanced left parenthesis
(
 $
Error at character 1: mulFactor not found
(
 $
Error at character 1: addFactor not found
(
 $
Can't parse expression

""


Converting "((((2": expect "Error"
Error at character 5: Unbalanced left parenthesis
((((2
     $
Error at character 5: mulFactor not found
((((2
     $
Error at character 5: addFactor not found
((((2
     $
Can't parse expression

""


Converting "////2": expect "Error"
Error at character 0: mulFactor not found
////2
$
Error at character 0: addFactor not found
////2
$
Can't parse expression

""


Converting "": expect "Error"
Error at character 0: mulFactor unavailable

$
Error at character 0: mulFactor not found

$
Error at character 0: addFactor not found

$
Can't parse expression

""


Converting "()": expect "Error"
Error at character 1: mulFactor unavailable
()
 $
Error at character 1: mulFactor not found
()
 $
Error at character 1: addFactor not found
()
 $
Error at character 1: Expression doesn't appear in parentheses
()
 $
Error at character 2: mulFactor not found
()
  $
Error at character 2: addFactor not found
()
  $
Can't parse expression

""


Converting "(((5))": expect "Error"
Error at character 6: Unbalanced left parenthesis
(((5))
      $
Error at character 6: mulFactor not found
(((5))
      $
Error at character 6: addFactor not found
(((5))
      $
Can't parse expression

""


Converting "(((5)))": expect "5"
"5"


Converting "((5))": expect "5"
"5"


Converting "5": expect "5"
"5"


Converting "((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a": expect "10
113 2 2 4 3 + / + 2 + 2 + - + a *"
"10 113 2 2 4 3 + / + 2 + 2 + - + a *"


Converting "1+1": expect "1 1 +"
"1 1 +"


Converting "a": expect "a"
"a"


Converting "   a  +  b ": expect "a b +"
"a b +"
0
spinoza1111 (3246)
11/3/2009 4:14:35 PM
On Nov 3, 7:56=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> spinoza1111<spinoza1...@yahoo.com> writes:
> > On Nov 3, 12:13=A0pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
> >>spinoza1111<spinoza1...@yahoo.com> writes:
>
> >> <snip>
>
> >> > But I think you messed up the grammar...but not the code.
>
> >> > expr -> term { [+-] term }
>
> >> > doesn't parse 1+1+1.
>
> >> The {} is a very common notation. =A0I agree that [+-] is not usual, b=
ut were
> >> you at all puzzled by what the notation meant? =A0It is obviously
> >> borrowed from regular expressions.
>
> > OK, that's correct: [+-] is "the set of characters including plus and
> > minus" where one character is chosen from the set. But I shouldn't
> > have to do the work of expressing things clearly on your behalf in
> > English.
>
> > Nor should regular expression notation be mixed into BNF unless
> > absolutely necessary.
>
> Most extended grammar notations use very similar nation to that used
> in regular expressions. =A0I don't see a problem with that.

Fair enough.
>
> > But in neither notation do curley braces imply iteration and as far as
> > I can see you need iteration to parse 1+1+1. What am I missing, dear
> > Ben?
>
> That {} denotes repetition in all the forms of EBNF that I have seen.

OK.
>
> >> Wirth would have written:
>
> >> =A0 expr =3D term { ("+"|"-") term } .
>
> >> and in plain EBNF one would write
>
> >> =A0 expr =3D term | { "+" , term } | { "-" , term } ;
>
> >> both of which are a bit clumsy. =A0I found Gene's shorthand quite clea=
r.
>
> > They both look wrong (and note that unlike some of the thugs and
> > twerps here I don't infer your global ignorance). Period ordinarily
> > means end of string (which is needed as I have said when you do not
> > lookahead to balance parentheses)....not iteration.
>
> In Wirth's version of EBNF (note the E) . ends the production. =A0()s
> indicate grouping and | alternation (as in most regular expression
> syntax) and {} repetition zero or more times.

Does the period in Wirth-EBNF mean "the symbol we use to represent end
of file explicitly"?
>
> > The second is in particular absurd. If by | you mean BNF or, then
> > you're saying that an expr may start with a plus sign. If you add
> > unary minus it may but I do not believe this was your intent.
>
> No, I missed the term that starts each alternation:
>
> =A0 expr =3D term | term { "+" , term } | term { "-" , term } ;

Thanks for clarification.
>
> Where () can't be used to group and alternation, the alternatives get
> more complex. =A0The point being that in both Wirth's EBNF and in plain
> EBNF {} means repetition.
>
> > I think
> > you either have a private BNF notation, Bacarisse Normal Form, or you
> > don't know how to use BNF at all.

I withdraw that statement. You are in fact current on more notations
than I.
>
> > Here is the correct BNF as far as I can tell:
>
> > expr :=3D addFactor
> > expr :=3D addFactor ( [+-] addFactor ) *
>
> You keep saying BNF but all these are extended notations. =A0BNF used
> <>s and ::=3D and has no shorthand for optional or repeated elements.

OK, it's my BNF, and it's less standard than yours. Your point is
conceded.
>
> > As a favor to you I use the square bracket set notation and instead of
> > square brackets for optional sequence I've split the production into
> > two parts, using round parentheses to group and asterisk to iterate.
>
> Your notation -- specifically adding * after an optional item -- is
> not common. =A0I've not seen it in any text. =A0Some EBNFs do use * but a=
s
> a operator applied to any element. =A0Applying it to something optional
> is redundant.

That is correct.
>
> <snip>
> --
> Ben.- Hide quoted text -
>
> - Show quoted text -

0
spinoza1111 (3246)
11/3/2009 4:18:16 PM
On Nov 3, 5:24=A0pm, Nick Keighley <nick_keighley_nos...@hotmail.com>
wrote:
> On 2 Nov, 17:36, Gene <gene.ress...@gmail.com> wrote:
>
> > On Nov 2, 10:48=A0am,spinoza1111<spinoza1...@yahoo.com> wrote:
> > > On Nov 2, 10:10=A0pm, Gene <gene.ress...@gmail.com> wrote:
> > > > On Oct 25, 11:33=A0pm, Tameem <etam...@gmail.com> wrote:
> > > > > i have a string as (a+b)+8-(c/d) in Infix form.
>
> > > > > how can i convert it to postfix form using C language,,,????
>
> > > > I suppose that if this is homework, the due date has passed.
>
> <snip neat code>
>
> > > Thanks for this. Looks like you stole my approach,
>
> good grief

You snipped the other alternative, which was "great minds think
alike".
>
> > > but I find that
> > > most gratifying if true, and an indication that "great minds think
> > > alike" if not. Your contribution at a minimum is to show just how
> > > gnomic and terse one can be in C.
>
> looks pretty straightforward C to me. It's clearer than yours.

I really wish people would qualify "clarity" and relativise it to
their perception. Like Seebach, you use the word "clarity" here. His
code is more to your taste: I can deal with that. But not "clearer"
except for a reader who prefers a terse style.

>
> > > It would not be appropriate to
> > > credit me since it is a common and solid algorithm that has been
> > > around for years.
>
> riight

Yup.
>
> > > Hope you don't mind, but I'm going to copy this code and incorporate
> > > it in what will not be a three way test: of my C Sharp version, my C
> > > version and your gnomic C. I want to add more testing (using a random
> > > generator in C Sharp), a GUI and timing comparisions and shall report
> > > back.
>
> one idea would be to make you tester() function silent. Only print
> something if the test fails. This will also mean your timeing tests
> are testing the algorithm rather than the i/o.

....not if the test material is a constant...
>
> > This doesn't qualify as anything like theft or great thinking. For
> > fun, I wrote the code in about 5 minutes after the OP posted (based onh=
ttp://groups.google.com/group/comp.lang.c/msg/fe772c9d6a28fdc4), but
> > refrained from posting it because it was probably homework for the
> > OP. =A0This is a standard example or homework assignment for just about
> > any undergrad course that covers recursive descent parsing.
>
> I don't see the words "recursive descent parsing" in the OP

I don't think the professor taught him RDP. That would be material
introduced in a compiler course.
>
>
>
> >=A0The
> > gramamr with minor variations is in at least a dozen complier design
> > textbooks including ASU. Usually it's given in left-recursive form,
> > and then the author or student go through the L-rec removal, left-
> > factoring, and BNF conversion. =A0RPN generation is a trivial example o=
f
> > attribute evaluation.- Hide quoted text -
>
> - Show quoted text -

0
spinoza1111 (3246)
11/3/2009 4:22:16 PM
On Nov 3, 4:54=A0pm, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-11-03, Richard Heathfield <r...@see.sig.invalid> wrote:
>
> > Yeah. If ever he gets around to fixing them in my lifetime, I'll look
> > at the resulting code.

Richard, either participate in the discussion (examining the code and
reporting bugs or pissing and moaning about style if you must) or just
leave the room.
>
> You missed some pretty fun stuff in there, though.
>
> I think I'm actually willing to half-concede one of his points: =A0For hi=
m,
> it is probably true that C is an inherently unsafe language. =A0Note the
> qualifier, though.

Jerk.
>
> -s
> --
> Copyright 2009, all wrongs reversed. =A0Peter Seebach / usenet-nos...@see=
bs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny picturesht=
tp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

0
spinoza1111 (3246)
11/3/2009 4:23:54 PM
On Nov 3, 3:32=A0pm, Chris McDonald <ch...@csse.uwa.edu.au> wrote:
> spinoza1111<spinoza1...@yahoo.com> writes:
> >But the more I relearn about C from experts like you, the more I
> >wonder why this language is still in use. Perhaps it will be
> >eradicated in 2038 as much old Cobol was eradicated to prevent Y2K,
> >since C shall blow us all to kingdom come when its timers overflow in
> >that year. I shall work out and not drink or smoke to see that happy
> >day.
>
> Which part of the C standard do you believe links C to the year 2038?

Date precision. Ever wonder why spam is dated 2038? Did the standards
fix this problem?
>
> --
> Chris.

0
spinoza1111 (3246)
11/3/2009 4:26:23 PM
spinoza1111 <spinoza1111@yahoo.com> writes:

> On Nov 3, 7:56 pm, Ben Bacarisse <ben.use...@bsb.me.uk> wrote:
<snip>
>> >> Wirth would have written:
>>
>> >>   expr = term { ("+"|"-") term } .
<snip>
>> In Wirth's version of EBNF (note the E) . ends the production.  ()s
>> indicate grouping and | alternation (as in most regular expression
>> syntax) and {} repetition zero or more times.
>
> Does the period in Wirth-EBNF mean "the symbol we use to represent end
> of file explicitly"?

No, it denotes the end of the grammar rule.  It is meta-syntax.

<snip>
-- 
Ben.
0
ben.usenet (6790)
11/3/2009 4:56:44 PM
spinoza1111 <spinoza1111@yahoo.com> writes:

> On Nov 3, 3:32 pm, Chris McDonald <ch...@csse.uwa.edu.au> wrote:
>> spinoza1111<spinoza1...@yahoo.com> writes:
>> >But the more I relearn about C from experts like you, the more I
>> >wonder why this language is still in use. Perhaps it will be
>> >eradicated in 2038 as much old Cobol was eradicated to prevent Y2K,
>> >since C shall blow us all to kingdom come when its timers overflow in
>> >that year. I shall work out and not drink or smoke to see that happy
>> >day.
>>
>> Which part of the C standard do you believe links C to the year 2038?
>
> Date precision. Ever wonder why spam is dated 2038? Did the standards
> fix this problem?

I am sure you can see this does not answer the question.  Chris
McDonald was asking specifically about C.  You seem to think there is
a problem with C's date/time functions.

-- 
Ben.
0
ben.usenet (6790)
11/3/2009 5:00:04 PM
On 2009-11-03, spinoza1111 <spinoza1111@yahoo.com> wrote:
> I really wish people would qualify "clarity" and relativise it to
> their perception. Like Seebach, you use the word "clarity" here. His
> code is more to your taste: I can deal with that. But not "clearer"
> except for a reader who prefers a terse style.

This is not entirely accurate.  There are measurable traits such as the
time it takes people to read code, or the reliability with which they
read it.  Your version of this had a lot more fluff between the code
and the reader.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/3/2009 5:12:15 PM
On 2009-11-03, spinoza1111 <spinoza1111@yahoo.com> wrote:
> On Nov 3, 3:32�pm, Chris McDonald <ch...@csse.uwa.edu.au> wrote:
>> spinoza1111<spinoza1...@yahoo.com> writes:
>> Which part of the C standard do you believe links C to the year 2038?

> Date precision.

Uh, well, no.

> Ever wonder why spam is dated 2038? Did the standards
> fix this problem?

The standard never had this problem.  Individual implementors have chosen
different ways of representing dates; it's up to them to decide which
representation they want.  POSIX does specify a representation in seconds
since Jan 1 1970 UTC, but does not specify a particular limit on the size
of the object used to store that value.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/3/2009 5:13:36 PM
On Nov 3, 2:39=A0am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-11-02,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > This post contains the promised C code version of the infix to Polish
> > notation convertor. When run from the command line it should execute
> > all cases used to test the C Sharp version correctly. Its string
> > handling is simpler owing to the limitations of C.
>
> Okay.

Hmm, didn't see your comments. If you contribute a bug report or good
suggestion for change, I shall incorporate it.
>
> > #include <stdio.H>
> > #include <stdlib.H>
>
> Don't capitalize the "H" -- while it may happen to work on your system,
> it means the code won't compile on others. =A0Even an easily-fixed compil=
e
> error makes people likely to discount your code.

Got it. Thanks.
>
> > #define MAX_POLISH_LENGTH 100
> > int errorHandler(char *strMessage)
> > {
> > =A0 =A0printf("\n%s\n", strMessage); return 0;
> > }
>
> This always returns the same value, why does it have a return value at
> all?

I do this all the time in C Sharp, because when I call the error
handler I am usually preparing to return from any caller with a
Boolean value, and my practice, in C Sharp, is to always return true
or false from any method that does not otherwise return a value. Saves
a lot of bullshit and enables optimization, in my understanding.
>
> If this is for an error message, why isn't it using stderr for its output=
?

Because there is no meaningful distinction anymore between stderr and
stdout, and the disctinction is legacy.
>
> The double-\n thing is a bit unusual; normally a convention is adopted
> where messages should either end with (normally) or start with (less
> often) a newline, rather than providing two. =A0In particular, if there a=
re
> two consecutive error messages for some reason, this would produce a blan=
k
> line between them.
>
Yes. I like white space.

> It would seem much more useful to implement this function using ... argum=
ents
> and the underlying vfprintf() to allow formatted messages to be displayed=
..
> If I were writing a function to this effect, I'd probably do:
>
> =A0 =A0 =A0 =A0 void
> =A0 =A0 =A0 =A0 errorHandler(char *msg, ...) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 va_list ap;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 va_start(ap, fmt);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 vfprintf(stderr, fmt, ap);
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 va_end(ap);
> =A0 =A0 =A0 =A0 }
>

I don't see the worth of this at this time, but I may be missing
something.

> You prefix the variable's name with a type. =A0While that certainly CAN b=
e
> a reasonable thing, it's important to ensure that the type used is a real
> abstract type, not merely a language type -- language types are already
> type checked.

Do you mean my use of Hungarian here?
>
> > int errorHandlerSyntax(int intIndex, char *strMessage)
>
> You're using Systems Hungarian here, which is crap. =A0Don't. =A0Apps Hun=
garian
> is what Simonyi proposed and demonstrated to be useful. =A0Systems Hungar=
ian
> isn't useful, and leads to bugs later.

This is not my experience, especially with modern editors. It doesn't
cause bugs unless it is not maintained. What part of strong typing
don't you understand?

>
> > {
> > =A0 =A0printf("\nError at character %d: %s\n",
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 intIndex,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 strMessage);
> > =A0 =A0return 0;
> > }
>
> This is a useless message. =A0It doesn't tell the user what the character
> IS, nor does it give the user any feedback as to the nature of the messag=
e.
> And, again, suggest that you implement format arguments.

The most recent version prints the infix expression and puts a dollar
sign under the error point, so your point is taken. The strMessage
gives the "feedback".
>
> > int stringLength(char *strInstring)
> > {
> > =A0 =A0int intIndex1;
> > =A0 =A0for (intIndex1 =3D 0;
> > =A0 =A0 =A0 =A0 =A0 =A0 strInstring[intIndex1] !=3D '\0';
> > =A0 =A0 =A0 =A0 =A0 =A0 intIndex1++) { }
> > =A0 =A0return intIndex1;
> > }
>
> Why the fuck did you even write this? =A0

Because string.h is fucking fucked.

> strlen() exists for a reason.

I don't choose to include libraries unnecessarily when I can write a
little code for the limited amount of functionality that I need.

> And just for extra credit: =A0This name is reserved for use exclusively
> by the implementation, since it starts with "str" followed by a lowercase
> letter. =A0In practice it's likely harmless in modern systems because
> names are usually case-sensitive, and the standard doesn't define library
> functions with camelCase.
>
> But it's still stupid.

In your view. In my view, the "library" approach of C is horseshit
because you get a Lot Of Useless Crap for one little function that you
need.
>
> > int stringAppendChar(char *strInstring,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 char chrNew,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 int intMaxLength)
> > {
> > =A0 =A0int intLength =3D stringLength(strInstring);
> > =A0 =A0if (intLength >=3D intMaxLength - 1)
> > =A0 =A0{
> > =A0 =A0 =A0 =A0 =A0 =A0errorHandler
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0("Cannot append character: strin=
g too long");
> > =A0 =A0 =A0 =A0 =A0 =A0return 0;
> > =A0 =A0}
> > =A0 =A0strInstring[intLength] =3D chrNew;
> > =A0 =A0strInstring[intLength + 1] =3D '\0';
> > =A0 =A0return -1;
> > }
>
> int
> stringAppendChar(char *s, char c, size_t max) {
> =A0 =A0 =A0 =A0 char *end =3D strchr(s, '\0');
> =A0 =A0 =A0 =A0 if (end - s < max) {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 *end++ =3D c;
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 *end =3D '\0';
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return end - s;
> =A0 =A0 =A0 =A0 } else {
> =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 return -1;
> =A0 =A0 =A0 =A0 }
>
> }
>
> Note that I've changed the sense of the return value. =A0This is because
> by convention -1 indicates a failure. =A0Returning the actual length,
> rather than a meaningless value, gives the caller some additional
> information.

No, -1 is the truest true value. My understanding (let me know if it's
changed since 1991), zero is falseness whereas nonzero is truthiness.
Well, -1, on twos-complement systems, which despite your nonsense in
C: The Complete Nonsense are dominant, is the number least like zero
since it's all ones and isn't that a kiss my ass?


>
> Note that I've preserved the probable-bug, which is that if you have an
> array of 15 characters, and you call this function with the limit 15 on
> an array containing 14 non-zero characters and a null byte,
> it'll write the 16th character of the 15-character array. =A0That's almos=
t
> always a bad choice.

Making sure that the only string I allocate and append to, the Polish
string, is on my to do. I was worried about screwing that up, but I
malloc'd 100 bytes for the Polish string, and none of my test cases
approach that length.

The next version (not the one I posted this evening, Nov 3 in China
time) will malloc n characters for the Polish, where n is the number
of characters in the infix less the number of parentheses and blanks.
This will break the string append if I didn't do it right, and I shall
in all probability incorporate this observation.
>
> I've omitted the ridiculous error message call, for reasons which shall
> become apparent.

So it's ridiculous to give a humane error message? Explain.
>
>
>
>
>
> > int appendPolish(char *strPolish, char chrNext)
> > {
> > =A0 =A0return
> > =A0 =A0 =A0 =A0 =A0 =A0((*strPolish =3D=3D '\0' || *strPolish =3D=3D ' =
')
> > =A0 =A0 =A0 =A0 =A0 =A0 ?
> > =A0 =A0 =A0 =A0 =A0 =A0 -1
> > =A0 =A0 =A0 =A0 =A0 =A0 :
> > =A0 =A0 =A0 =A0 =A0 =A0 stringAppendChar(strPolish,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0' ',
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 =A0MAX_POLISH_LENGTH))
> > =A0 =A0 =A0 =A0 &&
> > =A0 =A0 =A0 =A0 =A0 =A0stringAppendChar(strPolish,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 chrNext,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0 MAX_POLISH_LENGTH)
> > =A0 =A0 =A0 =A0 &&
> > =A0 =A0 =A0 =A0 =A0 =A0stringAppendChar(strPolish, ' ', MAX_POLISH_LENG=
TH);
> > }
>
> This is just plain horrid. =A0The layout is surreal, and the logic
> opaque.

The layout is the result of tabs being converted to blanks. Tomorrow I
shall resubmit the detabbed code.
>
> I think you mean:
>
> int appendPolish(char *strPolish, char chrNext)
> {
> =A0 if (*strPolish =3D=3D ' ' || *strPolish =3D=3D '\0')
> =A0 =A0 return -1;
> =A0 ... wait, this doesn't even make sense.
>
> }
>
> This function aborts if the FIRST character of strPolish is a space or
> a null, but then appends characters off at the end of strPolish. =A0This
> makes no sense. =A0You'll have to put in some kind of explanatory comment
> to justify that.
>
This code has been rewritten, so your point may be correct, but it's
moot.

> There's also the fact that calling stringAppendChar three times in a row
> is stupid. =A0Figure out how many characters are left, and if there's eno=
ugh
> room for three, append all three at once. =A0Appending one or two of them
> is not useful.

Point taken. The code was rewritten. Great minds think alike. You too.
>
> > int mulFactor(char *strInfix,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0char *strPolish,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int *intPtrIndex,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0int intEnd)
> > { /* mulFactor =3D LETTER | NUMBER | '(' expression ')' */
> > =A0 =A0int intIndexStart =3D 0;
> > =A0 =A0int intLevel =3D 0;
> > =A0 =A0char chrNext =3D ' ';
> > =A0 =A0int intInner;
> > =A0 =A0if (*intPtrIndex > intEnd)
> > =A0 =A0 =A0 =A0 =A0 =A0return errorHandlerSyntax(*intPtrIndex,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0"mulFactor unavailable");
>
> This is a crappy error message. =A0The problem has nothing at all to do w=
ith
> mulFactor. =A0It has to do with you having, apparently, run out of room
> or something. =A0So say so; give a message like "string too long".

Study the code a little more thoroughly. While this particular test
may have changed in my Nov 3 version, it was necessary in this version
because mulFactor in all versions must needs incorporate the functions
of a scanner (including testing end of input). If input has been
exhausted, we have entered mulFactor expecting a multiply factor and
there is none.
>
> > =A0 =A0if (chrNext =3D=3D '(')
>
> This is the point where you should be calling a different function that
> handles parenthesized expressions, IMHO.
>
> > =A0 =A0 =A0 =A0 =A0 =A0if (!expression(strInfix,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strPolis=
h,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0&intInner,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
 =A0 =A0 =A0 =A0*intPtrIndex - 2))
>
> Ugh.
>
> Seems like this would be a great time to refactor this more sanely. =A0In
> particular, you're having the higher-level code (mulfactor) try to guess
> the range of the substring.

Yes, I said it looks ahead.
If it didn't it would be dead.

In this code, mulFactor integrates scanning and parsing and is
lowlevel. As I have said elsewhere, it might be better to avoid this
lookahead by making "end of input" a grammar category, but this "ugly"
code is elegant in context, since I wanted to keep the program short;
it seemed overkill to write a lexical scanner for mulFactor to call.
>
> What happens when someone asks you to support strings? =A0

At that point, I factor. Premature factorization especially for you
bums is in my experience a waste of time.

> Then suddenly
> mulfactor() has to be smart enough to find the end of:
> =A0 =A0 =A0 =A0 (a + ")")
>
> and you're making a ton of work. =A0Wrong. =A0When you see the (, pass it=
 off
> to the function which tries to find an expression followed by a trailing =
),
> and have the expression parser hand what it found so far back up when it
> sees the ) -- at which point the parens function finds its trailing ) and=
 is
> happy.

"The function which tries to find an expression followed by a
trailing )"? Give me a break. That's not a grammar category and
writing such a function is asking for trouble.

It's not necessarily ugly to "read ahead": cf the 2nd ed. of the
Dragon Book, p 78. Also, see Nilges' "Build Your Own Goddamn .Net
Language and Goddamn Compiler" for a discussion of the need for
lookahead in processing unary minus and right parentheses. I worked
through these issues several years ago in VB, and if you care to
comment on my approaches, buy my book. Of course, if you do a hatchet
job on the book, I'll be on your case like a fly on shit...save where
you are right in any important way, in which case I will help you
write your critique and get your errata into Apress' Web site.

Reading ahead steps outside the formal grammar paradigm, but think of
it as having an "oracle": this metaphor was used in an old MacDonald
Elsevier "Monograph in Computer Science": the one, in fact, on
compiler development. It's like using a lex symbol to represent end of
input.

>
> > char *infix2Polish(char *strInfix)
> > {
> > =A0 =A0int intIndex =3D 0;
> > =A0 =A0char *strPolish =3D malloc(MAX_POLISH_LENGTH);
>
> Sure enough, you did what I thought you'd do. =A0You allocate MAX_POLISH_=
LENGTH
> characters, but then, you use MAX_POLISH_LENGTH as the cap you pass to
> strAppendChar, meaning that if your Polish string contains MAX_POLISH_LEN=
GTH-1
> characters, you will end up writing one past the end of the array.

Point taken. I was suspicious of the code myself since I have
encountered that problem before. It's an artifact of the unsafe design
of the Infantile Disorder in which I am coding. My plan was to address
it when I got around to doing an EXACT malloc of n bytes, where n is
the number of nonparentheses and nonblanks in the infix string plus
one for the Stupid Nul Byte.

>
> It turns out that the fencepost conventions people use in C are there for
> a good reason.
>
> > =A0 =A0if (strPolish =3D=3D 0)
> > =A0 =A0 =A0 =A0 =A0 =A0errorHandler("Can't get storage");
> > =A0 =A0strPolish[0] =3D '\0';
>
> Since errorHandler doesn't exit in any way, you're still going to segfaul=
t
> (or whatever) when you reach this line.

Thanks for pointing this out. Probably should return.
>
> > =A0 =A0if (!expression(strInfix,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0strPolish,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
&intIndex,
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
stringLength(strInfix) - 1))
> > =A0 =A0{
> > =A0 =A0 =A0 =A0 =A0 =A0errorHandler("Can't parse expression");
> > =A0 =A0 =A0 =A0 =A0 =A0return "";
>
> Oh, that's great. =A0You are now returning pointers from this function wh=
ich
> MAY OR MAY NOT be the results of malloc(), so you can't free them safely.

Very good point.
>
> This should be:
> =A0 =A0 =A0 =A0 strPolish[0] =3D '\0';
> =A0 =A0 =A0 =A0 return strPolish;
>
Excellent. You should turn pro.

> > =A0 =A0printf("Expect 10 113 + a *: %s\n",
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 infix2Polish("(10+113)*a"));
>
> Because infix2Polish allocates memory, but you never free the results, th=
is
> is a memory leak.

Don't be a silly bastard. It's not a memory leak since I return to main
() (I was tempted to return void just to piss you off but Microsoft C
sets me up with int main()). Now you're making silly comments just to
pad your anti-resume. Shape up.

Nonetheless, I like the idea of having a free for every malloc, since
there's this cool computer author that recommends doing this, and it
makes eminent sense.

{Chortle)

Therefore I shall fix this.

>
> > int main(int intArgCount, char **strArgs)
>
> Renaming the args to main, not useful. =A0Declaring them when you're not =
using
> them, also not useful.

I prefer that all things use my naming style, thank you. And they are
for later use.

>
> > {
> > =A0 =A0 tester();
> > =A0 =A0 return;
>
> return without a value in function not returning void
>
> Okay, I will concede one point: =A0You would actually be better off readi=
ng
> Schildt's books than muddling along without. =A0You'd be even better off =
reading
> a better C book, but really, any port in a storm.

Bite my crank.

But thanks for your observations. Not as good as Bacarisse but at
least you jumped in and got to work, unlike your friend Heathfield,
who's trashed so many people that he's afraid to make a mistake.

Furthermore, thanks to your help and my own coding and testing, I am
ramping back up quickly in C and shall shortly, if I persist, run
rings around you. This is because Princeton was right when they
refused to conduct classes at uni level in C, and had a mere Roosevelt
graduate (me) teach C. A programming language is easy to learn: it's
the science and effective style that's difficult...the latter so much
so, that most programmers' opinions on style are worthless (your views
on Hungarian being an example).

However, C is also a waste of spirit in an expense of shame. I am also
an artist and a teacher, and instead of focusing on nonsense problems
that wouldn't exist if C had been designed not misbegotten I could be
preparing classes or painting pictures. Instead I am muttering over
runes from the Dark Ages and the process is making me crabby. I am
having to restrain myself from kicking small animals.

Nonetheless I shall persist for now, in order to demonstrate that two
propositions are true. One is that I'm smarter than you. The other is
that we can work together to find bugs in each others' code because
nobody is too smart to make stupid mistakes, a lesson which if you
learn well will, I hope, cause you to withdraw The Vicious Tirade.

>
> -s
> --
> Copyright 2009, all wrongs reversed. =A0Peter Seebach / usenet-nos...@see=
bs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny picturesht=
tp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!- Hide =
quoted text -
>
> - Show quoted text -

0
spinoza1111 (3246)
11/3/2009 5:21:16 PM
In 
<26fc2e78-e151-4c23-990e-e86a1e993b62@u16g2000pru.googlegroups.com>, 
spinoza1111 wrote:

> On Nov 3, 4:54 pm, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2009-11-03, Richard Heathfield <r...@see.sig.invalid> wrote:
>>
>> > Yeah. If ever he gets around to fixing them in my lifetime, I'll
>> > look at the resulting code.
> 
> Richard, either participate in the discussion (examining the code
> and reporting bugs

Did that already. Not my fault you're too stupid to recognise bug 
reports. Turn Up Your Warning Level. Sheesh.

-- 
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
0
rjh (10791)
11/3/2009 5:48:24 PM
In 
<cfebc09f-0b34-4de8-ab71-f309369ffb36@w37g2000prg.googlegroups.com>, 
spinoza1111 wrote:
> On Nov 3, 2:39 am, Seebs <usenet-nos...@seebs.net> wrote:
> > On 2009-11-02,spinoza1111<spinoza1...@yahoo.com> wrote:

<polite stuff reluctantly snipped despite its rarity value>

>> > #define MAX_POLISH_LENGTH 100
>> > int errorHandler(char *strMessage)
>> > {
>> > printf("\n%s\n", strMessage); return 0;
>> > }
>>
>> This always returns the same value, why does it have a return value
>> at all?
> 
> I do this all the time in C Sharp, because when I call the error
> handler I am usually preparing to return from any caller with a
> Boolean value, and my practice, in C Sharp, is to always return true
> or false from any method that does not otherwise return a value.

This is (close to) my practice too - in general, my functions return 
int (and the ones that don't, tend to return either void or a T* for 
some type T). Sometimes, I have no better value to return than 0 
during the development process, so return 0; goes in, awaiting more 
rigorous error handling later. Sometimes that error handling turns 
out to be unnecessary for the time being, but the return 0 stays in 
anyway, in case at some point in the future it becomes necessary to 
add error handling.

<didn't read the rest - no time>

-- 
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
0
rjh (10791)
11/3/2009 5:56:46 PM
On 2009-11-03, spinoza1111 <spinoza1111@yahoo.com> wrote:
> On Nov 3, 2:39�am, Seebs <usenet-nos...@seebs.net> wrote:

> I do this all the time in C Sharp, because when I call the error
> handler I am usually preparing to return from any caller with a
> Boolean value, and my practice, in C Sharp, is to always return true
> or false from any method that does not otherwise return a value. Saves
> a lot of bullshit and enables optimization, in my understanding.

Be interesting to know how it "enables optimization".

>> If this is for an error message, why isn't it using stderr for its output?

> Because there is no meaningful distinction anymore between stderr and
> stdout, and the disctinction is legacy.

Simply untrue -- there's a ton of systems out there which maintain the
distinction clearly.  Again, if you're posting code that might some day
be used or tried by other people, doing things right matters even if it
doesn't have a discernable effect on your system.  There is a difference
there, even if it doesn't affect your personal desktop.

>> The double-\n thing is a bit unusual; normally a convention is adopted
>> where messages should either end with (normally) or start with (less
>> often) a newline, rather than providing two. �In particular, if there are
>> two consecutive error messages for some reason, this would produce a blank
>> line between them.

> Yes. I like white space.

Blank lines used for emphasis are useful, blank lines which flood the display
with blank lines just disrupt the reader's flow.

>> It would seem much more useful to implement this function using ... arguments
>> and the underlying vfprintf() to allow formatted messages to be displayed.
>> If I were writing a function to this effect, I'd probably do:

> I don't see the worth of this at this time, but I may be missing
> something.

Consider the option of writing messages like:

  errorHandler("syntax error: Got '%c', was expecting an operator.", s[i]);

Basically, anything that makes it convenient and easy to give more
specific feedback.

>> You prefix the variable's name with a type. �While that certainly CAN be
>> a reasonable thing, it's important to ensure that the type used is a real
>> abstract type, not merely a language type -- language types are already
>> type checked.

> Do you mean my use of Hungarian here?

There are two kinds of Hungarian.  The kind that is actually in some way
beneficial, which denotes abstract types, and the kind which denotes compiler
types and is demonstrably harmful.  You used the latter kind.

>> You're using Systems Hungarian here, which is crap. �Don't. �Apps Hungarian
>> is what Simonyi proposed and demonstrated to be useful. �Systems Hungarian
>> isn't useful, and leads to bugs later.

> This is not my experience, especially with modern editors. It doesn't
> cause bugs unless it is not maintained. What part of strong typing
> don't you understand?

I understand strong typing just fine.  That's why systems hungarian is stupid;
it's not actually adding any data.

Apps Hungarian would be to, say, indicate whether something is a distance
or an index or whatever -- all things which could be stored in an int,
but which are not interchangeable sorts.  Systems Hungarian is useless,
because it just replicates stuff the compiler can already check.

Interestingly, Simonyi has come out pretty strongly against the Systems
Hungarian thing -- and given that he's the originator of Hungarian notation,
I thin kthat's pretty damning.

> Because string.h is fucking fucked.

No, it isn't.

>> strlen() exists for a reason.

> I don't choose to include libraries unnecessarily when I can write a
> little code for the limited amount of functionality that I need.

When the library is part of the core language, that attitude is stupid.
You can't outperform the library writers, and every line of code you
spend reinventing the wheel is wasted.

> In your view. In my view, the "library" approach of C is horseshit
> because you get a Lot Of Useless Crap for one little function that you
> need.

Maybe, except *you already got it*.  You've already paid the cost, might as
well use the stuff.

> No, -1 is the truest true value.

It may be, but it's also used widely as an out-of-band error indicator.

> My understanding (let me know if it's
> changed since 1991), zero is falseness whereas nonzero is truthiness.
> Well, -1, on twos-complement systems, which despite your nonsense in
> C: The Complete Nonsense are dominant, is the number least like zero
> since it's all ones and isn't that a kiss my ass?

Actually, it's not, because no one cares about the bit representation; we
just care whether the number it represents communicates clearly to the
user.

>> Note that I've preserved the probable-bug, which is that if you have an
>> array of 15 characters, and you call this function with the limit 15 on
>> an array containing 14 non-zero characters and a null byte,
>> it'll write the 16th character of the 15-character array. �That's almost
>> always a bad choice.

> Making sure that the only string I allocate and append to, the Polish
> string, is on my to do. I was worried about screwing that up, but I
> malloc'd 100 bytes for the Polish string, and none of my test cases
> approach that length.

Which is to say, it does indeed turn out that you got it wrong.

This is the other reason to use the library -- the library functions
handle their boundaries correctly, in general.

>> I've omitted the ridiculous error message call, for reasons which shall
>> become apparent.

> So it's ridiculous to give a humane error message? Explain.

It's not a useful message in context.

> Study the code a little more thoroughly. While this particular test
> may have changed in my Nov 3 version, it was necessary in this version
> because mulFactor in all versions must needs incorporate the functions
> of a scanner (including testing end of input). If input has been
> exhausted, we have entered mulFactor expecting a multiply factor and
> there is none.

But the user doesn't care about "mulFactor".  The user wants to know
"we reached the end of the string while expecting more input".  The internal
details like "mulFactor" are not part of the user's knowledge of what
the program is doing, and shouldn't have to be.

>> Seems like this would be a great time to refactor this more sanely. �In
>> particular, you're having the higher-level code (mulfactor) try to guess
>> the range of the substring.

> Yes, I said it looks ahead.
> If it didn't it would be dead.

Looking ahead like that, though, means that that function has to handle
all sorts of hypothetical future special cases -- which is silly.  Just
have the parser recurse and tell you how far it got.

> At that point, I factor. Premature factorization especially for you
> bums is in my experience a waste of time.

I'm a big fan of handling at least the common cases up front.

> It's not necessarily ugly to "read ahead": cf the 2nd ed. of the
> Dragon Book, p 78. Also, see Nilges' "Build Your Own Goddamn .Net
> Language and Goddamn Compiler" for a discussion of the need for
> lookahead in processing unary minus and right parentheses. I worked
> through these issues several years ago in VB, and if you care to
> comment on my approaches, buy my book. Of course, if you do a hatchet
> job on the book, I'll be on your case like a fly on shit...save where
> you are right in any important way, in which case I will help you
> write your critique and get your errata into Apress' Web site.

You need some lookahead, but a single token of lookahead should do for
most of the stuff we care about.  Scanning through the string of characters
is a bad way to do lookahead.

> Point taken. I was suspicious of the code myself since I have
> encountered that problem before. It's an artifact of the unsafe design
> of the Infantile Disorder in which I am coding.

Except it's not.  It's easy to get right, and thousands of people do.
You just have to be aware of it.

>> This should be:
>> � � � � strPolish[0] = '\0';
>> � � � � return strPolish;

> Excellent. You should turn pro.

:)

> Don't be a silly bastard. It's not a memory leak since I return to main
> () (I was tempted to return void just to piss you off but Microsoft C
> sets me up with int main()). Now you're making silly comments just to
> pad your anti-resume. Shape up.

There is a historical quirk, likely no longer relevant:  On some DOS/Windows
implementations, long ago, failing to free malloc'd memory before exiting
resulted in the memory being lost until the next reboot.

> But thanks for your observations. Not as good as Bacarisse but at
> least you jumped in and got to work, unlike your friend Heathfield,
> who's trashed so many people that he's afraid to make a mistake.

Heathfield is not afraid to make mistakes, he just doesn't very often.
He was making a point -- which is that if you want people reviewing code,
running it through a picky compiler is a great starting point.

> Furthermore, thanks to your help and my own coding and testing, I am
> ramping back up quickly in C and shall shortly, if I persist, run
> rings around you.

Good luck with that.

> Nonetheless I shall persist for now, in order to demonstrate that two
> propositions are true. One is that I'm smarter than you.

I doubt it.  It's not theoretically impossible, but it would certainly
surprise me.

> The other is
> that we can work together to find bugs in each others' code because
> nobody is too smart to make stupid mistakes, a lesson which if you
> learn well will, I hope, cause you to withdraw The Vicious Tirade.

Not really.  People do, indeed, make stupid mistakes.  The question is
whether they then try to correct them...

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/3/2009 6:18:35 PM
Seebs <usenet-nospam@seebs.net> writes:
> On 2009-11-03, spinoza1111 <spinoza1111@yahoo.com> wrote:
>> On Nov 3, 3:32 pm, Chris McDonald <ch...@csse.uwa.edu.au> wrote:
>>> spinoza1111<spinoza1...@yahoo.com> writes:
>>> Which part of the C standard do you believe links C to the year 2038?
>
>> Date precision.
>
> Uh, well, no.
>
>> Ever wonder why spam is dated 2038? Did the standards
>> fix this problem?
>
> The standard never had this problem.  Individual implementors have chosen
> different ways of representing dates; it's up to them to decide which
> representation they want.  POSIX does specify a representation in seconds
> since Jan 1 1970 UTC, but does not specify a particular limit on the size
> of the object used to store that value.

All correct.

On the other hand, if I understand the history correctly, the first
implementations to provide time_t defined it as a signed 32-bit
integer type measuring seconds since 1970-01-01.  The standard
came along later and established looser requirements that were
consistent with the existing implementations, but also allowed for
other representations (such as using a 64-bit integer, choosing an
epoch other than 1970-01-01, choosing a resolution other than one
second, and so forth).  The POSIX requirements are tighter than
the ISO C requirements, but they still allow for 64-bit integers.
(And I suspect there were a few 64-bit time_t implementations before
either standard came along.)

The standards didn't fix the problem, but they certainly allowed
for it to be fixed.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
kst-u (21963)
11/3/2009 7:59:17 PM
spinoza1111 <spinoza1111@yahoo.com> writes:

>On Nov 3, 3:32=A0pm, Chris McDonald <ch...@csse.uwa.edu.au> wrote:
>> spinoza1111<spinoza1...@yahoo.com> writes:
>> >But the more I relearn about C from experts like you, the more I
>> >wonder why this language is still in use. Perhaps it will be
>> >eradicated in 2038 as much old Cobol was eradicated to prevent Y2K,
>> >since C shall blow us all to kingdom come when its timers overflow in
>> >that year. I shall work out and not drink or smoke to see that happy
>> >day.
>>
>> Which part of the C standard do you believe links C to the year 2038?

>Date precision. Ever wonder why spam is dated 2038? Did the standards
>fix this problem?


You've missed the point (again);  answered in other people's replies.

Standards permit those evil blooksucking compiler and library
developers to avoid the problem.

-- 
Chris.
0
chris16 (579)
11/3/2009 9:59:40 PM
On Nov 4, 2:18=A0am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-11-03,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > On Nov 3, 2:39=A0am, Seebs <usenet-nos...@seebs.net> wrote:
> > I do this all the time in C Sharp, because when I call the error
> > handler I am usually preparing to return from any caller with a
> > Boolean value, and my practice, in C Sharp, is to always return true
> > or false from any method that does not otherwise return a value. Saves
> > a lot of bullshit and enables optimization, in my understanding.
>
> Be interesting to know how it "enables optimization".

Bone up on compiler optimization and tail recursion. I'm not gonna
explain it to you. Do you own Sethi Aho et al 2nd ed.?
>
> >> If this is for an error message, why isn't it using stderr for its out=
put?
> > Because there is no meaningful distinction anymore between stderr and
> > stdout, and the disctinction is legacy.
>
> Simply untrue -- there's a ton of systems out there which maintain the
> distinction clearly. =A0Again, if you're posting code that might some day
> be used or tried by other people, doing things right matters even if it
> doesn't have a discernable effect on your system. =A0There is a differenc=
e
> there, even if it doesn't affect your personal desktop.

Don't even presume to lecture me, kiddo. Your consideration for others
is on display in your treatment of Schildt.
>
> >> The double-\n thing is a bit unusual; normally a convention is adopted
> >> where messages should either end with (normally) or start with (less
> >> often) a newline, rather than providing two. =A0In particular, if ther=
e are
> >> two consecutive error messages for some reason, this would produce a b=
lank
> >> line between them.
> > Yes. I like white space.
>
> Blank lines used for emphasis are useful, blank lines which flood the dis=
play
> with blank lines just disrupt the reader's flow.

You have a disturbing tendency to lapse into sloppy English and
corporatese whenever you want to stop thinking, and when this harms
other people, it needs to stop. What on earth is "the reader's flow?"
Menstrual?
>
> >> It would seem much more useful to implement this function using ... ar=
guments
> >> and the underlying vfprintf() to allow formatted messages to be displa=
yed.
> >> If I were writing a function to this effect, I'd probably do:
> > I don't see the worth of this at this time, but I may be missing
> > something.
>
> Consider the option of writing messages like:
>
> =A0 errorHandler("syntax error: Got '%c', was expecting an operator.", s[=
i]);
>
> Basically, anything that makes it convenient and easy to give more
> specific feedback.

Haven't you run the latest edition? It does this visually on any
monospace window by putting a dollar sign under the point at which the
error is discovered...although now that I think of it, it's probably a
mistake on my part to assume monospace output.

I don't think, however, that it makes sense to overengineer this
issue, in part because what rilly needs change is the fact that
recursive descent implemented simply produces too many "nested" error
messages and is bad at error recovery.
>
> >> You prefix the variable's name with a type. =A0While that certainly CA=
N be
> >> a reasonable thing, it's important to ensure that the type used is a r=
eal
> >> abstract type, not merely a language type -- language types are alread=
y
> >> type checked.
> > Do you mean my use of Hungarian here?
>
> There are two kinds of Hungarian. =A0The kind that is actually in some wa=
y
> beneficial, which denotes abstract types, and the kind which denotes comp=
iler
> types and is demonstrably harmful. =A0You used the latter kind.
>
> >> You're using Systems Hungarian here, which is crap. =A0Don't. =A0Apps =
Hungarian
> >> is what Simonyi proposed and demonstrated to be useful. =A0Systems Hun=
garian
> >> isn't useful, and leads to bugs later.
> > This is not my experience, especially with modern editors. It doesn't
> > cause bugs unless it is not maintained. What part of strong typing
> > don't you understand?
>
> I understand strong typing just fine. =A0That's why systems hungarian is =
stupid;
> it's not actually adding any data.

No, it's organizing material for easy retrieval in a modern editor
with intellisense.


>
> Apps Hungarian would be to, say, indicate whether something is a distance
> or an index or whatever -- all things which could be stored in an int,
> but which are not interchangeable sorts. =A0Systems Hungarian is useless,
> because it just replicates stuff the compiler can already check.
>
> Interestingly, Simonyi has come out pretty strongly against the Systems
> Hungarian thing -- and given that he's the originator of Hungarian notati=
on,
> I thin kthat's pretty damning.
>

He's not the originator. "Systems Hungarian" was already in use in IBM
when he was still in Hungary helping to destroy socialism as a punk
kid who needed a kick in the ass. It is in fact mentioned in a book by
Richard Diebold published in 1962.

> > Because string.h is fucking fucked.
>
> No, it isn't.
>
> >> strlen() exists for a reason.
> > I don't choose to include libraries unnecessarily when I can write a
> > little code for the limited amount of functionality that I need.
>
> When the library is part of the core language, that attitude is stupid.
> You can't outperform the library writers, and every line of code you
> spend reinventing the wheel is wasted.

Actually, for trivial algorithms, I can.

>
> > In your view. In my view, the "library" approach of C is horseshit
> > because you get a Lot Of Useless Crap for one little function that you
> > need.
>
> Maybe, except *you already got it*. =A0You've already paid the cost, migh=
t as
> well use the stuff.

I didn't pay a dime for Microsoft C++ Express.
>
> > No, -1 is the truest true value.
>
> It may be, but it's also used widely as an out-of-band error indicator.

Yes. The confusion is here created not by me, however, but by C's lack
of a boolean type.
>
> > My understanding (let me know if it's
> > changed since 1991), zero is falseness whereas nonzero is truthiness.
> > Well, -1, on twos-complement systems, which despite your nonsense in
> > C: The Complete Nonsense are dominant, is the number least like zero
> > since it's all ones and isn't that a kiss my ass?
>
> Actually, it's not, because no one cares about the bit representation; we
> just care whether the number it represents communicates clearly to the
> user.

This is childish. "I care about all sorts of useless shit like what
main() returns but not about interpersonal decency, nor elegance I
didn't invent". You see, C lacks Boolean values, and -1 is more
visible than 1: more readable: more elegant, and, in a twos complement
system, it uses the literary technique of "evocation", for it evokes
in the intelligent code reader a vision of all ones (and it's more
visible at what we used to call core dump time, and what is now The
Time of Blue Screen of Death). Useful beauty. In your comments

Nonsense prevails, modesty fails: all this useless beauty (Elvis
Costello)
>
> >> Note that I've preserved the probable-bug, which is that if you have a=
n
> >> array of 15 characters, and you call this function with the limit 15 o=
n
> >> an array containing 14 non-zero characters and a null byte,
> >> it'll write the 16th character of the 15-character array. =A0That's al=
most
> >> always a bad choice.
> > Making sure that the only string I allocate and append to, the Polish
> > string, is on my to do. I was worried about screwing that up, but I
> > malloc'd 100 bytes for the Polish string, and none of my test cases
> > approach that length.
>
> Which is to say, it does indeed turn out that you got it wrong.

Not in any substantive way. My goal was to get something coded and see
how you behave in a structured walkthrough where owing to the written
nature of the medium, we can exclude noncontributing thugs like
Heathfield. Right now, I am not impressed, but I think you have
potential that Heathfield lacks.


>
> This is the other reason to use the library -- the library functions
> handle their boundaries correctly, in general.
>
> >> I've omitted the ridiculous error message call, for reasons which shal=
l
> >> become apparent.
> > So it's ridiculous to give a humane error message? Explain.
>
> It's not a useful message in context.

Words, my lord: words words words. But that's not the problem. "In
context" is meaningless corporatese.
>
> > Study the code a little more thoroughly. While this particular test
> > may have changed in my Nov 3 version, it was necessary in this version
> > because mulFactor in all versions must needs incorporate the functions
> > of a scanner (including testing end of input). If input has been
> > exhausted, we have entered mulFactor expecting a multiply factor and
> > there is none.
>
> But the user doesn't care about "mulFactor". =A0The user wants to know

The "user" (sigh). Sloppy English: because in a structured walkthrough
users have no place, no more than managers. You invoke "the user" as a
deus ex machina: a Lacanian phallus. But literally, that's the person
who as you say needs to be innocent of the details!

> "we reached the end of the string while expecting more input". =A0The int=
ernal
> details like "mulFactor" are not part of the user's knowledge of what

If you'd learn how to write properly, which you can't, you'd here
express this as an assertion which should always be true. My program
satisfies that assertion. Rather than quarreling about whether some
"user" (some abstract thug with money and a loud mouth) can see it, I
need to use informal or formal argumentation to prove that "there is
no input, that is not completely examined by my code, such that each
byte is scanned" (X strong) or "there is no valid input where this is
untrue" (weak X: implied by strong X).

I will provide a short informal argument to this effect in comments, a
fix to the library case problem, a new malloc scheme that will avoid
the probable bug you found, and detabbed properly formatted source by
Tue eve China time. I believe these are the only real problems you
found (that weren't corrected in the latest version I posted), and
once again as in the case of Schildt you have a disturbing tendency to
pad your attacks with opinion and trivia.

> the program is doing, and shouldn't have to be.
>
> >> Seems like this would be a great time to refactor this more sanely. =
=A0In
> >> particular, you're having the higher-level code (mulfactor) try to gue=
ss
> >> the range of the substring.
> > Yes, I said it looks ahead.
> > If it didn't it would be dead.
>
> Looking ahead like that, though, means that that function has to handle
> all sorts of hypothetical future special cases -- which is silly. =A0Just
> have the parser recurse and tell you how far it got.

Nonsense. It looks ahead for one reason alone. Again, on the related
issue of one-character lookahead cf Aho/Sethi et al. 2nd ed. p 78.
Drop the issue, you're just making a big deal out of it to show off.
>
> > At that point, I factor. Premature factorization especially for you
> > bums is in my experience a waste of time.
>
> I'm a big fan of handling at least the common cases up front.
>
> > It's not necessarily ugly to "read ahead": cf the 2nd ed. of the
> > Dragon Book, p 78. Also, see Nilges' "Build Your Own Goddamn .Net
> > Language and Goddamn Compiler" for a discussion of the need for
> > lookahead in processing unary minus and right parentheses. I worked
> > through these issues several years ago in VB, and if you care to
> > comment on my approaches, buy my book. Of course, if you do a hatchet
> > job on the book, I'll be on your case like a fly on shit...save where
> > you are right in any important way, in which case I will help you
> > write your critique and get your errata into Apress' Web site.
>
> You need some lookahead, but a single token of lookahead should do for
> most of the stuff we care about. =A0Scanning through the string of charac=
ters
> is a bad way to do lookahead.

Says who? I refer you to Nilges 2004. He recommends it.

Seriously, saying dully "ooo dat is a bad way to do wookahead" doesn't
make what you say true. Stick to what you're good at, which strangely
is C, not programming.
>
> > Point taken. I was suspicious of the code myself since I have
> > encountered that problem before. It's an artifact of the unsafe design
> > of the Infantile Disorder in which I am coding.
>
> Except it's not. =A0It's easy to get right, and thousands of people do.
> You just have to be aware of it.
>
> >> This should be:
> >> =A0 =A0 =A0 =A0 strPolish[0] =3D '\0';
> >> =A0 =A0 =A0 =A0 return strPolish;
> > Excellent. You should turn pro.
>
> :)
>
> > Don't be a silly bastard. It's not a memory leak since I return to main
> > () (I was tempted to return void just to piss you off but Microsoft C
> > sets me up with int main()). Now you're making silly comments just to
> > pad your anti-resume. Shape up.
>
> There is a historical quirk, likely no longer relevant: =A0On some DOS/Wi=
ndows
> implementations, long ago, failing to free malloc'd memory before exiting
> resulted in the memory being lost until the next reboot.

Fascinating. But useless.
>
> > But thanks for your observations. Not as good as Bacarisse but at
> > least you jumped in and got to work, unlike your friend Heathfield,
> > who's trashed so many people that he's afraid to make a mistake.
>
> Heathfield is not afraid to make mistakes, he just doesn't very often.

That's because he doesn't code. He in fact here emulates the very
worst sort of manager who sits back and destroys people in meetings
for taking risks, proposing solutions, and coding. He makes me sick,
and I want him out of here.

> He was making a point -- which is that if you want people reviewing code,
> running it through a picky compiler is a great starting point.
>
> > Furthermore, thanks to your help and my own coding and testing, I am
> > ramping back up quickly in C and shall shortly, if I persist, run
> > rings around you.
>
> Good luck with that.
>
> > Nonetheless I shall persist for now, in order to demonstrate that two
> > propositions are true. One is that I'm smarter than you.
>
> I doubt it. =A0It's not theoretically impossible, but it would certainly
> surprise me.
>
> > The other is
> > that we can work together to find bugs in each others' code because
> > nobody is too smart to make stupid mistakes, a lesson which if you
> > learn well will, I hope, cause you to withdraw The Vicious Tirade.
>
> Not really. =A0People do, indeed, make stupid mistakes. =A0The question i=
s
> whether they then try to correct them...

I don't know what you mean. Where I agree it's a stupid mistake, I
don't "try" to correct it, I just correct it. Your corporatese on the
other hand implies that the person being objectified by the language
will recognize something with the ugly name of a "behavior pattern"
which they will then, in the debased language of Human Resources, "try
to correct", where the expectation, of course, is that he or she
(having been found wanting in a secret Calvinism: a society haunted by
predestination) will fail but "we" will have done our best.

I am here, however, for your insights on code, not for any wisdom I
see in you.

>
> -s
> --
> Copyright 2009, all wrongs reversed. =A0Peter Seebach / usenet-nos...@see=
bs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny picturesht=
tp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

0
spinoza1111 (3246)
11/4/2009 3:13:50 AM
On Nov 4, 1:56=A0am, Richard Heathfield <r...@see.sig.invalid> wrote:
> In
> <cfebc09f-0b34-4de8-ab71-f309369ff...@w37g2000prg.googlegroups.com>,
>
> spinoza1111wrote:
> > On Nov 3, 2:39 am, Seebs <usenet-nos...@seebs.net> wrote:
> > > On 2009-11-02,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> <polite stuff reluctantly snipped despite its rarity value>

It's rare because when people make genuine technical remarks I respond
professionally.

Few genuine technical remarks are made here. Ben Bacarisse is by far
the best source of solid technical feedback. Seebach is just barely
acceptable since unlike Ben he doesn't organize his thoughts well and
proceeds sequentially just identifying nits. You're not even in the
running and you need to leave this discussion.

>
> >> > #define MAX_POLISH_LENGTH 100
> >> > int errorHandler(char *strMessage)
> >> > {
> >> > printf("\n%s\n", strMessage); return 0;
> >> > }
>
> >> This always returns the same value, why does it have a return value
> >> at all?
>
> > I do this all the time in C Sharp, because when I call the error
> > handler I am usually preparing to return from any caller with a
> > Boolean value, and my practice, in C Sharp, is to always return true
> > or false from any method that does not otherwise return a value.
>
> This is (close to) my practice too - in general, my functions return
> int (and the ones that don't, tend to return either void or a T* for
> some type T). Sometimes, I have no better value to return than 0
> during the development process, so return 0; goes in, awaiting more
> rigorous error handling later. Sometimes that error handling turns
> out to be unnecessary for the time being, but the return 0 stays in
> anyway, in case at some point in the future it becomes necessary to
> add error handling.
>
> <didn't read the rest - no time>
>
> --
> 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

0
spinoza1111 (3246)
11/4/2009 3:19:57 AM
On 2009-11-04, spinoza1111 <spinoza1111@yahoo.com> wrote:
> On Nov 4, 2:18�am, Seebs <usenet-nos...@seebs.net> wrote:
>> Be interesting to know how it "enables optimization".

> Bone up on compiler optimization and tail recursion. I'm not gonna
> explain it to you.

It just seems non-obvious to me that always returning a value is necessarily
better than not having to return a value.

> Do you own Sethi Aho et al 2nd ed.?

Probably.  :)

>> Simply untrue -- there's a ton of systems out there which maintain the
>> distinction clearly. �Again, if you're posting code that might some day
>> be used or tried by other people, doing things right matters even if it
>> doesn't have a discernable effect on your system. �There is a difference
>> there, even if it doesn't affect your personal desktop.

> Don't even presume to lecture me, kiddo.

You posted code, you got feedback.  :)

> Your consideration for others
> is on display in your treatment of Schildt.

I would never *dream* of giving you advice based on the theory that you were
interested in showing consideration for others.  I'm telling you how to reduce
the likelihood that people will think you're an idiot.  You can pursue that
out of pure self interest, no worries!

> You have a disturbing tendency to lapse into sloppy English and
> corporatese whenever you want to stop thinking, and when this harms
> other people, it needs to stop.

Corporatese?  I don't think so.

> What on earth is "the reader's flow?"

People performing tasks such as "reading diagnostic messages" or "skimming
output from code" tend to perform them more reliably and more quickly when
the format and structure of the material is conducive to maintaining a
state called "flow".

http://www.eric.ed.gov/ERICWebPortal/custom/portlets/recordDetails/detailmini.jsp?_nfpb=true&_&ERICExtSearch_SearchValue_0=EJ525775&ERICExtSearch_SearchType_0=no&accno=EJ525775

Basic familiarity with the literature:  Always a plus.

> Haven't you run the latest edition?

These comments were all on the original edition.  You asked what benefit
a format string might have, I gave an example.

> It does this visually on any
> monospace window by putting a dollar sign under the point at which the
> error is discovered...although now that I think of it, it's probably a
> mistake on my part to assume monospace output.

Not an unreasonable one, though.

> No, it's organizing material for easy retrieval in a modern editor
> with intellisense.

It still doesn't work.

> He's not the originator. "Systems Hungarian" was already in use in IBM
> when he was still in Hungary helping to destroy socialism as a punk
> kid who needed a kick in the ass. It is in fact mentioned in a book by
> Richard Diebold published in 1962.

Perhaps, but he's the reason people mostly adopted it -- and while Systems
Hungarian may well have been useful in 1962, it's been worthless since the
80s or so in nearly all languages.

>> When the library is part of the core language, that attitude is stupid.
>> You can't outperform the library writers, and every line of code you
>> spend reinventing the wheel is wasted.

> Actually, for trivial algorithms, I can.

Probably not for this one.  (If you're on x86, for instance, consider
that there's a single instruction for this operation, which is likely to
get used if it's a good fit.  There's a reason compilers often have built-in
implementations of common library functions.)

>> > In your view. In my view, the "library" approach of C is horseshit
>> > because you get a Lot Of Useless Crap for one little function that you
>> > need.

>> Maybe, except *you already got it*. �You've already paid the cost, might as
>> well use the stuff.

> I didn't pay a dime for Microsoft C++ Express.

No one said you did.  I was referring to the "Lot Of Useless Crap".  You
already got the Lot Of Useless Crap.  It's there.  You might as well use
it.

> Yes. The confusion is here created not by me, however, but by C's lack
> of a boolean type.

One of the things that fluent speakers learn is that beyond the raw formal
lexicon of a language, it will usually have idioms.  C has had idioms for
true and false since 1978, and it would make sense to stick with those
idioms.  (Or, if you prefer, you could always use the boolean type, since
there is one in C99.)

> This is childish. "I care about all sorts of useless shit like what
> main() returns but not about interpersonal decency, nor elegance I
> didn't invent".

Oh, I'm all for elegance, regardless of who invented it, but -1 isn't
elegant.

> You see, C lacks Boolean values,

Not since 1999 it doesn't.  :)

But even in 1978... Let's consider the question.

If we are to define "false" and "true", what should they be?

Obviously:

	if (false) {
	}

should not execute the contents of the block.  How about... 0?

Okay.  So what's true?  "!false" is true.  What's !0?  1.  true is 1.

> and -1 is more
> visible than 1: more readable: more elegant, and, in a twos complement
> system, it uses the literary technique of "evocation", for it evokes
> in the intelligent code reader a vision of all ones (and it's more
> visible at what we used to call core dump time, and what is now The
> Time of Blue Screen of Death).

Your continued assertions that you are the gold standard of the "intelligent
reader" are unsupported.

However, it gets a bit deeper than that.

There are many functions and APIs which have standardized on using negative
values to indicate *errors*.  Because of this, readers who are experienced
with C will usually regard a "-1" as an error indicator.  Your theory that it
would make sense for it to be regarded as a particularly idiomatic "true"
is fascinating, but it doesn't match the real world.

>> Which is to say, it does indeed turn out that you got it wrong.

> Not in any substantive way.

Your code has a buffer overrun that exists because you didn't pay attention
to the well-established idioms that allow experienced programmers to avoid
buffer overruns.

That's pretty substantive.

> My goal was to get something coded and see
> how you behave in a structured walkthrough

Ahh, that won't happen.  I'm not about to put real effort into this stuff.
I view you as an amusing kook, no more.  The moment I saw multiple responses
from you continuing to assert your tinfoil hat theory about how the
standards process worked, without even ONE bit of supporting evidence, I
gave up.  I have not taken you seriously since, nor do I now.

> Words, my lord: words words words. But that's not the problem. "In
> context" is meaningless corporatese.

No, it isn't.

It's odd, because you keep talking about what users would expect, but you
appear to have carefully avoided learning anything about how users form
their expectations.

>> But the user doesn't care about "mulFactor". �The user wants to know

> The "user" (sigh). Sloppy English: because in a structured walkthrough
> users have no place, no more than managers. You invoke "the user" as a
> deus ex machina: a Lacanian phallus. But literally, that's the person
> who as you say needs to be innocent of the details!

Lots of handwaving, but you haven't addressed the point.  The purpose of the
code is to be used.  The person using it does not care about the internal
implementation; that person's sole interest is to get an infix expression
converted to RPN, for reasons we are not privileged to speculate on.  :)

> If you'd learn how to write properly, which you can't,

*snicker*

Bored now, gonna go change the litterbox.

I was hoping you'd stay fun longer, but you've actually really dropped off
in hilarity lately, such that I'd rather go deal with trash night.  (One of
the few holidays nearly all Americans still revere.)

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/4/2009 3:43:31 AM
On 3 Nov, 16:26, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Nov 3, 3:32=A0pm, Chris McDonald <ch...@csse.uwa.edu.au> wrote:
>
> > spinoza1111<spinoza1...@yahoo.com> writes:
> > >But the more I relearn about C from experts like you, the more I
> > >wonder why this language is still in use. Perhaps it will be
> > >eradicated in 2038 as much old Cobol was eradicated to prevent Y2K,
> > >since C shall blow us all to kingdom come when its timers overflow in
> > >that year. I shall work out and not drink or smoke to see that happy
> > >day.
>
> > Which part of the C standard do you believe links C to the year 2038?
>
> Date precision.

sentence no verb

> Ever wonder why spam is dated 2038?

is it?

> Did the standards fix this problem?

what problem?

I'll repeat the question "Which part of the C standard do you believe
links C to the year 2038?". Hint, C is not Unix.
0
11/4/2009 8:29:58 AM
In article <96bcce10-b381-4dfe-8a43-a562f312065b@e4g2000prn.googlegroups.com>,
spinoza1111  <spinoza1111@yahoo.com> wrote:
>Ever wonder why spam is dated 2038?

In a sample of 30,952 spam messages, I found none dated 2038.

-- Richard
-- 
Please remember to mention me / in tapes you leave behind.
0
richard91 (3692)
11/4/2009 9:38:30 AM
In <f95734c9-355d-417d-a18b-522a787437eb@x5g2000prf.googlegroups.com>, 
spinoza1111 wrote:

> On Nov 4, 1:56 am, Richard Heathfield <r...@see.sig.invalid> wrote:
>> In
>> 
<cfebc09f-0b34-4de8-ab71-f309369ff...@w37g2000prg.googlegroups.com>,
>>
>> spinoza1111wrote:
>> > On Nov 3, 2:39 am, Seebs <usenet-nos...@seebs.net> wrote:
>> > > On 2009-11-02,spinoza1111<spinoza1...@yahoo.com> wrote:
>>
>> <polite stuff reluctantly snipped despite its rarity value>
> 
> It's rare because when people make genuine technical remarks I
> respond professionally.

That has not been my experience of you.

-- 
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
0
rjh (10791)
11/4/2009 10:22:30 AM
On Nov 4, 6:22=A0pm, Richard Heathfield <r...@see.sig.invalid> wrote:
> In <f95734c9-355d-417d-a18b-522a78743...@x5g2000prf.googlegroups.com>,
>
> spinoza1111wrote:
> > On Nov 4, 1:56 am, Richard Heathfield <r...@see.sig.invalid> wrote:
> >> In
>
> <cfebc09f-0b34-4de8-ab71-f309369ff...@w37g2000prg.googlegroups.com>,
>
>
>
> >> spinoza1111wrote:
> >> > On Nov 3, 2:39 am, Seebs <usenet-nos...@seebs.net> wrote:
> >> > > On 2009-11-02,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> >> <polite stuff reluctantly snipped despite its rarity value>
>
> > It's rare because when people make genuine technical remarks I
> > respond professionally.
>
> That has not been my experience of you.

You rarely make genuine technical remarks, dear boy. Complaining about
test questions, repeating saws, maxims, and folk-lore, and trashing
people online don't count, my dear fellow,
>
> --
> 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

0
spinoza1111 (3246)
11/4/2009 1:38:27 PM
In article <3aa2d9aa-c423-411a-a20a-c075fba67c4e@j9g2000prh.googlegroups.com>,
spinoza1111  <spinoza1111@yahoo.com> explained Petey's behavior thusly:
....
>> > It's rare because when people make genuine technical remarks I
>> > respond professionally.
>>
>> That has not been my experience of you.
>
>You rarely make genuine technical remarks, dear boy. Complaining about
>test questions, repeating saws, maxims, and folk-lore, and trashing
>people online don't count, my dear fellow,

So obvious.  So true.  And yet, Petey will come along any second now and
issue a denial.

0
gazelle3 (1726)
11/4/2009 1:56:32 PM
In <3aa2d9aa-c423-411a-a20a-c075fba67c4e@j9g2000prh.googlegroups.com>, 
spinoza1111 wrote:

<snip>
 
> You rarely make genuine technical remarks,

Like most of your assertions, you have failed to provide evidence to 
support this one.

Go clean your code up so that it compiles at a decent warning level 
without making the compiler want to vomit. Then I'll be happy to 
provide some *more* technical feedback.

-- 
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
0
rjh (10791)
11/4/2009 2:21:02 PM
On Nov 4, 11:43=A0am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-11-04,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > On Nov 4, 2:18=A0am, Seebs <usenet-nos...@seebs.net> wrote:
> >> Be interesting to know how it "enables optimization".
> > Bone up on compiler optimization and tail recursion. I'm not gonna
> > explain it to you.
>
> It just seems non-obvious to me that always returning a value is necessar=
ily
> better than not having to return a value.
>
> > Do you own Sethi Aho et al 2nd ed.?
>
> Probably. =A0:)

Oh great, so you haven't opened it.
>
> >> Simply untrue -- there's a ton of systems out there which maintain the
> >> distinction clearly. =A0Again, if you're posting code that might some =
day
> >> be used or tried by other people, doing things right matters even if i=
t
> >> doesn't have a discernable effect on your system. =A0There is a differ=
ence
> >> there, even if it doesn't affect your personal desktop.
> > Don't even presume to lecture me, kiddo.
>
> You posted code, you got feedback. =A0:)

I'm not complaining. You are. You need to use Ben Bacarisse as a role
model. If you have technical insight, share it. Shove your corporatese
and generalizations about people's competence (whether Schildt's,
Navia's, or mine), up your ass, because this medium simply isn't one
where you have a broad enough signal to make the online judgements you
make on Navia and I, and you were out of line with Schildt because you
don't know Microsoft platforms.

Schildt is weak on non-Microsoft and should not have used upper case
file names in #include statements for this reason. But for the same
reason, you weren't qualified to tech review his book. What is worse,
you enabled a series of personal attacks because you only published 20
flaws, but made references to hundreds, which you have not, as far as
I can see, documented.
>
> > Your consideration for others
> > is on display in your treatment of Schildt.
>
> I would never *dream* of giving you advice based on the theory that you w=
ere
> interested in showing consideration for others. =A0I'm telling you how to=
 reduce
> the likelihood that people will think you're an idiot. =A0You can pursue =
that
> out of pure self interest, no worries!

I have plenty of consideration for others, but unlike a feminized
corporate dweeb "this animal defends itself when attacked".

>
> > You have a disturbing tendency to lapse into sloppy English and
> > corporatese whenever you want to stop thinking, and when this harms
> > other people, it needs to stop.
>
> Corporatese? =A0I don't think so.

I do. When you are at a loss for enough to say technically you venture
without warning into abstractions with which you're not qualified to
deal. For example, your claim that Schildt somehow made software
incorrect by publishing a book is nonsense, because what makes
software incorrect is the refusal of technicians to abandon C.
>
> > What on earth is "the reader's flow?"
>
> People performing tasks such as "reading diagnostic messages" or "skimmin=
g
> output from code" tend to perform them more reliably and more quickly whe=
n
> the format and structure of the material is conducive to maintaining a
> state called "flow".

No shit, Dick Tracy. Have you ever heard about the use of white space
in technical writing?
>
> http://www.eric.ed.gov/ERICWebPortal/custom/portlets/recordDetails/de...
>
> Basic familiarity with the literature: =A0Always a plus.
>
> > Haven't you run the latest edition?
>
> These comments were all on the original edition. =A0You asked what benefi=
t
> a format string might have, I gave an example.
>
> > It does this visually on any
> > monospace window by putting a dollar sign under the point at which the
> > error is discovered...although now that I think of it, it's probably a
> > mistake on my part to assume monospace output.
>
> Not an unreasonable one, though.
>
> > No, it's organizing material for easy retrieval in a modern editor
> > with intellisense.
>
> It still doesn't work.

Corporatese, because a naming standard doesn't work or fail. It is
usable or otherwise. Learn to write before you write another document
that trashes a decent person's career, punk.

>
> > He's not the originator. "Systems Hungarian" was already in use in IBM
> > when he was still in Hungary helping to destroy socialism as a punk
> > kid who needed a kick in the ass. It is in fact mentioned in a book by
> > Richard Diebold published in 1962.
>
> Perhaps, but he's the reason people mostly adopted it -- and while System=
s
> Hungarian may well have been useful in 1962, it's been worthless since th=
e
> 80s or so in nearly all languages.

Your laziness doesn't control. I find Systems Hungarian easy to
maintain. I also find that most programmers are too lazy to maintain
another's naming standards. Systems Hungarian was abandoned out of
laziness. Szymonyi was told how to name variables at IBM but went his
own way, stealing the idea and taking credit for it.


>
> >> When the library is part of the core language, that attitude is stupid=
..
> >> You can't outperform the library writers, and every line of code you
> >> spend reinventing the wheel is wasted.
> > Actually, for trivial algorithms, I can.
>
> Probably not for this one. =A0(If you're on x86, for instance, consider
> that there's a single instruction for this operation, which is likely to
> get used if it's a good fit. =A0There's a reason compilers often have bui=
lt-in
> implementations of common library functions.)

When I see the need, I'll use assembler to get the instruction. The
legacy C libraries are too full of gotchas to be worth the trouble in
the case of strings. If I were to use C for a "real" project, first
thing I'd do would be to reinvent strings.
>
> >> > In your view. In my view, the "library" approach of C is horseshit
> >> > because you get a Lot Of Useless Crap for one little function that y=
ou
> >> > need.
> >> Maybe, except *you already got it*. =A0You've already paid the cost, m=
ight as
> >> well use the stuff.
> > I didn't pay a dime for Microsoft C++ Express.
>
> No one said you did. =A0I was referring to the "Lot Of Useless Crap". =A0=
You
> already got the Lot Of Useless Crap. =A0It's there. =A0You might as well =
use
> it.

Can I quote you as you misrepresent Schildt? Peter Seebach says, use
Useless Crap.

(Chortle)
>
> > Yes. The confusion is here created not by me, however, but by C's lack
> > of a boolean type.
>
> One of the things that fluent speakers learn is that beyond the raw forma=
l
> lexicon of a language, it will usually have idioms. =A0C has had idioms f=
or
> true and false since 1978, and it would make sense to stick with those
> idioms. =A0(Or, if you prefer, you could always use the boolean type, sin=
ce
> there is one in C99.)

I'd rather use C Sharp.
>
> > This is childish. "I care about all sorts of useless shit like what
> > main() returns but not about interpersonal decency, nor elegance I
> > didn't invent".
>
> Oh, I'm all for elegance, regardless of who invented it, but -1 isn't
> elegant.

I don't think you know what elegance is. For starters elegance is
conceptual unity, and for this reason I have always been sickened by
discussions among programmers, with their consistent misuse of
language ("language x isn't efficient, but language y is"). Right up
there is having to argue with some dweeb about whether a snippet is
elegant out of context. As it happened, it was best for me in my
limited time, simply to show that this conversion could be grammar-
driven, to use -1 as truthiness.

I am so glad not to be a programmer anymore, because programmers don't
realize that while a guy like Dijkstra was indeed concerned with
elegance of coding languages, what he meant was integrated syntax and
semantics, and would probably regard it as silly to waste a person's
time criticising -1 as truthiness.

Also, while you yourself have not demonstrated the willingness or
ability to post code extempore, you probably excuse your own stylistic
and technical failings by calling new code throwaway, while acting as
if others only have the right here to post bug free code...a common
failing of the twerps here. I come here for your feedback on technical
matters on C exclusively because as I have said you appear to me to
know C while having much to learn about programming.
>
> > You see, C lacks Boolean values,
>
> Not since 1999 it doesn't. =A0:)
>
> But even in 1978... Let's consider the question.
>
> If we are to define "false" and "true", what should they be?
>
> Obviously:
>
> =A0 =A0 =A0 =A0 if (false) {
> =A0 =A0 =A0 =A0 }
>
> should not execute the contents of the block. =A0How about... 0?
>
> Okay. =A0So what's true? =A0"!false" is true. =A0What's !0? =A01. =A0true=
 is 1.

Wow, I'll alert the media. 1=3D=3D!0? New math indeed.

You wouldn't say this if you had in the past to debug at machine code
level, because 1 looks too much like  0 to be a good way to represent
truthiness. -1 is best.

>
> > and -1 is more
> > visible than 1: more readable: more elegant, and, in a twos complement
> > system, it uses the literary technique of "evocation", for it evokes
> > in the intelligent code reader a vision of all ones (and it's more
> > visible at what we used to call core dump time, and what is now The
> > Time of Blue Screen of Death).
>
> Your continued assertions that you are the gold standard of the "intellig=
ent
> reader" are unsupported.
>
> However, it gets a bit deeper than that.
>
> There are many functions and APIs which have standardized on using negati=
ve
> values to indicate *errors*. =A0Because of this, readers who are experien=
ced
> with C will usually regard a "-1" as an error indicator. =A0Your theory t=
hat it
> would make sense for it to be regarded as a particularly idiomatic "true"
> is fascinating, but it doesn't match the real world.

I don't have to follow broken standards. I am very familiar, from
longer experience than you, that in many situations 0 means "all
clear". This is an unfortunate problem because in other contexts, it
means false.

The problem is not using -1 for truthiness. It is that globally, C is
a broken language that fosters bad practices, buggy code, personality
dysfunction, and the politics of personal destruction when people
scapegoat others for their refusal to use a safer language.


>
> >> Which is to say, it does indeed turn out that you got it wrong.
> > Not in any substantive way.
>
> Your code has a buffer overrun that exists because you didn't pay attenti=
on
> to the well-established idioms that allow experienced programmers to avoi=
d
> buffer overruns.

Well, sure, if I were in a C workgroup (not if hell froze over, but
let's suppose) then I would use my coworker's idioms which, no matter
what you believe, vary all over the map because C IS BROKEN. As it
happens, in the code you reviewed, there probably is an off by one
situation which I fixed this evening in code not ready for release.

FYI, this evening, I changed the malloc to malloc exactly n bytes
where n is the total number of characters in the infix expression that
aren't blanks or parentheses to see my append test FAIL (properly)
because I am now appending more than the allocated number of bytes,
less one for the Silly Assed Null, whereas earlier I'd allocated far
too many bytes.

Which was actually a good thing, because I realized in bantering with
you that I needed to make sure that append failed correctly!

It now (at this minute) fails all the time, because I "forgot" that I
ALSO add extra blanks around output tokens, and these weren't
accounted for.

If I were outputting infix, I would simply not output blanks, but
blanks are necessary in suffix because operands can be adjacent in
suffix.

The most elegant solution would be to only insert a blank where
necessary but this would require the routine which runs before parsing
and counts outputting characters to know when in the output two
operands would be adjacent. I believe that this would be when they are
separated in the infix by a binary operator.

This might complicate the pre-scan, and another less optimal solution
would simply to request twice the bytes needed from malloc, an
inelegant solution indeed.

The point being I shall think this true
Without, in all probability, any help from you.


>
> That's pretty substantive.
>
> > My goal was to get something coded and see
> > how you behave in a structured walkthrough
>
> Ahh, that won't happen. =A0I'm not about to put real effort into this stu=
ff.

No, you prefer to shit all over a person and leave. As you did to
Schildt. You want sympathy for being autistic without taking
responsibility for the fact that autistic people are very bad at
understanding other minds...and have no standing when assessing the
knowledge of a Schildt, which you nonetheless do.


> I view you as an amusing kook, no more. =A0The moment I saw multiple resp=
onses

Fuck you, asshole. I am nothing of the kind. I am an experienced
programmer with thirty years of experience who left in the field in
disgust when it was taken over by autistic twerps.

> from you continuing to assert your tinfoil hat theory about how the
> standards process worked, without even ONE bit of supporting evidence, I
> gave up. =A0I have not taken you seriously since, nor do I now.
>
> > Words, my lord: words words words. But that's not the problem. "In
> > context" is meaningless corporatese.
>
> No, it isn't.
>
> It's odd, because you keep talking about what users would expect, but you
> appear to have carefully avoided learning anything about how users form
> their expectations.
>

Users? I don't use the word.

> >> But the user doesn't care about "mulFactor". =A0The user wants to know
> > The "user" (sigh). Sloppy English: because in a structured walkthrough
> > users have no place, no more than managers. You invoke "the user" as a
> > deus ex machina: a Lacanian phallus. But literally, that's the person
> > who as you say needs to be innocent of the details!
>
> Lots of handwaving, but you haven't addressed the point. =A0The purpose o=
f the
> code is to be used. =A0The person using it does not care about the intern=
al
> implementation; that person's sole interest is to get an infix expression
> converted to RPN, for reasons we are not privileged to speculate on. =A0:=
)

This is just wrong. For one thing, this "user" has to know, not
whether the code is "correct" (for in fact all code is "incorrect" in
the absolute sense that a computer is ultimately a finite state
automaton) but its limitations, and in this case and many others, this
"user" (I prefer "caller") would rather read the code. And note that
despite this, this "user" does not, in fact, give a rat's ass that the
code uses -1 to signal truthiness, since the code returns a string.

And you also failed, now that I think of it, to realize that
infix2Polish should NOT free() this string: it is the caller's
responsibility to free() it. Yet you added this to your Vicious Tirade
with the same lack of diligence you showed in "C: the Complete
Nonsense".

Yes, main() should: but you did not say this because as in the Vicious
Tirade you did not make constructive suggestions. Had you done so,
McGraw Hill might not have treated you like a joke.

Why is it when I submitted a proposal to O'Reilly in 1999, it was
accepted? Why is it when I contacted Apress in 2001 I was invited to
write a book? Why is it I get stuff published, whereas you failed to
get an errata published? Why did my 13 year old get errata published
and not you?

It's because you were destructive and had no insight as to what was
going on.

You should have done your homework as I did when I taught IBM
mainframe C at Transunion. I had enough familiarity from Princeton and
Bell-Northern to be able to describe the culture of C, including its
case sensitivity and use of ASCII in place of EBCDIC. Whereas you
attacked Schildt without having any experience, as far as I can see,
on his platforms.

You had no standing, and this is why McGraw Hill rejected you. You
were the crazy man with the tinfoil hat. The problem is that the
Internet empowers creeps like you to sound authoritative, because it
confuses pointers to facts with facts.

Withdraw "C: The Complete Nonsense". Apologize publically to Herb. And
here, do not presume ever again to advise me on scientific or
stylistic issues. Confine your comments to your area of competence,
which is C.
>
> > If you'd learn how to write properly, which you can't,
>
> *snicker*
>
> Bored now, gonna go change the litterbox.
>
> I was hoping you'd stay fun longer, but you've actually really dropped of=
f
> in hilarity lately, such that I'd rather go deal with trash night. =A0(On=
e of
> the few holidays nearly all Americans still revere.)


>
> -s
> --
> Copyright 2009, all wrongs reversed. =A0Peter Seebach / usenet-nos...@see=
bs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny picturesht=
tp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

0
spinoza1111 (3246)
11/4/2009 2:44:34 PM
On 2009-11-04, spinoza1111 <spinoza1111@yahoo.com> wrote:
> Oh great, so you haven't opened it.

I dunno, my memory's crap.  I can't remember which books I've read.

But I don't see you advancing any argument that always moving data is
necessarily more efficient than not always moving data.

>> You posted code, you got feedback. �:)

> I'm not complaining. You are.

Uh, actually, you're complaining.  You were claiming that my behavior
didn't meet your needs.

> You need to use Ben Bacarisse as a role model.

While I certainly don't dispute that he'd be a plausible one, I am
not much for role models.

> If you have technical insight, share it.

Why, certainly!  Thank you for your permission.  :P

> Shove your corporatese

You keep using this word, I do not think it means what you think it means.

> and generalizations about people's competence (whether Schildt's,
> Navia's, or mine), up your ass, because this medium simply isn't one
> where you have a broad enough signal to make the online judgements you
> make on Navia and I,

I don't recall having made any particular judgements about Navia.  I have
enough data to state confidently that you don't know what you're talking
about, as widely demonstrated across several different (though related)
fields of inquiry.

> and you were out of line with Schildt because you
> don't know Microsoft platforms.

First off, several of his claims were false even there.

Secondly, if he wanted to write a book called "C for Microsoft Platforms Only:
The Incomplete Reference With A Few Errors To Make Sure You Are Staying On
Your Toes", I have every confidence that it would be well-received.

> Schildt is weak on non-Microsoft and should not have used upper case
> file names in #include statements for this reason.

No, he shouldn't have used them because *they are never in any way a
better choice*.  They don't make anything work that otherwise wouldn't.

Your inability to grasp this point astounds me.  The question is not
one where there's a tradeoff.  Covering the far/huge memory model crap?
Perfectly reasonable, because it's going to be useful to people on a common
platform.  Note:  *It offers them a benefit they cannot have by doing
things the standard way*.  Using uppercase letters for headers specified
as lowercase?  Stupid, *because it does not offer any benefit*.

> But for the same
> reason, you weren't qualified to tech review his book.

As long as it claims to cover ANSI C, rather than DOS/Windows-only, I am.

> What is worse,
> you enabled a series of personal attacks because you only published 20
> flaws, but made references to hundreds, which you have not, as far as
> I can see, documented.

So what?  Plenty of other people have pointed out flaws, and there are plenty
more.  A representative sample is more useful.

> I have plenty of consideration for others, but unlike a feminized
> corporate dweeb "this animal defends itself when attacked".

So does my cat, albeit more effectively.

>> Corporatese? �I don't think so.

> I do.

Of course you do.  But you can't actually, say, justify or support
that point.

> When you are at a loss for enough to say technically you venture
> without warning into abstractions with which you're not qualified to
> deal.

Wait, that's not a telepathy helmet, it's a mirror!

> For example, your claim that Schildt somehow made software
> incorrect by publishing a book is nonsense, because what makes
> software incorrect is the refusal of technicians to abandon C.

Even if we grant (despite the lack of support or evidence from you)
the theoretical notion that C is a source of errors, it's still noticeable
that those errors are exacerbated by people trying to learn from Schildt,
and mitigated by people trying to learn from other authors.

> No shit, Dick Tracy. Have you ever heard about the use of white space
> in technical writing?

Yes.

Keep in mind, unless you've got more books out there, I've done 2-5 times
as much technical writing as you have.  White space?  A good thing *used
intelligently*.  Double-spacing paragraph text would not be a good thing.
Large spaces between members of lists, also not good.

> Corporatese, because a naming standard doesn't work or fail. It is
> usable or otherwise.

A naming standard presumably has goals.  The goals given for Hungarian
notation are not met by Systems Hungarian.  Therefore, it does not work.

> Learn to write before you write another document
> that trashes a decent person's career, punk.

Good thought.  I'll just zip back in my time machine and tell my earlier self
to start learning to write seriously five or ten years ago... oh, wait, he
already did.  Lucky that, I think my time machine's batteries are low, and
I haven't got a steam locomotive or a thunderstorm anyway.

> Your laziness doesn't control.

But your incompetence does.

> I find Systems Hungarian easy to maintain.

It certainly can be, but it is COMPLETELY WORTHLESS.

> I also find that most programmers are too lazy to maintain
> another's naming standards. Systems Hungarian was abandoned out of
> laziness.

No, it was abandoned because it is COMPLETELY WORTHLESS (in a strongly-typed
language).

> Szymonyi was told how to name variables at IBM but went his
> own way, stealing the idea and taking credit for it.

Have you ever gone five minutes without inventing a conspiracy theory
involving people stealing, lying, and cheating?

> When I see the need, I'll use assembler to get the instruction. The
> legacy C libraries are too full of gotchas to be worth the trouble in
> the case of strings.

Only they're not, at least, not for strlen().

Basic familiarity with the tools is a prerequisite for coding effectively.

> If I were to use C for a "real" project, first
> thing I'd do would be to reinvent strings.

Badly.

Yes, we already saw that your first idea was to make something which
carefully checked the limits for an append -- incorrectly.  That's not
encouraging.

> Can I quote you as you misrepresent Schildt?

That's a philosophical question, since you've never shown that I've
misrepresented Schildt at all.  You've come up with some incredible
and elaborate reinterpretations of his writing, ignored entire arguments,
and then lied about the rest, but you've never actually shown anything
about what he actually said or what I said about it.

>> One of the things that fluent speakers learn is that beyond the raw formal
>> lexicon of a language, it will usually have idioms. �C has had idioms for
>> true and false since 1978, and it would make sense to stick with those
>> idioms. �(Or, if you prefer, you could always use the boolean type, since
>> there is one in C99.)

> I'd rather use C Sharp.

Please do.  C has a problem with an undeserved bad reputation because
shitty programmers insist on using it then blaming the language for their
inability to learn to do simple things.

> I don't think you know what elegance is.

Oh, of course not.

> Also, while you yourself have not demonstrated the willingness or
> ability to post code extempore, you probably excuse your own stylistic
> and technical failings by calling new code throwaway, while acting as
> if others only have the right here to post bug free code...

Who said that?  Correcting code doesn't mean the poster didn't have the
right to post it, only that it had an error of some sort.

A lot of my code is sorta dodgy, certainly.  That's one of the reasons
I hang out and look at code; to try to learn more.

> You wouldn't say this if you had in the past to debug at machine code
> level,

Sure I would.

> because 1 looks too much like  0 to be a good way to represent
> truthiness. -1 is best.

Nope.  You're still wrong, and no amount of making excuses is gonna change
it.

In C, the canonically-true value is 1, not -1.  -1 indicates an error.

You're acting like one of those foreigners who picked up a bit of a language
from a phrase book, and is now arguing with the native speakers that they're
pronouncing it wrong and don't have their idioms right.

> I don't have to follow broken standards.

You don't, but if you don't follow a standard merely because you think
it's broken, you're going to be useless as a contributor to any project
that will ever involve other people.

> The problem is not using -1 for truthiness. It is that globally, C is
> a broken language that fosters bad practices, buggy code, personality
> dysfunction, and the politics of personal destruction when people
> scapegoat others for their refusal to use a safer language.

That's interesting, because you're the person here who writes buggy code
and indulges in ceaseless personal attacks.  It seems to me that you're
projecting your own pre-existing failings on C.

> Well, sure, if I were in a C workgroup (not if hell froze over, but
> let's suppose) then I would use my coworker's idioms which, no matter
> what you believe, vary all over the map because C IS BROKEN.

You keep saying C is broken, but other people don't seem to be having
the problems you do.

> You want sympathy for being autistic

No, I don't.

> without taking
> responsibility for the fact that autistic people are very bad at
> understanding other minds...

You might consider learning about things from sources other than movies
and television.

Autistic people are not necessarily always bad at understanding other minds,
and have noticeable advantages in doing so.  Specifically, not being
constrained to accept the instinctive heuristics of the brain as Revealed
Truth.  Big win, there.

> and have no standing when assessing the
> knowledge of a Schildt, which you nonetheless do.

Knowledge is easily assessed when looking at a book someone wrote on a topic.

>> I view you as an amusing kook, no more.

> Fuck you, asshole. I am nothing of the kind.

You have been ranting for almost two years about the Schildt thing.
What we know so far:
* You demonstrate no familiarity, at all, with the contents of his books
  about C.
* You consistently misunderstand basic features of C.
* You make a broad range of claims about the standardization process, none
  of which you have presented ANY evidence for.
* You contradict yourself freely.

In short, you behave as though you are a complete nutter.

> I am an experienced
> programmer with thirty years of experience who left in the field in
> disgust when it was taken over by autistic twerps.

It's a wonderful thing to know that you are totally above the sort
of personal attacks and character assassination you so decry.  :)

>> The moment I saw multiple responses
>> from you continuing to assert your tinfoil hat theory about how the
>> standards process worked, without even ONE bit of supporting evidence, I
>> gave up.  I have not taken you seriously since, nor do I now.

.... and this still stands.

You haven't actually supported any of your claims, but you keep making
them.

>> It's odd, because you keep talking about what users would expect, but you
>> appear to have carefully avoided learning anything about how users form
>> their expectations.

> Users? I don't use the word.

That's nice.

> This is just wrong.

It's nice that you think that, but your handwaving and use of scare
quotes are not an argument.

> And you also failed, now that I think of it, to realize that
> infix2Polish should NOT free() this string: it is the caller's
> responsibility to free() it.

You can define those responsibilities however you want.

> Yes, main() should: but you did not say this because as in the Vicious
> Tirade you did not make constructive suggestions.

I made a number of constructive suggestions in regard to your sample code,
but I didn't try to catch everything; it stopped being interesting.

> Had you done so,
> McGraw Hill might not have treated you like a joke.

You keep referring to this hypothetical event, but it never happened.

> Why is it when I submitted a proposal to O'Reilly in 1999, it was
> accepted?

I don't know, maybe it was a plausible-looking proposal?  I suspect that
this was before your current incarnation as a Usenet troll.

> Why is it when I contacted Apress in 2001 I was invited to
> write a book?

Again, maybe you had a nice proposal?

> Why is it I get stuff published, whereas you failed to
> get an errata published?

I did not try to get an errata published.  I contacted a publisher to
state that one of their books had a disturbingly large number of errors.
They offered me a small amount of money to do a technical review.  At the
time, I thought the amount of money was too small, so I turned them down.

> Why did my 13 year old get errata published
> and not you?

Possibly he submitted errata, and I didn't?

> It's because you were destructive and had no insight as to what was
> going on.

No, it's because I never submitted errata.  Sort of a key point, that.

> You should have done your homework as I did when I taught IBM
> mainframe C at Transunion. I had enough familiarity from Princeton and
> Bell-Northern to be able to describe the culture of C, including its
> case sensitivity and use of ASCII in place of EBCDIC. Whereas you
> attacked Schildt without having any experience, as far as I can see,
> on his platforms.

The book was not sold as being platform-specific -- and in any event, the
bulk of the complaints were not platform-specific.

> You had no standing, and this is why McGraw Hill rejected you.

Except, again, they didn't.

> Withdraw "C: The Complete Nonsense".

Not until you show it to be incorrect, rather than merely not as well written
as it would be if I did it again today.

> Apologize publically to Herb.

Not unless you show that I was actualy wrong.  Not merely "acting according
to different priorities than some random guy on the internet".  Show that the
FACTS were wrong, or shut up.

> And here, do not presume ever again to advise me on scientific or
> stylistic issues.

No.

> Confine your comments to your area of competence, which is C.

I'll comment on anything I feel like, in my areas, plural, of competence --
which include C, shell, some other languages, and general issues of
programming style.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/4/2009 4:47:43 PM
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Seebs <usenet-nospam@seebs.net> writes:
>
>> On 2009-11-03, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>> typedef struct string string;
>>
>> I don't like the name "string" for this.  The term "string" is pretty
>> well defined in C, and I think this has real potential to confuse
>> readers in a larger program.
>
> I dithered about that.  In the end, since it is used only on this
> program, the name was just about OK.

Erm, but doesn't it tromp on reserved namespace? 

>>>           size_t new_cap = s->capacity * 3 / 2 + 8;
vs.
>   size_t new_cap = s->capacity ? 2 * s->capacity : 8;

Measure? Having said that, surely some applications prefer 
slower increments, and your measurements of time and wastage
might well be completely misaligned with others'. I'm pretty 
sure the measurements have already been done - the C++ standard
library probably has a reasonable corpus backing it up.

Sleep-deprived, but still just able to type, 
Phil
-- 
Any true emperor never needs to wear clothes. -- Devany on r.a.s.f1
0
11/4/2009 8:01:40 PM
Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Seebs <usenet-nospam@seebs.net> writes:
>>
>>> On 2009-11-03, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>> typedef struct string string;
>>>
>>> I don't like the name "string" for this.  The term "string" is pretty
>>> well defined in C, and I think this has real potential to confuse
>>> readers in a larger program.
>>
>> I dithered about that.  In the end, since it is used only on this
>> program, the name was just about OK.
>
> Erm, but doesn't it tromp on reserved namespace? 

No, I don't think so but, to be honest, I am not sure -- and that alone
is reason enough to avoid the name.  The code (of mine, BTW) from with
I borrowed that small part uses a capitalised name, but that looked odd
in the context of the other code, I so replaced it.

I think the str[a-z][a-z]* names are only reserved as identifiers with
external linkage (and probably as function-like macros when string.h
is included) though I admit to finding the passages in the standard
less than crystal clear.  I used it as struct tag and as a type name.

I hope someone with more certain knowledge can say one way or the other.

<snip>
-- 
Ben.
0
ben.usenet (6790)
11/5/2009 12:07:21 AM
Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
>
>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>> Seebs <usenet-nospam@seebs.net> writes:
>>>
>>>> On 2009-11-03, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>>> typedef struct string string;
>>>>
>>>> I don't like the name "string" for this.  The term "string" is pretty
>>>> well defined in C, and I think this has real potential to confuse
>>>> readers in a larger program.
>>>
>>> I dithered about that.  In the end, since it is used only on this
>>> program, the name was just about OK.
>>
>> Erm, but doesn't it tromp on reserved namespace? 
>
> No, I don't think so but, to be honest, I am not sure -- and that alone
> is reason enough to avoid the name.  The code (of mine, BTW) from with
> I borrowed that small part uses a capitalised name, but that looked odd
> in the context of the other code, I so replaced it.
>
> I think the str[a-z][a-z]* names are only reserved as identifiers with
> external linkage (and probably as function-like macros when string.h
> is included) though I admit to finding the passages in the standard
> less than crystal clear.  I used it as struct tag and as a type name.
>
> I hope someone with more certain knowledge can say one way or the other.

C99 7.1.3p1:

    All identifiers with external linkage in any of the following
    subclauses (including the future library directions) are always
    reserved for use as identifiers with external linkage.

    Each identifier with file scope listed in any of the following
    subclauses (including the future library directions) is reserved
    for use as a macro name and as an identifier with file scope in
    the same name space if any of its associated headers is included.

This includes identifiers starting with str (or mem, or wcs) and
a lowercase letter.  Using "string" as a struct tag is ok (though
probably inadvisable).  Using it as a type name with file scope
is not.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
kst-u (21963)
11/5/2009 12:41:42 AM
Keith Thompson <kst-u@mib.org> writes:

> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>> Phil Carmody <thefatphil_demunged@yahoo.co.uk> writes:
>>
>>> Ben Bacarisse <ben.usenet@bsb.me.uk> writes:
>>>> Seebs <usenet-nospam@seebs.net> writes:
>>>>
>>>>> On 2009-11-03, Ben Bacarisse <ben.usenet@bsb.me.uk> wrote:
>>>>>> typedef struct string string;
>>>>>
>>>>> I don't like the name "string" for this.  The term "string" is pretty
>>>>> well defined in C, and I think this has real potential to confuse
>>>>> readers in a larger program.
>>>>
>>>> I dithered about that.  In the end, since it is used only on this
>>>> program, the name was just about OK.
>>>
>>> Erm, but doesn't it tromp on reserved namespace? 
>>
>> No, I don't think so but, to be honest, I am not sure -- and that alone
>> is reason enough to avoid the name.  The code (of mine, BTW) from with
>> I borrowed that small part uses a capitalised name, but that looked odd
>> in the context of the other code, I so replaced it.
>>
>> I think the str[a-z][a-z]* names are only reserved as identifiers with
>> external linkage (and probably as function-like macros when string.h
>> is included) though I admit to finding the passages in the standard
>> less than crystal clear.  I used it as struct tag and as a type name.
>>
>> I hope someone with more certain knowledge can say one way or the other.
>
> C99 7.1.3p1:
>
>     All identifiers with external linkage in any of the following
>     subclauses (including the future library directions) are always
>     reserved for use as identifiers with external linkage.
>
>     Each identifier with file scope listed in any of the following
>     subclauses (including the future library directions) is reserved
>     for use as a macro name and as an identifier with file scope in
>     the same name space if any of its associated headers is included.
>
> This includes identifiers starting with str (or mem, or wcs) and
> a lowercase letter.  Using "string" as a struct tag is ok (though
> probably inadvisable).  Using it as a type name with file scope
> is not.

Thank you.  For some odd reason I thought the type names were in their
own name space so I also needed to read 6.2.3 "Name spaces of
identifiers" to understand 7.1.3p1.  Seems daft now but that was my
chain of thought...

-- 
Ben.
0
ben.usenet (6790)
11/5/2009 3:28:54 AM
On Nov 5, 12:47=A0am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-11-04,spinoza1111<spinoza1...@yahoo.com> wrote:
>
> > Oh great, so you haven't opened it.
>
> I dunno, my memory's crap. =A0I can't remember which books I've read.

So we listen to your opinions why?
>
> But I don't see you advancing any argument that always moving data is
> necessarily more efficient than not always moving data.
>
> >> You posted code, you got feedback. =A0:)
> > I'm not complaining. You are.
>
> Uh, actually, you're complaining. =A0You were claiming that my behavior
> didn't meet your needs.

No, your behavior is unacceptable.
>
> > You need to use Ben Bacarisse as a role model.
>
> While I certainly don't dispute that he'd be a plausible one, I am
> not much for role models.
>
> > If you have technical insight, share it.
>
> Why, certainly! =A0Thank you for your permission. =A0:P
>
> > Shove your corporatese
>
> You keep using this word, I do not think it means what you think it means=
..
>
> > and generalizations about people's competence (whether Schildt's,
> > Navia's, or mine), up your ass, because this medium simply isn't one
> > where you have a broad enough signal to make the online judgements you
> > make on Navia and I,
>
> I don't recall having made any particular judgements about Navia. =A0I ha=
ve
> enough data to state confidently that you don't know what you're talking
> about, as widely demonstrated across several different (though related)
> fields of inquiry.

....or that I know so much more, and am so free of learning disorders,
that you can't follow my reasoning.
>
> > and you were out of line with Schildt because you
> > don't know Microsoft platforms.
>
> First off, several of his claims were false even there.
>
> Secondly, if he wanted to write a book called "C for Microsoft Platforms =
Only:
> The Incomplete Reference With A Few Errors To Make Sure You Are Staying O=
n
> Your Toes", I have every confidence that it would be well-received.

Grow up. Most platforms are Microsoft.

>
> > Schildt is weak on non-Microsoft and should not have used upper case
> > file names in #include statements for this reason.
>
> No, he shouldn't have used them because *they are never in any way a
> better choice*. =A0They don't make anything work that otherwise wouldn't.
>
> Your inability to grasp this point astounds me. =A0The question is not
> one where there's a tradeoff. =A0Covering the far/huge memory model crap?
> Perfectly reasonable, because it's going to be useful to people on a comm=
on
> platform. =A0Note: =A0*It offers them a benefit they cannot have by doing
> things the standard way*. =A0Using uppercase letters for headers specifie=
d
> as lowercase? =A0Stupid, *because it does not offer any benefit*.

Perhaps distinguishing lower and upper case file names is the mistake.
It might seem cool, but it's English - centric.
>
> > But for the same
> > reason, you weren't qualified to tech review his book.
>
> As long as it claims to cover ANSI C, rather than DOS/Windows-only, I am.
>
> > What is worse,
> > you enabled a series of personal attacks because you only published 20
> > flaws, but made references to hundreds, which you have not, as far as
> > I can see, documented.
>
> So what? =A0Plenty of other people have pointed out flaws, and there are =
plenty
> more. =A0A representative sample is more useful.

No, they haven't. They've repeated what you have said, or they have
said that "Schildt sucks", which isn't pointing out a flaw at all.
>
> > I have plenty of consideration for others, but unlike a feminized
> > corporate dweeb "this animal defends itself when attacked".
>
> So does my cat, albeit more effectively.
>
> >> Corporatese? =A0I don't think so.
> > I do.
>
> Of course you do. =A0But you can't actually, say, justify or support
> that point.

I have supported it.

It is corporate-speak to pass on rumors about a person's competence
without substantiation, and this is what you've done with Schlidt.
>
> > When you are at a loss for enough to say technically you venture
> > without warning into abstractions with which you're not qualified to
> > deal.
>
> Wait, that's not a telepathy helmet, it's a mirror!
>
> > For example, your claim that Schildt somehow made software
> > incorrect by publishing a book is nonsense, because what makes
> > software incorrect is the refusal of technicians to abandon C.
>
> Even if we grant (despite the lack of support or evidence from you)
> the theoretical notion that C is a source of errors, it's still noticeabl=
e
> that those errors are exacerbated by people trying to learn from Schildt,
> and mitigated by people trying to learn from other authors.

That's simply not the case. As it happens, people use his approaches
to generate correct software. What part of "critical thinking" and
"testing" don't you understand?

>
> > No shit, Dick Tracy. Have you ever heard about the use of white space
> > in technical writing?
>
> Yes.
>
> Keep in mind, unless you've got more books out there, I've done 2-5 times
> as much technical writing as you have. =A0White space? =A0A good thing *u=
sed

Wow, the autistic writer of documents nobody bothers to read.

> intelligently*. =A0Double-spacing paragraph text would not be a good thin=
g.
> Large spaces between members of lists, also not good.
>
> > Corporatese, because a naming standard doesn't work or fail. It is
> > usable or otherwise.
>
> A naming standard presumably has goals. =A0The goals given for Hungarian
> notation are not met by Systems Hungarian. =A0Therefore, it does not work=
..

In my experience this is not the case. Systems Hungarian makes
selection of data type a design point and not coding and the fact that
it's difficult to change is a good thing. This is because before
coding starts you need to know your data types.
>
> > Learn to write before you write another document
> > that trashes a decent person's career, punk.
>
> Good thought. =A0I'll just zip back in my time machine and tell my earlie=
r self
> to start learning to write seriously five or ten years ago... oh, wait, h=
e
> already did. =A0Lucky that, I think my time machine's batteries are low, =
and
> I haven't got a steam locomotive or a thunderstorm anyway.
>
> > Your laziness doesn't control.
>
> But your incompetence does.

If you're a technical writer, what are you doing misrepresenting
yourself as a competent programmer?
>
> > I find Systems Hungarian easy to maintain.
>
> It certainly can be, but it is COMPLETELY WORTHLESS.
>
> > I also find that most programmers are too lazy to maintain
> > another's naming standards. Systems Hungarian was abandoned out of
> > laziness.
>
> No, it was abandoned because it is COMPLETELY WORTHLESS (in a strongly-ty=
ped
> language).
>
> > Szymonyi was told how to name variables at IBM but went his
> > own way, stealing the idea and taking credit for it.
>
> Have you ever gone five minutes without inventing a conspiracy theory
> involving people stealing, lying, and cheating?
>
> > When I see the need, I'll use assembler to get the instruction. The
> > legacy C libraries are too full of gotchas to be worth the trouble in
> > the case of strings.
>
> Only they're not, at least, not for strlen().
>
> Basic familiarity with the tools is a prerequisite for coding effectively=
..
>
> > If I were to use C for a "real" project, first
> > thing I'd do would be to reinvent strings.
>
> Badly.
>
> Yes, we already saw that your first idea was to make something which
> carefully checked the limits for an append -- incorrectly. =A0That's not
> encouraging.
>
> > Can I quote you as you misrepresent Schildt?
>
> That's a philosophical question, since you've never shown that I've
> misrepresented Schildt at all. =A0You've come up with some incredible
> and elaborate reinterpretations of his writing, ignored entire arguments,
> and then lied about the rest, but you've never actually shown anything
> about what he actually said or what I said about it.
>
> >> One of the things that fluent speakers learn is that beyond the raw fo=
rmal
> >> lexicon of a language, it will usually have idioms. =A0C has had idiom=
s for
> >> true and false since 1978, and it would make sense to stick with those
> >> idioms. =A0(Or, if you prefer, you could always use the boolean type, =
since
> >> there is one in C99.)
> > I'd rather use C Sharp.
>
> Please do. =A0C has a problem with an undeserved bad reputation because
> shitty programmers insist on using it then blaming the language for their
> inability to learn to do simple things.
>
> > I don't think you know what elegance is.
>
> Oh, of course not.
>
> > Also, while you yourself have not demonstrated the willingness or
> > ability to post code extempore, you probably excuse your own stylistic
> > and technical failings by calling new code throwaway, while acting as
> > if others only have the right here to post bug free code...
>
> Who said that? =A0Correcting code doesn't mean the poster didn't have the
> right to post it, only that it had an error of some sort.
>
> A lot of my code is sorta dodgy, certainly. =A0That's one of the reasons
> I hang out and look at code; to try to learn more.
>
> > You wouldn't say this if you had in the past to debug at machine code
> > level,
>
> Sure I would.
>
> > because 1 looks too much like =A00 to be a good way to represent
> > truthiness. -1 is best.
>
> Nope. =A0You're still wrong, and no amount of making excuses is gonna cha=
nge
> it.
>
> In C, the canonically-true value is 1, not -1. =A0-1 indicates an error.
>
> You're acting like one of those foreigners who picked up a bit of a langu=
age
> from a phrase book, and is now arguing with the native speakers that they=
're
> pronouncing it wrong and don't have their idioms right.
>
> > I don't have to follow broken standards.
>
> You don't, but if you don't follow a standard merely because you think
> it's broken, you're going to be useless as a contributor to any project
> that will ever involve other people.
>
> > The problem is not using -1 for truthiness. It is that globally, C is
> > a broken language that fosters bad practices, buggy code, personality
> > dysfunction, and the politics of personal destruction when people
> > scapegoat others for their refusal to use a safer language.
>
> That's interesting, because you're the person here who writes buggy code
> and indulges in ceaseless personal attacks. =A0It seems to me that you're
> projecting your own pre-existing failings on C.
>
> > Well, sure, if I were in a C workgroup (not if hell froze over, but
> > let's suppose) then I would use my coworker's idioms which, no matter
> > what you believe, vary all over the map because C IS BROKEN.
>
> You keep saying C is broken, but other people don't seem to be having
> the problems you do.
>
> > You want sympathy for being autistic
>
> No, I don't.
>
> > without taking
> > responsibility for the fact that autistic people are very bad at
> > understanding other minds...
>
> You might consider learning about things from sources other than movies
> and television.
>
> Autistic people are not necessarily always bad at understanding other min=
ds,
> and have noticeable advantages in doing so. =A0Specifically, not being
> constrained to accept the instinctive heuristics of the brain as Revealed
> Truth. =A0Big win, there.
>
> > and have no standing when assessing the
> > knowledge of a Schildt, which you nonetheless do.
>
> Knowledge is easily assessed when looking at a book someone wrote on a to=
pic.
>
> >> I view you as an amusing kook, no more.
> > Fuck you, asshole. I am nothing of the kind.
>
> You have been ranting for almost two years about the Schildt thing.
> What we know so far:
> * You demonstrate no familiarity, at all, with the contents of his books
> =A0 about C.
> * You consistently...
>
> read more =BB

0
spinoza1111 (3246)
11/5/2009 8:00:41 AM
In 
<f6731d50-9f4d-45c8-b0ea-d7b212b8fc68@f20g2000prn.googlegroups.com>, 
spinoza1111 wrote:

> On Nov 5, 12:47 am, Seebs <usenet-nos...@seebs.net> wrote:
>> On 2009-11-04,spinoza1111<spinoza1...@yahoo.com> wrote:
>>
>> > Oh great, so you haven't opened it.
>>
>> I dunno, my memory's crap.  I can't remember which books I've read.
> 
> So we listen to your opinions why?

Because he can remember what he's learned from them.

<snip>

>> > I'm not complaining. You are.
>>
>> Uh, actually, you're complaining.  You were claiming that my
>> behavior didn't meet your needs.
> 
> No, your behavior is unacceptable.

To you, perhaps, but not to normal people.

<snip>

>> I don't recall having made any particular judgements about Navia. 
>> I have enough data to state confidently that you don't know what
>> you're talking about, as widely demonstrated across several
>> different (though related) fields of inquiry.
> 
> ...or that I know so much more, and am so free of learning
> disorders, that you can't follow my reasoning.

In your dreams.

>> > and you were out of line with Schildt because you
>> > don't know Microsoft platforms.
>>
>> First off, several of his claims were false even there.
>>
>> Secondly, if he wanted to write a book called "C for Microsoft
>> Platforms Only: The Incomplete Reference With A Few Errors To Make
>> Sure You Are Staying On Your Toes", I have every confidence that it
>> would be well-received.
> 
> Grow up. Most platforms are Microsoft.

Absolute rubbish. If you're going by installation count, there are 
approximately 1,000,000,000 PCs out there, not all of which run MS 
operating systems. And there are well over four times as many mobile 
phones, of which only a tiny fraction run Windows Mobile. And if 
you're going by platform count, Microsoft has written a handful of 
versions of Windows (1, 2, 3, 95, 98, NT3.5, NT4, ME, 2000, XP, 
Vista, 7, plus slight mods thereof), and they released a few versions 
of MS-DOS. There are at least that many different mainframe operating 
systems, and then there's all the minicomputer OSs, not forgetting 
alternate PC OSs, and all the Mac platforms, various games consoles, 
and a whole bundle of mobile phone systems, engine management 
systems, set top boxes, and various other embedded devices. MS is a 
tiny drop in a rather large puddle.

<snip>

>> Your inability to grasp this point astounds me.  The question is
>> not one where there's a tradeoff.  Covering the far/huge memory
>> model crap? Perfectly reasonable, because it's going to be useful
>> to people on a common platform.  Note:  *It offers them a benefit
>> they cannot have by doing things the standard way*.  Using
>> uppercase letters for headers specified as lowercase?  Stupid,
>> *because it does not offer any benefit*.
> 
> Perhaps distinguishing lower and upper case file names is the
> mistake.

No, the mistake is Schildt's *failure* to distinguish between upper 
and lower case.

> It might seem cool, but it's English - centric.

Hardly. A great many languages use case distinctions just as much as 
English does, and in some csaes even more (e.g. German).

<snip>

>> > What is worse,
>> > you enabled a series of personal attacks because you only
>> > published 20 flaws, but made references to hundreds, which you
>> > have not, as far as I can see, documented.
>>
>> So what?  Plenty of other people have pointed out flaws, and there
>> are plenty more.  A representative sample is more useful.
> 
> No, they haven't. They've repeated what you have said, or they have
> said that "Schildt sucks", which isn't pointing out a flaw at all.

Wrong. I have pointed out flaws that have reported by neither Seebach 
nor Feather.

>> > I have plenty of consideration for others, but unlike a feminized
>> > corporate dweeb "this animal defends itself when attacked".
>>
>> So does my cat, albeit more effectively.
>>
>> >> Corporatese?  I don't think so.
>> > I do.
>>
>> Of course you do.  But you can't actually, say, justify or support
>> that point.
> 
> I have supported it.

No, you've just ranted about it. "Support" means reference to 
independently verifiable and /relevant/ facts that give credence to 
your case.

> It is corporate-speak to pass on rumors about a person's competence
> without substantiation, and this is what you've done with Schlidt.

Wrong. He has substantiated the claim.

<snip>

>> Even if we grant (despite the lack of support or evidence from you)
>> the theoretical notion that C is a source of errors, it's still
>> noticeable that those errors are exacerbated by people trying to
>> learn from Schildt, and mitigated by people trying to learn from
>> other authors.
> 
> That's simply not the case.

Er, yes it is.

> As it happens, people use his approaches to generate correct
> software.

If they follow his advice, they can hardly fail to produce incorrect 
software.

> What part of "critical thinking" and "testing" don't you understand?

He has thunk critically. He has tested. He has reached conclusions. He 
has produced a report to promulgate those conclusions. That you do 
not agree with the conclusions would be interesting if you knew C.

>> > No shit, Dick Tracy. Have you ever heard about the use of white
>> > space in technical writing?
>>
>> Yes.
>>
>> Keep in mind, unless you've got more books out there, I've done 2-5
>> times as much technical writing as you have.  White space?  A good
>> thing *used
> 
> Wow, the autistic writer of documents nobody bothers to read.

Unless you can support that claim with independent evidence of a 0 
readership (which you can't), it would be proper to conclude that the 
claim is nonsense.

>> intelligently*.  Double-spacing paragraph text would not be a good
>> thing. Large spaces between members of lists, also not good.
>>
>> > Corporatese, because a naming standard doesn't work or fail. It
>> > is usable or otherwise.
>>
>> A naming standard presumably has goals.  The goals given for
>> Hungarian notation are not met by Systems Hungarian.  Therefore, it
>> does not work.
> 
> In my experience this is not the case.

If you had any useful experience you'd know otherwise.

> Systems Hungarian makes
> selection of data type a design point and not coding and the fact
> that it's difficult to change is a good thing. This is because
> before coding starts you need to know your data types.

No, a good design is independent of such language-dependent details as 
data types. For numeric values it needs to specify ranges, but that's 
all. The choice of type is the province of the programmer, not the 
designer.

<snip>

> If you're a technical writer, what are you doing misrepresenting
> yourself as a competent programmer?

Your racism doesn't stop you being homophobic, does it? Likewise, his 
programming doesn't stop him being a technical writer.

<big ol' snip on EGN's behalf because he's either too lazy or too 
stupid to do it himself>

-- 
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
0
rjh (10791)
11/5/2009 8:34:49 AM
"Richard Heathfield" <rjh@see.sig.invalid> wrote in message 
news:Ic2dnRgejPw5EW_XnZ2dnUVZ7qGdnZ2d@bt.com...
> In
> <f6731d50-9f4d-45c8-b0ea-d7b212b8fc68@f20g2000prn.googlegroups.com>,
> spinoza1111 wrote:

>> Grow up. Most platforms are Microsoft.
>
> Absolute rubbish. If you're going by installation count, there are
> approximately 1,000,000,000 PCs out there, not all of which run MS
> operating systems. And there are well over four times as many mobile
> phones, of which only a tiny fraction run Windows Mobile. And if
> you're going by platform count, Microsoft has written a handful of
> versions of Windows (1, 2, 3, 95, 98, NT3.5, NT4, ME, 2000, XP,
> Vista, 7, plus slight mods thereof), and they released a few versions
> of MS-DOS. There are at least that many different mainframe operating
> systems, and then there's all the minicomputer OSs, not forgetting
> alternate PC OSs, and all the Mac platforms, various games consoles,
> and a whole bundle of mobile phone systems, engine management
> systems, set top boxes, and various other embedded devices. MS is a
> tiny drop in a rather large puddle.

I keep hearing all this. But since the 80's, most of the computers I've been 
able to buy have come with a MS operating system. Most of the rest have been 
Macs.

By computers I mean what you normally expect: a box with a screen and 
keyboard.

There are also a number of products which might have microprocessors inside 
but are not primarily computers (easy to tell when they contain any 
programmable devices, because they take ages to power up, are temperamental, 
slow, unresponsive, and half the time don't work; it seems not only MS are 
capable of writing crappy software).

Regarding C, some development will be targeted at MS/PC platforms, the rest 
at everything else.

I don't know what the mix is (counting developers, not numbers of 
end-products), but I'd say the MS/PC lot are still a sizeable chunk; they 
would welcome that book that was mentioned and there's no real reason for 
them to care whether their product runs on anything else.

Likewise, someone developing C for your engine management system can't 
really be expected to care whether his product will work on a PC.

-- 
Bartc 

0
bartc (786)
11/5/2009 12:18:29 PM
In <pozIm.1994$Ym4.221@text.news.virginmedia.com>, bartc wrote:

> 
> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
> news:Ic2dnRgejPw5EW_XnZ2dnUVZ7qGdnZ2d@bt.com...
>> In
>> 
<f6731d50-9f4d-45c8-b0ea-d7b212b8fc68@f20g2000prn.googlegroups.com>,
>> spinoza1111 wrote:
> 
>>> Grow up. Most platforms are Microsoft.
>>
>> Absolute rubbish. [...] MS is a tiny drop in a rather large puddle.
> 
> I keep hearing all this. But since the 80's, most of the computers
> I've been able to buy have come with a MS operating system. Most of
> the rest have been Macs.

How many mainframe systems have you bought, personally, in the last 
twenty years? How many minicomputer systems? And of course most of 
the computers that you /have/ bought in the last twenty years aren't 
MS platforms.

> By computers I mean what you normally expect: a box with a screen
> and keyboard.

If you can arbitrarily restrict the meaning of the word "computer" as 
much as you like, it's easy enough to come to almost any conclusion 
about them that you wish.

<snip>

> Regarding C, some development will be targeted at MS/PC platforms,
> the rest at everything else.

I prefer to include "MS/PC" in with "everything else" wherever 
possible. It's easier (less work).

> I don't know what the mix is (counting developers, not numbers of
> end-products), but I'd say the MS/PC lot are still a sizeable chunk;
> they would welcome that book that was mentioned and there's no real
> reason for them to care whether their product runs on anything else.

If they base their knowledge on "that book that was mentioned", 
there's no real reason for their product to run on MS platforms 
either.

> Likewise, someone developing C for your engine management system
> can't really be expected to care whether his product will work on a
> PC.

On several non-PC projects I've worked on, we cared passionately that 
the program would work on a PC, because that was the easiest place to 
do development and debugging.

-- 
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
0
rjh (10791)
11/5/2009 2:02:01 PM
trim your posts?

On 4 Nov, 14:44, spinoza1111 <spinoza1...@yahoo.com> wrote:
> On Nov 4, 11:43=A0am, Seebs <usenet-nos...@seebs.net> wrote:
> > On 2009-11-04,spinoza1111<spinoza1...@yahoo.com> wrote:
> > > On Nov 4, 2:18=A0am, Seebs <usenet-nos...@seebs.net> wrote:

<snip>


> > Oh, I'm all for elegance, regardless of who invented it, but -1 [for tr=
ue]
> > isn't elegant.
>
> I don't think you know what elegance is. For starters elegance is
> conceptual unity, [...] As it happened, [-1 for true]  was best for me in=
 my
> limited time, simply to show that this conversion could be grammar-
> driven, to use -1 as truthiness.

you could use a macro and diffuse all these arguments

#define TRUE -1

I quite like the grammer driven approach as an idea.

<snip>

> > > You see, C lacks Boolean values,
>
> > Not since 1999 it doesn't. =A0:)
>
> > But even in 1978... Let's consider the question.

personnally I thought this was one of C's mistakes. They should have
had a boolean type (or alias) from day 1 and null should have been a a
language word. Oh, and function prototypes they should have been in
from the beginning. Lint? feugh!

> > If we are to define "false" and "true", what should they be?

I don't think there's any should about it. Various languages ahve made
various decisions. This is why the atcual values should be hidden
behind macros (or even language words!). We don't get our knickers in
a twist about the representaion of floating point values or character
sets (ok, we /do/; but we shouldn't).

> > Obviously:
>
> > =A0 =A0 =A0 =A0 if (false) {
> > =A0 =A0 =A0 =A0 }
>
> > should not execute the contents of the block. =A0How about... 0?
>
> > Okay. =A0So what's true? =A0"!false" is true. =A0What's !0? =A01. =A0tr=
ue is 1.
>
> Wow, I'll alert the media. 1=3D=3D!0? New math indeed.

well =3D=3D isn't very standard mathematical notation to start with. You
are aware that in C the ! operator yields 1 when applied to 0?

x    !x
0    1
1    0
nz   0

where nz is any non-zero value. Hence !!x must yield either 0 or 1.
But of course Peter is begging the question.


> You wouldn't say this if you had in the past to debug at machine code
> level, because 1 looks too much like =A00 to be a good way to represent
> truthiness.

you're a hardware engineer, right? In my experience they're the people
who can't tell a 0 from a 1.

<snip>

> > There are many [C] functions and APIs which have standardized on using =
negative
> > values to indicate *errors*. =A0Because of this, readers who are experi=
enced
> > with C will usually regard a "-1" as an error indicator. =A0Your theory=
 that it
> > would make sense for it to be regarded as a particularly idiomatic "tru=
e"
> > is fascinating, but it doesn't match the real world.

although this is a bit of a angels on the head of a pin discussion
Peter Seebach /is/ correct here. When I read Spinoza's code I was
expecting -1 to be a failure indication. Idioms and cultural norms are
important.

<snip>

> > > My goal was to get something coded and see
> > > how you behave in a structured walkthrough

you can't have a structured walkthru in a bunch of usenet posts. Who's
the Co-ordinator?

<snip>

> > It's odd, because you keep talking about what users would expect, but y=
ou
> > appear to have carefully avoided learning anything about how users form
> > their expectations.
>
> Users? I don't use the word.

You do actually. What alternative would you offer for "the people who
use a program"?  If a user of my program says it is hard to use I
listen (I don't necessarily fix it but I do listen). If a random
person made comments he'd get less weight added to his comments.

I have, apocryphally, heard the comment "I don't like being called a
"user" it sounds like I take drugs".

> > >> But the user doesn't care about "mulFactor". =A0The user wants to kn=
ow
> > > The "user" (sigh). Sloppy English: because in a structured walkthroug=
h
> > > users have no place, no more than managers.

why don't the end-users have a place? Who else can assess usability?


> > > You invoke "the user" as a
> > > deus ex machina: [...] But literally, that's the person
> > > who as you say needs to be innocent of the details!

the user interface and what the system does isn't a detail


> > Lots of handwaving, but you haven't addressed the point. =A0The purpose=
 of the
> > code is to be used. =A0The person using it does not care about the inte=
rnal
> > implementation; that person's sole interest is to get an infix expressi=
on
> > converted to RPN, for reasons we are not privileged to speculate on. =
=A0:)
>
> This is just wrong. For one thing, this "user" has to know, not
> whether the code is "correct" (for in fact all code is "incorrect" in
> the absolute sense that a computer is ultimately a finite state
> automaton) but its limitations, and in this case and many others, this
> "user" (I prefer "caller")

caller and user are not synonymns


> would rather read the code.

users don't typically read code. Though the user of an infix to
postfix library is not a very typical user...

<snip>

> [...] I had enough familiarity [...] to be able to describe the culture o=
f C,
> including its case sensitivity and use of ASCII in place of EBCDIC.

the C standard does not specify the use of ASCII


> Whereas you
> attacked Schildt without having any experience, as far as I can see,
> on his platforms.

the point is, Schildt didn't have to write a platform specific book.
And if that is what he wanted to do he should have picked a better
title.

<snip>
0
11/5/2009 2:13:57 PM
On 5 Nov, 08:34, Richard Heathfield <r...@see.sig.invalid> wrote:
> <f6731d50-9f4d-45c8-b0ea-d7b212b8f...@f20g2000prn.googlegroups.com>,
> spinoza1111 wrote:
> > On Nov 5, 12:47 am, Seebs <usenet-nos...@seebs.net> wrote:
> >> On 2009-11-04,spinoza1111<spinoza1...@yahoo.com> wrote:

<snip>

> >> Secondly, if he wanted to write a book called "C for Microsoft
> >> Platforms Only: The Incomplete Reference With A Few Errors To Make
> >> Sure You Are Staying On Your Toes", I have every confidence that it
> >> would be well-received.
>
> > Grow up. Most platforms are Microsoft.
>
> Absolute rubbish. If you're going by installation count, there are
> approximately 1,000,000,000 PCs out there, not all of which run MS
> operating systems. And there are well over four times as many mobile
> phones, of which only a tiny fraction run Windows Mobile.

and settop boxes, and mp3 players and engine management systems, and
HDTVs, and satnavs, and...

And the internet, and e-commerce, and factory production lines...

And... oh I give up.


> And if
> you're going by platform count, Microsoft has written a handful of
> versions of Windows (1, 2, 3, 95, 98, NT3.5, NT4, ME, 2000, XP,
> Vista, 7, plus slight mods thereof), and they released a few versions
> of MS-DOS. There are at least that many different mainframe operating
> systems, and then there's all the minicomputer OSs, not forgetting
> alternate PC OSs, and all the Mac platforms, various games consoles,
> and a whole bundle of mobile phone systems, engine management
> systems, set top boxes, and various other embedded devices.

ah, ok you got those. Have you heard of Linux?


> MS is a tiny drop in a rather large puddle.

It bugged me when the adverts came out for Windows-7. "A new version
of the windows operating systems which already runs 90% of the worlds
computers".


> >> Your inability to grasp this point astounds me. =A0The question is
> >> not one where there's a tradeoff. =A0Covering the far/huge memory
> >> model crap? Perfectly reasonable, because it's going to be useful
> >> to people on a common platform. =A0Note: =A0*It offers them a benefit
> >> they cannot have by doing things the standard way*. =A0Using
> >> uppercase letters for headers specified as lowercase? =A0Stupid,
> >> *because it does not offer any benefit*.
>
> > Perhaps distinguishing lower and upper case file names is the
> > mistake.
>
> No, the mistake is Schildt's *failure* to distinguish between upper
> and lower case.
>
> > It might seem cool, but it's English - centric.
>
> Hardly. A great many languages use case distinctions just as much as
> English does, and in some csaes even more (e.g. German).

most programs are written with the english alphabet.


<snip>

> >> Even if we grant (despite the lack of support or evidence from you)
> >> the theoretical notion that C is a source of errors, it's still
> >> noticeable that those errors are exacerbated by people trying to
> >> learn from Schildt, and mitigated by people trying to learn from
> >> other authors.
>
> > That's simply not the case.
>
> Er, yes it is.
>
> > As it happens, people use his approaches to generate correct
> > software.
>
> If they follow his advice, they can hardly fail to produce incorrect
> software.

do either of you have any empirical evidence for your claims?

<snip>

0
11/5/2009 2:38:43 PM
In 
<8ae6d6e7-2ded-47ae-ba35-77e15471e6d5@k17g2000yqh.googlegroups.com>, 
Nick Keighley wrote:

> trim your posts?

If he knew how, he would surely do so, since nobody could be so 
arrogant and lazy as to leave vast swathes of uncommented material 
for everyone else to trim in their replies to him.

Since he doesn't trim his posts, then, we may safely deduce that he 
doesn't know how. Not only this, but he has consistently failed to 
learn how, in (at least) a decade of posting to Usenet. From this, we 
may deduce that he is to all intents and purposes unteachable.

<snip>

-- 
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
0
rjh (10791)
11/5/2009 2:46:28 PM
On 5 Nov, 12:18, "bartc" <ba...@freeuk.com> wrote:
> "Richard Heathfield" <r...@see.sig.invalid> wrote in message
> news:Ic2dnRgejPw5EW_XnZ2dnUVZ7qGdnZ2d@bt.com...
> > <f6731d50-9f4d-45c8-b0ea-d7b212b8f...@f20g2000prn.googlegroups.com>,
> > spinoza1111 wrote:


> >> Grow up. Most platforms are Microsoft.
>
> > Absolute rubbish. If you're going by installation count, there are
> > approximately 1,000,000,000 PCs out there, not all of which run MS
> > operating systems. [lots of examples]

<snip>

> I keep hearing all this. But since the 80's, most of the computers I've been
> able to buy have come with a MS operating system. Most of the rest have been
> Macs.

You probably haven't bought many articulated lorries either but they
still exist.

> By computers I mean what you normally expect: a box with a screen and
> keyboard.

So all those machines that sit in air conditioned rooms running google
or e-bay or generating Pixar's latest aren't computers?

> There are also a number of products which might have microprocessors inside
> but are not primarily computers (easy to tell when they contain any
> programmable devices, because they take ages to power up, are temperamental,
> slow, unresponsive, and half the time don't work; it seems not only MS are
> capable of writing crappy software).

Some things like MP2 players, digital cameras and GSM phones can't be
built without microprocessors.

Your phone would just be a rather ugly paper weight if it wan't for
all the base-stations, switches, databases, management systems,
routers, billers, etc etc. Most of that stuff looks very much like a
computer to me and a lot of it doesn't run MS DOS.

One of those thingies mentioned above has over 3/4 million lines of
software in it. And *that's* not a computer?

Do you know a how many *million* lines of software there is in a
modern commercial aircraft?


> Regarding C, some development will be targeted at MS/PC platforms, the rest
> at everything else.
>
> I don't know what the mix is (counting developers, not numbers of
> end-products), but I'd say the MS/PC lot are still a sizeable chunk;

agreed


> they
> would welcome that book that was mentioned and there's no real reason for
> them to care whether their product runs on anything else.

personnally I'd prefer a book that clearly distinguised standard stuff
from non-standard stuff. Some of us like to write software that runs
on multiple platforms. That 3/4 million line program has been ported
between OSs once and between DBMSs another.

> Likewise, someone developing C for your engine management system can't
> really be expected to care whether his product will work on a PC.

do you really think they test an EMS by bunging a PROM in and starting
the engine?

Host Based Development



0
11/5/2009 2:52:52 PM
In 
<c9e97f5b-8a37-45c2-9f79-9307344ab46f@d10g2000yqh.googlegroups.com>, 
Nick Keighley wrote:

> On 5 Nov, 08:34, Richard Heathfield <r...@see.sig.invalid> wrote:
 
<snip>

>> And if
>> you're going by platform count, Microsoft has written a handful of
>> versions of Windows (1, 2, 3, 95, 98, NT3.5, NT4, ME, 2000, XP,
>> Vista, 7, plus slight mods thereof), and they released a few
>> versions of MS-DOS. There are at least that many different
>> mainframe operating systems, and then there's all the minicomputer
>> OSs, not forgetting alternate PC OSs, and all the Mac platforms,
>> various games consoles, and a whole bundle of mobile phone systems,
>> engine management systems, set top boxes, and various other
>> embedded devices.
> 
> ah, ok you got those. Have you heard of Linux?

Oh, I left loads out by name - including Unix! Oh, and of course I 
also left out Xenix. Oops. Sorry, MS.

<snip>

>> > As it happens, people use his approaches to generate correct
>> > software.
>>
>> If they follow his advice, they can hardly fail to produce
>> incorrect software.
> 
> do either of you have any empirical evidence for your claims?

I have better than that. I have analytical evidence. Take, for 
example, his explanation of sizeof (the one where he uses it to 
determine the size of an array, when all he has is a pointer to that 
array's first element). Assume it to be correct. Write a program that 
relies on this "ability" of sizeof to interrogate pointers in some 
magical way. Et voila! You have incorrect software.

-- 
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
0
rjh (10791)
11/5/2009 2:54:04 PM
On 5 Nov, 14:02, Richard Heathfield <r...@see.sig.invalid> wrote:

> On several non-PC projects I've worked on, we cared passionately that
> the program would work on a PC, because that was the easiest place to
> do development and debugging.

so we actually *like* PCs. They just aren't the whole world. I've
worked on stuff where the target platform didn't exist when we started
testing.
0
11/5/2009 2:55:54 PM
"Richard Heathfield" <rjh@see.sig.invalid> wrote in message 
news:V4ednQFRmpHJRG_XnZ2dnUVZ8j2dnZ2d@bt.com...
> In <pozIm.1994$Ym4.221@text.news.virginmedia.com>, bartc wrote:
>
>>
>> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
>> news:Ic2dnRgejPw5EW_XnZ2dnUVZ7qGdnZ2d@bt.com...
>>> In
>>>
> <f6731d50-9f4d-45c8-b0ea-d7b212b8fc68@f20g2000prn.googlegroups.com>,
>>> spinoza1111 wrote:
>>
>>>> Grow up. Most platforms are Microsoft.
>>>
>>> Absolute rubbish. [...] MS is a tiny drop in a rather large puddle.
>>
>> I keep hearing all this. But since the 80's, most of the computers
>> I've been able to buy have come with a MS operating system. Most of
>> the rest have been Macs.
>
> How many mainframe systems have you bought, personally, in the last
> twenty years? How many minicomputer systems? And of course most of
> the computers that you /have/ bought in the last twenty years aren't
> MS platforms.

They don't seem to stock mainframes at PC World or Dixons.

>> By computers I mean what you normally expect: a box with a screen
>> and keyboard.
>
> If you can arbitrarily restrict the meaning of the word "computer" as
> much as you like, it's easy enough to come to almost any conclusion
> about them that you wish.

It's fairly obvious when something is a computer, ie. a desktop or laptop 
PC. Everything else is more specialised. There might be some consumer 
gadgets that are getting close though.

-- 
Bartc 

0
bartc (786)
11/5/2009 3:32:05 PM
In <VdCIm.2040$Ym4.846@text.news.virginmedia.com>, bartc wrote:

<snip>
 
> They don't seem to stock mainframes at PC World or Dixons.

I know, I know. Shame, really.

> 
>>> By computers I mean what you normally expect: a box with a screen
>>> and keyboard.
>>
>> If you can arbitrarily restrict the meaning of the word "computer"
>> as much as you like, it's easy enough to come to almost any
>> conclusion about them that you wish.
> 
> It's fairly obvious when something is a computer, ie. a desktop or
> laptop PC.

That's a very parochial view, temporally speaking. If you could send a 
laptop back in time, sans battery or AC adapter, to 1960, and put it 
next to a mainframe system of the time, and ask any reasonably 
competent person of the time to indicate where the computer is, they 
would point to the mainframe. Similarly, if you could send it a 
substantial distance /forward/ in time, you'd get a very similar 
reaction - the denizens of the future will, at best, regard the 
laptop as a primitive abacus-like device that can hardly be 
considered a real computer.

You don't have to work on very many embedded projects before you start 
seeing computers all around you. Phone? Computer. Microwave oven? 
Computer. Sewing machine? Computer. Car? Computer. Traffic lights? 
Computer. They're everywhere. And hardly any of them run an MS OS.

<snip>

-- 
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
0
rjh (10791)
11/5/2009 4:40:26 PM
On 2009-11-05, spinoza1111 <spinoza1111@yahoo.com> wrote:
> On Nov 5, 12:47�am, Seebs <usenet-nos...@seebs.net> wrote:
>> I dunno, my memory's crap. �I can't remember which books I've read.

> So we listen to your opinions why?

Because my opinions are frequently right.

Look at it this way:  Who is better at mathematics, someone who knows all the
standard trigonometry relationships, or someone who can't remember them but
can rederive them on the fly any time they come up?

>> >> You posted code, you got feedback. �:)
>> > I'm not complaining. You are.

>> Uh, actually, you're complaining. �You were claiming that my behavior
>> didn't meet your needs.

> No, your behavior is unacceptable.

That's a "complaint".  (It's also patently false, as at least some people
appear to accept it.)

>> I don't recall having made any particular judgements about Navia. �I have
>> enough data to state confidently that you don't know what you're talking
>> about, as widely demonstrated across several different (though related)
>> fields of inquiry.

> ...or that I know so much more, and am so free of learning disorders,
> that you can't follow my reasoning.

Being a cautious sort, I did consider this as a possibility, briefly.  I have
shown your arguments to a broad selection of people with either different
learning disorders or none that we know of.  The responses are essentially
consistent; everyone thinks you're a nutter.  This would be because you don't
HAVE any reasoning, just various assertions offered as a sort of miasma
of impotent rage against C.

>> Secondly, if he wanted to write a book called "C for Microsoft Platforms Only:
>> The Incomplete Reference With A Few Errors To Make Sure You Are Staying On
>> Your Toes", I have every confidence that it would be well-received.

> Grow up.

Did.

> Most platforms are Microsoft.

Not really.  Most desktop computers are Microsoft -- but much of what
Schildt wrote is no longer true of them.  The vast majority of CPUs running
C code, though, are not running MS operating systems, and many of the ones
which are are cell phones or other devices which, again, don't conform to
the rules Schildt discussed.

But even if it were true, the best case is that we reduce the set of errors
to about two thirds of its current size, and observe that the other third
of the "errors" were in fact a single error, the claim that the book covered
all systems and portable code.  That would get us from incompetence about C
to mere fraud, doubtless an improvement.  :)

>> Your inability to grasp this point astounds me. �The question is not
>> one where there's a tradeoff. �Covering the far/huge memory model crap?
>> Perfectly reasonable, because it's going to be useful to people on a common
>> platform. �Note: �*It offers them a benefit they cannot have by doing
>> things the standard way*. �Using uppercase letters for headers specified
>> as lowercase? �Stupid, *because it does not offer any benefit*.

> Perhaps distinguishing lower and upper case file names is the mistake.

Even if you were right, you'd still be wrong.

The job of a technical writer is to describe what is, not just what
should have been.

I'd hate to see you dealing with history books.  "Schildt's claim that
the Japanese never attacked Pearl Harbor is ridiculous."  "But that would
have been a horrible mistake; they'd have gotten America into WWII and
probably subsequently lost the war.  Clearly, it was the Japanese that
made the mistake, Schildt is correct."

> It might seem cool, but it's English - centric.

Doesn't matter.  It's what is.  It is an error for the book to describe
things incorrectly, *even if you don't like the way they are*.

>> So what? �Plenty of other people have pointed out flaws, and there are plenty
>> more. �A representative sample is more useful.

> No, they haven't.

Untrue.  We've pointed you at several instances.

> They've repeated what you have said, or they have
> said that "Schildt sucks",

Untrue.  No one has been identified as having said this.  Seriously, find
an example.

> I have supported it.

No, you haven't.  You've claimed that you have, but normally you just post
non-sequiturs, occasionally you post untrue things.

> It is corporate-speak to pass on rumors about a person's competence
> without substantiation,

I never knew that junior high school students were the epitome of
"corporate-speak".

> and this is what you've done with Schlidt.

Only it isn't.  It isn't what I've done with Schildt, either.

I've passed on verified factual claims with substantiation and support.
The support's strong enough that you're now reduced to claiming that
the real world should have been different so that the book wouldn't be
wrong.  That's... Well, it's funny, and it's why I see no evidence
that *anyone* is taking you seriously anymore.

>> Even if we grant (despite the lack of support or evidence from you)
>> the theoretical notion that C is a source of errors, it's still noticeable
>> that those errors are exacerbated by people trying to learn from Schildt,
>> and mitigated by people trying to learn from other authors.

> That's simply not the case.

Again, "yes it is".  Go look at the Google Groups archives from back when
his books were popular.

> As it happens, people use his approaches
> to generate correct software.

Not demonstrably.

> What part of "critical thinking" and "testing" don't you understand?

I understand those fine.  However, that doesn't make the book correct; that
makes the book incorrect in a way that many users recover from.

Here's the great part.

Critical thinking is what happens when people realize that a source is
unreliable.  One of the ways this can be streamlined is to tell them about it
up front.  Then, they critically think about the value of the book, toss
it in the trash, and get one that doesn't suck.

> Wow, the autistic writer of documents nobody bothers to read.

Fascinating assertion.  Not particularly supported, but fascinating.

> In my experience this is not the case. Systems Hungarian makes
> selection of data type a design point and not coding and the fact that
> it's difficult to change is a good thing. This is because before
> coding starts you need to know your data types.

You continue to hammer home the fact that you have no clue what you're
talking about.  The "data types" you need to know are at the level
of "structure" or "integer"; if you think you need to know whether something
is an int or a long during the design phase, your design is flawed.

> If you're a technical writer, what are you doing misrepresenting
> yourself as a competent programmer?

This makes no sense.  Why should the categories be mutually exclusive?
If they are mutually exclusive, which are you?

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/5/2009 5:13:09 PM
On 2009-11-05, bartc <bartc@freeuk.com> wrote:
> It's fairly obvious when something is a computer, ie. a desktop or laptop 
> PC. Everything else is more specialised. There might be some consumer 
> gadgets that are getting close though.

But if they have CPUs, they're still computers.  We target a lot of those
things with C compilers.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/5/2009 5:15:01 PM
On 2009-11-05, Nick Keighley <nick_keighley_nospam@hotmail.com> wrote:
> trim your posts?

He can't.

> although this is a bit of a angels on the head of a pin discussion

Agreed.

> Peter Seebach /is/ correct here. When I read Spinoza's code I was
> expecting -1 to be a failure indication. Idioms and cultural norms are
> important.

That was the point, really.  All the arguments about what true should or
shouldn't be are sort of arbitrary, although there's a lot to be said for
accepting the value the language provides for !0.  But once people have
picked an answer, sticking with it is important.

Whether it's better to drive on the left or right side of the road appears
to be very close to a moot point; there's no obvious reason to assert that
either answer is unambiguously superior.  But, once you know that you are
in a place where a particular answer has been adopted, it's crucial to
acknowledge that they've picked an answer.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/5/2009 5:21:26 PM
In article <slrnhf624f.c1d.usenet-nospam@guild.seebs.net>,
Seebs  <usenet-nospam@seebs.net> wrote:
>On 2009-11-05, bartc <bartc@freeuk.com> wrote:
>> It's fairly obvious when something is a computer, ie. a desktop or laptop 
>> PC. Everything else is more specialised. There might be some consumer 
>> gadgets that are getting close though.
>
>But if they have CPUs, they're still computers.  We target a lot of those
>things with C compilers.

Wrong (of course - could it ever be otherwise with you?)

.... If it has wheels and an engine, it is a car ...

0
gazelle3 (1726)
11/5/2009 6:31:37 PM
On 2009-11-05, Kenny McCormack <gazelle@shell.xmission.com> wrote:
> In article <slrnhf624f.c1d.usenet-nospam@guild.seebs.net>,
> Seebs  <usenet-nospam@seebs.net> wrote:
>>But if they have CPUs, they're still computers.  We target a lot of those
>>things with C compilers.

> Wrong

So you say, but you don't really argue it.

> (of course - could it ever be otherwise with you?)

Wow, you're still pretty butthurt about having the emptiness of your status
hallucinations pointed out, aren't you?

> ... If it has wheels and an engine, it is a car ...

Not comparable.  There are a whole lot of things with wheels and engines
which are, say, trucks -- members of other categories.

But "computer" is a top-level category, more like "vehicle".  If it has
wheels (in the sense specifically of the kind used for travel, not including
all possible round spinny things, such as the rollers used to advance paper
in a large printing press) and an engine, it's a motor vehicle.

Someone who insists that something is only a "vehicle" if it has a steering
wheel on the left-hand side and is intended for use by commuters is wrong,
and someone who insists that something is only a "computer" if it is intended
for individual desktop use in conjunction with a keyboard and monitor is
wrong too.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/5/2009 6:38:19 PM
Nick Keighley <nick_keighley_nospam@hotmail.com> writes:
[...]
> you could use a macro and diffuse all these arguments
>
> #define TRUE -1
>
> I quite like the grammer driven approach as an idea.
[...]

I think you mean

#define TRUE (-1)

And if I saw that, I'd still wonder why the author used -1 rather
than 1.

My own favorite way to define a Boolean type in C (if <stdbool.h>
isn't available) is

    typedef enum { false=0, true=1 } bool;

where the "=0" and "=1" are superfluous, but nice to have for
emphasis.

But as long as you maintain the habit of *never* comparing for
equality to true or false, you can probably use any non-zero value you
like for true.

-- 
Keith Thompson (The_Other_Keith) kst-u@mib.org  <http://www.ghoti.net/~kst>
Nokia
"We must do something.  This is something.  Therefore, we must do this."
    -- Antony Jay and Jonathan Lynn, "Yes Minister"
0
kst-u (21963)
11/5/2009 6:55:39 PM
On 2009-11-05, Keith Thompson <kst-u@mib.org> wrote:
> But as long as you maintain the habit of *never* comparing for
> equality to true or false, you can probably use any non-zero value you
> like for true.

Long ago, I worked at a place that had some C++/Fortran interactions.

And the following macro:

	#define IS_TRUE(x) ((x & 0x100) != 0)

Interestingly, after a compiler upgrade, that stopped working.  Apparently
the Fortran compiler's value for .TRUE. had changed in some way that resulted
in that particular bit not being set.  I was never able to get anyone to
explain what they thought this macro was good for, since .FALSE. was always
0.

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/5/2009 7:16:46 PM
In article <slrnhf670m.42i.usenet-nospam@guild.seebs.net>,
Seebs  <usenet-nospam@seebs.net> wrote:
....
>Someone who insists that something is only a "vehicle" if it has a steering
....

I don't exactly see a lot of argumentation or proof in your posts
either, dear boy...

0
gazelle3 (1726)
11/5/2009 8:04:19 PM
bartc wrote:
> 
> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message 
> news:V4ednQFRmpHJRG_XnZ2dnUVZ8j2dnZ2d@bt.com...
>> In <pozIm.1994$Ym4.221@text.news.virginmedia.com>, bartc wrote:
>>
>>>
>>> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
>>> news:Ic2dnRgejPw5EW_XnZ2dnUVZ7qGdnZ2d@bt.com...
>>>> In
>>>>
>> <f6731d50-9f4d-45c8-b0ea-d7b212b8fc68@f20g2000prn.googlegroups.com>,
>>>> spinoza1111 wrote:
>>>
>>>>> Grow up. Most platforms are Microsoft.
>>>>
>>>> Absolute rubbish. [...] MS is a tiny drop in a rather large puddle.
>>>
>>> I keep hearing all this. But since the 80's, most of the computers
>>> I've been able to buy have come with a MS operating system. Most of
>>> the rest have been Macs.
>>
>> How many mainframe systems have you bought, personally, in the last
>> twenty years? How many minicomputer systems? And of course most of
>> the computers that you /have/ bought in the last twenty years aren't
>> MS platforms.
> 
> They don't seem to stock mainframes at PC World or Dixons.

So? That isn't where most computers (even most desktops and laptops, I 
would guess), are bought.

Oh, and since you've said, since the 80s, there are the HP systems which 
were in common use in some industries for which you had a choice of (to 
my knowledge) three OSs NONE of which were by MS. These were computers 
about the same size as an IBM PC, they had a keyboard, they had a 
monitor, and where shipped with at least one programming language (I 
used Pascal and BASIC) for software development *on* the machines.

>>> By computers I mean what you normally expect: a box with a screen
>>> and keyboard.
>>
>> If you can arbitrarily restrict the meaning of the word "computer" as
>> much as you like, it's easy enough to come to almost any conclusion
>> about them that you wish.
> 
> It's fairly obvious when something is a computer, ie. a desktop or 
> laptop PC.

So servers are not computers? That will be interesting to my customer 
who buy servers from computer manufacturers, and to the computer 
manufacturers themselves who think they are building computers when they 
build servers.

> Everything else is more specialised.

Hmm. A computer running simultaneously three versions of Windows (all 
server versions, so MS think servers are computers) and I think about 5 
versions of Linux as well as the native OS is more specialised than a 
computer only running one OS and far fewer applications?

Oh, and it's not long ago we had a customer asking us to port one of our 
applications to AIX (a Unix version).

> There might be some 
> consumer gadgets that are getting close though.

You mean like the netbook PCs running Linux? Or the PDAs on which you 
can run word processors, spreadsheets, terminal emulators, games and 
loads more are not computers?
-- 
Flash Gordon
0
smap (838)
11/5/2009 11:29:57 PM
"Flash Gordon" <smap@spam.causeway.com> wrote in message
news:mo3cs6xefp.ln2@news.flash-gordon.me.uk...
> bartc wrote:
>>
>> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
>> news:V4ednQFRmpHJRG_XnZ2dnUVZ8j2dnZ2d@bt.com...
>>> In <pozIm.1994$Ym4.221@text.news.virginmedia.com>, bartc wrote:

>>>> "Richard Heathfield" <rjh@see.sig.invalid> wrote in message
>>>> news:Ic2dnRgejPw5EW_XnZ2dnUVZ7qGdnZ2d@bt.com...

>>> <f6731d50-9f4d-45c8-b0ea-d7b212b8fc68@f20g2000prn.googlegroups.com>,
>>>>> spinoza1111 wrote:
>>>>
>>>>>> Grow up. Most platforms are Microsoft.
>>>>>
>>>>> Absolute rubbish. [...] MS is a tiny drop in a rather large puddle.
>>>>
>>>> I keep hearing all this. But since the 80's, most of the computers
>>>> I've been able to buy have come with a MS operating system. Most of
>>>> the rest have been Macs.
>>>
>>> How many mainframe systems have you bought, personally, in the last
>>> twenty years? How many minicomputer systems? And of course most of
>>> the computers that you /have/ bought in the last twenty years aren't
>>> MS platforms.
>>
>> They don't seem to stock mainframes at PC World or Dixons.
>
> So? That isn't where most computers (even most desktops and laptops, I
> would guess), are bought.

My point-of-view is that of a hobbyist programmer. But even when I worked
for a (very small) company we were buying PCs with DOS or Windows, since
that was most of our clients had or could easily buy. I can't remember where
they were from, they just appeared.

(This has come up before and I understand some hobbyists do have esoteric
systems of various kinds.)

>>>> By computers I mean what you normally expect: a box with a screen
>>>> and keyboard.
>>>
>>> If you can arbitrarily restrict the meaning of the word "computer" as
>>> much as you like, it's easy enough to come to almost any conclusion
>>> about them that you wish.
>>
>> It's fairly obvious when something is a computer, ie. a desktop or laptop
>> PC.
>
> So servers are not computers? That will be interesting to my customer who
> buy servers from computer manufacturers, and to the computer manufacturers
> themselves who think they are building computers when they build servers.

Actually I've little idea what a server is. I'd imagine it's some machine
accessed across a network. I would call it specialised, although the way the
internet works is blurring some of the distinctions.

(I started in computing using timesharing terminals connected to a single
large computer. A few years later with no job I drifted into hardware and
started using simple microprocessor computers that were 100% personal and
hands-on.

Great! Finally we could get away from monster computers, operating systems,
logins, passwords, quotas, booking of terminals... but 25 years on and we're
drifting back in that same direction, and in spades...)

>> Everything else is more specialised.
>
> Hmm. A computer running simultaneously three versions of Windows (all
> server versions, so MS think servers are computers) and I think about 5
> versions of Linux as well as the native OS is more specialised than a
> computer only running one OS and far fewer applications?

3 versions of Windows and 5 of Linux, and you think it's not specialised?..

>> There might be some consumer gadgets that are getting close though.
>
> You mean like the netbook PCs running Linux? Or the PDAs on which you can
> run word processors, spreadsheets, terminal emulators, games and loads
> more are not computers?

All I'm saying is that my world is dominated by computers running MS
products and I don't think that's an uncommon situation. (Not all of us are
lucky to have been given cool jobs developing for all these other systems
that are always mentioned.)

If I had to write a utility, let's say in C, to be sent to half a dozen
people I know, then if I compile it for x86-32 under Windows, I know they
will be able to run it. Compiled for anything else, they won't.


-- 
Bartc

0
bartc (786)
11/6/2009 1:11:10 AM
In <OIKIm.2184$Ym4.1158@text.news.virginmedia.com>, bartc wrote:

> "Flash Gordon" <smap@spam.causeway.com> wrote in message
> news:mo3cs6xefp.ln2@news.flash-gordon.me.uk...
>> bartc wrote:

<snip>

>>> It's fairly obvious when something is a computer, ie. a desktop or
>>> laptop PC.
>>
>> So servers are not computers? That will be interesting to my
>> customer who buy servers from computer manufacturers, and to the
>> computer manufacturers themselves who think they are building
>> computers when they build servers.
> 
> Actually I've little idea what a server is.

Oversimplifying a little, a typical rack-mounted server is basically a 
PC with no keyboard or mouse or screen. (It may or may not be plugged 
into a KVM, however.) Its connectivity is via the network. Normally 
it will be running Unix or Linux, although Windows servers are by no 
means rare. Of course, servers do not /have/ to be rack-mounted, and 
some have screens and keyboards - especially Windows servers, which 
aren't always too ecstatic about booting up if there's no keyboard 
attached.

According to you, the server that sits under my desk happily serving 
my Web site as well as being my main box, *is* a computer, because it 
has a screen and keyboard attached to it, but my LAN server sat only 
a few feet away - which is an absolutely identical box in every 
respect, same manufacturer, same model, same spec, an identical twin 
bought at the same time - is *not* a computer, because the only wires 
dangling out the back are AC power and Cat-5.

I suppose it's a point of view, but it seems strange. If I swap them 
over, does the non-computer become a computer? And does the computer 
stop being a computer?

> I'd imagine it's some
> machine accessed across a network. I would call it specialised,

Not really. If you run a Web site from home, you have a server right 
there in front of you.

> although the way the internet works is blurring some of the
> distinctions.

Which distinctions did you have in mind?

> (I started in computing using timesharing terminals connected to a
> single large computer.

Sounds like a mini or a mainframe. Your keyboard-bearing terminal was 
attached to it remotely. Does that count? Is a remote keyboard 
sufficient to qualify it as a computer?

<snip>

>>> Everything else is more specialised.
>>
>> Hmm. A computer running simultaneously three versions of Windows
>> (all server versions, so MS think servers are computers) and I
>> think about 5 versions of Linux as well as the native OS is more
>> specialised than a computer only running one OS and far fewer
>> applications?
> 
> 3 versions of Windows and 5 of Linux, and you think it's not
> specialised?

It can run a wider range of software. Do you truly believe that a 
computer running only *one* OS and *less* software is more 
general-purpose than a computer with lots of choices?

>>> There might be some consumer gadgets that are getting close
>>> though.
>>
>> You mean like the netbook PCs running Linux? Or the PDAs on which
>> you can run word processors, spreadsheets, terminal emulators,
>> games and loads more are not computers?
> 
> All I'm saying is that my world is dominated by computers running MS

The world you think about, maybe. But even in your own home, whilst 
you may have as many as five or six PCs running Windows if you're a 
really fanatical hobbyist, that number is dwarfed by the number of 
embedded systems in a typical modern "First World" home.

<snip>

> If I had to write a utility, let's say in C, to be sent to half a
> dozen people I know, then if I compile it for x86-32 under Windows,
> I know they will be able to run it. Compiled for anything else, they
> won't.

Sure. Obviously your platform decision will be determined by your user 
base. But other people have different user bases to you.

-- 
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
0
rjh (10791)
11/6/2009 2:03:36 AM
On 2009-11-06, bartc <bartc@freeuk.com> wrote:
> If I had to write a utility, let's say in C, to be sent to half a dozen
> people I know, then if I compile it for x86-32 under Windows, I know they
> will be able to run it. Compiled for anything else, they won't.

Among people I know, my best bet would probably be OS X or x86 Linux.
Many of my friends don't have any access at all to Windows.

It varies some.  :)

-s
-- 
Copyright 2009, all wrongs reversed.  Peter Seebach / usenet-nospam@seebs.net
http://www.seebs.net/log/ <-- lawsuits, religion, and funny pictures
http://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!
0
usenet-nospam (2309)
11/6/2009 3:47:10 AM
On Nov 6, 11:47=A0am, Seebs <usenet-nos...@seebs.net> wrote:
> On 2009-11-06, bartc <ba...@freeuk.com> wrote:
>
> > If I had to write a utility, let's say in C, to be sent to half a dozen
> > people I know, then if I compile it for x86-32 under Windows, I know th=
ey
> > will be able to run it. Compiled for anything else, they won't.
>
> Among people I know, my best bet would probably be OS X or x86 Linux.
> Many of my friends don't have any access at all to Windows.
>
> It varies some. =A0:)
>
> -s
> --
> Copyright 2009, all wrongs reversed. =A0Peter Seebach / usenet-nos...@see=
bs.nethttp://www.seebs.net/log/<-- lawsuits, religion, and funny picturesht=
tp://en.wikipedia.org/wiki/Fair_Game_(Scientology) <-- get educated!

What ev er. Any way, here is the next version of the parser under
discussion, with input from you and Bacarisse. Try to make
constructive comments only. Thanks.



// ***************************************************************
// *                                                             *
// * infix2PolishC   Infix to Polish notation using a grammar    *
// *                                                             *
// *                                                             *
// * This application converts infix to Polish notation using a  *
// * simple grammar and two different implementations. It also   *
// * contains testing and timing facilities. For more            *
// * information, see the readme.TXT file in this project.       *
// *                                                             *
// *                                                             *
// * C H A N G E   R E C O R D --------------------------------- *
// *   DATE     PROGRAMMER     DESCRIPTION OF CHANGE             *
// * --------   ---------      --------------------------------- *
// * 11 01 09   Nilges         Version 1                         *
// *                                                             *
// * 11 03 09   Nilges         Version 2                         *
// *            ANON           1.  Commenting added    DONE      *
// *                           2.  Routine index added with      *
// *                               forward definitions   DONE    *
// *                           3.  Expected/actual cleanup DONE  *
// *                           4.  Bug? Seems to convert Polish  *
// *                               expression to value of first  *
// *                               token without complaint       *
// *                               FIXED                         *
// *                           5.  Minor bug: extra spaces in    *
// *                               polish expression FIXED       *
// *                           6.  Bugs as found by anon         *
// *                               8.1 1)  FIXED                 *
// *                               8.2 (((1)))) FIXED            *
// *                           7.  Predetermine malloc using     *
// *                               number of symbols other than  *
// *                               parentheses and white space   *
// *                                                             *
// * 11 04 09   Nilges         Version 3                         *
// *                           1.  Predetermine malloc using     *
// *                               infix length times two        *
// *                           2.  Detab code for posting        *
// *                           3.  Free polish expression after  *
// *                               displaying it in testcase()   *
// *                               as noticed by Seebs and       *
// *                               recommended by Schildt        *
// *                           4.  Display purpose of code on    *
// *                               entry                         *
// *                           5.  Option to specify malloc on   *
// *                               command line for Polish       *
// *                               expression (primarily to test *
// *                               storage usage)                *
// *                                                             *
// * I S S U E S ----------------------------------------------- *
// *   DATE     POSTER         DESCRIPTION AND RESOLUTION        *
// * --------   ---------      --------------------------------- *
// * 11 03 09   Nilges         Version 4 plan                    *
// *                           1.  Random expressions            *
// *                           2.  Integrate in GUI with C sharp,*
// *                               versions from Gene, Seebach   *
// *                               & anon                        *
// *                           3.  Post versions from Gene and   *
// *                               Anon and Seebach version      *
// *                                                             *
// ***************************************************************

#include <stdio.H>
#include <stdlib.H>

// ***** Constants ***********************************************
#define ABOUT_INFO \
"This application converts infix to Polish notation using a simple
grammar-based approach."

// ***** Macros **************************************************

// --- Pass over white space
#define SKIP_WHITE_SPACE(s, i, e) \
    { for(; (i) <=3D (e) && (s)[(i)] =3D=3D ' '; (i)++ ); }

// --- Return maximum value
#define MAX(x, y) ((x) > (y) ? (x) : (y))

// ***** Function index ******************************************
#define ADDFACTOR \
        int addFactor(char *strInfix, \
                      char *strPolish, \
                      int *intPtrIndex, \
                      int intEnd, \
                      int intMaxPolishLength)
ADDFACTOR;
#define ERRORHANDLER \
        int errorHandler(char *strMessage)
ERRORHANDLER;
#define ERRORHANDLERSYNTAX \
        int errorHandlerSyntax(int intIndex, \
                               char *strMessage, \
                               char *strInfix)
ERRORHANDLERSYNTAX;
#define EXPRESSION \
        int expression(char *strInfix, \
                       char *strPolish, \
                       int *intPtrIndex, \
                       int intEnd, \
                       int intMaxPolishLength)
EXPRESSION;
#define FINDCHARS \
        int findChars(char *strInstring, \
                      char *strFind, \
                      int intStartIndex)
FINDCHARS;
#define INFIX2POLISH \
        int infix2Polish(char *strInfix, \
                         char *strPolish, \
                         int intMaxPolishLength)
INFIX2POLISH;
#define MAIN \
        int main(int intArgCount, \
                 char *strArgs[])
MAIN;
#define MULFACTOR \
        int mulFactor(char *strInfix, \
                      char *strPolish, \
                      int *intPtrIndex, \
                      int intEnd, \
                      int intMaxPolishLength)
MULFACTOR;
#define STRING2UNSIGNEDINT \
        int string2UnsignedInt(char *strInstring)
STRING2UNSIGNEDINT;
#define STRINGAPPENDCHAR \
        int stringAppendChar(char *strString, \
                             char chrNew, \
                             int intMaxLength, \
                             int intSpaceBefore)
STRINGAPPENDCHAR;
#define STRINGLENGTH \
        int stringLength(char *strInstring)
STRINGLENGTH;
#define TESTCASE \
        void testCase(char *strInfix, \
                      char *strExpected, \
                      int intMalloc)
TESTCASE;
#define TESTER \
        void tester(int intMalloc)
TESTER;

// ***** Functions ***********************************************

// ---------------------------------------------------------------
// Command line handler
//
// int main(int intArgCount, char **strArgs)
//
MAIN
{
    int intMalloc =3D -1;
    printf("%s\n\n", ABOUT_INFO);
    if (intArgCount > 1)
        if ((intMalloc =3D string2UnsignedInt(strArgs[1])) < 0)
        {
            printf("%sInvalid malloc request %s\n", intMalloc);
            return;
        }
    tester(intMalloc);
    printf("\n\nTesting complete: check output for correctness");
    return;
}

// ---------------------------------------------------------------
// Parse add factor
//
// int addFactor(char *strInfix,
//               char *strPolish,
//               int *intPtrIndex,
//               int intEnd,
//               int intMaxPolishLength)
//
// addFactor =3D mulFactor [ *|/ mulFactor ]
//
ADDFACTOR
{
    char chrMulOp =3D ' ';
    int intStartIndex =3D 0;
    if (!mulFactor(strInfix,
                   strPolish,
                   intPtrIndex,
                   intEnd,
                   intMaxPolishLength))
    {
        errorHandlerSyntax(*intPtrIndex,
                           "mulFactor not found",
                           strInfix);
        return 0;
    }
    if (*intPtrIndex > intEnd) return -1;
    intStartIndex =3D *intPtrIndex;
    while (1)
    {
        SKIP_WHITE_SPACE(strInfix, (*intPtrIndex), intEnd)
        if (*intPtrIndex > intEnd) break;
        if ((chrMulOp =3D strInfix[*intPtrIndex]) !=3D '*'
            &&
            chrMulOp !=3D '/')
            return -1;
        (*intPtrIndex)++;
        if (*intPtrIndex > intEnd
            ||
            !mulFactor(strInfix,
                       strPolish,
                       intPtrIndex,
                       intEnd,
                       intMaxPolishLength))
            return errorHandlerSyntax
                   (*intPtrIndex,
                    "Mul/div op not followed by mulFactor",
                    strInfix);
        if (!stringAppendChar(strPolish,
                              chrMulOp,
                              intMaxPolishLength,
                              1)) return 0;
    }
    return -1;
}

// ---------------------------------------------------------------
// Error handler
//
// int errorHandler(char *strMessage)
//
ERRORHANDLER
{
    printf("\n%s\n", strMessage); return 0;
}

// ---------------------------------------------------------------
// Syntax error handler
//
// int errorHandlerSyntax(int intIndex,
//                        char *strMessage,
//                        char *strInfix)
//
ERRORHANDLERSYNTAX
{
    int intIndex1 =3D 0;
    printf("\nError at character %d: %s\n",
           intIndex,
           strMessage);
    printf("%s\n", strInfix);
    for (intIndex1 =3D 0; intIndex1 < intIndex; intIndex1++)
        printf(" ");
    printf("$");
    return 0;
}

// ---------------------------------------------------------------
// Parse expression
//
// int expression(char *strInfix,
//                  char *strPolish,
//                  int *intPtrIndex,
//                  int intEnd,
//                int intMaxPolishLength)
//
EXPRESSION
{   /* expression =3D addFactor [ +|- addFactor ] */
    char chrAddOp =3D ' ';
    int intStartIndex =3D 0;
    if (!addFactor(strInfix,
                   strPolish,
                   intPtrIndex,
                   intEnd,
                   intMaxPolishLength))
    {
        errorHandlerSyntax(*intPtrIndex,
                           "addFactor not found",
                           strInfix);
        return 0;
    }
    intStartIndex =3D *intPtrIndex;
    while (1)
    {
        SKIP_WHITE_SPACE(strInfix, (*intPtrIndex), intEnd)
        if (*intPtrIndex > intEnd) break;
        if ((chrAddOp =3D strInfix[*intPtrIndex]) !=3D '+'
            &&
            chrAddOp !=3D '-')
            return
             errorHandlerSyntax
             (*intPtrIndex,
              "Unrecognizable char found instead of add op",
              strInfix);
        (*intPtrIndex)++;
        if (*intPtrIndex > intEnd
            ||
            !addFactor(strInfix,
                       strPolish,
                       intPtrIndex,
                       intEnd,
                       intMaxPolishLength))
            return errorHandlerSyntax
                   (*intPtrIndex,
                    "Add/sub op not followed by addFactor",
                    strInfix);
        stringAppendChar(strPolish,
                         chrAddOp,
                         intMaxPolishLength,
                         1);
    }
    return -1;
}

// ---------------------------------------------------------------
// Find one of a set of alternative characters
//
// int findChars(char *strInstring,
//               char *strFind,
//               int intStartIndex)
//
FINDCHARS
{
    int intIndex1 =3D intStartIndex;
    int intIndex2 =3D 0;
    for (; strInstring[intIndex1] !=3D '\0'; intIndex1++)
        for (intIndex2 =3D 0;
             strFind[intIndex2] !=3D '\0';
             intIndex2++)
            if (strInstring[intIndex1] =3D=3D strFind[intIndex2])
                return intIndex1;
    return intIndex1;
}

// ---------------------------------------------------------------
// Convert infix to Polish
//
// int infix2Polish(char *strInfix, int intMalloc)
//
INFIX2POLISH
{
    int intIndex =3D 0;
    int intLength =3D stringLength(strInfix);
    strPolish[0] =3D '\0';
    if (!expression(strInfix,
                    strPolish,
                    &intIndex,
                    intLength - 1,
                    intMaxPolishLength))
    {
        errorHandler("Error");
        return 0;
    }
    return -1;
}

// ---------------------------------------------------------------
// Parse multiplication factor
//
// int mulFactor(char *strInfix,
//               char *strPolish,
//               int *intPtrIndex,
//               int intEnd,
//               int intMaxPolishLength)
//
// mulFactor =3D LETTER | NUMBER | '(' expression ')'
//
MULFACTOR
{
    int intIndexStart =3D 0;
    int intLevel =3D 0;
    char chrNext =3D ' ';
    int intInner =3D 0;
    int intSpaceBefore =3D 0;
    SKIP_WHITE_SPACE(strInfix, (*intPtrIndex), intEnd)
    if (*intPtrIndex > intEnd)
        return errorHandlerSyntax(*intPtrIndex,
                                  "mulFactor unavailable",
                                  strInfix);
    chrNext =3D strInfix[*intPtrIndex];
    if (chrNext >=3D 'a' && chrNext <=3D 'z')
    {
        (*intPtrIndex)++;
        return stringAppendChar(strPolish,
                                chrNext,
                                intMaxPolishLength,
                                1);
    }
    intIndexStart =3D *intPtrIndex;
    intSpaceBefore =3D -1;
    while(*intPtrIndex <=3D intEnd
          &&
          (chrNext =3D strInfix[*intPtrIndex]) >=3D '0'
          &&
          chrNext <=3D '9')
    {
        if (!stringAppendChar(strPolish,
                              chrNext,
                              intMaxPolishLength,
                              intSpaceBefore))
            return 0;
        intSpaceBefore =3D 0;
        (*intPtrIndex)++;
    }
    if (*intPtrIndex > intIndexStart)
        return -1;
    if (chrNext =3D=3D '(')
    {
        intLevel =3D 1;
        (*intPtrIndex)++;
        intInner =3D *intPtrIndex;
        while (intLevel > 0 && *intPtrIndex <=3D intEnd)
        {
            if ((chrNext =3D strInfix[(*intPtrIndex)++]) =3D=3D '(')
            {
                intLevel++;
            }
            else
            {
                if (chrNext =3D=3D ')')
                {
                    intLevel--;
                }
            }
        }
        if (intLevel !=3D 0)
            return errorHandlerSyntax
                   (*intPtrIndex,
                    "Unbalanced left parenthesis",
                    strInfix);
        if (!expression(strInfix,
                        strPolish,
                        &intInner,
                        *intPtrIndex - 2,
                        intMaxPolishLength))
            return errorHandlerSyntax
                   (intInner,
                    "Expression doesn't appear in parentheses",
                    strInfix);
        return -1;
    }
    return 0;
}

// ---------------------------------------------------------------
// Convert string to an unsigned integer
//
//      int string2UnsignedInt(char *strInstring)
//
//
STRING2UNSIGNEDINT
{
    int intIndex1 =3D 0;
    int intValue =3D 0;
    for (; strInstring[intIndex1] !=3D '\0'; intIndex1++)
    {
        if (strInstring[intIndex1] < '0'
            ||
            strInstring[intIndex1] > '9') break;
        intValue =3D intValue * 10
                   +
                   strInstring[intIndex1] - (int)'0';
    }
    return intValue;
}

// ---------------------------------------------------------------
// Append character to string
//
// int stringAppendChar(char *strInstring,
//                       char chrNew,
//                        int intMaxLength,
//                      int intSpaceBefore)
//
STRINGAPPENDCHAR
{
    int intLength =3D stringLength(strString);
    int intSpaceBeforeInEffect =3D
        intSpaceBefore
        &&
        intLength > 0
        &&
        strString[intLength - 1] !=3D ' ';
    if (intLength
        >=3D
        intMaxLength - (intSpaceBeforeInEffect ? 2 : 1))
    {
        errorHandler
            ("Cannot append character(s): insufficient storage");
        return 0;
    }
    if (intSpaceBeforeInEffect)
    {
        strString[intLength++] =3D ' ';
    }
    strString[intLength] =3D chrNew;
    strString[intLength + 1] =3D '\0';
    return -1;
}

// ---------------------------------------------------------------
// Return string length
//
// int stringLength(char *strInstring)
//
STRINGLENGTH
{
    int intIndex1;
    for (intIndex1 =3D 0;
         strInstring[intIndex1] !=3D '\0';
         intIndex1++) { }
    return intIndex1;
}

// ---------------------------------------------------------------
// Test case
//
// void testCase(char *strInfix, char *strExpected, int intMalloc)
//
TESTCASE
{
    char *strPolish;
    int intMaxPolishLength =3D 0;
    int intReq =3D intMalloc > 0
                 ?
                 intMalloc
                 :
                 MAX((intMaxPolishLength
                      =3D
                      stringLength(strInfix) << 1)
                     +
                     1,
                     10);
    printf("\n\nConverting \"%s\": expect \"%s\"",
           strInfix,
           strExpected);
    strPolish =3D (char *)malloc(intReq);
    if (strPolish =3D=3D 0)
        errorHandler("Can't get storage");
    printf("\n\"%s\"\n",
           (infix2Polish(strInfix,
                         strPolish,
                         intMaxPolishLength)
            ?
            strPolish
            :
            "Conversion failed"));
    free(strPolish); // cf. Schildt, C: the Complete Reference
}

// ---------------------------------------------------------------
// Tester
//
// void tester()
//
TESTER
{
    testCase("1", "1", intMalloc);
    testCase("1+1", "1 1 +", intMalloc);
    testCase("(10+613)*a", "10 613 + a *", intMalloc);
    testCase(")", "Error", intMalloc);
    testCase("1)", "Error", intMalloc);
    testCase("(((1))))", "Error", intMalloc);
    testCase("10 113 + a *", "Error", intMalloc);
    testCase("(10 + 113) * a", "10 113 + a *", intMalloc);
    testCase(" ( 10 + 113 ) *  a  ", "10 113 + a *", intMalloc);
    testCase("(", "Error", intMalloc);
    testCase("((((2", "Error", intMalloc);
    testCase("////2", "Error", intMalloc);
    testCase("", "Error", intMalloc);
    testCase("()", "Error", intMalloc);
    testCase("(((5))", "Error", intMalloc);
    testCase("(((5)))", "5", intMalloc);
    testCase("((5))", "5", intMalloc);
    testCase("5", "5", intMalloc);
    testCase("((10+(113-(2+((((((2/(4+3)))))))+2+2))))*a", "10 113 2 2
4 3 + / + 2 + 2 + - + a *", intMalloc);
    testCase("a", "a", intMalloc);
    testCase("   a  +  b ", "a b +", intMalloc);
    testCase("   a  +  b ", "Malloc bound failure", 5);
}
0
spinoza1111 (3246)
11/6/2009 4:52:43 AM
spinoza1111 <spinoza1111@yahoo.com> writes:

> #define ADDFACTOR \
>         int addFactor(char *strInfix, \
>                       char *strPolish, \
>                       int *intPtrIndex, \
>                       int intEnd, \
>                       int intMaxPolishLength)
> ADDFACTOR;

This is a very strange coding style.
-- 
Ben Pfaff 
http://benpfaff.org
0
blp (3955)
11/6/2009 5:00:36 AM
On Nov 6, 1:00=A0pm, Ben Pfaff <b...@cs.stanford.edu> wrote:
> spinoza1111<spinoza1...@yahoo.com> writes:
> > #define ADDFACTOR \
> > =A0 =A0 =A0 =A0 int addFactor(char *strInfix, \
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 char *strPolish, \
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int *intPtrIndex, \
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int intEnd, \
> > =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 int intMaxPolishLength)
> > ADDFACTOR;
>
> This is a very strange coding style.

That is an unconstructive comment. 99.999% of code (esp C) doesn't
work and sucks stylistically. he only decent code I ever saw besides
my own and a man who was bullied at Bell Northern Research was by John
Nash. Anyway, when in Rome, don't do as the Romans do, especially if
they are a pack of bloody fools as is on display in this ng.
> --
> Ben Pfaffhttp://benpfaff.org

0
spinoza1111 (3246)
11/6/2009 5:07:57 AM
On Nov 6, 2:55=A0am, Keith Thompson <ks...@mib.org> wrote:
> Nick Keighley <nick_keighley_nos...@hotmail.com> writes:
>
> [...]> you could use a macro and diffuse all these arguments
>
> > #define TRUE -1
>
> > I quite like the grammer driven approach as an idea.
>
> [...]
>
> I think you mean
>
> #define TRUE (-1)
>
> And if I saw that, I'd still wonder why the author used -1 rather
> than 1.
>
> My own favorite way to define a Boolean type in C (if <stdbool.h>
> isn't available) is
>
> =A0 =A0 typedef enum { false=3D0, true=3D1 } bool;
>
> where the "=3D0" and "=3D1" are superfluous, but nice to have for
> emphasis.
>
> But as long as you maintain the habit of *never* comparing for
> equality to true or false, you can probably use any non-zero value you
> like for true.

That is correct. And what's the best? The one you can see on blue
screen of death style dumps? When twos complement is in use?

My stars it is -1.

Case closed.

Course I never get blue screen of death but you should use it in the
event you do.
>
> --
> Keith Thompson (The_Other_Keith) ks...@mib.org =A0<http://www.ghoti.net/~=
kst>
> Nokia
> "We must do something. =A0This is something. =A0Therefore, we must do thi=
s."
> =A0 =A0 -- Antony Jay and Jonathan Lynn, "Yes Minister"

0
spinoza1111 (3246)
11/6/2009 5:10:27 AM
On 2009-11-06, Ben Pfaff <blp@cs.stanford.edu> wrote:
> spinoza1111 <spinoza1111@yahoo.com> writes:

>> #define ADDFACTOR \
>>         int addFactor(char *strInfix, \
>>                       char *st