Latest Proposals for C++0x 911
CodeDemon writes "It looks like the ISO/IEC JTC1/SC22/WG21 working group has made some headway in reviewing new proposals for the C++ language. The long anticipated upgrade for C++, C++0x, may be just around the corner. Head on over to check out the proposals yourself."
It keeps going and going.... (Score:4, Funny)
Re:It keeps going and going.... (Score:4, Funny)
Re:It keeps going and going.... (Score:3, Informative)
Well, since there was never a "C+" language, and you increment variables by one with "++" (hence the inherent joke in the name "c++"..."c incremented by one") a more logical construct would be (c++)++
Re:It keeps going and going.... (Score:5, Funny)
I'm rooting for C+=2.
Re:It keeps going and going.... (Score:5, Funny)
And the other joke of an Object-Oriented COBOL being named, ADD ONE TO COBOL.
Re:It keeps going and going.... (Score:5, Funny)
Re:It keeps going and going.... (Score:5, Funny)
Yes, but it's postincrement, so the result is still C without any added value ;-)
Re:It keeps going and going.... (Score:3, Interesting)
(C++)++ invokes undefined behavior, because you're altering the same variable twice before the next sequence point.
c += 2 (Score:5, Funny)
So let's see; somebody else already proposed (c++)++ , which is a reasonable suggestion... but... um... how about "c += 2"? For now, it's as concise as the alternative, but going forward it will scale better (c += 3 vs ((c++)++)++ ).
Re:c += 2 (Score:5, Funny)
Re:c += 2 (Score:4, Funny)
And that you would post that indicates that you don't really know what humor is all about.
Re:c += 2 (Score:4, Funny)
Re:c += 2 (Score:3, Informative)
The expression ++c++ is equivalent to ++(c++). Since the postfix increment operator yields an rvalue (unlike the prefix increment operator, which yields an lvalue), ++c++ is not a valid expression in C++.
Re:It keeps going and going.... (Score:5, Funny)
Re:It keeps going and going.... (Score:3, Funny)
TIME TO RETIRE C++ (Score:5, Funny)
I'm a first year programming student at an Ivy League school and I've
just finished my Visual Basic classes. This term I'll be moving onto
C++. However I've noticed some issues with C++ that I'd like to
discuss with the rest of the programming community. Please do not
think of me as being technically ignorant. In addition to VB, I am
very skilled at HTML programming, one of the most challenging
languages out there!
C++ is based on a concept known as Object Oriented Programming. In
this style of programming (also known as OOPS in the coding community)
a programmer builds "objects" or "glasses" out of his code, and then
manipulates these "glasses". Since I'm assuming that you, dear reader,
are as skilled at programming as I am, I'll skip further explanation
of these "glasses".
Please allow me to make a brief aside here and discuss the origins C++
for a moment. My research shows that this language is one of the
oldest languages in existence, pre-dating even assembly! It was
created in the early 70s when AT&T began looking for a new language to
write BSD, its Unix Operation System (later on, other companies would
"borrow" the BSD source code to build both Solaris and Linux!)
Interestingly, the name C++ is a pun by the creator of the language.
When the first beta was released, it was remarked that the language
would be graded as a C+, because of how hideously complex and unwieldy
it was. The extra plus was tacked on during a later release when some
of these issues were fixed. The language would still be graded a C,
but it was the highest C possible! Truly a clever name for this
language.
Back to the topic on hand, I feel that C++ - despite its flaws - has
been a very valuable tool to the world of computers. Unfortunately
its starting to show its age, and I feel that it should be
retired, as COBOL, ADA and Smalltalk seem to have been. Recently I've
become acquainted with another language that's quite recently been
developed. Its one that promises to greatly simplify programming. This
new language is called C.
Although syntactically borrowing a great deal from its predecessor
C++, C greatly simplifies things (thus its name, which hints at its
simpler nature by striping off the clunky double-pluses.) Its biggest
strength is that it abandons an OOPS-style of programming. No more
awkward "objects" or "glasses". Instead C uses what are called
structs. Vaguely similar to a C++ "glass", a struct does away with
anachronisms like inheritance, namespaces and the whole
private/public/protected/friend access issues of its variables and
routines. By freeing the programmer from the requirement to juggle all
these issues, the coder can focus on implementing his algorithm and
rapidly developing his application.
While C lacks the speed and robustness of C++, I think these are petty
issues. Given the speed of modern computers, the relative sluggishness
of C shouldn't be an issue. Robustness and stability will occur as C
becomes more pervasive amongst the programming community and it
becomes more fine-tuned. Eventually C should have stability rivaling
that of C++.
I'm hoping to see C adopted as the de facto standard of programming.
Based on what I've learned of this language, the future seems very
bright indeed for C! Eventually, many years from now, perhaps we'll
even see an operating system coded in this language.
Thank you for your time. Your feedback is greatly appreciated.
Egg Troll
Just call it E. (Score:4, Funny)
Re:Just call it E. (Score:3, Funny)
Re:It keeps going and going.... (Score:5, Funny)
Great language!! Would code in again!!! C++++++++++++++++++
why not... (Score:3, Funny)
Re:why not... (Score:4, Informative)
I've no idea if there was an A though.
Re:why not... (Score:4, Informative)
Re:C++ == Algol++++++++++ (Score:4, Funny)
where does the name come from? (Score:4, Interesting)
Re:where does the name come from? (Score:5, Informative)
Re:where does the name come from? (Score:5, Funny)
Didn't we learn anything from Y2K? How am I going to tell the difference betwen code written to the C++ 2005 standard and the C++ 1905 standard?
Re:where does the name come from? (Score:4, Interesting)
Re:where does the name come from? (Score:5, Insightful)
Re:where does the name come from? (Score:3, Funny)
Re:where does the name come from? (Score:3, Funny)
"C++ is to C as Lung Cancer is to Lung"
- a sig I read on slashdot
NULL pointer dereference (Score:3, Funny)
Supercalifragilisticexpialidocious! (Score:5, Funny)
Someone try to say that ten times fast!
Re:Supercalifragilisticexpialidocious! (Score:3, Funny)
yes, this is supposed to be funny
C++0x ? (Score:5, Funny)
The hardest part is deschiphering the comments...
Alan (Score:4, Funny)
What does Alan C++0x think of this?
Alan C++0X (Score:5, Funny)
C++0x? (Score:5, Funny)
I've...I've been living a lie...
Anonymous array members (Score:5, Interesting)
struct somestruct {
int a;
int [3];
int b;
}
vs.
struct somestruct {
int a;
int pad[3];
int b;
}
The only thing its really saving you is the variable name, and its giving you an extra check at compile time to ensure you don't use the 'pad' array. Which shouldn't be a problem with proper variable naming and documentation, right?
Re:Anonymous array members (Score:5, Insightful)
I suppose this is what happens when you allow a programming language to be designed by a committee...
Useful for structs/unions (Score:3, Interesting)
Suppose I have:
struct foo {
int i;
struct bar {
int j;
int k;
} s;
} n;
Now to reference j, I have to say n.s.j. But why not leave the s out so that I can just reference n.j?
This becomes really useful is when you have a huge project and you decide that some element of a struct should be made into a union. Now you wouldn't have to change every reference throughout your project (or use
Re:Useful for structs/unions (Score:4, Insightful)
Re:Useful for structs/unions (Score:3, Insightful)
Re:Useful for structs/unions (Score:3, Informative)
COBOL (Score:5, Funny)
Re:COBOL (Score:5, Interesting)
How 'bout range checking like purify? (Score:4, Interesting)
Re:How 'bout range checking like purify? (Score:3, Informative)
Works for C, but probably can be made to work with C++ too by writing an operator new that uses malloc() internally. Not sure if glibc actually does that.
Re:Lack? (Score:3, Insightful)
Instead of leaving it as "undefined", they should define it as "If compiled with array range checking so and so exception should be thrown with the name of the variable and line (given debugging info is one)" or something...so that at least it is USEFUL.
learn from Java (Score:3, Insightful)
hehe.. sorta (Score:5, Insightful)
With that said, it's an extremely powerful and flexible language. Very much more powerful than Java or C#. The complexity is mostly due to its flexibility. You can do (almost) anything with it. Of course, we can argue whether that's good or bad.
I think C++ can learn from Java though. The default should be to pass all non-built-in-type function parameters by const reference and the programmer has to specify otherwise (basically opposite of the way it is now). That would clean up the code a whole lot since 99% of the time that's what you want anyway. And the standard C++ library should have some sort of garbage collector available.
Another problem I have with C++ is that even with all its power you have no way to get to the "left hand" variable of operations. For example, if you have a matrix class you can overload the "+" operator so that you can do things like "matrix3 = matrix1 + matrix2". However, that's not going to be very efficient (assuming that's why you're using C++ in the first place) because there is no way to get to the matrix3 variable from inside the + operator. That forces you to use a temporary variable to add the two matrices then copy by value the whole matrix after adding matrix1 and matrix2. There are tricks around this problem but none are clean.
Re:hehe.. sorta (Score:3, Interesting)
Why in the world would you want access to matrix3 from the plus operator???
Re:hehe.. sorta (Score:4, Informative)
To fill the matrix (which we assume is large enough to make copying the values expensive) directly, instead of copying it into a temporary matrix with the overloaded '+' operator then copying it over with the overloaded '=' operator. You could do
MatrixAdd(const matrix& m1, const matrix& m2, matrix& result);
but then what's the point of overloaded operators?
Isn't it obvious? (Score:3, Insightful)
Well, I think the obvious answer is: NONE
I'm sorry, but operator overloading is one of the most gratuitous and depraved features to make it into the language. And it's not just needlessly pretty, but causes all kinds of subtle errors. From not being able to be sure what "a + b" actually does, to disabling the guaranteed evaluation order in boolean expressions.
Re:hehe.. sorta (Score:3, Insightful)
And guess, what, YES, there are problems which are easier to program in C++ than in C#. My job is mostly programming in C# and I'd rather be programming in C++.
There is NO one right programming language or even one right type of programming lan
So does everyone else. (Score:5, Interesting)
The most popular suggestion, during the original standards process, was: every time someone proposes a new feature, they have to also propose an existing feature to be removed.
The followup suggestion: every time someone proposes a new feature, they have to donate a kidney. This ensures that proposals will be given serious thought, and that a serious idiot can only propose, at worst, two extensions.
No, I'm not joking. Those were some of the suggestions that received rare unanamous agreement.
Seriously, everyone on the committee, from Stroustrup and Koenig on out, agrees that the language is too complicated. They even said so before it was standardized. But...
Let's hear your suggestions on which stuff should be removed. Remember that no matter what you choose, people somewhere are currently using it, and you will break their code. No matter what you change, it will cause incompatabilities, which future generations of /. will then bitch and moan about.
Also, since compiler vendors don't like pissing off their customers, they can't really completely remove stuff even when the standard says it's okay.
Who cares? (Score:5, Informative)
C++ on the other hand can have all the extra stuff it wants and it doesn't affect my project. If I don't wan to use templates or whatever, I don't have to. And the compiler won't force me to include anything.
Whining about C++ having too many features is like bitching that Baskin Robbins has too many flavors. Nobody is forcing you to buy them.
Ben
Re:remove export (Score:3, Interesting)
EDG are some really smart people, but their comments have since then been disproven.
export in itself (specifically, the idea which export is trying to implement) is a good idea. Where the committee screwed up was mandating its existence without any prior experience.
Keep in mind that the point of an ISO standard is not to require/"legislate" new ideas, but to standardize existing practice. Everything in C++98 had already existed by the time the standard was even close to being done, except export.
Re:learn from Java (Score:3, Insightful)
Lots of good papers there (Score:4, Interesting)
Williams, Stephen, cited by Lois Goldthwaite in her Technical Report on C++ Performance [dkuug.dk]
Compiler Compliance (Score:4, Interesting)
But that's not why I'm posting.
It's nice to read about all the standards processes, and I can appreciate all the great work that these bodies perform. But after the standards are completed, and everyone goes home, it seems to take years for the compiler writers to implement the standards properly.
I'm not trying to slam the poor developers who have to implement the changes. But yet, it seems that the standards bodies don't seem to take acutual usage of the last set of changes into account before proposing the next set of standards.
What I mean is this: Take C++ 97. OK? How many of us have actually used a 100% compliant compiler, and used the latest features? Not too many. I know I haven't. But it seems to me that the language masters want to go ahead and move C++ along without getting real feedback from developers about how useful the language changes are.
It's almost like the big boys are saying "well, it'd be nice to have X, Y, and Z in the language" instead of "you know, everybody hates the way we did A, B, and C back in 97. Lets think about fixing that". The language masters, IMHO are basing the next round of changes on their experiences, not the experiences of the developer community at large.
C++ is already a big complicated language. Maybe the standards process should slow down a bit and give us ordinary developers a few more years to catch up.
SCO (Score:5, Interesting)
MozillaQuest Magazine: C++ appears to be one of the properties that SCO acquired through Novell's acquisition of AT&T's UNIX Systems Laboratories and subsequent purchase of Novell's UNIX interests by SCO. At this time most Linux and/or GNU/Linux distributions include C++ compilers and editors. Is this something for which SCO currently charges? If so, just what are the current arrangements? If not, will C++ licensing and enforcement be added to SCO's licensing and enforcement program?
Blake Stowell: C++ is one of the properties that SCO owns today and we frequently are approached by customers who wish to license C++ from us and we do charge for that. Those arrangements are done on a case-by-case basis with each customer and are not disclosed publicly. C++ licensing is currently part of SCO's SCOsource licensing program.
MozillaQuest Magazine: How about GNU C++? Does GNU C++ use SCO IP? If so, could SCO license and/or charge for use of its IP in GNU C++?
Blake Stowell: I honestly don't know.
Re:SCO owns nothing but C++rap (Score:3, Informative)
More on D (Score:5, Insightful)
One of the stated goals on the
In short, it really *is* time to move to D.
Re:More on D (Score:3, Insightful)
Yeah, we need a java-like syntax so you too can create lots of debug info in programs with 'if (global_debug==1) ' rather than the infinitely more efficient #ifdef DEBUG.
I think some people have problems with practical features of the language - sure, we can make it 'elegant' (like they read somewhere t
Re:More on D (Score:3, Insightful)
I'm pretty sure Java guarantees that if the conditional of an if is known at compile-time (as it would be in this case), then the if will be optimized out of your code. Just like an #ifdef. So, nice straw-man, but the two constructs are equally efficient.
It's great to see some metaprogramming related... (Score:5, Interesting)
Unfortunately metaprogramming is a pain in C++. One of the biggest problems is the lack of reflection in C++ that would allow template metaprograms to easily determine type information. Some of the new proposals would remedy that issue. Also the use of local classes in templates, that is sorely lacking in the current standard, would be a great boon for such techniques.
And maybe one day there will be many more C++ textbooks that don't just relegate templates to half a paragraph in the "advanced techniques" section. Templates are fundamental to C++. If you don't use the benefits of C++ then C++ really isn't that interesting a language. No wonder so many people propose using C rather than C++. It's like programming in Lisp but refusing to use list datastructures.
Re:It's great to see some metaprogramming related. (Score:3, Insightful)
One reason C is so popular today is that it reached a critical threshold in abstraction: it isn't assembly code. C can be learned very quickly, and, given that prior programmers weren't too supidly clever, C-based programs can be easy to learn. I say "stupidly clever" because some people really do try to shoehorn functions into structures (oooo...I make C object-like) or use the preprocessor as if they have to, because it's there.
C, used as inte
Create a C++ platform like Java (Score:3, Interesting)
Fragile Base Class problem (whining follows) (Score:3, Interesting)
I'm tired, so forgive me if i explain this poorly, but C++ has this issue where, since object methods are really just function pointers, if you have class A that is shipped as a library or API, and class B which inherits from class A and is part of some third-party program, and the people who make class A add a private method or private variable to class A and then re-ship their libraries, every existing binary containing class B breaks becuase C++ just slaps a struct containing Bs methods and variables at the end of A, and becuase the size of A has changed the offsets have all changed.
This is horrible. This completely negates the purposes of encapsulization and information hiding, which is the entire reason you'd be writing an OO API in the first place, and leads to anyone attempting to create a C++ API doing horrible workarounds [2f.ru] like sticking a whole bunch of dead space in the form of methods named, for example, "reserved_23" at the end of every class they make, just so that in case later they have to add a method or instance variable they'll have a little bit of room to do so without breaking everyone who's ever inherited from them.
Until they fix this, and until they reach the point where there is some kind of standard String class that everyone uses (as is, there are an untold number of String classes, one for just about every major C++ API, and so from what i've seen people rarely if ever store their strings as anything other than c-strings just because in the end, all they're going to do with their strings is pass them to other c or c++ libraries.. who expect to be given c-strings..), I will continue to consider C++ to be more or less a huge joke that can be used as a high-level oo programming language, but only by coincidence.
Also note that they still are not even considering adding any sort of real reflection into the language, nor are they considering adding a real, robust macro system despite the fact people clearly want one (or else they wouldn't be trying to metaprogram the C++ template system to be a macro system!). It would be nice to be able to typedef a single variable type that acts as a template, though.. that's a good innovation, if i'm reading that right. Anything that minimizes the contact I have with the C++ template system makes me happy. (If it were up to me, they would add ML-like syntax where you can say something like 'typedef myinttype = int | long | IntegerClass | BigInt;' and it would automatically generate the templates for me whenever i used a myinttype in a function.) Of course, considering how long the major compiler makers took to all implement C++ in a standard fashion (the STL doesn't really even seem standard across all the platforms i use, yet), it will probably be a long time before i can safely use any C++0x features
I will, however, support the spread of C++0x, just becuase that will make it the first major language whose name is written in leetspeak.
I like (Score:3, Interesting)
N1428 Dynamic Library Support in C++
Coming from Java (well, I did do a bit of introductory C++), one of the things that really bugs me, is the aesthetic of looking at the soup of classname::function implementation declarations. Class namespaces would clean this up considerably and make things much easier to read and more manageable (Java packages and classes are basically namespaces, and this concept confers very well). I also like the dynamic library support (another thing that is automatic in Java)...the worst thing is having to code native OS-specific macros, extern "C" DECLSPEC(dllexport) BLAH BLAH F'ING BLAH. Dynamic libraries are a ubiquitous concept and support should be built in. Leave it to the compiler to figure out what that actually *means* for a given OS. There is no performance benefit in making a human code this.
Further library standardization would of course help...it really helps to have a standard library (even if it is not the BEST one), since it avoids balkenization, which makes skills truly portable ("C++ developer eh? well do you know how to use the Frobnitz Super Fantastic library? No? Shame."), and programs reusable (by other humans).
C++0x is a Frankenstein Java (Score:4, Interesting)
Unfortunately with Java 1.5, some of C++ is corrupting Java, mainly the completely academic confusing implementation of C++'s templates. Why not go for a more easier to understand concept of templates as implemented by languages such as Haskell?
This will help out companies (Score:4, Interesting)
The company I worked for used to write our software in C++, but moved over to java 3 or 4 years ago for the cross platform abaility of this. There are so many core parts of a program that are system dependent, that supporting 8 different operating systems in C++ is impossible without a standard library of some sorts. Add a standard socket structure will be very nice, and most OSs have very different ways of handling this. Threading is also the other huge issue with crossplatform, there is near zero standard on out threading works in C++.
The one thing that the new C++ proposal is missing is a standard widget/windowing commands. But there is no good way to make standard libraries for something like that, the best if to create a general class to create and control widgets, then write the system specific code for each OS you want it to run on.
It's something I'm looking forward to.
Noooooooo! (Score:5, Insightful)
Re:Noooooooo! (Score:5, Insightful)
If the differece beween C and C++ ..... (Score:3, Funny)
A new version of language or filter-busting spam? (Score:3, Funny)
Cool (Score:5, Interesting)
1) Metafunctions. Like Lisp macros, they allow code-generation at compile time. They're less flexible, because they don't allow access to the AST, but they're much better than the current template-metaprogramming kludge.
2) Lambdas. Even if we don't get true lambdas, with continuations and closures, but I'd like to see some sort of anonymous functions. The STL desperately requires it. Overall, I'd like to see more functional stuff get into the language. Unlike many of the other features discussed, lambdas and higher order functions really need language-level support to work well.
3) Type inference. There is a proposal to allow a new use of the auto keyword like such:
auto x = new int;
The compiler will automatically detect that 'x' should be an int*. I've wanted this feature from the minute I saw stuff like:
int* i = new int;
Its so redundant! I'm surprised that Java (whose simple semantics would make type inference much easier) still makes you do stuff like:
foo i = new foo;
An additional motiviation is that:
vector::iterator i = vec.begin()
can be shortened to:
auto i = vec.begin();
C++ is seriously eating into the horizontal space, thanks to namespaces and nested typedefs and whatnot, and type inference would go a long way in alleviating some of that pain.
The nice thing about these features is they keep with C++'s philosophy. Most of the complexity here is in the compiler --- there is no overhead in the generated code.
C++0x? (Score:3, Funny)
What about existing proposals? (Score:4, Funny)
Rather than just rushing into designing yet more features for the language, shouldn't existing proposals such as This 5-year-old proposal for overloading [att.com] be taken into consideration? :-)
Hmm...0x or 1x? (Score:3, Interesting)
Why? (Score:3, Insightful)
I recently started messing with Squeak [squeak.org] and I think that it is the kind of thing programming language should try to mimic: an easy to use, very dynamic environment. Let's take computing to a new level, leave the 90s behind please.
Re:Whatever. (Score:3, Informative)
Re:Whatever. (Score:5, Insightful)
Straight C is my favorite tool and what I use for embedded programming, quick hacks and performance constrained work. Every time I try to do a large application with it though, I find myself thinking "you know, they already did this exact thing with C++, and I'm going to spend 2 days re-inventing this and testing it".
I use tidbits of Assembly (80x86, MIPS, Arm, PowerPC, what have you) in embedded systems for device driver or performance critical sections. As a HW engineer I tend to use this a lot in bringup of new designs, especially "very new" designs that don't necessarily work and every instruction is important.
I use C++ when I am building a very large, flexible application where I use many types of data structures and need it to get up and running in a short period of time. I like this language for "serious application" programming.
I use Perl to manage my file system, do text processing and other maintenance hacks.
I use Java for simple GUIs that often work as a front end for serious endeavors.
I use TCL/TK for ASIC/FGPA debugging (simulator interface) and test suites.
I use fortran less and less (often I convert to C) for purely numerical computation. Gems of knowledge exist in fortran code for optimized matrix related algorithms that are highly useful in 3D visualization.
I have not found any practical use for Pascal or Lisp lately (the latter is useful for emacs, but I rarely mess with it).
The point of all this is that much like you wouldn't use a screwdriver to drive a nail through wood (unless that was all that was available), you would tend to use whatever tool is best suited to a task. Us engineer types are supposed to be tool-makers and users of the highest order. It surprises me when I hear one of us suggest we should use our favorite tool to the exclusion of all others.
I do not like C++ in terms of the performance and memory impact it infers, but when building large applications I do not have time to re-invent a linked list for the umpteenth time, nor do I want to debug every different link list in my code, there are much harder problems to solve more critical to the success of my project. That said, C++ (and C for that matter) is lacking in some very important things. Among those I think are critical are: multithreading, network stack framework (platform independent that is) and GUI framework (platform independent!). If you read the article, you'll see mention of at least two of those things (we need a standard platform independent GUI library dammit!)
Re:C++0x? (Score:3, Informative)
D Programming Language [digitalmars.com]
Re:C++0x? (Score:3, Funny)
Re:Why C didn't progress to D.. (Score:3, Informative)
Re:Why C didn't progress to D.. (Score:5, Informative)
Uh, no. (Score:5, Insightful)
Everyone but you, friend.
The language C was descended from the language B, which was descended from the language BCPL. Dennis Ritchie never decided whether C followed B because it was alphabetical (in which case C++ would have been D), or whether C followed B because it was the next letter in BCPL (in which case C++ would have been P).
As for the C++0x thing, it's quite common to call languages by the year of their standardization, thus "FORTRAN77", "FORTRAN90", "C89", "C99", "C++98". The next cycle for C++ will be completed sometime in the next seven years, but we don't know exactly which year, so "0x".
Again, uh, no. If it doesn't look "exciting," perhaps you're simply looking at the wrong proposals. Or perhaps you simply still think of C++ as "C with more type checking, and those // comments."
The routine standards adjustment came in the form of "TC1", which was just recently published. Basically, "C++98.0.3p4rc2", to put it in Linux terms. Just bugfixes. C++0x is a different story.
(And I don't know that I'd call Perl 6 particularly innovative, either.)
Re:Stroustrup's Remove Embarrassments (Score:3, Funny)
Re:how the hell do you pronouce that (Score:3, Funny)
Re:C++0x's biggest new feature... (Score:3, Informative)
I don't think it impacts memory footprint much... if you remember to set pointers to null when yo
Re:C++0x's biggest new feature... (Score:3, Informative)
Re:C++0x's biggest new feature... (Score:4, Informative)
1) Creating a smart pointer involves an extra heap allocation to allocate a counter. This is necessary because boost's smart pointers (which are the basis of the standard) are non-intrusive --- they don't require giving the target object a special counter. This overhead, can be eliminated by using intersive_ptr, which allows you to put the counter inside the object itself, and provide functions to increment/decrement it.
2) Copying a smart pointer involves an atomic increment of a counter.
3) Having a smart pointer go out of scope involves an atomic decrement of a counter.
4) When the last smart pointer is destructed, an extra heap free is needed to free the counter.
Re:OOP (Score:3, Insightful)
Java is a great example of a language that forces OOP on programmers. Most universities are starting students on Java because there are a lot fewer ways to get things done in the language.
Re:OOP (Score:4, Insightful)
This is one aspect of Java I appreciated most...
Re:Great... (Score:3, Informative)
Re:Great... (Score:3, Insightful)
Re:Great... (Score:3, Insightful)
Re:What C++ really needs to do (Score:5, Insightful)
The IDEs do also cater to the business community, probably why you don't see more Perl. The fact is "business software" is usually just glue, and Perl/Python/Java/VB/tcl will always be better glue then C++, because they were DESIGNED to be glue and C++ was designed to be the bricks and mortar.
What I would really like to see in C++ would be compile-time exception enforcement ALA Java. I mean Jesus, when you are trying to work with a class library they can't even document what functions may throw what [apache.org], how the hell are you supposed to write robust code? In Java this documentation comes for free when you write the function, and is forced to be correct by the compiler.
Re:~bs (Score:3, Informative)
The hard part is not in taking a compiler and getting it to construct Windows executables. The hard part is getting it to cooperate with the existing ABI well enou