Bjarne Stroustrup Previews C++0x 741
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.'"
Comment removed (Score:4, Interesting)
Should've just done it in Python/Ruby anyways (Score:4, Interesting)
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.
Slashdot interview? (Score:5, Interesting)
Lots of detractors here (Score:4, Interesting)
Just get rid of it altogether (Score:2, Interesting)
Threads Cannot be Implemented as a Library (Score:4, Interesting)
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.
Re:Downhill at a fast rate (Score:2, Interesting)
But if you spend just a little up-front design time, it is also very easy to create nice clean code.
Refactoring C after a year of development is not that hard.
Refactoring C++ after a year of development can be impossible.
Did you say reuse? Bah.
Re:This has brought out the C++ haters (Score:2, Interesting)
No, they aren't. C/C++ is still used for the widest range of applications, but in terms of numbers of commercial applications right now, Java dominates.
Sure, its possible to create artificial benchmarks that prove otherwise, but in te real world where performance counts, people use C++.
I'm afraid that is increasingly not the case anymore. For example, Boeing have requested that all new development is in Java, even for real-time mission-critical high-performance work. The reason they give is that Java is simply a more productive language to work with. You may not agree with them, but this is what is happening.
Re:The GUI. (Score:3, Interesting)
Using a procedural, compiled programming languague for GUI's is a fundamentally flawed concept to begin with. If you want to create a user interface, just use HTML, XUL, XAML whatever. 300+ lines of Visual C++ code just to display hello world is indicative of an underlying problem.
Re:Adding new features is not always an improvemen (Score:3, Interesting)
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.
what is he taking OUT? (Score:3, Interesting)
-russ
C++ vs Retards on Rails (Score:2, Interesting)
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.
I like some of the proposals for C++0x (Score:3, Interesting)
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.
Re:Adding new features is not always an improvemen (Score:3, Interesting)
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.)
ditch the long long long long void* already please (Score:2, Interesting)
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.
Re:Worth it? (Score:3, Interesting)
C++ is virtually a superset of ANSI C so I don't make the distinction between the two. C++ is C with classes, exceptions & rtti to me. The difference that exist are mostly irrelevant to modern programming. These days as far as most programmers or indeed compilers go, C++ and C are one and the same with a few switches to control stack unwinding or other behaviour for .c or .cpp extensions but little else.
As long as your library's entry points are not mangled, and use a standard calling convention it makes no odds what language it is implemented in on the other side. And even if it were C++ mangled, it would be hardly a supreme effort to write some stubs around them. I do think that using C is better for the APIs but QT has bindings so clearly it's not strictly necessary. Personally I prefer the GTK approach to its API and would call Win32 directly than through MFC any day, but I don't care how it works internally.
Re:Adding new features is not always an improvemen (Score:2, Interesting)
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.