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."
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.
I think C++ needs stuff *removed* more than it needs anything added.
(Please browse at -1 to read this comment.)
Okay, I'm normally not a vocal C++ basher (although I do dislike the language), but this is a really excellent example of the kind of cruft that has made it into C++. It's like everyone and their dog had some pet feature they wanted included in the standard, and the result is a huge mess of stuff that most people won't use but the compiler is forced to support.
I suppose this is what happens when you allow a programming language to be designed by a committee...
Sorry to pick your nit, but int [3] will pad 12 bytes, not 3. an int is 4 bytes.
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
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".
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
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!)
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.
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?
Let's hear your suggestions on which stuff should be removed.
Default parameters and function overloading. Both encourage lazy programming and, more importantly, hide bugs.
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.
Until somebody adds a member called 'j' to foo, at which point your code still compiles fine, but is no longer doing what you intended.
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.
Actually, if someone adds a member 'j' to foo, then there's no reason to assume it would compile fine. In fact, I would suggest that such a case should be specified as illegal, as it is essentially identical to having two elements of a structure with the same name.
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.
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
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
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.
Ok, the mods must be crazy. This guy might be a troll, but... One thing I would like to point out is that Haskell is by far an "academic" language, if there ever was such a thing. Not sure why the parent poster uses that as an insult about Java's generics.
It's like everyone and their dog had some pet feature they wanted included in the standard, and the result is a huge mess of stuff that most people won't use but the compiler is forced to support.
You mean like templates, and member function templates, which allow for STL? Or operator overloading and references, which allow for *real* custom types.
Feel free to give specific examples, Mr. Insightful.
Why not explain further. Why is this modded as interesting when he doesn't even give proper basis for his/her accusations.
Troll. Troll. Tr...
The problem is much worst than that.
sizeof char is defined to be 1
1 what? 1 char.
A char is NOT DEFINED TO BE A BYTE (8 bits) in the any standard.
Almost always it is, though.
Take a look at the Texas Instruments TMS320C3x family of DSP's. It can do no byte level access. In the c compiler for it, sizeof char is 1 and defines a char as 32 bits. This means sizeof long is 1 and defines 32 bits as well. and this is completely standard compliant!!
And it also breaks tons of code!
--jeff++
ipv6 is my vpn