Slashdot Mirror
Stroustrup Says New C++ Standard Delayed Until 2010 Or Later
wandazulu writes "At the end of an article written by the creator of C++, where he talks about removing a feature from the new C++ standard, he drops a bombshell: The new C++ standard (typically referred to as C++0x) has been delayed until 2010 or later. What does this mean? No new C++ features like threads, proper enum classes, or hash tables. C++0x is dead, long live C++1x!"
C++0x
Yes, well, that just rolls off the tongue, doesn't it?
Maybe he can get one of those hieroglyphs like Prince.
Or C++0x0A no need to change the name.
"C++0x... Yes, well, that just rolls off the tongue, doesn't it?"
Well, it does if you just pronounce it "Cocks".
Because this is obviously the language's fault.
from 09 F9 11 02 9D 74 E3 5B D8 41 56 C5 63 56 88 C0
to 45 2F 6E 40 3C DF 10 71 4E 41 DF AA 25 7D 31 3F
It's not a bombshell by a long measure. Anyone who had been tracking C++0x standardization process (reading comp.std.c++, and WG papers) knows that the goal of getting the standard out by 2010 was fairly unrealistic, mostly because of concepts. The joke that "x" in C++0x is actually a hex digit and not decimal has been around for several years now.
The latest version of Cobol (eagerly expected by 6 people) will also be delayed till January 2011.
Or a crowbar for anybody who thinks languages make things automatically safe.
If you are a good programmer, you can do safe programs in C++ or any other language.
If you are a bad programmer, you can't do that in C++ or any other language.
This sig does not contain any SCO code.
The headline completely misses the central part of the article and focuses on a very minor point. Everyone has known for quite a while that C++0x would actually be C++1x. There's only a few months left in 2009, so there's absolutely no surprise there. The real meat of the article is that support for "concepts", a key (and arguably the most anticipated) part of C++0x, is being dropped. That's a major disappointment to many people, including Stroustrup.
There will be buffer overflow after C++0xFF
Are you saying that C++0x is unnecessary?
If so, then you haven't stumbled upon C++'s many problems. Like, lack of rvalue references. Or, lack of a proper lambda.
This sig does not contain any SCO code.
With that definition of good programmer, are there in fact any good programmers?
"Give me six lines of C++ code written by the most competent programmer, and I will find enough in there to hang him."
If you are a good programmer, you can do safe programs in C++ or any other language.
So it must just be that there are no good programmers. Because I haven't seen any safe web browsers, word processors, or PDF readers.
# (/.);;
- : float -> float -> float =
sure when those 'memory safe' languages produce efficient executables that do not require 400MB 'runtimes' to function. The net result from these sandbox environments is a bloated app that requires 5-10x more ram than is needed.
No new C++ features like threads, proper enum classes, or hash tables
Cause one thing C++ sure doesn't have is enough features, right?
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
"Can" does not imply "must".
This sig does not contain any SCO code.
Or better yet- take the crowbar and whack programmers who can't write in C++ until they leave the industry. If you can't understand memory allocation and pointers, you aren't competent to be in this profession.
I still have more fans than freaks. WTF is wrong with you people?
Someone give grandpa his oatmeal.
I haven't been following C++0x, but after reading the C++0x FAQ I am very pleased. It really fills a lot of the simple, practical holes in the language.
I think the success of C# is part of why these things are being considered. For example, C# recently added an advanced form of initializer lists - which is now in C++0x. Another example is the scoping of enums, which has long been a pain. Many coding standards require enums to be ALL_CAPS_WITH_UNDER_SCORES because they don't obey scoping rules: this is fixed. NULL is now replaced with nullptr, which is a minor improvement that looks much like how this was done in C++/CLI. (That's the bastardized C++ for .NET). Namespace cleanups, foreach, ... the list is huge, and it looks like C++ is "borrowing back" from Java and C#.
Competition is good.
I know that everything I just listed probably exists in many other languages, but C# and Java are very prominent in enterprise development, and are making huge gains. I will be very very glad to see a real ISO standard gaining ground again.
This. Can we add a special addendum specifying the use of chainsaw instead of a crowbar for fixed-size buffers without checking for overflow?
C++0x is a goofy name no wonder no one wants to work hard on it. How would you like that on your resume. C+=2 is much more consistent with the language and is much easier to read.
Forget about type safety... just give me the "auto" variable type. :P
Dear Lord: One of your creatures may be hurt tonight. Please let it be the other creature.
C++ has reached staggering complexity already; I don't think adding another 40 pages of complicated features is going to make the language any better.
someone stop feeding this kiddie count chocula and remind him that his precious sandboxed languages waste cpu cycles...lots of them, and that trend is increasing. The unchecked bloat that is being output by these latest college grads who know nothing but c#, vb, and java are serving no one's interest besides the hardware vendors.
I've been following C++0x for a long time now, and have been looking forward to it, but now I'm not so sure I'll ever use it. I was looking forward to Concepts more than anything and with that gone, it seems like a extremely minor upgrade. Also, even when the spec does come out, how many years before we can trust that most compilers can use it effectively... two, three? Then after we've been using it for a while, how long before books come out that tell us that we've been using it all wrong and we have to start over (ie: the Exceptional " " and Effective " " books from Sutter and Meyers)?
Okay, so I can use C++0x well in 10 years, okay I'll probably be so burned out by then I'll be a manager, or I will have convinced someone to let us use D for embedded work and something managed for everything else.
"We need a fourth law of Robotics: Stop Fingering My Wife"
Or better yet- take the crowbar and whack programmers who can't write in C++ until they leave the industry.
Because C++ is the pinnacle of programming knowledge? *giggle*
If you can't understand memory allocation and pointers, you aren't competent to be in this profession.
Just because one can understand memory allocations and pointers doesn't mean one wants to have to deal with them manually in all their programs. There is a reason why there are auto_ptrs in C++ and it's not because those people are "noobs", it's because people want to actually spend their time writing the program rather than having their time eaten up by writing tons of boilerplate memory management code.
If so, then you haven't stumbled upon C++'s many problems. Like, lack of rvalue references. Or, lack of a proper lambda.
I think \bigger problems are C++'s complexity, the presence of pointers, the use of include files, and the lack of garbage collection.
On the whole, I'd rather code in Ratfor.
"Do you really want to hold back all the other very important features like lambda, rvalue references, variadic templates, type deduction etc. just because of concepts?"
Unfortunately, without concepts, many of the templates that would make features like those REALLY powerful aren't implementable due to silly things like the compiler insisting upon being able to instantiate member functions that don't make sense for a class and won't be used, just because there isn't a means to tell the compiler "and if this member doesn't make sense, just don't instantiate it, and throw an error IF AND ONLY IF somebody tries to use it." (and yes, I know about SFINAE, but that gets REALLY UGLY to do).
I've been bit by this, where I ended up having to create two completely separate template classes, one for objects that don't have sub-members and one for objects that do, just because I couldn't tell the compiler "Look, if operator . doesn't exist for this method, then don't worry about it!"
That said: I will say, I felt that some of the implementation details of concepts felt "forced" to me, in the same way that the streams library feels "forced": they "hacked" (in the bad way) the library in using language semantics that weren't a good fit.
<sigh/> - I hope the extra time will allow them to put a bit more polish on how you actually express things, and make it feel less "forced"....
www.eFax.com are spammers
C++ can't be fixed by adding features.
C++ can only be fixed by removing features.
My minivan won't get me to Jamaica, so I need to add wings or pontoons? Or maybe I should buy an airline ticket instead?
Use the right tool for the job. Sticking another bag on the side of a language that's almost entirely bags isn't going to fix it. If you need a better language than C++, maybe you shouldn't be using C++.
They can't release a new standard until they figure out a way to keep the language from collapsing under its own weight, forming a black hole that would destroy the solar system.
That is all.
First: OO.o is Java.
Bzzzt wrong. Look at the code, it's 98% or so C++. The only parts that are Java are some database access layers and some stuff for multimedia. Way to show yourself as being an idiot for repeating this oft-repeated and incorrect meme.
Second: The language has little to no bearing on the amount of RAM being used. The amount of data being stored (and how it's stored), however, does. Firefox stores a lot of images and such, which, surprise surprise, eat up RAM.
So then you've just effectively nullified your own point since you were blaming the languages on the bloat instead of the crappy programmers.
There are two basic problems with your code. First, there are unbalanced parenthesis. Second, this is a thread about C++. Not Perl. Next time, be more careful. Thanks.
Some years ago, the C++ committee went off into template la-la land. Most of the work there focuses on template features that will be used by few, and used correctly by fewer.
Templates are useful, but "generic programming", doing arbitrary computation at compile time with templates, was a terrible idea. Templates can be abused as a recursive term-rewriting system, and through some clever and obscure tricks, recursive computations can be run at compile time. As a programming language, this trick is awful; awful from a syntax point of view, awful from an understandability point of view, and awful from a debugging point of view. If you need to do work at compile time, there have been much better approaches. LISP "macros" were standard LISP, not a second language. And even they created such a mess that Scheme had to be invented to clean out the language.
Orignally, templates were conceived as a saner way to do what C programmers did with macros, providing a way to have some type independence at compile time. But the template crowd got out of control.
The obsession with templates has led to a neglect of things C++ really needed, like better memory safety (C++ still has buffer overflows, and most of the security holes today stem from this), and better approaches to concurrency (the compiler has no idea what locks what, and it needs to know). Anything that wasn't template-related tended to be ignored by the committee.
The result of this failure has been C++ spinoffs - Java, C#, etc. Even Objective C has made a comeback in the Apple world. C++ has never even been able to displace C, twenty years on.
I've written a lot of C++, and I'm disgusted with this mess.
There is nothing they can add to any language that cannot be done effectively with C and C++ with a good support library like BOOST and STL.
The whole point of concepts was to make C++ libraries that heavily rely on templates, such as STL and Boost, easier to use. As it is, C++ templates are effectively compile-time duck typing, which means that error is reported not at point of call, but where it actually leads to non-compilable code produced during template instantiation (which is usually inside the library you're calling). Ever made a mistake while calling boost::bind (or, Heaven forbid, while using Boost lambdas)? Do you remember what the error message looks like when it happens?
And there are times when you want the memory management code for performance, and you can't get to it. I've seen such horrible Java programs from new programmers because they are never taught ANYTHING about memory management. You can't forget about memory in ANY language that you use. I highly value C/C++ as an initial learning language because it forces you to recognize that resources need to be allocated in order to use them. Java and other languages make implicit allocation easy, but it hides that from the programmer, which allows people to shit all over memory because they don't have a clue about removing objects when done, or even just removing all references to them. They just don't know.
My blog. Good stuff (when I remember to update it). Read it.
C++0x is just an evolution of C++. It does not add anything that is not already possible, but it does attempt to improve certain usecases. Adding threading support to the language core allows the standard library to be used with threading, and makes it easier to write thread-safe code. (As it is, you need to look up for each and every compiler/standard library pair you use which if any standard library functions are threadsafe.)
The hash-based containers have been fairly standard since the beginning, although there were slight incompatible differences between the implementations, which meant that portibility suffered if you used them. Now adopted by the Standard Library, you can use them in any C++ implementation that support C++0x (Which will be most of them. Even Microsoft plans to strive for a fully complaint implementation, minus a small number of legacy deviations (although they will always remain fairly far from perfect compliance)).
Much of the standardization effort is in bringing chunks of BOOST into the standard library, such that you can just use them without installing all of BOOST (which is pretty extensive). They are adding a few nice convenience features, such as lambdas (really useful with STL algorithms), and a few other features.
Just like any decent C compiler supports C99, all good C++ compilers will support C++0x. It is highly backwards compatible, although a few minor breakages will be present, especially if you use one of the few new keywords as an identifier.
Stylish sheet to fix many problems in Slashdot's D3: https://gist.github.com/801524
I've been following C++0x for a long time now, and have been looking forward to it, but now I'm not so sure I'll ever use it. I was looking forward to Concepts more than anything and with that gone, it seems like a extremely minor upgrade.
I would disagree on this part. I'm already using some C++0x features actively in production code, and I can say that they are well worth it. Lambdas are extremely handy as they finally let you use STL (and Boost) algorithms properly without lots of unneeded hand-waving. This may sound a minor thing, but remember how things have changed in C# world when anonymous delegates were introduced in C# 2.0, and their syntax simplified in 3.0? All of a sudden, everyone shifted to functional ("LINQ") techniques of writing code, abandoning hand-coded loops. The same thing happens here.
The second big part is rvalue references. They really do give major performance benefits for STL containers, especially of user-defined types (as smart implementations of C++03 already optimize their containers for standard types to avoid copy by using swap instead - but they can only legally do it for types they control...).
One other thing. C++0x may take a while to be released, but you'll see quite a few of its features in production-quality compilers before the spec is finalized. I've already pointed out that some are in VC++2010. There's even more in newer g++ versions (IIRC, they implement all that stuff, and also variadic templates). I've also seen mention of rvalue references and lambdas in the feature list of the most recent C++Builder release. All in all, this means that you'll have them at your disposal within a year or so one way or another.
Lynx vulnerability
# (/.);;
- : float -> float -> float =
Azureus isn't a browser though. It downloads torrents. They do completely different things. A browser actually has to render images, animations, and even videos. It has to parse large amounts of HTML, CSS, Javascript, and make sense of all that so that it can display it on the screen. Torrent applications are basically glorified FTP clients. They don't have to display anything on the screen at all. They just have to manage a bunch of internet connections and save some data to the disk. It's like me saying that Notepad uses less memory than Azureus, therefore C++ is better. Show me a browser with a similar feature set to Firefox written in Java, and then we can talk.
Anthropic principle: We see the universe the way it is because if it were different we would not be here to see it.
The problem is the amount of C programmers/thinkers who think they're writing C++ just because they type "class". It doesn't work that way, C++ is a totally different language.
eg. If you're Doing It Right then it's impossible to get a "buffer overflow" in C++. Most of the exploits you see are down to buffer overflows so I leave you to draw your own conclusions about the programmers.
Problems with C++ that will catch C programmers:
No sig today...
So, if I'm understanding your argument, there are good programmers, but none of them are actually trying to program securely.
They could stop writing vulnerabilities if they wanted to...
# (/.);;
- : float -> float -> float =
Gotta have the "auto" variable because expecting all programmers to know how to type efficiently or to understand what data types are being used isn't fair to those that haven't gained those skills yet.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
C++:
You can program it like assembly.
You can program it like FP.
They should bring Larry Wall into the committee and things will really get cooking. Imagine the awesome possibilities.
Fuck systemd. Fuck Redhat. Fuck Soylent, too. Wait, scratch the last one.
That's funny cause I've never seen a single C# or Java app.
Where are they? If C# and Java are so great, where are the apps? It's been, what, twelve years since it was announced that they'd take over the world and make C and C++ obsolete but I've yet to see a C# or Java program that wasn't some simple sort of utility or the GUI layer over a C++ app (eg Norton products).
What I have noticed is that all those "GUI layer over a C++ app" programs are enormous. 200Mb for a disk backup program (both Norton Ghost and Acronis TrueImage went from 20Mb to 300Mb during their transition-from-C phase and neither of them seems any better off for it.
Firefox memory usage is a mystery to me. I can't conceive of how it uses so much memory just to show a few pages of text with embedded images. The other browsers aren't really far behind though so maybe I'm missing something.
No sig today...
Care to hazard a guess as to how complex those 5 .NET and Java applications are compared to a web-browser or Office Suite?
.NET or Java, running the same websites. Likewise for comparing against OpenOffice. I don't think either item exists yet.
.NET web browsers and office suites to compete with them is that they flat out can't do it.
To make the comparison fair, you should be measuring Firefox against a more or less even-featured competing web browser written entirely in
I'm not saying Firefox and OpenOffice are especially lean applications. They definitely do seem like resource hogs. But the most logical explanation for the lack of proprietary or open source Java and
Funnily enough, all the features you mention are ones which CAN be fixed with "a good support library".
(Apart from the include files...)
No sig today...
Just because one can understand memory allocations and pointers doesn't mean one wants to have to deal with them manually in all their programs.
I fully agree with this. I've learned all about the use and necessity of pointers and allocation, and I've done my time with the debugging and memory leaks because I didn't do it right. Lots of great lessons from that. And I can really appreciate languages that handle that for me so I don't have to fuck with it. It saves me so much time and frustration.
Although it irks me that colleges start people off with these languages now. Most students I teach were brought up on a strict diet of Java and so to them, variable declaration is just a formality and pointers (or references, as the Java people insist) are just part of the magic that happens behind that friendly, colorful compiler.
These are the types I fear for in the industry.
/* No Comment */
I would describe concepts as increasing the usability of templates because you start to get readable error messages, but I don't see anything that can be done with concepts that can't be done without.
Concepts let you "overload" templates depending on whether a template parameter conforms to some concept or not. You can do some of that right now with SFINAE, but it's a hack of epic proportions, and it doesn't cover all use cases (e.g. it doesn't let you test for members).
I think bigger problems are C++'s complexity, the presence of pointers, the use of include files, and the lack of garbage collection.
Funny - I see all of those things as advantages.
If C++ wasn't based on C, it might have been a decent language...
OOP, metaprogramming, RAII, exceptions are all decent concepts. Too bad it also inherited C's "arrays are just pointers" idiom, and extended C's already stupid grammar to the point of grotesqueness. And it's not going in the right direction nowadays either. The syntax they chose for lambdas in C++0x is awful.
Any topic that involves geeks and C++ is just asking for flame wars, I'll submit my name to the mix.
Although I've been coding in c++ for more years than half of you have been alive, and am rather biased, I feel good programmers write good code independent of the language they use.
Hi, I Boris. Hear fix bear, yes?
Any garbage collected language requires more memory to operate than the program actually needs.. Otherwise you'd be garbage collecting 24/7. So yes, if you want to minimize GC cycles/pauses, your memory usage can be vastly higher than what the program would actually require in a traditional language. That's probably the big reason, for example, that the iPhone doesn't support GC in its Objective-C implementation.
Um, yes. And they do.
Take a look at something like Acronis TrueImage (or any Norton program) before/after their transition from C++ to C++-with-C#-user-interface.
Installer before: 29Mb
Installer after: 290Mb
Memory usage: Completely unusable on a 512Mb machine
nb. I use these as an example because they're the only commercial apps I can think of that use .Net.
No sig today...
Back in the day they used to have little children crawling around under cotton stipping machines. The children were needed to pick up fluff and other debris that would cause the machine to break the thread it was working on. Some children would get crushed in the machine because they weren't fast enough to get out of the way etc.
C++ is a bit like that machine. It works fine if you have the luxury of being able to pick only the fastest most able children but there comes a time when you need to grow your business beyond the limits of what the best can achieve. At that point you need to either accept that some of the less able children will get crushed (bugs in the code) or you need to make the machine safer. It's often cheaper and simpler to make the machine safer and hopefully those most able children will then be able to perform more complex and hopefully profitable work.
To paraphrase... everytime you argue for a language without safety features god kills a child.
I used to have a better sig but it broke.
How many Java browsers are out there? None? Case in point.
Or, lack of a proper lambda.
I think \bigger problems
Is that backslash some kind of Haskell joke?
No, he was saying that if you weren't a C++ programmer that you should leave the industry as if being able to program C++ and knowing pointers and memory management was some sort of godlike skill. The people who bluster on about how they know about memory management and pointers are usually the ones who write some of the leakiest code around.
It's not necessary to check a return value if you don't care if the action succeeded or failed. One could reasonably argue that (at least in GUI application) printf qualifies as just such a throwaway statement.
As for returning an exit status, AFAIK, both C99 and C++ codify that a main() function should implicitly return zero if the end of the function is reached. Thus, that's also correct, although one could argue that the behavior was OS-dependent back when that code was originally written, and thus it has only become correct in the past decade or so. :-)
Check out my sci-fi/humor trilogy at PatriotsBooks.
Where are they? If C# and Java are so great, where are the apps?
gmail, amazon, your online banking, etc.
Firefox memory usage is a mystery to me. I can't conceive of how it uses so much memory just to show a few pages of text with embedded images.
Modern web standards are extraordinarily complicated. The current html spec is 756.93 KB alone. Add to that css, js, xml, http, etc. Add to that compatibility with the millions of existing web pages, and all of a sudden you have a ton of complicated code in order to display "a few pages of text".
There aint no pancake so thin it doesn't have two sides.
And btw before someone mentions something like Azureus as a counterexample, I've seen Firefox still eat up more RAM than that program if they are running for the same period of time and that's with about 10 or so torrents running in it.
And just as pointlessly, I've seen Photoshop eat up far more memory than my Java "Hello World" program. Seriously, pitting a modern web browser to a BitTorrent client to compare the languages used to code them is beyond absurd.
As someone else noted below, compare Azureus's memory footprint (as well as speed and responsiveness) to uTorrent, which has virtually identical functionality to Azureus but is written in C++.
Momentarily, the need for the construction of new light will no longer exist.
Like the guy who wrote Hello, World. Completely safe.
It is because of both it's triviality and the fact it doesn't deal with untrusted data (or any data).
Real systems are a lot more complex and they often have to deal untrusted data. Noone is perfect and it is almost a certainty that a coder will overlook something or make an incorrect assumption sooner or later. Of course some coders will do it more often than others. If they are lucky they spot it during testing and/or it is not exploitable. If they are unluky they have just introduced a security hole.
You can reduce the bug rate in code by hiring better programmers or by doing a lot more testing and inspection of code, but you quickly get into very high costs and diminishing returns and some bugs still slip through (see: NASA).
C (and some C++ subsets*) has very little checking built into the language. As a result of this it is easy to end up with bugs that allow overwriting memory the code was never meant to even touch and thus allowing injection of code.
*C++ is a huge language (it's not quite a strict superset of C but it's pretty close) with an even bigger standard library. Some constructs in it are much safer than others and so it's vulnerability depends on what subset you work with.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
"Could that be because Bjarne first named it "C with classes"?"
It's because writing good C++ requires a lot of patience and self-discipline, something that most "programmers" simply don't have (or they're always up against a deadline or some other excuse for "just get it working, we can tidy it up later",- which never happens and you go into a downward spiral).
No sig today...
C++0x adds syntactic sugar, no more.
I'm actually relieved to see concepts dropped, that was probably the biggest useless sugar ever (axioms were not just sugar, but they were the part less ready for inclusion anyway). Everything concepts can do can already be done in C++03 with SFINAE with expressions (which, thankfully, was required explicitly in C++0x unlike C++03 which is quite vague on that topic).
Lambdas are monomorphic, thus useless. Even a DSEL can do better. Worse, even MACROS can do better (since there is no stupid limit on templates being declared at file scope anymore).
Rvalue references is just broken magic; relying on NRVO works just fine to implement move semantics and is not as senseless.
The only real update that comes with C++0x is fixing the standard library so that it doesn't require stuff it doesn't need. Nothing developers haven't already solved by implementing their alternative to the standard library.
Yet, C++ remains the most awesome language ever.
Too bad the committee isn't working on actually useful additions, such as virtual templates, which would allow it to compete with dynamic typed languages such as Python.
eg. If you're Doing It Right then it's impossible to get a "buffer overflow" in C++.
Is it? STL iterators (and therefore containers) do not guarantee (and usually don't provide) any bound checking, so they aren't really any safer than good old memcpy in that respect.
The use case for auto is stuff like this:
There's absolutely no good reason why I have to spell out the map type in full twice on two adjacent lines of code. Yes, one can use typedef, but it actually makes code harder to read (I'd rather see std::map<...>, and immediately know what is meant, than see MapOfFooBar, and try to guess if it's std::map, or std::multimap, or maybe one of the fancy Boost containers, or a custom class). With auto, this becomes:
The big problems with GC are:
a) Resources are more than just RAM. All files, network connections, etc., have to be manually closed in Java. There's no way to automate this (no equivalent to C++ stack unwinding) and it ends up being more work than managing RAM in C++ (where the compiler does 99.99% of the work for you).
b) Even if you're only managing RAM, a garbage collector will totally destroy your performance if you run out of it and start paging to disk. To me, anything which continually scans the entire heap when you're out of RAM is a showstopping problem and makes GC useless for real applications.
No sig today...
Take a look at something like Acronis TrueImage (or any Norton program) before/after their transition from C++ to C++-with-C#-user-interface.
As someone who worked in Acronis, and wrote a bunch of code for True Image, I feel obliged to tell you that there's no C# code in it at all - it's all pure C++. Acronis SDK (which is a separate thing, and IIRC comes only with True Image Enterprise) has component that exposes .NET API, and that's written in C#, but it's separate from True Image proper, and those C# APIs are just sanitized wrappers on top of the original COM API (which is implemented in C++), and, in fact, most of C# code there is automatically generated from COM interfaces (I know that because I'm the guy who originally designed that part of it).
As for GUI in True Image (and pretty much all other Acronis products) - it's FOX Toolkit, or rather, forked and heavily-customized version of it (since it's LGPL'd, you can request the source code with customizations here).
And there are times when you want the memory management code for performance, and you can't get to it.
That's actually one thing I appreciate about C# over Java - it defaults to GC and memory safety, but it also has raw pointers with arithmetic, stack allocation, unions, and unchecked fixed-size buffers for when you need them.
Code is complex, sure, but where does the RAM usage come from? At the end of the day the data being processed is a few kb of text and some bitmaps.
No sig today...
Yeah, the C with classes is a nice language. The C++ with std:: stuff can be a bit of a mess. The reason for arrays is that they're still much faster than vectors because compilers haven't figured out how to optimize a complex templates very well. If C++ wasn't used in an area where speed matters, then maybe you could get away with replacing fundamental types with compile time add-ons.
Every time I try to start using some other language, it fails. Mostly because other languages do not provide necessary tools to build correct programs.
1) java failed to support variables in stack, and the whole VM/GC thing is horrible.
2) haskell failed in supporting for-loops (MapM_ is not exactly the same thing)
3) erlang failed when it made it too difficult to use existing libraries made with some other language
4) python failed when it's performance is not very good
5) C# failed because it's from microsoft
6) C failed because of it's lack of support for abstractions
So I keep coming back to c++ every time. It provides combination of performance, low level programming, high level programming, good abstractions, rich tools to build your programs, proper tools for debugging your programs, plenty of libraries available, caveats are well known and workarounds exists, and it keeps working year after year without any compability problems in all supported environments.
C++0x dropping concepts is a big news. This is because c++ is important. It also means that the concepts proposal was not good enough. Only the best proposals will survive. If concepts needs to go, then they go. C++ is too important to get ruin by proposals that do not work or leads programmers to deadends. Concepts looked like a fine proposal at first, but seems it was still not good enough.
This might make other languages think they're progressing faster and providing new features faster. The other languages are still struggling to provide even basic support for things that programmers need. It's not the new features that the languages provide that determines if the language is useful. It's what the language fails to provide that counts. If there are big gaps in it's support, the tool is just unusable for use.
Complete rubbish. Compiler writers aren't stupid, they know how to optimize std::vector. Go and disassemble some std::vector code before posting stuff like this.
No sig today...
Yes, if you need to grow your business and all you can hire are dumb@$$3$ then yes, stick with Java (or C#).
Wow, so all the programmers you hire are perfect little automata that never make mistakes? Impressive! Where did you find such miracles of science?
And how much of a hit in performance are you taking when garbage collector turns on? How many times a minute does it fire and what happens to all those threads that are blocking?
Depends on the GC. There's a reason Sun provides a bunch of alternative implementations which have various performance characteristics that are better for different workloads.
On the flipside, how often do you see a crash because of a bad pointer reference, or worse, a security hole available to the world because of a buffer overflow in the code your perfectly little automata hacked up?
There was a time when people expected computers to be fast.
They also expect them to be stable and secure. Hint: speed isn't the sole requirement for most applications, and in fact isn't even the top one most of the time.
The advantages of C and C++ have always been the speed of execution, and it's ability to get really close to the hardware. The problem now is that the speed of execution advantage is fading. Interpreted byte code languages like Java and C# are getting faster and faster, and they byte code has always made them more portable. Add to that that the extra complexity of C++ is often unnecessary, and you start reaching a point where more and more applications which would once have been written in C++ are now being written in C# or Java, this trend is only likely to continue with more and more applications moving onto the web, and continued improvements in the byte code languages themselves.
There is certainly still a need for C and C++, they are really the only viable languages for writing device drivers and certain core OS components, not to mention all the interpreters necessary for running all these byte code languages. The problem, as I see it, and I'm by no means an expert, is that C++ is continually trying to compete with languages like Java, which it will never be able to functionally do without giving up all of the things which make it powerful and which java can't do. Java is powerful because you don't have to worry about all the things you don't really care about, and C++ is powerful because when you do need to care about them you have the level of control you need(C# tried to allow both, but it doesn't really work that way). The more libraries and features you add to C++ to make it like java, the more complex and bloated you make it, and you're still chasing an unachievable goal because you can't make C++ into Java and you wouldn't really want to.
I'm not sure why the language is going in this direction, but it seems to me better to use C and C++ where they're appropriate and use Java/C# where they're appropriate and to stop trying to create some jack of all trades language which can't exist.
Most of C++'s superior performance comes back once you start using metaprogramming. Note, modern C++ does not outperform Java because of low-level bit fiddling, it outperforms Java because of its ability to do work at compile-time. Once one starts to do this, it becomes apparent just how many class hierarchies actually never require run-time polymorphism (and only polymorphism at compile-time). As a result, the actual class hierarchies are dramatically reduced, because most classes in Java are just poor man's concepts (as in C++ concepts) or poor man's Haskell typeclasses.
Also, C++ is multi-paradigmatic, and does not try to shoehorn everything into the OOP paradigm, which means the code can fit the problem better. For instance, I lost count of how often I use boost.lambda, or boost.phoenix, or bind, which all are sort of implementations of lambda.
Then there are expression templates, which allows you to do things like matrix multiplications which even outperform Fortran.
This sig does not contain any SCO code.
Include files are used as some sort of interface 99% of the time. Count the amount of include files without include guards. This means that include files are used in one limited way almost always. If headers are used like module interfaces, then it would be better to support modules in the first place.
Plus, you have to manually take care that stuff isn't defined multiple times (which can happen even with include guards), templates have to be re-evaluated all the time, headers included in include files propagate and can affect compile time as well....
As for why they are still around: backwards compatibility...
This sig does not contain any SCO code.
No, because there is nothing that can replace it. Look at the range it covers. Give me a language that can replace this, and I'm truly happy, because C++ is not a shining beacon of light, C++ is a necessary evil until something can truly replace it.
Oh, and mind the amount of C++ code out there I'd need to interface with. D is the closest thing out there, but it still falls short (well, perhaps until D 2.0 comes out).
This sig does not contain any SCO code.
Gotta have functions because expecting all programmers to know how to copy and paste large chunks of code when they use them isn't unfair to those who haven't gained those skills yet.
When I'm programming, certain things set off red flags. If I see myself doing something similar many times, I extract that stuff into a function if "the thing" is parameterised by values. If it's parameterised in terms of types, I use a template, if there's obvious structure, I use a class. If it's small and gets done a lot, I use a loop. These structures are things that are not technically necessary for programming, but each mechanism cuts down on redundancy and reduces the chance of errors by having to remember where all the changes are. In addition, reducing the boilerplate makes it easier to see the structure in the program.
The auto variable is an example of type inference, and the fact that C/C++ doesn't have it is really a nuisance once one has gotten used to languages with more powerful type systems like Haskell.
Languages aren't inherently fast -- implementations are efficient
He's only putting auto_ptr pointers on the stack, not whole objects. That is what he meant by "automatic".
But also don't discount putting things on the stack. It's not a good idea if your functions are recursive, but for leaf functions it is. I just did some tests today, replacing a stl stringstream with a 256 byte stack buffer and using snprintf and it literally was 4 times faster. I wasted some time trying to improve the stringstream, by putting it outside the loop and clearing it instead of recreating it each time, and performance got worse (I think because the only way to clear it is to do s.str("") which created a temporary std::string and the compiler was too stupid to remove it). Changing the called code to take a const char* instead of a const std::string& did improve it about 1.5 times, but that was just doing a portion of the conversion to old fashined C code, and was still worse than the one that kept the std::string and used the buffer.
Anybody who claims C++ stl stuff is just as fast is lying. They are safer (for instance nothing stopped me from sending the wrong number to snprintf, and my code did truncate if the answer was too big for the buffer, though I knew that the input (identifiers) would never be that long). But they are never faster, even compared to rather stupid code. I'm sure if I went and replaced snprintf with various strlcat calls it would be even better.
Yes, but you will dump core with a bad_index or an assertion if you write outside iterator bounds instead of overwriting arbitrary memory, opening up opportunities for exploits.
Except that you won't. Alright, checked iterators are an option, which is normally disabled by default in release builds in all implementations that I know of. So normally your std::vector iterators are just thin wrappers over pointers with no checking. And, of course, an implementation that checks iterators can check pointers just as well.
In Java, C# or about any other language I've ever programmed indexing outside the bounds arrays or other containers will b0rk your program, it's all about _how_ it borks, and in that regard C++ code that only uses STL (properly) is pretty safe against buffer under/overflow exploits.
To reiterate: there's absolutely no guarantee of that. Dereferencing an invalid iterator is U.B.; moving iterator before first element, or more than one past the last element in container, is U.B.; std::vector::operator[] with out-of-bounds index is U.B. The only thing that Standard guarantees is that std::vector::at() will throw if index is out of bounds, and almost no-one uses that (I've yet to see it in production code). It is absolutely not like Java or C#, where you're guaranteed that any out of bounds index, or any invalid iterator/enumerator, will throw upon use and not corrupt anything.
anything which continually scans the entire heap when you're out of RAM is a showstopping problem and makes GC useless for real applications.
Luckily, GC has advanced since the 1960s.
I know that. But C++ forces you to think about those issues, whereas Java/C# don't. That's why I recommend everyone at least learning a bit of C/C++, so they know where things come from. Do the development in Java, C#, Haskell, whatever. Have a ball. But realize that even if the language hides it from you, your structures and program still use resources. THAT is the problem I see coming from newer programmers.
My blog. Good stuff (when I remember to update it). Read it.
Actually, this is part of a bigger shift in the C++ development community. From now on, a new C++ core edition will be released each year, with names in the format "C++ ". C++ 2010 (or C10 for short) will also contain a major overhaul of the C++ rules, intended to make it so that user's guesses about how the language works will most likely be correct. Here are some of them:
- The long and short keywords are now #defined as static. This fixes issues with respect to variables using these keywords going out of scope before all functions using them have resolved. It also keeps them from being used more than once for the same variable.
- Some of the terminology is changed. "to declare" is replaced with "to put on the battlefield"; "to free" is replaced with "to send to the exile" (or "to exile" for short). This is to make the language less confusing for new users. Also, functions are no longer "called" but "evoked", bringing back some terminology from the early days of the franchise.
- Local variables will no longer be exiled when a block ends. This mechanic has frustrated many new users (as almost nobody can tell without looking it up where a block begins or ends) and thus the developers have removed it. They are aware that this breaks some peoples' coding styles but really think it improves the language.
- Local variables no longer use the stack. The developers felt that putting local variables on the stack could create unintuitive situations and thus moved them to the heap.
All in all C10 will be the best version of C++ ever. Prerelease events will be held shortly.
USE HOT GRITS WITH STATUE OF NATALIE PORTMAN (NAKED AND PETRIFIED)