new AnsiString question

[Zoran]

Malcome, can you give us an example LCL application which follows simple rules - all string variables are plain strings (except the parts of code which communicate with outside world) and the program does not work as expected?

If you don't have this example, why can't you just admit that everything in LCL actually work well?

[malcome]

Zoran, I don't want to do the same thing again and again.
Could you ask someone else?

[loopbreaker]

If you don't have this example, why can't you just admit that everything in LCL actually work well?

Zoran, there are no examples needed for this.
The string codepage needs to be fixed at compiletime,
anything else is amateurish, up to dangerous.
Old versions were safer, because the acp meaning was fixed to the system,
such that all code (can be even closed source) from different authors used the same codepage.
And the lack of expertise here will only hurt the reputation of Lazarus.

[Michl]

Lazarus follows FPC.

Old versions were safer

Why? There are AFAIK no open bug reports about FPC string magic.

such that all code ... used the same codepage.

Per default (in Lazarus), now a string is a UTF-8 encoded string, the same in older Lazarus.

[Bart]

This discussion is going nowhere.
Everybody repeats their arguments.
This is turning into a "bash the fpc/lazarus developers" thread.

From what I get from discussions with fpc devels, the cp-aware ansistrings are (meant to be) compatible with Delhi cp-aware ansistrings, including some (grant it) counter-intuitive behaviour.

You can insist on fighting the system and fighting the fpc devels if you want, but I don't think that is going to get us anywhere.
It distracts also from the fact we are in some kind of transition phase, moving to a solution where every string is fully unicode (and unambigous).

Personally I don't like the cp-aware string solution that Delphi invented at all.
It adds complexity, all for the sake of having a "1 byte = 1 char = all you ever need"?
The fact that string=unicodestring in Delphi now, only adds confusion to the discussion about strings in fpc/Lazarus here.

Fact is that even complex software (like Lazarus IDE) runs very well with the new cp-aware strings.
Yes, there were adjustments needed, but not as many as I feared.
And yes, adjustments in you code may be needed as well.
Such as not using the UTF8String type (which was discouraged even in the pre cp-string era), and adding explicit codepage identifiers to sourcecode that has string constants with characters that er not ASCII (or ad -FcUTF8 to your default compiler options to achieve the same).

It is an illusion that the evolution of the compiler/RTL/Lazarus is not at some point forcing you to adjust your code.
We'll try to be as minimal invasive as possible.

So, please either keep away from fpc 3.0 and later or at least try to implement the suggestions we give you to solve your problem.
And yes, please report back if our suggestions fail (and give sample code so we can test it).


Please stop just bickering.

Bart

[malcome]

Hi, Bart. Thank you always.

Probably I have same feeling with you.
I like C++, but Object Pascal gives me easy programing especially at string type.
So I usually use Lazarus.
Conversely, I do not like Visual Basic. Because there are many restrictions.

I have no opinion that Lazarus is going to. Just I want to report about new AnsiString.
So I don't intend bickering at all.
If Lazarus is going bad, I report "What the xxxx!" and just I stop using it.

But I expect to you guys.
Thank you!