I didn't know about possible problems in floating point rounding behaviour, I haven't looked, but I'd be surprised if they're significant in the magnitude range of stats calculations the library performs (I'd like to be warned if this is wrong!).
I read Katz's articles, and I claim there's a fair bit of bluster and bullshit in what he says about C being a *high level language*. I wrote assembler daily for 12 years and when I bought the C/C++ SDK 3.1 in 1992 so I could learn this mystical and legendary language C (and C++ a soon after) I was quite shocked to discover that C is basically a pretty indented version of assembler, although much more friendly and productive in comparison. I actually wished I had been writing C instead of assembler for all those years. And "callable from anywhere" and "small surface area APIs" ... who's leg is he pulling? Of course, C is highly dependent upon the libraries is consumes, making it little more than "library glue" to me. Anyway, it looks like the Borland code bulk reads UTF8 files and applies various well known statistical algorithms to the data. So I'm still hoping it won't be hard to migrate. The reason behind this migration is more peculiar: there are appalling performance bugs in the Borland math libraries of Sin, Cos, etc that apparently will not be fixed, so the guys are using this as a first step as a planned migration completely away from Borland/Embarcadero to the Microsoft world. There are other issues of course, but overall they're fed up with the Borland culture and directions and want to go "mainstream". I hope they're not jumping out of the frying pan into a bigger flying pan. *GK* P.S. In previous days I've been reading about "Modern C++" ... Are people here following the style? Guess what I reckon Modern C++ looks like ... C# and Java. I wonder how Stroustup feels about that. On 6 January 2015 at 13:56, Thomas Koster <[email protected]> wrote: > On 5 January 2015 at 10:47, Greg Keogh <[email protected]> wrote: >> >> Folks, I might have to migrate some Embarcadero/Borland C (not C++) code >> over to Visual Studio, but I haven't written any C/C++ for about 10 years >> now (thankfully). The C code mostly manipulates flat files and performs >> heavy stats calculations, so there are no serious platform dependencies to >> make conversion difficult. > > > These two posts by Damien Katz (creator of CouchDB) are inspiring reading > if you are concerned that going back to C is a regression: > > - > http://damienkatz.net/2013/01/the_unreasonable_effectiveness_of_c.html > - http://damienkatz.net/2013/01/follow_up_to_the_unreasonable.html > > His message is: C is exactly as high- or low-level as the libraries you > are using with it. If you think C is too low-level, then you are using the > wrong abstraction. > > On 5 January 2015 at 19:15, Greg Harris <[email protected]> > wrote: > >> Not being a C++ guy I can not tell you when the // style comment came in >> for C based languages :-) >> > > C has supported "//" comments since C99[1]. > > However, Microsoft Visual C++ does not support C99 before version 2013, > and even in 2013 it only supports a subset of C99[2]. Still, I would be > flabbergasted if that subset did not include "//" comments. > > Anyway, if "heavy stats calculations" means "heavy calculations > on floating point numbers", then that is an area where C99 does differ from > C89, especially with regard to rounding[3], which apparently had > unspecified semantics before the C99 standard. > > You do want to check that MSVC++ 2013 is a reasonably compliant C99 > compiler re IEEE 754 floats (it probably is because it includes > "fenv.h"[2][3]) so that irrespective of whether Borland's compiler is or is > not, you can reproduce the Borland compiler's behaviour using the new C99 > macros (or fix previously unfixable rounding bugs with them!). > > So you thought that there were no serious platform dependencies, eh? > > [1] ISO/IEC 9899:1999, 6.4.9.2 > [2] > http://blogs.msdn.com/b/vcblog/archive/2013/07/19/c99-library-support-in-visual-studio-2013.aspx > [3] ISO/IEC 9899:1999, 7.6 and annex F > > -- > Thomas Koster > >
