8 ms·

My favorite aspect of programming in C is how little it gets in the way of the programmer. Once you become familiar with the language there is not much to looku

by rwbt 9y ago

My favorite aspect of programming in C is how little it gets in the way of the programmer. Once you become familiar with the language there is not much to lookup in the docs because it's such a small language. I might end up writing more verbose code, but it's usually very clear to me. You still can write spaghetti code but that's besides the point.

deleted 9y ago
[deleted]
ethelward 9y ago
I'm not sure I get your point. You say that C is a tiny language, hence leading to small docs, but that can be said of every language? Except that they may have larger standard libraries, but nothing stop you from using a subset of them.
- pentagonpapers 9y ago
  If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?
  - fao_ 9y ago
    C++ =/= C
    - deleted 9y ago
      [deleted]
  - jcelerier 9y ago
    If you think C is not overly complicated, just what is a static const __declspec((dllimport)) __restrict volatile unsigned long long int* and when was the last time you needed one?
    - dreta 9y ago
      Considering that half of that is not standard C code, and the other is just a standard way of declaring a pointer that doesn’t differ much in any other typed language, i don’t think you’re making a point here.
      - DSMan195276 9y ago
        I would agree, if you take out the __declspec((dllimport) then it's just a 'static const restrict volatile long long int * ', which has lots of qualifications but isn't really much more then just a pointer to a `long long`. The qualifiers make it a bit harder to reason about, but that's also why people rarely use `restrict` and `volatile` in the first place. I could be wrong but I think the above poster hasn't actually written tons of C, or else they would have picked a much more complicated example. If you throw a bunch of arrays, pointers, and function pointers in it quickly gets out of hand, like this: int (* const(*foo)(int (*)(int, int))[5])(void); That thing defines 'foo', which is a pointer to a function who's first argument is a pointer to a function return a int and taking two ints as arguments, and returns a pointer to an array of 5 const function pointers which take no arguments and return an int. Thankfully, you rarely run into something like that in the wild. And if you `typedef` the function pointers (Which is a pretty common now) it becomes tons easier to read.
        jcelerier 9y ago
        > That thing defines 'foo', which is a pointer to a function who's first argument is a pointer to a function return a int and taking two ints as arguments, and returns a pointer to an array of 5 const function pointers which take no arguments and return an int. I find this much easier to understand than something with different keywords and qualifiers. Function pointers follow some simple rules to read, but can you be sure of what `volatile` implies ?
        DSMan195276 9y ago
        > I find this much easier to understand than something with different keywords and qualifiers. Function pointers follow some simple rules to read, but can you be sure of what `volatile` implies ? Hmm, I suppose we just disagree then, which is fine. Things like `restrict` and `volatile` don't really bother me because: 1. The spots where people actually need to use them are very rare (`restrict` does have uses, but almost nobody uses it commonly. `volatile` has pretty much no correct uses outside of accessing registers in low-level code). 2. It's still just a pointer to a long long. I would need to look-up what __declspec((dllimport)) does, and I'd be highly suspicious of the use of `restrict` and `volatile` if it was not explained, but I still generally know what it is and how it can be used. Whereas with the example I gave, without staring for a long time or throwing it into a parser I can hardly tell what the type even is, let alone wrap my head around how it will be used.
  - maxlybbert 9y ago
    I know the original quote was meant as a complaint about C++, but it’s always seemed to me to be more about how people were teaching C++ in the ‘90s. What about the zinger, “if you think English is not overly complex, just what is a loud old fast tall red car, and when was the last time you needed one?” No language I’m familiar with limits the number of adjectives you can use for a single noun. That doesn’t mean you generally should string several adjectives together; usually you’re fine just saying “car,” but sometimes you need the ability to be specific. English is a complicated language, but limiting how many adjectives can apply to a particular noun would make it much worse in my opinion. As for the original question, a pure virtual function is a function that must be implemented in a derived class, while a private function is a function that can’t be accessed outside of the class, not even from derived classes. A destructor is a function used to clean up when an object goes out of scope; I don’t think anything about the destructor is important in this case, it just happens to be a convenient member function to use. The combination would make it impossible to instantiate objects of the class (because of the pure virtual function) or objects of classes that inherit from it (because the pure virtual function can’t be accessed, let alone implemented, from a derived class). That rules out much of what you’d want to do with a class. You’re left with static data and functions, and nested types. Overall, the best I can tell, you would use that to make the class imitate a namespace. But for the last twenty years, you don’t have to imitate namespaces: C++ has them. You might still find somebody trying to avoid using actual namespaces because of a vague fear of argument dependent lookup, but to be honest, I’ve never seen argument dependent lookup call the wrong function. Some programmers oppose it in principle, but in practice it doesn’t seem to cause much trouble.
- colanderman 9y ago
  Python is a tremendously complicated language, even disregarding the standard library. Understanding all the "everything-is-an-object" magic that goes on behind the scenes is a burden which C does not share. (Though, C does have its share of mental burdens. Understanding automatic type conversion is quite a beast.)
  - ethelward 9y ago
    Though I wouldn't compare python and C, as they obviously don't target the same domain, for C, you have a whole world of UB and system interaction that you also have to keep in mind which is, IMHO, worse than the thing going on in Python.
- pjc50 9y ago
  C++ is a huge language by comparison, and very few people know every corner of it.
  - Ace17 9y ago
    Very few people know every corner of the English language, or, say, French. This doesn't prevent us from communicating, though.
- LaGrange 9y ago
  In Python, you _need_ to understand the GC and its class system - even if you ignore it, the standard library doesn't. In C++ the situation is similar unless you're actually writing C and compiling it with a C++ compiler. Go is fairly small for a modern language, but it does have a GC and a fancy type system. OTOH preprocessor directives grow the base C a bit. It's still very tiny, though.
  - kevinmgranger 9y ago
    In what way do you need to understand the GC before using it? The only thing I can think of is avoiding circular references.
    - Retric 9y ago
      GC can cause a lot of issues if you care about how exactly long something takes. Like all abstractions there are corner cases that force you to deal with the underlying complexity.
    - LaGrange 9y ago
      Go ahead and allocate and deallocate lots of tiny objects in a short period of time. Depending on GC, you'll either run out of memory, or grind down to a halt.
- forgot-my-pw 9y ago
  The language specs is 700-page long, I wouldn't call that tiny: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf Sure, C++ is double of that, but it's still long. In comparison, Java language specs is around 800 pages, Ruby 330 pages, and C# 500 pages.
  - Skunkleton 9y ago
    The length of the spec isn't really relevant is it? Or are you implying that C is about as complex as Java?
    - pcwalton 9y ago
      C is significantly more complex than Java. The memory model of Java is simple (multithreading notwithstanding), because it's memory-safe and garbage collected. Not so for C, which has very subtle rules, which result in undefined behavior if broken.
      - boomlinde 9y ago
        The question here isn't whether it's easier to write correct C programs than Java programs, it's whether C is a simple language. Subtle UB, as much of a headache as it can be to a programmer using the language, in this case leads to simpler implementation of a compiler.
        kevinmgranger 9y ago
        I think you've pointed out the distinction many miss when talking about simplicity, which results in talking past each other: simplicity for the user and simplicity for the compiler writer are totally different things. Java is simpler for the user but more complex for the implementer, and C is more complex for the user but simpler for the implementer.
        pcwalton 9y ago
        No, it doesn't. Maybe it did in 1978, but modern C compilers have to go to heroic lengths to do things like alias analysis that would be easier if the aliasing rules of C weren't so subtle. In Java the question of "can pointer A alias pointer B" is simple (unless typeof A derives typeof B or vice versa, the answer is no). In C, due to TBAA, it's hideously complex.
- murukesh_s 9y ago
  "but that can be said of every language? " What about Haskell?
  - tome 9y ago
    I'm not sure what you mean. Haskell is a small language.
    - chewxy 9y ago
      GHC Core is. Haskell is far from small https://blog.chewxy.com/2014/09/03/small-languages/ https://blog.chewxy.com/2014/09/03/small-languages/
- Ace17 9y ago
  > nothing stops you from using a subset of [the standard libraries]. This only applies if you're writing 100% of the code. Not having coworkers to mess around with every corner-case of the langage is a rare privilege.
- dopamean 9y ago
  I don't write C but I have to imagine that the language being small doesn't really save you from having to look up stuff in documentation. If the language doesn't have it surely some library will and you'll have to read the docs no? The "problem" has just been outsourced.
Ace17 9y ago
> Once you become familiar with the language there is not much to lookup in the docs because it's such a small language. The same could be said about Lisp. Would you trade your C compiler for Lisp one?
- laythea 9y ago
  It is not fair to compare Lisp to C. C is much more practical.
simias 9y ago
I mostly agree but I think there are too many weird UB and corner cases to qualify as a small language. I guess C compiled with -fwrapv -fno-strict-overflow -fno-strict-aliasing and a few others might come close to what you're describing. I think C's apparent simplicity lulls me into complacency at times, I delude myself into thinking that I'm coding into some kind of macro assembly and I think I know what the resulting machine code will look like. And then some super weird optimization or UB kicks in and nothing makes sense anymore, because I stopped playing by the rules and I triggered the footgun. Just look at the number of bug reports on the GCC bugtracker for code that at a glance ought to work and it turns out that it's actually not a bug, the code just triggered a subtle UB and the compiler ran away with it and generated code that ate your cat.
- geezerjay 9y ago
  > I mostly agree but I think there are too many weird UB and corner cases to qualify as a small language. I don't see the point of your claim regarding undefined behaviour. The rules are quite simple: undefined behavior means compiler-specific behavior. Therefore, if you aim for compiler independence then you don't use it. If somehou you decide yo target a compiler then you read the compiler's docs. It's that simple. These UB complains are even more ridiculous when we realize they complain about the fact that the language is actually defined.
  - zbentley 9y ago
    > if you aim for compiler independence then you don't use [undefined behavior]. I think the point was that UB occurs in a lot of relatively common cases and programmers don't realize that they're depending on it/experiencing it. > If [somehow] you decide [to] target a compiler then you read the compiler's docs. Which is why the post you're responding to made the point about undefined behavior. "Read the compiler's docs" is in counterpoint to that post's parent, which praises C for being a small language, and thus one in which reading the language's docs is seldom required.
  - simias 9y ago
    UB is not implementation defined, it's UB. Some compilers have options to defuse certain classes of UBs but then you're effectively coding in a non-compatible dialect of C. Otherwise you can't ever rely on a certain UB behaving one way or an other: a simple compiler update, code change or compiler flag modification could break everything. A compiler is under no obligation to define what it does in case of UB and that's the point of it, it leaves some room for aggressive optimization. There are "implementation defined" details in the C standard but it's a different problem, see for instance: https://gcc.gnu.org/onlinedocs/gcc/C-Implementation.html https://gcc.gnu.org/onlinedocs/gcc/C-Implementation.html Anyway that wasn't really my point, the problem is that some of these UB can arise because of subtle bugs in code that might not look suspicious at a glance. Things like breaking aliasing rules, mis-using unions, casting things that aren't compatible etc... Your code triggers an UB and you don't know it. Actually you might not notice it until you turn an optimization flag or you update your compiler and suddenly it doesn't do what you want anymore. Even something as trivial as computing a pointer that's more than one byte after the end of an object is UB for instance (not dereferencing it, merely computing its address). For that reason `ptr.offset` in unsafe in Rust for instance, even though it doesn't dereference the pointer.

by rwbt 9y ago

deleted 9y ago

[deleted]

ethelward 9y ago

I'm not sure I get your point. You say that C is a tiny language, hence leading to small docs, but that can be said of every language? Except that they may have larger standard libraries, but nothing stop you from using a subset of them.

pentagonpapers 9y ago
If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?
- fao_ 9y ago
  C++ =/= C
  - deleted 9y ago
    [deleted]
- jcelerier 9y ago
  If you think C is not overly complicated, just what is a static const __declspec((dllimport)) __restrict volatile unsigned long long int* and when was the last time you needed one?
  - dreta 9y ago
    Considering that half of that is not standard C code, and the other is just a standard way of declaring a pointer that doesn’t differ much in any other typed language, i don’t think you’re making a point here.
    - DSMan195276 9y ago
      I would agree, if you take out the __declspec((dllimport) then it's just a 'static const restrict volatile long long int * ', which has lots of qualifications but isn't really much more then just a pointer to a `long long`. The qualifiers make it a bit harder to reason about, but that's also why people rarely use `restrict` and `volatile` in the first place. I could be wrong but I think the above poster hasn't actually written tons of C, or else they would have picked a much more complicated example. If you throw a bunch of arrays, pointers, and function pointers in it quickly gets out of hand, like this: int (* const(*foo)(int (*)(int, int))[5])(void); That thing defines 'foo', which is a pointer to a function who's first argument is a pointer to a function return a int and taking two ints as arguments, and returns a pointer to an array of 5 const function pointers which take no arguments and return an int. Thankfully, you rarely run into something like that in the wild. And if you `typedef` the function pointers (Which is a pretty common now) it becomes tons easier to read.
      - jcelerier 9y ago
        > That thing defines 'foo', which is a pointer to a function who's first argument is a pointer to a function return a int and taking two ints as arguments, and returns a pointer to an array of 5 const function pointers which take no arguments and return an int. I find this much easier to understand than something with different keywords and qualifiers. Function pointers follow some simple rules to read, but can you be sure of what `volatile` implies ?
        DSMan195276 9y ago
        > I find this much easier to understand than something with different keywords and qualifiers. Function pointers follow some simple rules to read, but can you be sure of what `volatile` implies ? Hmm, I suppose we just disagree then, which is fine. Things like `restrict` and `volatile` don't really bother me because: 1. The spots where people actually need to use them are very rare (`restrict` does have uses, but almost nobody uses it commonly. `volatile` has pretty much no correct uses outside of accessing registers in low-level code). 2. It's still just a pointer to a long long. I would need to look-up what __declspec((dllimport)) does, and I'd be highly suspicious of the use of `restrict` and `volatile` if it was not explained, but I still generally know what it is and how it can be used. Whereas with the example I gave, without staring for a long time or throwing it into a parser I can hardly tell what the type even is, let alone wrap my head around how it will be used.
- maxlybbert 9y ago
  I know the original quote was meant as a complaint about C++, but it’s always seemed to me to be more about how people were teaching C++ in the ‘90s. What about the zinger, “if you think English is not overly complex, just what is a loud old fast tall red car, and when was the last time you needed one?” No language I’m familiar with limits the number of adjectives you can use for a single noun. That doesn’t mean you generally should string several adjectives together; usually you’re fine just saying “car,” but sometimes you need the ability to be specific. English is a complicated language, but limiting how many adjectives can apply to a particular noun would make it much worse in my opinion. As for the original question, a pure virtual function is a function that must be implemented in a derived class, while a private function is a function that can’t be accessed outside of the class, not even from derived classes. A destructor is a function used to clean up when an object goes out of scope; I don’t think anything about the destructor is important in this case, it just happens to be a convenient member function to use. The combination would make it impossible to instantiate objects of the class (because of the pure virtual function) or objects of classes that inherit from it (because the pure virtual function can’t be accessed, let alone implemented, from a derived class). That rules out much of what you’d want to do with a class. You’re left with static data and functions, and nested types. Overall, the best I can tell, you would use that to make the class imitate a namespace. But for the last twenty years, you don’t have to imitate namespaces: C++ has them. You might still find somebody trying to avoid using actual namespaces because of a vague fear of argument dependent lookup, but to be honest, I’ve never seen argument dependent lookup call the wrong function. Some programmers oppose it in principle, but in practice it doesn’t seem to cause much trouble.
colanderman 9y ago
Python is a tremendously complicated language, even disregarding the standard library. Understanding all the "everything-is-an-object" magic that goes on behind the scenes is a burden which C does not share. (Though, C does have its share of mental burdens. Understanding automatic type conversion is quite a beast.)
- ethelward 9y ago
  Though I wouldn't compare python and C, as they obviously don't target the same domain, for C, you have a whole world of UB and system interaction that you also have to keep in mind which is, IMHO, worse than the thing going on in Python.
pjc50 9y ago
C++ is a huge language by comparison, and very few people know every corner of it.
- Ace17 9y ago
  Very few people know every corner of the English language, or, say, French. This doesn't prevent us from communicating, though.
LaGrange 9y ago
In Python, you _need_ to understand the GC and its class system - even if you ignore it, the standard library doesn't. In C++ the situation is similar unless you're actually writing C and compiling it with a C++ compiler. Go is fairly small for a modern language, but it does have a GC and a fancy type system. OTOH preprocessor directives grow the base C a bit. It's still very tiny, though.
- kevinmgranger 9y ago
  In what way do you need to understand the GC before using it? The only thing I can think of is avoiding circular references.
  - Retric 9y ago
    GC can cause a lot of issues if you care about how exactly long something takes. Like all abstractions there are corner cases that force you to deal with the underlying complexity.
  - LaGrange 9y ago
    Go ahead and allocate and deallocate lots of tiny objects in a short period of time. Depending on GC, you'll either run out of memory, or grind down to a halt.
forgot-my-pw 9y ago
The language specs is 700-page long, I wouldn't call that tiny: http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1570.pdf Sure, C++ is double of that, but it's still long. In comparison, Java language specs is around 800 pages, Ruby 330 pages, and C# 500 pages.
- Skunkleton 9y ago
  The length of the spec isn't really relevant is it? Or are you implying that C is about as complex as Java?
  - pcwalton 9y ago
    C is significantly more complex than Java. The memory model of Java is simple (multithreading notwithstanding), because it's memory-safe and garbage collected. Not so for C, which has very subtle rules, which result in undefined behavior if broken.
    - boomlinde 9y ago
      The question here isn't whether it's easier to write correct C programs than Java programs, it's whether C is a simple language. Subtle UB, as much of a headache as it can be to a programmer using the language, in this case leads to simpler implementation of a compiler.
      - kevinmgranger 9y ago
        I think you've pointed out the distinction many miss when talking about simplicity, which results in talking past each other: simplicity for the user and simplicity for the compiler writer are totally different things. Java is simpler for the user but more complex for the implementer, and C is more complex for the user but simpler for the implementer.
      - pcwalton 9y ago
        No, it doesn't. Maybe it did in 1978, but modern C compilers have to go to heroic lengths to do things like alias analysis that would be easier if the aliasing rules of C weren't so subtle. In Java the question of "can pointer A alias pointer B" is simple (unless typeof A derives typeof B or vice versa, the answer is no). In C, due to TBAA, it's hideously complex.
murukesh_s 9y ago
"but that can be said of every language? " What about Haskell?
- tome 9y ago
  I'm not sure what you mean. Haskell is a small language.
  - chewxy 9y ago
    GHC Core is. Haskell is far from small https://blog.chewxy.com/2014/09/03/small-languages/ https://blog.chewxy.com/2014/09/03/small-languages/
Ace17 9y ago
> nothing stops you from using a subset of [the standard libraries]. This only applies if you're writing 100% of the code. Not having coworkers to mess around with every corner-case of the langage is a rare privilege.
dopamean 9y ago
I don't write C but I have to imagine that the language being small doesn't really save you from having to look up stuff in documentation. If the language doesn't have it surely some library will and you'll have to read the docs no? The "problem" has just been outsourced.

Ace17 9y ago

> Once you become familiar with the language there is not much to lookup in the docs because it's such a small language. The same could be said about Lisp. Would you trade your C compiler for Lisp one?

laythea 9y ago
It is not fair to compare Lisp to C. C is much more practical.

simias 9y ago

I mostly agree but I think there are too many weird UB and corner cases to qualify as a small language. I guess C compiled with -fwrapv -fno-strict-overflow -fno-strict-aliasing and a few others might come close to what you're describing. I think C's apparent simplicity lulls me into complacency at times, I delude myself into thinking that I'm coding into some kind of macro assembly and I think I know what the resulting machine code will look like. And then some super weird optimization or UB kicks in and nothing makes sense anymore, because I stopped playing by the rules and I triggered the footgun. Just look at the number of bug reports on the GCC bugtracker for code that at a glance ought to work and it turns out that it's actually not a bug, the code just triggered a subtle UB and the compiler ran away with it and generated code that ate your cat.

geezerjay 9y ago
> I mostly agree but I think there are too many weird UB and corner cases to qualify as a small language. I don't see the point of your claim regarding undefined behaviour. The rules are quite simple: undefined behavior means compiler-specific behavior. Therefore, if you aim for compiler independence then you don't use it. If somehou you decide yo target a compiler then you read the compiler's docs. It's that simple. These UB complains are even more ridiculous when we realize they complain about the fact that the language is actually defined.
- zbentley 9y ago
  > if you aim for compiler independence then you don't use [undefined behavior]. I think the point was that UB occurs in a lot of relatively common cases and programmers don't realize that they're depending on it/experiencing it. > If [somehow] you decide [to] target a compiler then you read the compiler's docs. Which is why the post you're responding to made the point about undefined behavior. "Read the compiler's docs" is in counterpoint to that post's parent, which praises C for being a small language, and thus one in which reading the language's docs is seldom required.
- simias 9y ago
  UB is not implementation defined, it's UB. Some compilers have options to defuse certain classes of UBs but then you're effectively coding in a non-compatible dialect of C. Otherwise you can't ever rely on a certain UB behaving one way or an other: a simple compiler update, code change or compiler flag modification could break everything. A compiler is under no obligation to define what it does in case of UB and that's the point of it, it leaves some room for aggressive optimization. There are "implementation defined" details in the C standard but it's a different problem, see for instance: https://gcc.gnu.org/onlinedocs/gcc/C-Implementation.html https://gcc.gnu.org/onlinedocs/gcc/C-Implementation.html Anyway that wasn't really my point, the problem is that some of these UB can arise because of subtle bugs in code that might not look suspicious at a glance. Things like breaking aliasing rules, mis-using unions, casting things that aren't compatible etc... Your code triggers an UB and you don't know it. Actually you might not notice it until you turn an optimization flag or you update your compiler and suddenly it doesn't do what you want anymore. Even something as trivial as computing a pointer that's more than one byte after the end of an object is UB for instance (not dereferencing it, merely computing its address). For that reason `ptr.offset` in unsafe in Rust for instance, even though it doesn't dereference the pointer.