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 ;)
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
Someone try to say that ten times fast!
Hate me!
Sounds like the l33t version of C++
The hardest part is deschiphering the comments...
Um... C is C(\+)*.
I've had this sig for three days.
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.'
Version 6 sucked A$$, but Vis c++ .Net is actually pretty good. And wtf are you talking about, I've used templates before with .Net (2002 and 2003) and had no problem.
You mean...the successor ISN'T C#?!
I've...I've been living a lie...
Already done!
D Programming Language
"Times have not become more violent. They have just become more televised."
-Marilyn Manson
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
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!
This is what happens when he's happy to see you!
sulli
RTFJ.
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 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?
If there is any progress, the new language should be at least ++C. You see, C++ is better than C but all you have is the C before C++.
Gentlemen, you can't fight in here, this is the War Room!
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.
However, alot of code breaks when moving to VC .NET 2003 : for some reason they decided to remove classic headers, giving us _days_ of work. I've never had so much problems with a compiler as with VC .NET 2003 when trying to just build projects that have worked fine since VC 6.0.
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
C has 15 levels of operator precedence, and you do not blush?
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.
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".
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.
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 believe it's pronounced "double-plus ungood".
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?"
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)
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!)
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
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?
From the Jargon:
C n. [..] 3. The name of a programming language designed by Dennis Ritchie during the early 1970s and immediately used to reimplement Unix; so called because many features derived from an earlier compiler named `B' in commemoration of its parent, BCPL. (BCPL was in turn descended from an earlier Algol-derived language, CPL.) Before Bjarne Stroustrup settled the question by designing C++, there was a humorous debate over whether C's successor should be named `D' or `P'.[..]
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...
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?
If there's a fundamental design goal of C++, it is not to force anything on the programmer. C++ supports procedural (C), OOP (many C++ programs), interface/component-based (COM, XPCOM, and CORBA), and aspect-oriented programming (not widely used yet). It's flexible enough to allow all these and more that are to come.
Java is a great example of a language that forces OOP on programmers. Most universities are starting students on Java because there are a lot fewer ways to get things done in the language. But experts know how to use the parts of the language that they need, and if C++0x took that power away from them they'd look elsewhere.
Making small changes to C++ to do things like get it closer to merging with C and improve weaknesses in the library like smart pointers are worthwhile and will directly benefit programmers. I don't understand your logic that any changes have to be large and basically change the nature of the language.
2003 is a great deal better than 2002. The version number of VC++ was only bumped to 7.1 from 7.0, but it was more of a 7.0 to 8.0 increase in compatibility. 7.1 is now on a par with GCC in terms of compatibility.
A deep unwavering belief is a sure sign you're missing something...
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
Which headers? I see IOSTREAM.H isn't there anymore. All I can say is thank goodness. I've seen so many people in the last 5 years include that file when really they should have been including IOSTREAM. Mixing the iostream libraries can be very bad. Besides, IOSTREAM is more standards compliant than IOSTREAM.H. I've seen people get confused by the documentation and use features of IOSTREAM.H that were completely unportable to other platforms. Now nobody will be confused and development costs are reduced.
If the upgrade was so expensive, you shouldn't have done it. We're still using MSVC 5 for some products, and MSVC 6 for most of the rest. Some small *new* products are now being developed in MSVC.Net, but we have to consider the cost of having code that might not be portable to older versions of the compiler. The cost of upgrading the older products cannot be justified, so we still use what works.
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)
Uh, just leaving it as "undefined" so that implemenations MAY (or most probably will not) define some useful behavoir...is far from useful.
Instead of leaving it as "undefined", they should define it as "If compiled with array range checking so and so exception should be thrown with the name of the variable and line (given debugging info is one)" or something...so that at least it is USEFUL.
It's 10 PM. Do you know if you're un-American?
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
T33N 8abes ready for your h0t C++0x !!!
======================================
Writers get in shape by pumping irony.
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
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...
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.
Classic headers (iostream.h, string.h, etc.) were deprecated in the 1998 Standard. You've had 5 years to remove them from your code. If you still have problems because you move to the latest compiler but don't move your code to the latest standards, then you have no one to blame but yourself. Well, maybe your manager, in which case I forgive you.
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? :-)
Maybe B was still short for BCPL, and C is now short for CPL because it's not Basic any more. So next, P would would be short for PL because it's not really combined (?) any more. And finally, L would be for, well, L, because it's not really for programming any more.
I found the meaning of life the other day, but I had write-only access.
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.
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.
The hard part is not in taking a compiler and getting it to construct Windows executables. The hard part is getting it to cooperate with the existing ABI well enough that you can integrate with the other compilers for the platform. This is much harder to do for Windows than it is for, say, *nix.
In other words, if Microsoft wanted to make it easy to make 3rd party compilers for the Windows platform, then they could have done so. I am claiming that they instead did the opposite, and made it difficult to construct and maintain a 3rd party compiler. I think even Borland would agree with me on this.
Is it Sun's fault that MS doesn't have a VB compiler for Solaris?
No, but in this hypothetical situation, if MS had investigated making a VB compiler for Solaris but gave up because of difficulties imposed by Sun, then some of the blame must go towards Sun.
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 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
Personally, I'd like to see header files go the way of the dodo. Usless, annoying, and repetitive. Why do I need to define my functions twice?
This is one aspect of Java I appreciated most...
"Ignorance more frequently begets confidence than does knowledge"
- Charles Darwin
EDG are some really smart people, but their comments have since then been disproven.
export in itself (specifically, the idea which export is trying to implement) is a good idea. Where the committee screwed up was mandating its existence without any prior experience.
Keep in mind that the point of an ISO standard is not to require/"legislate" new ideas, but to standardize existing practice. Everything in C++98 had already existed by the time the standard was even close to being done, except export.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
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.
Yeah, it's MUCH more efficient to slog through source code to find out the definition of a function, as opposed to looking in (much more easily read) header files. I doubt I'd be able to write code anywhere near as efficiently if I had to look up function definitions within the code modules themselves.
I think that by "EDG comments" you are referring to the paper "Why We Can't Afford Export". This was not actually written by EDG. There was a thread on comp.std.c++ recently which discussed this. You'll need to look at the whole of the first article as it refers to export only in a footnote.