"John Redford" <[email protected]> writes: ... > However, I suspect that you won't find many places that are in the business > of doing business that will be using C/C++. It's just not a > business-friendly language. Which is a polite way of saying that you cannot > hire low-skill programmers to use it and expect them to produce code without > massive memory-related issues. C/C++ is commonplace in certain domains -- > many of which are popular with OSS developers -- and some of those are > profitable and high-tech; but people who are serious about using C/C++ to > make money -- and thus to hire you with the money -- are going to be looking > for people who are "good", not people who just learned the language.
Are you thinking of new development or including maintaining existing programs? I don't know how much new development for business programs there is using C++ or how many places that aren't product companies, i.e. that only have themselves as users, would use it (I mean literally that I don't know, not that I doubt there are any), but we still use it as our primary language and I know the people who write Quicken use it. In 2005, I interviewed at a place that sold some kind of financial trading software that used it and later found a different job that had one C++ program among their Java and Perl. I was recently contacted by a recruiter who was looking for either MFC/C++ or .NET/C# people. She didn't seem to favor one over the other. There must be all kinds of code still needing work that was created in the late nineties when C++ with MFC (and maybe rogue wave?) was the thing to use in some circles. But I really have no perspective, since the recruiters who contact me know I know C++ programmers. Maybe I'll be doomed next time I'm layed off. Or I should nod and smile whenever people make C++ not sound like a lucrative place to be. About being good, that's not really my experience either. I probably know the language as well as anyone left at my company, and I'm certainly no great shakes. I think we hire like a lot of places. If they answer a couple simple questions like why would you want your destructors to be virtual or what's a concrete class (i.e. why would you not want them virtual) and have one C++ job in the resume they move through to the part of the process where others judge whether they can work with them and whether they seem reasonably quick on their feet. The memory leak issue is largely solved for average programmers by the use of reference counted smart pointers, which will be in the standard library in the new standard, but you can get them from Boost or make your own easily enough in the mean time. I suppose you could also plug in a conservative garbage collector like Boehm's too, but I have no experience with that. Was that the memory issue you had in mind, or something to do with copying or allocation strategies? Really, our very average programmers don't have much more trouble with our MFC and C++ code than they do with our C# code. The ones who were excited about .NET worked themselvs up over little issues like why they need to change function signatures in two places, but they would quiet down when there was a pressing deadline. The biggest issue we had, in my opinion, was the care you have to take to manage your dependencies well and get your physical design just so, to avoid long compile times, but hardware is catching up with our incompetence on that front each year. That and lately I see many optimization problems coming about from our thinking about databases as only a storage medium for objects. I've not worked at enough different places to know if there's a better solution, but I really wish there was some way that something like an RDMS's optimizer could bound the network, so you could just write code on the client side that will manipulate the data with an OO interface. Then this optimizer would figure out how it should send the data over (or send your code to the server) to avoid sending columns you won't use and to avoid many round trips with latency delays that would have been unnecessary if you'd asked for more things all in one go. Most of what I see is people making choices between doing things in stored procedures (where you need a version for each back end you support) and doing a relational/OO mapping, which seems like not a very good dichotomy for humans to have to worry about. But that's not C++ related, unless other languages have better libraries that solve it for you. -- Mike Small [email protected] _______________________________________________ Boston-pm mailing list [email protected] http://mail.pm.org/mailman/listinfo/boston-pm
