Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Interview With Herb Sutter 166

Posted by Hemos from the working-with-the-crowd dept.
Anonymous Coward writes "Herb Sutter, a C++ luminary, recently joined Microsoft's Developer Platform and Evangelism Division, where he acts as a liaison between Microsoft and the C++ developer community. In this interview he speaks about his new job, the role of C++ in the .NET framework, and the current state of C++."
This discussion has been archived. No new comments can be posted.

Interview With Herb Sutter More

Interview With Herb Sutter

Comments Filter:
  • No mention of IA64, or X86-64 =( I'm really curious to know if compilers will be in place to exploit these platforms, ESPECIALLY IA64.

    -Berj

    (hyperthreading, too?)
  • My job definitely includes giving direct input into the feature set for future releases of Visual C++, to make sure that the product has what the C++ community needs. Note that by "the C++ community," I mean everyone who works for or with C++, on all compilers and platforms--that includes in-the-trenches systems and application developers
    So... when are we going to see the linux kernel compiled on VC++?
    • So... when are we going to see the linux kernel compiled on VC++?

      Oh, I guess that'll happen soon after kernel hackers throw away their free GCC and sign up for Visual Studio.NET :0)

    • Re:VC++ will provide what the community needs... (Score:4, Funny)

      by x0n ( 120596 ) on Thursday April 18, 2002 @05:50AM (#3364198) Homepage Journal
      Nope, it definitely doesn't work.

      c:\linux\src\kernel>nmake
      Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9466 for 80x86
      Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.

      kernel.c
      kernel.c(3) : error : Invalid token : expecting "(C)", found "GPL".

      compile aborted.
      c:\linux\src\kernel>

      bugger.

    • So... when are we going to see the linux kernel compiled on VC++?

      Considering the linux kernel uses non standardised GCC extensions...i doubt it.
      • the inline assembly would have to be swapped over as well

        VC uses a more straightforward inline asm, but the C/asm code isn't optimized (and VC scans the asm for registers affected and explicitly reloads them when you're done), and accessing variables passed in registers doesn't work.

        __asm
        {
        xchg eax,myvar
        }
      • Considering the linux kernel uses non standardised GCC extensions...i doubt it.

        At the MS PDC ~3-4 years ago, the VC development team was talking about giving "providers" the ability to integrate into the VC compiler. This would have given VC++ the same extensibility as C# (where you can define your own custom attributes, and write code that generates the IL for that attribute.)

        My memory of this is, admitedly, hazy, but as I recall, this caused quite a stir (both for and against the idea.) Why bring it up? Well... MS has obviously at least thought about this over the past few years (both with C# and C++). If they really wanted to snarf market share from other compilers - including gcc - then providing the ability for end users to add arbitrary language extensions to VC++ (and minimize porting time) would be a pretty significant feature.

        And, finally... if they did that, then you'd at least get around the problem non-standard gcc extensions in the kernel code. I'm sure many other problems would manifest themselves, though.

  • MS made a smart move hiring one of the most famous C++ guru, and moderator of "Guru of the week" (GotW, here [www.gotw.ca]).
    (The Exceptional C++ books are selections from the GoW series).
    I really think that this will enhance the MS' C++ offer quality, and including the GotW thinkabout in its future design is a kind of "bazaar" approach!... Funny!
    • Herb is the creator and sole mind behind the "Guru of the Week" series, not just one of a panel.

      He's also a moderator of comp.lang.c++.moderated, and recently has also joined the comp.std.c++ moderation panel, on which I also sit.

      His "Exceptional C++" and "More Exceptional C++" books are more than just printed copies of the GotW material, which is freely available online.
      Exceptional C++ in particular is a fine book, and all truly serious C++ programmers should read it.

      • because some job interview questions I sat recently were taken directly from the book/site :-)

        Argh, the difference between implicit and explicit copy construction and direct construction :-/

  • ANSI C++ compliance (Score:3, Insightful)

    by YeeHaW_Jelte ( 451855 ) on Thursday April 18, 2002 @05:56AM (#3364213) Homepage
    I find it pretty strange that the same guy who is secretary in the standards committe now works for a company that market a definetly non-standard compatible C++ developement suite.
    I've worked with Visual Studio in the past, and was always irritated by the microsoft-specific stuff and especially the automatically generated code, which is inserted at compilation time and thus can't be read or seen. I don't like using mystery code in my appilications.
    • My take is that MS is getting serious about standards compliance and quality in a number of areas. Hiring Herb is one of those high-profile actions that sends a message to the troops.
      • Get it right people; it's an ISO standard [dkuug.dk], not an ANSI standard. If nothing else this is a useful interview answer!

        As for Herb Sutter - I believe him when he says he's to going to compromise his standards work. I don't believe MS, but Herb Sutter's books have earned him my respect.

        • Get it right: it's both an ISO/IEC and an ANSI/ISO/IEC standard, and may well have been adopted by other national bodies as well.

          The name on my copy is ISO/IEC 14882:1998, but I believe that in the US it's ANSI/ISO/IEC 14882:1998.

          Cooperation between the ANSI C++ panel and the rest of the ISO C++ community is excellent, fortunately.

          You're not wrong about Mr Sutter being trustworthy though, in my experience.
        • Well, the ISO standard and ANSI standard are identical except the ANSI standard is like $13 whereas the ISO standard is like $250.

          So I have and follow the ANSI standard. Much nicer IMHO.
          • Well, the ISO standard and ANSI standard are identical except the ANSI standard is like $13 whereas the ISO standard is like $250.

            Wrong way around, I think. ISO's electronic version is the cheap one; the only version available from ANSI, as far as I know, is the one that costs ~10x as much. Fortunately, there seem to be moves afoot for several standards agencies to make their material available for a sensible price, so hopefully this whole issue is moot.

    • Re:ANSI C++ compliance (Score:5, Interesting)

      by jdennett ( 157516 ) on Thursday April 18, 2002 @06:12AM (#3364234)
      You shouldn't find it so strange that a "guy which is secretary in the standards committee" works for a company which has recently declared its intention to change its ways and produce a fully conforming C++ compiler. Their internal build supports partial specialization now, and in fact most stuff other than export. It's finally getting to be about as compliant as compilers from other companies.

      Did you know that Microsoft has relatively recently rejoined the C++ standards process, and even hosted the last ISO/ANSI C++ meeting? That's quite a turnaround.

      After a little initial concern, I'm pleased to have someone with Herb's integrity working inside Microsoft. Over recent months (indeed, even before Herb joined MS) we've finally seen a willingness from Microsoft to discuss the flaws of VC++, and what they plan to do about it.

      We can't assume that MS will play fair forever in this area, but we shouldn't assume that they'll double-cross the community. Much though the quality (or lack thereof) in VC++ annoyed me, I'm willing to give them the benefit of what little doubt is left. VC++7.0 is a step forward, and the next release is make-or-break in terms of the credibility of MS's C++ development team. If it's up with the leading group they'll have won the (possibly grudging) respect of large parts of the C++ community. If not, they might not get another chance so easily again.

      • Did you know that Microsoft has relatively recently rejoined the C++ standards process, and even hosted the last ISO/ANSI C++ meeting? That's quite a turnaround.

        Indeed it is. However, coming from a company with a vast history of turnarounds in their past -- many of which have proven to be anything but in the interests of The Rest Of Us when faced with the test of time -- I think it's only fair that the rest of us be a little sceptical. Hiring people like Stan Lippman and Herb Sutter is not, in itself, going to turn around their whole program. I'm sure Herb and Stan have laudable intentions, and I wish them the best of luck at changing from within, but it'll be a while before I bet my career on it. When you can use C++ -- all of C++ -- with .NET and all the new toys, get back to me...

        Much though the quality (or lack thereof) in VC++ annoyed me, I'm willing to give them the benefit of what little doubt is left.

        You're more generous than me, I'm afraid. Y'see, I remember a few months back, when VC++.NET was going to be the one with all the improved standards compliance, and y'know what? It's almost as bad as VC++ 6. I've heard the song before, and it's getting a bit tired now.

    • Re:ANSI C++ compliance (Score:5, Informative)

      by PhilHibbs ( 4537 ) <snarks@gmail.com> on Thursday April 18, 2002 @07:08AM (#3364329) Journal
      I was at the ACCU Conference [accuconference.co.uk] that Herb mentions in his speech, and at the end of the first day there was a special last-minute session scheduled with Herb and Stan, called "Revelation on the road to redmond". It was quite interesting, and when Herb introduced the man who had implemented partial specialisation in Visual C++, there was a tremendous round of applause! And this was not a conference full of Microsoft flunkies, far from it.

      The upshot is, MS have an internal build of MSVC that will compile Loki [awl.com]. It should be available around the end of this year.

    • no compiler on any platform will compile all of the boost and loki libraries, not even gcc on linux.

      But many compiler vendors are seeking to increase their compliance. Hey, it's not a toy language :-)

      • no compiler on any platform will compile all of the boost and loki libraries, not even gcc on linux.

        ok, what is this Loki? I read "Loki" in the interview, and instantly was extremely confused. and it looks like it has 2 mentions on /., but no explanation.

        am I missing something obvious?

        • It's the library that comes with this book

          http://cseng.aw.com/book/0,3828,0201704315,00.ht ml

          It uses enough of the corners of the language that most compilers have problems compiling it.

          The book itself is very very good: all experienced C++ developers ought to read it.
    • That's interesting. Could you give an example of this misterious "automatically generated code"? But wait... you say it can't be read or seen... Hmm...
  • Fair enough, but given that Herb Sutter is an authority and "evangelist" on C++ in general - how can he reconcile his new position with the new licenses MS are attaching to their development tools which seem to prohibit any GPL'd application (e.g. GCC) linking against their .NET library?

  • yeah right (Score:2, Funny)

    by Foss ( 248146 )
    "The need for a flexible programming language that can handle everything from high-level abstraction to bit-twiddling, all unified within the same language, isn't going away anytime soon."

    I think he forgot to add "because we have waaaay too many bugs to fix" at the end of that sentence. :)

  • Might just be me (Score:2, Insightful)

    by nervlord1 ( 529523 )
    It might just be me, but to me, it seems.. well.. wrong, for someone recommending the C++ standard to be part of ANY commercial company who's job it is to write C++ code.
    Ok that sound's a bit silly on the surface but think about it: they might recommend specs that make thing's easier for them but harder for other's, or basically have a hidden agenda.
    this is ESPECIALLY true for a company like Microsoft who.. well, Lets not kid ourselves Microsoft Apologists: rarely follow standards, and tend to "embrace and extend" the standards they do choose to follow. it just seems like a reciepe for a little underhanded.

    But maybe i'm missing something, anyone want to make a constructive critism?

    • Re:Might just be me (Score:2, Informative)

      by jdennett ( 157516 )
      Sure, I'll take a crack at constructive criticism.

      Most of those in the C++ standards group are employed by companies with an interest in how the standard works out. By the time it comes to voting on issues for inclusion in the standard, however, each country gets just one vote, so no company can impose its will; standardisation works by building concensus.

      So, sure, Microsoft will be pushing for things which suit them. And likewise for Sun, Oracle, Comeau Computing, and any number of other companies. The ISO standards process isn't so easy to buy.

    • Re:Might just be me (Score:5, Insightful)

      by Harri ( 100020 ) on Thursday April 18, 2002 @06:29AM (#3364269) Homepage
      it seems.. well.. wrong, for someone recommending the C++ standard to be part of ANY commercial company who's job it is to write C++ code.

      The C++ language is _for_ people who write C++ code. Are you seriously suggesting that the majority of the users of a language should be banned from participating in the standards process, because they get money for doing their job?

      I am hoping you really meant that the people who write the compilers should not be allowed input: but even this is impractical, since nobody wants a standard full of features which turn out in practice to be unimplementable.

      • yer, as i said after i wrote that it sounded a bit silly, and i suppose it is.
        but still, i stand by my no-compiler-writers people on there
        (perhaps have one person whos entire job it is is to say "no, a compiler can't do that" is a good fix?)
        • Who, then, do you think would pay for the standardisation process? In our capitalist world, it just about has to be funded by those who stand to gain from it.
    • it seems.. well.. wrong, for someone recommending the C++ standard to be part of ANY commercial company who's job it is to write C++ code.

      I can't see that this is a problem, since the standard body consists of many people. It would be a problem if a majority of the standard body belonged to the same company and could force decisions, but I don't think that's the case here.

      I don't think the fact that Kerningham & Ritchie worked for AT&T when C was born has been a problem and the same goes for Java with the ties to Sun (through Gosling, Joy et al).

      I would think that it's a good thing that the people recommending standards work with the language.

      Just my .2$

    • Re:Might just be me (Score:2, Informative)

      by Cuthalion ( 65550 )
      You're just plain wrong. Even assuming that you mean the people making compilers, not the people using C++. First of all, if you exclude the people who implement your standard from the decision process, if it turns out to be a nightmare to implement or whatever, then they all just ignore the standard. Secondly, they may have some insights onto what constitutes well-definedness for various standards issues (when you're looking at the problem from the other end, you see different things). Thirdly, the people making the compilers get a lot of feature requests from their users. They can provide a lot of useful information to the consortium. Fourth, any embrace and extend can be avoided by putting the useful features that Microsoft wishes to add to lure people to their compiler into the actual standard. If the standard does what people want, there'll be no reason to use nonstandard extensions. Also note that it's not Microsoft that added a whole nother pair of operators to C++, but GCC [gnu.org]. (try fixing _THAT_ with a preprocessor macro)

      I agree with the basic sentiment that any standards body should not be dominated by a single entity, be it Netscape, Microsoft, or Sun. Microsoft should have a say. So should the GCC team. So should Borland. If they can all agree on a standard that they each want to implement, the standard will be implemented faster and with stronger adherence.
  • I certainly hope that C# will be the destination of choice for a lot of today's Visual Basic application developers.
    Do you think this is what MS had in mind when they developed the Common Language Runtime?

    Hmmmm... Let's develop a runtime and a language that fits perfectly on top of it. Then, let's claim that any language can compile to this same runtime so we have a cross-language platform! Nevermind that they will have to forgo any features that aren't supported by the runtime or at least will have to hack around them. Eventually everyone will move to our perfect single language!

    Even VB.NET falls into this category. It doesn't quite match the CLR as perfectly as C# does. I wonder how long until they try something similar C++... oh wait...
  • There really is a division within Microsoft with Evangelism in its name.

    Look here [microsoft.com] for its press release.

  • So how long until I they start moving onto the other untainted languages? perl.NET? assembler.NET? english.NET? This is really going too far, really.
  • Penny Arcade reveals eternal thruths. [penny-arcade.com]

    Way to go, Herb. If I could sell out for the kinda cash you must be raking in (suggestions - build giant bin, go swimming) I'd do it in a second. 99% of the personal criticsm is (already apparent) personal jealousy. This isn't a sinister plot to somehow subvert ANSI C++ to MS' evil ends. It's a good career move on his part.

    from MS web site:
    "Herb's involvement in the C++ community will allow Microsoft to better work with developers building great applications in C++ and ultimately help drive the direction of our Visual C++ .NET tool," said Eric Rudder, senior vice president of the Developer and Platform Evangelism Division at Microsoft.

    i.e. he's a PR figurehead. MS seems to think people will care. Jokes on them. This is too bad, b/c some people are going to be forced to work on C++@.NET, and Herb writes good; if they put him in documentation I'd actually be pleased.
    • a PR figurehead to whom? it seems like his job is to talk to the C++ developers and ask them what they need. he then figures out what is actually a good request for features and what is just wishful thinking and tries to get MS to deliver. In also doing that he's going to be getting VC++ standards compliant! so as i see it the only person that has to listen to him is the MS employees. he's more an C++ evangelist targeting MS than anyone else.

      still, if he was a figurehead, he's pretty credible and i would listen to him.

      it'll be great if he delivers on his promises. if VC++ becomes standards compliant even somewhat MS can't take that away. they will be forced to always support it for a very long time.

    • Nobody gets "forced" to work in any language or on any platform. If you don't like the language, don't program in it.

      "But Windows is the standard at my job, I'm forced to write one a windows platform and use .NET"

      Get a different job then dork, if you can't find a job that will make you happy. Change careers, you can always program on your Linux/Unix/OSX box at home as a hobby if you really love programming.

      Why does every programmer think that they are so important that the world must cater to them?
      "Microsoft must go away because they are evil, they should change their languages because I don't like them"

      Go play with your GCC compiler on your Linux box then. No one is "forced" to use any technology, you don't get put in jail or killed if you don't use Microsoft products. If you don't like what Microsoft does with VC++, don't use it. If you have to at your job and that doesn't make you happy, find another job. If you can't find a job programming on the Linux platform then either suck up and use MS products to make yourself money or find another career and make Linux programming your hobby.

      • Get a different job then dork

        Here, here! No wonder everyone thinks programmers are whiny little geeks. Can you imagine? An entire community has sprung up around such esoteric issues as C++ standards compliance.

        Hey, nerds: cut out the whining. It's making it harder for me to feed my kids. And get laid, so I can make more kids. Please mod parent up.

  • One Target? (Score:2, Insightful)

    by Komarosu ( 538875 )
    Maybe now with him joining the MS team he can maybe push for more compatabilty between the compiler sets. I know theres alot of G++ and VC++ extensions that people would like to see in both sets. Maybe one day this may make porting apps specialised for one compiler to another easier. Just my 2 cents :)

  • C++ is *not* a good cross-platform language (Score:5, Interesting)

    by evbergen ( 31483 ) on Thursday April 18, 2002 @07:22AM (#3364345) Homepage
    From the article:

    "Q: Standard C++ doesn't support modern programming concepts such as multithreading, distributed computing, components, and persistence. The result is a plethora of proprietary libraries and platform-dependent frameworks that make cross-platform development in C++ nearly impossible. Is Standard C++ still relevant? Which features would you like to see added to the language in the future?

    A: Again, these questions arise from an overstated premise. Thousands of companies are routinely writing and shipping cross-platform software written in C++. Claiming that it's "nearly impossible" doesn't change the fact that we've been doing it for years. The one big area I can think of where portability is genuinely difficult is one the question didn't mention -- GUIs. GUI portability is a problem in all languages, unless you give up writing rich GUIs and write only simple and limited ones. Interestingly, despite some languages' attempts to "standardize" cross-platform GUI libraries, the best and most successful solution for cross-platform GUIs is not a code library at all, but HTML."

    Well, that proves the point, doesn't it -- HTML + JavaScript is apparently a "language" that people find better suited to define standard, cross-platform GUIs in than C++!

    The reason may very well be that C++ GUIs tend to they tie in to too many features of the underlying platform to be portable. If you /do/ want portabilty, you're on your own: you'll have to invent your own abstraction layer in order to achieve it. Obviously, some succeed better than others in that respect, and as he says, it doesn't keep people from trying.

    It seems that any language that uses a runtime (for HTML+JavaScript, that's the browser; for Java, that's the JVM; for Scheme, that's Emacs :P), is much better for offering cross-platform services and libraries, simply because the burden does not lie upon each and every individual library developer anymore to create a platform abstraction layer. That only has to be done once, by the runtime.

    Really, this is not exactly a mind-shattering concept (USCD-Pascal on p-Code anyone?)

    Not that the current state of affairs with HTML+Javascript or Java gives much reason to feel content, but I *definitely* still see the point of having a runtime that offers a standard, special-purpose language to define GUIs.

    However, I think the API for such a runtime should be viewed more as a data protocol than as a set of language-specific functions to call.

    And *that* really applies to more than just GUIs: there really is a need for portable APIs that are not tied to any language these days, if you look at those complex, horrible 800lb monstrosities like Corba, COM or .NET. But I think the reason why these are so big and ugly is because they want to make it possible to put the interface at every conceivable place. Of course the interfaces will be complex if you do that.

    Why not focus on *data-centric* APIs instead, that are intended to be put where the interface is as thin as possible, and build them as efficient and robust as an internet protocol should be?

    If you're thinking of XML now, that may be close, but I really can't see how XML is the most efficient and easy-to-implement way of transmitting trees of attribute/value pairs. It's too difficult and slow to parse, to start using it as a transport for local subsystem calls as well, and contains too much redundancy, such as named close tags.

    What the Internet and your local system needs is a good OSI layer 5. Is HTTP + XML really the best thing we can come up with?
    • Personally, I found it amazing that he completely blew off a perfectly legitimate question like this.

      I work for a company that ships a dbms on 12+ different platforms. We've had to license a gui toolkit and write our own threading library, nevermind the lack of binary interface standards.

      The c++ committee needs to get their heads out of the clouds and actually talk to developers rather than listen to others in their ivory towers.

      People criticize java for being too closed, but at least sun listens and has process in place to insure their users are heard.
      • Personally, I found it amazing that he completely blew off a perfectly legitimate question like this.

        Hello, he linked to an article of his describing how a great number of these issues are slated to be sorted out in the next standard! How is that "blowing it off"?

        And, by the by, the C++ committee isn't a bunch of lawyers and accountants or something: it's made up of C++ developers, compiler writers and so forth. If you want to get your point across, go to a committee meeting! There's little use in complaining that the people who could actually be bothered to go aren't following your agenda.

        • Damn, I missed that link. my bad.

          However, I did subscribe to the mail list, and I di follow it loosely (note the tense). As for the makeup of the comittee, it's not *really* made up of developers. Compiler writers yes, typical developers no. (No one ever said it consisted of lawyers or accountants).

          Compiler writers obviously have a different agenda than developers.
          Where as a compiler writer would prefer those features that are easier to implements, I would prefer those that are easier to use.
          • Have you ever followed the discussion on comp.lang.c++.moderated or comp.std.c++? You'd know you are wrong in implying the comittee is biased towards "easy solutions", if you did. Most of these people spend lots of time writing articles on how to use the language most effectively.
    • Excellent point that the API should be a data protocol or otherwise simplified.

      GUI api design today seems to me to be equivalent to the interfaces to file systems in the 1960's. At that time you had to know exactly what device and structure of the file you were going to use, you had to use a completely different set of calls for each file, and "pip" (the equivalent of "cp") was far larger than any other application on the system. In modern GUI interfaces you have windows, menus, buttons, canvases, etc, and printers, all with vastly different interfaces (MicroSoft's GDI is not quite a solution although I certainly admit it is better than the situation on Unix), and COM and Corba, etc, are the equivalent of PIP and enormously complicated.

      In 1970 the Multics/Unix people came up with the open/read/write/seek interface to files. I'm sure then there was huge gnashing of teeth and complaints that people would write all kinds of inefficient databases and there would be "inconsistent interfaces" that would "confuse users" and all the other attacks that are levied against any attempt to simplify the GUI today. Well it turns out they were wrong, the simple interface works and resulted in more powerful databases than anybody ever imagined, and that interface designed in 1970 can be used today on huge arrays of networked computers and on disks the size of which was unimaginable then.

      We need the same thing in GUI today. I don't know if there is much hope as it requires a powerful force to implement it. MicroSoft could, but ActiveX is the exact opposite, it is enormously complex and basically requires all of Windows to be implemented (there would be little complaint if in fact a slow emulator like Mesa could be written for ActiveX, but the design makes it impossible). Everything else I see is an attempt to make "toolkits" be part of the OS (ie Berlin and Qt Embedded and Atheos) and I think is going to make things worse. I don't know if it is possible for a solution to appear today.

    • Well, that proves the point, doesn't it -- HTML + JavaScript is apparently a "language" that people find better suited to define standard, cross-platform GUIs in than C++!

      HTML + JavaScript is a better cross-platform interface than just about any other currently in existence. That's why it's so popular as a combination.

      OTOH, I'd love to see you write a full-blown word processor or a 3D FPS game in HTML and JavaScript.

      • > OTOH, I'd love to see you write a full-blown word processor or a 3D FPS game in HTML and JavaScript.

        Exactly. That's why we need something that's much more lightweight, and that's why I said technologies such as XML-RPC are not going to solve the API-as-a-protocol problem.

        Something that's a well-balanced rebirth of the X windows protocol, DPS or Apple's Display PDF and HTML + JavaScript combined, that is expressive enough to define much of a GUI in, and at the same time lightweight enough to allow things like games to work.

        Oh well, you've got to have dreams, don't you.
    • It seems that any language that uses a runtime (for HTML+JavaScript, that's the browser; for Java, that's the JVM; for Scheme, that's Emacs :P), is much better for offering cross-platform services and libraries, simply because the burden does not lie upon each and every individual library developer anymore to create a platform abstraction layer. That only has to be done once, by the runtime.

      Agreed that a runtime can be made platform-specific, but isn't this just another abstraction layer? What is the difference between the runtime and an abstraction layer for GUIs in C++, in terms of cross-platform GUIs?

      And *that* really applies to more than just GUIs: there really is a need for portable APIs that are not tied to any language these days, if you look at those complex, horrible 800lb monstrosities like Corba, COM or .NET. But I think the reason why these are so big and ugly is because they want to make it possible to put the interface at every conceivable place. Of course the interfaces will be complex if you do that.

      The strange part is that you've mentioned three of the most famous portable APIs (or, more accurately, API protocols) that are not tied to any language - as examples of why we need portable APIs that are not tied to any language. And they are, as you said, 800lb gorillas. And can you elaborate on "put the interface at every conceivable place"? All of these API protocols have a well-defined interface layer.

      Why not focus on *data-centric* APIs instead, that are intended to be put where the interface is as thin as possible, and build them as efficient and robust as an internet protocol should be?

      Can you elaborate on this idea? I like it, but I'm not sure I'm completely following your "thin as possible" line of thinking (what does that mean?) And why should it be like an internet protocol?

  • reguardless (Score:2, Insightful)

    by f00zbll ( 526151 )
    No matter what people think of him going to MS, the man knows his C++. Merit is what counts people, not where you sit at work, or the name attached to your business card. The only thing worth keeping is ones integrity and work ethic. Companies, languages and platforms come and go, so don't get too attached to the latest fad.
  • His webpage [www.gotw.ca] is Frontpage generated.
  • Regarding namespaces

    It just creates useless typing overhead. After all, there's nothing wrong with the liberal use of using-directives when there aren't any name ambiguities, and why tell people to always manually resolve names even when there is no name collision to resolve?

    Not to start a flamewar here, Herb, but this idea seems to help in a similar way a decent variable naming convention helps. Additional information, embedded in the code, (with the resulting maintenance hassles) has the potential to save a lot of time during maintenance and when you have a new hire.

    The reply might be that such meta-information belongs in a design document. Fair enough, yet you've merely re-located a requirement, not obviated it.

    I guess with an infinite budget we could just hire an army of gurus who sneeze, emitting code that compiles on any platform with nary a warning... :)

    • Re:What about the learning curve? (Score:1, Informative)

      by Anonymous Coward
      Read the interview. He's talking about coding guidelines which prohibit using directives and/or declarations everywhere: e.g. a using std; placed inside a cpp file or even better inside a function definition, where it can't possibly contaminate other compilation units.

      OTOH, anyone putting a using directive (especially at global scope) in a header file deserves to be shot, of course.

      Herb deprecating the use of namespaces might make a good Twilight Zone++ episode... :-)
  • That's the data it's my job to distill -- to separate patterns from noise, well-thought-out requests from blue-ski wish lists

    Blue skis? Man, I could really go a pair of those. Of course, looks like I won't be getting any from Microsoft... :)

  • Developers [simplenet.com] Developers [simplenet.com] Developers [simplenet.com]
  • I think now you will begin to see a better VC++, on the limit they will open it and converge to ANSI and ISO standards.
  • ...What the deal is with C++. It's a terrible language with NO pre-thought design (Stroustroup has said in interviews that he doesn't think it's necessary to design a language before writing it) that is so badly broken that nobody has EVER made a fully compliant compiler (or, indeed, is even CAPABLE of making a fully complaint compiler). Herb Sutter says that you should go out and learn lots of languages if you want to be a better (C++) programmer, but the only thing that other languages taught me was how BAD C++ really is. I'm desperately hoping for C# to take over. Everything I've seen makes it a fair step up on C++. Java is a fine language, if you use it properly, and Squeak (http://www.squeak.org) Smalltalk is fun, simple programming. Objective-C is great for people that want to program in an object oriented, C based language, and there are legions of other languages that get barely used, even though they're super good.

    I program in C++, but I don't think I'll ever like it. The language is too big, too complicated, and gives bad programmers too many ways to blow their feet clean off. I believe in the original C language philosophy. Small, simple, fast, powerful.
    • ...What the deal is with C++. It's a terrible language with NO pre-thought design

      Then do something about it [sf.net]! This 55000 lines project has received exactly two (2) outside contributions (to the makefiles :-) in its two years of existence as an open source project. And yet everybody keeps complaining how C++ is bad! I'm keeping it in the >90% percentile at SourceForge, but all by myself. Where is the community when you need it?
    • Exactly. The reason why C++ sucks so badly is precisely because it is "a flexible programming language that can handle everything from high-level abstraction to bit-twiddling, all unified within the same language".

      Preaching on in the software-development-is-an-evolution style: life itself teaches us that the systems that stand the test of time are usually composed of clearly separated simple components or layers, each fit for its own set of tasks. An overly complex intermingled system has lesser chances to change in order to match new challenges, where a layered/componentized system simply tosses aside parts that became unusable and picks up new, better ones. Or uses both kinds if there's still a need.

      Fortunately, we have good tools that do each his own thing well and delimit responsibilities nicely. Whenever you need low-level twiddling, write functions in C, hooked up to your high-level application platform. Whenever you want to avoid writing boilerplate code, use an automated generator, e.g. an IDL compiler or a wizard from your favourite IDE, then fill in the blanks -- or edit it down to tiniest bits, if you so desire. C++ borgs all this into an incomprehensible heap of techniques that conceal stuff from the programmer's eye, and no compiler vendor has ever implemented these in clean and uniform manner. If you want
      clear implementation independance, portability or compactness, you have to restrict the used feature set and jump through hoops nearly as much as you have to do with C. Java is much much better at this, because it doesn't go into stuff where C reigns.

      And no, don't tell me about how templates are good. I'd better learn how to reuse code with reasonable type abstraction and thus improve locality than let identical template instantiations infest my libraries.
      • Preaching on in the software-development-is-an-evolution style: life itself teaches us that the systems that stand the test of time are usually composed of clearly separated simple components or layers, each fit for its own set of tasks.

        So, are you claiming that it's not possible to write good, modular code in C++, or that C++ has not stood the test of time? If the former, then how come it's the language of choice for so much large-scale development? If the latter, well, get back to me if Java survives another twenty years without a major library overhaul, or C# survives twenty years at all.

        And no, don't tell me about how templates are good. I'd better learn how to reuse code with reasonable type abstraction and thus improve locality than let identical template instantiations infest my libraries.

        Your prejudice and/or ignorance are showing. The very point of templates is that they allow you to separate concerns. This is true from the simple generic containers and algorithms found in the C++ library through to the state-of-the-art research into expression templates, policy classes, etc.

    • It's a terrible language with NO pre-thought design...

      Interesting, then, that its history is so well-documented, and Stroustrup himself has written a whole book on how the language was designed, the rationale behind each feature that was, or was not, provided, and other historical reasoning behind decisions that were made. Where's the Java or C# equivalent?

      ...that is so badly broken that nobody has EVER made a fully compliant compiler (or, indeed, is even CAPABLE of making a fully complaint compiler...

      Well, except for the currently-under-test Comeau compiler, which provides just about everything there is, and the internal code at MS, which is rumoured to support pretty much everything except export, anyway.

      I'm desperately hoping for C# to take over. Everything I've seen makes it a fair step up on C++.

      Y'know what? I really hope you're wrong. But unlike you, I'm going to justify my position.

      Firstly, I work at a software development house, and on a MLOC C++ project. Our clients just hired a new whizzkid just like you. They provided all the latest tools, and he's come up with this really cool interface using C# and .NET. The only slight problem is that, unlike many other languages, he can't figure out how to use the 500,000 lines of rigorously tested mathematics we've accumulated over the past decade, so his code is utterly useless. Had he written in any number of other languages that were designed to communicate freely rather than locking you into a pet framework with much hype but little real support, he wouldn't just have cost them thousands of pounds for a cute but useless prototype. So, that's one thing where C# has a long way to go to catch C++.

      There are many more. The obvious and boring example is templates and the standard library. Then there are all the portability issues, but I suppose they don't count because .NET and the CLR are portable and support many platforms, languages, days of the week, etc. There's the teensy-weensy little issue of performance, which is pretty much untested in C# and .NET as yet. Don't you think the Java developers might have learned a trick or two in the past few years? There's the insistence on everything being an object, single inheritance and a common root, all of which are as flawed as they have ever been. And in return we have what? A garbage collector? They could at least have learned from Java's mistakes and provided a decent mechanism for managing other resources -- which C++ has had for years -- but they seem to have forgotten that people also need to close files, release locks, share databases and such. I could go on, but what's the point? You're obviously massively prejudiced and unwilling to make the effort to get anything worthwhile out of C++, so why bother?

      Oh, and bad programmers can blow their feet off in every language I've ever written. Still, at least in C++, good programmers can be great.

      • I'm really interested in reading that book. I've found it, and when I get the time, I'll buy it and read it. However, I have read that he doesn't think that you have to design a language before you sit down and write it. This seems to fit the current state of C++, since bad design decisions are being squirrelled out and ironed over later.

        When I say nobody has ever made a fully compliant compiler, I mean that. The standard is huge, and at last estimation, it appeared that there must be an error in the grammar. I'd provide a link to the comment and the author who was a compiler programmer, but /. doesn't archive anything under 4 letters, making it hard to search for C++ comments. :P

        I've programmed in C, Java, Objective-C and Smalltalk (among other things, but those are the ones that are relevant) and each of them has something that offers itself as a better solution than C++. Above all, each of them has a clearer and less convoluted syntax. Java, Smalltalk, and Objective-C all offer (in my opinion, in any case) a superior object model to C++.

        I write C++ code every day. I write it, and I don't like it. I admit, I'm not a master at the language, but the amount of work it would take to do so seems somewhat ludicrous. By comparison, it's easy to master C, Smalltalk and Obj-C because of the tight design and relative smallness of the languages in comparison to C++.

        I agree that bad programmers will always find a way to do damage, but C++ gives far more ammunition than most languages. Every syntactic structure is another noose to hang yourself with.

        The fact of the matter is that you don't need a language like C++ to to big projects, write complicated systems, or have a flexible system. I'd argue that Objective-C and it's runtime system are far more flexible, easier to program, and have done a good job at implementing a complex system (ie. OSX). Check through the /. archives on topics like OSX and Objective-C. Many more eloquent people than me can tell you what's right with Obj-C and what's wrong with C++. Even better, go and pick up a book on Objective-C, and see for yourself.

        I won't lie to you, and deny that I'm biased against C++. But I'm biased against it for the same reason I don't like Windows. It's too big, it's too complicated, and there are better alternatives. But this is all just my opinion. Take it or leave it.

        I'll leave you with this quote that has always appealed to me:

        "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?" --Tom Cargin (C++ Journal, Fall 1990)
        • Above all, each of them has a clearer and less convoluted syntax. Java, Smalltalk, and Objective-C all offer (in my opinion, in any case) a superior object model to C++.

          The "cleanliness" and "superior object model" is a design tradeoff, it is not superior design. For example, you can be more consistent by not having the notion of "values" versus "references" versus "pointers" that you have in C++. But having these things offers compatibility with C, better performance, and a language that offers more in the way of static checking. This "elegance" you speak of does have some real world benefits, but the tight static checking and high performance offered by C++ also have real world benefits, and MLOC multi platform applications exist as proof of concept.

          I admit, I'm not a master at the language, but the amount of work it would take to do so seems somewhat ludicrous.

          Perhaps you should do some reading (-;

          By comparison, it's easy to master C,

          Depends on what you mean by "master". If "master" requires that you are capable of writing object oriented code, then it's really not that easy to "master" C. It's actually harder, because using encapsulation, modules, polymorphism and objects takes some discipline and skill. Any idiot can write fortran in C, but that's not "mastering" it.

          Smalltalk and Obj-C because of the tight design and relative smallness of the languages in comparison to C++.

          The apparent simplicity of these languages is a design tradeoff. There are a lot of good reasons why C++ did not choose the saqme tradeoffs, and they are all documented in Design and Evolution.

          I agree that bad programmers will always find a way to do damage, but C++ gives far more ammunition than most languages. Every syntactic structure is another noose to hang yourself with.

          Any useful tool can be abused.

          The fact of the matter is that you don't need a language like C++ to to big projects, write complicated systems, or have a flexible system.

          The fact of the matter is that C++ works very well for precisely this.

          I'd argue that Objective-C and it's runtime system are far more flexible, easier to program, and have done a good job at implementing a complex system (ie. OSX).

          Being "flexible" and "easy to program" is not necessarily a good thing for implementing large scale software. I'm not sure which parts of OSX are written in ObjC, but that sort of object model certainly works well in GUI components.

          Many more eloquent people than me can tell you what's right with Obj-C and what's wrong with C++.

          So what ? Many eloquent people can explain what's right with fascism and what's wrong with democracy. That doesn't make it true.

          If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one

          So where does he say that we should stop using C++ and start using objective C instead ?

          BTW, I know what it is, and I've never needed it.

        • I'm really interested in reading that book. I've found it, and when I get the time, I'll buy it and read it. However, I have read that he doesn't think that you have to design a language before you sit down and write it. This seems to fit the current state of C++, since bad design decisions are being squirrelled out and ironed over later.

          Please do read D&E. You seem to be trying to keep an open mind in the face of bad experience, for which I commend you. I think reading the book would explain a lot of the reasoning you aren't aware of, and perhaps change your perception of C++ a bit.

          As for the things to be ironed out, yes, there are certainly problems with the first standard. However, there are remarkably few serious ones; by far the most work on the new standard is going into the new library extensions, to fix glaring omissions like multitasking support, regular expressions, etc. And in fairness, many of the other language specifications (Java, C#, etc) would suffer the same problems when faced with criticism as rigorous as the C++ standard has received. Some of the loopholes (e.g., the DDD problem) they've written out of the languages by dropping features (e.g. MI), which is fair enough. Others, though, they just plain gloss over. Sadly, hiding a problem does not necessarily make it go away.

          When I say nobody has ever made a fully compliant compiler, I mean that. The standard is huge, and at last estimation, it appeared that there must be an error in the grammar.

          There are a number of such problems; the reference-to-a-reference issue is a common example. OTOH, at least they're being fixed. And again, don't forget that all the other languages have similar flaws, or just gloss over issues completely. How is Java's support for floating point maths these days, anyway? ;-)

          I've programmed in C, Java, Objective-C and Smalltalk (among other things, but those are the ones that are relevant) and each of them has something that offers itself as a better solution than C++.

          That may be the case. However, does any of them provide the combination of features as well as C++ does, or even provide it at all? If not, it's not really a fair comparison.

          Above all, each of them has a clearer and less convoluted syntax.

          That's harsh. The vast majority of problems with C++'s syntax come from C, not C++. The only real exceptions are references (designed to match C's pointers) and templates (designed to work with the preprocessors available when they were first implemented). I'm sure that, if writing the language from scratch and without compatibility considerations, Stroustrup would have considered alternatives. In fairness to him, he didn't have that luxury, and it's easy to criticise theoretically imperfect decisions made under practicality constraints.

          Java, Smalltalk, and Objective-C all offer (in my opinion, in any case) a superior object model to C++.

          We'll just have to agree to disagree on that one, then. Personally, I don't buy the hype about single-inheritance single-root hierarchies. They get used because they're simple, not because they're powerful. If that floats your boat, no problem, but let's be clear about what we're saying.

          The fact of the matter is that you don't need a language like C++ to to big projects, write complicated systems, or have a flexible system.

          Of course not. Then again, you don't really need high level languages at all, since you could just do it all in assembler. Any high-level language is designed to make things easier, and some languages make some things easier than others. The point, surely, is the trade-offs that are made in doing so. OO, for example, makes some things much simpler than they might be. On the other hand, it has well-documented but rarely-acknowledged limitations, particularly as implemented by many popular languages today. You pays your money (or downloads :-)) and takes your choice...

          "If you think C++ is not overly complicated, just what is a protected abstract virtual base pure virtual private destructor and when was the last time you needed one?" --Tom Cargin (C++ Journal, Fall 1990)

          (It's Cargill, by the way.) I think that's unfair in the context of today's C++, as is much of what Cargill wrote back then when faced with the test of time (c.f. the difficulty of writing exception-safe code when faced with techniques developed over the past few years). In particular, while I know what one of those is (actually, it's a mistake, since C++ does not define the term "abstract" in that context; it's an OO term, not a C++ one) and have never used one in practice, I have used each of abstract classes, virtual base classes, pure virtual destructors, private destructors and even protected inheritance quite legitimately at some point. I have never chosen to use the combination, but each of the features has value in its own right, and it would be more complicated to exclude probably-meaningless combinations than to just leave them be as orthogonal concepts.

          As I said, please read the book. Contrary to what you seem to have concluded, a lot of thought went in to each and every one of these features, and they are the way they are for a reason. That's why C++ is such a powerful language for those who make the effort. It's not, and was never intended to be, a simple language for those who are undemanding, so it's a bit unfair to judge it in that light.

    • This is complete nonsense. C++ is NOT a bad language. If you've ever heard Bjarne talk, you would know that he has a powerful mind for design, and his research background gives him the practical experience to build a great language.

      C++ is big. C++ is complicated. But these features do not make it a poor language. Rather, it takes a better programmer to effectively use C++.

      And you believe in the "C language philosophy"? The C language philosophy was "hey guys, I'm tired of porting assembler from machine to machine, let's generalize it". C is not faster than C++. At all. If you are a horrible C++ programmer, and completely missuse the more advanced features of C++, well, then C might be faster.

      And powerful? C is not powerful. Powerful is the STL - being able to use hyper-efficient genralized data structures with very little effort, and having that code be portable to virtually every platform you could dream of. Powerful is built-in exception handling.
    • > What the deal is with C++.

      Sounds like you haven't read:
      - "Desin and Evolution of C++" by Stroustrup and/or
      - "Multi-Paradigm Design for C++" by James Coplien.

      C++ is WAY better then C

      1 - It's a better C (better type checking, cleans up that cruft with typedef struct {}, etc)
      2 - Supports OOP synatix natively (Yes, you *can* do OOP in C, but it's tedious)
      3 - Supports generic programming (templates)

      > but the only thing that other languages taught me was how BAD C++ really is.

      True enough. Also, interesting, is that when I learnt C++, it showed me how bad C is.

      I agree learning multiple languages is always "A Good Thing" -- you get exposed to new idioms and design patterns.

      > I believe in the original C language philosophy. Small, simple, fast, powerful.

      So why not use just the C subset of C++? You'd gain all advantage and no disadvantages.

      Cheers
      • I do, in fact, do what you suggest, and use the C subset of C++. :)

        I'd rather be using Objective-C, though. It always stuns me that an excellent language like Obj-C (or even Smalltalk, for that matter) never really got popular, and an extremely complicated language with a few benefits over C got super popular.

        • I'd rather be using Objective-C, though. It always stuns me that an excellent language like Obj-C (or even Smalltalk, for that matter) never really got popular, and an extremely complicated language with a few benefits over C got super popula

          May I suggest you do some research into how and why C++ became popular ? C++ has an enormous number of benefits over C. To suggest otherwise is laughably ignorant. Thinks like built in support for OOP, parametrised types, and even a useful, well designed set of container classes are in themselves an enormous benefit.

          As for Obj C and Smalltalk, you disingeneously claim they are "better than" C++. They are not. They embrace different design tradeoffs to C++. Smalltalk and Obj C offer little or nothing in the way of static checking, which can be problematic when developing and debugging large applications.

  • From his document about things to be added to the C++ standard - talking about Random Number Generators:

    RNGs are used all the time for all sorts of things, from unimportant things like generating die rolls in a board game, to important modeling applications like generating random input for stock market simulations, to vital and crucial and easy-to-get-wrong security applications like creating unguessable input for cryptographically secure secret key generation.

    So...the die rolls are unimportant eh? Yeah...this guy has lost it. :)-
  • It's interesting (and I guess troubling?) that Herb didn't talk [cuj.com] about C99 ( everyone ready for C99? [gatech.edu]) in the context of VC++'s future.

    Microsoft definitely needs to boldly go where C++0x goes, which will be in part derived [cuj.com] from C99. C99 is cool. Can you say "complex"? Yeah =)

    I just hope VC++'s next compiler is the last one that is not compliant... it's too freaking painful sometimes.

  • It's great to see that Microsoft considers people like Herb to improve the quality of their C++ implementation.

    It's sad that after more than 10 years, C++ compilers all over the place still have a lot of trouble compiling C++ code. It's already bad enough that C++ is too difficult for most programmers. It's definitely a severe problem for C++ that most compilers can't deal with advanced C++, and fail compiling things like Loki. And yes, I'm talking about G++ too :-)

    What draws people to Java is not only the simplicity of the language for programmers. It's also the fact that most compilers have no trouble compiling your code on all platform. I think that's a point that most C++ folks (including Herb in the article) fail to understand. But to get this, you give up many handy features, notably templates.

    I personally believe that there is another way [sf.net], and that new programming languages [sf.net] are still a good idea.
    • I have to agree with you entirely. I am a C++ programmer by heart. But lately I have been doing quite a bit of Java again. Wow, does it work cross-platform. I am using a Windows Intel Notebook and a Linux PowerBook from Apple. Only with Java can I move sources and binaries from one machine to another without any problems.

      In C++ the Open Source community seems to have stuck its head up its butt in complexity. Take for example building a Open Source application. First we run autoconf, then ./configure and then finally we build. Of course lets not forget to include libtool and the likes. PEOPLE what are doing, making work for themselves?

      I have dropped the entire notion of using make files and other things. I ended up using ANT to build C++ programs. What a cool tool. Here is something that was re-engineered and it ends up as being a better project management of sources, executables, etc. And what is ANT written in? Java!

      C++ needs to get back to the drawing board and start things over and make things simpler! Java have and so has .NET...

      Sad to (Really Sad) to say it, but if C++ does not simplify it will run out of steam.
    • It's sad that after more than 10 years, C++ compilers all over the place still have a lot of trouble compiling C++ code.

      ANSI/ISO is still only 3 years old. Features to support code like Loki (templates, partial specialisations, MI) were not a part of the original AT&T implementation. So a big part of the problem is that it's been a moving target. But then, this is true of most useful languages in their early stages. C for example was standardised in 1989, 18 years after Bell implemented it.

      What draws people to Java is not only the simplicity of the language for programmers.

      The simplicity is a tradeoff. Java trades compile time optimisations, performance and static type safety for simplicity. This is not "better", or "worse", it's just "different".

      Note that Java, like C++, is still very much a moving target.

      It's also the fact that most compilers have no trouble compiling your code on all platform.

      Java has its share of version compatibility issues, caused by the fact that it's a moving target. It's also worth noting that a lot ot the "different compilers" license code from Sun. Look how long it's taking for a (working!) free implementation of java on Linux to appear.

      I think that's a point that most C++ folks (including Herb in the article) fail to understand.

      On the contrary, Herb is insightful to understand that other languages also have their advantages. He's a strong advocate of learning other programming languages.

      I personally believe that there is another way [sf.net], and that new programming languages [sf.net] are still a good idea.

      Matz (the Ruby guy) said in response to "why another language", that if someone found Ruby useful, that was a good enough reason for him. I think this is a good philosophy.


  • The need for a flexible programming language that can handle everything from high-level abstraction to bit-twiddling, all unified within the same language, isn't going away anytime soon.

    C'mon, there is absolutely no need for a language like that! You should use the right tool for the job, and lemme tell you, C++ is not necessarily the right tool. To whit, applications that should not be written in C++:

    • high-performance embedded applications
    • text processing applications
    • Hello, World!
    Seriously, though, an programmer who has only one tool in their toolbox is a waste of space. I swear, the world must look like it's made of nothing but nails to this guy, 'cuz all he has in his toolbox is a big freakin' hammer...
    • FUD. C++ for embedded work is perfectly sensible, if the tools aren't crud. C++ is known as the second best language for any given job -- but in actual fact that often makes it the best when you've taken the non-technical factors into account.

      And yes, I have used a wide range of languages professionally. I know about choosing the right tool for the job. It's just that C++ is usually eliminated, when it is, because people believe myths, not because of valid reasons (which do sometimes exist).
  • C++ standard is stabilized, its proper implementation is nowhere in sight (especially by Microsoft, no matter what they proclaim as their goal -- was February supposed to be the month the whole company had to spend entirely on fixing security bugs?), so it doesn't matter what those people are doing.

    Of course absolutely idiotic idea that someone's cumbersome library is a part of the language, gives a lot of fuel to the "progress", but I hope, programmers will learn soon that TEMPLATES EXIST FOR THEM TO USE, NOT TO MAKE STL WORK. That will, of course, happen when enough smart people will start using C++ -- right now C++ is mostly being used by people too dumb to use C, or ones that had misfortune to get some crippling course that teaches C++ without C, thus making otherwise good language a domain of ignorant people.

Slashdot Top Deals

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Close