On Wed, 2007-08-08 at 21:59 +0200, Christian Thaeter wrote:
> I didn't meant that this way, for myself I am rather pro C (or using a
> real high level language). I'd rather meant fixes should be done in
> proper C++ way when the whole sourcefile is C++, for consistency and
> robustness. I really appreciate your contribution and I don't feel
> myself in a position to judge about inclusion or refusing such. I asked
> if you may rewrite it in C++ which was really a informal question, if
> you don't wan't to or can't do that then someone else might do that,
> maybe I take a look next week and do it, if not I think better apply
> your C way than leaving a bug unpatched. Kudos to you for your work!
Thanks. I could try writing it in as an object.
I am thinking I have an almost irresistible urge to strip out the
C++ ;). You may ask why. Well, my answer is because sometimes I think it
produces more problems than it solves.
Look at the following piece of code in Cinelerra file.C:
case FILE_UNKNOWN:
FILE *stream;
if(!(stream = fopen(this->asset->path, "rb")))
{
// file not found
return 1;
}
char test[16];
fread(test, 16, 1, stream);
if(FileDV::check_sig(this->asset))
{
// libdv
fclose(stream);
file = new FileDV(this->asset, this);
}
else if(FileSndFile::check_sig(this->asset))
{
// libsndfile
fclose(stream);
file = new FileSndFile(this->asset, this);
}
else
if(FilePNG::check_sig(this->asset))
{
// PNG file
fclose(stream);
file = new FilePNG(this->asset, this);
}
etc. There are other places that this pattern is repeated. Now, if we
were to define a table of functions { file_dv_check_sig(),
file_snd_check_sig(), file_png_check_sig() ...}
we could perform iteration over that table, and essentially reduce the
code to about a tenth of what it currently is. C++ just gets in the way.
You can do other stuff with macros to expand the table, to make other
things possible. So, in the iteration, you could return a structure
file_handler as a result of iterating over the table. When you want to
call read_frame(), you write
file_handler->read_frame()
and you eliminate all of the switching that the class File calls for
that particular task (OK maybe there are complications and you have to
use a "category" of file handlers instead, but even then that's
soluble).
I'm watching the videos of the lectures on SICP, so perhaps I'm being
brainwashed into thinking in functional and layered terms ;) A
functional language might be a good one to use (although the Lispers
seem to poo-poo the notion of strong types) - and I'm not proposing that
we actually do it - it's just that sometimes I wistfully think everyone
is writing in C (or C++). The idea of not having to deallocate memory or
run into memory overruns and so on is quite appealing.
_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
