[FFmpeg-devel] [PATCH 1/4] lavu: add simple array implementation
george at nsup.org
Thu Mar 6 23:38:17 CET 2014
Le sextidi 16 ventôse, an CCXXII, Michael Niedermayer a écrit :
> compiler errors to such macros are cryptic and cost more time
> to fix. get the "code passed as argument" wrong and the compiler
> will likely have a hard time to figure out what is wrong, it really
> cant know if your macro or the code using it is at fault if the
> result is a syntax error
> This doesnt occur with functions
These arguments were not present in the message I was answering to.
As for the actual reply: I agree this is a drawback, it must be weighted
against the advantages. In this particular case, I believe the drawback is
not severe, as the statements are likely to be very simple: probably a
single return or goto for failure, and nothing or an affectation for
> An API thats designed with
> "And the beauty of that kind of API is: if you don't like it, don't use it."
> will probably not improve that
What I was emphasizing here is was that this kind of API intrudes. If the
API uses a specific data structure, using it is mandatory to interact with
parts of the code that use it too. In this case, it is a single standard C
> Its important that the developers like the API because if they end
> up not using it then no matter how great it is in theory it wont
> help them in practice
But not all developers have to like all APIs.
> printf(future extension, we might use this, 10234, 9999, 1234, yes,
> no, reserved, hello_world_string, goto error /* this cant fail */);
> i find the later more readable, that is needing less of my time.
There is a real difference between adding useless arguments with dummy
values just in case and adding arguments with a clearly defined semantic
while knowing they will likely be used with always the same value.
But as you can see in the proof-of-concept code I posted, this point is
> I agree with wm4 that removing success part would be nicer. It can be
> done outside the macro.
If the macro accepts a statement and you do not need it because you do the
work outside the macro, then you leave the statement empty, that is not a
If the macro does not accept a statement and in some circumstance you can
not do the job outside, you are screwed.
A lot of if()s do not have an else...
To conclude, I would suggest: define the macro, in a separate header, and
use it to build the _nofree variant you proposed (but with variable element
size, for good measure).
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 819 bytes
Desc: Digital signature
More information about the ffmpeg-devel