Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
Programming IT Technology

Interview With Bjarne Stroustrup 502

Posted by Hemos from the talking-with-the-giants dept.
koval writes "artima.com has published an initial portion of interview with Bjarne Stroustrup. The scope of first part is mostly about improving the style of C++ programming and getting maximum from a language."
This discussion has been archived. No new comments can be posted.

Interview With Bjarne Stroustrup More

Interview With Bjarne Stroustrup

Comments Filter:
  • How about eliminating the buffer overflows?
    • There aren't any buffer overflows inherent in the c++ language, it's crappy programming that causes buffer overflows.
      • Well then, there must be a whole lot of crappy C and C++ programmers and no crappy Java, Python, Ruby, Smalltalk, Lisp programmers.
        • What I don't understand is WHY DOESN'T ANYONE COMPILE BOEHM GC INTO THEIR PROGRAMS???????

          Is that so hard? Is it too much to ask?

          I mean, not only would it save bugs, it would make C++ 10000000 times easier to program in.
          • Most people believe in the 40 year old myth that started with Lisp that a garbage collector makes a program slow. Of course, that isn't true anymore, but myths stick for longer than facts.
    • How about eliminating the buffer overflows?

      std::vector already does this. How about using it?
      • std::vector already does this. How about using it?

        I don't think it does. STL does very little checking in general, because it has to be blazingly fast in order to not be ignored by C++ mainstream (for which performance is everything, never mind the development costs).

        Besides, a lot of people who program C++ have to program in environments ( == old compilers) where such pansy features as STL, RTTI or exceptions are not available.
      • std::vector already does this. How about using it?

        Am I the first to think that maybe "STD vector" is possibly the worst name for a data type? ;)
    • strncpy() has existed for quite some time, thanks. How about eliminating the coding practices that lead to buffer overflows? Oh, right, it's the *language's* fault. God forbid a language which is designed explicitly to allow you to do exactly what you want to in the nearest-to-machine way reasonable allow you to write security holes too.

      Maybe instead of asking your toolset to design for you - security is a design process, not a patch process, which is why it works for qmail but not for sendmail - you sh

  • Scott Meyers (Score:3, Funny)

    by CyberGarp ( 242942 ) <Shawn.Garbett@org> on Monday October 13, 2003 @10:33AM (#7199272) Homepage
    Any language that allows for someone making a living pointing out everything one shouldn't do needs more than a face-lift.

    • Any language that allows for someone making a living pointing out everything one shouldn't do needs more than a face-lift.

      Cute, but meaningless. Any language has features that are easily overused or abused. One of the things a programming teacher has to do with any beginning class is explain what you shouldn't do. Or at least he should be spending time on that.

      C++ has problems, yes; pretty unavoidable since it was the first real object oriented language. Java has a different set of problems since it w

      • >since it was the first real object oriented language.

        Huh? What about Simula, the first object oriented language?

        • Re:Scott Meyers (Score:2, Funny)

          by PD ( 9577 ) *
          Or assembly. You could have any object you wanted, as long as it fit in a register.

        • since it was the first real object oriented language.

          Huh? What about Simula, the first object oriented language?

          Or what about Common Lisp, the first object-oriented language with a published standard?

          It doesn't make much sense to say that any particular language was "the first real object-oriented language" because people have different religious beliefs as to what constitutes a "real" object-oriented language.

          People get into hideous flamewars about that word "real" when applied to categories like

      • Re:Scott Meyers (Score:3, Interesting)

        by CyberGarp ( 242942 )

        C++ has problems, yes; pretty unavoidable since it was the first real object oriented language.

        This comment alone summarizes the posters knowledge of programming languages. For a better understanding of C++, check it out on the Computer Languages History [levenez.com] website

        My reply: Cute, but it unfortunately does mean something. C++ has more features that are so easily misused (not abused), that Scott Meyers wrote 3 large volumes on the subject. Other languages have similar featuers, but not in near the quantity o

        • > PS Object Oriented is a concept adapted from functional programming languages, i.e. LISP.

          It is definitely not. Functional programming languages work with "values" not "objects". Objects (with having a state) and Functional languages are mutually exclussive. All attempts to introduce objects into functional programming languages have failed.

        • PS Object Oriented is a concept adapted from functional programming languages, i.e. LISP.

          This comment alone summarizes the posters[sic] knowledge of programming languages. :-)

        • that Scott Meyers wrote 3 large volumes on the subject.

          To bolster the point, there are a fair number of other authors which have written such series, and some of them arguably more difficult than the effective trio. Notably, Dewhurst's C++ Gotchas and Sutter's Exceptional/More Exceptional C++ are similar vein, similar-or-greater difficulty issues. None quite so well written as Meyers', though.

      • Re:Scott Meyers (Score:5, Funny)

        by Waffle Iron ( 339739 ) on Monday October 13, 2003 @10:54AM (#7199457)
        C++ has problems, yes; pretty unavoidable since it was the first real object oriented language. Java has a different set of problems since it was the first language that was OO from the ground up.

        Let me guess... you work as a prior art researcher for the USPTO.

    • I swore off C++ almost a year ago (wish I had done it sooner), and in retrospect, getting "the maximum" from C++ felt like getting blood from a turnip.

      Check out Ruby, Python, Scheme, OCaml, Smalltalk, Haskell, Objective-C [I mention this last one because a competent programmer in either C or C++ can pick up the language in 20 minutes...], or some other language you've thought about but never made time to learn. Any and all of these languages will change the way you program, and the way you think about pr

    • Re:Scott Meyers (Score:3, Insightful)

      by stonecypher ( 118140 )
      Any language that allows for someone making a living pointing out everything one shouldn't do needs more than a face-lift.

      It's not exactly clear to me whether I'm taking a joke on as if it were serious. That said, this is a genuine sentiment with many, so I feel my rebuttal to be germane to them if not nessecarily to you.

      The problem with language is that its domain is inherently difficult. The more expressive a language is, the deeper and more powerful structures it can express. Conversely, because ma

  • Yes! (Score:4, Funny)

    by kurosawdust ( 654754 ) on Monday October 13, 2003 @10:33AM (#7199273)
    Oh boy! I can't get enough of Bjarne and J-Lo!

  • Probably fake but . . . (Score:4, Funny)

    by Brahmastra ( 685988 ) on Monday October 13, 2003 @10:37AM (#7199309)
    I agree with every word of this probably fake interview [safe-t.net]

    Interviewer: Well, it's been a few years since you changed the world of software design, how does it feel, looking back?

    Stroustrup: Actually, I was thinking about those days, just before you arrived. Do you remember? Everyone was writing 'C' and, the trouble was, they were pretty damn good at it. Universities got pretty good at teaching it, too. They were turning out competent - I stress the word 'competent' - graduates at a phenomenal rate. That's what caused the problem.

    Interviewer: problem?

    Stroustrup: Yes, problem. Remember when everyone wrote Cobol?

    Interviewer: Of course, I did too

    Stroustrup: Well, in the beginning, these guys were like demi-gods. Their salaries were high, and they were treated like royalty.

    Interviewer: Those were the days, eh?

    Stroustrup: Right. So what happened? IBM got sick of it, and invested millions in training programmers, till they were a dime a dozen.

    Interviewer: That's why I got out. Salaries dropped within a year, to the point where being a journalist actually paid better.

    Stroustrup: Exactly. Well, the same happened with 'C' programmers.

    Interviewer: I see, but what's the point?

    Stroustrup: Well, one day, when I was sitting in my office, I thought of this little scheme, which would redress the balance a little. I thought 'I wonder what would happen, if there were a language so complicated, so difficult to learn, that nobody would ever be able to swamp the market with programmers? Actually, I got some of the ideas from X10, you know, X windows. That was such a bitch of a graphics system, that it only just ran on those Sun 3/60 things. They had all the ingredients for what I wanted. A really ridiculously complex syntax, obscure functions, and pseudo-OO structure. Even now, nobody writes raw X-windows code. Motif is the only way to go if you want to retain your sanity.

    [NJW Comment: That explains everything. Most of my thesis work was in raw X-windows. :)]

    Interviewer: You're kidding...?

    Stroustrup: Not a bit of it. In fact, there was another problem. Unix was written in 'C', which meant that any 'C' programmer could very easily become a systems programmer. Remember what a mainframe systems programmer used to earn?

    Interviewer: You bet I do, that's what I used to do.

    Stroustrup: OK, so this new language had to divorce itself from Unix, by hiding all the system calls that bound the two together so nicely. This would enable guys who only knew about DOS to earn a decent living too.

    Interviewer: I don't believe you said that...

    Stroustrup: Well, it's been long enough, now, and I believe most people have figured out for themselves that C++ is a waste of time but, I must say, it's taken them a lot longer than I thought it would.

    Interviewer: So how exactly did you do it?

    Stroustrup: It was only supposed to be a joke, I never thought people would take the book seriously. Anyone with half a brain can see that object-oriented programming is counter-intuitive, illogical and inefficient.

    Interviewer: What?

    Stroustrup: And as for 're-useable code' - when did you ever hear of a company re-using its code?

    Interviewer: Well, never, actually, but...

    Stroustrup: There you are then. Mind you, a few tried, in the early days. There was this Oregon company - Mentor Graphics, I think they were called - really caught a cold trying to rewrite everything in C++ in about '90 or '91. I felt sorry for them really, but I thought people would learn from their mistakes.

    Interviewer: Obviously, they didn't?

    Stroustrup:


    • It's not "probably" fake. It's complete crap. He debunked this in his FAQ a couple days after the first troll posted it.

  • Compilers (Score:4, Interesting)

    by ultrabot ( 200914 ) on Monday October 13, 2003 @10:39AM (#7199324)
    Speaking of C++, is there a compiler that complies with the ISO standard already? Does anyone use it?
    • Actually, all of the most popular C++ compilers are getting pretty close to standards compliance (even g++ ;-). This is largely thanks to the work of The Edison Design Group [edg.com], who license compiler front ends, and are very focused on standards compliance.

      If you don't want to spend a lot of money, and you don't want to stop using the compiler that you have, I highly recommend The Comeau Compiler [comeaucomputing.com]. It is a compiler front end derived from the EDG codebase, and only costs you $50. The big downside is that your c
  • I see that a lot of people here are confused and posting questions for Bjarne Stroustrup. This is not a slashdot interview where people post questions for the guru and the editors pick the top 5 for the interviewee to answer. This is an interview that was done by an external website and not interviews.slashdot.org.
  • Seriously, you can't seriously improve a language by telling people how to program with it. You also don't know if these so-called style improvements help anyone at all. This is just like Hungarian notation, where people stupidly decided they wanted to know the type of a variable by looking at its name. The C++ language is what it is. Whatever you can do with it is what it is. You can't make C++ into Java by telling people what they can't do. This is why C++ is not Java. The "problems" in its design a
    • Are you saying that "_f_m_computedAreaOfCircle" is not a good name for the private member floating point variable that holds the computed area of the containing circle object? =)
      • how about just AreaOfCircle.. your ide should tell you that its private and that its a float, and "computed" is sort've implied by it being a variable in the first place. In the case this is a class property where the class is the circle well then it should just be Area because circle is implied.

        I'm really picky about variable names.. in the end if you can stay consistent and make good decisions on variable names it ultimately makes the biggest difference as to the readability of your code
    • Seriously, you can't seriously improve a language by telling people how to program with it.

      You can write bad code in any language. I don't see how your statement and the prvious sentence can both be true unless you equate it to some individuals are capable of programming and some are not, but, at some point in time, we had to be "told" how to write programs which kind of invalidates your statement.

      The other point is, there are a number of rules that you can use that if abided by will have fewer chances o

      • You can write bad code in any language. I don't see how your statement and the prvious sentence can both be true unless you equate it to some individuals are capable of programming and some are not, but, at some point in time, we had to be "told" how to write programs which kind of invalidates your statement.

        Not exactly sure what you are saying here. But by when I say how to program, I am speaking of style. Which is what the interview is about.

        The other point is, there are a number of rules that you

    • This is just like Hungarian notation, where people stupidly decided they wanted to know the type of a variable by looking at its name

      Sadly, the original idea behind Hungarian notation seems to have been lost to the ages. The idea behind it was that the C language's weak typing made it quite easy to accidently use the wrong type, particularly when doing parameter passing. The idea was to encode the type into parameters and variables, such that it would become blantantly obvious when one was making such a

    • It's an education issue (Score:4, Insightful)

      by Anonymous Brave Guy ( 457657 ) on Monday October 13, 2003 @01:57PM (#7201062)
      Seriously, you can't seriously improve a language by telling people how to program with it.

      However, you very much can improve how a language is used by telling people how to program with it. The single biggest problem C++ has isn't dangerous pointers, or ugly template syntax, or lack of a garbage collector, it's lack of good programmer education. C++ is a power tool, and requires skill to use. When most of the C++ textbooks in the world are teaching decade-old crap themselves, and most of the university professors don't know their own subject, it's not too surprising.

      I can sympathise a lot with Stroustrup here. His tool is unjustly battered by the ignorant more than perhaps any other mainstream language today, and it creates a self-fulfilling prophecy: most people who learn C++ learn it badly, and write code with buffer overflows and other kindergarten mistakes. Others pick up on this, and learn from people who themselves learned badly, and write more code with kindergarten mistakes. It's about time the C++ programming industry reached High School, but few ever seem to, and when they do, they aren't valued as much as they should be.

  • From the article (Score:3, Insightful)

    by Apreche ( 239272 ) on Monday October 13, 2003 @10:57AM (#7199481) Homepage Journal
    Quote Bjarne Stroustrup: Yes. If every data can have any value, then it doesn't make much sense to have a class. Take a single data structure that has a name and an address. Any string is a good name, and any string is a good address. If that's what it is, it's a structure. Just call it a struct. Don't have anything private. Don't do anything silly like having a hidden name and address field with get_name and set_address and get_name and set_name functions. Or even worse, make a virtual base class with virtual get_name and set_name functions, and override it with the one and only representation. That's just elaboration. It's not necessary.

    Thank You! This is the number one java peeve. Every time I just want to make a structure I've got to make a whole class. That's a whole file. That's a whole lot of extra code. In C/C++ I can make an equivalent struct in a few lines.

    This is why I like python so much. I can do all the object-orientedness I want and all the proceduralness I want and they work together perfect. And everything pops out into super efficient C code and then into executable with my gcc. And if I want it cross platform I can just use jython and get workin .class files.
    • How are you getting super efficient C code from your python programs?

      • Re:From the article (Score:2, Informative)

        by Anonymous Coward
        I suppose he could be talking about Psyco [sourceforge.net], the Python JIT module. I haven't used it yet, but I hear good things.
    • Wha? You can create an inner class. If you make it static, you can share it publically (new X().Y() or new X.Y()). If you make all it's attributes public, you get what is the equiv of a struct.

      public class X{ public int a; public int b } ...

      X z = new X();
      z.a = 1;
      z.b = 1;

      is it really THAT much different from

      typedef struct { int a; int b; } X

      X *z = ( *X ) malloc( sizeof( *X ) );
      z->a = 1;
      z->b = 2;

      Complaining that you can't do the equiv of struct{ ... } a,b,c is really petty. 3 (java) new statem

    • Re:From the article (Score:4, Insightful)

      by X ( 1235 ) <x@xman.org> on Monday October 13, 2003 @11:20AM (#7199629) Homepage Journal
      You need to bone up on your Java, and perhaps your C++.
      1. In C++, in terms of writing effort, a class and a struct are the same
      2. In Java, you can have multiple classes in a single file. Indeed, the compiler could care less, just like in C++.
      3. You can compile Java code to binary, indeed you can do so with gcc.
      4. Try benchmarking Java vs. Python some day. You'll discover that aside from start up time, Java outperforms Python in the majority of cases.
      This is the C++ code for a class:
      class Foo {
      public:
      int bar;
      int baz;
      };
      This is the C++ code for the equivalent struct:
      struct Foo {
      int bar;
      int baz;
      };
      This is the Java code for the equivalent class:
      class Foo {
      public int bar;
      public int baz;
      }
      Not a lot of difference is there?
    • If you want to save an extra file:

      class X { // "real class" using // some datastructure Y

      static class Y {
      type1 field1;
      type2 field2;
      }
      }

    • Re:From the article (Score:3, Informative)

      by jcbphi ( 235355 )
      These are some of the many reasons why Python is my language-of-choice, and why I don't program much in Java (my first programming language!). However, I should point out that what pops out is not super efficient C, but rather reasonably efficient compiled byte-code. Its nice, but python is rarely as fast as I'd sometimes like it to be.

      But that's a story for another day...

      Cheers,
      J

    • You could just make an inner class with only data members. It would probably take you two more lines than it would to make a struct. You can make it private or make it public and use it in other classes.

      But really, making a whole file isn't that hard either - you copy some other file and then change the innards. Done. You don't have to write get/set, you can just have accessible data members.

      -andy

  • Weird guy (Score:3, Informative)

    by the uNF cola ( 657200 ) on Monday October 13, 2003 @11:05AM (#7199534)
    I went to one of this guy's conferences on C++. I thought it'd be more in depth, but it was merely introduction to the features of C++. It does this, it does that. Neat libs like boost and the stl. Also has ACE libs for cross compatability

    Well, as one may expect, someone asked about java. He got very biligerant and brief about it. "C++ is supported on N many more platforms than java." (Can't remember N). It was also the last question too, which left that "weird" sense in my mind's eye.

    • Re:Weird guy (Score:2, Insightful)

      by kraut ( 2788 )
      Funnily enough, I've met him a few times at accu (http://www.accu.org/) conferences and had really interesting discussions with him.

      He's certainly no weirder than most other programmers I know, if you make allowances for him being Danish ;) And you have to make some allowances for being annoyed about Java: He developed a systems programming language that allows you to use OO; then everyone jumped onto the bandwagon and wrote crap programs in it (think monkeys with powertools), and then someone comes up w
      • But at a conference? I get my name mispronounced by everyone, which is by far, more personal, but I don't get snippy when it gets misprounced. I get happy when people pronounce it right :) Can't he be happy people do use it? He's prolly gotten further than most program language developers ever have.

  • Invariant/struct discussions and binary compatibil (Score:3, Interesting)

    by tjansen ( 2845 ) * on Monday October 13, 2003 @11:19AM (#7199623) Homepage
    Stroustrup and the interviewer miss one important point in the class vs. struct and invariant discussion: binary compatibility. The reason why you should not access variables in structs/classes directly is not always that their representation may change. More often it happens that you need to add a member, but this is not possible without breaking binary compatibility (at least on the usual Linux/Unix compilers). So you need to use the private class/d-ptr pattern to hide at least future members from the public class. This does not break apps that use the class members of earlier version, but it would make the API inconsistent, as the newer version would need to offer a different way of accessing the members. And the easiest one is to have get/set methods. So if you don't want to fall into the inconsistent API trap later, you should use get/set methods from the beginning. It's the only chance to have a consistent API over several evolving but still binary compatible versions.
  • >>Instead, if you build a relatively simple interface to a Date class, you might have five or ten member functions that are there because they are logically necessary. [..] Then you get these five or ten operations, and you can build the other 50 in a supporting library.

    I would disagree with that statement. While I can understand the concern (less dependence on data structures in the 50 methods), this creates an API that sucks. As a developer you want to have all helper functions for a data type at a
    • Most C++ IDE's do a pretty good job of showing you the functions you can invoke on a type.

      Also keep in mind that nothing says that your Date functions have to be "spread all over the place". Indeed, it is quite logical to have calendar-type manipulations in one place, standard temporal operations in another, and formatting stuff idealling in a third place. Amazingly, this is actually what happens in the case of Java, despite the fact that it uses classes for all this stuff.

    • As a developer you want to have all helper functions for a data type at a single place.

      Why? Adding all the supporting functions into the type itself just clutters the interface and makes it hard to find the "heart" of what the class does. As mentioned in the interview, it also removes much of the benefit of abstraction and encapsulation.

      As the user of an IDE you want to see all available functions when you enter a variable with a given type.

      That argument doesn't generalise, though. How do you find

  • I've always liked C++. After reading about half (still working on the rest of it) of "The C++ Programming Language" by Bjarne, I've learned so much about what good C++ programming is about. During University, the C++ class I took covered so little. It was basically a C course except we implemented yet another string class. This book is great. Bjarne comes across as a really smart and logical person. The last few chapters about design are great. I skipped up to them after reading the first 2 sections or so.

  • The real trouble with C++ (Score:4, Insightful)

    by Animats ( 122034 ) on Monday October 13, 2003 @12:03PM (#7199973) Homepage
    C++ suffers from the same problem that killed Pascal - its creator thinks everything is just fine, yet people are deserting it because it has some major problems that the creator refuses to fix and everybody has to work around.

    We went through this with Wirth. Wirth devised Pascal, which had reasonable data structures, although not objects, terrible I/O, and strings that only worked if they were short. He then insisted that it shouldn't change. From this came a whole range of incompatible Pascal dialects (Turbo Pascal, Object Pascal, Clascal...), and some successor languages (Modula I, II, III). Modula III was actually rather good, but nobody except some researchers at DEC SRL (now an empty building in Palo Alto) used it. Two decades later, few use Pascal or its derivatives, and Wirth is a forgotten and bitter man in Switzerland.

    This cycle is being repeated with C++. The first version of C++, before templates and the STL, was terrible. Without templates, horrible schemes involving huge defines were used to make generic objects. Strostrup used to have great hostility to run-time type information, which led to unchecked downcasts all over the place.

    Round 2 of C++ came late, and it took a long time before the compilers did templates. Then came the STL, which is wierd and unsafe, although useful.

    C has little abstraction and little safety. Java has both abstraction and safety. C++ has abstraction without safety, a terrible combination. The basic problem with both C and C++ is that the language requires the programmer to obsess on storage allocation and release, yet gives no assistance in this. Attempts to encapsulate storage allocation in C++ fail miserably (look at the history of auto_ptr). Attempts have been made to fix the language by adding another layer of rote ritual ("patterns") on top of it, but compilers can't check that, so it doesn't reduce bugs.

    Another area of trouble comes from the history of C++ as a preprocessor for C. Bell Labs had a tradition that "you can't change the linker". (This is probably because the original UNIX linker was written in assembler and had few comments.) Because of this, some tasks that should be deferred to link time (such as building vtables) are done at compile time.

    The price paid for not changing the linker is substantial. Private function members appear in header files so that vtables can be built at compile time. That's the real reason, despite what you read. If it weren't for that, you could have much stronger separation between declaration and implementation. And you wouldn't be recompiling class users just because the class implementation changed. Ada and Modula got this right, but C++ got it wrong. And Strostrup refuses to fix it.

    Yes, there are "patterns" for working around this. But they're workarounds. The programmer is doing the compiler's job. This imposes a cost on every programmer and distorts C++ programs.

    Strostrup still insists there's nothing really wrong with his language. Read what he's written about the C++200x standards revision cycle. Meanwhile, C++ is being abandoned for Java, C#, C, and scripting languages.

    • I agree with everything you say about C++. On the the Pascal side, however, I believe that fixing the language was necessary but not sufficient; witness Borland's Delphi, which features Object Pascal, a superb dialect of Pascal. For something like six years Delphi/Object Pascal was unmatched by anything in the Windows arena - nothing was even close - but it did not take over the world. Now that Delphi is essentially matched by C#/VB.NET, I suspect that Delphi's days are, sadly, numbered.

      I guess the poin
      • For something like six years Delphi/Object Pascal was unmatched by anything in the Windows arena - nothing was even close - but it did not take over the world.

        That's more of a Borland problem than a language problem. No single-vendor language has ever gone very far. Even Java and C# are open enough that others can write compilers for them.

  • Not awake yet- (Score:3, Funny)

    by IWantMoreSpamPlease ( 571972 ) on Monday October 13, 2003 @12:07PM (#7200013) Homepage Journal
    I mis-read the title. Thought it said "interview with a mousetrap"

    oooops...
  • Just how do you pronounce your name?

    Looking through, I can't believe I didn't see someone else asking it...

  • C++ in the long term. (Score:3, Interesting)

    by Godeke ( 32895 ) * on Monday October 13, 2003 @12:48PM (#7200440)
    I programmed in C for years, mostly due to the performance of the early machines I used. Today, I wouldn't consider going back to C unless it was for time critical functions. Everything I do these days is in an environment that protects me from the gory details of memory management and pointers of doom. If I really need performance, I am going to profile my code and find the parts that really need the boost, and then recode the classes as C++ COM or more recently C++ assemblies for .NET. It is the same procedure I used to use when C was my primary language: find the performance hot spots and drop to assembly if needed.

    The discussion of class design has nearly nothing to do with C++. I can use Java to build overly complex towers of inheritance. I can also use it to build poorly defined libraries. One think I *can't* easily do is blow myself (and the underlying OS) up do to a memory allocation problems.

    I see C++ remaining for many years to build those "cycle critical" components, which are going to be consumed by languages with a guard over the chainsaw blade. Programmer efficency should always trump speed concerns until you have exhausted *algorithmic* improvement. I don't know how many times I see programmers saying "I'm using C++ for performance" while simultaniously writing something that is going to run in o(n^2) time, when a o(log(n)) algorithm is available. Yes, your C code will run your inefficent algorithm quicker than I would in a protected environment, but if my protected environment allowed me to see the abstraction that runs the fastest algorithm, my code will still be faster for large data sets.

  • Confirmed: C++'s not very object-oriented (Score:5, Insightful)

    by dpbsmith ( 263124 ) on Monday October 13, 2003 @02:15PM (#7201189) Homepage
    I'm not saying that's necessarily a bad thing.

    The interview is interesting in that it confirms the impression I've had from using and/or struggling to use C++. When I try to do anything object-oriented, specifically anything involving polymorphism, it seems to be fighting me all the way. After some struggling I usually emerge triumphant, but it's almost always a battle.

    What Stoustrup seems to be saying is that classes should be treated as a special big deal, and shouldn't be used unless you're sure they're necessary. He seems to be recommending that there be, um, a class of elite programmers who put in the intense work to develop good, usable, well-debugged classes, and that the rank and file should, by all means use those classes but should not aspire to write new ones.

    And this is not unreasonable, given the effort of writing classes and getting the storage management right and so forth.

    The thing is, it's not a big deal to use classes in a truly object-oriented language. I'm not just talking about Smalltalk. Heck, they're trivial to use in REALbasic.

    Well, is that good? It certainly leads to overuse of OOP. To a man with a hammer everything is a nail, and every programming language tends to encourage overuse of the things that it facilitates. Every programming language has a tendency to induce brain-warp.

    C++, for better or for worse, does not induce object-oriented brain-warp.

    People who try to use OOP in C++ because it's cool or because of some article they read (or some instructor they had) find that C++ punishes such behavior. And Stoustrup is right: when you are programming in C++, OOP should be used sparingly and only when it's needed.

    Again, I'm not saying whether that's bad or good. That will depend on the degree to which you think OOP ought to be encouraged. If you think OOP should be just as much a part of a programmer's mental toolbox as iteration, or recursion, then it's not good. If you think OOP was the overhyped IT fad of the nineties, then it's not bad.

    What I'm saying is that it has always seemed to me that C++ is not a very object-oriented language, and Stoustrup's remarks seem to me to confirm the objective validity of that observation.

  • What is OOP? (Score:3, Interesting)

    by exp(pi*sqrt(163)) ( 613870 ) on Monday October 13, 2003 @02:44PM (#7201434) Journal
    If I write something like:

    class F {
    float a;
    public:
    F(float a0) : a(a0) { }
    template<class X> X operator()(X x) const { return X(a)+x; }
    }

    is it OOP? It looks like OOP: it has a member variable, a method, a constructor and so on. But actually I'm defining a function closure. In Haskell you coud write an F(a) object as (a+).

    My point is this: for many programmers today objects are often a(n awkward) vehicle for computing with closures. This has many payoffs: it gives the ease of functional programming but also potentially provides many performance benefits. I code like this all the time as do hundreds of others. This is how you need to code if you actually want to do anything non-trivial with the STL.

    So in some sense I'm an OOP programmer. But in another sense I'm not. I'm not writing my code this way because I want to work with objects - I do it because this is the only way I know to treat a polymorphic function as a first class object in C++. Really I'm a functional programmer forced to use C++. It seems to me that many of Bjarne's remarks are way off the mark for programmers like me. We have to define classes for every damn little thing!

  • Read Stroustrup's Design and Evolution of C++ (Score:4, Interesting)

    by ChaosDiscord ( 4913 ) on Monday October 13, 2003 @04:29PM (#7202324) Homepage Journal

    If you hate C++, it's unfair to suggest you read a book on it. But if you have any fondess for C++, or use C++ (even if you dislike it), Design and Evolution of C++ [att.com] is probably worth your time. You learn why C++ is the slightly confusing mess that it is, and why Stroustrup believes it's the only way it could have succeeded. Having a grasp on why C++ is C++ (and not Objective C or Java) can improve your C++ coding abilities. And understanding why behavior you don't like is there can at least help minimize the suffering ("This is stupid, but there really isn't any way to change it.").

  • C++ is too simple. (Score:3, Funny)

    by rice_burners_suck ( 243660 ) on Monday October 13, 2003 @07:22PM (#7203694)
    improving the style of C++ programming

    What C++ really needs is more features... LOTS more features. The language is not "rich" enough. C++ should add many other features to its syntax.

    • For example, the ability to name identifiers with any character in any character set.
    • As C++ is not complicated enough, we need a way to dynamically create syntax. It would work like operator overloading, but much more complicated. And it would be called Syntax Overloading. For example, the code, ("for (" class "in" class ")")() { [insert code here] } would allow you to specify a new type of for loop with your own syntax. The compiler, upon reading this line, would add the new syntax to its language rules. Then, you could type for (className in otherClassName) { some.code.here(); } and it would work as expected.
    • The language desperately needs some built-in cryptography functions. For example, the function const unsigned void do_it(const unsigned short void const crypto % arg) takes one parameter, arg, which is encrypted inside a processor register and cannot enter main memory for security reasons.
    • More complicated template syntax is needed. For example, suppose you want to create a class that is unknown at compile time... obviously, a way to specify runtime template processing is desperately needed.
    • Support for returning multiple return values from a function. For example, the function const unsigned short, const int *, const long long grok_the_file(void) might return three different return values, seperated by commas, as in, return i, j, size; Oh yeah, and you could specify functions that return an unknown number of values using ellipses, as in unsigned short... function_name() or simply ... function_name(). Suppose you want to call a funciton that takes 3 parameters... you could instead pass it one function that returns 3 return values and C++ would know what to do with it.
    • C++ needs a reserved word, like please_reconsider_cast, or something, that uses common sense to figure out what the heck you're trying to typecast into what, so that even if the code is faulty, the compiler will figure out what you really mean.
    These are all just a drop in the bucket. C++ is obviously too small and simple of a language.

Slashdot Top Deals

"For the love of phlegm...a stupid wall of death rays. How tacky can ya get?" - Post Brothers comics

Close