I believe telemarketing is a plague and should plain and simple become illegal. Spam should also be illegal, as any unsollicited publicity. I'm gonna start charging rental space for my mailbox!
First, there are two types of tests:
Unit Tests and Functional Tests.
The first type, unit tests can be measured and rather easily implemented as part of your coding process. This is, to test every function of your libraries, and if you're up to it, you should even write these tests before implementing the functionality to be sure it measures up to your expectation of what it should be doing.
These tests must be run before putting anything on the source code database by the programmer and should also be automatically run periodically to asses that the code is still perfect. The idea is NOT to test everything, but to test the limit and probable problems that you think you could encounter. As you find programming but, you should ADD a test to make sure that the bug never crawls back in your code. That being said, it does not make your code full proof and neither TESTED! It only makes you, the coder, more confident that your code "works". That is a great achievement though... how many times has your boss ever asked: "So, does it work?" and you say...: "Huh... well, it worked when I tried it..." now you can tell him/her... I've tested it within reason and it works perfectly fine.
That should never take the place of Functional Testing. Some stuff cannot be tested programmatically, for example, you cannot really test much of anything having to do with communication ports and communication errors. These should be done by hand by somebody who is from the QA department (if you're lucky enough to have one;-) If there are major bugs at this stage of testing, you probably had a bogus design to begin with as most of these bugs should be faily minor.
just my thoughts...
My comments are with the VC6 version of the STL and do not necessarely apply with another compiler.
When I first started using STL, I first hated the fact that everything had an underscore (argh!). Second thing that pissed me off was the nomenclature of the methods. For instance, with the stl vector, what did I expect std::vector::empty() to do? I expected it to empty the vector. What does this actually do? It tells you whether the vector is empty or not. Why not use a method called IsEmpty() ? or is_empty();-).
After this first bad encounter, I decided to give it a shot and started using it extensively whenever I had the occasion. At first, mainly for strings and vectors. I found the iterators particularly fun to use. And now I would never go back to using char * or arrays unless I really have to. Mainly, I love the fact that everything a casual C++ programmer ever wanted IS in the STL, all these data structures you learned in school are integrated AND templatized! The only thing that is not explicitely included are trees unfortunately:-(. And yes, I know a std::map uses a binary tree structure.
After using the STL on projects, I found 2 major irritating things:
1) When you have a syntax error, the compiler lets you know by filling the screen with the function signature and it can be hell to decipher if you're not used to it. And with VC, if you use vectors without a #pragma warning ( disable : 4786 ), the warning the compiler gives you takes 10 lines.
2) Some STL classes do not tranfert good between an application and objects in a DLL. Mainly cause some variables are on the stack of the DLL and cannot be shared with the main application. I think this is a M$ implementation bug specific, but anyway, it can be a pain in the ass to find a solution. usually, you have to use good old arrays and structs to transfert data between the DLL and the main app.
Other than that, after the learning curve is flattened, STL is a great productive tool.
Slashdot Mirror
Please, take out the next to last digit space out of the string... dunno what happened.... (no space between the 2 and the 6).
Seems like Canada wants its part of the market and are aggressive about it.
Ok. It seems the link was somehow tempered during the process of posting this...
2 6
Here is the link:
http://www.cbc.ca/stories/2002/08/26/diamonds0208
I just thought I would point out this link as I find it very on-topic for this thread:
2 6
http://www.cbc.ca/stories/2002/08/26/diamonds0208
I believe telemarketing is a plague and should plain and simple become illegal. Spam should also be illegal, as any unsollicited publicity. I'm gonna start charging rental space for my mailbox!
First, there are two types of tests: Unit Tests and Functional Tests. The first type, unit tests can be measured and rather easily implemented as part of your coding process. This is, to test every function of your libraries, and if you're up to it, you should even write these tests before implementing the functionality to be sure it measures up to your expectation of what it should be doing. These tests must be run before putting anything on the source code database by the programmer and should also be automatically run periodically to asses that the code is still perfect. The idea is NOT to test everything, but to test the limit and probable problems that you think you could encounter. As you find programming but, you should ADD a test to make sure that the bug never crawls back in your code. That being said, it does not make your code full proof and neither TESTED! It only makes you, the coder, more confident that your code "works". That is a great achievement though... how many times has your boss ever asked: "So, does it work?" and you say...: "Huh... well, it worked when I tried it..." now you can tell him/her... I've tested it within reason and it works perfectly fine. That should never take the place of Functional Testing. Some stuff cannot be tested programmatically, for example, you cannot really test much of anything having to do with communication ports and communication errors. These should be done by hand by somebody who is from the QA department (if you're lucky enough to have one ;-) If there are major bugs at this stage of testing, you probably had a bogus design to begin with as most of these bugs should be faily minor.
just my thoughts...
My comments are with the VC6 version of the STL and do not necessarely apply with another compiler.
;-).
:-(. And yes, I know a std::map uses a binary tree structure.
When I first started using STL, I first hated the fact that everything had an underscore (argh!). Second thing that pissed me off was the nomenclature of the methods. For instance, with the stl vector, what did I expect std::vector::empty() to do? I expected it to empty the vector. What does this actually do? It tells you whether the vector is empty or not. Why not use a method called IsEmpty() ? or is_empty()
After this first bad encounter, I decided to give it a shot and started using it extensively whenever I had the occasion. At first, mainly for strings and vectors. I found the iterators particularly fun to use. And now I would never go back to using char * or arrays unless I really have to. Mainly, I love the fact that everything a casual C++ programmer ever wanted IS in the STL, all these data structures you learned in school are integrated AND templatized! The only thing that is not explicitely included are trees unfortunately
After using the STL on projects, I found 2 major irritating things:
1) When you have a syntax error, the compiler lets you know by filling the screen with the function signature and it can be hell to decipher if you're not used to it. And with VC, if you use vectors without a #pragma warning ( disable : 4786 ), the warning the compiler gives you takes 10 lines.
2) Some STL classes do not tranfert good between an application and objects in a DLL. Mainly cause some variables are on the stack of the DLL and cannot be shared with the main application. I think this is a M$ implementation bug specific, but anyway, it can be a pain in the ass to find a solution. usually, you have to use good old arrays and structs to transfert data between the DLL and the main app.
Other than that, after the learning curve is flattened, STL is a great productive tool.
proxima centauri, closest star to our sun!