Re: [fpc-devel] Closures -- debug warning @ ttgobj.FreeTemp

Am 09.03.2015 um 14:36 schrieb bla...@blaise.ru: FPC trunk r30150, compiled with EXTDEBUG, emits a debug warning for the following program: --8<-- type T = interface procedure Bar; end; function Foo: T; begin result := nil end; begin Foo().Bar() // ^-- Warning

Re: [fpc-devel] BOOL

Am 14.12.2014 um 16:51 schrieb Marco van de Voort: In our previous episode, Adriaan van Os said: reveals 0 for False and -1 for True, where I had expected 0 for False and 1 f according to the same respectively in Visual Studio 2013. There

[fpc-devel] cp1252 problems

Using FPC trunk, Lazarus on WinXP, file and $codepage UTF-8, DefaultSystemCodePage is 1252. Then AnsiString variables can contain either UTF-8 or cp1252 strings (inconsistent), but that's an already known problem :-( Now I found another bug with AnsiString(1252), which IMO should behave like

[fpc-devel] RawByteString Insert etc.

IMO the Insert procedure should change the encoding of the string-to-insert into the CP of the target string. Else the target string can become unusable, containing an mix of characters from different codepages. While a RawByteString can have any encoding, it cannot have two encodings at the sa

[fpc-devel] AnsiUpperCase problems

The following console program demonstrates various problems with the new (encoded) AnsiStrings (FPC trunk): program litTest2; {.$codepage UTF8} //off for now uses Classes,SysUtils; var A: AnsiString; begin a := 'äöü'; //a := a+' '; //uncomment later WriteLn(a,'äöü'); WriteLn(AnsiUpperCas

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"

Michael Schnell schrieb: On 11/29/2014 07:55 AM, Jonas Maebe wrote: Exactly the same goes for converting strings with code page CP_NONE to a different code page: your program is broken when it tries to do that, While accessing an array beyond its bounds is not detectable at compile time and a

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"

Michael Schnell schrieb: On 11/28/2014 09:15 PM, Hans-Peter Diettrich wrote: Apart from that, every encoding-tolerant code will execute much slower than code without a need for checks and conversions everywhere. As I pointed out I don't agree at all. - The check is only two ASM instruc

Re: [fpc-devel] Delphi incompatible encoding

Mattias Gaertner schrieb: On Tue, 02 Dec 2014 04:05:59 +0100 Hans-Peter Diettrich wrote: Many things affect string literals. Source codepage, system codepage, string type, defaultsystemcodepage, library, compiler version. I started a table for UTF-8 literals: http

Re: [fpc-devel] Delphi incompatible encoding

Tomas Hajny schrieb: On Tue, December 2, 2014 08:31, Hans-Peter Diettrich wrote: When I compile a console program on the commandline, most strings are readable in the console (see previous answer). But when I compile using Lazarus, all strings (including UnicodeString!) are shown in

Re: [fpc-devel] Delphi incompatible encoding

Jonas Maebe schrieb: To get behaviour that is compatible with Delphi2009+, compile with -Mdelphiunicode or {$modeswitch delphiunicode}. Do you mean {$mode delphiunicode}? Now I wonder about compilation at all. When I compile a console program on the commandline, most strings are readable in

Re: [fpc-devel] Delphi incompatible encoding

Jonas Maebe schrieb: Hans-Peter Diettrich wrote on ma, 01 dec 2014: To get behaviour that is compatible with Delphi2009+, compile with -Mdelphiunicode or {$modeswitch delphiunicode}. The compiler option (-M) works, but the $modeswitch is not accepted by the compiler (2.7.1): Illegal

Re: [fpc-devel] Delphi incompatible encoding

Sven Barth schrieb: Am 01.12.2014 10:33 schrieb "Hans-Peter Diettrich" <mailto:drdiettri...@aol.com>>: > Another one: > Delphi XE does not export the CP_xxx encoding constants from System.pas. This means that the encoding constants are not available in (compatible)

