C++0x

Anyone started to learn C++0x yet? I've been learning this past few hours, there's quite a lot of extra stuff here, the C++0x Final Committee Draft is twice as big as the original C++98 spec. Most of it is library additions.

Overall it looks like it fixes a lot of shortcomings with C++ currently and will be a help if you're already an expert. But it also looks like there will be a lot more here to shoot yourself in the foot with if you're a beginner.

I wonder if C++0x will be well received or will only end up fracturing existing C++ communities.

How long have they been trying to fix C++? how many years now?

>>2
27 years.

Did they added ifstream::ifstream(const  std::string& file_name) yet? Because it's inconvenient to use

ifstream porn(porn_path.c_str());

>>4
I just took a look at the draft spec, and yes, it's there.


// 27.9.1.7 Constructors:
basic_ifstream();
explicit basic_ifstream(const char* s,
ios_base::openmode mode = ios_base::in);
explicit basic_ifstream(const string& s,
ios_base::openmode mode = ios_base::in);
basic_ifstream(basic_ifstream&& rhs);

>>1
I started to learn Sepplesox in 1999 with the inception of Boost.

>my face when i don't have a clue about the impact of C++0x on the C++ industry.

honestlyNoIdea.jpg

Interesting: I got here exactly to ask you what do you think about C++0x and what are the benefits which it introduces.

So what do you think about C++0x and what are the benefits which it introduces?

* C++1x

Official /prog/ announcement

I hereby declare that every reference to Sepplesox is to be henceforth replaced by Sepplesix.

>>9
C++0xA
Fixed that for you.

>>8
Concepts and axioms would've been glorious benefits, but they've been remanded to a technical report. They were also integral in reducing the complexity of C++ for beginners that weren't writing them, though admittedly, "spectacularly bad" error messages are only a part of the story. The rest is semantic overload and the lambda syntax illustrates precisely what is the largest percentage of its badness: Its complex syntax.

There is an entire working group dedicated to figuring out how to parse additional C++ syntax. No mortal can keep all the rules in their head. Nearly every single thing they change introduces new keywords, syntax, or semantics.

In this vein, the right angle brackets and new enum semantics are probably the most potent. auto is a necessary addition. The uniform initialization syntax change was good. From a syntax perspective, there was very little else that helped.

As far as utility, other than the above mentioned, lambdas are something that were sorely needed. Closures are simply too useful to not exist where abstraction is important.

nullptr closes a huge gap in the type system. For example, because std::string has an implicit conversion from unsigned char *, you can actually use 0 in comparisons with std::string. Not to mention the overloaded function resolution when you're using null pointers... they default to the integer versions. It's subtle things like this that lead to confused noobs and very long debug times.

rvalue references are good from a performance and library perspective. Respectable additions. Actually, most of the standard library changes are great.

Those inheritance type specifiers should've been upgraded to necessary or at least had one of the labels be the default. The syntax makes it horrible and ugly to use and those are extremely useful for limiting inheritance and increasing clarity.

Variadric templates are pretty useful, I guess. Type-safe printf has been a long time coming. I wouldn't personally use them, but recognize the power in such an option.

Memory model changes were necessary. User-defined literals are retarded.

Overall, it's better to have it than not, but it still doesn't address the primary problem with Sepples because anything that adds to Sepples doesn't address it. It does, however, increase Sepples' power for writing libraries and general programming constructs. This is what Sepples is good at. So pick your poison, I suppose.

>>10


I don't understand why that would be better than Sepplesux

The blogging C++ "authorities" probably like the new Sepples, so therefore it will catch on.

>>12
Closures
You sure?

>>12
About nullptr[/null], didn't we have NULL already? I know it's defined as 0, but is it different? If we keep retro-compatibility with C we cannot remove NULL, therefore we finish in having two different notation (namely [code]nullptr and NULL) which are doing the same thing!

>>15
You fail it.

>>15
Yes. nullptr acts as much like NULL as possible while still being of type nullptr_t. It closes a gap in the type system and clarifies intent. You can still use NULL and it'll still compile, but that can lead to the issues I described (and a number of them that I didn't). So no, they don't do the exact same thing.

>>14
Yes.

>>16
Yep, sorry, someone should wordfilter [/null] with [/code].

>>14
Closures
Absolutely.

>>15
C++'s root problem has always been keeping C compatibility. It already duplicates functionality between C library calls and C++ language features, not to mention between C library calls and C++ library calls... so this is nothing new.

>>12 thanks for your explanation, Bro.

I honestly think move semantics is the only valuable addition in sepplesox. The language was never complete without them; the idea of returning a string causing a copy operation is just ludicrous.

Lambdas are okay, but not hugely necessary; they'd be better if the syntax for them wasn't horrible.

auto is a joke. Either have type inference or fucking don't, all right? What's with this half way bullshit?

nullptr makes me sad because it reminds me that C++ will never, ever break backwards compatibility to fix horrible glaring issues, like NULL being of type int instead of void*. That bullshit is there forever, for fucking ever. And they could at least have claimed 'null' instead of 'nullptr' for fuck's sake. What the fuck are they worried about, that someone has already defined it to something other than ((void*)0)? Those retards deserve their code to break.

variadic templates are alright, but i haven't seen a non-novelty use for them yet other than tuples and typesafe printf (something which should probably have just been done as a built-in; c++ is the only language in the world without built-in strings...)

