Opened 7 years ago

Closed 7 years ago

#1357 closed enhancement (fixed)

no-call functions

Reported by: kolya Owned by: karlsharman
Priority: minor Milestone: HM-16.5
Component: HM Version: HM-16.2
Keywords: redundant functions Cc: ksuehring, davidf, karlsharman, jct-vc@…

Description

TComOutputBitstream::insertAt
TComDataCU::setCbfSubParts
TComDataCU::isFirstAbsZorderIdxInDepth
TComDataCU::deriveLeftRightTopIdxAdi
TComDataCU::clearCbf
TComDataCU::xGetMvdBits

Change History (12)

comment:1 Changed 7 years ago by DefaultCC Plugin

  • Cc ksuehring davidf karlsharman jct-vc@… added

comment:2 Changed 7 years ago by kolya

It seems that these functions are also orphaned:

TDecBinCABAC* getTDecBinCABAC()             { return this; }

const TDecBinCABAC* getTDecBinCABAC() const { return this; }
TDecBinCABAC::copyState( const TDecBinIf* pcTDecBinIf )
TDecSbac::load ( const TDecSbac* pSrc )
TDecSbac::load ( const TDecSbac* pSrc )

comment:3 Changed 7 years ago by kolya

One more orphaned substance

const TComMv operator +

comment:4 Changed 7 years ago by ksuehring

Well, the generic question is, whether a library should remove all functionality that is currently unused, or keep some helper functions that my be useful, if people want to experiment with the software. The + operator would definitely be in category of potentially useful stuff...

comment:5 Changed 7 years ago by kolya

Yes, there are some more as "dump" or "Check3" that could be used. The proposal is to mark it in a somewhat explicit way why the code should remain in a reference, if there is a need to leave it untouched.

comment:6 Changed 7 years ago by ksuehring

From the above lists, I think only

TComDataCU::deriveLeftRightTopIdxAdi()

looks like it should actually be removed as there is a direct reference to directional intra, which seems not to use this neighborhood anymore. The CABAC decoder load may also not be necessary, but as with the others I see no harm in keeping it.

The problem with marking library code as unused in comments is that nobody will care about removing the marking, when the code gets used again. Usually that happens in a completely different place without even noticing the comment.

comment:7 Changed 7 years ago by kolya

Okay, generally I think the approach "keeping as it is by default for reference s\w" is justified in a more reasonable way than permanent fixing, though there are technical means to force people to trace the unused things.

comment:8 Changed 7 years ago by ksuehring

  • Milestone changed from HM-16.3 to HM-next

comment:9 Changed 7 years ago by ksuehring

  • Milestone changed from HM-16.4 to HM-next

comment:10 Changed 7 years ago by ksuehring

  • Milestone changed from HM-next to HM-16.5

comment:11 Changed 7 years ago by ksuehring

  • Owner set to karlsharman
  • Status changed from new to assigned

comment:12 Changed 7 years ago by ksuehring

  • Resolution set to fixed
  • Status changed from assigned to closed

r4389 and r4386 remove the functions that we agree on. Closing the ticket as fixed.

Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber, Participant

  • David Flynn(Subscriber)
  • jct-vc@…(Subscriber)
  • Karl Sharman(Owner, Subscriber)
  • karl.sharman@…(Always)
  • Karsten Suehring(Subscriber, Participant, Always)
  • Nikolay Shlyakhov(Reporter, Participant)