The State Of C++1z In LLVM / Clang

[gamerk2]

But as people have pointed out, D doesn't do a lot of what people like me need it to do. For me, there's no real replacement for C++. Sure, D, Rust, and a number of other languages are fine for user-level applications, but for developers that program device drivers, RTOS's, and Embedded Systems, its C++ or bust. Yes, the language at this point is a PITA, but at the end of the day, you have the flexibility, capability, and performance that no other singular language allows.

[kpedersen]

TBH, C++ is overly complicated language, and the fact that they keep adding more features to it (burrowing it from other languages like modules) makes it even more complicated and cryptic.

True but there are some very smart people in this world that are able to handle these complexities, solve issues and get a (higher than average) paycheck.

Myself? I just bumble along using just the parts of C++ that I can actually understand. I tend to use C++0x era code (i.e std::weak_ptr which I find beats garbage collection hands down (especially when integrating with lower level C APIs. Sometimes there really is no way to handle the lifetime of an object and std::weak_ptr allows for this)).

As for all this new fangled future<T>, auto etc... Meh, leave all that to the cool kids

[kpedersen]

RTOS's, and Embedded Systems, its C++ or bust. Yes, the language at this point is a PITA, but at the end of the day, you have the flexibility, capability, and performance that no other singular language allows.

Erk, sometimes you don't even get the luxury of a PITA and crippled C++ compiler. Its C or ASM... yay! :/

I recently started work on an embedded project requiring only C and... argh dangling pointers. There was no easy way to know if some random function was going to free the memory pointed to or not. It would be nice if there was a clean segfault at the immediate source of a problem but stuff tends to just keep on going until the memory is trashed. Basically the problem...

struct SomeStruct *ptr = SomeStructCreate();
DoSomething(ptr);
// is ptr still valid? How do we know if DoSomething has freed the data or not?

For this I decided to write a small library called libstent to provide std::weak_ptr functionality (https://github.com/osen/stent/blob/m...le/game/main.c). Now you can write code like this and it should be more safe.

REF(SomeStruct) ptr = SomeStructCreate();
DoSomething(ptr);
// GET(ptr) is guaranteed to return NULL if DoSomething has freed the data

I honestly cannot see how kernel developers write such stable C code without any crutches like this!

Anyway... back on topic to C++ lol.

[pal666]

They should kill off C++ now that we have D

you don't have d. d's authors are busy working in c++ iso committee.

[pal666]

C++ is overly complicated language

that is common misconception
c++ core language spec is of the same size as java or c#.
library spec is order of magnitude smaller

[caligula]

Well, there is still no variadic templates and no specialization. Once this is backed into the language, I would happily say that Rust the best candidate as a safe C++ replacement. At the moment I'll continue to say that C++ as no real safe replacement.

Again that doesn't explain in any way why those features are needed in a language. Variadic templates are really problematic wrt typing unless you have something that's a lot better than what C++ offers.

[Ansla]

I honestly cannot see how kernel developers write such stable C code without any crutches like this!

When the language allows you to shoot yourself in the foot it's your job to make sure you don't. In your case, it's your job when defining the API if a function will free a pointer received as parameter or not. And how it signals the caller in case it did that.

Here is a concrete example from the kernel code: when writing a netfilter hook you get a pointer to an skb that represents the incoming packet. You can do whatever you want with it, free it or not, but if you do free it you MUST return NF_STOLEN. The opposite is also true, if you return NF_STOLEN you MUST free it yourself or memory will be leaked.

[swoorup]

that is common misconception
c++ core language spec is of the same size as java or c#.
library spec is order of magnitude smaller

Yeah, just C++ 14 specification is very small of just only 1368 pages. And this is just C++14, lol
http://www.open-std.org/jtc1/sc22/wg...2014/n4296.pdf

[pal666]

Yeah, just C++ 14 specification is very small of just only 1368 pages. And this is just C++14, lol
http://www.open-std.org/jtc1/sc22/wg...2014/n4296.pdf

clown, it's core language spec + standard library spec.
now enumerate pages of java standard library and c# standard library
btw, 'lightweight' and 'simple' c11 is 700 pages and most of the diff is in library http://www.open-std.org/jtc1/sc22/wg...docs/n1570.pdf

[pal666]

Again that doesn't explain in any way why those features are needed in a language.

there was language without variadic templates. it required horrible kludges like preprocessor generation of 50 tuple variants or printf-style functions with no type checking. so variadic templates were added to it.
you could find detailed explanation in motivation section of http://www.open-std.org/jtc1/sc22/wg...2004/n1704.pdf
next time you need an explanation, just look it up in relevant proposal instead of posting bullshit

Variadic templates are really problematic wrt typing unless you have something that's a lot better than what C++ offers.

variadic templates are much better than alternatives and something better simply does not exist