1

Topic: Handling of standard containers - a question on designing

There was recently before me such question:

There is card CAtlMap and array CAtlArray. It is necessary to pack/unpack their contents for storage/transfer on a network.

Package is understood as record of the contained container in storage. Unpacking is a creation of the container from storage.

I will not go into detail of implementation of package/unpacking of the data, for this point in question it is unimportant. Instead of serialization there can be for example, an export/import of the data.

It would would be desirable write one  which could to process different types  (a card, an array, probably list).

Here a prototype:



template <class A C> 
class CSerializer 
{ 
    & m_rc;//the container (a card or an array) 
public: 
    CSerializer (& rc): m_rc (rc) {}; 
    DWORD GetSerializedSize () const; 

    HRESULT Serialize (PBYTE pbData, PDWORD pcbProcessed) const; 
    HRESULT Deserialize (const PBYTE pbData, PDWORD pcbProcessed); 
};


It is supposed that each element of the container also will have methods Serialize and Deserialize and CSerializer it will be simple to use them  all elements of the container. However a problem that operations with containers differs. For example  cards - two components a key and value, and at an array one (the index is not considered).

Here and a question, as though  operation with these collections of the data?




28.02.13 20:57: It is transferred by the moderator from ' a C/C ++ ' - Kodt

2

Re: Handling of standard containers - a question on designing

Hello, Electrode, you wrote:

E> There was recently before me such question:
E> There is card CAtlMap and array CAtlArray. It is necessary to pack/unpack their contents for storage/transfer on a network.
E> package is understood as record of the contained container in storage. Unpacking is a creation of the container from storage.
E> I will not go into detail of implementation of package/unpacking of the data, for this point in question it is unimportant. Instead of serialization there can be for example, an export/import of the data.
E> it would Would be desirable write one  which could to process different types  (a card, an array, probably list).
E> Here a prototype:
E>

E> template <class A C> 
E> class CSerializer 
E> { 
E> & m_rc;//the container (a card or an array) 
E> public: 
E> CSerializer (& rc): m_rc (rc) {}; 
E> DWORD GetSerializedSize () const; 

E> HRESULT Serialize (PBYTE pbData, PDWORD pcbProcessed) const; 
E> HRESULT Deserialize (const PBYTE pbData, PDWORD pcbProcessed); 
E>}; 
E> 


E> It is supposed that each element of the container also will have methods Serialize and Deserialize and CSerializer it will be simple to use them  all elements of the container. However a problem that operations with containers differs. For example  cards  two components a key and value, and at an array one (the index is not considered).
E> Here and a question, as though  operation with these collections of the data?


template class for CAtlMap CAtlArray, the general code to pull out in the general base class?





template <class A C> class CSerializer; 

template <> 
class CSerializer <CAtlMap>: public CSerializerBase {....}; 

template <> 
class CSerializer <CAtlArray>: public CSerializerBase {....}; 

3

Re: Handling of standard containers - a question on designing

Hello, andyp, you wrote:

A> Spetsializirovat template class for CAtlMap CAtlArray, the general code to pull out in the general base class?

A>

A> template <class A C> class CSerializer; 

A> template <> 
A> class CSerializer <CAtlMap>: public CSerializerBase {....}; 

A> template <> 
A> class CSerializer <CAtlArray>: public CSerializerBase {....}; 
A> 



The problem in that when there as that also is not present the general, . then sense is lost in generalized .

For example, method Serialize could be implemented so:




template <class A C> 
HRESULT CSerializer <C>:: Serialize ( 
    PBYTE pbData, 
    PDWORD pcbProcessed 
) const 
{ 
    DWORD cbElement; 
    CElement* pNode; 

    HRESULT hr = S_OK; 
    ...
    cbData = 0; 
    POSITION pos = m_rc. GetStartPosition (); 
    while (pos) 
    { 
        m_rc. GetAt (pos, &pNode); 

        hr = cbSize + = pNode-> Serialize (pbData, &cbElement); 
        cbData + = cbElement; 
        if (FAILED (hr)) 
            break; 
        pbData + = cbElement; 
        m_rc. GetNext (pos); 
    }
    if (pcbProcessed) 
        *pcbProcessed = cbData; 
    return hr; 
}



But at CAtlArray there are no methods GetStartPosition (), GetNext (), and the main problem that at elements of a card two components - a key and value.

4

Re: Handling of standard containers - a question on designing

Hello, Electrode, you wrote:

E> But at CAtlArray there are no methods GetStartPosition (), GetNext (), and the main problem that at elements of a card two components  a key and value.


Perhaps, to throw in a template a class, able to be iterated on the given type of the container? Such "iterator-HELPER" which if needed can incur passing business functions (for example,  elements-duplicates or to resolve conflicts)

5

Re: Handling of standard containers - a question on designing

Hello, Electrode, you wrote:

E> Hello, andyp, you wrote:

