Thread: Check word

You want the user to input a string, right? "enter_word" is not a string in your code, though. Also, you need to use the "==" operator to test two things for equality.

Originally Posted by jimblumberg

I don't see where the OP is using a std::string or a C-string. Look closely at the provided code, what type of variable is enter_word?

Jim

I had already seen that, but that's far from the point. I am doubtful that comparison between an int and a string literal (presumably) is what he's trying to do. There's no way that would even make sense, but if he's comparing to a string, he's going to need another string unless he has some way to translate an int to some string content, without using the int datatype as a storage for some pointer type... -- which would also be very bad IMO.

I went off by what he's trying to do here (as best as I could interpret it):

Code:

if (enter_word"yellow"){ cout<<"Yep you are right bro!";}

Perhaps he doesn't understand the type system yet? Who knows...

I just assumed he wanted the logic of something in terms of comparison:

Code:

if (enter_word == "yellow")

Yet the best bet here would be if enter_word was a std::string.

As his code stands however, suggesting == for comparison without *fixing* the rest of the code first is horrible advice. I wanted to make sure that such problems are at least clarified before he did such a thing.

I thought it was obvious. Nobody should be using C-strings while working with C++ nowadays( unless they really have to ).

Originally Posted by GReaper

I thought it was obvious. Nobody should be using C-strings while working with C++ nowadays( unless they really have to ).

"c++ 1 week ago"

For someone who has been learning C++ for no more than a week and has given no proof of understanding of similar languages I think it's much better to be prudent when it comes to those kinds of assumptions.

Originally Posted by jimblumberg

No, that is the point. You seem to be assuming a lot about what the OP is actually trying to accomplish. IMO the first thing to point out, and was, it that the OP is using the wrong type, not starting to babble on about pointers, overloads, and read-only memory.

Jim

No it is not the point.. My statement about the == operator and std::string vs a raw c-string had to do with GReaper's post directly -- it's clear that you don't understand that as you keep relating my statement to OP's code for some reason.

Re:

I don't see where the OP is using a std::string or a C-string. Look closely at the provided code, what type of variable is enter_word?

I was simply saying that the only way the == operator would achieve string comparison would be to use std::string's most likely. Either way, although I didn't point out that the type was wrong, it wasn't really my intention to do so when I was speaking only on behalf of GReaper's suggestion. My post does imply the proper type to be using if OP decided to use the == operator for string data comparison, and that was the purpose of my post; clarity.

Furthermore, I'm not assuming any more than I have to by what OP is trying to do. He's provided invalid code that would never compile, so by filling in the gaps, one can best assume that he is trying to do string comparison. If you have a better idea on what he is actually trying to accomplish I would kindly suggest that you enlighten us on your theory, otherwise I don't know why you bring up the idea that I'm assuming things or what the purpose of that statement was...

Re:

You seem to be assuming a lot about what the OP is actually trying to accomplish

OP hasn't posted back in this thread for a week so far, and based on what I have read, my "assumptions" are no different than yours or other member's ideas of what OP was trying to do regardless.

On one hand, I think GReaper should have explicitly mentioned std::string as we know that some instructors start students on null terminated C-style strings first; on the other hand students should be learning strings with std::string first, so GReaper's assumption is understandable.

I think it would have been simpler to just recommend std::string, pointing out that otherwise GReaper's suggestion will be problematic, instead of objecting to GReaper's suggestion on the grounds that you "don't see the <string> header is included".

Originally Posted by laserlight

On one hand, I think GReaper should have explicitly mentioned std::string as we know that some instructors start students on null terminated C-style strings first; on the other hand students should be learning strings with std::string first, so GReaper's assumption is understandable.

I think it would have been simpler to just recommend std::string, pointing out that otherwise GReaper's suggestion will be problematic, instead of objecting to GReaper's suggestion on the grounds that you "don't see the <string> header is included".

Fair enough. As far as "string's" go, I was more apt to *guess* that he was going to take the suggestion into consideration without the use of std::string, and I know that many instructors start students off with dynamic allocation and raw c-strings in C++ regardless of the way C++ code should be written, in order to give younger programmers an idea of how such objects work in the background, even at a high level understanding without diving into the details of allocators and iterators. Smart IMO, but eventually I would expect that they teach students to forget about doing that kind of stuff in C++ and move onto containers for such things instead, unless you're programming in C.

You can't efficiently reap the benefits of std::string or containers like std::vector without knowing about fundamental concepts like dynamic allocation and how null terminated strings work as a minimum IMHO, so I can see the reasoning behind avoiding such things at the start at least.

Originally Posted by cstryx

I know that many instructors start students off with dynamic allocation and raw c-strings in C++ regardless of the way C++ code should be written, in order to give younger programmers an idea of how such objects work in the background, even at a high level understanding without diving into the details of allocators and iterators. Smart IMO, but eventually I would expect that they teach students to forget about doing that kind of stuff in C++ and move onto containers for such things instead, unless you're programming in C.

IMO that is not smart, though in practice it certainly does happen. Even the book that the webmaster authored, although it takes that "low level to high level" approach for containers, begins with std::string objects after glossing over string literals. For an alternative approach that I consider smarter, read Stroustrup's essay on Learning Standard C++ as a New Language (PDF).

I guess it depends on your perspective. For myself, which is all I can speak for, understanding low level concepts has definitely helped me understand how to effectively use such *features* of the C++ language, as well as a well-enough understanding for writing optimized code while keeping my code more C++-looking rather than some C code that I can improperly call C++... Stroustrup is always a good reference for C++ material. IMO there is a fine line between proper C++ and writing super-efficient code because using lots of the C++ language features actually means slower code, albeit, typically safer code more often than not. In some cases it's nice to have a combination of both, but in most cases that is where you see all C++ code written as true C++ code, and for any of the core stuff, C and ASM -- instead of having some code written in C++ that avoids a lot of C++ *features* to reduce the overhead at runtime.

Originally Posted by cstryx

As far as "string's" go, I was more apt to *guess* that he was going to take the suggestion into consideration without the use of std::string, and I know that many instructors start students off with dynamic allocation and raw c-strings in C++ regardless of the way C++ code should be written, in order to give younger programmers an idea of how such objects work in the background, even at a high level understanding without diving into the details of allocators and iterators. Smart IMO, but eventually I would expect that they teach students to forget about doing that kind of stuff in C++ and move onto containers for such things instead, unless you're programming in C.

You can't efficiently reap the benefits of std::string or containers like std::vector without knowing about fundamental concepts like dynamic allocation and how null terminated strings work as a minimum IMHO, so I can see the reasoning behind avoiding such things at the start at least.

It is not smart. Many people have problems dealing with high complexity from the start. To take an example, if you're going to teach someone how a car works, are you going to teach them exactly how the engine works first or are you going to teach them what components there are and how they connect? Furthermore, the teaching time is limited. It is better spent teaching people how to use building blocks to piece a program together than wasting time teaching people exactly how a computer works. That can be delegated to a computer architecture course.

If you're going to teach low-level concepts, start from high-level concepts are slowly break them down. Not the other way around.

Originally Posted by cstryx

understanding low level concepts has definitely helped me understand how to effectively use such *features* of the C++ language, as well as a well-enough understanding for writing optimized code

That is certainly true: abstractions leak, so if you know what is behind the abstractions, you are in a better position to make decisions in the face of such leakage. However, if actually read the article, you would see that the approach "presents code relying on relatively high-level libraries before going into the lower-level details (necessary to build those libraries)" and "presents common and useful techniques and features before details". That is, the details will eventually be explored, but where applicable the use of relatively high-level libraries will be presented first.