Hi,
Yes, I tried to use recursive descent parsing techniques but ended up
with too many complications that are not justified for the simple
syntax rules that I have.
In short I am trying to parse Boolean expressions like the following
to verify their syntax.
a) (a+!b).(!!c+d)
b) ((w+!!!c).(!e+((!
Hi,
Syntax:
a) (a+!b).(c+(!q))
b) (q+r).!w
For the simple syntax rules I have, code was getting too complicated
using recursive descent parsing. So, I switched algorithm to use an
old algorithm I used some 20 years ago to implement algebraic
expression parsing. In this algorithm tokens are
Edward Bartolo:
...
> I am attaching the source file for comments for all those who may want
> to comment.
If you want to compare, have a look:
http://turkos.aspodata.se/git/c/libaspoutil/parse.h
http://turkos.aspodata.se/git/c/libaspoutil/parse.c
Regards,
/Karl Hammar
Hi,
I think the code I am attaching can correctly find errors in Boolean
expressions of the type:
a) (a+b).(c+d)
b) ((a+!d).(!c+e))
c) (!!!a+(!d)).(c+f)
It should also be able to use identifiers with more than one letter like:
a) _abc
b) _12b
c) abc2
The Algorithm:
After many hours of pulli
Hi,
I think the code I am attaching can correctly find errors in Boolean
expressions of the type:
a) (a+b).(c+d)
b) ((a+!d).(!c+e))
c) (!!!a+(!d)).(c+f)
It should also be able to use identifiers with more than one letter like:
a) _abc
b) _12b
c) abc2
The Algorithm:
After many hours of pulli
Hi,
I think the code I am attaching can correctly find errors in Boolean
expressions of the type:
a) (a+b).(c+d)
b) ((a+!d).(!c+e))
c) (!!!a+(!d)).(c+f)
It should also be able to use identifiers with more than one letter like:
a) _abc
b) _12b
c) abc2
The Algorithm:
After many hours of pulli
On Fri, Jul 08, 2016 at 05:05:29PM +0100, KatolaZ wrote:
> On Fri, Jul 08, 2016 at 11:48:25AM -0400, Hendrik Boom wrote:
>
> [cut]
>
> > >
> > > I am not asking because I want to be pedantic, but rather because this
> > > is usually where parsing context-free languages becomes an enormous
> > >
On Fri, Jul 08, 2016 at 11:48:25AM -0400, Hendrik Boom wrote:
[cut]
> >
> > I am not asking because I want to be pedantic, but rather because this
> > is usually where parsing context-free languages becomes an enormous
> > error-prone mess, and is the reason why we have tools like lex/flex
> > a
On Fri, Jul 08, 2016 at 07:03:36AM +0100, KatolaZ wrote:
> On Fri, Jul 08, 2016 at 06:26:35AM +0200, Edward Bartolo wrote:
> > Hi,
> >
> > Since any grammar item has boundaries it makes sense for a syntax
> > checker to pass boundaries to syntax checking functions. The first
> > step would be to
Peter Olson wrote:
> What happens with
>
> a = b((7, c[3)])
Unless it's a really strange syntax, IMO that should throw up an error when it
hits the ")" after the "3".
Taking a step back a few messages, under what conditions would it not work to
recurse down each time an opening tag is found
On Fri, Jul 08, 2016 at 02:18:46AM -0400, Peter Olson wrote:
> > On July 8, 2016 at 12:26 AM Edward Bartolo wrote:
>
>
> > Since any grammar item has boundaries it makes sense for a syntax
> > checker to pass boundaries to syntax checking functions. The first
> > step would be to check the exis
> On July 8, 2016 at 12:26 AM Edward Bartolo wrote:
> Since any grammar item has boundaries it makes sense for a syntax
> checker to pass boundaries to syntax checking functions. The first
> step would be to check the existence of an opening bracket and a
> closing bracket. If more brackets fol
On Fri, Jul 08, 2016 at 06:26:35AM +0200, Edward Bartolo wrote:
> Hi,
>
> Since any grammar item has boundaries it makes sense for a syntax
> checker to pass boundaries to syntax checking functions. The first
> step would be to check the existence of an opening bracket and a
> closing bracket. If
On Thu, Jul 07, 2016 at 10:57:23PM +0100, Rainer Weikusat wrote:
> Didier Kryn writes:
> > Le 07/07/2016 19:25, Rainer Weikusat a écrit :
> >> The conversion happened implicitly as part of an assignment and the Ada
> > There isn't implicit conversion in Ada.
>
> I vaguely imagine writing some
Hi,
Since any grammar item has boundaries it makes sense for a syntax
checker to pass boundaries to syntax checking functions. The first
step would be to check the existence of an opening bracket and a
closing bracket. If more brackets follow the process should be
repeated.
I think, this strateg
Didier Kryn writes:
> Le 07/07/2016 19:25, Rainer Weikusat a écrit :
>> The conversion happened implicitly as part of an assignment and the Ada
> There isn't implicit conversion in Ada.
I vaguely imagine writing somewhat more than 'the Ada runtime threw an
exception because it was asked to do
Le 07/07/2016 19:25, Rainer Weikusat a écrit :
The conversion happened implicitly as part of an assignment and the Ada
There isn't implicit conversion in Ada. No way. Conversions have to
be explicit.
Didier
___
Dng mailing list
Dng@lists.dyn
Didier Kryn writes:
> Le 04/07/2016 17:20, Rainer Weikusat a écrit :
>> Didier Kryn writes:
>>> Le 03/07/2016 23:17, Hendrik Boom a écrit :
On Fri, Jun 24, 2016 at 01:36:14PM -0400, Peter Olson wrote:
> Can I download your compiler that fixes all my mistakes? I could really
>
On Thu, Jul 07, 2016 at 03:20:09PM +0200, Edward Bartolo wrote:
> Hi,
>
> The parser code compiles and runs without access violations
> (segmentation faults) but I made a huge mistake in the parser
> algorithm. I mistakenly assumed that any number of consecutive open
> brackets all have the same i
Hi,
The parser code compiles and runs without access violations
(segmentation faults) but I made a huge mistake in the parser
algorithm. I mistakenly assumed that any number of consecutive open
brackets all have the same interpretation, which is wrong.
Notwithstanding the parser still does not w
Hi,
Re-examining the Syntax Rules for the Boolean expressions I mentioned
earlier, I updated the syntax rules as follows:
Expressions of the form: (!AvB)^(Cv!D)
Syntax Rules:
a) operand = identifier
b) term = operand [ operator-->operand ... ]
c) sub-expression = term [ operator-->term ... ]
d)
On Wed, Jul 06, 2016 at 08:16:12AM +0100, KatolaZ wrote:
> On Wed, Jul 06, 2016 at 08:54:12AM +0200, Edward Bartolo wrote:
> > Hi,
> >
> > It seems the interest to give me feedback about what I am studying and
> > coding is dwindling rapidly. Nevertheless, I am coding a parser in C.
> > I have alr
Hi,
Analising the expression grammar, I found these syntax rules to be
checked by the parser.
Boolean Expressions like: (AvB)^(!CvD)
Key for Syntax Rules:
a) [ ] means whatever is in the brackets is optional
b) ... means repeat the latter
c) no brackets mean compulsory syntax
Syntax Rules:
i)
On Wed, Jul 06, 2016 at 08:54:12AM +0200, Edward Bartolo wrote:
> Hi,
>
> It seems the interest to give me feedback about what I am studying and
> coding is dwindling rapidly. Nevertheless, I am coding a parser in C.
> I have already coded the tokeniser and tested it. Next, I will
> dedicate my ef
Hi,
It seems the interest to give me feedback about what I am studying and
coding is dwindling rapidly. Nevertheless, I am coding a parser in C.
I have already coded the tokeniser and tested it. Next, I will
dedicate my efforts to the actual parsing. I am writing a syntax
checker for simple boolea
Hi, further debugging (gdb) uncovered two little coding errors (bugs).
The following is the corrected code.
---
#include
#include
#include
#include
#define token_delta 50
typedef char* pchar;
pchar* tokens;
int token_count = 0;
void tokenise(char* expression) {
char ch;
Hi,
To improve my coding proficiency I am coding a simple parser for
expressions like (Av!B)^(DvE). The parser's aim is to detect syntax
errors in the expression.
I have just completed the tokeniser. The main function calls the
tokeniser and then lists the tokens for feedback. I have yet to code
Le 04/07/2016 17:20, Rainer Weikusat a écrit :
Didier Kryn writes:
Le 03/07/2016 23:17, Hendrik Boom a écrit :
On Fri, Jun 24, 2016 at 01:36:14PM -0400, Peter Olson wrote:
Can I download your compiler that fixes all my mistakes? I could really use
such a tool.
Yes, as a matter of fat you
Didier Kryn writes:
> Le 03/07/2016 23:17, Hendrik Boom a écrit :
>> On Fri, Jun 24, 2016 at 01:36:14PM -0400, Peter Olson wrote:
>>
>>> Can I download your compiler that fixes all my mistakes? I could really
>>> use such a tool.
>> Yes, as a matter of fat you can -- almost.
>>
>> Two languages
Le 03/07/2016 23:17, Hendrik Boom a écrit :
On Fri, Jun 24, 2016 at 01:36:14PM -0400, Peter Olson wrote:
Can I download your compiler that fixes all my mistakes? I could really use
such a tool.
Yes, as a matter of fat you can -- almost.
Two languages I use have the property that once the pr
On Fri, Jun 24, 2016 at 01:36:14PM -0400, Peter Olson wrote:
>
> Can I download your compiler that fixes all my mistakes? I could really use
> such a tool.
Yes, as a matter of fat you can -- almost.
Two languages I use have the property that once the program gets
through the compiler, almost
Hi,
Studying and Practicing Pointers: (exercise5-4)
#include
#include
int strend(char* s, char* t) {
char* saved_t = t;
for (; *t; t++);
for (; *s; s++);
while (*--t == *--s);
return (t + 1 == saved_t);
}
int main() {
char a[] = "mouse, cat, d
Hi,
<<
while(*t++ = *s++);
>>
Using the operator priority table, ++ have the highest priority and
evaluation takes place left-to-right. This increments the pointers.
Next, * is 'evaluated' right-to-left. This has the effect of
dereferencing both pointers. Thirdly, the assignment operator '=' is
Hi,
I mistakenly wrote:
<<
*t++ means first increment the pointer, then dereference it,
otherwise this wouldn't work.
*/
while(*t++ = *s++);
}
>>
*t++ means first dereference, then increment. Since we have an
assignment both incremented pointers are not used for the assignment
of the characters
Hi,
I am now studying pointers my "weakest" part of the language. The
following is a program I wrote as an exercise to mimic what strcat
does in a very rudimentary way. Please, be aware this is only to serve
as an exercise and NOT to reinvent the standard functions.
#include
#include
/* assume
On Wed, Jun 29, 2016 at 06:36:25AM -0400, Peter Olson wrote:
> n 2016-06-29 06:00, Didier Kryn wrote:
> > Le 29/06/2016 11:54, Peter Olson a écrit :
>
> [..]
>
> >> They are talking about numbers, so the largest such number is the most
> >> negative.
> >>
> >> You might want to think about what
n 2016-06-29 06:00, Didier Kryn wrote:
> Le 29/06/2016 11:54, Peter Olson a écrit :
[..]
>> They are talking about numbers, so the largest such number is the most
>> negative.
>>
>> You might want to think about what is being said before you make a claim
>> that something is idiotic.
>
>
Le 29/06/2016 11:54, Peter Olson a écrit :
Do these authors understand what negative numbers are?! Describing
>-(2^(wordsize - 1)) as the LARGEST negative number clearly shows they
>have no idea!
>
>For the set of integers, as is the case above, the largest negative
>number is -1. The negative nu
> On June 29, 2016 at 3:06 AM Edward Bartolo wrote:
> Pg 78. "... our version of itoa does not handle the largest negative
> number, that is, the value of n equal to -(2^(wordsize - 1))".
>
> Do these authors understand what negative numbers are?! Describing
> -(2^(wordsize - 1)) as the LARGEST
ROFL.
Brexit must be having its adverse effects!
On 29/06/2016, Matthew Melton wrote:
> I think I'm being pedantic here but in the context of an 8 bit 2's
> compliment word the binary rep of -1 is and -128 is 100.
>
> So that -1 + 1 = 0 the carried bit gets dropped.
>
> So that
>
>
Hi,
You know pretty well that I am in the right about this. Yes, it is
incorrect to state it is the largest negative number without
explicitly stating that one is talking about its modulus.
On 29/06/2016, KatolaZ wrote:
> On Wed, Jun 29, 2016 at 09:06:22AM +0200, Edward Bartolo wrote:
>> Hi,
>
On Wed, Jun 29, 2016 at 09:06:22AM +0200, Edward Bartolo wrote:
> Hi,
>
> Pg 78. "... our version of itoa does not handle the largest negative
> number, that is, the value of n equal to -(2^(wordsize - 1))".
>
> Do these authors understand what negative numbers are?! Describing
> -(2^(wordsize -
Hi,
Pg 78. "... our version of itoa does not handle the largest negative
number, that is, the value of n equal to -(2^(wordsize - 1))".
Do these authors understand what negative numbers are?! Describing
-(2^(wordsize - 1)) as the LARGEST negative number clearly shows they
have no idea!
For the s
Rainer Weikusat writes:
> KatolaZ writes:
>> On Fri, Jun 24, 2016 at 09:44:31PM +0200, Irrwahn wrote:
>>> On Fri, 24 Jun 2016 19:41:54 +0100, Rainer Weikusat wrote:
>>> [...]
>>> > If you want
>>> > a mathematical example, picture somone always writing
>>> >
>>> > x / (1/n)
>>> >
>>> > instead
Hendrik Boom writes:
> On Sat, Jun 25, 2016 at 01:21:33AM +0200, Irrwahn wrote:
>> On Fri, 24 Jun 2016 14:33:21 -0400, Steve Litt wrote:
>> [...]
>> > I often use continue and break, but every time I do, I make a mental
>> > note that I'm decreasing modularity and thus reducing the scalability
>>
KatolaZ writes:
> On Fri, Jun 24, 2016 at 09:44:31PM +0200, Irrwahn wrote:
>> On Fri, 24 Jun 2016 19:41:54 +0100, Rainer Weikusat wrote:
>> [...]
>> > If you want
>> > a mathematical example, picture somone always writing
>> >
>> > x / (1/n)
>> >
>> > instead of
>> >
>> > x * n
>>
>> Not to un
Hi,
<<
A
switch statement cannot jump a successive number of lines but my
little example can.
>>
Rereading my previous email, I think this is a mistake on my part. A
switch's default clause can be used to execute such a number of lines.
The only thing that a switch cannot do is use a non-constant
Hi,
With a switch statement execution continues immediately after the
switch. My example also involved a chunk of code that followed the
series of if statements that was also skipped by the goto jump. A
switch statement cannot jump a successive number of lines but my
little example can. In fact, I
John Morris:
...
> Or you are doing the sort of things most C code written these days
> does. My last C program was taking to an RFID writer over a serial
> port to implement ISO 28560 standard library article tags. Bit
> fiddling is useful when the storage available on a typical RFID tag is
> le
Irrwahn:
...
> [4] http://david.tribble.com/text/goto.html
As an mental exercise, look at part II in the above, and make programs
for if/while etc. with labels and goto's.
E.g. a general loop is
loop_init();
loop_start:
loop_pre();
if (condition()) goto loop_start;
else goto loop_end;
On Sat, Jun 25, 2016 at 09:27:40AM +0200, Edward Bartolo wrote:
[cut]
>
> execution continues from here
>
> This can still be done by something like this:
> do {
> if (test1) break;
> if (test2) break;
> if (test3) break;
> ...
> if (testN) break;
>
> more code here
> } while (0);
I think,
In this discussion about 'goto' we are forgetting one important fact
about it. This is, the fact that 'goto' is simply a jump and a
corresponding lable. This makes 'goto' jumps possible at any point in
code which is absolutely not necessary. Evolving from simple 'goto'
and lable statement
On Sat, 25 Jun 2016 01:21:33 +0200
Irrwahn wrote:
> For the
> interested, David Tribble's "Go To Statement Considered
> Harmful: A Retrospective"[4] makes for a good read.
>
>
> [1] NB: "break" and "continue" are just "goto" in disguise.
>
> [2] For example in the notorious case of releasing
Hi,
Steve Litt wrote:
<<
> Bitwise Operators:
>
> Pg 63:
> /* getbits: get n bits from position p */
>
> unigned int getbits(unsigned int x, int p, int n)
> {
>return (x >> (p + 1 - n)) & ~(~0 << n);
> }
Stuff like this is the reason I soon abandoned K&R as a learning tool,
and used it only t
On Sat, Jun 25, 2016 at 01:21:33AM +0200, Irrwahn wrote:
> On Fri, 24 Jun 2016 14:33:21 -0400, Steve Litt wrote:
> [...]
> > I often use continue and break, but every time I do, I make a mental
> > note that I'm decreasing modularity and thus reducing the scalability
> > of my code. Of course, I mi
Hi all,
On 06/25/2016 12:16 AM, Irrwahn wrote:
Well, AIUI it was supposed to be a mathematical example, not a
code snippet, but apart from that — yes, indeed. Of course unless
x happens to be of floating point type, and n != 0. But then the
results for n < -1 or n > 1 would presumably come as
On Fri, 2016-06-24 at 15:11 -0400, Steve Litt wrote:
> Stuff like this is the reason I soon abandoned K&R as a learning
> tool,
> and used it only to determine the official behavior of C.
>
> Bit stuffing, sliding and masking were a tool of the assembly
> programmer
> back when your RAM could be c
On Fri, 24 Jun 2016 14:33:21 -0400, Steve Litt wrote:
[...]
> I often use continue and break, but every time I do, I make a mental
> note that I'm decreasing modularity and thus reducing the scalability
> of my code. Of course, I might have also increased my code's
> readability by reducing redunda
On Fri, 24 Jun 2016 22:36:33 +0100, Katolaz wrote:
> On Fri, Jun 24, 2016 at 09:44:31PM +0200, Irrwahn wrote:
>> On Fri, 24 Jun 2016 19:41:54 +0100, Rainer Weikusat wrote:
>> [...]
>>> If you want
>>> a mathematical example, picture somone always writing
>>>
>>> x / (1/n)
>>>
>>> instead of
>>>
>>>
On Fri, Jun 24, 2016 at 09:44:31PM +0200, Irrwahn wrote:
> On Fri, 24 Jun 2016 19:41:54 +0100, Rainer Weikusat wrote:
> [...]
> > If you want
> > a mathematical example, picture somone always writing
> >
> > x / (1/n)
> >
> > instead of
> >
> > x * n
>
> Not to undermine your point, just a mino
On Fri, 24 Jun 2016 19:41:54 +0100, Rainer Weikusat wrote:
[...]
> If you want
> a mathematical example, picture somone always writing
>
> x / (1/n)
>
> instead of
>
> x * n
Not to undermine your point, just a minor quibble: The example
is flawed in that above terms are not quite equivalent, a
Steve Litt wrote:
> On Fri, 24 Jun 2016 09:19:40 +0200
> Edward Bartolo wrote:
>
> > Bitwise Operators:
> >
> > Pg 63:
> > /* getbits: get n bits from position p */
> >
> > unigned int getbits(unsigned int x, int p, int n)
> > {
> >return (x >> (p + 1 - n)) & ~(~0 << n);
> > }
>
> Stuff li
On Fri, 24 Jun 2016 09:19:40 +0200
Edward Bartolo wrote:
> Bitwise Operators:
>
> Pg 63:
> /* getbits: get n bits from position p */
>
> unigned int getbits(unsigned int x, int p, int n)
> {
>return (x >> (p + 1 - n)) & ~(~0 << n);
> }
Stuff like this is the reason I soon abandoned K&R as
Albert van der Horst writes:
[...]
>>> Another habit I have is to avoid a statement like:
>>>
>>> if (abc == 42)
>>>
>>> and write it as
>>>
>>> if (42 == abc)
>>>
>>> instead.
>>
>> That's a habit of many people who either believe to be master yoda
>> ('Your sister she is') or who belie
On Thu, 23 Jun 2016 23:34:23 -0400 (EDT)
Peter Olson wrote:
> > On June 23, 2016 at 10:48 AM Edward Bartolo
> > wrote: if (count > 0)
> > while(putchar(' ') && --count);
>
> I strongly recommend using the continue statement here:
>
> while(putchar(' ') && --count) continue;
>
> Th
Peter Olson writes:
> On 2016-06-24 12:17, Rainer Weikusat wrote:
>> Peter Olson writes:
On June 23, 2016 at 10:48 AM Edward Bartolo wrote:
if (count > 0)
while(putchar(' ') && --count);
>>>
>>> I strongly recommend using the continue statement here:
>>>
>>> while(putc
> On June 24, 2016 at 12:45 PM Albert van der Horst
> wrote:
[...]
> Sorry, but that means your brain is not wired correctly to recognize
> == as the symmetric operation that it is.
> Would you be equally fuzzy about
> mask = 0x42 & abc;
> versus
> mask = abc & 0x42;
> ?
I'm perfectly
On 2016-06-24 12:17, Rainer Weikusat wrote:
> Peter Olson writes:
>>> On June 23, 2016 at 10:48 AM Edward Bartolo wrote:
>>> if (count > 0)
>>> while(putchar(' ') && --count);
>>
>> I strongly recommend using the continue statement here:
>>
>> while(putchar(' ') && --count) continue;
Rainer Weikusat schreef op 2016-06-24 18:17:
Peter Olson writes:
On June 23, 2016 at 10:48 AM Edward Bartolo wrote:
if (count > 0)
while(putchar(' ') && --count);
I strongly recommend using the continue statement here:
while(putchar(' ') && --count) continue;
I and I strongly
Peter Olson writes:
>> On June 23, 2016 at 10:48 AM Edward Bartolo wrote:
>> if (count > 0)
>> while(putchar(' ') && --count);
>
> I strongly recommend using the continue statement here:
>
> while(putchar(' ') && --count) continue;
I and I strongly recommend against it. The continue
On Thu, Jun 23, 2016 at 11:34:23PM -0400, Peter Olson wrote:
> > On June 23, 2016 at 10:48 AM Edward Bartolo wrote:
> > if (count > 0)
> > while(putchar(' ') && --count);
>
> I strongly recommend using the continue statement here:
>
> while(putchar(' ') && --count) continue;
>
> The
Hi,
Never mind, I understood it.
Edward
On 24/06/2016, Edward Bartolo wrote:
> Bitwise Operators:
>
> Pg 63:
> /* getbits: get n bits from position p */
>
> unigned int getbits(unsigned int x, int p, int n)
> {
>return (x >> (p + 1 - n)) & ~(~0 << n);
> }
>
> Why is the book using p + 1 - n
Bitwise Operators:
Pg 63:
/* getbits: get n bits from position p */
unigned int getbits(unsigned int x, int p, int n)
{
return (x >> (p + 1 - n)) & ~(~0 << n);
}
Why is the book using p + 1 - n?! According to my logic it should use p - 1.
Edward
__
> On June 23, 2016 at 10:48 AM Edward Bartolo wrote:
> if (count > 0)
> while(putchar(' ') && --count);
I strongly recommend using the continue statement here:
while(putchar(' ') && --count) continue;
The reason is that the semicolon by itself is almost unnoticeable and you can
cre
Hi,
I am using nano. I paste the program's output in nano and use the
cursor keys to investigate the position of tabs.
This is the final debugged version of the tab insertion program. It
assumes tabs are 8 characters apart with the first column having no
tab.
#include
/* insert tabs instead o
On Thu, Jun 23, 2016 at 02:17:37PM +0200, Edward Bartolo wrote:
> Hi,
>
> I am doing exercise 1-21 Pg 48 The C programming language" (Kernighan
> & Ritchie). Since I am finding difficulty inspecting tabs in XFCE4.10
> terminal, I would like someone to inspect this program which replaces
> repeatin
Ooops, this is the corrected program for exercise1-21
#include
/* insert tabs instead of repeated spaces
* I am assuming a tab is equivalent to 3 spaces and forgetting tabs
that are defined at specific columns */
int tab_width = 3;
void replace_spaces_with_tabs(char c) {
int count = 0;
if
Hi,
I am doing exercise 1-21 Pg 48 The C programming language" (Kernighan
& Ritchie). Since I am finding difficulty inspecting tabs in XFCE4.10
terminal, I would like someone to inspect this program which replaces
repeating spaces with tabs when there are sufficient consecutive
spaces. I am not as
Hi,
At this point of my C studies, I did a test to get feedback of my C
language learning progress. I found an online C test which consisted
of 20 questions and a time duration of 30 minutes.
Link: http://www.indiabix.com/online-test/c-programming-test/random
The test included concepts and synta
On 06/23/2016 11:26 AM, Adam Borowski wrote:
...
[1]. Actually, the English alphabet had more letters: þ, ð, ƿ[2] and ȝ, but
they got dropped as early printing presses imported from Germany lacked
these characters. Before the technology was copied and fonts could be
manufactured domestically, th
On Wed, Jun 22, 2016 at 12:35:22PM +0100, Simon Hobson wrote:
> Rainer Weikusat wrote:
> > Lastly, if the target system is Linux (as here), one can safely assume
> > that EBCDIC won't be used.
> >
> > None of this matter anyhow for solving algorithm exercises in an
> > entry-level book about a pr
On Wed, 22 Jun 2016 18:37:32 +0100, Katolaz wrote:
[...]
> It is perfectly legal in C to do something like:
>
> =
>
> int fun (int *v){
>
> v[4] = 17;
> }
>
> int fun2(char *p){
>
> p[32] = 0;
>
> }
>
> int fun3(float *f){
>
> f[7] = 3.1415;
> }
>
>
> int main(){
>
>
On Wed, Jun 22, 2016 at 08:23:08PM +0200, Irrwahn wrote:
> On Wed, 22 Jun 2016 18:37:32 +0100, Katolaz wrote:
> [...]
> > no array can be actually "passed" to function,
> [...]
>
> I'm not trying to argue against anything you wrote in your
> spot-on analysis, but regarding that one claim quoted
KatolaZ writes:
[...]
> and the reason is that arrays in C are just syntactic sugar around
> memory addresses. This has nothing to do with polymorphism or generic
> programming, and is indeed much lower-level and more basic than
> that. Simply put, arrays do not effectively *exist* in C.
This i
Hi,
These are my worked examples. I am posting just in case some may want
to comment.
exercise1-17:
-
#include
#define MAXLINE 1000 /* maximum length of line */
int lgetline(char line[], int maxline);
/* print lines longer than 80 characters */
int main() {
int len;
On Wed, 22 Jun 2016 18:37:32 +0100, Katolaz wrote:
[...]
> no array can be actually "passed" to function,
[...]
I'm not trying to argue against anything you wrote in your
spot-on analysis, but regarding that one claim quoted above
one could postulate that an exception to that rule exists
for a
On Wed, Jun 22, 2016 at 05:04:38PM +0200, Edward Bartolo wrote:
[cut]
>
> This is why I am finding it hard to logically accept that "passing by
> reference" is NOT equivalent to passing a pointer for the machine. For
> the programmer, it is using a different syntax, but the machine sees
> no dif
On Wed, 22 Jun 2016 17:04:38 +0200, Edward Bartolo wrote:
> Hi,
>
> Irrwhan35 wrote:
> <<
> There is no "passing by reference" in C. Forget it. No
> references. Only *values*. Everything is passed *by* *value* in C. You
> will never pass "an array" to a function call in C. You will instead
> pass
On Wed, 22 Jun 2016 11:15:44 +0200
Edward Bartolo wrote:
> The program:
> --
> #include
>
> void times2(int i[]) {
> i[0] = 33;
> }
Others have commented on value and reference. What I have to add is
this: Always take special care to name functions and variables
desc
On Wed, 22 Jun 2016 14:08:55 +0200
Irrwahn wrote:
> On Wed, 22 Jun 2016 12:35:22 +0100, Simon Hobson wrote:
> > I suspect we've all conversed with people who have approximately
> > zero knowledge or interest in how "the greasy bits" of the machine
> > ends up running their code. My first compute
Hi,
Irrwhan35 wrote:
<<
There is no "passing by reference" in C. Forget it. No
references. Only *values*. Everything is passed *by* *value* in C. You
will never pass "an array" to a function call in C. You will instead
pass the *value* of a *pointer* to a contiguous region of RAM which
contains th
Edward Bartolo writes:
> Now I have several exercises from "The C programming language"
> (Kernighan & Ritchie). Some question look rather challenging...
>
> I learnt arrays are always passed by reference to function calls.
As was already pointed out, all arguments to C functions are passed via
v
On Wed, 22 Jun 2016 12:35:22 +0100, Simon Hobson wrote:
> On 21 Jun 2016, at 18:50, Irrwahn wrote:
>> Source code is written for humans, not machines! Clarity and
>> simplicity can help minimize code maintenance cost, and thus
>> easily outweigh some slight runtime penalty. Whoever has found
>>
Rainer Weikusat wrote:
> Lastly, if the target system is Linux (as here), one can safely assume
> that EBCDIC won't be used.
>
> None of this matter anyhow for solving algorithm exercises in an
> entry-level book about a programming language.
On the other hand, it might just give a newbie to C
On Wed, 22 Jun 2016 11:15:44 +0200, Edward Bartolo wrote:
> I learnt arrays are always passed by reference to function calls. So,
KatolaZ already posted a very clear and correct comment
regarding by-reference vs. by-value, but anyway:
It is a fact that there are no *references* in C, but only
On Wed, Jun 22, 2016 at 11:15:44AM +0200, Edward Bartolo wrote:
> Hi,
>
> Now I have several exercises from "The C programming language"
> (Kernighan & Ritchie). Some question look rather challenging...
>
> I learnt arrays are always passed by reference to function calls. So,
> I wrote the follow
Hi,
Now I have several exercises from "The C programming language"
(Kernighan & Ritchie). Some question look rather challenging...
I learnt arrays are always passed by reference to function calls. So,
I wrote the following program to make use of this so that a variable
in main() is modified in a
On Tue, 21 Jun 2016 16:42:02 +0100, Simon Hobson wrote:
> An interesting task would be to look at the various algorithms offered, work
> out how the compiler is likely to handle them when turning into code (or even
> look at the code generated), and then work out the efficiency of the
> differen
An interesting task would be to look at the various algorithms offered, work
out how the compiler is likely to handle them when turning into code (or even
look at the code generated), and then work out the efficiency of the different
methods in terms of CPU cycles/character.
Of course, it's poss
Edward Bartolo writes:
> I am saving your program for future study as its level is beyond the
> current level I am at. I am still at page 34 ("The C programming
> language" (Kernighan & Ritchie))
This is based on another simple idea, namely, instead of using a simple
pattern-recognition automaton
1 - 100 of 104 matches
Mail list logo
