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."
Someone try to say that ten times fast!
Hate me!
Sounds like the l33t version of C++
The hardest part is deschiphering the comments...
Language revs are often referred to by the year of the completion of their standardizatioin (e.g., C++98.) The next C++ would presumably be somewhere in this decade, e.g., C++05 or so, but of course nobody is sure what year the work would be completed in, ergo C++0x.
I'm a nature photographer.
I too read it as "C++ followed by some hex number to be named later", but after skimming very quickly through the proposal, it seems they meant "C++ (20)0x, where x depends on whatever year the spec/implementation/whatever is released". Or, at least, that's what I think it means.
You mean...the successor ISN'T C#?!
I've...I've been living a lie...
I'm still waiting for the object-oriented business programming language, "ADD 1 TO COBOL".
I'm rooting for C+=2.
LibBT: BitTorrent for C - small - fast - clean (Now Versio
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 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
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!)
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?
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