[Shapelib] Re: shapelib improvements

[Tom Kazimiers]

Mateusz Loskot schrieb:
> Bram de Greve wrote:
>   
>> Tom Kazimiers wrote:
>>     
>>> Mateusz Loskot schrieb:  
>>>   
>>>       
>>>> Tom,
>>>>
>>>> Perhaps we could make a unicode branch of Shapelib.
>>>> Frank's opinion is most important here, not mine
>>>>   
>>>>     
>>>>         
>>> This would be a good thing
>>>   
>>>       
>>>>> But if you use shapelib as a dll from another program, esp. a managed
>>>>> code one (I use C#) - on windows CE you have the only option to call
>>>>> with unicode parameters. This means you have to write wrappers which
>>>>> to the transformation or one makes the dll unicode aware (this is
>>>>> what I did). Are there any ways to get a managed to unmanaged call on
>>>>> Win CE working with char?
>>>>>     
>>>>>       
>>>>>           
>>>> Doesn't marchaling to UnmanagedType.LPStr work?
>>>> Also, CharSet attribute of DLLImport to control how encoding information
>>>> is marshalled. CharSet.Ansi is default for C++, so Unicode->ANSI is
>>>> translated automatically.
>>>>         
>>> Sure it is on a "normal" desktop computer - but in Win CE environment
>>> one can only choose CharSet.Unicode as the whole OS works only with unicode.
>>> The UnmanagedType.LPStr I did not try out - I will test it. But since I
>>> have read that Win CE can only handle unicode I doupt it  would work.
>>>       
>> It might solve your problems with unicode filenames, but how will you
>> cope with textual content
>>     
>
> Bram,
>
> We are discussing solution for encodings of file paths only.
> Certainly, it wouldn't solve problems with handling localized content
> (strings) but this is another subject.
>
>   
>> You will need to build in all your encodings
>> as internally all textural content is char* exclusively (with various
>> encodings).  That can be done?
>>     
>
> Yes, it can.
> However, it is complex task and would require use of char codes
> encoders/decoders like iconv.
>
> This subject will probably be covered along with implementation of
> GDAL/OGR RFC 5 (http://trac.osgeo.org/gdal/wiki/rfc5_unicode).
>
>   
>> Also, I suggest to first consider if you can't solve your problems with
>> wrapper code.  Not wrapper code around the DLL, but building a unicode
>> DLL with wrapper code around the original.  That way, you don't have to
>> branch (or to fork), which might be beneficial to both ...
>>     
>
> This won't solve all possible problems with internationalized paths.
> IMHO, simpler and cleaner solution is to replace current I/O calls with
> Unicode-aware calls from C/C++ libraries. The main disadvantage is that
> it will introduce new fork. However, Shapelib is not a big library, it's
> just 3 files of code, so forking does not sound as a problem for
> possible merge in future.
>
> Cheers
>   
And since shapelib seems to be really mature and stable there are not
that frequent updates. I won't think that the additional fork will be a
problem.

What are the advantages of non-unicode-code (as many libraries are
written this way)?

bye