Thread: cstrings and strings

Perhaps a little more accurately:

Code:

for (std::string::size_type x = 0, size = stdString.size(); x < size; ++x)

Otherwise your compiler might complain that x is an integer but it is being compared with an unsigned integer. size() also has constant complexity, so the above is just an example of avoiding multiple function calls.

how do I assign a C style string to the C++ string?

There are a number of suitable constructors:
1. The constructor that takes a null terminated C style string, or
2. The constructor that takes a null terminated C style string and a size, or
2. The constructor that takes an iterator pair (to the beginning and one past the end of the C style string).

Originally Posted by dragongunner

Hello Daved, how do I assign a C style string to the C++ string?

With a simple =

Code:

std::string hello = "Hello";

Originally Posted by laserlight

Incidentally, it would be better to prefer ++it to it++ since the former is no slower than the latter and might be faster, with equal readability.

I don't know about that. If to prefer to avoid mistakes or such, then mayhap. Generally, I don't like ++n, I always use n++ unless I need ++n, so it's a taste thing, I think.

As laserlight said, ++it is no slower and might be faster, yet is equally readable. It is an extremely minor issue, but there's no logical reason your taste should be for it++ over ++it.

>> I don't know about that.
There should be plenty of explanations on why it might be faster available on the web. If you have Meyers' More Effective C++ (Item 6) or Sutter and Alexandrescu's C++ Coding Standards (Item 28) you can read explanations there.

Note that we're referring to iterators here. Built-in types are likely never going to show a difference, so in that case perhaps it doesn't lack sense to prefer the look of post-increment. However, for consistency alone I don't see why you would.

Originally Posted by Daved

As laserlight said, ++it is no slower and might be faster, yet is equally readable. It is an extremely minor issue, but there's no logical reason your taste should be for it++ over ++it.

>> I don't know about that.
There should be plenty of explanations on why it might be faster available on the web. If you have Meyers' Effective C++ or Sutter and Alexandrescu's C++ Coding Standards you can read explanations there.

Yes, pre increment returns a reference and the post returns a new object, as per the rules on overloading.
But as for ++n or n++, well... unless you are writing time critical code, it hardly matters. I don't know what the best thing to do is... teach them it might be faster and say should try to use it as a good practice or saying it hardly matters anyway since the speed will be about equal.

But, as some others are, I'm reluctant as to teaching what someone should use. They should use what they feel is best. Though I'm not going to argue the point.

Originally Posted by Elysia

I don't know about that. If to prefer to avoid mistakes or such, then mayhap. Generally, I don't like ++n, I always use n++ unless I need ++n, so it's a taste thing, I think.

It needs to be noted though that the postfix operator does more work. The prefix operator returns an lvalue (it increments the object and returns the object itself) whereas the postfix returns a rvalue. The compiler needs to store the original value. For built-in types, pointers and simple user-based objects capable of iteration this should probably be optimized for the compiler. But for more complex objects, this storage may come at a higher cost.

The prefix operator should be preferred instead and the postfix operator used only when there is a need.

No, my point was that people should not be "taught" to only use ++n unless n++ was necessary; the point was it's a choice and one shouldn't advise people to use one over another.
Now performance issues with ++n and n++ is an entirely different case, but I don't want to confuse on the above matter.
Anyway, I digress.

Originally Posted by Elysia

No, my point was that people should not be "taught" to only use ++n unless n++ was necessary; the point was it's a choice and one shouldn't advise people to use one over another.

Well, one should when the issue is introduced for some reason. And what one should advise is prefix over suffix for a reasons of consistency, since on large or complex objects postfix increment or decrement has the potential to be costly.

No, my point was that people should not be "taught" to only use ++n unless n++ was necessary; the point was it's a choice and one shouldn't advise people to use one over another.

In a sense I agree that if that was the only point of the original post, then it would be as pointless as posts that say nothing beyond void main() or indentation (I mean, if that's all one's got to say, may-be it would be better to ignore the thread).

However, in this case it was pointed out as a side note and indeed one option is preferable to other, so it's something that's good to know and I don't see your point. I started out as a "post-increment user" myself, but after reading a similar comment, I simply changed my habit.

Actually, I think it was my mistake.
Originally, when I read through, I was thinking that laserlight was encouraging the ++n syntax before n++ (in all cases), but now I realize laserlight was proposing the use of ++n due to the variable being an iterator.
Of course, it might be preferable to use ++n with objects and iterators.

This was all my misunderstanding. Sorry about the mess.

Habit over evaluation. By simply always using prefix increment, you avoid having to think about whether postfix incurs a performance penalty in this case. It also makes your code look more consistent: if one for-loop uses postfix and the next prefix, that's ugly.

That's the rational and objective argument speaking for always using prefix increment. (Except, of course, the places where the semantics really require postfix.) There is no such argument for preferring postfix, only a subjective "matter of taste".
Thus, always using prefix is clearly the better solution.


Hmm ... is there a way to unquote something?