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

This is a discussion on Bjarne Stroustrup on the Evolution of Languages - Interview MSDN Magazine Apr 2008 within the A Brief History of Cprogramming.com forums, part of the Community Boards category; I kinda like the auto keyword for simplifying some types, especially iterators. But I am concerned, as Mario points out, ...

  1. #16
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,411
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  2. #17
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,403
    Quote Originally Posted by Elysia View Post
    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.
    Last edited by Mario F.; 05-02-2008 at 06:22 AM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  3. #18
    Cat without Hat CornedBee's Avatar
    Join Date
    Apr 2003
    Posts
    8,893
    Quote Originally Posted by Mario F. View Post
    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.
    All the buzzt!
    CornedBee

    "There is not now, nor has there ever been, nor will there ever be, any programming language in which it is the least bit difficult to write bad code."
    - Flon's Law

  4. #19
    C++まいる!Cをこわせ! Elysia's Avatar
    Join Date
    Oct 2007
    Posts
    22,411
    Quote Originally Posted by Mario F. View Post
    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.
    Quote Originally Posted by Adak View Post
    io.h certainly IS included in some modern compilers. It is no longer part of the standard for C, but it is nevertheless, included in the very latest Pelles C versions.
    Quote Originally Posted by Salem View Post
    You mean it's included as a crutch to help ancient programmers limp along without them having to relearn too much.

    Outside of your DOS world, your header file is meaningless.

  5. #20
    Banned
    Join Date
    Nov 2007
    Posts
    678
    Quote Originally Posted by Mario F. View Post
    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?

  6. #21
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,403
    Quote Originally Posted by Elysia View Post
    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.

    Quote 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
    Last edited by Mario F.; 05-02-2008 at 07:13 AM.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

  7. #22
    Registered User
    Join Date
    Oct 2001
    Posts
    2,129
    Code:
    for (vec::iterator i=vec.begin(); i!=vec.end(); ++i)
        std::cout << *i << '\n';
    Why not that? static members do it.

  8. #23
    Captain Crash brewbuck's Avatar
    Join Date
    Mar 2007
    Location
    Portland, OR
    Posts
    7,230
    Quote Originally Posted by Mario F. View Post
    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.

  9. #24
    (?<!re)tired Mario F.'s Avatar
    Join Date
    May 2006
    Location
    Portugal
    Posts
    7,403
    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.
    The programmer’s wife tells him: “Run to the store and pick up a loaf of bread. If they have eggs, get a dozen.”
    The programmer comes home with 12 loaves of bread.


    Originally Posted by brewbuck:
    Reimplementing a large system in another language to get a 25% performance boost is nonsense. It would be cheaper to just get a computer which is 25% faster.

Page 2 of 2 FirstFirst 12
Popular pages Recent additions subscribe to a feed

Similar Threads

  1. An Interview with Bjarne Stroustrup By Michael Miller
    By kermi3 in forum Article Discussions
    Replies: 9
    Last Post: 03-15-2005, 09:59 AM
  2. Interview with Bjarne Stroustrup "C++ a joke"
    By novacain in forum A Brief History of Cprogramming.com
    Replies: 4
    Last Post: 03-31-2003, 10:55 PM
  3. Exclusive Interview With Bjarne Stroustrup
    By Osama Lives in forum A Brief History of Cprogramming.com
    Replies: 7
    Last Post: 05-07-2002, 03:17 PM

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21