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

[Don Moir]

----- Original Message ----- 
From: "Nicolas George" <george at nsup.org>
To: "FFmpeg development discussions and patches" <ffmpeg-devel at ffmpeg.org>
Sent: Wednesday, March 05, 2014 7:46 AM
Subject: Re: [FFmpeg-devel] [PATCH 1/4] lavu: add simple array implementation


>Le quintidi 15 ventôse, an CCXXII, Don Moir a écrit :
>> You got anything else idiodic to say or is that the best you can do?

>With that acerbic remark, you just show you missed the point completely.

Was tired last night and mostly things like that don't bother me. I actually trust arrogance as opposed to someone just rolling over 
as long as it's well founded.

>The line of reasoning that you are following is exactly the same that drives
>the design of java's API: you have an interface, and then an abstract class
>that implements the interface, and then an actual class that extends the
>abstract class, and yet another class to extend the previous one, and at
>each level there are two or three more variants that implements another
>interface too or use a slightly different data structure. I am not making
>this up: can anyone remember the relations between List, Vector, Collection,
>ArrayList, Set without perusing the doc? And do not get me started on the
>thread-safe / thread-unsafe variants.

I have had to do quite a lot of java coding and I am not a big fan for reasons you state.

>The marketing pitch for that is that you should use the interface you need,
>and any implementation will work with it. The reality, for complex projects,
>is that different parts have different needs and chose different interfaces
>and implementations, and are therefore incompatible.

Java is too much object oriented for my taste.

>...In C, a dynamic array is a
>pointer to mallocated memory, plus an integer to store the size. That is it.

True at the lowest level. It becomes a balance between passing off more of the implementation to everyone else or to incapsulate it 
somewhat to make it easier to use, debug, and maintain.

>For example, there is no need for a "deleter", because you usually know at
>build-time what your array contains and how to free it. Of course, you can
>add that king of things in a complex high-level data structure, because it
>does not cost much.

Technically there is no need for formal array functions and everyone can just roll their own. Of course libraries try to encapsulate 
some things so it can be used generally as building blocks. Too much generalization can lead to inflexibility and not enough causes 
the same code to be written over and over again.

No one is talking about a complex data structure here. Just basic array management thats a little more than what you have now but is 
smarter and less of headache for someone trying to use it.

A 'deleter' is of course optional and not needed but it helps to encapsulate the case when it is useful. Or everyone can just delete 
the array item pointers if needed and then delete the array referenece and do this over an over. Why not optionally encapsulate it? 
It cost nothing to speak of.

My roots are in C and asm. When C++ first came about, I said oh shit mostly because I could see people going haywire about objects 
etc. I went to C++ not for objects at first but because it's a better C than C89 was for just a couple basic reasons. Stronger 
typing, mixed declarations and statements, and default parameters. Mixed declarations and statements leads to cleaner and more 
readable code. Default parameters is something that I don't really like to use too often because it hides the intent somewhat, but 
it is very useful for testing things out without changing code.

My array class is pure C and very efficient. It has maybe about 10 functions to support it. Like delete, delete range. swap, lock, 
push,  pop, etc. Just things I have found needs for over and over.

My C++ template class just calls the C code. It overrides new and delete. The memory allocation is handled inside the C code. new in 
this case does not allocate any memory and just calls the class for initialization if needed. delete just calls the destructor if 
needed and other house cleaning.

The C++ template just makes life easier. The C implemention is just called ARRAY. It's just a structure that defines a few useful 
elements. The template class is called cArray. All this does is type things and makes management easy at no real expense. It just 
calls the C code.

So I might have a struct or class defined as:

typedef struct my_array_item
{
    int a;
    int b;
};

Could have constructor or destructor but trying to keep this short haha.

So I need an array.

cArray<my_array_item>my_array;

All the initialization is done. It knows the size, the type, and other things. I use this kind of thing a lot and god knows I am 
glad I don't have to keep repeating the same code over and over. Nested arrays are just as easy. No memory allocations are done 
until needed so the constructor of the array cannot fail.

a reference to a my_array_item can be:

my_array [i]->a;

I don't overdo objects and you can make a mess in any language.

Sorry to run on but get that way when tired. I have a lot more to say but not sure if you care.