Hi, On Fri, Oct 16, 2015 at 8:03 AM, Ganesh Ajjanagadde <gajja...@mit.edu> wrote:
> On Thu, Oct 15, 2015 at 11:21 PM, Ronald S. Bultje <rsbul...@gmail.com> > wrote: > > Hi, > > > > On Thu, Oct 15, 2015 at 8:37 PM, Ganesh Ajjanagadde <gajja...@mit.edu> > > wrote: > > > >> Hi all, > >> > >> Examining libavutil/macros, there is AV_GLUE/AV_JOIN (why are there > >> two?) defined for preprocessor token pasting. However, it is not being > >> used anywhere, instead people have use "##". There are a number of > >> options regarding this: > >> 1. Start using them, and convert the ## usage to AV_GLUE/AV_JOIN. > >> 2. Don't bother at all. > >> 3. Deprecate and remove them at some point. > >> > > > > ../libavcodec/flacdsp_lpc_template.c:#define FUNC(n) AV_JOIN(n ## _, > > SAMPLE_SIZE) > > ../libavcodec/flacdsp_template.c:# define FSUF AV_JOIN(SAMPLE_SIZE, > p) > > ../libavcodec/flacdsp_template.c:#define FUNC(n) AV_JOIN(n ## _, FSUF) > > ../libavcodec/h264_mb_template.c:# define FUNC(n) AV_JOIN(n ## > _simple_, > > BITS) > > > > You have to understand _why_ we use this. The problem is that in some > cases > > (sometimes in a compiler-dependent way, other times more generally), you > > need to expand preprocessor tokens before concatenating them. Older > > versions of MSVC were bad at this, but you can see gcc suffers from it > also > > if you look for uses of cat() in > > libavcodec/x86/vp9dsp_init_16bpp_template.c. If you change cat into just > > ##, it stops working. > > > > And yes, cat, should probably be AV_JOIN, I forgot about AV_JOIN. > > Got it, thanks. I still suppose AV_GLUE is redundant (isn't it the > same as AV_JOIN in all these use cases?). To force-expand, you sometimes need to call a macro in a macro. Again, see cat() - all uses are themselves in macros. Let's say I wanted to use BPC directly in a line of actual code - it would fail. By making a macro call another macro (catcat, basically), we force-expand preproc tokens and everything works as expected. So I guess AV_JOIN is public and AV_GLUE is an internal implementation detail, but since it's in a public header, we gave it a prefix. Ronald _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
