50 new of 52 responses total.
I think that's fair. Pascal comes, originally, from a CDC background. But
that may share more in common with VMS than Unix; a few weird CDC-isms
remain in modern Pascal: the packed data types, for instance.
With respect to pointers, C makes you declare the type associated with the
pointer so it has some idea of what you're pointing at, not necessarily so
it knows how much space to reserve for it (on some machines that doesn't
matter, though on some it does). What I mean by this is that the compiler
uses the type to figure out what to do when you say, "p + 1", and p is a
pointer time. If p points to an array of characters, and the size of a
character is 1 addressing unit, then "p + 1" is the value of p plus one. On
the other hand, if p points to an array of, say, integers, and the
addressing unit of an integer is 4, then "p + 1" is the value of p plus
*four*. Why is this? Why not just let the programmer deal with it him or
herself? Because of the way that arrays are implemented: internally, a[i]
is the same as *(a + i). Incidentally, a[i] = *(a + i) = *(i + a) = i[a],
and a fun thing to play around with is the following:
char a[] = "Hi there";
int i;
for (i = 0; i < sizeof(a); i++)
printf("%c\n", i[a]);
Does that look weird? It is, but it'll compile and do what you may expect:
addition is commutative, and this is a good way to demonstrate the parity
between arrays and pointers.
But more to the point, if C required the programmer to specify explicit type
widths when incrementing pointers, it wouldn't be very portable across
platforms where type widths varied. For instance, if you hypothetically
always incremented integer pointers by four, because that's how wide
integers are on one platform, what's going to happen when you need to compile
it for a platform with integers that are 8 units wide? Or 16, 2, etc? You
would have to find all places that used points to iterate over integer
pointers and modify them, or define weird constants to increment by or
something of that nature. Of course this would extend to other data types,
as well. Eww. But I think that's the primary reason you declare types for
pointers.
I taught C a lot. My students' minds were always boggled when I pointed out that i[a] was equivalent to a[i]. Putting the intelligence about type widths in the compiler, rather than making it the programmer's responsibility as had been the case in some earlier "system programming" languages that incorporated pointer arithmetic, was a stroke of genius on the part of the designers of C.
It does sound like a good idea. It just fealt strange to someone more used to machine code and assembler.
C's portability is often overstated. Trivial programs are portable. Programs that use do anything more complicated than standard I/O generally are not, because the system libraries are not standardized. This has lead to abominations like ./configure scripts to try to automated the process of fixing up the program for each system's eccentricities.
Regarding #6; To pick a nit: the standard libraries *are* standardized. But many other useful libraries are not (or, rather standardized by different standards. For instance, POSIX and Single Unix include sockets, while Windows has winsock which is slightly different. Both are "standard," yet they differ. That's the nice thing about standards: there are so many to choose from). I've found that, if you constrain yourself to a reasonable subset of available libraries that conforms to say POSIX, you can write quite portable programs that don't require things like configure. Ironically, the problem autoconf was designed to solve has largely gone away through near-universal adoptation of C89 (the 1989 ANSI and ISO C standard - I believe ISO differs from ANSI only cosmetically, but they may have added a preface or something), POSIX and X11R6. Now it's largely used to handle differences between other, higher level librares (what version of GTK+ is installed? etc). Even where I need to account for system differences, I've found it best to implement some intermediate compatability layer, or emulate an existing, standard interface rather than resort to autoconf. But I digress.... C can be portable if used with care. If not, you'll have problems, and probably more so than with other languages!
Is it required that the sizes of char and int types be the same in C?
No, it is not. For instance, on grex, sizeof(char) = 1 and sizeof(int) = 4; this is perfectly legal.
Okay, have never seen that code before. Pretty funky. . .
Oh, that wasn't real code, just pseudo-code. You can't assign to the sizeof
operator; I'm just saying that the two are already different. In "real" C,
you could run the following on grex:
if (sizeof(char) == 1) && sizeof(int) == 4)
printf("Hey, that works...\n");
and it would print "Hey, that works...\n".
Re: 11- was talking about the a[i] == i[a] stuff, sorry. :)
Oh, okay.
I've lost my momentum in the C class because the CBT software is shoddy and yet again my lecturer has gone AWOL (different lecturer, different college). He's not replying to my emails or voicemail messages.
This response has been erased.
I have a strange problem when I compile with GCC in an xterm. Often the names of identifiers in the error messages are replaced with , an a-with-a-carat character. This doesn't happen in other terminals. It seems like it must be some kind of character encoding problem. Has anyone else run into this?
The actual character didn't appear in my post, so you'll have to use your imagination, I guess. ;)
What's your locale set to?
en_US
Hmm.. Wouldn't think you'd be getting funky international characters from gcc on purpose, then. In other terminals, are the values that are munged in xterm marked up in some way (e.g. bolded, colored, etc..)? I haven't run into that. As a practical suggestion, take a screenshot and post a query to a gcc forum with a pointer to the screenshot and I bet you'll get an answer pretty quickly.
In other terminals they're surrounded by open and close single quotes. I'm starting to think MacOS X's xterm is buggier than most.
I would be happier if I could just get xterm /on/ the MacOS X machine I have at home. MacOS X "Terminal" works after a fassion, but the colours are so screwed up that some programs end up printing white text on a white background.
Why can't you get xterm?
He can, and the "terminal" program can emulate it.
Re: 24 xterm probably requires the presence of an X server, which is another useful thing that's missing from the machine in question. I don't have the MacOS X install disc either.
You might want to look into http://www.finkproject.org/ which allows installation of UNIX-like (and Linux-like) software in Mac OS X (alongside the BSD/Mach stuff). Most people primarily get it so they can have XWindow on Mac.
I just installed X11 that I downloaded from Apple and it worked fine.
a thing u lost the central thing on this forum :D :D
this forum must be about C lenguage
printf("Hello World");
C'ya
Hi Temo. Discussions here often change topic. Where in the World do you live?
mehico.. could be tor though and jvmv in disguise..
Holy crap it's Pete. PFV What's up?
Re resp:23: You can change the background color in Terminal. BTW, the version of X11 that comes with Leopard is horrendously buggy. I ended up installing Xquartz from here, to get a working version: http://trac.macosforge.org/projects/xquartz
i live in the same world as u do... but come on.. for other topics exist other forums exit ?
somebody know books about "Object-Oriented Programming" in C ?, because now I'm reading "Object-Oriented with ANSI C" by Axel-Tobias Schreiner, but I want to know if there is others. cheers :) PS: Sorry if my english sucks :P
Most object-oriented programming books for C programmers are probably going to deal with learning C++ or Objective C or one of the other C language variants rather than try to impose object-oriented constructs on a language that isn't intended to support them.
I recommend UNIX Scripting
tod, Scripting is good, but sometimes you need something faster and powerfull, things that C can give you.
This response has been erased.
I'm curious, though -- why use C in preference to some C-like object-oriented language?
I prefer use C, so I want learn _new ways_ to write code, and one of them is the Object-Oriented paradigm, also I want improve my C skills too.
But C++, to pick the most obvious example, is (almost?) a superset of C. The additions, however, are there to support the "object-orientedness".
I don't think there's anything wrong with exploring a particular paradigm in any given language. A friend of mine - the best programmer I have ever seen - wrote basically all of his code in object oriented Macro-32 (VAX assembly language under VMS).
cross, wow your friend is a super-programmer :D I don't know, I think that could be a good idea store free-books about programming languages (and Un*x?), as a little repository in Grex :) - just an idea.
That would be pretty cool. Yup, that man has done some amazing things with computers.
so, what can we do to make real the idea? (about make a mini repository with free-books) cheers :)
Create a directory and give people write permission to it. Two issues I see: 1) Copyrights. One has to be fairly well certain that one isn't accidentally putting copyrighted material on Grex and distributing it in a manner that is inconsistent with its licensing. This is to protect Grex legally. 2) Filtering and quality control. There's a lot of good stuff out there, and a lot of really, really bad stuff. Who sorts the useful and informative from the fluff? Grex could quickly turn into yet another repository of bad web authoring documents.
I think the way to make a good repository is designate a little group to compile the stuff, and if other people wants recommend some text these must to send a message to this group. About the copyrights issues, I think this repository must have only free texts, or with the author's permission.
I agree with you on both counts. The latter is a given. :-)
More ideas??
Lots! But they should probably go into the garage conference, not here. :-)
no problem :D I'll go to the garage :D-<--< cheers
You have several choices: