[Fribidi-discuss] How much to hide the internal structure of FriBidiEnv?

Behdad Esfahbod behdad at bamdad.org
Sun Feb 24 06:28:08 EST 2002


Hi,

I think that the first one is fine, but we can have a void *, and 
two ints reserved, for future use without breaking binary 
compatibility, the ints can be used for many future flags, or 
needed integer values, and the void* can be used to be replaced 
by a FriBidiEnvInternal*, which contains the extra needed vars, 
and in a major release, we will move FriBidiEnvInternal into the 
FriBidiEnv, and release the void*, this is the common method in 
KDE classes.

behdad

On Sun, 24 Feb 2002, Omer Zak wrote:

> I am now in midst of finalizing the FriBidiEnv patch, which adds an
> argument to all important FriBidi procedures.  The extra argument allows
> different processes and different modules of the same software package to
> run FriBidi with different environments (and achieve thread-safety,
> customized debug modes, etc.).
> 
> An issue was raised, over which I would like to know the opinions of the
> list subscribers.
> 
> There are two possible ways to declare FriBidiEnv:
> 
> 1. Expose the whole structure in fribidi_env.h - the client software may
>    allocate memory for FriBidiEnv in whatever way it wants - static, on
>    the stack, on the heap.  It is possible to avoid having to check for
>    memory allocation success.
> 
>    On the other hand, if the structure of FriBidiEnv changes, the client
>    software has to be recompiled.
> 
>    It is easy for an application to request the default FriBidiEnv
>    instance, by passing a NULL pointer to FriBidi procedures (in operating
>    systems, which support global static variables).
> 
> 2. Declare FriBidiEnv to be an opaque datatype, and treat it as an handle.
>    The length of FriBidiEnv will be the same as that of a void* pointer.
> 
>    The contents of the data structure will be hidden from the client
>    application.
> 
>    An application has to explicitly allocate ("open") and deallocate
>    ("close") memory to be referenced by a FriBidiEnv handle.
> 
>    It is more difficult for an application to use NULL as the value of
>    FriBidiEnv, because it may also be the result of memory allocation
>    failure.  Furthermore, it is necessary for a robust application to
>    check that FriBidi successfully "opened" FriBidiEnv.
> 
> 
> Personally I prefer the simplicity of (1).  What do you think?
>                                              --- Omer
> WARNING TO SPAMMERS:  see at http://www.zak.co.il/spamwarning.html
> 
> 
> _______________________________________________
> Fribidi-discuss mailing list
> Fribidi-discuss at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/fribidi-discuss
> 

-- 
Behdad Esfahbod				5 Esfand 1380, 2002 Feb 24 
<behdad at bamdad dot org>		[Finger for Geek Code]

Today is a good day for information-gathering.
Read someone else's mail file.





More information about the FriBidi mailing list