Re: [fpc-devel] Dangerous optimization in CASE..OF

[DaWorm]

I store record data in files with a checksum (usually a CRC). I block read
them into an array buffer and verify the checksum.  If it passes, I assign
via typecast the array buffer to a variable of the record type.  If I'm the
only one reading and writing the files that is usually enough to handle
drive bit rot, or transfer errors.

If someone else's code can write the data I validate everything either when
reading and assigning to the record type, or occasionally before use.  Sure
its slow but it's the only safe thing to do. I wouldn't think of abrogating
that responsibility to the compiler.

Jeff

On Jul 2, 2017 4:50 PM, "Marco van de Voort"  wrote:

> In our previous episode, Florian Kl?mpfl said:
> [ Charset UTF-8 unsupported, converting... ]
> > Am 02.07.2017 um 21:40 schrieb Martok:
> > > Honestly, I still don't understand why we're even having this
> discussion.
> >
> > Because it is a fundamental question: if there is any defined behavior
> possible if a variable
> > contains an invalid value. I consider a value outside of the declared
> range as invalid, if it shall
> > be valid, change the declaration of the type.
>
> _AND_ remove types that can't have reasonably cheap range checks like
> sparse
> enums ? :-)
> ___
> fpc-devel maillist  -  fpc-devel@lists.freepascal.org
> http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel
>
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Sets > 256

[DaWorm]

On Wed, Oct 14, 2015 at 5:36 AM, Michael Schnell  wrote:

> (Not hitchhiking the other thread...)
>
> On 13/10/15 19:59, Mohsen wrote:
>
>>
>> Pascal sets can only contain values/enumerations whose ordinal value is
>> <= 255.
>>
> As currently new language features are discussed I would vote to drop (or
> relax to some K ) this limitation. This would not break any existing code.
>
>
What if someone is storing a set in a file, or a stream?  Old version saves
it, new version reads it, and all of the sudden the data isn't in the same
format.

Jeff.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] BOOL / Comparing booleans - bad style

[DaWorm]

Pascal is about readability.  A sentence like if this variable is true do
that reads better than if this variable do that.  The danger is only
when the variable type and the constant representing TRUE are not
compatible.  In C, since TRUE is usually an untyped #define, that can be
hard to determine by the compiler or parser.  In Pascal, it should be easy
to detect when the two arguments aren't defined as identical types, even if
the types are assignable to each other.  But as long as True and the
affirmative type of Boolean match, there should be no need for a warning.
Only if True is Boolean, and the variable is ByteBool, or WordBool, or BOOL
or some other type that doesn't use the same True/False values as Boolean
should a warning be needed.

In other words, it isn't a style issue, it is a type compatibility issue.

Jeff

On Mon, Dec 15, 2014 at 7:46 AM, Jasper Neumann j...@sirrida.de wrote:

 Hello folks!

 MS But the silly C programmer did if (a == TRUE).

 JN I have seen this kind of nonsense way too often,
  even in Pascal code.
 May I sincerely ask to include a hint/warning feature such as
   Comparing booleans - bad style
 in order to notify the programmer to think twice.
 This warning should be also active when using booleans
  as case expression.

 Marco van de Voor wrote:
  This thread is about C style booleans.
  For normal, safe behaviour, use Pascal booleans.

 Well, yes, but...
 I probably should better have changed the subject.
 My aim was to cure this kind of practice as it occurs on the Pascal side,
 although it might concern C compilers as well. I should propose this
 hint/warning for e.g. LLVM or GCC also.

 Best regards
 Jasper
 ___
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/cgi-bin/mailman/listinfo/fpc-devel

Re: [fpc-devel] Multithreading under DOS

[DaWorm]

On Sep 27, 2013 3:27 AM, Michael Schnell mschn...@lumino.de wrote:

 In fact I remember that there even was a multitasking add-on for DOS.
