6 Replies - 8284 Views - Last Post: 05 July 2013 - 03:48 PM

#1 raspinudo  Icon User is offline

  • D.I.C Head
  • member icon

Reputation: 61
  • View blog
  • Posts: 232
  • Joined: 19-September 11

C++14 Feature Discussion

Post icon  Posted 02 July 2013 - 10:16 PM

In the spirit of being forward-looking, I thought it might be fun to begin discussing
the new C++14 features presented in the most recent draft.

References:
Copy of the draft: (Most recent I believe, correct me if I'm wrong)
Wikipedia Reference

For the following compiler support tables, bold means full or partial
support, a strikethrough means none at this time.

Clangs C++14 Compiler Support (8/11)
Tweak to certain C++ contextual conversions N3323 SVN
Binary literals N3472 Yes
decltype(auto) N3638 Clang 3.3
Return type deduction for normal functions SVN
Runtime-sized arrays with automatic storage duration N3639 Partial
Initialized lambda captures N3648 No
Generic lambdas N3649 No [WIP]
Variable templates N3651 No
Relaxing requirements on constexpr functions N3652 Partial
Member initializers and aggregates N3653 Clang 3.3
Clarifying memory allocation N3664 Partial

Clang C++1y Support Reference

GCC C++14 Compiler Support Status (5/10)

Language Feature Proposal Available in GCC?
Tweak to certain C++ contextual conversions N3323 4.9
Binary literals N3472 4.3 (GNU) ,4.9 (N3472)
Return type deduction for normal functions N3638 4.8 (N3386) , 4.9 (N3638)
Runtime-sized arrays with automatic storage duration N3639 ?.? (GNU VLAs), 4.9 (N3639)
Generalized lambda capture (init-capture) N3648 4.5 (partial), 4.9 (N3648)
Generic (polymorphic) lambda expressions N3649 No [WIP]
Variable templates N3651 No [WIP]
Relaxing requirements on constexpr functions N3652 No
Member initializers and aggregates N3653 No
Clarifying memory allocation N3664 N/A

GCC C++1y Support Reference

I would appreciate anyone who cares to post up the Visual Studio C++14
support plan/current status. I believe Herb Sutter discussed VS's at the most recent
build conference.

My Take on Compiler Support
It looks like a win for clang at this time, although I'm sure GCC should catch up.
It just gives me another reason to prefer clang as my current compiler along with
the color coded, and generally more readable compiler errors.

Also worth noting, recent phoronixbenchmarks indicate that clang's binaries are also
closely competitive with those of GCC's.

My Take on The Features
Now, onto the stuff we really care about, the neat new features!
For me, there are three features which seem really neat:

Function Return Type Deduction
I can't count how many times I have changed my mind as to
what a function I'm developing will return and forget to propagate
the change throughout its containing codebase. With the use
of auto for functions, this now becomes simple and clean. With
the use of auto all the way around, everything just works.

auto myFunc() { return 2; }
auto x = myFunc();



Note that these functions can support recursion, so long as a "regular"
return statement appears before the recursive one so the compiler
can properly deduce the type.

auto myFibFunc(auto f) 
{  
   if(f == 0 || f == 1)
      return f;
   else
      return myFibFunc(f-1) + myFibFunc(f-2);
}

auto fibRes = myFibFunc(10);



Less Constexpr Restrictions
At my current internship, we were planning on using constexpr to generate
a SCPI lookup table at compile time for our embedded device. The team decided
to move away from it due to all the restrictions placed on constexpr in c++11.
It will be great to use these much more freely going forward.

Newly added abilities include:
- The use of if/else blocks
- Looping constructs, including range based for
- General Declarations (Sans non initialized ones)


Tuple Addressing Via Type
Ok, this one is pretty small, but I find it to be handy.
You can now address a tuple element via its type, so long
as there is only one of that type.

std::tuple<int, int, char> myTuple(1, 5, 'c');
auto x = get<int>(myTuple); // compile error because its ambiguous, which int???
auto y = get<char>(myTuple); //works, y = 'c'



That's more than enough of me talking, what do you all think?

Is This A Good Question/Topic? 4
  • +

Replies To: C++14 Feature Discussion

#2 Martyr2  Icon User is offline

  • Programming Theoretician
  • member icon

Reputation: 4361
  • View blog
  • Posts: 12,180
  • Joined: 18-April 07

Re: C++14 Feature Discussion

Posted 02 July 2013 - 10:50 PM

Oh man I need to go run and get my popcorn! I love all this geek boy talk! Isn't it fun to have these little get togethers and talk about all the great things about a language that is not even baked yet?

PILLOW FIGHT!!!!!


;)
Was This Post Helpful? 2
  • +
  • -

