Bjarne Stroustrups and More Problems With Programming

Phoe6 writes "As a follow up to the first part of his interview, Technology Review Magazine has another article running titled 'More Trouble with Programming'. Bjarne Stroustrup shares his point of view on good software, bad software design and aspect oriented programming." From the article: "Technology Review: Name the coolest and lamest programs ever written in C++, and say what worked and didn't work. Bjarne Stroustrup: Google! Can you even remember the world before Google? (It was only five years ago, after all.) What I like about Google is its performance under severe resource constraints. It possesses some really neat parallel and distributed algorithms. Also, the first Web browsers. Can you imagine the world without the Web? (It was only about 10 years ago.) Other programs that I find cool are examples of embedded-systems code: the scene-analysis and autonomous driving systems of the Mars Rovers, a fuel-injection control for a huge marine engine. There is also some really cool code in Photoshop's image processing and user interfaces."

Comments

Coolest and lamest!

[Anonymous Coward]

It is,

int main()
{
      cout "Hello World" eol;
      return 0;
}

Very cool at first, then it just goes down from there.

Re:Coolest and lamest!

[gangien]

as cool as html parsers?

Re:Coolest and lamest!

[Anonymous Coward]

Very cool at first, then it just goes down from there.

You are of course referring to int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR szCmdLine, int iCmdShow). Hello World! just doesn't feel the same when you have to write 100 lines of code to get it to work.

Re:Coolest and lamest!

[Anonymous Coward]

No, you have already used C++ syntax. At this point, it is not too late to correct your ways, but otherwise, it really is downhill from there.

Re:Coolest and lamest!

[ToasterofDOOM]

Hey, Guess what's cooler ...
program MyProg;

uses
  CRT;

begin
  Writeln('Hello World!');
end.

...Doesn't duck because he knows that any real pascal programmer could beat any C++ pussy down

P.S. - C++ isn't too bad, but Pascal is way cooler.

Re:Coolest and lamest!

[Amazing Quantum Man]

with TEXT_IO;
 
procedure body MAIN is
begin
  TEXT_IO.WRITE_LINE('Hello World');
end;

Disclaimer, it's been close to 10 years since I've used Ada(r). I may have a few minor errors there.

Re:Coolest and lamest!

[jrockway]

> Very cool at first, then it just goes down from there.

Psh, infix languages are lame. Try:

you forth love if honk then

or

(cond ((love 'you 'lisp) honk))

Re:Coolest and lamest!

[Z34107]

Actually, the "hello world" program using the native Win32 API is:

int WINAPI WinMain(HINSTANCE hInstance, HINSTANCE hPrevInstance, LPSTR szCmdLine, int iCmdShow) {
MessageBox(NULL, "Hello, World!", "HelloWorldApp", MB_OK);
return 0;
}

You don't need 100 lines of code, obviously. The WinMain function can be a little intimidating, unless you consider that the parameters actually make ince. hInstance is a handle to your program in memory - you only need this if you want to dig icons or other resources out of your EXE while it's running. hPrevInstance is no longer used. szCmdLine is - you guessed it - the command line (rarely used) and iCmdShow is whether your program should be starting maximized, minimized, etc (but can be ignored.)

Granted, the 100 lines of code comes in when you want to make a "real" Windows app - have a real window that responds to events. But, all this entails is filling out a struct that describes your window, creating the window from that struct, and setting up your message queue. About 1 page of code, but it's the same for every program and you can copy/paste.

MFC makes this easier, of course, but that's C++.

Re:Coolest and lamest!

[Anonymous Coward]

Any 'properly' written Hello world is over a 100 lines. The golden standard, GNU's hello.c, is 192 lines.

Re:Coolest and lamest!

[krischik]

Almost - procedures don't need the "body" keyword and modern Ada programmers don't CAPS any more. Modern Ada style is lowercase for keywords and Camel_Case for everything else.

Correct, up to date version ;-):

http://en.wikibooks.org/wiki/Ada_Programming/Basic

Martin

Re:Coolest and lamest!

[sasdrtx]

I think you mean

#include <iostream>

int main()
      {
      cout << "Hello World" << eol;
      return 0;
      }

Re:Coolest and lamest!

[litghost]

Still wrong:

#include <iostream>

int main()
{
      std::cout << "Hello World" << std::endl;
      return 0;
}

Re:Coolest and lamest!

[sasdrtx]

Crap! It would pay me to run my examples before posting them.

I would have inserted

using namespace std;

instead, however.

Re:Coolest and lamest!

[Anonymous Coward]

Here is a perfectly acceptable C++ "Hello, World":

#include <cstdio>
int main()
{
  printf("Hello, World\n");
}

By the way, for those who do not know, endl manipulator is not a synonym for "\n", yet
very many books have taught that it's so-- and, for several reasons, this program isn't even close
to being legal C. Find out the truth for yourself.

The biggest problem with C++ has absolutely nothing to do with C++.

Re:Coolest and lamest!

[Anonymous Coward]

MFC makes this easier, of course, but that's C++

Having written Windows apps full time for 8 years straight (starting with VC++ 1.52 on Win 3.1), I have to disagree with this statement. MFC does not make most things easier, it just makes them different. And in a lot of ways, it makes things harder. MFC is, IMO, hugely bloated. I wrote almost entirely in straight C, direct to the Win32 API, sometimes throwing in some C++ (not MFC, just a class or two) when it was convenient (I especially like classes for keeping track of things like memory maps and global file handles, so they can clean up after themselves whenever they happen to go out of scope). Anyway, once you really understand the Win32 API, MFC seems very cumbersome. It's like the difference between a scalpel and a dull rusty butter knife. As far as the hassle of all those big chunks of repetitive code that you need just to accomplish simple things, there are many clever ways to get around that if you just put some effort into finding them early on. I've probably written at least 400 Windows apps, from small utilities to full scale distributed systems. You think I manually typed in all that WinMain/WndProc code each time? Hell no!

Also, this is just a nitpick, but non-MFC does not necessarily mean non-C++. You can easily write a Win32 app in C++, where the only things that aren't part of a class are the WinMain/WndProc, and whatever other callbacks you require.

Re:Coolest and lamest!

[Jerry Coffin]

#include <iostream>

int main()
{
std::cout << "Hello World" << std::endl;
return 0;
}

Still technically wrong. is required to declare std::cout, but it's not actually required to declare std::endl. OTOH, I believe your code should work with every real C++ compiler, even though in theory a conforming implementation of C++ could be written that wouldn't accept it.

Re:Coolest and lamest!

[Jerry Coffin]

Here is a perfectly acceptable C++ "Hello, World":

#include <cstdio>
int main()
{
printf("Hello, World\n");
}

Not really. When you #include <cstdio> you get a declaration of printf in the std namespace, so you'd need to use std::printf("..."); Alternatively, you can include <stdio.h> and get printf in the global namespace, and the remainder of your code is correct.

The standard C headers are included in Appendix D of the C++ standard, and while using them is officially deprecated, I consider it highly unlikely that they'll really be removed anytime soon at all. Even when/if they should be removed from the standard proper, I'd guess that essentially every real C++ compiler will continue to include them anyway (if only because essentially every C++ compiler is also a C compiler).

Re:Coolest and lamest!

[litghost]

You are wrong, as std::cout is defined in the header "iostream". See here. cout is an extern in the namespace std. By include-ing iostream, I have defined cout.

Re:Coolest and lamest!

[Anonymous Coward]

Well, while I am happy to see that you're sophisticated enough to quote the standard, I'm dissapointed that you immediately lapsed into going back to "the compiler is right"-- for example, my original program compiles just fine (for example, with "g++ -ansi -Wall -pedantic", although that is indeed not a way of guaranteeing standards-compliance).

In any case, I do not have the luxury of owning an expensive copy of the actual standard , but please refer to section 16.1.2 of "The C++ Programming Language", special edition (ISBN: 0-201-88954-4), and you will see that "A standard header with a name starting with the letter c is equivalent to a header in the C standard library'-- which, of course, obviates the inclusion of functions in the global namespace.

In face of this, I believe that Stroustrup's description of what should happen and g++'s actual implementation of what happens is correct. It certainly works, and by your own logic that's appearantly acceptable.

In any case, you are subverting my point about the issue (perhaps unintentionally). My point is that most C programs and C style techniques are also part of C++, and that C++ is very much misunderstood.

Re:Coolest and lamest!

[Jerry Coffin]

Please read what I actually said: you've included a declaration of std::cout, but NOT a declaration of std::endl.

Re:Coolest and lamest!

[Jerry Coffin]

Well, while I am happy to see that you're sophisticated enough to quote the standard, I'm dissapointed that you immediately lapsed into going back to "the compiler is right"-- for example, my original program compiles just fine (for example, with "g++ -ansi -Wall -pedantic", although that is indeed not a way of guaranteeing standards-compliance).

I didn't "lapse into" anything. I pointed out two separate points: one, that the code isn't technically conforming, the other that for most practical purposes it probably won't ever matter. Which viewpoint you choose to care about is entirely your own decision. Personally, I prefer to stick as close to the theoretical ideal as reasonable, but I don't let that stop me from writing code that's portable in the real world when I need to.

In any case, I do not have the luxury of owning an expensive copy of the actual standard

