How to serialize MFC collections using boost - boost

I'm trying to use Boost serialization in my MFC based project so far I had no luck whatsoever but getting error likes that serialize is not a member of CArray or serialize is not a member of CMap .
I cannot figure out how to serialize MFC collection .
Can any one come with a code that successfully serialize and deserialize MFC collection(CString ,CMap) using Boost API .
Thanks in advance

Since you don't have control over the CArray and CMap classes/templates, You will want to work from the non-intrusive instructions. In short, overload a serialize() free function that takes your class and stores the inner elements within it. Depending on the contents of the array or map, you may need to write a further serialize<>() function for them.

Related

Find out specific element with unique id from json array

I have json array & want to group weeks according to person id's as mentioned in below example. I tried code but unable to get it because i am new to free-marker code. The JSON Array as follows:-
[{"Hours":"5.500","Status":"Draft","Week":"17","person_name":"Raj","person_id":"1414"},
{"Hours":"0.500","Status":"Draft","Week":"17","person_name":"Raj","person_id":"1414"},
{"Hours":"24.500","Status":"Draft","Week":"14","person_name":"Mukesh","person_id":"1046"},
{"Hours":"7.500","Status":"Draft","Week":"15","person_name":"Mukesh","person_id":"1046"},
{"Hours":"3.000","Status":"Draft","Week":"16","person_name":"Mukesh","person_id":"1046"}]
Could please help me. The output in below foramt
for id {1046:[14,15,16], 1414:[17,17]}
Such kind of restructuring is not something that should be done inside a template. While FTL can add together map-like values and also list-like values, it would be very inefficient to hack this together with that (it's only for very simple tasks). The entries should be already grouped before passing the data to the template.
If you must initiate this from the template, then you will need a utility Java object that has a method that does this grouping, or a TemplateMethodModelEx implementation that does it. Then you call that utility object from the template (like utils.groupByPersonId(foo) or groupByPersonId(foo)). Such utility objects can be exposed to the template on various ways: as part of the data-model, globally as "shared variable" through the freemarker.tempalte.Configuration object, or by ensuring that the utility TemplateMethodModelEx (or any other TemplateModel) class is visible for Java and then do something like <#assign groupByPersonId = 'com.example.GroupByPersonIdMethod'?new()> in the template.

Dynamic dispatch implementation- virtual function table offset

I'm currently in the code generation phase of building a compiler for a Java-like language. I'm trying to understand how to implement dynamic dispatch for virtual methods.
I get how to build a virtual function table for every class and store a pointer to it in every object. What I don't get is- when generating code for a function call, how do you know what the offset is for that function in the table?
Thanks.
How do you know what anything is in your language? You write it down somewhere while parsing.
What I did in one of my toy languages was to keep a "vtable size" for each class, and when you add a new method to a class, you write down the vtable size as the offset of the method somewhere (i.e. you create a lookup table that maps method name to info about it, like its parameter types and its offset in the vtable), then add to the size to account for the newly-added method.
Of course, this assumes your language actually uses a vtable, like for example C++. If you use messaging in the style of Smalltalk or Objective-C, this table that you build actually gets saved to your compiled product and just used directly. Now a table look-up is slower than just accessing an offset directly, but also has the advantage that a caller does not need to know the type of an object to call a method on it, and you can easily add methods to objects without having to recompile the entire program.

Save IEnumerable in Isolated Storage

I used the isolated storage before to save text files, xml files and images. However, is it possible to save variables of type IEnumerable using IsolatedStorage or any other resource in windows phone 7??
Thanks,
You are misunderstanding core concepts.. There is no such thing as "saving variables", you save objects. Your variable points to an object, and that objects implements IEnumerable. Is On WP7, it is the object's actual class that determines whether that object can be serialized and stored on the ISO directly. If that actual collection class does not support serialization, you will have to re-wrap all its current elements into a List/Array/Dictionary/Stack/Queue - literally whatever what supports being serialized - and store that instead of.
Once you have an serializable collection, then your code for saving gets reduced to something as trivial as:
IsolatedStorageSettings.ApplicationSettings["blah"] = your_serializable_collection;
IsolatedStorageSettings.ApplicationSettings.Save();
and in general, that's it. Retrieving is similar:
var items = (SomeCollection)IsolatedStorageSettings.ApplicationSettings["blah"];
where SomeCollection may be an IEnumerable, a List/Array/Dictionary/Stack/Queue - whatever you had put there and whatever is implemented by the actual collection class.
If you want, you may use IsolatedStorageFile and write files directly, but unless you have a good reason to - there's no point in it, as using the common dictionary is far simplier.
In my other post you'll find some links:
How to do isolated storage in Wp7?
Use for saving/loading of data List which are serializable out of the box. Last time i tried deserialize an IEnumerable I got errors...

Scalar type in Managed Object only works for IPhone 5

Property 'Latitude' is a scalar type on class 'LatitudeLongitude'. Cannot generate a setter method for it.
When I generated codes for my managed object, I got a message whether I want scalar properties for primitive data type. should I use it? I want to make this application compatible with iPhone 3 - 5
is there any issues with this problem?
When you use scalar properties you have to provide implementations of getters and setters for those properties by yourself, as described in documentation:
"You can declare properties as scalar values, but for scalar values Core Data cannot dynamically generate accessor methods—you must provide your own implementations (see “Managed Object Accessor Methods”). Core Data automatically synthesizes the primitive accessor methods (primitiveLength and setPrimitiveLength:), but you need to declare them to suppress compiler warnings."
Documentation
At this place I would recommend you to check this post core-data-scalars.
I hope I have helped.
This is not true, scalars have been supported in Core Data out of the box for a long time. You do not have to implement custom accessors as many blog posts out there indicate.

NSCoder vs NSDictionary, when do you use what?

I'm trying to figure out how to decide when to use NSDictionary or NSCoder/NSCoding?
It seems that for general property lists and such that NSDictionary is the easy way to go that generates XML files that are easily editable outside of the application.
When dealing with custom classes that holds data or possibly other custom classes nested inside, it seems like NSCoder/NSCoding would be the better route since it will step through all the contained object classes and encode them as well when an archive command is used.
NSDictionary seems like it would take more work to get all the properties or data characteristics to a single level to be able to save it, where as NSCoder/NSCoding would automatically encode nested custom classes that implement the NSCoding interface.
Outside of it being binary data and not editable outside of your application is there a real reason to use one over the other? And along those lines is there an indicator of which way you should lean between the two? Am I missing something obvious?
Apple's documentation on object graphs has this to say:
Mac OS X serializations store a simple hierarchy of value objects, such as dictionaries, arrays, strings, and binary data. The serialization only preserves the values of the objects and their position in the hierarchy. Multiple references to the same value object might result in multiple objects when deserialized. The mutability of the objects is not maintained.
…
Mac OS X archives store an arbitrarily complex object graph. The archive preserves the identity of every object in the graph and all the relationships it has with all the other objects in the graph. When unarchived, the rebuilt object graph should, with few exceptions, be an exact copy of the original object graph.
The way I interpret this is that, if you want to store simple values, serialization (using an NSDictionary, for example) is a fine way to go. If you want to store an object graph of arbitrary types, with uniqueness and mutability preserved, using archives (with NSCoder, for example) is your best bet.
You may also want to read Apple's Archives and Serializations Programming Guide for Cocoa, of which the aforelinked page on object graphs is a part, as it covers this topic well.
I am NOT a big fan of using NSCoding/NSCoder/NSArchiver (we need to pick a name!) to serialise an object graph to a file.
Archives created in this way are incredibly fragile. If you save an object of class Foo then by golly you need to make sure when you load the data back in you have a class Foo in your application.
This makes NSCoder based serialisation difficult from the perspective of sharing files with other applications or even forwards compatibility with your future application.
I forgot to list what I would recommend.
NSCoding can be ok in certain situations: if you're just doing something quick and simple (although you do have to write a lot of code - two methods per class to be serialised). It can also be ok if you're not worried about compatibility with other applications.
Export/import via property lists (perhaps using the NSPropertyListSerializaion class) is a fine solution. XML based plists are easy to create and edit. Main advantage to plists is that you're not tying the file format to just your application.
You can also create your own XML based file format and read/write to it using NSXMLDocument API and friends. This really isn't much more work than using property lists.
I think you're a bit confused, NSDictionary is a data structure, it also happens to implement the NSCoding protocol. So in essence, you could either put all your data into a NSDictionary and have that encode itself later on, or you can implement the NSCoding protocol and encode your object tree using the NSCoder API. Based on the type of NSCoder object passed in to the encodeWithCoder: method, is the output of your encoding.

Resources