Why use libs11n?Almost every application needs some way to read data, and most also need a way to write data. For many applications, the only reading of data they need to be able to do is the simple parsing of a typical configuration file of key/value pairs. For example:
# configuration file for MyApplication setting_1 = 45 plugins_path = /home/me/lib/MyApplication:/usr/local/lib/MyApplication ...Most programmers have written code to read in such a file. If indeed that is all the support you need, then libs11n is overkill for your purposes and you are probably better off using your own ConfigFile class. If, however, you want to load and save more complex data, such as multiple instances of a particular class, then libs11n is probably a good choice. Let's take a brief look at why...
First off, implementing i/o support is not trivial. Even the ConfigFile example can take an hour or two of work to get right when one considers problems like handling of multi-line values. And such a ConfigFile handles only basic data with no hierarchical structure. It does not scale well to handle hierarchical data without a lot more work (even then, there are limits, and it does not scale well to support multiple instances of any given object). As soon as we want to save, e.g., a std::vector or std::map, we have to write completely new code to handle them. Since std::map<int,string> and std::map<string,int> are different types, we also have to handle those different cases unless we want to lock ourselves in to a very limited set of map types. And what about std::map<int,vector<string>>? libs11n handles all supported types to arbitrarily deep nesting levels, so as our data complexity grows libs11n is still suitable, whereas our ConfigFile type has long since been obsoleted by new data requirements.
Many programmers will of course say, "we can use XML." That's all fine and good - XML is a wonderful technology. My first argument against that would then be, "then you have to embed XML support into your application." My second argument would be, "and you still need to design an i/o interface suitable for XML." That is, your objects have to know that they are working with XML. That requires, amongst other things, adding a dependency to a particular XML implementation. Even if you have a generic, factory-based XML interface with hot-swappable implementations behind it, you're still limited to using XML. In my opinion, application objects should not know what data store they are using (except, of course, in the case of the objects which do the data marshaling). libs11n is, AFAIK, the only C++ serialization library which hides the detail of format from clients. Even in C# clients must specify whether they want to use XML or Binary serialization and they are then stuck with that format - they cannot change it without changing their objects' code. This is not the case in s11n - the format can be changed independently of the de/serialized objects.
While there are many examples of use cases for which libs11n is not suitable, there are many, many more for which libs11n is an ideal solution. Not only is it ideal for many problems, but it has the following additional properties:
|[home]||This site is developed in conjunction with: toc, SpiderApe, & wanderinghorse.net.||[top]|