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.
But I can assure you it's better than Cloud Computing with JavaScript :)
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.
"No new C++ features like threads, proper enum classes, or hash tables"
"Concepts" is the only thing being removed from the new standard due to time constraints (which is a shame since they seemed like a great new feature).
I think you meant to say 'No new C++ features .... _until next year at the earliest_'
Of course if you want to try some of the new features in the meantime feel free to checkout the expiremental branch of gcc geared towards implementing C++0x.
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.
Why the #$%! do computer scientists believe that languages are like movies and you need to release a sequel? 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. Language-specidic Threads? Enum classes? Hash tables? All of those are ALREADY possible without another language being introduced.
The purpose of new languages? To sell books. To sell compilers. To keep academics publishing about their new inventions. But lets face it, we have enough languages now. If you can't accomplish what you want to do in a relatively short time with the options that are now available, the problem isn't the language.
There will be buffer overflow after C++0xFF
the standards body has very specific steps that it needs to go through for approval of the standard, with defined notification, voting, etc time windows. mid 2008 it was already clear that it was impossible to follow these rules and get final approval by the end of 2009, even if you assume that nobody has _any_ changes or corrections to anything
David Lang
C++ concepts were effectively the same as Haskell typeclasses - an extremely powerful feature that allows for fully and properly typechecked (unlike present-day C++ templates, which are "typechecked" in essentially the same way macros are) abstraction and code reuse in a statically typed language. Removing them significantly reduces the power of the language, and effectively makes C++ a minor evolution of the language (most notable new features are now probably rvalue references and lambdas), and leaves templates as broken as they are today. It's too bad. I'd rather see the standard delayed even more, but done properly.
Even if they were not preemptive on the MAC in 1996, it would still work if you cared to call Thread.yield() once in a while.
Hashtable and Enumeration were there in 1996 as well. All newer versions of Java provide backward compatibility for the 1996 version of these classes. Code written in 1996 still runs fine.
Don't get me wrong, I like assembly, C and bash, I am just stating a fact.
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?
Also some of the features they've been aiming for are pretty complex and don't have a proper implementation yet (like Concepts - good an idea as it is) - hence they're trying to standardize from thin air.
Let me guess, you need an electron microscope and optical tweezers to masturbate, right?
So everybody has programmed a web browser, word processor or PDF reader?
Can you hack a barebones lynx?
Self proclaimed typo king, and inventor of the bear destroying coffee table (patent not pending).
God, that's terrible.
You should be using
for (auto i=...)
or for_each(...) and the new [] lambda.. nevermind the really terrible stuff in there, lordy, you dont need * and ->, use * and . or just -> its almost like you're ignorant or out of date or something.
Goes to show how brilliant C++ is, in a normal language psychotic fuckers can do all sorts of damage, in C++ they can't even compile...
http://rareformnewmedia.com/
Someone give grandpa his oatmeal.
I did not RTFA but is there anything new in here? I learned that C++0x was being renamed to C++1x and would not be out untill 2010 a while ago. I think over half a year ago when I was visiting the IRC channels.
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.
sure when those 'memory safe' languages produce efficient executables that do not require 400MB 'runtimes' to function.
So that means Java and .NET are good to go as neither one of them have 400MB runtimes.
The net result from these sandbox environments is a bloated app that requires 5-10x more ram than is needed.
Only if you can't code worth shit.
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.
What does this mean? No new C++ features like threads, proper enum classes, or hash tables.
As far as I understand, concepts have been "decoupled" from this standard, but not threads, proper enum classes, or hash tables.
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.
Anger problem
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"
Lynx and notepad?
Your ad here. Ask me how!
Sorry, I meant to say that without a final C++ standard, we wouldn't have these features in a standard commercial compiler; I didn't mean to imply that they had been removed from the standard itself.
typesafe and memory safe languages are written in c++ you insensitive cod!
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.
I love trolls :)
typesafe ? Is not C++ type safe ? Where did you read about C++, while listening to some podcast ? Get real man. Read the specs, use it.
Memory safe ? What is exactly this concept of "memory safe" ? Having a GC that does not have a clue of what the programmer wants to do ? To have a such dumb programmer that expects that memory allocations can be entirely managed by other layers ?
Get real. You ain't getting anything better than C++ for the time being.
Oh, sorry. I guess I can run VBscript and Java on this 16kb ROM/2kb RAM controller I have here... or then not.
On the whole, I'd rather code in Ratfor.
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.
That's funny cause I've never seen a single C# or Java apps that uses as much memory as C++ programs like Firefox (currently using 350 megs of RAM) or OpenOffice.org (current using 250 megs of RAM). On the other hand I have 5 different .NET apps and a Java app running and their combined RAM usage isn't even 200 megs.
Memory safe ? What is exactly this concept of "memory safe" ? Having a GC that does not have a clue of what the programmer wants to do ? To have a such dumb programmer that expects that memory allocations can be entirely managed by other layers ?
That's funny because any good C++ programmer will take advantage of auto_ptrs which effectively do manage memory for you automatically. Or is Bjarne Stroustop only a "dumb programmer" since he advocates their usage?
"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++.
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.
That's funny cause I've never seen a single C# or Java apps that uses as much memory as C++ programs like Firefox (currently using 350 megs of RAM) or OpenOffice.org (current using 250 megs of RAM). On the other hand I have 5 different .NET apps and a Java app running and their combined RAM usage isn't even 200 megs.
First: OO.o is Java.
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.
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.
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.
That's funny cause I've never seen a single C# or Java apps that uses as much memory as C++ programs like Firefox (currently using 350 megs of RAM) or OpenOffice.org (current using 250 megs of RAM). On the other hand I have 5 different .NET apps and a Java app running and their combined RAM usage isn't even 200 megs.
Are any of those .NET apps a web browser or office application? Both require the files they are working on (or at least a sufficiently large portion of them) to reside in local memory. I'm guessing your .NET apps aren't doing anything as data intensive.
Let's at least compare apples to oranges, here, rather than ham to tomatos.
Write your representatives! Repeal the 2nd Law of Thermodynamics!
To have a such dumb programmer that expects that memory allocations can be entirely managed by other layers ?
That's funny because any good C++ programmer will take advantage of auto_ptrs which effectively do manage memory for you automatically.
However, the idea is that an auto_ptr "knows" much more about what the programmer is doing than many of the "garbage collection" systems that try to infer it by reading tea leaves^W^Wthe stack frames.
So you are both right: garbage collection that doesn't get enough data from the programmer sucks, and programmers that rely upon it suck - but auto_ptr and Boost's smart_ptr's don't belong to that category.
www.eFax.com are spammers
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.
Are any of those .NET apps a web browser or office application? Both require the files they are working on (or at least a sufficiently large portion of them) to reside in local memory. I'm guessing your .NET apps aren't doing anything as data intensive.
The apps I am using store lots of what they are working in in local memory. One of them is a karaoke subtitle editor which holds the audio in ram, the other is a bittorrent client and one is actually a pretty bloated .NET program that is a frontend for a bunch of encoding tools and it still uses less memory than Firefox does on load up with no tabs opened.
Actually, I think it was really ment to torture that vector...
If you think C++ is staggeringly complex, you're probably not in a position to evaluate whether another 40 pages of complicated features is going to make the language any better.
Can we get a "-1 Wrong" moderation option?
Well, most of the things are already supported by compilers, or will be soon. (Se forexample http://gcc.gnu.org/gcc-4.5/cxx0x_status.html for the list of that gcc 4.5 (The newest released gcc version) supports. So it is likely that c++0x will be supported almost fully, within a year of release.
(Microsoft and intel have also implemented much of the standard).
The only thing I miss from the gcc is an implementation of "Lambda expressions" and they are working on those. (They have a branch which afair kinda works :}
Speaking as someone who was writing C++ for 4-5 years *before* ANSI came up with the original spec, that's not really the part I'm worried about. Judging by past experience, everyone except Microsoft will probably come up with a "good enough" compiler relatively quickly, and there will be a series of #defines that will allow one to simulate compliance on Microsoft compilers.
E pluribus unum
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.
azureus is a good example, but not just because of its ram footprint.. it's still dogass slow. in comparison, look at rtorrent or utorrent. nice, small, fast, efficient code. both in c++
So you are both right: garbage collection that doesn't get enough data from the programmer sucks, and programmers that rely upon it suck - but auto_ptr and Boost's smart_ptr's don't belong to that category.
Yes, relying on a garbage collector that you and the GP describe which is about 10-15 years out of date would make you a sucky programmer. Fortunately for us, though, GCs have gotten much better since then.
So your 5 unspecified .NET apps and an unspecified Java app combined don't use as much RAM as a web browser that is designed to quickly run through all tabs and documents that have been loaded since it started? Who gives a shit.
Yes, Azureus is a crappily written program. The point though is that I've seen it running with 10+ torrents for the same amount of time as Firefox and it still uses less memory. The point was that this whole notion that only Java and .NET programs are bloated use up tons of RAM is a stupid and incorrect meme.
Yes, but since every Java and .NET app are supposed to be super bloated wouldn't they by that very virtue have bigger executables and use more RAM than any C or C++ program? Or maybe my point was that such oft-repeated hyperbole is moronic.
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.
You assume the good ones have worked on any of those.
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.
for a given task, they tend to, assuming both projects had competent programmers. It's not just about storage, it's also about execution performance. .NET comes closest but still does not compare with well written native code. The difference IS noticable. There is a reason microsoft still maintains their C/C++ compiler. There is a reason OS kernels aren't written in java. There are things that cannot be done in sandboxed languages, exercises in geek masturbation notwithstanding. Sure one CAN write an office suite in java or CSS/javascript, but the result is a slow painful mess for the user.
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.
Post me one of your taskbuilder descriptor files before continuing. If you aren't competent to understand memory allocation and management at compile time, you aren't competent to be in this profession. Run time memory management is trivial.
Don't know TKB? N00b.
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.
Thats because it doesn't count the shared libraries that are loaded in the background, also known as the WHOLE .NET PLATFORM thats loaded into your ram to run anything in c# or other CLR language.
That language would be called Haskell. And the type safety crowbar built into GHC really freaking hurts (your brain)! ;)
Haskell -- The most beautiful and painful language to learn at the same time.
Am I a masochist? If so then: Moar monads, in teh gonads! ^^
Any sufficiently advanced intelligence is indistinguishable from stupidity.
There are plenty of good programmers. Like the guy who wrote Hello, World. Completely safe.
Check out my sci-fi/humor trilogy at PatriotsBooks.
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...
Wanna know what we real professionals do, who don't have the time or the stupidity to re-invent the wheel of memory management every time they write a program?
We solve that problem once, make a library out of it or abstract it out, and are done with it. We call it advanced garbage collection.
It's like a calculator: You could do all those calculations in your head, or with a mechanic tool, in less steps than the calculator needs. But why? The problem was solved decades ago.
In my eyes, between C with assembler, Haskell, and Python & co, there is no space left to be filled by C++. It's a dirty ugly language, that wants the features of Haskell with the low-level of C, but fails to be better than any of those two.
Any sufficiently advanced intelligence is indistinguishable from stupidity.
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
Wait, so having your code take up a bunch of wasted space and having to make you change a lot of code when structures or functions change is somehow a good thing in terms of development time and maintenance?
Dear Lord: One of your creatures may be hurt tonight. Please let it be the other creature.
"don't want to deal with them"? it's perfectly fine to optimize development time, but this trend of offloading excess work onto users platform is unacceptable. it directly opposes the whole point of having computers in the first place. a few years ago, some contractor tried to offload this java based mainframe screen scraper app. When we told him it was too slow for our desktops, he said "I'm sorry, but our app requires robust clients." needless to say, he did not get the sale. Apparently, professors are telling kids not to worry about performance because hardware always gets faster while ignoring the fact that it's all about performance/given hardware.
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 */
The key word is "can". Nobody's forcing you to abuse them.
I agree with the guy above though: C++ needs templates because it needs things like std::vector, std::string and smart pointers. The problems appear when "creative" people get hold of them.
No sig today...
The language that eventually became Fortran 90 was known as Fortran 8x during its development period.
Given that its now the latter half of 2009, the chances of C++ 0x actually having x==9 have been vanishingly small for quite a long time already.
Squirrel!
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.
Then use a framework, like Qt, that deals with all of that for you.
I write graphics software, and C++ allows me to write very efficient, flexible, and maintainable code that runs on a variety of architectures. Just because you don't need to mess around with pointers, that doesn't mean everyone doesn't need to.
We're already going through the same scenario as OpenGL 3.0 - lots of years spent on essentially a bare minimum of changes which in the end pissed off and disappointed practically everyone. Another coincidence, C++ is the primary language of OpenGL.
Compare what you can compare, for example tomboy memory and CPU ressources to its C++ clone, gnote, or point me to a browser as feature-rich as firefox written in Java.
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.
It would be different if the standardization committee was working on some tiny new language that 98% of the Slashdot population - let alone the world at large - had never encountered. This is C++, still one of the most commonly used programming languages in the world.
The committee would be stupid to move too quickly. Their biggest job right now is simply not to break the stuff that already works. I'm not saying C++ is already mostly great, just that changing it too much will make moving from older versions to C++0x harder.
Have garbage collectors got to the point where they can avoid scanning the entire heap when the going gets rough? Scanning the entire heap when you're low on RAM and paging to disk isn't too smart - performance will drop by six or seven orders of magnitude.
Last time I checked, the 200,000 lines of C++ that I'm working on had exactly 19 "delete" statements in it, everything else is automatic. The is hardly "manual memory management".
No sig today...
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?
How can it be safe when it's not even correct?
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.
C++ new features , Do they already have book out detailing the new features? Looks like I will have to brush up on my C++
Firefox contains a GC'd language: Javascript. And why don't you compare it to a comparable web browser written in Java? Oh right, there aren't any. Apples and oranges.
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.
In some cases it makes sense to exactly know when a piece of memory is freed. In most cases, a general GC suffices. C++ allows the 'some', Java/C# does only the 'most'. Do you have any idea how much time your program spents in GC cycles? The Java programmers I know, don't have a clue, as it usually doesn't show up in their profilers...
[...] its almost like you're ignorant or out of date or something.
Goes to show how brilliant C++ is, in a normal language psychotic fuckers can do all sorts of damage, in C++ they can't even compile...
Errrrr....
(*i) would refer to the object that the iterator is pointing at... -> is needed if that object is a pointer ( which seems to be, given that syntax and the delete (*i) )
So indeed, his code seem to be valid at first glance, and would compile if the std::vector is a container with pointers on it. Maybe C++ is more suited for psychotic fuckers than for you...
How many Java browsers are out there? None? Case in point.
So, these apps are neither browsers nor office suites? Come back when you've got something of comparable complexity. I can program a 'frontend for a bunch of encoding tools' in probably 60K of memory (if I lazily load the tools). Doesn't prove a thing.
"don't want to deal with them"?
In all programs, yes sometimes you don't want to deal with them when you can use a language feature to simplify things. Dealing with new/deletes, etc is both a tedious task and can be very error prone as one can see by the number of C++ programs that have memory leak issues. Now this isn't to say that there aren't cases where you have to do it because of critical performance reasons.
it's perfectly fine to optimize development time, but this trend of offloading excess work onto users platform is unacceptable.
It's unacceptable to use a built-in language feature, such as auto_ptr, to help to reduce the amount of memory leaks? Huh?
The rest of your post has no relevance at all to what I was talking about. I wasn't proclaiming that one shouldn't ever manage their memory manually or that you shouldn't care about performance or the quality of your code because hardware will get faster to make up for it. You seem to be ranting at someone else or else your turning my post into some sort of strawman.
I've seen such horrible Java programs from new programmers because they are never taught ANYTHING about memory management.
Well but that can be said of programs written in any language. It's not a language or frameworks fault if you can't write good code. There is nothing inherent to Java, C#, etc that mean that your program HAS to be bloated or use a lot of memory. Most of the time it happens for the same reason you see bloated and memory leaky C/C++ program: programmer inexperience or laziness.
Yes, but this frontend uses about 75 megs of RAM without anything running. When it's actually doing something it uses around 175 megs of RAM. The fact that Firefox can use more on start up with no tabs open is not a positive for Firefox.
As I read it, all the GP was saying is that if you don't understand them then you don't have any business doing anything with C/C++.
"linux is just DOS with a UNIX like syntax" -- Galactic Dominator (944134)
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.
this is a thread about C++. Not Perl
Just wait until you see the guy's APL code! :-O
There's generally more than 1 cook in the kitchen, especially when you consider the direct and indirect use of third-party code. Besides, "good programmers" is not the same as "perfect programmers." They are people, and they naturally prone to honest mistakes and oversights like ourselves and everyone else. I also can't imagine anything applications you have in mind (given your descriptions of browsers, word processors, pdf readers, etc...) is limited to anything even close to a single developer.
Additionally, there is error with everything that is made. Even something coming off a factory line isn't the same every time, and has room for error/failure. The failure rate is a large part what determines whether something is designed & manufactured well, not the fact that any failure is inevitable. Even so, the quality of product support in the event that failure does occur is equally as important as initial prevention measures.
Now when it comes to source code specifically, "safe" is relative to a number of things. Whether or not code is safe from being exploited to compromise a system is one thing, but there is also security of the information in which the application deals with, security of the intellectual property (hence why obfuscators are commonly used with managed languages), etc... Nothing is ever completely safe from every risk and hazard out there.
Could that be because Bjarne first named it "C with classes"?
I would claim that libstdc++ is what makes it a totally different language, not core C++. Drop the std additions, and you pretty much have "C with classes".
And how do you think those other languages were written?
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.
Yes, the ones that have never programmed anything other than "Hello World!".
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.
When i need to do something optional in a program i know takes a lot of memory in java (indexation for ex) i use the Process class - there is a bug, but it can be worked around) to fork a jvm, so that the memory used can be returned to the O.S. later.
I would prefer a real dynamic garbage collector though.
Newsflash: your magical language that makes everything secure is implemented in C/C++
--
Stay tuned for some shock and awe coming right up after this messages!
uTorrent vs. Azureus.
Not even 7MB of memory usage with 10 torrents going.
Now, explain how the drag-and-drop .NET program even comes close to approaching the functionality of Firefox, or OpenOffice, or even uTorrent.
DATABASE WOW WOW
I was looking forward to a language called "cocks", to bring some fresh air to the old flamewars...
--
Stay tuned for some shock and awe coming right up after this messages!
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.
Didn't you get the memo? Firefox does NOT have a memory issue. Perhaps you just haven't configured it correctly. First, open and edit a text file...
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.
If you are Doing It Right it's also impossible to get a "buffer overflow" in plain C...
About the lack of a standardized smart pointer, there is std::auto_ptr since C++98, which I tend to use quite frequently.
"Give me six lines of C++ code written by the most competent programmer, and I will find enough in there to hang him."
Languages don't make things automatically safe, but they can help. Memory safety and type safety are properties of a programming language that make entire classes of errors impossible. Of course, you can write bad code in any language, but, say, a having code execute via a buffer overflow is pretty unlikely in Java unless there is a bug in the Java implementation.
I have pretty much no experience with C++, but it sounds like using the features which are not memory or type safe is strongly discouraged (which I assume could be checked with static code analysis), so it is a bit misleading to suggest that languages like Java and C# are "better" than C++ due to having those safety features.
Centralization breaks the internet.
I'm not sure you have any idea what you're talking about.
You're comparing something that's highly rich in features, like Firefox, to an extremely bloated frontend. If it uses 75 megs of RAM to run something extremely simple, what do you think would happen with something just as complex as Firefox? Does extrapolation mean nothing to you?
Paradox
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.
Firefox has the Gecko engine which is sort of like a VM on its own for running XUL based apps. That's probably where the bloat comes from, not from C++.
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
How about Dan Bernstein?
See: http://it.slashdot.org/comments.pl?sid=1150721&cid=27084021
But if you do that you may as well code in Java.
Most of C++'s superior performance disappears when you start using what are referred to as Collections in Java. ArrayList, Vector, etc. are lean and mean - I suppose because like most Java base-classes, they were coded by someone knowledgeable in C.
auto_ptr is awful, absolutely useless for actual memory management (eg. can't be used in std::vector) and not really very "smart" at all.
No sig today...
Sorry, Slashcode fucked up my code. Jews is a vector of pointers to Jew objects:
std::vector<Jew*> Jews;
I am not using C++0x, so my code as written is proper.
"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.
std::tr1::shared_ptr is a de facto standard now (since both g++ and Visual C++ support it in latest incarnations).
The "elephant in the room" problem with GC is that computer resources are more then just "RAM".
As soon as you start adding files, network connections, etc. into the mix then you start having to do manual memory management in Java - where it's really verbose (you have to do it manually, *every time* you use a file) and easy to forget (you have to do it manually, *every time* you use a file).
In C++ the compiler writes the calls to finalize() for you automatically. You can't forget, because you never have to remember to do it.
Garbage collection seems like a good idea but in practice it fails miserably and ends up being more work and more error prone than managing RAM in C++ ever was.
No sig today...
Obviously you're still in emacs land.
Try eclipse (java) or VS2008 (really more
Reason why the main apps are still C++:
backward compatibility. And considering all the "guru" developers tried JDK1.0 and C# 2.0 and said "noway this stinks"--yes, they were too buggy, slow, and ... cutting edge. Guess what? C++ had the same reception when it first came out compared to C. BUT since the gurus got proficient in C++ by the time JDK2.0/C# 3.0/Mono/Python became mature, they poo-poo those high-level languages. And that's a flaw with the S/W development community I hope changes as newer languages like Scala, Ruby and D move forward... The new languages have untapped potential and if you can meld old concepts with new languages results in better code.
Try Java/C# now and it supercedes C++ in capability and development time. And you can always go unmanaged/native if you need backwards capability or specific performance. I sure if Mozilla could turn back the clock, we'd be on a JDK/hotspot-ish browser with threads on dedicated cores and DnD between the desktop and browser with proper security... and without bloated flash apps.
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:
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).
Several buffer overflows have been found in DJB's software, cf Guninsky.
"Give me six lines of C++ code written by the most competent programmer, and I will find enough in there to hang him."
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.
Yeah, it's a shame it doesn't play along with standard containers, but it's still very useful. I use it mostly for the ownership semantics (which is what's causing problems with standard containers...). Very helpful in keeping track of resources...
"Give me six lines of C++ code written by the most competent programmer, and I will find enough in there to hang him."
Open firefox with a blank window on windows 7, open process explorer. about 35MB.
Now, open gmail
100 MB....
do nothing, javascript garbage collector kicks in.... 70MB
Let gmail or any other ajax app who has a loop continuosly checking against a server running for hours.
Chat with integrated gtalk, open some google documents.....
Most javascript implementations have some memory leaks. With time those leaks add up.
Now, try writing the javascript engine with a managed, garbage collected language. Ping me if you survive the experience.
Your ad could be here!
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...
Lisa Lampanelli, is that you?
(Seriously, is that "comedian" capable of talking about anything other than what black cock she last sucked or fucked?)
In other words, your point was a straw man.
When people say Java is slower or more bloated, they obviously don't mean that every Java program is slower or takes up more memory than every single C++ program. For heaven's sake, think!
(Although the reason I finally gave up on Java was because the GUI toolkit was so damn buggy. This was a few years ago, though.)
There are also cases where you genuinely cannot know the exact type of the variable you want to declare, but where the compiler already does:
The function, as I intend to write it, doesn't care what types A and B are, only that operator* is defined between them, and that the result of operator* supports operator<( int ). What, besides auto, replaces some_type without pushing additional constraints onto the callers of this function?
The only thing I can do right now is either replace each reference to temp with (a * b), which sucks if operator* is nontrivial, or I can add additional constraints to the valid types for A and B, pushing responsibility for foo's implementation details down onto its callers (which also sucks).
I'd take C++ over C. And you might just as well say "between C++ with assembler, Haskell, and Python & co, there is no space left to be filled by C".
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.
operator[] doesn't guarantee bounds checking, so overflows are still possible. Also, you can get much the same effect by not memorizing the iterator invalidation rules for the various containers.
Problems with C++ that will catch C programmers:
std::shared_ptr<>, Coming Soon (tm).
Yes, and it should also have made it impossible to instantiate classes on the stack or as members of an other class/structure, so you always have to use pointers/references. But some people like not being forced to use the heap for everything.
" how many years before we can trust that most compilers can use it effectively... two, three?"
FYI, you can use a lot of it already http://gcc.gnu.org/projects/cxx0x.html
It's a fair bet that by the time it's signed off most of it will be available in gcc and you'll have an 'effective' implementation.
How quickly your shop upgrades compilers is a different problem.
i wish i could stop
Except you can still end up with memory leaks in Java, if there's a reference to the memory somewhere.
I don't know why people continue to self flagellate themselves on C++.
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.
You don't actually understand what the word "safe" means in a language context, do you?
But hey I guess any random pseudo-intellectually-superior fart noises will get a +5 around here.
There are plenty of cases where C is preferred over C++. The extra features C++ has are not without a cost.
Whoosh.
Check out my sci-fi/humor trilogy at PatriotsBooks.
So ... no actual desktop apps then?
No sig today...
Utter bullshit: I WORK FOR ACRONIS-- YOU ARE CAUGHT. If you are really an employee of Acronis, what is Jason's mother's maiden name.
Wake me up when MS rewrites windows in C#. Or Sun/Oracle releases JVM written in Java. I refuse to eat their dogfood until vendors do the same.
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.
Java programs are pretty common. A lot of "internal business apps" are written entirely in Java. For example look at financial software (look up job postings for hedge funds), Operations/Supply chain tools (i2 ) or many other programs that gets outsourced to third parties (IBM, Infosys and others).
These applications have the advantage of being run only on a specific configuration and so don't have to worry about the right JRE etc. Program size is often not a constraint and speed is pretty good. I have sometimes seen high frequency traders in stock markets code in Java.
Don't diss Java just because very few commercial apps get developed in it.
Same goes for C# - Microsoft convinced many large Java users to switch to C# (Dell was an early adopter). And nowadays anyone who uses Microsoft SQL Server uses C# to write apps around it.
There was a time when people expected computers to be fast. But I guess in the world of web applications that dream will end.
Computers *are* fast. Fast enough that people can have the relatively slow-running web apps they love. You're free not to use them of course.
I'll get off your lawn now.
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...
Also amazon is about half Java half C++. The parts that need to be right and fast- written in C++.
I still have more fans than freaks. WTF is wrong with you people?
Shrink-wrap applications represent a tiny, tiny, tiny fraction of applications. Internal business applications are the vast majority and those are often written using Visual Basic, Java, C#, COBOL, etc. What you personally have seen represents a negligible chunk of the market.
Parent is not a troll. Please fix. If you don't agree with him, the proper thing to do is argue with him, not moderate him.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
See subject because it's stupid little shits like you that know squat about this field that ought to get a good punch in the jaw to knock you the fuck out.
As one that works in the embedded world ... I cringe at your cruel usage of the stack. Stack over flow ... bad. At least in virtual space with unmapped guard pages around the stack(s), the worst that will happen is a jarring MMU fault. In kernel space ... YIKES!!
here's an example of why we need an "auto":
template <typename parent_type, typename query_type>
struct recursive_query
{
typedef recursive_query<parent_type, query_type> this_type;
template<typename query_type>
recursive_query<this_type, query_type> operator[](query_type q);
};
struct query_base
{
template<typename query_type>
recursive_query<query_base, query_type> operator()(query_type q);
};
recursive_query<recursive_query<recursive_query<recursive_query<query_base, const char *>, int>, std::list<int> >, float> result =
// or would you rather write:
recursive_query<query_base>["foo"][5][my_list_of_ints][4.2];
auto result = recursive_query<query_base>["foo"][5][my_list_of_ints][4.2];
if you don't understand why you might need a recursive type like that, learn more about metaprogramming! it's the bee's knees!
So, if you're good with powertools you can be safe without guards, eye protection and hearing protection? I suppose you think that all the buffer overflow and memory leak problems we've seen in high quality software is because the programmers are no good. Nobody claims absolutes, but language features that make it easy to do the right thing make it more likely that people will do the right thing. Language features that allow you to do something that is likely to cause problems increase the risk that these problems will occur. That's just basic probability.
I can tell you that I have had to debug off-by-one errors in Fortran and C (where no range checking is done, so you can easily end up modifying the next variable in memory rather than the last element of your array), but never in something like Matlab or Python where range checking is done. Now, that may make me a bad programmer, but show me the programmer who has never made a typo.
Languages aren't inherently fast -- implementations are efficient
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.
Actually, no.
auto_ptr is useful for handling resource release when the stack is unrolled due to a thrown exception. There are technical reasons for it.
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.
That's the most brilliant metaphor I've heard in a long time.
Property is theft.
Not only are you completely flat-out wrong about "98%" of OpenOffice being C++, you also use the phrase "Bzzzt wrong," which makes you obnoxious.
"Sufferin' succotash."
son of C and an impure virtual function.
Now you get 2, 2, 2 languages for the price of 1.
N' delay pas. Acheter now!
Please please let it die.
Can't we use a decent 21st century language
with embedded D or something for the
bare metal access sections.
Where are we going and why are we in a handbasket?
most of our vulns are in the Java code in our product. which makes up only about 30% if you go by LOCs. The rest is plain old C (not even C++). Programming mistakes are spectacular in C, but mistakes in any language can be a serious security problem. There is something massively more important than typesafe and memory safe, and something that C and C++ do badly (and Java is fairly weak at). Everytime people bring up typesafety as some sort of amazing feature that solves every problem I just roll my eyes. Most of the time when I run into people that gush praise for such a simplistic language feature I mention formal verification and their eyes glaze over. I guess formal verification isn't as cool of a buzzword, or it's just too process-oriented to be a quick and easy fix to all your problems. Sorry, but their ain't no magic bullet, you gotta work hard to make good software. (formal verification means you work hard, but when you're done you at least aren't guessing anymore about the correctness of your software)
C++ is being used in areas where speed matters. WITH templates. In fact, expression templates are one of the primary tools for writing fast code in C++ without having to go to a low semantic level, like in C. Using expression templates, I can write the actual expression, and the templates will unroll to form the optimized code. Yes, this is used in practice. Google for Blitz++ for an example.
This sig does not contain any SCO code.
I've been working in C# with people who don't understand memory management. Now, where's my crowbar...
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.
When so-called "software standards" include real Engineering testing and certification by third parties, civil liability for bad software that causes serious fiscal losses including lost time spent deploying bad software, and real repercussions for code monkeys that don't FOLLOW the standards, wake me up. Yawn.
+++OK ATH
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.
Languages don't make things automatically safe. Huge languages with retarded defaults, make things unsafe for sure.
I once felt that standards-compliant C was a bit limited. I went to try C++ only to find out that it was a security nightmare. For each of the big features, there was an even bigger hole in the middle.
Sure, many C library functions are insecure, and some algorithms are as well, still, the average programmer can learn C in an out with some effort.
C++ is not only huge making learning all of the implications impossible, additionally it promotes insecurity by means of fatally flawed libraries.
In C you have backwards compatibility requirements, in C++ you just have retardation. The whole standard c++ library should be thrown down the sewage, then templates need to be included properly in the language without weird syntax and verbosity. Then and only then, can C++ be taken seriously.
VC2010 already supports a C++0x subset - see http://blogs.msdn.com/vcblog/archive/2008/10/28/visual-studio-2010-ctp-released.aspx
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.
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.
Working on a large flash game, I frequently ran into code like this:
variableName = null;
... because Garbage Collectors work based on references. That line of code is directly equivalent to
delete variableName;
There were *more* memory leaks in that application than in any non-GC'd app I'd worked on, because programmers got lazy and figured GC would take care of everything for them.
And that's just the first problem I have with GC. The client demanded this program be done in flash or no contract, so we were stuck with flash. Our graphics suffered a few framedrops every few seconds, and we determined it was due to Garbage Collection, which we have no controll over. Our workaround, which makes me sick to this day, was to allocate a bunch of random lightweight objects every few cycles to trigger their garbage collection more often.
That just wouldn't have happened if we used C++.
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.
Its not that they don't want to. Often, they could do it with their skills, but other factors stop them from doing so. Like, budget, deadlines.
Of course there is also the fact that people are lazy, and it is just so inconvenient to worry about writing that parser with security in mind, right? "It is not motivating, and I want to see something cool, so lets hack the parser, I will do it properly later" (which never happens) ...
This sig does not contain any SCO code.
But how did it get so big then?
The saddest poem
There are many ways to bloat a C++ program. For one thing, if you split it into lot of small DLLs, and heavily use templated libraries everywhere (STL, but also some in-house stuff), you get the same repeated bunches of template instantiations in every DLL. Another contribution to it was gratuitous use of code generators, and this gets especially bad when combined with templates from the first point (nothing like a code generator to produce as many instantiations as possible). I remember that at some point we actually started hitting MSVC .obj file format limitation of no more than 65536 symbols per .obj (every member in every template class specialization produces a distinct symbol).
Who gives a shit. They lost me when they first announced C++0x
C++ was a great old language (sometimes, when the moons were aligned), but I've moved on. They needn't bother trying to patch up a patch up for an old obsolete language (and I do apologize to C fans.. I know I'm being harsh). Opinion, sure, but you gotta admit, we don't need a patched up C++.
I strongly disagree.
First off, you write C++ the moment your code is C++ standard compliant. C++ is a multi-purpose language, almost like a swiss army knife. People have different styles, and there are tons of ways to approach one single problem. Just because one is reluctant to use inheritance, RTTI and other features doesn't make ones code less C++'ish. I use C++ mostly for template and procedural programming, but I do use other features when they make the most sense as a solution.
"If you don't use keyword/language semantic X, then you don't really *use* the language" is utter crap. Sorry.
Second, your claim that you can avoid buffer overflows is theoretical at best. You don't seem to take performance into account. Sure, some people have the luxury to check the ranges in the overloaded subscript operator and throw std::out_of_range exceptions when something bad happens, but that's far from everyone. C++ is often a choice because of its performance.
Third, removing support for old-fashion arrays would make C++ much harder to use on embedded platforms which are short on memory and/or have no memory allocation scheme. If you then have to write a custom allocator, nothing is gained. And why use vector when all you need is a fixed-size array as automatic storage. The construction overhead of a vector is rarely a problem compared to a old-fashioned array, but it can be.
That's complete bullshit. An Iterator is not much more than a pointer. In fact, std::vector was specifically designed such that X* is a possible implementation of std::vector::iterator. And you pretty much can't avoid Iterators in C++.
A little, er. persuasion is in order here. Committees are what they are, but add some heat and they'll GET TO WORK and so can we.
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?
http://gcc.gnu.org/gcc-4.5/cxx0x_status.html
It's not that bad. Many of the simple, neat features (like auto typing and initializer lists) are available already. Also, many of the library improvements are just standardizations of existing libraries, so it won't take that long for implementations to catch up. The main reason for all this is that one of the criteria for inclusion of a feature into the standard was the existance of an implementation. And this is why concepts were dropped. There is the conceptGCC implementation, but several people were not satisfied with the design of concepts that conceptGCC implements. If the decision was made to change that design, concepts were not standard-ready anymore (no existing implementation).
Since C++ is a super set of C by definition, your suggestion that it is a totally different language is clearly wrong.
As for, 'If you're Doing It Right then it's impossible to get a "buffer overflow"'. That's like saying if you don't make a mistake there won't be any mistakes.
I suggest you take time out to reflect.
RValue references do not give any major performance benefits - it's the move operation that gives the performance benefit. RValue references can be emulated by templates in the current version of the language. RValue references is a notation for making move semantics available to the compiler. Move semantics are not magically supported. You still have to code the move constructor and the move assignment operator.
Moving data around is a dangerous practice. Auto_ptr was considered bad exactly because of this - you don't know where your data may end up to. Moving data means more destructive updating. Modern programming language theory is slowly moving away from destructive updating, as it is much easier to do better optimizations when things are not allowed to be destructively updated. I expect that there would be a lot of problems in production code from this, when non-const variables will be passed to functions that reset the variables to their initial state; it would be the auto_ptr fiasco all over again.
Spoken like a true Software Architect!?
How about using a technology that doesn't need children crawl inside big machines, in the first place? But you're right. How dare I propose such a thing?
The technology has always worked that way and it always will. Never touch a running system!
And don't worry about the children. They're abundant and cheap. We're doing their parents a favour!
Seriously, "not killing children unless there's a bug" isn't that great a software feature. My guess is you've been working with C++ for far too long. Maybe you should take a look around you and outside the C++ world. Modern software development is more like procreation :)
And your paraphrase is wrong. God isn't responsible for letting the kid die. It was the guy who's specified the child go into the machine.
(USER WAS PUT ON PROBATION FOR THIS POST)
So is this correct?
Let me give you a hint: it's not. It still allows for buffer overflows. Why is the operator [] not bounds-checked is beyond me. They could have had the operator [] safe and the function at() unsafe, if you really wanted such fast access.
http://www.mozilla.org/rhino/
Is this true? I understood that a mark & sweep GC as default in Java leaves some memory allocated, but a GC does not have to be mark and sweep. Especially if performance is less of a burden you could do GC for 24/7. You would loose some performance but you would gain memory. And then you could go and sit somewhere in the middle and use the G1 gc in Java, which trades in processor time in another thread. Besides, even compiled languages won't leave each and every piece of memory usable. Without anything to "collect the holes" a compiled language may be more of a memory burden when it is used as a service.
If anything I think the meta-information used by the managed languages and scripts is much more of a memory burden than the garbage collection (although the Java implementation certainly leaves some things to be desired). You can strip a lot of that out of your Java application by removing all debugging information (and renaming all classes and methods), but your exception stack will look horrible without any line numbers etc. And Java is more about easy maintenance than anything else.
Most C++ features *don't* have a cost in performance. Among these are:
- templates
- RAII
- namespaces
- operator overloading
virtual function calls do have a cost, but it's not larger than what you get when you implement the same stuff manually in C. Also, C++ can be a *lot* faster than C due to templates. Try sorting an array of doubles using qsort and std::sort. The C++ version will be faster, because you can avoid a function call. Additionally, qsort can only sort arrays, while std::sort can sort anything that provides random access (such as a std::vector and a std::deque).
There is no way to avoid buffer overflows in any language. You just can't.
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.
Agreed. The absolutely sanest way I've found to develop is that memory follows objects. New instance? Memory allocated. Delete instance? Memory cleared. You fill up an object list = You run out of memory, but there's no "loose buffers" anywhere that you allocate somewhere but never gets cleared in the other end. If you really need to send "memory" around, send values (Qt has some really neat implicitly shared classes that means performance doesn't hurt much). I'd say almost all code can be written in a way that gives you 80% of the performance using only sane methods, and the reminder should probably have a assembler implementation with a standard fallback...
Live today, because you never know what tomorrow brings
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.
snprintf is faster than a stringstream simply because it does less. With stringstreams, you can build strings of arbitrary length, which forces the stringstream to allocate memory dynamically, which makes things slow. Of course, there is a way to avoid this: write your own streambuf that writes to and reads from a fixed-size buffer instead of a std::string. This way, you get all the stream goodness (for example, extensibility to user-defined types and type safety) without paying the cost for a feature you don't need.
(captcha: impostor :o))
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)
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.
Or worse. multi-paradigm programming is akin to messy code. Lots of C++ code provides paradigmatic examples of this. Just like sort-of kind-of kind of argumentation of:
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.
:D
In reality, there are examples where C++ induces 5-10% run-time overhead compared to the same code in FORTRAN 77 when compiling numerically intensive code using classes/templates.
Firefox has it's own XUL and other abstractions that are nearly as involved as a Java VM.
Can you hack a barebones lynx?
Well duh - lynx is written in C, which is perfectly safe. It's C++ that's the problem.
I think this gets into where people abuse headers. I NEVER put code into header files (unless it's maybe a small macro which will get in-lined by the compiler for performance reasons). Headers get things like function and class definitions - which aren't code, they're just information for the compiler to use at compile time. Also, symbolic constants (e.g. #define RED 0xFF0000).
I've not done much with Templates (I've not done much C++ coding in the past few years since I took some classes on it in college), maybe you'd put a template into a header, but again, that's something for the compiler to use at compile time, not code, IIRC?
What else would you be putting in the header? How does that duplicate code? By writing a header file once and including it in other files, aren't you *reducing* duplication?
You have missed the real purpose for the "auto" variable type. While you can use it to reduce the amount of code you type, it's real purpose is to define a typesafe variable of a type for which it is IMPOSSIBLE to write in your code (lambdas).
OK, so ActionScript's GC seems to suck. How does that relate to GCs in general?
See Haskell.
Or worse. multi-paradigm programming is akin to messy code.
Not necessarily. D is multi-paradigmatic with a much nicer syntax. C# has a nice functional core, even though it started as an OOP language. Do not let the C++ syntax problems fool you; C++ syntax sucks no matter what you want to do :)
In reality, there are examples where C++ induces 5-10% run-time overhead compared to the same code in FORTRAN 77 when compiling numerically intensive code using classes/templates.
5-10% is a margin where compiler flags and the used compiler are relevant. Also, there is always the possibility that expression templates weren't used properly..
This sig does not contain any SCO code.
C++ does have standard smart pointer types. std::tr1::shared_ptr, std::tr1::weak_ptr etc. are all available in the Technical Report 1 extension to the C++98 standard. Many C++ programmers, including myself, make heavy use of these types.
Regards,
Roger
different people mention just yet one more feature that would make C++ compete with alternatives.
I feel that that feature is Reflection
(introspection) -- ability to find at runtime
for each class
methods names, arguments names and argument types to those methods, data type
and platform independent serialization (both are related).
This would give C++ ability to have Strong database access library (ORM),
session management for stateless operations (via serialization)
and therefore would allow creation of C++ web frameworks that have built-in ORM, session management, etc
languag
This conversation is what's wrong with C++. It is at least two fully independent languages, servicing at least two different interest groups. I'm not sure how relevant either group will be to long-term computing trends, like parallelism. However, first I am going to consider two groups of people that C++ services well.
First, for the low level people, C++ is C with classes. These people want the ability to control every memory allocation and deallocation, although in practice, they only want control over some of them. The low level people use C++ as high-level assembly, and occasionally refer to the assembly print outs. The low level people still don't understand why C++ hasn't fixed it's pointer bug that would make numerical code as fast as FORTRAN. These people know what an interrupt handler is, and may have even written one. Accordingly, RAII and exceptions are explicitly banned from large segments of code.
The second group of people actually use templates and RAII. The big advantage of RAII is that it handles all memory allocation automatically. It brings back the simplicity of the really old (pre-pointer) PASCAL and FORTRAN programs, where everything was allocated on the stack and no memory leaks existed. RAII's big contribution to programming is memory leak-free programming. This second group of programmers, want ease of programming as much as performance. The code they write, makes for very complex assembly. The second group is comparing C++ to languages like C#, Java and Haskell. They are interested in trading off the speed of program writing with the speed of execution.
Some people will quickly point out, that other groups of people may exist. I think a few commercial projects have tried to blend the two extremes. In practice, I think C++ may be too overgrown to be a usable language. If the programmer wants to be safe, use Java. Otherwise, embrace the danger, and do the memory allocs and deallocs are manually, sometimes with custom memory handlers. Use the assembly, as the compilation is being done for speed. However, these are also yesterday's tradeoffs.
Today, parallelism is the new speed optimization. For parallel programming, neither RAII or low-level C++ hacks create a good speed of programming vs. good speed of execution trade off. With multi-CPU, NUMA architectures, the applications need good memory control and multi-processor support. FORTRAN with some of its super-computer extensions is a better language for some of this stuff. Hadoop is uses Java.
Where does C++ sit in this new trade-off? The new standard is silent.
As soon as you start adding files, network connections, etc. into the mix then you start having to do manual memory management in Java
So don't use Java. C# has using blocks which call Dispose() on your object when they're exited, whether that be through normal program flow or abnormal exit.
In short: don't assume all languages with a GC suck just because Java does.
It's hopelessly outdated and crufty, but it will never go away because it's too big to die. Good thing that at least it's not evolving anytime soon, so people might start to look around for simpler, safer and more powerful languages to replace it. There are plenty.
RValue references do not give any major performance benefits - it's the move operation that gives the performance benefit. RValue references can be emulated by templates in the current version of the language. RValue references is a notation for making move semantics available to the compiler. Move semantics are not magically supported. You still have to code the move constructor and the move assignment operator.
I know about the rest of it (though obviously move constructor is enabled by rvalue references). But can you clarify the bit about "emulated by templates in the current version of the language"? I recall there being a few hacks, but wasn't they far from universal?
Moving data around is a dangerous practice. Auto_ptr was considered bad exactly because of this - you don't know where your data may end up to.
auto_ptr is dangerous not because it moves data, but because it does that in operations which have copy semantics for all other types - i.e. copy constructor, and operator=. In other words, it moved data regardless of whether it is safe or not. Rvalue references let one constrain move semantics such that it only gets applied when it is safe to do so.
I expect that there would be a lot of problems in production code from this, when non-const variables will be passed to functions that reset the variables to their initial state; it would be the auto_ptr fiasco all over again.
Non-const variables (and, in general, lvalues) don't bind to rvalue references, by design. So you won't get anything quietly moved from a variable, only from a temporary - that's why there's std::move added to allow you to explicitly request move-from-lvalue.
You would loose some performance but you would gain memory.
Sometimes both performance and space are important, and then GC is inappropriate.
Without anything to "collect the holes" a compiled language may be more of a memory burden when it is used as a service.
Compiled languages do not imply no garbage collection. There is even a garbage collector for C, which lets you remove the "free()" calls from code: Look for Boehm GC or libgc. It does not always collect everything (it does not know aout types and an integer might alias a pointer), and if you do funny things like storing the color of a red-black tree node in the low bit of the pointer it will break horribly, but it works.
Those who would give up liberty to obtain working drivers, deserve neither liberty nor working drivers.
To continue the analogy...
The new, 'safe' machine still crushes children, but it hides it a lot better. In fact, while the old machine would only crush children when they stayed under it while it was coming down, sometimes the new machine would just randomly pick a child and crush it. However, when the new machine crushes children, it's "user error", but the old machine it was "a dangerous machine".
The new machine is more efficient at dealing with a coarse weave fabric, but the old one would handle anything, including extremely fine, valuable fabrics, and would do it all with relative ease.
However, anybody who only needed a machine which dealt exclusively with coarse weave fabrics immediately purchased this new machine, and decried that anybody using the old machine was stupid, failing to see the inherent superiority in this machine which crushed 10% fewer children, provided all the children were the slow and constantly making mistakes.
Whatever happened to "the right tool for the right job"?
Yes I would suspect that such a streambuf, along with some methods to reset/clear it and to get the char* pointer without copying, would get the speed up to match unless the compiler is really stupid.
They could also write stringstream so it has a fixed-size buffer as part of the structure. I would not be surprised if 99.99% of the uses are 128 bytes or less. When the buffer overflows it starts allocating one. They also need to put a method to get a char* pointer directly, all legal things str() can call will copy the buffer and rvalue optimization does not help here. Yea the compilers put tricks in there such as secret string constructors but this is why we have unreadable error messages.
I can tell you that figuring this out would be a hundred times harder than using snprintf. It is true that it could make up for it by allowing complicated objects to be printed, my normal solution has been to add a "print yourself to this buffer" call that uses stringstream internally, which adds up to the same complexity.
I'll even let you start over and not keep backwards compatibility with old code.
Then I'd start over and not keep compatibility with C. Maybe use a Smalltalk-like syntax and encourage reflection. Dynamic typing and binding by default, maybe even relegate static typing to optimization with assertions. ... ... ellipses ... more ellipses ...
I have switched to C++ exactly because overloaded operators allowed me to program transformation in parametric domain (think Fourier) in a natural way, like C = B*A.
And that's better than (set 'C (* B A)) why?
I once took a course in JBoss administration that included a section on tuning garbage collection. It convinced me that GC is a bad idea. It may make it easier for programmers but it shifts the burden for efficient memory management into a domain where it doesn't belong. Effective memory management is very sensitive to the design of the application. Shifting it to a generalized facility that runs garbage collection based on the short, medium or long duration of objects is an administrative nightmare. Someone writes an app that goes against the rules configured into the GC and the performance of the whole server suffers. So now we have training classes for Java programmers on how the GC works so they can write more efficient programs. How is that different from teaching C++ programmers a few simple code design disciplines (encapsulation, proper use of auto_ptr, etc.) to minimize memory management problems in their code?
Because C++ is the pinnacle of programming knowledge? *giggle*
Are you trying to come over as a little school girl? (You succeeded.)
Compared "vector" with "int*" for three different architectures. The vector does take slightly more instructions, and this seems to be an extra indirection to get at the underlying array. This is likely to be amortized out in longer expressions, so I think this difference can be ignored.
However that was with -O and a relatively newer GCC compiler. With -Os however the amount of generated code for vector was much greater, and the [] operator did not seem to be inlined. The -Os flag does get used a lot when memory space is tight.
When C++ was new, the compilers were not really that great with optimization and being able to fall back to the C operators was very important. Without this I think C++ would have taken much longer to catch on in the scientific or systems programming areas.
Good. There's an overpopulation problem.
You mean when it the programmer isn't clever enough to figure out how to do it. Reread how to use classes.
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
How many Java browsers are out there? None? Case in point.
I'm working on a fix for that. I could be doomed. :-P
-IOVAR Web Dev Platform
Thanks for the information. I'm interested in what toolkits commercial software vendors are using. I'd actually like to go back to C++ for personal and small commercial stuff. (I hate web programming.) What would be a good development setup to go along with the FOX Toolkit with respect to compilers or other tools? Free and cross platform have an appeal.
I wish people would write some good articles about these kinds of things - what different companies are really using.
Personally, I don't have much liking for FOX. The main reason why Acronis is using it today is because in-house FOX fork has been ported to all kinds of things: not just Win32 and X11, but also Linux framebuffer (this is used for Acronis recovery CDs), and even EFI (this is fore special editions of Acronis products that are sold to hardware manufacturers to be embedded into sold hardware; imagine True Image restore module in your BIOS...). It's a pretty interesting port, too, because it tries to preserve look and feel of Win32 widgets (if you ever saw an Acronis boot CD, or Acronis boot loader, you should know what I mean).
When FOX was originally chosen, Qt was IIRC still GPL'd and thus unusable in commercial settings, and there was a need for a toolkit that draws all its widgets itself (rather than a wrapper on top of OS or another toolkit), for those framebuffer and EFI scenarios.
By itself, FOX is really just your basic C++ toolkit. I'm not aware of any special tooling existing for it, but even if it does, we just hand-coded all UI. So all you'd really need is a C++ compiler. Can't beat VC++ on Windows (I know it's not free, but there's a reason why virtually all commercial shops use it, and not e.g. MinGW, for Windows development); and, of course there's no contest with g++ on any other platform.
We used VC2003, later migrating to VS2005, for all Windows builds, and g++ for Linux/MacOS/EFI (several different versions, I don't remember the exact ones, but it was 4.x by the end of it). IDEs? Well, Visual Studio provides very nice debugging experience on Windows (duh), and our hardened and brutal Linux guys mostly just used gdb directly. No idea about how OS X team handled it, but I'd guess XCode.
Editor-wise, it was free for all. Some used VS, some Vim (including Vim/Win32), some Emacs (again, including Win32 port), a lot used the built-in editor in Far Manager with Colorer for syntax highlighting, and there were some even more obscure combinations.
That's probably the big reason, for example, that the iPhone doesn't support GC in its Objective-C implementation.
Yes, it does.
Rhino anyone? (FGoogle it yourself!)
I know tobacco is bad for you, so I smoke weed with crack.
http://lobobrowser.org/java-browser.jsp
I know tobacco is bad for you, so I smoke weed with crack.
I've worked out the problem you guys (possibly girls too) all seem to have. You seem to think the purpose of the C++ committee is to, generally speaking, improve the C++ language. Given their conduct to date, I fail to see how you could arrive at such a conclusion. However, I will clarify the situation so that further confusion can be avoided.
The purpose of the C++ committee is to guarantee that C++ IN NO WAY interferes with the popularity of C.
Some of you will think I'm joking whereas the rest will know that I speak the truth. :(
My parrot changed sex today. That's not a joke. We always thought it was a male, and it also had the male colored beak. This morning... It had changed color entirely from blue to brown. It's a female now, and deeply fallen in love with an other parrot.
No, it does not. Unless you're talking about auto-release pools, which still require a ton of hand-holding and I don't think anyone would consider a true GC.
William Selden, Gertrude Tierney, Howard Bromberg, Howard Discount, Vernon Reeves and Jean E. Sammet.
I wondered this myself. How can a few hundred K of HTML/javascript and images turn into 10-15M of memory usage. The only explanation is the DOM structures are being constructed and left in memory, and Javascript garbage collection/leaking.