Watch, Follow, &
Connect with Us

For forums, blogs and more please visit our
Developer Tools Community.


Welcome, Guest
Guest Settings
Help

Thread: Product Roadmap August 2016



Permlink Replies: 726 - Last Post: Nov 18, 2016 2:07 PM Last Post By: Markus Humm Threads: [ Previous | Next ]
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 4, 2016 2:11 PM
A new roadmap has been released:

http://community.embarcadero.com/article/news/16418-product-roadmap-august-2016

--
Remy Lebeau (Indy Team)

Alexandre Machado

Posts: 1,754
Registered: 8/10/13
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 4, 2016 8:21 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
A new roadmap has been released:

http://community.embarcadero.com/article/news/16418-product-roadmap-august-2016

I really would like to know whether Linux memory management will be ARC-based or not... although I'm afraid I already know the answer...
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 5, 2016 12:40 PM   in response to: Alexandre Machado in response to: Alexandre Machado
Alexandre wrote:

I really would like to know whether Linux memory management will be
ARC-based or not... although I'm afraid I already know the answer...

They already announced earlier that it will be using ARC.

--
Remy Lebeau (TeamB)
Alexandre Machado

Posts: 1,754
Registered: 8/10/13
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 5, 2016 4:57 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
Alexandre wrote:

I really would like to know whether Linux memory management will be
ARC-based or not... although I'm afraid I already know the answer...

They already announced earlier that it will be using ARC.

--
Remy Lebeau (TeamB)

Hum... I missed that. Thanks for the information.
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 5, 2016 5:57 PM   in response to: Alexandre Machado in response to: Alexandre Machado
Alexandre wrote:

Hum... I missed that.

http://community.embarcadero.com/article/news/16211-embarcadero-rad-studio-2016-product-approach-and-roadmap-2

- Linux compilers will be for Intel 64-bit server, LLVM-based and ARC-enabled

--
Remy Lebeau (TeamB)
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 13, 2016 4:24 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
ARC-enabled

it's a pity :( build server software (linux is mostly for server
software) with ARC who will destroy the multithreading :( i can't
believe it ! i start to think that it's student who work in the emb team :(
Ralf Stocker

Posts: 121
Registered: 12/24/04
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 13, 2016 7:15 AM   in response to: loki loki in response to: loki loki
They offer ARC, because the LLVM Linux compiler has ARC. If the LLVM compiler would have no ARC, they would offer a none ARC compiler.

BTW. Emba has no compiler engineer at the moment. The Delphi dev is floating through the universe...


loki loki wrote:
ARC-enabled

it's a pity :( build server software (linux is mostly for server
software) with ARC who will destroy the multithreading :( i can't
believe it ! i start to think that it's student who work in the emb team :(
Ralf Stocker

Posts: 121
Registered: 12/24/04
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 13, 2016 7:16 AM   in response to: Ralf Stocker in response to: Ralf Stocker
They offer ARC, because the LLVM Linux compiler has ARC. If the LLVM compiler would have no ARC, they would offer a none ARC compiler.

BTW. Emba has no compiler engineer at the moment. The Delphi dev department is floating through the universe...


loki loki wrote:
ARC-enabled

it's a pity :( build server software (linux is mostly for server
software) with ARC who will destroy the multithreading :( i can't
believe it ! i start to think that it's student who work in the emb team :(

Edited by: Ralf Stocker on Aug 13, 2016 4:16 PM
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 13, 2016 7:37 AM   in response to: Ralf Stocker in response to: Ralf Stocker
They offer ARC, because the LLVM Linux compiler has ARC. If the LLVM compiler would have no ARC, they would offer a none ARC compiler.

and who did this LLVM linux compiler ? :)

BTW. Emba has no compiler engineer at the moment. The Delphi dev department is floating through the universe...

