Not a UFO, already determined that even in the summary. We know what it is, thus "identified". Not "unidentified". Thus no UFO. Why is this a story? That a few people called in and didn't recognize a few lights in the sky?
I think "Crash Override" is an extremely poor choice of names. I mean, who in the community doesn't know 1995's "Hackers"? Johnny Lee Miller's character had a handle "Crash Override". He spent the entire movie trying to get into Angelina Jolie's character's pants (and succeeded), and he (the actor) married Jolie in real life, if only for a few years. If you want to talk "messages", what does choosing such a moniker for this movement represent? At its best, willful ignorance (which I doubt) or an alternate purpose, which then begs the question of for what? I'm not going to go so far to say Quinn is either stupid or ignorant, so that again beg's the question: why "Crash Override"?
Dude, don't use square brackets with STL arrays and vectors, just to make your code more readable. The [] operator skips bounds checking, which is the main reason for using these classes in the first place. At() is the proper methodology to use in pretty much every case, unless you are so confident in your bounds that its worth the trivial speed increase in access time.
This is usually just plain wrong. I have extremely seldom ever seen "at" used in production code. Why? Because it's usually duplicating a bounds check you've already done. If you're going to naively randomly access a location into a vector without checking if it's within bounds, sure, but that's kind of a nasty smell (also, are you handling the exception that may/will occur?). Most vector accesses occur something like looping from 0 until (but not including size), or using begin/end (either the free functions or the members). At best, the optimizer might be able to deduce you're never modifying the size of the vector during a loop and elide the repeated bounds check. At worst, you're evaluating "if ((_M_end - _M_start) <= i) throw std::out_of_range();" on every iteration.
Regarding point #4, forward declarations aren't to save compilation time or declare linkage. Yes, they can be used to do both, but the prime function is to, well, declare a name and just enough information to be somewhat useful before it is used (i.e. reduce very simple otherwise circular-references). I can forward-declare 'struct A', but I cannot instantiate/allocate it until it is defined (need to know the size, layout, etc.). You can declare a pointer to 'struct A', because well, you know the size of the pointer. Same reason you can't define "struct A { struct A a; };", but you can define "struct A {struct A* p_a; };".
Regarding "#ifdefs", yeah, there shouldn't really be a need for them in this day and age, but they won't go away due to legacy code. If you removed them, you'd break every single codebase in the world. Not going to happen. Additionally, due to the historical lack of variadic macros, there are numerous libraries that rely upon multiple inclusion of the same header to fake variadic macros. If you assumed a "#pragma once", you'd break various Boost libraries as well as even some STL implementations. Headers guarded with ifdef's can only safely be precompiled and reused if any and all preprocessor defines referenced are identical across all usages and inclusion order of every & all predecessor headers is exactly the same for all usages, otherwise you very well may violate the one-definition-rule.
the petitions in question take aggregated opinions to decision-makers
No, they don't. They take an aggregate of a singular shared opinion by some set of like-minded people, but they don't represent an aggregated set of opinions. Note the plurality in opinions.
Petition sites such as change.org or even the White House's site are not democratic in nature and they should not be construed as "votes" from the voting populace. First, there is no guarantee the signatures are valid or even from the US. Second, there is no mechanism to vote against, or to otherwise say something to the effect of "no, I think this is a bad idea". So, you only measure the yeas, but have no meter of the nays. For argument sake, and assuming rough numbers: White House is requiring 250,000 signatures to consider a petition? US estimated 2013 population is 316,128,839. So, that ends up being 0.079% of the population needs to ascent to the petition to be considered, with no way to voice countering options or dissent, except with an opposing petition. Personally, I think a better mechanism would be a vote up/down mechanism and consider the net. Yes, I recognize only recording the yeas is the very nature of a petition, but I think the way these petitions are being represented is more as an opinion poll of what *everyone* wants, which is not true. If that's how you're going to represent it, you should give everyone an opportunity to actually express their view, not just that of those that are reinforcing your opinion/view.
I, personally, define bad code (in this context), from the perspective of code generated by the compiler, as code that does not perform in an expected manner as dictated by the higher-level language lacking any sort of unspecified or undefined behavior failing to produce the expected result. In a most ridiculous example, if I had int i = 3 * 7; printf("%d", i); and anything other than 21 was output, there's some bad code present. Suboptimal does not mean bad or erroneous, if it produces the correct result. Suboptimal but correct would be a target for manual inline assembly optimization, if it is sufficiently inefficient. Bad with incorrect result might also be a target for manual assembly if a resolution from the compiler vendor could not be completed, or would otherwise be unfeasible.
File a bug report for the compiler with 'missed optimization opportunity' in the title and a reduced test case.
We like to see real-world examples of where we're generating bad code - if we don't see them, we can't fix them.
Definitely correct, and an oversight on my part. To my part, I've not first-hand observed a compiler generating bad or erroneous code, but was more thinking back to Linus's recent tirade about GCC 4.8. When I have seen the compiler behaving badly, it's usually been in the form of internal compiler errors. When I do encounter these, I do as much research as I reasonably can, and try and distill a minimal reproduction. Last such ICE I saw was in GCC 4.1.2 a few years ago (yes, my employer at the time was that far behind). The Ops team wanted to push a "small" update to my dev server, which I think was running Rhel 5.4 at the time to fix a completely unrelated issue. After the update, I noticed it also updated GCC to a newer point release of 4.1.2 and an unmodified code base started to fail with an ICE. A bit of investigation narrowed it down to, in C++ code, defining an anonymous namespace at the global scope (perfectly legal, but caused an ICE in that particular GCC version). Turns out it had already been reported, fixed and already released in a later version, so my Ops team had very little work to do to fix it.
If you have the time to write the algorithm in assembly, then you have the time to write it in the high level language (I'd imagine for anything but the most trivial of operations, you're probably looking at a minimum of 5x-10x longer to write and verify the algorithm by hand in assembly vs C or C++. I'd also wager my estimate may be an order of magnitude or more low. I'd also expect a large variance in the extra time relative to the experience and familiarity of the architecture of the developer/engineer doing the inline assembly.). The additional benefit of this, as you mentioned, but I failed to: is that you have it there for regression/comparison (assuming, of course, the compiler is generating functionally correct assembly, to begin with). Additionally, having both the assembly & high level implementations affords you the ability to quickly, if sub-optimally, support new architectures.
But yes, a mixture of C++ and assembly is definitely the right solution, either inline assembly or a single separate function to do the messy math.
I disagree with nothing you've said here, or in your initial reply to me. One word of caution: I'd discourage mixing inline assembly with "regular" C/C++ code. Most compilers (last I've looked) immediately bail on attempting to optimize any function that contains inline assembly. I honestly don't know if you have an inline asm function how that plays in - it's just not something I deal with regularly. Last time I wrote/modified any inline assembly was to correct a x86->x64 compatibility problem roughly 6 years ago.
What do you think intrinsics are? They are nothing but very thinly wrapped C functions, often marked inline, over the underlying instructions. The major downside here is you have no choice over register allocation, if you're making a number of calls, this could become an issue.
This is generally true, but when you've measured and proven the compiler is generating sub optimal code, it may be time to hand-optimize in assembly. Compilers don't always generate better code than a human. In general, if you have performance critical code, I find it better to write it in C/C++ first, then examine the compiler optimized assembly. IIF it is shown to be sub optimal, then you optimize by hand. Compilers are also finicky. One algorithm it may optimize it well, but make a slight change in a high level language and sometimes the compiler optimizer gets confused and generates horridly different and rather un-optimized code. Different compilers may also optimize differently, so it may be ideal to do the assembly by hand to get uniform performance across compilers. In general, if performance is *that* critical to you, you need to examine by hand those critical sections to verify the compiler is doing what you expect it to do. This isn't even to mention that compilers target the lowest common denominator of the architecture you specify. i.e. if you target x86, most compilers will not utilize any SSE or SIMD instructions unless separately and explicitly enabled.
Before I posted this, I read through the roughly 60 posts that were here. If your child is interested in the lore and mechanics of gaming, I think the prime focus should be on creativity and writing. I don't think you can necessarily "teach" creativity, but I think you can encourage it. I would probably suggest a lot of reading of fiction from as great an expansive base of styles and genres as you can. Through exposure to a variety of material, they may find something they like and build/expand upon something they like. Very little is truly a brand new idea. Most fiction is an adaptation/twist/extension on a previous idea.
If your kid wants to both write the story behind the game and the code that makes it happen, large AAA games are not what you want to strive towards. There tends to be a strict separating of responsibilities.
If your child is insistent upon that, as far as development goes, a large number of people have already post some great links to development resources. A lot of those may be over the head of a child, though, let alone a seasoned non-game developer./p?
Personally, my inclination to watch "the Interview" increased more and more as the hacking went on and on. I am disappoint that I will not be able to see it likely now, in the theater. I will, however purchase it, in the very likely soon DVD/BluRay release.
I don't have a problem with a long/lengthy article being broken into a series (so long as there's a view as single page). Lately, I've gotten my choice Dobbs articles via redit & RSS, and they come in as just "Part 1", Part 2", etc. Not even "Part 1/9". I understand that, because they're probably publishing them as they receive them/write them and arguably don't even know how many parts there will be (which is probably due to an arbitrary editorial decision of number of lines/paragraphs). But, what I want is: on a 30-minute train ride, can I digest an article, not can I read a 5 minute snippet, then remember where that snippet left off a few weeks ago, and then a few weeks further yet remember those previous 2 snippets I read. I can really get behind a multisegment such as "we're going to design a scripting language interpreter", and every section is a logical conclusion of a part of it. But to beak mid-stream as a lot of the newish articles seam to do in order to "make you come back next week" is asinine and extremely frustrating from a user perspective, especially from a software developer perspective. I have this problem *now*. I do not want to come back next week to see how the second have can be solved.
From a C++ perspective, the only lately useful articles are from Andrew Koenig, but how the release of the articles is done has pissed me off so much I removed it from my feeds. His most recent article series, is at part 9: Abstractions for Binary Search. How about write an article that can be released in a single piece and consumed as such. Trying to consume parts of something every few weeks is an ineffective learning tool. There doesn't seem to be any more single articles. The interesting ones are broken up into multiple parts released every week or two. FUCK THAT. Give me an article that I can read, start to finish. Don't make me come back next week. I'm a developer. I'm already being torn six ways to sundown by various issues, I don't need a publication compounding that. Give me single, solitary articles that have all the content in a single page and I'm happy (it also makes the googling easier).
Actually this is false. It is possible to write a language that is both safe* and compiles itself.
This is not true, at least not initially. And your example of LLVM (and clang) completely disregards its history. LLVM/clang are only relatively recently self-hosting (can be used to build themselves). LLVM & clang are written in C++ and for a long time relied upon an external C++ compiler (typically gcc) to be built.
At least z/OS has some pretty aggressive protection going on that x86 doesn't, otherwise I'd have no hope for the ol' systems (they should hardly ever have existed really then)
That may be, but it didn't stop me from crashing an entire LPAR, knocking the entire development staff off the mainframe by running a simple select sql statement against DB2.
One of the simplest constructs in C++ that makes me cringe is when I see people do:
std::string foo = "";
instead of:
std::string foo;
The reason being, although functionally equivalent, the second version results in faster, smaller code. On every implementation I've looked at the first one results in calls to strlen, a possible memory allocation and a strcpy. The second is a mere memset of the internal pointers to null. Even though us humans that understand C++, the compiler knows only the language. It typically does not know anything about the standard library. Yes, there are exceptions, such as compile-time warnings/errors for mismatched arguments to printf style functions. But, those are exceptions, not the rule, and they are few and far between.
When I see the first form, I immediately understand that I am looking at code from some whose primary language is not C++, but instead likely Java or C#.
Name mangling is not standardized, still, and it probably never will be unless there is a formalized ABI. It sounds like you were using STL from pre-standard days. Even post standardization, it took all of the compiler vendors to catch up. The landscape is a lot better now. In particular it's been great to see the effort MS has put into becoming standards compliant and treating C++ as a first-class citizen on Windows instead of the ugly step child locked in the attic because they can't kill it.
iostreams are a bit ugly, but at least they're type-safe. iostreams also have the added benefit of operator overloading, allowing types to format themselves. You can't do that with printf - you'd at a minimum have to have an extra string buffer to defer to a type to format itself to then pass to a printf for additional formatting.
I think it's more a function of what people "know" than "like". I also think this is true regardless of the language/tool set used. It is also usually an indicator of the developer's experience. A junior dev is far more likely than a senior to have a need for something and reinvent the wheel out of ignorance of available options rather than a justified reason to do so.
Or a library written in another language, in which case C, or more exactly, the ABI (usually dictated by your C runtime of choise), is the common dialect.
I agree that language comes down to preference and usually comfort level. Having +10 years experience with C++, C# and Python each, while roughly a year experience with Java & Ruby, my languages of choice, in order are: C++, Python, C#, Ruby, Java.
I particularly like C++ because of it's raw unabashed power. There's very little magic, and nearly every language construct is straight forward and easy to understand. Granted, there are a ton of subtle gotchas an nuances that will trip up the inexperienced and even the veterans. I like Python because the language itself is clean, succinct and terse (but not perl level terse). It also has the benefit of generally being easily readable by non-Python folks. I hear a lot of complaints about the whitespace, but when it comes down to it, it's a non-issue when you're used to it. If you indent your code well and normally in other languages, your code looks the same, but you've saved having to type the braces. One of the other things I like about Python is how well and cleanly it interfaces with C/C++. It's C object model is one of the cleanest and most straight forward I've ever seen. It is a breeze to interface with and expose C/C++ APIs to. Unlike perl with its abomination of a library: XS. I like C# for a lot of the same reasons: mostly clean language, expansive built-in library and removed a lot of the idiocy of Java (exception specs? ew. Double is an object, double is a value, wtf?
I have very little experience with Ruby, and I'm still learning. It seems a mix of Python & Perl which, I tend to stay towards the more Python-ic approaches in Ruby because they're clearer and make more sense to me.
As far as looking for a job, money isn't everything. A year ago, I left a job pulling in $155K base with bonuses around $40K per anum doing mostly C++ & Python, which I liked. But after a decade at the company, I'd enough of the stress and the B.S. politics, so I left for a job where I'm just pulling $145K base and little to no bonus doing mostly C#, Java, Ruby and maintaining legacy Python code. And, for now at least, I'm happier. Sure, I miss the money, but I still make enough.
Slashdot Mirror
Not a UFO, already determined that even in the summary. We know what it is, thus "identified". Not "unidentified". Thus no UFO. Why is this a story? That a few people called in and didn't recognize a few lights in the sky?
I think "Crash Override" is an extremely poor choice of names. I mean, who in the community doesn't know 1995's "Hackers"? Johnny Lee Miller's character had a handle "Crash Override". He spent the entire movie trying to get into Angelina Jolie's character's pants (and succeeded), and he (the actor) married Jolie in real life, if only for a few years. If you want to talk "messages", what does choosing such a moniker for this movement represent? At its best, willful ignorance (which I doubt) or an alternate purpose, which then begs the question of for what? I'm not going to go so far to say Quinn is either stupid or ignorant, so that again beg's the question: why "Crash Override"?
Dude, don't use square brackets with STL arrays and vectors, just to make your code more readable. The [] operator skips bounds checking, which is the main reason for using these classes in the first place. At() is the proper methodology to use in pretty much every case, unless you are so confident in your bounds that its worth the trivial speed increase in access time.
This is usually just plain wrong. I have extremely seldom ever seen "at" used in production code. Why? Because it's usually duplicating a bounds check you've already done. If you're going to naively randomly access a location into a vector without checking if it's within bounds, sure, but that's kind of a nasty smell (also, are you handling the exception that may/will occur?). Most vector accesses occur something like looping from 0 until (but not including size), or using begin/end (either the free functions or the members). At best, the optimizer might be able to deduce you're never modifying the size of the vector during a loop and elide the repeated bounds check. At worst, you're evaluating "if ((_M_end - _M_start) <= i) throw std::out_of_range();" on every iteration.
Regarding point #4, forward declarations aren't to save compilation time or declare linkage. Yes, they can be used to do both, but the prime function is to, well, declare a name and just enough information to be somewhat useful before it is used (i.e. reduce very simple otherwise circular-references). I can forward-declare 'struct A', but I cannot instantiate/allocate it until it is defined (need to know the size, layout, etc.). You can declare a pointer to 'struct A', because well, you know the size of the pointer. Same reason you can't define "struct A { struct A a; };", but you can define "struct A {struct A* p_a; };".
Regarding "#ifdefs", yeah, there shouldn't really be a need for them in this day and age, but they won't go away due to legacy code. If you removed them, you'd break every single codebase in the world. Not going to happen. Additionally, due to the historical lack of variadic macros, there are numerous libraries that rely upon multiple inclusion of the same header to fake variadic macros. If you assumed a "#pragma once", you'd break various Boost libraries as well as even some STL implementations. Headers guarded with ifdef's can only safely be precompiled and reused if any and all preprocessor defines referenced are identical across all usages and inclusion order of every & all predecessor headers is exactly the same for all usages, otherwise you very well may violate the one-definition-rule.
Recently infected? Feels more like a primordial specimen that couldn't step out of the initial pool.
the petitions in question take aggregated opinions to decision-makers
No, they don't. They take an aggregate of a singular shared opinion by some set of like-minded people, but they don't represent an aggregated set of opinions. Note the plurality in opinions.
Petition sites such as change.org or even the White House's site are not democratic in nature and they should not be construed as "votes" from the voting populace. First, there is no guarantee the signatures are valid or even from the US. Second, there is no mechanism to vote against, or to otherwise say something to the effect of "no, I think this is a bad idea". So, you only measure the yeas, but have no meter of the nays. For argument sake, and assuming rough numbers: White House is requiring 250,000 signatures to consider a petition? US estimated 2013 population is 316,128,839. So, that ends up being 0.079% of the population needs to ascent to the petition to be considered, with no way to voice countering options or dissent, except with an opposing petition. Personally, I think a better mechanism would be a vote up/down mechanism and consider the net. Yes, I recognize only recording the yeas is the very nature of a petition, but I think the way these petitions are being represented is more as an opinion poll of what *everyone* wants, which is not true. If that's how you're going to represent it, you should give everyone an opportunity to actually express their view, not just that of those that are reinforcing your opinion/view.
I, personally, define bad code (in this context), from the perspective of code generated by the compiler, as code that does not perform in an expected manner as dictated by the higher-level language lacking any sort of unspecified or undefined behavior failing to produce the expected result. In a most ridiculous example, if I had int i = 3 * 7; printf("%d", i); and anything other than 21 was output, there's some bad code present. Suboptimal does not mean bad or erroneous, if it produces the correct result. Suboptimal but correct would be a target for manual inline assembly optimization, if it is sufficiently inefficient. Bad with incorrect result might also be a target for manual assembly if a resolution from the compiler vendor could not be completed, or would otherwise be unfeasible.
And he missed the second step:
File a bug report for the compiler with 'missed optimization opportunity' in the title and a reduced test case.
We like to see real-world examples of where we're generating bad code - if we don't see them, we can't fix them.
Definitely correct, and an oversight on my part. To my part, I've not first-hand observed a compiler generating bad or erroneous code, but was more thinking back to Linus's recent tirade about GCC 4.8. When I have seen the compiler behaving badly, it's usually been in the form of internal compiler errors. When I do encounter these, I do as much research as I reasonably can, and try and distill a minimal reproduction. Last such ICE I saw was in GCC 4.1.2 a few years ago (yes, my employer at the time was that far behind). The Ops team wanted to push a "small" update to my dev server, which I think was running Rhel 5.4 at the time to fix a completely unrelated issue. After the update, I noticed it also updated GCC to a newer point release of 4.1.2 and an unmodified code base started to fail with an ICE. A bit of investigation narrowed it down to, in C++ code, defining an anonymous namespace at the global scope (perfectly legal, but caused an ICE in that particular GCC version). Turns out it had already been reported, fixed and already released in a later version, so my Ops team had very little work to do to fix it.
If you have the time to write the algorithm in assembly, then you have the time to write it in the high level language (I'd imagine for anything but the most trivial of operations, you're probably looking at a minimum of 5x-10x longer to write and verify the algorithm by hand in assembly vs C or C++. I'd also wager my estimate may be an order of magnitude or more low. I'd also expect a large variance in the extra time relative to the experience and familiarity of the architecture of the developer/engineer doing the inline assembly.). The additional benefit of this, as you mentioned, but I failed to: is that you have it there for regression/comparison (assuming, of course, the compiler is generating functionally correct assembly, to begin with). Additionally, having both the assembly & high level implementations affords you the ability to quickly, if sub-optimally, support new architectures.
But yes, a mixture of C++ and assembly is definitely the right solution, either inline assembly or a single separate function to do the messy math.
I disagree with nothing you've said here, or in your initial reply to me. One word of caution: I'd discourage mixing inline assembly with "regular" C/C++ code. Most compilers (last I've looked) immediately bail on attempting to optimize any function that contains inline assembly. I honestly don't know if you have an inline asm function how that plays in - it's just not something I deal with regularly. Last time I wrote/modified any inline assembly was to correct a x86->x64 compatibility problem roughly 6 years ago.
What do you think intrinsics are? They are nothing but very thinly wrapped C functions, often marked inline, over the underlying instructions. The major downside here is you have no choice over register allocation, if you're making a number of calls, this could become an issue.
This is generally true, but when you've measured and proven the compiler is generating sub optimal code, it may be time to hand-optimize in assembly. Compilers don't always generate better code than a human. In general, if you have performance critical code, I find it better to write it in C/C++ first, then examine the compiler optimized assembly. IIF it is shown to be sub optimal, then you optimize by hand. Compilers are also finicky. One algorithm it may optimize it well, but make a slight change in a high level language and sometimes the compiler optimizer gets confused and generates horridly different and rather un-optimized code. Different compilers may also optimize differently, so it may be ideal to do the assembly by hand to get uniform performance across compilers. In general, if performance is *that* critical to you, you need to examine by hand those critical sections to verify the compiler is doing what you expect it to do. This isn't even to mention that compilers target the lowest common denominator of the architecture you specify. i.e. if you target x86, most compilers will not utilize any SSE or SIMD instructions unless separately and explicitly enabled.
There are days where I do not have mod points, and this ^^^^^^^^ is it.
Before I posted this, I read through the roughly 60 posts that were here. If your child is interested in the lore and mechanics of gaming, I think the prime focus should be on creativity and writing. I don't think you can necessarily "teach" creativity, but I think you can encourage it. I would probably suggest a lot of reading of fiction from as great an expansive base of styles and genres as you can. Through exposure to a variety of material, they may find something they like and build/expand upon something they like. Very little is truly a brand new idea. Most fiction is an adaptation/twist/extension on a previous idea.
If your kid wants to both write the story behind the game and the code that makes it happen, large AAA games are not what you want to strive towards. There tends to be a strict separating of responsibilities.
If your child is insistent upon that, as far as development goes, a large number of people have already post some great links to development resources. A lot of those may be over the head of a child, though, let alone a seasoned non-game developer./p?
Personally, my inclination to watch "the Interview" increased more and more as the hacking went on and on. I am disappoint that I will not be able to see it likely now, in the theater. I will, however purchase it, in the very likely soon DVD/BluRay release.
I don't have a problem with a long/lengthy article being broken into a series (so long as there's a view as single page). Lately, I've gotten my choice Dobbs articles via redit & RSS, and they come in as just "Part 1", Part 2", etc. Not even "Part 1/9". I understand that, because they're probably publishing them as they receive them/write them and arguably don't even know how many parts there will be (which is probably due to an arbitrary editorial decision of number of lines/paragraphs). But, what I want is: on a 30-minute train ride, can I digest an article, not can I read a 5 minute snippet, then remember where that snippet left off a few weeks ago, and then a few weeks further yet remember those previous 2 snippets I read. I can really get behind a multisegment such as "we're going to design a scripting language interpreter", and every section is a logical conclusion of a part of it. But to beak mid-stream as a lot of the newish articles seam to do in order to "make you come back next week" is asinine and extremely frustrating from a user perspective, especially from a software developer perspective. I have this problem *now*. I do not want to come back next week to see how the second have can be solved.
From a C++ perspective, the only lately useful articles are from Andrew Koenig, but how the release of the articles is done has pissed me off so much I removed it from my feeds. His most recent article series, is at part 9: Abstractions for Binary Search. How about write an article that can be released in a single piece and consumed as such. Trying to consume parts of something every few weeks is an ineffective learning tool. There doesn't seem to be any more single articles. The interesting ones are broken up into multiple parts released every week or two. FUCK THAT. Give me an article that I can read, start to finish. Don't make me come back next week. I'm a developer. I'm already being torn six ways to sundown by various issues, I don't need a publication compounding that. Give me single, solitary articles that have all the content in a single page and I'm happy (it also makes the googling easier).
Actually this is false. It is possible to write a language that is both safe* and compiles itself.
This is not true, at least not initially. And your example of LLVM (and clang) completely disregards its history. LLVM/clang are only relatively recently self-hosting (can be used to build themselves). LLVM & clang are written in C++ and for a long time relied upon an external C++ compiler (typically gcc) to be built.
At least z/OS has some pretty aggressive protection going on that x86 doesn't, otherwise I'd have no hope for the ol' systems (they should hardly ever have existed really then)
That may be, but it didn't stop me from crashing an entire LPAR, knocking the entire development staff off the mainframe by running a simple select sql statement against DB2.
One of the simplest constructs in C++ that makes me cringe is when I see people do:
std::string foo = "";
instead of:
std::string foo;
The reason being, although functionally equivalent, the second version results in faster, smaller code. On every implementation I've looked at the first one results in calls to strlen, a possible memory allocation and a strcpy. The second is a mere memset of the internal pointers to null. Even though us humans that understand C++, the compiler knows only the language. It typically does not know anything about the standard library. Yes, there are exceptions, such as compile-time warnings/errors for mismatched arguments to printf style functions. But, those are exceptions, not the rule, and they are few and far between.
When I see the first form, I immediately understand that I am looking at code from some whose primary language is not C++, but instead likely Java or C#.
Name mangling is not standardized, still, and it probably never will be unless there is a formalized ABI. It sounds like you were using STL from pre-standard days. Even post standardization, it took all of the compiler vendors to catch up. The landscape is a lot better now. In particular it's been great to see the effort MS has put into becoming standards compliant and treating C++ as a first-class citizen on Windows instead of the ugly step child locked in the attic because they can't kill it.
iostreams are a bit ugly, but at least they're type-safe. iostreams also have the added benefit of operator overloading, allowing types to format themselves. You can't do that with printf - you'd at a minimum have to have an extra string buffer to defer to a type to format itself to then pass to a printf for additional formatting.
I think it's more a function of what people "know" than "like". I also think this is true regardless of the language/tool set used. It is also usually an indicator of the developer's experience. A junior dev is far more likely than a senior to have a need for something and reinvent the wheel out of ignorance of available options rather than a justified reason to do so.
Or a library written in another language, in which case C, or more exactly, the ABI (usually dictated by your C runtime of choise), is the common dialect.
I agree that language comes down to preference and usually comfort level. Having +10 years experience with C++, C# and Python each, while roughly a year experience with Java & Ruby, my languages of choice, in order are: C++, Python, C#, Ruby, Java.
I particularly like C++ because of it's raw unabashed power. There's very little magic, and nearly every language construct is straight forward and easy to understand. Granted, there are a ton of subtle gotchas an nuances that will trip up the inexperienced and even the veterans. I like Python because the language itself is clean, succinct and terse (but not perl level terse). It also has the benefit of generally being easily readable by non-Python folks. I hear a lot of complaints about the whitespace, but when it comes down to it, it's a non-issue when you're used to it. If you indent your code well and normally in other languages, your code looks the same, but you've saved having to type the braces. One of the other things I like about Python is how well and cleanly it interfaces with C/C++. It's C object model is one of the cleanest and most straight forward I've ever seen. It is a breeze to interface with and expose C/C++ APIs to. Unlike perl with its abomination of a library: XS. I like C# for a lot of the same reasons: mostly clean language, expansive built-in library and removed a lot of the idiocy of Java (exception specs? ew. Double is an object, double is a value, wtf?
I have very little experience with Ruby, and I'm still learning. It seems a mix of Python & Perl which, I tend to stay towards the more Python-ic approaches in Ruby because they're clearer and make more sense to me.
As far as looking for a job, money isn't everything. A year ago, I left a job pulling in $155K base with bonuses around $40K per anum doing mostly C++ & Python, which I liked. But after a decade at the company, I'd enough of the stress and the B.S. politics, so I left for a job where I'm just pulling $145K base and little to no bonus doing mostly C#, Java, Ruby and maintaining legacy Python code. And, for now at least, I'm happier. Sure, I miss the money, but I still make enough.