Why are developers so afraid of C++?
-
Eddie Velasquez wrote: I wonder why some C++ developers are so afraid to use certain less-known features of C++ like templates, pointers to members, operator overloading, etc. I don't think it is always a matter of fear, for the most part a C++ programmer should be very cautious about the use of more advanced features. Too many programmers often use advanced features for no good engineering principle but only because they want to use them. All of those features you mention can turn your code into spegetti very quickly. I can understand the mentality of those who promote VB, C#, Java etc as better languages for this very reason. C++ code often becomes far more complex than it needs to be because C++ programmers seem to be incapable of exercising common sense when engineering their code. If you cannot do that then you *should* be programming in VB regardless of how well you think you know C++. "There's a slew of slip 'twixt cup and lip"
Stan Shannon wrote: for the most part a C++ programmer should be very cautious about the use of more advanced features. Too many programmers often use advanced features for no good engineering principle but only because they want to use them As I've said before, inexperience can cause problems when misunderstood features are used in the wrong places, but a developer has to start using those parts of the language to gain experience. That's a catch-22 situation. I think mentoring and intensive and permanent self-training are two things that we're missing in this industry.
Eddie Velasquez: A Squeezed Devil (Don't you just love that anagram craze?)
Checkout GUIDGen.NET -
Well, having 25 years of programming, with the last 12 of those in C++, I've had to maintain a lot of code. Some of it mine, some of it not. I've seen C++ evolve from C-with-classes to a language that pretty much defines what software development is. I've also taught courses in it for new hires, and trained people on how to work with MFC. I interview people and test them on their coding knowledge and style. So I think that I'm pretty much qualified as knowing C++. I've also had to deal with programmers who insist that macros are the one true path, and point to the MFC message map structure as to why they are godlike. The fact that you cannot debug them properly when something goes horribly wrong (and it does) never bothers them. This is why templates were created. Passing everything as a pointer, and typcasting the living hell out of it is also fine. I know it's a CView that got passed to that CObject fifty functions ago, so I can blindly typecast it back. Sure, always works. No problem. For these people Microsoft has IsKindOf. For the rest of us poor bastards who have to deal with this code we have dynamic_cast, which is portable. Globals are cool. Static globals are even cooler. Putting static global things in with pragmas to force the intializtion order rocks. Never mind it's not portable. Never mind that a new version of the compiler breaks it. Whee! While(1) loops that cover 15 printed pages. In 6 point font. Those are fine. It compiles and runs, right? Ship it! A function that is 9,783 lines long. Even better, I'm a god, who needs a debugger. Every language has "features" that allows you to pull off "wow, cool!" operations. Never mind that nobody other than yourself understands that feature, without looking at it for a while, which means that your geek peerage level rises way up in your current job. Breaking common sense program design is never good. There are books on the subject of coding style. There are linting tools that check for these coding styles. Sadly, nobody seems to read these books or use these tools. They consider using a "feature" of the language a much more "cool" thing than actually writing code that can be mantained without their name being cursed. Software houses spend roughly 30% of their time mantaining old code (this is from my jobs over the years). If code was commented, and strange constructs not used, this could be cut in half. Or more. Instead, we wind up refactoring things like address offsets to class functions that are applied to a reference of a dervied clas
Todd C. Wilson wrote: Simple: using poor language tricks to make your code "cool" without showing a damn good reason why nothing else will possibly work, will get your ass fired. Period. I agree 100%. Just using any language feature just to be cool and look clever is irresponsible and dangerous in large projects. And the opposite, using any language feature were appropiate is good engineering. I don't think you would fire me then! ;) Todd C. Wilson wrote: PS: And I know damn well why you're posting this topic. Are you taking the subject of this thread personal? The thread was motivated by a discussion I was having with some friends and also in the lounge with you, John Simmmons and others. It's NOT a personal attack or anything like it. I'm no troll.
Eddie Velasquez: A Squeezed Devil (Don't you just love that anagram craze?)
Checkout GUIDGen.NET -
Eddie Velasquez wrote: What's your opinion? That not every developer needs to be a super guru who knows every single feature and function of a language so that they can always use the right feature in the right place. We need the super guru developers, no doubt. But we also need the average guys, like me, who can be pointed in the right direction and relied upon to get the job done at minimal cost. We cannot afford 20 super guru developers, but we can afford 15 average guys and 5 super guru's. It is the role of the super guru's to plan and structure the applications and show where advanced features must be used. It is then the role of the average developer to take that plan and implement it. Remember, any Tom, Dick or Harry can actually code if they have a good plan in front of them. Coding is just taking syntax rules and following them. Like a machinist with a lathe. They don't need to know every function or nuance of the lathe. All they need is a blueprint and then follow the blueprint to the letter. regards, Paul Watson Bluegrass Cape Town, South Africa "The greatest thing you will ever learn is to love, and be loved in return" - Moulin Rouge Sonork ID: 100.9903 Stormfront
Paul Watson wrote: It is the role of the super guru's to plan and structure the applications and show where advanced features must be used. It is then the role of the average developer to take that plan and implement it Amen. Very true.
Eddie Velasquez: A Squeezed Devil (Don't you just love that anagram craze?)
Checkout GUIDGen.NET -
Well, having 25 years of programming, with the last 12 of those in C++, I've had to maintain a lot of code. Some of it mine, some of it not. I've seen C++ evolve from C-with-classes to a language that pretty much defines what software development is. I've also taught courses in it for new hires, and trained people on how to work with MFC. I interview people and test them on their coding knowledge and style. So I think that I'm pretty much qualified as knowing C++. I've also had to deal with programmers who insist that macros are the one true path, and point to the MFC message map structure as to why they are godlike. The fact that you cannot debug them properly when something goes horribly wrong (and it does) never bothers them. This is why templates were created. Passing everything as a pointer, and typcasting the living hell out of it is also fine. I know it's a CView that got passed to that CObject fifty functions ago, so I can blindly typecast it back. Sure, always works. No problem. For these people Microsoft has IsKindOf. For the rest of us poor bastards who have to deal with this code we have dynamic_cast, which is portable. Globals are cool. Static globals are even cooler. Putting static global things in with pragmas to force the intializtion order rocks. Never mind it's not portable. Never mind that a new version of the compiler breaks it. Whee! While(1) loops that cover 15 printed pages. In 6 point font. Those are fine. It compiles and runs, right? Ship it! A function that is 9,783 lines long. Even better, I'm a god, who needs a debugger. Every language has "features" that allows you to pull off "wow, cool!" operations. Never mind that nobody other than yourself understands that feature, without looking at it for a while, which means that your geek peerage level rises way up in your current job. Breaking common sense program design is never good. There are books on the subject of coding style. There are linting tools that check for these coding styles. Sadly, nobody seems to read these books or use these tools. They consider using a "feature" of the language a much more "cool" thing than actually writing code that can be mantained without their name being cursed. Software houses spend roughly 30% of their time mantaining old code (this is from my jobs over the years). If code was commented, and strange constructs not used, this could be cut in half. Or more. Instead, we wind up refactoring things like address offsets to class functions that are applied to a reference of a dervied clas
