7 ms·
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
by 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 agoIf 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 agoC++ =/= C
- deleted 9y ago[deleted]
- jcelerier 9y agoIf 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 agoConsidering 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 agoI 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.
- dreta 9y ago>`volatile` has pretty much no correct uses outside of accessing registers in low-level code Sorry, but what are you guys on about? You use "volatile" if you don't want the compiler to produce code that caches a variable. You use it all the time in embedded systems, or when writing multi-threaded code, etc. The usage of "volatile" is very clear, and should be well understood. "restrict" isn't used much because it's a c99 standard first of all, and second of all, it's like "inline"; it might make a difference, might not, and not a lot of people are in a situation where they have to shave off cycles.
- 3chelon 9y agoWell... the declaration you cited resolves down to a pointer to a wide integer. Part of C's simplicity is its small number of keywords, many of which have become way too overloaded as architectures have grown more advanced. The keywords were decided in the 1970s, when address spaces were 16 bits at the most. The ability to create type aliases with `typedef` has added to this apparent complexity, and this has been abused by compiler and OS vendors for decades. None of it makes the language inherently any more complex, any more than representing machine instructions by long strings of binary makes _them_ any more complex.
- jcelerier 9y ago> Well... the declaration you cited resolves down to a pointer to a wide integer With a boatload of associated semantics, quite a bunch bein in practice compiler-dependent (looking at you, MSVC volatile). And a "protected abstract virtual base pure virtual private destructor" does not mean anything -- or at least any code that compiles.
- saagarjha 9y ago> With a boatload of associated semantics, quite a bunch bein in practice compiler-dependent (looking at you, MSVC volatile). Which is not part of C. Your argument that "C is complicated" doesn't work if you cite an egregious misuse of nonstandard extensions.
- 3chelon 9y agoForgive my ignorance here, I'm genuinely intrigued: what's so special about MSVC's volatile as opposed to the regular volatile keyword?
- ci5er 9y agoStick with 1989, and you donb't have to worry about it.
- maxlybbert 9y agoI 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 agoPython 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 agoThough 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 agoC++ is a huge language by comparison, and very few people know every corner of it.
- Ace17 9y agoVery few people know every corner of the English language, or, say, French. This doesn't prevent us from communicating, though.
- LaGrange 9y agoIn 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 agoIn 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 agoGC 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 agoGo 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 agoThe 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 agoThe length of the spec isn't really relevant is it? Or are you implying that C is about as complex as Java?
- pcwalton 9y agoC 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 agoThe 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 agoI 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 agoNo, 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?
- 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 agoI 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.