this is scaring :(
Lajos Juhasz

Posts: 801
Registered: 3/14/14
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 13, 2016 8:42 AM   in response to: Ralf Stocker in response to: Ralf Stocker
Ralf Stocker wrote:

They offer ARC, because the LLVM Linux compiler has ARC. If the LLVM
compiler would have no ARC, they would offer a none ARC compiler.
BTW. Emba has no compiler engineer at the moment. The Delphi dev
department is floating through the universe...


I doubt that that is the reason, that's not what Allen Bauer wrote. He
was all about to bring ARC and ZBS also to the desktop compiler of the
Delphi.

I wonder when will Apple stop with this silly ARC thing. I think that
was the strongest influence why the LLVM based Delphi compilers support
ARC.
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 13, 2016 11:07 AM   in response to: Lajos Juhasz in response to: Lajos Juhasz
Lajos Juhasz wrote:
Ralf Stocker wrote:

They offer ARC, because the LLVM Linux compiler has ARC. If the LLVM
compiler would have no ARC, they would offer a none ARC compiler.
BTW. Emba has no compiler engineer at the moment. The Delphi dev
department is floating through the universe...


I doubt that that is the reason, that's not what Allen Bauer wrote. He
was all about to bring ARC and ZBS also to the desktop compiler of the
Delphi.

I wonder when will Apple stop with this silly ARC thing. I think that
was the strongest influence why the LLVM based Delphi compilers support
ARC.

What does Apple has to do with anything? Delphi had ARC for interfaces
since Delphi 3.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 13, 2016 12:00 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar

What does Apple has to do with anything? Delphi had ARC for interfaces
since Delphi 3.

yes and that was perfect ! but putting ARC for all object it's simply a
non sense :(

1/ it's not help at all to reduce memory leaks (in the full opposite,
you never really know when you object will be destroyed or if your are
in a circular reference).

2/ it's not more faster, it's the full opposite also, it's even destroy
multithreading because global memory lock must be acquire when
increasing/decreasing the ref count

3/ it's fully useless! because as we need to stay compatible with
desktop, we still need to write our code with try .. finally .free end

4/ it's just badly designed, now with .free, .disposeOf and .release,
just very good to afraid new developer who want to try delphi

i suggest to update a little the ARC by removing .disposeOF, to make it
at least a little more "compatible" with non ARC code.

https://quality.embarcadero.com/browse/RSP-15401

please vote vote it !

Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 14, 2016 4:50 AM   in response to: loki loki in response to: loki loki
loki loki wrote:

What does Apple has to do with anything? Delphi had ARC for interfaces
since Delphi 3.

yes and that was perfect ! but putting ARC for all object it's simply a
non sense :(

But it made sense. Right now in Delphi desktop interfaces are tied to memory management.
You have mixed memory management that can be huge culprit at times. Yes, it also
enables you to do some cool things but most of the time it is not worth the trouble,

Pure ARC streamlines that side of development.

1/ it's not help at all to reduce memory leaks (in the full opposite,
you never really know when you object will be destroyed or if your are
in a circular reference).

You have to learn to code for ARC. Just like you had to learn to code for manual memory
management.

2/ it's not more faster, it's the full opposite also, it's even destroy
multithreading because global memory lock must be acquire when
increasing/decreasing the ref count

It is hard to tell how much slowdowns will ARC bring to multithreading.
Just like with some other things some coding patterns will have to be changed
to remove bottlenecks.

3/ it's fully useless! because as we need to stay compatible with
desktop, we still need to write our code with try .. finally .free end

That is why I hope we will have desktop ARC compiler sooner rather than later.

4/ it's just badly designed, now with .free, .disposeOf and .release,
just very good to afraid new developer who want to try delphi

i suggest to update a little the ARC by removing .disposeOF, to make it
at least a little more "compatible" with non ARC code.

https://quality.embarcadero.com/browse/RSP-15401


That request makes no sense at this point in time. That ship has sailed
long ago.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 14, 2016 6:59 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
yes and that was perfect ! but putting ARC for all object it's simply a
non sense :(

But it made sense. Right now in Delphi desktop interfaces are tied to memory management.
You have mixed memory management that can be huge culprit at times. Yes, it also
enables you to do some cool things but most of the time it is not worth the trouble,

yes, desktop interfaces are tied to memory management and that is very
good, it's like this we all learn how to code in delphi ! it's also like
that that we all code in serious software (in c/c++ for exemple)
and please don't gave me apple as an example !

why the hell want to change it, break the compatibility and start
everything (again) from zero ? stupid decision made by people not
looking more far away than their nose :(

it's non sense because what you will win from it ? absolutely nothing in
the opposite ! how many DELPHI developer say me that they will not
start their mobile application with Delphi :( don't say me the opposite,
it's a fact ! this quite very few serious mobile app made in delphi !
and it's stupid :(


1/ it's not help at all to reduce memory leaks (in the full opposite,
you never really know when you object will be destroyed or if your are
in a circular reference).

You have to learn to code for ARC. Just like you had to learn to code for manual memory
management.

i do delphi from 20 years, i don't want to learn again! if i need to
learn i will do on something else, this is what you don't understand :(

2/ it's not more faster, it's the full opposite also, it's even destroy
multithreading because global memory lock must be acquire when
increasing/decreasing the ref count

It is hard to tell how much slowdowns will ARC bring to multithreading.
Just like with some other things some coding patterns will have to be changed
to remove bottlenecks.

again i don't want to change my coding pattern for no gain (because
again we win nothing with ARC). after coding pattern or not you can not
avoid the threadlock when you will increase/decrease the refcount! that
a fact..

3/ it's fully useless! because as we need to stay compatible with
desktop, we still need to write our code with try .. finally .free end

That is why I hope we will have desktop ARC compiler sooner rather than later.

stupid :( after that you will be probably the last delphi developper :(
all the shared source will not work anymore like you source code too ...
of course if you just do hello world software maybe yes it's will be ok
for you


4/ it's just badly designed, now with .free, .disposeOf and .release,
just very good to afraid new developer who want to try delphi

i suggest to update a little the ARC by removing .disposeOF, to make it
at least a little more "compatible" with non ARC code.

https://quality.embarcadero.com/browse/RSP-15401


That request makes no sense at this point in time. That ship has sailed
long ago.

it's make sense because right now we can't remove ARC because some code
(and not much as you can see) for mobile have been already made for ARC,
so their is no way to remove ARC (except playing like the last monkey
emb chief scientist and destroy the compatibility *again*). so removing
the disposeOF if the first step to cancel the arc effect

Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 14, 2016 8:13 AM   in response to: loki loki in response to: loki loki
Am 14.08.2016 um 15:59 schrieb loki loki:
yes and that was perfect ! but putting ARC for all object it's simply a
non sense :(

But it made sense. Right now in Delphi desktop interfaces are tied to memory management.
You have mixed memory management that can be huge culprit at times. Yes, it also
enables you to do some cool things but most of the time it is not worth the trouble,

yes, desktop interfaces are tied to memory management and that is very
good, it's like this we all learn how to code in delphi ! it's also like
that that we all code in serious software (in c/c++ for exemple)
and please don't gave me apple as an example !

why the hell want to change it, break the compatibility and start
everything (again) from zero ? stupid decision made by people not
looking more far away than their nose :(

it's non sense because what you will win from it ? absolutely nothing in
the opposite ! how many DELPHI developer say me that they will not
start their mobile application with Delphi :( don't say me the opposite,
it's a fact ! this quite very few serious mobile app made in delphi !
and it's stupid :(

Yes it is: because if coding like for non ARC (means simply calling
free) you can maintain a high grade of compatibility to Win32. The only
place afaik where this doesn't properly work is when dealing with FMX
GUI objects and forms or when needing to prematurely freeing some object
because it would block some ressource or keep a lot of memory. But
that's no big problem either.

Greetings

Markus
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 2:30 AM   in response to: loki loki in response to: loki loki
loki loki wrote:

it's non sense because what you will win from it ? absolutely nothing in
the opposite ! how many DELPHI developer say me that they will not
start their mobile application with Delphi :( don't say me the opposite,
it's a fact ! this quite very few serious mobile app made in delphi !
and it's stupid :(

I am not using Delphi for mobile applications. But for different reasons.
Anyway, using other tools and technologies also takes time. You
don't like ARC in Delphi, but using native tools for iOS and OSX also
require learning ARC, Android requires knowledge of GC, where you can
also make nice memory leaks with cycles if you are not careful.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 2:41 AM   in response to: loki loki in response to: loki loki
loki loki wrote:
i suggest to update a little the ARC by removing .disposeOF, to make it
at least a little more "compatible" with non ARC code.

https://quality.embarcadero.com/browse/RSP-15401

That request makes no sense at this point in time. That ship has sailed
long ago.

it's make sense because right now we can't remove ARC because some code
(and not much as you can see) for mobile have been already made for ARC,
so their is no way to remove ARC (except playing like the last monkey
emb chief scientist and destroy the compatibility *again*). so removing
the disposeOF if the first step to cancel the arc effect


Removing DisposeOf now would be step in wrong direction. We have to move
forward not backward.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 3:02 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar

That is why I hope we will have desktop ARC compiler sooner rather than later.

It's terrible. We had many C++ objects. And we use abstract class with many virtual function to use the objects(c++) in DLL

With ARC. All the C++ object can not be used.

If ARC come in desktop. Then I can only completely abandon the delphi.
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 3:31 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

That is why I hope we will have desktop ARC compiler sooner rather than later.

It's terrible. We had mang C++ objects. And we use abstract class with many virtual function to use the objects(c++) in DLL

With ARC. All the C++ object can not be used.

You can use [unsafe] attribute to avoid ARC on specific object instances.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 4:19 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:
wenjie zhou wrote:

That is why I hope we will have desktop ARC compiler sooner rather than later.

It's terrible. We had mang C++ objects. And we use abstract class with many virtual function to use the objects(c++) in DLL

With ARC. All the C++ object can not be used.

You can use [unsafe] attribute to avoid ARC on specific object instances.

So, i would write [unsafe] everywhere. Pass the object to an inner function as a parameter. Use a local variable to store the object. I had write [unsafe] again.
I had to be very careful. Any local variable without [unsafe] will bring disaster .
No matter how difficult it is to intervene with other systems, Delphi to go its own way and live in it's own world .
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 5:11 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
You can use [unsafe] attribute to avoid ARC on specific object instances.

By the way.I don't understand why it is not unsafe but [unsafe].

An attribute affect compiler behavior. Why not a keyword?

An attribute affect compiler how to produce runtime code. It is strange.
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 3:22 PM   in response to: wenjie zhou in response to: wenjie zhou
wenjie wrote:

It's terrible. We had mang C++ objects. And we use abstract class
with many virtual function to use the objects(c++) in DLL

With ARC. All the C++ object can not be used.

Let's clarify something here. In this situation, ARC applies **only** to
classes that are derived from System::TObject, as these are the classes that
are cross-compatible with Delphi. You cannot safely pass these types of
classes over the DLL boundary to begin with, unless both DLL and calling
module are compiled with Runtime Packages enabled. Classes that are not
derived from TObject are not affected by ARC at all. This is clearly outlined
in Embarcadero's documentation:

http://docwiki.embarcadero.com/RADStudio/en/Automatic_Reference_Counting_in_C%2B%2B

So, using non-TObject abstract classes for cross-module interfaces still
works just fine.

--
Remy Lebeau (TeamB)
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 5:38 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
http://docwiki.embarcadero.com/RADStudio/en/Automatic_Reference_Counting_in_C%2B%2B

So, using non-TObject abstract classes for cross-module interfaces still
works just fine.

--

Where is the non-TObject in Delphi ( With ARC-Enabled)?

"C++ object in DLL" not refer to "C++ Builder". In fact, in the world of C++Builder, C++Builder has little influence.
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 5:55 PM   in response to: wenjie zhou in response to: wenjie zhou
wenjie wrote:

Where is the non-TObject in Delphi ( With ARC-Enabled)?

All classes in Delphi derive from TObject, so all class objects in Delphi
will use ARC on relevant platforms. But in C++, only classes that are implemented
in Delphi and accessed in C++ derive from TObject. Pure C++ classes do not,
and thus are not subject to ARC (unless you explicitly derive them from TObject
yourself, which you generally should not do when not interacting with Delphi).

The statement I made was in reference to ARC in C++.

If the DLL in question is written in Delphi and the EXE is written in C++
(any flavor), or vice versa, and the app and DLL are exchanging objects using
abstract classes on the C++ side, then you wouldn't use actual class types
on the Delphi side, you would use interfaces or even records (Delphi's equivilent
to C++ structs) instead.

--
Remy Lebeau (TeamB)
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 7:24 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
All classes in Delphi derive from TObject, so all class objects in Delphi
will use ARC on relevant platforms. But in C++, only classes that are implemented
in Delphi and accessed in C++ derive from TObject. Pure C++ classes do not,
and thus are not subject to ARC (unless you explicitly derive them from TObject
yourself, which you generally should not do when not interacting with Delphi).

The ARC you described is the big problem. Without ARC. There is no such problem. So ARC for TObject is a mistake.

If the DLL in question is written in Delphi and the EXE is written in C++
(any flavor), or vice versa, and the app and DLL are exchanging objects using
abstract classes on the C++ side, then you wouldn't use actual class types
on the Delphi side, you would use interfaces or even records (Delphi's equivilent
to C++ structs) instead.

DLL(Delphi) EXE(C++) : abstract classes can not achieve the problem. C++ can not increase or decrease the reference count. Can't work according to ARC mode

DLL(C++) EXE(Delphi) :
interfaces has 3 virtual functions. They cccupy the ahead space in VMT. Unless these 3 methods are added to the c++ object. Otherwise unable to use.
records do not have VMT. For c++ objects. It cannot use at all. That is why i suggest embarcadero to add VMT for record. I'm really disappointed with ARC in TObject
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 7:55 PM   in response to: wenjie zhou in response to: wenjie zhou
wenjie wrote:

DLL(Delphi) EXE(C++) : abstract classes can not achieve the
problem. C++ can not increase or decrease the reference count.

Can't work according to ARC mode

TObject is not safe to pass over the DLL boundary without runtime packages
in both DLL and EXE. Only C++Builder can interact with TObject anyway.
If the EXE were written in another C++ compiler, it couldn't interact with
TObject at all, so the DLL and EXE would have to agree to use a standardized
cross-compiler compatible interface, like IUnknown.

DLL(C++) EXE(Delphi) :

interfaces has 3 virtual functions.

As imposed by the standard IUnknown interface, yes.

They cccupy the ahead space in VMT. Unless these 3 methods are
added to the c++ object. Otherwise unable to use.

records do not have VMT.

No, but they can be used to access/simulate a VMT of a C++ object that crosses
the DLL boundary. This is how COM interfaces (which are generally based
on C++) are used in C, for instance.

I'm really disappointed with ARC in TObject

It is not going away, though. So either learn to use it, or go use another
development tool.

--
Remy Lebeau (TeamB)
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 8:17 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
TObject is not safe to pass over the DLL boundary without runtime packages
in both DLL and EXE. Only C++Builder can interact with TObject anyway.

No, you are completely wrong. C++ Object as same as COM object. No essential difference.
DLL(VC) do not need additional runtime package. We're using a lot of. So, your mind is really just limited to the Delphi world

If the EXE were written in another C++ compiler, it couldn't interact with
TObject at all,
You have no research on memory structure. And you don't have a try. Now, i tell you clearly, Delphi could use VC++ object.
Your conclusion is wrong.

No, but they can be used to access/simulate a VMT of a C++ object that crosses
the DLL boundary. This is how COM interfaces (which are generally based
on C++) are used in C, for instance.

I really think you're not deep enough in this area. In memory structure. COM object has a VMT, the first member is the pointer for VMT. TObject also has the sturcture.
C++ object has a little different. They has two case. If c++ object has no virtual method. Then. We can not use C++ object. If c++ object has virtual method.
And then the C++ object has the same the sturcture with TObject (That is the first member is the pointer for VMT).
Therefore, there is no doubt that we can use the virtual method to use the c++ object.
And this is not my speculation.That's what we're doing with the rest of the company. They supply c++ objects in dll with virtual functions and with STDCALL call convention.
It works very well.

It is not going away, though. So either learn to use it, or go use another
development tool.

I know ARC. It's easy.I do not think it's hard to learn. It is not more difficult than manage memory by myself. I opposition to it is not because of the difficulty of learning.
But because it is stupid to force everything to be ARC.
Arthur Hoornweg

Posts: 414
Registered: 6/2/98
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 1:12 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

It is hard to tell how much slowdowns will ARC bring to multithreading.
Just like with some other things some coding patterns will have to be changed
to remove bottlenecks.

Couldn't the user just overwrite _AddRef() and _Release() with non-atomic versions on selected classes? I do that for a few tInterfacedobjects where speed really matters.

Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 3:33 AM   in response to: Arthur Hoornweg in response to: Arthur Hoornweg
Arthur Hoornweg wrote:
Dalija Prasnikar wrote:

It is hard to tell how much slowdowns will ARC bring to multithreading.
Just like with some other things some coding patterns will have to be changed
to remove bottlenecks.

Couldn't the user just overwrite _AddRef() and _Release() with non-atomic versions on selected classes? I do that for a few tInterfacedobjects where speed really matters.


AFAIK on ARC compiler you cannot choose counting implementation.
But I am not 100% sure.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 10:53 AM   in response to: Arthur Hoornweg in response to: Arthur Hoornweg
Arthur wrote:

Couldn't the user just overwrite _AddRef() and _Release()
with non-atomic versions on selected classes?

In TObject ARC, the methods are __ObjAddRef() and __ObjRelease().

--
Remy Lebeau (TeamB)
Arthur Hoornweg

Posts: 414
Registered: 6/2/98
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 30, 2016 2:48 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:

In TObject ARC, the methods are __ObjAddRef() and __ObjRelease().

OK, but I suppose that's because Arc supports weak references which must be handled. Are these methods virtual, by any chance?
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 30, 2016 10:08 AM   in response to: Arthur Hoornweg in response to: Arthur Hoornweg
Arthur wrote:

Are these methods virtual, by any chance?

Yes, they are.

--
Remy Lebeau (TeamB)
Arthur Hoornweg

Posts: 414
Registered: 6/2/98
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 31, 2016 12:13 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
Arthur wrote:

Are these methods virtual, by any chance?

Yes, they are.

Then speed issues can be resolved in selected classes by overriding these methods with simpler non-atomic versions. One could even disable the refcounting (un-ARC!) which will make some forum members happy ;-)

loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 13, 2016 11:48 AM   in response to: Lajos Juhasz in response to: Lajos Juhasz
I doubt that that is the reason, that's not what Allen Bauer wrote. He
was all about to bring ARC and ZBS also to the desktop compiler of the
Delphi.

i m very happy that allen go to work at google! he was putting more
trouble in delphi than benefit ! Ansitring removed from llvm was also
because of him ...

I wonder when will Apple stop with this silly ARC thing. I think that
was the strongest influence why the LLVM based Delphi compilers support
ARC.

yes i often hear as a answer to the ARC: look apple they migrate to ARC
and it's work ... it's a pity :(
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 15, 2016 3:07 AM   in response to: loki loki in response to: loki loki
loki loki wrote:

I doubt that that is the reason, that's not what Allen Bauer wrote.
He was all about to bring ARC and ZBS also to the desktop compiler
of the Delphi.

i m very happy that allen go to work at google! he was putting more
trouble in delphi than benefit ! Ansitring removed from llvm was also
because of him ...

I am pretty sure that was not his decision, although simplification of
the entire string mess that grew more and more complex during the time
Delphi was developed was IMO a good idea. But the implementation of
Linux code requires UTF8String anyway, and that is why it was also
implemented for the mobile compilers in Berlin.

And LLVM doesn't know anything about AnsiStrings or UnicodeStrings. It
is an intermediate language and compiler back-end. The implementation
of strings is done by the Delphi compiler front-end and runtime, which
is not LLVM's.

--
Rudy Velthuis http://www.rvelthuis.de

"An inconvenience is only an adventure wrongly considered; an
adventure is an inconvenience rightly considered."
-- Gilbert Keith Chesterton (1874-1936)
Arthur Hoornweg

Posts: 414
Registered: 6/2/98
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 31, 2016 12:43 AM   in response to: loki loki in response to: loki loki
loki loki wrote:

yes i often hear as a answer to the ARC: look apple they migrate to ARC
and it's work ... it's a pity :(

The advantages of Arc are that its run time behaviour is smooth/deterministic and that it automatically minimizes memory consumption by releasing objects immediately when all references to it go out of scope.

Whereas GC-based systems always have tons of orphaned objects in memory which may delay new memory allocations and make the system choppy. Smoothness is important, choppiness can be a real show-stopper ( http://www.telegraph.co.uk/technology/2016/07/19/us-army-ditches-android-for-faster-iphones/ )

Anyway, theoretically it might be possible to un-Arc objects by overwriting virtual methods __ObjAddRef() and __ObjRelease() with dummy methods if you really want to go that way.

Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 14, 2016 4:41 AM   in response to: Ralf Stocker in response to: Ralf Stocker
Ralf Stocker wrote:
They offer ARC, because the LLVM Linux compiler has ARC. If the LLVM compiler would have no ARC, they would offer a none ARC compiler.

AFAIK, ARC is front end thing not back end.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 15, 2016 3:08 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

Ralf Stocker wrote:
They offer ARC, because the LLVM Linux compiler has ARC. If the
LLVM compiler would have no ARC, they would offer a none ARC
compiler.

AFAIK, ARC is front end thing not back end.

Indeed. The fact that LLVM's CLang compiler implements it for
Objective-C (and only for Obj-C) has nothing to do with the fact that
there is ARC in Delphi, although it was probably partly modelled after
it.

--
Rudy Velthuis http://www.rvelthuis.de

"If you kill one person you are a murderer. If you kill ten
people you are a monster. If you kill ten thousand you are
a national hero." -- Vassilis Epaminondou
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 15, 2016 2:31 AM   in response to: Ralf Stocker in response to: Ralf Stocker
Ralf Stocker wrote:

They offer ARC, because the LLVM Linux compiler has ARC. If the LLVM
compiler would have no ARC, they would offer a none ARC compiler.
BTW. Emba has no compiler engineer at the moment.

Where did you get that silly notion? Who do you think implements the
changes? Santa?

--
Rudy Velthuis http://www.rvelthuis.de

"Sir, you will either die of the pox or on the gallows."
-- The Earl Of Sandwich to John Wilkes

"That depends, sir, On whether I embrace your mistress or
your principles" -- John Wilkes to the Earl of Sandwich
Quentin Correll


Posts: 2,412
Registered: 12/1/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 13, 2016 11:08 AM   in response to: Ralf Stocker in response to: Ralf Stocker
Ralf,

| BTW. Emba has no compiler engineer at the moment. The Delphi dev is
| floating through the universe...

Ouch! <sigh>

--

Q -- XanaNews 1.19.1.372 - 2016-08-13 11:08:39
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 13, 2016 11:20 AM   in response to: Quentin Correll in response to: Quentin Correll
Quentin Correll wrote:
Ralf,

| BTW. Emba has no compiler engineer at the moment. The Delphi dev is
| floating through the universe...

Ouch! <sigh>

They still have people working on compilers. They just no longer have
Chief Scientist position.

And yes, there are some holes that will be hard to fill but sky has not fallen yet
nor it will anytime soon.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 13, 2016 12:04 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
They still have people working on compilers. They just no longer have
Chief Scientist position.

unicode on 16bit, arc, zero base string, ansiString removed (on purpose)
from LLVM to finally be added back in berlin and now linux with ARC ...
do you really thing that they was a chief scientist before ??

And yes, there are some holes that will be hard to fill but sky has not fallen yet
nor it will anytime soon.

i hope :(
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 14, 2016 1:01 AM   in response to: loki loki in response to: loki loki
Am 13.08.2016 um 21:04 schrieb loki loki:
They still have people working on compilers. They just no longer have
Chief Scientist position.

unicode on 16bit, arc, zero base string, ansiString removed (on purpose)
from LLVM to finally be added back in berlin and now linux with ARC ...
do you really thing that they was a chief scientist before ??

Yes I do. Unicode done as 16 bit was due to the only supported platform
at that point in time: Windows. So stop complaining at EMBT for this and
start to complain at Microsoft!

And please be precise: afaik AnsiString still does not exist in the
mobile compilers in Berlin. RawByteString got "undisabled". I have no
problems with questioning what EMBT does, but only if it stays to the facts.

Greetings

Markus
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 14, 2016 2:59 AM   in response to: Markus Humm in response to: Markus Humm
unicode on 16bit, arc, zero base string, ansiString removed (on purpose)
from LLVM to finally be added back in berlin and now linux with ARC ...
do you really thing that they was a chief scientist before ??

Yes I do. Unicode done as 16 bit was due to the only supported platform
at that point in time: Windows. So stop complaining at EMBT for this and
start to complain at Microsoft!

excuse me, but at this exact point, they took the decision to make
delphi a cross compiler tool (you can read the source code on d2009 and
see that they stop to make fast ASM function (like Fastcode) writing in
comments that now it's not good to write ASM for a product that will be
cross compiler)

so saying they choose 16 bit because of windows and at the same time
already think about other system it's what i say: no chief in the command

And windows also support 8 bit string :) look lazarus, they do unicode
on UTF8 (8 bit string).

most important is always to keep compatibility with previous code, and
at this exact point with unicode they break the compatibility !
you can say what you want it's was the worse mistake they does, they
destroy delphi at this exact moment. All the multi-thier library was
suddenly destroyed, look on torry.net how many companent are still on
version d2009- and are now abandonned :( all of this code simply lost,
it's was like killing the past and restarting from zero ... problem it's
didn't restart and now you see the delphi developper are where ? by how
many it's was divided from 2009 ?? that a fact

say what you want, me i m not blind and i see what i see ...

And please be precise: afaik AnsiString still does not exist in the
mobile compilers in Berlin. RawByteString got "undisabled". I have no
problems with questioning what EMBT does, but only if it stays to the facts.

ok, yes in berlin you have utf8 string that is 8 bit string, so yes not
really ansiString, but at least 8 bit string. in didn't want to speak
about unicode/widestring/ansiString/utf8string/etc but instead about 8
bit string and 16 bit string. after you can do what you want with them,
nothing forbid you to store binary data in utf8 string (even in unicode
string) for example
Brandon Staggs

Posts: 683
Registered: 3/3/01
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 14, 2016 6:00 AM   in response to: loki loki in response to: loki loki
"loki loki" wrote on Sun, 14 Aug 2016 02:59:06 -0700:

And windows also support 8 bit string :) look lazarus, they do unicode
on UTF8 (8 bit string).

We've had this argument before. It would be FOOLISH to make UTF8 the
default string type on Windows, and when Delphi finally made Unicode
the default string type, it was mainly a Windows platform (and it
still is). On Windows I would NOT want UTF8 to be the default string
type. It would be insane to do that there.

That doesn't mean I don't use UTF8.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 14, 2016 7:12 AM   in response to: Brandon Staggs in response to: Brandon Staggs
And windows also support 8 bit string :) look lazarus, they do unicode
on UTF8 (8 bit string).

We've had this argument before. It would be FOOLISH to make UTF8 the
default string type on Windows, and when Delphi finally made Unicode
the default string type, it was mainly a Windows platform (and it
still is). On Windows I would NOT want UTF8 to be the default string
type. It would be insane to do that there.

That doesn't mean I don't use UTF8.

i can understand you word, because you are still using delphi :) but
where are all the other delphi developper that not agree with you ;) ;)

again the problem was to break the compatibility with previous code, not
that unicode is the default string type or not in delphi.

what you say it's just a point of view (IE: your point of view), and
probably the point of view that the few delphi developper who are still
here have ! but it's not mean it's a true point of view !!

their was no problem to make unicode and ansiString leave together, keep
string=8 bit string and add a new unicodeString type and keep tiny
function like pos, inttostr, formatfloat, etc.. compatible with both
variant, unicodestring and ansiString

but instead emb decide to be extrem, replace type string to 16 bit
string, and destroy all compatibility :( 7 years later we can see the
damage, the delphi comunity collapse drastically, i even hear that all
the emb delphi team was fired ... it's a pity :(

Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 14, 2016 8:17 AM   in response to: loki loki in response to: loki loki
Am 14.08.2016 um 16:12 schrieb loki loki:
And windows also support 8 bit string :) look lazarus, they do unicode
on UTF8 (8 bit string).

We've had this argument before. It would be FOOLISH to make UTF8 the
default string type on Windows, and when Delphi finally made Unicode
the default string type, it was mainly a Windows platform (and it
still is). On Windows I would NOT want UTF8 to be the default string
type. It would be insane to do that there.

That doesn't mean I don't use UTF8.

i can understand you word, because you are still using delphi :) but
where are all the other delphi developper that not agree with you ;) ;)

again the problem was to break the compatibility with previous code, not
that unicode is the default string type or not in delphi.

what you say it's just a point of view (IE: your point of view), and
probably the point of view that the few delphi developper who are still
here have ! but it's not mean it's a true point of view !!

their was no problem to make unicode and ansiString leave together, keep
string=8 bit string and add a new unicodeString type and keep tiny
function like pos, inttostr, formatfloat, etc.. compatible with both
variant, unicodestring and ansiString

but instead emb decide to be extrem, replace type string to 16 bit
string, and destroy all compatibility :( 7 years later we can see the
damage, the delphi comunity collapse drastically, i even hear that all
the emb delphi team was fired ... it's a pity :(


Hello,

you often misinterpret things.
And one thing: transitioning from 8 bit AnsiString to a UTF8 string
would only create a false feeling of security for too many unaware
developers.

That would only help developers in western hemisphere mostly only having
to work with one locale/charset.

Additionally: those decisions are not easy and you're not their only
customer. Other customers might have (had) other requirements.

Greetings

Markus
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 14, 2016 9:19 AM   in response to: Markus Humm in response to: Markus Humm

you often misinterpret things.
And one thing: transitioning from 8 bit AnsiString to a UTF8 string
would only create a false feeling of security for too many unaware
developers.

so explain me why the all world work on utf8 under html and not under
utf16 ! maybe you need to read this doc: http://utf8everywhere.org/


Additionally: those decisions are not easy and you're not their only
customer. Other customers might have (had) other requirements.

i agree i was not their only customer, problem i don't see anymore the
other developers :(
Quentin Correll


Posts: 2,412
Registered: 12/1/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 14, 2016 12:36 PM   in response to: loki loki in response to: loki loki
loki,

| read this doc: http://utf8everywhere.org/

"UTF-16 is the worst of both worlds,"

My feeling as well!

Thanks for that link!

--

Q -- XanaNews 1.19.1.372 - 2016-08-14 12:34:58
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 14, 2016 1:13 PM   in response to: Quentin Correll in response to: Quentin Correll
Quentin wrote:

"UTF-16 is the worst of both worlds,"

My feeling as well!

And yet:

1. Windows native strings and APIs are based UTF-16.

1. Java/Android native strings and APIs are based UTF-16.

1. OSX/iOS native strings and APIs are based UTF-16.

For years, Delphi's native string type was ANSI, and that imposed lots of
overhead when calling OS APIs. Now its default string type is UTF-16, and
that overhead is finally gone. UTF8<->UTF16 conversions are lossless, but
they are still imposing runtime overhead. Do you really think it would be
wise for Embarcadero to make Delphi's native string type be something other
than UTF-16 on multiple platforms whose native APIs are also based on UTF-16?
I don't think so. If you want to use UTF-8 to store your own data, go for
it. If you want to interact with Delphi APIs and OS API, UTF-8 is not the
best choice for that.

--
Remy Lebeau (TeamB)
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 14, 2016 2:23 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...

1. Windows native strings and APIs are based UTF-16.

1. Java/Android native strings and APIs are based UTF-16.

1. OSX/iOS native strings and APIs are based UTF-16.

and what ? if delphi was made from the beginning with UTF-16 that could
be good also ! but it's was not the case :(

For years, Delphi's native string type was ANSI, and that imposed lots of
overhead when calling OS APIs. Now its default string type is UTF-16, and
that overhead is finally gone.

except that all the world is still on utf8/8 bit string, like database,
html, text file, etc... so you replace one overhead by another overhead :(

they are still imposing runtime overhead. Do you really think it would be
wise for Embarcadero to make Delphi's native string type be something other
than UTF-16 on multiple platforms whose native APIs are also based on UTF-16?

ahahah we are speaking of linux now in next version of delphi, linux is
not on utf-8 ?

I don't think so. If you want to use UTF-8 to store your own data, go for
it. If you want to interact with Delphi APIs and OS API, UTF-8 is not the
best choice for that.

no, but the good decision was to add a new utf16 string that can cohabit
with the default ansiString instead of replacing the default ansistring
to utf16 and loosing compatibility
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 14, 2016 2:46 PM   in response to: loki loki in response to: loki loki
loki wrote:

except that all the world is still on utf8/8 bit string, like
database, html, text file, etc... so you replace one overhead
by another overhead :(

DATA can certainly be in UTF-8, or any other encoding. That doesn't change
what I said about APIs. And using ANSI strings did not avoid the need
for runtime data conversions when processing data in terms of Unicode.

ahahah we are speaking of linux now in next version of delphi,
linux is not on utf-8 ?

I was referring to all of the other platforms that Delphi already supports.
None of them are based on UTF-8. Embarcadero has not released any information
about its Linux compiler yet, other than it will be using ARC like the other
compilers. Chances are, the native string type will remain UTF-16. It doesn't
make sense to have one compiler using UTF-8 and all of the other compilers
using UTF-16. A whole new set of RTL/FMX libraries will have to be created.
Which goes right back to the old discussion about having separate ANSI and
Unicode versions of the RTL/VCL/FMX. Not going to happen. If anything,
everything will remain UTF-16, and at the lower OS level the RTL will simply
convert from UTF-16 to UTF-8 and vice versa when needed. An undesirable
conversion, certainly, but a simpler one than conversions between ANSI and
Unicode.

no, but the good decision was to add a new utf16 string that can
cohabit with the default ansiString

Which they did. AnsiString still existed at the time UnicodeString was added.
And to this day, still exists on the desktop compilers, and is not going
away anytime soon, if ever.

instead of replacing the default ansistring to utf16

That was the correct decision at the time to support Windows better. Cross-platform
development had not been added to Delphi yet, that came several versions
later. And since Windows, OSX, iOS, and Android are all based on UTF-16,
it makes sense to leave the default string type as UTF-16. If Linux changes
things, I'm sure Embarcadero will figure out a way to deal with it.

and loosing compatibility

The compatibilty that was "lost" was for people who were abusing AnsiString
in the first place for things it was not intended for. The vast majority
of existing code ported from AnsiString to UnicodeString just fine with very
little changes needed, if any changes at all.

--
Remy Lebeau (TeamB)
Quentin Correll


Posts: 2,412
Registered: 12/1/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 14, 2016 4:17 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy,

| The vast majority
| of existing code ported from AnsiString to UnicodeString just fine
| with very little changes needed, if any changes at all.

Yeah, I was surprised that I did not have to do anything to my apps
that I updated or re-compiled!

--

Q -- XanaNews 1.19.1.372 - 2016-08-14 16:15:51
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 14, 2016 11:48 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Am 14.08.2016 um 23:46 schrieb Remy Lebeau (TeamB):
loki wrote:

except that all the world is still on utf8/8 bit string, like
database, html, text file, etc... so you replace one overhead
by another overhead :(

DATA can certainly be in UTF-8, or any other encoding. That doesn't change
what I said about APIs. And using ANSI strings did not avoid the need
for runtime data conversions when processing data in terms of Unicode.

And he forgot another thing:
when Delphi 2 introduced the AnsiString datatype back in 1996 all the
consumer versions of Windows didn't support Unicode at all and Windows
NT was not too widespread yet I guess.

Greetings

Markus
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 15, 2016 2:25 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...

Which they did. AnsiString still existed at the time UnicodeString was added.
And to this day, still exists on the desktop compilers, and is not going
away anytime soon, if ever.

And how they did it? they simply remove all the ansiString skiny
function like inttostr, floattostr, formatfloat, Tstrings, etc... :(
instead of moving the existing code in for exemple the unit ansiString,
destroying all the possibility for end user to simply replace string
by ansiString to keep staying in ansiString :( seriously it's was not
a good job at all !


The compatibilty that was "lost" was for people who were abusing AnsiString
in the first place for things it was not intended for.

i disagree, because 8 bit string, and the powerfull skiny function (like
pos, like managed string, etc.) was very usefull to parse all data
with characters codepoint inside with could cohabit with binary data,
like html, xml, socket answer, etc.. string is not only shakespear text
this what you don't understand :(

The vast majority
of existing code ported from AnsiString to UnicodeString just fine with very
little changes needed, if any changes at all.

remy, that depend of the software ! i worked on a huge isapi app with my
own database driver, everything was on utf8 via ansiString, and believe
me the migration to the "forced" unicode was all but not easy ...
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 15, 2016 3:37 AM   in response to: loki loki in response to: loki loki
loki loki wrote:


1. Windows native strings and APIs are based UTF-16.

1. Java/Android native strings and APIs are based UTF-16.

1. OSX/iOS native strings and APIs are based UTF-16.

and what ? if delphi was made from the beginning with UTF-16 that
could be good also ! but it's was not the case :(

In 1995, that was not the case indeed, especially not because Delphi
1.0 ran on 16-bit Windows 3.x.

Java, OS X, iOS and Android came later. OK, Java was released in 1995
too, but only for Sun Microsystems. Its ubiquity came later.

--
Rudy Velthuis http://www.rvelthuis.de

"I don't know anything about music. In my line you don't have
to." -- Elvis Presley (1935-1977)
Quentin Correll


Posts: 2,412
Registered: 12/1/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 14, 2016 4:14 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy,

Yeah, I know you're right.

I'm just such an ol'timer I wish things were still like "the ol'days."
<g>

--

Q -- XanaNews 1.19.1.372 - 2016-08-14 16:13:03
Brandon Staggs

Posts: 683
Registered: 3/3/01
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 15, 2016 8:16 AM   in response to: Quentin Correll in response to: Quentin Correll
"Quentin Correll" wrote on Sun, 14 Aug 2016 12:36:07 -0700:

"UTF-16 is the worst of both worlds,"

Nonsense, and irrelevant anyway. Windows uses UTF-16 natively. Using
anything else as a default string type in Delphi would have
unacceptable performance issues, just to start.

It does not matter if some people think Windows shouldn't have used
UTF-16 natively. It has for decades. End of story.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 15, 2016 8:36 AM   in response to: Brandon Staggs in response to: Brandon Staggs
On 8/15/2016 6:16 PM, Brandon Staggs wrote:
"Quentin Correll" wrote on Sun, 14 Aug 2016 12:36:07 -0700:

"UTF-16 is the worst of both worlds,"

Nonsense, and irrelevant anyway. Windows uses UTF-16 natively. Using
anything else as a default string type in Delphi would have
unacceptable performance issues, just to start.

It does not matter if some people think Windows shouldn't have used
UTF-16 natively. It has for decades. End of story.

and what? the question is not utf8 or utf16, the problem was : it's was
a bad decision to remove ansistring to replace it by unicode instead of
just adding unicode !

i never say that it's was a mistake to add utf-16 in delphi, it's was a
mistake to remove ansiString from delphi ... end of the story
Brandon Staggs

Posts: 683
Registered: 3/3/01
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 15, 2016 1:36 PM   in response to: loki loki in response to: loki loki
"loki loki" wrote on Mon, 15 Aug 2016 08:36:39 -0700:

and what? the question is not utf8 or utf16, the problem was : it's was
a bad decision to remove ansistring to replace it by unicode instead of
just adding unicode !

AnsiString was never removed in Delphi for Windows. The stupid
decision to hide 8-bit strings in mobile from users without using a
hack has been reversed now, hasn't it?

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 15, 2016 1:49 PM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon Staggs wrote:
"loki loki" wrote on Mon, 15 Aug 2016 08:36:39 -0700:

and what? the question is not utf8 or utf16, the problem was : it's was
a bad decision to remove ansistring to replace it by unicode instead of
just adding unicode !

AnsiString was never removed in Delphi for Windows. The stupid
decision to hide 8-bit strings in mobile from users without using a
hack has been reversed now, hasn't it?

Well... UTF8String and RawByteString have been supported now, but
that is it. Should be enough.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 15, 2016 1:55 PM   in response to: Brandon Staggs in response to: Brandon Staggs
Brandon wrote:

AnsiString was never removed in Delphi for Windows. The stupid
decision to hide 8-bit strings in mobile from users without using a
hack has been reversed now, hasn't it?

Only in part, but not fully. RawByteString and UTF8String have been "restored".

--
Remy Lebeau (TeamB)
Brandon Staggs

Posts: 683
Registered: 3/3/01
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 16, 2016 5:36 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
"Remy Lebeau" wrote on Mon, 15 Aug 2016 13:55:37 -0700:

Only in part, but not fully. RawByteString and UTF8String have been "restored".

I see. That would be enough for my needs, should I decide to use
those compilers.

--
Brandon Staggs
StudyLamp Software LLC
http://www.studylamp.com
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 15, 2016 3:53 PM   in response to: Brandon Staggs in response to: Brandon Staggs
On 8/15/2016 11:36 PM, Brandon Staggs wrote:
"loki loki" wrote on Mon, 15 Aug 2016 08:36:39 -0700:

and what? the question is not utf8 or utf16, the problem was : it's was
a bad decision to remove ansistring to replace it by unicode instead of
just adding unicode !

AnsiString was never removed in Delphi for Windows. The stupid
decision to hide 8-bit strings in mobile from users without using a
hack has been reversed now, hasn't it?

off course they was :( all the tiny function like inttostr, floattostr,
TstringList, etc was removed from ansiString :(
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 15, 2016 4:54 PM   in response to: loki loki in response to: loki loki
loki wrote:

off course they was :( all the tiny function like inttostr,
floattostr, TstringList, etc was removed from ansiString :(

IntToStr() and FloatToStr() return the default string type, and always have.
Functions cannot be overloaded on return value type alone, only on parameters.
To expose AnsiString versions of these functions would require all new functions
with either different names or output parameters, either way would require
changes in your code to call them with AnsiString values.

TStringList uses the default string type, and always has. There is no AnsiString
version of it. If you need that, you will have to write your own, or find
a 3rd party implementation. Or, use TList<AnsiString> instead.

--
Remy Lebeau (TeamB)
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 16, 2016 2:56 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
On 8/16/2016 2:54 AM, Remy Lebeau (TeamB) wrote:
loki wrote:

off course they was :( all the tiny function like inttostr,
floattostr, TstringList, etc was removed from ansiString :(

IntToStr() and FloatToStr() return the default string type, and always have.
Functions cannot be overloaded on return value type alone, only on parameters.
To expose AnsiString versions of these functions would require all new functions
with either different names or output parameters, either way would require
changes in your code to call them with AnsiString values.

exactly, the good way was to introduce utf16 with a new naming convention

TStringList uses the default string type, and always has. There is no AnsiString
version of it. If you need that, you will have to write your own, or find
a 3rd party implementation. Or, use TList<AnsiString> instead.

their is no "default" string type ! their 8 bit string and 16 bit string
! saying i want absolutely that the name string = unicodeString when
before the name string = ansiString was the mistake that break all the
ascent compatibility. their was no problem to add a new unicodeString
type and unicode component suite that go with it.

now you can say what you want the fact is here, after d2009+ we loose
all the past source code, and now (subject of this discution) emb do
again the same mistake with introducing arc in linux ... like they never
learm from their mistake !
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 16, 2016 5:11 AM   in response to: loki loki in response to: loki loki
Am 16.08.2016 um 11:56 schrieb loki loki:


now you can say what you want the fact is here, after d2009+ we loose
all the past source code

That's an exaggeration and the help did state before that "string" is
only an alias to the concrete type and might change in the future.

Greetings

Markus
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 16, 2016 10:23 AM   in response to: loki loki in response to: loki loki
loki wrote:

exactly, the good way was to introduce utf16 with a new naming
convention

Which would have required users to make much more code changes than they
had to. The whole point of the way the Unicode migration was implemented
was to minimize code changes, not add to them. Was it a perfect migration?
No. Was it an adequate migration? Yes, for the majority of users. Of
course, there are always exceptions to every rule, and clearly your code
is one of them. MOST users were not badly affected.

their is no "default" string type !

Um, yes there is - System.String.

their 8 bit string and 16 bit string ! saying i want absolutely that the
name
string = unicodeString when before the name string = ansiString was the
mistake

No, it was not a mistake. Just because you don't like it this way does
not mean it was wrong to do it this way.

that break all the ascent compatibility.

Not really.

their was no problem to add a new unicodeString type

In of itself, no.

and unicode component suite that go with it.

Yes, there was, actually. It would have been a MAJOR undertaking to create
and maintain separate libraries for Ansi vs Unicode. They settled on a Unicode-only
library, and for good reasons. And besides, the rest of the world is Unicode,
Ansi is on its way out. If you want to keep using Ansi, that is your choice,
but don't use a Unicode product for it. Go back to using an Ansi product.

now you can say what you want the fact is here, after d2009+ we
loose all the past source code

You might have. Most users did not.

and now (subject of this discution) emb do again the same
mistake with introducing arc in linux ... like they never learm
from their mistake !

Introducing ARC was not a mistake. Objects in iOS and Android have system-managed
lifespans. Making Delphi objects have a similar managed lifespan helps Delphi
code play niver in those platforms. Certain aspects of the implementation
of Delphi's ARC could certainly be better, but using ARC in general is not
a mistake unless you misuse it and don't make the effort to understand it.

--
Remy Lebeau (TeamB)
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 16, 2016 12:07 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Was it a perfect migration? No.

ok we agree on this :)

And besides, the rest of the world is Unicode,
Ansi is on its way out. If you want to keep using Ansi, that is your choice,
but don't use a Unicode product for it. Go back to using an Ansi product.

yes the world is on unicode, you are right, but on unicode 8 bit ;)
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 2:22 AM   in response to: loki loki in response to: loki loki
loki loki wrote:
Was it a perfect migration? No.

ok we agree on this :)

And besides, the rest of the world is Unicode,
Ansi is on its way out. If you want to keep using Ansi, that is your choice,
but don't use a Unicode product for it. Go back to using an Ansi product.

yes the world is on unicode, you are right, but on unicode 8 bit ;)

UTF8 is mainly used for storage and transmmiting data. Windows, Android
iOS and OSX all use UTF-16 as internal OS string types. For interfacing
with OS API's that is the best type. Why is that so hard to understand.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
Arthur Hoornweg

Posts: 414
Registered: 6/2/98
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 12:53 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

UTF8 is mainly used for storage and transmmiting data. Windows, Android
iOS and OSX all use UTF-16 as internal OS string types.

Hold on, isn't Android built on top of Linux? Isn't Linux UTF8?

Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 12:55 AM   in response to: Arthur Hoornweg in response to: Arthur Hoornweg
Arthur Hoornweg wrote:
Dalija Prasnikar wrote:

UTF8 is mainly used for storage and transmmiting data. Windows, Android
iOS and OSX all use UTF-16 as internal OS string types.

Hold on, isn't Android built on top of Linux? Isn't Linux UTF8?


Android runs on top of modified Java VM. UTF-16 all the way.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 1:52 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

Arthur Hoornweg wrote:
Dalija Prasnikar wrote:

UTF8 is mainly used for storage and transmmiting data. Windows,
Android iOS and OSX all use UTF-16 as internal OS string types.

Hold on, isn't Android built on top of Linux? Isn't Linux UTF8?


Android runs on top of modified Java VM. UTF-16 all the way.

Indeed. UTF-16 and big-endian all the way, no matter what the
underlying platform is or uses.
--
Rudy Velthuis http://www.rvelthuis.de

"Faith is belief without evidence in what is told by one who
speaks without knowledge, of things without parallel."
-- Ambrose Bierce
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 10:44 AM   in response to: Arthur Hoornweg in response to: Arthur Hoornweg
Arthur wrote:

Hold on, isn't Android built on top of Linux? Isn't Linux UTF8?

Android is Java (UTF-16) running on top of Linux.

--
Remy Lebeau (TeamB)
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 18, 2016 9:25 AM   in response to: loki loki in response to: loki loki
Am 16.08.2016 um 21:07 schrieb loki loki:
Was it a perfect migration? No.

ok we agree on this :)

And besides, the rest of the world is Unicode,
Ansi is on its way out. If you want to keep using Ansi, that is your choice,
but don't use a Unicode product for it. Go back to using an Ansi product.

yes the world is on unicode, you are right, but on unicode 8 bit ;)

Only in your narrow view which seems to be on HTML and Linux only. Most
if not all other major OS (Windows, OS X, Android iOS) use UTF16.
But you have already been told that.

Greetings

Markus
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 2:23 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
loki wrote:

exactly, the good way was to introduce utf16 with a new naming
convention

Which would have required users to make much more code changes than they
had to. The whole point of the way the Unicode migration was implemented
was to minimize code changes, not add to them. Was it a perfect migration?
No. Was it an adequate migration? Yes, for the majority of users. Of
course, there are always exceptions to every rule, and clearly your code
is one of them. MOST users were not badly affected.

Exactly.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 6:16 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:
Remy Lebeau (TeamB) wrote:
loki wrote:

exactly, the good way was to introduce utf16 with a new naming
convention

Which would have required users to make much more code changes than they
had to. The whole point of the way the Unicode migration was implemented
was to minimize code changes, not add to them. Was it a perfect migration?
No. Was it an adequate migration? Yes, for the majority of users. Of
course, there are always exceptions to every rule, and clearly your code
is one of them. MOST users were not badly affected.

Exactly.

This minimize code changes just for you need new feature(UnicodeString).
If you do not need UnicodeString. And let the code work as old days. There is no doubt that you need to do more.

And for new feature, it is not a compatible question. It is a question for how much of the cost to get a new feature(UnicodeString).

In order to automatically get this new feature and sacrifice compatibility. This is not wise
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 6:52 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:
Dalija Prasnikar wrote:
Remy Lebeau (TeamB) wrote:
loki wrote:

exactly, the good way was to introduce utf16 with a new naming
convention

Which would have required users to make much more code changes than they
had to. The whole point of the way the Unicode migration was implemented
was to minimize code changes, not add to them. Was it a perfect migration?
No. Was it an adequate migration? Yes, for the majority of users. Of
course, there are always exceptions to every rule, and clearly your code
is one of them. MOST users were not badly affected.

Exactly.

This minimize code changes just for you need new feature(UnicodeString).
If you do not need UnicodeString. And let the code work as old days. There is no doubt that you need to do more.

It minimizes code changes for everyone.

You can say that you don't need Unicode, but Windows supports UTF-16 since
Windows 2000. That was 16-years ago.

Delphi had to introduce Unicode. And since having compiler switch is not
possible it had to be introduced for all, whether you like it or not.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 3:46 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija wrote:

You can say that you don't need Unicode, but Windows supports
UTF-16 since Windows 2000. That was 16-years ago.

Even earlier than that, if you count UCS-2 in Windows NT4.

--
Remy Lebeau (TeamB)
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 5:48 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...

You can say that you don't need Unicode, but Windows supports
UTF-16 since Windows 2000. That was 16-years ago.

Even earlier than that, if you count UCS-2 in Windows NT4.

But whatever it is. Look c++, supply char* and w_char*. Select by yourself and do whatever you want. Mans do not need chang any thing, no matter how earlier USC-2 in windows.

The truth is more obvious. Delphi sacrifice us for those who want get UnicodeString automatically. They force us to chang my code for a function that I don't need .
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 7:03 PM   in response to: wenjie zhou in response to: wenjie zhou
wenjie wrote:

But whatever it is. Look c++, supply char* and w_char*.

Do you realize the amount of effort it takes to maintain two sets of libraries
for those data types? This is even more apparent in C, but at least C++
supports templates so a single implementation can be specialization for char
and wchar_t as needed to reduce overhead of repeated code. But that still
doesn't negate the fact that char and wchar_t are two separate data types,
that need to be handled separately the further down the layers you go.

And besides, C++ is controlled by committee, no single compiler can change
the rules (not counting extensions). Everyone has to agree to a change that
effects everyone. That is not the case with Delphi, which is the sole property
of one company that can do whatever it wants with Delphi.

The truth is more obvious. Delphi sacrifice us for those who want get
UnicodeString automatically. They force us to chang my code for a
function that I don't need .

Delphi is not C++, so stop comparing them. If you don't like what Embarcadero
did, don't use it.

--
Remy Lebeau (TeamB)
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 8:36 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Do you realize the amount of effort it takes to maintain two sets of libraries
for those data types? This is even more apparent in C, but at least C++
supports templates so a single implementation can be specialization for char
and wchar_t as needed to reduce overhead of repeated code. But that still
doesn't negate the fact that char and wchar_t are two separate data types,
that need to be handled separately the further down the layers you go.

What you said is try to prove that : There's a better solution. Just because more efforts. So, they choose an easier solution. That is the truth.

And besides, C++ is controlled by committee, no single compiler can change
the rules (not counting extensions). Everyone has to agree to a change that
effects everyone. That is not the case with Delphi, which is the sole property
of one company that can do whatever it wants with Delphi.

That looks better. Instead of random changes


Delphi is not C++, so stop comparing them. If you don't like what Embarcadero
did, don't use it.
I don't like what Embarcadero did. And i try to speak out. And try to change it.
And if all effort had no effect. If the worst things happend(e.g. ARC in Desktop).
I will leave. And don't need you to tell me.

3 years ago. When i talk about some bad things in new Delphi on a forums. Many people do not care.
But now, in the forums, more people is talking about using C# instead of Delphi, or using free pascal.
How many facts do we need to prove some decisions are problematic. Many Embarcadero did is not correct.
Kim Madsen

Posts: 362
Registered: 12/13/99
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 18, 2016 6:04 AM   in response to: wenjie zhou in response to: wenjie zhou

That looks better. Instead of random changes

Ive been working extensively with C++ and I cant really say that the
output of a committee has done much positive to the language and syntax.
Basically C++ is IMO a genuine mess of attempts to fix problems in the
basic structure, resulting in ever more complex syntax and ever less
readable code.

The biggest issue is that the design flaws/ugly syntax/not fully well
designed new parts introduced in earlier versions of the language,
continues to be supported in later versions, providing many ways to
describe the almost same ting. In Delphi I have always advorcated for
keeping backwards compatibility, and they have done a great job doing
that, because not many "blunders" entered the language syntax compared
to C++.

I kind of like the dictatorial choises made in Delphi. The syntax is
generally very clean and readable, even with all the new stuff that has
been added over the years.


best regards
Kim/C4D

wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 18, 2016 6:27 PM   in response to: Kim Madsen in response to: Kim Madsen
Kim Madsen wrote:

That looks better. Instead of random changes

Ive been working extensively with C++ and I cant really say that the
output of a committee has done much positive to the language and syntax.
Basically C++ is IMO a genuine mess of attempts to fix problems in the
basic structure, resulting in ever more complex syntax and ever less
readable code.

The biggest issue is that the design flaws/ugly syntax/not fully well
designed new parts introduced in earlier versions of the language,
continues to be supported in later versions, providing many ways to
describe the almost same ting. In Delphi I have always advorcated for
keeping backwards compatibility, and they have done a great job doing
that, because not many "blunders" entered the language syntax compared
to C++.

I kind of like the dictatorial choises made in Delphi. The syntax is
generally very clean and readable, even with all the new stuff that has
been added over the years.

It's like the difference between dictatorship and democracy. If the dictator is a wise monarch.
Things will develop in the right direction.Otherwise, it will only be in a worse direction.

Then the question is, does embarcadero has really scientist. Is there enough scientific theory to support the decisions they make.
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 8:38 AM   in response to: wenjie zhou in response to: wenjie zhou
It's like the difference between dictatorship and democracy. If the dictator is a wise monarch.
Things will develop in the right direction.Otherwise, it will only be in a worse direction.

Then the question is, does embarcadero has really scientist. Is there enough scientific theory to support the decisions they make.

just see the zero base string they introduce and understand that their
is noone serious in this position !
Kim Madsen

Posts: 362
Registered: 12/13/99
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 8:49 AM   in response to: loki loki in response to: loki loki
Den 8/19/2016 kl. 17:38 skrev loki loki:
It's like the difference between dictatorship and democracy. If the dictator is a wise monarch.
Things will develop in the right direction.Otherwise, it will only be in a worse direction.

Then the question is, does embarcadero has really scientist. Is there enough scientific theory to support the decisions they make.

just see the zero base string they introduce and understand that their
is noone serious in this position !

I cant say that I was happy about zero based string indexes, since
Delphi all the time used 1 based string indexes. However I understand
that the rest of the world use zero based indexes, and thus it makes it
slightly "easier" to sell to new users.

They recognized the problem, and made an option to choose to use 1 or 0
based string indexing...and that didnt improve much in the clarity of
things imo. So the same could be said about maintaining a switch for ARC
or no ARC and the libraries that supports it.

What I would prefer, is basically a NextGen Windows compiler. The day
that happens, I bet that people automatically will start to embrace ARC
and 0 based string indexing for new code, and it will be fairly simple
to debug too, since most of the existing debugging tools on Windows
could be used with little or no changes.

best regards
Kim/C4D
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 11:15 AM   in response to: Kim Madsen in response to: Kim Madsen
I cant say that I was happy about zero based string indexes, since
Delphi all the time used 1 based string indexes. However I understand
that the rest of the world use zero based indexes, and thus it makes it
slightly "easier" to sell to new users.

but off course it's could be better to have string starting from 0, but
in this way from the beginning !! not that suddenly your S[1] will get
wrong without any warning ! and now mixing string function that start
from 1 like pos and other that start from 0 like s.indexof ... stupid :(

at least they can introduce a new way like
S[x] = 1 based string
s[{x}] = 0 base string

not breaking everything


What I would prefer, is basically a NextGen Windows compiler. The day
that happens, I bet that people automatically will start to embrace ARC
and 0 based string indexing for new code, and it will be fairly simple
to debug too, since most of the existing debugging tools on Windows
could be used with little or no changes.

sincerely from the time i start developing on mobile, i don't see any
advantage at all with ARC! it's completely useless, dangerous and not
productive !

it's help maybe if you work with teenager doing low quality or even
shitty code and you don't want to care about memory leaks.

else seriously nothing to embrace ! never !

what will be next? no need to declare the variable maybe ??
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 12:04 PM   in response to: loki loki in response to: loki loki
loki wrote:

but off course it's could be better to have string starting from 0,
but in this way from the beginning !! not that suddenly your S[1] will
get wrong without any warning !

The reason strings are even 1-based at all with is for backwards compatibility
with ShortString, where S[0] is the string length and S[1] is the first character.
When AnsiString was first added, the default string type was changed from
ShortString to AnsiString (unless you disable the {$H} compiler directive),
so existing code that expected 1-based indexing needed to be preserved when
ported to AnsiString. That has carried through the years. Now enter mobile
and 0-based strings. ShortString doesn't even exist (well, more accurately,
it is hidden) in the mobile compilers.

and now mixing string function that start from 1 like pos and other
that start from 0 like s.indexof ... stupid :(

Nobody is going to deny that 0-based strings in Delphi is stupid.

But Embarcadero introduced a clear migration path (deprecated the 1-based
RTL functions in favor of the new 0-based record helpers) does not break
existing code. It was very smart. People who WANT 0-based indexing, even
on desktop systems, can do so. People who WANT 1-based indexing, even on
mobile systems, can do so.

at least they can introduce a new way like
S[x] = 1 based string
s[{x}] = 0 base string
not breaking everything

They did introduce a new way, via the new Chars[] property:

uses
  SysUtils; // activate string helper
 
s.Chars[x] // always 0 based on all platforms


The "S[x]" syntax is 0-based or 1-based, depending on the {$ZEROBASEDSTRINGS}
directive, which is ON by default for mobile and OFF by default for desktop.
Now THAT was stupid, IMHO, and where the majority of confusion comes into
play. But all of the existing RTL string functions remain 1-based on all
platforms, and the new TStringHelper methods are all 0-based on all platforms.
You should stay away from the string "[]" operator, unless you explictiy
set {$ZEROBASEDSTRINGS} to your liking.

--
Remy Lebeau (TeamB)
Quentin Correll


Posts: 2,412
Registered: 12/1/99
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 12:42 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy,

| You should stay away from the string "[]" operator, unless you
| explictiy set {$ZEROBASEDSTRINGS} to your liking.

I have lots of OLD code which use string[]...
written LONG before {$ZEROBASEDSTRINGS} existed. <grumbling sigh>

--

Q -- XanaNews 1.19.1.372 - 2016-08-19 12:40:54
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 1:15 PM   in response to: Quentin Correll in response to: Quentin Correll
Quentin wrote:

I have lots of OLD code which use string[]... written LONG before
{$ZEROBASEDSTRINGS} existed. <grumbling sigh>

Well, presumably that old code is not being used in mobile projects, so ZBS
is off and 1-based indexing is the default.

But even in mobile, it is a no-brainer to simply add {$ZEROBASEDSTRINGS OFF}
to any unit that uses the '[]' operator and wants to keep using 1-based indexing.
That is what Indy does.

--
Remy Lebeau (TeamB)
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 3:49 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...

But even in mobile, it is a no-brainer to simply add {$ZEROBASEDSTRINGS OFF}
to any unit that uses the '[]' operator and wants to keep using 1-based indexing.
That is what Indy does.

no it is brainer because if you have few lines of code no problem, but
if you have thousands of lines, and the {$ZEROBASEDSTRINGS OFF} is add
in the middle (maybe it's not your code) then thanks to see at first
view if you are in zero or 1 based string :(
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 5:22 PM   in response to: loki loki in response to: loki loki
loki wrote:

no it is brainer because if you have few lines of code no problem, but
if you have thousands of lines, and the {$ZEROBASEDSTRINGS OFF} is
add in the middle (maybe it's not your code) then thanks to see at first
view if you are in zero or 1 based string :(

{$ZEROBASEDSTRINGS} does not cross unit boundaries. The only way to have
the first half of the unit using one base, and the other half use another
base, is if you explicitly code the unit that way to begin with.

--
Remy Lebeau (TeamB)
Quentin Correll


Posts: 2,412
Registered: 12/1/99
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 22, 2016 10:44 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy,

| Well, presumably that old code is not being used in mobile projects,

And, fortunately, I'm not doing any mobile stuff. <g>

| But even in mobile, it is a no-brainer to simply add
| {$ZEROBASEDSTRINGS OFF} to any unit that uses the '[]' operator and
| wants to keep using 1-based indexing. That is what Indy does.

Good info. Thanks!

--

Q -- XanaNews 1.19.1.372 - 2016-08-22 10:41:51
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 3:47 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
The reason strings are even 1-based at all with is for backwards compatibility
with ShortString, where S[0] is the string length and S[1] is the first character.
When AnsiString was first added, the default string type was changed from
ShortString to AnsiString (unless you disable the {$H} compiler directive),
so existing code that expected 1-based indexing needed to be preserved when
ported to AnsiString. That has carried through the years.

Yes i know that, but do you see how they did in the past time ? *they
keep the compatibility* and that the most important !

Nobody is going to deny that 0-based strings in Delphi is stupid.

But Embarcadero introduced a clear migration path (deprecated the 1-based
RTL functions in favor of the new 0-based record helpers) does not break
existing code. It was very smart. People who WANT 0-based indexing, even
on desktop systems, can do so. People who WANT 1-based indexing, even on
mobile systems, can do so.

no, it's not work ! it's break the code if you move to mobile, except if
you add everywhere the {$zerobasestringoff}
but even nothing will stop to break you head mixing in some code 1 base
string with in other 0 based string. and if you don't see very well the
{$zerobasestringoff} in the thousands of lines of codes, you will have
surelly stupid bug with your s[x] because you will not know if your are
in 1 based or 0 based

at least they can introduce a new way like
S[x] = 1 based string
s[{x}] = 0 base string
not breaking everything

They did introduce a new way, via the new Chars[] property:

uses
  SysUtils; // activate string helper
 
s.Chars[x] // always 0 based on all platforms

that was the best option !!! what the hell touch also the s[x] :(

The "S[x]" syntax is 0-based or 1-based, depending on the {$ZEROBASEDSTRINGS}
directive, which is ON by default for mobile and OFF by default for desktop.
Now THAT was stupid, IMHO, and where the majority of confusion comes into
play.

yes we agree :) :)
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 5:19 PM   in response to: loki loki in response to: loki loki
loki wrote:

Yes i know that, but do you see how they did in the past time ? *they
keep the compatibility* and that the most important !

The jump from ShortString to AnsiString was much simpler than the jump from
AnsiString to UnicodeString. Mainly because ShortString and AnsiString are
both based on AnsiChar. There were fewer things that could break (but there
were still things that could and did break).

no, it's not work ! it's break the code if you move to mobile, except
if you add everywhere the {$zerobasestringoff}

Only for code that:

1) blindly assumed that '[]' was always 1-indexed and did not adjust for
0-indexing.

2) incorrectly passed 0-based indexes to 1-based APIs, or vice versa.

that was the best option !!! what the hell touch also the s[x] :(

Because re-writting code to use s.Chars[x] instead of s[x] takes time and
effort. s[x] had to be changed in the interim.

--
Remy Lebeau (TeamB)
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 20, 2016 9:15 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Am 19.08.2016 um 21:04 schrieb Remy Lebeau (TeamB):


Nobody is going to deny that 0-based strings in Delphi is stupid.

Sorry, but this time you're wrong: folks from EMBT will deny this.
They will claim that 0-based is being used by the majority of things,
neglecting the hughe list we instantly wrote of things using 1-based
indexing, like SQL.

Greetings

Markus
Christian Kaufm...

Posts: 68
Registered: 7/26/98
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 22, 2016 5:01 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
You should stay away from the string "[]" operator, unless you explictiy
set {$ZEROBASEDSTRINGS} to your liking.

Yes. And this is a place where I miss a compiler warning or hint in order to locate all these in my
code.

cu Christian
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 22, 2016 8:26 AM   in response to: Christian Kaufm... in response to: Christian Kaufm...
Am 22.08.2016 um 14:01 schrieb Christian Kaufmann:
You should stay away from the string "[]" operator, unless you explictiy
set {$ZEROBASEDSTRINGS} to your liking.

Yes. And this is a place where I miss a compiler warning or hint in order to locate all these in my
code.

Then file a feature request via quality.embarcadero.com for it so that
we finally get it. Be sure to tell us the number so we can vote and
track it.

Greetings

Markus
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 22, 2016 11:27 AM   in response to: Markus Humm in response to: Markus Humm
Markus wrote:

Then file a feature request via quality.embarcadero.com for it so that
we finally get it. Be sure to tell us the number so we can vote and
track it.

RSP-15692: Add compiler hint when using the string index operator
https://quality.embarcadero.com/browse/RSP-15692

--
Remy Lebeau (TeamB)
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 23, 2016 12:00 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Am 22.08.2016 um 20:27 schrieb Remy Lebeau (TeamB):
Markus wrote:

Then file a feature request via quality.embarcadero.com for it so that
we finally get it. Be sure to tell us the number so we can vote and
track it.

RSP-15692: Add compiler hint when using the string index operator
https://quality.embarcadero.com/browse/RSP-15692

Thanks!

Greetings

Markus
Arthur Hoornweg

Posts: 414
Registered: 6/2/98
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 12:58 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:

RSP-15692: Add compiler hint when using the string index operator
https://quality.embarcadero.com/browse/RSP-15692


BTW, how to get a user account on that server? Thanks.

Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 1:53 AM   in response to: Arthur Hoornweg in response to: Arthur Hoornweg
Arthur Hoornweg wrote:

Remy Lebeau (TeamB) wrote:

RSP-15692: Add compiler hint when using the string index operator
https://quality.embarcadero.com/browse/RSP-15692


BTW, how to get a user account on that server? Thanks.


AFAIK, you can use your EDN account, if you have any.

--
Rudy Velthuis http://www.rvelthuis.de

"The spirit of resistance to government is so valuable on
certain occasions that I wish it to be always kept alive."
-- Thomas Jefferson
Dave Nottage

Posts: 1,850
Registered: 1/7/00
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 2:32 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Rudy Velthuis (TeamB) wrote:

AFAIK, you can use your EDN account, if you have any.

He has to in order to use the newsgroups, which he did to post here :-)

--
Dave Nottage [TeamB]
Hints, tips and tricks at: http://www.delphiworlds.com/blog
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 2:35 PM   in response to: Dave Nottage in response to: Dave Nottage
Dave Nottage wrote:

Rudy Velthuis (TeamB) wrote:

AFAIK, you can use your EDN account, if you have any.

He has to in order to use the newsgroups, which he did to post here
:-)

Ah, indeed.

--
Rudy Velthuis http://www.rvelthuis.de

"If a man does his best, what else is there?"
-- General George S. Patton (1885-1945)
Arthur Hoornweg

Posts: 414
Registered: 6/2/98
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 30, 2016 4:56 AM   in response to: Dave Nottage in response to: Dave Nottage
Dave Nottage wrote:
Rudy Velthuis (TeamB) wrote:

AFAIK, you can use your EDN account, if you have any.

He has to in order to use the newsgroups, which he did to post here :-)


This has puzzled me for some time, but I've just found out that the username/password logic behaves differently on various Embarcadero servers.

The forums.embarcadero.com website accepts both my e-mail address and my user name as credentials.
The quality.embarcadero.com website will only accept my user name, not the e-mail address.

Christian Kaufm...

Posts: 68
Registered: 7/26/98
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 23, 2016 2:26 AM   in response to: Markus Humm in response to: Markus Humm
Then file a feature request via quality.embarcadero.com for it so that
we finally get it. Be sure to tell us the number so we can vote and
track it.

Here you go:
https://quality.embarcadero.com/browse/RSP-15696

cu Christian
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 20, 2016 9:13 AM   in response to: loki loki in response to: loki loki
Am 19.08.2016 um 20:15 schrieb loki loki:
I cant say that I was happy about zero based string indexes, since
Delphi all the time used 1 based string indexes. However I understand
that the rest of the world use zero based indexes, and thus it makes it
slightly "easier" to sell to new users.

but off course it's could be better to have string starting from 0, but
in this way from the beginning !!

You know why the indexing started with being 1-based?

Greetings

Markus
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 20, 2016 12:14 PM   in response to: Markus Humm in response to: Markus Humm

but off course it's could be better to have string starting from 0, but
in this way from the beginning !!

You know why the indexing started with being 1-based?

off course :) s[0] = length of the string in the first variant
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 11:50 AM   in response to: Kim Madsen in response to: Kim Madsen
Kim wrote:

They recognized the problem, and made an option to choose to use 1
or 0 based string indexing...and that didnt improve much in the clarity
of things imo.

It is not that the feature itself didn't improve things. It is that did
it in a not-so-clean way. They forced 0-based by default in half the product
(mobile), and left it 1-based in the other half (desktop), and that caused
a lot of issues when porting code between them.

--
Remy Lebeau (TeamB)
Arthur Hoornweg

Posts: 414
Registered: 6/2/98
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 30, 2016 5:07 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:

It is not that the feature itself didn't improve things. It is that did
it in a not-so-clean way. They forced 0-based by default in half the product
(mobile), and left it 1-based in the other half (desktop), and that caused
a lot of issues when porting code between them.

AFAIK they are 1-based in other Pascal and Object-Pascal dialects. Deviating from that makes code less portable.

Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 20, 2016 9:12 AM   in response to: Kim Madsen in response to: Kim Madsen
Am 19.08.2016 um 17:49 schrieb Kim Madsen:
Den 8/19/2016 kl. 17:38 skrev loki loki:
It's like the difference between dictatorship and democracy. If the dictator is a wise monarch.
Things will develop in the right direction.Otherwise, it will only be in a worse direction.

Then the question is, does embarcadero has really scientist. Is there enough scientific theory to support the decisions they make.

just see the zero base string they introduce and understand that their
is noone serious in this position !

I cant say that I was happy about zero based string indexes, since
Delphi all the time used 1 based string indexes. However I understand
that the rest of the world use zero based indexes, and thus it makes it
slightly "easier" to sell to new users.

No, the rest doesn't 100% use 0-based strings. We determined that back
when they introduced ZBS.

A lot of systems, languages etc. use 1-based string index as well. Most
prominent is most likely SQL.

That they try to make the language easy to get for newbies is good, but
that ZBS is not good.

Greetings

Markus
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 22, 2016 8:11 PM   in response to: Markus Humm in response to: Markus Humm
That they try to make the language easy to get for newbies is good, but
that ZBS is not good.

The most important question is why it is so easy to decide to introduce ZBS.
ZBS and UTF16 and ARC and Lockable Object are all in some situation, That is fundamentally ignore the compatibility, ignoring the existing customer cost.
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 18, 2016 9:35 AM   in response to: wenjie zhou in response to: wenjie zhou
Am 18.08.2016 um 06:41 schrieb wenjie zhou:
Do you realize the amount of effort it takes to maintain two sets of libraries
for those data types? This is even more apparent in C, but at least C++
supports templates so a single implementation can be specialization for char
and wchar_t as needed to reduce overhead of repeated code. But that still
doesn't negate the fact that char and wchar_t are two separate data types,
that need to be handled separately the further down the layers you go.

What you said is try to prove that : There's a better solution. Just because more efforts. So, they choose an easier solution. That is the truth.

Hm that in your perception better solution would have to be paid for
you: it would have to be developed and maintained and tested. in every
release. It would take quite some ressources.

Since most folks are happy enough with the solution of adpting their
code once where necessary (and for most developers the needed changes
were minimal I guess) it would not have been sensible to implement a
"big" solution which would further increase the cost for every developer.


And besides, C++ is controlled by committee, no single compiler can change
the rules (not counting extensions). Everyone has to agree to a change that
effects everyone. That is not the case with Delphi, which is the sole property
of one company that can do whatever it wants with Delphi.

That looks better. Instead of random changes

Commitees do have their issues as well.


Delphi is not C++, so stop comparing them. If you don't like what Embarcadero
did, don't use it.
I don't like what Embarcadero did.

Everybody is allowed to have his opinion...

And i try to speak out.

...and to tell it to us, if the wording used is polite enough.
(I'm not claiming you're impolite yet)

And try to change it.

You can try to, but I guess after reintroducing some 8 bit types on
mobile they won't do much further changes in the directions you like.
What I'd like them to do is to improve those parts of ARC which aren't
too "shiny" yet.

And if all effort had no effect. If the worst things happend(e.g. ARC in Desktop).
I will leave. And don't need you to tell me.

3 years ago. When i talk about some bad things in new Delphi on a forums. Many people do not care.
But now, in the forums, more people is talking about using C# instead of Delphi, or using free pascal.
How many facts do we need to prove some decisions are problematic. Many Embarcadero did is not correct.

Which forums are you referring to (I'm not talking about the 3 years ago
discussions but the current ones)?
And people did care for some of the topics, but as it seems just not in
the way you would like. The solutions you're fond of either cost more
money to maintain as it nearly doubles the number of needed functions
(in case of string handling) or they might make interaction with certain
OS APIs more cumbersome (by not using ARC on mobile).

I wouldn't need ARC either, but I cannot dictate the manufacturers of
those mobile platforms what to do (e.g. to better educate developers
about how proper manual memory management works). But I can understand
that EMBT has to follow to at least a certain extend. Be glad that they
diodn't go down the GC route on Android!

Greetings

Markus
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 18, 2016 7:20 PM   in response to: Markus Humm in response to: Markus Humm

Hm that in your perception better solution would have to be paid for
you: it would have to be developed and maintained and tested. in every
release. It would take quite some ressources.
I don't know what you mean.
If there's a switch. When it opened. Compiler works in the mode as you like current. Do not need you do anything. It just supply one more way for those who need ansi.
They never interfere with yous.

Since most folks are happy enough with the solution of adpting their
code once where necessary (and for most developers the needed changes
were minimal I guess) it would not have been sensible to implement a
"big" solution which would further increase the cost for every developer.
If embarcardero want more users, that's no doubt they should pay the cost.


Commitees do have their issues as well.
At least with compatibility, It's more better. At least when the language features are introduced, they are fully discussed.
Anyone can do stupid things include me. So for Delphi, how to prevent it from doing stupid things?


...and to tell it to us, if the wording used is polite enough.
(I'm not claiming you're impolite yet)
When i am discussing questions but someone says" If you don't like what Embarcadero did, don't use it.".I can't control my mood.
Maybe my english is pool.I can't understand that is a polite act.

And try to change it.

You can try to, but I guess after reintroducing some 8 bit types on
mobile they won't do much further changes in the directions you like.
Our studio use C++ in mobile. We will not use Delphi on mobile. So, i don't care what they do on mobile.

What I'd like them to do is to improve those parts of ARC which aren't
too "shiny" yet.
ARC is a good thing. I love it. But i do not like everything is ARC. If Delphi can support operator overloading. And if we have assignment Operator.
ARC can be implement by you or me. That's the right way. This is the way to make the language more expressive.
Programmers use language to create, not to make.

Which forums are you referring to (I'm not talking about the 3 years ago
discussions but the current ones)?
A forum in china.

And people did care for some of the topics, but as it seems just not in
the way you would like.
That is not only a question about like or not. Most case it is because compatibility issues.
Compatibility with old code. Compatibility with old user data. Compatibility with other system in company or cooperative business.
The broken is a full range. Not the only world in Delphi.

Some people said that the large-scale modularization development of Delphi is less than c++/c. And now the situation is getting more worse.

The solutions you're fond of either cost more
money to maintain as it nearly doubles the number of needed functions
(in case of string handling) or they might make interaction with certain
OS APIs more cumbersome (by not using ARC on mobile).
Sorry, i don't know what does it mean. If it talks about mobile, And i don't care mobile.
Excuse me for my abrupt, Very seldom Enterprises used Delphi for mobile in china.
I think the situation in the United States may also be about. There are many reasons for this.
But the embarcadero has the greatest responsibility. Is there any discussion or analysis of the reasons for this.
Just talk about it and it will be under siege.

I wouldn't need ARC either, but I cannot dictate the manufacturers of
those mobile platforms what to do (e.g. to better educate developers
about how proper manual memory management works). But I can understand
that EMBT has to follow to at least a certain extend. Be glad that they
diodn't go down the GC route on Android!
Though I still think there's a better plan. But I don't want to talk about it.
I had been despair for Mobile Delphi. So, let it be.
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 7:06 AM   in response to: wenjie zhou in response to: wenjie zhou
Am 19.08.2016 um 05:44 schrieb wenjie zhou:

Hm that in your perception better solution would have to be paid for
you: it would have to be developed and maintained and tested. in every
release. It would take quite some ressources.
I don't know what you mean.

I mean that providing two sets of functions etc. means at least doubles
the testing effort required. or would you like to get your ansi stuff
untested? ;-)

If there's a switch. When it opened. Compiler works in the mode as you
like current. Do not need you do anything. It just supply one more
way for those who need ansi. They never interfere with yous.

You still don't 100% get all the implications. What If I supply you some
routine you need which uses strings but I only give you the DCU?

In which mode has it been compiled?


Since most folks are happy enough with the solution of adpting their
code once where necessary (and for most developers the needed changes
were minimal I guess) it would not have been sensible to implement a
"big" solution which would further increase the cost for every developer.
If embarcardero want more users, that's no doubt they should pay the cost.

While as a customer you can ask for this that way the owners quite
likely won't do this, unless not doing this leads to mass exodus of
customers, which doesn't really seem to be the case (no, you don't have
the numbers either!)



Commitees do have their issues as well.
At least with compatibility, It's more better. At least when the language
features are introduced, they are fully discussed.

I doubt this. And some things take longer. See Java.

Anyone can do stupid things include me. So for Delphi, how to prevent it from doing stupid things?

Well said and a good question. I fear there's no universal answer
available to that one. :-(


What I'd like them to do is to improve those parts of ARC which aren't
too "shiny" yet.
ARC is a good thing. I love it. But i do not like everything is ARC. If Delphi can support operator overloading. And if we have assignment Operator.
ARC can be implement by you or me. That's the right way. This is the way to make the language more expressive.
Programmers use language to create, not to make.

Greetings

Markus
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 22, 2016 8:25 PM   in response to: Markus Humm in response to: Markus Humm
You still don't 100% get all the implications. What If I supply you some
routine you need which uses strings but I only give you the DCU?

In which mode has it been compiled?

DCUs may have a flag to specify it is ansi or utf16. Compiler can detect the flag, and can give warning or fatal information.
We need defination in xxxx.pas to introduce DCUs. And we can give a another local compiler directives to specify the the ansi or utf16 in DCUs.
And of course , if current projects's directive is not same with the local compiler. The converting will happen.

While as a customer you can ask for this that way the owners quite
likely won't do this, unless not doing this leads to mass exodus of
customers, which doesn't really seem to be the case (no, you don't have
the numbers either!)
This efforts is to make the best possible to ensure that the existing polite migration . It means money for them.
No one knows how many new customers they can bring in these new features. I think they are too shy to talk about it. Because they was failed on this.


Well said and a good question. I fear there's no universal answer
available to that one. :-(
Things have happened. ZBS :)
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 7:53 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
And besides, C++ is controlled by committee, no single compiler can change
the rules (not counting extensions). Everyone has to agree to a change that
effects everyone. That is not the case with Delphi, which is the sole property
of one company that can do whatever it wants with Delphi.

that the big problem

Delphi is not C++, so stop comparing them. If you don't like what Embarcadero
did, don't use it.

i don't like ! and it's stupid to say don't use it when all you code is
already on it, like if we have choice !!!
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 7:49 AM   in response to: wenjie zhou in response to: wenjie zhou
But whatever it is. Look c++, supply char* and w_char*. Select by yourself and do whatever you want. Mans do not need chang any thing, no matter how earlier USC-2 in windows.

exactly what i try to say!! that was the good way to do !


The truth is more obvious. Delphi sacrifice us for those who want get UnicodeString automatically. They force us to chang my code for a function that I don't need .

exactly :(
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 6:19 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
It minimizes code changes for everyone.
No, if AnsiString and the routines is still there. I just set String equal AnsiString. I do not need chang anything.
So, do not says it "It minimizes code changes for everyone. ". At least, not for me.

You can say that you don't need Unicode, but Windows supports UTF-16 since
Windows 2000. That was 16-years ago.
How the operating system handles the string is not directly related to my code .
If utf16 as the only default string type is because of the operating system use it.
And now days, delphi's target is cross platform. If Linux use utf8. How do you select the default string type for Delphi?

And since having compiler switch is not possible it had to be introduced for all, whether you like it or not.
Why it is not possible?
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 6:57 PM   in response to: wenjie zhou in response to: wenjie zhou
wenjie wrote:

So, do not says it "It minimizes code changes for everyone. ".
At least, not for me.

Because you were doing things with AnsiString that you should not have
been doing in the first place, and which did not translate to Unicode. Just
because your code "broke" does not mean the change was bad in generral.
It means it caught mistakes you were making in the first place.

How do you select the default string type for Delphi?

You can't, nor should you be trying to. And that certainly does not promote
cross-platform coding, where the same code compiles the same for multiple
platforms.

Why it is not possible?

That has already been explained many times.

--
Remy Lebeau (TeamB)
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 17, 2016 8:47 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Because you were doing things with AnsiString that you should not have
been doing in the first place, and which did not translate to Unicode.
Yes, but it is truth.

Just because your code "broke" does not mean the change was bad in generral.
It means it caught mistakes you were making in the first place.

With string type switch. *me"(Those who don't care UnicodeString) can not chang any code. "you"(Those who care UnicodeString) can do things like now.
This is the best solution for all of us.

How do you select the default string type for Delphi?

You can't, nor should you be trying to. And that certainly does not promote
cross-platform coding, where the same code compiles the same for multiple
platforms.

Why Delphi choose UTF16 as default? Some of you told me: it is because Windows use UTF16.
And can we say, For Linux, The default should be UTF8 because Linux use UTF8.
Programmers need to be rigorous. Why standard random change.

Why it is not possible?

That has already been explained many times.
No, We have not reached a consensus. You dont't explain it.
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 18, 2016 9:42 AM   in response to: wenjie zhou in response to: wenjie zhou
Am 18.08.2016 um 05:47 schrieb wenjie zhou:
Because you were doing things with AnsiString that you should not have
been doing in the first place, and which did not translate to Unicode.

Yes, but it is truth.

And? I also did some such things in certain parts of certain apps. Did I
complain? No. I didn't change them yet as I lack the time to do the more
general overhaul these parts should get, but as of now I can still life
with it.


Just because your code "broke" does not mean the change was bad in generral.
It means it caught mistakes you were making in the first place.

With string type switch. *me"(Those who don't care UnicodeString) can not chang any code. "you"(Those who care UnicodeString) can do things like now.
This is the best solution for all of us.

We know what could be done with such a switch, but we also know that a
mess can be created. WHat if somebody uses some external units written
by others? And to add to it: what if those are only avaliable in DCU
format and not in source? What does the switch do there?


How do you select the default string type for Delphi?

You can't, nor should you be trying to. And that certainly does not promote
cross-platform coding, where the same code compiles the same for multiple
platforms.

Why Delphi choose UTF16 as default? Some of you told me: it is because Windows use UTF16.
And can we say, For Linux, The default should be UTF8 because Linux use UTF8.
Programmers need to be rigorous. Why standard random change.

Hm? From the major operating systems it currently looks like only Linux
is using UTF8 for its API. So it's in the minority.


Why it is not possible?

That has already been explained many times.
No, We have not reached a consensus. You dont't explain it.

Ok then I'll explain it: it would cost too much to develop and maintain
(something you would have to pay for!) and it would create all sorts of
issues (look at the food for thought I gave you a few paragraphs above).
Delphi is no open source or charity project unfortunately. :-(

Greetings

Markus
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 18, 2016 7:45 PM   in response to: Markus Humm in response to: Markus Humm

Yes, but it is truth.

And? I also did some such things in certain parts of certain apps. Did I
complain? No. I didn't change them yet as I lack the time to do the more
general overhaul these parts should get, but as of now I can still life
with it.

That is not complain. This is a kind of effort to try to make Delphi better.
If there is only allowed to sing the praises , that I was indeed a heterogeneous.


With string type switch. *me"(Those who don't care UnicodeString) can not chang any code. "you"(Those who care UnicodeString) can do things like now.
This is the best solution for all of us.

We know what could be done with such a switch, but we also know that a
mess can be created. WHat if somebody uses some external units written
by others? And to add to it: what if those are only avaliable in DCU
format and not in source? What does the switch do there?
Set a flag in DCUs. the flags mean it is Ansi version or UTF16 version.
When link the DCUs. Give out fatal report when the flag is not same as current setting.

I believe that there are a lot of people who can find a solution better than I do.

If you try to work hard in this direction, there will be a lot of ways.
The most terrible is that has not yet begun to think that can not.


Hm? From the major operating systems it currently looks like only Linux
is using UTF8 for its API. So it's in the minority.

If Windows11, 12 use UTF8. Then Delphi Compiler set default string type to UTF8 again?
Just have a look for two solutions. Which is better adaptability is very clear.


Why it is not possible?

That has already been explained many times.
No, We have not reached a consensus. You dont't explain it.

Ok then I'll explain it: it would cost too much to develop and maintain
(something you would have to pay for!)
It not means "not possible".

and it would create all sorts of
issues (look at the food for thought I gave you a few paragraphs above).
On above. I had give out a solution.

Delphi is no open source or charity project unfortunately. :-(
In my opinion, Delphi IDE is the most valuable thing but not Delphi compiler.
If IDE can open source. I think there will be a lot of people who transform it into working with free pascal.
Jon Robertson

Posts: 254
Registered: 9/22/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 22, 2016 6:06 PM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:
How the operating system handles the string is not directly related to my code .

Really? Do you only write services? If you have strings that are provided to the operating system, such as captions, labels, or output to a console, then I beg to differ.

I, on the other hand, don't care how the operating system handles my strings. That is because I'm using a development tool that is smart enough to use the same character encoding as the operating system, so I don't have to care. Unless I'm doing something with strings aside from storing strings or I actually need to handle character data encoded in multiple ways, such as interfacing with another product or service that uses a different encoding.

Jon
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 23, 2016 1:19 AM   in response to: Jon Robertson in response to: Jon Robertson
Jon Robertson wrote:
wenjie zhou wrote:
How the operating system handles the string is not directly related to my code .

Really? Do you only write services? If you have strings that are provided to the operating system, such as captions, labels, or output to a console, then I beg to differ.

I, on the other hand, don't care how the operating system handles my strings. That is because I'm using a development tool that is smart enough to use the same character encoding as the operating system, so I don't have to care. Unless I'm doing something with strings aside from storing strings or I actually need to handle character data encoded in multiple ways, such as interfacing with another product or service that uses a different encoding.

Jon

I mean most time string was processed in our inner logic.

As you said, When you need to interact with the system you will care the OS API and care what string type they need.And on the other hand.
We not only need OS API. But we also may need other SDK and other API. Those modules may not have same string type with OS.
So, the inner used string type is not necessarily required to match the OS. As you mentioned, services may not need match the OS string type.

The right to choose string type should be given to the programmer but not the compiler. Of course you can choose the string type matched the OS. That's the freedom.
That is what i want to say.
Jon Robertson

Posts: 254
Registered: 9/22/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 23, 2016 4:07 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:
The right to choose string type should be given to the programmer but not the compiler. Of course you can choose the string type matched the OS. That's the freedom.
That is what i want to say.

I agree with you 100%. As I believe everyone else does.

The difference is that we acknowledge that Delphi already allows us to do exactly that. We can code with whatever "type" of string we want to. Heck, you could write your code in such a way that all strings were stored in some weird multi-dimensional byte array.

It really doesn't matter how your code handles strings (as long as your team can maintain the code). What matters is how the string is stored when you pass it along to something else, whether that is the OS, a TCP/IP socket, or any other interface.

Delphi gives us the flexibility to do just that. Feel free to handle strings however you'd like. Create your own string data type for that matter.

You've been using Delphi a long time and seem to be fairly knowledgable. Why isn't the flexibility already provided by the language enough for you? And why do you want to impose changes that would significantly complicate the RTL, VCL, FireMokey, and anything else that uses *String*? I certainly don't want Embarcadero or anyone else to implement what you're suggesting.

Jon

Jon
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 25, 2016 8:26 PM   in response to: Jon Robertson in response to: Jon Robertson
The difference is that we acknowledge that Delphi already allows us to do exactly that. We can code with whatever "type" of string we want to. Heck, you could write your code in such a way that all strings were stored in some weird multi-dimensional byte array.

It really doesn't matter how your code handles strings (as long as your team can maintain the code). What matters is how the string is stored when you pass it along to something else, whether that is the OS, a TCP/IP socket, or any other interface.

Delphi gives us the flexibility to do just that. Feel free to handle strings however you'd like. Create your own string data type for that matter.

You've been using Delphi a long time and seem to be fairly knowledgable. Why isn't the flexibility already provided by the language enough for you? And why do you want to impose changes that would significantly complicate the RTL, VCL, FireMokey, and anything else that uses *String*?

I'm here to discuss the bad things in my opinion. Not noly for String.
As you mentioned. I can do TAnsiStringList and other AnsiString routine by myself.(And in fact, i do really finished the job.)
This can only to solve my personal problems. As you see, just for here, not only me need such things.

For String. If Embarcadero do give an option to switch. And set defualt switch is "UTF16". All your work is fully same as current.
Why you don't like it? There is no reason for this.
But, the fact is Embarcadero do not give the chooice.

I even try to change RTL, and rebuild RTL, VCL just for erasing RTTI to get a set of DCUs without RTTI.
RTTI is also has a better solution for programers to choose link it or not. It's a easy work to make *.exe more smaller and more safe.
Embarcadero do not give an option to remove RTTI.

Lockable object also has problem. In new compiler, all objects has a hide field to store lock flag. Assume your application is not a multithread application.
And your application has a plenty of little objects. The hide field will consume a large amount of memory.
And again. Embarcadero do not give the chooice, do not give a switch to let programer to judge which class or object can be lockable.

And then. It's ARC. Also the same situation. If ARC-Enabled. And then you have no chooice.

All the key things have to be decided by the compiler and no chooice. These Delphi's practices is going to kill the creative ability of programers.Delphi is not a script.

It's really not only one thing is not good.
Please think carefully for Living Binding.Is it really large use in practical engineering.
If you want to bind fewer properties, it seemed beautiful. If there's a large number of properties, using Living Binding will be a disaster for extremely slow running speed.

Think about FMX for self drawing. 6-7 years had past. And now, they had introduce the native controls.

All above proved that they do some flashy without substance things. That's a serious problem not for features but for their attitude.

I certainly don't want Embarcadero or anyone else to implement what you're suggesting.
All your work is fully same as current. Why you don't like it? There is no reason for this.
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 26, 2016 12:28 AM   in response to: wenjie zhou in response to: wenjie zhou
Am 26.08.2016 um 05:30 schrieb wenjie zhou:
The difference is that we acknowledge that Delphi already allows us to do exactly that. We can code with whatever "type" of string we want to. Heck, you could write your code in such a way that all strings were stored in some weird multi-dimensional byte array.

It really doesn't matter how your code handles strings (as long as your team can maintain the code). What matters is how the string is stored when you pass it along to something else, whether that is the OS, a TCP/IP socket, or any other interface.

Delphi gives us the flexibility to do just that. Feel free to handle strings however you'd like. Create your own string data type for that matter.

You've been using Delphi a long time and seem to be fairly knowledgable. Why isn't the flexibility already provided by the language enough for you? And why do you want to impose changes that would significantly complicate the RTL, VCL, FireMokey, and anything else that uses *String*?

I'm here to discuss the bad things in my opinion. Not noly for String.
As you mentioned. I can do TAnsiStringList and other AnsiString routine by myself.(And in fact, i do really finished the job.)
This can only to solve my personal problems. As you see, just for here, not only me need such things.

For String. If Embarcadero do give an option to switch. And set defualt switch is "UTF16". All your work is fully same as current.
Why you don't like it? There is no reason for this.

There definitely is: it would make the product even more expensive as
they would factor the work required for this into the product price and
it may introduce further bugs. They will do this, even if you insist
that the cost is theirs. They have to stay afloat and they're no charity
organization.

Lockable object also has problem. In new compiler, all objects has a hide field to store lock flag. Assume your application is not a multithread application.
And your application has a plenty of little objects. The hide field will consume a large amount of memory.
And again. Embarcadero do not give the chooice, do not give a switch to let programer to judge which class or object can be lockable.

And then. It's ARC. Also the same situation. If ARC-Enabled. And then you have no chooice.

In case of ARC the providing of a non-ARC enabled base class would be
good in my eyes and much easier and cheaper to implement and maintain
than the string type switch you want.

Greetings

Markus
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 26, 2016 1:22 AM   in response to: Markus Humm in response to: Markus Humm

There definitely is: it would make the product even more expensive as
they would factor the work required for this into the product price and
it may introduce further bugs. They will do this, even if you insist
that the cost is theirs. They have to stay afloat and they're no charity
organization.

:)

In case of ARC the providing of a non-ARC enabled base class would be
good in my eyes and much easier and cheaper to implement and maintain
than the string type switch you want.

:)
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 26, 2016 12:28 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

For String. If Embarcadero do give an option to switch.

Won't happen because it doesn't make sense. This has been discussed
already, ad nauseam, when D2009 came out. No need to rehash that once
again.

Again: THERE WILL BE NO SWITCH. This has been made VERY clear at that
time. And they did everything they could to take care no one would need
a switch.

Well, except those who were so foolish never to correct their hacks
made many many years before. These people had problems, but hey,
nothing that could be prevented by the Delphi development team.
--
Rudy Velthuis http://www.rvelthuis.de

"How good bad music and bad reasons sound when we march against
an enemy!"
-- Nietzsche
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 26, 2016 12:57 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
For String. If Embarcadero do give an option to switch.

Won't happen because it doesn't make sense. This has been discussed
already, ad nauseam, when D2009 came out. No need to rehash that once
again.

:) Angry? Is it necessary for the discuss.
Your anger comes from you don't have enough reason to convince others.

Have a look for ZBS;
ZBS come out before. And then it changed and been add a switch.

Have a look for FMX
FMX has no native controls in mang prev version. They think they can do everything.
However, after a number of versions, they had to introduce native controls. But 6 years had wasted. The price is too high.

Some things are so wrong so that they had to change. But some of things is not obvious. So they can continue to go beyond the wrong path.

Again: THERE WILL BE NO SWITCH. This has been made VERY clear at that
time. And they did everything they could to take care no one would need
a switch.
It seemd you are not the product manager. And, you are even not an employee in embarcadero.
Even if we all know there's a very small possibility. It is not suitable for you to says THERE WILL BE NO SWITCH.
You don't have the right. Just like others in this forums.

Well, except those who were so foolish never to correct their hacks
made many many years before. These people had problems, but hey,
nothing that could be prevented by the Delphi development team.
Nobody prevent them. They can do everything. Does anybody prevent the Delphi development team to introduce ZBS, ARC?
Obviously, you are more care for we are talking it is not good but not is it really not good.

I will support the opinion i think it is the right one unless you close this forum or ban my account. I am doing the right thing just like you think you are the right one.
Jim Fleming

Posts: 113
Registered: 2/12/00
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 26, 2016 7:06 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

For String. If Embarcadero do give an option to switch.

Won't happen because it doesn't make sense. This has been discussed
already, ad nauseam, when D2009 came out. No need to rehash that
once again.

:) Angry? Is it necessary for the discuss.
Your anger comes from you don't have enough reason to convince
others.

Have a look for ZBS;
ZBS come out before. And then it changed and been add a switch.

Have a look for FMX
FMX has no native controls in mang prev version. They think they can
do everything. However, after a number of versions, they had to
introduce native controls. But 6 years had wasted. The price is too
high.

Some things are so wrong so that they had to change. But some of
things is not obvious. So they can continue to go beyond the wrong
path.

Again: THERE WILL BE NO SWITCH. This has been made VERY clear at
that time. And they did everything they could to take care no one
would need a switch.
It seemd you are not the product manager. And, you are even not an
employee in embarcadero. Even if we all know there's a very small
possibility. It is not suitable for you to says *THERE WILL BE NO
SWITCH*. You don't have the right. Just like others in this forums.

Well, except those who were so foolish never to correct their hacks
made many many years before. These people had problems, but hey,
nothing that could be prevented by the Delphi development team.
Nobody prevent them. They can do everything. Does anybody prevent
the Delphi development team to introduce ZBS, ARC? Obviously, you
are more care for we are talking it is not good but not *is it
really not good*.

I will support the opinion i think it is the right one unless you
close this forum or ban my account. I am doing the right thing just
like you think you are the right one.

No, wenjie, it is not anger at what you think -- it is a reaction to
your stubborn insistence on something that is not technically nor
economically feasible. Live with it, life's like that.

If at some time in the past you or your organisation made a wrong
technical decision about some fundamental aspect of your application(s)
and now must bite the bullet to undo that error, please don't try to
get all of us to suffer economically so that you can solve your problem
easily and cheaply. Make the changes you need to make, evolve your
application(s), but do so with a well-thought-out plan, possibly with
several phases over a number of years. All is not lost if you just roll
up your sleeves and think a bit before jumping on the easiest route
forward (for you).

--
JF
Jon Robertson

Posts: 254
Registered: 9/22/99
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 26, 2016 9:25 AM   in response to: Jim Fleming in response to: Jim Fleming
Jim Fleming wrote:
No, wenjie, it is not anger at what you think -- it is a reaction to
your stubborn insistence on something that is not technically nor
economically feasible. Live with it, life's like that.

+Infinity (there isn't a number high enough to express my agreement with that response)

Frankly, I would have switched to another toolcain long ago if I was that unhappy with Delphi.

Jon
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 28, 2016 6:50 PM   in response to: Jim Fleming in response to: Jim Fleming
No, wenjie, it is not anger at what you think -- it is a reaction to
your stubborn insistence on something that is not technically nor
economically feasible. Live with it, life's like that.

On the contrary. Not me, it's just your stubborn lead problem.
I have repeatedly referred to, so that all people can have their own choice.
Nobody have enough reason to say what is batter.And the better choice is allow users to choose their own.
Just you, Stubbornly think that only one thing is right. I use UTF16 in some new projects. I use full RTTI in my data analysis tools. I like all of them. And i live with it no problem.
All these should not be a War. Should not be a battle to kill old things.

If at some time in the past you or your organisation made a wrong
technical decision about some fundamental aspect of your application(s)
and now must bite the bullet to undo that error, please don't try to
get all of us to suffer economically so that you can solve your problem
easily and cheaply. Make the changes you need to make, evolve your
application(s), but do so with a well-thought-out plan, possibly with
several phases over a number of years. All is not lost if you just roll
up your sleeves and think a bit before jumping on the easiest route
forward (for you).

Unfortunately, In my opinion, Old Delphi didn't make wrong technical decision.
Old Delphi do make the decisions are more sensible than it is now.
Just for new Delphi, it makes many wrong technical decision. Some of it is very serious. The more serious problem is, they do not recognize this point.
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Product Roadmap August 2016 [Edit] [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 12:16 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

No, wenjie, it is not anger at what you think -- it is a reaction to
your stubborn insistence on something that is not technically nor
economically feasible. Live with it, life's like that.

On the contrary. Not me, it's just your stubborn lead problem.

No, it is you who is stubbornly trying to discuss something that has
been discussed at length before and which clearly and definitely showed
that there will never be a switch. Keeping on discussing it is nonsense.

--
Rudy Velthuis http://www.rvelthuis.de

"Sex is like air. It's only a big deal if you can't get any."
-- Unknown
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016 [Edit] [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 2:12 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...

No, it is you who is stubbornly trying to discuss something that has
been discussed at length before and which clearly and definitely showed
that there will never be a switch.

I will not deny that I want to discuss something. And now, i am happy that i can find more people who are on the same wavelength.
If only me have the this thought. I may shut up early. Indeed, i was not the first people who talk about those things in this post. I just support them.

Keeping on discussing it is nonsense.
I think the discuss is important to let things more better. I'm doing right things. I'm try to explain what is better.
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Product Roadmap August 2016 [Edit] [Edit] [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 2:38 PM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:


No, it is you who is stubbornly trying to discuss something that has
been discussed at length before and which clearly and definitely
showed that there will never be a switch.

I will not deny that I want to discuss something.

Everyone knows, by now, that you /want/ to discuss it. But there is
nothing to discuss. The decision has been made years ago and that won't
be changed.

So it makes no sense to persist in wanting to discuss it. You could
just as well discuss gravity and ask it be changed.

--
Rudy Velthuis http://www.rvelthuis.de

"Smoking is one of the leading causes of statistics."
-- Fletcher Knebel
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016 [Edit] [Edit] [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 30, 2016 10:13 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 29.08.2016 um 23:38 schrieb Rudy Velthuis (TeamB):
wenjie zhou wrote:


No, it is you who is stubbornly trying to discuss something that has
been discussed at length before and which clearly and definitely
showed that there will never be a switch.

I will not deny that I want to discuss something.

Everyone knows, by now, that you /want/ to discuss it. But there is
nothing to discuss. The decision has been made years ago and that won't
be changed.

So it makes no sense to persist in wanting to discuss it. You could
just as well discuss gravity and ask it be changed.

And even discussing it here in the group will not reach relevant EMBNT
personel anyway as they mostly don't read this group.

Greetings

Markus
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 1:09 PM   in response to: wenjie zhou in response to: wenjie zhou
Am 29.08.2016 um 04:09 schrieb wenjie zhou:
No, wenjie, it is not anger at what you think -- it is a reaction to
your stubborn insistence on something that is not technically nor
economically feasible. Live with it, life's like that.

On the contrary. Not me, it's just your stubborn lead problem.
I have repeatedly referred to, so that all people can have their own choice.
Nobody have enough reason to say what is batter. And the better choice is allow
users to choose their own.

In a perfect world you'd be right, but since providing all these options
costs money and you already stated somewhere that you wouldn't pay more
for this it will not be done. It complicates the product as well.

If some customer asked you to implement some costly/complicated feature
in your product but wouldn't want to pay extra for it, would you not try
to get by without implementing that?

Greetings

Markus
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 3:04 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 29.08.2016 um 04:09 schrieb wenjie zhou:
No, wenjie, it is not anger at what you think -- it is a reaction
to >> your stubborn insistence on something that is not technically
nor >> economically feasible. Live with it, life's like that.

On the contrary. Not me, it's just your stubborn lead problem.
I have repeatedly referred to, so that all people can have their
own choice. Nobody have enough reason to say what is batter. And
the better choice is allow users to choose their own.

In a perfect world you'd be right

No, I disagree. It is not always good or necessary to have a choice.
Sometimes being forced to do something (e.g. to port your code to be
Unicode compatible, or to clean your room, or to eat your vegetables,
or get your finances in order) is a Good Thing(tm).

--
Rudy Velthuis http://www.rvelthuis.de

"It has become appallingly obvious that our technology has
exceeded our humanity."
-- Albert Einstein
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 30, 2016 10:14 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Am 30.08.2016 um 00:04 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:

Am 29.08.2016 um 04:09 schrieb wenjie zhou:
No, wenjie, it is not anger at what you think -- it is a reaction
to >> your stubborn insistence on something that is not technically
nor >> economically feasible. Live with it, life's like that.

On the contrary. Not me, it's just your stubborn lead problem.
I have repeatedly referred to, so that all people can have their
own choice. Nobody have enough reason to say what is batter. And
the better choice is allow users to choose their own.

In a perfect world you'd be right

No, I disagree. It is not always good or necessary to have a choice.
Sometimes being forced to do something (e.g. to port your code to be
Unicode compatible, or to clean your room, or to eat your vegetables,
or get your finances in order) is a Good Thing(tm).

You can speak that way as you don't depend on such code. In most
companies you normally don't get much time for such things so you need
to avoid those. Thats reality as bad as it is.

Greetings

Markus
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 31, 2016 7:48 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 30.08.2016 um 00:04 schrieb Rudy Velthuis (TeamB):
Markus Humm wrote:

Am 29.08.2016 um 04:09 schrieb wenjie zhou:
No, wenjie, it is not anger at what you think -- it is a reaction
to >> your stubborn insistence on something that is not technically
nor >> economically feasible. Live with it, life's like that.

On the contrary. Not me, it's just your stubborn lead problem.
I have repeatedly referred to, so that all people can have their
own choice. Nobody have enough reason to say what is batter. And
the better choice is allow users to choose their own.

In a perfect world you'd be right

No, I disagree. It is not always good or necessary to have a choice.
Sometimes being forced to do something (e.g. to port your code to be
Unicode compatible, or to clean your room, or to eat your
vegetables, or get your finances in order) is a Good Thing(tm).

You can speak that way as you don't depend on such code.

I try to keep dependencies very low, indeed. But still, it is not
always good to have a choice.

--
Rudy Velthuis http://www.rvelthuis.de

"The trouble with the Internet is that it's replacing
masturbation as a leisure activity." -- Patrick Murray.
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 26, 2016 11:00 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie wrote:

Have a look for ZBS;
ZBS come out before. And then it changed and been add a switch.

ZBS is localized to individual lines of code, and can be toggled multiple
times within the same unit. So a local switch makes sense. Adding a switch
to change the default string type doesn't make sense.

--
Remy Lebeau (TeamB)
Jacinto Franca

Posts: 10
Registered: 10/15/00
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 26, 2016 1:28 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
El 8/26/2016 7:00 PM, Remy Lebeau (TeamB) escribió:
wenjie wrote:

Have a look for ZBS;
ZBS come out before. And then it changed and been add a switch.

ZBS is localized to individual lines of code, and can be toggled multiple
times within the same unit. So a local switch makes sense. Adding a switch
to change the default string type doesn't make sense.

That switch was already available in Delphi < 2009.
{$LONGSTRINGS ON}

It just replaced String with ShortString or AnsiString.

It could have been extended with a {$LONGSTRINGS ANSI} option.
The default must have been:
{$LONGSTRINGS ON} where String = UnicodeString,
{$LONGSTRINGS OFF} must stay the same String = ShortString,
{$LONGSTRINGS ANSI} must replace String = AnsiString.

The dcus themselves must keep only the real type, not string.
Put the wrong one in a Form Unit and it will show incompatible types
when you override a function:
[Error] MyUnit.pas(xxx): Declaration of 'FunctionName' differs from
previous declaration.
the same that old Delphi did with {$LONGSTRINGS OFF}
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 28, 2016 7:14 PM   in response to: Jacinto Franca in response to: Jacinto Franca
Jacinto Franca wrote:
El 8/26/2016 7:00 PM, Remy Lebeau (TeamB) escribió:
wenjie wrote:

Have a look for ZBS;
ZBS come out before. And then it changed and been add a switch.

ZBS is localized to individual lines of code, and can be toggled multiple
times within the same unit. So a local switch makes sense. Adding a switch
to change the default string type doesn't make sense.

That switch was already available in Delphi < 2009.
{$LONGSTRINGS ON}

It just replaced String with ShortString or AnsiString.

It could have been extended with a {$LONGSTRINGS ANSI} option.
The default must have been:
{$LONGSTRINGS ON} where String = UnicodeString,
{$LONGSTRINGS OFF} must stay the same String = ShortString,
{$LONGSTRINGS ANSI} must replace String = AnsiString.

The dcus themselves must keep only the real type, not string.
Put the wrong one in a Form Unit and it will show incompatible types
when you override a function:
[Error] MyUnit.pas(xxx): Declaration of 'FunctionName' differs from
previous declaration.
the same that old Delphi did with {$LONGSTRINGS OFF}

But, now it is been removed:

Note: The LONGSTRINGS directive is obsolete and is ignored by the compiler. Current Delphi compilers use a long string type based on Unicode characters (UnicodeString). It is recommended that you use the default string type (UnicodeString). If you want to use the older string type, explicitly use the ShortString or string[<number>] types where needed.
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 28, 2016 1:14 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:

wenjie wrote:

Have a look for ZBS;
ZBS come out before. And then it changed and been add a switch.

ZBS is localized to individual lines of code, and can be toggled
multiple times within the same unit. So a local switch makes sense.
Adding a switch to change the default string type doesn't make sense.

Also note that ZBS do not change the strings, they only change the
index with which the first item is accessed, in some circumstances. The
string is the same all the time. The same string can be accessed
with a different index base in another piece of code.

--
Rudy Velthuis http://www.rvelthuis.de

"If absolute power corrupts absolutely, where does that leave
God?" -- George Deacon.
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 28, 2016 1:11 PM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

For String. If Embarcadero do give an option to switch.

Won't happen because it doesn't make sense. This has been discussed
already, ad nauseam, when D2009 came out. No need to rehash that
once again.

:) Angry? Is it necessary for the discuss.

Who is angry?

I am merely telling you that you won't get a switch and that the
reasons for this have been discussed long and extensively.

So your "If Embarcadero do give an option to switch" won't ever happen.
There is no need to discuss this once again.

--
Rudy Velthuis http://www.rvelthuis.de

"Early to rise, Early to bed, Makes a man healthy but socially
dead." -- The Warner Brothers (Animaniacs)
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 28, 2016 7:21 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
Who is angry?

I am merely telling you that you won't get a switch and that the
reasons for this have been discussed long and extensively.

So your "If Embarcadero do give an option to switch" won't ever happen.
There is no need to discuss this once again.
If you think there's no need to talk about it. I respect your choice.
And i wish you respect my choice. If you don't like what i said, just ignore it.
Not matter you like or not, I will discuss it again and again. Till something changed or me had changed.
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 12:12 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

Who is angry?

I am merely telling you that you won't get a switch and that the
reasons for this have been discussed long and extensively.

So your "If Embarcadero do give an option to switch" won't ever
happen. There is no need to discuss this once again.
If you think there's no need to talk about it. I respect your choice.

There is no /*use*/ talking about it. It will not change, that is for
sure. Your stubborn insistence to still talk about it won't change that
and therefore makes no sense.

Again: there is no switch and there will be no switch.
CodeGear/Embarcadero have been very clear about that.

I hope you finally understand that. You can try to discuss this, but it
is a futile attempt.

--
Rudy Velthuis http://www.rvelthuis.de

"Translate 'Allah'."
-- Bumper Sticker
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 2:18 AM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...

I hope you finally understand that. You can try to discuss this, but it
is a futile attempt.

Thanks. I do not need understand that. Everything will happen, who knows. Nobody knows that Allen will leave.
Maybe i buy Delphi and do what i want. :) A joke.
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 1:12 PM   in response to: wenjie zhou in response to: wenjie zhou
Am 29.08.2016 um 11:18 schrieb wenjie zhou:

I hope you finally understand that. You can try to discuss this, but it
is a futile attempt.

Thanks. I do not need understand that. Everything will happen, who knows. Nobody knows that Allen will leave.
Maybe i buy Delphi and do what i want. :)

Then you could implement that switch. But you would most likely be
surprised how much this would cost and what you have overlooked but
which needs to be taken care of. ;-)

But: you need the necessary pocket money first, then we can talk again ;-)

Greetings

Markus
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 3:04 PM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:

Am 29.08.2016 um 11:18 schrieb wenjie zhou:

I hope you finally understand that. You can try to discuss this,
but it >> is a futile attempt.

Thanks. I do not need understand that. Everything will happen, who
knows. Nobody knows that Allen will leave. Maybe i buy Delphi and
do what i want. :)

Then you could implement that switch.

Obviously he is oblivious to the implications. If he were, he wouldn't
ask and even if he owned Embarcadero, he wouldn't implement it.
--
Rudy Velthuis http://www.rvelthuis.de

"I'm not going to have some reporters pawing through our papers.
We are the president." -- Hillary Clinton.
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016 [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 29, 2016 5:44 PM   in response to: Rudy Velthuis (... in response to: Rudy Velthuis (...
:) Mabey i can't. Mabey someone else can do. Nothing is impossible.
Dave Nottage

Posts: 1,850
Registered: 1/7/00
Re: Product Roadmap August 2016 [Edit] [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 30, 2016 1:43 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

Nothing is impossible.

I agree. Some things just take longer ;-)

--
Dave Nottage [TeamB]
Hints, tips and tricks at: http://www.delphiworlds.com/blog
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Product Roadmap August 2016 [Edit] [Edit] [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 31, 2016 7:49 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

:) Mabey i can't. Mabey someone else can do. Nothing is impossible.

Yeah, for Toyota. But in real life, some things will simply never
happen.

--
Rudy Velthuis http://www.rvelthuis.de

"The purpose of law is to prevent the strong from always having
their way."
-- Ovid
Paul Scott

Posts: 33
Registered: 10/27/01
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 18, 2016 12:41 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija,

Dalija Prasnikar wrote:

wenjie zhou wrote:
Dalija Prasnikar wrote:
Remy Lebeau (TeamB) wrote:
loki wrote:

exactly, the good way was to introduce utf16 with a new naming
convention

Which would have required users to make much more code changes
than they had to. The whole point of the way the Unicode
migration was implemented was to minimize code changes, not add
to them. Was it a perfect migration? No. Was it an adequate
migration? Yes, for the majority of users. Of course, there
are always exceptions to every rule, and clearly your code is
one of them. MOST users were not badly affected.

Exactly.

This minimize code changes just for you need new
feature(UnicodeString). If you do not need UnicodeString. And let
the code work as old days. There is no doubt that you need to do
more.

It minimizes code changes for everyone.

You can say that you don't need Unicode, but Windows supports UTF-16
since Windows 2000. That was 16-years ago.

Delphi had to introduce Unicode. And since having compiler switch is
not possible it had to be introduced for all, whether you like it or
not.

Sorry. IMNSHO "minimise-changes-to-take-advantage-of-Unicode" was
completely the wrong approach to take.

The prime, overriding objective of /any/ program change should always
be "preservation-of-user-data-and-program-behaviour".

In this case, Borland's "user-data" was our program source code (and,
even at the point D2009 appeared, we had more than a decade's worth of
32bit Delphi code)

We also had more than enough /new/ development requirements on our
to-do lists. The very last thing we needed was expend time (which means
money) on changing existing, running, debugged code just to conform to
the new compiler

We did make major efforts - and more than once - to move to D2009 but
the insuperable problem was interfacing the new Unicode front-end to
the immovably-fixed-field-length-ASCII database to which we /had/ to
conform.

Now if the brand new Unicode strings had been introduced as a
completely new "type", leaving "string" as an alias for "AnsiString"
then with one compilation and a run of our test suite, we would all
have been happy campers - but it wasn't.

(Of course, I'm sure that lots and lots of CRUD programs working to
Unicode databases did convert without problem. But our major system did
not. With the eventual result that we dismounted from the Delphi
upgrade bandwagon - with who knows how many software licences lost to
"the-companies-wich-have-owned-Delphi")

Now I see that the direction of travel is "ARC". Dan Barclay has
explained many times how breaking changes to Visual Basic caused the
collapse of its entire ecosystem.

People have been writing 32-bit Delphi programs for 20 years now. Even
though the average life of a Delphi application will be less than that,
it will take many years before the amount of /newly-written/ code even
begins to approach the volume of existing, running Delphi applications.

Q: So, have we learned anything from history? Has ARC been implemented
by introducing a separate, new type (say "tArcObject")?

A: Of course not! Let's change the behaviour of each and every
occurence of "Free" in absolutely every existing program source.
(Immediately if you were thinking of using any existing code
"cross-platform")

Just as well we did jump when we did

YMM-of course-V

wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 18, 2016 7:52 PM   in response to: Paul Scott in response to: Paul Scott

Sorry. IMNSHO "minimise-changes-to-take-advantage-of-Unicode" was
completely the wrong approach to take.

The prime, overriding objective of /any/ program change should always
be "preservation-of-user-data-and-program-behaviour".

In this case, Borland's "user-data" was our program source code (and,
even at the point D2009 appeared, we had more than a decade's worth of
32bit Delphi code)

Marvellous! This theoretical analysis is very logical. I like it.
Dan Barclay

Posts: 889
Registered: 11/9/03
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 18, 2016 8:13 PM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

Sorry. IMNSHO "minimise-changes-to-take-advantage-of-Unicode" was
completely the wrong approach to take.

The prime, overriding objective of /any/ program change should always
be "preservation-of-user-data-and-program-behaviour".

In this case, Borland's "user-data" was our program source code (and,
even at the point D2009 appeared, we had more than a decade's worth of
32bit Delphi code)

Marvellous! This theoretical analysis is very logical. I like it.

You will not win your argument here. It is "we" who are wrong.

Microsoft took the same position with VB, breaking the language itself significantly at VB4 and the coup de grace with VB7 (VB.Net). Read about it here (no, I'm not a writer but you get the picture):
http://vb.mvps.org/tips/stability/

The Delphi development team listens to "insiders" who are tightly coupled, just like the VB team did. While I was an MVP since 1993 (the first group of MVP's) I was not inside enough... I'm talking about really tightly coupled. Eventually these kinds of things break trust with developers and they wonder where their customers went.

Not that I've seen this before or know what I'm talking about. I'm just an idiot who doesn't know how to do things "right". Ask anybody.

Dan
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 18, 2016 8:57 PM   in response to: Dan Barclay in response to: Dan Barclay
I'm not going to win the argument. I just like the idea.
If can cause more thinking. That's enough. To tell you the truth, I have little hope of changing the Delphi.

I have a question. There's more than 6 years from Delphi2009. Does Delphi have anything wrong in the 6 years?
If there's no any mistake. Maybe there's no need to discuss.

If there's some mistake. Let's us discuss the mistake.
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 6:25 AM   in response to: Paul Scott in response to: Paul Scott
Paul Scott wrote:
Dalija Prasnikar wrote:


Delphi had to introduce Unicode. And since having compiler switch is
not possible it had to be introduced for all, whether you like it or
not.

Sorry. IMNSHO "minimise-changes-to-take-advantage-of-Unicode" was
completely the wrong approach to take.

The prime, overriding objective of /any/ program change should always
be "preservation-of-user-data-and-program-behaviour".

While I certainly value backward compatibility above all else, there are times
when you have to break things in order to go forward. Because maintaining
compatibility is more costly and more convoluted solution in the long run
than making breaking change at certain point.

Delphi had to implement Unicode strings.

First, Windows ANSI APIs are de facto deprecated since Windows XP. Some newer
APIs don't even have ANSI variant. The fact that ANSI variants of our applications
still run decade later is more good will of Microsoft than nothing else.

Second, there are developers that do need full support for Unicode in their applications,
where fiddling around ANSI is just not good enough or worth the trouble. There are
limitations to what you can do with ANSI variant of user interface.

I know that it would be much easier if we could only have to deal with ASCII set
of characters (or with English language) but unfortunately world is not that simple.

If you want to dispute that full support for Unicode string was needed then I am
afraid there is not much I can say.

If you agree that Unicode string was needed, then I am claiming that the only viable
choice was changing generic string type from ANSI to UTF-16. The only other option
would be to use UTF-8 as base but that would not be practical because Windows and
many other OS-ses use UTF-16 encoding, and second going from ANSI to UTF-8
would also require changes to everyones code.

Having string compiler switch is not viable solution. Why?

Because there would be need to maintain two sets of core libraries RTL/VCL (same goes
for any third party library)

But what people usually don't realize is that having (compiling) two sets of libraries is not
simple as flipping the switch. It is not just about providing libraries precompiled with
different string switch, they would have to maintain two sets of source code.

For instance, interacting with Windows API requires calling different functions depending on whether
you pass ANSI or Unicode strings as parameters. If nothing else maintaining backward compatibility
would require coding and testing for both string flavors of RTL/VCL (and now FMX) libraries.
That costs time and money for constantly maintaining obsolete functionality just because some
developers have hard time coping with one time transition to Unicode world.

Not to mention that all above does not even cover maintaining now more complex compiler that
is capable of supporting supporting such switch.

Unicode transition was inevitable.

Now, as far as ARC and ZBS are concerned, those changes didn't have to happen. But, since
they did happen we have to live with them. And at this pint I am only interested in how to
make ARC work better than discussing how stupid or not was introducing it.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
Lajos Juhasz

Posts: 801
Registered: 3/14/14
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 7:31 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:

[snip]

I agree what Dalija wrote. What more I would add that there are request
that AnsiString should not be code page aware. Now my question is:how
should the ANSI version of the RTL could convert that to unicode in
order to call a Windows API?

Also please don't forget that in this discussion there was some talk
about new developers. Does anybody really in believe in 2016 that in
any university students learn how to code using ASCII or ANSI?!

Get real Delphi must go further and keep up with C#, Java, etc..
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 12:17 PM   in response to: Lajos Juhasz in response to: Lajos Juhasz
Lajos wrote:

I would add that there are request that AnsiString should not be
code page aware.

That addition was inevitable. You can't convert from ANSI to Unicode without
knowing which ANSI encoding to use for the conversion. Prior to D2009,
the conversion was always done using Windows' default ANSI encoding only,
which more times than not proved to be the wrong encoding, especially since
it can be different on separate machines. Allowing AnsiString to carry its
own codepage was a smart and necessary move when migrating into a Unicode
environment.

how should the ANSI version of the RTL could convert that to unicode
in order to call a Windows API?

Without the proper codepage, it can't, without risking data loss.

--
Remy Lebeau (TeamB)
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 4:23 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...

I would add that there are request that AnsiString should not be
code page aware.

That addition was inevitable. You can't convert from ANSI to Unicode without
knowing which ANSI encoding to use for the conversion. Prior to D2009,
the conversion was always done using Windows' default ANSI encoding only,
which more times than not proved to be the wrong encoding, especially since
it can be different on separate machines. Allowing AnsiString to carry its
own codepage was a smart and necessary move when migrating into a Unicode
environment.

yes, this is the only good think emb does in the unicode migration !
make ansi string with code page that we can translate on the fly and
transparently. it's even so fast that the argument we need to migrate to
utf16 because all api are utf16 is false because this translation on the
fly will be in most of the case invisible and not noticeable to end user
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 5:28 PM   in response to: loki loki in response to: loki loki
loki wrote:

yes, this is the only good think emb does in the unicode migration !
make ansi string with code page that we can translate on the fly and
transparently. it's even so fast that the argument we need to migrate
to utf16 because all api are utf16 is false because this translation
on the fly will be in most of the case invisible and not noticeable to
end user

Prior to D2009, that translation was already being performed, but at the
OS layer instead. The RTL/VCL would call ANSI APIs, which in turn would
translate parameters to Unicode, call the corresponding Unicode APIs, and
then translate any output strings back to ANSI. That was a performance hit
on every API call.

Making Delphi call Unicode APIs instead of ANSI APIs was the correct move
to make. Making the default string type be UnicodeString instead of AnsiString
to match that change was the correct move to make.

If you pass an AnsiString where a UnicodeString is expected, or vice versa,
the RTL already does perform a silent and transparent conversion for you.
But are you going to want to force that on conversion every API call again?
No, that is another performance hit, and this time it is at the RTL layer
instead of the OS layer.

--
Remy Lebeau (TeamB)
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 20, 2016 3:10 AM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...

Prior to D2009, that translation was already being performed, but at the
OS layer instead. The RTL/VCL would call ANSI APIs, which in turn would
translate parameters to Unicode, call the corresponding Unicode APIs, and
then translate any output strings back to ANSI. That was a performance hit
on every API call.

+1

Making Delphi call Unicode APIs instead of ANSI APIs was the correct move
to make. Making the default string type be UnicodeString instead of AnsiString
to match that change was the correct move to make.

It's correct. But not enough. It should retain the possibility of continuing to use AnsiString

If you pass an AnsiString where a UnicodeString is expected, or vice versa,
the RTL already does perform a silent and transparent conversion for you.
But are you going to want to force that on conversion every API call again?
No, that is another performance hit, and this time it is at the RTL layer
instead of the OS layer.

+1
Rudy Velthuis (...


Posts: 7,731
Registered: 9/22/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 20, 2016 3:23 AM   in response to: wenjie zhou in response to: wenjie zhou
wenjie zhou wrote:

Making Delphi call Unicode APIs instead of ANSI APIs was the
correct move to make. Making the default string type be
UnicodeString instead of AnsiString to match that change was the
correct move to make.

It's correct. But not enough. It should retain the possibility of
continuing to use AnsiString

You can use AnsiString, and even ShortString, if you like. It is just
not the default anymore.

--
Rudy Velthuis http://www.rvelthuis.de

"Would you like to liberate yourself from the lower realms of
life? Would you like to save the world from the degradation and
destruction it seems destined for? Then step away from shallow
mass movements and quietly go to work on your own
self-awareness."
-- Lao tzu

loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 4:19 PM   in response to: Lajos Juhasz in response to: Lajos Juhasz

Also please don't forget that in this discussion there was some talk
about new developers. Does anybody really in believe in 2016 that in
any university students learn how to code using ASCII or ANSI?!

yes, because university, when they are not payed by microsoft, are on
.... LINUX (utf8) :)
Lajos Juhasz

Posts: 801
Registered: 3/14/14
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 20, 2016 1:11 AM   in response to: loki loki in response to: loki loki
loki loki wrote:


Also please don't forget that in this discussion there was some talk
about new developers. Does anybody really in believe in 2016 that in
any university students learn how to code using ASCII or ANSI?!

yes, because university, when they are not payed by microsoft, are on
.... LINUX (utf8) :)

Not every university is using Linux. In Eastern Europe the standard was
Java, not sure what they use nowdays (I was one of the last generations
to learn Modula-2). I have had only one subject about Linux and
developing software for it.
Dan Barclay

Posts: 889
Registered: 11/9/03
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 10:33 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:
Not to mention that all above does not even cover maintaining now more complex compiler that
is capable of supporting supporting such switch.

Unicode transition was inevitable.

It is not that they did it, but how they did it.

I'm not in the camp that says there needs to be a switch.

I do believe that, had their objectives and strategy been right, behavior of base types would have remained unchanged. Users should have been able to change their declarations to "ansistring" from "string" (if, after all, ansistring is what they require for their own reasons) and have code behave the same in older and newer versions.

Yes, they could have. They didn't. We don't know what the discussion was internally, but those insiders here clearly believe that concern for existing code should take a back seat. You can get away with that once or twice, but developers begin to lose trust that their code assets are being respected and protected.

So, one response I've seen here is "if you don't like it here then leave". Have they noticed fewer renewals? I know of at least two. We transitioned a lot of code from VB to Delphi on account of the same issue. VB, compared to prior usage, is dead and it certainly wasn't my leaving that had anything to do with it.

Dan
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 11:37 AM   in response to: Dan Barclay in response to: Dan Barclay
Dan Barclay wrote:
Dalija Prasnikar wrote:
Not to mention that all above does not even cover maintaining now more complex compiler that
is capable of supporting supporting such switch.

Unicode transition was inevitable.

It is not that they did it, but how they did it.

I'm not in the camp that says there needs to be a switch.

I do believe that, had their objectives and strategy been right, behavior of base types would have remained unchanged. Users should have been able to change their declarations to "ansistring" from "string" (if, after all, ansistring is what they require for their own reasons) and have code behave the same in older and newer versions.

I am not sure what you mean.

In theory there are three ways it could be handled

1. The way it is now, generic string type has changed from ANSI to UTF-16

2. Providing compiler switch that would define string as ANSI or UTF-16 (that is
scenario I was talking about that would require two sets of everything)

3. Leave string as ANSI, introduce UnicodeString - this is by far the worst possible
scenario - it would require insurmountable changes to code for people that do need
Unicode - because each string they would have to rename to UnicodeString, and it
would also include large amount of changes to code for people that do not need
Unicode because in order for Unicode part to work RTL/VCL would have to be moved
to UnicodeString

No matter how you look at it, Unicode was done right in Delphi - with least issues for
ALL people.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
Quentin Correll


Posts: 2,412
Registered: 12/1/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 12:52 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija,

| 3. Leave string as ANSI, introduce UnicodeString - this is by far the
| worst possible scenario

Not for some of us!!!

I'm one of the ol'timers who would rather have nothing-at-all to do
with Unicode!!!!!!!

--

Q -- XanaNews 1.19.1.372 - 2016-08-19 12:51:11
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 20, 2016 12:35 PM   in response to: Quentin Correll in response to: Quentin Correll
Quentin Correll wrote:
Dalija,

| 3. Leave string as ANSI, introduce UnicodeString - this is by far the
| worst possible scenario

Not for some of us!!!

You would not want this scenario. Because under this scenario everyone
would have to change their code a lot.

Scenario you would want is no Unicode at all ;-)

I'm one of the ol'timers who would rather have nothing-at-all to do
with Unicode!!!!!!!

I wish world would be that simple.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 20, 2016 3:10 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
On 8/20/2016 10:35 PM, Dalija Prasnikar wrote:
Quentin Correll wrote:
Dalija,

| 3. Leave string as ANSI, introduce UnicodeString - this is by far the
| worst possible scenario

Not for some of us!!!

You would not want this scenario. Because under this scenario everyone
would have to change their code a lot.

explain me how ?

with alcinoe, I build a small application (available in
/demo/ALStringToAnsiString/) to convert all string type and string
function to their ansistring equivalent. I often rewrite the ansiString
equivalent when not exist (like for TStrings or inttostr for exemple)

thanks to this i was able to survive to the unicode migration by
"canceling" it !

it's not very hard to do !! but this must have be done by emb not by me ...

Also on lot of my applications the migration to Unicode was
really unnecessary, as they was already working in UTF8,
receive their input request in utf8 and output their response
in UTF8. Here the migration to UTF16 will mean:
Input (UTF8) => UTF16 => data processing => UTF16 => output(UTF8)
+ off course all the migration job (that include debugging).
In fact, except the input/output to the "visual interface",
most (if not all) of the input/output of most of the
application will be done in 8bit string (ex: file storage,
client/server protocol, HTTP, Smtp, tcp, xml, html, database,
etc.).

to conclude if you application is a gui app, maybe yes unicode is maybe
good, if you application is a server app working in 8bit string, it's
completely stupid ! and when you will understand that emb with their
unicode migration kill all theses server app we will made a big step!
their is good raison why the number of delphi developper do down after
2009 ! their is no mistery ...
Quentin Correll


Posts: 2,412
Registered: 12/1/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 22, 2016 10:48 AM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija,

| Scenario you would want is no Unicode at all ;-)

Yes, you are indeed correct! <g>

--

Q -- XanaNews 1.19.1.372 - 2016-08-22 10:48:14
Dan Barclay

Posts: 889
Registered: 11/9/03
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 4:47 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
Dalija Prasnikar wrote:
Dan Barclay wrote:
Dalija Prasnikar wrote:
Not to mention that all above does not even cover maintaining now more complex compiler that
is capable of supporting supporting such switch.

Unicode transition was inevitable.

It is not that they did it, but how they did it.

I'm not in the camp that says there needs to be a switch.

I do believe that, had their objectives and strategy been right, behavior of base types would have remained unchanged. Users should have been able to change their declarations to "ansistring" from "string" (if, after all, ansistring is what they require for their own reasons) and have code behave the same in older and newer versions.

I am not sure what you mean.

In theory there are three ways it could be handled

1. The way it is now, generic string type has changed from ANSI to UTF-16

2. Providing compiler switch that would define string as ANSI or UTF-16 (that is
scenario I was talking about that would require two sets of everything)

3. Leave string as ANSI, introduce UnicodeString - this is by far the worst possible
scenario - it would require insurmountable changes to code for people that do need
Unicode - because each string they would have to rename to UnicodeString, and it
would also include large amount of changes to code for people that do not need
Unicode because in order for Unicode part to work RTL/VCL would have to be moved
to UnicodeString

No matter how you look at it, Unicode was done right in Delphi - with least issues for
ALL people.

I am not being clear, or you would understand me.

I'm saying that you can go ahead and change "string" from a meaning of "ansistring" to a meaning of "UTF-8" (or whatever type of string you want). I view "string" as only a placeholder or assignment, it is not a base data type. That is, there simply is no such thing as a "string data type" in Delphi.

If my code specifies "ansistring" (rather than string) and it only interacts with other ansistrings (and arrays of ansistring) then the code should behave the same in D2007 and XEn. If I want to use ansistring to encode binary, and only fling ansi characters around with no interaction of user interface (where Text lives) then the code should behave precisely the same in any version since the introduction of ansistring.

It does not. There are conversions between ansistring and "string", pounding it through code pages, that occur without permission. I pointed out a trivial example before [MyAnsi1:=ansiLeftStr(MyAnsi2,2)] where, by default, MyAnsi2 is converted to Unicode before the function and then the Unicode result is converted to ansi before assignment to MyAnsi1.

This kind of behavior is driven by lack of priority on existing code, probably influenced by the attitude of "you're just doing it wrong" as we see here often. That attitude is both subjective and (mainly) irrelevant. Myself and others receive the message explicitly stated earlier in this thread "If you don't like it, leave". And so it happens, and that helps no one.

If you maintained a preservation objective, and the behavior, you could easily deprecate the "string is ansistring" and users could convert to definitions of ":ansistring" instead of ":string" where it mattered. Moreover, that code could be changed in an earlier version of Delphi where some of the newer "recommended" data types don't exist.

This is not rocket surgery. It's almost completely about vision and priorities. Microsoft even had the ability to make VB code work great through a direct transition to .Net and chose not to, because they were far enough down the road that it was going to delay them a few months to fix it. Some even tried to claim "you can't do that in .Net" on some things, and clearly you can (some of us do understand IL and the language conversions). VB, R.I.P.

Developers with real code assets value the code at a higher level than they do developer tools. The developer tool is a tool, not an objective.

They could hire me to help on this... if my phone ain't ringing it must not be them. <shrug>

Dan
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 5:35 PM   in response to: Dan Barclay in response to: Dan Barclay
Dan wrote:

I'm saying that you can go ahead and change "string" from a meaning of
"ansistring" to a meaning of "UTF-8" (or whatever type of string you
want). I view "string" as only a placeholder or assignment, it is not
a base data type. That is, there simply is no such thing as a "string
data type" in Delphi.

Now you are going down a steep and slippery slope. Strongly-typed languages,
like C++ and Delphi, can't treat strings that way. They need to be a concise
data type, using a concise encoding.

If my code specifies "ansistring" (rather than string) and it only
interacts with other ansistrings (and arrays of ansistring) then the
code should behave the same in D2007 and XEn. If I want to use
ansistring to encode binary, and only fling ansi characters around
with no interaction of user interface (where Text lives) then the code
should behave precisely the same in any version since the introduction
of ansistring.

And that is what it really does, even today, IF you assign an AnsiString
to another AnsiString.

There are conversions between ansistring and "string", pounding it through
code pages, that occur without permission.

Yes, but only IF you assign an AnsiString to a different string type, whether
that be UnicodeString, WideString, UTF8String. Or vice versa.

I pointed out a trivial example before [MyAnsi1:=ansiLeftStr(MyAnsi2,2)]
where, by default, MyAnsi2 is converted to Unicode before the function
and then the Unicode result is converted to ansi before assignment to
MyAnsi1.

Yes, but only because you are calling the UnicodeString version of AnsiLeftStr().
There is an AnsiString version of AnsiLeftStr() in the System.AnsiStrings
unit, where most of the AnsiString-based legacy functions were moved to.

--
Remy Lebeau (TeamB)
Dan Barclay

Posts: 889
Registered: 11/9/03
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 7:04 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
Dan wrote:
I pointed out a trivial example before [MyAnsi1:=ansiLeftStr(MyAnsi2,2)]
where, by default, MyAnsi2 is converted to Unicode before the function
and then the Unicode result is converted to ansi before assignment to
MyAnsi1.

Yes, but only because you are calling the UnicodeString version of AnsiLeftStr().
There is an AnsiString version of AnsiLeftStr() in the System.AnsiStrings
unit, where most of the AnsiString-based legacy functions were moved to.

If you try to reuse a unit, this is what it does. By default.

The correct way to have handled it would be to either overload the functions, or require specification of Unicode versions of AnsiStrings. For goodness sake, do you not see the silliness in having ansiXXXstr() functions default to Unicode???

It
Breaks
Code.

Yes, I know it's easier for some people to transition, but the objective should be to preserve developers code assets. It is not.

Dan
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 8:16 PM   in response to: Dan Barclay in response to: Dan Barclay
Dan wrote:

The correct way to have handled it would be to either overload
the functions, or require specification of Unicode versions of
AnsiStrings. For goodness sake, do you not see the silliness
in having ansiXXXstr() functions default to Unicode???

The Ansi... names were preserved to maintain backwards compatibility with
existing code. Many of them also have companion functions without the Ansi...
prefix (LeftStr(), etc).

It
Breaks
Code.

So you keep saying, and yet you haven't provided one single example that
is broken, and **MOST** Delphi users have made the migration to Unicode without
issue. **YOU** have issues - fine. Fix them. Most everyone else has moved
on.

--
Remy Lebeau (TeamB)
Dan Barclay

Posts: 889
Registered: 11/9/03
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 9:59 PM   in response to: Remy Lebeau (Te... in response to: Remy Lebeau (Te...
Remy Lebeau (TeamB) wrote:
Dan wrote:

The correct way to have handled it would be to either overload
the functions, or require specification of Unicode versions of
AnsiStrings. For goodness sake, do you not see the silliness
in having ansiXXXstr() functions default to Unicode???

The Ansi... names were preserved to maintain backwards compatibility with
existing code. Many of them also have companion functions without the Ansi...
prefix (LeftStr(), etc).

And? Irrelevant. Call them Fred if you want.


It
Breaks
Code.

So you keep saying, and yet you haven't provided one single example that
is broken, and **MOST** Delphi users have made the migration to Unicode without
issue. **YOU** have issues - fine. Fix them. Most everyone else has moved
on.

Bingo. I rest my case.
You have moved on, some others yet haven't. I'm sure some have not even moved to XE versions.

Dan
Lajos Juhasz

Posts: 801
Registered: 3/14/14
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 20, 2016 1:16 AM   in response to: Dan Barclay in response to: Dan Barclay
Dan Barclay wrote:


If my code specifies "ansistring" (rather than string) and it only
interacts with other ansistrings (and arrays of ansistring) then the
code should behave the same in D2007 and XEn. If I want to use
ansistring to encode binary, and only fling ansi characters around
with no interaction of user interface (where Text lives) then the
code should behave precisely the same in any version since the
introduction of ansistring.

This is simply not true. In D2007 ansi string was not code page aware.
so it would not be the same. Storing a binary in ANSI string is not
possible. Please note that not every byte corresponds to a character in
every code page. In some cases you could loose that as your assignment
would translate to ? characters when you try to assign an invalid byte.
Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 20, 2016 9:27 AM   in response to: Lajos Juhasz in response to: Lajos Juhasz
Am 20.08.2016 um 10:16 schrieb Lajos Juhasz:
Dan Barclay wrote:


If my code specifies "ansistring" (rather than string) and it only
interacts with other ansistrings (and arrays of ansistring) then the
code should behave the same in D2007 and XEn. If I want to use
ansistring to encode binary, and only fling ansi characters around
with no interaction of user interface (where Text lives) then the
code should behave precisely the same in any version since the
introduction of ansistring.

This is simply not true. In D2007 ansi string was not code page aware.
so it would not be the same. Storing a binary in ANSI string is not
possible. Please note that not every byte corresponds to a character in
every code page. In some cases you could loose that as your assignment
would translate to ? characters when you try to assign an invalid byte.

Hello,

in D2009 they introduiced RawByteString for such codepage less scenarious.

Greetings

Markus
Lajos Juhasz

Posts: 801
Registered: 3/14/14
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 21, 2016 1:28 AM   in response to: Markus Humm in response to: Markus Humm
Markus Humm wrote:


in D2009 they introduiced RawByteString for such codepage less
scenarious.

Greetings

Markus

The reason for that was not that. But even you have to modify your code
to use RawByteString instead of ansistring so it's not just a
recompile. The code will not compile as is in both D2007 and D2009+.

Markus Humm

Posts: 5,113
Registered: 11/9/03
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 22, 2016 12:14 AM   in response to: Lajos Juhasz in response to: Lajos Juhasz
Am 21.08.2016 um 10:28 schrieb Lajos Juhasz:
Markus Humm wrote:


in D2009 they introduiced RawByteString for such codepage less
scenarious.

Greetings

Markus

The reason for that was not that. But even you have to modify your code
to use RawByteString instead of ansistring so it's not just a
recompile. The code will not compile as is in both D2007 and D2009+.


Yes, but the necessary modifications are minor.
You can define RawByteString = AnsiString for older versions.

Greetings

Markus
Remy Lebeau (Te...


Posts: 9,447
Registered: 12/23/01
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 22, 2016 10:38 AM   in response to: Markus Humm in response to: Markus Humm
Markus wrote:

in D2009 they introduiced RawByteString for such codepage
less scenarious.

Not exactly. RawByteString is not codepage-less. It inherits the current
codepage of whatever Ansi string type is assigned to it (AnsiString, AnsiString(N),
UTF8String, another RawByteString, etc). This allows you to write codepage-agnostic
functions that accept any Ansi data as input. That is what RawByteString
is primarily intended for. It is not a general-purpose string type like
the others are.

--
Remy Lebeau (TeamB)
Dan Barclay

Posts: 889
Registered: 11/9/03
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 22, 2016 9:56 AM   in response to: Lajos Juhasz in response to: Lajos Juhasz
Lajos Juhasz wrote:
Dan Barclay wrote:


If my code specifies "ansistring" (rather than string) and it only
interacts with other ansistrings (and arrays of ansistring) then the
code should behave the same in D2007 and XEn. If I want to use
ansistring to encode binary, and only fling ansi characters around
with no interaction of user interface (where Text lives) then the
code should behave precisely the same in any version since the
introduction of ansistring.

This is simply not true. In D2007 ansi string was not code page aware.
so it would not be the same. Storing a binary in ANSI string is not
possible. Please note that not every byte corresponds to a character in
every code page. In some cases you could loose that as your assignment
would translate to ? characters when you try to assign an invalid byte.

I'm not sure what your point is, but you are making my point.

If I put a character (as a byte) in an ansistring in D2007 it remains the same bit pattern unless I do something that causes it to reference a code page. That, essentially, only happens during I/O. How do I know? Before I started using it I checked. The AnsiXXXStr() functions and friends that I used only move bytes. Not a code page in sight. It's easy enough to check by tracing the VCL.

The byte slinging functions are pure and fast in D2007 (and before). Not so in later versions, and "new datatypes" were not blessed with equivalent support functions. This is the base issue that causes a lot of code to be rewritten (or NOT rewritten and left where it is).

When you have a working library and/or app there is a huge risk in rewriting that code, and the idea that some other wizard thinks it shouldn't have been done that way is completely irrelevant. It means the code won't be migrated, and the Delphi upgrades won't be purchased.

Then there's the next change (some discussed here) and the next and the next. Before long you begin to lose trust that your code assets can be maintained. You don't have to agree or understand it's just a fact, BTDT. Several versions down the road folks start to wonder "where did they go?". Answer: you left them behind.

Dan
Dalija Prasnikar

Posts: 2,325
Registered: 11/9/99
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 20, 2016 12:48 PM   in response to: Dan Barclay in response to: Dan Barclay
Dan Barclay wrote:
Dalija Prasnikar wrote:
Dan Barclay wrote:
Dalija Prasnikar wrote:
Not to mention that all above does not even cover maintaining now more complex compiler that
is capable of supporting supporting such switch.

Unicode transition was inevitable.

It is not that they did it, but how they did it.

I'm not in the camp that says there needs to be a switch.

I do believe that, had their objectives and strategy been right, behavior of base types would have remained unchanged. Users should have been able to change their declarations to "ansistring" from "string" (if, after all, ansistring is what they require for their own reasons) and have code behave the same in older and newer versions.

I am not sure what you mean.

In theory there are three ways it could be handled

1. The way it is now, generic string type has changed from ANSI to UTF-16

2. Providing compiler switch that would define string as ANSI or UTF-16 (that is
scenario I was talking about that would require two sets of everything)

3. Leave string as ANSI, introduce UnicodeString - this is by far the worst possible
scenario - it would require insurmountable changes to code for people that do need
Unicode - because each string they would have to rename to UnicodeString, and it
would also include large amount of changes to code for people that do not need
Unicode because in order for Unicode part to work RTL/VCL would have to be moved
to UnicodeString

No matter how you look at it, Unicode was done right in Delphi - with least issues for
ALL people.

I am not being clear, or you would understand me.

I'm saying that you can go ahead and change "string" from a meaning of "ansistring" to a meaning of "UTF-8" (or whatever type of string you want). I view "string" as only a placeholder or assignment, it is not a base data type. That is, there simply is no such thing as a "string data type" in Delphi.

If my code specifies "ansistring" (rather than string) and it only interacts with other ansistrings (and arrays of ansistring) then the code should behave the same in D2007 and XEn. If I want to use ansistring to encode binary, and only fling ansi characters around with no interaction of user interface (where Text lives) then the code should behave precisely the same in any version since the introduction of ansistring.

It does not. There are conversions between ansistring and "string", pounding it through code pages, that occur without permission. I pointed out a trivial example before [MyAnsi1:=ansiLeftStr(MyAnsi2,2)] where, by default, MyAnsi2 is converted to Unicode before the function and then the Unicode result is converted to ansi before assignment to MyAnsi1.

This kind of behavior is driven by lack of priority on existing code, probably influenced by the attitude of "you're just doing it wrong" as we see here often. That attitude is both subjective and (mainly) irrelevant. Myself and others receive the message explicitly stated earlier in this thread "If you don't like it, leave". And so it happens, and that helps no one.

If you maintained a preservation objective, and the behavior, you could easily deprecate the "string is ansistring" and users could convert to definitions of ":ansistring" instead of ":string" where it mattered. Moreover, that code could be changed in an earlier version of Delphi where some of the newer "recommended" data types don't exist.

OK, if I get you right you don't mind renaming string with AnsiString in code where
you need old behavior, but you have issues with codepage conversions.

If that is the case, then using AnsiString is wrong type RawByteString is the one
that doesn't do any conversions.

Also, when I say that Unicode conversion was done right, I mean changing of
generic string type from ANSI to UTF-16. There are some dubious RTL decisions
like the ones you mention where functions named Ansi... now work on Unicode
strings. And of course, some functions working on Ansi (8-bit) strings are no
longer supported. But I consider those only minor nuisance far from being showstoppers,
and those issues can be corrected without touching compiler.

--
Dalija Prasnikar
https://twitter.com/dalijap
https://plus.google.com/+DalijaPrasnikar
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 20, 2016 3:12 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
On 8/20/2016 10:48 PM, Dalija Prasnikar wrote:
Dan Barclay wrote:
Dalija Prasnikar wrote:
Dan Barclay wrote:
Dalija Prasnikar wrote:
Not to mention that all above does not even cover maintaining now more complex compiler that
is capable of supporting supporting such switch.

Unicode transition was inevitable.

It is not that they did it, but how they did it.

I'm not in the camp that says there needs to be a switch.

I do believe that, had their objectives and strategy been right, behavior of base types would have remained unchanged. Users should have been able to change their declarations to "ansistring" from "string" (if, after all, ansistring is what they require for their own reasons) and have code behave the same in older and newer versions.

I am not sure what you mean.

In theory there are three ways it could be handled

1. The way it is now, generic string type has changed from ANSI to UTF-16

2. Providing compiler switch that would define string as ANSI or UTF-16 (that is
scenario I was talking about that would require two sets of everything)

3. Leave string as ANSI, introduce UnicodeString - this is by far the worst possible
scenario - it would require insurmountable changes to code for people that do need
Unicode - because each string they would have to rename to UnicodeString, and it
would also include large amount of changes to code for people that do not need
Unicode because in order for Unicode part to work RTL/VCL would have to be moved
to UnicodeString

No matter how you look at it, Unicode was done right in Delphi - with least issues for
ALL people.

I am not being clear, or you would understand me.

I'm saying that you can go ahead and change "string" from a meaning of "ansistring" to a meaning of "UTF-8" (or whatever type of string you want). I view "string" as only a placeholder or assignment, it is not a base data type. That is, there simply is no such thing as a "string data type" in Delphi.

If my code specifies "ansistring" (rather than string) and it only interacts with other ansistrings (and arrays of ansistring) then the code should behave the same in D2007 and XEn. If I want to use ansistring to encode binary, and only fling ansi characters around with no interaction of user interface (where Text lives) then the code should behave precisely the same in any version since the introduction of ansistring.

It does not. There are conversions between ansistring and "string", pounding it through code pages, that occur without permission. I pointed out a trivial example before [MyAnsi1:=ansiLeftStr(MyAnsi2,2)] where, by default, MyAnsi2 is converted to Unicode before the function and then the Unicode result is converted to ansi before assignment to MyAnsi1.

This kind of behavior is driven by lack of priority on existing code, probably influenced by the attitude of "you're just doing it wrong" as we see here often. That attitude is both subjective and (mainly) irrelevant. Myself and others receive the message explicitly stated earlier in this thread "If you don't like it, leave". And so it happens, and that helps no one.

If you maintained a preservation objective, and the behavior, you could easily deprecate the "string is ansistring" and users could convert to definitions of ":ansistring" instead of ":string" where it mattered. Moreover, that code could be changed in an earlier version of Delphi where some of the newer "recommended" data types don't exist.

OK, if I get you right you don't mind renaming string with AnsiString in code where
you need old behavior, but you have issues with codepage conversions.

Under D2009+, ansiString Have now a codepage, and some
transliteration (OldCodePage => UTF16 => NewCodePage) will
happen when assigning one ansiString with different codepage
to another ansistring with another codepage. To avoid this
it’s important to always set project option to the code page
you want (eg. 65001 for UTF8) and also to call at the
beginning of the program SetMultiByteConversionCodePage(CP_UTF8);
Also it’s very important to avoid to use 2 differents
string type (eg UTF8string and aniString) even if they have
the same codepage, because compiler at compile time
don’t know that codepage is the same and will do a
transliteration (ex MyAnsiStringUTF8 := MyUTF8String will
result in UTF8 => UTF16 => UTF8). This is why we use in
all our code only AnsiString instead of UTF8String (even
when we assume that string contain only UTF8 char) to
avoid theses transliteration keep the rule to only use
AnsiString with SetMultiByteConversionCodePage and not type
like UTF8string or other

wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 22, 2016 8:40 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar
In fact, I think codepage for string is the beginning of evil.
We just need 2 string type.
1. bytestring = (old ansistring, also can store Utf8 string)
2. wordstring = (widestring , also can store Utf16 string);

In the future , we may need dwordstring = (can store Utf32)

Things are simple and clear. If we really need auto converting.
We can do this :

type  
   UTF8String = record
   private
       Value: bytestring;
   public
       class operator Implicit(const Value: AnsiString);
       class operator Implicit(const Value: UTF16String);
       ...
   end;
Quentin Correll


Posts: 2,412
Registered: 12/1/99
Re: Product Roadmap August 2016 [Edit]
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 22, 2016 10:50 AM   in response to: Dan Barclay in response to: Dan Barclay
Dan,

| there simply is no such thing as a "string data type" in Delphi.

Huh?! I could have swore I've been using such for years. (???)

--

Q -- XanaNews 1.19.1.372 - 2016-08-22 10:49:31
wenjie zhou

Posts: 424
Registered: 6/28/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Sep 20, 2016 3:13 AM   in response to: Dan Barclay in response to: Dan Barclay
I do believe that, had their objectives and strategy been right, behavior of base types would have remained unchanged. Users should have been able to change their declarations to "ansistring" from "string" (if, after all, ansistring is what they require for their own reasons) and have code behave the same in older and newer versions.
+1

Yes, they could have. They didn't. We don't know what the discussion was internally, but those insiders here clearly believe that concern for existing code should take a back seat. You can get away with that once or twice, but developers begin to lose trust that their code assets are being respected and protected.
+1
loki loki

Posts: 787
Registered: 7/1/02
Re: Product Roadmap August 2016
Click to report abuse...   Click to reply to this thread Reply
  Posted: Aug 19, 2016 4:18 PM   in response to: Dalija Prasnikar in response to: Dalija Prasnikar

Having string compiler switch is not viable solution. Why?

Because there would be need to maintain two sets of core libraries RTL/VCL (same goes
for any third party library)

But what people usually don't realize is that having (compiling) two sets of libraries is not
simple as flipping the switch. It is not just about providing libraries precompiled with
different string switch, they would have to maintain two sets of source code.

exactly ! but what is better, have 80 more developper in the emb team
to maintain this 2 precompiled librairies and 100.000 more customers
or to have 80 less emb developper in the team (ie read the recent
actuality) and 100.000 less customers ?? it's a pity :(

for my own compoment set, i do like this:
TalJsonDoc (ansi) and TalJsonDocU (unicode)
TalStringList (Ansi) and TalStringListU (unicode)
AlStringReplace (ansi) and alStringReplaceU (unicode)
etc...

it's not hard to maintain 2 set !

Now, as far as ARC and ZBS are concerned, those changes didn't have to happen. But, since
they did happen we have to live with them. And at this pint I am only interested in how to
make ARC work better than discussing how stupid or not was introducing it.

so vote for this feature :
https://quality.embarcadero.com/browse/RSP-15401

this is the best way for now, their is not other options. And it's will
not break any already made ARC code (i don't see how)