Opened 9 years ago

Closed 9 years ago

#779 closed discussion (wontfix)

Behaviour of BamHeader copy constructor

Reported by: Peter Owned by: Peter
Priority: major Milestone:
Component: omic Version:
Keywords: Cc:


BamHeader does not own its underlying data but is only valid as long as corresponding BamFile is open. Is this the desired behaviour or do we wanna make the BamHeader more independent. There is a function bam_header_dup in sam.c that could be used to create an independent header*.

See docs added in r3158

Changing the behaviour is not a problem in terms of compatibility as the change would only add behaviour for code that in yat0.11 is undefined - and since a BamHeader is read only making them independent (hard copy) has no effect in terms of: "hey I changed the header and that used to effect all copies of it".

The pro with the change is obvious. You can kill the BamFile and still have a valid header object (just had a segfault due to current [undefined] behaviour). The con is that it makes the code more complicated. How is the assignment implemented? Can all instances own their data. Probably yes, except the original one that is held privately in InBamFile. That one is destructed by samclose in BamFile destructor. Is it confusing to have ownership sometimes and sometimes not, or is it OK in this case since the non-owner case is private?

Change History (2)

comment:1 Changed 9 years ago by Peter

Milestone: yat 0.x+yat 0.12

comment:2 Changed 9 years ago by Peter

Milestone: yat 0.12
Resolution: wontfix
Status: newclosed

bam_header_dup is not included in API but only declared in source files, which makes the change suggested in description impossible to implemented (in a sensible way).

Note: See TracTickets for help on using tickets.