Slashdot Mirror
Interview Update With Bjarne Stroustrup On C++0x
An anonymous reader writes "DevX interviewed Bjarne Stroustrup about C++0x, the new C++ standard that is due in 2009. Bjarne Stroustrup has classified the new features into three categories: Concurrency, Libraries and Language. The changes introduced in Concurrency makes C++ more standardized and easy to use on multi-core processors. It is good to see that some of the commonly used libraries are becoming standard (eg: unordered_maps and regex)."
I saw the headline and thought I was seeing some 1337 form of "cox."
huhuhuuhuhuh he said "form."
You can't figure out why. You'll never know.
And that warms my heart.
will it be applied to C as well?
The grass is always greener on the other side of the light cone.
Now we got "cetox"
If anyone has used both Objective-C and current C++, can anyone tell me whether the new specification is a clear improvement on either if these?
Jumpstart the tartan drive.
"control of alignment"
I'd like chaotic good please
Knowledge is power. Knowledge shared is power lost.
Yes.
I'm a big tall mofo.
I want to like C++, heck, it was the first language I learned. But after so many hours of memory leaks and pointer-induced errors... My friend had mentioned at one point there was going to be transparent garbage collection in the C++0x standard. Unfortunately... looks like it's tabled for now: http://en.wikipedia.org/wiki/C%2B%2B0x#Transparent_garbage_collection Oh well.
Try writing a large program that needs to do heavy number-crunching in Java/Ruby/Perl/Python
Those languages are way too high level. What you make up in development time will nowhere near compensate you for the greater processing time. I mean, CPU costs are through the roof these days!
But I have to say - even C++ is too high level. I hand code assembler with vi. That's what real number crunchers do.
I'm a big tall mofo.
...or, as a former manager explained it, "When C++ is your hammer, everything looks like a thumb."
So we are going to create the unmanaged form of C#?
Politics is the art of looking for trouble, finding it everywhere, diagnosing it incorrectly and applying the wrong fix.
Have you ever tried writing a large-scale simulation code, for say dark matter/cosmology or cosmic-ray propagation in Java or C#? Please let me know when your code has finished executing.
Why the hell would you waste precious cycles running an assembler? That's what grad students are for!
You blame your memory leaks on the language? No wonder you couldn't find a C++ job.
:)
Here's some free advice: Next time you are working in a non-GC language and allocate memory, write the line that deallocates that memory next and then work from both ends towards the middle. Or, be a lazy bastard like me and do everything with std::auto_ptr.
hours finding memory leaks? How bad are you at debugging? Plus there are tons of tools to assist with memory leak detection. However, protection is no substitute for abstinence. Learn to write code better. BTW go do some embedded software with C# or Java.
I have C++ code that I maintain. It was written in 2004. I also use Firefox, Notepad++, FileZilla, 7-Zip, which are all written in C++. It seems like most the applications I run are written in C++, with many written in C and some Microsoft programs perhaps written in C#. Java killed C++? You wouldn't be aware of it from the software on my computer.
What a fool believes, he sees, no wise man has the power to reason away.
There's only one interview with Stroustrup that's worth reading: http://www.nsbasic.com/desktop/info/interview.shtml
{Science sans conscience n'est que ruine de l'âme}
C++? Isn't that dead and buried? Bjorne created one interesting thing in his life and he is hell bent on keeping it alive--after Java and C# have buried it. Anyone ever tried to get a C++ job? They are few and far between.
Maybe if you are the kind of programmer/developer that endlessly creates one-off database front end applications, this is true. C/C++ jobs are not hard to find at all. They just have a different target than you are apparently willing to work with. Try analytics. Try custom driver development.
"When life gives you lemons, don't make lemonade. Make life take the lemons back!" -- Cave Johnson
That's what this is... automatic memory management...bigger libraries... restricting pointers more and more....
I mean, C++ is evolving so badly it makes Pascal suddenly look a lot better as a compile time language.
This is my sig.
...what do people find so difficult about C++? Use the standard libraries, exception handling, and make sure your news all have deletes, and it's no more difficult than any scripting language. I actually prefer it over scripting languages, which have their place, but feel all sloppy and unspecific. It's like the difference between building a house out of 2x4s and building one out of sticks you found laying on the ground.
I'll consider Java and C# as C++ replacements once they get:
These points are serious, especially the first, without real templates, generic programming/metaprogramming at compile-time is not possible. These two are one of C++'s biggest strenghts, though.
To be fair, C# 3.0 is somewhat nice, especially its functional core. Java is a totally uninteresting language with very small expressiveness. Of course, if the job requires it, there is no discussion, but in my spare time, I prefer C++.
This sig does not contain any SCO code.
I wonder what Fred Brookes would say about that? Perhaps a revised edition of the Mythical Man Month is required here... 'cept he'll have to rename it the Mythical Man Millenium.
Seriously Bjarne, give it up already.
C++ sucked the 1st time round, the only thing he could do to fix the design mistakes would be to invent time travel and perform an actual experimental test of the Grandfather Paradox.
Oh and Taco, FFS fix the captcha system, it's not very reliable.
http://yosefk.com/c++fqa/ - this site says it all.
And it's also being argumentative and verbose at that, unlike your routine 'C++ sucks' rant.
All my favorite video game engines are written in Java I hear.
This guy is an obvious troll.
One thing I've noticed is that you're much more likely to work with idiots if working on applications that use Java or C#. As the programming language becomes more powerful, the programmers using it are often far better and of superior education and degree.
"If you are a dreamer, a wisher, a liar, A hope-er, a pray-er, a magic bean buyer
"C++0x" - it just rolls off the tounge!
But to their/his credit, from the Wikipedia entry on the "Haxe" language:
he name haXe was chosen because it is short, easy, cool, and "has an X inside", which the author claims is necessary to make any new technology a success. /quote
I really, really, really hope a lot of these things are implemented as compiler- or runtime-level features. I understand the purity aspect of implementing features as templates, but it just bloats my code and slows my compile times. A lot of the compile time for my apps is spent regenerating the same template crap over and over, then waiting on the linker to weed out what's duplicated. It takes forever.
C++ is to C as Lung Cancer is to Lung
You didn't get a big show of hands here, eh? 1997 called, he wants his raw pointers back. Nowadays we use any of the myriad freely available pointer wrappers and libraries. If you're using any framework at all, chances are you have a pointer class. STL, Boost, ATL, APR, MFC, MC++, etc. They all do. If you are a masochist, that's fine. Just don't assume everyone else is too.
Well, you're probably just trolling here, but C++ is hardly dead, and it's hardly crap. After all, the two languages you claim "buried" it are written in C++.
Web2.0: I love when people Flickr my cuil and digg my boingboing until my google is reddit and I start to yahoo
Actually I just did a couple of months ago. And I found more than one. In fact I'm sitting here at the one I took posting this while I wait for a whole lot of C++ code to compile.
You haven't spent enough time looking then for horribly crappy C++ apps. Especially in MMO emulator communities (SWGemu I'm looking at you!)
The amazing part to me is that when people try to compare managed code -- like java or .NET -- to native code c, c+++ they make these wild claims about how much faster native code is. But they fail to mention that most of the managed code is running natively. And as far as your simulation, can you reasonably explain why it would be so much faster in c++ as opposed to say java that we would have to wait forever for it to finish?
Try writing a large program that needs to do heavy number-crunching in Java/Ruby/Perl/Python, or whatever is your preferred language.
Python + Numpy is probably faster that anything most C++ programmer can write, since it uses libraries that can be optimized for the specific processor they run on, including using multiple processors/cores if available.
Hand-optimizing code that runs on modern processors is not a trivial task at all (very simple example: caches can have extremely big and very non-intuitive effects on the speed of code).
Try writing a trivial (5 or 6 lines of code) md5 implementation using only the Python standard library and compare its speed to the GNU md5sum program (written in C). Hint: read blocks with sizes of roughly 10 kB.
There's a hidden treasure in Python 3.x: __prepare__()
Anyone ever tried to get a C++ job?
I had done some very light/minor C++ dev in my time, so I included it as an item on my resume. Last time I was job hunting (about a year ago), 90% of the calls that I got were for C++ positions, which I really did not want. I ended up removing it to filter out the noise.
William of Ockham had no beard. The most likely explanation is that it was chewed off by squirrels every morning.
We will see the usual litany of C++ hating here in this thread. The hating will be generally based around misconceptions or problems that are 5 years old.
So to get them out of the way:
If you're leaking memory or spending time managing memory in C++, then you're using C++ wrong. Get a book written in the last 5 years.
If you're worried about compiler compatibility (with the exception of export which isn't much use anyway), get a compiler written in the last 5 years.
If you think that C does some subset of your task better, then write it in the common subset of C and C++ and quit whining. Or, write it in C and link it against your C++ code and quit whining.
If you think that templates simply provide code bloat, then get a compiler newer than 5 years old.
If you think C++ is slower than C, then get a good optimizing compiler (you know one written in the last 5 years) and do a benchmark. You will generally find that templates make C++ faster.
If you think "modern" languages are more expressive, then give "modern" C++ a try (insert comment about recent compilers here).
Sure there are valid complaints about C++, but the majority of them I hear on slashdot are complete bull. The majority of the remaining complaints will be fixed by C++0x.
One remaining problem is the lack of a vast array of standard, business oriented libraries. I don't write business oriented code, and I find the C++ STL one of the best libraries out there since it provides really good support for writing efficient algorithms.
Another problem is the difficulty in parsing C++. Sadly that's never going away.
But if you're going to complain about C++ compared to recent languages here, make sure that you're talking about recent C++ too, and try to make sure the complaints are accurate.
SJW n. One who posts facts.
Confucius say "Those who do not understand Lisp are doomed to reinvent it - poorly."
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
Thank the maker that I won't live to see it.
C++ is an extremely powerful programming language and that is why I use it every day. But it has one major problem: It is too complicated. As long as you do programming full time you are OK but if too much of your time is spent on the application side of things you quickly get in trouble. This is what people like BS don't seem to get - not everyone can spend 100% of their time studying the language.
You're doing it wrong.
Attention deficit disorder is a complicated issue, spanning several major... HEY LET'S GO RIDE BIKES!
I am with Bjarne on this one.
Bjarne Stroustrup, creator of the C++ programming language, claims that C++ is experiencing a revival and
that there is a backlash against newer programming languages such as Java and C#. "C++ is bigger than ever.
There are more than three million C++ programmers. Everywhere I look there has been an uprising
- more and more projects are using C++. A lot of teaching was going to Java, but more are teaching C++ again.
There has been a backlash.", said Stroustrup.
He continues.. ..What would the world be like without Google?... Only C++ can allow you to create applications as powerful as MapReduce which allows them to create fast searches.
I totally agree. If Java ( or Pyhton etc. for that matter ) were fast enough why did Google choose C++ to build their insanely fast search engine. MapReduce rocks.. No Java solution can even come close.
I rest my case.
The new "auto" declarations really fix one of the biggest gripes with C++. Everybody is dead tired of doing
std::map::iterator it = m.begin()
Now you can just do:
auto ip = m.begin()
It takes much of the pain away from static typing...
Save your wrists today - switch to Dvorak
Building a self-consistent rule set as complex as a parser/compiler combination takes years and years of work to get it right. And you're saying leave that to the programmer??? That's the biggest maintenance nightmare I have EVER heard of.
It's bad enough that a new programmer has to learn the application idiosyncrasies; throwing in the fact that every instance of the language is fundamentally different would at least double the length of the learning curve.
I do however see the appeal of having a common syntax for several different styles of programming schema. Imagine having one punctuation set and operator set for a language that can be either script-like (no typing system), strongly typed, garbage collected, etc, and have it all inter-operate. I just don't think it should be left to the whims of some dude in the back room that would never document his intent and execution properly.
If you do go ahead and write it, I nominate Female+- as the name (see http://www.anvari.org/fun/Gender/17_Female_Rules.html )
They ARE out to get you simply because They are in it for themselves and they don't care about you.
Great! That means in 2099, will have another "man made crisis" when C++99 is being superseded by C++100!!!
Or will we count by Hex? C++0x0x63?
Hopefully, we'll be up to "D" by then.
1. Boost.
2. Nonsense. Boost has facilities for this ("any", iirc) and also for something called "sum" types which can achieve what you want in a better way ("variant", iirc).
3. shared_ptr, weak_ptr.
4. Yup. Going to be fixed by C++0x.
5. C++ can be written to be a lot more portable than your Ruby or Python.
6. A matter of taste.
HAND.
.. want to read this article. The name says it all. I for one, am sticking to C. If I need to write using a higher level language, I'll go with Perl. People who need to write *fast* code, need to stay away from C altogether and need to stop adding ascii characters to C.
TOP DSLR Cameras Reviews of the top DSLRs
You actually don't build a house out of 2x4s anymore. It's a lot more of 2x6s for exterior walls and 2x8-2x10+12s for beams and the like. 2x4's are merely for interior walls, at least according to most building codes.
I just don't like the expression, since it is quite imprecise. Languages are not fast? Is English faster than Japanese?
Languages can be more concise or terse, i.e. you write little and say a lot.
Now language implementation can be faster or slower (for exact same code), and almost always is (e.g. Intel's C++ compiler vs. GNU gcc).
As the island of our knowledge grows, so does the shore of our ignorance.
Around here I see more and more housing going up without two by anything. Steel beams and laminated plywood trusses and the like are being used instead.
This update used to be called "C++9x", but the committee got lost in template la-la land for a decade.
Thread-local storage is a good idea. GCC and Microsoft have had it for a decade. There's still no language guarantee that a pointer to a thread-local variable can't be exported outside the thread. But that was already true of stack variables. (Can't say "auto" any more; that keyword has been "repurposed".)
Threading is basically POSIX threads with new paint, plus some atomic primitives that have been around in incompatible forms since the 1990s. There's no improvement in thread safety.
Unordered maps were supposed to go into the original STL years ago, but somebody didn't get the paperwork in on time. Really.
It's no safer than the previous revision of C++. We're doomed to another decade of crashes and buffer overflows. Amit Yoran pointed this out when he was the director of the National Cyber Security Division at Homeland Security. (He resigned under political pressure for pointing out that Microsoft's poor security was the biggest part of the problem.)
At least they didn't put in "concepts".
Have you the slightest clue about how computing intensive cosmology simulations are? Even on our 96 node cluster, a single simple run takes on the order of several days to finish. I have yet to see any Java/C#/Python code that can compete. I have been involved in developing code for simulating cosmic-ray acceleration in expanding supernova remnants, this in Python. It is incredibly slow and we can only compute on small grid sizes. Granted, on your little home desktop or even workstation, your managed code will do just fine. But that is on a completely different level. It is like comparing oranges and coconuts.
These are all very good points, particularly regarding RAII. I'm sure you know this already, but other languages such as Python provide deterministic resource management as well (in Python, it's the "with" statement). Java, along with C, seems to be one of the few languages that have absolutely no faculties for the RAII pattern.
That's because we're running out of good lumber (the last construction company I worked for used imported studs ,) and skilled labor. Laminates and truss systems are even easier to put together.
Ask an average framer how big a birds mouth on a (insert example of pitched roof here with dimensions) should be, compared to how to assemble a truss package. Easy, instructions and even supervisors come with truss packages.
I must be mentally ill, but, as much as I gripe about C++ and now C++0x, (even calling it C++#), I have to know, does anyone know when GNU targets the compiler to be due? I mean, I can't imagine them chasing a moving target but with the standard evolving I'm sure there's some stuff that they could work on.
I looked at their C++0x implementation web site, and it looks like they have a way to go:
http://gcc.gnu.org/projects/cxx0x.html
I like C++, even though I hate it, and this next incarnation has me tremendously excited.
This is my sig.
Maybe I'm not fully appreciating your problem with (2), but FYI, the "using" keyword in C# is pretty nice. It looks like this:
using(Bitmap mybitmap = new Bitmap(...args...))
{
// do work with bitmap
}
Once the program exits the "using" scope, the bitmap's Dispose method will be called (which for the sake of this argument is roughly equivalent to calling its destructor).
I used to think like that, but then all the things you talk about are just syntactic sugar. There is nothing you can do with proper generic that you can't do in Java or C#. Yes, C++ is way more expressive than almost any other language, but that is also its peril.
And when was the last time you used meta programming to solve a concrete problem that could not be elegantly solved otherwise.
Most people learn how to calculate a factorial using meta programming techniques and stop right there. It's more of a curiosity than useful practical technique.
As the island of our knowledge grows, so does the shore of our ignorance.
hours finding memory leaks? How bad are you at debugging?
If you think that taking hours to find a leak is excessive, the people at mozilla could do with some help -- they've been hunting them down for *years* :-P
I mod down anyone who says "I will be modded down for this", regardless of the rest of their comment
I get your view that it's easier to do stuff with C#, at least on a windows platform. But Java?
I've used Java much more than I'd like. In my experience, due to lacking basics such as proper operator overloading and some other stuff, must Java coding ends up a horrible experience. It boils down to a frustrating repetition of grunt-work, stating stuff that in C++ would be both short and much more readable, to achieve the same effect. In the end you have a big hairball of code, saying basically nothing, performing lousy, badly cooperating with ANY other process on the system, and that shameful feeling you know means you've just done a bad thing.
Add the horrible details of class-path and jar-dependencies, and the fact that most successful java-apps needs a carefully written shell-script or bat-file to even launch.
Nah, I don't get it.
What's the difference between C and C++?
C gives you lots of different ways to shoot yourself in the foot. C++ allows you to instantiate ten copies of ten feet and shoot them all at the same time.
The kernel of truth in this joke is that no language is going to make a lousy programmer into a good one. Rigor is required in every program. Rigor transcends language.
As for which language is best - learn many. Pick the best one for the given task at hand.
Weaselmancer
rediculous.
C++ was once thought to be a language that was powerful enough that it could be used to express most features that other languages had. With things like operator overloading, multiple inheritance, and templates, you could pretty much make a class behave however you want. But years later, we have seen that C++ failed at that mission. There are simple and common OO constructs that C++ is unable to represent. Rather than focusing on improving the template functionality, I want the OO syntax fixed.
Let me cite some examples:
1) It is impossible to make a string class that behaves "normally"
Plenty of people have tried. QT, Boost, STL, Gnome, WxWidgets, all have their own string classes. Years ago, when VB developers touted how easy it was to use strings compared to C++, I told them it was merely because nobody had made a good string class. After 10 years of trying to write one, and using dozens of other ones people created, I realized that C++ is simply too weak and too loosely typed to do this.
Suppose I make a string class, kinda like the STL string:
string foo;
1) foo = "whatever";
2) foo = foo + "bar";
3) foo = 7;
4) foo = foo + 7;
5) foo += 7;
Take a look at these. The first one is no problem. That can call an assignment operator to copy the char * contents to the string. The second one can also be done with a + operator. The third one can also be done via assignment. But what if you forget that? Well, the compiler will see that as foo = foo(7) which will call the constructor that allocates 7 characters, and then assign that. So instead of the string "7" you get a blank string. The next example is a problem too. If the string class can be converted to a const char *, as is common, then does this mean to use the + operator on string and an integer? Or did it mean to convert foo to a const char *, then move 7 characters ahead, then assign it? That can result in a crash. This is because pointer arithmetic is intrinsic in C++, but it is inherently type unsafe.
Then how about a function that returns a string? A simple case in most languages, but in C++ it results in redundant copies across the stack. So people revert to funny things like auto_ptr and other wrappers, or complex mechanisms for doing shallow copies to prevent that. Other languages just avoid the problem entirely by not allocating things on the callee's stack. It's just an intrinsic problem in the old everything-goes-on-the-stack-by-default mentality of C++. It just doesn't always work.
Properties are another one. This is something that various libraries try to do, and is free in most new OO languages. But just cant be done in C++ // C#
class Foo
{
private int _x;
public int x
{
get { return _x; }
set { _x = value; }
}
}
So in the above class, I want to access _x via a property get/set. C# has a built-in construct for this. In C#, I could do:
MyFoo.x = 7;
MyFoo.x++;
MyFoo.x = MyFoo.x + 3;
MyFoo.x/= 7;
etc. The compiler knows how to get/set x, and it can even be inlined! This allows me to do things like log when x changes, or see what accesses the variable. Now, let's try that in C++.
class Foo
{
private:
int _x;
public: // Get X // Set X // Another way to get/set X
int x();
void x(int);
int &x2();
};
MyFoo.x(); // Gets x, no problem // Weird syntax, but that is fine // Does not modify the value of x, hmmm... //
MyFoo.x(7);
MyFoo.x()++;
MyFoo.x2()++;// Modifies x, but only lets you track the get, not the set.
MyFoo.x()/=7;// Same exact issue
MyFoo.x(MyFoo.x()/7);
I do not understand why the post is modded "funny". Indeed, very fast SIMD libraries are coded in assembly. I think even 'liboil' has some parts coded in assembly
Such as C++, for instance?
Great! A confusing and overly-complicated programming language now made even MORE confusing and complicated!
G++ is a god awful compiler. I cant imagine G++0x to be any better.
GCC should learn from Intel here. ic is way way ahead of them.
> I have been involved in developing code for simulating cosmic-ray acceleration in expanding supernova remnants, this in Python.
Well, Python is a different game than Java or C#, which both have a much better JIT-compiler.
I mainly program in C++ (real-time data processing), but I feel hard-pressed to believe, that Java has to be severely slower than C++ in numeric computations. The Java implementations of FFT and LinPack suggest, that comparable performance should be possible. The SciMark 2.0 should also be more up to par, when you replace the synchronized Random in the benchmark with a Java implemented Mersenne Twister.
"Between strong and weak, between rich and poor [...], it is freedom which oppresses and the law which sets free"
Well, python+numpy in a single cpu environment can be very fast, depending on what you want to calculate. But you completely miss the point; for really computing intensive work you have to go parallel, and I have yet to see anything in Java that works efficiently in a parallel environment.
You've never spent hours on a single bug? And you only work on code you yourself have written? Wow, I wish I were you. Then all of the memory leaks, uninitialized values, pointer screwups, etc. that I have dealt with in the past will either never exist or be easily tracked down and fixed within minutes.
Most of the development is done by the devs on their local windows machines, ant compiles everything nicely on any platform into a jar or war or ear or just classes, then you just copy the binaries to a Unix machine and it works. (of-course if you start using platform specific stuff, then you will have to do more work, but actually it's very rare for business apps. to use platform specific stuff, especially if it's all about databases and networks.)
The memory is managed by the JVM, which of-course does not prevent memory leaking in itself, but at least buffer overruns will not allow injected code execution, at this point anyway.
The libraries are part into the JRE and you can rely on them for being present.
There are many people familiar with the language.
Note that I didn't write anything bad about C++, which I also use and often link to Java. Why can't it be more about positives than about negatives? C++ has a place in the world.
You can't handle the truth.
I also have an extensive experience with C++, and I tend to agree with a lot of the criticism that it gets.
But the problem is that no alternative exists for the type of problems where C++ is used extensively. I guess the most important area is games.
The world really NEEDS a language (the last low-level language) with the low-level performance of C++/C and with a full, modern library, and modern language features (threading, modern module system (not based on #includes and a crude preprocessor...), optional strong typing system a la Ada with optional runtime-checking etc etc etc.
Basically, a really nice, compiled, well-performing, modern low-level language could easily exist. But it doesn't. So we'll have to settle for C++ until someone makes something better.
GCC should learn from Intel here. ic is way way ahead of them.
I've always liked Intel's compiler but I wonder -- what does ic do that gnu doesn't? Yeah, I know that gnu's error messages make no sense but it does seem to be more standards correct and to generate working code.
This is my sig.
If not, it can't do this:
char * p, * q;
while (*p++ = *q++);
trouble is, once you get past 1 object you're into a nightmare world of nested 'using' statements that make 'if then elseif' look good.
....posting this while I wait for a whole lot of C++ code to compile.
From the new list of "features":
> nullptr: a name for the null pointer
#define nullptr NULL
There, that was hard.
(-1: Post disagrees with my already-settled worldview) is not a valid mod option.
Stuff I would like to see, all of which is really simple:
1. A "0" type. The typename is "0" and the only value is the constant "0". This would expose the C fact that "0" can be cast to more types than "1" or void* can. The following allows fast compile-time initialization without an if statement and without having to put these functions inline (or the typical kludge of allowing the object to be initialized with any integer, which is silly but I have seen it done):
class Foo {
A* p;
public:
Foo(0) { p = 0; }
Foo(A* pp) { p = do_expensive_stuff(pp); }
};
2. Partial classes. You can already put "class Foo;" in a header file. The following syntax would allow all the same things as that statement, plus allow the getX() and setX() methods to be efficiently run:
... // this ellipsis must be last
class Foo {
int x;
public:
int getX() const {return x;}
void setX(int v) {x = v;}
static Foo& makeone();
};
Implementation would do this to finish the Foo class:
... // ellipsis must be first
class Foo {
int more_stuff;
Foo() : x(0), more_stuff(1) {}
};
Foo& Foo::makeone() {return new Foo;}
Yes I know you can do something like this with a derived class but I think that is stupid to have to make two names for what is really one type of object.
3. Even without the ellipsis shown above, you can define private inline functions outside the class definition. This allows implementation details to be hidden from the header file. Again I know it can be done with a derived class but the need for an extra dummy classname is really annoying.
class Foo {
public:
int f();
int g();
};
The following would be in an implementation file. It would act exactly as though the method implementation_detail() was declared in the private part of Foo:
int Foo::implementation_detail(int) { return stuff_used_by_both_f_and_g();}
int Foo::f() { return implementation_detail(1); }
int Foo::g() { return implementation_detail(2)*5; }
> Well, python+numpy in a single cpu environment can be very fast, depending on what you want to calculate.
So can be MATLAB, as long as it matrix-multiplication, which is practically reduced to a single call to an external C++ library. Java, in contrast, has native implementations of numeric algorithms, which are on par with C(++) ones.
> But you completely miss the point; for really computing intensive work you have to go parallel,
I am well aware of that. I assume you've seen, that the Java version of FFT is, like the C version, running multi-threaded on a single computer. So, I guess you are talking about computer cluster.
In that case, I/O latency and bandwidth should be the limiting factor, which should be fairly language independent. Also, communication should be only a small part of the computation time, which makes the impact even smaller.
> and I have yet to see anything in Java that works efficiently in a parallel environment.
Not so long ago, people argued the same way in favour for Fortran over C++, but
as someone put it so eloquently: The absence of proof is not the proof of absence.
From what I gather from a quick search: The results of Java MPI bindings didn't look too favourable.
MPJava, however, suggests that comparable performance is possible (within 10% of the Fortran/MPI results in NAS PB Conjugate Gradient benchmark).
"Between strong and weak, between rich and poor [...], it is freedom which oppresses and the law which sets free"
The C syntax is horrendous, the conversion rules chaotic
Bjarne Stroustrup, creator of C++, is saying that C has a horrendous syntax and chaotic conversion rules...
Hahahahahahahahaha.
Most people who I run into who "hate" C++:
A. Don't really know much about it, especially modern C++.
B. Aren't really capable of using it. You have to be a better developer with C++. Any fool can write code in Java, but you actually have to know what you are doing in C++. Sadly, most developers really aren't any good and instead of admitting that to themselves, they say "C++ sucks".
"Java, along with C, seems to be one of the few languages that have absolutely no faculties for the RAII pattern."
Really?
What about:
COBOL
FORTRAN
VB
Prolog
Lisp
ML
In fact any non-OO languages , given that RAII is an OO concept.
MOD PARENT UP. Calling it a "Troll" is disgusting.
How much does it matter to you that Python is only bytecode compiled, allowing easy de-compilation?
It seems to me that the fundamental problem with C++ is that the development of the language that will happen in 2009 or 2010 should have happened 10 years ago. It amazes me that big corporations use C++, but aren't willing to support the language.
Why is it a good thing that it is more difficult to program in C++?
Isn't it a valid reason to "hate" C++ if you can do what you need in Java with less expertice and less effort?
He was my C++ professor just 3 years ago. Most horrendous class ever. He pretty much got up the first day and told us we were his guinea pigs for this new textbook he was writing. It wasn't complete, and I was a EE stuck in a CS class. Just the sight of his picture makes me shudder.
Java's Generics are more expressive; I hear C++0x will be more like them.
VB.Net does, actually. Anyway, I was referring to object-oriented languages, which I should have made clear. I included C on purpose, as various people out there will tell you how "easy" it is to write object-oriented C code, so I guess that was a bit of a dig at them.
You actually don't build a house out of 2x4s anymore. It's a lot more of 2x6s for exterior walls and 2x8-2x10+12s for beams and the like. 2x4's are merely for interior walls, at least according to most building codes.
Perhaps in your area. Around here (central USA), 2x4 outer wall construction remains quite common, with 2x6 outer wall construction typically used for "upscale" home construction.
- T
You obviously never wrote a single line of (C++) server code. When you have your code running in production, and it suddenly starts to leaks after two weeks of running, there's very little you can do except to hope that your logging is good enough to help you figure out the problem. Tools to assist with memory leaks? In my experience, vast number of such tools are unusable when you go to big league (when your code uses 1+ GB of memory) - when you run your program with such tools, it usually slows down so much that you don't have a chance to see actual leak (except if it's really trivial one)
digitalmars.com/d
I thought my reference to COBOL would be enough to imply that I meant in the corporation where I think most of us work.
Do you use COBOL at home? No, of course not. Some industries (insurance, finance) still do run that. C++ is gone from industry except for a few places, such as you mentioned. And companies these days don't want to spend endless time while you perfect your microscopic bit of code to do some tiny thing. Face it: developers are more productive in the newer languages: Java & C#. Those languages were invented precisely to overcome the obvious weaknesses of C++. If you are a C++ guru then you are a master of the Edsel. What I've noticed is the great number of Prima Donnas you meet in a C++ shop. Developers who have spent years perfecting some tiny app. Well, there is not time. These people cannot survive in any typical modern corporation where you get single digit days to get a large application or feature set done. If you're a dinosaur, you should just lie down and take your extinction with a smile.
Well, full disclosure: I'm not up on the latest band aids you guys are using to overcome the inherant weaknesses in C++. I agree that C++ is a fast, powerful language. I full-well know that both Java and C# are written in C++. The fastest language of all is Assembler. Having been exposed to a tiny bit of that, I know why it's so fast in execution: it's bare metal. I do not doubt the power of C++ in the hands of the specialist. My question pertains to its suitability for the wild corporate environment. I think C++ is like Assembler. Though its raw power is always available, the difficulty of executing code in Assembler and C++ should discourage it from being used as a standard. If you want to become the expert at Assembler or C++, be my guest. I just would NEVER recommend to any company I work for that we choose C++ for a project. I have seen quite a few projects that were rewritten from C++ to Java and we ended up after the refactoring with a better executing app. The old version was so brittle and ill understood that no one was ever willing to tinker with it. The old version was opaque because it was written in C++ and of course had no notes in the code. One guy wrote it and the manual was in his neocortex. You are free to label me a troll. Anyone who pushes you from your comfort zone would qualify, I suppose.
Next thing, someone will be pushing a new version of COBOL!
FYI, the "voting/comment period" for the next COBOL standard closed just over two months ago. I don't follow (or use) COBOL, so I have no idea when the new standard is scheduled to supplant the prior 2002 standard. And there's always COBOL.Net.
- T
Nothing more, nothing less. C++0x does not change that fact.
Having a memory model is a good thing though :)
As the document shows from page 3 to 7, C++ values efficiency a lot. If that's a requirement C++ is great. Criticism that C++ is not Python/Java totally missed the point!
http://www.research.att.com/~bs/abstraction-and-machine.pdf
For many, there isn't.
Java: operator overloading
No, never. Operator overloading is one of the worst features to be added to a typed language. I don't want to have to account for a billion different cases for the + operator because someone thinks a+b looks better than a.add(b) or that the shift operator should somehow be used for streams in addition to bits. Operators belong in the realm of reserved words that should never be redefined from their original purpose. If you are defining your own operation on your own types I expect an identifier with a well chosen name rather than yet another function tacked on to the meaning of '+' that is sorta like addition but not really.
In Lisp there is something functionally equivalent to RAII. It is a macro that opens the resource, lets you pass the code to process it and closes it. Very neat, and it does not need special language support.
Don't forget C#, but then it's basically an enhanced form of Java.
If you think "modern" languages are more expressive, then give "modern" C++ a try (insert comment about recent compilers here).
If I were going to ditch my preferred more expressive language, why wouldn't I just go to something like D?
Tweet, tweet.
Stick to your modern languages kidz, don't spoil the party B-)
Maybe you should hate C++. We really do not need that kind of expertiCe around :-)
I wouldn't want to work with whoever's servers you are maintaining. None of the C++ servers I've worked on have had the same issues.
What happens when you have to use 5 different objects with Dispose methods? Do you need 5 levels of indentation? I'm genuinely curious, because I've been spoiled by RAII (C++, PHP, Python), and I get frustrated in any language that doesn't have deterministic destruction by default.
The proper solution is to smack the idiot developers, not hamstring the intelligent ones.
GCC has done a pretty good job of keeping up with ICC on Intel... even though GCC supports a multitude of other platforms. Pretty much the only place where ICC is ahead of the game (based on aggressive in-house benchmarking) is interprocedural optimization and hardcore floating-point math. Everything else is a wash, and GCC is free software. The biggest hurdle with GCC is that it takes a fair amount of compiler flags in order to get reasonable output out of it - in comparison, ICC works well (for an Intel chipset) without any extra flags. On the other hand, ICC isn't going to do well for anyone on any other chipsets...
Um, I'm sorry, but... what the hell are you talking about? Restricting pointers?
Yes, restricting pointers.
You know how you tell that C++0x disappoints? It's that arrays are still not first class objects in the language. It's that you can't do cool stuff like attach extra junk to the prologue and epilogue of a function and then walk up the call graph and put things in there. I don't see any keywords for specifying the endianness of an integer - how useful would that be.. to be able to say "bigend int foo" or "littleend int foo". I'd like to be able to specify a structure or a class which could have a single value be composed of a few bits in utterly random places in it. In other words, you could say something like:
struct foo {
int a bits 1-2 this+1.2, bits 4-5 this+3.3
};
which you would read as int a bits 1-2 are at a byte and bit offset from the structure.
And, while we were at it, how about packed pointers. AMD64 has 64 bit pointers and we can easily stuff some extra crap at the high end of them if the compiler knew to strip it out before we dereferenced them. You could implement that as a mov and an and.
If you do want to "guard" your pointers, it would be interesting to perhaps tag different pointers as having different selectors for those hardware architectures that support it, like Intel. I mean, you could make programs a lot safer under Intel and AMD if you didn't use a flat memory model. Put all of input data onto their own segments and lock it down with the hardware mmu. If it blows up, or overruns, oh well. No need to check arrays in that case because the hardware will do it. And of course, having some explicit language support for memory mapping seems useful.
To me, a language like C or C++ is that you can evolve your own exact brick of memory and carve it up in some way... really, the idea of C is almost to be just to be a very fancy macro assembler and C++ was to throw a bit of object orientedness around it, if you want.
But, instead, we have iterators and containers and ever more powerful templates and, gross, garbage collection support... that's all nice and all, but, its all indicative of a movement towards this idea that C++ is -only- an OOP language and libraries are written on building OOP programs and not necessarily smaller systems ones. C was short and sweet and simple and fast and C++ was a couple of useful things on it at first but now its just getting out of hand with this C++0x.
The great irony, of course, is that C++ templates and, wow, look at generics in C++0x, are so incredibly powerful that, what we have is a extremely high level language that still doesn't do comma delimited output of numbers. It's schizophrenic, is what it is.
This is my sig.
Well, C# is halfway there with Dispose and "using" blocks - using them to perform some actions on exit from a block are fairly common. Though "finally" is really a better replacement for scoped guards that are specific to a single piece of code.
Came across this link at reddit just yesterday: http://importantshock.wordpress.com/2008/08/20/a-skeptics-look/
Ada + a modern library meets most of the requirements. To ease learning, an "ugly" version of Ada using C/C++/Java/C#-like syntax could easily be made.
with the recend performance improvements with Java and C#, their huge library base and open source projects (Java) it would be just plain stupid to use C++ for new projects unless one really neads full control over memory (kernels, embedded systems). otherwise, you will just spend much more time with C++ than with Java.
...header files. Having to manually synchronize header and implementation files each time the design changes is a major pain the butt. It takes away valuable time and greatly distracts from the mental process that is design of a program.
That is, until you try to combine it with other libraries, like Qt, for example. Boost has a namespace signals, Qt has a #define signals. Yes, you can solve the problem using the preprocessor, but boost was supposed to be 'plug-n-play'...
Smart pointers are difficult to manage in the context of complex object relationships. See my other post for more info.
The idea that destructors don't play well with GC is largely a myth. Non-trivial jobs should not be done in destructors. But even if they are done in destructors, they should be invoked using RAII style. The destructor is only a function, so it can be called normally just like any other C++ function.
As I explain in my other post, the problems of cyclic references introduced indirectly, the situation where you only have 'this' and you should use shared_ptrs, etc are great problems and you should not underestimate them.
1. Only makes you code faster by bloating your binary. Also is "interesting" to debug.
2. If you don't use exceptions as secondary flow control mechanism this isn't necessary. You made the problem and then manufactured a solution.
3. You later state that Java is "totally uninteresting" so, whatever.
I think there's a fundamental rift here. Some developers (me) are most productive with a language that is simple, easy to read, and has room for side-effects.
And you're saying leave that to the programmer??? That's the biggest maintenance nightmare I have EVER heard of.
I just don't think it should be left to the whims of some dude in the back room that would never document his intent and execution properly.
If you do go ahead and write it, ...
I can see you are very tempted with the idea of unlimited power but you struggle to keep your sanity (*my preciouss*)...
Yes, it IS a lot like putting all the eggs in one basket ... it requires WATCHING OVER THAT BASKET LIKE A HAWK! Hopefully, it should be easier then watching all over wide area of baskets (whole project). With it, you could actually *take away* freedom to do many stupid things from your underling code monkeys.
The dangerous "freedom" is just theoretical. Flexibility may mean more freedom, but also less freedom, of for that matter, same amount of it as it is presently. First of all, the language would have to carry "standard set of rules definition" with it, but including them in your project would be optional and RECOMMENDED. Rule sets would not be designed by any programmer (like probably someone you regret to know, or whose code you regret to had to read), but by an expert (e.g. a CS PhD) who is capable of properly detecting problems and devising solutions.
It is near equivalent situation to C/C++ system API being moved from language definition into accompanying standard library: you *could* write your own library replacement, or even not use any at all (in small embedded systems development), but hardly ever anyone does anything like that. However, should it become absolutely necessary, it could be done. Of course, anyone could write their own rule sets, if they dared, but it will be considered dangerous and not recommended, just like messing with standard library. Someone more foolish, toying with programming for fun, or knowing very well what they do, could also do some stunts without safety gear, hopefully in some very thoroughly isolated and well documented performance-critical part of code.
Imagine integrating language contemporary best practices and recommendations, your own organization coding standards, your project specific safety (or style) rules, thus (by means of having each coworker #include-ing header file with their definition in each source file) instantly enforcing them project-wide, all in modular and layered manner? Over time accumulated experience will be possible to transfer onto new projects. I think it could be great collaboration (hmm, an one-way collaboration) tool.
Admittedly, saying about a project that it was written in such a language would not mean any hint of measure of its quality any more. Instead, one would say that certain well known and respectable set of rules was applied to the project, and then we would know that it was enforced by compiler, not left to whim of developers to "respect" and prone to bugs wiggling through the loopholes of manual code inspections.
The proper solution is to smack the idiot developers, not hamstring the intelligent ones.
Intelligent developers can deal with not having operator overloading. Idiot developers can't deal with having it.
i'd hit it so hard, if you pulled me out you'd be the king of britain [bash.org]
No matter how smart you are, you can't make
more readable than
If this problem had a solution, the smartest people in the world would have long since used it to win everyone over to Lisp.
Well, one reason to find it funny is that function calls are expensive these days. Small operations encapsulated in libraries that are only available through linking can degrade performance, even if the implementation is superior. That's one reason to prefer inline assembly in C++. To top it off, introduce the specific implementations as template specializations, for example hand-unrolled loops for a few specific small sizes. That is simply not possible to do in C, or macro assembler, without introducing a maintenance mess.
I've always liked the Intel compilers... and I even once plinked down some bucks for the Intel compiler and vTune when I was writing commodity server back in the day... but the thing that keeps me away from Intel now is that I don't know how much I can trust that compiler to produce good code for AMD chips. Even though they have nearly the same instruction sets, they are very different internally and it follows that the timings and sequences of the instructions might well be different. I just don't know... and the other thing too is that I don't know how well deploying an Intel compiled solution would even fly on a Linux platform. Doing a source / make solution almost seems like it would be out of the question. Are these perceptions unfounded, or are they accurate. I defer to your experience and await your answer literally with baited breath.
This is my sig.
C++ is to C as Lung Cancer is to Cancer.
Seriously, the problem with C++ is its C heritage.
C is a language whose design was driven by having to fit the compiler into the 64kbyte instruction space of the PDP-11.