[fpc-devel] Delphi incompatible encoding

Now I could compile FPC 2.7.1 and perform some tests :-) Unfortunately I couldn't submit an bug report, so it comes here: When compiled with Delphi XE, the code below shows 1252 (my DefaultSystemCodePage) for all strings, be empty or non-empty. Compiled with FPC 2.7.1, the StringCodePage(r) is

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicodesupport"

Marco van de Voort schrieb: In our previous episode, Hans-Peter Diettrich said: storage, we'll have to take that into account. (16-bit codepages were designed into OS/2 and Windows NT before utf-8 even existed) Right, both systems were developed by Microsoft :-] A cooperation betwee

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"

Jonas Maebe schrieb: On 28/11/14 21:30, Hans-Peter Diettrich wrote: I prefer to specify and document everything *before* coding, so that everybody can expect that the code will behave as specified. If certain behaviour is explicitly undefined, it *is* specified and documented. It means that

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicodesupport"

Marco van de Voort schrieb: In our previous episode, Hans-Peter Diettrich said: While it certainly is a stupid (Microsoft) idea to use UTF-16 for file storage, we'll have to take that into account. (16-bit codepages were designed into OS/2 and Windows NT before utf-8 even existed)

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"

Michael Schnell schrieb: I fear that there will be code that relies on the "flawed" behavior of RawByteString ("it's a feature, not a bug") and using the same name with different behavior would brake same. And a really usable DynmicString would not adhere to that description. How can somebo

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"

Jonas Maebe schrieb: I'm sorry, but I simply cannot discuss with people that, when I literally state "the result is undefined", think that I may actually have meant "the result is defined and if you change the implementation and/or keep it stable across compiler releases, then it will also confo

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"

Michael Schnell schrieb: On 11/27/2014 03:44 PM, Hans-Peter Diettrich wrote: An *efficient* implementation would be based on a single program-wide string representation, with different encodings being handled only in an exchange with external data sources. Yep. But it would result in severe

[fpc-devel] RFC: proper interpretation and implementation of Unicode Support

In response to another thread (this should start an new thread): "CP_NONE: this value indicates that no code page information has been associated with the string data. The result of any explicit or implicit operation that converts this data to another code page is undefined." After rereading I

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"

Michael Schnell schrieb: On 11/26/2014 06:37 PM, Hans-Peter Diettrich wrote: An AnsiString consists of AnsiChar's. The *meaning* of these char's (bytes) depends on their encoding, regardless of whether the used encoding is or is not stored with the string. I understan

Re: [fpc-devel] Regionalisation (Was ThousandSeparator)

Michael Thompson schrieb: I hear you, but this issue is so much wider than separators. I know one software package that will only successfully export data to excel if the system regional is one of the "English (xxx)" variations (Australian guaranteed to work, not really played with the rest..

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"

Jonas Maebe schrieb: On 26/11/14 23:41, Hans-Peter Diettrich wrote: In this case the implementation is "compiler specific", somewhat different from "undefined" (in a RawByteString): "CP_NONE: this value indicates that no code page information has been associated with th

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"

Michael Schnell schrieb: On 11/26/2014 07:13 PM, Hans-Peter Diettrich wrote: Not all codepages have a fixed number of bytes per character. The string preamble contains the *element size* (1 for AnsiString), just like with every dynamic array. Sorry for sloppy wording. Of course I did mean

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"

Michael Schnell schrieb: I now understand that the "Element Size" field in the String header is quite dummy, as under the hood there are two completely separate concepts for one-byte-Strings and 2-Byte Strings and none for other Element sizes. After a code review I realized that the element

Re: [fpc-devel] ThousandSeparator

Frederic Da Vitoria schrieb: 2014-11-26 16:54 GMT+01:00 Hans-Peter Diettrich <mailto:drdiettri...@aol.com>>: 2) Formatted numbers, as enterd by the user (maybe by copy&paste from other applications), can have various encodings. Before a conversion into binary values I

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicodesupport"

