Earlier quoted context omitted.
> nobody really does that, because that would be kind of insane Yeah. That's why people don't do things in C. It's more like most C programmers probably weren't aware of this. After your comment, we'll start to see C codebases everywhere with that.
Most programmers probably weren't aware of this, but no true Scottish C programmer would be unaware of it. If you want to manipulate memory directly - which is risky though sometimes useful - C is one of the best languages in which to do it. Memory addresses are numbers, and C will let you work with those numbers in whatever way you want: add, subtract, multiply, divide... and if you didn't shudder at the suggestion…
The Descent to C (2013)
91–96 of 96 posts
Re: The Descent to C (2013)
#92Earlier quoted context omitted.
Never thought pointers could expire, but it makes sense.
That's a fairly common trap for new C coders. Setting a pointer to something on the stack and then returning that pointer when you exit the function. It's extra insidious because it will appear to be working fine until you call another function and then try to dereference the pointer. Then your data suddenly becomes corrupt even though your program was nowhere near it.
Re: The Descent to C (2013)
#93> So why is C like this, anyway? Worth mentioning that C is over 40 years old, and was designed to be easily portable across a range of machines that had less compute power and memory than today's smaller microcontrollers. As a result, a lot of things were left undefined, or were designed in a way to be easy to implement rather than easy to program for . There existed other programming languages that were better, but…
> left undefined, or were designed in a way to be easy to implement rather than easy to program for. I'd tweak your statement a little, or even a lot: "left undefined" most often meant "left to be defined by the compiler writers to fit the architecture of the underlying hardware, in a way that would make it easy to program to beneficially exploit features of the architecture"; and (yes) in a way "that would not be ve…
Re: The Descent to C (2013)
#94Some compilers and libraries, such as GNU, do have some improvements. For example, in GNU you can make zero-length arrays (which I use sometimes), ?: without anything in between (which I use often), and some other things.
They say there is no object-oriented programming in C. Well, C doesn't have object-oriented features, although you can still do some limited object-oriented stuff in cases where it is useful. For example, there is the stream object (called FILE); GNU has a fopencookie function to write your own implementation of the stream interface too, even though standard C doesn't have that.
Object-oriented programming is good for some things but too often is overused in modern programming, I think. You shouldn't need object-oriented programming for everything.
It is true that some of the undefined behaviour stuff is too confusing and perhaps should be changed; in some cases the compiler has options to control these things, such as -fwrapv (which I often use).
I like the string handling of C; you can easily skip some from the beginning, and can sometimes use the string functions with non-text data too, and it doesn't use Unicode.
It says "C lets you take the address of any variable you like", but this is not quite true. There is a "register" command which means that you cannot take the address of something.
I think that many things in C (both things that they mention and some that they don't) (including pointer arithmetic, no bound checking, untagged unions, string handling, not using Unicode, setjmp/longjmp, etc) are often advantages of C.
Re: The Descent to C (2013)
#95Earlier quoted context omitted.
What is then? When you start listing out properties you can always find an OO language that doesn't support it. But all of them support mutation.
Sure, they all support mutation. So do languages that are clearly not object oriented, like, say, ALGOL-60. (You can do mutation in Haskell, too.) So "mutation" is at least somewhat orthogonal to "object oriented". What is object oriented? It's worse than "you can find an OO language that doesn't support feature X". There are (at least) two schools of OO, and they define OO differently. There's the Alan Kay school, w…
But you can do that in C. The argument for C not being object oriented is that it does allow you do stuff that isn't object oriented, but you just said yourself that even so-called OO languages allow you to do that anyway.
Object-oriented programming is a thing that C lets you do. It's fine if it lets you do other things too.
You should check out Common Lisp's CLOS which is the best object-oriented framework I've ever used. It's nothing like the "bundle of data structure and code" you describe.
Re: The Descent to C (2013)
#96Earlier quoted context omitted.
Sure, they all support mutation. So do languages that are clearly not object oriented, like, say, ALGOL-60. (You can do mutation in Haskell, too.) So "mutation" is at least somewhat orthogonal to "object oriented". What is object oriented? It's worse than "you can find an OO language that doesn't support feature X". There are (at least) two schools of OO, and they define OO differently. There's the Alan Kay school, w…
> What both of those have in common, though, is the idea of an "object", which is a bundle of a data structure plus code. In general, the associated code is the only code that can modify the data in the structure. But you can do that in C. The argument for C not being object oriented is that it does allow you do stuff that isn't object oriented, but you just said yourself that even so-called OO languages allow you to…
As opposed to C++, which gives you a bunch of tools to help you, and to Java, which forces you.