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" 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?
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
"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
There's a reason why languages come and go.
I agree that ADA and FORTRAN are out and Java and Python are in, but isn't C/C++ an expection?
C/C++ have been around for many years and show no signs of going away - C++ was initially developed in 1983, while C itself hails from the early 1970s - and they're still popular to this day. And, of course, C++ "bolted on new features" to C. In fact, C++ was initially called 'C with classes'.
As far as I'm concerned, as long as C++ is "the standard language" in so many places we may as well make it not suck in comparison to other languages, which we can do by appropriating the nice features of those other languages.
Just my $0.02,
Michael
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?
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.
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.
I doubt Google, Adobe, or many of the thousands of other companies depening on C++ will be throwing their code base away any time soon. Rather, they will want their C++ code to be more robust and more managable. The features the article lists all seem to do this.
(See Stroustrup's C++ Applications page for more.)
Tell me about it! And those fancy editor thingamajiggs? A-phoooey! Real Programmers use cat(1) and do it right the first time!
sudo ergo sum
C++ is a tremendously type safe language, to the point where every time I work with it I feel like about 90% of the work I do is in accounting for type. Most of that work is thrown away after the code has been compiled, too, but it does make for a rock solid program if you do it right. It seems to deliver on a lot of the promise of ADA, really. If they can improve access to its features without compromising that type safety, I'm all for it.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
I still think C++ was invented as a joke.
Not a joke, a research project. Thus, Stroustrup's willingness to include any "feature" that someone suggests: "Oh sure, we'll put that in and see how it works out."
The upshot is a language that is accreted instead of designed.
When I found the C language, I stopped looking. Ah well.
Too bad.
-jcr
The only title of honor that a tyrant can grant is "Enemy of the State."
To us stuffy old farts things keep moving way too fast. I just got gazillion errors from the spanking new compiler, because the scope change to the variables declared inside for loops.
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.
It's not that hard to see if there's a 'const' in the function prototype, is it?
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.
>> When I found the C language, I stopped looking. Ah well.
> Too bad.
I guess I should have qualified my comment, really. I suppose in part it comes down to what problems one is trying to solve. I'm an embedded designer, working on small systems. Assembly and C turned out to be the right tools for the job. So I guess I should really have qualified my rant with "in my line of work".
The red mist has lifted now!
Open Source Drum Kit, LPLC deve board - mjhdesigns.com
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_
It can get ugly, if it isn't designed.
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.
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
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
"Dude, have you ever heard of text formatting?"
As a die-hard C/C++ fan, he figures redundant whitespace will just compile out in the end.
> And reference variables?
There is no such thing as a reference variable, you clearly don't know the C++ language. references are not variables. references are newly defined identifiers that refer to an object that already has identifiers referencing it, they don't change, ever, hence are not variable... But I see that you *really* meant *pass* by reference, if you want to ensure that the function can have no side effects, cast the parameter to const. Otherwise, if you expect to write software without knowing what the functions do, you should not be writing software.
BTW, when you say "fancy allowing standard operators to be overloaded" I think you mean "overrided". C has overloaded operators (+ is defined for int, char, short, long, float, double, etc). overriding lets you tell the compiler how to do addition for your custom bigint library, or whatever. You can misuse operator overriding, or you can misuse macros, each are there for a purpose, and each get misused by bad programmers.
> And now garbage collection? That just a feature to fix poorly written code.
No it isn't, it is a feature to simplify the determination of object lifetime when that lifetime depends on complex (or more likely, merely chaotic) runtime factors. Bad programmers use it to fix poorly written code. Sure, every lifetime can (maybe) be determined by some complicated equation, but when you have limits on how much CPU you can use and limits on how much time you can spend on maths, you use garbage collection.
The trick is only to use garbage collection when you know that you need it and what it means. There's the problem with most dynamic languages.
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.
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
++ 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)
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:
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 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.
Huh?!? C++ is a tremendously type dependant language, which is a very different thing from being type safe. If you type x = y * 3; where x is an unsigned integer and y is a float, a "type safe" language would generate a type-mismatch error at compile. A "type unsafe" language (like C++) would auto-cast without telling you and leave you scratching your head for hours trying to figure out why the results are not what you expected. Yes, that's a programmer error, but a good language should be designed to catch programmer errors at the earliest possible point (compile time).
Support Right To Repair Legislation.
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.)
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.
You really need to do this:
/vmunix /dev/tty
:-).
ln -s
Then you have to type in your OS on each reboot - kind of like having a 1.5 million character password
Don't underestimate the power of The Source
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,
From my experience using C++ in the field, I basically agree. While type safety can be a headache, there are many errors that strong typing eliminates entirely, almost to the point that "if it compiles, it's correct".
If you were talking about ML, you might be right, but in the case of C++, that's unadulterated bullshit. C++ can never approach the "if it compiles, it's correct" ideal because it allows unsafe memory operations. I recently worked on a large C++ code base that "compiled" the day I arrived. Within a couple of months, I had fixed about 90 memory handling bugs, which type safety did absolutely nothing to guard against.
Erlang.org: wow
Windows is like decaf - it tastes like the real thing, but it won't get you through the day.
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...
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?
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.
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.
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.
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.
Good to see you doing your part to make it happen.
The Farewell Tour II
You can be warned about that on almost every C/C++ compiler out there. Most compilers don't by default, but if it's something that you care about, enable it; it takes seconds.
"WANTED: Sinking ship seeks rats."
I agree that ADA and FORTRAN are out and Java and Python are in, but isn't C/C++ an expection?
As someone who's been paid to program in each of those over my career, I'd say that each of them have their places.
"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.
Agreed. The first step to coding C++ is to forget all the C you ever knew. Arrays are used for optimizing and nothing else. Combine that with the type safety of the language, and using references instead of pointers, and you basically get Java without all the flaws of Java/C# - it's faster, more typesafe, backwards-compatible, better hardware access, and more expressive than it's newer offspring. If only the 9x standard had come out (and been supported by mainstream compilers) earlier and there were some solid GUI libraries, we could've dodged the whole Java/C# thing altogether... well, if there were some way to put pointers in a collection and have them be deleted on removal in standard C++ (either support for auto_ptrs or inclusion of smart_ptrs in C++).
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.
Clearly you use C++ but not Java, or you'd be able to spell "exception".
Besides, Java is so on-the-way-out these days. Didn't you get the memo? I'll forward you a copy.
Have you read my blog lately?
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