Same allowed for switching between multiple DOS desktops without needing a
graphical UI. I don't remember the features and the requirements.

Perhaps you are thinking of Desqview/386?

Jeff
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Re: [fpc-pascal] Should TObject or TComponent have a Comment property?

[DaWorm]

How do you know which object to use if the documentation isn't in a
separate, searchable file or website?  Just query objects at random until
you find what you need?  How do you even know what the available objects
are? Also, many people still use a lot of procedural code.  Where is their
documentation since there is no object in the first place?

Can't see in any way how this proposal makes things better instead of worse.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] where do download BinUtils for ARM - Raspberry Pi?

[DaWorm]

On Mon, Jun 24, 2013 at 11:25 AM, Dennis Poon den...@avidsoft.com.hkwrote:

 **
 Does   have a stable stock supply?


Note this response I saw to a question about the BeagleBoard/BeagleBone:

Are we talking the design or the board? We will not guarantee continued
supply of any version of the BeagleBone. We will change it as we deem
necessary to make it better. Therefore if you put the BeagleBone boards in
a product, you will find that a particular revision is no longer made and
you cannot buy them. If you want to use the design in a product, that is
fine. If you want to build the board yourself, that is fine. We are not in
the business to crank out thousands of boards for someone to stick in their
product., We want to use our production capacity to build boards that go to
the community. If we determine that a distributor is selling the BeagleBone
for commercial use, they will find their supply of boards will not be there.
 

https://groups.google.com/forum/#!topic/beagleboard/yeX5GkEbqZc

So you might want to be careful about using them straight from the mfg,
but you can build your own from the design data all you like.

Jeff.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] PPU version checking

[DaWorm]

Is the project one that can use shared libraries?  Or does the code require
inheritance from the code you want to hide the implementation of?

Jeff.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Are x86 optimizations across various platforms shared?

[DaWorm]

Could it be OS calls are slower on FreeBSD?  I don't suppose there's an
easy way to profile application versus OS call execution time, is there?

Jeff.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Unicode proceedings

[DaWorm]

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.  I'm on my phone, so this may be hard to show an example:

type String = record
  encoding: TEncoding;
  disposition: Tdisposition;
  data: Tbytes;
end;

Disposition would have values like:

fixed - will always be in this encoding, anything assigned to a variable of
this type will be automatically converted.  Any out parameter of this type
will be initialized to an empty string of this encoding.

open - encoding only defines initial encoding.  Assigning a string of
another type will result in this string taking on that type, but NOT that
type's disposition.  Out parameters initialized to the given encoding.

strict - only compatible with other strings of the same type, period.  Try
to assign a string of a different type, compile time error.  Will force
manual conversion between encoding (possibly via typecast that calls
internal encoding translation).

Example:
type ANSIString = String encoding UTC16 disposition fixed;

Syntax is probably all wrong, but hopefully you get the idea.  If the real
lowest level is something other than String, then String itself can be an
alias that is different for each platform to match that platforms native
type.

It seems something like this would let the people who just want to use
strings in a consistent way and not worry about conversion performance to
do so, and those who want speed to have the compiler help them out by
stopping them from creating code with lots of conversions.

Or, I may be completely off base.

