Well, I came across several string manipulation exercises for C++, such as reverse string, reverse words, and so on. I found out that using string stream makes it much easier to do those kinds of functions, and also much cleaner as you only need 2-3 loops for each function. This is pretty much because you don't need extra array(s) to manipulate, you just add stuff to the stream and convert it to string. As opposed to doing it C way, by manipulating characters in an array, which needs at least around 5-6 loops for complicated functions, and the codes become hard to read as well.
I'm not good with the internal working of the programming, so I don't really know which way is more efficient, but well, is it considered cheating to do it my way?
Is using string stream considered cheating?
Started by MPD Psycho, Nov 14 2007 10:08 AM
5 replies to this topic
#1
Posted 14 November 2007 - 10:08 AM
|
|
|
#2
Posted 14 November 2007 - 01:45 PM
No, this is not considered cheating and why would it be? It is an available library to you. I'm guessing it is more efficient to do it using your "cheat" way because there is less potential for errors and bugs.
#3
Posted 14 November 2007 - 04:58 PM
Lop said:
No, this is not considered cheating and why would it be? It is an available library to you. I'm guessing it is more efficient to do it using your "cheat" way because there is less potential for errors and bugs.
Well, I somehow get the feelings that some "hardcore" programmers would always try to come up with the solution that uses only <stdio.h> for every string manipulation exercise.
#4
Posted 14 November 2007 - 09:41 PM
The string-library, STL, etc. were all made for one purpose; to be used, and make it easier for the programmer to code. So, I do not see how this could be cheating. It's a good thing to know how to work with C-strings as well, though, but when you're working in C++, it's normal to use the C++-features.
#5
Posted 17 November 2007 - 06:09 AM
The libraries that are provided with C++ are generally going to be more efficient than what you would come up with doing it manually. They frequently were written with embedded assembler code, etc, to get the maximum efficiency. Moreover, why reinvent the wheel if you don't have to? A programming language that forces you to do everything the hard way isn't really helping you.
#6
Posted 18 November 2007 - 08:14 AM
Do everything the easiest way possible.
Your time >>>>>>>>>> Machine time.
Only give undue consideration to efficiency if your program will not work reasonably without it.
Even then optimise late and cleverly. Make it work, then make it work fast. Profile and reimplement the most travelled code more efficiently (remember a 1% improvement in a function that's called 1m times is better than a 95% improvement in a function that's called once). When reimplementing focus on better algorithms first then if you still haven't got enough performance look at silly hacks and ASM.
I seriously doubt any of this is needed though. For the most part, inefficiency is caused by naive algorithms. Silly hacking to account for what is a weak design is even more naive.
Your time >>>>>>>>>> Machine time.
Only give undue consideration to efficiency if your program will not work reasonably without it.
Even then optimise late and cleverly. Make it work, then make it work fast. Profile and reimplement the most travelled code more efficiently (remember a 1% improvement in a function that's called 1m times is better than a 95% improvement in a function that's called once). When reimplementing focus on better algorithms first then if you still haven't got enough performance look at silly hacks and ASM.
I seriously doubt any of this is needed though. For the most part, inefficiency is caused by naive algorithms. Silly hacking to account for what is a weak design is even more naive.


Sign In
Create Account


Back to top









