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

[Michael Niedermayer]

On Thu, Mar 06, 2014 at 11:38:17PM +0100, Nicolas George wrote:
> 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).

that sounds ok to me
buth i cant speak for others


8...]

-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

What does censorship reveal? It reveals fear. -- Julian Assange
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://ffmpeg.org/pipermail/ffmpeg-devel/attachments/20140307/cb770a88/attachment.asc>