I have not encountered any hostility. But if you don't know how to get better performance from C++ than you can get from C and lots of extra work, you probably will not be hired, most places.
It's not about hostility, it's about competence. Some places just demand competence more than others.
The laughter would not be about measurable performance; you might well be able to get C code to go as fast. The laughter would be over your apparent fear of the C++ compiler, and the suggestion to spend their money on a predictably inferior, more expensive, less maintainable solution.
You might as well suggest installing fluorescent lights in the office, or 10baseT network hubs, or CRT monitors. Those would get a jolly laugh, too, completely without hostility, but you still might not be invited back.
This conversation is now bordering on unhelpful. C has uses, some of them are compelling. Every finance shop I've worked in uses the linux kernel and drivers extensively. These are (mostly? all?) written in C. As is git. Nobody laughs. C++ has uses. Some of them are compelling. For a given case where these uses dominate nobody laughs. Claiming C is as obsolete as CRT monitors or 10baseT without any supporting evidence? Yeah, no thanks. Someone could take that the wrong way. Actually isn't this what Alexandrescou says about C++ because he's all about D nowadays? What Eckel did when he became all about Java (or is he now all scala?). Last time I saw footage of Stanley Lippman speaking he was being brutally disparaging of C++ and invoking in his defence Richard Gabriel describing C as "a virus" to make him look less hostile in comparison to other language warriors and wars. [2]
It just isn't a meaningful conversation without a specific case, with specific requirements and where a specific solution is advanced with appropriate evidence. If in your experience there has never been a case for C, in your own work in the very broad finance domain, over C++. Great. Your experience differs from mine. I've had circumstance where I've made the case, then implemented and released it and watched the p&l go quite well as a result. I do know how to program in C++ where that is appropriate and indeed I do. No really. Also Java, and Python, and (gasp, even) Perl, and... Like any and every experienced programmer, right?
Claiming someone is "scared of the c++" compiler in the absence of evidence for that is probably not your best comment here. It's actually imho the very worst thing about c++ as a language. That is the casual derogatory, frequently unsubstantiated, statements the pervade the surrounding culture. Linus had something to say about it back in the day [1] so it's not like the C++ folk have an exclusive license on that kind of attitude... His tone there doesn't make me laugh.
Two Cases you might like to consider. (1) Optimising the very last cycle matters, how hard you have to work to shake it out, not so much. Maybe you haven't had that, um, pleasure. (2) You have a reason to want to parse and transform the source. (Given (1) above the reason for doing so might be obvious but I probably shouldn't say too much more about it, also you might laugh! ;-)
Maybe in ncmncm's circle they laugh at C developers, but trying to extrapolate that across the finance industry is not credible.
Performance at the sharp end comes from preallocating memory, reducing syscalls, removing PIC (drop the GOT), static linking (enable LTO), using LTO, using simd where possible, hand rolling important functions in assembly, cpusets, reducing network hops, attempting to get the program to fit in L1 cache, putting the code into the switch, moving to fpga, moving to asic.
There's loads more optimizations but almost none of them have anything to do with C++ over C.
> You do all those things with C++ (or, for fpga, asic, etc., without). There is exactly zero benefit to dropping to C first.
That's my point. The performance tuning is generally not between C++ or C hence why you cannot extrapolate your experiences to the rest of the finance industry.
>And, nobody suggested anybody actually laughs at C developers.
You said, "In the finance world, you would be laughed out of the room for proposing C for a performance-critical task."
Then in discussing the nature of the laughter you said "The laughter would not be about measurable performance; you might well be able to get C code to go as fast. The laughter would be over your apparent fear of the C++ compiler, and the suggestion to spend their money on a predictably inferior, more expensive, less maintainable solution."
We have a case in English, as in all languages in its cohort, for discussion of counterfactuals, signaled by "would". If there were anyone proposing C for performance-critical code, they would be laughed at. Happily, none are.
This conversation is no longer of any benefit, but for the sake of you and your co-workers... Saying that C is predictably inferior, more expensive, and less maintainable shows a blatant amount of incompetence on how either languages operate. C++ only offers abstractions to (debatably) more easily allow for an object oriented design for codebases. Semantically everything that you can do in C++, you can do in C.
There are plenty of features in C++ that are beneficial, particularly the handful of mechanisms that allow you to move away from #defines, but to compare performance between C and C++ simply shows ignorance.
It's not about hostility, it's about competence. Some places just demand competence more than others.
The laughter would not be about measurable performance; you might well be able to get C code to go as fast. The laughter would be over your apparent fear of the C++ compiler, and the suggestion to spend their money on a predictably inferior, more expensive, less maintainable solution.
You might as well suggest installing fluorescent lights in the office, or 10baseT network hubs, or CRT monitors. Those would get a jolly laugh, too, completely without hostility, but you still might not be invited back.