:: Please check that your code compiles and works ok before checking it in to
:: the CVS ...
::
That doesn't help fully to solve the problem. Compiler and runtime libs are
different. So the check can only be done for one (or two) compilers.
Another problem are interferencing code changes in the evaluation phase
(currently 1 hour at my computer).
Currently my aim is, that the program is compilable with:
gcc 2.95.2
g++ 2.95.2
It is generally a good idea if a C program is (also) compilable with a C++
compiler. I've patched a lot of code, reached the aim at 5:30 a.m.
and now I got an executable. Several hundreds of warnings are remaining.
layer1 and layer2 decoding I have disabled. There are some ugly things in
it, I must correct separately:
struct bla {
int i;
char c;
};
typedef struct bla bla [32] [64];
struct bla a1;
bla a2;
a1 [12] [7] . c = 12;
a2 . c = 7;
Really nasty hacking stuff. C++ forbits it strictly.
In the future I suggest to test the code with C *and* C++.
It also increases the chance of portable ANSI C code.
:: I've repeatedly had to go fix compile errors in the CVS now... :P
::
I too.
:: Also it would be nice if you cast types that don't match the functions types
:: into the correct one
::
Casting is a bad thing. Correct the reason for the casting, not the warning
(or the error in C++) itself. See Ada Rationale. It is Ada related, but the
reasons are the same for every procedural language like C, Pascal, Ada, ...
Another idea is to use separate types for separate items. Changing the type
of an item becomes easy. The idea of C is that everything is an int, but
that isn't a very nice idea. You mix too much things with are fully
incompatible. And a sample frequency is for one person a long, for the next
a int, for a 3rd a unsigned int, the 4rd takes a float to save storage
and the last one takes a long double to reduce the danger of roundings.
Casts are the wrong way to hide this mess.
typedef long double samplefreq_t;
samplefreq_t in_sample_freq = 44100;
No mixtures of int, long, unsigned, float and double.
:: (or use the correct one to begin with) .. it's both the
:: correct and nice way to do it...
::
:: Also don't set ambigous types like "unsigned", use the proper full name,
:: "unsigned int".
::
Right. Some of them I have fixed, some of them are mine ;-(
:: And a problem I can't figure out right now is why LAME won't encode at all
:: anymore, it just creates an empty mp3 (that means it atleast opens it), and
:: then quits saying "Error writing mp3, disk full?" .. what have you done? ;)
::
Fixed. Bug of mime.
I've added a check of the return value of the final fwrite().
There are runtime libs out there which reports an error for the request of
writing 1 item of 0 bytes.
--
Mit freundlichen Gr��en
Frank Klemm
eMail | [EMAIL PROTECTED] home: [EMAIL PROTECTED]
phone | +49 (3641) 64-2721 home: +49 (3641) 390545
sMail | R.-Breitscheid-Str. 43, 07747 Jena, Germany
--
MP3 ENCODER mailing list ( http://geek.rcc.se/mp3encoder/ )
