Changes between Initial Version and Version 3 of Ticket #785


Ignore:
Timestamp:
Mar 30, 2014, 11:56:39 AM (9 years ago)
Author:
Peter
Comment:

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #785

    • Property Status changed from new to assigned
  • Ticket #785 – Description

    initial v3  
    22
    33It's a couple of things:
    4   1) Create a CIGAR from an aligned Aligner.
    5   2) Output a CIGAR (see `BamRead::cigar_str(void)`)
    6   3) Set the CIGAR of BamRead (which already possible via `BamRead::cigar(const std::vector<uint32_t >& c)` )
    7   4) Modify the CIGAR, possible restrict modification to `clear`, `pop_back`, and `push_back` or if possible mimic `std::vector` (depends on implementation details).
     4  1. Create a CIGAR from an aligned Aligner.
     5  2. Output a CIGAR (see `BamRead::cigar_str(void)`)
     6  3. Set the CIGAR of !BamRead (which already possible via `BamRead::cigar(const std::vector<uint32_t >&)` )
     7  4. Modify the CIGAR, possible restrict modification to `clear`, `pop_back`, and `push_back` or if possible mimic `std::vector` (depends on implementation details).
    88
    99The question is whether we should keep storing this information in a `vector<uint32_t>` as suggested by 3) or if should create a new class. Either way I think the functionality should be available also when `configure --without-samtools`, so even if we use some `#define`s from `bam.h` we can port them [conditionally] to a yat header. New class, Cigar, or keep on with the vector? The latter implies free functions (C-style) where the former means member functions.