Why are developers so afraid of C++?
-
Christian Graus wrote: Some people are just too stupid to use C++... Christian Graus wrote: ...adding to the number of VB users. Damn, and here I was thinking we had got past this whole VB is for idiots, C++ is for clever people debate. :| 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: Damn, and here I was thinking we had got past this whole VB is for idiots, C++ is for clever people debate. Sometimes it's just too easy.... If VB is all someone needs, then there is no reason for people not to use it. BUT there is no denying that it is less complex, less flexible and less powerful than C++, precisely because of the sort of language features mentioned in the original post. I think VB is in the same boat as AOL - never able to shake off the fact that it's simplicity attracts the morons of this world as well as people who will use the tool properly and despite it's limitations achieve what they want to with it. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little. "I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
-
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. Some argue that some features are so confusing and obscure that they won't use them even if it provides the optimal solution for the problem at hand. Some also argue that the maintenance cost is too big considering that mostly junior developers do maintenance. I can see the point, but a junior developer should always have a senior at hand that can teach him. Sometimes I believe that developers get scared of the C++ myth or are too lazy to try to fully understand the language. What's your opinion?
Eddie Velasquez: A Squeezed Devil (Don't you just love that anagram craze?)
Checkout GUIDGen.NETEddie 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
-
Lucky for me they hired two people at once, me and a guy who knows VB very well. They have people for the VB side, I won't be squandered on testing in VB. I will be doing ASP.NET shortly though, so I'll be doing a lot of C#, methinks. Christian The tragedy of cyberspace - that so much can travel so far, and yet mean so little. "I'm thinking of getting married for companionship and so I have someone to cook and clean." - Martin Marvinski, 6/3/2002
Lets hope he will not be occupied with other projects and he will find the time to test. Me wish thee good luck. Best regards, Paul. Paul Selormey, Bsc (Elect Eng), MSc (Mobile Communication) is currently Windows open source developer in Japan.
-
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. Some argue that some features are so confusing and obscure that they won't use them even if it provides the optimal solution for the problem at hand. Some also argue that the maintenance cost is too big considering that mostly junior developers do maintenance. I can see the point, but a junior developer should always have a senior at hand that can teach him. Sometimes I believe that developers get scared of the C++ myth or are too lazy to try to fully understand the language. What's your opinion?
Eddie Velasquez: A Squeezed Devil (Don't you just love that anagram craze?)
Checkout GUIDGen.NET3 reasons to this : 1º they're lazy :mad: 2º Maintenance of the code, in this case I with 2 other colleagues, were involved in programming a selling ticket Machine requiring a certain degree of complexity, this with the following aspects, I was the only to know to program multithreaded code on windows(the app was heavy multithreading),one guy didn't know shit of c++, so I teached him a lot on the work, the other besides being a bit lazy in some aspects in terms of c++ semantics,he doesn't to read programming books, because he likes to a have normal life. This leads us to the 3º they didn't have a clueless idea on templates neither on stl. So ... And one more thing, I was involved in 6 months on the project, after that because they lost a LOT of MONEY, between my colleague and me(both of us consultants of other company), they decided to kick me back, why do you ask ? Well, the answer is simple ... I did know more c++ than my boss and the programming manager, so I was told that for thinking, they have enough people, who, may you ask again? Of course THEM :mad: And this only because the ideas about the arquitecture of the app that I supplied to my chief, he refused every one, making me program his solution, and after a time, he will bring my idea as his idea, and so recoding everything again. :eek: Oh well ... Cheers and best luck next time Joao Vaz
-
Damn straight. :) A new country song, "Don't take my goto away". Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
Tim, I honestly have to say that after 13 years of C++ programming, I have NEVER used a goto, or found a need for one. However, I absolutely could not live without pointers. :) "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
-
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
Damn, I might now agree with everything you said, but this message should be required reading. Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
-
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
Nicely put, if this was slashdot I'd moderate you +5 Insightful Michael :-)
-
Using functors to replace a "simple" for loop is overkill, but when you're writing generic code that can be used with any container of any type (with certain restrictions) for_each, functors and their kind are absolutly necessary. The thing is that sometimes you don't need to write generic code and that when inexperienced screw things up. I would love to see the study of how many of these "generic functors" actually get reused. I once did a once over of my for loops and it was rare I could find instances where a functor would have been reusable. If I have the need for reusable code, it becomes a routine. Also, looking at a lot of the hoops I have seen people jump through to get functors to do what they want, I reject the notion that it is more bug free. ...optimal... This is a case where we agree totally. I am all for the right tool for the right application. Any time you totally reject the old OR the new, you are making a HUGE mistake. (and I don't mean "you" and in you) Tim Smith I know what you're thinking punk, you're thinking did he spell check this document? Well, to tell you the truth I kinda forgot myself in all this excitement. But being this here's CodeProject, the most powerful forums in the world and would blow your head clean off, you've got to ask yourself one question, Do I feel lucky? Well do ya punk?
Tim Smith wrote: I reject the notion that it is more bug free. Have you read "More Exceptional C++" by Herb Sutter? It explains why STL algorithms often are less error-prone and sometimes are more efficient than hand-written code. Unfortunately I don't have the book at hand so I could tell you which page to look. The thing has to do with preventing "off b one" errors, excesive calls to copy ctors and function calls in the conditional of the "for" statement the way the average programmer codes them.
Eddie Velasquez: A Squeezed Devil (Don't you just love that anagram craze?)
Checkout GUIDGen.NET -
Tim, I honestly have to say that after 13 years of C++ programming, I have NEVER used a goto, or found a need for one. However, I absolutely could not live without pointers. :) "...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
Squishy Tampon of Justice wrote: after 13 years of C++ programming, I have NEVER used a goto It might sound embarrasing :-O, but I've found that gotos are extremely useful when coding finite state machines that have to be fast.
Eddie Velasquez: A Squeezed Devil (Don't you just love that anagram craze?)
Checkout GUIDGen.NET -
Eddie Velasquez wrote: Those are the crappy books that follow the Java karma: "You're stupid, you can't understand pointers... You'll never learn... You're stupid, you can't understand pointers... You'll never learn". So lets get rid of pointers! Absurd. You can say that again! And what about garbage collection? I understand that if you're not careful that you can get memory leaks, but is this REALLY the huge problem that the creators of Java make it out to be?
Jnaut wrote: And what about garbage collection? I understand that if you're not careful that you can get memory leaks As if memory was the only resource that could leak! What about database connections, files, sockets, etc. What does the Java mantra have to say about that?
Eddie Velasquez: A Squeezed Devil (Don't you just love that anagram craze?)
Checkout GUIDGen.NET -
Multiple reasons: 1. C++ is a complex language. Some say it takes 5 years to master. Obviously not every C++ developer is going to know all the features of the language. 2. Sometimes developers are to busy to learn (or lazy) 3. In my experience I often spend more time maintaining code than developing new code. As such it makes more sense to write code that's easy to understand for everyone. Using advanced features can make maintenance more difficult. 4. In order to really learn the more advanced features of a language it helps to have a project where you can apply them on a daily basis. Not every gets to work on such projects. That tends to hinder one's ability to learn the features well.**
Todd Smith
CPUA 0x007 ... shaken not stirred
**
Todd Smith wrote: C++ is a complex language. Some say it takes 5 years to master. Obviously not every C++ developer is going to know all the features of the language. I agree. Todd Smith wrote: Sometimes developers are to busy to learn (or lazy) Most of the C++ developers I personally know will find any excuse just to say that they're too busy to pick up a book and read.
Eddie Velasquez: A Squeezed Devil (Don't you just love that anagram craze?)
Checkout GUIDGen.NET -
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