Slashdot Mirror
Latest Proposals for C++0x
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."
And I thought the next version of C would be +++... and then ++++
KappaStone
...make it like grade school and just give the poor bastard a "B". Enough already ;)
How about upping the name to D?
It may be a no-brainer for many of you, but can somebody enlighten me on why the name is C++0x? AFAIK C++ was named as such to indicate it was "more than C" [C++ is C = C+1 for the unlikely few who wouldn't know]. Is this the same kind of nomenclature (0x is zero in Hex), or is it something pronunciation-based ("plusox"?)...
The ENIAC Demo Competition
More changes to the standard so that the compilers can't keep up! Microsoft Visual Studio (6 or .NET) still can't handle templates correctly. For half the stuff I do I have to use gcc or VS shits itself.
I guess gcc will always be what I use.
Someone try to say that ten times fast!
Hate me!
Sounds like the l33t version of C++
The hardest part is deschiphering the comments...
Calling a paper "Directions" is the quickest sure-fire way to ensure that _nobody_ will read it...
Um... C is C(\+)*.
I've had this sig for three days.
would be c+=2, with source files using the .cp2 extension. Can't be any worse than C++0x.
I think "D" is already taken.
My rights don't need management.
What does Alan C++0x think of this?
Trolling is a art,
Everyone knows the history of C, coming from B, which came from A. Sure, an object-oriented version of C might be C++.. but why are we progressing onto C++0x (which reads like 'cocks' to me, anyone else??)? Isn't it time for D? Or is this a marketing/branding thing?
Either way, it doesn't look too exciting judging from these proposals. It's certainly nothing on the scale of Perl 6 compared to Perl 5, so yeah, maybe I've answered my own question. This is just a routine standards adjustment, rather than a real 'development.'
You mean...the successor ISN'T C#?!
I've...I've been living a lie...
Etymology: Latin laconicus Spartan, from Greek lakOnikos; from the Spartan reputation for terseness of speech
Date: 1589
: using or involving the use of a minimum of words : concise to the point of seeming rude or mysterious
"I designed and implemented the C++ programming language." --Bjarne Stroustrup
It get's my vote.
Great, you stick your old ass to plain jane ISO C, I and the rest of the world that has realized the benefits of object-oriented programming will move on to that which is superior.
evil adrian
Honestly, I don't see how this is a big improvement. You have, basically:
//3 pad bytes
// 3 pad bytes, do not use
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?
My journal has hot
Sorry, Bjarne, but your home directory sums up what I think of this proposal.
I mean, we're only just now getting compilers that properly handle the C++ standard from 5 years ago. Why muck things up now?
Just be sure to wear the gold uniform when you beam down -- you know what happens when you wear the red one.
I'm still waiting for the object-oriented business programming language, "ADD 1 TO COBOL".
I think what C and C++ really lack is the option to turn on array range checking. Sure you can drop a couple grand for a purify license or learn to use valgrind, but it should be an easy-to-switch compiler option.
--- Often in error; never in doubt!
So someone, who in no way has mastered his native language, is telling the C++ crowd how to write a language. Unbelieveable!!!
This is what happens when he's happy to see you!
sulli
RTFJ.
You have to imagine some theoretical limit to all the plusses at some point. I can just see it now...
"What language did you write that app with?" "Oh, let's see.. That one was C plus plus, plus plus, plus plus.... plus"
KappaStone
You are an idiot. Try using OO in plain C.
It's possible, but needlessly difficult.
C++ exists for a reason. Don't say it's shit if you haven't had time to delve into it or used it enough to form an opinion based on facts.
The "two week IT people" are not that. More to the point, the 2 week IT people are the ones who spout comments like yours.
c += 2;
In case no one has ever told you, there is a very good saying "right tool for the job". C is very useful language, for (nowadays) fairly limited, albeit important, set of problems. Other C-derivatives are superior to C in many other areas.
I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
I think C++ needs stuff *removed* more than it needs anything added.
(Please browse at -1 to read this comment.)
We got the first c++ compiler to handle the whole language just a little over a year ago. (article) I wonder how many decades it will be until we get a compliant compiler for c++r0x0rz.
Ox: [definition 1] a domestic bovine mammal
Just wait until the free standard comes out: C++Gnu
N1450 03-0033 A Proposal to Add General Purpose Smart Pointers
I've used parts Boost quite alot myself (www.boost.org), and found it very useful even when using Visual Studio.
Williams, Stephen, cited by Lois Goldthwaite in her Technical Report on C++ Performance
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++)++)++ ).
I like paying taxes. With them I buy civilization -- Oliver Wendell Holmes
I think if you are going to put the work into improving C++, do like Java and get rid of the procedural and just make it OOP only. It's just so much more functional, and why not just have newbies start out learning it that way, instead.
> Um... C is C(\+)*.
:-)
yeah, he obviously meant C(\+)+
how the hell do you pronounce C++0x?
c plus plus zero x?
???
there are 3 kinds of people:
* those who can count
* those who can't
What does Stroustrup mean by "remove embarrassments?" I was never embarrassed to admit programming in C. As a matter of fact, back in the day (circa 1988) it was cool to tell people I programmed in K&R C. (This is Kernighan and Ritchie pre-ANSI C for you young'ens.)
--- I'm Green Hornet's sidekick not Inspector Clouseau's!
I haven't read all the proposals, hence my early post, but the subjects look interesting. It'll be cool to see what makes it to the final standard.
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.
Huh?
That name would corrspond to "C+1". "C++" corresponds to "ADD 1 TO COBOL GIVING COBOL".
Patrick Doyle
I mod down every jackass who puts his moderation policy in his sig. Oh, wait a sec....
Actually, a continuation of the patern C, C++ is C+=2. Perhaps that was already taken. Does C++0x rhyme with detox?
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.
Reports show that the reason for the groups lengthy debates was the argument over the syntax of the programming language's name itself.
I found the meaning of life the other day, but I had write-only access.
Oops broken link, try this:
% 24 qd3.1247%40tornadotest1.news.pas.earthlink.net&oe= UTF-8&output=gplain
http://groups.google.com/groups?selm=EK8Ea.1338
With the C++Ox or thay are just adding more gobbledegook. Take this from the link:
Controling Implicit Template Instantiation
Piling abstraction on abstraction. The language is more complex than the logic it is trying to implement.
Could C++ be tightened up? Why not tackle that age old bugaboo the "dangling else". Why not take this opportunity to require curly braces around all if/else constructs? There are many small fixes like this which would make C++ a tighter, more robust language.
(This is a joke, for the sarcasm impaired.)
.CPP0X? Sounds like "Seep Pox", a new virus caused by inadequate plumbing infrastructure.
Then will C++0x be
Buffer overflow exploits, anybody?
<sig>Mr. Kaze</sig>
I know talking about D is already redundant on this article, but I'd like to anyway. Improving c++ is great, but where c++ *really* needs improvements is the syntax. It's time for c++ to move into the 90s and get rid of the preprocessor. It's unnecessary with modern compilers, and it's a pain in the ass.
.pdf file linked is to make c++ easier to learn, but many of the syntactic kludges in c++ (like the preprocessor and the differences between a pointer and a reference) confuse the hell out of newbies. It's time to adopt a syntax more like Java while retaining the power of native compilation and library creation that c++ gives.
One of the stated goals on the
In short, it really *is* time to move to D.
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
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.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
Now THAT would be an awesome name. (@w350|\/|3?)
[SIG] It's like putting a moose in the blender -- a recipe for disaster!
dude, the ^ operator is for XOR, not X^Y
How many compilers fully implement the current C++ standard properly? Remind me? It isn't ZERO is it?
Now is not the time for a new standard.
Leave it as it is, in 5 years only the crazy few will be using it anyway. C++ will never become as standard as C, so making the standard book thicker is a moot point.
I think comments like this are often incorrectly moderated as "Flamebait". The poster makes a good point about practicality, but, at least for myself, practicality isn't enough to keep me happy and motivated. Programming is a craft; a craft involves developing and applying a collection of related and sometimes un-related skills. Craft also involves elegance. Having said all that, certainly one is able to solve many problems in C as in C++. In fact, one could probably argue that any problem solvable in C++ can also be solved in C. The difference is elegance... I think C++ makes it easier to write code that expresses the design aspect of a program without compromising the implementation; thus, well written C++ programs may be more maintainable/understable than well written C programs. Further, the biggest improvements I've made in my own programming ability has been to improve the way I do things I already know how to do; I believe that kind of behaviour has been of more benefit to me in some ways than learning how to do new things. In this sense, C++ is, as advertised, a "better C".
The maintainence of the economic order requires the consumers to consume. If your product lasts forever there is an upper consumer threshold after which you can close your shop and go home: you will never make a profitable sale again.
With material goods it is only a matter of varying the quality. A car will eventually break for good, a house will fall apart. In the case of digital products, the obsolescence must be forced upon consumers by other means: new features, new standards, refusal to correct bugs (as in Windows 95 and bellow, Oracle 8x and bellow etc).
The point is, why would you buy another compiler if the language stays the same forever and all bells and whistles are already there?
One big advantage of Java is that it is a platform, not just a language. You don't have to reinvent the wheel for basic things like threading that modern systems do. In the pdf linked from the article Stroustrup proposes filling out the standard library in ways that Java already does, and think this is a good thing. STL was a start in that direction, but every C++ system I come accross seems to do threading and many other common operation over again (pwlib used in openh323 for example). I'm glad to see the C++ world recognize this type of developer need.
Just wait another 10 years for the gcc team to implement it, and break binary compatibillity *again*! when will they learn?
-1, troll^H^H^Hue.
I am just waiting for a Object-Desoriented language...
C++0x is not a bad name, they could've called C++::ver++
Mod parent up, people need to know BS is dead and this is just a hoax!
How can SCO own the language? I can see them owning an implementation of the compliler and libraries but the actual language? Come on, that doesn't compute, especially since it has been ANSI standardized.
--- I'm Green Hornet's sidekick not Inspector Clouseau's!
I can understand where you're coming from. C++ is a complex beast. I've been using some form of C++ for over 10 years (well before it was standardised) and I still don't understand everything about it.
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.
The ratio of people to cake is too big
If they can do this right, I'll be very happy. After all, Java's main advantage over C++ is their abstracting away pointers. Course Java is still slow, and that pointer abstraction is expensive, in terms of garbage collection, program speed, and (most important) huge memory footprint. C++ pointers are a major PITA, but they are fast 'n cheap. How fast 'n cheap are smart pointers?????
Practice Kind Randomness and Beautiful Acts of Nonsense.
"cee plus plus ox?"
"cox?"
"kooks?"
The link is from att research and it point to the home page of M. Stroustrup (http://www.research.att.com/~bs/). I think it's safe to assume this is not a hoax.
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.)
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Visual Studio.NET 2003 works fine with any sort of template madness you throw at it: Partial template specialization, etc. Except for export, which is supposedly extremely difficult to implement.
I think C++ is quite useful, and I'm not a "2 week IT person", not that I think they are necessarily inferior beings. On another note, most IT people I know tend to make the most use of Perl/Ruby/Python since it solves most of their problems quickest.
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!)
I think what C and C++ really lack is the option to turn on array range checking.
How do C and C++, as languages, lack this? You're talking about specific implementations of the languages, not the languages themselves. When you read or write outside of array bounds, the language standards say in no uncertain terms that the behavior is undefined. That means that anything (and everything) can happen. Permissible undefined behavior includes printing an error message such as "Attempt to write outside of array bounds at line 427 of foo.c."
There is nothing in the language standards that prevent runtime array bounds checking. The reason why you don't see many implementations doing it is the performance hit, which works against one of the biggest selling points of C and C++ (speed.) And, as you say, there already exist tools with which you can diagnose runtime memory problems.
We're going down, in a spiral to the ground
Let's hope nobody is still using this language and nomenclature in the 2100's. They'll be dreadfully flummoxed when their own C++0x standard gets confused with one that is a century older. Then again, this, like the Y2K bug, is a good way to drum up business for our greatgrandkids and strengthen our technocracy. Muahahahahah!!!
It's now official. C++ creator admits it was all a hoax! Read on for the details of the stunning scoop...
On the 1st of January, 2003, Bjarne Stroustrup gave an interview to the IEEE's 'Computer' magazine.
Naturally, the editors thought he would be giving a retrospective view of twelve years of object-oriented design, using the language he created.
By the end of the interview, the interviewer got more than he had bargained for and, subsequently, the editor decided to suppress its contents, 'for the good of the industry' but, as with many of these things, there was a leak.
Here is a complete transcript of what was was said, unedited, and unrehearsed, so it isn't as neat as planned interviews.
Interviewer: Well, it's been a few years since you changed the world of software design, how does it feel, looking back?
Stroustrup: Actually, I was thinking about those days, just before you arrived. Do you remember? Everyone was writing 'C' and, the trouble was, they were pretty damn good at it. Universities got pretty good at teaching it, too. They were turning out competent - I stress the word 'competent' - graduates at a phenomenal rate. That's what caused the problem.
Interviewer: Problem?
Stroustrup: Yes, problem. Remember when everyone wrote Cobol?
Interviewer: Of course, I did too
Stroustrup: Well, in the beginning, these guys were like demi-gods. Their salaries were high, and they were treated like royalty.
Interviewer: Those were the days, eh?
Stroustrup: Right. So what happened? IBM got sick of it, and invested millions in training programmers, till they were a dime a dozen.
Interviewer: That's why I got out. Salaries dropped within a year, to the point where being a journalist actually paid better.
Stroustrup: Exactly. Well, the same happened with 'C' programmers.
Interviewer: I see, but what's the point?
Stroustrup: Well, one day, when I was sitting in my office, I thought of this little scheme, which would redress the balance a little. I thought 'I wonder what would happen, if there were a language so complicated, so difficult to learn, that nobody would ever be able to swamp the market with programmers? Actually, I got some of the ideas from X10, you know, X windows. That was such a bitch of a graphics system, that it only just ran on those Sun 3/60 things. They had all the ingredients for what I wanted. A really ridiculously complex syntax, obscure functions, and pseudo-OO structure. Even now, nobody writes raw X-windows code. Motif is the only way to go if you want to retain your sanity.
Interviewer: You're kidding...?
Stroustrup: Not a bit of it. In fact, there was another problem. Unix was written in 'C', which meant that any 'C' programmer could very easily become a systems programmer. Remember what a mainframe systems programmer used to earn?
Interviewer: You bet I do, that's what I used to do.
Stroustrup: OK, so this new language had to divorce itself from Unix, by hiding all the system calls that bound the two together so nicely. This would enable guys who only knew about DOS to earn a decent living too.
Interviewer: I don't believe you said that...
Stroustrup: Well, it's been long enough, now, and I believe most people have figured out for themselves that C++ is a waste of time but, I must say, it's taken them a lot longer than I thought it would.
Interviewer: So how exactly did you do it?
Stroustrup: It was only supposed to be a joke, I never thought people would take the book seriously. Anyone with half a brain can see that object-oriented programming is counter-intuitive, illogical and inefficient.
Interviewer: What?
Stroustrup: And as for 're-useable code' - when did you ever hear of a company re-using its code?
Interviewer: Well, never, actually, but...
Stroustrup: There you are then. Mind you, a few tried, in the early days.
So, are they ever going to do anything about the Fragile Base Class problem? I don't see anything related in those proposals.
:P
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 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.
Irritable, left-wing and possibly humorous bumper stickers and t-shirts
But when you submit a story, post a story, etc. Can you guys please alert folks about plug-in content. I hate ACROBAT.
I've wanted this feature for many years, but mostly in the context of structs and unions.
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 #define to simulate the old naming).
N1420 Class Namespaces
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).
It's 10 PM. Do you know if you're un-American?
After working on the internals of the Std C++ library for several years I can honestly say that C++ is the biggest mess ever. The ANSI C++ committee is now trying to patch the language into a frankenstein version of Java.
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?
Reports of my death have been greatly exaggerated.
- Stephen King
In other news, SCO owns the Solaris extension known as Java, since it clearly is an extension to the Unix System V Operating System, having been incorporated there first.
c += 2; ? = c + 2
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.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
everyone knows that JavaScript is where its at.
I do all my cluster number crunching in JavaScript.
pure speed baby
There are some odd things afoot now, in the Villa Straylight.
If this standard does go through, aht GNU supports it via gcc or what have you, this will help companies in a big way.
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.
Its not what it is, its something else.
Obviously this is named after the long tradition in C and C++ of null pointer dereferencing. No C or C++ program is complete without it. The version after this one will be called C++BUFFEROVERFLOWWWWWWWWWWWWWWWWWWWWWWWWWWWWW...
> I and the rest of the world that has realized the benefits of object-oriented programming will move on to that which is superior.
You're talking about Objective-C, right?
In practice, C++ is finally getting to the point where various compilers accept the same code. That after 15 years or so. Now they want to shake it up again?
Phonetically, Isoiec-Jetsee-Wonsc-Tutu-Wig-Tuwan sounds like a Jedi name. Or a droid. Maybe a Jedi droid. Artoo's brother.
...try to say it once.
is that with C++ it's harder to shoot yourself in the foot, but when you do you end up blowing your whole leg off... With C++0x will it be nearly impossible, but when it does happen you end up blowing up the whole city?
Technoli
Not a Troll.
I'll ignore the mass of amazingly redundant and unfunny comments made about "C++0x."
The PDF file shows that they're committed to killing some of the idiosyncrasies of the language. I could list a lot of them, but here are a few that stick out at this moment in time.
What would be most beneficial is if the . operator worked in the same context the arrow operator did. It is a pain to have to convert every usage of it over if you switch a reference to a pointer. The arrow operator could just be a deprecated operator for C compatibility.
Also, references seem to be ill conceived. The worst part is they can't be stored in STL structures because there is (currently) no such thing as a double reference. References should only be allowed in function argument lists.
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, 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.
apt-get install redhat please god - Me (take it easy, I love Debian)
Hello Gentlemen,
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
Overall goals
Make C++ a better language for systems
programming and library building
- Rather than providing specialized facilities for a particular sub-community
(e.g. numeric computation or Windows application development)
Make C++ easier to teach and learn
I see exactly what they need to do in order to accomplish their objectives: make C++ into Java.
Okay, well, maybe that's more like C-=0.5, but it's still sorta cool.
I have yet to see this mentioned (which surprised me)
http://www.digitalmars.com/d/
so then what does C++ + ObjectiveC=?
a big mess that still does not compare to Java..
Don't Tread on OpenSource
T33N 8abes ready for your h0t C++0x !!!
======================================
Writers get in shape by pumping irony.
I do not like C++ in terms of the performance and memory impact it infers
You have only yourself to be mad at. You are responsible for the performance and memory impact. Compiling C code in C++ doesn't hurt a thing.
C++ lets you choose whether you want to pay the cost of a feature or make do without it. Don't want virtual function table overhead? Don't mark anything virtual! Don't want RTTI? Don't enable it!
IMO this is far superior to many other languages forcing these choices on you.
It's called Objective-C
Yuck! Back to the future, we find ourselves chasing stale object graphs, like in COM. Or have they somehow made them safer? Refcounting was a Microsoft innovation I clearly could have done without.
If C++==D then the next gen should be E. Actually, if we count pre and post ISO standards, we've moved on to F, which is a fine letter, imho. F, of course will add the exponentiation operator **, so we can compute F**k. ;-)
So long, and thanks for all the Phish
Any girl like sex there? I need girl like sex!
...My guess would be that the good programming langage wouldn't be the one with no safe net (C++) or the one with safe nets that cripple the performance (C#), but the one where you can choose the degree of safety you need, and can play with it at will.
..." (emphasis mine)
So... that would be what... c++ in the hands of an experienced programmer then?
j/k
Really though, as Stroustrup states in ch. 2 of his The C++ Programming Language book,
"C++ is a general-purpose programming language with a bias towards systems programming
So it might not be the tool you're looking for it to be. But for it's intended purpose, serves quite well.
It doesnt make much sense that Rambus could patent some technologies in RDRAM, considering it was a standard and all... /sarcasm
-Bucky
Modern C++ really is a cool language. Its hardly clean, and its a big beast to learn, but (IMHO) it allows a great deal of abstraction without sacrificing much (if any) performance. Personally, I'd like to see the following features in C++ 0x.
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.
A deep unwavering belief is a sure sign you're missing something...
"We don't know what it will be, but i'm sure we'll find ways to make it more....umm...programish
Yeah, metaprogramming makes C++ an ugly Lisp. Keep in mind that Lisp code is generally regarded to be very ugly.
I'll put my flame suit on now. I just insulted both C++ and Lisp.
The middle mind speaks!
Hmm... cluster number crunching in JavaScript... are you the author of the prime number shitting bear!?!?
how about a much cuter name, like "Snugglums" or "Bwumpie-poo"?
"I would say that 99 per cent of what my father has written about his own life is false." - L. Ron Hubbard Jr.
I do not have time to re-invent a linked list for the umpteenth time
This may be naive, but couldn't you just cut and paste your previously used linked list. It seems to me that the one thing that C++ in particular and OO in general has sacrifices is simplicity. In OO to create a linked list you define a class which inherits from another class (which inherits from another class??), then you create the object. That is a lot of code. It becomes quite hard to understand what is going on when you do have a problem.If you just pasted in your previous linked list code, you will have a simpler program. As I said, the one thing that is ignored is simplicity.
> B actually existed... it was the language that predated C.
//
w ww.wikipedia.org/wiki/CPL
>
> I've no idea if there was an A though.
There was no A, but B was actually derived from BCPL. BCPL was interesting in that it included two features not found in C:
* Single line comments that begin with
* The ability to create expressions with statements in them (sort of like inlining or closure expressions)
* All variables had "word"-size (a la FORTH) so you didn't need to declare types.
C++ adopted "// comments" so maybe C++ v2.0 will adopt closure BCPL closure expressions;-)
You can find out more about BCPL here:
http://www.lysator.liu.se/c/clive-on-bcpl.html
Anyway BCPL (Basic CPL) was a simplification of CPL which was called "Combined Programming Language".
http://www.wikipedia.org/wiki/Talk:CPL
http://
CPL was derived from Algol.
So in essense, C++ could be renamed:
Algol++++++++++
You are simply fabulous. Love the shoes!
most compilers worth their salt will eleminate the temporary local variables for code like this at compile time. It's a technique called return value optimization.
- Houdini
C# is already a very cleaned up version of C++. If you turn off garbage collection, add C++-style new and delete keywords, some modern templating syntax, and a compiler, you get the next version of C++.
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 be taken into consideration? :-)
Actually, from FORTRAN 90 onward, pointers (somewhat restricted compared to C, but still) as well as dynamic memory allocation are part of the language. Making FORTRAN as slow as C.. :-)
Anyway, I don't think the difference between C and fortran is so big anymore. Compiler tech has improved, and in fact most fortran compilers have identical backends with the C/C++ compiler from the same manufacturer.
No insult! Template metaprogramming is ugly as hell. But it does get the job done well sometimes. An alternative language might be something like Haskell which I think looks pretty beautiful. But outside of contrived benchmarks its performance seems to suck.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
Here's some more info on CPL:? CPLo lume_ 06/Issue_02/default.html
http://www.instantweb.com/foldoc/foldoc.cgi
http://www3.oup.co.uk/computer_journal/hdb/V
(Look for the "The main features of CPL" text.)
Apparently ML is also derived from CPL too so ML and C++ are distant cousins.
In related news...
SCO announced earlier this morning that they obtained all rights to the English language from England for an undisclosed amount and plan develop a "reasonable and non-discrimatory" license plan for individuals wishing to communicate using the language. A SCO spokesperson recently told reporters: "We're not after the individual English speakers, so there's no need to worry. It has come to our attention that IBM intentionally placed some English words into the open-source Jive language and is in clear breach of our license with them, forcing us to take them to court for... (cue music and camera zoom-in) One Meelion Dollars."
Although details are not yet finalized, SCO promises that the royalty for using the English language will be affordable, "something in the ballpark of 3 to 4 cents per word communicated." In that scenario, this news story would cost us several dollars, which is quite cheap and reasonable in this news agency's opinion. More at 11.
I wish they'd give programming languages and other software unique and easy-to-search names. C++ doesn't search well in some search engines. C is even worse, since it's so generic and short. Add to that software with names like Word and Access.
It makes a difference when it comes time to search on a feature or problem.
Unfortunately the "check it out" link is slash dotted... What I'd like added to the C++ language would be the ability to dynamically iterate through the inheritance structure of an object using type_info structures at runtime. For example, you have an inheritance structure where: A inherits from B inherits from C inherits from D. I get an A* as an argument. Right now, I can call typeid and find out is actually a D*. If I know about class B, I can dynamic_cast it as B. However, my code doesn't know about class C (let's say I'm a DLL or something), I can't really find about class C. It should also handle cases of multiple inheritance. There was a real-world case where I needed this. Sure, if the system had been properly designed in the first place I wouldn't have needed it, but I had to fix something and it would have been easier if I could have dynamically asked for a list of the type_info structures that the class with some type_info structure inherited from. The case was that I was dispatching some objects to handlers that had registered for objects by their type_info structure. In my stupidly named ficticious example above, if you register for class C and nobody else registered for D, you would get any D's that are dispatched. My code treated all these classes as anonymous and only knew about A. I kept a std::map around for doing the dispatches. I solved it non-elegantly by requiring that any class derived from A call a base class method called SaveTypeInfo in all versions of their constructors. SaveTypeInfo did somehting like: mTypeStack.push(&typeid(self)); where mTypeStack is a std::stack in the base class A. What that results in is a stack of type_info*s poiting to: D C B A (bottom of stack) Then I would compare the top of the stack to the map, if it exists in the map, dispatch it, if it doesn't then pop it off and try again until the stack is empty.
Avoid Missing Ball for High Score
I haven't played with FORTRAN recently myself but there are figures and discussion published by Todd Veldhuizen that are certainly a lot more recent than '90.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
Can I be considered an old-timer for remembering when Fortran 90 was still the Fortran 8X proposal?
"Rub her feet." -- L.L.
I recently started messing with Squeak 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.
Closures.
Going with the analogy of glue vs bricks and mortar, I'd like to point out some obvious problems with C++, from the point of view of someone who works more on the "glue" side.
When I write a program in VB, there are precisely two ways that I can mess things up from the point of view of causing an application crash. One is to create circular references between objects, and the other is to cause a stack overflow. I know enough to avoid those two problems, but my programs still crash sometimes, because of the brick & mortar that my program relies on.
I don't blame MS for that, I blame the languages they use, i.e. C and C++. What C++ needs is better protection from programmers against themselves. Buffer overflows, pointers pointing where they should not; all that stuff needs to be harder to do. Give us guys with the sticky-glue fingers something decent to work with!
MS have it right with C#, i.e. no more pointers, no possibility of circular references. Unfortunately, the cost of that seems to be the runtime framework to do GC, which would be unacceptable for low-level stuff in C++.
Oh well. I forgot my point. Anyone?
Most writers regard truth as their most valuable possession, and therefore are most economical in its use - Mark Twain
The most interesting discussion on the comments list was the material on removing export. I had always thought export was a good idea and the comments from EDG completely changed my mind.
assert(index < size);
I don't see what the issue is there really. I imagine it implemented as follows:
virtual union {
int i;
float j;
} k;
Where i === k.i, j === k.j in the current namespace and scope.
If i is ambigous because an int i already exists outside the union in a similar scope, the behavior is to favor the "inner" scope provided by the union.
Similarly, we can have:
struct outer_t {
int member;
virtual struct inner_t {
int member;
int data;
} inner;
} outer;
Where outer.member === outer.inner.member (there is no seperate memory allocated for names that collide). However, inner_t structs can be seperately allocated, and for example:
inner_t x = outer.inner;
is a valid statement doing exactly what you expect.
Black holes are where the Matrix raised SIGFPE
How about we rename it C=*((long *)0)?
Or does C++ have too many pointer problems already?
C++ needs ACE like dogs need submarines.
Can ACE possibly be any more complicated than it is?
The ACE developers should really look at Qt/KDE to see how to design intuitive C++ APIs.
Boost has the right idea, but I fear they are heading down the ACE path of needless complexity.
Wouldn't "C+=2" be a more appropriate name?
What about OCaml ? (See the last item in "news" for a "benchmark")
But some people tend to faint when you tell them you coded a DB front end application in VB, and tell you how C++ is superior. All I'm saying is that if C++ wants to be the end-all-be-all of programmation, it seriously lacks in that department. If you stick to real time programming, C++ seems very good indeed.
I work in Europe. Delphi is far more widely used here, because it's taught in several universities. "because they were DESIGNED to be glue and C++ was designed to be the bricks and mortar." Can I translate that as : businesses don't need/want to reinvent the wheel every time they have a problem to solve ? :) I know once you have a good code base in the house it's not so bad, but most small or middle sized businesses most likely won't ever have the time to get that.
Tried that too as I was initially impressed with those benchmarks. I found the performance really started dropping when I started using more complex datastructures. Still, I might consider OCaml in some situations.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
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++.
"...in C", I would have said, since in order for the original joke to work, it has to be interpreted in plain C syntax.
But anyway, you bring up a good point: C++ should really have been called "++C" all along, since the expression "C++" increments C (as intended) but returns the old value, not the new incremented value, but you'd want the expression to evaluate to the new language.
Also, my language-laywering is a bit rusty, but if the pre-increment operator yields an lvalue as you claim, doesn't that mean that "++++C" should be valid? If so, why does it give me an error "invalid lvalue in increment"? Note: "invalid lvalue", not "not an lvalue" -- are there different kinds of lvalues, or something?
David Gould
main(i){putchar(340056100>>(i-1)*5&31|!!(i<6)<< 6)&&main(++i);}
One thing that has always bugged me about C++ is that when they added object-oriented features, they also threw in a bunch of other useful stuff that has nothing to do with OO.
Wouldn't it make sense to put out both a new C and C++ standard at the same time, where C contains everything from C++ that isn't object-related?
Actually, that's not legal C++. You can't modify c twice without an intervening sequence point. (No, that isn't a pun.)
Geez... wake up!
Clearly, C++ has many features for libraries, and these support what I think of as infrastructure/middleware kinds of applications. Just link your code to a C++ library and access all sorts of other features. It may or may not do a good job of this, but it is clearly part of the charter of the language.
The real issue is if C++ is a systems programming language: is it actually used for classical system programming tasks? I think not. Let me give examples:
1. Language implementation. Are any languages actually implemented in C++? For all the open source software I have seen, C is the language used for almost all language implementations. Unless there has been some big change GCC is written in C, I think. Is VC++ or the Intel C++ compiler written in C++? Is this a historical issue, or is there some reason that language implementers stick to C? For a counter example, there are many LISP systems written in LISP using meta-circular implementations.
2. Operating systems. I know of no operating systems written in C++, and I doubt that it is possible. C++ assumes a lot of support exists for memory management and tasks like interrupt handling. When you are in this domain, you have to be very strict about memory allocation and deallocation, and C++ often implicitly creates objects on the fly. You would have to code in a very non C++ style to keep from constantly going into and out of storage allocation.
3. Real time and embedded programming. All the problems of operating systems along with code bloat and possible speed problems due to method overhead.
Does anyone have counter examples? Are there other typical systems areas where C++ is not the right choice? I'm not trying to start a flame war, I really want to get intelligent meaningful feedback.
Stardard C is
still a decent language. What gives the language its power is the Stanard
C Library. Rather than focus on improving the language itself, which I
think does not need to be done, why not focus on improving the standard
library interfaces for cross platform portability. I write everything in
standard C, sometimes going into C++, and I use C++ compilers to compile
my code. I find myself having to write or rewrite common code just to get
common functions to work. I'm not on any committees steering the
direction of these languages, but I know that if you would recommend
serious improvements to the fundamental API itself, the language would in
turn be a better language directly because of it. For example, there
exists no regular expression (i.e. PCRE) API functions in the standard C
library. There should be. It should have been in there 10 years ago. It
sucks that millions of people have to reinvent the wheel every day because
the standard library is inefficient for common programming tasks..
The D Programming Language is the successor to C++.
Last time I worked in ATT I've met Mr. Stroustrup there. If ATT owes Stroustrup (does he work there or not?) and he owes C++ (is he the inventor of C++ or not?) *and* the ownership relation is transitive (this part could be more difficult to agree) then ATT owes C++. Sort of.
Less is more !
If you're looking for a straight update of C++ ability and syntax, why not check out D developed by digital mars. It's based off of C++ compiler designs.
http://www.digitalmars.com/d/
are horribly inefficient, and just plain wrong. I hope they don't make it into the standard.
Try the Boost Lambda library. It's hardly perfect, but it works well for most purposes.
Java is a joke for static applications for the following reasons:
1) Lack of templates. This makes the code an unreadable mess of casting. Not to mention that every cast in Java is a dynamic cast.
2) Lack of stack-allocated objects. Everything, even the smallest integer, must be allocated on the heap. Which means memory is too easily fragmented.
3) The garbage collection moves memory around. That means that a Java pointer is a triple pointer: a variable which points to a variable which points to the object. Then, the garbage collector knows the middle pointer and can change its contents as needed by moving the object around. Twice as slow as C++.
4) Garbage collection does not help the memory management problem. If I forget to nullify a pointer, the object remains in memory forever.
5) A static app does not need a VM. It slows things down. Why should my code be translated on the fly, since a compiler would know beforehand what my program does ?
Java has the following advantages:
1) it runs everywhere.
2) it provides a rich set of classes for every need. Especially gui.
Now that I bashed Java and got it off my chest (I make applications with Java/C++ for a living), let's get off to C++. I love C++, especially for the template metaprogramming that it has, but it has some serious problems:
1) the operator = is transferrable to a class/struct's members. Why not about the other operators ? For example the + operator. That way I could add two structs by using the operator + without having a temporary object to store the result.
2) The lack of defining own operators
3) Having to declare everything explicitely. For example x = 3 should be enough
4) Having to declare two versions of each method, one when the object is const and one when the object is not const
5) Having to put a semicolon after a class or struct declarations (as if the curly brackets were not enough)
6) Having to declare forward stuff
7) Having separation of header files and implementation files. This is the biggest language problem. It makes development problematic, since every change of the API requires two modifications.
8) Lack of a standard String class
9) I can't overload the operator '.'
10) It does not have properties. A simple alias to get_x/set_x would be the x =, int i = x. It's only syntactic sugar, but it matters.
11) lack of delegates, signals and slots
12) lack of reflection
13) unsafe variable argument list mechanism
14) lack of threads
There are many more things that are problematic, but I don't remember all right now (in one point in time I had constructed a list with 68 things that irritate me about C++). Although the language has the problems mentioned above, they can be overcomed by various techniques, and they are not as serious as the Java ones.
The biggest problem is that it lacks standard libraries. A good language would come with standard gui, database, io, xml, collections, threads, internationalisation, etc. From all this, C++ has only collections. Mr Stroustrup correctly identifies the lack of threads, but what about the gui ?
Being a novice programmer and CIS student that has been writing small script-like task-automation programs, I think better pattern-matching support for C++ is a big step.
Das ist nicht lustig! Und dann was sollten wir über englische Wörter in Linux tun?
Good people do not need laws to tell them to act responsibly, while bad people will find a way around the laws-Plato
The C++ standards committee does not want to get involved with operating system issues, nor do they want to impose a standard object file linking convention for various vendors' C++ compilers. I don't agree with this. C++ is forever doomed to be a statically compiled language with poor compilation speed if they do not mandate standard object file and shared library formats and conventions. The C++ ABI standardization is a good start - but it does not go far enough. And no, a template repository is not a solution - it's a band-aid covering this underlying problem of brittle classes and the need to recompile everything under the sun everytime a fundamental class' structure is changed. The .o (or .obj) files ought to store much higher level information about templates, classes, dependencies and typedefs. I know a number of projects that have switched to Java solely due to the poor C++ compilation speed issue. It is not unusual for a complete rebuild of a C++ system to take several hours. Don't believe me? Build Qt on typical two-year old hardware. This is not acceptable. Even the largest Java projects typically take under 10 minutes to build from scratch. Say what you will about Java, but they got it right when it came to creating a standard object file format (the .class file). A third party Java analysis tools industry was born overnight to take advantage of this common object format. As far as I'm concerned, the more standardization between various C++ compilers on different platforms - the better it will be for all C++ programmers.
Modern C++ Design actually does a good job describing some of the more sophisticated metaprogramming work you can do with C++. It actually demonstrates that you can determine a lot of type information when metaprogramming thanks to C++ template semantics. Really cool stuff.
;-)
Of course it does look ugly as hell.
sigs are a waste of space
Can we please have a preferences option to filter out anything that's been moderated as funny?
I mean, it's nice every now and then but practically every single frickin post on this story is a "+X Funny". Anyone who actually has anything to say about the proposals is drowned in a sea of jokes about increment operators. And let's face it THERE'S ONLY SO MANY JOKES YOU CAN HEAR ABOUT INCREMENT OPERATORS.
:wq
No wonder so many people propose using C rather than C++.
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 intended (structures and functions that use structures), is actually quite refreshing to program in. You know, even Motif (a C library) isn't all that bad, as long as it is used directly without resorting to compulsive-big-clever-framework-because-I'm so-smart-syndrome.
If you haven't caught on, I don't care for programmers who are so caught up in their genius that they invent these beasts of programs just to make them feel like they are architecting a space station or something. Usually, these are people just out of college, or "experienced" folk too stubborn to see their outside of their fantasy micro-universe. People need to realize that other people have to work with that code, too!
Healthcare article at Kuro5hin
The Cyclone project over at Cornell is the best thing I've seen in the C family of languages. It ought to be the next standard.
Postfix ++ returns the value before incrementing it, so it's almost like C++'s name itself is mocking it: Grown up, but too little, too late.
And what would "cout << f (b, c)" do then?
The extra bloat in Visual Basic is forced into my projects wether I use it or not.
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
Work Safe Porn
Modern C++ Design actually does a good job describing some of the more sophisticated metaprogramming work you can do with C++. It actually demonstrates that you can determine a lot of type information when metaprogramming thanks to C++ template semantics. Really cool stuff.
;-)
Of course it does look ugly as hell.
sigs are a waste of space
See, the problem here is this.
// Java doesn't trust me
I'm a programmer, I want to write code, and I'm going to use a tool that lets me write code the way I want to write it, not a tool that tells me I'm too stupid to write good code, so it's going to force me to jump through hoops.
Take, for instance, this particular annoyance in Java:
I am trying to read from STDIN, wait, Java calls that System.in (everyone else in the universe seems to be able to agree on this one...) -- Specifically, I need something with a readLine() function, so I have to construct something around System.in.
So, first, this annoys me greatly, because there is a certain amount of overhead in continually constructing new objects from old ones... In C I could just call a different function and pass it my FILE* pointer. I can (and generally will) do this in C++ as well...
So... anyway, I do something like this (which comes from the Java API Docs)
BufferedReader br = new BufferedReader(new InputStreamReader(System.in));
two constructions... oh goody...
So... anyway, now I readLine()
Now... I have to do this (like about 99% of all my lines of code) within a try/catch block, because it _might_ throw an IOException.
well... it might, except that the source is System.in so it won't. If it runs out of data, it'll sit and wait until I type something
(unless, of course, System.in is set to some file, but then my particular program (a chatbot AI) is not really very meaningful.)
But Java thinks I'm too stupid to know what I'm doing, so I can't call readLine(), I have to do this
try
{
myNextLine = br.readLine();
}
catch (IOException ioe)
{
}
this has turned one very simple line of code into 7, and don't tell me that I can save space by moving the brackets, I can save even more my not putting \n's anywhere, but sometimes it makes code more readable
so... yeah... when I'm forced to use Java, I hate it... I keep thinking 'wow... this could be done 5 times faster with half the code in C++ and it'd be more legible to boot!'. I don't want to be protected from myself... If your not capable of enforcing reasonable restrictions on yourself, or your organization is too lazy to do real code-reviews, then your code deserves to suck it up...
So... yeah... that's the second half of my "I hate Java" rant... perhaps someday I'll give y'all the first half.
Until then,
-- Fareq
You know how I optimize my car repair projects? If I'm not using a tool that day, I throw the tool away so I don't get confuzed. Besides, who needs a hammer? I use the fat end of the screwdriver because the screwdriver has a much better interface. And I save a ton of time because I don't have to think "Hammer? Screwdriver? Wrench?" I just grab the screwdriver and I'm wrenching and hamming in seconds.
-pyrrho
SCO today proudly announced that the version following C++0x will be SC++0x
Chris Sonnatag and Darl McPride said in an interview to cnet.com.news.com.com.com:
"We own the C++ language. We can get more royalties and licensing fees after renaming it and charging for every use of the name."
One thing that was good in the original Ada standard was that pre-processors were not allowed. Nonetheless, several big shops wrote preprocessors to standardize their code and implement extensions.
I would like it if C++0x defined a nice way to add on object orientated external libraries. Maybe like COM. Maybe then C++ would finally start building a big warehouse of libraries like Perl has in CPAN. The committee shouldn't be writing specific libraries -- only as examples.
If you take a look at many APIs built using template metaprogramming you'll find that the primary goal in almost every case is to present an intuitive interface for the end user. Check out Blitz++. It's horrible inside. But the end user gets to write code that looks like familiar mathematical notation.
However, aside from metaprogramming I agree with your "architecting a space station" comments. People like to build these gigantic hierarchies. The strategy often fails because the goal is to cover ever conceivable situation. Invariably the programmer fails and you're left with an even more complex morass that needs to be fixed to work in your situation. But that's different from metaprogramming and these problems are just as present in C.
PS In my spare time I'm working on an assembler project at the moment. I expect the final app to fit in under 8K, 4K with luck. I enjoy C++ but I haven't forgotten my roots!
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
Hmm, so I'm not the only one...
I've often wondered about an 'ultra-strict' compile flag for c++ which would reject any function that propogated exceptions not listed in it's exception specification list. (I guess the implementation would have to check every the specifications on every sub-level function call, or something)
page 375 of TCP++PL (3rd edition) states that breaking an exception-guarantee, when it exists, generally terminates the program. But this is a run-time solution - I don't see why it can't be made into a compile time solution, apart from trivial little matters like every single library on the planet having to be re-written to correctly specify their exceptions.
Looking a page ahead in the text, I see that Stroustrup does debate whether no-throw should be the default, and decides that it wouldn't be worth the effort. He's probably right, but if you could do it, it seems to me it would make c++ even more robust than it currently is.
OR YOU COULD JUST DECLARE (oops) declare your method to throw the IOException. Either way, whether you have to add extra code for exception handling or whether you have to add code to check if an I/O error occured (and go back until you read a whole line) is probably about the same. Exceptions are just replacing the old way of using return values for error/success events.
why run from Vincenzo?
"A Proposal to add Regular Expression to the Standard Library"
This seems typical of the pace at which language standardization moves. How long have standard, free, C (useable in C++) regex implementations been available for those who really want them?
And ISO-C still specifies no standard library for graphics, networking, regex, or data structures which are respectively satisfied by (numerous APIs), sockets, Henry Spencer, and (roll-your-own).
So, if any of this stuff ever makes it into the standard, that will just add the extra work of having to write a wrapper around the current solution to make your code "standard compliant". Why bother?
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
Everything else can be done within the language. (Actually, a lot could be deprecated - like "protected", which has no good use, IMHO.)
The class access operator overloading is especially important. Without the ability to overload ".", ".*", "::", and "sizeof", the class designer really can't completely control the behavior of his object under all circumstances. This leads to shared responsibility over the object, which in turn leads to confusion and bugs.
I could write an extended essay on this latter point, with tons of pattern and anti-pattern examples, but I won't bore you with it here.
instead of the names? This is stupid. Half the people who visit here sound like childish morons. Who cares what its called? I did not come here to read all the "funny" ++c++ jokes. I came here to read a discussion on the merits of all those changes and such.
Take a look at boost::lambda. There's a proposal to include it in the standard. :
It lets you do the right thing, e.g.
for_each(a.begin(), a.end(), cout (1 + _1));
Not quite as sexy as a functional language, but useful w/minimal overhead.
Life is a psychology experiment gone awry.
but you don't run across it much in the business world and never have
.NET marketing platform won, no surprise.
... AWT? Someone thought that would be a good idea?)
That's funny, I do. Or at least I used to. It seems (unfortunately) to be dying. The
and Perl/Python/Java/VB/tcl will always be better glue then C++
I'll give you Perl and tcl. Arguably, Python. But VB? Java? Have you ever tried to use Java as glue? Why didn't you name PHP, Lua, bash, etc?
(PHP is krazyglue. It's got every other language and major app on earth in a hard hat stuck to the underside of the c++ girder. And if you give them money, you get a seriously balls to the wall optimizer. Pity about the way it handles objects, but the way it handles variables almost makes up for it.)
Java, by the way, was designed to be hardened styrofoam bricks, not glue. Why hardened styrofoam? Because you can use it for support, or a wall, or insulation, or it'll float in water - that is, it runs pretty much anywhere, but isn't great for any of them. If you want it in a small bucket or low gravity (tiny systems) you have to hollow it out (J2ME) and if you want it as a really hardened wall you need to add all sorts of struts and support (tomcat, beans, JavaFeces.)
Java's a good ideal. It's good for some people. To me, it's like visual studio: it tries to do too much for me, and I don't like it. I'm a control freak. Besides: AWT. (I mean, really, I'd be making fun of swing, but
What I would really like to see in C++ would be compile-time exception enforcement ALA Java.
Would be nice, wouldn't it? There's a problem: C++ has lots of things that make this outright impossible. I brought this up on #c++ on efNet once, and it was explained to me in a way that made sense for about an hour and fourty five monutes (don't pretend like that's never happened to you.)
This is an open plea to someone better at C++ than I am: please explain why compile-time exceptions in C++ aren't possible, or alternately explain why I'm wrong.
StoneCypher is Full of BS
Let's create a working group of industry folks,
and CHARGE MONEY for the standard, so
that less and less people use the language,
write parsers, etc.
This model has worked before (well, not so much
for C, but C is simple). So it should work again.
On the other hand, most of the proposals for C++ "enhancements" are bad. Most of the "enhancement" proposals are from people who want to program at compile time by abusing the template mechanism. Then the end user is stuck debugging some gonzo template written by somebody who thinks they're l33t. This is not progress. We went through this with LISP, and it's one of the reasons LISP is a dead language.
But thinking that C++ is OK is a big mistake. The fundamental problem with C++ is that it has abstraction without safety. C has neither abstraction nor safety, so you can get in trouble easily but the problem is usually visible in the source code. Java has both abstraction and safety, but pays a performance penalty for it. C# offers the illusion of safety, with "managed objects", but doesn't really provide it, which is so Microsoft. Strostrup doesn't even mention "safety" as an issue. This is more of that "we're so l33t, we don't need a safe language" attitude that produces a few new buffer overrun vulnerabilties every week.
I'm being hard on Strostrup here. But we have far too many preventable bugs in code today. It doesn't have to be this way.
Two years ago, I proposed strict mode for C++. The basic idea is modelled on Perl's "strict mode"; you have to turn it on, but once it's on, the rules are tighter and there are some guarantees about the code not having certain common problems. I don't necessarily endorse that syntax, and I've had some later ideas on how to do this better. But increased safety is the way to go. As a retrofit, I admit it's tough.
"dude, the ^ operator is for XOR, not X^Y"
Okay, so what's logical XOR?
and #define xor(a,b) ((a)&&(^b)||(^a)&&(b)) doesn't count, unless you're a secret BASIC admirer
RDRAM is not and never was a standard. It's a proprietary memory interface.
Maybe you're thinking of SDRAM, which really is a standard (approved by JEDEC). The RAMBUS patents pertaining to SDRAM caused several court cases, including charges of fraud against RAMBUS itself. I haven't heard what's finally happened with that.
The gcc will finally be able to compile templates correctly without a serious performance hit?
-- I smell varmit puntang -- Carl Spangler
drop primitive data types.
Every data type becomes an object - Integer for int, Character for char - all dervived from a single master data object type.
What is weird to me is that every OO language that I have seen still needs seven lines of code to make an encapsulated attribute:
int x;
int getX() {
return x;
}
void setX(int x) {
this->x=x;
}
Is it not time we do this a litle bit smarter? For example as:
getable setalbe int x;
This would seriously limit the number of lines needed in C++ (and other OO languages), which would make it alot faster to write. Furthermore, and more importantly it would be easier to read as it is easier to get an overview of 50 lines than 100 lines of code.
When C++ came out, there was some debate over whether it should be called C++ or P, as P is the letter after C in BCPL.
Therefore, it would be more logical to call the new language L instead of D, E, or F.
This may be naive, but couldn't you just cut and paste your previously used linked list.
Well, you can cut and paste code, and that happens quite often in this world (one project here has 400 controls that perform various functions, and most of them are based off of a cut and pasted code template. Talk about a maintenance nightmare!). However, there is one huge problem with cutting and pasting code: if there is a bug, you will have to fix it everywhere you have copied that code. That's the big benefit of implementing a generic container class in a dynamic library-if you find a bug in your code, you fix it one place and the fix propagates to all applications using that library.
Point by point, then.
Not quite sure what you mean by "allow code-generation at compile time," since that's exactly what template functions allow. Also, C++ is already the only mainstream language which permits execution of semi-arbitrary code during compilation, making it a compile-time Turing machine in addition to a run-time Turing machine (which is what everything else is). Think recursive templates or take a look at the Alexandrescu text, you'll see what I mean.
You probably won't see continuations, but you might see closures. Those tend to destroy performance and can be tricky to implement correctly on oddball hardware. But some changes to the language (relaxations of existing rules, mostly) have already been proposed, specifically to ease the implementation of lambdas.
The existing language already permits things awfully close. Local anonymous classes with static functions, for example, come very close to local functions. Also, check out the Boost lambda library.
Many compilers already support __typeof to do type inference.
(Hint: no matter what you guess, the programmer really meant "the other one".) Now, how is a compiler supposed to guess, if you can't?As for your "so surprised that languages still make you do stuff like foo i = new foo;", I think you were absent the day the taught "Basics of Object-Oriented Design." Given two classes, Base and Derived, fill in the blank:
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Thats actually a use for return type sensitivity that I hadn't thought of, but that'd be really cool. Being able to overload a function with different return types, however, I've wanted many times.
Being able to do so would be extremely powerful, you could do all sorts of useful things.
For instance, even something as simple as returning an int or float from an overloaded Average function based upon what the user wanted back:
public int Average(int a, int b)
{
return a*b/2
}
public double Average(int a, int b)
{
return double(a)*double(b)/2.00
}
int intAverage = Average(1,2);
double doubleAverage = Average(1,2);
And hey, that's psuedo code so don't get all syntax freaky on me!
It'd be sweet if that worked in the major languages, I think right now it'd certainly be my top request for language enhancements...
// harborpirate
// Slashbots off the starboard bow!
Shouldn't MS take a hint and name their upcoming OS "XP0x" ?
Metaprogramming in C++ is one big hack!!!!!! Give me a break, stacking things up in the compiler just to hack together type lists? Frikking fix C++ so that it does this stuff naturally or switch to Lisp which gives you the entire language in which to do meta programming instead of hacking together crap in a system that was clearly never designed to be used that way.
That's from Wikkiepedia, and straight from Ken Thompsons mouth, at my aunts wedding (he was the best man.) So, plbbbbbbbbbt, I win!
http://www.wikipedia.org/wiki/B_programming_lan
If you want a standardized object-oriented C that's easy to learn, it already exists. It's called Objective-C.
GCHQ Quantum Insert installed. If only our tongues were made of glass, how much more careful we would be when we speak
Yeah, but I think the number one thing that Java did right was to start over. Most of the problems of C++ comes from the decision to be C compatible.
So if C++ wants to learn from Java, it should start over. But then it wouldn't be C++ anymore. Actually, you might as well use Java... Except that the focus of the new language should be performance, since that's really the one substantial advantage C++ has over Java.
but then what's the point of overloaded operators?
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.
Does that mean that "C" is short for Connie?
Patent: from Latin patere, to be open
and admit that c++ was all a mistake. demand a full apology!
Um... And how is that different than just making x public?
(OK, I guess it's a bit different if you just use one of the attributes, instead of both, but it's still doable with something like:
(definition of ReadOnly left as an exercise for the student).I don't understand why people get so obsessed with features they don't like that they always want those features removed. It's like they can't bear that those features even exist.
So maybe you don't like templates, operator overloading or something else. Who's forcing you to use them? If you don't like them, don't use them in your code. If you direct a group of programmers, warn them whoever uses those features will be fired, and use grep to be sure they comply. Just forget those features exist and let them stay for the rest of us.
Perhaps the "let's remove features" crowd should spend some time with the Ada programming language. Its extreme inflexibility by design (which is supposed to provide safety, though I don't buy it) gets constantly in the way of good, elegant, efficient implementations. I'm always angry that some perfectly sane and useful language feature that would be very handy in implementing my code doesn't exist simply because the language designers didn't deign to deem it worthy.
Different programming problems and styles need different language features. C++ can be applied to a much broader problem scope than Java thanks to its greater featurefulness. C++'s complexity shouldn't bother you unless you are in the business of developing C++ compilers.
-- Repeat with me: "There is no right to profits".
C++ templates have turned out to be surprisingly powerful and useful. C++ templates are not at all like generics in other programming languages because C++ templates respect overloading. That means that template instantiations may do completely different things for different classes. On the one hand, that requires extra care to avoid bloat during expansion, on the other hand it enables expressiveness that is unavailable in just about any other language. I hope Microsoft won't make the mistake of adding a watered-down generics facility to C#, instead of full template support.
If people want to beat C++ into shape, I think here are some things that would have to be done:
- Add a notion of "safe" compilation units, compilation units in which all unsafe operations (pointer dereferencing, pointer subscripting, some uses of the reference operator) are prohibited. (How do you get anything done? You use data structures that are internally using unsafe operations but are externally safe.)
- Require the presence of a garbage collector in every C++ implementation.
- Improve reflection features.
- Make error and bounds checking mandatory and the default in all standard libraries, in particular the STL, but provide options or operations that allow the user to turn off error checking selectively.
The biggest reason for not using C# for everything for me is that stupid virtual machine; Microsoft's CLR and Mono seem ever more eager to copy the sluggish startup times of the Java JVM. And, frankly, I don't give a damn about being able to move byte codes across architectures, so why should I pay the overhead?If we had a native compiler like gcj for C#, I'd probably be using C# for everything.
and "D" is short for Donnie?
cpeterso
But with metaprogramming C++ becomes an entirely new system. The template system is computationally complete (see here for what that means) and so important work can be shifted to compile time. [...]
While I agree with your post, note that the same (and in much more native and generic way) is provided by Lisp. What C++ does is making metaprogramming type-safe.
See, for example, this "confession" by Andrei Alexandrescu.
The preprocessor is a kludgey hack and needs to be reengineered out of the language. What benefits do we get with the preprocessor:
1) macros definitions to reduce the execution time overhead of a function call.
2) constants in the form of #define
3) the ability to conditionally compile code
A modern c/c++ compiler covers all of these cases by:
1) inline functions, in place of macros and all their evil side effects.
2) const, in place of #define
3) throwing away unreachable code during code generation, in place of conditional compilation. Granted you still pay the compilation cost, but the execution costs are negated.
I thought the successor to C++ was called Java.
Exceptions are just replacing the old way of using return values for error/success events.
And that's one of the drawbacks of the Java libraries. They think of exceptions as a way to return values from functions, rather than returning values or having "out" parameters. And thus the throw/catch turns into a non-local goto.
Exceptions should be _exceptional_, not routine and expected results of a function. A disk I/O error when your hard drive crashes is exceptional. Running into EOF while reading a file is not.
As others have pointed out, a la previous languages like FORTRAN, Algol and LISP, it refers to C++ and the year the spec is expected to be completed--in this case, (20)0x.
Have fun: Join D.N.A. (National Dyslexics Association)
I'm sorry, but I've seen the light and man, it sure it isn't C++. I thought C++ was this great thing, only to be bogged down with stuff like keeping header files in sync with implementation files. Get rid of that, and I might consider returning to C++.
C# is the language for me. Man, it takes all the great stuff of C++ and gets rid of all the hassles. foreach() loops make sense. Multiple inheritance of implementation is a trainwreck. I'll grant there are a few little annoyances with C# (like having to mark members as override, or with new [keywords should only have 1 meaning in my book]). But, C++ has TONS of them. I've coded in C++ for 8 years. I've gotten more done with C# in the past 6 months (including learning the language) than I have in my previous 2 years of C++ coding.
Sorry, but I'm never going back to C++, if I can possibly avoid it. And no, I don't like Microsoft anymore than anyone else here.
>somebody else already proposed (c++)++ , which is a reasonable suggestion...
The problem with (C++)++ is that while C++ would increment value of C by 1, (C++)++ would still increment the value of C by 1. Since (C++) yields a new value that gets stored back in C, that value will again be incremened by 1, but it never gets stored back into C, so (C++)++ would still yield the same value for C as C++, even though an annonymous temp stack variable would have a value 2 higher than original C!
to the tune of supercalifragilisticexpialidocious.
No. Michael Eisner's copyright lawyers would kick their a**es in a court of law.
Will I retire or break 10K?
So to summarize all the responses to Karma_Sucks's thread, C++ is basically pointless.
.... so, er, what exactly were the pro's?
As most of you agree, it has lots of pretty features (even the advocates agree that it's got *too* many though), and it's incredibly versatile (although even the advocates agree that in some areas it's *too* versatile for its own good), and it allows the compiler to optimize better (except that language complexity results in most programs being a lot slower than necessary because of all the unexpected and unnecessary temp constructions and destructions), and it's got excellent overloading (except that the gotchas increase semantic complexity a hundredfold and the rest of the time overloading confuses the newbies), and it's fully object-oriented (except that it's not since the encapsulation is only class-based)
I'm speaking as a long-term C++ developer, but (clearly) not as an advocate. I've just seen too many commercial projects die through using C++, mainly because the team's project management skills were not up to the challange of using such an extraordinarily complex language. When I say "die", I mean it has cost the companies millions of dollars each time.
I've also seen it succeed, magnificently, just once. But the management on that project was absolutely brilliant, exceptional. It is not the norm.
C++ has a few good things for lone developers. Pure and simply though, C++ is dangerous on typical commercial projects. YMMV.
I agree with the parent post (but not from a Java standpoint, as that language has a lot of silliness too): to improve C++, remove 90% of it.
What we really need is a C+.
"The question of whether machines can think is no more interesting than [] whether submarines can swim" - Dijkstra
How about getting rid of some features for a change?
The trouble with not removing features is that they interact with each other. Each time you add something or modify a semantic somewhere in the language, it has an impact on all those rarely used features that you've just left lying around for old times' sake.
This happened repeatedly during C++'s growth from its early "C with Classes" origins to the abomination we know now. Overall language semantic complexity explodes each time something is added that has more than a local impact, and that occurred again and again, which is why C++ is now the most complex language in existence. Virtually nobody has the 5 years and IQ of 200 to understand it fully (just too many nooks and crannies).
Suggesting that things be removed is just an exercise in survival.
or whether C followed B because it was the next letter in BCPL (in which case C++ would have been P).
P is for "Plus". C++ is pronounced "C Plus Plus".
Or perhaps you simply still think of C++ as "C with more type checking, and those // comments."
No, that's "gcc -Wall".
Will I retire or break 10K?
Oh stop that! It's a feature that the trigger is permanently on in C++. If your leg got blown off because you were on the same continent, that's your own fault!
How about c^2? (C squared)
You shouldn't be using raw arrays in anything except low level code anyway. For higher level code, it's almost invariably better to use a container class, be it vector, map, a matrix class of your choice, or whatever.
If you're using vector, there is already an at() method that checks the index. It should perhaps have been the "default", rather than making the overloaded operator[] the non-range-checked one and at() the safer alternative, but it's a bit late to fix that now; the feature is, and always has been, there, though.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
First of all, the discussion so far has been pretty immature.
To answers the most common question (why name C++0x), the name of the language is still C++. For standardized languages, it's common to refer to the different dialects by their 2-digit year extensions. Such as C89, F77, C99, etc. The use of C++98 and C++0x are merely used to disginuish the language at that particular standard.
Most of the library features of the new standard are already in the Boost library. Things like threads, regexs, smart pointers, are all there.
The smart pointer is actually one of the most highly debated topics because a stronger smart pointer is easy to implement but requires a new language feature (and even though this feature is likely to make it in, there's a requirement that all proposed libraries not required additional language features).
The focus on the new standard is really expanding the standard library (the goal is a library for C++ as useful as the ANSI library for C). Since C++ is committee based though (unlike Java), it takes a long time for these things to happen since it involves comprimise between many strongly-opinionated smart folks.
On the one hand, the language evolves slowly, but on the other hand, when it is ready, it will be a beautiful thing.
int func(int a);
func((b += 3, b));
Bengali or Urdu? Afterall, all the programming jobs are going to India anyways.
However, making that standard in the language is a terribly bad idea for one simple reason: what you have outlined is not the standard definition for multiplication. You have defined element-by-element multiplication, not matrix multiplication. For a matrix, that is incorrect. For an array, it might be right. Either way, there are multiple definitions that make sense, so defining either one as standard cannot be correct.
Lol. That's funny dude. The compiler forces it to be correct! Lol. Take a look at any big piece of java code and count the number of occurences of structures like:
// Lots of complicated stuff
try {
}
catch (SomeException e) {
}
I have wanted a tightening of a certain portion of the spec since ANSI's deliberations on the first standard. (Actually, I think I corresponded with Bjarne about it even before then.) I'll paraphrase it here (rather than spending time to put it into correct standard-ese).
1) Beginning with the execution of the first user-written statement of a constructor of the most-baseward class where a virtual function is defined, and ending immediately after the execution of the last user-written statement of that class' destructor, it shall be explicitly legal to call the virtual member function via a "this" pointer (or a copy of its value in an appropriate pointer type).
(This may be done even from code which has no special relationship to the object, other than knowlege of the value of a pointer to the instance and enough of the class' declaration to use it to call the virtual function.)
2) When a virtual function of a base class is overridden by a new definition in a derived class, such a call will execute:
a) The base-class version if performed before the exectuion of the first user-written statement of a constructor of the derived class.
b) The derived-class version if performed during or after the execution of the first user-written statement of the constructor of the derived class and before or during the execution of the last user-written statement of the destructor of the derived class.
c) The base-class version if performed after the execution of the last user-written statement of the desctructor of the derived class.
In particular: If such a call is made during the construction or destruction of member variables or objects of the derived class, the base-class version of the virtual function (if such is defined) is the one executed.
= = = = = = =
In a vpointer implementation this would correspond to the storing of the derived class vpointer as the last action before executing the body of the constructor, and storing the base class vpointer as the first action after executing the body of the destructor.
= = = = = = =
This is not a frivolous, nit-pick.
Making this change enables such functionality as base classes registering their instances during construction, with the behavior of the instances being appropriately promoted as they are built up, even if the behavior happens to be invoked during construction or destruction.
For example: Mark-and-sweep garbage collection of C++ objects can be built using a base class for garbage-collectable objects containing a virtual member function to encode knowlege of the derived object's pointers to perform the marking phase. But without the guarantees of this proposal, constructors and destructors of member objects (and even the containing class itself) become VERY limited in the complexity of behavior they can exhibit, since they must not allocate memory in a way that might preciptiate a garbage-collector activation.
Even absent this (and other) concrete example(s), the proposal would tend to make classes more flexible and less error-prone, because virtual functions become available during construction yet the derived class versions can't be invoked unless the derived class members (and the class itself) are initialized but not finalized. (With this guarantee the only issue of invoking a member of a partially-constructed class is within the class' own constructor and destructor, where it can be handled by programmer care. Without it the member objects may invoke derived class behavior on an uninitialized level of the object, or fail to perform necessary actions appropriate to the current level).
The proposal is upwardly-compatable because it simply tightens requirements on a subset of already allowed behavior. (The first ANSI C++ standard explicitly gave no guarantee of which overriding of virtual member functions would be invoked by a member object constructor or destructor of functions it called, while the revised standard didn't guarantee that EITHER would be invoked - essentially saying "Don't call them from there. Anything might happen.")
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
Yes, but as has been remarked, Ken is famous for pulling the leg of unsuspecting dolts like yourself.
I got one! Valarray should be called vector and vector, valarray.
After all, valarray is the one with the vector operations built into it! Hell, even Stroustrup commented about this in "The C++ Programming Language", and he created the damn language!
As the self-professed finder of the fortran "gems of knowledge" you are worthy of tribute and adulation ya know... oi polloi to learned patrician.
Where may we, to whom the gods don't speak, direct our tithes?
I'm gonna use what you use from now on.
It's one of Wouter van Oortmerssens many languages.
The logo is a nice little mdma e.
How small a thought it takes to fill a whole life
No, gentlemen are all about screwing the employees through non-verbal communication.
My pointy-haired boss wrote the book for the Mona Lisa school of project (mis)management.
But, hey, no angst here...
C++ aught x.
I cannot wait to tell my grand & great grand kids stories about aught (sp?) three like my great grandparents did.
IBM's did not comment on SCO's latest suit but instead issued a statement.
"All we needed to deal with the SCO threat was some sharks with frikkin lasers on their heads. Is that so hard? Really?"
>>
I am the director, and this is my movie
After reading some of these proposed features, I have to question why people would not use one of the already engineered languages.
The great example is Eiffel. Eiffel basically has every thing that you could possibly want in an OO language. Its design by contract features are pretty much unsurpassed. Polymorphism. True covariance. The whole nine yards.
I have used C/C++/Java pretty much my entire career. But after dabbling in Eiffel, it opened my eyes that C++/C are not the end all be all of languages. In fact, it seems to me that C++ was striving to be more like languages such as Eiffel.
I guess old habits die hard... which is why we stick with C++, Java, and the like. It also stands to reason why we continue to try to enhance C++ into different, more robust forms (Objective, D, etc).
But after using Eiffel for a few years now, I can say that I think it is highly superior to C++ in so many ways. But the big lacking it has is in its libraries. Eiffel simply has nowhere near the library support of C++, Java, or Python.
Anyways... I'm rambling here... but I wanted to put a plug in for Eiffel. For those who want a taste of something different.
How can I get me one of those numberals?
/adds another joke to the heap. Get it? heap?
:P
seriously though, this thread is like some sort of nerd version of fark.com
autopr0n is like, down and stuff.
Is page 6 of the PDF, the bullet point says "Remove embarasments" :P
autopr0n is like, down and stuff.
Oh, shut up. Typedef a struct with some data & function pointers, then have a "new" function to spit out freshly built structs.
It doesn't take any significant amount of time more or less than writing a C++ class, and you've got an object without the overhead of an OO language.
And you can swap out those functions at will, too.
Very nice for, say, changing the comparison function when walking a B+ tree full of said structs. You can then search on any criteria and not need to bog the search down with numerous compares in the tree-walking code.
Your mom is of the opinion that my crotch is superior.
Ooops, my bad. I could've sworn I remembered Rambus doing that to RDRAM and then getting away with it, which caused the industry to move towards the more-cheaper (yes, I know) DDRAM
Thanks for the correction.
-Bucky
Understand that anything written into a language standard must be implemented by everybody
Then create a multiple part standard: C++ Core, C++ Streams, C++ STL, C++ Bounds Checking Extensions, and what have you. Most compilers would include Core, Streams, and STL at a minimum because C++98 defined them.
Will I retire or break 10K?
The parent post overlooks the fact that GC is penalized repeatedly while malloc/free incurs a one-time hit. O(N_dead) vs. O(N_live) is not the correct model.
Each allocation must be returned to the heap whether using malloc/free or GC. That's a fact of life. Moreover, in any OOP language, (C++, C#, or Java) you may also have deconstructors or finalization to worry about. Memory deallocation should be discounted as baseline as none of these languages offers any advantage over the other in terms of speed.
This still leaves GC with the recurring overhead of tracking live objects.
No matter how many allocations have been previously freed, malloc/free-based languages do not have to repeatedly iterate through them, invalidating the parent poster's argument that the ratio of live/dead objects will ever tip the balance in favor of GC.
-Hope
If you think OO, you do this by inheriting an interface and implementing the comparison function the way you want. You can then search by just plugging in a suitable object (implementing the comparison). Or you can use a pattern (find it yourself).
Stupid. How do you implement overloaded methods? How do you implement abstract interfaces?
You are either ignoring the obvious solutions or using the wrong programming language.
It is generally understood that certain changes to a C++ base class will invalidate derived classes. This is not a side-effect; it's a given. Asking for this to be fixed is like asking that nails be provided with threads and a slot on top for easy removal. If you need to use a screw, use a screw.
-Hope
Micro$ux already has copyrights on any thing that refers to $
Diplomacy is the art of saying "Nice doggie" until you can find a rock. Will Rogers
I think you mean increase signal to noise; if so, I agree wholeheartedly.
I'm from Brooklyn, i'm allowed to say "not for nothin'" unironically.
If you defined your functions twice, you'd receive an error from the compiler. In the header file, typically, you declare your functions.
This has been a public service announcement by the cognoscenti for the benefit of the neophyte.
You can cast both up and down a class hierarchy. Usually, you only need to go one way, and polymorphism suffices. Sometimes, it's useful to go the other way, and the safest and most convenient method of doing that is a dynamic_cast.
You can even combine the cast with an if statement to ensure that no code ever tries to use a pointer that's been cast to a more derived type unless the cast succeeded, i.e., the object pointed to really is of a suitably derived type:
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
I think it's important to realise that most of the time, you shouldn't be using a lot of the nitty gritty features in C++: they're primitive, low level features, designed to offer maximum flexibility and performance, without any particular guarantees of safety. For most code, you should be using higher level tools with a more appropriate balance of performance, flexibility and safety.
However, a lot of the smarter, higher level tools now becoming popular -- libraries like the Boost collection and Loki, for example -- are possible precisely because a few people, typically those writing libraries of higher level tools, have the low level features available. If you're writing your own tools, you'd miss most of the power of a language like C++ if the low level support weren't there.
So I agree with you that many people use the same subsets of the tools available, but I think there is (or at least should be) a pretty clear distinction. Most applications programmers should rarely be using many of the language features, and will mostly use only the basics and some higher level tools, probably from libraries. The people writing those higher level libraries, on the other hand, will probably be using every trick in the book to make the library code as widely useful as possible, and for them, that extra power is invaluable, and what sets a language like C++ apart from something like Java or C#.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
The whole concept of files and headers etc is the out dated methodology.
What we need is a ONE project based system, that has all files transparent, perhaps internally it might be 1 file per class/function, but in the IDE its all in one with no files, just objects.
Liberty freedom are no1, not dicks in suits.
The problem is that compile-time exception enforcement ALA Java make many C++ programmers puke.
It always ends up in one of three ways:
1) Throws-lists that take three rows themselves and makes the code look fugly.
2) A lot of methods throwing Exception, which means a lot of work for nothing.
3) throw / catch blocks all over the place doing basically nothing other than printing to stderr (again, making the code fugly).
It's not worth it!
You're absolutely right. One of C++'s critical strengths is the zero-overhead principle.
The part you're overlooking is this: consider a language with two features. Then, for any given user program, there are four possibilities that the compiler (and thus, the compiler vendors, and thus, the language standard) has to be prepared to handle: the user uses none of them, or A, or B, or both A and B.
It's the last one that gets interesting. Feature A (say. run-time binding) has nothing directly to do with Feature B (say, "pointer to array is same as pointer to single thing", which we got from a different language). But their interaction can be surprising (say, deleting an array of Derived through a pointer-to-Base, which usually causes segfaults if sizeof Derived > sizeof Base).
Now consider a language with three features. Eight possibilities (none, A, B, C, AB, BC, AC, ABC).
Now consider C++. It's not forcing anybody to use features #3, #12, and #57, but if you use them in combination, the result had better be mentioned in the standard. And it had better make sense.
That's why the committee (and the compiler writers) are worried about adding new features to C++. Or any other language. It's not the features themselves that cause problems, it's the surprising ways in which they all interact. As a user of the language, it would behoove you to also be worried, because you could be relying on feature #22 without realizing it, and brand-new feature #107 just shot #22 in the ass.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
This is a tiresome and usually ill-founded argument. How much (space) overhead do you really think is incurred in a typical application as a result of this design decision?
Consider the common template example of a container class. Generalising but not much, you don't use a container class with many different types in most programs, and you don't use many of the methods available on it even then. Since only the implementation of necessary function specialisations is generated, the overhead is usually very little.
Moreover, techniques exist to reduce this overhead in some cases where it's of particular interest. For instance, a list<T*> can typically be just a typesafe wrapper for a list<void*>. These techniques are in active use, by the better STL implementations, for example.
While we're on the subject of space overhead, I'll just note that in the dynamic-binding languages, you typically have to instantiate a generalised version of every member function, since you never know who will be using your function and with what generic parameters. This can easily result in more space overhead in realistic circumstances than the specific code generated by C++ templates.
Now, consider the advantages of compiling specialisations rather than a single generic implementation. Your scope for optimisation is much better in this case, and a generic implementation of a function typically carries no more overhead than a specific one. A common example here is comparing C++'s std::sort with C's qsort, where the former frequently produces much superior output code due to the improved scope for optimisation.
Moreover, you have scope to optimise out whole layers of template mechanics. This allows high performance maths and expression template libraries to use clever template mechanics behind the scenes with impunity, while offering fairly straightforward syntax to the "end user".
As far as I can tell, all of this comes down very much in favour of C++'s approach. Java, as usual, adopts an approach where everything is available dynamically at run time, which grants a lot of flexibility on one hand, but carries a heavy performance penalty on the other (some, but crucially not all, of which can be overcome with JIT techniques).
There is nothing inherently superior about either approach: they are different design decisions with different goals in mind, each better for its own goal. Claiming that C++ templates induce more code bloat than Java's generics is, under realistic circumstances, pretty much wrong, though.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Inheritance bloats. Have you ever seen how much unneccessary junk goes into a Java JButton? All that extra garbage still has to be churned through, and will slow your implimentation way down.
What's stupid is insisting on loading the language down with cruft just so you can concatenate strings with a "+". You're adding unneccessary complexity just so you can have a function call resemble something that it's not.
Abstract, nothing. If you need it, put it in. If you don't, keep it and the crufty framework the fuck out.
Preach on, brother!
Fucking pussies use ramping cpu speeds to justify being stupid. "Oh, it's too hard! Why can't it be aligned according to my Feng Shui? Waahh!"
Um... And how is that different than just making x public?
The difference is in how you access the attribute. When it is public you would do something like:
SomeClass Y;
Y.x = 3;
With an encapsulated attribute you would do:
SomeClass Y;
Y.setX(3);
This may not seem like an important difference, and indeed it is not until you want to change how x are written or read. For example if you want to change setX to:
void setX(int x) {
if (x < 0)
return;
else
this->x = x;
}
Now if you have just used a public variable, you will have to change all the places where the x-attribute is accessed. When it is encapsulated you can just make the changes within the class where the x-attribute is declared.
ReadOnly<int> x;
(definition of ReadOnly left as an exercise for the student).
You can not use templates to declare methods within the class they are used. That is you can not make the ReadOnly template, such that:
class Y {
ReadOnly<int> x;
}
Will translate into (at an intermediate compiler stage):
class Y {
int x;
int getX() { return x; }
}
You don't need setX/getX in the owning object, just change x from an int to a class that implements operator = and operator int. If modifying x requires access to the owning object, it's not behaving like an attribute, so making its interface resemble one is misleading.
Diomidis Spinellis - Code Reading: The Open Source Perspective
#include "/dev/tty"
Get/set methods are concerning the use of a class. How it is actually implemented is another matter. The use and implementation can be very different. This makes it possible to make changes to the representation of your data, without having to change code thoughout your program. Below is an example to illustrate the point:
...
...
class Person {
string name;
public:
string getName() { return name; }
}
One year later your discover that it was a bad way to organize your data. Using first name and surname would have been better. With get/set methods you can change your class to:
class Person {
string firstName;
string surName;
public:
string getName() { return firstName + " " + surName; }
}
The users of the class will not have to change one line of code. You cannot do this with operator int and operator =.
But please, Lisp is no use to me. I have to work in the real word with pre-existing C++ software libraries and an expectation of high performance.
Doesn't it make you feel good to know that our freedoms are protected by politicans, lawyers and journalists.
Java name is not too bad, let's try 'Jacobs'...
We incremented it in the past, we're incrementing it now
This works unless changing a person's name has side effects on other
members (or vice versa), but in that case the name doesn't behave like
an attribute so it shouldn't be usable as one. It's more lines than
yours but is reusable and behaves much more like a builtin type.
(You may have to move >> and << outside the class if your compiler's
Koenig lookup is broken.)
#include <sstream>
struct person_name {
std::string first, last;
person_name() { }
person_name(std::string const &first, std::string const &last): first(first), last(last) { }
person_name(std::string const &name) { *this = name; }
person_name const &operator =(std::string const &name) {
std::istringstream(name) >> *this;
return *this;
}
operator std::string() const {
return static_cast<std::ostringstream &>(std::ostringstream() << *this).str();
}
static std::ostream &operator <<(std::ostream &os, person_name const &name) {
return os << name.first << ' ' << name.last;
}
static std::istream &operator >>(std::istream &is, person_name &name) {
return is >> name.first >> name.last;
}
};
class person {
public:
person_name name;
};