"Ronald S. Bultje" <[email protected]> writes: > Hi, > > 2011/8/8 Måns Rullgård <[email protected]>: >> "Ronald S. Bultje" <[email protected]> writes: >>> On Mon, Aug 8, 2011 at 11:17 AM, Diego Biurrun <[email protected]> wrote: >>>> On Mon, Aug 08, 2011 at 11:00:40AM -0700, Ronald S. Bultje wrote: >>>>> On Mon, Aug 8, 2011 at 3:30 AM, Diego Biurrun <[email protected]> wrote: >>>>> > --- a/libavcodec/truespeech.c >>>>> > +++ b/libavcodec/truespeech.c >>>>> > @@ -33,13 +33,13 @@ >>>>> > */ >>>>> > typedef struct { >>>>> > /* input data */ >>>>> > - int16_t vector[8]; //< input vector: 5/5/4/4/4/3/3/3 >>>>> > - int offset1[2]; //< 8-bit value, used in one copying offset >>>>> > - int offset2[4]; //< 7-bit value, encodes offsets for copying >>>>> > and for two-point filter >>>>> > - int pulseoff[4]; //< 4-bit offset of pulse values block >>>>> > - int pulsepos[4]; //< 27-bit variable, encodes 7 pulse positions >>>>> > - int pulseval[4]; //< 7x2-bit pulse values >>>>> > - int flag; //< 1-bit flag, shows how to choose filters >>>>> > + int16_t vector[8]; // input vector: 5/5/4/4/4/3/3/3 >>>>> > + int offset1[2]; // 8-bit value, used in one copying offset >>>>> > + int offset2[4]; // 7-bit value, encodes offsets for copying >>>>> > and for two-point filter >>>>> > + int pulseoff[4]; // 4-bit offset of pulse values block >>>>> > + int pulsepos[4]; // 27-bit variable, encodes 7 pulse positions >>>>> > + int pulseval[4]; // 7x2-bit pulse values >>>>> > + int flag; // 1-bit flag, shows how to choose filters >>>>> > /* temporary data */ >>>>> > int filtbuf[146]; // some big vector used for storing filters >>>>> > int prevfilt[8]; // filter from previous frame >>>>> > --- a/libavcodec/vp3.c >>>>> > +++ b/libavcodec/vp3.c >>>>> > @@ -225,7 +225,7 @@ typedef struct Vp3DecodeContext { >>>>> > /* these arrays need to be on 16-byte boundaries since SSE2 >>>>> > operations >>>>> > * index into them */ >>>>> > - DECLARE_ALIGNED(16, int16_t, qmat)[3][2][3][64]; >>>>> > //<qmat[qpi][is_inter][plane] >>>>> > + DECLARE_ALIGNED(16, int16_t, qmat)[3][2][3][64]; // >>>>> > qmat[qpi][is_inter][plane] >>>>> > --- a/libavfilter/vf_drawbox.c >>>>> > +++ b/libavfilter/vf_drawbox.c >>>>> > @@ -34,7 +34,7 @@ enum { Y, U, V, A }; >>>>> > typedef struct { >>>>> > int x, y, w, h; >>>>> > unsigned char yuv_color[4]; >>>>> > - int vsub, hsub; //< chroma subsampling >>>>> > + int vsub, hsub; // chroma subsampling >>>>> > } DrawBoxContext; >>>>> >>>>> All these are struct members, are you sure you want to drop their doxy? >>>> >>>> I see little point in (doxygen) documenting structs only used in a >>>> single file and/or documenting only single struct members. But I >>>> can surely be convinced of something else... >>> >>> We do that in many decoders. It helps to document the implementation >>> if ever, in the far far future ahead, the original author disappears >>> and some poor new soul has to fix bugs or add new features instead. >> >> Plain comments are good enough for that. Doxygen is mostly intended to >> generate documentation for people who otherwise have no reason to read >> the code. > > The idea is "have documentation open in browser, and look at actual > code in editor". Otherwise you need multiple code editors open.
I do not want code from someone who cannot cope with multiple editor windows. -- Måns Rullgård [email protected] _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
