Slashdot Mirror
Bjarne Stroustrup Previews C++0x
Szplug writes "Bjarne Stroustrup has a sneak peek at the additions to C++ that he expects will be completed (hopefully) by 2009. Included are language-defined threads, optional garbage collection, some automatic type deduction, and template concepts. From the article: 'The list of current proposals is still quite modest and not anywhere as ambitious as I'd like. However, more proposals are being considered and more libraries will appear either as part of the C++0x standard itself or as further committee technical reports.'"
C+Infinite here we come!
Having programmed in numerous languages I can't help wonder if it's really worth it. There's a reason why languages come and go. Bolting on new features might be more like treating the symptoms rather than the cause?
Time will tell, I guess.
.: Max Romantschuk
"C" was an unusual enough name for a language. Then "C++", which makes sense to you or I but would only mystify a non-geek. Now "C++0x"? How is that even pronounced? "See Plus Plus Zero Ecks"? Or maybe just "C...ocks"?
Names like this serve to only further mystify computing and programming among the non-geek population.
With spending like this, exactly what are "conservatives" conserving?
Seems that the famous interview was spot on. Remember OpenBSD has only one C++ package, and that has a good reason.
Does anyone expect to still be using C++ in 2009?
proof that not everything from Bell Labs is brilliant.
What I started to hate in C++/Java/C# is that there's no easy and standard-conforming way to express complex data 'inline'. Yeah, it's cleaner to make it XML and load it runtime, but there's no simple+quick way to do that either.
Hell, you can't event put known non-uniform data in C++ vector without doing it one-by-one.
fucktard is a tenderhearted description
I still think C++ was invented as a joke. I mean, fancy allowing standard operators to be overloaded. And reference variables? I now have to carefully examine very function prototype when I need to know if a function call might have side effects.
And now garbage collection? That just a feature to fix poorly written code.
When I found the C language, I stopped looking. Ah well.
Open Source Drum Kit, LPLC deve board - mjhdesigns.com
You mean D?
"And C++ programming languages, we own those, have licensed them out multiple times, obviously. We have a lot of royalties coming to us from C++."
i n/0,14179,2877578,00.html
http://techupdate.zdnet.com/techupdate/stories/ma
You know where to send your royalty checks.
Thanks
Darl McBride
I think it is obvious that this guy has no idea what he is talking about when talking about C++.
By the time he's finished with C++0x\n==%d, I bet the specification will look suspiciously similar to that of Common Lisp!
I also have come to realize that if there is one bad thing in C++ than it is this preprocessing which it inherited from C. Especially in a large project the trouble of including the right files and linking against the matching libraries becomes a pain in the ass. In this respect I would like C++ be more like Java (or TurboPascal for the matter) where interface declarations and compiled code are unified. At the moment moving around code from one DLL to another is a lot of work, while in my perception, it could have been completely transparent from the users point of view.
I do realize that keeping backwards compatibility was one of the design features of C++, and that it also determined the success of C. But as many C++ tools are now able to make use of precompiled headers, it seems that the problem should be able to be done away with.
If we want to write complex and secure programs quickly, we need better languages, and more features does not mean better.
You're an immobile computer, remember?
The work on C++0x has entered a decisive phase. The ISO C++ committee aims for C++0x to become C++09.
C++ octal-9???
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
If you are a C++ developer, check out Scott Meyer's webpage on the TR1 additions: http://aristeia.com/EC3E/TR1_info.html
Much of this functionality is already available in gcc4. The includes are stuffed in the TR1 subdirectory (#include ) and all the functionality is stuffed in the std::tr1 namespace (std::tr1::array).
Objective-c has this feature since 20 eyars, and obviusly better and more consistent design as a true C superset. Steve jobs had a great idea to use
it for it's next generation mac stuff.
Translation : C++ will continue to be a highly useful language, as long as some other sucker does all the hard work
'Some other sucker' being the hundreds of C++ experts across the world who contribute to the C++ Standard Library and others (e.g. Boost). What would you prefer - Stroustrup does it all single-handed?
As the article says, C++ is a 'general-purpose programming language with a bias towards systems programming'. If the libraries were lumped in with the core language, C++ would be a much less flexible and less appropriate tool for those kind of tasks.
Take what we have now, add whatever we want, for fucking christ sake get something coherent out of it and call it C+++.
How can one add to something incoherent and get a coherent result?
How about having a slashdot interview about C++0x with Strousrup? I think it would be a good forum to gain more insights about C++ and a fine possibility to allow a community (in this case the slashdot readers) to make and to vote on feature proposals.
This has really brought out the C++ haters. Still, most commercial applications, games, utilities, OS's, etc are still written in C++ (or a combination of C and C++). There is a reason for this; it is because C++ is both incredibly effective and extremely efficient. Sure, its possible to create artificial benchmarks that prove otherwise, but in te real world where performance counts, people use C++. But when they want flexibility they go for Ruby or Python or something similar. If you want outstanding applications, you use an outstanding language like C++. If you want average applications, you use an average language like Java.
Surely that should be C+=2
But considering that lots of OSS projects like Firefox and KDE still use C++, not to mention commercial games like World of Warcraft, C++ probably does have some saving merits.
interface and implementation (both are keywords, comes from pascal) section: lets get rid of seperate header and code files. The idea is aged, inefficient and doesn't help clarity nor ease of coding.
Bit-arrays: yesyes, I know. Boost contains a class which does that. But I think it would be so much nicer if the language had that feature.
In my opinion, many people are trying too hard to be clever and advanced.
I was advanced once, but unfortunately it just left me waiting for everyone else to catch up.
He who knows best knows how little he knows. - Thomas Jefferson
Aw, has diddums been playing with the grown-ups things again?
They do redefine C every few years, the last time was in 99. Of course, the changes were minor. The biggest one I remember was that // is now a comment, and a few other tweaks. No whole features added.
I still have more fans than freaks. WTF is wrong with you people?
Take a look at the some of the posts round here - sadly it looks like the typical Slashdot poster is pretty stupid these days :(
just use D.
http://www.digitalmars.com/d/
how about adding a run-time compile feature? how about being able to read in a string and use that as a variable name? (hash table with pointer/reference?)
just my 2 bytes
What would you prefer - Stroustrup does it all single-handed?
It might be nice if he could.
Stroustrup lives in a fantasy world where the only reason C++ isn't as fast as C, or produce as small of assembly as C is because of the compilers- which he conveniently disavowes responsibility for.
Compare to Objective-C: You'll note that these new C++ "concepts" feature are extremely similar to Objective-C's "protocols"- only not only can a moderate programmer produce a fast Objective-C compiler, they'll know exactly where it can be slowed down and why.
It'll also already be able to do these things in C++ that are so new and innovative.
Meanwhile, some C++ compilers can make "cout << 1 << endl;" slow- and others only do it when the programmer tries to make their own "cout" like device.
If the libraries were lumped in with the core language, C++ would be a much less flexible and less appropriate tool for those kind [systems programming] of tasks.
No, it's if those libraries imposed greater responsibilities on the runtime. As it stands, the C++ runtime already has an awful lot to do- albeit less than Java or Objective-C.
Worse still: The C++ runtime isn't a peer to your own code as it is in Objective-C: With Objective-C you can interact with the runtime as if it were regular library calls.
C has a mountain of library code available, and the functionality of that library code drives new extensions to the C core language (TLS extensions, for example)
But then, C has almost zero runtime (and if you reject certain extensions: it actually has no runtime), and that's what makes it suitable for systems programming.
I don't think C++ is now, or ever was (or with the way these "extensions" keep showing up) - or ever will be suitable for Systems Programming.
Because the C++ programmer infrequently can understand what his runtime is doing- and is not encouraged to know the interface by which C++ does it's magic (because nobody knows- they're still trying to figure out how to make some C++ magic work in a way that isn't slow)- a C++ systems programmer needs a C++ runtime. Nobody has one in systems-space, so the C++ programmer (which isn't a programmer of C++) needs to write it.
The inventor of C++ can't even do this, but any moderate programmer could do this for Objective-C.
What I'd really like is a fully vertical programming environment that's more humane, lets me get to the bare metal if I want to, or be very lazy and high level, if I want to, it would do assembler, C, C++, and higher than C++ level, a set of languages where I know what each statement expands to in the lower level, where the compiler sort of holds my hand, and shows me what's going on, and I'd rather have a more plain english compiler output even if it's not optimized, or if it's optimized and difficult to follow the jumps, then a plain english description of why it's doing it. What happens when I write a statement and get a bug is too much behind the scenes for me, too much of a smoke and mirrors, too cryptic. I'm lazy and prefer writing programs the easy way, in very high level languages, say in basic, python and perl, unfortunately they lack performance because most are interpreted. There should be a way to do high level without interpretation, but instead compiling into lower level stuff, after all, instructions in one language should have a 1 to 1 matching of what happens in another language, or there could be such an optimized matching. If I was allowed to constantly inspect what each high level construct translates to in the lower level language that's still higher than assembler, in a human readable form, that could improve the overall performance and bug issues for all the levels of programming, because if there is a problem, a bug, the programmer could inspect and figure it out and submit patches. I find myself learning things mostly when I'm involved with a task at hand, if I didn't have a problem, I'd never learn about something. I'm sure most people are intelligent enough to figure things out if they really need to, but they have no transparent and easy way these days, it's all or nothing, C++ to straight assembler, and they are stuck with starting off writing a program in a difficult and low level language because that's all you can do - once you made choice and settled on a language, or even a set of libraries, you're stuck with it, and if you don't like the language code, you're welcome to look at the compiler output in assembler. I'd rather see some smoother transition layers, something that starts out very nonverbose and progressively gets more verbose and difficult as you go lower on the layers. Something that starts out as simply as drawing a few diagrams to generate some very high level code, almost in plain english, that a compiler translates into C++, that I can look at, and even see what C++ would translate into in C, and then C into assembler. Some Microchip PIC c compilers retain the original C code next to the assembler part, so it's readable what's going on. Even dotnet that's an interpreted language, that too can list the bytecode next to the original code. I'd like to see what happens, all the way to the bare metal. Yes compiling time would go up, but you could skip intermediate stages if you wanted to. One of the worst things these days is that there is no single programming environment where I can sit down and 'own' the computer, without working my ass off, unless I want to. An environment that debugs the speed of the code, shows you what happens where, what code consumes a lot of memory, what code portion took how many milliseconds to execute, and with this constant feedback, I could concentrate my efforts on the portions I'd like to concentrate on. You could have the 4 level layers called C-02, C-01, C+00, C+01, C+02, etc. C-02 equivalent to the architecture layer, C-01 to the C layer, C+00 to what currently C++ is, C+01 to something like basic or python, and C+02 to some diagramming software (like VB/VBA macro record or Visio or something similarly super-easy). You could then directly compile C+02 to C-02 if C+02 diagramming software is all you know, or go deeper in the in-between levels, depending on how much elbow-grease you'd like to put in and what your skill level is, you could go from C+02 to C+01 to C+00, each code expandable if it has a hand-coded equivalent, or just using the de
No features??? Try complex numbers, inline functions (i.e. typesafe macros) and variable declarations which does not have to follow the start of a scope and restricted pointers.
"Civis Europaeus sum!"
I was pleased to notice that Bjarne Stroustrup has acknowledged that they won't be pursuing to include a GUI framework into the new C++ standard.
;)
Although this might be considered a disappointment, his citing the fact of low resources, time and money are best spent in other areas. Lets get something out the door that we can use now instead of waiting for the GUI. I'm no C++ expert, as a matter of fact I'm only into about 400 pages of my first teaching book
Nobody will deny the power of some of the C++ GUI's out there, QT is probably best of breed. Its probably good to have commerical interest in the GUI space, since the desktop is forever evolving faster than a C++ committee could handle.
C++ template concepts are no better (or worse for that matter) than C# generics constraints, they only bind differently: C++ binds to a name, C# binds to an interface. Both are equally rigid. Both require foresight. In C++ you don't have to derive your class from a specific interface, but on the other hand you still need to implement the function knowing what name it will be accessed through (i.e. should it be named begin or Begin or GetBegin).
It is good for a language to have threads "built in". As mentioned in this paper, "Threads Cannot Be Implemented as a Library": http://www.hpl.hp.com/techreports/2004/HPL-2004-20 9.pdf
if you do threads in a library, you run into problems with semantics or performance. Semantic problems == compiler breaks your multithreaded program. Performance problmes == compiler does naive translation of program, terrible performance.
http://www.thebricktestament.com/the_law/when_to_
Hi Guys.
The rumours are true. I have been bored, so I thought you should all rearrange your furniture.
I've decided to change { } for the more traditional begin-end. Don't worry. In the next version after this version I will change it to something else.
I've also decided to change streams again. This time three functions will not be supported. You guess which three!
I thought I might add some new namespaces. You will now have to prefix every reserved word with BjarneIsCool. For example, BjarneIsCool::for (BjarneIsCool::i=0; i10; i++).
I've also decided to make "i" a reserved word. Global Search and Replace is your friend!
Yeah, I know some of you might be cursing me for this, but on the bright side, unlike those poor COBOL-Y2K programmers, I *am* keeping you all employed.
Your BjarneIsCool::friend,
Bjarne!
they should call it ++C, so then the "shouldn't you iterate the language BEFORE you use it" jokes can go away.
99 bottles of beer in 175 characte
Translation : C++ will continue to be a highly useful language, as long as some other sucker does all the hard work.
Well, the power of most languages is in the libraries anyway. What is Java or C# without the standard libraries? I program in C++/Qt and rarely if ever touch all that is ugly about C++. The very few places I allocate memory myself for operation with other code I check it rigorously, Qt objects handle themselves. I use QString and QBytearray and never have issues with zero-termination or buffer overflows. Signals and slots will never crash on a dangling pointer. The new Qt4 containers with foreach are brilliant. So yeah, core C++ may be functionally poor but if you need the equivalent of java or C# it's a library away.
Kjella
Live today, because you never know what tomorrow brings
The thing is that one of C++ main design points is that it should be able to do everything a computer can do; it is a system programming language.
That is why it will always include features which will force the programmer to think whilst typing, unlike in Java (my current job) which is a lot easier but won't allow such low level access to the computer.
As for the preprocessor issue you describe; it's type-safety.
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
I'm waiting for C++-Ultimate0xff
When Fascism comes to America, it will call itself Anti-Fascism, and tell you to give up your guns.
I think you have missed, or underestimated the effects, of having to pre-define the interface rather than just using it. In C++ you just write the template code, in C# you need to have an interface defined. How many do you think get a bit lazy and use a more generic interface that includes constraints not nessesarily used in the specific function call?
- These characters were randomly selected.
At the very least, the new name could be Y2K compliant.
C++09 doesn't seem to do that. At this rate, they'll still be making updates in 2109, so maybe they should clear the ambiguity and rename it from C++0x to C++200x
http://www.mozillaquest.com/Linux03/ScoSource-02_S tory03.html
"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."
Thanks
Blake Stowell
That's old stuff. The Great Streams Rewrite came later, which was precisely the problem. If you want to change a prototype language, or a language that isn't widely spread, or if you've got a *real*good*reason* (hello buffer overflow), that is fine. But the Great Streams Rewrite was making cosmetic changes to something already out there, and that costs IT departments $$$ without adding a cent in return.
It's the ninth-circle-of-hell compiler optimisation. It does some form of distributed computation using hell's citizens' bones for data storage and avian carriers for data transfer, and will protect your Windows box from spyware because its binaries are more evil.
Yeah, the power of the dark side. You're only a master of evil, AC.
You're an immobile computer, remember?
I also have come to realize that if there is one bad thing in C++ than it is this preprocessing which it inherited from C. Especially in a large project the trouble of including the right files and linking against the matching libraries becomes a pain in the ass.
/usr/local/strange_module-2.3.7 and that would pass -I /usr/local/strange_module-2.3.7/include to the preprocessor and -L /usr/local/strange_module-2.3.7/lib to the linker.
Even though headers and libraries are the most common problem I come across from day to day, it wasn't until now that I thought about it as an implementation problem.
I'm not sure about the preprocessing bit. ifdefs and includes to get prototypes and other global/module specific variables are very handy. Its just a little silly that there is not a common preprocess and link flag that you can tell your compiler to find includes and libraries. How about gcc -F
How tough would that be? You can always explicitly add linker or preprocessor flags if you need to, but I would find this method superior to the current one by far. One of the biggest issues with preprocessing and linking is the order of the search path. Having it as one flag to pass to both of preprocessor and linker would simplify things.
You put everything in one big file (implementation and interface all combined together).
The compiled version was a TPU file and contained both the meta information on the interface (for the compiling other modules that interface) and the actual code (for the linker)
The compiler of other modules read the meta information from TPUs,
The linker got all the code from each TPU, and thru away the meta info from each, and linked them
And if you don't "do it right"?
I think he means to call it C++x0r. Cause the type safety makes you ub4r.
The perfect sig is a lot like silence, only louder
I personally have more hope in this alternative.
To me, D has surfaced to become what I always thought C++ should have been. I hope (and believe) that it will be giving C++ more competition in the comming years. It might not be ready for full production yet (due to lack of big supporters and libraries, mostly), but I have tried it out on several of my own projects, and I love it.
It's much more interesting to me to hear about what Barne will be taking OUT of C++. Adding features is the easy, wimpy part of the job. Removing them is the part that takes cohones.
-russ
Don't piss off The Angry Economist
Implicit vs. Explicit. Informal vs. Formal.
Give me C++ templates. I don't want to formally declare my interfaces, it is just too much work to justify when other methods exist.
If you can't see a good use for preprocessors, look up preprocessor metaprogramming. It's a very powerful tool for not only making portable code, but also for expanding the language itself on a per program basis.
++ is the increment operator, C++ is C that has been incremented with new OO features (be that for better or worse is a personal opinion in the same league as religion)
C++ template concepts are no better (or worse for that matter) than C# generics constraints, they only bind differently: C++ binds to a name, C# binds to an interface. Both are equally rigid. Both require foresight.
The point here is, that to use e.g. an int, you would have to make int implement the interface, meaning that the necessary foresight goes all the way back to when the language was designed - "Oh, in 2009, dalleboy is going to need to use an int in a generic that needs the ICountDown interface, we better define that interface now, and make int implement it".
That's what they are trying to avoid.
So I switched to Common Lisp and have been happy ever after.
Why do they want so many years to decide on so simple things that are other languages take for granted for more than 15 years now? Let's see what they have in store:
But what makes the most negative impression is the willingness to recognize that the programming language world has made huge steps in the last few years, and C++ is light years behind. Here are some of the negative points, in random order:
...and stop all this high-level language folderall. Real Men program in raw machine language, not some namby-pamby crutch like C++.
Remember: counting in binary is just like counting in decimal...if you're missing nine fingers!
"My country, right or wrong; if right, to be kept right; and if wrong, to be set right." --Senator Carl Schurz (1872)
From that page:
I can't believe IBM wrote OS/400 in C++! I don't think the OS/400 even had a decent C++ compiler back when they wrote it. Besides, I think it's too stable to be written in C++ (especially in those days, C++ today is OK).
is that the *fix of all the other examples you mention actually mean something (as does the ++). What does 0x mean? That somebody got creative?
(Just pointing it out.)
Implementing a garbage collector for this language, even if optional, will kill it. There is a reason for C++ still not having one, it is because it is impossible to write one without restricting the language. Even if you can disable the collector, you'll can not use the constructions that it doesn't unerstand, so this C++0x wont be suitable exactly to what C++ does well.
If you want Java with native widgets, please, rewrite the widgets, not Java!
Rethinking email
Bjarn says he wants to make C++ an even better systems programming language. The way to do this is apparently by adding features to a language already groaning under the last batch, far from all of which have been consistently implemented in all (or even a majority of) compilers. None of these features seem to address the fact that as a systems programming language, C++ has most of the same shortcomings as C, while adding a few of its own:
1) It is no more portable than C. In particular, various fundamental data types are still dependent on the underlying CPU architecture for their size and format, leading to copious macro #ifdef sections in low-level code that must run on a variety of different systems.
2) Use of the extra abstraction mechanisms provided by C++ tends to result in code that is both larger and less performant. This is not a desirable attribute in a systems programming language.
3) It is already an extremely complex language that requires an extremely complex compiler to implement it. This makes it very difficult to validate, thereby rendering it useless for whole classes of systems programming tasks (e.g. high-reliability embedded systems).
4) The language is a mine-field of ambiguities, overloaded meanings, and counter-intuitive default behaviours that conspire to make it incredibly difficult to learn properly. There are so many potential pit-falls that even very experienced programmers from other languages have trouble writing high-quality code with it, meaning that the language is actually a source of problems in many projects rather than a mechanism for solving them.
It is thus not (as Bjarn claims) a "better C", at least in a systems programming context, because nearly everything it adds is largely superfluous to systems programmers, and comes at a cost that they are unwilling to pay. This is especially true in what is by far the largest segment of systems programming, i.e. embedded systems, many of which are programmed in _significantly simplified_ versions of C, not the goya-esque monster that is modern C++.
NB: it is very difficult to design a single language that is equally useful for both high-level applications programming and low-level systems programming because they have fundamentally different requirements. Systems programmers require precise control of minutiae, whereas applications programmers want something that lets them churn build quality end-user systems with a minimum of pissing around. C++ falls between these two stools, adding nothing useful to C's systems programming capabilities, while being so concerned with nit-picking minutiae that writing high-level applications in it is like scrubbing a very big floor with a very small toothbrush. It is IMO well-suited to only one notable application domain: games development, which is unusual in requiring a mixture of both low and high level code.
I'm not going to change your sheets again, Mr. Hastings.
I agree 100% - C++ is too feature-heavy as it is. Bjarne should stop while he's only a little behind ;-).
As far as the preprocessor goes, one of the things I don't like about Java is the lack of a preprocessor. Sun ended up having to build assert() into the language because of it. Yes, the preprocessor can be abused, and perhaps it needs to be redesigned, but having no preprocessor is too restrictive.
I know there is this grass-roots "D" language floating around, but I'd like to see a C+=2 (or perhaps E?) that started back with the current ISO C standard, then added object-oriented features in a more organized, well-thought-out fashion.
(And no, I don't consider C# to be the answer. C# was just Microsoft's way of cloning Java. Now Sun and Microsoft are in a pissing match with Sun playing catch-up this round, trying to force features into Mustang to catch up to C# 3.0.)
Don't underestimate the power of The Source
I can't believe someone rated you "3 interesting" for a crap post like that.
...) which is why things like templates were introduced as a first in C++ and LATER adapted in languages as Java and C#. So who's leading?
It's like judging the quality of a car by the features of the glove department. Obviously you haven't been doing any serious C++ programming to come up with this sort of comment. I suggest you try to read Andrei Alexandrescu (google that up yourself) for some real programming power.
I can't believe people can be serious about calling Java and C# more modern than C++; they don't even have multiple inheritance or class-local typedefs. Or how about switching your code to call a memberfunction at compile-time vs at runtime (as in templates vs polymorphism). How will you do that if you are forced to use a virtual machine?
Oh no wait, the next big thing: Ruby on Rails (that's Retards on Rails to me). Everybody in the industry knows the major drawbacks of code generation (generate code, change generated code, IT manager says the specs change, regenerate code, redo the initial changes, notice they don't work anymore,
You people make me tired.
And what if there's nothing behind the door until it is being opened?
Here are some things I personally would like to see (some of which have been mentioned elsewhere as possible inclusions). Not all of them are 100% appropriate for something like C++ and the C++ standard library but all of them are things that seem (to me) to be usefull things to have as compiler and library provided functionality.
language provided thread support. This would need to provide the following (at least):
1.Proper thread safety at the language level (including mandates that the standard library is thread safe)
2.Thread-local storage (i.e. a way to say "this variable is local to this thread")
3.A way to say "this block of code should only be accessed by one thread at once" or "this variable should only be accessed by one thread at once" (something like a critical section on win32 I guess)
Plus of course ways to create threads and such.
Complete compatibility with C99 (i.e. any valid C99 program is also a valid C++0x program and will compile and run)
something similar to (and compatible with) fstream/ifstream/ofstream except that it reads from a block of memory instead of a disk file
A nice sane cross-platform way to detect memory leaks (i.e. the compiler implements the standards-specific memory leak detection in the implementation of new and delete and then the progammer would enable it e.g. with a new #paragma or something. (this goes with the garbage collector idea mentioned elsewhere)
Complete unicode support throughout the C++ language and standard library (although I think this is already mostly there)
New classes or functions (e.g. a new string class and new/improved collection classes) designed such that they help prevent or miinimize buffer overflows and memory corruption and the resulting effects (sort of like how compiler vendors like microsoft have started to add "safe" string functions only standardized)
Standardized definitions for constants like pi (plus more math functions as standard)
A standard library to do data compression and uncompression (perhaps an implementation of what is defined in RFC 1950, RFC 1951 and RFC 1952 i.e. the algorithim and format used in gzip, pkzip and zlib would be appropriate). Further to this, a new fstream/ifstream/ofstream derivitive that will compress data when writen out and uncompress it when read back in (without the programmer having to do anything).
I like the idea for a standard library way to do directory and file manipulation and the idea for a standard sockets library although (like the compression idea I have above), I do wonder if they are really appropriate for C++ or if they are better provided by third party libraries.
I ressent your synicism.
- First they ignore you, then they laugh at you, then ???, then profit.
And using C++ template concepts - "Oh, in 2009, AC is going to need to use an int in a template that needs the CountDown member function, we better make int implement it".
Same thing, different taste. (Not that primitives have member functions in C++, but feel free to exchange int with something other.)
As far as I can see:
./ discussion were about the new features of C++0x instead of the old "C is better than C++", "python is better than C" and "x86-assembly beats the pants off both".
1) people complaining here about C++ or its will-be features either aren't C++ users or don't understand much of C++;
2) people who have at least managed to RTFA to the end are complaining about new features of the _language_, that will be _few_, while the biggest efforts will be oriented towards extending the STL, which is the really important part.
Btw, only a C user that understand C++ poorly could complain about references. If you find yourself at ease with C, by all means, use it. But don't spit on another well engineered language without the necessary knowledge to do so.
By the way, about references: what's so different when passing to a C function a pointer to a struct, instead of a reference to a C++ one? Don't you have still to read the prototype to know you must pass a pointer indeed? There's just one small difference between C and C++: guess what, if the prototype is a const reference in C++ you've more guarantees the object won't change than with a const pointer in C, since C++ enforces constness. And you don't even have to worry about pointers referencing to free'd memory.
It would also have been nice if this
Oh, well: it's Slashdot after all. What was I expecting. Sigh.
42.
This is because the .dll file does not contain any information of .h files being used during the compilation. And I hope you can change the "effect" of an .h file by defines in other .h files. So, one would have to examine the preprocessed files to determine whether the interfaces would match. The evil of preprocessing is that you lose all kind of information that is essential for the kind of type-safety that you would like to have in an environment where you make use of libraries.
And this problem is not specific to DLL files on MS Windows, but also occurs on other platforms where shared libraries are in use and the libraries do not contain an explicit interface definition that can be validated. (And we all know that a simple version number is not sufficient for interface validation.)
it's called C++0x for now because it hasn't been finalized yet. When it's finalized, as expected in 2009, it will be C++09, just as when the last revision was finalized it was C++98
Most languages are revised over the years, deprecating some things, adding others.
Java, for example, has deprecated and added HUGE numbers of features and classes, and there've been many more official/standard versions of it than there have been of C++
Inconceivable!
While C++ is more strongly typed than C, C++ is not type safe. Type safety means that the language ensures that no operation will ever be applied to a variable of the wrong type. However, C++ supports the ability to access arbitrary memory locations, allows type casting, and automatically converts types in many instances. Java is more strongly typed than C++, as it doesn't allow access to arbitrary memory locations, but it also supports casting and automatic conversions, and so is not type safe. If you want type safety, try a language like Ocaml or SPARK Ada.
The problem with preprocessing is that you never can establish a reliable relation between the interface definition (.h files) and the compiled code (.exe or .dll), because the compiler does not know which .h files where used after preprocessing has taken place. And I hope you realize that the used of #defines in one .h file can change the definition of classes in another .h file. So, even in a collection of .cpp files that compile into a library or executable, it is possible to introduce "bugs" due to miss-alignment of member variables that are very hard to find. Preprocessing as it is done in C (and C++) is simply bad. But I guess that most people don't realize it, because they have become used to it.
What you say is true for C++98 templates, but C++98 templates are not the same thing as C++0x template concepts. C++98 templates grants you to use any member (function, typedef, variable, etc) of a type, but C++0x template concepts does not allow you to use any other member than those specified in the concept of a type.
No need, the Unix way is not to compicate a program with features but instead to combine another small tool with it to together achieve the functionality. There are quite a few things around that could do this for you, Make, Ant, etc or even just the shell.
DIR=/usr/local/strange_module-2.3.7
CFLAGS=$(DIR)/include
LIBS=$(DIR)/lib
Also GC doesn't solve memory leaks. You just leak it in different ways. It probably makes it worse since it just encourages sloppy resource management.
Along these lines, one problem I am aware of from my C++ days is this:
The caller allocates the memory for a new object. The class code initializes the data members. This is ok if everything is compiled together.
But if you use shared libraries, and you change the class to contain more or fewer data members, you must re-compile all the calling code.
So much for data hiding.
You can work around this limitation by providing functions or factory class methods in your shared library to do all your constructing, but this is extra work.
"We can't solve problems by using the same kind of thinking we used when we created them." -- Albert Einstein
There has been a lot of talk about getting rid of C++ altogether. I can't help but think C++ will continue to be used (and with good reason) by many schools and universities. Being such a low level language, C++ does a good job at teaching one about memory and computer architecture while also teaching principles of programming. Learning C++ with help one with a computer architecture course and vice versa. It is also a nice transition language between learning a programming language and learning assembly programming. Do we really think it will be gotten rid of? Just a thought.
When Objective C has templates then maybe I'll look at it.
With C++ I can write one piece of code that can process pixels with 8 or 16 bit integer channels or 16 or 32 bit floating point channels. Fanboys of Objective C and Java are obviously not writing image processing software.
Without such important features as operator overloading, constructors, stack-based objects, and references, I really can't take Objective C seriously. I can't imagine it being used for much mission critical software, that's for sure.
You know, as excited as I am about a new C++, when I looked at some of the code Bjarne offers up as an example I have to say that I feel a bit underwhelmed.
I know all you C++ guru's out their are just IN LOVE with template classes, but you should pick your head up every now and then and look at how other languages are tackling the issue. Other languages offer the same inherent functionality in MUCH cleaner ways at the expense of a little CPU. You already have RTTI, use it, and save us all the pain of debugging a class with 4 template parameters (which themselves are probably templated classes)....
Don't even get me started on the useless error messages heavily templated code causes the compiler to emit.
td
hard core geek-ware
Actually, the correct pronunciation will be "See Plus Plus".
:-D
As soon as some buzzword-compliant HR department gets a hold of this, they're going to be sending job-reqs to dice through stupid non-tech headhunters. They'll want someone with 10 years of C++0x experience (C++ is insufficient now) and who's willing to take a retarded online test to prove it. How many times have you heard a brain-dead recruiter spell out acronyms that are usually pronounced or pronounce acronyms that are usually spelled out? I vote for Cocks. At least it's a word bimbo T&A recruiters will understand.
Disconnect your television. Do your own research. Draw your own conclusions. They're probably lying. Don't be a sheep.
Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas!
Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas!
Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas!
Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas!
Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas! Lambdas!
It is tedious, inefficient and unclear to define a functor for single-use transformations, away from where the code is actually used.
C++ is already a multi-paradigm language.
Add some functional concepts while you're at it.
Your DLL problems are a problem of Windows, not of C++. C++ does not try (nor it should) to fix Microsoft's architecural problems. C++ just tries to be as powerful and the least intrusive it can be.
I often find that programming with C++ for Windows is mostly programming for Windows, with a ver little tiny bit of C++ thrown in to bind things together. Expanding on the reasoning on the first paragraph, it seems C++ succeeds admirably well on this.
My USD 0.02
http://www.dieblinkenlights.com
Sorry for rather long and muddled post, and also for my poor English... Also, if you have allergic reaction to Lisp advocacy, don't read any further.
Some years ago when I had some spare time I was struggling a lot trying to make C++ a better language. I was trying to reinvent reflection, easy serialization, extend metaprogramming facilities and so on. My hopes were mostly in http://www.boost.org/">Boost C++ libraries.
At some point I've decided to try to write some extended metaobject generator, like Qt's moc, but friendlier to "modern C++", using GCCXML. In addition to generating reflection info, I was thinking of generating proxy classes and other stuff like this.
Among other things I've tried to do some of XML translation work using XSL (i.e. XML AST from GCCXML -> some more AST convenient XML representation -> (transformation) -> resulting metaobject AST. I've discovered some interesting things about XSL, e.g. that it's possible to "emulate" iteration (which is somewhat lacking in XSL) with recursion. Nevertheless after a few days of fighting with XSL I've decided to try some language which is more suited for processing various trees. Of course, when C++0x is ready, I thought, it will be the best language in all respects, including tree stuff, but as of now, STL+boost::lambda+whatever is still somewhat quirky (for instance, look at those 10 pages long error messages when you make a typo). So, although I was heavily influenced by standard myth-based mindset concerning Lisps (slow, interpreted, purely academic, "lost in a sea of parenthesis" and so on) I've decided to give Scheme a try, as I've heard that it can be used as a better XSL.
After playing with Scheme for a while, I've found out (to my surprise) that the language can be used for many other purposes besides list (tree) processing and simple scripting (as in Gimp). As an example, there are wonderful things like Scsh. It's possible to write Web applications, many Schemes can do OO. My deep respect to C++ (The Most Powerful Language Ever) began to fade, albeit slowly.
So I've begun to try to do some real things in Scheme. Disillusionment has come rather quickly due to the fact that a lot of critical stuff in Scheme (e.g. OO and packages) is not standardized and thus is 100% non-portable between implementations. Moreover, every implementation has its bugs and limitations, and when you come to the point when you need to change your implementation you discover that most of your code needs to be rewritten from scratch.
I was nearly ready to continue developing my "metaobject generator", pushing Scheme's role back to "better XSL". But something made me try Common Lisp before doing so.
What quickly became apparent to me from my CL experience is that most of problems Boost guys are fighting against are just plain nonexistent for Lispers. Look at this, for example: variant.hpp. A good workaround for C++ typing model. What do we have in Common Lisp?
(sorry for mangled indentation)
Now look at this beauty: boost::lambda. Don't forget error messages it produces when you mistype something or stumble across a bug. CL example?
Not to mention Lisp's GC versus boost::shared_ptr.
OK, these are areas where dynamic languages like Perl, Python and Ruby, and even statically typed like C# or Java are catching up to some degree. Now let's look at some CL's more-or-less unique features.
You bring up an excellent point about the rigidity of C# generics constraints. One of the crucial features of the proposals for concepts in C++ is retroactive modeling, which allows you to adapt to the specific syntax of a concept *without* changing your data type. So the problem you mention for C# generics is not actually a problem with C++
// the type of values on the stack
concepts.
Here's an example. I'm writing a concept for a Stack, which might look like this:
template
concept Stack
{
typename value_type = S::value_type;
void push_to_top(S& s, const value_type& value);
void pop_from_top(S& s);
value_type& get_top(S& s);
bool is_empty(const S& s);
};
I picked some silly names on purpose. Now, std::stack doesn't match the syntax of this concept. So what if we try to pass a std::stack to a function like the following, which expects something that is (we use the term "models") a Stack?
template
void clear_stack(S& s)
{
while (!is_empty(s)) {
pop_from_top(s);
}
}
It's going to fail to compile, because std::stack does not match the syntax of the Stack concept. If C++ concepts had the same restrictions as C# generics in this regard, we would be stuck writing an adaptor class. Yuck.
Retroactive modeling saves the day. We can fix the problem by writing a model definition like this:
template
model Stack >
{
typedef T value_type;
void push_to_top(std::stack& s, const T& value) { s.push(value); }
void pop_from_top(std::stack& s) { s.pop(); }
value_type& get_top(std::stack& s) { return s.top(); }
bool is_empty(const std::stack& s) { return s.empty(); }
};
In this model definition, we're meeting all of the requirements of the concept by providing function definitions that transform the syntax of the Stack concept (pop_from_top, is_empty, etc.) into calls to the std::stack itself (see the function bodies). Now, when we call clear_stack() with a std::stack, it "just works": the calls to is_empty() and pop_from_top() in clear_stack() go through the model definition. Of course, if we picked more standard names and member functions in our Stack concept, the model definition could be empty or (for implicit/structural concepts) omitted entirely.
Retroactive modeling is *really* important for making it easier to reuse template code. You won't need to be paranoid about matching syntax *exactly* with every concept you need to model, because the compiler will detect any mismatches and you can fix them through a model definition---without having to change the data types, templates,
or concepts. Of course, people will still try to agree on names and concepts when possible, because it saves typing. You can check out the actual proposals before the C++ committee (references follow) for more information. There are two active proposals, but the groups are working together, so expect a final "combined" proposal in the future.
There are other differences between C# generics and C++ concepts. Before starting to design concepts for C++, most of the authors of one of the concepts proposals (N1849; see below) did an extensive study of the generics facilities of several languages (e.g., C# generics, Java generics, Haskell, ML functors, C++ templates). They ran into trouble with every language they tried, and we designed our C++ concepts to avoid those problems. Here's the original paper; there's an extended version (with more languages and more detail) under review:
Ronald Garcia, Jaakko Jarvi, Andrew Lumsdaine, Jeremy G. Siek, and Jeremiah Willcock. A Comparative Study of Language Support for Generic Programming. In Proceedings of the 2003 ACM SIGPLAN conference on Object-oriented programming, systems, languages,
Windows is like decaf - it tastes like the real thing, but it won't get you through the day.
We italians are quite creative with the english language... just another way to say that we invent new words when we don't know them off-hand. Strange enough, the word "constness" exists, and it's a perfectly legal one in English. You can even google for that! :-)
Maybe also English people invent new words when they don't exist. ;-)
42.
Here is the complete Common Lisp secification:
PROGRAM:= ( STATEMENT )
STATEMENT:= ( STATEMENT ) | CDR STATEMENT | CAR STATEMENT | CONS STATEMENT STATEMENT | NAME
NAME:= [a-zA-Z0-9]*
Reason: Don't use so many caps.
Reason: Don't use so many caps.
Reason: Don't use so many caps.
Reason: Don't use so many caps.
I like most of these additions, though I wonder why they're not just standardizing the (currently nonstandard but widely supported) STL hash containers for hash tables. Regexps are also already in the language in the form of a POSIX library (regex.h), though I don't think MSVC++ supports that, and the regex library could definitely become more user-friendly.
:)
The "auto" keyword being used to automatically determine the type of a variable sounds like it can cause no end of trouble, especially when using polymorphism (will auto give you back a pointer to the base class or the derived one? What if the function isn't virtual? etc.), so I probably won't be using it in my future programming.
Garbage collection AND dynamic allocation via new/delete together? That ought to be interesting... and probably very dangerous
The "using" thing after the template definition seems pretty useless and confuses the template declaration with potentially unrelated aliases. Why not use a typedef further down in your program?
Concepts were something I wanted to see in the language from the first day I learned about templates. They should make debugging template issues much easier. I'm glad to see that they're considering them.
(I didn't write the AC post above) You are getting silly now trying to defend your point. Please google for "duck typing".
.zero() method.
You can't add methods to primitives (in C based languages, anyway) but because of operator overloading there are still options available. In fact combining Operator overloading and templates is quite cool:
template<class T> T min(T a, T b) {
return a<b? a : b;
}
ie this would work for int, float, as well as your own matrix class (if you implemented operator<).
I once made a container that returned the average of all the objects in it (all things I hadn't made myself eg float, int, short, matrix, 2D vector etc). To do this you need to somehow reset a counter to zero, which is pretty hard if eg the matrix class can't accept an assignment constructor of 0. The solution of course is "*= 0", which works assuming that has been defined.
The only way to do that in C# would have been if someone had the foresign with all of those classes to have added a virtual
As a systems language, right now, no. But there is some really interesting-looking work on the MS Research page (the Singularity project, if I remember) with using it as that with some crazed tools they have, and exploiting the features of "safe" languages to make a different sort of system.
As for "C+=2", have you looked at Objective C? I believe that its general purpose is to provide a "better" OO implementation, although I've never used it myself. That said I think it runs all C code (where C++ does not) so possibly not all that OO from the ground level...
Syntactic sugar for getters and setters can be useful for providing a more natural interface (as long as people don't abuse them), but they don't really have any place in a language like C++, where almost everything is set in stone at compile time. Properties work well in dynamic languages like JavaScript because the binding takes place at runtime, at the very last moment before the member access is resolved. The code to access a plain member field vs. a property is quite different, and in C++ this must be generated at compile time.
The upshot of this is that you can't change a field to a property and vice-versa while retaining binary compatibility. This means that you've essentially added a gotcha to the language which everyone must be wary of when designing their public interfaces. While a.b = c looks a bit prettier than a.setB(c), in my opinion it's better to be explicit about what's going on to avoid problems down the line.
Blocks are just anonymous functions with closures, so ruby and python are equals? But python doesn't have proper first class anonymous functions with closures. It only has a half-assed crippled version that is supposedly being removed in python 3. So clearly python is missing functionality that languages like ruby and pike have.
The problem sound rather like "linking an incompatible library version" than header problems occuring through use of the C++ preprocessor.
.h file by defines in other .h files." was a typo.
Java can have the same problem since it links in EVERYTHING at runtime. Put an outdated class in the classpath before or instead of the correct class and you've got a problem.
I don't think any other language handles the situation any better.
The only way to "fix" this is by doing some sort of version-number (timestamp?) checks, the mechanics of which aren't dependant on a specific language or it's features.
I still don't see how this problem is caused by the C++ preprocessor though, perhaps an example would help?
p.s. I hope "And I hope you can change the "effect" of an
Slashdot social media options: AIM, ICQ, Yahoo, Jabber and Mobile Text. Why no MySpace?
for (vector > p = v.begin(); p!=v.end(); ++p) cout >::iterator p = v.begin(); p!=v.end(); ++p) cout *p endl; Hot damn, somebody get me a cookie, I found a mistake in Bjarne Stroustrup's code!
<xml><I><am><so><damn>Web 2.0</damn></so></am></I></xml>
They don't have writers the caliber of Guy Steele or Kent Pitman, so it'll still read like gargling razor blades
Their legacy syntax straightjacket will insure the code stays verbose and hard to read. Compare:
struct ltXMLCh {
bool operator() (const XMLCh* s1, const XMLCh* s2) const
{
return XMLString::compareString(s1, s2) 0;
};
};
with
#'string<
or (comparing apples to apples):
(lambda (s1 s2) (declare (string s1 s2)) (string< s1 s2))
To a Lisp hacker, XML is S-expressions in drag.
Here are some tools that allow you to combine interface declarations with the compiled code. Both tools automatically write the header and source files for a module given a single unified file.
s s/
Preprocess - http://os.inf.tu-dresden.de/~hohmuth/prj/preproce
Lzz - http://lazycplusplus.com/
Both tools are open sourced. Of the two, Lzz is quicker and has more backwards compatibility with existing C++ code.
No one has used C++ for any major operating system,
t ml
Windows XP, NT, 9x. See: http://public.research.att.com/~bs/applications.h
and no one has used C++ for any hardcore military project.
I'd beg to differ.
-everphilski-
Not to add a pointless "me too", but I would also agree with this. I'd just like to add that this massive time for dealing with types does make C++ very unwieldy for quick prototypes if you just want to test an idea. To that end, I find the common approach of prototyping or doing quick utilities in python, and re-doing mission-critical stuff in C++ to be a great compromise.
Can you imagine what a C++ lambda construct would have to look like?
(lambda (x y) (- y x))
would turn into a mess like:
int lambda(int x, int y) { return y - x; }
And that's a trivial one...
To a Lisp hacker, XML is S-expressions in drag.
I also end up looking silly by placing paragraph break HTML on other sites I post. Everyone around Slashdot (just like -- name favorite feature -- C/C++) programmers gets in the habit of using proper paragraph breaks, but it is entertaining to watch a noob make a long post, or perhaps an old timer who has passed some brain gas, make a honkin run-on post.
I guess Slashdot could fix this and accept whitespace as a paragraph break, but I guess that would violate some deep principle. But I am not blaming Slashdot -- it is deep in the software developer culture to accept things the way they are and then holler at the newcomers about their mistakes brought on by the fractured syntax. How do you think the C syntax has become so viral?
it would do assembler, C, C++, and higher than C++ level
IMHO those four languages are better unified - that gives the programmer the most control.
Have you heard of the D language? It's not C or C++ precisely but is pretty close, has provision for using C APIs, has assembly, more function/object features and is easier to make more reliable code - see features kept and features dropped from C++:
D Programming overview
"With C++ I can write one piece of code that can process pixels with 8 or 16 bit integer channels or 16 or 32 bit floating point channels. Fanboys of Objective C and Java are obviously not writing image processing software."
s . Could have found a lot more stuff, but can't be bothered just to provide even more proof of the fact that you are talking utter crap.
And C++ fanbois are prone to assume silly things about other languages from what somebody they agree with says about them. As an example of this, the fact that Java has templates seems to have escaped you.
As to image processing:
Objective C: http://en.wikibooks.org/wiki/OsiriX_Specification
Java: lots of examples here, as Sun's JAI (Advanced Imaging API) is specifically designed for image processing. Google is your friend.
People are also doing image processing in Python because it is used by lots of scientists, and image processing is something they do. And of course good old venerable C, which completely lacks all the "++" bits which you seem to think are necessary for writing any type of software.
"Without such important features as operator overloading, constructors, stack-based objects, and references, I really can't take Objective C seriously."
And these are necessary to write software because... Oh, that's right, you need a Turing complete language to write any conceivable piece of software, and what's that? A language can be Turing-complete without having any of these? What strange heresy is this?
"I can't imagine it being used for much mission critical software, that's for sure."
It seems you are incapable of imagining lots of things that exist, but that's your problem. For example, one thing that has escaped your imagination is the fact that C++ is far from being the language du jour for writing mission-critical software: the bulk of what can truly be classified as mission critical (i.e. extremely high reliability stuff where lives are at stake such as medical embedded systems, aerospace, real-time operating system kernels, etc,) are written in C or Ada, usually with a liberal sprinkling of assembler. How can this be when these languages lack all of those amazing features that you insist are necessary for them to be taken seriously? Is it possible that they are missing critical pieces of functionality that can only be implemented by using references to pass parameters? Maybe you should tell them!
I'm not going to change your sheets again, Mr. Hastings.
C++ is going to change into ocaml or Haskell...
It worked for Common Lisp!
No, really. Maybe what they realized was that C++ is an evolutionary dead-end. And how do you get people to stop using a language? You can't just abandon it -- they'll keep using it. So you "upgrade" it by adding tons of new features. Geeks will be forced to upgrade, because their egos (or their bosses) won't let them use old versions. Eventually the language will be far too complex for even the most hardcore C++ hackers to understand, and they'll switch to something else.
I will never cease to be amazed at how so many people can see "they're moving in that direction!", and interpret it to mean "they must want to go there!". Don't you people ever play sports? Oh, right... Don't you people ever fence, or do martial arts? Half of the art is convincing the other guy that what you're doing isn't what you're doing.
Get off your soapbox. Some of us like languages that actually have syntaxes and can really do low-level work.
It is very likely that the sugary-syntax language you use is glued to the standard C library to meaningfully interact with your system, assuming you are using a *nix system. I cannot vouch for what goes on behind a Windoze machine. You must be a Python programmer. That is ok. It is a lot better than being a VB programmer. But Python has nearly reached the precipice to oblivion that Perl reached a few years back. It is out of vogue. Go back to the classics. Try guile! You can link C libraries in the same way. I do admit I am hoping for a renaissance for the Lisp languages in 2006. As for the elegant and necessary Lisp parentheses, just use Emacs show-paren-mode and you will never be bothered by matching ')', '}' or anything else.
an ill wind that blows no good
#define foreach(x,it) for(typeof((x).begin()) it = (x).begin();it!=(x).end();++it)
This can be done because typeof is implemented in the GNU C++ extensions, but not in standard C++. Why not begin with a handy feature such as this?
Here's the two features I want:
unsigned, signed, signed, etc. The built in types should have size specifiers and all use the same names. The whole thing about incompatible long size is confusing and unnecessary. This also lends itself to hardware programming better. You could have an unsigned (i.e., seven bit number) handled by the compiler just fine by building in checks on the eighth bit of a byte instead of relying on the carry flag. It would be a wee bit slower, but still useful.
The second feature is some fixed data types. fixed would have sixteen bits for the whole number portion and sixteen bits for the decimal portion. unfixed would be an unsigned version of the same thing. Why do we need this? So that I can have a freakin cross-platform video and image library. libjpeg runs faster on my local box than on the $13k SGI box in the lab. Why? A nice fellow wrote the thing in fixed point MMX assembly and the Itanium chips don't have 32bit MMX support so it kicks back to the floating point overload of the DCT function. Shifting would also work directly on these fixed point numbers. I'm also a fan of making it so that shifting a floating point number inc/decs the exponent.
"No one has used C++ for any major operating system"
OS/400 was re-written from scratch in C++ in the mid-90's. It's the most robust (but least fashionable) OS in the history of computing.
Nothing on the scope that C++ is talking. The inline functions is syntactic sugar, we already had macros. Nice syntactic sugar, but still sugar. Complex numbers already existed, there were dozens of libraries that did them and did them well. Read the list of changes for C++, its a major turn in the language.
I still have more fans than freaks. WTF is wrong with you people?
Well, I wouldn't go so far as saying that C# or Java is more "modern" than C++ (Which is kinda stupid...); but to say that C++ is "well engineered"...
C++ is well engineered in the same sense of PL/I was well engineered- and it's becoming as complex and convoluted.
"Over engineered" would be a better description- and I'm a proponent of the language.
I am not merely a "consumer" or a "taxpayer". I am a Citizen of the State of Texas
"Your DLL problems are a problem of Windows, not of C++"
To be fair, it can also occur on UNIX (a catch-all category which should be read as including Linux) with shared objects. But you are right in saying that this is not a C++ problem as such: shared libraries / DLLs are features of particular OS families that should not be specifically supported by a general-purpose programming language like C++.
NB: I share the general consensus that C++' handling of modularity leaves a lot to be desired. In particular, the loose coupling between headers and source modules together with the ability of any header to redefine the values of constants etc. imported from prior headers is both a potential and actual source of problems. I can understand C++ _supporting this_ for compatibility with C, but Bjarn should IMO have added another better system for use with new C++ code. If something like this had been done properly from the beginning, then they wouldn't have had to retro-fit name-spaces at a later date, because the module name could have also served as a name-space identifier, as was the case with Pascal and Modula-2, later borrowed by more modern languages such as Python and Java.
I'm not going to change your sheets again, Mr. Hastings.
Instead of tacking more features like threads onto an already bloated language, how about making some options that would make C++ codes more debuggable. I would love to have a compiler option that forces strong typing ala Ada in my codes. No automatic type conversions. No default constructors or operators to my classes being built. I would also love a sane I/O syntax. And while you are at it, please simplify the STL API. I know I am just being cranky but I would be surprised if there are a dozen people on the planet that understand the complete C++ standard as it is.
The truth is an offense, but not a sin.------R. N. Marley
I just read through the article and I must say that I am excited. The changes that they are proposing are so awesome. Each one is something that has frustrated me that C++ does not already do. Must of the past changes of C++ have made it much more complicated. They were good changes, but they did make the language more complicated. Apart from concepts, these proposed changes seem to make things simpler. I especially like the "auto" type. What a brilliantly wonderful idea. This is something that I have longed for. I love it.
Using the assignment library this is easy.
// for 'operator+=()' // bring 'operator+=()' into scope
// insert values at the end of the container
Here's an example from :
http://boost.org/libs/assign/doc/#operator+=
#include
using namespace std;
using namespace boost::assign;
{
vector values;
values += 1,2,3,4,5,6,7,8,9;
}
This, it seems, is not the way it will be implemented in the new C++. But lots of other stuff mentioned is already in boost (smart pointers, threads).
That said, if you're using gcc and GNU make, you may prefer the following:
/usr/local/strange_module-2.3.7
PREFIX =
CPPFLAGS += -I$(PREFIX)/include
LDFLAGS += -L$(PREFIX)/lib -R$(PREFIX)/lib
Most people forget the -R and assume that ${LD_LIBRARY_PATH} will be set appropriately by the users. IMHO, that's just dumb.
Of course, the example above is not very good if you're also building the strange module's library at the same time as the executable. But I'll leave *that* solution as an EFTS.
Do daemons dream of electric sleep()?
What exactly do you mean?
C already has int8_t, int16_t, int32_t, and int64_t. Is that what you want?
There are various template hacks where you specify some_typedef<32> and it will give you an integer with at least 32 bits. Is that what you mean?
I'm a bit confused as to what you are asking for. For the most part, these problems are already solved in ad-hoc ways. It would be nice to have more of a standard, but the problem with new standards is you still have to get your code working on stuff that doesn't conform to them. That's one reason I'm reading this whole article/dicussion with a grain of salt; because I know it'll be 10 years or so before these changes are actually mainstream.
How much is "much"? C doesn't have all of those important features, yet it is the backbone of much mission critical software. Maybe by "take seriously" you meant "consider optimal" and by "used" you meant "preferred"?
...C++ is doing it via first evolving into Java 1.0.
So slowly C++ will become Ada? Are there really any substanive differences in Ada and C++0X other then using "{ }" vs. using "begin end" and simalar trivia? Ada, BTW is still very much in use but that use is restrited to a small range of applications. mostly to applications where people will die if there is a software bug like airplane flight control, guidance systems for cruise missles, nuclear power plants and so on. Not many web browsers are written in Ada. I think what kiled Ada for general use is a lack of a huge set of _standard_ libraries. C, C++ and Java and the other hand are populare because of thier libraries
If you're interested in reading about possible future extensions to C++, check out the official home of the C++ Standards Committee. The papers page links to all the "mailings" containing every paper submitted to the committee, as well as draft standards and such. There's a lot of interesting ideas floating around: true "metacode" macros (like Lisp), flexible initialization (so that the {...} initializer could be "overloaded" on your own classes), automatic type deduction, etc.
I agree.
Bjarne Stroustrup seems to be the only person who has the mental capacity to guide the development of C++. However, he is taking a very leisurely view of improving the language, in my opinion. We need those improvements 8 years ago.
Java is attractive, but writing in it means getting involved with Sun's mismanagement, which is so bad it may eventually kill the language.
C# is attractive, but using it means being under the influence of Microsoft, a company which is often adversarial toward its customers.
As in other fields, we suffer greatly because of the poor quality of our leadership.
Assuming of course that I want to put a lot of complex data into my code rather than load it from XML or a database, I would seriously consider creating the XML files anyway. That would make switching to loading XML at runtime later a bit easier if I had a change of heart. Then I'd write some XLST to generate the C++ initialization from the XML source. Not that I expect any of this to change anyone's opinion on whether this is a shortcoming of C++ or whether it should be considered as a possible new feature.
Someone else asked why you would want to hard-code complex data. I can think of a couple of reasons. Sometimes your data is essentially static, but isn't composed completely of built-in types. State tables are a rich source of examples. In an embedded system, you may be hard-coding all sorts of things that could be expressed in a database or XML, but you can't afford the storage for the libraries and the database. Finally, if you need to write a small program that loads fast to do a quick job, you don't want the program to load and then have it read it's configuration from somewhere if that configuration is static.
The net will not be what we demand, but what we make it. Build it well.
I think C++ wants to be a low level language that can also do high level constructs.
t /boost/bind/mem_fn_template.hpp?rev=1.7&view=auto) .
And I do think this is a great goal, a goal that not many languages are able to do well.
Actually I don't know of any other language that allows you to type raw assembler and at the same time use higher order functions like boost::bind (http://www.boost.org/libs/bind/bind.html).
(Please not that C# and D delegates don't have all the features of bind, that is binding any argument to a precomputed value, not just the first argument).
But while the low level programming in C++ is good, writing high level functionnality is still very complicated. Just have a look at the code at the previously mentionned boos::bind and you'll probably run away (http://cvs.sourceforge.net/viewcvs.py/boost/boos
After reading the article, I understand that they are willing to fix this issue, at least partially.
But there are many other issues that preclude it to be really "comfortable" to use as a high level language :
Some of them are old issues, already solved many years ago by a lot of languages like parent post said (introspection (compile-time and run-time), modules, lambdas...).
Some other issues are old but require some carefull thinking to integrate well with C++: multi-methods, garbage collection, mixing functional and imperative programming...
An finaly there are new needs arising like compile-time code generation, aspect-oriented programming, multi-process programming, interfaces (as in the Heron language or the boost interface library, not Java interfaces)...
Of all these features, very few will be added in C++0x.
Other C++-like languages do offer these features or a subset of them.
Here is a short list for reference :
D : http://www.digitalmars.com/d/index.html
Heron : http://www.heron-language.com/
Boo : http://boo.codehaus.org/Language+Features
Nice : http://nice.sourceforge.net/
etc.
But to my knowledge none of them has fully succedeed in offering both a good low and a good high level programming, while keeping the zero-overhead principle of C++ (that is: if you don't use a feature of the language, you don't pay for it).
Seeing this situation, I'm afraid we have only 2 options :
1- split programs into 2 parts: high level and low level, and use 2 different languages for these parts.
2- create a new language
Actually, this is already happening:
I see more and more programmers using high level languages like Python and doing some system or high performance routines in C (with Pyrex for example) and then glue them together.
The languages I mentionned before (D, Heron, etc) are an attempt at creating a successor of C++ but IMHO they are not mature enough and/or feature complete.
So... I forsee option 1 will become more and more comomon for years to come, until we hit option 2, because I think C++ will not be fixed.
"Oh dear God! It's growing bigger!"
Clearly, intellectual bitch-slapping at its finest!
Cheers
I got tired of complaining about C++, and decided to do something about it. The result is the D programming language.
A compiler switch to turn off many or most all of the language extensions differentiating C++ from simpler OO languages (Java, C#) so that I can force the developers and myself to write simpler code.
preprocessor metaprogramming. It's a very powerful tool
"powerful" in the sense of "as powerful as a Turing machine", I suppose.
Template/preprocessor metaprogramming is a horrendous hack. It basically happened by accident because the addition of templates "upgraded" the compiler to have a Turing-complete language embedded within it. Not that anyone realized this while they were actually *designing* templates.
Well-designed "metaprogramming" would use, get this, a programming language, with sane syntax, not the mess that template syntax is; C++ was already so crowded with line-noise operators, they had to separate less-than signs with spaces. It would also have real programming semantics, instead of hijacking the type system to provide flow-control.
Lisp basically got this right, by allowing meta-programming to use the same language and operators that the underlying language has.
The problem is that you are forced to use textual inclusion to build pretty much any project bigger than a single source file. There isn't a real module system as in many more 'academic' languages like Modula-2. What I mean is: suppose you would like to use libpng in your program. So you #include the libpng headers. Purely as an internal implementation detail, libpng happens to use zlib. Its header files #include some of the zlib things, which means that zlib is now dragged in at the top level even though you did not ask for it. Ideally, the zlib functions should be available only in the libpng source files that asked for them, and if you separately wanted to use zlib (perhaps a different version) in the main project you should be able to do so without needing to know or care about whether libpng also uses it.
Also as the UNIX-HATERS Handbook notes:
In other words it is very hard to write automated code browsing tools or refactoring tools for C and C++ because you can't parse a given source file without textually expanding it (and thus dragging in megabytes of headers). Things like etags are only approximations. I guess I'm contradicting what I said earlier: the mere existence of the preprocessor is bad, because it makes life difficult for IDEs and code browser tools. There are some good points to the preprocessor, but in this day and age when any compiler can do inlining, not many.
-- Ed Avis ed@membled.com
The Borland of today seems better than the Borland of before, but I got scared by Borland's previous bad management.
KDE is open source. All KDE libraries are either LGPL or BSD. The Free edition of Qt is GPL/QPL. All of those previously-mentioned licenses are OSI-approved.
Please keep your stupid anti-KDE FUD elsewhere.
I can't believe they're putting still more lipstick on this pig.
What you have just described is Apple's Frameworks This might work on other systems with gcc aswell. Since I got my first iBook and learned about frameworks, I've pondered, why the heck doesn't any of the linux distributions use them.
The goal of C++0x is not to add a bunch of new features to the language.
Two of the driving goals of the committee are to prefer library extension
to language extension and to focus on simplifying current features.
Remeber that the standard library specification is a major part of
the standard. And standard library extensions are very different than
language extensions.
The actual "new features" that the Bjarne was discussing focus on
simplifying and streamlining current features and syntax. For example,
while template typedefs and auto iterator types are language
extensions their goal is to simplify a current language feature: templates.
The possible exception to this is the addition of "concepts". However,
information about the design of "concepts" is so sparse in that article
that it is difficult to form an opinion.
Jake
Spoken (Natural) languages are extremely complex and extremely useful. Programming languages can profitably be just as complex if they were good enough to last for as many decades as we use natural languages! If you're going to learn a new language every 5 years it constrains how complex that language can be. If you're going to use it for 50 years it's a different story. C++ isn't good enough to use for enough years to be worth the complexity.
Nevertheless, the choice of programming languages should not determine whether the app is garbage-collected or not. Although that will greatly impact libraries.
C++ is a research language that should be replaced by something that is not afraid to be incompatible with it. Java and "D" are nice tries but tie garbage collection to the language. C# is disappointing considering the size of the organization behind it. And is also tied to GC.
Software systems often contain components that need to be coded close to the machine to obtain maximum performance or flexibility or power. At least the OS. Those same software systems always contains portions of glue and convenience code that does not need to be coded close to the machine and should be coded at as high a level as possible. The challenge to language designers is to create a programming system that spans as great a height as possible without forcing the coder to migrate to different syntaxes and toolsets. C++ and OO are an attempt but don't really make it.
I18N == Intergalacticization
// 6 lines in Java, not sure if the code does exactly the same
import javax.swing.*;
public class F
{
public static void main (String[] _args)
{
JDialog form = new JDialog ();
form.add (new JButton ("Hello, World!"));
form.show();
}
}
Million Dollar Screenshot
Or is it you? Show me a piece of code that runs faster with a C compiler than the same piece of code with a C++ compiler from the same manufacture. Maybe you don't understand that if you write code that doesn't use the "slow" features of C++ its the same speed as C. Even then when you use virtual methods, compare them to the performace you get with structures of function pointers in C. Then there are things that acually make C++ faster than C, like for example templates and exceptions. Look up template meta programming on google if you don't believe me. I know of at least 1 compiler that accually generates faster code for the C++ virtual methods can get generated by the C function pointers. I think at this point most of the C compilers out there are acually just C++ compilers with a slightly diffrent parser running on the frontend.
I don't think C++ is now, or ever was (or with the way these "extensions" keep showing up) - or ever will be suitable for Systems Programming.
This is complete and utter BS, I have written a number of drivers using C++ in enviroments that didn't officially support C++. I have also written a microkernel that runs on a number of embedded ARMs in C++. C++ is a wonderful systems programming language, I no longer have to manage function tables, deal with a lot of error handing etc. System calls are a natural place to create a "transaction" that can be aborted by an exception, as are SLIH's the list goes on. I'm not the only one, a number of other people have C++ based kernels and drivers. Writting an OO kernel also encourages you to have interfaces between the diffrent subsystems, this is something linux strongly needs and doesn't have.
cout
cout is in my opinion stupid, and I don't use it, so I don't care if its slow (plus its not internationalized, and hard to convert, unlike the printf family). Plus most people don't understand that it tends to creates temp objects all over the place, and that is what is slow not cout.(this reminds me of Java, which isn't always slow, but it encourages practices that are)
Because the C++ programmer infrequently can understand what his runtime is doing- and is not encouraged to know the interface by which C++ does it's magic (because nobody knows- they're still trying to figure out how to make some C++ magic work in a way that isn't slow)- a C++ systems programmer needs a C++ runtime. Nobody has one in systems-space, so the C++ programmer (which isn't a programmer of C++) needs to write it.
This is utter BS too, it isn't any harder than C, in fact its almost the same as C except for virtual methods, RTTI, and exceptions. The rest is basically all compile time. RTTI is off by default on most compilers because it can slow things down, exceptions and virtual methods usually only take a little while to understand how they work with a given compiler. If its not documented then a few minuits in the RTI and stepping through the call or excption with an assembly debugger should make it perfectly clear. In fact as part of using C++ in a kernel mode enviroment I have implemented a number of C++ startup and basic support libraries, the biggest one was probably 200 lines of code (because you can't include the full C++ or for that matter C runtime for usermode, with C that code is usually already in the kernel so you don't need to generate it again). Mostly it was simply changes like overridding global new and making it call the kernel allocator, setting up the module/driver/kernel load routine to call the constructors/destructors for global objects, and other really simple things like that.
Great. Just what we need. A language that looks like leet-speek for "cocks".
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
I've been programming C++ professionally for 10+ years now in a near-real time field. A few years ago I started using C# for offline things (e.g. tools), and most recently, a domain-specific language for large chunks of the runtime. Some of our team uses C++, some use the DSL. The C++ guys are orders of magnitudes slower to produce results. The primary problem is compile and link time. Getting thousands of C++ files to compile quickly is a fulltime job in itself, and requires thought from every programmer all the time not to #include absolutely everything. (Feel free to respond with "try this!", but I probably have). C#, Java and Python are near instantaneous, and do not require time twiddling includes or forward declarations. If the committee could organize compiler developers to progress C++ away from #include files and towards live code databases (or whatever is required) we will be much better served.
This sumarizes most of the problems I've seen in C++. Many people seem to be under the impression that because C++ is widely used, that it is a good language, or at least well adapted to the tasks it is used for. In reality, of the many many languages I've used, it is one of the most poorly put together and your writeup sumarizes why that is.
I'd like to add why I believe that C++ *is* so widely used.
1. easy access to C libraries. all the critical libraries are written in C, so there's no need to do language bindings (although wrapping some constructs in a class is still smart).
2. momentum. C++ seems/seemed like the natural next step to the many many C programmers out there. Businesses want to be able to hire from a large pool of talent. Also, C is pretty nice as far as portable assembly languages go, and so programmers who developed an afinity for C tend to assume that C++ will be just as nice to work with.
3. templates. templates are a really horribly implemented in C++, really just a glorified macro, but they are still extremely powerful and not long ago they were a feature that other mainstream languages lacked. Now virtually every language has a better implemented Generics. C#'s are pretty nice. See Ocaml or SML for a language with REALLY nice generics.
4. the belief that C++ is fast. As far as *compiled* languages go... not really. C++ may stack up well against Python and Java, but neither of these languages were designed to be compiled directly to machine code (although hacks do exist...). However, C is generally considered to be faster than C++, and Ocaml (a much higher level language which implements garbage collection) is about the same, maybe a little faster. One reason for this is that C++ tends to suffer from code bloat, which causes cache misses, which majorly slows down modern hardware. The code bloat happens because C++ tends to over-inline, any member functions in a header are automatically inlined, and because instatiations of templates are often duplicated.
One feature that would be nice to bring along from C++ to newer and better languages is easy bindings to C. If this happened, probably the largest real reason to use C++ would disappear. Here's how I'd do it if I were adding this feature to language X.
1. Define what primitive types in X are equivalent to what primitive types in C. Define a special syntax for accessing non-garbage collected C structures and pointers (similar to what C# does with com objects).
2. Make the compiler understand how to read function prototypes and type definitions out of C header files. Treat a C header file like a module in language X (assuming X is statically typed and has something like modules in C/Python/Sml/Ocaml or namespaces in C++/Java/C#). Now C functions can be called as naturally from language X as from C.
Diffr'nt strokes and all that; to me, the design of D is practically a bullet point list of ways to undo the things that Stroustrup and co. understood and got right but Java and friends got wrong. The design gives up most of the flexibility and power, in exchange for what? A garbage collector and, in Java's case, an extensive library (most of which isn't very good)?
If you want a higher-level language with a different balance of power vs. safety, there are many much better choices than things like D. On the other hand, if you want the power and you're smart enough to take advantage of the lower-level features in something like D, you're probably smart enough not to make rookie mistakes in C++ and to use the extra tools it offers effectively. I just don't see the target audience for the middle-ground languages. Java was born of hype, C# was born of exasperation with Java, and D was still-born, as you say yourself:
Well, if D is to become even a shadow of what C++ is already, it's pretty much going to have to overcome these fundamental drawbacks. It's tough; obviously a lot of hard work has gone into it. But as I said, I think it's a product with no market, trapped between the more powerful and much more established C++ on one side and the more flexible and productive "scripting" languges on the other, and squashed under theoretically sounder academic languages with better underlying programming models for good measure. You only have to look at the... not entirely representative... features checklist on the D language site to see where the design came from.
Perhaps there is a reason that, as the D site itself notes, most new languages appearing today are either from the academic community and showcasing more theoretically robust programming techniques, or from the business community and based on quick and effective development?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Doesn't the language need LESS complexity? tone
tone
fonbio,
As you seem to have some experience with both, could you try to summarize the main differences between Scheme and Lisp?
C++ in my opinion, one of the big advantage for C programmers, is to better organize the code.
On big projects, we want to know where is the beginning of one object code and start of another,
rather than have to read and analyze all the code.
That should be a good and helpfull thing.
Type Checking is one annoying topic,
when i am developping i dont want the compiler
allways tell me to make a "cast" on basic logic
type checking, because it should be intelligence
enough to help on that.
in my view, all applications should be developped with high level object oriented languages.
One big addition to c++, whould be support for
inline assembling and easily access hardware devices.
Will be wonderfull and cool, make an entire x86 operating system only with c++ objects.
eg. class Screen, class Pit, class Pic, class Hardisk
I think C++, speedup and make easy the
development of large code projects.
What I find amazing about the group of C++ detractors as a whole is how rarely I comprehend the claims put forward about the vaguely defined desirable language ~C++.
r e+Java+isnt/2100-1012_3-5903187.html
5 0,39129961,00.htm
s plus&seqNum=200&rl=1
I think "you don't pay for what you don't use" is a fundamental design flaw of the language.
What is the precise claim here? That the entire language niche of pay-as-you-play languages should have remained empty? That C++ was the wrong language to occupy this niche? That there is a finite set of everyone-pays-all-the-time features that could have been added to C++ without compromising the language's scope or applicability? That any two people asked to write down such a list would produce a non-empty intersection?
Pay-as-you-play enables compositionality: the very idea that libraries like Boost can exist and be 90% as effective as if those same features had been designed into the language. It's the 10% that Boost doesn't achieve that gets folded back into the core language.
One guy was ranting that the true test of cohones is what the designer removes from the language, while another long post was devoted to a laundry list of "how could this language not have all these kitchen sinks so late in the day?" Which is it? You can't have minimalism in all places all of the time. Minimalism to the compiler vendor is a different beast than minimalism to the end user.
Ada had generics in 1983. Yada yada yada. What do you get when you start with a clean slate in 1995?
Does it thrill Marc Andreessen?
http://news.com.com/Andreessen+PHP+succeeding+whe
"Java is much more programmer-friendly than C or C++, or was for a few years there until they made just as complicated. It's become arguably even harder to learn than C++," Andreessen said. And the mantle of simplicity is being passed on: "PHP is such is an easier environment to develop in than Java."
Does it thrill Miguel de Icaza?
http://www.builderau.com.au/program/work/0,390246
The problem with J2EE really is that it became very, very academic and the complexity of all these perfectly designed systems in schools does not necessarily map when you have deadlines and all kinds of other things.
http://www.informit.com/guides/content.asp?g=cplu
When Java designers decided to disallow operator overloading, they cited C++ as an example of the inherent woes of this feature. As usual, they got it wrong, which is why operator overloading is slowly but surely creeping into Java just as generics recently did.
Does it thrill Sun insiders?
http://idevnews.com/CaseStudies.asp?ID=170
Peter Yared, former CTO for Sun J2EE app server unit says Java/J2EE may lose out to Open Source technologies in the future, as IT managers are architects get tired of the time and cost of building in Java.
The sad fact is that few of the C++ detractors out there could do any better than Java, and Java didn't hit its own sweet spot any better than C++ mapped to its own misbegotten design criteria.
In this respect I would like C++ be more like Java (or TurboPascal for the matter) where interface declarations and compiled code are unified
One thing that Java does well is put the interface to something in its compiled code. This also means that anyone can look into your interfaces from your compiled code. :)
In C, you could choose not to give someone your headersand they could never (easily) use your code, but the other code you distributed which needs it could still use it. Consider a third party library, for example. In my C/C++ days, I often wanted to use a library that another library I was using called into, but I couldn't do so because I didn't have the headers for it.
In Java you can achieve some of this with signed jars, and good use of public/private/protected/etc., but you simply can't give expose a public method in your JAR to one fellow and not to another.
Still, I manage to just fine without this :)
With the exception of ADA and maybe Modula-2, J2SE5 is one of the most type-safe languages I've used.
Java's "typecasting" is not like a C-cast, but rather like a full C++ dynamic_cast with RTTI enabled.
There is a big difference between type-safe runtimes and compile time type checking.
Where pretty much every language other than ADA falls down is their lack of numeric precision enforcement -- it's almost impossible to implement correct calculations in C/C++ without unwinding the statements so you can do correct result truncation after each operation involved. Languages which do such precision checking and enforcement don't suffer when automatic type conversions are performed, because you get told about the overflow/underflow issues.
Don't think for a minute that the C++ "void *" is anything like Java's "Object". The former is just an address/pointer, the latter carries type information.
I do not fail; I succeed at finding out what does not work.
Damn, and we used to just use a plain old text file. Why does everything have to be XEverything these days?
XML is a not-particularly-good implementation of a not-particularly-clever idea, whose sole benefit in most cases is that there are libraries to parse it for you. Then again, if your programming language is even slightly good at text processing, you can do enough reading and parsing to handle most configuration files in a line or two of code anyway, and the rest is just overhead.
Or you could just hard-code data that's not really likely to change anyway, and have a much faster, more maintainable program than the guy who wrote more lines to process his XML than there were in the file he was processing. I'm just sayin', y'know, it's a thought.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Just a note: interface == .h for java. Document all you want, and ship to your customer, along with a crypted jar with the actual binary.
I think I know what you're getting at, but I don't think its quite true.
Interfaces in Java are only used like a .h file once they're compiled. The compiled .class file is what you're actually importing... or rather, the API of that .class file. On the other hand, a header file in C++, IIRC, is inline at compile time as plain text before the compile does anything. Thus, you could include anything text you want.. imcomplete syntactical fragments, for example. In Java, this is not possible. This is essentially the difference between a preprocessor which treats source and includes as text and the Java compiler's treats imports as a way for the compiler to be aware of a pre-compiled API. That is, one happens in the text domain while the other happens in the domain of the compiler's understanding of the parsed source. This is nice in some ways, btu also means you can't do some cool tricks you could do with a preprocessor.
As for the crypted jar file, I'm not sure as I don't use them much. But what I am fairly certain of is that Java uses runtime linking, meaning the actual names of methods and classes is stored in the .class file itself so that they can be linked to the right code loaded from elsewhere by name. So in order for Java's runtime linking, the non-private API of a class must be known to the .class. This is why once you have a .class file, you can run javap against it and get its API. Its just dumping the same information that is used at runtime to match of what one class needs to what another provides.
So, I'd say Java's runtime linking info in a .class file is most similar to what C/C++ header files are used for a good deal of the time, but via a var different mechanism that those includes. Thus, it is much cleaner at doing that job, but weaker at doing everythign else you might do in a header file.
What I started to hate in C++/Java/C# is that there's no easy and standard-conforming way to express complex data 'inline'.
I once worked on a Java programmer (written by a lot of recently C programmers) that had sometime like a Vector of HashMaps, and each HashMap had an element under a a known key that was an Array, and the first item in the array was a Vector of IDs, and the second item in the array was a Map of names to a Vectors where the 1st, 2nd and 3rd items were a crude struct. You couldn't debug crap with this, and even coding was hard unless you had a colorful diagram on your whiteboard explaining what everything meant.
This reminded me a lot of what I used to do with Perl before I started taking advantage of Perl's OO features.
I've often found places where I need to do somethign quick and dirty for a test program and wish I could just use Maps of Arrays rather than defining formal types. But for anything serious, it is much better to just make formal classes for each one. These classes are then types, and which gives not just your language some semantics, but the code you've written now has semantics!
Consider:
(String)((Vector)((Map)((Object[])((Map)vec.get( 0)).get("foo"))[1]).get("email")).get(0)
vs.
customers.getCustomer(0).getContact("foo").getEm ailInfo().getEmailAddresses().getEmailAddress(0)
What are you doing such that you need to put constant data into a vector like that? Is there a reason you're not just using an array?
Vectors have more built-in guards against buffer overflows.
What about Eiffel, Erlang, Haskell, Ocaml (mentioned above), Python (checks at runtime, but also disallows Java's troublesome numeric auto-conversions inherited from C/C++), Sather, Scala, or Standard ML? What about the type safe versions of C, like CCured, Cyclone, and D? There are even type-safe versions of assembly (TAL) and Java (Java_light).
C+=2 ?
In other words it is very hard to write automated code browsing tools or refactoring tools for C and C++ because you can't parse a given source file
Some might say that a command like "gcc -E" would solve this, as it runs the preprocessor stage only, creating a file which other tools can parse. However, that's not a real solution, because the preprocessor depends on -D macros set from the makefile / environment-vars / build-script, which may be arbitrarily complex.
As usual, powerful and flexible software has the pitfall that it cannot be sanely analyzed by another program.
When you're writing software that must be reliable, programming language features like type safety are important too. That's why high reliability systems are often written in languages like SPARK Ada that provide type safety, a fine-grained type system, and even methods for proving your code correct.
I haven't managed to come up with a situation in which you'd want to store so many booleans that you could afford processing power more than extra space, since hard drives and memory are relatively cheap these days.
Classic example is the Sieve of Eratosthenes. Use a byte array and you've multiplied RAM usage by 8. That said, if you really need it, you can probably implement a bit vector in terms of a byte array.
after all you're just calling a function, and add(a,b) isn't much more typing than a + b... right?
At least in Lisp they'd be of the same form: (add a b) vs. (+ a b). Common Lisp fans will be quick to point out that the destiny of C++ and every other similarly high-level language is to reinvent the feature set of Lisp, allegedly poorly.
Well, not for the property thing, I can live without that.
I would kill for a multipass C++ compiler that lets me write classes like C#/Java. With cross module optimisation (LTCG in visual c++), it pretty much needs to do multiple passes anyway, so they might as well have the option.
This would be a major change, so at the same time, I would suggest a tidying of the language to get rid of any syntax hacks (ahem, pure virtual = 0), and anything that's simply for legacy support. I guess you'd end up with a quite different language, which is fine, so why not have profiles like with XHTML (strict, etc), to ease migration?
There are loads of languages I'd like to try, which are going for a lot of the same goals, but they always have a dealbreaker. D looks ok, but then I can't live with forced garbage collection, and there aren't going to be compilers for PS2, Xbox, etc. Therefore I would say that any solution would have to have the possibility of being compiled to current C or C++, like C++ was in the old days.
I want variable-sized stack arrays:
...
void function(size_t size)
{
char array[size];
}
There is no technical reason that this can't be done. Even if you have a type with a destructor instead of "char", there is nothing bad about this. The compiler can store a copy of size for later and iteratively destruct them one by one. That's what would happen anyway if you used new[]. (If there is only one variable-sized array being used in the function, it can actually avoid storing the value entirely because it can deduce it by comparing ebp with esp.) GCC implements this feature already and there are no breaking problems with it.
Another thing C++ needs is a standard implementation of big integers. C# and Java have this. Even Perl has this. It's such a pain when doing cryptography to either reinvent the wheel or use some library with annoying DLL/SO dependencies (GMP).
Finally, someone needs to get on Microsoft's case and force them to implement stdint.h like everyone else has.
Melissa
"Screw Sun, cross-platform will never work. Let's move on and steal the Java language." - Visual J++ Product Manager
Stroustrup writes "This illustrates the most significant proposed C++0x language extension that is likely to be accepted: concepts. Basically, a concept is the type of a type; ..."
Templates brought considerable power to the class idea in C++, but templates are fundamentally a static, compile-time issue, while many things can happen to classes during runtime. For a while now, I've been working on a simulation application (remember when everyone seemed to point to simulation as the major application for C++?) where the type of the input file data elements (e.g. long list of integers, floats, shorts, etc) isn't known until runtime. The simulator uses a pipe and filter architecture, so you'd love to have templates Pipe<D> and Filter<D> where D is the data type, but oooh you won't know that until runtime. And you'd love to make the software future proof for arbitrary types of D. The concepts uh concept discussed in the article look like they could fix this problem. And if they don't, the committee should keep working until they do.
adéu,
Mateu
PS why, when I say the post is plain old text, does <D> still require me to use < and so forth?
"And we're happy here, but we live in fear, we've seen a lot of temples crumble..." - Concrete Blonde
Yeah, try to create a generic class / method in C# that creates an instance of the type it's instantiated with. Oh, and the types constructor takes parameters, good luck!
In C++ the compilers just checks to make sure that everything you do with the supplied type is allowed, in C# you must explicitly tell the compiler what it allready knows using it's own twisted incomplete syntax.
While C++ 98 and C 99 are similar languages, they have many incompatibilities. See http://david.tribble.com/text/cdiffs.htm for details.
You seemed to have entirely missed my point about writing image processing software. While I was talking about writing one piece of high-performance code (using templates) that can deal with multiple image formats (and gets automatically inlined by the compiler) automatically, you countered with using prefab Java LIBRARIES (what language do you think THOSE are written in?) or Python (that also uses libraries written in C++ for high-performance image processing).
The mission-critical reference I was making was to Objective-C's runtime binding of functions. Without the compile-time checking you get from C++, Objective C lets you write code that calls functions that might not even exist.
I didn't mention C at all but since you brought it up - it's possible to write far more robust programs in C++, with less code, than C, so people should really prefer C++ over C in almost all cases.
The topic, to get back on topic, is about C++0x, and any discussion of C++ promotes a flamefest. The parent post to this thread was flaming/whining/ranting about some aspect of C++ while neglecting to use any paragraph breaks, and people piled on to the parent post lecturing the dude/dudette about the need for paragraph breaks when posting.
I was trying to point out a parallel between C++ and Slashdot posting -- they are both feature-full and expressive at the risk of making a dumb mistake, and when the dumb mistake is made, people pile on telling you how dumb you are rather than considering whether C++/Slashdot could be more dumb resistant. And when a person dares suggest that something be made more dumb resistant, that suggestion triggers a response that a person is also dumb and a complainer to boot.
For more background on this, I defer to Cooper of "Inmates are Running the Asylum", anything by Donald Norman, and the infamous "Unix Hater's Handbook." There is this culture that any user-interface problems are the fault of the luser and that anyone pointing out such problems is a whining complainer. I was reading a book on Boost, and barely made it into the first chapter on auto pointers when my head started to spin on different flavors of auto pointer and how one worked in one situation but would result in a GP fault in another situation -- geez, Louise, in Java you just have garbage collection and don't have to wrap one's head around such issues. Of course, I am probably mentally deficient for not grasping Boost/C++ auto pointer flavors and I will go through life writing mentally-deficient Java.
"You seemed to have entirely missed my point about writing image processing software. While I was talking about writing one piece of high-performance code (using templates) that can deal with multiple image formats (and gets automatically inlined by the compiler) automatically, you countered with using prefab Java LIBRARIES (what language do you think THOSE are written in?)"
Mostly Java, actually. This wasn't originally the case, but as Java's performance has increased, various parts of its core libraries have been rewritten in itself. The primary reason for this is to make porting it to other platforms easier: the less non-java code there is, the easier the system is to bootstrap with only a Java compiler.
"or Python (that also uses libraries written in C++ for high-performance image processing)."
Most Python libraries are written in C because that is what Python binds to. There are some C++ ones (usually with C "wrappers"), but then there are some written in other compiled languages as well.
"The mission-critical reference I was making was to Objective-C's runtime binding of functions. Without the compile-time checking you get from C++, Objective C lets you write code that calls functions that might not even exist."
You are missing the fact that Objective-C is perfectly capable of using static typing if required. You simply declare a pointer to a type directly as you would in C, e.g. "MyClass *aClass;", and voila! Any attempt to send a message isn't a member of "MyClass" on "aClass" will result in a compile-time warning. Dynamic types are therefore an option that you can use or not use, much like many C++ features. Note also that for those times when one wishes to avoid the overhead of the message dispatch system, Objective-C allows methods to be directly called by address. This is as fast as calling a C function by address (because that it what it is doing).
I'm not going to change your sheets again, Mr. Hastings.
Well, the heat was on the other day and I must admit I got carried away. In the same way as others have critisized C++ while never having done anything serious with it I was critisizing on the rails framework, knowing to little about it. In retrospect, it actually reduces the value of my other comment - which does hold a lot of truth as for the other part.
;-)
The only thing with Ruby is that I fail to see why we would need yet another language - except maybe to introduce object orientation in scripting languages. But I'm not so much in favor of scripts in the first place; configuration files and good software are a better alternative imho. But that's another discussion.
I do seem to have drawn attention with my rant though...
And what if there's nothing behind the door until it is being opened?
> You have to remember who you're dealing with here. Many of Slashdot's commenters are kids who have dabbled in scripting or perhaps...
/. may become tomorrow's next generation of programmers. That's what concerns me if now they turn away from C++.
...)
Yes, that is true, however:
- today's script kiddies on
- companies use internet forums as a source of marketing research and can in the long run - wrongfully - get the idea that mature languages like C++ haven't got it anymore and as a result no longer produce software for it (such as compilers, editors,
- IT managers, often having no clue at all about the programming language anymore may use such forums as a source of information to select the language in which to develop.
etc.
I think it is usefull to provide a counterweight in the discussion in order to protect a beautiful language that too few people calling themselves programmers bother to master.
> Andrei's Alexandresu's "Modern C++ Design" demonstrates these features well - that book is just mind boggling
Amen to that. This is the future of programming languages. Nowadays, OO is being taught, in a few years time, aspect oriëntation and policy-based design will be the norm.
The only thing I wish to add is that my rant about Ruby (on or off rails) being retarded was exaggerated. What I should have said is that I don't see why we need another language.
And what if there's nothing behind the door until it is being opened?
Well, I stick by my comment about a great deal of Slashdot posters. Many are poorly informed about programming. Most don't work as programmers. I wasn't really referring to just "script kiddies" by that. Basically, "hard" things that deviate from the Unix norm (C and Perl, basically) are denigrated. C++ has a difficult syntax, exploits some of the more nether regions of object oriented design, and does not have a Unix-friendly history. Therefore, it is "bad", even to people whose total C knowledge amounts to "Hello World".
;)
I agree about Ruby being Yet Another Language that tries to occupy a niche already filled by Python. That said, there is a great deal to be said for virtual machine-based languages. Python is just awesome. It boils down to requirements, and balancing the demands of rapid deployment with application speed. A VM language with a nifty, list-based syntax (I've heard it said that Python is Lisp with conventional syntax) is just the ticket if app speed is not the highest priority, but time to market is. Then you can profile what you've done and touch up the hot spots with custom modules written in C or C++, if you need to. It works quite well.
I too regard C++ as a beautiful and deep language whose possibilities are only just being explored.
All that said, I work in a startup with nine programmers. What we're doing with Python may allow us to succeed. If we were using a more time-costly language like C++, we would fail. So everything has its place
Probably this : http://www.digitalmars.com/d/property.html which is incomparably more elegant than the C way.
Those are useful features, but the most important thing C++ needs is a notion of safe modules, analogous to what C# has.
But, frankly, to me, C# is what C++ should be anyway. The only thing that is annoying about C# is its Microsoft connection and the concerns that causes.
A major difference that I can think off the top of my head is that C++ concepts are not "hard-wired" into the language. People can create non-standard extensions to these concepts and it will "just work".