Project

General

Profile

Bug #1500

Entry Methods Always Take lvalue References (feature/bug)

Added by Nils Deppe about 1 month ago. Updated about 1 month ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
04/12/2017
Due date:
% Done:

0%


Description

I'm filing this bug/feature request is mainly to start a discussion of C++11 and template metaprogramming being used to simplify or even eliminate Charm interface files.

Currently if I declare a function argument as pass-by-value in an Interface file the generated function in the .def.h file still takes a const lvalue reference to the object. I realize there are likely deep reasons for this implementation. However, it would be very nice to have an interface that is more C++ compliant. Currently it seems like one must have a callback to delete any data that was sent, which seems like wasted communication. (Is there a better approach that I don't know of? Messages seems like an option) If entry methods were function templates in general then maybe forwarding references could be used together with SFINAE to do some automation of "doing the right thing". That is, if the deduced type is an lvalue reference the current implementation is used, but if it is an rvalue reference then the data should be stored locally somehow since this is generally what the programmer would be expecting.

Unfortunately I think resolving this issue would require C++11 and potentially a fairly major redesign of the way Charm entry methods work. However, not knowing how the latter works in detail I cannot comment on it. I saw some bugs about use "pure C++" for entry methods but because there wasn't a detailed description I'm not sure if they are getting at the same issue. I think this would be an interesting problem to approach with template metaprogramming in C++11.

History

#1 Updated by Phil Miller about 1 month ago

  • Target version changed from 6.9.0 to 7 (Next Generation Charm++)

This is indeed the direction we're aiming to go, and want to move on in the not-too-distant future. There's room for big reductions in how much the user has to write, and also performance improvements (e.g. bug #921). We'll look forward to discussing this with you (e.g. at the workshop), and try to get more of our plans and ideas out in the open so that users can see it.

#2 Updated by Nils Deppe about 1 month ago

Okay, that's really good news. We would be happy to be involved in brainstorming, development and testing of any new infrastructure. We've made very extensive use of template metaprogramming in our code. Almost everything is decided at compile time that can be and with C++11 compilation time doesn't need to increase much, even with very TMP heavy code. We also have a very generic wrapper around Charm++ arrays that we are planning an making more generic in the near future (weeks timescale). This will hopefully be useful for drawing some inspiration and learning some lessons on where to go with TMP in Charm++.

Also available in: Atom PDF