Re: [fpc-pascal] constant records as default parameters
> AFAIK default parameters can only be simple types, not complex types
> like records.
Well... it certainly appears to be so...
> Although, I did get the following program using a default
> class parameter to compile and run.
Kinda defeats the purpose (low overhead). I'll stick with two simple params
with
defaults. (The other way would be to write more overloaded functions, but
that's cumbersome, and has overhead of its own)
You know, it's just occurring to me that I wouldn't be saving anything anyway:
any parameter with a default value must be passed-by-value, not by reference.
So I'm passing two longints either way. Whether they're adjacent doesn't really
make any difference at all.
> (And I thought you could not have var default parameters).
You can't. Here is a much shorter example:
{$mode objfpc}
procedure s (var a : longint = 0);
begin
inc (a);
end;
begin
s; // Error: Variable identifier expected
end.
Perhaps it's a compiler bug that it doesn't complain about the indication of a
var default parameter; however it definitely complains when you actually try to
put that default parameter to use. I guess the default parameter part in the
function header is simply being ignored.
Thanks for your input, though! I've got a more definitive answer now.
Although I still continue to wonder about constant records and record default
params, even if they can't pass-by-ref.
~David.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Moving callbackfunctions to class
31.12.2010 7:53, Darius Blaszyk wrote:
I installed 2.5.1 just to test if it was possible to use static class methods
or not. Apparently not so it seems. It was a good try, but it failed. Thanks
anyway for the help and explanation Jonas.
Try {$mode delphi}.
Best regards,
Paul Ishenin
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode strings
Jonas Maebe kirjoitti tiistai 28 joulukuu 2010 12:31:08: > Delphi's UnicodeString supports holding strings with arbitrary encodings > (not just UTF-16), along with transparent re-coding of strings when > assigning them to unicodestrings whose codepage has been statically > defined at compile time. Thanks. Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode strings
In our previous episode, Jonas Maebe said: > > On 28 Dec 2010, at 11:22, Juha Manninen wrote: > > > What is the difference between the current FPC's UnicodeString and > > Delphi's UnicodeString? I am confused with all these string types and > > encodings. > > Delphi's UnicodeString supports holding strings with arbitrary encodings > (not just UTF-16), along with transparent re-coding of strings when > assigning them to unicodestrings whose codepage has been statically > defined at compile time. This is afaik not true, or ill formulated. The D2009+ unicodestring type is much like FPC 2.4's Unicode string or Kylix and older FPC's non COM Widestring (refcounted 2-byte type) , it is the ansistring type (1-byte type) that gets codepage support. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode strings
Marco van de Voort kirjoitti perjantai 31 joulukuu 2010 13:04:27: > In our previous episode, Jonas Maebe said: > > Delphi's UnicodeString supports holding strings with arbitrary encodings > > (not just UTF-16), along with transparent re-coding of strings when > > assigning them to unicodestrings whose codepage has been statically > > defined at compile time. > > This is afaik not true, or ill formulated. The D2009+ unicodestring type is > much like FPC 2.4's Unicode string or Kylix and older FPC's non COM > Widestring (refcounted 2-byte type) , it is the ansistring type (1-byte > type) that gets codepage support. UTF-16 needs codepages, too. I think only the 4-byte char type (is it UTF-32) would solve all encoding problems. All characters of all languages fit into 2^32 space. Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode strings
2010/12/31 Juha Manninen : > UTF-16 needs codepages, too. I don't think so. What would a code page be used for with UTF-16. UTF-16 itself is already an encoding, implictly stating one and only one code page, if it can be named a code page. Vincent ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode strings
In our previous episode, Juha Manninen said: > > Widestring (refcounted 2-byte type) , it is the ansistring type (1-byte > > type) that gets codepage support. > > UTF-16 needs codepages, too. > I think only the 4-byte char type (is it UTF-32) would solve all encoding > problems. codepage<>encoding > All characters of all languages fit into 2^32 space. character<>codepoint. Anyway surrogates etc is a different problem of processing true unicode spec, and the bits that UTF32 solves are the lesser ones. (and at the expense of speed and memory) The document is a bit messy (since it was conceived before Delphi 2009 came out, and later updates for that), but http://www.stack.nl/~marcov/unicode.pdf has some details. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode strings
Vincent Snijders kirjoitti perjantai 31 joulukuu 2010 14:09:25: > 2010/12/31 Juha Manninen : > > UTF-16 needs codepages, too. > > I don't think so. What would a code page be used for with UTF-16. > > UTF-16 itself is already an encoding, implictly stating one and only > one code page, if it can be named a code page. Ok, right. I think I wanted to write: UTF-16 needs variable length encoding, too. It is not guaranteed to be 2 bytes long although in most cases it is. Juha ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[2]: [fpc-pascal] Moving callbackfunctions to class
Hello FPC-Pascal, Friday, December 31, 2010, 1:53:31 AM, you wrote: DB> I installed 2.5.1 just to test if it was possible to use DB> static class methods or not. Apparently not so it seems. It was a DB> good try, but it failed. Thanks anyway for the help and DB> explanation Jonas. DB> It seems that GLut however offers a backdoor as was pointed DB> out by honza. By using glutGetWindow, I can simply check in the DB> main callback function which window paint method to handle. Thanks DB> for the tip! You can create the same effect using trampolines, but unless fpc has a way to create trampolines you will be forced to use assembler (I was using them in assembler in the past with Delphi). With this trampolines you create a different callback pointer for each callback and in this callback the Self pointer is "hardcoded" and the "class callback" called, which creates the effect that the callback is connected with the class. I do not know if all platforms support code execution in data memory :-? -- Best regards, José ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Moving callbackfunctions to class
On Dec 31, 2010, at 10:43 AM, Paul Ishenin wrote:
> 31.12.2010 7:53, Darius Blaszyk wrote:
>> I installed 2.5.1 just to test if it was possible to use static class
>> methods or not. Apparently not so it seems. It was a good try, but it
>> failed. Thanks anyway for the help and explanation Jonas.
> Try {$mode delphi}.
>
Thanks for the tip Paul. Unfortunately it did not help. See for the results
below.
Delphi mode:
class -> Error: Incompatible types: got "class TfpgGLApplication.CDisplayFunc;
CDecl;" expected ""
static -> Error: Incompatible types: got "class TfpgGLApplication.CDisplayFunc;
CDecl; Static;" expected ""
ObjFPC mode:
class -> Error: Incompatible types: got "" expected ""
static -> Error: Incompatible types: got "" expected ""
I was surprised that under objfpc there is no difference in error message.
Regards, Darius___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: Re[2]: [fpc-pascal] Moving callbackfunctions to class
On Dec 31, 2010, at 1:53 PM, José Mejuto wrote: > Hello FPC-Pascal, > > Friday, December 31, 2010, 1:53:31 AM, you wrote: > > DB> I installed 2.5.1 just to test if it was possible to use > DB> static class methods or not. Apparently not so it seems. It was a > DB> good try, but it failed. Thanks anyway for the help and > DB> explanation Jonas. > DB> It seems that GLut however offers a backdoor as was pointed > DB> out by honza. By using glutGetWindow, I can simply check in the > DB> main callback function which window paint method to handle. Thanks > DB> for the tip! > > You can create the same effect using trampolines, but unless fpc has a > way to create trampolines you will be forced to use assembler (I was > using them in assembler in the past with Delphi). With this > trampolines you create a different callback pointer for each callback > and in this callback the Self pointer is "hardcoded" and the "class > callback" called, which creates the effect that the callback is > connected with the class. > > I do not know if all platforms support code execution in data memory :-? Unfortunately I need a platform independent method to handle this. So assembler is not really the way I want to go, unless it proves to be the only way. Regards, Darius___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Moving callbackfunctions to class
On Fri, Dec 31, 2010 at 11:01 AM, Darius Blaszyk wrote: > Thanks for the tip Paul. Unfortunately it did not help. See for the results > below. Using a correct type cast it should work. Which line brings the errors? -- Felipe Monteiro de Carvalho ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Moving callbackfunctions to class
On Fri, 31 Dec 2010 14:03:27 +0100 Darius Blaszyk wrote: > Unfortunately I need a platform independent method to handle this. So > assembler is not really the way I want to go, unless it proves to be the only > way. Now you know why I called glut a major PITA and using platform dependent assembler code to wrap a cross platform lib is just not right. Why don't you look at the context creation code of either TOpenGLContext from Lazarus or the equivalent component from GLScene (yes, it is more difficult than glut but not that difficult)? Glut is just not meant for the things you are doing with it and you are working around restrictions which other context creation mechanisms just don't have. But feel free to ignore my advice as it is your time you are wasting. Happy new year and good luck. R. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Moving callbackfunctions to class
On Fri, 31 Dec 2010, Darius Blaszyk wrote:
On Dec 31, 2010, at 10:43 AM, Paul Ishenin wrote:
31.12.2010 7:53, Darius Blaszyk wrote:
I installed 2.5.1 just to test if it was possible to use static class methods
or not. Apparently not so it seems. It was a good try, but it failed. Thanks
anyway for the help and explanation Jonas.
Try {$mode delphi}.
Thanks for the tip Paul. Unfortunately it did not help. See for the results
below.
Delphi mode:
class -> Error: Incompatible types: got "class TfpgGLApplication.CDisplayFunc; CDecl;"
expected ""
static -> Error: Incompatible types: got "class TfpgGLApplication.CDisplayFunc; CDecl; Static;"
expected ""
ObjFPC mode:
class -> Error: Incompatible types: got ""
expected ""
static -> Error: Incompatible types: got ""
expected ""
Even if they worked, it would do you no good: you would have no access to instance fields,
or the VMT, since neither is passed when glut calls your callback:
- Class methods need 'self' (it will contain the VMT),
and cannot access fields of an instance (since there is none to work with)
- Static methods do not need self, but they also cannot access fields of a
class instance.
Static methods are like regular procedures, but their name just contains a
dot (.) character.
Conclusion: You can just as well use a regular procedure; the rest is a waste
of your time.
Michael.
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Moving callbackfunctions to class
On Dec 31, 2010, at 2:06 PM, Felipe Monteiro de Carvalho wrote:
> On Fri, Dec 31, 2010 at 11:01 AM, Darius Blaszyk
> wrote:
>> Thanks for the tip Paul. Unfortunately it did not help. See for the results
>> below.
>
> Using a correct type cast it should work. Which line brings the errors?
Hi Felipe,
Casting works, but the app crashes (Michael get that smile from your face ;)
Here's an example app for those that are curious:
Regards, Darius
program gluttest;
{$mode delphi}{$H+}
{$define ClassGLutWindow}
uses
Classes, SysUtils, gl, glut;
{$IFDEF ClassGLutWindow}
type
{ TGLWindow }
TGLWindow = class
public
constructor Create;
class procedure DisplayFunc; cdecl;
end;
var
GLWindow: TGLWindow;
constructor TGLWindow.Create;
begin
glutInitWindowSize(350, 200);
glutInitWindowPosition(0, 0);
glutCreateWindow(PChar('GLut window'));
//GLut callback functions
glutDisplayFunc(TGlutVoidCallback(DisplayFunc));
end;
class procedure TGLWindow.DisplayFunc; cdecl;
{$ELSE}
procedure DisplayFunc; cdecl;
{$ENDIF}
begin
//clear background
glClearColor(0.3, 0.3, 0.3, 1);
glClear(GL_COLOR_BUFFER_BIT);
//swap the buffer
glutSwapBuffers;
end;
begin
glutInit(@argc, argv);
glutInitDisplayMode(GLUT_DOUBLE or GLUT_RGBA);
{$IFNDEF ClassGLutWindow}
glutInitWindowSize(350, 200);
glutInitWindowPosition(0, 0);
glutCreateWindow(PChar('GLut window'));
//GLut callback functions
glutDisplayFunc(DisplayFunc);
{$ENDIF}
{$IFDEF ClassGLutWindow} GLWindow := TGLWindow.Create; {$ENDIF}
glutMainLoop;
end.___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Moving callbackfunctions to class
On Dec 31, 2010, at 2:23 PM, Reimar Grabowski wrote: > On Fri, 31 Dec 2010 14:03:27 +0100 > Darius Blaszyk wrote: > >> Unfortunately I need a platform independent method to handle this. So >> assembler is not really the way I want to go, unless it proves to be the >> only way. > > Now you know why I called glut a major PITA and using platform dependent > assembler code to wrap a cross platform lib is just not right. Why don't you > look at the context creation code of either TOpenGLContext from Lazarus or > the equivalent component from GLScene (yes, it is more difficult than glut > but not that difficult)? Glut is just not meant for the things you are doing > with it and you are working around restrictions which other context creation > mechanisms just don't have. But feel free to ignore my advice as it is your > time you are wasting. I know that GLut is inflexible and that creating your own context is the best way to go. I'm not ignorant to your advice and besides that it is my plan to do so from the beginning. However resolving the message loop for multiple windows is more or less my last obstacle to create an opengl fpgui. When I manage this, I will plead with Graeme to refactor the existing context handling code and create a new "context" layer in fpgui. This will open up the possibility to create multiple backends to fpgui eg cairo, sdl, etc. Regards, Darius ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re[4]: [fpc-pascal] Moving callbackfunctions to class
Hello FPC-Pascal, Friday, December 31, 2010, 2:03:27 PM, you wrote: >> You can create the same effect using trampolines, but unless fpc has a >> way to create trampolines you will be forced to use assembler (I was >> using them in assembler in the past with Delphi). With this >> trampolines you create a different callback pointer for each callback >> and in this callback the Self pointer is "hardcoded" and the "class >> callback" called, which creates the effect that the callback is >> connected with the class. >> I do not know if all platforms support code execution in data memory :-? DB> Unfortunately I need a platform independent method to handle DB> this. So assembler is not really the way I want to go, unless it DB> proves to be the only way. After thinking a bit in the problem, you do not need assembler, but you will need to write a wrapper for each callback call that setup some kind of trampoline different for each callback. Just for the experiment I'll try to mockup something that should work ( if I'm able :) ). -- Best regards, José ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
[fpc-pascal] Lifetime of a database (PostgreSQL) connection
I've just taken our name server down for maintenance, and noted that a db-aware app I'd left running ground to a halt despite the fact that it was only activating queries, not establishing new (named) connections. The connection was being made by host name rather than by dotted-quad address, resulting in a long-term handle associated with the TPQConnection object. Whenever a TSQLQuery is activated, it results in the opening of a short-term handle, if I'm reading things correctly associated with a TSQLTransaction object which relies on the host information from the connection object. My expectation is that these short-term handles should not mandate a name lookup, since the host name or address cannot be specified at this point. Am I being unreasonable? -- Mark Morgan Lloyd markMLl .AT. telemetry.co .DOT. uk [Opinions above are the author's, not those of his employers or colleagues] ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
Re: [fpc-pascal] Unicode strings
In our previous episode, Juha Manninen said: > What I have understood so far: > > WideString uses UTF16 encoding. It is managed by Windows and so is not > reference counted by Delphi or FPC under Windows. However it is reference > counted by FPC on other platforms. > Then FPC has UnicodeString which is identical with WideString except that it > is always reference counted. > Delphi since v.2009 has UnicodeString as default. It also uses UTF16 > encoding. Correct. > Now there is a new branch for Delphi compatible unicode strings in FPC. > What is the difference between the current FPC's UnicodeString and Delphi's > UnicodeString? I am confused with all these string types and encodings. Afaik none, except in Delphi it is default. In FPC it is a beta feature, waiting for the codepage ansistring (which is being worked (*) in the branch that you name), before the (very massive!) rtl changes, and the option for unicodestring to be the default type become reality. The actual form of the RTL changes and default types has not even been decided. There are various opinions, but no decision has been taken. > What do you people say about Open XML: http://www.philo.de/xml/ Never used it. I use FPC's XML routines, even with Delphi. ___ fpc-pascal maillist - fpc-pascal@lists.freepascal.org http://lists.freepascal.org/mailman/listinfo/fpc-pascal
