User: Password:
|
|
Subscribe / Log in / New account

A look at C++14 and beyond: Papers part 3

Part 3 of the "Meeting C++" papers series on C++14 is available. "The concepts approach for C++11 failed, it was dropped, as it was to complex to be adopted fully to the standard for C++11. Since then a lot of people have had their thoughts on how to integrate concepts into the language, as its a feature that would enhance C++ for sure. This proposal now concentraits on template constraints, which shall be applied to force the correctness of template use, not definition."


(Log in to post comments)

A look at C++14 and beyond: Papers part 3

Posted Apr 4, 2013 7:51 UTC (Thu) by helge.bahmann (subscriber, #56804) [Link]

"Binding stateful functions as function pointers

[...] The approach outlined here of a thunk, or trampoline, is well-understood and used commonly in language implementations which include a JIT compiler."

I seriously hope this proposal is stopped as early as possible, for exactly the reason stated.

A look at C++14 and beyond: Papers part 3

Posted Apr 4, 2013 16:35 UTC (Thu) by Cyberax (✭ supporter ✭, #52523) [Link]

Why? Thunks are already widely used and they are quite useful. For example, ATL/WTL on Windows uses them instead of a global HWND table.

A look at C++14 and beyond: Papers part 3

Posted Apr 5, 2013 7:15 UTC (Fri) by helge.bahmann (subscriber, #56804) [Link]

It requires run-time code generation, so security restrictions enforcing "text not writable/data not executable" need to be waived for executing any program that makes use of such feature, or links in a library that does. Introducing such a thing at the language level should therefore be done with care, especially as there is a well-known design alternative (really, is it that hard to turn on your brain and just pass a void * closure pointer in C callback APIs?).

Since the argument in favor of this boils down to: It would be useful to cater for badly-designed legacy APIs, this should not be a language feature but a legacy hack/workaround library.

A look at C++14 and beyond: Papers part 3

Posted Apr 5, 2013 7:20 UTC (Fri) by helge.bahmann (subscriber, #56804) [Link]

To avoid any misunderstanding: The "turn on your brain" part was not directed at you, but at prospective programmers using this feature just because it looks so "incedibly convenient", unaware of the side effects, while the security-friendly alternative of passing an opaque closure pointer is just a few fingertips away.

A look at C++14 and beyond: Papers part 3

Posted Apr 5, 2013 19:45 UTC (Fri) by hummassa (subscriber, #307) [Link]

I don't think runtime code generation is needed.
old_api_pass_pointer_to_function(less_than(8));
would only be syntactic sugar for
extern "C" int _generated_less_than_8(int x) {
  less_than called { 8 };
  return called(x)/
}
//...
old_api_pass_pointer_to_function(&_generated_less_than_8);

A look at C++14 and beyond: Papers part 3

Posted Apr 6, 2013 9:16 UTC (Sat) by helge.bahmann (subscriber, #56804) [Link]

That works only for compile-time constants. The proposal as worded places no restriction on

- run-time values
- multi-threading
- recursion

and therefore calls for a generic solution that works in the presence of all of the above, unless the compiler can prove its absence (which for the last two may be impossible). The only way that I see this can be satisfied is via run-time code generation.

A look at C++14 and beyond: Papers part 3

Posted Apr 6, 2013 10:16 UTC (Sat) by khim (subscriber, #9252) [Link]

You don't need a runtime generation, in fact on any POSIX system you can implement it in a library using tools already present in C++11 with an auxiliary .so file using dlopen. Create helper library with around 1000 thunks (it'll be 12KB for thunks and 8KB for data pointers), load it via dlopen(RTLD_LOCAL) and use them as needed. If they are all used up - load it again and use as another batch of thunks. This will satisfy all the requirements of standard, keep W^X property and will actually be practical enough if implemented in the standard library (since wastage from this scheme will be limited to about 20-30KB no matter how many actual users will be there).

I don't see what got you so riled up.

A look at C++14 and beyond: Papers part 3

Posted Apr 6, 2013 15:47 UTC (Sat) by helge.bahmann (subscriber, #56804) [Link]

Thanks for the explanation, you are right and I was not aware of this option, and this does indeed sound like good solution. The part that immediately raised a red flag for me is the following sentence, quoted from the proposal:

"The primary implementation hurdle will be the implementation of an allocator that can provide executable memory [...]"

at which point I immediately thought "please don't"...


Copyright © 2013, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds