|
String class| vectorcpp (11) |  |
| I am in the middle of writing a program where I declare two objects to be of the string class. However, I am new to this section of C++ and I think I may have declared them incorrectly (i.e the errors I get when I compile should go away if I fix them). Can anyone tell me the proper way to do this? This is what I had String target, pattern; Where target and pattern were the objects. | |
| Duoas (3505) | | ||
C++ is case sensitive, so you have to be careful.
Hope this helps. | |||
| vectorcpp (11) | |
| I thought class names usually began with a capital letter? I suppose the syntax is just different. My mistake. Thank you. | |
Last edited on | |
| Bazzy (4120) | |
| Standard library class and function names are lower case, the reason for this may be to make those easier to type. | |
| kempofighter (672) | |
| When you write "user defined" classes it might be typical for the typenames to begin with uppercase letters. That is how it is on the project that I work on. However, the std::string is part of the standard template library, therefore your project specific coding standard doesn't apply here. | |
| vectorcpp (11) | |
| Thank you all. I actually had another question and will take the liberty of posting it on this thread. What does the find() function return if the two string arguments are not equal? Is there another function that handles this? | |
| Bazzy (4120) | |
| It returns string::npos There are many string member functions which find something, see http://www.cplusplus.com/reference/string/string/ (scroll down to String operations ) | |
| vectorcpp (11) | |
| Thank you. | |
| kempofighter (672) | |
| Honestly, sometimes I do not like the string find function because it does not return iterators the way the std algorithms do when searching a container. I prefer using std::find on strings in many cases. The general rule is to prefer the container functions when they provide a function with the same name as an algorithm but this case is an exception for me. The std find algorithms work just as well except that they return iterators instead of the position offset and npos value. I sometimes find it easier to work with iterators, but that is just my opinion. | |
| jsmith (3807) | |
| I agree. It is a remnant of the fact that std::string came before the STL. Since string::find() of a char isn't really any faster than std::find(), I agree that using std::find() is probably a better solution on the grounds that it is more general. | |
| vectorcpp (11) | |
| Interesting, this program was one assigned by my instructor who for purposes of instruction, I assume, required me to use the string class. Honestly, I am new to these std algorithms, but if either one of you has more information on them I would be interested in it. | |
| kempofighter (672) | |
| I was simply stating an opinion. There is nothing wrong with using std::string::find instead of std::find. I was just sharing my personal preference about the subject. The algorithms are found here. I can understand your constraints as a student but as you develop your own knowledge of the language there is no reason that you can't experiment with the algorithms on your own so that you can learn about them. Most have simple main functions demonstrating their use that can easily be copied, pasted, compiled, and executed. http://cplusplus.com/reference/algorithm/ | |
| Hammurabi (399) | | |
Otherwise known as -1. :) | ||
| Duoas (3505) | |
| Don't assume knowledge of magical values. | |
| Hammurabi (399) | |
| A "magical value" is one that has no logical explanation. string::size_type(-1) is, as you know, the highest value that a size_type can hold. If 0 is not available as a special value (and it isn't), then -1 is the only other reasonable value to use. From the C++ Standard: Clause 21.3, Paragraph 6: static const size_type npos = -1; | |
| Duoas (3505) | |
| http://en.wikipedia.org/wiki/Magic_number_(programming) Reasonableness doesn't have anything to do with it. Besides which, you missed my point. | |
| Hammurabi (399) | | |
Nope. I understood you completely. However, you've missed the point entirely, which is that string::npos == -1. And obviously reasonableness has EVERYTHING to do with it in this particular case. What other value would you suggest? | ||
| Zhuge (634) | |
| I think the idea is that if, for some unfathomable reason, the string::npos was changed to -2, then checking vs. -1 won't work. Of course, it is very unlikely it ever will but that's no reason to use -1 when there is a perfectly good constant that explains the check. | |
| Duoas (3505) | |
| > Nope. I understood you completely. So, now you are so smart that you are actually telling me that you actually understood what I said -- even though I don't believe you? What is your problem? Don't encourage people to use literal values in place of established symbolic names. There is a great deal of literature on this very concept for you to use your excellent finding skills to read. Oh, and BTW, I know how to read source code too. The point is exactly this: - littering your code with literal constants is typically a bad idea - using -1 causes compiler complaints when size_type is unsigned (as indicated in the standard) when strict warnings are enabled - the value of string::npos may potentially change or be modified Why rely on a constant value when a convenient name is given to it? It is bad programming practice and a bad idea. Please don't encourage utter newbies to even think about doing it. | |
| Hammurabi (399) | |
| > So, now you are so smart that you are actually telling me that you > actually understood what I said -- even though I don't believe you? So now your arrogance has grown to such monstrous proportions that you are dictatingt to me what I know? You are truly a pathetic little boy! Stop crying and grow up. | |
Pages: [1] [2]
This topic is archived - New replies not allowed.