How to check what is the last char of a

How do i check wether (lets say, string end) end is the last character of a string?

Is it: if (end = string.npos) ?

If I understood the question correctly, it's

1
2

If (!string.empty() && end == *string.rbegin() )
{

1
2

If (!string.empty() && end == string[string.size() - 1] )
{

Last edited on

vlad from moscow (6539)

Type std::string is not the same as type char. So you should elaborate what is 'end' in your post?

If Cubbi's post is not the answer you were looking for, tell us: you wouldn't happen to be messing with iterators, would you?

Hello, sorry because my explanations are not so... explanative.

I am trying to check wether the last character of a string is a "\" (char(92))

If the last character of that string is indeed a "\" then cout << "YES", else cout << "NO"

Cubbi, you are a genius! Thank you very much for your answers guys! That's what i wanted!

EDIT: Can you please tell me what does the "*" do, in general? (*string.rbegin() )

Last edited on

Peter87 (11234)

You can also use the back function to get last char of the string.

1
2

If (!string.empty() && end == string.back())
{

Thank you!

Right, totally forgot about .back()

Can you please tell me what does the "*" do, in general? (*string.rbegin() )

It dereferences what's on the right.
In this case what's on the right is the reverse begin iterator, which points to the last character of the string and increments to the left. (it's the opposite of the usual begin iterator, str.begin(), which points to the first character of the string and increments to the right)

vlad from moscow (6539)

@Cubbi
Right, totally forgot about .back()

Cubbi you forgot that there is such a function as front!:)

1
2

if ( !string.empty() && ( std::reverse( sttring.begin(), string.end() ) , end == string.front() ) )
{

Last edited on

Er, back() and front() are fixes to the std::string class made by the C++11 standard. While it is reasonable to assume that most people here are working with a compiler that understands C++03, it is not (yet) reasonable to assume that everyone is on our C++11 high horse.

std::string has over a hundred* member functions, there's lots of room for creative programming.
* http://www.gotw.ca/gotw/084.htm

But, he's making an argument against the current STL design and not the string class. He's just picking on std::string because it is convenient.

I don't consider the std::string to be particularly bloated. Every reference I could find to support "It's widely accepted that basic_string has way too many member functions" actually wraps right back around to Herb Sutter.

The string class is in the odd position that it needs to behave like a standard container, but it has to specialize some important text handling stuff. A little fluff for the programmer who uses this exceedingly important object is fine. It doesn't actually fluff your executable size any when you don't use it.

He first takes aim at stuff that applies equally to all containers. He then picks on std::string's specializations, using the rationale that the standard algorithms can do it too.

Well, yeah, they can, but the whole point is that it is specialized to the most important object in computing. Once you consider that, you realize that the specialization must be done, and Mr. Sutter is just advocating moving it elsewhere.

My $0.02.

vlad from moscow (6539)

@Duoas

elsewhere. is where?:)

cire (8284)

Duoas wrote:
But, he's making an argument against the current STL design and not the string class. He's just picking on std::string because it is convenient.

No, I'm pretty sure he's making an argument against monolithic classes, one of which is std::string.

The article wrote:
Decomposition and encapsulation are Good Things. In particular, it's often best to separate the algorithm from the container, which is what the STL does most of the time.

Certainly doesn't seem to suggest he's going after the STL design as a whole.

@vlad
If you don't specialize for string operations in the string class, you will have to specialize for string operations in all the STL algorithms that work over string classes.

@cire
What a person says he is saying and what he is actually saying are not always the same thing.

Ostensively, his article is about efficient class design vs "monolithic classes". He spends the article supporting his viewpoint by attacking parts of the STL's container classes' design, while holding up the string class as an example.

I never said he was attacking the STL as a whole.

cire (8284)

Apparently what you're reading and what I'm reading aren't the same thing.

string was never in STL to begin with, and the result of the hurried merge of all the different flavors of strings into one class in 1998, with the STL container interface slapped on last minute, has been rightfully criticized ever since, not just by Sutter.

@cire
Too bad you're so arrogant that we cannot simply have a difference of opinion, but I must be too stupid to understand what you understand. As that is the case, I'm done talking with you.

@Cubbi
True, and I'm not defending poor std::string here against the Evil Dr. Sutter. I do think it a bit of a stretch to say it was all crufted together "last minute". The string and container class interfaces were pretty heavily considered by a lot of big, smart, important people -- including but not only Sutter. And his article makes some important points. I just think that his presentation logic is a little off and mistreats string.

Compared to some other big string classes in important frameworks, the STL string is positively lightweight and clean without losing important characteristics.

I still have to see any major criticisms of std::string that don't relate to someone agreeing with Sutter. But then again, I don't spend all day considering how to improve it.