So, I'm trying out Google's C++ test library...

**Mario F.** · 11-22-2016

By controversial, I mean controversial. There has been a generalized debate around this feature, which is indicative of a controversial feature. There are proposals for its removal from the standard and some maintainers have rejected its inclusion (glibc rejection of slibc implementation), or criticized it, including the Austin Group. Users seem to also have given a lackluster welcome to it.

I'm not sure what the status on the next draft. But likely there are proposals being prepared or already put forth for its obsolescence, in particular considering its dismaying adoption (it appears only Watcom has a near complete implementation).

**jimblumberg** · 11-22-2016

Okay, I hope in the future that they also consider doing something about all the "optional" features. To me these "optional" features are fragmenting the language. Things like the the "safe" interface and VLA should either be required or removed from the standard, IMO.

Jim

**Yarin** · 11-22-2016

Originally Posted by jimblumberg

To me these "optional" features are fragmenting the language. Things like the the "safe" interface and VLA should either be required or removed from the standard, IMO.

No fragmentation is going to come about because of optional features. Compiler writers are smarter than you give them credit for. A compiler that doesn't support optional features, will likely not be terribly concerned about being to spec, anyway (think embedded and Microsoft).

**MutantJohn** · 11-22-2016

Actually, msvc has tons of awesome optional features. Like taking the address of rvalues, for example.

**Epy** · 11-22-2016

Originally Posted by MutantJohn

Actually, msvc has tons of awesome optional features. Like taking the address of rvalues, for example.

That are nonstandard, will likely be obsolete in a few versions, and make maintaining your code a PITA. Microsoft is the same with its library functions and the Windows API. They remove or obsolete functions like it's going out of style. Glad I'm no longer working on a project that required me to figure out what value of _WIN32_WINNT was going to make it happy. Congrats, you've been caught hook, line, and sinker by M$'s attempt to lock you in.

**MutantJohn** · 11-22-2016

Oh, I was being 110% sarcastic. I think it's an actual standards violation to be able to the address of an rvalue. The compiler will complain about but only if you use the `/Za` flag or in future release of msvc, `/permissive` which is their `-pedantic` flag.

**Epy** · 11-22-2016

Originally Posted by MutantJohn

Oh, I was being 110% sarcastic. I think it's an actual standards violation to be able to the address of an rvalue. The compiler will complain about but only if you use the `/Za` flag or in future release of msvc, `/permissive` which is their `-pedantic` flag.

Lol, good.

Also, Lol @ M$ for deciding to use the phrase "/permissive-" for conformance, yet another dumb thing to make switching between MSVC and GCC more confusing (-fpermissive is entirely different).

**Mario F.** · 11-22-2016

Now, we just need a way to take the address of a register variable.

**jimblumberg** · 11-22-2016

No fragmentation is going to come about because of optional features.

No? Then why are the "safe" functions optional? Why was the VLA moved from mandatory to optional? It couldn't be because of disagreements between different compiler makers right?

Jim

**Mario F.** · 11-22-2016

Originally Posted by jimblumberg

No? Then why are the "safe" functions optional? Why was the VLA moved from mandatory to optional? It couldn't be because of disagreements between different compiler makers right?

I'm afraid to even ask what's your opinion on implementation-defined behaviour.

**jimblumberg** · 11-22-2016

I'm afraid to even ask what's your opinion on implementation-defined behaviour.

Why?

IMO implementation defined behavior should be avoided whenever possible. This doesn't necessarily mean never use an implementation defined feature as long as you know you're using a feature that may not be available with some other compiler and you document the fact that you're using that feature and why.

Jim

**Mario F.** · 11-23-2016

Case closed.

**Epy** · 11-23-2016

Originally Posted by jimblumberg

Why?

IMO implementation defined behavior should be avoided whenever possible. This doesn't necessarily mean never use an implementation defined feature as long as you know you're using a feature that may not be available with some other compiler and you document the fact that you're using that feature and why.

Jim

I think we're getting terms mixed up here, it sounds like you're referring to compiler-specific features, like GNU extensions etc. Every compiler has implementation-defined behavior -- every compiler team has to choose what to make the compiler do when it runs into undefined behavior, like fflush(stdin), right-shifting signed ints, etc.

**Epy** · 11-23-2016

Originally Posted by jimblumberg

No? Then why are the "safe" functions optional? Why was the VLA moved from mandatory to optional? It couldn't be because of disagreements between different compiler makers right?

Jim

I agree here, by making things optional it basically places them in the same class as compiler-specific features and therefore no one who wants to write code portably will ever use them.

Also, VLAs are mandatory in Fortran...wonder why the C people didn't want to make it mandatory as well.

**jimblumberg** · 11-23-2016

VLAs are mandatory in Fortran...wonder why the C people didn't want to make it mandatory as well.

VLA support was/is mandatory in C99 however it was moved to optional in C11 probably because one of the compilers refused to support the "feature" which is also why I believe the "safe interface" is optional instead of mandatory.

Jim