Jonas Maebe schrieb: On 26/11/14 21:25, Hans-Peter Diettrich wrote: What about file I/O? It should be possible to read (and write) files of either endianness. Standard I/O only supports single byte code pages (which should be documented). Please clarify "single byte code pages".

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"

Sven Barth schrieb: Just a little remark: please don't throw in WideString, which is a completely different type and only there for easy compatibility with COM and other Windows APIs. I mentioned it for completness, and because (at least in Delphi) the elements of an UnicodeString are WideCh

Re: [fpc-devel] ThousandSeparator

Sven Barth schrieb: At my old company our Delphi application handled runtime changes to these settings rather well. For display the normal XToY (e.g. DateToStr) functions are used which use the DefaultFormatSettings which are updated automatically (the VCL's message loop triggers a repaint whe

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicodesupport"

Jonas Maebe schrieb: On 26/11/14 17:41, Tomas Hajny wrote: BTW, in this context - can users choose UTF16BE on little endian platforms (and vice versa)? No, because we do not have any routines that allow a user to set/change the codepage of a unicodestring (either at run time or at compile time

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"

Jonas Maebe schrieb: Technically, that section literally states that they will be concatenated without data loss and that the result is then converted to the target string's encoding (except in case the target is RawByteString). How that is implemented exactly is undefined; again in the meaning

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"

Michael Schnell schrieb: So seemingly you could do MyStringType = type AnsiString(CP_UTF16), and seemingly the size information is set according to this. Not in Delphi XE. DoDi ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http:/

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"

Mattias Gaertner schrieb: For example: CP_ACP=0, DefaultSystemCodePage=1252 That means static code page is always 0, while dynamic code page can be 0 or 1252. Both describe the same encoding. A *dynamic* encoding *never* can be CP_ACP nor CP_NONE (in Delphi). These values are allowed only for

Re: [fpc-devel] ThousandSeparator

Ewald schrieb: Of the OS/window manager actually. You are of course right in that there are a certain set of separators that can be used, but the exact separator to use is dependent on the system. Sounds easy, but just yesterday I ran into a bunch of related problems. Even if the following is

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"

Michael Schnell schrieb: I fail to understand some of the text. It seems to be unavoidable to use the name "ANSIString" even though I always though up when seeing a thing called "ANSI" containing Unicode (e. g. "UTF8String = type AnsiString(CP_UTF8)" ). Seemingly here the "bytes per chara

Re: [fpc-devel] Codepage aware RTL

Mattias Gaertner schrieb: Hi, The page about "FPC Unicode support" mentions what has already been updated to preserve character data. http://wiki.freepascal.org/FPC_Unicode_support#RTL_changes Is there already a page about what has not (yet) been updated aka does not work with all code pages?

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"

Michael Schnell schrieb: On 11/26/2014 11:40 AM, Mattias Gaertner wrote: Ansistring supports only one byte per character code pages. Even more confused. Am I wrong thinking that with code aware Strings, for Delphi XE compatibility, in Windows CP_ACP needs to be UTF16 (if not right, than due

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"

Michael Schnell schrieb: On 11/26/2014 12:09 PM, Sven Barth wrote: In Delphi (and FPC) CP_ACP corresponds by default with the current system codepage (e.g. CP1252 on a German Windows). OK. So in Delphi XE (in Germany) String(CP_ACP) is the same as String(CP1252) but different from String wi

Re: [fpc-devel] Trying to understand the wiki-Page "FPC Unicode support"

Mattias Gaertner schrieb: On Wed, 26 Nov 2014 11:23:17 +0100 Michael Schnell wrote: Seemingly here the "bytes per character" setting implicitly is thought of as a port of the "code-page" definition. correct ? Code page define bytes per character. Huh? Not all codepages have a fixed numbe

Re: [fpc-devel] ThousandSeparator

Mattias Gaertner schrieb: Does concatenating a string and a WideChar create a UnicodeString? Can this become a problem? Concatenation requires 2 strings, so everything depends on the concrete code. Regardless of eventual compiler magics, something like this will happen: var c: WideChar; s,

Re: [fpc-devel] ThousandSeparator

Michael Van Canneyt schrieb: The ThousandSeparator is "char" and supports only 1 byte characters. For example French and Russian need more. Are there any plans to extend it? Plans: yes. Time: no. Maybe a widechar is sufficient ? Making it a string is more invasive than making it a widechar.

Re: [fpc-devel] Clarify expression grammar

Vsevolod Alekseyev schrieb: Hi all, in the FPC reference at http://www.freepascal.org/docs-html/ref/refse68.html#x127-13700012.1 , the formal grammar spec only goes down as far as factor. Can I please see the grammar for variable reference? A variable reference can be an arbitrarily complex

Re: [fpc-devel] Clarify expression grammar

Vsevolod Alekseyev schrieb: Hi all, in the FPC reference at http://www.freepascal.org/docs-html/ref/refse68.html#x127-13700012.1 , the formal grammar spec only goes down as far as factor. Can I please see the grammar for variable reference? A variable reference can be an arbitrarily complex

Re: [fpc-devel] Small virtual machine to cross compile FPC

Paul Breneman schrieb: I think 100Mb is a bit small. You'll need cross-binutils, X, cross-dev libs and whatnot. 650Mb would be feasable, I guess. Thanks for that info, but couldn't most of that be download into the VM *after* it is running? Seems to me I'd like the *smallest* VM and then h

Re: [fpc-devel] Proof of Concept ARC implementation

Sven Barth schrieb: On 30.10.2014 04:14, Hans-Peter Diettrich wrote: I wonder how difficult it would be to implement the existing Interface refcounting model for TObject, so that this runtime variation could be tested and benchmarked as well, in addition to the current compiletime approach

Re: [fpc-devel] Proof of Concept ARC implementation

Sven Barth schrieb: On 28.10.2014 09:57, Hans-Peter Diettrich wrote: > Something like ShortString and AnsiString? Take unit Typinfo for example where quite some methods take a TObject instance. The TypInfo methods can determine the exact type of their arguments, and act ins

Re: [fpc-devel] Proof of Concept ARC implementation

Sven Barth schrieb: On 28.10.2014 10:19, Michael Schnell wrote: On 10/27/2014 07:59 PM, Sven Barth wrote: - in code that does not use ARC ("modeswitch arc off" - the default; or maybe better a local directive) all instance variables are considered "weak" While I do have a vision what "weak"

Re: [fpc-devel] Proof of Concept ARC implementation

Sven Barth schrieb: On 28.10.2014 10:15, Michael Schnell wrote: On 10/27/2014 05:17 PM, Hans-Peter Diettrich wrote: Something like ShortString and AnsiString? Only that ShortStrings can easily be avoided (AFAIK, no great performance advantage to use them) and hence are seldom used right now

Re: [fpc-devel] Proof of Concept ARC implementation

Sven Barth schrieb: Am 27.10.2014 23:41 schrieb "Boian Mitov" >: > > Well... we may differ on this one. I absolutely love attributes, but I guess that is just me :-D . > I think attributes are the greatest thing that has happened to Delphi ever, I just wish they ware

Re: [fpc-devel] Small virtual machine to cross compile FPC

Paul Breneman schrieb: I've spent a bit of time during the past 7 years trying to figure out how to simplify things by avoiding cross-compiling. This page has many of the details: http://turbocontrol.com/monitor.htm I think there is a way to simplify cross-compiling. Levinux is a small (~

Re: [fpc-devel] Proof of Concept ARC implementation

Boian Mitov schrieb: In general the C/C++ notion of doing as little in the language as possible, and as much in library has worked very well for it over the years. Yes, pluggable languages concept has existed at least since C ;-) . I agree, and as I said has worked well. AFAIR such languages

Re: [fpc-devel] Proof of Concept ARC implementation

Sven Barth schrieb: Am 27.10.2014 21:00, schrieb Hans-Peter Diettrich: Sven Barth schrieb: Am 27.10.2014 17:20 schrieb "Hans-Peter Diettrich" mailto:drdiettri...@aol.com>>: > Something like ShortString and AnsiString? With the difference that Short- and AnsiStrin

Re: [fpc-devel] Proof of Concept ARC implementation

Sven Barth schrieb: A semicolon has the problem that you need to distinguish between it being a modifier and a normal following identifier as not every keyword is a keyword in every context (like for example "read" and "write" for properties). In this discussion I almost miss the elementary

Re: [fpc-devel] Proof of Concept ARC implementation

Kostas Michalopoulos schrieb: On Mon, Oct 27, 2014 at 5:17 PM, Hans-Peter Diettrich mailto:drdiettri...@aol.com>> wrote: Then the compiler can safely generate refcounting code for *all* objects and non-weak references, and the counting methods take care of required oper

Re: [fpc-devel] Proof of Concept ARC implementation

Sven Barth schrieb: Am 27.10.2014 17:20 schrieb "Hans-Peter Diettrich" <mailto:drdiettri...@aol.com>>: > Something like ShortString and AnsiString? With the difference that Short- and AnsiString are assignable to eachother while Jonas does not want that for reference

Re: [fpc-devel] Proof of Concept ARC implementation

Jonas Maebe schrieb: Additionally, as mentioned before, I still believe it's a very bad idea to be able to inherited from a regular class and turn it into a reference counted class. Reference counted and non-reference-counted classes are different language entities with different behaviour and

Re: [fpc-devel] Proof of Concept ARC implementation

Sven Barth schrieb: Am 25.10.2014 03:17 schrieb "Hans-Peter Diettrich" <mailto:drdiettri...@aol.com>>: >> - a class instance is destroyed once the reference count reaches zero (and Free does not work for them) > > > Shouldn't Free be usable as a final

Re: [fpc-devel] Proof of Concept ARC implementation

Sven Barth schrieb: Hello together! I've now finished my Proof of Concept ARC implementation which is based on the RFC I published a few weeks back: http://lists.freepascal.org/fpc-devel/2014-September/034263.html Fine :-) To recap: [...] - a class instance is destroyed once the reference

Re: [fpc-devel] suggestion: virtual method co-variance

Sven Barth schrieb: At least at first sight there don't seem to be any real (technical) reasons to not covariance for return values. Parameters would be a different topic though... Just so I get the idea right: === code begin === type TBar = class function Test: TObject; virtual; en

Re: [fpc-devel] Suggestion: reference counted objects

Marco van de Voort schrieb: In our previous episode, Sven Barth said: It looks to me like inside methods Self doesn't deserve refcounting, because a method can be invoked only with an existing instance, which will stay alive at least until the call returns. That's the thing I'm not yet entirely

Re: [fpc-devel] Suggestion: reference counted objects

Sven Barth schrieb: There are however some nasty problems inside constructors and destructors, because "Self" is reference counted as well (and should be after all as we don't want the instance to be destroyed behind our backs suddenly). IMO before the end of a constructor, and before the st

Re: [fpc-devel] Suggestion: reference counted objects

Florian Klämpfl schrieb: If the time spent in this thread had been spent in coding, FPC would have already ARC. The list has approx. 600 members, 200 message were written. If each of the 600 members spent on average 1 min reading this thread, this is 2000 man-hour, i. e. approx. 1 MY :) First

Re: [fpc-devel] Suggestion: reference counted objects

Mark Morgan Lloyd schrieb: Boian Mitov wrote: I think parallel processing belongs in library implementations. I have reservations, based in part on the fact that other language implementations are prepared to assume responsibility for parallelisation, in part on experience with e.g. APL wh

Re: [fpc-devel] Suggestion: reference counted objects

Boian Mitov schrieb: In general, records and classes are inherently the same thing (and in C++ are indeed practically interchangeable). This model might have been the reason for introducing Object at all, for compatibility with CBuilder. The only real difference in Delphi/FPC is that record

Re: [fpc-devel] Suggestion: reference counted objects

Sven Barth schrieb: Am 22.09.2014 12:59 schrieb "Hans-Peter Diettrich" > That's why I also suggested an compiler option, useful for all people which care about program size or ARC at all. The problem with the compiler option is that you'd need to rebuild the complete

Re: [fpc-devel] weak referencing (was Suggestion:.....)

Marco van de Voort schrieb: (to Sven) So the cycle break mechanism is going to be marking potential cycle cases as weak. Do you still plan to at least detect cycles for debugging purposes? Or is the cycle detection itself already too hard? IOW I'm wondering what will happen (and what to do) i

Re: [fpc-devel] Suggestion: reference counted objects

Michael Schnell schrieb: On 09/20/2014 08:04 PM, Boian Mitov wrote: This is actually a very good idea IMHO! I would vote for it. Record inheritance is something I miss badly in Delphi. As said in a previous mail: why have "Record" ad all, if you want things like inheritance (and "active" pr

Re: [fpc-devel] Suggestion: reference counted objects

Sven Barth schrieb: Am 22.09.2014 09:47 schrieb "Michael Schnell" > Why not use "interface" to add ref-counting to an object ? This seems to work nicely even though the name "interface" in not "speaking" on that behalf. Because you'll need to declare an interface for each class you want to

Re: [fpc-devel] Suggestion: reference counted objects

Sven Barth schrieb: On 21.09.2014 21:09, Hans-Peter Diettrich wrote: Sven Barth schrieb: [...] I'd add a _RefCount field to TObject, regardless of whether it's really used later; this will fix the field offset - just like the VMT reference is fixed in TObject, but not in Object t

Re: [fpc-devel] Suggestion: reference counted objects

Florian Klämpfl schrieb: Am 21.09.2014 um 07:22 schrieb Hans-Peter Diettrich: Boian Mitov schrieb: That is easy. it gets incremented when it gets assigned. The running threads have no way of accessing it if there is no reference (assignment) already in place. The problem arises when an

Re: [fpc-devel] Suggestion: reference counted objects

Marco van de Voort schrieb: In our previous episode, Hans-Peter Diettrich said: IMO Weak references should be reserved for users who accept possible consequential problems, but should never be used in standard libraries. At least I'd suggest to make weak references subject to an com

Re: [fpc-devel] Suggestion: reference counted objects

Sven Barth schrieb: On 20.09.2014 13:42, Sven Barth wrote: On 20.09.2014 13:11, Peter Popov wrote: - to remedy this TObject is extended with non-virtual methods that allow manual reference counting and would rely on the RTTI data I mentioned (let's call the methods AddRef, Release, IsReferen

Re: [fpc-devel] Suggestion: reference counted objects

Boian Mitov schrieb: That is easy. it gets incremented when it gets assigned. The running threads have no way of accessing it if there is no reference (assignment) already in place. The problem arises when an object is destroyed, or even elected for destruction in _Release, while another thre

Re: [fpc-devel] Suggestion: reference counted objects

Giuliano Colla schrieb: Hi Boian, I'm easily convinced that you've developed a lot of things using reference counting. Design is the art of compromise, and possibly in your class of application that's the best compromise. But we should never forget that our class of applications isn't the on

Re: [fpc-devel] Suggestion: reference counted objects

Sven Barth schrieb: Am 20.09.2014 20:34 schrieb "Giuliano Colla" > A general mechanism to be reliable should take into account all possibilities. If it does, it will block threads even when unnecessary. If it doesn't, it will be unsafe. That would work the same way as it does in interfaces

Re: [fpc-devel] Suggestion: reference counted objects

Boian Mitov schrieb: The short story is that any approach has issues. The component container approach has issue of a single ownership with the easy loss of pointers. The ref counting has the danger of circular references. The GC has the non deterministic behavior (Actually I proposed a determ

Re: [fpc-devel] Suggestion: reference counted objects

Sven Barth schrieb: On 20.09.2014 12:36, Hans-Peter Diettrich wrote: AFAIK some Delphi XE made TObject itself managed, by reference counting. It would be easy to introduce the same feature in FPC, so that no special base class would be required. Like with extended RTTI a decision should be

Re: [fpc-devel] Suggestion: reference counted objects

Fabrício Srdic schrieb: Hello, In platforms with managed code (.NET, Java), objects are automatically freed by the memory manager / garbage collector. Would not it be interesting to have a similar feature in FPC? AFAIK some Delphi XE made TObject itself managed, by reference counting. It w

Re: [fpc-devel] RTTI generating

Sven Barth schrieb: Am 20.09.2014 01:52 schrieb "Hans-Peter Diettrich" > It's up to the coder to make all properties etc. published, when he *intends* to ever use RTTI on them. That't the way to tell the compiler what to do. The extended RTTI introduced with Delphi

Re: [fpc-devel] RTTI generating

Boian Mitov schrieb: On Fri, 19 Sep 2014, Adriaan van Os wrote: Your remarks seem to imply that you think RTTI can be used to inspect any aspect of an object. It was/is not meant for that. <<< Quite incorrect. All languages with modern RTTI allow for full object inspection, and that includ

Re: [fpc-devel] Method for write string into TStreamt

Dmitry Boyarintsev schrieb: How about introducing a default parameter? The parameter keeps the method backward compatible, allowing write a string without the prefix. public procedure TStream.WriteAnsiString( const S: string; withLength: Boolean = true; How should a string without a leng

Re: [fpc-devel] TTimers and TThreads. Attn Michael Schnell

Giuliano Colla schrieb: If you're using relative times and not absolute ones, then you may avoid the search, without need to resort, using a slightly different scheme, i.e. entering in a sorted list the times *relatives to the previous one*. Then your queue can run out of sync with the absolu

Re: [fpc-devel] Extended($FFFFFFFFFFFFFFFF) = -1?

Ewald schrieb: On 03 Mar 2014, at 12:49, Hans-Peter Diettrich wrote: How (which data type) does *your* parser store untyped numerical constants? Roughly like this (syntax may be a bit awry, but you get the point): TIntegerNumber = Record Case SignedNess: TSignedNess of snPositive: UValue

Re: [fpc-devel] Extended($FFFFFFFFFFFFFFFF) = -1?

Ewald schrieb: On 03 Mar 2014, at 00:29, Hans-Peter Diettrich wrote: `-1` would then be $1 , whereas $ would be $0 . It really is quite easy to store it like that and `fix` things [picking a fitting datatype] afterwards. The datatype

Re: [fpc-devel] Extended($FFFFFFFFFFFFFFFF) = -1?

Ewald schrieb: Talking about principles: If hexadecimal is actually used to represent bit patterns (as Hans-Peter Diettrich wrote), then the decision to use a signed type here seems to violate this (represent bitpatterns) principle, since the highest bit in a signed number has a different

Re: [fpc-devel] Extended($FFFFFFFFFFFFFFFF) = -1?

Ewald schrieb: On 28 Feb 2014, at 20:39, Jonas Maebe wrote: All hexadecimal constants are (conceptually) parsed as int64, so this is by design. int64($) is not -1. By the way, what do you do when you want to port fpc to a one's comlement machine (if they still exist)? Nume

Re: [fpc-devel] Class property and virtual getter

Michael Schnell schrieb: On 02/28/2014 02:18 AM, Hans-Peter Diettrich wrote: So the lack of "Self" seems to apply to "static;" methods, not to "class" methods. I'll ask in an EMBT group for a description of "static;", the OH seems to reflect th

Re: [fpc-devel] Class property and virtual getter

Jonas Maebe schrieb: Error: Only class methods, class properties and class variables can be referred with class references You have to declare an instance and then call its property. You don't have to instantiate the instance if the property maps to a class method. Technically there's some

Re: [fpc-devel] Class property and virtual getter

Sven Barth schrieb: Am 27.02.2014 15:35, schrieb Hans-Peter Diettrich: Also "self" is no more known inside class methods in XE. In D7 it was the class type instead of the instance pointer. Thus a too restrictive compiler, geared towards compatibilitiy with *new* Delphi versions,

Re: [fpc-devel] Class property and virtual getter

Michael Van Canneyt schrieb: The reason is explained in the upcoming docs. Namely: a static method cannot be overridden. Sure, but virtual methods (including class methods) can be overridden. The class property is part of this particular class, and descendent classes should not be able to o

Re: [fpc-devel] Class property and virtual getter

Michael Van Canneyt schrieb: So what's the special use of a *class* property? If it exists for Delphi compatibility only, why then is it handled differently from "property"? The reason is explained in the upcoming docs. Namely: a static method cannot be overridden. Sure, but virtual method

Re: [fpc-devel] Class property and virtual getter

Sven Barth schrieb: Changing the GetResourceClient method from virtual to static works Is this a bug or by design? As Michael said this is by design. If you want to use a non-static class procedure you must not use "class property", but only "property" (yes, that works). So what's the speci

Re: [fpc-devel] About typecasts and the documentation

Martin Frb schrieb: http://www.freepascal.org/docs-html/ref/refse67.html#x124-13400012.4 In general, the type size of the expression and the size of the type cast must be the same. However, for ordinal types (byte, char, word, boolean, enumerates) this is not so, they can be used interchangeabl

Re: [fpc-devel] Incomplete docs on operator precedence / Question about actual precedence

Martin Frb schrieb: Further, it appears that ^ has a higher precedence than unary - IMO pointer/address arithmetic (should) follows its own rules. Unary - and @ should not be applicable to addresses. @ also is restricted to arguments which *do* have an address, i.e. not applicable to arithm

Re: [fpc-devel] Black List of examples that FPC won't compile.

Maciej Izak schrieb: Following by current logic, this example should not compile: --begin code-- TA = class procedure Foo; end; TB = class(TA) procedure Foo(A: Integer = 0); overload; end; var b: TB; begin b := TB.Create; b.Foo; // should raise Error: Can't determine which o

Re: [fpc-devel] DOS GUI

Thaddy schrieb: Well, I have a statement from their legal dating from 2005 amounting to: "we use it as you intended (sic) and see no reason to quote that this sourcecode is yours. Furthermore, the two units that contain said sourcecode you refer to are protected under U.S. copyright law and are

Re: [fpc-devel] DOS GUI

Mark Morgan Lloyd schrieb: Hans-Peter Diettrich wrote: If the owner wants that not to happen,, choose any of these licenses mentioned. This is really important. Without huge legal fees I can't get my intellectual property back Sorry, that's nonsense. You still have all righ

Re: [fpc-devel] DOS GUI

Thaddy schrieb: It happened to me once or twice ;) that a certain company with ever changing names used my sourcecode and licensed it under their own closed terms because i included the term: "use as you like". Better: "free for private use". If the owner wants that not to happen,, choose an

Re: [fpc-devel] Explanation about code page-aware AnsiStrings

Sven Barth schrieb: On 08.01.2014 19:57, Hans-Peter Diettrich wrote: It looks to me, however, that no conversion occurs at all! The strings are only concatenated as they are. Same for a concatenation of (global) RawByteString variables. This of course were not a desireable implementation

Re: [fpc-devel] Explanation about code page-aware AnsiStrings

Sven Barth schrieb: Am 08.01.2014 15:58 schrieb "Hans-Peter Diettrich" <mailto:drdiettri...@aol.com>>: > Delphi concatenates RawByteStrings to the dynamic encoding of the *first* string, the appended strings eventually are converted before concatenation. Special handli

  1   2   3   4   5   6   7   8   9   10   >