#3 jimblumberg  Icon User is online

  • member icon


Reputation: 4142
  • View blog
  • Posts: 12,896
  • Joined: 25-December 09

Re: C++14 Feature Discussion

Posted 03 July 2013 - 08:19 AM

Really? The ink isn't even dry on C++11 and you want to talk about the pie in the sky of C++14?

Several of those proposed changes were already proposed in C++11 but weren't accepted. I doubt that, even this small list, will get approval for all items. One of the items is VLA.

Quote

Now, onto the stuff we really care about, the neat new features!

Quote

I can't count how many times I have changed my mind as to
what a function I'm developing will return and forget to propagate
the change throughout its containing codebase. With the use
of auto for functions, this now becomes simple and clean. With
the use of auto all the way around, everything just works.

Until it doesn't.

What happens if you change the return type from a standard type to a strurcture, and later in your code you have a statement that then tries to add this structure to a standard type?

Jim
Was This Post Helpful? 3
  • +
  • -

#4 Skydiver  Icon User is online

  • Code herder
  • member icon

Reputation: 3623
  • View blog
  • Posts: 11,291
  • Joined: 05-May 12

Re: C++14 Feature Discussion

Posted 03 July 2013 - 12:18 PM

Even worse, if 'auto' is listed in a header file, and all I have is a header file and a compiled library, how am I supposed to write code that uses that header file?
#pragma once

auto CreateMagicCookie(const vector<int> &ingredients);


Was This Post Helpful? 2
  • +
  • -

#5 raspinudo  Icon User is offline

  • D.I.C Head
  • member icon

Reputation: 61
  • View blog
  • Posts: 232
  • Joined: 19-September 11

Re: C++14 Feature Discussion

Posted 03 July 2013 - 01:42 PM

View Postjimblumberg, on 03 July 2013 - 08:19 AM, said:

Really? The ink isn't even dry on C++11 and you want to talk about the pie in the sky of C++14?


Yes, I said it was forward looking. I'm not about to throw any of this into my current code base, but it is
fun and useful to discuss these features because it can bring about real concerns as you noted below.

Quote

Until it doesn't.

What happens if you change the return type from a standard type to a strurcture, and later in your code you have a statement that then tries to add this structure to a standard type?

Jim

This post has been edited by raspinudo: 03 July 2013 - 01:43 PM

Was This Post Helpful? 0
  • +
  • -

#6 ishkabible  Icon User is offline

  • spelling expret
  • member icon




Reputation: 1622
  • View blog
  • Posts: 5,709
  • Joined: 03-August 09

Re: C++14 Feature Discussion

Posted 03 July 2013 - 05:52 PM

I'm really looking forward to generic lambda's of some sort. I think they should be treated just like function objects which have templated overloaded call methods as the semantics are already very clear and this idiom is already in use.

Generalized lambda capture, variable templates, and better constexpr support(particularly being able to have arbitrary constexpr values as template parameters would be amazing). I don't think that constexpr functions should be expanded; this is useless if you ask me as most of this is already very doable via ternary and recursion.

I think tuple type addressing is a bit odd personally; it feels rather hacked.

this all said, I *REALLY* doubt the committee will actually make the deadline of 14. My bet is 17 14 if anything will be technical report for libraries (which *WILL* be cool but not as cool as these tiny little features)

Quote

Even worse, if 'auto' is listed in a header file, and all I have is a header file and a compiled library, how am I supposed to write code that uses that header file?


That wouldn't be allowed. If this were to be adopted it would have to be treated like templates or for prototypes to have explicit return types that agree with what auto deduced. I see this more as a boon for templates however when you have a long complex return type that is in a sense "calculated" via compile time types and values. now it can be inferred so you don't need to boilerplate.

But ya, I would say don't use return type deduction unless it's a template
Was This Post Helpful? 0
  • +
  • -

#7 Switters  Icon User is offline

  • D.I.C Head

Reputation: 25
  • View blog
  • Posts: 110
  • Joined: 03-June 12

Re: C++14 Feature Discussion

Posted 05 July 2013 - 03:48 PM

View Postjimblumberg, on 03 July 2013 - 08:19 AM, said:

Really? The ink isn't even dry on C++11 and you want to talk about the pie in the sky of C++14?


And in a discussion forum (of all places!) at that. With balls that big you wonder how raspinudo even gets onto a bicycle without falling over...
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1