So get yourself an inexpensive copy. The last time I checked, you could get an electronic copy from webstore.ansi.org for something like $20 US (or so -- it was originally $18, but I seem to recall that it's gone up a little bit).

but please refer to section 16.1.2 of "The C++ Programming Language", special edition (ISBN: 0-201-88954-4), and you will see that "A standard header with a name starting with the letter c is equivalent to a header in the C standard library'-- which, of course, obviates the inclusion of functions in the global namespace.

Sorry, but that's just plain wrong. According to the standard, section D.5:

1 For compatibility with the Standard C library, the C + + Standard library provides the 18 C headers, as shown in Table 100:

Table 100--C Headers

<assert.h> <iso646.h> <setjmp.h> <stdio.h> <wchar.h>
<ctype.h> <limits.h> <signal.h> <stdlib.h> <wctype.h>
<errno.h> <locale.h> <stdarg.h> <string.h>
<float.h> <math.h> <stddef.h> <time.h>

2 Every C header, each of which has a name of the form name.h, behaves as if each name placed in the Standard library namespace by the corresponding cname header is also placed within the namespace scope of the namespace std and is followed by an explicit using-declaration (7.3.3).

3 [Example: The header <cstdlib> provides its declarations and definitions within the namespace std. The header <stdlib.h> makes these available also in the global namespace, much as in the C Standard.
--end example]

That seems pretty clear to me: by including <cstdio> you've gotten a declaration of printf in the std namespace. You could explicitly qualify the name printf (std::printf) or you could use an explicit using directive or declaration to make the name visible, or you could include stdio.h to do the same implicitly, but as it stands, your code simply isn't right, and won't work with a properly functioning compiler.

In face of this, I believe that Stroustrup's description of what should happen and g++'s actual implementation of what happens is correct.

I've been trying for years, and I've still yet to come up with a more polite way of saying: "Your logic is flawed and your conclusion erroneous." I wish I could though...

It certainly works, and by your own logic that's appearantly acceptable.

Not really. I (along with most real programmers) have to combine two viewpoints to varying degrees. One is writing code that's theoretically correct, and the applicable standard(s) gurantee will work. the other is making my code actually work in the targets I care about. From the theoretical viewpoint, I can write C++ code using export, and it's all fine and good. From a practical viewpoint, that only really works with

Re:Coolest and lamest!

[litghost]

You are partially correct, but ultimatelly wrong. endl is not defined in iostream. However, iostream must include istream and ostream because of inheritance paths. std::endl is defined in ostream. So include-ing iostream is always sufficent to get std::endl.

Re:Coolest and lamest!

[Jerry Coffin]

So include-ing iostream is always sufficent to get std::endl.

No, it's not. This problem has been fairly carefully studied, and well known in the C++ community for a long time. Nobody seems very interested in fixing it, mostly because nobody is aware of a compiler that actually breaks any code this way, and it also looks like the author would have to go to a fair amount of extra work to do it, so it probably won't ever happen either.

Re:Coolest and lamest!

[Anonymous Coward]

Thank you for your thoughtful and edifying reply. I agree with your position, and my program should be corrected
to add ".h". I also appreciate learning that I can obtain an inexpensive copy of the standard, and will do so.

I too am not for using many C-style conventions in C++, unless there is a specific reason for doing so. C++ definitely offers tools which are efficient and robust, and should in my view be used like C++ and not like C.

Regards, and thanks.

Re:Coolest and lamest!

[litghost]

Both the MSV++ and glibc++ implimentations of the C++ Standard libraries have include and/or . It is not a compiler issue no matter how you slice it. It is a header/library problem.

Stroustrups

[abshnasko]

Please... he's one of the most influential people in the field of computer science today, at least spell his name right.

Re:Stroustrups

[WilliamSChips]

No, he has nothing to do with computer science. Programming, yes, but computer science doesn't use C++.

Re:Stroustrups

[TrappedByMyself]

This site is about new spam, not accuracy, so keep your hopes down. Gems like this hidden in the muck of Microsoft bug articles (which are needed to pay the bills) still make Slashdot useful.

Re:Stroustrups

[abshnasko]

Programming, yes, but computer science doesn't use C++.

Unless you get your CS degree to try to develop a faster sorting algorithm, you are going to be doing some type of programming. He is head of the CS department at Texas A&M, to say he "has nothing to do with computer science" is ridiculous.

Re:Stroustrups

[WilliamSChips]

Programming, yes, but not in C++. Generally, Computer Scientists use languages like Smalltalk, Scheme and Haskell which aren't bundles of watered-down paradigms.

Re:Stroustrups

[EvanED]

Programming, yes, but computer science doesn't use C++.

Bull. At least sort of.

First, it depends in part on what your definition of computer science is. Most CS courses are taught in a C-like languages. At my undergrad institution, most of my programming assignments were done with C++. Sure, there was exposure to ML, but my impression is that most places that's mostly confined to the PL classes. (There are some notible exceptions that use ML or Scheme for intro courses.) Even at those institutions, I expect that later classes have assignments in a C-like language.

Second, there's a lot of CS that relates to C++. Compiler theory of how you implement things about it, and language design. It's not about C++ specifically, but it certainly relates.

Third, there is a fair bit of work in PL that directly relates. Not all PL is people in ivory towers coding in ML and Lisp. CCured is a very nice bit of work, though it's only C because it's built on top of the C Intermediate Language (CIL). There's early work now to create a CIL++, and I'm sure that it hasn't escaped anyone there about the potential to extend CCured to C++ once that's done. The parser for CIL++ will be something called Elsa, which was a major part of the research of one of the people there. My own research is indirectly related even. I'm looking at static analysis of binary code. Earlier work done in my group was explicitly directed to being able to find vtable pointers that C++ compilers produce.

You're right to the extent that the core of CS is really in some sense applied math, and is entirely language-neutral. However, to say that C++ has no relation to CS because it's just programming (which CS isn't about) is just wrong.

Re:Stroustrups

[macshit]

Actually the vast majority of recently written (last 5 years) code I've seen from CS departments (at very good schools) has been in Java, with C++ a somewhat distant second. This seems to apply across the board, from hard-core long term research projects to undergrad frameworks to quick experimental coding.

I don't particularly like java (and it's particularly painful watching the hoops people jump through to make it perform well), but while it doesn't seem to really be the best at anything, I guess on average it turns out pretty well -- it's pretty safe, pretty fast, pretty readable, pretty well supported, pretty widespread, ... One important point that many people seem to ignore is that java seems to have huge number of freely available libraries, often for somewhat specialized subjects.

The languages you mention are all great languages, and have carved out productive niches, but they seem to remain niche languages, even in academia...

[Disclaimer: I have never written a java program (!), though I have read many...]

Re:Stroustrups

[sunwukong]

Bull. At least sort of.

That's probably the most succinct description of academics, ever.

Your three points just clarified that it was CS you're specifically talking about.

Re:Stroustrups

[Nataku564]

As a bit of anecdotal evidence, I offer up my university - UW Milwaukee. All required programming courses are C++. Electives exist for most of the languages you mention, but no student is required to learn any of them. From what I hear of people I have hired from UW Madison, that school is a Java shop - again, with electives for the more obscure language.

But then, of course, this is Wisconsin we are talking about. We tend to be practical up here, and have students learn stuff they will actually use in the industry. Learning the other stuff helps with the theory, since most of them have better models - but no significant real world usage.

Re:Stroustrups

[Anonymous Coward]

Agreed.

There is also another little spoken of field of Computer Science called Systems. Many people claim that all systems research is dead, but there's really still much more to do. In systems they care ALOT about languages like C++. More recent experimental OS' like L4 are often implemented in C++ (often ignoring the bulk of the language features). PL people even are actually very interested in languages like C++. Yes they blelieve such languages are the bane of our very existant and the fact that any systems written using it work is nothing short of a miracle (a point I actually happen to agree with). But they also still have to look down occasionally at what is actually used and what does work, and figure out what bits of those systems are and aren't interesting.

Yet another huge point here is that when C++ was designed and written it really had one goal in mind, which was to bring the wonders of object orientedness to the unwashed masses of computer programming. At the time real code was written in C, Fortran, Pascal, Lisp, and Cobol primarilly. The more practical of these are very unstructured languages. C++ was an attempt to add structure to C, without breaking it's fundamental usefulness as a systems lanaguge. This was, in a very real sense, a research project. Someone invented a language and set it loose on the world to see if OOP could really hold it's own. Much to the anguish of many PL people it appears to have fluroushed in the jungles of industrial programing, but this was certainly an experiment.

Now as it happens I personally detest C++ (though I've certainly coded in it from time to time), but it's invention was most certainly well within the realm of computer science. Arguing that it's not is like arguing that Von Neumann wasn't a computer scientist because he was just an "systems guy" not a hard-core mathematician.

Re:Stroustrups

[Scrameustache]

spell his name right. Yeah, but... Couldn't he have choosen a coller alias? Like Commander Taco or something, anything but Smurf Stirrups.

Re:Stroustrups

[maxume]

itsatrap.

Re:Stroustrups

[another_fanboy]

One important point that many people seem to ignore is that java seems to have huge number of freely available libraries
The biggest argument I have against C++ is the disorganization of the libraries. Having used Java, I find them (generally) well structured and easy to use with minimal previous experience required. I will admit, however, that the libraries often feel bloated in their generality.

Re:Stroustrups

[Anonymous Coward]

Generally, Computer Scientists use languages like Smalltalk, Scheme and Haskell which aren't bundles of watered-down paradigms.

Serious ones, sure. Most CS students just want a programming degree so they can get a job. They're not really serious computer scientists.

Re:Stroustrups

[Anonymous Coward]

That's education, not research. Computer science gets done in a variety of languages. Everything from asm on up gets used. C and C++ included. To say that "computer science doesn't use C++" is incredibly ignorant. Plenty of evidence to the contrary. Not that it's entirely relevant, but keep in mind that a lot of computer scientists don't write

Re:Stroustrups

[mrchaotica]

You know why schools teach Java instead of C++? So they don't have to teach pointers first. At least that's how it seems to work at Georgia Tech...

Re:Stroustrups

[oldhack]

Computer science is an applied math where programming is essential. If you can't program a computer, i.e., there is no programming, CS should just be a sub discipline within math dept (mechanized math?).

Re:Stroustrups

[Watson Ladd]

Penicillin. Lisp. BSD. Shannon's information theory. Smalltalk. The Web. The Internet. All of these came out of academia. Saying that academia is bull is saying that pure research counts for nothing. Well, look at number theory. Once considered unsullied by practical applications it now is used in cryptography. The atomic bomb started as pure research.

Re:Stroustrups

[cnettel]

Well, you really can get away get quite well without using pointers in C++. It won't be fast, it won't always be pretty, but you really can write non-trivial stuff with only references and STL containers doing the allocation. What's really hard is to do C++ without both pointers and non-trivial use of templates...

Re:Stroustrups

[rolfwind]

Arguing that it's not is like arguing that Von Neumann wasn't a computer scientist because he was just an "systems guy" not a hard-core mathematician.

Um, Von Neumann was a hard-core mathematician.

Re:Stroustrups

[Durandal64]

Why don't we just dereference him and call him 'B'?

Re:Stroustrups

[abshnasko]

Not sure what schools you're looking at, but I'm an undergrad at Virginia Tech (pursuing a CS+Math double major) and Java is only taken at the introductory level. After that it's mostly C++, some Perl, and whatever else we want to use to complete a project.

Re:Stroustrups

[Anonymous Coward]

There's early work now to create a CIL++, and I'm sure that it hasn't escaped anyone there about the potential to extend CCured to C++ once that's done. The parser for CIL++ will be something called Elsa, which was a major part of the research of one of the people there.

Do you have a source for this? I've followed the CIL mailing list for awhile, and I thought that project was scrapped awhile ago. Some of your previous posts sound like you go to Berkeley. Maybe you have some inside info?

Re:Stroustrups

[WhoBeDaPlaya]

I love this style. Just makes it all the sweeter when the other kids get WTF pwned in the junior level embedded programming class ;)

Re:Stroustrups

[EvanED]

Some of your previous posts sound like you go to Berkeley.

Hah! I wish. Berkeley was my top choice when I was applying to grad schools, but they didn't like me apparently. I'm at UW Madison now, which is still a fine school, and it's very nice. (Albeit a bit cold for the past couple weeks.)

Do you have a source for this? I've followed the CIL mailing list for awhile, and I thought that project was scrapped awhile ago.

Like I said, I don't go there, so I'm quite removed from what's going on. That said, I'll tell you what I know. I'm working on a project right now that uses Elsa, so I've been in correspondence with the people behind that a little bit. The prof in the class this project is for is a recent Berkeley grad (like a couple years ago) and said that there was some effort on this a while ago, but it was scrapped, so this is probably what you are referring to. I'm looking back at the email that talked about this, and I think saying there's early work might have been a little premature actually; but it's definitely still on the radar there.

First, I should give a little background. Scott McPeak, a (former now I think?) grad student there, has a Generalized LR parser called Elkhound which at least sounds quite fancy. (I don't know enough about parsing theory and grammars and such.) He used that to create a C++ front end called Elsa. This has been sort of slurped up under the umbrella of a project called Oink, which is overseen by Dan Wilkerson and Karl Chen. Elsa development is continuing under that heading, though it seems that Scott McPeak has little time for it now. The idea behind Oink is to provide platform for different static analysis tools for C++. Right now it's essentially a C++ version of CQual (which is another project out of Berkeley, this time by a guy named Jeff Foster).

[The poster I'm replying to can skip this paragraph.] CIL is an abbreviation for C Intermediate Language, which is in some sense a simplified form of C. (Many kinds of operations are "lowered" into other forms to reduce the number of constructs that one has to analyze. For instance, all loops are changed into "while(1) { ... }" with an if statement and a break to leave.) But what it really is is a set of OCaml bindings to reference the above simplified form of a program. Tools can then implement a static analysis off of this (I think CQual falls in this category) or do transformations of the ASTs and then pretty-print it back to source form (CCured is in this category). CCured is a source-to-source C transformation that inserts memory safety checks in locations that it can't statically prove safe. I forget who is behind these projects, but you can Google them as easily as I can. (They are out of Berkeley. ;-))

[Finally, to complete the "these are from Berkeley" bit, the project that I'm working on with Elsa is extending the Cooperative Bug Isolation (CBI) project to being able to use C++. CBI is the brain child and (ACM award-winning) dissertation of Ben Liblit, who wrote his C source-to-source transformation using CIL while he was a grad student at Berkeley, and he's now my prof.]

Now... with all that setup, I actually have surprisingly little to say. Point being is that the Berkeley crowd is still interested in creating a "CIL++"-like think. Dan Wilkerson and Matt Harren are starting to put together a way to create OCaml bindings to the ASTs that Elsa generate. At least an eye is cocked towards a CIL++, though I think their aim is bigger than that. From the relevant email:

Several different groups are all interested in an OCaml way of relating to the Elsa AST
and possibly Typesystem as well. The Mozilla guys want to use it as an AST query language and here at Berkeley there is a group that wants to do program analysis in OCaml on C++ (think CIL++). I want one solution to all of these problems. Mat Harren, a grad student here, and I just spec-ed out a solution that seems like it will work.

I

Re:Stroustrups

[sydneyfong]

The downside is that you'll have to explain what " public class " is. What " public static void " means.

The best intro language remains to be pascal. I don't know why people get so fed up with it. Sure it's not as powerful or as popular as C/C++/Java, it's a bit verbose, but the language is clean and readable.

Re:Stroustrups

[diegocgteleline.es]

In other words, they create barbie programmers....

Re:Stroustrups

[Ed Avis]

Yet another huge point here is that when C++ was designed and written it really had one goal in mind, which was to bring the wonders of object orientedness to the unwashed masses of computer programming.

Er, where did you get that from? I don't think Stroustrup ever said anything like that. See this interview for example:

Stroustrup: My main aim with C++ was to be able to express ideas directly in code and have that code execute with close-to-optimal performance. In other words, to write programs that were both elegant and efficient.

Really, the object-oriented part of C++ is not the most important. More useful is the support for generic programming and efficient, type-safe libraries. I do recommend you read The C++ Programming Language, which is to C++ what K&R is to C. The object-oriented stuff with classes and inheritance isn't introduced until quite late in the book. It's a mistake to characterize C++ as 'C with classes', although it might have started out as that in the very beginning.

Re:Stroustrups

[CptNerd]

And all of us old farts call it "job security"...

Re:Stroustrups

[mrchaotica]

Junior level? No, pointers come in the third CS class, which for any self-respecting CS major is taken first semester of sophomore year. At Tech, the progression for CS majors goes "Python->Java->C" (although when I was doing it, it went "Scheme->Java->C" instead). For everybody else (i.e., engineering students) it goes "Matlab->Java," which is unfortunate because I think Scheme did a better job of teaching fundamental programming concepts than Matlab.

Re:Stroustrups

[Anonymous Coward]

I hate to disagree with you but until C++ takes care of the reference of a reference problem some things are going to be really difficult.

The STL rocks but not enough people know about it. I had to read The C++ Programming Language, 3rd Ed. to found out about the STL. There is more STL literature today but doubt there is much STL education. A darn shame.

Re:Stroustrups

[mrchaotica]

I didn't say they used Java as an intro language; by the time students learn Java they've already had a semester based on either Python or Matlab.

Now, a really good intro language is Scheme (which is what was taught before the switch to Python and Matlab). IMHO, it's best to instill the idea of programming without side-effects early, and Scheme does a much better job of that than imperative languages like Python, Matlab, Java, or C.

Re:Stroustrups

[Anonymous Coward]

Or, as Edsger Dijkstra was purported to have said. "Computer Science is no more about computers than astronomy is about telescopes."

Re:Stroustrups

[davidgay]

The project you are all looking for is Oink: http://www.cubewano.org/oink

David Gay

Re:Stroustrups

[JabberWokky]

Yet another huge point here is that when C++ was designed and written it really had one goal in mind, which was to bring the wonders of object orientedness to the unwashed masses of computer programming. At the time real code was written in C, Fortran, Pascal, Lisp, and Cobol primarilly.

I followed the development in his columns, and the object oriented part of C++ was only one of many extensions to the language he was trying to create. If you list them all, most have nothing to do with being object oriented. C++ code can be written perfectly nicely with no object oriented features, and those that do exist are a subset intended to be the most useful parts (and I personally think it was influenced a bit by what could be compiled using Cfront).

Your other comment is amusing too... at this time (i.e., late 2006), quite a bit of real code is still written in C and Fortran. My fiance does all her quantum simulations using maintained and fairly new Fortran codebases. But then your comment is logically obvious: of course those were the languages that were used. Few people were using Ruby, Python or PHP in the 80s. (And if you're trying to list non-OO languages, Smalltalk and Lisp had already had their orgy and Lisp had contracted OO capabilities from it before C++ came along).

--
Evan

Re:Stroustrups

[WilliamSChips]

In other words, to write programs that were both elegant and efficient. And yet C++ comes out as neither.

Re:Stroustrups

[Anonymous Coward]

That's a pretty bad list of academic programming language examples (this is a programming language thread after all). Lisp and Smalltalk are to this day pretty much limited to academia and other fringe groups.

Re:Stroustrups

[Anonymous Brave Guy]

You know why schools teach Java instead of C++? So they don't have to teach pointers first.

Yes, the world will truly be a better place when it's full of people who use pointers all the time, without appreciating the significance of what they're doing, the ways to take advantage of it, and the pitfalls to avoid...

For reasons I've never quite understood, the CS department where I studied also used Java in its introductory programming courses. This is odd, given that the department in question is a focus for programming language research, particularly in the area of functional programming, and that the researchers are not known for being shy in criticising mainstream programming languages. Since the Java courses were lectured by someone not very good with no research responsibilities, I've always assumed that the syllabus for introductory programming was someone considered beneath the research staff, and they just hired someone else to get on with it.

Re:Stroustrups

[Anonymous Coward]

And the worst... Psudocode. Making smart kids stupid. I personally like Python.

Re:Stroustrups

[sasdrtx]

Well, in my day it was Fortran, System/370 Assembler, PL/I, Survey (APL, Algol, Lisp, SNOBOL), then hardware design and math for the 1st three years. Never heard of C, and I don't think C++ was out of Bjarne's skull yet.

Ironically, this was Texas A&M.

Re:Stroustrups

[scotch]

I love your unabashed and stubborn ignorance in this thread. This statement:

And yet C++ comes out as neither.

is of course untrue. But hey, keep whacking at the C++ windmill; your comments are saying more about you than they are about C++ or any other language. Thanks for the continued entertainment.

Re:Stroustrups

[The_Wilschon]

I notice that you said that all required "programming" courses are C++. That is precisely right. C++, Java, C, Python, Perl, and friends are used for programming. However, programming and computer science are not really the same thing. Computer science is properly a branch of mathematics (See Turing, Von Neumann, Chaitin, Church, etc). The name is far more frequently whored out to give artificial gravitas to a programming training course, however. The world really requires surprisingly few actual computer scientists, and far far more programmers. However, a thorough understanding of computer science tends to make for better programmers.

Re:Stroustrups

[try_anything]

Historically, object orientation was the raison d'etre for C++. Stroustrup liked Simula's class concept and the way it allowed him to structure programs, but his effort to use Simula in a large project failed because its performance was too poor. He decided that Simula was inherently inefficient and could not be implemented efficiently, so the next time he encountered similar requirements, he started extending C.

The GP was wrong when he said Stroustrup wanted to bring OO "to the unwashed masses" -- Stroustrup wanted to bring OO to himself and other AT&T engineers who needed performance characteristics similar to C. Their only motive in making the language popular was to make the language self-supporting.

Re:Stroustrups

[Kupek]

Stroustrup's original goal was for a language that allowed OO programming and was still suitable for serious systems programming. I think he makes that clear in The Design and Evolution of C++. And are you aware that the original name was, in fact, C with Classes?

Re:Stroustrups

[bored]

The best intro language remains to be pascal. I don't know why people get so fed up with it. Sure it's not as powerful or as popular as C/C++/Java

I'll buy part of that for $1. Pascal is probably the cleanest language I have ever used, Object Pascal is probably the cleanest OO language I have ever used (part of that may be my bias towards borlands VCL, stuff just worked the way it should). I would say that Object Pascal is more powerful than C (C's strengths in low level stuff _can_ be achieved in pascal with a tiny bit more work, and the OO in OP is way more powerful than anything in C). OP is less powerful than C++ (due to generics and some other stuff), and more powerful than Java although its close.

In the case of java the recent addition of lightweight generics give it a plus there, but its lowlevel support is for shit (aka DNE), and I've found the dynamic nature of java to be misused the way weak typechecking and multiple inheritance in other languages is misused. By this I mean that if you find yourself needing weak typchecking, or multiple inheritance you had better start wondering about the structure of your algorithm/program. Then there is the java one true way which makes everything a nail to be attached with your nailgun. So OP wins in my book.

I can understand the switch from pascal to C++, that was due to industry pressure, why teach a language no one uses, just teach people C++ and hopefully they will get around the gotcha's. But java? Jeeze java had a big bandwagon, but I have never really seen the advantages, a reasonable look at the language soon determines that all of its strong points are either stronger somewhere else or are masked by some other critical issue in the language. Seems to me the people calling themselves "software engineers" are still using C/C++, the people calling themselves "programmers" can't quite settle on a language and at the moment C# seems to be winning (a language that has more credibility than java in my book, it has some serious strong points).

Re:Stroustrups

[DuckDodgers]

I keep meaning to learn the STL and keep putting it off. (I do Java programming at work, for now, so it's not an issue.) Thanks for the reminder.

Google's in C++?

[feijai]

My understanding was that much of Google was in python.

Re:Google's in C++?

[say]

Googlebot is mainly written in Python. Google is mainly written in C/C++.

Re:Google's in C++?

[Marcos Eliziario]

No, not the data-crunching engine, not the indexer, not the ranker.... Python (and java, and ruby) is cool, but, frankly... sometimes you need the most of your hardware.

Re:Google's in C++?

[abshnasko]

How could something that large and efficiency-dependent be written in non-native code?

Re:Google's in C++?

[Anonymous Coward]

This is a common misconception that is usually toted out by the Python crowd. So far, Google uses Python primarily for small scripts and a couple of simple applications that are internal to the company. Everything that is of any significance is written in C, C++ or Java. C and C++ are usually used for stand alone applications and systems programming, while Java is used for the back end for most of their web applications.

Re:Google's in C++?

[j3richo]

Greg Stein has said there is more Python code in Google than Java during one of those Q&A at Pycon, so it's not accurate to say it's only used for small stuff.

Re:Google's in C++?

[LauraW]

What I usually say when interview candidates ask about this is that back-end and data crunching code tends to be C++, web GUI front-end stuff tends to be Java and Javascript, and scripts tend to be Python. Whatever tool works best for the job. It's not much different from what I've seen at other jobs, except for using Python instead of something like Perl. But there are no hard and fast rules. For example, there was a slashdot article last week about an internal web app written in Python. Here's an older article that talks a bit about Google's philosophy for choosing tools. There are various articles on Google technologies floating around on the web site too. Before anyone asks, I have no idea what the relative size of the code base in each language is.

Disclaimer: I work for Google.

Re:Google's in C++?

[chris_mahan]

Maybe java is used for even smaller stuff?

j/k

Re:Google's in C++?

[dubbayu_d_40]

Continous/adaptive compilation. Like Java Hotspot.

Re:Google's in C++?

[Anonymous Coward]

No Google bot is written in C++
http://www.robotstxt.org/wc/active/html/googlebot. html

When you need high performance, C++ is better choice than any other language. Google(or Yahoo) wont have a single language framework to run its platform. Always it will be combination of languages. Whatever have I read so far Google's core search engine is in C++ and several C++ libraries are available as python modules. Standalone products may be written in specific languages. Gmail and Google Calender are written in Java.

Re:Google's in C++?

[AuMatar]

While those techniques are better than pure interpretation, they're still a good 40% slower or more than native code.

Re:Google's in C++?

[IamTheRealMike]

There are at least two reasons why GoogleBot isn't written in Python. Firstly it's a very large and complex piece of code. Anecdotally, for very large codebases a statically typed language like C++ seems to work better with respect to allowing many developers to work together, because it requires and allows you to specify interfaces in a checkable way. Secondly it's performance sensitive. Your suggestion of continuous/adaptive compilation doesn't work because the resources that are used to redundantly compile/optimise a program "in flight" many times for each machine/run of the program could be better used to, say, crawl the web. Generally, it's much more efficient to compile something once on a developers machine and let the compiler ponder the program as a whole, then upload the finished result to the machines.

Re:Google's in C++?

[Anonymous Coward]

Disclaimer: I work for Google.

Are you getting a kick out of these replies?

Re:Google's in C++?

[Chandon Seldon]

That's benchmark-dependent. For some benchmarks, under some circumstances, you can generate faster native code during execution than a traditional compiler would generate beforehand.

Re:Google's in C++?

[LizardKing]

When you need high performance, C++ is better choice than any other language.

Bullshit, C is. Assembler (just for the pedants) is too labour intensive and platform specific to be a good choice. With C++, lots of the features that on the face of them seem to be improvements over C, are in fact far less performant than C. Consider the "one size fits all" and implicit copying of the STL, or the brainfuck that is the iostream library once you actually want to format something.

Re:Google's in C++?

[Anonymous Coward]

I missed to add maintainability in the comment. Assembly and C gives you better performance than C++. But how is the maintenance of the code ? Assembly would be a nightmare for complex programs like Google Search and Googlebot. Due to Object Oriented concept, C++ beats out C in terms of maintainability and easier understanding of the code.

iostream library once you actually want to format something.

Comeon you judge a language based on a particular functionality of a library. If you are not happy with a library, write your own library something like google done for malloc.Anyway most of the complex programs run in the background dont need to generate output other than log files.

Re:Google's in C++?

[LauraW]

Are you getting a kick out of these replies?

It is sometimes entertaining having an inside perspective when there's so much speculation floating around. The same thing has happened when I've worked for other companies that occasionally made the news, so it's not unique to Google, but it's more frequent.

I occasionally try to chime in and correct things. But I know fairly little about what's going on in most parts of the company, so I often don't know what's confidential and what isn't. Most of the time I just play it safe and keep my mouth in order to avoid putting my foot in it.

Re:Google's in C++?

[bored]

When you need high performance, C++ is better choice than any other language.

Bullshit, C is.

Not to get into a holy war here, but please show me a program for which your C compiler generates better code than the equivalent C++ compiler does on the same code. For the same code its generally the same damn thing, C++ is just more tools in your toolbox. You don't have to use the extra crap in C++ unless you have a reason. I use C++ exclusively (vs C, I use lots of other languages too, just not C) because it reduces problems with C when used properly, and it provides some powerful constructs that are hard to simulate without a lot of extra overhead in C. There are dozens of cases that short of writing 100x as much code in C, simply cannot be matched for performance. I would like to see your implementation in C of a matrix library that supports a dozen element types ranging from simple ints, floats, vector types to arbitrary precision math that matches what can be done with a template class.

There are gains in everyday tasks as well, C++ exceptions can significantly speed up business logic type code by removing thousands of "if (error)" checks, on some architectures virtual methods are faster than C function pointers in structures, the list goes on. Of course i'm not a purist, I use lots of calls to sprintf, some things are better in C++ syntax some are better in C, I like to have the choice.

Re:Google's in C++?

[LizardKing]

Err, I pointed out that Assembler is not a good choice. As for maintainability, C++ often loses out to C because of inheritance. I find that I often have to dig through layers of it to find the method that I'm looking for, having first ascertained which class to start from (which of course depends on the type of the pointer used to call the method).

As for writing my own I/O library, if I'm forced to use C++, then I usually fallback on C stdio as there is inevitably a call to synchronise the two in the code already. Then all I need to do is reimplement realloc using a templated function, and I'm cooking with gas. It woul still be better if the C++ library was an improvement over the C one, rather than being incomplete, incompatible and a pain in the arse to use.

Re:Google's in C++?

[LizardKing]

Of course the compiler doesn't generate equivalent code for a C program and a C++ one, unless your simply compiling C with a C++ compiler because your platform doesn't provide a C one. For starters, there's name mangling and vtable lookups which bloat the code and slow it down. Then there's the overhead of the STL if you're using it. As a quick test, I wrote two programs with equivalent functionality in C and C++. They both use a hand coded linked list, with the C++ one implemented as a class. The compiled C++ code is 44% bigger than the C code (the STL wasn't used in the C++ code nor were excpetions, however the iostream library was used) and in a timed test run the C++ code is 21% slower.

Re:Google's in C++?

[bored]

Name mangling doesn't slow the code down, thats a linker problem... Vtable lookups arn't there unless you use virtual methods, C code calling through function pointers is just as slow. Its not an apples to apples comparison. The point is that you _CAN_ compile C code with the C++ compiler, and then sprinkle C++ where it helps. That is why C++ is not slower than C, sure you can write C++ code that is slower than C if you choose to, I can do exactly the same in the converse with proper use of C++, of corse the slower code will probably compile in the C++ compiler as well so the whole argument is bogus. That is why its just plain stupid to say that C++ is slower than C, because C is a subset of C++.

Re:Google's in C++?

[Jerry Coffin]

When you need high performance, C++ is better choice than any other language.

Bullshit, C is.

I have to disagree. Essentially any C code can also be written as C++ with essentially no modifications, short of possibly minor changes in spelling (e.g. if the C code happened to use 'class' as a variable name). The reverse is not true, however -- it's entirely possible to write things in C++ (e.g. using templates) that really have no direct counterpart in C.

Some of those give considerable opportunity for optimization that's (at best) considerably more difficult in C. An obvious example would be sorting. The C library includes qsort, which allows various forms of comparison by using a pointer to a function. The C++ library includes std::sort, which is a template that accepts a name of a comparison function/functor as a parameter. This may initially seem like a trivial distinction (name vs. pointer) but, in fact, makes a huge difference -- in particular, it frequently allows the compiler to generate the comparison code in-line instead of calling a function via a pointer to do each comparison. Since the comparison itself is often quite trivial, the call via a pointer often adds a great deal of overhead -- to the point that in my experience, std::sort is typically at least twice the speed of qsort (I'll attach a bit of benchmark code to the end of the message for those who care to test with their compiler).

While it has taken a fair amount of work, libraries like blitz++ include many more optimizations like this. While the code to implement them isn't always the most readable, the library is relatively easy to use, and the code that uses it is quite readable.

Consider the "one size fits all" and implicit copying of the STL

I'm not sure exactly what you mean by 'one size fits all', so it's hard to reply to that. Its' true that the containers in the standard library are written with the assumption that copying is relatively cheap. Fortunately, you can essentially always provide for that, since you can use a smart pointer with cheap copying and value semantics on the (IME relatively rare) occasion that copying the object itself causes a performance problem. Given that C simply lacks any counterpart of the C++ standard containers, it's difficult to compare C to C++ in this respect, but my own experience indicates that more often than not, C code that had hand-rolled containers gets faster when converted to C++ standard containers.

[...] or the brainfuck that is the iostream library once you actually want to format something.

This is a matter of verbosity of the code, not performance. Unfortunately, although you didn't point it out, most implementations of the iostream library really do have performance problems. Fortunately, that is strictly the library, not anything inherent to the language though. The problem arises primarily from the fact that the iostreams library has a couple of virtual function calls in the critical path. The flexibility this adds is considerable, but few programmers are aware of it, or attempt to take advantage of it, and this is one of those rare cases where you really do pay a price even when you don't use the feature.

In fairness, however, I should point out that this is an area that almost certainly could be improved considerably. Technical report 1 on the C++ language, a number of techniques that would almost certainly improve performance in this area, though I'm not aware of a full library that actually implements those techniques.

Getting back to your original comment about formatting, it's entirely possible to create a formatting class that allows you to set up a complex format, and then when you want to use that format, you simply apply the format as a whole to the stream instead of setting flags individually. While I've never attempted to write a parser

Re:Google's in C++?

[LizardKing]

Firstly templates. They are just void pointers with type safety. While that safety is a very nice thing to have, it does have performance costs. The thing is, in practice the overhead of the type checking is superfluous as very few bugs are down to bad casts in functionally similar C code. And while I'm considering performance, despite another poster claiming it's a linker issue, vtable lookups do impact performance regardless of whether you blame the linker or the compiler. The language requiring something like vtable support is the real culprit, excacerbated by the debatable way that C++ handles method resolution. In Java, if I call List.get() on an object that is actually an ArrayList, I get the ArrayList version of the method - the most derived one - not the List implementation. In C++, I get the List implementation (this ignores the fact that List is an interface in Java, but you should get the gist of what I'm saying). In practice, the C++ way of doing this is counter intuitive, despite the fact that the C++ way seems more logical from a syntax point of view.

As for the inlining of sorting code, in a test I just ran the sorting function was inlined in a C example just like the use of std::sort() you described. The difference is that my sort resulted in far less assembler instructions than the C++ std::sort() one, although I did have to spend an extra couple of minutes copying the sort code from a Sedgewick book.

Finally, the iostream library. I spent part of this afternoon refactoring a loop that was proving to be a bottleneck in some C++ code. It relied on ostringstream to turn an unsigned integer into a string, and then passed the std::string representation to be added to an STL list. I refactored the code to use malloc (having determined the number of decimal digits in the number) and snprintf, then passed the C string to be added to the list. This resulted in a roughly 20% speedup, despite the malloc calls. The reason being that the ostringstream had to be allocated on each pass of the loop, as it provides no means I can see to effectively "flush" it at the end of each pass. Yet another reason the C++ iostream library is a pain in the arse. Switching to a minimal hand coded list class (something that I'd be suprised if many experienced programmers don't already have to hand), resulted in a further speedup of around 5%.

Re:Google's in C++?

[Jerry Coffin]

Firstly templates. They are just void pointers with type safety.

This is thoroughly wrong it's hard to keep my reply polite. You'd be roughly correct about the generic support in Java, but about C++ templates, your statement is completely, totally and thoroughly wrong. I can't do anything approaching justice to the subject here, but I'd recommend reading Modern C++ Design by Andrei Alexrandescu, to at least start getting a clue about how much more there really is to templates. You might also want to look at the source code to The boost library for more along the same general line (e.g. take a look at boost Lambda, which is quite different from anything you can do with void pointers.

The thing is, in practice the overhead of the type checking is superfluous as very few bugs are down to bad casts in functionally similar C code.

Sorry, but no. The type-checking is done at compile time, so it doesn't impose any overhead (at runtime -- in theory it makes for slightly longer compile times, but in practice the difference is rarely noticeable.

And while I'm considering performance, despite another poster claiming it's a linker issue, vtable lookups do impact performance regardless of whether you blame the linker or the compiler. The language requiring something like vtable support is the real culprit, excacerbated by the debatable way that C++ handles method resolution. In Java, if I call List.get() on an object that is actually an ArrayList, I get the ArrayList version of the method - the most derived one - not the List implementation. In C++, I get the List implementation (this ignores the fact that List is an interface in Java, but you should get the gist of what I'm saying). In practice, the C++ way of doing this is counter intuitive, despite the fact that the C++ way seems more logical from a syntax point of view.

The performance of a virtual function in C++ (at least with most recent compilers I've tested) is essentially the same as the switch statement or pointer to a function you'd have to use to get the same functionality in C. The problem arises primarily from the fact that people often use virtual functions where they're not really suitable.

The differences between C++ and Java tend to get sufficiently religious quickly enough that I'll stay away from discussing that, at least for now.

As for the inlining of sorting code, in a test I just ran the sorting function was inlined in a C example just like the use of std::sort() you described.

I specifically talked about using qsort. Obviously, you're not doing that. It's nearly always true that more specialized code can be more efficient than more generalized code. The trick is to write generalized code that retains close to the efficiency of the more specialized code -- and C++ does a better job of that than C does.

The difference is that my sort resulted in far less assembler instructions than the C++ std::sort() one, although I did have to spend an extra couple of minutes copying the sort code from a Sedgewick book.

Counting assembly instructions gave a useful of speed in the days of 68Ks and 8088s. Those days are long gone. Given that it came from a Sedgewick book, your code may easily be substantially slower ( I'm not a fan of Sedgewick).

Finally, the iostream library. I spent part of this afternoon refactoring a loop that was proving to be a bottleneck in some C++ code. It relied on ostringstream to turn an unsigned integer into a string, and then passed the std::string representation to be add

Re:Google's in C++?

[LizardKing]

> Firstly templates. They are just void pointers with type safety.

This is thoroughly wrong it's hard to keep my reply polite. You'd be roughly correct about the generic support in Java, but about C++ templates, your statement is completely, totally and thoroughly wrong. I can't do anything approaching justice to the subject here, but I'd recommend reading Modern C++ Design by Andrei Alexrandescu, to at least start getting a clue about how much more there really is to templates. You might also want to look at the source code to The boost library for more along the same general line (e.g. take a look at boost Lambda, which is quite different from anything you can do with void pointers.

A colleague at work loaned me the Alexrandescu book, and while it's got some neat tricks in it, they're hardly what template support was originally intended to be used for. As I recall, even the book acknowledges that in the preface. It left me with a feeling of "neat, but it's a hack all the same". However, if you've mastered these ideas sufficently that they can be used productively, then I'm very happy for you. As for boost, I'm well aware that it's the testing ground for yet more fluff that will make its way into a future C++ standard. A classic case of ignoring the fact that C++ needs to go and diet, and chucking more "paradigms" into it instead. No wonder compiler writers are complaining that its nearly impossible to write a standards compliant C++ compiler - just getting the parser right is a nightmare, let alone trying to write a good intermediate code generator.

Can you imagine the world without the Web?

[Larry Lightbulb]

Why try to imagine it, can't we just remember it?

Re:Can you imagine the world without the Web?

[Skim123]

I remember back when I was a young lad, and the only access to pornography we had was through a friend's dad's discovered "collection", or, in some less proud moments, the Victoria Secret's catalog. Kids today don't know how good they have it.

Re:Can you imagine the world without the Web?

[csguy314]

Why try to imagine it, can't we just remember it?

Maybe you can. Some of us aren't that old... or have ingested massive amounts of memory modifying substances.

Re:Can you imagine the world without the Web?

[yoprst]

Mod parent insightful!

Re:Can you imagine the world without the Web?

[sgt_doom]

Hmmm...so you're saying they don't understand life in pre-Google times...

This line explains a thing or two

[gangien]

I do not believe that a paradigm completely replaces previous paradigms in one revolutionary moment (or "shift"). Instead, each programming paradigm adds to what worked previously

I think that line explains a thing or two about C++..

He then goes on to say that Java and C# go on to further this, and I don't believe that. Java (and my C# experience is limited, but I believe it applies to C# as well), does not augment C/C++. In fact wasn't it originally called C++-? Java did shift the paradigm, and as a java developer, I am thankful.

Re:This line explains a thing or two

[WilliamSChips]

Remember that you're talking about a guy who thinks that if something is designed correctly then it becomes stillborn.

Re:This line explains a thing or two

[gangien]

I should probably add that i 100% agree with this statement

I think that would be misguided. The idea of programming as a semiskilled task, practiced by people with a few months' training, is dangerous. We wouldn't tolerate plumbers or accountants that poorly educated. We don't have as an aim that architecture (of buildings) and engineering (of bridges and trains) should become more accessible to people with progressively less training. Indeed, one serious problem is that currently, too many software developers are undereducated and undertrained.

Very interesting read all together!

Re:This line explains a thing or two

[Timesprout]

Java and C# dont really augment c++. I think what Bjarne meant was they have augmented the programming paradigm in the sense that developers are able to focus more on adressing the problem space rather than the nitty gritty implementation of the the solution.

Re:This line explains a thing or two

[cryptoluddite]

I guess he's never heard of Home Depot or Lowes. The basic idea behind those stores is that yes people can be their own plumber, electrician, mason, handyman, etc, for many basic tasks and that people want these things to be more accessible to them. Millions of people can write things in Java or its kind without lots of training and expertise.

This must be threatening to Bjarne for some reason. I submit that it is only in C++ where even a few months training is dangerous.

Re:This line explains a thing or two

[MBCook]

No kidding. Doesn't that call to mind half the programs you've seen written in VB and such? They may work for prototyping, or a little app for a small business, but you start scaling them up and those kind of things become disasters. I agree COMPLETELY with he statement that we have too many "programmers" who can't program right now. A large chunk of my job (as a programmer) is integration with other people's systems. And while I can tell you our system is hardly perfect, it looks like a panacea of brilliance compared to some of the things I've run across.

Re:This line explains a thing or two

[MoralHazard]

Ooh, but your analogy can extend! Sure, I can go down to Home Depot and buy some interior paint to spruce up my living room, or some 2x4s to build a new deck, or something like that. But have you ever heard of building inspections? Anytime you do serious work, like an addition or a new building or even heavy electrical, you're probably going to have to get permits, submit plans, and then have a licensed building inspector come out and check your work. And it if ain't done to code, you're going to have to rip it all out and hire somebody who know what they're doing.

The reason behind all this bureacratic, intrusive government oversight is that building codes are written in blood. Code specs have emerged over time because people died when buildings collapsed, or bad electrical wiring caused fires. The lesson is that if you're not doing something that could cause injury or death, go ahead and do it yourself. If not, you'd either better learn the right way to do it or hire somebody.

Code divides into similar categories, although I the decision point is different: Is the failure of this application tolerable? It may be a question of lives at risk (avionics, air traffic control, miliary systems, automotives braking/control, medical) or it might just be economic (my business stops and I lose money when our servers bug out). It's only prudent to analyze your situation and come to a rational decision about whether you want to tolerate the risks of hiring professionals (or learning professional methods and implementing them yourself), versus playing pickup ball.

Having lived through a couple of start-ups, both successful and unsuccessful, I can tell you that the different approaches do make a difference. I think that's what Bjarne is getting at: if the application matters, you'd better do it right.

Re:This line explains a thing or two

[Anonymous Coward]

Having lived through a couple of start-ups, both successful and unsuccessful, I can tell you that the different approaches do make a difference. I think that's what Bjarne is getting at: if the application matters, you'd better do it right.

True, but there are huge classes of applications which are tremendously useful, for which a failure is tolerable, and which are relatively easy to write. So I strongly favor the existence of languages which allow people to write code with only a few months training. And as a professional software developer/computer scientist, I don't feel threatened by it - I wouldn't want to write those applications. When they need something more complex or more robust, they'll come to me.

Re:This line explains a thing or two

[oldhack]

That's a very self-serving argument - I'm assuming you're a programmer. There is a programming and there is a programming. Consider programming life-support system vs. programming your powered car seat. Why should my wife have to get an MS in CS to program her car seat? Or why should a financial analyst, to do their what-if analysis? It make sense that my wife only need to know the sequence of the buttons, and the finanacial analysts their Excel macros, do their jobs.

Re:This line explains a thing or two

[imaginaryelf]

Actually, when lame programmers all over the world has made a total mess of things using that weak language, people will call on you to clean up his shit. Yes, they'll pay you more, but is that really worth your while?

Re:This line explains a thing or two

[Fulcrum of Evil]

I believe that for $75/hr, I can overlook a lot of bad code/design. Actually, I'd be happy to clean up messes for that rate (possibly more if it's really horrendous). The only real condition is that I be allowed to actually fix things, and the management can't act as though it's my fault. Naturally, we set the deadline after an initial evaluation and negotiation over the scope of the work.

Re:This line explains a thing or two

[gangien]

yeah after rereading that I agree with you and the AC below.

Re:This line explains a thing or two

[kraut]

> Remember that you're talking about a guy who thinks that if something is designed correctly then it becomes stillborn

So that's why the whole world is programming in Simula, Smalltalk and Lisp ;)

The key constraint in C++ design was maintaining backward compatibility with C. That was one of the key factors in its success, but also one of the key source for its problems.

Re:This line explains a thing or two

[WilliamSChips]

So that's why the whole world is programming in Simula, Smalltalk and Lisp ;) On the other hand, notice how quickly Python and Ruby grew. Admittedly they're not as 'clean' as Smalltalk or Lisp(both of which are used in surprising places--I'm pretty sure most of your car companies use Smalltalk for some pretty important stuff) but they're fucking god compared to C++, Perl, and Java.

Re:This line explains a thing or two

[try_anything]

Remember that you're talking about a guy who thinks that if something is designed correctly then it becomes stillborn.

Only if your definition of "correctly" is a very limited one. Stroustrup had an idea of what problems the language should be useful for, he made himself intimately familiar with the burdens and obstactles faced by people solving those problems, and he labored very hard to make sure that his target users would actually be able to use C++. If you think those things have nothing to do with good design, then you probably think sod skyscrapers and fur swimsuits are a good idea.

The bottom line is that C++ was not meant to be a proof of concept or an objet d'art. Wishing away C++, if it were possible, would not make it any easier to apply "better" languages to practical problems.

Re:This line explains a thing or two

[ralphdaugherty]

Millions of people can write things in Java or its kind without lots of training and expertise.

      I have to question that. I'm a self-starter myself and all for it, but I don't think there's any basis for this statement.

  rd

First web browser not written in C++

[Anonymous Coward]

WorldWideWeb, being on a NeXT box, was written in Objective-C, not C++.

Aspect Oriented Programming is a Hack.

[suv4x4]

FTFA: I hope you didn't put too much money on it! I don't see aspect-oriented programming escaping the "academic ghetto" any day soon, and if it does, it will be less pervasive than OO. When it works, aspect-oriented programming is elegant, but it's not clear how many applications significantly benefit from its use.

Totally agreed. AOP is a strange form of "dynamic" insertion of code at special "cut points" of execution within the code and represent a very very lazy way to avoid good OOP structure of your applications.

In a bigger framework AOP can be totally unpredictable and wreck otherwise locked and working code.

When AOP started to pick some speed in the beginning I was naturally both interested and slightly annoyed that so short after OOP here's yet another concept for programming I have to learn and implement in my software.

Not so fast though, since as much as OOP provides useful abstractions that makes your code more readable and predictable, AOP does exactly the opposite except in few very limited cases.

The cons outweigh the pros.

Re:Aspect Oriented Programming is a Hack.

[Elias Ross]

AOP solves the N times problem nicely. For instance, if you wanted to take an object with N methods and add a call x() to each of them, if you used ordinary OOP, you'd have to override every method, then call x() from each method. What's the elegance of that? I don't see how "proper" OOP can solve this sort of problem better than AOP.

AOP is largely mysterious and confusing because it's not something (yet) integrated with any standard languages. If it were integrated, then there would be proper tool support, recommend methodologies, references, implementaiton refinements to make AOP easier.

And in a sense, AOP isn't new to Java. Have you ever used the Java "Proxy" class? AOP really just provides a java.lang.reflect.Proxy "version 2.0".

Maybe AOP won't be used except by container providers, i.e. people writing EJB3 implementations.

Re:Aspect Oriented Programming is a Hack.

[Breakfast Pants]

def wrapper(to_wrap):
    def blah():
        x();
        return foo()
    return blah

for name, val in some_obj.__dict__.iteritems:
      if type(val) == instancemethod:
            some_obj.__dict__[name] = wrapper(val)

You'd need some other stuff to handle arguments but it is definitely possible, I just didn't feel like remembering. (also I don't know where the instancemethod type is.. in its place you could use

class throwaway:
    def nonsense(): pass

instancemethod = type(throwaway.nonsense)

Re:Aspect Oriented Programming is a Hack.

[bit01]

AOP is object oriented come from. It can trash maintainability. In any program using AOP you can't look at any call in the entire program without assuming there's an arbitrarily large block of code somewhere else messing things up.

While it's true that AOP can help the classes of problems it solves are fairly small compared to the cost it brings. Instead, adding calls to the first/last line of method implementations is no big deal. Less consistency checking but more debugability. If all you've got is binaries then AOP will get you going but in that case your solution of a derived class is workable and documents the fact that you've changed the behavior of the entire class.

---

Don't be a programmer-bureaucrat; someone who substitutes marketing buzzwords and software bloat for verifiable improvements.

Re:Aspect Oriented Programming is a Hack.

[suv4x4]

AOP is largely mysterious and confusing because...

I never said its mysterious and confusing however. I just said it's poorly conceived and wrecks maintainability.

AOP solves the N times problem nicely. For instance, if you wanted to take an object with N methods and add a call x() to each of them, if you used ordinary OOP, you'd have to override every method, then call x() from each method. What's the elegance of that? I don't see how "proper" OOP can solve this sort of problem better than AOP.

You see, the thing is, if I override every method and call a piece of code in OOP, I can only do it to a class I extend. And when you instantiate the child class, you know it runs the code defined within it.

With AOP, you can have some piece of code affecting code in some completely different place, other class package, and classes which instantiate it wouldn't have the slightest idea this is happening.

Your "N times" issue solved by AOP is a nice example of what I said: it's an excuse for poorly designed OOP packages.

Of course, a problem defined as "I need to run x for every method in those classes" is also not well defined enough so I could tell you how to solve it.

The two pervasive example where AOP makes sense that I've seen so far are:

- logging
- validation

Logging is best solved via the debug utilities inside the language, or via common functionality inherited by a common class. It's also quite a specific issue solved by AOP, you can't claim logging is a generic case of "N times problem", whatever meaning you put in this phrase.

Equally odd is the validation example. Would you trust validation to run via "stealth" code injections produced by AOP? What are we exactly saving here? Time? File size?

The AOP advocates give examples like:

int getXYZ(Data data) {
... looooots of validation code repeated in every method ...
 
.. code processing data ...

    return dataProcessed;
}

and explain how you have to "copy/paste" this for all your get*() methods, for example.

then go on to say how the magic of AOP solves this by injecting code on all your get* methods.

What if I have a get* method that is so called but I need different processing for it? What if I have otherwise named method that should also run this validation code? Just few questions popping up. And suddenly AOP is not so easy except in few tightly specialised cases.

Not to mention you can shorten the above example to just this, using strictly OOP facilities:

int getXYZ(Data data) {
    validate(data); // throws exception if not valid
 
... core data processing ...

    return dataProcessed;
}

suddenly the huge problem AOP solves is making this single line invisible, and you need special magical IDE functionality to hunt it down where in the source code tree it is.

Let's even be more extreme and ask: if your get* (in this case) methods are SO generic that they ALL can reuse the exact same validation code injections, why have separate methods at all?

int get[PROPERTYNAME](Data data)

suddenly becomes:

int get(String propertyName, Data data)
 
.. and now you have to type the validation code just once. And it's all visible and no need for special tools.

Re:Aspect Oriented Programming is a Hack.

[Anonymous Coward]

Try that in Java. I'm guessing that the example you posted is SmallTalk. Haven't seen that used much.

Re:Aspect Oriented Programming is a Hack.

[Anonymous Coward]

AOP just needs some programmer discipline. I've seen some real messes with Java and C++ too. With the proper tools (the AspectJ plugin for Eclipse, for example), it is pretty clear where an aspect is affecting your code. In the pure OO world, you still don't know where there could be 'an arbitrarily large block of code' - what about subclasses overriding your method? Maybe it calls super, maybe it doesn't. Maybe it screws with your parameters before calling super, or messes with your return value.

Re:Aspect Oriented Programming is a Hack.

[Anonymous Coward]

Other uses: declarative transactions, policy enforcement (eg, don't allow calls to JDBC outside of a DAO, I/O calls in an EJB), pooling and caching, declarative security, thread safety (eg, with Swing), remote method invocation. Your example of get* methods that you don't want aspects to apply to can be handled in AspectJ by using annotations to identify pointcuts. I've been using AspectJ for enterprise applications for 4 years now, and it has been very useful. Personally, I find it very easy to understand. For a great introduction and many examples, try the book 'AspectJ in Action'.

Your counter-example of a generic get method that takes a property name as a parameter is a very special case. As a more generic example, consider business methods that take an assortment of parameters, and your validation has to validate the (multiple) parameters. In this case, you might want an aspect that applies validation to all public methods of any class that implements your business interface.

Also, take a look at this: http://news.com.com/2100-1008-5178164.html?tag=cd_ hed/ for a quote from an IBM VIP indicating that they consider AOP to be 'vital to their survival'. And the Spring guys seem thrilled to have better integration with AspectJ.

Re:Aspect Oriented Programming is a Hack.

[Breakfast Pants]

Close; it's Python =)

Re:Aspect Oriented Programming is a Hack.

[Breakfast Pants]

x()

Should read:

to_wrap()

The World Before Google

[Anonymous Coward]

Why yes, I remember the world before Google. We had AltaVista. Their ads? Teh suck. Their search? If we're talking before they left DIGITAL Corp, as good as Google's. Google's an *ad* company, people, not a geek company.

Java

[goombah99]

Javac is the coolest program written in C++ :-)

Re:Java

[Anonymous Coward]

Javac is written in Java. The JVM is written in C++.

Re:Java

[Anonymous Coward]

Javac is written in Java.

Really? I wonder why I never see the JVM start up when I compile with javac.

Re:Java

[Anonymous Coward]

Ever hear of a java compiler?

Re:Java

[Iffy Bonzoolie]

What do you mean by "see the JVM start up" ? It doesn't have an animation or anything - javac is a native stub that launches the VM and invokes the compiler. It's all within that "javac" process. Now, there is a native Java compiler: Jikes. But last I checked it was pretty outdated. Also, GJC will compile Java to native code, and it is also native, but I haven't played with it yet.

-If

Re:Java

[Wavicle]

I wonder why I never see the JVM start up when I compile with javac.

Because you aren't paying attention. Javac is in the package com.sun.tools, see documentation here.

When you're done reading, download jikes and use that instead.

Re:Java

[vocaro]

Uh, Javac is not written in C++. It's written in Java. Download the source code and see for yourself. It's in the com.sun.tools.javac package.

Re:Java

[Anonymous Coward]

You mean from: http://download.java.net/openjdk/jdk7/, of course. It is the GPL'd source.

Re:Java

[Rockgod]

Aha!!! That explains its blazing speed!!

Lamest - Slashdot HTML parser

[Anonymous Coward]

Where in "Plain Old Text" you have to escape < as <

Re:Lamest - Slashdot HTML parser

[Anonymous Coward]

slashdot (and their HTML parser) are in perl.

(it probably would be even lamer if they wrote it in C++, though).

Re:Lamest - Slashdot HTML parser

[HeroreV]

If only there was some way to preview your message to see how it will appear before submitting it. Perhaps one of these days, far, far in the future...

Re:Lamest - Slashdot HTML parser

[Anonymous Coward]

Do what I do: download the slashcode and run it locally, then just keep a stub article up so you can test posts.

Google

[Anonymous Coward]

Claiming Google as a cool C++ program is about 1/3 true. Most Google code is written in C++, Java, and Python: C++ for performance-critical stuff, Python for scripting, and Java for everything in between. The trend is definitely toward Java at the expense of the other two.

Also, for what it's worth, Google's use of Aspect-oriented programming is ramping up pretty fast.

Re:Google

[Midnight Thunder]

The trend is definitely toward Java at the expense of the other two.

I prefer programming in Java, but have been doing a lot of programming in C++ recently. From my experience, while Java produce larger code and slightly less performant code than C/C++ there are many advantages: shorter development cycle (assisted by a large and complete API and you avoid many issue with pointers vs references), works without recompilation no matter the OS/architecture you are using.

Re:Google

[Anonymous Coward]

Well, all of the actual search engine code is written in C++.

Bug in C++

[Anonymous Coward]

Can you find the bug in this C++ program?

---- begin bugdemo.h ----
template<class T> void doprint(T obj) { printf("The numbers are: %d %d\n",obj.num1,obj.num2);}
void foo(void);
void bar(void);
---- end bugdemo.h ----
---- begin bugdemo.cc ----
#include "bugdemo.h"

int main(int argc, char *argv[])
{
  foo();
  bar();
  return 0;
}
---- end bugdemo.cc ----
---- begin foo.cc ----
#include <stdio.h>
#include "bugdemo.h"

struct A {
  int num1,num2;
};
void foo(void)
{
  A myobj;

  myobj.num1=-5;
  myobj.num2=6;

  doprint(myobj);
}
---- end foo.cc ----
---- begin bar.cc----
#include <stdio.h>
#include "bugdemo.h"

struct A {
  short num1,num2;
};
void bar(void)
{
  A myobj;

  myobj.num1=-5;
  myobj.num2=6;

  doprint(myobj);
}
---- end bar.cc ----
This program seems to be intended to generate:
The numbers are: -5 6
The numbers are: -5 6

But instead generates:
The numbers are: -5 -1
The numbers are: -5 6
or perhaps something different altogether.

The problem is portable across platforms and compilers (although the exact incorrect answers sometimes vary).

Re:Bug in C++

[EvanED]

http://en.wikipedia.org/wiki/One_Definition_Rule

Re:Bug in C++

[BonoLeBonobo]

Can you explain where the problem is ?

Re:Bug in C++

[Anonymous Coward]

Agreed. Nevertheless, no compiler diagnoses this. And it has the potential to cause bizarre memory corruption. That makes it a land mine waiting to be stepped on.

The real problem is that the linker crosslinks lightweight symbols without checking if those symbols really are equivalent. But the linker folks don't seem to care ("not our bug").

The "official" response I've seen to this is "you're supposed to use namespaces".

Re:Bug in C++

[Anonymous Coward]

doprint<A>(myobj);

Re:Bug in C++

[EvanED]

The problem is that two different translation units define two different versions of struct A.

Relevant parts from Section 3.2 of the cpp standard:
"There can be more than one definition of a class type ... in a program provided that each definition appears in a different translation unit, and ... each definition of [the name defined more than once] shall consist of the same sequence of tokens ..."

In the example provided, two translation units have definitions for struct A. However, they are not identical; in particular, one has members that are ints, the other, shorts.

However:
"If the definitions of the [name defined more than once] do not satisfy these requirements, then the behavior is undefined."

In other words, the compiler is not required to diagnose violations of the ODR (One Definition Rule).

In this particular example, the compiler compiled bar as if doprint had a four-byte argument* (two shorts) but then threw out one of the definitions of doprint, leaving the other to treat shorts as if they were ints.

*or maybe an eight-byte argument with misc padding that wasn't cleared

Re:Bug in C++

[Anonymous Coward]

The compiler generates different but identically names instances of doprint() in each of the two modules (notice the difference in the definition of struct A). The linker then arbitrarily picks an instance and throws out the other.

The net result is that one of the calls to doprint() ends up using a template instantiation for an incompatible datatype and prints out the wrong things.

With GNU ld, the linker's selection of the instance is determined by the order of parameters on the command line, so you can get different behaviors by switching the parameters around.

I spent a week tracking this down during my dissertation work. It was buried in a 4000 line (not including libraries) numerical analysis code. The offending template definition was buried in a macro expansion defined in an external library.

Needless to say, I've avoided C++ since then. Too many gotchas and subtle behaviors, weirdnesses with virtual methods, etc. Not to mention the const/non-const combinatorial explosion and the other hassles resulting from strong typing.

These days I usually end up using C, Matlab/Octave, or Python depending on the problem. The new Numpy is very very good for numeric computation.

Re:Bug in C++

[EvanED]

You don't need to write doprint because the type can be deduced from the argument to doprint.

(This can be further demonstrated by the fact that making your change doesn't fix the problem.)

Re:Bug in C++

[Anonymous Coward]

The real problem is that the linker crosslinks lightweight symbols without checking if those symbols really are equivalent. But the linker folks don't seem to care ("not our bug").

By the way, ld (the link editor) has has an option called --allow-multiple-definition whose documentation says:

Normally when a symbol is defined multiple times, the linker will report a fatal error. These options allow multiple definitions and the first definition will be used.

This tells me that it is a bug in the linker (or at least the linker's documentation).

Note that ld also has an option called --warn-common whose documentation says:

Warn when a common symbol is combined with another common symbol or with a symbol definition. Unix linkers allow this somewhat sloppy practise, but linkers on some other operating systems do not. This option allows you to find potential problems from combining global symbols. Unfortunately, some C libraries use this practise, so you may get some warnings about symbols in the libraries as well as in your programs.

This option does not warn about the issue in question, so I consider that a linker bug as well.

p.s. The best policy is to disallow header files to define nonstatic symbols. This is fairly difficult to enforce programmatically, but you can at least catch multiple definitions and reject them before linking if you do something along the lines of: nm -ogC --defined-only *.o | cut -d: -f2 | sort | uniq -dc. In this case, you'll get 2 00000000 W void doprint<A>(A const&), which indicates that there are two weak symbols with the name void doprint<A>(A const&), so your custom build process can halt with an error.

p.p.s. The fix for the case in question is to change its definition to be template<class T> static void doprint(T obj) { printf("The numbers are: %d %d\n",obj.num1,obj.num2);}

Re:Bug in C++

[Anonymous Coward]

The linker documentation (i.e. --allow-multiple-definition) is referring to regular symbols, not lightweight symbols. The reason for lightweight symbols is to allow the linker to eliminate redundancy in code compiled from header files. However, as EvanED pointed out, the compiler and linker are following the spec.

The trouble is that the spec doesn't say what to do in this circumstance. My opinion is that
    1. The linker should issue a warning that it's combining two symbols that refer to code that is not bit-for-bit identical. (this would cause problems if different modules are compiled with different compiler flags), and/or
    2. The linker should keep both versions separate and distinct. One way to achieve this would be to have the compiler add a hash of the generated code to the symbol name

In addition
    3. The language should allow the static keyword in the class/struct definition. That would make all templates of the class or struct also static (i.e. local to the module).

Who knows. Maybe Bjarne will read this and come up with an even better solution.

Re:Bug in C++

[Anonymous Coward]

By the way, ld (the link editor) has has an option called --allow-multiple-definition whose documentation says:

"Normally when a symbol is defined multiple times, the linker will report a fatal error. These options allow multiple definitions and the first definition will be used."

This tells me that it is a bug in the linker (or at least the linker's documentation).

You seem to like throwing around the word "bug" without knowing what it means. If the C++ standard specifies that doing something results in undefined or implementation defined behavior, then it's not a bug when you do that thing and get varied behavior.

Re:Bug in C++

[Anonymous Coward]

Problem is that you should provide template specification for both types of A you introduce.
More specifically, as A,1 uses int and A,2 uses short and printf() does not know any type,
you're not printing what you would expect.

Next big programming paradigm: VM on Steroid

[Anonymous Coward]

TR brought up aspected orientation, and BS brought concurrency (in line with current CPU design pattern) and generic programming. Concurrency will definitely be a biggie - it applies not only to multi-core CPUs, it already applies to distributed computing (cluster and all those related). Generic would need a lot more work. It has been in C++ (template, STL) for many years, but only the ninjas would cook up their own templates - most of use simply use library-supplied templates and don't f*ck it up. Same story with Java generics, the way it was added. C#'s generics seem easier to use.

AO appears more of an extension to OO - helps to organize and manage the design workload. Much buzz, but no real uptake so far. Maybe a takeup by one of the big platforms (C++, Java, .net) is the push AO needs to take root in practice/industry.

My guess is growing importance of VM/runtime support. Both Java and .net are based on runtime VM, and it has the advantage of access to the runtime profile information that static languages lack. I'm thinking addition to language that better expresses how the VM should optimize in execution of the program (maybe in conjunction with dynamic typing - i.e., runtime morphing of the code) can provide the next leap in programming productivity by pushing up the abstraction level. MDA promised the same result, but so far it seems to have failed to hit the sweetspot on the tradeoff between abstraction and control. And the super VM is not mutually exclusive with any of the ideas noted.

Ok, just an idea out ma ass. I know next to nothing on the topic of VM design. :-)

"Severe resource constraints"

[melted]

"Severe resource constraints"? Since when a datacenter with half a million servers in it is called "resource constraints"?

Re:"Severe resource constraints"

[halftrack]

Since always ... Getting a 10% performance gain in a 500,000 servers data center could mean a cost saving of 50,000 servers. On 5 servers you wouldn't bother because you wouldn't save anything. The resources we are talking about here are in essence entirely economical and pragmatical. Adding 50,000 servers is not easily done nor particularly cheap.

Re:"Severe resource constraints"

[ralphdaugherty]

"Severe resource constraints"? Since when a datacenter with half a million servers in it is called "resource constraints"?

      When millions of people are hitting on them.

  rd

errrr check your timeline please

[biafra]

From the article: "Technology Review: Name the coolest and lamest programs ever written in C++, and say what worked and didn't work. Bjarne Stroustrup: Google! Can you even remember the world before Google? (It was only five years ago, after all.)

OK, I really try not to be elitist/whatever but this one kind of bugs me. Google has been around, and part of (mostly) popular culture for more than 5 years. And I would imagine that a decent amount of people actually do remember the days before Google. Writing like that is just lazy.

Re:errrr check your timeline please

[zendog]

This is the structure referred to in literature as a "droll comment." Shorter: it's a JOKE, dude. I am old enough to remember thinking Gopher was pretty cool, but I can hear what he is saying without getting into a hipper-than-thou snit.

Re:errrr check your timeline please

[WgT2]

Yeah, that

(It was only five years ago, after all.)

really bothered me too... especially since I started using Google in H2 of 1999.

Also, the whois page on it has this to say about it:

Created: 1997-09-14

Re:errrr check your timeline please

[Anonymous Coward]

What's with all the pedants on Slashdot?

Const

[kryten_nl]

Yes, yes, all fine and well that he's influenced by Kierkegaard and dislikes AOP, but ... COULD SOMEONE PLEASE ASK HIM TO EXPLAIN THE "CONST" keyword .... please ....


(A very good explination is given here for those of you who didn't know I was kidding)

Re:Const

[EvanED]

I don't see why you need to say so much.

* If a variable or reference to a variable of primitive type is const, you can't assign to (and must initialize) it
* If an object or reference to an object is const, you can't change non-mutable data members or call non-const functions
* For pointers to primitive types, there are two notions of constness: whether the address stored in the pointer ("where the pointer points") can be changed, and whether the value at the pointed-to location can change. In the type of a pointer, __1__ <type> __2__ * __3__, a const in slot 1 or 2 refers to the second kind of constness, while a const in slot 3 refers to the first kind.
* For pointers to objects, the same rules apply as the last point, except that the second notion of constness changes to preventing modification of non-mutible members or calling non-const member functions
* A const on a member function means that you can't modify non-const data-members or call non-const functions of this
* Implicit conversions will add but never remove const qualifiers

There, that's most of C++ const rules.

Now, I'm being a little facetious here, because the article does go into a lot more detail about how const is actually used in practice (for instance, passing objects by const reference for efficency), but I think the article is making more of it than needs be.

For instance, there's no difference between the treatment of const for normal variables, parameters, and return values. In all cases, const means you can't modify it or call non-const functions, yet he devotes a section to each.

Re:Const

[Anonymous Brave Guy]

Using const when you create an object states that the object may not be modified. Using const when referring to an object is a promise that it will not be modified. The other rules all follow from these two statements.

The confusing factor in C++ is that using const qualification can have two different meanings, depending on context.

Used simply, you get "physical constancy", where the memory representing an object cannot be changed at all. This can be useful if you're working in a low-level environment with physically read-only data, for example, and is "constancy from a physical design perspective".

However, combined with things like mutable and const_cast, you can get the often more powerful concept of "logical constancy". Here the observable state of an object (accessible through the interface from outside) cannot be changed, but internal data can (a cache being the textbook example). This is more like "constancy from an OO design perspective".

It is unfortunate that the same keyword is used to help enforce both concepts in C++, and therefore a programmer is never 100% sure what guarantees are available. Fortunately, if your design is at all sensible and your use of const is consistent, it rarely matters.

Re:Const

[HeroreV]

It makes perfect sense to me, but C++ was the first programming language I learned. How would this be confusing to newcomers? How was it confusing to you?

"Also, the first Web browsers."

[SEE]

Um. Yeah. Er.

"WorldWideWeb was written in Objective-C."

Re:"Also, the first Web browsers."

[Anonymous Coward]

Yeah and Mosaic was totally written in Objective-C, too.

Re:"Also, the first Web browsers."

[SEE]

Well, let's see. The claim was the "first web browsers".

WorldWideWeb was in Objective-C.
WWW. the line-mode CERN browser, was in plain C.
Erwise was in plain C.
ViolaWWW was written in the Viola toolkit/language system.

Mosaic was early, and Mosaic was important, but to say the "first web browsers" to have been written in C++, one has to ignore the actual first web browsers.

Re:"Also, the first Web browsers."

[iabervon]

Even Mosaic wasn't written in C++. I'm looking at the 2.7b4 source now, and it's definitely C.

Re:"Also, the first Web browsers."

[XdevXnull]

Just because it doesn't use classes doesn't mean it's not C++

Re:"Also, the first Web browsers."

[pthisis]

Sure, but that doesn't change the fact that the Mosaic source code is not C++, it's C. Looking at it for even a second shows at least a few places that don't cast the return value of malloc or otherwise are legal C but illegal C++.

(and no, C is not a subset of C++)

Interview with Stroustrup

[ghenne]

How can any not read this interview with Stroustrup? http://www.nsbasic.com/ce/info/interview.shtml

Best part of interview

[rjdegraaf]

.Net is a huge integrated system backed by Microsoft. That's its major advantage and disadvantage. Personally, I'm a great fan of portability. I want my software to run everywhere it makes sense to run it. I also want to be able to change suppliers of parts of my system if the suppliers are not the best. Obviously, suppliers of huge integrated systems, such as .Net and Java, see things differently. Their claim is that what they provide is worth more to users than independence. Sometimes they are right, and of course some degree of integration is necessary: you cannot write a complete application of any realistic size without introducing some system dependencies. The question is how deeply integrated into the application those system dependencies are. I prefer the application to be designed conceptually in isolation from the underlying system, with an explicitly defined interface to "the outer world," and then integrated through a thin layer of interface code.

Re:Best part of interview

[oldhack]

Large part of the many (most?) business applications is glue to the system ("integration"), especially nowadays where much of the basic algorithms (supplied lib), data access (SQL), and UI are handled by underlying systems.

Re:Best part of interview

[hey!]

This is very true. My pet peeve is the way java frameworks other than Spring infect application code.

Re:Best part of interview

[SanityInAnarchy]

When you do it this way, it's possible you'll find yourself re-inventing the wheel a bunch. The trick is to choose a system that is flexible enough and portable enough that you're alright with having your application married to that system.

After all, we all have to choose a programming language to start with.

So, for instance, if your concern is that tying yourself to a graphics library, even a nice cross-platform one like wxwindows or opengl, will make your program forever a GUI program, you might design your code for a system that has both wx and ncurses backends. You might write a configuration management system that can be operated through config files, commandline, curses, or wx, and have your program tied heavily to that system.

But yes, we want to be portable. The important thing to remember is that the only way to make an idea portable from an application is to wrap that idea in a library. I prefer to have the majority of the application logic be in CPAN modules, and have the app itself be around a few hundred lines of Perl code. In fact, more than a hundred lines or so, and I probably haven't abstracted enough.

Professionals...

[Savage-Rabbit]

True, but there are huge classes of applications which are tremendously useful, for which a failure is tolerable, and which are relatively easy to write. So I strongly favor the existence of languages which allow people to write code with only a few months training. And as a professional software developer/computer scientist, I don't feel threatened by it - I wouldn't want to write those applications. When they need something more complex or more robust, they'll come to me.

Severe ranting ahead, you have been waned...

That's just the problem, a lot of companies don't come to professionals when they need something more complex or robust. They usually start off hiring a bunch of amateurs who have no firm grasp of professional software design because they are cheap to employ and let them loose without proper supervision. These people cobble together some system that works, it doesn't work very stably, but by and large it works if you constantly monitor it and as long as it the system is still relatively small. This system gets maintained for a while and added to. These additions are usually badly designed or even worse, quick fixes intended to patch up problems that could have been avoided if the system had been properly designed in the first place. As I said before, while the system is still relatively small the bad design does not matter so much but as the system's complexity, the load the system is subjected to and it's importance to the company grow the instability and constant hiccups due to bad design begin to become a liability. This is usually the point the company finally decides to call in the professionals who are then confronted with a system that badly needs a complete rewrite and an employer who expects the necessary rewrite to be done in a couple of weeks and on a shoestring budget. My experience is that a lot of the time (not to be read as: **always**, there are companies out there who proper design work) the professionals are called in to clean up messes created by people who learned to write code with only a few months training. Way to many of the jobs I get involve cleaning up problems created by people who committed basic errors such as duplicating code all over the place instead of building it into class libraries and who didn't seem to be aware of the existence of nifty utilities like 'javadoc'/'doxygen' and 'subversion' or even revolutionary concepts like 'multi-line code comments'. Not that I am complaining mind you; the clumsiness of these badly trained developers and the frugality of the managers who hire them keeps me, a professional university educated software developer, employed but it's still a frustrating way to make a living because a lot of the crap I have to deal with could have been so easily avoided.

Re:Intw with Stroustrup - http://www.google.com

[Anonymous Coward]

I dont think he likes it though
http://www.research.att.com/~bs/bs_faq.html#impost or

the world before google?

[Anonymous Coward]

Yes, I remember clearly, I used some other search engine instead.

People need to stop acting like google invented the search engine.

It's a decent one, but only marginally better than the competition and if google search disappeared tomorrow it just wouldn't be a big deal.

Re: (minor correction to parent)

[Anonymous Coward]

Ooops. To avoid confusion for people trying to follow along with what I did, I should mention that I had changed my copy of the header to
template<class T> void doprint(const T& obj) { printf("The numbers are: %d %d\n",obj.num1,obj.num2);};
that's why I got void doprint<A>(A const&) instead of void doprint<A>(A).

use ObjC and your problem will go away

[Anonymous Coward]

C++ is an inherently and unnecessary complex language, if you want to use some C inheritor for OO programming resort to Objective-C: it is a much simpler and cleaner "enhancement" of C instead of C++ which tries to kill many flies with one stroke (multiparadigm language). ObjC is essentially C + Smalltalk, you can learn it within one day if you already know C, just compare the number of pages of http://www.amazon.com/C++-Programming-Language-Spe cial-3rd/dp/0201700735 vs http://www.amazon.com/Object-Oriented-Programming- Evolutionary-Brad-Cox/dp/0201548348 . it's like in real live: the worse approach wins (Windows vs. Linux and so on). Good tutorial here: http://objc.toodarkpark.net/ . And by the way: the OpenStep Libs are to die for!

Re:use ObjC and your problem will go away

[Josef Meixner]

And the three Smalltalk books describing it are even more pages than the C++ book, so obviously ObjC is inferior to both? What a stupid way to compare programming languages.

ObjC is a language which has a core with a static type system, which is somewhat weak because of the ease of casts and on top of that a language with a dynamic type system. So basically you have the worst of two worlds. It is neither as efficient as C/C++ nor as elegant as Smalltalk. And yes, C++ is multiparadigm, structured if you basically use the C core, object-oriented when you use the class system and generic when you program with templates. ObjC is also multiparadigm, structured and object-oriented, but dynamic typing doesn't need generics, so it has no concept for it.

And sorry, but the learning speed of a language is not determined by the number of symbols. Without the supporting libs you can't do anything in either and I doubt you learnt the OpenStep libs in a day. The same is true of C++ and expecially Smalltalk. That language is so small that its syntax graph fits on two pages of the first Smalltalk book. So by your reasoning you should use Smalltalk, why don't you?

Please understand me right. I don't like ObjC as you obviously don't like C++. I have my reasons and you yours. But I really, really dislike the claim of ObjC being "basically C + Smalltalk" because that is simply not true. And I have programmed in all four languages, C, Smalltalk, ObjC and C++, although the least amount in ObjC because I heard the claim "it is like Smalltalk" (which I already knew at the time before trying ObjC) and was very disappointed, no, it is not like Smalltalk. Interestingly I never heard someone claim it who also knows Smalltalk.

Re:use ObjC and your problem will go away

[Anonymous Coward]

So basically you have the worst of two worlds. It is neither as efficient as C/C++ nor as elegant as Smalltalk.

I prefer to think of it as the best of two worlds: more elegant than C++, and more efficient than Smalltalk. (Actually, I still prefer Smalltalk, but those are the reasons why NeXT adopted it over C++.)

I heard the claim "it is like Smalltalk" (which I already knew at the time before trying ObjC) and was very disappointed, no, it is not like Smalltalk. Interestingly I never heard someone claim it who also knows Smalltalk.

I know Smalltalk and Objective-C and yes, it is like Smalltalk. It's not exactly like Smalltalk, but it has a dynamic dispatch object runtime based on selectors which is more similar to Smalltalk's runtime than, say, C++'s virtual dispatch tables, and message-passing syntax which is similar to Smalltalk as well.

Objective-C looks pretty much like what you'd expect if you tried to cram Smalltalk's object model into a C-like language, which in fact is the case: Brad Cox consciously designed Objective-C with Smalltalk as its role model (as opposed to the more Simula-inspired C++).

Re:use ObjC and your problem will go away

[Josef Meixner]

I know Smalltalk and Objective-C and yes, it is like Smalltalk. It's not exactly like Smalltalk, but it has a dynamic dispatch object runtime based on selectors which is more similar to Smalltalk's runtime than, say, C++'s virtual dispatch tables, and message-passing syntax which is similar to Smalltalk as well.

Well, let's see what I missed:

1. No unary and binary selectors, so no way to define a new numerical type like complex
2. No way to influence the type coercion on numerical types, so you can't define a new complex type where e.g. double automatically converts itself to a complex when necessary (yes, Smalltalk can do that)
3. Static typing clutter allowed in selectors (and already used by the base runtime, so can't be evaded). Something like test: (int) aVal is just plain ugly and breaks dynamic semantics.
4. No block contexts, so no way to create new control structures like do:
5. Native types not part of the dynamic system, so if you want the full power you have to define your own integer type, which is even slower as Smalltalks

Somehow I don't see the "is basically like smalltalk" if most of the really cool core features of Smalltalk are missing. Also one of the best aids in Smalltalk development is the environment which won't compile code if there is no selector with the signature you tried to use and could show you all classes implementing a certain selector. And the debugger allowing to stop, change the code and resume operation. Compared to that the compile cycle of ObjC is that of a static language without the abilities to catch the same problems a statically typed language can catch.

Objective-C looks pretty much like what you'd expect if you tried to cram Smalltalk's object model into a C-like language, which in fact is the case: Brad Cox consciously designed Objective-C with Smalltalk as its role model (as opposed to the more Simula-inspired C++).

Hmm, Simula's class model has single inheritance, no data hiding (public, protected, private) and no overloading. C++ has multiple inheritance, virtual inheritance (the same base class appearing multiple times is only included once in the data layout), data hiding with the three keywords plus a way to break it (friend) and overloading. Also Simula had no operators, no constructor or destructor. To me ObjC's class model is exactly that of Simula. The only thing they differ in is that Simula uses Algol function syntax and ObjC Smalltalk selector syntax. So I really don't see that the class model differs. The object model of all three is basically the same: an opaque reference to an object (ref in ObjC, pointer and reference in C++, forgot what it was called in Simula (haven't used it in the last 15 years) and in Smalltalk it has no name as the references are the only type of the system) you can send messages/call functions on which does polymorphic dispatch. In the dynamically typed languages basically looking if a matching selector exists in the target, in the statically typed languages statically designated by the inheritance relationship. So for me they differ the most in the method dispatch and that is exactly to be expected.

You are confused

[Anonymous Coward]

He is talking about object orientation not being a paradigm shift, not a specific language. Object orientation as implemented in Java did not throw out all of the previous programming language concepts from C++, Simula, Smalltalk, Algol, etc. It built on them and picked and chose features from previous systems. Hence, no paradigm shift.

Moo

[Chacham]

Can you imagine the world without the Web? (It was only about 10 years ago.)

The web was created by Al Gore in 1996?

My word ignorance has passed on even to our elders. /me cries.

Just a quick look at AltaVista's about pages shows they *indexed* the web in 95. Of course, the Internet wasn't there before Google, so it must be bogus.

RFC 1580/FYI23 which was published in March 1994, contains a definition of the web.

In actuality, the World Wide Web came about in 1992 about 15 years ago.

Now, had Bjorn meant that slashdotters wouldn't remember before ten years ago because that's about how old most moderators are, i could understand, but he should have been more clear on the matter.

Re:Moo

[cyberon22]

Take your disinformation elsewhere troll.

Gore was incredibly active in the 1980s promoting the development of a national research network. He was a proponent of funding a national "data highway" as early as 1986, and proposed legislation in 1988 that among other things funded a 3GB/sec fiber optic national network backbone, pushed additional money to CS research and funded institutional supercomputing and database development. As his proposal stated:

CAN WE RELY ON THE MARKET SYSTEM TO PROVIDE THIS KIND OF INFRASTRUCTURE? WE CERTAINLY COULDN'T WHERE THE INTERSTATE HIGHWAY SYSTEM WAS CONCERNED, ALTHOUGH PRIVATE INDUSTRY ULTIMATELY BENEFITED A GREAT DEAL FROM THE GOVERNMENT'S LEADERSHIP AND INVESTMENT. I BELIEVE THAT THE FEDERAL GOVERNMENT MUST AGAIN BE A CATALYST, TO GET COMPANIES INTERESTED IN THOSE INFORMATION NETWORKS AND SHOW THEM THAT THERE IS A MARKET OUT THERE. CLEARLY, THE TECHNOLOGICAL SPINOFFS AND PRODUCTIVITY GAINS WOULD BE ENORMOUS, FROM A NETWORK THAT WOULD COST THE GOVERNMENT LESS THAN ONE STEALTH BOMBER.

This basically guaranteed what is today known as Network Neutrality -- business built on a technically non-discriminating data network. And if you don't consider it progressive you might want to remember that even by the early 1990s the market was still banking on online connectivity being offered to consumers through "walled gardens" like Compuserve/Sierra Online/AOL.

More details here if you are ever interested in taking those blinders off. Anyone who imagined Gore passing himself off as a hacker is either an idiot, or content to pass themselves off as one.

Re:Moo

[Chacham]

The beauty of that "troll" is, you didn't even read the rest of my comment! I mentioned good ol Al as a side swipe, In reality, he had nothing to do with my comment.

Re:Moo

[cyberon22]

I read it... I just missed the point. My fault, and apologies for the rant.

Re:Moo

[Chacham]

I read it... I just missed the point. My fault, and apologies for the rant.

Heh. :)

CFG

[sadler121]

What is a language anyways but a context free grammar? The school I goto teaches Java as the primary language, but once you get into the junior, senior classes you branch out into C and C++ (they even teach Cobol, ewww, I know). Once you take on Automata and Computability, and learn about CFG's then the language isn't the problem. On the other hand, learning a paradigm (like OO vs Structural) can be a bitch.

Re:CFG

[BitchKapoor]

What is a language anyways but a context free grammar?

Semantics.

Re:CFG

[EvanED]

What is a language anyways but a context free grammar?

What? What kind of question is that?

If anything, it's the context free grammar part of languages that is LEAST interesting and, with the arguable exception of C++, easiest part!

A language is a mapping of syntactic elements to an actual action that the computer will perform. Saying "x ? y : z" is a legal expression means almost nothing; saying "x ? y : z means that the computer will evaluate x, convert it to a boolean value; if it is true, the computer will evaluate y and that will be the result of the expression, otherwise the computer will evaluate z and that will be the result of the expression" is what a language IS.

Even ignoring semantics, there's a large number of syntactic rules that can't be specified in a CFG. For instance, "int main() { return x; }" is not a legal C++ program, but there's no way to say that variables must be declared before they are used. "5.4 + "hello world"" is (I hope and think) not a valid C++ expression, but the CFG doesn't capture that.

The language part of the C++ standard is about 300 pages. The context free grammar is about 25. (And that's not doing much to make it compact either; that might be one column of grammar rules per page.)

Re:CFG

[whereiseljefe]

They don't branch out until Junior/Senior classes where you go?

Granted I am a student at Texas A&M (eagerly awaiting when I can weasle my way into a Stroustrup class) but we branch out into C in our data structures class (being the second class a CS major takes).

I do love Stroustrup to death though purely for the fact that he's been strongarming the CS dept. here into moving away from Java and into C++ and C# (I'm sorry but so many of my peers are pointer-stupid something needs to change. Java is easily learned, pointers not so).

Re:CFG

[Pseudonym]

What is a language anyways but a context free grammar?

Me do agree. Just syntax was a languages.

Re:CFG

[Pseudonym]

True enough, but to read a typical "compilers 101" book, you'd easily get the impression that it was all just parsing.

Re:CFG

[Anonymous Brave Guy]

I suspect that's because, in the grand scheme of things, parsing is easy, particularly if you can structure your language so that it's simple to parse. It's also easy to write a textbook on parsing, because it's basically a cookbook of the usual methods with a few examples thrown in (though most authors don't seem to be very good at that part, which makes me question how much they really understand themselves and how much is just regurgitating what they once read in someone else's notes).

On the other hand, writing a compiler that optimises well (particularly in languages that don't lend themselves to easy optimisation), or a virtual machine that uses JIT compilation efficiently, or code generation engines that support compatible ABIs so you can link across programming languages... those things are seriously difficult. Even with all the effort concentrated on the big commercial tools or the big OSS players like the GCC, it's only in fairly recent times that JIT has become popular, and optimisation over the whole code base of a language like C++ is performed.

I've been interested in this field for a long time, and I've never seen a book or a set of lecture notes that come even close to the kind of detail you'd need to understand to write code that does these things. As you said, most of the standard references are just a checklist of compilation stages and a few kiddie examples of parsing that don't really convey the significance of each step anyway. All in all, I think compilation techniques are probably the least understood (and perhaps most misunderstood) of all the major programming areas. That's a shame, because we could certainly do with someone developing a good programming language one of these years! :-)

Re:CFG

[NittanyTuring]

What is a language anyways but a context free grammar?

Semantics

Don't forget the type system.

Re:CFG

[Pseudonym]

I suspect that's because, in the grand scheme of things, parsing is easy, particularly if you can structure your language so that it's simple to parse.

Or, perhaps, that parsing is considered a solved problem because lex and yacc handle most programming languages that we care about.

(In reality, parsing isn't a solved problem. You try writing lex/yacc for Fortran or C++ and see how far you get. We have ways to handle these things, but there's still good research to be done in these areas.)

A follower-up recommends Muchnik, as do I. Andrew Appel's "tiger book" is also excellent. And it'd also be well worth reading Levine's "linkers and loaders".

Re:CFG

[Anonymous Brave Guy]

Thanks for the hint. I've noticed from reviews on Amazon and the like that Programming Language Processors in Java by Watt and Brown seems to cover similar ground, but get more favourable feedback (sometimes in direct comparison to Appel's book). OTOH, I'm also wary of customer reviews on web sites, since often these are written by people who have limited understanding of a subject themselves and therefore aren't really qualified to criticise a book on technical grounds. Have you by any chance seen the Watt and Brown book, and if so, what did you think?

Tiresome evangelising

[JLeslie]

It would be silly to fault someone for not having 20/20 foresight, so I can hardly blame BS for not including things that we know now to be good, but not necessarily then. One example would be pass by value, which at the time seemed like the safest default for parameter passing (the thinking was probably to avoid unintentional side effects). Extending this to objects though causes pains involving copy constructors and other esoteric stuff. Java decided on always pass by reference, and from my experience, unintentioned side effects almost never come up (the fact that the 'native objects' were immutable might have helped).

Yet to read these articles, it's almost like he still thinks that C++ is the top language, and anyone who's not using it is just a poorer programmer who can't handle the power. When I hear him reply with stuff about Java's success coming from 'massive corporate backing' it just sounds like tired whining. C++ did fill an important role, it introduced a lot of people to OO by piggy backing on a very popular language. It also allowed for OO programming on a lot slower hardware. But the cost was it wasn't much of an abstraction. I think it can be put to rest for the majority of projects. There's still some areas where it will shine for quite awhile (graphics maybe) but those are the minority.

Re:Tiresome evangelising

[Josef Meixner]

One example would be pass by value, which at the time seemed like the safest default for parameter passing (the thinking was probably to avoid unintentional side effects).

No, the reason is very simple, C++ was to be compatible to C and C uses pass by value as default. What kind of language would have resulted from passing variables of type int by value and objects by reference? Sorry, but I don't think I would want to program in that.

Yet to read these articles, it's almost like he still thinks that C++ is the top language, and anyone who's not using it is just a poorer programmer who can't handle the power.

And I always thought that was what the Java developers said, that they made the language simpler by removing the confusing parts from C++ which are rarely needed. By simple reasoning you get exactly what Bjarne Stroustrup said, no? C++ is more powerful but also much easier to get wrong. So it needs better and more experienced developers (which it rarely gets and that is in large part why C++ is blamed so often). Is it so hard to accept that there might be languages which are "better" (I don't even know, if harder and needing more experienced programmers is "better") in some way or other?

Re:Tiresome evangelising

[JLeslie]

What kind of language would have resulted from passing variables of type int by value and objects by reference? Sorry, but I don't think I would want to program in that.

But that is exactly what Java does. I thought it sounded bad at first too, but it works really well.

Is it so hard to accept that there might be languages which are "better" (I don't even know, if harder and needing more experienced programmers is "better") in some way or other?

When I first started on Java (I was 'forced' to learn it for a Uni class) I thought it was lame. 'How will I be able to do anything without pointers?!' After a few weeks I gave up the ghost deciding that there was a lot of stuff in Java that made life easier. C++ does need developers that are very experienced--in C++, but I don't think that necessarily makes them 'better'. As I said, it has its place in a few specialised areas, but it's not the general purpose tool it one was. It just seems like Bjarne can't really see that.

Re:Tiresome evangelising

[Josef Meixner]

What kind of language would have resulted from passing variables of type int by value and objects by reference? Sorry, but I don't think I would want to program in that.

But that is exactly what Java does. I thought it sounded bad at first too, but it works really well.

I never used Java (tried it a bit and intend to use it soon), but that sounds terrible. I don't like special cases in languages. In C++ you decide for yourself if you want to pass by value or by reference. I agree, that there are not a lot of cases where pass by value (or let's call it what it really is, pass by copying) on objects makes sense and is a sure way to make a very slow program. So you just get used to the habit of writing the const& behind the type. Or if it needs to be changeable only &. So basically it is just syntactic sugar, but I really prefer it the way it is.

As I said, it has its place in a few specialised areas, but it's not the general purpose tool it one was. It just seems like Bjarne can't really see that.

Hmm, I know of parts of OSes (Windows), device drivers, Office, UIs (e.g. KDE), Games and a lot of other stuff being written in C++. Seems quite general purpose, to me at least.

Re:Tiresome evangelising

[JLeslie]

I never used Java (tried it a bit and intend to use it soon), but that sounds terrible. I don't like special cases in languages. It's actually not really a special case when you consider what's going on in the JVM. Aside from the native types (int, char, boolean...) the only other type is reference. All of these types are copied onto the new stack frame when a method is called (it is pass by value). Working with objects implicilty involves working with these references, but the abstraction works pretty well so you don't have to think about it. Like I said, I thought it would be bad at first too, but I've not found it to be a problem in experience.

For the record, I'm by no means a Java evangelist. There's a few design decisions that seem wrong at this point (checked exceptions for example). But, thinking that because a language is 'harder' immediately makes it 'better' is not the way to go. I don't think this is the point you're making, but some people seem to think that way.

Re:Tiresome evangelising

[Josef Meixner]

There's a few design decisions that seem wrong at this point (checked exceptions for example). But, thinking that because a language is 'harder' immediately makes it 'better' is not the way to go. I don't think this is the point you're making, but some people seem to think that way.

There are a lot of design decisions which are outright terrible in C++. The behaviour of objects and the native C-arrays is completely broken (most people don't know the exact rules there) and there are a lot of strange things (multiple virtual inheritance and constructors is another very surprising thing). I fear no language you can actually use is free from those things. C++ just has a particular bad way of being taught, people start with C, learn the terrible way to do array and string manipulation the C way and then use that in C++ where there are much better ways.

And no, implicitely harder does not mean better, I am not even sure languages should or can be ranked. It all depends on what you want to do. I for example am writing a raytracer in my spare time and I guess we agree that Java wouldn't be a good choice and Smalltalk would be terrible. As always it depends on the use what is best. But I do think that Bjarne Stroustrup is right when he says that C++ needs experienced developers. It is a very powerful language and its more esoteric stuff (like templates and multiple inheritance) can be used for very powerful abstractions. But they need experience and knowledge and most importantly the knowledge when not to use them.

Re:Tiresome evangelising

[pjt33]

No, Java is pass-by-value.

Re:Tiresome evangelising

[JLeslie]

No, Java is pass-by-value.

Sorry I should have been a bit more clear, the native types are passed by value, but in the case of passing an object, it's the reference that's copied into the new stack frame. C++ will, by default, make copies of objects that are passed into methods (analogous to calling 'clone' in Java).

Re:Tiresome evangelising

[EvanED]

I never used Java (tried it a bit and intend to use it soon), but that sounds terrible. I don't like special cases in languages. In C++ you decide for yourself if you want to pass by value or by reference

It's not really a special case though, because Java *isn't* pass by reference. It's pass by value. It just passes references by value.

If you think of reference = pointer then there's no confusion, and no special case.

I'm not saying Java is a great language (I'll take C++ any day), but this part is not as conceptually unclean as it seems.

Re:Tiresome evangelising

[koh]

What kind of language would have resulted from passing variables of type int by value and objects by reference?

C#. And everything targetting the .NET platform.

Sorry, but I don't think I would want to program in that.

It's actually not that bad once you grasp the strange concepts of "value" and "reference" types. I.e. an int is a value type. A string is a value type. A class instance is a reference type, but a struct instance is a value type. Are we sufficiently confused yet ?

Re:Tiresome evangelising

[try_anything]

I think the clearest way to say it is that Java is pass-by-value, and all Java variables and method parameters hold primitives or object references, never objects. Since a method parameter never contains an object, an object can never be passed. A reference to an object can be passed, and it will be passed by value.

Re:Tiresome evangelising

[JLeslie]

It just passes references by value. At the risk of sounding pendantic, I'm pretty sure that's what 'pass by reference' means. You aren't doing anything different when you stick an & in front of your objects in a method call in C++.

Re:Tiresome evangelising

[EvanED]

The following prints 1:

#include <iostream>
 
struct C {int x; };
 
void foo(C & p) {
  C l;
  l.x = 1;
  p = l;
}
 
int main() {
  C l;
  l.x = 0;
  foo(l);
  std::cout << l.x << "\n";
}

The following should print 0 if you take the time to clean up any compile errors:

class C { public int x; };
 
class JavaBites {
  public void foo(C p) {
    C l = new C;
    l.x = 1;
    p = l;
  }
 
  public int main() {
    C l = new C;
    l.x = 0;
    foo(l);
    System.out.println(l.x);
  }
}

This is what I mean when I say Java passes a reference by value.

In C++, I don't know that it really makes sense to say that it passes a reference by value... it's possible that people refer to that sometimes (possibly even the standard), but conceptually I don't think it makes too much sense. It's only when you drop to the implementation perspective and realize that references are syntactic sugar for pointers that it makes sense.

But while C++ references are implemented *using* pointers, and are syntactic sugar around pointers, Java references ARE pointers. (The syntax differs from C++ because it uses . instead of ->, and you don't have pointer arithmetic in Java, but other than that the semantics are the same as C++ pointers, and there is no equivalent entity to C++ references.)

Aspect Oriented Programming

[Anonymous Coward]

I actually code in AOP everyday at work - and couldn't imagine life without it. Sure, it is a bit difficult, but then you start to understand and appreciate its beauty. It is perfect for my job, Hardware Verification.

The language I use is 'e'. Take a gander at http://www.ieee1647.org/ if you are interested.

Long Memory...

[evilviper]

Can you even remember the world before Google? (It was only five years ago, after all.)

Vividly... Searches for Hippopotamuses turned up porn. Searches for C++ turned up porn. Searches for Slashdot turned up porn...

Other than the porn, there were dozens upon dozens of pointless hits for sites that only in-passing included the search term you wanted, and perhaps not even that, as search engine databases were often years old, and sites completely changed in that time. What's more, there was never any spell-checker, so with a trivial mistake, you could be wasting all that time with the wrong term, and never find what you want.

Finding anything was laborious and extremely time consuming. Now with Google, almost ALL search engines have raised their standards near the Google level (alltheweb seems to be somewhat of an exception) and now only a tiny fraction of searches turn up page after page of pointless crap.

However, Google doesn't seem to be improving much these days, while there are obviously other ideas to be explored. On vague or expansive subjects (or just if you aren't particularly good at searching) Clusty tends to be a better bet, as it automatically categorizes your results for you, allowing you to trivially easily narrow them down... much moreso than if you just included additional categorizing terms in the search.

Can you imagine the world without the Web? (It was only about 10 years ago.)

Yes... fondly. Links neatly grouped together in the same spot on every page, not in colors that blend in with the background, in tiny font sizes, or hidden in buggy, inconsistent javascript sub-sub-sub menus.

No god awful color schemes, or Flash-only sites. No sites that have huge columns on the left and right sides (with almost nothing useful in them) that squish the center column (content) down to one-word-per-line (I'm looking at you, Slashdot).

Never a single site that depended on your screen resolution (now all but 0.01% of websites are utterly unusable in 640x480 or below).

No cookies, no javascript, no background images, no BLINK element, no pop-up windows, etc. To make a site, you actually needed CONTENT, not overindulgent designers.

Re:Long Memory...

[Anonymous Coward]

Before Google, websearch gave people what they really wanted.
Now, people get useful information.

Re:Long Memory...

[Anonymous Coward]

Can you even remember the world before Google? (It was only five years ago, after all.)

Vividly... Searches for Hippopotamuses turned up porn. Searches for C++ turned up porn. Searches for Slashdot turned up porn...

Ahhh - those were the days!

Re:Long Memory...

[Anonymous Coward]

Can you imagine the world without the Web?

Yes... fondly. Links neatly grouped together in the same spot on every page, not in colors that blend in with the background, in tiny font sizes, or hidden in buggy, inconsistent javascript sub-sub-sub menus.

Are you thinking of Gopher? Or are you describing in fact, the world with the Web (just in its early days)?

Re:Long Memory...

[Anonymous Brave Guy]

Searches for Hippopotamuses turned up porn. Searches for C++ turned up porn. Searches for Slashdot turned up porn...

As opposed to Google, where searching for almost anything turns up an ad for buying it on eBay, an ad for downloading ringtones for your phone, a dozen price comparison/review sites (with a dozen links each) none of which has any human-written reviews of the search item, a sponsored ad for someone selling a related item, and a reference to the Wikipedia article?

Re:Long Memory...

[evilviper]

Or are you describing in fact, the world with the Web (just in its early days)?

In the earliest days, everyone copied Gopher, of course, since it was the standard. However, doing that meant lots of extra work and HTML markup, which Gopher didn't require at all.

The fact that HTML doesn't enforce a reasonably strict layout, and standard tags that can be easily parsed by machine, has been it's weakness, even if you can vaguely imitate the end result (in specific circumstances).

Re:Long Memory...

[evilviper]

As opposed to Google, where searching for almost anything turns up an ad for buying it on eBay, an ad for downloading ringtones for your phone,

There's a world of difference between ads on the page, and unrelated search engine hits in the body.

a dozen price comparison/review sites (with a dozen links each) none of which has any human-written reviews of the search item, a sponsored ad for someone selling a related item, and a reference to the Wikipedia article?

There are a few of those, unfortunately. However, they are almost always on uncommon/rare terms, where they aren't as important (and you can always report that to Google as spam).

It's not a panacea, but it's several orders of magnitude better than things were before Google came along. Before Google, EVERYTHING was crap. Now, just a few select things are crap.

Mars rovers in C++?

[mi]

Yes, I think so too. In addition, I don't think, the Mars rovers certainly aren't programmed in C++ either... Would be pretty lame for the author of the language to claim credit like this...

Re:Mars rovers in C++?

[thebjorn]

Yes, I think so too. In addition, I don't think, the Mars rovers certainly aren't programmed in C++ either...

They used elements of Roge Wave Software's Tools.h++ library. It was before my time as tech lead for that product, but I remember we had a picture of the rover on our homepage for a while.

Bjorn

Early 1990's is indeed "about 10 years ago"

[Anonymous Coward]

So you think it's worth arguing the toss about whether 1992 is "about 10 years ago", which means you're arguing about how vague the term "about" is, which means you seem to be missing all of the major points.

Go back much more than 10 years, and most people had next to nothing to do with the web; for most practical purposes "the Web" as we know it today (in practical terms) wasn't there.

But then you didn't manage to spell Bjarne's name correctly, so why would I expect you to make useful criticisms?

Bjarne Stroustrup

[idlake]

Bjarne Stroustrup is the problem with programming. C++ is probably the worst widely-used language design the industry has ever seen. And what makes it particularly insidious is that it seems useful and powerful, that is, people get started with it, like the raw power and performance they get, and often never figure out the profound problems the language has.

Re:Bjarne Stroustrup

[hey!]

Power is the problem.

The most powerful flow control construct is if/then goto. It's more power than you need.

Likewise C++ has more features than anybody needs, although most of the features may be needed by somebody some of the time.

This is not a criticism of Stourstrup; C++ simply implements what everyone thought was necessary in a high performance OO language twenty five years ago. Since the paradigm was not in widespread use, it's no surprising that the design is different from what we'd come up with today.

Re:Bjarne Stroustrup

[Anonymous Coward]

the profound problems the language has.

Like?

Re:Bjarne Stroustrup

[idlake]

This is not a criticism of Stourstrup; C++ simply implements what everyone thought was necessary in a high performance OO language twenty five years ago.

Sorry, no, that's false. People knew pretty much as much about OOP and high performance language implementations back then as they do today: dynamic compilation, dynamic optimization, generational garbage collection, incremental compilation, runtime class updating, method dispatch optimization, etc.

Since the paradigm was not in widespread use, it's no surprising that the design is different from what we'd come up with today.

We haven't "come up" with anything "today". What happened is that people like Stroustrup incorrectly postulated 25 years ago that efficiency was more important than good design and designed languages without what they naively considered "inefficient" constructs. We have been spending the last 25 years putting these features back in again. Today, Java and C# are almost where OOLs were before C++, except that Java and C# are far more bloated and less consistent.

Stroustrup was simply wrong, and he could have known better if he had done his homework.

Re:Bjarne Stroustrup

[Anonymous Coward]

Foremost, lack of runtime safety. Unnecessary language complexity and lack of crucial features like reflection and garbage collection are additional serious problems.

Re:Bjarne Stroustrup

[bored]

25 years ago Stroustrup wasn't wrong, I would like to see you run a modern java enviroment on a 64k machine (no, the embedded java systems that remove most of the language don't count). Performace did matter back then, for example the much toted java garbage collection system would take up 100% of a 8mhz 286's cycles just figuring out what could be released.

designed conceptually in isolation?

[mr_tenor]

"It is impossible to develop a framework such as GStreamer in isolation as there are always usecases and trouble areas that get lost or design decisions who seem clever from the framework point of view but which is a complete fuck up from the application developers point of view. This is a big part of the reason why GStreamer have taken so long to get to where it is today."

http://blogs.gnome.org/view/uraeus/2006/12/08/0

There are very few cool C(++) programs out there

[Casandro]

Well the problem with C(++) is that it wasn't actually "designed", but just an ugly conglomeration of features which turned out to be easy to implement at the time of writing the compiler.

Just look at it. His standard book about C++ has 956 pages and even he himself tells the programmers to not use all those features.

The language itself is very chumbersome to use. Creating an object typically takes you a _lot_ of lines and concepts like copying objects create incredibly bloated code. (I have been writing commercial software for several years in Delphi and never had the desire to copy an object)

Some features are just halfway implemented. Look at operator overloading. It only works in some cases on some operators.

Of course, you can write efficient code in C(++), but it's hard. And most programmers don't work hard enough to actually write such code. That's why computers seem to not get faster since the mid 90s.

My point is, if you want to write in C(++) you need to learn how to do it. You need to learn what it does, even down close to the hardware. Then you can write in those languages. If you don't want to do that, then C(++) is not the language of your choice.

What you never knew about C++

[3dWarlord]

You might think twice about using C++ after reading this interview with Mr. Stroustrup.

Re:What you never knew about C++

[Anonymous Coward]

Pretty sure that's a well-known fake interview, so take it as humorous, but not as accurate.

Re:What you never knew about C++

[timetourist]

LOL I believe there is some truth in that intervview

This stuff is not even funny

[igomaniac]

I have quite a bit of experience with C++ and this example is just _one_ of a seemingly unending list of problems that bite the unwary C++ programmer. And without 10s of years of experience, there is _no way_ you can know about all of these. Some of my other 'favourites' are problems related to ordering of construction/destruction of static objects, virtual overrides becoming overloads without warning (try to change one of the arguments of a virtual function to be 'const' in the base class and what happens if you forget to do the same change to the override in some derived class?), all kinds of memory overwrite bugs caused by hanging on to pointers to memory that have been freed, being able to pass the address of an object on the stack out of a function (there is no excuse for this, the kind of program analysis done by optimising compilers could catch this easily -- the worst thing is the code often works at first but breaks much later when no-one has a clue where the bug is). And so on, and so forth...

Unfortunately the code I write is performance critical, so I have to put up with the nightmare that maintaining and extending a million line of code C++ project is...

Re:This stuff is not even funny

[Cthefuture]

This is true of all programming languages I have used. They all try to do a good job but in the end they only protect you from certain things and they all can bite you in the ass if you don't know what you are doing. They all require memorization of odd quirks. That's why programmers are always seeking the one perfect language even though you hear people chant about using the right tool for the right job. It's hard enough to write proper code but then you add the pain in the ass of remembering all the specific behaviours of each tool and it's just too much.

As they say: I have yet to see a language can "do what I mean" rather than do what I wrote.

I doubt we will ever see such a language until I can have a discussion with my computer about what I want to accomplish.

Re:Const - the ugly

[igomaniac]

... and now explain how using the 'const' keyword interacts with overloading functions and how it works with templates

class A { virtual void f(const A *pA); }
class B : public A { void f(A *pA); }

quick, which functions are the following calling?

A *p = new B(); p->F(p);
const A *p = new B(); p->F(p);
B *p = new B(); p->F(p);
const B *p = new B(); p->F(p);

And that's just overloads...

Re:There are very few cool C(++) programs out ther

[igomaniac]

I think you're right, you have to know C or C++ intimately to be able to write correct code. C++ is a half-assed attempt to add modern features to C which results in an explosion in complexity. The thing is, C is not an easy language to program in because there is almost no protection against shooting yourself in the foot. Luckily C is pretty small and simple, and it is possible to understand the language well enough to be able to write a simple compiler after you've used it for a couple of years. Now C++ is pretty much impossible for one person to understand. Even the compiler writers find themselves struggling with the specification. If anyone still have doubts, have a look here http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_de fects.html for some eye-opening reading material...

Only it's not C++

[krischik]

Apart from the fact that the #includes are missing it's not C++. Shure (with the missing includes) it might compile. But it is not the way it is done in C++.

The C++ (as well as C99) standart define 0 to be the null pointer. With older C standards that was different and there where indeed some platforms with:

#define NULL ((void*)-1)

which means that

if (s && s[0] != '\0')

won't work. But that' all over now - it's the null pointer is 0 now. on the other hand C++2008 is likely to get an extra null pointer keyword.

But it does show the greatest problem of C++ programming: Most C++ programmers don't actualy know how C++ works. And just because MS used NULL it does not mean it is current standart.

Martin

Re:Only it's not C++

[Z34107]

Apart from the fact that the #includes are missing it's not C++. Shure (with the missing includes) it might compile. But it is not the way it is done in C++.

The Windows API is written in C, and designed for C. Of course it's not C++.

MFC - the Microsoft Foundation Classes - are a C++ object-oriented encapsulation of the original C API.

Besides, just correcting parent poster (who didn't use correct cout syntax, or #include . But, yes, you would need a #include at the top of your program, and you'd probably want a #define WIN32_LEAN_AND_MEAN if you want to keep your program size smallish reduce your compile times.

The C++ (as well as C99) standart define 0 to be the null pointer. With older C standards that was different and there where indeed some platforms with [...]

That's nice, except windows.h defines NULL to be 0. You can also use HWND_DESKTOP for the first parameter of MessageBox(), or the actual window handle to your program. You're also forgetting that C has been ANSI/ISO standardized, too.

Most C++ programmers don't actualy know how C++ works. And just because MS used NULL it does not mean it is current standart.

Silly you - it doesn't matter what the current pointer standard is; the first parameter isn't a pointer, but a window handle (hwnd). Besides, I'm pretty sure Microsoft decides what's "standard" for their own API. You may not want to use NULL in other programs, or you may want to #define your own if you're paranoid about it compiling in Borland Turbo C.

As for the slam on C++ programmers from a person who didn't recognize C code... We'll leave it at that.

Re:Only it's not C++

[krischik]

You're also forgetting that C has been ANSI/ISO standardized, too. I did mention that C99 defined the null pointer to be 0 as well. But then there is only one compiler which implements the C99 standart [1].

Silly you - it doesn't matter what the current pointer standard is; the first parameter isn't a pointer, but a window handle (hwnd). Indeed, silly mee. But then how am I supposed to know that the first parameter is a window when a null pointer is passed in (in which case it won't matter is old fashioned NULL or a modern 0 is used)? There is more to strong typing (which C/C++ does not posses) then an error message. There is readablity. For that best would have been an NWND constant or prehaps (hwnd)0.

Martin

[1] http://www.comeaucomputing.com/

Re:Only it's not C++

[Z34107]

Indeed, silly mee. But then how am I supposed to know that the first parameter is a window when a null pointer is passed in (in which case it won't matter is old fashioned NULL or a modern 0 is used)? There is more to strong typing (which C/C++ does not posses) then an error message. There is readablity. For that best would have been an NWND constant or prehaps (hwnd)0.

Can't say I know if the C++ standards include strong typing, but most compilers I've used, do. Microsoft's Visual Studio will throw you a warning or an error depending on how cranky you have the compiler set to be (defaults to a warning in most versions.)

I'll give you readability - Microsoft uses HWND_DESKTOP instead of NULL. The first parameter is the "parent window" the message box belongs to; since our program has no window, per se, it "belongs" to and is clipped by the desktop, hence the HWND_DESKTOP. Some people (and too many textbooks) use the NULL constant (again, from windows.h, nothing to do with pointer definitions) to emphasize the fact that the message box does NOT have a parent window. Others are confused and think a pointer of some sort is being passed and not a window handle (big difference, HWNDs are NOT dereferenceable.)

Re:Only it's not C++

[pthisis]

The C++ (as well as C99) standart defines 0 to be the NULL pointer

Not strictly true. See the comp.lang.c FAQ for details. 0 in pointer contexts is recognized as the NULL pointer by the compiler, but that's not equivalent to defining 0 to be the NULL pointer.

It's true that

my_pointer = 0;

will set my_pointer to the NULL pointer, and that things like "if(my_pointer==0)" are safe.

But e.g. trying to memcpy 0 into a pointer is not guaranteed to give you a NULL pointer, while memcpy of a NULL pointer into another pointer will make the second pointer NULL.

Re:Only it's not C++

[bored]

the first parameter isn't a pointer, but a window handle (hwnd).

Just a minor pick, but a HWND is a "pointer" in this case to a pointer. Where I come from a handle is defined as a pointer to a pointer. This is due to proper heap managment. Today most people just assume that the virtual address space is unlimited and they don't worry about heap managment. Heap compression is a a very valuable idea, if a little lost in the modern world of 64-bit virtual address spaces and fixed size pages. Windows is old enought to know what a handle is if you read the goobly goop in the header file you find that it is a pointer to the declared type. Wikipedia defines a handle as a smart pointer http://en.wikipedia.org/wiki/Smart_pointer and points out that the values acting as pointers can be array indexes or something similar (in the case of unix file handles) but the concept is the same.

BTW: I'm of the school that C programmers are C++ programmers with less education.

Re:Only it's not C++

[Z34107]

A handle is NOT a pointer to a pointer; in CS lingo, that's a "vector." (Not to be confused with the C++ vector class.)

A handle is a "token" Windows gives the resources it controls - open windows, files, icons, etc, all have their own "handles." They cannot be dereferenced - they're not pointers to ANYTHING. The Windows API just uses them to number the things it keeps track of.

Go ahead and try it - call CreateWindowEx() and save the HWND window handle it returns. Try typing **hwndMyWindow once and watch your IDE debugger whine at you. This is because they're NOT pointers; they're more like coat check tokens. You give one to Windows, it gives you your resource because Windows, and Windows only keeps the actual pointers.

Re:Only it's not C++

[bored]

I don't know about your CS, but I've never heard a pointer to a pointer called a vector. I've always used vector in the same sense as math class. Which BTW, the STL vector conforms to, because it is an n dimensional vector AKA an array. A quick google search on vector didn't yield any results, got any references? I'm just curious, terminology is definitely not always standardized.

Secondly, a HWND is a pointer to the WND structure which is a reference to the window. Just because you can't easily dereference it with your debugger doesn't make it so. On 16-bit windows the HWND was a pointer to a localalloc heap owned by USER and GDI (all you have to do is find the right heap). On 9x systems this was modified slightly and some games were played at the last minute before release to extend the GDI heap past 64k. But its still the same basic game, look at windows 95 system programming secrets for some info. You again need to find the base of the GDI DGROUP to dereference it. With NT its still there, only its read-only (since you could dork with other processes windows if it wasn't), again the game is to find it. Here is a good start http://www.winterdom.com/dev/ui/wnd.html

Now maybe we are discussing semantics, I guess you might define anything that isn't directly dereferencable as a token. I'm calling it a pointer because in the right context it is. I do system programming for a living and I'm used to something only being a "pointer" in the correct context. By this maybe we would like to call the "token" an index or the converse. Whatever...

Re:Only it's not C++

[Anonymous Coward]

C++ is a strongly-typed language.

It also intentionally maintains backward-compatibility with C.

I hope that folks who say otherwise are not, for example, suggesting
that "strongly typed" languages which also nearly require you to accept
and exception now and then are less strongly-typed than C++ is.

Please take some time to consider the problem, as very little of your
time is required to truly confirm that this is not the case.

Most programmers are arrogant

[timetourist]

For those of you that say you have to learn all these all these algorithms and correct way of doing things what would you do when you have to program a quantum computer where none of what you learned before seems to apply? People do quick and dirty programming in todays world but don't just casually dismiss people's ingenuity to come up with crwative solutions.

C++ a Grandparent?

[blubblub]

I would not consider C++ as a Grandparent to Java, C# or .Net. This role would belong to Objective-C and OpenStep (OpenStep also has been licensed by Sun before coming along with Java). WebObjects was the first (Web) Application Server (1995 I believe) long before Sun had anything in this area.

Re:C++ a Grandparent?

[Anonymous Coward]

I think I remember Gosling crediting C++, Objective-C, and Smalltalk in one of his talks at Java One (recorded on VHS). But I threw away the tape long ago.

I thought Stroustrup was the problem ...

[Anonymous Coward]

He's the idiot who invented C++ when C, LISP and Smalltalk were doing just fine. Not to mention Erlang.

moderation

[Anonymous Coward]

Moderation was obviously by C++ programmers who are feeling insecure about their skills. Good going, guys.

Re:Const - the ugly

[TheSunborn]

Without turning on my compiler, I would say that this is ambigious(And really really bad DESIGN even if allowed. But you can shoot your self in any language)

Do I really have to find gcc to test it :}

Not a Hack

[12357bd]

AOP is not a hack, is just one indirection level ahead of usual programming, I like to think about this kind of concepts as something that has full sense somewhere between the system and the programs.
It's not about what a program must do, it's about what should be done when a program do something.

Re: Academia vs industry

[Anonymous Coward]

Even some of the cited examples did not come from academia:

Shannon's information theory Bell labs. One can check wikipedia http://en.wikipedia.org/wiki/Shannon_information_t heory#Historical_background

Smalltalk XERO PARC. http://en.wikipedia.org/wiki/Smalltalk_programming _language

The atomic bomb started as pure research. The early investigations into the physics of the atom was pure research, however, the manhatton project was not.

It's not meant to be funny...

[Anonymous Brave Guy]

The answer to this is not to hire unwary C++ programmers, but rather competent professionals. C++ is not a language for newbies or cash-grabbing McProgrammers, and I rather doubt Bjarne or anyone else on the standards committees has ever claimed it was.

A professional would immediately tell you that you should not rely on the order of construction or destruction for statics, that the derived class implementation will hide the base class one in your const modification case (precisely to prevent the kind of problem you described, actually), that you should rarely need to use simple pointers in C++ code so your released memory problem shouldn't be a problem in practice, that pretty much any recent compiler will warn if you try to return a reference to a local variable, etc.

Most of this stuff is in the better introductory books, the main FAQ, and countless "how not to shoot yourself in the foot" guides. Anyone who hasn't come across them doesn't know their subject well enough to be using it for real. If you want to hire people in that category, sure, give them Java or something, where the balance between safety and expressive power/performance is different. Just don't expect the kind of results you could have had by paying for professionals to do the job with more powerful tools.

Re:It's not meant to be funny...

[igomaniac]

... and _you_, my brave friend, have obviously not seen the state of C++ code written by competent professionals rushing to meet deadlines and fixing bugs at 2am in the morning. Anyway, a programming language so complex it can only be mastered by the top 5% of programmers after 5 years of education and then another 5 years of experience is probably not what you'd call 'well designed'.

Re:It's not meant to be funny...

[Anonymous Brave Guy]

Competent professionals don't rush to meet deadlines by trying to fix bugs at 2am, because they aren't generally in that sort of position in the first place. Even if they were, they'd realise that coding for stupidly long hours at a time does not yield net productivity increases anyway.

As for C++, my experience is that the top whatever proportion of programmers are up to speed and avoiding the sort of kindergarten mistakes that critics like to shout about within a few months, or faster if they have decent training/supervision. The people who still don't get it after 5 or 10 years either aren't trying, or aren't the people the language is aimed at.

It's all completely logical!

[Anonymous Brave Guy]

Nice trick question.

For one thing, C++ is case-sensitive, so your p->F(/*whatever*/) calls have nothing to do with the f members of your classes.

For another, class visibility defaults to private, so you can't call any of your member functions via a pointer (other than from within the same class).

Next up, and this is perhaps where you think there is a difficulty, there are no overloads or overrides in your example at all. The function f in class B hides the function of the same name in class A because of the different parameter types. Any call through an A* can only see A::f. Any call through a B* can only see B::f.

So, assuming we change the function identifiers to be consistent and that you're calling from somewhere with access to private members, the compiler has only one possible call to consider in each of your example cases. If const correctness permits, it will use it. Otherwise, the code will fail to compile.

That means the answers are:

First case: calls A::f

Second case: fails to compile (can't call a non-const method on a const pointer) or would call A::f if this were made a const member function

Third case: calls B::f

Fourth case: fails to compile (same as second case), and would still fail to compile even if the member functions were made const, as it can only see B::f and that requires a non-const A* parameter.

Really, if you understand a few basic rules, this sort of thing is all pretty obvious. Not good design, of course, but obvious all the same.

Re:It's all completely logical!

[igomaniac]

yes, my example was made up as I typed so it would of course not compile. I though the reader would use their imagination to understand the problem I was hinting at instead of nitpicking about adding things like public: qualifiers which would have made the example longer. The point I was getting at is much better detailed in the C++ FAQ at http://www.parashift.com/c++-faq-lite/const-correc tness.html#faq-18.12 -- const overloading is very easy to get into trouble with because it breaks virtual overrides easily and without warning. It's a definite misfeature, and newer (and frankly better designed) programming languages like C# makes it impossible to make this mistake.

Re:It's all completely logical!

[Anonymous Brave Guy]

The point I was getting at is much better detailed in the C++ FAQ at http://www.parashift.com/c++-faq-lite/const-correc tness.html#faq-18.12 -- const overloading is very easy to get into trouble with because it breaks virtual overrides easily and without warning.

It does nothing of the sort. The use of so-called const-overloading is a natural consequence of the concept of const correctness, which in turn is a simple yet powerful idea that prevents several otherwise-common classes of programmer error. I have never in my life "got into trouble" with this concept, and nor has anyone else whose code I've reviewed. If you really think this is a problem, perhaps you should stick with C#... or maybe knitting.

Compiler design book

[igomaniac]

Advanced Compiler Design and Implementation by Steven Muchnick is a good book in my opinion. Did you try that?

Re:Compiler design book

[Anonymous Brave Guy]

Thanks for the tip. Looking that up on Amazon, it does sound much more like what I've often looked for than anything I've encountered in my local (university) bookshops. A couple of the other books people bought at the same time are also new to me and look promising, so you might just have identified something I've been wanting for years. Thanks again!

Good plan.

[Generic Player]

Lets rely on programmers to know everything and be perfect, rather than having languages that don't suck. Programmers should never be making mistakes anyways, and its easy to always remember the hundreds of C++ problems that will bite you when coding at 3 am in crunch time. Who needs to concentrate on the problem at hand anyways, much better to use your precious memory on remembering how to avoid getting bitten by a hostile language.

Re:Good plan.

[Anonymous Brave Guy]

It's not relying on programmers to be perfect at all. It just requires someone to pick the right tools for them.

Personally, I am much happier with tools where fine programmer control is possible, such as C++. I write high-performance mathematical code for a living, and this stuff matters in that context. I am also happy spending some time learning how and why different programming languages work as they do, and how to take advantage of each without hitting the gotchas.

Others may not have the time or inclination to study their tools as much as I like to, and may not need the kind of control that is useful to me. For them, other languages are unquestionably better choices than C++.

This isn't to say that either C++ or safer but less flexible languages suck. They are simply different tools for different jobs, and as always, a skilled practitioner will choose the one that's right for him and for his current job.

Re:Good plan.

[Generic Player]

Why do you make the assumption that well designed languages that aren't full of horrible ways to accidently shoot your feet off are "safer but less flexible"? What makes languages that are designed to help you instead of hinder you "less flexible" exactly? Take D for example, its basically C++ as DESIGNED by someone who actually has experience having to write code. Where is D or ocaml or SML or lisp any less flexible than C++?

And high performance mathematical code is not exactly a great fit for C++, why aren't you using fortran if performance matters so much? Hell, if you have so much time on your hands to study C++ so much that you don't get bitten by its hundreds of stupidities, why not do it in ASM?

Re:Good plan.

[Anonymous Brave Guy]

Why do you make the assumption that well designed languages that aren't full of horrible ways to accidently shoot your feet off are "safer but less flexible"?

Because by their nature, safety and flexibility are almost invariably opposite ends of a programming language spectrum.

Take D for example, its basically C++ as DESIGNED by someone who actually has experience having to write code. Where is D or ocaml or SML or lisp any less flexible than C++?

I spent a bit of time exploring D. And then I dropped it, in the same pile as Java, as having a few improvements over C++ and a few steps backwards, but overall nothing revolutionary that would help me enough to justify the switch. The fact that the Digital Mars web site has a grossly misleading feature comparison chart between D and other somewhat similar languages did not exactly fill me with faith, either (and no, listing a gazillion footnotes under C++ entries by way of disclaimer is not the professional programmer's answer to such a situation, it's the marketing droid's answer).

OCaml is a nice language, in many ways, but not a good tool for systems programming. To get sane performance out of it, you have to throw away much of the functional programming stuff anyway, and its syntax for more imperative styles is cumbersome.

SML is a different tool entirely, and doesn't even have those imperative tools. In exchange for the neat features, you give up any semblance of ability to do systems programming with it.

The same is true to some extent of LISP, and in any case, some of us don't consider a near-uniform syntax for everything and anything to be a positive trait in a programming language, macros or no.

And high performance mathematical code is not exactly a great fit for C++, why aren't you using fortran if performance matters so much? Hell, if you have so much time on your hands to study C++ so much that you don't get bitten by its hundreds of stupidities, why not do it in ASM?

Why would we use FORTRAN? We typically get better performance out of C++, we can build our stuff on platforms that don't even have FORTRAN compilers, we can write stuff other than mathematical code with some degree of elegance, and in any case where there are things like BLAS and LAPACK implemented in FORTRAN, we can get ports and link directly to them via C calling conventions anyway.

As for ASM, it's not exactly portable, now is it? In any case, with modern optimising compilers and processing architectures, it's rather rash to assume that anyone but a serious platform expert would get better performance out of assembly than the compiler does.

Re:Good plan.

[Generic Player]

"Because by their nature, safety and flexibility are almost invariably opposite ends of a programming language spectrum."

That's a bizzare non-sequitur. I don't agree with this random statement either, but lets stick with the first one. Why do you think a language designed well and not full of horrible hacks and hundreds of ways to shoot your feet off is "safe and unflexible"? Again, look at D. While I admit it does have some safety that C++ does not, its not any less flexible than C++. Its just designed well and doesn't have all the crazy shit like the example that started this thread.

Or what about C? Its not safe by any stretch of the imagination. But its a very basic language with almost no features, making it very simple and easy to use. You don't have to remember hundreds of crazy things to use C in an reliable and expected manner. But C++'s huge pile of crazy makes it hard to use reliably.

What is your definition of flexible? I think ML and lisp languages are much more flexible than C++. They provide far more useful abstractions and powerful features. Do you think having pointers is the definition of flexible?

"Why would we use FORTRAN?"

Because its faster for numerical computation than C++. If you get better performance out of C++, then clearly you don't spend all that time learning that you claimed you did, or your fortran code would be much better.

I don't think you should use fortran, this was just a trick to get you to point out your own mistake. You can use fortran code from a different language without having to suffer with using fortran. You can also use C (or even C++ if you really have to) from another language. Do you really have any reason to use C++? Or do you just use it because you've never learned a good language? How much of your code really is benefitting from C++, and at what cost in maintainence and debugging?

"As for ASM, it's not exactly portable, now is it? In any case, with modern optimising compilers and processing architectures, it's rather rash to assume that anyone but a serious platform expert would get better performance out of assembly than the compiler does."

But if you really spent all that time learning the ins and outs you would be that expert. What you are really saying is its ok to have to spend 10 years trying to learn how to use C++ without shooting your feet off, but its not ok to spend 10 years trying to learn how to use other languages more effectively.

Your ignorant dismissal of other languages certainly does indicate that you are just in the camp of people who learned C++ and now don't want to admit what a shitty language you spent that time on.

"I spent a bit of time exploring D. And then I dropped it, in the same pile as Java, as having a few improvements over C++ and a few steps backwards, but overall nothing revolutionary that would help me enough to justify the switch."

Start naming specifics. D gives you everything you need from C++, only in a language that isn't actively programmer-hostile. What's the problem exactly? You seemed to be under the impression that C++ is the only possible language for your magical C++ only task. There's no reason D couldn't do it, and likely faster based on the shootout results. It may not be worth switching for you since you already know C++, but that's not the point. The point is you can easily have the power C++ gives you without having a shitty language that makes it as hard as possible to write maintainable code.

"OCaml is a nice language, in many ways, but not a good tool for systems programming. To get sane performance out of it, you have to throw away much of the functional programming stuff anyway, and its syntax for more imperative styles is cumbersome."

No you don't. You can get very reasonable performance from ocaml using functional code. And its imperative syntax is no worse than the rest of its syntax (which is admittedly not pretty). Of course, that's not the only way to go is it? Some people have foun

Re:Good plan.

[Anonymous Brave Guy]

Wow, I must have really touched a nerve there somewhere! You seem to have much stronger feelings on this than I do, so let me assure you that I am in no way a "C++ man" and in every way a "right tool for the job" man. At work, I currently write C++ for the heavyweight mathematical stuff and Perl for the analysis tools. At home, I am currently maintaining a web site, which involves PHP, Perl, SQL and occasionally Javascript. I've worked with countless other languages from C and various assemblers through Java and C# to various functional languages.

Now, to address your major points quickly...

When I'm talking about safety vs. flexibility, I'm really talking about the sort of low-level fiddling common in systems programming and high-performance fields. Either you can ignore things like type systems and just twiddle bits and hack memory, or you can't. If you can, your language is flexible in this sense but unsafe. If you can't, your language may be safer, but it will not allow some flexibility. There is a fundamental dichotomy here.

As for the numerical performance issue, I have several years of professional experience in this field, and I work with a large number of other people who do likewise, both at my own office and those we work with. We've heard this argument before, done the benchmarks, looked at the assembly. Your comments about FORTRAN are simply wrong. Think about it: what magical gift does FORTRAN have that means it can generate faster mathematical code than C++, or any other low-level language for that matter? Sure, FORTRAN effectively has built-in support for common optimisations that aren't possible using naive code in other languages, but techniques to avoid the overheads were developed for C++ years ago. Moreover, as I said before, some of the more useful FORTRAN-based numerical libraries can readily be wrapped and called from C++ to avoid unnecessary porting effort anyway.

Your assembly language argument also misses the point. We ship on probably a dozen different hardware platforms today, and the assembly languages for those are constantly evolving with the release of new processors. C++ has been standardised for nearly a decade, with only minor changes in the 2003 revision. The effort to learn C++, warts and all, is tiny compared to the effort to learn and stay up to date with a dozen different assembly languages. Why would we take the time to reinvent a wheel that specialist compiler writers have already crafted to a high standard?

As for D, check my posting history for many times I've criticised it on various objective grounds. In this particular context, one might add that AFAIK there isn't even a D compiler available on several of the platforms we support.

Incidentally, I notice that you used the word "shootout" while talking about that. I do hope your assessment of the relative performance of different programming languages isn't based mainly on a single well-known web site of relatively trivial benchmarks.

As for OCaml and getting performance out of functional code, I will simply ask you to provide a single, non-trivial example where this has been shown to be the case. I note that in everything from the kiddie benchmarks on the shootout site to the high-scoring submissions in the ICFP, the fast OCaml pretty much invariably falls back on imperative techniques. The overheads incurred in dealing with functional techniques appear to be too great for current compilers to keep up with imperative code. Perhaps this will change with the development of better optimisation techniques in time, but I'm talking about today.

Re:Good plan.

[Generic Player]

Please try to read my posts before replying to them.

"When I'm talking about safety vs. flexibility, I'm really talking about the sort of low-level fiddling common in systems programming and high-performance fields. Either you can ignore things like type systems and just twiddle bits and hack memory, or you can't. If you can, your language is flexible in this sense but unsafe. If you can't, your language may be safer, but it will not allow some flexibility. There is a fundamental dichotomy here"

I figured as much. Unsafe pointers are not flexability, they are a way to gain performance. You can still do what you want without them, it just might not perform as well. Flexability is languages like ocaml and nemerle, allowing you to use any programming paradigm you want when you want, and combining powerful features like macros in a sane and usable way. Like I said, this is irrelivant. I asked why you think a well designed language is a language without unsafe pointers. I never said anything about unsafe pointers, and like I said, C has them too, but its well designed. Same with D.

I don't have arguments for fortran and asm. Like I said, you shouldn't use them. Just like you shouldn't use C++. I was just pointing out how from your little vantage point, you see fortran and ASM as ridiculous options that would be awful to use. From the standpoint of anyone who's use a nice language, C++ is right there with fortran and asm.

Yes, fortran can be wrapped up and called from C++. Just like you can write your unsafe, bit twiddling, pointer abusing code in C, and then call it from ocaml which you use for the rest of your code. Use two good languages for the tasks they are good at, instead of using one awful language to try to do both. This is my point.

Again, give me actual concrete reasons why D is not acceptable, but C++ is. D lets you do unsafe things, high performance pointer and bit twiddling tasks, embedded asm, etc, etc. What is the problem? The gnu D compiler should work just fine on your platform, or are you seriously using some ancient 30Mhz motorola 88k based machines or something? Are you really using a platform that gcc doesn't support?

"As for OCaml and getting performance out of functional code, I will simply ask you to provide a single, non-trivial example where this has been shown to be the case."

Several of the examples you just gave of imperative code used functional code. You seem to be confused. You are saying that you are all about the best tool for the job, but yet all ocaml code must be pure functional code for no reason? Ocaml lets you use functional, imperative and OO code all at the same time for a reason. Take this for example:

http://www.ffconsultancy.com/free/ray_tracer/langu ages.html

The code is mostly functional, including recursion. It just has an imperative "main" function with a few for loops in it. Look how little code that is too, its almost like the language was meant to help you instead of hinder you. You are saying that doesn't count because of the imperative main? Even though that's the whole point of ocaml? If you want pure functional try haskell or clean. Clean is a better example of good performance from a pure functional language.

Of course, all this is irrelivant, as I said. The question here is why do you pretend that its ok for C++ to be a pile of shit, and assume that any well designed language must be taking away your precious pointers? Neither C nor D take pointers away from you. They are both nice, well designed languages. Either explain why D is not good enough for you, or stop pretending C++ is magical and that programmers should just start being perfect and never make mistakes again. C++ takes brain power away from doing the job, and puts it on dealing with C++. This is a bad thing, and its why you can do much more in much less time with D, even though its not really higher level.

Re:Good plan.

[iPatch]

OK so I found this argument amusing but really irritating. Just a few questions and thoughts:

1. Do you do a lot of numerical programming (like, solving PDEs, large linear systems, optimization, etc.)? Not just calculating the normal of a polygon.

2. Have you ever written numerical code in teams consisting of applied mathematicians, engineers and computer scientists?

I know that the engineers I work with would give you REALLY strange looks if you wanted them to learn OCaml. I'm pretty sure the mathematicians would too. C++ is a language all of these people have been exposed to. If you're doing hardcore number crunching you're writing in Fortran, C, or C++. I know of companies that were crippled by writing their libraries/applications by hand in ASM or less popular languages. It's unmaintainable. You loose the person who originally wrote the code and you're totally out of luck. You not only need to find a new bright engineer but one that knows that language well enough to debug someone else's work.

3. Have you ever maintained large numerical codes that require constant change, new features and tweaking?

OO techniques can come in very handy... Sure you can do it in C but you can really start kicking ass with a well defined subset of C++. Need more rope? Expand your subset and point out the features of the language you'll be using to the rest of the team. Is someone writing unmaintainable code? Slap 'em in the face! At the most basic level you have a language that's close to one of your advocated languages: C. You can start there and build upwards slowly depending on the experience of your team.

4. Have you worked on codes that run so long that achieving even a 3% speedup is seen as a great step forward? I'd be more than willing to bet my Intel compiler will run circles around your D compiler. Yes, circles.

5. Did C++ touch you in a bad place when you were a young programmer? Why are you arguing this with such vitriol? Can you not accept that some people _like_ C++ and all the rope that it has to offer? Personally, I have yet to get bit in the ass by C++. From the passion you apply to your arguments I must be a freakin' genius.

Re:Good plan.

[Anonymous Brave Guy]

I have read your posts, but you keep moving the goalposts. I stated, several posts ago, my conclusions about D: some possible improvements over C++, some steps backwards, but overall nothing spectacular that motivates me to move. I didn't say D was in some sense unacceptable, just that it offers me no sufficiently compelling advantages to consider it far superior to C++ as you seem to. Then again, I also don't seem to suffer from all these terrible problems you ascribe to C++.

You, however, wrote:

"Take D for example, its basically C++ as DESIGNED by someone who actually has experience having to write code."

What qualifies Walter Bright and co as "actually having experience having to write code"? Do you think Bjarne Stroustrup never wrote any real code?! He wrote a whole book on how he reached his decisions about how C++ would work, and it's an enlightening study of how to make a highly successful programming language.

So, what advantages does D really offer over C++, ignoring that hopelessly misleading feature comparison chart on the Digital Mars web site? Why should I, as a professional programmer with a tool that works well for the job I'm doing, invest the time and effort to learn a new language and port about 50 man-years of code to a relatively untried language with no standard, little formal support and minor commercial backing, and few users? What compelling advantage does your/Bright's proposed alternative offer me?

I don't understand what you're getting at with OCaml, either. Again, I have nothing against the language. On the contrary, I think in many ways it's rather nice. However, I have seen nothing to suggest that its impressive performance relative to other functional programming languages comes from anything other than its imperative roots. Moreover, if the example you quoted is your idea of typical functional programming then we have very different ideas indeed about what characterises that particular programming style. Merely using functions is not the same as functional programming, even if one of them happens to be recursively defined.

Re:Good plan.

[Generic Player]

Why are C++ fans incapable of reading? Please stop with the same nonsense that has nothing to do with what I am saying.

"I know that the engineers I work with would give you REALLY strange looks if you wanted them to learn OCaml."

I bet you they would. I didn't say they should learn ocaml. I said C++ is a bad language. Not quite the same is it? This has nothing to do with functional programming, or safe languages, or anything else. C++ is very poorly designed. It is trade off on top of hack on top of mistake on top of ugly. You can certainly avoid much of the problems with C++ if you treat it as C with classes, but avoiding most of a language because its so awful isn't exactly a glowing recommendation is it? If you are looking for a large pool of easily replacable programmers, C++ is a good choice. This doesn't make it a good language, or helpful to programmers.

"4. Have you worked on codes that run so long that achieving even a 3% speedup is seen as a great step forward? I'd be more than willing to bet my Intel compiler will run circles around your D compiler. Yes, circles."

I'm willing to bet you haven't tried it. If you are on a platform where you can use the intel compiler, then you are on a platform where you can use the digitalmars D compiler instead of the gnu one (which isn't quite as fast). Walter is a very bright man (no pun intended), and has DECADES of practical experience implimenting compilers. He wrote the first native C++ compiler. His C++ and D compilers are very good. Why are the only people who insist that C++ is awesome people who refuse to try anything else and dismiss everything else in ignorance? And of course, if you really would get such a benefit from 3% performance, you would be taking the time to add in little bits of hand tuned assembly. It doesn't matter how unportable it is, you can rewrite it once every 5 years when you switch platforms. But then, you are probably already doing that. Funny how people see C++ and bits of ASM as normal, but D with bits of ASM is just plain crazy!

"OO techniques can come in very handy... Sure you can do it in C but you can really start kicking ass with a well defined subset of C++"

Hence people doing smart things like generating the otherwise tedious and error prone redundant C code from ocaml. You maintain the ocaml code, which generates the very fast, but not maintainable C code, which doesn't need to be maintained. Or the more common, using a good language for the project, and writing the performance critical 10% in C.

"5. Did C++ touch you in a bad place when you were a young programmer? Why are you arguing this with such vitriol? Can you not accept that some people _like_ C++ and all the rope that it has to offer? Personally, I have yet to get bit in the ass by C++. From the passion you apply to your arguments I must be a freakin' genius."

Did C++ touch you in a good place? Why are you seeing this magical vitriol? Do you associate the use of words such as "shit" with vitriol? This is how I talk, sorry if you don't like it. I am not saying you shouldn't use C++, or that anon brave guy shouldn't either. I am saying that his dismissal of C++'s problems is stupid. C++ is full of problems that make programmers lives more difficult, and better languages don't have these problems. Very simple. Avoiding most of C++ will certainly avoid most of C++'s problems, but claiming those problems are ok because "good programmers" will have all the hundreds of gotchas memorized and will never make a mistake is just moronic. Sure, there are times when C++ is the right choice, like when you are stuck with existing C++ code. But you shouldn't pretend its a good language just because you haven't bothered to try anything else.

Of course, anyone who has used C++ more than a little has been touched in a bad place by it. Some people just get attached to their abuser because he says he loves them ;)

Re:Good plan.

[Generic Player]

"What qualifies Walter Bright and co as "actually having experience having to write code"? Do you think Bjarne Stroustrup never wrote any real code?! He wrote a whole book on how he reached his decisions about how C++ would work, and it's an enlightening study of how to make a highly successful programming language."

A very enlightening book indeed. Its a great book to read, and a very good example of how you can make reasonable decisions, and end up with a horrible pile of crap. Read through it and see if you can point out any individual mistake that makes C++ bad. You can't, he explains his reasoning and its always quite sane. But the end result of making tons of individual little decisions without regard for the whole is a mess.

What qualifies Walter is having written compilers for 20+ years. Frankly, having actually written C++ compilers, including the first native C++ compiler, he has more practical experience with C++ than Bjarne does. Notice all the amazingly brilliant people who were at bell labs. Notice that nobody there would use C++, even though it was designed by a fellow bell labs genious. I don't think this is a co-incidence.

"So, what advantages does D really offer over C++, ignoring that hopelessly misleading feature comparison chart on the Digital Mars web site? Why should I, as a professional programmer with a tool that works well for the job I'm doing, invest the time and effort to learn a new language and port about 50 man-years of code to a relatively untried language with no standard, little formal support and minor commercial backing, and few users? What compelling advantage does your/Bright's proposed alternative offer me?"

Why do you refuse to listen? I didn't say you should port your existing C++ to D. I said C++ is a bad language. This is clearly a pointless discussion, as you can only seem to relate "C++ is bad" to "he wants to me stop using C++". A gremlin is a bad car. That doesn't mean you need to sell yours, or buy a new car. It just means its a bad car. You can own a bad car, drive a bad car, and still realize that its a bad car. C++ is a gremlin.

I am not getting at anything with ocaml, apparently simply using any example leads to your inability to focus on the topic. Ignore ocaml, ignore C, ignore everything else. This is very simple, when you have a language like C++ with hundreds of ugly mistakes that can bite you (you even admitted it has and needs books on how to avoid these gotchas), then programmers are stuck trying to remember and deal with these problems instead of concentrating on programming. Claiming that "experienced programmers" won't make this mistakes is bullshit, and any experienced C++ programmmer knows it (wether you admit it or not is another issue entirely). Languages should not pose problems. They should not be something you need to be aware of keeping happy. They should allow you to express the solution to the problem with as little interference as possible.

I only mentioned other languages because you seem to be under the impression that C++ is the only language that can do the job you want. I pointed out that D is very comparable and does what C++ does without the constant "oh yeah, careful about hidden problem X" that C++ is full of. The original post if you care to read it again was that programmers should not have to work around and be careful of the language. Your tool shouldn't be cutting you, use a sharper knife.

Re:Good plan.

[Anonymous Brave Guy]

Its a great book to read, and a very good example of how you can make reasonable decisions, and end up with a horrible pile of crap.

Why do you persist in calling C++ unpleasant names and advocating D instead? No-one's claiming C++ is perfect. Take a look at my posting history; I've certainly criticised it many times and for varying reasons! But if it were really as bad as you make out, then it wouldn't be one of the most successful programming languages ever, and if D were so much better then surely a lot more smart programmers would have switched over by now?

I don't understand the strength of your advocacy here. You seem to have labelled me as some sort of C++ evangelist, when in fact I'm just a guy using a tool. Since we did our homework into how to use that tool and how it compared with the alternatives, I'm quite willing to stand up and defend a considered choice we made, but that doesn't mean I'd recommend the same choice for others or make the same choice myself under different circumstances. You, on the other hand, seem to think it's up to me to argue that D is not superior to C++, despite the fact that you keep claiming good things about it without actually giving any concrete examples of where it's good while C++ is a "pile of crap".

Incidentally, your claim about Bright having more practical experience with C++ than Bjarne does not ring true. He may (or may not) know more about writing C++ compilers, but C++ is useful for a great deal more than writing compilers, and being good at writing compilers is far from the same as being good at designing programming languages. I find much of Bright's reasoning behind his "improvements" in D to be flawed, while Stroustrup's considered arguments for many of the "tricky bits" of C++ that you dislike so much generally stand up to scrutiny. Perhaps this is why I like C++ as a practical tool for real programming jobs, but saw few real improvements over it in the design of D.

However, this thread seems to be going nowhere. I see now why Bjarne stays well clear of language politics. I should spend more time using the tools to do useful things and less time talking about them.

Re:Good plan.

[Generic Player]

"But if it were really as bad as you make out, then it wouldn't be one of the most successful programming languages ever, and if D were so much better then surely a lot more smart programmers would have switched over by now?"

Of course that must be true. The best things are always the most popular right? That's why windows is so popular, because its so awesome. That's why VHS killed betamax right? I guess VB used to be a pretty good language, till it mysteriously got worse right around the time MS told the VB coders to use .net. Certainly quality is the only factor determining the success of a product.

"You, on the other hand, seem to think it's up to me to argue that D is not superior to C++, despite the fact that you keep claiming good things about it without actually giving any concrete examples of where it's good while C++ is a "pile of crap"."

You said that you had to use C++ because D would not do the job. I told you to give specifics. You don't seem able to provide any such specifics (shocking indeed!). C++ is a pile of crap because of all those annoying gotchas that you already admitted fill a book. I cannot think of another language with as many warts with the possible exception of perl. I am not saying Bjarne is a dumb guy. Neither is Larry Wall. But they both made a lot of very reasonable and well thought out choices in creating their languages, but didn't consider the language as a whole. They let it "evolve" too much and didn't "design" it enough. Hence C++ and perl being such hideous monsters.

"Perhaps this is why I like C++ as a practical tool for real programming jobs, but saw few real improvements over it in the design of D."

Or perhaps, since you have admittedly already invested the time learning about much of C++'s sharp toothed and hungry areas, and you are used to dealing with that crap, you don't notice what a pain C++ is? After driving your gremlin every day for 10 years, you don't realize how awful it is till you get to drive a good car, then have to go back to your gremlin. You are dismissing D because you looked at a list of features, saw that D is not designed for the 1970s, and dismissed it. A list of choices about the language doesn't really tell you how well the language works in practice. Otherwise C++ wouldn't be so bad. Just because D offers a modern language, doesn't mean its not practical. But I suppose rational thought hasn't really been part of the process of considering D for you has it? Or perhaps you might have some actual reasons why its not able to do your super awesome math that only C++ can do.

None of this changes the fact that you pretended that C++ having a book full of traps is ok, because "experienced programmers" will have memorized them all and will always remember them. The language should not hinder you. It should not be a source of mistakes and bugs. It should not require constant attention to tricky bullshit instead of letting you concentrate on solving the problem. Why do you think languages that try to bite your ass is acceptable? Demand better instead of settling for whatever you get, you'll end up learning alot in the process of finding better tools.

Re:Good plan.

[Anonymous Brave Guy]

The best things are always the most popular right? That's why windows is so popular, because its so awesome.

Actually, I think it's more akin to why Linux is very popular for some tasks among geeks and professional sysadmins, yet rarely seen on home user desktops. It's the difference between the adoption of a mass-market, good-enough tool promoted by a wave of corporate advertising, and a tool that an informed group of users choose after serious consideration.

You said that you had to use C++ because D would not do the job.

I said no such thing. I have made no comment on what jobs D can't do at any point in this thread. I have simply argued that for the kind of work I do, D does not offer sufficiently compelling advantages for me to justify choosing it over C++.

Or perhaps, since you have admittedly already invested the time learning about much of C++'s sharp toothed and hungry areas, and you are used to dealing with that crap, you don't notice what a pain C++ is?

You know, it's funny. I've been training a new starter at work recently, someone with a background in Java but little C++. After just a few hours of training, looking at how C++ is put together and why certain things work as they do, he doesn't seem to be falling into all these terrible "traps" that are commonly asked about in on-line forums and the like. So, is this guy a genius, am I the best teacher in history, or have the newbies just not bothered reading the textbooks or getting proper training before trying to use a complicated tool?

Which isn't to say C++ isn't a royal PITA at times, of course, just that it's not usually the silly little gotchas that make it so.

None of this changes the fact that you pretended that C++ having a book full of traps is ok, because "experienced programmers" will have memorized them all and will always remember them.

Of course it's not OK. I'm still waiting to find any programming language I don't consider seriously flawed in many ways. But as a practical tool, C++ has a lot of merit for the kind of work we do, and these gotchas just aren't the show-stopping horrors you make them out to be.

C++ undeniably has an image problem, though: so many of the books are populist "50 ways not to blow the whole leg off" exercises that almost no-one has actually bothered to present the language features in a positive light as an integrated whole. Hence the only people who really appreciate things like the power of the RIAA idiom are the kind of high-flyers who also read things like D&E (or at least to read more than the first half-dozen chapters of a good introductory book). But these people don't learn all the gotchas to avoid them; they understand how the language is put together, and simply don't run into the gotchas in the first place.

Re:Good plan.

[Generic Player]

"Actually, I think it's more akin to why Linux is very popular for some tasks among geeks and professional sysadmins, yet rarely seen on home user desktops. It's the difference between the adoption of a mass-market, good-enough tool promoted by a wave of corporate advertising, and a tool that an informed group of users choose after serious consideration."

Interesting choice of metaphor, given that C++ has a windows-like position in the "market", and that its popularity is almost entirely based on early misleading marketing and OO hype, combined with the PHB mentality. Everyone I know who knows C++ learned it because "its what everyone uses", or because they had to for school or some project. C++ is where the jobs are, because the PHBs who know nothing about programming say so.

Incidently, I don't think linux is very often an informed choice. Most places I find are using linux "cause windows sucks". Very rarely have these people even considered other options, they frequently don't even know they exist. Why is linux more popular than any BSD? It has nothing to do with quality does it?

"I said no such thing. I have made no comment on what jobs D can't do at any point in this thread. I have simply argued that for the kind of work I do, D does not offer sufficiently compelling advantages for me to justify choosing it over C++."

Actually, your first reply was to inform me that in your very important work you need "fine programmer control" that C++ offers. The obvious implication being that you either think C++ is the only language that gives you this fine control, or you think C++ and java are the only languages that exist. You only fell back on "D isn't a big enough improvement to make the effort of switching worth it" after I pointed out that D gives you all the flexibility of C++ without the crap. But that is missing the point. Like I said, I'm not telling you to switch languages. I am saying C++ is a bad language. That doesn't mean nobody should ever use it, and it doesn't mean you should switch for existing projects. I just don't think you should dismiss the problems C++ has and pretend programmers should just never make mistakes. Its not realistic, and attitudes like that are what creates an expectation of mediocrity.

We can make newer, better tools using what we learned from older tools. You seem to think linux is good, but have you really considered what is so good about it? Its a poor reimplimentation of an obsolete operating system. The geniuses who made unix don't use unix anymore. Why are so many people now hung up on using a unix wannabe that totally missed the point? Just because something is popular, or the status quo, doesn't mean its good. Again, I am not saying nobody should ever use C++ or linux, just that practical considerations making them the right choice in certain situations doesn't negate the fact that they are nasty, ugly hacks that we should be striving to relegate to the dustbin of computing history where they belong.

"Hence the only people who really appreciate things like the power of the RIAA"

I think its mostly record execs who appreciate the power of the RIAA ;) (sorry, I had to)

Re:Good plan.

[Anonymous Brave Guy]

OK, I have made my usual Slashdot typo of writing RIAA for RAII. I hereby withdraw from the argument, and will hang my head in shame for the remainder of the week...

Re:Good plan.

[Generic Player]

That's ok, I still type mysql every time I mean to type myself (just did it again) and have to backspace and fix it. I haven't even used mysql in years.

The worst thing about C++: compile/link times

[truth_revealed]

When evaluating a computer language people often concentrate on generated code quality. Very few languages can rival C++ in this area. But what is often neglected is code build times. The code generated by C++ templates is pretty amazing - huge chunks of C++ code can sometimes be reduced into a few machine opcodes, but few people have the hundreds of hours per year to spare waiting for their compilers to actually build the code. I like the power and expressiveness of C++, but javac build times puts C++ to shame. Even if you rebuild your entire project from scratch in Java it is still 10 times faster than an incremental build in C++. God forbid you change a key C++ header file or something drastic. Knowing that C++ compile times are so horrendously slow, people often keep lousy base classes in place and puts hacks in derived classes that should not be there. Yes, pointer forward declarations help. Yes, Distcc and ccache are also helpful. But these techniques and tools do not address the basic shortcomings of the static C++ build process. If your build cycle is fast you can get more work done, plain and simple.

Since we're on the topic of C++

[truth_revealed]

C++ could greatly benefit from ONE standard object file and bytecode format for all OSes and CPUs. Yes, I'm a heritic. The linker or loader should be responsible for translating the standard object file format to the host's native machine code. Bjarne's biggest failure in C++ was giving too much flexibility in C++ compiler implementations. This aided early adoption of C++, but this flexibility has led to needless incompatibility - even with compilers on the same architecture and OS. LLVM's bytecode format is as good a candidate for such a universal intermediate format as any (and probably better than most). Just having a standard C++ ABI is not good enough to carry C++ forward. C++ needs a proper architecturally neutral distrobution format and a standard set of libraries. With such a format in place C++ developers might mirror the 3rd party library support success that Java and its ubiquitous .jar files currently enjoy.

When someone writes code in java here is the process:

1. Google for feature X.
2. Grab .jar file for X - almost never download the actual code.
3. write 2 lines of code in Java to call the function in question.
4. done.

When someone tries to do the same in C++, here is the process:

1. Google for feature X and C++.
2. Find something written in 1997 on some C++ compiler/platform that is different than your own.
3. download the code and see if it is compatible with your own C++ code and its myriad of compiler flags and libraries on your system.
4. try to compile it - this step usually ends in failure.
5. even if it does compile when you go to run the code it will invariably crash due to some invalid type size assumptions in the library code.
6. hack the 3rd party library source to get it to work, but you realize that it does not do what you want it to do.
7. go to step 2.
8. /*NOTREACHED*/

bullshit

[idlake]

25 years ago Stroustrup wasn't wrong, I would like to see you run a modern java enviroment on a 64k machine (no, the embedded java systems that remove most of the language don't count).

C++ was never aimed at "64k machines". The kinds of machines people started using C++ on had several megabytes of memory at least--machines perfectly capable of running other high level languages of the day. C++ use on PCs didn't become common until they reached that size and performance; prior to that, it was used mostly for research applications on UNIX workstations.

Also, C++ 20 years ago (which is when it was released) was not the same language as it is today. 20 years ago, C++ was a small, backwards compatible extension of C, implemented as a preprocessor. As such, it made sense as a temporary improvement for C until people could move to something else. Today, C++ is a different language--a bloated monster.

Performace did matter back then, for example the much toted java garbage collection system would take up 100% of a 8mhz 286's cycles just figuring out what could be released.

That's not how GC costs work; GC isn't some big, fixed overhead that you can only afford once you have a fast machine. Rather, GC costs a certain number of cycles per byte allocated. That means that the impact on a normal program running 10 sec on an 8 MHz machine is the same as on a normal program running 10 sec on an 8 GHz machine.

Furthermore, then, as now, a good garbage collector reduces the total amount of CPU spend on memory management compared to C++'s manual storage management scheme; C++ memory management is highly inefficient.

As for Java, Java's implementation of garbage collection, reflection, and other features are lousy, so you can't use Java as a yardstick. Nevertheless, C++ programs like OpenOffice and Firefox are slow and very resource intensive; evidently, using C++ as the underlying language doesn't work magic.

Stroustrup was wrong 25 years ago, and he should have known better. I was there, I know.

Re:bullshit

[bored]

Performace did matter back then, for example the much toted java garbage collection system would take up 100% of a 8mhz 286's cycles just figuring out what could be released.

That's not how GC costs work; GC isn't some big, fixed overhead that you can only afford once you have a fast machine. Rather, GC costs a certain number of cycles per byte allocated. That means that the impact on a normal program running 10 sec on an 8 MHz machine is the same as on a normal program running 10 sec on an 8 GHz machine.

Furthermore, then, as now, a good garbage collector reduces the total amount of CPU spend on memory management compared to C++'s manual storage management scheme; C++ memory management is highly inefficient.

Ok, so I exadurated a little about the 100% CPU, but the point remains. I suspect you don't really know how java does its garbage collection. Here is a nice starting point http://www.javaworld.com/javaworld/jw-03-2003/jw-0 307-j2segc.html?page=1. When your done please explain to me how that can be faster than a simple stack allocation (usually precomputed by the compiler and done when the initial stack is setup on procedure entry) done in C/C++ or a fast O(1) heap based allocator. After all the BS about garbage collection, there is still a heap sitting under it all, and the same heap algorithms are used in C/C++ as java. In fact you can change the heap allocator in C++ if it doesn't match the performace characteristics of your application.

Now, i've seen dozens of programs written in both C++ and java which are written to prove that java has faster memory allocation because of the garbage collector. In ever single case, the C++ example makes some major mistake which would not be made by an experienced C/C++ programmer. Once that mistake is fixed, the C++ version runs anywhere from as fast to significantly faster than the java version, as measured by total wall time. Usually the C++ mistake is there to give the implicit object reuse the JIT did a big boost. The point here is that while you may be able to make C++ programs slower than java, there is usually some way to tweak the C++ program to reverse the situation.

Oh, and while C++ may not have been designed for 64k machines, I ran C++ compilers in DOS and on the early mac's neither of my target machines had 2M of ram.

Re:bullshit

[idlake]

When your done please explain to me how that can be faster than a simple stack allocation (usually precomputed by the compiler and done when the initial stack is setup on procedure entry) done in C/C++ or a fast O(1) heap based allocator

You're incorrectly assuming that other languages can't use stack allocation (they can, and do, and do so more than C++), and that the C/C++ memory allocator is "fast" (it isn't, relative to a good garbage collector).

Now, i've seen dozens of programs written in both C++ and java which are written to prove that java has faster memory allocation

Which part of "As for Java, Java's implementation of garbage collection, reflection, and other features are lousy, so you can't use Java as a yardstick" did you not understand?

The point here is that while you may be able to make C++ programs slower than java, there is usually some way to tweak the C++ program to reverse the situation.

I fully agree. Were you trying to make a point?

In general, when you compare C++ to a good implementation of a good language X (and that excludes Java), you'll find that C++ sometimes wins and sometimes loses in terms of performance; but C++ almost always loses in terms of programmer productivity and software quality.

Re:bullshit

[bored]

You're incorrectly assuming that other languages can't use stack allocation (they can, and do, and do so more than C++), and that the C/C++ memory allocator is "fast" (it isn't, relative to a good garbage collector).

I never said that, I thought we were discussing C++ vs's newer languages like java and C# as they relate to having runtime features C++ doesn't have. My original assertion was that C++'s lack of many of these features 25 years ago wasn't a mistake due to constraints of the time.

but C++ almost always loses in terms of programmer productivity and software quality.

I find this to be overgeneralization, I've been involved in a large range of projects over the years using just about every major language, in nearly all the cases C++ found, or could have found a section of the project where it was the best choice for the problem. Of course I tend to use C++ as a better C, which means that just about anywhere I see C code I prefer to use C++ even if 99% of the resulting code could have compiled with a C compiler. When matched with languages like PHP for web development, RAD GUI builders (VB,Delphi,C# etc) for GUI development, database and assorted other tools, the result is impossible to beat with any single language and hard to beat with other combinations. C++ is an incredibly flexable language, that is its strong point. There are C++ libraries that put in on par with the best languages designed for specific purposes. For example, Borland C++ builder, is a far more productive enviroment for GUI development than _ANY_ java enviroment i have ever used, the diffrences are stunning. The resulting code is often of amazing high quality (as measured in customer defects per LOC).

Oh, and BTW, what general purpose garbage collection algorithm which doesn't require a heap allocator, is faster than just using a general purpose heap allocator? I'm afraid you don't understand that most garbage collectors also have heap allocators, and that C/C++ and many other languages skip the middle man and simply use the heap allocator. GC's are added for programmer safety not performace. A particular C++ implementation may have a slow allocator relative to your problem set, that is why there are other specific purpose allocators and other compiler/library/OS vendors. The C++ language standard doesn't describe how the allocator is to work. My opinion of the java GC isn't all that high either, but I know that getting a GC correct in 100% of cases is _REALLY__REALLY_ hard unless you constrain your language so much that its unusable. The fact that it works as well as it does, says a lot of positive things about the tradeoffs being made.

Re:bullshit

[idlake]

I thought we were discussing C++ vs's newer languages like java and C# as they relate to having runtime features C++ doesn't have.

No. My point (which started this thread) is that none of those languages have much of anything that's new; C++ was a huge step backwards from the state of the art at the time, and neither Java nor C# have fully caught up with where we were 25 years ago.

I'm afraid you don't understand that most garbage collectors also have heap allocators, and that C/C++ and many other languages skip the middle man and simply use the heap allocator.

Your model of how garbage collectors work is completely wrong. High performance garbage collectors aren't a layer on top of a C/C++-like heap allocator--that would be horribly inefficient--they use completely different allocation strategies.

C++ is an incredibly flexable language, that is its strong point.

I used to think so myself, but after using C++ professionally for 20 years, I can say without a doubt that C++'s flexibility is its weak point: it has enormous project management costs and no significant benefits.

GC's are added for programmer safety not performace.

Quite right. The nice thing is that you get the added safety without paying a cost in performance, which should make it a no-brainer.

Re:bullshit

[bored]

Your model of how garbage collectors work is completely wrong. High performance garbage collectors aren't a layer on top of a C/C++-like heap allocator--that would be horribly inefficient--they use completely different allocation strategies

Like what? There are dozens of heap allocation algorithms, whether or not the heap allocator is integrated into the garbage collector, or a call out to some routine is sort of irrelevant. The fact is that somewhere in the garbage collector there is some form of heap allocation/deallocation. Whether you choose to call it that or not will probably affect the maintainability of your code, more than the performance characteristics of the GC. At some point characteristics like how you select a region to be broken up, how you reuse allocation, or how you merge adjacent regions back in is a heap management problem not a GC problem.

Your right of course that a lot of language features that java and C# claim to be new are decades old, most BASIC's did GC, a number of OO languages, had dynamic binding. C++ became popular despite the lack of these features, which indicate that maybe they aren't as important as everyone would like to think. Things like true dynamic OO as represented by old school activex,COM,DCOM,OLE and now the .net components are one of the only cases where its truly proven to be helpful, and all those technologies had multiple language bindings including C++. Its the same with a lot of operating system features, mainframes from the 70's pioneered many technologies claimed by Linux/Windows/Mac crowds.

I used to think so myself, but after using C++ professionally for 20 years, I can say without a doubt that C++'s flexibility is its weak point: it has enormous project management costs and no significant benefits.

This is almost entirely dependent on your development organization in my book. The project I worked on before my current one, was lead by a C++ weenee that tried to use every feature in the book because he could. It was a mess, and impossible to work on. The current one I lead, uses a number of "advanced" C++ features, but they are used to aid maintainability. Overriding the array index operator, on a couple of utility classes used everywhere in the code so that we could use strings as array indexes, cut literally thousands of lines of BS code. Changing the locking model from a pthreads style lock to a declare the lock and then declare a class to lock it model, saved thousands of lines of exception handling code that had to be wrapped around lock/unlock pairs. Using exceptions from the bottom up, saved thousands of lines of `if (errorcondition)` code, now the exception propagates to the top level and the transaction is canceled with the possibly to retry or simply return an error. Our application has yet to be shown to leak any memory, the few that were there didn't make it out of development due to automatic memory leak detection tools, and use of automatically constrained memory buffers avoid buffer overflow problems. The flexibility allows a very small team to achieve similar results as our competitors do with 10x-25x the manpower. We have a couple of UI's one is written in java and the backlog of features in the C++ portion of the code that are not supported into the java code is enormous. Well maintainable code is more a function of the software engineering practices enforced than the language chosen. The java part of our product has actually had more memory leaks than the C++ portion, proving again that GC can fail. Heck even java now has classes which can be used to control explicit allocation/deallocation.

Re:bullshit

[Anonymous Coward]

Like what?

Like stop-and-copy, where allocation can be done simply by incrementing a pointer. No need to search around a fragmented heap for a suitably large free block in the middle of somewhere.

And before you say that the stop-and-copy is going to spend a lot of time copying objects, stop and think about the actual amortized costs compared to manual memory management; crucially, notice that manual management must pay a cost to deallocate every object ever allocated, while stop-and-copy spends doesn't need to spend any.

Mind you, the actual performance comparison is nowhere near as simple as I've presented it, and within each framework, there are improvements (e.g., hand-managed pools, generational garbage collection); but my point is that it's nowhere near as simple as you have presented it.

Re:bullshit

[idlake]

There are dozens of heap allocation algorithms, whether or not the heap allocator is integrated into the garbage collector, or a call out to some routine is sort of irrelevant. The fact is that somewhere in the garbage collector there is some form of heap allocation/deallocation. Whether you choose to call it that or not will probably affect the maintainability of your code, more than the performance characteristics of the GC. At some point characteristics like how you select a region to be broken up, how you reuse allocation, or how you merge adjacent regions back in is a heap management problem not a GC problem.

Garbage collectors usually don't do any of those things: they don't break up regions, they don't reuse allocated memory, and they don't merge blocks.

I'm sorry, but this discussion is pointless: you evidently have no idea of how garbage collectors work and lack any basis from which to argue. Since you keep comparing C++ and Java, I also must conclude that those are the only two languages you have any real experience with (both seriously flawed), which means that you, again, simply aren't competent to argue about C++ relative to the languages that preceded it.

Re:bullshit

[bored]

Jesus christ, the simple copy active regions type of heap managment (of which stop and copy is a subset) is one of the most simple types of heap managment algorithms out there. One of the reasons it fell out of use for general heap management was the requirement to double derefrence all memory through double pointers, or to manually go through all refrences and update them when the copy operation happened. Plus of course the overhead of copying memory regions around, which gets worse every year due to the fact that main memory accesses are getting more expensive. When I started programming IO and memory use was cheap, and we optimized for conditional checks, today you have to optimize for memory refrences, conditional checks are basically free.

Re:bullshit

[bored]

See my comment to the AC on stop and copy, and how people have been using similar schemes for heap managment, any why they fell out of favor. BTW what do you think the copy operations are doing if they arn't merging blocks? Also, how do you think the GC runs in a finite amount of memory if its not reusing blocks? Or for that matter were does the memory for the copy operation come from if there isn't some kind of region management?

Just because I am talking about C++ and Java which were the initial choices doesn't make it true that is all I have programmed in. I list 7 major computer languages on my resume that I have written extensive code in, without counting the dozens of scripting languages used for small side projects or pieces of larger projects, or languages I learned to gain experience. Pick another language that implements GC better, that you don't think is as flawed. How about lisp or smalltalk?

Re:bullshit

[Anonymous Coward]

I'm sorry, but your lack of understanding of garbage collectors and memory management is so fundamental that any further discussion is pointless.

Re:bullshit

[Anonymous Coward]

(Not the same person as above) After reading this whole discussion, I am convinced that "bored" is onto something. See here for an example of how Java's GC requires 5x the memory to match the performance of a certain "manual" memory management strategy. Performance of the Java GC drops dramatically as available memory drops to 3x and 2x what is available to the manual MM.

Garbage collection has gotten better with time, but people might ignore that "manual" MM has as well. The key informational advantage available to GC algorithms seems to be knowledge of how objects are related to one another (and thus how their memory-use is correlated), but this information is also available to a sufficiently-skilled programmer. Seems to be another runtime/space to skill/effort/developer time tradeoff.

Re:bullshit

[bored]

The funny thing was that paper was written in 2005, if you look in Knuth's V1 first edition, and read his section on garbage collection you get basically the same information (GC's suck when memory gets tight, the result is that a GC needs a certain amount of extra space to keep performace up). That was known in the 1960's, doesn't appear that much has really changed.

c++

[sentientbrendan]

is a monster of a language, and stroustrups knows it, but sometimes it takes an ugly monster of a language to get a job done.

Nothing will ever replace c++, except another language like c++ that provides all of its low level power. That said, I'd like to see a few outstanding issues in c++ fixed.

1. compile times. headers should be discarded, and a single implementation file approach used by java and c# adopted.
2. templates should be cleaned up a little bit. c# style generics are generally preferable (although runtime instantiation is probably impossible for a compiled language.)
3. 1st class lambda's and bindings would be nice. the stuff provided through boost is pretty awkward right now...

It would be nice if there was a language that was to c++ as c# is to java, a language that fits the same niche, but doesn't have to be compatible so that core language issues can be learned form and cleaned up. To some extent D fills this void, but I'm waiting for a more fleshed out toolchain (IDE, 3rd party libs and bindings, etc) to become available for it before I mess with it for anything more than for fun projects.

null pointer

[krischik]

I would not believe the comp.lang.c FAQ - only the ISO/IEC 9899:1999 counts. And indeed I have a copy at hand:

6.3.2.3(3): An integer constant expression with the value 0, or such an expression cast to type void*, is called the null pointer constant. So here you are: 0 is the null pointer constant. Please note the lower caps null - NULL is just a define:

7.17(3): The macros NULL which expand to an implementation-defined null pointer constant; ...-. But I give you that: there is an "implementation-defined" here - so there might indeed be another possible representation for the null pointer.

As for using memcpy: how actually are you going to memcpy a 0 or NULL? They both don't have an address to copy from.

Maybe you meant memset. But memset won't work for NULL either. Look at the prototype:

void *memset(void *s, int c, size_t n);

The bad news is: int might not be large enough to hold a pointer (It's defined in 6.3.2.3 as well) and indded is not for x86_64. One is supposed to use intptr_t or uintptr_t.

Martin

Re:null pointer

[pthisis]

So here you are: 0 is the null pointer constant. Please note the lower caps null - NULL is just a define:

Good catch on the caps.

A null pointer constant is _not_ the same as the representation of a null pointer (the "null pointer value"). A null pointer constant can be used to set or compare a null pointer only in pointer contexts.

I'll note briefly before going into more detail that the most common mistake caused by assuming that the null pointer value is 0 is to assume that:

struct foo {
  void *next;
};
...
struct foo * my_foo = calloc(sizeof *my_foo, 1);

has a null pointer as my_foo->next. It will on common platforms, but it is not required in a conforming implementation. I'm pretty sure that a null member of a static struct likewise doesn't have to be initialized to a null value, but I'd have to double-check that.

As for using memcpy: how actually are you going to memcpy a 0 or NULL? They both don't have an address to copy from.

In more detail, what I mean is that this:

intptr_t some_int = 0;
void * some_ptr;
 
memcpy(&some_ptr, &some_int, sizeof(some_ptr));

or this:

memset(&some_ptr, 0, sizeof(some_ptr));

Or even this*:

some_ptr = (void *)some_int /* some_int is 0, but not a 0 constant */

is not guaranteed to give you a null pointer in some_ptr. After any of those three, then any of the following lines:

if(some_ptr) print("Pointer isn't null!\n);
if(some_ptr != NULL) print("Pointer isn't null!\n);
if(some_ptr != 0) print("Pointer isn't null!\n);

is free to print "Pointer isn't null\n" in a conforming implementation. But if you had instead done "some_ptr=0;", "some_ptr = 3/4;", "some_ptr = NULL;" or similar (using NULL, a constant 0, or the constant 0 cast to the appropriate pointer type) then a conforming implementation would have to set the value of some_ptr to the null pointer value, and those if branches would not be taken.

So to re-phrase my statement:

Saying "the null pointer is zero" is wrong. A conforming implementation can have a representation of the null pointer that is not all-bits-zero. The NULL constant and/or a 0 constant can be used in pointer contexts to set and compare the null value of a pointer, but when you say "some_ptr = 0" there could be a lot of magic going on to set the actual value of the bits in some_ptr. In non-pointer contexts there's nothing guaranteeing a null pointer has a zero value, or that setting a pointer to a zero value will result in a null pointer. Even in pointer contexts, there's no guarantee that using a non-constant zero will result in a null pointer*.


The bad news is: int might not be large enough to hold a pointer (It's defined in 6.3.2.3 as well) and indded is not for x86_64. One is supposed to use intptr_t or uintptr_t.

The worse news is that intptr_t and uintptr_t need not be defined, specifically because on some machines there is no integer type large enough to hold a pointer. You cannot portably assume they exist. You _can_ portably treat a void pointer as a sequence of characters, which is generally the best approach if you need to play pointer games (though usually that's a bad idea).

As long as we're on the pointer subject, it's also worth noting that you can't portably assume a void pointer is large enough to hold all pointer types (it'll portably hold object pointer types but not function pointer types).

The latter relates back to the topic, because on some platforms function pointers have different representations than non-function pointers, and on some of those function pointers are the only type of pointer that has non-zero representation of the null pointer.

*There's some argument about whether an unrelated change in C99 might force this to set a pointer to the null value, but I'm unsure as to what the current consensus is. Certainly the other cases remain unchanged.

Re:null pointer

[krischik]

Thank's - you deserve an "Insightfull" for the Article!

Martin

strongly typed - in the eye of the beholder

[krischik]

and in my eyes a language which allows any of the following is weak:

unsigned i = -1;
char x[10]; x[10]='a';

However:

unsigned i = static_cast<int> (-1);
unsigned i = dynamic_cast<int> (-1);

would be OK. With the later to to raise range_error - sadly the C++ standard comite missed the opportunity to define dynamic_cast for numeric types.

Yes, you need exceptions from the type system - but they should be exceptions and not default behavior.

Martin

Re:strongly typed - in the eye of the beholder

[Anonymous Coward]

Sure, it allows this. In part, is /has/ to, since one of C++'s core principles (and one of great complexity, as Bjarne notes in his interview) is backward compatability with C. For things in which that principle isn't voilated, it's not the default behavior. In the case of the "unsigned int" type, for example, it's required for that compatibility. That sort of behavior is nearly always from that reason.

In fact, the syntax of the "C++ style" casts (dynamic_cast, stactic_cast, and reinterpret_cast) is deliberately ugly so that it's very clear when it happens (people often complain that (int)'a' in C isn't clear enough).

(Note: Your example of using dynamic_cast to cast from an int to an unsigned int won't work. That's part of what dynamic_cast is meant to prevent. It uses a pointer or a reference.)

This reasoning is similar to the claim that C++ isn't an object-oriented programming language because it has features which violate the nature of a "pure" OOPL. Well, it isn't a "pure" OOPL at all. It does, however, support object-oriented programming very, very well.

I feel that those arguments do have validity in languages which claim to be "pure", but that is not and has never been the case with C++. However, that does not mean that C++ does not support the ideas, and support them well.

Example GC

[ratboy666]

A "common" GC allocator divides memory into two regions. Allocation is done from one region, by simply returning the current end of memory, and advancing. If the allocation would no longer fit, a GC pass is made, copying all live memory to the second region.

Allocation is now a constant time operation EXCEPT for the GC, and "free" is zero time.

This can be modified to tenure blocks of memory -- if a block lives over "n" copies, it is pulled from the normal allocation, thus increasing the efficiency of the copies. (Which is the "nubbin" idea behind most generational techniques).

There is no heap structure implemented at all.

Ratboy

Re:Example GC

[bored]

BTW: this is a heap allocation scheme. Very similar to the one used on the early mac, and some other machines. Basically you copy memory around once you discover that the heap is to fragmented to make the next allocation. http://en.wikipedia.org/wiki/Mac_OS_memory_managem ent

dynamic_cast - the missed oportunity.

[krischik]

(Note: Your example of using dynamic_cast to cast from an int to an unsigned int won't work. That's part of what dynamic_cast is meant to prevent. It uses a pointer or a reference.) I know. And as I said: it is a missed oportunity.

dynamic_cast makes a runtime check to see if the source pointer is compatible with the destination pointer. As such it is the savest cast available.

It would have been easy to extend the idea of a runtime check to create a save cast for primitive data types (int, long, char). Then one would have got the matra "dynamic_cast is save" which would have been easy to teach to C++ beginners.

But sadly the C++ standart comete where so pointer centric.

Shure you can create templates for save numeric casts (the boost library got one, I programmed one myself). But they are all missing the matra value and - more importanly - are not mentioned in "Teach yourself C++ in 21 days".

Martin

Re:dynamic_cast - the missed oportunity.

[Anonymous Coward]

Good observations, and I am curious to learn the reason why it is the way it is. I can imagine that the idea of runtime type checking encountered some pretty serious opposition-- and, I'm not sure that would disagree with the choice that was, clearly, made. So maybe we aren't on the same page there-- but, you can definitely find nice libraries that help with this problem. It's great that you've even contributed to a really cool one!

I agree that unfortunately most books teaching C++ aren't very good. : The Addison-Wesley series edited by Bjarne Stroustrup is the best one I know of right now.