A>> Spetsializirovat template class for CAtlMap CAtlArray, the general code to pull out in the general base class?

A>>

A>> template <class A C> class CSerializer; 

A>> template <> 
A>> class CSerializer <CAtlMap>: public CSerializerBase {....}; 

A>> template <> 
A>> class CSerializer <CAtlArray>: public CSerializerBase {....}; 
A>> 


E> the Problem that when there as that also is not present the general, . then the sense is lost in generalized .
E> For example, method Serialize could be implemented so:

E>


E> template <class A C> 
E> HRESULT CSerializer <A C>:: Serialize ( 
E> PBYTE pbData, 
E> PDWORD pcbProcessed 
E>) const 
E> { 
E> DWORD cbElement; 
E> CElement* pNode; 

E> HRESULT hr = S_OK; 
E>... 
E> cbData = 0; 
E> POSITION pos = m_rc. GetStartPosition (); 
E> while (pos) 
E> { 
E> m_rc. GetAt (pos, &pNode); 

E> hr = cbSize + = pNode-> Serialize (pbData, &cbElement); 
E> cbData + = cbElement; 
E> if (FAILED (hr)) 
E> break; 
E> pbData + = cbElement; 
E> m_rc. GetNext (pos); 
E>} 
E> if (pcbProcessed) 
E> *pcbProcessed = cbData; 
E> return hr; 
E>} 
E> 


E> But at CAtlArray there are no methods GetStartPosition (), GetNext (), and the main problem that at elements of a card two components  a key and value.


Looked for a moment - the general basis can be useful only as the general virtual interface to separate  (if in it purely virtual functions to define) - well i.e. all remaining code can use pointers-references on the general basis. In remaining it is similar you are right also the general pieces in implementation will not be.

6

Re: Handling of standard containers - a question on designing

Hello, Mr. Delphist, you wrote:

MD> Hello, Electrode, you wrote:

E>> But at CAtlArray there are no methods GetStartPosition (), GetNext (), and the main problem that at elements of a card two components  a key and value.

MD> Perhaps, to throw in a template a class, able to be iterated on the given type of the container? Such "iterator-HELPER" which if needed can incur passing business functions (for example,  elements-duplicates or to resolve conflicts)


+1. It is possible the analogs getNext () GetStartPosition () for an array to add. In the general base class to make actually serialization in these terms.

7

Re: Handling of standard containers - a question on designing

Hello, andyp, you wrote:

A> Hello, Mr. Delphist, you wrote:

MD>> Hello, Electrode, you wrote:

E>>> But at CAtlArray there are no methods GetStartPosition (), GetNext (), and the main problem that at elements of a card two components  a key and value.

MD>> Perhaps, to throw in a template a class, able to be iterated on the given type of the container? Such "iterator-HELPER" which if needed can incur passing business functions (for example,  elements-duplicates or to resolve conflicts)

A> +1. It is possible the analogs getNext () GetStartPosition () for an array to add. In the general base class to make actually serialization in these terms.


It is necessary to think over it. It is possible to make also  classes class CSerializableAtlArray: public CAtlArray and class CSerializableAtlMap: public CAtlMap and to add  methods. Then the array can be "adjusted" to the general interface, but here a question how to make something of type such for a card not bad:




    CPair* pNode; 
    GetAt (pos, &pNode); 
    hr = pNode-> Serialize (pbData, &cbElement); 



Initially after all in CPair there is no such method as Serialize...

8

Re: Handling of standard containers - a question on designing

Hello, Electrode, you wrote:

E> it is primary after all in CPair there is no such method as Serialize...


, it is not so successful idea to interpose serialization in  and containers. It generally not their duty, and infrastructures.

9

Re: Handling of standard containers - a question on designing

Hello, AndrewJD, you wrote:

AJD> Hello, Electrode, you wrote:

E>> it is primary after all in CPair there is no such method as Serialize...

AJD> , it is not so successful idea to interpose serialization in  and containers. It generally not their duty, and infrastructures.


I too  separately did. And that then is all to MegaBrightlySparklingSerializableSuperArray comes
smile

10

Re: Handling of standard containers - a question on designing

Hello, andyp, you wrote:

A> Hello, AndrewJD, you wrote:

AJD>> Hello, Electrode, you wrote:

E>>> it is primary after all in CPair there is no such method as Serialize...

AJD>> , it is not so successful idea to interpose serialization in  and containers. It generally not their duty, and infrastructures.

A> I too  separately did. And that then is all to MegaBrightlySparklingSerializableSuperArray comes
smile


It agree, it is necessary to separate flies from cutlets, and the in itself array should not be able something , but its elements should be able . Otherwise in any way. After all elements in itself can be difficult data structures.

As well with a card. If card Serializable, somewhere there should be a method of serialization of a node of a card, which inside causes methods K:: Serialize () and V:: Serialize () where K - a key, V - value. A question in that as this idea to embody on a C ++...