Hello Amol,
On Mon, 25 Jul 2005 22:18:15 UTC, "am*****@gmail. com" <am*****@gmail. com>
wrote:
Is there any open source C++ library that performs platform independent
binary file I/O?
There are libraries that help with that sort of thing. They aren't
a requirement for platform independance though.
Major concerns being endianness,
Byte order is a fairly simple concept to encode correctly. The problem
is determining what format the data is in. There are a few simple coding
techniques that can be used to determine the endianness and wordsize of
your target platform. It is much easier to simply establish a standard
binary format and be able to translate between that and your current
machine architecture.
structure alignment,
This varies by platform and can be difficult for some platforms to
manipulate. Various alignments are easy on 80x86 architecture but
somewhat harder on other platforms. Again, it is establishing a standard
format and allowing that some architectures may have trouble encoding
that format.
size of data types on different platforms, 32-bit
vs 64-bit architectures and format of floating point numbers. Can
someone give a clear cut explanation on how this could be achieved
using some snippet if possible? A preliminary demonstration of
serializing and deserializing a float could be a good starter ...
Okay, let's say we decide to use a given floating point format
as our standard and that standard defines that values are encoded
in a four (eight-bit) byte in a certain byte order. All you need
is to write a small routine to: A-decide what byte order to read/write
the data, and B-to read/write a floating point value. Floating point
values could be problematic if your machine supported a floating
point encoding format that was fundamentally different than what your
data file format would be.
Thanks
Amol
The ACE library has some code to help with this. So do the standard
TCP/IP libraries. You might also try looking up references for
"network byte order".
Many years ago I needed to load/store and communicate with a large
tree of data that some might use XML for today. It used TLD or
Tag-Length-Data formatting. Basically you write a tag that states
what comes next, its length, and the data. It is just a binary form
of XML-like encoding.
The byte encoding was defined for all related programs. The underlying
tree structure was written exactly once with an in-memory object oriented
access mechanism. Every object (class) also had to include its own
encode/decode (<< and >>) operators. The code for this data structure
was written entirely in portable code. I also mandated that no other code
be added to this particular module/library. Thus, I had all access
mechanisms
to the data, binary encode/decode, and data validation all in one library.
The low level data started with Flags, Bytes, Strings, Integers, and
so on. Then I'd derive from String and create something like NumericString.
Tha might be derived from and called NADPPhoneNumber . (NADP stands for
North American Dialing Plan). Another derivation was for WorldPhoneNumbe r.
Various friendships and conversions were allowed so that you could easily
convert from one similar format to another. Validation errors were
mandatory
so something like
NADPPhoneNumber MyPhoneNumber = "+1236546786524 432ABC";
was gauranteed to throw an exception if the action wasn't legal. The
general
goal of the library was to encode all the information for processing
an automated or manual phone call and recording the processed results. It
could be used for file storage, passing a call-in-process from an automated
call handler to a manual operator, and so on.
A second library was then developed that duplicated this object-tree
structure that was UI specific. So there was a self describing GUI with
editors for all of the data classes. Validation at this level was somewhat
more meaningful and the example above would be flagged as having an error
and the error text could be read. A simple arrangement of GUI design
made it easy to build complex and user-friendly editors.
The base structure only had 300 or so classes and never required any
fixes. Classes were added as the project evolved.
As layers were added, so was a drag-and-drop GUI editor for constructing
the phone call. The goal of all this was to take a shop that basically
programmed every call into real code and convert it to one that could
allow end users the ability to construct their own phone call systems
reusing the companies automated systems and operators. Since the system
supported validation at all levels, the end user knew if the description
was correct. Behind the scenes valdiation also allowed incorrect
descriptions to be rereouted back to customers. It was a very productive
nine month project that drastically changed a well known telephone company.
New phone call ideas could be created and implemented based on interpreting
the demands of the lower level call handling structure and passing the
results between machines as needed. Eventually the system added a few
more bells and whistles and it also build web pages to go along with the
automated attendants and operator centers. It was a great inbound only
call center solution that allowed salespersons to make and sell call
center solutions from their laptops in just a few hours or minutes.
....they wanted an outbound verson but I was able to squash that idea
by changing the "Answer" portion of the product name to "Bother".
Sorry to be so long winded. Yes, binary objects can easily be
defined and used. They are often very useful and reusable.
Proper separation of your layers (e.g. data and UI) can also
be very useful.
David
