Approved: C++0x Will Be An International Standard

[plonoma]

Yes, I do. Typically of course I'll define a macro and use &, |, ^ for bit manipulation. I do use 8bit words, 16bit words, 32bit words, and have dealt with the odd 64bit word in such a manner. Particularly in the latter cases, binary literals would be just plain bad - too great a risk of putting the bits in the wrong place. Far easier with hex.

I was not talking about bit manipulations!

When you have a control register with each bit being a flag for something.
Then it's much more practical to be able to write a binary literal.
In this situation, working with hex makes it more error prone and complicated.
If your documentation goes like '... the third bit enables <some random thing>...', especially then it's really practical to be able to use binary literals.

[bachinchi]

D is massively larger. I just need to point that out. Complaining about the size of C++ and then recommending D as an alternative makes as much sense as complaining about the fuel economy of old car and recommending a Hummer to replace it.

I didn't meant the implementation, but the number of odd keywords and grammar.

D was a nice attempt at a better C++. The best, even. It just screwed up the way that every last single other attempt at the same has screwed up: it failed to actually be a (very near to) pure superset of C. C++ has a very specific set of properties that make it so successful. One of those is being a C superset. Obviously a clean syntax is not one of those, but frankly syntax is not that important in the grand scheme of things. Being able to do exactly what I need to do is important.

I sure was. I see your point, sadly nobody is using D in big projects.

The things C++ most needs fixed are changes that will give the programmer more control, less of a "safety net," and which would only mean more features and a larger spec. It would certainly be possible to design an actually successful "better C++" language. This will likely not happen, though, because the potential gain is basically nothing more than "fix a few syntax warts" and that would have to compete with "not compatible with the large body of C++ code already out there." Just not worth it.

?Time for F?

[Cyborg16]

You don't use bitset then? But truth be told bit-manipulation is most often used in performance-critical code and

bitset<2> bits;
...
if( bits[1] ){ ... }

isn't quite as fast as 'if( bits & FLAG ){...}'.

Btw, why isn't the new release C++B?

[mirv]

Do you also use hex when each bit is a flag for something in a word (16 bit) and let's go crazy and say dword, qword(32 and 64 bit)?

Seriously using hex is cumbersome in some situations.
Other languages starting to add binary literals.

The problem with pointer syntax is that from pointer to it's value and from value to it's pointer it's the same sign in some situations. I'm referring to the use of the '*' and the '&' sign and the pointer is not a type way of implementation.
You have to remember everything. Not a big deal if it's a small example exercise. But in a bit project this is how errors easily slip in.

Yes, I do. Typically of course I'll define a macro and use &, |, ^ for bit manipulation. I do use 8bit words, 16bit words, 32bit words, and have dealt with the odd 64bit word in such a manner. Particularly in the latter cases, binary literals would be just plain bad - too great a risk of putting the bits in the wrong place. Far easier with hex.

[plonoma]

I'm not convinced binary literals are great - I'd use hex in all cases even if they were there. It's actually more readable to have things in hex. As for pointer syntax...well, that can be confusing (nullptr is a bit late, but helpful never the less), particularly with function pointers, but I don't think it's that bad.

I'm quite enjoying the threading with C++0x (or C++11, or whatever) - glad to see that around. Combined with variadic templates, it's quite useful.

Do you also use hex when each bit is a flag for something in a word (16 bit) and let's go crazy and say dword, qword(32 and 64 bit)?

Seriously using hex is cumbersome in some situations.
Other languages starting to add binary literals.

The problem with pointer syntax is that from pointer to it's value and from value to it's pointer it's the same sign in some situations. I'm referring to the use of the '*' and the '&' sign and the pointer is not a type way of implementation.
You have to remember everything. Not a big deal if it's a small example exercise. But in a bit project this is how errors easily slip in.

[mirv]

There are a few things C and C++ really drop the ball.

- binary literals
- the way pointers syntax works (I'm saying the syntax for pointers sucks, pointers in itselve are very useful.

I'm not convinced binary literals are great - I'd use hex in all cases even if they were there. It's actually more readable to have things in hex. As for pointer syntax...well, that can be confusing (nullptr is a bit late, but helpful never the less), particularly with function pointers, but I don't think it's that bad.

I'm quite enjoying the threading with C++0x (or C++11, or whatever) - glad to see that around. Combined with variadic templates, it's quite useful.

[Cyborg16]

There are a few things C and C++ really drop the ball.

- binary literals
- the way pointers syntax works (I'm saying the syntax for pointers sucks, pointers in itselve are very useful.

Huh? Would you prefer

pointer<int> p = new int;

? Or do you mean the p->y vs o.y syntax?

[plonoma]

There are a few things C and C++ really drop the ball.

- binary literals
- the way pointers syntax works (I'm saying the syntax for pointers sucks, pointers in itselve are very useful.

[Cyborg16]

Plus, D really doesn't actually do anything of note that C++ doesn't do

I've got to disagree with you there; D adds quite a few useful things from much cleaner syntax (not critical, as you point out, but the easier code is to read the better from my point of view) to contracts to a slightly odd form of meta-programming (mixin statements), and lets not forget, built-in arrays and that are actually worth using for more than just basic operations. Contracts and class invariants are great debugging features, and something like array index checking which is done in debug mode is something I've wanted quite a few times in C++. (To be sure, some of these things are less important advanced programmers as for beginners, but C++ just gives less experienced programmers way too many possibilities to cause something completely unexpected ? from crashes to output that just doesn't make sense ? to happen in my experience.)

On the other hand, I agree with you that D doesn't quite cut it. The difficulties of using C++ and even C libraries is one of the biggies; some other significant limitations are garbage-collector only operation, no multiple inheritence (interfaces don't quite cut it as a replacement), limited operator overload support, and class destructors not guaranteed to be run (a trade-off to allow faster program exits, as I understand it).

[gilboa]

C++ got to the point of no return. It's huge. People should move to D or something.

You are aware that ***huge*** amounts of C code are still being written, right?
Both C++ (and C) are far from dead. (I've been hearing the news about C and C++ death for the last ~15 years or so...)

- Gilboa