Here is the first public preview of the source translation of lossyWAV 1.3.0 to C++. It is not finished, but the main work is done.

- vc10_err.txt list the current compiler output in Visual Studio C++ 2010.- A number of built-in Delphi functions are not yet converted. Most are trivial, but Write() involves some work.

Please note, I know very little of how the code actually works, I basically translated it line by line, and did minor optimizations.Developers can look over the code and compare with the Delphi source. I have tried to take into account a number of C++'s quirks, e.g.:- integer / integer -> integer (not floating point, but if one operand is float, it returns float)- unsigned int (opr) signed int -> unsigned int - & is bitwise-and, && is boolean-and, likewise with or: |, || - c++ base 0 arrays, versus base X in delphi. (range_array class in nSupport.h emulates that)

At last, i'm not sure if it will be of help, or it will add to confusion, but these two source files might help on the file loadingriff.cppriff.hppThat's a .wav file load/save in a mixture of C and C++. (Not the best code anyway, it was scheduled for improvement, but since it works, it has been kept)

I canít claim to be an expert, but I thought that the reason C99 introduced these numbered types in its stdint.h was due to a demand for integers of known and fixed widths, with the result that these types are guaranteed to have the corresponding widths in bits. Although it may not matter for lossyWAV, I would say in a general sense that typedefing them to be equivalent to standard types, which come with no guarantee of a given fixed width (you get a minimum width at best), doesnít seem an adequate compensation for a compiler that lacks stdint.h.

I was going to say it was good (and my something-new-learned-today) that Microsoft provide a way (albeit proprietary, but who would’ve expected anything else?) of defining fixed widths, but then I read about their types, and they seem to be merely a different flavour of syntactic sugar for the same non–fixed-width standard types:

The types __int8, __int16, and __int32 are synonyms for the ANSI types that have the same size, and are useful for writing portable code that behaves identically across multiple platforms. The __int8 data type is synonymous with type char, __int16 is synonymous with type short, and __int32 is synonymous with type int.

FWIW, there are implementations of stdint.h that can be used with VC(++), or there’s Boost.

It’s not my intention to assert (geddit?) a problem where they might not be one, and I’m not meaning to blame anyone for C/C++’s lack of well-defined boundaries in various contexts, but I’m just mentioning all this in case it might matter to the project at hand.

Thank you guys. I already did IntToStr() and Copy(), but the rest goes straight in. Actually, I simply replaced directly Copy() with substr() and did the -1 adjustment. I've defined variables in cpp files, and implemented Bit_Scan_Left() and ..Right(). Both GCC and Visual Studio have intrinsic functions for these, and they are now used. There is a C-implementation for other compilers/HW as well. /add: I've also done Val()

I think the stdint.h thing is a minor problem, only the int32_t and int64_t are used. Most important now is to get it working on ONE compiler, then it's a simple matter to port it to others (older etc).

The WAV-reading files could possibly be used, although I hope it's is easier to implement the rest of the Delphi IO functions that are missing. These are roughly:

Here is v03 of the translation. (I didn't publish v02). I know its silly not to use github, but I haven't gotten around to it. To compare the two directory trees, use WinMerge. Now, it almost compiles, only complaining about some missing functions, and two more issues:

These calls should replaced by the native c++ <iostream> lib calls in nWav.cpp and nParameter.cpp without making wrapper function. I would be happy if someone (JAZ?) would take the job - it's not hard, but I need a break. Google "Append delphi", etc. will give the required documentation at delphibasics.co.uk.

Write <-- this is harder, may wait (empty function defined in nSupport.h)datetimetostring

Nick, also the argument to datetimetostring() call in nCore is a little mysterious to me - not sure handle that one.

I finally made it to link successfully, however it does not work yet. I have only tried it once, and it fails on trying to read a wav file although no arguments are given. Something with the parameter checking must be wrong. The program must be compiled and run with a debugger, to ensure that it does what it is supposed to.Notes:

I have used gnu g++ 4.7.0 via Qt Creator (CMake) for the last part of the translation, not sure if it will compile cleanly in Visual Studio anylonger.

Many of the Delphi structs were "Packed Record" types, meaning they have non-aligned members. There is a #pragma pack() feature in C as well, but it's not portable, and slows down processing. Please identify which, if any structs needs to be "packed". Typically if the WAV format has "unaligned fields" that are directly read from/written to data structures. Check sizeof(struct) if they are of expected size.

The Delphi functions filegetattr(), filesetattr() are not translated (yet), only used for checking and forcing to write on read-only output files.

Version checking stuff is translated, but commented out. The version is simply set (some constants should be made or a file with version could be #included). Also, this code wouldn't be possible to translate to Linux anyhow.

Global initialization objects in each translation unit (each .cpp file) may have some issues because the sequence of them are random. Initialization could better be done explicitly from the main() routine, in a controlled sequence.

The Delphi text Write() function calls has optional formatting in arguments (like :6:4). These are commented out, but can be emulated closely by by inserting << setw(n) and << setprecision(m), etc.

I may have done all sorts of other errors during translation, please verify with the original source. The translation still matches the original closely, and it should stay so until it works.

DirectoryExist() function is not translated yet. Only an empty function returning true in nSupport.h for now. Must be done.

I have limited time to follow up on this before Christmas, so any help to get this working is welcome..

I''ve got it to compile with Dev-CPP. It doesn't't like strings inside structures and parameter passing was a bit tricky. I''ll post a revision in the development thread when I have something worthwhile to contribute.

I''ve got it to compile with Dev-CPP. It doesn't't like strings inside structures and parameter passing was a bit tricky. I''ll post a revision in the development thread when I have something worthwhile to contribute.

Ok. I have fixed the initialization problems, and more, so now it actually goes all the way to the main processing loop, and things look good up until there in the debugger. The main loop is slow as heck, and puts out garbage, so something is very wrong - haven't looked at it. I'm now back to using Visual Studio 2010, using the debugger there.