pdf-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [pdf-devel] Memory management for hashes


From: gerel
Subject: Re: [pdf-devel] Memory management for hashes
Date: Sun, 20 Jul 2008 12:48:36 -0700 (PDT)

  
  The problem with this schema is that the values stored in a hash
  usually are heterogeneous. That is the case, for example, of the
  filter parameters or file properties. The actual API is not
  appropriate.

I totally agree.


  As I see it there are three alternatives:
  
  1) To let the management of the memory of the values to the entity
     using the module. This sound really bad for me, since the client
     would need to dispose all the values contained in the hash before
     to destroy it. It is error prone.

I don't like this one :-/
  
  2) To specify the element memory disposal function at element
     insertion time, like:
   
      pdf_hash_add (myhash, 
                    "key",
                    a_text_variable,
                    memory_disposal_function_for_text_variables);
  
     In this case would be quite useful to have some element disposal
     functions written for the several pdf_*_t types, including the
     pdf_hash_t one.
  

This is the cheapest solution I guess.

  3) To change the way the hash module works by introducing
     typed-values. That is, to restrict the contents of a hash entry to
     a predefined set of types, like:
  
       pdf_hash_add_text (myhash, 
                          "key",
                          a_text_variable);
  
       pdf_hash_add_u32 (myhash,
                         "FileSize",
                         pdf_u32_value);
  
     In this case we will need to expand the pdf-hash API to be able to
     ask the type of a given entry:
  
       pdf_hash_entry_type_t pdf_hash_entry_type (myhash, "key");
                      

This one is nice too, but will take some time to implement comparing to 2) and
we need to modify the API each time a new type is needed.

I have no problem to implement either one though. So i prefer 2.

cheers
-gerel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]