PDA

View Full Version : Bjarne Stroustrup on the Evolution of Languages - Interview MSDN Magazine Apr 2008



vart
05-01-2008, 12:52 AM
http://msdn.microsoft.com/en-us/magazine/cc500572.aspx
I have this link in my Microsoft subscription letter. Maybe it will be of some interest for others...

manav
05-01-2008, 07:24 AM
I liked the fact that he himself is unhappy about some things in C++ :)
This makes me feel better, if even the creator can't change some things, then, at least I should stop rambling about some tiny problems, that usually come by me, sometimes !

Waiting for C++0x although!

medievalelks
05-01-2008, 07:59 AM
Good interview. Loved the bit at the end about cell phones. I love how games, video, cameras, etc. are all being perfected by I still routinely get dropped calls, missed voice mails, etc. Flash over substance, which seems to be the norm anymore.

Mario F.
05-01-2008, 08:08 AM
It still pains me bjarne fully supports the auto keyword. Bah!

*defeated*

laserlight
05-01-2008, 08:26 AM
It still pains me bjarne fully supports the auto keyword. Bah!
What's wrong with the new use of auto?

Mario F.
05-01-2008, 09:09 AM
What's wrong with the new use of auto?

At the surface nothing:
- You get more expressiveness (syntactical);
- You save on keystrokes;
- You minimize (debatable) compile time errors.

Complex template base object declarations are made simpler, I foresee iterators being one of the favorite uses for auto. But also, as suggested on the article, "hard to acquire" types can be easily declared.

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."

But the above argument has it flaws, I concede. I only recently started giving template based programming a hard look. And already I'm faced with annoying type declarations that I wished (truly) had been made simpler. As such, I can only imagine what the above paragraph may look like to a seasoned template based programmer.

My major beef with it is instead the fact the new use of auto is an accident waiting to happen also because of the fact it opens yet another door for bad code. The fact it is openly discussed as a tool for the beginner programmer, by the very same people who are institutionalizing it, only makes this worse. You know what I mean, but for illustration purposes, the following is not something you, I, or anyone else would like to see in the years to come on the C++ board:


std::string foo(int x);

int main () {
auto bar = foo(13);
}

And yet, I foresee this is exactly what is going to happen.

EDIT: Note that the loss of semantical value is no minor issue. The amount of inconvinient and confusing bugs that might arise from auto foo = "This is a string"; when written by a programming language beginner is overwhelming. Is auto in this instance helping him, or on the other hand making his life harder for not even making it clear this variable is a const char*? Can we say type obfuscation? I chose this example because, believe it or not, is what you can see here: http://en.wikipedia.org/wiki/C%2B%2B0x

EDIT 2: Just a minor correction; one doesn't need to be a seasoned "template based programmer" (allow me that expression yet again) to experience the need for auto, as anyone who has, for instance, constructed a complex STL container can attest.

vart
05-01-2008, 09:16 AM
I've found it funny to see him discuss the vector<Apple> and vector<Fruit> after seeing same discussion on this forum...

CornedBee
05-01-2008, 12:51 PM
Thanks, vart, that was a great article. And I also greatly enjoyed the linked paper about multiple dispatch.


Is auto in this instance helping him, or on the other hand making his life harder for not even making it clear this variable is a const char*?
The worst part is that it isn't. The type of a string literal is const char[N], where N is the number of chars in the string literal, including the terminator. The type of a wide string literal is const wchar_t[N], same rule.
What does this mean? It means this:

const char *s1 = "foo";
const char *s2 = "foo";
assert(s1 == s2); // Probably true. Compilers generally fold string literals.

auto a1 = "bar";
auto a2 = "bar";
assert(a1 == a2); // Definitely false. On a side note, you've just wasted 8 stack bytes for nothing.

I need to go edit that Wikipedia article.

vart
05-01-2008, 12:57 PM
Thanks, vart
It makes me happy to see that people find this link useful... So you're wellcome. :)

Mario F.
05-01-2008, 01:06 PM
Quiet right, CornedBee. And yet another reason to be carefull around auto.

But for all purposes the example shouldn't even be there, in my opinion, because it suggests exactly what I'm against with; an oversimplification of its true usefulness that will introduce a new crowd of bad code and hard to track bugs. It pains me especially that it is advertised as being introduced to help the life of newcomers to the language.

Personally I feel auto is an advanced feature that is (un)fortunately extremely easy to use. This contradiction only means use and abuse of auto will probably become all too prevalent.

CornedBee
05-01-2008, 01:28 PM
Probably. But as one of those seasoned template programmers you refer to, I'm way too happy about auto to care about its abuse by newbies.

VirtualAce
05-01-2008, 07:43 PM
Good read. I'm concerned with auto but I guess I'll get used to its uses and abuses. Bjarne seems to be a fundamentals type fella which is nice because he realizes that new bells and whistles or the latest greatest thing does not always make a good language. Overall I like the new features that were mentioned and look forward to learning and working with the new standard (sometime in the next few years?). Since it was 2003 to 2005 before most compilers caught up to the most recent standard I doubt I will see a compiler up to the new standard for quite some time.

CornedBee
05-02-2008, 03:07 AM
Overall I like the new features that were mentioned and look forward to learning and working with the new standard (sometime in the next few years?).

Depends on how much of them you want. GCC will develop support gradually. Vararg templates and r-value references are there now, in GCC 4.3.

manav
05-02-2008, 03:13 AM
An offtopic question:


All the buzzt!
What that means?

CornedBee
05-02-2008, 03:30 AM
It means, "All the best!", that is, a well-wishing, with altered spelling to make a pun on my username. I've been using it as long as the username exists.

Elysia
05-02-2008, 05:39 AM
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, 06:14 AM
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:


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, 06:17 AM
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, 06:54 AM
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, 07:01 AM
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, 07:08 AM
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().


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.



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, 11:56 AM
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, 12:28 PM
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.



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:



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, 01:28 PM
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.