[lazarus] Two FPC questions

[Michal Bukovjan]

Michael Van Canneyt wrote:

>On Wed, 11 Sep 2002, Michal Bukovjan wrote:
>
>  
>
>>Michael.VanCanneyt at Wisa.be wrote:
>>
>>    
>>
>>>On Tue, 10 Sep 2002, [ISO-8859-1] Sebastian G?nther wrote:
>>>
>>>
>>>
>>>      
>>>
>>>>>Michael.VanCanneyt at wisa.be schrieb:
>>>>>          
>>>>>
>>>>        
>>>>
>>>>>>>FormatC can easily be implemented and added to SysUtils. If you implement
>>>>>>>it, I can add it.
>>>>>>>              
>>>>>>>
>>>>>
>>>>>ehm... but in C, things like \t are just converted to their ASCII
>>>>>representation by the compiler and get stored as such in the binary. I
>>>>>would suggest to just add a helper function which converts strings with
>>>>>C-like escaped characters to a normal string, instead of writing
>>>>>high-level functions such as FormatC. (something like EscapeC/UnescapeC;
>>>>>the same could be done for other escaping schemes as well)
>>>>>          
>>>>>
>>>>        
>>>>
>>>I don't think this is a compiler matter, but a preprocessor matter.
>>>In such case it would be better to add general preprocessor support
>>>to lazarus or the compiler, and write some standard m4 preprocessing
>>>statements for this job.
>>>
>>>If we honor requests like this, the sky is the limit and finally code
>>>becomes totally unreadable as it is in C. Macroitis is a C disease,
>>>and should remain a C disease. So, I don't think this is a good idea.
>>>
>>>Michael.
>>>
>>>
>>>
>>>
>>>      
>>>
>>To have a platform and language independent tab, newline etc,
>>representation is in fact a very good idea.
>>It is supported by other languagea as well, like Python or Perl - only
>>Pascal stands out.
>>Without it (or something similar), it will be virtually impossible to
>>maintain mutliline translations via standard gettext tools.
>>    
>>
>
>Nothing a run-time function cannot solve, I would think ?
>I just don't think that it should be a _language_ feature.
>
>Michael.
>
>  
>
Runtime function would be quite slow, I can imagine. But a different 
idea came to my mind: How about implementing it just for resourcestrings?

- these are constants, so should not be hard to implement (just few 
regexps, I think)
- this would not break existing string/shortstring/ansistring semantics
- it would enable sane translations
- it could drive users to use resourcestrings when possible, possibly 
cleaning up code
- at runtime, already translated strings would be present in memory, so 
no speed penalty.

What do you think?

Michal