the threaded library is useful, but... huge. that is just asking for incompatibilities between different standard libraries, and in a threading library??? this is bound to be disastrous. IMHO they should have only defined the memory model and included a few low-level primitives (thread, mutex/semaphore, condition), and let people make their own higher level constructs (futures, thread pools, etc.)

User-defined literals is the stupidest goddamn fucking retarded fucking language addition in the history of programming. This is seriously the prime example of how trying to please everyone is completely poisonous to the language.

>>15
Yes, NULL is different, because it's an int. This means it does the wrong thing in overload resolution. Observe:

void foo(int bar)   {printf("fuck!\n");}
void foo(void* bar) {printf("fuck!\n");}
int main(void)      {foo(NULL);}

Guess what it prints? Yeah, that's why nullptr. Fucking retarded language.

>>21
It is much easier and accurate to simply say "C++ sucks" and be done with it.

It looks like they tried to turn C++ into Perl.

>>21
Lambda functions and closures are important, because algorithms are becoming more and more important in C++.


std::atomic<int> sum = 0;
std::parallel_for(a.begin(), a.end(), [](int x) { sum += x });

That will sum a huge sequence of values for you in a parallel fashion, running chunks of it on separate threads. You can do the same thing with old-school functor classes and objects, but that's a lot of boiler plate you need to right.

This is a simple example, but it's not hard to see how it could be useful.

Also, the threading library in C++0x isn't huge, it's just basic, it wraps common stuff in pthreads or windows threads. If you're a proficient C++ developer, you could write that library in a couple of days.

a lot of boiler plate you need to right.
back to /b/, please.

>>25
Sorry. It's 3AM here and I'm exhausted.

nullptr makes me sad because it reminds me that C++ will never, ever break backwards compatibility to fix horrible glaring issues, like NULL being of type int instead of void*.
problem: NULL is an int instead of a void *
sepples solution: leave NULL the way it is, add a new keyword to the language, and break compatibility with c even further by making any attempt to compare nullptr to 0 an error.

>>27
The more they break compatibility with C (and C++) the sooner they can totally eschew, deprecate and eventually eliminate the older usages and have a proper language (for better or worse) instead of "C with featuritis".

>>28
a language that's 10 years behind where c was 11 years ago isn't really what i'd consider a "proper language".

>>28
This compiles and prints out what you would expect.

if (nullptr == 0) {
   std::printf("Expert Sepplesox Programmers\n");
}

However, this will generate a compilation error:

int x = 0;
if (nullptr == x) {
   std::printf("Expert Sepplesox Programmers\n");
}

The '0' literal can still be implicitly cast to a nullptr_t. Some semblance of backwards compatibility is maintained. If you understand the C++ type system, it makes sense.

>>30
Only Cthulhu can understand the C++ type system.

>>30
auto null = NULL;
if (nullptr != null) std::cout << "NULL MY ANUS" << std::endl;

>>32
null takes on an integer type, but literals such as '0' have a more lose definition of type.

>>33
Looks like a lose--lose position.

>>34
Not really, because real Sepples programmers never use NULL anyway, unless they're interfacing with a C library.

>>35
I'm guessing >>34 was making fun of >>33's spelling rather than making a real point about what >>33 said.

>>21
>>12 here. COMPLETELY agreed on the user-defined literals.

I can't even wrap my mind around how that could possibly be useful (a net gain) in any context. You already have string and number literals. There's nothing else you could want? The only way it could be useful is for metaprogramming, and there's not really any use in that because you can't dynamically define types or variable names or anything like that.

Yeah, you can shift more things to compile time, which is good, but this has massive costs in the same way that operator overloading has massive costs - except worse because these aren't encapsulated. They basically stomp all over scoping tricks that make sure things play decently with one another.

Oh well. It's not like I can stop it from being added. Here's to hoping it's not abused and there are use cases that justify it.

I like how languages like C++ and Perl are too messy to really apply modern theory too (e.g., both have non-decidable grammars), so no one even tries. They just pile on random ad hoc features, usually to fix some other broken feature, into every unused nook and cranny of the syntax without a thought to orthogonality, cleanness, ease of implementation, etc.

You know, D, for instance, let you specify that a variable or function should be evaluated at compile-time, as the compiler can actually interpret a subset of the language.
I haven't researched this, but I'm pretty sure that lets you do all the things these user-defined literals are good for.
This places a demand on the compiler implementation, yes, but in return the language syntax remains virtual identical. You use the exact same simple-to-understand form for compile time evaluation that you would for run-time evaluation, and it works pretty much as constant-folding.

This isn't new with Cppox either; initialization lists are exactly the same. What moron would completely redundantly introduce complex new syntax just to save himself some simple analysis of the ``constructor'' that in turn is only necessary because of the ill-thought-out implementation of some other features that in turn were redundant themselves? The big B, that's who. Even Java does this better.

Gobbledygook.

>>38
well, d and java both have the advantage of being designed for the sole purpose of being like sepples but better.

>>40

>>41
Stating the incredibly obvious was worth a bump, was it?

>>41-42
if it wasn't, then why did you bump it?

>>41,43
Go away.

>>40
That should also apply to new C++ revision, though.

/prog/ will be spammed continuously until further notice. we apologize for any inconvenience this may cause.