A C++ feature I would love to have: custom type modifiers « Technology Temple

A C++ feature I would love to have: custom type modifiers

In C++ the const type modifiers when applied to methods has the nice property of making it impossible by default (e.g. without a const_cast) to call non-const methods. A similar feature is provided by C++0x keyword constexpr.

It would be very nice if this property could be applied to custom classes of functions. The idea would be to tag method definitions with a custom keyword, or a type. Tagged methods would then only be able to call method tagged with the same type.

A nice usage I could find for this would be to define a non-blocking class of methods. Non blocking methods are such if they never blocks for a potentially unbounded amount of time waiting for an event. Using the tags the compiler will be able to detect if a method supposed to be non-blocking is trying to call some potentially blocking code and this would be very useful to detect possible deadlocks at compile time. Another usage would be to tag all the methods that are supposed to be used by a specific thread with the same tag. With such setup methods that access shared data would be untagged and using them would require a cast or some special syntax, hopefully helping the programmer remember that some synchronization is needed.

A possible approach to (ab)use the volatile keyword to detect race conditions was described here in 2001. But maybe this approach could be more general. Any comment?

C++, deadlocks, threading

This entry was posted on March 18, 2011, 5:08 pm and is filed under Bar discussions. You can follow any responses to this entry through RSS 2.0. You can leave a response, or trackback from your own site.

http://www.timonvo.com Timon Van Overveldt

I think this is a very interesting idea. I guess the implementation in compilers wouldn’t be that hard since all the functionality is already there.
I bet that if you ask some people they can come up with a dozen of handy ways this could be used.
http://www.timonvo.com Timon Van Overveldt

I think this is a very interesting idea. I guess the implementation in compilers wouldn’t be that hard since all the functionality is already there.
I bet that if you ask some people they can come up with a dozen of handy ways this could be used.
Alex

What you want is actually something a little more general called “Generalized Algebraic Datatypes” or GADTs. They’re well-known (though somewhat new) in type theory (which is the field studying the kinds of things you ask ) and the Functional Programming community, esp. Haskell. Though somewhat technical, look here: http://www.haskell.org/haskellwiki/Generalised_algebraic_datatype
Specifically at “Example with lists” for a similar example to what you want with non-blocking. The idea is that you use an arbitrary datatype-constructor to pass in (through a mechanism similar to Phantom types) an extra implicit argument that represents the “tag” for the GADT that you’re targeting. Sorry if I’m not being clear, but the minutiae of type theory and GADTs are tricky. ^^;
Alex

What you want is actually something a little more general called “Generalized Algebraic Datatypes” or GADTs. They’re well-known (though somewhat new) in type theory (which is the field studying the kinds of things you ask ) and the Functional Programming community, esp. Haskell. Though somewhat technical, look here: http://www.haskell.org/haskellwiki/Generalised_algebraic_datatype
Specifically at “Example with lists” for a similar example to what you want with non-blocking. The idea is that you use an arbitrary datatype-constructor to pass in (through a mechanism similar to Phantom types) an extra implicit argument that represents the “tag” for the GADT that you’re targeting. Sorry if I’m not being clear, but the minutiae of type theory and GADTs are tricky. ^^;
Sean

At the very least, you can use c++0x attributes and GCC plugins to achieve this.

Using some macros you can easily make this something you enable only for builds where it’s supported.

#if defined(NONBLOCKING_CHECK_PLUGIN)
# define NONBLOCKING [[nonblocking_call]]
#else
# define NONBLOCKING
#endif

class Foo {
public:
void bar (void* baz) NONBLOCKING { blocking_call(baz); } // error
};

gcc –fnonblockingcheck.so –c foo.cc

The blocking check plugin would define the NONBLOCKING_CHECK_MACRO implicitly, and then add the semantic analysis for nonblocking_call functions.

Technically you don’t even need c++0x attributes, you can just use GCC attributes in this case since it’d be a GCC-only plugin. If you wanted to propose it as a patch for Clang though you might want to use the more standardized syntax.

With a little effort, you could generalize this too. Make the plugin load a list of context attributes and policies, something like SELinux. Functions defined with context A can only call functions with context A or B, and cannot be called from any function with context C, etc.
Sean

At the very least, you can use c++0x attributes and GCC plugins to achieve this.

Using some macros you can easily make this something you enable only for builds where it’s supported.

#if defined(NONBLOCKING_CHECK_PLUGIN)
# define NONBLOCKING [[nonblocking_call]]
#else
# define NONBLOCKING
#endif

class Foo {
public:
void bar (void* baz) NONBLOCKING { blocking_call(baz); } // error
};

gcc –fnonblockingcheck.so –c foo.cc

The blocking check plugin would define the NONBLOCKING_CHECK_MACRO implicitly, and then add the semantic analysis for nonblocking_call functions.

Technically you don’t even need c++0x attributes, you can just use GCC attributes in this case since it’d be a GCC-only plugin. If you wanted to propose it as a patch for Clang though you might want to use the more standardized syntax.

With a little effort, you could generalize this too. Make the plugin load a list of context attributes and policies, something like SELinux. Functions defined with context A can only call functions with context A or B, and cannot be called from any function with context C, etc.
Asfrap_neiu

You can see monads in haskell as something similiar. For example to divide into pure and impure functions the IO monad is used
Asfrap_neiu

You can see monads in haskell as something similiar. For example to divide into pure and impure functions the IO monad is used
Manuel López-Ibáñez

You can create a GCC plugin that handles a user-defined attribute:

http://gcc.gnu.org/onlinedocs/gccint/Plugins.html

The difficult part would depend on exactly what you want to implement. Don’t be afraid to propose any enhancements to the plugin API that you may need, it is FAR from complete!
Manuel López-Ibáñez

You can create a GCC plugin that handles a user-defined attribute:

http://gcc.gnu.org/onlinedocs/gccint/Plugins.html

The difficult part would depend on exactly what you want to implement. Don’t be afraid to propose any enhancements to the plugin API that you may need, it is FAR from complete!
Karl Chen

You want CQual++. It allows defining custom type qualifiers and also infers them.
Karl Chen

You want CQual++. It allows defining custom type qualifiers and also infers them.

A C++ feature I would love to have: custom type modifiers

In C++ the const type modifiers when applied to methods has the nice property of making it impossible by default (e.g. without a const_cast) to call non-const methods. A similar feature is provided by C++0x keyword constexpr.

It would be very nice if this property could be applied to custom classes of functions. The idea would be to tag method definitions with a custom keyword, or a type. Tagged methods would then only be able to call method tagged with the same type.

A nice usage I could find for this would be to define a non-blocking class of methods. Non blocking methods are such if they never blocks for a potentially unbounded amount of time waiting for an event. Using the tags the compiler will be able to detect if a method supposed to be non-blocking is trying to call some potentially blocking code and this would be very useful to detect possible deadlocks at compile time. Another usage would be to tag all the methods that are supposed to be used by a specific thread with the same tag. With such setup methods that access shared data would be untagged and using them would require a cast or some special syntax, hopefully helping the programmer remember that some synchronization is needed.

A possible approach to (ab)use the volatile keyword to detect race conditions was described here in 2001. But maybe this approach could be more general. Any comment?

C++, deadlocks, threading

This entry was posted on March 18, 2011, 5:08 pm and is filed under Bar discussions. You can follow any responses to this entry through RSS 2.0. You can leave a response, or trackback from your own site.