Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon. Entire thread

LOL IT'S C TIME

Name: Anonymous 2007-07-11 13:15 ID:hoSRp9Cj

Hi /prog/, I have some experience with C, but I don't know how to do much except take text input, save variables, calculate, and print text out. What should I read to learn to do things like display graphics, save/load files, send/receive data using ports, et cetera?

Name: Anonymous 2008-12-12 13:22

id.field // access a field of an instance of some struct.
ptr->field // dereference a pointer to struct and access a field of the resulting instance.

How the fuck is it unambiguous?
IHBT

Name: Anonymous 2008-12-12 13:24

>>38,40
OH WOW! We're seem to be having a three-way-argument here. We all disagree with each other and you both are wrong.

Name: Anonymous 2008-12-12 14:00

>>36 here
>>38
Idiot.
>>37
It's redundant.

Name: Anonymous 2008-12-12 14:01

>>41
Do you not know what unambiguous means?

Name: Anonymous 2008-12-12 14:16

>>42
We're seem to be having

Name: Anonymous 2008-12-12 15:13

>>43
I am greatly offended by you calling me dumb. Please apologize immediately or I will resort to leaving this forum.

>>41
You are missing the point. What I am offering is to make . both // access a field of an instance of some struct. and // dereference a pointer to struct and access a field of the resulting instance.. I am claiming that it won't introduce any ambiguity.

Name: Anonymous 2008-12-12 16:20

You are missing the pointer.
fix'd

Name: Anonymous 2008-12-12 17:42

>>46
It's semantically ambiguous, like overloading "+" to mean string concatenation.

Name: Anonymous 2008-12-12 18:23

I think the more important question is, why does C have -> in the first place, when the same can be accomplished by dereferencing the pointer and then referencing the member: (*a).b versus a->b.  It's much more obvious what it's doing at a glance, and if the operator precedence for such things weren't so screwy it wouldn't even be more characters to type. *a.b reads intuitively from left to right: "dereference the pointer 'a', and access field 'b'".

Name: Anonymous 2008-12-12 18:29

>>37
If redundancy was an issue, we'd all be writing in assembly.

Name: Anonymous 2008-12-12 18:58

>>50
What.

Name: Anonymous 2008-12-12 19:02

>>50
Thanks for the advice, PoppaVic.

Name: Anonymous 2008-12-12 19:20

>>49
Maybe Dennis Ritchie dislikes parentheses.

Name: Anonymous 2008-12-12 19:45

>>53
Then he should have fixed the operator precedence.

Name: Anonymous 2008-12-13 2:07

>>48
It's not it's not it's not ambiguous! Post code where it would be, then we're talking. + is not used for string catenation in C because you can't catenate strings in C. And + is very successfully used in other languages for string catenation.

Name: Anonymous 2008-12-13 2:19

>>55
CONCATENATION, you goddamn moron.

Name: Anonymous 2008-12-13 2:23

>>55
Uh, don't you mean Concatenation? Dumbass.

Name: Anonymous 2008-12-13 2:33

>>56,57
Concatenation-mind

Name: Anonymous 2008-12-13 2:54

>>56-58
No, I mean catenate.
Catenate as in ``To connect in a series of ties or links; form into a chain''.
Just like the cat program does.

Name: Anonymous 2008-12-13 3:03

Except that catenate typically refers to the chemistry definition, while concatenate refers to the CS definition. Either way, we have been trolled, or ``WHBT'' as the saying goes.

Name: Anonymous 2008-12-13 7:26

Name: Anonymous 2008-12-13 9:27

>>55
If C had a primitive string type, I doubt that "+" would be used for string concatenation, because in C EVERY DISTINCT OPERATION HAS ITS OWN EXCLUSIVE OPERATOR. Except for "-" and "*" wich have two different meanings each, especifically one meaning for the binary version and another for the unary version. But that's because you'd never mistake a binary operator for a unary one, so there's no ambiguity.

Name: Anonymous 2008-12-13 9:50

>>62
Actually a * b; is ambiguous because it can mean either `multiply a by b, then disregard the result' or `declare b as a pointer to type a'.

Name: Anonymous 2008-12-13 10:05

>>63
Touché.

Name: Anonymous 2008-12-13 10:16

>>63
I AM SHOCKED

Name: Anonymous 2008-12-13 10:16

>>63
It's not, because a is either a variable or a type name.

Name: Anonymous 2008-12-13 10:18

>>66
Which makes C's grammar non-context-free?

Name: Anonymous 2008-12-13 10:27

>>67
You don't know what "context-free grammar" means.

Name: Anonymous 2008-12-13 10:31

>>68
Indeed, I don't.

Name: Anonymous 2008-12-13 10:34

>>69
Look it up, mate. Wikipedia is just one step away.

Name: Anonymous 2008-12-13 10:52

The current state of the parser (i.e. the "context") does not have to be known in order to continue parsing correctly.

Name: Anonymous 2008-12-13 11:00

>>71
Close [spoier](well, not really)[/spoiler], but no cigar.

Name: Anonymous 2008-12-13 12:02

>>72
Close, but no spoiler.

Name: Anonymous 2008-12-13 12:05

>>73
Thanks, I hadn't noticed.

Name: Anonymous 2008-12-13 14:27

[b]THIS IS /prog/
EVERY [b[[i][o][u]BBCODE FAILURE[/i[[/b][//u]{o] WILL BE POINTED OUT
NO EXCEPTION[/b]

Name: Anonymous 2008-12-13 15:24

When you fail BBCode, you die for real.

Name: Anonymous 2008-12-13 18:04

>>75
BBCODEFAILURE

Name: Anonymous 2011-02-04 13:13

Newer Posts
Don't change these.
Name: Email:
Entire Thread Thread List