Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

StringPulseIslandMap etc #144

Open
litchfld opened this issue Jul 5, 2014 · 4 comments
Open

StringPulseIslandMap etc #144

litchfld opened this issue Jul 5, 2014 · 4 comments
Assignees
Labels
Milestone

Comments

@litchfld
Copy link
Contributor

litchfld commented Jul 5, 2014

In the file definitions.h we have several typedefs for containers of XxxPulse containers (see bottom of post).

I've been going round the way memory is allocated during I/O all afternoon, and I've come to the conclusion these aren't useful. The scheme I planned out with Ben is that each container of XxxPulses resulting from a particular source is stored in a branch. That means I have to be able to pass the address of each container to the tree, and it will stream to and from those memory locations. This is not compatible with the containers that have been typedef below because they all store the XxxPulse containers by value, and STL containers reserve the right to reorder things in memory, meaning I can't do

ChannelPulseIslandMap myCpiMap;
//...
IDs::channel cid;
fTree->SetBranchAddress(&(myCpiMap[cid]))

and furthermore it isn't sensible to pass in pointers to known locations, then refer to these when to create a map - it would require mass copying of the vector each time. Much more efficient to have maps where the value_type is a pointer.

So the I/O is not going to use these containers internally, and as a result it isn't ever going to accept or return one. Would it be sensible to replace them containers of pointers?

// Typedefs of PulseIslandList  containers
typedef std::map<IDs::channel, PulseIslandList> ChannelPulseIslandMap;
typedef std::map<std::string, PulseIslandList> StringPulseIslandMap;
typedef std::map<std::string, ConstPulseIslandList> StringConstPulseIslandMap;

// Typedefs of AnalysedPulseList containers
typedef std::map<IDs::source, AnalysedPulseList> SourceAnalPulseMap;
typedef std::map<std::string, AnalysedPulseList> StringAnalPulseMap;
typedef std::map<std::string, ConstAnalysedPulseList> StringConstAnalPulseMap;

// Typedefs of DetectorPulseList containers
typedef std::map<IDs::source, DetectorPulseList> SourceDetPulseMap;
typedef std::map<std::string, DetectorPulseList> StringDetPulseMap;
typedef std::map<std::string, ConstDetectorPulseList> StringConstDetPulseMap;
@jrquirk
Copy link
Contributor

jrquirk commented Jul 6, 2014

Let's also remember typedefs sometimes obfuscate instead of elucidate. Source

@AndrewEdmonds11
Copy link
Contributor

I've always been worried about this, it's nice to know that there are other people who think the same

@litchfld
Copy link
Contributor Author

litchfld commented Jul 7, 2014

Oh come now, we don't follow any of the conventions in that guide (or any other, AFAIK). Why single that one out for special treatment? =)

Less flippantly, I like that there are typedefs for some of these (the ones we actually use), since they are central enough to be practically be classes---in a bigger project, they almost certainly would be. It's just they are currently defined to types I can't make use of.

@litchfld
Copy link
Contributor Author

litchfld commented Jul 8, 2014

That means I have to be able to pass the address of each container to the tree, and it will stream to and from those memory locations.

Edit: looking closer, i have to store the address of a pointer to a container of pointers. i.e.

std::vector<TPulseIsland*> list_of_TPI();
TTree branch("blah" &&list_of_TPI);
//I.E.
std::vector<TPulseIsland*>* plist_of_TPI = new std::vector<TPulseIsland*>();
TTree branch("blah" &plist_of_TPI);
//or even
std::vector<TPulseIsland*>** pp = &plist_of_TPI

If i got that right then that last one is typed so that one can do:

TPulseIsland& foo = **((**pp).begin())

=S

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants