I think that it's important to note that the US is far from true capitalism and far from true democracy.
I think that it would be nice for someone to actually give the "free market" a try since to my knowledge it really hasn't ever been tried. I could definitely be wrong. Just thinking out loud.
>>If the answer is "never", then your code must be debuggable. STL isn't, at least not with today's compilers, although you can approximate it for the *common* errors with a sed script.
I'll buy this. You are right. The debugging process can never end if we are going to strive for improvement and if debugging is made harder due to poor implementation it's like someone throwing rocks down at you while you are climbing a cliff.
True it doesn't mean that you found all of the bugs. In fact I highly doubt that you will ever find all of the bugs on any piece of code that isn't trivial.
Don't write code that is ugly, obscure, or especially hacked up. This is where planning comes into play once again. You need to have a clear understanding of what you are trying to implement or the use of STL and/or OOP is probably a bust.
Well, that's just the thing. The point is that you shouldn't wait until you've implemented five levels of code before you start debugging let alone compiling. You code a class, compile it, test it as much as you can and then add another class. Repeat.
The other issue is that you must plan ahead and think about what you are doing before you start coding. If you are going to code by the seat of your pants then OOP is a very bad idea. You are far too likely to program yourself into a corner. To be in a situation where something that is burried under five layers of classes needs something that is burried under five entirely different classes is a very frustrating situation. You can back yourself into that situaion with most any OO language.
If you are going to code by the seat of your pants then you should write really ugly Perl. =)
This is true but the beauty of C++ is that you can implement the obscure, ugly stuff once and burry it in a class with whatever type of interface you would like to use. Abstraction is your friend.
I got a job in less than a week back in November. I just put my availability up on dice [dice.com] and got a call in less than 24 hours. I now have a decent paying job working with people I like doing all kinds of different things, from programming, to system administration, to web design to router administration. I did all of this with very little induxtry experience. Pretty much everything I learned prior to getting hired I learned at home on my own little POS network pieced together from spare parts I got for free. Maybe there just aren't enough people who love being in IT.
Slashdot Mirror
Dont' forget Cowboy Neal!!!
Sorry. I couldn't resist.
Seriously though, I'm okay with us being a Republic I just wish we'd elect representitives who aren't idiots.
In the end they should really just make me supreme dictator for life.
I think that it's important to note that the US is far from true capitalism and far from true democracy.
I think that it would be nice for someone to actually give the "free market" a try since to my knowledge it really hasn't ever been tried. I could definitely be wrong. Just thinking out loud.
Add a 31st day to your April Calendar?
>>If the answer is "never", then your code must be debuggable. STL isn't, at least not with today's compilers, although you can approximate it for the *common* errors with a sed script.
I'll buy this. You are right. The debugging process can never end if we are going to strive for improvement and if debugging is made harder due to poor implementation it's like someone throwing rocks down at you while you are climbing a cliff.
I love Perl. =)
True it doesn't mean that you found all of the bugs. In fact I highly doubt that you will ever find all of the bugs on any piece of code that isn't trivial.
Don't write code that is ugly, obscure, or especially hacked up. This is where planning comes into play once again. You need to have a clear understanding of what you are trying to implement or the use of STL and/or OOP is probably a bust.
Well, that's just the thing. The point is that you shouldn't wait until you've implemented five levels of code before you start debugging let alone compiling. You code a class, compile it, test it as much as you can and then add another class. Repeat.
The other issue is that you must plan ahead and think about what you are doing before you start coding. If you are going to code by the seat of your pants then OOP is a very bad idea. You are far too likely to program yourself into a corner. To be in a situation where something that is burried under five layers of classes needs something that is burried under five entirely different classes is a very frustrating situation. You can back yourself into that situaion with most any OO language.
If you are going to code by the seat of your pants then you should write really ugly Perl. =)
This is true but the beauty of C++ is that you can implement the obscure, ugly stuff once and burry it in a class with whatever type of interface you would like to use. Abstraction is your friend.
I got a job in less than a week back in November. I just put my availability up on dice [dice.com] and got a call in less than 24 hours. I now have a decent paying job working with people I like doing all kinds of different things, from programming, to system administration, to web design to router administration. I did all of this with very little induxtry experience. Pretty much everything I learned prior to getting hired I learned at home on my own little POS network pieced together from spare parts I got for free. Maybe there just aren't enough people who love being in IT.