On Nov 18, 2011 1:14 PM, "Hans-Peter Diettrich"
wrote:
>
>
> That's not easily feasable, as long as empty strings are implemented as
Nil pointers. When reference counting etc. should be preserved, the
additional information had to be moved into an static string descriptor,
together with the pointe
On 18.11.2011 21:12, Sven Barth wrote:
Please note: While this is how it SHOULD work this does currently not
work with any version of the compiler except maybe my generic branch (I
haven't tested that yet).
Ok, I have tested that with my branch and it doesn't work there either.
After thinking
On 18.11.2011 18:31, AvP wrote:
1. Is this behavior intended (generic objects)?
I didn't find anything like that in the docs
It's at least not forbidden. I can imagine though that it was forgotten
to document as objects aren't used by that many persons (and thus they
are forgotten rather
DaWorm schrieb:
Perhaps a little extra compiler magic could be used? If the base
definition of a string (the hidden stuff before the data) contains not
only a field with the encoding, but a flag indicating the disposition of
the encoding, then when a string type is aliases, that disposition co
Michael Schnell schrieb:
As already said, my request at this time is not considering
implementation before agreeing on a decently clear definition of what
should be provided and what is supposed top happen when.
IMO such a separation is of no use. If you want an new string type, then
make it
Graeme Geldenhuys schrieb:
On 2011-11-18 12:11, Michael Schnell wrote:
Why should a type that is capable of holding multiple different UTF
encodings be called "ANSIString". IMHO this is very contra-intuitive.
Every time I see this used in Delphi too, I start to laugh as well. It
makes no sense
I just made a first attempt to use generics. Trying different things I figured
out that the appended code compiles without any error message in FPC
2.6.0RC1
1. Is this behavior intended (generic objects)?
I didn't find anything like that in the docs
2. Replacing "object" at (1) with "class" gi
Jonas wrote:
> One command line parameter was added later on to facilitate dealing with
> such situations: -CF32 and -CF64. Those specify the minimal precision
> that will be used for floating point constants
Terrific, thanks. I'll check out using that as a possibility as well.
-SG
--
This emai
Florian wrote:
> How should the compiler know that the division should be done using
> double? Using always double slows down calculations. Because the range
> of longword fits into a single as well as 24, fpc uses a single division.
...
> This is not possible. Especially i386/x87 behaves really s
Seems like the message you quote here went to you personally as well
(that would explain why you sent this answer to me directly first...)
Thus here the original mail I wroted
=== original mail begin ===
Am 18.11.2011 10:22, schrieb Michael Schnell:
> On 11/17/2011 02:44 PM, Sven Barth wrote:
On 18 Nov 2011, at 14:41, Seth Grover wrote:
Fair enough. Jonas, thanks for the link and explanation. I'll just be
more aware of what I'm doing when it involves calculations like this
and do the cast when needed.
One command line parameter was added later on to facilite dealing with
such si
On Fri, Nov 18, 2011 at 2:36 PM, Michael Schnell wrote:
>> And now very recently I found out that this is no longer valid in 2.7,
>> ansistring can be configured to hold a UTF-8 value in a valid and supported
>> way, and this changes a lot of things to me.
>
> To the worse I gather.
Quite the con
Fair enough. Jonas, thanks for the link and explanation. I'll just be
more aware of what I'm doing when it involves calculations like this
and do the cast when needed.
-SG
--
This email is fiction. Any resemblance to actual events
or persons living or dead is purely coincidental.
Seth Grover
___
On 11/18/2011 01:37 PM, Sven Barth wrote:
Because then you don't need to rely on the point that SizeOf(Char) =
1. Now imagine you have an applications that uses strings as buffers
and port that from lets say Delphi 7 to Delphi 2009. Have fun finding
the bugs if you don't remember that you used a
On 11/18/2011 01:48 PM, Felipe Monteiro de Carvalho wrote:
And now very recently I found out that this is no longer valid in 2.7,
ansistring can be configured to hold a UTF-8 value in a valid and
supported way, and this changes a lot of things to me.
To the worse I gather.
-Michael
__
On 11/18/2011 01:41 PM, Sven Barth wrote:
This could indeed have been named better. But there are other examples
like this: I still can't remember which of SmallInt and Short is the 1
Byte and the 2 Byte variant. Some type names like "Signed8" and
"Unsigned16" would simplyfy this... but I won
As already said, my request at this time is not considering
implementation before agreeing on a decently clear definition of what
should be provided and what is supposed top happen when.
-Michael
___
fpc-devel maillist - fpc-devel@lists.freepascal.o
Am 18.11.2011 14:09, schrieb Marco van de Voort:
In our previous episode, Graeme Geldenhuys said:
like this: I still can't remember which of SmallInt and Short is the 1
Byte and the 2 Byte variant. Some type names like "Signed8" and
"Unsigned16" would simplyfy this... but I won't go more into th
In our previous episode, Graeme Geldenhuys said:
> > like this: I still can't remember which of SmallInt and Short is the 1
> > Byte and the 2 Byte variant. Some type names like "Signed8" and
> > "Unsigned16" would simplyfy this... but I won't go more into that
> > direction now ^^
>
> For exactly
On 2011-11-18 14:41, Sven Barth wrote:
> like this: I still can't remember which of SmallInt and Short is the 1
> Byte and the 2 Byte variant. Some type names like "Signed8" and
> "Unsigned16" would simplyfy this... but I won't go more into that
> direction now ^^
For exactly the same reason I hav
On Fri, Nov 18, 2011 at 11:11 AM, Michael Schnell wrote:
> Why should a type that is capable of holding multiple different UTF
> encodings be called "ANSIString". IMHO this is very contra-intuitive.
Yes, I have to agree here. It seams that my understanding in the
Unicode discussions was plagued b
Perhaps a little extra compiler magic could be used? If the base
definition of a string (the hidden stuff before the data) contains not only
a field with the encoding, but a flag indicating the disposition of the
encoding, then when a string type is aliases, that disposition could be
overridden.
Am 18.11.2011 11:11, schrieb Michael Schnell:
In theory the AnsiString type (which is now the code page aware string
type) should be capable of holding UTF-8 and UTF-16 data,
Why should a type that is capable of holding multiple different UTF
encodings be called "ANSIString". IMHO this is very c
On 2011-11-18 13:37, Jonas Maebe wrote:
>
> It says that the floating point *constant* (in Seth's example: 24.0) is
> converted to the lowest precision that does not cause data loss.
My mistake, I read it wrong.
Regards,
- Graeme -
--
fpGUI Toolkit - a cross-platform GUI toolkit using Free
On 11/18/2011 12:04 PM, Jonas Maebe wrote:
http://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants
Taking a look at the "go" language:
Here all constants are considered to be of arbitrary precision. This
also holds for integers !
A constant can be "10<<1000" there.
Compile
On 11/18/2011 11:21 AM, Graeme Geldenhuys wrote:
Can't we just have a single damn string type like Java and some other
languages. Lets just call it...ummm String! ;-)
This has been discussed at any length here and in many other forums.
This is what I tried to describe in (B). It has been t
On 18 Nov 2011, at 12:20, Graeme Geldenhuys wrote:
On 2011-11-18 13:04, Jonas Maebe wrote:
http://wiki.freepascal.org/
User_Changes_2.2.0#Floating_point_constants
The description of the "new behaviour" should change then. The part
that
says "...which doesn't cause data loss" is now fals
On 2011-11-18 13:04, Jonas Maebe wrote:
>
> http://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants
The description of the "new behaviour" should change then. The part that
says "...which doesn't cause data loss" is now false, given Seth's
example. He lost precision compared to pre
On 17 Nov 2011, at 20:51, Seth Grover wrote:
Notice that in x86_64, unless you explicitly cast the longword as a
double before the division, you get some sort of rounding error or
loss of precision.
http://wiki.freepascal.org/User_Changes_2.2.0#Floating_point_constants
Jonas
___
On 2011-11-18 12:11, Michael Schnell wrote:
> Why should a type that is capable of holding multiple different UTF
> encodings be called "ANSIString". IMHO this is very contra-intuitive.
Every time I see this used in Delphi too, I start to laugh as well. It
makes no sense. Call the damn thing Unico
On 11/17/2011 03:01 PM, Marco van de Voort wrote:
The ansistring and unicodestring types have the same memory layout except
for the character data (iow the record before the character data is the
same).
My intention with starting this Thread was not to discuss any
implementation details, but to
On 11/17/2011 02:55 PM, Sven Barth wrote:
Am 17.11.2011 12:59, schrieb Michael Schnell:
Note that the Delphi2009 definition is theoretically capable of
combining one and
two bytes in one type (like Yury's).
As I don't have such a Delphi please help me to understand:
Is there a general type ded
On 11/17/2011 02:44 PM, Sven Barth wrote:
One could implement a similar type for something like this (maybe even
use the mentioned TBytes) and define operator overloads for it (at
least for "+").
Why should one do this, regarding that a normal string type provides
exactly what very often is
33 matches
Mail list logo
