Username or EmailPassword
A better summary of the new features:
Also, GCC support:
http://gcc.gnu.org/projects/cxx0x.html Edited 2011-06-15 08:38 UTC
While I like the additions on their own I am not sure I like C++ as a whole.
What I would have like to see is a very strong "C++ The Good Parts" recommendation with a lot of commitment. And one that goes way beyond what current guidelines say. 0x would have been a great time for that.
I am not sure that _I_ would start _new_ projects in 0x when fairly mature and much simpler solutions like Go exist for a lot of similar problem spaces.
If D features Go style interfaces, or Go feature D style template modules, I'm sold. Sadly neither is true
There is nothing spectacular about Go interfaces besides not having to write an "implements" somewhere.
I like the language, but if you know your way around programming with interfaces and protocols in another languages, you will easily find similar features.
The thing is that I feel it will increase the flexibility of the language as changes in an interface doesn't require the implementation/class to make the respective change.
The bit about writing "implements" is in some ways same as the "auto" keyword in C# and D -- it saves a LOT of retyping and improves interface-implementation segregation.
New interfaces can also be written as per one's requirements and the older classes needn't implement it. In general, we write wrappers to take care of this.
IIRC, most of the C++-inspired languages don't feature method renaming or deleting abilities as in Eiffel which is where the strength of nominal typing lies. Without that, it's a constrained form of Go styled interfaces since the method signature has to be the same.
In particular I'm talking about the "interface segregation principle". If linked via interfaces, then yes the changes are necessary. But if there are multiple interfaces or if the function accepts the implementation itself, then no changes are necessary.
Well, I'd invoke the great god murphy's law: bad designs would spring up either way.
People end up writing bad code be it C++ or Ruby
I'll be honest though, I often keep modifying my interfaces rapidly but modify the classes much more slowly
Really? How do you add a function to an interface without having to add it to the implementing classes? How can you change a parameter type, or change a function signature without adapting the code that depends on it?
Why? The code you write to support an interface needs to be all on the same package.
It is not possible to add interface support to a type that lives in another package.
You did not understand my remark.
You can only add methods to types inside the same package the type is defined.
So if the interface is defined in package A, the type I am using is defined in package B, both I don't have access to the source code.
Now the interface changes, you cannot add the new methods to the type without modifying the package B as well. Because you are not allowed to add methods to you package B type, from package C for example.
I too would like to see a much simplified C++ design, instead of even more features added with few things removed. But I fear that we each would like to keep/remove a very different set of features, sort of proving Stourstup's point of creating a monster-sized "multi-paradigm" language.
As an example, I like that C++, like C, is good for all OS layers, provided that you are cautious with some features. But many other persons would probably prefer something that's fine-tuned for application-level development, and totally drops the power and control needed for low-level use in favor of extra comfort.
I doubt it will happen any time soon.
Personally I would like to have a more type safe systems language available. Joining the low level power with the high level expressiveness.
Sadly most of the languages that tried to displace C++, never fully managed it.
The main reason is that there isn't any other multi-paradigm language with C++ power that is currently available. Maybe only Ada would be one, but I won't see anyone wanting to jump ship to it.
And tool vendors are slowly bringing their C++ tooling to the same level we already have in managed languages.
The LLVM project has already shown how much error reporting and static analysis can be improved if the compiler is integrated into the tooling.
Actually, earlier version of MacOS classic, up to 6 or 7 were written in a mix of assembler and straight Pascal, not Object Pascal. Object Pascal was pretty much a Borland thing (it was a really nice language though).
Later versions (when PPC was introduced I think) were transitioned to C, but they still used Pascal calling convention for compatibility.
NeXT / OSX is a lot cleaner than MacOS classic, give Objective-C a try, think you might like it.
Get you facts straight. Object Pascal was created by Apple for MacOS and later on adopted by Borland.
You can read about it here,
"Revolution in the Valley: The Insanely Great Story of How the Mac Was Made"
Object Pascal a Borland thing?
The Borland version/dialect is nowadays perhaps the most known "Delphi", but there is/was an Apple version/dialect of Object Pascal as well.
Type safety has nothing to do with nominal typing. OCaml and Haskell have a (more powerful) version of the type system in Go. For most part, C++'s class system is mostly restricted VTables. Greater flexibility and consistent type system has nearly always been better for languages..
PS: I have only cursory knowledge of most of these languages. I love C++ for the templates, not so much a fan of the class system Edited 2011-06-16 22:51 UTC
The "class system", whatever meaning you intended to put into the phrase, in C++ is exactly the same as in Java with one glaring difference and another less obvious: multiple inheritance and friends.
I don't know any other OO languages but, as I understand it, a "class system" is only about inheritance, abstraction and encapsulation. I can't see how these basic bricks of OOP can be implemented in such a strikingly better way that you would be "not fan of the C++ class system".
Could you elaborate on what you call "class system" and C++'s shortcomings as to that class system?
What makes you think I'm talking about Java as being in any way superior?
Class System is done (almost) right in Eiffel. Method Renaming and Deleting.
The deficiencies? Diamond Inheritance and Constructor Chaining can make easy mistakes. The argument given is that "good practices and patterns will obviate this" but most of them exist only to overcome the shortcomings of the type system.
PS: And to clarify, the reason i say "class system" is because I don't wish to include templates into it, which are a lot more awesome Edited 2011-06-17 11:16 UTC
Maybe a good solution would be to define use cases and subsets.
Something like Qt forces you to write very different C++ than when you write low level system stuff. So have Qt-C++ and system-C++.
Maybe the guys who like ot define ISO standards are the wrong people to ask for something like that.
I guess once GO gets its concurrent GC a lot more people will see the light and only face the C++ monster when they really have to. Let's talk again in 10 years
Well, in practice everyone already uses a subset of C++, I think. Some are into heavy templating, others get into more traditional inherited class hierarchies, and then there are those who use C++ like a better C with extra tricks like function overloading and a "bool" type...
The problem is that in many projects, the types that involve multi-site across the globe, it is very hard to keep everyone on the same subset.
This is the main reason why you end up forcing style guides on the teams.
Still C++11 is looking a good improvement.
While you can totally see it from this point of view, I see it myself at something which makes C++ compilers more difficult to implement, and as such probably less efficient in each individual area
Assuming that the compiler can inline the overloaded ++ operator (which it should in this case), and you have a trivial copy constructor (which again, should be the case), modern compilers should be able to completely remove the copy. Probably.
If the interface is external (from a frame-work or shared library) the compiler can often not do those kinds of optimizations. With C++ overloading there is no guarantee that ++i and i++ has the same effect when used as procedure calls.
Agree 100%. I taught myself c/c++ in the mid 90's from books written in the late 70s early 80s at the school library and old borland Turbo C compilers. When moving to gcc in the late 90's I really wanted some *good* *modern* best practices guide to using the language. I never found anything of the sort. When I got my first job, I was made fun of for my ancient syntax patterns, even by the gray beards.
The way I improved my style was by reading Dr Dobbs, The C/C++ User's Journal and C++ Report.
Back in the day when Internet was called Arpanet and the best some of us could wish for was some form of BBS access.
Later on, the nice books from Andrei Alexandrescu, Scott Meyers and of course Bjarne.
This link is great to have an overview of the new features
Given that to this day, not one single compiler fully implements the C99 standard, despite the fact that it has been 12 years since it was published, how long is it going to be before any of the new features of the C++ standard can actually be used without tying your code to a specific compiler? If compiler implementation of the new features moves as slow as it has been doing for C99, I think we have a long wait ahead of us before we can actually safely use the new features in the standard. Edited 2011-06-15 15:50 UTC
Well, GCC is almost there, apart for the conccurency stuff...
EDIT : By the way, many thanks to whoever will implement stdint.h in g++. I dream of the day where I'll be able to remove this ugly GCC-specific hack_stdint.h header of mine from my OS' code ^^ Edited 2011-06-15 16:02 UTC
C99 has another problem, most compiler vendors do not care.
Most developers are quite happy with C89 features. The majority of developers that care about other features have moved to C++ or managed languages.
At least this is the official excuse from many companies when you ask about C99 support at developer conferences.
Bad excuse Things like stdint should have been in the C standard from the very beginning. It's unacceptable to create a system programming language that doesn't feature a way to get integers of known size without assembly snippets.
The short/long thing was broken from the beginning. There should have been int for everyday use and fixed-size integers for specific uses to start with. Edited 2011-06-15 17:09 UTC
You are right, and the worst are Borland and Microsoft. They are the main ones stating the point I was referring above.
If you are using Linux or another POSIX system accurate integers have been there for a "long long" time.
As part of the C library maybe, but not built in the "core" GCC, as it's supposed to. The C99 version of stdint.h has only appeared in gcc 4.5.something, IIRC, and the C++11 part is yet to be implemented.
May seem like nitpicking, I give you that, but the difference is there when you develop an OS as a hobby and DON'T want stdlib stuff to be linked in your code Edited 2011-06-19 18:54 UTC
POSIX and stdlib are not the same. One is a system interface, the other the standard library. The C99 stdint.h in the standard library (which you don't like), what I referred to was the system interface.
Anyway it was a joke.. "long long" time? Edited 2011-06-19 19:08 UTC
Simple things like <stdint.h> works standalone because it is only a header-file with no object core.
Last I had to write a kernel though, we had to copy stdint.h into the directory we were building the kernel from. It did not work with freestanding back then. I guess things have gotten easier
Whether that means it is now a core C language feature and not a core C standard library feature, I am... ehmm.. I guess, maybe.. I am not pedantic enough to care. Edited 2011-06-19 19:34 UTC
After having explored the D programming language, I'm a convert. D is very much designed using a "less is more" approach, and I'm sold on it. The fact that it has garbage collection built-in is nice as well.
Simple, elegant and clean.
D is "C++ done right".
Is D used by any large organizations, or for any large projects?
not to star a flame war but d is way too heavy. They loaded it up with reserve keywords and just lots of extra crap. d should have been smaller and more orthogonal than c++. Instead they decided to load it up with bloat. Edited 2011-06-16 04:20 UTC
What the heck are you talking about? It is C++ that has the bloat with the ten-thousand special cases for templates and constructors and operators and overloading and implicit type conversions and so forth and so on. D seems to have simplified a lot of that. I'm not sure what else you are referring to in terms of "bloat" (a term that is thrown around far too often these days -- as if we should all be doing 8-bit assembler on some 10,000 transistor chip from the 70s).
The problem with "done right" OS, tools, languages is that most of them fail victim of "worse is better" concept.
D is in some areas C++ done right and has quite a few nice features, but C++ has the tooling and industry support. So unless D provides a few killer features the adoption will never be that much.
A language to succeed has either to provide killer features that gather people around it until the language gains momentum, or needs industry push.
D has quite a lot of flaws, actually. More flaws than C++.
For example, the artificial separation between structs and classes.
The list is quite long.
The separation between structs and classes is eerily similar to the policies in .NET. It's nice to have explicit value type semantics rather than the fingers-crossed "semantics" of C++.
One friend told me something like: "You do not need garbage collection if you do not produce garbage!"... really true!!
"That's one of the things keeping me sticking with C++. Garbage collection is an ugly and unsatisfying solution to a minor problem."
I think it's more a matter of opinion.
The problem with delete in a managed language is that the language can no longer vouch for program safeness with regards to preventing code from corrupting it's own structures. Deleting an object which is still in use could cause stray pointers/references.
"I think a better solution is judicious use of reference counting & shallow copying. Then you get to keep speed, determinism, smoothness (no stopping the world), and deterministic destruction (for RAII)."
It's tempting to think so, but it's not safe to assume that malloc/free is always going to be faster than GC. There are alot of factors, it came up not long ago:
Are you thinking that the language ought to enforce reference counting on objects or just that programmers should use it as a design pattern?
One issue with ref counting is cyclic data structures. Though it may be uncommon, I'd hate for any language to be limited in this fashion: Visual basic used ref counting and was susceptible to memory leaks in cyclic structures.
I personally don't have any problem using new/delete myself, but I don't have any serious objections to managed memory if it helps devs produce more reliable code. Edited 2011-06-18 03:45 UTC