Jeff.
On Nov 18, 2011 6:44 AM, Michael Schnell mschn...@lumino.de wrote:

 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 turned down as it's not
 possible to implement this providing predictable performance.

 -Michael
 __**_
 fpc-devel maillist  -  fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/**mailman/listinfo/fpc-develhttp://lists.freepascal.org/mailman/listinfo/fpc-devel

___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Unicode proceedings

[DaWorm]

On Nov 18, 2011 1:14 PM, Hans-Peter Diettrich drdiettri...@aol.com
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 pointer to the dynamic string content. And what about
temporary strings, used in string expressions?

I was thinking that the type for this sort of thing would be done at
compile time, not run time, but I suppose I expressed that quite poorly.

 I don't think that an added disposition will improve anything, because
its value has to be checked with every access to a string variable. With
strictly typed strings (of fixed encoding) all checks can be performed at
compile time.

The idea was that instead of forcing strings to be one way (dynamically
typed) or the other (fixed type), as defined by the compiler writers, that
instead both behaviours be supported, and which is in play for a particular
piece of code is decided by the developer.  How that gets implemented
cleanly could be anything, but I think it would have to be in the type
declaration.

Jeff.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: RE : [fpc-devel] Unicode support (yet again)

[DaWorm]

On Sep 18, 2011 5:50 AM, Marco van de Voort mar...@stack.nl wrote:

  The trouble is that it is not that easy, consider the first thing a
 long time pascal user will do is fix his existing code which has many
 constructs that loop over a string:

 setlength(s2,s1);
 for i:=1 to length(s1) do
  s2[i]:=s1[i];

 Now, to return codepoint[i], you need to parse all codepoints before [i].

 So instead of O(n) this loop suddenly becomes O(n^2)

Sure it does.  So what?  The point is, it will do what the user expects.
And for most users, the fact that it does it slowly won't even matter.  For
those whom it does matter, it is a chance for them to learn the right way.
Like I said in my first post, this is an extremely complex subject.  I think
trying to optimize user code before they even write it adds even more
complexity, which slows implementation down.  Get something that works and
gives the expected results first, worry about speed later.  By the time you
finish, the CPU speed will have caught up to you.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: RE : [fpc-devel] Unicode support (yet again)

[DaWorm]

On Sun, Sep 18, 2011 at 12:01 PM, Sven Barth
pascaldra...@googlemail.com wrote:
 On 18.09.2011 17:48, DaWorm wrote:

But isn't it O(n^2) only when actually using unicode strings?
Wouldn't you also be able to do something like String.Encoding := Ansi
and then all String[i] accesses would then be o(n) + x (where x is the
overhead of run time checking that it is safe to just use a memory
offset, presumably fairly short)? Of course it would be up to the user
to choose to reencode some string he got from the RTL or FCL that way
and understand the consequences.

What assumptions are the typical String[i] user going to make about
what is returned?  There will be the types that are seeing if the
fifth character is a 'C' or something like that, and for those there
probably isn't too much that is going to go wrong, they might have to
switch to C instead, or the compiler can make the 'C' literal a
unicode char which is really a string conversion at compile time.
There may be the ones that want to turn a 'C' into a 'c' by flipping
the 6th bit, and that will indeed break, and in a Unicode world,
perhaps that should break, forcing using LowerCase as needed.  And
there are those (such as myself) who often use strings as buffers for
things like serial comms.  That code will totally break if I were to
try to use a unicode string buffer, but a simple addition of
String.Encoding := ANSI or RawByteString or ShortString in the first
line would fix that, or I could bite the bullet and recode that quick
and dirty code the right way.  My point is that trying to keep the bad
habits of a single byte string world in a unicode world is
counterproductive.  They aren't the same, and all attempts to make
them the same just cause more problems than they solve.

As for the RTL and FCL, presumably they wouldn't be doing any of this
Sting[i] stuff in the first place, would they? So they aren't going to
suffer that speed penalty.  Just because one type of code is slow,
doesn't mean everything is slow.

Jeff.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: RE : [fpc-devel] Unicode support (yet again)

[DaWorm]

This might be total crap, so bear with me a moment,  In an object like
a Stringlist, there is a default property such as Strings, such that
List.Strings[1] is equivalent to List[1], is there not?  If, as in
.NET or Java, all strings become objects, then you could have a String
object whose default property is Chars, whose type isn't really a
char, but another String whose length is one entity.  Thus code that
was written as MyString[1] would essentially behave the same as for
old shortstrings (ignoring for a moment the difference between ' and 
in specifying a literal char or string).  This string object could
have a property called Encoding that determined if it was UTF8 or
UTF16 or ANSI or raw bytes, and methods to trigger a direct
conversion, and AsXXX properties to convert for use in routines that
needed a different encoding, the need for which can be determined at
run time.

This may not be even feasible, and it will break some legacy code, but
I think those used to old style strings could get used to it very
quickly, and most of the details would be buried in the RTL where
people who didn't want to see them would not.  Of course, any code
using move or treating a section of shortstring as an open array would
still break, but perhaps that is a good thing.  We aren't running on
8088's any more so dangerous tricks in search of speed shouldn't be
needed as often, if at all.

Those who are looking for super efficiency won't find it here, but I
think months of discussions and thousands of messages pretty much
prove this is a complex task and only a complex solution will solve
it.  Even if the solution is nothing like the above, it is fairly
obvious that any attempt at a simple one type fits all solution
won't work, and if you are going to have to have multiple solutions,
to me it is better to bite the bullet and implement a full solution.

Jeff.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]

[DaWorm]

On Tue, Sep 13, 2011 at 8:52 AM, Graeme Geldenhuys
graemeg.li...@gmail.com wrote:
 [sorry to be harsh towards DaWorm, but that was a
 damn stupid example]

It was only an example intended to show that executing getters can
have unintended and sometimes disastrous and/or non reversible side
effects.  By itself it might be a stupid thing to do, but the concept
that merely reading a property may actually change something else is
not stupid.  Maybe your getter returns the next item in a pseudo
random sequence, who know what it does?  The example wasn't the point:
that such an example is possible was the point.  And you might not
have built such a thing consciously.  Maybe you've descended from a
third party library routine that you may or may not have the source
code, for and that library does something you might not expect.

You may have the memory capacity to know that 15 levels deep there is
a property that is implemented by a getter with a side effect, but
that in this instance it is ok to run that getter in the debugger, but
I don't trust my memory that much.  I can easily forget that this
property has a getter with a side effect and that one doesn't.  That's
why I create objects in the first place, to hide all of those
implementation details once and for all, and concentrate on actually
getting things done.

I would not want any debugger to automatically execute such a property
getter.  I wouldn't mind if it warned me with a dialog box or message
that this property has a getter defined by such and such method, and I
then had the option to go check it out first, then maybe check a box
or change a setting saying this is ok from now on, but I don't want it
to just go and do it on its own.

As for it not being a problem in Delphi, I don't automatically enable
that option.  I doubt many others do either, at least not after
they've been bitten by it the first time.  If I try to evaluate a
property and it doesn't it is fairly obvious why, and I go down the
inheritence chain until I find the getter and look at what it is
using.  If it is harmless, then I might check the checkbox that says
to execute code to get the value, but it is the last thing I do, not
the first.  Of course, maybe all of my code is bad like that example
and so I don't have any choice, and maybe all of your code is perfect
and you never have to worry about it.  I'd say neither is totally
true.

Jeff.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: Adding properties into existing stabs/dwarf; gdb readable workaround ? [[Re: [fpc-devel] Status and ideas about debug info (stabs, dwarf / dwar3)]]

[DaWorm]

I don't understand why a property with a getter could ever be ran by a
debugger.  If I have a property called NextValue, implanted by a method
called GetNextValue, that increments a field, stores it in a database, and
returns the new value, I absolutely do not want the debugger to execute that
even if I'm dumb enough to try to ask it to view that property.  I would
expect it to give me a rational error message such as Property NextValue
implemented by method GetNextValue which would tell me that it understood
what I was asking, and why it couldn't do it.
On Sep 12, 2011 4:14 PM, Martin laza...@mfriebe.de wrote:
 On 12/09/2011 20:46, Joost van der Sluis wrote:
 On Mon, 2011-09-12 at 20:31 +0200, Jonas Maebe wrote:
 On 12 Sep 2011, at 20:20, Martin wrote:
 Could not properties mapping to a function be implemented the same way
= normal functions are already listed in ptype so
 public
 property Counter: Integer read GetCounter
 could appear the same as the function GetCounter ?

 In that case at least the list of available symbols is complete. The
only thing that then would need codetools involved was to check if the name
is a property and not a function/field.
 That may be possible, yes.
 What is it that we actually need? At the Dwarf-level:

 Is the information that a property actually has a getter, and the name
 of that getter enough?

 Or do we want that when the value of a property is asked, the getter is
 called automagically? (And that there is some kind of flag that
 indicates that a getter is being used?) I don't think that we can add a
 stack-script in the DW_AT_Location that executes the getter. I've looked
 at DW_OP_call, but that won't help us here.

 Or, and maybe this is the best solution: some 'opaque' type that returns
 a reference to something else. Which can be different for reading and
 writing values...


 There are 2 conflicting desires.

 -data-evaluate-expression FooObject.BarObjProp.BarValue
 ptype FooObject / ptype FooObject.BarObjProp

 The first only works, ( at current) if it is a field, not a getter
 function. IMHO that is ok.

 While alot of people do want code execution for properties, there must
 be a mean of control (in the front end, e.g lazarus). Even if that was
 enabled by default.
 That means, I would like that gdb does *not* automatically call the
 function.

 So for data evaluation we are fine.
 If it is a function, the expression fails, and the IDE needs to look
 into it.

 Well having said that. If the function was only called, if brackets are
 supplied, maybe.
 -data-evaluate-expression FooObject.BarObjProp().BarValue

 But it is not a must. I am not even sure if desirable.

 
 the 2nd issue is knowledge that
 a) a there is something in the object under the name of the property
 b) this something happens to be a property

 a) is already fulfilled if it is a field-property. Hence I asked, if
 functions could be added the same way.
 -data-evaluate-expression FooObject.GetCounter
 currently gets no value
 -data-evaluate-expression FooObject.Counter
 gives an error, no symbol

 if Counter could be the same as GetCounter (making it effectively a
 function of the object), then at least the symbol was present.
 And at the same time, this solves the question of does it get executed
 or not = same rules as for GetCounter

 b) The above of course does make no difference between it being a
 property or just a function.

 for normal evaluation, this may most times make no difference. But for
 debug inspector type windows (that offer an object inspector like view
 of the object, with values) it may make a diff.
 If the users setting is to auo-execute properties, then properties would
 be executed = but functions would not.

 So then it would be desirable, if there was any indicator between a
 function (or even field), and a property.
 Ideally this difference would be viewable via gdb = but that is not
 even a must. Eventually the IDE will read dwarf directly, at which time
 it could make use of it.

 -
 As for the whole auto execution:

 I do not know what the options are = I have not even checked all the
 means of controlling it in gdb


 ---
 I know, that given that the IDE anyway hasn't support for it yet, it is
 a very early request.
 But support in the IDE is hard to implement, if the feature cannot be
 tested. And also given that it will take time until the feature is
 present in a release, it is neer to early to ask





 ___
 fpc-devel maillist - fpc-devel@lists.freepascal.org
 http://lists.freepascal.org/mailman/listinfo/fpc-devel
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Thumb2 - Stellaris status

[DaWorm]

I'm not sure how FPC should handle the peripherals, but I don't think it
should be at the compiler level.  Even if the part I'm using has, for
instance, an ADC, if I'm not using it I do not want support for it built in
to my app.  With what I use currently (IAR C) I uncomment a #define for each
peripheral I want to add support for.  I'm sure something similar can be
done for FPC at the unit level.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Thumb2 - Stellaris status

[DaWorm]

On Aug 19, 2011 7:13 AM, Geoffrey Barton m...@periphon.net wrote:


  Afaik there is a standard for the Cortex platform how to do it, google
  for ARM Cortex Microcontroller Software Interface Standard

 there is a generic doc on the arm.com site and a stellaris specific one on
the TI site.

Following the CMSIS would definitely make development easier, but it comes
with a tradeoff.  The generic nature of it makes it very wordy and somewhat
inefficient (sometimes you have to make several function calls to do what a
single assign could do).  If possible, it might be best to have the compiler
expose the raw registers, and add CMSIS as a unit that can be included in
your application source.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Stellaris Update

[DaWorm]

STM32F103 and other ST Micro M3 parts have the ability to remap the vector
table.  You can create applications to start anywhere in memory, and use a
bootloader to remap the table and jump to the new power up vector.  In IAR C
this is handled in the linker config file.  Someone on the list thought it
better not to go that route.  However it is done, it should be done at an
individual application level, not tied to the part.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Arm Thumb2 - Stellaris status

[DaWorm]

For what it's worth, IAR's C compiler for Cortex-M3 uses an ICF file
to hold that information, so there is precedent for doing it that way.

It holds the following (edited slightly to remove fluff):

define symbol __ICFEDIT_intvec_start__ = 0x0800;
define symbol __ICFEDIT_region_ROM_start__ = 0x08EC;
define symbol __ICFEDIT_region_ROM_end__   = 0x0801EFFF;
define symbol __ICFEDIT_region_RAM_start__ = 0x2000;
define symbol __ICFEDIT_region_RAM_end__   = 0x20004FFF;
define symbol __ICFEDIT_size_cstack__ = 0x400;
define symbol __ICFEDIT_size_heap__   = 0x4;

define memory mem with size = 4G;
define region ROM_region   = mem:[from __ICFEDIT_region_ROM_start__
to __ICFEDIT_region_ROM_end__];
define region RAM_region   = mem:[from __ICFEDIT_region_RAM_start__
to __ICFEDIT_region_RAM_end__];

define block CSTACKwith alignment = 8, size = __ICFEDIT_size_cstack__   { };
define block HEAP  with alignment = 8, size = __ICFEDIT_size_heap__ { };

initialize by copy { readwrite };
do not initialize  { section .noinit };

place at address mem:__ICFEDIT_intvec_start__ { readonly section .intvec };

place in ROM_region   { readonly };
place in RAM_region   { readwrite,
block CSTACK, block HEAP };
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] String and UnicodeString and UTF8String

[DaWorm]

On Wed, Jan 12, 2011 at 7:38 AM, Hans-Peter Diettrich
drdiettri...@aol.com wrote:

 Until now most users, including you, most probably don't
 realize that difference between phyiscal and logical characters, and assume
 that sizeof(char) always is 1

Oh, I'm aware of it.  But to date, I haven't had to really deal with
it in Delphi or FPC. My use of strings is either ancient legacy (from
TP/BP days) where I simply changed all references to string to
shortstring or low level Windows API code, where I'm dealing with
PChar.

I find these discussions fascinating, but as they say in the southern
US, I don't have a dog in this hunt.  Whatever the decision, I'll
probably continue to use shortstring.

Jeff.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel

Re: [fpc-devel] Interface scope incompatibility with Delphi

[DaWorm]

Rather than filling up the list with why this particular issue
(something I've never done, and don't care about) behaves differently
than Delphi, could someone instead focus on how to perform the needed
task(s) with FPC?

FPC doesn't work the way Delphi does.  Take that as a given.  Then
figure out how FPC can do the same task.  If it is an easy compiler
fix, fine, do that.  If it isn't, don't gripe about it, instead figure
out another way to do the job with what you have available.  Wrap the
code, IFDEF it, whatever it takes, get the job done, and move on.
Pretty?  Not particularly.  Elegant?  Certainly not.  But it is far
more productive than spending a week arguing back and forth on the
mailing list.

Arguing about why FPC and Delphi are different, rather than
implementing solutions within the framework of what is available, is a
waste of everyone's time, including those of us who just want to read
our mail.

Jeff.
___
fpc-devel maillist  -  fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel