The DOJ publishes a continuation every year. But it's so hard visiting the server linked under the graph and clicking three times to find the right statistic, isn't it?
You aren't allowed to go on someone else's lawn and do what you want: it's the same thing with creations of the mind as with ownership of physical property.
My computer is not MAFIAA's lawn. Neither are the bajillion other computers, devices and wires that together form the Internet. When I create copies of content under MAFIAA monopoly, I don't go to MAFIAA's lawn to do it, I stay on my own lawn and use tools from my own house. But apparently the law allows MAFIAA to come to my lawn and tell me what I'm not allowed to do with the stuff I own. Copyright is legal violation of physical property rights.
The pirates in this article have called themselves "the Pirate Party," while engaging in contributory and vicarious copyright infringement to take the monopolies of creators away from them.
We have plenty of mass manufacturing technology in the USA. Industrial automation of current manufacturing technologies is already starting to leveling the playing field between China and industrialized nations in the rest of the world.
You know, that doesn't really help at all. If you want the economy to work, it doesn't matter whether the goods are made in China by cheap Chinese workers or by machines in your own country. The only thing that matters is whether or not all of your customers can earn back (directly or indirectly) every single cent they've paid for your goods. If they can, the economy will flourish. If they can't, it'll trigger a domino effect of poverty that will effectively remove all the people who are unable to earn their money back from you from the economy (though it may take a decade or two). That's pretty much the 2008 crisis in a nutshell. And it's also the main reason why high-tech DIY manufacturing is an economic necessity for a lot of people. Injection molding solves a technical problem but 3D printing solves an economic one.
Hint: Inductors and capacitors are made by carefully printing insulator and conductor materials in a certain pattern. They don't require a special material for themselves.
Uh, like we aren't in a mass manufacturing bonanza right now?
Yes, we are. And it's one of the main causes of our current economic problems. That's why we need to move from buying everything from east Asia to making stuff we need back home again. We don't go nuts over the technology itself, we just see a huge potential for stabilizing the economy in it. The technology is not perfect, it just happens to be the closest one to practical usability.
First off, I don't think that evolution is "unimportant." I think that its promotion within political debates to be the central topic of science education is unwarranted.
Except it is warranted by the political attacks on science led by religious nutjobs. If you think that scientists can fend off a political attack by writing scientific papers, you're naive.
Can you articulate why you think that it is all that important for it to be given emphasis in a typical public school curriculum? Honestly, I have trouble coming up with a reasonable argument for that. Most introductory biology courses focus on the mechanics of organisms, and while learning about evolution can be helpful there, I don't see it as being required.
Evolution is the thing that makes sense out of all those weird mechanics. If you want to make someone excited about computer science, you don't make him memorize menu buttons, you show him how computers really work on the inside. If you want to make someone excited about chemistry, you don't make him memorize the periodic table, you show him why it looks the way it looks and how is it useful. If you want to make someone excited about biology, you teach him evolution because that's the only way to make the pieces fit together like in the other examples I've listed. Organism mechanics are the boring facts of biology but evolution is the thing that makes it all click and the little future biologists go "Ooooh".
Now all we need are two 3D-printable materials that can form a semiconductor and an extruder design that can automatically switch between all of those materials and the 3D printing bonanza will begin.
Creationism and religion aside, where do you think our civilization is headed, what new problems await us in the near future and what should we do to solve them and keep the right direction?
If your programming style is good, you can probably figure out a way to write readable code even in Whitespace.
Now that I disagree with. I'm pretty sure it's impossible (whitespace is isomorphic to brainfuck IIRC). One has to take such programmatic circumlocquitions to fight the langage that the reaults are very opaque. Same with doing general computation in SED. It's possible: there's some amazing sed programs out there implementing dc, sokoban, and a whole load others. But they're very hard to follow even with extensive comments.
That one was a joke.
Correction: It does, you just don't know how. Writing primitive object and memory pool-based garbage collection that supports destructors takes what, 500 lines of reusable support code and 5 extra lines per pool to set it up and then clean up anything left in it? As a bonus, the garbage collector can tell you where exactly you allocated the stuff you forgot to clean up.
Sure, that applies to memory. In C++ it applies to files, locks and just about anything else as well. Also, the constructors allow for automatic initialisation of those resources too.
All constructors (except copy constructor in some cases) are called directly. The most indirection you can get is calling it through some factory object and you can do that in C as well.
Of course, you can make the pool actualy destruct non-trivial objects, but you're looking at quite a lot of work just to open and close a file (what's the scope of the pool? when do you flush it? How many file object lifetimes do you have etc), for example. The C++ version has much less boilerplate.
That's completely under your control. The most simple pool implementation I can think of would have a grand total of 6 functions: one to initialize the whole thing at the very beginning, one to clean everything up on exit, one to create new pool and push it on stack, one to pop the top pool from stack and release everything in it, one to add new object with given structure prefix (including pointer to destructor function) to the pool on top of stack (this one will be called from constructors) and one to remove an object from its pool and clean it up.
The nice thing about C++ is that you get accurate memory management basically for free with the STL, and you can always change your allocator (you can get STL pool allocators) if you find that you have a performance bottleneck.
It's never for free. There's always some kind of trade off that you have to keep in mind.
Like every feature mis-used it has severe downsides.
That's why Linus and many others think that less is sometimes more. When you have powerful features, they should at least be very hard to misuse and get away with it.
Taking your memory pool example. You need the 500 lines of support code and 5 per pool. compare that to just using a std::vector or std::string when you need it.
So much nicer to read in C++ and so much less to go wrong.
The implementation of std::vector or std::string is also 500 lines of support code.
It doesn't take that much extra effort because you can do the same damn thing as in C++.
Of course, and you can do the same things in assembler. It's easier in C ane easier still in C++.
You can even write class and function templates using preprocessor macros.
And you get a poorly specified, buggy and quite possibly slow implementation of half of C++98. Which won't catch most of the common errors. Or allow clean parameterisation without tons of syntactic overhead.
We're not talking about implementing a formal programming language. We're talking about implementing a system that works. You don't need tons of syntactic sugar for that.
So, I challenge you: find a C parser library as clean and easy
What about temporary variables that didn't get constructed in the first place?
Er, how?
IIRC in C++98 when you return objects from function by value, a temporary object is created using a copy constructor on whatever you've passed as an argument to the return statement. Then the function's stack is unwinded. Then if the return value is used in the above scope, the temporary object is passed to whatever function uses it (copy constructor, assignment operator or a function that takes a reference to the object). Then the temporary object is destroyed just before control returns to the parent function.
I'm also pretty sure that the behavior when you fall out of non-void function without returning anything is undefined so it's perfectly possible the compiler won't call constructor for the temporary object but it will call destructor later.
Yes, but the list of things you have to expect in C++ is a mile long.
No. You expect variables to have their constructor called when the enter the scope and the destructor called when they leave it. You see operator+ and know that it's just a fancy function call syntax, etc etc.
Again: exceptions, virtual methods, some uses of templates, multiple inheritance... All of that imposes restrictions on what you can do in the code that you have to keep in your head all the time. If you don't, your code will blow up sometime in the future.
And I believe that Valgrind can detect and clearly report this kind of bugs
No, it detects use of uninitialised memory, but agumenting every memory location.
IIRC Valgrind places some padding with special values between return address and local variables and then it checks that the special pattern is still there before return. If not, it'll complain.
Valgrind's report of falling out of function that is supposed to return an object by value will be really confusing.
The compiler detects it just fine.
Only as a warning that you may not notice. Or ignore because you think it's a "can't happen" situation.
Quite a lot of the code I write is numerics code. A good library like Eigen strips away all of the syntactic overhead, and replaces it with code that looks like maths. Numerics code is hard ot get right and such an assistance is immensely helpful.
Yes, because writing "plus(a,b)" is so much harder than "a+b".
Or try writing a little ad-hoc parser in C. Then try writing one in C++ using boost (Spirit).
Been there, done that. I'll see your Boost and raise you Flex+Bison.
Or try implementing a k-D tree, with priority based searching (requiring a priority queue).
As simple as writing it in C++.
All of those will be vastly shorter in C++ because C++ gives you the abstractions to create powerful libraries.
Vastly? Oh come on. The C implementation of the same thing will have about 10% more lines + some fixed amount of reusable support code. That's it. And the internal design will be exactly the same.
They'll be less buggy because the amount of code you have to write is much shorter. Every line you _don't_ write is a bug that cannot happen.
You're forgetting the little problem that you can introduce bugs by NOT writing a line of code where one is required. It applies to C++ much more than to plain C.
What about writing GUI code. Every C level GUI code I've messed with has been a right royal pain in the ass, full of boilerplate, pain and bugs. By comparison, FLTK, for instance is very, very easy. I've also heard great things about QT, though I've never used it.
I've never heard anyone say great things about writing GUIs in C. Sure it can be done. I used to know enough M*tif to be dangerous, but it is not easy, end they all involve not only haveing to learn the GUI toolkit, but also the toolkit's ad-hoc implementation of features built into C++.
And we're back to my original point. When some C++ features are useful, you can implement and use them in C as well.
You are also acting like I do not know C.
Correction: I'm acting like you can't think about the problem at hand outside the confines of the syntax of whatever language you're using at the moment. I don't care whether or not you know any C at all because it doesn't matter in this discussion.
And unlike C++, C prevents a lot of useful work from getting done because C has very limited support for abstraction.
Actually, C has enough support for abstraction that adding more doesn't improve code quality. It only makes your code shorter but the overall quality will remain the same.
And the simple fact is that piles of shit written in C tend to be much smaller than those written in C++.
I don't believe that you have anything to back that up. Historically, vast amounts of crap was written in C.
C programmers are not better than C++ programmers, they just know their place better
You have no evidence for that whatsoever.
What kind of evidence would you like to see? The fact that you said yourself that C++ allows you to do more by hiding design complexity is good enough. If people know they can do more, they'll also take on bigger tasks and get further with them before they grow over their heads.
You're also ignoring the point that your repository should not allow write access for all.
I'm ignoring it because it's obvious. The difference between C and C++ in fairly big project is whether pull requests will put you in shit up to your knees, or up to your neck.
If your ability depends on the choice of language so much, then you still have a lot to learn.
You said earlier, and I quote:
But unlike C, it'll also prevent any useful work from getting done because ASM (including LLVM ASM) has very limit
Readability and bugginess has nothing to do with the programming language.
Trivially you must be wrong: try writing in brainfuck.
That's obviously a carefully selected example, but there's a scale. Some languages are more readable than other. Selecting production languages, you almost certainly find C easier to read than Fortran 77.
I was referring to the old saying that real programmers can write Fortran in any language. When your coding style is fucked up, changing a language won't magically fix it. Not even Python with its ridiculous indent-delimited code blocks. If your programming style is good, you can probably figure out a way to write readable code even in Whitespace. Also, I said the thing about language support for structures and functions for a reason.
you make bugs in C because you can't think the design through, you'll make the same bugs in C++ as well.
I also make bugs because I'm ont perfect and sometimes I forget to do things. If I can automate away common tasks, there are entire classes of bug that I won't make.
C++ allows such automation. C does not.
Correction: It does, you just don't know how. Writing primitive object and memory pool-based garbage collection that supports destructors takes what, 500 lines of reusable support code and 5 extra lines per pool to set it up and then clean up anything left in it? As a bonus, the garbage collector can tell you where exactly you allocated the stuff you forgot to clean up.
And for those few bugs that C++ actually takes care of for you, you'll make several more bugs by breaking the rules you must follow when you use things like exceptions and STL containers (for example accessing invalidated iterators).
huh? Like what? I don't tend to have heaps of active iterators lying around to be invalidated. Also, exceptions are orthogonal to that problem, much like setjmp/longjmp are orthogonal to the problem of invalid pointers in C.
Invalidated iterators are just one of the many things you need to keep in mind. Exceptions are another. When you catch and handle an exception that was propagated through object method call (but originated deeper in the call tree), you may end up with the object in invalid state because you forgot to catch, handle and rethrow the exception in its method. Then there're also single-parameter constructors which may cause unwanted implicit casts unless declared explicit. The performance difference between "++x" and "x++". Not forgetting to declare some methods as virtual. Not forgetting to declare the destructor as virtual. Understanding the difference between constructing local object with automatic scope using parameterless constructor and declaring parameterless function that returns an object by value (Hint: the difference is one pair of parentheses). For every problem C++ solves for you, it adds at least two things for you to screw up if you don't pay enough attention.
What efficiency metric are we even talking about?
The usual one where the program runs faster. You can make C as fast (obviously), but it requires vastly more effort.
It doesn't take that much extra effort because you can do the same damn thing as in C++. You can even write class and function templates using preprocessor macros.
Once you get fluent in C++, you know that all variables are destructed when they go out of scope.
What about temporary variables that didn't get constructed in the first place?
You expect that to happen.
Yes, but the list of things you have to expect in C++ is a mile long. That's why bad C++ programmers cause so much more damage when their code blows up compared to bad C programmers.
Spoken like someone who's never smashed the stack and had a program crash in a random place.
That's actually right because I've stopped doing this kind of mistakes years ago. And I believe that Valgrind can detect and clearly report this kind of bugs, whereas Valgrind's report of falling out of function that is supposed to return an object by value will be really confusing.
No, I mean "a little bit". When your system is well designed, it doesn't take as much extra effort to implement it in C as you think. "Well designed" is the key requirement though. If it's not well designed, it'll take forever.
And, of course you can all do it in ASM anyway, or LLVM ASM if you want to be portable. Tha will weed out even more people.
But unlike C, it'll also prevent any useful work from getting done because ASM (including LLVM ASM) has very limited support for structures and functions.
You have no evidence to support that whatsoever. There is heaps of bad C code out there and heaps of bad C programmers.
The total amount of shitty code is not important. The size of each individual pile of shit is. And the simple fact is that piles of shit written in C tend to be much smaller than those written in C++. Bad C programmers usually don't make major contributions to big projects because they figure out very early on that the task is out of their league. C programmers are not better than C++ programmers, they just know their place better.
Funy thing, by managing the complexity for me, C++ allows me to hold vastly larger and more interesting systems in my head in one go, meaning I can do much better, more interesting and more efficient stuff
If your ability depends on the choice of language so much, then you still have a lot to learn.
If you think that writing C++ code doesn't make your code more concise, more readable, less buggy and more efficient with a given effort, then I pity your employer.
Concise is the only word I agree with. Readability and bugginess has nothing to do with the programming language. When your programming language supports at least structures and functions, it's all about your programming skill. If you make bugs in C because you can't think the design through, you'll make the same bugs in C++ as well. And for those few bugs that C++ actually takes care of for you, you'll make several more bugs by breaking the rules you must follow when you use things like exceptions and STL containers (for example accessing invalidated iterators).
And efficient? Seriously? What efficiency metric are we even talking about?
So making things more obtuse, fiddly, and generally a PITA is a GOOD thing?
Ya know, I could make a crack about how "Well that explains Linux in a nutshell" but I won't because the simple fact that you treat programming as a "club" where things should be as hard as possible to "weed out the undesirables" I think explains why Linux has gone nowhere on the desktop better than I ever could, and its toxic attitudes just like yours.
Again, you're not getting the point. I didn't say "things should be as hard as possible" and neither did Linus. OS kernel is the kind of code which has to be written by people who know exactly what they're doing. In this case, too hard is bad, bud too easy is even worse. When you hide complexity, you also remove any incentive to learn how to design things properly.
You have to realize that abstraction can be used in two ways: either to reduce complexity of the problem, or to pile tons of additional complexity on it. It takes lots of experience to be able to tell the difference. The most reliable sign that you can tell the difference is that you stop thinking that switching from C to C++ would improve the code in any meaningful way. And I say that as someone who mostly writes C++ code.
example: never allow exceptions to propagate out of constructors, which is usually news even to people who know about exceptions and destructors.
What do you mean? IIRC when a constructor is terminated by exception, the object is left in undefined state, the destructor won't be called and no memory is allocated in case the object was created using the new keyword. So if you clean up the object before the exception leaves the constructor and then don't access the object from outside, it's perfectly fine to propagate exceptions from constructors.
Your argument about return values is literally the same thing in C. Your program is just as prone to crash if you return garbage instead of a char pointer.
C doesn't add implicit function calls to simple returns from a function like C++ does. When your C code crashes, it crashes in code you have called directly.
Torvalds was spot on in those comments and the response is completely clueless about what Torvalds was talking about. Anything you can do in C++ you can also do in C but it takes a little bit of extra effort. That little extra effort is just enough to get rid of clueless programmers because when they try to do something complicated, it'll keep blowing up in their face until they give up. In C++ on the other hand, the language (and STL and Boost) will take away some of the complexity thus allowing the clueless programmers to get away with much worse and more broken designs that seem to work at first but will eventually blow up with a much bigger bang.
In other words, using plain C is a test of how much complexity you can hold in your head at a time. If you need extra syntactic sugar to make something work, you're not fit to hack the Linux kernel. If you don't, those few extra lines of code to implement the same object pattern in plain C won't kill you.
If you want examples of complete and utter crap that can be written in C++, I suggest you try to read and make sense of the sources of UShock and FreeOrion. These are the worst cases of C++ OOP abuse I've seen so far but I'm sure someone else could provide links to something even worse.
Slashdot Mirror
The DOJ publishes a continuation every year. But it's so hard visiting the server linked under the graph and clicking three times to find the right statistic, isn't it?
You aren't allowed to go on someone else's lawn and do what you want: it's the same thing with creations of the mind as with ownership of physical property.
My computer is not MAFIAA's lawn. Neither are the bajillion other computers, devices and wires that together form the Internet. When I create copies of content under MAFIAA monopoly, I don't go to MAFIAA's lawn to do it, I stay on my own lawn and use tools from my own house. But apparently the law allows MAFIAA to come to my lawn and tell me what I'm not allowed to do with the stuff I own. Copyright is legal violation of physical property rights.
The pirates in this article have called themselves "the Pirate Party," while engaging in contributory and vicarious copyright infringement to take the monopolies of creators away from them.
FTFY
Sure, but that's a bit of overkill for lots of applications.
We have plenty of mass manufacturing technology in the USA. Industrial automation of current manufacturing technologies is already starting to leveling the playing field between China and industrialized nations in the rest of the world.
You know, that doesn't really help at all. If you want the economy to work, it doesn't matter whether the goods are made in China by cheap Chinese workers or by machines in your own country. The only thing that matters is whether or not all of your customers can earn back (directly or indirectly) every single cent they've paid for your goods. If they can, the economy will flourish. If they can't, it'll trigger a domino effect of poverty that will effectively remove all the people who are unable to earn their money back from you from the economy (though it may take a decade or two). That's pretty much the 2008 crisis in a nutshell. And it's also the main reason why high-tech DIY manufacturing is an economic necessity for a lot of people. Injection molding solves a technical problem but 3D printing solves an economic one.
Hint: Inductors and capacitors are made by carefully printing insulator and conductor materials in a certain pattern. They don't require a special material for themselves.
Uh, like we aren't in a mass manufacturing bonanza right now?
Yes, we are. And it's one of the main causes of our current economic problems. That's why we need to move from buying everything from east Asia to making stuff we need back home again. We don't go nuts over the technology itself, we just see a huge potential for stabilizing the economy in it. The technology is not perfect, it just happens to be the closest one to practical usability.
First off, I don't think that evolution is "unimportant." I think that its promotion within political debates to be the central topic of science education is unwarranted.
Except it is warranted by the political attacks on science led by religious nutjobs. If you think that scientists can fend off a political attack by writing scientific papers, you're naive.
Can you articulate why you think that it is all that important for it to be given emphasis in a typical public school curriculum? Honestly, I have trouble coming up with a reasonable argument for that. Most introductory biology courses focus on the mechanics of organisms, and while learning about evolution can be helpful there, I don't see it as being required.
Evolution is the thing that makes sense out of all those weird mechanics. If you want to make someone excited about computer science, you don't make him memorize menu buttons, you show him how computers really work on the inside. If you want to make someone excited about chemistry, you don't make him memorize the periodic table, you show him why it looks the way it looks and how is it useful. If you want to make someone excited about biology, you teach him evolution because that's the only way to make the pieces fit together like in the other examples I've listed. Organism mechanics are the boring facts of biology but evolution is the thing that makes it all click and the little future biologists go "Ooooh".
Insulators/structural support - check
Conductors - check
Inductors - check
Resistors - check
Capacitors - check
Now all we need are two 3D-printable materials that can form a semiconductor and an extruder design that can automatically switch between all of those materials and the 3D printing bonanza will begin.
Nope. But if Microsoft continues this nonsense and major game developers switch to Linux, 2014 will be.
Creationism and religion aside, where do you think our civilization is headed, what new problems await us in the near future and what should we do to solve them and keep the right direction?
What do you think of open access initiatives, scientific publishing in general and what would you change to improve the situation?
If you just download and not distribute, the GPL doesn't oblige you to do anything either.
If your programming style is good, you can probably figure out a way to write readable code even in Whitespace.
Now that I disagree with. I'm pretty sure it's impossible (whitespace is isomorphic to brainfuck IIRC). One has to take such programmatic circumlocquitions to fight the langage that the reaults are very opaque. Same with doing general computation in SED. It's possible: there's some amazing sed programs out there implementing dc, sokoban, and a whole load others. But they're very hard to follow even with extensive comments.
That one was a joke.
Correction: It does, you just don't know how. Writing primitive object and memory pool-based garbage collection that supports destructors takes what, 500 lines of reusable support code and 5 extra lines per pool to set it up and then clean up anything left in it? As a bonus, the garbage collector can tell you where exactly you allocated the stuff you forgot to clean up.
Sure, that applies to memory. In C++ it applies to files, locks and just about anything else as well. Also, the constructors allow for automatic initialisation of those resources too.
All constructors (except copy constructor in some cases) are called directly. The most indirection you can get is calling it through some factory object and you can do that in C as well.
Of course, you can make the pool actualy destruct non-trivial objects, but you're looking at quite a lot of work just to open and close a file (what's the scope of the pool? when do you flush it? How many file object lifetimes do you have etc), for example. The C++ version has much less boilerplate.
That's completely under your control. The most simple pool implementation I can think of would have a grand total of 6 functions: one to initialize the whole thing at the very beginning, one to clean everything up on exit, one to create new pool and push it on stack, one to pop the top pool from stack and release everything in it, one to add new object with given structure prefix (including pointer to destructor function) to the pool on top of stack (this one will be called from constructors) and one to remove an object from its pool and clean it up.
The nice thing about C++ is that you get accurate memory management basically for free with the STL, and you can always change your allocator (you can get STL pool allocators) if you find that you have a performance bottleneck.
It's never for free. There's always some kind of trade off that you have to keep in mind.
Like every feature mis-used it has severe downsides.
That's why Linus and many others think that less is sometimes more. When you have powerful features, they should at least be very hard to misuse and get away with it.
Taking your memory pool example. You need the 500 lines of support code and 5 per pool. compare that to just using a std::vector or std::string when you need it.
So much nicer to read in C++ and so much less to go wrong.
The implementation of std::vector or std::string is also 500 lines of support code.
It doesn't take that much extra effort because you can do the same damn thing as in C++.
Of course, and you can do the same things in assembler. It's easier in C ane easier still in C++.
You can even write class and function templates using preprocessor macros.
And you get a poorly specified, buggy and quite possibly slow implementation of half of C++98. Which won't catch most of the common errors. Or allow clean parameterisation without tons of syntactic overhead.
We're not talking about implementing a formal programming language. We're talking about implementing a system that works. You don't need tons of syntactic sugar for that.
So, I challenge you: find a C parser library as clean and easy
What about temporary variables that didn't get constructed in the first place?
Er, how?
IIRC in C++98 when you return objects from function by value, a temporary object is created using a copy constructor on whatever you've passed as an argument to the return statement. Then the function's stack is unwinded. Then if the return value is used in the above scope, the temporary object is passed to whatever function uses it (copy constructor, assignment operator or a function that takes a reference to the object). Then the temporary object is destroyed just before control returns to the parent function.
I'm also pretty sure that the behavior when you fall out of non-void function without returning anything is undefined so it's perfectly possible the compiler won't call constructor for the temporary object but it will call destructor later.
Yes, but the list of things you have to expect in C++ is a mile long.
No. You expect variables to have their constructor called when the enter the scope and the destructor called when they leave it. You see operator+ and know that it's just a fancy function call syntax, etc etc.
Again: exceptions, virtual methods, some uses of templates, multiple inheritance... All of that imposes restrictions on what you can do in the code that you have to keep in your head all the time. If you don't, your code will blow up sometime in the future.
And I believe that Valgrind can detect and clearly report this kind of bugs
No, it detects use of uninitialised memory, but agumenting every memory location.
IIRC Valgrind places some padding with special values between return address and local variables and then it checks that the special pattern is still there before return. If not, it'll complain.
Valgrind's report of falling out of function that is supposed to return an object by value will be really confusing.
The compiler detects it just fine.
Only as a warning that you may not notice. Or ignore because you think it's a "can't happen" situation.
Quite a lot of the code I write is numerics code. A good library like Eigen strips away all of the syntactic overhead, and replaces it with code that looks like maths. Numerics code is hard ot get right and such an assistance is immensely helpful.
Yes, because writing "plus(a,b)" is so much harder than "a+b".
Or try writing a little ad-hoc parser in C. Then try writing one in C++ using boost (Spirit).
Been there, done that. I'll see your Boost and raise you Flex+Bison.
Or try implementing a k-D tree, with priority based searching (requiring a priority queue).
As simple as writing it in C++.
All of those will be vastly shorter in C++ because C++ gives you the abstractions to create powerful libraries.
Vastly? Oh come on. The C implementation of the same thing will have about 10% more lines + some fixed amount of reusable support code. That's it. And the internal design will be exactly the same.
They'll be less buggy because the amount of code you have to write is much shorter. Every line you _don't_ write is a bug that cannot happen.
You're forgetting the little problem that you can introduce bugs by NOT writing a line of code where one is required. It applies to C++ much more than to plain C.
What about writing GUI code. Every C level GUI code I've messed with has been a right royal pain in the ass, full of boilerplate, pain and bugs. By comparison, FLTK, for instance is very, very easy. I've also heard great things about QT, though I've never used it.
I've never heard anyone say great things about writing GUIs in C. Sure it can be done. I used to know enough M*tif to be dangerous, but it is not easy, end they all involve not only haveing to learn the GUI toolkit, but also the toolkit's ad-hoc implementation of features built into C++.
And we're back to my original point. When some C++ features are useful, you can implement and use them in C as well.
You are also acting like I do not know C.
Correction: I'm acting like you can't think about the problem at hand outside the confines of the syntax of whatever language you're using at the moment. I don't care whether or not you know any C at all because it doesn't matter in this discussion.
And unlike C++, C prevents a lot of useful work from getting done because C has very limited support for abstraction.
Actually, C has enough support for abstraction that adding more doesn't improve code quality. It only makes your code shorter but the overall quality will remain the same.
And the simple fact is that piles of shit written in C tend to be much smaller than those written in C++.
I don't believe that you have anything to back that up. Historically, vast amounts of crap was written in C.
C programmers are not better than C++ programmers, they just know their place better
You have no evidence for that whatsoever.
What kind of evidence would you like to see? The fact that you said yourself that C++ allows you to do more by hiding design complexity is good enough. If people know they can do more, they'll also take on bigger tasks and get further with them before they grow over their heads.
You're also ignoring the point that your repository should not allow write access for all.
I'm ignoring it because it's obvious. The difference between C and C++ in fairly big project is whether pull requests will put you in shit up to your knees, or up to your neck.
If your ability depends on the choice of language so much, then you still have a lot to learn.
You said earlier, and I quote:
But unlike C, it'll also prevent any useful work from getting done because ASM (including LLVM ASM) has very limit
Readability and bugginess has nothing to do with the programming language.
Trivially you must be wrong: try writing in brainfuck.
That's obviously a carefully selected example, but there's a scale. Some languages are more readable than other. Selecting production languages, you almost certainly find C easier to read than Fortran 77.
I was referring to the old saying that real programmers can write Fortran in any language. When your coding style is fucked up, changing a language won't magically fix it. Not even Python with its ridiculous indent-delimited code blocks. If your programming style is good, you can probably figure out a way to write readable code even in Whitespace. Also, I said the thing about language support for structures and functions for a reason.
you make bugs in C because you can't think the design through, you'll make the same bugs in C++ as well.
I also make bugs because I'm ont perfect and sometimes I forget to do things. If I can automate away common tasks, there are entire classes of bug that I won't make.
C++ allows such automation. C does not.
Correction: It does, you just don't know how. Writing primitive object and memory pool-based garbage collection that supports destructors takes what, 500 lines of reusable support code and 5 extra lines per pool to set it up and then clean up anything left in it? As a bonus, the garbage collector can tell you where exactly you allocated the stuff you forgot to clean up.
And for those few bugs that C++ actually takes care of for you, you'll make several more bugs by breaking the rules you must follow when you use things like exceptions and STL containers (for example accessing invalidated iterators).
huh? Like what? I don't tend to have heaps of active iterators lying around to be invalidated. Also, exceptions are orthogonal to that problem, much like setjmp/longjmp are orthogonal to the problem of invalid pointers in C.
Invalidated iterators are just one of the many things you need to keep in mind. Exceptions are another. When you catch and handle an exception that was propagated through object method call (but originated deeper in the call tree), you may end up with the object in invalid state because you forgot to catch, handle and rethrow the exception in its method. Then there're also single-parameter constructors which may cause unwanted implicit casts unless declared explicit. The performance difference between "++x" and "x++". Not forgetting to declare some methods as virtual. Not forgetting to declare the destructor as virtual. Understanding the difference between constructing local object with automatic scope using parameterless constructor and declaring parameterless function that returns an object by value (Hint: the difference is one pair of parentheses). For every problem C++ solves for you, it adds at least two things for you to screw up if you don't pay enough attention.
What efficiency metric are we even talking about?
The usual one where the program runs faster. You can make C as fast (obviously), but it requires vastly more effort.
It doesn't take that much extra effort because you can do the same damn thing as in C++. You can even write class and function templates using preprocessor macros.
Once you get fluent in C++, you know that all variables are destructed when they go out of scope.
What about temporary variables that didn't get constructed in the first place?
You expect that to happen.
Yes, but the list of things you have to expect in C++ is a mile long. That's why bad C++ programmers cause so much more damage when their code blows up compared to bad C programmers.
Spoken like someone who's never smashed the stack and had a program crash in a random place.
That's actually right because I've stopped doing this kind of mistakes years ago. And I believe that Valgrind can detect and clearly report this kind of bugs, whereas Valgrind's report of falling out of function that is supposed to return an object by value will be really confusing.
Hmm, good point.
If by "a little bit" you mean "a lot", then yes.
No, I mean "a little bit". When your system is well designed, it doesn't take as much extra effort to implement it in C as you think. "Well designed" is the key requirement though. If it's not well designed, it'll take forever.
And, of course you can all do it in ASM anyway, or LLVM ASM if you want to be portable. Tha will weed out even more people.
But unlike C, it'll also prevent any useful work from getting done because ASM (including LLVM ASM) has very limited support for structures and functions.
You have no evidence to support that whatsoever. There is heaps of bad C code out there and heaps of bad C programmers.
The total amount of shitty code is not important. The size of each individual pile of shit is. And the simple fact is that piles of shit written in C tend to be much smaller than those written in C++. Bad C programmers usually don't make major contributions to big projects because they figure out very early on that the task is out of their league. C programmers are not better than C++ programmers, they just know their place better.
Funy thing, by managing the complexity for me, C++ allows me to hold vastly larger and more interesting systems in my head in one go, meaning I can do much better, more interesting and more efficient stuff
If your ability depends on the choice of language so much, then you still have a lot to learn.
If you think that writing C++ code doesn't make your code more concise, more readable, less buggy and more efficient with a given effort, then I pity your employer.
Concise is the only word I agree with. Readability and bugginess has nothing to do with the programming language. When your programming language supports at least structures and functions, it's all about your programming skill. If you make bugs in C because you can't think the design through, you'll make the same bugs in C++ as well. And for those few bugs that C++ actually takes care of for you, you'll make several more bugs by breaking the rules you must follow when you use things like exceptions and STL containers (for example accessing invalidated iterators).
And efficient? Seriously? What efficiency metric are we even talking about?
So making things more obtuse, fiddly, and generally a PITA is a GOOD thing?
Ya know, I could make a crack about how "Well that explains Linux in a nutshell" but I won't because the simple fact that you treat programming as a "club" where things should be as hard as possible to "weed out the undesirables" I think explains why Linux has gone nowhere on the desktop better than I ever could, and its toxic attitudes just like yours.
Again, you're not getting the point. I didn't say "things should be as hard as possible" and neither did Linus. OS kernel is the kind of code which has to be written by people who know exactly what they're doing. In this case, too hard is bad, bud too easy is even worse. When you hide complexity, you also remove any incentive to learn how to design things properly.
You have to realize that abstraction can be used in two ways: either to reduce complexity of the problem, or to pile tons of additional complexity on it. It takes lots of experience to be able to tell the difference. The most reliable sign that you can tell the difference is that you stop thinking that switching from C to C++ would improve the code in any meaningful way. And I say that as someone who mostly writes C++ code.
example: never allow exceptions to propagate out of constructors, which is usually news even to people who know about exceptions and destructors.
What do you mean? IIRC when a constructor is terminated by exception, the object is left in undefined state, the destructor won't be called and no memory is allocated in case the object was created using the new keyword. So if you clean up the object before the exception leaves the constructor and then don't access the object from outside, it's perfectly fine to propagate exceptions from constructors.
Your argument about return values is literally the same thing in C. Your program is just as prone to crash if you return garbage instead of a char pointer.
C doesn't add implicit function calls to simple returns from a function like C++ does. When your C code crashes, it crashes in code you have called directly.
Torvalds was spot on in those comments and the response is completely clueless about what Torvalds was talking about. Anything you can do in C++ you can also do in C but it takes a little bit of extra effort. That little extra effort is just enough to get rid of clueless programmers because when they try to do something complicated, it'll keep blowing up in their face until they give up. In C++ on the other hand, the language (and STL and Boost) will take away some of the complexity thus allowing the clueless programmers to get away with much worse and more broken designs that seem to work at first but will eventually blow up with a much bigger bang.
In other words, using plain C is a test of how much complexity you can hold in your head at a time. If you need extra syntactic sugar to make something work, you're not fit to hack the Linux kernel. If you don't, those few extra lines of code to implement the same object pattern in plain C won't kill you.
If you want examples of complete and utter crap that can be written in C++, I suggest you try to read and make sense of the sources of UShock and FreeOrion. These are the worst cases of C++ OOP abuse I've seen so far but I'm sure someone else could provide links to something even worse.