[FFmpeg-devel] [PATCH 1/4] lavu: add simple array implementation

[Nicolas George]

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
success.

> 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
array.

> 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.

> between
> 
> printf(future extension, we might use this, 10234, 9999, 1234, yes,
>        no, reserved, hello_world_string, goto error /* this cant fail */);
> 
> and
> 
> printf(hello_world_string);
> 
> 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
moot:

Lukasz:
> 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
problem.

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).

Regards,

-- 
  Nicolas George
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140306/8895d8f1/attachment.asc>