Bjarne Stroustrup on the Evolution of Languages - Interview MSDN Magazine Apr 2008

**Elysia** · 05-02-2008

I kinda like the auto keyword for simplifying some types, especially iterators. But I am concerned, as Mario points out, that it may leave the door open to bad things. IMHO, it should be limited in ways it could be used.
But I'm definitely glad it's there.

**Mario F.** · 05-02-2008

Originally Posted by Elysia

I kinda like the auto keyword for simplifying some types, especially iterators. But I am concerned, as Mario points out, that it may leave the door open to bad things. IMHO, it should be limited in ways it could be used.
But I'm definitely glad it's there.

I'm not sure of any way it could be limited. The use of auto is much better described as a means to deduce a type from the initializer in order to simplify generic programming (generic programming, the expression I was drawing a blank on my previous posts). Examples of auto that translate to built-in types are in my opinion not a good example of proper usage of auto.

I'm not sure if your edit of the wikipedia article was a joke, CornedBee. I'm wanting to believe not. However, what you are essentially doing is giving an example on how auto shouldn't be used; i.e. While essentially correct, the example fails however to provide auto with a proper context. And that is almost certainly more confusing to the reader. No one will suddenly not understand what auto is, if instead something like this is shown:

Code:

for (auto itr = vec.begin(); itr != vec.end(); ++it) {
    std::cout << *itr << std:endl;
}

Probably this is a non-issue as I'm wanting to believe textbooks will be less inclusive on the matter of auto usage. However, for the most part, bad habits are born of imitation and I completely fail to see why one should be so lenient when it comes to provide usage examples and so adamant when it comes to correct the code of others. Code, I may add, very often is the result of what was read and understood from said examples.

**CornedBee** · 05-02-2008

Originally Posted by Mario F.

I'm not sure if your edit of the wikipedia article was a joke, CornedBee. I'm wanting to believe not.

It was not. I don't particularly care about this article or whether it conveys good practice. I just wanted to correct something that was simply wrong, and I took the path of the least work for it.

**Elysia** · 05-02-2008

Originally Posted by Mario F.

I'm not sure of any way it could be limited. The use of auto is much better described as a means to deduce a type from the initializer in order to simplify generic programming (generic programming, the expression I was drawing a blank on my previous posts). Examples of auto that translate to built-in types are in my opinion not a good example of proper usage of auto.

Perhaps. That's just the thing, isn't it? It's dangerous because it might not be able to be limited.
But I would rather not have to type std::vector<mylongtype>::iterator for every iterator. That's where the auto keyword comes in handy, I think.

**~~manav~~** · 05-02-2008

Originally Posted by Mario F.

Code:

std::string foo(int x);
int main () {
    auto bar = foo(13);
}

I could not see this example, is it edited now, by some fellow board member?

**Mario F.** · 05-02-2008

Originally Posted by Elysia

Perhaps. That's just the thing, isn't it? It's dangerous because it might not be able to be limited.
But I would rather not have to type std::vector<mylongtype>::iterator for every iterator. That's where the auto keyword comes in handy, I think.

And you also will probably have decltype().

Code:

for (decltype(vec.begin()) itr = vec.begin(); itr != vec.end(); ++it) {
    std::cout << *itr << std:endl;
}

Combined with auto, this duo will make wonders. Saving keystrokes will be the least they can do.

Originally Posted by manav

I could not see this example, is it edited now, by some fellow board member?

It was edited, yes. But that was not the original one. A variable initialized from a constant w_char[] was the one

**robwhit** · 05-02-2008

Code:

for (vec::iterator i=vec.begin(); i!=vec.end(); ++i)
    std::cout << *i << '\n';

Why not that? static members do it.

**brewbuck** · 05-02-2008

Originally Posted by Mario F.

However, I believe auto is an accident waiting to happen. For one, you lose semantical expressiveness and you make the code logic harder to follow. auto almost feels like I'm wanting to program in a non typed system; i.e. "I don't know the type, I just know it's some form of X, I can't bothered checking the library documentation, or it is too long to type, so I go with auto. This will work."

It's not like a type error could occur, you're just relieved of having to express the exact type name (which is usually irrelevant anyway).

And many uses of "auto" can already be simulated.

Code:

void func1()
{
    auto f = boost::bind(... some crazy complex binder ...);

    // Do something repeatedly with f
}

Without auto you'd be reduced to figuring out the exact type of the complex bind expression. OR, you could add a level of indirection to allow the compiler's type deduction to do things for you:

Code:

void func2()
{
    with_f(boost::bind(...))
}

template <typename F>
void with_f(F func_p)
{
    // Do something repeatedly with func_p
    ...
    // Declare other instances
    F a, b, c;
}

So it becomes clear that the "hiddenness" of the actual type name is no different than how a type name is hidden by a template function. Again, you don't care what F is, you just want to be able to refer to that type easily.

**Mario F.** · 05-02-2008

As I said, it's not what auto can do for us, it's how it is being advertised that has very little to do with auto true purpose.

Thread: Bjarne Stroustrup on the Evolution of Languages - Interview MSDN Magazine Apr 2008

Thread Tools

Search Thread

Display

Similar Threads

An Interview with Bjarne Stroustrup By Michael Miller

Interview with Bjarne Stroustrup "C++ a joke"

Exclusive Interview With Bjarne Stroustrup