Increment WTF
-
C was designed to make the compiler as simple as possible because there wasn't have room in memory for complex compilers. The alternative to C was assembly language. So C was a big improvement. C++ was designed to be compatible with C, since all existing Unix code was written in C, and it wasn't reasonable to rewrite it all in a new language.
-
@morbiuswilters said:
@esoterik said:
C++11 has many changes and improvements that make the language more usable and more flexible, and they have even fixed some mistakes where they could.
Short of deleting every scrap of C++ source code in existence and putting a bullet through Stroustrup's fat, dumb head, what do you think could possibly "fix" C++? I just looked at the Wikipedia page for C++11 and it seems like a bunch of clumsy workarounds for problems that shouldn't have existed in a well-thought-out language in the first place and some more "kitchen sink" features, because the only way Stroustrup can get off at night is knowing that his language contains every single feature that has ever existed in any other language.
You know it's shit because it took so long to get finished. Programs that take forever are always shit. Like Netscape 6. Or Perl 6. Or Word 6 on Mac. They are also version 6 usually. This is what I've learned. This is computer software FACT.
-
@powerlord said:
Wow, is this really undefined in the C++ spec?
Modifying a variable more than once between sequence points? Of course
-
@kc0a said:
C was designed to make the compiler as simple as possible because there wasn't have room in memory for complex compilers.
And then there was enough memory, but C never got better. And there were better languages that could still run on constrained hardware--Lisp pre-dates C by over a decade, and Scheme came out in the mid-70s. So while C might have been acceptable in the early 70s, it's indefensible now.
@kc0a said:
C++ was designed to be compatible with C, since all existing Unix code was written in C, and it wasn't reasonable to rewrite it all in a new language.
Who cares what C++ was designed to be? Are we awarding points for effort now? Integrating a non-trivial base of C code with C++ is nightmarish, so it's a failure in that regard.
-
@morbiuswilters said:
Who cares what C++ was designed to be? Are we awarding points for effort now? Integrating a non-trivial base of C code with C++ is nightmarish, so it's a failure in that regard.
I still have nightmares about the project I had to convert from C to C++ which used the keyword "class" as a variable in about 34,034,432 places. Of course that was before we had decent IDEs with decent refactoring tools... I guess today I could have done it in Visual Studio or something else in a fraction of the time. But that's no excuse for C or C++ still being a popular language.
That work was done back in 1997, and even then I was thinking: "why the fuck was this written in C?" But at that time there still wasn't anything better enough to replace it-- PHP, Java and Perl were about as good as we had. And I hadn't been exposed at all to Java. Actually I did a lot of work in RealBasic (now Xojo), and RealBasic was pretty awesome by the standards of the day-- but wasn't suitable for server processes for various reasons.
Now there are so many options. So many. If you broke ground on a new project in 2013, and chose C++, and were under the age of 75, I'd seriously question your sanity.
-
@blakeyrat said:
If you broke ground on a new project in 2013, and chose C++, and were under the age of 75, I'd seriously question your sanity.
The one place it seems to make sense is in high-end 3D games. (Maybe "make sense" is being too generous; that's the only place where the alternatives are--shockingly, depressingly--worse.)
-
@morbiuswilters said:
The one place it seems to make sense is in high-end 3D games. (Maybe "make sense" is being too generous; that's the only place where the alternatives are--shockingly, depressingly--worse.)
No. I think game devs delude themselves into thinking optimization matters much more than it does. Also, game devs are (generally speaking) AWFUL software developers and aren't likely to do a detailed analysis of game performance vs. development time.
AAA games like Skyrim run my CPU at like 30%, max.
-
@blakeyrat said:
@morbiuswilters said:
The one place it seems to make sense is in high-end 3D games. (Maybe "make sense" is being too generous; that's the only place where the alternatives are--shockingly, depressingly--worse.)
No. I think game devs delude themselves into thinking optimization matters much more than it does. Also, game devs are (generally speaking) AWFUL software developers and aren't likely to do a detailed analysis of game performance vs. development time.
AAA games like Skyrim run my CPU at like 30%, max.
Yeah, it's certainly possible game devs are delusional. But one of the concerns now also seems to be cross-platform compatibility, where you have to be able to take advantage of specialized, constrained console hardware. That works with C++ because compilers can optimize for a particular architecture; I don't know if that would be as easy to pull off with a managed language.
There's also the question of which language they'd end up using if they went the managed route. It seems the only two candidates would be Java or C#, and I don't think Nintendo or Sony would be down with C#, nor would M$ be down with Java (and who can blame them?) So there's also that aspect that may drive development to a more platform-neutral language like C++. (I'm not a game dev, so I don't really know what constraints they're operating under; I'm just spitballing here.)
-
@blakeyrat said:
I still have nightmares about the project I had to convert from C to C++ which used the keyword "class" as a variable in about 34,034,432 places.
Couldn't you just, using global search-and-replace, spell "klass" with a K?(All together now: "Never thought of that; what a silly bunt!")
-
@morbiuswilters said:
It seems the only two candidates would be Java or C#, and I don't think Nintendo or Sony would be down with C#,
God knows what Nintendo does. But Sony already has games on its console written in C#. (Presumably using Mono and the MonoGame library.)
@morbiuswilters said:
So there's also that aspect that may drive development to a more platform-neutral language like C++.
That just shows there's still too many shitty languages around.
-
@blakeyrat said:
God knows what Nintendo does.
I'm not even sure he knows..
@blakeyrat said:
But Sony already has games on its console written in C#. (Presumably using Mono and the MonoGame library.)
Really? I'm surprised Sony would allow it, but alright then. Are they high-end AAA games, though?
-
@morbiuswilters said:
Really? I'm surprised Sony would allow it, but alright then.
Why? What incentive would Sony have to deny it?
@morbiuswilters said:
Are they high-end AAA games, though?
PSN titles.
-
@blakeyrat said:
Why? What incentive would Sony have to deny it?
I dunno, what incentive does Apple have to keep other languages off iOS?
-
@morbiuswilters said:
@blakeyrat said:
Why? What incentive would Sony have to deny it?
I dunno, what incentive does Apple have to keep other languages off iOS?
They have to meet that requirement as a tribute to Satan, their Supreme Lord, in exchange for all the success they've had since 2001.
-
@morbiuswilters said:
@esoterik said:
Move semantics, lambda's and uniform initialization are all huge improvements to the language; however nothing you have said evaluates to a valid argument that C++ is bad. You seem to imply that C++ is bad because you can write bad code in it, but you can write bad code in any language. I think you are just biased against C++, your mad that it has lasted so long, used so extensively and is multi-paradigm.C++11 has many changes and improvements that make the language more usable and more flexible, and they have even fixed some mistakes where they could.
Short of deleting every scrap of C++ source code in existence and putting a bullet through Stroustrup's fat, dumb head, what do you think could possibly "fix" C++? I just looked at the Wikipedia page for C++11 and it seems like a bunch of clumsy workarounds for problems that shouldn't have existed in a well-thought-out language in the first place and some more "kitchen sink" features, because the only way Stroustrup can get off at night is knowing that his language contains every single feature that has ever existed in any other language.
-
@esoterik said:
however nothing you have said evaluates to a valid argument that C++ is bad. You seem to imply that C++ is bad because you can write bad code in it, but you can write bad code in any language.
No I didn't. C++ is bad because it's nearly impossible to write good code in it. It's a clusterfuck of bad ideas (multiple inheritance, operator overloading, exceptions in an unmanaged language, memory management in a high-level, "object-oriented" language, recursive templates) mixed with overly-complex twaddlecock (pure virtual abstract blah blah blah...)
@esoterik said:
your mad that it has lasted so long, used so extensively and is multi-paradigm.
No, I'm mad that it's lasted this long, is used so extensively and comprises Exhibits A through M in "The People versus Shitty Programming Languages". It's awful, it's garbage and people who keep coding in it are just demeaning the entire software industry with their cargo-cult ignorance.
-
@esoterik said:
Move semantics, lambda's and uniform initialization are all huge improvements to the language; however nothing you have said evaluates to a valid argument that C++ is bad. You seem to imply that C++ is bad because you can write bad code in it, but you can write bad code in any language.
Well duh. But how easy is it? That's the question. How easy is it to write code that will crash your program in C++ compared to other languages? How easy is it to write code that leads to security holes in C++ compared to other languages? How easy is it to shoot yourself in the foot?
As it turns out, REALLY FUCKING EASY. That's why C++ is a terrible language.
@esoterik said:
I think you are just biased against C++, your mad that it has lasted so long, used so extensively and is multi-paradigm.
My mad what? #PedanticDickweed
Yes, I'm furious that people are still using C++, because it means those people are writing crashing software, writing software filled with security holes, wasting their own time with pointless boilerplate instead of writing good software. I'm pissed at everything that distracts developers from writing good software, it's kind of my "thing".
-
@blakeyrat said:
I'm pissed at everything
FTFYthat distracts developers from writing good software, it's kind of my "thing".
-
Ah, predictable C++ bashing!
Now while I'll readily concede that it's an old language with its share of warts, it's by no means a beginner's language, and there are better languages for most purposes, I don't get why people trot out the same objections to the language that are largely solved problems.
@morbiuswilters said:
C++ is bad because it's nearly impossible to write good code in it. It's a clusterfuck of bad ideas (multiple inheritance, operator overloading, exceptions in an unmanaged language, memory management in a high-level, "object-oriented" language, recursive templates) mixed with overly-complex twaddlecock (pure virtual abstract blah blah blah...)
Just because those options are on the table doesn't mean you have to use them. If you're using sane libraries, good patterns and practices, your code will look pretty similar to a C# or Java equivalent.
Also, C++ is far older than a lot of the alternatives presented here. Hindsight is 20/20 - will C# or Java still be paragons of purity in 20 years?
@blakeyrat said:
doing manual memory management
I admit that if you're not careful with dynamic allocation you'll find yourself in a heap of trouble, but these days you rarely need to work with raw pointers, if at all. There's RAII, and std::auto_ptr or boost::shared_ptr if you want reference-counting.
@blakeyrat said:
crashing software
That's not exclusive to C++.
@blakeyrat said:
writing software filled with security holes
Buffer overflows? Don't use C arrays. STL and Boost are your friends.
@blakeyrat said:
AAA games like Skyrim run my CPU at like 30%, max.
Suppose that you have a multiplayer game with physics and a lot of entities. Your client doesn't need to process entities that are outside your view (or it can process them less frequently), but the server needs to process all visible entities for all players. Granted, the server doesn't necessarily have to render frames, but the dynamics engine is going to have to integrate a much larger number of entities, perform the "business rules," and propogate entity positions/velocities/state to all connected players. With enough players, that gets to be pretty CPU-intensive, especially since the complexity for n players is somewhere between O(n log n) and O(n^2). You might be able to scale out to more instances, but players like to crowd together in the same instance, so squeezing out what extra headroom you reasonably can helps.
@morbiuswilters said:
The one place it seems to make sense is in high-end 3D games. (Maybe "make sense" is being too generous; that's the only place where the alternatives are--shockingly, depressingly--worse.
Part of it is that since C++ has been a dominant choice for game development for so long, most of the libraries are in C++. People are making managed wrappers to a lot of the major libraries, so if you want to work in a managed language, there are options. I once tried getting part of my stack to work in the abomination that is C++/CLI (so that that unmanaged code at least has a managed interface), and gave up when the compiler complained about some classes requiring alignment. With some effort, I could have probably gotten around it, but I already had something working in good ol' unmanaged C++ by that point.
-
@Groaner said:
Suppose that you have a multiplayer game with physics and a lot of entities.
"Suppose?" I do. Several. And they never get even remotely close to taxing my CPU. Now they'll always swallow up every last byte of GPU capacity, that's a given, but CPU? Feh. CPU just exists to swap data in and out of the GPU.
-
@Groaner said:
Ah, predictable C++ bashing!
Ah, predictable trolls coming out from under their bridge to defend C++ like it was the honor of a maiden faire!
@Groaner said:
Just because those options are on the table doesn't mean you have to use them.
Yes, you can work around most of the features of C++. This is, of course, idiotic.
@Groaner said:
If you're using sane libraries, good patterns and practices, your code will look pretty similar to a C# or Java equivalent.
So your argument is "It's possible to force C++ to kinda-sorta be as good as a mediocre language like Java"? Do you not realize what side of the argument you are on?
@Groaner said:
Also, C++ is far older than a lot of the alternatives presented here. Hindsight is 20/20 - will C# or Java still be paragons of purity in 20 years?
What the fuck is wrong with you people? I'm like "C++ is a bad language" and your rebuttal is "Sure, but other languages will not be well-liked in the future." That's not an argument. That's you waving your hands and trying to distract from the fact that C++ is a disaster.
And it's not like this is hindsight--most of C++'s ideas were bad fucking ideas in the first place. It was an abysmal language from the start. It's not like any of this is news; in the early 80s people said "Don't add exceptions" but the dipshits added exceptions and made the language a fucking mess.
@Groaner said:
There's RAII, and std::auto_ptr or boost::shared_ptr if you want reference-counting.
There are also entire, vast collections of languages which don't have manual memory management at all. Why work around the mistakes of C++?
@Groaner said:
That's not exclusive to C++.
No, it's just much, much, much more likely in C++. Please try to keep up with the discussion.
@Groaner said:
STL and Boost are your friends.
STL and Boost are the kinds of friends who hold you up at knife-point while they build a meth lab in your basement, then they end up burning your whole house down. I am now convinced C++ apologists must have severely low self-esteem to tolerate (and even sing the praises of!) such abusive behavior.
@Groaner said:
Part of it is that since C++ has been a dominant choice for game development for so long, most of the libraries are in C++.
Right, the gaming industry is made up of cretinous retards who can't advance technologically. That was sort of the core of the argument.
-
@morbiuswilters said:
Ah, predictable trolls coming out from under their bridge to defend C++ like it was the honor of a maiden faire!
I think you missed the part where I laid out my position.
@Groaner said:
Now while I'll readily concede that it's an old language with its share of warts, it's by no means a beginner's language, and there are better languages for most purposes, I don't get why people trot out the same objections to the language that are largely solved problems.
@morbiuswilters said:
Yes, you can work around most of the features of C++. This is, of course, idiotic.
So your argument is "It's possible to force C++ to kinda-sorta be as good as a mediocre language like Java"? Do you not realize what side of the argument you are on?
There are also entire, vast collections of languages which don't have manual memory management at all. Why work around the mistakes of C++?
Sure do, the side of pragmatism. Until other platforms have caught up and legacy projects fade away (which is happening, Kerbal Space Program and the stuff Blakey mentioned are in C#, aren't they?), there are people who are going to have to deal with C++. I wouldn't doubt that there's still code in World of Warcraft from 2001.
@morbiuswilters said:
I'm like "C++ is a bad language" and your rebuttal is "Sure, but other languages will not be well-liked in the future." That's not an argument. That's you waving your hands and trying to distract from the fact that C++ is a disaster.
Is it unreasonable to assume that the lessons learned were incorporated into the design of younger languages, and that C++ has a much longer legacy?
@morbiuswilters said:
And it's not like this is hindsight--most of C++'s ideas were bad fucking ideas in the first place. It was an abysmal language from the start. It's not like any of this is news; in the early 80s people said "Don't add exceptions" but the dipshits added exceptions and made the language a fucking mess.
I dunno, I think exceptions are less messy than setjmp or goto.
In spite of its flaws, it was good enough to become the lingua franca, so we're stuck with it until other options become viable. If you lose a leg, you can use a piece of driftwood as a peg leg and limp to a hospital, or you can complain about the splintery nature of the driftwood, criticize people who foolishly choose that option and bleed to death while scientists spend years perfecting cloning technologies and clone a new leg and attach it to you. I don't think it's going out on a limb to accept temporarily an imperfect but functional solution.
@Your buddy Bjarne said:
Anybody who comes to you and says he has a perfect language is either naïve or a salesman.
I'm not saying C++ is an exemplar. It has its flaws, but if you're careful and have a performance-intensive problem domain, it can get your job done. It's just tiresome to hear people bring up the same points about memory management, multiple inheritance, operator overloading, etc. as critical flaws when C++ has had ways of dealing with them for a while. If you want to criticize C++, compare its scattered standard "library" (libraries) to.NET, or its lack of a good standardized database framework, for example.
@morbiuswilters said:
Right, the gaming industry is made up of cretinous retards who can't advance technologically. That was sort of the core of the argument
John Carmack has many fast cars, and I don't think that's the product of a broken clock factory staffed with blind squirrels.
-
@Groaner said:
Is it unreasonable to assume that the lessons learned were incorporated into the design of younger languages
You sir just opened the door to making this thread about Go.
this image is a tribute to El_Heffe
-
@Ronald said:
@Groaner said:
Is it unreasonable to assume that the lessons learned were incorporated into the design of younger languages
You sir just opened the door to making this thread about Go.
Wait, only four posts in and I'm already at my first (albeit unintentional) potential thread derailment? Isn't that like a coming of age around here? Am I on track for a record or something?
Go's too easy a target. It seems you guys (I say you guys because that was when I was but a young lurker) have already beat that one into the ground, though. It's not like C++ where one can carefully construct a somewhat-defensible position.
-
@Groaner said:
Wait, only four posts in and I'm already at my first (albeit unintentional) potential thread derailment?
Make 9,996 more posts like this and maybe you'll get the same deal as Morbius, who according to the rumors
gets paid $1.25 per post in the forums, a misguided way to keep the forums alive and rack up Alexa hits.
If you don't think this is possible read this site's Privacy Policy & Disclaimer Statement.
-
@Groaner said:
Sure do, the side of pragmatism. Until other platforms have caught up and legacy projects fade away (which is happening, Kerbal Space Program and the stuff Blakey mentioned are in C#, aren't they?), there are people who are going to have to deal with C++. I wouldn't doubt that there's still code in World of Warcraft from 2001.
But that doesn't make C++ a good language. That's like saying influenza is good because your body hasn't completely fought it off yet.
@Groaner said:
Is it unreasonable to assume that the lessons learned were incorporated into the design of younger languages, and that C++ has a much longer legacy?
Lessons were learned from the Triangle Shirtwaist Factory fire, but that doesn't mean it was a good thing.
@Groaner said:
I dunno, I think exceptions are less messy than setjmp or goto.
Exceptions are meant for error-handling, and in managed code they are worse than plain old error codes.
@Groaner said:
In spite of its flaws, it was good enough to become the lingua franca, so we're stuck with it until other options become viable.
My God, did I just stumble back to 1986 or did your TimePod® just come from there? There are literally dozens (nay, hundreds) of better options. Even loathsome Java is better than C++.
@Groaner said:
John Carmack has many fast cars...
So did Hitler. But seriously, I like Carmack and he's clearly a very skilled programmer. However, I wouldn't consider him a technological or gaming oracle; id's games have been pretty mediocre since the Quake I days. And the guy doesn't even command the same respect in the engine community; last I heard, they gave up on licensing id Tech 5 to third parties due to lack of interest.
Anyway, success in the games industry means almost nothing with regard to usable software or languages. Shit, there's financial software that still runs on COBOL. Really, you're going to have to come up with a better argument than this.
-
@Ronald said:
Make 9,996 more posts like this and maybe you'll get the same deal as Morbius, who according to the rumors
gets paid $1.25 per post in the forums...It was recently cut-back to $1.17 /post. Times are tough all around..
-
@morbiuswilters said:
@blakeyrat said:
And high-performance computing. I've conversed with a friend of mine, who knows a thing or two about the subject, and it comes down to specific compiler optimisations and libraries to use stuff like CUDA. You're not going to manage that with, say, Java.If you broke ground on a new project in 2013, and chose C++, and were under the age of 75, I'd seriously question your sanity.
The one place it seems to make sense is in high-end 3D games.
-
@Severity One said:
@morbiuswilters said:
@blakeyrat said:
And high-performance computing. I've conversed with a friend of mine, who knows a thing or two about the subject, and it comes down to specific compiler optimisations and libraries to use stuff like CUDA. You're not going to manage that with, say, Java.If you broke ground on a new project in 2013, and chose C++, and were under the age of 75, I'd seriously question your sanity.
The one place it seems to make sense is in high-end 3D games.
But you could do it with C, which is still a better language than C++.
-
@morbiuswilters said:
@Severity One said:
@morbiuswilters said:
@blakeyrat said:
And high-performance computing. I've conversed with a friend of mine, who knows a thing or two about the subject, and it comes down to specific compiler optimisations and libraries to use stuff like CUDA. You're not going to manage that with, say, Java.If you broke ground on a new project in 2013, and chose C++, and were under the age of 75, I'd seriously question your sanity.
The one place it seems to make sense is in high-end 3D games.
But you could do it with C, which is still a better language than C++.
You use C when you have less than 1KB of RAM at your disposal. (I sometimes have to write for 64 bytes of RAM)
You use C++ when you have enough RAM to waste for the implicitly added object pointers but still may need to count instruction cycles.
Think Arduino. Or AVRs, PICs...
The other good place to use C++ is in oft-used libraries of other languages. If it gets called often, it better be fast. But actually touching C/C++ should require a license. It's not for sissies.
EDIT: Removed explicit insults.
-
@Severity One said:
I've conversed with a friend of mine, who knows a thing or two about the subject, and it comes down to specific compiler optimisations and libraries to use stuff like CUDA.
Hearsay.
-
@Ronald said:
@Severity One said:
Wanker.I've conversed with a friend of mine, who knows a thing or two about the subject, and it comes down to specific compiler optimisations and libraries to use stuff like CUDA.
Hearsay.
Said friend has a PhD from the ETH in Zürich, so I trust his word quite a bit more than someone with a proven history of making a fool of himself on this site.
-
@flabdablet said:
Thor's results suggest that the compiler he's using evaluates function parameters right to left.
Thanks for the explanation. I never realized C was such a big cock-up.
-
@Severity One said:
@Ronald said:
@Severity One said:
Wanker.I've conversed with a friend of mine, who knows a thing or two about the subject, and it comes down to specific compiler optimisations and libraries to use stuff like CUDA.
Hearsay.
Said friend has a PhD from the ETH in Zürich, so I trust his word quite a bit more than someone with a proven history of making a fool of himself on this site.
You can trust him, but for everybody reading your post it's hearsay. That's a fact, my friend who has TWO PhD from a slightly more prestigious university than the ETH in Zürich told me so. Also he's not a whiny name-dropping pussy so he's got more credibility than someone with a proven history of not having his own opinions who's expecting that quoting unknown and uninteresting people that he admires will bring any kind of weight to his posts.
-
@Severity One said:
Said friend has a PhD from the ETH in Zürich, so I trust his word quite a bit more than someone with a proven history of making a fool of himself on this site.
Since when do PhD's know how to write software? Out of the three PhD's I've worked with, two were complete idiots.
-
@Faxmachinen said:
@flabdablet said:
Thor's results suggest that the compiler he's using evaluates function parameters right to left.
Thanks for the explanation. I never realized C was such a big cock-up.
It's not. It's just misused.
And if your code is dependent on order of evaluation to that extent, please refrain from writing software.
-
@morbiuswilters said:
@esoterik said:
however nothing you have said evaluates to a valid argument that C++ is bad. You seem to imply that C++ is bad because you can write bad code in it, but you can write bad code in any language.
No I didn't. C++ is bad because it's nearly impossible to write good code in it. It's a clusterfuck of bad ideas (multiple inheritance, operator overloading, exceptions in an unmanaged language, memory management in a high-level, "object-oriented" language, recursive templates) mixed with overly-complex twaddlecock (pure virtual abstract blah blah blah...)
Hey, while I'll give you some of those, operator overloading is the shit. I miss it every single day I have to write stringBuilder.append( someThing ).append( somethingElse ). Or fucking .compare() > 0 instead of a simple ">".
-
@Faxmachinen said:
I never realized C was such a big cock-up.
C is not really a cock up: it's a portable assembly language designed to drag about as much performance from a CPU as can be achieved without resorting to its architecture-specific assembly language*, and as such it's best used by people with a good understanding of what the underlying machine is actually doing. Requiring people who don't have that understanding to use C for almost anything is a management cock-up. In an ideal world, C would be something you'd consider rewriting the CPU-intensive parts of your project in once your profiler had identified them as bottlenecks.
C++, on the other hand, is the Homer of computer languages; a design completely devoid of taste.
*Modern compilers are now good enough, and modern CPU architectures complex enough, that C compilers routinely emit code that runs at least as fast as a competent assembly language programmer could achieve.
-
@flabdablet said:
*Modern compilers are now good enough, and modern CPU architectures complex enough, that C compilers routinely emit code that runs at least as fast as a competent assembly language programmer could achieve.
Considering the complexity of modern CPUs, I'd be surprised of any mature, fully compiled (i.e. no bytecode) languages could be beaten by manual intervention. Do "competent assembly language programmers" even exist in 2013? Is it even possible for someone to fully, 100%, understand everything about how a CPU works and how to optimally code for it?
In any case, that problem is already solved: in 99% of code you never need to optimize; the other 1% can be optimized by picking a better algorithm; and the other unmeasurably small % can be optimized by writing a C code library and calling out to it. So even if you argue, "code that needs to run as fast as possible should be written in C++!" it doesn't follow that the other 99% of your code should be as well.
-
@Groaner said:
I don't get why people trot out the same objections to the language that are largely solved problems.
It's because the whole fucking shitpile is so fucking ugly. C++ is a language completely without charm. Its misfeatures are not even endearing enough to merit the label "quirks". The design is hamfisted, lacking in elegance, and manages the astounding feat of being underdone and overdone at the same time. C++ is a blight on the language design landscape, an evolutionary dead end, a total waste of time, a huge pile of suck. C++ is for people with no soul who think Yngwie Malmsteen is an improvement on Jimi Hendrix. Friends don't let friends defend C++.
-
@blakeyrat said:
Considering the complexity of modern CPUs, I'd be surprised of any mature, fully compiled (i.e. no bytecode) languages could be beaten by manual intervention. Do "competent assembly language programmers" even exist in 2013? Is it even possible for someone to fully, 100%, understand everything about how a CPU works and how to optimally code for it?
I suspect the only places this works is if you replace something compiled for a rather generic architecture and replace it with something more specific. In particular, I'm thinking of something like memset, where you might take advantage of certain registers or vector operations or something. But this is obviously a very rare circumstance, and even more rarely justified.
@blakeyrat said:
In any case, that problem is already solved: in 99% of code you never need to optimize; the other 1% can be optimized by picking a better algorithm; and the other unmeasurably small % can be optimized by writing a C code library and calling out to it.
THIS
-
@blakeyrat said:
Is it even possible for someone to fully, 100%, understand everything about how a CPU works and how to optimally code for it?
Yes, and modern compilers do an excellent job of encapsulating that understanding, especially on x86 architectures; there's been so much lipstick plastered on that particular pig that you can't really see its face any more, and the only way for an assembly coder to improve on compiler output is very project-specific and will involve lots of fartarsing about with fine grained performance measurement. This is, as you correctly note, almost never worth doing. But there is still a lot of work available on microcontrollers, many of which are architecturally pretty much as they were in 1980. Shocking as it may seem, people are still building stuff with 8051 and 6502 and PIC cores, though often embedded in some kind of SoC.
@blakeyrat said:
even if you argue, "code that needs to run as fast as possible should be written in C++!"
In my view, anybody making that argument seriously is deluded and not somebody I want to work with. C? Sure; constraints drive creativity. C++? Thanks, I'll pass.
-
@OldCrow said:
You use C++ when you have enough RAM to waste for the implicitly added object pointers but still may need to count instruction cycles.
I think the only time you'd choose C++ over C is when you have extreme brain damage.
-
@Snooder said:
Hey, while I'll give you some of those, operator overloading is the shit. I miss it every single day I have to write stringBuilder.append( someThing ).append( somethingElse ). Or fucking .compare() > 0 instead of a simple ">".
Yeah, but those are kinds that can be handled simply as language built-ins--no need for user-defined operators. With C++ you get shit like somebody overloading the + operator on an object to modify it somehow and before you know it you've got hundreds of operators being used throughout the project in inconsistent, insane ways.
-
@morbiuswilters said:
@Snooder said:
Hey, while I'll give you some of those, operator overloading is the shit. I miss it every single day I have to write stringBuilder.append( someThing ).append( somethingElse ). Or fucking .compare() > 0 instead of a simple ">".
Yeah, but those are kinds that can be handled simply as language built-ins--no need for user-defined operators.
Not really. The point of operator overloading is that you can decide how your own classes behave. Unless the language writers are omniscient, there's no way for them to anticipate every class that every person would create or how they'd like the operators to behave on those objects.@morbiuswilters said:
With C++ you get shit like somebody overloading the + operator on an
object to modify it somehow and before you know it you've got hundreds
of operators being used throughout the project in inconsistent, insane
ways.
You know how you fix that? You read the goddamn documentation for the class. String + String works in a different way from Integer + Integer. Why is it insane for UserDefinedClassA + UserDefinedClassA to work differently from UserDefinedClassB + UserDefinedClassB?
-
@morbiuswilters said:
With C++ you get shit like somebody overloading the + operator on an object to modify it somehow and before you know it you've got hundreds of operators being used throughout the project in inconsistent, insane ways.
Never mind the + operator; I want to know what was in the crack pipe that made overloading the bit shift operators for text I/O look like a good idea.
-
@Snooder said:
You read the goddamn documentation for the class.
Documentation is good, but if somebody has to read it to comprehend the basic methods of your class, you done fucked up. Descriptive method names are much more useful than opaque operators.
@Snooder said:
Why is it insane for UserDefinedClassA + UserDefinedClassA to work differently from UserDefinedClassB + UserDefinedClassB?
It's not. What is insane is when UserDefinedClassA + UserDefinedClassA modifies the first object, or does something goofy like a database write. There's also shit like UserDefinedClassA + UserDefinedClassB behaving differently than UserDefinedClassB + UserDefinedClassA.
-
@Snooder said:
You read the goddamn documentation for the class
In a good language, the "goddamn documentation for the class" is in the intellisense/auto-complete database.
-
@Groaner said:
Hindsight is 20/20 - will C# or Java still be paragons of purity in 20 years?
I'm hoping both will have been superseded by newer and better languages by that time. I'm guessing that C++ will still be around though, and that makes me sad.
@Groaner said:
There's RAII, and std::auto_ptr or boost::shared_ptr if you want reference-counting.
Buffer overflows? Don't use C arrays. STL and Boost are your friends.
Don't use basic language features because said features were designed in the same way that I design my bowel movements after a good curry? Why not just use a language that is actually designed and doesn't need third-party libraries to be useful?
C++ doesn't have warts, it is a wart. With warts growing on it. And those warts have warts. And every new C++ "standard" adds another layer of warts that are a different size, colour, and texture to the old warts. And what really needs to happen is that the "designers" need to pull their faces out of the warts and step back far enough to realise that JESUS IT'S HORRIBLE and then kill the thing with a flamethrower.
-
@flabdablet said:
@morbiuswilters said:
With C++ you get shit like somebody overloading the + operator on an object to modify it somehow and before you know it you've got hundreds of operators being used throughout the project in inconsistent, insane ways.
Never mind the + operator; I want to know what was in the crack pipe that made overloading the bit shift operators for text I/O look like a good idea.
- Make a list of every operator in the language
- Cross off the ones that have already been misused for other arbitrary reasons
- Of the remainder, pick the one that is least likely to make sense in the context it's being chosen for
- ???
- Profit
