Re: [fpc-devel] interface vs optimizer
This is by design. - Original Message - From: mariano podesta To: fpc-devel@lists.freepascal.org Sent: Saturday, January 21, 2006 1:56 AM Subject: [fpc-devel] interface vs optimizer hi people, there is a problem with functions returning interfaces: if nobody stores the result, the object decrements one reference despite turn off optimizations. sample: function getobj: IUnknown; begin Result := TInterfacedObject.Create; end; procedure test; begin getobj; // here result of getobj has died :( end; es there a solution or workaround? thanks, marianop ___ 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] Templates / Generics
Delphi 11 .Net 2.0 will support Generics. Maybe Delphi 11 Win32. This page looks only like the start of a proposal. Neither complete nor official. Why do you think, that D2006 will have generics? Not Delphi 2006, but Delphi 2007 ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Passing consts to const
procedure TestBuf(const Buf; Size: Integer); begin end; It should work. AFAIR, typed constants are treated exactly as variables with an initial value. Actually untyped parameters accept anything except numeral or untyped numeric constant in Delphi. The meaning of const in this example is contract that function will not change passed value. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] webserver
Try www.jp.freepascal.org as a workaround (works nice here), or the google cache. But I still will not be able to fill / browse bug reports! ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] fpc_ShortStr_To_WideStr
Use the bug database to report bugs. Bugs reported on the mailing list will be forgotten. I know, but www.freepascal.org cvs.freepascal.org are down (?) altrow pings show they are active... ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] TShiftState as enum
Delphi dowsn't allow sets with ordinal values larger than 255 too: That's incorrect. . Sets are restricted to a maximum of 256 members, but the ordinal values of the members can be higher. As I've already posted: sample code below not compile in any Delphi version. You can try it yourself. type aenum=510..517; aset = set of aenum; begin Writeln(sizeof(aset)); end. Delphi 2005 emits: Borland Delphi for Win32 compiler version 17.0 Copyright (c) 1983,2004 Borland Software Corporation 1.pas(2) Error: E2028 Sets may have at most 256 elements 1.pas(7) ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in PWidechar and refcounting
- Original Message - From: DrDiettrich [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Tuesday, February 15, 2005 4:11 AM Subject: Re: [fpc-devel] Bug in PWidechar and refcounting Alexey Barkovoy wrote: PAnsiChar, PChar are just pointers and not garbage collected by compiler. But AnsiString and WideString are compiler managed types. So, as Peter mentioned, behaviour you are seeing is by design. In Delphi WideString is not reference counted at all. The layout of the string prefix is dictated by the Windows API (BSTR type), and AFAIK Windows also doesn't use reference counting with this type, or with OLEVariants containing wide strings. In e-mail above I've not said anywhere about reference-counting, I've said WideString are managed by compiler. For example if you declare WideString local variable in procedure it will be automatically freed at the end of procedure in compiler generated try ... finally block. And if you declare PWideChar, allocate memory for it, when it's up to you to free this memory after you no longer need it. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Abbrevia and Delphi compatibility
2) Sets with minimal size, at least with 1 and 2 bytes for replacement
of Byte and Word types.
This is already correctly working (at least in FPC 1.9.x). For example:
type
{$MINENUMSIZE 2}
enumDMUS_VARIATIONT_TYPES = (
DMUS_VARIATIONT_SEQUENTIAL {= 0}, (* Play sequential starting with
variation 1. *)
DMUS_VARIATIONT_RANDOM {= 1}, (* Play randomly. *)
DMUS_VARIATIONT_RANDOM_START {= 2}, (* Play sequential starting with a
random variation. *)
DMUS_VARIATIONT_NO_REPEAT{= 3}, (* Play randomly, but don't play the
same variation twice. *)
DMUS_VARIATIONT_RANDOM_ROW {= 4} (* Play randomly as a row: don't
repeat any variation until all have played. *)
);
begin
WriteLn(SizeOf(enumDMUS_VARIATIONT_TYPES));
end.
will write 2
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] Bug in PWidechar and refcounting
Normally I would aggree with you, but as far as I can see, PWideChar is also an automated type. (If not then large parts of the variant-code in the RTL has to be rewritten, and probably alsoe the wstrings.inc file) From wstrings.inc: WideString is defined as a 'silent' pwidechar : a pwidechar that points to : @-8 : SizeInt for reference count; @-4 : SizeInt for size; @: String + Terminating #0; Pwidechar(Widestring) is a valid typecast. So WS[i] is converted to the address @WS+i-1. So there is a bug somewhere. But if they should not be refcounted, that's ok. But then I have some fixs for the variant-code Above is just an internal description of WideString layout in memory, so this layout allows easy type conversion of WideString to PWideChar. Note: PWideChar, PAnsiChar, PChar are just pointers and not garbage collected by compiler. But AnsiString and WideString are compiler managed types. So, as Peter mentioned, behaviour you are seeing is by design. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] VMT compatibility
I where any chance to see FreePascal generating VMT's for classes that is more compatible with C++ / TurboPascal / Delphi one? To explain mine question: recently I've been porting Delphi framework interfacing to C++ code to FPC and finded out that althrow Delphi VMT layout is compatible to C++ one, FPC is not. Are you sure Delphi is compatible to C++ or just to Borland C++? The latter would be logical, since both Delphi and C++ Builder use the same backend. Or are Delphi classes also binary compatible with Visual C++ and g++ classes? Delphi is compatible at least with Borland C++ and MS VC++. And taking in accout how COM intefaces are implemented in C++ (I'm supposing here all C++ compilers support the same syntax) - each C++ compiler supporting MS way to declare COM interfaces has compatible VMT layout. PS. I'm not insisting for compatibility on internal fields (with negative offset in Delphi case), but hope for layout compatibility of user defined virtual methods. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
[fpc-devel] Bug in compiler after fixes applied: 2005/01/10 21:50:05 jonas
Fixes description:
2005/01/10 21:50:05 jonas
+ support for passing records in registers under darwin
* tcgpara now also has an intsize field, which contains the size in
bytes of the whole parameter
I've initially filled bug report here:
http://www.freepascal.org/bugs/showrec.php3?ID=3563
After looking at problem source I've discovered that changing ncgcal.pas
around 330 line back to pre-patch (old) condition fixes mine problems:
{$ifndef cpu64bit}
// Old code ---
//if left.location.size in [OS_64,OS_S64] then
// New code ---
//{ don't call the cg64 stuff for 8-byte sized records etc }
//if is_64bit(left.resulttype.def) then
if left.location.size in [OS_64,OS_S64] then
cg64.a_param64_loc(exprasmlist,left.location,tempcgpara)
else
{$endif cpu64bit}
Mine problems seems to happen in this function (class method), but I can't
reproduce it in simpler case:
function CDXUTButton.ContainsPoint(pt: TPoint): LongBool; // this is virtual
function
begin
// this checking of class variable raises an exception
if (Text = 'aaa') then begin end;
// if line above is commented this function returns always false.
Result:= PtInRect(m_rcBoundingBox, pt);
end;
Compilation is done with -Sd -Or parameters.
PS: changing declaration to use CONST doesn't change anything:
function CDXUTButton.ContainsPoint(const pt: TPoint): LongBool;
PPS: How this can be related to this bug report?
http://www.freepascal.org/bugs/showrec.php3?ID=1807
___
fpc-devel maillist - fpc-devel@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ansistrings and widestrings
- Original Message - From: peter green [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Sunday, January 09, 2005 11:45 PM Subject: RE: [fpc-devel] ansistrings and widestrings Type // Lenght paremeters are number of CHARS not bytes TWide2AnsiMove=function(source:pwidechar; srclen:SizeInt; dest:pansichar; destlen:SizeInt): SizeInt; TAnsi2WideMove=function(source:pansichar; srclen:SizeInt; dest:pwidechar; destlen:SizeInt): SizeInt; These functions should return actual number of characters in output. Returning ZERO should indicate insufficient destination size. yes theese would be workabable but they seem to me to be a horrible Cism whats wrong with twidestringtoansistring=procedure(const source : widestring;var dest : ansistring); tansistringtowidestring=procedure(const source : ansistring;var dest : widestring); Because we need to transform from PChar to WideString or from PWideChar to AnsiString or from Array [0..xx] of Char to WideString, etc. ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ansistrings and widestrings
Well functions are called ANSI to unicode and vice versa. ANSI is always single byte; by unicode people usually refer to utf16, not multibyte encoding and both Delphi and FPC define WideString as double byte strings. So semantically functions do that is required. IMHO then assigning widestring to ansistring noone should expect multibyte encoded result. Then you need utf-8 you should call special functions. - Original Message - From: peter green [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Wednesday, January 05, 2005 8:32 PM Subject: RE: [fpc-devel] ansistrings and widestrings ok i see a MAJOR problem with the semantics of those functions. they assume that one widechar is equivilent to one ansichar (that is the source count of widechars will equal the destination count of ansichars or the source count of widechars will equal the destination count of ansichars). this is simply not the case for many encodings. (utf-8 sjis euc to name just a few) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Behalf Of Michael Van Canneyt Sent: 05 January 2005 16:11 To: FPC developers' list Subject: RE: [fpc-devel] ansistrings and widestrings On Wed, 5 Jan 2005, peter green wrote: where are theese default versions located in the code? In the inc directory of the rtl. wstrings.inc procedure Wide2AnsiMove(source:pwidechar;dest:pchar;len:SizeInt); procedure Ansi2WideMove(source:pchar;dest:pwidechar;len:SizeInt); ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
Re: [fpc-devel] ansistrings and widestrings
Firstly: I agree that Wide2AnsiMoveProc and Ansi2WideMoveProc should take size of resulting string. Next: I was wrong about ansistrings - on Windows their are (PCHAR's) used (until WinNT arrived) in far east localized versions coupled with multibyte encoding. So currenltly for legacy applications multibyte encoded character sets are supported in any WinNT box. PS. I hope mine patch (bug 3451) extending Widestring support in compiler will finally be applied to CVS and we can proceed with RTL modifications to support more extended ansi to wide strings conversions. ;-) PPS. AFAIK UTF-8 is not used internally in any OS - it's only used for storing UNICODE text in more compact form - web site authors really like it. - Original Message - From: peter green [EMAIL PROTECTED] To: FPC developers' list fpc-devel@lists.freepascal.org Sent: Thursday, January 06, 2005 12:19 AM Subject: RE: [fpc-devel] ansistrings and widestrings in wondows terminology (which i presume is where the name ansistring comes from) the windows code page which is often refered to in documentation as the ansi code page CAN be multi byte. http://www.microsoft.com/globaldev/reference/WinCP.mspx more generally i belive an ansistring is usually intended to represent text in the platforms local encoding. Whilst a widestring is meant to represent text in utf-16. The platforms local encoding may be a single byte encodeing (iso-8859-? windows-125? etc) it may be a legacy mixed width encoding (EUC-?? SHIFT-JIS BIG5 etc) or it may be a unicode transformation format which is a superset of ascii (utf-8). now for dependency reasons i belive that the default conversion functions should remain a dumb fallback BUT i also belive that the function prototypes should be designed in such a way as to allow the conversion routines to be replaced with ones that can sesiblly handle the local encoding. i've created a page on the wiki for this issue at http://www.freepascal.org/wiki/index.php/Widestrings ___ fpc-devel maillist - fpc-devel@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-devel
