[fpc-devel] bug report 20473: Please add a directive to define string=utf8string

[michael.vancanneyt at wisa.be]

On Thu, 13 Oct 2011, Alex Shishkin wrote:

> 13.10.2011 13:34, michael.vancanneyt at wisa.be пишет:
>> 
>> 
>> On Thu, 13 Oct 2011, Felipe Monteiro de Carvalho wrote:
>> 
>>> On Thu, Oct 13, 2011 at 11:24 AM, Sven Barth
>>> <pascaldragon at googlemail.com> wrote:
>>>> I think he ment that if such a feature is introduced it would be a
>>>> natural
>>>> conclusion to define "string = unicodestring" on Windows and "string =
>>>> utf8string" for Unix in the RTL and the FCL
>>> 
>>> ? I am totally lost as to what this has to do with my proposal. My
>>> proposal is to add a minimum facility to port UTF-8 based code which
>>> makes heavy use of the "string" keyword. It says nothing about which
>>> string the RTL should use.
>> 
>> In short, you want a directive to say
>> 
>> "In this unit, 'string' means MyNiceStringType"
>> 
>> Which is in fact an extension of the current {$H} to a more general case ?
>> 
>> Michael.
>> _______________________________________________
>> fpc-devel maillist - fpc-devel at lists.freepascal.org
>> http://lists.freepascal.org/mailman/listinfo/fpc-devel
>> 
>> 
>
> another alternative. in {$H-} no changes string=shortstring, in {$h+} string 
> = ansistring  or unocodestring in delphiunicode mode) by default but can be 
> redefined directly in code (or this definition is set in ObjPas unit) "type 
> string = MyNiceStringType". and this redefinition is inherited from used unit 
> if all of them compiled in {$h+} mode. In other words if unit has directive 
> {$h-} string=shortstring in any case, but if unit has {$h+} it use "string" 
> type from used unit as it is regular type.

I think from an implementation point of view, the directive approach is
easier.

>From discussions on the core mailing list, I understood that the
implementation is rather hairy.

In each case, this feature is not there yet, and there is also no guarantee that
it will be there. I assume that Paul Ishenin can shed more light on the
feasibility of this feature.

Michael.