I just don't get this...

Code:

---

for (auto i = vec.begin(); i != vec.end(); ++i)

---

Or I wonder if this works...

Code:

---

for (auto i = vec.begin(), end = vec.end(); i != end; ++i)

---

Or your example, of course...

Code:

---

for (auto end = vec.size(), i = 0; i != end; ++i)

---

Shortcuts. Gotta love 'em.
Hopefully they DO work.
Iterator method works for sure, though.

Ah! That new C looks too simple o.o That can never be good...

C++, and you gotta see it to believe it. It's going to make things so much easier for programmers. You will see. You will welcome it.

So was the nuclear reaction :P
Anyways, if it makes it C++ simpler, must it then not make it... Not as good? Like, slower, less features, something?

Nope. It will actually make it more flexible, because with template programming, functions can return some incredibly complex type (like boost::bind or stuff). So having auto makes it simpler while allowing for more, flexible and complex functionality!

It sounds good, but you only tell the good sides :P there are always bad sides too ;)
I'm a bit sceptical(?) about this new C++...

In particular, why should the auto keyword (automatic deduction of variable type from the return type of a function) cause any runtime penalty - it only happens at compile-time. So, it can only make compiling slower (and probably not much here). It's trivial for the compiler to know what type vec.begin() returns, whereas it is not as simple for the programmer - you could easily type std::vector<X>::iterator where it actually should be std::vector<X>::const_iterator and get an "incomprehensible" compiler error.

There are also features that are supposed to make C++ programs faster (e.g "move constructors").

Well, it is possible to abuse auto...

Code:

---

auto i = 100; // i = ???

---

But that's the story with everything. No, the new standard will bring more good than bad.

Quote:

---

Originally Posted by anon

I wonder if C++0x would allow this though

Code:

---

for (auto end = vec.size(), i = 0; i != end; ++i)

---

---

Hmm... no it wouldn't. You still need a type declaration for i. However, you will be able to do this:

Code:

---

for (auto end = vec.size(), decltype(end) i = 0; i != end; ++i)

---

Quote:

---

Originally Posted by Elysia

Well, it is possible to abuse auto...
Code:

Code:

---

auto i = 100; // i = ???

---

---

IIRC that will in fact produce a compile time error. auto usage cannot result in ambiguity.

The Wikipedia article however uses this as an example. Don't the literals in their various forms have a default type that they are associated with, for which reason i should be int without ambiguity?

As to the decltype example, I don't think you can do

Code:

---

for (unsigned i, unsigned end; ...; ...)

---

and therefore your example probably wouldn't work either.

A little more about struct's :P
"4-6. Rewrite the Student_info structure to calculate the grades immediately and store only the
final grade."
I tried making struct like this:

Code:

---

struct Student_info{
    double grade(double, double);

};

---

But that gave me "17|undefined reference to `Student_info::grade(double, double)'|" error, any advice? :P

You do have to eventually define the function somewhere, I would guess.

Edit: And since it's inside a struct, you can't just use the name, you have to indicate that you mean the function inside the struct. So you'd have to define it just like your error message says: Student_info::grade(double this, double that).

ok, thanks ^^