On 31/08/11 16:18, Ben Greear wrote: > On 08/31/2011 04:55 AM, [email protected] wrote: >> diff --git a/xorp/libxipc/SConscript b/xorp/libxipc/SConscript >> index 104bc8e..e7cf973 100644 >> --- a/xorp/libxipc/SConscript >> +++ b/xorp/libxipc/SConscript >> @@ -87,6 +87,7 @@ libxipc_sources = [ >> 'xrl_std_router.cc', >> 'xrl_tokens.cc', >> 'xuid.cc', # only for udp (and fea tcpudp mgr) >> + 'fp64serial.c', >> ] > > It should be a .cc file I think.
It was intentional. It appeared to be the easiest way to access certain C99 features portably - they don't all appear automatically in C++ (so I discovered). I don't think finding a strictly C++ solution buys you very much for the effort - it's just two ordinary functions that don't use any C++ features. Is it vital to be C++ for other reasons? I'll put the effort in if so. >> +// $XORP: xorp/libxipc/xrl_atom.hh,v 1.23 2008/10/30 20:49:07 pavlin >> Exp $ > > Please just remove the previous line. Ew - will do. > In general, I'm amazed at how much code this took, but from skimming > through > it quickly, I didn't notice any issues. I guess floating-point > serialization > is just a pain in the arse to do right! It's a matter of recognizing that double has many implementation-defined characteristics, so it can't just be shifted and masked like an integer. frexp, ldexp, etc allow it to be expressed more portably, and shouldn't be too costly on most systems. In practice, you could probably just alias a double as uint64_t on most systems, but I don't think there's a robust, portable, general way to detect this at compile time. Of course, you could still detect specific environments, and conditionally compile in a trivially cheap implementation, but at least you have the portable code as a back-up for everything else. Cheers! _______________________________________________ Xorp-hackers mailing list [email protected] http://mailman.ICSI.Berkeley.EDU/mailman/listinfo/xorp-hackers
